idnits 2.17.1 

draft-ietf-mpls-rsvp-te-p2mp-02.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 21.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 2083.

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

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

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

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

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

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 48 pages


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

  ** There are 55 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 1130 has weird spacing: '...irst is  make-...'

  == Line 1277 has weird spacing: '...ed Path  messa...'

  == 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 mes-sages generated
     by a LSR to signal state for the same P2MP LSP have the same Sub-Group
     Originator ID and have a different sub-Group ID. The Sub-Group Originator
     ID SHOULD be set to the TE Router ID of the LSR that originates the Path
     message. This is either the ingress LSR or a LSR which re-originates the
     Path message with its own Sub-Group Originator ID. Cases when a transit
     LSR may change the Sub-Group Originator ID of an incoming Path message
     are described below. The <Sub-Group Originator ID, sub-Group ID> tuple is
     globally unique. The sub-Group ID space is specific to the Sub-Group
     Originator ID. There-fore the combination <Sub-Group Originator ID,
     sub-Group ID> is net-work-wide unique. Also, a router that changes the
     Sub-Group origina-tor ID of an incoming Path message MUST use the same
     value of the Sub-Group Originator ID for all outgoing Path messages, for
     a partic-ular 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. The
     Sub-Group Originator ID of a received Path message may also be changed in
     the outgoing Path message and set to that of the LSR orig-inating the
     Path message based on a local policy. For instance a LSR may decide to
     always change the Sub-Group Originator ID while per-forming 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 (July 2005) is 6853 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 143, but not defined

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

  == Missing Reference: 'RSVP-FR' is mentioned on line 1217, but not defined

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

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

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

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

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

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

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

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

  == Unused Reference: 'RFC2209' is defined on line 1897, 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 (~~), 27 warnings (==), 8 comments (--).

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

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

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

7	                                                    S. Yasukawa (Editor)
8	                                                                     NTT

10	                                                               July 2005

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

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

16	Status of this Memo

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

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

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

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

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

39	Abstract

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

52	Table of Contents

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

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

144	2. Terminology

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

149	3. Introduction

151	   [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS net-
152	   works. [RFC3473] defines extensions to [RFC3209] for setting up P2P
153	   TE LSPs in GMPLS networks. However these specifications do not pro-
154	   vide a mechanism for building P2MP TE LSPs.

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

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

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

172	4. Mechanism

174	   This document describes a solution that optimizes data replication by
175	   allowing non-ingress nodes in the network to be replication/branch
176	   nodes. A branch node is a LSR that is capable of replicating the
177	   incoming data on two or more outgoing interfaces. The solution uses
178	   RSVP-TE in the core of the network for setting up a P2MP TE LSP.

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

185	4.1. P2MP Tunnels

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

192	   A P2MP TE Tunnel comprises of one or more P2MP LSPs. A P2MP TE Tunnel
193	   is identified by a P2MP SESSION object. This object contains the
194	   identifier of the P2MP Session which includes the P2MP ID, a tunnel
195	   ID and an extended tunnel ID.

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

201	   The P2MP ID provides an identifier for the set of destinations of the
202	   P2MP TE Tunnel.

204	4.2. P2MP LSP

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

212	4.3. Sub-Groups

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

225	   These differences in P2MP state are addressed through the addition of
226	   a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-
227	   Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects.

229	   Taken together the Sub-Group ID and Sub-Group Originator ID are
230	   referred to as the Sub-Group fields.

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

242	4.4. S2L Sub-LSPs

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

246	4.4.1. Representation of a S2L Sub-LSP

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

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

264	4.4.2. S2L Sub-LSPs and Path Messages

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

275	4.5. Explicit Routing

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

287	   When a Path message signals multiple S2L sub-LSPs the path of the
288	   first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded
289	   in the ERO. The first S2L sub-LSP is the one that corresponds to the
290	   first S2L_SUB_LSP object in the Path message. The S2L sub-LSPs corre-
291	   sponding to the S2L_SUB_LSP objects that follow are termed as subse-
292	   quent S2L sub-LSPs.  One approach to encode the explicit route of a
293	   subsequent S2L sub-LSP is to include all the hops from the ingress to
294	   the egress of the S2L sub-LSP. However this implies potential repeti-
295	   tion of hops that can be learned from the ERO or explicit routes of
296	   other S2L sub-LSPs. Explicit route compression using SEROs attempts
297	   to minimize such repetition.

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

313	   Explicit route compression is illustrated using the following figure.

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

332	                        Figure 1. Explicit Route Compression

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

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

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

352	      S2L sub-LSP-F:   ERO = {D, C, F},  S2L_SUB_LSP Object-F
353	      S2L sub-LSP-N:   SERO = {D, G, J, N}, S2L_SUB_LSP Object-N

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

358	      S2L sub-LSP-O:   ERO = {H, K, O}, S2L_SUB_LSP Object-O
359	      S2L sub-LSP-P:   SERO = {H, L, P}, S2L_SUB_LSP Object-P,
360	      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q,
361	      S2L sub-LSP-R:   SERO = {Q, R}, S2L_SUB_LSP Object-R,

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

367	      S2L sub-LSP-O:   ERO  = {K, O}, S2L_SUB_LSP Object-O

369	   The encoding of the Path message sent by LSR H to LSR L is as fol-
370	   lows:

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

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

377	      S2L sub-LSP-Q:   ERO = {I, M, Q}, S2L_SUB_LSP Object-Q,
378	      S2L sub-LSP-R:   SERO = {Q, R}, S2L_SUB_LSP Object-R,

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

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

394	5. Path Message

396	5.1. Path Message Format

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

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

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

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

424	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC-
425	   ONDARY_EXPLICIT_ROUTE> ]

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

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

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

