idnits 2.17.1 

draft-ietf-mpls-lsr-self-test-04.txt:

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

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

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

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

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

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

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

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


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

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents. 

  == The page length should not exceed 58 lines per page, but there was 12
     longer pages, the longest (page 2) being 59 lines


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

  ** The abstract seems to contain references ([RSVP-TE], [LSP-Ping], [LDP]),
     which it shouldn't.  Please replace those with straight textual mentions
     of the documents in question.


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

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

  == Line 355 has weird spacing: '...by this  when ...'

  -- 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 (February 2005) is 7000 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


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

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

  == Missing Reference: 'LDP' is mentioned on line 84, but not defined

  == Missing Reference: 'LSP-PING' is mentioned on line 244, but not defined

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

  ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-Ping'


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

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

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

1	Network Working Group                                     George Swallow
2	Internet Draft                                       Cisco Systems, Inc.
3	Category: Standards Track
4	Expiration Date: August 2005
5	                                                        Kireeti Kompella
6	                                                  Juniper Networks, Inc.

8	                                                              Dan Tappan
9	                                                     Cisco Systems, Inc.

11	                                                           February 2005

13	                    Label Switching Router Self-Test

15	                  draft-ietf-mpls-lsr-self-test-04.txt

17	Status of this Memo

19	   By submitting this Internet-Draft, the authors certify that any
20	   applicable patent or other IPR claims of which we are aware have been
21	   disclosed, and any of which we become aware will be disclosed, in
22	   accordance with RFC 3668.

24	   This document is an Internet-Draft and is in full conformance with
25	   all provisions of Section 5 of RFC3667.  Internet-Drafts are working
26	   documents of the Internet Engineering Task Force (IETF), its areas,
27	   and its working groups.  Note that other groups may also distribute
28	   working documents as Internet-Drafts.

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

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

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

41	Copyright Notice

43	   Copyright (C) The Internet Society (2005).

45	   Abstract
46	      This document defines a means of self test for a Label-Switching
47	      Router (LSR) to verify that its dataplane is functioning for
48	      certain key Multi-Protocol Label Switching (MPLS) applications
49	      including unicast forwarding based on LDP [LDP] and traffic
50	      engineering tunnels based on [RSVP-TE].  A new Loopback FEC type
51	      is defined to allow an upstream neighbor to assist in the testing
52	      at very low cost.  MPLS Echo Request and MPLS Echo Reply messages
53	      [LSP-Ping] are extended to do the actual probing.

55	Contents

57	 1      Introduction  ..............................................   3
58	 1.1    Conventions  ...............................................   3
59	 2      Loopback FEC  ..............................................   4
60	 2.1    Loopback FEC Element  ......................................   4
61	 2.2    LDP Procedures  ............................................   5
62	 3      Data Plane Self Test  ......................................   5
63	 3.1    Data Plane Verification Request / Reply Messages  ..........   6
64	 3.2    Reply-To Object  ...........................................   8
65	 3.2.1  IPv4 Reply-To Object  ......................................   8
66	 3.2.2  IPv6 Reply-To Object  ......................................   8
67	 3.3    Sending procedures  ........................................   9
68	 3.4    Receiving procedures  ......................................   9
69	 3.5    Upstream Neighbor Verification  ............................  10
70	 4      Security Considerations  ...................................  11
71	 5      IANA Considerations  .......................................  11
72	 6      Acknowledgments  ...........................................  11
73	 7      References  ................................................  11
74	 7.1    Normative References  ......................................  11
75	 7.2    Informative References  ....................................  12
76	 8      Authors' Addresses  ........................................  12
77	 9      Full Copyright and Intellectual Property Statements  .......  12

79	1. Introduction

81	   This document defines a means of self test for a Label-Switching
82	   Router (LSR) to verify that its dataplane is functioning for certain
83	   key Multi-Protocol Label Switching (MPLS) applications including uni-
84	   cast forwarding based on LDP [LDP] and traffic engineering tunnels
85	   based on [RSVP-TE].  MPLS Echo Request and MPLS Echo Reply messages
86	   [LSP-Ping] messages are extended to do the actual probing.  The pings
87	   are sent to an upstream neighbor, looped back through the LSR under
88	   test and intercepted, by means of TTL expiration by a downstream
89	   neighbor.  Extensions to LSP-Ping [LSP-Ping] are defined to allow the
90	   down stream neighbor to report the test results.

