Internet Draft
Network Working Group                                     Dino Farinacci
Internet Draft                                    Procket Networks, Inc.
Expiration Date: May 2001
                                                           Yakov Rekhter
                                                           Eric C. Rosen
                                                                Ted Qian
                                                     Cisco Systems, Inc.

                                                           November 2000


        Using PIM to Distribute MPLS Labels for Multicast Routes


                 draft-farinacci-mpls-multicast-03.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

   This document specifies a method of distributing MPLS labels [MPLS-
   ARCH, MPLS-MUL-FR] for multicast routes.

   The labels are distributed in the same PIM messages that are used to
   create the corresponding routes.  The method is media-type
   independent, and therefore works for multi-access/multicast capable
   LANs, point-to-point links, and NBMA networks.








Farinacci, et al.                                               [Page 1]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000




Table of Contents

    1          Overview  ...........................................   2
    2          Label Distribution for PIM-SM  ......................   3
    2.1        Piggybacking Labels with Multicast Routes  ..........   3
    2.2        LANs with Multiple Downstream Nodes  ................   5
    2.2.1      Partitioning the Label Space  .......................   5
    2.2.1.1    Partitioning Procedure  .............................   5
    2.2.1.2    Effect of Partition in Layer 2 Topology  ............   6
    2.2.1.3    Effect of Exceeding the Label Range  ................   7
    2.2.2      Assigning the Labels  ...............................   7
    2.3        Labels for Point-to-Point Links  ....................   8
    2.4        Labels for NBMA Networks  ...........................   8
    2.5        When NOT to Send a Labelled Multicast Packet  .......   9
    2.6        No Conflict between Unicast and Multicast Labels  ...   9
    2.7        Supporting Bidirectional PIM  .......................   9
    2.8        ATM-LSRs without Multipoint-to-Multipoint  ..........  10
    2.8.1      Label Request/Binding  ..............................  10
    2.8.2      Steady State Maintenance  ...........................  11
    2.8.3      Label Distribution and LSP Control  .................  12
    3          Modifications to PIMv2  .............................  12
    3.1        Join/Prune Packets  .................................  12
    3.2        Hello Packets  ......................................  13
    4          Label Distribution for PIM-DM  ......................  15
    5          Security Considerations  ............................  16
    6          Acknowledgments  ....................................  16
    7          References  .........................................  17




1. Overview

   PIM [PIMv1, PIMv2] is used to combine MPLS label distribution with
   the distribution of (*,G) join state, (S,G) join state, or (S,G)RPT-
   bit prune state. Labels and multicast routes are sent together in one
   message.

   This design has the following goals:

     o If an interface attaches to a network with data-link broadcast
       capability, an LSR should never have to send more than one copy
       of a given multicast data packet out that interface.  However, it
       is NOT a goal for that LSR to be able to send the same packet,
       with the same label, out multiple interfaces.




Farinacci, et al.                                               [Page 2]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


     o When an interface supports data link multicasting, it must be
       possible for the receiver of a labeled packet to interpret the
       label without knowing who the transmitter is.

     o When a LAN contains multiple label distribution peers, it should
       be possible to use data link multicast to distribute the label
       distribution control packets themselves.  Other aspects of label
       distribution methodology should remain as consistent with unicast
       label distribution as possible.

     o Multicast label distribution procedures should not depend on the
       media type.  (However, it has been necessary to compromise this
       goal in the case of ATM-LSRs which do not have multipoint-to-
       multipoint capability, see section 2.8.)

     o Once the label for a particular multicast tree on a given LAN has
       been assigned, unicast routing changes should not cause
       redistribution or reassignment of the label for that group on
       that LAN.

     o When a multicast routing table change requires a label
       distribution change, the latency between the two should be
       minimized, both to improve performance and to minimize the
       possibility of race conditions.

     o The procedures should work with either dense-mode or sparse mode
       operation.


