idnits 2.17.1 

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

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

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

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

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

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

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

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

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

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


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

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

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


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

     No issues found here.

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

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

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:
     
     Multiple Path messages generated by an LSR that signal state for
     the same P2MP LSP are signaled with the same SESSION object and have the
     same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order to
     disambiguate these Path messages a <Sub-Group Originator ID, sub-Group
     ID> tuple is introduced (also referred to as the Sub-Group field) and
     encoded in the SENDER_TEMPLATE object. Multiple Path messages generated
     by a LSR to signal state for the same P2MP LSP have the same Sub-Group
     Originator ID and have a different sub-Group ID. The Sub-Group Originator
     ID MUST be set to the TE Router ID of the LSR that originates the Path
     message. This is either the ingress LSR or a LSR which re-originates the
     Path message with its own Sub-Group Originator ID. Cases when a transit
     LSR may change the Sub-Group Originator ID of an incoming Path message
     are described below. The <Sub-Group Originator ID, sub-Group ID> tuple is
     globally unique. The sub-Group ID space is specific to the Sub-Group
     Originator ID. Therefore the combination <Sub-Group Originator ID,
     sub-Group ID> is network-wide unique. Also, a router that changes the
     Sub-Group originator ID of an incoming Path message MUST use the same
     value of the Sub-Group Originator ID for all outgoing Path messages, for
     a particular P2MP LSP, and SHOULD not vary it during the life of the P2MP
     LSP.

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

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     Considerations about the reservation style in a Resv message apply
     as described in [RFC3209]. The reservation style in the Resv messages can
     either be FF or SE. All P2MP LSPs that belong to the same P2MP Tunnel
     MUST be signaled with the same reservation style. Irrespective of whether
     the reservation style is FF or SE, the S2L sub-LSPs that belong to the
     same P2MP LSP SHOULD share labels where they share hops. If the S2L
     sub-LSPs that belong to the same P2MP LSP share labels then they MUST
     share resources. The S2L sub-LSPs that belong to different P2MP LSP MUST
     NOT share labels. If the reservation style is FF then S2L sub-LSPs that
     belong to different P2MP LSP MUST NOT share resources. If the reservation
     style is SE than S2L sub-LSPs that belong to different P2MP LSP and the
     same P2MP Tunnel SHOULD share resources where they share hops, but MUST
     not share labels.

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     If link protection is desired, a bypass tunnel MUST be used to
     protect the link between the PLR and next-hop. Thus all S2L sub-LSPs that
     use the link MUST be protected in the event of link failure. Note that
     all such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel
     will share the same outgoing label on the link between the PLR and the
     next-hop. This is the P2MP LSP label on the link. Label stacking is used
     to send data for each P2MP LSP into the bypass tunnel. The inner label is
     the P2MP LSP label allocated by the next-hop. During failure Path
     messages for each S2L sub-LSP, that are effected, MUST be sent to the MP,
     by the PLR. It is recommended that the PLR use the sender template
     specific method to identify these Path messages. Hence the PLR will set
     the source address in the sender template to a local PLR address. The MP
     MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP
     MUST not use the <sub-group originator ID, sub-group ID> while
     identifying the corresponding S2L sub-LSPs. In order to further process a
     S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the
     LSP-id and the <S2L_SUB_LSP> object.

  == 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:
     
     After detecting failure of the protected node the PLR MUST send a
     Path message for each protected S2L sub-LSP to the MP of the protected
     S2L sub-LSP. It is recommended that the PLR use the sender template
     specific method to identify these Path messages. Hence the PLR will set
     the source address in the sender template to a local PLR address. The MP
     MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP
     MUST not use the <sub-group originator ID, sub-group ID> while
     identifying the corresponding S2L sub-LSPs. In order to further process a
     S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the
     LSP-id and the <S2L_SUB_LSP> object.

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

  -- The document date (May 2006) is 6555 days in the past.  Is this
     intentional?


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

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

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

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

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

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

  ** Downref: Normative reference to an Informational RFC: RFC 4461

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

  -- No information found for draft-ietf-bfd - is the name correct?

  == Outdated reference: A later version (-07) exists of
     draft-ietf-bfd-mpls-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)

  == Outdated reference: A later version (-06) exists of
     draft-ietf-ccamp-inter-domain-framework-04

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

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


     Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--).

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

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


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

8	                                                    S. Yasukawa (Editor)
9	                                                                     NTT

11	                                                                May 2006

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

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

17	Status of this Memo

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

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

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

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

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

40	Abstract

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

53	Table of Contents

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

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

151	2. Terminology

153	   This document uses terminologies defined in [RFC3031], [RFC2205],
154	   [RFC3209], [RFC3473] and [RFC4461].

156	3. Introduction

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

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

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

176	   Path computation and P2MP application specific aspects are outside
177	   the scope of this document.

179	4. Mechanism

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

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

192	4.1. P2MP Tunnels

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

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

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

208	   The P2MP ID provides an identifier for the set of destinations of the
209	   P2MP TE Tunnel.

211	4.2. P2MP LSP

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

219	4.3. Sub-Groups

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

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

236	   Taken together the Sub-Group ID and Sub-Group Originator ID are
237	   referred to as the Sub-Group fields.

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

249	4.4. S2L Sub-LSPs

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

253	4.4.1. Representation of a S2L Sub-LSP

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

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

271	4.4.2. S2L Sub-LSPs and Path Messages

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

282	4.5. Explicit Routing

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

295	   When a Path message signals multiple S2L sub-LSPs the path of the
296	   first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded
297	   in the ERO. The first S2L sub-LSP is the one that corresponds to the
298	   first <S2L_SUB_LSP> object in the Path message. The S2L sub-LSPs
299	   corresponding to the <S2L_SUB_LSP> objects that follow are termed as
300	   subsequent S2L sub-LSPs.

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

315	   In order to avoid the potential repetition of path information for
316	   the parts of S2L sub-LSPs that share hops, this information is
317	   deduced from the explicit routes of other S2L sub-LSPs using explicit
318	   route compression in SEROs.

320	   Explicit route compression is illustrated using the following figure.

322	                                    A
323	                                    |
324	                                    |
325	                                    B
326	                                    |
327	                                    |
328	                          C----D----E
329	                          |    |    |
330	                          |    |    |
331	                          F    G    H-------I
332	                               |    |\      |
333	                               |    | \     |
334	                               J    K   L   M
335	                               |    |   |   |
336	                               |    |   |   |
337	                               N    O   P   Q--R

339	                        Figure 1. Explicit Route Compression

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

348	      S2L sub-LSP-F:   ERO = {B, E, D, C, F},  <S2L_SUB_LSP> object-F
349	      S2L sub-LSP-N:   SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
350	      S2L sub-LSP-O:   SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
351	      S2L sub-LSP-P:   SERO = {H, L, P}, <S2L_SUB_LSP> object-P,
352	      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q,
353	      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R,

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

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

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

365	      S2L sub-LSP-O:   ERO = {H, K, O}, <S2L_SUB_LSP> object-O
366	      S2L sub-LSP-P:   SERO = {H, L, P}, S2L_SUB_LSP object-P,
367	      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q,
368	      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R,

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

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

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

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

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

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

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

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

401	5. Path Message

403	5.1. Path Message Format

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

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

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

428	   <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
429	                                     [ <S2L sub-LSP descriptor list> ]

431	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP
432	   SECONDARY_EXPLICIT_ROUTE> ]

434	   Each LSR MUST use the common objects in the Path message and the S2L
435	   sub-LSP descriptors to process each S2L sub-LSP represented by the
436	   <S2L_SUB_LSP> object and the SECONDARY-/EXPLICIT_ROUTE object
437	   combination.

439	   The first <S2L_SUB_LSP> object's explicit route is specified by the
440	   ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the
441	   corresponding SERO. A SERO corresponds to the following <S2L_SUB_LSP>
442	   object.

444	   The RRO in the sender descriptor contains the hops traversed by the
445	   Path message and applies to all the S2L sub-LSPs signaled in the Path
446	   message.

448	   Path message processing is described in the next section.

450	5.2. Path Message Processing

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

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

472	5.2.1. Multiple Path Messages

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

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

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

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

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

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

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

536	   The S2L sub-LSP descriptor list allows the signaling of one or more
537	   S2L sub-LSPs in one Path message. It is possible to signal multiple
538	   <S2L_SUB_LSP> object and ERO/SERO combinations in a single Path
539	   message. Note that these two objects differentiate a S2L sub-LSP.

541	   All LSRs MUST process the ERO corresponding to the first S2L sub-LSP
542	   if the ERO is present. If one or more SEROs are present an ERO MUST
543	   be present.  The first S2L sub-LSP MUST be propagated in a Path
544	   message by each LSR along the explicit route specified by the ERO, if
545	   the ERO is present.  Else it MUST be propagated using hop-by-hop
546	   routing towards the destination identified by the <S2L_SUB_LSP>
547	   object.

549	   A LSR MUST process a S2L sub-LSP descriptor for a subsequent S2L sub-
550	   LSP as follows:

