Network Working Group                               R. Aggarwal (Juniper) (Editor)
Internet Draft                              D. Papadimitriou (Alcatel)                                          Juniper Networks
Expiration Date: June 2005 January 2006
                                               D. Papadimitriou (Editor)
                                                                 Alcatel

                                                    S. Yasukawa (NTT)
                                            Editors (Editor)
                                                                     NTT

                                                               July 2005

         Extensions to RSVP-TE for Point to Multipoint TE LSPs

                  draft-ietf-mpls-rsvp-te-p2mp-01.txt

                  draft-ietf-mpls-rsvp-te-p2mp-02.txt

Status of this Memo

   By submitting this Internet-Draft, we certify each author represents that any
   applicable patent or other IPR claims of which we are he or she is aware
   have been or will be disclosed, and any of which we become he or she becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

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

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

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

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

Abstract

   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the setup 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.

Table of Contents

 1          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 [KEYWORDS].

Authors' Note

   Some of the text in the document needs further discussion between
   authors and feedback from MPLS WG. This has been pointed out when
   applicable. A change log and reviewed/updated text will be made
   available online.

Table of Contents

       1      Terminology............................................. 4  .....................   5
 2      Introduction.............................................4          Terminology  ...........................................   5
 3      Mechanisms..............................................          Introduction  ..........................................   5
 4
       3.1    P2MP Tunnels............................................          Mechanism  .............................................   5
       3.2
 4.1        P2MP Tunnels  ..........................................   6
 4.2        P2MP LSP Tunnels........................................ 5
       3.3    Sub-Groups.............................................. 5
       3.4    S2L Sub-LSPs............................................   .............................................   6
 4.3        Sub-Groups  ............................................   6
       3.4.1
 4.4        S2L Sub-LSPs  ..........................................   7
 4.4.1      Representation of a S2L sub-LSP......................... 6
       3.4.2 Sub-LSP  .......................   7
 4.4.2      S2L Sub-LSPs and Path Messages.......................... 6
       3.5    Explicit Routing........................................ Messages  ........................   7
       4      Path Message............................................ 9
       4.1
 4.5        Explicit Routing  ......................................   8
 5          Path Message Format..................................... 9
       4.2  ..........................................  10
 5.1        Path Message Processing................................. Format  ...................................  10
       4.2.1  Multiple
 5.2        Path Messages.................................. Message Processing  ...............................  11
       4.2.2
 5.2.1      Multiple Path Messages  ................................  12
 5.2.2      Multiple S2L Sub-LSPs in One one Path Message............... 12
       4.2.3  Transit Fragmentation................................... message  .............  13
       4.3    Grafting................................................
 5.2.3      Transit Fragmentation  .................................  14
       4.3.1  Addition
 5.2.4      Control of S2L Sub-LSP................................. 14
       5 Branch Fate Sharing  ........................  15
 5.3        Grafting  ..............................................  15
 6          Resv Message............................................ 14
       5.1 Message  ..........................................  16
 6.1        Resv Message Format..................................... 14
       5.2 Format  ...................................  16
 6.2        Resv Message Processing................................. 15
       5.2.1 Processing  ...............................  17
 6.2.1      Resv Message Throttling................................. 16
       5.3 Throttling  ...............................  18
 6.3        Record Routing.......................................... 17
       5.3.1 Routing  ........................................  18
 6.3.1      RRO Processing.......................................... 17
       6 Processing  ........................................  18
 6.4        Reservation Style....................................... 17 Style  .....................................  19
 7      Path Tear Message....................................... 17          PathTear Message  ......................................  19
 7.1    Path Tear        PathTear Message Format................................ 17 Format  ...............................  19
 7.2    Pruning................................................. 17        Pruning  ...............................................  20
 7.2.1  Explicit      Implicit S2L Sub-LSP Teardown........................... 17 Teardown  .........................  20
 7.2.2  Implicit      Explicit S2L Sub-LSP Teardown........................... 18
       7.2.1  P2MP TE LSP Teardown.................................... 19 Teardown   ........................  20
 8          Notify and ResvConf Messages............................ 20 Messages  ..........................  21
 9      Error Processing........................................ 20
       9.1    PathErr Message Format.................................. 20
       9.2    Handling of Failures at Branch LSRs.....................          Refresh Reduction  .....................................  21
10     Refresh Reduction....................................... 22
       11          State Management........................................ Management  ......................................  22
       11.1
10.1        Incremental State Update................................ Update  ..............................  22
       11.2
10.2        Combining Multiple Path Messages........................ Messages  ......................  23
       12     Control of Branch Fate Sharing..........................
11          Error Processing  ......................................  24
       13     Admin Status Change.....................................
11.1        PathErr Messages  ......................................  24
       14     Label Allocation on LANs
11.2        ResvErr Messages  ......................................  24
11.3        Branch Failure Handling  ...............................  25
12          Admin Status Change  ...................................  26
13          Label Allocation on LANs with Multiple Downstream Nodes. 25
       15     Make-Before-Break....................................... 25
       15.1 Nodes  ...26
14          P2MP Tree re-optimization............................... 25
       15.2 LSP and Sub-LSP Re-optimization of a subset of S2L sub-LSPs ............ 25
       16     Fast Reroute............................................  ..................  26
       16.1

14.1        Make-before-break  .....................................  27
14.2        Sub-Group Based Re-optimization  .......................  27
15          Fast Reroute  ..........................................  27
15.1        Facility Backpup........................................ 26
       16.2 Backup  .......................................  28
15.2        One to One Backup....................................... 26
       17 Backup  .....................................  29
16          Support for LSRs that are not P2MP Capable.............. 27
       18 Capable  ............  29
17          Reduction in Control Plane Processing with LSP Hierarchy 29
       19  ..31
18          P2MP LSP Tunnel Remerging and Cross-Over................ 29
       20 Cross-Over  .....................  31
19          New and Updated Message Objects......................... 31
       20.1 Objects  .......................  34
19.1        SESSION Object  ........................................  34
19.1.1      P2MP LSP Tunnel IPv4 SESSION Object..................................... 31
       20.2 Object  ...................  34
19.1.2      P2MP LSP Tunnel IPv6 SESSION Object  ...................  35
19.2        SENDER_TEMPLATE Object.................. 32
       20.2.1 object  ................................  35
19.2.1      P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object............. 33
       20.2.2 Object  ...........  35
19.2.2      P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object............. 33
       20.3 Object  ...........  36
19.3        S2L SUB-LSP Object...................................... 34
       20.3.1 Object  ....................................  37
19.3.1      S2L IPv4 SUB-LSP Object................................. 34
       20.3.2 IPv4 Object  ...............................  37
19.3.2      S2L IPv6 SUB-LSP Object................................. 35
       20.4 IPv6 Object  ...............................  38
19.4        FILTER_SPEC Object...................................... 35
       20.5   SUB EXPLICIT ROUTE Object (SERO)........................ 36
       20.6   SUB RECORD ROUTE  ....................................  38
19.4.1      P2MP LSP_IPv4 FILTER_SPEC Object (SRRO).......................... 36
       21  ......................  38
19.4.2      P2MP LSP_IPv4 FILTER_SPEC Object  ......................  38
19.5        P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)  ...........  38
19.6        P2MP_SECONDARY_RECORD_ROUTE Object (SRRO)  .............  39
20          IANA Considerations..................................... 37
       22 Considerations  ...................................  39
20.1        New Class Numbers  .....................................  39
20.2        New Class Types  .......................................  39
20.3        New Error Codes  .......................................  40
20.4        LSP Attributes Flags  ..................................  40
21          Security Considerations................................. 37 Considerations  ...............................  41
22          Acknowledgements  ......................................  41
23     Acknowledgements........................................ 37
       24          Appendix  ..............................................  41
23.1        Example P2MP LSP Establishment ......................... 37  ...............................................  41
24          References  ............................................  42
24.1        Normative References  ..................................  42
24.2        Informative References  ................................  43
25     References.............................................. 39          Author Information  ....................................  44
25.1        Editor Information  ....................................  44
25.2        Contributor Information  ...............................  45
26     Authors................................................. 40
       27          Intellectual Property................................... 43
       28 Property  .................................  47
27          Full Copyright Statement................................ 43
       29     Acknowledgement......................................... 44 Statement  ..............................  48
28          Acknowledgement  .......................................  48

1. 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 [KEYWORDS].

2. Terminology

   This document uses terminologies defined in [RFC3031], [RFC2205],
   [RFC3209], [RFC3473] and [P2MP-REQ]. In particular, this document
   uses the notation defined in [P2MP-REQ] for describing the components
   on a P2MP LSP between root, branches and leaves.

2.

3. Introduction

   [RFC3209] defines a mechanism for setting up point-to-point (P2P)
   Traffic Engineered (TE) P2P TE LSPs in MPLS networks. net-
   works. [RFC3473] defines extensions to [RFC3209] for setting up P2P
   TE LSPs in GMPLS networks. However these specifications do not provide pro-
   vide a mechanism for building
   point-to-multipoint P2MP TE LSPs.

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

   This document relies on the semantics of RSVP that RSVP-TE inherits
   for building P2MP LSP Tunnels. LSPs. A P2MP LSP Tunnel  is comprised of multiple S2L sub-LSPs. 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. Hence the S2L sub-
   LSPs sub-LSPs belonging to a P2MP
   LSP Tunnel can be signaled using one Path message or split across multiple
   Path messages.

   Path computation and P2MP application specific aspects are outside of
   the scope of this document.

3.

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 a LSR that is capable of replicating the
   incoming data on two or more outgoing interfaces. The solution uses
   RSVP-TE in the core of the network for setting up a P2MP TE LSP.

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

3.1.