440	   Path message processing is described in the next section.

442	5.2. Path Message Processing

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

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

464	5.2.1. Multiple Path Messages

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

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

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

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

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

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

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

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

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

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

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

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

576	5.2.3. Transit Fragmentation

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

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

598	   As described above one case in which the Sub-Group Originator ID of a
599	   received Path message is changed is that of transit fragmentation.
600	   The Sub-Group Originator ID of a received Path message may also be
601	   changed in the outgoing Path message and set to that of the LSR orig-
602	   inating the Path message based on a local policy. For instance a LSR
603	   may decide to always change the Sub-Group Originator ID while per-
604	   forming ERO expansion. The Sub-Group ID MUST not be changed if the
605	   Sub-Group Originator ID is not being changed.

607	5.2.4. Control of Branch Fate Sharing

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

616	   The ingress LSP may request 'LSP integrity' by setting bit [TBA] of
617	   the Attributes Flags TLV. The bit is set if LSP integrity is
618	   required.

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

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

628	5.3. Grafting

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

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

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

647	6. Resv Message

649	6.1. Resv Message Format

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

653	   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
654	                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
655	                         [ <MESSAGE_ID> ]
656	                         <SESSION> <RSVP_HOP>
657	                         <TIME_VALUES>
658	                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
659	                         [ <NOTIFY_REQUEST> ]
660	                         [ <ADMIN_STATUS> ]
661	                         [ <POLICY_DATA> ... ]
662	                         <STYLE> <flow descriptor list>

664	   <flow descriptor list> ::= <FF flow descriptor list>
665	                              | <SE flow descriptor>

667	   <FF flow descriptor list> ::= <FF flow descriptor>
668	                                 | <FF flow descriptor list>
669	                                 <FF flow descriptor>

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

673	   <SE filter spec list> ::= <SE filter spec>
674	                            | <SE filter spec list> <SE filter spec>

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

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

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

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

689	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SEC-
690	   ONDARY_EXPLICIT_ROUTE> ]
691	   FILTER_SPEC is defined in section 20.4.

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

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

707	6.2. Resv Message Processing

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

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

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

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

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

736	   Each branch node can potentially send one Resv message upstream for
737	   each of the downstream receivers. This MAY result in overflowing the
738	   Resv message, particularly when considering that the number of mes-
739	   sages increases the closer the branch node is to the ingress.

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

749	6.2.1. Resv Message Throttling

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

765	6.3. Record Routing

767	6.3.1. RRO Processing

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

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

786	6.4. Reservation Style

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

802	7. PathTear Message

804	7.1. PathTear Message Format

806	   The format of the PathTear message is as follows:

808	   <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
809	                           [ [ <MESSAGE_ID_ACK> |
810	                               <MESSAGE_ID_NACK> ... ]
811	                           [ <MESSAGE_ID> ]
812	                           <SESSION> <RSVP_HOP>
813	                           [ <sender descriptor> ]
814	                           [ <S2L sub-LSP descriptor list> ]

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

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

822	7.2. Pruning

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

829	7.2.1. Implicit S2L Sub-LSP Teardown

831	   Implicit teardown uses standard RSVP message processing. Per standard
832	   RSVP processing, a S2L sub-LSP may be removed from a P2MP TE LSP by
833	   sending a modified message for the Path or Resv message that previ-
834	   ously advertised the S2L sub-LSP. This message MUST list all S2L sub-
835	   LSPs that are not being removed. When using this approach, a node
836	   processing a message that removes a S2L sub-LSP from a P2MP TE LSP
837	   MUST ensure that the S2L sub-LSP is not included in any other Path
838	   state associated with session before interrupting the data path to
839	   that egress.  All other message processing remains unchanged.

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

848	7.2.2. Explicit S2L Sub-LSP Teardown

850	   Explicit S2L Sub-LSP teardown relies on generating a PathTear message
851	   for the corresponding Path message. The PathTear message is signaled
852	   with the SESSION and SENDER_TEMPLATE objects corresponding to the
853	   P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple corre-
854	   sponding to the Path message. This approach SHOULD be used when all
855	   the egresses signaled by a Path message need to be removed from the
856	   P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled using
857	   other Path messages, are not affected by the PathTear.

859	   A transit LSR that propagates the PathTear message downstream MUST
860	   ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
861	   in the PathTear message to the values used to generate the previous
862	   Path message that corresponds to the S2L sub-LSPs being deleted by it
863	   in the PathTear message.  The transit LSR may need to generate multi-
864	   ple PathTear messages for an incoming PathTear message if it had per-
865	   formed transit fragmentation for the corresponding incoming Path mes-
866	   sage.

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

871	8. Notify and ResvConf Messages

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

876	   Notify Request and Notify messages are described in [RFC3473].  If a
877	   transit router sets the sub-group originator ID in the SENDER_TEM-
878	   PLATE object of a Path message to its own address and the Path mes-
879	   sage carries a Notify Request object then the router MUST set the
880	   notify node address in the Notify Request object to its own address.
881	   If this router receives a corresponding Notify message from down-
882	   stream than it MUST generate a Notify message upstream towards the
883	   Notify node address that the router had received in the incoming Path
884	   message. The receiver of a Notify message MUST identify the sender
885	   state referenced in the message based on the SESSION and SENDER_TEM-
886	   PLATE objects.

888	   ResvConf messages are described in [RFC2205]. An egress LSR may
889	   include a RESV_CONFIRM object that contains the egress LSR's address.
890	   If a transit LSR is merging Resv messages received from more than
891	   egress LSR and one or more of these Resv messages contain a RESV_CON-
892	   FIRM object than the transit LSR MUST set its own address in the
893	   RESV_CONFIRM object in the Resv message that it generates. Also if
894	   the transit LSR changes the sub-group originator ID in the generated
895	   Resv message and it includes a RESV_CONFIRM object in the Resv mes-
896	   sage, it MUST set its own address in the RESV_CONFIRM object.  Upon
897	   receiving a ResvConf message from upstream the transit LSR MUST gen-
898	   erate a ResvConf message towards each of the downstream LSRs that had
899	   included RESV_CONFIRM objects in the corresponding Resv messages.  As
900	   with Notify messages, the receiver of a ResvConf message MUST iden-
901	   tify the state referenced in the message based on the SESSION and
902	   FILTER_SPEC objects.

904	9. Refresh Reduction

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

911	10. State Management

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

918	   Additional information signaled in the Path message is part of the
919	   state created by a local implementation. This mandatorily includes
920	   PHOP and SENDER_TSPEC object.

922	10.1. Incremental State Update

924	   RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
925	   GMPLS [RFC3473] uses the same basic approach to state communication
926	   and synchronization, namely full state is sent in each state adver-
927	   tisement message. Per [RFC2205] Path and Resv messages are idempo-
928	   tent. Also, [RFC2961] categorizes RSVP messages into two types: trig-
929	   ger and refresh messages and improves RSVP message handling and scal-
930	   ing of state refreshes but does not modify the full state advertise-
931	   ment nature of Path and Resv messages. The full state advertisement
932	   nature of Path and Resv messages has many benefits, but also has some
933	   drawbacks. One notable drawback is when an incremental modification
934	   is being made to a previously advertised state. In this case, there
935	   is the message overhead of sending the full state and the cost of
936	   processing it. It is desirable to overcome this drawback and
937	   add/delete S2L sub-LSPs to a P2MP LSP by incrementally updating the
938	   existing state.

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

945	   As described in section 4.2, multiple Path messages can be used to
946	   signal a P2MP LSP. The Path messages are distinguished by different
947	   <Sub-Group Originator ID, sub-Group ID> tuples in the SENDER_TEMPLATE
948	   object.  In order to perform incremental S2L sub-LSP state addition a
949	   separate Path message with a new sub-Group ID is used to add the new
950	   S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be
951	   set to the TE Router ID [RFC3477] of the node that sets the Sub-Group
952	   ID.

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

958	10.2. Combining Multiple Path Messages

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

971	   The new Path message is signaled by the node that is combining multi-
972	   ple Path messages with all the S2L sub-LSPs that are being combined
973	   in a single Path message. This Path message MAY contain a new Sub-
974	   Group ID field value.  When a new Path and Resv message that is sig-
975	   naled for an existing S2L sub-LSP is received by a transit LSR, state
976	   including the new instance of the S2L sub-LSP is created.

978	   The S2L sub-LSP SHOULD continue to be advertised in both the old and
979	   new Path messages until a Resv message listing the S2L sub-LSP and
980	   corresponding to the new Path message is received by the combining
981	   node. Hence until this point state for the S2L sub-LSP SHOULD be
982	   maintained as part of the Path state for both the old and the new
983	   Path message [Section 3.1.3, 2205]. At that point the S2L sub-LSP
984	   SHOULD be deleted from the old Path state using the procedures of
985	   section 7.

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

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

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

1003	11. Error Processing

1005	   PathErr and ResvErr messages are processed as per RSVP-TE procedures.
1006	   Note that a LSR on receiving a PathErr/ResvErr message for a particu-
1007	   lar S2L sub-LSP changes the state only for that S2L sub-LSP. Hence
1008	   other S2L sub-LSPs are not impacted. In case the ingress node
1009	   requests the maintenance of the 'LSP integrity', any error reported
1010	   within the P2MP TE LSP must be reported at (least at) any other
1011	   branching nodes belonging to this LSP. Therefore, reception of an
1012	   error message for a particular S2L sub-LSP MAY change the state of
1013	   any other S2L sub- LSP of the same P2MP TE LSP.

1015	11.1. PathErr Messages

1017	   The PathErr message will include one or more S2L_SUB_LSP objects. The
1018	   resulting modified format for a PathErr Message is:

1020	   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1021	                             [ [<MESSAGE_ID_ACK> |
1022	                                <MESSAGE_ID_NACK>] ... ]
1023	                             [ <MESSAGE_ID> ]
1024	                             <SESSION> <ERROR_SPEC>
1025	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1026	                             [ <POLICY_DATA> ... ]
1027	                             <sender descriptor>
1028	                             [ <S2L sub-LSP descriptor list> ]

1030	   PathErr messages generation is unmodified, but nodes that set the
1031	   Sub-Group Originator field and propagate a received PathErr message
1032	   upstream MUST replace the Sub-Group fields received in the PathErr
1033	   message with the value that was received in the Sub-Group fields of
1034	   the Path message from the upstream neighbor.  Note the receiver of a
1035	   PathErr message is able to identify the errored outgoing Path mes-
1036	   sage, and outgoing interface, based on the Sub-Group fields received
1037	   in the PathErr message.

1039	11.2. ResvErr Messages

1041	   The ResvErr message will include one or more S2L_SUB_LSP objects. The
1042	   resulting modified format for a ResvErr Message is:

1044	   <ResvErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1045	                             [ [<MESSAGE_ID_ACK> |
1046	                                <MESSAGE_ID_NACK>] ... ]
1047	                             [ <MESSAGE_ID> ]
1048	                             <SESSION> <RSVP_HOP>
1049	                             <ERROR_SPEC> [ <SCOPE> ]
1050	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1051	                             [ <POLICY_DATA> ... ]
1052	                             <STYLE> <flow descriptor list>

1054	   ResvErr messages generation is unmodified, but nodes that set the
1055	   Sub-Group Originator field and propagate a received ResvErr message
1056	   downstream MUST replace the Sub-Group fields received in the ResvErr
1057	   message with the value that was set in the Sub-Group fields of the
1058	   Path message sent to the downstream neighbor. Note the receiver of a
1059	   ResvErr message is able to identify the errored outgoing Path mes-
1060	   sage, and outgoing interface, based on the Sub-Group fields received
1061	   in the ResvErr message.

1063	11.3. Branch Failure Handling

1065	   During setup and during normal operation, PathErr messages may be
1066	   received at a branch node. In all cases, a received PathErr message
1067	   is first processed per standard processing rules. That is: the
1068	   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
1069	   Path message.  Intermediate nodes until this ingress/branch LSR MAY
1070	   inspect this message but take no action upon it. The behavior of a
1071	   branch LSR that generates a PathErr message is under the control of
1072	   the ingress LSR.

1074	   The default behavior is that the PathErr does not have the
1075	   Path_State_Removed flag set. However, if the ingress LSR has set the
1076	   'LSP integrity' flag on the Path message (see LSP_ATTRIBUTE object in
1077	   section 20) and if the Path_State_Removed flag is supported, the LSR
1078	   generating a PathErr to report the failure of a branch of the P2MP
1079	   LSP SHOULD set the Path_State_Removed flag.

1081	   A branch LSR that receives a PathErr message with the
1082	   Path_State_Removed flag set MUST act according to the wishes of the
1083	   ingress LSR. The default behavior is that the branch LSR clears the
1084	   Path_State_Removed flag on the PathErr and sends it further upstream.
1085	   It does not tear any other branches of the LSP. However, if the LSP
1086	   integrity flag is set on the Path message, the branch LSR MUST send
1087	   PathTear on all downstream branches and send the PathErr message
1088	   upstream with the Path_State_Removed flag set.

1090	   A branch LSR that receives a PathErr message with the
1091	   Path_State_Removed flag clear MUST act according to the wishes of the
1092	   ingress LSR. The default behavior is that the branch LSR forwards the
1093	   PathErr upstream and takes no further action. However, if the LSP
1094	   integrity flag is set on the Path message, the branch LSR MUST send
1095	   PathTear on all downstream branches and send the PathErr upstream
1096	   with the Path_State_Removed flag set (per [RFC3473]).

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

1103	12. Admin Status Change

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

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

1117	13. Label Allocation on LANs with Multiple Downstream Nodes

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

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

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

1133	14.1. Make-before-break

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

1145	14.2. Sub-Group Based Re-optimization

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

1151	   To alter the path taken by a particular set of S2L sub-LSPs the node
1152	   initiating the path change initiates one or more separate Path mes-
1153	   sages, for the same P2MP LSP, each with a new sub-Group ID. The gen-
1154	   eration of these Path messages, each with one or more S2L sub-LSPs,
1155	   follows procedures in section 5.2. As is the case in Section 10.2, a
1156	   particular egress continues to be advertised in both the old and new
1157	   Path messages until a Resv message listing the egress and correspond-
1158	   ing to the new Path message is received by the re-optimizing node. At
1159	   that point the egress SHOULD be deleted from the old Path state using
1160	   the procedures of section 7.  Sub-tree re-optimization is then com-
1161	   pleted.

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

1166	15. Fast Reroute

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

1171	15.1. Facility Backup

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

1176	   If link protection is desired, a bypass tunnel is used to protect the
1177	   link between the PLR and next-hop. Thus all S2L sub-LSPs that use the
1178	   link can be protected in the event of link failure. Note that all
1179	   such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
1180	   will share the same outgoing label on the link between the PLR and
1181	   the next-hop. This is the P2MP LSP label on the link. Label stacking
1182	   is used to send data for each P2MP LSP in the bypass tunnel. The
1183	   inner label is the P2MP LSP label allocated by the nhop. During fail-
1184	   ure Path messages for each S2L sub-LSP, that is effected, will be
1185	   sent to the MP, by the PLR. It is recommended that the PLR use the
1186	   sender template specific method to identify these Path messages.
1187	   Hence the PLR will set the source address in the sender template to a
1188	   local PLR address. The MP will use the LSP-ID to identify the corre-
1189	   sponding S2L sub-LSPs.

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

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

1197	   If node protection is desired, the bypass P2P tunnel must intersect
1198	   the path of the protected S2L sub-LSPs on a LSR that is downstream
1199	   from the PLR. This constrains the set of S2L sub-LSPs being backed-up
1200	   via that bypass tunnel to those S2L sub-LSPs that pass through a com-
1201	   mon downstream MP. This MP is the destination of the bypass tunnel.
1202	   The MP will allocate the same label to all such S2L sub-LSPs belong-
1203	   ing to a particular instance of a P2MP tunnel. This will be the inner
1204	   label used during label stacking by the PLR when it sends data for
1205	   each P2MP LSP in the bypass tunnel.  The outer label is the bypass
1206	   tunnel label. During failure of the protected node the PLR will send
1207	   Path messages for the protected S2L Sub-LSPs to the MP using proce-
1208	   dures that are same as the link protection procedures described
1209	   above. Node protection may require the PLR to be branch capable as
1210	   multiple bypass tunnels may be required to backup the set of S2L sub-
1211	   LSPs passing through the protected node. Else all the S2L sub-LSPs
1212	   passing through the protected node must also pass through a MP that
1213	   is downstream from the protected node.

1215	15.2. One to One Backup

1217	   One to one backup as described in [RSVP-FR] can be used to protect a
1218	   particular S2L sub-LSP against link and next-hop failure. Protection
1219	   may be used for one or more S2L sub-LSPs between the PLR and the
1220	   next-hop. All the S2L sub-LSPs corresponding to the same instance of
1221	   the P2MP tunnel, between the PLR and the next-hop share the same P2MP
1222	   LSP label.

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

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

1231	   Its is recommended that the path specific method be used to identify
1232	   a backup S2L sub-LSP. Hence the DETOUR object will be inserted in the
1233	   backup Path message. A backup S2L sub-LSP MUST be treated as belong-
1234	   ing to a different P2MP tunnel instance than the one specified by the
1235	   LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be treated as
1236	   part of the same P2MP tunnel instance if they have the same LSP-id
1237	   and the same DETOUR objects. Note that as specified in section 4 S2L
1238	   sub-LSPs between different P2MP tunnel instances use different
1239	   labels.

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

1245	16. Support for LSRs that are not P2MP Capable

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

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

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

1266	   The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows to build
1267	   P2MP LSPs in such an environment. A P2P LSP segment is signaled from
1268	   the previous P2MP capable hop of a legacy LSR to the next P2MP capa-
1269	   ble hop. Of course this assumes that intermediate legacy LSRs are
1270	   transit LSRs and cannot act as P2MP branch points. Transit LSRs along
1271	   this LSP segment do not process control plane messages associated
1272	   with a P2MP LSP. Furthermore these LSRs also do not need to have P2MP
1273	   data plane capability as they only need to process data belonging to
1274	   the P2P LSP segment. Hence these LSRs do not need to support P2MP
1275	   MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP.
1276	   After the P2P LSP segment is established the P2MP Path message is
1277	   sent to the next P2MP capable LSR as a directed Path  message. The
1278	   next P2MP capable LSR stitches the P2P LSP segment to the outgoing
1279	   P2MP LSP.

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

1286	   It may be an overhead for an operator to configure the P2P LSP seg-
1287	   ments in advance, when it is desired to support legacy LSRs. It may
1288	   be desirable to do this dynamically. The ingress can use IGP exten-
1289	   sions to determine non P2MP capable LSRs [TE-NODE-CAP]. It can use
1290	   this information to compute S2L sub-LSP paths such that they avoid
1291	   these legacy LSRs. The explicit route object of a S2L sub-LSP path
1292	   may contain loose hops if there are legacy LSRs along the path. The
1293	   corresponding explicit route contains a list of objects upto the P2MP
1294	   capable LSR that is adjacent to a legacy LSR followed by a loose
1295	   object with the address of the next P2MP capable LSR. The P2MP capa-
1296	   ble LSR expands the loose hop using its TED. When doing this it
1297	   determines that the loose hop expansion requires a P2P LSP to tunnel
1298	   through the legacy LSR. If such a P2P LSP exists, it uses that P2P
1299	   LSP. Else it establishes the P2P LSP.  The P2MP Path message is sent
1300	   to the next P2MP capable LSR using non-adjacent signaling. The P2MP
1301	   capable LSR that initiates the non-adjacent signaling message to the
1302	   next P2MP capable LSR may have to employ a fast detection mechanism
1303	   such as [BFD] to the next P2MP capable LSR.

1305	   This may be needed for the directed Path message Head-End to use node
1306	   protection FRR when the protected node is the directed Path message
1307	   tail.

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

1312	17. Reduction in Control Plane Processing with LSP Hierarchy

1314	   It is possible to take advantage of LSP hierarchy [LSP-HIER] while
1315	   setting up P2MP LSP, as described in the previous section, to reduce
1316	   control plane processing along transit LSRs that are P2MP capable.
1317	   This is applicable only in environments where LSP hierarchy can be
1318	   used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP,
1319	   do not process control plane messages associated with the P2MP LSP.
1320	   Infact they are not aware of these messages as they are tunneled over
1321	   the P2P LSP segment. This reduces the amount of control plane pro-
1322	   cessing required on these transit LSRs.

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

1331	18. P2MP LSP Remerging and Cross-Over

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

1336	   The functional description described so far assumes that multiple
1337	   Path messages received by a LSR for the same P2MP LSP arrive on the
1338	   same incoming interface. However this may not always be the case.

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

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

1357	      b) The new S2L sub-LSP uses the same PHOP but different outgoing
1358	   interface as the existing S2L sub-LSP. This is a case of re-routing.
1359	      c) The new S2L sub-LSP uses a different PHOP and same outgoing
1360	   interface as the existing S2L sub-LSP. This is a case of re-routing.
1361	      d) The new S2L sub-LSP uses a different PHOP and a different out-
1362	   going interface as compared to the existing S2L sub-LSP. This is a
1363	   case of re-routing.