2. Label Distribution for PIM-SM

2.1. Piggybacking Labels with Multicast Routes

   An LSR that supports multicast sends PIM Join/Prune messages on
   behalf of hosts that join groups. It sends Join/Prune messages to
   upstream neighboring LSRs toward the RP for the shared-tree (*,G) or
   toward a source for a source-tree (S,G).  Labels are distributed by
   being associated with addresses in the join list or the prune list.
   In particular:

      1. If an LSR Rd, joins the shared tree for a group, the Join/Prune
         message it sends upstream will contain the group address
         followed by a join-list.  The join-list will contain an element
         which contains the address of the RP.  This element will also
         contain a a label, and this label can be used by the upstream
         LSR Ru, when it sends multicast data down the shared tree.
         Intuitively, this label represents the route downstream from
         the current node along the shared tree.



Farinacci, et al.                                               [Page 3]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


         Note that if Rd joins the shared tree for group G, but Ru
         happens to have (S,G) state for some S, then Ru must merge its
         (*,G) output interface list into its (S,G) output interface
         list.  This is necessary in order to ensure that Rd will
         receive packets sent from S to G, even though Ru only gets
         these packets on the source tree.  In this case, when Ru
         receives an (S,G) packet, it should forward it to Rd using the
         same label that Rd assigned for (*,G) packets, EXCEPT IN THE
         CASE where Ru is an ATM-LSR which does not support multipoint-
         to-multipoint connections(see section 2.8).

      2. If an LSR Rd, joins a source tree for a group, the Join/Prune
         message it sends upstream will contain the group address
         followed by a join-list.  The join-list will contain an element
         which contains the address of the source.  This element will
         also contain a label, and this label can be used by the
         upstream LSR Ru, when it sends multicast data down the source
         tree.  Intuitively, this label represents the route downstream
         from the current node along the specified source tree.

      3. Suppose an LSR Rd, has (S,G)RPT-bit state with a null output
         interface list.  This indicates that all of its downstream
         neighbors on the shared tree for G have pruned source S from
         the shared tree.  Rd sends a Join/Prune message upstream (on
         the shared tree), containing the group address followed by a
         prune-list.  The prune-list contains an element which contains
         the address of the source.  In this case, no label is included
         in the element.

         Similarly, if an LSR has (S,G)SPT-bit state, and also has (*,G)
         state with a non-null output interface list, and the input
         interface for (*,G) is different than the input interface for
         (S,G), it will send a Join/Prune message upstream on the shared
         tree, with S in the prune-list, and will not include a label.

      4. Suppose an LSR Rd, as the result of receiving, from a
         downstream neighbor on the shared tree, a Join/Prune message
         such as described in 3, creates (S,G)RPT-bit state with a non-
         null output interface list.  In this case, it may send a
         Join/Prune message upstream on the shared tree, containing the
         group address followed by a prune-list.  An element of the
         prune list will contain the address S and a corresponding
         label.  However, a special bit (the "Label Only" bit, or "L-
         bit") in the element will be set indicating to the upstream LSR
         that the source S is not really to be pruned from the shared
         tree.  The result is that the upstream LSR Ru, will still send
         packets from S to G to Rd, and will label those packets as
         specified.  When Rd receives such packets, it forwards them



Farinacci, et al.                                               [Page 4]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


         according to the output interface list of the (S,G)RPT-bit
         entry.  Intuitively, this label represents a route along the
         shared tree, but only for packets from the specified source.

      5. An LSR which receives a Join/Prune message as described in 4
         may send a corresponding Join/Prune message (with the L-bit
         set) to its upstream LSR on the shared tree. Again, this label
         represents a route along the shared tree, but only for packets
         from the specified source.

   Rules 3-5 above ensure that if a source is pruned off the shared tree
   at some point, any packets from that source which is sent down the
   shared tree will have a label that implicitly identifies the source.
   Thus if those packets encounter a node with (S,G)RPT-bit state, they
   will be sent according to the output interface list of the (S,G)RPT-
   bit entry, NOT according to the output interface list of the (*,G)
   entry.


2.2. LANs with Multiple Downstream Nodes

2.2.1. Partitioning the Label Space

   Only one copy of a given multicast data packet is sent downstream.
   On a LAN, this packet will be received by all the LSRs on the LAN.
   The label it carries is used, by the receiving LSRs, to find the
   packet's multicast distribution tree.  The label it carries must have
   a unique association, on that LAN, with a multicast distribution
   tree.

   Therefore, once an LSR assigns a label to a particular multicast
   distribution tree on a particular LAN, all other LSRs on that LAN are
   prohibited from making any other use of that label.  The prohibition
   remains in effect as long as the distribution tree in question
   exists.

   In order to meet this requirement, the LSRs on a LAN must divide up
   the label space, such that each LSR has a particular unique range of
   labels which it may distribute.


2.2.1.1. Partitioning Procedure

   Each multicast LSR on a LAN is configured with the total number of
   labels (N) that may be used to represent multicast distribution trees
   on the LAN.  It is also configured with an approximate count (R) of
   the routers on the LAN.  The router divides the multicast label space
   into a number of equal-sized ranges, where the size of a range is



Farinacci, et al.                                               [Page 5]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   T/R.  Each router will randomly select one of these ranges.

   When a multicast LSR boots up or enables the LAN interface to do
   multicast routing, it will advertise in PIM Hello messages the total
   number of multicast labels, the router count, and the label range it
   randomly selects. The lower range label value and the higher range
   label value accompany the advertisement.

   If the total number of multicast labels for the LAN is not configured
   consistently on all LSRs connected to a LAN, the smallest number
   advertised by any LSR will be used.

   If the router count is not configured consistently on all LSRs
   connected to a LAN, the smallest router count value advertised by any
   LSR will be used.

   If there is another LSR that has selected the same range, then the
   following procedures are used to determine which of the two LSRs
   would be able to keep its range, and which would be required to
   allocate another label range.  If DR election priority is included in
   the Hello messages at both LSRs, and the priority values are not
   equal, then the LSR with the lower DR election priority is required
   to allocate another label range. Otherwise, the LSR with the lower IP
   address on the LAN is required to allocate another label range. In
   both cases the label range is allocated randomly. If as a result of
   these procedures a LSR has to allocate another label range, then the
   LSR has to withdraw its label bindings from its currently allocated
   range, and then (after it allocates another range) reallocate its
   bindings.

   A LSR can be configured to use more than one label range if one
   believes it will be an upstream LSR for many flows. It just inserts
   additional advertisements in the same PIM Hello message. The label
   table size and router-count should be the same in all advertisements
   contained in a message.


2.2.1.2. Effect of Partition in Layer 2 Topology

   When a subnet partitions (due to, say, the failure of a layer 2
   switch) and new multicast LSRs come up, they will allocate label
   ranges that are unique to their partition. When the partition heals,
   there may be conflicts. Once the PIM Hellos messages are received by
   LSRs on the other side of the partition, they will determine there is
   a label range allocation conflict and immediately perform the tie
   breaking rules described above.





Farinacci, et al.                                               [Page 6]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


2.2.1.3. Effect of Exceeding the Label Range

   When a LSR cannot allocate a label range because all ranges within
   the label table size have been allocated, it will not participate in
   binding labels to multicast routes. Packets for these routes will not
   be label switched.  However, the LSR is still capable of label
   switching a packet as either an upstream or downstream LSR on that
   LAN. This is the case when another router is binding labels for the
   multicast route and has an allocated a label range successfully.


2.2.2. Assigning the Labels

   Since PIM Join/Prune messages are multicast on a LAN, other
   downstream LSRs that are interested in the group will hear the
   message.  They must cache the binding of multicast routing table
   state and label state together. Since the upstream LSR is going to
   forward data packets using the advertised label, they must be ready
   to accept the data packet with that advertised label.

   The first downstream LSR that joins a group is the label assigner on
   that LAN for that multicast route. All other downstream LSRs that
   send PIM Join/Prune messages will use the same label that the
   assigner selected. A LSR that sends a PIM Join/Prune message with a
   label of 0 means that it doesn't know the label for the associated
   multicast routing table entry. When this occurs, the assigner can
   trigger a PIM Join/Prune message making the label known.

   When the label assigner leaves the group, the label that it assigned
   still remains active. The next highest IP addressed downstream LSR
   becomes the owner of that label and may change it if it sees fit.
   However, it is not required to change it. All downstream LSRs can
   continue to use the assignment in their Join messages.

   If two systems simultaneously join a distribution tree for the first
   time (they do not have state for that tree), and each chooses a
   different label value, the highest IP addressed downstream LSR's
   label will be used by the upstream LSR. The lower addressed LSR will
   hear the higher addressed LSR's Join too and will also use it's
   label.

   If the label assigner crashes, the highest IP addressed downstream
   LSR assigns a new label to the multicast routes, which were assigned
   by the crashing LSR, and triggers a Join message so all other LSRs on
   the LAN to use the new label.

   When a LAN partitions due to a layer-2 switch failure, it follows the
   same logic for the case when a LSR stops joining for a group. When



Farinacci, et al.                                               [Page 7]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   the partition heals, there may be an RPF neighbor change in one of
   the partitions.  When there is an RPF neighbor change and the
   downstream routers trigger joins to their new RPF neighbor with a
   different label assignment than the other partition is using, one of
   two resolutions occur:

      1) The LSR which is the allocator in the partition of the new RPF
         neighbor will trigger a join if it has a higher IP address than
         the allocator in the other region. The downstream routers in
         the other partition use the new label assignment immediately.

      2) If the LSR which is the allocator in the partition of the new
         RPF neighbor has a lower IP address, all downstream routers and
         the new RPF neighbor will switch to the label assigned by the
         allocator in the other partition.

   If an RPF change occurs (the topology changed so the upstream LSR is
   different), the PIM protocol spec indicates that a PIM Join may be
   triggered to get on the new distribution tree as soon as possible. In
   this case, if the label assigner becomes the upstream LSR, then the
   new highest IP addressed downstream LSR may become the label
   assigner. It may change the label if it sees fit. Otherwise, the same
   label is used.


