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