idnits 2.17.1 

draft-raggarwa-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 1965.

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

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

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

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


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

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

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

  == Line 1222 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 '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 P2P 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 50, but not defined

  == Missing Reference: 'TBD' is mentioned on line 1045, but not defined

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

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

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

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

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

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

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

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

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

  == Unused Reference: 'RFC2209' is defined on line 1818, 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 (-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: 7 errors (**), 0 flaws (~~), 22 warnings (==), 7 comments (--).

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

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

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

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

8	                draft-raggarwa-mpls-rsvp-te-p2mp-01.txt

10	Status of this Memo

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

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

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

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

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

33	Abstract

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

45	Conventions used in this document

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

51	Authors' Note

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

58	Table of Contents

60	       1      Introduction............................................ 3
61	       2      Terminology............................................. 3
62	       3      Mechanisms.............................................. 4
63	       3.1    P2MP Tunnels............................................ 4
64	       3.2    P2MP LSP Tunnels........................................ 5
65	       3.3    P2P Sub-LSPs............................................ 5
66	       3.3.1  Representation of a P2P sub-LSP......................... 5
67	       3.3.2  P2P Sub-LSPs and Path Messages.......................... 5
68	       3.4    Explicit Route Encoding................................. 6
69	       4      Sub-Groups.............................................. 8
70	       5      Path Message Format..................................... 9
71	       6      Path Message Processing................................. 10
72	       6.1    Multiple Path Messages.................................. 10
73	       6.1.1. Identifying Multiple Path Messages...................... 11
74	       6.2    Multiple P2P Sub-LSPs in One Path Message............... 12
75	       7      RESV Message Format..................................... 13
76	       8      RESV Message Processing................................. 14
77	       8.1    RRO Processing.......................................... 15
78	       8.2    Resv Message Throttling................................. 15
79	       9      Transit Fragmentation................................... 16
80	       10     Grafting................................................ 16
81	       11     Pruning................................................. 17
82	       11.1   P2MP TE LSP Teardown.................................... 18
83	       11.2   Path Tear Message Format................................ 19
84	       12     Refresh Reduction....................................... 19
85	       13     State Management........................................ 19
86	       13.1   Incremental State Update................................ 19
87	       13.2   Combing Multiple Path Messages.......................... 20
88	       14     Error Processing........................................ 21
89	       14.1   Branch Failure Handling................................. 21
90	       15     Notify and ResvConf Messages............................ 22
91	       16     Control of Branch Fate Sharing.......................... 23
92	       17     Admin Status Change..................................... 23
93	       18     Label Allocation on LANs with Multiple Downstream Nodes. 24
94	       19     Make-Before-Break....................................... 24
95	       19.1   P2MP Tree re-optimization............................... 24
96	       19.2   Re-optimization of a subset of P2P sub-LSPs ............ 24
97	       20     Fast Reroute............................................ 25
98	       20.1   Facility Backpup........................................ 25
99	       20.2   One to One Backup....................................... 25
100	       21     Support for LSRs that are not P2MP Capable.............. 26
101	       22     Reduction in Control Plane Processing with LSP Hierarchy 28
102	       23     P2MP LSP Tunnel Remerging and Cross-Over................ 28
103	       23.1   PathErr Message Format.................................. 30
104	       24     New and Updated Message Objects......................... 31
105	       24.1   P2MP SESSION Object..................................... 31
106	       24.2   P2MP LSP Tunnel SENDER_TEMPLATE Object.................. 32
107	       24.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object............. 33
108	       24.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object............. 33
109	       24.3   P2P SUB-LSP Object...................................... 34
110	       24.3.1 P2P IPv4 SUB-LSP Object................................. 34
111	       24.3.2 P2P IPv6 SUB-LSP Object................................. 35
112	       24.4   FILTER_SPEC Object...................................... 35
113	       24.5   SUB EXPLICIT ROUTE Object (SERO)........................ 36
114	       24.6   SUB RECORD ROUTE Object (SRRO).......................... 36
115	       25     IANA Considerations..................................... 37
116	       26     Security Considerations................................. 37
117	       27     Acknowledgements........................................ 37
118	       28     Appendix................................................ 37
119	       28.1   Example................................................. 37
120	       29     References.............................................. 39
121	       30     Authors................................................. 40
122	       31     Intellectual Property................................... 43
123	       32     Full Copyright Statement................................ 43
124	       33     Acknowledgement......................................... 44

126	1. Introduction

128	   [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS
129	   networks. [RFC3473] defines extensions to [RFC3209] for setting up
130	   P2P TE LSPs in GMPLS networks. However these specifications do not
131	   provide a mechanism for building P2MP TE LSPs.

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

137	   This document relies on the semantics of RSVP that RSVP-TE inherits
138	   for building P2MP LSP Tunnels. A P2MP LSP Tunnel is comprised of
139	   multiple P2P sub-LSPs. These P2P sub-LSPs are set up between the
140	   ingress and egress LSRs and are appropriately combined by the branch
141	   LSRs using RSVP semantics to result in a P2MP TE LSP. One Path
142	   message may signal one or multiple P2P sub-LSPs. Hence the P2P sub-
143	   LSPs belonging to a P2MP LSP Tunnel can be signaled using one Path
144	   message or split across multiple Path messages.

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

149	2. Terminology

151	   This document uses terminologies defined in [RFC3031], [RFC2205],
152	   [RFC3209], [RFC3473] and [P2MP-REQ]. In addition the following terms
153	   are used in this document.

155	   P2P sub-LSP: A P2MP TE LSP is constituted of one or more P2P sub-
156	   LSPs. A P2P sub-LSP refers to the portion of the label switched path
157	   from the ingress LSR to a particular egress LSR. The egress LSR is
158	   the destination of the P2P sub-LSP.

160	3. Mechanism

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

168	   The P2MP TE LSP is set up by associating multiple P2P TE sub-LSPs and
169	   relying on data replication at branch nodes. This is described
170	   further in the following sub-sections by describing P2MP tunnels and
171	   how they relate to P2P sub-LSPs.

173	3.1. P2MP Tunnels

175	   The specific aspect related to P2MP TE LSP is the action required at
176	   a branch node, where data replication occurs. For instance, in the
177	   MPLS case, incoming labeled data is appropriately replicated to
178	   several outgoing interfaces with different labels.

180	   A P2MP TE tunnel comprises of one or more P2MP LSPs referred to as
181	   P2MP LSP tunnels. A P2MP TE Tunnel is identified by a P2MP SESSION
182	   object. This object contains the P2MP ID defined as a destination
183	   identifier, a tunnel ID and an extended tunnel ID.

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

189	   This identifier encodes the P2MP ID and identifies the set of
190	   destination(s) of the P2MP LSP Tunnel.

192	3.2. P2MP LSP Tunnel

194	   A P2MP TE tunnel comprises of one or more P2MP LSPs referred to as
195	   P2MP LSP Tunnels. A P2MP LSP Tunnel is identified by the combination
196	   of the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of
197	   the P2MP SESSION object, and the IPv4 or IPv6 tunnel sender address
198	   and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP
199	   SENDER_TEMPLATE object is defined in section 24.2

201	3.3. P2P Sub-LSPs

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

205	3.3.1. Representation of a P2P Sub-LSP

207	   A P2P sub-LSP exists within the context of a P2MP LSP Tunnel. Thus it
208	   is identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that
209	   are part of the P2MP SESSION, the IPv4 or IPv6 tunnel sender address
210	   and LSP ID fields of the P2MP SENDER_TEMPLATE object, and the P2P
211	   sub-LSP destination address that is part of the P2P_SUB_LSP object.
212	   The P2P_SUB_LSP object is defined in section 24.3.

214	   Additionally, a sub-LSP ID contained in the P2P_SUB_LSP object may be
215	   used depending on further discussions about the make-before-break
216	   procedures described in section 19.

218	   An EXPLICIT_ROUTE Object (ERO) or SUB_EXPLICIT_ROUTE Object (SERO) is
219	   used to optionally specify the explicit route of a P2P sub-LSP. Each
220	   ERO or a SERO that is signaled corresponds to a particular
221	   P2P_SUB_LSP object. Details of explicit route encoding are specified
222	   in section 3.4.

224	3.3.2. P2P Sub-LSPs and Path Messages

226	   The mechanism in this document allows a P2MP LSP Tunnel to be
227	   signaled using one or more Path messages. Each Path message may
228	   signal one or more P2P sub-LSPs. Multiple Path messages are desirable
229	   as one Path message may not be large enough to fit all the P2P sub-
230	   LSPs; and they also allow separate manipulation of sub-trees of the
231	   P2MP LSP Tunnel. The reason for allowing a single Path message, to
232	   signal multiple P2P sub-LSPs, is to optimize the number of control
233	   messages needed to setup a P2MP LSP Tunnel.

235	3.4. Explicit Route Encoding

237	   When a Path message signals a single P2P sub-LSP (that is, the Path
238	   message is only targeting a single leaf in the P2MP tree), the
239	   EXPLICIT_ROUTE object encodes the path from the ingress LSR to the
240	   egress LSR. The Path message also includes the P2P_SUB_LSP object for
241	   the P2P sub-LSP being signaled. The < [<EXPLICIT_ROUTE>],
242	   <P2P_SUB_LSP> > tuple represents the P2P sub-LSP. The absence of the
243	   ERO should be interpreted as requiring hop-by-hop routing for the
244	   sub-LSP based on the P2P sub-LSP destination address field of the
245	   P2P_SUB_LSP object.

247	   The absence of the ERO should be interpreted as requiring hop-by-hop
248	   routing for the sub-LSP based on the P2P sub-LSP destination address
249	   field of the P2P_SUB_LSP object.

251	   When a Path message signals multiple P2P sub-LSPs the path of the
252	   first P2P sub-LSP, from the ingress LSR to the egress LSR, is encoded
253	   in the ERO. The first P2P sub-LSP is the one that corresponds to the
254	   first P2P_SUB_LSP object in the Path message. The P2P sub-LSPs
255	   corresponding to the P2P_SUB_LSP objects that follow are termed as
256	   subsequent P2P sub-LSPs. The path of each subsequent P2P sub-LSP is
257	   encoded in a SUB_EXPLICIT_ROUTE object (SERO). The format of the SERO
258	   is the same as an ERO (as defined in [RFC3209]).  Each subsequent P2P
259	   sub-LSP is represented by tuples of the form [<SUB_EXPLICIT_ROUTE>]
260	   <P2P_SUB_LSP>. There is a one to one correspondence between a
261	   P2P_SUB_LSP object and a SERO. The absence of a SERO should be
262	   interpreted as requiring hop-by-hop routing for that sub-LSP. Note
263	   that the destination address is carried in the P2P sub-LSP object.
264	   The encoding of the SERO and P2P sub-LSP object are described in
265	   detail in section 24.

267	   The motivation behind the use of the SERO object is to provide
268	   explicit route compression when a Path message signals simultaneously
269	   multiple P2P sub-LSPs. One approach to encode the explicit route of a
270	   subsequent P2P sub-LSP is to include the path from the ingress to the
271	   egress of the P2P sub-LSP. However this implies potential repetition
272	   of hops that can be learned from the ERO or explicit routes of other
273	   P2P sub-LSPs. Explicit route compression using SEROs attempts to
274	   minimize such repetition. A SERO for a particular P2P sub-LSP
275	   includes only the path from a certain branch LSR to the egress LSR if
276	   the path to that branch LSR can be derived from the ERO or other
277	   SEROs.

279	   Explicit route compression is illustrated using the following figure.

281	                                    A
282	                                    |
283	                                    |
284	                                    B
285	                                    |
286	                                    |
287	                          C----D----E
288	                          |    |    |
289	                          |    |    |
290	                          F    G    H-------I
291	                               |    |      |
292	                               |    |      |
293	                               J    K   L   M
294	                               |    |   |   |
295	                               |    |   |   |
296	                               N    O   P   Q--R

298	                        Figure 1. Explicit Route Compression

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

307	      P2P sub-LSP-F:   ERO = {B, E, D, C, F},  P2P_SUB_LSP Object-F
308	      P2P sub-LSP-N:   SERO = {D, G, J, N}, P2P_SUB_LSP Object-N
309	      P2P sub-LSP-O:   SERO = {E, H, K, O}, P2P_SUB_LSP Object-O
310	      P2P sub-LSP-P:   SERO = {H, L, P}, P2P_SUB_LSP Object-P,
311	      P2P sub-LSP-Q:   SERO = {H, I, M, Q}, P2P_SUB_LSP Object-Q,
312	      P2P sub-LSP-R:   SERO = {Q, R}, P2P_SUB_LSP Object-R,

314	   After LSR E processes the incoming Path message from LSR B it sends a
315	   Path message to LSR D with the P2P sub-LSP explicit routes encoded as
316	   follows:

318	      P2P sub-LSP-F:   ERO = {D, C, F},  P2P_SUB_LSP Object-F
319	      P2P sub-LSP-N:   SERO = {D, G, J, N}, P2P_SUB_LSP Object-N

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

324	      P2P sub-LSP-O:   ERO = {H, K, O}, P2P_SUB_LSP Object-O
325	      P2P sub-LSP-P:   SERO = {H, L, P}, P2P_SUB_LSP Object-P,
326	      P2P sub-LSP-Q:   SERO = {H, I, M, Q}, P2P_SUB_LSP Object-Q,
327	      P2P sub-LSP-R:   SERO = {Q, R}, P2P_SUB_LSP Object-R,

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

333	      P2P sub-LSP-O:   ERO  = {K, O}, P2P_SUB_LSP Object-O

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

338	      P2P sub-LSP-P:   ERO = {L, P}, P2P_SUB_LSP Object-P,

340	   Following is one way for LSR H to encode the P2P sub-LSP explicit
341	   routes in the Path message sent to LSR I:

343	      P2P sub-LSP-Q:   ERO = {I, M, Q}, P2P_SUB_LSP Object-Q,
344	      P2P sub-LSP-R:   SERO = {Q, R}, P2P_SUB_LSP Object-R,

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

349	   This compression mechanism reduces the Path message size. It also
350	   reduces extra processing that can result if explicit routes are
351	   encoded from ingress to egress for each P2P sub-LSP. No assumptions
352	   are placed on the ordering of the subsequent P2P sub-LSPs and hence
353	   on the ordering of the SEROs in the Path message. All LSRs need to
354	   process the ERO corresponding to the first P2P sub-LSP. A LSR needs
355	   to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only
356	   if the first hop in the corresponding SERO is a local address of that
357	   LSR. The branch LSR that is the first hop of a SERO propagates the
358	   corresponding P2P sub-LSP downstream.

360	4. Sub-Groups

362	   As with all other RSVP controlled LSP Tunnels, P2MP LSP Tunnel state
363	   is managed using RSVP messages. While use of RSVP messages is the
364	   same, P2MP LSP Tunnel state differs from P2P LSP state in a number of
365	   ways.  The two most notable differences are that a P2MP LSP Tunnel is
366	   targeted at multiple P2P Sub-LSPs and that, as a result of this, it
367	   may not be possible to represent full state in a single IP datagram
368	   and even more likely that it can't fit into a single IP packet. It
369	   must also be possible to efficiently add and remove endpoints to and
370	   from P2MP TE LSPs. An additional issue is that P2MP LSP Tunnels must
371	   also handle the state "remerge" problem, see [P2MP-REQ].

373	   These differences in P2MP state are addressed through the addition of
374	   a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-
375	   Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects.
376	   Taken together the Sub-Group ID and Sub-Group Originator ID are
377	   referred to as the Sub-Group fields.

379	   The Sub-Group fields, together with rest of the SENDER_TEMPLATE and
380	   SESSION objects, are used to represent a portion of a P2MP LSP
381	   Tunnel's state. The portion of P2MP LSP Tunnel state identified by
382	   specific subgroup field values is referred to as a signaling sub-
383	   tree. It is important to note that the term "signaling sub-tree"
384	   refers only to signaling state and not data plane replication or
385	   branching. For example, it is possible for a node to "branch"
386	   signaling state for a P2MP LSP Tunnel, but to not branch the data
387	   associated with the P2MP LSP Tunnel.  Typical applications for
388	   generation and use of multiple subgroups are adding an egress and
389	   semantic fragmentation to ensure that a Path message remains within a
390	   single IP packet.

392	5. Path Message Format

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

399	   <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
400	                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
401	                          [ <MESSAGE_ID> ]
402	                          <SESSION> <RSVP_HOP>
403	                          <TIME_VALUES>
404	                          [ <EXPLICIT_ROUTE> ]
405	                          <LABEL_REQUEST>
406	                          [ <PROTECTION> ]

408	                          [ <LABEL_SET> ... ]
409	                          [ <SESSION_ATTRIBUTE> ]
410	                          [ <NOTIFY_REQUEST> ]
411	                          [ <ADMIN_STATUS> ]
412	                          [ <POLICY_DATA> ... ]
413	                          <sender descriptor>
414	                          [P2P sub-LSP descriptor list]

416	   Following is the format of the P2P sub-LSP descriptor list.

418	   <P2P sub-LSP descriptor list> ::= <P2P sub-LSP descriptor>
419	                                     [ <P2P sub-LSP descriptor list> ]

421	   <P2P sub-LSP descriptor> ::= <P2P_SUB_LSP> [ <SUB_EXPLICIT_ROUTE> ]

423	   Each LSR MUST use the common objects in the Path message and the P2P
424	   sub-LSP descriptors to process each P2P sub-LSP represented by the
425	   P2P sub-LSP object and the SUB-/EXPLICIT_ROUTE object combination.

427	   The first P2P_SUB_LSP object's explicit route is specified by the
428	   ERO. Explicit routes of subsequent P2P sub-LSPs are specified by the
429	   corresponding SERO. A SERO corresponds to the following P2P_SUB_LSP
430	   object.

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

436	   Path message processing is described in the next section.

438	6. Path Message Processing

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

452	   As mentioned earlier, it is possible to signal P2P sub-LSPs for a
453	   given P2MP LSP Tunnel in one or more Path messages. And a given Path
454	   message can contain one or more P2P sub-LSPs."

456	6.1. Multiple Path messages

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

466	   Processing of Path messages containing more than one P2P sub-LSP is
467	   described in Section 6.2.

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

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

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

497	6.1.1. Identifying Multiple Path Messages

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

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

523	6.2. Multiple P2P Sub-LSPs in one Path message

525	   The P2P sub-LSP descriptor list allows the signaling of one or more
526	   P2P sub-LSPs.

528	   in one Path message. It is possible to signal multiple P2P sub-LSP
529	   object and ERO/SERO combinations in a single Path message. Note that
530	   these two objects are the ones that differentiate a P2P sub-LSP. Each
531	   LSR can use the common objects in the Path message and the P2P sub-
532	   LSP descriptors to process each P2P sub-LSP.

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

555	   Note that if one or more SEROs contains loose hops, expansion of such
556	   loose hops may result in overflowing the Path message size. Section 9
557	   describes how signaling of the set of P2P sub-LSPs can be split in
558	   more than one Path message.

560	   The Record Route Object (RRO) contains the hops traversed by the Path
561	   message and applies to all the P2P sub-LSPs signaled in the path
562	   message. A transit LSR appends its address in an incoming RRO and
563	   propagates it downstream. A branch LSR forms a new RRO for each of
564	   the outgoing Path messages. Each such updated RRO is formed by
565	   appending the branch LSR's address to the incoming RRO.

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

577	7. Resv Message Format

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

581	   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
582	                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
583	                         [ <MESSAGE_ID> ]
584	                         <SESSION> <RSVP_HOP>
585	                         <TIME_VALUES>
586	                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
587	                         [ <NOTIFY_REQUEST> ]
588	                         [ <ADMIN_STATUS> ]
589	                         [ <POLICY_DATA> ... ]
590	                         <STYLE> <flow descriptor list>

592	   <flow descriptor list> ::= <FF flow descriptor list>
593	                              | <SE flow descriptor>

595	   <FF flow descriptor list> ::= <FF flow descriptor>
596	                                 | <FF flow descriptor list>
597	                                 <FF flow descriptor>

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

601	   <SE filter spec list> ::= <SE filter spec>
602	                            | <SE filter spec list> <SE filter spec>

604	   The FF flow descriptor and SE filter spec are modified as follows to
605	   identify the P2P sub-LSPs that they correspond to:

607	   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
608	                            [ <RECORD_ROUTE> ] [ <P2P sub-LSP descriptor
609	   list> ]

611	   <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
612	                            [ <P2P sub-LSP descriptor list> ]

614	   FILTER_SPEC is defined in section 24.4.

616	   The P2P sub-LSP descriptor has the same format as in section 5.1 with
617	   the difference that a SUB_RECORD_ROUTE object is used in place of a
618	   SUB_EXPLICIT_ROUTE object. The SUB_RECORD_ROUTE objects follow the
619	   same compression mechanism as the SUB_EXPLICIT_ROUTE objects. Note
620	   that that a Resv message can signal multiple P2P sub-LSPs that may
621	   belong to the same FILTER_SPEC object or different FILTER_SPEC
622	   objects. The same label is allocated if the FILTER_SPEC object is the
623	   same.

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

629	8. Resv Message Processing

631	   The egress LSR follows normal RSVP procedures while originating a
632	   Resv message. The Resv message carries the label allocated by the
633	   egress LSR.

635	   A subsequent node allocates its own label and passes it in the Resv
636	   message upstream. The node may combine multiple flow descriptors,
637	   from different Resv messages received from downstream, in one Resv
638	   message sent upstream. A Resv message is not sent upstream until at
639	   least one Resv message has been received from a downstream neighbor
640	   except when the integrity bit is set in the LSP_ATTRIBUTE object.

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

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

653	   The ingress LSR may need to understand when all desired egresses have
654	   been reached. This is achieved using <P2P_SUB_LSP> objects.

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

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

669	   The solution for this issue is for further discussion.

671	8.1. RRO Processing

673	   A Resv message contains a record route per P2P sub-LSP that is being
674	   signaled by the Resv message if the sender node requests route
675	   recording by including a RRO in the Path message. The same rule is
676	   used during signaling of P2MP LSP Tunnels i.e. insertion of the RRO
677	   in the Path message used to signal one or more P2P sub-LSP triggers
678	   the inclusion of an RRO for each sub-LSP.

680	   The record route of the first P2P sub-LSP is encoded in the RRO.
681	   Additional RROs for the subsequent P2P sub-LSPs are referred to as
682	   SUB_RECORD_ROUTE objects (SRROs). Their format is specified in
683	   section 24.5. The ingress node then receives the RRO and  possibly
684	   the SRRO  corresponding to each subsequent P2P sub-LSP. Each
685	   P2P_SUB_LSP object is followed by the RRO/SRRO. The ingress node can
686	   then determine the record route corresponding to a particular P2P
687	   sub-LSP. The RRO and SRROs can be used to construct the end to end
688	   Path for each P2P sub-LSP.

690	8.2. Resv Message Throttling

692	   A branch node may have to send the Resv message being sent upstream
693	   whenever there is a change in a Resv message for a P2P sub-LSP
694	   received from downstream. This can result in excessive Resv messages
695	   sent upstream, particularly when the P2P sub-LSPs are established for
696	   the first time.  In order to mitigate this situation, branch nodes
697	   can limit their transmission of Resv messages. Specifically, in the
698	   case where the only change being sent in a Resv message is in one or
699	   more SRRO objects, the branch node SHOULD transmit the Resv message
700	   only after a delay time has passed since the transmission of the
701	   previous Resv message for the same session. This delayed Resv message
702	   SHOULD include SRROs for all branches. Specific mechanisms for Resv
703	   message throttling are implementation dependent and are outside the
704	   scope of this document.

706	9. Transit Fragmentation

708	   In certain cases a transit LSR may need to generate multiple Path
709	   messages to signal state corresponding to a single received Path
710	   message. For instance ERO expansion may result in an overflow of the
711	   resultant Path message. It is desirable not to rely on IP
712	   fragmentation in this case. In order to achieve this, the multiple
713	   Path messages generated by the transit LSR, are signaled with the
714	   Sub-Group Originator ID set to the TE Router ID of the transit LSR
715	   and a distinct sub-Group ID. Thus each distinct Path message that is
716	   generated by the transit LSR for the P2MP LSP Tunnel carries a
717	   distinct <Sub-Group Originator ID, Sub-Group ID> tuple.

719	   When multiple Path messages are used by an ingress or transit node,
720	   each Path message SHOULD be identical with the exception of the P2P
721	   sub-LSP related information (e.g., SERO), message and hop information
722	   (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the SENDER_TEMPLATE
723	   objects. Except when performing a  make-before-break operation, the
724	   tunnel sender address and LSP ID fields MUST be the same in each
725	   message, and for transit nodes, the same as the values in the Path
726	   message.

728	   As described above one case in which the Sub-Group Originator ID of a
729	   received Path message is changed is that of transit fragmentation.
730	   The Sub-Group Originator ID of a received Path message may also be
731	   changed in the outgoing Path message and set to that of the LSR
732	   originating the Path message based on a local policy. For instance a
733	   LSR may decide to always change the Sub-Group Originator ID while
734	   performing ERO expansion. The Sub-Group ID MUST not be changed if the
735	   Sub-Group Originator ID is not being changed.

737	10. Grafting

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

743	   There are two methods to add P2P sub-LSPs to a P2MP LSP Tunnel.  The
744	   first is to add new P2P sub-LSPs to the P2MP LSP Tunnel by adding
745	   them to an existing Path message and refreshing the entire Path
746	   message. Path message processing described in section 6 results in
747	   adding these P2P sub-LSPs to the P2MP LSP Tunnel. Note that as a
748	   result of adding one or more P2P sub-LSPs to a Path message the ERO
749	   compression encoding may have to be recomputed.

751	   The second is to use incremental updates described in section 13.1.
752	   The egress LSRs can be added/removed by signaling only the impacted
753	   P2P sub-LSPs in a new Path message. Hence other P2P sub-LSPs do not
754	   have to be re-signaled.

756	11. Pruning

758	   The operation of removing egress LSR(s) from an existing P2MP LSP
759	   Tunnel is termed as pruning. This operation allows egress nodes to
760	   leave  a P2MP LSP Tunnel at different points in time.

762	   The P2P sub-LSP(s) being removed from the P2MP LSP Tunnel are
763	   signaled in a PathTear message. The PathTear message includes the P2P
764	   sub-LSP descriptor list which is included before the sender
765	   descriptor. Note that the PathTear message contains only the P2P sub-
766	   LSP(s) being removed and rest of the P2MP LSP Tunnel does not have to
767	   be re-signaled. This results in removal of the state corresponding to
768	   these P2P sub-LSPs. State for rest of the P2P sub-LSPs is not
769	   modified.

771	   This section describes various mechanisms to perform pruning. Further
772	   discussion and feedback is needed to finesse these mechanisms. In the
773	   first mechanism in order to delete one or more P2P Sub-LSPs, a
774	   PathTear message is sent with the list of P2P sub-LSPs being deleted.
775	   This is a form of explicit tear down. A single PathTear message can
776	   only contain P2P sub-LSPs that were signaled by the ingress using the
777	   same <Sub-Group Originator ID, Sub-Group ID> tuple. The PathTear
778	   message is signaled with the SESSION and SENDER_TEMPLATE objects
779	   corresponding to the P2MP LSP Tunnel and the <Sub-Group Originator
780	   ID, Sub-Group ID> tuple corresponding to the P2P sub-LSPs that are
781	   being deleted. A transit LSR that propagates the PathTear message
782	   downstream MUST ensure that it sets the <Sub-Group Originator ID,
783	   Sub-Group ID> tuple in the PathTear message to the values used to
784	   generate the last Path message that corresponds to the P2P sub-LSPs
785	   signaled in the PathTear message that it generates. The transit LSR
786	   may need to generate multiple PathTear messages for an incoming
787	   PathTear message if it had performed transit fragmentation for the
788	   corresponding incoming Path message.

790	   The Path messages from which the P2P sub-LSPs were deleted need to be
791	   refreshed with the remaining P2P sub-LSPs. Note that as a result of
792	   deleting one or more P2P sub-LSPs from a Path message the ERO
793	   compression encoding may have to be recomputed.

795	   When the last P2P sub-LSP is to be removed from a Path state, i.e.,
796	   there are no remaining P2P sub-LSPs to send in a Path message, a
797	   PathTear message SHOULD be sent carrying the Sub-Group ID of the Path
798	   message that no longer has any P2P sub-LSPs.

800	   The second mechanism to delete P2P sub-LSPs is implicit teardown
801	   which uses standard RSVP message processing. Per standard RSVP
802	   processing, a P2P sub-LSP may be removed from a P2MP TE LSP by
803	   sending a modified message for the Path or Resv message that
804	   previously advertised the P2P sub-LSP.  This message MUST list all
805	   P2P sub-LSPs that are not being removed. When using this approach, a
806	   node processing a message that removes a P2P sub-LSP from a P2MP TE
807	   LSP MUST ensure that the P2P sub-LSP is not included in any other
808	   Path state associated with session before interrupting the data path
809	   to that egress.  All other message processing remains unchanged.

811	   The third mechanism is an explicit teardown mechanism that defines
812	   new syntax and semantics for a PathTear message. This new mechanism
813	   minimizes signaling required to remove a subset of P2P sub-LSPs set
814	   signaled in a Path message, and thereby reduces associated
815	   processing.  When using this mechanism each identified P2P sub-LSP is
816	   removed from the P2MP LSP Tunnel state, even if the P2P sub-LSP is
817	   advertised in multiple Path message.

819	   When using this approach, a PathTear message is generated. The
820	   PathTear message MUST identify each P2P sub-LSP to be removed, via a
821	   P2P_SUB_LSP object per P2P Sub-LSP, and include a SENDER_TEMPLATE
822	   object corresponding to the Path state being modified. The Sub-Group
823	   ID valued contained in the SENDER_TEMPLATE object message MUST be set
824	   to zero (0). Subsequent Path messages associated with the P2MP LSP
825	   Tunnel MUST NOT contain the removed P2P sub-LSPs, unless that P2P
826	   sub-LSP is being re-added to the P2MP LSP.

828	   To support the third mechanism, the receiver of PathTear message that
829	   is associated with a P2MP LSP Tunnel MUST check the value of a
830	   received Sub-Group ID fields.  When there is no SENDER_TEMPLATE
831	   object present or the value of the Sub-Group ID fields is non-zero,
832	   then PathTear processing as defined in the above explicit tear down
833	   mechanism must be followed.  When the Sub-Group ID field is zero (0),
834	   then the processing node MUST remove the identified egresses from all
835	   control plane state associated with the P2MP LSP Tunnel and adjust
836	   the data path appropriately.

838	11.1. P2MP TE LSP Tear Down

840	   This operation is accomplished by listing all the P2P sub-LSPs in a
841	   PathTear message.

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

846	11.2. PathTear message Format

848	   The format of the PathTear message is as follows:

850	   <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
851	                           [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ...
852	   ]
853	                           [ <MESSAGE_ID> ]
854	                           <SESSION> <RSVP_HOP>
855	                           [ <sender descriptor> ]
856	                           [ <P2P sub-LSP descriptor list> ]

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

860	   Note: it is assumed that the P2P sub-LSP descriptor will not include
861	   the SUB_EXPLICIT_ROUTE object associated with each P2P_SUB_LSP being
862	   deleted

864	12. Refresh Reduction

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

872	13. State Management

874	   State signaled by a P2MP Path message is managed by a local
875	   implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as
876	   part of the SESSION object and <Tunnel Sender Address, LSP ID, Sub-
877	   Group Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE
878	   object.

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

884	13.1. Incremental State Update

886	   RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
887	   GMPLS [RFC3473] uses the same basic approach to state communication
888	   and synchronization, namely full state is sent in each state
889	   advertisement message. Per [RFC2205] Path and Resv messages are
890	   idempotent. Also, [RFC2961] categorizes RSVP messages into two types:
891	   trigger and refresh messages and improves RSVP message handling and
892	   scaling of state refreshes but does not modify the full state
893	   advertisement nature of Path and Resv messages. The full state
894	   advertisement nature of Path and Resv messages has many benefits, but
895	   also has some drawbacks. One notable drawback is when an incremental
896	   modification is being made to a previously advertised state. In this
897	   case, there is the message overhead of sending the full state and the
898	   cost of processing it. It is desirable to overcome this drawback and
899	   add/delete P2P sub-LSPs to a P2MP LSP Tunnel by incrementally
900	   updating the existing state.

902	   It is possible to use the procedures described in this document to
903	   allow P2P sub-LSPs to be incrementally added or deleted from the P2MP
904	   LSP by allowing a Path or a PathTear message to incrementally change
905	   the existing P2MP LSP Tunnel Path state.

907	   As described in section 6.1, multiple Path messages can be used to
908	   signal a P2MP LSP Tunnel. The Path messages are distinguished by
909	   different <Sub-Group Originator ID, sub-Group ID> tuples in the
910	   SENDER_TEMPLATE object.  In order to perform incremental P2P sub-LSP
911	   state addition a separate Path message with a new sub-Group ID is
912	   used to add the new P2P sub-LSPs, by the ingress LSR. The Sub-Group
913	   Originator ID MUST be set to the TE Router ID [RFC3477] of the node
914	   that sets the Sub-Group ID.

916	   This maintains the idempotent nature of RSVP Path messages; avoids
917	   keeping track of individual P2P sub-LSP state expiration and provides
918	   the ability to perform incremental P2MP LSP Tunnel state updates.

920	13.2. Combining Multiple Path Messages

922	   There is a tradeoff between the number of Path messages used by the
923	   ingress to maintain the P2MP LSP Tunnel and using full state refresh
924	   to add P2P sub- LSPs. It is possible to combine P2P sub-LSPs
925	   previously advertised in different Path messages in a single Path
926	   message in order to reduce the number of Path messages needed to
927	   maintain the P2MP LSP. This can also be done by a transit node that
928	   performed fragmentation and at a later point is able to combine
929	   multiple Path messages that it generated into a single Path message.
930	   This may happen when one or more P2P sub-LSPs are pruned from the
931	   existing Path states.

933	   The new Path message is signaled by the node that is combining
934	   multiple Path messages with all the P2P sub-LSPs that are being
935	   combined in a single Path message. This Path message contains a new
936	   Sub-Group ID field value. When a new Path and Resv message that is
937	   signaled for an existing P2P sub-LSP is received by a transit LSR,
938	   state including the new instance of the P2P sub-LSP is created.

940	   The P2P sub-LSP SHOULD continue to be advertised in both the old and
941	   new Path messages until a Resv message listing the P2P sub-LSP and
942	   corresponding to the new Path message is received by the combining
943	   node. Hence until this point state for the P2P sub-LSP SHOULD be
944	   maintained as part of the Path state for both the old and the new
945	   Path message [Section 3.1.3, 2205]. At that point the P2P sub-LSP
946	   SHOULD be deleted from the old Path state using a PathTear message.
947	   The P2P sub-LSP should also be removed from the old Path message and
948	   the old Path message should be signaled again, if there are other
949	   remaining P2P sub-LSPs in the old Path message.

951	   A Path message with a sub-Group_ID(n+1) may signal a set of P2P sub-
952	   LSPs that belong partially or entirely to an already existing Sub-
953	   Group_ID(i), i <= n, the SESSION object and <Sender Tunnel Address,
954	   LSP-ID, Sub-Group Originator ID> being the same. Or it may signal a
955	   strictly non-overlapping new set of P2P sub-LSPs with a strictly
956	   higher sub-Group_ID value.

958	   1) If sub-Group_ID(i) = sub-Group_ID(n+1), i =< n then either a full
959	   refresh is indicated by the Path message or a P2P Sub-LSP is added
960	   to/deleted from the group signaled by sub-Group_ID(n+1)

962	   2) If sub-Group_ID(i) != sub-Group_ID(n+1), i =< n then the Path
963	   message is signaling a set of P2P sub-LSPs that belong partially or
964	   entirely to an already existing Sub-Group_ID(i) or a strictly non-
965	   overlapping set of P2P sub-LSPs.

967	14. Error Processing

969	   PathErr and ResvErr messages are processed as per RSVP-TE procedures.
970	   Note that a LSR on receiving a PathErr/ResvErr message for a
971	   particular P2P sub-LSP changes the state only for that P2P sub-LSP.
972	   Hence other P2P sub-LSPs are not impacted. In case the ingress node
973	   requests the maintenance of the 'LSP integrity', any error reported
974	   within the P2MP TE LSP must be reported at (least at) any other
975	   branching nodes belonging to this LSP. Therefore, reception of an
976	   error message for a particular P2P sub-LSP MAY change the state of
977	   any other P2P sub- LSP of the same P2MP TE LSP.

979	14.1. Branch Failure Handling

981	   During setup and during normal operation, PathErr messages may be
982	   received at a branch node. In all cases, a received PathErr message
983	   is first processed per standard processing rules. That is: the
984	   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
985	   Path message.  Intermediate nodes until this ingress/branch LSR MAY
986	   inspect this message but take no action upon it. The behavior of a
987	   branch LSR that generates a PathErr message is under the control of
988	   the ingress LSR.

990	   The default behavior is that the PathErr does not have the
991	   Path_State_Removed flag set. However, if the ingress LSR has set the
992	   'LSP integrity' flag on the Path message (see LSP_ATTRIBUTE object in
993	   section 24) and if the Path_State_Removed flag is supported, the LSR
994	   generating a PathErr to report the failure of a branch of the P2MP
995	   LSP Tunnel SHOULD set the Path_State_Removed flag.

997	   A branch LSR that receives a PathErr message with the
998	   Path_State_Removed flag set MUST act according to the wishes of the
999	   ingress LSR. The default behavior is that the branch LSR clears the
1000	   Path_State_Removed flag on the PathErr and sends it further upstream.
1001	   It does not tear any other branches of the LSP. However, if the LSP
1002	   integrity flag is set on the Path message, the branch LSR MUST send
1003	   PathTear on all downstream branches and send the PathErr message
1004	   upstream with the Path_State_Removed flag set.

1006	   A branch LSR that receives a PathErr message with the
1007	   Path_State_Removed flag clear MUST act according to the wishes of the
1008	   ingress LSR. The default behavior is that the branch LSR forwards the
1009	   PathErr upstream and takes no further action. However, if the LSP
1010	   integrity flag is set on the Path message, the branch LSR MUST send
1011	   PathTear on all downstream branches and send the PathErr upstream
1012	   with the Path_State_Removed flag set (per [RFC3473]).

1014	   In all cases, the PathErr message forwarded by a branch LSR MUST
1015	   contain the P2P sub-LSP identification and explicit routes of all
1016	   branches that are errored (reported by received PathErr messages) and
1017	   all branches that are explicitly torn by the branch LSR.

1019	15. Notify and ResvConf Messages

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

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

1036	16. Control of Branch Fate Sharing

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

1045	   The ingress LSP may request 'LSP integrity' by setting bit [TBD] of
1046	   the Attributes Flags TLV. The bit is set if LSP integrity is
1047	   required.

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

1052	   A branch LSR that supports the Attributes Flags TLV and recognizes
1053	   this bit MUST support LSP integrity or reject the LSP setup with a
1054	   PathErr carrying the error "Routing Error"/"Unsupported LSP
1055	   Integrity"

1057	17. Admin Status Change

1059	   A branch node that receives an ADMIN_STATUS object processes it
1060	   normally and also relays the ADMIN_STATUS object in a Path on every
1061	   branch. All Path messages may be concurrently sent to the downstream
1062	   neighbors.

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

1071	18. Label Allocation on LANs with Multiple Downstream Nodes

1073	   A sender on a LAN uses a different label for sending traffic to each
1074	   node on the LAN that belongs to the P2MP LSP Tunnel. Thus the sender
1075	   performs replication. It may be considered desirable on a LAN to use
1076	   the same label for sending traffic to multiple nodes belonging to the
1077	   same P2MP LSP Tunnel, to avoid replication. Procedures for doing this
1078	   are for further study. Given the relatively small number of receivers
1079	   on LANs typically deployed in MPLS networks, this is not currently
1080	   seen as a practical problem. Furthermore avoiding replication at the
1081	   sender on a LAN requires significant complexity in the control plane.
1082	   Given the tradeoff we propose the use of replication by the sender on
1083	   a LAN.

1085	19. Make-before-break

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

1089	19.1. P2MP Tree Re-optimization

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

1098	19.2. Re-optimization of a subset of P2P sub-LSPs.

1100	   One way to accomplish re-optimization of a subset of P2P sub-LSPs
1101	   that belong to a P2MP LSP Tunnel is to resignal the entire tree with
1102	   a new LSP-ID as described in the previous subsection.

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

1107	   It is possible to accomplish re-optimization of one or more P2P sub-
1108	   LSPs without re-signaling rest of the P2MP LSP. To achieve this a
1109	   sub-LSP ID is used to identify each P2P sub-LSP. This is encoded in
1110	   the P2P sub-LSP object. Each re-optimized P2P sub-LSP is signaled
1111	   with a different sub-LSP ID and hence a new P2P sub-LSP is
1112	   established. Once the new setup is complete, the old P2P sub-LSP can
1113	   be torn down. In some cases this may result in transient data
1114	   duplication.

1116	20. Fast Reroute

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

1121	20.1. Facility Backup

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

1126	   If link protection is desired, a bypass tunnel is used to protect the
1127	   link between the PLR and next-hop. Thus all P2P sub-LSPs that use the
1128	   link can be protected in the event of link failure. Note that all
1129	   such P2P sub-LSPs belonging to a particular instance of a P2MP tunnel
1130	   will share the same outgoing label on the link between the PLR and
1131	   the next-hop. This is the P2MP LSP label on the link. Label stacking
1132	   is used to send data for each P2MP LSP in the bypass tunnel. The
1133	   inner label is the P2MP LSP Tunnel label allocated by the nhop.
1134	   During failure Path messages for each P2P sub-LSP, that is effected,
1135	   will be sent to the MP, by the PLR. It is recommended that the PLR
1136	   use the sender template specific method to identify these Path
1137	   messages. Hence the PLR will set the source address in the sender
1138	   template to a local PLR address. The MP will use the LSP-ID to
1139	   identify the corresponding P2P sub-LSPs.

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

1144	   In order to further process a P2P sub-LSP it will determine the
1145	   protected P2P sub-LSP using the LSP-id and the P2P sub-LSP object.

1147	   If node protection is desired, the bypass tunnel must intersect the
1148	   path of the protected P2P sub-LSPs somewhere downstream of the PLR.
1149	   This constrains the set of P2P sub-LSPs being backed-up via that
1150	   bypass tunnel to those that pass through a common downstream MP. The
1151	   MP will allocate the same label to all such P2P sub-LSPs belonging to
1152	   a particular instance of a P2MP tunnel. This will be the inner label
1153	   used during label stacking. This may require the PLR to be branch
1154	   capable as multiple bypass tunnels may be required to backup the set
1155	   of P2P sub-LSPs passing through the protected node. Else all the P2P
1156	   sub-LSPs being backed up must pass through the same MP.

1158	20.2. One to One Backup

1160	   One to one backup as described in [RSVP-FR] can be used to protect a
1161	   particular P2P sub-LSP against link and next-hop failure. Protection
1162	   may be used for one or more P2P sub-LSPs between the PLR and the
1163	   next-hop. All the P2P sub-LSPs corresponding to the same instance of
1164	   the P2MP tunnel, between the PLR and the next-hop share the same P2MP
1165	   LSP Tunnel label.

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

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

1175	   Its is recommended that the path specific method be used to identify
1176	   a backup P2P sub-LSP. Hence the DETOUR object will be inserted in the
1177	   backup Path message. A backup P2P sub-LSP MUST be treated as
1178	   belonging to a different P2MP tunnel instance than the one specified
1179	   by the LSP-id. Furthermore multiple backup P2P sub-LSPs MUST be
1180	   treated as part of the same P2MP tunnel instance if they have the
1181	   same LSP-id and the same DETOUR objects. Note that as specified in
1182	   section 3 P2P sub-LSPs between different P2MP tunnel instances use
1183	   different labels.

1185	   If there is only P2P sub-LSP in the Path message, the DETOUR object
1186	   applies to that sub-LSP. If there are multiple P2P sub-LSPs in the
1187	   Path message the DETOUR applies to all the P2P sub-LSPs.

1189	21. Support for LSRs that are not P2MP Capable

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

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

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

1210	   The use of LSP-stitching and LSP-hierarchy [LSP-HIER] allows to build
1211	   P2MP LSP Tunnels in such an environment. A P2P LSP segment is
1212	   signaled from the previous P2MP capable hop of a legacy LSR to the
1213	   next P2MP capable hop. Of course this assumes that intermediate
1214	   legacy LSRs are transit LSRs and cannot act as P2MP branch points.
1215	   Transit LSRs along this LSP segment do not process control plane
1216	   messages associated with a P2MP LSP Tunnel. Furthermore these LSRs
1217	   also do not need to have P2MP data plane capability as they only need
1218	   to process data belonging to the P2P LSP segment. Hence these LSRs do
1219	   not need to support P2MP MPLS. This P2P LSP segment is stitched to
1220	   the incoming P2MP LSP Tunnel. After the P2P LSP segment is
1221	   established the P2MP Path message is sent to the next P2MP capable
1222	   LSR as a directed Path  message. The next P2MP capable LSR stitches
1223	   the P2P LSP segment to the outgoing P2MP LSP Tunnel.

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

1231	   It may be an overhead for an operator to configure the P2P LSP
1232	   segments in advance, when it is desired to support legacy LSRs. It
1233	   may be desirable to do this dynamically. The ingress can use IGP
1234	   extensions to determine non P2MP capable LSRs. It can use this
1235	   information to compute P2P sub-LSP paths such that they avoid these
1236	   legacy LSRs. The explicit route object of a P2P sub-LSP path may
1237	   contain loose hops if there are legacy LSRs along the path. The
1238	   corresponding explicit route contains a list of objects upto the P2MP
1239	   capable LSR that is adjacent to a legacy LSR followed by a loose
1240	   object with the address of the next P2MP capable LSR. The P2MP
1241	   capable LSR expands the loose hop using its TED. When doing this it
1242	   determines that the loose hop expansion requires a P2P LSP to tunnel
1243	   through the legacy LSR. If such a P2P LSP exists, it uses that P2P
1244	   LSP. Else it establishes the P2P LSP.  The P2MP Path message is sent
1245	   to the next P2MP capable LSR using non-adjacent signaling. The P2MP
1246	   capable LSR that initiates the non-adjacent signaling message to the
1247	   next P2MP capable LSR may have to employ a fast detection mechanism
1248	   such as [BFD] to the next P2MP capable LSR.

1250	   This may be needed for the directed Path message Head-End to use node
1251	   protection FRR when the protected node is the directed Path message
1252	   tail.

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

1257	22. Reduction in Control Plane Processing with LSP Hierarchy

1259	   It is possible to take advantage of LSP hierarchy [LSP-HIER] while
1260	   setting up P2MP LSP Tunnels, as described in the previous section, to
1261	   reduce control plane processing along transit LSRs that are P2MP
1262	   capable. This is applicable only in environments where LSP hierarchy
1263	   can be used. Transit LSRs along a P2P LSP segment, being used by a
1264	   P2MP LSP Tunnel, do not process control plane messages associated
1265	   with the P2MP LSP Tunnel. Infact they are not aware of these messages
1266	   as they are tunneled over the P2P LSP segment. This reduces the
1267	   amount of control plane processing required on these transit LSRs.

1269	   Note that the P2P LSP segments can be dynamically setup as described
1270	   in the previous section or preconfigured. For example in Figure 2,
1271	   PE1 can setup a P2P LSP to P1 and use that as a LSP segment. The Path
1272	   messages for PE3 and PE4 can now be tunneled over the LSP segment.
1273	   Thus P3 is not aware of the P2MP LSP Tunnel and does not process the
1274	   P2MP control messages.

1276	23. P2MP LSP Tunnel Remerging and Cross-Over

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

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

1293	   Case1: P2P sub-LSP already exist as part of an existing Path state.
1294	   The following are the various sub-cases.
1295	      a) The new P2P sub-LSP uses the same PHOP and outgoing interface
1296	   as the existing P2P sub-LSP. This is either a refresh or can occur
1297	   when multiple existing Path messages are combined in a new Path
1298	   message.
1299	      b) The new P2P sub-LSP uses the same PHOP but different outgoing
1300	   interface as the existing P2P sub-LSP. This is a case of re-routing.
1301	      c) The new P2P sub-LSP uses a different PHOP and same outgoing
1302	   interface as the existing P2P sub-LSP. This is a case of re-merging.
1303	      d) The new P2P sub-LSP uses a different PHOP and a different
1304	   outgoing interface as compared to the existing P2P sub-LSP. This is a
1305	   case of cross-over.