4.1. P2MP Tunnels

   The specific aspect related to P2MP TE LSP is the action required at
   a branch node, where data replication occurs. Incoming For instance, in the
   MPLS case, incoming labeled data is appropriately replicated to several sev-
   eral outgoing interfaces which may have different labels.

   A P2MP TE tunnel Tunnel comprises of one or more P2MP LSPs referred to as
   P2MP LSP tunnels. LSPs. A P2MP TE Tunnel
   is identified by a P2MP SESSION object. This object contains an the
   identifier of the P2MP session
   defined as a Session which includes the P2MP ID, a tunnel
   ID and an extended tunnel ID.

   The fields of a 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 Identifier (P2MP ID) field.

   The P2MP ID provides an identifier for the set of destinations of the
   P2MP TE Tunnel. The P2MP SESSION object is defined in section 20.1.

3.2.

4.2. P2MP LSP Tunnel

   A P2MP LSP Tunnel  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 20.2.

3.3.

4.3. Sub-Groups

   As with all other RSVP controlled LSP Tunnels, LSPs, P2MP LSP Tunnel  state is managed
   using RSVP messages. While use of RSVP messages is the same, P2MP LSP Tunnel
   state differs from P2P LSP state in a number of ways. A The two most
   notable difference is differences are that a P2MP LSP Tunnel is comprised of  comprises multiple S2L Sub-LSPs As Sub-
   LSPs and that, as a result of this, it may not be possible to
   signal a P2MP LSP Tunnel repre-
   sent full state in a single RSVP-TE Path/Resv message. It is
   also possible IP datagram and even more likely that such a signaling message can not it
   can't fit into a single IP packet. It must also be possible to efficiently effi-
   ciently add and remove endpoints to and from P2MP TE LSPs. An additional addi-
   tional issue is that P2MP LSP Tunnels must also handle the state "remerge" problem
   problem, see [P2MP-REQ].

   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 rest of the SENDER_TEMPLATE and
   SESSION objects, are used to represent a portion of a P2MP LSP
   Tunnel's LSP's
   state. The  This portion of a P2MP LSP Tunnel LSP's state identified by
   specific subgroup field values is referred to as a signaling sub-
   tree. It is important to note that the term "signaling sub-tree" refers only to signaling
   state and not data plane replication or branching. For example, it is
   possible for a node to "split" "branch" signaling state for a P2MP LSP Tunnel, LSP, but
   to not branch the data associated with the P2MP LSP Tunnel. LSP. Typical applications applica-
   tions for generation and use of multiple subgroups are adding an
   egress and semantic fragmentation to ensure that a Path message
   remains within a single IP packet.

3.4.

4.4. S2L Sub-LSPs

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

3.4.1.

4.4.1. Representation of a S2L Sub-LSP

   A S2L sub-LSP exists within the context of a P2MP LSP Tunnel. 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 20.3.

   Additionally, a sub-LSP ID contained in the S2L_SUB_LSP object may be
   used depending on further discussions about the make-before-break
   procedures described in section 14.

   An EXPLICIT_ROUTE Object (ERO) or SUB_EXPLICIT_ROUTE P2MP SECONDARY_EXPLICIT_ROUTE
   Object (SERO) is used to optionally specify the explicit route of a
   S2L sub-LSP. Each ERO or a SERO that is signaled corresponds to a
   particular S2L_SUB_LSP object. Details of explicit route encoding are
   specified in section 3.5.

3.4.2. 4.5. The SECONDARY_EXPLICIT_ROUTE Object is
   defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-
   type is defined in Section 20.5 and a matching P2MP SEC-
   ONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6.

4.4.2. S2L Sub-LSPs and Path Messages

   The mechanism in this document allows a P2MP LSP Tunnel 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 fit all the S2L sub-LSPs; and
   they also allow separate manipulation of sub-
   trees sub-trees of the P2MP LSP Tunnel. 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
   setup a P2MP LSP Tunnel.

3.5. 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 may encode encodes the path from the ingress LSR 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. sub-LSP and is referred to
   as the sub-LSP descriptor.  The absence of the ERO should be
   interpreted inter-
   preted 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, from the ingress LSR 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 corre-
   sponding to the S2L_SUB_LSP objects that follow are termed as
   subsequent subse-
   quent S2L sub-LSPs.  One approach to encode the explicit route of a
   subsequent S2L sub-LSP is to include all the path hops from the ingress to
   the egress of the S2L sub-LSP. However this implies potential
   repetition repeti-
   tion of hops that could can be learned from the ERO or explicit routes of
   other S2L sub-LSPs. Explicit route compression using SEROs attempts
   to minimize such repetition and is described below. repetition.

   The path of each subsequent S2L sub-LSP is encoded in a
   SUB_EXPLICIT_ROUTE P2MP SEC-
   ONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the
   same as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP
   is represented by tuples of the form [<SUB_EXPLICIT_ROUTE>]
   <S2L_SUB_LSP>. < [<P2MP SEC-
   ONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >. There is a one to one correspondence corre-
   spondence between a S2L_SUB_LSP object and a SERO. A SERO for a particular par-
   ticular S2L sub-LSP includes only the path from a certain branch LSR
   to the egress LSR if the path to that branch LSR can be derived from
   the ERO or other SEROs. The absence of a SERO should be interpreted
   as requiring hop-
   by-hop hop-by-hop routing for that S2L sub-LSP. Note that the
   destination address is carried in the S2L sub-LSP object. The encoding encod-
   ing of the SERO and S2L sub-LSP object are described in detail in
   section 20.

   Explicit route compression is illustrated using the following figure.

                                    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 Tunnel with LSR A as the ingress LSR and six
   egress LSRs: (F, N, O, P, Q and R). When all the 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. sub-
   LSPs. Following 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 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,

   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: fol-
   lows:

      S2L sub-LSP-P:   ERO = {L, P}, S2L_SUB_LSP Object-P,

   Following 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 to the reader.

   This compression mechanism reduces the Path message size. It also
   reduces the 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. A LSR needs
   to process a SERO 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 a SERO propagates the
   corresponding S2L sub-LSP downstream.

4.

5. Path Message

4.1.

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.

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

   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> [ <SUB_EXPLICIT_ROUTE> <P2MP SEC-
   ONDARY_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 SUB-/EXPLICIT_ROUTE object combination.

   The first S2L_SUB_LSP object's explicit route is specified by the
   ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the
   corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP
   object.

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

   Path message processing is described in the next section.

4.2.

5.2. Path Message Processing

   The ingress-LSR initiates the set up of a S2L sub-LSP to each egress-
   LSR that is the destination of the P2MP LSP Tunnel. LSP. Each S2L sub-LSP is
   associated with the same P2MP LSP Tunnel using common P2MP SESSION object
   and <Source 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 Tunnel. LSP.  Another S2L sub-LSP belonging to the same instance of this
   S2L sub-LSP (i.e.  the same P2MP LSP Tunnel) can share LSP) shares resources with this LSP. S2L
   sub-LSP. The session corresponding to the P2MP TE tunnel is determined deter-
   mined based on the P2MP SESSION object. Each S2L sub-
   LSP sub-LSP is identified identi-
   fied using the S2L_SUB_LSP object. Explicit routing for the S2L sub-LSPs 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 Tunnel in one or more Path messages. And a given Path message
   can contain one or more S2L sub-LSPs.

4.2.1. Multiple A 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 a LSR MUST be able to receive and process
   all objects listed in section 20.

5.2.1. Multiple Path Messages

   As described in section 3, {<EXPLICIT_ROUTE>, either the <EXPLICIT_ROUTE> <S2L SUB-LSP>} SUB-LSP>
   or
   {<SUB_EXPLICIT_ROUTE>, <S2L_SUB_LSP>} the <P2MP SECONDARY_EXPLICIT_ROUTE> <S2L_SUB_LSP> tuple is used to
   specify a S2L sub-LSP. Multiple Path messages can be used to signal a
   P2MP LSP
   Tunnel. 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 4.3. 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 Tunnel. LSP. Or it may be while adding leaves to
   the P2MP LSP Tunnel the new leaves are signaled in a new Path message. Or an
   ingress LSR MAY choose to break the P2MP tree into separate manageable S2L sub-trees. manage-
   able P2MP trees.  These trees share the same root and may share the
   trunk and certain branches.  The scope of this management decomposition decomposi-
   tion of P2MP trees is bounded by a single tree (the P2MP Tree) and
   multiple S2L sub-trees trees with a single leaf each. As defined in
   [P2MP-REQ], each (S2L sub-LSPs).  Per [P2MP-
   REQ], a P2MP LSP Tunnel must MUST have consistent attributes across all portions
   of a tree. This implies that each Path message that is used to signal
   a P2MP LSP Tunnel is signaled using the same signaling attributes with the
   exception of the S2L sub-LSP information.

   The resulting S2L sub-LSPs from the different Path messages belonging to
   the same P2MP LSP Tunnel 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. mes-
   sage. For instance ERO expansion may result in an overflow of the
   resultant Path message. There are two cases occurring in such
   circumstances, either In this case the message can be decomposed
   into multiple Path messages such that each of the message carries messages carry a
   subset of the
   incoming S2L sub-LSPs X2L sub-tree carried by the incoming message, or the message
   can not be decomposed such that each of the outgoing Path message
   fits its maximum size value. message.

   Multiple Path messages generated by a 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
   field).
   field) and encoded in the SENDER_TEMPLATE object. Multiple Path messages mes-
   sages generated by a 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 SHOULD be set to the TE Router ID of the
   LSR that originates the Path message. This is either the ingress LSR
   or a LSR which re-originates the Path message with its own Sub-Group
   Originator ID. 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, sub-Group ID> tuple is network-wide globally unique. The
   sub-Group ID space is specific to the Sub-Group Originator ID. Therefore There-
   fore the combination <Sub-Group Originator ID, sub-Group ID> is network-wide net-
   work-wide unique. Also, a router that changes the Sub-Group Originator origina-
   tor ID of an incoming Path message MUST use the same value of the
   Sub-Group Originator ID on for all outgoing Path messages messages, for the same a partic-
   ular P2MP LSP Tunnel LSP, and SHOULD not vary the value it during the life of the P2MP LSP Tunnel.

   Note: This version of the document assumes that these additional
   fields, i.e. <Sub-Group Originator ID, sub-Group ID>, are part of the
   SENDER_TEMPLATE object.

