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

Versions: 00 01 02 03                                                   
MPLS Working Group                                                 R. Li
Internet-Draft                                                   Q. Zhao
Intended status: Standards Track                     Huawei Technologies
Expires: April 26, 2013                                     C. Jacquenet
                                                   France Telecom Orange
                                                                  R. Tao
                                                     Huawei Technologies
                                                                B. Zhang
                                                    Telus Communications
                                                        October 23, 2012


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

Abstract

   This document describes the receiver-driven RSVP-TE P2MP LSP
   signaling protocol (mRSVP-TE) which is an extension to the Resource
   Reservation Protocol - Traffic Engineering (RSVP-TE) for the
   computation and establishment of Receiver-Driven Traffic-Engineered
   point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label
   Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) networks.  The document also describes the
   mRSVP-TE extensions and procedures for the interworking between
   mRSVP-TE and the Protocol Independent Multicast (PIM) protocol.

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 April 26, 2013.

Copyright Notice

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



Li, et al.               Expires April 26, 2013                 [Page 1]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   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
   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 April 26, 2013                 [Page 2]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  mRSVP-TE . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.2.  The Need For PIM and mRSVP-TE Interworking . . . . . .  5
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Receiver-Driven mRSVP-TE LSP Examples  . . . . . . . . . . . .  9
     2.1.  RD P2MP LSP Example  . . . . . . . . . . . . . . . . . . .  9
     2.2.  RD MP2MP LSP Example . . . . . . . . . . . . . . . . . . . 11
   3.  Signaling Protocol Extensions  . . . . . . . . . . . . . . . . 12
     3.1.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.1.1.  Sessions . . . . . . . . . . . . . . . . . . . . . . . 12
       3.1.2.  L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . 13
       3.1.3.  Path Originator and Data Receiver  . . . . . . . . . . 14
       3.1.4.  Explicit Routing . . . . . . . . . . . . . . . . . . . 14
     3.2.  PIM-mRSVP TE Interworking Operation  . . . . . . . . . . . 15
       3.2.1.  New M-Flow Spec Types  . . . . . . . . . . . . . . . . 15
       3.2.2.  Signaling An Unidentified Sub-LSP  . . . . . . . . . . 16
     3.3.  Path Messages  . . . . . . . . . . . . . . . . . . . . . . 17
     3.4.  Resv Messages  . . . . . . . . . . . . . . . . . . . . . . 18
     3.5.  PathErr Messages . . . . . . . . . . . . . . . . . . . . . 19
     3.6.  ResvErr Message  . . . . . . . . . . . . . . . . . . . . . 19
     3.7.  PathTear Messages  . . . . . . . . . . . . . . . . . . . . 19
   4.  New and Updated Objects  . . . . . . . . . . . . . . . . . . . 19
     4.1.  SESSION Object . . . . . . . . . . . . . . . . . . . . . . 19
       4.1.1.  mRSVP-TE IPv4 LSP Tunnel SESSION Object  . . . . . . . 20
       4.1.2.  mRSVP-TE IPv6 LSP Tunnel SESSION Object  . . . . . . . 21
     4.2.  SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 21
       4.2.1.  mRSVP-TE LSP IPv4 Tunnel SENDER_TEMPLATE Object  . . . 21
       4.2.2.  SENDER_TEMPLATE Objects  . . . . . . . . . . . . . . . 22
     4.3.  L2S_SUB_LSP Objects  . . . . . . . . . . . . . . . . . . . 23
       4.3.1.  L2S_SUB_LSP IPv4 Objects . . . . . . . . . . . . . . . 23
       4.3.2.  L2S_SUB_LSP IPv6 Objects . . . . . . . . . . . . . . . 24
     4.4.  FILTER_SPEC Objects  . . . . . . . . . . . . . . . . . . . 24
       4.4.1.  mRSVP-TE LSP_IPv4 FILTER_SPEC Objects  . . . . . . . . 24
       4.4.2.  mRSVP-TE LSP_IPv6 FILTER_SPEC Objects  . . . . . . . . 24
     4.5.  MFLOW Object . . . . . . . . . . . . . . . . . . . . . . . 24
   5.  Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 27
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 28
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31



Li, et al.               Expires April 26, 2013                 [Page 3]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


