Internet DRAFT - draft-kim-spring-use-cases
draft-kim-spring-use-cases
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]
