idnits 2.17.1 draft-ooms-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: ---------------------------------------------------------------------------- ** 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 29 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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 106 has weird spacing: '... mp2mp mult...' == Line 107 has weird spacing: '... p2mp poi...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DAV2' is defined on line 1197, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ACHA' -- No information found for draft-mpls-ldp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ANDE' -- Possible downref: Normative reference to a draft: ref. 'BALL' == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. 'CALL' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-fr-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'CRAW' == Outdated reference: A later version (-04) exists of draft-ietf-mpls-atm-01 -- Possible downref: Normative reference to a draft: ref. 'DAV2' ** Obsolete normative reference: RFC 2117 (ref. 'DEER') (Obsoleted by RFC 2362) == Outdated reference: A later version (-03) exists of draft-ietf-pim-v2-dm-01 -- Possible downref: Normative reference to a draft: ref. 'DEE2' == Outdated reference: A later version (-01) exists of draft-farinacci-multicast-tagsw-00 -- Possible downref: Normative reference to a draft: ref. 'FARI' -- Possible downref: Normative reference to a draft: ref. 'FAR2' -- Possible downref: Normative reference to a draft: ref. 'KATS' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOY') == Outdated reference: A later version (-05) exists of draft-ietf-mpls-vcid-atm-00 == Outdated reference: A later version (-03) exists of draft-perlman-simple-multicast-02 -- Possible downref: Normative reference to a draft: ref. 'PERL' == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-05 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'PUSA') -- Possible downref: Non-RFC (?) normative reference: ref. 'PARS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PAXS' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-03 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Submitted to MPLS Working Group D. Ooms, W. Livens 2 B. Sales, M. Ramalho 3 INTERNET DRAFT Alcatel 4 A. Acharya, F. Griffoul 5 NEC 6 F. Ansari 7 Bell Labs 9 May, 1999 10 Expires November, 1999 12 Framework for IP Multicast in MPLS 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document offers a framework for IP multicast deployment in an 38 MPLS environment. Issues arising when MPLS techniques are applied to 39 IP multicast are overviewed. The pros and cons of existing IP 40 multicast routing protocols in the context of MPLS are described and 41 the relation to the different trigger methods and label distribution 42 modes are discussed. The consequences of various layer 2 (L2) 43 technologies are listed. Both point-to-point and multi-access 44 networks are considered. 46 Table of Contents 48 1. Introduction 49 2. Layer 2 characteristics 50 3. Taxonomy of IP multicast routing protocols in the context of MPLS 51 3.1. Aggregation 52 3.2. Flood & Prune 53 3.3. Source/Shared trees 54 3.4. Co-existence of Source and Shared Trees 55 3.5. Uni/Bi-directional Shared Trees 56 3.6. Encapsulated multicast data 57 3.7. Loop-free-ness 58 3.8. RPF Check 59 3.9. Mapping of characteristics on existing protocols 60 4. Mixed L2/L3 forwarding in a single node 61 5. Taxonomy of IP multicast LSP triggers 62 5.1. Request driven 63 5.1.1. General 64 5.1.2. Multicast routing messages 65 5.1.3. Resource reservation messages 66 5.2. Topology driven 67 5.3. Traffic driven 68 5.3.1. General 69 5.3.2. An implementation example 70 5.4. Combinations of triggers and label distribution modes 71 6. Piggy-backing 72 7. Explicit routing 73 8. QoS/CoS 74 8.1 DiffServ 75 8.2 IntServ and RSVP 76 9. Multi-access networks 77 10. More issues 78 10.1. TTL field 79 10.2. Independent vs. Ordered Label Distribution Control 80 10.3. Conservative vs. Liberal Label Retention Mode 81 10.4. Downstream vs. Upstream Label Allocation 82 10.5. Explicit vs. Implicit Label Distribution 83 11. Security Considerations 84 12. Acknowledgements 86 Table of Abbreviations 88 ATM Asynchronous Transfer Node 89 CBT Core Based Tree 90 CoS Class of Service 91 DLCI Data Link Connection Identifier 92 DRrecv Designated Router of the receiver 93 DRsend Designated Router of the sender 94 DVMRP Distant Vector Multicast Routing Protocol 95 FR Frame Relay 96 IGMP Internet Group Management Protocol 97 IP Internet Protocol 98 L2 layer 2 (e.g. ATM, Frame Relay) 99 L3 layer 3 (e.g. IP) 100 LSP Label Switched Path 101 LSR Label Switching Router 102 LSRd Downstream LSR 103 LSRu Upstream LSR 104 MIP Multicast Internet Protocol 105 MOSPF Multicast OSPF 106 mp2mp multipoint-to-multipoint 107 p2mp point-to-multipoint 108 PIM-DM Protocol Independent Multicast-Dense Mode 109 PIM-SM Protocol Independent Multicast-Sparse Mode 110 QoS Quality of Service 111 RP Rendezvous Point 112 RPF Reverse Path Forwarding 113 RSVP Resource reSerVation Protocol 114 TCP Transmission Control Protocol 115 UDP User Datagram Protocol 116 VC Virtual Circuit 117 VCI Virtual Circuit Identifier 118 VP Virtual Path 119 VPI Virtual Path Identifier 121 1. Introduction 123 In an MPLS cloud the routes are determined by a L3 routing protocol. 124 These routes can then be mapped onto L2 paths to enhance network 125 performance. Besides this, MPLS offers a vehicle for enhanced 126 network services such as QoS/CoS, traffic engineering, etc. 128 Current unicast routing protocols generate a same (optimal) shortest 129 path in steady state for a certain (source, destination)-pair. Remark 130 that unicast protocols can behave slightly different with regard to 131 equal cost paths. 133 For multicast, the optimal solution (minimum cost to interconnect N 134 nodes) would impose a Steiner tree computation. Unfortunately, no 135 multicast routing protocol today is able to maintain such an optimal 136 tree. Different multicast protocols will therefore, in general, 137 generate different trees. 139 The discussion is focused on intra-domain multicast routing 140 protocols. Aspects of inter-domain routing are beyond the scope of 141 this document. 143 2. Layer 2 characteristics 145 Although MPLS is multiprotocol both at L3 and at L2, in practice IP 146 is the only considered L3 protocol. MPLS can run on top of several 147 L2 technologies (PPP/Sonet, Ethernet, ATM, FR, ...). 149 When label switching is mapped on L2 switching capabilities (e.g. 150 VPI/VCI is used as label), attention is mainly focused on the mapping 151 to ATM [DAVI]. ATM offers high switching capacities and QoS 152 awareness, but in the context of MPLS it poses several limitations 153 which are described in [DAVI]. Similar considerations are made for 154 Frame Relay on L2 in [CONT]. The limitations can be summarized as: 156 - Limited Label Space: either the standardized or the implemented 157 number of bits available for a label can be small (e.g. VPI/VCI 158 space, DLCI space), limiting the number of LSPs that can be 159 established. 161 - Merging: some L2 technologies or implementations of these 162 technologies do not support multipoint-to-point and/or multipoint- 163 to-multipoint 'connections', obstructing the merging of LSPs. 165 - TTL: L2 technologies do not support a 'TTL-decrement' function. 167 All three limitations can impact the implementation of multicast in 168 MPLS as will be described in this document. 170 When native MPLS is deployed the above limitations vanish. Moreover 171 on PPP and Ethernet links the same label can be used at the same time 172 for a unicast and a multicast LSP because different EtherTypes for 173 MPLS unicast and multicast are defined [ROSE]. 175 3. Taxonomy of IP multicast routing protocols in the context of MPLS 177 At the moment, an abundance of IP multicast routing protocols is 178 being proposed and developed. All these protocols have different 179 characteristics (scalability, computational complexity, latency, 180 control message overhead, tree type, etc...). It is not the purpose 181 of this document to give a complete taxonomy of IP multicast routing 182 protocols, only their characteristics relevant to the MPLS technology 183 will be addressed. 185 Following characteristics are considered: 187 - Aggregation 188 - Flood & Prune 189 - Source/Shared trees 190 - Co-existence of Source and Shared Trees 191 - Uni/Bi-directional shared trees 192 - Encapsulated multicast data 193 - Loop-free-ness 194 - RPF check 196 The discussion of these characteristics will not lead to the 197 selection of one superior multicast routing protocol. It is not 198 impossible that different IP multicast routing protocols will be 199 deployed in the Internet. 201 3.1. Aggregation 203 In unicast different destination addresses are aggregated to one 204 entry in the routing table, yielding one FEC and one LSP. 206 The granularity of multicast streams is (*, G) for a shared tree and 207 (S, G) for a source tree, S being the source address and G the 208 multicast group address. Aggregation of multicast trees with 209 different multicast 'destination' addresses on one LSP is a subject 210 for further study. 212 3.2. Flood & Prune 214 To establish a multicast tree some IP multicast routing protocols 215 (e.g. DVMRP, PIM-DM) flood the network with multicast data. The 216 branches can then be pruned by nodes which do not want to receive the 217 data of the specific multicast group. This process is repeated 218 periodically. 220 Flood & Prune multicast routing protocols have some characteristics 221 which significantly differ from unicast routing protocols: 223 a) Volatile. Due to the Flood & Prune nature of the protocol, very 224 volatile tree structures are generated. Solutions to map a dynamic 225 L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of 226 signaling overhead and LSP setup time. The volatile L2 LSP will 227 consume a lot of labels throughout the network, which is a 228 disadvantage when label space is limited. 230 b) Traffic-driven. The router only creates state for a certain group 231 when data arrives for that group. Routers also independently decide 232 to remove state when an inactivity timer expires. 233 - Thus LSPs can not be pre-established as is usually done in 234 unicast. To minimize the time between traffic arrival and LSP 235 establishment a fast LSP setup method is favorable. 236 - Since creation and deletion of a L3 route at each node is 237 triggered by traffic, this suggests that the LSP associated with the 238 route be setup and torn down in a traffic-driven manner as well. 239 - If an LSR does not support L3 forwarding this traffic-driven 240 nature even requires that the upstream LSR takes the initiative to 241 create an LSP (upstream or downstream-on-demand label advertisement). 243 3.3. Source/Shared trees 245 IP multicast routing protocols create either source trees (S, G), 246 i.e. a tree per source (S) and per multicast group (G), or shared 247 trees (*, G), i.e. one tree per multicast group (Figure 1). 249 R1 R1 R1 250 S1 / / / 251 \ / / / 252 \ / / / 253 C---R2 S1---R2 S2---R2 254 / \ \ \ 255 / \ \ \ 256 S2 \ \ \ 257 R3 R3 R3 259 Figure 1. Shared tree and Source trees 261 The advantage of using shared trees, when label switching is applied, 262 is that shared trees consume less labels than source trees (1 label 263 per group versus 1 label per source and per group). 265 However, mapping a shared tree end-to-end on L2 implies setting up 266 multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing 267 mp2mp LSPs boils down to the merging problem discussed earlier. 269 3.4. Co-existence of Source and Shared Trees 271 Some protocols support both source and shared trees (e.g. PIM-SM) and 272 one router can maintain both (*, G) and (S, G) state for the same 273 group G. Two cases of state co-existence are described below. 274 Assume topologies with senders Si and receivers Ri. RP is the 275 Rendezvous Point. Ni are LSRs. The numbers are the interface 276 numbers, Reg is the Register interface. All IGMP and PIM Join/Prune 277 messages are shown in the figures. It is also indicated whether the 278 RPT-bit is set for the (S, G) state. 280 1) Figure 2 shows a switchover from shared to source tree. Assume 281 that the shortest path from R1 to RP is via N1-N2-N5. N1, the 282 Designated Router of receiver R1 (DRrecv), decides to initiate a 283 source tree for source S1. After the arrival of data via the source 284 tree in N2, N2 will send a prune to N5 for source S1. State co- 285 existence occurs in the node where the overlap of shared and source 286 tree starts (N2) and in the node where S1 does not need forwarding on 287 the shared tree anymore (N5). 289 PJ 290 IJ PJS PJS 291 -> 1 2 -> 1 2 -> 1 2 292 R1-----N1------N2------N3----S1 293 3| |3 IJ=Igmp Join 294 ||PPS | PJ=Pim Join (*,G) 295 |vPJ | PJS=Pim Join (S1,G) 296 IJ PJ | PJ | PPS=Pim Prune (S1,G) 297 -> -> |3 -> | 298 R2-----N4------N5------RP----S2 299 1 2 1 2 1 301 Figure 2 303 The multicast routing states created in the MRT are: 305 in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) 306 in N1: (*,G):2->1 307 in N2: (*,G):3->1 308 (S1,G):2->1 309 in N3: (S1,G):2->Reg,1 310 in N4: (*,G):2->1 311 in N5: (*,G):2->1,3 312 (S1,G)RPT-bit:2->1 314 2) Figure 3 shows that even without a switchover, state co-existence 315 can occur. Multicast traffic from a sender will create (S, G) state 316 in the Designated Router of the sender (DRsend; N3 in Figure 3 is the 317 DRsend of S). Each node on a shared-tree has (*, G) state. Thus an 318 on-tree DRsend has both (*, G) and (S, G) state. If the DRsend is 319 on-tree it will also send a prune for S towards the RP, creating (S, 320 G) state in all nodes until the first router which has a branch (N1 321 and N2 in Figure 3). 323 S 324 PPS PPS | 325 PJ PJ PJ |2 PJ IJ 326 1 <- 1 3<- <- | <- <- PJ=Pim Join 327 RP------N1----N2----N3----N4----R1 IJ=Igmp Join 328 ^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G) 329 PJ|| IJ 330 1| <- 331 N5----R2 332 2 333 Figure 3 335 The multicast routing states created in the MRT are: 337 in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) 338 in N1: (*,G):1->2,3 339 (S,G)RPT-bit:1->2 340 in N2: (*,G):1->2 341 (S,G)RPT-bit:1->none 342 in N3: (*,G):1->3 343 (S,G):2->Reg,3 344 in N4: (*,G):1->2 345 in N5: (*,G):1->2 347 In the examples one can observe that two types of state co-existence 348 occur: 350 1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The 351 (*, G) and (S, G) state have different incoming interfaces, but some 352 common outgoing interfaces. It is possible that the traffic of S 353 arrives on both the (*, G) and (S, G) interfaces. In normal L3 354 forwarding the (S, G)SPT-bit entry prohibits the forwarding of the 355 traffic from S arriving on the (*, G) incoming interface. The 356 traffic of S can only temporarily arrive on the incoming interfaces 357 of both the (*, G) and (S, G) entries (until N5 in Figure 2 and N1 in 358 Figure 3 have processed the prune messages). To avoid the temporary 359 forwarding of duplicate packets L3 forwarding can be applied in this 360 type of node. If one does not mind the temporary duplicate packets 361 L2 forwarding can be applied. In this case the (*, G) and (S, G) 362 streams have to be merged into the (*, G) LSP on their common 363 outgoing interfaces. 365 2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The (*, 366 G) and (S, G) state have the same incoming interface. The (S, G) 367 traffic must be extracted from the (*, G) stream. In MPLS this state 368 co-existence can be handled in several ways. Four approaches to this 369 problem will be described: 371 a) A first method to handle this state co-existence is to terminate 372 the LSPs and forward all traffic of this group at L3. However a 373 return to L3 can be avoided in case a (S, G) entry without outgoing 374 interface is added to the MRT (N2 in Figure 3). This entry will only 375 receive traffic temporarily. In this particular case one could 376 ignore the (S, G) state and maintain the existing (*, G) LSP, the 377 disadvantage being duplicate traffic for a very short time. 379 b) A second approach is to assign source specific labels on the nodes 380 of the shared tree. Multiple labels will be associated with one (*, 381 G) entry, corresponding to one label per active source. Since the 382 nodes only know which sources are active when traffic from these 383 sources arrives, the LSPs can not be pre-established and a fast LSP 384 setup method is favorable. 386 c) A third way is that only source trees are labelswitched and that 387 traffic on the shared tree is always forwarded at L3. This assumes 388 that the shared tree is only used as a way for the receivers to find 389 out who the sources are. By configuring a low bitrate switchover 390 threshold one can obtain that the receivers switchover to source 391 trees very quickly. 393 d) In the fourth approach an LSR which has (S, G)RPT-bit state with a 394 non-null oif, advertises a label for (S, G) to the upstream LSR and 395 this label advertisement is then propagated by each upstream LSR 396 towards the RP. In this way a dedicated LSP is created for (S, G) 397 traffic from the RP to the LSR with the (S, G)RPT-bit state. In the 398 latter LSR the (S, G) LSP is merged onto the (*, G) LSP for the 399 appropriate outgoing interfaces. This ensures that (S, G) packets 400 traveling on the shared tree do not make it past any LSR which has 401 pruned S. 403 3.5. Uni/Bi-directional Shared Trees 405 Bidirectional shared trees (e.g. CBT) have the disadvantage of 406 creating a lot of merging points (M) in the nodes (N) of the shared 407 tree. Figure 4 shows these merging points resulting from 2 senders S1 408 and S2 on a bidirectional tree. 410 S1 S2 411 || || 412 v| <- <- <- <- |v 413 <- <- | -> -> -> -> | -> 414 ----N----M----M----M----M----M----N 415 || || || || || || 416 |v |v |v |v |v |v 417 | | | | | | 419 Figure 4. Multicast traffic flows from 2 senders on a bidirectional tree 421 In Figure 5 the same situation for unidirectional shared trees is 422 depicted. In this case the data of the senders is tunneled towards 423 the root node R, yielding only a single merging point, namely the 424 root of the shared tree itself. 426 S1 427 tunnel || S2 428 <----- v| tunnel || 429 to R<------------------------- v| 430 -> -> | -> -> -> -> | -> 431 ----N----N----N----N----N----N----N 432 || || || || || || 433 |v |v |v |v |v |v 434 | | | | | | 436 Figure 5. Multicast traffic flows from 2 senders on a unidirectional tree 438 3.6. Encapsulated multicast data 440 Sources of unidirectional shared trees and non-member sources of 441 bidirectional shared trees encapsulate the data towards the root 442 node. The data is then decapsulated in the root node. The 443 encapsulation and decapsulation of multicast data are L3 processes. 445 Thus in case of encapsulation/decapsulation a path can never be 446 mapped onto an end-to-end LSP: the traffic can not be forwarded on L2 447 on the Register interface of the DRsend (encapsulation), nor can it 448 cross the root (decapsulation) at L2. 450 Remarks: 452 1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G) 453 traffic in DRsend can still be forwarded on L2 on the outgoing 454 interfaces which are not the Register interface. 456 2) The encapsulated traffic can also benefit from MPLS by label 457 switching the tunnels. 459 3) If the root node decides to join the source (to avoid 460 encapsulation/decapsulation), an end-to-end (S, G) LSP can be 461 constructed. 463 3.7. Loop-free-ness 465 Multicast routing protocols which depend on a unicast routing 466 protocol suffer from the same transient loops as the unicast 467 protocols do, however the effect of loops will be much worse in the 468 case of multicast. The reason being, each time a multicast packet 469 goes around a loop, copies of the packet may be emitted from the loop 470 if branches exist in the loop. 472 Note that there exist multicast routing protocols which are 473 guaranteed loop free [PARS]. Currently loop detection is a 474 configurable option in LDP and a decision on the mechanism for loop 475 prevention is postponed. If loops appear to be a major issue and 476 MPLS does not handle them properly these guaranteed loop free 477 protocols have an advantage. 479 3.8. RPF Check 481 Some protocols perform a Reverse Path Forwarding (RPF) check on the 482 received multicast packets. This mechanism checks whether the packet 483 is received on the interface which is on the shortest path to the 484 source (or root). This mechanism can introduce problems when 485 explicit routing is used (see section 7). Indeed, explicit routing 486 can construct a tree yielding another incoming interface than the 487 RPF-compatible one. 489 3.9. Mapping of characteristics on existing protocols 491 The above characteristics are summarized in Table 1 for a non- 492 exhaustive list of existing IP multicast routing protocols: DVMRP 493 [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], MIP 494 [PARS], SM [PERL]. 496 +------------------+------+------+------+------+------+-----+------+ 497 | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|MIP |SM | 498 +------------------+------+------+------+------+------+-----+------+ 499 |Aggregation |no |no |no |no |no |no |no | 500 +------------------+------+------+------+------+------+-----+------+ 501 |Flood & Prune |yes |no |no |yes |no |no |option| 502 +------------------+------+------+------+------+------+-----+------+ 503 |Tree Type |source|source|shared|source|both |both |shared| 504 +------------------+------+------+------+------+------+-----+------+ 505 |State Co-existence|no |no |no |no |yes |yes |no | 506 +------------------+------+------+------+------+------+-----+------+ 507 |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |both |bi | 508 +------------------+------+------+------+------+------+-----+------+ 509 |Encapsulation |no |no |yes |no |yes |yes |yes | 510 +------------------+------+------+------+------+------+-----+------+ 511 |Loop Free |no |no |no |no |no |yes |no | 512 +------------------+------+------+------+------+------+-----+------+ 513 |RPF check |yes |yes |no |yes |yes |no |no | 514 +------------------+------+------+------+------+------+-----+------+ 516 Table 1. Taxonomy of IP Multicast Routing Protocols 518 From Table 1 one can derive e.g. that DVMRP will consume a lot of 519 labels when the Flood & Prune L3 tree is mapped onto a L2 tree. 520 Furthermore since DVMRP uses source trees it experiences no merging 521 problem when label switching is applied. The table can be 522 interpreted in the same way for the other protocols. 524 4. Mixed L2/L3 forwarding in a single node 526 Since unicast traffic has one incoming and one outgoing interface the 527 traffic is either forwarded at L2 OR at L3 (Figure 6). Because 528 multicast traffic can be forwarded to more than one outgoing 529 interface one can consider the case that traffic to some branches is 530 forwarded on L2 and to other branches on L3 (Figure 7). 532 +--------+ +--------+ 533 | L3 | | L3 | 534 | +>>+ | | | 535 | | | | | | 536 +--|--|--+ +--------+ 537 | | | | | | 538 ->-----+ +-----> ->------>>-----> 539 | L2 | | L2 | 540 +--------+ +--------+ 542 Figure 6. Unicast forwarding on resp. L3 or L2 544 +--------+ +--------+ +--------+ 545 | L3 | | L3 | | L3 | 546 | +>>++ | | +>>+ | | | 547 | | || | | | | | | | 548 +--|--||-+ +--|--|--+ +--------+ 549 | | |+----> | | +-----> | +----> 550 ->-----+ | | | |L2 | ->----->>-+ | 551 | L2+-----> ->-----+>>------> | L2 +----> 552 +--------+ +--------+ +--------+ 554 Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2 556 Nodes which support this 'mixed L2/L3 forwarding' feature allow that 557 a multicast tree splits in branches of which some are forwarded at L3 558 while others are switched at L2. 560 The L3 forwarding has to take care that the traffic is not forwarded 561 on those branches that already get their traffic on L2. This can be 562 accomplished by e.g. providing an extra bit in the Multicast Routing 563 Table. 565 Although the mixed L2/L3 forwarding requires processing of the 566 traffic at L3, the load on the L3 forwarding engine is generally less 567 than in a pure L3 node. 569 Supporting this 'mixed L2/L3 forwarding' feature has following 570 advantages: 572 a) Assume LSR A (Figure 8) is an MPLS edge node for the branch 573 towards LSR B and an MPLS root node for the branch towards LSR C. 574 The mixed L2/L3 forwarding allows that the branch towards C is not 575 disturbed by a return to L3 in LSR A. 577 +-------------+ 578 | MPLS cloud | 579 | N | 580 | / \ | 581 | / \ | 582 | / \ | 583 | A N | 584 |/ \ \ | 585 | \ \ | 586 /| \ | 587 B | C | 588 | | 589 +-------------+ 591 Figure 8. Mixed L2/L3 forwarding in node A 593 b) Allows a return to L3 for branches which requested lower QoS 594 (section 8). 596 c) Enables the use of the traffic driven trigger with the downstream 597 or upstream on demand label distribution mode, as explained in 598 section 5.4. 600 5. Taxonomy of IP multicast LSP triggers 602 The creation of an LSP for multicast streams can be triggered by 603 different events, which can be mapped on the well known categories of 604 'request driven', 'topology driven' and 'traffic driven'. 606 a) Request driven: intercept the sending or receiving of control 607 messages (e.g. multicast routing messages, resource reservation 608 messages). 610 b) Topology driven: map the L3 tree, which is available in the 611 Multicast Routing Table, to a L2 tree. The mapping is done even if 612 there is no traffic. 614 c) Traffic driven: the L3 tree is mapped onto a L2 tree when data 615 arrives on the tree. 617 Whether the trigger by multicast routing messages is categorized as 618 request or topology driven is debatable. The constructed L2 tree 619 will be identical to the one constructed by topology driven methods, 620 but the definition of request driven [CALL] includes all label 621 assignments in response to control traffic. In [KATS] the multicast 622 routing messages trigger is categorized as request driven, so we will 623 continue using this convention. 625 5.1. Request driven 627 5.1.1. General 629 The establishment of LSPs can be triggered by the interception of 630 outgoing (requiring that the label is requested by the downstream 631 LSR) or incoming (requiring that the label is requested by the 632 upstream LSR) control messages. Figure 9 illustrates these two 633 cases. 635 LSRu LSRd LSRu LSRd 636 -------+ +--- ---+ +------- 637 | control | | control | 638 <---*<-----message------- <-------message-------*---- 639 | | | | | | 640 trigger| | | | | |trigger 641 | | bind | | bind | | 642 +--------or---------> <---------or----------+ 643 | bind-request | | bind-request | 644 | | | | 645 | | | | 646 |----data----->| |-----data---->| 648 incoming outgoing 650 Figure 9. Request driven trigger 651 (interception of resp. incoming and outgoing control messages) 653 The downstream LSR (LSRd) sends a control message to the upstream LSR 654 (LSRu). In the case that incoming control messages are intercepted 655 and the MPLS module in LSRu decides to establish an LSP it will send 656 an LDP bind (upstream mode) or an LDP bind request (downstream-on- 657 demand mode) to LSRd. 659 Currently, for multicast, we can identify two important types of 660 control messages: the multicast routing messages and the resource 661 reservation messages. 663 5.1.2. Multicast routing messages 665 In principle, this mechanism can only be used by IP multicast routing 666 protocols which use explicit signaling: e.g. the Join messages in 667 PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to 668 support this type of trigger [FARI], however, at the cost of 669 modifying the IP multicast routing protocol itself ! 671 IP multicast routing messages can create both hard states (e.g. CBT 672 Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent 673 periodically). The latter generates more control traffic for tree 674 maintenance and thus requires more processing in the MPLS module. 676 Triggers based on the multicast routing protocol messages have the 677 disadvantage that the routing calculations performed by the multicast 678 routing daemon to determine the Multicast Routing Table are repeated 679 by the MPLS module. The former determines the tree that will be used 680 at L3, the latter calculates an identical tree to be used by L2. 681 Since the same task is performed twice, it is better to create the 682 multicast LSP on the basis of information extracted from the 683 Multicast Routing Table itself (see section 5.2 and 5.3). The 684 routing calculations become more complex for protocols which support 685 a switch-over from a (*, G) tree to a (S, G) tree because more 686 messages have to be interpreted. 688 When a host has a point-to-point connection to the first router one 689 could create 'LSPs up to the end-user' by intercepting not only the 690 multicast routing messages but the IGMP Join/Prune messages ([FENN]) 691 as well. 693 5.1.3. Resource reservation messages 695 As is the case for unicast the RSVP Resv message can be used as a 696 trigger to establish LSPs. A source of a multicast group will send 697 an RSVP Path message down the tree, the receivers can then reply with 698 an RSVP Resv message. RSVP scales equally well for multicast as it 699 does for unicast because: 701 a) RSVP Resv messages can merge. 703 b) RSVP Resv messages are only sent up to the first branch which made 704 the required reservation. 706 More on RSVP in the sections on Piggy-backing (section 6) and QoS 707 (section 8). 709 5.2. Topology driven 711 The Multicast Routing Table (MRT) is maintained by the IP multicast 712 routing protocol daemon (e.g. PIM/pimd, DVMRP/mrouted). The MPLS 713 module maps this L3 tree topology information to L2 p2mp LSPs. 715 The MPLS module can poll the MRT to extract the tree topologies. 716 Alternatively, the multicast daemon can be modified to notify the 717 MPLS module directly of any change to the MRT. 719 The disadvantage of this method is that labels are consumed even when 720 no traffic exists. 722 5.3. Traffic driven 724 5.3.1. General 726 A traffic driven trigger method will only construct LSPs for trees 727 which carry traffic. It consumes less labels than the topology 728 driven method, as labels are only allocated when there is traffic on 729 the multicast tree. 731 If the mixed L2/L3 forwarding capability (see section 4) is not 732 supported, the traffic driven trigger requires a label distribution 733 mode in which the label is requested by the LSRu (downstream-on- 734 demand or upstream mode). In Figure 10, suppose an LSP for a certain 735 group exists to LSRd1 and another LSRd2 wants to join the tree. In 736 order for LSRd2 to initiate a trigger, it must already receive the 737 traffic from the tree. This can be either at L2 or at L3. The former 738 case is a chicken and egg problem. The latter case requires a mixed 739 L2/L3 forwarding capability in LSRu to add the L3 branch. 741 +--------+ 742 | LSRd1 | 743 | | 744 +--------+ | L3 | 745 | LSRu | +--------+ 746 | | | | 747 | L3 | +--------------------------> 748 +--------+ / | L2 | 749 | | / +--------+ 750 ->-------------+ 751 | L2 | +--------+ 752 +--------+ | LSRd2 | 753 | | 754 | L3 | 755 +--------+ 756 | | 757 | | 758 | L2 | 759 +--------+ 761 Figure 10. The LSRu has to request the label. 763 5.3.2. An implementation example 765 To illustrate that by choosing an appropriate trigger one can obtain 766 that MPLS multicast is independent of the deployed multicast routing 767 protocol following implementation example is given. 769 Current implementations on Unix platforms of IP multicast routing 770 protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The 771 MFC is a cached copy of the Multicast Routing Table. The MFC 772 requests an entry for a certain multicast group when it experiences a 773 'cache miss' for an incoming multicast packet. The missing routing 774 information is provided by the multicast daemon. If at a later point 775 in time something changes to the route (outgoing interfaces added or 776 removed), the multicast daemon will update the MFC. 778 The MFC is implemented as a common component (part of the kernel), 779 which makes this trigger very attractive because it can be 780 transparently used for any IP multicast routing protocol. 782 Entries in the MFC are removed when no traffic is received for this 783 entry for a certain period of time. When label switching is applied 784 to a certain MFC-entry, the L3 will not see any packets arriving 785 anymore. To retain the normal MFC behavior, the L3 counters of the 786 MFC need to be updated by L2 measurements. 788 5.4. Combinations of triggers and label distribution modes 790 Table 2 shows the valid combinations of label distribution modes and 791 trigger types which were discussed in the previous sections. The (X) 792 means that the combination is valid when the mixed L2/L3 forwarding 793 feature is supported in the LSR. 795 +----------------+-------------------------------------------+ 796 | | label requested by | 797 | | LSRu | LSRd | 798 | +---------------------+---------------------+ 799 | | upstream |downstream|downstream| upstream | 800 | | |on demand | | on demand| 801 +----------------+----------+----------+----------+----------+ 802 |Request Driven | | | | | 803 |(incoming msg) | X | X | | | 804 +----------------+----------+----------+----------+----------+ 805 |Request Driven | | | | | 806 |(outgoing msg) | | | X | X | 807 +----------------+----------+----------+----------+----------+ 808 |Topology Driven | X | X | X | X | 809 +----------------+----------+----------+----------+----------+ 810 |Traffic Driven | X | X | (X) | (X) | 811 +----------------+----------+----------+----------+----------+ 813 Table 2. Valid combinations of triggers and label distribution modes 815 6. Piggy-backing 817 In Figure 9 (outgoing case) one can observe that instead of sending 2 818 separate messages the label advertisement can be piggy-backed on the 819 existing control messages. For multicast two piggy-back candidates 820 exist: 822 a) Multicast routing messages: protocols as PIM-SM and CBT have 823 explicit Join messages which could carry the label mappings. This 824 approach is described in [FARI]. When different multicast routing 825 protocols are deployed, an extension to each of these protocols has 826 to be defined. 828 b) RSVP Resv messages: a label mapping extension object for RSVP, 829 also applicable to multicast, is proposed in [DAVI]. 831 The pro and cons of piggy-backing on multicast routing messages will 832 be described now. 834 Piggy-backing has following advantages: 836 a) If label advertisement is piggy-backed on multicast routing 837 messages, then the distribution of routes and the distribution of 838 labels is tightly synchronized. This eliminates difficult corner 839 cases such as "what do I do with a label if I don't (yet) have a 840 routing table entry to attach it to?". It also minimizes the 841 interval between the establishment of the multicast route and the 842 mapping of a label to the route. 844 b) The number of control messages needed to support label 845 advertisement beyond those needed to support the multicast routing 846 itself is zero. 848 Following disadvantages of piggy-backing can be identified: 850 a) In dense-mode protocols there are no messages on which the label 851 advertisement can be piggy-backed. [FARI] proposes to add periodic 852 messages to dense-mode protocols for the purpose of label 853 advertisement, which is a heavy impact on the multicast routing 854 protocol and it eliminates the message conserving benefit of piggy- 855 backing. 857 b) The second solution for the state co-existence problem (section 858 3.4) can not be applied in combination with piggy-backing. 860 c) Piggybacking requires extending the multicast routing protocol, 861 and hence becomes less attractive if label advertisement needs to be 862 supported for multiple routing protocols. Especially when not only 863 the label advertisement but also the other two LDP functions 864 (discovery and adjacency) are piggy-backed. 866 d) Piggy-backing assumes the downstream label distribution mode, this 867 excludes a number of trigger methods (see Table 2). 869 e) LDP normally runs on top of TCP, assuring a reliable communication 870 between peer nodes. Piggy-backed label advertisement often replaces 871 the reliable communication with periodic soft-state label 872 advertisements. Because of this periodic label advertisement the 873 control traffic (in number of bytes) will increase. 875 f) If a VCID notification mechanism [NAGA] is required, the (in-band) 876 notification can normally be done by sending the LDP bind through the 877 newly established VC. This way only one message is required. This 878 method cannot be combined with piggy-backing because the routing 879 message is sent before the VC can be established. An extra handshake 880 message is thus required, diminishing the benefit of piggy-backing. 882 So whether piggy-backing makes sense or not depends heavily on which 883 and how many multicast routing protocols are deployed, whether LDP is 884 already used for unicast, which trigger mechanism is used, ... . 885 Piggybacking is just one possible component of an MPLS multicast 886 solution. 888 7. Explicit routing 890 Explicit routing for unicast refers to overriding the unicast routing 891 table by using LSPs. A first way to interpret "multicast explicit 892 routing" is overriding the multicast routing table by another LSP 893 tree (e.g. a centrally calculated Steiner tree). 895 A second way of interpreting "multicast explicit routing" is that 896 multicast routing protocols use the explicit unicast routes to 897 construct trees. However this approach creates some problems: 899 1) The unicast explicit paths need to be bidirectional so that the 900 multicast data (from source to receiver) and the multicast routing 901 messages (from receiver to source) follow the same path. 903 2) The RPF check also has to take into account the explicit path. 905 8. QoS/CoS 907 8.1. DiffServ 909 The Differentiated Services approach can be applied to multicast as 910 well. It introduces finer stream granularities (Class of Service 911 (CoS) as an extra differentiator). A sender can construct one or 912 more trees with different CoS bits. 914 These (S, G, CoS) or (*, G, CoS) trees can be mapped very easily onto 915 LSPs when the traffic driven trigger is used. In this case one can 916 create LSPs with different attributes for the various classes. Note 917 however that these LSPs still use the same route as long as the tree 918 construction mechanism does not support a class identifier, this 919 means that the multicast routing protocol has to interpret the CoS 920 bits in the join messages and create (S, G, CoS) state in the 921 routers. 923 8.2. IntServ and RSVP 925 RSVP can be used to setup multicast trees with QoS. An important 926 multicast issue is the problem of how to map the 'heterogeneous 927 receivers' paradigm onto L2 (remark that it is not solved in IP 928 either). This subject is tackled in [CRAW]. Pragmatic approaches 929 are the 'Limited Heterogeneity Model' which allows a best effort 930 service and a single alternate QoS (e.g. a QoS proposed by the sender 931 in a RSVP Path message) and the 'Homogeneous Model' which allows only 932 a single QoS. 934 The first approach will construct full trees for each service class. 935 The sender has to send its traffic twice across the network (1 best- 936 effort and 1 QoS tree). Both trees can be label switched. 938 The second approach constructs one tree and the best-effort users are 939 connected to the QoS tree. If the branches created for best-effort 940 users are not to be label switched, (thus carried by a hop-by-hop 941 default LSP) the QoS multicast traffic has to be merged onto these 942 default LSPs. This function can be provided by the 'mixed L2/L3 943 forwarding' feature described in section 4. If this is not available 944 merging is necessary to avoid a return to L3 in the QoS LSP. 946 The mapping of the IntServ service categories onto L2 for ATM service 947 categories is studied in [GARR]. 949 9. Multi-access networks 951 Multicast MPLS on multi-access networks poses a special problem. An 952 LSR that wants to join a group must always be ready to accept the 953 label that is already assigned to the group LSP (to another 954 downstream LSR on the link). This can be achieved in three ways: 956 1) Each LSR on the multi-access link memorizes all the advertised 957 labels on the link, even if it has not received a join for the 958 associated group. If an LSR is added to the multi-access link it has 959 to retrieve this information from another LSR on the link or in case 960 of soft state label advertisement it can wait a certain time before 961 it can allocate labels itself. If LSRs allocate a label 'at the same 962 moment' the LSR with the highest IP address could keep it, while the 963 other LSRs withdraw the label. 965 2) Each LSR gets its own label range to allocate labels from. A 966 mechanism for label partitioning is described in [FAR2]. If an LSR 967 is added to the multi-access link the label ranges have to be 968 negotiated again and possibly existing LSPs are teared down and are 969 reconstructed with other labels. 971 3) Per multi-access link one LSR could be elected to be responsibe 972 for label allocation. When an LSR needs a label, it can request it 973 from this Label Allocation LSR. 975 Unlike the unicast case, a multicast stream can have more than one 976 downstream LSR which all have to use the same label. Two solutions 977 for label advertisement can be thought of: 979 1) [FARI] proposes to multicast the label advertisements to all LSRs 980 on the shared link. Since multicast is not reliable this requires 981 periodic label advertisements, yielding label advertisement 982 duplicates in time. 984 2) Another approach is that an LSR unicasts its label advertisements 985 in a reliable way (TCP) to all other (or to all interested) LSRs on 986 the shared link. In this approach the hard-state character of LDP 987 can be maintained but the label advertisement is duplicated in space. 989 Since LSPs are only rewarding if they have a long lifetime and since 990 the number of LSRs on a shared link is limited the second approach 991 seems advantageous. 993 Another issue with multicast in multi-access networks is whether to 994 use upstream or downstream label advertisement. For multicast 995 traffic, upstream label allocation is simpler since there can be only 996 one upstream node per link that belongs to a multicast tree. This 997 (upstream) node can assign a label without any contention. With 998 downstream allocation, there may be multiple downstream nodes for a 999 given tree on a multi-access link; each node may propose a label 1000 assignment leading to contention and a contention resolution scheme 1001 is required to chose one of them as the label allocator. 1003 Once a label has been assigned, it is possible that the label 1004 assigner leaves the tree. With downstream label assignment, this 1005 could happen when the label allocator leaves the group. With 1006 upstream assignment this could happen when the upstream LSR changes 1007 due to a unicast topology change. 1009 10. More issues 1011 10.1. TTL field 1013 The TTL field in the IP header is typically used for loop detection. 1014 In IP multicast it is also used to limit the scope of the multicast 1015 packets by setting an appropriate TTL value. 1017 Thus in LSRs that do not support a TTL decrement function (e.g ATM 1018 LSR), the scope restriction function is affected. Suppose one could 1019 calculate in advance the number of hops an LSP traverses. In a 1020 unicast LSP the TTL value could then be decremented at the ingress or 1021 the egress node. For multicast all the branches of the tree can have 1022 different lengths so the TTL can only be decremented at the egress 1023 node, potentially wasting bandwidth if the TTL turns out to be zero 1024 or negative. 1026 10.2. Independent vs. Ordered Label Distribution Control 1028 Current Label Distribution Terminology is only defined for unicast. 1029 The following sections explore what this terminology might mean in a 1030 multicast context. 1032 In Independent Control ([ANDE]) each LSR can take the initiative to 1033 do a label mapping. In Ordered Control ([ANDE]) an LSR only maps a 1034 label when it already received a label from its next-hop. 1036 All the previously described trigger methods (section 5) combine with 1037 Independent Control. Note that if the request driven approach is 1038 used with Independent Control the label distribution still behaves as 1039 in Ordered Control: the control messages flow from the egress node 1040 upstream, imposing the same sequence to the label advertisement. 1042 Ordered Control is not applicable for a traffic driven trigger in 1043 case the node does not support mixed L2/L3 forwarding. According to 1044 Table 2, this case implies that labels are requested by the upstream 1045 LSR. Suppose in Figure 11 that an LSP exists from S to R1 and a new 1046 branch must be added to R2. B will only accept a label on the A-B 1047 link if a label is already assigned on the B-C link. However, to 1048 establish a label on the B-C link, B must already receive traffic on 1049 the A-B link. 1051 N---N---R1 1052 / 1053 / 1054 S -----A 1055 \ 1056 \ 1057 B---C---R2 1059 Figure 11. 1061 10.3. Conservative vs. Liberal Label Retention Mode 1063 In the Conservative Mode ([ANDE]) only the labels that are used for 1064 forwarding data (if the next-hop for the FEC is the LSR which 1065 advertised the label) are allocated and maintained. In the Liberal 1066 Mode labels are advertised and maintained to all neighbors. 1068 Liberal Mode does not make sense in multicast. Two reasons can be 1069 identified for this: 1071 1) All LSRs have a route for each unicast FEC. This is not true for 1072 multicast FECs. 1074 2) For multicast an LSR always knows to which neighbor to send the 1075 label request or the label map messages. In e.g. unicast downstream 1076 mode (see below) the LSR does not know where to send the label 1077 mappings and thus has to send the mapping to all its neighbors. In 1078 this case supporting the Liberal Mode does not generate extra 1079 messages (it still requires extra state information and label space) 1080 and thus the threshold to support Liberal Mode could be considered 1081 lower. 1083 Table 3 shows the cases where it is known by an LSR where to send its 1084 label requests. 1086 +---------+----------------------------------+ 1087 | | label requested by | 1088 | | LSRu | LSRd | 1089 +---------+----------------+-----------------| 1090 |unicast | Yes | No | 1091 +---------+----------------+-----------------| 1092 |multicast| Yes | Yes | 1093 +---------+----------------+-----------------+ 1095 Table 3. Does an LSR know where to send its label requests ? 1097 For a unicast flow, an LSR can determine the next hop LSR, which is 1098 the one to send the request to in case of upstream or downstream-on- 1099 demand mode. The LSR is however not able to find the previous hop. 1100 The previous hop is not necessarily the next hop towards the source, 1101 because the path from A to B is not necessarily the same as the path 1102 from B to A. Such a situation can occur as a result of asymmetric 1103 link measures or in the event that multiple equal cost paths exist 1104 [PAXS]. 1106 In the case of multicast, an LSR knows both the next hop(s) and the 1107 previous hop. Because multicast trees are constructed using the 1108 reverse shortest path method, the previous hop is always the next hop 1109 towards the source or towards the root of the tree. 1111 10.4. Downstream vs. Upstream Label Allocation 1113 The label can be allocated by either the downstream LSR (downstream- 1114 on-demand, downstream) or the upstream LSR (upstream-on-demand, 1115 upstream, implicit). The advantages of downstream label allocation 1116 are: 1118 a) It is the same mode as for unicast LDP, thus eliminating the need 1119 to develop upstream label distribution procedures. 1121 b) The same label can be kept when the upstream LSR changes due to a 1122 route change, which is an advantage on multi-access networks (see 1123 section 9). 1125 c) Compatible with piggybacking (especially the downstream 1126 distribution mode). 1128 The advantages of upstream label allocation are: 1130 a) Easier label allocation in multi-access networks (see section 9). 1132 b) The same label can be kept when the downstream LSR (which would 1133 have been the label allocator in downstream mode in a multi-access 1134 network) leaves the group (see section 9). 1136 c) The upstream and implicit distribution mode allow a faster LSP 1137 setup when the LSP is traffic triggered. 1139 10.5. Explicit vs. Implicit Label Distribution 1141 Beside the explicit distribution modes (which use a signaling 1142 protocol), [ACHA] proposes an implicit label distribution method by 1143 using unknown labels. This method has all the advantages of the 1144 upstream label allocation method and is probably the fastest label 1145 advertisement method for traffic triggered LSPs. 1147 Implicit label distribution is not applicable if the FEC-to-label 1148 binding has been advertised prior to traffic arrival, e.g. explicit 1149 routing (i.e. if all the information necessary to identify the FEC is 1150 not present in the packet). 1152 Explicit distribution allows pre-establishment (before the arrival of 1153 data) of LSPs with topology or request driven triggers. 1155 11. Security Considerations 1157 Security considerations are not discussed in this version of the 1158 document. 1160 12. Acknowledgements 1162 The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip 1163 Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard 1164 Gastaud for the fruitful discussions and/or their thorough revision 1165 of this document. 1167 References 1169 [ACHA] A. Acharya, F. Griffoul, F. Ansari, "IP Multicast Support in 1170 MPLS Networks", IETF Draft, draft-acharya-ipsofacto-mpls-mcast- 1171 00.txt, February 1999. 1173 [ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, 1174 "Label Distribution Protocol", IETF Draft, draft-mpls-ldp- 1175 03.txt, January 1999. 1177 [BALL] A. Ballardie, B. Cain, Z. Zhang, "Core Based Trees (CBT, v3) 1178 Multicast Routing - Protocol Specification", IETF Draft, draft- 1179 ietf-idmr-cbt-spec-v3-01.txt, August 1998. 1181 [CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A. 1182 Viswanathan, "A Framework for Multiprotocol Label Switching", 1183 IETF Draft, draft-ietf-mpls-framework-02.txt, November 1997. 1185 [CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame 1186 Relay Networks", IETF Draft, draft-ietf-mpls-fr-03.txt, November 1187 1998. 1189 [CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden 1190 and J. Krawczyk, "A Framework for Integrated Services and RSVP 1191 over ATM", IETF Draft, RC2382, August 1998. 1193 [DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. 1194 Swallow and P. Doolan, "MPLS using ATM VC switching", IETF 1195 Draft, draft-ietf-mpls-atm-01.txt, November 1998. 1197 [DAV2] B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan 1198 and S. Blake, "Use of Label Switching With RSVP", IETF Draft, 1199 draft-ietf-mpls-rsvp-00.txt, March 1998 1201 [DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 1202 Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, 1203 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 1204 Specification", RFC 2117, June 1997. 1206 [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol 1207 Independent Multicast Version 2 Dense Mode Specification", IETF 1208 Draft, draft-ietf-pim-v2-dm-01.txt, November, 1998. 1210 [FARI] D. Farinacci and Y. Rekhter, "Multicast Tag Binding and Distri- 1211 bution using PIM", IETF Draft, draft-farinacci-multicast-tagsw- 1212 00.txt, December 1996. 1214 [FAR2] D. Farinacci and Y. Rekhter, "Partitioning Tag Space among Mul- 1215 ticast Routers on a Common Subnet", IETF Draft, draft- 1216 farinacci-multicast-tag-part-00.txt, December 1996. 1218 [FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version 1219 2", RFC 2236, November 1997. 1221 [GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load 1222 Service and Guaranteed Service with ATM", IETF Draft, RFC2381, 1223 August 1998. 1225 [KATS] Y. Katsube, Y. Ohba and K. Nagami, "Two Modes of MPLS Explicit 1226 Label Distribution Protocol", IETF Draft, draft-katsube-mpls- 1227 two-ldp-00.txt, September 1997. 1229 [MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. 1231 [NAGA] K. Nagami, N. Demizu, H. Esaki and P. Doolan, "VCID Notification 1232 over ATM link", IETF Draft, draft-ietf-mpls-vcid-atm-00.txt; 1233 March 1998. 1235 [PERL] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. 1236 Maufer, "Simple Multicast", IETF Draft, draft-perlman-simple- 1237 multicast-02.txt, February 1999. 1239 [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", IETF 1240 Draft, draft-ietf-idmr-dvmrp-v3-05, October 1997. 1242 [PARS] M. Parsa and J. Garcia-Luna-Aceves, "A protocol for scaleable 1243 loop-free multicast routing", IEEE JSAC, vol.15, no.3, p.316- 1244 331, April 1997 1246 [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", 1247 IEEE/ACM Transactions on Networking 5(5), pp. 601-615. 1249 [ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. 1250 Li, A. Conta, "MPLS Label Stack Encoding", IETF draft, draft- 1251 ietf-mpls-label-encaps-03.txt, September 1998. 1253 Authors Addresses 1255 Dirk Ooms 1256 Alcatel Corporate Research Center 1257 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1258 Phone : 32-3-240-4732 1259 Fax : 32-3-240-9932 1260 E-mail: Dirk.Ooms@alcatel.be 1262 Wim Livens 1263 Alcatel Corporate Research Center 1264 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1265 Phone : 32-3-240-7570 1266 E-mail: Wim.Livens@alcatel.be 1268 Bernard Sales 1269 Alcatel Corporate Research Center 1270 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1271 Phone : 32-3-240-9574 1272 E-mail: Bernard.Sales@alcatel.be 1274 Maria Fernanda Ramalho 1275 Alcatel Corporate Research Center 1276 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1277 Phone : 32-3-240-9725 1278 E-mail: Maria.Ramalho@alcatel.be 1280 Arup Acharya 1281 C&C Research Labs, NEC USA 1282 4 Independence Way, Princeton, NJ, USA 1283 Phone : 1 609 951 2992 1284 Fax : 1 609 951 2499 1285 E-mail: arup@ccrl.nj.nec.com 1287 Frederic Griffoul 1288 C&C Research Labs, NEC Europe Ltd. 1289 Adenauerplatz 6, D-69115 Heidelberg, Germany 1290 Phone : 49 6221 905 1120 1291 Fax : 49 6221 905 1155 1292 E-mail: griffoul@ccrle.nec.de 1294 Furquan Ansari 1295 Bell Labs 1296 101 Crawfords Corner Rd., Holmdel, NJ 07733 1297 Phone : 1 732 949 5149 1298 Fax : 1 732 332 6511 1299 E-mail: furquan@dnrc.bell-labs.com