1.  Introduction

   The dramatic growth of multicast-based IP services such as live TV
   broadcasting raises new challenges for network operators.  The sole
   use of IP multicast becomes challenging, given the QoS-demanding
   nature of the applications.  The specification of traffic-engineered,
   MPLS-based, Point-to-Multi-Point (P2MP) tree structures ([RFC4875] is
   meant to address both quality and robustness issues, but failed to be
   massively adopted and deployed so far, mostly because the current
   standard assumes a priori knowledge of all the routers involved in
   the establishment and the maintenance of the tree structure, at the
   cost of extra management complexity.

   However, it is possible and intuitively more efficient to start the
   signaling of a LSP as soon as a receiver notifies interest about a
   multicast content.  Thus, the signaling path relies upon a receiver-
   initiated paradigm, all the way from the receiver to the source.
   This means that the information conveyed in IGMP/MLD Report messages
   sent by the receiver towards the IGMP/MLD Querier which is often
   embedded in the PIM Designated Router that is located as close to the
   receiver as possible and typically at the edge of the PIM network
   will be used to compute the receiver-initiated, PIM-derived signaled,
   P2MP MPLS LSP.

   This document extends RSVP-TE for the dynamic computation of
   receiver- driven P2MP and MP2MP LSP tree structures.  It also
   specifies the mRSVP-TE extenstions and procedures for the
   interworking between mRSVP-TE and the Protocol Independent Multicast
   PIM protocol [RFC4601].

1.1.  Motivation

1.1.1.  mRSVP-TE

   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.
   Typically, the LSP signaling is initiated by the MPLS router
   connected to the source (headend) in such environments.  The a priori
   knowledge of receiver locations is obtained either through static
   configuration or by using another protocol to discover the receivers
   and their Join/Prune states for each data stream.  On the other hand,
   there is no straightforward way to support MP2MP applications by



Li, et al.               Expires April 26, 2013                 [Page 4]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   using P2MP LSP unless full-meshed P2MP LSPs are set up.

   The receiver-driven extension to RSVP-TE defined in this document
   will support both P2MP LSPs and MP2MP LSPs.  Moreover, it does not
   require the root router to know all the receivers' locations a
   priori.  A protocol for receiver discovery is therefore not needed.

1.1.2.  The Need For PIM and mRSVP-TE Interworking

   Service providers use IP multicast for the delivery of live TV
   broadcasting services.  IP multicast traffic is generally forwarded
   over core MPLS infrastructures, along PIM- computed multicast
   distribution trees.

   For the sake of overall service performance, scalability and
   robustness, it is recognized that the PIM machinery should be
   restricted to the edge of the MPLS network, while IP multicast
   traffic is forwarded along P2MP MPLS LSP paths in the MPLS core
   network.  Such a design assumes that:

   o  PIM multicast trees are dynamically computed and established at
      PIM edge(s), and

   o  MPLS P2MP LSPs are dynamically computed and established according
      to the information conveyed in PIM signaling messages.

   Subsequently, IP multicast traffic is forwarded along a PIM multicast
   tree from a source connected somewhere at the edge of the MPLS
   network, then forwarded along the corresponding Receiver-Driven P2MP
   LSP within the MPLS network so that it ultimately reaches receivers
   through PIM Designated Routers connected somewhere at the edge of the
   MPLS network.

   The purpose of such design that combine the dynamics of PIM signaling
   with the robustness of traffic-engineered P2MP MPLS tree structures
   is to encourage PIM-free core infrastructures for the sake of
   operational simplification and performance optimization.

   In this document we describe PIM/mRSVP-TE interworking procedures
   derived from the framework documented in
   [I-D.tao-mpls-pim-interworking]].  [I-D.tao-mpls-pim-interworking]]
   defines a framework for interworking procedures between PIM and an
   MPLS P2MP LSP signaling protocol to accommodate all PIM operations
   with an MPLS network in an optimal and scalable manner, thereby
   avoiding the need for a third protocol to dynamically discover and
   propagate PIM multicast states across the MPLS network.

   The general interworking mechanisms and procedures are those defined



Li, et al.               Expires April 26, 2013                 [Page 5]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   in [I-D.tao-mpls-pim-interworking] and MUST be implemented as part of
   the interworking solution.  Therefore, this document only describes
   the mRSVP-TE-specific procedures to be implemented.

1.2.  Terminology

   The following terms are used in this document:

   o  Sender: Sender refers to the Originator (and hence the 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].

   o  Path-Sender: The sender of RSVP PATH messages, with no correlation
      to the direction of multicast content flows.  Its flow direction
      is irrelevant to that of the Sender, as defined above.

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

   o  Path-Initiator: The Path-Sender that originated a RSVP PATH
      message.  A Path-Initiator is different from a Path-Sender in that
      an intermediate node can be a Path-Sender, but such an
      intermediate node cannot create and initiate RSVP PATH messages.
      A Path-Initator is a Path-Sender, but a Path-Sender doesn't have
      to be a Path-Initiator.

   o  Path-Terminator: The Path-Receiver that does NOT propagate the
      Path message any further.  A Path-Terminator is different from a
      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 RD P2MP LSP is rooted at.  Multicast
      content data enter are forwarded along the RD P2MP LSP from the
      root to the leaves.

   o  mPMBR: MPLS-PIM Multicast Border Router where MPLS-PIM
      interworking takes place.





Li, et al.               Expires April 26, 2013                 [Page 6]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   o  Leaf or Leaf mPMBR: In the context of a RD P2MP LSP, it is the
      mPMBR acting as a leaf for the said LSP.

   o  Root or Root mPMBR: In the context of a RD P2MP LSP, it is the
      mPMBR acting as the root of the said LSP.

   o  M-Flow Spec: The Multicast Flow Spec (from a mRSVP TE standpoint)
      that corresponds to a PIM forwarding rule

1.3.  Overview

   Although the receiver-driven extensions to RSVP-TE as defined in this
   document use the existing sender-driven syntax, there are important
   semantic differences that need to be defined for correct
   interpretation and interoperability purposes.  In the receiver-driven
   context, some semantics of RSVP-TE messages are inverted, but the
   syntax remains unchanged as much as possible.

   In this document, mRSVP-TE denotes the use of the receiver-driven
   multicast extensions to RSVP-TE.

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

   o  The leaf router: The router that receives multicast contents which
      will be eventually delivered to the receiver.  In this document,
      the leaf router will initiate PATH messages.

   o  L2S (Leaf-To-Source) Destinations: Routers where multicast content
      data enter the RD P2MP LSP.

   o  RSVP P2MP PATH messages are sent by leaf routers of the RD P2MP
      LSP towards the root of the said LSP.

   o  RSVP P2MP RESV messages are sent by the root towards the leaf
      routers of the RD P2MP tree structure.

   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 RD 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 an RD MP2MP tree structure.

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




