idnits 2.17.1 draft-farinacci-mpls-multicast-03.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MPLS-ARCH,MPLS-MUL-FR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2000) is 8534 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) -- No information found for draft-ietf-mpls-ldp-7 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDP' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 ** Obsolete normative reference: RFC 2362 (ref. 'PIMv1') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Normative reference to a draft: ref. 'PIMv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-BIDIR' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ENCAPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-MUL-FR' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ATM' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dino Farinacci 2 Internet Draft Procket Networks, Inc. 3 Expiration Date: May 2001 4 Yakov Rekhter 5 Eric C. Rosen 6 Ted Qian 7 Cisco Systems, Inc. 9 November 2000 11 Using PIM to Distribute MPLS Labels for Multicast Routes 13 draft-farinacci-mpls-multicast-03.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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 Internet- 23 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/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies a method of distributing MPLS labels [MPLS- 39 ARCH, MPLS-MUL-FR] for multicast routes. 41 The labels are distributed in the same PIM messages that are used to 42 create the corresponding routes. The method is media-type 43 independent, and therefore works for multi-access/multicast capable 44 LANs, point-to-point links, and NBMA networks. 46 Table of Contents 48 1 Overview ........................................... 2 49 2 Label Distribution for PIM-SM ...................... 3 50 2.1 Piggybacking Labels with Multicast Routes .......... 3 51 2.2 LANs with Multiple Downstream Nodes ................ 5 52 2.2.1 Partitioning the Label Space ....................... 5 53 2.2.1.1 Partitioning Procedure ............................. 5 54 2.2.1.2 Effect of Partition in Layer 2 Topology ............ 6 55 2.2.1.3 Effect of Exceeding the Label Range ................ 7 56 2.2.2 Assigning the Labels ............................... 7 57 2.3 Labels for Point-to-Point Links .................... 8 58 2.4 Labels for NBMA Networks ........................... 8 59 2.5 When NOT to Send a Labelled Multicast Packet ....... 9 60 2.6 No Conflict between Unicast and Multicast Labels ... 9 61 2.7 Supporting Bidirectional PIM ....................... 9 62 2.8 ATM-LSRs without Multipoint-to-Multipoint .......... 10 63 2.8.1 Label Request/Binding .............................. 10 64 2.8.2 Steady State Maintenance ........................... 11 65 2.8.3 Label Distribution and LSP Control ................. 12 66 3 Modifications to PIMv2 ............................. 12 67 3.1 Join/Prune Packets ................................. 12 68 3.2 Hello Packets ...................................... 13 69 4 Label Distribution for PIM-DM ...................... 15 70 5 Security Considerations ............................ 16 71 6 Acknowledgments .................................... 16 72 7 References ......................................... 17 74 1. Overview 76 PIM [PIMv1, PIMv2] is used to combine MPLS label distribution with 77 the distribution of (*,G) join state, (S,G) join state, or (S,G)RPT- 78 bit prune state. Labels and multicast routes are sent together in one 79 message. 81 This design has the following goals: 83 o If an interface attaches to a network with data-link broadcast 84 capability, an LSR should never have to send more than one copy 85 of a given multicast data packet out that interface. However, it 86 is NOT a goal for that LSR to be able to send the same packet, 87 with the same label, out multiple interfaces. 89 o When an interface supports data link multicasting, it must be 90 possible for the receiver of a labeled packet to interpret the 91 label without knowing who the transmitter is. 93 o When a LAN contains multiple label distribution peers, it should 94 be possible to use data link multicast to distribute the label 95 distribution control packets themselves. Other aspects of label 96 distribution methodology should remain as consistent with unicast 97 label distribution as possible. 99 o Multicast label distribution procedures should not depend on the 100 media type. (However, it has been necessary to compromise this 101 goal in the case of ATM-LSRs which do not have multipoint-to- 102 multipoint capability, see section 2.8.) 104 o Once the label for a particular multicast tree on a given LAN has 105 been assigned, unicast routing changes should not cause 106 redistribution or reassignment of the label for that group on 107 that LAN. 109 o When a multicast routing table change requires a label 110 distribution change, the latency between the two should be 111 minimized, both to improve performance and to minimize the 112 possibility of race conditions. 114 o The procedures should work with either dense-mode or sparse mode 115 operation. 117 2. Label Distribution for PIM-SM 119 2.1. Piggybacking Labels with Multicast Routes 121 An LSR that supports multicast sends PIM Join/Prune messages on 122 behalf of hosts that join groups. It sends Join/Prune messages to 123 upstream neighboring LSRs toward the RP for the shared-tree (*,G) or 124 toward a source for a source-tree (S,G). Labels are distributed by 125 being associated with addresses in the join list or the prune list. 126 In particular: 128 1. If an LSR Rd, joins the shared tree for a group, the Join/Prune 129 message it sends upstream will contain the group address 130 followed by a join-list. The join-list will contain an element 131 which contains the address of the RP. This element will also 132 contain a a label, and this label can be used by the upstream 133 LSR Ru, when it sends multicast data down the shared tree. 134 Intuitively, this label represents the route downstream from 135 the current node along the shared tree. 137 Note that if Rd joins the shared tree for group G, but Ru 138 happens to have (S,G) state for some S, then Ru must merge its 139 (*,G) output interface list into its (S,G) output interface 140 list. This is necessary in order to ensure that Rd will 141 receive packets sent from S to G, even though Ru only gets 142 these packets on the source tree. In this case, when Ru 143 receives an (S,G) packet, it should forward it to Rd using the 144 same label that Rd assigned for (*,G) packets, EXCEPT IN THE 145 CASE where Ru is an ATM-LSR which does not support multipoint- 146 to-multipoint connections(see section 2.8). 148 2. If an LSR Rd, joins a source tree for a group, the Join/Prune 149 message it sends upstream will contain the group address 150 followed by a join-list. The join-list will contain an element 151 which contains the address of the source. This element will 152 also contain a label, and this label can be used by the 153 upstream LSR Ru, when it sends multicast data down the source 154 tree. Intuitively, this label represents the route downstream 155 from the current node along the specified source tree. 157 3. Suppose an LSR Rd, has (S,G)RPT-bit state with a null output 158 interface list. This indicates that all of its downstream 159 neighbors on the shared tree for G have pruned source S from 160 the shared tree. Rd sends a Join/Prune message upstream (on 161 the shared tree), containing the group address followed by a 162 prune-list. The prune-list contains an element which contains 163 the address of the source. In this case, no label is included 164 in the element. 166 Similarly, if an LSR has (S,G)SPT-bit state, and also has (*,G) 167 state with a non-null output interface list, and the input 168 interface for (*,G) is different than the input interface for 169 (S,G), it will send a Join/Prune message upstream on the shared 170 tree, with S in the prune-list, and will not include a label. 172 4. Suppose an LSR Rd, as the result of receiving, from a 173 downstream neighbor on the shared tree, a Join/Prune message 174 such as described in 3, creates (S,G)RPT-bit state with a non- 175 null output interface list. In this case, it may send a 176 Join/Prune message upstream on the shared tree, containing the 177 group address followed by a prune-list. An element of the 178 prune list will contain the address S and a corresponding 179 label. However, a special bit (the "Label Only" bit, or "L- 180 bit") in the element will be set indicating to the upstream LSR 181 that the source S is not really to be pruned from the shared 182 tree. The result is that the upstream LSR Ru, will still send 183 packets from S to G to Rd, and will label those packets as 184 specified. When Rd receives such packets, it forwards them 185 according to the output interface list of the (S,G)RPT-bit 186 entry. Intuitively, this label represents a route along the 187 shared tree, but only for packets from the specified source. 189 5. An LSR which receives a Join/Prune message as described in 4 190 may send a corresponding Join/Prune message (with the L-bit 191 set) to its upstream LSR on the shared tree. Again, this label 192 represents a route along the shared tree, but only for packets 193 from the specified source. 195 Rules 3-5 above ensure that if a source is pruned off the shared tree 196 at some point, any packets from that source which is sent down the 197 shared tree will have a label that implicitly identifies the source. 198 Thus if those packets encounter a node with (S,G)RPT-bit state, they 199 will be sent according to the output interface list of the (S,G)RPT- 200 bit entry, NOT according to the output interface list of the (*,G) 201 entry. 203 2.2. LANs with Multiple Downstream Nodes 205 2.2.1. Partitioning the Label Space 207 Only one copy of a given multicast data packet is sent downstream. 208 On a LAN, this packet will be received by all the LSRs on the LAN. 209 The label it carries is used, by the receiving LSRs, to find the 210 packet's multicast distribution tree. The label it carries must have 211 a unique association, on that LAN, with a multicast distribution 212 tree. 214 Therefore, once an LSR assigns a label to a particular multicast 215 distribution tree on a particular LAN, all other LSRs on that LAN are 216 prohibited from making any other use of that label. The prohibition 217 remains in effect as long as the distribution tree in question 218 exists. 220 In order to meet this requirement, the LSRs on a LAN must divide up 221 the label space, such that each LSR has a particular unique range of 222 labels which it may distribute. 224 2.2.1.1. Partitioning Procedure 226 Each multicast LSR on a LAN is configured with the total number of 227 labels (N) that may be used to represent multicast distribution trees 228 on the LAN. It is also configured with an approximate count (R) of 229 the routers on the LAN. The router divides the multicast label space 230 into a number of equal-sized ranges, where the size of a range is 231 T/R. Each router will randomly select one of these ranges. 233 When a multicast LSR boots up or enables the LAN interface to do 234 multicast routing, it will advertise in PIM Hello messages the total 235 number of multicast labels, the router count, and the label range it 236 randomly selects. The lower range label value and the higher range 237 label value accompany the advertisement. 239 If the total number of multicast labels for the LAN is not configured 240 consistently on all LSRs connected to a LAN, the smallest number 241 advertised by any LSR will be used. 243 If the router count is not configured consistently on all LSRs 244 connected to a LAN, the smallest router count value advertised by any 245 LSR will be used. 247 If there is another LSR that has selected the same range, then the 248 following procedures are used to determine which of the two LSRs 249 would be able to keep its range, and which would be required to 250 allocate another label range. If DR election priority is included in 251 the Hello messages at both LSRs, and the priority values are not 252 equal, then the LSR with the lower DR election priority is required 253 to allocate another label range. Otherwise, the LSR with the lower IP 254 address on the LAN is required to allocate another label range. In 255 both cases the label range is allocated randomly. If as a result of 256 these procedures a LSR has to allocate another label range, then the 257 LSR has to withdraw its label bindings from its currently allocated 258 range, and then (after it allocates another range) reallocate its 259 bindings. 261 A LSR can be configured to use more than one label range if one 262 believes it will be an upstream LSR for many flows. It just inserts 263 additional advertisements in the same PIM Hello message. The label 264 table size and router-count should be the same in all advertisements 265 contained in a message. 267 2.2.1.2. Effect of Partition in Layer 2 Topology 269 When a subnet partitions (due to, say, the failure of a layer 2 270 switch) and new multicast LSRs come up, they will allocate label 271 ranges that are unique to their partition. When the partition heals, 272 there may be conflicts. Once the PIM Hellos messages are received by 273 LSRs on the other side of the partition, they will determine there is 274 a label range allocation conflict and immediately perform the tie 275 breaking rules described above. 277 2.2.1.3. Effect of Exceeding the Label Range 279 When a LSR cannot allocate a label range because all ranges within 280 the label table size have been allocated, it will not participate in 281 binding labels to multicast routes. Packets for these routes will not 282 be label switched. However, the LSR is still capable of label 283 switching a packet as either an upstream or downstream LSR on that 284 LAN. This is the case when another router is binding labels for the 285 multicast route and has an allocated a label range successfully. 287 2.2.2. Assigning the Labels 289 Since PIM Join/Prune messages are multicast on a LAN, other 290 downstream LSRs that are interested in the group will hear the 291 message. They must cache the binding of multicast routing table 292 state and label state together. Since the upstream LSR is going to 293 forward data packets using the advertised label, they must be ready 294 to accept the data packet with that advertised label. 296 The first downstream LSR that joins a group is the label assigner on 297 that LAN for that multicast route. All other downstream LSRs that 298 send PIM Join/Prune messages will use the same label that the 299 assigner selected. A LSR that sends a PIM Join/Prune message with a 300 label of 0 means that it doesn't know the label for the associated 301 multicast routing table entry. When this occurs, the assigner can 302 trigger a PIM Join/Prune message making the label known. 304 When the label assigner leaves the group, the label that it assigned 305 still remains active. The next highest IP addressed downstream LSR 306 becomes the owner of that label and may change it if it sees fit. 307 However, it is not required to change it. All downstream LSRs can 308 continue to use the assignment in their Join messages. 310 If two systems simultaneously join a distribution tree for the first 311 time (they do not have state for that tree), and each chooses a 312 different label value, the highest IP addressed downstream LSR's 313 label will be used by the upstream LSR. The lower addressed LSR will 314 hear the higher addressed LSR's Join too and will also use it's 315 label. 317 If the label assigner crashes, the highest IP addressed downstream 318 LSR assigns a new label to the multicast routes, which were assigned 319 by the crashing LSR, and triggers a Join message so all other LSRs on 320 the LAN to use the new label. 322 When a LAN partitions due to a layer-2 switch failure, it follows the 323 same logic for the case when a LSR stops joining for a group. When 324 the partition heals, there may be an RPF neighbor change in one of 325 the partitions. When there is an RPF neighbor change and the 326 downstream routers trigger joins to their new RPF neighbor with a 327 different label assignment than the other partition is using, one of 328 two resolutions occur: 330 1) The LSR which is the allocator in the partition of the new RPF 331 neighbor will trigger a join if it has a higher IP address than 332 the allocator in the other region. The downstream routers in 333 the other partition use the new label assignment immediately. 335 2) If the LSR which is the allocator in the partition of the new 336 RPF neighbor has a lower IP address, all downstream routers and 337 the new RPF neighbor will switch to the label assigned by the 338 allocator in the other partition. 340 If an RPF change occurs (the topology changed so the upstream LSR is 341 different), the PIM protocol spec indicates that a PIM Join may be 342 triggered to get on the new distribution tree as soon as possible. In 343 this case, if the label assigner becomes the upstream LSR, then the 344 new highest IP addressed downstream LSR may become the label 345 assigner. It may change the label if it sees fit. Otherwise, the same 346 label is used. 348 2.3. Labels for Point-to-Point Links 350 The procedure of section 2.2 works on point-to-point links because 351 there is only one downstream LSR on the link which always becomes the 352 label assigner. 354 2.4. Labels for NBMA Networks 356 On NBMA networks, all PIM routers are known to each other through 357 pseudo-broadcast mechanisms provided by the data-link layer. However, 358 PIM Join messages are unicast to the upstream LSR. Therefore, other 359 downstream LSRs will not hear the label assigner's advertisement. 360 Therefore we treat an NBMA network with one upstream and n downstream 361 LSRs as n point-to-point links, from the upstream LSR to each of the 362 downstream LSRs. Each downstream LSR then assigns its own label, and 363 the upstream LSR must replicate the multicast data packets. 364 Therefore the procedure of section 2.2 applies. 366 Note that this is not incompatible with the use of native point-to- 367 multipoint capabilities at the data link layer. 369 2.5. When NOT to Send a Labelled Multicast Packet 371 PIM Hello messages, sent periodically by all PIM-capable routers, 372 will indicate if the router is MPLS-capable. An upstream router on a 373 LAN will therefore know if all routers on the same LAN are LSRs or 374 not. If there are ANY MPLS-incapable routers which are interested in 375 a particular group, the upstream router will transmit to the LAN only 376 unlabelled multicast data packets for that group. 378 If there are any group members on a LAN, only unlabelled multicast 379 data for that group will be transmitted onto that LAN. 381 Routers that support non-PIM multicast are assumed, for the purposes 382 of this procedure, to be MPLS-incapable. 384 2.6. No Conflict between Unicast and Multicast Labels 386 Frame based MPLS uses different data-link layer code-points [MPLS- 387 ENCAPS] to distinguish multicast labeled packets from unicast labeled 388 packets. Therefore, the assignment of labels for unicast routes is 389 completely independent from the assignment of labels for multicast 390 routes. For example, the same label value could be allocated for a 391 unicast route and for a multicast route, without any possibility of 392 ambiguity. 394 MPLS on a label switching controlled ATM (LC-ATM) interface uses 395 VPI/VCI as the top label [MPLS-ATM]. There is no VPI/VCI range 396 specifically reserved for multicast or for unicast. 398 2.7. Supporting Bidirectional PIM 400 We consider support of Bidirectional PIM [PIM-BIDIR] only in LSRs 401 which are not ATM-LSRs. In the absence of an ATM multipoint-to- 402 multipoint capability, bidirectional PIM over ATM will not have the 403 favorable scaling properties that make it interesting. 405 On links which are not sender-only links, support for Bidirectional 406 PIM is straightforward. Labels are assigned in the usual manner by 407 downstream LSRs. However, a label can be used in either direction 408 (i.e., can be carried by packets traveling either upstream or 409 downstream). On a given link, the label is bound to the same 410 multicast route (*,G) or (S,G) in both directions. As long as the 411 procedures of section 2.2 are always used to partition the label 412 space (even on point-to-point links), it is possible to use the same 413 label in both directions. 415 Sender-only links present a bit more of a difficulty since PIM 416 Join/Prune messages are not generally sent on those links. In order 417 to assign labels to these links, a downstream node on a sender only 418 link should send a PIM Join message, as if it were going to join the 419 tree, but should set the newly defined "label only" bit (L-bit). In 420 essence, these nodes will contain (*,G) state, and will associate the 421 (*,G) state with a label that is distributed upstream. However, 422 there will be no output interface list associated with the (*,G) 423 state, and packets will just be forwarded towards the RP. 425 2.8. ATM-LSRs without Multipoint-to-Multipoint 427 Multipoint-to-multipoint capability is a feature of an ATM switch 428 that allows an outgoing VC to appear in one or more cross-connect 429 (e.g., two incoming VCs cross-connecting to the the same set of 430 outgoing VCs) without causing cell interleaving. The procedure 431 described in this section applies to ATM-LSRs that do NOT have 432 multipoint-to-multipoint capability. 434 2.8.1. Label Request/Binding 436 When LSR Ru receives an (S,G) join from LSR Rd, Ru, which did not 437 have the (S,G) state, must create the (S,G) state and populate it 438 with the oifs from (*,G). When LSR Ru receives an (*,G) join from LSR 439 Rd, if the (S,G) state already exists on Ru, the oif must be added to 440 the (S,G)'s oif list as well. 442 At LSR Ru, for each oif that is copied from a (*,G) to an (S,G), the 443 associated label/VCI is not replicated. Instead, the oif moves into a 444 Label Needed state, and an (S,G) L-bit Join/Request is sent out of 445 the interface to the Rd. The Encoded-Unicast-Upstream Neighbor 446 Address field in such Join is set to the address of Rd. Source 447 address in the join list employs the Label Address encoding with the 448 next t-bit (section 3.1) in the label field set and the L-bit set. 449 Since this is a source specific Join Request along the shared tree, 450 the R bit is set and W bit is clear. In addition, the current 451 multicast route timer (section 3.1) is set to the time remaining on 452 the (S,G) Entry-Timer at Ru. Rd, upon receiving such Join, fills in 453 the label field with the next t-bit cleared, and then sends the (S,G) 454 L-bit R-bit Join/Binding back out of the RPF interface toward the RP. 455 (S,G) L-bit Join/Request received from non-RPF interface towards RP 456 must be discarded. At Ru, the incoming label for (S,G) is then 457 cross-connected with labels in the (S,G) L-bit R-bit join received 458 from Rd. 460 LSR Rd, that receives an (S,G) L-bit R-bit Join/Request via the RPF 461 towards the RP, must create an (S,G) L-bit state if it doesn't 462 already exist, and must initializes the (S,G)'s Entry-Timer with the 463 the current multicast route timer encoded in the source address. If 464 Rd is capable of multipoint-to-multipoint connection, label 465 replication follows the procedure described in section 2.1. 466 Otherwise, it follows the procedure described in this section. 468 The L-bit on an (S,G) indicates that the state is created by an (S,G) 469 L-bit R-bit Join/Request, and periodic Joins that it sends must have 470 the L-bit set. 472 2.8.2. Steady State Maintenance 474 An (S,G) entry is removed upon expiration of its Entry-Timer. The 475 timer may be updated upon receiving an (S,G) L-bit R-bit Join/Request 476 from the RPF interface towards the RP. If the "Current Multicast 477 Route Timer" is greater than the remaining timer value of the Entry- 478 Timer, the timer value is increased to the "Current Multicast Route 479 Timer" specified in the L-bit R-bit Join/Request. The time may also 480 be updated by other event such as receiving (S,G) Join from any 481 downstream oif peers. Note, (S,G) L-bit Join from downstream oif 482 doesn't reset the Entry-Timer. 484 In the event that an upstream router no longer needs a (S,G) label 485 from its downstream peer (e.g., switching back to a share tree), the 486 (S,G) state eventually expires since the (S,G) Entry-Timer is NOT 487 updated by the receipt of L-bit Join/Bindings. It simply stops 488 sending periodic L-bit R-bit Join/Request out of that oif upon 489 expiration of the (S,G) state. This eventually causes the (S,G)'s 490 Entry-Timer to expire in the downstream router and the state removal. 492 Sending a (S,G) L-bit R-bit Join/Request out of an oif is triggered 493 by the receipt of a (*,G) Join from the same oif. For each (S,G) that 494 exists, an (S,G) L-bit R-bit Join/Request is sent down the oif in a 495 Label Needed state. Regular (S,G) Join received with the L-bit 496 cleared removes the Label Needed state on the oif, and also clears 497 the L-bit state on the (S,G) entry. Joins triggered by the expiration 498 of the Join Timer on such (S,G)contain cleared L-bit. This mechanism 499 accommodates the situation where an upstream LSR that needs a label 500 and a downstream DR receiver which decides that traffic exceeds the 501 threshold both initiate the source tree, and part of the shared and 502 source tree overlaps. 504 2.8.3. Label Distribution and LSP Control 506 The procedures of section 2.8 use MPLS Downstream on Demand 507 procedures with Independent LSP control [MPLS-ARCH]. 509 The Downstream on Demand procedures are needed whenever two incoming 510 VCs corresponding to the same FEC cannot be merged into a single 511 outgoing VC. In the absence of multipoint-to-multipoint capability, 512 this applies to multicast distribution trees. 514 Independent LSP control is needed so that different downstream 515 branches of a multicast distribution tree can join the tree 516 independently. The fact that one particular downstream branch of the 517 tree is slow to respond to the control messages does not then prevent 518 or even delay other more responsive downstream branches from joining 519 the tree. 521 3. Modifications to PIMv2 523 3.1. Join/Prune Packets 525 PIMv2 has a packet format for each address type it may support when 526 encoding both multicast and unicast addresses. We will define a new 527 address type called "Label Address" for unicast address encoding. 528 The label will accompany the source address in the Encoded Source 529 Address format as specified in [PIMv2]. The label value will be in a 530 32-bit quantity following the source address. We also take one bit 531 from the PIMv2 reserved field to be the "label only" bit (shown below 532 as the "L-bit"). So, for example, an IPv4 Label Address format would 533 look like: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Rsrvd |L|S|W|R| Mask Len | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Source Address | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |a|t| Label | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Current Multicast Route Timer | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Label 548 If the a-bit is clear, the low-order 20 bits are a label value (as 549 described in [MPLS-ATM]) assigned by the LSR sending the 550 Join/Prune message. All other bits should be set to 0 by the 551 sender and should be ignored by the receiver. 553 If the a-bit is set, the low-order 28 bits are a label value in 554 the VPI/VCI format of (as described in [MPLS-ATM]) assigned by the 555 LSR sending the Join/Prune message. If the t-bit is set, the 556 VPI/VCI label value should be ignored by the receiver since this 557 represents a label request by an ATM-LSR. All other bits should be 558 set to 0 by the sender and should be ignored by the receiver. 560 Current Multicast Route Timer 561 The sender of a Join/Prune message inserts the current time left 562 before expiration for the multicast route table entry described by 563 the Source Address (either the (S,G) or (*,G) entry). This is 564 needed so all routers on a common multi-access subnet can time-out 565 the entry close to the same time without each other recreating the 566 state when the source goes inactive. 568 Refer to [PIMv2] for other field descriptions not specified here. 570 3.2. Hello Packets 572 The PIM Hello message will carry 2 new OptionTypes (called "Label 573 Parameters" and "VCI Capability") as specified in [PIMv2]. A router 574 that sends a PIM Hello with the Label Parameters option is regarded 575 as being label-capable. This Option can appear multiple times in a 576 Hello packet if a LSR wants to allocate multiple ranges. When this 577 option appears multiple times in the Hello message, the Label Table 578 Size and Router Count must be the same for each Label Parameters 579 Option supplied in the message. 581 When sent on point-to-point links, this option should have Router 582 Count, Lower Label Range, and Upper Label Range set to 0. These 583 fields are ignored on receipt. 585 When sent on LC-ATM links, the first Label Parameter option carries 586 the VPI range and the second one carries the VCI range. 588 Label Parameters TLV 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | OptionType = 17 | OptionLength = 16 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Total Number of Multicast Labels for this LAN | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Router Count | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Lower Label Range | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Upper Label Range | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 OptionType "Label Parameters" 605 Set to value 17 decimal. 607 OptionLength 608 The option is 16 bytes in length. 610 Total Number of Multicast Labels 611 The total number of multicast labels the sending router can 612 support on the interface the Hello is sent on. 614 Router Count 615 The approximate maximum number of routers that may be connected to 616 the subnet the Hello is sent on. 618 Lower Label Range 619 The lower label value in the label range. This value, randomly 620 selected by the sending router in the case of non LC-ATM link or 621 supplied by the ATM driver in the case of LC-ATM link, must be 622 less than the Upper Label Range value. 624 Upper Label Range 625 The upper label value in the label range. This value, randomly 626 selected by the sending router in the case of non LC-ATM link or 627 supplied by the ATM driver in the case of LC-ATM link, must be 628 greater than the Lower Label Range value. 630 VCI Capability TLV 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | OptionType = 23 | OptionLength = 5 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Priority | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Reserved |D| 640 +-+-+-+-+-+-+-+-+ 642 OptionType "VCI Capability" 643 Set to value 23 decimal. 645 OptionLength 646 The option is 5 bytes in length. 648 Priority 649 Peering ATM-LSRs exchange the priority value for VC space odd-even 650 determination when at least one side supports unidirectional VC. 651 An ATM-LSR with a higher priority value may assign only odd- 652 numbered VC and ATM-LSR with a lower priority value may assign 653 even-numbered VC. The value should be ignored if the LC-ATM link 654 is bidirectional. 656 D Bit 657 When the D bit is clear, VCI capability is bidirectional. When it 658 is set, VCI capability is unidirectional. Bidirectional capability 659 indicates an ATM-LSR issuing this option can, within a single VPI, 660 support binding of the same VCI to different routes on the 661 different directions of the link. Unidirectional capability 662 indicates an ATM-LSR issuing this option can, within a single VPI, 663 a single VCI may appear in one binding only. In such systems when 664 a VCI has been bound in one direction on the link it may not be 665 used in the other. 667 4. Label Distribution for PIM-DM 669 In dense-mode PIM, there is no downstream Join message traveling 670 upstream to perform the binding of multicast routes with labels. 671 However, since we don't want a separate algorithm for dense-mode 672 groups, we extend this basic design for dense-mode PIM. 674 When a downstream LSR creates (S,G) state from the receipt of 1) 675 data, or 2) Join/Prune or Graft messages, it will start a periodic 676 timer to send Join messages with label assignment information 677 present. The messages look no different and are treated on receipt no 678 differently than in the sparse-mode case. 680 The periodic Join message will be multicast on the LAN with an 681 upstream target address of 0.0.0.0. All multicast LSRs on the LAN 682 must know the group operates in dense-mode. This is accomplished 683 using standard PIM mechanisms. 685 5. Security Considerations 687 The security considerations for MPLS in general and label 688 distribution in particular are discussed in [MPLS-ARCH] and [LDP] 689 respectively. Security considerations for PIM are discussed in 690 [PIMv2]. 692 The use of IPSEC for securing the PIM messages, as suggested in 693 [PIMv2], provides adequate security for this application. 695 6. Acknowledgments 697 The authors would like to thank Yiqun Cai for his overall help on 698 this draft. We thank Fred Baker for his comments on an earlier 699 version. We also thank the authors of [MPLS-MUL-FR] for their 700 critique of an earlier version. 702 9.0 Author's Addresses 704 Dino Farinacci 705 Procket Networks, Inc. 706 3850 North First Street 707 San Jose, CA 95134 708 Email: dino@procket.com 710 Yakov Rekhter 711 Cisco Systems, Inc. 712 170 Tasman Drive 713 San Jose, CA, 95134 714 Email: yakov@cisco.com 715 Eric C. Rosen 716 Cisco Systems, Inc. 717 250 Apollo Drive 718 Chelmsford, MA, 01824 719 Email: erosen@cisco.com 721 Ted Qian 722 Cisco Systems, Inc. 723 250 Apollo Drive 724 Chelmsford, MA, 01824 725 Email: tqian@cisco.com 727 7. References 729 [LDP] "LDP Specification", draft-ietf-mpls-ldp-7.txt, Andersson, 730 Doolan, Feldman, Fredette, Thomas, June 2000. 732 [MPLS-ARCH] "Multiprotocol Label Switching Architecture", draft- 733 ietf-mpls-arch-06.txt, Rosen, Viswanathan, Callon, August 1999. 735 [PIMv1] "Protocol Independent Multicast-Sparse Mode (PIM-SM): 736 Protocol" Specification", RFC 2362, Estrin, Farinacci, Helmy, Thaler, 737 Deering, Handley, Jacobson, Liu, Sharma, Wei, June 1998. 739 [PIMv2] "Protocol Independent Multicast-Sparse Mode (PIM-SM): 740 Protocol Specification", draft-ietf-pim-v2-sm-01.txt, Wei, et. al., 741 November, 1999. 743 [PIM-BIDIR] "Bi-directional Protocol Independent Multicast", , Handley, Kouvelas, and Vicisano, March 2000. 746 [MPLS-ENCAPS] "MPLS Label Stack Encoding", , Rosen, Rekhter, Farinacci, Tappan, Fedorkow, Li, 748 Conta, September 1999. 750 [MPLS-MUL-FR] "Framework for IP Multicast in MPLS", , Ooms, Sales, Livens, Acharya, Griffoul, 752 Ansari, May 2000. 754 [MPLS-ATM] "MPLS using LDP and ATM VC Switching", , Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow, 756 Doolan, June 2000.