doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc3353.txt b/doc/rfc/rfc3353.txt
new file mode 100644
index 0000000..f16fb91
--- /dev/null
+++ b/doc/rfc/rfc3353.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+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:
+
+   - 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.
+
+   - 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.
+
+   - 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:
+
+   - Aggregation
+   - Flood & Prune
+   - Source/Shared trees
+   - Co-existence of Source and Shared Trees
+   - Uni/Bi-directional shared trees
+   - Encapsulated multicast data
+   - 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.
+
+      - 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.
+
+      - 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.
+
+      - 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]
+