2.3. Labels for Point-to-Point Links

   The procedure of section 2.2 works on point-to-point links because
   there is only one downstream LSR on the link which always becomes the
   label assigner.


2.4. Labels for NBMA Networks

   On NBMA networks, all PIM routers are known to each other through
   pseudo-broadcast mechanisms provided by the data-link layer. However,
   PIM Join messages are unicast to the upstream LSR. Therefore, other
   downstream LSRs will not hear the label assigner's advertisement.
   Therefore we treat an NBMA network with one upstream and n downstream
   LSRs as n point-to-point links, from the upstream LSR to each of the
   downstream LSRs.  Each downstream LSR then assigns its own label, and
   the upstream LSR must replicate the multicast data packets.
   Therefore the procedure of section 2.2 applies.

   Note that this is not incompatible with the use of native point-to-
   multipoint capabilities at the data link layer.





Farinacci, et al.                                               [Page 8]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


2.5. When NOT to Send a Labelled Multicast Packet

   PIM Hello messages, sent periodically by all PIM-capable routers,
   will indicate if the router is MPLS-capable.  An upstream router on a
   LAN will therefore know if all routers on the same LAN are LSRs or
   not.  If there are ANY MPLS-incapable routers which are interested in
   a particular group, the upstream router will transmit to the LAN only
   unlabelled multicast data packets for that group.

   If there are any group members on a LAN, only unlabelled multicast
   data for that group will be transmitted onto that LAN.

   Routers that support non-PIM multicast are assumed, for the purposes
   of this procedure, to be MPLS-incapable.


