Network Working Group S. Mirtorabi Internet-Draft Force10 Networks Intended status: Standards Track A. Roy Expires: April 22, 2007 N. Shen A. Lindem Cisco Systems October 19, 2006 Extensions to OSPFv2 for Advertising Optional Prefix/Link Attributes draft-mirtorabi-ospf-tag-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Mirtorabi, et al. Expires April 22, 2007 [Page 1] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 Abstract There are applications that require additional attributes to be advertised with an OSPF link or prefix. The existing OSPF LSA formats do not allow for backward compatible extension to advertise these attributes. This draft proposes an extension to OSPF for advertising additional attributes which will be associated with a link or prefix. It also introduces the support of administrative tags for any link type in the prefix-LSA and any prefix in summary- LSAs, NSSA-LSAs, or AS-external-LSAs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. OSPF Router Attributes (RA) Opaque LSA . . . . . . . . . . . . 4 2.1. TLV Advertisement Granularity . . . . . . . . . . . . . . 5 3. Link Attribute TLV (LA-TLV) . . . . . . . . . . . . . . . . . 6 4. Inter-Area/External Prefix Attribute TLV (PA-TLV) . . . . . . 7 5. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. MT-ID sub-TLV . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Tag sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Extended Tag sub-TLV . . . . . . . . . . . . . . . . . . . 9 6. Generation of RA-LSAs . . . . . . . . . . . . . . . . . . . . 11 7. Generation of RA-LSA across Area Boundaries . . . . . . . . . 12 8. AS Boundary Router (ASBR) Operations . . . . . . . . . . . . . 13 9. Multi-access Link Considerations . . . . . . . . . . . . . . . 14 10. Backward Compatibility/Deployment Considerations . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Mirtorabi, et al. Expires April 22, 2007 [Page 2] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 1. Introduction There are applications which require the advertisement of additional attributes associated with an OSPF link or prefix. This document enhances the support for administrative tags for OSPF prefixes. Prior to this enhancement, a single tag can be advertised for AS external and NSSA prefixes. Now multiple tags and extended tags may be advertised for intra-area, inter-area, AS external, or NSSA prefixes. Future applications could introduce new link or prefix attributes. 1.1. Requirements notation 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 RFC2119 [RFC2119]. Mirtorabi, et al. Expires April 22, 2007 [Page 3] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 2. OSPF Router Attributes (RA) Opaque LSA OSPF prefixes will optionally advertise additional link/prefix attributes in an area-scoped or AS-scoped opaque-LSA [OPAQUE]. The advertising OSPF router will originate an area-scoped (type 10) opaque LSA to associate additional attributes with one or more self- originated area scoped LSAs. An AS-scoped (type 11) Opaque-LSA will be originated to associate additional attributes with one or more self-originated AS scoped LSAs. For certain applications the additional prefix attributes may only need to be advertised to an adjacent neighbor. In this case, a link- scoped (type 9) opaque LSA may originated instead of an area-scoped (type 10) or AS-scoped (type 11) opaque LSA. The Router Attributes (RA) LSA will have an LSDB Opaque type of 5. The remainder of LSID or Opaque ID is a unique 24-bit identifier. This unique ID has no topological significance and is used solely to distinguish multiple RA LSAs originated by a single router. The body of this LSA is made up of one or more TLVs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10, or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Unique ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Attributes Opaque LSA The format of the TLVs within the body of a router attributes LSA is the same as the format used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. The LSA payload consists of one or more nested Type/ Length/Value (TLV) triplets. The format of each TLV/sub-TLV is: Mirtorabi, et al. Expires April 22, 2007 [Page 4] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Format The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. For example, a one-byte value would have the length field set to 1, and three bytes of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored. The following TLV-type are defined: TLV-type Definition ----------------------------------------------- 1 Link attribute TLV 2 Inter-area prefix attribute 3 External prefix attribute 4 NSSA External prefix attribute TLV Types Note that a type 3 link in a Router-LSA carries intra-area prefix. Therefore, TLV-type 1 can advertise both link attributes and intra- area prefix attributes. 2.1. TLV Advertisement Granularity The intent is to maintain a loose correspondence between prefix/link attributes and base OSPF LSAs. Hence, a given LSA MUST only advertise a single TLV type of the types 1-4. However, while the base LSA types 3, 5, and 7 only advertise a single prefix, an implementation MAY advertise attributes for multiple prefixes in a single RA opaque LSA. This optimization represents a trade-off between encoding compactness and how much information is readvertised when attributes for a single prefix change. Mirtorabi, et al. Expires April 22, 2007 [Page 5] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 3. Link Attribute TLV (LA-TLV) This TLV appears in RA LSA and allows one of more attributes to be associated with a link or an intra-area prefix. The format of this TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | link-type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Attribute TLV Format Link-type This field is as defined in Router-LSA in [OSPF]. Unknown link- types MUST be ignored. Reserved This field is reserved. It should be set to 0 and ignored upon reception. Link ID This field is as defined in Router-LSA in [OSPF]. Link Data This field is as defined in Router-LSA in [OSPF]. sub-TLVs This field is the same as TLV and could further contain sub-TLVs. See section 5 for sub-TLVs. At least one sub-TLV must be present. The combination of [Link-type, Link ID, Link Data] uniquely identifies a link description in the corresponding Router-LSA. Mirtorabi, et al. Expires April 22, 2007 [Page 6] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 4. Inter-Area/External Prefix Attribute TLV (PA-TLV) This TLV allows one or more attributes to be associated with an inter-area, NSSA, or external prefix. The format of this TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2/3/4 | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R| P-length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inter-Area/External Prefix Attribute TLV Format Link State ID This field is as defined in summary-LSA, NSSA-LSA, or AS-external- LSA as defined in [OSPF]. R Bits Reserved, they are set 0 and ignored in reception. P-length This fields indicates the length of prefix carried in Link state ID field. The valid range for the length is 0-32. Reserved This field is reserved. It should be set to 0 and ignored upon reception. sub-TLVs This field is the same as TLV and could further contain sub-TLVs. See section 5 for sub-TLV. At least one sub-TLV must be present. Mirtorabi, et al. Expires April 22, 2007 [Page 7] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 5. Sub-TLVs The following sub-TLV area defined for inclusion in the LA-TLV and PA-TLV. sub-TLV-type Definition ----------------------------------------------- 1 MT-ID 2 Tag 3 Extended tag Sub-TLV types 5.1. MT-ID sub-TLV This sub-TLV advertises attributes corresponding to topologies other than the Default topology as defined in [MT-OSPF]. The MT-ID identifies the topology as defined in [MT-OSPF]. Since this TLV advertises attributes to be associated with the prefix or link within a topology, nested Sub-TLVs SHOULD be advertised. Attributes for the Default topology (MT-ID 0) SHOULD NOT be advertised using this sub- TLV. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MT-ID sub-TLV Format MT-ID Multi-topology identifier as defined in [MT-OSPF]. The valid MT-ID range is [1-127]. If a value outside the valid range is specified, the sub-TLV and all nested sub-TLVs will be ignored. Reserved This field is reserved. It should be set to 0 and ignored upon reception. Mirtorabi, et al. Expires April 22, 2007 [Page 8] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 5.2. Tag sub-TLV This sub-TLV allows one or more tags to be advertised for a prefix or link. Note that the Tag sub-TLV (type 1) is not required for the first tag for NSSA and external prefixes since AS-external-LSAs and NSSA-LSAs already contain a tag field. For backward compatibility, the existing tag field SHOULD be used for the first tag and the tag SHOULD NOT be readvertised using this sub-TLV. The sub-TLV MAY be used to advertise any additional tags needed for those LSA types. The format of this sub-TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag sub-TLV Format Tag A 32-bit configurable value set by the user. 5.3. Extended Tag sub-TLV This sub-TLV allows one or more extended tags to be advertised for a prefix. The format of this sub-TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended tag | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended tag | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Tag sub-TLV Format Mirtorabi, et al. Expires April 22, 2007 [Page 9] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 Extended Tag A 64-bit configurable value set by the user. Mirtorabi, et al. Expires April 22, 2007 [Page 10] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 6. Generation of RA-LSAs A router configured to advertise prefix attributes, generates Router Attribute LSAs corresponding to links or prefixes advertised in its LSAs. The attribute LS type in RA-LSA header corresponds to the LS type advertised by the router. All attributes of a link or prefix MUST be advertised in a single Router Attribute LSA. A single RA LSA may include attributes for one or more prefixes or links. RA-LSAs should be regenerated only when there is a change in an attribute value. On a multi-access link, the DR is responsible for advertised attributes for the prefix corresponding to the transit link. If attributes are to be advertised all routers eligible to become DR MUST be configured to advertise them. If an LSA is selected for use by a router then additional attributes in the RA opaque LSA will be associated with the prefix and handled in an application specific manner. Mirtorabi, et al. Expires April 22, 2007 [Page 11] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 7. Generation of RA-LSA across Area Boundaries OSPF Area Border Routers (ABRs) supporting RA opaque LSAs MAY originate an RA opaque LSA when they propagate prefixes from one area to another. This implies that the ABR MAY: o Originate an RA area-scoped opaque LSA when it originates a summary-LSA (type 3 or 4) for an intra-area or inter-area prefix. o Originate an RA AS-scoped opaque LSA when it originates an AS- external-LSA corresponding to a translated NSSA prefix. o Originate an RA area-scoped opaque LSA when it originates a summary-LSA for an area range and policy dictates that the ABR should associate additional attributes with the area range. o Originate an RA AS-scoped opaque LSA when it originates an AS- external-LSA for an NSSA area range and policy dictates that the ABR should associate additional attributes with the NSSA area range. Whether and which prefix attributes the ABR advertises is a matter of local policy. Options include: o Propagate attributes from the corresponding prefix. o Inhibit propagation of prefix attributes. o Advertise an alternate set of attributes based on local configuration. This set MAY include a subset or super-set of the existing prefix attributes. For ABRs supporting the RA extension, the default is to propagate the existing prefix attributes Mirtorabi, et al. Expires April 22, 2007 [Page 12] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 8. AS Boundary Router (ASBR) Operations ASBRs supporting the RA extension MAY advertise additional prefix attributes for prefixes redistributed or imported from other protocol instances. This is simply a generalization of what is done today for the prefix tag. Through local configuration, advertised prefix attributes MAY be propagated from the redistributed prefix, omitted, or added to the redistributed prefix attributes. Mirtorabi, et al. Expires April 22, 2007 [Page 13] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 9. Multi-access Link Considerations In order to associate attributes with prefixes multi-access links, the Designated Router (DR) SHOULD be capable of the RA extension. This is accomplished by advertising a link type of 2 in the Link Attribute TLV. Mirtorabi, et al. Expires April 22, 2007 [Page 14] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 10. Backward Compatibility/Deployment Considerations This document does not introduce any backward compatibility issues. The new LSA is simply ignored by non-capable routers. Attribute capable routers could be introduced gradually without any interoperability problem. It should be noted that in order to convey the attributes across an area boundary, the ABRs MUST be RA capable so that attributes can be propagated to multiple areas. Mirtorabi, et al. Expires April 22, 2007 [Page 15] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 11. Security Considerations This document does not raise any security issues that are not already covered in [OSPF]. Mirtorabi, et al. Expires April 22, 2007 [Page 16] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 12. IANA Considerations The following IANA assignments are to be made from existing registries: 1. The OSPFv2 opaque LSA type 5 will need to be reserved for the OSPFv2 RA opaque LSA. New registries are defined for the following purposes: 1. Registry for OSPF RA TLVs - The values of 1-4 are defined herein. All TLV additions are subject to review by an expert designated by the IESG. 2. Registry for OSPF RA Sub-TLVs - The values of 1-2 are defined herein. All Sub-TLV additions are subject to review by an expert designated by the IESG. Mirtorabi, et al. Expires April 22, 2007 [Page 17] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 13. Normative References [MT-OSPF] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", draft-ietf-ospf-mt-06.txt (work in progress). [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. Mirtorabi, et al. Expires April 22, 2007 [Page 18] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 Appendix A. Acknowledgments Thanks to Liem Nguyen and Peter Psenak for their comments. The RFC text was produced using Marshall Rose's xml2rfc tool. Mirtorabi, et al. Expires April 22, 2007 [Page 19] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 Authors' Addresses Sina Mirtorabi Force10 Networks 1440 McCarthy Blvd Milpitas, CA 95035 USA Email: sina@force10networks.com Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: akr@cisco.com Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: naiming@cisco.com Acee Lindem Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA Email: acee@cisco.com Mirtorabi, et al. Expires April 22, 2007 [Page 20] Internet-Draft OSPFv2 Prefix/Link Attributes October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mirtorabi, et al. Expires April 22, 2007 [Page 21]