GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3353

Network Working Group D. Ooms Request for Comments: 3353 Alcatel Category: Informational B. Sales

                                                               Alcatel
                                                             W. Livens
                                                          Colt Telecom
                                                            A. Acharya
                                                                   IBM
                                                           F. Griffoul
                                                               Ulticom
                                                             F. Ansari
                                                             Bell Labs
                                                           August 2002
                   Overview of IP Multicast in a
         Multi-Protocol Label Switching (MPLS) Environment

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

 This document offers a framework for IP multicast deployment in an
 MPLS environment.  Issues arising when MPLS techniques are applied to
 IP multicast are overviewed.  The pros and cons of existing IP
 multicast routing protocols in the context of MPLS are described and
 the relation to the different trigger methods and label distribution
 modes are discussed.  The consequences of various layer 2 (L2)
 technologies are listed.  Both point-to-point and multi-access
 networks are considered.

Ooms, et al. Informational [Page 1] RFC 3353 IP Multicast in an MPLS Environment August 2002

Table of Contents

 1.     Introduction .............................................  3
 2.     Layer 2 Characteristics ..................................  4
 3.     Taxonomy of IP Multicast Routing Protocols
        in the Context of MPLS ...................................  5
 3.1.   Aggregation ..............................................  5
 3.2.   Flood & Prune ............................................  5
 3.3.   Source/Shared Trees ......................................  6
 3.4.   Co-existence of Source and Shared Trees ..................  7
 3.5.   Uni/Bi-directional Shared Trees .......................... 10
 3.6.   Encapsulated Multicast Data .............................. 11
 3.7.   Loop-free-ness ........................................... 11
 3.8.   Mapping of Characteristics on Existing Protocols ......... 11
 4.     Mixed L2/L3 Forwarding in a Single Node .................. 12
 5.     Taxonomy of IP Multicast LSP Triggers .................... 14
 5.1.   Request Driven ........................................... 14
 5.1.1. General .................................................. 14
 5.1.2. Multicast Routing Messages ............................... 15
 5.1.3. Resource Reservation Messages ............................ 15
 5.2.   Topology Driven .......................................... 16
 5.3.   Traffic Driven ........................................... 16
 5.3.1. General .................................................. 16
 5.3.2. An Implementation Example ................................ 17
 5.4.   Combinations of Triggers and Label Distribution Modes .... 18
 6.     Piggy-backing ............................................ 18
 7.     Explicit Routing ......................................... 20
 8.     QoS/CoS .................................................. 20
 8.1.   DiffServ ................................................. 20
 8.2.   IntServ and RSVP ......................................... 21
 9.     Multi-access Networks .................................... 21
 10.    More Issues .............................................. 22
 10.1.  TTL Field ................................................ 22
 10.2.  Independent vs. Ordered Label Distribution Control ....... 23
 10.3.  Conservative vs. Liberal Label Retention Mode ............ 24
 10.4.  Downstream vs. Upstream Label Allocation ................. 25
 10.5.  Explicit vs. Implicit Label Distribution ................. 25
 11.    Security Considerations .................................. 26
 12.    Acknowledgements ......................................... 26
 Informative References........................................... 27
 Authors' Addresses .............................................. 28
 Full Copyright Statement ........................................ 30

Ooms, et al. Informational [Page 2] RFC 3353 IP Multicast in an MPLS Environment August 2002

Table of Abbreviations

 ATM     Asynchronous Transfer Node
 CBT     Core Based Tree
 CoS     Class of Service
 DLCI    Data Link Connection Identifier
 DRrecv  Designated Router of the receiver
 DRsend  Designated Router of the sender
 DVMRP   Distant Vector Multicast Routing Protocol
 FR      Frame Relay
 IGMP    Internet Group Management Protocol
 IP      Internet Protocol
 L2      layer 2 (e.g. ATM, Frame Relay)
 L3      layer 3 (e.g. IP)
 LSP     Label Switched Path
 LSR     Label Switching Router
 LSRd    Downstream LSR
 LSRu    Upstream LSR
 MOSPF   Multicast OSPF
 mp2mp   multipoint-to-multipoint
 MRT     Multicast Routing Table
 p2mp    point-to-multipoint
 PIM-DM  Protocol Independent Multicast-Dense Mode
 PIM-SM  Protocol Independent Multicast-Sparse Mode
 QoS     Quality of Service
 RP      Rendezvous Point
 RPT-bit RP Tree bit [DEER]
 RSVP    Resource reSerVation Protocol
 SPT-bit Shortest Path Tree [DEER]
 SSM     Source Specific Multicast
 TCP     Transmission Control Protocol
 UDP     User Datagram Protocol
 VC      Virtual Circuit
 VCI     Virtual Circuit Identifier
 VP      Virtual Path
 VPI     Virtual Path Identifier

1. Introduction

 In an MPLS cloud the routes are determined by a L3 routing protocol.
 These routes can then be mapped onto L2 paths to enhance network
 performance.  Besides this, MPLS offers a vehicle for enhanced
 network services such as QoS/CoS, traffic engineering, etc.
 Current unicast routing protocols generate a same (optimal) shortest
 path in steady state for a certain (source, destination) pair.
 Remark that unicast protocols can behave slightly different with
 regard to equal cost paths.

Ooms, et al. Informational [Page 3] RFC 3353 IP Multicast in an MPLS Environment August 2002

 For multicast, the optimal solution (minimum cost to interconnect N
 nodes) would impose a Steiner tree computation.  Unfortunately, no
 multicast routing protocol today is able to maintain such an optimal
 tree.  Different multicast protocols will therefore, in general,
 generate different trees.
 The discussion is focused on intra-domain multicast routing
 protocols.  Aspects of inter-domain routing are beyond the scope of
 this document.

2. Layer 2 Characteristics

 Although MPLS is multiprotocol both at L3 and at L2, in practice IP
 is the only considered L3 protocol.  MPLS can run on top of several
 L2 technologies (PPP/Sonet, Ethernet, ATM, FR, ...).
 When label switching is mapped on L2 switching capabilities (e.g.
 VPI/VCI is used as label), attention is mainly focused on the mapping
 to ATM [DAVI].  ATM offers high switching capacities and QoS
 awareness, but in the context of MPLS it poses several limitations
 which are described in [DAVI].  Similar considerations are made for
 Frame Relay on L2 in [CONT].  The limitations can be summarized as:
  1. Limited Label Space: either the standardized or the implemented

number of bits available for a label can be small (e.g. VPI/VCI

   space, DLCI space), limiting the number of LSPs that can be
   established.
  1. Merging: some L2 technologies or implementations of these

