Internet Draft






Submitted to MPLS Working Group                                  D. Ooms
INTERNET DRAFT                                                 W. Livens
<draft-ooms-mpls-multicast-00.txt>                              B. Sales
                                                              M. Ramalho
                                                                 Alcatel

                                                            August, 1998
                                                  Expires February, 1999

                   Framework for IP Multicast in MPLS


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).  Distribution of this memo is unlimited.


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 LDP modes are
   discussed.  Focus is on ATM as a L2 technology.


Table of Contents

   1. Introduction
   2. MPLS and IP multicast: a winner combination
   3. ATM as layer 2
   4. Taxonomy of IP multicast routing protocols in the context of MPLS
   4.1. Flood & Prune



Ooms, et al.             Expires February 1999                  [Page 1]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   4.2. Source/Shared trees
   4.3. Uni/Bi-directional Shared Trees
   4.4. Loop-free-ness
   4.5. RPF Check
   4.6. Mapping of characteristics on existing protocols
   5. Taxonomy of IP multicast LSP triggers
   5.1. Request driven
   5.1.1. General
   5.1.2. Multicast routing messages
   5.1.3. Resource reservation messages
   5.2. Topology driven
   5.3. Traffic driven
   5.3.1. General
   5.3.2. An implementation example
   5.4. Combinations of triggers and LDP modes
   6. Mixed L2/L3 forwarding in a single node
   7. Piggy-backing
   8. Explicit routing
   9. QoS/CoS
   9.1 DiffServ
   9.2 IntServ and RSVP
   10. More issues
   10.1. TTL field
   10.2. Shared media
   10.3. Local control vs. egress control
   10.4. Conservative vs. optimistic
   10.5. Conservative vs. liberal
   10.6. Scalability
   11. Security Considerations
   12. Acknowledgements




   Table of Abbreviations

   ATM     Asynchronous Transfer Node
   CBT     Core Based Tree
   CoS     Class of Service
   DVMRP   Distant Vector Multicast Routing Protocol
   IGMP    Internet Group Management Protocol
   IP      Internet Protocol
   L2      layer 2 (e.g. ATM)
   L3      layer 3 (e.g. IP)
   LSP     Label Switched Path
   LSR     Label Switching Router
   LSRd    Downstream LSR
   LSRu    Upstream LSR



Ooms, et al.             Expires February 1999                  [Page 2]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   MIP     Multicast Internet Protocol
   MOSPF   Multicast OSPF
   mp2mp   multipoint-to-multipoint
   p2mp    point-to-multipoint
   PIM-DM  Protocol Independent Multicast-Dense Mode
   PIM-SM  Protocol Independent Multicast-Sparse Mode
   QoS     Quality of Service
   RPF     Reverse Path Forwarding
   RSVP    Resource reSerVation Protocol
   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 and to create a vehicle for enhanced network services
   (QoS/CoS, traffic engineering,...).

   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.

   For multicast, the optimal solution 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. MPLS and IP multicast: a winner combination

   Besides the better utilization of expensive L3 resources, multicast
   LSPs have even more benefits than unicast LSPs.  First, multicast
   traffic flows are often those long-duration high-bandwidth flows that
   are prime candidate to be label switched (e.g. video streams).  Next,
   the detection of these flows can be straightforward, as multicast
   flows are often setup using explicit routing messages (e.g. the
   receiver triggered Join messages in PIM-SM), which can be easily
   intercepted. Finally, IP multicast uses UDP, which does not have the



Ooms, et al.             Expires February 1999                  [Page 3]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   congestion-avoiding behavior of TCP.  A large scale deployment of
   multicast may therefore push aside regular TCP traffic, deteriorating
   the latter's performance.  Label switching this multicast UDP traffic
   will therefore result in a better performance for non-label-switched
   TCP-based applications.