2.6. No Conflict between Unicast and Multicast Labels

   Frame based MPLS uses different data-link layer code-points [MPLS-
   ENCAPS] to distinguish multicast labeled packets from unicast labeled
   packets.  Therefore, the assignment of labels for unicast routes is
   completely independent from the assignment of labels for multicast
   routes.  For example, the same label value could be allocated for a
   unicast route and for a multicast route, without any possibility of
   ambiguity.

   MPLS on a label switching controlled ATM (LC-ATM) interface uses
   VPI/VCI as the top label [MPLS-ATM].  There is no VPI/VCI range
   specifically reserved for multicast or for unicast.

2.7. Supporting Bidirectional PIM

   We consider support of Bidirectional PIM [PIM-BIDIR] only in LSRs
   which are not ATM-LSRs.  In the absence of an ATM multipoint-to-
   multipoint capability, bidirectional PIM over ATM will not have the
   favorable scaling properties that make it interesting.

   On links which are not sender-only links, support for Bidirectional
   PIM is straightforward.  Labels are assigned in the usual manner by
   downstream LSRs.  However, a label can be used in either direction
   (i.e., can be carried by packets traveling either upstream or
   downstream).  On a given link, the label is bound to the same
   multicast route (*,G) or (S,G) in both directions.   As long as the
   procedures of section 2.2 are always used to partition the label
   space (even on point-to-point links), it is possible to use the same
   label in both directions.

   Sender-only links present a bit more of a difficulty since PIM



