Software-defined Networking Efforts Debuted at IETF 84

Demonstrations at the Bits-N-Bites session of the IETF 84 meeting in Vancouver, Canada, featured the framework of a software-defined networking (SDN) solution suitable for the telco environment, as well as new proposals such as an SDN northbound interface for the coexistence of SDN with application-layer traffic optimization (ALTO) and the application of ALTO in an east-west interface interconnecting SDN controllers.

SDN is a hot topic these days, as illustrated by Monday’s plenary discussion and the incredibly crowded SDNRG BoF at the IETF 84 meeting. SDN allows separation of the control plane and the data plane in network equipment, whereby the control plane is implemented in software in a logically centralized manner, and the data plane is implemented in commodity network equipment. OpenFlow is a leading enabler of SDN architectures.

As a slightly more mature topic, ALTO has an established IETF Working Group of its own. ALTO provides applications with information to, for example, perform better-than-random initial peer selection, and its services may take different approaches, including maximum bandwidth, minimum cross-domain traffic, and lowest cost to users. The ALTO information and services could help network applications to optimize application-layer traffic and to improve the performance of both the network and applications.

The demonstrations were based on two Internet Drafts:

The SDN+ALTO draft1 (draft-xie-alto-sdn-use-cases) describes architectures for the coexistence of SDN and ALTO.

The SDNi draft2 (draft-yin-sdn-sdni) proposes SDN interconnectivity and message exchange among multiple SDN controller instances within the scope of a single administrative domain.

The SDN+ALTO draft focuses mainly on interacting with an ALTO server to provide SDN-specific network state information and to provision the network in a more efficient and optimal manner. However, network provisioning through SDN+ALTO only may be difficult due to challenges such as granularity, scalability, and real-time issues. These difficulties could be addressed via the approach proposed in the SDNi draft.

SDN Domains: Partitioning the Control Plane

Both drafts emphasize the new concept of SDN domains, which was introduced to support the need for partitioning a network control plane among different controllers within an administrative domain. An SDN domain can be defined as the portion of the network (a “subnetwork,” although not necessarily in the traditional IP-oriented sense) being managed by a particular SDN controller. Figure 1 shows an example of this concept. Among the reasons for introducing the concept of SDN domains we can emphasize:

1. Scalability. Because the number of devices an SDN controller can feasibly manage is likely to be limited, a reasonably large network may need to deploy multiple SDN controllers.
2. Privacy. A carrier may choose to implement different privacy policies in different SDN domains because, for instance, an SDN domain may be dedicated to a set of customers who implement their own highly customized privacy policies requiring that some networking information in this domain (e.g., network topology) should not be disclosed to an external entity.
3. Incremental deployment. A carrier’s network may consist of portions of legacy and nonlegacy infrastructure. Dividing the network into multiple, individually manageable SDN domains allows for flexible incremental deployment and a more-seamless network evolution.

There are many other reasons for partitioning a network using the concept of SDN domains. For instance, if an SDN controller is used to manage a certain portion of the network, losing connectivity between the controller and the network could result in outages (or reduced service); this mandates locality between the controller and the network under its control in order to minimize the risk of network problems causing more network problems. Additionally, large amounts of mergers among companies introduce the need to interconnect data centers, and in many cases a certain customer will deploy its services on multiple data centers from multiple providers. In these cases, the data centers will be SDN managed in the near future, thereby requiring SDN interconnection

Figure 1. Example of SDN Domains

In the demonstrations, a simple network topology was used to illustrate these key ideas. The topology consisted of three infrastructure nodes and two SDN domains, as shown in figure 2. All three nodes supported OpenFlow 1.0 and were SDN-capable. Node-1 and Node-2 were 1 Gbps switches based on the BCM5662 chipset, and Node-3 was a Huawei NE40E-X3 router. The two SDN domains are labeled SDN-1 and SDN-2. Domain SDN-1 consisted of only Node-1; domain SDN-2 consisted of Node-2 and Node-3. Each of these two SDN domains had its own SDN controller managing the corresponding nodes. An ALTO client was integrated with each of these two SDN controllers, and to simplify the demonstration configurations, an ALTO server was collocated with Node-2, and a VLC video server was collocated with controller SDN-1. The demonstration showed three video streams corresponding to three network flows, from the video server to three clients connected to Node-2.

Figure 2. Demonstration Setup

SDN+ALTO: A Northbound Interface for the Coexistence of SDN and ALTO

In a network where SDN and ALTO both operate, a northbound interface is needed to support their coexistence. In draft-xie-alto-sdn-use-cases, the authors propose that SDN controllers become a special type of ALTO client in the following ways:

1. SDN controllers feed the ALTO server with SDN-domain-specific and possibly aggregated network information, policed by the specific privacy policies that are enforced by the corresponding SDN domains. The draft does not specify what specific protocol the SDN controllers should use to export information. Some protocol drafts (e.g., BGP-LS3) could be applicable for this purpose, however, the privacy policy, which governs how network information should be aggregated before exporting to the ALTO server, could be difficult to integrate with BGP-LS unless the latter is significantly improved by explicitly allowing the implementation and execution of foreign privacy policies.

2. SDN controllers obtain key SDN-domain-specific information from the ALTO servers in order to manage the whole network. Key information obtained from ALTO must be customized specifically for SDN and SDN domains, since the SDN controllers cannot use the vanilla non-SDN-domain-specific ALTO information directly. For example, an SDN controller needs a network cost map or end-point ranking that is specific to the controller’s SDN domain. More important, the SDN controller may require key information, such as a set of SDN-domain-level paths, in order to correctly and fully utilize the cost map or end-point ranking. In non-SDN environments, ALTO clients likely do not have the ability to choose routes, therefore cost maps need not come with any path information. However, in SDN-enabled networks, SDN controllers are special infrastructural ALTO clients that are able to—and should—choose routes. In this scenario, cost map (or end-point ranking) by itself without any path information is not very useful.

In the demonstration for SDN+ALTO coexistence (see figure 3), three flows—gold, silver, and bronze video streams—were injected into the net-work one by one. Controller SDN-1 obtained cost maps or ranking information from the ALTO server and decided which path should be set up for each flow. According to the information returned by ALTO, the upper path (Node-1 to Node-3 to Node-2) was set up for the gold flow, while the lower path (Node-1 to Node-2) was chosen for the silver flow and the bronze flow. There are many possible reasons for this flow assignment, including engineering the traffic to minimize the maximum number of link utilizations (putting the silver and bronze flows together minimizes the maximum of aggregated flow rates on the two paths); or the existence of transient flows consuming a significant portion of the capacity on the upper path when assigning the gold flow (necessitating that the silver flow be assigned on the alternative path, however, the transient flow may disappear after the assignment).

Figure 3. SDN+ALTO Demonstration

In the demonstration, assigning the silver and bronze flows to the lower path caused congestion on Node-2. The congestion may have been a result of background traffic on the link between Node-1 and Node-2. Such background traffic may have existed before or after setting up paths for the two flows. In both cases, controller SDN-1 as a client of ALTO was not able to receive the most up-to-date information from the ALTO server, because ALTO only provides coarse-grain, nonreal-time cost maps or ranking services. As a result, the video quality of both the silver and bronze streams was severely degraded.

This demonstration suggests that with ALTO alone as the source of network information for SDN, network performance may suffer—the coarse granularity of ALTO is not sufficient for SDN to operate on the fine granularity of network flows. Clearly, we need other mechanisms (e.g., SDNi) to solve such problems.

SDNi: An East-West Control Plane Interface for SDN Controllers

Multiple SDN controllers are likely to be deployed in a reasonably large network administrative domain; interconnecting these controllers in order to share information and coordinate their decisions becomes inevitable—and a key factor for success. In draft-yin-sdn-sdni, the authors propose a protocol framework called SDNi to interconnect SDN controllers. This draft describes the inter-faces for exchanging information among multiple SDN domain controllers and the benefits of coordinating network provisioning using SDNi.

The SDNi demonstration shown in figure 4 illustrates this framework. Besides interconnecting multiple controllers, SDNi also allows them to share control-plane network information and coordinate their decision-making processes.

Figure 4. SDNi Demonstration

In this case, when congestion happens, Node-2 detects and reports the congestion information to its controller, which again shares this information with controller SDN-1. On receiving the congestion report through SDNi, controller SDN-1 can then recover from the congestion by rerouting the flows. More specifically, the silver flow is shifted from the lower path to the upper path. After this shift, the video quality of both silver and bronze flows is significantly improved.

Feedback and Conclusions

The new proposals for SDN evolution described in the two drafts mentioned previously were demonstrated during the Bits-N-Bites session in what we believe is the purest IETF style: running code. Demonstrating via the archetypal video streaming service, the Telco SDN framework, as well as the innovations on the northbound and east-west interfaces in the SDN architecture, provided a win-win solution for network carriers and Internet content providers. In particular, SDN+ALTO achieved goals such as flexibility, privacy preservation, and independent evolution; SDNi provided an approach to partitioning a network administrative domain and to interconnecting islands of SDN domains to form a coherent network.

The commitment and effort it took to put on the demonstrations were acknowledged and appreciated by many IETF participants. Russ Housley, IETF chair, said to Tina Tsou “I saw people at your table all evening. Thank you very much for your contribution to the IETF.” IETF Participants from network carriers such as KDDI commented that it was great to see an initial effort of SDN solution done in IETF while most of the people were still talking about SDN in slides, and that they’d like to see more developments in this area. Said Raquel Morera from Verizon, “we’re interested in SDN and in following developments in the area.”

The contributors to the demonstrated draft and the demonstration itself included (alphabetical within each institution):

Telefonica: Pedro Andres Aranda, Diego Lopez

Huawei Technologies: Weiqian Dai, Ritesh Mukherjee, Tina Tsou, Haiyong Xie, Ken Yi, Hongtao Yin

Contextreme: Ron Sidi

Alcatel-Lucent: Vijay Gurbani

References

1.         H. Xie, T. Tsou, D. Lopez, H. Yin, and V. Gurbani. Use cases for alto with software defined networks. (IETF Internet-Draft), draft-xie-alto-sdn-extension-use-cases-00, 2012.

2.         H. Yin, H. Xie, T. Tsou, D. Lopez, P. A. Aranda, and R. Sidi. SDNi: A message exchange protocol for software defined networks (SDNs) across multiple domains. (IRTF Internet-Draft), draft-yin-sdn-sdni-00, 2012.

3.         H. Gredler, J. Medved, S. Previdi, and A. Farrel. North-bound distribution of link-state and TE information using bgp. (IETF Internet-Draft), draft-gredler-idr-ls-distribution-02, 2012.