idnits 2.17.1 

draft-ietf-mpls-rsvp-te-p2mp-01.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 3979, Section 5, paragraph 1 on line 1978.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1985.

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

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

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

  ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78
     -- however, there's a paragraph with a matching beginning. Boilerplate
     error?

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


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

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

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


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

  ** There are 103 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 758 has weird spacing: '...RRO and  possi...'

  == Line 793 has weird spacing: '...  leave  a P2M...'

  == Line 1254 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). 
     Multiple Path messages generated by a LSR to signal state for the same
     P2MP LSP have the same Sub-Group Originator ID and have a different
     sub-Group ID.  The Sub-Group Originator ID SHOULD be set to the TE Router
     ID of the LSR that originates the Path message. This is either the
     ingress LSR or a LSR which re-originates the Path message with its own
     Sub-Group Originator ID. Cases when a transit LSR may change the
     Sub-Group Originator ID of an incoming Path message are described below.
     The <Sub-Group Originator ID, sub-Group ID> tuple is network-wide unique.
     The sub-Group ID space is specific to the Sub-Group Originator ID.
     Therefore the combination <Sub-Group Originator ID, sub-Group ID> is
     network-wide unique. Also, a router that changes the Sub-Group Originator
     ID MUST use the same Sub-Group Originator ID on all Path messages for the
     same P2MP LSP Tunnel and SHOULD not vary the value during the life of the
     P2MP LSP Tunnel.

  == 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 originating the Path
     message based on a local policy. For instance a LSR may decide to always
     change the Sub-Group Originator ID while performing ERO expansion. The
     Sub-Group ID MUST not be changed if the Sub-Group Originator ID is not
     being changed.

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

  -- Couldn't find a document date in the document -- date freshness check
     skipped.


  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 52, but not defined

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

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

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

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

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

  == Unused Reference: 'RSVP-FRR' is defined on line 1802, but no explicit
     reference was found in the text

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

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

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

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

  == Outdated reference: A later version (-05) exists of
     draft-ietf-mpls-rsvpte-attributes-03

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

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

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

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


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

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

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


2	Network Working Group                       R. Aggarwal (Juniper)
3	Internet Draft                              D. Papadimitriou (Alcatel)
4	Expiration Date: June 2005                  S. Yasukawa (NTT)
5	                                            Editors

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

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

11	Status of this Memo

13	   By submitting this Internet-Draft, we certify that any applicable
14	   patent or IPR claims of which we are aware have been disclosed, and
15	   any of which we become aware will be disclosed, in accordance with
16	   RFC 3668.

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

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

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

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

34	Abstract

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

47	Conventions used in this document

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

53	Authors' Note

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

60	Table of Contents

62	       1      Terminology............................................. 4
63	       2      Introduction.............................................4
64	       3      Mechanisms.............................................. 4
65	       3.1    P2MP Tunnels............................................ 5
66	       3.2    P2MP LSP Tunnels........................................ 5
67	       3.3    Sub-Groups.............................................. 5
68	       3.4    S2L Sub-LSPs............................................ 6
69	       3.4.1  Representation of a S2L sub-LSP......................... 6
70	       3.4.2  S2L Sub-LSPs and Path Messages.......................... 6
71	       3.5    Explicit Routing........................................ 7
72	       4      Path Message............................................ 9
73	       4.1    Path Message Format..................................... 9
74	       4.2    Path Message Processing................................. 10
75	       4.2.1  Multiple Path Messages.................................. 11
76	       4.2.2  Multiple S2L Sub-LSPs in One Path Message............... 12
77	       4.2.3  Transit Fragmentation................................... 13
78	       4.3    Grafting................................................ 14
79	       4.3.1  Addition of S2L Sub-LSP................................. 14
80	       5      Resv Message............................................ 14
81	       5.1    Resv Message Format..................................... 14
82	       5.2    Resv Message Processing................................. 15
83	       5.2.1  Resv Message Throttling................................. 16
84	       5.3    Record Routing.......................................... 17
85	       5.3.1  RRO Processing.......................................... 17
86	       6      Reservation Style....................................... 17
87	       7      Path Tear Message....................................... 17
88	       7.1    Path Tear Message Format................................ 17
89	       7.2    Pruning................................................. 17
90	       7.2.1  Explicit S2L Sub-LSP Teardown........................... 17
91	       7.2.2  Implicit S2L Sub-LSP Teardown........................... 18
92	       7.2.1  P2MP TE LSP Teardown.................................... 19
93	       8      Notify and ResvConf Messages............................ 20
94	       9      Error Processing........................................ 20
95	       9.1    PathErr Message Format.................................. 20
96	       9.2    Handling of Failures at Branch LSRs..................... 21
97	       10     Refresh Reduction....................................... 22
98	       11     State Management........................................ 22
99	       11.1   Incremental State Update................................ 22
100	       11.2   Combining Multiple Path Messages........................ 23
101	       12     Control of Branch Fate Sharing.......................... 24
102	       13     Admin Status Change..................................... 24
103	       14     Label Allocation on LANs with Multiple Downstream Nodes. 25
104	       15     Make-Before-Break....................................... 25
105	       15.1   P2MP Tree re-optimization............................... 25
106	       15.2   Re-optimization of a subset of S2L sub-LSPs ............ 25
107	       16     Fast Reroute............................................ 26
108	       16.1   Facility Backpup........................................ 26
109	       16.2   One to One Backup....................................... 26
110	       17     Support for LSRs that are not P2MP Capable.............. 27
111	       18     Reduction in Control Plane Processing with LSP Hierarchy 29
112	       19     P2MP LSP Tunnel Remerging and Cross-Over................ 29
113	       20     New and Updated Message Objects......................... 31
114	       20.1   P2MP SESSION Object..................................... 31
115	       20.2   P2MP LSP Tunnel SENDER_TEMPLATE Object.................. 32
116	       20.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object............. 33
117	       20.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object............. 33
118	       20.3   S2L SUB-LSP Object...................................... 34
119	       20.3.1 S2L IPv4 SUB-LSP Object................................. 34
120	       20.3.2 S2L IPv6 SUB-LSP Object................................. 35
121	       20.4   FILTER_SPEC Object...................................... 35
122	       20.5   SUB EXPLICIT ROUTE Object (SERO)........................ 36
123	       20.6   SUB RECORD ROUTE Object (SRRO).......................... 36
124	       21     IANA Considerations..................................... 37
125	       22     Security Considerations................................. 37
126	       23     Acknowledgements........................................ 37
127	       24     Example P2MP LSP Establishment ......................... 37
128	       25     References.............................................. 39
129	       26     Authors................................................. 40
130	       27     Intellectual Property................................... 43
131	       28     Full Copyright Statement................................ 43
132	       29     Acknowledgement......................................... 44

134	1. Terminology

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

141	2. Introduction

143	   [RFC3209] defines a mechanism for setting up point-to-point (P2P)
144	   Traffic Engineered (TE) LSPs in MPLS networks. [RFC3473] defines
145	   extensions to [RFC3209] for setting up P2P TE LSPs in GMPLS networks.
146	   However these specifications do not provide a mechanism for building
147	   point-to-multipoint P2MP TE LSPs.

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

153	   This document relies on the semantics of RSVP that RSVP-TE inherits
154	   for building P2MP LSP Tunnels. A P2MP LSP Tunnel is comprised of
155	   multiple S2L sub-LSPs. These S2L sub-LSPs are set up between the
156	   ingress and egress LSRs and are appropriately combined by the branch
157	   LSRs using RSVP semantics to result in a P2MP TE LSP. One Path
158	   message may signal one or multiple S2L sub-LSPs. Hence the S2L sub-
159	   LSPs belonging to a P2MP LSP Tunnel can be signaled using one Path
160	   message or split across multiple Path messages.

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

165	3. Mechanism

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

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

178	3.1. P2MP Tunnels

180	   The specific aspect related to P2MP TE LSP is the action required at
181	   a branch node, where data replication occurs. Incoming labeled data
182	   is appropriately replicated to several outgoing interfaces which may
183	   have different labels.

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

190	   The fields of a P2MP SESSION object are identical to those of the
191	   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
192	   Address field is replaced by the P2MP Identifier (P2MP ID) field.
193	   The P2MP ID provides an identifier for the set of destinations of the
194	   P2MP TE Tunnel. The P2MP SESSION object is defined in section 20.1.

196	3.2. P2MP LSP Tunnel

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

204	3.3. Sub-Groups