1365	   Case2: S2L sub-LSP does not exist as part of an existing Path state.
1366	   The following are the sub-cases.
1367	      a) The new S2L sub-LSP uses a PHOP and outgoing interface that is
1368	   same as the PHOP and outgoing interface used by an existing S2L sub-
1369	   LSP that belongs to the same P2MP LSP. This is a legal case of sig-
1370	   naling a new S2L sub-LSP.
1371	      b) The new S2L sub-LSP uses a PHOP that is same as that used by an
1372	   existing S2L sub-LSP. However the outgoing interface is different
1373	   from the outgoing interfaces used by existing S2L sub-LSPs belonging
1374	   to the same P2MP LSP. This is a legal case of signaling a new S2L
1375	   sub-LSP.
1376	      c) The new S2L sub-LSP uses a different PHOP than that used by any
1377	   of the existing S2L sub-LSP that belong to the same P2MP LSP . How-
1378	   ever the outgoing interface is same as the outgoing interface used by
1379	   an existing S2L sub-LSPs. This is a case of remerging.
1380	      d) The new S2L sub-LSP uses a different PHOP than that used by any
1381	   of the existing S2L sub-LSP that belong to the same P2MP LSP. Also
1382	   the outgoing interface is different from the outgoing interfaces used
1383	   by existing S2L sub-LSPs. This is a case of cross-over.

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