3. ATM as layer 2

   Although MPLS is multiprotocol both at L3 and at L2, IP and ATM are
   the main L3 and L2 technologies.  ATM offers big pipes, high
   switching capacities and QoS awareness, but in the context of MPLS it
   poses several limitations [DAVI]:

   - Limited ATM resources (VPI/VCI space): current ATM switches have a
   limited range of VPI/VCIs, limiting the number of LSPs that can be
   established.

   - No VC merging: a majority of current ATM switches does not support
   VC merging, it is an active area of research, not only in the context
   of MPLS, but also in the traditional ATM world.

   - No 'TTL-decrement' function in ATM.

   All three limitations will impact the implementation of multicast in
   MPLS as will be described in this document.


4. 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.

   Following characteristics are considered:

   - Flood & Prune
   - Source/Shared trees
   - Uni/Bi-directional shared trees
   - Loop-free-ness
   - RPF check

   The discussion of these characteristics will not lead to the
   selection of one superior multicast routing protocol.  It is even



Ooms, et al.             Expires February 1999                  [Page 4]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   very probable that different IP multicast routing protocols will be
   deployed in the Internet.


4.1. Flood & Prune

   To establish the multicast tree some IP multicast routing protocols
   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, thus
   generating a very volatile tree structure. Direct mapping of this
   dynamic layer 3 (L3) point-to-multipoint (p2mp) tree to a layer 2
   (L2) p2mp LSP is problematic because of the limited ATM resources and
   the setup time of the LSPs.


4.2. 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).  Some
   protocols support a mixture of both tree types.


                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 (for ATM: less VPI/VCI
   space) than source trees (1 label per group versus 1 label per source
   and per group).

   However, mapping a shared tree end-to-end on ATM implies setting up
   multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing
   mp2mp LSPs boils down to the VC merging problem.


4.3. Uni/Bi-directional Shared Trees



Ooms, et al.             Expires February 1999                  [Page 5]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   Bidirectional shared trees have the disadvantage of creating a lot of
   merging points (M) in the nodes (N) of the shared tree. Figure 2
   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 2. Multicast traffic flows from 2 senders on a bidirectional tree


   In Figure 3 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 3. Multicast traffic flows from 2 senders on a unidirectional tree


   In unidirectional shared trees the multicast traffic is sent
   encapsulated from the Designated Router (DR) of the source to the
   root node R.  Hence, multicast traffic arriving at the root needs to
   be decapsulated first (L3 operation) before transmission over the (*,
   G) tree.  Therefore, forwarding multicast packets in the root node
   can only be done at L3, so there is no issue of merging data from
   different sources at L2 in the root node.  LSPs can only start from
   the root node, so the traffic can never be label switched end-to-end.


4.4. Loop-free-ness

   Multicast routing protocols which depend on a unicast routing



Ooms, et al.             Expires February 1999                  [Page 6]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   protocol can 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 (multicast avalanche).

   Note that there exist multicast routing protocols which are
   guaranteed loop free [PARS]. This is however not an advantage if loop
   prevention is also performed by MPLS.


4.5. RPF Check

   Some protocols perform a Reverse Path Forwarding (RPF) check on the
   received multicast packets.  This mechanism checks whether the packet
   is received on the interface which is on the shortest path to the
   source (or root).  This mechanism can introduce problems when
   explicit routing is used (see section 8). Indeed, explicit routing
   can construct a tree yielding another incoming interface than the
   RPF-compatible one.


4.6. 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 [DEER], PIM-SM [DEE2], MIP
   [PARS].

       +------------------+------+------+------+------+------+-----+
       |                  |DVMRP |MOSPF |CBT   |PIM-DM|PIM-SM|MIP  |
       +------------------+------+------+------+------+------+-----+
       |Flood & Prune     |yes   |yes   |no    |yes   |no    |no   |
       +------------------+------+------+------+------+------+-----+
       |Tree Type         |source|source|shared|source|both  |both |
       +------------------+------+------+------+------+------+-----+
       |Uni/Bi-directional|N/A   |N/A   |bi    |N/A   |uni   |both |
       +------------------+------+------+------+------+------+-----+
       |Loop Free         |no    |no    |no    |no    |no    |yes  |
       +------------------+------+------+------+------+------+-----+
       |RPF check         |yes   |yes   |no    |yes   |yes   |no   |
       +------------------+------+------+------+------+------+-----+

            Table 1. Taxonomy of IP Multicast Routing Protocols


   From Table 1 one can derive e.g. that DVMRP will consume a lot of L2
   resources 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



