idnits 2.17.1 

draft-ietf-mpls-rsvp-te-p2mp-00.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 1975.

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

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

  ** 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 11 instances of too long lines in the document, the longest
     one being 8 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 686 has weird spacing: '...RRO and  possi...'

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

  == Line 1229 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 1051, but not defined

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

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

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

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

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

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

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

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

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

  == Unused Reference: 'RFC2209' is defined on line 1828, 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: June 2005                  S. Yasukawa (NTT)
4	                                           Editors

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

8	                 draft-ietf-mpls-rsvp-te-p2mp-00.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....................................
121	.......... 39
122	      30     Authors................................................. 40
123	      31     Intellectual Property................................... 43
124	      32     Full Copyright Statement................................ 43
125	      33     Acknowledgement......................................... 44

127	1. Introduction

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

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

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

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

150	2. Terminology

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

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

161	3. Mechanism

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

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

174	3.1. P2MP Tunnels

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

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

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

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

193	3.2. P2MP LSP Tunnel

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

202	3.3. P2P Sub-LSPs

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

206	3.3.1. Representation of a P2P Sub-LSP

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

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

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

225	3.3.2. P2P Sub-LSPs and Path Messages

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

236	3.4. Explicit Route Encoding

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

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

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

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

281	  Explicit route compression is illustrated using the following figure.

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

300	                       Figure 1. Explicit Route Compression

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

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

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

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

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

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

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

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

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

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

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

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

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

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

362	4. Sub-Groups

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

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

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

394	5. Path Message Format

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

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

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

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

420	  <P2P sub-LSP descriptor list> ::= <P2P sub-LSP descriptor>
421	                                    [ <P2P sub-LSP descriptor list> ]

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

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

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

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

439	  Path message processing is described in the next section.

441	6. Path Message Processing

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

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

459	6.1. Multiple Path messages

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

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

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

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

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

500	6.1.1. Identifying Multiple Path Messages

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

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

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

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

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

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

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

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

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

580	7. Resv Message Format

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

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

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

598	  <FF flow descriptor list> ::= <FF flow descriptor>
599	                                | <FF flow descriptor list>
600	                                <FF flow descriptor>

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

604	  <SE filter spec list> ::= <SE filter spec>
605	                           | <SE filter spec list> <SE filter spec>

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

610	  <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
611	                           [ <RECORD_ROUTE> ] [ <P2P sub-LSP descriptor
612	  list> ]

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

617	  FILTER_SPEC is defined in section 24.4.

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

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

632	8. Resv Message Processing

634	  The egress LSR follows normal RSVP procedures while originating a
635	  Resv message. The Resv message carries the label allocated by the
636	  egress LSR.

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

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

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

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

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

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

672	  The solution for this issue is for further discussion.

674	8.1. RRO Processing

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

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

693	8.2. Resv Message Throttling

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

709	9. Transit Fragmentation

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

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

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

741	10. Grafting

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

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

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

760	11. Pruning

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

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

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

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

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

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

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

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

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

842	11.1. P2MP TE LSP Tear Down

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

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

850	11.2. PathTear message Format

852	  The format of the PathTear message is as follows:

854	  <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
855	                          [ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ...
856	  ]
857	                          [ <MESSAGE_ID> ]
858	                          <SESSION> <RSVP_HOP>
859	                          [ <sender descriptor> ]
860	                          [ <P2P sub-LSP descriptor list> ]

862	                <send
863	er descriptor> ::= (see earlier definition)

865	  Note: it is assumed that the P2P sub-LSP descriptor will not include
866	  the SUB_EXPLICIT_ROUTE object associated with each P2P_SUB_LSP being
867	  deleted

869	12. Refresh Reduction

871	  The refresh reduction procedures described in [RFC2961] are equally
872	  applicable to P2MP LSP Tunnels described in this document. Refresh
873	  reduction applies to individual messages and the state they
874	  install/maintain, and that continues to be the case for P2MP LSP
875	  Tunnels.

877	13. State Management

879	  State signaled by a P2MP Path message is managed by a local
880	  implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as
881	  part of the SESSION object and <Tunnel Sender Address, LSP ID, Sub-
882	  Group Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE
883	  object.

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

889	13.1. Incremental State Update

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

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

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

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

925	13.2. Combining Multiple Path Messages

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

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

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

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

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

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

972	14. Error Processing

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

984	14.1. Branch Failure Handling

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

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