206	   As with all other RSVP controlled LSP Tunnels, P2MP LSP Tunnel state
207	   is managed using RSVP messages. While use of RSVP messages is the
208	   same, P2MP LSP Tunnel state differs from P2P LSP state in a number of
209	   ways. A notable difference is that a P2MP LSP Tunnel is comprised of
210	   multiple S2L Sub-LSPs As a result of this, it may not be possible to
211	   signal a P2MP LSP Tunnel in a single RSVP-TE Path/Resv message. It is
212	   also possible that such a signaling message can not fit into a single
213	   IP packet. It must also be possible to efficiently add and remove
214	   endpoints to and from P2MP TE LSPs. An additional issue is that P2MP
215	   LSP Tunnels must also handle the state "remerge" problem [P2MP-REQ].

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

223	   The Sub-Group fields, together with rest of the SENDER_TEMPLATE and
224	   SESSION objects, are used to represent a portion of a P2MP LSP
225	   Tunnel's state. The portion of P2MP LSP Tunnel state identified by
226	   specific subgroup field values is referred to as a signaling sub-
227	   tree. It is important to note that the term "signaling sub-tree"
228	   refers only to signaling state and not data plane replication or
229	   branching. For example, it is possible for a node to "split"
230	   signaling state for a P2MP LSP Tunnel, but to not branch the data
231	   associated with the P2MP LSP Tunnel. Typical applications for
232	   generation and use of multiple subgroups are adding an egress and
233	   semantic fragmentation to ensure that a Path message remains within a
234	   single IP packet.

236	3.4. S2L Sub-LSPs

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

240	3.4.1. Representation of a S2L Sub-LSP

242	   A S2L sub-LSP exists within the context of a P2MP LSP Tunnel. Thus it
243	   is identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that
244	   are part of the P2MP SESSION, the tunnel sender address and LSP ID
245	   fields of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP
246	   destination address that is part of the S2L_SUB_LSP object. The
247	   S2L_SUB_LSP object is defined in section 20.3.

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

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

259	3.4.2. S2L Sub-LSPs and Path Messages

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

270	3.5. Explicit Routing

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

281	   When a Path message signals multiple S2L sub-LSPs the path of the
282	   first S2L sub-LSP, to the egress LSR, is encoded in the ERO. The
283	   first S2L sub-LSP is the one that corresponds to the first
284	   S2L_SUB_LSP object in the Path message. The S2L sub-LSPs
285	   corresponding to the S2L_SUB_LSP objects that follow are termed as
286	   subsequent S2L sub-LSPs.  One approach to encode the explicit route
287	   of a subsequent S2L sub-LSP is to include the path from the ingress
288	   to the egress of the S2L sub-LSP. However this implies potential
289	   repetition of hops that could be learned from the ERO or explicit
290	   routes of other S2L sub-LSPs. Explicit route compression using SEROs
291	   attempts to minimize such repetition and is described below.

293	   The path of each subsequent S2L sub-LSP is encoded in a
294	   SUB_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same
295	   as an ERO (as defined in [RFC3209]). Each subsequent S2L sub-LSP is
296	   represented by tuples of the form [<SUB_EXPLICIT_ROUTE>]
297	   <S2L_SUB_LSP>. There is a one to one correspondence between a
298	   S2L_SUB_LSP object and a SERO. A SERO for a particular S2L sub-LSP
299	   includes only the path from a certain branch LSR to the egress LSR if
300	   the path to that branch LSR can be derived from the ERO or other
301	   SEROs. The absence of a SERO should be interpreted as requiring hop-
302	   by-hop routing for that S2L sub-LSP. Note that the destination
303	   address is carried in the S2L sub-LSP object. The encoding of the
304	   SERO and S2L sub-LSP object are described in detail in section 20.

306	   Explicit route compression is illustrated using the following figure.

308	                                    A
309	                                    |
310	                                    |
311	                                    B
312	                                    |
313	                                    |
314	                          C----D----E
315	                          |    |    |
316	                          |    |    |
317	                          F    G    H-------I
318	                               |    |\      |
319	                               |    | \     |
320	                               J    K   L   M
321	                               |    |   |   |
322	                               |    |   |   |
323	                               N    O   P   Q--R

325	                        Figure 1. Explicit Route Compression

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

334	      S2L sub-LSP-F:   ERO = {B, E, D, C, F},  S2L_SUB_LSP Object-F
335	      S2L sub-LSP-N:   SERO = {D, G, J, N}, S2L_SUB_LSP Object-N
336	      S2L sub-LSP-O:   SERO = {E, H, K, O}, S2L_SUB_LSP Object-O
337	      S2L sub-LSP-P:   SERO = {H, L, P}, S2L_SUB_LSP Object-P,
338	      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q,
339	      S2L sub-LSP-R:   SERO = {Q, R}, S2L_SUB_LSP Object-R,

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

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

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

351	      S2L sub-LSP-O:   ERO = {H, K, O}, S2L_SUB_LSP Object-O
352	      S2L sub-LSP-P:   SERO = {H, L, P}, S2L_SUB_LSP Object-P,
353	      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, S2L_SUB_LSP Object-Q,
354	      S2L sub-LSP-R:   SERO = {Q, R}, S2L_SUB_LSP Object-R,

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

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

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

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

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

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

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

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

387	4. Path Message

389	4.1. Path Message Format

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

396	   <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
397	                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
398	                          [ <MESSAGE_ID> ]
399	                          <SESSION> <RSVP_HOP>
400	                          <TIME_VALUES>
401	                          [ <EXPLICIT_ROUTE> ]
402	                          <LABEL_REQUEST>
403	                          [ <PROTECTION> ]
404	                          [ <LABEL_SET> ... ]
405	                          [ <SESSION_ATTRIBUTE> ]
406	                          [ <NOTIFY_REQUEST> ]
407	                          [ <ADMIN_STATUS> ]
408	                          [ <POLICY_DATA> ... ]
409	                          <sender descriptor>
410	                          [S2L sub-LSP descriptor list]

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

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

417	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <SUB_EXPLICIT_ROUTE> ]

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

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

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

432	   Path message processing is described in the next section.

434	4.2. Path Message Processing

436	   The ingress-LSR initiates the set up of a S2L sub-LSP to each egress-
437	   LSR that is the destination of the P2MP LSP Tunnel. Each S2L sub-LSP
438	   is associated with the same P2MP LSP Tunnel using common P2MP SESSION
439	   object and <Source Address, LSP-ID> fields in the SENDER_TEMPLATE
440	   object.  Hence it can be combined with other S2L sub-LSPs to form a
441	   P2MP LSP Tunnel.  Another S2L sub-LSP belonging to the same instance
442	   of this S2L sub-LSP (i.e.  the same P2MP LSP Tunnel) can share
443	   resources with this LSP. The session corresponding to the P2MP TE
444	   tunnel is determined based on the P2MP SESSION object. Each S2L sub-
445	   LSP is identified using the S2L_SUB_LSP object. Explicit routing for
446	   the S2L sub-LSPs is achieved using the ERO and SEROs.

448	   As mentioned earlier, it is possible to signal S2L sub-LSPs for a
449	   given P2MP LSP Tunnel in one or more Path messages. And a given Path
450	   message can contain one or more S2L sub-LSPs.

452	4.2.1. Multiple Path messages

454	   As described in section 3, {<EXPLICIT_ROUTE>, <S2L SUB-LSP>} or
455	   {<SUB_EXPLICIT_ROUTE>, <S2L_SUB_LSP>} tuple is used to specify a S2L
456	   sub-LSP. Multiple Path messages can be used to signal a P2MP LSP
457	   Tunnel. Each Path message can signal one or more S2L sub-LSPs. If a
458	   Path message contains only one S2L sub-LSP, each LSR along the S2L
459	   sub-LSP follows [RFC3209] procedures for processing the Path message
460	   besides the S2L SUB-LSP object processing described in this document.

462	   Processing of Path messages containing more than one S2L sub-LSP is
463	   described in Section 4.3.

465	   An ingress LSR may use multiple Path messages for signaling a P2MP
466	   LSP. This may be because a single Path message may not be large
467	   enough to signal the P2MP LSP Tunnel. Or it may be while adding
468	   leaves to the P2MP LSP Tunnel the new leaves are signaled in a new
469	   Path message. Or an ingress LSR MAY choose to break the P2MP tree
470	   into separate manageable S2L sub-trees.  These trees share the same
471	   root and may share the trunk and certain branches.  The scope of this
472	   management decomposition of P2MP trees is bounded by a single tree
473	   and multiple S2L sub-trees with a single leaf each. As defined in
474	   [P2MP-REQ], a P2MP LSP Tunnel must have consistent attributes across
475	   all portions of a tree. This implies that each Path message that is
476	   used to signal a P2MP LSP Tunnel is signaled using the same signaling
477	   attributes with the exception of the S2L sub-LSP information.

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