technologies do not support multipoint-to-point and/or

   multipoint-to-multipoint 'connections', obstructing the merging of
   LSPs.
  1. TTL: L2 technologies do not support a 'TTL-decrement' function.
 All three limitations can impact the implementation of multicast in
 MPLS as will be described in this document.
 When native MPLS is deployed the above limitations vanish.  Moreover
 on PPP and Ethernet links the same label can be used at the same time
 for a unicast and a multicast LSP because different EtherTypes for
 MPLS unicast and multicast are defined [ROSE].

Ooms, et al. Informational [Page 4] RFC 3353 IP Multicast in an MPLS Environment August 2002

3. Taxonomy of IP Multicast Routing Protocols in the Context of MPLS

 At the moment, an abundance of IP multicast routing protocols is
 being proposed and developed.  All these protocols have different
 characteristics (scalability, computational complexity, latency,
 control message overhead, tree type, etc...).  It is not the purpose
 of this document to give a complete taxonomy of IP multicast routing
 protocols, only their characteristics relevant to the MPLS technology
 will be addressed.
 The following characteristics are considered:
  1. Aggregation
  2. Flood & Prune
  3. Source/Shared trees
  4. Co-existence of Source and Shared Trees
  5. Uni/Bi-directional shared trees
  6. Encapsulated multicast data
  7. Loop-free-ness
 The discussion of these characteristics will not lead to the
 selection of one superior multicast routing protocol.  It is not
 impossible that different IP multicast routing protocols will be
 deployed in the Internet.

3.1. Aggregation

 In unicast different destination addresses are aggregated to one
 entry in the routing table, yielding one FEC and one LSP.
 The granularity of multicast streams is (*, G) for a shared tree and
 (S, G) for a source tree, S being the source address and G the
 multicast group address.  Aggregation of multicast trees with
 different multicast 'destination' addresses on one LSP is a subject
 for further study.

3.2. Flood & Prune

 To establish a multicast tree some IP multicast routing protocols
 (e.g. DVMRP, PIM-DM) flood the network with multicast data.  The
 branches can then be pruned by nodes which do not want to receive the
 data of the specific multicast group.  This process is repeated
 periodically.
 Flood & Prune multicast routing protocols have some characteristics
 which significantly differ from unicast routing protocols:

Ooms, et al. Informational [Page 5] RFC 3353 IP Multicast in an MPLS Environment August 2002

 a) Volatile.  Due to the Flood & Prune nature of the protocol, very
    volatile tree structures are generated.  Solutions to map a
    dynamic L3 p2mp tree to a L2 p2mp LSP need to be efficient in
    terms of signaling overhead and LSP setup time.  The volatile L2
    LSP will consume a lot of labels throughout the network, which is
    a disadvantage when label space is limited.
 b) Traffic-driven.  The router only creates state for a certain group
    when data arrives for that group.  Routers also independently
    decide to remove state when an inactivity timer expires.
  1. Thus LSPs can not be pre-established as is usually done in

unicast. To minimize the time between traffic arrival and LSP

      establishment a fast LSP setup method is favorable.
  1. Since creation and deletion of a L3 route at each node is

triggered by traffic, this suggests that the LSP associated with

      the route be setup and torn down in a traffic-driven manner as
      well.
  1. If an LSR does not support L3 forwarding this traffic-driven

nature even requires that the upstream LSR takes the initiative

      to create an LSP (Upstream Unsolicited or Downstream on Demand
      label advertisement).

3.3. Source/Shared Trees

 IP multicast routing protocols create either source trees (S, G),
 i.e. a tree per source (S) and per multicast group (G), or shared
 trees (*, G), i.e. one tree per multicast group (Figure 1).
              R1                         R1           R1
       S1    /                          /            /
        \   /                          /            /
         \ /                          /            /
          C---R2                    S1---R2      S2---R2
         / \                          \            \
        /   \                          \            \
      S2     \                          \            \
              R3                         R3           R3
                Figure 1. Shared tree and Source trees
 The advantage of using shared trees, when label switching is applied,
 is that shared trees consume less labels than source trees (1 label
 per group versus 1 label per source and per group).

Ooms, et al. Informational [Page 6] RFC 3353 IP Multicast in an MPLS Environment August 2002

 However, mapping a shared tree end-to-end on L2 implies setting up
 multipoint-to-multipoint (mp2mp) LSPs.  The problem of implementing
 mp2mp LSPs boils down to the merging problem discussed earlier.
 Note that in practice shared trees are often only used to discover
 new sources of the group and a switchover to a source tree is made at
 very low bitrates.

3.4. Co-existence of Source and Shared Trees

 Some protocols support both source and shared trees (e.g. PIM-SM) and
 one router can maintain both (*, G) and (S, G) state for the same
 group G.  Two cases of state co-existence are described below.
 Assume topologies with senders Si and receivers Ri.  RP is the
 Rendezvous Point.  Ni are LSRs.  The numbers are the interface
 numbers, "Reg" is the Register interface.  All IGMP and PIM
 Join/Prune messages are shown in the figures.  It is also indicated
 whether the RPT-bit is set for the (S, G) state.
 1) Figure 2 shows a switchover from shared to source tree.  Assume
    that the shortest path from R1 to RP is via N1-N2-N5.  N1, the
    Designated Router of receiver R1 (DRrecv), decides to initiate a
    source tree for source S1.  After the arrival of data via the
    source tree in N2, N2 will send a prune to N5 for source S1.
    State co-existence occurs in the node where the overlap of shared
    and source tree starts (N2) and in the node where S1 does not need
    forwarding on the shared tree anymore (N5).
                PJ
        IJ      PJS     PJS
         -> 1  2 -> 1  2 -> 1  2
     R1-----N1------N2------N3----S1
                   3|       |3            IJ=Igmp Join
                    ||PPS   |             PJ=Pim Join (*,G)
                    |vPJ    |             PJS=Pim Join (S1,G)
         IJ     PJ  |    PJ |             PPS=Pim Prune (S1,G)
         ->     ->  |3   -> |
     R2-----N4------N5------RP----S2
           1  2    1  2    1
                               Figure 2