Ooms, et al.             Expires February 1999                  [Page 7]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   interpreted in the same way for the other protocols.


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.

   The granularity of the multicast streams will be (*, G) for the
   shared tree and (S, G) for a source tree, S being the source address
   and G the multicast group address.

   Whether the trigger by multicast routing messages is categorized as
   request or topology driven is debatable.  The constructed L2 tree
   will be identical to the one constructed by topology driven methods,
   but the definition of request driven [CALL] includes all label
   assignments in response to control traffic.  In [KATS] the multicast
   routing messages trigger is categorized as request driven, so we will
   continue using this convention.


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 4 illustrates these two
   cases.









Ooms, et al.             Expires February 1999                  [Page 8]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


           LSRu              LSRd      LSRu              LSRd
       -------+              +---      ---+              +-------
              |   control    |            |   control    |
       <---*<-----message-------      <-------message-------*----
           |  |              |            |              |  |
    trigger|  |              |            |              |  |trigger
           |  |    bind      |            |    bind      |  |
           +--------or--------->      <---------or----------+
              | bind-request |            | bind-request |
              |              |            |              |
              |              |            |              |
              |----data----->|            |-----data---->|

                  incoming                    outgoing

                     Figure 4. Request driven trigger
      (interception of resp. incoming and outgoing control messages)


   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 mode) or an LDP bind request (downstream on
   demand mode) to LSRd.

   Currently, 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



Ooms, et al.             Expires February 1999                  [Page 9]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   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:

   a) RSVP Resv messages can merge.

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

   More on RSVP in the sections on Piggy-backing (section 7) and QoS
   (section 9).


5.2. Topology driven

   The Multicast Routing Table (MRT) is maintained by the IP multicast
   routing protocol daemon (e.g. PIM/pimd, DVMRP/mrouted). 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.


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.



Ooms, et al.             Expires February 1999                 [Page 10]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   If the mixed L2/L3 forwarding capability (see section 6) is not
   supported, the traffic driven trigger requires an LDP mode in which
   the label is requested by the LSRu (downstream on demand or upstream
   mode).  In Figure 5, 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.

                                    +--------+
                                    |  LSRd1 |
                                    |        |
         +--------+                 |   L3   |
         |  LSRu  |                 +--------+
         |        |                 |        |
         |   L3   |    +-------------------------->
         +--------+   /             |   L2   |
         |        |  /              +--------+
     ->-------------+
         |   L2   |                 +--------+
         +--------+                 |  LSRd2 |
                                    |        |
                                    |   L3   |
                                    +--------+
                                    |        |
                                    |        |
                                    |   L2   |
                                    +--------+

               Figure 5. The LSRu has to request the label.


5.3.2. An implementation example

   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.




Ooms, et al.             Expires February 1999                 [Page 11]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   Entries in the MFC are removed when for a certain time no traffic is
   received anymore for this entry.  When label switching is applied to
   a certain MFC-entry, the L3 will not see any packets arriving
   anymore.  To obtain a normal MFC behavior the L3 counters of the MFC
   need to be updated by L2 measurements.


5.4. Combinations of triggers and LDP modes

   Table 2 shows the valid combinations of LDP modes and trigger types
   which 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 (section 6).

      +----------------+-------------------------------------------+
      |                |             label requested by            |
      |                |         LSRu        |         LSRd        |
      |                +---------------------+---------------------+
      |                | upstream |downstream|downstream| upstream |
      |                |          |on demand |          | 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 LDP modes


6. 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).