Farinacci, et al.                                               [Page 9]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   Join/Prune messages are not generally sent on those links.  In order
   to assign labels to these links, a downstream node on a sender only
   link should send a PIM Join message, as if it were going to join the
   tree, but should set the newly defined "label only" bit (L-bit).  In
   essence, these nodes will contain (*,G) state, and will associate the
   (*,G) state with a label that is distributed upstream.  However,
   there will be no output interface list associated with the (*,G)
   state, and packets will just be forwarded towards the RP.


2.8. ATM-LSRs without Multipoint-to-Multipoint

   Multipoint-to-multipoint capability is a feature of an ATM switch
   that allows an outgoing VC to appear in one or more cross-connect
   (e.g., two incoming VCs cross-connecting to the the same set of
   outgoing VCs) without causing cell interleaving. The procedure
   described in this section applies to ATM-LSRs that do NOT have
   multipoint-to-multipoint capability.


2.8.1. Label Request/Binding

   When LSR Ru receives an (S,G) join from LSR Rd, Ru, which did not
   have the (S,G) state, must create the (S,G) state and populate it
   with the oifs from (*,G). When LSR Ru receives an (*,G) join from LSR
   Rd, if the (S,G) state already exists on Ru, the oif must be added to
   the (S,G)'s oif list as well.

   At LSR Ru, for each oif that is copied from a (*,G) to an (S,G), the
   associated label/VCI is not replicated. Instead, the oif moves into a
   Label Needed state, and an (S,G) L-bit Join/Request is sent out of
   the interface to the Rd. The Encoded-Unicast-Upstream Neighbor
   Address field in such Join is set to the address of Rd. Source
   address in the join list employs the Label Address encoding with the
   next t-bit (section 3.1) in the label field set and the L-bit set.
   Since this is a source specific Join Request along the shared tree,
   the R bit is set and W bit is clear. In addition, the current
   multicast route timer (section 3.1) is set to the time remaining on
   the (S,G) Entry-Timer at Ru. Rd, upon receiving such Join, fills in
   the label field with the next t-bit cleared, and then sends the (S,G)
   L-bit R-bit Join/Binding back out of the RPF interface toward the RP.
   (S,G) L-bit Join/Request received from non-RPF interface towards RP
   must be discarded. At Ru, the incoming label for (S,G) is then
   cross-connected with labels in the (S,G) L-bit R-bit join received
   from Rd.

   LSR Rd, that receives an (S,G) L-bit R-bit Join/Request via the RPF
   towards the RP, must create an (S,G) L-bit state if it doesn't



