summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3784.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3784.txt')
-rw-r--r--doc/rfc/rfc3784.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3784.txt b/doc/rfc/rfc3784.txt
new file mode 100644
index 0000000..208fa97
--- /dev/null
+++ b/doc/rfc/rfc3784.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group H. Smit
+Request for Comments: 3784 Procket Networks
+Category: Informational T. Li
+ June 2004
+
+
+ Intermediate System to Intermediate System (IS-IS)
+ Extensions for Traffic Engineering (TE)
+
+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 (2004).
+
+Abstract
+
+ This document describes extensions to the Intermediate System to
+ Intermediate System (IS-IS) protocol to support Traffic Engineering
+ (TE). This document extends the IS-IS protocol by specifying new
+ information that an Intermediate System (router) can place in Link
+ State Protocol (LSP) Data Units. This information describes
+ additional details regarding the state of the network that are useful
+ for traffic engineering computations.
+
+1. Introduction
+
+ The IS-IS protocol is specified in ISO 10589 [1], with extensions for
+ supporting IPv4 specified in RFC 1195 [3]. Each Intermediate System
+ (IS) (router) advertises one or more IS-IS Link State Protocol Data
+ Units (LSPs) with routing information. Each LSP is composed of a
+ fixed header and a number of tuples, each consisting of a Type, a
+ Length, and a Value. Such tuples are commonly known as TLVs, and are
+ a good way of encoding information in a flexible and extensible
+ format.
+
+ This document contains the design of new TLVs to replace the existing
+ IS Neighbor TLV, IP Reachability TLV, and to include additional
+ information about the characteristics of a particular link to an IS-
+ IS LSP. The characteristics described in this document are needed
+ for Traffic Engineering [4] (TE). Secondary goals include increasing
+ the dynamic range of the IS-IS metric and improving the encoding of
+ IP prefixes.
+
+
+
+
+Smit & Li Informational [Page 1]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+ The router id is useful for traffic engineering purposes because it
+ describes a single address that can always be used to reference a
+ particular router.
+
+ Mechanisms and procedures to migrate to the new TLVs are not
+ discussed in this document.
+
+2. Introducing Sub-TLVs
+
+ This document introduces a new way to encode routing information in
+ IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to
+ regular TLVs. They use the same concepts as regular TLVs. The
+ difference is that TLVs exist inside IS-IS packets, while sub-TLVs
+ exist inside TLVs. TLVs are used to add extra information to IS-IS
+ packets. Sub-TLVs are used to add extra information to particular
+ TLVs. Each sub-TLV consists of three fields, a one-octet Type field,
+ a one-octet Length field, and zero or more octets of Value. The Type
+ field indicates the type of items in the Value field. The Length
+ field indicates the length of the Value field in octets. Each sub-
+ TLV can potentially hold multiple items. The number of items in a
+ sub-TLV can be computed from the length of the whole sub-TLV, when
+ the length of each item is known. Unknown sub-TLVs are to be ignored
+ and skipped upon receipt.
+
+ The Sub-TLV type space is managed by the IETF IS-IS WG
+ (http://www.ietf.org/html.charters/isis-charter.html). New type
+ values are allocated following review on the IETF IS-IS mailing list.
+ This will normally require publication of additional documentation
+ describing how the new type is used. In the event that the IS-IS
+ working group has disbanded the review shall be performed by a
+ Designated Expert assigned by the responsible Area Director.
+
+3. The Extended IS Reachability TLV
+
+ The extended IS reachability TLV is TLV type 22.
+
+ The existing IS reachability (TLV type 2, defined in ISO 10589 [1])
+ contains information about a series of IS neighbors. For each
+ neighbor, there is a structure that contains the default metric, the
+ delay, the monetary cost, the reliability, and the 7-octet ID of the
+ adjacent neighbor. Of this information, the default metric is
+ commonly used. The default metric is currently one octet, with one
+ bit used to indicate whether the metric is internal or external, and
+ one bit that was originally unused, but which was later defined by
+ RFC 2966 to be the up/down bit. The remaining 6 bits are used to
+ store the actual metric, resulting in a possible metric range of 0-
+ 63. This limitation is one of the restrictions that we would like to
+ lift.
+
+
+
+Smit & Li Informational [Page 2]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+ The remaining three metrics (delay, monetary cost, and reliability)
+ are not commonly implemented and reflect unused overhead in the TLV.
+ The neighbor is identified by its system ID, typically 6-octets, plus
+ one octet indicating the pseudonode number. Thus, the existing TLV
+ consumes 11 octets per neighbor, with 4 octets for metric and 7
+ octets for neighbor identification. To indicate multiple
+ adjacencies, this structure is repeated within the IS reachability
+ TLV. Because the TLV is limited to 255 octets of content, a single
+ TLV can describe up to 23 neighbors. The IS reachability TLV can be
+ repeated within the LSP fragments to describe further neighbors.
+
+ The proposed extended IS reachability TLV contains a new data
+ structure, consisting of:
+
+ 7 octets of system Id and pseudonode number
+ 3 octets of default metric
+ 1 octet of length of sub-TLVs
+ 0-244 octets of sub-TLVs,
+ where each sub-TLV consists of a sequence of
+ 1 octet of sub-type
+ 1 octet of length of the value field of the sub-TLV
+ 0-242 octets of value
+
+ Thus, if no sub-TLVs are used, the new encoding requires 11 octets
+ and can contain up to 23 neighbors. Please note that while the
+ encoding allows for 255 octets of sub-TLVs, the maximum value cannot
+ fit in the overall IS reachability TLV. The practical maximum is 255
+ octets minus the 11 octets described above, or 244 octets. Further,
+ there is no defined mechanism for extending the sub-TLV space for a
+ particular neighbor. Thus, wasting sub-TLV space is discouraged.
+
+ The metric octets are encoded as a 24-bit unsigned integer. Note
+ that the metric field in the new extended IP reachability TLV is
+ encoded as a 32-bit unsigned integer. These different sizes were
+ chosen so that it is very unlikely that the cost of an intra-area
+ route has to be chopped off to fit in the metric field of an inter-
+ area route.
+
+ To preclude overflow within a traffic engineering SPF implementation,
+ all metrics greater than or equal to MAX_PATH_METRIC SHALL be
+ considered to have a metric of MAX_PATH_METRIC. It is easiest to
+ select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link
+ metric does not overflow the number of bits for internal metric
+ calculation. We assume that this is 32 bits. Therefore, we have
+ chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
+
+
+
+
+
+
+Smit & Li Informational [Page 3]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+ If a link is advertised with the maximum link metric (2^24 - 1), this
+ link MUST NOT be considered during the normal SPF computation. This
+ will allow advertisement of a link for purposes other than building
+ the normal Shortest Path Tree. An example is a link that is
+ available for traffic engineering, but not for hop-by-hop routing.
+
+ Certain sub-TLVs are proposed here:
+
+ Sub-TLV type Length (octets) Name
+ 3 4 Administrative group (color)
+ 6 4 IPv4 interface address
+ 8 4 IPv4 neighbor address
+ 9 4 Maximum link bandwidth
+ 10 4 Reservable link bandwidth
+ 11 32 Unreserved bandwidth
+ 18 3 TE Default metric
+ 250-254 Reserved for cisco specific extensions
+ 255 Reserved for future expansion
+
+ Each of these sub-TLVs is described below. Unless stated otherwise,
+ multiple occurrences of the information are supported by multiple
+ inclusions of the sub-TLV.
+
+3.1. Sub-TLV 3: Administrative group (color, resource class)
+
+ The administrative group sub-TLV contains a 4-octet bit mask assigned
+ by the network administrator. Each set bit corresponds to one
+ administrative group assigned to the interface.
+
+ By convention, the least significant bit is referred to as 'group 0',
+ and the most significant bit is referred to as 'group 31'.
+
+ This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in
+ each extended IS reachability TLV.
+
+3.2. Sub-TLV 6: IPv4 interface address
+
+ This sub-TLV contains a 4-octet IPv4 address for the interface
+ described by the (main) TLV. This sub-TLV can occur multiple times.
+
+ Implementations MUST NOT inject a /32 prefix for the interface
+ address into their routing or forwarding table because this can lead
+ to forwarding loops when interacting with systems that do not support
+ this sub-TLV.
+
+
+
+
+
+
+
+Smit & Li Informational [Page 4]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+ If a router implements the basic TLV extensions in this document, it
+ MAY add or omit this sub-TLV from the description of an adjacency.
+ If a router implements traffic engineering, it MUST include this
+ sub-TLV.
+
+3.3. Sub-TLV 8: IPv4 neighbor address
+
+ This sub-TLV contains a single IPv4 address for a neighboring router
+ on this link. This sub-TLV can occur multiple times.
+
+ Implementations MUST NOT inject a /32 prefix for the neighbor address
+ into their routing or forwarding table because this can lead to
+ forwarding loops when interacting with systems that do not support
+ this sub-TLV.
+
+ If a router implements the basic TLV extensions in this document, it
+ MAY add or omit this sub-TLV from the description of an adjacency.
+ If a router implements traffic engineering, it MUST include this
+ sub-TLV on point-to-point adjacencies.
+
+3.4. Sub-TLV 9: Maximum link bandwidth
+
+ This sub-TLV contains the maximum bandwidth that can be used on this
+ link in this direction (from the system originating the LSP to its
+ neighbors). This is useful for traffic engineering.
+
+ The maximum link bandwidth is encoded in 32 bits in IEEE floating
+ point format. The units are bytes (not bits!) per second.
+
+ This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
+ each extended IS reachability TLV.
+
+3.5. Sub-TLV 10: Maximum reservable link bandwidth
+
+ This sub-TLV contains the maximum amount of bandwidth that can be
+ reserved in this direction on this link. Note that for
+ oversubscription purposes, this can be greater than the bandwidth of
+ the link.
+
+ The maximum reservable link bandwidth is encoded in 32 bits in IEEE
+ floating point format. The units are bytes (not bits!) per second.
+
+ This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
+ each extended IS reachability TLV.
+
+
+
+
+
+
+
+Smit & Li Informational [Page 5]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+3.6. Sub-TLV 11: Unreserved bandwidth
+
+ This sub-TLV contains the amount of bandwidth reservable in this
+ direction on this link. Note that for oversubscription purposes,
+ this can be greater than the bandwidth of the link.
+
+ Because of the need for priority and preemption, each head end needs
+ to know the amount of reserved bandwidth at each priority level.
+ Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers.
+ The units are bytes (not bits!) per second. The values correspond to
+ the bandwidth that can be reserved with a setup priority of 0 through
+ 7, arranged in increasing order with priority 0 occurring at the
+ start of the sub-TLV, and priority 7 at the end of the sub-TLV.
+
+ For stability reasons, rapid changes in the values in this sub-TLV
+ SHOULD NOT cause rapid generation of LSPs.
+
+ This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
+ each extended IS reachability TLV.
+
+3.7. Sub-TLV 18: Traffic Engineering Default Metric
+
+ This sub-TLV contains a 24-bit unsigned integer. This metric is
+ administratively assigned and can be used to present a differently
+ weighted topology to traffic engineering SPF calculations.
+
+ To preclude overflow within a traffic engineering SPF implementation,
+ all metrics greater than or equal to MAX_PATH_METRIC SHALL be
+ considered to have a metric of MAX_PATH_METRIC. It is easiest to
+ select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link
+ metric does not overflow the number of bits for internal metric
+ calculation. We assume that this is 32 bits. Therefore, we have
+ chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
+
+ This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
+ each extended IS reachability TLV. If a link is advertised without
+ this sub-TLV, traffic engineering SPF calculations MUST use the
+ normal default metric of this link, which is advertised in the fixed
+ part of the extended IS reachability TLV.
+
+4. The Extended IP Reachability TLV
+
+ The extended IP reachability TLV is TLV type 135.
+
+ The existing IP reachability TLVs (TLV type 128 and TLV type 130,
+ defined in RFC 1195 [3]) carry IP prefixes in a format that is
+ analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four
+ metrics, of which only the default metric is commonly used. The
+
+
+
+Smit & Li Informational [Page 6]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+ default metric has a possible range of 0-63. We would like to remove
+ this restriction.
+
+ In addition, route redistribution (a.k.a. route leaking) has a key
+ problem that was not fully addressed by the existing IP reachability
+ TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in
+ the level hierarchy. Unfortunately there were no mechanisms defined
+ to advertise prefixes downwards in the level hierarchy.
+
+ To address these two issues, the proposed extended IP reachability
+ TLV provides for a 32 bit metric and adds one bit to indicate that a
+ prefix has been redistributed 'down' in the hierarchy.
+
+ The proposed extended IP reachability TLV contains a new data
+ structure, consisting of:
+
+ 4 octets of metric information
+ 1 octet of control information, consisting of
+ 1 bit of up/down information
+ 1 bit indicating the presence of sub-TLVs
+ 6 bits of prefix length
+ 0-4 octet of IPv4 prefix
+ 0-250 optional octets of sub-TLVs, if present consisting of
+ 1 octet of length of sub-TLVs
+ 0-249 octets of sub-TLVs,
+ where each sub-TLV consists of a sequence of
+ 1 octet of sub-type
+ 1 octet of length of the value field of the sub-TLV
+ 0-247 octets of value
+
+ This data structure can be replicated within the TLV, without
+ exceeding the maximum length of the TLV.
+
+ The 6 bits of prefix length can have the values 0-32 and indicate the
+ number of significant bits in the prefix. The prefix is encoded in
+ the minimal number of octets for the given number of significant
+ bits. This implies:
+
+ Significant bits Octets
+ 0 0
+ 1-8 1
+ 9-16 2
+ 17-24 3
+ 25-32 4
+
+ The remaining bits of prefix are transmitted as zero and ignored upon
+ receipt.
+
+
+
+
+Smit & Li Informational [Page 7]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+ If a prefix is advertised with a metric larger then MAX_PATH_METRIC
+ (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered
+ during the normal SPF computation. This allows advertisement of a
+ prefix for purposes other than building the normal IP routing table.
+
+4.1. The up/down Bit
+
+ If routers were allowed to redistribute IP prefixes freely in both
+ directions between level 1 and level 2 without any additional
+ mechanisms, those routers would not be able to determine looping of
+ routing information. A problem occurs when a router learns a prefix
+ via level 2 routing and advertises that prefix down into a level 1
+ area, where another router might pick up the route and advertise the
+ prefix back up into the level 2 backbone. If the original source
+ withdraws the prefix, those two routers might end up having a routing
+ loop between them, where part of the looped path is via level 1
+ routing and the other part of the looped path is via level 2 routing.
+ The solution that RFC 1195 [3] poses is to allow only advertising
+ prefixes upward in the level hierarchy, and to disallow the
+ advertising of prefixes downward in the hierarchy.
+
+ To prevent this looping of prefixes between levels, a new bit of
+ information is defined in the new extended IP reachability TLV. This
+ bit is called the up/down bit. The up/down bit SHALL be set to 0
+ when a prefix is first injected into IS-IS. If a prefix is
+ advertised from a higher level to a lower level (e.g. level 2 to
+ level 1), the bit MUST be set to 1, indicating that the prefix has
+ traveled down the hierarchy. Prefixes that have the up/down bit set
+ to 1 may only be advertised down the hierarchy, i.e. to lower levels.
+
+ These semantics apply even if IS-IS is extended in the future to have
+ additional levels. By insuring that prefixes follow only the IS-IS
+ hierarchy, we have insured that the information does not loop,
+ thereby insuring that there are no persistent forwarding loops.
+
+ If a prefix is advertised from one area to another at the same level,
+ then the up/down bit SHALL be set to 1. This situation can arise
+ when a router implements multiple virtual routers at the same level,
+ but in different areas.
+
+ The semantics of the up/down bit in the new extended IP reachability
+ TLV are identical to the semantics of the up/down bit defined in RFC
+ 2966 [2].
+
+
+
+
+
+
+
+
+Smit & Li Informational [Page 8]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs
+
+ The extended IP reachability TLV can hold sub-TLVs that apply to a
+ particular prefix. This allows for easy future extensions. If there
+ are no sub-TLVs associated with a prefix, the bit indicating the
+ presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the
+ first octet after the prefix will be interpreted as the length of all
+ sub-TLVs associated with this IPv4 prefix. Please note that while
+ the encoding allows for 255 octets of sub-TLVs, the maximum value
+ cannot fit in the overall extended IP reachability TLV. The
+ practical maximum is 255 octets minus the 5-9 octets described above,
+ or 250 octets.
+
+ This document does not define any sub-TLVs for the extended IP
+ reachability TLV.
+
+5. The Traffic Engineering Router ID TLV
+
+ The Traffic Engineering router ID TLV is TLV type 134.
+
+ The router ID TLV contains the 4-octet router ID of the router
+ originating the LSP. This is useful in several regards:
+
+ For traffic engineering, it guarantees that we have a single stable
+ address that can always be referenced in a path that will be
+ reachable from multiple hops away, regardless of the state of the
+ node's interfaces.
+
+ If OSPF is also active in the domain, traffic engineering can compute
+ the mapping between the OSPF and IS-IS topologies.
+
+ If a router does not implement traffic engineering, it MAY add or
+ omit the Traffic Engineering router ID TLV. If a router implements
+ traffic engineering, it MUST include this TLV in its LSP. This TLV
+ SHOULD not be included more than once in an LSP.
+
+ If a router advertises the Traffic Engineering router ID TLV in its
+ LSP, and if it advertises prefixes via the Border Gateway Protocol
+ (BGP) with the BGP next hop attribute set to the BGP router ID, the
+ Traffic Engineering router ID SHOULD be the same as the BGP router
+ ID.
+
+ Implementations MUST NOT inject a /32 prefix for the router ID into
+ their forwarding table because this can lead to forwarding loops when
+ interacting with systems that do not support this TLV.
+
+
+
+
+
+
+Smit & Li Informational [Page 9]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+6. IANA Considerations
+
+6.1. TLV Codepoint Allocations
+
+ This document defines the following new IS-IS TLV types, which have
+ been reflected in the ISIS TLV code-point registry:
+
+ Type Description IIH LSP SNP
+ ---- ----------------------------------- --- --- ---
+ 22 The extended IS reachability TLV n y n
+ 134 The Traffic Engineering router ID TLV n y n
+ 135 The extended IP reachability TLV n y n
+
+6.2. New Registries
+
+ IANA has created the following new registries.
+
+6.2.1. Sub-TLVs for the Extended IS Reachability TLV
+
+ This registry contains codepoints for Sub-TLVs of TLV 22. The range
+ of values is 0-255. Allocations within the registry require
+ documentation of the proposed use of the allocated value and approval
+ by the Designated Expert assigned by the IESG (see [5]).
+
+ Taking into consideration allocations specified in this document, the
+ registry has been initialized as follows:
+
+ Type Description
+ ---- -----------------------------------
+ 0-2 unassigned
+ 3 Administrative group (color)
+ 4-5 unassigned
+ 6 IPv4 interface address
+ 7 unassigned
+ 8 IPv4 neighbor address
+ 9 Maximum link bandwidth
+ 10 Reservable link bandwidth
+ 11 Unreserved bandwidth
+ 12-17 unassigned
+ 18 TE Default metric
+ 19-254 unassigned
+ 255 Reserved for future expansion
+
+
+
+
+
+
+
+
+
+Smit & Li Informational [Page 10]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+6.2.2. Sub-TLVs for the Extended IP Reachability TLV
+
+ This registry contains codepoints for Sub-TLVs of TLV 135. The range
+ of values is 0-255. Allocations within the registry require
+ documentation of the use of the allocated value and approval by the
+ Designated Expert assigned by the IESG (see [5]).
+
+ No codepoints are defined in this document.
+
+7. References
+
+7.1. Normative References
+
+ [1] ISO, "Intermediate System to Intermediate System Intra-Domain
+ Routeing Exchange Protocol for use in Conjunction with the
+ Protocol for Providing the Connectionless-mode Network Service
+ (ISO 8473)", International Standard 10589:2002, Second Edition
+
+ [2] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
+ Distribution with Two-Level IS-IS", RFC 2966, October 2000.
+
+7.2. Informative References
+
+ [3] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual
+ environments", RFC 1195, December 1990
+
+ [4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus,
+ "Requirements for Traffic Engineering Over MPLS", RFC 2702,
+ September 1999.
+
+ [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+8. Security Considerations
+
+ This document raises no new security issues for IS-IS.
+
+9. Acknowledgments
+
+ The authors would like to thank Yakov Rekhter and Dave Katz for their
+ comments on this work.
+
+
+
+
+
+
+
+
+
+
+Smit & Li Informational [Page 11]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+10. Authors' Addresses
+
+ Henk Smit
+
+ EMail: hhwsmit@xs4all.nl
+
+
+ Tony Li
+
+ EMail: tony.li@tony.li
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smit & Li Informational [Page 12]
+
+RFC 3784 IS-IS extensions for Traffic Engineering June 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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.
+
+
+
+
+
+
+
+
+
+Smit & Li Informational [Page 13]
+