idnits 2.17.1 draft-ietf-mpls-multicast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 109 has weird spacing: '... mp2mp mult...' == Line 110 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.) -- The document date (May 2000) is 8747 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) == Unused Reference: 'CALL' is defined on line 1172, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ACHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'AWDU' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANDE' ** Downref: Normative reference to an Historic RFC: RFC 2201 (ref. 'BALL') -- Possible downref: Non-RFC (?) normative reference: ref. 'CALL' -- Possible downref: Non-RFC (?) normative reference: ref. 'CONT' ** Downref: Normative reference to an Informational RFC: RFC 2382 (ref. 'CRAW') -- Possible downref: Non-RFC (?) normative reference: ref. 'DAVI' ** Obsolete normative reference: RFC 2117 (ref. 'DEER') (Obsoleted by RFC 2362) -- Possible downref: Non-RFC (?) normative reference: ref. 'DEE2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FARI' -- Possible downref: Non-RFC (?) normative reference: ref. 'FAR2' -- Possible downref: Non-RFC (?) normative reference: ref. 'HOLB' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOY') -- Possible downref: Non-RFC (?) normative reference: ref. 'NAGA' -- Possible downref: Non-RFC (?) normative reference: ref. 'PERL' -- Possible downref: Non-RFC (?) normative reference: ref. 'PUSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'PAXS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROSE' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Ooms, B. Sales 2 Internet Draft Alcatel 3 Expiration Date: November 2000 W. Livens 4 Colt Telecom 5 A. Acharya 6 IBM 7 F. Griffoul 8 Ulticom 9 F. Ansari 10 Bell Labs 12 May 2000 14 Framework for IP Multicast in MPLS 16 draft-ietf-mpls-multicast-01.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document offers a framework for IP multicast deployment in an 42 MPLS environment. Issues arising when MPLS techniques are applied to 43 IP multicast are overviewed. The pros and cons of existing IP 44 multicast routing protocols in the context of MPLS are described and 45 the relation to the different trigger methods and label distribution 46 modes are discussed. The consequences of various layer 2 (L2) 47 technologies are listed. Both point-to-point and multi-access 48 networks are considered. 50 Table of Contents 52 1. Introduction 53 2. Layer 2 characteristics 54 3. Taxonomy of IP multicast routing protocols in the context of MPLS 55 3.1. Aggregation 56 3.2. Flood & Prune 57 3.3. Source/Shared trees 58 3.4. Co-existence of Source and Shared Trees 59 3.5. Uni/Bi-directional Shared Trees 60 3.6. Encapsulated multicast data 61 3.7. Loop-free-ness 62 3.8. RPF Check 63 3.9. Mapping of characteristics on existing protocols 64 4. Mixed L2/L3 forwarding in a single node 65 5. Taxonomy of IP multicast LSP triggers 66 5.1. Request driven 67 5.1.1. General 68 5.1.2. Multicast routing messages 69 5.1.3. Resource reservation messages 70 5.2. Topology driven 71 5.3. Traffic driven 72 5.3.1. General 73 5.3.2. An implementation example 74 5.4. Combinations of triggers and label distribution modes 75 6. Piggy-backing 76 7. Explicit routing 77 8. QoS/CoS 78 8.1 DiffServ 79 8.2 IntServ and RSVP 80 9. Multi-access networks 81 10. More issues 82 10.1. TTL field 83 10.2. Independent vs. Ordered Label Distribution Control 84 10.3. Conservative vs. Liberal Label Retention Mode 85 10.4. Downstream vs. Upstream Label Allocation 86 10.5. Explicit vs. Implicit Label Distribution 87 11. Security Considerations 88 12. Acknowledgements 90 Table of Abbreviations 92 ATM Asynchronous Transfer Node 93 CBT Core Based Tree 94 CoS Class of Service 95 DLCI Data Link Connection Identifier 96 DRrecv Designated Router of the receiver 97 DRsend Designated Router of the sender 98 DVMRP Distant Vector Multicast Routing Protocol 99 FR Frame Relay 100 IGMP Internet Group Management Protocol 101 IP Internet Protocol 102 L2 layer 2 (e.g. ATM, Frame Relay) 103 L3 layer 3 (e.g. IP) 104 LSP Label Switched Path 105 LSR Label Switching Router 106 LSRd Downstream LSR 107 LSRu Upstream LSR 108 MOSPF Multicast OSPF 109 mp2mp multipoint-to-multipoint 110 p2mp point-to-multipoint 111 PIM-DM Protocol Independent Multicast-Dense Mode 112 PIM-SM Protocol Independent Multicast-Sparse Mode 113 QoS Quality of Service 114 RP Rendezvous Point 115 RPF Reverse Path Forwarding 116 RSVP Resource reSerVation Protocol 117 SSM Source Specific Multicast 118 TCP Transmission Control Protocol 119 UDP User Datagram Protocol 120 VC Virtual Circuit 121 VCI Virtual Circuit Identifier 122 VP Virtual Path 123 VPI Virtual Path Identifier 125 Changes - clean up references - changes to section of Explicit 126 Routing - added SSM to multicast protocol taxonomy 128 1. Introduction 130 In an MPLS cloud the routes are determined by a L3 routing protocol. 131 These routes can then be mapped onto L2 paths to enhance network 132 performance. Besides this, MPLS offers a vehicle for enhanced 133 network services such as QoS/CoS, traffic engineering, etc. 135 Current unicast routing protocols generate a same (optimal) shortest 136 path in steady state for a certain (source, destination)-pair. Remark 137 that unicast protocols can behave slightly different with regard to 138 equal cost paths. 140 For multicast, the optimal solution (minimum cost to interconnect N 141 nodes) would impose a Steiner tree computation. Unfortunately, no 142 multicast routing protocol today is able to maintain such an optimal 143 tree. Different multicast protocols will therefore, in general, 144 generate different trees. 146 The discussion is focused on intra-domain multicast routing 147 protocols. Aspects of inter-domain routing are beyond the scope of 148 this document. 150 2. Layer 2 characteristics 152 Although MPLS is multiprotocol both at L3 and at L2, in practice IP 153 is the only considered L3 protocol. MPLS can run on top of several 154 L2 technologies (PPP/Sonet, Ethernet, ATM, FR, ...). 156 When label switching is mapped on L2 switching capabilities (e.g. 157 VPI/VCI is used as label), attention is mainly focused on the mapping 158 to ATM [DAVI]. ATM offers high switching capacities and QoS 159 awareness, but in the context of MPLS it poses several limitations 160 which are described in [DAVI]. Similar considerations are made for 161 Frame Relay on L2 in [CONT]. The limitations can be summarized as: 163 - Limited Label Space: either the standardized or the implemented 164 number of bits available for a label can be small (e.g. VPI/VCI 165 space, DLCI space), limiting the number of LSPs that can be 166 established. 168 - Merging: some L2 technologies or implementations of these 169 technologies do not support multipoint-to-point and/or multipoint- 170 to-multipoint 'connections', obstructing the merging of LSPs. 172 - TTL: L2 technologies do not support a 'TTL-decrement' function. 174 All three limitations can impact the implementation of multicast in 175 MPLS as will be described in this document. 177 When native MPLS is deployed the above limitations vanish. Moreover 178 on PPP and Ethernet links the same label can be used at the same time 179 for a unicast and a multicast LSP because different EtherTypes for 180 MPLS unicast and multicast are defined [ROSE]. 182 3. Taxonomy of IP multicast routing protocols in the context of MPLS 184 At the moment, an abundance of IP multicast routing protocols is 185 being proposed and developed. All these protocols have different 186 characteristics (scalability, computational complexity, latency, 187 control message overhead, tree type, etc...). It is not the purpose 188 of this document to give a complete taxonomy of IP multicast routing 189 protocols, only their characteristics relevant to the MPLS technology 190 will be addressed. 192 Following characteristics are considered: 194 - Aggregation 195 - Flood & Prune 196 - Source/Shared trees 197 - Co-existence of Source and Shared Trees 198 - Uni/Bi-directional shared trees 199 - Encapsulated multicast data 200 - Loop-free-ness 201 - RPF check 203 The discussion of these characteristics will not lead to the 204 selection of one superior multicast routing protocol. It is not 205 impossible that different IP multicast routing protocols will be 206 deployed in the Internet. 208 3.1. Aggregation 210 In unicast different destination addresses are aggregated to one 211 entry in the routing table, yielding one FEC and one LSP. 213 The granularity of multicast streams is (*, G) for a shared tree and 214 (S, G) for a source tree, S being the source address and G the 215 multicast group address. Aggregation of multicast trees with 216 different multicast 'destination' addresses on one LSP is a subject 217 for further study. 219 3.2. Flood & Prune 221 To establish a multicast tree some IP multicast routing protocols 222 (e.g. DVMRP, PIM-DM) flood the network with multicast data. The 223 branches can then be pruned by nodes which do not want to receive the 224 data of the specific multicast group. This process is repeated 225 periodically. 227 Flood & Prune multicast routing protocols have some characteristics 228 which significantly differ from unicast routing protocols: 230 a) Volatile. Due to the Flood & Prune nature of the protocol, very 231 volatile tree structures are generated. Solutions to map a dynamic 232 L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of 233 signaling overhead and LSP setup time. The volatile L2 LSP will 234 consume a lot of labels throughout the network, which is a 235 disadvantage when label space is limited. 237 b) Traffic-driven. The router only creates state for a certain group 238 when data arrives for that group. Routers also independently decide 239 to remove state when an inactivity timer expires. 240 - Thus LSPs can not be pre-established as is usually done in 241 unicast. To minimize the time between traffic arrival and LSP 242 establishment a fast LSP setup method is favorable. 243 - Since creation and deletion of a L3 route at each node is 244 triggered by traffic, this suggests that the LSP associated with the 245 route be setup and torn down in a traffic-driven manner as well. 246 - If an LSR does not support L3 forwarding this traffic-driven 247 nature even requires that the upstream LSR takes the initiative to 248 create an LSP (Upstream Unsolicited or Downstream on Demand label 249 advertisement). 251 3.3. Source/Shared trees 253 IP multicast routing protocols create either source trees (S, G), 254 i.e. a tree per source (S) and per multicast group (G), or shared 255 trees (*, G), i.e. one tree per multicast group (Figure 1). 257 R1 R1 R1 258 S1 / / / 259 \ / / / 260 \ / / / 261 C---R2 S1---R2 S2---R2 262 / \ \ \ 263 / \ \ \ 264 S2 \ \ \ 265 R3 R3 R3 267 Figure 1. Shared tree and Source trees 269 The advantage of using shared trees, when label switching is applied, 270 is that shared trees consume less labels than source trees (1 label 271 per group versus 1 label per source and per group). 273 However, mapping a shared tree end-to-end on L2 implies setting up 274 multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing 275 mp2mp LSPs boils down to the merging problem discussed earlier. 277 Note that in practice shared trees are often only used to discover 278 new sources of the group and a switchover to a source tree is made at 279 very low bitrates. 281 3.4. Co-existence of Source and Shared Trees 283 Some protocols support both source and shared trees (e.g. PIM-SM) and 284 one router can maintain both (*, G) and (S, G) state for the same 285 group G. Two cases of state co-existence are described below. 286 Assume topologies with senders Si and receivers Ri. RP is the 287 Rendezvous Point. Ni are LSRs. The numbers are the interface 288 numbers, Reg is the Register interface. All IGMP and PIM Join/Prune 289 messages are shown in the figures. It is also indicated whether the 290 RPT-bit is set for the (S, G) state. 292 1) Figure 2 shows a switchover from shared to source tree. Assume 293 that the shortest path from R1 to RP is via N1-N2-N5. N1, the 294 Designated Router of receiver R1 (DRrecv), decides to initiate a 295 source tree for source S1. After the arrival of data via the source 296 tree in N2, N2 will send a prune to N5 for source S1. State co- 297 existence occurs in the node where the overlap of shared and source 298 tree starts (N2) and in the node where S1 does not need forwarding on 299 the shared tree anymore (N5). 301 PJ 302 IJ PJS PJS 303 -> 1 2 -> 1 2 -> 1 2 304 R1-----N1------N2------N3----S1 305 3| |3 IJ=Igmp Join 306 ||PPS | PJ=Pim Join (*,G) 307 |vPJ | PJS=Pim Join (S1,G) 308 IJ PJ | PJ | PPS=Pim Prune (S1,G) 309 -> -> |3 -> | 310 R2-----N4------N5------RP----S2 311 1 2 1 2 1 313 Figure 2 315 The multicast routing states created in the MRT are: 317 in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) 318 in N1: (*,G):2->1 319 in N2: (*,G):3->1 320 (S1,G):2->1 321 in N3: (S1,G):2->Reg,1 322 in N4: (*,G):2->1 323 in N5: (*,G):2->1,3 324 (S1,G)RPT-bit:2->1 326 2) Figure 3 shows that even without a switchover, state co-existence 327 can occur. Multicast traffic from a sender will create (S, G) state 328 in the Designated Router of the sender (DRsend; N3 in Figure 3 is the 329 DRsend of S). Each node on a shared-tree has (*, G) state. Thus an 330 on-tree DRsend has both (*, G) and (S, G) state. If the DRsend is 331 on-tree it will also send a prune for S towards the RP, creating (S, 332 G) state in all nodes until the first router which has a branch (N1 333 and N2 in Figure 3). 335 S 336 PPS PPS | 337 PJ PJ PJ |2 PJ IJ 338 1 <- 1 3<- <- | <- <- PJ=Pim Join 339 RP------N1----N2----N3----N4----R1 IJ=Igmp Join 340 ^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G) 341 PJ|| IJ 342 1| <- 343 N5----R2 344 2 345 Figure 3 347 The multicast routing states created in the MRT are: 349 in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) 350 in N1: (*,G):1->2,3 351 (S,G)RPT-bit:1->2 352 in N2: (*,G):1->2 353 (S,G)RPT-bit:1->none 354 in N3: (*,G):1->3 355 (S,G):2->Reg,3 356 in N4: (*,G):1->2 357 in N5: (*,G):1->2 359 In the examples one can observe that two types of state co-existence 360 occur: 362 1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The 363 (*, G) and (S, G) state have different incoming interfaces, but some 364 common outgoing interfaces. It is possible that the traffic of S 365 arrives on both the (*, G) and (S, G) interfaces. In normal L3 366 forwarding the (S, G)SPT-bit entry prohibits the forwarding of the 367 traffic from S arriving on the (*, G) incoming interface. The 368 traffic of S can only temporarily arrive on the incoming interfaces 369 of both the (*, G) and (S, G) entries (until N5 in Figure 2 and N1 in 370 Figure 3 have processed the prune messages). To avoid the temporary 371 forwarding of duplicate packets L3 forwarding can be applied in this 372 type of node. If one does not mind the temporary duplicate packets 373 L2 forwarding can be applied. In this case the (*, G) and (S, G) 374 streams have to be merged into the (*, G) LSP on their common 375 outgoing interfaces. 377 2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The (*, 378 G) and (S, G) state have the same incoming interface. The (S, G) 379 traffic must be extracted from the (*, G) stream. In MPLS this state 380 co-existence can be handled in several ways. Four approaches to this 381 problem will be described: 383 a) A first method to handle this state co-existence is to terminate 384 the LSPs and forward all traffic of this group at L3. However a 385 return to L3 can be avoided in case a (S, G) entry without outgoing 386 interface is added to the MRT (N2 in Figure 3). This entry will only 387 receive traffic temporarily. In this particular case one could 388 ignore the (S, G) state and maintain the existing (*, G) LSP, the 389 disadvantage being duplicate traffic for a very short time. 391 b) A second approach is to assign source specific labels on the nodes 392 of the shared tree. Multiple labels will be associated with one (*, 393 G) entry, corresponding to one label per active source. Since the 394 nodes only know which sources are active when traffic from these 395 sources arrives, the LSPs can not be pre-established and a fast LSP 396 setup method is favorable. 398 c) A third way is that only source trees are labelswitched and that 399 traffic on the shared tree is always forwarded at L3. This assumes 400 that the shared tree is only used as a way for the receivers to find 401 out who the sources are. By configuring a low bitrate switchover 402 threshold one can obtain that the receivers switchover to source 403 trees very quickly. 405 d) In the fourth approach an LSR which has (S, G)RPT-bit state with a 406 non-null oif, advertises a label for (S, G) to the upstream LSR and 407 this label advertisement is then propagated by each upstream LSR 408 towards the RP. In this way a dedicated LSP is created for (S, G) 409 traffic from the RP to the LSR with the (S, G)RPT-bit state. In the 410 latter LSR the (S, G) LSP is merged onto the (*, G) LSP for the 411 appropriate outgoing interfaces. This ensures that (S, G) packets 412 traveling on the shared tree do not make it past any LSR which has 413 pruned S. 415 3.5. Uni/Bi-directional Shared Trees 417 Bidirectional shared trees (e.g. CBT) have the disadvantage of 418 creating a lot of merging points (M) in the nodes (N) of the shared 419 tree. Figure 4 shows these merging points resulting from 2 senders S1 420 and S2 on a bidirectional tree. 422 S1 S2 423 || || 424 v| <- <- <- <- |v 425 <- <- | -> -> -> -> | -> 426 ----N----M----M----M----M----M----N 427 || || || || || || 428 |v |v |v |v |v |v 429 | | | | | | 431 Figure 4. Multicast traffic flows from 2 senders on a bidirectional tree 433 In Figure 5 the same situation for unidirectional shared trees is 434 depicted. In this case the data of the senders is tunneled towards 435 the root node R, yielding only a single merging point, namely the 436 root of the shared tree itself. 438 S1 439 tunnel || S2 440 <----- v| tunnel || 441 to R<------------------------- v| 442 -> -> | -> -> -> -> | -> 443 ----N----N----N----N----N----N----N 444 || || || || || || 445 |v |v |v |v |v |v 446 | | | | | | 448 Figure 5. Multicast traffic flows from 2 senders on a unidirectional tree 450 3.6. Encapsulated multicast data 452 Sources of unidirectional shared trees and non-member sources of 453 bidirectional shared trees encapsulate the data towards the root 454 node. The data is then decapsulated in the root node. The 455 encapsulation and decapsulation of multicast data are L3 processes. 457 Thus in case of encapsulation/decapsulation a path can never be 458 mapped onto an end-to-end LSP: the traffic can not be forwarded on L2 459 on the Register interface of the DRsend (encapsulation), nor can it 460 cross the root (decapsulation) at L2. 462 Remarks: 464 1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G) 465 traffic in DRsend can still be forwarded on L2 on the outgoing 466 interfaces which are not the Register interface. 468 2) The encapsulated traffic can also benefit from MPLS by label 469 switching the tunnels. 471 3) If the root node decides to join the source (to avoid 472 encapsulation/decapsulation), an end-to-end (S, G) LSP can be 473 constructed. 475 3.7. Loop-free-ness 477 Multicast routing protocols which depend on a unicast routing 478 protocol suffer from the same transient loops as the unicast 479 protocols do, however the effect of loops will be much worse in the 480 case of multicast. The reason being, each time a multicast packet 481 goes around a loop, copies of the packet may be emitted from the loop 482 if branches exist in the loop. 484 Currently loop detection is a configurable option in LDP and a 485 decision on the mechanism for loop prevention is postponed. 487 3.8. RPF Check 489 Some protocols perform a Reverse Path Forwarding (RPF) check on the 490 received multicast packets. This mechanism checks whether the packet 491 is received on the interface which is on the shortest path to the 492 source (or root). This mechanism can introduce problems when 493 explicit routing is used (see section 7). Indeed, explicit routing 494 can construct a tree yielding another incoming interface than the 495 RPF-compatible one. 497 3.9. Mapping of characteristics on existing protocols 498 The above characteristics are summarized in Table 1 for a non- 499 exhaustive list of existing IP multicast routing protocols: DVMRP 500 [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], SSM 501 [HOLB], SM [PERL]. 503 +------------------+------+------+------+------+------+------+------+ 504 | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM | 505 +------------------+------+------+------+------+------+------+------+ 506 |Aggregation |no |no |no |no |no |no |no | 507 +------------------+------+------+------+------+------+------+------+ 508 |Flood & Prune |yes |no |no |yes |no |no |option| 509 +------------------+------+------+------+------+------+------+------+ 510 |Tree Type |source|source|shared|source|both |source|shared| 511 +------------------+------+------+------+------+------+------+------+ 512 |State Co-existence|no |no |no |no |yes |no |no | 513 +------------------+------+------+------+------+------+------+------+ 514 |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | 515 +------------------+------+------+------+------+------+------+------+ 516 |Encapsulation |no |no |yes |no |yes |no |yes | 517 +------------------+------+------+------+------+------+------+------+ 518 |Loop Free |no |no |no |no |no |no |no | 519 +------------------+------+------+------+------+------+------+------+ 520 |RPF check |yes |yes |no |yes |yes |yes |no | 521 +------------------+------+------+------+------+------+------+------+ 523 Table 1. Taxonomy of IP Multicast Routing Protocols 525 From Table 1 one can derive e.g. that DVMRP will consume a lot of 526 labels when the Flood & Prune L3 tree is mapped onto a L2 tree. 527 Furthermore since DVMRP uses source trees it experiences no merging 528 problem when label switching is applied. The table can be 529 interpreted in the same way for the other protocols. 531 4. Mixed L2/L3 forwarding in a single node 533 Since unicast traffic has one incoming and one outgoing interface the 534 traffic is either forwarded at L2 OR at L3 (Figure 6). Because 535 multicast traffic can be forwarded to more than one outgoing 536 interface one can consider the case that traffic to some branches is 537 forwarded on L2 and to other branches on L3 (Figure 7). 539 +--------+ +--------+ 540 | L3 | | L3 | 541 | +>>+ | | | 542 | | | | | | 543 +--|--|--+ +--------+ 544 | | | | | | 545 ->-----+ +-----> ->------>>-----> 546 | L2 | | L2 | 547 +--------+ +--------+ 549 Figure 6. Unicast forwarding on resp. L3 or L2 551 +--------+ +--------+ +--------+ 552 | L3 | | L3 | | L3 | 553 | +>>++ | | +>>+ | | | 554 | | || | | | | | | | 555 +--|--||-+ +--|--|--+ +--------+ 556 | | |+----> | | +-----> | +----> 557 ->-----+ | | | |L2 | ->----->>-+ | 558 | L2+-----> ->-----+>>------> | L2 +----> 559 +--------+ +--------+ +--------+ 561 Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2 563 Nodes which support this 'mixed L2/L3 forwarding' feature allow that 564 a multicast tree splits in branches of which some are forwarded at L3 565 while others are switched at L2. 567 The L3 forwarding has to take care that the traffic is not forwarded 568 on those branches that already get their traffic on L2. This can be 569 accomplished by e.g. providing an extra bit in the Multicast Routing 570 Table. 572 Although the mixed L2/L3 forwarding requires processing of the 573 traffic at L3, the load on the L3 forwarding engine is generally less 574 than in a pure L3 node. 576 Supporting this 'mixed L2/L3 forwarding' feature has following 577 advantages: 579 a) Assume LSR A (Figure 8) is an MPLS edge node for the branch 580 towards LSR B and an MPLS root node for the branch towards LSR C. 581 The mixed L2/L3 forwarding allows that the branch towards C is not 582 disturbed by a return to L3 in LSR A. 584 +-------------+ 585 | MPLS cloud | 586 | N | 587 | / \ | 588 | / \ | 589 | / \ | 590 | A N | 591 |/ \ \ | 592 | \ \ | 593 /| \ | 594 B | C | 595 | | 596 +-------------+ 598 Figure 8. Mixed L2/L3 forwarding in node A 600 b) Enables the use of the traffic driven trigger with the Downstream 601 Unsolicited or Upstream on Demand label distribution mode, as 602 explained in section 5.3.1. 604 5. Taxonomy of IP multicast LSP triggers 606 The creation of an LSP for multicast streams can be triggered by 607 different events, which can be mapped on the well known categories of 608 'request driven', 'topology driven' and 'traffic driven'. 610 a) Request driven: intercept the sending or receiving of control 611 messages (e.g. multicast routing messages, resource reservation 612 messages). 614 b) Topology driven: map the L3 tree, which is available in the 615 Multicast Routing Table, to a L2 tree. The mapping is done even if 616 there is no traffic. 618 c) Traffic driven: the L3 tree is mapped onto a L2 tree when data 619 arrives on the tree. 621 5.1. Request driven 623 5.1.1. General 624 The establishment of LSPs can be triggered by the interception of 625 outgoing (requiring that the label is requested by the downstream 626 LSR) or incoming (requiring that the label is requested by the 627 upstream LSR) control messages. Figure 9 illustrates these two 628 cases. 630 LSRu LSRd LSRu LSRd 631 -------+ +--- ---+ +------- 632 | control | | control | 633 <---*<-----message------- <-------message-------*---- 634 | | | | | | 635 trigger| | | | | |trigger 636 | | bind | | bind | | 637 +--------or---------> <---------or----------+ 638 | bind-request | | bind-request | 639 | | | | 640 | | | | 641 |----data----->| |-----data---->| 643 incoming outgoing 645 Figure 9. Request driven trigger 646 (interception of resp. incoming and outgoing control messages) 648 The downstream LSR (LSRd) sends a control message to the upstream LSR 649 (LSRu). In the case that incoming control messages are intercepted 650 and the MPLS module in LSRu decides to establish an LSP it will send 651 an LDP bind (Upstream Unsolicited mode) or an LDP bind request 652 (Downstream on Demand mode) to LSRd. 654 Currently, for multicast, we can identify two important types of 655 control messages: the multicast routing messages and the resource 656 reservation messages. 658 5.1.2. Multicast routing messages 660 In principle, this mechanism can only be used by IP multicast routing 661 protocols which use explicit signaling: e.g. the Join messages in 662 PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to 663 support this type of trigger [FARI], however, at the cost of 664 modifying the IP multicast routing protocol itself ! 666 IP multicast routing messages can create both hard states (e.g. CBT 667 Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent 668 periodically). The latter generates more control traffic for tree 669 maintenance and thus requires more processing in the MPLS module. 671 Triggers based on the multicast routing protocol messages have the 672 disadvantage that the 'routing calculations' performed by the 673 multicast routing daemon to determine the Multicast Routing Table are 674 repeated by the MPLS module. The former determines the tree that will 675 be used at L3, the latter calculates an identical tree to be used by 676 L2. Since the same task is performed twice, it is better to create 677 the multicast LSP on the basis of information extracted from the 678 Multicast Routing Table itself (see section 5.2 and 5.3). The 679 routing calculations become more complex for protocols which support 680 a switch-over from a (*, G) tree to a (S, G) tree because more 681 messages have to be interpreted. 683 When a host has a point-to-point connection to the first router one 684 could create 'LSPs up to the end-user' by intercepting not only the 685 multicast routing messages but the IGMP Join/Prune messages ([FENN]) 686 as well. 688 5.1.3. Resource reservation messages 690 As is the case for unicast the RSVP Resv message can be used as a 691 trigger to establish LSPs. A source of a multicast group will send 692 an RSVP Path message down the tree, the receivers can then reply with 693 an RSVP Resv message. RSVP scales equally well for multicast as it 694 does for unicast because: 696 a) RSVP Resv messages can merge. 698 b) RSVP Resv messages are only sent up to the first branch which made 699 the required reservation. 701 5.2. Topology driven 703 The Multicast Routing Table (MRT) is maintained by the IP multicast 704 routing protocol daemon. The MPLS module maps this L3 tree topology 705 information to L2 p2mp LSPs. 707 The MPLS module can poll the MRT to extract the tree topologies. 708 Alternatively, the multicast daemon can be modified to notify the 709 MPLS module directly of any change to the MRT. 711 The disadvantage of this method is that labels are consumed even when 712 no traffic exists. 714 5.3. Traffic driven 716 5.3.1. General 717 A traffic driven trigger method will only construct LSPs for trees 718 which carry traffic. It consumes less labels than the topology 719 driven method, as labels are only allocated when there is traffic on 720 the multicast tree. 722 If the mixed L2/L3 forwarding capability (see section 4) is not 723 supported, the traffic driven trigger requires a label distribution 724 mode in which the label is requested by the LSRu (Downstream on 725 Demand or Upstream Unsolicited mode). In Figure 10, suppose an LSP 726 for a certain group exists to LSRd1 and another LSRd2 wants to join 727 the tree. In order for LSRd2 to initiate a trigger, it must already 728 receive the traffic from the tree. This can be either at L2 or at 729 L3. The former case is a chicken and egg problem. The latter case 730 requires a mixed L2/L3 forwarding capability in LSRu to add the L3 731 branch. 733 +--------+ 734 | LSRd1 | 735 | | 736 +--------+ | L3 | 737 | LSRu | +--------+ 738 | | | | 739 | L3 | +--------------------------> 740 +--------+ / | L2 | 741 | | / +--------+ 742 ->-------------+ 743 | L2 | +--------+ 744 +--------+ | LSRd2 | 745 | | 746 | L3 | 747 +--------+ 748 | | 749 | | 750 | L2 | 751 +--------+ 753 Figure 10. The LSRu has to request the label. 755 5.3.2. An implementation example 757 To illustrate that by choosing an appropriate trigger one can obtain 758 that MPLS multicast is independent of the deployed multicast routing 759 protocol following implementation example is given. 761 Current implementations on Unix platforms of IP multicast routing 762 protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The 763 MFC is a cached copy of the Multicast Routing Table. The MFC 764 requests an entry for a certain multicast group when it experiences a 765 'cache miss' for an incoming multicast packet. The missing routing 766 information is provided by the multicast daemon. If at a later point 767 in time something changes to the route (outgoing interfaces added or 768 removed), the multicast daemon will update the MFC. 770 The MFC is implemented as a common component (part of the kernel), 771 which makes this trigger very attractive because it can be 772 transparently used for any IP multicast routing protocol. 774 Entries in the MFC are removed when no traffic is received for this 775 entry for a certain period of time. When label switching is applied 776 to a certain MFC-entry, the L3 will not see any packets arriving 777 anymore. To retain the normal MFC behavior, the L3 counters of the 778 MFC need to be updated by L2 measurements. 780 5.4. Combinations of triggers and label distribution modes 782 Table 2 shows the valid combinations of label distribution modes and 783 trigger types which were discussed in the previous sections. The (X) 784 means that the combination is valid when the mixed L2/L3 forwarding 785 feature is supported in the LSR. 787 +----------------+---------------------------------------------+ 788 | | label requested by | 789 | | LSRu | LSRd | 790 | +----------------------+----------------------+ 791 | | upstream |downstream|downstream |upstream | 792 | |unsolicited|on demand |unsolicited|on demand | 793 +----------------+-----------+----------+-----------+----------+ 794 |Request Driven | | | | | 795 |(incoming msg) | X | X | | | 796 +----------------+-----------+----------+-----------+----------+ 797 |Request Driven | | | | | 798 |(outgoing msg) | | | X | X | 799 +----------------+-----------+----------+-----------+----------+ 800 |Topology Driven | X | X | X | X | 801 +----------------+-----------+----------+-----------+----------+ 802 |Traffic Driven | X | X | (X) | (X) | 803 +----------------+-----------+----------+-----------+----------+ 805 Table 2. Valid combinations of triggers and label distribution modes 807 6. Piggy-backing 809 In Figure 9 (outgoing case) one can observe that instead of sending 2 810 separate messages the label advertisement can be piggy-backed on the 811 existing control messages. For multicast two piggy-back candidates 812 exist: 814 a) Multicast routing messages: protocols as PIM-SM and CBT have 815 explicit Join messages which could carry the label mappings. This 816 approach is described in [FARI]. When different multicast routing 817 protocols are deployed, an extension to each of these protocols has 818 to be defined. 820 b) RSVP Resv messages: a label mapping extension object for RSVP, 821 also applicable to multicast, is proposed in [AWDU]. 823 The pro and cons of piggy-backing on multicast routing messages will 824 be described now. 826 Piggy-backing has following advantages: 828 a) If the label advertisement is piggy-backed on multicast routing 829 messages, then the distribution of routes and the distribution of 830 labels is tightly synchronized. This eliminates difficult corner 831 cases such as "what do I do with a label if I don't (yet) have a 832 routing table entry to attach it to?". It also minimizes the 833 interval between the establishment of the multicast route and the 834 mapping of a label to the route. 836 b) The number of control messages needed to support label 837 advertisement beyond those needed to support the multicast routing 838 itself is zero. 840 Following disadvantages of piggy-backing can be identified: 842 a) In dense-mode protocols there are no messages on which the label 843 advertisement can be piggy-backed. [FARI] proposes to add periodic 844 messages to dense-mode protocols for the purpose of label 845 advertisement, which is a heavy impact on the multicast routing 846 protocol and it eliminates the message conserving benefit of piggy- 847 backing. 849 b) The second solution for the state co-existence problem (section 850 3.4) can not be applied in combination with piggy-backing. 852 c) Piggybacking requires extending the multicast routing protocol, 853 and hence becomes less attractive if label advertisement needs to be 854 supported for multiple multicast routing protocols. Especially when 855 not only the label advertisement but also the other two LDP functions 856 (discovery and adjacency) are piggy-backed. 858 d) Piggy-backing assumes the Downstream Unsolicited label 859 distribution mode, this excludes a number of trigger methods (see 860 Table 2). 862 e) LDP normally runs on top of TCP, assuring a reliable communication 863 between peer nodes. Piggy-backed label advertisement often replaces 864 the reliable communication with periodic soft-state label 865 advertisements. Because of this periodic label advertisement the 866 control traffic (in number of bytes) will increase. 868 f) If a VCID notification mechanism [NAGA] is required, the (in-band) 869 notification can normally be done by sending the LDP bind through the 870 newly established VC. This way only one message is required. This 871 method cannot be combined with piggy-backing because the routing 872 message is sent before the VC can be established. An extra handshake 873 message is thus required, diminishing the benefit of piggy-backing. 875 So whether piggy-backing makes sense or not depends heavily on which 876 and how many multicast routing protocols are deployed, whether LDP is 877 already used for unicast, which trigger mechanism is used, ... . 878 Piggybacking is just one possible component of an MPLS multicast 879 solution. 881 7. Explicit routing 883 Explicit routing for unicast refers to overriding the unicast routing 884 table by using LSPs. 886 A first way to interpret "multicast explicit routing" is overriding 887 the tree established by the multicast routing protocol by another LSP 888 tree (e.g. a centrally calculated Steiner tree). In this 889 interpretation the current 'shortest path' multicast routing protocol 890 becomes obsolete and can be replaced by label advertisement messages 891 that follow an explicit route which is e.g. calculated by an offline 892 tool. 894 A second way of interpreting "multicast explicit routing" is that 895 multicast routing protocols use the explicit unicast routes to 896 construct trees. This approach requires that the RPF check also 897 takes the explicit path into account. 899 8. QoS/CoS 901 8.1. DiffServ 902 The Differentiated Services approach can be applied to multicast as 903 well. It introduces finer stream granularities (DiffServ Codepoint 904 (DSCP) as an extra differentiator). A sender can construct one or 905 more trees with different DSCPs. 907 These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily 908 onto LSPs when the traffic driven trigger is used. In this case one 909 can create LSPs with different attributes for the various DSCPs. 910 Note however that these LSPs still use the same route as long as the 911 tree construction mechanism itself does not take the DSCP as an 912 input. 914 8.2. IntServ and RSVP 916 RSVP can be used to setup multicast trees with QoS. An important 917 multicast issue is the problem of how to map the 'heterogeneous 918 receivers' paradigm onto L2 (remark that it is not solved in IP 919 either). This subject is tackled in [CRAW]. Pragmatic approaches 920 are the 'Limited Heterogeneity Model' which allows a best effort 921 service and a single alternate QoS (e.g. a QoS proposed by the sender 922 in a RSVP Path message) and the 'Homogeneous Model' which allows only 923 a single QoS. 925 The first approach will construct full trees for each service class. 926 The sender has to send its traffic twice across the network (e.g. 1 927 best-effort and 1 QoS tree). Both trees can be label switched. 929 The second approach constructs one tree and the best-effort users are 930 connected to the QoS tree. If the branches created for best-effort 931 users are not to be label switched, (thus carried by a hop-by-hop 932 default LSP) the QoS multicast traffic has to be merged onto these 933 default LSPs. This function can be provided by the 'mixed L2/L3 934 forwarding' feature described in section 4. If this is not available 935 merging is necessary to avoid a return to L3 in the QoS LSP. 937 The mapping of the IntServ service categories onto L2 for ATM service 938 categories is studied in [GARR]. 940 9. Multi-access networks 942 Multicast MPLS on multi-access networks poses a special problem. An 943 LSR that wants to join a group must always be ready to accept the 944 label that is already assigned to the group LSP (to another 945 downstream LSR on the link). This can be achieved in three ways: 947 1) Each LSR on the multi-access link memorizes all the advertised 948 labels on the link, even if it has not received a join for the 949 associated group. If an LSR is added to the multi-access link it has 950 to retrieve this information from another LSR on the link or in case 951 of soft state label advertisement it can wait a certain time before 952 it can allocate labels itself. If LSRs allocate a label 'at the same 953 moment' the LSR with the highest IP address could keep it, while the 954 other LSRs withdraw the label. 956 2) Each LSR gets its own label range to allocate labels from. A 957 mechanism for label partitioning is described in [FAR2]. If an LSR 958 is added to the multi-access link the label ranges have to be 959 negotiated again and possibly existing LSPs are teared down and are 960 reconstructed with other labels. 962 3) Per multi-access link one LSR could be elected to be responsible 963 for label allocation. When an LSR needs a label, it can request it 964 from this Label Allocation LSR. 966 Unlike the unicast case, a multicast stream can have more than one 967 downstream LSR which all have to use the same label. Two solutions 968 for label advertisement can be thought of: 970 1) [FARI] proposes to multicast the label advertisements to all LSRs 971 on the shared link. Since multicast is not reliable this requires 972 periodic label advertisements, yielding label advertisement 973 duplicates in time. 975 2) Another approach is that an LSR unicasts its label advertisements 976 in a reliable way (TCP) to all other (or to all interested) LSRs on 977 the shared link. In this approach the hard-state character of LDP 978 can be maintained but the label advertisement is duplicated in space. 980 Since LSPs are only rewarding if they have a long lifetime and since 981 the number of LSRs on a shared link is limited the second approach 982 seems advantageous. 984 Another issue with multicast in multi-access networks is whether to 985 use upstream or downstream label assignment. For multicast traffic, 986 upstream label allocation is simpler since there can be only one 987 upstream node per link that belongs to a multicast tree. This 988 (upstream) node can assign a label without any contention. With 989 downstream allocation, there may be multiple downstream nodes for a 990 given tree on a multi-access link; each node may propose a label 991 assignment leading to contention and a contention resolution scheme 992 is required to chose one of them as the label allocator. 994 Once a label has been assigned, it is possible that the label 995 assigner leaves the tree. With downstream label assignment, this 996 could happen when the label allocator leaves the group. With 997 upstream assignment this could happen when the upstream LSR changes 998 due to a unicast topology change. 1000 10. More issues 1002 10.1. TTL field 1004 The TTL field in the IP header is typically used for loop detection. 1005 In IP multicast it is also used to limit the scope of the multicast 1006 packets by setting an appropriate TTL value. 1008 Thus in LSRs that do not support a TTL decrement function (e.g ATM 1009 LSR), the scope restriction function is affected. Suppose one could 1010 calculate in advance the number of hops an LSP traverses. In a 1011 unicast LSP the TTL value could then be decremented at the ingress or 1012 the egress node. For multicast all the branches of the tree can have 1013 different lengths so the TTL can only be decremented at the egress 1014 node, potentially wasting bandwidth if the TTL turns out to be zero 1015 or negative. 1017 10.2. Independent vs. Ordered Label Distribution Control 1019 Current Label Distribution Terminology is only defined for unicast. 1020 The following sections explore what this terminology might mean in a 1021 multicast context. 1023 In Independent Control ([ANDE]) each LSR can take the initiative to 1024 do a label mapping. In Ordered Control ([ANDE]) an LSR only maps a 1025 label when it already received a label from its next-hop. 1027 All the previously described trigger methods (section 5) combine with 1028 Independent Control. Note that if the request driven approach is 1029 used with Independent Control the label distribution still behaves as 1030 in Ordered Control: the control messages flow from the egress node 1031 upstream, imposing the same sequence to the label advertisement. 1033 Ordered Control is not applicable for a traffic driven trigger in 1034 case the node does not support mixed L2/L3 forwarding. According to 1035 Table 2, this case implies that labels are requested by the upstream 1036 LSR. Suppose in Figure 11 that an LSP exists from S to R1 and a new 1037 branch must be added to R2. B will only accept a label on the A-B 1038 link if a label is already assigned on the B-C link. However, to 1039 establish a label on the B-C link, B must already receive traffic on 1040 the A-B link. 1042 N---N---R1 1043 / 1044 / 1045 S -----A 1046 \ 1047 \ 1048 B---C---R2 1050 Figure 11. 1052 10.3. Conservative vs. Liberal Label Retention Mode 1054 In the Conservative Mode ([ANDE]) only the labels that are used for 1055 forwarding data (if the next-hop for the FEC is the LSR which 1056 advertised the label) are allocated and maintained. In the Liberal 1057 Mode labels are advertised and maintained to all neighbors. 1059 Liberal Mode does not make sense in multicast. Two reasons can be 1060 identified for this: 1062 1) All LSRs have a route for each unicast FEC. This is not true for 1063 multicast FECs. 1065 2) For multicast an LSR always knows to which neighbor to send the 1066 label request or the label map messages. In e.g. unicast Downstream 1067 Unsolicited mode (see below) the LSR does not know where to send the 1068 label mappings and thus has to send the mapping to all its neighbors. 1069 In this case supporting the Liberal Mode does not generate extra 1070 messages (it still requires extra state information and label space) 1071 and thus the threshold to support Liberal Mode could be considered 1072 lower. 1074 Table 3 shows the cases where it is known by an LSR where to send its 1075 label requests. 1077 +---------+----------------------------------+ 1078 | | label requested by | 1079 | | LSRu | LSRd | 1080 +---------+----------------+-----------------| 1081 |unicast | Yes | No | 1082 +---------+----------------+-----------------| 1083 |multicast| Yes | Yes | 1084 +---------+----------------+-----------------+ 1086 Table 3. Does an LSR know where to send its label requests ? 1088 For a unicast flow, an LSR can determine the next hop LSR, which is 1089 the one to send the request to in case of Upstream Unsolicited or 1090 Downstream on Demand mode. The LSR is however not able to find the 1091 previous hop. The previous hop is not necessarily the next hop 1092 towards the source, because the path from A to B is not necessarily 1093 the same as the path from B to A. Such a situation can occur as a 1094 result of asymmetric link measures or in the event that multiple 1095 equal cost paths exist [PAXS]. 1097 In the case of multicast, an LSR knows both the next hop(s) and the 1098 previous hop. Because multicast trees are constructed using the 1099 reverse shortest path method, the previous hop is always the next hop 1100 towards the source or towards the root of the tree. 1102 10.4. Downstream vs. Upstream Label Allocation 1104 The label can be allocated by either the downstream LSR (Downstream 1105 on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on 1106 Demand, Upstream Unsolicited, implicit). The advantages of 1107 downstream label allocation are: 1109 a) It is the same mode as for unicast LDP, thus eliminating the need 1110 to develop upstream label distribution procedures. 1112 b) The same label can be kept when the upstream LSR changes due to a 1113 route change, which is an advantage on multi-access networks (see 1114 section 9). 1116 c) Compatible with piggybacking (especially the downstream 1117 distribution mode). 1119 The advantages of upstream label allocation are: 1121 a) Easier label allocation in multi-access networks (see section 9). 1123 b) The same label can be kept when the downstream LSR (which would 1124 have been the label allocator in downstream mode in a multi-access 1125 network) leaves the group (see section 9). 1127 c) The upstream and implicit distribution mode allow a faster LSP 1128 setup when the LSP is traffic triggered. 1130 10.5. Explicit vs. Implicit Label Distribution 1132 Beside the explicit distribution modes (which use a signaling 1133 protocol), [ACHA] proposes an implicit label distribution method by 1134 using unknown labels. This method has all the advantages of the 1135 upstream label allocation method and is probably the fastest label 1136 advertisement method for traffic triggered LSPs. 1138 Implicit label distribution is not applicable if the FEC-to-label 1139 binding has been advertised prior to traffic arrival, e.g. explicit 1140 routing (i.e. if all the information necessary to identify the FEC is 1141 not present in the packet). 1143 Explicit distribution allows pre-establishment (before the arrival of 1144 data) of LSPs with topology or request driven triggers. 1146 11. Security Considerations 1148 This document raises no security issues. 1150 12. Acknowledgements 1152 The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip 1153 Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard 1154 Gastaud for the fruitful discussions and/or their thorough revision 1155 of this document. 1157 References 1159 [ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM 1160 Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE 1161 Globecom '97. 1163 [AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva- 1164 san, "Extensions to RSVP for LSP Tunnels", Work In Progress 1166 [ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, 1167 "Label Distribution Protocol", Work In Progress. 1169 [BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi- 1170 tecture", RFC2201, September 1997. 1172 [CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A. 1173 Viswanathan, "A Framework for Multiprotocol Label Switching", 1174 Work In Progress. 1176 [CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame 1177 Relay Networks", Work In Progress. 1179 [CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden 1180 and J. Krawczyk, "A Framework for Integrated Services and RSVP 1181 over ATM", RFC2382, August 1998. 1183 [DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. 1184 Swallow and P. Doolan, "MPLS using ATM VC switching", Work In 1185 Progress. 1187 [DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 1188 Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, 1189 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 1190 Specification", RFC 2117, June 1997. 1192 [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol 1193 Independent Multicast Version 2 Dense Mode Specification", Work 1194 In Progress. 1196 [FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute 1197 MPLS Labels for Multicast Routes", Work In Progress. 1199 [FAR2] D. Farinacci and Y. Rekhter, "Partitioning Label Space among 1200 Multicast Routers on a Common Subnet", Work In Progress. 1202 [FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version 1203 2", RFC 2236, November 1997. 1205 [GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load 1206 Service and Guaranteed Service with ATM", RFC2381, August 1998. 1208 [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work 1209 In Progress. 1211 [MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. 1213 [NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID 1214 Notification over ATM link for LDP", Work In Progress. 1216 [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. 1217 Maufer, "Simple Multicast", Work In Progress. 1219 [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work 1220 In Progress. 1222 [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", 1223 IEEE/ACM Transactions on Networking 5(5), pp. 601-615. 1225 [ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. 1226 Li, A. Conta, "MPLS Label Stack Encoding", Work In Progress. 1228 Authors Addresses 1230 Dirk Ooms 1231 Alcatel Corporate Research Center 1232 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1233 Phone : 32 3 2404732 1234 Fax : 32 3 2409879 1235 E-mail: Dirk.Ooms@alcatel.be 1237 Bernard Sales 1238 Alcatel Corporate Research Center 1239 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1240 Phone : 32 3 2409574 1241 E-mail: Bernard.Sales@alcatel.be 1243 Wim Livens 1244 Colt Telecom 1245 Zweefvliegtuigstraat 10, 1130 Brussel, Belgium 1246 Phone : 32 2 7901705 1247 Fax : 32 2 7901711 1248 E-mail: WLivens@colt-telecom.be 1250 Arup Acharya 1251 IBM TJ Watson Research Center 1252 30 Saw Mill River Road, Hawthorne 1253 NY 10532 1254 Phone : 1 914 784 7481 1255 E-mail: arup@us.ibm.com 1257 Frederic Griffoul 1258 Ulticom, Inc. 1259 Les Algorithmes, 2000 Route des Lucioles, BP29 1260 06901 Sophia-Antipolis, FRANCE 1261 E-mail: griffoul@ulticom.com 1263 Furquan Ansari 1264 Bell Labs 1265 101 Crawfords Corner Rd., Holmdel, NJ 07733 1266 Phone : 1 732 949 5149 1267 Fax : 1 732 332 6511 1268 E-mail: furquan@dnrc.bell-labs.comy