Li, et al.               Expires April 26, 2013                 [Page 7]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


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

   o  For RD 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, it will, before sending the RSVP
      PATH message upstream, allocate the requested bandwidth as
      signaled in the RSVP PATH message 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 for a
      given multicast group before it receives the PATH message, it will
      then allocate the requested 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 RD P2MP LSPs, a label
      is carried by the PATH message and should be used by the upstream
      node to forward multicast content downstream.

   o  For RD MP2MP LSP tree structures, a node will allocate the
      requested 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, it
      will then allocate the requested bandwidth on the interface on
      which the RSVP PATH message is received as well as 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 already
      a branch or a transit node for a given multicast group before it
      receives the PATH message, it will then allocate the requested
      resources on the interface on which the RSVP PATH message is
      received, and send back the RESV message to the node that sent 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 send data from the Path-Sender node to the Path-Receiver node.




Li, et al.               Expires April 26, 2013                 [Page 8]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


2.  Receiver-Driven mRSVP-TE LSP Examples

   This section illustrates by two examples how RD P2MP and RD MP2MP LSP
   paths are set up, respectively.  In both examples, RSVP PATH messages
   are initiated by the leaf routers of the LSP.

   For the RD P2MP example, a RSVP PATH message carries a label for
   sending multicast data downstream.  And for the RD MP2MP example,
   both RSVP PATH and RESV messages carry a label for sending data
   downstream and upstream.

2.1.  RD P2MP LSP Example


                       Sender/Source/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: RD P2MP LSP Example




Li, et al.               Expires April 26, 2013                 [Page 9]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   In Figure 1, when R5 is added as the first leaf of a mulitcast
   distribution tree (multicast LSP), the message flow goes as follows:
   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 a RD P2MP LSP has already been set up for the same
   multicast group (and the same source).  Therefore, R3 is a branch
   node for leaves R4 and R5, and R3 will therefore be the last router
   to receive and process the PATH message.  R3 will then 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 upon the processing of the SESSION and
   L2S_SUB_LSP objects conveyed in the mRSVP-TE messages.  The SESSION
   and the L2S_SUB_LSP objects are documented later in this draft.



































Li, et al.               Expires April 26, 2013                [Page 10]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


2.2.  RD MP2MP LSP Example


                    Root/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 \  \  \  (msg1)
             (msg6)  /  /  /          \  \  \   w/ Label OBJECT
     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: RD MP2MP LSP Example

   In Figure 2, when R5 is added as the first leaf (acting as both a
   sender and a receiver of multicast content) of a RD MP2MP 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 a RD MP2MP LSP
   has already been set up for the same multicast group, and R3
   therefore becomes a branch LSR for leaves R4 and R5.  R3 will be the
   last router to receive and process the corresponding PATH message, R3
   will then build a RESV message accordingly, and send it back to R4.



Li, et al.               Expires April 26, 2013                [Page 11]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   The association of the LSP initiated by R4 to the existing RD MP2MP
   LSP is determined based upon the processing of the SESSION and the
   S2L_SUB_LSP objects conveyed in the mRSVP-TE messages.  The SESSION
   and the L2S_SUB_LSP objects are documented in this draft.


3.  Signaling Protocol Extensions

   The mRSVP-TE protocol is similar to RSVP-TE protocol as specified in
   [RFC4875], [RFC3473], and [RFC3209].  The main difference is that the
   leaf routers of a P2MP LSP initiate the RSVP PATH messages toward the
   root of the said LSP.  Unlike [RFC4875], mRSVP-TE can also be used to
   set up RD MP2MP LSPs.

   In the context of the mRSVP-TE, the leaf router is the Path-
   Originator.  The RSVP RESV messages flow in the opposite direction,
   and are generated by the root or a branch LSR.  RSVP PATH messages
   are forwarded in the opposite direction of the multicast traffic.

   A RSVP PATH message will be terminated at the root of the RD P2MP LSP
   or at an intermediate node if this intermediate node has already
   received another PATH message from another leaf router for the same
   multicast group.  When an intermediate node receives two or more PATH
   messages for the same multicast group, the intermediate node will
   merge them together.  Whether two PATH messages should be merged
   depends on the information encoded in the SESSION and L2S-SUB-LSP
   objects.  The SESSION object encodes multicast group information and
   the L2S-SUB-LSP (leaf-to-source sub-LSP) object encodes the multicast
   source or multicast root information.

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

3.1.  Operation

3.1.1.  Sessions

   As specified in [RFC2205], a session is a data flow with a particular
   destination and transport-layer protocol.  In the context of
   multicast, the data flow is essentially a multicast distribution tree
   rooted at the RD P2MP LSP or RD MP2MP LSP sources.

   For the sake of reliability, two or more sources/roots may be
   deployed to distribute the same multicast streams identified by a
   mulitcast group address (and possibly the address of the multicast
   source, in typical SSM environments).  In this document, the
   mulitcast group address is encoded in the SESSION object and the



