idnits 2.17.00 (12 Aug 2021) /tmp/idnits2602/draft-ychen-vc-id-asm-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 63 == Unused Reference: '4' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (ref. '1') (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yue.Chen 3 Internet-Draft Zhengzhou Institute of Information 4 Expires: October 8, 2011 Science and Technology 5 Julong.Lan 6 NDSC 7 Pengxu.Tan 8 Hongyong.Jia 9 Zhengzhou Institute of Information 10 Science and Technology 11 Dourui.Yu 12 NDSC 13 April.8, 2011 15 A Virtual Channel based Inter-domain Any Source Multicast Protocol 17 draft-ychen-vc-id-asm-01.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 1, 2011. 43 Copyright Statement 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 6.b of the Trust Legal Provisions and are provided without 56 warranty as described in the BSD License. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 62 this document are to be interpreted as described in [RFC2119]. 64 Abstract 66 This document defines VC-ID-ASM, a virtual channel based inter- 67 domain any source multicast protocol. Based on extended source 68 specific multicast, the participants join a virtual channel and a 69 shared tree is formed. The receivers receive the multicast traffic 70 along the shared tree, sense the source addresses and then initiate 71 the switch process from the shared tree to the source trees. 73 Table of Contents 75 Copyright Statement............................................... 1 76 1 Introduction.................................................... 2 77 2 VC-ID-ASM....................................................... 3 78 2.1 Many-to-many Group Communication and Group Address 79 Consideration..................................................... 3 80 2.2 Initial Shared Tree Setup by Extended PIM-SSM................. 5 81 2.2.1 Virtual channel selection................................... 5 82 2.2.2 (*,g) state................................................. 5 83 2.2.3 IGMP/MLD message extension and DR's processing.............. 5 84 2.2.4 JOIN/REQS/LEAVE message processing by extended PIM-SSM...... 6 85 2.2.5 Switching from the Shared Tree to the Source Trees.......... 7 86 2.2.6 VC-ID-ASM Packet Forwarding Rule............................ 8 87 3 Security Considerations......................................... 8 88 IANA Considerations............................................... 8 89 Normative References.............................................. 8 90 Author's Address.................................................. 9 92 1 Introduction 94 IP multicast model includes Any Source Multicast (ASM) and Source 95 Specific Multicast (SSM) models. ASM provides many-to-many packet 96 delivery, while SSM provides one-to-many packet delivery in IP 97 layer. 99 The typical intra-domain ASM protocol is Protocol Independent 100 Multicast Routing Protocols-Sparse Mode (PIM-SM)[1]. In PIM-SM, the 101 multicast traffic firstly gathers to a Rendezvous Point (RP), and 102 then reaches the receivers along the shared tree rooted at RP. When 103 the routers directly connected with the receivers (DRs) sense a 104 multicast source, they initiates join to the source and multicast 105 tree rooted at the source is formed. But PIM-SM has the following 106 flaws. (1) It relies on RP, and will cause heavy traffic at and 107 around RP. Computing and distribution the mapping of a group and a 108 RP will consume a great deal computing and bandwidth resource. (2) 109 It is complex, especially in the source registration process. (3) 110 It cannot support inter-domain multicast by itself. One inter- 111 domain scheme is MBGP[2]/PIM-SM[1]/MSDP[3]. But the scheme has 112 serious problems in scalability, security, and group address 113 management. Another inter-domain multicast schema put forward by 114 IETF is MASC/BGMP. Because of its complexity, it is not widely used. 115 The above flaws baffle the deployment of the large scale inter- 116 domain ASM application, and it is urgent to put forward a simple 117 effective inter-domain ASM protocol. 119 Compared with ASM, SSM is a simple. The typical protocol of SSM is 120 PIM-SSM[6], which is a subset of PIM-SM. The introduction of the 121 channel eliminates the dependency to RP and make it directly 122 support inter-domain single source multicast application. Inspired 123 by SSM, VC-ID-ASM, a virtual channel based inter-domain any source 124 multicast protocol, is put forward. It uses the extended PIM-SSM to 125 build a many-to-many inter-domain shared tree for initial group 126 communication and switch to the source trees when the receivers 127 sense the sources for the received packets' heads. Compared with 128 the other schemes, VC-ID-ASM is simple and can support inter-domain 129 ASM application by itself. 131 2 VC-ID-ASM 133 2.1 Many-to-many Group Communication and Group Address Consideration 135 The multi-source group communication process of VC-ID-ASM includes 136 two steps. 138 Step1: forming the initial shared tree and source discovery. 140 Firstly, a visual channel identifier , including it supports a 141 specific ASM application, is published in certain ways (via web 142 pages, etc). s is an addressable IP address (commonly a address in 143 core network equipment, near the center of the participants) . s is 144 not the real multicast source, and it only tells the routers what 145 direction they should send the JOIN(for applying receiving the 146 traffic)/REQS(for applying sending the traffic) messages. g is a 147 multicast group identifier. Secondly, after the senders and 148 receivers get the channel address, they tell the DRs by sending 149 extended IGMPv3[5] (or MLDv2[6], for IPv6) messages that they want 150 to send or to receive the group traffic. The routers send the 151 JOIN/REQS messages to the shortest path interface towards s, hop- 152 by-hop. The routers along the shortest path process the messages to 153 create or maintain the (*,g) states, and the initial shared tree is 154 formed. Thirdly, the group traffic is transmitted alone the shared 155 tree and the receivers sense the real source set S={s1,s2,...,sm}. 157 Step2: forming the source specific trees. 159 +---+ +--+ 160 |sr1| |r1| 161 +---+ +--+ 162 | | 163 | | 164 +--+ +--+ 165 |R1| |R2| 166 +--+ +--+ 167 \ / 168 \ / 169 +--+ +--+ +------+ +--+ +--+ 170 |r4|----|R3|----| R4 |----|R5|----|r2| 171 +--+ +--+ +------+ +--+ +--+ 172 \ / | \ | 173 \ / | \I1 |I2 174 +---+ +---+ +--+ +---+ +----+ +---+ +--+ 175 |sr3|---|R14|---|R6|--|R7-|----| R8 |----|R10|---|s1| 176 +---+ +---+ +--+ +---+ I4+----+I3 +---+ +--+ 177 \ / \ / 178 \ / \I1 I3/ 179 +--+ +---+ +---+ +--------+ +---+ 180 |s2|---|R13|---|R12|----| R9 |----|R11| 181 +--+ +---+ +---+ I2+--------+I4 +---+ 182 | | 183 | | 184 +--+ +---+ 185 |r3| |sr2| 186 +--+ +---+ 187 Figure1 The shared tree rooted at s and the 188 source tree rooted at s1 190 Be aware of si in S by receiving the multicast packets, the 191 receivers tell theirs DRs they want the traffic of channel 192 (1<=i<=m) by sending IGMPv3 messages. The routers send the 193 PIM-SSM JOIN messages to the shortest path interface towards si, 194 hop-by-hop. And the source tree rooted at si is formed. Then the 195 group traffic from si delivers to the receivers along the source 196 tree. When the traffic alone the source tree reaches the receivers, 197 they can optionally send IGMP or MLD message to leave channel , 198 and the routers send extended PIM-SSM LEAVE messages to the 199 shortest path interface towards s, hop by hop, to eliminate the 200 (*,g) on the shared tree rapidly. 202 The routers need to run extended PIM-SSM to process JOIN/REQS/LEAVE 203 messages. Considering the compatibility with standard PIM-SSM, a 204 group address adopted by VC-ID-ASM must be a SSM address, and 205 specific reserved bits need to be set to identify that it is a VC- 206 ID-ASM address. For IPv4 network, a special range in 232.0.0.0- 207 232.0.0.255 can be divided out to denote VC-ID-ASM groups. For IPv6 208 network, a special value of the reserved 4 flag bits can be used to 209 denote VC-ID-ASM groups. 211 Take Fig. 1 as an example, the group senders are s1 and s2, 212 receivers are r1,r2,r3 and r4, and senders as well as receivers are 213 sr1,sr2 and sr3. Router i is denoted as Ri. The broken lines with 214 arrows denote the shared tree rooted at s formed by extended PIM- 215 SSM, and the real lines with arrows denote the source tree rooted 216 at source s1 (the other source trees are neglected). 218 2.2 Initial Shared Tree Setup by Extended PIM-SSM 220 2.2.1 Virtual channel selection 222 There are two methods to select a virtual channel s. The one 223 is that we specify a static s which is in the core network to be 224 the virtual channel. The other is that a s in the core network is 225 choosen using a selection algorithm, such as a random core 226 selection algorithm. 228 2.2.2 (*,g) state 230 (*,g) state formed by extended PIM-SSM includes four fields 231 <*,g,ilist,olist>, where * means it can match any source, g is a 232 VC-ID-ASM group address, ilist is the incoming interface list, and 233 olist is the outgoing interface list. In Fig. 1, for (*,g) of R8, 234 ilist is {I4}, and olist is {I2}. For (*,g) of R9, the ilist is 235 {I1,I3,I4}, and olist is {I1,I2,I4}. Also, the (*,g) states are 236 soft states. The expirations of the interface timer and the state 237 timer will eliminate corresponding interface in ilist or olist, or 238 the whole state. 240 2.2.3 IGMP/MLD message extension and DR's processing 242 In VC-ID-ASM, a host needs to tell its DR that it applies to 243 send/receive group traffic or leave a group. The value of "Type" 244 field in IGMP/MLD message can be extended to fulfill this. Take 245 MLDv2 message for example. Its "Type" field includes 8 bits. Its 246 value is 130,131 or 132 represents the message is a Multicast 247 Listener Query, a Multicast Listener Report or a Multicast Listener 248 Done message. The field value can be extended as: when its value is 249 133, the message is a "Multicast Sender Report" message which 250 represents the host applies to send the group traffic. 252 When a DR receives a extended IGMP/MLD message, it creates or 253 maintains its (*,g) state. Diffident with standard PIM-SSM, when 254 receiving a Multicast Sender Report message from a host, it adds 255 the interface receiving the message to ilist of its (*,g) state; 256 when receiving a Multicast Listener Done message from a host, it 257 removes the interface receiving the message from olist and ilist of 258 its (*,g). 260 Then, according the different requests from the host, the DR sends 261 JOIN/REQS/LEAVE message towards s. When sending JOIN message, it 262 adds the sending interface to ilist of its (*,g) state. When 263 sending REQS message, it adds the sending interface to olist of its 264 (*,g) state. When sending LEAVE message, it removes the sending 265 interface from ilist and olist of its (*,g) state. 267 2.2.4 JOIN/REQS/LEAVE message processing by extended PIM-SSM 269 In control plane, VC-ID-ASM uses extended PIM-SSM JOIN/REQS/LEAVE 270 messages to create and maintain (*,g) states. The type of extended 271 PIM-SSM message includes JOIN (for applying receiving the traffic), 272 REQS (for applying sending the traffic) and LEAVE (for applying 273 leaving the group). JOIN and REQS can be combined in one message, 274 and LEAVE must be used separately. The highest 3 bits in 275 "reversed1" field of SSM message specifies the type of the messages. 276 In the 3 bits, the bit from the highest to the lowest represents 277 whether or not ('1' or '0') expecting to receive the group traffic, 278 whether or not ('1' or '0') expecting to send the group traffic and 279 whether or not ('1' or '0') expecting to leave the group 280 respectively. 282 When a router r receives a JOIN/REQS/LEAVE message sent from a 283 downstream router on interface I, it processes the message as 284 follows. 286 1. If the message type is '100', '010' or '110', and r does not has 287 (*,g) state, r generates a (*,g) state, with its ilist and olist 288 be set {}. 290 2. If the message type is '1?0' (where ? represents '1' or '0'), r 291 adds I to the olist of its (*,g) state. 293 3. If the message type is '?10', r adds I to the ilist of its (*,g) 294 state. 296 4. If the message type is '??1', r removes I from the ilist and the 297 olist of its (*,g) state. 299 After that, suppose the shortest path interface from r to s is I', 300 r processes as follows. 302 1. If the set of the ilist and olist without {I'} is null, 303 indicating there is neither sender nor receiver downstream, r 304 immediately sends LEAVE message (whose type is '??1') to I', and 305 eliminates its (*,g) state; 307 2. If the set of the ilist and olist without {I'} is null and r's 308 (*,g) state is a newly generated one, r immediately sends 309 JOIN/REQS message to I', or else, r sends JOIN/REQS message to 310 I' when JOIN/REQS timer expires; 312 3. If the set of ilist without {I'} is null and the set of olist 313 without {I'} is not null, indicating there is receiver and no 314 sender downstream, r sends the message with type '100' and adds 315 I' to the ilist of its (*,g) state; 317 4. If the set of olist without {I'} is null and the set of ilist 318 without {I'} is not null, indicating there is sender and no 319 receiver downstream, r sends the message with type '010' and 320 adds I' to the olist of its (*,g) state; 322 5. If the set of olist without {I'} is not null and the set of 323 ilist without {I'} is also not null, indicating there is sender 324 and receiver downstream, r sends the message with type '110' and 325 adds I' to the ilist and olist of its (*,g) state. 327 2.2.5 Switching from the Shared Tree to the Source Trees 329 After forming the shared tree, the group traffic will reach the 330 receivers along it. Being aware of a source address si from the 331 multicast packet header, the receiving hosts apply to join 332 channel using IGMPv3 or MLDv2 messages, and the routers send 333 JOIN(si,g) messages to the shortest path interface towards si, hop 334 by hop, to establish the source tree rooted at si. 336 In VC-ID-ASM, the participants of ASM application can begin to 337 apply to send or receive the group traffic at a time point t1, and 338 should let the group traffic from all sources reaches all receivers 339 in a time period t2 after t1. That is, at the time point t1+t2, the 340 receivers should be aware of the source set S={s1,s2, ...,sm }. 341 After t1+t2, the receivers will send extended IGMP or MLD message 342 to leave channel, and then the routers send extended PIM-SSM 343 LEAVE messages towards s to eliminate the (*,g) on the shared tree. 345 According to above rule, after t1+t2, a new participant can not 346 take part in the group communication. While, the switching process 347 is initiated by the user's host; and the value of t1 and t2 can be 348 set in the terminal programs to meet the needs of the ASM 349 application. For example, in a video conference application, t1 is 350 set to 9:00 a.m. and t2 is set to 30 minutes, which means the 351 conference begin at 8:00, and after 8:30 a user can not take part 352 in the conference. For the application that anyone can take part in 353 the whole group application process, t2 should be equal to or 354 greater than the whole application duration. 356 2.2.6 VC-ID-ASM Packet Forwarding Rule 358 When a router r receivers a VC-ID-ASM packet P, whose source 359 address is si and destination address is g, on a interface iif, it 360 will forward the packet according to the following rule (related 361 functions can be found in [1], only PIM-SSM functions are 362 considered and the assert mechanics is ignored). 364 o-list = NULL; 365 if ((si,g) state exists) and (RPF check succeeds) 366 o-list= olist(si,g); 367 else if ((*,g) state exists) and (iif is in ilist of (*,g)) 368 {o-list = olist(*,g); 369 o-list = o-list (-) iif}; 370 Forwards P on each interface in o-list; 372 Above process shows that if a router is the intersection of the 373 shared tree and the source tree, it will firstly forward the packet 374 along the source tree. Take R8 for example. It has (s1,g) and (*,g) 375 state. When R8 receives a VC-ID-ASM packet, whose source address is 376 s1 and destination address is g, on interface I3, It will firstly 377 matches the (s1,g) state, and forwards the packet on I1 and I2, 378 which are in the olist of the (s1,g) state. 380 3 Security Considerations 382 All of the VC-ID-ASM protocol messages (Join/Prune and Hello etc.) 383 are identical, both in format and functionality, to the respective 384 messages used in PIM-SM. Security considerations for these 385 messages are to be found in [1]. 387 It is recommended that IPsec authentication be applied to all VC- 388 ID-ASM protocol messages. The specification on how this is done is 389 found in [1]. Specifically, the authentication of PIM-SM link- 390 local messages, described in [1], applies to all VC-ID-ASM messages 391 as well. 393 The denial-of-service attack based on forged Join messages, 394 described in [1], also applies to VC-ID-ASM. 396 IANA Considerations 398 This document makes no request of IANA. 400 Normative References 402 [1] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, Protocol 403 Independent Multicast - Sparse Mode (PIM-SM): Protocol 404 Specification (Revised), RFC4601, August 2006. 406 [2] T. Bates, Y. Rekhter, R. Chandra, and D. katz, Multiprotocol 407 Extensions for BGP-4, RFC4760. January 2007. 409 [3] M. McBride, J. Meylor, Multicast Source Discovery Protocol 410 (MSDP) Deployment, RFC4611, August 2006. 412 [4] H. Holbrook, B. Cain, Source-specific multicast for IP, RFC4607, 413 Augest 2006. 415 [5] B Cain, S. Deering, Internet Group Management Protocol Version 416 3, RFC3376, October 2002. 418 [6] R.Vida, Ed.r, Multicast Listerner Discovery Version 2(MLDV2) 419 for IPv6, RFC3810, June 2004. 421 Author's Address 423 Yue Chen 424 Zhengzhou Institute of Information Science and Technology 425 12 Shangcheng Road 426 Zhengzhou 450004 427 P.R.China 428 EMail: cyue2008@yahoo.com.cn 430 Julong Lan 431 National Digital Switching System Engneering Technological Reserch 432 Center, P.R.China(NDSC) 433 Lianxue Road 434 Zhengzhou 450004 435 P.R.China 436 Email: ndscljl@163.com 438 Pengxu Tan 439 Zhengzhou Institute of Information Science and Technology 440 12 Shangcheng Road 441 Zhengzhou 450004 442 P.R.China 443 EMail: tanpengxu@gmail.com 445 Hongyong.Jia 446 Zhengzhou Institute of Information Science and Technology 447 12 Shangcheng Road 448 Zhengzhou 450004 449 P.R.China 450 EMail: Jiahy_pla@126.com 452 Dourui.Yu 453 National Digital Switching System Engneering Technological Reserch 454 Center, P.R.China(NDSC) 455 Lianxue Road 456 Zhengzhou 450004 457 P.R.China 458 EMail: ly_dry@126.com