Ooms, et al.             Expires February 1999                 [Page 12]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


                  +--------+            +--------+
                  |   L3   |            |   L3   |
                  |  +>>+  |            |        |
                  |  |  |  |            |        |
                  +--|--|--+            +--------+
                  |  |  |  |            |        |
              ->-----+  +----->     ->------>>----->
                  |   L2   |            |   L2   |
                  +--------+            +--------+

              Figure 6. Unicast forwarding on resp. L3 or L2

            +--------+          +--------+         +--------+
            |   L3   |          |   L3   |         |   L3   |
            |  +>>++ |          |  +>>+  |         |        |
            |  |  || |          |  |  |  |         |        |
            +--|--||-+          +--|--|--+         +--------+
            |  |  |+---->       |  |  +----->      |      +---->
        ->-----+  |  |          |  |L2   |      ->----->>-+ |
            |   L2+----->   ->-----+>>------>      |   L2 +---->
            +--------+          +--------+         +--------+

       Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2


   Nodes which support this 'mixed L2/L3 forwarding' feature allow that
   a multicast tree splits in branches of 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 following
   advantages:











Ooms, et al.             Expires February 1999                 [Page 13]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   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

   b) Allows a return to L3 for branches which requested lower QoS
   (section 9).

   c) Enables the use of the traffic driven trigger with the LDP
   downstream or upstream on demand mode, as explained in section 5.4.


7. Piggy-backing

   In Figure 4 (outgoing case) one can observe that instead of sending 2
   separate messages the label advertisement can be piggy-backed on the
   existing control messages.  However, some disadvantages can be
   identified:

   a) Since label advertisement is only one of the three functions of
   LDP (the two others are discovery and adjacency), LDP is still
   required for e.g. label range negotiation.

   b) Suppose piggy-backing is applied on the multicast routing
   protocol. In order to support unicast label switching, either piggy-
   backing has also to be implemented on the unicast routing protocol or
   LDP must be used. In the latter case, one may question the benefit of
   piggy-backing on the multicast routing protocol.  As a result,
   piggy-backing introduces extra implementation effort.

   c) Piggy-backing assumes the LDP downstream mode, this excludes a



Ooms, et al.             Expires February 1999                 [Page 14]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   number of trigger methods (see Table 2).

   d) Piggy-backing changes the LDP paradigm: 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 will
   increase.

   e) If a VCID notification mechanism [NAGA] is required, the (in-band)
   notification can 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.

   For multicast two piggy-back candidates exist:

   a) Multicast routing messages: protocols 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 [DAVI].

   Piggy-backing is not incompatible with multicast, but one has to
   consider the disadvantages carefully.


8. Explicit routing

   Explicit routing is a powerful concept to control the multicast
   network topology. It provides network engineers with a tool which
   allows explicitly defined LSPs to be selected for multicast traffic.
   Such tools can be very useful for ISPs [UUNE] so that new IP
   multicast services  could be directed to particular links which are
   under traffic engineering control, unlike conventional dynamic IP
   routing.

   In case of explicit routing, (part of) the tree is calculated or
   configured by a single node and subsequently mapped on an LSP.

   If one central node would know all receivers, it can construct a more
   optimal tree (more optimal than a shortest-path-tree). However,
   maintaining the knowledge of all receivers introduces a lot of
   signaling towards this central node. This can be a bottleneck if



Ooms, et al.             Expires February 1999                 [Page 15]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   group membership is very dynamic.

   If routing is based on multiple constraints (instead of just hop-
   count), it can occur that two branches of the same tree cross a same
   node.

   An example of this is shown in Figure 9.  The two additive cost
   metrics associated with a certain link are represented by (c1,c2).
   Suppose two users A and B both require that sum(c1)<12 and sum(c2)<7.
   The only solution implies that the traffic from S is split in M1 and
   carried two times over the M2-M3 link.


                            (1,5)            A3---User A
                           A1-----A2        /
                          /        \       /(10,1)
                         /          +-----+
                  S-----M1          M2    M3
                         \          +-----+
                          \        /       \(1,5)
                           B1-----B2        \
                            (10,1)           B3---User B


           Figure 9. Two branches of a tree crossing a same node


   Such forwarding state cannot be represented by the usual (S,G) or
   (*,G) table lookup and RPF check. Only explicit routing can do this.

   Note that if an 'explicit routed' LSP for a certain part of the tree
   is established, one must make sure that the L3 forwarding engine of
   the LSRs at the end of the LSP is notified of the explicit path in
   order not to do an (incorrect) RPF check.

