MPLS                                                            R. Torvi
Internet-Draft                                              K. Chan, Ed.
Expires: April 22, 2010                              Huawei Technologies
                                                            C. Jacquenet
                                                          France Telecom
                                                        October 19, 2009


 Receiver Driven Point-To-Multi-Point Traffic Engineered Label Switched
                                 Paths
             draft-chan-torvi-jacquenet-mpls-rd-p2mp-te-00

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on April 22, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Torvi, et al.            Expires April 22, 2010                 [Page 1]


Internet-Draft                  Document                    October 2009


Abstract

   For content delivery services that rely upon the IP multicast
   transmission scheme, the distribution trees are receiver initiated.
   The delivery of such services over MPLS networking infrastructures
   may rely upon P2MP LSP tree structures that are sender initiated,
   with the root of the P2MP tree being at the LSR router directly
   connected to the sender.  This document describes a mechanism that
   aims at establishing MPLS P2MP tree structures that are receiver
   initiated.  This mechanism builds on the works of Point-to-MultiPoint
   Traffic Engineered Lable Swithched Paths (P2MP-TE LSPs).  This
   mechanism can also be used to establish receiver driven BiDirectional
   P2MP TE LSPs.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Signaling Protocol Extensions  . . . . . . . . . . . . . . . .  6
     2.1.  Path Message Extensions  . . . . . . . . . . . . . . . . .  6
     2.2.  Resv Message Extensions  . . . . . . . . . . . . . . . . .  7
     2.3.  PathErr Message Extensions . . . . . . . . . . . . . . . .  8
     2.4.  ResvErr Message Extensions . . . . . . . . . . . . . . . .  8
     2.5.  PathTear Message Extensions  . . . . . . . . . . . . . . .  9
   3.  Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . .  9
   4.  Fast Re-Route Considerations . . . . . . . . . . . . . . . . .  9
   5.  Re-Merging and Crossover . . . . . . . . . . . . . . . . . . . 10
   6.  Receiver-Driven Bidirectional LSPs . . . . . . . . . . . . . . 10
   7.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Implications  . . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13












Torvi, et al.            Expires April 22, 2010                 [Page 2]


Internet-Draft                  Document                    October 2009


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 the procedure to setup
   multipoint LSPs from sender to receiver.  This document extends
   P2MP-TE to be used for receiver-driven P2MP-TE LSPs.  This document
   complements P2MP-TE [RFC4875], allowing P2MP-TE LSPs to be
   established either from a sender or from a receiver, unidirectional
   or bidirectional.

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 several
   hundreds of thousands of IPTV receivers need to be served with the
   appropriate level of quality.  Current source-driven P2MP LSP
   establishment assumes a prior knowledge of receiver(s) location for
   the sake of the P2MP LSP tree structure's forwarding efficiency.  But
   the receiver's location information is not available a priori for the
   root MPLS router to compute and establish the relevant P2MP tree
   structure.

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

1.2.  Terminology

   With the receiver-driven concept, we have re-defined the following
   terms:

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

   o  Receiver: Receiver refers to the Receiver of the content/payload.
      As 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].



Torvi, et al.            Expires April 22, 2010                 [Page 3]


Internet-Draft                  Document                    October 2009


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

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

   o  Path-Initiator: The Path-Sender that originated the RSVP PATH
      message.  This being different from Path-Sender because an
      intermediate node can be a Path-Sender, but different from the
      node that created and initiated the RSVP PATH message, the Path-
      Initiator.

   o  Path-Terminator: The Path-Receiver that does NOT propagate the
      Path message.  This being different from Path-Receiver because an
      intermediate node can be a Path-Receiver.

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:

   1.  Receiver initiates RSVP PATH message towards the one or more
       senders.  We keep same convention with respect to data flows,
       which are opposite to control flows.

   2.  S2L Destinations (the leaves) are ingress routers where user data
       payload traffic enter the LSP.

   3.  RSVP P2MP PATH messages traverse from receiver to senders.

   4.  RSVP P2MP RESV messages traverse from sender to receiver.

   5.  A node receiving a RSVP RESV message is interpreted as successful
       resource reservation from the upstream node.

   6.  A node receiving a RSVP PATH message would first allocate
       required resources on the interface through which the RSVP PATH
       message is received, before sending the RSVP PATH message
       upstream.  So that the upstream node can send traffic soon after



Torvi, et al.            Expires April 22, 2010                 [Page 4]


Internet-Draft                  Document                    October 2009


       successfully reserving resources on the downstream link, on which
       the RSVP PATH message is received.

   7.  Label allocation on incoming interface is done prior to sending
       RSVP PATH messages upstream.  The syntax details are defined in
       Section 2.




                    Path Terminator/Ingress Router
                  +---------+
                  |    R1   |
                  +-----+---+   _
                 \       \     /\   Path Message w/ Label OBJECT
                  \       \      \
            Resv   \       \      \
            Message \       \      \
                     \       \      \
                     _\/      \      \    Path Remerge
                          +------------+  Creates Branch Point
                          |      R3    |
                          +------------+   _
                               /  \       /\
                          /   /    \        \   Path Message
            Resv Message /   /      \        \   w/ Label OBJECT
                        /   /        \        \
                       /   /          \        \
                     \/_  /            \        \
                         /          +---+-----+
                  +----------+      |   R5    |
                  |    R4    |      +---------+
                  +----------+           Path Initiator/Egress Router
                   Path Initiator        LSP_ID = X
                   LSP_ID = X            Originator ID = R5
                   Originator ID = R4    Destination = R1
                   Destination = R1
                   Session ID = A        Session ID = A




            Figure 1: Receiver-Driven P2MP RSVP-TE LSP Overview








Torvi, et al.            Expires April 22, 2010                 [Page 5]


Internet-Draft                  Document                    October 2009


2.  Signaling Protocol Extensions

   Receiver-driven P2MP MPLS-TE LSP uses the RSVP-TE protocol as
   specified in [RFC4875], [RFC3473], and [RFC3209], but unlike what is
   specified in [RFC4875], receivers initiate the RSVP PATH messages
   toward the sender.

   With receiver-driven P2MP MPLS-TE LSP, the content 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 content Sender or the MPLS router it is
   directly attached to.  All other RSVP messages flow in reference to
   this picture.

   Within this receiver-driven context, the processing of receiver-
   initiated P2MP RSVP-TE messages should be differentiated from the
   other RSVP messages.  Following the method used by RSVP-TE and P2MP
   RSVP-TE, this document recommends the use of new SESSION C-Type as
   follows:


   Class Name = SESSION
   C-Type
     XX+0   RcvrD_P2MP_LSP_TUNNEL_IPv4 C-Type
     XX+1   RcvrD_P2MP_LSP_TUNNEL_IPv6 C-Type
     XX+2   BiDi_P2MP_LSP_TUNNEL_IPv4 C-Type
     XX+4   BiDi_P2MP_LSP_TUNNEL_IPv6 C-Type

   Where XX is a number 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.

2.1.  Path Message Extensions

   Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the
   LABEL object upstream towards the Sender.  With 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 indicated below:







Torvi, et al.            Expires April 22, 2010                 [Page 6]


Internet-Draft                  Document                    October 2009


    <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>
                           [<S2L sub-LSP descriptor list>]


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



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


   With the LABEL object defined in section 4.1 of [RFC3209]

   Please note that the 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 is needed, the
   LABEL_REQUEST will operate as described in [RFC4875], providing the
   label allocation operation in the other direction.

   With the receiver-driven usage, the Extended Tunnel ID of the P2MP
   Session object MUST NOT be set to the router ID of the Path-
   Initiator.  This is different from section 19.1.1 of [RFC4875].

2.2.  Resv Message Extensions

   Receiver-driven P2MP RSVP-TE does not need any change in the basic
   RESV message illustrated in section 6.1 of [RFC4875], as long as the
   SESSION object is using one of the C-Types defined by this document.



Torvi, et al.            Expires April 22, 2010                 [Page 7]


Internet-Draft                  Document                    October 2009


   For receiver-driven P2MP RSVP-TE, the PATH message is carrying the
   LABEL object, it is not necessary to have the LABEL object be carried
   by the RESV message anymore.  Except when bi-directional P2MP RSVP-TE
   is needed, as indicated by the new C-Type of the SESSION object.
   Within the context of bi-directional P2MP 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 here:



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

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


2.3.  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 Problem and
   Error Value sub-code of 9 for MPLS label allocation failure as
   defined in section 7.3 of [RFC3209].

2.4.  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 follow the functionality defined for the
   receiver-driven Resv message of Section 2.2 of this document.  Where
   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 or bi-directional.







Torvi, et al.            Expires April 22, 2010                 [Page 8]


Internet-Draft                  Document                    October 2009


2.5.  PathTear Message Extensions

   The receiver-driven PathTear message have the same syntax and
   utilization as the PathTear message described in [RFC4875].  With the
   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
   in the SENDER DESCRIPTOR.


3.  Broadcast Interfaces

   The receiver-driven approach interoperates with the RSVP upstream
   label allocation mechanism [I-D.ietf-mpls-rsvp-upstream].  Path
   messages originated by Path-Senders can be signaled over lower layer
   P2MP-LSP, using context-specific labels.  Path-Senders SHOULD detect
   the presence of such P2MP-LSP over broadcast interfaces for each
   Path-Receiver.  In the absence of upstream allocated P2MP-LSP, path-
   senders use normal procedures to establish LSP, please note that in
   such case user data will be replicated by upstream routers.


4.  Fast Re-Route Considerations

   Fast Reroute techniques are applicable in the context of receiver-
   driven P2MP tree structures, as stated in [RFC4875].  However, there
   are semantic differences with the conventions used in [RFC4090] and
   [RFC4875].  In a receiver-driven paradigm PLR and MP notions are
   inverted.  For example, from a signaling point of view, PLR is the
   LSR that initiates a Detour S2L sub-LSP towards a MP, and an MP
   merges paths from primary S2L sub-LSP and detour S2L sub-LSP.
   However, protection switch takes place at the MP, and data merging
   takes place in the PLR.

   Please note that this document refers to PLR and MP from the
   signaling point of view.  With PLR sending the PATH messages toward
   the MP.

   A Detour S2L Sub-LSP is signaled from the PLR using procedures
   described in Section 2 of this document, with the DETOUR object
   conveyed in the RSVP PATH message.  A MP not only merges a DETOUR
   S2Ls of primary S2Ls, but also associates the primary and DETOUR sub-
   LSPs as protected and protecting sub-LSPs respectively.

   S2L Detour protection SHOULD be used in the receiver-driven context,
   as S2L Detour protection does not require additional extensions.



Torvi, et al.            Expires April 22, 2010                 [Page 9]


Internet-Draft                  Document                    October 2009


   However, receiver-driven mechanism can easily be extended to P2P
   Bypass LSP protection.


5.  Re-Merging and Crossover

   [RFC4875] provides two ways to handle remerge and cross-over.
   However, within the context of receiver-driven P2MP, a LSR MUST allow
   remerge and cross-over of path messages of same LSP to form a P2MP
   tree, which is fundamental to the construction of a P2MP tree.
   Branches are formed when paths of two or more receivers merge to a
   common upstream path-receiver.


6.  Receiver-Driven Bidirectional LSPs

   In certain situations it is required to establish congruent
   bidirectional LSPs.  A receiver-driven bidirectional P2MP tree can be
   established using the procedures provided in [RFC5467], along with
   the procedures described in Section 2.

   In case of IP/MPLS domains, bidirectional LSPs require an additional
   RSVP object in addition to the extensions mentioned in Section 2.

   A receiver-driven congruent bidirectional P2MP LSPs is an optional
   feature that could be turned on or off through configuration.
   Bidirectional LSPs require both upstream and downstream S2L sub-LSPs
   merge.  Both upstream and downstream merging is done according to
   [RFC4875].  Upstream merging takes place when RSVP PATH messages sent
   by Path-Senders diverge, and downstream merging takes place when RSVP
   PATH messages from two or more Senders converge.




















Torvi, et al.            Expires April 22, 2010                [Page 10]


Internet-Draft                  Document                    October 2009


                 Path Terminator
               +---------+      +----------+
               |    R1   |      |    R2    |    Ingress Nodes
               +-----+---+      +----+-----+
                      \             /
                       \           /
                        \         /
                         \       /   Upstream Merge
                          \     /
                           \   /
                       +------------+
                       |      R3    |  Branch Node
                       +------------+
                            /  \
                           /    \  Downstream Merge
                          /      \
                         /        \
                        /          \
                       /            \
                      /          +---+-----+
               +----------+      |   R5    |     Egress Nodes
               |    R4    |      +---------+
               +----------+          Path Initiator
                Path Initiator



         Figure 2: Receiver-Driven BiDirectional P2MP RSVP-TE LSP


7.  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.  Additionally, the RSVP Capability object
   would have the "RD-bit" set to indicate support or non-support of
   receiver-driven P2MP-LSP.  IGP extensions to flood the additional
   node capabilities will be considered in the future.


8.  Security Implications

   A receiver MUST be authenticated before it is allowed to establish
   P2MP LSP with source, in addition to hop-by-hop security issues
   identified by in RFC 3209 and RFC 4206.  How a receiver is
   authenticated is outside the scope of this document.





Torvi, et al.            Expires April 22, 2010                [Page 11]


Internet-Draft                  Document                    October 2009


9.  IANA Considerations

   To be completed.


10.  Acknowledgements

   To be completed.


11.  References

11.1.  Normative References

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

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

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




Torvi, et al.            Expires April 22, 2010                [Page 12]


Internet-Draft                  Document                    October 2009


11.2.  Informative References

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 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.

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


Authors' Addresses

   Raveendra Torvi
   Huawei Technologies
   125 Nagog Park
   Acton, MA  01720
   USA

   Email: traveendra@huawei.com


   Kwok Ho Chan (editor)
   Huawei Technologies
   125 Nagog Park
   Acton, MA  01720
   USA

   Email: khchan@huawei.com


   Christian Jacquenet
   France Telecom
   3 avenue Francois Chateau
   35000 Rennes,
   France

   Email: christian.jacquenet@orange-ftgroup.com








Torvi, et al.            Expires April 22, 2010                [Page 13]