tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4875

 Errata 
Proposed STD
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)

Part 1 of 3, p. 1 to 15
None       Next RFC Part

Updated by:    6510


Top       ToC       Page 1 
Network Working Group                                   R. Aggarwal, Ed.
Request for Comments: 4875                              Juniper Networks
Category: Standards Track                          D. Papadimitriou, Ed.
                                                                 Alcatel
                                                        S. Yasukawa, Ed.
                                                                     NTT
                                                                May 2007


                             Extensions to
     Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
         for Point-to-Multipoint TE Label Switched Paths (LSPs)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered
   (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
   Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   networks.  The solution relies on RSVP-TE without requiring a
   multicast routing protocol in the Service Provider core.  Protocol
   elements and procedures for this solution are described.

   There can be various applications for P2MP TE LSPs such as IP
   multicast.  Specification of how such applications will use a P2MP TE
   LSP is outside the scope of this document.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................4
   3. Terminology .....................................................4
   4. Mechanism .......................................................5
      4.1. P2MP Tunnels ...............................................5
      4.2. P2MP LSP ...................................................5
      4.3. Sub-Groups .................................................5
      4.4. S2L Sub-LSPs ...............................................6
           4.4.1. Representation of an S2L Sub-LSP ....................6
           4.4.2. S2L Sub-LSPs and Path Messages ......................7
      4.5. Explicit Routing ...........................................7
   5. Path Message ....................................................9
      5.1. Path Message Format ........................................9
      5.2. Path Message Processing ...................................11
           5.2.1. Multiple Path Messages .............................11
           5.2.2. Multiple S2L Sub-LSPs in One Path Message ..........12
           5.2.3. Transit Fragmentation of Path State Information ....14
           5.2.4. Control of Branch Fate Sharing .....................15
      5.3. Grafting ..................................................15
   6. Resv Message ...................................................16
      6.1. Resv Message Format .......................................16
      6.2. Resv Message Processing ...................................17
           6.2.1. Resv Message Throttling ............................18
      6.3. Route Recording ...........................................19
           6.3.1. RRO Processing .....................................19
      6.4. Reservation Style .........................................19
   7. PathTear Message ...............................................20
      7.1. PathTear Message Format ...................................20
      7.2. Pruning ...................................................20
           7.2.1. Implicit S2L Sub-LSP Teardown ......................20
           7.2.2. Explicit S2L Sub-LSP Teardown ......................21
   8. Notify and ResvConf Messages ...................................21
      8.1. Notify Messages ...........................................21
      8.2. ResvConf Messages .........................................23
   9. Refresh Reduction ..............................................24
   10. State Management ..............................................24
      10.1. Incremental State Update .................................25
      10.2. Combining Multiple Path Messages .........................25
   11. Error Processing ..............................................26
      11.1. PathErr Messages .........................................27
      11.2. ResvErr Messages .........................................27
      11.3. Branch Failure Handling ..................................28
   12. Admin Status Change ...........................................29
   13. Label Allocation on LANs with Multiple Downstream Nodes .......29

Top      ToC       Page 3 
   14. P2MP LSP and Sub-LSP Re-Optimization ..........................29
      14.1. Make-before-Break ........................................29
      14.2. Sub-Group-Based Re-Optimization ..........................29
   15. Fast Reroute ..................................................30
      15.1. Facility Backup ..........................................31
           15.1.1. Link Protection ...................................31
           15.1.2. Node Protection ...................................31
      15.2. One-to-One Backup ........................................32
   16. Support for LSRs That Are Not P2MP Capable ....................33
   17. Reduction in Control Plane Processing with LSP Hierarchy ......34
   18. P2MP LSP Re-Merging and Cross-Over ............................35
      18.1. Procedures ...............................................36
           18.1.1. Re-Merge Procedures ...............................36
   19. New and Updated Message Objects ...............................39
      19.1. SESSION Object ...........................................39
           19.1.1. P2MP LSP Tunnel IPv4 SESSION Object ...............39
           19.1.2. P2MP LSP Tunnel IPv6 SESSION Object ...............40
      19.2. SENDER_TEMPLATE Object ...................................40
           19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object .......41
           19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object .......42
      19.3. S2L_SUB_LSP Object .......................................43
           19.3.1. S2L_SUB_LSP IPv4 Object ...........................43
           19.3.2. S2L_SUB_LSP IPv6 Object ...........................43
      19.4. FILTER_SPEC Object .......................................43
           19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object ..................43
           19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object ..................44
      19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ..............44
      19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ................44
   20. IANA Considerations ...........................................44
      20.1. New Class Numbers ........................................44
      20.2. New Class Types ..........................................44
      20.3. New Error Values .........................................45
      20.4. LSP Attributes Flags .....................................46
   21. Security Considerations .......................................46
   22. Acknowledgements ..............................................47
   23. References ....................................................47
      23.1. Normative References .....................................47
      23.2. Informative References ...................................48
   Appendix A. Example of P2MP LSP Setup .............................49
   Appendix B. Contributors ..........................................50

Top      ToC       Page 4 
1.  Introduction

   [RFC3209] defines a mechanism for setting up point-to-point (P2P)
   Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol
   Label Switching (MPLS) networks.  [RFC3473] defines extensions to
   [RFC3209] for setting up P2P TE LSPs in Generalized MPLS (GMPLS)
   networks.  However these specifications do not provide a mechanism
   for building point-to-multipoint (P2MP) TE LSPs.

   This document defines extensions to the RSVP-TE protocol ([RFC3209]
   and [RFC3473]) to support P2MP TE LSPs satisfying the set of
   requirements described in [RFC4461].

   This document relies on the semantics of the Resource Reservation
   Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs.  A P2MP
   LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.  These
   S2L sub-LSPs are set up between the ingress and egress LSRs and are
   appropriately combined by the branch LSRs using RSVP semantics to
   result in a P2MP TE LSP.  One Path message may signal one or multiple
   S2L sub-LSPs for a single P2MP LSP.  Hence the S2L sub-LSPs belonging
   to a P2MP LSP can be signaled using one Path message or split across
   multiple Path messages.

   There are various applications for P2MP TE LSPs and the signaling
   techniques described in this document can be used, sometimes in
   combination with other techniques, to support different applications.

   Specification of how applications will use P2MP TE LSPs and how the
   paths of P2MP TE LSPs are computed is outside the scope of this
   document.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Terminology

   This document uses terminologies defined in [RFC2205], [RFC3031],
   [RFC3209], [RFC3473], [RFC4090], and [RFC4461].

Top      ToC       Page 5 
4.  Mechanism

   This document describes a solution that optimizes data replication by
   allowing non-ingress nodes in the network to be replication/branch
   nodes.  A branch node is an LSR that replicates the incoming data on
   to one or more outgoing interfaces.  The solution relies on RSVP-TE
   in the network for setting up a P2MP TE LSP.

   The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and
   relying on data replication at branch nodes.  This is described
   further in the following sub-sections by describing P2MP tunnels and
   how they relate to S2L sub-LSPs.

4.1.  P2MP Tunnels

   The defining feature of a P2MP TE LSP is the action required at
   branch nodes where data replication occurs.  Incoming MPLS labeled
   data is replicated to outgoing interfaces which may use different
   labels for the data.

   A P2MP TE Tunnel comprises one or more P2MP LSPs.  A P2MP TE Tunnel
   is identified by a P2MP SESSION object.  This object contains the
   identifier of the P2MP Session, which includes the P2MP Identifier
   (P2MP ID), a tunnel Identifier (Tunnel ID), and an extended tunnel
   identifier (Extended Tunnel ID).  The P2MP ID is a four-octet number
   and is unique within the scope of the ingress LSR.

   The <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple provides an
   identifier for the set of destinations of the P2MP TE Tunnel.

   The fields of the P2MP SESSION object are identical to those of the
   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
   Address field is replaced by the P2MP ID field.  The P2MP SESSION
   object is defined in section 19.1

4.2.  P2MP LSP

   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
   ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
   and the tunnel sender address and LSP ID fields of the P2MP
   SENDER_TEMPLATE object.  The new P2MP SENDER_TEMPLATE object is
   defined in section 19.2.

4.3.  Sub-Groups

   As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages.  While the use of RSVP messages is the same,
   P2MP LSP state differs from P2P LSP state in a number of ways.  A

Top      ToC       Page 6 
   P2MP LSP comprises multiple S2L Sub-LSPs, and as a result of this, it
   may not be possible to represent full state in a single IP packet.
   It must also be possible to efficiently add and remove endpoints to
   and from P2MP TE LSPs.  An additional issue is that the P2MP LSP must
   also handle the state "re-merge" problem, see [RFC4461] and section
   18.

   These differences in P2MP state are addressed through the addition of
   a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-
   Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects.
   Taken together, the Sub-Group ID and Sub-Group Originator ID are
   referred to as the Sub-Group fields.

   The Sub-Group fields, together with the rest of the SENDER_TEMPLATE
   and SESSION objects, are used to represent a portion of a P2MP LSP's
   state.  This portion of a P2MP LSP's state refers only to signaling
   state and not data plane replication or branching.  For example, it
   is possible for a node to "branch" signaling state for a P2MP LSP,
   but to not branch the data associated with the P2MP LSP.  Typical
   applications for generation and use of multiple sub-groups are (1)
   addition of an egress and (2) semantic fragmentation to ensure that a
   Path message remains within a single IP packet.

4.4.  S2L Sub-LSPs

   A P2MP LSP is constituted of one or more S2L sub-LSPs.

4.4.1.  Representation of an S2L Sub-LSP

   An S2L sub-LSP exists within the context of a P2MP LSP.  Thus, it is
   identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are
   part of the P2MP SESSION, the tunnel sender address and LSP ID fields
   of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
   address that is part of the S2L_SUB_LSP object.  The S2L_SUB_LSP
   object is defined in section 19.3.

   An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE
   Object (SERO) is used to optionally specify the explicit route of a
   S2L sub-LSP.  Each ERO or SERO that is signaled corresponds to a
   particular S2L_SUB_LSP object.  Details of explicit route encoding
   are specified in section 4.5.  The SECONDARY_EXPLICIT_ROUTE Object is
   defined in [RFC4873], a new P2MP SECONDARY_EXPLICIT_ROUTE Object
   C-type is defined in section 19.5, and a matching
   P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in section 19.6.

Top      ToC       Page 7 
4.4.2.  S2L Sub-LSPs and Path Messages

   The mechanism in this document allows a P2MP LSP to be signaled using
   one or more Path messages.  Each Path message may signal one or more
   S2L sub-LSPs.  Support for multiple Path messages is desirable as one
   Path message may not be large enough to contain all the S2L sub-LSPs;
   and they also allow separate manipulation of sub-trees of the P2MP
   LSP.  The reason for allowing a single Path message to signal
   multiple S2L sub-LSPs is to optimize the number of control messages
   needed to set up a P2MP LSP.

4.5.  Explicit Routing

   When a Path message signals a single S2L sub-LSP (that is, the Path
   message is only targeting a single leaf in the P2MP tree), the
   EXPLICIT_ROUTE object encodes the path to the egress LSR.  The Path
   message also includes the S2L_SUB_LSP object for the S2L sub-LSP
   being signaled.  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  The absence of the ERO should be interpreted as
   requiring hop-by-hop routing for the sub-LSP based on the S2L sub-LSP
   destination address field of the S2L_SUB_LSP object.

   When a Path message signals multiple S2L sub-LSPs, the path of the
   first S2L sub-LSP to the egress LSR is encoded in the ERO.  The first
   S2L sub-LSP is the one that corresponds to the first S2L_SUB_LSP
   object in the Path message.  The S2L sub-LSPs corresponding to the
   S2L_SUB_LSP objects that follow are termed as subsequent S2L sub-
   LSPs.

   The path of each subsequent S2L sub-LSP is encoded in a
   P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO).  The format of the SERO
   is the same as an ERO (as defined in [RFC3209] and [RFC3473]).  Each
   subsequent S2L sub-LSP is represented by tuples of the form < [<P2MP
   SECONDARY_EXPLICIT_ROUTE>], <S2L_SUB_LSP> >.  An SERO for a
   particular S2L sub-LSP includes only the path from a branch LSR to
   the egress LSR of that S2L sub-LSP.  The branch MUST appear as an
   explicit hop in the ERO or some other SERO.  The absence of an SERO
   should be interpreted as requiring hop-by-hop routing for that S2L
   sub-LSP.  Note that the destination address is carried in the S2L
   sub-LSP object.  The encoding of the SERO and S2L_SUB_LSP object is
   described in detail in section 19.

   In order to avoid the potential repetition of path information for
   the parts of S2L sub-LSPs that share hops, this information is
   deduced from the explicit routes of other S2L sub-LSPs using explicit
   route compression in SEROs.