552	   If the <S2L_SUB_LSP> object is followed by an SERO, the LSR MUST
553	   check the first hop in the SERO:
554	       - If the first hop of the SERO identifies a local address of the
555	         LSR, and the LSR is also the egress identified by the
556	         <S2L_SUB_LSP> object, the descriptor MUST NOT be propagated
557	         downstream, but the SERO may be used for egress control per
558	         [RFC4003].
559	       - If the first hop of the SERO identifies a local address of the
560	         LSR, and the LSR is not the egress as identified by the
561	         <S2L_SUB_LSP> object the S2L sub-LSP descriptor MUST be
562	         included in a Path message sent to the next-hop determined
563	         from the SERO.
564	       - If the first hop of the SERO is not a local address of the LSR
565	         the S2L sub-LSP descriptor MUST be included in the Path message
566	         sent to LSR that is the next hop to reach the first hop in the
567	         SERO. This next hop is determined by using the ERO or other
568	         SEROs that encode the path to the SERO's first hop.

570	   If the <S2L_SUB_LSP> object is not followed by an SERO, the LSR MUST
571	   examine the <S2L_SUB_LSP> object:
572	        - If this LSR is the egress as identified by the
573	          <S2L_SUB_LSP> object, the S2L sub-LSP descriptor MUST
574	          NOT be propagated downstream.
575	        - If this LSR is not the egress as identified by the
576	          <S2L_SUB_LSP> object, the LSR MUST make a routing decision
577	          to determine the next hop towards the egress, and MUST
578	          include the S2L sub-LSP descriptor in a Path message sent
579	          to the next-hop towards the egress. In this case, the LSR
580	          MAY insert an SERO into the S2L sub-LSP descriptor.

582	   Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
583	   descriptors on each downstream link. A S2L sub-LSP descriptor list
584	   that is propagated on a downstream link MUST only contain those S2L
585	   sub-LSPs that are routed using that link. This processing MAY result
586	   in a subsequent S2L sub-LSP in an incoming Path message to become the
587	   first S2L sub-LSP in an outgoing Path message.

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

594	   The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
595	   message and applies to all the S2L sub-LSPs signaled in the Path
596	   message. A transit LSR MUST append its address in an incoming RRO and
597	   propagate it downstream. A branch LSR MUST form a new RRO for each of
598	   the outgoing Path messages by copying the RRO from the incoming Path
599	   message and appending its address. Each such updated RRO MUST be
600	   formed using the rules in [RFC3209].

602	   If a LSR is unable to support a S2L sub-LSP in a Path message, a
603	   PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
604	   processing of the rest of the P2MP LSP SHOULD continue. The default
605	   behavior is that the remainder of the LSP is not impacted (that is,
606	   all other branches are allowed to set up) and the failed branches are
607	   reported in PathErr messages in which the Path_State_Removed flag
608	   MUST NOT be set. However, the ingress LSR may set a LSP Integrity
609	   flag to request that if there is a setup failure on any branch the
610	   entire LSP should fail to set up. This is described further in
611	   section 12.

613	5.2.3. Transit Fragmentation

615	   In certain cases a transit LSR may need to generate multiple Path
616	   messages to signal state corresponding to a single received Path
617	   message. For instance ERO expansion may result in an overflow of the
618	   resultant Path message. It is desirable not to rely on IP
619	   fragmentation in this case. In order to achieve this, the multiple
620	   Path messages generated by the transit LSR, are signaled with the
621	   Sub-Group Originator ID set to the TE Router ID of the transit LSR
622	   and a distinct sub-Group ID for each Path message. Thus each distinct
623	   Path message that is generated by the transit LSR for the P2MP LSP
624	   carries a distinct <Sub-Group Originator ID, Sub-Group ID> tuple.

626	   When multiple Path messages are used by an ingress or transit node,
627	   each Path message SHOULD be identical with the exception of the S2L
628	   sub-LSP related information (e.g., SERO), message and hop information
629	   (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields
630	   of the SENDER_TEMPLATE objects. Except when performing a  make-
631	   before-break operation as specified in section 14.1, the tunnel
632	   sender address and LSP ID fields MUST be the same in each message,
633	   and for transit nodes, the same as the values in the received Path
634	   message.

636	   As described above one case in which the Sub-Group Originator ID of a
637	   received Path message is changed is that of transit fragmentation.
638	   Another case is when the Sub-Group Originator ID of a received Path
639	   message may be changed in the outgoing Path message and set to that
640	   of the LSR originating the Path message based on a local policy. For
641	   instance a LSR may decide to always change the Sub-Group Originator
642	   ID while performing ERO expansion. The Sub-Group ID MUST not be
643	   changed if the Sub-Group Originator ID is not being changed.

645	5.2.4. Control of Branch Fate Sharing

647	   An ingress LSR can control the behavior of an LSP if there is a
648	   failure during LSP setup or after an LSP has been established. The
649	   default behavior is that only the branches downstream of the failure
650	   are not established, but the ingress may request 'LSP integrity' such
651	   that any failure anywhere within the LSP tree causes the entire P2MP
652	   LSP to fail.

654	   The ingress LSP may request 'LSP integrity' by setting bit (TBA) of
655	   the Attributes Flags TLV. The bit is set if LSP integrity is
656	   required.

658	   It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES Object.

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

665	5.3. Grafting

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

671	   There are two methods to add S2L sub-LSPs to a P2MP LSP.  The first
672	   is to add new S2L sub-LSPs to the P2MP LSP by adding them to an
673	   existing Path message and refreshing the entire Path message. Path
674	   message processing described in section 4 results in adding these S2L
675	   sub-LSPs to the P2MP LSP. Note that as a result of adding one or more
676	   S2L sub-LSPs to a Path message the ERO compression encoding may have
677	   to be recomputed.

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

684	6. Resv Message

686	6.1. Resv Message Format

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

690	   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
691	                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
692	                         [ <MESSAGE_ID> ]
693	                         <SESSION> <RSVP_HOP>
694	                         <TIME_VALUES>
695	                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
696	                         [ <NOTIFY_REQUEST> ]
697	                         [ <ADMIN_STATUS> ]
698	                         [ <POLICY_DATA> ... ]
699	                         <STYLE> <flow descriptor list>

701	   <flow descriptor list> ::= <FF flow descriptor list>
702	                              | <SE flow descriptor>

704	   <FF flow descriptor list> ::= <FF flow descriptor>
705	                                 | <FF flow descriptor list>
706	                                 <FF flow descriptor>

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

710	   <SE filter spec list> ::= <SE filter spec>
711	                            | <SE filter spec list> <SE filter spec>

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

716	   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
717	                            [ <RECORD_ROUTE> ] [ <S2L sub-LSP descriptor
718	   list> ]

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

723	   <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
724	                                     [ <S2L sub-LSP descriptor list> ]

726	   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP
727	   SECONDARY_EXPLICIT_ROUTE> ]

729	   FILTER_SPEC is defined in section 20.4.

731	   The S2L sub-LSP descriptor has the same format as in section 4.1 with
732	   the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in
733	   place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The
734	   P2MP_SECONDARY_RECORD_ROUTE objects follow the same compression
735	   mechanism as the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that
736	   that a Resv message can signal multiple S2L sub-LSPs that may belong
737	   to the same FILTER_SPEC object or different FILTER_SPEC objects. The
738	   same label SHOULD be allocated if the <Sender Address, LSP-ID> fields
739	   of the FILTER_SPEC object are the same.

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

745	6.2. Resv Message Processing

747	   The egress LSR MUST follow normal RSVP procedures while originating a
748	   Resv message. The Resv message carries the label allocated by the
749	   egress LSR.

751	   A node upstream of the egress node MUST allocate its own label and
752	   pass it in the Resv message upstream. The node MAY combine multiple
753	   flow descriptors, from different Resv messages received from
754	   downstream, in one Resv message sent upstream. A Resv message MUST
755	   NOT be sent upstream until at least one Resv message has been
756	   received from a downstream neighbor. When the integrity bit is set in
757	   the LSP_REQUIRED_ATTRIBUTE object, no Resv message MUST be sent
758	   upstream until all Resv messages have been received from the
759	   downstream neighbors.

761	   Each FF flow descriptor or SE filter spec sent upstream in a Resv
762	   message includes a S2L sub-LSP descriptor list. Each such FF flow
763	   descriptor or SE filter spec for the same P2MP LSP (whether on one or
764	   multiple Resv messages) on the same Resv MUST be allocated the same
765	   label, and FF flow descriptors or SE filter specs SHOULD use the same
766	   label across multiple Resv messages.

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

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

777	   Each branch node can potentially send one Resv message upstream for
778	   each of the downstream receivers. This MAY result in overflowing the
779	   Resv message, particularly when considering that the number of
780	   messages increases the closer the branch node is to the ingress of
781	   the P2MP LSP.

783	   Transit nodes MUST replace the Sub-Group ID fields received in the
784	   FILTER_SPEC objects with the value that was received in the Sub-Group
785	   ID field of the Path message from the upstream neighbor, when the
786	   node set the Sub-Group Originator field in the associated Path
787	   message.  ResvErr messages generation is unmodified.  Nodes
788	   propagating a received ResvErr message MUST use the Sub-Group field
789	   values carried in the corresponding Resv message.

791	6.2.1. Resv Message Throttling