1002	  A branch LSR that receives a PathErr message with the
1003	  Path_State_Removed flag set MUST act according to the wishes of the
1004	  ingress LSR. The default behavior is that the branch LSR clears the
1005	  Path_State_Removed flag on the PathErr and sends it further upstream.
1006	  It does not tear any other branches of the LSP. However, if the LSP

1008	  integrity flag is set on the Path message, the branch LSR MUST send
1009	  PathTear on all downstream branches and send the PathErr message
1010	  upstream with the Path_State_Removed flag set.

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

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

1025	15. Notify and ResvConf Messages

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

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

1042	16. Control of Branch Fate Sharing

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

1051	  The ingress LSP may request 'LSP integrity' by setting bit [TBD] of
1052	  the Attributes Flags TLV. The bit is set if LSP integrity is
1053	  required.

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

1058	  A branch LSR that supports the Attributes Flags TLV and recognizes
1059	  this bit MUST support LSP integrity or reject the LSP setup with a
1060	  PathErr carrying the error "Routing Error"/"Unsupported LSP
1061	  Integrity"

1063	17. Admin Status Change

1065	  A branch node that receives an ADMIN_STATUS object processes it
1066	  normally and also relays the ADMIN_STATUS object in a Path on every
1067	  branch. All Path messages may be concurrently sent to the downstream
1068	  neighbors.

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

1077	18. Label Allocation on LANs with Multiple Downstream Nodes

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

1091	19. Make-before-break

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

1095	19.1. P2MP Tree Re-optimization

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

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

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

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

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

1122	20. Fast Reroute

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

1127	20.1. Facility Backup

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

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

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

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

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

1165	20.2. One to One Backup

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

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

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

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

1192	  If there is only P2P sub-LSP in the Path message, the DETOUR object
1193	  applies to that sub-LSP. If there are multiple P2P sub-LSPs in the
1194	  Path message the DETOUR applies to all the P2P sub-LSPs.

1196	21. Support for LSRs that are not P2MP Capable

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

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

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

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

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

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

1257	  This may be needed for the directed Path message Head-End to use node
1258	  protection FRR when the protected node is the directed Path message
1259	  tail.

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

1264	22. Reduction in Control Plane Processing with LSP Hierarchy

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

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

1283	23. P2MP LSP Tunnel Remerging and Cross-Over

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

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

1301	  Case1: P2P sub-LSP already exist as part of an existing Path state.
1302	  The following are the various sub-cases.
1303	     a) The new P2P sub-LSP uses the same PHOP and outgoing interface
1304	  as the existing P2P sub-LSP. This is either a refresh or can occur
1305	  when multiple existing Path messages are combined in a new Path
1306	  message.
1307	     b) The new P2P sub-LSP uses the same PHOP but different outgoing
1308	  interface as the existing P2P sub-LSP. This is a case of re-routing.
1309	     c) The new P2P sub-LSP uses a different PHOP and same outgoing
1310	  interface as the existing P2P sub-LSP. This is a case of re-merging.
1311	     d) The new P2P sub-LSP uses a different PHOP and a different
1312	  outgoing interface as compared to the existing P2P sub-LSP. This is a
1313	  case of cross-over.

1315	  Case2: P2P sub-LSP does not exist as part of an existing Path state.
1316	  The following are the sub-cases.
1317	     a) The new P2P sub-LSP uses a PHOP and outgoing interface that is
1318	  same as the PHOP and outgoing interface used by an existing P2P sub-
1319	  LSP. This is a legal case of signaling a new P2P sub-LSP.
1320	     b) The new P2P sub-LSP uses a PHOP that is same as that used by an
1321	  existing P2P sub-LSP. However the outgoing interface is different
1322	  from the outgoing interfaces used by existing P2P sub-LSPs. This is a
1323	  legal case of signaling a new P2P sub-LSP.
1324	     c) The new P2P sub-LSP uses a different PHOP than that used by any
1325	  of the existing P2P sub-LSP. However the outgoing interface is same
1326	  as the outgoing interface used by an existing P2P sub-LSPs. This is a
1327	  case of remerging.
1328	     d) The new P2P sub-LSP uses a different PHOP than that used by any
1329	  of the existing P2P sub-LSP. Also the outgoing interface is different
1330	  from the outgoing interfaces used by existing P2P sub-LSPs. This is a
1331	  case of cross-over.

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

1338	  The below procedure applies for remerging.

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

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

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

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

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

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

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

1394	23.1. PathErr Message Format

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

