Software-Defined Networking

The topic of Software Defined Networking (SDN) has attracted a great deal of attention from service providers, enterprises, and industry associations. A true picture of SDN has yet to emerge, however, despite today’s enthusiastic expectations.

The basic concept of SDN spread following the emergence of OpenFlow, which is now one of the effective enablers, or candidate solutions, of SDN under industry consideration. One of SDN’s defining characteristics is that it centrally places the intelligence of a network system (e.g., the intelligence is logically centralized by a so-called SDN controller). While this increases the flexibility of network utilization, it also keeps its complexity hidden from operators—which is why SDN is easy to operate and maintain. SDN also introduces the abstraction of lower network infrastructure functionality, which is well suited for the efficient development of new applications, and thereby promotes SDN as helpful in bringing innovative services to the market in a more timely manner. SDN can realize all of this in a cost-effective manner (capital expenditure/operating expenditure).

From a technical point of view, some argue that an essential aspect of SDN is the separation of a network device’s control-plane from its data-plane. If one looks at the architecture of OpenFlow, this is a fairly distinct and easily comprehensible feature. However, when one considers the general goals of SDN—to simplify network operations, to deploy innovative services with increased velocity, and to lower costs—other aspects may arise. While these general goals are commonly recognized, but there also exist a variety of other proposals and technical points of focus regarding SDN, such as investigating how to support coexistence with existing devices. For this reason, it is of utmost importance that a wide survey is conducted to establish a common idea of SDN’s architectural direction.

This article presents an outline of the IETF’s current SDN work, and provides examples of related use cases.

IETF Activity with SDN

The IETF is investigating models of SDN for feasible technical approaches. At IETF 86 in Orlando, Florida, an SDNRG (IRTF SDN Research Group) session included several presentations devoted to different candidate solutions. The session covered the analysis of OpenFlow, as well as a wide variety of other related topics—including network function virtualization¹ (NFV), which involves leveraging the virtualization technology of network equipment.

There was also an introductory presentation of forwarding and control element separation² (ForCES), a conceptually similar protocol to OpenFlow. It is hoped that this comprehensive study will enable SDNRG to provide input on the design of protocol, network, and service, and will accelerate detailed discussion.

Simultaneous to SDNRG’s study, other IETF Working Groups have started their own efforts in SDN:

• In SDN, intelligent programmability to the network is expected. But until now there have been no standard interfaces between the SDN controller and IP routers. The Interface to Routing System³(I2RS) WG was formed to meet requirements, such as the dynamic manipulation of state routing information, and held its first face-to-face meeting at IETF 86.
• SDN’s logically centralized management model requires existing technologies to take into account additional enhancement. For example, in IP/MPLS, there already exists a standard technology, path computation element⁴ (PCE), that can find optimal label switched paths (LSPs). But because the original PCE specification was not sufficient (the LSP state could not be monitored or changed by the controller side), a new extension, stateful-PCE, is being proposed to overcome it.
• The separation of control-plane and data-plane is effective for the seamless operation of a computing and network infrastructure. The Network Virtualization Overlays⁵ (NVO3) WG is active in discussing Data Center Virtual Private Networks—VPNs across a number of virtual machines (VMs). Collaborating with L2VPN and L3VPN WGs, NVO3 is proposing an architecture in which control-planes (e.g., BGP, XMPP) are decoupled from data-planes (e.g., MPLS, NVGRE, VXLAN). This architecture is expected to support a high level of scalability in the multitenant datacenter network. (According to the WG’s charter, there are a few thousand to several million VMs running on greater than 100,000 physical servers.)
• SDN gives a centralized view of network topology. In this context, application-layer traffic optimization⁶ (ALTO) can be placed at the controller side, which collects abstracted topology data and publishes service endpoints. PCE might have similar applicability. A new protocol extension of BGP, BGP link state⁷ (BGP-LS) is seen as a new interface for network devices to advertise their link-state and traffic-engineering information to the controller side.

In addition to standardization activity, new service scenarios and use cases are being studied, mostly driven by the industry’s high expectations of SDN. Following are some examples.

Automated Interconnection between Cloud and WAN VPN

SDN, especially OpenFlow, has already been used in a carrier’s production network to provide virtualized networking for cloud service (e.g., global carrier NTT Communications is providing Enterprise Cloud computing clients using OpenFlow). In this case, the Layer-2 network such as VLAN, is dynamically controlled by the SDN controller. The virtualized network is also extended to interdatacenter connection services for data migration without IP renumbering, and for bandwidth provisioning/deprovisioning on demand.