Ooms, et al. Informational [Page 7] RFC 3353 IP Multicast in an MPLS Environment August 2002

 The multicast routing states created in the Multicast Routing Table
 (MRT) are:
   in RP: (*,G):Reg->1   (i.e. incoming itf=Reg; outgoing itf=1)
   in N1: (*,G):2->1
   in N2: (*,G):3->1
          (S1,G):2->1
   in N3: (S1,G):2->Reg,1
   in N4: (*,G):2->1
   in N5: (*,G):2->1,3
          (S1,G)RPT-bit:2->1
 2) Figure 3 shows that even without a switchover, state co-existence
    can occur.  Multicast traffic from a sender will create (S, G)
    state in the Designated Router of the sender (DRsend; N3 in Figure
    3 is the DRsend of S).  Each node on a shared-tree has (*, G)
    state.  Thus an on-tree DRsend has both (*, G) and (S, G) state.
    If the DRsend is on-tree it will also send a prune for S towards
    the RP, creating (S, G) state in all nodes until the first router
    which has a branch (N1 and N2 in Figure 3).
                           S
                  PPS  PPS |
           PJ     PJ    PJ |2 PJ    IJ
         1 <- 1  3<-    <- |  <-    <-            PJ=Pim Join
       RP------N1----N2----N3----N4----R1         IJ=Igmp Join
              ^|2   1  2  1  3  1  2              PPS=Pim Prune (S,G)
            PJ||  IJ
              1|  <-
               N5----R2
                  2
                                 Figure 3
    The multicast routing states created in the MRT are:
      in RP: (*,G):Reg->1   (i.e. incoming itf=Reg; outgoing itf=1)
      in N1: (*,G):1->2,3
             (S,G)RPT-bit:1->2
      in N2: (*,G):1->2
             (S,G)RPT-bit:1->none
      in N3: (*,G):1->3
             (S,G):2->Reg,3
      in N4: (*,G):1->2
      in N5: (*,G):1->2

Ooms, et al. Informational [Page 8] RFC 3353 IP Multicast in an MPLS Environment August 2002

    In the examples one can observe that two types of state co-
    existence occur:
 1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3).  The
    (*, G) and (S, G) state have different incoming interfaces, but
    some common outgoing interfaces.  It is possible that the traffic
    of S arrives on both the (*, G) and (S, G) interfaces.  In normal
    L3 forwarding the (S, G)SPT-bit entry prohibits the forwarding of
    the traffic from S arriving on the (*, G) incoming interface.  The
    traffic of S can only temporarily arrive on the incoming
    interfaces of both the (*, G) and (S, G) entries (until N5 in
    Figure 2 and N1 in Figure 3 have processed the prune messages).
    To avoid the temporary forwarding of duplicate packets L3
    forwarding can be applied in this type of node.  If one does not
    mind the temporary duplicate packets L2 forwarding can be applied.
    In this case the (*, G) and (S, G) streams have to be merged into
    the (*, G) LSP on their common outgoing interfaces.
 2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3).  The
    (*, G) and (S, G) state have the same incoming interface.  The (S,
    G) traffic must be extracted from the (*, G) stream.  In MPLS this
    state co-existence can be handled in several ways.  Four
    approaches to this problem will be described:
    a) A first method to handle this state co-existence is to
       terminate the LSPs and forward all traffic of this group at L3.
       However a return to L3 can be avoided in case a (S, G) entry
       without an outgoing interface is added to the MRT (N2 in Figure
       3).  This entry will only receive traffic temporarily.  In this
       particular case one could ignore the (S, G) state and maintain
       the existing (*, G) LSP, the disadvantage being duplicate
       traffic for a very short time.
    b) A second approach is to assign source specific labels on the
       nodes of the shared tree.  Multiple labels will be associated
       with one (*, G) entry, corresponding to one label per active
       source.  Since the nodes only know which sources are active
       when traffic from these sources arrives, the LSPs cannot be
       pre-established and a fast LSP setup method is favorable.
    c) A third way is that only source trees are labelswitched and
       that traffic on the shared tree is always forwarded at L3.
       This assumes that the shared tree is only used as a way for the
       receivers to find out who the sources are.  By configuring a
       low bitrate switchover threshold, one can ensure that the
       receivers switchover to source trees very quickly.

Ooms, et al. Informational [Page 9] RFC 3353 IP Multicast in an MPLS Environment August 2002

    d) In the fourth approach, an LSR which has (S, G) RPT-bit state
       with a non-null oif, advertises a label for (S, G) to the
       upstream LSR and this label advertisement is then propagated by
       each upstream LSR towards the RP.  In this way a dedicated LSP
       is created for (S, G) traffic from the RP to the LSR with the
       (S, G) RPT-bit state.  In the latter LSR, the (S, G) LSP is
       merged onto the (*, G) LSP for the appropriate outgoing
       interfaces.  This ensures that (S, G) packets traveling on the
       shared tree do not make it past any LSR which has pruned S.

3.5. Uni/Bi-directional Shared Trees

 Bidirectional shared trees (e.g. CBT [BALL]) have the disadvantage of
 creating a lot of merging points (M) in the nodes (N) of the shared
 tree.  Figure 4 shows these merging points resulting from 2 senders
 S1 and S2 on a bidirectional tree.
               S1                   S2
               ||                   ||
               v| <-   <-   <-   <- |v
        <-   <- | ->   ->   ->   -> | ->
        ----N----M----M----M----M----M----N
           ||   ||   ||   ||   ||   ||
           |v   |v   |v   |v   |v   |v
           |    |    |    |    |    |
                              Figure 4.
    Multicast traffic flows from 2 senders on a bidirectional tree
 In Figure 5 the same situation for unidirectional shared trees is
 depicted.  In this case the data of the senders is tunneled towards
 the root node R, yielding only a single merging point, namely the
 root of the shared tree itself.
               S1
        tunnel ||                  S2
        <----- v|       tunnel     ||
    to R<------------------------- v|
        ->   -> | ->   ->   ->   -> | ->
        ----N----N----N----N----N----N----N
           ||   ||   ||   ||   ||   ||
           |v   |v   |v   |v   |v   |v
           |    |    |    |    |    |
                              Figure 5.
    Multicast traffic flows from 2 senders on a unidirectional tree

Ooms, et al. Informational [Page 10] RFC 3353 IP Multicast in an MPLS Environment August 2002

3.6. Encapsulated Multicast Data

 Sources of unidirectional shared trees and non-member sources of
 bidirectional shared trees encapsulate the data towards the root
 node.  The data is then decapsulated in the root node.  The
 encapsulation and decapsulation of multicast data are L3 processes.
 Thus in case of encapsulation/decapsulation a path can never be
 mapped onto an end-to-end LSP:  the traffic can not be forwarded on
 L2 on the Register interface of the DRsend (encapsulation), nor can
 it cross the root (decapsulation) at L2.
 Remarks:
 1) If the LSR supports mixed L2/L3 forwarding (section 4), the (S, G)
    traffic in DRsend can still be forwarded at L2 on all outgoing
    interfaces other than the Register interface.
 2) The encapsulated traffic can also benefit from MPLS by label
    switching the tunnels.
 3) If the root node decides to join the source (to avoid
    encapsulation/decapsulation), an end-to-end (S, G) LSP can be
    constructed.