4.2.2.
   LSP.

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. It is possible to signal multiple
   S2L sub-LSP objects object and ERO/SERO combinations in a single Path
   message. mes-
   sage. Note that these two objects are the ones that differentiate a
   S2L sub-LSP. Each LSR can use the common objects in the Path message
   and the S2L sub-LSP descriptors to process each S2L sub-LSP.

   All LSRs need to MUST process the ERO corresponding to the first S2L sub-
   LSP sub-LSP
   when the ERO is present. If one or more SEROs are present an ERO MUST
   be present.  The signaling information for the first S2L sub-LSP
   is MUST be propagated in a Path message mes-
   sage by each LSR along the explicit route specified by the ERO. A LSR needs to
   MUST process a 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. If this is not the case the S2L sub-LSP descriptor is MUST be
   included in the Path message sent to 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 this is the case and the LSR is also the egress egress, the S2L sub-LSP
   descriptor is not MUST NOT be propagated downstream. If this is the case and
   the LSR is not the egress the S2L sub-LSP descriptor is MUST be included
   in a Path message sent to the next-hop determined from the SERO.
   Hence a branch LSR MUST only propagates propagate the relevant S2L sub-LSP
   descriptors on each downstream link. A S2L sub-
   LSP sub-LSP descriptor list
   that is propagated on a downstream link MUST only contains contain those S2L
   sub-LSPs that are routed using that link. This processing
   may MAY result
   in a subsequent S2L sub-LSP in an incoming Path message to become the
   first S2L sub-LSP in an outgoing Path message.

   Note that if one or more SEROs contains contain loose hops, expansion of such
   loose hops may MAY result in overflowing the Path message size. Section
   4.2.3
   5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
   in 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. path mes-
   sage. A transit LSR appends MUST append its address in an incoming RRO and
   propagates
   propagate it downstream. A branch LSR forms MUST form a new RRO for each of
   the outgoing Path messages. Each such updated RRO is MUST be formed
   using the rules in [RFC3209].

   If a LSR is unable to support a S2L sub-LSP setup, in a Path message, a
   PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
   processing of the rest of the P2MP LSP Tunnel 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_Reomved Path_State_Removed flag
   MUST NOT be set. However, the ingress LSR may set a LSP Integrity
   flag (see
   section 21.3) to request that if there is a setup failure on any branch the
   entire LSP should fail to set up.

4.2.3. This is described further in sec-
   tion 12.

5.2.3. Transit Fragmentation

   In certain cases a transit LSR may need to generate multiple Path
   messages to signal state corresponding to a single received Path
   message. mes-
   sage. For instance ERO expansion may result in an overflow of the
   resultant Path message. It is desirable not to rely on IP
   fragmentation fragmenta-
   tion in this case. In order to achieve this, the multiple Path messages mes-
   sages generated by the transit LSR, MUST be are signaled with the Sub-Group
   Originator ID set to the TE Router ID of the transit LSR and a distinct dis-
   tinct sub-Group ID. Thus each distinct Path message that is generated
   by the transit LSR for the P2MP LSP Tunnel 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 information (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 performing a  make-before-break  make-
   before-break operation, the tunnel sender address and LSP ID fields
   MUST be the same in each message, and for transit nodes, 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 transit fragmentation.
   The Sub-Group Originator ID of a received Path message may also be
   changed in the outgoing Path message and set to that of the LSR
   originating orig-
   inating the Path message based on a local policy. For instance a LSR
   may decide to always change the Sub-Group Originator ID while
   performing per-
   forming ERO expansion. The Sub-Group ID MUST not be changed if the
   Sub-Group Originator ID is not being changed.

4.3.

5.2.4. Control of Branch Fate Sharing

   An ingress LSR can control the behavior of an LSP if there is a fail-
   ure 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 [TBA] of
   the Attributes Flags TLV. The bit is set if LSP integrity is
   required.

   It is RECOMMENDED to use the LSP_ATTRIBUTES Object for this flag and
   not the LSP_REQUIRED_ATTRIBUTES Object.

   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 carrying the error "Routing Error"/"Unsupported LSP
   Integrity"

5.3. Grafting

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

4.3.1. Addition of S2L Sub-LSPs

   There are two methods to add S2L sub-LSPs to a P2MP LSP Tunnel. LSP.  The first
   is to add new S2L sub-LSPs to the P2MP LSP Tunnel 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 Tunnel. 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 11.1. 10.1.
   The egress LSRs can be added/removed added by signaling only the impacted S2L sub-LSPs sub-
   LSPs in a new Path message. Hence other S2L sub-LSPs do not have to
   be re-signaled.

5.

6. Resv Message

5.1.

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 descriptor
   list> ]

   <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                            [ <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 SEC-
   ONDARY_EXPLICIT_ROUTE> ]
   FILTER_SPEC is defined in section 20.4.

   The S2L sub-LSP descriptor has the same format as in section 4.1 with
   the difference that a SUB_RECORD_ROUTE P2MP_SECONDARY_RECORD_ROUTE object is used in
   place of a
   SUB_EXPLICIT_ROUTE P2MP SECONDARY_EXPLICIT_ROUTE object.

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

   <S2L sub-LSP filte descriptor> ::= <S2L_SUB_LSP> [ <SUB_RECORD_ROUTE>
   ] The SUB_RECORD_ROUTE P2MP_SEC-
   ONDARY_RECORD_ROUTE objects follow the same compression mechanism as
   the SUB_EXPLICIT_ROUTE P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv message mes-
   sage can signal multiple S2L sub-LSPs that may belong to the same
   FILTER_SPEC object or different FILTER_SPEC objects. The same label is
   SHOULD be allocated if the <Source Address, LSP-ID> fields of the
   FILTER_SPEC object is are the same.

   However different upstream labels are allocated if the <Source
   Address, LSP-ID> of the FILTER_SPEC object is different as that
   implies different P2MP LSP Tunnels.

5.2. LSP.

6.2. Resv Message Processing

   The egress LSR follows MUST follow normal RSVP procedures while originating a
   Resv message. The Resv message carries the label allocated by the
   egress LSR.

   A subsequent node MUST allocates its own label and passes pass it upstream in the
   Resv message. message upstream. The node may MAY combine multiple flow descriptors, descrip-
   tors, from different Resv messages received from downstream, in one
   Resv message sent upstream. A Resv message is not MUST NOT be sent upstream by a
   transit LSR
   until at least one Resv message has been received from a downstream neighbor except when
   neighbor. When the integrity bit is set in the LSP_ATTRIBUTE object. object,
   no Resv message MUST be sent upstream until all Resv messages have
   been received from the downstream neighbors.

   Each FF flow descriptor or SE filter spec sent upstream in a Resv
   message includes a S2L sub-LSP descriptor list. Each such FF flow
   descriptor or SE filter spec for the same P2MP LSP Tunnel (whether on one or
   multiple Resv messages) is MUST be allocated the same label.

   This label is associated by that node with all the labels received
   from downstream Resv messages for that P2MP LSP Tunnel. 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 Tunnel from
   the ingress-LSR to the egress LSRs.

   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 can potentially send one Resv message upstream for
   each of the downstream receivers. This may MAY result in overflowing the
   Resv message, particularly when considering that the number of
   messages mes-
   sages increases the closer the branch node is to the ingress.

   Transit nodes MUST replace the Sub-Group ID fields received in the
   FILTER_SPEC objects with the value that was received in the Sub-Group
   ID field of the Path message from the upstream neighbor, when the
   node set the Sub-Group Originator field in the associated Path
   message. mes-
   sage.  ResvErr message messages generation is unmodified.  Nodes propagating
   a received ResvErr message MUST use the Sub-Group field values carried car-
   ried in the corresponding Resv message.

   The solution for this issue is for further discussion.

5.2.1.

6.2.1. Resv Message Throttling

   A branch node needs may have to send the Resv message being sent upstream
   whenever there is a change in a Resv message for a S2L sub-LSP
   received from downstream. This can result in excessive Resv messages
   sent upstream, particularly when the S2L sub-LSPs are established for
   the first time.  In order to mitigate this situation, branch nodes
   MAY
   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 SRRO objects, the branch node SHOULD transmit the Resv message
   only after a delay time has passed since the transmission of the
   previous pre-
   vious Resv message for the same session. This delayed Resv message
   SHOULD include SRROs for all branches. Specific mechanisms for Resv
   message throttling are implementation dependent and are outside the
   scope of this document.

5.3.

6.3. Record Routing

5.3.1.

6.3.1. RRO Processing

   A Resv message contains a recorded record route per S2L sub-LSP that is being
   signaled by the Resv message if the sender node requests route
   recording by including a RRO in the Path message. The same rule is
   used during signaling of P2MP LSP Tunnels. Thus i.e. insertion of the RRO in the
   Path message used to signal one or more S2L sub-LSPs sub-LSP triggers the
   inclusion of an RRO for each sub-LSP signaled in that Path
   message or any derivative Path message. sub-LSP.

   The record route of the first S2L sub-LSP is encoded in the RRO.
   Additional RROs for the subsequent S2L sub-LSPs are referred to as
   SUB_RECORD_ROUTE
   P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is specified speci-
   fied in section 20.6. 20.5. The ingress node then receives the RRO and
   possibly the SRRO  corresponding to each subsequent S2L sub-LSP. Each
   S2L_SUB_LSP object is followed by the RRO/SRRO. The ingress node can
   then determine the recorded record route corresponding to a particular S2L
   sub-LSP. The RRO and SRROs can be used to construct the end-to-end end to end
   Path for each S2L sub-LSP.

6.

6.4. Reservation Style

   TBD

   Considerations about the reservation style in a Resv message apply as
   described in [RFC3209]. The reservation style in the Resv messages
   can either be FF or SE. All P2MP LSP 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. The S2L sub-LSPs that belong
   to different P2MP LSP MUST NOT share labels. If the reservation style
   is FF than S2L Sub-LSPs that belong to different P2MP LSP MUST NOT
   share resources. If the reservation style is SE than S2L sub-LSPs
   that belong to different P2MP LSP and the same P2MP Tunnel SHOULD
   share resources where they share hops, but MUST not share labels.

7. PathTear Message

7.1. PathTear message 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> ]

                 <sender descriptor> ::= (see earlier definition)

   Note: it is assumed that the S2L sub-LSP descriptor will not include
   the SUB_EXPLICIT_ROUTE P2MP SECONDARY_EXPLICIT_ROUTE object associated with each
   S2L_SUB_LSP being deleted

7.2. Pruning

   The operation of removing egress LSR(s) from an existing P2MP LSP
   Tunnel is
   termed as pruning. This operation allows egress nodes to
   leave be removed
   from a P2MP LSP Tunnel at different points in time. This section describes various
   the mechanisms to perform pruning. Further discussion
   and feedback is needed to finesse these mechanisms.

7.2.1. Explicit Implicit S2L Sub-LSP Teardown

   The

   Implicit teardown uses standard RSVP message processing. Per standard
   RSVP processing, a S2L sub-LSP(s) being sub-LSP may be removed from the a P2MP TE LSP Tunnel are
   signaled in by
   sending a PathTear message. The PathTear modified message includes the S2L
   sub-LSP descriptor list which is included before for the sender
   descriptor. Note Path or Resv message that previ-
   ously advertised the PathTear S2L sub-LSP. This message contains only the MUST list all S2L sub-
   LSP(s)
   LSPs that are not being removed and rest of the removed. When using this approach, a node
   processing a message that removes a S2L sub-LSP from a P2MP TE LSP Tunnel does not have to
   be re-signaled. This results in removal of the state corresponding to
   these S2L sub-LSPs. State for rest of
   MUST ensure that the S2L sub-LSPs sub-LSP is not
   modified.

   In the first mechanism included in order 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, sub-LSPs, by
   modifying a Path message, a transit LSR may have to generate a
   PathTear message is sent with the list downstream to delete one or more of these S2L sub-LSPs being deleted. sub-
   LSPs. This is can happen if as a form result of explicit tear down. A single PathTear message can
   only contain the implicit deletion of S2L
   sub-LSP(s) there are no remaining S2L sub-LSPs that were signaled by to send in the ingress using corre-
   sponding Path message downstream.

7.2.2. Explicit S2L Sub-LSP Teardown

   Explicit S2L Sub-LSP teardown relies on generating a PathTear message
   for the
   same <Sub-Group Originator ID, Sub-Group ID> tuple. corresponding Path message. The PathTear message is signaled
   with the SESSION and SENDER_TEMPLATE objects corresponding to the
   P2MP LSP Tunnel and the <Sub-Group Originator ID, Sub-Group ID> tuple corresponding corre-
   sponding to the S2L sub-LSPs that are
   being deleted. A transit 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 to generate the last previous
   Path message that corresponds to the S2L sub-LSPs
   signaled being deleted by it
   in the PathTear message that it generates. message.  The transit LSR may need to generate multiple multi-
   ple PathTear messages for an incoming PathTear message if it had performed per-
   formed transit fragmentation for the corresponding incoming Path message.

   The Path messages from which the S2L sub-LSPs were deleted need to be
   refreshed with the remaining S2L sub-LSPs. Note that as mes-
   sage.

   When a result of
   deleting one or more S2L sub-LSPs from P2MP LSP is removed by the ingress, a PathTear message MUST be
   generated for each Path message the ERO
   compression encoding may have used to be recomputed.

   When signal the last S2L sub-LSP P2MP LSP.

8. Notify and ResvConf Messages

   This section is to currently under discussion between the authors and
   will be removed from a Path state, i.e.,
   there updated in the next revision.

   Notify Request and Notify messages are no remaining S2L sub-LSPs to send described in [RFC3473].  If a Path message, a
   PathTear message SHOULD be sent carrying
   transit router sets the Sub-Group sub-group originator ID of in the SENDER_TEM-
   PLATE object of a Path message that no longer has any S2L sub-LSPs.

   The second mechanism is an explicit teardown mechanism that defines
   new syntax and semantics for a PathTear message. This new mechanism
   minimizes signaling required to remove its own address and the Path mes-
   sage carries a subset of S2L sub-LSPs Notify Request object then the router MUST set
   signaled the
   notify node address in a Path message, and thereby reduces associated
   processing.  When using the Notify Request object to its own address.
   If this mechanism each identified S2L sub-LSP is
   removed router receives a corresponding Notify message from down-
   stream than it MUST generate a Notify message upstream towards the P2MP LSP Tunnel state, even if the S2L sub-LSP is
   advertised
   Notify node address that the router had received in multiple the incoming Path
   message.

   When using this approach, a PathTear message is generated. The
   PathTear receiver of a Notify message MUST identify each S2L sub-LSP to be removed, via a
   S2L_SUB_LSP object per S2L Sub-LSP, the sender
   state referenced in the message based on the SESSION and SENDER_TEM-
   PLATE objects.

   ResvConf messages are described in [RFC2205]. An egress LSR may
   include a SENDER_TEMPLATE RESV_CONFIRM object corresponding to the Path state being modified. The Sub-Group
   ID valued contained in that contains the SENDER_TEMPLATE egress LSR's address.
   If a transit LSR is merging Resv messages received from more than
   egress LSR and one or more of these Resv messages contain a RESV_CON-
   FIRM object message than the transit LSR MUST be set
   to zero (0). Subsequent Path messages associated with its own address in the P2MP LSP
   Tunnel MUST NOT contain
   RESV_CONFIRM object in the removed S2L sub-LSPs, unless Resv message that S2L
   sub-LSP is being re-added to it generates. Also if
   the P2MP LSP.

   To support transit LSR changes the second mechanism, sub-group originator ID in the receiver of PathTear generated
   Resv message
   that is associated with and it includes a P2MP LSP Tunnel RESV_CONFIRM object in the Resv mes-
   sage, it MUST check set its own address in the value of RESV_CONFIRM object.  Upon
   receiving a
   received Sub-Group ID fields.  When there is no SENDER_TEMPLATE
   object present or ResvConf message from upstream the value transit LSR MUST gen-
   erate a ResvConf message towards each of the Sub-Group ID fields is non-zero,
   then PathTear processing as defined downstream LSRs that had
   included RESV_CONFIRM objects in the above explicit tear down
   mechanism must be followed.  When the Sub-Group ID field is zero (0),
   then corresponding Resv messages.  As
   with Notify messages, the processing node MUST remove receiver of a ResvConf message MUST iden-
   tify the identified egresses from all
   control plane state associated with referenced in the message based on the SESSION and
   FILTER_SPEC objects.

9. Refresh Reduction

   The refresh reduction procedures described in [RFC2961] are equally
   applicable to P2MP LSP Tunnel described in this document. Refresh reduction
   applies to individual messages and adjust the data path appropriately.

7.2.2. Implicit S2L Sub-LSP Teardown

   The third mechanism state they install/maintain,
   and that continues to delete S2L sub-LSPs is implicit teardown which
   uses standard RSVP message processing. Per standard RSVP processing,
   a S2L sub-LSP may be removed from a the case for P2MP TE LSP LSP.

10. State Management

   State signaled by sending a modified
   message for the P2MP 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 a S2L sub-LSP from is managed by a P2MP TE LSP MUST ensure that local implemen-
   tation using the
   S2L sub-LSP is not included in any other Path state associated with
   session before interrupting <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of
   the data path to that egress.  All other
   message processing remains unchanged.

7.2.3. P2MP TE SESSION object and <Tunnel Sender Address, LSP Teardown

   This operation is accomplished by listing all ID, Sub-Group
   Originator ID, Sub-Group ID> as part of the S2L sub-LSPs SENDER_TEMPLATE object.

   Additional information signaled in a
   PathTear message.

   A PathTear message must be generated for each the Path message used to
   signal is part of the P2MP LSP Tunnel.

8. Notify
   state created by a local implementation. This mandatorily includes
   PHOP and ResvConf Messages

   Notify messages, see [RFC3473], may contain either SENDER_TEMPLATE or
   FILTER_SPEC objects, but are sent in a targeted fashion. This means
   that the Sub-Group fields cannot be updated in transit and is
   unlikely to provide any value to the Notify message recipient.
   Therefore, the receiver of a Notify message MUST identify the sender
   state referenced in the message based on the Source address and LSP
   ID contained in the received SENDER_TEMPLATE or FILTER_SPEC objects
   rather than, as is normally done, based on the whole objects.

   ResvConf messages may contain FILTER_SPEC objects and may also be
   sent in a targeted fashion.  As with Notify messages, the receiver of
   a ResvConf message MUST identify the state referenced in the message
   based on the address and LSP ID contained in the received FILTER_SPEC
   object rather than, as is normally done, based on the whole objects.

9. Error Processing

   Note that a 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. In case the ingress node
   requests the maintenance of the 'LSP Integrity', any error reported
   within the P2MP TE LSP must be reported at (least at) any other
   branching nodes belonging to this LSP. Therefore, reception of an
   error message for a particular S2L sub-LSP MAY change the state of
   any other S2L sub-LSP of the same P2MP TE LSP.

9.1. PathErr Message Format

   A PathErr message will include one or more S2L_SUB_LSP objects. The
   resulting modified format of 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 messages 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 SENDER_TSPEC object.

10.1. Incremental State Update

   RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
   GMPLS [RFC3473] uses the PathErr
   message with the value that was received same basic approach to state communication
   and synchronization, namely full state is sent in the Sub-Group fields of
   the each state adver-
   tisement message. Per [RFC2205] Path and Resv messages are idempo-
   tent. Also, [RFC2961] categorizes RSVP messages into two types: trig-
   ger and refresh messages and improves RSVP message from the upstream neighbor. Note the receiver handling and scal-
   ing of a
   PathErr message is able to identify state refreshes but does not modify the errored outgoing full state advertise-
   ment nature of Path
   message, and outgoing interface, based on the Sub-Group fields
   received in the error message.

9.2. Handling Resv messages. The full state advertisement
   nature of Failures at Branch LSRs

   During setup Path and during normal operation, PathErr Resv messages may be
   received at a branch node. In all cases, a received PathErr message has many benefits, but also has some
   drawbacks. One notable drawback is first processed per standard processing rules. That is, the
   PathErr message when an incremental modification
   is sent hop-by-hop being made 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 previously advertised state. In this case, there
   is under the control message overhead of sending the ingress LSR.

   The default behavior is that the PathErr does not have the
   Path_State_Removed flag set. However, if the ingress LSR has set the
   'LSP Integrity' flag on full state and the Path message (see LSP_ATTRIBUTE object in
   section 21.3) cost of
   processing it. It is desirable to overcome this drawback and if
   add/delete S2L sub-LSPs to a P2MP LSP by incrementally updating the Path_State_Removed flag
   existing state.

   It is supported, possible to use the
   LSR generating a PathErr procedures described in this document to report
   allow S2L sub-LSPs to be incrementally added or deleted from the failure of P2MP
   LSP by allowing a branch of Path or a PathTear message to incrementally change
   the existing P2MP LSP Tunnel SHOULD set Path state.

   As described in section 4.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 Path_State_Removed flag.

   A branch LSR that receives SENDER_TEMPLATE
   object.  In order to perform incremental S2L sub-LSP state addition a PathErr
   separate Path message with the
   Path_State_Removed flag clear MUST act according a new sub-Group ID is used to add the wishes of new
   S2L sub-LSPs, by the ingress LSR. The default behavior is that Sub-Group Originator ID MUST be
   set to the branch LSR forwards TE Router ID [RFC3477] of the
   PathErr upstream and takes no further action. However, if node that sets the LSP
   integrity flag is set on Sub-Group
   ID.

   This maintains the idempotent nature of RSVP Path message, the branch LSR MUST send
   PathTear on all downstream branches messages; avoids
   keeping track of individual S2L sub-LSP state expiration and send the PathErr upstream
   with the Path_State_Removed flag set (per [RFC3473]).

   In all cases, provides
   the PathErr message forwarded by ability to perform incremental P2MP LSP state updates.

10.2. Combining Multiple Path Messages

   There is a branch LSR MUST
   contain tradeoff between the S2L sub-LSP identification and explicit routes number of all
   branches that are errored (reported by received PathErr messages) and
   all branches that are explicitly torn Path messages used by the branch LSR.

10. Refresh Reduction

   The refresh reduction procedures described in [RFC2961] are equally
   applicable
   ingress to maintain the P2MP LSP Tunnels described in this document. Refresh
   reduction applies to individual messages and the processing imposed by full
   state they
   install/maintain, and that continues messages when adding S2L sub-LSPs to be an existing Path message.
   It is possible to combine S2L sub-LSPs previously advertised in dif-
   ferent Path messages in a single Path message in order to reduce the
   number of Path messages needed to maintain the case for P2MP LSP
   Tunnels.

11. State Management

   State signaled LSP. This can
   also be done by a P2MP transit node that performed fragmentation and at a
   later point is able to combine multiple Path messages that it gener-
   ated into a single Path message. This may happen when one or more S2L
   sub-LSPs are pruned from the existing Path states.

   The new Path message is managed signaled by an implementation
   using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of node that is combining multi-
   ple Path messages with all the
   SESSION object S2L sub-LSPs that are being combined
   in a single Path message. This Path message MAY contain a new Sub-
   Group ID field value.  When a new Path and <Tunnel Sender Address, LSP ID, Sub-Group
   Originator ID, Sub-Group ID> as part Resv message that is sig-
   naled for an existing S2L sub-LSP is received by a transit LSR, state
   including the new instance of the SENDER_TEMPLATE object.

   Additional information signaled 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 part of received by the combining
   node. Hence until this point state created by an implementation. This mandatorily includes PHOP
   and SENDER_TSPEC objects.

11.1. Incremental State Update

   RSVP as defined in [RFC2205] and for the S2L sub-LSP SHOULD be
   maintained as extended by RSVP-TE [RFC3209] and
   GMPLS [RFC3473] uses part of the same basic approach to Path state communication for both the old and synchronization, namely full state is sent in each state
   advertisement message. Per [RFC2205] the new
   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 [Section 3.1.3, 2205]. At that point the full state
   advertisement nature of S2L sub-LSP
   SHOULD be deleted from the old Path and Resv messages. The full state
   advertisement nature using the procedures of
   section 7.

   A 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 with a sub-Group_ID(n) may signal a set of sending S2L sub-
   LSPs that belong partially or entirely to an already existing Sub-
   Group_ID(i), the full state SESSION object and <Sender Tunnel Address, LSP-ID,
   Sub-Group Originator ID> being the
   cost same. Or it may signal a strictly
   non-overlapping new set of processing it. It is desirable to overcome this drawback and
   add/delete S2L sub-LSPs to with a strictly higher sub-
   Group_ID value.

   1) If sub-Group_ID(i) = sub-Group_ID(n), then either a P2MP LSP Tunnel by incrementally
   updating the existing state.

   It full refresh
   is possible to use indicated by the procedures described in this document to
   allow Path message or a S2L sub-LSPs to be incrementally Sub-LSP is added or deleted to/deleted
   from the P2MP
   LSP group signaled by allowing a sub-Group_ID(n)

   2) If sub-Group_ID(i) != sub-Group_ID(n), then the Path or a PathTear message is
   signaling a set of S2L sub-LSPs that belong partially or entirely to incrementally change
   the
   an already existing P2MP LSP Tunnel Path state.

   As described in section 4.2, multiple Path messages can be used to
   signal Sub-Group_ID(i) or a P2MP LSP Tunnel. The Path strictly non-overlapping set
   of S2L sub-LSPs.

11. Error Processing

   PathErr and ResvErr messages are distinguished by
   different <Sub-Group Originator ID, Sub-Group ID> tuples in processed as per RSVP-TE procedures.
   Note that a LSR on receiving a PathErr/ResvErr message for a particu-
   lar S2L sub-LSP changes the
   SENDER_TEMPLATE object. state only for that S2L sub-LSP. Hence
   other S2L sub-LSPs are not impacted. In order case the ingress node
   requests the maintenance of the 'LSP integrity', any error reported
   within the P2MP TE LSP must be reported at (least at) any other
   branching nodes belonging to perform incremental this LSP. Therefore, reception of an
   error message for a particular S2L sub-LSP MAY change the state addition a separate Path of
   any other S2L sub- LSP of the same P2MP TE LSP.

11.1. PathErr Messages

   The PathErr message with will include one or more S2L_SUB_LSP objects. The
   resulting modified format for a new sub-Group ID 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 messages generation is
   used to add the new S2L sub-LSPs, by unmodified, but nodes that set the ingress LSR. The
   Sub-Group Originator ID field and propagate a received PathErr message
   upstream MUST be set to the TE Router ID [RFC3477] of the node
   that sets replace the Sub-Group ID.

   This maintains fields received in the idempotent nature of RSVP Path messages; avoids
   keeping track of individual S2L sub-LSP state expiration and provides PathErr
   message with the ability to perform incremental P2MP LSP Tunnel state updates.

11.2. Combining Multiple Path Messages

   There is a tradeoff between value that was received in the number Sub-Group fields of Path messages used by
   the
   ingress to maintain the P2MP LSP Tunnel and using full state refresh
   to add S2L sub-LSPs. It is possible to combine S2L sub-LSPs
   previously advertised in different Path messages into a single Path message in order to reduce from the number of Path messages needed to
   maintain upstream neighbor.  Note the P2MP LSP. This can also be done by a transit node that
   performed fragmentation and at receiver of a later point
   PathErr message is able to combine
   multiple Path messages that it generated into a single identify the errored outgoing Path mes-
   sage, and outgoing interface, based on the Sub-Group fields received
   in the PathErr message.
   This may happen when

11.2. ResvErr Messages

   The ResvErr message will include one or more S2L sub-LSPs are pruned from the
   existing Path states. S2L_SUB_LSP objects. The new Path message
   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 messages generation is signaled by the node unmodified, but nodes that is combining
   multiple Path messages with all set the S2L sub-LSPs that are being
   combined in a single Path message. This Path message contains a new
   Sub-Group ID Originator field value. When a new Path and Resv message that is
   signaled for an existing S2L sub-LSP is received by propagate a transit LSR,
   state including the new instance of received ResvErr message
   downstream MUST replace the S2L sub-LSP is created.

   The S2L sub-LSP SHOULD continue to be advertised Sub-Group fields received in both the old and
   new Path messages until a Resv ResvErr
   message listing with the S2L sub-LSP and
   corresponding to value that was set in the Sub-Group fields of the new
   Path message is received by sent to the combining
   node. Hence until this point state for downstream neighbor. Note the S2L sub-LSP SHOULD be
   maintained as part receiver of a
   ResvErr message is able to identify the errored outgoing Path state for both the old mes-
   sage, and outgoing interface, based on the new
   Path message [Section 3.1.3, 2205]. At that point the S2L sub-LSP
   SHOULD be deleted from Sub-Group fields received
   in the old Path state using a PathTear ResvErr message.
   The S2L sub-LSP should also be removed from the old Path message

11.3. Branch Failure Handling

   During setup and
   the old Path message should during normal operation, PathErr messages may be signaled again, if there are other
   remaining S2L sub-LSPs in
   received at a branch node. In all cases, a received PathErr message
   is first processed per standard processing rules. That is: the old
   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
   Path message.

   A Path  Intermediate nodes until this ingress/branch LSR MAY
   inspect this message with but take no action upon it. The behavior of a Sub-Group_ID(n+1) may signal
   branch LSR that generates a set PathErr message is under the control of S2L sub-
   LSPs
   the ingress LSR.

   The default behavior is that belong partially or entirely to an already existing Sub-
   Group_ID(i), i <= n, the SESSION object and <Sender Tunnel Address,
   LSP-ID, Sub-Group Originator ID> being PathErr does not have the same. Or it may signal a
   strictly non-overlapping new
   Path_State_Removed flag set. However, if the ingress LSR has set of S2L sub-LSPs with a strictly
   higher Sub-Group_ID value.

   1) If Sub-Group_ID(i) = Sub-Group_ID(n+1), i =< n then either a full
   refresh is indicated by the
   'LSP integrity' flag on the Path message or a S2L Sub-LSP (see LSP_ATTRIBUTE object in
   section 20) and if the Path_State_Removed flag is added
   to/deleted from supported, the group signaled by Sub-Group_ID(n+1)

   2) If Sub-Group_ID(i) != Sub-Group_ID(n+1), i =< n then LSR
   generating a PathErr to report the Path
   message is signaling failure of a set branch of S2L sub-LSPs the P2MP
   LSP SHOULD set the Path_State_Removed flag.

   A branch LSR that belong partially or
   entirely to an already existing Sub-Group_ID(i) or receives a strictly non-
   overlapping PathErr message with the
   Path_State_Removed flag set MUST act according to the wishes of S2L sub-LSPs.

12. Control of Branch Fate Sharing

   An the
   ingress LSR. The default behavior is that the branch LSR can control clears the behavior
   Path_State_Removed flag on the PathErr and sends it further upstream.
   It does not tear any other branches of an LSP the LSP. However, if there is a
   failure during LSP setup or after an the LSP has been established. The
   default behavior
   integrity flag is that only set on the branches Path message, the branch LSR MUST send
   PathTear on all downstream of branches and send the failure
   are not established, but PathErr message
   upstream with the ingress may request 'LSP integrity' such Path_State_Removed flag set.

   A branch LSR that any failure anywhere within the LSP tree causes receives a PathErr message with the entire P2MP
   LSP Tunnel
   Path_State_Removed flag clear MUST act according to fail.

   The ingress LSP may request 'LSP integrity' by setting bit [section
   21.3] the wishes of the Attributes Flags TLV.
   ingress LSR. The bit default behavior is set that the branch LSR forwards the
   PathErr upstream and takes no further action. However, if the LSP
   integrity flag is
   required.

   It is RECOMMENDED to use set on the LSP_ATTRIBUTES Object for this flag and
   not Path message, the LSP_REQUIRED_ATTRIBUTES Object.

   A branch LSR that supports the Attributes Flags TLV and recognizes
   this bit MUST support LSP integrity or reject send
   PathTear on all downstream branches and send the LSP setup PathErr upstream
   with the Path_State_Removed flag set (per [RFC3473]).

   In all cases, the PathErr message forwarded by a branch LSR MUST con-
   tain the S2L sub-LSP identification and explicit routes of all
   branches that are reported by received PathErr carrying messages and all
   branches that are explicitly torn by the error "Routing Error"/"Unsupported LSP
   Integrity"

13. branch LSR.

12. Admin Status Change

   A branch node that receives an ADMIN_STATUS object processes it
   normally nor-
   mally 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 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 messsage) on all
   branches before relaying a corresponding Resv message upstream.

14.

13. Label Allocation on LANs with Multiple Downstream Nodes

   A sender on a LAN uses a different label for sending traffic to each
   node on the LAN that belongs to the P2MP LSP Tunnel. LSP. Thus the sender
   performs per-
   forms replication. It may be considered desirable on a LAN to use the
   same label for sending traffic to multiple nodes belonging to the
   same P2MP LSP Tunnel, LSP, to avoid replication. Procedures for doing this are
   for further study. Given

14. P2MP LSP and Sub-LSP Re-optimization

   It is possible to change the relatively small number path used by P2MP LSPs to reach the des-
   tinations of receivers
   on LANs typically deployed in MPLS networks, this the P2MP Tunnel. There are two methods that can be used
   to accomplish this.  The first is not currently
   seen as a practical problem. Furthermore avoiding replication at the
   sender on a LAN requires significant complexity  make-before-break, defined in
   [RFC3209], and the control plane.
   Given the tradeoff we propose the use of replication by second uses the sender on
   a LAN.

15. sub-groups defined above.

14.1. Make-before-break

   Let's consider the following cases where make-before-break is needed:

15.1. P2MP Tree Re-optimization

   In this case all the S2L sub-LSPs are signaled with a different LSP
   ID by the ingress-LSR and follow make-before-break procedure defined
   in [RFC3209]. Thus a new P2MP LSP Tunnel instance is established. Each S2L sub-LSP is
   signaled with a different LSP ID, corresponding to the new P2MP TE LSP. The ingress can, after
   After moving traffic to the new
   instance, P2MP LSP, the ingress can tear down
   the previous old P2MP LSP Tunnel instance.

15.2. Re-optimization LSP. This procedure can be used to re-optimize the path
   of the entire P2MP LSP or paths to a subset of S2L sub-LSPs

   One way to accomplish re-optimization the destinations of
   the P2MP LSP. When modifying just a subset portion of S2L sub-LSPs
   that belong to a the P2MP LSP Tunnel is to resignal this
   approach requires the entire tree with P2MP LSP to be resignaled.

14.2. Sub-Group Based Re-optimization

   Any node may initiate re-optimization of a new LSP-ID as described in the previous subsection.

   (There is NO-CONSENSUS between the authors on rest set of S2L sub-LSPs by
   using the text in
   this subsection incremental state update and it needs further discussion.)

   It is possible to accomplish re-optimization then, optionally, combining
   multiple path messages.

   To alter the path taken by a particular set of S2L sub-LSPs the node
   initiating the path change initiates one or more S2L sub-
   LSPs without re-signaling rest of separate Path mes-
   sages, for the same P2MP LSP. To achieve this LSP, each with a
   sub-LSP ID is used to identify new sub-Group ID. The gen-
   eration of these Path messages, each with one or more S2L sub-LSP. This is encoded sub-LSPs,
   follows procedures in
   the S2L sub-LSP object. Each re-optimized S2L sub-LSP section 5.2. As is signaled
   with the case in Section 10.2, a different sub-LSP ID
   particular egress continues to be advertised in both the old and hence a new S2L sub-LSP is
   established. Once
   Path messages until a Resv message listing the egress and correspond-
   ing to the new setup Path message is complete, received by the old S2L sub-LSP can re-optimizing node. At
   that point the egress SHOULD be torn down. In some cases this deleted from the old Path state using
   the procedures of section 7.  Sub-tree re-optimization is then com-
   pleted.

   As is always the case, a node may result choose to combine multiple path
   messages as described in transient data
   duplication.

16. section 10.2.

15. Fast Reroute

   [RSVP-FR] extensions can be used to perform fast reroute for the
   mechanism described in this document.

16.1.

15.1. Facility Backup

   Facility backup as described in [RSVP-FR] can be used to protect P2MP
   LSP Tunnels.
   LSPs.

   If link protection is desired, a bypass tunnel is used to protect the
   link between the PLR and next-hop. Thus all S2L sub-LSPs that use the
   link can be protected in the event of link failure. Note that all
   such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
   will share the same outgoing label on the link between the PLR and
   the next-hop. This is the P2MP LSP label on the link. Label stacking
   is used to send data for each P2MP LSP in the bypass tunnel. The
   inner label is the P2MP LSP Tunnel label allocated by the nhop. During failure fail-
   ure Path messages for each S2L sub-LSP, that is effected, will be
   sent to the MP, by the PLR. 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 will use the LSP-ID to identify the corresponding corre-
   sponding S2L sub-LSPs.

   The MP MUST not use the <sub-group originator ID, sub-group ID> while
   identifying the corresponding S2L sub-LSPs.

   In order to further process a S2L sub-LSP it will determine the
   protected pro-
   tected S2L sub-LSP using the LSP-id and the S2L sub-LSP object.

   If node protection is desired, the bypass P2P tunnel must intersect
   the path of the protected S2L sub-LSPs somewhere on a LSR that is downstream of
   from the PLR. 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 com-
   mon downstream MP. This MP is the destination of the bypass tunnel.
   The MP will allocate the same label to all such S2L sub-LSPs belonging belong-
   ing to a particular instance of a P2MP tunnel. This will be the inner
   label used during label stacking. This stacking by the PLR when it sends data for
   each P2MP LSP in the bypass tunnel.  The outer label is the bypass
   tunnel label. During failure of the protected node the PLR will send
   Path messages for the protected S2L Sub-LSPs to the MP using proce-
   dures that are same as the link protection procedures described
   above. Node protection may require the PLR to be branch capable as
   multiple bypass tunnels may be required to backup the set of S2L sub-LSPs sub-
   LSPs passing through the protected node. Else all the S2L sub-LSPs being backed up
   passing through the protected node must also pass through a MP that
   is downstream from the same MP.

16.2. protected node.

15.2. One to One Backup

   One to one backup as described in [RSVP-FR] 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 share the same P2MP
   LSP Tunnel label.

   All or some of these S2L sub-LSPs may be protected.

   The detour S2L sub-LSPs may or may not share labels, depending on the
   detour path. Thus the set of outgoing labels and next-hops for a P2MP
   LSP Tunnel that was using a single next-hop and label between the PLR and
   next-hop before protection, may change once protection is triggerred.

   Its is recommended that the path specific method be used to identify
   a backup S2L sub-LSP. Hence the DETOUR object will be inserted in the
   backup Path message. A backup S2L sub-LSP MUST be treated as
   belonging belong-
   ing 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 3 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 applies to all the S2L sub-LSPs.

17.

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 Value "Routing Error" and Error Code
   "Unable to Branch".

   Its also conceivable that some LSRs, in a network deploying P2MP
   capability, may not support the extensions described in this
   document. docu-
   ment.  If a Path message for the establishment of a P2MP LSP
   Tunnel reaches
   such an LSR it will reject it with a PathErr because it will not recognize rec-
   ognize 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
   LSP-hierarchy [LSP-HIER]. Note that LSRs that are required to play
   any other role in the network (ingress, branch or egress) MUST support sup-
   port the extensions defined in this document.

   The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows P2MP LSP
   Tunnels to be built build
   P2MP LSPs in such an environment. A P2P LSP segment is signaled from
   the previous P2MP capable hop of a legacy LSR to the next P2MP capable capa-
   ble hop. Of course this assumes that intermediate legacy LSRs are
   transit LSRs and cannot act as P2MP branch points. Transit LSRs along
   this LSP segment do not process control plane messages associated
   with a P2MP LSP Tunnel. LSP. Furthermore these LSRs also do not need to have P2MP
   data plane capability as they only need to process data belonging to
   the P2P LSP segment. Hence these LSRs do not need to support P2MP
   MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP Tunnel. 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 Tunnel. LSP.

   In packet networks, the S2L sub-LSPs may be nested inside the outer
   P2P LSP Tunnel. LSP. Hence label stacking can be used to enable use of the same
   LSP Tunnel segment for multiple P2MP LSP Tunnels. LSP. Stitching and nesting considerations considera-
   tions and procedures are described further in [INT-
   REG]. [INT-REG].

   It may be an overhead for an operator to configure the P2P LSP
   segments seg-
   ments in advance, when it is desired to support legacy LSRs. It may
   be desirable to do this dynamically. The ingress can use IGP
   extensions exten-
   sions to determine non P2MP capable LSRs. LSRs [TE-NODE-CAP]. It can use
   this information to compute S2L sub-LSP paths such that they avoid
   these legacy LSRs. The explicit route object of a 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 upto 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 capa-
   ble LSR expands the loose hop using its 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] to the next P2MP capable LSR.

   This may be needed for the directed Path message Head-End to use node
   protection FRR 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.

18.

17. Reduction in Control Plane Processing with LSP Hierarchy

   It is possible to take advantage of LSP hierarchy [LSP-HIER] while
   setting up P2MP LSP Tunnels, 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 LSP Tunnel, LSP,
   do not process control plane messages associated with the P2MP LSP Tunnel. LSP.
   Infact they are not aware of these messages as they are tunneled over
   the P2P LSP segment. This reduces the amount of control plane processing pro-
   cessing required on these transit LSRs.

   Note that the P2P LSP segments can be dynamically set up setup as described
   in the previous section or preconfigured. For example in Figure 2,
   PE1 can setup 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 Tunnel and does not process the P2MP
   control messages.

19.

18. P2MP LSP Tunnel Remerging and Cross-Over

   This section is currently under discussion between the authors and
   will be updated in the next revision.

   The functional description described so far assumes that multiple
   Path messages received by a LSR for the same P2MP LSP Tunnel arrive on the
   same incoming interface. However this may not always be the case. Further discussion is needed for this section.

   P2MP tree remerging or cross-over occurs when a transit or egress
   node receives the signaling state i.e. Path message for the same P2MP
   TE LSP from more than one previous hop. If the re-merged remerged S2L sub-LSPs
   are sent out on different interfaces there is no data plane issue.
   However if the re-merged remerged S2L sub-LSPs are sent out on the same
   interface inter-
   face it can result in data duplication downstream. In order to
   describe identification of cross over and remerging by a LSR let us
   list the various cases when state for a S2L sub-LSP is received by a
   LSR.

   Case1: S2L sub-LSP already exist as part of an existing Path state.
   The following are the various sub-cases.
      a) The new S2L sub-LSP uses the same PHOP and outgoing interface
   as the existing S2L sub-LSP. This is either a refresh or can occur
   when multiple existing Path messages are combined in a new Path message. mes-
   sage.

      b) The new S2L sub-LSP uses the same PHOP but different outgoing
   interface as the existing S2L sub-LSP. This is a case of re-routing.
      c) The new S2L sub-LSP uses a different PHOP and same outgoing
   interface as the existing S2L sub-LSP. This is a case of re-merging. re-routing.
      d) The new S2L sub-LSP uses a different PHOP and a different outgoing out-
   going interface as compared to the existing S2L sub-LSP. This is a
   case of
   cross-over. re-routing.

   Case2: S2L sub-LSP does not exist as part of an existing Path state.
   The following are the sub-cases.
      a) The new S2L sub-LSP uses a PHOP and outgoing interface that is
   same as the PHOP and outgoing interface used by an existing S2L sub-
   LSP that belongs to the same P2MP LSP. This is a legal case of signaling sig-
   naling a new S2L sub-LSP.
      b) The new S2L sub-LSP uses a PHOP that is same as that used by an
   existing S2L sub-LSP. However the outgoing interface is different
   from the outgoing interfaces used by existing S2L sub-LSPs. sub-LSPs belonging
   to the same P2MP LSP. This is a legal case of signaling a new S2L
   sub-LSP.
      c) The new S2L sub-LSP uses a different PHOP than that used by any
   of the existing S2L sub-LSP. However sub-LSP that belong to the same P2MP LSP . How-
   ever the outgoing interface is same as the outgoing interface used by
   an existing S2L sub-LSPs. This is a case of remerging.
      d) The new S2L sub-LSP uses a different PHOP than that used by any
   of the existing S2L sub-LSP. sub-LSP that belong to the same P2MP LSP. Also
   the outgoing interface is different from the outgoing interfaces used
   by existing S2L sub-LSPs. This is a case of cross-over.

   Cases 1(d) and

   Case 2(d) above identify identifies cross-over and this is considered legal.  Cases 1(c) and
   Case 2(c) above identify identifies remerging in the data plane. If the LSR is
   capable of remerging in the data plane this is considered legal.

   The below procedure applies for remerging.

   The remerge error case is detected by checking incoming Path messages
   that represent new P2MP TE LSP state and seeing if they represent
   both known LSP state and a different S2L sub-LSP list. Specifically,
   the remerge check MUST be performed when processing Path messages
   that contain SESSION, SENDER_TEMPLATE and RSVP_HOP objects that have
   not previously been seen on a particular interface. The remerge check
   consists of attempting to locate state that has the same values in
   the SESSION object and in the tunnel sender address and LSP ID fields
   of the SENDER_TEMPLATE object.

   If no matching state is located, then there is no remerge condition.

   If matching state is found, then the list of S2L Sub-LSPs associated
   with the new Path message is compared against the list present in the
   located state.  If any addresses in the lists of S2L sub-LSPs match,
   then it is the legal LSP rerouting case mentioned here above.

   If there are no overlap in the lists, the node checks whether any of
   the outgoing interfaces, as identified by the ERO/SUB_EROs, are an
   outgoing interface already associated with the existing P2MP LSP. If
   not, then legal LSP crossing is being performed. Else re-merging has
   occurred and if the LSR is capable of remerging in the data plane,
   this is considered legal. Else In that case the LSR will return the label
   already associated with the existing S2L sub-LSP with the matching
   egress interface, in the Resv message it sends upstream. If the LSR
   is not capable of remerging in the data plane the new Path message
   MUST be handled according to remerge error processing as described
   below.

   The LSR generates a PathErr message with Error Code "Routing
   Problem/P2MP Prob-
   lem/P2MP Remerge Detected" towards the upstream node (i.e.  the node
   that sent the Path message) until it reaches the node that caused the
   remerge condition.  Identification of the offending node requires
   special processing by the nodes upstream of the error.  A node that
   receives a PathErr message that contains a the error "Routing Problem/P2MP Prob-
   lem/P2MP Remerge Detected" MUST check to see if it is the offending
   node. This check is done by comparing the S2L sub-LSPs listed in the
   PathErr message with existing LSP state. If any of the egresses are
   already present in any Path state associated with the P2MP TE LSP
   other than the one associated with the <SESSION, SENDER_TEMPLATE>
   objects signaled in the PathErr message, then the node is the signaling signal-
   ing branch node that caused the remerge condition. This node SHOULD
   then correct the remerge condition by adding all S2L sub-LSPs listed
   in the offending Path state to the Path state (and Path message)
   associated to these S2L sub-LSPs. Note that the new Path state may be
   sent out the same outgoing interface in different Path messages in
   order to meet IP packet size limitations.  If use of a new outgoing
   interface violates one or more SERO constraint, then a PathErr message mes-
   sage containing the associated egresses and any identified valid
   egresses SHOULD be generated with the error code "Routing Problem"
   and error value of "ERO Resulted in Remerge".

   This process may continue hop-by-hop until the ingress is reached.
   The only case where this process will fail is when all the listed S2L
   sub-LSPs 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.

   In all cases where a remerge error is not detected, normal processing
   continues.

20.

19. New and Updated Message Objects

   This section presents the new and updated RSVP message objects used object formats as modified by this
   document.

20.1. P2MP LSP Tunnel

19.1. SESSION Object

   A P2MP LSP Tunnel SESSION object is used. This object uses the existing SESSION SES-
   SION 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 part of the
   same P2MP LSP Tunnel 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 identify-
   ing a P2P Tunnel which in turn can contain multiple LSP
   Tunnels, LSPs, each distinguished dis-
   tinguished by a unique SENDER_TEMPLATE object.

20.1.1.

19.1.1. P2MP IPv4 LSP Tunnel IPv4 SESSION Object

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD TBA

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       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 ID and identifies the set of destinations of the P2MP
      LSP
      Tunnel.

   Tunnel ID
      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.

   Extended Tunnel ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  Normally set to
      all zeros. Ingress nodes that wish to narrow the scope of a
      SESSION to the ingress-PID pair may place their IPv4 address
      here as a globally unique identifier [RFC3209].

20.1.2.

19.1.2. P2MP IPv6 LSP Tunnel IPv6 SESSION Object

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

20.2.

19.2. SENDER_TEMPLATE object

   The sender template contains the ingress-LSR source address. LSP ID
   can be 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, but use different labels. 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
   Tunnel by
   using a <Sub-Group ID Originator ID, Sub-Group ID> tuple.
   There are various methods to encode this information. This document
   proposes the use of the The
   SENDER_TEMPLATE object and modifies it is modified to carry this information as shown
   below. This encoding is subject to
   review by the MPLS WG.

20.2.1.

19.2.1. P2MP IPv4 LSP Tunnel IPv4 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD TBA

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   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 a 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. If the third
            mechanism for pruning is used as described in section 7.2,
            the Sub-Group ID value of zero (0) has special meaning and
            MUST NOT be used with P2MP LSP Tunnels in messages other
            than PathTear messages. Use of a Sub-Group ID value of zero
            (0) in PathTear messages is defined below.

        LSP ID
           See [RFC3209]

20.2.2.

19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBD TBA

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                   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 a LSR which re-originates the Path
            message with its own Sub-Group Originator ID.

        Sub-Group ID
           As above.

        LSP ID
           See [RFC3209]

20.3.

19.3. S2L SUB-LSP IPv4 Object

   A new S2L Sub-LSP object identifies a particular S2L sub-LSP
   belonging belong-
   ing to the P2MP LSP Tunnel.

20.3.1. LSP.

19.3.1. S2L SUB-LSP IPv4 Object

   SUB_LSP Class = TBD, 50, S2L_SUB_LSP_IPv4 C-Type = TBD TBA

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 S2L Sub-LSP destination address        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |            Sub-LSP ID         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Sub-LSP destination address

      IPv4 address of the S2L sub-LSP destination.

   (There is NO-CONSENSUS amongst the authors on the sub-LSP ID
   described below and it needs more discussion)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Sub-LSP ID

      A 16-bit identifier that identifies a particular instance destination address

      IPv4 address of a S2L sub-LSP. It can be varied for the S2L sub-LSP
      make-before-break. Different S2L sub-LSPs, with the same SESSION
      object and LSP ID, follow the label merge semantics described in
      section 3 to form a particular instance of the P2MP tunnel.

20.3.2. destination.

19.3.2. S2L SUB-LSP IPv6 Object

   SUB_LSP Class = TBD, 50, S2L_SUB_LSP_IPv6 C-Type = TBD TBA

   This is same as the S2L IPv4 Sub-LSP object, with the difference that
   the destination address is a 16 byte IPv6 address.

20.4.

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

19.4. FILTER_SPEC Object

   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
   object.

20.4.1.

19.4.1. P2MP LSP_TUNNEL_IPv4 LSP_IPv4 FILTER_SPEC Object

   Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv4 LSP_IPv4 C-Type = TBD TBA

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

20.4.2.

19.4.2. P2MP LSP_TUNNEL_IPv4 LSP_IPv4 FILTER_SPEC Object

   Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv6 C_Type LSP_IPv6 C-Type = TBD TBA

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

20.5. SUB_EXPLICIT_ROUTE

19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

   The SERO P2MP Secondary Explicit Route Object (SERO) is defined as identical identi-
   cal to the ERO.  The CNums are TBD and
   TBD class of the form 11bbbbbb.

20.6. SUB_RECORD_ROUTE P2MP SERO is the same as the SERO
   defined in [RECOVERY] (TBA).  The P2MP SERO C-Type = TBA The sub-
   objects are identical to those defined for the ERO.

19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

   The SRRO P2MP Secondary Record Route Object (SRRO) is defined as identical
   to the RRO. ERO.  The CNums are TBD and
   TBD class of the form 11bbbbbb.

21. P2MP SRRO is the same as the SRRO
   defined in [RECOVERY] (TBA).  The P2MP SRRO C-Type = TBA.  The sub-
   objects are identical to those defined for the RRO.

20. IANA Considerations

21.1.

20.1. New Message Objects Class Numbers

   IANA considerations is requested to assign the following Class Numbers for the new message objects will
   object classes introduced. The Class Types for each of them are to be specified after
   assigned via standards action. The sub-object types for the objects used are decided upon.

21.2. P2MP SEC-
   ONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same
   IANA considerations as those of the ERO and RRO [RFC3209].

   50  Class Name = SUB_LSP

   C-Type
      1   S2L_SUB_LSP_IPv4 C-Type
      2   S2L_SUB_LSP_IPv6 C-Type

20.2. New Class Types

   IANA is requested to assign the following C-Type values:

   Class Name = SESSION

   C-Type
     13    P2MP_LSP_IPv4 C-Type
     14    P2MP_LSP_IPv6 C-Type

   Class Name = SENDER_TEMPLATE

   C-Type
     12    P2MP_LSP_IPv4 C-Type
     13    P2MP_LSP_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
   C-Type
      2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type

   Class Name = SECONDARY_RECORD_ROUTE

   C-Type
      2  P2MP_SECONDARY_RECORD_ROUTE C-Type

20.3. New Error Codes

   Two

   Four new Error Codes are defined for use with the Error Value "Routing
   Error". "Rout-
   ing Problem". IANA is requested to assign values.

   The Error Code "Unable to Branch" indicates that a P2MP branch cannot
   be formed by the reporting LSR. IANA is requested to assign value 20
   to this Error Code.

   The Error Code "Unsupported LSP Integrity" indicates that a P2MP
   branch does not support the requested LSP integrity function.

21.3. IANA is
   requested to assign value 21 to this Error Code.

   The Error Code "P2MP Remerge Detected" indicates that a node has
   detected remerge. IANA is requested to assign value 22 to this Error
   Code.

20.4. LSP Attributes Flags

   IANA has been asked to manage the space of flags in the Attibutes
   Flags TLV carried in the LSP_ATTRIBUTES Object [LSP-ATTRIB]. This
   document defines two new flags as follows:

   Suggested 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 Document:   12

   Suggested Bit Number:             4
   Meaning:                          Branch Reoptimization Allowed
   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 Document: TBD

22. Doc:   10

21. Security Considerations

   This document does not introduce any new security issues. The
   security secu-
   rity issues identified in [RFC3209] and [RFC3473] are still relevant.

23.

22. Acknowledgements

   This document is the product of many people. The contributors are
   listed in Section 25. 27.2.

   Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal
   Sheth for their suggestions and comments. Thanks also to Dino
   Farninacci Farni-
   nacci for his comments.

24.

23. Appendix

23.1. Example P2MP LSP Establishment

   Following is one example of setting up a P2MP LSP Tunnel using the
   procedures proce-
   dures 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.

   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>

   e) P1 receives a Resv message from PE4 with label L4. It had
   previously previ-
   ously received a Resv message from PE3 with label L3. It had
   allocated allo-
   cated 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}.

25.

24. References

25.1.

24.1. Normative References

      [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
                 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt. draft-ietf-mpls-lsp-hierarchy-08.txt, work in
                 progress.

      [LSP-ATTR] A. Farrel, et. al. , "Encoding of
                 Attributes for Multiprotocol Label Switching (MPLS)
                 Label Switched Path (LSP) Establishment Using RSVP-TE",
                 draft-ietf-mpls-rsvpte-attributes-03.txt,
                 draft-ietf-mpls-rsvpte-attributes-05.txt, March 2004,
                 work in progress.

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

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

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

      [RFC3471]  Lou Berger, et al., "Generalized MPLS - Signaling Functional
                 Description", RFC 3471, January 2003 2003, work in progress.

      [RFC3473]  L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE
                 Extensions", RFC 3473, January 2003. 2003, work in progress.

      [RFC2961]  L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
                 S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
                 RFC 2961, April 2001. 2001, work in progress.

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

      [RSVP-FRR] 2001, work in
                 progress.

      [RFC4090]  P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute Extensions
                 to RSVP-TE for LSP Tunnels",
                 draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt. work in progress.

      [RFC3477]  K. Kompella, Y. Rekther, "Signalling Unnumbered Links in
                 Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
                 work in progress .

      [P2MP-REQ] S. Yasukawa, et. al., "Requirements Editor "Signaling Requirements for
                 Point-to-Multipoint
                 capability extension to MPLS",
                 draft-ietf-mpls-p2mp-sig-requirement-00.txt.

25.2. Traffic Engineered MPLS LSPs",
                 draft-ietf-mpls-p2mp-sig-requirement-02.txt, work in progress.

      [RECOVERY] "GMPLS Based Segment Recovery",
                 draft-ietf-ccamp-gmpls-segment-recovery-02.txt

24.2. Informative References

      [BFD]      D. Katz, D. Ward, "Bidirectional Forwarding Detection",
                                                draft-katz-ward-bfd-01.txt.
              draft-katz-ward-bfd-01.txt, work in progress.

      [BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for MPLS
                 LSPs",
                 draft-raggarwa-mpls-bfd-00.txt draft-ietf-bfd-mpls-00.txt, work in progress.

      [IPR-1]    Bradner, S., "IETF Rights in Contributions", BCP 78,
                 RFC 3667, February 2004. 2004, work in progress.

      [IPR-2]    Bradner, S., Ed., "Intellectual Property Rights in IETF
                 Technology", BCP 79, RFC 3668, February 2004. 2004, work in progress.

      [INT-REG]  JP Vasseur, A. Ayyangar, "Inter-area and Inter-AS MPLS Traffic
                 Engineering",  draft-vasseur-ccamp-inter-area-as-te-00.txt.  draft-vasseur-ccamp-inter-area-as-te-00.txt,
                 work in progress.

      [RFC2209]  R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP)
                 Version 1 Message Processing Rules", RFC 2209.

      [RFC3477]  K. Kompella, Y. Rekther, "Signalling Unnumbered Links 2209, work in
                 Resource ReSerVation Protocol - progress.

      [LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path Stitching
                   with Generalized MPLS Traffic Engineering",
                   draft-ietf-ccamp-lsp-stitching-00.txt, April 2005
                   work in progress

      [TE-NODE-CAP] JP Vasseur, JL Le Roux, et al. "Routing extensions for
                    discovery of Traffic Engineering (RSVP-TE)".

26. Node Capabilities",
                    draft-vasseur-ccamp-te-node-cap-00.txt, February 2005,
                    work in progress

25. Author Information

26.1.

25.1. Editor Information

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

26.2.

25.2. Contributor Information

   John Drake
   Calient Networks
   Email: jdrake@calient.net

   Alan Kullberg
   Motorola Computer Group
   120 Turnpike Road 1st Floor
   Southborough, MA  01772
   EMail: alan.kullberg@motorola.com

   Lou Berger
   Movaz Networks, Inc.
   7926 Jones Branch Drive
   Suite 615
   McLean VA, 22102
   Phone: +1 703 847-1801
   EMail: lberger@movaz.com

   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

   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

   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

   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
   E-mail: jeanlouis.leroux@francetelecom.com

27.

26. 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 assur-
   ances 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.

28.

27. Full Copyright Statement

   Copyright (C) The Internet Society (2004). (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78 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 AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUNG
   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.

29.

28. Acknowledgement

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