doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5307.txt b/doc/rfc/rfc5307.txt
new file mode 100644
index 0000000..f45c774
--- /dev/null
+++ b/doc/rfc/rfc5307.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                   K. Kompella, Ed.
+Request for Comments: 5307                               Y. Rekhter, Ed.
+Obsoletes: 4205                                         Juniper Networks
+Updates: 5305                                               October 2008
+Category: Standards Track
+
+
+                    IS-IS Extensions in Support of
+           Generalized Multi-Protocol Label Switching (GMPLS)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies encoding of extensions to the IS-IS routing
+   protocol in support of Generalized Multi-Protocol Label Switching
+   (GMPLS).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 1]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+1.  Introduction
+
+   This document specifies extensions to the IS-IS routing protocol in
+   support of carrying link state information for Generalized Multi-
+   Protocol Label Switching (GMPLS).  The set of required enhancements
+   to IS-IS are outlined in [GMPLS-ROUTING].  Support for unnumbered
+   interfaces assumes support for the "Point-to-Point Three-Way
+   Adjacency" IS-IS Option type [ISIS-3way].
+
+   In this section, we define the enhancements to the Traffic
+   Engineering (TE) properties of GMPLS TE links that can be announced
+   in IS-IS Link State Protocol Data Units.
+
+   In this document, we enhance the sub-TLVs for the extended IS
+   reachability TLV (see [ISIS-TE]) in support of GMPLS.  Specifically,
+   we add the following sub-TLVs:
+
+      Sub-TLV Type        Length    Name
+                 4             8    Link Local/Remote Identifiers
+                20             2    Link Protection Type
+                21      variable    Interface Switching Capability
+                                    Descriptor
+
+   We further add one new TLV to the TE TLVs:
+
+          TLV Type        Length    Name
+               138      variable    GMPLS-SRLG
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.1.  Link Local/Remote Identifiers
+
+   A Link Local Interface Identifier is a sub-TLV of the extended IS
+   reachability TLV.  The type of this sub-TLV is 4, and the length is 8
+   octets.  The value field of this sub-TLV contains 4 octets of Link
+   Local Identifier followed by 4 octets of Link Remote Identifier (see
+   Section 2.1, "Support for Unnumbered Links", of [GMPLS-ROUTING]).  If
+   the Link Remote Identifier is unknown, it is set to 0.
+
+   The following illustrates encoding of the Value field of the Link
+   Local/Remote Identifiers sub-TLV.
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 2]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Link Local Identifier                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Link Remote Identifier                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Link Local/Remote Identifiers sub-TLV MUST NOT occur more than
+   once within the extended IS reachability TLV.  If the Link
+   Local/Remote Identifiers sub-TLV occurs more than once within the
+   extended IS reachability TLV, the receiver SHOULD ignore all these
+   sub-TLVs.
+
+1.2.  Link Protection Type
+
+   The Link Protection Type is a sub-TLV (of type 20) of the extended IS
+   reachability TLV, with a length of 2 octets.
+
+   The following illustrates encoding of the Value field of the Link
+   Protection Type sub-TLV.
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Protection Cap |    Reserved   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+The first octet is a bit vector describing the protection capabilities
+   of the link (see Section 2.2, "Link Protection Type", of
+   [GMPLS-ROUTING]).  They are:
+
+      0x01  Extra Traffic
+
+      0x02  Unprotected
+
+      0x04  Shared
+
+      0x08  Dedicated 1:1
+
+      0x10  Dedicated 1+1
+
+      0x20  Enhanced
+
+      0x40  Reserved
+
+      0x80  Reserved
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 3]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+   The second octet SHOULD be set to zero by the sender, and SHOULD be
+   ignored by the receiver.
+
+   The Link Protection Type sub-TLV MUST NOT occur more than once within
+   the extended IS reachability TLV.  If the Link Protection Type sub-
+   TLV occurs more than once within the extended IS reachability TLV,
+   the receiver SHOULD ignore all these sub-TLVs.
+
+1.3.  Interface Switching Capability Descriptor
+
+   The Interface Switching Capability Descriptor is a sub-TLV (of type
+   21) of the extended IS reachability TLV.  The length is the length of
+   the value field in octets.  The following illustrates encoding of the
+   Value field of the Interface Switching Capability Descriptor sub-TLV.
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Switching Cap |   Encoding    |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 0              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 1              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 2              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 3              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 4              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 5              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 6              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Max LSP Bandwidth at priority 7              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Switching Capability-specific information              |
+      |                  (variable)                                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 4]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+   The Switching Capability (Switching Cap) field contains one of the
+   following values:
+
+            1     Packet-Switch Capable-1 (PSC-1)
+            2     Packet-Switch Capable-2 (PSC-2)
+            3     Packet-Switch Capable-3 (PSC-3)
+            4     Packet-Switch Capable-4 (PSC-4)
+            51    Layer-2 Switch Capable  (L2SC)
+            100   Time-Division-Multiplex Capable (TDM)
+            150   Lambda-Switch Capable   (LSC)
+            200   Fiber-Switch Capable    (FSC)
+
+   The Encoding field contains one of the values specified in Section
+   3.1.1 of [GMPLS-SIG].
+
+   Maximum Link State Protocol Data Unit (LSP) Bandwidth is encoded as a
+   list of eight 4-octet fields in the IEEE floating point format
+   [IEEE], with priority 0 first and priority 7 last.  The units are
+   bytes (not bits!) per second.
+
+   The content of the Switching Capability specific information field
+   depends on the value of the Switching Capability field.
+
+   When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
+   the Switching Capability specific information field includes Minimum
+   LSP Bandwidth and Interface MTU.
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Minimum LSP Bandwidth                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Interface MTU       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE
+   floating point format.  The units are bytes (not bits!) per second.
+   The Interface MTU is encoded as a 2-octet integer, and carries the
+   MTU value in the units of bytes.
+
+   When the Switching Capability field is L2SC, there is no Switching
+   Capability specific information field present.
+
+   When the Switching Capability field is TDM, the Switching Capability
+   specific information field includes Minimum LSP Bandwidth and an
+   indication whether the interface supports Standard or Arbitrary
+   SONET/SDH (Synchronous Optical Network / Synchronous Digital
+   Hierarchy).
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 5]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Minimum LSP Bandwidth                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Indication  |
+      +-+-+-+-+-+-+-+-+
+
+   The Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE
+   floating point format.  The units are bytes (not bits!) per second.
+   The indication whether the interface supports Standard or Arbitrary
+   SONET/SDH is encoded as 1 octet.  The value of this octet is 0 if the
+   interface supports Standard SONET/SDH, and 1 if the interface
+   supports Arbitrary SONET/SDH.
+
+   When the Switching Capability field is LSC, there is no Switching
+   Capability specific information field present.
+
+   To support interfaces that have more than one Interface Switching
+   Capability Descriptor (see Section 2.4, "Interface Switching
+   Capability Descriptor", of [GMPLS-ROUTING]) the Interface Switching
+   Capability Descriptor sub-TLV MAY occur more than once within the
+   extended IS reachability TLV.
+
+1.4.  Shared Risk Link Group TLV
+
+   The Shared Risk Link Group (SRLG) TLV (of type 138) contains a data
+   structure consisting of:
+
+       6 octets of System ID
+       1 octet of Pseudonode Number
+       1 octet Flag
+       4 octets of IPv4 interface address or 4 octets of a Link Local
+         Identifier
+       4 octets of IPv4 neighbor address or 4 octets of a Link Remote
+         Identifier
+       (variable) list of SRLG values, where each element in the list
+         has 4 octets.
+
+   The following illustrates encoding of the Value field of the SRLG
+   TLV.
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 6]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          System ID                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            System ID (cont.)  | Pseudonode num|    Flags      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        IPv4 interface address/Link Local Identifier           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        IPv4 neighbor address/Link Remote Identifier           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Shared Risk Link Group Value                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        ............                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Shared Risk Link Group Value                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The neighbor is identified by its System ID (6 octets), plus one
+   octet to indicate the pseudonode number if the neighbor is on a LAN
+   interface.
+
+   The least significant bit of the Flag octet indicates whether the
+   interface is numbered (set to 1) or unnumbered (set to 0).  All other
+   bits are reserved and should be set to 0.
+
+   The length of this TLV is 16 + 4 * (number of SRLG values).
+
+   This TLV carries the Shared Risk Link Group information (see Section
+   2.3, "Shared Risk Link Group Information", of [GMPLS-ROUTING]).
+
+   The SRLG TLV MAY occur more than once within the IS-IS Link State
+   Protocol Data Units.
+
+1.5.  Link Identifier for Unnumbered Interfaces
+
+   Link Identifiers are exchanged in the Extended Local Circuit ID field
+   of the "Point-to-Point Three-Way Adjacency" IS-IS Option type [ISIS-
+   3way].
+
+2.  Implications on Graceful Restart
+
+   The restarting node SHOULD follow the IS-IS restart procedures
+   [ISIS-RESTART] and the RSVP-TE restart procedures [GMPLS-RSVP].
+
+   When the restarting node is going to originate its IS-IS Link State
+   Protocol Data Units for TE links, these Link State Protocol Data
+   Units SHOULD be originated with 0 unreserved bandwidth, Traffic
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 7]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+   Engineering Default metric set to 0xffffff.  Also, if the link has
+   LSC or FSC as its Switching Capability, then they SHOULD be
+   originated with 0 as Max LSP Bandwidth, until the node is able to
+   determine the amount of unreserved resources taking into account the
+   resources reserved by the already established LSPs that have been
+   preserved across the restart.  Once the restarting node determines
+   the amount of unreserved resources, taking into account the resources
+   reserved by the already established LSPs that have been preserved
+   across the restart, the node SHOULD advertise these resources in its
+   Link State Protocol data units.
+
+   In addition, in the case of a planned restart prior to restarting,
+   the restarting node SHOULD originate the IS-IS Link State Protocol
+   data units for TE links with 0 as unreserved bandwidth.  Also, if the
+   link has LSC or FSC as its Switching Capability, then they SHOULD be
+   originated with 0 as Max LSP Bandwidth.  This would discourage new
+   LSP establishment through the restarting router.
+
+   Neighbors of the restarting node SHOULD continue to advertise the
+   actual unreserved bandwidth on the TE links from the neighbors to
+   that node.
+
+3.  Security Considerations
+
+   This document specifies the contents of GMPLS TE TLVs in IS-IS.  As
+   these TLVs are not used for SPF computation or normal routing, the
+   extensions specified here have no direct effect on IP routing.
+   Tampering with GMPLS TE TLVs may have an effect on the underlying
+   transport (optical and/or SONET/SDH) network.  Mechanisms to secure
+   IS-IS Link State PDUs and/or the TE TLVs [ISIS-HMAC] can be used to
+   secure the GMPLS TE TLVs as well.
+
+   For a discussion of general security considerations for IS-IS, see
+   [ISIS-HMAC].
+
+4.  IANA Considerations
+
+   This document defines the following new IS-IS TLV type that has been
+   reflected in the IS-IS TLV codepoint registry:
+
+         Type        Description              IIH   LSP   SNP
+         ----        ----------------------   ---   ---   ---
+          138        Shared Risk Link Group    n     y     n
+
+   This document also defines the following new sub-TLV types of top-
+   level TLV 22 that have been reflected in the IS-IS sub-TLV registry
+   for TLV 22:
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 8]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+         Type        Description                        Length
+         ----        ------------------------------   --------
+            4        Link Local/Remote Identifiers           8
+           20        Link Protection Type                    2
+           21        Interface Switching Capability   variable
+                     Descriptor
+
+5.  References
+
+5.1.  Normative References
+
+   [GMPLS-ROUTING] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+                   Extensions in Support of Generalized Multi-Protocol
+                   Label Switching (GMPLS)", RFC 4202, October 2005.
+
+   [GMPLS-RSVP]    Berger, L., Ed., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Resource ReserVation
+                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                   RFC 3473, January 2003.
+
+   [GMPLS-SIG]     Berger, L., Ed., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Functional Description",
+                   RFC 3471, January 2003
+
+   [IEEE]          IEEE, "IEEE Standard for Binary Floating-Point
+                   Arithmetic", Standard 754-1985, 1985 (ISBN
+                   1-5593-7653-8).
+
+   [ISIS-3way]     Katz, D. and R. Saluja, "Three-Way Handshake for IS-
+                   IS Point-to-Point Adjacencies", RFC 5303, October
+                   2008.
+
+   [ISIS-HMAC]     Li, T. and R. Atkinson, "IS-IS Cryptographic
+                   Authentication", RFC 5304, October 2008.
+
+   [ISIS-RESTART]  Shand, M. and L. Ginsberg, "Restart Signaling for
+                   IS-IS", RFC 5306, October 2008.
+
+   [ISIS-TE]       Smit, H. and T. Li, "IS-IS Extensions for Traffic
+                   Engineering", RFC 5305, October 2008.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+6.  Acknowledgements
+
+   The authors would like to thank Jim Gibson, Suresh Katukam, Jonathan
+   Lang, and Quaizar Vohra for their comments on the document.
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 9]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+7.  Contributors
+
+   Ayan Banerjee
+   Calient Networks
+   5853 Rue Ferrari
+   San Jose, CA 95138
+
+   Phone: +1 408 972 3645
+   EMail: abanerjee@calient.net
+
+
+   John Drake
+   Calient Networks
+   5853 Rue Ferrari
+   San Jose, CA 95138
+
+   Phone: +1 408 972 3720
+   EMail: jdrake@calient.net
+
+
+   Greg Bernstein
+   Grotto Networking
+
+   EMail: gregb@grotto-networking.com
+
+
+   Don Fedyk
+   Nortel Networks Corp.
+   600 Technology Park Drive
+   Billerica, MA 01821
+
+   Phone: +1 978 288 4506
+   EMail: dwfedyk@nortelnetworks.com
+
+
+   Eric Mannie
+   Independent Consultant
+
+   EMail: eric_mannie@hotmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 10]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+   Debanjan Saha
+   Tellium Optical Systems
+   2 Crescent Place
+   P.O. Box 901
+   Ocean Port, NJ 07757
+
+   Phone: +1 732 923 4264
+   EMail: dsaha@tellium.com
+
+
+   Vishal Sharma
+
+   EMail: v.sharma@ieee.org
+
+Authors' Addresses
+
+   Kireeti Kompella (editor)
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+
+   Yakov Rekhter (editor)
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 11]
+
+RFC 5307               IS-IS Extensions for GMPLS           October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 12]
+