Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-khas-nwcrg-impact-of-vir-and-sdn-00.txt Дата изменения: Sun Oct 18 03:09:49 2015 Дата индексирования: Sun Apr 10 08:04:31 2016 Кодировка: Поисковые слова: horizon

Network Coding RG B. Khasnabish
Internet-Draft ZTE TX, Inc.
Intended status: Informational E. Haleplidis
Expires: April 19, 2016 University of Patras
C. Adjih
Inria
S. Sivakumar
Cisco Systems Inc.
October 17, 2015


Impact of Virtualization and SDN on Emerging Network Coding
draft-khas-nwcrg-impact-of-vir-and-sdn-00.txt

Abstract

Network Coding is a technique used to code packets and be able to
recover coded packets from loses. It requires at least two
participating nodes in the path of the packet, one to encode and
another to decode. This document discusses the impact of
virtualization and Software-Defined Networking (SDN) on the emerging
network coding. This document also discusses the integration of
network coding in various layers of the network stack and the APIs
required from the network coding entity to program it from a
controller.

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 April 19, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.




Khasnabish, et al. Expires April 19, 2016 [Page 1]

Internet-Draft Virtualization, SDN for Network Coding October 2015


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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Definitions . . . . . . . . . . . . . . . 4
2. Separation of Control . . . . . . . . . . . . . . . . . . . . 5
2.1. Separation Fundamentals . . . . . . . . . . . . . . . . . 5
2.2. Separation of Control for Transport . . . . . . . . . . . 5
2.3. Separation of Control for network layer . . . . . . . . . 6
2.4. Separation of Control for Forwarding . . . . . . . . . . 7
3. Virtualization and its use in Network Coding . . . . . . . . 8
3.1. Virtualization of Application/Service Resources . . . . . 8
3.2. Virtualization of Computing Resources . . . . . . . . . . 8
3.3. Virtualization of Network-Level Resources . . . . . . . . 8
3.4. Virtualization for Network Coding . . . . . . . . . . . . 8
3.5. Network Coding Controller and APIs . . . . . . . . . . . 8
4. Network Coding Control and SDN . . . . . . . . . . . . . . . 8
4.1. Apps and Service Layer . . . . . . . . . . . . . . . . . 8
4.2. Control Layer . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Virtualization Layer . . . . . . . . . . . . . . . . . . 9
4.4. Physical Resources Layer . . . . . . . . . . . . . . . . 9
4.5. Management and Orchestration . . . . . . . . . . . . . . 9
4.6. APIs: For Example Transport APIs . . . . . . . . . . . . 9
4.7. Generic Lifecycle Management . . . . . . . . . . . . . . 9
5. Practical Considerations with NC and SDN . . . . . . . . . . 9
5.1. Some Use Cases for NC in SDN . . . . . . . . . . . . . . 10
5.2. Integrating NC with SDN technologies . . . . . . . . . . 12
6. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 13
7. Reference Implementation . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16




Khasnabish, et al. Expires April 19, 2016 [Page 2]

Internet-Draft Virtualization, SDN for Network Coding October 2015


1. Introduction

Background:

Abstraction/Virtualization of the Elements of Network:

Control of Network Coding:

APIs:

1.1. Scope

The scope of this document is discussion (and standardization) of
utilizing virtualization and SDN paradigm in the emerging network
coding.

