doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4201.txt b/doc/rfc/rfc4201.txt
new file mode 100644
index 0000000..a41c1c0
--- /dev/null
+++ b/doc/rfc/rfc4201.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                        K. Kompella
+Request for Comments: 4201                                    Y. Rekhter
+Updates: 3471, 3472, 3473                               Juniper Networks
+Category: Standards Track                                      L. Berger
+                                                          Movaz Networks
+                                                            October 2005
+
+
+             Link Bundling in MPLS Traffic Engineering (TE)
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
+   signaling, in certain cases a combination of <link identifier, label>
+   is not sufficient to unambiguously identify the appropriate resource
+   used by a Label Switched Path (LSP).  Such cases are handled by using
+   the link bundling construct, which is described in this document.
+   This document updates the interface identification TLVs, which are
+   defined in the GMPLS Signaling Functional Description.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 1]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+Table of Contents
+
+   1.  Introduction .................................................  2
+       1.1.  Specification of Requirements ..........................  2
+   2.  Link Bundling ................................................  3
+       2.1.  Restrictions on Bundling ...............................  4
+       2.2.  Routing Considerations .................................  4
+       2.3.  Signaling Considerations ...............................  5
+             2.3.1.  Interface Identification TLV Format ............  6
+             2.3.2.  Errored Component Identification ...............  7
+   3.  Traffic Engineering Parameters for Bundled Links .............  7
+       3.1.  OSPF Link Type .........................................  7
+       3.2.  OSPF Link ID ...........................................  7
+       3.3.  Local and Remote Interface IP Address ..................  7
+       3.4.  Local and Remote Identifiers ...........................  8
+       3.5.  Traffic Engineering Metric .............................  8
+       3.6.  Maximum Bandwidth ......................................  8
+       3.7.  Maximum Reservable Bandwidth ...........................  8
+       3.8.  Unreserved Bandwidth ...................................  8
+       3.9.  Resource Classes (Administrative Groups) ...............  8
+       3.10.  Maximum LSP Bandwidth .................................  8
+   4.  Bandwidth Accounting .........................................  9
+   5.  Security Considerations ......................................  9
+   6.  IANA Considerations ..........................................  9
+   7.  References ................................................... 10
+       7.1.  Normative References ................................... 10
+       7.2.  Informative References ................................. 11
+
+1.  Introduction
+
+   For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
+   signaling, in certain cases a combination of <link identifier, label>
+   is not sufficient to unambiguously identify the appropriate resource
+   used by a Label Switched Path (LSP).  Such cases are handled by using
+   the link bundling construct, which is described in this document.
+   This document updates the interface identification TLVs, which are
+   defined in the GMPLS Signaling Functional Description.
+
+1.1.  Specification of Requirements
+
+   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].
+
+
+
+
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 2]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+2.  Link Bundling
+
+   As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a
+   logical construct that represents a way to group/map information
+   about certain physical resources (and their properties) that
+   interconnect LSRs with information that is used by Constrained SPF
+   (for the purpose of path computation) and by GMPLS signaling.
+
+   As stated in [GMPLS-ROUTING], depending on the nature of resources
+   that form a particular TE link for the purpose of GMPLS signaling, in
+   some cases a combination of <TE link identifier, label> is sufficient
+   to unambiguously identify the appropriate resource used by an LSP.
+   In other cases, a combination of <TE link identifier, label> is not
+   sufficient.  Consider, for example, a TE link between a pair of
+   SONET/SDH cross-connects, where this TE link is composed of several
+   fibers.  In this case the label is a TDM time slot, and moreover,
+   this time slot is significant only within a particular fiber.  Thus,
+   when signaling an LSP over such a TE link, one needs to specify not
+   just the identity of the link, but also the identity of a particular
+   fiber within that TE link, as well as a particular label (time slot)
+   within that fiber.  Such cases are handled by using the link bundling
+   construct, which is described in this document.
+
+   Consider a TE link such that, for the purpose of GMPLS signaling, a
+   combination of <TE link identifier, label> is not sufficient to
+   unambiguously identify the appropriate resources used by an LSP.  In
+   this situation, the link bundling construct assumes that the set of
+   resources that form the TE link could be partitioned into disjoint
+   subsets, such that (a) the partition is minimal, and (b) within each
+   subset, a label is sufficient to unambiguously identify the
+   appropriate resources used by an LSP.  We refer to such subsets as
+   "component links", and to the whole TE link as a "bundled link".
+   Furthermore, we restrict the identifiers that can be used to identify
+   component links such that they are unique for a given node.  On a
+   bundled link, a combination of <component link identifier, label> is
+   sufficient to unambiguously identify the appropriate resources used
+   by an LSP.
+
+   The partition of resources that form a bundled link into component
+   links has to be done consistently at both ends of the bundled link.
+   Both ends of the bundled link also have to understand the other end's
+   component link identifiers.
+
+   The purpose of link bundling is to improve routing scalability by
+   reducing the amount of information that has to be handled by OSPF
+   and/or IS-IS.  This reduction is accomplished by performing
+   information aggregation/abstraction.  As with any other information
+   aggregation/abstraction, this results in losing some of the
+
+
+
+Kompella, et al.            Standards Track                     [Page 3]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+   information.  To limit the amount of losses, one needs to restrict
+   the type of information that can be aggregated/abstracted.
+
+2.1.  Restrictions on Bundling
+
+   All component links in a bundle have the same Link Type (i.e.,
+   point-to-point or multi-access), the same Traffic Engineering metric,
+   the same set of resource classes at each end of the links, and must
+   begin and end on the same pair of LSRs.
+
+   A Forwarding Adjacency may be a component link; in fact, a bundle can
+   consist of a mix of point-to-point links and FAs.
+
+   If the component links are all multi-access links, the set of IS-IS
+   or OSPF routers that are connected to each component link must be the
+   same, and the Designated Router for each component link must be the
+   same.  If these conditions cannot be enforced, multi-access links
+   must not be bundled.
+
+   Component link identifiers MUST be unique across both TE and
+   component link identifiers on a particular node.  This means that
+   unnumbered identifiers have a node-wide scope, and that numbered
+   identifiers have the same scope as IP addresses.
+
+2.2.  Routing Considerations
+
+   A component link may be either numbered or unnumbered.  A bundled
+   link may itself be numbered or unnumbered, independent of whether the
+   component links of that bundled link are numbered.
+
+   Handling identifiers for unnumbered component links, including the
+   case in which a link is formed by a Forwarding Adjacency, follows the
+   same rules as those for an unnumbered TE link (see Section "Link
+   Identifiers" of [RFC3477]/[RFC3480]).  Furthermore, link local
+   identifiers for all unnumbered links of a given LSR (whether
+   component links, Forwarding Adjacencies, or bundled links) MUST be
+   unique in the context of that LSR.
+
+   The "liveness" of the bundled link is determined by the liveness of
+   each of the component links within the bundled link; a bundled link
+   is alive when at least one of its component links is determined to be
+   alive.  The liveness of a component link can be determined by any of
+   several means: IS-IS or OSPF hellos over the component link, RSVP
+   Hello, LMP hellos (see [LMP]), or from layer 1 or layer 2
+   indications.
+
+
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 4]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+   Once a bundled link is determined to be alive, it can be advertised
+   as a TE link and the TE information can be flooded.  If IS-IS/OSPF
+   hellos are run over the component links, IS-IS/OSPF flooding can be
+   restricted to just one of the component links.  Procedures for doing
+   this are outside the scope of this document.
+
+   In the future, as new Traffic Engineering parameters are added to
+   IS-IS and OSPF, they should be accompanied by descriptions as to how
+   they can be bundled, and possible restrictions on bundling.
+
+2.3.  Signaling Considerations
+
+   Because information about the bundled link is flooded, but
+   information about the component links is not, typically, an LSP's ERO
+   will identify the bundled link to be used for the LSP, but not the
+   component link.  While Discovery of component link identities to be
+   used in an ERO is outside the scope of the document, it is envisioned
+   that such information may be provided via configuration or via future
+   RRO extensions.  When the bundled link is identified in an ERO or is
+   dynamically identified, the choice of the component link for the LSP
+   is a local matter between the two LSRs at each end of the bundled
+   link.
+
+   Signaling must identify both the component link and label to use.
+   The choice of the component link to use is always made by the sender
+   of the Path/REQUEST message.  If an LSP is bidirectional [RFC3471],
+   the sender chooses a component link in each direction.  The handling
+   of labels is not modified by this document.
+
+   Component link identifiers are carried in RSVP messages, as described
+   in section 8 of [RFC3473].  Component link identifiers are carried in
+   CR-LDP messages, as described in section 8 of [RFC3473].  Additional
+   processing related to unnumbered links is described in the
+   "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV",
+   and "Unnumbered Forwarding Adjacencies" sections of
+   [RFC3477]/[RFC3480].
+
+   [RFC3471] defines the Interface Identification type-length-value
+   (TLV) types.  This document specifies that the TLV types 1, 2, and 3
+   SHOULD be used to indicate component links in IF_ID RSVP_HOP objects
+   and IF_ID TLVs.
+
+   Type 1 TLVs are used for IPv4 numbered component link identifiers.
+
+   Type 2 TLVs are used for IPv6 numbered component link identifiers.
+
+   Type 3 TLVs are used for unnumbered component link identifiers.
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 5]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+   The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
+   Note, in Path and REQUEST messages, link identifiers MUST be
+   specified from the sender's perspective.
+
+   Except in the special case noted below, for a unidirectional LSP,
+   only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
+   TLV.  This TLV indicates the component link identifier of the
+   downstream data channel on which label allocation must be done.
+
+   Except in the special case noted below, for a bidirectional LSP, only
+   one or two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
+   TLV.  The first TLV always indicates the component link identifier of
+   the downstream data channel on which label allocation must be done.
+   When present, the second TLV always indicates the component link
+   identifier of the upstream data channel on which label allocation
+   must be done.  When only one TLV is present, it indicates the
+   component link identifier for both downstream and upstream data
+   channels.
+
+   In the special case where the same label is to be valid across all
+   component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object
+   or IF_ID TLV.  The first TLV indicates the TE link identifier of the
+   bundle on which label allocation must be done.  The second TLV
+   indicates a bundle scope label.  For TLV types 1 and 2, this is done
+   by using the special bit value of all ones (1) (e.g., 0xFFFFFFFF for
+   a type 1 TLV).  Per [RFC3471], for TLV types 3, 4, and 5, this is
+   done by setting the Interface ID field to the special value
+   0xFFFFFFFF.  Note that this special case applies to both
+   unidirectional and bidirectional LSPs.
+
+   Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
+   the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.
+
+2.3.1.  Interface Identification TLV Format
+
+   This section modifies section 9.1.1. of [RFC3471].  The definition of
+   the IP Address field of the TLV types 3, 4, and 5 is clarified.
+
+      For types 3, 4, and 5, the Value field has an identical format to
+      the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object
+      defined in [RFC3477].  Note that this results in the renaming of
+      the IP Address field defined in [RFC3471].
+
+
+
+
+
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 6]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+2.3.2.  Errored Component Identification
+
+   When Interface Identification TLVs are used, the TLVs are also used
+   to indicate the specific components associated with an error.  For
+   RSVP, this means that any received TLVs SHOULD be copied into the
+   IF_ID ERROR_SPEC object (see Section 8.2 in [RFC3473]).  The Error
+   Node Address field of the object SHOULD indicate the TE Link
+   associated with the error.  For CR-LDP, this means that any received
+   TLVs SHOULD be copied into the IF_ID Status TLV (see Section 8.2 in
+   [RFC3472]).  The HOP Address field of the TLV SHOULD indicate the TE
+   Link associated with the error.
+
+3.  Traffic Engineering Parameters for Bundled Links
+
+   In this section, we define the Traffic Engineering parameters to be
+   advertised for a bundled link, based on the configuration of the
+   component links and of the bundled link.  The definition of these
+   parameters for component links was undertaken in [RFC3784] and
+   [RFC3630]; we use the terminology from [RFC3630].
+
+3.1.  OSPF Link Type
+
+   The Link Type of a bundled link is the (unique) Link Type of the
+   component links.  Note that this parameter is not present in IS-IS.
+
+3.2.  OSPF Link ID
+
+   For point-to-point links, the Link ID of a bundled link is the
+   (unique) Router ID of the neighbor.  For multi-access links, this is
+   the interface address of the (unique) Designated Router.  Note that
+   this parameter is not present in IS-IS.
+
+3.3.  Local and Remote Interface IP Address
+
+   Note that in IS-IS, the Local Interface IP Address is known as the
+   IPv4 Interface Address and the Remote Interface IP Address is known
+   as the IPv4 Neighbor Address.
+
+   If the bundled link is numbered, the Local Interface IP Address is
+   the local address of the bundled link; similarly, the Remote
+   Interface IP Address is the remote address of the bundled link.
+
+
+
+
+
+
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 7]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+3.4.  Local and Remote Identifiers
+
+   If the bundled link is unnumbered, the link local identifier is set
+   to the identifier chosen for the bundle by the advertising LSR.  The
+   link remote identifier is set to the identifier chosen by the
+   neighboring LSR for the reverse link corresponding to this bundle, if
+   known; otherwise, this is set to 0.
+
+3.5.  Traffic Engineering Metric
+
+   The Traffic Engineering Metric for a bundled link is that of the
+   component links.
+
+3.6.  Maximum Bandwidth
+
+   This parameter is not used.  The maximum LSP Bandwidth (as described
+   below) replaces the Maximum Bandwidth for bundled links.
+
+3.7.  Maximum Reservable Bandwidth
+
+   For a given bundled link, we assume that either each of its component
+   links is configured with the Maximum Reservable Bandwidth, or the
+   bundled link is configured with the Maximum Reservable Bandwidth.  In
+   the former case, the Maximum Reservable Bandwidth of the bundled link
+   is set to the sum of the Maximum Reservable Bandwidths of all
+   component links associated with the bundled link.
+
+3.8.  Unreserved Bandwidth
+
+   The unreserved bandwidth of a bundled link at priority p is the sum
+   of the unreserved bandwidths at priority p of all the component links
+   associated with the bundled link.
+
+3.9.  Resource Classes (Administrative Groups)
+
+   The Resource Classes for a bundled link are the same as those of the
+   component links.
+
+3.10.  Maximum LSP Bandwidth
+
+   The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
+   For an unbundled link, the Maximum Bandwidth is defined in
+   [GMPLS-ROUTING].  The Maximum LSP Bandwidth of a bundled link at
+   priority p is defined to be the maximum of the Maximum LSP Bandwidth
+   at priority p of all of its component links.
+
+
+
+
+
+
+Kompella, et al.            Standards Track                     [Page 8]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+   The details of how Maximum LSP Bandwidth is carried in IS-IS is given
+   in [GMPLS-ISIS].  The details of how Maximum LSP Bandwidth is carried
+   in OSPF is given in [GMPLS-OSPF].
+
+4.  Bandwidth Accounting
+
+   The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
+   LSR with bundled links must apply admission control on a per-
+   component link basis.  An LSP with a bandwidth requirement b and
+   setup priority p fits in a bundled link if at least one component
+   link has a maximum LSP bandwidth >= b at priority p.  If there are
+   several such links, the implementation will choose which link to use
+   for the LSP.
+
+   In order to know the maximum LSP bandwidth (per priority) of each
+   component link, the Traffic Control module must track the unreserved
+   bandwidth (per priority) for each component link.
+
+   A change in the unreserved bandwidth of a component link results in a
+   change in the unreserved bandwidth of the bundled link.  It also
+   potentially results in a change in the maximum LSP bandwidth of the
+   bundle; thus, the maximum LSP bandwidth should be recomputed.
+
+   If one of the component links goes down, the associated bundled link
+   remains up and continues to be advertised, provided that at least one
+   component link associated with the bundled link is up.  The
+   unreserved bandwidth of the component link that is down is set to
+   zero, and the unreserved bandwidth and maximum LSP bandwidth of the
+   bundle must be recomputed.  If all the component links associated
+   with a given bundled link are down, the bundled link MUST not be
+   advertised into OSPF/IS-IS.
+
+5.  Security Considerations
+
+   This document defines ways of utilizing procedures defined in other
+   documents, referenced herein.  Any security issues related to those
+   procedures are addressed in the referenced documents.  Thus, this
+   document raises no new security issues for RSVP-TE [RFC3209] or CR-
+   LDP [RFC3212].
+
+6.  IANA Considerations
+
+   This document changes the recommended usage of two of the
+   Interface_ID Types defined in [RFC3471].  For this reason, the IANA
+   registry of GMPLS Signaling Parameters has been updated to read:
+
+   4      12      COMPONENT_IF_DOWNSTREAM - DEPRECATED
+   5      12      COMPONENT_IF_UPSTREAM   - DEPRECATED
+
+
+
+Kompella, et al.            Standards Track                     [Page 9]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [GMPLS-ISIS]    Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate
+                   System to Intermediate System (IS-IS) Extensions in
+                   Support of Generalized Multi-Protocol Label Switching
+                   (GMPLS)", RFC 4205, October 2005.
+
+   [GMPLS-OSPF]    Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF
+                   Extensions in Support of Generalized Multi-Protocol
+                   Label Switching (GMPLS)", RFC 4203, October 2005.
+
+   [GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
+                   Extensions in Support of Generalized Multi-Protocol
+                   Label Switching (GMPLS)", RFC 4202, October 2005.
+
+   [RFC3471]       Berger, L., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Functional Description",
+                   RFC 3471, January 2003.
+
+   [RFC3473]       Berger, L., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Resource ReserVation
+                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                   RFC 3473, January 2003.
+
+   [RFC3472]       Ashwood-Smith, P. and L. Berger, "Generalized Multi-
+                   Protocol Label Switching (GMPLS) Signaling
+                   Constraint-based Routed Label Distribution Protocol
+                   (CR-LDP) Extensions", RFC 3472, January 2003.
+
+   [RFC3784]       Smit, H. and T. Li, "Intermediate System to
+                   Intermediate System (IS-IS) Extensions for Traffic
+                   Engineering (TE)", RFC 3784, June 2004.
+
+   [RFC3630]       Katz, D., Kompella, K., and D. Yeung, "Traffic
+                   Engineering (TE) Extensions to OSPF Version 2", RFC
+                   3630, September 2003.
+
+   [RFC3480]       Kompella, K., Rekhter, Y., and A. Kullberg,
+                   "Signalling Unnumbered Links in CR-LDP (Constraint-
+                   Routing Label Distribution Protocol)", RFC 3480,
+                   February 2003.
+
+   [RFC3477]       Kompella, K. and Y. Rekhter, "Signalling Unnumbered
+                   Links in Resource ReSerVation Protocol - Traffic
+                   Engineering (RSVP-TE)", RFC 3477, January 2003.
+
+
+
+
+Kompella, et al.            Standards Track                    [Page 10]
+
+RFC 4201                Link Bundling in MPLS-TE            October 2005
+
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3209]       Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                   V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
+                   LSP Tunnels", RFC 3209, December 2001.
+
+   [RFC3212]       Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
+                   Wu, L., Doolan, P., Worster, T., Feldman, N.,
+                   Fredette, A., Girish, M., Gray, E., Heinanen, J.,
+                   Kilty, T., and A. Malis, "Constraint-Based LSP Setup
+                   using LDP", RFC 3212, January 2002.
+
+7.2.  Informative References
+
+   [LMP]           Lang, J., Ed., "Link Management Protocol (LMP)", RFC
+                   4204, October 2005.
+
+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
+
+
+   Lou Berger
+   Movaz Networks, Inc.
+
+   Phone: +1 703-847-1801
+   EMail: lberger@movaz.com
+
+
+
+
+
+
+
+
+
+
+Kompella, et al.            Standards Track                    [Page 11]
+
+RFC 4201                Link Bundling in MPLS-TE            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, et al.            Standards Track                    [Page 12]
+