3.7. Loop-free-ness

 Multicast routing protocols which depend on a unicast routing
 protocol suffer from the same transient loops as the unicast
 protocols do, however the effect of loops will be much worse in the
 case of multicast.  The reason being, each time a multicast packet
 goes around a loop, copies of the packet may be emitted from the loop
 if branches exist in the loop.
 Currently loop detection is a configurable option in LDP and a
 decision on the mechanism for loop prevention is postponed.

3.8. Mapping of Characteristics on Existing Protocols

 The above characteristics are summarized in Table 1 for a
 non-exhaustive list of existing IP multicast routing protocols:
 DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER],
 SSM [HOLB], SM [PERL].

Ooms, et al. Informational [Page 11] RFC 3353 IP Multicast in an MPLS Environment August 2002

 +------------------+------+------+------+------+------+------+------+
 |                  |DVMRP |MOSPF |CBT   |PIM-DM|PIM-SM|SSM   |SM    |
 +------------------+------+------+------+------+------+------+------+
 |Aggregation       |no    |no    |no    |no    |no    |no    |no    |
 +------------------+------+------+------+------+------+------+------+
 |Flood & Prune     |yes   |no    |no    |yes   |no    |no    |option|
 +------------------+------+------+------+------+------+------+------+
 |Tree Type         |source|source|shared|source|both  |source|shared|
 +------------------+------+------+------+------+------+------+------+
 |State Co-existence|no    |no    |no    |no    |yes   |no    |no    |
 +------------------+------+------+------+------+------+------+------+
 |Uni/Bi-directional|N/A   |N/A   |bi    |N/A   |uni   |uni   |bi    |
 +------------------+------+------+------+------+------+------+------+
 |Encapsulation     |no    |no    |yes   |no    |yes   |no    |yes   |
 +------------------+------+------+------+------+------+------+------+
 |Loop Free         |no    |no    |no    |no    |no    |no    |no    |
 +------------------+------+------+------+------+------+------+------+
          Table 1. Taxonomy of IP Multicast Routing Protocols
 From Table 1 one can derive e.g. that DVMRP will consume a lot of
 labels when the Flood & Prune L3 tree is mapped onto a L2 tree.
 Furthermore since DVMRP uses source trees it experiences no merging
 problem when label switching is applied.  The table can be
 interpreted in the same way for the other protocols.

4. Mixed L2/L3 Forwarding in a Single Node

 Since unicast traffic has one incoming and one outgoing interface the
 traffic is either forwarded at L2 OR at L3 (Figure 6).  Because
 multicast traffic can be forwarded to more than one outgoing
 interface one can consider the case that traffic to some branches is
 forwarded on L2 and to other branches on L3 (Figure 7).
                +--------+            +--------+
                |   L3   |            |   L3   |
                |  +>>+  |            |        |
                |  |  |  |            |        |
                +--|--|--+            +--------+
                |  |  |  |            |        |
            ->-----+  +----->     ->------>>----->
                |   L2   |            |   L2   |
                +--------+            +--------+
            Figure 6. Unicast forwarding on resp. L3 or L2

Ooms, et al. Informational [Page 12] RFC 3353 IP Multicast in an MPLS Environment August 2002

          +--------+          +--------+         +--------+
          |   L3   |          |   L3   |         |   L3   |
          |  +>>++ |          |  +>>+  |         |        |
          |  |  || |          |  |  |  |         |        |
          +--|--||-+          +--|--|--+         +--------+
          |  |  |+---->       |  |  +----->      |      +---->
      ->-----+  |  |          |  |L2   |      ->----->>-+ |
          |   L2+----->   ->-----+>>------>      |   L2 +---->
          +--------+          +--------+         +--------+
     Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2
 Nodes that support this 'mixed L2/L3 forwarding' feature allow
 splitting of a multicast tree into branches in which some are
 forwarded at L3 while others are switched at L2.
 The L3 forwarding has to take care that the traffic is not forwarded
 on those branches that already get their traffic on L2.  This can be
 accomplished by e.g. providing an extra bit in the Multicast Routing
 Table.
 Although the mixed L2/L3 forwarding requires processing of the
 traffic at L3, the load on the L3 forwarding engine is generally less
 than in a pure L3 node.
 Supporting this 'mixed L2/L3 forwarding' feature has the following
 advantages:
 a) Assume LSR A (Figure 8) is an MPLS edge node for the branch
    towards LSR B and an MPLS core node for the branch towards LSR C.
    The mixed L2/L3 forwarding allows that the branch towards C is not
    disturbed by a return to L3 in LSR A.
                         +-------------+
                         | MPLS cloud  |
                         |     N       |
                         |    / \      |
                         |   /   \     |
                         |  /     \    |
                         | A       N   |
                         |/ \       \  |
                         |   \       \ |
                        /|    \        |
                       B |     C       |
                         |             |
                         +-------------+
              Figure 8.  Mixed L2/L3 forwarding in node A

Ooms, et al. Informational [Page 13] RFC 3353 IP Multicast in an MPLS Environment August 2002

 b) Enables the use of the traffic driven trigger with the Downstream
    Unsolicited or Upstream on Demand label distribution mode, as
    explained in section 5.3.1.

5. Taxonomy of IP Multicast LSP Triggers

 The creation of an LSP for multicast streams can be triggered by
 different events, which can be mapped on the well known categories of
 'request driven', 'topology driven' and 'traffic driven'.
 a) Request driven:  intercept the sending or receiving of control
    messages (e.g. multicast routing messages, resource reservation
    messages).
 b) Topology driven:  map the L3 tree, which is available in the
    Multicast Routing Table, to a L2 tree.  The mapping is done even
    if there is no traffic.
 c) Traffic driven:  the L3 tree is mapped onto a L2 tree when data
    arrives on the tree.

5.1. Request Driven

5.1.1. General

 The establishment of LSPs can be triggered by the interception of
 outgoing (requiring that the label is requested by the downstream
 LSR) or incoming (requiring that the label is requested by the
 upstream LSR) control messages.  Figure 9 illustrates these two
 cases.
         LSRu              LSRd      LSRu              LSRd
     -------+              +---      ---+              +-------
            |   control    |            |   control    |
     <---*<-----message-------      <-------message-------*----
         |  |              |            |              |  |
  trigger|  |              |            |              |  |trigger
         |  |    bind      |            |    bind      |  |
         +--------or--------->      <---------or----------+
            | bind-request |            | bind-request |
            |              |            |              |
            |              |            |              |
            |----data----->|            |-----data---->|
                incoming                    outgoing
                   Figure 9. Request driven trigger
    (interception of resp. incoming and outgoing control messages)