1307	   Case2: P2P sub-LSP does not exist as part of an existing Path state.
1308	   The following are the sub-cases.
1309	      a) The new P2P sub-LSP uses a PHOP and outgoing interface that is
1310	   same as the PHOP and outgoing interface used by an existing P2P sub-
1311	   LSP. This is a legal case of signaling a new P2P sub-LSP.
1312	      b) The new P2P sub-LSP uses a PHOP that is same as that used by an
1313	   existing P2P sub-LSP. However the outgoing interface is different
1314	   from the outgoing interfaces used by existing P2P sub-LSPs. This is a
1315	   legal case of signaling a new P2P sub-LSP.
1316	      c) The new P2P sub-LSP uses a different PHOP than that used by any
1317	   of the existing P2P sub-LSP. However the outgoing interface is same
1318	   as the outgoing interface used by an existing P2P sub-LSPs. This is a
1319	   case of remerging.
1320	      d) The new P2P sub-LSP uses a different PHOP than that used by any
1321	   of the existing P2P sub-LSP. Also the outgoing interface is different
1322	   from the outgoing interfaces used by existing P2P sub-LSPs. This is a
1323	   case of cross-over.

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

1330	   The below procedure applies for remerging.

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

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

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

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

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

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

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

1386	23.1. PathErr Message Format

