idnits 2.17.1 draft-kjsun-dmm-multicast-anchoring-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 1 longer page, the longest (page 8) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7429]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 2726 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7028' is mentioned on line 213, but not defined -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DMM Working Group Kyoungjae Sun 2 Internet Draft Younghan Kim 3 Intended status: Informational Soongsil University 4 Expires: April 2017 October 31, 2016 6 Multicast Anchoring in DMM 7 draft-kjsun-dmm-multicast-anchoring-04.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute 16 working documents as Internet-Drafts. The list of current Internet- 17 Drafts is at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on April 30, 2017. 26 Copyright Notice 28 Copyright (c) 2015 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with 36 respect to this document. Code Components extracted from this 37 document must include Simplified BSD License text as described in 38 Section 4.e of the Trust Legal Provisions and are provided without 39 warranty as described in the Simplified BSD License. 41 Abstract 43 In this draft, we define multicast support functions in a 44 Distributed Mobility Management (DMM) environment. Based on the 45 decomposed mobility management functions in [RFC7429], each defined 46 multicast support function can be located and operated with DMM 47 functions. 49 Table of Contents 51 1. Introduction ................................................ 2 52 2. Conventions and Terminology ................................. 3 53 3. Multicast Support Functions in DMM .......................... 3 54 3.1. Multicast Anchoring Function (Multicast AF) ............ 3 55 3.2. Multicast Group Management Function (Multicast GM) ..... 4 56 3.3. Multicast Forwarding Management Function (Multicast FM). 5 57 4. Deploying Multicast Functions into Current Approaches ....... 5 58 4.1. Distributed AM, LM, and FM : All-in-One ................ 6 59 4.2. Distributed AF-DP, LM and FM with centralized AF-CP .... 6 60 4.3. Distributed AF-DP and FM-DP with centralized AF-CP, LM, 61 and FM-CP ............................................. 6 62 5. Security Considerations ..................................... 6 63 6. IANA Considerations ......................................... 6 64 7. References .................................................. 7 65 7.1. Normative References ................................... 7 66 7.2. Informative References ................................. 8 67 8. Acknowledgments ............................................. 8 69 1. Introduction 71 Based on [RFC7333], a multicast solution in Distributed Mobility 72 Management (DMM) should be considered early in the process of 73 designing protocol and deployment models. Multicast support in DMM 74 should avoid inefficient methods, such as non-optimal forwarding or 75 tunnel convergence. 77 To support IP multicasting, we need several functions: a multicast 78 routing protocol, membership management, etc. When we consider 79 multicast support in DMM, we should determine how efficiently these 80 functions can be operated with the mobility management functions in 81 DMM. Possible use cases are already described in [Use Case for 82 Multicast DMM]. However, since current DMM research considers 83 control/data separation and functional decomposition, we need to 84 define multicast support functions following decomposed DMM anchor 85 functions and operate with them. 87 In this draft, we define multicast mobility management functions 88 that enable us to deploy the DMM functions defined in [RFC7429]. We 89 define multicast mobility management functions in a similar way 90 because it is easier to deploy multicast mobility management 91 functions with DMM functions. 93 2. Conventions and Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [RFC2119]. 99 This document uses the terminology defined in [RFC5213], [RFC3810], 100 and [RFC4601]. New entities are defined by relying on the DMM 101 functions specified in [RFC7429]: 103 1. Anchoring Function (AF) is an allocation to a mobile node of an 104 IP address (e.g. Home Address (HoA))) or prefix (e.g. Home Network 105 Prefix (HNP)), topologically anchored by the advertising node. 107 2. Internetwork Location Management (LM) function manages and keeps 108 track of the internetwork location of an Mobile Node (MN). The 109 location information may be a binding of the advertised IP 110 address/prefix (e.g. HoA or HNP) to the MN's IP routing address, or 111 it may be a binding of a node that can forward packets destined for 112 the MN. 114 3. Forwarding Management (FM) function intercepts and forwards a 115 packet to/from the IP address/prefix assigned to the MN based on the 116 internetwork location information, either to the destination or to 117 some other network element that knows how to forward the packets to 118 their destinations. 120 3. Multicast Support Functions in DMM 122 In this chapter, we define functions to support multicasting in DMM 123 environment. The multicast support of previous mobility management 124 schemes (e.g., MIP and PMIP) deployed multicast router or MLD proxy 125 functions into their mobility entities (e.g., HA, LMA, and MAG). 126 According to the decomposition of previous mobility management 127 functions and considering the separation of the control and data 128 planes, a multicast support function also could be decompose into 129 several functions. 131 3.1. Multicast Anchoring Function (Multicast AF) 133 The multicast AF is defined as the anchoring point for multicast 134 subscribers in DMM domain. It means that all multicast traffic 135 from/to the DMM domain should be forwarded through the multicast AF. 137 Even if the multicast AF is anchor point for multicast traffic, it 138 does not mean that it is anchor point for unicast traffic. In other 139 words, this function could be deployed separately with the DMM AF 140 (e.g. MTMA solution in [RFC7028]), or combined with the DMM AF 141 (e.g. LMA in [RFC6224]). The multicast AF function provides 142 connectivity to the multicast infrastructure out of the DMM domain. 143 With the multicast AF, the network entity may be part of multicast 144 tree. That is, multicast AFs have a Tree Information Base (TIB). It 145 could be act role of MLD proxy function which generate MLD 146 membership report or user-defined subset in the its upstream 147 interface. In addition, the multicast AF acts as MLD Querier of 148 other MLD proxy instances located in DMM. 150 To support multicast listeners, the multicast AF collects MLD report 151 messages from mobile nodes or other entities (e.g. MLD proxy defined 152 in [RFC4605]). To provide an appropriate multicast subscription, the 153 multicast AF should join/prune multicast channels based on MLD 154 reports from the mobile nodes. To support the multicast sender, this 155 function forwards the source information of the sender to the 156 Rendezvous Point (RP) in multicast infrastructure. 158 The multicast AF could be separated into control-plane function and 159 data-plane function. In that case, the multicast AF Control Plane 160 (multicast AF-CP) is responsible of managing multicast tree 161 information and sharing source information through multicast 162 infrastructure. In other words, the multicast AF-CP acts as MLD 163 Querier for the DMM domain and MLD proxy for the multicast 164 infrastructure. For that, the multicast AF-CP maintains multicast 165 forwarding states at its corresponding downstream interface and 166 aggregated multicast membership states at its upstream interface. 167 The multicast Data Plane (multicast AF-DP) is responsible of 168 anchoring multicast data packets destined to the appropriate 169 subscribers in the DMM domain. It should forward multicast traffic 170 according to the multicast forwarding rules configured by the 171 multicast AF-CP. 173 3.2. Multicast Group Management Function (Multicast GM) 175 The multicast GM function is partially acts as MLD proxy which 176 manages multicast subscriber information. According to [RFC4605], 177 the MDL proxy devices maintain the membership database, which 178 considers merging all subscriptions on the downstream interface. The 179 membership database is presented a set of membership records, 180 multicast addresses, filter modes and source lists. The multicast GM 181 can maintain this database to support maintaining multicast 182 subscribers and multicast sources. For that, the multicast AF 183 function should create/delete/update membership database in the 184 multicast GM when the mobile node join or leave multicast channel. 186 Especially the multicast GM support mobility management easily by 187 requesting/updating subscriber information to this function. To 188 track location of mobile node, the multicast GM can deployed with 189 the location management function for DMM or can be extended flow 190 entry table in that. Using this function, all multicast subscribers 191 using the same multicast channel can be managed logically into the 192 same records wherever they attach to so that it can avoid tunnel 193 convergence problem. For example, even though two different nodes 194 subscribing same multicast channel from different access router are 195 moving to the same access node, the multicast GM can support to use 196 only one upstream interface to the same multicast source address by 197 updating its database and signaling with access node. Additionally 198 the multicast GM function can support optimal multicast routing 199 which sender and receiver are connected in the DMM domain. According 200 group database in the multicast GM and location information of 201 mobile nodes, in case that both sender and subscriber are located in 202 DMM domain, the multicast AF can forward multicast packets directly 203 to the access node where receiver is located in. 205 3.3. Multicast Forwarding Management Function (Multicast FM) 207 The multicast FM function manages forwarding states that is used to 208 forward packets from a source to a multicast group. Forwarding 209 states could be managed together or separately with unicast 210 forwarding states handled by the DMM FM function. In the former 211 case, the multicast FM function should be located at the same entity 212 where the DMM FM function is deployed (e.g. MAG function in 213 [RFC7028] and [RFC6224]). Basically the multicast FM function 214 maintains forwarding rules for routing from/to multicast 215 infrastructure and multicast subscribers, and additionally it can be 216 used specific forwarding mechanism such as PMIP or GRE tunneling 217 between multicast FM entities to support mobility. 219 The multicast FM function can be split into the control and data 220 plane. The multicast FM control plane (FM-CP) performs multicast 221 routing mechanism, makes forwarding rules for multicast traffic and 222 commands to the multicast FM data plane (FM-DP). For communication 223 between control and data plane, [dmm-fpc-cpdp] can be a method for 224 configuring forwarding policies. Rule of forwarding multicast 225 traffic can be considered in various way; a set of forwarding rules 226 of multicast subscribers or a single rule for each multicast 227 channel. 229 4. Considering multicast functions into current approaches 231 In this section, we consider how multicast functions can be merged 232 with DMM functional deployment model. In this section, based on DMM 233 functional deployment model in [sijeon-dmm-deployment-models], we 234 make use cases which combine or separate multicast functions as we 235 defined in previous section. 237 4.1. Distributed AM, LM, and FM : All-in-One 239 In this model, all of DMM anchor functions (AF, FM, LM) are combined 240 into one physical entity and such physical entities are distributed 241 at the edge of network. This model is presented in [seite-dmm-dma] 242 and [bernardos-dmm-pmip] To support multicast, the multicast anchor 243 functions may be deployed together in mobility router. Optionally, 244 in case of central LM usage, the multicast GM entity also may be 245 centralized. On the other hand, one or more multicast entity also 246 may be deployed independently as described in Figure 1. For example, 247 in case of deploying the multicast AF functions separately, 248 signaling messages for supporting mobility are required between 249 All-in-One DMM entity and the multicast AF. In this example, DMM 250 entity which includes the multicast FM function can perform as 251 multicast proxy. 253 +---------------------+ 254 | (LM + GM) | 255 +---------------------+ 256 ^ ^ 257 | | 258 v v 259 +--------------+ +------------------+ 260 | AF + LM + FM |(<-->)| M-AF + GM + M-FM | 261 +--------------+ +------------------+ 262 u m 263 u m 264 u m 265 +------+ 266 | MN | 267 +------+ 269 Figure 1: Multicast anchor for distributed AM, LM, and FM 271 4.2. Distributed AF-DP, LM and FM with centralized AF-CP 273 This model separates AF function into control and data plane. AF-DP 274 is distributed with LM and FM while AF-CP is centralized in a single 275 entity. In this model, centralized AF-CP can determine AF-DP based 276 on policy or network condition. As presented in [RFC7389], specific 277 routing protocol, such as GTP or GRE, can be used to forward MN's 278 traffic between AF-DPs. 279 To support multicast in this model, the multicast AF-CP may be co- 280 located where DMM AF-CP is placed. The multicast AF-DP may deploy 281 together with DMM AF-DP or separately. In the latter case, like as 282 Multimedia Broadcast Multicast Service (MBMS) gateway in 283 [3GPP TS 36.440], specific AF-DP gateway can be used. Centralized 284 AF-CP which includes multicast AF-CP can determine the multicast 285 AF-DP for forwarding multicast traffic of MN. Figure 2 is described 286 one options for adopting this model. 288 +---------------+ +------------------+ 289 | AF-CP (+ LM) |(<-->)| M-AF-CP (+ GM) | 290 +---------------+ +------------------+ 291 ^ ^ 292 (fpc) | | (fpc) 293 v v 294 +------------+ +------------+ 295 | AF-DP + | | M-AF-DP + | 296 | LM + FM | | GM + M-FM | 297 +------------+ +------------+ 298 u m 299 u m 300 +------+ 301 | MN | 302 +------+ 304 Figure 2: Multicast anchor for distributed AF-DP, LM and 305 FM with centralized AF-CP 307 4.3. Distributed AF-DP and FM-DP with centralized AF-CP, LM, and FM-CP 309 This model considers separation of FM-CP and FM-DP with separation 310 of AF-CP and AF-DP. In this model, forwarding path between AF-DP can 311 be provided more flexible. [matsushima-stateless-uplane-vepc] is 312 one example of this model. To support multicast in this model, 313 multicast FM-CP, AF-CP and GM may be implemented in centralized 314 control plane of DMM. In this case, signaling messages between 315 control and data plane can be used by extending messages which could 316 be used in normal DMM. For example, [dmm-fpc-cpdp] can be extended 317 to make rule for multicast traffic by defining group forwarding 318 rules. Figure 3 is described for this model. 320 +----------------------+ +--------------------------+ 321 | AF-CP + LM + FM-CP |(<-->)| M-AF-CP + GM + M-FM-CP | 322 +----------------------+ +--------------------------+ 323 ^ ^ 324 (fpc) | | (fpc) 325 v v 326 +---------+ +---------+ 327 | AF-DP | | M-AF-DP | 328 | FM-DP | | M-FM-DP | 329 +---------+ +---------+ 330 u m 331 u m 332 +------+ 333 | MN | 334 +------+ 336 Figure 3: Multicast anchor for distributed AF-DP and FM-DP 337 with centralized AF-CP, LM, and FM-CP 339 5. Security Considerations 341 TBD 343 6. IANA Considerations 345 TBD 347 7. References 349 7.1. Normative References 351 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 7.2. Informative References 356 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 357 Patil, B., "Proxy Mobile IPv6", RFC 5213, August 2008. 359 [RFC3810] Vida, R., Costa, L., "Multicast Listener Discovery Version 360 2 (MLDv2) for IPv6", RFC 3810, June 2004. 362 [RFC4601] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 363 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 364 Protocol Specification (Revised)", RFC 4601, August 2006. 366 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., Bernardos, CJ., 367 "Distributed Mobility Management: Current Practices and 368 Gap Analysis", RFC 7429, January 2015. 370 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., Korhonen, J., 371 "Requirements for Distributed Mobility Management", RFC 372 7333, August 2014. 374 [Use Case for Multicast DMM] Figueiredo, S., Jeon, S., Aguiar, R., 375 L., "IP Multicast Use Cases and Analysis over Distributed 376 Mobility Management", draft-sfigueiredo-multimob-use-case- 377 dmm-03, October 2012 (Expired). 379 [RFC4605] Fenner, B., He, H., Haberman, B., Sandick, H., "Internet 380 Group Management Protocol (IGMP) / Multicast Listener 381 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD 382 Proxying")", RFC 4605, August 2006. 384 [RFC6224] Schmidt, T., Waehlisch, M., Krishnan, S., "Base Deployment 385 for Multicast Listener Support in Proxy Mobile IPv6 386 (PMIPv6) Domains", RFC 6224, April 2011. 388 [dmm-fpc-cpdp] Liebsch, M., Matsushima, S., Gundavelli, S., Moses, 389 D., Bertz, L., "Protocol for Forwarding Policy 390 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-03 391 (work in progress), March 2016. 393 [sijeon-dmm-deployment-models] Jeon, S., Kim, Y., "Deployment Models 394 for Distributed Mobility Management", draft-sijeon-dmm- 395 deployment-models-02 (work in progress), March 2016. 397 [seite-dmm-dma] Seite, P., Bertin, P., and J. Lee, "Distributed 398 Mobility Anchoring" (Expired), draft-seite-dmm-dma-07, 399 February 2014. 401 [bernardos-dmm-pmip] Bernardos, C., Oliva, A., and F. Giust, "A 402 PMIPv6-based solution for Distributed Mobility 403 Management", draft-bernardos-dmm-pmip-06 (work in 404 progress), March 2016. 406 [RFC7389] Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. 407 Perkins, "Separation of Control and User Plane for Proxy 408 Mobile IPv6", RFC 7389, October 2014. 410 [3GPP TS 36.440] ETSI TS 36.440 v12.0.0, "LTE; Evolved Universal 411 Terrestrial Radio Access Network (E-UTRAN); General 412 aspects and principles for interfaces supporting 413 Multimedia Broadcast Multicast Service (MBMS) within 414 E-UTRAN (3GPP TS 36.440 version 12.0.0 Release 12)", 415 September 2014. 417 [matsushima-stateless-uplane-vepc] Matsushima, S. and R. Wakikawa, 418 "Stateless user-plane architecture for virtualized EPC 419 (vEPC)", draft-matsushima-stateless-uplane-vepc-06 (work 420 in progress), March 2016. 422 8. Acknowledgments 423 Authors' Addresses 425 Kyoungjae Sun 426 Soongsil University 427 369, SSnagdo-ro, Dongjak-gu 428 Seoul, Korea 430 Email: gomjae@dcn.ssu.ac.kr 432 Younghan Kim 433 Soongsil University 434 369, SSnagdo-ro, Dongjak-gu 435 Seoul, Korea 437 Email: younghak@ssu.ac.kr