Ooms, et al. Informational [Page 14] RFC 3353 IP Multicast in an MPLS Environment August 2002

 The downstream LSR (LSRd) sends a control message to the upstream LSR
 (LSRu).  In the case that incoming control messages are intercepted
 and the MPLS module in LSRu decides to establish an LSP, it will send
 an LDP bind (Upstream Unsolicited mode) or an LDP bind request
 (Downstream on Demand mode) to LSRd.
 Currently, for multicast, we can identify two important types of
 control messages:  the multicast routing messages and the resource
 reservation messages.

5.1.2. Multicast Routing Messages

 In principle, this mechanism can only be used by IP multicast routing
 protocols which use explicit signaling:  e.g. the Join messages in
 PIM-SM or CBT.  Remark that DVMRP and PIM-DM can be adapted to
 support this type of trigger [FARI], however, at the cost of
 modifying the IP multicast routing protocol itself!
 IP multicast routing messages can create both hard states (e.g. CBT
 Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent
 periodically).  The latter generates more control traffic for tree
 maintenance and thus requires more processing in the MPLS module.
 Triggers based on the multicast routing protocol messages have the
 disadvantage that the 'routing calculations' performed by the
 multicast routing daemon to determine the Multicast Routing Table are
 repeated by the MPLS module.  The former determines the tree that
 will be used at L3, the latter calculates an identical tree to be
 used by L2.  Since the same task is performed twice, it is better to
 create the multicast LSP on the basis of information extracted from
 the Multicast Routing Table itself (see section 5.2 and 5.3).  The
 routing calculations become more complex for protocols which support
 a switch-over from a (*, G) tree to a (S, G) tree because more
 messages have to be interpreted.
 When a host has a point-to-point connection to the first router one
 could create 'LSPs up to the end-user' by intercepting not only the
 multicast routing messages but the IGMP Join/Prune messages ([FENN])
 as well.

5.1.3. Resource Reservation Messages

 As is the case for unicast the RSVP Resv message can be used as a
 trigger to establish LSPs.  A source of a multicast group will send
 an RSVP Path message down the tree, the receivers can then reply with
 an RSVP Resv message.  RSVP scales equally well for multicast as it
 does for unicast because:

Ooms, et al. Informational [Page 15] RFC 3353 IP Multicast in an MPLS Environment August 2002

 a) RSVP Resv messages can merge.
 b) RSVP Resv messages are only sent up to the first branch which made
    the required reservation.

5.2. Topology Driven

 The Multicast Routing Table (MRT) is maintained by the IP multicast
 routing protocol daemon.  The MPLS module maps this L3 tree topology
 information to L2 p2mp LSPs.
 The MPLS module can poll the MRT to extract the tree topologies.
 Alternatively, the multicast daemon can be modified to notify the
 MPLS module directly of any change to the MRT.
 The disadvantage of this method is that labels are consumed even when
 no traffic exists.

5.3. Traffic Driven

5.3.1. General

 A traffic driven trigger method will only construct LSPs for trees
 which carry traffic.  It consumes less labels than the topology
 driven method, as labels are only allocated when there is traffic on
 the multicast tree.
 If the mixed L2/L3 forwarding capability (see section 4) is not
 supported, the traffic driven trigger requires a label distribution
 mode in which the label is requested by the LSRu (Downstream on
 Demand or Upstream Unsolicited mode).  In Figure 10, suppose an LSP
 for a certain group exists to LSRd1 and another LSRd2 wants to join
 the tree.  In order for LSRd2 to initiate a trigger, it must already
 receive the traffic from the tree.  This can be either at L2 or at
 L3.  The former case is a chicken and egg problem.  The latter case
 requires a mixed L2/L3 forwarding capability in LSRu to add the L3
 branch.

Ooms, et al. Informational [Page 16] RFC 3353 IP Multicast in an MPLS Environment August 2002

                                  +--------+
                                  |  LSRd1 |
                                  |        |
       +--------+                 |   L3   |
       |  LSRu  |                 +--------+
       |        |                 |        |
       |   L3   |    +-------------------------->
       +--------+   /             |   L2   |
       |        |  /              +--------+
   ->-------------+
       |   L2   |                 +--------+
       +--------+                 |  LSRd2 |
                                  |        |
                                  |   L3   |
                                  +--------+
                                  |        |
                                  |        |
                                  |   L2   |
                                  +--------+
             Figure 10. The LSRu has to request the label.

5.3.2. An Implementation Example

 To illustrate that by choosing an appropriate trigger one can
 conclude that MPLS multicast is independent of the deployed multicast
 routing protocol, the following implementation example is given.
 Current implementations on Unix platforms of IP multicast routing
 protocols (DVMRP, PIM) have a Multicast Forwarding Cache (MFC).  The
 MFC is a cached copy of the Multicast Routing Table.  The MFC
 requests an entry for a certain multicast group when it experiences a
 'cache miss' for an incoming multicast packet.  The missing routing
 information is provided by the multicast daemon.  If at a later point
 in time something changes to the route (outgoing interfaces added or
 removed), the multicast daemon will update the MFC.
 The MFC is implemented as a common component (part of the kernel),
 which makes this trigger very attractive because it can be
 transparently used for any IP multicast routing protocol.
 Entries in the MFC are removed when no traffic is received for this
 entry for a certain period of time.  When label switching is applied
 to a certain MFC-entry, the L3 will not see any packets arriving
 anymore.  To retain the normal MFC behavior, the L3 counters of the
 MFC need to be updated by L2 measurements.

Ooms, et al. Informational [Page 17] RFC 3353 IP Multicast in an MPLS Environment August 2002

5.4. Combinations of Triggers and Label Distribution Modes

 Table 2 shows the valid combinations of label distribution modes and
 trigger types that were discussed in the previous sections.  The (X)
 means that the combination is valid when the mixed L2/L3 forwarding
 feature is supported in the LSR.
   +----------------+---------------------------------------------+
   |                |              label requested by             |
   |                |          LSRu        |          LSRd        |
   |                +----------------------+----------------------+
   |                | upstream  |downstream|downstream |upstream  |
   |                |unsolicited|on demand |unsolicited|on demand |
   +----------------+-----------+----------+-----------+----------+
   |Request Driven  |           |          |           |          |
   |(incoming msg)  |    X      |    X     |           |          |
   +----------------+-----------+----------+-----------+----------+
   |Request Driven  |           |          |           |          |
   |(outgoing msg)  |           |          |     X     |    X     |
   +----------------+-----------+----------+-----------+----------+
   |Topology Driven |    X      |    X     |     X     |    X     |
   +----------------+-----------+----------+-----------+----------+
   |Traffic Driven  |    X      |    X     |    (X)    |   (X)    |
   +----------------+-----------+----------+-----------+----------+
 Table 2. Valid combinations of triggers and label distribution modes

