+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++
     |      Network Coding Controller (e.g., a module in SDN Controller)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++
                     |     |     |     |     |  
                     |     |     |     |     | 
                     |     |     |     |     |
                     |     |     |     |     |
     +-+-+-+-+-+-+-+-+-+   |     |     |     |
     |    IP-MPLS      |   |     |     |     | 
     +-+-+-+-+-+-+-+-+-+   |     |     |     |
                           |     |     |     |
          +-+-+-+-+-+-+-+-+-+    |     |     |
          |      MPLS-TP    |    |     |     |
          +-+-+-+-+-+-+-+-+-+    |     |     |
                                 |     |     |
               +-+-+-+-+-+-+-+-+-+-+   |     |
               |      OTN          |   |     |
               +-+-+-+-+-+-+-+-+-+-+   |     |
                                       |     |
                    +-+-+-+-+-+-+-+-+-+-+    |
                    |  DWDM, ROADM      |    |
                    +-+-+-+-+-+-+-+-+-+-+    |
                                             | 
                             +-+-+-+-+-+-+-+-+-+
                             |      Other      |
                             +-+-+-+-+-+-+-+-+-+

 

Figure 2

The network coding can be applied on the originating node and/or in intermediate forwarding nodes at the Layer 3 as shown in Figure 2. The NCC can orchestrate the network coding entity running at the network layer to code packets with desired granularity. The granularity can be, for example, all the IP and MPLS packets must be coded. A more granular example, all the MPLS packets matching a certain MPLS label should be coded or a five-tuple in the IP must be matched to determine if the packet is to be coded or not.

2.4. Separation of Control for Forwarding

In this section we discuss how the separation of control for forwarding impacts the network coding and its implementation in the emerging software-defined networks or SDNs.

3. Virtualization and its use in Network Coding

In this section, we discuss general virtualization of applications/services, and computing/networking resources. We then explore the impact of virtualization on emerging networking coding (architecture, control, and services).

3.1. Virtualization of Application/Service Resources

Virtualization of Application/Service resources is becoming increasingly popular with the proliferation of the APP based services in the mobile and Tablet world.

3.2. Virtualization of Computing Resources

Virtualization of computing resources has been widely used in Cloud Computing [I-D.khasnabish-cloud-reference-framework] environment.

3.3. Virtualization of Network-Level Resources

In this section we discuss virtualization of network resources. The network resources typically include routers, switches, and topology and routing databases, policy and security controllers, etc.

3.4. Virtualization for Network Coding

In this section we discuss virtualization for network coding, its benefits and implementation and management hurdles.

3.5. Network Coding Controller and APIs

In this section we discuss the features/functions of the Network Coding Controller (NCC), and possible NCC APIs. Although North- and South-bound APIs are the most important ones, East, West, etc. bound APIs may be also very useful.

4. Network Coding Control and SDN

In this section we discuss a high-level architecture for network/service function virtualization and Software-Defined Networking.

4.1. Apps and Service Layer

In this section we discuss the elements and capabilities of the Application and Service layer.

4.2. Control Layer

In this section we discuss the features/functions and the capabilities of the Control layer.

4.3. Virtualization Layer

In this section we discuss the details of the virtualization layer.

4.4. Physical Resources Layer

In this section we discuss the elements of the physical layer.

4.5. Management and Orchestration

In this section we discuss efficient management and Orchestration in virtualized multi-technology and multi-admin-domain environments.

4.6. APIs: For Example Transport APIs

For the emerging Network Coding, defining an appropriate API for dynamically selecting application/service based Transport may be the most suitable option. For example, SCTP [RFC4960] may be more suitable than TCP/Multi-Path-TCP [RFC6824] or UDP [RFC0768] or any other variants for some applications/services.

The added flexibility (due to using an open Transport API) will allow guided navigation of sessions/flows through a variety of network operations systems and physical/virtual infrastructure network/service elements. This will help achieve unified and seamless user experience irrespective of what the underlying network infrastructure is. Further discussion in this area can be found in [I-D.montpetit-transport-strawman].