Farinacci, et al.                                              [Page 10]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   already exist, and must initializes the (S,G)'s Entry-Timer with the
   the current multicast route timer encoded in the source address. If
   Rd is capable of multipoint-to-multipoint connection, label
   replication follows the procedure described in section 2.1.
   Otherwise, it follows the procedure described in this section.

   The L-bit on an (S,G) indicates that the state is created by an (S,G)
   L-bit R-bit Join/Request, and periodic Joins that it sends must have
   the L-bit set.


2.8.2. Steady State Maintenance

   An (S,G) entry is removed upon expiration of its Entry-Timer. The
   timer may be updated upon receiving an (S,G) L-bit R-bit Join/Request
   from the RPF interface towards the RP. If the "Current Multicast
   Route Timer" is greater than the remaining timer value of the Entry-
   Timer, the timer value is increased to the "Current Multicast Route
   Timer" specified in the L-bit R-bit Join/Request. The time may also
   be updated by other event such as receiving (S,G) Join from any
   downstream oif peers. Note, (S,G) L-bit Join from downstream oif
   doesn't reset the Entry-Timer.

   In the event that an upstream router no longer needs a (S,G) label
   from its downstream peer (e.g., switching back to a share tree), the
   (S,G) state eventually expires since the (S,G) Entry-Timer is NOT
   updated by the receipt of L-bit Join/Bindings.  It simply stops
   sending periodic L-bit R-bit Join/Request out of that oif upon
   expiration of the (S,G) state. This eventually causes the (S,G)'s
   Entry-Timer to expire in the downstream router and the state removal.

   Sending a (S,G) L-bit R-bit Join/Request out of an oif is triggered
   by the receipt of a (*,G) Join from the same oif. For each (S,G) that
   exists, an (S,G) L-bit R-bit Join/Request is sent down the oif in a
   Label Needed state. Regular (S,G) Join received with the L-bit
   cleared removes the Label Needed state on the oif, and also clears
   the L-bit state on the (S,G) entry. Joins triggered by the expiration
   of the Join Timer on such (S,G)contain cleared L-bit. This mechanism
   accommodates the situation where an upstream LSR that needs a label
   and a downstream DR receiver which decides that traffic exceeds the
   threshold both initiate the source tree, and part of the shared and
   source tree overlaps.









Farinacci, et al.                                              [Page 11]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


2.8.3. Label Distribution and LSP Control

   The procedures of section 2.8 use MPLS Downstream on Demand
   procedures with Independent LSP control [MPLS-ARCH].

   The Downstream on Demand procedures are needed whenever two incoming
   VCs corresponding to the same FEC cannot be merged into a single
   outgoing VC.  In the absence of multipoint-to-multipoint capability,
   this applies to multicast distribution trees.

   Independent LSP control is needed so that different downstream
   branches of a multicast distribution tree can join the tree
   independently.  The fact that one particular downstream branch of the
   tree is slow to respond to the control messages does not then prevent
   or even delay other more responsive downstream branches from joining
   the tree.


3. Modifications to PIMv2