Li, et al.               Expires April 26, 2013                [Page 12]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   mulitcast source/root address in the Leaf-to-Source (L2S) sub-LSP
   object.  Note that the same session can have different sources/roots,
   and the same sources/roots can have different sessions.

   The processing of SESSION objects in mRSVP TE is different from that
   of SESSION objects in RSVP-TE [RFC4875].  In order to uniquely
   identify mRSVP TE SESSION objects, different C-Types of SESSION
   objects are introduced.  This draft documents SESSION objects for
   native IPv4/IPv6 multicast applications.  Additional SESSION object
   types MAY be added in the future.

   The new SESSION C-Types are described 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.


                       Figure 3: New SESSION C-Types

   The new SESSION C-Type MUST be used in all mRSVP-TE messages.

3.1.2.  L2S Sub-LSPs

   A RD P2MP LSP is composed of one or more L2S sub-LSPs, which are
   merged together at the branch nodes.  There are two ways to identify
   each L2S 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 [RFC4875].  The SESSION object encodes the P2MP
      ID, Tunnel ID, and Extended Tunnel ID.  The P2MP ID is unique
      within the scope of the sender (ingress LSR) and remains constant
      throughout the lifetime of the RD P2MP tree structure.  The
      Extended Tunnel ID, which remains constant throughout the lifetime
      of the RD P2MP tree structure, contains the sender's address to
      make sure the identifier is globally unique.  Finally, the Tunnel
      ID also remains constant throughout the lifetime of the RD P2MP
      tree structure.  The SENDER_TEMPLATE object contains the ingress
      LSR source address.  The S2L_SUB_LSP object contains the
      destination address of the sub-LSP.




Li, et al.               Expires April 26, 2013                [Page 13]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   o  From the Receiver's perspective, each sub-LSP is identified by a
      new SESSION object, a new SENDER_TEMPLATE object and a new
      L2S_SUB_LSP object.  The SESSION object, different from the one
      used in typical sender-driven environments, contains information
      to be used as the key to associate different PATH messages
      originated from different leaves.  The SENDER_TEMPLATE object
      contains the Path-Originator's address, which is actually the leaf
      router of the corresponding RD P2MP LSP.  The L2S_SUB_LSP object
      contains the source or root address of the sub-LSP, i.e., the data
      Sender's address.  The SESSION, SENDER_TEMPLATE and L2S_SUB_LSP
      objects all together will identify the multicast group address,
      the multicast address source, and a mulitcast leaf router.

   This document assumes the receiver-driven approach.

   Once an LSR receives a receiver-driven PATH message that contains
   both the SESSION and L2S_SUB_LSP objects, the LSR will use these
   objects to determine whether the sub-LSP signaled by this PATH
   message should be merged with an existing RD P2MP LSP.

3.1.3.  Path Originator and Data Receiver

   This draft documents a new type of SENDER_TEMPLATE object, which
   contains the Path-Originator's IP address and describes the identity
   of the Path Originator.

   In [RFC2205] and [RFC4875], the sender is a Path Originator that also
   forwards multicast data.  In the receiver-driven context, Path
   Originators and data senders may be different.  For RD P2MP LSPs,
   Path Originators are actually the leaf routers.  For RD MP2MP LSPs,
   Path Originators are also both the data senders and leaf routers.

   In this document, the same Object Class SENDER_TEMPLATE with a
   different C-Type is used to represent and identify a Path Originator.
   In the case of RD P2MP LSPs, the SENDER_TEMPLATE object describes the
   identify of a leaf router.  In the case of RD MP2MP LSPs, the
   SENDER_TEMPLATE object describes the identify of an LSR that behaves
   as both a data sender and a data receiver.

   All the SESSION, L2S_SUB_LSP and SENDER_TEMPLATE objects together
   contained in a RSVP PATH message will uniquely identify a L2S sub-
   LSP.

3.1.4.  Explicit Routing

   An EXPLICIT_ROUTE Object (ERO) is used to optionally specify the
   explicit route of an L2S sub-LSP.  Each signaled ERO corresponds to a
   particular L2S_SUB_LSP object.  Details of ERO encoding are specified



Li, et al.               Expires April 26, 2013                [Page 14]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   in Section 4.5 of [RFC4875].  Within the Receiver-Driven context, ERO
   objects are encoded in a reverse order.

   When a RSVP 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 an ERO should be interpreted as requiring hop-by-hop
   reverse forwarding for the sub-LSP based on the root address field of
   the L2S_SUB_LSP object.

3.2.  PIM-mRSVP TE Interworking Operation

