SPRING S. Kim Internet-Draft J. Park Expires: January 4, 2015 E. Paik KT LM. Contreras Telefonica I+D July 3, 2014 SPRING Use Cases for Software-defined Networking draft-kim-spring-use-cases-00.txt Abstract In the Software-Defined Networking (SDN) architecture, an SDN controller establishes flow paths. An SDN controller provides global optimization of paths by controlling all managed switches. However, long flow setup time and failure recovery problems arise due to control overhead of an SDN controller. Segment routing provides source routing function by designating an explicit path. SDN and segment routing can be combined to provide both global optimization and better performance. In this document, we illustrate SDN segment routing use cases of flow setup, failure recovery, Content Distribution Network(CDN), and dual homing. 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 January 4, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Kim, et al. Expires January 4, 2015 [Page 1] Internet-Draft SPRING Use Cases July 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Fast Flow Setup . . . . . . . . . . . . . . . . . . . . . . . 3 4. Failure Recovery . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Path Protection . . . . . . . . . . . . . . . . . . . . . 5 4.2. Restoration . . . . . . . . . . . . . . . . . . . . . . . 6 5. Content Distribution . . . . . . . . . . . . . . . . . . . . 6 6. Dual Homing . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Software-Defined Networking (SDN) architecture provides a network control mechanism through one or more SDN controllers. The SDN controller communicates with one or more SDN switches to calculate and/or establishes flow paths. It provides a global optimization of the managed network, but performance issues can emerge for instance with the flow setup and failure recovery processes. In order to establish new flow or change flow path, the controller should communicate with every switch along the path to send actions. The overhead can be reduced by applying source routing. Segment routing has a source routing feature that designates an explicit path which consists of a list of segments. By applying the source routing feature of segment routing to SDN, global optimization and low control overhead can be achieved at the same time. In this document, we will describe a combination of SDN and segment routing use cases. For fundamental communication, we will show flow setup and failure recovery use cases. We also describe use cases for some applications, such as Content Distribution Network (CDN) and dual homing. Kim, et al. Expires January 4, 2015 [Page 2] Internet-Draft SPRING Use Cases July 2014 2. Terminology 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]. The following terms are defined: Software-defined Networking: SDN (Software-defined Networking) provides network programmability by separating control plane and data plane of network infrastructure. Source Routing: Source routing allows a sender of a packet to partially or completely specify the route the packet takes through the network. Segment: A segment that identifies an instruction SID: A 32-bit identification for a segment Path Protection: Path protection in telecommunications is an end-to- end protection scheme used in connection oriented circuits in different network architectures to protect against inevitable failures on service providers' network that might affect the services offered to end customers. Any failure occurred at any point along the path of a circuit will cause the end nodes to move/pick the traffic to/from a new route. 3. Fast Flow Setup Source routing offers benefits to flow setup in SDN as it minimizes communications between an SDN controller and switches. In the SDN architecture, an SDN Controller decides paths for packet delivery and sets flow entries to switches along the paths to establish the flow paths. The flow setup mechanism of the SDN architecture provides controllability to network administrators, but it takes relatively long time to establish flow paths. By applying source routing to SDN flow setup, faster flow setup can be achieved. In this section, we illustrate an example case of flow setup with source routing. Figure 1 is an example SDN topology to explain source routing use cases. Kim, et al. Expires January 4, 2015 [Page 3] Internet-Draft SPRING Use Cases July 2014 __________________________ { } { SDN Controller } {__________________________} +---------1:C:2----------+ | | | 2 | 2 A:1--------1:B:3-------1:E:2--------1:D:3-----------1:F 4 | 4 | | | +---------1:G:2----------+ Figure 1: Topology Example Assumptions in the above network diagram: An SDN controller is connected to the network and is able to retrieve the topology and traffic information. Based on the information and their policies, an SDN controller calculates path from a source to a destination. In an SDN architecture, Datapath ID (DPID) and port number are used to specify a path. In Figure.1, Nodes A, B, C, D, E, F, and G are switches. A number betwen a node and a link represents a port number. Assume that A wants to send a packet to F, A first sends a packet to B, which is directly connected to A. When B receives the packet, it requests the SDN controller to handle the packet. The SDN controller extract a flow from the packet by inspecting packet header, such as MAC, IP addresses, protocol, etc. Then the SDN controller calculates a path based on its own policy. For example, path (B, E, D, F) is chosen by the policy. The SDN Controller encodes output port numbers (2, 3) of nodes in path (E, D) and insert them into the flow entry of B. SDN Controller adds a flow entry to B. The flow entry specifies the output port 3 for the flow from A to F and includes the encoded path information to establish the path to F. After the SDN controller adds the flow entry to B, B inserts the encoded path to the packet header and forwards the packet to the port 3 as instructed in its flow entry. E receives the packet and gets its output port number 2 in the packet header. Then, E removes the port number in the encoded path it consumes. E adds the flow entry which specifies output port as 3 to its flow table and forwards the packet to the port 2. D receives the packet, adds its flow entry, and forwards the packet to the port 3. The packet is sent from A to F and the path (A, B, E, D, F) is successfully set. Segment routing simplifies the task of controller. The controller does not have to encode all switch IDs and port number to specify paths. Assuem that the operator provisioned the Node-SIDs 61, 62, Kim, et al. Expires January 4, 2015 [Page 4] Internet-Draft SPRING Use Cases July 2014 63, 64, 65, 66, and 67 respectively at nodes A, B, C, D, E, F, and G. In the example above, the controller specifies the path {62, 66, 65, 67} and attaches corresponding segment routing actions. 4. Failure Recovery Source routing offers benefits to failure recovery in SDN in terms of recovery speed. If failures occur, such as link or port failures, some flows have been delivered through them will be failed. These flows should be redirected to healthy paths as fast as possible. A path protection mechanism prepares backup paths in case of failure and provides fast failure recovery as it provides a backup path in advance. However, if backup paths are not set, an SDN controller redirects all the affected flows sequentially, which is called restoration. In this section, we illustrate how source routing can be applied to protection and restoration for fast failure recovery in SDN. 4.1. Path Protection In order to recover from failures fast, path protection can be implemented in SDN using the source routing mechanism. An SDN controller inserts backup path information, as well as a working path. If a failure occurs in the working path, then the affected flows is redirected to the backup path. For example, in Figure 1, when a flow path from A to F is set, the SDN controller extracts a flow of the packet. Then, it calculates the working path (B, E, D, F) and the backup path (B, G, D, F). The working path (B, E, D, F) is established using the existing flow setup mechanism or our method shown in section 3. The SDN controller extracts output port numbers of nodes along the path. The backup path (B, G, D, F) is encoded to (2, 3) which includes output port numbers of node G and D and inserted to the flow entry of B. During the network is healthy, packets from A to F are delivered through (B, E, D, F). Assume that the link B-E fails, B detects that the port 3 is unavailable and redirects the packet to the port 4 after inserts the encoded path to the packet header. G receives the packet and obtains the output port 2 for the packet by inspecting the packet header. G adds a flow entry which instructs G to forward matched flows to the port 2. After G obtains the output port, it removes its output port number in the encoded path (2, 3), so G puts (2) to the packet header and forwards the packet to port 2. D receives the packet, obtains the output port 3, and sends the packet to the port 3. Kim, et al. Expires January 4, 2015 [Page 5] Internet-Draft SPRING Use Cases July 2014 4.2. Restoration Unlike the path protection, a restoration mechanism does not prepare for failure cases in advance. No additional actions are required during flow setup. If failures occur, SDN nodes detect failures and notify them to a SDN controller. The SDN controller first identifies flows affected by the failures with the failure notification. Then, the controller redirects the affected flows to alternative paths. For example, in Figure 1, let us assume that link B-E fails, then B and D detect the port 3 and 1 are unavailable, respectively. B and D send notification messages to the SDN Controller, then it extracts flows from flow tables of B and D, which are directly affected by the failure. The SDN controller then calculates alternative paths for the affected flows and sets alternative paths for the flows. When the SDN controller redirects each affected flow, source routing is used to recover failures fast. Redirection process of each affected flow is same as the flow setup shown in section 3. If 10 flows are affected by the failure, then the SDN controller should redirect these flows sequentially. 5. Content Distribution The delivery of content in current operator's networks is commonly implemented by means of a Content Distribution Network (CDN). The CDN consists of a number of nodes playing different roles in the overlay distribution. There are some nodes, named ingest nodes, which are placed at the root of the CDN where the content is pushed. There are some other intermediate nodes, known as delivery nodes, at regional level that can be used for traffic delivery to end users requesting the content in the region, or even for traffic forwarding to nodes deeper on the CDN or end points in other regions to serve some remote users. All these nodes maintain a cache where the content is temporary stored in order to serve subsequent request from end users. Typically, the end user request arrive to a central control point in the CDN infrastructure which decides which end point will be in charge of serving the content, considering factors like end point load, content availability, etc. Then, the end user request is redirected to the end point of choice, and the traffic delivery starts. In an SDN enabled environment, the SDN controller can be in charge of instructing the most appropriate delivery node to forward traffic to the end user location by applying the segment routing logic. This could be performed in a simplistic way, just identifying the segment where the end user is located, or in a more sophisticated way, by Kim, et al. Expires January 4, 2015 [Page 6] Internet-Draft SPRING Use Cases July 2014 avoiding for instance some network segments of high load or by implementing more complicated traffic engineering. Looking at the topology in Figure 1, let us consider a delivery point deployed in A and an end user requesting some content placed in F. Let us consider also that the link E-D has a high load in this moment. Once the CDN control part resolves that the end point to deliver the traffic to the end user is the one located in A, the SDN controller can instruct the delivery node for sending the traffic to the D-F segment while avoiding the segment in E-D. Note that in this case some communication between the control entities in the CDN and the SDN is required for collaborating in the segment routing definition. 6. Dual Homing Typical enterprise services are built as overlay networks (in the form of VPNs). In order to offer redundancy to the connectivity of these enterprises, dual homing is implemented by connecting the router located in customer premises to two separate nodes in the operator's network. The decision for delivering traffic on top of one link or the other towards the other sites connected to the VPN or to Internet depends on some pre-defined policies, as load balancing, BGP parameterization tuning, etc. In an SDN controlled scenario, the SDN controller can take the decisions of the traffic delivery and instruct the router in the customer premises to condition the traffic according to the defined segment routing injected from the controller. The policies are not more configured in the router, but in the controller. The router in the customer premises is not more required to keep any per flow state. 7. Security Considerations One of the most important security issues of source routing in SDN is that malicious users may change paths. To prevent this, switches in a network domain should ignore encoded path information. By deleting encoded path information in packets from ports connected to external networks, we can prevent malicious users from altering paths. Kim, et al. Expires January 4, 2015 [Page 7] Internet-Draft SPRING Use Cases July 2014 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Sungsu Kim KT Infra R&D Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6688 Fax: +82-2-526-5200 Email: sngsu.kim@kt.com Jaewoo Park KT Infra R&D Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6688 Fax: +82-2-526-5200 Email: jawoo.park@kt.com EunKyoung Paik KT Infra R&D Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5200 Email: eun.paik@kt.com URI: http://mmlab.snu.ac.kr/~eun/ Kim, et al. Expires January 4, 2015 [Page 8] Internet-Draft SPRING Use Cases July 2014 Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain Email: lmcm@tid.es URI: http://people.tid.es/LuisM.Contreras/ Kim, et al. Expires January 4, 2015 [Page 9]