Distributed Mobility Management Kyoungjae Sun Internet Draft Truong-Xuan Do Intended status: Informational Younghan Kim Expires: January 2017 Soongsil University, Korea July 6, 2016 Multicast mobility deployment scenarios over distributed mobility management draft-kjsun-dmm-deployment-scenarios-multicast-dmm-03.txt 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 January 5, 2017. Copyright Notice Copyright (c) 2015 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. KJ Sun, et al. Expires January 5, 2017 [Page 1] Internet-Draft Multicast deployment scenario over DMM July 2016 Abstract This document presents deployment scenarios for supporting IP multicast over distributed mobility management (DMM) architecture, which considers the separation of the control and the data planes. This document describes three main use cases of IP multicast deployments over DMM depending on the placement of control and data plane functional entities. Table of Contents 1. Introduction ................................................ 2 2. Functional Decomposition..................................... 3 3. Terminology ................................................. 3 4. Use Cases Analysis .......................................... 4 4.1. Use Case 1 ............................................. 5 4.2. Use Case 2 ............................................. 6 5. Forwarding Policy Configuration for Multicast ................8 6. Security Considerations...................................... 9 7. IANA Considerations ......................................... 9 8. References .................................................. 9 8.1. Normative References.................................... 9 8.2. Informative References.................................. 9 9. Acknowledgments ..............................................9 1. Introduction Distributed mobility management is a new paradigm to solve current problems of centralized mobility management, such as a single point of failure, non-optimal routing [RFC7333]. IP multicast is an efficient content distribution mechanism which is designed with the IP mobility to bring new user experience and reduce bandwidth cost. In the [RFC7333], one requirement for DMM is to enable multicast solutions to avoid the inefficiency in the multicast traffic delivery. Existing solutions for supporting multicast in DMM are bi- directional tunnel [TUNNEL] and direct routing [ROUTING]. These solutions focus on the placement of MLD proxy and multicast router functions into the Mobility Access Router. The current architecture of the DMM is being changed to employ the concept of data and control plane separation. The data plane nodes KJ Sun, et al. Expires January 5, 2017 [Page 2] Internet-Draft Multicast deployment scenario over DMM July 2016 are configured by the control nodes via Forwarding Policy Configuration protocol, as defined in [I-D.ietf-dmm-fpc-cpdp]. The several deployment scenarios were presented in [I-D.wt-dmm-deployment-model]. However, there is no work until now, mentioning about multicast support in such new DMM architectures. Therefore, this document presents possible deployment scenarios, which support multicast listener in the DMM architectures based on the concept of the data and control planes separation. 2. Functional Decomposition Two options for deploying the multicast over conventional distributed mobility management (i.e. without the control and data plane separation) are MLD Proxy and Multicast router [RFC3810] [RFC4605]. This section decomposes functions of MLD Proxy and Multicast router that are required to deliver the multicast traffic with the respect to the concept of data and control planes separation. Below table is represented about functional description for supporting multicast. +------------------------------------------------------------------+ | Function | Description |C/D Plane| +------------------------------------------------------------------+ |Run | Used to join/leave the multicast tree | C-Plane | |multicast | infrastructure to receive the multicast | | |routing | data | | |protocol | | | +------------------------------------------------------------------+ |MLD | Used to notify about the multicast group | C-Plane | |membership | membership on the directly attached link | | |report | | | +------------------------------------------------------------------+ |MLD | Used to discover multicast listeners on | C-Plane | |Querier | the directly attached link | | +------------------------------------------------------------------+ |Membership | Used to maintain the merger of multicast | C-Plane | |database | subscriptions | | +------------------------------------------------------------------+ |Multicast | Used to forward multicast packets based on| D-Plane | |forwarding | the multicast subscriptions over each link| | +------------------------------------------------------------------+ Figure 1: Functional descriptions for supporting multicast 3. 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]. KJ Sun, et al. Expires January 5, 2017 [Page 3] Internet-Draft Multicast deployment scenario over DMM July 2016 This document uses the terminology defined in [RFC4605] and [RFC3810]. Also, new entities are defined relying on the concept of data and control planes separation and the functional decomposition. Terminologies are similarly named as DMM functions defined in [wt-dmm-deployment-model]. - CMA (Control plane Multicast Anchor): CMA consists of the control plane functions of the multicast router (Multicast Anchor). CMA is responsible for joining the multicast tree. - DMA (Data plane Multicast Anchor): DMA is the topological anchor point for multicast channels, subscribed by the MN. DMA provides packet treatment functions, such as packet forwarding, packet encapsulation. The DMA can be configured by the CMA via Forwarding Policy Configuration (FPC) protocol - CMN (Control plane Multicast Node): CMN is responsible for control plane functions of MLD-Proxy (multicast node) as described in the previous section. - DMN (Data plane Multicast Node): DMN is located at the first-hop router where the MN is attached. The DMN has the protocol interface with the CMN for configuration. 4. Use Cases Analysis Following defined terminologies, we adjust these entities into current centralized approaches which support multicast in centralized mobility architecture. Current multicast support approaches in centralized mobility architecture are defined in [RFC6224] and [RFC7028]. Since both approaches are based on PMIPv6, we use DMM entities which are mapped with PMIPv6 entities. Following table identifies the potential mapping of DMM function defined in [I-D.wt-dmm-deployment-model]. +===========+==========+==========+==========+==========+==========+ | FUNCTION | PMIPv6 | MIPv6 | IPsec | 3GPP | Broadband| +===========+==========+==========+==========+==========+==========+ | Home-CPA | LMA-CPA | HA-CPA | IKE-CPA | PGW-CPA | BNG-CPA | +-----------+----------+----------+----------+----------+----------+ | Home-DPA | LMA-DPA | HA-DPA | IKE-DPA | PGW-DPA | BNG-DPA | +-----------+----------+----------+----------+----------+----------+ |Access-CPN | MAG-CPN | - | - | SGW-CPN | RG-CPN | +-----------+----------+----------+----------+----------+----------+ |Access-DPN | MAG-DPN | - | - | SGW-DPN | RG-DPN | +-----------+----------+----------+----------+----------+----------+ Figure 2: Mapping of DMM functions KJ Sun, et al. Expires January 5, 2017 [Page 4] Internet-Draft Multicast deployment scenario over DMM July 2016 4.1. Use Case 1 First use case is based on [RFC 6224], which LMA has a role of both unicast and multicast anchor in PMIPv6 domain. In that approaches, LMA transposes any MLD message from a MAG into the multicast routing infrastructure and creates appropriate multicast forwarding states at its tunnel interface between LMA-to-MAG. Additionally, LMA acts as a MLD Querier. MAG acts as MLD proxy which forwards multicast traffic and initiates related signaling down to the appropriate MN. In this approach, most importantly, mobility entities are tightly coupled with multicast support functions. In other words, there is no additional entities to support multicast besides adding more functions into their PMIPv6 entities. Considering DMM deployment scenario with separation of control and data plane, two possible deployment models are existed. First model is that separated control and user plane model presented in Figure 3. In this model, the control plane function of multicast anchor is handled by the CMA and where as the data plane function is handled by DMA. The control plane function of the MLD proxy is handled by CMN and where as the data plane function is handled by DMN. Between control plane nodes, CMA and CMN, multicast related signaling messages are used to manage multicast group and make upstream/downstream interfaces to appropriate nodes. After a mobile node wants to join specific multicast channel and all related signaling messages are exchanged between control plane functions, control plane functions interact with their corresponding data plane nodes for the multicast traffic forwarding state management. ===================== == === = Multicast Infrastructure = ========================= | +================+ FPC +================+ | CMA + Home-CPA |-------| DMA + Home-DPA | +================+ +================+ | | | MLD/IGMP | UP {Tunnel/Route} | | +==================+ FPC +==================+ | CMN + Access-CPN |-----| DMN + Access-DPN | +==================+ +==================+ Figure 3: Separated control and user plane model with multicast supports KJ Sun, et al. Expires January 5, 2017 [Page 5] Internet-Draft Multicast deployment scenario over DMM July 2016 Another possible deployment model is that centralized control plane model presented in Figure 4. In this model, the control plane functions of multicast anchor and MLD proxy are combined into a combined control function of DMM. There is no signaling messages between multicast anchor and MLD proxy. Between the control plane and the data plane nodes, FPC protocol defined [I-D.ietf-dmm-fpc-cpdp] can be used to managing forwarding states of multicast traffic. ===================== == === = Multicast Infrastructure = ======================== | +================+ FPC +================+ | CMA + Home-CPA |-------| DMA + Home-DPA | | | +================+ | | | | | | UP {Tunnel/Route} | | | | | FPC +=================+ |CMN + Access-CPN|-------| DMN + Access-DPN| +================+ +=================+ Figure 4: Centralized control plane model with multicast supports 4.2. Use Case 2 In [RFC 7028], it separates multicast function into PMIPv6 entities. Following that document, two approaches are proposed; Multicast Tree Mobility Anchor (MTMA) solution and Direct routing solution. In the MTMA solution, the MTMA is dedicated to multicast traffic and used to get access to remote multicast content. That is, the MTMA acts as multicast router or MLD proxy. When MN attach to this architecture and receive both unicast and multicast traffic, since the MAG connects to both unicast anchor (e.g. LMA) and multicast anchor (e.g. MTMA), MN can simultaneously receive both unicast and multicast traffic from same MAG. For that, the MAG should support MLD proxy function in [RFC4605] and maintain its upstream/downstream interfaces to appropriate nodes. For multicast traffic, a multicast tunnel is established between MAG and MTMA. KJ Sun, et al. Expires January 5, 2017 [Page 6] Internet-Draft Multicast deployment scenario over DMM July 2016 Considering DMM deployment scenario with separation of control and data plane, MTMA approach can be described as Figure 5. In this figure, all multicast functions are deployed separately from unicast DMM function except access data plane function. In the access data plane, it maintains two forwarding states; unicast traffic forwarding states and multicast forwarding states. Unicast forwarding states are anchored by Home-DPA and multicast forwarding states are anchored by DMA. The control plane functions of DMM can be centralized and also the control functions of multicast can be centralized. ===================== == === +=================+ = Multicast Infrastructure = | Unicast Traffic | ======================== +=================+ | . | | . | | . MLD/IGMP +======+ +======+ | . | Home |_FPC_| Home | +=====+ +=====+ | -CPA | | -DPA | | DMA |---FPC--| CMA | +======+ +======+ +=====+ +=====+ | || || | |PMIP/ || UP || UP | MLD/IGMP |GTP ||{Tunnel/route} ||{Tunnel/route}| +======+ +======================+ +=====+ |Access|_FPC_| Access-DPN + DMN |____FPC__| CMN | | -CPN | | | +======+ +======+ +======================+ Figure 5: MTMA solution model with separated control and data plane Direct routing solution in [RFC7028] allows the MAG to directly connect to a multicast router. In this case, there is no multicast anchor and the MAG acts as the MLD proxy. For multicast traffic, the upstream interface of the MLD proxy instance has been configured pointing to a multicast router internal to the PMIPv6 domain. The MAG does not manage multicast group information. It just maintain upstream/downstream interface and performs MLD proxy operations defined in [RFC4605]. KJ Sun, et al. Expires January 5, 2017 [Page 7] Internet-Draft Multicast deployment scenario over DMM July 2016 Considering DMM deployment scenario with separation of control and data plane, direct routing approach can be described as Figure 6. In this figure, the multicast anchor function and the multicast access function are combined into single control/data plane nodes. In the access data plane node, it maintains both unicast and multicast forwarding states and interfaces to the appropriate nodes. Similar with the MTMA solution, the control plane functions of DMM or the control functions of multicast can be centralized. ===================== == === + ================+ = Multicast Infrastructure = | Unicast Traffic | ========================= +=================+ | | | | | +======+ +======+ | | Home |_FPC_| Home | +===========+ | -CPA | | -DPA | | Legacy MR | +======+ +======+ +===========+ | || || . |PMIP/ || UP || UP . MLD/IGMP |GTP || {Tunnel/Route} || . +========+ +=========================+ +===========+ | Access |_FPC_| Access-DPN |___FPC__| CMA + CMN | | -CPN | | DMA+DMN | +===========+ +========+ +=========================+ Figure 6: Direct routing solution model with separated control and data plane 5. Forwarding Policy Configuration for Multicast For communicating between DMM control plane and data plane function, Forwarding Policy Configuration (FPC) protocol is proposed in [I-D.ietf-dmm-fpc-cpdp]. FPC protocol enables the configuration of any data plane node and type by the abstraction of configuration details and the use of common configuration semantics. In recent document gives detail protocol attributes and operation parameters. Considering multicast support, we need to make sure that the current FPC protocol is resolved to create a forwarding rules for multicast traffic. For example, we can add identifier which represent multicast source address or add attribute for specific multicast group. KJ Sun, et al. Expires January 5, 2017 [Page 8] Internet-Draft Multicast deployment scenario over DMM July 2016 6. Security Considerations T.B.D 7. IANA Considerations T.B.D 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7333] H. Chan, D. Liu, P. Seite, H. Yokota, and J. Korhonen, "Requirements for Distributed Mobility Management", IETF RFC 7333, Aug. 2014. [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", IETF RFC 3810, June 2004. [RFC4605] B. Fenner, H. He, B. Haberman, H. Sandick, "Internet Group Management Protocol (IGMP)/ Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", IETF RFC 4605, Aug. 2006. 8.2. Informative References [TUNNEL] S. Figueiredo, S. Jeon, and R. L. Aguiar, "IP Multicast Use Cases and Analysis over Distributed mobility Management",draft-sfigueiredo-multimob-use-case-dmm-03 (expired April 2013). [ROUTING] Y. Kim, T-X. Do, and Y. Kim, "Direct Routing for Mobile Multicasting in Distributed Mobility Management Domain", Proc. INTERNET 2013 pp. 1-3. [I-D.ietf-dmm-fpc-cpdp] M. Liebsch, S. Matsushima, S. Bundavelli, D. Moses, "Protocol for Forwarding Policy Configuration (FPC)", draft-ietf-dmm-fpc-cpdp-03 (work in progress), March 2016. [I-D.wt-dmm-deployment-model] S. Gundavelli, "DMM Depolyment Models and Architectural Considerations", draft-wt-dmm-deployment -models-00 (work in progress), April 2016. [RFC6224] Schmidt, T., Waehlisch, M., Krishnan, S., "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 9. Acknowledgments KJ Sun, et al. Expires January 5, 2017 [Page 9] Internet-Draft Multicast deployment scenario over DMM July 2016 Authors' Addresses Kyoungjae Sun Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul 156-743, Korea Email: gomjae@ssu.ac.kr Truong-Xuan Do Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul 156-743, Korea Email: xuan@dcn.ssu.ac.kr Younghan Kim Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul 156-743, Korea Email: younghak@dcn.ssu.ac.kr KJ Sun, et al. Expires January 5, 2017 [Page 10]