Ongoing discussions on virtualization and SDN can be found in the
following IETF and IRTF Websites: NVO3
[http://datatracker.ietf.org/wg/nvo3/], ForCES
[http://datatracker.ietf.org/wg/forces/], I2RS
[http://datatracker.ietf.org/wg/i2rs/], SCIM
[http://datatracker.ietf.org/wg/scim/], SPRING
[http://datatracker.ietf.org/wg/spring/], SFC/NSC
[http://datatracker.ietf.org/wg/sfc/], and SDN-RG [http://irtf.org/
sdnrg].

Virtualization has been discussed (and deployed) widely in the
Computing Industry (e.g., server) in the context of efficient
utilization of server resources.

Virtual resources management in the context of Cloud and Data Center
(DC) environment using unified API has been discussed in
[I-D.junsheng-opsawg-virtual-resource-management].

IETF ForCES Logical Function Block (LFB) Subsidiary Management (SM)
for supporting virtualization of ForCES Network Element (NE)
including control Element (CE) and Forwarding Element (FE) has been
recently discussed in [I-D.khs-forces-lfb-subsidiary-management].

1.2. Abbreviations

o API: Application Programming Interface

o CPSI: Control Plane Southbound Interface

o DAL: Device and resource Abstraction Layer

o DC: Data Center



Khasnabish, et al. Expires April 19, 2016 [Page 3]

Internet-Draft Virtualization, SDN for Network Coding October 2015


o NC: Network Coding

o NCC: Network Coding Controller

o NE: Network Element

o PL: Protocol Layer

o SCTP: Stream Control Transmission Protocol

o SDN: Software-Defined Network/Networking

o TCP: Transport Control Protocol

o TML: Transport Mapping Layer

o VCE: Virtual CE

o VDC: Virtual DC

o VNE: Virtual NE

1.3. Conventions and Definitions

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 definitions are taken from the notional Network Coding
Architecture slides (http://www.ietf.org/proceedings/88/slides/
slides-88-nwcrg-6.pdf). These are repeated here for convenience.

o APP --

o APP Interface --

o Network Coding Transport Protocol --

o Network coding Aware Routing Protocol --

o Link Layer / MAC --

o Others --








Khasnabish, et al. Expires April 19, 2016 [Page 4]

Internet-Draft Virtualization, SDN for Network Coding October 2015


2. Separation of Control

There are many advantages of separating control from forwarding,
routing, transport, etc. in the emerging SDNs. The ability to
integrate network coding in different layers provides the abstraction
and the flexibility to choose to apply the technique based on
different application characteristics.

In addition to flexibility, this also offers additional reliability
and scalability with minimal additional burden on cost and
performance.

2.1. Separation Fundamentals

Recent work in the SDNrg have focused on the terminology and a base
layered architecture, described in
[I-D.irtf-sdnrg-layer-terminology].
[I-D.irtf-sdnrg-layer-terminology] provides a detailed description of
the SDN layers architecture by separating SDN into distinct planes,
abstraction layers and interfaces.

[I-D.irtf-sdnrg-layer-terminology] describes a number of different
planes. The forwarding and operational plane associated with the
device, the control and management plane and the application plane.
In addition [I-D.irtf-sdnrg-layer-terminology] specifies their
relevant interfaces and their characteristics as well as the
abstraction layers that all comprise an SDN architecture.

This document is well aligned with
[I-D.irtf-sdnrg-layer-terminology]. Depending on where the network
coding entity is located, in the forwarding or operational plane or
as a service in the control plane different abstraction layers and
interfaces are involved.

For example if a network coding entity is located in the forwarding
plane of the device, the operations of the network coding entity are
described by the Device and resource Abstraction Layer (DAL) and the
Network Coding Controller, described in Figure 1 and Figure 2, is a
service of the control plane and uses a Control Plane Southbound
Interface (CPSI) to control the network coding entity.

2.2. Separation of Control for Transport

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





Khasnabish, et al. Expires April 19, 2016 [Page 5]

Internet-Draft Virtualization, SDN for Network Coding October 2015


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++++
| Network Coding Controller (e.g., a module in SDN Controller) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++++
| | | | |
| | | | |
| | | | |
| | | | |
+-+-+-+-+-+-+-+-+-+ | | | |
| SCTP | | | | |
+-+-+-+-+-+-+-+-+-+ | | | |
| | | |
+-+-+-+-+-+-+-+-+-+ | | |
| MP-TCP | | | |
+-+-+-+-+-+-+-+-+-+ | | |
| | |
+-+-+-+-+-+-+-+-+-+-+ | |
| TCP | | |
+-+-+-+-+-+-+-+-+-+-+ | |
| |
+-+-+-+-+-+-+-+-+-+-+ |
| UDP | |
+-+-+-+-+-+-+-+-+-+-+ |
|
+-+-+-+-+-+-+-+-+-+
| Other |
+-+-+-+-+-+-+-+-+-+




Figure 1

The network coding can be applied for different transport protocols
based on what the controller specifies, as shown in Figure 1. For
example, the controller can orchestrate the network coding entity to
code all the traffic on specific TCP/UDP sockets. This requires the
APIs from network coding controller (NCC) to program the network
coding function in the forwarding plane to intercept the interesting
transport layer packets and code them.

2.3. Separation of Control for network layer

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






Khasnabish, et al. Expires April 19, 2016 [Page 6]

Internet-Draft Virtualization, SDN for Network Coding October 2015


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++
| 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.






Khasnabish, et al. Expires April 19, 2016 [Page 7]

Internet-Draft Virtualization, SDN for Network Coding October 2015


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.






Khasnabish, et al. Expires April 19, 2016 [Page 8]

Internet-Draft Virtualization, SDN for Network Coding October 2015


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



Khasnabish, et al. Expires April 19, 2016 [Page 9]

Internet-Draft Virtualization, SDN for Network Coding October 2015


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:

o In which scenarios (use cases) could NC be used with SDN?

o 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:

o 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




Khasnabish, et al. Expires April 19, 2016 [Page 10]

Internet-Draft Virtualization, SDN for Network Coding October 2015


network to recover from link failure (and re-route) is considered
too high.

o 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:

o 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.

o cross-domain coding: through SDN, there is potential for combining
NC in the network itself, with NC in the storage for instance.

o 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:





Khasnabish, et al. Expires April 19, 2016 [Page 11]

Internet-Draft Virtualization, SDN for Network Coding October 2015


o 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 Nemeth 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:

o 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

o An extension of OpenFlow with specific buffers (to hold coded
packets, managed by the controller), and specific actions: coding
initialization, coding, and decoding

o An implementation done in the simulator Mininet, by extending
OpenvSwitch 1.9.0



Khasnabish, et al. Expires April 19, 2016 [Page 12]

Internet-Draft Virtualization, SDN for Network Coding October 2015


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].






Khasnabish, et al. Expires April 19, 2016 [Page 13]

Internet-Draft Virtualization, SDN for Network Coding October 2015


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", draft-irtf-sdnrg-layer-
terminology-01 (work in progress), September 2014.

[I-D.junsheng-opsawg-virtual-resource-management]
Chu, J., Khasnabish, B., Qing, Y., and Y. Meng, "Virtual
Resource Management in Cloud", draft-junsheng-opsawg-
virtual-resource-management-00 (work in progress), July
2011.

[I-D.karavettil-vdcs-security-framework]
Karavettil, S., Khasnabish, B., Ning, S., and W. Dong,
"Security Framework for Virtualized Data Center Services",
draft-karavettil-vdcs-security-framework-05 (work in
progress), 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", draft-khasnabish-cloud-reference-
framework-06 (work in progress), January 2014.

[I-D.khs-forces-lfb-subsidiary-management]
Khasnabish, B., Haleplidis, E., and J. Salim, "IETF ForCES
Logical Function Block (LFB) Subsidiary Management",
draft-khs-forces-lfb-subsidiary-management-01 (work in
progress), July 2014.

[I-D.montpetit-transport-strawman]
Montpetit, M., Zhovnirovsky, I., and B. Reuther,
"Transport Services Strawman Architecture", draft-
montpetit-transport-strawman-01 (work in progress),
February 2014.



Khasnabish, et al. Expires April 19, 2016 [Page 14]

Internet-Draft Virtualization, SDN for Network Coding October 2015


[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., Ed., "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] Felician Nemeth, Adam Stipkovits, Balazs Sonkoly, Andras
Gulyas, , "Towards SmartFlow: Case Studies on Enhanced
Programmable Forwarding in OpenFlow Switches", SIGCOMM
Demo 2012, Aug 2012.

[RFC3654] Khosravi, H., Ed. and T. Anderson, Ed., "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, .







Khasnabish, et al. Expires April 19, 2016 [Page 15]

Internet-Draft Virtualization, SDN for Network Coding October 2015


[RFC7642] LI, K., Ed., 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

Bhumip Khasnabish
ZTE TX, Inc.
55 Madison Avenue, Suite 160
Morristown, New Jersey 07960
USA

Phone: +001-781-752-8003
EMail: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/


Evangelos Haleplidis
University of Patras
Department of Electrical and Computer Engineering
Patras 26500
Greece

EMail: ehalep@ece.upatras.gr


Cedric Adjih
Inria
Saclay - Ile-de-France research centre
France

EMail: Cedric.Adjih@inria.fr



Khasnabish, et al. Expires April 19, 2016 [Page 16]

Internet-Draft Virtualization, SDN for Network Coding October 2015


Senthil Sivakumar
Cisco Systems Inc.
7100-8 Kit Creek Road
Durham, North Carolina 27709
USA

Phone: +001-919-392-5158
EMail: ssenthil@cisco.com











































Khasnabish, et al. Expires April 19, 2016 [Page 17]