1389	   The below procedure applies for remerging.

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

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

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

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

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

1443	   This process may continue hop-by-hop until the ingress is reached.
1444	   The only case where this process will fail is when all the listed S2L
1445	   sub-LSPs are deleted prior to the PathErr message propagating to the
1446	   ingress. In this case, the whole process will be corrected on the
1447	   next (refresh or trigger) transmission of the offending Path message.

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

1452	19. New and Updated Message Objects

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

1457	19.1. SESSION Object

1459	   A P2MP LSP SESSION object is used. This object uses the existing SES-
1460	   SION C-Num. New C-Types are defined to accommodate a logical P2MP
1461	   destination identifier of the P2MP Tunnel. This SESSION object has a
1462	   similar structure as the existing point to point RSVP-TE SESSION
1463	   object. However the destination address is set to the P2MP ID instead
1464	   of the unicast Tunnel Endpoint address. All S2L sub-LSPs part of the
1465	   same P2MP LSP share the same SESSION object. This SESSION object
1466	   identifies the P2MP Tunnel.

1468	   The combination of the SESSION object, the SENDER_TEMPLATE object and
1469	   the S2L SUB-LSP object, identifies each S2L sub-LSP. This follows the
1470	   existing P2P RSVP-TE notion of using the SESSION object for identify-
1471	   ing a P2P Tunnel which in turn can contain multiple LSPs, each dis-
1472	   tinguished by a unique SENDER_TEMPLATE object.

