Network Working Group Z. Qiang Internet Draft Ericsson Intended status: Informational October 27, 2014 Expires: April 2015 Supporting Applications Specific Multicast in NVO3 draft-zu-nvo3-mcast-considerations-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 27, 2015. Z. Qiang Expires April 27, 2015 [Page 1] Internet-Draft Multicast in NVO3 October 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Abstract The framework of supporting applications specific multicast traffic in a network using Network Virtualization using Overlays over Layer 3 (NVO3) has been discussed. The various mechanisms and considerations that can be used for delivering those application specific multicast traffic in networks that use NVO3 have been considered. This draft discusses some additional considerations on how to support applications specific multicast traffic in NVO3. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Terminology....................................................3 4. Considerations.................................................3 5. Optimizations..................................................4 6. Procedures.....................................................5 6.1. Source NVE................................................5 6.2. Receiving NVE.............................................6 6.3. Multicast Proxy function..................................6 6.4. Receiving multicast packets at Source NVE.................7 6.5. Receiving multicast packets at Proxy NVE..................7 6.6. Receiving multicast packets at Receiving NVE..............7 7. Security Considerations........................................7 8. IANA Considerations............................................7 9. References.....................................................8 9.1. Normative References......................................8 Z. Qiang Expires April 27, 2015 [Page 2] Internet-Draft Multicast in NVO3 October 2014 9.2. Informative References....................................8 10. Acknowledgments...............................................8 1. Introduction Network virtualization using Overlays over Layer 3 (NVO3) is a technology that is used to address issues that arise in building Large, multitenant data centers that make extensive use of server virtualization [RFC7364]. The framework of supporting application specific multicast traffic in a network that uses Network Virtualization using Overlays over Layer 3 (NVO3) is discussed in the draft [NVO3-MC]. It describes 4 mechanisms and some considerations that can be used for delivering those application specific multicast traffic in networks that use NVO3. This draft discusses some additional considerations on how to support applications specific multicast traffic in NVO3. The reader is assumed to be familiar with the terminology as defined in the NVO3 Framework document [RFC7365] and NVO3 Architecture document [NVO3-ARCH]. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Terminology This document uses the same terminology as found in [NVO3-MC]. 4. Considerations While the mechanisms discussed in Section 3 of [NVO3-MC] have been discussed individually, it is important for a development to support one or more methods in a large, multitenant data centers. It is hard to say which method is better than the others without considerations of the tenant system overlay network architecture. This document attempts to provide considerations on each mechanism detailed in section 3 of [NVO3-MC]. Z. Qiang Expires April 27, 2015 [Page 3] Internet-Draft Multicast in NVO3 October 2014 The source NVE replication method descripted in Section 3.2 of the [NVO3-MC] may be more attractive for a tenant system which only has a few NVEs participating the overlay forwarding, even the tenant system may have hundreds of VMs. As the number of participating NVE is not that many, the source NVE replication will not generate too many duplicated traffic traverse the same overlay network connection. Additional overlay control signaling may provide some level of optimizations. Furthermore, it is not a big scaling issue for a multi-tenant data center which the number of tenant networks can be hundreds. However, if a tenant system contains many VMs attaching to a large number of NVEs, using source NVE replication method may generate large amount of duplicated traffic on the same overlay network connection. Another alternative, which can be used to avoid network connections overloading due to the duplicated traffic, is to use an IP multicast in underlay method descripted in Section 3.4 of [NVO3-MC] to handle the application multicast traffic. However, additional NVA-NVE control signaling may be needed in order to enable the multicast address mapping at source NVE. This method however introduces an additional scaling problem if there are too many multicast groups within a multi-tenancy data center which may have a large number of tenant networks. The service node method descripted in Section 3.3 of [NVO3-MC] may be preferable for a tenant network where the multicast source VM and the receiver VMs are distributed and the service node can be placed closer to the multicast receiving VMs. Otherwise, this alternative will have same duplicated traffic overloading issue as the source NVE replication mechanism. In order to enable the service node function at the property location, the NVA may need to know the participants list of each multicast group in advance. Ideally, the service node function shall be placed closer to the receivers attached NVEs. Indeed, if the service node function and one of the receivers attached NVEs are collocated, this method is very similar to the multicast distribution tree mechanism described in MVPN [RFC6513]. 5. Optimizations In order to provide optimal routing for a particular multicast flow and to improve the multicast scalability as unicast traffic, the source NVE shall forward the received multicast packet to the destination NVEs only if the destination NVE has at least one participating VM of that multicast group. Duplication of the Z. Qiang Expires April 27, 2015 [Page 4] Internet-Draft Multicast in NVO3 October 2014 multicast packet to the destination NVEs on the same network connection shall be avoided. One alternative for the above optimization is to use the multicast distribution proxy for each multicast group, which is similar to the multicast distribution tree mechanism described in MVPN [RFC6513]. Instead of using BGP as control plane signaling, the NVA-NVE signaling can be used to setup this multicast distribution proxy architecture per multicast group. To avoid generating large amount of duplicated traffic on the same overlay network connection, the source NVE may duplicate the multicast traffic and only send it to a limited number of proxy NVEs. Then the proxy NVE can further duplicate the multicast traffic and forward it to the rest of the receiving NVEs. 6. Procedures In this document, the optimization alternative of how the multicast distribution proxy can be applied in the NVO3 architecture is discussed. The procedure is to make use of the NVA, which is the centralized control node of the NVO3 architecture, to select the proxy NVEs from the participating NVEs and setup a distribution path for each multicast group. 6.1. Source NVE Source NVE is the NVE which the multicast application VM is attached. It is assumed that the source NVE knows if a multicast application VM is attached. The NVE may know it via overlay network provisioning or using some kind multicast monitoring functions, e.g. IGMP snooping. How the multicast monitoring is performed is out of the scope of this document. The source NVE needs to register itself to the NVA in order to enable the multicast distribution mechanism. Once the source NVE registration is done, based on the multicast registration information and the multicast proxy function role selection decision, a multicast proxy NVE list and a Participant NVE list are created by the NVA. Z. Qiang Expires April 27, 2015 [Page 5] Internet-Draft Multicast in NVO3 October 2014 Multicast Proxy NVE list is a list of Proxy NVEs. It is created by the NVA and saved in the source NVE. It is used by the source NVE for multicast traffic duplication and distribution. And the source NVE is updated with the multicast proxy NVE list by NVA using the NVA-NVE control plane signaling. 6.2. Receiving NVE Receiving NVEs is the NVE where a multicast group participanting VMs attached. It is assumed that the Receiving NVE knows if an attached VM would like to join a multicast group. The NVE may know it via overlay network provisioning or using some kind multicast monitoring functions, e.g. IGMP snooping. How the multicast monitoring is performed is out of the scope of this document. The Receiving NVE shall inform the NVA if there is any VM multicast registrations, or if all the registered VMs of a given multicast group discontinue participating to the multicast group. The NVA uses this information to create / update the Participant NVE list of the multicast group. Participant NVE list is a list of receiving NVEs. It is created by the NVA and saved in the Proxy NVE. It is used by the Proxy NVE for multicast traffic duplication and distribution. 6.3. Multicast Proxy function Proxy NVE is one of the receiving NVEs. The proxy NVE is selected by the NVA. It has the responsibility of distributing the received multicast traffic to the participant NVEs. Multicast Proxy function role is assigned to one of the Receiving NVEs. The multicast proxy function role is dynamic allocated by the NVA at per multicast group and per tenant system. The proxy NVE will receive the multi-cast traffic from the source NVE and distribute it to other receiving NVEs in the receiving NVE list. When receiving the multicast registration information, the NVA selects one NVE as multicast proxy. The selection may be based on several conditions, such as forwarding capability, location, network segmentations, etc. A Participant NVE list will be sent to the Multicast Proxy NVE for multicast traffic duplication and distribution. The Participant NVE Z. Qiang Expires April 27, 2015 [Page 6] Internet-Draft Multicast in NVO3 October 2014 list is created at per Proxy NVE based. This is to avoid any unnecessary traffic duplication and looping. 6.4. Receiving multicast packets at Source NVE When receiving a multicast packet from the attached VM, the source NVE shall handle the packet as followings: If the multicast Proxy NVE list of a given multicast group is empty, the source NVE shall not forward any multicast packet of the given multicast group when receiving it from the attached VM. If the multicast Proxy NVE list of a given multicast group is not empty, the source NVE shall duplicate, encapsulate, and forward the received multicast packet to each Proxy NVEs based on the multicast Proxy NVE list received from NVA. 6.5. Receiving multicast packets at Proxy NVE The NVE which has been assigned with the multicast proxy function role will have the responsibility to distribute the multicast traffic based on the received multicast Participated NVE list. When receiving a multicast packet from the source NVE, the proxy NVE shall dencapsulate, duplicate, encapsulate, and forward the multicast packet to the destination NVEs based on the multicast Participated NVE list received from NVA. 6.6. Receiving multicast packets at Receiving NVE When receiving a multicast packet from a Proxy NVE, the receiving NVE shall dencapsulate multicast packet, and forward to the attached VM which has registered to the multicast group. 7. Security Considerations This is a discussion paper which provides inputs for the NVO3 requirement documents and in itself does not introduce any new security concerns. TBD 8. IANA Considerations No actions are required from IANA for this informational document. TBD Z. Qiang Expires April 27, 2015 [Page 7] Internet-Draft Multicast in NVO3 October 2014 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 9.2. Informative References [NVO3-MC] "Framework of Supporting Applications Specific Multicast in NVO3", June 6, 2014. [RFC6513] "Multicast in MPLS/BGP IP VPNs", February 2012 [RFC7364] "Problem statement: Overlays for network virtualization", October 2014. [RFC7365] "Framework for Data Center (DC) Network Virtualization", October 2014. [NVO3-ARCH] Narten, T. et al.," An Architecture for Overlay Networks (NVO3)", work in progress, Feb 2014. 10. Acknowledgments Many people have contributed to the development of this document and many more will probably do so before we are done with it. While we cannot thank all contributors, some have played an especially prominent role. The following have provided essential input: Suresh Krishnan. Authors' Addresses Zu Qiang Ericsson 8400, boul. Decarie Ville Mont-Royal, QC, Canada Email: Zu.Qiang@Ericsson.com Z. Qiang Expires April 27, 2015 [Page 8]