6. Piggy-backing

 In Figure 9 (outgoing case) one can observe that instead of sending 2
 separate messages the label advertisement can be piggy-backed on the
 existing control messages.  For multicast two piggy-back candidates
 exist:
 a) Multicast routing messages:  protocols such as PIM-SM and CBT have
    explicit Join messages which could carry the label mappings.  This
    approach is described in [FARI].  When different multicast routing
    protocols are deployed, an extension to each of these protocols
    has to be defined.
 b) RSVP Resv messages:  a label mapping extension object for RSVP,
    also applicable to multicast, is proposed in [AWDU].
 The pros and cons of piggy-backing on multicast routing messages will
 be described now.

Ooms, et al. Informational [Page 18] RFC 3353 IP Multicast in an MPLS Environment August 2002

 Piggy-backing has following advantages:
 a) If the label advertisement is piggy-backed on multicast routing
    messages, then the distribution of routes and the distribution of
    labels is tightly synchronized.  This eliminates difficult corner
    cases such as "what do I do with a label if I don't (yet) have a
    routing table entry to attach it to?".  It also minimizes the
    interval between the establishment of the multicast route and the
    mapping of a label to the route.
 b) The number of control messages needed to support label
    advertisement beyond those needed to support the multicast routing
    itself is zero.
 Following disadvantages of piggy-backing can be identified:
 a) In dense-mode protocols there are no messages on which the label
    advertisement can be piggy-backed.  [FARI] proposes to add
    periodic messages to dense-mode protocols for the purpose of label
    advertisement, which is a heavy impact on the multicast routing
    protocol and it eliminates the message conserving benefit of
    piggy-backing.
 b) The second solution for the state co-existence problem (section
    3.4) cannot be applied in combination with piggy-backing.
 c) Piggy-backing requires extending the multicast routing protocol,
    and hence becomes less attractive if label advertisement needs to
    be supported for multiple multicast routing protocols.  Especially
    when not only the label advertisement but also the other two LDP
    functions (discovery and adjacency) are piggy-backed.
 d) Piggy-backing assumes the Downstream Unsolicited label
    distribution mode, this excludes a number of trigger methods (see
    Table 2).
 e) LDP normally runs on top of TCP, assuring a reliable communication
    between peer nodes.  Piggy-backed label advertisement often
    replaces the reliable communication with periodic soft-state label
    advertisements.  Because of this periodic label advertisement the
    control traffic (in number of bytes) will increase.

Ooms, et al. Informational [Page 19] RFC 3353 IP Multicast in an MPLS Environment August 2002

 f) If a VCID notification mechanism [NAGA] is required, the (in-band)
    notification can normally be done by sending the LDP bind through
    the newly established VC.  This way only one message is
    required.  This method cannot be combined with piggy-backing
    because the routing message is sent before the VC can be
    established.  An extra handshake message is thus required,
    diminishing the benefit of piggy-backing.
 So whether piggy-backing makes sense or not depends heavily on which
 and how many multicast routing protocols are deployed, whether LDP is
 already used for unicast, which trigger mechanism is used, ...
 Piggy-backing is just one possible component of an MPLS multicast
 solution.

7. Explicit Routing

 Explicit routing for unicast refers to overriding the unicast routing
 table by using LSPs.
 A first way to interpret "multicast explicit routing" is overriding
 the tree established by the multicast routing protocol by another LSP
 tree (e.g. a Steiner tree calculated by an off-line tool).  In this
 interpretation the current 'shortest path' multicast routing protocol
 becomes obsolete and can be replaced by label advertisement messages
 that follow an explicit route (e.g. a branch of the Steiner tree).
 A second way of interpreting "multicast explicit routing" is that the
 known multicast routing protocols are running, but that the messages
 generated by these protocols use explicit unicast routes (instead of
 the IGP shortest path routes) to construct trees.

8. QoS/CoS

8.1. DiffServ

 The Differentiated Services approach can be applied to multicast as
 well.  It introduces finer stream granularities (DiffServ Codepoint
 (DSCP) as an extra differentiator).  A sender can construct one or
 more trees with different DSCPs.
 These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily
 onto LSPs when the traffic driven trigger is used.  In this case one
 can create LSPs with different attributes for the various DSCPs.
 Note however that these LSPs still use the same route as long as the
 tree construction mechanism itself does not take the DSCP as an
 input.

Ooms, et al. Informational [Page 20] RFC 3353 IP Multicast in an MPLS Environment August 2002

8.2. IntServ and RSVP

 RSVP can be used to setup multicast trees with QoS.  An important
 multicast issue is the problem of how to map the 'heterogeneous
 receivers' paradigm onto L2 (remark that it is not solved in IP
 either).  This subject is tackled in [CRAW].  Pragmatic approaches
 are the 'Limited Heterogeneity Model' which allows a best effort
 service and a single alternate QoS (e.g. a QoS proposed by the sender
 in a RSVP Path message) and the 'Homogeneous Model' which allows only
 a single QoS.
 The first approach will construct full trees for each service class.
 The sender has to send its traffic twice across the network (e.g. 1
 best-effort and 1 QoS tree).  Both trees can be label switched.
 The second approach constructs one tree and the best-effort users are
 connected to the QoS tree.  If the branches created for best-effort
 users are not to be label switched, (thus carried by a hop-by-hop
 default LSP) the QoS multicast traffic has to be merged onto these
 default LSPs.  This function can be provided by the 'mixed L2/L3
 forwarding' feature described in section 4.  If this is not
 available, merging is necessary to avoid a return to L3 in the QoS
 LSP.
 The mapping of the IntServ service categories onto L2 for ATM service
 categories is studied in [GARR].

9. Multi-access Networks

 Multicast MPLS on multi-access networks poses a special problem.  An
 LSR that wants to join a group must always be ready to accept the
 label that is already assigned to the group LSP (to another
 downstream LSR on the link).  This can be achieved in three ways:
 1) Each LSR on the multi-access link memorizes all the advertised
    labels on the link, even if it has not received a join for the
    associated group.  If an LSR is added to the multi-access link it
    has to retrieve this information from another LSR on the link or
    in case of soft state label advertisement it can wait a certain
    time before it can allocate labels itself.  If LSRs allocate a
    label 'at the same moment' the LSR with the highest IP address
    could keep it, while the other LSRs withdraw the label.
 2) Each LSR gets its own label range to allocate labels from.  A
    mechanism for label partitioning is described in [FARI].  If an
    LSR is added to the multi-access link, the label ranges have to be
    negotiated again and possibly existing LSPs are torn down and
    are reconstructed with other labels.

