idnits 2.17.1 draft-farinacci-bidir-pim-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 36 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 196 has weird spacing: '...onsible for f...' == Line 386 has weird spacing: '... Hello mes-...' == Line 452 has weird spacing: '... old-rp old-...' == Line 454 has weird spacing: '... old-dr new-...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 1999) is 9110 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) ** Obsolete normative reference: RFC 2362 (ref. '1') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1825 (ref. '4') (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Deborah Estrin 2 INTERNET-DRAFT USC/ISI 3 Expiration Date: November 1999 Dino Farinacci 4 cisco Systems 5 May 17, 1999 7 Bi-Directional Shared Trees in PIM-SM 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This proposal extends the PIM-SM [1] mechanism for multicast 34 datagram forwarding. PIM-SM constructs and maintains uni-directional 35 shared trees and uni-directional source trees. We describe how we can 36 extend the elements of operation of sparse-mode PIM to support bi- 37 directional shared trees. 39 1. Introduction 41 A uni-directional shared tree allows sources to send multicast 42 datagrams to members of a multicast group. Members receive packets 43 sent to the group by joining the shared tree, using a particular node 44 in the network as the root of the shared tree. The root of the shared 45 tree is called the Rendezvous Point (RP). When using undirectional 46 shared trees, all sources' datagrams initially go to the root (RP) of 47 the tree before being delivered down the distribution tree. As a 48 result, there can be suboptimal delivery paths to the receivers close 49 to the source. 51 In PIM-SM, the RP typically joins back to the source to draw 52 datagrams down directly and natively (no encapsulation) from the 53 source to the RP. The RP then forwards the datagrams down the uni- 54 directional shared tree to the receivers. Eventually, receivers may 55 join to the source as well, thus drawing datagrams down a source 56 specific, uni-directional, shortest path tree. Or the receivers may 57 continue to receive datagrams on the shared tree. 59 When using bi-directional shared trees, data can flow in either 60 direction on a branch of the tree. This allows improved data delivery 61 to receivers close to the source because the traffic traveling 62 upstream to the root node is "turned around" and forwarded on 63 downstream branches [2]. 65 The bi-directional shared trees described in this extension to PIM-SM 66 are used both to distribute datagrams from sources to the RP, as well 67 as to distribute datagrams directly to receivers. Moreover, the 68 protocol does not build source-specific trees from sources to the RP, 69 nor to receivers. Instead, source transmissions travel up the shared 70 tree toward the RP providing coverage to receivers along the way. 71 The RP only needs to forward datagrams downward on those branches of 72 the shared tree not covered by the path from the source to the RP. 74 However, bi-directional trees are incompatible with source specific 75 uni-directional trees and so no switching to source-trees is allowed. 76 Source-trees have the best delay characteristics so there is a 77 tradeoff between uni-directional shared trees with source-trees and 78 bi-directional shared trees. For large numbers of moderate to low 79 rate sources, bi-directional PIM may offer significant advantages. 81 2. Pros and Cons of Bi-Directional Shared Trees 83 There are 3 basic advantages of bi-directional shared trees: 85 1. State is reduced compared to source trees. Each router in 86 the multicast routing domain needs only keep state for the 87 group and not each source sending to each group. [2] 89 2. Datagrams from sources to topologically near-by receivers do not have 90 to travel all the way to the root of the shared tree. These improved 91 distribution paths also support better scoping semantics for 92 applications that might use TTL based expanding ring scope to look 93 for nearby resources. 95 3. Bursty sources can send with no or little state in routers. 97 There are 3 basic disadvantages of bi-directional shared trees: 99 1. Since all traffic eventually goes to the root of the tree, there is a 100 traffic concentration point at the root node and links leading to 101 it (pruning mechanisms could be added but at the cost of additional 102 state and complexity). Traffic always flows to the root node even when 103 it doesn't have to. That is, if the root node has a single sender 104 branch, the root does not take part in forwarding traffic but it must 105 receive the traffic because downstream nodes don't know the group 106 membership tree near the root. 108 2. The path taken between the source and receivers might not travel 109 over the shortest path, although it is likely to be a shorter 110 path than via a uni-directional shared tree. 112 3. Bi-directional trees are incompatible with uni-directional 113 source-trees. There is an increase in complexity when both are 114 used for the same group. 116 Compared to CBT, the bi-directional trees proposed in this 117 specification differ in two respects: 119 1. Non-member senders do not encapsulate their data to the root, the data 120 is forwarded along the same path that it would take if the sender were 121 also a member. 122 2. The protocol reuses much of the existing PIM-SM implementation. 124 3. Modifications to PIM 126 A strong goal of this proposal is to make as few changes as possible 127 to PIM and multicast forwarding. We also wish to make the changes 128 compatible, to enable a phased (incrementally deployed) transition to 129 bi-directional shared tree PIM. Therefore, we use (*,G) state to 130 describe bi-directional shared tree state (traditionally (*,G) has 131 been used to describe uni-directional shared tree state). 133 By definition a PIM bi-directional shared tree group may not have any 134 (S,G) state stored for the group. There are exceptions when mixing 135 non-bidir PIM routers with bidir PIM routers (see later in this 136 specification). 138 We assume that at the same time a router learns the RP for a group, 139 it will know if the group is to operate in bi-directional shared tree 140 mode or uni-directional shared tree mode. This assumption greatly 141 simplifies the deployment and operation of the protocol. 143 4. Modifications to Multicast Forwarding 145 There will be modifications to multicast forwarding since bi- 146 directional shared tree delivery requires traffic to flow upstream 147 (towards the root). This is contrary to RPF forwarding rules used on 148 uni-directional shared trees (datagrams can only be forwarded away 149 from the root node, downstream towards receivers). 151 5. No Modifications to Multicast Capable Hosts 153 This proposal does not require modifications to multicast capable 154 hosts [3]. Hosts that receive multicast datagrams with the UMP 155 option must ignore the option and accept the datagram [6]. 157 6. How are hosts Joined to a Bi-directional Shared Tree 159 No change is required in hosts. Receiving hosts use IGMP [3] (as they 160 do today) to join multicast groups. The attached designated router 161 (DR) will initiate joining of the shared tree. 163 The attached routers perform the same actions as are done to graft 164 branches on the uni-directional tree. That is, the designated router 165 (DR), on the attached subnet with the receiver, will send a PIM 166 Join/Prune message for (*,G) with the RP in the Join-List toward the 167 RP for the group. Routers maintain (*,G) state as defined in the 168 sparse-mode PIM specification. [1] 170 7. How are Source's Datagrams sent onto a Bi-directional Shared Tree 172 No change is required to hosts. A source host will send a multicast 173 datagram by transmitting on its attached interface (as it does today) 174 [3]. The attached DR will initiate the delivery of the multicast 175 datagram upstream towards the RP. 177 When a datagram flows upstream, a receiving router must know that it 178 can bypass the RPF check on the (*,G) entry. To accomplish this, we 179 introduce a new IP option called the Upstream Multicast Packet (UMP). 180 The UMP IP header option is encoded as follows: 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Option Type | Option Length | Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Upstream Router's IP address | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Option Type value is 152 (0x98). That is, the 1-bit copied flag is 191 set to 1, the 2-bit option class is set to 0, and the 5-bit option 192 number is 24. 194 When a router forwards a multicast datagram upstream, it identifies 195 the upstream router in the option. Only the indicated upstream router 196 is responsible for forwarding the datagram upstream. When a router 197 forwards a multicast datagram with the UMP option, it will multicast 198 the datagram on the attached upstream subnet so other routers can 199 forward datagrams down the shared tree if they have (*,G) state. Any 200 directly attached members also receive the datagram. 202 In most cases, only a single copy of the datagram is sent upstream, 203 taking advantage of multi-access/multicast capable media whereever 204 possible. However, on the first hop LAN, there may be two datagrams 205 that traverse the LAN. See next section for details. 207 It is important to note that symmetry between receivers and senders 208 along the same branch must be maintained. That is, a router must join 209 along the same path it would forward traffic upstream or loops could 210 result. This specification forces symmetry because the same choice 211 for forwarding and joining is achieved by using the RPF neighbor to 212 the RP. 214 8. First-hop LAN 216 When a source transmits a multicast datagram, there is one router on 217 the attached LAN that will insert the UMP option. The PIM designated 218 router (DR) will be responsible for this. The DR will insert the UMP 219 option using the address of the next-hop router it knows to reach the 220 RP for the (*,G) entry. 222 There is one case where two datagrams traverse the first-hop LAN. The 223 first datagram is transmitted as multicast by the source and the 224 second is transmitted by the DR as MAC-level unicast to the next-hop 225 upstream router. This only occurs when the DR uses the first-hop LAN 226 as its RPF interface for (*,G). If the DR is an upstream router, the 227 extra datagram is not sent because the RPF interface for (*,G) is not 228 the first-hop LAN. 230 The DR is made responsible for selecting the upstream router in order 231 to avoid inconsistent join and forwarding decisions if multiple 232 downstream routers on the LAN receive joins or datagrams for the same 233 group. If all routers on a LAN always ran a common link state 234 protocol or always had some other means to guarantee consistent 235 routing information, then this would not be necessary. However, in 236 order to allow loop free operation in the widest range of 237 environments, without making restrictive assumptions about unicast 238 routing protocols, configurations and policies, we make use of the DR 239 to enforce consistent decisions. 241 A network administrator can control which router is the PIM DR [5] to 242 avoid particular suboptimal cases. 244 9. Multicast Forwarding Rules 246 The following steps describe the rules for bi-directional shared tree 247 forwarding in PIM. When a router receives a multicast datagram, it 248 may arrive on the RPF interface for a (*,G) entry or another (the 249 non-RPF) interface. 251 A. When a multicast datagram arrives on the RPF interface toward the RP: 253 A1. A multicast routing table lookup is performed. Only a (*,G) entry 254 can be returned (based on our definition that PIM bi-directional 255 shared trees groups will not have (S,G) route entries). 257 If the entry is not found, the datagram is silently discarded. 259 A2. If the entry is found, the datagram is sent out each outgoing 260 interface that resides in the outgoing interface list for the (*,G) 261 entry. In this situation, the router doesn't care if the (*,G) tree 262 state is bi-directional or uni-directional. 264 A3. Before replicating the datagram on each outgoing interface, a router 265 checks to see if the UMP option is present. If so, it can either 266 remove the option or replace the existing address with 0.0.0.0 in 267 the Upstream Router IP Address field. This is to indicate to 268 downstream routers the datagram is not traveling upstream. 270 A4. If the UMP option isn't present and the router is DR on the 271 interface the datagram was received on and the source is directly 272 attached, the DR is responsible for inserting the UMP option. It 273 includes in the UMP option address the next-hop IP address of its 274 RPF neighbor for (*,G). The DR forwards the datagram using the 275 MAC-level address (unicast address) of this RPF neighbor. 277 A5. If the UMP option isn't present and the router isn't the DR, or the 278 source isn't directly attached, the datagram is silently discarded. 280 B. When multicast datagram arrives on a non-RPF interface toward the RP: 282 B1. A multicast routing table lookup is performed. Only a (*,G) entry 283 can be returned (based on our definition of PIM bi-directional shared 284 trees). 286 B2. The router looks at the UMP option. If the option is present and 287 the Upstream Router IP Address is not its own IP address on the 288 received interface, the datagram is silently discarded. 290 B3. If the UMP option is not present and the router is directly connected 291 to the source of the multicast datagram and is the DR on the 292 interface, the DR inserts the UMP option and follows the steps B4.1 293 and B4.2. 295 B4. If the UMP option is present and the Upstream Router IP Address field 296 contains the IP address of the receiving router (on the received 297 interface), it will forward the datagram as follows: 299 B4.1 The datagram is sent out each outgoing interface that resides 300 in the outgoing interface list for the (*,G) entry except for 301 the interface on which the datagram was received on. Before 302 sending out each interface, the router may remove the UMP 303 option from the datagram or replace the existing address with 304 0.0.0.0 in the Upstream Router IP Address field. 306 B4.2 The datagram is forwarded on the RPF interface for (*,G) by 307 replacing the Upstream Router IP Address field in the UMP 308 option with the next-hop address of the router that is used 309 to reach the RP. 311 10. Distinguishing Bi-Directional Shared Tree Groups from other Groups 313 When routers discover the identity of the RP for a multicast group 314 they can determine if the group will operate in bi-directional shared 315 tree mode or uni-directional tree mode. We modify the Encoded-Group 316 Address fields in PIM Bootstrap and Candidate-RP Advertisement 317 messages to include the Bidir-bit (see bit B below): 319 0 1 2 3 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Addr Family | Encoding Type |B| Reserved | Mask Len | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Group Multicast Address | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 When the Bidir-bit is set, all upgraded bi-directional PIM routers 328 will follow the forwarding rules described in this specification. 330 11. Mixing Bi-Directional Capable with Uni-Directional-Only Routers 332 It will take time to upgrade all PIM routers in a domain to be bi- 333 directional shared tree capable. However, enabling bi-directional 334 shared tree routers in an existing network can be easy and simple. 335 First, no special attention at the protocol level needs to be taken 336 if the network is engineered where you can place bidir PIM routers 337 strategically near sources. That is, if sources are located on 338 sender-only branches (no Joins have traveled up that branch) of the 339 bi-directional shared tree, only that branch needs to be upgraded 340 with bi-directional shared tree capable routers. All other routers on 341 receiver branches forward based on (*,G) uni-directional shared tree 342 forwarding rules. 344 When the network cannot be engineered to locate bi-directional shared 345 tree capable routers on sender-only branches, the following 346 transition support can be implemented: 348 o A router will detect if its upstream neighboring router toward the 349 RP is bi-directional shared tree capable or not. We will use the 350 Bidir-Capable PIM Hello Option to convey this information. 352 o A router that is one-hop downstream (of the RP) from a non-bidir 353 capable router will maintain (S,G) state and will be responsible for 354 forwarding multicast traffic as to the RP by Registering to the RP as 355 it would if it was a DR (or MBR) in uni-directional mode. When the 356 data arrives at the RP, it can be delivered on the uni-directional 357 shared-tree (or any source trees that overlap with the shared tree). 359 We define the following PIM Hello Option: 361 Bidir-Capable Option 363 0 1 2 3 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |PIM Ver| Type | Reserved | Checksum | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | OptionType | OptionLength | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | OptionValue | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | . | 373 | . | 374 | . | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | OptionType | OptionLength | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | OptionValue | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 OptionType = 19 (decimal) 383 OptionLength 384 The length of the option payload in bytes. This is set to 0. 386 Therefore, the following encoding is inserted in the PIM Hello mes- 387 sage: 389 0 1 2 3 390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | 19 | 0 | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 By definition, in a pure bi-directional router environment, a bidir 396 capable PIM router will not create (S,G) state when it either 1) 397 receives a datagram or 2) receives any PIM control message. However, 398 there is one exception. When a router receives a datagram that is 399 traveling upstream (the UMP option is present or the router is the DR 400 directly attached to the source) and the upstream neighbor toward the 401 RP is not bidir capable, it will create (S,G) state and set the 402 necessary flags indicating datagrams that match the route entry will 403 be Register encapsulated to the RP. In this case, the router still 404 doesn't accept join messages (and therefore doesn't populate the 405 (S,G) olist) if there are routers upstream that are sending (S,G) 406 Joins or Prunes. A router that does this transition logic is called, 407 a bidir border router. 409 If a bidir router creates (S,G) state for a bi-directional group, it 410 will not send Join/Prune messages for the entry. If a bidir router 411 changes its RPF neighbor toward the RP and the RPF neighbor is bidir 412 capable, it will delete its (S,G) entries. 414 A bidir router must do longest match lookups for a group that is in 415 bi-directional tree mode. This handles the case where the RP 416 forwards datagrams down a branch that has a both a sender and a 417 member on it and avoids datagrams returning to the sender. In this 418 case, a bidir border router should RPF fail for such datagrams since 419 it will use the (S,G) entry rather than the (*,G) entry for the 420 forwarding decision. 422 If the RP is a bidir capable router and it receives a Register 423 message, it will not create (S,G) state. It will forward the data 424 encapsulated in the Register message down the shared tree. The RP 425 will only send a Register-Stop if there are no members for the group 426 (the (*,G) outgoing interface list is empty). An RP will receive a 427 Register message in two cases, 1) the DR is a non-bidir capable 428 router, or 2) it was sent by a bidir border router. 430 If the RP is not bidir capable and it receives a Register from either 431 a non-bidir capable DR or a bidir border router, it may trigger a 432 Join toward the source. If there are any bidir capable routers on the 433 path, they will not create (S,G) state. In this case, the RP will 434 never get data natively and therefore never send Register-Stop 435 messages. The data will continue to be delivered via Register 436 encapsulation. 438 The following shows all possible cases mixing non-bidir (old) and bidir 439 capable (new) routers. Each column shows the capability of 1) the RP, 2) 440 an router between the DR and the RP, and 3) the DR. The following 441 notation 442 is used: 444 "new-rp" - RP is bidir capable 445 "old-rp" - RP is non-bidir capable 446 "old" - router is non-bidir capable 447 "new" - router is bidir capaple 448 "new-dr" - DR is bidir capable 449 "old-dr" - DR is non-bidir capable 451 (1) (2) (3) (4) (5) (6) (7) (8) 452 old-rp old-rp old-rp old-rp new-rp new-rp new-rp new-rp 453 old old new new new new old old 454 old-dr new-dr old-dr new-dr new-dr old-dr new-dr old-dr 456 (1) This case is uni-directional mode. 458 (2) The bidir DR sends Registers and does not forward datagrams with 459 the UMP option. It does this because it detects the upstream router 460 is not bidir-capable. The RP joins back to the source through the 461 intermediate router. The intermediate router's join is ignored by 462 the bidir DR. Datagrams get to receivers via Register encapsulation 463 only from the DR. 465 (3) The non-bidir DR sends Registers. The non-bidir RP may send joins 466 but the bidir intermediate router will ignore them. Datagrams get 467 to receivers via Register encapsulation only from the DR. 469 (4) The bidir DR forwards multicast datagram with the UMP option 470 upstream. It does this because it detects the upstream router is 471 bidir-capable. The bidir intermediate router (acting as a bidir 472 border router) sends Registers to the non-bidir RP. Datagrams get 473 to receivers via Register encapsulation only from the bidir border 474 router. 476 (5) This case is bi-directional shared tree mode. 478 (6) The non-bidir DR will Register to the bidir RP. The bidir RP will 479 not send Joins back to the source. It only Register-Stops if there 480 are no members. The bidir intermediate router is not involved in 481 forwarding multicast datagrams. Datagrams get to receivers via 482 Register encapsulation only from the DR. 484 (7) The bidir DR will Register to the bidir RP. It does this because it 485 detects the upstream router is non-bidir capable. It is performing 486 as a bidir border router. The bidir RP will not send Joins back to 487 the source. It only Register-Stops if there are no members. The 488 non-bidir intermediate router is not involved in forwarding 489 multicast datagrams. Datagrams get to receivers via Register 490 encapsulation only from the DR. 492 (8) The non-bidir DR will Register to the bidir RP. The bidir RP will 493 not send Joins back to the source. It only Register-Stops if there 494 are no members. The non-bidir intermediate router is not involved 495 in forwarding multicast datagrams. Datagrams get to receivers via 496 Register encapsulation only from the DR. 498 12. Security Considerations 500 When IPsec [4] is used on a multicast datagram, the UMP IP option 501 will not be part of the encrypted payload. This is justified by 502 allowing routers to be performant when forwarding datagrams upstream. 504 13. Acknowledgments 506 The authors would like to acknowledge Rusty Eddy (USC), Radia Perlman 507 (Sun), Tony Speakman (cisco), and Liming Wei (cisco) for their 508 comments and contributions to this specification. 510 14. Author Information 512 Deborah Estrin 513 ISI/USC 514 estrin@usc.edu 516 Dino Farinacci 517 cisco Systems, Inc. 518 dino@cisco.com 520 15. References 522 [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- 523 SM): Protocol Specification", RFC 2362, June 1998. 525 [2] A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. 526 In Proceedings of the ACM SIGCOMM, San Francisco, 1993. 528 [3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 529 1112, August 1989. 531 [4] Atkinson, R., "Security Architecture for the Internet Protocol", 532 RFC 1825, August 1995. 534 [5] Wei, L., Farinacci, D., "PIM Version 2 DR Election Priority Option", 535 INTERNET-DRAFT, March 1998. 537 [6] ISI/USC, "Internet Protocol", RFC 791, September 1981.