Top      ToC       Page 8 
                                    A
                                    |
                                    |
                                    B
                                    |
                                    |
                          C----D----E
                          |    |    |
                          |    |    |
                          F    G    H-------I
                               |    |\      |
                               |    | \     |
                               J    K   L   M
                               |    |   |   |
                               |    |   |   |
                               N    O   P   Q--R

                  Figure 1.  Explicit Route Compression

   Figure 1 shows a P2MP LSP with LSR A as the ingress LSR and six
   egress LSRs: (F, N, O, P, Q and R).  When all six S2L sub-LSPs are
   signaled in one Path message, let us assume that the S2L sub-LSP to
   LSR F is the first S2L sub-LSP, and the rest are subsequent S2L sub-
   LSPs.  The following encoding is one way for the ingress LSR A to
   encode the S2L sub-LSP explicit routes using compression:

      S2L sub-LSP-F:   ERO = {B, E, D, C, F},  <S2L_SUB_LSP> object-F
      S2L sub-LSP-N:   SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
      S2L sub-LSP-O:   SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
      S2L sub-LSP-P:   SERO = {H, L, P}, <S2L_SUB_LSP> object-P
      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R

   After LSR E processes the incoming Path message from LSR B it sends a
   Path message to LSR D with the S2L sub-LSP explicit routes encoded as
   follows:

      S2L sub-LSP-F:   ERO = {D, C, F},  <S2L_SUB_LSP> object-F
      S2L sub-LSP-N:   SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N

   LSR E also sends a Path message to LSR H, and the following is one
   way to encode the S2L sub-LSP explicit routes using compression:

      S2L sub-LSP-O:   ERO = {H, K, O}, <S2L_SUB_LSP> object-O
      S2L sub-LSP-P:   SERO = {H, L, P}, S2L_SUB_LSP object-P
      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R

Top      ToC       Page 9 
   After LSR H processes the incoming Path message from E, it sends a
   Path message to LSR K, LSR L, and LSR I.  The encoding for the Path
   message to LSR K is as follows:

      S2L sub-LSP-O:   ERO  = {K, O}, <S2L_SUB_LSP> object-O

   The encoding of the Path message sent by LSR H to LSR L is as
   follows:

      S2L sub-LSP-P:   ERO = {L, P}, <S2L_SUB_LSP> object-P

   The following encoding is one way for LSR H to encode the S2L sub-LSP
   explicit routes in the Path message sent to LSR I:

      S2L sub-LSP-Q:   ERO = {I, M, Q}, <S2L_SUB_LSP> object-Q
      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R

   The explicit route encodings in the Path messages sent by LSRs D and
   Q are left as an exercise for the reader.

   This compression mechanism reduces the Path message size.  It also
   reduces extra processing that can result if explicit routes are
   encoded from ingress to egress for each S2L sub-LSP.  No assumptions
   are placed on the ordering of the subsequent S2L sub-LSPs and hence
   on the ordering of the SEROs in the Path message.  All LSRs need to
   process the ERO corresponding to the first S2L sub-LSP.  An LSR needs
   to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP
   only if the first hop in the corresponding SERO is a local address of
   that LSR.  The branch LSR that is the first hop of an SERO propagates
   the corresponding S2L sub-LSP downstream.

5.  Path Message

5.1.  Path Message Format

   This section describes modifications made to the Path message format
   as specified in [RFC3209] and [RFC3473].  The Path message is
   enhanced to signal one or more S2L sub-LSPs.  This is done by
   including the S2L sub-LSP descriptor list in the Path message as
   shown below.

Top      ToC       Page 10 
   <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>]

   The following is the format of the S2L sub-LSP descriptor list.

   <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
                                     [ <S2L sub-LSP descriptor list> ]

   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
                                [ <P2MP SECONDARY_EXPLICIT_ROUTE> ]

   Each LSR MUST use the common objects in the Path message and the S2L
   sub-LSP descriptors to process each S2L sub-LSP represented by the
   S2L_SUB_LSP object and the SECONDARY-/EXPLICIT_ROUTE object
   combination.

   Per the definition of <S2L sub-LSP descriptor>, each S2L_SUB_LSP
   object MAY be followed by a corresponding SERO.  The first
   S2L_SUB_LSP object is a special case, and its explicit route is
   specified by the ERO.  Therefore, the first S2L_SUB_LSP object SHOULD
   NOT be followed by an SERO, and if one is present, it MUST be
   ignored.

   The RRO in the sender descriptor contains the upstream hops traversed
   by the Path message and applies to all the S2L sub-LSPs signaled in
   the Path message.

   An IF_ID RSVP_HOP object MUST be used on links where there is not a
   one-to-one association of a control channel to a data channel
   [RFC3471].  An RSVP_HOP object defined in [RFC2205] SHOULD be used
   otherwise.

   Path message processing is described in the next section.

Top      ToC       Page 11 
5.2.  Path Message Processing

   The ingress LSR initiates the setup of an S2L sub-LSP to each egress
   LSR that is a destination of the P2MP LSP.  Each S2L sub-LSP is
   associated with the same P2MP LSP using common P2MP SESSION object
   and <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
   object.  Hence, it can be combined with other S2L sub-LSPs to form a
   P2MP LSP.  Another S2L sub-LSP belonging to the same instance of this
   S2L sub-LSP (i.e., the same P2MP LSP) SHOULD share resources with
   this S2L sub-LSP.  The session corresponding to the P2MP TE tunnel is
   determined based on the P2MP SESSION object.  Each S2L sub-LSP is
   identified using the S2L_SUB_LSP object.  Explicit routing for the
   S2L sub-LSPs is achieved using the ERO and SEROs.

   As mentioned earlier, it is possible to signal S2L sub-LSPs for a
   given P2MP LSP in one or more Path messages, and a given Path message
   can contain one or more S2L sub-LSPs.  An LSR that supports RSVP-TE
   signaled P2MP LSPs MUST be able to receive and process multiple Path
   messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path
   message.  This implies that such an LSR MUST be able to receive and
   process all objects listed in section 19.

5.2.1.  Multiple Path Messages

   As described in section 4, either the < [<EXPLICIT_ROUTE>]
   <S2L_SUB_LSP> > or the < [<P2MP SECONDARY_EXPLICIT_ROUTE>]
   <S2L_SUB_LSP> > tuple is used to specify an S2L sub-LSP.  Multiple
   Path messages can be used to signal a P2MP LSP.  Each Path message
   can signal one or more S2L sub-LSPs.  If a Path message contains only
   one S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209]
   procedures for processing the Path message besides the S2L_SUB_LSP
   object processing described in this document.

   Processing of Path messages containing more than one S2L sub-LSP is
   described in section 5.2.2.

   An ingress LSR MAY use multiple Path messages for signaling a P2MP
   LSP.  This may be because a single Path message may not be large
   enough to signal the P2MP LSP.  Or it may be that when new leaves are
   added to the P2MP LSP, they are signaled in a new Path message.  Or
   an ingress LSR MAY choose to break the P2MP tree into separate
   manageable P2MP trees.  These trees share the same root and may share
   the trunk and certain branches.  The scope of this management
   decomposition of P2MP trees is bounded by a single tree (the P2MP
   Tree) and multiple trees with a single leaf each (S2L sub-LSPs).  Per
   [RFC4461], a P2MP LSP MUST have consistent attributes across all
   portions of a tree.  This implies that each Path message that is used
   to signal a P2MP LSP is signaled using the same signaling attributes

Top      ToC       Page 12 
   with the exception of the S2L sub-LSP descriptors and Sub-Group
   identifier.

   The resulting sub-LSPs from the different Path messages belonging to
   the same P2MP LSP SHOULD share labels and resources where they share
   hops to prevent multiple copies of the data being sent.

   In certain cases, a transit LSR may need to generate multiple Path
   messages to signal state corresponding to a single received Path
   message.  For instance ERO expansion may result in an overflow of the
   resultant Path message.  In this case, the message can be decomposed
   into multiple Path messages such that each message carries a subset
   of the X2L sub-tree carried by the incoming message.

   Multiple Path messages generated by an LSR that signal state for the
   same P2MP LSP are signaled with the same SESSION object and have the
   same <Source address, LSP-ID> in the SENDER_TEMPLATE object.  In
   order to disambiguate these Path messages, a <Sub-Group Originator
   ID, Sub- Group ID> tuple is introduced (also referred to as the Sub-
   Group fields) and encoded in the SENDER_TEMPLATE object.  Multiple
   Path messages generated by an LSR to signal state for the same P2MP
   LSP have the same Sub-Group Originator ID and have a different sub-
   Group ID.  The Sub-Group Originator ID MUST be set to the TE Router
   ID of the LSR that originates the Path message.  Cases when a transit
   LSR may change the Sub-Group Originator ID of an incoming Path
   message are described below.  The Sub-Group Originator ID is globally
   unique.  The Sub-Group ID space is specific to the Sub-Group
   Originator ID.

5.2.2.  Multiple S2L Sub-LSPs in One Path Message

   The S2L sub-LSP descriptor list allows the signaling of one or more
   S2L sub-LSPs in one Path message.  Each S2L sub-LSP descriptor
   describes a single S2L sub-LSP.

   All LSRs MUST process the ERO corresponding to the first S2L sub-LSP
   if the ERO is present.  If one or more SEROs are present, an ERO MUST
   be present.  The first S2L sub-LSP MUST be propagated in a Path
   message by each LSR along the explicit route specified by the ERO, if
   the ERO is present.  Else it MUST be propagated using hop-by-hop
   routing towards the destination identified by the S2L_SUB_LSP object.

   An LSR MUST process an S2L sub-LSP descriptor for a subsequent S2L
   sub-LSP as follows:

   If the S2L_SUB_LSP object is followed by an SERO, the LSR MUST check
   the first hop in the SERO:

Top      ToC       Page 13 
      - If the first hop of the SERO identifies a local address of the
        LSR, and the LSR is also the egress identified by the
        S2L_SUB_LSP object, the descriptor MUST NOT be propagated
        downstream, but the SERO may be used for egress control per
        [RFC4003].

      - If the first hop of the SERO identifies a local address of the
        LSR, and the LSR is not the egress as identified by the
        S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST be included
        in a Path message sent to the next-hop determined from the SERO.

      - If the first hop of the SERO is not a local address of the LSR,
        the S2L sub-LSP descriptor MUST be included in the Path message
        sent to the LSR that is the next hop to reach the first hop in
        the SERO.  This next hop is determined by using the ERO or other
        SEROs that encode the path to the SERO's first hop.

   If the S2L_SUB_LSP object is not followed by an SERO, the LSR MUST
   examine the S2L_SUB_LSP object:

      - If this LSR is the egress as identified by the S2L_SUB_LSP
        object, the S2L sub-LSP descriptor MUST NOT be propagated
        downstream.

      - If this LSR is not the egress as identified by the S2L_SUB_LSP
        object, the LSR MUST make a routing decision to determine the
        next hop towards the egress, and MUST include the S2L sub-LSP
        descriptor in a Path message sent to the next-hop towards the
        egress.  In this case, the LSR MAY insert an SERO into the S2L
        sub-LSP descriptor.

   Hence, a branch LSR MUST only propagate the relevant S2L sub-LSP
   descriptors to each downstream hop.  An S2L sub-LSP descriptor list
   that is propagated on a downstream link MUST only contain those S2L
   sub-LSPs that are routed using that hop.  This processing MAY result
   in a subsequent S2L sub-LSP in an incoming Path message becoming the
   first S2L sub-LSP in an outgoing Path message.

   Note that if one or more SEROs contain loose hops, expansion of such
   loose hops MAY result in overflowing the Path message size.  section
   5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
   across more than one Path message.

   The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
   message and applies to all the S2L sub-LSPs signaled in the Path
   message.  A transit LSR MUST append its address in an incoming RRO
   and propagate it downstream.  A branch LSR MUST form a new RRO for
   each of the outgoing Path messages by copying the RRO from the

Top      ToC       Page 14 
   incoming Path message and appending its address.  Each such updated
   RRO MUST be formed using the rules in [RFC3209] (and updated by
   [RFC3473]), as appropriate.

   If an LSR is unable to support an S2L sub-LSP in a Path message (for
   example, it is unable to route towards the destination using the
   SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP,
   and normal processing of the rest of the P2MP LSP SHOULD continue.
   The default behavior is that the remainder of the LSP is not impacted
   (that is, all other branches are allowed to set up) and the failed
   branches are reported in PathErr messages in which the
   Path_State_Removed flag MUST NOT be set.  However, the ingress LSR
   may set an LSP Integrity flag to request that if there is a setup
   failure on any branch, the entire LSP should fail to set up.  This is
   described further in sections 5.2.4 and 11.

5.2.3.  Transit Fragmentation of Path State Information

   In certain cases, a transit LSR may need to generate multiple Path
   messages to signal state corresponding to a single received Path
   message.  For instance, ERO expansion may result in an overflow of
   the resultant Path message.  RSVP [RFC2205] disallows the use of IP
   fragmentation, and thus IP fragmentation MUST be avoided in this
   case.  In order to achieve this, the multiple Path messages generated
   by the transit LSR are signaled with the Sub-Group Originator ID set
   to the TE Router ID of the transit LSR and with a distinct Sub-Group
   ID for each Path message.  Thus, each distinct Path message that is
   generated by the transit LSR for the P2MP LSP carries a distinct
   <Sub-Group Originator ID, Sub-Group ID> tuple.

   When multiple Path messages are used by an ingress or transit node,
   each Path message SHOULD be identical with the exception of the S2L
   sub-LSP related descriptor (e.g., SERO), message and hop information
   (e.g., INTEGRITY, MESSAGE_ID, and RSVP_HOP), and the Sub-Group fields
   of the SENDER_TEMPLATE objects.  Except when a make-before-break
   operation is being performed (as specified in section 14.1), the
   tunnel sender address and LSP ID fields MUST be the same in each
   message.  For transit nodes, they MUST be the same as the values in
   the received Path message.

   As described above, one case in which the Sub-Group Originator ID of
   a received Path message is changed is that of fragmentation of a Path
   message at a transit node.  Another case is when the Sub-Group
   Originator ID of a received Path message may be changed in the
   outgoing Path message and set to that of the LSR originating the Path
   message based on a local policy.  For instance, an LSR may decide to

Top      ToC       Page 15 
   always change the Sub-Group Originator ID while performing ERO
   expansion.  The Sub-Group ID MUST not be changed if the Sub-Group
   Originator ID is not changed.

5.2.4.  Control of Branch Fate Sharing

   An ingress LSR can control the behavior of an LSP if there is a
   failure during LSP setup or after an LSP has been established.  The
   default behavior is that only the branches downstream of the failure
   are not established, but the ingress may request 'LSP integrity' such
   that any failure anywhere within the LSP tree causes the entire P2MP
   LSP to fail.

   The ingress LSP may request 'LSP integrity' by setting bit 3 of the
   Attributes Flags TLV.  The bit is set if LSP integrity is required.

   It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES object
   [RFC4420].

   A branch LSR that supports the Attributes Flags TLV and recognizes
   this bit MUST support LSP integrity or reject the LSP setup with a
   PathErr message carrying the error "Routing Error"/"Unsupported LSP
   Integrity".

5.3.  Grafting

   The operation of adding egress LSR(s) to an existing P2MP LSP is
   termed grafting.  This operation allows egress nodes to join a P2MP
   LSP at different points in time.

   There are two methods to add S2L sub-LSPs to a P2MP LSP.  The first
   is to add new S2L sub-LSPs to the P2MP LSP by adding them to an
   existing Path message and refreshing the entire Path message.  Path
   message processing described in section 4 results in adding these S2L
   sub-LSPs to the P2MP LSP.  Note that as a result of adding one or
   more S2L sub-LSPs to a Path message, the ERO compression encoding may
   have to be recomputed.

   The second is to use incremental updates described in section 10.1.
   The egress LSRs can be added by signaling only the impacted S2L sub-
   LSPs in a new Path message.  Hence, other S2L sub-LSPs do not have to
   be re-signaled.


Next RFC Part