483	   In certain cases a transit LSR may need to generate multiple Path
484	   messages to signal state corresponding to a single received Path
485	   message. For instance ERO expansion may result in an overflow of the
486	   resultant Path message. There are two cases occurring in such
487	   circumstances, either the message can be decomposed into multiple
488	   Path messages such that each of the message carries a subset of the
489	   incoming S2L sub-LSPs carried by the incoming message, or the message
490	   can not be decomposed such that each of the outgoing Path message
491	   fits its maximum size value.

493	   Multiple Path messages generated by a LSR that signal state for the
494	   same P2MP LSP are signaled with the same SESSION object and have the
495	   same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order
496	   to disambiguate these Path messages a <Sub-Group Originator ID, sub-
497	   Group ID> tuple is introduced (also referred to as the Sub-Group
498	   field).  Multiple Path messages generated by a LSR to signal state
499	   for the same P2MP LSP have the same Sub-Group Originator ID and have
500	   a different sub-Group ID.  The Sub-Group Originator ID SHOULD be set
501	   to the TE Router ID of the LSR that originates the Path message. This
502	   is either the ingress LSR or a LSR which re-originates the Path
503	   message with its own Sub-Group Originator ID. Cases when a transit
504	   LSR may change the Sub-Group Originator ID of an incoming Path
505	   message are described below. The <Sub-Group Originator ID, sub-Group
506	   ID> tuple is network-wide unique. The sub-Group ID space is specific
507	   to the Sub-Group Originator ID. Therefore the combination <Sub-Group
508	   Originator ID, sub-Group ID> is network-wide unique. Also, a router
509	   that changes the Sub-Group Originator ID MUST use the same Sub-Group
510	   Originator ID on all Path messages for the same P2MP LSP Tunnel and
511	   SHOULD not vary the value during the life of the P2MP LSP Tunnel.

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

517	4.2.2. Multiple S2L Sub-LSPs in one Path message

519	   The S2L sub-LSP descriptor list allows the signaling of one or more
520	   S2L sub-LSPs in one Path message. It is possible to signal multiple
521	   S2L sub-LSP objects and ERO/SERO combinations in a single Path
522	   message. Note that these objects are the ones that differentiate a
523	   S2L sub-LSP. Each LSR can use the common objects in the Path message
524	   and the S2L sub-LSP descriptors to process each S2L sub-LSP.

526	   All LSRs need to process the ERO corresponding to the first S2L sub-
527	   LSP when the ERO is present. If one or more SEROs are present an ERO
528	   MUST be present. The signaling information for the first S2L sub-LSP
529	   is propagated in a Path message by each LSR along the explicit route
530	   specified by the ERO. A LSR needs to process a S2L sub-LSP descriptor
531	   for a subsequent S2L sub-LSP only if the first hop in the
532	   corresponding SERO is a local address of that LSR. If this is not the
533	   case the S2L sub-LSP descriptor is included in the Path message sent
534	   to LSR that is the next hop to reach the first hop in the SERO. This
535	   next hop is determined by using the ERO or other SEROs that encode
536	   the path to the SERO's first hop.  If this is the case and the LSR is
537	   also the egress the S2L sub-LSP descriptor is not propagated
538	   downstream. If this is the case and the LSR is not the egress the S2L
539	   sub-LSP descriptor is included in a Path message sent to the next-hop
540	   determined from the SERO. Hence a branch LSR only propagates the
541	   relevant S2L sub-LSP descriptors on each downstream link. A S2L sub-
542	   LSP descriptor that is propagated on a downstream link only contains
543	   those S2L sub-LSPs that are routed using that link. This processing
544	   may result in a subsequent S2L sub-LSP in an incoming Path message to
545	   become the first S2L sub-LSP in an outgoing Path message.

547	   Note that if one or more SEROs contains loose hops, expansion of such
548	   loose hops may result in overflowing the Path message size.  Section
549	   4.2.3 describes how signaling of the set of S2L sub-LSPs can be split
550	   in more than one Path message.

552	   The Record Route Object (RRO) contains the hops traversed by the Path
553	   message and applies to all the S2L sub-LSPs signaled in the Path
554	   message. A transit LSR appends its address in an incoming RRO and
555	   propagates it downstream. A branch LSR forms a new RRO for each of
556	   the outgoing Path messages. Each such updated RRO is formed using the
557	   rules in [RFC3209].

559	   If a LSR is unable to support a S2L sub-LSP setup, a PathErr message
560	   MUST be sent for the impacted S2L sub-LSP, and normal processing of
561	   the rest of the P2MP LSP Tunnel SHOULD continue. The default behavior
562	   is that the remainder of the LSP is not impacted (that is, all other
563	   branches are allowed to set up) and the failed branches are reported
564	   in PathErr messages in which the Path_State_Reomved flag MUST NOT be
565	   set. However, the ingress LSR may set a LSP Integrity flag (see
566	   section 21.3) to request that if there is a setup failure on any
567	   branch the entire LSP should fail to set up.

569	4.2.3. Transit Fragmentation

571	   In certain cases a transit LSR may need to generate multiple Path
572	   messages to signal state corresponding to a single received Path
573	   message. For instance ERO expansion may result in an overflow of the
574	   resultant Path message. It is desirable not to rely on IP
575	   fragmentation in this case. In order to achieve this, the multiple
576	   Path messages generated by the transit LSR, MUST be signaled with the
577	   Sub-Group Originator ID set to the TE Router ID of the transit LSR
578	   and a distinct sub-Group ID. Thus each distinct Path message that is
579	   generated by the transit LSR for the P2MP LSP Tunnel carries a
580	   distinct <Sub-Group Originator ID, Sub-Group ID> tuple.

582	   When multiple Path messages are used by an ingress or transit node,
583	   each Path message SHOULD be identical with the exception of the S2L
584	   sub-LSP related information (e.g., SERO), message and hop information
585	   (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the SENDER_TEMPLATE
586	   objects. Except when performing a  make-before-break operation, the
587	   tunnel sender address and LSP ID fields MUST be the same in each
588	   message, and for transit nodes, the same as the values in the Path
589	   message.

591	   As described above one case in which the Sub-Group Originator ID of a
592	   received Path message is changed is that of transit fragmentation.
593	   The Sub-Group Originator ID of a received Path message may also be
594	   changed in the outgoing Path message and set to that of the LSR
595	   originating the Path message based on a local policy. For instance a
596	   LSR may decide to always change the Sub-Group Originator ID while
597	   performing ERO expansion. The Sub-Group ID MUST not be changed if the
598	   Sub-Group Originator ID is not being changed.

600	4.3. Grafting

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

606	4.3.1. Addition of S2L Sub-LSPs

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

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

621	5. Resv Message

623	5.1. Resv Message Format

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

627	   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
628	                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
629	                         [ <MESSAGE_ID> ]
630	                         <SESSION> <RSVP_HOP>
631	                         <TIME_VALUES>
632	                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
633	                         [ <NOTIFY_REQUEST> ]
634	                         [ <ADMIN_STATUS> ]
635	                         [ <POLICY_DATA> ... ]
636	                         <STYLE> <flow descriptor list>

638	   <flow descriptor list> ::= <FF flow descriptor list>
639	                              | <SE flow descriptor>

641	   <FF flow descriptor list> ::= <FF flow descriptor>
642	                                 | <FF flow descriptor list>
643	                                 <FF flow descriptor>

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

647	   <SE filter spec list> ::= <SE filter spec>
648	                            | <SE filter spec list> <SE filter spec>

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

653	   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
654	                            [ <RECORD_ROUTE> ]
655	                            [ <S2L sub-LSP descriptor list> ]

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

660	   FILTER_SPEC is defined in section 20.4.

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

666	   <S2L sub-LSP filte descriptor list> ::= <S2L sub-LSP filter
667	   descriptor>
668	                                       [ <S2L sub-LSP filter descriptor
669	   list> ]

671	   <S2L sub-LSP filte descriptor> ::= <S2L_SUB_LSP> [ <SUB_RECORD_ROUTE>
672	   ]

674	   The SUB_RECORD_ROUTE objects follow the same compression mechanism as
675	   the SUB_EXPLICIT_ROUTE objects. Note that a Resv message can signal
676	   multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object
677	   or different FILTER_SPEC objects. The same label is allocated if the
678	   FILTER_SPEC object is the same.

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

684	5.2. Resv Message Processing

686	   The egress LSR follows normal RSVP procedures while originating a
687	   Resv message. The Resv message carries the label allocated by the
688	   egress LSR.

690	   A subsequent node allocates its own label and passes it upstream in
691	   the Resv message. The node may combine multiple flow descriptors,
692	   from different Resv messages received from downstream, in one Resv
693	   message sent upstream. A Resv message is not sent upstream by a
694	   transit LSR until at least one Resv message has been received from a
695	   downstream neighbor except when the integrity bit is set in the
696	   LSP_ATTRIBUTE object.

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

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

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

712	   Each branch node can potentially send one Resv message upstream for
713	   each of the downstream receivers.  This may result in overflowing the
714	   Resv message, particularly when considering that the number of
715	   messages increases the closer the branch node is to the ingress.

717	   Transit nodes MUST replace the Sub-Group ID fields received in the
718	   FILTER_SPEC objects with the value that was received in the Sub-Group
719	   ID field of the Path message from the upstream neighbor, when the
720	   node set the Sub-Group Originator field in the associated Path
721	   message.  ResvErr message generation is unmodified.  Nodes
722	   propagating a received ResvErr message MUST use the Sub-Group field
723	   values carried in the corresponding Resv message.

725	   The solution for this issue is for further discussion.

727	5.2.1. Resv Message Throttling

729	   A branch node needs to send the Resv message being sent upstream
730	   whenever there is a change in a Resv message for a S2L sub-LSP
731	   received from downstream. This can result in excessive Resv messages
732	   sent upstream, particularly when the S2L sub-LSPs are established for
733	   the first time.  In order to mitigate this situation, branch nodes
734	   MAY limit their transmission of Resv messages. Specifically, in the
735	   case where the only change being sent in a Resv message is in one or
736	   more SRRO objects, the branch node SHOULD transmit the Resv message
737	   only after a delay time has passed since the transmission of the
738	   previous Resv message for the same session. This delayed Resv message
739	   SHOULD include SRROs for all branches. Specific mechanisms for Resv
740	   message throttling are implementation dependent and are outside the
741	   scope of this document.

743	5.3. Record Routing

745	5.3.1. RRO Processing

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

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

765	6. Reservation Style

767	   TBD

769	7. PathTear Message

771	7.1. PathTear message Format

773	   The format of the PathTear message is as follows:

775	   <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
776	                           [ [ <MESSAGE_ID_ACK> |
777	                             <MESSAGE_ID_NACK> ... ]
778	                           [ <MESSAGE_ID> ]
779	                           <SESSION> <RSVP_HOP>
780	                           [ <sender descriptor> ]
781	                           [ <S2L sub-LSP descriptor list> ]

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

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

789	7.2. Pruning

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

797	7.2.1. Explicit S2L Sub-LSP Teardown

799	   The S2L sub-LSP(s) being removed from the P2MP LSP Tunnel are
800	   signaled in a PathTear message. The PathTear message includes the S2L
801	   sub-LSP descriptor list which is included before the sender
802	   descriptor. Note that the PathTear message contains only the S2L sub-
803	   LSP(s) being removed and rest of the P2MP LSP Tunnel does not have to
804	   be re-signaled. This results in removal of the state corresponding to
805	   these S2L sub-LSPs. State for rest of the S2L sub-LSPs is not
806	   modified.

808	   In the first mechanism in order to delete one or more S2L Sub-LSPs, a
809	   PathTear message is sent with the list of S2L sub-LSPs being deleted.
810	   This is a form of explicit tear down. A single PathTear message can
811	   only contain S2L sub-LSPs that were signaled by the ingress using the
812	   same <Sub-Group Originator ID, Sub-Group ID> tuple. The PathTear
813	   message is signaled with the SESSION and SENDER_TEMPLATE objects
814	   corresponding to the P2MP LSP Tunnel and the <Sub-Group Originator
815	   ID, Sub-Group ID> tuple corresponding to the S2L sub-LSPs that are
816	   being deleted. A transit LSR that propagates the PathTear message
817	   downstream MUST ensure that it sets the <Sub-Group Originator ID,
818	   Sub-Group ID> tuple in the PathTear message to the values used to
819	   generate the last Path message that corresponds to the S2L sub-LSPs
820	   signaled in the PathTear message that it generates. The transit LSR
821	   may need to generate multiple PathTear messages for an incoming
822	   PathTear message if it had performed transit fragmentation for the
823	   corresponding incoming Path message.

825	   The Path messages from which the S2L sub-LSPs were deleted need to be
826	   refreshed with the remaining S2L sub-LSPs. Note that as a result of
827	   deleting one or more S2L sub-LSPs from a Path message the ERO
828	   compression encoding may have to be recomputed.

830	   When the last S2L sub-LSP is to be removed from a Path state, i.e.,
831	   there are no remaining S2L sub-LSPs to send in a Path message, a
832	   PathTear message SHOULD be sent carrying the Sub-Group ID of the Path
833	   message that no longer has any S2L sub-LSPs.

835	   The second mechanism is an explicit teardown mechanism that defines
836	   new syntax and semantics for a PathTear message. This new mechanism
837	   minimizes signaling required to remove a subset of S2L sub-LSPs set
838	   signaled in a Path message, and thereby reduces associated
839	   processing.  When using this mechanism each identified S2L sub-LSP is
840	   removed from the P2MP LSP Tunnel state, even if the S2L sub-LSP is
841	   advertised in multiple Path message.

843	   When using this approach, a PathTear message is generated. The
844	   PathTear message MUST identify each S2L sub-LSP to be removed, via a
845	   S2L_SUB_LSP object per S2L Sub-LSP, and include a SENDER_TEMPLATE
846	   object corresponding to the Path state being modified. The Sub-Group
847	   ID valued contained in the SENDER_TEMPLATE object message MUST be set
848	   to zero (0). Subsequent Path messages associated with the P2MP LSP
849	   Tunnel MUST NOT contain the removed S2L sub-LSPs, unless that S2L
850	   sub-LSP is being re-added to the P2MP LSP.

852	   To support the second mechanism, the receiver of PathTear message
853	   that is associated with a P2MP LSP Tunnel MUST check the value of a
854	   received Sub-Group ID fields.  When there is no SENDER_TEMPLATE
855	   object present or the value of the Sub-Group ID fields is non-zero,
856	   then PathTear processing as defined in the above explicit tear down
857	   mechanism must be followed.  When the Sub-Group ID field is zero (0),
858	   then the processing node MUST remove the identified egresses from all
859	   control plane state associated with the P2MP LSP Tunnel and adjust
860	   the data path appropriately.

862	7.2.2. Implicit S2L Sub-LSP Teardown

864	   The third mechanism to delete S2L sub-LSPs is implicit teardown which
865	   uses standard RSVP message processing. Per standard RSVP processing,
866	   a S2L sub-LSP may be removed from a P2MP TE LSP by sending a modified
867	   message for the Path or Resv message that previously advertised the
868	   S2L sub-LSP.  This message MUST list all S2L sub-LSPs that are not
869	   being removed. When using this approach, a node processing a message
870	   that removes a S2L sub-LSP from a P2MP TE LSP MUST ensure that the
871	   S2L sub-LSP is not included in any other Path state associated with
872	   session before interrupting the data path to that egress.  All other
873	   message processing remains unchanged.

875	7.2.3. P2MP TE LSP Teardown

877	   This operation is accomplished by listing all the S2L sub-LSPs in a
878	   PathTear message.

880	   A PathTear message must be generated for each Path message used to
881	   signal the P2MP LSP Tunnel.

883	8. Notify and ResvConf Messages

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

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

900	9. Error Processing

902	   Note that a LSR on receiving a PathErr/ResvErr message for a
903	   particular S2L sub-LSP changes the state only for that S2L sub-LSP.
904	   Hence other S2L sub-LSPs are not impacted. In case the ingress node
905	   requests the maintenance of the 'LSP Integrity', any error reported
906	   within the P2MP TE LSP must be reported at (least at) any other
907	   branching nodes belonging to this LSP. Therefore, reception of an
908	   error message for a particular S2L sub-LSP MAY change the state of
909	   any other S2L sub-LSP of the same P2MP TE LSP.

911	9.1. PathErr Message Format

913	   A PathErr message will include one or more S2L_SUB_LSP objects. The
914	   resulting modified format of a PathErr Message is:

916	   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
917	                             [ [<MESSAGE_ID_ACK> |
918	                               <MESSAGE_ID_NACK>] ... ]
919	                             [ <MESSAGE_ID> ]
920	                             <SESSION> <ERROR_SPEC>
921	                             [ <ACCEPTABLE_LABEL_SET> ... ]
922	                             [ <POLICY_DATA> ... ]
923	                             <sender descriptor>
924	                             [ <S2L sub-LSP descriptor list> ]

926	   PathErr messages generation is unmodified, but nodes that set the
927	   Sub-Group Originator field and propagate a received PathErr message
928	   upstream MUST replace the Sub-Group fields received in the PathErr
929	   message with the value that was received in the Sub-Group fields of
930	   the Path message from the upstream neighbor. Note the receiver of a
931	   PathErr message is able to identify the errored outgoing Path
932	   message, and outgoing interface, based on the Sub-Group fields
933	   received in the error message.

935	9.2. Handling of Failures at Branch LSRs

937	   During setup and during normal operation, PathErr messages may be
938	   received at a branch node. In all cases, a received PathErr message
939	   is first processed per standard processing rules. That is, the
940	   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
941	   Path message.  Intermediate nodes until this ingress/branch LSR MAY
942	   inspect this message but take no action upon it. The behavior of a
943	   branch LSR that generates a PathErr message is under the control of
944	   the ingress LSR.

946	   The default behavior is that the PathErr does not have the
947	   Path_State_Removed flag set. However, if the ingress LSR has set the
948	   'LSP Integrity' flag on the Path message (see LSP_ATTRIBUTE object in
949	   section 21.3) and if the Path_State_Removed flag is supported, the
950	   LSR generating a PathErr to report the failure of a branch of the
951	   P2MP LSP Tunnel SHOULD set the Path_State_Removed flag.

953	   A branch LSR that receives a PathErr message with the
954	   Path_State_Removed flag clear MUST act according to the wishes of the
955	   ingress LSR. The default behavior is that the branch LSR forwards the
956	   PathErr upstream and takes no further action. However, if the LSP
957	   integrity flag is set on the Path message, the branch LSR MUST send
958	   PathTear on all downstream branches and send the PathErr upstream
959	   with the Path_State_Removed flag set (per [RFC3473]).

961	   In all cases, the PathErr message forwarded by a branch LSR MUST
962	   contain the S2L sub-LSP identification and explicit routes of all
963	   branches that are errored (reported by received PathErr messages) and
964	   all branches that are explicitly torn by the branch LSR.

966	10. Refresh Reduction

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

974	11. State Management

976	   State signaled by a P2MP Path message is managed by an implementation
977	   using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as part of the
978	   SESSION object and <Tunnel Sender Address, LSP ID, Sub-Group
979	   Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE object.

981	   Additional information signaled in the Path message is part of the
982	   state created by an implementation. This mandatorily includes PHOP
983	   and SENDER_TSPEC objects.

985	11.1. Incremental State Update

987	   RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
988	   GMPLS [RFC3473] uses the same basic approach to state communication
989	   and synchronization, namely full state is sent in each state
990	   advertisement message. Per [RFC2205] Path and Resv messages are
991	   idempotent. Also, [RFC2961] categorizes RSVP messages into two types:
992	   trigger and refresh messages and improves RSVP message handling and
993	   scaling of state refreshes but does not modify the full state
994	   advertisement nature of Path and Resv messages. The full state
995	   advertisement nature of Path and Resv messages has many benefits, but
996	   also has some drawbacks. One notable drawback is when an incremental
997	   modification is being made to a previously advertised state. In this
998	   case, there is the message overhead of sending the full state and the
999	   cost of processing it. It is desirable to overcome this drawback and
1000	   add/delete S2L sub-LSPs to a P2MP LSP Tunnel by incrementally
1001	   updating the existing state.

1003	   It is possible to use the procedures described in this document to
1004	   allow S2L sub-LSPs to be incrementally added or deleted from the P2MP
1005	   LSP by allowing a Path or a PathTear message to incrementally change
1006	   the existing P2MP LSP Tunnel Path state.

1008	   As described in section 4.2, multiple Path messages can be used to
1009	   signal a P2MP LSP Tunnel. The Path messages are distinguished by
1010	   different <Sub-Group Originator ID, Sub-Group ID> tuples in the
1011	   SENDER_TEMPLATE object.  In order to perform incremental S2L sub-LSP
1012	   state addition a separate Path message with a new sub-Group ID is
1013	   used to add the new S2L sub-LSPs, by the ingress LSR. The Sub-Group
1014	   Originator ID MUST be set to the TE Router ID [RFC3477] of the node
1015	   that sets the Sub-Group ID.

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

1021	11.2. Combining Multiple Path Messages

1023	   There is a tradeoff between the number of Path messages used by the
1024	   ingress to maintain the P2MP LSP Tunnel and using full state refresh
1025	   to add S2L sub-LSPs. It is possible to combine S2L sub-LSPs
1026	   previously advertised in different Path messages into a single Path
1027	   message in order to reduce the number of Path messages needed to
1028	   maintain the P2MP LSP. This can also be done by a transit node that
1029	   performed fragmentation and at a later point is able to combine
1030	   multiple Path messages that it generated into a single Path message.
1031	   This may happen when one or more S2L sub-LSPs are pruned from the
1032	   existing Path states.

1034	   The new Path message is signaled by the node that is combining
1035	   multiple Path messages with all the S2L sub-LSPs that are being
1036	   combined in a single Path message. This Path message contains a new
1037	   Sub-Group ID field value. When a new Path and Resv message that is
1038	   signaled for an existing S2L sub-LSP is received by a transit LSR,
1039	   state including the new instance of the S2L sub-LSP is created.

1041	   The S2L sub-LSP SHOULD continue to be advertised in both the old and
1042	   new Path messages until a Resv message listing the S2L sub-LSP and
1043	   corresponding to the new Path message is received by the combining
1044	   node. Hence until this point state for the S2L sub-LSP SHOULD be
1045	   maintained as part of the Path state for both the old and the new
1046	   Path message [Section 3.1.3, 2205]. At that point the S2L sub-LSP
1047	   SHOULD be deleted from the old Path state using a PathTear message.
1048	   The S2L sub-LSP should also be removed from the old Path message and
1049	   the old Path message should be signaled again, if there are other
1050	   remaining S2L sub-LSPs in the old Path message.

1052	   A Path message with a Sub-Group_ID(n+1) may signal a set of S2L sub-
1053	   LSPs that belong partially or entirely to an already existing Sub-
1054	   Group_ID(i), i <= n, the SESSION object and <Sender Tunnel Address,
1055	   LSP-ID, Sub-Group Originator ID> being the same. Or it may signal a
1056	   strictly non-overlapping new set of S2L sub-LSPs with a strictly
1057	   higher Sub-Group_ID value.

1059	   1) If Sub-Group_ID(i) = Sub-Group_ID(n+1), i =< n then either a full
1060	   refresh is indicated by the Path message or a S2L Sub-LSP is added
1061	   to/deleted from the group signaled by Sub-Group_ID(n+1)

1063	   2) If Sub-Group_ID(i) != Sub-Group_ID(n+1), i =< n then the Path
1064	   message is signaling a set of S2L sub-LSPs that belong partially or
1065	   entirely to an already existing Sub-Group_ID(i) or a strictly non-
1066	   overlapping set of S2L sub-LSPs.

