doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4205.txt b/doc/rfc/rfc4205.txt
new file mode 100644
index 0000000..f3f7a00
--- /dev/null
+++ b/doc/rfc/rfc4205.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                   K. Kompella, Ed.
+Request for Comments: 4205                               Y. Rekhter, Ed.
+Updates: 3784                                           Juniper Networks
+Category: Informational                                     October 2005
+
+
+     Intermediate System to Intermediate System (IS-IS) Extensions
+    in Support of Generalized Multi-Protocol Label Switching (GMPLS)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies encoding of extensions to the IS-IS routing
+   protocol in support of Generalized Multi-Protocol Label Switching
+   (GMPLS).
+
+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
+
+
+
+
+Kompella & Rekhter           Informational                      [Page 1]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+   We further add one new TLV to the TE TLVs:
+
+          TLV Type      Length    Name
+               138      variable  Shared Risk Link Group
+
+   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 Identifiers is a sub-TLV of the extended IS
+   reachability TLV.  The type of this sub-TLV is 4, and length is eight
+   octets.  The value field of this sub-TLV contains four octets of Link
+   Local Identifier followed by four octets of Link Remote Identifier
+   (see Section "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.
+
+       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 length two 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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Kompella & Rekhter           Informational                      [Page 2]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+   The first octet is a bit vector describing the protection
+   capabilities of the link (see Section "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
+
+   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
+   value field in octets.  The following illustrates encoding of the
+   Value field of the Interface Switching Capability Descriptor sub-TLV.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter           Informational                      [Page 3]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+       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)                                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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 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.
+
+
+
+
+Kompella & Rekhter           Informational                      [Page 4]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+   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 octets field in the IEEE
+   floating point format.  The units are bytes (not bits!) per second.
+   The Interface MTU is encoded as a 2 octets 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.
+
+       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 octets 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 "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.
+
+
+
+Kompella & Rekhter           Informational                      [Page 5]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+1.4.  Shared Risk Link Group TLV
+
+   The 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.
+
+       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 neighbors 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
+   "Shared Risk Link Group Information" of [GMPLS-ROUTING]).
+
+
+
+
+Kompella & Rekhter           Informational                      [Page 6]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+   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 ISIS 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
+   Engineering Default metric set to 0xffffff, and if the link has LSC
+   or FSC as its Switching Capability then also 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, and if the
+   link has LSC or FSC as its Switching Capability then also 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter           Informational                      [Page 7]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+3.  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
+
+   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
+
+
+
+Kompella & Rekhter           Informational                      [Page 8]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+4.  Acknowledgements
+
+   The authors would like to thank Jim Gibson, Suresh Katukam, Jonathan
+   Lang and Quaizar Vohra for their comments on the draft.
+
+5.  Security Considerations
+
+   This document specifies the contents of GMPLS TE TLVs in ISIS.  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
+   ISIS Link State PDUs and/or the TE TLVs [ISIS-HMAC] can be used to
+   secure the GMPLS TE TLVs as well.
+
+6.  IANA Considerations
+
+   This document defines the following new ISIS TLV type that needs to
+   be reflected in the ISIS TLV code-point 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 need to be reflected in the ISIS sub-TLV registry
+   for TLV 22:
+
+          Type        Description                        Length
+          ----        ------------------------------   --------
+             4        Link Local/Remote Identifiers           8
+            20        Link Protection Type                    2
+            21        Interface Switching Capability   variable
+                      Descriptor
+
+References
+
+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., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Resource ReserVation
+                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                   RFC 3473, January 2003.
+
+
+
+
+Kompella & Rekhter           Informational                      [Page 9]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+   [GMPLS-SIG]     Berger, L., "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
+                   Intermediate System to Intermediate System (IS-IS)
+                   Point-to-Point Adjacencies", RFC 3373, September
+                   2002.
+
+   [ISIS-RESTART]  Shand, M. and L. Ginsberg, "Restart Signaling for
+                   Intermediate System to Intermediate System (IS-IS)",
+                   RFC 3847, July 2004.
+
+   [ISIS-TE]       Smit, H. and T. Li, "Intermediate System to
+                   Intermediate System (IS-IS) Extensions for Traffic
+                   Engineering (TE)", RFC 3784, June 2004.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ISIS-HMAC]     Li, T. and R. Atkinson, "Intermediate System to
+                   Intermediate System (IS-IS) Cryptographic
+                   Authentication", RFC 3567, July 2003.
+
+Authors' Addresses
+
+   Kireeti Kompella
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+Kompella & Rekhter           Informational                     [Page 10]
+
+RFC 4205               IS-IS Extensions for MPLS            October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Kompella & Rekhter           Informational                     [Page 11]
+