idnits 2.17.1 draft-farinacci-mpls-multicast-02.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: ---------------------------------------------------------------------------- == Line 535 has weird spacing: '...binding of th...' -- 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 (June 2000) is 8714 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) -- Looks like a reference, but probably isn't: '5' on line 446 -- 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 (~~), 3 warnings (==), 10 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: December 2000 4 Yakov Rekhter 5 Eric C. Rosen 6 Ted Qian 7 Cisco Systems, Inc. 9 June 2000 11 Using PIM to Distribute MPLS Labels for Multicast Routes 13 draft-farinacci-mpls-multicast-02.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 ....................................... 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 3 Modifications to PIMv2 ............................. 10 63 3.1 Join/Prune Packets ................................. 10 64 3.2 Hello Packets ...................................... 11 65 4 Label Distribution for PIM-DM ...................... 13 66 5 Security Considerations ............................ 13 67 6 Acknowledgments .................................... 14 68 7 References ......................................... 15 70 1. Overview 72 PIM [PIMv1, PIMv2] is used to combine MPLS label distribution with 73 the distribution of (*,G) join state, (S,G) join state, or (S,G)RPT- 74 bit prune state. Labels and multicast routes are sent together in one 75 message. 77 This design has the following goals: 79 o If an interface attaches to a network with data-link broadcast 80 capability, an LSR should never have to send more than one copy 81 of a given multicast data packet out that interface. However, it 82 is NOT a goal for that LSR to be able to send the same packet, 83 with the same label, out multiple interfaces. 85 o When an interface supports data link multicasting, it must be 86 possible for the receiver of a labeled packet to interpret the 87 label without knowing who the transmitter is. 89 o When a LAN contains multiple label distribution peers, it should 90 be possible to use data link multicast to distribute the label 91 distribution control packets themselves. Other aspects of label 92 distribution methodology should remain as consistent with unicast 93 label distribution as possible. 95 o Multicast label distribution procedures should not depend on the 96 media type. 98 o Once the label for a particular multicast tree on a given LAN has 99 been assigned, unicast routing changes should not cause 100 redistribution or reassignment of the label for that group on 101 that LAN. 103 o When a multicast routing table change requires a label 104 distribution change, the latency between the two should be 105 minimized, both to improve performance and to minimize the 106 possibility of race conditions. 108 o The procedures should work with either dense-mode or sparse mode 109 operation. 111 2. Label Distribution for PIM-SM 113 2.1. Piggybacking 115 An LSR that supports multicast sends PIM Join/Prune messages on 116 behalf of hosts that join groups. It sends Join/Prune messages to 117 upstream neighboring LSRs toward the RP for the shared-tree (*,G) or 118 toward a source for a source-tree (S,G). Labels are distributed by 119 being associated with addresses in the join list or the prune list. 120 In particular: 122 1. If an LSR, Rd, joins the shared tree for a group, the 123 Join/Prune message it sends upstream will contain the group 124 address followed by a join-list. The join-list will contain an 125 element which contains the address of the RP. This element 126 will also contain a a label, and this label can be used by the 127 upstream LSR, Ru, when it sends multicast data down the shared 128 tree. Intuitively, this label represents the route downstream 129 from the current node along the shared tree. 131 Note that if Rd joins the shared tree for group G, but Ru 132 happens to have (S,G) state for some S, then Ru must merge its 133 (*,G) output interface list into its (S,G) output interface 134 list. This is necessary in order to ensure that Rd will 135 receive packets sent from S to G, even though Ru only gets 136 these packets on the source tree. In this case, when Ru 137 receives an (S,G) packet, it should forward it to Rd using the 138 same label that Rd assigned for (*,G) packets, AS LONG AS THE 139 Ru-Rd LINK IS NOT AN LC-ATM interface [MPLS-ATM]. The case 140 where the link is an LC-ATM interface is not considered in the 141 current version of this document, but will be described in a 142 future version. (The procedure described in this paragraph 143 would create a mulitpoint-to-multipoint VC, which ATM-LSRs 144 might not be able to support.) 146 2. If an LSR, Rd, joins a source tree for a group, the Join/Prune 147 message it sends upstream will contain the group address 148 followed by a join-list. The join-list will contain an element 149 which contains the address of the source. This element will 150 also contain a label, and this label can be used by the 151 upstream LSR, Ru, when it sends multicast data down the source 152 tree. Intuitively, this label represents the route downstream 153 from the current node along the specified source tree. 155 3. Suppose an LSR, Rd, has (S,G)RPT-bit state with a null output 156 interface list. This indicates that all of its downstream 157 neighbors on the shared tree for G have pruned source S from 158 the shared tree. Rd sends a Join/Prune message upstream (on 159 the shared tree), containing the group address followed by a 160 prune-list. The prune-list contains an element which contains 161 the address of the source. In this case, no label is included 162 in the element. 164 Similarly, if an LSR has (S,G) state, and also has (*,G) state 165 with a non-null output interface list, it will send a 166 Join/Prune message upstream on the shared tree, with S in the 167 prune-list, and will not include a label. 169 4. Suppose an LSR, Rd, as the result of receiving, from a 170 downstream neighbor on the shared tree, a Join/Prune message 171 such as described in 3, creates (S,G)RPT-bit state with a non- 172 null output interface list. In this case, it may send a 173 Join/Prune message upstream on the shared tree, containing the 174 group address followed by a prune-list. An element of the 175 prune list will contain the address S and a corresponding 176 label. However, a special bit (the "Label Only" bit, or "L- 177 bit") in the element will be set indicating to the upstream LSR 178 that the source S is not really to be pruned from the shared 179 tree. The result is that the upstream LSR, Ru, will still send 180 packets from S to G to Rd, and will label those packets as 181 specified. When Rd receives such packets, it forwards them 182 according to the output interface list of the (S,G)RPT-bit 183 entry. Intuitively, this label represents a route along the 184 shared tree, but only for packets from the specified source. 186 5. An LSR which receives a Join/Prune message as described in 4 187 may send a corresponding Join/Prune message (with the L-bit 188 set) to its upstream LSR on the shared tree. Again, this label 189 represents a route along the shared tree, but only for packets 190 from the specified source. 192 Rules 3-5 above ensure that if a source is pruned off the shared tree 193 at some point, any packets from that source which is sent down the 194 shared tree will have a label that implicitly identifies the source. 195 Thus if those packets encounter a node with (S,G)RPT-bit state, they 196 will be sent according to the output interface list of the (S,G)RPT- 197 bit entry, NOT according to the output interface list of the (*,G) 198 entry. 200 2.2. LANs with Multiple Downstream Nodes 202 2.2.1. Partitioning the Label Space 204 Only one copy of a given multicast data packet is sent downstream. 205 On a LAN, this packet will be received by all the LSRs on the LAN. 206 The label it carries is used, by the receiving LSRs, to find the 207 packet's multicast distribution tree. The label it carries must have 208 a unique association, on that LAN, with a multicast distribution 209 tree. 211 Therefore, once an LSR assigns a label to a particular multicast 212 distribution tree on a particular LAN, all other LSRs on that LAN are 213 prohibited from making any other use of that label. The prohibition 214 remains in effect as long as the distribution tree in question 215 exists. 217 In order to meet this requirement, the LSRs on a LAN must divide up 218 the label space, such that each LSR has a particular unique range of 219 labels which it may distribute. 221 2.2.1.1. Partitioning Procedure 223 Each multicast LSR on a LAN is configured with the total number of 224 labels (N) that may be used to represent multicast distribution trees 225 on the LAN. It is also configured with an approximate count (R) of 226 the routers on the LAN. The router divides the multicast label space 227 into a number of equal-sized ranges, where the size of a range is 228 T/R. Each router will randomly select one of these ranges. 230 When a multicast LSR boots up or enables the LAN interface to do 231 multicast routing, it will advertise in PIM Hello messages the total 232 number of multicast labels, the router count, the label range it 233 randomly selects, and optionally its priority. The lower range label 234 value and the higher range label value accompany the advertisement. 235 If a LSR doesn't advertise its priority, it is treated as if the LSR 236 would advertise the highest possible priority. 238 If the total number of multicast labels for the LAN is not configured 239 consistently on all LSRs connected to a LAN, the smallest number 240 advertised by any LSR will be used. 242 If the router count is not configured consistently on all LSRs 243 connected to a LAN, the smallest router count value advertised by any 244 LSR will be used. 246 If there is another LSR that has selected the same range, then the 247 following procedures are used to determine which of the two LSRs 248 would be able to keep its range, and which would be required to 249 allocate another label range. If the two LSRs have different 250 priority, then the one with the lower priority is required to 251 allocate another label range. If the two LSRs have the same priority, 252 then the one with the lower IP address on the LAN is required to 253 allocate another label range. In both cases the label range is 254 allocated randomly. If as a result of these procedures a LSR has to 255 allocate another label range, then the LSR has to withdraw its label 256 bindings from its currently allocated range, and then (after it 257 allocates another range) reallocate its bindings. 259 A LSR can be configured to use more than one label range if one 260 believes it will be an upstream LSR for many flows. It just inserts 261 additional advertisements in the same PIM Hello message. The label 262 table size and router-count should be the same in all advertisements 263 contained in a message. 265 2.2.1.2. Effect of Partition in Layer 2 Topology 267 When a subnet partitions (due to, say, the failure of a layer 2 268 switch) and new multicast LSRs come up, they will allocate label 269 ranges that are unique to their partition. When the partition heals, 270 there may be conflicts. Once the PIM Hellos messages are received by 271 LSRs on the other side of the partition, they will determine there is 272 a label range allocation conflict and immediately perform the tie 273 breaking rules described above. 275 2.2.1.3. Effect of Exceeding the Label Range 277 When a LSR cannot allocate a label range because all ranges within 278 the label table size have been allocated, it will not participate in 279 binding labels to multicast routes. Packets for these routes will not 280 be label switched. However, the LSR is still capable of label 281 switching a packet as either an upstream or downstream LSR on that 282 LAN. This is the case when another router is binding labels for the 283 multicast route and has an allocated a label range successfully. 285 2.2.2. Assigning the Labels 287 Since PIM Join/Prune messages are multicast on a LAN, other 288 downstream LSRs that are interested in the group will hear the 289 message. They must cache the binding of multicast routing table 290 state and label state together. Since the upstream LSR is going to 291 forward data packets using the advertised label, they must be ready 292 to accept the data packet with that advertised label. 294 The first downstream LSR that joins a group is the label assigner on 295 that LAN for that multicast route. All other downstream LSRs that 296 send PIM Join/Prune messages will use the same label that the 297 assigner selected. A LSR that sends a PIM Join/Prune message with a 298 label of 0 means that it doesn't know the label for the associated 299 multicast routing table entry. When this occurs, the assigner can 300 trigger a PIM Join/Prune message making the label known. 302 When the label assigner leaves the group, the label that it assigned 303 still remains active. The next highest IP addressed downstream LSR 304 becomes the owner of that label and may change it if it sees fit. 305 However, it is not required to change it. All downstream LSRs can 306 continue to use the assignment in their Join messages. 308 If two systems simultaneously join a distribution tree for the first 309 time (they do not have state for that tree), and each chooses a 310 different label value, the highest IP addressed downstream LSR's 311 label will be used by the upstream LSR. The lower addressed LSR will 312 hear the higher addressed LSR's Join too and will also use it's 313 label. 315 If the label assigner crashes, the highest IP addressed downstream 316 LSR assigns a new label to the multicast routes, which were assigned 317 by the crashing LSR, and triggers a Join message so all other LSRs on 318 the LAN to use the new label. 320 When a LAN partitions due to a layer-2 switch failure, it follows the 321 same logic for the case when a LSR stops joining for a group. When 322 the partition heals, there may be an RPF neighbor change in one of 323 the partitions. When there is an RPF neighbor change and the 324 downstream routers trigger joins to their new RPF neighbor with a 325 different label assignment than the other partition is using, one of 326 two resolutions occur: 328 1) The LSR which is the allocator in the partition of the new RPF 329 neighbor will trigger a join if it has a higher IP address than 330 the allocator in the other region. The downstream routers in 331 the other partition use the new label assignment immediately. 333 2) If the LSR which is the allocator in the partition of the new 334 RPF neighbor has a lower IP address, all downstream routers and 335 the new RPF neighbor will switch to the label assigned by the 336 allocator in the other partition. 338 If an RPF change occurs (the topology changed so the upstream LSR is 339 different), the PIM protocol spec indicates that a PIM Join may be 340 triggered to get on the new distribution tree as soon as possible. In 341 this case, if the label assigner becomes the upstream LSR, then the 342 new highest IP addressed downstream LSR may become the label 343 assigner. It may change the label if it sees fit. Otherwise, the same 344 label is used. 346 2.3. Labels for Point-to-Point Links 348 The procedure of section 2.2 works on point-to-point links because 349 there is only one downstream LSR on the link which always becomes the 350 label assigner. 352 2.4. Labels for NBMA Networks 354 On NBMA networks, all PIM routers are known to each other through 355 pseudo-broadcast mechanisms provided by the data-link layer. However, 356 PIM Join messages are unicast to the upstream LSR. Therefore, other 357 downstream LSRs will not hear the label assigner's advertisement. 358 Therefore we treat an NBMA network with one upstream and n downstream 359 LSRs as n point-to-point links, from the upstream LSR to each of the 360 downstream LSRs. Each downstream LSR then assigns its own label, and 361 the upstream LSR must replicate the multicast data packets. 362 Therefore the procedure of section 2.2 applies. 364 Note that this is not incompatible with the use of native point-to- 365 multipoint capabilities at the data link layer. 367 2.5. When NOT to Send a Labelled Multicast Packet 369 PIM Hello messages, sent periodically by all PIM-capable routers, 370 will indicate if the router is MPLS-capable. An upstream router on a 371 LAN will therefore know if all routers on the same LAN are LSRs or 372 not. If there are ANY MPLS-incapable routers which are interested in 373 a particular group, the upstream router will transmit to the LAN only 374 unlabelled multicast data packets for that group. 376 If there are any group members on a LAN, only unlabelled multicast 377 data for that group will be transmitted onto that LAN. 379 Routers that support non-PIM multicast are assumed, for the purposes 380 of this procedure, to be MPLS-incapable. 382 2.6. No Conflict between Unicast and Multicast Labels 384 MPLS uses different data-link layer code-points [MPLS-ENCAPS] to 385 distinguish multicast labeled packets from unicast labeled packets. 386 Therefore, the assignment of labels for unicast routes is completely 387 independent from the assignment of labels for multicast routes. For 388 example, the same label value could be allocated for a unicast route 389 and for a multicast route, without any possibility of ambiguity. 391 2.7. Supporting Bidirectional PIM 393 We consider support of Bidirectional PIM [PIM-BIDIR] only in LSRs 394 which are not ATM-LSRs. In the absence of an ATM multipoint-to- 395 multipoint capability, bidirectional PIM over ATM will not have the 396 favorable scaling properties that make it interesting. 398 On links which are not sender-only links, support for Bidirectional 399 PIM is straightforward. Labels are assigned in the usual manner by 400 downstream LSRs. However, a label can be used in either direction 401 (i.e., can be carried by packets traveling either upstream or 402 downstream). On a given link, the label is bound to the same 403 multicast route (*,G) or (S,G) in both directions. As long as the 404 procedures of section 2.2 are always used to partition the label 405 space (even on point-to-point links), it is possible to use the same 406 label in both directions. 408 Sender-only links present a bit more of a difficulty since PIM 409 Join/Prune messages are not generally sent on those links. In order 410 to assign labels to these links, a downstream node on a sender only 411 link should send a PIM Join message, as if it were going to join the 412 tree, but should set the newly defined "label only" bit (L-bit). In 413 essence, these nodes will contain (*,G) state, and will associate the 414 (*,G) state with a label that is distributed upstream. However, 415 there will be no output interface list associated with the (*,G) 416 state, and packets will just be forwarded towards the RP. 418 3. Modifications to PIMv2 420 3.1. Join/Prune Packets 422 PIMv2 has a packet format for each address type it may support when 423 encoding both multicast and unicast addresses. We will define a new 424 address type called "Label Address" for unicast address encoding. 425 The label will accompany the source address in the Encoded Source 426 Address format as specified in [PIMv2]. The label value will be in a 427 32-bit quantity following the source address. We also take one bit 428 from the PIMv2 reserved field to be the "label only" bit (shown below 429 as the "L-bit"). So, for example, an IPv4 Label Address format would 430 look like: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Rsrvd |L|S|W|R| Mask Len | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Source Address | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Label | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Current Multicast Route Timer | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Label 445 If the high-order bit is clear, the low-order 20 bits are a label 446 value (as described in [5]) assigned by the LSR sending the 447 Join/Prune message. All other bits should be set to 0 by the 448 sender and should be ignored by the receiver. 450 If the high-order bit is set, the low-order 28 bits are a label 451 value in the VPI/VCI format of (as described in [MPLS-ATM]) 452 assigned by the LSR sending the Join/Prune message. All other 453 bits should be set to 0 by the sender and should be ignored by the 454 receiver. 456 Current Multicast Route Timer 457 The sender of a Join/Prune message inserts the current time left 458 before expiration for the multicast route table entry described by 459 the Source Address (either the (S,G) or (*,G) entry). This is 460 needed so all routers on a common multi-access subnet can time-out 461 the entry close to the same time without each other recreating the 462 state when the source goes inactive. 464 Refer to [PIMv2] for other field descriptions not specified here. 466 3.2. Hello Packets 468 The PIM Hello message will carry 2 new OptionTypes (called "Label 469 Parameters" and "VCI Capability") as specified in [PIMv2]. A router 470 that sends a PIM Hello with the Label Parameters option is regarded 471 as being label-capable. This Option can appear multiple times in a 472 Hello packet if a LSR wants to allocate multiple ranges. When this 473 option appears multiple times in the Hello message, the Label Table 474 Size and Router Count must be the same for each Label Parameters 475 Option supplied in the message. 477 When sent on point-to-point links, this option should have Router 478 Count, Lower Label Range, and Upper Label Range set to 0. These 479 fields are ignored on receipt. 481 Label Parameters TLV 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | OptionType = 17 | OptionLength = 16 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Total Number of Multicast Labels for this LAN | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Router Count | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Lower Label Range | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Upper Label Range | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 OptionType "Label Parameters" 498 Set to value 17 decimal. 500 OptionLength 501 The option is 16 bytes in length. 503 Total Number of Multicast Labels 504 The total number of multicast labels the sending router can 505 support on the interface the Hello is sent on. 507 Router Count 508 The approximate maximum number of routers that may be connected to 509 the subnet the Hello is sent on. 511 Lower Label Range 512 The lower label value in the label range that was been randomly 513 selected by the sending router. This value must be less than the 514 Upper Label Range value. 516 Upper Label Range 517 The upper label value in the label range that was been randomly 518 selected by the sending router. This value must be greater than 519 the Lower Label Range value. 521 VCI Capability TLV 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | OptionType = 18 | OptionLength = 1 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Direction | 529 +-+-+-+-+-+-+-+-+ 531 Direction 532 When set to 0, VCI capability is bidirectional. When set to 1, VCI 533 capability is unidirectional. Bidirectional capability indicates 534 an ATM-LSR issuing this option can, within a single VPI, support 535 binding of the same VCI to different routes on the different 536 directions of the link. Unidirectional capability indicates an 537 ATM-LSR issuing this option can, within a single VPI, a single VCI 538 may appear in one binding only. In such systems when a VCI has 539 been bound in one direction on the link it may not be used in the 540 other. 542 Priority TLV 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | OptionType = 19 | OptionLength = 4 | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Priority | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Priority 553 When several LSRs on a LAN allocate the same label range, this 554 field is used to determine which one of those LSRs may keep the 555 allocation. The Priority field is treated as a 32-bits unsigned 556 integer. Higher value is associated with higher Priority. 558 4. Label Distribution for PIM-DM 560 In dense-mode PIM, there is no downstream Join message traveling 561 upstream to perform the binding of multicast routes with labels. 562 However, since we don't want a separate algorithm for dense-mode 563 groups, we extend this basic design for dense-mode PIM. 565 When a downstream LSR creates (S,G) state from the receipt of 1) 566 data, or 2) Join/Prune or Graft messages, it will start a periodic 567 timer to send Join messages with label assignment information 568 present. The messages look no different and are treated on receipt no 569 differently than in the sparse-mode case. 571 The periodic Join message will be multicast on the LAN with an 572 upstream target address of 0.0.0.0. All multicast LSRs on the LAN 573 must know the group operates in dense-mode. This is accomplished 574 using standard PIM mechanisms. 576 5. Security Considerations 578 The security considerations for MPLS in general and label 579 distribution in particular are discussed in [MPLS-ARCH] and [LDP] 580 respectively. Security considerations for PIM are discussed in 581 [PIMv2]. 583 The use of IPSEC for securing the PIM messages, as suggested in 584 [PIMv2], provides adequate security for this application. 586 6. Acknowledgments 588 The authors would like to thank Fred Baker for his comments. We also 589 thank the authors of [MPLS-MUL-FR] for their critique of an earlier 590 version. 592 9.0 Author's Addresses 594 Dino Farinacci 595 Procket Networks, Inc. 596 3850 North First Street 597 San Jose, CA 95134 598 Email: dino@procket.com 600 Yakov Rekhter 601 Cisco Systems, Inc. 602 170 Tasman Drive 603 San Jose, CA, 95134 604 Email: yakov@cisco.com 606 Eric C. Rosen 607 Cisco Systems, Inc. 608 250 Apollo Drive 609 Chelmsford, MA, 01824 610 Email: erosen@cisco.com 612 Ted Qian 613 Cisco Systems, Inc. 614 250 Apollo Drive 615 Chelmsford, MA, 01824 616 Email: tqian@cisco.com 618 7. References 620 [LDP] "LDP Specification", draft-ietf-mpls-ldp-7.txt, Andersson, 621 Doolan, Feldman, Fredette, Thomas, June 2000. 623 [MPLS-ARCH] "Multiprotocol Label Switching Architecture", draft- 624 ietf-mpls-arch-06.txt, Rosen, Viswanathan, Callon, August 1999. 626 [PIMv1] "Protocol Independent Multicast-Sparse Mode (PIM-SM): 627 Protocol" Specification", RFC 2362, Estrin, Farinacci, Helmy, Thaler, 628 Deering, Handley, Jacobson, Liu, Sharma, Wei, June 1998. 630 [PIMv2] "Protocol Independent Multicast-Sparse Mode (PIM-SM): 631 Protocol Specification", draft-ietf-pim-v2-sm-01.txt, Wei, et. al., 632 November, 1999. 634 [PIM-BIDIR] "Bi-directional Protocol Independent Multicast", , Handley, Kouvelas, and Vicisano, March 2000. 637 [MPLS-ENCAPS] "MPLS Label Stack Encoding", , Rosen, Rekhter, Farinacci, Tappan, Fedorkow, Li, 639 Conta, September 1999. 641 [MPLS-MUL-FR] "Framework for IP Multicast in MPLS", , Ooms, Sales, Livens, Acharya, Griffoul, 643 Ansari, May 2000. 645 [MPLS-ATM] "MPLS using LDP and ATM VC Switching", , Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow, 647 Doolan, April 1999.