3.1. Join/Prune Packets

   PIMv2 has a packet format for each address type it may support when
   encoding both multicast and unicast addresses. We will define a new
   address type called "Label Address" for unicast address encoding.
   The label will accompany the source address in the Encoded Source
   Address format as specified in [PIMv2].  The label value will be in a
   32-bit quantity following the source address. We also take one bit
   from the PIMv2 reserved field to be the "label only" bit (shown below
   as the "L-bit").  So, for example, an IPv4 Label Address format would
   look like:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsrvd |L|S|W|R|   Mask Len    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |a|t|                        Label                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Current Multicast Route Timer                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Label
      If the a-bit is clear, the low-order 20 bits are a label value (as



Farinacci, et al.                                              [Page 12]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


      described in [MPLS-ATM]) assigned by the LSR sending the
      Join/Prune message.  All other bits should be set to 0 by the
      sender and should be ignored by the receiver.

      If the a-bit is set, the low-order 28 bits are a label value in
      the VPI/VCI format of (as described in [MPLS-ATM]) assigned by the
      LSR sending the Join/Prune message.  If the t-bit is set, the
      VPI/VCI label value should be ignored by the receiver since this
      represents a label request by an ATM-LSR. All other bits should be
      set to 0 by the sender and should be ignored by the receiver.

   Current Multicast Route Timer
      The sender of a Join/Prune message inserts the current time left
      before expiration for the multicast route table entry described by
      the Source Address (either the (S,G) or (*,G) entry). This is
      needed so all routers on a common multi-access subnet can time-out
      the entry close to the same time without each other recreating the
      state when the source goes inactive.

   Refer to [PIMv2] for other field descriptions not specified here.




3.2. Hello Packets

   The PIM Hello message will carry 2 new OptionTypes (called "Label
   Parameters" and "VCI Capability") as specified in [PIMv2]. A router
   that sends a PIM Hello with the Label Parameters option is regarded
   as being label-capable. This Option can appear multiple times in a
   Hello packet if a LSR wants to allocate multiple ranges. When this
   option appears multiple times in the Hello message, the Label Table
   Size and Router Count must be the same for each Label Parameters
   Option supplied in the message.

   When sent on point-to-point links, this option should have Router
   Count, Lower Label Range, and Upper Label Range set to 0. These
   fields are ignored on receipt.

   When sent on LC-ATM links, the first Label Parameter option carries
   the VPI range and the second one carries the VCI range.










Farinacci, et al.                                              [Page 13]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   Label Parameters TLV

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OptionType = 17          |      OptionLength = 16        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Total Number of Multicast Labels for this LAN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router Count                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Lower Label Range                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Upper Label Range                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OptionType "Label Parameters"
      Set to value 17 decimal.

   OptionLength
      The option is 16 bytes in length.

   Total Number of Multicast Labels
      The total number of multicast labels the sending router can
      support on the interface the Hello is sent on.

   Router Count
      The approximate maximum number of routers that may be connected to
      the subnet the Hello is sent on.

   Lower Label Range
      The lower label value in the label range. This value, randomly
      selected by the sending router in the case of non LC-ATM link or
      supplied by the ATM driver in the case of LC-ATM link, must be
      less than the Upper Label Range value.

   Upper Label Range
      The upper label value in the label range. This value, randomly
      selected by the sending router in the case of non LC-ATM link or
      supplied by the ATM driver in the case of LC-ATM link, must be
      greater than the Lower Label Range value.










Farinacci, et al.                                              [Page 14]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   VCI Capability TLV

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OptionType = 23          |      OptionLength = 5         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Priority                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved   |D|
   +-+-+-+-+-+-+-+-+


   OptionType "VCI Capability"
      Set to value 23 decimal.

   OptionLength
      The option is 5 bytes in length.

   Priority
      Peering ATM-LSRs exchange the priority value for VC space odd-even
      determination when at least one side supports unidirectional VC.
      An ATM-LSR with a higher priority value may assign only odd-
      numbered VC and ATM-LSR with a lower priority value may assign
      even-numbered VC.  The value should be ignored if the LC-ATM link
      is bidirectional.

   D Bit
      When the D bit is clear, VCI capability is bidirectional. When it
      is set, VCI capability is unidirectional. Bidirectional capability
      indicates an ATM-LSR issuing this option can, within a single VPI,
      support binding of the same VCI to different routes on the
      different directions of the link. Unidirectional capability
      indicates an ATM-LSR issuing this option can, within a single VPI,
      a single VCI may appear in one binding only. In such systems when
      a VCI has been bound in one direction on the link it may not be
      used in the other.


4. Label Distribution for PIM-DM

   In dense-mode PIM, there is no downstream Join message traveling
   upstream to perform the binding of multicast routes with labels.
   However, since we don't want a separate algorithm for dense-mode
   groups, we extend this basic design for dense-mode PIM.

   When a downstream LSR creates (S,G) state from the receipt of 1)
   data, or 2) Join/Prune or Graft messages, it will start a periodic