92	   In order to minimize the load on upstream LSRs a new loopback FEC is
93	   defined. Receipt of a packet labeled with a loopback label will cause
94	   the advertising LSR to pop the label off the label stack and send the
95	   packet out the advertised interface.

97	   Note that use of a loopback allows an LSR to test label entries for
98	   which the LSR is not currently some neighbor's next hop.  In this way
99	   label entries can be verified prior to the occurrence of a routing
100	   change.

102	   Some routing protocls, most notably OSPF have no means of exchanging
103	   the "Link Local Identifiers" used to identify unnumbered links and
104	   components of bundled links.  These test procedures can be used to
105	   associate the neighbor's interfaces with the probing LSRs interfaces.
106	   This is achieved by simply having the TTL of the MPLS Ping expire one
107	   hop sooner, i.e. at the testing LSR itself.

109	1.1. Conventions

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

115	2. Loopback FEC

117	   The Loopback FEC type is defined to enable an upstream neighbor to
118	   assist in LSR self-testing at very low cost.  This FEC causes the
119	   loopback to occur in the dataplane without control plane involvement
120	   beyond the initial LDP exchange and dataplane setup.

122	   An LSR uses the Loopback FEC to selectively advertise loopback labels
123	   to its neighbor LSRs.  Each loopback label is bound to a particular
124	   interface.  For multi-access links, a unique label for each neighbor
125	   is required, since the link-level address is derived from the label
126	   lookup.  When an MPLS packet with its top label set to a loopback
127	   label is received from an interface over which that label was adver-
128	   tised, the loopback label is popped and the packet is sent on the
129	   interface to which the loopback label was bound.

131	   TTL treatment for loopback labels follows the Uniform model.  I.e.
132	   the TTL carried in the loopback label is decremented and copied to
133	   the exposed label or IP header as the case may be.

135	2.1. Loopback FEC Element

137	   FEC element type 130 is used.   The FEC element is encoded as fol-
138	   lows: (note: 130 is provisionally assigned, the actual value will be
139	   assigned by IANA.)

141	       0                   1                   2                   3
142	       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
143	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
144	      |     130       |      Res      | Interface Type|   Id Length   |
145	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
146	      |                     Interface Identifier                      |
147	      |                              "                                |
148	      |                              "                                |
149	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

151	      Reserved (Res)

153	         Must be set to zero on transmission and ignored on receipt.

155	      Interface Type

157	            #     Type              Interface Identifier
158	           ---    ----              --------------------
159	            0     Unnumbered        A 32 bit Link Identifier as
160	                                      defined in [RFC3477]
161	            1     IPv4 Numbered     IPv4 Address
162	            2     IPv6 Numbered     IPv6 Address

164	      Identifier Length

166	         Length of the interface identifier in octets.  The length is 4
167	         bytes for Unnumbered and IPv4, 16 bytes for IPv6.

169	      Address

171	         An identifier encoded according to the Identifier Type field.

173	2.2. LDP Procedures

175	   It is RECOMMENDED that loopback labels only be distributed in
176	   response to a Label Request message, irrespective of the label adver-
177	   tisement mode of the LDP session.  However it is recognized that in
178	   certain cases such as OSPF with unnumbered links, the upstream LSR
179	   may not have sufficiently detailed information of the neighbor's link
180	   identifier to form the request.  In these cases, the downstream LSR
181	   will need to be configured to make unsolicited advertisements.

183	3. Data Plane Self Test

185	   A self test operation involves three LSRs, the LSR doing the test, an
186	   upstream neighbor and a downstream neighbor.  We refer to these as
187	   LSRs T, U, and D respectively.  In order to minimize the processing
188	   load on LSR-D, two new LSP Ping messages are defined, called the MPLS
189	   Data Plane Verification Request and the MPLS Data Plane Verification
190	   Reply.  These messages are used to allow LSR-T to obtain the label
191	   stack, address and interface information of LSR-D.