1388	   As described above, in the case where remerging is detected, a
1389	   PathErr message will include one or more P2P_SUB_LSP objects. The
1390	   resulting modified for a PathErr Message is:

1392	   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1393	                             [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]
1394	   ... ]
1395	                             [ <MESSAGE_ID> ]
1396	                             <SESSION> <ERROR_SPEC>
1397	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1398	                             [ <POLICY_DATA> ... ]
1399	                             <sender descriptor>
1400	                             [ <P2P sub-LSP descriptor list> ]

1402	   PathErr messages generation is unmodified, but nodes that set the
1403	   Sub-Group Originator field and propagate a received PathErr message
1404	   upstream MUST replace the Sub-Group fields received in the PathErr
1405	   message with the value that was received in the Sub-Group fields of
1406	   the Path message from the upstream neighbor.  Note the receiver of a
1407	   PathErr message is able to identify the errored outgoing Path
1408	   message, and outgoing interface, based on the Sub-Group fields
1409	   received in the error message.

1411	24. New and Updated Message Objects

1413	   This section presents the RSVP message related formats as modified by
1414	   this document.

1416	24.1. P2MP LSP Tunnel SESSION Object

1418	   A P2MP LSP Tunnel SESSION object is used. This object uses the
1419	   existing SESSION C-Num. New C-Types are defined to accommodate a
1420	   logical P2MP destination identifier of the P2MP Tunnel. This SESSION
1421	   object has a similar structure as the existing point to point RSVP-TE
1422	   SESSION object. However the destination address is set to the P2MP ID
1423	   instead of the unicast Tunnel Endpoint address. All P2P sub-LSPs part
1424	   of the same P2MP LSP Tunnel share the same SESSION object. This
1425	   SESSION object identifies the P2MP Tunnel.

