idnits 2.17.1 draft-meng-pim-sm-enhancement-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 issues found here. 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. -- The document date (November 20, 2017) is 2350 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'KEYWORDS' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC7761' is defined on line 505, but no explicit reference was found in the text -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in 'KEYWORDS'. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Meng 3 Intended Status: Informational Huawei Technologies 4 Expires: May 20, 2018 November 20, 2017 6 An Enhancement of PIM-SM 8 draft-meng-pim-sm-enhancement-01.txt 10 Abstract 12 This document specifies an enhanced version of PIM-SM which works 13 without requiring whole network deployment. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 56 3. Compatible Scheme . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Sending Join/Prune Messages . . . . . . . . . . . . . . . 4 58 3.2. Receiving Join Messages . . . . . . . . . . . . . . . . . 4 59 3.3. Receiving Prune Messages . . . . . . . . . . . . . . . . . 5 60 4. Clean Slate Scheme . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Sending Join/Prune Messages . . . . . . . . . . . . . . . 6 62 4.2. Receiving Join Messages . . . . . . . . . . . . . . . . . 6 63 4.3. Receiving Prune Messages . . . . . . . . . . . . . . . . . 7 64 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 PIM-SM is a multicast routing protocol that can use the underlying 75 unicast routing information base or a separate multicast-capable 76 routing information base. It builds unidirectional shared trees 77 rooted at a Rendezvous Point (RP) per group, and it optionally 78 creates shortest-path trees per source. 80 However, PIM-SM must be deployed contiguously in the whole network, 81 because a joining router can not join into a tree if the upstream 82 neighbor does not support PIM-SM. 84 1.1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Problem Description 92 PIM-SM protocol works generally as follows: 94 1)Multicast receivers express their interests in receiving traffic 95 destined for multicast by using IGMP, MLD or other mechanisms. 97 2)One of a receiver's local routers is elected as the Designated 98 Router (DR) for that subnet. On receiving the receiver's expression 99 of interest, the DR then sends a PIM Join message towards the 100 RP/Source for that multicast group. The Join message travels hop-by- 101 hop towards the RP/Multicast source for the group, and in each router 102 it passes through, multicast tree state for group G is instantiated. 103 Eventually, the Join message either reaches the RP/Multicast source 104 or reaches a router that already has Join state for that group. 106 3)In RFC 7761, all join/prune messages are multicast with TTL 1 to 107 the 'ALL-PIM-ROUTERS' group, a message receiver would compare Unicast 108 Upstream Neighbor Address carried in the message with the address of 109 itself, the message will be processed only if the two addresses are 110 the same. 112 As long as there is one router does not support PIM in the path from 113 a joining router to the target RP/Source, the router can not join 114 into the RPT/SPT. 116 3. Compatible Scheme 118 This scheme is based on RFC 7761. 120 New unicast Join/Prune messages(and their process procedures) will be 121 introduced in this scheme and they will coexist with old Join/Prune 122 messages. 124 3.1. Sending Join/Prune Messages 126 PIM-SM routers send join messages to join into multicast groups, send 127 prune messages to leave multicast groups. 129 If upstream neighbor is a PIM-SM neighbor, old join/prune messages 130 should be sent by the joining/pruning router even if unicast 131 join/prune messages are being received. 133 Otherwise, new unicast join/prune messages should be sent as below: 135 1)If an RPT is being joined/pruned, the destination address of the 136 unicast join/prune message should be the RP address, the source 137 address of the unicast join/prune message should be the address of 138 the joining/pruning router. 140 2)If an SPT is being joined/pruned, the destination address of the 141 unicast join/prune message should be the multicast source address, 142 the source address of the unicast join/prune message should be the 143 address of the joining/pruning router, and there is no Joined/Pruned 144 Source Address field in the message. 146 3.2. Receiving Join Messages 148 Both old join messages and new unicast join messages could be 149 received: 151 1)Old Join messages can only be received by PIM-SM neighbors of the 152 sender, they should be processed according to RFC7761. 154 2)Unicast Join messages could be received by PIM routers(other than 155 RP/Multicast Source) through ACL or similar means, they could also be 156 received by the destination(RP/Multicast Source) of the messages, 157 receivers should create tunnels from themselves to senders along with 158 new states. 160 Join messages should be processed as below in detail: 162 join_msg_arrives(msg) { 164 if (msg.dst == 224.0.0.13) { 166 //The message should be processed according to RFC 7761 168 } else { 170 S = multicast_source(msg); 172 state = S ? get_state(*, G) : get_state(S, G); 174 if (!state) { 176 state = S ? new_state(*, G) : new_state(S, G); 178 if (msg.dst != self_addr) { 180 if (upstream_neighbor_is_a_PIM-SM_neighbor) { 182 send_multicast_join_message; 184 } else { 186 new_msg = msg; 188 new_msg.src = OIF(new_msg).addr; 190 send(new_msg); 192 } 194 } 196 } 198 add_IF_to_olist(state, create_tunnel(IIF(msg).addr, 199 msg.src)); 201 } 203 } 205 add_IF_to_olist(state, IF) { 207 if (/*IF is in state's olist*/){ 209 return; 211 } 213 add(state.olist, IF); 215 } 216 IIF(msg) { 218 return the input interface of msg; 220 } 222 OIF(msg) { 224 return the output interface of msg; 226 } 228 3.3. Receiving Prune Messages 230 Old Prune messages should be processed according to RFC7761. 232 New Prune messages would be intercepted by PIM routers or be received 233 be RP/Source, they should be processed as below. 235 prune_msg_arrives(msg) { 237 if (msg.dst == 224.0.0.13) { 239 //The message should be processed according to RFC 7761 241 } else { 243 S = multicast_source(msg); 245 state = S ? get_state(*, G) : get_state(S, G); 247 if (state) { 249 IIF = tunnel(IIF(msg).addr, msg.src) ? 250 tunnel(IIF(msg).addr, msg.src) : IIF(msg); 252 delete_IF_from_olist(state, IIF); 254 if (state.olist_num == 0) { 256 delete_state(state); 258 if (msg.dst != self_addr) { 260 if (upstream_neighbor_is_a_PIM-SM_neighbor) { 262 send_multicast_prune_message; 264 } else { 266 new_msg = msg; 268 new_msg.src = OIF(new_msg).addr; 270 send(new_msg); 272 } 274 } 276 } 278 } else if (msg.dst != self_addr) { 280 forward(msg); 282 } else { 284 //The prune message should be ignored 286 } 288 } 290 } 292 delete_IF_from_olist(state, IF) { 294 if (/*IF is not in state's olist*/){ 296 return; 298 } 300 delete(state.olist, IF); 302 } 304 IIF(msg) { 306 return the input interface of msg; 308 } 310 OIF(msg) { 311 return the output interface of msg; 313 } 315 4. Clean Slate Scheme 317 This scheme is a modification of RFC 7761: 319 1)Neighbor relationship between PIM routers will no longer be 320 maintained. 322 2)Join/Prune messages(and their process procedures) in RFC 7761 will 323 be replaced by Join/Prune messages introduced in this section. 325 4.1. Sending Join/Prune Messages 327 Join/Prune messages will no longer be multicast with TTL 1 to the 328 'ALL-PIM-ROUTERS' group, they will be unicast as below: 330 1)If an RPT is being joined/pruned, the destination address of the 331 join/prune message should be the RP address, the source address of 332 the join/prune message should be the address of the joining/pruning 333 router. 335 2)If an SPT is being joined/pruned, the destination address of the 336 join/prune message should be the multicast source address, the source 337 address of the join/prune message should be the address of the 338 joining/pruning router, and there is no Joined/Pruned Source Address 339 field in the message. 341 4.2. Receiving Join Messages 343 Join messages could be received by PIM routers(other than 344 RP/Multicast Source) through ACL or similar means, they could also be 345 received by the destination(RP/Multicast Source) of the messages. 347 A receiver should create tunnel from itself to the sender along with 348 new state only if it is the sender's neighbor which can be identified 349 by TTL in IPv4 packet or Hop Limit in IPv6 packet. 351 Join messages would be intercepted by PIM routers or be received be 352 RP/Source, they should be processed as below: 354 join_msg_arrives(msg) { 356 S = multicast_source(msg); 358 state = S ? get_state(*, G) : get_state(S, G); 359 if (!state) { 361 state = S ? new_state(*, G) : new_state(S, G); 363 if (msg.dst != self_addr) { 365 new_msg = msg; 367 new_msg.src = OIF(new_msg).addr; 369 new_msg.ttl = 255; 371 send(new_msg); 373 } 375 } 377 IIF = (msg.ttl == 255) ? IIF(msg) : create_tunnel(IIF(msg).addr, 378 msg.src); 380 add_IF_to_olist(state, IIF); 382 } 384 add_IF_to_olist(state, IF) { 386 if (/*IF is in state's olist*/){ 388 return; 390 } 392 add(state.olist, IF); 394 } 396 IIF(msg) { 398 return the input interface of msg; 400 } 402 OIF(msg) { 404 return the output interface of msg; 406 } 408 4.3. Receiving Prune Messages 410 Prune messages would be intercepted by PIM routers or be received be 411 RP/Source, they should be processed as below: 413 prune_msg_arrives(msg) { 415 S = multicast_source(msg); 417 state = S ? get_state(*, G) : get_state(S, G); 419 if (state) { 421 IIF = tunnel(IIF(msg).addr, msg.src) ? tunnel(IIF(msg).addr, 422 msg.src) : IIF(msg); 424 delete_IF_from_olist(state, IIF); 426 if (state.olist_num == 0) { 428 delete_state(state); 430 if (msg.dst != self_addr) { 432 new_msg = msg; 434 new_msg.src = OIF(new_msg).addr; 436 send(new_msg); 438 } 440 } 442 } else if (msg.dst != self_addr) { 444 forward(msg); 446 } else { 448 //The prune message should be ignored 450 } 452 } 454 delete_IF_from_olist(state, IF) { 455 if (/*IF is not in state's olist*/){ 457 return; 459 } 461 delete(state.olist, IF); 463 } 465 IIF(msg) { 467 return the input interface of msg; 469 } 471 OIF(msg) { 473 return the output interface of msg; 475 } 477 5. Packet Formats 479 There is only one modification about packet formats: 481 If an SPT is being joined/pruned, there will be no Joined/Pruned 482 Source Address field in the joined/pruned message, and the Number of 483 Joined Sources in the message is 1. 485 6. Security Considerations 487 To be perfected. 489 7. IANA Considerations 491 There is no IANA consideration in this specification. 493 8. References 495 8.1. Normative References 497 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, DOI 502 10.17487/RFC2119, March 1997, .. 505 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 506 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 507 Multicast - Sparse Mode (PIM-SM): Protocol Specification 508 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 509 2016, . 511 Authors' Addresses 513 Rui Meng 514 Huawei Technologies Co., Ltd 515 Huawei Campus, 156 Beiqing Road, Hai-dian District 516 Beijing 100089 517 China 519 EMail: mengrui@huawei.com