GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4875

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.

Aggarwal, et al. Standards Track [Page 1] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

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

Aggarwal, et al. Standards Track [Page 2] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 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

Aggarwal, et al. Standards Track [Page 3] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

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

Aggarwal, et al. Standards Track [Page 4] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

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

Aggarwal, et al. Standards Track [Page 5] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 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.

Aggarwal, et al. Standards Track [Page 6] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

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.

Aggarwal, et al. Standards Track [Page 7] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

                                  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

Aggarwal, et al. Standards Track [Page 8] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 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.

Aggarwal, et al. Standards Track [Page 9] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

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

Aggarwal, et al. Standards Track [Page 10] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

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

Aggarwal, et al. Standards Track [Page 11] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 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:

Aggarwal, et al. Standards Track [Page 12] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

  1. 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].
  1. 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.
  1. 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:
  1. If this LSR is the egress as identified by the S2L_SUB_LSP

object, the S2L sub-LSP descriptor MUST NOT be propagated

      downstream.
  1. 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

Aggarwal, et al. Standards Track [Page 13] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 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

Aggarwal, et al. Standards Track [Page 14] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 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.

Aggarwal, et al. Standards Track [Page 15] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

6. Resv Message

6.1. Resv Message Format

 The Resv message follows the [RFC3209] and [RFC3473] format:
 <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
                       [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                       [ <MESSAGE_ID> ]
                       <SESSION> <RSVP_HOP>
                       <TIME_VALUES>
                       [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                       [ <NOTIFY_REQUEST> ]
                       [ <ADMIN_STATUS> ]
                       [ <POLICY_DATA> ... ]
                       <STYLE> <flow descriptor list>
 <flow descriptor list> ::= <FF flow descriptor list>
                            | <SE flow descriptor>
 <FF flow descriptor list> ::= <FF flow descriptor>
                               | <FF flow descriptor list>
                               <FF flow descriptor>
 <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
 <SE filter spec list> ::= <SE filter spec>
                          | <SE filter spec list> <SE filter spec>
 The FF flow descriptor and SE filter spec are modified as follows to
 identify the S2L sub-LSPs that they correspond to:
 <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> ]
 <S2L sub-LSP flow descriptor list> ::=
                             <S2L sub-LSP flow descriptor>
                             [ <S2L sub-LSP flow descriptor list> ]
 <S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
                                   [ <P2MP_SECONDARY_RECORD_ROUTE> ]
 FILTER_SPEC is defined in section 19.4.

Aggarwal, et al. Standards Track [Page 16] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
 descriptor in section 4.1 with the difference that a
 P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
 SECONDARY_EXPLICIT_ROUTE object.  The P2MP_SECONDARY_RECORD_ROUTE
 objects follow the same compression mechanism as the P2MP
 SECONDARY_EXPLICIT_ROUTE objects.  Note that a Resv message can
 signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC
 object or different FILTER_SPEC objects.  The same label SHOULD be
 allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC
 object are the same.
 However different labels MUST be allocated if the <Sender Address,
 LSP-ID> of the FILTER_SPEC object is different, as that implies that
 the FILTER_SPEC refers to a different P2MP LSP.

6.2. Resv Message Processing

 The egress LSR MUST follow normal RSVP procedures while originating a
 Resv message.  The format of Resv messages is as defined in section
 6.1.  As usual, the Resv message carries the label allocated by the
 egress LSR.
 A node upstream of the egress node MUST allocate its own label and
 pass it upstream in the Resv message.  The node MAY combine multiple
 flow descriptors, from different Resv messages received from
 downstream, in one Resv message sent upstream.  A Resv message MUST
 NOT be sent upstream until at least one Resv message has been
 received from a downstream neighbor.  When the integrity bit is set
 in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
 upstream until all Resv messages have been received from the
 downstream neighbors.
 Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter
 spec sent upstream in a Resv message includes an S2L sub-LSP
 descriptor list.  Each such FF flow descriptor or SE filter spec for
 the same P2MP LSP (whether on one or multiple Resv messages) on the
 same Resv MUST be allocated the same label, and FF flow descriptors
 or SE filter specs SHOULD use the same label across multiple Resv
 messages.
 The node that sends the Resv message, for a P2MP LSP, upstream MUST
 associate the label assigned by this node with all the labels
 received from downstream Resv messages, for that P2MP LSP.  Note that
 a transit node may become a replication point in the future when a
 branch is attached to it.  Hence, this results in the setup of a P2MP
 LSP from the ingress LSR to the egress LSRs.

Aggarwal, et al. Standards Track [Page 17] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 The ingress LSR may need to understand when all desired egresses have
 been reached.  This is achieved using S2L_SUB_LSP objects.
 Each branch node MAY forward a single Resv message upstream for each
 received Resv message from a downstream receiver.  Note that there
 may be a large number of Resv messages at and close to the ingress
 LSR for an LSP with many receivers.  A branch LSR SHOULD combine Resv
 state from multiple receivers into a single Resv message to be sent
 upstream (see section 6.2.1).  However, note that this may result in
 overflowing the Resv message, particularly as the number of receivers
 downstream of any branch LSR increases as the LSR is closer to the
 ingress LSR.  Thus, a branch LSR MAY choose to send more than one
 Resv message upstream and partition the Resv state between the
 messages.
 When a transit node sets the Sub-Group Originator field in a Path
 message, it MUST replace the Sub-Group fields received in the
 FILTER_SPEC objects of any associated Resv messages with the value
 that it originally received in the Sub-Group fields of the Path
 message from the upstream neighbor.
 ResvErr message generation is unmodified.  Nodes propagating a
 received ResvErr message MUST use the Sub-Group field values carried
 in the corresponding Resv message.

6.2.1. Resv Message Throttling

 A branch node may have to send a revised Resv message upstream
 whenever there is a change in a Resv message for an S2L sub-LSP
 received from one of the downstream neighbors.  This can result in
 excessive Resv messages sent upstream, particularly when the S2L sub-
 LSPs are first established.  In order to mitigate this situation,
 branch nodes can limit their transmission of Resv messages.
 Specifically, in the case where the only change being sent in a Resv
 message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects
 (SRROs), the branch node SHOULD transmit the Resv message only after
 a delay time has passed since the transmission of the previous Resv
 message for the same session.  This delayed Resv message SHOULD
 include SRROs for all branches.  A suggested value for the delay time
 is thirty seconds, and delay times SHOULD generally be longer than 1
 second.  Specific mechanisms for Resv message throttling and delay
 timer settings are implementation dependent and are outside the scope
 of this document.

Aggarwal, et al. Standards Track [Page 18] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

6.3. Route Recording

6.3.1. RRO Processing

 A Resv message for a P2P LSP contains a recorded route if the ingress
 LSR requested route recording by including an RRO in the original
 Path message.  The same rule is used during signaling of P2MP LSPs.
 That is, inclusion of an RRO in the Path message used to signal one
 or more S2L sub-LSPs triggers the inclusion of a recorded route for
 each sub-LSP in the Resv message.
 The recorded route of the first S2L sub-LSP is encoded in the RRO.
 Additional recorded routes for the subsequent S2L sub-LSPs are
 encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs).  Their format
 is specified in section 19.5.  Each S2L_SUB_LSP object in a Resv is
 associated with an RRO or SRRO.  The first S2L_SUB_LSP object (for
 the first S2L sub-LSP) is associated with the RRO.  Subsequent
 S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed
 by an SRRO that contains the recorded route for that S2L sub-LSP from
 the leaf to a branch.  The ingress node can then use the RRO and
 SRROs to determine the end-to-end path for each S2L sub-LSP.

6.4. Reservation Style

 Considerations about the reservation style in a Resv message apply as
 described in [RFC3209].  The reservation style in the Resv messages
 can be either FF or SE.  All P2MP LSPs that belong to the same P2MP
 Tunnel MUST be signaled with the same reservation style.
 Irrespective of whether the reservation style is FF or SE, the S2L
 sub-LSPs that belong to the same P2MP LSP SHOULD share labels where
 they share hops.  If the S2L sub-LSPs that belong to the same P2MP
 LSP share labels then they MUST share resources.  If the reservation
 style is FF, then S2L sub-LSPs that belong to different P2MP LSPs
 MUST NOT share resources or labels.  If the reservation style is SE,
 then S2L sub-LSPs that belong to different P2MP LSPs and the same
 P2MP tunnel SHOULD share resources where they share hops, but they
 MUST not share labels in packet environments.

Aggarwal, et al. Standards Track [Page 19] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

7. PathTear Message

7.1. PathTear Message Format

 The format of the PathTear message is as follows:
 <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
                         [ [ <MESSAGE_ID_ACK> |
                             <MESSAGE_ID_NACK> ... ]
                         [ <MESSAGE_ID> ]
                         <SESSION> <RSVP_HOP>
                         [ <sender descriptor> ]
                         [ <S2L sub-LSP descriptor list> ]
 <S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
                                   [ <S2L sub-LSP descriptor list> ]
 The definition of <sender descriptor> is not changed by this
 document.

7.2. Pruning

 The operation of removing egress LSR(s) from an existing P2MP LSP is
 termed as pruning.  This operation allows egress nodes to be removed
 from a P2MP LSP at different points in time.  This section describes
 the mechanisms to perform pruning.

7.2.1. Implicit S2L Sub-LSP Teardown

 Implicit teardown uses standard RSVP message processing.  Per
 standard RSVP processing, an S2L sub-LSP may be removed from a P2MP
 TE LSP by sending a modified message for the Path or Resv message
 that previously advertised the S2L sub-LSP.  This message MUST list
 all S2L sub-LSPs that are not being removed.  When using this
 approach, a node processing a message that removes an S2L sub-LSP
 from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included
 in any other Path state associated with session before interrupting
 the data path to that egress.  All other message processing remains
 unchanged.
 When implicit teardown is used to delete one or more S2L sub-LSPs, by
 modifying a Path message, a transit LSR may have to generate a
 PathTear message downstream to delete one or more of these S2L sub-
 LSPs.  This can happen if as a result of the implicit deletion of S2L
 sub-LSP(s) there are no remaining S2L sub-LSPs to send in the
 corresponding Path message downstream.

Aggarwal, et al. Standards Track [Page 20] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

7.2.2. Explicit S2L Sub-LSP Teardown

 Explicit S2L Sub-LSP teardown relies on generating a PathTear message
 for the corresponding Path message.  The PathTear message is signaled
 with the SESSION and SENDER_TEMPLATE objects corresponding to the
 P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple
 corresponding to the Path message.  This approach SHOULD be used when
 all the egresses signaled by a Path message need to be removed from
 the P2MP LSP.  Other S2L sub-LSPs, from other sub-groups signaled
 using other Path messages, are not affected by the PathTear.
 A transit LSR that propagates the PathTear message downstream MUST
 ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
 in the PathTear message to the values used in the Path message that
 was used to set up the S2L sub-LSPs being torn down.  The transit LSR
 may need to generate multiple PathTear messages for an incoming
 PathTear message if it had performed transit fragmentation for the
 corresponding incoming Path message.
 When a P2MP LSP is removed by the ingress, a PathTear message MUST be
 generated for each Path message used to signal the P2MP LSP.

8. Notify and ResvConf Messages

8.1. Notify Messages

 The Notify Request object and Notify message are described in
 [RFC3473].  Both object and message SHALL be supported for delivery
 of upstream and downstream notification.  Processing not detailed in
 this section MUST comply to [RFC3473].
 1.  Upstream Notification
 If a transit LSR sets the Sub-Group Originator ID in the
 SENDER_TEMPLATE object of a Path message to its own address, and the
 incoming Path message carries a Notify Request object, then this LSR
 MUST change the Notify node address in the Notify Request object to
 its own address in the Path message that it sends.
 If this LSR subsequently receives a corresponding Notify message from
 a downstream LSR, then it MUST:
  1. send a Notify message upstream toward the Notify node address

that the LSR received in the Path message.

Aggarwal, et al. Standards Track [Page 21] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

  1. process the Sub-Group fields of the SENDER_TEMPLATE object on

the received Notify message, and modify their values, in the

      Notify message that is forwarded, to match the Sub-Group field
      values in the original Path message received from upstream.
 The receiver of an (upstream) Notify message MUST identify the state
 referenced in this message based on the SESSION and SENDER_TEMPLATE.
 2.  Downstream Notification
 A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
 object(s) of a Resv message to the value that was received in the
 corresponding Path message.  If the incoming Resv message carries a
 Notify Request object, then:
  1. If there is at least another incoming Resv message that carries

a Notify Request object, and the LSR merges these Resv messages

      into a single Resv message that is sent upstream, the LSR MUST
      set the Notify node address in the Notify Request object to its
      Router ID.
  1. Else if the LSR sets the Sub-Group Originator ID (in the

outgoing Path message that corresponds to the received Resv

      message) to its own address, the LSR MUST set the Notify node
      address in the Notify Request object to its Router ID.
  1. Else the LSR MUST propagate the Notify Request object unchanged,

in the Resv message that it sends upstream.

 If this LSR subsequently receives a corresponding Notify message from
 an upstream LSR, then it MUST:
  1. process the Sub-Group fields of the FILTER_SPEC object in the

received Notify message, and modify their values, in the Notify

      message that is forwarded, to match the Sub-Group field values
      in the original Path message sent downstream by this LSR.
  1. send a Notify message downstream toward the Notify node address

that the LSR received in the Resv message.

 The receiver of a (downstream) Notify message MUST identify the state
 referenced in the message based on the SESSION and FILTER_SPEC
 objects.
 The consequence of these rules for a P2MP LSP is that an upstream
 Notify message generated on a branch will result in a Notify being
 delivered to the upstream Notify node address.  The receiver of the
 Notify message MUST NOT assume that the Notify message applies to all

Aggarwal, et al. Standards Track [Page 22] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 downstream egresses, but MUST examine the information in the message
 to determine to which egresses the message applies.
 Downstream Notify messages MUST be replicated at branch LSRs
 according to the Notify Request objects received on Resv messages.
 Some downstream branches might not request Notify messages, but all
 that have requested Notify messages MUST receive them.

8.2. ResvConf Messages

 ResvConf messages are described in [RFC2205].  ResvConf processing in
 [RFC3473] and [RFC3209] is taken directly from [RFC2205].  An egress
 LSR MAY include a RESV_CONFIRM object that contains the egress LSR's
 address.  The object and message SHALL be supported for the
 confirmation of receipt of the Resv message in P2MP TE LSPs.
 Processing not detailed in this section MUST comply to [RFC2205].
 A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
 object(s) of a Resv message to the value that was received in the
 corresponding Path message.  If any of the incoming Resv messages
 corresponding to a single Path message carry a RESV_CONFIRM object,
 then the LSR MUST include a RESV_CONFIRM object in the corresponding
 Resv message that it sends upstream.  If the Sub-Group Originator ID
 is its own address, then it MUST set the receiver address in the
 RESV_CONFIRM object to this address, else it MUST propagate the
 object unchanged.
 A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
 object(s) of a Resv message to the value that was received in the
 corresponding Path message.  If an incoming Resv message
 corresponding to a single Path message carries a RESV_CONFIRM object,
 then the LSR MUST include a RESV_CONFIRM object in the corresponding
 Resv message that it sends upstream and:
  1. If there is at least another incoming Resv message that carries

a RESV_CONFIRM object, and the LSR merges these Resv messages

      into a single Resv message that is sent upstream, the LSR MUST
      set the receiver address in the RESV_CONFIRM object to its
      Router ID.
  1. If the LSR sets the Sub-Group Originator ID (in the outgoing

Path message that corresponds to the received Resv message) to

      its own address, the LSR MUST set the receiver address in the
      RESV_CONFIRM object to its Router ID.
  1. Else the LSR MUST propagate the RESV_CONFIRM object unchanged,

in the Resv message that it sends upstream.

Aggarwal, et al. Standards Track [Page 23] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 If this LSR subsequently receives a corresponding ResvConf message
 from an upstream LSR, then it MUST:
  1. process the Sub-Group fields of the FILTER_SPEC object in the

received ResvConf message, and modify their values, in the

      ResvConf message that is forwarded, to match the Sub-Group field
      values in the original Path message sent downstream by this LSR.
  1. send a ResvConf message downstream toward the receiver address

that the LSR received in the RESV_CONFIRM object in the Resv

      message.
 The receiver of a ResvConf message MUST identify the state referenced
 in this message based on the SESSION and FILTER_SPEC objects.
 The consequence of these rules for a P2MP LSP is that a ResvConf
 message generated at the ingress will result in a ResvConf message
 being delivered to the branch and then to the receiver address in the
 original RESV_CONFIRM object.  The receiver of a ResvConf message
 MUST NOT assume that the ResvConf message should be sent to all
 downstream egresses, but it MUST replicate the message according to
 the RESV_CONFIRM objects received in Resv messages.  Some downstream
 branches might not request ResvConf messages, and ResvConf messages
 SHOULD NOT be sent on these branches.  All downstream branches that
 requested ResvConf messages MUST be sent such a message.

9. Refresh Reduction

 The refresh reduction procedures described in [RFC2961] are equally
 applicable to P2MP LSPs described in this document.  Refresh
 reduction applies to individual messages and the state they
 install/maintain, and that continues to be the case for P2MP LSPs.

10. State Management

 State signaled by a P2MP Path message is identified by a local
 implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID>
 tuple as part of the SESSION object and the <Tunnel Sender Address,
 LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the
 SENDER_TEMPLATE object.
 Additional information signaled in the Path/Resv message is part of
 the state created by a local implementation.  This includes PHOP/NHOP
 and SENDER_TSPEC/FILTER_SPEC objects.

Aggarwal, et al. Standards Track [Page 24] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

10.1. Incremental State Update

 RSVP (as defined in [RFC2205] and as extended by RSVP-TE [RFC3209]
 and GMPLS [RFC3473]) uses the same basic approach to state
 communication and synchronization -- namely, full state is sent in
 each state advertisement message.  Per [RFC2205], Path and Resv
 messages are idempotent.  Also, [RFC2961] categorizes RSVP messages
 into two types (trigger and refresh messages) and improves RSVP
 message handling and scaling of state refreshes, but does not modify
 the full state advertisement nature of Path and Resv messages.  The
 full state advertisement nature of Path and Resv messages has many
 benefits, but also has some drawbacks.  One notable drawback is when
 an incremental modification is being made to a previously advertised
 state.  In this case, there is the message overhead of sending the
 full state and the cost of processing it.  It is desirable to
 overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP
 by incrementally updating the existing state.
 It is possible to use the procedures described in this document to
 allow S2L sub-LSPs to be incrementally added to or deleted from the
 P2MP LSP by allowing a Path or a PathTear message to incrementally
 change the existing P2MP LSP Path state.
 As described in section 5.2, multiple Path messages can be used to
 signal a P2MP LSP.  The Path messages are distinguished by different
 <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE
 object.  In order to perform incremental S2L sub-LSP state addition,
 a separate Path message with a new Sub-Group ID is used to add the
 new S2L sub-LSPs, by the ingress LSR.  The Sub-Group Originator ID
 MUST be set to the TE Router ID [RFC3477] of the node that sets the
 Sub-Group ID.
 This maintains the idempotent nature of RSVP Path messages, avoids
 keeping track of individual S2L sub-LSP state expiration, and
 provides the ability to perform incremental P2MP LSP state updates.

10.2. Combining Multiple Path Messages

 There is a tradeoff between the number of Path messages used by the
 ingress to maintain the P2MP LSP and the processing imposed by full
 state messages when adding S2L sub-LSPs to an existing Path message.
 It is possible to combine S2L sub-LSPs previously advertised in
 different Path messages in a single Path message in order to reduce
 the number of Path messages needed to maintain the P2MP LSP.  This
 can also be done by a transit node that performed fragmentation and
 that at a later point is able to combine multiple Path messages that
 it generated into a single Path message.  This may happen when one or
 more S2L sub-LSPs are pruned from the existing Path states.

Aggarwal, et al. Standards Track [Page 25] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 The new Path message is signaled by the node that is combining
 multiple Path messages with all the S2L sub-LSPs that are being
 combined in a single Path message.  This Path message MAY contain new
 Sub-Group ID field values.  When a new Path and Resv message that is
 signaled for an existing S2L sub-LSP is received by a transit LSR,
 state including the new instance of the S2L sub-LSP is created.
 The S2L sub-LSP SHOULD continue to be advertised in both the old and
 new Path messages until a Resv message listing the S2L sub-LSP and
 corresponding to the new Path message is received by the combining
 node.  Hence, until this point, state for the S2L sub-LSP SHOULD be
 maintained as part of the Path state for both the old and the new
 Path message (see section 3.1.3 of [RFC2205]).  At that point the S2L
 sub-LSP SHOULD be deleted from the old Path state using the
 procedures of section 7.
 A Path message with a Sub-Group_ID(n) may signal a set of S2L sub-
 LSPs that belong partially or entirely to an already existing Sub-
 Group_ID(i), or a strictly non-overlapping new set of S2L sub-LSPs.
 A newly received Path message that matches SESSION object and Sender
 Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
 state carrying the same or different Sub-Group_ID, referred to Sub-
 Group_ID(n) is processed as follows:
 1) If Sub-Group_ID(i) = Sub-Group_ID(n), then S2L Sub-LSPs that are
    in both Sub-Group_ID(i) and Sub-Group_ID(n) are refreshed.  New
    S2L Sub-LSPs are added to Sub-Group_ID(i) Path state and S2L Sub-
    LSPs that are in Sub-Group_ID(i) but not in Sub-Group_ID(n) are
    deleted from the Sub-Group_ID(i) Path state.
 2) If Sub-Group_ID(i) != Sub-Group_ID(n), then a new Sub-Group_ID(n)
    Path state is created for S2L Sub-LSPs signaled by Sub-
    Group_ID(n).  S2L Sub-LSPs in existing Sub-Group_IDs(i) Path state
    (that are or are not in the newly received Path message Sub-
    Group_ID(n)) are left unmodified (see above).

11. Error Processing

 PathErr and ResvErr messages are processed as per RSVP-TE procedures.
 Note that an LSR, on receiving a PathErr/ResvErr message for a
 particular S2L sub-LSP, changes the state only for that S2L sub-LSP.
 Hence other S2L sub-LSPs are not impacted.  If the ingress node
 requests 'LSP integrity', an error reported on a branch of a P2MP TE
 LSP for a particular S2L sub-LSP may change the state of any other
 S2L sub-LSP of the same P2MP TE LSP.  This is explained further in
 section 11.3.

Aggarwal, et al. Standards Track [Page 26] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

11.1. PathErr Messages

 The PathErr message will include one or more S2L_SUB_LSP objects.
 The resulting modified format for a PathErr message is:
 <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
                           [ [<MESSAGE_ID_ACK> |
                              <MESSAGE_ID_NACK>] ... ]
                           [ <MESSAGE_ID> ]
                           <SESSION> <ERROR_SPEC>
                           [ <ACCEPTABLE_LABEL_SET> ... ]
                           [ <POLICY_DATA> ... ]
                           <sender descriptor>
                           [ <S2L sub-LSP descriptor list> ]
 PathErr message generation is unmodified, but nodes that set the
 Sub-Group Originator field and propagate a received PathErr message
 upstream MUST replace the Sub-Group fields received in the PathErr
 message with the value that was received in the Sub-Group fields of
 the Path message from the upstream neighbor.  Note the receiver of a
 PathErr message is able to identify the errored outgoing Path
 message, and outgoing interface, based on the Sub-Group fields
 received in the PathErr message.  The S2L sub-LSP descriptor list is
 defined in section 5.1.

11.2. ResvErr Messages

 The ResvErr message will include one or more S2L_SUB_LSP objects.
 The resulting modified format for a ResvErr Message is:
 <ResvErr Message> ::=    <Common Header> [ <INTEGRITY> ]
                           [ [<MESSAGE_ID_ACK> |
                              <MESSAGE_ID_NACK>] ... ]
                           [ <MESSAGE_ID> ]
                           <SESSION> <RSVP_HOP>
                           <ERROR_SPEC> [ <SCOPE> ]
                           [ <ACCEPTABLE_LABEL_SET> ... ]
                           [ <POLICY_DATA> ... ]
                           <STYLE> <flow descriptor list>
 ResvErr message generation is unmodified, but nodes that set the
 Sub-Group Originator field and propagate a received ResvErr message
 downstream MUST replace the Sub-Group fields received in the ResvErr
 message with the value that was set in the Sub-Group fields of the
 Path message sent to the downstream neighbor.  Note the receiver of a
 ResvErr message is able to identify the errored outgoing Resv

Aggarwal, et al. Standards Track [Page 27] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 message, and outgoing interface, based on the Sub-Group fields
 received in the ResvErr message.  The flow descriptor list is defined
 in section 6.1.

11.3. Branch Failure Handling

 During setup and during normal operation, PathErr messages may be
 received at a branch node.  In all cases, a received PathErr message
 is first processed per standard processing rules.  That is, the
 PathErr message is sent hop-by-hop to the ingress/branch LSR for that
 Path message.  Intermediate nodes until this ingress/branch LSR MAY
 inspect this message but take no action upon it.  The behavior of a
 branch LSR that generates a PathErr message is under the control of
 the ingress LSR.
 The default behavior is that the PathErr message does not have the
 Path_State_Removed flag set.  However, if the ingress LSR has set the
 LSP integrity flag on the Path message (see LSP_REQUIRED_ATTRIBUTEs
 object in section 5.2.4), and if the Path_State_Removed flag is
 supported, the LSR generating a PathErr to report the failure of a
 branch of the P2MP LSP SHOULD set the Path_State_Removed flag.
 A branch LSR that receives a PathErr message during LSP setup with
 the Path_State_Removed flag set MUST act according to the wishes of
 the ingress LSR.  The default behavior is that the branch LSR clears
 the Path_State_Removed flag on the PathErr and sends it further
 upstream.  It does not tear any other branches of the LSP.  However,
 if the LSP integrity flag is set on the Path message, the branch LSR
 MUST send PathTear on all other downstream branches and send the
 PathErr message upstream with the Path_State_Removed flag set.
 A branch LSR that receives a PathErr message with the
 Path_State_Removed flag clear MUST act according to the wishes of the
 ingress LSR.  The default behavior is that the branch LSR forwards
 the PathErr upstream and takes no further action.  However, if the
 LSP integrity flag is set on the Path message, the branch LSR MUST
 send PathTear on all downstream branches and send the PathErr
 upstream with the Path_State_Removed flag set (per [RFC3473]).
 In all cases, the PathErr message forwarded by a branch LSR MUST
 contain the S2L sub-LSP identification and explicit routes of all
 branches that are reported by received PathErr messages and all
 branches that are explicitly torn by the branch LSR.

Aggarwal, et al. Standards Track [Page 28] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

12. Admin Status Change

 A branch node that receives an ADMIN_STATUS object processes it
 normally and also relays the ADMIN_STATUS object in a Path on every
 branch.  All Path messages may be concurrently sent to the downstream
 neighbors.
 Downstream nodes process the change in the ADMIN_STATUS object per
 [RFC3473], including generation of Resv messages.  When the last
 received upstream ADMIN_STATUS object had the R bit set, branch nodes
 wait for a Resv message with a matching ADMIN_STATUS object to be
 received (or a corresponding PathErr or ResvTear message) on all
 branches before relaying a corresponding Resv message upstream.

13. Label Allocation on LANs with Multiple Downstream Nodes

 A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one
 copy of the data traffic per downstream LSR connected on that LAN for
 that P2MP LSP.  Procedures for preventing MPLS labeled traffic
 replication in such a case is beyond the scope of this document.

14. P2MP LSP and Sub-LSP Re-Optimization

 It is possible to change the path used by P2MP LSPs to reach the
 destinations of the P2MP tunnel.  There are two methods that can be
 used to accomplish this.  The first is make-before-break, defined in
 [RFC3209], and the second uses the sub-groups defined above.

14.1. Make-before-Break

 In this case, all the S2L sub-LSPs are signaled with a different LSP
 ID by the ingress LSR and follow the make-before-break procedure
 defined in [RFC3209].  Thus, a new P2MP LSP is established.  Each S2L
 sub-LSP is signaled with a different LSP ID, corresponding to the new
 P2MP LSP.  After moving traffic to the new P2MP LSP, the ingress can
 tear down the old P2MP LSP.  This procedure can be used to re-
 optimize the path of the entire P2MP LSP or the paths to a subset of
 the destinations of the P2MP LSP.  When modifying just a portion of
 the P2MP LSP, this approach requires the entire P2MP LSP to be re-
 signaled.

14.2. Sub-Group-Based Re-Optimization

 Any node may initiate re-optimization of a set of S2L sub-LSPs by
 using incremental state update and then, optionally, combining
 multiple path messages.

Aggarwal, et al. Standards Track [Page 29] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 To alter the path taken by a particular set of S2L sub-LSPs, the node
 initiating the path change initiates one or more separate Path
 messages for the same P2MP LSP, each with a new sub-Group ID.  The
 generation of these Path messages, each with one or more S2L sub-
 LSPs, follows procedures in section 5.2.  As is the case in section
 10.2, a particular egress continues to be advertised in both the old
 and new Path messages until a Resv message listing the egress and
 corresponding to the new Path message is received by the re-
 optimizing node.  At that point, the egress SHOULD be deleted from
 the old Path state using the procedures of section 7.  Sub-tree re-
 optimization is then completed.
 Sub-Group-based re-optimization may result in transient data
 duplication as the new Path messages for a set of S2L sub-LSPs may
 transit one or more nodes with the old Path state for the same set of
 S2L sub-LSPs.
 As is always the case, a node may choose to combine multiple path
 messages as described in section 10.2.

15. Fast Reroute

 [RFC4090] extensions can be used to perform fast reroute for the
 mechanism described in this document when applied within packet
 networks.  GMPLS introduces other protection techniques that can be
 applied to packet and non-packet environments [RFC4873], but which
 are not discussed further in this document.  This section only
 applies to LSRs that support [RFC4090].
 This section uses terminology defined in [RFC4090], and fast reroute
 procedures defined in [RFC4090] MUST be followed unless specified
 below.  The head-end and transit LSRs MUST follow the
 SESSION_ATTRIBUTE and FAST_REROUTE object processing as specified in
 [RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP.  Each
 S2L sub-LSP of a P2MP LSP MUST have the same protection
 characteristics.  The RRO processing MUST apply to SRRO as well
 unless modified below.
 The sections that follow describe how fast reroute may be applied to
 P2MP MPLS TE LSPs in all of the principal operational scenarios.
 This document does not describe the detailed processing steps for
 every imaginable usage case, and they may be described in future
 documents, as needed.

Aggarwal, et al. Standards Track [Page 30] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

15.1. Facility Backup

 Facility backup can be used for link or node protection of LSRs on
 the path of a P2MP LSP.  The downstream labels MUST be learned by the
 Point of Local Repair (PLR), as specified in [RFC4090], from the
 label corresponding to the S2L sub-LSP in the RESV message.
 Processing of SEROs signaled in a backup tunnel MUST follow backup
 tunnel ERO processing described in [RFC4090].

15.1.1. Link Protection

 If link protection is desired, a bypass tunnel MUST be used to
 protect the link between the PLR and next-hop.  Thus all S2L sub-LSPs
 that use the link SHOULD be protected in the event of link failure.
 Note that all such S2L sub-LSPs belonging to a particular instance of
 a P2MP tunnel SHOULD share the same outgoing label on the link
 between the PLR and the next-hop as per section 5.2.1.  This is the
 P2MP LSP label on the link.  Label stacking is used to send data for
 each P2MP LSP into the bypass tunnel.  The inner label is the P2MP
 LSP label allocated by the next-hop.
 During failure, Path messages for each S2L sub-LSP that is affected,
 MUST be sent to the Merge Point (MP) by the PLR.  It is RECOMMENDED
 that the PLR uses the sender template-specific method to identify
 these Path messages.  Hence, the PLR will set the source address in
 the sender template to a local PLR address.
 The MP MUST use the LSP-ID to identify the corresponding S2L sub-
 LSPs.  The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group
 ID> tuple while identifying the corresponding S2L sub-LSPs.  In order
 to further process an S2L sub-LSP the MP MUST determine the protected
 S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.

15.1.2. Node Protection

 If node protection is desired the PLR SHOULD use one or more P2P
 bypass tunnels to protect the set of S2L sub-LSPs that transit the
 protected node.  Each of these P2P bypass tunnels MUST intersect the
 path of the S2L sub-LSPs that they protect on an LSR that is
 downstream from the protected node.  This constrains the set of S2L
 sub-LSPs being backed- up via that bypass tunnel to those S2L sub-
 LSPs that pass through a common downstream MP.  This MP is the
 destination of the bypass tunnel.  When the PLR forwards incoming
 data for a P2MP LSP into the bypass tunnel, the outer label is the
 bypass tunnel label and the inner label is the label allocated by the
 MP to the set of S2L sub-LSPs belonging to that P2MP LSP.

Aggarwal, et al. Standards Track [Page 31] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 After detecting failure of the protected node the PLR MUST send one
 or more Path messages for all protected S2L sub-LSPs to the MP of the
 protected S2L sub-LSP.  It is RECOMMENDED that the PLR use the sender
 template specific method to identify these Path messages.  Hence the
 PLR will set the source address in the sender template to a local PLR
 address.  The MP MUST use the LSP-ID to identify the corresponding
 S2L sub-LSPs.  The MP MUST NOT use the <Sub-Group Originator ID,
 Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs
 because the Sub-Group Originator ID might be changed by some LSR that
 is bypassed by the bypass tunnel.  In order to further process an S2L
 sub-LSP the MP MUST determine the protected S2L sub-LSP using the
 LSP-ID and the S2L_SUB_LSP object.
 Note that node protection MAY require the PLR to be branch capable in
 the data plane, as multiple bypass tunnels may be required to back up
 the set of S2L sub-LSPs passing through the protected node.  If the
 PLR is not branch capable, the node protection mechanism described
 here is applicable to only those cases where all the S2L sub-LSPs
 passing through the protected node also pass through a single MP that
 is downstream from the protected node.  A PLR MUST set the Node
 protection flag in the RRO/SRRO as specified in [RFC4090].  If a PLR
 is not branch capable, and one or more S2L sub-LSPs are added to a
 P2MP tree, and these S2L sub-LSPs do not transit the existing MP
 downstream of the protected node, then the PLR MUST reset this flag.
 It is to be noted that procedures in this section require P2P bypass
 tunnels.  Procedures for using P2MP bypass tunnels are for further
 study.

15.2. One-to-One Backup

 One-to-one backup, as described in [RFC4090], can be used to protect
 a particular S2L sub-LSP against link and next-hop failure.
 Protection may be used for one or more S2L sub-LSPs between the PLR
 and the next-hop.  All the S2L sub-LSPs corresponding to the same
 instance of the P2MP tunnel between the PLR and the next-hop SHOULD
 share the same P2MP LSP label, as per section 5.2.1.  All such S2L
 sub-LSPs belonging to a P2MP LSP MUST be protected.
 The backup S2L sub-LSPs may traverse different next-hops at the PLR.
 Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the
 PLR, may change once protection is triggered.  Consider a P2MP LSP
 that is using a single next-hop and label between the PLR and the
 next-hop of the PLR.  This may no longer be the case once protection
 is triggered.  This MAY require a PLR to be branch capable in the
 data plane.  If the PLR is not branch capable, the one-to-one backup
 mechanisms described here are only applicable to those cases where
 all the backup S2L sub-LSPs pass through the same next-hop downstream

Aggarwal, et al. Standards Track [Page 32] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 of the PLR.  Procedures for one-to-one backup when a PLR is not
 branch capable and when all the backup S2L sub-LSPs do not pass
 through the same downstream next-hop are for further study.
 It is recommended that the path-specific method be used to identify a
 backup S2L sub-LSP.  Hence, the DETOUR object SHOULD be inserted in
 the backup Path message.  A backup S2L sub-LSP MUST be treated as
 belonging to a different P2MP tunnel instance than the one specified
 by the LSP-ID.  Furthermore multiple backup S2L sub-LSPs MUST be
 treated as part of the same P2MP tunnel instance if they have the
 same LSP-ID and the same DETOUR objects.  Note that, as specified in
 section 4, S2L sub-LSPs between different P2MP tunnel instances use
 different labels.
 If there is only one S2L sub-LSP in the Path message, the DETOUR
 object applies to that sub-LSP.  If there are multiple S2L sub-LSPs
 in the Path message, the DETOUR object applies to all the S2L sub-
 LSPs.

16. Support for LSRs That Are Not P2MP Capable

 It may be that some LSRs in a network are capable of processing the
 P2MP extensions described in this document, but do not support P2MP
 branching in the data plane.  If such an LSR is requested to become a
 branch LSR by a received Path message, it MUST respond with a PathErr
 message carrying the Error Code "Routing Error" and Error Value
 "Unable to Branch".
 It is also conceivable that some LSRs, in a network deploying P2MP
 capability, may not support the extensions described in this
 document.  If a Path message for the establishment of a P2MP LSP
 reaches such an LSR, it will reject it with a PathErr because it will
 not recognize the C-Type of the P2MP SESSION object.
 LSRs that do not support the P2MP extensions in this document may be
 included as transit LSRs by the use of LSP stitching [LSP-STITCH] and
 LSP hierarchy [RFC4206].  Note that LSRs that are required to play
 any other role in the network (ingress, branch or egress) MUST
 support the extensions defined in this document.
 The use of LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs
 to be built in such an environment.  A P2P LSP segment is signaled
 from the last P2MP-capable hop that is upstream of a legacy LSR to
 the first P2MP-capable hop that is downstream of it.  This assumes
 that intermediate legacy LSRs are transit LSRs: they cannot act as
 P2MP branch points.  Transit LSRs along this LSP segment do not
 process control plane messages associated with the P2MP LSP.
 Furthermore, these transit LSRs also do not need to have P2MP data

Aggarwal, et al. Standards Track [Page 33] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 plane capabilities as they only need to process data belonging to the
 P2P LSP segment.  Hence, these transit LSRs do not need to support
 P2MP MPLS.  This P2P LSP segment is stitched to the incoming P2MP
 LSP.  After the P2P LSP segment is established, the P2MP Path message
 is sent to the next P2MP-capable LSR as a directed Path message.  The
 next P2MP-capable LSR stitches the P2P LSP segment to the outgoing
 P2MP LSP.
 In packet networks, the S2L sub-LSPs may be nested inside the outer
 P2P LSP.  Hence, label stacking can be used to enable use of the same
 LSP segment for multiple P2MP LSPs.  Stitching and nesting
 considerations and procedures are described further in [LSP-STITCH]
 and [RFC4206].
 There maybe overhead for an operator to configure the P2P LSP
 segments in advance, when it is desired to support legacy LSRs.  It
 may be desirable to do this dynamically.  The ingress can use IGP
 extensions to determine P2MP-capable LSRs [TE-NODE-CAP].  It can use
 this information to compute S2L sub-LSP paths such that they avoid
 legacy non-P2MP-capable LSRs.  The explicit route object of an S2L
 sub-LSP path may contain loose hops if there are legacy LSRs along
 the path.  The corresponding explicit route contains a list of
 objects up to the P2MP-capable LSR that is adjacent to a legacy LSR
 followed by a loose object with the address of the next P2MP-capable
 LSR.  The P2MP-capable LSR expands the loose hop using its Traffic
 Engineering Database (TED).  When doing this it determines that the
 loose hop expansion requires a P2P LSP to tunnel through the legacy
 LSR.  If such a P2P LSP exists, it uses that P2P LSP.  Else it
 establishes the P2P LSP.  The P2MP Path message is sent to the next
 P2MP-capable LSR using non-adjacent signaling.
 The P2MP-capable LSR that initiates the non-adjacent signaling
 message to the next P2MP-capable LSR may have to employ a fast
 detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-
 capable LSR.  This may be needed for the directed Path message head-
 end to use node protection fast reroute when the protected node is
 the directed Path message tail.
 Note that legacy LSRs along a P2P LSP segment cannot perform node
 protection of the tail of the P2P LSP segment.

17. Reduction in Control Plane Processing with LSP Hierarchy

 It is possible to take advantage of LSP hierarchy [RFC4206] while
 setting up P2MP LSP, as described in the previous section, to reduce
 control plane processing along transit LSRs that are P2MP capable.
 This is applicable only in environments where LSP hierarchy can be
 used.  Transit LSRs along a P2P LSP segment, being used by a P2MP

Aggarwal, et al. Standards Track [Page 34] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 LSP, do not process control plane messages associated with the P2MP
 LSP.  In fact, they are not aware of these messages as they are
 tunneled over the P2P LSP segment.  This reduces the amount of
 control plane processing required on these transit LSRs.
 Note that the P2P LSPs can be set up dynamically as described in the
 previous section or preconfigured.  For example, in Figure 2 in
 section 24, PE1 can set up a P2P LSP to P1 and use that as a LSP
 segment.  The Path messages for PE3 and PE4 can now be tunneled over
 the LSP segment.  Thus, P3 is not aware of the P2MP LSP and does not
 process the P2MP control messages.

18. P2MP LSP Re-Merging and Cross-Over

 This section details the procedures for detecting and dealing with
 re-merge and cross-over.  The term "re-merge" refers to the case of
 an ingress or transit node that creates a branch of a P2MP LSP, a re-
 merge branch, that intersects the P2MP LSP at another node farther
 down the tree.  This may occur due to such events as an error in path
 calculation, an error in manual configuration, or network topology
 changes during the establishment of the P2MP LSP.  If the procedures
 detailed in this section are not followed, data duplication will
 result.
 The term "cross-over" refers to the case of an ingress or transit
 node that creates a branch of a P2MP LSP, a cross-over branch, that
 intersects the P2MP LSP at another node farther down the tree.  It is
 unlike re-merge in that, at the intersecting node, the cross-over
 branch has a different outgoing interface as well as a different
 incoming interface.  This may be necessary in certain combinations of
 topology and technology; e.g., in a transparent optical network in
 which different wavelengths are required to reach different leaf
 nodes.
 Normally, a P2MP LSP has a single incoming interface on which all of
 the data for the P2MP LSP is received.  The incoming interface is
 identified by the IF_ID RSVP_HOP object, if present, and by the
 interface over which the Path message was received if the IF_ID
 RSVP_HOP object is not present.  However, in the case of dynamic LSP
 re-routing, the incoming interface may change.
 Similarly, in both the re-merge and cross-over cases, a node will
 receive a Path message for a given P2MP LSP identifying a different
 incoming interface for the data, and the node needs to be able to
 distinguish between dynamic LSP re-routing and the re- merge/cross-
 over cases.

Aggarwal, et al. Standards Track [Page 35] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 Make-before-break represents yet another similar but different case,
 in that the incoming interface associated with the make-before-break
 P2MP LSP may be different than that associated with the original P2MP
 LSP.  However, the two P2MP LSPs will be treated as distinct (but
 related) LSPs because they will have different LSP ID field values in
 their SENDER_TEMPLATE objects.

18.1. Procedures

 When a node receives a Path message, it MUST check whether it has
 matching state for the P2MP LSP.  Matching state is identified by
 comparing the SESSION and SENDER_TEMPLATE objects in the received
 Path message with the SESSION and SENDER_TEMPLATE objects of each
 locally maintained P2MP LSP Path state.  The P2MP ID, Tunnel ID, and
 Extended Tunnel ID in the SESSION object and the sender address and
 LSP ID in the SENDER_TEMPLATE object are used for the comparison.  If
 the node has matching state, and the incoming interface for the
 received Path message is different than the incoming interface of the
 matching P2MP LSP Path state, then the node MUST determine whether it
 is dealing with dynamic LSP rerouting or re-merge/cross-over.
 Dynamic LSP rerouting is identified by checking whether there is any
 intersection between the set of S2L_SUB_LSP objects associated with
 the matching P2MP LSP Path state and the set of S2L_SUB_LSP objects
 in the received Path message.  If there is any intersection, then
 dynamic re-routing has occurred.  If there is no intersection between
 the two sets of S2L_SUB_LSP objects, then either re-merge or cross-
 over has occurred.  (Note that in the case of dynamic LSP rerouting,
 Path messages for the non-intersecting members of set of S2L_SUB_LSPs
 associated with the matching P2MP LSP Path state will be received
 subsequently on the new incoming interface.)
 In order to identify the re-merge case, the node processing the
 received Path message MUST identify the outgoing interfaces
 associated with the matching P2MP Path state.  Re-merge has occurred
 if there is any intersection between the set of outgoing interfaces
 associated with the matching P2MP LSP Path state and the set of
 outgoing interfaces in the received Path message.

18.1.1. Re-Merge Procedures

 There are two approaches to dealing with the re-merge case.  In the
 first, the node detecting the re-merge case, i.e., the re-merge node,
 allows the re-merge case to persist, but data from all but one
 incoming interface is dropped at the re-merge node.  In the second,
 the re-merge node initiates the removal of the re-merge branch(es)
 via signaling.  Which approach is used is a matter of local policy.

Aggarwal, et al. Standards Track [Page 36] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 A node MUST support both approaches and MUST allow user configuration
 of which approach is to be used.
 When configured to allow a re-merge case to persist, the re-merge
 node MUST validate consistency between the objects included in the
 received Path message and the matching P2MP LSP Path state.  Any
 inconsistencies MUST result in a PathErr message sent to the previous
 hop of the received Path message.  The Error Code is set to "Routing
 Problem", and the Error Value is set to "P2MP Re-Merge Parameter
 Mismatch".
 If there are no inconsistencies, the node logically merges, from the
 downstream perspective, the control state of incoming Path message
 with the matching P2MP LSP Path state.  Specifically, procedures
 related to processing of messages received from upstream MUST NOT be
 modified from the upstream perspective; this includes processing
 related to refresh and state timeout.  In addition to the standard
 upstream related procedures, the node MUST ensure that each object
 received from upstream is appropriately represented within the set of
 Path messages sent downstream.  For example, the received <S2L sub-
 LSP descriptor list> MUST be included in the set of outgoing Path
 messages.  If there are any NOTIFY_REQUEST objects present, then the
 procedures defined in section 8 MUST be followed for all Path and
 Resv messages.  Special processing is also required for Resv
 processing.  Specifically, any Resv message received from downstream
 MUST be mapped into an outgoing Resv message that is sent to the
 previous hop of the received Path message.  In practice, this
 translates to decomposing the complete <S2L sub-LSP descriptor list>
 into subsets that match the incoming Path messages, and then
 constructing an outgoing Resv message for each incoming Path message.
 When configured to allow a re-merge case to persist, the re-merge
 node receives data associated with the P2MP LSP on multiple incoming
 interfaces, but it MUST only send the data from one of these
 interfaces to its outgoing interfaces.  That is, the node MUST drop
 data from all but one incoming interface.  This ensures that
 duplicate data is not sent on any outgoing interface.  The mechanism
 used to select the incoming interface is implementation specific and
 is outside the scope of this document.
 When configured to correct the re-merge branch via signaling, the re-
 merge node MUST send a PathErr message corresponding to the received
 Path message.  The PathErr message MUST include all of the objects
 normally included in a PathErr message, as well as one or more
 S2L_SUB_LSP objects from the set of sub-LSPs associated with the
 matching P2MP LSP Path state.  A minimum of three S2L_SUB_LSP objects
 is RECOMMENDED.  This will allow the node that caused the re-merge to
 identify the outgoing Path state associated with the valid portion of

Aggarwal, et al. Standards Track [Page 37] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 the P2MP LSP.  The set of S2L_SUB_LSP objects in the received Path
 message MUST also be included.  The PathErr message MUST include the
 Error Code "Routing Problem" and Error Value of "P2MP Re-Merge
 Detected".  The node MAY set the Path_State_Removed flag [RFC3473].
 As is always the case, the PathErr message is sent to the previous
 hop of the received Path message.
 A node that receives a PathErr message that contains the Error Value
 "Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the
 node that created the re-merge case.  This is done by checking
 whether there is any intersection between the set of S2L_SUB_LSP
 objects associated with the matching P2MP LSP Path state and the set
 of other-branch S2L_SUB_LSP objects in the received PathErr message.
 If there is, then the node created the re-merge case.  Other-branch
 S2L_SUB_LSP objects are those S2L_SUB_LSP objects included, by the
 node detecting the re-merge case, in the PathErr message that were
 taken from the matching P2MP LSP Path state.  Such S2L_SUB_LSP
 objects are identifiable as they will not be included in the Path
 message associated with the received PathErr message.  See section
 11.1 for more details on how such an association is identified.
 The node SHOULD remove the re-merge case by moving the S2L_SUB_LSP
 objects included in the Path message associated with the received
 PathErr message to the outgoing interface associated with the
 matching P2MP LSP Path state.  A trigger Path message for the moved
 S2L_SUB_LSP objects is then sent via that outgoing interface.  If the
 received PathErr message did not have the Path_State_Removed flag
 set, the node SHOULD send a PathTear via the outgoing interface
 associated with the re-merge branch.
 If use of a new outgoing interface violates one or more SERO
 constraints, then a PathErr message containing the associated
 egresses and any identified S2L_SUB_LSP objects SHOULD be generated
 with the Error Code "Routing Problem" and Error Value of "ERO
 Resulted in Re-Merge".
 The only case where this process will fail is when all the listed
 S2L_SUB_LSP objects are deleted prior to the PathErr message
 propagating to the ingress.  In this case, the whole process will be
 corrected on the next (refresh or trigger) transmission of the
 offending Path message.

Aggarwal, et al. Standards Track [Page 38] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

19. New and Updated Message Objects

 This section presents the RSVP object formats as modified by this
 document.

19.1. SESSION Object

 A P2MP LSP SESSION object is used.  This object uses the existing
 SESSION C-Num.  New C-Types are defined to accommodate a logical P2MP
 destination identifier of the P2MP tunnel.  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 S2L sub-LSPs
 that are part of the same P2MP LSP share the same SESSION object.
 This SESSION object identifies the P2MP tunnel.
 The combination of the SESSION object, the SENDER_TEMPLATE object and
 the S2L_SUB_LSP object identifies each S2L sub-LSP.  This follows the
 existing P2P RSVP-TE notion of using the SESSION object for
 identifying a P2P Tunnel, which in turn can contain multiple LSPs,
 each distinguished by a unique SENDER_TEMPLATE object.

19.1.1. P2MP LSP Tunnel IPv4 SESSION Object

 Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       P2MP ID                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MUST be zero                 |      Tunnel ID                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Extended Tunnel ID                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 P2MP ID
    A 32-bit identifier used in the SESSION object that remains
    constant over the life of the P2MP tunnel.  It encodes the P2MP
    Identifier that is unique within the scope of the ingress LSR.
 Tunnel ID
    A 16-bit identifier used in the SESSION object that remains
    constant over the life of the P2MP tunnel.

Aggarwal, et al. Standards Track [Page 39] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 Extended Tunnel ID
    A 32-bit identifier used in the SESSION object that remains
    constant over the life of the P2MP tunnel.  Ingress LSRs that wish
    to have a globally unique identifier for the P2MP tunnel SHOULD
    place their tunnel sender address here.  A combination of this
    address, P2MP ID, and Tunnel ID provides a globally unique
    identifier for the P2MP tunnel.

19.1.2. P2MP LSP Tunnel IPv6 SESSION Object

 This is the same as the P2MP IPv4 LSP SESSION object with the
 difference that the extended tunnel ID may be set to a 16-byte
 identifier [RFC3209].
 Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       P2MP ID                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MUST be zero                 |      Tunnel ID                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Extended Tunnel ID (16 bytes)            |
    |                                                               |
    |                             .......                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.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 P2MP tunnel can be created,
 each with a different LSP ID.  The instances can share resources with
 each other.  The S2L sub-LSPs corresponding to a particular instance
 use the same LSP ID.
 As described in section 4.2, it is necessary to distinguish different
 Path messages that are used to signal state for the same P2MP LSP by
 using a <Sub-Group ID Originator ID, Sub-Group ID> tuple.  The
 SENDER_TEMPLATE object is modified to carry this information as shown
 below.

Aggarwal, et al. Standards Track [Page 40] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

 Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
     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             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Sub-Group Originator ID                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Reserved                |            Sub-Group ID       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 IPv4 tunnel sender address
    See [RFC3209].
 Sub-Group Originator ID
    The Sub-Group Originator ID is set to the TE Router ID of the LSR
    that originates the Path message.  This is either the ingress LSR
    or an LSR which re-originates the Path message with its own Sub-
    Group Originator ID.
 Sub-Group ID
    An identifier of a Path message used to differentiate multiple
    Path messages that signal state for the same P2MP LSP.  This may
    be seen as identifying a group of one or more egress nodes
    targeted by this Path message.
 LSP ID
    See [RFC3209].

Aggarwal, et al. Standards Track [Page 41] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

 Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
     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 tunnel sender address                  |
    +                                                               +
    |                            (16 bytes)                         |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Reserved                |            LSP ID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                   Sub-Group Originator ID                     |
    +                                                               +
    |                            (16 bytes)                         |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Reserved                |            Sub-Group ID       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 IPv6 tunnel sender address
    See [RFC3209].
 Sub-Group Originator ID
    The Sub-Group Originator ID is set to the IPv6 TE Router ID of the
    LSR that originates the Path message.  This is either the ingress
    LSR or an LSR which re-originates the Path message with its own
    Sub-Group Originator ID.
 Sub-Group ID
    As above in section 19.2.1.
 LSP ID
    See [RFC3209].

Aggarwal, et al. Standards Track [Page 42] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

19.3. S2L_SUB_LSP Object

 An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging
 to the P2MP LSP.

19.3.1. S2L_SUB_LSP IPv4 Object

 S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1
     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 S2L Sub-LSP destination address        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 IPv4 Sub-LSP destination address
    IPv4 address of the S2L sub-LSP destination.

19.3.2. S2L_SUB_LSP IPv6 Object

 S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2
 This is the same as the S2L IPv4 Sub-LSP object, with the difference
 that the destination address is a 16-byte IPv6 address.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        IPv6 S2L Sub-LSP destination address (16 bytes)        |
    |                        ....                                   |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.4. FILTER_SPEC Object

 The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
 object.

19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object

 Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
 The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
 the P2MP LSP_IPv4 SENDER_TEMPLATE object.

Aggarwal, et al. Standards Track [Page 43] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object

 Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
 The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
 the P2MP LSP_IPv6 SENDER_TEMPLATE object.

19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

 The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as
 identical to the ERO.  The class of the P2MP SERO is the same as the
 SERO defined in [RFC4873].  The P2MP SERO uses a new C-Type = 2.  The
 sub-objects are identical to those defined for the ERO.

19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

 The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical
 to the ERO.  The class of the P2MP SRRO is the same as the SRRO
 defined in [RFC4873].  The P2MP SRRO uses a new C-Type = 2.  The
 sub-objects are identical to those defined for the RRO.

20. IANA Considerations

20.1. New Class Numbers

 IANA has assigned the following Class Numbers for the new object
 classes introduced.  The Class Types for each of them are to be
 assigned via standards action.  The sub-object types for the P2MP
 SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the
 same IANA considerations as those of the ERO and RRO [RFC3209].
 50  Class Name = S2L_SUB_LSP
 C-Type
    1   S2L_SUB_LSP_IPv4 C-Type
    2   S2L_SUB_LSP_IPv6 C-Type

20.2. New Class Types

 IANA has assigned the following C-Type values:
 Class Name = SESSION
 C-Type
   13    P2MP_LSP_TUNNEL_IPv4 C-Type
   14    P2MP_LSP_TUNNEL_IPv6 C-Type

Aggarwal, et al. Standards Track [Page 44] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 Class Name = SENDER_TEMPLATE
 C-Type
   12    P2MP_LSP_TUNNEL_IPv4 C-Type
   13    P2MP_LSP_TUNNEL_IPv6 C-Type
 Class Name = FILTER_SPEC
 C-Type
   12    P2MP LSP_IPv4 C-Type
   13    P2MP LSP_IPv6 C-Type
 Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
 C-Type
    2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type
 Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
 C-Type
    2  P2MP_SECONDARY_RECORD_ROUTE C-Type

20.3. New Error Values

 Five new Error Values are defined for use with the Error Code
 "Routing Problem".  IANA has assigned values for them as follows.
 The Error Value "Unable to Branch" indicates that a P2MP branch
 cannot be formed by the reporting LSR.  IANA has assigned value 23 to
 this Error Value.
 The Error Value "Unsupported LSP Integrity" indicates that a P2MP
 branch does not support the requested LSP integrity function.  IANA
 has assigned value 24 to this Error Value.
 The Error Value "P2MP Re-Merge Detected" indicates that a node has
 detected re-merge.  IANA has assigned value 25 to this Error Value.
 The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
 section 18.  IANA has assigned value 26 to this Error Value.
 The Error Value "ERO Resulted in Re-Merge" is described in section
 18.  IANA has assigned value 27 to this Error Value.

Aggarwal, et al. Standards Track [Page 45] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

20.4. LSP Attributes Flags

 IANA has been asked to manage the space of flags in the Attributes
 Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES object [RFC4420].
 This document defines a new flag as follows:
 Bit Number:                       3
 Meaning:                          LSP Integrity Required
 Used in Attributes Flags on Path: Yes
 Used in Attributes Flags on Resv: No
 Used in Attributes Flags on RRO:  No
 Referenced Section of this Doc:   5.2.4

21. Security Considerations

 In principle this document does not introduce any new security issues
 above those identified in [RFC3209], [RFC3473], and [RFC4206].
 [RFC2205] specifies the message integrity mechanisms for hop-by-hop
 RSVP signaling.  These mechanisms apply to the hop-by-hop P2MP RSVP-
 TE signaling in this document.  Further, [RFC3473] and [RFC4206]
 specify the security mechanisms for non hop-by-hop RSVP-TE signaling.
 These mechanisms apply to the non hop-by-hop P2MP RSVP-TE signaling
 specified in this document, particularly in sections 16 and 17.
 An administration may wish to limit the domain over which P2MP TE
 tunnels can be established.  This can be accomplished by setting
 filters on various ports to deny action on a RSVP path message with a
 SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.
 The ingress LSR of a P2MP TE LSP determines the leaves of the P2MP TE
 LSP based on the application of the P2MP TE LSP.  The specification
 of how such applications will use a P2MP TE LSP is outside the scope
 of this document.  Applications MUST provide a mechanism to notify
 the ingress LSR of the appropriate leaves for the P2MP LSP.
 Specifications of applications within the IETF MUST specify this
 mechanism in sufficient detail that an ingress LSR from one vendor
 can be used with an application implementation provided by another
 vendor.  Manual configuration of security parameters when other
 parameters are auto-discovered is generally not sufficient to meet
 security and interoperability requirements of IETF specifications.

Aggarwal, et al. Standards Track [Page 46] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

22. Acknowledgements

 This document is the product of many people.  The contributors are
 listed in Appendix B.
 Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger, and Nischal
 Sheth for their suggestions and comments.  Thanks also to Dino
 Farninacci and Benjamin Niven for their comments.

23. References

23.1. Normative References

 [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.
 [RFC4420]     Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., 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.
 [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.
 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2205]     Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
               S. Jamin, "Resource ReSerVation Protocol (RSVP) --
               Version 1 Functional Specification", RFC 2205,
               September 1997.
 [RFC3471]     Berger, L., Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Functional Description",
               RFC 3471, January 2003.
 [RFC3473]     Berger, L., Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Resource ReserVation
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
               3473, January 2003.

Aggarwal, et al. Standards Track [Page 47] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 [RFC2961]     Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
               and S. Molendini, "RSVP Refresh Overhead Reduction
               Extensions", RFC 2961, April 2001.
 [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC 3031,
               January 2001.
 [RFC4090]     Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
               "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
               RFC 4090, May 2005.
 [RFC3477]     Kompella, K. and Y. Rekhter, "Signalling Unnumbered
               Links in Resource ReSerVation Protocol - Traffic
               Engineering (RSVP-TE)", RFC 3477, January 2003.
 [RFC4873]     Berger, L., Bryskin, I., Papadimitriou, D., and A.
               Farrel, "GMPLS Segment Recovery", RFC 4873, April 2007.

23.2. Informative References

 [RFC4461]     Yasukawa, S., Ed., "Signaling Requirements for Point-
               to-Multipoint Traffic-Engineered MPLS Label Switched
               Paths (LSPs)", RFC 4461, April 2006.
 [BFD]         Katz, D. and D. Ward, "Bidirectional Forwarding
               Detection", Work in Progress, March 2007.
 [BFD-MPLS]    Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
               "BFD for MPLS LSPs", Work in Progress, March 2007.
 [LSP-STITCH]  Ayyanger, A., Kompella, K., Vasseur, JP., and A.
               Farrel, "Label Switched Path Stitching with Generalized
               Multiprotocol Label Switching Traffic Engineering
               (GMPLS TE)", Work in Progress, March 2007.
 [TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing
               Protocol Extensions for Discovery of Traffic
               Engineering Node Capabilities", Work in Progress, April
               2007.
 [RFC4003]     Berger, L., "GMPLS Signaling Procedure for Egress
               Control", RFC 4003, February 2005.

Aggarwal, et al. Standards Track [Page 48] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

Appendix A. Example of P2MP LSP Setup

 The Following is one example of setting up a P2MP LSP using the
 procedures described in this document.
                 Source 1 (S1)
                   |
                  PE1
                 |   |
                 |L5 |
                 P3  |
                 |   |
              L3 |L1 |L2
     R2----PE3--P1   P2---PE2--Receiver 1 (R1)
                | L4
        PE5----PE4----R3
                |
                |
               R4
              Figure 2.
 The mechanism is explained using Figure 2.  PE1 is the ingress LSR.
 PE2, PE3, and PE4 are egress LSRs.
 a) PE1 learns that PE2, PE3, and PE4 are interested in joining a P2MP
    tree with a P2MP ID of P2MP ID1.  We assume that PE1 learns of the
    egress LSRs at different points in time.
 b) PE1 computes the P2P path to reach PE2.
 c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>.
 d) PE1 computes the P2P path to reach PE3 when it discovers PE3.
    This path is computed to share the same links where possible with
    the sub-LSP to PE2 as they belong to the same P2MP session.
 e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.
 f) PE1 computes the P2P path to reach PE4 when it discovers PE4.
    This path is computed to share the same links where possible with
    the sub-LSPs to PE2 and PE3 as they belong to the same P2MP
    session.
 g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
    PE4>.

Aggarwal, et al. Standards Track [Page 49] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 h) P1 receives a Resv message from PE4 with label L4.  It had
    previously received a Resv message from PE3 with label L3.  It had
    allocated a label L1 for the sub-LSP to PE3.  It uses the same
    label and sends the Resv messages to P3.  Note that it may send
    only one Resv message with multiple flow descriptors in the flow
    descriptor list.  If this is the case, and FF style is used, the
    FF flow descriptor will contain the S2L sub-LSP descriptor list
    with two entries: one for PE4 and the other for PE3.  For SE
    style, the SE filter spec will contain this S2L sub-LSP descriptor
    list.  P1 also creates a label mapping of (L1 -> {L3, L4}).  P3
    uses the existing label L5 and sends the Resv message to PE1, with
    label L5.  It reuses the label mapping of {L5 -> L1}.

Appendix B. Contributors

 John Drake
 Boeing
 EMail: john.E.Drake2@boeing.com
 Alan Kullberg
 Motorola Computer Group
 120 Turnpike Road 1st Floor
 Southborough, MA  01772
 EMail: alan.kullberg@motorola.com
 Lou Berger
 LabN Consulting, L.L.C.
 EMail: lberger@labn.net
 Liming Wei
 Redback Networks
 350 Holger Way
 San Jose, CA 95134
 EMail: lwei@redback.com
 George Apostolopoulos
 Redback Networks
 350 Holger Way
 San Jose, CA 95134
 EMail: georgeap@redback.com
 Kireeti Kompella
 Juniper Networks
 1194 N. Mathilda Ave
 Sunnyvale, CA 94089
 EMail: kireeti@juniper.net

Aggarwal, et al. Standards Track [Page 50] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 George Swallow
 Cisco Systems, Inc.
 300 Beaver Brook Road
 Boxborough , MA - 01719
 USA
 EMail: swallow@cisco.com
 JP Vasseur
 Cisco Systems, Inc.
 300 Beaver Brook Road
 Boxborough , MA - 01719
 USA
 EMail: jpv@cisco.com
 Dean Cheng
 Cisco Systems Inc.
 170 W Tasman Dr.
 San Jose, CA 95134
 Phone 408 527 0677
 EMail:  dcheng@cisco.com
 Markus Jork
 Avici Systems
 101 Billerica Avenue
 N. Billerica, MA 01862
 Phone: +1 978 964 2142
 EMail: mjork@avici.com
 Hisashi Kojima
 NTT Corporation
 9-11, Midori-Cho 3-Chome
 Musashino-Shi, Tokyo 180-8585 Japan
 Phone: +81 422 59 6070
 EMail: kojima.hisashi@lab.ntt.co.jp
 Andrew G. Malis
 Tellabs
 2730 Orchard Parkway
 San Jose, CA 95134
 Phone: +1 408 383 7223
 EMail: Andy.Malis@tellabs.com
 Koji Sugisono
 NTT Corporation
 9-11, Midori-Cho 3-Chome
 Musashino-Shi, Tokyo 180-8585 Japan
 Phone: +81 422 59 2605
 EMail: sugisono.koji@lab.ntt.co.jp

Aggarwal, et al. Standards Track [Page 51] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

 Masanori Uga
 NTT Corporation
 9-11, Midori-Cho 3-Chome
 Musashino-Shi, Tokyo 180-8585 Japan
 Phone: +81 422 59 4804
 EMail: uga.masanori@lab.ntt.co.jp
 Igor Bryskin
 Movaz Networks, Inc.
 7926 Jones Branch Drive
 Suite 615
 McLean VA, 22102
 ibryskin@movaz.com
 Adrian Farrel
 Old Dog Consulting
 Phone: +44 0 1978 860944
 EMail: adrian@olddog.co.uk
 Jean-Louis Le Roux
 France Telecom
 2, avenue Pierre-Marzin
 22307 Lannion Cedex
 France
 EMail: jeanlouis.leroux@francetelecom.com

Editors' Addresses

 Rahul Aggarwal
 Juniper Networks
 1194 North Mathilda Ave.
 Sunnyvale, CA 94089
 EMail: rahul@juniper.net
 Seisho Yasukawa
 NTT Corporation
 9-11, Midori-Cho 3-Chome
 Musashino-Shi, Tokyo 180-8585 Japan
 Phone: +81 422 59 4769
 EMail: yasukawa.seisho@lab.ntt.co.jp
 Dimitri Papadimitriou
 Alcatel
 Francis Wellesplein 1,
 B-2018 Antwerpen, Belgium
 Phone: +32 3 240-8491
 EMail: Dimitri.Papadimitriou@alcatel-lucent.be

Aggarwal, et al. Standards Track [Page 52] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Aggarwal, et al. Standards Track [Page 53]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4875.txt · Last modified: 2007/05/09 20:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki