IPoRPR Working Group M. Holness Internet-Draft G. Parsons Expires: January 11, 2006 Nortel July 10, 2005 Mapping of IP/MPLS Packets into IEEE 802.17 (Resilient Packet Ring) Networks draft-ietf-iporpr-basic-00.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 January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a basic standard method of encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient Packet Ring (RPR) datagrams. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Holness & Parsons Expires January 11, 2006 [Page 1] Internet-Draft IPoRPR July 2005 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. The term "Higher Layer" refers to IPv4, IPv6, and MPLS when they act as clients of the IEEE 802.17 network. "IP" refers to both IPv4 and IPv6. The terms "IPv4" and "IPv6" are used only when a specific version of IP is meant. Holness & Parsons Expires January 11, 2006 [Page 2] Internet-Draft IPoRPR July 2005 1. IEEE 802.17 This section gives a brief introduction to the IEEE 802.17 protocol. The intent is to provide information needed to understand the rest of this document. This section is SHALL NOT be used as a definitive description of IEEE 802.17 [2]. IEEE 802.17 SHALL be consulted for specific details on the functionality. Section 5 contains a ~30 page overview of the ~700 page specification. Details on the MAC service is contains in section 6. 1.1 Overview of IEEE 802.17 IEEE 802.17 is a dual, counter-rotating, ring network technology with destination stripping. In the event of a fault (such as a fiber cut) the stations on each side of the fault can continue to function by wrapping the ring and/or by steering away from the fault and towards the operational path. When the fault clears, the ring reverts to normal operation. The ring is composed of two ringlets, called ringlet0 and ringlet1. A station may transmit a frame in either direction around the ring. IEEE 802.17 includes MAC-level protocols to determine the "best" path to each destination. The determination of "best" may be by any of several algorithms, including shortest path. Normally, the 802.17 MAC layer will automatically send frames via the "best" path. Alternatively, higher layers (such as IP) may explicitly specify the ringlet to use. All stations on the ring have 48-bit IEEE 802 addresses. IEEE 802.17 is a media-independent network protocol that is layered over several different physical media. SONET/SDH, Gigabit Ethernet and 10-Gigabit Ethernet are currently specified. The higher layers are shielded from any media dependencies. There are fairness and bandwidth-management elements. There are three service classes: Class A provides low delay and low delay variation, class B has committed and excess bandwidth components, and class C is best-effort. There are several frame types, one of which is a data frame. The data frame contains a payload (such as an IPv4, IPv6, or MPLS packet). The type of the payload is indicated by a 2-byte type field. The type-field is identical to the type field in IEEE 802.3 Ethernet. Holness & Parsons Expires January 11, 2006 [Page 3] Internet-Draft IPoRPR July 2005 There is a TTL in the IEEE 802.17 frame headers. This TTL is used to prevent frames from infinitely looping. 1.2 IEEE 802.17 MAC Service The IEEE 802.17 MAC Service Definition defines the MA_DATA.request primitive which a station uses to transmit data (see section 6.4.1 of [2]). This primitive takes several Parameters (only three of which are mandatory): destination_address source_address optional mac_service_data_unit frame_check_sequence optional service_class ringlet_id optional mac_protection optional mark_fe optional strict_order optional destination_address_extended optional source_address_extended optional flooding_form optional 1.2.1 IEEE 802.17 Addressing The Destination Address (DA) [destination_address] is the 48-bit MAC address of the destination station. This may be a multicast or broadcast address. This address is an IEEE 802 address. This is a required parameter. The Source Address (SA) [source_address] is the 48-bit MAC address of the source station. This address is an IEEE 802 address. This is an optional parameter. If it is omitted, the MAC uses the source address that is assigned to the station. Holness & Parsons Expires January 11, 2006 [Page 4] Internet-Draft IPoRPR July 2005 1.2.2 IEEE 802.17 Payload The MAC SDU [mac_service_data_unit] is the RPR payload. It includes the entire IP/MPLS packet prefaced with the Ethertype field. This is a required parameter. . 1.2.3 IEEE 802.17 Service Classes One of the key features of RPR that can distinguish it from other network interconnects, is it ability to support multiple service qualities. Per service quality flow control protocols regulate traffic introduced by clients. The list of supported service classes are listed below: Class a: Class A services provides an allocated, guaranteed data rate, and low end-to-end delay and jitter bound. Class A traffic is allocated with a committed information rate (CIR). Traffic above the allocated rate is rejected. Class A traffic has precedence over class B and class C traffic at the ingress to the ring. This class is well suited for real time applications. Class b: Class B services provides an allocated, guaranteed data rate, and bounded end-to-end delay and jitter for the traffic within the allocated rate. Class B also provides access to additional best effort data transmission that is not allocated, guaranteed, or bounded. Class B traffic is allocated with a CIR component. Any class B traffic amount beyond the allocated CIR is referred to as excess information rate (EIR) class B traffic. Class B traffic (including class B EIR) has precedence over class C traffic at the ingress to the ring. Class c: Class C services provides a best-effort traffic service with non allocated or guaranteed data rate, and no bounds on end- to-end delay or jitter. Class C traffic has the lowest precedence for ingress to the ring. Both class B EIR and class C traffic is governed by the RPR fairness algorithm which ensures proper partitioning of opportunistic traffic over the ring. This class is well suited for best effort applications. The RPR datagram carries the priority (i.e., service class) of the traffic being transported within a sc (service class) field found within the baseControl field of the RPR header. The RPR sc is a 2-bit field. The values are shown in Table 1 below. Holness & Parsons Expires January 11, 2006 [Page 5] Internet-Draft IPoRPR July 2005 +----------+----------------+ | Value | Name | +==========+================+ | 00 | CLASS_C | +----------+----------------+ | 01 | CLASS_B | +----------+----------------+ | 10 | CLASS_A1 | +----------+----------------+ | 11 | CLASS_A0 | +----------+----------------+ Table 1: sc values 1.2.4 IEEE 802.17 Fairness The RPR fairness algorithm ensures proper partitioning of opportunistic traffic over the ring and governs class B EIR and class C traffic. The RPR datagram conveys the application of the fairness algorithm on the datagram by the value of the fairness eligible (fe) field, found in the baseControl field of the RPR header. The fe (fairness eligible) bit marks whether the frame is subject to the fairness algorithm. A value of 0 indicates that the frame is not fairness eligible, while a value of 1 indicates that the frame is fairness eligible. Holness & Parsons Expires January 11, 2006 [Page 6] Internet-Draft IPoRPR July 2005 2. General Mapping Details This section covers issues that are common to IPv4, IPv6, and MPLS. 2.1 IEEE 802.17 MAC Service Parameters When transmitting an IP or MPLS packet, a host or router indicates various parameters to the IEEE 802.17 MAC layer (see section 6.4 of [2]). This section specifies how those parameters are to be used: 2.1.1 Destination_address Is the 48-bit MAC address of the 802.17 station to which the packet is being transmitted. 2.1.2 Source_address The source_address SHOULD be the address assigned to the station that is transmitting the packet. Per [2] if the client omits this parameter then the MAC inserts the correct address. 2.1.3 mac_service_data_unit This is the payload, including the Ethernet type field. See "Protocol Type Field" (Section 2.2), for more information. 2.1.4 frame_check_sequence The MAC will calculate the FCS 2.1.5 serviceClass Specific service class mapping from DSCP and EXP within the client payload SHOULD be used to determine the RPR service class. These mappings are shown in Section 3.2 and Section 5.1. 2.1.6 Ringlet_id The client SHOULD NOT specify the ringletID. The MAC will use its default algorithm to select a ringlet. 2.1.7 mac_protection This is set by the MAC to indicate if RPR protection is used for the frame. Holness & Parsons Expires January 11, 2006 [Page 7] Internet-Draft IPoRPR July 2005 2.1.8 mark_fe This parameter SHOULD NOT be specified unless the RPR service class is CLASS B as indicated from the mappings in Section 3.2 and Section 5.1. 2.1.9 strict_order This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will then use its default treatment. 2.1.10 destination_address_extended This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary. 2.1.11 source_address_extended This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary. 2.1.12 flooding_form This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary. 2.2 Protocol Type Field The 16-bit protocol type field (or Ethertype) is set to a value to indicate the payloads protocol. The values for IPv4, IPv6, and MPLS are: 0x0800 If the payload contains an IPv4 packet. 0x0806 If the payload contains an ARP packet. 0x86DD If the payload contains an IPv6 packet. 0x8847 If the payload contains a MPLS Unicast packet. 0x8848 if the payload contains a MPLS Multicast packet. 0x8100 if the payload contains an Ethernet VLAN/Priority tagged packet. Holness & Parsons Expires January 11, 2006 [Page 8] Internet-Draft IPoRPR July 2005 2.3 Payload The payload contains the IPv4, IPv6, or MPLS packet. The first byte of the IPv4 header, IPv6 header, or top MPLS label begins immediately after the 802.17 headers. Note that in 802.17 there is no minimum size for frames carried over Ethernet physical layers, thus there is no need to pad frames that are shorter than the minimum size. However, the robustness principle dictates that nodes be able to handle frames that are padded. Like 802.3 Ethernet, 802.17 defines the maximum regular frame payload as 1500 bytes. Note that a maximum jumbo frame payload size that MAY be supported is defined at 9100 bytes. 2.4 Byte Order As described in "APPENDIX B: Data Transmission Order" of RFC 791 [3], IP and MPLS datagrams are transmitted over the IEEE 802.17 network as a series of 8-bit bytes in "big endian" order. This is the same byte order as used for Ethernet. 2.5 Trailer Format Trailer encapsulation is NOT specified for IEEE 802.17 networks. 2.6 Ringlet and Direction Selection IEEE 802.17 allows the Higher Layer to select the direction around the ring that traffic is to go. If the Higher Layer does not make the selection then the IEEE 802.17 MAC makes the decision. Ringlet and Direction selection are left to the MAC. The advanced version of this specification may change this. 2.7 Higher Layer TTL and Ring TTL There is no correlation or interaction between the Higher Layer TTL and the IEEE 802.17 TTL. Holness & Parsons Expires January 11, 2006 [Page 9] Internet-Draft IPoRPR July 2005 3. IPv4 Specific Mapping Details 3.1 Address Resolution ARP [4] is used to map IPv4 addresses to the appropriate MAC address. The "Hardware Address Space" parameter (ar$hrd) used for IEEE 802.17 networks is TBD. ARP parameter assignments may be found at IANA. 3.1.1 Editor's Notes The hardware type is to be allocated by IANA prior to publication. We could overload the Ethernet (1) or IEEE 802 (6) hardware type value since 802.17 addresses are the same size and format as Ethernet addresses. However, it is not inconceivable that overloading this value may turn out to have unforeseen undesired consequences. As we are not in any danger of running out of ARP hardware codes, we'll get an 802.17-specific one. 3.2 IP Differentiated Service (DSCP) Mapping to RPR The Differentiated Service (DS) field of the IPv4 and IPv6 frame can be used to convey service priority. The format of the IP DS field is shown in Figure 1 below. | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |-----------------------------------|-----------| | DSCP | ECN | |-----------------------------------|-----------| Figure 1: Differentiated Services Field The DSCP field denotes the differentiated services codepoint. The DSCP is used to select the per hop behavior a packet experiences at each network node. As per [6], [7], [8] and [9], the DSCP field description is illustrated in Table 2. Holness & Parsons Expires January 11, 2006 [Page 10] Internet-Draft IPoRPR July 2005 |---------------------|----------|-------------------| | IP Service Class | DSCP | Per Hop Behaviour | |=====================|==========|===================| | Standard | 000000 | Best effort | | |----------|-------------------| | Low Priority Data | 001000 | Class Selector 1 | |---------------------|----------| | | High Throughput | 001010 | AF11 | | Data | 001100 | AF12 | | | 001100 | AF13 | |---------------------|----------|-------------------| | OAM | 010000 | Class Selector 2 | |---------------------|----------| | | | 010010 | AF21 | | Low Latency Data | 010100 | AF22 | | | 010110 | AF23 | |---------------------|----------|-------------------| | Broadcast Video | 011000 | Class Selector 3 | |---------------------|----------| | | Multimedia | 011010 | AF31 | | Streaming | 011100 | AF32 | | | 011110 | AF33 | |---------------------|----------|-------------------| |Real-time Interactive| 100000 | Class Selector 4 | |---------------------|----------| | | Multimedia | 100010 | AF41 | | Conferencing | 100100 | AF42 | | | 100110 | AF43 | |---------------------|----------|-------------------| | Signaling | 101000 | Class Selector 5 | |---------------------|----------| | | Telephony | 101110 | EF | |---------------------|----------|-------------------| | Network Control | 110000 | Class Selector 6 | |---------------------|----------|-------------------| | Reserved | 111000 | Class Selector 7 | | for future use | | | |---------------------|----------|-------------------| Table 2: DSCP Field Definition The best effort DSCP group denotes a best effort service. The Assured Forwarding (AF) PHB groups are a means for a provider DS domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain. In case of congestion, the drop precedence of a packet determines the relative importance of Holness & Parsons Expires January 11, 2006 [Page 11] Internet-Draft IPoRPR July 2005 the packet within the AF class. A congested DS node tries to protect packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value. The Expedited Forwarding (EF) PHB group is used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. The Class Selector PHBs are to provide limited backwards capability for IP precedence. The mapping between IP DSCP to RPR header service class relevant fields are shown in Table 3. Note that four treatment aggregates are used as suggested by [10]. Holness & Parsons Expires January 11, 2006 [Page 12] Internet-Draft IPoRPR July 2005 |----------|-------------------|--------|---------------| | DSCP | RPR Service Class | RPR sc | RPR fe | |==========|===================|========|===============| | 000000 | Class C | 00 | 1 | | 001000 | | | | |----------|-------------------|--------|---------------| | 001010 | | | 0-Class B CIR | | | | |---------------| | 001100 | | | 1-Class B EIR | | 001100 | | | | |----------| | |---------------| | 010000 | | | 0-Class B CIR | |----------| | |---------------| | 010010 | | | | | 010100 | | | 1-Class B EIR | | 010110 | Class B | | | |----------| | |---------------| | 011010 | | | 0-Class B CIR | | | | |---------------| | 011100 | | | 1-Class B EIR | | 011110 | | | | |----------| | |---------------| | 100010 | | | 0-Class B CIR | | | | |---------------| | 100100 | | | 1-Class B EIR | | 100110 | | | | |----------|-------------------|--------|---------------| | 011000 | | | | |----------| | | | | 100000 | Class A0 | 11 | | |----------| or | or | 0 | | 101000 | Class A1 | 10 | | |----------| | | | | 101110 | | | | |----------|-------------------|--------|---------------| | | Class A0 | 11 | | | 110000 | or | or | 0 | | | Class A1 | 10 | | |----------|-------------------|--------|---------------| Table 3: IP DSCP to RPR Header Mapping Internal to the RPR MAC, Class A traffic is partitioned into two sub classes: Class A0 and Class A1. This partitioning is done in order to increase the ability of the ring to reclaim unused Class A traffic. The RPR MAC is configured for a total Class A amount, from which it determines how much is Class A0 and ClassA1. The division Holness & Parsons Expires January 11, 2006 [Page 13] Internet-Draft IPoRPR July 2005 of Class A is based on ring circumference and the size of internal transit queues. The reclaimable bandwidth allocated to Class A1 can be reclaimed by traffic of Class B-EIR and Class C when not being used by the station originating the Class A traffic being reclaimed. Services marked with a DF and CS1 DSCP do not have a small amount of assured bandwidth component. That is, it only has an EIR component. Services marked with AF1x, AF2x, AF3x, AF4x and CS2 DSCPs have an aggregate CIR and EIR component. Services marked with CS3, CS4, CS5 and EF DSCPs only have a CIR component. Routing traffic marked with CS6 DSCP class also only has a CIR component. As CS7 is for future use, no mapping is provided. As per [11], bits 6 and 7 of the DS field can be defined to be the Explicit Congestion Notification (ECN) field. The coding of the ECN does not influence the mappings to the RPR service class relevant fields (listed in Table 3). Holness & Parsons Expires January 11, 2006 [Page 14] Internet-Draft IPoRPR July 2005 4. IPv6 Specific Details Transport of IPv6 packets over IEEE 802.17 networks is designed to be as similar to IPv6 over Ethernet as possible. The intent is to minimize time and risk in developing both the standard and the implementations. 4.1 Stateless Autoconfiguration IPv6 stateless autoconfiguration follows the rules and procedures in section 4 of RFC 2464 [5]. 4.2 Link Local Address IPv6 link-local addresses follow the rules and procedures in section 5 of RFC 2464 [5]. 4.3 Unicast Address Mappings IPv6 unicast address mappings follow the rules and procedures in section 6 of RFC 2464 [5]. 4.4 Multicast Address Mappings IPv6 multicast address mappings follow the rules and procedures in section 7 of RFC 2464 [5]. 4.5 Diffserv mapping The mapping is as specified in Section 3.2 Holness & Parsons Expires January 11, 2006 [Page 15] Internet-Draft IPoRPR July 2005 5. MPLS Specific Details Transport of MPLS packets over IEEE 802.17 follows RFC 3032 [12]. As with IPv6, the intent is to allow the IEEE 802.17 network to be treated as a simple Ethernet LAN. 5.1 MPLS EXP bit Mapping to RPR MPLS support for DiffServ is defined in RFC 3270 [13]. The MPLS shim header is illustrated in Figure 2 below. | 20 | 3 | 1 | 8 | |----------------------------|---------|-----|---------------| | Label | EXP | S | TTL | |----------------------------|---------|-----|---------------| Figure 2: MPLS shim The EXP bits define the PHB. However [12]does not recommend specific EXP values for DiffServ PHB (e.g., EF, AF, DF). 5.1.1 MPLS EXP PHB Mapping to RPR The mapping between MPLS EXP bits to RPR header service class relevant fields are shown in Table 4. Note that four treatment aggregates are used as suggested by [10]. |-------------|-------------------|--------|---------------| | MPLS EXP | RPR Service Class | RPR sc | RPR fe | |=============|===================|========|===============| | 000 | Class C | 00 | 1 | | 001 | | | | |-------------|-------------------|--------|---------------| | 010 | Class B | 01 | 0-Class B CIR | | 011 | | | 1-Class B EIR | |-------------|-------------------|--------|---------------| | 100 | Class A0 | 11 | | | | or | or | 0 | |101(reserved)| Class A1 | 10 | | |-------------|-------------------|--------|---------------| | 110 | Class A0 | 11 | | | | or | or | 0 | |111(reserved)| Class A1 | 10 | | |-------------|-------------------|--------|---------------| Table 4: MPLS EXP to RPR Header Mapping Holness & Parsons Expires January 11, 2006 [Page 16] Internet-Draft IPoRPR July 2005 6. Ethernet Specific Details Encapsulation of Ethernet packets over IEEE 802.17 is fairly simple since they are both 802 MACs and can be either transparently mapped or bridged. Details of address translation, priority mappings and learning are fully described in IEEE 802.17 [2], IEEE 802.17a [14], and IEEE 802.17b [15] Holness & Parsons Expires January 11, 2006 [Page 17] Internet-Draft IPoRPR July 2005 7. Security Considerations This specification provides no security measures. In particular: 1. Masquerading and spoofing are possible. There is no strong authentication. 2. Traffic analysis and snooping is possible since no encryption is provided, either by this specification or by IEEE 802.17 3. Limited denial of Service attacks are possible by, eg, flooding the IEEE 802.17 network with ARP broadcasts. These attacks are limited to other class-C (best effort) traffic. 4. Attacks against the IEEE 802.17 ring management protocols are possible by stations that are directly connected to the ring. We note that all of these vulnerabilities exist today for transport of IP and MPLS over Ethernet networks. Holness & Parsons Expires January 11, 2006 [Page 18] Internet-Draft IPoRPR July 2005 8. IANA Considerations A new ARP codepoint is to be assigned by IANA per Section 3.1 Holness & Parsons Expires January 11, 2006 [Page 19] Internet-Draft IPoRPR July 2005 9. Acknowledgements The authors acknowledge and appreciate the work and comments of the IETF IPoRPR working group and the IEEE 802.17 working group. 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, BCP 14, March 1997. [2] "Resilient Packet Ring Access Method and Physical Layer Specifications - medium access control parameters, physical layer interface, and management parameters", IEEE 802.17-2004, July 2004. [3] Postel, J., "Internet Protocol", RFC 791, September 1981. [4] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [5] Crawford, ., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [6] Nichols, K., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.", RFC 2474, December 1998. [7] Heinanen, J., "Assured Forwarding PHB Group.", RFC 2597, June 1999. [8] Jacobson, V., "An Expedited Forwarding PHB Group.", RFC 2598, June 1999. [9] Babiarz, J., "Configuration Guidelines for Diffserv Service Classes", draft-ietf-tsvwg-diffserv-service-classes-00 (work in progress), June 2005. [10] Chan, K., "Aggregation of Diffserv Service Classes.", draft-chan-tsvwg-diffserv-class-aggr-01 (work in progress), February 2005. [11] Ramakrishnan, K., "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [12] Rosen, E., "MPLS Label Stack Encoding", RFC 3032, January 2001. [13] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. Holness & Parsons Expires January 11, 2006 [Page 20] Internet-Draft IPoRPR July 2005 [14] "Media Access Control (MAC) Bridges - Amendment 1: Bridging of 802.17", IEEE 802.17a-2004, October 2004. [15] "Resilient Packet Ring Access Method and Physical Layer Specifications - Amendment 1: Spatially Aware Sublayer", IEEE P802.17b. Authors' Addresses Marc Holness Nortel 3500 Carling Avenue Ottawa, ON K2H 8E9 CA Phone: +1 613 765 2840 Email: holness@nortel.com Glenn Parsons Nortel 3500 Carling Avenue Ottawa, ON K2H 8E9 CA Phone: +1 613 763 7582 Email: gparsons@nortel.com Holness & Parsons Expires January 11, 2006 [Page 21] Internet-Draft IPoRPR July 2005 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Holness & Parsons Expires January 11, 2006 [Page 22]