| SPRING WG | F. Hu |
| Internet-Draft | ZTE Corporation |
| Intended status: Informational | B. Khasnabish |
| Expires: March 25, 2015 | ZTE TX Inc. |
| H. Cankaya | |
| Fujitsu | |
| September 21, 2014 |
SPRING OpenFlow Interworking Requirements
draft-khc-spring-openflow-interworking-req-00.txt
This draft reviews the use cases and lists the requirements for interworking (IW) between OpenFlow (OF) and Segment routing (SR). Although the details and specifics of IW depend on both the architecture and framework, there are some common requirements. We specify those common requirements and show a simple architecture framework.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 ([I-D.filsfils-rtgwg-segment-routing]) 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([OpenFlow]). 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.
+--------------+ +-------------+ +-------------+
| TE App | |Security App | | Policy App |
+--------------+ +-------------+ +-------------+
.....................................................................................
+-------------+ +-------------+
|OF Controller| |OF Controller|
+------+------+ +------+------+
| |
................|..................................................|................
+---------------+--------------+ +-------------+---------------+
| | | |
| +-------+ | -------- | +-------+ |
| +---+ | Switch| | / \ | | Switch| +---+ |
| |VM | +-------+ +-------+ | / IP/MPLS \ | +-------+ +-------+ |VM | |
| +---+ | Router| ---|- ------------|---| | Router| +---+ |
| +-------+ | \ (Segment / | +-------+ |
| +-------+ | \Forwarding)/ | +-------+ |
| |Switch | | ---------- | |Switch | |
| +-------+ | | +-------+ |
| Data Center 1 | | Data Center 2 |
+------------------------------+ +-----------------------------+
Figure 1: Data Center Inter-connection (DCI)
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 ([I-D.ietf-isis-segment-routing-extensions]) ([I-D.ietf-ospf-segment-routing-extensions]).
+-------+ +---------+ +----------+
|Routing| |Discovery| |Forwarding|
|Service| |Service | |Service |
+-------+ +---------+ +----------+
| |
| | Service Plane
.........................|..|............................
o------v--v----o
| Controller |
o--------------o \
/ | | \ Control Plane
.............../......|.........|....\...................
/ +--v-----+ | \
/ |Router2 | | \
+--------++ +--------+ | +---------+
| Ingress | | | Router4 |
| Router1 | | +---------+
+---------+ +------v-+
| Router3|
+--------+
Figure 2: SDN-Based WAN Control
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.
+------------+
| Application|
+------------+
/ \
................../.............\.........
/ \
+--------------+ +--------+
|OF Controller |-------------| BGP RR |
+--------------+ +--------+
| \ / |
..........|.........\...../...........|.....
| \/ |
+------+ / \ +------+|
| PE1 | / \ | PE3 ||
+------+ / \ +------+|
/ |
+-----+ / Traditional +-------+
| PE2 | / IP/MPLS network | PE4 |
+-----+ +-------+
Figure 3: Interworking of OpenFlow and BGP Edge Routers
In this section we discuss a simple SR OF IW Architecture Framework.
+-------------------------------------------+
| Applications and Services Domain |
| (BGP, OF, SPRING, etc. Apps |
+-------------------------------------------+
| | |
..........|................|.....................|......
| | |
+--------------+ +------------------+ +--------------------+
|OF Controller |-----| SPRING Net | |SPRING Func.Entity |
| | | Cont.Func./Entity| | |
+--------------+ /+--------------|---+ +--------------------+
| | / | / \
.....|..|.../.................|......../............\.....
| +--/----------------+ | / \
| / | | / \
+------+ +------+ / \
| PE1 | | PE3 | / \
+------+ +------+ / \
/ \
+-----+ Traditional +-------+
| PE2 | IP/MPLS network | PE4 |
+-----+ +-------+
Figure 4: SR OF IW Architecture
In this section we list the common SR OF interworking requirements.
TBD.
In progress.
IANA request for this document, if any, will be discussed in a future version of this draft.
| [I-D.filsfils-rtgwg-segment-routing] | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J. and E. Crabbe, Segment Routing Architecture", Internet-Draft draft-filsfils-rtgwg-segment-routing-01, October 2013. |
| [I-D.ietf-isis-segment-routing-extensions] | Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B. and J. Tantsura, "IS-IS Extensions for Segment Routing", Internet-Draft draft-ietf-isis-segment-routing-extensions-02, June 2014. |
| [I-D.ietf-ospf-segment-routing-extensions] | Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W. and J. Tantsura, "OSPF Extensions for Segment Routing", Internet-Draft draft-ietf-ospf-segment-routing-extensions-02, August 2014. |
| [OpenFlow] | OpenFlow Switch Specification, Version 1.3.4", March 2014. | , "
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |