idnits 2.17.1 

draft-ietf-mpls-rsvp-te-p2mp-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 22.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2196.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2209.

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748)
     Disclaimer -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

  ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 70 instances of too long lines in the document, the longest
     one being 9 characters in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Line 1213 has weird spacing: '...irst is  make-...'

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:
     
     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) and
     encoded in the SENDER_TEMPLATE object. Multiple Path messages 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
     globally unique. The sub-Group ID space is specific to the Sub-Group
     Originator ID. Therefore the combination <Sub-Group Originator ID,
     sub-Group ID> is network-wide unique. Also, a router that changes the
     Sub-Group originator ID of an incoming Path message MUST use the same
     value of the Sub-Group Originator ID for all outgoing Path messages, for
     a particular P2MP LSP, and SHOULD not vary it during the life of the P2MP
     LSP.

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     As described above one case in which the Sub-Group Originator ID of
     a received Path message is changed is that of transit fragmentation.
     Another case is when the Sub-Group Originator ID of a received Path
     message may be changed in the outgoing Path message and set to that of
     the LSR originating the Path message based on a local policy. For
     instance a LSR may decide to always change the Sub-Group Originator ID
     while performing ERO expansion. The Sub-Group ID MUST not be changed if
     the Sub-Group Originator ID is not being changed.

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     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.

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     The MP MUST not use the <sub-group originator ID, sub-group ID>
     while identifying the corresponding S2L sub-LSPs.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 2005) is 6766 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'KEYWORDS' is mentioned on line 148, but not defined

  == Missing Reference: 'TBA' is mentioned on line 621, but not defined

  == Missing Reference: 'LSP-ATTRIB' is mentioned on line 1880, but not
     defined

  == Unused Reference: 'LSP-ATTR' is defined on line 1973, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2119' is defined on line 1983, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3471' is defined on line 1992, but no explicit
     reference was found in the text

  == Unused Reference: 'BFD-MPLS' is defined on line 2025, but no explicit
     reference was found in the text

  == Unused Reference: 'IPR-1' is defined on line 2028, but no explicit
     reference was found in the text

  == Unused Reference: 'IPR-2' is defined on line 2031, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2209' is defined on line 2038, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-04) exists of
     draft-ietf-mpls-p2mp-sig-requirement-02

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-mpls-p2mp-sig-requirement (ref. 'P2MP-REQ')

  == Outdated reference: A later version (-03) exists of
     draft-ietf-ccamp-gmpls-segment-recovery-02

  == Outdated reference: A later version (-02) exists of
     draft-katz-ward-bfd-01

  == Outdated reference: A later version (-07) exists of
     draft-ietf-bfd-mpls-00

  -- Obsolete informational reference (is this intentional?): RFC 3667 (ref.
     'IPR-1') (Obsoleted by RFC 3978)

  -- Obsolete informational reference (is this intentional?): RFC 3668 (ref.
     'IPR-2') (Obsoleted by RFC 3979)

  == Outdated reference: A later version (-06) exists of
     draft-ietf-ccamp-lsp-stitching-00

  == Outdated reference: A later version (-01) exists of
     draft-vasseur-ccamp-te-node-cap-00


     Summary: 6 errors (**), 0 flaws (~~), 23 warnings (==), 7 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                               R. Aggarwal (Editor)
3	Internet Draft                                          Juniper Networks
4	Expiration Date: April 2006
5	                                               D. Papadimitriou (Editor)
6	                                                                 Alcatel

8	                                                    S. Yasukawa (Editor)
9	                                                                     NTT

11	                                                            October 2005

13	         Extensions to RSVP-TE for Point to Multipoint TE LSPs

15	                  draft-ietf-mpls-rsvp-te-p2mp-03.txt

17	Status of this Memo

19	   By submitting this Internet-Draft, each author represents that any
20	   applicable patent or other IPR claims of which he or she is aware
21	   have been or will be disclosed, and any of which he or she becomes
22	   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

40	Abstract

42	   This document describes extensions to Resource Reservation Protocol -
43	   Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered
44	   (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
45	   Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
46	   networks.  The solution relies on RSVP-TE without requiring a
47	   multicast routing protocol in the Service Provider core. Protocol
48	   elements and procedures for this solution are described. There can be
49	   various applications for P2MP TE LSPs such as IP multicast.
50	   Specification of how such applications will use a P2MP TE LSP is
51	   outside the scope of this document.

53	Table of Contents

55	 1          Conventions used in this document  .....................   5
56	 2          Terminology  ...........................................   5
57	 3          Introduction  ..........................................   5
58	 4          Mechanism  .............................................   5
59	 4.1        P2MP Tunnels  ..........................................   6
60	 4.2        P2MP LSP   .............................................   6
61	 4.3        Sub-Groups  ............................................   6
62	 4.4        S2L Sub-LSPs  ..........................................   7
63	 4.4.1      Representation of a S2L Sub-LSP  .......................   7
64	 4.4.2      S2L Sub-LSPs and Path Messages  ........................   7
65	 4.5        Explicit Routing  ......................................   8
66	 5          Path Message  ..........................................  10
67	 5.1        Path Message Format  ...................................  10
68	 5.2        Path Message Processing  ...............................  11
69	 5.2.1      Multiple Path Messages  ................................  12
70	 5.2.2      Multiple S2L Sub-LSPs in one Path message  .............  13
71	 5.2.3      Transit Fragmentation  .................................  14
72	 5.2.4      Control of Branch Fate Sharing  ........................  15
73	 5.3        Grafting  ..............................................  15
74	 6          Resv Message  ..........................................  16
75	 6.1        Resv Message Format  ...................................  16
76	 6.2        Resv Message Processing  ...............................  17
77	 6.2.1      Resv Message Throttling  ...............................  18
78	 6.3        Record Routing  ........................................  18
79	 6.3.1      RRO Processing  ........................................  18
80	 6.4        Reservation Style  .....................................  19
81	 7          PathTear Message  ......................................  19
82	 7.1        PathTear Message Format  ...............................  19
83	 7.2        Pruning  ...............................................  20
84	 7.2.1      Implicit S2L Sub-LSP Teardown  .........................  20
85	 7.2.2      Explicit S2L Sub-LSP Teardown   ........................  20
86	 8          Notify and ResvConf Messages  ..........................  21
87	 8.1        Notify Messages  .......................................  21
88	 8.2        ResvConf Messages  .....................................  22
89	 9          Refresh Reduction  .....................................  23
90	10          State Management  ......................................  23
91	10.1        Incremental State Update  ..............................  23
92	10.2        Combining Multiple Path Messages  ......................  24
93	11          Error Processing  ......................................  25
94	11.1        PathErr Messages  ......................................  25
95	11.2        ResvErr Messages  ......................................  26
96	11.3        Branch Failure Handling  ...............................  26
97	12          Admin Status Change  ...................................  27
98	13          Label Allocation on LANs with Multiple Downstream Nodes.  28
99	14          P2MP LSP and Sub-LSP Re-optimization  ..................  28
100	14.1        Make-before-break  .....................................  28
101	14.2        Sub-Group Based Re-optimization  .......................  28
102	15          Fast Reroute  ..........................................  29
103	15.1        Facility Backup  .......................................  29
104	15.2        One to One Backup  .....................................  30
105	16          Support for LSRs that are not P2MP Capable  ............  30
106	17          Reduction in Control Plane Processing with LSP Hierarchy. 32
107	18          P2MP LSP Remerging and Cross-Over  .....................  32
108	18.1        Procedures  ............................................  33
109	18.1.1      Re-Merge Procedures  ...................................  34
110	19          New and Updated Message Objects  .......................  36
111	19.1        SESSION Object  ........................................  36
112	19.1.1      P2MP LSP Tunnel IPv4 SESSION Object  ...................  36
113	19.1.2      P2MP LSP Tunnel IPv6 SESSION Object  ...................  37
114	19.2        SENDER_TEMPLATE object  ................................  37
115	19.2.1      P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object  ...........  38
116	19.2.2      P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object  ...........  39
117	19.3        <S2L_SUB_LSP> Object  ..................................  40
118	19.3.1      <S2L_SUB_LSP> IPv4 Object  .............................  40
119	19.3.2      <S2L_SUB_LSP> IPv6 Object  .............................  40
120	19.4        FILTER_SPEC Object  ....................................  40
121	19.4.1      P2MP LSP_IPv4 FILTER_SPEC Object  ......................  41
122	19.4.2      P2MP LSP_IPv4 FILTER_SPEC Object  ......................  41
123	19.5        P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)  ...........  41
124	19.6        P2MP SECONDARY_RECORD_ROUTE Object (SRRO)  .............  41
125	20          IANA Considerations  ...................................  41
126	20.1        New Class Numbers  .....................................  41
127	20.2        New Class Types  .......................................  42
128	20.3        New Error Codes  .......................................  42
129	20.4        LSP Attributes Flags  ..................................  43
130	21          Security Considerations  ...............................  43
131	22          Acknowledgements  ......................................  43
132	23          Appendix  ..............................................  43
133	23.1        Example  ...............................................  43
134	24          References  ............................................  45
135	24.1        Normative References  ..................................  45
136	24.2        Informative References  ................................  46
137	25          Author Information  ....................................  47
138	25.1        Editor Information  ....................................  47
139	25.2        Contributor Information  ...............................  47
140	26          Intellectual Property  .................................  50
141	27          Full Copyright Statement  ..............................  50
142	28          Acknowledgement  .......................................  51
143	1. Conventions used in this document

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

149	2. Terminology

151	   This document uses terminologies defined in [RFC3031], [RFC2205],
152	   [RFC3209], [RFC3473] and [P2MP-REQ].

154	3. Introduction

156	   [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS
157	   networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P
158	   TE LSPs in GMPLS networks. However these specifications do not
159	   provide a mechanism for building P2MP TE LSPs.

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

165	   This document relies on the semantics of RSVP that RSVP-TE inherits
166	   for building P2MP LSPs. A P2MP LSP  is comprised of multiple S2L
167	   sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress
168	   LSRs and are appropriately combined by the branch LSRs using RSVP
169	   semantics to result in a P2MP TE LSP. One Path message may signal one
170	   or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP
171	   LSP can be signaled using one Path message or split across multiple
172	   Path messages.

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

177	4. Mechanism

179	   This document describes a solution that optimizes data replication by
180	   allowing non-ingress nodes in the network to be replication/branch
181	   nodes. A branch node is a LSR that is capable of replicating the
182	   incoming data on two or more outgoing interfaces. The solution relies
183	   on RSVP-TE in the network for setting up a P2MP TE LSP.

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

190	4.1. P2MP Tunnels

192	   The specific aspect related to P2MP TE LSP is the action required at
193	   a branch node, where data replication occurs. Incoming MPLS labeled
194	   data is appropriately replicated to several outgoing interfaces which
195	   may have different labels.

197	   A P2MP TE Tunnel comprises of one or more P2MP LSPs. A P2MP TE Tunnel
198	   is identified by a P2MP SESSION object. This object contains the
199	   identifier of the P2MP Session which includes the P2MP ID, a tunnel
200	   ID and an extended tunnel ID.

202	   The fields of a P2MP SESSION object are identical to those of the
203	   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
204	   Address field is replaced by the P2MP Identifier (P2MP ID) field.

206	   The P2MP ID provides an identifier for the set of destinations of the
207	   P2MP TE Tunnel.

209	4.2. P2MP LSP

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

217	4.3. Sub-Groups

219	   As with all other RSVP controlled LSPs, P2MP LSP  state is managed
220	   using RSVP messages. While use of RSVP messages is the same, P2MP LSP
221	   state differs from P2P LSP state in a number of ways. The two most
222	   notable differences are that a P2MP LSP  comprises multiple S2L
223	   Sub-LSPs and that, as a result of this, it may not be possible to
224	   represent full state in a single IP packet and even more likely that it
225	   can't fit into a single IP packet. It must also be possible to
226	   efficiently add and remove endpoints to and from P2MP TE LSPs. An
227	   additional issue is that P2MP LSP must also handle the state "remerge"
228	   problem, see [P2MP-REQ].

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

236	   The Sub-Group fields, together with rest of the SENDER_TEMPLATE and
237	   SESSION objects, are used to represent a portion of a P2MP LSP's
238	   state.  This portion of a P2MP LSP's state refers only to signaling
239	   state and not data plane replication or branching. For example, it is
240	   possible for a node to "branch" signaling state for a P2MP LSP, but
241	   to not branch the data associated with the P2MP LSP. Typical
242	   applications for generation and use of multiple subgroups are adding
243	   an egress and semantic fragmentation to ensure that a Path message
244	   remains within a single IP packet.

246	4.4. S2L Sub-LSPs

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

250	4.4.1. Representation of a S2L Sub-LSP

252	   A S2L sub-LSP exists within the context of a P2MP LSP. Thus it is
253	   identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are
254	   part of the P2MP SESSION, the tunnel sender address and LSP ID fields
255	   of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
256	   address that is part of the <S2L_SUB_LSP> object. The <S2L_SUB_LSP>
257	   object is defined in section 20.3.

259	   An EXPLICIT_ROUTE Object (ERO) or P2MP SECONDARY_EXPLICIT_ROUTE
260	   Object (SERO) is used to optionally specify the explicit route of a
261	   S2L sub-LSP. Each ERO or a SERO that is signaled corresponds to a
262	   particular <S2L_SUB_LSP> object.  Details of explicit route encoding
263	   are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is
264	   defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-
265	   C-type is defined in Section 20.5 and a matching P2MP
266	   SECONDARY_RECORD_ROUTE Object C-type is defined in Section 20.6.

268	4.4.2. S2L Sub-LSPs and Path Messages

270	   The mechanism in this document allows a P2MP LSP to be signaled using
271	   one or more Path messages. Each Path message may signal one or more
272	   S2L sub-LSPs. Support for multiple Path messages is desirable as one
273	   Path message may not be large enough to fit all the S2L sub-LSPs; and
274	   they also allow separate manipulation of sub-trees of the P2MP LSP.
275	   The reason for allowing a single Path message, to signal multiple S2L
276	   sub-LSPs, is to optimize the number of control messages needed to
277	   setup a P2MP LSP.

279	4.5. Explicit Routing

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

291	   When a Path message signals multiple S2L sub-LSPs the path of the
292	   first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded
293	   in the ERO. The first S2L sub-LSP is the one that corresponds to the
294	   first <S2L_SUB_LSP> object in the Path message. The S2L sub-LSPs
295	   coresponding to the <S2L_SUB_LSP> objects that follow are termed as
296	   subsequent S2L sub-LSPs.  In order to avoid the potential repetition
297	   of path information for the parts of S2L sub-LSPs that share hops,
298	   this information is deduced from the explicit routes of other S2L
299	   sub-LSPs using explicit route compression in SEROs.

301	   The path of each subsequent S2L sub-LSP is encoded in a P2MP
302	   SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the
303	   same as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP
304	   is represented by tuples of the form < [<P2MP SEC-
305	   ONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >. There is a one to one
306	   correspondence between a <S2L_SUB_LSP> object and a SERO. A SERO for a
307	   particular S2L sub-LSP includes only the path from a certain branch
308	   LSR to the egress LSR if the path to that branch LSR can be derived
309	   from the ERO or other SEROs. The absence of a SERO should be
310	   interpreted as requiring hop-by-hop routing for that S2L sub-LSP. Note
311	   that the destination address is carried in the S2L sub-LSP object.
312	   The encoding of the SERO and <S2L_SUB_LSP> object are described in
313	   detail in section 20.

315	   Explicit route compression is illustrated using the following figure.

317	                                    A
318	                                    |
319	                                    |
320	                                    B
321	                                    |
322	                                    |
323	                          C----D----E
324	                          |    |    |
325	                          |    |    |
326	                          F    G    H-------I
327	                               |    |\      |
328	                               |    | \     |
329	                               J    K   L   M
330	                               |    |   |   |
331	                               |    |   |   |
332	                               N    O   P   Q--R

334	                        Figure 1. Explicit Route Compression

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

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

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

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

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

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

365	   After LSR H processes the incoming Path message from E it sends a
366	   Path message to LSR K, LSR L and LSR I. The encoding for the Path
367	   message to LSR K is as follows:

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

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

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

376	   Following is one way for LSR H to encode the S2L sub-LSP explicit
377	   routes in the Path message sent to LSR I:

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

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

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

396	5. Path Message

398	5.1. Path Message Format

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

405	   <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
406	                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
407	                          [ <MESSAGE_ID> ]
408	                          <SESSION> <RSVP_HOP>
409	                          <TIME_VALUES>
410	                          [ <EXPLICIT_ROUTE> ]
411	                          <LABEL_REQUEST>
412	                          [ <PROTECTION> ]
413	                          [ <LABEL_SET> ... ]
414	                          [ <SESSION_ATTRIBUTE> ]
415	                          [ <NOTIFY_REQUEST> ]
416	                          [ <ADMIN_STATUS> ]
417	                          [ <POLICY_DATA> ... ]
418	                          <sender descriptor>
419	                          [<S2L sub-LSP descriptor list>]

421	   Following is the format of the S2L sub-LSP descriptor list.

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

426	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC-
427	   ONDARY_EXPLICIT_ROUTE> ]

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

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

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

443	   Path message processing is described in the next section.

445	5.2. Path Message Processing

447	   The ingress-LSR initiates the set up of a S2L sub-LSP to each egress
448	   LSR that is the destination of the P2MP LSP. Each S2L sub-LSP is
449	   associated with the same P2MP LSP using common P2MP SESSION object
450	   and <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
451	   object.  Hence it can be combined with other S2L sub-LSPs to form a
452	   P2MP LSP.  Another S2L sub-LSP belonging to the same instance of this
453	   S2L sub-LSP (i.e.  the same P2MP LSP) shares resources with this S2L
454	   sub-LSP. The session corresponding to the P2MP TE tunnel is
455	   determined based on the P2MP SESSION object. Each S2L sub-LSP is
456	   identified using the <S2L_SUB_LSP> object. Explicit routing for the S2L
457	   sub-LSPs is achieved using the ERO and SEROs.

459	   As mentioned earlier, it is possible to signal S2L sub-LSPs for a
460	   given P2MP LSP in one or more Path messages. And a given Path message
461	   can contain one or more S2L sub-LSPs. A LSR that supports RSVP-TE
462	   signaled P2MP LSPs MUST be able to receive and process multiple Path
463	   messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path
464	   message. This implies that a LSR MUST be able to receive and process
465	   all objects listed in section 20.

467	5.2.1. Multiple Path Messages

469	   As described in section 3, either the <EXPLICIT_ROUTE> <S2L_SUB_LSP>
470	   or the <P2MP SECONDARY_EXPLICIT_ROUTE> <S2L_SUB_LSP> tuple is used to
471	   specify a S2L sub-LSP. Multiple Path messages can be used to signal a
472	   P2MP LSP. Each Path message can signal one or more S2L sub-LSPs. If a
473	   Path message contains only one S2L sub-LSP, each LSR along the S2L
474	   sub-LSP follows [RFC3209] procedures for processing the Path message
475	   besides the <S2L_SUB_LSP> object processing described in this docu-
476	   ment.

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

481	   An ingress LSR may use multiple Path messages for signaling a P2MP
482	   LSP.  This may be because a single Path message may not be large
483	   enough to signal the P2MP LSP. Or it may be while adding leaves to
484	   the P2MP LSP the new leaves are signaled in a new Path message. Or an
485	   ingress LSR MAY choose to break the P2MP tree into separate
486	   manageable P2MP trees.  These trees share the same root and may share the
487	   trunk and certain branches.  The scope of this management
488	   decomposition of P2MP trees is bounded by a single tree (the P2MP Tree)
489	   and multiple trees with a single leaf each (S2L sub-LSPs).  Per
490	   [P2MP-REQ], a P2MP LSP MUST have consistent attributes across all
491	   portions of a tree. This implies that each Path message that is used
492	   to signal a P2MP LSP is signaled using the same signaling attributes
493	   with the exception of the S2L sub-LSP information.

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

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

506	   Multiple Path messages generated by a LSR that signal state for the
507	   same P2MP LSP are signaled with the same SESSION object and have the
508	   same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order
509	   to disambiguate these Path messages a <Sub-Group Originator ID,
510	   sub-Group ID> tuple is introduced (also referred to as the Sub-Group
511	   field) and encoded in the SENDER_TEMPLATE object. Multiple Path
512	   messages generated by a LSR to signal state for the same P2MP LSP
513	   have the same Sub-Group Originator ID and have a different sub-Group
514	   ID. The Sub-Group Originator ID SHOULD be set to the TE Router ID of
515	   the LSR that originates the Path message. This is either the ingress
516	   LSR or a LSR which re-originates the Path message with its own Sub-Group
517	   Originator ID. Cases when a transit LSR may change the Sub-Group
518	   Originator ID of an incoming Path message are described below. The
519	   <Sub-Group Originator ID, sub-Group ID> tuple is globally unique. The
520	   sub-Group ID space is specific to the Sub-Group Originator ID.
521	   Therefore the combination <Sub-Group Originator ID, sub-Group ID> is
522	   network-wide unique. Also, a router that changes the Sub-Group
523	   originator ID of an incoming Path message MUST use the same value of
524	   the Sub-Group Originator ID for all outgoing Path messages, for a
525	   particular P2MP LSP, and SHOULD not vary it during the life of the
526	   P2MP LSP.

528	5.2.2. Multiple S2L Sub-LSPs in one Path message

530	   The S2L sub-LSP descriptor list allows the signaling of one or more
531	   S2L sub-LSPs in one Path message. It is possible to signal multiple
532	   <S2L_SUB_LSP> object and ERO/SERO combinations in a single Path mes-
533	   sage. Note that these two objects are the ones that differentiate a
534	   S2L sub-LSP.

536	   All LSRs MUST process the ERO corresponding to the first S2L sub-LSP
537	   when the ERO is present. If one or more SEROs are present an ERO MUST
538	   be present.  The first S2L sub-LSP MUST be propagated in a Path
539	   message by each LSR along the explicit route specified by the ERO. A
540	   LSR MUST process a S2L sub-LSP descriptor for a subsequent S2L sub-LSP
541	   only if the first hop in the corresponding SERO is a local address of
542	   that LSR. If this is not the case the S2L sub-LSP descriptor MUST be
543	   included in the Path message sent to LSR that is the next hop to
544	   reach the first hop in the SERO. This next hop is determined by using
545	   the ERO or other SEROs that encode the path to the SERO's first hop.
546	   If this is the case and the LSR is also the egress, the S2L sub-LSP
547	   descriptor MUST NOT be propagated downstream. If this is the case and
548	   the LSR is not the egress the S2L sub-LSP descriptor MUST be included
549	   in a Path message sent to the next-hop determined from the SERO.
550	   Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
551	   descriptors on each downstream link. A S2L sub-LSP descriptor list
552	   that is propagated on a downstream link MUST only contain those S2L
553	   sub-LSPs that are routed using that link. This processing MAY result
554	   in a subsequent S2L sub-LSP in an incoming Path message to become the
555	   first S2L sub-LSP in an outgoing Path message.

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

562	   The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
563	   message and applies to all the S2L sub-LSPs signaled in the path
564	   message. A transit LSR MUST append its address in an incoming RRO and
565	   propagate it downstream. A branch LSR MUST form a new RRO for each of
566	   the outgoing Path messages. Each such updated RRO MUST be formed
567	   using the rules in [RFC3209].

569	   If a LSR is unable to support a S2L sub-LSP in a Path message, a
570	   PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
571	   processing of the rest of the P2MP LSP SHOULD continue. The default
572	   behavior is that the remainder of the LSP is not impacted (that is,
573	   all other branches are allowed to set up) and the failed branches are
574	   reported in PathErr messages in which the Path_State_Removed flag
575	   MUST NOT be set. However, the ingress LSR may set a LSP Integrity
576	   flag to request that if there is a setup failure on any branch the
577	   entire LSP should fail to set up. This is described further in
578	   section 12.

580	5.2.3. Transit Fragmentation

582	   In certain cases a transit LSR may need to generate multiple Path
583	   messages to signal state corresponding to a single received Path
584	   message. For instance ERO expansion may result in an overflow of the
585	   resultant Path message. It is desirable not to rely on IP
586	   fragmentation in this case. In order to achieve this, the multiple Path
587	   messages generated by the transit LSR, are signaled with the Sub-Group
588	   Originator ID set to the TE Router ID of the transit LSR and a dis-
589	   tinct sub-Group ID. Thus each distinct Path message that is generated
590	   by the transit LSR for the P2MP LSP carries a distinct <Sub-Group
591	   Originator ID, Sub-Group ID> tuple.

593	   When multiple Path messages are used by an ingress or transit node,
594	   each Path message SHOULD be identical with the exception of the S2L
595	   sub-LSP related information (e.g., SERO), message and hop information
596	   (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields
597	   of the SENDER_TEMPLATE objects. Except when performing a  make-
598	   before-break operation as specified in section 14.1, the tunnel
599	   sender address and LSP ID fields MUST be the same in each message,
600	   and for transit nodes, the same as the values in the received Path
601	   message.

603	   As described above one case in which the Sub-Group Originator ID of a
604	   received Path message is changed is that of transit fragmentation.
605	   Another case is when the Sub-Group Originator ID of a received Path
606	   message may be changed in the outgoing Path message and set to that
607	   of the LSR originating the Path message based on a local policy. For
608	   instance a LSR may decide to always change the Sub-Group Originator
609	   ID while performing ERO expansion. The Sub-Group ID MUST not be
610	   changed if the Sub-Group Originator ID is not being changed.

612	5.2.4. Control of Branch Fate Sharing

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

621	   The ingress LSP may request 'LSP integrity' by setting bit [TBA] of
622	   the Attributes Flags TLV. The bit is set if LSP integrity is
623	   required.

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

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

633	5.3. Grafting

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

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

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

652	6. Resv Message

654	6.1. Resv Message Format

656	   The Resv message follows the [RFC3209] and [RFC3473] format:

658	   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
659	                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
660	                         [ <MESSAGE_ID> ]
661	                         <SESSION> <RSVP_HOP>
662	                         <TIME_VALUES>
663	                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
664	                         [ <NOTIFY_REQUEST> ]
665	                         [ <ADMIN_STATUS> ]
666	                         [ <POLICY_DATA> ... ]
667	                         <STYLE> <flow descriptor list>

669	   <flow descriptor list> ::= <FF flow descriptor list>
670	                              | <SE flow descriptor>

672	   <FF flow descriptor list> ::= <FF flow descriptor>
673	                                 | <FF flow descriptor list>
674	                                 <FF flow descriptor>

676	   <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

678	   <SE filter spec list> ::= <SE filter spec>
679	                            | <SE filter spec list> <SE filter spec>

681	   The FF flow descriptor and SE filter spec are modified as follows to
682	   identify the S2L sub-LSPs that they correspond to:

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

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

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

694	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP
695	   SECONDARY_EXPLICIT_ROUTE> ]
696	   FILTER_SPEC is defined in section 20.4.

698	   The S2L sub-LSP descriptor has the same format as in section 4.1 with
699	   the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in
700	   place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SEC-
701	   ONDARY_RECORD_ROUTE objects follow the same compression mechanism as
702	   the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv
703	   message can signal multiple S2L sub-LSPs that may belong to the same
704	   FILTER_SPEC object or different FILTER_SPEC objects. The same label
705	   SHOULD be allocated if the <Sender Address, LSP-ID> fields of the
706	   FILTER_SPEC object are the same.

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

712	6.2. Resv Message Processing

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

718	   A subsequent node MUST allocates its own label and pass it in the
719	   Resv message upstream. The node MAY combine multiple flow descrip-
720	   tors, from different Resv messages received from downstream, in one
721	   Resv message sent upstream. A Resv message MUST NOT be sent upstream
722	   until at least one Resv message has been received from a downstream
723	   neighbor. When the integrity bit is set in the LSP_ATTRIBUTE object,
724	   no Resv message MUST be sent upstream until all Resv messages have
725	   been received from the downstream neighbors.

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

732	   This label is associated by that node with all the labels received
733	   from downstream Resv messages for that P2MP LSP. Note that a transit
734	   node may become a replication point in the future when a branch is
735	   attached to it.  Hence this results in the setup of a P2MP LSP from
736	   the ingress-LSR to the egress LSRs.

738	   The ingress LSR may need to understand when all desired egresses have
739	   been reached. This is achieved using <S2L_SUB_LSP> objects.

741	   Each branch node can potentially send one Resv message upstream for
742	   each of the downstream receivers. This MAY result in overflowing the
743	   Resv message, particularly when considering that the number of
744	   messages increases the closer the branch node is to the ingress of
745	   the P2MP LSP.

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

755	6.2.1. Resv Message Throttling

757	   A branch node may have to send the Resv message being sent upstream
758	   whenever there is a change in a Resv message for a S2L sub-LSP
759	   received from one of the downstream neighbors. This can result in
760	   excessive Resv messages sent upstream,particularly when the S2L
761	   sub-LSPs are established for the first time. In order to mitigate
762	   this situation, branch nodes can limit their transmission of Resv mes-
763	   sages. Specifically, in the case where the only change being sent in
764	   a Resv message is in one or more SRRO objects, the branch node SHOULD
765	   transmit the Resv message only after a delay time has passed since
766	   the transmission of the previous Resv message for the same session.
767	   This delayed Resv message SHOULD include SRROs for all branches.
768	   Specific mechanisms for Resv message throttling are implementation
769	   dependent and are outside the scope of this document.

771	6.3. Record Routing

773	6.3.1. RRO Processing

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

782	   The record route of the first S2L sub-LSP is encoded in the RRO.
783	   Additional RROs for the subsequent S2L sub-LSPs are referred to as
784	   P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is speci-
785	   fied in section 20.5. The ingress node then receives the RRO and
786	   possibly the SRRO  corresponding to each subsequent S2L sub-LSP. Each
787	   <S2L_SUB_LSP> object is followed by the RRO/SRRO. The ingress node
788	   can then determine the record route corresponding to a particular S2L
789	   sub-LSP. The RRO and SRROs can be used to construct the end to end
790	   Path for each S2L sub-LSP.

792	6.4. Reservation Style

794	   Considerations about the reservation style in a Resv message apply as
795	   described in [RFC3209]. The reservation style in the Resv messages
796	   can either be FF or SE. All P2MP LSP that belong to the same P2MP
797	   Tunnel MUST be signaled with the same reservation style. Irrespective
798	   of whether the reservation style is FF or SE, the S2L sub-LSPs that
799	   belong to the same P2MP LSP SHOULD share labels where they share
800	   hops. If the S2L sub-LSPs that belong to the same P2MP LSP share
801	   labels then they MUST share resources. The S2L sub-LSPs that belong
802	   to different P2MP LSP MUST NOT share labels. If the reservation style
803	   is FF than S2L sub-LSPs that belong to different P2MP LSP MUST NOT
804	   share resources. If the reservation style is SE than S2L sub-LSPs
805	   that belong to different P2MP LSP and the same P2MP Tunnel SHOULD
806	   share resources where they share hops, but MUST not share labels.

808	7. PathTear Message

810	7.1. PathTear Message Format

812	   The format of the PathTear message is as follows:

814	   <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
815	                           [ [ <MESSAGE_ID_ACK> |
816	                               <MESSAGE_ID_NACK> ... ]
817	                           [ <MESSAGE_ID> ]
818	                           <SESSION> <RSVP_HOP>
819	                           [ <sender descriptor> ]
820	                           [ <S2L sub-LSP list> ]

822	   <S2L sub-LSP list> ::= <S2L_SUB_LSP> [ <S2L sub-LSP list> ]

824	   The definition of <sender descriptor> is not changed by this docu-
825	   ment.

827	   Note: it is assumed that the S2L sub-LSP descriptor will not include
828	   the P2MP SECONDARY_EXPLICIT_ROUTE object associated with each S2L
829	   sub-LSP being deleted.

831	7.2. Pruning

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

838	7.2.1. Implicit S2L Sub-LSP Teardown

840	   Implicit teardown uses standard RSVP message processing. Per standard
841	   RSVP processing, a S2L sub-LSP may be removed from a P2MP TE LSP by
842	   sending a modified message for the Path or Resv message that previ-
843	   ously advertised the S2L sub-LSP. This message MUST list all S2L
844	   sub-LSPs that are not being removed. When using this approach, a node
845	   processing a message that removes a S2L sub-LSP from a P2MP TE LSP
846	   MUST ensure that the S2L sub-LSP is not included in any other Path
847	   state associated with session before interrupting the data path to
848	   that egress.  All other message processing remains unchanged.

850	   When implicit teardown is used to delete one or more S2L sub-LSPs, by
851	   modifying a Path message, a transit LSR may have to generate a
852	   PathTear message downstream to delete one or more of these S2L sub-
853	   LSPs. This can happen if as a result of the implicit deletion of S2L
854	   sub-LSP(s) there are no remaining S2L sub-LSPs to send in the corre-
855	   sponding Path message downstream.

857	7.2.2. Explicit S2L Sub-LSP Teardown

859	   Explicit S2L Sub-LSP teardown relies on generating a PathTear message
860	   for the corresponding Path message. The PathTear message is signaled
861	   with the SESSION and SENDER_TEMPLATE objects corresponding to the
862	   P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple corre-
863	   sponding to the Path message. This approach SHOULD be used when all
864	   the egresses signaled by a Path message need to be removed from the
865	   P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled using
866	   other Path messages, are not affected by the PathTear.

868	   A transit LSR that propagates the PathTear message downstream MUST
869	   ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
870	   in the PathTear message to the values used to generate the previous
871	   Path message that corresponds to the S2L sub-LSPs being deleted by it
872	   in the PathTear message.  The transit LSR may need to generate multi-
873	   ple PathTear messages for an incoming PathTear message if it had per-
874	   formed transit fragmentation for the corresponding incoming Path mes-
875	   sage.

877	   When a P2MP LSP is removed by the ingress, a PathTear message MUST be
878	   generated for each Path message used to signal the P2MP LSP.

880	8. Notify and ResvConf Messages

882	8.1. Notify Messages

884	   The Notify Request object and Notify messages are described in
885	   [RFC3473]. Both object and messages SHALL be supported for delivery
886	   of upstream and downstream notification. Processing not detailed in
887	   this section MUST comply to [RFC3473].

889	   1. Upstream Notification

891	   If a transit LSR sets the Sub-Group Originator ID in the
892	   SENDER_TEMPLATE object of a Path message to its own address and the
893	   incoming Path message carries a Notify Request object then this LSR
894	   MUST change the Notify node address in the Notify Request object to
895	   its own address in the Path message that it sends.

897	   If this router subsequently receives a corresponding Notify message
898	   from a downstream LSR than it MUST:

900	   - send a Notify message upstream toward the Notify
901	     node address that the LSR received in the Path message.
902	   - process the sub-group fields of the SENDER_TEMPLATE
903	     object on the received Notify message, and modify their values
904	     in the Notify message that is forwarded to match the sub-group
905	     field values in the original Path message received from upstream.

907	   The receiver of an (upstream) Notify message MUST identify the state
908	   referenced in this message based on the SESSION and SENDER_TEMPLATE.

910	   2. Downstream Notification

912	   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
913	   object(s) of a Resv message to the value, that was received in the
914	   corresponding Path message. If the incoming Resv message carries a
915	   Notify Request object then the LSR MUST set the Notify node address
916	   in the Notify Request object to the value, that was received in the
917	   corresponding Path message, in the Resv message that it sends
918	   upstream.

920	   If this router subsequently receives a corresponding Notify message
921	   from upstream LSR than it MUST:
922	   - send a Notify message downstream toward the Notify
923	     node address that the LSR received in the Resv message.

925	   - process the sub-group fields of the FILTER_SPEC object in the
926	     received Notify message, and modify their values in the Notify
927	     message that is forwarded to match the sub-group field values
928	     in the original Path message sent downstream by this LSR.

930	   The receiver of a (downstream) Notify message MUST identify the state
931	   referenced in this message based on the SESSION and FILTER_SPEC
932	   objects.

934	   The consequence of these rules for a P2MP LSP is that an upstream
935	   Notify message generated on a branch will result in a Notify being
936	   delivered to the upstream Notify node address. The receiver of the
937	   Notify message MUST NOT assume that the Notify message applies to all
938	   downstream egresses, but MUST examine the information in the message
939	   to determine to which egresses the message applies.

941	   Downstream Notify messages MUST be replicated at branch LSRs accord-
942	   ing to the Notify Request objects received on Resv messages.  Some
943	   downstream branches might not request Notify messages, but all that
944	   have requested Notify messages MUST receive them

946	8.2. ResvConf Messages

948	   ResvConf messages are described in [RFC2205]. ResvConf processing in
949	   [RFC3473] and [RFC3209] is taken directly from [RFC2205]. An egress
950	   LSR may include a RESV_CONFIRM object that contains the egress LSR's
951	   address.  The object and message SHALL be supported for the confirma-
952	   tion of receipt of the Resv message in P2MP TE LSPs. Processing not
953	   detailed in this section MUST comply to [RFC2205].

955	   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
956	   object(s) of a Resv message to the value, that was received in the
957	   corresponding Path message. If the incoming Resv message carries a
958	   RESV_CONFIRM object then the LSR MUST include a RESV_CONFIRM object
959	   in the corresponding Resv message that it sends upstream and MUST set
960	   the receiver address in the RESV_CONFIRM object to the value that was
961	   received in the corresponding Path message.

963	   If this router subsequently receives a corresponding ResvConf message
964	   from an upstream LSR than it MUST:
965	   - send a ResvConf message downstream toward the receiver address that
966	     the LSR received in the RESV_CONFIRM object in the Resv message.
967	   - process the sub-group fields of the FILTER_SPEC object in the
968	     received ResvConf message, and modify their values in the ResvConf
969	     message that is forwarded to match the sub-group field values
970	     in the original Path message sent downstream by this LSR.

972	   The receiver of a ResvConf message MUST identify the state referenced
973	   in this message based on the SESSION and FILTER_SPEC objects.

975	   The consequence of these rules for a P2MP LSP is that a ResvConf mes-
976	   sage generated at the ingress will result in a ResvConf message being
977	   delivered to the branch and then to the receiver address in the orig-
978	   inal RESV_CONFIRM object. The receiver of a ResvConf message MUST NOT
979	   assume that the ResvConf message should be sent to all downstream
980	   egresses, but MUST replicate the message according to the
981	   RESV_CONFIRM objects received in Resv messages. Some downstream branches
982	   branches might not request ResvConf messages, and ResvConf messages
983	   SHOULD NOT be on these branches. All downstream branches that do
984	   requested ResvConf messages MUST be sent such a message.

986	9. Refresh Reduction

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

993	10. State Management

995	   State signaled by a P2MP Path message is managed by a local implemen-
996	   tation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of
997	   the SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group
998	   Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE object.

1000	   Additional information signaled in the Path/Resv message is part of
1001	   the state created by a local implementation. This mandatorily
1002	   includes PHOP/NHOP and SENDER_TSPEC/FILTER_SPEC object.

1004	10.1. Incremental State Update

1006	   RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
1007	   GMPLS [RFC3473] uses the same basic approach to state communication
1008	   and synchronization, namely full state is sent in each state adver-
1009	   tisement message. Per [RFC2205] Path and Resv messages are idempo-
1010	   tent. Also, [RFC2961] categorizes RSVP messages into two types: trig-
1011	   ger and refresh messages and improves RSVP message handling and scal-
1012	   ing of state refreshes but does not modify the full state advertise-
1013	   ment nature of Path and Resv messages. The full state advertisement
1014	   nature of Path and Resv messages has many benefits, but also has some
1015	   drawbacks. One notable drawback is when an incremental modification
1016	   is being made to a previously advertised state. In this case, there
1017	   is the message overhead of sending the full state and the cost of
1018	   processing it. It is desirable to overcome this drawback and
1019	   add/delete S2L sub-LSPs to a P2MP LSP by incrementally updating the
1020	   existing state.

1022	   It is possible to use the procedures described in this document to
1023	   allow S2L sub-LSPs to be incrementally added or deleted from the P2MP
1024	   LSP by allowing a Path or a PathTear message to incrementally change
1025	   the existing P2MP LSP Path state.

1027	   As described in section 4.2, multiple Path messages can be used to
1028	   signal a P2MP LSP. The Path messages are distinguished by different
1029	   <Sub-Group Originator ID, sub-Group ID> tuples in the SENDER_TEMPLATE
1030	   object.  In order to perform incremental S2L sub-LSP state addition a
1031	   separate Path message with a new sub-Group ID is used to add the new
1032	   S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be
1033	   set to the TE Router ID [RFC3477] of the node that sets the Sub-Group
1034	   ID.

1036	   This maintains the idempotent nature of RSVP Path messages; avoids
1037	   keeping track of individual S2L sub-LSP state expiration and provides
1038	   the ability to perform incremental P2MP LSP state updates.

1040	10.2. Combining Multiple Path Messages

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

1053	   The new Path message is signaled by the node that is combining multi-
1054	   ple Path messages with all the S2L sub-LSPs that are being combined
1055	   in a single Path message. This Path message MAY contain a new Sub-
1056	   Sub-Group ID field value.  When a new Path and Resv message that is
1057	   signaled for an existing S2L sub-LSP is received by a transit LSR,
1058	   state including the new instance of the S2L sub-LSP is created.

1060	   The S2L sub-LSP SHOULD continue to be advertised in both the old and
1061	   new Path messages until a Resv message listing the S2L sub-LSP and
1062	   corresponding to the new Path message is received by the combining
1063	   node. Hence until this point state for the S2L sub-LSP SHOULD be
1064	   maintained as part of the Path state for both the old and the new
1065	   Path message [Section 3.1.3, RFC2205]. At that point the S2L sub-LSP
1066	   SHOULD be deleted from the old Path state using the procedures of
1067	   section 7.

1069	   A Path message with a sub-Group_ID(n) may signal a set of S2L
1070	   sub-LSPs that belong partially or entirely to an already existing
1071	   Sub-Group_ID(i), the SESSION object and <Sender Tunnel Address,
1072	   LSP-ID, Sub-Group Originator ID> being the same. Or it may signal a
1073	   strictly non-overlapping new set of S2L sub-LSPs with a strictly higher
1074	   sub-Group_ID value.

1076	   1) If sub-Group_ID(i) = sub-Group_ID(n), then either a full refresh
1077	   is indicated by the Path message or a S2L Sub-LSP is added to/deleted
1078	   from the group signaled by sub-Group_ID(n)

1080	   2) If sub-Group_ID(i) != sub-Group_ID(n), then the Path message is
1081	   signaling a set of S2L sub-LSPs that belong partially or entirely to
1082	   an already existing Sub-Group_ID(i) or a strictly non-overlapping set
1083	   of S2L sub-LSPs.

1085	11. Error Processing

1087	   PathErr and ResvErr messages are processed as per RSVP-TE procedures.
1088	   Note that a LSR on receiving a PathErr/ResvErr message for a particu-
1089	   lar S2L sub-LSP changes the state only for that S2L sub-LSP. Hence
1090	   other S2L sub-LSPs are not impacted. In case the ingress node
1091	   requests the maintenance of the 'LSP integrity', any error reported
1092	   within the P2MP TE LSP must be reported at (least at) any other
1093	   branching nodes belonging to this LSP. Therefore, reception of an
1094	   error message for a particular S2L sub-LSP MAY change the state of
1095	   any other S2L sub- LSP of the same P2MP TE LSP.

1097	11.1. PathErr Messages

1099	   The PathErr message will include one or more <S2L_SUB_LSP> objects.
1100	   The resulting modified format for a PathErr message is:

1102	   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1103	                             [ [<MESSAGE_ID_ACK> |
1104	                                <MESSAGE_ID_NACK>] ... ]
1105	                             [ <MESSAGE_ID> ]
1106	                             <SESSION> <ERROR_SPEC>
1107	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1108	                             [ <POLICY_DATA> ... ]
1109	                             <sender descriptor>

1111	                             [ <S2L sub-LSP descriptor list> ]

1113	   PathErr messages generation is unmodified, but nodes that set the
1114	   Sub-Group Originator field and propagate a received PathErr message
1115	   upstream MUST replace the Sub-Group fields received in the PathErr
1116	   message with the value that was received in the Sub-Group fields of
1117	   the Path message from the upstream neighbor.  Note the receiver of a
1118	   PathErr message is able to identify the errored outgoing Path mes-
1119	   sage, and outgoing interface, based on the Sub-Group fields received
1120	   in the PathErr message.

1122	11.2. ResvErr Messages

1124	   The ResvErr message will include one or more <S2L_SUB_LSP> objects.
1125	   The resulting modified format for a ResvErr Message is:

1127	   <ResvErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1128	                             [ [<MESSAGE_ID_ACK> |
1129	                                <MESSAGE_ID_NACK>] ... ]
1130	                             [ <MESSAGE_ID> ]
1131	                             <SESSION> <RSVP_HOP>
1132	                             <ERROR_SPEC> [ <SCOPE> ]
1133	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1134	                             [ <POLICY_DATA> ... ]
1135	                             <STYLE> <flow descriptor list>

1137	   ResvErr messages generation is unmodified, but nodes that set the
1138	   Sub-Group Originator field and propagate a received ResvErr message
1139	   downstream MUST replace the Sub-Group fields received in the ResvErr
1140	   message with the value that was set in the Sub-Group fields of the
1141	   Path message sent to the downstream neighbor. Note the receiver of a
1142	   ResvErr message is able to identify the errored outgoing Path mes-
1143	   sage, and outgoing interface, based on the Sub-Group fields received
1144	   in the ResvErr message.

1146	11.3. Branch Failure Handling

1148	   During setup and during normal operation, PathErr messages may be
1149	   received at a branch node. In all cases, a received PathErr message
1150	   is first processed per standard processing rules. That is: the
1151	   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
1152	   Path message.  Intermediate nodes until this ingress/branch LSR MAY
1153	   inspect this message but take no action upon it. The behavior of a
1154	   branch LSR that generates a PathErr message is under the control of
1155	   the ingress LSR.

1157	   The default behavior is that the PathErr message does not have the
1158	   Path_State_Removed flag set. However, if the ingress LSR has set the
1159	   LSP integrity flag on the Path message (see LSP_ATTRIBUTE object in
1160	   section 20) and if the Path_State_Removed flag is supported, the LSR
1161	   generating a PathErr to report the failure of a branch of the P2MP
1162	   LSP SHOULD set the Path_State_Removed flag.

1164	   A branch LSR that receives a PathErr message with the
1165	   Path_State_Removed flag set MUST act according to the wishes of the
1166	   ingress LSR. The default behavior is that the branch LSR clears the
1167	   Path_State_Removed flag on the PathErr and sends it further upstream.
1168	   It does not tear any other branches of the LSP. However, if the LSP
1169	   integrity flag is set on the Path message, the branch LSR MUST send
1170	   PathTear on all other downstream branches and send the PathErr mes-
1171	   sage upstream with the Path_State_Removed flag set.

1173	   A branch LSR that receives a PathErr message with the
1174	   Path_State_Removed flag clear MUST act according to the wishes of the
1175	   ingress LSR. The default behavior is that the branch LSR forwards the
1176	   PathErr upstream and takes no further action. However, if the LSP
1177	   integrity flag is set on the Path message, the branch LSR MUST send
1178	   PathTear on all downstream branches and send the PathErr upstream
1179	   with the Path_State_Removed flag set (per [RFC3473]).

1181	   In all cases, the PathErr message forwarded by a branch LSR MUST con-
1182	   tain the S2L sub-LSP identification and explicit routes of all
1183	   branches that are reported by received PathErr messages and all
1184	   branches that are explicitly torn by the branch LSR.

1186	12. Admin Status Change

1188	   A branch node that receives an ADMIN_STATUS object processes it nor-
1189	   mally and also relays the ADMIN_STATUS object in a Path on every
1190	   branch. All Path messages may be concurrently sent to the downstream
1191	   neighbors.

1193	   Downstream nodes process the change in the status object per
1194	   [RFC3473], including generation of Resv messages. When the last
1195	   received upstream ADMIN_STATUS object had the R bit set, branch nodes
1196	   wait for a Resv message with a matching ADMIN_STATUS object to be
1197	   received (or a corresponding PathErr or ResvTear messsage) on all
1198	   branches before relaying a corresponding Resv message upstream.

1200	13. Label Allocation on LANs with Multiple Downstream Nodes

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

1209	14. P2MP LSP and Sub-LSP Re-optimization

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

1216	14.1. Make-before-break

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

1228	14.2. Sub-Group Based Re-optimization

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

1234	   To alter the path taken by a particular set of S2L sub-LSPs the node
1235	   initiating the path change initiates one or more separate Path mes-
1236	   sages, for the same P2MP LSP, each with a new sub-Group ID. The gen-
1237	   eration of these Path messages, each with one or more S2L sub-LSPs,
1238	   follows procedures in section 5.2. As is the case in Section 10.2, a
1239	   particular egress continues to be advertised in both the old and new
1240	   Path messages until a Resv message listing the egress and correspond-
1241	   ing to the new Path message is received by the re-optimizing node. At
1242	   that point the egress SHOULD be deleted from the old Path state using
1243	   the procedures of section 7.  Sub-tree re-optimization is then com-
1244	   pleted.

1246	   As is always the case, a node may choose to combine multiple path
1247	   messages as described in section 10.2.

1249	15. Fast Reroute

1251	   [RFC4090] extensions can be used to perform fast reroute for the
1252	   mechanism described in this document.

1254	15.1. Facility Backup

1256	   Facility backup as described in [RFC4090] can be used to protect P2MP
1257	   LSPs.

1259	   If link protection is desired, a bypass tunnel is used to protect the
1260	   link between the PLR and next-hop. Thus all S2L sub-LSPs that use the
1261	   link can be protected in the event of link failure. Note that all
1262	   such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
1263	   will share the same outgoing label on the link between the PLR and
1264	   the next-hop. This is the P2MP LSP label on the link. Label stacking
1265	   is used to send data for each P2MP LSP in the bypass tunnel. The
1266	   inner label is the P2MP LSP label allocated by the nhop. During fail-
1267	   ure Path messages for each S2L sub-LSP, that is effected, will be
1268	   sent to the MP, by the PLR. It is recommended that the PLR use the
1269	   sender template specific method to identify these Path messages.
1270	   Hence the PLR will set the source address in the sender template to a
1271	   local PLR address. The MP will use the LSP-ID to identify the corre-
1272	   sponding S2L sub-LSPs.

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

1277	   In order to further process a S2L sub-LSP it will determine the pro-
1278	   tected S2L sub-LSP using the LSP-id and the <S2L_SUB_LSP> object.

1280	   If node protection is desired, the bypass P2P tunnel must intersect
1281	   the path of the protected S2L sub-LSPs on a LSR that is downstream
1282	   from the PLR. This constrains the set of S2L sub-LSPs being backed-up
1283	   via that bypass tunnel to those S2L sub-LSPs that pass through a com-
1284	   mon downstream MP. This MP is the destination of the bypass tunnel.
1285	   The MP will allocate the same label to all such S2L sub-LSPs belong-
1286	   ing to a particular instance of a P2MP tunnel. This will be the inner
1287	   label used during label stacking by the PLR when it sends data for
1288	   each P2MP LSP in the bypass tunnel.  The outer label is the bypass
1289	   tunnel label. During failure of the protected node the PLR will send
1290	   Path messages for the protected S2L sub-LSPs to the MP using
1291	   procedures that are same as the link protection procedures described
1292	   above. Node protection may require the PLR to be branch capable as
1293	   multiple bypass tunnels may be required to backup the set of S2L sub-
1294	   LSPs passing through the protected node. Else all the S2L sub-LSPs
1295	   passing through the protected node must also pass through a MP that
1296	   is downstream from the protected node.

1298	15.2. One to One Backup

1300	   One to one backup as described in [RFC4090] can be used to protect a
1301	   particular S2L sub-LSP against link and next-hop failure. Protection
1302	   may be used for one or more S2L sub-LSPs between the PLR and the
1303	   next-hop. All the S2L sub-LSPs corresponding to the same instance of
1304	   the P2MP tunnel, between the PLR and the next-hop share the same P2MP
1305	   LSP label.

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

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

1314	   Its is recommended that the path specific method be used to identify
1315	   a backup S2L sub-LSP. Hence the DETOUR object will be inserted in the
1316	   backup Path message. A backup S2L sub-LSP MUST be treated as belong-
1317	   ing to a different P2MP tunnel instance than the one specified by the
1318	   LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be treated as
1319	   part of the same P2MP tunnel instance if they have the same LSP-id
1320	   and the same DETOUR objects. Note that as specified in section 4 S2L
1321	   sub-LSPs between different P2MP tunnel instances use different
1322	   labels.

1324	   If there is only one S2L sub-LSP in the Path message, the DETOUR
1325	   object applies to that sub-LSP. If there are multiple S2L sub-LSPs in
1326	   the Path message the DETOUR applies to all the S2L sub-LSPs.

1328	16. Support for LSRs that are not P2MP Capable

1330	   It may be that some LSRs in a network are capable of processing the
1331	   P2MP extensions described in this document, but do not support P2MP
1332	   branching in the data plane. If such an LSR is requested to become a
1333	   branch LSR by a received Path message, it MUST respond with a PathErr
1334	   message carrying the Error Value "Routing Error" and Error Code
1335	   "Unable to Branch".

1337	   Its also conceivable that some LSRs, in a network deploying P2MP
1338	   capability, may not support the extensions described in this docu-
1339	   ment.  If a Path message for the establishment of a P2MP LSP reaches
1340	   such an LSR it will reject it with a PathErr because it will not rec-
1341	   ognize the C-Type of the P2MP SESSION object.

1343	   LSRs that do not support the P2MP extensions in this document may be
1344	   included as transit LSRs by the use of LSP-stitching [LSP-STITCH] and
1345	   LSP-hierarchy [LSP-HIER]. Note that LSRs that are required to play
1346	   any other role in the network (ingress, branch or egress) MUST sup-
1347	   port the extensions defined in this document.

1349	   The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows to build
1350	   P2MP LSPs in such an environment. A P2P LSP segment is signaled from
1351	   the previous P2MP capable hop of a legacy LSR to the next P2MP capa-
1352	   ble hop. Of course this assumes that intermediate legacy LSRs are
1353	   transit LSRs and cannot act as P2MP branch points. Transit LSRs along
1354	   this LSP segment do not process control plane messages associated
1355	   with a P2MP LSP. Furthermore these LSRs also do not need to have P2MP
1356	   data plane capability as they only need to process data belonging to
1357	   the P2P LSP segment. Hence these LSRs do not need to support P2MP
1358	   MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP.
1359	   After the P2P LSP segment is established the P2MP Path message is
1360	   sent to the next P2MP capable LSR as a directed Path message. The
1361	   next P2MP capable LSR stitches the P2P LSP segment to the outgoing
1362	   P2MP LSP.

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

1369	   It may be an overhead for an operator to configure the P2P LSP seg-
1370	   ments in advance, when it is desired to support legacy LSRs. It may
1371	   be desirable to do this dynamically. The ingress can use IGP exten-
1372	   sions to determine non P2MP capable LSRs [TE-NODE-CAP]. It can use
1373	   this information to compute S2L sub-LSP paths such that they avoid
1374	   these legacy LSRs. The explicit route object of a S2L sub-LSP path
1375	   may contain loose hops if there are legacy LSRs along the path. The
1376	   corresponding explicit route contains a list of objects upto the P2MP
1377	   capable LSR that is adjacent to a legacy LSR followed by a loose
1378	   object with the address of the next P2MP capable LSR. The P2MP capa-
1379	   ble LSR expands the loose hop using its TED. When doing this it
1380	   determines that the loose hop expansion requires a P2P LSP to tunnel
1381	   through the legacy LSR. If such a P2P LSP exists, it uses that P2P
1382	   LSP. Else it establishes the P2P LSP.  The P2MP Path message is sent
1383	   to the next P2MP capable LSR using non-adjacent signaling. The P2MP
1384	   capable LSR that initiates the non-adjacent signaling message to the
1385	   next P2MP capable LSR may have to employ a fast detection mechanism
1386	   such as [BFD] to the next P2MP capable LSR.

1388	   This may be needed for the directed Path message Head-End to use node
1389	   protection FRR when the protected node is the directed Path message
1390	   tail.

1392	   Note that legacy LSRs along a P2P LSP segment cannot perform node
1393	   protection of the tail of the P2P LSP segment.

1395	17. Reduction in Control Plane Processing with LSP Hierarchy

1397	   It is possible to take advantage of LSP hierarchy [LSP-HIER] while
1398	   setting up P2MP LSP, as described in the previous section, to reduce
1399	   control plane processing along transit LSRs that are P2MP capable.
1400	   This is applicable only in environments where LSP hierarchy can be
1401	   used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP,
1402	   do not process control plane messages associated with the P2MP LSP.
1403	   Infact they are not aware of these messages as they are tunneled over
1404	   the P2P LSP segment. This reduces the amount of control plane pro-
1405	   cessing required on these transit LSRs.

1407	   Note that the P2P LSP segments can be dynamically setup as described
1408	   in the previous section or preconfigured. For example in Figure 2,
1409	   PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path
1410	   messages for PE3 and PE4 can now be tunneled over the LSP segment.
1411	   Thus P3 is not aware of the P2MP LSP and does not process the P2MP
1412	   control messages.

1414	18. P2MP LSP Remerging and Cross-Over

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

1419	   This section details the procedures for detecting and dealing with
1420	   re-merge and cross-over. The term re-merge refers to the case of an
1421	   ingress or transit node that creates a branch of a P2MP LSP, a re-
1422	   merge branch, which intersects the P2MP LSP at another node farther
1423	   down the tree.  This may occur due to such events as an error in path
1424	   calculation, an error in manual configuration, or network topology
1425	   changes during the establishment of the P2MP LSP.  If the procedures
1426	   detailed in this section are not followed, data duplication will
1427	   result.

1429	   The term cross-over refers to the case of an ingress or transit node
1430	   that creates a branch of a P2MP LSP, a cross-over branch, which
1431	   intersects the P2MP LSP at another node farther down the tree. It is
1432	   unlike re-merge in that at the intersecting node the cross-over
1433	   branch has a different outgoing interface as well as a different
1434	   incoming interface.  This may be necessary in certain combinations of
1435	   topology and technology; e.g., in a transparent optical network in
1436	   which different wavelengths are required to reach different leaf
1437	   nodes.

1439	   Normally, a P2MP LSP has a single incoming interface on which all of
1440	   the Path messages associated with that P2MP LSP are received.  The
1441	   incoming interface is identified by the IF_ID RSVP_HOP Object, if
1442	   present, and by interface over which the Path message was received if
1443	   the IF_ID RSVP_HOP Object is not present.  However, in the case of
1444	   dynamic LSP re-routing, the incoming interface may change.

1446	   Similarly, in both the re-merge case and cross-over cases, a node
1447	   will receive a Path message for a given P2MP LSP on a different
1448	   incoming interface, and the node needs to be able to distinguish
1449	   between dynamic LSP re-routing and the re-merge/cross-over cases.

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

1458	18.1. Procedures

1460	   When a node receives a Path message, it MUST check whether it has
1461	   matching state for the P2MP LSP. Matching state is identified by com-
1462	   paring the SESSION and SENDER_TEMPLATE objects in the received Path
1463	   message with the SESSION and SENDER_TEMPLATE objects of each locally
1464	   maintained P2MP LSP Path state. The P2MP ID, Tunnel ID, and Extended
1465	   Tunnel ID in the SESSION Object and the sender address and LSP ID in
1466	   the SENDER_TEMPLATE object are used for the comparison.  If the node
1467	   has matching state and the incoming interface for the received Path
1468	   message is different than the incoming interface of the matching P2MP
1469	   LSP Path state, then the node MUST determine whether it is dealing
1470	   with dynamic LSP rerouting or re-merge/cross-over.

1472	   Dynamic LSP rerouting is identified by checking whether there is any
1473	   intersection between the set of SUB-LSP objects associated with the
1474	   matching P2MP LSP Path state and the set of SUB-LSP objects in the
1475	   received Path message.  If there is any intersection, then dynamic
1476	   re-routing has occurred.  If there is no intersection between the two
1477	   sets of SUB-LSP objects, then either re-merge or cross-over has
1478	   occurred. (Note that in the case of dynamic LSP rerouting, Path mes-
1479	   sages for the non-intersecting members of set of SUB-LSPs associated
1480	   with the matching P2MP LSP Path state will be received subsequently
1481	   on the new incoming interface.)

1483	   In order to identify the re-merge case, the node processing the
1484	   received Path message MUST identify the outgoing interfaces associ-
1485	   ated with the matching P2MP Path state.  Re-merge has occurred if
1486	   there is any intersection between the set of outgoing interfaces
1487	   associated with the matching P2MP LSP Path state and the set of out-
1488	   going interfaces in the received Path message.

1490	18.1.1. Re-Merge Procedures

1492	   There are two approaches to dealing with re-merge case.  In the
1493	   first, the node detecting the re-merge case, i.e., the re-merge node,
1494	   allows the re-merge case to persist but data from all but one incom-
1495	   ing interface is dropped at the re-merge node.  In the second, the
1496	   re-merge node initiates the removal of the re-merge branch(es) via
1497	   signaling.  Which approach is used is a matter of local policy.  A
1498	   node MUST support both approaches and MUST allow user configuration
1499	   of which approach is to be used.

1501	   When configured to allow a re-merge case to persist, the re-merge
1502	   node MUST validate consistency between the objects included the
1503	   received Path message and the matching P2MP LSP Path state. Any
1504	   inconsistencies MUST result in an appropriate PathErr message sent to
1505	   the previous hop of the received Path message.  The error code is set
1506	   to "Routing Problem" and the error value is set to "P2MP Re-Merge
1507	   Parameter Mistmatch".

1509	   If there are no inconsistencies, the node logically merges, from the
1510	   downstream perspective, the control state of incoming Path message
1511	   with the matching P2MP LSP Path state.  Specifically, procedures
1512	   related to processing of messages received from upstream MUST NOT be
1513	   modified from the upstream perspective; this includes refresh and
1514	   state timeout related processing.  In addition to the standard
1515	   upstream related procedures, the node MUST ensure that each object
1516	   received from upstream is appropriately represented within the set of
1517	   Path messages sent downstream. For example, the received <S2L sub-LSP
1518	   descriptor list> MUST be included in the set of outgoing Path mes-
1519	   sages. If there are any NOTIFY_REQUEST request objects present, then
1520	   the procedures defined in Section 8 MUST be followed for both Path
1521	   and Resv messages.  Special processing is also required for Resv pro-
1522	   cessing.  Specifically, any Resv message received from downstream
1523	   MUST be mapped into an outgoing Resv message that is sent to the pre-
1524	   vious hop of the received Path message.  In practice, this translates
1525	   to decomposing the complete <S2L sub-LSP descriptor list> into sub-
1526	   sets that match the incoming Path messages and then constructing an
1527	   outgoing Resv message for each incoming Path message.

1529	   When configured to allow a re-merge case to persist, the re-merge
1530	   node receives data associated with the P2MP LSP on multiple incoming
1531	   interfaces, but it may only send the data from one of these inter-
1532	   faces to its outgoing interfaces, i.e., the node MUST drop data from
1533	   all but one incoming interface.  This ensures that duplicate data is
1534	   not sent on any outgoing interface.  The mechanism used to select the
1535	   incoming interface to use is implementation specific and is outside
1536	   the scope of this document.

1538	   When configured to correct the re-merge branch via signaling, the re-
1539	   merge node MUST send a PathErr message corresponding to the received
1540	   Path message. The PathErr message MUST include all of the objects
1541	   normally included in a PathErr message, as well as one or more SUB-
1542	   LSP objects from the set of sub-LSPs associated with the matching
1543	   P2MP LSP Path state.  A minimum of three SUB-LSP objects is RECOM-
1544	   MENDED. This will allow the node that caused the re-merge to identify
1545	   the outgoing Path state associated with the valid portion of the P2MP
1546	   LSP. The PathErr message MUST include the error code "Routing Prob-
1547	   lem" and error value of "P2MP Remerge Detected". The node MAY set the
1548	   Path_State_Removed flag [RFC3473].  As is always the case, the
1549	   PathErr message is sent to the previous hop of the received Path mes-
1550	   sage.

1552	   A node that receives a PathErr message that contains the error "Rout-
1553	   ing Problem/P2MP Remerge Detected" MUST determine if it is the node
1554	   that created the re-merge case.  This is done by checking whether
1555	   there is any intersection between the set of SUB-LSP objects associ-
1556	   ated with the matching P2MP LSP Path state and the set of SUB-LSP
1557	   objects in the received PathErr message.  If there is, then the node
1558	   created the re-merge case.

1560	   The node SHOULD remove the re-merge case by moving the SUB-LSP
1561	   objects included in the Path message associated with the received
1562	   PathErr message to the outgoing interface associated with the match-
1563	   ing P2MP LSP Path state.  A trigger Path message for the moved SUB-
1564	   LSP objects is then sent via that outgoing interface.  If the
1565	   received PathErr message did not have the Path_State_Removed flag
1566	   set, the node SHOULD send a PathTear via the outgoing interface asso-
1567	   ciated with the re-merge branch.

1569	   If use of a new outgoing interface violates one or more SERO con-
1570	   straint, then a PathErr message containing the associated egresses
1571	   and any identified SUB-LSP objects SHOULD be generated with the error
1572	   code "Routing Problem" and error value of "ERO Resulted in Remerge".

1574	   The only case where this process will fail is when all the listed
1575	   SUB-LSP objects are deleted prior to the PathErr message propagating
1576	   to the ingress.  In this case, the whole process will be corrected on
1577	   the next (refresh or trigger) transmission of the offending Path mes-
1578	   sage.

1580	19. New and Updated Message Objects

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

1585	19.1. SESSION Object

1587	   A P2MP LSP SESSION object is used. This object uses the existing
1588	   SESSION C-Num. New C-Types are defined to accommodate a logical P2MP
1589	   destination identifier of the P2MP Tunnel. This SESSION object has a
1590	   similar structure as the existing point to point RSVP-TE SESSION
1591	   object.  However the destination address is set to the P2MP ID
1592	   instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs part
1593	   of the same P2MP LSP share the same SESSION object. This SESSION
1594	   object identifies the P2MP Tunnel.

1596	   The combination of the SESSION object, the SENDER_TEMPLATE object and
1597	   the <S2L_SUB_LSP> object, identifies each S2L sub-LSP. This follows
1598	   the existing P2P RSVP-TE notion of using the SESSION object for iden-
1599	   tifying a P2P Tunnel which in turn can contain multiple LSPs, each
1600	   distinguished by a unique SENDER_TEMPLATE object.

1602	19.1.1. P2MP LSP Tunnel IPv4 SESSION Object

1604	   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA

1606	       0                   1                   2                   3
1607	       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
1608	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1609	      |                       P2MP ID                                 |
1610	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1611	      |  MUST be zero                 |      Tunnel ID                |
1612	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1613	      |                      Extended Tunnel ID                       |
1614	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1616	   P2MP ID
1617	      A 32-bit identifier used in the SESSION object that remains
1618	      constant over the life of the P2MP tunnel. It encodes the
1619	      P2MP ID and identifies the set of destinations of the P2MP
1620	      Tunnel.

1622	   Tunnel ID

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

1627	   Extended Tunnel ID

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

1635	19.1.2. P2MP LSP Tunnel IPv6 SESSION Object

1637	   This is same as the P2MP IPv4 LSP SESSION Object with the difference
1638	   that the extended tunnel ID may be set to a 16 byte identifier
1639	   [RFC3209].

1641	       0                   1                   2                   3
1642	       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
1643	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1644	      |                       P2MP ID                                 |
1645	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1646	      |  MUST be zero                 |      Tunnel ID                |
1647	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1648	      |                      Extended Tunnel ID (16 bytes)            |
1649	      |                                                               |
1650	      |                             .......                           |
1651	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1653	19.2. SENDER_TEMPLATE object

1655	   The SENDER_TEMPLATE object contains the ingress-LSR source address.
1656	   LSP ID can be can be changed to allow a sender to share resources
1657	   with itself. Thus multiple instances of the P2MP tunnel can be cre-
1658	   ated, each with a different LSP ID. The instances can share resources
1659	   with each other, but use different labels. The S2L sub-LSPs corre-
1660	   sponding to a particular instance use the same LSP ID.

1662	   As described in section 4.2 it is necessary to distinguish different
1663	   Path messages that are used to signal state for the same P2MP LSP by
1664	   using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. The
1665	   SENDER_TEMPLATE object is modified to carry this information as shown
1666	   below.

1668	19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

1670	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA

1672	         0                   1                   2                   3
1673	         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
1674	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1675	        |                   IPv4 tunnel sender address                  |
1676	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1677	        |       Reserved                |            LSP ID             |
1678	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1679	        |                   Sub-Group Originator ID                     |
1680	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1681	        |       Reserved                |            Sub-Group ID       |
1682	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1684	        IPv4 tunnel sender address
1685	            See [RFC3209]

1687	        Sub-Group Originator ID
1688	            The Sub-Group Originator ID is set to the TE Router ID of
1689	            the LSR that originates the Path message. This is either the
1690	            ingress LSR or a LSR which re-originates the Path message
1691	            with its own Sub-Group Originator ID.

1693	        Sub-Group ID
1694	            An identifier of a Path message used to differentiate
1695	            multiple Path messages that signal state for the same P2MP
1696	            LSP. This may be seen as identifying a group of one or more
1697	            egress nodes targeted by this Path message.

1699	        LSP ID
1700	           See [RFC3209]

1702	19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

1704	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBA

1706	         0                   1                   2                   3
1707	         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
1708	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1709	        |                                                               |
1710	        +                                                               +
1711	        |                   IPv6 tunnel sender address                  |
1712	        +                                                               +
1713	        |                            (16 bytes)                         |
1714	        +                                                               +
1715	        |                                                               |
1716	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1717	        |       Reserved                |            LSP ID             |
1718	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1719	        |                                                               |
1720	        +                                                               +
1721	        |                   Sub-Group Originator ID                     |
1722	        +                                                               +
1723	        |                            (16 bytes)                         |
1724	        +                                                               +
1725	        |                                                               |
1726	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1727	        |       Reserved                |            Sub-Group ID       |
1728	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1730	        IPv6 tunnel sender address
1731	           See [RFC3209]

1733	        Sub-Group Originator ID
1734	            The Sub-Group Originator ID is set to the IPv6 TE Router ID
1735	            of the LSR that originates the Path message. This is either
1736	            the ingress LSR or a LSR which re-originates the Path
1737	            message with its own Sub-Group Originator ID.

1739	        Sub-Group ID
1740	           As above in section 19.2.2.

1742	        LSP ID
1743	           See [RFC3209]

1745	19.3. <S2L_SUB_LSP> Object

1747	   A new <S2L_SUB_LSP> object identifies a particular S2L sub-LSP
1748	   belonging to the P2MP LSP.

1750	19.3.1. <S2L_SUB_LSP> IPv4 Object

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

1754	       0                   1                   2                   3
1755	       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
1756	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1757	      |                   IPv4 S2L Sub-LSP destination address        |
1758	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1760	   IPv4 Sub-LSP destination address

1762	      IPv4 address of the S2L sub-LSP destination.

1764	19.3.2. <S2L_SUB_LSP> IPv6 Object

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

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

1771	       0                   1                   2                   3
1772	       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
1773	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1774	      |        IPv6 S2L Sub-LSP destination address (16 bytes)        |
1775	      |                        ....                                   |
1776	      |                                                               |
1777	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1779	19.4. FILTER_SPEC Object

1781	   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
1782	   object.

1784	19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object

1786	   Class = FILTER SPEC, P2MP LSP_IPv4 C-Type = TBA

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

1791	19.4.2. P2MP LSP_IPv4 FILTER_SPEC Object

1793	   Class = FILTER SPEC, P2MP LSP_IPv6 C-Type = TBA

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

1798	19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

1800	   The P2MP Secondary Explicit Route Object (SERO) is defined as identi-
1801	   cal to the ERO. The class of the P2MP SERO is the same as the SERO
1802	   defined in [RECOVERY]. The P2MP SERO uses a new C-Type = 2. The sub-
1803	   objects are identical to those defined for the ERO.

1805	19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

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

1812	20. IANA Considerations

1814	20.1. New Class Numbers

1816	   IANA is requested to assign the following Class Numbers for the new
1817	   object classes introduced. The Class Types for each of them are to be
1818	   assigned via standards action. The sub-object types for the P2MP
1819	   SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the
1820	   same IANA considerations as those of the ERO and RRO [RFC3209].

1822	   50  Class Name = SUB_LSP

1824	   C-Type
1825	      1   S2L_SUB_LSP_IPv4 C-Type
1826	      2   S2L_SUB_LSP_IPv6 C-Type

1828	20.2. New Class Types

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

1832	   Class Name = SESSION

1834	   C-Type
1835	     13    P2MP_LSP_IPv4 C-Type
1836	     14    P2MP_LSP_IPv6 C-Type

1838	   Class Name = SENDER_TEMPLATE

1840	   C-Type
1841	     12    P2MP_LSP_IPv4 C-Type
1842	     13    P2MP_LSP_IPv6 C-Type

1844	   Class Name = FILTER_SPEC

1846	   C-Type
1847	     12    P2MP LSP_IPv4 C-Type
1848	     13    P2MP LSP_IPv6 C-Type

1850	   Class Name = SECONDARY_EXPLICIT_ROUTE

1852	   C-Type
1853	      2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type

1855	   Class Name = SECONDARY_RECORD_ROUTE

1857	   C-Type
1858	      2  P2MP_SECONDARY_RECORD_ROUTE C-Type

1860	20.3. New Error Codes

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

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

1869	   The Error Code "Unsupported LSP Integrity" indicates that a P2MP
1870	   branch does not support the requested LSP integrity function. IANA is
1871	   requested to assign value 24 to this Error Code.

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

1877	20.4. LSP Attributes Flags

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

1883	   Suggested Bit Number:             3
1884	   Meaning:                          LSP Integrity Required
1885	   Used in Attributes Flags on Path: Yes
1886	   Used in Attributes Flags on Resv: No
1887	   Used in Attributes Flags on RRO:  No
1888	   Referenced Section of this Doc:   10

1890	21. Security Considerations

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

1895	22. Acknowledgements

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

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

1904	23. Appendix

1906	23.1. Example

1908	   Following is one example of setting up a P2MP LSP using the proce-
1909	   dures described in this document.

1911	                   Source 1 (S1)
1912	                     |
1913	                    PE1
1914	                   |   |
1915	                   |L5 |
1916	                   P3  |
1917	                   |   |
1918	                L3 |L1 |L2
1919	       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
1920	                  | L4
1921	          PE5----PE4----R3
1922	                  |
1923	                  |
1924	                 R4

1926	                Figure 2.

1928	   The mechanism is explained using Figure 2. PE1 is the ingress-LSR.
1929	   PE2, PE3 and PE4 are Egress-LSRs.

1931	   a) PE1 learns that PE2, PE3 and PE4 are interested in joining a P2MP
1932	   tree with a P2MP ID of P2MP ID1. We assume that PE1 learns of the
1933	   egress-LSRs at different points.

1935	   b) PE1 computes the P2P path to reach PE2.

1937	   c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>

1939	   d) PE1 computes the P2P path to reach PE3 when it discovers PE3. This
1940	   path is computed to share the same links where possible with the sub-
1941	   LSP to PE2 as they belong to the same P2MP session.

1943	   e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>

1945	   f) PE1 computes the P2P path to reach PE4 when it discovers PE4. This
1946	   path is computed to share the same links where possible with the sub-
1947	   LSPs to PE2 and PE3 as they belong to the same P2MP session.

1949	   g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
1950	   PE4>

1952	   e) P1 receives a Resv message from PE4 with label L4. It had previ-
1953	   ously received a Resv message from PE3 with label L3. It had allo-
1954	   cated a label L1 for the sub-LSP to PE3. It uses the same label and
1955	   sends the Resv messages to P3. Note that it may send only one Resv
1956	   message with multiple flow descriptors in the flow descriptor list.
1957	   If this is the case and FF style is used, the FF flow descriptor will
1958	   contain the S2L sub-LSP descriptor list with two entries: one for PE4
1959	   and the other for PE3. For SE style, the SE filter spec will contain
1960	   this S2L sub-LSP descriptor list. P1 also creates a label mapping of
1961	   (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv
1962	   message to PE1, with label L5. It reuses the label mapping of {L5 ->
1963	   L1}.

1965	24. References

1967	24.1. Normative References

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

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

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

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

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

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

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

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

2002	      [RFC3031]  Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
2003	                 Label Switching Architecture", RFC 3031, January 2001, work in
2004	                 progress.

2006	      [RFC4090]  P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute Extensions
2007	                 to RSVP-TE for LSP Tunnels", work in progress.

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

2013	      [P2MP-REQ] S. Yasukawa, Editor "Signaling Requirements for
2014	                 Point-to-Multipoint Traffic Engineered MPLS LSPs",
2015	                 draft-ietf-mpls-p2mp-sig-requirement-02.txt, work in progress.

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

2020	24.2. Informative References

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

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

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

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

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

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

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

2046	      [TE-NODE-CAP] JP Vasseur, JL Le Roux, et al. "Routing extensions for
2047	                    discovery of Traffic Engineering Node Capabilities",
2048	                    draft-vasseur-ccamp-te-node-cap-00.txt, February 2005,
2049	                    work in progress

2051	25. Author Information

2053	25.1. Editor Information

2055	   Rahul Aggarwal
2056	   Juniper Networks
2057	   1194 North Mathilda Ave.
2058	   Sunnyvale, CA 94089
2059	   Email: rahul@juniper.net

2061	   Seisho Yasukawa
2062	   NTT Corporation
2063	   9-11, Midori-Cho 3-Chome
2064	   Musashino-Shi, Tokyo 180-8585 Japan
2065	   Phone: +81 422 59 4769
2066	   EMail: yasukawa.seisho@lab.ntt.co.jp

2068	   Dimitri Papadimitriou
2069	   Alcatel
2070	   Francis Wellesplein 1,
2071	   B-2018 Antwerpen, Belgium
2072	   Phone: +32 3 240-8491
2073	   Email: Dimitri.Papadimitriou@alcatel.be

2075	25.2. Contributor Information

2077	   John Drake
2078	   Calient Networks
2079	   Email: jdrake@calient.net

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

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

2095	   Liming Wei
2096	   Redback Networks
2097	   350 Holger Way
2098	   San Jose, CA 95134
2099	   Email: lwei@redback.com

2101	   George Apostolopoulos
2102	   Redback Networks
2103	   350 Holger Way
2104	   San Jose, CA 95134
2105	   Email: georgeap@redback.com

2107	   Kireeti Kompella
2108	   Juniper Networks
2109	   1194 N. Mathilda Ave
2110	   Sunnyvale, CA 94089
2111	   Email: kireeti@juniper.net

2113	   George Swallow
2114	   Cisco Systems, Inc.
2115	   300 Beaver Brook Road
2116	   Boxborough , MA - 01719
2117	   USA
2118	   Email: swallow@cisco.com

2120	   JP Vasseur
2121	   Cisco Systems, Inc.
2122	   300 Beaver Brook Road
2123	   Boxborough , MA - 01719
2124	   USA
2125	   Email: jpv@cisco.com

2127	   Dean Cheng
2128	   Cisco Systems Inc.
2129	   170 W Tasman Dr.
2130	   San Jose, CA 95134
2131	   Phone 408 527 0677
2132	   Email:  dcheng@cisco.com

2134	   Markus Jork
2135	   Avici Systems
2136	   101 Billerica Avenue
2137	   N. Billerica, MA 01862
2138	   Phone: +1 978 964 2142
2139	   EMail: mjork@avici.com

2141	   Hisashi Kojima
2142	   NTT Corporation
2143	   9-11, Midori-Cho 3-Chome
2144	   Musashino-Shi, Tokyo 180-8585 Japan
2145	   Phone: +81 422 59 6070
2146	   EMail: kojima.hisashi@lab.ntt.co.jp

2148	   Andrew G. Malis
2149	   Tellabs
2150	   2730 Orchard Parkway
2151	   San Jose, CA 95134
2152	   Phone: +1 408 383 7223
2153	   Email: Andy.Malis@tellabs.com

2155	   Koji Sugisono
2156	   NTT Corporation
2157	   9-11, Midori-Cho 3-Chome
2158	   Musashino-Shi, Tokyo 180-8585 Japan
2159	   Phone: +81 422 59 2605
2160	   EMail: sugisono.koji@lab.ntt.co.jp

2162	   Masanori Uga
2163	   NTT Corporation
2164	   9-11, Midori-Cho 3-Chome
2165	   Musashino-Shi, Tokyo 180-8585 Japan
2166	   Phone: +81 422 59 4804
2167	   EMail: uga.masanori@lab.ntt.co.jp

2169	   Igor Bryskin
2170	   Movaz Networks, Inc.
2171	   7926 Jones Branch Drive
2172	   Suite 615
2173	   McLean VA, 22102

2175	   Adrian Farrel
2176	   Old Dog Consulting
2177	   Phone: +44 0 1978 860944
2178	   EMail: adrian@olddog.co.uk

2180	   Jean-Louis Le Roux
2181	   France Telecom
2182	   2, avenue Pierre-Marzin
2183	   22307 Lannion Cedex
2184	   France
2185	   E-mail: jeanlouis.leroux@francetelecom.com

2187	26. Intellectual Property

2189	   The IETF takes no position regarding the validity or scope of any
2190	   Intellectual Property Rights or other rights that might be claimed to
2191	   pertain to the implementation or use of the technology described in
2192	   this document or the extent to which any license under such rights
2193	   might or might not be available; nor does it represent that it has
2194	   made any independent effort to identify any such rights.  Information
2195	   on the procedures with respect to rights in RFC documents can be
2196	   found in BCP 78 and BCP 79.

2198	   Copies of IPR disclosures made to the IETF Secretariat and any assur-
2199	   ances of licenses to be made available, or the result of an attempt
2200	   made to obtain a general license or permission for the use of such
2201	   proprietary rights by implementers or users of this specification can
2202	   be obtained from the IETF on-line IPR repository at
2203	   http://www.ietf.org/ipr.

2205	   The IETF invites any interested party to bring to its attention any
2206	   copyrights, patents or patent applications, or other proprietary
2207	   rights that may cover technology that may be required to implement
2208	   this standard.  Please address the information to the IETF at ietf-
2209	   ipr@ietf.org.

2211	27. Full Copyright Statement

2213	   Copyright (C) The Internet Society (2005).  This document is subject
2214	   to the rights, licenses and restrictions contained in BCP 78, and
2215	   except as set forth therein, the authors retain all their rights.

2217	   This document and the information contained herein are provided on an
2218	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2219	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2220	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2221	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
2222	   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
2223	   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2225	28. Acknowledgement

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