SPRING OpenFlow Interworking Requirements

Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through a controlled set of instructions, called segments, by pre-pending the packet with an SR header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. Segment Routing allows one to enforce a flow through any topological path and service chaining while maintaining per-flow state only at the ingress node to the Segment Routing domain The Segment Routing architecture is described in () The Segment Routing control plane is agnostic to the data plane, and hence it can be applied to both MPLS (and its many variants) and IPv6. OpenFlow is a communications protocol and open interface defined between the control and forwarding layers(). It allows direct access to and manipulation of the forwarding plane of network devices such as switches and routers, both physical and virtual (hypervisor-based). This document introduces several scenarios and discusses the interworking between segment routing and openflow.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Modern day DCs are increasingly utilizing Openflow protocol now, while the WAN network keeps maintaining the traditional IP/MPLS network. Therefore, there exits a need for interworking between OpenFlow and the traditional IP/MPLS network. This scenario discusses how to control the inter-DC flow based on the SDN architecture and segment routing technology. As shown in Figure 1, the data center is controlled by one or several OF controllers, and all the switches and routers support flow forwarding. The switches and routers communicate with OF controller by OpenFlow protocol. The router is the layer 3 gateway for that data center. The IP/MPLS network between the data centers support segment routing technology. The segment routing label stacks are encapsulated in the edge routers of the data center. The security app and Traffic Engineering app are the application layer. They communicate with controller through north bound interface. If there are some policies, such as TE App, or security App and policy App for the inter-flow forwarding, the Apps download the service decision to the controller to result into forwarding instance, and the forwarding instances are downloaded to the gateway router of the data center to or from the forwarding label stack.

OF-based DCI-Req-1: All switches and routers in DCs should support flow forwarding. OF-based DCI-Req-2: All switches and routers in DCs should support OpenFlow protocol. OF-based DCI-Req-3: Routers in DCs should support IP/MPLS and SR technologies. OF-based DCI-Req-4: Interworking function should be transparent at the edge routers of DCs that facilitate the label stacks and SIDs. OF-based DCI-Req-5: The Interworking function should not introduce a considerable delay to the inter DC communication. OF-based DCI-Req-6: The ECMP-based path placement and explicit path mechanisms should be supported. OF-based DCI-Req-7: State information is only maintained at head-end. Tail-end and intermediate nodes do not maintain state info. Policy changes should happen at the head-end. OF-based DCI-Req-8: The interworking function should support OAM functions that is needed to manage SPRING and OF.

Figure 2 shows an SDN based WAN control scenario. The controller is introduced to the WAN network. The controller should support an externally visible Discovery Service and a Routing Service. The Discovery Service is responsible for bootstrapping and configuring the network, discovering node-capabilities, discovering and maintaining the topology graph, providing statistics and troubleshooting services and finally implementing an API for the Routing Service as well as external requests. The Routing Service is responsible for default routing on the configured network using Segment Routing principles like Node Segments and ECMP. It should also support capabilities allowing for Policy Routing, Traffic Engineering and Steering. The transit routers (Route 2 and Router 3) are only responsible for MPLS label forwarding. The SR forwarding tables could be built by the controller or the IGP protocols () ().

OF-based-SDN-WAN-Req-1: Controller may be multiple in WAN. OF-based-SDN-WAN-Req-2: The controller should support Discovery Service, Routing Service, and Forwarding Services. OF-based-SDN-WAN-Req-3: The Discovery Service should support bootstrapping and configuring the network, discovering node-capabilities and topology, statistics and troubleshooting services, and an API for the Routing Service. OF-based-SDN-WAN-Req-4: The Routing Service should support default routing on the configured network using Segment Routing principles like Node Segments and ECMP. OF-based-SDN-WAN-Req-5: The Routing Service should also support Policy Routing, Traffic Engineering and Steering. OF-based-SDN-WAN-Req-6: Forwarding tables should be maintained by the controller, but could be built by IGP protocol and the Routing Service. OF-based-SDN-WAN-Req-7: Routing Service and Discovery Service should support high availability. OF-based-SDN-WAN-Req-8: The ECMP-based path placement and explicit path mechanisms for WAN should be supported.