4.7. Generic Lifecycle Management

In this section we discuss the generic lifecycle management of virtual entities.

5. Practical Considerations with NC and SDN

In this section, we describe some discussions related to the practical integration of network coding with emerging software-defined networks architectures. We start by observing that, on one hand, thanks to network virtualization, network coding might be done transparently with SDN, which offers the advantage of not having to modify the higher level applications, existing protocols such as TCP/IP, or the network stack inside guest VMs. On the other hand, this leaves open the question of which entities in the network will actually do the coding/decoding; in addition, not all of the currently advocated uses of NC are necessarily mapped to cases where SDN is used. Thus some of the major questions are:

• In which scenarios (use cases) could NC be used with SDN?
• How to integrate NC with SDN technologies in practice?

5.1. Some Use Cases for NC in SDN

We present some possible scenarios where NC could bring benefits to SDN. Since SDN might be more related to datacenters or RAN virtualization, they could be slightly different to often described NC use cases. For instance, end-to-end (user) Internet video streaming is a typical application for network coding, but at least on the "last link" to the user, it would not not typically use SDN.

A first concrete scenario of how NC can be conceptually integrated with SDN and virtualization, is the example of IETF NVO3 (Network Virtualization over Layer 3) architecture [RFC7365] (see "Generic Reference Model"). One plausible scenario is a tenant with multiple data centers interconnected through WAN, and with networking applications in virtual machines. In the NVO3 architecture, it is possible to create an overlay over the physical WAN network and then set this overlay as the virtual network for the VMs of the data centers. Network virtualization edges (NVE) are pivotal elements in NVO3; they implement L3 (or L2) virtualization functions. When a NVE receives traffic from a VM (tenant system), it identifies the remote NVE that corresponds to the destination and then the associated overlay, it adds an NVO3 overlay encapsulation header, and it sends the resulting packet on the physical network as native IP packet (encapsulating it). Upon receival by remote NVE, the packet is decapsulated and delivered to the proper destination VM.

In this scenario, the virtualized network relies on actual physical WAN links, and one might imagine several benefits from the use network coding in this context, among the traditional benefits:

• reliability: by splitting the flows on several routes, it is possible to provide diversity for the paths, so that in case of failure of some link, other paths would still be available. The benefits of network coding would includes those of traditional erasure coding; the redundancy could be different than 1+1 (that is: one path+one backup path), typically less costly. This is useful mostly for real-time/low latency communication requirements, in cases where the global convergence time for the network to recover from link failure (and re-route) is considered too high.
• performance: in the case of multicast traffic, a first step is of course to have optimized multicast routing on the overlay; a second step would be to optimize the WAN links utilization, which could be done by network coding, as examplified by the classic network coding "butterfly" example. Such scenarios are more likely when information is replicated in more two geographically distinct sites.

A second concrete example would be related to the traditional benefits of network coding for wireless communications. There have been a few proposals for the use of wireless links inside the data centers (on relatively short distances, and with well-defined beams), for instance in [Z2012]. The idea is that (at least in part) gigabit wireless links in the 60 GHz range could be used to interconnect racks of the data center, for instance, top-of-the rack. Because wireless links behave in a more complex way than wired Ethernet/fiber, complexity would be reflected in their management.

In this scenario, benefits of network coding would include:

• packet loss recovery: it is natural to use all physical layer and MAC techniques (directional antennas, beamforming, MIMO, error coding ...), but then also natural to use network coding, especially considering multiple hops inside the data center.
• cross-domain coding: through SDN, there is potential for combining NC in the network itself, with NC in the storage for instance.
• central network optimization: as in SDN, the network coding controller will have the entire knowledge of the virtualized and physical network topology, (including all type of interfaces, wired/wireless), and could better optimize network use.

