idnits 2.17.1 draft-zhang-pim-muiimp-02.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 11) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 123 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), 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 == Line 18 has weird spacing: '...quently updat...' == Line 95 has weird spacing: '... proxy may ...' == Line 96 has weird spacing: '...pecific scena...' == Line 107 has weird spacing: '... proxy in d...' == Line 111 has weird spacing: '... In this ...' == (14 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 2) If there exists the same IGMP/MLD subscription which has already been subscribed by other downstream multicast listeners, the proxy device SHOULD not initiate extra IGMP/MLD subscription. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 3) If there exist IGMP/MLD subscriptions which have already included the received IGMP/MLD subscription, the proxy device SHOULD not initiate extra IGMP/MLD subscription. -- The document date (May 25, 2015) is 3252 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 400 looks like a reference -- Missing reference section? '2' on line 404 looks like a reference -- Missing reference section? 'RFC2119' on line 30 looks like a reference -- Missing reference section? '3' on line 408 looks like a reference -- Missing reference section? '4-5' on line 90 looks like a reference -- Missing reference section? '6' on line 420 looks like a reference -- Missing reference section? '7' on line 424 looks like a reference -- Missing reference section? '8' on line 428 looks like a reference -- Missing reference section? '4' on line 413 looks like a reference -- Missing reference section? '5' on line 417 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group Hong-Ke Zhang 3 Internet Draft Shuai Gao 4 Intended status: Standards Track Beijing Jiaotong University 5 Expires: November 24, 2015 T C.Schmidt 6 HAW Hamburg 7 Bo-hao Feng 8 Fei Song 9 Beijing Jiaotong University 10 May 25, 2015 12 Multi-Upstream Interfaces IGMP/MLD Proxy 13 draft-zhang-pim-muiimp-02.txt 15 Abstract 17 In this document, followed by the idea mentioned in [1] and 18 subsequently updated in [2], an IGMP/MLD proxy with multiple 19 upstream interfaces called MUIIMP is proposed and analyzed. The 20 MUIIMP inherits the basic rule of the IGMP/MLD proxy but extends 21 with multiple upstream interfaces. To avoid data redundancy, each 22 upstream interface of an MUIIMP device MUST NOT send or subscribe to 23 the same data simultaneously. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with 34 the provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as 44 reference material or to cite them other than as "work in progress". 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on November 24, 2015. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction....................................................3 72 2. Terminology.....................................................3 73 3. MUIIMP Operation................................................4 74 3.1. The selection of default upstream interface................5 75 3.2. Report of downstream subscriptions on upstream interfaces..5 76 3.3. Handover of the upstream interface.........................6 77 4. Use Case in PMIPv6 Environment..................................6 78 5. Security Considerations.........................................9 79 5. IANA Considerations.............................................9 80 6. References......................................................9 81 Authors' Addresses................................................11 82 Acknowledgment....................................................11 84 1. Introduction 86 RFC 4605 [3] specifies an IGMP/MLD proxy mechanism for forwarding 87 based solely upon IGMP/MLD membership information in scenarios where 88 multicast routing is not available. According to RFC 4605, an 89 IGMP/MLD proxy performs the router portion of the IGMP/MLD protocol 90 [4-5] on its downstream interfaces, and the host portion of the 91 IGMP/MLD protocol on its single upstream interface. 93 The IGMP/MLD proxy mechanism can effectively expand the scope of the 94 multicast and greatly simplify the implementation of edge devices. 95 However, the IGMP/MLD proxy may appear inefficiency in some 96 specific scenarios due to the limitation of single upstream 97 interface. For example, in PMIPv6 multicast environment, multiple 98 IGMP/MLD proxy instances need to be deployed at the MAG in RFC 6224 99 [6], which may lead to tunnel convergence problem. In addition, 100 there are also requirements to extend the IGMP/MLD proxy to support 101 multiple upstream interfaces with the emergence of multi-homing. 103 It is noted that the idea about multiple upstream interfaces for 104 IGMP/MLD proxy was first put forward in the draft [1] to improve the 105 performance of multicast source mobility. Subsequently, the Multimob 106 working group draft [2] describes the multi-upstream interfaces 107 IGMP/MLD proxy in detail. Considering the multiple upstream 108 interfaces extension is not only required for mobile multicast 109 sources scenarios, this document is presented here. 111 In this document, an IGMP/MLD proxy with multiple upstream 112 interfaces called MUIIMP is proposed and described. The MUIIMP 113 inherits the basic rule of the IGMP/MLD proxy but extends with 114 multiple upstream interfaces. To avoid data redundancy, each 115 upstream interfaces of an MUIIMP device MUST NOT send or subscribe 116 to the same data simultaneously. Additionally, the MUIIMP is 117 designed to support local multicast listeners and senders. 119 2. Terminology 121 Upstream Interface: A proxy device's interface in the direction of 122 the root of the tree. 124 Downstream Interface: Each of a proxy device's interfaces that is not 125 in the direction of the root of the multicast tree. 127 Default Upstream Interface: An upstream interface which is by 128 default associated with each downstream node subscribing or sending 129 specific channel (group address prefix) or special multicast state. 131 3. MUIIMP Operation 133 The MUIIMP not only inherits the basic rule of the IGMP/MLD proxy 134 but also extends with multiple upstream interfaces. A MUIIMP device 135 has one or more upstream as well as downstream interfaces, which may 136 be any type interfaces, including physical or logical interfaces. 138 The MUIIMP performs the router portion of the IGMP/MLD protocol on 139 its downstream interfaces, and the host portion of IGMP/MLD on its 140 upstream interfaces. The MUIIMP device MUST NOT perform the router 141 portion of IGMP/MLD on its upstream interfaces. 143 The MUIIMP device maintains a database for multicast listeners 144 consisting of the merger of all subscriptions on any downstream 145 interface. To avoid the redundant multicast traffic, the proxy device 146 should initiate unique traffic subscriptions. Besides, a policy list 147 recording the default upstream interface for the downstream nodes is 148 held for the selection of the upstream interface. 150 According to the role of the downstream nodes, the operation process 151 of the MUIIMP device is described as follows: 153 1) Multicast listener on the downstream interface 155 Multicast listener reports are group-wise aggregated by the IGMP/MLD 156 proxy. The aggregated report is issued to the upstream interface 157 based on the subscriptions as well as the policy list. When 158 receiving the IGMP/MLD subscriptions on the downstream interface, 159 the MUIIMP decides whether to send the IGMP/MLD membership reports 160 on the corresponding default upstream interface based on the 161 membership database. The detailed membership subscriptions lookup 162 and report decisions will be discussed in Section 3.2. 164 When receiving packets on its upstream interfaces, the MUIIMP 165 forwards the traffic to all the downstream interfaces based upon the 166 downstream interfaces' subscriptions. 168 2) Multicast source on the downstream interface 170 Once receiving packets on its downstream interface, the MUIIMP 171 forwards the traffic to the corresponding default upstream interface 172 as well as all the downstream interfaces other than the incoming 173 interface based upon the downstream interfaces' subscriptions. 175 The (first) multicast router(s) operating multicast routing protocol 176 like PIM-SM [7] connected to the outside multicast domain should be 177 configured to treat the multicast source inside the MUIIMP domain 178 being directly connected. Otherwise, it will discard the data due to 179 the failure of the direct connection check. 181 3.1. The selection of default upstream interface 183 Typically, the choice of the default upstream interface is based on 184 the policy list maintained at the MUIIMP. 186 The expression of the policy list is like below: 188 (node prefix, multicast group address/multicast state, upstream 189 interface) 191 Here, node prefix represents the address prefix of the node on the 192 downstream interface that may be a multicast listener or multicast 193 source. The multicast group address indicates the channel that the 194 multicast listener is subscribing or the multicast source is 195 publishing, while the multicast state is only valid for listeners 196 indicating the state about both multicast source and multicast group 197 they are subscribing. 199 In other words, in the MUIIMP, the multicast group address/multicast 200 state and the node prefix will act as rules to select the default 201 upstream interface. Alternate configurations (e.g., the MAG-LMA 202 tunnel interface in the PMIPv6 environment) MAY be applied. 204 3.2. Report of downstream subscriptions on upstream interfaces 206 In order to avoid the redundant multicast traffic, the proxy device 207 MUST NOT send the same multicast subscription record on different 208 upstream interfaces simultaneously. specifically, we recommend the 209 following rules when receiving an IGMP/MLD subscription on the downstream 210 interface. 212 1) If the received IGMP/MLD subscription is new and has not been 213 subscribed by other downstream multicast listeners, the proxy 214 device SHOULD initiate the IGMP/MLD subscription on the 215 corresponding default upstream interface. 217 2) If there exists the same IGMP/MLD subscription which has already 218 been subscribed by other downstream multicast listeners, the proxy 219 device SHOULD not initiate extra IGMP/MLD subscription. 221 3) If there exist IGMP/MLD subscriptions which have already 222 included the received IGMP/MLD subscription, the proxy device 223 SHOULD not initiate extra IGMP/MLD subscription. 225 4) If there exist overlapping subsets between the received IGMP/MLD 226 subscription and the current IGMP/MLD subscriptions, the proxy 227 device SHOULD initiate the IGMP/MLD subscription on the 228 corresponding default upstream interface excluding the overlapping 229 subsets that have been subscribed before. 231 All subscriptions sent on the same upstream interface SHOULD be 232 merged according to the merging rule specified in RFC 4605. In 233 addition, the local multicast source should be excluded in the final 234 subscriptions to avoid replicated multicast traffic from outside. 236 3.3. Handover of the upstream interface 238 If an upstream interface fails for some reason, such as the deletion 239 of the tunnel interface in mobile environment, the handover of the 240 upstream interface should be performed. Generally, all the 241 subscriptions sent on the previous invalid upstream interface are 242 transferred to the new valid upstream interfaces which are chosen 243 among the default upstream interfaces of the corresponding 244 downstream nodes. The choice may be made based on the predefined 245 policy (e.g., the interface priority, the number of listeners, the 246 lowest IP address). An alternative may be applied by the MUIIMP 247 device itself according to the traffic monitored or some strategies 248 configured by the operator. 250 4. Use Case in PMIPv6 Environment 252 With the development of the Mobile IP-like protocols (such as, MIPv6, 253 PMIPv6 and DMM), combining multicast with mobile protocols has been 254 widely discussed. One way is to deploy traditional IGMP/MLD proxy at 255 the gateway of mobile nodes [2,6], but there are some drawbacks like 256 the detour routing and tunnel convergence problem. MUIIMP can be 257 used to optimize the behavior of multicast mobility as well as to 258 support the multi-homing/multi-interface for both the mobile nodes 259 and the fixed nodes. Requirements for an IGMP/MLD proxy with 260 multiple interfaces have been proposed in the draft [8], covering a 261 variety of application scenarios. In this section, a use case in 262 PMIPv6 environment is presented to illustrate how the MUIIMP works. 264 The basic deployment of MUIIMP in PIMPv6 networks is shown in Figure 265 1, in which there are three mobile nodes (MNs) belonging to 266 different LMAs and attaching under the same MAG. Let's adopt the 267 scheme in RFC 6224 [6] and assume that the default upstream 268 interface for each MN in Figure 1 is the tunnel interface from the 269 MAG to the corresponding LMA. In real environment, the MN may also 270 express its preference on upstream interface selection by other 271 means. Detailed multicast related information of each MN is depicted 272 in Table 1. We assume that MN1, MN2 and MN3 attach at the MAG in 273 sequence. 275 +-------------------------+ 277 | Multicast Domain | ------------ 279 +-------------------------+ | 281 / | \ | 283 +-------+ +-------+ +-------+ | 285 | LMA-1 | | LMA-2 | | LMA-3 | | 287 +-------+ +-------+ +-------+ | 289 \\ || // | 291 \\ || // | 293 \\ ||IF-B // | 295 \\ || // | 297 \\ || // | 299 IF-A \\ || // IF-C | 301 +---------+ +-----+ 303 MUIIMP | M A G | -----IF-D-------- | M R | 305 +---------+ +-----+ 307 / | \ 309 MN-1 MN-2 MN-3 311 Figure 1: The basic deployment of MUIIMP in PIMPv6 networks 312 +----+-----+--------+---------------------+-----------------+ 314 |Node| LMA | Type | Multicast Channel | Default U-IF | 316 +----+-----+--------+---------------------+-----------------+ 318 | | | | (m1,EXCLUDE,{}) | | 320 | | | |---------------------| | 322 |MN-1|LMA-1|Receiver| (m2,EXCLUDE,{}) | IF-A | 324 | | | |---------------------| | 326 | | | | (m3,INCLUDE,{a}) | | 328 +----+-----+--------+---------------------+-----------------+ 330 | | | | (m1,EXCLUDE,{}) | | 332 | | | |---------------------| | 334 |MN-2|LMA-2|Receiver| (m2,INCLUDE,{b}) | IF-B | 336 | | | |---------------------| | 338 | | | | (m3,EXCLUDE,{}) | | 340 +----+-----+--------+---------------------+-----------------+ 342 | | |Receiver| (m1,EXCLUDE,{}) | | 344 |MN-3|LMA-3|--------|---------------------| IF-C | 346 | | | Source | m2 | | 348 +----+-----+--------+---------------------+-----------------+ 350 Table 1: Detailed information of each MN 352 The operation of the MUIIMP is described as follows: 354 1) MN1 firstly subscribes (m1,EXCLUDE,{}), (m2,EXCLUDE,{}) and 355 (m3,INCLUDE,{a}), the MUIIMP initiates the corresponding IGMP/MLD 356 subscription through the IF-A. 358 2) When MN2 (as well as MN3) subscribes (m1,EXCLUDE,{}), since there 359 exists the same IGMP/MLD subscription through the IF-A, the MUIIMP 360 will not initiate extra IGMP/MLD subscription. 362 3) When MN2 subscribes (m2,INCLUDE,{b}), since (m2,EXCLUDE,{}) has 363 been subscribed, the MUIIMP does not initiate extra IGMP/MLD 364 subscription. 366 4) When MN2 subscribes (m3,EXCLUDE,{}), since (m3,INCLUDE,{a}) has 367 been subscribed through the IF-A, the MUIIMP will send IGMP/MLD 368 subscription of (m3,EXCLUDE,{a}) through the IF-B. 370 5) When MN3 acts one of the sources for m2, traffic from MN3 are 371 transmitted to the downstream interface towards MN1 as well as the 372 IF-C. Besides, IGMP/MLD subscription of (m2,EXCLUDE,{}) sent by 373 the MUIIMP through the IF-A is modified as (m2,EXCLUDE,{MN3}). 375 6) When MN1 hands over, the tunnel interface IF-A will be deleted 376 and the MUIIMP needs to deal with this scenario because the 377 subscriptions of MN2 and MN3 was sent through the IF-A previously. 378 Here, IF-B and IF-C, as the default upstream interfaces of MN2 and 379 MN3, are two candidate upstream interfaces for m1 subscription. 380 Then, the predefined customized policy can be used to select a new 381 U-IF from the candidate upstream interfaces. As for 382 (m2,INCLUDE,{b}) and (m3,EXCLUDE,{}), they are only subscribed by 383 the MN2, thus, the IF-B will be selected as the new U-IF for them. 385 It is worth noting that the fixed node (FN) connecting to the MAG can 386 be regarded as an MN that never handovers. The default upstream 387 interface of FN can be an interface adjacent to multicast domain, 388 like the IF-D in Figure 1. 390 5. Security Considerations 392 This document does not contain any security considerations. 394 6. Security Considerations 396 There are presently no IANA considerations with this document. 398 7. References 400 [1] H. Zhang, Z. Yan, S. Gao, L. Wang, Q. Wu and H. Li, "Multicast 401 Source Mobility Support in PMIPv6 Network", draft-zhang- 402 multimob-msm-03, July 2011. 404 [2] T C. Schmidt, S. Gao, H. Zhang and M. Waehlisch, "Mobile 405 Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) 406 Domains", draft-ietf-multimob-pmipv6-source-03, February 2013. 408 [3] B. Fenner, H. He, B. Haberman and H. Sandick, "Internet Group 409 Management Protocol (IGMP) / Multicast Listener Discovery 410 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 411 4605, August 2006. 413 [4] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 414 Thyagarajan, "Internet Group Management Protocol, Version3", 415 RFC 3376, October 2002. 417 [5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 418 (MLDv2) for IPv6", RFC 3810, June 2004. 420 [6] T. Schmidt, M. Waehlisch and S. Krishnan, "Base Deployment 421 forMulticast Listener Support in Proxy Mobile IPv6 (PMIPv6) 422 Domains", RFC 6224, April 2011. 424 [7] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 425 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 426 Protocol Specification (Revised)", RFC 4601, August 2000. 428 [8] LM. Contreras, CJ. Bernardos and JC. Zuniga, "Extension of the 429 MLD proxy functionality to support multiple upstream 430 interfaces", draft-contreras-multimob-multiple-upstreams-01, 431 February 2013. 433 Authors' Addresses 435 Hong-Ke Zhang 436 National Engineering Lab for NGI Interconnection Devices 437 Beijing Jiaotong University, Beijing, China 439 Email:hkzhang@bjtu.edu.cn 441 Shuai-Gao 442 National Engineering Lab for NGI Interconnection Devices 443 Beijing Jiaotong University, Beijing, China 445 Email:shgao@bjtu.edu.cn 447 Thomas C. Schmidt 448 HAW Hamburg 449 Berliner Tor 7 450 Hamburg 20099 451 Germany 453 Email: schmidt@informatik.haw-hamburg.de 454 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 456 Bo-Hao Feng 457 National Engineering Lab for NGI Interconnection Devices 458 Beijing Jiaotong University, Beijing, China 460 Email:11111021@bjtu.edu.cn 462 Fei-Song 463 National Engineering Lab for NGI Interconnection Devices 464 Beijing Jiaotong University, Beijing, China 466 Email:fsong@bjtu.edu.cn 468 Acknowledgment 470 Funding for the RFC Editor function is currently provided by the 471 Internet Society.