1068	12. Control of Branch Fate Sharing

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

1077	   The ingress LSP may request 'LSP integrity' by setting bit [section
1078	   21.3] of the Attributes Flags TLV. The bit is set if LSP integrity is
1079	   required.

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

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

1089	13. Admin Status Change

1091	   A branch node that receives an ADMIN_STATUS object processes it
1092	   normally and also relays the ADMIN_STATUS object in a Path on every
1093	   branch. All Path messages may be concurrently sent to the downstream
1094	   neighbors.

1096	   Downstream nodes process the change in the ADMIN_STATUS object per
1097	   [RFC3473], including generation of Resv messages. When the last
1098	   received upstream ADMIN_STATUS object had the R bit set, branch nodes
1099	   wait for a Resv message with a matching ADMIN_STATUS object to be
1100	   received (or a corresponding PathErr or ResvTear messsage) on all
1101	   branches before relaying a corresponding Resv message upstream.

1103	14. Label Allocation on LANs with Multiple Downstream Nodes

1105	   A sender on a LAN uses a different label for sending traffic to each
1106	   node on the LAN that belongs to the P2MP LSP Tunnel. Thus the sender
1107	   performs replication. It may be considered desirable on a LAN to use
1108	   the same label for sending traffic to multiple nodes belonging to the
1109	   same P2MP LSP Tunnel, to avoid replication. Procedures for doing this
1110	   are for further study. Given the relatively small number of receivers
1111	   on LANs typically deployed in MPLS networks, this is not currently
1112	   seen as a practical problem. Furthermore avoiding replication at the
1113	   sender on a LAN requires significant complexity in the control plane.
1114	   Given the tradeoff we propose the use of replication by the sender on
1115	   a LAN.

