idnits 2.17.1 draft-kjsun-dmm-deployment-scenarios-multicast-dmm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 6) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7028' is mentioned on line 327, but not defined == Missing Reference: 'RFC 6224' is mentioned on line 204, but not defined == Missing Reference: 'RFC 7028' is mentioned on line 279, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-03 -- No information found for draft-wt-dmm-deployment - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Distributed Mobility Management Kyoungjae Sun 2 Internet Draft Truong-Xuan Do 3 Intended status: Informational Younghan Kim 4 Expires: April 2017 Soongsil University, Korea 5 October 31, 2016 7 Multicast mobility deployment scenarios over distributed mobility 8 management 9 draft-kjsun-dmm-deployment-scenarios-multicast-dmm-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on April 30, 2017. 28 Copyright Notice 30 Copyright (c) 2015 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with 38 respect to this document. Code Components extracted from this 39 document must include Simplified BSD License text as described in 40 Section 4.e of the Trust Legal Provisions and are provided without 41 warranty as described in the Simplified BSD License. 43 Abstract 45 This document presents deployment scenarios for supporting IP 46 multicast over distributed mobility management (DMM) architecture, 47 which considers the separation of the control and the data planes. 48 This document describes three main use cases of IP multicast 49 deployments over DMM depending on the placement of control and data 50 plane functional entities. 52 Table of Contents 54 1. Introduction ................................................ 2 55 2. Functional Decomposition..................................... 3 56 3. Terminology ................................................. 3 57 4. Use Cases Analysis .......................................... 4 58 4.1. Use Case 1 ............................................. 5 59 4.2. Use Case 2 ............................................. 6 60 5. Forwarding Policy Configuration for Multicast ................8 61 6. Security Considerations...................................... 9 62 7. IANA Considerations ......................................... 9 63 8. References .................................................. 9 64 8.1. Normative References.................................... 9 65 8.2. Informative References.................................. 9 66 9. Acknowledgments ..............................................9 68 1. Introduction 70 Distributed mobility management is a new paradigm to solve current 71 problems of centralized mobility management, such as a single point 72 of failure, non-optimal routing [RFC7333]. 74 IP multicast is an efficient content distribution mechanism which is 75 designed with the IP mobility to bring new user experience and 76 reduce bandwidth cost. In the [RFC7333], one requirement for DMM is 77 to enable multicast solutions to avoid the inefficiency in the 78 multicast traffic delivery. 80 Existing solutions for supporting multicast in DMM are bi- 81 directional tunnel [TUNNEL] and direct routing [ROUTING]. These 82 solutions focus on the placement of MLD proxy and multicast router 83 functions into the Mobility Access Router. 85 The current architecture of the DMM is being changed to employ the 86 concept of data and control plane separation. The data plane nodes 87 are configured by the control nodes via Forwarding Policy 88 Configuration protocol, as defined in [I-D.ietf-dmm-fpc-cpdp]. The 89 several deployment scenarios were presented in 90 [I-D.wt-dmm-deployment-model]. 92 However, there is no work until now, mentioning about multicast 93 support in such new DMM architectures. Therefore, this document 94 presents possible deployment scenarios, which support multicast 95 listener in the DMM architectures based on the concept of the data 96 and control planes separation. 98 2. Functional Decomposition 100 Two options for deploying the multicast over conventional 101 distributed mobility management (i.e. without the control and data 102 plane separation) are MLD Proxy and Multicast router [RFC3810] 103 [RFC4605]. This section decomposes functions of MLD Proxy and 104 Multicast router that are required to deliver the multicast traffic 105 with the respect to the concept of data and control planes 106 separation. Below table is represented about functional description 107 for supporting multicast. 109 +------------------------------------------------------------------+ 110 | Function | Description |C/D Plane| 111 +------------------------------------------------------------------+ 112 |Run | Used to join/leave the multicast tree | C-Plane | 113 |multicast | infrastructure to receive the multicast | | 114 |routing | data | | 115 |protocol | | | 116 +------------------------------------------------------------------+ 117 |MLD | Used to notify about the multicast group | C-Plane | 118 |membership | membership on the directly attached link | | 119 |report | | | 120 +------------------------------------------------------------------+ 121 |MLD | Used to discover multicast listeners on | C-Plane | 122 |Querier | the directly attached link | | 123 +------------------------------------------------------------------+ 124 |Membership | Used to maintain the merger of multicast | C-Plane | 125 |database | subscriptions | | 126 +------------------------------------------------------------------+ 127 |Multicast | Used to forward multicast packets based on| D-Plane | 128 |forwarding | the multicast subscriptions over each link| | 129 +------------------------------------------------------------------+ 130 Figure 1: Functional descriptions for supporting multicast 132 3. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC-2119 [RFC2119]. 138 This document uses the terminology defined in [RFC4605] and 139 [RFC3810]. Also, new entities are defined relying on the concept of 140 data and control planes separation and the functional decomposition. 141 Terminologies are similarly named as DMM functions defined in 142 [wt-dmm-deployment-model]. 144 - CMA (Control plane Multicast Anchor): CMA consists of the control 145 plane functions of the multicast router (Multicast Anchor). CMA is 146 responsible for joining the multicast tree. 147 - DMA (Data plane Multicast Anchor): DMA is the topological anchor 148 point for multicast channels, subscribed by the MN. DMA provides 149 packet treatment functions, such as packet forwarding, packet 150 encapsulation. The DMA can be configured by the CMA via Forwarding 151 Policy Configuration (FPC) protocol 152 - CMN (Control plane Multicast Node): CMN is responsible for 153 control plane functions of MLD-Proxy (multicast node) as described 154 in the previous section. 155 - DMN (Data plane Multicast Node): DMN is located at the first-hop 156 router where the MN is attached. The DMN has the protocol 157 interface with the CMN for configuration. 159 4. Use Cases Analysis 161 Following defined terminologies, we adjust these entities into 162 current centralized approaches which support multicast in 163 centralized mobility architecture. Current multicast support 164 approaches in centralized mobility architecture are defined in 165 [RFC6224] and [RFC7028]. Since both approaches are based on PMIPv6, 166 we use DMM entities which are mapped with PMIPv6 entities. Following 167 table identifies the potential mapping of DMM function defined in 168 [I-D.wt-dmm-deployment-model]. 170 +===========+==========+==========+==========+==========+==========+ 171 | FUNCTION | PMIPv6 | MIPv6 | IPsec | 3GPP | Broadband| 172 +===========+==========+==========+==========+==========+==========+ 173 | Home-CPA | LMA-CPA | HA-CPA | IKE-CPA | PGW-CPA | BNG-CPA | 174 +-----------+----------+----------+----------+----------+----------+ 175 | Home-DPA | LMA-DPA | HA-DPA | IKE-DPA | PGW-DPA | BNG-DPA | 176 +-----------+----------+----------+----------+----------+----------+ 177 |Access-CPN | MAG-CPN | - | - | SGW-CPN | RG-CPN | 178 +-----------+----------+----------+----------+----------+----------+ 179 |Access-DPN | MAG-DPN | - | - | SGW-DPN | RG-DPN | 180 +-----------+----------+----------+----------+----------+----------+ 182 Figure 2: Mapping of DMM functions 184 For supporting multicast, several entities are already defined in 185 IETF and 3GPP. Following table idientifies the potential mapping of 186 multicast functions with our defined terminologies. 188 +===========+=============+======================+ 189 | FUNCTIONS | 3GPP | IETF | 190 +===========+=============+======================+ 191 | CMA | BMSC-CPA | Multicast Router-CPA | 192 +-----------+-------------+----------------------+ 193 | DMA | BMSC-DPA | Multicast Router-DPA | 194 +-----------+-------------+----------------------+ 195 | CPN | MBMS-GW-CPN | Multicast Proxy-CPN | 196 +-----------+-------------+----------------------+ 197 | DPN | MBMS-GW-DPN | Multicast Proxy-DPN | 198 +-----------+-------------+----------------------+ 200 Figure 3: Mapping of Multicast functions 202 4.1. Use Case 1 204 First use case is based on [RFC 6224], which LMA has a role of 205 both unicast and multicast anchor in PMIPv6 domain. In that 206 approaches, LMA transposes any MLD message from a MAG into the 207 multicast routing infrastructure and creates appropriate multicast 208 forwarding states at its tunnel interface between LMA-to-MAG. 209 Additionally, LMA acts as a MLD Querier. MAG acts as MLD proxy 210 which forwards multicast traffic and initiates related signaling 211 down to the appropriate MN. In this approach, most importantly, 212 mobility entities are tightly coupled with multicast support 213 functions. In other words, there is no additional entities to 214 support multicast besides adding more functions into their PMIPv6 215 entities. 217 Considering DMM deployment scenario with separation of control and 218 data plane, two possible deployment models are existed. First 219 model is that separated control and user plane model presented in 220 Figure 4. In this model, the control plane function of multicast 221 anchor is handled by the CMA and where as the data plane function 222 is handled by DMA. The control plane function of the MLD proxy is 223 handled by CMN and where as the data plane function is handled by 224 DMN. Between control plane nodes, CMA and CMN, multicast related 225 signaling messages are used to manage multicast group and make 226 upstream/downstream interfaces to appropriate nodes. After a 227 mobile node wants to join specific multicast channel and all 228 related signaling messages are exchanged between control plane 229 functions, control plane functions interact with their 230 corresponding data plane nodes for the multicast traffic 231 forwarding state management. 233 ===================== 234 == === 235 = Multicast Infrastructure = 236 ========================= 237 | 238 +================+ FPC +================+ 239 | CMA + Home-CPA |-------| DMA + Home-DPA | 240 +================+ +================+ 241 | | 242 | MLD/IGMP | UP {Tunnel/Route} 243 | | 244 +==================+ FPC +==================+ 245 | CMN + Access-CPN |-----| DMN + Access-DPN | 246 +==================+ +==================+ 248 Figure 4: Separated control and user plane model with 249 multicast supports 251 Another possible deployment model is that centralized control 252 plane model presented in Figure 5. In this model, the control 253 plane functions of multicast anchor and MLD proxy are combined 254 into a combined control function of DMM. There is no signaling 255 messages between multicast anchor and MLD proxy. Between the 256 control plane and the data plane nodes, FPC protocol defined 257 [I-D.ietf-dmm-fpc-cpdp] can be used to managing forwarding states 258 of multicast traffic. 260 ===================== 261 == === 262 = Multicast Infrastructure = 263 ======================== 264 | 265 +================+ FPC +================+ 266 | CMA + Home-CPA |-------| DMA + Home-DPA | 267 | | +================+ 268 | | | 269 | | | UP {Tunnel/Route} 270 | | | 271 | | FPC +=================+ 272 |CMN + Access-CPN|-------| DMN + Access-DPN| 273 +================+ +=================+ 275 Figure 5: Centralized control plane model with multicast supports 277 4.2. Use Case 2 279 In [RFC 7028], it separates multicast function into PMIPv6 280 entities. Following that document, two approaches are proposed; 281 Multicast Tree Mobility Anchor (MTMA) solution and Direct routing 282 solution. In the MTMA solution, the MTMA is dedicated to multicast 283 traffic and used to get access to remote multicast content. That 284 is, the MTMA acts as multicast router or MLD proxy. When MN attach 285 to this architecture and receive both unicast and multicast 286 traffic, since the MAG connects to both unicast anchor (e.g. LMA) 287 and multicast anchor (e.g. MTMA), MN can simultaneously receive 288 both unicast and multicast traffic from same MAG. For that, the 289 MAG should support MLD proxy function in [RFC4605] and maintain 290 its upstream/downstream interfaces to appropriate nodes. For 291 multicast traffic, a multicast tunnel is established between MAG 292 and MTMA. 294 Considering DMM deployment scenario with separation of control and 295 data plane, MTMA approach can be described as Figure 6. In this 296 figure, all multicast functions are deployed separately from 297 unicast DMM function except access data plane function. In the 298 access data plane, it maintains two forwarding states; unicast 299 traffic forwarding states and multicast forwarding states. Unicast 300 forwarding states are anchored by Home-DPA and multicast 301 forwarding states are anchored by DMA. The control plane functions 302 of DMM can be centralized and also the control functions of 303 multicast can be centralized. 305 ===================== 306 == === 307 +=================+ = Multicast Infrastructure = 308 | Unicast Traffic | ======================== 309 +=================+ | . 310 | | . 311 | | . MLD/IGMP 312 +======+ +======+ | . 313 | Home |_FPC_| Home | +=====+ +=====+ 314 | -CPA | | -DPA | | DMA |---FPC--| CMA | 315 +======+ +======+ +=====+ +=====+ 316 | || || | 317 |PMIP/ || UP || UP | MLD/IGMP 318 |GTP ||{Tunnel/route} ||{Tunnel/route}| 319 +======+ +======================+ +=====+ 320 |Access|_FPC_| Access-DPN + DMN |____FPC__| CMN | 321 | -CPN | | | +======+ 322 +======+ +======================+ 324 Figure 6: MTMA solution model with separated control 325 and data plane 327 Direct routing solution in [RFC7028] allows the MAG to directly 328 connect to a multicast router. In this case, there is no multicast 329 anchor and the MAG acts as the MLD proxy. For multicast traffic, 330 the upstream interface of the MLD proxy instance has been 331 configured pointing to a multicast router internal to the PMIPv6 332 domain. The MAG does not manage multicast group information. It 333 just maintain upstream/downstream interface and performs MLD proxy 334 operations defined in [RFC4605]. 336 Considering DMM deployment scenario with separation of control and 337 data plane, direct routing approach can be described as Figure 7. 338 In this figure, the multicast anchor function and the multicast 339 access function are combined into single control/data plane nodes. 340 In the access data plane node, it maintains both unicast and 341 multicast forwarding states and interfaces to the appropriate 342 nodes. Similar with the MTMA solution, the control plane functions 343 of DMM or the control functions of multicast can be centralized. 345 ===================== 346 == === 347 + ================+ = Multicast Infrastructure = 348 | Unicast Traffic | ========================= 349 +=================+ | 350 | | 351 | | 352 +======+ +======+ | 353 | Home |_FPC_| Home | +===========+ 354 | -CPA | | -DPA | | Legacy MR | 355 +======+ +======+ +===========+ 356 | || || . 357 |PMIP/ || UP || UP . MLD/IGMP 358 |GTP || {Tunnel/Route} || . 359 +========+ +=========================+ +===========+ 360 | Access |_FPC_| Access-DPN |___FPC__| CMA + CMN | 361 | -CPN | | DMA+DMN | +===========+ 362 +========+ +=========================+ 364 Figure 7: Direct routing solution model with separated control 365 and data plane 367 5. Forwarding Policy Configuration for Multicast 369 For communicating between DMM control plane and data plane 370 function, Forwarding Policy Configuration (FPC) protocol is 371 proposed in [I-D.ietf-dmm-fpc-cpdp]. FPC protocol enables the 372 configuration of any data plane node and type by the abstraction 373 of configuration details and the use of common configuration 374 semantics. In recent document gives detail protocol attributes and 375 operation parameters. Considering multicast support, we need to 376 make sure that the current FPC protocol is resolved to create a 377 forwarding rules for multicast traffic. For example, we can add 378 identifier which represent multicast source address or add 379 attribute for specific multicast group. 381 6. Security Considerations 383 T.B.D 385 7. IANA Considerations 387 T.B.D 389 8. References 391 8.1. Normative References 393 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC7333] H. Chan, D. Liu, P. Seite, H. Yokota, and J. Korhonen, 397 "Requirements for Distributed Mobility Management", IETF 398 RFC 7333, Aug. 2014. 400 [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery 401 Version 2 (MLDv2) for IPv6", IETF RFC 3810, June 2004. 403 [RFC4605] B. Fenner, H. He, B. Haberman, H. Sandick, "Internet Group 404 Management Protocol (IGMP)/ Multicast Listener Discovery 405 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 406 IETF RFC 4605, Aug. 2006. 408 8.2. Informative References 410 [TUNNEL] S. Figueiredo, S. Jeon, and R. L. Aguiar, "IP Multicast Use 411 Cases and Analysis over Distributed mobility 412 Management",draft-sfigueiredo-multimob-use-case-dmm-03 413 (expired April 2013). 415 [ROUTING] Y. Kim, T-X. Do, and Y. Kim, "Direct Routing for Mobile 416 Multicasting in Distributed Mobility Management Domain", 417 Proc. INTERNET 2013 pp. 1-3. 419 [I-D.ietf-dmm-fpc-cpdp] M. Liebsch, S. Matsushima, S. Bundavelli, D. 420 Moses, "Protocol for Forwarding Policy Configuration 421 (FPC)", draft-ietf-dmm-fpc-cpdp-03 (work in progress), 422 March 2016. 424 [I-D.wt-dmm-deployment-model] S. Gundavelli, "DMM Depolyment Models 425 and Architectural Considerations", draft-wt-dmm-deployment 426 -models-00 (work in progress), April 2016. 428 [RFC6224] Schmidt, T., Waehlisch, M., Krishnan, S., "Base Deployment 429 for Multicast Listener Support in Proxy Mobile IPv6 430 (PMIPv6) Domains", RFC 6224, April 2011. 432 9. Acknowledgments 433 Authors' Addresses 435 Kyoungjae Sun 436 Soongsil University 437 369, Sangdo-ro, Dongjak-gu 438 Seoul 156-743, Korea 440 Email: gomjae@ssu.ac.kr 442 Truong-Xuan Do 443 Soongsil University 444 369, Sangdo-ro, Dongjak-gu 445 Seoul 156-743, Korea 447 Email: xuan@dcn.ssu.ac.kr 449 Younghan Kim 450 Soongsil University 451 369, Sangdo-ro, Dongjak-gu 452 Seoul 156-743, Korea 454 Email: younghak@dcn.ssu.ac.kr