193	   If FEC verification is required, the MPLS Echo Request and Reply mes-
194	   sages are used.

196	   The packet flow is shown below. Although the figure shows LSR-D adja-
197	   cent to LSR-T it may in some cases be an arbitrary number of hops
198	   away.

200	                 +-------+       +-------+       +-------+
201	                 |     ,-|-------|<DPVRq |       |       |
202	                 |     `-|-------|-------|-------|->     |
203	                 |       |       |       |       |       |
204	                 |       |       |     <-|-------|<DPVRp |
205	                 +-------+       +-------+       +-------+
206	                   LSR-U           LSR-T           LSR-D

208	               DPVRq: MPLS Data Plane Verification Request
209	               DPVRp: MPLS Data Plane Verification Reply

211	                    Figure 1: Self Test Message Flow

213	   In order to perform a test on an incoming label stack, LSR-T forms an
214	   MPLS Data Plane Verification Request.  LSR-T prepends the packet with
215	   the incoming label stack being tested and the loopback label received
216	   from LSR-U.  The TTL values are set such that they will expire at
217	   LSR-D.  LSR-T then forwards the packet to LSR-U.

219	   LSR-U receives the packet and performs normal MPLS forwarding.  That
220	   is, the loopback label is popped, the TTL is decremented and propa-
221	   gated (in this case) to the exposed label.

223	   LSR-T receives the packet and performs normal MPLS forwarding.  If
224	   everything is functioning as expected this will cause the packet to
225	   arrive at LSR-D with a TTL of 1.

227	   In this example, we assume that all is working properly.  The TTL
228	   expires at LSR-D causing it to receive the packet.   LSR-D notes the
229	   the interface and the label stack on which the packet was received
230	   and records these in an Interface and Label Stack TLV.  This Object
231	   is sent to LSR-T in an MPLS Data Plane Verification Reply message.

233	3.1. Data Plane Verification Request / Reply Messages

235	   Two new LSP Ping messages are defined for LSR self test.  The purpose
236	   of the new messages is three fold.  First the timestamps are removed
237	   to minimize processing.  Second the message type allows simple recog-
238	   nition that minimal processing is necessary to service this request.
239	   Third, the Verification Request message itself conveys the the
240	   request, thus a Verification Request message with no Objects is both
241	   legal and normal.

243	   The definitions of all fields in the messages are identical to those
244	   found in [LSP-PING].

246	   The new message types are: (Provisionally; to be assigned)

248	      Type     Message
249	      ----     -------
250	        3      MPLS Data Plane Verification Request
251	        4      MPLS Data Plane Verification Reply

253	   The messages have the following format:

255	    0                   1                   2                   3
256	    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
257	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
258	   |         Version Number        |         Must Be Zero          |
259	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260	   |  Message Type |   Reply mode  |  Return Code  | Return Subcode|
261	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
262	   |                        Sender's Handle                        |
263	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
264	   |                        Sequence Number                        |
265	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
266	   |                            TLVs ...                           |
267	   .                                                               .
268	   .                                                               .
269	   .                                                               .
270	   |                                                               |
271	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

273	   The MPLS Data Plane Verification Request message MAY contain the fol-
274	   lowing objects:

276	          Type #            Object
277	          ------            -----------
278	            3               Pad
279	            5               Vendor Enterprise Code
280	           11 (tba)         IPv4 Reply-to Object
281	           12 (tba)         IPv6 Reply-to Object

283	   The MPLS Data Plane Verification Reply message MAY contain the fol-
284	   lowing objects:

286	          Type #            Object
287	          ------            -----------
288	            3               Pad
289	            4               Error Code
290	            5               Vendor Enterprise Code
291	            7               IPv4 Interface and Label Stack Object
292	            8               IPv6 Interface and Label Stack Object

294	3.2. Reply-To Object

296	   In order to perform detailed diagnostics of a particular failing flow
297	   in the face of ECMP, it is useful to be able to use the exact source
298	   and destination addresses of that flow.  The Reply-To Object is an
299	   optional TLV in a MPLS Data Plane Verification Request message.  The
300	   Object has two formats, type 9 for IPv4 and type 10 for IPv6 (to be
301	   assigned by IANA).

303	3.2.1. IPv4 Reply-To Object

305	   The length of an IPv4 Reply-To Object is 4 octets; the value field
306	   has the following format:

308	       0                   1                   2                   3
309	       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
310	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
311	      |                     Reply-to IPv4 Address                     |
312	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

314	      Reply-to IPv4 Address

316	         The address to which the MPLS Data Plane Verification Reply
317	         message is to be sent.

319	3.2.2. IPv6 Reply-To Object

321	   The length of an IPv6 Reply-To Object is 16 octets; the value field
322	   has the following format:

324	       0                   1                   2                   3
325	       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
326	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
327	      |                     Reply-to IPv6 Address                     |
328	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
329	      |                 Reply-to IPv6 Address (Cont.)                 |
330	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
331	      |                 Reply-to IPv6 Address (Cont.)                 |
332	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
333	      |                 Reply-to IPv6 Address (Cont.)                 |
334	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
335	      Reply-to IPv6 Address

337	         The address to which the MPLS Data Plane Verification Reply
338	         message is to be sent.

340	3.3. Sending procedures

342	   In order to perform a test on an incoming label stack, an LSR first
343	   determines the expected outgoing label stack, next hop router and
344	   next hop interface.

346	   The LSR creates an MPLS Data Plane Verification Request message and
347	   includes a Data Plane Verification Object.  Optionally a FEC Stack
348	   TLV may be included.  In this case an MPLS Echo Request Message MUST
349	   be used.

351	   In normal use, the source address is set to an address belonging to
352	   the LSR and the destination set to an address in the range of 127/8.
353	   The IP TTL SHOULD be set to 1.  The incoming label stack is prepended
354	   to the packet.  The TTL of these labels SHOULD be set to appropriate
355	   values - 2 for those labels which will be process by this  when the
356	   packet is looped back; 1 for those labels which will be carried
357	   through.  Finally the loopback label bound to the incoming interface
358	   is prepended to the packet.  The TTL is set such that it will have
359	   the value of 3 on the wire.

361	   The packet is sent to the upstream neighbor on an interface for which
362	   the loopback label is valid.

364	   In diagnostic situations, the source and destination addresses MAY be
365	   set to any value.  In this case, a Reply-to IPv4 or IPv6 Object MUST
366	   be included.  The IP TTL MUST be set to 1.  The TTL of labels other
367	   than the loopback label MUST be set to appropriate values - 2 for
368	   those labels which will be process by this LSR when the packet is
369	   looped back; 1 for those labels which will be carried through.

371	3.4. Receiving procedures

373	   An LSR X that receives an MPLS Verification Request message formats a
374	   MPLS Verification Reply message.  The Sender's Handle and Sequence
375	   Number are copied from the Request message.

377	   X then parses the packet to ensure that it is a well-formed packet,
378	   and that the TLVs that are not marked "Ignore" are understood.  If
379	   not, X SHOULD send an MPLS echo reply with the Return Code set to
380	   "Malformed echo request received" or "TLV not understood" (as appro-
381	   priate), and the Subcode set to zero.  In the latter case, the misun-
382	   derstood TLVs (only) are included in the reply.

384	   If the echo request is good, X notes the interface I over which the
385	   echo was received, and the label stack with which it came. If the
386	   MPLS echo request contained a Downstream Verification object, then X
387	   must format this information as a Downstream Verification object and
388	   include it in its MPLS echo reply message.

390	   The source address of the Reply message MUST be an address of the
391	   replying LSR.  If the request included a Reply-to IPv4 or IPv6
392	   Object, the MPLS Data Plane Verification Reply message MUST be sent
393	   to that address.  Otherwise the Reply message is sent to the source
394	   address of the Verification Request message.

396	   An LSR MUST be capable of filtering addresses that are to be replied
397	   to.  If a filter has been invoked (i.e. configured) and an address
398	   does not pass the filter, then a reply MUST NOT be sent, and the
399	   event SHOULD be logged.

401	3.5. Upstream Neighbor Verification

403	   To verify that an upstream neighbor is properly echoing packets an
404	   LSR may send an MPLS Data Plane Verification Request packet with the
405	   TTL set so that the packet will expire upon reaching reaching itself.
406	   This procedure not only tests that the neighbor is correctly process-
407	   ing the loopback label, it also allow the node to verify the neigh-
408	   bor's interface mapping.

410	                      +-------+       +-------+
411	                      |       |       |       |
412	                      |     ,-|-------|<DPVRq |
413	                      |     `-|-------|->     |
414	                      |       |       |       |
415	                      +-------+       +-------+
416	                        LSR-U           LSR-T

418	             DPVRq: MPLS Data Plane Verification Request

420	              Figure 2: Upstream Neighbor Verification

422	   No TLVs need to be included in the MPLS Data Plane Verification
423	   Request.  By noting the Sender's Handle and Sequence Number, as well
424	   as the loopback label, LSR-T is able to detect that a) the packet was
425	   looped, and b) determine (or verify) the interface on which the
426	   packet was received.

428	4. Security Considerations

430	   Were loopback labels widely known, they might be subject to abuse.
431	   It is therefore RECOMMENDED that loopback labels only be shared
432	   between trusted neighbors.  Further, if the loopback labels are drawn
433	   from the Global Label Space, or any other label space shared across
434	   multiple LDP sessions, it is RECOMMENDED that all loopback labels be
435	   filtered from a session except those labels pertaining to interfaces
436	   directly connected to the neighbor participating in that session.

438	5. IANA Considerations

440	   TBD

442	6. Acknowledgments

444	   The authors would like to thank Vanson Lim, Tom Nadeau, and Bob
445	   Thomas for their comments and suggestions.

447	7. References

449	7.1. Normative References

451	   [RFC3036]  Andersson, L. et al., "LDP Specification", January 2001.

453	   [LSP-Ping] Bonica, R. et al., "Detecting MPLS Data Plane Liveness",
454	              work-in-progress.

456	   [RFC3477]  Kompella, K. & Y. Rekhter, "Signalling Unnumbered Links
457	              in Resource ReSerVation Protocol - Traffic Engineering
458	              (RSVP-TE)", January 2003.

460	   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
461	              Requirement Levels", BCP 14, RFC 2119, March 1997.

463	7.2. Informative References

465	   [RSVP-TE]  Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
466	              tunnels", RFC 3209, December 2001.

468	8. Authors' Addresses

470	      Kireeti Kompella
471	      Juniper Networks, Inc.
472	      1194 N. Mathilda Ave.
473	      Sunnyvale, CA 94089
474	      Email:  kireeti@juniper.net

476	      George Swallow
477	      Cisco Systems, Inc.
478	      1414 Massachusetts Ave
479	      Boxborough, MA 01719

481	      Email:  swallow@cisco.com

483	      Dan Tappan
484	      Cisco Systems, Inc.
485	      1414 Massachusetts Ave
486	      Boxborough, MA 01719

488	      Email:  tappan@cisco.com

490	9. Full Copyright and Intellectual Property Statements

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

496	   This document and the information contained herein are provided on an
497	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
498	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
499	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
500	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
501	   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
502	   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

504	Intellectual Property

506	   The IETF takes no position regarding the validity or scope of any
507	   Intellectual Property Rights or other rights that might be claimed to
508	   pertain to the implementation or use of the technology described in
509	   this document or the extent to which any license under such rights
510	   might or might not be available; nor does it represent that it has
511	   made any independent effort to identify any such rights.  Information
512	   on the procedures with respect to rights in RFC documents can be
513	   found in BCP 78 and BCP 79.

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

522	   The IETF invites any interested party to bring to its attention any
523	   copyrights, patents or patent applications, or other proprietary
524	   rights that may cover technology that may be required to implement
525	   this standard.  Please address the information to the IETF at ietf-
526	   ipr@ietf.org.

528	Acknowledgement

530	   Funding for the RFC Editor function is currently provided by the
531	   Internet Society.