1400	  <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1401	                            [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]
1402	  ... ]
1403	                            [ <MESSAGE_ID> ]
1404	                            <SESSION> <ERROR_SPEC>
1405	                            [ <ACCEPTABLE_LABEL_SET> ... ]
1406	                            [ <POLICY_DATA> ... ]
1407	                            <sender descriptor>
1408	                            [ <P2P sub-LSP descriptor list> ]

1410	  PathErr messages generation is unmodified, but nodes that set the
1411	  Sub-Group Originator field and propagate a received PathErr message
1412	  upstream MUST replace the Sub-Group fields received in the PathErr
1413	  message with the value that was received in the Sub-Group fields of
1414	  the Path message from the upstream neighbor.  Note the receiver of a
1415	  PathErr message is able to identify the errored outgoing Path
1416	  message, and outgoing interface, based on the Sub-Group fields
1417	  received in the error message.

1419	24. New and Updated Message Objects

1421	  This section presents the RSVP message related formats as modified by
1422	  this document.

1424	24.1. P2MP LSP Tunnel SESSION Object

1426	  A P2MP LSP Tunnel SESSION object is used. This object uses the
1427	  existing SESSION C-Num. New C-Types are defined to accommodate a
1428	  logical P2MP destination identifier of the P2MP Tunnel. This SESSION
1429	  object has a similar structure as the existing point to point RSVP-TE
1430	  SESSION object. However the destination address is set to the P2MP ID
1431	  instead of the unicast Tunnel Endpoint address. All P2P sub-LSPs part
1432	  of the same P2MP LSP Tunnel share the same SESSION object. This
1433	  SESSION object identifies the P2MP Tunnel.

1435	  The combination of the SESSION object, the SENDER_TEMPLATE object and
1436	  the P2P SUB-LSP object, identifies each P2P sub-LSP. This follows the
1437	  existing P2P R
1438	SVP-TE notion of using the SESSION object for
1439	  identifying a P2P Tunnel which in turn can contain multiple LSP
1440	  Tunnels, each distinguished by a unique SENDER_TEMPLATE object.

1442	24.1.1. P2MP IPv4 LSP SESSION Object

1444	  Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD

1446	      0                   1                   2                   3
1447	      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
1448	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1449	     |                       P2MP ID                                 |
1450	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1451	     |  MUST be zero                 |      Tunnel ID                |
1452	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1453	     |                      Extended Tunnel ID                       |
1454	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1456	  P2MP ID

1458	     A 32-bit identifier used in the SESSION object that remains
1459	     constant over the life of the P2MP tunnel. It encodes the
1460	     P2MP ID and identifies the set of destinations of the P2MP
1461	     LSP Tunnel.

1463	  Tunnel ID

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

1468	  Extended Tunnel ID

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

1476	24.1.2. P2MP IPv6 LSP SESSION Object

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

1482	24.2. SENDER_TEMPLATE object

1484	  The sender template contains the ingress-LSR source address. LSP ID
1485	  can be can be changed to allow a sender to share resources with
1486	  itself. Thus multiple instances of the P2MP tunnel can be created,
1487	  each with a different LSP ID. The instances can share resources with
1488	  each other, but use different labels. The P2P sub-LSPs corresponding
1489	  to a particular instance use the same LSP ID.

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

1499	24.2.1. P2MP IPv4 LSP Tunnel SENDER_TEMPLATE Object

1501	  Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = TBD

1503	        0                   1                   2                   3
1504	        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
1505	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1506	       |                   IPv4 tunnel sender address                  |
1507	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1508	       |       Reserved                |            LSP ID             |
1509	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1510	       |                   Sub-Group Originator ID                     |
1511	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1512	       |       Reserved                |            Sub-Group ID       |
1513	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1514	       IPv4 tunnel sender address
1515	           See [RFC3209]

1517	       Sub-Group Originator ID
1518	           The Sub-Group Originator ID is set to the TE Router ID of
1519	           the LSR that originates the Path message. This is either the
1520	           ingress LSR or a LSR which re-originates the Path message
1521	           with its own Sub-Group Originator ID.

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

1534	       LSP ID
1535	          See [RFC3209]

1537	24.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

1539	  Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = TBD

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

1565	       IPv6 tunnel sender address
1566	          See [RFC3209]

1568	       Sub-Group Originator ID
1569	           The Sub-Group Originator ID is set to the IPv6 TE Router ID
1570	           of the LSR that originates the Path message. This is either
1571	           the ingress LSR or a LSR which re-originates the Path
1572	           message with its own Sub-Group Originator ID.

1574	       Sub-Group ID
1575	          As above.

1577	       LSP ID
1578	          See [RFC3209]

1580	24.3. P2P SUB-LSP IPv4 Object

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

1585	24.3.1. P2P SUB-LSP IPv4 Object

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

1589	      0                   1                   2                   3
1590	      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
1591	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1592	     |                   IPv4 P2P Sub-LSP destination address        |
1593	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1594	     |  MUST be zero                 |            Sub-LSP
1595	ID         |
1596	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1598	  IPv4 Sub-LSP destination address

1600	     IPv4 address of the P2P sub-LSP destination.

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

1605	  Sub-LSP ID

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

1613	24.3.2. P2P SUB-LSP IPv6 Object

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

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

1620	24.4. FILTER_SPEC Object

1622	  The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
1623	  object.

1625	24.4.1. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object

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

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

1632	24.4.2. P2MP LSP_TUNNEL_IPv4 FILTER_SPEC Object

1634	  Class = FILTER SPEC, P2MP LSP_TUNNEL_IPv6 C_Type = TBD

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

1639	24.5. SUB_EXPLICIT_ROUTE Object (SERO)

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

1644	24.6. SUB_RECORD_ROUTE Object (SRRO)

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

1649	25. IANA Considerations

1651	25.1. New Message Objects

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

1656	25.2. New Error Codes

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

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

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

1667	25.3. LSP Attributes Flags

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

1673	  Suggested Bit Number:             3
1674	  Meaning:                          LSP Integrity Required
1675	  Used in Attributes Flags on Path: Yes
1676	  Used in Attributes Flags on Resv: No
1677	  Used in Attributes Flags on RRO:  No
1678	  Referenced Section of this Doc:   16

1680	  Suggested Bit Number:             4
1681	  Meaning:                          Branch Reoptimization Allowed
1682	  Used in Attributes Flags on Path: Yes
1683	  Used in Attributes Flags on Resv: No
1684	  Used in Attributes Flags on RRO:  No
1685	  Referenced Section of this Doc:   17.3

1687	26. Security Considerations

1689	  This document does not introduce any new security issues. The
1690	  security issues identified in [RFC3209] and [RFC3473] are still
1691	  relevant.

1693	27. Acknowledgements

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

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

1702	28. Appendix

1704	28.1. Example

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

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

1724	               Figure 2.

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

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

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

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

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

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

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

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

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

1763	29. References

1765	29.1. Normative References

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

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

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

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

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

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

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

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

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

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

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

1807	29.2. Informative References

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

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

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

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

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

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

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

1831	30. Author Information

1833	30.1. Editor Information

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

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

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

1855	30.2. Contributor Information

1857	  John Drake
1858	  Calient Networks
1859	  Email: jdrake@calient.net

1861	  Alan Kullberg
1862	  Motorola Computer Group
1863	  120 Turnpike Road 1st Floor
1864	  Southborough, MA  01772
1865	  EMail: alan.kullberg@motorola.com
1866	  Lou Berger
1867	  Movaz Networks, Inc.
1868	  7926 Jones Branch Drive
1869	  Suite 615
1870	  McLean VA, 22102
1871	  Phone: +1 703 847-1801
1872	  EMail: lberger@movaz.com

1874	  Liming Wei
1875	  Redback Networks
1876	  350 Holger Way
1877	  San Jose, CA 95134
1878	  Email: lwei@redback.com

1880	  George Apostolopoulos
1881	  Redback Networks
1882	  350 Holger Way
1883	  San Jose, CA 95134
1884	  Email: georgeap@redback.com

1886	  Kireeti Kompella
1887	  Juniper Networks
1888	  1194 N. Mathilda Ave
1889	  Sunnyvale, CA 94089
1890	  Email: kireeti@juniper.net

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

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

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

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

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

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

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

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

1948	  Igor Bryskin
1949	  Movaz Networks, Inc.
1950	  7926 Jones Branch Drive
1951	  Suite 615
1952	  McLean VA, 22102

1954	  Adrian Farrel
1955	  Old Dog Consulting
1956	  Phone: +44 0 1978 860944
1957	  EMail: adrian@olddog.co.uk

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

1966	31. Intellectual Property

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

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

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

1990	32. Full Copyright Statement

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

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

2004	33. Acknowledgement

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