9. QoS/CoS

9.1. DiffServ

   The Differentiated Services approach can be applied to multicast as
   well.  It introduces finer stream granularities (Class of Service
   (CoS) as an extra differentiator).  A sender can construct one or
   more trees with different CoS bits.

   These (S, G, CoS) or (*, G, CoS) trees can be mapped very easily onto
   LSPs when the traffic driven trigger is used.  In this case one can
   create different LSPs for the different classes.  Note however that
   these LSPs still use the same route.  The situation becomes more



Ooms, et al.             Expires February 1999                 [Page 16]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   complicated when one wants to combine DiffServ with QoS Routing
   [NEVE].


9.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 ATM (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 (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 VC) the QoS multicast traffic has to be merged onto these
   default VCs.  This function can be provided by the 'mixed L2/L3
   forwarding' feature described in section 6.  If this is not available
   VC merging is necessary to avoid a return to L3 in the QoS LSP.

   The mapping of the IntServ service categories onto ATM service
   categories is studied in [GARR].


10. More issues

10.1. TTL

   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. Since the TTL value is
   not decremented in an LSP, 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 node.  This is impossible for multicast since all the
   branches of the tree can have different lengths.

10.2. Shared media




Ooms, et al.             Expires February 1999                 [Page 17]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   Multicast on shared media requires label space partitioning,
   otherwise the danger exists that two downstream LSRs will use the
   same label to subscribe to different multicast groups. A label space
   partitioning mechanism is described in [FAR2].


10.3. Local control vs. egress control

   In local control (also called independent mode [ANDE]) each LSR can
   take the initiative to set up a LSP.  In egress control (also called
   ordered mode [ANDE]) the LSP is set up on the initiative of the
   egress node.  All the previously described trigger methods (section
   5) combine with LDP local control.  In case of the request driven
   approach the label distribution in fact behaves as egress controlled:
   the control messages flow from the egress node upstream, imposing the
   same sequence to the label advertisement.  In case of piggy-backing
   the label advertisements themselves are flowing from the egress node
   upstream.


10.4. Conservative vs. optimistic

   The conservative mode ([DAVI]) only accepts an upstream label for a
   certain stream if it already has a downstream label for this stream.
   The optimistic mode always accepts the label.

   The conservative mode cannot be used in combination with 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 10 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. This is not possible at L2
   nor at L3 (since A does not support mixed L2/L3).


                                     N---N---R1
                                    /
                                   /
                           S -----A
                                   \
                                    \
                                     B---C---R2

                                Figure 10.





Ooms, et al.             Expires February 1999                 [Page 18]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


10.5. Conservative vs. liberal

   In the conservative mode ([ANDE]) only the labels that are required
   for forwarding data are allocated and maintained.  In the liberal
   mode labels are advertised and maintained to all neighbors. This mode
   does not scale in ATM due to the the limited VPI/VCI space.

   In some cases (see below) it is not known by an LSR to which neighbor
   it has to request a label. Therefore, it has to send the request to
   all its neighbors. In such case supporting the liberal mode requires
   no extra messages. However, it still requires extra state information
   and label space.

   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 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. As a result,
   multicast maps very naturally on the conservative mode.


10.6. Scalability

   Sparse mode multicast routing protocols (CBT, PIM-SM) are more
   scalable than dense mode protocols.  But even the sparse mode



Ooms, et al.             Expires February 1999                 [Page 19]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


   protocols introduce state in each node of the tree.  An enhancement
   to this is proposed in [TIAN].  In this proposal tunnels are created
   which span the non-branching nodes.  An appropriate trigger could map
   these tunnels to LSPs.


11. Security Considerations

   Security considerations are not discussed in this version of the
   document.


12. Acknowledgements

   The authors would like to thank 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.


References


[ANDE]  L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas,
        "Label Distribution Protocol", IETF Draft, draft-mpls-ldp-
        00.txt, March 1998.

[BALL]  A. Ballardie, "Core Based Trees (CBT, v2) Multicast Routing -
        Protocol Specification", IETF Draft, draft-ietf-idmr-cbt-spec-
        09.txt, 1997.

[CALL]  R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A.
        Viswanathan, "A Framework for Multiprotocol Label Switching",
        IETF Draft, draft-ietf-mpls-framework-02.txt, November 1997.

[CRAW]  E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden
        and J. Krawczyk, "A Framework for Integrated Services and RSVP
        over ATM", IETF Draft, draft-ietf-issll-atm-framework-04.txt,
        May 1998.

[DAVI]  B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G.
        Swallow and P. Doolan, "Use of Label Switching With ATM", IETF
        Draft, draft-davie-mpls-atm-00.txt, November 1997.

[DAV2]  B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan
        and S. Blake, "Use of Label Switching With RSVP", IETF Draft,
        draft-ietf-mpls-rsvp-00.txt, March 1998

[DEER]  S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S.



Ooms, et al.             Expires February 1999                 [Page 20]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


        Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        Specification", RFC 2117, June 1997.

[DEE2]  S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol
        Independent Multicast (PIM), Dense Mode Protocol: Specifica-
        tion", IETF Draft, 1994.

[FARI]  D. Farinacci and Y. Rekhter, "Multicast Tag Binding and Distri-
        bution using PIM", IETF Draft, draft-farinacci-multicast-tagsw-
        00.txt, December 1996.

[FAR2]  D. Farinacci and Y. Rekhter, "Partitioning Tag Space among Mul-
        ticast Routers on a Common Subnet", IETF Draft, draft-
        farinacci-multicast-tag-part-00.txt, December 1996.

[FENN]  W. Fenner, "Internet Group Management Protocol, IGMP, version
        2", RFC 2236, November 1997.

[GARR]  M. Garrett and M. Borden, "Interoperation of Controlled-Load
        Service and Guaranteed Service with ATM", IETF Draft, draft-
        ietf-issll-atm-mapping-06.txt, March 1998.

[KATS]  Y. Katsube, Y. Ohba and K. Nagami, "Two Modes of MPLS Explicit
        Label Distribution Protocol", IETF Draft, draft-katsube-mpls-
        two-ldp-00.txt, September 1997.

[MOY]   J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994.

[NAGA]  K. Nagami, N. Demizu, H. Esaki and P. Doolan, "VCID Notification
        over ATM link", IETF Draft, draft-ietf-mpls-vcid-atm-00.txt;
        March 1998.

[NEVE]  H. De Neve and P. Van Mieghem, "Hop-by-Hop Quality of Service
        Routing", submitted to INFOCOM '99.

[PUSA]  T. Pusateri, "Distance Vector Multicast Routing Protocol", IETF
        Draft, draft-ietf-idmr-dvmrp-v3-05, October 1997.

[PARS]  M. Parsa and J. Garcia-Luna-Aceves, "A protocol for scaleable
        loop-free multicast routing", IEEE JSAC, vol.15, no.3, p.316-
        331, April 1997

[PAXS]  V. Paxson, "End-to-End Routing Behavior in the Internet",
        IEEE/ACM Transactions on Networking 5(5), pp. 601-615.

[TIAN]  J. Tian, G. Neufeld, "Forwarding State Reduction for Sparse Mode
        Multicast Communication"



Ooms, et al.             Expires February 1999                 [Page 21]

Internet Draft      draft-ooms-mpls-multicast-00.txt         August 1998


[UUNE]  D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
        "Requirements for Traffic Engineering Over MPLS", , April 1998.

Authors Addresses

   Dirk Ooms
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-4732
   Fax   : 32-3-240-9932
   E-mail: oomsd@rc.bel.alcatel.be

   Wim Livens
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-7570
   E-mail: livensw@rc.bel.alcatel.be

   Bernard Sales
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-9574
   E-mail: salesb@btmaa.bel.alcatel.be

   Maria Fernanda Ramalho
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-9725
   E-mail: ramalhom@rc.bel.alcatel.be





















Ooms, et al.             Expires February 1999                 [Page 22]