Farinacci, et al.                                              [Page 15]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000


   timer to send Join messages with label assignment information
   present. The messages look no different and are treated on receipt no
   differently than in the sparse-mode case.

   The periodic Join message will be multicast on the LAN with an
   upstream target address of 0.0.0.0. All multicast LSRs on the LAN
   must know the group operates in dense-mode. This is accomplished
   using standard PIM mechanisms.


5. Security Considerations

   The security considerations for MPLS in general and label
   distribution in particular are discussed in [MPLS-ARCH] and [LDP]
   respectively.  Security considerations for PIM are discussed in
   [PIMv2].

   The use of IPSEC for securing the PIM messages, as suggested in
   [PIMv2], provides adequate security for this application.


6. Acknowledgments

   The authors would like to thank Yiqun Cai for his overall help on
   this draft.  We thank Fred Baker for his comments on an earlier
   version.  We also thank the authors of [MPLS-MUL-FR] for their
   critique of an earlier version.

   9.0 Author's Addresses


      Dino Farinacci
      Procket Networks, Inc.
      3850 North First Street
      San Jose, CA 95134
      Email: dino@procket.com



      Yakov Rekhter
      Cisco Systems, Inc.
      170 Tasman Drive
      San Jose, CA, 95134
      Email: yakov@cisco.com







Farinacci, et al.                                              [Page 16]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000



      Eric C. Rosen
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA, 01824
      Email: erosen@cisco.com



      Ted Qian
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA, 01824
      Email: tqian@cisco.com



7. References

   [LDP] "LDP Specification", draft-ietf-mpls-ldp-7.txt, Andersson,
   Doolan, Feldman, Fredette, Thomas, June 2000.

   [MPLS-ARCH] "Multiprotocol Label Switching Architecture", draft-
   ietf-mpls-arch-06.txt, Rosen, Viswanathan, Callon, August 1999.

   [PIMv1] "Protocol Independent Multicast-Sparse Mode (PIM-SM):
   Protocol" Specification", RFC 2362, Estrin, Farinacci, Helmy, Thaler,
   Deering, Handley, Jacobson, Liu, Sharma, Wei, June 1998.

   [PIMv2] "Protocol Independent Multicast-Sparse Mode (PIM-SM):
   Protocol Specification", draft-ietf-pim-v2-sm-01.txt, Wei, et. al.,
   November, 1999.

   [PIM-BIDIR] "Bi-directional Protocol Independent Multicast", , Handley, Kouvelas, and Vicisano, March 2000.

   [MPLS-ENCAPS] "MPLS Label Stack Encoding", , Rosen, Rekhter, Farinacci, Tappan, Fedorkow, Li,
   Conta, September 1999.

   [MPLS-MUL-FR] "Framework for IP Multicast in MPLS", , Ooms, Sales, Livens, Acharya, Griffoul,
   Ansari, May 2000.

   [MPLS-ATM] "MPLS using LDP and ATM VC Switching", , Davie, Lawrence, McCloghrie, Rekhter, Rosen, Swallow,
   Doolan, June 2000.




Farinacci, et al.                                              [Page 17]


Internet Draft   draft-farinacci-mpls-multicast-03.txt     November 2000





















































Farinacci, et al.                                              [Page 18]