1474	19.1.1. P2MP LSP Tunnel IPv4 SESSION Object

1476	   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA

1478	       0                   1                   2                   3
1479	       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
1480	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1481	      |                       P2MP ID                                 |
1482	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1483	      |  MUST be zero                 |      Tunnel ID                |
1484	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1485	      |                      Extended Tunnel ID                       |
1486	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1488	   P2MP ID

1490	      A 32-bit identifier used in the SESSION object that remains
1491	      constant over the life of the P2MP tunnel. It encodes the
1492	      P2MP ID and identifies the set of destinations of the P2MP
1493	      Tunnel.

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

1499	   Extended Tunnel ID

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

1507	19.1.2. P2MP LSP Tunnel IPv6 SESSION Object

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

1513	19.2. SENDER_TEMPLATE object

1515	   The sender template contains the ingress-LSR source address. LSP ID
1516	   can be can be changed to allow a sender to share resources with
1517	   itself. Thus multiple instances of the P2MP tunnel can be created,
1518	   each with a different LSP ID. The instances can share resources with
1519	   each other, but use different labels. The S2L sub-LSPs corresponding
1520	   to a particular instance use the same LSP ID.

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

1528	19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

1530	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBA

1532	         0                   1                   2                   3
1533	         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
1534	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1535	        |                   IPv4 tunnel sender address                  |
1536	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1537	        |       Reserved                |            LSP ID             |
1538	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1539	        |                   Sub-Group Originator ID                     |
1540	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1541	        |       Reserved                |            Sub-Group ID       |
1542	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1544	        IPv4 tunnel sender address
1545	            See [RFC3209]

1547	        Sub-Group Originator ID
1548	            The Sub-Group Originator ID is set to the TE Router ID of
1549	            the LSR that originates the Path message. This is either the
1550	            ingress LSR or a LSR which re-originates the Path message
1551	            with its own Sub-Group Originator ID.

1553	        Sub-Group ID
1554	            An identifier of a Path message used to differentiate
1555	            multiple Path messages that signal state for the same P2MP
1556	            LSP. This may be seen as identifying a group of one or more
1557	            egress nodes targeted by this Path message.

1559	        LSP ID
1560	           See [RFC3209]

1562	19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

1564	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBA

1566	         0                   1                   2                   3
1567	         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
1568	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1569	        |                                                               |
1570	        +                                                               +
1571	        |                   IPv6 tunnel sender address                  |
1572	        +                                                               +
1573	        |                            (16 bytes)                         |
1574	        +                                                               +
1575	        |                                                               |
1576	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1577	        |       Reserved                |            LSP ID             |
1578	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1579	        |                                                               |
1580	        +                                                               +
1581	        |                   Sub-Group Originator ID                     |
1582	        +                                                               +
1583	        |                            (16 bytes)                         |
1584	        +                                                               +
1585	        |                                                               |
1586	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1587	        |       Reserved                |            Sub-Group ID       |
1588	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1590	        IPv6 tunnel sender address
1591	           See [RFC3209]