1117	15. Make-before-break

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

1121	15.1. P2MP Tree Re-optimization

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

1130	15.2. Re-optimization of a subset of S2L sub-LSPs

1132	   One way to accomplish re-optimization of a subset of S2L sub-LSPs
1133	   that belong to a P2MP LSP Tunnel is to resignal the entire tree with
1134	   a new LSP-ID as described in the previous subsection.

1136	   (There is NO-CONSENSUS between the authors on rest of the text in
1137	   this subsection and it needs further discussion.)

1139	   It is possible to accomplish re-optimization of one or more S2L sub-
1140	   LSPs without re-signaling rest of the P2MP LSP. To achieve this a
1141	   sub-LSP ID is used to identify each S2L sub-LSP. This is encoded in
1142	   the S2L sub-LSP object. Each re-optimized S2L sub-LSP is signaled
1143	   with a different sub-LSP ID and hence a new S2L sub-LSP is
1144	   established. Once the new setup is complete, the old S2L sub-LSP can
1145	   be torn down. In some cases this may result in transient data
1146	   duplication.

1148	16. Fast Reroute

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

1153	16.1. Facility Backup

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

1158	   If link protection is desired, a bypass tunnel is used to protect the
1159	   link between the PLR and next-hop. Thus all S2L sub-LSPs that use the
1160	   link can be protected in the event of link failure. Note that all
1161	   such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
1162	   will share the same outgoing label on the link between the PLR and
1163	   the next-hop. This is the P2MP LSP label on the link. Label stacking
1164	   is used to send data for each P2MP LSP in the bypass tunnel. The
1165	   inner label is the P2MP LSP Tunnel label allocated by the nhop.
1166	   During failure Path messages for each S2L sub-LSP, that is effected,
1167	   will be sent to the MP, by the PLR. It is recommended that the PLR
1168	   use the sender template specific method to identify these Path
1169	   messages. Hence the PLR will set the source address in the sender
1170	   template to a local PLR address. The MP will use the LSP-ID to
1171	   identify the corresponding S2L sub-LSPs.

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

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

1179	   If node protection is desired, the bypass tunnel must intersect the
1180	   path of the protected S2L sub-LSPs somewhere downstream of the PLR.
1181	   This constrains the set of S2L sub-LSPs being backed-up via that
1182	   bypass tunnel to those that pass through a common downstream MP. The
1183	   MP will allocate the same label to all such S2L sub-LSPs belonging to
1184	   a particular instance of a P2MP tunnel. This will be the inner label
1185	   used during label stacking. This may require the PLR to be branch
1186	   capable as multiple bypass tunnels may be required to backup the set
1187	   of S2L sub-LSPs passing through the protected node. Else all the S2L
1188	   sub-LSPs being backed up must pass through the same MP.

1190	16.2. One to One Backup

1192	   One to one backup as described in [RSVP-FR] can be used to protect a
1193	   particular S2L sub-LSP against link and next-hop failure. Protection
1194	   may be used for one or more S2L sub-LSPs between the PLR and the
1195	   next-hop. All the S2L sub-LSPs corresponding to the same instance of
1196	   the P2MP tunnel, between the PLR and the next-hop share the same P2MP
1197	   LSP Tunnel label.

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

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

1207	   Its is recommended that the path specific method be used to identify
1208	   a backup S2L sub-LSP. Hence the DETOUR object will be inserted in the
1209	   backup Path message. A backup S2L sub-LSP MUST be treated as
1210	   belonging to a different P2MP tunnel instance than the one specified
1211	   by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be
1212	   treated as part of the same P2MP tunnel instance if they have the
1213	   same LSP-id and the same DETOUR objects. Note that as specified in
1214	   section 3 S2L sub-LSPs between different P2MP tunnel instances use
1215	   different labels.

1217	   If there is only S2L sub-LSP in the Path message, the DETOUR object
1218	   applies to that sub-LSP. If there are multiple S2L sub-LSPs in the
1219	   Path message the DETOUR applies to all the S2L sub-LSPs.

1221	17. Support for LSRs that are not P2MP Capable

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

1230	   Its also conceivable that some LSRs, in a network deploying P2MP
1231	   capability, may not support the extensions described in this
1232	   document.  If a Path message for the establishment of a P2MP LSP
1233	   Tunnel reaches such an LSR it will reject it with a PathErr because
1234	   it will not recognize the C-Type of the P2MP SESSION object.

1236	   LSRs that do not support the P2MP extensions in this document may be
1237	   included as transit LSRs by the use of LSP-stitching and LSP-
1238	   hierarchy [LSP-HIER]. Note that LSRs that are required to play any
1239	   other role in the network (ingress, branch or egress) MUST support
1240	   the extensions defined in this document.

1242	   The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows P2MP LSP
1243	   Tunnels to be built in such an environment. A P2P LSP segment is
1244	   signaled from the previous P2MP capable hop of a legacy LSR to the
1245	   next P2MP capable hop. Of course this assumes that intermediate
1246	   legacy LSRs are transit LSRs and cannot act as P2MP branch points.
1247	   Transit LSRs along this LSP segment do not process control plane
1248	   messages associated with a P2MP LSP Tunnel. Furthermore these LSRs
1249	   also do not need to have P2MP data plane capability as they only need
1250	   to process data belonging to the P2P LSP segment. Hence these LSRs do
1251	   not need to support P2MP MPLS. This P2P LSP segment is stitched to
1252	   the incoming P2MP LSP Tunnel. After the P2P LSP segment is
1253	   established the P2MP Path message is sent to the next P2MP capable
1254	   LSR as a directed Path  message. The next P2MP capable LSR stitches
1255	   the P2P LSP segment to the outgoing P2MP LSP Tunnel.

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

1263	   It may be an overhead for an operator to configure the P2P LSP
1264	   segments in advance, when it is desired to support legacy LSRs. It
1265	   may be desirable to do this dynamically. The ingress can use IGP
1266	   extensions to determine non P2MP capable LSRs. It can use this
1267	   information to compute S2L sub-LSP paths such that they avoid these
1268	   legacy LSRs. The explicit route object of a S2L sub-LSP path may
1269	   contain loose hops if there are legacy LSRs along the path. The
1270	   corresponding explicit route contains a list of objects upto the P2MP
1271	   capable LSR that is adjacent to a legacy LSR followed by a loose
1272	   object with the address of the next P2MP capable LSR. The P2MP
1273	   capable LSR expands the loose hop using its TED. When doing this it
1274	   determines that the loose hop expansion requires a P2P LSP to tunnel
1275	   through the legacy LSR. If such a P2P LSP exists, it uses that P2P
1276	   LSP. Else it establishes the P2P LSP.  The P2MP Path message is sent
1277	   to the next P2MP capable LSR using non-adjacent signaling. The P2MP
1278	   capable LSR that initiates the non-adjacent signaling message to the
1279	   next P2MP capable LSR may have to employ a fast detection mechanism
1280	   such as [BFD] to the next P2MP capable LSR.

1282	   This may be needed for the directed Path message Head-End to use node
1283	   protection FRR when the protected node is the directed Path message
1284	   tail.

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

1289	18. Reduction in Control Plane Processing with LSP Hierarchy

1291	   It is possible to take advantage of LSP hierarchy [LSP-HIER] while
1292	   setting up P2MP LSP Tunnels, as described in the previous section, to
1293	   reduce control plane processing along transit LSRs that are P2MP
1294	   capable. This is applicable only in environments where LSP hierarchy
1295	   can be used. Transit LSRs along a P2P LSP segment, being used by a
1296	   P2MP LSP Tunnel, do not process control plane messages associated
1297	   with the P2MP LSP Tunnel. Infact they are not aware of these messages
1298	   as they are tunneled over the P2P LSP segment. This reduces the
1299	   amount of control plane processing required on these transit LSRs.

1301	   Note that the P2P LSP segments can be dynamically set up as described
1302	   in the previous section or preconfigured. For example in Figure 2,
1303	   PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path
1304	   messages for PE3 and PE4 can now be tunneled over the LSP segment.
1305	   Thus P3 is not aware of the P2MP LSP Tunnel and does not process the
1306	   P2MP control messages.

1308	19. P2MP LSP Tunnel Remerging and Cross-Over

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

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