Ooms, et al. Informational [Page 21] RFC 3353 IP Multicast in an MPLS Environment August 2002

 3) Per multi-access link one LSR could be elected to be responsible
    for label allocation.  When an LSR needs a label, it can request
    it from this Label Allocation LSR.
 Unlike the unicast case, a multicast stream can have more than one
 downstream LSR which all have to use the same label.  Two solutions
 for label advertisement can be thought of:
 1) [FARI] proposes to multicast the label advertisements to all LSRs
    on the shared link.  Since multicast is not reliable this requires
    periodic label advertisements, yielding label advertisement
    duplicates in time.
 2) Another approach is that an LSR unicasts its label advertisements
    in a reliable way (TCP) to all other (or to all interested) LSRs
    on the shared link.  In this approach the hard-state character of
    LDP can be maintained but the label advertisement is duplicated in
    space.
 Since LSPs are only rewarding if they have a long lifetime and since
 the number of LSRs on a shared link is limited the second approach
 seems advantageous.
 Another issue with multicast in multi-access networks is whether to
 use upstream or downstream label assignment.  For multicast traffic,
 upstream label allocation is simpler since there can be only one
 upstream node per link that belongs to a multicast tree.  This
 (upstream) node can assign a unique label for the FEC.  With
 downstream allocation, there may be multiple downstream nodes for a
 given tree on a multi-access link; each node may propose a different
 label assignment for a FEC that would require some resolution process
 in order to come up with a single label per multicast FEC on the
 link.
 Once a label has been assigned, it is possible that the label
 assigner leaves the tree.  With downstream label assignment, this
 could happen when the label allocator leaves the group.  With
 upstream assignment this could happen when the upstream LSR changes
 due to a unicast topology change.

10. More Issues

10.1. TTL Field

 The TTL field in the IP header is typically used for loop detection.
 In IP multicast it is also used to limit the scope of the multicast
 packets by setting an appropriate TTL value.

Ooms, et al. Informational [Page 22] RFC 3353 IP Multicast in an MPLS Environment August 2002

 Thus in LSRs that do not support a TTL decrement function (e.g. ATM
 LSR), the scope restriction function is affected.  Suppose one could
 calculate in advance the number of hops an LSP traverses.  In a
 unicast LSP the TTL value could then be decremented at the ingress or
 the egress node.  For multicast all the branches of the tree can have
 different lengths so the TTL can only be decremented at the egress
 node, potentially wasting bandwidth if the TTL turns out to be zero
 or negative.

10.2. Independent vs. Ordered Label Distribution Control

 Current Label Distribution Terminology is only defined for unicast.
 The following sections explore what this terminology might mean in a
 multicast context.
 In Independent Control ([ANDE]) each LSR can take the initiative to
 do a label mapping.  In Ordered Control ([ANDE]) an LSR only maps a
 label when it already received a label from its next-hop.
 All the previously described trigger methods (section 5) combine with
 Independent Control.  Note that if the request driven approach is
 used with Independent Control the label distribution still behaves as
 in Ordered Control:  the control messages flow from the egress node
 upstream, imposing the same sequence to the label advertisement.
 Ordered Control is not applicable for a traffic driven trigger in
 case the node does not support mixed L2/L3 forwarding.  According to
 Table 2, this case implies that labels are requested by the upstream
 LSR.  Suppose in Figure 11 that an LSP exists from S to R1 and a new
 branch must be added to R2.  B will only accept a label on the A-B
 link if a label is already assigned on the B-C link.  However, to
 establish a label on the B-C link, B must already receive traffic on
 the A-B link.
                                   N---N---R1
                                  /
                                 /
                         S -----A
                                 \
                                  \
                                   B---C---R2
                              Figure 11.

Ooms, et al. Informational [Page 23] RFC 3353 IP Multicast in an MPLS Environment August 2002

10.3. Conservative vs. Liberal Label Retention Mode

 In the Conservative Mode ([ANDE]) only the labels that are used for
 forwarding data (if the next-hop for the FEC is the LSR which
 advertised the label) are allocated and maintained.  In the Liberal
 Mode labels are advertised and maintained to all neighbors.  Liberal
 Mode does not make sense in multicast.  Two reasons can be identified
 for this:
 1) All LSRs have a route for each unicast FEC.  This is not true for
    multicast FECs.
 2) For multicast an LSR always knows to which neighbor to send the
    label request or the label map messages.  In e.g. unicast
    Downstream Unsolicited mode (see below) the LSR does not know
    where to send the label mappings and thus has to send the mapping
    to all its neighbors.  In this case supporting the Liberal Mode
    does not generate extra messages (it still requires extra state
    information and label space) and thus the threshold to support
    Liberal Mode could be considered lower.
 Table 3 shows the cases where it is known by an LSR where to send its
 label requests.
            +---------+----------------------------------+
            |         |       label requested by         |
            |         |      LSRu      |      LSRd       |
            +---------+----------------+-----------------|
            |unicast  |      Yes       |       No        |
            +---------+----------------+-----------------|
            |multicast|      Yes       |      Yes        |
            +---------+----------------+-----------------+
     Table 3. Does an LSR know where to send its label requests ?
 For a unicast flow, an LSR can determine the next hop LSR, which is
 the one to send the request to in case of Upstream Unsolicited or
 Downstream on Demand mode.  The LSR is however not able to find the
 previous hop.  The previous hop is not necessarily the next hop
 towards the source, because the path from A to B is not necessarily
 the same as the path from B to A.  Such a situation can occur as a
 result of asymmetric link measures or in the event that multiple
 equal cost paths exist [PAXS].
 In the case of multicast, an LSR knows both the next hop(s) and the
 previous hop.  Because multicast trees are constructed using the
 reverse shortest path method, the previous hop is always the next hop
 towards the source or towards the root of the tree.

Ooms, et al. Informational [Page 24] RFC 3353 IP Multicast in an MPLS Environment August 2002

10.4. Downstream vs. Upstream Label Allocation

 The label can be allocated by either the downstream LSR (Downstream
 on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on
 Demand, Upstream Unsolicited, implicit).  The advantages of
 downstream label allocation are:
 a) It is the same mode as for unicast LDP, thus eliminating the need
    to develop upstream label distribution procedures.
 b) The same label can be kept when the upstream LSR changes due to a
    route change, which is an advantage on multi-access networks (see
    section 9).
 c) Compatible with piggy-backing (especially the downstream
    distribution mode).
 The advantages of upstream label allocation are:
 a) Easier label allocation in multi-access networks (see section 9).
 b) The same label can be kept when the downstream LSR (which would
    have been the label allocator in downstream mode in a multi-access
    network) leaves the group (see section 9).
 c) The upstream and implicit distribution mode allow a faster LSP
    setup when the LSP is traffic triggered.
 Whether to use upstream or downstream label distribution is outside
 the scope of this framework.  The relative complexity between the
 necessary protocol extensions and the resolution mechanism needed, as
 well as the relative operational complexity, will influence which way
 to go.