793	   A branch node may have to send the Resv message being sent upstream
794	   whenever there is a change in a Resv message for a S2L sub-LSP
795	   received from one of the downstream neighbors. This can result in
796	   excessive Resv messages sent upstream,particularly when the S2L sub-
797	   LSPs are established for the first time. In order to mitigate this
798	   situation, branch nodes can limit their transmission of Resv
799	   messages. Specifically, in the case where the only change being sent
800	   in a Resv message is in one or more SRRO objects, the branch node
801	   SHOULD transmit the Resv message only after a delay time has passed
802	   since the transmission of the previous Resv message for the same
803	   session. This delayed Resv message SHOULD include SRROs for all
804	   branches. Specific mechanisms for Resv message throttling are
805	   implementation dependent and are outside the scope of this document.

807	6.3. Record Routing

809	6.3.1. RRO Processing

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

818	   The record route of the first S2L sub-LSP is encoded in the RRO.
819	   Additional RROs for the subsequent S2L sub-LSPs are referred to as
820	   P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is
821	   specified in section 20.5. The ingress node then receives the RRO and
822	   possibly the SRRO  corresponding to each subsequent S2L sub-LSP. Each
823	   <S2L_SUB_LSP> object is followed by the RRO/SRRO. The ingress node
824	   can then determine the record route corresponding to a particular S2L
825	   sub-LSP. The RRO and SRROs can be used to construct the end to end
826	   Path for each S2L sub-LSP.

828	6.4. Reservation Style

830	   Considerations about the reservation style in a Resv message apply as
831	   described in [RFC3209]. The reservation style in the Resv messages
832	   can either be FF or SE. All P2MP LSPs that belong to the same P2MP
833	   Tunnel MUST be signaled with the same reservation style. Irrespective
834	   of whether the reservation style is FF or SE, the S2L sub-LSPs that
835	   belong to the same P2MP LSP SHOULD share labels where they share
836	   hops. If the S2L sub-LSPs that belong to the same P2MP LSP share
837	   labels then they MUST share resources. The S2L sub-LSPs that belong
838	   to different P2MP LSP MUST NOT share labels. If the reservation style
839	   is FF then S2L sub-LSPs that belong to different P2MP LSP MUST NOT
840	   share resources. If the reservation style is SE than S2L sub-LSPs
841	   that belong to different P2MP LSP and the same P2MP Tunnel SHOULD
842	   share resources where they share hops, but MUST not share labels.

844	7. PathTear Message

846	7.1. PathTear Message Format

848	   The format of the PathTear message is as follows:

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

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

860	   The definition of <sender descriptor> is not changed by this
861	   document.

863	7.2. Pruning

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

870	7.2.1. Implicit S2L Sub-LSP Teardown

872	   Implicit teardown uses standard RSVP message processing. Per standard
873	   RSVP processing, a S2L sub-LSP may be removed from a P2MP TE LSP by
874	   sending a modified message for the Path or Resv message that
875	   previously advertised the S2L sub-LSP. This message MUST list all S2L
876	   sub-LSPs that are not being removed. When using this approach, a node
877	   processing a message that removes a S2L sub-LSP from a P2MP TE LSP
878	   MUST ensure that the S2L sub-LSP is not included in any other Path
879	   state associated with session before interrupting the data path to
880	   that egress.  All other message processing remains unchanged.

882	   When implicit teardown is used to delete one or more S2L sub-LSPs, by
883	   modifying a Path message, a transit LSR may have to generate a
884	   PathTear message downstream to delete one or more of these S2L sub-
885	   LSPs. This can happen if as a result of the implicit deletion of S2L
886	   sub-LSP(s) there are no remaining S2L sub-LSPs to send in the
887	   corresponding Path message downstream.

889	7.2.2. Explicit S2L Sub-LSP Teardown

891	   Explicit S2L Sub-LSP teardown relies on generating a PathTear message
892	   for the corresponding Path message. The PathTear message is signaled
893	   with the SESSION and SENDER_TEMPLATE objects corresponding to the
894	   P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple
895	   corresponding to the Path message. This approach SHOULD be used when
896	   all the egresses signaled by a Path message need to be removed from
897	   the P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled
898	   using other Path messages, are not affected by the PathTear.

900	   A transit LSR that propagates the PathTear message downstream MUST
901	   ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
902	   in the PathTear message to the values used to generate the previous
903	   Path message that corresponds to the S2L sub-LSPs being deleted by it
904	   in the PathTear message.  The transit LSR may need to generate
905	   multiple PathTear messages for an incoming PathTear message if it had
906	   performed transit fragmentation for the corresponding incoming Path
907	   message.

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

912	8. Notify and ResvConf Messages

914	8.1. Notify Messages

916	   The Notify Request object and Notify messages are described in
917	   [RFC3473]. Both object and messages SHALL be supported for delivery
918	   of upstream and downstream notification. Processing not detailed in
919	   this section MUST comply to [RFC3473].

921	   1. Upstream Notification

923	   If a transit LSR sets the Sub-Group Originator ID in the
924	   SENDER_TEMPLATE object of a Path message to its own address and the
925	   incoming Path message carries a Notify Request object then this LSR
926	   MUST change the Notify node address in the Notify Request object to
927	   its own address in the Path message that it sends.

929	   If this LSR subsequently receives a corresponding Notify message from
930	   a downstream LSR than it MUST:

932	   - send a Notify message upstream toward the Notify
933	     node address that the LSR received in the Path message.
934	   - process the sub-group fields of the SENDER_TEMPLATE
935	     object on the received Notify message, and modify their values
936	     in the Notify message that is forwarded to match the sub-group
937	     field values in the original Path message received from upstream.

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

942	   2. Downstream Notification

944	   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
945	   object(s) of a Resv message to the value, that was received in the
946	   corresponding Path message. If the incoming Resv message carries a
947	   Notify Request object then the LSR MUST set the Notify node address
948	   in the Notify Request object to the value, that was received in the
949	   corresponding Path message, in the Resv message that it sends
950	   upstream.

952	   If this LSR subsequently receives a corresponding Notify message from
953	   an upstream LSR than it MUST:
954	   - send a Notify message downstream toward the Notify
955	     node address that the LSR received in the Resv message.
956	   - process the sub-group fields of the FILTER_SPEC object in the
957	     received Notify message, and modify their values in the Notify
958	     message that is forwarded to match the sub-group field values
959	     in the original Path message sent downstream by this LSR.

961	   The receiver of a (downstream) Notify message MUST identify the state
962	   referenced in the message based on the SESSION and FILTER_SPEC
963	   objects.

965	   The consequence of these rules for a P2MP LSP is that an upstream
966	   Notify message generated on a branch will result in a Notify being
967	   delivered to the upstream Notify node address. The receiver of the
968	   Notify message MUST NOT assume that the Notify message applies to all
969	   downstream egresses, but MUST examine the information in the message
970	   to determine to which egresses the message applies.

972	   Downstream Notify messages MUST be replicated at branch LSRs
973	   according to the Notify Request objects received on Resv messages.
974	   Some downstream branches might not request Notify messages, but all
975	   that have requested Notify messages MUST receive them

977	8.2. ResvConf Messages

979	   ResvConf messages are described in [RFC2205]. ResvConf processing in
980	   [RFC3473] and [RFC3209] is taken directly from [RFC2205]. An egress
981	   LSR may include a RESV_CONFIRM object that contains the egress LSR's
982	   address.  The object and message SHALL be supported for the
983	   confirmation of receipt of the Resv message in P2MP TE LSPs.
984	   Processing not detailed in this section MUST comply to [RFC2205].

986	   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
987	   object(s) of a Resv message to the value, that was received in the
988	   corresponding Path message. If any of the incoming Resv messages
989	   corresponding to a single Path message carry a RESV_CONFIRM object
990	   then the LSR MUST include a RESV_CONFIRM object in the corresponding
991	   Resv message that it sends upstream and MUST set the receiver address
992	   in the RESV_CONFIRM object to the value that was received in the
993	   corresponding Resv message.

995	   If this LSR subsequently receives a corresponding ResvConf message
996	   from an upstream LSR than it MUST:
997	   - send a ResvConf message downstream toward the receiver address that
998	     the LSR received in the RESV_CONFIRM object in the Resv message.
999	   - process the sub-group fields of the FILTER_SPEC object in the
1000	     received ResvConf message, and modify their values in the ResvConf
1001	     message that is forwarded to match the sub-group field values
1002	     in the original Path message sent downstream by this LSR.

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

1007	   The consequence of these rules for a P2MP LSP is that a ResvConf
1008	   message generated at the ingress will result in a ResvConf message
1009	   being delivered to the branch and then to the receiver address in the
1010	   original RESV_CONFIRM object. The receiver of a ResvConf message MUST
1011	   NOT assume that the ResvConf message should be sent to all downstream
1012	   egresses, but MUST replicate the message according to the
1013	   RESV_CONFIRM objects received in Resv messages. Some downstream
1014	   branches might not request ResvConf messages, and ResvConf messages
1015	   SHOULD NOT be sent on these branches. All downstream branches that do
1016	   requested ResvConf messages MUST be sent such a message.

1018	9. Refresh Reduction

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

1025	10. State Management

1027	   State signaled by a P2MP Path message is managed by a local
1028	   implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> as
1029	   part of the SESSION object and <Tunnel Sender Address, LSP ID, Sub-
1030	   Group Originator ID, Sub-Group ID> as part of the SENDER_TEMPLATE
1031	   object.

