Requirements

The following are missing functionality in onos platform that is needed for Segment Routing use case:

• Multiple table support

• SPRING-OPEN needs the following pipeline processing

•                                               |- IPv4 unicast table ---|

• vlan table ---> tmac table --->|                                      --->acl table

•                                               |- MPLS unicast table -|

• The ONOS TrafficSelector has the support for IPv4 destination and MPLS label based match conditions

• MPLS BoS (Bottom of Stack) match condition to be added to Traffic Selector criteria (MplsCriterion class should be modified/extended)

• DefaultFlowRule class to be extended to include table IDs in the Flow Rule

• Switch specific processing

• Flow Table IDs for (IPv4, MPLS, VLAN, TMAC, ACL...etc) will differ depending on the underlying switch

• Network Configuration Manager functionality

• Device type (Switch/Router/Segment Router)

• Router MAC

• Router loopback IPv4 address

• Router/Node Segment Id (SId)

• Router subnets (if any)

• IsEdgeRouter

• Router name

• Adjancency Segment Ids

• OF1.3 Group support

• Default groups

• Group chaining

• Recovery from failures

• New TrafficTreatment Instructions:

• OUTGROUP

• Push MPLS with label and eth type

• Pop MPLS

• Decrement IP TTL

• Decrement MPLS TTL

• Copy In/Out TTL

Few other questions to keep in mind:

• CLI - we can keep our CLI as a separate project -- need to ensure that the rest API calls we need are implemented in onos-next -

• probably in the app and in the statistics service

• also needs to see how Karaf CLI is affected by segment routing

• GUI

• how can we avoid some of the GUI based intent creation?

• how can we display tunnels or policies?

• can we display router config in the GUI?

• Stats

• must find a way to get port-stats, group-stats and per-table flow stats

• Move from EQUAL to SLAVE

• need to change OpenFlow Controller to use SLAVE

• State info in controller if doing default routing in Intent Service

• probably not a good idea

• can intent service be made stateless?

• Any issues doing policy routing with the Intent Service?

• Only one instance of controller does policy and policy is implemented in only one switch -- so is there are need to use the intent service? Is there any harm?

• TTP Driver -

• we need to remove all intelligent group handling from driver -possibly because I think we concluded that app needs to know everything about group - is this still the case?

• what about the adjacency id stuff?

• What about the neighborSet stuff - if group handling is in app, do we still need it?

• Multi-instance issues (just need to keep in mind)

• HA - when master fails

• what happens to policy routing?

• what happens to default routing?

• Scale -- need to able to work in parallel with multi-masters for default routing

• must ensure that dst-rooted-in-trees is used for default routing

High Level Architecture Proposal

The below figure depicts the high level architecture of Segment Routing application on ONOS platform (Not all subsystem are shown in the figure).  It uses the following services of ONOS subsystems:

• • Topology service

  • Device service

  • Link service

  • Flow rule service

  • Packet service

New subsystems to be introduced in ONOS-core to be used by applications like Segment Routing application that uses Group constructus in the underlying network elements: 

• Group Subsystem

• Group store follows the same semantics of Flowrule store. i.e.

• Master instance of device will have ownership over groups with replicas available in Slave instances for fast failover

• Provides the Group descriptions and Group statistics from devices

• Creates Group chains

• Support recovery of groups when ports go UP/DOWN

   

Design

• Multiple Table Support
• Group subsystem

• Segment Routing Application Design