3.2.1.  New M-Flow Spec Types

   [I-D.tao-mpls-pim-interworking] introduces four types of M-Flow
   specs, each corresponding to a type of PIM forwarding state:

   o  M-Flow Spec Type-1(value 1) for (*, *, RP);

   o  M-Flow Spec Type-2(value 2) for (*, G);

   o  M-Flow Spec Type-3(value 3) for (S, G);

   o  M-Flow Spec Type-4(value 4) for (S, G, RPT);

   These M-Flow Spec types will be signaled in-band across the MPLS
   network by mRSVP-TE.  Their formats are specified in
   [I-D.tao-mpls-pim-interworking]. mRSVP-TE is used to (1) initiate the
   signaling of a RD P2MP LSP or a sub-LSP, (2) merge a sub-LSP into an
   existing LSP, or (3) delete it when a downstream router does not need
   it, based upon the information conveyed in the said M-Flow Specs.
   This implies that:

   o  M-Flow specs are encapsulated into mRSVP-TE PATH messages, and

   o  M-Flow specs are used to identify a given multicast session so
      that a receiver-driven, traffic-engineered P2MP LSP path will be
      computed and established accordingly.

   When an M-Flow spec is generated and passed to mRSVP-TE based upon
   the MPLS-PIM interworking procedures enforced by an mPMBR, mRSVP-TE
   first determines if this M-Flow spec leads to the grafting of an
   additional sub-LSP, by using the procedure described in
   [I-D.tao-mpls-pim-interworking].  If the contents of the signaled



Li, et al.               Expires April 26, 2013                [Page 15]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   M-Flow Spec does not mandate the grafting of an additional sub-LSP,
   the M-Flow is then bound to an existing RD P2MP LSP.

   If a new sub-LSP needs to be grafted to an existing receiver-driven,
   traffic engineered P2MP MPLS LSP according to the information
   conveyed in the M-Flow spec, the procedures documented in the
   following subsections MUST be followed.

3.2.2.  Signaling An Unidentified Sub-LSP

   When a sub-LSP is signaled from a leaf mPMBR towards the root,
   mRSVP-TE may not have determined if this sub-LSP would lead to the
   computation and the establishment of a new RD P2MP LSP or the
   grafting of an additional sub-LSP to an existing RD P2MP MPLS LSP.
   This sub-LSP is denoted as an "Unidentified" sub-LSP.

   mRSVP-TE then works as follows to signal an unidentified sub-LSP.

3.2.2.1.  Sending A Path Message For An Unidentified Sub-LSP

   o  Set 0 as the tunnel ID field in the session object

   o  Set the "Tunnel Identifier with M-Flow Spec Session" attribute
      flag to 1

   o  Encode the M-Flow spec in the mflow spec object list according to
      the "Path Message Change and Encoding".

3.2.2.2.  Receiving A Path Message For An Unidentified Sub-LSP

   When a LSR receives a PATH message with 0 as the tunnel ID and the
   "Tunnel Identifier with MFLOW spec" flag set to 1, it processes the
   sub-LSP grafting request as an unidentified sub-LSP as follows:

   o  Use the included M-Flow spec and binding policy to determine which
      RD P2MP LSP the sub-LSP belongs to.  See Sections 3.1.2 and 3.1.3
      of [I-D.tao-mpls-pim-interworking].

   o  When the sub-LSP does not merge into an existing RD P2MP MPLS LSP,
      the PATH message will reach the root, which can then determine if
      the sub-LSP assumes the computation of a new RD P2MP MPLS LSP, or
      merges into an existing RD P2MP MPLS LSP.

   o  The sub-LSP is then assigned the tunnel ID.  The root sets the
      "Tunnel Identifier with MFLOW spec" session attribute flag to 0,
      and completes the rest of the signaling using mRSVP-TE procedures.





Li, et al.               Expires April 26, 2013                [Page 16]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   o  Each LSR merges the M-Flow spec in the mflow spec object list
      using mflow_specs_merge(T, F) when the tunnel is identified.

3.3.  Path Messages

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

   A receiver-driven P2MP MPLS LSP uses the PATH message to carry the
   LABEL object upstream from the leaf router towards the Sender.  With
   a receiver-driven usage of the RSVP PATH messages, the LABEL_REQUEST
   object carried by the PATH message is no longer mandatory.  It
   becomes optional for receiver-driven PATH messages, as specified in
   Figure 4 below.

   The PIM/mRSVP-TE inter-working procedures introduce a new session
   attribute called "Tunnel Identifier with MFLOW spec".  By default, it
   is set to 0.  For an unidentified sub-LSP, the attribute is set by
   the Path Sender to indicate that a router receiving this message must
   process the information conveyed in M-Flow specs to identify the
   corresponding session and make a decision accordingly (e.g.,
   contribute to the grafting of a new sub-LSP to the relevant RD P2MP
   MPLS LSP).

   The mRSVP-TE PATH message is extended to include a list of M-Flow
   Spec Objects:


  <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>]
                           [mflow spec list]
       < mflow spec list > ::= <PMSI_MFLOW_SPEC> [< mflow spec list >]

                     Figure 4: Path Message Extensions



Li, et al.               Expires April 26, 2013                [Page 17]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   The SESSION object encodes information about the being-signalled
   multicast group address.  The SESSION object together with the
   L2S_SUB_LSP object will be used as the key to associate different
   sub-LSPs to the same RD P2MP LSP.

   Using [RFC4875] as the reference specification, the LABEL object is
   added to the <sender descriptor> as specified in Figure 5.

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

                        Figure 5: Sender Descriptor

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

   Note that the mRSVP-TE PATH messages convey the LABEL_REQUEST object
   as an optional object.  If the PATH message signals a RD P2MP LSP,
   the LABEL_REQUEST object is not used.  If the PATH message signals a
   RD MP2MP LSP, the LABEL_REQUEST object is required to ask for labels
   from the upstream LSR.