1033	   Additional information signaled in the Path/Resv message is part of
1034	   the state created by a local implementation. This includes PHOP/NHOP
1035	   and SENDER_TSPEC/FILTER_SPEC object.

1037	10.1. Incremental State Update

1039	   RSVP as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and
1040	   GMPLS [RFC3473] uses the same basic approach to state communication
1041	   and synchronization, namely full state is sent in each state
1042	   advertisement message. Per [RFC2205] Path and Resv messages are
1043	   idempotent. Also, [RFC2961] categorizes RSVP messages into two types:
1044	   trigger and refresh messages and improves RSVP message handling and
1045	   scaling of state refreshes but does not modify the full state
1046	   advertisement nature of Path and Resv messages. The full state
1047	   advertisement nature of Path and Resv messages has many benefits, but
1048	   also has some drawbacks. One notable drawback is when an incremental
1049	   modification is being made to a previously advertised state. In this
1050	   case, there is the message overhead of sending the full state and the
1051	   cost of processing it. It is desirable to overcome this drawback and
1052	   add/delete S2L sub-LSPs to a P2MP LSP by incrementally updating the
1053	   existing state.

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

1060	   As described in section 4.2, multiple Path messages can be used to
1061	   signal a P2MP LSP. The Path messages are distinguished by different
1062	   <Sub-Group Originator ID, sub-Group ID> tuples in the SENDER_TEMPLATE
1063	   object.  In order to perform incremental S2L sub-LSP state addition a
1064	   separate Path message with a new sub-Group ID is used to add the new
1065	   S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be
1066	   set to the TE Router ID [RFC3477] of the node that sets the Sub-Group
1067	   ID.

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

1073	10.2. Combining Multiple Path Messages

1075	   There is a tradeoff between the number of Path messages used by the
1076	   ingress to maintain the P2MP LSP and the processing imposed by full
1077	   state messages when adding S2L sub-LSPs to an existing Path message.
1078	   It is possible to combine S2L sub-LSPs previously advertised in
1079	   different Path messages in a single Path message in order to reduce
1080	   the number of Path messages needed to maintain the P2MP LSP. This can
1081	   also be done by a transit node that performed fragmentation and at a
1082	   later point is able to combine multiple Path messages that it
1083	   generated into a single Path message. This may happen when one or
1084	   more S2L sub-LSPs are pruned from the existing Path states.

1086	   The new Path message is signaled by the node that is combining
1087	   multiple Path messages with all the S2L sub-LSPs that are being
1088	   combined in a single Path message. This Path message MAY contain a
1089	   new Sub-Group ID field value.  When a new Path and Resv message that
1090	   is signaled for an existing S2L sub-LSP is received by a transit LSR,
1091	   state including the new instance of the S2L sub-LSP is created.

1093	   The S2L sub-LSP SHOULD continue to be advertised in both the old and
1094	   new Path messages until a Resv message listing the S2L sub-LSP and
1095	   corresponding to the new Path message is received by the combining
1096	   node. Hence until this point state for the S2L sub-LSP SHOULD be
1097	   maintained as part of the Path state for both the old and the new
1098	   Path message [Section 3.1.3, RFC2205]. At that point the S2L sub-LSP
1099	   SHOULD be deleted from the old Path state using the procedures of
1100	   section 7.

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

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

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

1118	11. Error Processing

1120	   PathErr and ResvErr messages are processed as per RSVP-TE procedures.
1121	   Note that an LSR on receiving a PathErr/ResvErr message for a
1122	   particular S2L sub-LSP changes the state only for that S2L sub-LSP.
1123	   Hence other S2L sub-LSPs are not impacted. If the ingress node
1124	   requests the maintenance of the 'LSP integrity', any error reported
1125	   within the P2MP TE LSP must be reported to (at least) any other
1126	   branching nodes belonging to this LSP. Therefore, reception of an
1127	   error message for a particular S2L sub-LSP MAY change the state of
1128	   any other S2L sub- LSP of the same P2MP TE LSP.

1130	11.1. PathErr Messages

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

1135	   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1136	                             [ [<MESSAGE_ID_ACK> |
1137	                                <MESSAGE_ID_NACK>] ... ]
1138	                             [ <MESSAGE_ID> ]
1139	                             <SESSION> <ERROR_SPEC>
1140	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1141	                             [ <POLICY_DATA> ... ]
1142	                             <sender descriptor>
1143	                             [ <S2L sub-LSP descriptor list> ]

1145	   PathErr messages generation is unmodified, but nodes that set the
1146	   Sub-Group Originator field and propagate a received PathErr message
1147	   upstream MUST replace the Sub-Group fields received in the PathErr
1148	   message with the value that was received in the Sub-Group fields of
1149	   the Path message from the upstream neighbor.  Note the receiver of a
1150	   PathErr message is able to identify the errored outgoing Path
1151	   message, and outgoing interface, based on the Sub-Group fields
1152	   received in the PathErr message.

1154	11.2. ResvErr Messages

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

1159	   <ResvErr Message> ::=    <Common Header> [ <INTEGRITY> ]
1160	                             [ [<MESSAGE_ID_ACK> |
1161	                                <MESSAGE_ID_NACK>] ... ]
1162	                             [ <MESSAGE_ID> ]
1163	                             <SESSION> <RSVP_HOP>
1164	                             <ERROR_SPEC> [ <SCOPE> ]
1165	                             [ <ACCEPTABLE_LABEL_SET> ... ]
1166	                             [ <POLICY_DATA> ... ]
1167	                             <STYLE> <flow descriptor list>

1169	   ResvErr messages generation is unmodified, but nodes that set the
1170	   Sub-Group Originator field and propagate a received ResvErr message
1171	   downstream MUST replace the Sub-Group fields received in the ResvErr
1172	   message with the value that was set in the Sub-Group fields of the
1173	   Path message sent to the downstream neighbor. Note the receiver of a
1174	   ResvErr message is able to identify the errored outgoing Path
1175	   message, and outgoing interface, based on the Sub-Group fields
1176	   received in the ResvErr message.

1178	11.3. Branch Failure Handling

1180	   During setup and during normal operation, PathErr messages may be
1181	   received at a branch node. In all cases, a received PathErr message
1182	   is first processed per standard processing rules. That is: the
1183	   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
1184	   Path message.  Intermediate nodes until this ingress/branch LSR MAY
1185	   inspect this message but take no action upon it. The behavior of a
1186	   branch LSR that generates a PathErr message is under the control of
1187	   the ingress LSR.

1189	   The default behavior is that the PathErr message does not have the
1190	   Path_State_Removed flag set. However, if the ingress LSR has set the
1191	   LSP integrity flag on the Path message (see LSP_REQUIRED_ATTRIBUTEs
1192	   object in section 5.2.4) and if the Path_State_Removed flag is
1193	   supported, the LSR generating a PathErr to report the failure of a
1194	   branch of the P2MP LSP SHOULD set the Path_State_Removed flag.

1196	   A branch LSR that receives a PathErr message with the
1197	   Path_State_Removed flag set MUST act according to the wishes of the
1198	   ingress LSR. The default behavior is that the branch LSR clears the
1199	   Path_State_Removed flag on the PathErr and sends it further upstream.
1200	   It does not tear any other branches of the LSP. However, if the LSP
1201	   integrity flag is set on the Path message, the branch LSR MUST send
1202	   PathTear on all other downstream branches and send the PathErr
1203	   message upstream with the Path_State_Removed flag set.

1205	   A branch LSR that receives a PathErr message with the
1206	   Path_State_Removed flag clear MUST act according to the wishes of the
1207	   ingress LSR. The default behavior is that the branch LSR forwards the
1208	   PathErr upstream and takes no further action. However, if the LSP
1209	   integrity flag is set on the Path message, the branch LSR MUST send
1210	   PathTear on all downstream branches and send the PathErr upstream
1211	   with the Path_State_Removed flag set (per [RFC3473]).

1213	   In all cases, the PathErr message forwarded by a branch LSR MUST
1214	   contain the S2L sub-LSP identification and explicit routes of all
1215	   branches that are reported by received PathErr messages and all
1216	   branches that are explicitly torn by the branch LSR.

1218	12. Admin Status Change

1220	   A branch node that receives an ADMIN_STATUS object processes it
1221	   normally and also relays the ADMIN_STATUS object in a Path on every
1222	   branch. All Path messages may be concurrently sent to the downstream
1223	   neighbors.

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

1232	13. Label Allocation on LANs with Multiple Downstream Nodes

1234	   A sender on a LAN uses a different label for sending traffic to each
1235	   node on the LAN that belongs to the P2MP LSP. Thus the sender
1236	   performs replication. It may be considered desirable on a LAN to use
1237	   the same label for sending traffic to multiple nodes belonging to the
1238	   same P2MP LSP, to avoid replication. Procedures for doing this are
1239	   for further study.

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

1243	   It is possible to change the path used by P2MP LSPs to reach the
1244	   destinations of the P2MP Tunnel. There are two methods that can be
1245	   used to accomplish this. The first is make-before-break, defined in
1246	   [RFC3209], and the second uses the sub-groups defined above.

1248	14.1. Make-before-break