A potential use case of SDN as an expansion for WAN-area beyond the cloud datacenter would be the interconnection between the BGP/MPLS IP-VPN (RFC4364⁸) network and the virtualized network in the datacenter. SDN can set up this interconnection automatically. The benefits for customers include use of Infrastructure-as-a-Service (IaaS) resources via IP-VPN on demand; and for carriers to provide such a connection without any manual operation of the configuration.

Currently, a typical connection mechanism between a datacenter network and an IP-VPN network may be Inter-AS Option-A of RFC4364. In this case, virtual routing and forwardings (VRFs) are configured at both border routers and VLANs are used for the tenant separation in the data-plane in the connection. One example of SDN usage in the connection is to use Inter-AS Option-B of RFC4364, in which case Mp-BGP peer is established between the SDN controller in the datacenter and the border router of the IP-VPN network. The VPN route information with MPLS labels and route targets is exchanged via the BGP peer. In the case that VLAN is used as the virtualized network in the datacenter, the MPLS label and VLAN-ID are converted in the data-plane associated with the IP-Prefix that an arriving packet has, and OpenFlow protocol is used to push the flow information at the gateway switch. OpenFlow protocol 1.3.X⁹ is the latest Open Flow version and supports such flow information in matching and action instruction. For example, when a packet arrives from a datacenter at the gateway switch, it does match VLAN-ID and IP-Prefix and can push the MPLS label associated with the combination based on the VPN route information obtained from the BGP peer. When a packet arrives from the border router at the gateway switch toward a datacenter, it matches the MPLS label and pushes the VLAN-ID associated with the MPLS label (see figure 1). In this type of SDN architecture, every implementation is covered by standardized protocols only—making it very flexible and vendor neutral.

            Figure 1. Use Case of an Automated Cloud and WAN VPN Interconnection

Dynamic Resource Sharing in the Network

Until recently, the IP/MPLS network settings of tunnel LSPs to carry user’s traffic were statically and manually configured at routers. As a result, it was technically difficult to deal with a scenario in which source-destination pairs of LSPs frequently changed. SDN’s logically centralized approach has the capability to solve this kind of technical challenge.

In this use case, RSVP-TE LSPs are dynamically created and deleted on the specified time, bandwidth, and source/destinations by the operator. The SDN controller monitors the traffic amount and utilization of the network infrastructure in real-time, and then controls MPLS edge routers so that RSVP-TE is signaled accurately at the specified timing. The benefit of this scheme is that multiple users can share the same physical network resources on a time-specific basis. From the end user’s view, bandwidth-assured leased lines may be reserved during a particular time period or immediately provided on-demand. Because network resources are allocated only when they are needed, both users and operators can utilize networks more efficiently, thereby contributing to a reduction in capital expenditure.

Technically, this use case needs to manage a network node’s time-triggered and/or ephemeral state (unlike initial configuration, a state that is not persistent and can be changed frequently) regarding LSP control. Solutions should support intelligent and customizable programmability on the controller side to quickly facilitate the creation of differentiated services (see figure 2).

Figure 2. Use Case of Dynamic Resource Sharing

Future Expectations

SDN, by its nature, is oriented toward joining different pieces of technology via the orchestration mechanism of a logically centralized controller. In fact, a unique SDN protocol, does not exist—users must combine various technologies. Therefore, in consideration of the technical solutions of SDN, it will be increasingly important to study the end-user’s benefit from a systemwide perspective to ensure the final configuration supports the user’s objectives. A similar focus will be required with regard to potential standardization activities by the IETF.

References

1. Network Functions Virtualisation: An Introduction, Benefits, Enablers, Challenges & Call for Action ,
http://portal.etsi.org/NFV/NFV_White_Paper.pdf

2. Forwarding and Control Element Separation (forces),
http://datatracker.ietf.org/wg/forces/charter/

3. Interface to the Routing System (i2rs),
http://datatracker.ietf.org/wg/i2rs/charter/

4. Path Computation Element (pce),
http://datatracker.ietf.org/wg/pce/charter/

5. Network Virtualization Overlays (nvo3),
http://datatracker.ietf.org/wg/nvo3/charter/

6. Application-Layer Traffic Optimization (alto),
http://datatracker.ietf.org/wg/alto/charter/

7. North-Bound Distribution of Link-State and TE Information using BGP,
http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-03

8. BGP/MPLS IP Virtual Private Networks (VPNs),
http://tools.ietf.org/html/rfc4364

9. Open Network Foundation, OpenFlow Switch Specification,

https://www.opennetworking.org/sdn-resources/onf-specifications/openflow