1593	        Sub-Group Originator ID
1594	            The Sub-Group Originator ID is set to the IPv6 TE Router ID
1595	            of the LSR that originates the Path message. This is either
1596	            the ingress LSR or a LSR which re-originates the Path
1597	            message with its own Sub-Group Originator ID.

1599	        Sub-Group ID
1600	           As above.

1602	        LSP ID
1603	           See [RFC3209]

1605	19.3. S2L SUB-LSP Object

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

1610	19.3.1. S2L SUB-LSP IPv4 Object

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

1614	       0                   1                   2                   3
1615	       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
1616	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1617	      |                   IPv4 S2L Sub-LSP destination address        |
1618	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1620	   IPv4 Sub-LSP destination address

1622	      IPv4 address of the S2L sub-LSP destination.

1624	19.3.2. S2L SUB-LSP IPv6 Object

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

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

1631	       0                   1                   2                   3
1632	       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
1633	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1634	      |                   IPv6 S2L Sub-LSP destination address        |
1635	      |                        ....                                   |
1636	      |                                                               |
1637	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1639	19.4. FILTER_SPEC Object

1641	   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
1642	   object.

1644	19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object

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

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

1651	19.4.2. P2MP LSP_IPv4 FILTER_SPEC Object

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

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

1658	19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

1660	   The P2MP Secondary Explicit Route Object (SERO) is defined as identi-
1661	   cal to the ERO.  The class of the P2MP SERO is the same as the SERO
1662	   defined in [RECOVERY] (TBA).  The P2MP SERO C-Type = TBA The sub-
1663	   objects are identical to those defined for the ERO.

1665	19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

1667	   The P2MP Secondary Record Route Object (SRRO) is defined as identical
1668	   to the ERO.  The class of the P2MP SRRO is the same as the SRRO
1669	   defined in [RECOVERY] (TBA).  The P2MP SRRO C-Type = TBA.  The sub-
1670	   objects are identical to those defined for the RRO.

1672	20. IANA Considerations

1674	20.1. New Class Numbers

1676	   IANA is requested to assign the following Class Numbers for the new
1677	   object classes introduced. The Class Types for each of them are to be
1678	   assigned via standards action. The sub-object types for the P2MP SEC-
1679	   ONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same
1680	   IANA considerations as those of the ERO and RRO [RFC3209].

1682	   50  Class Name = SUB_LSP

1684	   C-Type
1685	      1   S2L_SUB_LSP_IPv4 C-Type
1686	      2   S2L_SUB_LSP_IPv6 C-Type

1688	20.2. New Class Types

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

1692	   Class Name = SESSION

1694	   C-Type
1695	     13    P2MP_LSP_IPv4 C-Type
1696	     14    P2MP_LSP_IPv6 C-Type

1698	   Class Name = SENDER_TEMPLATE

1700	   C-Type
1701	     12    P2MP_LSP_IPv4 C-Type
1702	     13    P2MP_LSP_IPv6 C-Type

1704	   Class Name = FILTER_SPEC

1706	   C-Type
1707	     12    P2MP LSP_IPv4 C-Type
1708	     13    P2MP LSP_IPv6 C-Type

1710	   Class Name = SECONDARY_EXPLICIT_ROUTE
1711	   C-Type
1712	      2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type

1714	   Class Name = SECONDARY_RECORD_ROUTE

1716	   C-Type
1717	      2  P2MP_SECONDARY_RECORD_ROUTE C-Type

1719	20.3. New Error Codes

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

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

1728	   The Error Code "Unsupported LSP Integrity" indicates that a P2MP
1729	   branch does not support the requested LSP integrity function. IANA is
1730	   requested to assign value 21 to this Error Code.

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

1736	20.4. LSP Attributes Flags

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

1742	   Suggested Bit Number:             3
1743	   Meaning:                          LSP Integrity Required
1744	   Used in Attributes Flags on Path: Yes
1745	   Used in Attributes Flags on Resv: No
1746	   Used in Attributes Flags on RRO:  No
1747	   Referenced Section of this Doc:   10

1749	21. Security Considerations

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

1754	22. Acknowledgements

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

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

1763	23. Appendix

1765	23.1. Example

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

1770	                   Source 1 (S1)
1771	                     |
1772	                    PE1
1773	                   |   |
1774	                   |L5 |
1775	                   P3  |
1776	                   |   |
1777	                L3 |L1 |L2
1778	       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
1779	                  | L4
1780	          PE5----PE4----R3
1781	                  |
1782	                  |
1783	                 R4

1785	                Figure 2.

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

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

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

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

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

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

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

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

