Network Working Group S. Mirtorabi Internet-Draft A. Roy Expires: September 5, 2006 N. Shen A. Lindem Cisco Systems March 4, 2006 Extensions to OSPFv2 for Advertising Optional Route/Link Attributes draft-mirtorabi-ospf-tag-02.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 September 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract There are applications which require additional attributes to be advertised with an OSPF link or route. 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 route. It also introduces the support of administrative tags for any link Mirtorabi, et al. Expires September 5, 2006 [Page 1] Internet-Draft OSPFv2 Route/Link Attributes March 2006 type in the router-LSA and any route 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 3. Link Attribute TLV (LA-TLV) . . . . . . . . . . . . . . . . . 7 4. Inter-Area/External Route Attribute TLV (RA-TLV) . . . . . . . 8 5. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 MT-ID sub-TLV . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Tag sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 9 5.3 Extended Tag sub-TLV . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Mirtorabi, et al. Expires September 5, 2006 [Page 2] Internet-Draft OSPFv2 Route/Link Attributes March 2006 1. Introduction There are applications which require the advertisement of additional attributes associated with an OSPF link or route. This document enhances the support for administrative tags for OSPF routes. Prior to this enhancement, a single tag can be advertised for AS external and NSSA routes. Now multiple tags and extended tags may be advertised for intra-area, inter-area, AS external, or NSSA routes. Future applications could introduce new link or route 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 September 5, 2006 [Page 3] Internet-Draft OSPFv2 Route/Link Attributes March 2006 2. OSPF Router Attributes (RA) Opaque LSA OSPF routers will optionally advertise additional link/route 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. The attribute LSA type is specifically coded in opaque ID (see below) allowing direct mapping of an RA LSA to a given LSA type. For certain applications the additional route 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 divided into one byte Attribute type and two bytes of unique ID. The Attribute LS type will correspond to the LSA type for the link(s) or route(s) to which the advertised attributes apply. For example, if the RA LS contains attributes corresponding to router links, the attribute LS type is 1. Attribute LS Type Corresponding LSA Type --------------------------------------------------- 1 Router-LSA [OSPF] 2 Network-LSA [OSPF] 3 Summary-LSA (IP Network) [OSPF] 5 AS-External-LSA [OSPF] 7 NSSA-LSA [NSSA] The unique ID has no topological significance and is used solely to distinguish multiple RA LSAs with the same attribute type. The body of this LSA is made up of one or more TLVs. Mirtorabi, et al. Expires September 5, 2006 [Page 4] Internet-Draft OSPFv2 Route/Link Attributes March 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10, or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Attr LS type | Unique ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV's | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the TLV's 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: 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 TLV's 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: Mirtorabi, et al. Expires September 5, 2006 [Page 5] Internet-Draft OSPFv2 Route/Link Attributes March 2006 TLV-type Definition ----------------------------------------------- 1 Link attribute TLV 2 Inter-area route attribute 3 External route attribute 4 NSSA External route attribute Note that a type 3 link in a Router-LSA carries intra-area route. Therefore, TLV-type 1 can advertise both link attributes and intra- area route attributes. Mirtorabi, et al. Expires September 5, 2006 [Page 6] Internet-Draft OSPFv2 Route/Link Attributes March 2006 3. Link Attribute TLV (LA-TLV) This TLV appears in RA LSA with Attr LS type set to 1 and allows one of more attributes to be associated with a link or an intra-area route. The format of this TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | link-type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link-type This field is as defined in Router-LSA in [OSPF]. Unknown link- types MUST be ignored. Reserved Reserved field. 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 September 5, 2006 [Page 7] Internet-Draft OSPFv2 Route/Link Attributes March 2006 4. Inter-Area/External Route Attribute TLV (RA-TLV) This TLV appears in RA LSA with "Attr LS type" set to 3/5/7 allowing one or more attributes to be associated with an inter-area, NSSA, or external routes. The format of this TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2/3/4 | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R| P-length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 value range are 0-32. Reserved Reserved field. 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. One or more RA-TLV of same type MUST appear in the corresponding RA LSA. For example, RA-TLV type 2 (Inter-area route attribute) MUST appear in an RA LSA with Attr LS type set to 3. RA LSAs not meeting this constraint will be flooded normally but will be ignored for purposes of route and link attribute determination. Mirtorabi, et al. Expires September 5, 2006 [Page 8] Internet-Draft OSPFv2 Route/Link Attributes March 2006 5. Sub-TLVs The following sub-TLV area defined for inclusion in the LA-TLV and RA-TLV. sub-TLV-type Definition ----------------------------------------------- 1 MT-ID 2 Tag 3 Extended tag 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 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 Reserved field. It should be set to 0 and ignored upon reception. 5.2 Tag sub-TLV This sub-TLV allows one or more tags to be advertised for a route. Note that for intra-area routes, this sub-TLV is used for transit and stub links (link-types 2 and 3). Also, note that the Tag sub-TLV (type 1) is not required for the first tag for NSSA and external routes since AS-external-LSAs and NSSA-LSAs already contain a tag Mirtorabi, et al. Expires September 5, 2006 [Page 9] Internet-Draft OSPFv2 Route/Link Attributes March 2006 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 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 route. Note that for intra-area routes this sub-TLV is used for transit and stub links (Link-types 2 and 3). The format of this sub- TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended tag | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended tag | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Tag A 64-bit configurable value set by the user. Mirtorabi, et al. Expires September 5, 2006 [Page 10] Internet-Draft OSPFv2 Route/Link Attributes March 2006 6. Generation of RA-LSAs A router configured to advertise route 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 routes 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 route 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 route and handled in an application specific manner. Mirtorabi, et al. Expires September 5, 2006 [Page 11] Internet-Draft OSPFv2 Route/Link Attributes March 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 routes 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 route. o Originate an RA AS-scoped opaque LSA when it originates an AS- external-LSA corresponding to a translated NSSA route. 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 route attributes the ABR advertises is a matter of local policy. Options include: o Propagate attributes from the corresponding route. o Inhibit propagation of route attributes. o Advertise an alternate set of attributes based on local configuration. This set MAY include a subset or super-set of the route's attributes. For ABRs supporting the RA extension, the default is to propagate the route's existing attributes Mirtorabi, et al. Expires September 5, 2006 [Page 12] Internet-Draft OSPFv2 Route/Link Attributes March 2006 8. AS Boundary Router (ASBR) Operations ASBRs supporting the RA extension MAY advertise additional route attributes for routes redistributed or imported from other protocol instances. This is simply a generalization of what is done today for the route tag. Through local configuration, advertised route attributes MAY be propagated from the redistributed route, omitted, or added to the redistributed route's attributes. Mirtorabi, et al. Expires September 5, 2006 [Page 13] Internet-Draft OSPFv2 Route/Link Attributes March 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 September 5, 2006 [Page 14] Internet-Draft OSPFv2 Route/Link Attributes March 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 September 5, 2006 [Page 15] Internet-Draft OSPFv2 Route/Link Attributes March 2006 11. Security Considerations This document does not raise any security issues that are not already covered in [OSPF]. Mirtorabi, et al. Expires September 5, 2006 [Page 16] Internet-Draft OSPFv2 Route/Link Attributes March 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 OSPF WG review. 2. Registry for OSPF RA SubTLVs - The values of 1-2 are defined herein. All SubTLV additions are subject to OSPF WG review. 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. Authors' Addresses Sina Mirtorabi Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: sina@cisco.com Mirtorabi, et al. Expires September 5, 2006 [Page 17] Internet-Draft OSPFv2 Route/Link Attributes March 2006 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 September 5, 2006 [Page 18] Internet-Draft OSPFv2 Route/Link Attributes March 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 September 5, 2006 [Page 19] Internet-Draft OSPFv2 Route/Link Attributes March 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mirtorabi, et al. Expires September 5, 2006 [Page 20]