There are four PEs, two of them (PE1 and PE3) support Openflow protocol, and the other two(PE2 and PE4) support traditional BGP protocol as shown in Figure 3. The routes on the PE2 and PE4 are reflected to PE1 and PE3 through the BGP route reflector. For unified control and interoperability the OF controller needs to interpret the route control messages from the BGP route reflector/controller, and vice versa. The details of the interface and the messages that need to be exchanged between OF Controller and BGP Route Reflector/Controller need to be determined (future work). We introduce an OF controller in the network and an application layer server. The Apps in the Server can have visibility to the routes from BGP RR as the figure shows. This makes it feasible to export the route to OF controller. The OF controller make its forwarding decision based on the route exported from application and the application policy. The forwarding decision is made of label stack and downloaded to PE2 and PE4. The PE2 and PE3 are responsible for the segment routing encapsulation as ingress routers.

BGP-Edge-OF-IW-Req-1: The OpenFlow controller should interpret the route control messages from the BGP route reflector. BGP-Edge-OF-IW-Req-2: A routing application on the Application layer should coordinate routes between OpenFlow controller and BGP Route Reflector. BGP-Edge-OF-IW-Req-3: Segment routing encapsulation and label stacking should take place in ingress routers. BGP-Edge-OF-IW-Req-4: Forwarding decisions should be transparent to the traditional IP/MPLS network. BGP-Edge-OF-IW-Req-5: The interworking between the OF Controller and BGP RR should not introduce considerable delay to the route convergence caused by routing changes. BGP-Edge-OF-IW-Req-6: The proposed IW function solution should be scalable as network grows. BGP-Edge-OF-IW-Req-7: All BGP extensions should be supported. BGP-Edge-OF-IW-Req-8: Latest OF version should be supported.

There are two messaging systems; (1) between OF Controller and Switches/Routers, (2) between Of Controller and Route Reflector.

These messages are originated by the controller and sent to the switches.Features request message: Controller sends this message to request the identification and capabilities of a certain switch. After the receipt, the switch responds to this message by reporting its identification and capabilities. Configuration message: Controller sets and queries the switch parameters with this message. The switch responds with its parameters, if the message was a query. Modify-State: The controller uses this message to set and manage the states of the switches. Usually it is used to add/delete/modify flow entities in the OF tables and set the switch port parameters. Read-State message: This message is used by the controller to request the current configuration and stats from the switch. Packet-out message: This message is used by the controller to specify a port for the packet to leave the switch. Barrier message: These messages used by the controller to accomplish message dependencies between switches. Role-request message: This message is used by the controller to either set or query the role of the OF channel to a specific switch. Asynch-config message: Using this message, a controller can set an additional filter that it wants to receive over the OF channel.

A switch can initiate a message to the controller without being solicited by a request message from the controller. These messages will include Packet-in message: this message transfers the control of a packet to the controller. Any event like packet loss or flow table miss is sent to the controller by the switch. Flow removed message: Switch informs the controller about the removal of the flow table entry by using this message. Port-status message: Switch informs the controller about a change on the port status. This change could be caused by a user who set the port down or a link failure. Error message: Switch let controller know about any error by using this message. Symmetric Messages: These messages can be sent in both direction (switch to controller and controller to switch) without any requests. The messages include: Hollo message: hello messages are exchanged between controller and switch at the connection startup. Echo message: These messages are exchanged in request/reply fashion to check if the connection between the controller and the switch is up.

OF Controller and Route Reflector (RR) belonging to the same cluster run IBGP between them to exchange route updates. OF Controller becomes a client and receives all routes from the Route Reflector [RFC4456]. Message formats (OPEN, UPDATE, and KEEPALIVE messages), message handling and Finite State Machines (FSM) mimic [RFC4271].

In this section we discuss a simple SR OF IW Architecture Framework.

In this section we list the common SR OF interworking requirements. Common SR-OF-IW-Req-1: In case of multiple OpenFlow controllers, consistency between controllers should be supported [OpenFlow]. Common SR-OF-IW-Req-2: Security threats should be addressed by the architecture and the Interworking Function. Common SR-OF-IW-Req-3: The Interworking function should support OAM functions.

TBD.

In progress.

IANA request for this document, if any, will be discussed in a future version of this draft.