1325	   Case1: S2L sub-LSP already exist as part of an existing Path state.
1326	   The following are the various sub-cases.

1328	   a) The new S2L sub-LSP uses the same PHOP and outgoing interface as
1329	   the existing S2L sub-LSP. This is either a refresh or can occur when
1330	   multiple existing Path messages are combined in a new Path message.

1332	   b) The new S2L sub-LSP uses the same PHOP but different outgoing
1333	   interface as the existing S2L sub-LSP. This is a case of re-routing.

1335	   c) The new S2L sub-LSP uses a different PHOP and same outgoing
1336	   interface as the existing S2L sub-LSP. This is a case of re-merging.

1338	   d) The new S2L sub-LSP uses a different PHOP and a different outgoing
1339	   interface as compared to the existing S2L sub-LSP. This is a case of
1340	   cross-over.

1342	   Case2: S2L sub-LSP does not exist as part of an existing Path state.
1343	   The following are the sub-cases.

1345	   a) The new S2L sub-LSP uses a PHOP and outgoing interface that is
1346	   same as the PHOP and outgoing interface used by an existing S2L sub-
1347	   LSP. This is a legal case of signaling a new S2L sub-LSP.

1349	   b) The new S2L sub-LSP uses a PHOP that is same as that used by an
1350	   existing S2L sub-LSP. However the outgoing interface is different
1351	   from the outgoing interfaces used by existing S2L sub-LSPs. This is a
1352	   legal case of signaling a new S2L sub-LSP.

1354	   c) The new S2L sub-LSP uses a different PHOP than that used by any of
1355	   the existing S2L sub-LSP. However the outgoing interface is same as
1356	   the outgoing interface used by an existing S2L sub-LSPs. This is a
1357	   case of remerging.

1359	   d) The new S2L sub-LSP uses a different PHOP than that used by any of
1360	   the existing S2L sub-LSP. Also the outgoing interface is different
1361	   from the outgoing interfaces used by existing S2L sub-LSPs. This is a
1362	   case of cross-over.

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

1369	   The below procedure applies for remerging.

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

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

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

1388	   If there are no overlap in the lists, and the LSR is capable of
1389	   remerging in the data plane, this is considered legal. Else the new
1390	   Path message MUST be handled according to remerge error processing as
1391	   described below.

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

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

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

1425	20. New and Updated Message Objects

1427	   This section presents the new and updated RSVP message objects used
1428	   by this document.

1430	20.1. P2MP LSP Tunnel SESSION Object

1432	   A P2MP LSP Tunnel SESSION object is used. This object uses the
1433	   existing SESSION C-Num. New C-Types are defined to accommodate a
1434	   logical P2MP destination identifier of the P2MP Tunnel. This SESSION
1435	   object has a similar structure as the existing point to point RSVP-TE
1436	   SESSION object. However the destination address is set to the P2MP ID
1437	   instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs part
1438	   of the same P2MP LSP Tunnel share the same SESSION object. This
1439	   SESSION object identifies the P2MP Tunnel.

1441	   The combination of the SESSION object, the SENDER_TEMPLATE object and
1442	   the S2L SUB-LSP object, identifies each S2L sub-LSP. This follows the
1443	   existing P2P RSVP-TE notion of using the SESSION object for
1444	   identifying a P2P Tunnel which in turn can contain multiple LSP
1445	   Tunnels, each distinguished by a unique SENDER_TEMPLATE object.

1447	20.1.1. P2MP IPv4 LSP SESSION Object

1449	   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD

1451	       0                   1                   2                   3
1452	       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
1453	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1454	      |                       P2MP ID                                 |
1455	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1456	      |  MUST be zero                 |      Tunnel ID                |
1457	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1458	      |                      Extended Tunnel ID                       |
1459	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1461	   P2MP ID

1463	      A 32-bit identifier used in the SESSION object that remains
1464	      constant over the life of the P2MP tunnel. It encodes the
1465	      P2MP ID and identifies the set of destinations of the P2MP
1466	      LSP Tunnel.

1468	   Tunnel ID

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

1473	   Extended Tunnel ID

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

1481	20.1.2. P2MP IPv6 LSP SESSION Object

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

1487	20.2. SENDER_TEMPLATE object

1489	   The sender template contains the ingress-LSR source address. LSP ID
1490	   can be changed to allow a sender to share resources with itself. Thus
1491	   multiple instances of the P2MP tunnel can be created, each with a
1492	   different LSP ID. The instances can share resources with each other,
1493	   but use different labels. The S2L sub-LSPs corresponding to a
1494	   particular instance use the same LSP ID.

1496	   As described in section 4.2 it is necessary to distinguish different
1497	   Path messages that are used to signal state for the same P2MP LSP
1498	   Tunnel by using a <Sub-Group ID Originator ID, Sub-Group ID> tuple.
1499	   There are various methods to encode this information. This document
1500	   proposes the use of the SENDER_TEMPLATE object and modifies it to
1501	   carry this information as shown below. This encoding is subject to
1502	   review by the MPLS WG.

1504	20.2.1. P2MP IPv4 LSP Tunnel SENDER_TEMPLATE Object

1506	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD

1508	         0                   1                   2                   3
1509	         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
1510	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1511	        |                   IPv4 tunnel sender address                  |
1512	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1513	        |       Reserved                |            LSP ID             |
1514	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1515	        |                   Sub-Group Originator ID                     |
1516	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1517	        |       Reserved                |            Sub-Group ID       |
1518	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1519	        IPv4 tunnel sender address
1520	            See [RFC3209]

1522	        Sub-Group Originator ID
1523	            The Sub-Group Originator ID is set to the TE Router ID of
1524	            the LSR that originates the Path message. This is either the
1525	            ingress LSR or a LSR which re-originates the Path message
1526	            with its own Sub-Group Originator ID.

1528	        Sub-Group ID
1529	            An identifier of a Path message used to differentiate
1530	            multiple Path messages that signal state for the same P2MP
1531	            LSP. This may be seen as identifying a group of one or more
1532	            egress nodes targeted by this Path message. If the third
1533	            mechanism for pruning is used as described in section 7.2,
1534	            the Sub-Group ID value of zero (0) has special meaning and
1535	            MUST NOT be used with P2MP LSP Tunnels in messages other
1536	            than PathTear messages. Use of a Sub-Group ID value of zero
1537	            (0) in PathTear messages is defined below.

1539	        LSP ID
1540	           See [RFC3209]

1542	20.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

1544	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBD

1546	         0                   1                   2                   3
1547	         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
1548	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1549	        |                                                               |
1550	        +                                                               +
1551	        |                   IPv6 tunnel sender address                  |
1552	        +                                                               +
1553	        |                            (16 bytes)                         |
1554	        +                                                               +
1555	        |                                                               |
1556	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1557	        |       Reserved                |            LSP ID             |
1558	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1559	        |                                                               |
1560	        +                                                               +
1561	        |                   Sub-Group Originator ID                     |
1562	        +                                                               +
1563	        |                            (16 bytes)                         |
1564	        +                                                               +
1565	        |                                                               |
1566	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1567	        |       Reserved                |            Sub-Group ID       |
1568	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1570	        IPv6 tunnel sender address
1571	           See [RFC3209]

1573	        Sub-Group Originator ID
1574	            The Sub-Group Originator ID is set to the IPv6 TE Router ID
1575	            of the LSR that originates the Path message. This is either
1576	            the ingress LSR or a LSR which re-originates the Path
1577	            message with its own Sub-Group Originator ID.

1579	        Sub-Group ID
1580	           As above.

1582	        LSP ID
1583	           See [RFC3209]

1585	20.3. S2L SUB-LSP IPv4 Object

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

1590	20.3.1. S2L SUB-LSP IPv4 Object

1592	   SUB_LSP Class = TBD, S2L_SUB_LSP_IPv4 C-Type = TBD

1594	       0                   1                   2                   3
1595	       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
1596	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1597	      |                   IPv4 S2L Sub-LSP destination address        |
1598	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1599	      |  MUST be zero                 |            Sub-LSP ID         |
1600	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1602	   IPv4 Sub-LSP destination address

1604	      IPv4 address of the S2L sub-LSP destination.

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

1609	   Sub-LSP ID

1611	      A 16-bit identifier that identifies a particular instance
1612	      of a S2L sub-LSP. It can be varied for S2L sub-LSP
1613	      make-before-break. Different S2L sub-LSPs, with the same SESSION
1614	      object and LSP ID, follow the label merge semantics described in
1615	      section 3 to form a particular instance of the P2MP tunnel.

1617	20.3.2. S2L SUB-LSP IPv6 Object

1619	   SUB_LSP Class = TBD, S2L_SUB_LSP_IPv6 C-Type = TBD

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

1624	20.4. FILTER_SPEC Object

1626	   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
1627	   object.

1629	20.4.1. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object

1631	   Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv4 C-Type = TBD

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

1636	20.4.2. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object

1638	   Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv6 C_Type = TBD

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

1643	20.5. SUB_EXPLICIT_ROUTE Object (SERO)

1645	   The SERO is defined as identical to the ERO.  The CNums are TBD and
1646	   TBD of the form 11bbbbbb.

1648	20.6. SUB_RECORD_ROUTE Object (SRRO)

1650	   The SRRO is defined as identical to the RRO.  The CNums are TBD and
1651	   TBD of the form 11bbbbbb.

1653	21. IANA Considerations

1655	21.1. New Message Objects

1657	   IANA considerations for new message objects will be specified after
1658	   the objects used are decided upon.

1660	21.2. New Error Codes

1662	   Two new Error Codes are defined for use with the Error Value "Routing
1663	   Error". IANA is requested to assign values.

1665	   The Error Code "Unable to Branch" indicates that a P2MP branch cannot
1666	   be formed by the reporting LSR.

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

1671	21.3. LSP Attributes Flags

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

1677	   Suggested Bit Number:             3
1678	   Meaning:                          LSP Integrity Required
1679	   Used in Attributes Flags on Path: Yes
1680	   Used in Attributes Flags on Resv: No
1681	   Used in Attributes Flags on RRO:  No
1682	   Referenced Section of this Document:   12

1684	   Suggested Bit Number:             4
1685	   Meaning:                          Branch Reoptimization Allowed
1686	   Used in Attributes Flags on Path: Yes
1687	   Used in Attributes Flags on Resv: No
1688	   Used in Attributes Flags on RRO:  No
1689	   Referenced Section of this Document: TBD

1691	22. Security Considerations

1693	   This document does not introduce any new security issues. The
1694	   security issues identified in [RFC3209] and [RFC3473] are still
1695	   relevant.

1697	23. Acknowledgements

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

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

1706	24. Example P2MP LSP Establishment

1708	   Following is one example of setting up a P2MP LSP Tunnel using the
1709	   procedures described in this document.

1711	                   Source 1 (S1)
1712	                     |
1713	                    PE1
1714	                   |   |
1715	                   |L5 |
1716	                   P3  |
1717	                   |   |
1718	                L3 |L1 |L2
1719	       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
1720	                  | L4
1721	          PE5----PE4----R3
1722	                  |
1723	                  |
1724	                 R4

1726	                Figure 2.

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

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

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

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

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

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

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

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

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

1765	25. References

1767	25.1. Normative References

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

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

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

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

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

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

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

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

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

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

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

1810	25.2. Informative References

1812	      [BFD]      D. Katz, D. Ward, "Bidirectional Forwarding Detection",
1813	                                                draft-katz-ward-bfd-01.txt.

1815	      [BFD-MPLS] R. Aggarwal, K. Kompella, "BFD for MPLS LSPs",
1816	                 draft-raggarwa-mpls-bfd-00.txt

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

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

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

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

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

1833	26. Author Information

1835	26.1. Editor Information

1837	   Rahul Aggarwal
1838	   Juniper Networks
1839	   1194 North Mathilda Ave.
1840	   Sunnyvale, CA 94089
1841	   Email: rahul@juniper.net

1843	   Seisho Yasukawa
1844	   NTT Corporation
1845	   9-11, Midori-Cho 3-Chome
1846	   Musashino-Shi, Tokyo 180-8585 Japan
1847	   Phone: +81 422 59 4769
1848	   EMail: yasukawa.seisho@lab.ntt.co.jp

1850	   Dimitri Papadimitriou
1851	   Alcatel
1852	   Francis Wellesplein 1,
1853	   B-2018 Antwerpen, Belgium
1854	   Phone: +32 3 240-8491
1855	   Email: Dimitri.Papadimitriou@alcatel.be

1857	26.2. Contributor Information

1859	   John Drake
1860	   Calient Networks
1861	   Email: jdrake@calient.net

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

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

1877	   Liming Wei
1878	   Redback Networks
1879	   350 Holger Way
1880	   San Jose, CA 95134
1881	   Email: lwei@redback.com

1883	   George Apostolopoulos
1884	   Redback Networks
1885	   350 Holger Way
1886	   San Jose, CA 95134
1887	   Email: georgeap@redback.com

1889	   Kireeti Kompella
1890	   Juniper Networks
1891	   1194 N. Mathilda Ave
1892	   Sunnyvale, CA 94089
1893	   Email: kireeti@juniper.net

1895	   George Swallow
1896	   Cisco Systems, Inc.
1897	   300 Beaver Brook Road
1898	   Boxborough , MA - 01719
1899	   USA
1900	   Email: swallow@cisco.com

1902	   JP Vasseur
1903	   Cisco Systems, Inc.
1904	   300 Beaver Brook Road
1905	   Boxborough , MA - 01719
1906	   USA
1907	   Email: jpv@cisco.com

1909	   Dean Cheng
1910	   Cisco Systems Inc.
1911	   170 W Tasman Dr.
1912	   San Jose, CA 95134
1913	   Phone 408 527 0677
1914	   Email:  dcheng@cisco.com

1916	   Markus Jork
1917	   Avici Systems
1918	   101 Billerica Avenue
1919	   N. Billerica, MA 01862
1920	   Phone: +1 978 964 2142
1921	   EMail: mjork@avici.com

1923	   Hisashi Kojima
1924	   NTT Corporation
1925	   9-11, Midori-Cho 3-Chome
1926	   Musashino-Shi, Tokyo 180-8585 Japan
1927	   Phone: +81 422 59 6070
1928	   EMail: kojima.hisashi@lab.ntt.co.jp

1930	   Andrew G. Malis
1931	   Tellabs
1932	   2730 Orchard Parkway
1933	   San Jose, CA 95134
1934	   Phone: +1 408 383 7223
1935	   Email: Andy.Malis@tellabs.com

1937	   Koji Sugisono
1938	   NTT Corporation
1939	   9-11, Midori-Cho 3-Chome
1940	   Musashino-Shi, Tokyo 180-8585 Japan
1941	   Phone: +81 422 59 2605
1942	   EMail: sugisono.koji@lab.ntt.co.jp

1944	   Masanori Uga
1945	   NTT Corporation
1946	   9-11, Midori-Cho 3-Chome
1947	   Musashino-Shi, Tokyo 180-8585 Japan
1948	   Phone: +81 422 59 4804
1949	   EMail: uga.masanori@lab.ntt.co.jp

1951	   Igor Bryskin
1952	   Movaz Networks, Inc.
1953	   7926 Jones Branch Drive
1954	   Suite 615
1955	   McLean VA, 22102

1957	   Adrian Farrel
1958	   Old Dog Consulting
1959	   Phone: +44 0 1978 860944
1960	   EMail: adrian@olddog.co.uk

1962	   Jean-Louis Le Roux
1963	   France Telecom
1964	   2, avenue Pierre-Marzin
1965	   22307 Lannion Cedex
1966	   France
1967	   E-mail: jeanlouis.leroux@francetelecom.com

1969	27. Intellectual Property

1971	   The IETF takes no position regarding the validity or scope of any
1972	   Intellectual Property Rights or other rights that might be claimed to
1973	   pertain to the implementation or use of the technology described in
1974	   this document or the extent to which any license under such rights
1975	   might or might not be available; nor does it represent that it has
1976	   made any independent effort to identify any such rights.  Information
1977	   on the procedures with respect to rights in RFC documents can be
1978	   found in BCP 78 and BCP 79.

1980	   Copies of IPR disclosures made to the IETF Secretariat and any
1981	   assurances of licenses to be made available, or the result of an
1982	   attempt made to obtain a general license or permission for the use of
1983	   such proprietary rights by implementers or users of this
1984	   specification can be obtained from the IETF on-line IPR repository at
1985	   http://www.ietf.org/ipr.

1987	   The IETF invites any interested party to bring to its attention any
1988	   copyrights, patents or patent applications, or other proprietary
1989	   rights that may cover technology that may be required to implement
1990	   this standard.  Please address the information to the IETF at ietf-
1991	   ipr@ietf.org.

1993	28. Full Copyright Statement

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

1999	   This document and the information contained herein are provided on an
2000	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2001	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2002	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2003	   INCLUNG BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2004	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2005	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2007	29. Acknowledgement

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