It is a very similar architecture to the more general efforts proposed to virtualize Radio Access Networks (e.g. LTE and beyond), although more within the scope of IRTF/IETF. When inter-cell interference is considered in RAN architectures, the outcome would be related to the centralized management of network coding in that scenario (network coding controller), hence would be an inspiration.

Finally, in generic scenarios where multiple path routing is possible (e.g. some context as multi-path TCP/NVO3), an open question is whether the "reliability" case could be extended as follows:

• latency: as noted before, it is possible to improve reliability with respect to node or link failure with (network coding), at a permanent cost of bandwidth (redundancy), by sending coded packets on multiple paths. Going further, if one application has stringent jitter constraints, one could envision considering late packets as "lost", and still recover packets on time, through network coding/decoding.

A question is whether this trade of bandwidth for some gains in latency is worthwhile for current SDN applications.

5.2. Integrating NC with SDN technologies

Independently of the scenarios and the benefits of NC for SDN, a practical question is which network entity would actually be responsible for performing the (network) coding/decoding. The general issue is that current SDN switches cannot perform network coding at low level, whereas performing it in the controller, could be inefficient.

A first example is taken from a demo at SIGCOMM 2012 by Németh et al. [N2012]. Noting that the limited abilities of (OpenFlow) network forwarding devices render difficult the implementation of unconventional techniques, they extend OpenFlow to include new actions in the forwarding engine: precisely, they "extended the OF protocol with three simple actions to support XOR-based mixing of two flows." The global result is not L3 routing, nor L2 switching, but actual network coding done in extended-OpenFlow (non standard). Then a SDN centralized control plane features an explicit "NOX NC controller". Prior work on network coding (without SDN) discussed how to reap bandwidth benefits from creating "butterflies" in the network. For the demo, the NC controller indeed created a butterfly through programming of the (network) coding of video flows from two multicast video streams.

In [L2014], one can find NCoS, a more detailed description of a similar approach, with:

• A centralized controller has knowledge of the topology and of the flots: it constructs multipath multicast trees (subgraphs), and computes encoding matrix, and then NC flow entries for each switch
• An extension of OpenFlow with specific buffers (to hold coded packets, managed by the controller), and specific actions: coding initialization, coding, and decoding
• An implementation done in the simulator Mininet, by extending OpenvSwitch 1.9.0

The second example is related to the previously presented scenario in NVO3 context. In NVO3, the network virtualization edges (NVE) are performing encapsulation/decapsulation of packets. Ignoring interoperability, performance and implementation issues, these edges would be ideally located entities for performing coding, re-coding, and decoding. Because they are well identified, one could imagining chaining the operation of network coding prior or posterior to encapsulation. Compositional SDN architectures would render the integration of network coding more natural. In the same spirit, and more generally, in NFV (Network Functions Virtualization) architectures, a specific network coding "function" could be envisioned, yielding a more natural implementation next to the (purely) forwarding devices.