1427	   The combination of the SESSION object, the SENDER_TEMPLATE object and
1428	   the P2P SUB-LSP object, identifies each P2P sub-LSP. This follows the
1429	   existing P2P RSVP-TE notion of using the SESSION object for
1430	   identifying a P2P Tunnel which in turn can contain multiple LSP
1431	   Tunnels, each distinguished by a unique SENDER_TEMPLATE object.

1433	24.1.1. P2MP IPv4 LSP SESSION Object

1435	   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD

1437	       0                   1                   2                   3
1438	       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
1439	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1440	      |                       P2MP ID                                 |
1441	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1442	      |  MUST be zero                 |      Tunnel ID                |
1443	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1444	      |                      Extended Tunnel ID                       |
1445	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1447	   P2MP ID

1449	      A 32-bit identifier used in the SESSION object that remains
1450	      constant over the life of the P2MP tunnel. It encodes the
1451	      P2MP ID and identifies the set of destinations of the P2MP
1452	      LSP Tunnel.

1454	   Tunnel ID

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

1459	   Extended Tunnel ID

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

1467	24.1.2. P2MP IPv6 LSP SESSION Object

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

1473	24.2. SENDER_TEMPLATE object

1475	   The sender template contains the ingress-LSR source address. LSP ID
1476	   can be can be changed to allow a sender to share resources with
1477	   itself. Thus multiple instances of the P2MP tunnel can be created,
1478	   each with a different LSP ID. The instances can share resources with
1479	   each other, but use different labels. The P2P sub-LSPs corresponding
1480	   to a particular instance use the same LSP ID.

1482	   As described in section 6.1 it is necessary to distinguish different
1483	   Path messages that are used to signal state for the same P2MP LSP
1484	   Tunnel by using a <Sub-Group ID Originator ID, Sub-Group ID> tuple.
1485	   There are various methods to encode this information. This document
1486	   proposes the use of the SENDER_TEMPLATE object and modifies it to
1487	   carry this information as shown below. This encoding is subject to
1488	   review by the MPLS WG.

1490	24.2.1. P2MP IPv4 LSP Tunnel SENDER_TEMPLATE Object

1492	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD

1494	         0                   1                   2                   3
1495	         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
1496	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1497	        |                   IPv4 tunnel sender address                  |
1498	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1499	        |       Reserved                |            LSP ID             |
1500	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1501	        |                   Sub-Group Originator ID                     |
1502	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1503	        |       Reserved                |            Sub-Group ID       |
1504	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1505	        IPv4 tunnel sender address
1506	            See [RFC3209]

1508	        Sub-Group Originator ID
1509	            The Sub-Group Originator ID is set to the TE Router ID of
1510	            the LSR that originates the Path message. This is either the
1511	            ingress LSR or a LSR which re-originates the Path message
1512	            with its own Sub-Group Originator ID.

1514	        Sub-Group ID
1515	            An identifier of a Path message used to differentiate
1516	            multiple Path messages that signal state for the same P2MP
1517	            LSP. This may be seen as identifying a group of one or more
1518	            egress nodes targeted by this Path message. If the third
1519	            mechanism for pruning is used as described in section 11,
1520	            the Sub-Group ID value of zero (0) has special meaning and
1521	            MUST NOT be used with P2MP LSP Tunnels in messages other
1522	            than PathTear messages. Use of a Sub-Group ID value of zero
1523	            (0) in PathTear messages is defined below.

1525	        LSP ID
1526	           See [RFC3209]

1528	24.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

1530	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBD

1532	         0                   1                   2                   3
1533	         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1534	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1535	        |                                                               |
1536	        +                                                               +
1537	        |                   IPv6 tunnel sender address                  |
1538	        +                                                               +
1539	        |                            (16 bytes)                         |
1540	        +                                                               +
1541	        |                                                               |
1542	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1543	        |       Reserved                |            LSP ID             |
1544	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545	        |                                                               |
1546	        +                                                               +
1547	        |                   Sub-Group Originator ID                     |
1548	        +                                                               +
1549	        |                            (16 bytes)                         |
1550	        +                                                               +
1551	        |                                                               |
1552	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1553	        |       Reserved                |            Sub-Group ID       |
1554	        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1556	        IPv6 tunnel sender address
1557	           See [RFC3209]

1559	        Sub-Group Originator ID
1560	            The Sub-Group Originator ID is set to the IPv6 TE Router ID
1561	            of the LSR that originates the Path message. This is either
1562	            the ingress LSR or a LSR which re-originates the Path
1563	            message with its own Sub-Group Originator ID.

1565	        Sub-Group ID
1566	           As above.

1568	        LSP ID
1569	           See [RFC3209]

1571	24.3. P2P SUB-LSP IPv4 Object

1573	   A new P2P Sub-LSP object identifies a particular P2P sub-LSP
1574	   belonging to the P2MP LSP Tunnel.

1576	24.3.1. P2P SUB-LSP IPv4 Object

1578	   SUB_LSP Class = TBD, P2P_SUB_LSP_IPv4 C-Type = TBD

1580	       0                   1                   2                   3
1581	       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
1582	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1583	      |                   IPv4 P2P Sub-LSP destination address        |
1584	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1585	      |  MUST be zero                 |            Sub-LSP ID         |
1586	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1588	   IPv4 Sub-LSP destination address

1590	      IPv4 address of the P2P sub-LSP destination.

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

1595	   Sub-LSP ID

1597	      A 16-bit identifier that identifies a particular instance
1598	      of a P2P sub-LSP. It can be varied for P2P sub-LSP
1599	      make-before-break. Different P2P sub-LSPs, with the same SESSION
1600	      object and LSP ID, follow the label merge semantics described in
1601	      section 3 to form a particular instance of the P2MP tunnel.

1603	24.3.2. P2P SUB-LSP IPv6 Object

1605	   SUB_LSP Class = TBD, P2P_SUB_LSP_IPv6 C-Type = TBD

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

1610	24.4. FILTER_SPEC Object

1612	   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
1613	   object.

1615	24.4.1. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object

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

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

1622	24.4.2. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object

1624	   Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv6 C_Type = TBD

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

1629	24.5. SUB_EXPLICIT_ROUTE Object (SERO)

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

1634	24.6. SUB_RECORD_ROUTE Object (SRRO)

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

1639	25. IANA Considerations

1641	25.1. New Message Objects

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

1646	25.2. New Error Codes

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

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

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

1657	25.3. LSP Attributes Flags

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

1663	   Suggested Bit Number:             3
1664	   Meaning:                          LSP Integrity Required
1665	   Used in Attributes Flags on Path: Yes
1666	   Used in Attributes Flags on Resv: No
1667	   Used in Attributes Flags on RRO:  No
1668	   Referenced Section of this Doc:   16

1670	   Suggested Bit Number:             4
1671	   Meaning:                          Branch Reoptimization Allowed
1672	   Used in Attributes Flags on Path: Yes
1673	   Used in Attributes Flags on Resv: No
1674	   Used in Attributes Flags on RRO:  No
1675	   Referenced Section of this Doc:   17.3

1677	26. Security Considerations

1679	   This document does not introduce any new security issues. The
1680	   security issues identified in [RFC3209] and [RFC3473] are still
1681	   relevant.

1683	27. Acknowledgements

1685	   This document is the product of many people. The contributors are
1686	   listed in Section 26.

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

1692	28. Appendix

1694	28.1. Example

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

1699	                   Source 1 (S1)
1700	                     |
1701	                    PE1
1702	                   |   |
1703	                   |L5 |
1704	                   P3  |
1705	                   |   |
1706	                L3 |L1 |L2
1707	       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
1708	                  | L4
1709	          PE5----PE4----R3
1710	                  |
1711	                  |
1712	                 R4

1714	                Figure 2.

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

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

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

1725	   c) PE1 establishes the P2P sub-LSP to PE2 along <PE1, P2, PE2>

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

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

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

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

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

1753	29. References

1755	29.1. Normative References

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

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

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

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

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

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

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

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

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

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

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

1797	29.2. Informative References

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

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

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

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

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

1814	      [P2MP-REQ] S. Yasukawa, et. al., "Requirements for Point-to-Multipoint
1815	                 capability extension to MPLS",
1816	                 draft-ietf-mpls-p2mp-requirement-04.txt.

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

1821	30. Author Information

1823	30.1. Editor Information

1825	   Rahul Aggarwal
1826	   Juniper Networks
1827	   1194 North Mathilda Ave.
1828	   Sunnyvale, CA 94089
1829	   Email: rahul@juniper.net

1831	   Seisho Yasukawa
1832	   NTT Corporation
1833	   9-11, Midori-Cho 3-Chome
1834	   Musashino-Shi, Tokyo 180-8585 Japan
1835	   Phone: +81 422 59 4769
1836	   EMail: yasukawa.seisho@lab.ntt.co.jp

1838	   Dimitri Papadimitriou
1839	   Alcatel
1840	   Francis Wellesplein 1,
1841	   B-2018 Antwerpen, Belgium
1842	   Phone: +32 3 240-8491
1843	   Email: Dimitri.Papadimitriou@alcatel.be

1845	30.2. Contributor Information

1847	   John Drake
1848	   Calient Networks
1849	   Email: jdrake@calient.net

1851	   Alan Kullberg
1852	   Motorola Computer Group
1853	   120 Turnpike Road 1st Floor
1854	   Southborough, MA  01772
1855	   EMail: alan.kullberg@motorola.com
1856	   Lou Berger
1857	   Movaz Networks, Inc.
1858	   7926 Jones Branch Drive
1859	   Suite 615
1860	   McLean VA, 22102
1861	   Phone: +1 703 847-1801
1862	   EMail: lberger@movaz.com

1864	   Liming Wei
1865	   Redback Networks
1866	   350 Holger Way
1867	   San Jose, CA 95134
1868	   Email: lwei@redback.com

1870	   George Apostolopoulos
1871	   Redback Networks
1872	   350 Holger Way
1873	   San Jose, CA 95134
1874	   Email: georgeap@redback.com

1876	   Kireeti Kompella
1877	   Juniper Networks
1878	   1194 N. Mathilda Ave
1879	   Sunnyvale, CA 94089
1880	   Email: kireeti@juniper.net

1882	   George Swallow
1883	   Cisco Systems, Inc.
1884	   300 Beaver Brook Road
1885	   Boxborough , MA - 01719
1886	   USA
1887	   Email: swallow@cisco.com

1889	   JP Vasseur
1890	   Cisco Systems, Inc.
1891	   300 Beaver Brook Road
1892	   Boxborough , MA - 01719
1893	   USA
1894	   Email: jpv@cisco.com

1896	   Dean Cheng
1897	   Cisco Systems Inc.
1898	   170 W Tasman Dr.
1899	   San Jose, CA 95134
1900	   Phone 408 527 0677
1901	   Email:  dcheng@cisco.com

1903	   Markus Jork
1904	   Avici Systems
1905	   101 Billerica Avenue
1906	   N. Billerica, MA 01862
1907	   Phone: +1 978 964 2142
1908	   EMail: mjork@avici.com

1910	   Hisashi Kojima
1911	   NTT Corporation
1912	   9-11, Midori-Cho 3-Chome
1913	   Musashino-Shi, Tokyo 180-8585 Japan
1914	   Phone: +81 422 59 6070
1915	   EMail: kojima.hisashi@lab.ntt.co.jp

1917	   Andrew G. Malis
1918	   Tellabs
1919	   2730 Orchard Parkway
1920	   San Jose, CA 95134
1921	   Phone: +1 408 383 7223
1922	   Email: Andy.Malis@tellabs.com

1924	   Koji Sugisono
1925	   NTT Corporation
1926	   9-11, Midori-Cho 3-Chome
1927	   Musashino-Shi, Tokyo 180-8585 Japan
1928	   Phone: +81 422 59 2605
1929	   EMail: sugisono.koji@lab.ntt.co.jp

1931	   Masanori Uga
1932	   NTT Corporation
1933	   9-11, Midori-Cho 3-Chome
1934	   Musashino-Shi, Tokyo 180-8585 Japan
1935	   Phone: +81 422 59 4804
1936	   EMail: uga.masanori@lab.ntt.co.jp

1938	   Igor Bryskin
1939	   Movaz Networks, Inc.
1940	   7926 Jones Branch Drive
1941	   Suite 615
1942	   McLean VA, 22102

1944	   Adrian Farrel
1945	   Old Dog Consulting
1946	   Phone: +44 0 1978 860944
1947	   EMail: adrian@olddog.co.uk

1949	   Jean-Louis Le Roux
1950	   France Telecom
1951	   2, avenue Pierre-Marzin
1952	   22307 Lannion Cedex
1953	   France
1954	   E-mail: jeanlouis.leroux@francetelecom.com

1956	31. Intellectual Property

1958	   The IETF takes no position regarding the validity or scope of any
1959	   Intellectual Property Rights or other rights that might be claimed to
1960	   pertain to the implementation or use of the technology described in
1961	   this document or the extent to which any license under such rights
1962	   might or might not be available; nor does it represent that it has
1963	   made any independent effort to identify any such rights.  Information
1964	   on the procedures with respect to rights in RFC documents can be
1965	   found in BCP 78 and BCP 79.

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

1974	   The IETF invites any interested party to bring to its attention any
1975	   copyrights, patents or patent applications, or other proprietary
1976	   rights that may cover technology that may be required to implement
1977	   this standard.  Please address the information to the IETF at ietf-
1978	   ipr@ietf.org.

1980	32. Full Copyright Statement

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

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

1994	33. Acknowledgement

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