1811	   e) P1 receives a Resv message from PE4 with label L4. It had previ-
1812	   ously received a Resv message from PE3 with label L3. It had allo-
1813	   cated a label L1 for the sub-LSP to PE3. It uses the same label and
1814	   sends the Resv messages to P3. Note that it may send only one Resv
1815	   message with multiple flow descriptors in the flow descriptor list.
1816	   If this is the case and FF style is used, the FF flow descriptor will
1817	   contain the S2L sub-LSP descriptor list with two entries: one for PE4
1818	   and the other for PE3. For SE style, the SE filter spec will contain
1819	   this S2L sub-LSP descriptor list. P1 also creates a label mapping of
1820	   (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv
1821	   message to PE1, with label L5. It reuses the label mapping of {L5 ->
1822	   L1}.

1824	24. References

1826	24.1. Normative References

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

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

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

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

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

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

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

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

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

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

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

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

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

1879	24.2. Informative References

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

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

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

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

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

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

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

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

1910	25. Author Information

1912	25.1. Editor Information

1914	   Rahul Aggarwal
1915	   Juniper Networks
1916	   1194 North Mathilda Ave.
1917	   Sunnyvale, CA 94089
1918	   Email: rahul@juniper.net

1920	   Seisho Yasukawa
1921	   NTT Corporation
1922	   9-11, Midori-Cho 3-Chome
1923	   Musashino-Shi, Tokyo 180-8585 Japan
1924	   Phone: +81 422 59 4769
1925	   EMail: yasukawa.seisho@lab.ntt.co.jp

1927	   Dimitri Papadimitriou
1928	   Alcatel
1929	   Francis Wellesplein 1,
1930	   B-2018 Antwerpen, Belgium
1931	   Phone: +32 3 240-8491
1932	   Email: Dimitri.Papadimitriou@alcatel.be

1934	25.2. Contributor Information

1936	   John Drake
1937	   Calient Networks
1938	   Email: jdrake@calient.net

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

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

1954	   Liming Wei
1955	   Redback Networks
1956	   350 Holger Way
1957	   San Jose, CA 95134
1958	   Email: lwei@redback.com

1960	   George Apostolopoulos
1961	   Redback Networks
1962	   350 Holger Way
1963	   San Jose, CA 95134
1964	   Email: georgeap@redback.com

1966	   Kireeti Kompella
1967	   Juniper Networks
1968	   1194 N. Mathilda Ave
1969	   Sunnyvale, CA 94089
1970	   Email: kireeti@juniper.net

1972	   George Swallow
1973	   Cisco Systems, Inc.
1974	   300 Beaver Brook Road
1975	   Boxborough , MA - 01719
1976	   USA
1977	   Email: swallow@cisco.com

1979	   JP Vasseur
1980	   Cisco Systems, Inc.
1981	   300 Beaver Brook Road
1982	   Boxborough , MA - 01719
1983	   USA
1984	   Email: jpv@cisco.com

1986	   Dean Cheng
1987	   Cisco Systems Inc.
1988	   170 W Tasman Dr.
1989	   San Jose, CA 95134
1990	   Phone 408 527 0677
1991	   Email:  dcheng@cisco.com

1993	   Markus Jork
1994	   Avici Systems
1995	   101 Billerica Avenue
1996	   N. Billerica, MA 01862
1997	   Phone: +1 978 964 2142
1998	   EMail: mjork@avici.com

2000	   Hisashi Kojima
2001	   NTT Corporation
2002	   9-11, Midori-Cho 3-Chome
2003	   Musashino-Shi, Tokyo 180-8585 Japan
2004	   Phone: +81 422 59 6070
2005	   EMail: kojima.hisashi@lab.ntt.co.jp

2007	   Andrew G. Malis
2008	   Tellabs
2009	   2730 Orchard Parkway
2010	   San Jose, CA 95134
2011	   Phone: +1 408 383 7223
2012	   Email: Andy.Malis@tellabs.com

2014	   Koji Sugisono
2015	   NTT Corporation
2016	   9-11, Midori-Cho 3-Chome
2017	   Musashino-Shi, Tokyo 180-8585 Japan
2018	   Phone: +81 422 59 2605
2019	   EMail: sugisono.koji@lab.ntt.co.jp

2021	   Masanori Uga
2022	   NTT Corporation
2023	   9-11, Midori-Cho 3-Chome
2024	   Musashino-Shi, Tokyo 180-8585 Japan
2025	   Phone: +81 422 59 4804
2026	   EMail: uga.masanori@lab.ntt.co.jp

2028	   Igor Bryskin
2029	   Movaz Networks, Inc.

2031	   7926 Jones Branch Drive
2032	   Suite 615
2033	   McLean VA, 22102

2035	   Adrian Farrel
2036	   Old Dog Consulting
2037	   Phone: +44 0 1978 860944
2038	   EMail: adrian@olddog.co.uk

2040	   Jean-Louis Le Roux
2041	   France Telecom
2042	   2, avenue Pierre-Marzin
2043	   22307 Lannion Cedex
2044	   France
2045	   E-mail: jeanlouis.leroux@francetelecom.com

2047	26. Intellectual Property

2049	   The IETF takes no position regarding the validity or scope of any
2050	   Intellectual Property Rights or other rights that might be claimed to
2051	   pertain to the implementation or use of the technology described in
2052	   this document or the extent to which any license under such rights
2053	   might or might not be available; nor does it represent that it has
2054	   made any independent effort to identify any such rights.  Information
2055	   on the procedures with respect to rights in RFC documents can be
2056	   found in BCP 78 and BCP 79.

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

2065	   The IETF invites any interested party to bring to its attention any
2066	   copyrights, patents or patent applications, or other proprietary
2067	   rights that may cover technology that may be required to implement
2068	   this standard.  Please address the information to the IETF at ietf-
2069	   ipr@ietf.org.

2071	27. Full Copyright Statement

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

2077	   This document and the information contained herein are provided on an
2078	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2079	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2080	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2081	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2082	   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2083	   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2085	28. Acknowledgement

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