Internet DRAFT - draft-chen-opsawg-dcn-vn2pn-mapping
draft-chen-opsawg-dcn-vn2pn-mapping
Network Working Group H. Chen
INTERNET-DRAFT Y. Li
Intended Status: Informational X. Chu
Y. Wu
Expires: April 20, 2016 October 18, 2015
Virtual Network to Physical Network Mapping in DataCenter Network
draft-chen-opsawg-dcn-vn2pn-mapping-00
Abstract
Cloud tenant needs virtual network to interconnect their VMs on
server. In order to effectively and efficiently map virtual network
to physical network, certain mechanism should be employed.
This memo analysis the existing VN2PN mapping technique employed in
DataCenter and point out the potential shortcomings lie in it. This
memo also try to provide a generic mechanism to facilitate the VN2PN
mapping in DataCenter network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen & Li, et al [Page 1]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Status Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Problem Statements . . . . . . . . . . . . . . . . . . . . . 5
3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Fabric Agent . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Fabric Manager . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Chen & Li, et al [Page 2]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
1. Introduction
Cloud tenant needs virtual network to interconnect their VMs on
server. In order to effectively and efficiently map virtual network
to physical network, certain mechanism should be employed.
This memo analysis the existing VN2PN mapping technique employed in
DataCenter and point out the potential shortcomings lie in it. This
memo also try to provide a generic mechanism to facilitate the VN2PN
mapping in DataCenter network.
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 RFC 2119 [RFC2119].
This document makes use of the following terms, additional terms are
defined in [RFC7348] and [RFC7365]
o PoD - point of delivery, a module of network, compute, storage,
and application components that work together.
o Renderer - an intermediate layer used to realize the VN to PN
mapping function, which is usually technique dependent and vendor
specific.
o Fabric - a logic unit corresponds to a single Pod in DataCenter,
provides the basic layer2/3 network service.
o VN - Virtual Network
o PN - Physical Network
o BD - Bridge Domain
o LSW - Logic Switch
o LR - Logic Router
o ACL - Access Control List
3. Status Analysis
In DataCenter network, tenants need to create their network in the
logic view, namely the virtual network. The virtual network could be
a Bridge Domain provides layer 2 interconnection (e.g. Ethernet) or a
Chen & Li, et al [Page 3]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
VRF provides layer 3 interconnection(e.g. IP network).
As shown below, Figure 1 shows a logic network tenants wanted while
figure 2 shows one possible mapping results at the physical network
layer.
+------+ ^
| LR | |
+//---\+ |
// \ |
// \ |
+--/--+ +--\--+ |
|LSW 1| |LSW 2| |
+|---|+ ++---++ |
..|...| |...|.
... | |.. ... | ... VN
. | | . . | | .
. +-|-+ +-|-+. . +-+-+ +-+-+ . |
. |VM1| |VM3|. . |VM2| |VM4| . |
. +---+ +---. .+---+ +---+ . |
.... .... .... .... |
.... .... |
Subnet 1 Subnet 2 |
v
Figure 1: Example of required Logic Network
Considering the use case of cloud environment. Tenant has four VMs
and needs to create a network to interconnect. As figure 1 shows, VM1
and VM3 are of one BD (Subnet 1)and connected through LSW 1. VM2 and
VM4 are of another BD (Subnet 2) and connected through LSW 2. LSW 1
and LSW 2 are connected through LR to form a layer 3 IP network.
The generated network from VN normally depends on the architecture,
techniques, and available resources of underneath PN. One of the
possible result is shown in figure 2, where VM 1 and VM 3 are of a
VLAN-based BD while VM 2 and VM4 are of a VXLAN-based BD. A Core
switch connects these two subnets to form a layer 3 IP network.
Existing implementation is to employ an intermediate layer called
Renderer to realize it.
Chen & Li, et al [Page 4]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
+------+ ^
--------+ Core +------------- |
// +-/--\-+ \ |
// // \ \ |
/ // \ \ |
// // \ \ |
'''''''''//'''''''''//''''''' ''''''''\''''''''''''\'''''''''' |
' +--/---+ +--/---+ ' ' +-\---+ +---\-+ ' |
' | Aggr +---+ Aggr | ' ' |spine+---+spine| ' |
' +------+ +------+ ' ' +-----+ +-----+ '
' ' ' ' PN
' VLAN-based PoD ' ' VXLAN-based PoD '
' ' ' ' |
'+---+ +---+ +---+ +---+' '+----+ +----+ +----+ +----+' |
'|ToR+--+ToR| |ToR+--+ToR|' '|leaf| |leaf| |leaf| |leaf|' |
'+-+-+ +---+ +-+-+ +---+' '+-+--+ +----+ +----+ +-+--+' |
'''|''''''''''''''|'''''''''' '''|'''''''''''''''''''''''|'''' |
| | | | |
+-+-+ +-+-+ +-+-+ +-+-+ |
|VM1| |VM3| |VM2| |VM4| |
+---+ +---+ +---+ +---+ v
Figure 2: Example of Generated Physical Network
Network(PN) mapping
3.1 Problem Statements
Existing implementation of VN2PN mapping has some shortcomings:
o Technique Dependent
Many network techniques are being used in existing Data Center
network, such as VLAN, TRILL, and VXLAN. As shown in Figure 3, Pod 1
is VLAN-based, Pod 2 is TRILL-based and Pod 3 is VXLAN-based. One
Renderer supports mapping a VN to a PoD. For example, Renderer 1 is
able to map a VN to PoD 1, while Renderer 2 is able to map a VN to
PoD 2 and Renderer 3 is able to map a VN to PoD 3. That is to say,
current implementation of Renderers is technique dependent, one type
of Renderer can only map a VN to one specific type of PN. Considering
a Data Center network consists of multiple PoDs with different
network techniques(some PoDs are VLAN-based and some others are VXLAN
based), multiple types of Renderers are required.
Chen & Li, et al [Page 5]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
+----------+ +----------+ +----------+
| VN | | VN | | VN |
+----^-----+ +----^-----+ +----^-----+
| | |
| | |
| | |
+----v-----+ +----v-----+ +----v-----+
|Renderer 1| |Renderer 2| |Renderer 3|
+----^-----+ +----^-----+ +----^-----+
| | |
| | |
VLAN | TRILL | | VXLAN
+----v-----+ +----v-----+ +----v-----+
| PN | | PN | | PN |
+----------+ +----------+ +----------+
PoD 1 PoD 2 PoD 3
Figure 3: Example of Technique Dependent VN2PN Mapping
o Vender Specific
Basically, Data Center network consists of switches/routers from
various vendors, which usually configure their devices in a different
manner. As shown in Figure 4, for N vendors it requires at least N
type of renders, namely vender specific.
+----------+ +----------+ +----------+
| VN | | VN | | VN |
+----^-----+ +----^-----+ +----^-----+
| | |
| | |
| | |
+----v-----+ +----v-----+ +----v-----+
|Renderer 1| |Renderer 2| |Renderer 3|
+----^-----+ +----^-----+ +----^-----+
| | |
| | |
Vender A| Vender B| |Vender
+----v-----+ +----v-----+ +----v-----+
| PN | | PN | | PN |
+----------+ +----------+ +----------+
PoD 1 PoD 2 PoD 3
Figure 4: Example of Vender Specific VN2PN Mapping
o Individual device oriented configuration
Existing interfaces to network devices are lack of abstraction of
Chen & Li, et al [Page 6]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
network. The upper-layer application and network administrator have
to configure individual device. Besides, these interfaces are
complicated and procedure oriented. All these lead to a gap between
the upper-layer application model and PN.
In the real deployment scenario, the above issues may coexist in one
Date Center, which makes the VN2PN more complicate:
* The upper-layer application or the network manager must know all
type of Renderer, or there exists renderer which is able to
configure switch/router from various vendors. However, this may
not be true based on current renderer-based implementation .
* If it is required to mapping a VN to multiple Pods, the upper-
layer application should know which/how part of VN could be mapped
to which technique specific PoD(VLAN/TRILL/VXLAN/...) which means
upper-layer application should implement the VN2PN mapping
decomposition function.
3.2 Requirements
According to section 3.1, it can be concluded that the technique and
vendor independent VN2PN mapping mechanism should be firstly
considered. As shown in figure 5, a mapping manager can be used to
achieving the purposes.
+----------+
| VN |
+----^-----+
|
|
+--------v--------+
| |
| Mapping Manager |
| |
+--------^--------+
|
|
+----v-----+
| PN |
+----------+
PoD
(VLAN/TRILL/VXLAN/...)
Figure 5: Technique and Vendor Independent Mapping
with mapping manager
The requirements can be list as follows:
Chen & Li, et al [Page 7]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
o Network Technique Independent
There SHOULD be a mapping manager which is able to map tenant's VN to
technique independent PN. In this way, their are no requirements for
the up-layer application to know the technique employed in the PN.
o Vender Independent Configuration
The mapping manager SHOULD provide a mechanism to support multi-
vendor device configuration. In this way, the up-layer application
and mapping manager do not have to handle the underlying diversity of
multi-vender devices .
o Reasonable abstraction of network
Existing individual device oriented configuration results in a gap
between the upper-layer application model and PN, which complicates
the mapping procedure. There SHOULD be a reasonable abstraction of
network to reduce the gap and make it easy to implement the VN2PN
mapping.
4. Architecture
In order to effectively and efficiently map the VN to PN, certain
mechanism should be employed. The basic idea is to abstract the
underneath PN in a bottom-up fashion. Each PoD is abstracted to a
logic unit - called fabric.
4.1 Fabric Agent
Each fabric provides common fabric services via a fabric agent, as
shown in figure 6. The fabric services refer to the L2/L3
connectivity, QoS as well as ACL control. The upper-layer application
and network administrator will configure fabrics, instead of
configuring each individual devices. Those services provides fabric
oriented and technology and vendor agnostic APIs to make new
application building simpler, easier, faster and less error prone.
The fabric agent provides the fabric services to VN, including L2/L3
connectivity, QoS as well as ACL control. It is also responsible for
the configuration of switches and routers in PoD. The configuration
information may be transported to these devices by using SNMP,
NETCONF or OpenFlow. The Device Config Object provides a unified
device configuration model to hides the underneath details of device
from fabric agent. Different vendors may implement their own device
drivers and embed them to fabric agent as plugins. The Mapping Layer
is responsible for transforming the fabric service into the Device
Config Object.The fabric agent provides the fabric services to VN in
the form of LSW and LR.
Chen & Li, et al [Page 8]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
+-----------------------+
|+---------------------+|
|| Fabric Service ||
|+---------------------+|
|+---------------------+|
|| Mapping Layer ||
|+---------------------+|
|+---------------------+|
||Device Config Object ||
|+---------------------+|
|+---------------------+|
||Device Driver(plugin)||
|+---------------------+|
+-----------------------+
Figure 6: Structure and Elements of Fabric Agent
Assuming the VMs of a tenant reside in one PoD, forming the 1:1
mapping between VN and PN(PoD), the architecture can be shown as
figure 7. VN uses the fabric services provided by fabric agent to
generate device configuration data and transports them to switches
/routers in the PoD via certain network management protocol such as
SNMP, NETCONF or OpenFlow.
+------------+
| VN |
+-----^------+
| Fabric Service
......|.......
.+----v-----+.
.| Fabric |.
.| Agent |.
.+----^-----+.
. | SNMP/Netconf/Openflow
.+----v-----+.
.| |.
.| PoD |.
.| |.
.+----------+.
..............
Fabric
Figure 7: Example of 1:1 VN2PN Mapping
4.2 Fabric Manager
The VMs connected to switches may be distributed in several PoDs,
Chen & Li, et al [Page 9]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
which results in the the 1:N VN2PN mapping as figure 8 shows.
A logic element called fabric manager is employed. The main function
of fabric manager is to orchestrate the services provided by the
underneath multi-fabrics.
+------------+
| VN |
+-----+------+
|
| Fabric Service
+---------------------v----------------------+
| Fabric manager |
+---------------------^----------------------+
|
|
+---------------+---------------+
| | |
......|....... ......|....... ......|.......
.+----v-----+. .+----v-----+. .+----v-----+.
.| Fabric |. .| Fabric |. .| Fabric |.
.| Agent |. .| Agent |. .| Agent |.
.+----+-----+. .+----+-----+. .+----+-----+.
. | . . | . . | .
.+----v-----+. .+----v-----+. .+----v-----+.
.| |. .| |. .| |.
.| PoD 1 |. .| PoD 2 |. .| PoD 3 |.
.| |. .| |. .| |.
.+----------+. .+----------+. .+----------+.
. VLAN . . TRILL . . VXLAN .
.............. .............. ..............
Fabric 1 Fabric 2 Fabric 3
Figure 8: Example of 1:N VN2PN Mapping
5. Security Considerations
Security considerations are not addressed in this document.
6. Acknowledgements
The authors would like to thank Wei Song, Feng Dong and Guoli Yin for
their comments and contributions.
7. IANA Considerations
No IANA action is needed for this document.
Chen & Li, et al [Page 10]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC791] Postel, J., "Internet Protocol", September 1981.
8.2 Informative References
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M. and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", August 2014.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, October 2014,
Authors' Addresses
Hao Chen
Huawei Technologies
12, E. Mozhou Rd., Jiangning Dist.,
Nanjing, Jiangsu 211111
China
Phone: +86-25-56627052
EMail: philips.chenhao@huawei.com
Yizhou Li
Huawei Technologies
12, E. Mozhou Rd., Jiangning Dist.,
Nanjing, Jiangsu 211111
China
Phone: +86-25-56627056
EMail: liyizhou@huawei.com
Xingjun Chu
Chen & Li, et al [Page 11]
INTERNET DRAFT VN to PN Mapping in DataCenter Network July 2015
Huawei Technologies
303 Terry Fox Drive, Suite 400
Kanata, Ontario K2K 3J1
Canada
Phone: +1 613 595-1900
Email: Xingjun.Chu@huawei.com
Yapeng Wu
Huawei Technologies
303 Terry Fox Drive, Suite 400
Kanata, Ontario K2K 3J1
Canada
Phone: +1 613 595-1900
Email: Yapeng.Wu@huawei.com
Chen & Li, et al [Page 12]