10.5. Explicit vs. Implicit Label Distribution

 Beside the explicit distribution modes (which use a signaling
 protocol), [ACHA] proposes an implicit label distribution method by
 using unknown labels.  This method has all the advantages of the
 upstream label allocation method and is probably the fastest label
 advertisement method for traffic triggered LSPs.
 Implicit label distribution is not applicable if the FEC-to-label
 binding has been advertised prior to traffic arrival, e.g. explicit
 routing (i.e. if all the information necessary to identify the FEC is
 not present in the packet).

Ooms, et al. Informational [Page 25] RFC 3353 IP Multicast in an MPLS Environment August 2002

 Explicit distribution allows pre-establishment (before the arrival of
 data) of LSPs with topology or request driven triggers.

11. Security Considerations

 In general, the use of multicast in an MPLS environment poses no
 extra security issues beyond the ones that already exist in multicast
 and MPLS protocols as such.
 The protocols described in this document are however not suited to
 cross administrative boundaries.
 When the multicast tree is determined by an existing multicast
 routing protocol (this is the assumption made in this document,
 except for the Explicit Routing section), clearly no additional
 security issues are introduced with respect to the shape of the tree
 (e.g.  unauthorized joining, tapping, blackholing, injecting traffic,
 ...).  These security issues should have been addressed in the
 specifications of the multicast routing protocols.
 In the MPLS context it is possible that control messages trigger L2
 resource allocations (e.g. LSPs).  If security flaws would still be
 present in the existing protocols (which possibly are not too harmful
 in its original context) the abusive sending of such control messages
 can yield more severe DoS attacks.
 In case of an "explicit routed" tree that is calculated centrally,
 sufficient authentication must be done on the control messages that
 set up the tree in the network nodes.

12. Acknowledgements

 The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip
 Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard
 Gastaud for the fruitful discussions and/or their thorough revision
 of this document.

Ooms, et al. Informational [Page 26] RFC 3353 IP Multicast in an MPLS Environment August 2002

Informative References

 [ACHA]  A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast
         ATM Cell Transport (IPSOFACTO) : Switching Multicast flows",
         IEEE Globecom '97.
 [ADAM]  A. Adams, J. Nicholas, W. Siadak, Protocol Independent
         Multicast Version 2 Dense Mode Specification", Work In
         Progress.
 [ANDE]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
         R. Thomas, "LDP Specification", RFC 3036, January 2001.
 [AWDU]  Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G.  and
         V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
         RFC 3209, December 2001.
 [BALL]  Ballardie, A., "Core Based Trees (CBT) Multicast Routing
         Architecture", RFC 2201, September 1997.
 [CONT]  Conta, D., Doolan, P. and A. Malis, "Use of Label Switching
         on Frame Relay Networks", RFC 3034, January 2001.
 [CRAW]  Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M.
         and J. Krawczyk, "A Framework for Integrated Services and
         RSVP over ATM", RFC 2382, August 1998.
 [DAVI]  Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen,
         E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC
         switching", RFC 3035, January 2001.
 [DEER]  Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler,
         D., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L Wei,
         "Protocol Independent Multicast-Sparse Mode (PIM-SM):
         Protocol Specification", RFC 2362, June 1998.
 [FARI]  D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to
         Distribute MPLS Labels for Multicast Routes", Work In
         Progress.
 [FENN]  Fenner, W., "Internet Group Management Protocol, IGMP,
         Version 2", RFC 2236, November 1997.
 [GARR]  Garrett, M. and M. Borden, "Interoperation of Controlled-Load
         Service and Guaranteed Service with ATM", RFC 2381, August
         1998.

Ooms, et al. Informational [Page 27] RFC 3353 IP Multicast in an MPLS Environment August 2002

 [HOLB]  H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
         Work In Progress.
 [MOY]   Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
         1994.
 [NAGA]  Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan,
         "VCID Notification over ATM link for LDP", RFC 3038, January
         2001.
 [PERL]  R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
         Maufer, "Simple Multicast", Work In Progress.
 [PUSA]  T. Pusateri, "Distance Vector Multicast Routing Protocol",
         Work In Progress.
 [PAXS]  V. Paxson, "End-to-End Routing Behavior in the Internet",
         IEEE/ACM Transactions on Networking 5(5), pp. 601-615.
 [ROSE]  Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,
         G., Li, T. and A. Conta, "MPLS Label Stack Encoding",
         RFC 3032, January 2001.

Authors Addresses

 Dirk Ooms
 Alcatel Corporate Research Center
 Fr. Wellesplein 1, 2018 Antwerp, Belgium.
 Phone : 32 3 2404732
 Fax   : 32 3 2409879
 EMail: Dirk.Ooms@alcatel.be
 Bernard Sales
 Alcatel Corporate Research Center
 Fr. Wellesplein 1, 2018 Antwerp, Belgium.
 Phone : 32 3 2409574
 EMail: Bernard.Sales@alcatel.be
 Wim Livens
 Colt Telecom
 Zweefvliegtuigstraat 10, 1130 Brussels, Belgium
 Phone : 32 2 7901705
 Fax   : 32 2 7901711
 EMail: WLivens@colt-telecom.be

Ooms, et al. Informational [Page 28] RFC 3353 IP Multicast in an MPLS Environment August 2002

 Arup Acharya
 IBM TJ Watson Research Center
 30 Saw Mill River Road, Hawthorne
 NY 10532
 Phone : 1 914 784 7481
 EMail: arup@us.ibm.com
 Frederic Griffoul
 Ulticom, Inc.
 Les Algorithmes, 2000 Route des Lucioles, BP29
 06901 Sophia-Antipolis, FRANCE
 EMail: griffoul@ulticom.com
 Furquan Ansari
 Bell Labs, Lucent Tech.
 101 Crawfords Corner Rd., Holmdel, NJ 07733
 Phone : 1 732 949 5249
 Fax   : 1 732 949 4556
 EMail: furquan@dnrc.bell-labs.com

Ooms, et al. Informational [Page 29] RFC 3353 IP Multicast in an MPLS Environment August 2002

Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Ooms, et al. Informational [Page 30]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3353.txt · Last modified: 2002/08/23 20:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki