[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                              R. Li
Internet-Draft                                                   Q. Zhao
Intended status: Standards Track                     Huawei Technologies
Expires: August 30, 2012                                    C. Jacquenet
                                                          France Telecom
                                                           March 4,  2012


   Receiver-Driven Multicast Traffic Engineered Label Switched Paths
          draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00.txt

Abstract

   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven Traffic
   Engineered(TE) point-to-multipoint (P2MP) and multipoint-to-multipoint
   (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS)
   and Generalized MPLS (GMPLS)networks.


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 30, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Li, et al.               Expires August 30, 2012                [Page 1]


Internet-Draft            RD Multicast RSVP-TE             February 2012


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.




































Li, et al.               Expires August 30, 2012                [Page 2]


Internet-Draft            RD Multicast RSVP-TE             February 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Receiver-Driven mRSVP-TE LSP Exampls . . . . . . . . . . .  8
   2.  Signaling Protocol Extensions  . . . . . . . . . . . . . . . . 10
     2.1.  L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . . . 11
     2.2.  Explicit Routing . . . . . . . . . . . . . . . . . . . . . 12
     2.3.  L2S Sub-LSPs and Path Messages . . . . . . . . . . . . . . 12
     2.4.  Resv Message Extensions  . . . . . . . . . . . . . . . . . 13
     2.5.  PathErr Message Extensions . . . . . . . . . . . . . . . . 14
     2.6.  ResvErr Message Extensions . . . . . . . . . . . . . . . . 14
     2.7.  PathTear Message Extensions  . . . . . . . . . . . . . . . 14
     2.8.  SESSION Object . . . . . . . . . . . . . . . . . . . . . . 15
       2.8.1.  mRSVP-TE LSP Tunnel IPv4 SESSION Object  . . . . . . . 16
       2.8.2.  mRSVP-TE LSP Tunnel IPv6 SESSION Object  . . . . . . . 16
     2.9.  SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 17
       2.9.1.  mRSVP-TE LSP Tunnel IPv4 SENDER_TEMPLATE Object  . . . 17
       2.9.2.  mRSVP-TE LSP Tunnel IPv6 SENDER_TEMPLATE Object  . . . 17
     2.10. L2S_SUB_LSP Object . . . . . . . . . . . . . . . . . . . . 18
       2.10.1. L2S_SUB_LSP IPv4 Object  . . . . . . . . . . . . . . . 18
       2.10.2. L2S_SUB_LSP IPv6 Object  . . . . . . . . . . . . . . . 19
     2.11. FILTER_SPEC Object . . . . . . . . . . . . . . . . . . . . 19
       2.11.1. P2MP LSP_IPv4 FILTER_SPEC Object . . . . . . . . . . . 19
       2.11.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Object . . . . . . . . . 19
       2.11.3. mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO)  . . . 20
       2.11.4. mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO)  . . . . 20
   3.  In-Band and Out-Band Signalling  . . . . . . . . . . . . . . . 20
     3.1.  In-Band Signalling . . . . . . . . . . . . . . . . . . . . 20
     3.2.  Out-Band Signalling  . . . . . . . . . . . . . . . . . . . 20
   4.  Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . 21
   5.  Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 21
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24









Li, et al.               Expires August 30, 2012                [Page 3]


Internet-Draft            RD Multicast RSVP-TE             February 2012


1.  Introduction

   Multiparty multimedia applications are getting greater attention in
   the telecom world.  Such applications are QoS-demanding and can
   therefore benefit from the activation of MPLS traffic engineering
   capabilities that lead to the dynamic computation and establishment
   of MPLS LSPs whose characteristics comply with application-specific
   QoS requirements.  P2MP-TE [RFC4875] defines a procedure to set up
   point-to-multipoint LSPs from sender to receivers.  This document
   extends RSVP-TE for the dynamic computation of receiver-driven P2MP
   and MP2MP LSP tree structures.


1.1.  Motivation

   IP multicast distribution trees are receiver-initiated and dynamic
   by nature.  IP multicast-enabled applications are also bandwidth savvy,
   especially in the area of residential IPTV services, where the delivery
   of multicast contents to several hundreds of thousands of IPTV receivers
   assumes the appropriate level of quality.  Current source-driven P2MP
   LSP establishment, as defined as in [RFC4875], assumes a priori knowledge
   of receiver locations, and the LSP signalling is initiated and driven by
   the data sender(headend).

   Receiver-driven MPLS P2MP/MP2MP tree structures do not require sender
   to maintain/discover receiver information a priori, and their design
   should better accommodate the receiver-specific QoS conditions, such as
   network access capabilities.



1.2.  Terminology

   The following terms are used in this document:


   o  Sender: Sender refers to the Originator (and hence) Sender of the
      content/payload, as defined in [RFC2205].

   o  Receiver: Receiver refers to the Receiver of the content/payload,
      as defined in [RFC2205].

   o  Upstream: The direction of flow from content Receiver toward
      content Sender, as defined in [RFC2205].

   o  Downstream: The direction of flow from content Sender toward
      content Receiver, as defined in [RFC2205].




Li, et al.               Expires August 30, 2012                [Page 4]


Internet-Draft            RD Multicast RSVP-TE             February 2012


   o  Path-Sender: The sender of RSVP PATH messages, with NO correlation
      to the direction of content/payload flows.  Its flow direction is
      irrelevant to that of Sender defined above.  All other control
      messages discussed in this document will use this as the
      reference.

   o  Path-Receiver: The receiver of RSVP PATH messages, with NO
      correlation to the direction of content/payload flows.

   o  Path-Initiator: The Path-Sender that originated a RSVP PATH
      message.  This is different from Path-Sender in that an
      intermediate node can be a Path-Sender, but such an intermediate
      node cannot create and initiate the RSVP PATH message.

   o  Path-Terminator: The Path-Receiver that does NOT propagate the
      Path message any further.  This is different from Path-Receiver in
      that an intermediate node can be a Path-Receiver, but such an
      intermediate node will propagate the Path message to the next hop.

   o  Root: A router where a multcast LSP is rooted at.  Data enters the
      root and then is distributed to leaves along the P2MP/MP2MP LSP

1.3.  Overview

   Although receiver-driven P2MP LSPs as defined in this document use
   existing sender-driven syntax, there are important semantic
   differences that need to be defined for correct interpretation and
   interoperability.  In the receiver-driven approach, we inverted the
   semantics of P2MP-TE RSVP [RFC4875] messages, while keeping the
   syntax unchanged.

   Following are some key differences that are specific to the receiver-
   driven paradigm:

   o  The leaf router the receiver is connected to: that is, upon receipt
      of an IGMP/MLD Report message, the router that embeds the IGMP/MLD Querier
      would typically trigger a RSVP_PATH message towards the source.
      We keep the same convention with respect to data flows, which are opposite
      to control flows.

   o  L2S (Leaf-to-Source) Destinations (the sender or root) are routers where
      user data payload traffic enters the LSP.

   o  RSVP P2MP PATH messages traverse from receivers to the root.

   o  RSVP P2MP RESV messages traverse from the root to the leaf routers of the
      P2MP tree strcuture.




Li, et al.               Expires August 30, 2012                [Page 5]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012

   o  A RSVP RESV message received by a router is interpreted as a successful
      resource reservation made by the upstream node for the establishment of the
      P2MP tree structure.

   o  A RSVP RESV message received by a router is interpreted as successful
      resource reservation made by the downstream node for the establishment
      of a MP2MP tree structure.

   o  Label allocation on incoming interfaces is done prior to sending
      RSVP PATH messages upstream for P2MP tree structures.

   o  Label allocation on incoming interfaces is done prior to sending
      RSVP RESV messages upstream for MP2MP tree structures.

   o  For P2MP LSP tree structures, a node receiving a RSVP PATH message first
      decides if this RSVP PATH message will make the said node a branch LSR or
      not.  If it is not a branch LSR, it is a transit LSR.  In the case
      that it will become a transit LSR because of this PATH message,
      then it will, before sending the RSVP PATH message upstream,
      allocate required bandwidth on the interface on which the RSVP
      PATH message is received.  The upstream node can send traffic soon
      after successfully reserving resources on the downstream link, on
      which the RSVP PATH message SHOULD be received.  In the case that
      the node is already a branch or a transit node before it receives
      the PATH message, then it will allocate required bandwidth on the
      interface on which the RSVP PATH message is received, and send the
      RESV message to the node which sends the PATH message without
      propagating the PATH message further to the upstream node.  For
      P2MP LSPs, a label is carried by the PATH message and should be
      used by the upstream node when distributing the data from
      upstream to downstream.

   o  For MP2MP LSP tree structures, a node will allocate required bandwidth
      on the interface through which the RSVP PATH message is sent before
      sending the RSVP PATH message upstream.  A node receiving a
      RSVP PATH message MUST first decide if this RSVP PATH message will
      make the said node a branch LSR or not.  In the case it will become
      a transit LSR because of this PATH message, then it will allocate
      required bandwidth on the interface on which the RSVP PATH message
      is received and will allocate required bandwidth on the interface
      through which the RSVP PATH message is sent, before sending the
      RSVP PATH message upstream.  The downstream node can send traffic
      soon after successfully reserving bandwidth on the upstream link
      through which the RSVP PATH message SHOULD be sent.  The upstream
      node can send traffic soon after successfully reserving bandwidth
      on the downstream link on which the RSVP PATH message SHOULD be
      received.  In the case that the node is a already a branch or
      a transit node before it receives the PATH message, then it will
      allocate required resources on the interface on which the RSVP
      PATH message is received, and send the RESV message to the node


Li, et al.               Expires August 30, 2012                [Page 6]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012

      which sends the PATH message without propagating the PATH message
      further to the upstream node. The label carried by
      the PATH message should be used by the Path-Receiver node to
      forward data from the Path-Receiver node to the Path-Sender
      node, and the label carried by RESV messages should be used by its
      corresponding Path-Sender node to deliver data from the Path-
      Sender node to the Path-Receiver node.

   o  For the sake of readability, from now on, all mRSVP-TE messages will be
      used to represent all the RSVP-TE messages which are used for the
      computation of receiver-driven P2MP/MP2MP tree structures.

   o  For the sake of readability, from now on all mRSVP-TE LSPs will be used
      to represent all P2MP and/or MP2MP LSPs in receiver-driven (RD) multicast
      P2MP/MP2MP MPLS environments.  We will sometimes use RD P2MP TE LSP
      or RD MP2MP TE LSP to represent such receiver-driven multicast LSPs.




































Li, et al.               Expires August 30, 2012                [Page 7]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


1.4.  Receiver-Driven mRSVP-TE LSP Exampls


                    Path Terminator/Ingress Router
                    +---------+
                    |    R1   |
                    +-----+---+
                             _
                       \  \ /\
                        \  \  \ Path Message w/ Label OBJECT
                 Resv    \  \  \   (msg2)
                 Message  \  \  \
                  (msg3)   \  \  \
                           _\/ \  \
                        +----------------+ Path Remerge
                        |        R3      | Creates Branch Point
                        +----------------+
                              _          _
                        /  /  /\   \  \ /\
                       /  /  /      \  \  \ Path Message (msg1)
        Resv Message  /  /  /   msg4 \  \  \ w/ Label OBJECT
             (msg6)  /  /  /          \  \  \
                    /  /  /Path Msg    \ \  \
                   /  /  / msg5         \  \  \
                 \/_ /  / w/Label OBJ   _\/ \  \
               +----------+            +---+-----+
               |    R4    |            |   R5    |
               +----------+            +---------+
               Path Initiator          Path Initiator
               Originator ID = R4      Originator ID = R5
               L2S Destination = R1    L2S Destination = R1
               Session = S             Session = S


                        Figure 1: P2MP EXAMPLE



   Figure 1 shows that R5 is added as the first leaf of the RD P2MP TE
   LSP, the message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5.
   When the leaf R4 is added, the message flow goes from R4->msg5->R3->msg6->R4.
   In this case, when R3 receives msg5, R3 finds out that the RD P2MP LSP has
   already been set up for R5: therefore, R3 finds itself a branch node for
   leaf R4 and R5, so it will terminate the PATH message and build the corresponding
   RESV message and send it back to R4. The association of the LSP initiated by R4 to
   the existing RD P2MP LSP is determined based on the processing of the session object
   from the mRSVP-TE message. This session object is further documented in Section 2
   of this draft.



Li, et al.               Expires August 30, 2012                [Page 8]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012





                    Path Terminator/Ingress Router
                    +---------+
                    |    R1   |
                    +-----+---+
                             _
                       \  \ /\
                        \  \  \ Path-mp2mp Message w/ Label OBJECT
                 Resv    \  \  \   (msg2)
                 Message  \  \  \
                  (msg3)   \  \  \
           w/ Label OBJECT _\/ \  \
                        +----------------+ Path-mp2mp
                        |        R3      | (Branch Point)
                        +----------------+
                              _          _
                        /  /  /\   \  \ /\
                       /  /  /      \  \  \ Path-mp2mp Message (msg1)
        Resv Message  /  /  /   msg4 \  \  \ w/ Label OBJECT
             (msg6)  /  /  /          \  \  \
     w/ Label OBJECT/  /  /Path-mp2mp  \  \  \
                   /  /  / Message msg5 \  \  \
                  /  /  / w/ Label OBJ   \  \  \
                \/_ /  /                 _\/ \  \
               +----------+            +---+-----+
               |    R4    |            |   R5    |
               +----------+            +---------+
               Path-mp2mp Initiator    Path-mp2mp Initiator
               Originator ID = R4      Originator ID = R5
               L2S Destination = R1    L2S Destination = R1
               Session = S             Session = S


                    Figure 2: MP2MP Example



   Figure 2 shows that R5 is added as the first leaf
   (as both a sender and a receiver) of the RD MP2MP TE LSP, the message
   flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5.  When the
   leaf R4 (both receiver and sender)is added, the message flow goes
   from R4->msg5->R3->msg6.  In this case, when R3 receives msg5, R3
   finds out that the RD MP2MP LSP has already been set up for R5, and R3
   will become the branch LSR for the leaf R4 and R5, so it will
   terminate the PATH message, build a RESV message and send the RESV
   message back to R4.  The association of the LSP initiated by R4 to



Li, et al.               Expires August 30, 2012               [Page 9]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


   the existing MP2MP LSP is determined based on the processing of the
   session object from the mRSVP-TE message. This session object is further
   documented in Section 2 of this draft.


2.  Signaling Protocol Extensions

    mRSVP-TE is similar to the RSVP-TE protocol as specified in [RFC4875],
   [RFC3473] and [RFC3209], but differs in that the receivers (or the leaf
   routers they are connected to)
   initiate the RSVP PATH messages toward the sender.  Compared with
   [RFC4875], mRSVP-TE to be specified in this document can also be used
   to set up MP2MP LSPs.

   Within RD P2MP/MP2MP LSP tree structure environments, the Receiver is the
   Path-Originator.  The RSVP RESV messages flow in the opposite direction as
   compared to the RSVP PATH messages, i.e.  RSVP RESV messages are generated
   by the Sender or a branch LSR.

   Within this receiver-driven context, the processing of receiver-
   initiated mRSVP-TE P2MP messages is different from that of the
   other RSVP messages.  Following the method used by RSVP-TE and P2MP
   RSVP-TE, this draft documents the use of new SESSION C-Type as
   follows:

      Class Name = SESSION
      C-Type
        XX+0   mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type
        XX+1   mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type
        XX+2   mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type
        XX+3   mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type

      Where XX is a number to be allocated by IANA.

   The new SESSION C-Type MUST be used in all receiver-driven P2MP
   RSVP-TE messages.

   The following sections describe the receiver-driven P2MP RSVP-TE
   extensions to the P2MP RSVP-TE protocol.  When there is no difference
   in the protocol, usage of [RFC4875] is assumed.











Li, et al.               Expires August 30, 2012               [Page 10]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


2.1.  L2S Sub-LSPs

   A RD P2MP or MP2MP LSP is composed of one or more L2S sub-LSPs, which
   are merged together at the branch nodes.

   An L2S sub-LSP exists within the context of a RD P2MP or MP2MP LSP.
   There are two ways to identify each sub-LSP:

   o  From the Sender's perspective, each sub-LSP is identified by
      the SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP
      object, as specified in [RFC 4875].  The SESSION object encodes
      P2MP ID, which is unique within the scope of the sender (ingress
      LSR) and remains constant throughout the lifetime of the P2MP
      tree structure. The Extended Tunnel ID, which remains constant
      throughout the lifetime of the P2MP tree structure, and which should
      contain the sender's address to make sure the identifier is globally
      unique identifier. Finally, the Tunnel ID, also remains constant
      throughout the lifetime of the P2MP tree structure.  The
      SENDER_TEMPLATE object contains the ingress LSR source address.
      The S2L_SUB_LSP contains the destination address of the sub-LSP.

   o  From the Receiver's perspective, each sub-LSP is identified
      by a new SESSION object specified in this document, the
      SENDER_TEMPLATE object and L2S_SUB_LSP.  The SESSION object,
      different from the one used in typical sender-driven environments,
      contains some opaque values to be used as the key to associate
      different PATH messages originated from different leaves.  The
      SENDER_TEMPLATE object contains the Path-Sender's address, which
      is actually the Data Receiver.  The L2S_SUB_LSP contains the
      source address of the sub-LSP, i.e. the data Sender's address.

   This document takes the approach from the Receiver's perspective.
   The approach from the Sender's perspective is documented in [RFC 4875].
   In this draft, the SESSION object will encode multicast
   information such as multicast source and group addresses as the opaque
   value.

   Once either the Sender LSR, a transit LSR, or a branch LSR receives
   a PATH message containing SESSION object, the LSR should be able to use
   the opaque values encoded in the SESSION object to determine whether the
   sub-LSP signaled by this PATH message should be merged with existing
   LSPs.

   An EXPLICIT_ROUTE Object (ERO) or mRSVP-TE_SECONDARY_EXPLICIT_ROUTE
   Object (SERO) is used to optionally specify the explicit route of a
   L2S sub-LSP.  Each ERO or SERO that is signaled corresponds to a
   particular L2S_SUB_LSP object.  Details of explicit route encoding
   are specified in section 4.5 of [RFC4875].  The



Li, et al.               Expires August 30, 2012               [Page 11]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012

   SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], the mRSVP-TE
   SECONDARY_EXPLICIT_ROUTE Object C-type and the matching mRSVP-
   TE_SECONDARY_RECORD_ROUTE Object C-type is defined in this docuemnt.

2.2.  Explicit Routing

   When a Path message signals a L2S sub-LSP, the EXPLICIT_ROUTE object
   encodes the path from the leaf to the root LSR.  The Path message
   also includes the L2S_SUB_LSP object for the L2S sub-LSP being
   signaled.  The <(EXPLICIT_ROUTE), (L2S_SUB_LSP)> tuple represents the
   L2S sub-LSP and is referred to as the sub-LSP descriptor.  The
   absence of the ERO should be interpreted as requiring hop-by-hop
   routing for the sub-LSP based on the L2S sub-LSP root address field
   of the L2S_SUB_LSP object.

2.3.  L2S Sub-LSPs and Path Messages

   The mechanism specified in this document allows a RD P2MP/MP2MP LSP to
   be signaled using one or more Path messages.  Each Path message may
   signal one L2S sub-LSPs.

   Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the
   LABEL object upstream towards the Sender.  With a receiver-driven usage
   of the RSVP PATH message, the LABEL_REQUEST object carried by the
   PATH message is no longer mandatory, it becomes optional for
   receiver-driven PATH messages, as mentioned in Figure 4:

    <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
                           [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
                           [ <MESSAGE_ID> ]
                           <SESSION> <RSVP_HOP>
                           <TIME_VALUES>
                           [ <EXPLICIT_ROUTE> ]
                           [ <LABEL_REQUEST> ]
                           [ <PROTECTION> ]
                           [ <LABEL_SET> ... ]
                           [ <SESSION_ATTRIBUTE> ]
                           [ <NOTIFY_REQUEST> ]
                           [ <ADMIN_STATUS> ]
                           [ <POLICY_DATA> ... ]
                           <sender descriptor>
                           [<L2S sub-LSP descriptor list>]


                  Figure 4: PATH Message Extensions.

   The SESSION object encodes an opaque value which is used as a key to
   associate different PATHs to the same RD P2MP/MP2MP tree structure.




Li, et al.               Expires August 30, 2012               [Page 12]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012



   Using [RFC4875] as the base specification, with the LABEL object
   being added to the SENDER DESCRIPTOR object (Figure 5):


            <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                                     [ <ADSPEC> ]
                                     [ <RECORD_ROUTE> ]
                                     [ <SUGGESTED_LABEL> ]
                                     [ <RECOVERY_LABEL> ]
                                     <LABEL>


                   Figure 5: SENDER DESCRIPTOR Object.

   The LABEL object is defined in section 4.1 of [RFC3209].

   Please note that receiver-driven PATH messages convey the
   LABEL_REQUEST as an optional object.  When the receiver-driven P2MP
   LSP is uni-directional, the LABEL_REQUEST in the PATH message is not
   used.  When bi-directional receiver-driven P2MP LSP (MP2MP) are used, the
   LABEL_REQUEST will operate as described in [RFC4875], providing the
   label allocation operation in the other direction.

2.4.  Resv Message Extensions

   Receiver-driven P2MP RSVP-TE does not need any change to the basic
   RESV message, as illustrated in section 6.1 of [RFC4875], as long as the
   SESSION object is using one of the new C-Types to be assigned by
   IANA.  In this document, we specify four new C-Types for RD
   P2MP/MP2MP tree structures: IPv4 P2MP tunnels, IPv4 MP2MP tunnels, IPv6
   P2MP tunnels, IPv6 MP2MP tunnels.

   For receiver-driven P2MP tree structures, the PATH message carries the LABEL
   object, and thus the RESV message doesn't have to carry the LABEL object anymore.
   But for MP2MP LSP tree structures, as indicated by the new C-Type of the SESSION
   object, both PATH and RESV messages will carry LABEL objects for
   sending and receiving purposes, respectively.  Within the context of MP2MP
   tree structures, one of the directions is established as per
   [RFC3209].  Thus, this document is changing the use of the LABEL
   object in the FF Flow Descriptor and SE Filter Spec from mandatory to
   optional.  As indicated in Figure 6:









Li, et al.               Expires August 30, 2012               [Page 13]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> [ <LABEL> ]
                            [ <RECORD_ROUTE> ]
                            [ <L2S sub-LSP flow descriptor list> ]

   <SE filter spec> ::=     <FILTER_SPEC> [ <LABEL> ] [ <RECORD_ROUTE> ]
                            [ <L2S sub-LSP flow descriptor list> ]



                     Figure 6 : RESV Message Extensions.

2.5.  PathErr Message Extensions

   The receiver-driven PathErr messages have the same syntax and
   utilization as the PathErr message described in [RFC4875], with the
   difference in the SENDER DESCRIPTOR object carried by the PathErr
   message.  The receiver-driven PathErr message will use the SENDER
   DESCRIPTOR object defined in Section 2.1 of this document, the same
   SENDER DESCRIPTOR object carried by the Path message the PathErr
   message corresponds to, allowing the indication of the LABEL object
   in the SENDER DESCRIPTOR.  With the ERROR_SPEC object being able to
   indicate Label errors with Error Code 24 for Routing Problems and
   Error Value sub-code of 9 for MPLS label allocation failure as
   defined in section 7.3 of [RFC3209].

2.6.  ResvErr Message Extensions

   The receiver-driven ResvErr messages have the same syntax and
   utilization as the ResvErr message described in [RFC4875].  But this
   ResvErr message will be processed as per Section 2.2 of this document,
   given that the FF FLOW DESCRIPTOR object and the SE FILTER SPEC object
   can optionally contain the LABEL object (instead of mandating the use of
   the LABEL object).  The optional use of the LABEL object is
   conditioned by the nature of the P2MP tree structure, either uni-
   directional (P2MP) or bi-directional (MP2MP).

2.7.  PathTear Message Extensions

   The receiver-driven PathTear message have the same syntax and
   utilization as the PathTear message described in [RFC4875], assuming a
   difference in the SENDER DESCRIPTOR object carried by the PathTear
   message.  The receiver-driven PathTear message will use the SENDER
   DESCRIPTOR object defined in Section 2.1 of this document, the same
   SENDER DESCRIPTOR object carried by the Path message the PathTear
   message corresponds to, allowing the indication of the LABEL object






Li, et al.               Expires August 30, 2012               [Page 14]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


   in the SENDER DESCRIPTOR.

2.8.  SESSION Object

   An mRSVP-TE LSP SESSION object is used to implicitly represent a RD P2MP
   or an MP2MP tree strcuture.  The opaque values encoded in such SESSION
   objects are used by Path-Receivers to determine whether or not to
   associate different PATH messages from different leaves to the same
   P2MP/MP2MP tree structure.  The SESSION object has the following general
   format, whose length is determined by the C-type (Figure 7):


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                        Opaque Values                          ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 7: Format of the mRSVP-TE-LSP SESSION-Object.

   The SESSION object uses the existing SESSION C-Num.  New C-Types are
   defined to accommodate different lengths of opaque values.  For
   native IPv4/IPv6 multicast, the opaque values should encode IPv4/IPv6
   (S, G) or (*, G, RP) for P2MP or MP2MP LSPs.  For IPv4/IPv6 multicast VPNs,
   the opaque values should encode a VPN ID.  For tunnel aggregation where
   multiple multicast streams are sharing a same LSP tunnel, the
   opaque values are TBD.

   The combination of the SESSION object, the SENDER_TEMPLATE object and
   the L2S_SUB_LSP object identifies each L2S sub-LSP.  This follows the
   existing P2P RSVP-TE notion of using the SESSION object for
   identifying a P2P Tunnel, which in turn can contain multiple LSPs,
   each distinguished by a unique SENDER_TEMPLATE object.

   The mechanism for propagating the values defined in the SESSION
   object is outside the scope of this document.

   The mechanism for setting the values defined in the SESSION object is
   TBD.









Li, et al.               Expires August 30, 2012               [Page 15]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


2.8.1.  mRSVP-TE LSP Tunnel IPv4 SESSION Object

   Class = SESSION, mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type = TBD,
   mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type = TBD.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Multicast Source or LSR Root Address         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Multicast Group Address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 8: mRSVP-TE-LSP-Tunnel-IPv4-SESSION-Object.

2.8.2.  mRSVP-TE LSP Tunnel IPv6 SESSION Object

   This is the same as the mRSVP-TE IPv4 LSP SESSION object with the
   difference that the multicast source and group addresses are 16-byte
   long (Figure 8).

   Class = SESSION, mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type = TBD,
   mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type = TBD.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Multicast Source or Root Address (16 bytes)        |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Multicast Group Address (16 bytes)                 |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 9: mRSVP-TE-LSP-Tunnel-IPv6-SESSION-Object.









Li, et al.               Expires August 30, 2012               [Page 16]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012




2.9.  SENDER_TEMPLATE Object

   The SENDER_TEMPLATE object contains the Path-Initiator LSR address.
   In this document, the Path-Initiator is the same as the Leaf Router
   The LSP ID can be changed to allow a sender to do a certain level of
   aggregation. Thus, multiple instances of the P2MP tunnel can be created,
   each with a different LSP ID.  The instances can share resources with
   each other.  The L2S sub-LSPs corresponding to a particular instance
   use the same LSP ID.

2.9.1.  mRSVP-TE LSP Tunnel IPv4 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, mRSVP-TE_LSP_TUNNEL_IPv4 C-Type = TBD.


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 Leaf Router address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 10: mRSVP-TE-LSP-Tunnel-IPv4-SENDER_TEMPLATE-Object.

   IPv4 tunnel receiver address: the IPv4 address of the Leaf Router IPv4
   address.

   LSP ID

   See [RFC3209].

2.9.2.  mRSVP-TE LSP Tunnel IPv6 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, mRSVP-TE_LSP_TUNNEL_IPv6 C-Type = TBD.













Li, et al.               Expires August 30, 2012               [Page 17]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                   IPv6 Leaf Router address                    |
       +                                                               +
       |                            (16 bytes)                         |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Reserved                |            LSP ID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 11: mRSVP-TE-LSP-Tunnel-IPv6-SENDER_TEMPLATE-Object.

   IPv6 tunnel receiver address: the IPv6
   Address of the Leaf Router.

   LSP ID

   See [RFC3209].

2.10.  L2S_SUB_LSP Object

   An L2S_SUB_LSP object identifies a particular L2S sub-LSP belonging
   to the mRSVP-TE LSP.

2.10.1.  L2S_SUB_LSP IPv4 Object

   L2S_SUB_LSP Class = 50, L2S_SUB_LSP_IPv4 C-Type = TBD.



        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   IPv4 L2S Sub-LSP Root Address               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 12: L2S_SUB_LSP_IPv4_Object.








Li, et al.               Expires August 30, 2012               [Page 18]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012




   IPv4 L2S Sub-LSP Root Address: IPv4 address of the L2S sub-LSP
   sender.

2.10.2.  L2S_SUB_LSP IPv6 Object

   L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_IPv6 C-Type = TBD

   It is the same as the IPv4 L2S Sub-LSP object, with the difference
   that the root address is a 16-byte IPv6 address.



        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        IPv6 L2S Sub-LSP Root Address (16 bytes)               |
       |                        ....                                   |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 13: L2S_SUB_LSP_Ipv6_Object.

2.11.  FILTER_SPEC Object

   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
   object.

2.11.1.  P2MP LSP_IPv4 FILTER_SPEC Object

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = TBD.

   The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
   the P2MP LSP_IPv4 SENDER_TEMPLATE object.

2.11.2.  mRSVP-TE LSP_IPv6 FILTER_SPEC Object

   The mRSVP-TE LSP_IPv6 FILTER_SPEC Object uses the P2MP LSP_IPv6
   SENDER_TEMPLATE object defined in [RFC4875].










Li, et al.               Expires August 30, 2012               [Page 19]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


2.11.3.  mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO)

   The mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO) used the The P2MP
   SECONDARY_EXPLICIT_ROUTE Object (SERO) defined in [RFC4875].

2.11.4.  mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO)

   The mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO) uses the P2MP
   SECONDARY_RECORD_ROUTE Object (SRRO)defined in [RFC4875].


3.  In-Band and Out-Band Signalling

3.1.  In-Band Signalling

   In typical Live TV broadcasting environments where the corresponding IP
   multicast distribution trees usually computed and established by
   means of the Protocol Independent Multicast (PIM), need to be deployed over
   an MPLS domain, Receiver-Driven P2MP LSP tree structures can be
   created.  The part of the IP multicast tree that traverses the MPLS
   domain can be instantiated as a RD P2MP LSP.  When a PIM Join
   message is received at the border of the MPLS domain, information
   from that message will be encoded into RSVP-TE P2MP
   messages.  When the RSVP-TE P2MP messages reach the border of
   the next IP multicast domain, the encoded information will be able to be used
   to generate PIM messages that can be sent through this IP multicast domain.
   The result will be an IP multicast tree consisting of a set of IP
   multicast sub-trees that can be spliced together with a RD P2MP
   RSVP-TE based LSP.

   The detailed protocol extensions and procedures are TBD.

3.2.  Out-Band Signalling

   In the case that In-Band Signalling is not used, whenever a PIM Join
   message is received at the border of the MPLS domain, information
   from that message can also be encoded into BGP messages.
   When the BGP messages reach the border of the next IP multicast domain,
   the encoded information should be used to generate PIM
   messages that can be sent through the said IP multicast domain.  The result
   should be an IP multicast tree consisting of a set of IP multicast sub-trees
   that can be spliced together with a RD P2MP LSP tree structure.









Li, et al.               Expires August 30, 2012               [Page 20]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


4.  Broadcast Interfaces

   The receiver-driven approach interoperates with the RSVP upstream
   label allocation mechanism [I-D.ietf-mpls-rsvp-upstream].  Path-
   Senders SHOULD detect the presence of such P2MP-LSP over broadcast
   interfaces for each Path-Receiver.  Instead of labels carried by PATH
   messages, the upstream-assigned labels are carried by RESV messages.

   The considerations for MP2MP is TBD.


5.  Fast Re-Route Considerations

   TBD.


6.  Backward Compatibility

   A receiver-driven P2MP LSP mechanism uses a unique C-Type.  LSRs that
   do not support receiver-driven P2MP-TE LSP, send Path Error [TBD]
   back to the Path Initiator.

   The complete discussion on the Backward Compatibility will be provided in
   the Next version of the document.


7.  Acknowledgements

   We would like to thank authors of [RFC4461], [RFC4875] and the
   authors of draft-ietf-mpls-mp-ldp-reqs from which some text of this
   document has been inspired.


8.  IANA Considerations

   This section is TBD.


9.  Security Considerations

   How a receiver is authenticated is outside the scope of this
   document.  But we briefly summarize the requirements which are
   detailed in the requirements draft.

   It is a requirement that any mRSVP-TE solution developed to meet some
   or all of the requirements expressed in this document MUST include
   mechanisms to enable the secure establishment and management of
   mRSVP-TE MPLS-TE LSPs.  This includes, but is not limited to:



Li, et al.               Expires August 30, 2012               [Page 21]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


   o  A receiver MUST be authenticated before it is allowed to establish
      mRSVP-TE LSP with source, in addition to hop-by-hop security
      issues identified by in RFC 3209 and RFC 4206.

   o  mechanisms to ensure that the ingress LSR of a P2MP LSP is
      identified;

   o  mechanisms to ensure that communicating signaling entities can
      verify each other's identities;

   o  mechanisms to ensure that control plane messages are protected
      against spoofing and tampering;

   o  mechanisms to ensure that unauthorized leaves or branches are not
      added to the mRSVP-TE LSP; and

   o  mechanisms to protect signaling messages from snooping.

   o  Note that mRSVP-TE signaling mechanisms built on P2P RSVP-TE
      signaling are likely to inherit all the security techniques and
      problems associated with RSVP-TE.  These problems may be
      exacerbated in mRSVP-TE situations where security relationships
      may need to maintained between an ingress LSR and multiple egress
      LSRs.  Such issues are similar to security issues for IP
      multicast.

   o  It is a requirement that documents offering solutions for P2MP
      LSPs MUST have detailed security sections.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.




Li, et al.               Expires August 30, 2012               [Page 22]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


   [RFC4461]  Yasukawa, S., "Signaling Requirements for Point-to-
              Multipoint Traffic-Engineered MPLS Label Switched Paths
              (LSPs)", RFC 4461, April 2006.

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC4420]  Farrel, A., Papadimitriou, D., Vasseur, J., and A.
              Ayyangar, "Encoding of Attributes for Multiprotocol Label
              Switching (MPLS) Label Switched Path (LSP) Establishment
              Using Resource ReserVation Protocol-Traffic Engineering
              (RSVP-TE)", RFC 4420, February 2006.

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [I-D.ietf-mpls-rsvp-upstream]
              Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment
              for RSVP-TE", draft-ietf-mpls-rsvp-upstream-05 (work in
              progress), March 2010.

   [I-D.ietf-mpls-mp-ldp-reqs]
              Roux, J. and T. Morin, "Requirements for Point-To-
              Multipoint Extensions to the Label Distribution Protocol",
              draft-ietf-mpls-mp-ldp-reqs-08 (work in progress),
              May 2011.

10.2.  Informative References

   [RFC3468]  Andersson, L. and G. Swallow, "The Multiprotocol Label
              Switching (MPLS) Working Group decision on MPLS signaling
              protocols", RFC 3468, February 2003.




Li, et al.               Expires August 30, 2012               [Page 23]


Internet-Draft            RD Multicast RSVP-TE               March ,  2012


   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3564]  Le Faucheur, F. and W. Lai, "Requirements for Support of
              Differentiated Services-aware MPLS Traffic Engineering",
              RFC 3564, July 2003.

   [RFC5467]  Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
              Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
              Switched Paths (LSPs)", RFC 5467, March 2009.


Authors' Addresses

   Renwei Li
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone:
   Email: renwei.li@huawei.com


   Quintin Zhao
   Huawei Technologies
   Boston, MA
   USA

   Phone:
   Email: quintin.zhao@huawei.com


   Christian Jacquenet
   France Telecom Orange
   4 rue du Clos Courtel
   35512 Cesson Sevigne,
   France

   Phone: +33 2 99 12 43 82
   Email: christian.jacquenet@orange.com









Li, et al.               Expires August 30, 2012               [Page 24]

Internet-Draft            RD Multicast RSVP-TE               March ,  2012