1250	   In this case all the S2L sub-LSPs are signaled with a different LSP
1251	   ID by the ingress-LSR and follow make-before-break procedure defined
1252	   in [RFC3209]. Thus a new P2MP LSP is established. Each S2L sub-LSP is
1253	   signaled with a different LSP ID, corresponding to the new P2MP LSP.
1254	   After moving traffic to the new P2MP LSP, the ingress can tear down
1255	   the old P2MP LSP. This procedure can be used to re-optimize the path
1256	   of the entire P2MP LSP or paths to a subset of the destinations of
1257	   the P2MP LSP. When modifying just a portion of the P2MP LSP this
1258	   approach requires the entire P2MP LSP to be resignaled.

1260	14.2. Sub-Group Based Re-optimization

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

1266	   To alter the path taken by a particular set of S2L sub-LSPs the node
1267	   initiating the path change initiates one or more separate Path
1268	   messages, for the same P2MP LSP, each with a new sub-Group ID. The
1269	   generation of these Path messages, each with one or more S2L sub-
1270	   LSPs, follows procedures in section 5.2. As is the case in Section
1271	   10.2, a particular egress continues to be advertised in both the old
1272	   and new Path messages until a Resv message listing the egress and
1273	   corresponding to the new Path message is received by the re-
1274	   optimizing node. At that point the egress SHOULD be deleted from the
1275	   old Path state using the procedures of section 7.  Sub-tree re-
1276	   optimization is then completed.

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

1281	15. Fast Reroute

1283	   [RFC4090] extensions can be used to perform fast reroute for the
1284	   mechanism described in this document. This section uses terminology
1285	   defined in [RFC4090] and fast reroute procedures defined in [RFC4090]
1286	   MUST be followed unless specified below. The head-end and transit
1287	   LSRs MUST follow the SESSION_ATTRIBUTE and FAST_REROUTE object
1288	   processing as specified in [RFC4090] for each Path message and S2L
1289	   sub-LSP of a P2MP LSP. Each S2L sub-LSP of a P2MP LSP MUST have the
1290	   same protection characteristics. The RRO processing MUST apply to
1291	   SRRO as well unless modified below.

1293	15.1. Facility Backup

1295	   Facility backup can be used for link or node protection of LSRs on
1296	   the path of a P2MP LSP. The downstream labels MUST be learned by the
1297	   PLR as specified in [RFC4090] from the label corresponding to the S2L
1298	   sub-LSP in the RESV message. SERO processing for SEROs signaled in a
1299	   backup tunnel MUST follow backup tunnel ERO processing described in
1300	   [RFC4090].

1302	15.1.1. Link Protection

1304	   If link protection is desired, a bypass tunnel MUST be used to
1305	   protect the link between the PLR and next-hop. Thus all S2L sub-LSPs
1306	   that use the link MUST be protected in the event of link failure.
1307	   Note that all such S2L sub-LSPs belonging to a particular instance of
1308	   a P2MP tunnel will share the same outgoing label on the link between
1309	   the PLR and the next-hop. This is the P2MP LSP label on the link.
1310	   Label stacking is used to send data for each P2MP LSP into the bypass
1311	   tunnel. The inner label is the P2MP LSP label allocated by the next-
1312	   hop. During failure Path messages for each S2L sub-LSP, that are
1313	   effected, MUST be sent to the MP, by the PLR. It is recommended that
1314	   the PLR use the sender template specific method to identify these
1315	   Path messages. Hence the PLR will set the source address in the
1316	   sender template to a local PLR address. The MP MUST use the LSP-ID to
1317	   identify the corresponding S2L sub-LSPs. The MP MUST not use the
1318	   <sub-group originator ID, sub-group ID> while identifying the
1319	   corresponding S2L sub-LSPs. In order to further process a S2L sub-LSP
1320	   the MP MUST determine the protected S2L sub-LSP using the LSP-id and
1321	   the <S2L_SUB_LSP> object.

1323	15.1.2. Node Protection

1325	   If node protection is desired the PLR MUST use one or more P2P bypass
1326	   tunnels to protect the set of S2L sub-LSPs that transit the protected
1327	   node. Each of these P2P bypass tunnels MUST intersect the path of the
1328	   S2L sub-LSPs that they protect on a LSR that is downstream from the
1329	   protected node. This constrains the set of S2L sub-LSPs being backed
1330	   up via that bypass tunnel to those S2L sub-LSPs that pass through a
1331	   common downstream MP. This MP is the destination of the bypass
1332	   tunnel. The MP MUST allocate the same label to all such S2L sub-LSPs
1333	   belonging to a particular P2MP LSP. This is the inner label used
1334	   during label stacking by the PLR when it sends data for each P2MP LSP
1335	   into the bypass tunnel. The outer label is the bypass tunnel label.

1337	   After detecting failure of the protected node the PLR MUST send a
1338	   Path message for each protected S2L sub-LSP to the MP of the
1339	   protected S2L sub-LSP. It is recommended that the PLR use the sender
1340	   template specific method to identify these Path messages. Hence the
1341	   PLR will set the source address in the sender template to a local PLR
1342	   address. The MP MUST use the LSP-ID to identify the corresponding S2L
1343	   sub-LSPs. The MP MUST not use the <sub-group originator ID, sub-group
1344	   ID> while identifying the corresponding S2L sub-LSPs. In order to
1345	   further process a S2L sub-LSP the MP MUST determine the protected S2L
1346	   sub-LSP using the LSP-id and the <S2L_SUB_LSP> object.

1348	   Note that node protection MAY require the PLR to be branch capable in
1349	   the data plane as multiple bypass tunnels may be required to backup
1350	   the set of S2L sub-LSPs passing through the protected node. If the
1351	   PLR is not branch capable, the node protection mechanism described
1352	   here is applicable to only those cases where all the S2L sub-LSPs
1353	   passing through the protected node also pass through a single MP that
1354	   is downstream from the protected node. Procedures for node protection
1355	   when a PLR is not branch capable and all the protected S2L sub-LSPs
1356	   do not pass through a single MP that is downstream from the protected
1357	   node are for further study. It is also to be noted that procedures in
1358	   this section require P2P bypass tunnels. Procedures for using P2MP
1359	   bypass tunnels are for further study.

1361	15.2. One to One Backup

1363	   One to one backup as described in [RFC4090] can be used to protect a
1364	   particular S2L sub-LSP against link and next-hop failure. Protection
1365	   may be used for one or more S2L sub-LSPs between the PLR and the
1366	   next-hop. All the S2L sub-LSPs corresponding to the same instance of
1367	   the P2MP tunnel, between the PLR and the next-hop share the same P2MP
1368	   LSP label.

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

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

1377	   Its is recommended that the path specific method be used to identify
1378	   a backup S2L sub-LSP. Hence the DETOUR object SHOULD be inserted in
1379	   the backup Path message. A backup S2L sub-LSP MUST be treated as
1380	   belonging to a different P2MP tunnel instance than the one specified
1381	   by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be
1382	   treated as part of the same P2MP tunnel instance if they have the
1383	   same LSP-id and the same DETOUR objects. Note that as specified in
1384	   section 4 S2L sub-LSPs between different P2MP tunnel instances use
1385	   different labels.

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

1391	16. Support for LSRs that are not P2MP Capable

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

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

1406	   LSRs that do not support the P2MP extensions in this document may be
1407	   included as transit LSRs by the use of LSP-stitching [LSP-STITCH] and
1408	   LSP-hierarchy [RFC4206]. Note that LSRs that are required to play any
1409	   other role in the network (ingress, branch or egress) MUST support
1410	   the extensions defined in this document.

1412	   The use of LSP-stitching and LSP-hierarchy [RFC4206] allows P2MP LSPs
1413	   to be built in such an environment. A P2P LSP segment is signaled
1414	   from the last P2MP capable hop upstream of a legacy LSR to the first
1415	   P2MP capable hop downstream of it. This assumes that intermediate
1416	   legacy LSRs are transit LSRs: they cannot act as P2MP branch points.

1418	   Transit LSRs along this LSP segment do not process control plane
1419	   messages associated with the P2MP LSP.  Furthermore, these transit
1420	   LSRs also do not need to have P2MP data plane capabilities as they
1421	   only need to process data belonging to the P2P LSP segment. Hence
1422	   these transit LSRs do not need to support P2MP MPLS. This P2P LSP
1423	   segment is stitched to the incoming P2MP LSP. After the P2P LSP
1424	   segment is established the P2MP Path message is sent to the next P2MP
1425	   capable LSR as a directed Path message. The next P2MP capable LSR
1426	   stitches the P2P LSP segment to the outgoing P2MP LSP.

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

1433	   It may be an overhead for an operator to configure the P2P LSP
1434	   segments in advance, when it is desired to support legacy LSRs. It
1435	   may be desirable to do this dynamically. The ingress can use IGP
1436	   extensions to determine non P2MP capable LSRs [TE-NODE-CAP]. It can
1437	   use this information to compute S2L sub-LSP paths such that they
1438	   avoid these legacy LSRs. The explicit route object of a S2L sub-LSP
1439	   path may contain loose hops if there are legacy LSRs along the path.
1440	   The corresponding explicit route contains a list of objects upto the
1441	   P2MP capable LSR that is adjacent to a legacy LSR followed by a loose
1442	   object with the address of the next P2MP capable LSR. The P2MP
1443	   capable LSR expands the loose hop using its TED. When doing this it
1444	   determines that the loose hop expansion requires a P2P LSP to tunnel
1445	   through the legacy LSR. If such a P2P LSP exists, it uses that P2P
1446	   LSP. Else it establishes the P2P LSP.  The P2MP Path message is sent
1447	   to the next P2MP capable LSR using non-adjacent signaling. The P2MP
1448	   capable LSR that initiates the non-adjacent signaling message to the
1449	   next P2MP capable LSR may have to employ a fast detection mechanism
1450	   such as [BFD] [BFD-MPLS] to the next P2MP capable LSR.

1452	   This may be needed for the directed Path message Head-End to use node
1453	   protection FRR when the protected node is the directed Path message
1454	   tail.

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

1459	17. Reduction in Control Plane Processing with LSP Hierarchy

1461	   It is possible to take advantage of LSP hierarchy [RFC4206] while
1462	   setting up P2MP LSP, as described in the previous section, to reduce
1463	   control plane processing along transit LSRs that are P2MP capable.
1464	   This is applicable only in environments where LSP hierarchy can be
1465	   used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP,
1466	   do not process control plane messages associated with the P2MP LSP.
1467	   Infact they are not aware of these messages as they are tunneled over
1468	   the P2P LSP segment. This reduces the amount of control plane
1469	   processing required on these transit LSRs.

1471	   Note that the P2P LSPs be dynamically setup as described in the
1472	   previous section or preconfigured. For example in Figure 2, PE1 can
1473	   setup a P2P LSP to P1 and use that as a LSP segment. The Path
1474	   messages for PE3 and PE4 can now be tunneled over the LSP segment.
1475	   Thus P3 is not aware of the P2MP LSP and does not process the P2MP
1476	   control messages.

1478	18. P2MP LSP Remerging and Cross-Over

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

1483	   This section details the procedures for detecting and dealing with
1484	   re-merge and cross-over. The term re-merge refers to the case of an
1485	   ingress or transit node that creates a branch of a P2MP LSP, a re-
1486	   merge branch, which intersects the P2MP LSP at another node farther
1487	   down the tree.  This may occur due to such events as an error in path
1488	   calculation, an error in manual configuration, or network topology
1489	   changes during the establishment of the P2MP LSP.  If the procedures
1490	   detailed in this section are not followed, data duplication will
1491	   result.

1493	   The term cross-over refers to the case of an ingress or transit node
1494	   that creates a branch of a P2MP LSP, a cross-over branch, which
1495	   intersects the P2MP LSP at another node farther down the tree. It is
1496	   unlike re-merge in that at the intersecting node the cross-over
1497	   branch has a different outgoing interface as well as a different
1498	   incoming interface.  This may be necessary in certain combinations of
1499	   topology and technology; e.g., in a transparent optical network in
1500	   which different wavelengths are required to reach different leaf
1501	   nodes.

1503	   Normally, a P2MP LSP has a single incoming interface on which all of
1504	   the Path messages associated with that P2MP LSP are received.  The
1505	   incoming interface is identified by the IF_ID RSVP_HOP Object, if
1506	   present, and by interface over which the Path message was received if
1507	   the IF_ID RSVP_HOP Object is not present.  However, in the case of
1508	   dynamic LSP re-routing, the incoming interface may change.

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

1515	   (Make-before-break represents yet another similar but different case,
1516	   in that the incoming interface associated with the make-before-break
1517	   P2MP LSP may be different than that associated with the original P2MP
1518	   LSP.  However, the two P2MP LSPs will be treated as distinct, but
1519	   related, LSPs because they will have different LSP ID field values in
1520	   their SENDER_TEMPLATE objects.)

1522	18.1. Procedures

1524	   When a node receives a Path message, it MUST check whether it has
1525	   matching state for the P2MP LSP. Matching state is identified by
1526	   comparing the SESSION and SENDER_TEMPLATE objects in the received
1527	   Path message with the SESSION and SENDER_TEMPLATE objects of each
1528	   locally maintained P2MP LSP Path state. The P2MP ID, Tunnel ID, and
1529	   Extended Tunnel ID in the SESSION Object and the sender address and
1530	   LSP ID in the SENDER_TEMPLATE object are used for the comparison.  If
1531	   the node has matching state and the incoming interface for the
1532	   received Path message is different than the incoming interface of the
1533	   matching P2MP LSP Path state, then the node MUST determine whether it
1534	   is dealing with dynamic LSP rerouting or re-merge/cross-over.

1536	   Dynamic LSP rerouting is identified by checking whether there is any
1537	   intersection between the set of SUB-LSP objects associated with the
1538	   matching P2MP LSP Path state and the set of SUB-LSP objects in the
1539	   received Path message.  If there is any intersection, then dynamic
1540	   re-routing has occurred.  If there is no intersection between the two
1541	   sets of SUB-LSP objects, then either re-merge or cross-over has
1542	   occurred. (Note that in the case of dynamic LSP rerouting, Path
1543	   messages for the non-intersecting members of set of SUB-LSPs
1544	   associated with the matching P2MP LSP Path state will be received
1545	   subsequently on the new incoming interface.)

1547	   In order to identify the re-merge case, the node processing the
1548	   received Path message MUST identify the outgoing interfaces
1549	   associated with the matching P2MP Path state.  Re-merge has occurred
1550	   if there is any intersection between the set of outgoing interfaces
1551	   associated with the matching P2MP LSP Path state and the set of
1552	   outgoing interfaces in the received Path message.

1554	18.1.1. Re-Merge Procedures

1556	   There are two approaches to dealing with re-merge case.  In the
1557	   first, the node detecting the re-merge case, i.e., the re-merge node,
1558	   allows the re-merge case to persist but data from all but one
1559	   incoming interface is dropped at the re-merge node.  In the second,
1560	   the re-merge node initiates the removal of the re-merge branch(es)
1561	   via signaling.  Which approach is used is a matter of local policy.
1562	   A node MUST support both approaches and MUST allow user configuration
1563	   of which approach is to be used.

1565	   When configured to allow a re-merge case to persist, the re-merge
1566	   node MUST validate consistency between the objects included the
1567	   received Path message and the matching P2MP LSP Path state. Any
1568	   inconsistencies MUST result in an appropriate PathErr message sent to
1569	   the previous hop of the received Path message.  The Error Code is set
1570	   to "Routing Problem" and the Error Value is set to "P2MP Re-Merge
1571	   Parameter Mistmatch".

1573	   If there are no inconsistencies, the node logically merges, from the
1574	   downstream perspective, the control state of incoming Path message
1575	   with the matching P2MP LSP Path state.  Specifically, procedures
1576	   related to processing of messages received from upstream MUST NOT be
1577	   modified from the upstream perspective; this includes refresh and
1578	   state timeout related processing.  In addition to the standard
1579	   upstream related procedures, the node MUST ensure that each object
1580	   received from upstream is appropriately represented within the set of
1581	   Path messages sent downstream. For example, the received <S2L sub-LSP
1582	   descriptor list> MUST be included in the set of outgoing Path
1583	   messages. If there are any NOTIFY_REQUEST request objects present,
1584	   then the procedures defined in Section 8 MUST be followed for both
1585	   Path and Resv messages.  Special processing is also required for Resv
1586	   processing.  Specifically, any Resv message received from downstream
1587	   MUST be mapped into an outgoing Resv message that is sent to the
1588	   previous hop of the received Path message.  In practice, this
1589	   translates to decomposing the complete <S2L sub-LSP descriptor list>
1590	   into sub-sets that match the incoming Path messages and then
1591	   constructing an outgoing Resv message for each incoming Path message.

1593	   When configured to allow a re-merge case to persist, the re-merge
1594	   node receives data associated with the P2MP LSP on multiple incoming
1595	   interfaces, but it may only send the data from one of these
1596	   interfaces to its outgoing interfaces, i.e., the node MUST drop data
1597	   from all but one incoming interface.  This ensures that duplicate
1598	   data is not sent on any outgoing interface.  The mechanism used to
1599	   select the incoming interface to use is implementation specific and
1600	   is outside the scope of this document.

1602	   When configured to correct the re-merge branch via signaling, the re-
1603	   merge node MUST send a PathErr message corresponding to the received
1604	   Path message. The PathErr message MUST include all of the objects
1605	   normally included in a PathErr message, as well as one or more SUB-
1606	   LSP objects from the set of sub-LSPs associated with the matching
1607	   P2MP LSP Path state.  A minimum of three SUB-LSP objects is
1608	   RECOMMENDED. This will allow the node that caused the re-merge to
1609	   identify the outgoing Path state associated with the valid portion of
1610	   the P2MP LSP. The set of SUB-LSP objects in the received Path message
1611	   MUST also be included. The PathErr message MUST include the Error
1612	   Code "Routing Problem" and Error Value of "P2MP Remerge Detected".
1613	   The node MAY set the Path_State_Removed flag [RFC3473].  As is always
1614	   the case, the PathErr message is sent to the previous hop of the
1615	   received Path message.

1617	   A node that receives a PathErr message that contains the Error Value
1618	   "Routing Problem/P2MP Remerge Detected" MUST determine if it is the
1619	   node that created the re-merge case.  This is done by checking
1620	   whether there is any intersection between the set of SUB-LSP objects
1621	   associated with the matching P2MP LSP Path state and the set of SUB-
1622	   LSP objects in the received PathErr message.  If there is, then the
1623	   node created the re-merge case.

1625	   The node SHOULD remove the re-merge case by moving the SUB-LSP
1626	   objects included in the Path message associated with the received
1627	   PathErr message to the outgoing interface associated with the
1628	   matching P2MP LSP Path state.  A trigger Path message for the moved
1629	   SUB-LSP objects is then sent via that outgoing interface.  If the
1630	   received PathErr message did not have the Path_State_Removed flag
1631	   set, the node SHOULD send a PathTear via the outgoing interface
1632	   associated with the re-merge branch.

1634	   If use of a new outgoing interface violates one or more SERO
1635	   constraint, then a PathErr message containing the associated egresses
1636	   and any identified SUB-LSP objects SHOULD be generated with the Error
1637	   Code "Routing Problem" and Error Value of "ERO Resulted in Remerge".

1639	   The only case where this process will fail is when all the listed
1640	   SUB-LSP objects are deleted prior to the PathErr message propagating
1641	   to the ingress.  In this case, the whole process will be corrected on
1642	   the next (refresh or trigger) transmission of the offending Path
1643	   message.

1645	19. New and Updated Message Objects

1647	   This section presents the RSVP object formats as modified by this
1648	   document.

1650	19.1. SESSION Object

1652	   A P2MP LSP SESSION object is used. This object uses the existing
1653	   SESSION C-Num. New C-Types are defined to accommodate a logical P2MP
1654	   destination identifier of the P2MP Tunnel. This SESSION object has a
1655	   similar structure as the existing point to point RSVP-TE SESSION
1656	   object.  However the destination address is set to the P2MP ID
1657	   instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs that
1658	   are part of the same P2MP LSP share the same SESSION object. This
1659	   SESSION object identifies the P2MP Tunnel.

1661	   The combination of the SESSION object, the SENDER_TEMPLATE object and
1662	   the <S2L_SUB_LSP> object, identifies each S2L sub-LSP. This follows
1663	   the existing P2P RSVP-TE notion of using the SESSION object for
1664	   identifying a P2P Tunnel which in turn can contain multiple LSPs,
1665	   each distinguished by a unique SENDER_TEMPLATE object.

1667	19.1.1. P2MP LSP Tunnel IPv4 SESSION Object

1669	   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

1671	       0                   1                   2                   3
1672	       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
1673	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1674	      |                       P2MP ID                                 |
1675	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1676	      |  MUST be zero                 |      Tunnel ID                |
1677	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1678	      |                      Extended Tunnel ID                       |
1679	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1681	   P2MP ID

1683	      A 32-bit identifier used in the SESSION object that remains
1684	      constant over the life of the P2MP tunnel. It encodes the
1685	      P2MP ID and identifies the set of destinations of the P2MP
1686	      Tunnel.

1688	   Tunnel ID
1689	      A 16-bit identifier used in the SESSION object that remains
1690	      constant over the life of the P2MP tunnel.

1692	   Extended Tunnel ID

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

1700	19.1.2. P2MP LSP Tunnel IPv6 SESSION Object

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

1706	   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 14

1708	       0                   1                   2                   3
1709	       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
1710	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1711	      |                       P2MP ID                                 |
1712	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1713	      |  MUST be zero                 |      Tunnel ID                |
1714	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1715	      |                      Extended Tunnel ID (16 bytes)            |
1716	      |                                                               |
1717	      |                             .......                           |
1718	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1720	19.2. SENDER_TEMPLATE object

1722	   The SENDER_TEMPLATE object contains the ingress-LSR source address.
1723	   LSP ID can be can be changed to allow a sender to share resources
1724	   with itself. Thus multiple instances of the P2MP tunnel can be
1725	   created, each with a different LSP ID. The instances can share
1726	   resources with each other, but use different labels. The S2L sub-LSPs
1727	   corresponding to a particular instance use the same LSP ID.

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

1735	19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

1737	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

1739	       0                   1                   2                   3
1740	       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
1741	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1742	      |                   IPv4 tunnel sender address                  |
1743	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1744	      |       Reserved                |            LSP ID             |
1745	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1746	      |                   Sub-Group Originator ID                     |
1747	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1748	      |       Reserved                |            Sub-Group ID       |
1749	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1751	        IPv4 tunnel sender address
1752	            See [RFC3209]

1754	        Sub-Group Originator ID
1755	            The Sub-Group Originator ID is set to the TE Router ID of
1756	            the LSR that originates the Path message. This is either the
1757	            ingress LSR or a LSR which re-originates the Path message
1758	            with its own Sub-Group Originator ID.

1760	        Sub-Group ID
1761	            An identifier of a Path message used to differentiate
1762	            multiple Path messages that signal state for the same P2MP
1763	            LSP. This may be seen as identifying a group of one or more
1764	            egress nodes targeted by this Path message.

1766	        LSP ID
1767	           See [RFC3209]

1769	19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

1771	   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

1773	       0                   1                   2                   3
1774	       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
1775	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1776	      |                                                               |
1777	      +                                                               +
1778	      |                   IPv6 tunnel sender address                  |
1779	      +                                                               +
1780	      |                            (16 bytes)                         |
1781	      +                                                               +
1782	      |                                                               |
1783	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1784	      |       Reserved                |            LSP ID             |
1785	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1786	      |                                                               |
1787	      +                                                               +
1788	      |                   Sub-Group Originator ID                     |
1789	      +                                                               +
1790	      |                            (16 bytes)                         |
1791	      +                                                               +
1792	      |                                                               |
1793	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1794	      |       Reserved                |            Sub-Group ID       |
1795	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1797	        IPv6 tunnel sender address
1798	           See [RFC3209]

1800	        Sub-Group Originator ID
1801	            The Sub-Group Originator ID is set to the IPv6 TE Router ID
1802	            of the LSR that originates the Path message. This is either
1803	            the ingress LSR or a LSR which re-originates the Path
1804	            message with its own Sub-Group Originator ID.

1806	        Sub-Group ID
1807	           As above in section 19.2.1.

1809	        LSP ID
1810	           See [RFC3209]

1812	19.3. <S2L_SUB_LSP> Object

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

1817	19.3.1. <S2L_SUB_LSP> IPv4 Object

1819	   SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1

1821	       0                   1                   2                   3
1822	       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
1823	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1824	      |                   IPv4 S2L Sub-LSP destination address        |
1825	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1827	   IPv4 Sub-LSP destination address

1829	      IPv4 address of the S2L sub-LSP destination.

1831	19.3.2. <S2L_SUB_LSP> IPv6 Object

1833	   SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2

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

1838	       0                   1                   2                   3
1839	       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
1840	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1841	      |        IPv6 S2L Sub-LSP destination address (16 bytes)        |
1842	      |                        ....                                   |
1843	      |                                                               |
1844	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1846	19.4. FILTER_SPEC Object

1848	   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
1849	   object.

1851	19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object

1853	   Class = FILTER SPEC, P2MP LSP_IPv4 C-Type = 12

1855	   The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
1856	   the P2MP LSP_IPv4 SENDER_TEMPLATE object.

1858	19.4.2. P2MP LSP_IPv4 FILTER_SPEC Object

1860	   Class = FILTER SPEC, P2MP LSP_IPv6 C-Type = 13

1862	   The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
1863	   the P2MP LSP_IPv6 SENDER_TEMPLATE object.

1865	19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

1867	   The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as
1868	   identical to the ERO. The class of the P2MP SERO is the same as the
1869	   SERO defined in [RECOVERY]. The P2MP SERO uses a new C-Type = 2. The
1870	   sub-objects are identical to those defined for the ERO.

1872	19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

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

1879	20. IANA Considerations

1881	20.1. New Class Numbers

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

1889	   50  Class Name = SUB_LSP

1891	   C-Type
1892	      1   S2L_SUB_LSP_IPv4 C-Type
1893	      2   S2L_SUB_LSP_IPv6 C-Type

1895	20.2. New Class Types

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

1899	   Class Name = SESSION

1901	   C-Type
1902	     13    P2MP_LSP_IPv4 C-Type
1903	     14    P2MP_LSP_IPv6 C-Type

1905	   Class Name = SENDER_TEMPLATE

1907	   C-Type
1908	     12    P2MP_LSP_IPv4 C-Type
1909	     13    P2MP_LSP_IPv6 C-Type

1911	   Class Name = FILTER_SPEC

1913	   C-Type
1914	     12    P2MP LSP_IPv4 C-Type
1915	     13    P2MP LSP_IPv6 C-Type

1917	   Class Name = SECONDARY_EXPLICIT_ROUTE

1919	   C-Type
1920	      2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type

1922	   Class Name = SECONDARY_RECORD_ROUTE

1924	   C-Type
1925	      2  P2MP_SECONDARY_RECORD_ROUTE C-Type

1927	20.3. New Error Values

1929	   Four new Error Values are defined for use with the Error Code
1930	   "Routing Problem". IANA is requested to assign values.

1932	   The Error Value "Unable to Branch" indicates that a P2MP branch
1933	   cannot be formed by the reporting LSR. IANA is requested to assign
1934	   value 23 to this Error Value.

1936	   The Error Value "Unsupported LSP Integrity" indicates that a P2MP
1937	   branch does not support the requested LSP integrity function. IANA is
1938	   requested to assign value 24 to this Error Value.

1940	   The Error Value "P2MP Remerge Detected" indicates that a node has
1941	   detected remerge. IANA is requested to assign value 25 to this Error
1942	   Value.

1944	   The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
1945	   section 18. IANA is requested to assign value 26 to this Error Value.

1947	   The Error Value "ERO Resulted in Remerge" is described in section 18.
1948	   IANA is requested to assign value 27 to this Error Value.

1950	20.4. LSP Attributes Flags

1952	   IANA has been asked to manage the space of flags in the Attibutes
1953	   Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [LSP-ATTR].
1954	   This document defines a new flag as follows:

1956	   Suggested Bit Number:             3
1957	   Meaning:                          LSP Integrity Required
1958	   Used in Attributes Flags on Path: Yes
1959	   Used in Attributes Flags on Resv: No
1960	   Used in Attributes Flags on RRO:  No
1961	   Referenced Section of this Doc:   10

1963	21. Security Considerations

1965	   This document does not introduce any new security issues. The
1966	   security issues identified in [RFC3209] and [RFC3473] are still
1967	   relevant.

1969	22. Acknowledgements

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

1974	   Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal
1975	   Sheth for their suggestions and comments. Thanks also to Dino
1976	   Farninacci for his comments.

1978	23. Appendix

1980	23.1. Example

1982	   Following is one example of setting up a P2MP LSP using the
1983	   procedures described in this document.

1985	                   Source 1 (S1)
1986	                     |
1987	                    PE1
1988	                   |   |
1989	                   |L5 |
1990	                   P3  |
1991	                   |   |

1993	                L3 |L1 |L2
1994	       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
1995	                  | L4
1996	          PE5----PE4----R3
1997	                  |
1998	                  |
1999	                 R4

2001	                Figure 2.

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

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

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

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

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

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

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

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

2027	   e) P1 receives a Resv message from PE4 with label L4. It had
2028	   previously received a Resv message from PE3 with label L3. It had
2029	   allocated a label L1 for the sub-LSP to PE3. It uses the same label
2030	   and sends the Resv messages to P3. Note that it may send only one
2031	   Resv message with multiple flow descriptors in the flow descriptor
2032	   list. If this is the case and FF style is used, the FF flow
2033	   descriptor will contain the S2L sub-LSP descriptor list with two
2034	   entries: one for PE4 and the other for PE3. For SE style, the SE
2035	   filter spec will contain this S2L sub-LSP descriptor list. P1 also
2036	   creates a label mapping of (L1 -> {L3, L4}). P3 uses the existing
2037	   label L5 and sends the Resv message to PE1, with label L5. It reuses
2038	   the label mapping of {L5 -> L1}.

2040	24. References

2042	24.1. Normative References

2044	   [RFC4206] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
2045	             MPLS TE" [RFC4206]

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

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

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

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

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

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

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

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

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

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

2088	   [RFC4461] S. Yasukawa, Editor "Signaling Requirements for
2089	             Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.

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

2094	24.2. Informative References

2096	   [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
2097	         draft-ietf-bfd-02.txt, work in progress.

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

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

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

2109	   [INT-REG]  A. Farrel, J.P. Vasseur, and A. Ayyangar, "A Framework for
2110	              Inter-Domain MPLS Traffic Engineering",
2111	              draft-ietf-ccamp-inter-domain-framework-04.txt, work in
2112	              progress.

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

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

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

2128	   [RFC4003]     L. Berger, "GMPLS Signaling Procedure for Egress
2129	                 Control", February, 2005.

2131	25. Author Information

2133	25.1. Editor Information

2135	   Rahul Aggarwal
2136	   Juniper Networks
2137	   1194 North Mathilda Ave.
2138	   Sunnyvale, CA 94089
2139	   Email: rahul@juniper.net

2141	   Seisho Yasukawa
2142	   NTT Corporation
2143	   9-11, Midori-Cho 3-Chome
2144	   Musashino-Shi, Tokyo 180-8585 Japan
2145	   Phone: +81 422 59 4769
2146	   EMail: yasukawa.seisho@lab.ntt.co.jp

2148	   Dimitri Papadimitriou
2149	   Alcatel
2150	   Francis Wellesplein 1,
2151	   B-2018 Antwerpen, Belgium
2152	   Phone: +32 3 240-8491
2153	   Email: Dimitri.Papadimitriou@alcatel.be

2155	25.2. Contributor Information

2157	   John Drake
2158	   Boeing
2159	   Email: john.E.Drake2@boeing.com

2161	   Alan Kullberg
2162	   Motorola Computer Group
2163	   120 Turnpike Road 1st Floor
2164	   Southborough, MA  01772
2165	   EMail: alan.kullberg@motorola.com

2167	   Lou Berger
2168	   Movaz Networks, Inc.
2169	   7926 Jones Branch Drive
2170	   Suite 615
2171	   McLean VA, 22102
2172	   Phone: +1 703 847-1801
2173	   EMail: lberger@movaz.com

2175	   Liming Wei
2176	   Redback Networks
2177	   350 Holger Way
2178	   San Jose, CA 95134
2179	   Email: lwei@redback.com

2181	   George Apostolopoulos
2182	   Redback Networks
2183	   350 Holger Way
2184	   San Jose, CA 95134
2185	   Email: georgeap@redback.com

2187	   Kireeti Kompella
2188	   Juniper Networks
2189	   1194 N. Mathilda Ave
2190	   Sunnyvale, CA 94089
2191	   Email: kireeti@juniper.net

2193	   George Swallow
2194	   Cisco Systems, Inc.
2195	   300 Beaver Brook Road
2196	   Boxborough , MA - 01719
2197	   USA
2198	   Email: swallow@cisco.com

2200	   JP Vasseur
2201	   Cisco Systems, Inc.
2202	   300 Beaver Brook Road
2203	   Boxborough , MA - 01719
2204	   USA
2205	   Email: jpv@cisco.com

2207	   Dean Cheng
2208	   Cisco Systems Inc.
2209	   170 W Tasman Dr.
2210	   San Jose, CA 95134
2211	   Phone 408 527 0677
2212	   Email:  dcheng@cisco.com

2214	   Markus Jork
2215	   Avici Systems
2216	   101 Billerica Avenue
2217	   N. Billerica, MA 01862
2218	   Phone: +1 978 964 2142
2219	   EMail: mjork@avici.com

2221	   Hisashi Kojima
2222	   NTT Corporation
2223	   9-11, Midori-Cho 3-Chome
2224	   Musashino-Shi, Tokyo 180-8585 Japan
2225	   Phone: +81 422 59 6070
2226	   EMail: kojima.hisashi@lab.ntt.co.jp

2228	   Andrew G. Malis
2229	   Tellabs
2230	   2730 Orchard Parkway
2231	   San Jose, CA 95134
2232	   Phone: +1 408 383 7223
2233	   Email: Andy.Malis@tellabs.com

2235	   Koji Sugisono
2236	   NTT Corporation
2237	   9-11, Midori-Cho 3-Chome
2238	   Musashino-Shi, Tokyo 180-8585 Japan
2239	   Phone: +81 422 59 2605
2240	   EMail: sugisono.koji@lab.ntt.co.jp

2242	   Masanori Uga
2243	   NTT Corporation
2244	   9-11, Midori-Cho 3-Chome
2245	   Musashino-Shi, Tokyo 180-8585 Japan
2246	   Phone: +81 422 59 4804
2247	   EMail: uga.masanori@lab.ntt.co.jp

2249	   Igor Bryskin
2250	   Movaz Networks, Inc.
2251	   7926 Jones Branch Drive
2252	   Suite 615
2253	   McLean VA, 22102

2255	   Adrian Farrel
2256	   Old Dog Consulting
2257	   Phone: +44 0 1978 860944
2258	   EMail: adrian@olddog.co.uk

2260	   Jean-Louis Le Roux
2261	   France Telecom
2262	   2, avenue Pierre-Marzin
2263	   22307 Lannion Cedex
2264	   France
2265	   E-mail: jeanlouis.leroux@francetelecom.com

2267	26. Intellectual Property

2269	   The IETF takes no position regarding the validity or scope of any
2270	   Intellectual Property Rights or other rights that might be claimed to
2271	   pertain to the implementation or use of the technology described in
2272	   this document or the extent to which any license under such rights
2273	   might or might not be available; nor does it represent that it has
2274	   made any independent effort to identify any such rights.  Information
2275	   on the procedures with respect to rights in RFC documents can be
2276	   found in BCP 78 and BCP 79.

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

2285	   The IETF invites any interested party to bring to its attention any
2286	   copyrights, patents or patent applications, or other proprietary
2287	   rights that may cover technology that may be required to implement
2288	   this standard.  Please address the information to the IETF at ietf-
2289	   ipr@ietf.org.

2291	27. Full Copyright Statement

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

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

2305	28. Acknowledgement

2307	   Funding for the RFC Editor function is currently provided by the
2308	   Internet Society.