3.4.  Resv Messages

   The mRSVP-TE protocol does not need any change to the basic RESV
   messages, as specified in Section 6.1 of [RFC4875], assuming the
   receiver-driven-specific SESSION objects of the new C-Types are used.

   For receiver-driven P2MP LSPs, the PATH message carries the LABEL
   object, and thus, the RESV message doesn't have to carry the LABEL
   object anymore.  But for RD MP2MP LSPs, both PATH and RESV messages
   will carry LABEL objects for sending and receiving multicast content.
   Within the context of RD MP2MP LSPs, one of the directions is
   established as per [RFC2209] Thus, this document describes how the
   use of the LABEL object in the FF Flow Descriptor and SE Filter Spec
   is modified from Mandatory to Optional, as described in Figure 6.



   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> [ <LABEL> ]
                            [ <RECORD_ROUTE> ]
                            [ <L2S_SUB_LSP> ]

   <SE filter spec> ::=     <FILTER_SPEC> [ <LABEL> ] [ <RECORD_ROUTE> ]
                            [ <L2S_SUB_LSP> ]



Li, et al.               Expires April 26, 2013                [Page 18]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


                     Figure 6: Resv Message Extensions

3.5.  PathErr Messages

   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> carried by the PathErr message.
   The receiver-driven PathErr message will use the <sender descriptor>
   defined in this document, the same as that carried by the PATH
   messages which the PathErr messages correspond to.

3.6.  ResvErr Message

   The receiver-driven ResvErr messages have the same syntax and
   utilization as the ResvErr message described in [RFC4875] But the
   ResvErr messages will be processed as per this document, given that
   the <FF flow descriptor> and the <SE filter spec> 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 RD P2MP LSP, either uni-directional (P2MP) or bi-
   directional (MP2MP).

3.7.  PathTear Messages

   The receiver-driven PathTear messages have the same syntax and
   utilization as the PathTear messages described in [RFC4875], except
   for the <sender descriptor> carried by the PathTear messages.  The
   receiver-driven PathTear messages will use <sender descriptor>
   defined in this document, the same as that carried by the PATH
   messages which the PathTear messages correspond to.


4.  New and Updated Objects

4.1.  SESSION Object

   A mRSVP-TE LSP SESSION object is used.  This object uses the existing
   SESSION C-Num.  New C-Types are defined to uniquely identify any RD
   P2MP LSP.  This SESSION object has a similar structure as the
   existing point-to-point RSVP-TE SESSION object.  However, the
   destination address is set to the P2MP ID instead of the unicast
   Tunnel Endpoint address.  All L2S sub-LSPs that are part of the same
   RD P2MP LSP share the same SESSION object.  This SESSION object
   identifies the RD P2MP LSP.

   The combination of the SESSION, the SENDER_TEMPLATE and the
   L2S_SUB_LSP objects identifies each L2S sub-LSP.  This follows the
   existing P2P RSVP-TE notion of using the SESSION object for



Li, et al.               Expires April 26, 2013                [Page 19]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   identifying a P2P LSP, which in turn can contain multiple LSPs, each
   distinguished by a unique SENDER_TEMPLATE object.

   The mechanism for propagating the Tunnel ID value defined in the
   SESSION object is outside the scope of this document, the mechanism
   for setting the Tunnel ID values defined in the SESSION object, and
   the mechanism for associating the values defined in the SESSION
   object with PIM-signaled information is defined in
   [I-D.tao-mpls-pim-interworking]

4.1.1.  mRSVP-TE IPv4 LSP Tunnel SESSION Object

   Class = SESSION, 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       mRSVP-TE ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  MUST be zero                 |      Tunnel ID                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Extended Tunnel ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  mRSVP-TE-LSP-Tunnel-IPv4-SESSION-Object

                                 Figure 7

   mRSVP-TE ID

   A 32-bit identifier used in the SESSION object that remains constant
   during the lifetime of the RD P2MP LSP.  It encodes the mRSVP-TE
   Identifier that is unique within the scope of the Root LSR.

   Tunnel ID

   A 16-bit identifier used in the SESSION object that remains constant
   during the lifetime of the RD P2MP LSP.

   Extended Tunnel ID

   A 32-bit identifier used in the SESSION object that remains constant
   during the lifetime of the RD P2MP LSP.  Root LSRs that wish to have
   a globally unique identifier for the RD P2MP LSP SHOULD place their



Li, et al.               Expires April 26, 2013                [Page 20]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   tunnel sender address here.  A combination of this address with the
   mRSVP-TE ID and Tunnel ID provides a globally unique identifier for
   the RD P2MP LSP.

4.1.2.  mRSVP-TE IPv6 LSP Tunnel SESSION Object

   This is the same as the IPv4 LSP SESSION object with the difference
   that the extended tunnel ID is set to a 16-byte identifier [RFC2209].

   Class = SESSION, mRSVP-TE_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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       mRSVP-TE ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  MUST be zero                 |      Tunnel ID                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Extended Tunnel ID (16 bytes)            |
       |                                                               |
       |                             .......                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  mRSVP-TE-LSP-Tunnel-IPv6-SESSION-Object

                                 Figure 8

4.2.  SENDER_TEMPLATE Object

   The SENDER_TEMPLATE object contains the ingress LSR source address.
   The LSP ID can be changed to allow a sender to share resources with
   itself.  Thus, multiple instances of the RD P2MP LSP 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.

4.2.1.  mRSVP-TE LSP IPv4 Tunnel SENDER_TEMPLATE Object

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








Li, et al.               Expires April 26, 2013                [Page 21]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   IPv4 tunnel sender address                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Reserved                |            LSP ID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



              mRSVP-TE-LSP-Tunnel-IPv4-SENDER_TEMPLATE-Object

                                 Figure 9

   IPv4 tunnel sender address

   See [RFC2209].

   LSP ID

   See [RFC2209].

4.2.2.  SENDER_TEMPLATE Objects

   The SENDER_TEMPLATE object contains the IP address of the Path-
   Initiator LSR.  The LSP ID can be changed to allow a sender to do a
   certain level of resource sharing.  Thus, multiple instances of the
   same RD P2MP LSP 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.

4.2.2.1.  Multicast LSP IPv4 SENDER_TEMPLATE Objects

   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 Multicast LSP SENDER_TEMPLATE Objects

   IPv4 Leaf Router Address: The IPv4 address of the Leaf Router.



Li, et al.               Expires April 26, 2013                [Page 22]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   LSP ID: A 2-byte identifier that can be changed to allow it to share
   resources with itself.  Its usage is the same as that described in
   [RFC3209].

4.2.2.2.  Multicast LSP IPv6 SENDER_TEMPLATE Objects

   Class = SENDER_TEMPLATE, mRSVP-TE_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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                   IPv6 Leaf Router address                    |
       +                                                               +
       |                            (16 bytes)                         |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Reserved                |            LSP ID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 11: mRSVP-TE LSP IPv6 SENDER_TEMPLATE Objects

   IPv6 Leaf Router Address: The IPv6 address of the Leaf Router.

   LSP ID: A 2-byte identifier that can be changed to allow it to share
   resources with itself.  Its usage is the same as that described in
   [RFC2209].

4.3.  L2S_SUB_LSP Objects

   An L2S_SUB_LSP object identifies a particular L2S sub-LSP that is (to
   be) grafted to a given RD P2MP LSP, as explained earlier in this
   document.

4.3.1.  L2S_SUB_LSP IPv4 Objects

   L2S_SUB_LSP Class = TBD, 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               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Li, et al.               Expires April 26, 2013                [Page 23]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


                    Figure 12: L2S_SUB_LSP IPv4 Objects

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

4.3.2.  L2S_SUB_LSP IPv6 Objects

   L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        IPv6 L2S Sub-LSP Root Address (16 bytes)               |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 13: L2S_SUB_LSP IPv6 Object

4.4.  FILTER_SPEC Objects

   The FILTER_SPEC object is canonical to the SENDER_TEMPLATE object.

4.4.1.  mRSVP-TE LSP_IPv4 FILTER_SPEC Objects

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

   The format of the mRSVP-TE LSP_IPv4 FILTER_SPEC object is identical
   to the mRSVP_TE_LSP_TUNNEL_IPv4 SENDER_TEMPLATE object.

4.4.2.  mRSVP-TE LSP_IPv6 FILTER_SPEC Objects

   The format of the mRSVP-TE LSP_IPv6 FILTER_SPEC object is identical
   to the mRSVP_TE_LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.

4.5.  MFLOW Object

   New Object: Class = PMSI_MFLOW_SPEC (TBA)

   Class = PMSI_MFLOW_SPEC, MCAST_GROUP_SRC_LIST, C-Type = XXX(TBA)

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Reserved                     | Num groups    |ACT|M|  Policy |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Li, et al.               Expires April 26, 2013                [Page 24]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


       |         Multicast Group Address 1 (Encoded-Group format)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Number of Joined Sources    |   Number of Pruned Sources    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Joined Source Address 1 (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+
       |                             .                                 |
       |                             .                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Joined Source Address n (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Pruned Source Address 1 (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             .                                 |
       |                             .                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Pruned Source Address n (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           .                                   |
       |                           .                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Multicast Group Address m (Encoded-Group format)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Number of Joined Sources    |   Number of Pruned Sources    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Joined Source Address 1 (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             .                                 |
       |                             .                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Joined Source Address n (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Pruned Source Address 1 (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             .                                 |
       |                             .                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Pruned Source Address n (Encoded-Source format)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       "ACT": 0, 1, or 2 to indicate that the received M-Flow specs are
              to replace, be added into, or be removed from the existing
              M-FLOW specs, respectively.
       'M' bit: If set, it indicates that there are more entries
             following. This is to deal with fragmentation issues.
       "Policy" - M-Flow aggregation policy.





Li, et al.               Expires April 26, 2013                [Page 25]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


                          Figure 14: MFLOW Object



       An Encoded-Source address has the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Rsvd    |S|W|R|  Mask Len     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Source Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

                         Figure 15: Encoded-Source


        An Encoded-Group address has the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Group multicast Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

                         Figure 16: Encoded-Group

   Other fields are from [RFC4601], and MUST be set according to the PIM
   specification.




















Li, et al.               Expires April 26, 2013                [Page 26]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   The encoding of each M-Flow spec is defined by its type:


      For M-Flow Spec Type-1 (*, *, RP):
          The Multicast Group Address 1 gives the group range. It is
          encoded as the Multicast Group Address + Mask Length.

          A one-entry Join or Prune source list is used for the group
          range and the source address of the entry is set to the RP address.

          (S, G, RPT) list can be encoded in this M-Flow Spec Type by
          adding them in Join/Prune source list for the corresponding multicast group.


      For M-Flow Spec Type-2 (*, G):

          The Multicast Group Address 1 gives the group address. It is
          encoded as the Multicast Group Address + full mask length.

          A source entry in Join or Prune source list is used for the
          group, and the source address of the entry is set to the RP address.

          (S, G, RPT) list can be encoded in this M-Flow Spec Type by adding them
          in Join/Prune source list for the corresponding multicast group.

      For M-Flow Spec Type-3 (S, G):
          Multicast Group Address + Full Length Mask Length identify
          the multicast group;

          Source address is encoded into the source list.


      For M-Flow Spec Type-4 (S, G, RPT):

          Multicast Group Address + Full Length Mask Length identify
          the multicast group.

          Source address is encoded into the source list with 'R' bit
          set and 'W' bit cleared. See [RFC4601] "Source Address" encoding
          for the definition of these bits.

                    Figure 17: Encoding Spec for M-FLOW


5.  Fast Re-Route Considerations

   The Fast Re-Route mechanisms and procedures specified in [RFC4090]
   will not be applicable to the receiver-driven extension to RSVP-TE



Li, et al.               Expires April 26, 2013                [Page 27]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   described in this document, since the PATH and RESV messages are sent
   in different directions.

   Extensions to mRSVP-TE to support Fast Re-Route are described in
   [I-D.zlj-mpls-mrsvp-te-frr].


6.  Backward Compatibility

   A receiver-driven P2MP LSP mechanism uses different C-Types than
   those defined in [RFC4875].  If LSRs do not recognize the receiver-
   driven C-Types, they will not support the receiver-driven extensions
   described in this document.  LSRs that do not support such C-Types
   MUSTsend Path Error [TBD] back to the Path Originator.

   Elaboration will be provided in the further versions of the draft.


7.  Acknowledgements

   We would like to thank Lin Han and Katherine Zhao for their comments
   on early drafts of this work.  In particular we would like to thank
   Lou Berger and Eric Osborne for their very helpful questions,
   comments and suggestions.


8.  IANA Considerations

   This section is TBD.


9.  Security Considerations

   It is a requirement [I-D.jacquenet-mpls-rd-p2mp-te-requirements]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:

   o  A receiver MUST be authenticated before it is allowed to establish
      a RD P2MP LSP with its source, in addition to hop-by-hop security
      issues identified by in [RFC3209] and [RFC4206].

   o  Mechanisms to provide guarantees about the identity of the ingress
      LSR of a RD P2MP LSP;

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



Li, et al.               Expires April 26, 2013                [Page 28]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


   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
      grafted to a given RD P2MP LSP

   o  Mechanisms to protect signaling messages from snooping.Note that
      mRSVP-TE signaling mechanisms built on P2P RSVP-TE signaling are
      likely to inherit all the security issues and solutions associated
      with RSVP-TE.  These problems may be exacerbated in mRSVP-TE
      situations where security associations MAY be required 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.

   [RFC2209]  Braden, B. and L. Zhang, "Resource ReSerVation Protocol
              (RSVP) -- Version 1 Message Processing Rules", RFC 2209,
              September 1997.

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

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



Li, et al.               Expires April 26, 2013                [Page 29]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


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

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

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.

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

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP



Li, et al.               Expires April 26, 2013                [Page 30]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, February 2012.

   [RFC6517]  Morin, T., Niven-Jenkins, B., Kamite, Y., Zhang, R.,
              Leymann, N., and N. Bitar, "Mandatory Features in a Layer
              3 Multicast BGP/MPLS VPN Solution", RFC 6517,
              February 2012.

   [I-D.zlj-mpls-mrsvp-te-frr]
              Zhao, K., Li, R., and C. Jacquenet, "Fast Reroute
              Extensions to Receiver-Driven RSVP-TE for Multicast
              Tunnels", draft-zlj-mpls-mrsvp-te-frr-00 (work in
              progress), July 2012.

   [I-D.tao-mpls-pim-interworking]
              Tao, B., "MPLS PIM Inter-working",
              draft-tao-mpls-pim-interworking-00 (work in progress),
              July 2012.

   [I-D.jacquenet-mpls-rd-p2mp-te-requirements]
              Jacquenet, C., Zhao, Q., and B. Zhang, "Requirements for
              Receiver-Driven Traffic Engineered Point-to-Multi-Point
              (P2MP) MPLS Tree Structures",
              draft-jacquenet-mpls-rd-p2mp-te-requirements-02 (work in
              progress), October 2012.


Authors' Addresses

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

   Email: renwei.li@huawei.com


   Quintin Zhao
   Huawei Technologies
   Boston, MA
   USA

   Email: quintin.zhao@huawei.com







Li, et al.               Expires April 26, 2013                [Page 31]


Internet-Draft      Receiver-Driven Multicast RSVP-TE       October 2012


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

   Email: christian.jacquenet@orange.com


   Robert Tao
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: robert.tao@huawei.com


   Boris Zhang
   Telus Communications
   200 Consilium Pl Floor 15
   Toronto, ON M1H 3J3,
   Canada

   Email: Boris.Zhang@telus.com


























Li, et al.               Expires April 26, 2013                [Page 32]