The third example is related to implementation of network coded and SDN-controlled massive (virtualized) MIMO for providing highly reliable high-capacity access bandwdth for 5G services, as being discussed in [Z2014, Z2015]. ZTE and KT signed strategic Partnership on 5G in order to explore these further (http://www.reuters.com/article/2015/07/16/zte-corporation-idUSnBw156714a+100+BSW20150716). In addition, ZTE is also contributing to 5G projects in Europe including Horizon 2020 in these areas (http://www.businesswire.com/news/home/20150320005199/en/ZTE-Invited-EU-Commissioner-Contribute-Technology-Expertise, http://www.euractiv.com/sections/infosociety/china-eu-5g-and-internet-future-318016).

6. Testbed Platform

Texts and diagram(s) related to Testbeds will be added in this section.

7. Reference Implementation

Texts and diagram(s) related to Reference implementation(s) will be added in this section.

8. Security Considerations

Although the use virtualization and separation of control and transport (and forwarding) open up the possibility of supporting greater flexibility and scalability, these also make the network resources more vulnerable to abuse and spoofing. For example, the security considerations for virtualized resources in DC environment can be found in [I-D.karavettil-vdcs-security-framework].

9. IANA Considerations

This document introduces no additional considerations for IANA.

10. Acknowledgments

The author(s) would like to thank Victor, Brian, Marie-Jose, and many others for their discussions and support.

11. References

11.1. Normative References

[I-D.irtf-sdnrg-layer-terminology]	Haleplidis, E., Pentikousis, K., Denazis, S., Salim, J., Meyer, D. and O. Koufopavlou, "SDN Layers and Architecture Terminology", Internet-Draft draft-irtf-sdnrg-layer-terminology-01, September 2014.
[I-D.junsheng-opsawg-virtual-resource-management]	Chu, J., Khasnabish, B., Qing, Y. and Y. Meng, "Virtual Resource Management in Cloud", Internet-Draft draft-junsheng-opsawg-virtual-resource-management-00, July 2011.
[I-D.karavettil-vdcs-security-framework]	Karavettil, S., Khasnabish, B., Ning, S. and W. Dong, "Security Framework for Virtualized Data Center Services", Internet-Draft draft-karavettil-vdcs-security-framework-05, December 2012.
[I-D.khasnabish-cloud-reference-framework]	Khasnabish, B., Chu, J., Ma, S., Ning, S., Unbehagen, P., Morrow, M., Hasan, M., Demchenko, Y. and M. Yu, "Cloud Reference Framework", Internet-Draft draft-khasnabish-cloud-reference-framework-06, January 2014.
[I-D.khs-forces-lfb-subsidiary-management]	Khasnabish, B., Haleplidis, E. and J. Salim, "IETF ForCES Logical Function Block (LFB) Subsidiary Management", Internet-Draft draft-khs-forces-lfb-subsidiary-management-01, July 2014.
[I-D.montpetit-transport-strawman]	Montpetit, M., Zhovnirovsky, I. and B. Reuther, "Transport Services Strawman Architecture", Internet-Draft draft-montpetit-transport-strawman-01, February 2014.
[RFC0768]	Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4960]	Stewart, R., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007.
[RFC6824]	Ford, A., Raiciu, C., Handley, M. and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013.

11.2. Informative References

[L2014]	Sicheng Liu, Bei Hua, , "NCoS: A framework for realizing network coding over software-defined network", IEEE 39th Conference on Local Computer Networks (LCN) 2014, Sep 2014.
[N2012]	Felicián Németh, Ádám Stipkovits, Balázs Sonkoly, András Gulyás, , "Towards SmartFlow: Case Studies on Enhanced Programmable Forwarding in OpenFlow Switches", SIGCOMM Demo 2012, Aug 2012.
[RFC3654]	Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, DOI 10.17487/RFC3654, November 2003.
[RFC3746]	Yang, L., Dantu, R., Anderson, T. and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004.
[RFC7365]	Lasserre, M., Balus, F., Morin, T., Bitar, N. and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014.
[RFC7642]	LI, K., Hunt, P., Khasnabish, B., Nadalin, A. and Z. Zeltsan, "System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements", RFC 7642, DOI 10.17487/RFC7642, September 2015.
[Z2012]	Xia Zhou, Zengbin Zhang, Yibo Zhu, Yubo Li, Saipriya Kumar, Amin Vahdat, Ben Y. Zhao and Haitao Zheng, , "Mirror Mirror on the Ceiling: Flexible Wireless Links for Data Centers", SIGCOMM 2012, Aug 2012.
[Z2014]	ZTE, Comm-No2-2014., "Special Issue on Software Defined Networking (http://wwwen.zte.com.cn/endata/magazine/ztecommunications/2014/2/)", June 2014.
[Z2015]	ZTE, Comm-No1-2015., "Special Issue on 5G Wireless: Technology, Standard and Practice (http://wwwen.zte.com.cn/endata/magazine/ztecommunications/2015/1/)", March 2015.

Authors' Addresses