idnits 2.17.1 draft-ooms-mpls-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 94 has weird spacing: '... mp2mp mult...' == Line 95 has weird spacing: '... p2mp poi...' == Line 661 has weird spacing: '...ervices could...' -- 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 891, but no explicit reference was found in the text -- No information found for draft-mpls-ldp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ANDE' ** Downref: Normative reference to an Historic draft: draft-ietf-idmr-cbt-spec (ref. 'BALL') == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. 'CALL' -- Unexpected draft version: The latest known version of draft-ietf-issll-atm-framework is -03, but you're referring to -04. (However, the state information for draft-mpls-ldp is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-ietf-issll-atm-framework (ref. 'CRAW') == Outdated reference: A later version (-01) exists of draft-davie-mpls-atm-00 -- Possible downref: Normative reference to a draft: ref. 'DAVI' -- Possible downref: Normative reference to a draft: ref. 'DAV2' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEER' -- Possible downref: Non-RFC (?) normative reference: 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'NEVE' == 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'UUNE' Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Submitted to MPLS Working Group D. Ooms 3 INTERNET DRAFT W. Livens 4 B. Sales 5 M. Ramalho 6 Alcatel 8 August, 1998 9 Expires February, 1999 11 Framework for IP Multicast in MPLS 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). Distribution of this memo is unlimited. 31 Abstract 33 This document offers a framework for IP multicast deployment in an 34 MPLS environment. Issues arising when MPLS techniques are applied to 35 IP multicast are overviewed. The pros and cons of existing IP 36 multicast routing protocols in the context of MPLS are described and 37 the relation to the different trigger methods and LDP modes are 38 discussed. Focus is on ATM as a L2 technology. 40 Table of Contents 42 1. Introduction 43 2. MPLS and IP multicast: a winner combination 44 3. ATM as layer 2 45 4. Taxonomy of IP multicast routing protocols in the context of MPLS 46 4.1. Flood & Prune 47 4.2. Source/Shared trees 48 4.3. Uni/Bi-directional Shared Trees 49 4.4. Loop-free-ness 50 4.5. RPF Check 51 4.6. Mapping of characteristics on existing protocols 52 5. Taxonomy of IP multicast LSP triggers 53 5.1. Request driven 54 5.1.1. General 55 5.1.2. Multicast routing messages 56 5.1.3. Resource reservation messages 57 5.2. Topology driven 58 5.3. Traffic driven 59 5.3.1. General 60 5.3.2. An implementation example 61 5.4. Combinations of triggers and LDP modes 62 6. Mixed L2/L3 forwarding in a single node 63 7. Piggy-backing 64 8. Explicit routing 65 9. QoS/CoS 66 9.1 DiffServ 67 9.2 IntServ and RSVP 68 10. More issues 69 10.1. TTL field 70 10.2. Shared media 71 10.3. Local control vs. egress control 72 10.4. Conservative vs. optimistic 73 10.5. Conservative vs. liberal 74 10.6. Scalability 75 11. Security Considerations 76 12. Acknowledgements 78 Table of Abbreviations 80 ATM Asynchronous Transfer Node 81 CBT Core Based Tree 82 CoS Class of Service 83 DVMRP Distant Vector Multicast Routing Protocol 84 IGMP Internet Group Management Protocol 85 IP Internet Protocol 86 L2 layer 2 (e.g. ATM) 87 L3 layer 3 (e.g. IP) 88 LSP Label Switched Path 89 LSR Label Switching Router 90 LSRd Downstream LSR 91 LSRu Upstream LSR 92 MIP Multicast Internet Protocol 93 MOSPF Multicast OSPF 94 mp2mp multipoint-to-multipoint 95 p2mp point-to-multipoint 96 PIM-DM Protocol Independent Multicast-Dense Mode 97 PIM-SM Protocol Independent Multicast-Sparse Mode 98 QoS Quality of Service 99 RPF Reverse Path Forwarding 100 RSVP Resource reSerVation Protocol 101 TCP Transmission Control Protocol 102 UDP User Datagram Protocol 103 VC Virtual Circuit 104 VCI Virtual Circuit Identifier 105 VP Virtual Path 106 VPI Virtual Path Identifier 108 1. Introduction 110 In an MPLS cloud the routes are determined by a L3 routing protocol. 111 These routes can then be mapped onto L2 paths to enhance network 112 performance and to create a vehicle for enhanced network services 113 (QoS/CoS, traffic engineering,...). 115 Current unicast routing protocols generate a same (optimal) shortest 116 path in steady state for a certain (source, destination)-pair. Remark 117 that unicast protocols can behave slightly different with regard to 118 equal cost paths. 120 For multicast, the optimal solution would impose a Steiner tree 121 computation. Unfortunately, no multicast routing protocol today is 122 able to maintain such an optimal tree. Different multicast protocols 123 will therefore, in general, generate different trees. 125 The discussion is focused on intra-domain multicast routing 126 protocols. Aspects of inter-domain routing are beyond the scope of 127 this document. 129 2. MPLS and IP multicast: a winner combination 131 Besides the better utilization of expensive L3 resources, multicast 132 LSPs have even more benefits than unicast LSPs. First, multicast 133 traffic flows are often those long-duration high-bandwidth flows that 134 are prime candidate to be label switched (e.g. video streams). Next, 135 the detection of these flows can be straightforward, as multicast 136 flows are often setup using explicit routing messages (e.g. the 137 receiver triggered Join messages in PIM-SM), which can be easily 138 intercepted. Finally, IP multicast uses UDP, which does not have the 139 congestion-avoiding behavior of TCP. A large scale deployment of 140 multicast may therefore push aside regular TCP traffic, deteriorating 141 the latter's performance. Label switching this multicast UDP traffic 142 will therefore result in a better performance for non-label-switched 143 TCP-based applications. 145 3. ATM as layer 2 147 Although MPLS is multiprotocol both at L3 and at L2, IP and ATM are 148 the main L3 and L2 technologies. ATM offers big pipes, high 149 switching capacities and QoS awareness, but in the context of MPLS it 150 poses several limitations [DAVI]: 152 - Limited ATM resources (VPI/VCI space): current ATM switches have a 153 limited range of VPI/VCIs, limiting the number of LSPs that can be 154 established. 156 - No VC merging: a majority of current ATM switches does not support 157 VC merging, it is an active area of research, not only in the context 158 of MPLS, but also in the traditional ATM world. 160 - No 'TTL-decrement' function in ATM. 162 All three limitations will impact the implementation of multicast in 163 MPLS as will be described in this document. 165 4. Taxonomy of IP multicast routing protocols in the context of MPLS 167 At the moment, an abundance of IP multicast routing protocols is 168 being proposed and developed. All these protocols have different 169 characteristics (scalability, computational complexity, latency, 170 control message overhead, tree type, etc...). It is not the purpose 171 of this document to give a complete taxonomy of IP multicast routing 172 protocols, only their characteristics relevant to the MPLS technology 173 will be addressed. 175 Following characteristics are considered: 177 - Flood & Prune 178 - Source/Shared trees 179 - Uni/Bi-directional shared trees 180 - Loop-free-ness 181 - RPF check 183 The discussion of these characteristics will not lead to the 184 selection of one superior multicast routing protocol. It is even 185 very probable that different IP multicast routing protocols will be 186 deployed in the Internet. 188 4.1. Flood & Prune 190 To establish the multicast tree some IP multicast routing protocols 191 flood the network with multicast data. The branches can then be 192 pruned by nodes which do not want to receive the data of the specific 193 multicast group. This process is repeated periodically, thus 194 generating a very volatile tree structure. Direct mapping of this 195 dynamic layer 3 (L3) point-to-multipoint (p2mp) tree to a layer 2 196 (L2) p2mp LSP is problematic because of the limited ATM resources and 197 the setup time of the LSPs. 199 4.2. Source/Shared trees 201 IP multicast routing protocols create either source trees (S, G), 202 i.e. a tree per source (S) and per multicast group (G), or shared 203 trees (*, G), i.e. one tree per multicast group (Figure 1). Some 204 protocols support a mixture of both tree types. 206 R1 R1 R1 207 S1 / / / 208 \ / / / 209 \ / / / 210 C---R2 S1---R2 S2---R2 211 / \ \ \ 212 / \ \ \ 213 S2 \ \ \ 214 R3 R3 R3 216 Figure 1. Shared tree and Source trees 218 The advantage of using shared trees, when label switching is applied, 219 is that shared trees consume less labels (for ATM: less VPI/VCI 220 space) than source trees (1 label per group versus 1 label per source 221 and per group). 223 However, mapping a shared tree end-to-end on ATM implies setting up 224 multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing 225 mp2mp LSPs boils down to the VC merging problem. 227 4.3. Uni/Bi-directional Shared Trees 228 Bidirectional shared trees have the disadvantage of creating a lot of 229 merging points (M) in the nodes (N) of the shared tree. Figure 2 230 shows these merging points resulting from 2 senders S1 and S2 on a 231 bidirectional tree. 233 S1 S2 234 || || 235 v| <- <- <- <- |v 236 <- <- | -> -> -> -> | -> 237 ----N----M----M----M----M----M----N 238 || || || || || || 239 |v |v |v |v |v |v 240 | | | | | | 242 Figure 2. Multicast traffic flows from 2 senders on a bidirectional tree 244 In Figure 3 the same situation for unidirectional shared trees is 245 depicted. In this case the data of the senders is tunneled towards 246 the root node R, yielding only a single merging point, namely the 247 root of the shared tree itself. 249 S1 250 tunnel || S2 251 <----- v| tunnel || 252 to R<------------------------- v| 253 -> -> | -> -> -> -> | -> 254 ----N----N----N----N----N----N----N 255 || || || || || || 256 |v |v |v |v |v |v 257 | | | | | | 259 Figure 3. Multicast traffic flows from 2 senders on a unidirectional tree 261 In unidirectional shared trees the multicast traffic is sent 262 encapsulated from the Designated Router (DR) of the source to the 263 root node R. Hence, multicast traffic arriving at the root needs to 264 be decapsulated first (L3 operation) before transmission over the (*, 265 G) tree. Therefore, forwarding multicast packets in the root node 266 can only be done at L3, so there is no issue of merging data from 267 different sources at L2 in the root node. LSPs can only start from 268 the root node, so the traffic can never be label switched end-to-end. 270 4.4. Loop-free-ness 272 Multicast routing protocols which depend on a unicast routing 273 protocol can suffer from the same transient loops as the unicast 274 protocols do, however the effect of loops will be much worse in the 275 case of multicast (multicast avalanche). 277 Note that there exist multicast routing protocols which are 278 guaranteed loop free [PARS]. This is however not an advantage if loop 279 prevention is also performed by MPLS. 281 4.5. RPF Check 283 Some protocols perform a Reverse Path Forwarding (RPF) check on the 284 received multicast packets. This mechanism checks whether the packet 285 is received on the interface which is on the shortest path to the 286 source (or root). This mechanism can introduce problems when 287 explicit routing is used (see section 8). Indeed, explicit routing 288 can construct a tree yielding another incoming interface than the 289 RPF-compatible one. 291 4.6. Mapping of characteristics on existing protocols 293 The above characteristics are summarized in Table 1 for a non- 294 exhaustive list of existing IP multicast routing protocols: DVMRP 295 [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], MIP 296 [PARS]. 298 +------------------+------+------+------+------+------+-----+ 299 | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|MIP | 300 +------------------+------+------+------+------+------+-----+ 301 |Flood & Prune |yes |yes |no |yes |no |no | 302 +------------------+------+------+------+------+------+-----+ 303 |Tree Type |source|source|shared|source|both |both | 304 +------------------+------+------+------+------+------+-----+ 305 |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |both | 306 +------------------+------+------+------+------+------+-----+ 307 |Loop Free |no |no |no |no |no |yes | 308 +------------------+------+------+------+------+------+-----+ 309 |RPF check |yes |yes |no |yes |yes |no | 310 +------------------+------+------+------+------+------+-----+ 312 Table 1. Taxonomy of IP Multicast Routing Protocols 314 From Table 1 one can derive e.g. that DVMRP will consume a lot of L2 315 resources when the Flood & Prune L3 tree is mapped onto a L2 tree. 316 Furthermore since DVMRP uses source trees it experiences no merging 317 problem when label switching is applied. The table can be 318 interpreted in the same way for the other protocols. 320 5. Taxonomy of IP multicast LSP triggers 322 The creation of an LSP for multicast streams can be triggered by 323 different events, which can be mapped on the well known categories of 324 'request driven', 'topology driven' and 'traffic driven'. 326 a) Request driven: intercept the sending or receiving of control 327 messages (e.g. multicast routing messages, resource reservation 328 messages). 330 b) Topology driven: map the L3 tree, which is available in the 331 Multicast Routing Table, to a L2 tree. The mapping is done even if 332 there is no traffic. 334 c) Traffic driven: the L3 tree is mapped onto a L2 tree when data 335 arrives on the tree. 337 The granularity of the multicast streams will be (*, G) for the 338 shared tree and (S, G) for a source tree, S being the source address 339 and G the multicast group address. 341 Whether the trigger by multicast routing messages is categorized as 342 request or topology driven is debatable. The constructed L2 tree 343 will be identical to the one constructed by topology driven methods, 344 but the definition of request driven [CALL] includes all label 345 assignments in response to control traffic. In [KATS] the multicast 346 routing messages trigger is categorized as request driven, so we will 347 continue using this convention. 349 5.1. Request driven 351 5.1.1. General 353 The establishment of LSPs can be triggered by the interception of 354 outgoing (requiring that the label is requested by the downstream 355 LSR) or incoming (requiring that the label is requested by the 356 upstream LSR) control messages. Figure 4 illustrates these two 357 cases. 359 LSRu LSRd LSRu LSRd 360 -------+ +--- ---+ +------- 361 | control | | control | 362 <---*<-----message------- <-------message-------*---- 363 | | | | | | 364 trigger| | | | | |trigger 365 | | bind | | bind | | 366 +--------or---------> <---------or----------+ 367 | bind-request | | bind-request | 368 | | | | 369 | | | | 370 |----data----->| |-----data---->| 372 incoming outgoing 374 Figure 4. Request driven trigger 375 (interception of resp. incoming and outgoing control messages) 377 The downstream LSR (LSRd) sends a control message to the upstream LSR 378 (LSRu). In the case that incoming control messages are intercepted 379 and the MPLS module in LSRu decides to establish an LSP it will send 380 an LDP bind (upstream mode) or an LDP bind request (downstream on 381 demand mode) to LSRd. 383 Currently, we can identify two important types of control messages: 384 the multicast routing messages and the resource reservation messages. 386 5.1.2. Multicast routing messages 388 In principle, this mechanism can only be used by IP multicast routing 389 protocols which use explicit signaling: e.g. the Join messages in 390 PIM-SM or CBT. Remark that DVMRP and PIM-DM can be adapted to 391 support this type of trigger [FARI], however, at the cost of 392 modifying the IP multicast routing protocol itself ! 394 IP multicast routing messages can create both hard states (e.g. CBT 395 Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent 396 periodically). The latter generates more control traffic for tree 397 maintenance and thus requires more processing in the MPLS module. 399 Triggers based on the multicast routing protocol messages have the 400 disadvantage that the routing calculations performed by the multicast 401 routing daemon to determine the Multicast Routing Table are repeated 402 by the MPLS module. The former determines the tree that will be used 403 at L3, the latter calculates an identical tree to be used by L2. 404 Since the same task is performed twice, it is better to create the 405 multicast LSP on the basis of information extracted from the 406 Multicast Routing Table itself (see section 5.2 and 5.3). The 407 routing calculations become more complex for protocols which support 408 a switch-over from a (*, G) tree to a (S, G) tree because more 409 messages have to be interpreted. 411 When a host has a point-to-point connection to the first router one 412 could create 'LSPs up to the end-user' by intercepting not only the 413 multicast routing messages but the IGMP Join/Prune messages ([FENN]) 414 as well. 416 5.1.3. Resource reservation messages 418 As is the case for unicast the RSVP Resv message can be used as a 419 trigger to establish LSPs. A source of a multicast group will send 420 an RSVP Path message down the tree, the receivers can then reply with 421 an RSVP Resv message. RSVP scales equally well for multicast as it 422 does for unicast because: 424 a) RSVP Resv messages can merge. 426 b) RSVP Resv messages are only sent up to the first branch which made 427 the required reservation. 429 More on RSVP in the sections on Piggy-backing (section 7) and QoS 430 (section 9). 432 5.2. Topology driven 434 The Multicast Routing Table (MRT) is maintained by the IP multicast 435 routing protocol daemon (e.g. PIM/pimd, DVMRP/mrouted). The MPLS 436 module maps this L3 tree topology information to L2 p2mp LSPs. 438 The MPLS module can poll the MRT to extract the tree topologies. 439 Alternatively, the multicast daemon can be modified to notify the 440 MPLS module directly of any change to the MRT. 442 5.3. Traffic driven 444 5.3.1. General 446 A traffic driven trigger method will only construct LSPs for trees 447 which carry traffic. It consumes less labels than the topology 448 driven method, as labels are only allocated when there is traffic on 449 the multicast tree. 451 If the mixed L2/L3 forwarding capability (see section 6) is not 452 supported, the traffic driven trigger requires an LDP mode in which 453 the label is requested by the LSRu (downstream on demand or upstream 454 mode). In Figure 5, suppose an LSP for a certain group exists to 455 LSRd1 and another LSRd2 wants to join the tree. In order for LSRd2 456 to initiate a trigger, it must already receive the traffic from the 457 tree. This can be either at L2 or at L3. The former case is a 458 chicken and egg problem. The latter case requires a mixed L2/L3 459 forwarding capability in LSRu to add the L3 branch. 461 +--------+ 462 | LSRd1 | 463 | | 464 +--------+ | L3 | 465 | LSRu | +--------+ 466 | | | | 467 | L3 | +--------------------------> 468 +--------+ / | L2 | 469 | | / +--------+ 470 ->-------------+ 471 | L2 | +--------+ 472 +--------+ | LSRd2 | 473 | | 474 | L3 | 475 +--------+ 476 | | 477 | | 478 | L2 | 479 +--------+ 481 Figure 5. The LSRu has to request the label. 483 5.3.2. An implementation example 485 Current implementations on Unix platforms of IP multicast routing 486 protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC). The 487 MFC is a cached copy of the Multicast Routing Table. The MFC 488 requests an entry for a certain multicast group when it experiences a 489 'cache miss' for an incoming multicast packet. The missing routing 490 information is provided by the multicast daemon. If at a later point 491 in time something changes to the route (outgoing interfaces added or 492 removed), the multicast daemon will update the MFC. 494 The MFC is implemented as a common component (part of the kernel), 495 which makes this trigger very attractive because it can be 496 transparently used for any IP multicast routing protocol. 498 Entries in the MFC are removed when for a certain time no traffic is 499 received anymore for this entry. When label switching is applied to 500 a certain MFC-entry, the L3 will not see any packets arriving 501 anymore. To obtain a normal MFC behavior the L3 counters of the MFC 502 need to be updated by L2 measurements. 504 5.4. Combinations of triggers and LDP modes 506 Table 2 shows the valid combinations of LDP modes and trigger types 507 which were discussed in the previous sections. The (X) means that 508 the combination is valid when the mixed L2/L3 forwarding feature is 509 supported in the LSR (section 6). 511 +----------------+-------------------------------------------+ 512 | | label requested by | 513 | | LSRu | LSRd | 514 | +---------------------+---------------------+ 515 | | upstream |downstream|downstream| upstream | 516 | | |on demand | | on demand| 517 +----------------+----------+----------+----------+----------+ 518 |Request Driven | | | | | 519 |(incoming msg) | X | X | | | 520 +----------------+----------+----------+----------+----------+ 521 |Request Driven | | | | | 522 |(outgoing msg) | | | X | X | 523 +----------------+----------+----------+----------+----------+ 524 |Topology Driven | X | X | X | X | 525 +----------------+----------+----------+----------+----------+ 526 |Traffic Driven | X | X | (X) | (X) | 527 +----------------+----------+----------+----------+----------+ 529 Table 2. Valid combinations of triggers and LDP modes 531 6. 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 core 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) Allows a return to L3 for branches which requested lower QoS 601 (section 9). 603 c) Enables the use of the traffic driven trigger with the LDP 604 downstream or upstream on demand mode, as explained in section 5.4. 606 7. Piggy-backing 608 In Figure 4 (outgoing case) one can observe that instead of sending 2 609 separate messages the label advertisement can be piggy-backed on the 610 existing control messages. However, some disadvantages can be 611 identified: 613 a) Since label advertisement is only one of the three functions of 614 LDP (the two others are discovery and adjacency), LDP is still 615 required for e.g. label range negotiation. 617 b) Suppose piggy-backing is applied on the multicast routing 618 protocol. In order to support unicast label switching, either piggy- 619 backing has also to be implemented on the unicast routing protocol or 620 LDP must be used. In the latter case, one may question the benefit of 621 piggy-backing on the multicast routing protocol. As a result, 622 piggy-backing introduces extra implementation effort. 624 c) Piggy-backing assumes the LDP downstream mode, this excludes a 625 number of trigger methods (see Table 2). 627 d) Piggy-backing changes the LDP paradigm: LDP normally runs on top 628 of TCP, assuring a reliable communication between peer nodes. 629 Piggy-backed label advertisement often replaces the reliable 630 communication with periodic soft-state label advertisements. Because 631 of this periodic label advertisement the control traffic will 632 increase. 634 e) If a VCID notification mechanism [NAGA] is required, the (in-band) 635 notification can be done by sending the LDP bind through the newly 636 established VC. This way only one message is required. This method 637 cannot be combined with piggy-backing because the routing message is 638 sent before the VC can be established. An extra handshake message is 639 thus required, diminishing the benefit of piggy-backing. 641 For multicast two piggy-back candidates exist: 643 a) Multicast routing messages: protocols as PIM-SM and CBT have 644 explicit Join messages which could carry the label mappings. This 645 approach is described in [FARI]. When different multicast routing 646 protocols are deployed, an extension to each of these protocols has 647 to be defined. 649 b) RSVP Resv messages: a label mapping extension object for RSVP, 650 also applicable to multicast, is proposed in [DAVI]. 652 Piggy-backing is not incompatible with multicast, but one has to 653 consider the disadvantages carefully. 655 8. Explicit routing 657 Explicit routing is a powerful concept to control the multicast 658 network topology. It provides network engineers with a tool which 659 allows explicitly defined LSPs to be selected for multicast traffic. 660 Such tools can be very useful for ISPs [UUNE] so that new IP 661 multicast services could be directed to particular links which are 662 under traffic engineering control, unlike conventional dynamic IP 663 routing. 665 In case of explicit routing, (part of) the tree is calculated or 666 configured by a single node and subsequently mapped on an LSP. 668 If one central node would know all receivers, it can construct a more 669 optimal tree (more optimal than a shortest-path-tree). However, 670 maintaining the knowledge of all receivers introduces a lot of 671 signaling towards this central node. This can be a bottleneck if 672 group membership is very dynamic. 674 If routing is based on multiple constraints (instead of just hop- 675 count), it can occur that two branches of the same tree cross a same 676 node. 678 An example of this is shown in Figure 9. The two additive cost 679 metrics associated with a certain link are represented by (c1,c2). 680 Suppose two users A and B both require that sum(c1)<12 and sum(c2)<7. 681 The only solution implies that the traffic from S is split in M1 and 682 carried two times over the M2-M3 link. 684 (1,5) A3---User A 685 A1-----A2 / 686 / \ /(10,1) 687 / +-----+ 688 S-----M1 M2 M3 689 \ +-----+ 690 \ / \(1,5) 691 B1-----B2 \ 692 (10,1) B3---User B 694 Figure 9. Two branches of a tree crossing a same node 696 Such forwarding state cannot be represented by the usual (S,G) or 697 (*,G) table lookup and RPF check. Only explicit routing can do this. 699 Note that if an 'explicit routed' LSP for a certain part of the tree 700 is established, one must make sure that the L3 forwarding engine of 701 the LSRs at the end of the LSP is notified of the explicit path in 702 order not to do an (incorrect) RPF check. 704 9. QoS/CoS 706 9.1. DiffServ 708 The Differentiated Services approach can be applied to multicast as 709 well. It introduces finer stream granularities (Class of Service 710 (CoS) as an extra differentiator). A sender can construct one or 711 more trees with different CoS bits. 713 These (S, G, CoS) or (*, G, CoS) trees can be mapped very easily onto 714 LSPs when the traffic driven trigger is used. In this case one can 715 create different LSPs for the different classes. Note however that 716 these LSPs still use the same route. The situation becomes more 717 complicated when one wants to combine DiffServ with QoS Routing 718 [NEVE]. 720 9.2. IntServ and RSVP 722 RSVP can be used to setup multicast trees with QoS. An important 723 multicast issue is the problem of how to map the 'heterogeneous 724 receivers' paradigm onto ATM (remark that it is not solved in IP 725 either). This subject is tackled in [CRAW]. Pragmatic approaches 726 are the 'Limited Heterogeneity Model' which allows a best effort 727 service and a single alternate QoS (e.g. a QoS proposed by the sender 728 in a RSVP Path message) and the 'Homogeneous Model' which allows only 729 a single QoS. 731 The first approach will construct full trees for each service class. 732 The sender has to send its traffic twice across the network (1 best- 733 effort and 1 QoS tree). Both trees can be label switched. 735 The second approach constructs one tree and the best-effort users are 736 connected to the QoS tree. If the branches created for best-effort 737 users are not to be label switched, (thus carried by a hop-by-hop 738 default VC) the QoS multicast traffic has to be merged onto these 739 default VCs. This function can be provided by the 'mixed L2/L3 740 forwarding' feature described in section 6. If this is not available 741 VC merging is necessary to avoid a return to L3 in the QoS LSP. 743 The mapping of the IntServ service categories onto ATM service 744 categories is studied in [GARR]. 746 10. More issues 748 10.1. TTL 750 The TTL field in the IP header is typically used for loop detection. 751 In IP multicast it is also used to limit the scope of the multicast 752 packets by setting an appropriate TTL value. Since the TTL value is 753 not decremented in an LSP, the scope restriction function is 754 affected. 756 Suppose one could calculate in advance the number of hops an LSP 757 traverses. In a unicast LSP the TTL value could then be decremented 758 at the ingress node. This is impossible for multicast since all the 759 branches of the tree can have different lengths. 761 10.2. Shared media 762 Multicast on shared media requires label space partitioning, 763 otherwise the danger exists that two downstream LSRs will use the 764 same label to subscribe to different multicast groups. A label space 765 partitioning mechanism is described in [FAR2]. 767 10.3. Local control vs. egress control 769 In local control (also called independent mode [ANDE]) each LSR can 770 take the initiative to set up a LSP. In egress control (also called 771 ordered mode [ANDE]) the LSP is set up on the initiative of the 772 egress node. All the previously described trigger methods (section 773 5) combine with LDP local control. In case of the request driven 774 approach the label distribution in fact behaves as egress controlled: 775 the control messages flow from the egress node upstream, imposing the 776 same sequence to the label advertisement. In case of piggy-backing 777 the label advertisements themselves are flowing from the egress node 778 upstream. 780 10.4. Conservative vs. optimistic 782 The conservative mode ([DAVI]) only accepts an upstream label for a 783 certain stream if it already has a downstream label for this stream. 784 The optimistic mode always accepts the label. 786 The conservative mode cannot be used in combination with a traffic 787 driven trigger in case the node does not support mixed L2/L3 788 forwarding. According to Table 2, this case implies that labels are 789 requested by the upstream LSR. Suppose in Figure 10 that an LSP 790 exists from S to R1 and a new branch must be added to R2. B will only 791 accept a label on the A-B link if a label is already assigned on the 792 B-C link. However, to establish a label on the B-C link, B must 793 already receive traffic on the A-B link. This is not possible at L2 794 nor at L3 (since A does not support mixed L2/L3). 796 N---N---R1 797 / 798 / 799 S -----A 800 \ 801 \ 802 B---C---R2 804 Figure 10. 806 10.5. Conservative vs. liberal 808 In the conservative mode ([ANDE]) only the labels that are required 809 for forwarding data are allocated and maintained. In the liberal 810 mode labels are advertised and maintained to all neighbors. This mode 811 does not scale in ATM due to the the limited VPI/VCI space. 813 In some cases (see below) it is not known by an LSR to which neighbor 814 it has to request a label. Therefore, it has to send the request to 815 all its neighbors. In such case supporting the liberal mode requires 816 no extra messages. However, it still requires extra state information 817 and label space. 819 Table 3 shows the cases where it is known by an LSR where to send its 820 label requests. 822 +---------+----------------------------------+ 823 | | label requested by | 824 | | LSRu | LSRd | 825 +---------+----------------+-----------------| 826 |unicast | Yes | No | 827 +---------+----------------+-----------------| 828 |multicast| Yes | Yes | 829 +---------+----------------+-----------------+ 831 Table 3. Does an LSR know where to send its label requests ? 833 For a unicast flow, an LSR can determine the next hop LSR, which is 834 the one to send the request to in case of upstream or downstream-on- 835 demand mode. The LSR is however not able to find the previous hop. 836 The previous hop is not necessarily the next hop towards the source, 837 because the path from A to B is not necessarily the same as the path 838 from B to A. Such a situation can occur as a result of asymmetric 839 link measures or in the event that multiple equal cost paths exist 840 [PAXS]. 842 In the case of multicast, an LSR knows both the next hop(s) and the 843 previous hop. Because multicast trees are constructed using the 844 reverse shortest path method, the previous hop is always the next hop 845 towards the source or towards the root of the tree. As a result, 846 multicast maps very naturally on the conservative mode. 848 10.6. Scalability 850 Sparse mode multicast routing protocols (CBT, PIM-SM) are more 851 scalable than dense mode protocols. But even the sparse mode 852 protocols introduce state in each node of the tree. An enhancement 853 to this is proposed in [TIAN]. In this proposal tunnels are created 854 which span the non-branching nodes. An appropriate trigger could map 855 these tunnels to LSPs. 857 11. Security Considerations 859 Security considerations are not discussed in this version of the 860 document. 862 12. Acknowledgements 864 The authors would like to thank Piet Van Mieghem, Philip Dumortier, 865 Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard Gastaud for the 866 fruitful discussions and/or their thorough revision of this document. 868 References 870 [ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, 871 "Label Distribution Protocol", IETF Draft, draft-mpls-ldp- 872 00.txt, March 1998. 874 [BALL] A. Ballardie, "Core Based Trees (CBT, v2) Multicast Routing - 875 Protocol Specification", IETF Draft, draft-ietf-idmr-cbt-spec- 876 09.txt, 1997. 878 [CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A. 879 Viswanathan, "A Framework for Multiprotocol Label Switching", 880 IETF Draft, draft-ietf-mpls-framework-02.txt, November 1997. 882 [CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden 883 and J. Krawczyk, "A Framework for Integrated Services and RSVP 884 over ATM", IETF Draft, draft-ietf-issll-atm-framework-04.txt, 885 May 1998. 887 [DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. 888 Swallow and P. Doolan, "Use of Label Switching With ATM", IETF 889 Draft, draft-davie-mpls-atm-00.txt, November 1997. 891 [DAV2] B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan 892 and S. Blake, "Use of Label Switching With RSVP", IETF Draft, 893 draft-ietf-mpls-rsvp-00.txt, March 1998 895 [DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 897 Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, 898 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 899 Specification", RFC 2117, June 1997. 901 [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol 902 Independent Multicast (PIM), Dense Mode Protocol: Specifica- 903 tion", IETF Draft, 1994. 905 [FARI] D. Farinacci and Y. Rekhter, "Multicast Tag Binding and Distri- 906 bution using PIM", IETF Draft, draft-farinacci-multicast-tagsw- 907 00.txt, December 1996. 909 [FAR2] D. Farinacci and Y. Rekhter, "Partitioning Tag Space among Mul- 910 ticast Routers on a Common Subnet", IETF Draft, draft- 911 farinacci-multicast-tag-part-00.txt, December 1996. 913 [FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version 914 2", RFC 2236, November 1997. 916 [GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load 917 Service and Guaranteed Service with ATM", IETF Draft, draft- 918 ietf-issll-atm-mapping-06.txt, March 1998. 920 [KATS] Y. Katsube, Y. Ohba and K. Nagami, "Two Modes of MPLS Explicit 921 Label Distribution Protocol", IETF Draft, draft-katsube-mpls- 922 two-ldp-00.txt, September 1997. 924 [MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. 926 [NAGA] K. Nagami, N. Demizu, H. Esaki and P. Doolan, "VCID Notification 927 over ATM link", IETF Draft, draft-ietf-mpls-vcid-atm-00.txt; 928 March 1998. 930 [NEVE] H. De Neve and P. Van Mieghem, "Hop-by-Hop Quality of Service 931 Routing", submitted to INFOCOM '99. 933 [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", IETF 934 Draft, draft-ietf-idmr-dvmrp-v3-05, October 1997. 936 [PARS] M. Parsa and J. Garcia-Luna-Aceves, "A protocol for scaleable 937 loop-free multicast routing", IEEE JSAC, vol.15, no.3, p.316- 938 331, April 1997 940 [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", 941 IEEE/ACM Transactions on Networking 5(5), pp. 601-615. 943 [TIAN] J. Tian, G. Neufeld, "Forwarding State Reduction for Sparse Mode 944 Multicast Communication" 946 [UUNE] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 947 "Requirements for Traffic Engineering Over MPLS", , April 1998. 950 Authors Addresses 952 Dirk Ooms 953 Alcatel Corporate Research Center 954 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 955 Phone : 32-3-240-4732 956 Fax : 32-3-240-9932 957 E-mail: oomsd@rc.bel.alcatel.be 959 Wim Livens 960 Alcatel Corporate Research Center 961 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 962 Phone : 32-3-240-7570 963 E-mail: livensw@rc.bel.alcatel.be 965 Bernard Sales 966 Alcatel Corporate Research Center 967 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 968 Phone : 32-3-240-9574 969 E-mail: salesb@btmaa.bel.alcatel.be 971 Maria Fernanda Ramalho 972 Alcatel Corporate Research Center 973 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 974 Phone : 32-3-240-9725 975 E-mail: ramalhom@rc.bel.alcatel.be