Internet DRAFT - draft-khc-spring-openflow-interworking-req
draft-khc-spring-openflow-interworking-req
SPRING WG F. Hu
Internet-Draft ZTE Corporation
Intended status: Informational B. Khasnabish
Expires: September 10, 2015 ZTE TX Inc.
H. Cankaya
Fujitsu
March 9, 2015
SPRING OpenFlow Interworking Requirements
draft-khc-spring-openflow-interworking-req-01.txt
Abstract
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.
Status of This Memo
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 September 10, 2015.
Copyright Notice
Copyright (c) 2015 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
Hu, et al. Expires September 10, 2015 [Page 1]
Internet-Draft SR OF Interworking Req. March 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3
3. Data Center (DC) Inter-connection . . . . . . . . . . . . . . 3
3.1. List of Req. for DCI . . . . . . . . . . . . . . . . . . 4
4. OpenFlow Based WAN Control . . . . . . . . . . . . . . . . . 5
4.1. List of Req. for OF-based SDN WAN . . . . . . . . . . . . 6
5. Interworking of OpenFlow and BGP Edge Routers . . . . . . . . 6
5.1. List of Req. for BGP-Edge and OF IW . . . . . . . . . . . 7
5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Controller-to-Switch Messages . . . . . . . . . . . . 8
5.2.1.1. Asynchronous and Symmetric Messages . . . . . . . 8
5.3. OF Controller and Route Reflector Messages . . . . . . . 9
6. An SR OF IW Architecture Framework . . . . . . . . . . . . . 9
6.1. Common SR OF IW Requirements . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
Hu, et al. Expires September 10, 2015 [Page 2]
Internet-Draft SR OF Interworking Req. March 2015
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.
2. Conventions and Abbreviations
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].
3. Data Center (DC) Inter-connection
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.
Hu, et al. Expires September 10, 2015 [Page 3]
Internet-Draft SR OF Interworking Req. March 2015
+--------------+ +-------------+ +-------------+
| 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)
3.1. List of Req. for DCI
o OF-based DCI-Req-1: All switches and routers in DCs should support
flow forwarding.
o OF-based DCI-Req-2: All switches and routers in DCs should support
OpenFlow protocol.
o OF-based DCI-Req-3: Routers in DCs should support IP/MPLS and SR
technologies.
o OF-based DCI-Req-4: Interworking function should be transparent at
the edge routers of DCs that facilitate the label stacks and SIDs.
o OF-based DCI-Req-5: The Interworking function should not introduce
a considerable delay to the inter DC communication.
o OF-based DCI-Req-6: The ECMP-based path placement and explicit
path mechanisms should be supported.
o 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.
Hu, et al. Expires September 10, 2015 [Page 4]
Internet-Draft SR OF Interworking Req. March 2015
o OF-based DCI-Req-8: The interworking function should support OAM
functions that is needed to manage SPRING and OF.
4. OpenFlow Based WAN Control
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
Hu, et al. Expires September 10, 2015 [Page 5]
Internet-Draft SR OF Interworking Req. March 2015
4.1. List of Req. for OF-based SDN WAN
o OF-based-SDN-WAN-Req-1: Controller may be multiple in WAN.
o OF-based-SDN-WAN-Req-2: The controller should support Discovery
Service, Routing Service, and Forwarding Services.
o 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.
o 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.
o OF-based-SDN-WAN-Req-5: The Routing Service should also support
Policy Routing, Traffic Engineering and Steering.
o 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.
o OF-based-SDN-WAN-Req-7: Routing Service and Discovery Service
should support high availability.
o OF-based-SDN-WAN-Req-8: The ECMP-based path placement and explicit
path mechanisms for WAN should be supported.
5. Interworking of OpenFlow and BGP Edge Routers
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
Hu, et al. Expires September 10, 2015 [Page 6]
Internet-Draft SR OF Interworking Req. March 2015
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
5.1. List of Req. for BGP-Edge and OF IW
o BGP-Edge-OF-IW-Req-1: The OpenFlow controller should interpret the
route control messages from the BGP route reflector.
o BGP-Edge-OF-IW-Req-2: A routing application on the Application
layer should coordinate routes between OpenFlow controller and BGP
Route Reflector.
o BGP-Edge-OF-IW-Req-3: Segment routing encapsulation and label
stacking should take place in ingress routers.
o BGP-Edge-OF-IW-Req-4: Forwarding decisions should be transparent
to the traditional IP/MPLS network.
o 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.
o BGP-Edge-OF-IW-Req-6: The proposed IW function solution should be
scalable as network grows.
Hu, et al. Expires September 10, 2015 [Page 7]
Internet-Draft SR OF Interworking Req. March 2015
o BGP-Edge-OF-IW-Req-7: All BGP extensions should be supported.
o BGP-Edge-OF-IW-Req-8: Latest OF version should be supported.
5.2. Message Formats
There are two messaging systems; (1) between OF Controller and
Switches/Routers, (2) between Of Controller and Route Reflector.
5.2.1. Controller-to-Switch Messages
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.
5.2.1.1. Asynchronous and Symmetric Messages
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
Hu, et al. Expires September 10, 2015 [Page 8]
Internet-Draft SR OF Interworking Req. March 2015
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.
5.3. OF Controller and Route Reflector Messages
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].
6. An SR OF IW Architecture Framework
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
Hu, et al. Expires September 10, 2015 [Page 9]
Internet-Draft SR OF Interworking Req. March 2015
6.1. Common SR OF IW Requirements
In this section we list the common SR OF interworking requirements.
o Common SR-OF-IW-Req-1: In case of multiple OpenFlow controllers,
consistency between controllers should be supported [OpenFlow].
o Common SR-OF-IW-Req-2: Security threats should be addressed by the
architecture and the Interworking Function.
o Common SR-OF-IW-Req-3: The Interworking function should support
OAM functions.
7. Security Considerations
TBD.
8. Acknowledgements
In progress.
9. IANA Considerations
IANA request for this document, if any, will be discussed in a future
version of this draft.
10. Normative References
[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", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), 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", draft-ietf-isis-segment-
routing-extensions-03 (work in progress), October 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", draft-ietf-ospf-segment-
routing-extensions-04 (work in progress), February 2015.
Hu, et al. Expires September 10, 2015 [Page 10]
Internet-Draft SR OF Interworking Req. March 2015
[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.
Authors' Addresses
Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68897637
Email: hu.fangwei@zte.com.cn
Bhumip Khasnabish
ZTE TX Inc.
55 Madison Avenue, Suite 160
Morristown, New Jersey 07960
USA
Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/
Hakki Cankaya
Fujitsu
2800 Telecom Parkway,
Richardson, TX 75080
USA
Email: Hakki.Cankaya@us.fujitsu.com
Hu, et al. Expires September 10, 2015 [Page 11]
