IPoRPR Working Group M. Holness Internet-Draft G. Parsons Intended status: Standards Track Nortel Expires: February 22, 2007 August 21, 2006 Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks draft-ietf-iporpr-basic-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 February 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Holness & Parsons Expires February 22, 2007 [Page 1]
Internet-Draft IPoRPR August 2006 Abstract This document specifies a basic standard method of encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient packet ring (RPR) datagrams. Holness & Parsons Expires February 22, 2007 [Page 2]
Internet-Draft IPoRPR August 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [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 February 22, 2007 [Page 3]
Internet-Draft IPoRPR August 2006 1. Introduction This document gives a definition of how to transport IP/MPLS over IEEE 802.17 RPR in "basic mode". In basic mode, higher layers do not have any control over the underlying network and treat it as a broadcast media. This document will describe all the necessary mappings to aid interoperable networks. This includes encapsulation formats (e.g., IPv4/IPv6), how to perform address resolution (e.g., ARP/ND), IP multicast transmission, and priority mapping to the RPR service class. Holness & Parsons Expires February 22, 2007 [Page 4]
Internet-Draft IPoRPR August 2006 2. 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 SHALL NOT be used as a definitive description of IEEE 802.17 [2] or amendments IEEE 802.17a [14], and IEEE 802.17b [15]. IEEE 802.17 SHALL be consulted for specific details on the functionality. Clause 5 of 802.17 contains a ~30 page overview of the ~700 page specification. Details on the MAC service is contained in Clause 6 of 802.17. 2.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. 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 default path to each destination. The determination of default may be by any algorithm, including shortest path. Normally, the 802.17 MAC layer will automatically send frames via the default 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 three service classes: classA provides committed bandwidth and low delay and jitter, classB has committed and excess bandwidth components and bounded delay and jitter, and classC 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. There is a TTL in the IEEE 802.17 frame headers. This TTL is used to Holness & Parsons Expires February 22, 2007 [Page 5]
Internet-Draft IPoRPR August 2006 measure and limit the lifetime of frames on a ring. 2.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, noted with '*', are mandatory): *destination_address source_address *mac_service_data_unit frame_check_sequence *service_class ringlet_id mac_protection mark_fe strict_order destination_address_extended source_address_extended flooding_form 2.2.1. IEEE 802.17 addressing The destination address (DA) [destination_address] is the 48-bit MAC address of the destination station. This may also be a multicast or broadcast address. This is a required parameter. The source address (SA) [source_address] is the 48-bit MAC address of the source station. This is an optional parameter. If it is omitted, the MAC uses the source address that is assigned to the station. 2.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 protocol type field. Holness & Parsons Expires February 22, 2007 [Page 6]
Internet-Draft IPoRPR August 2006 This is a required parameter. 2.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: classA: classA service provides an allocated, guaranteed data rate, and low end-to-end delay and jitter bound. classA traffic is allocated with a committed information rate (CIR). Traffic above the allocated rate is rejected. classA traffic has precedence over classB and classC traffic at the ingress to the ring and in transit. This class is well suited for real time applications. classB: classB service provides an allocated, guaranteed data rate, and bounded end-to-end delay and jitter for the traffic within the allocated rate. classB also provides access to additional best effort data transmission that is not allocated, guaranteed, or bounded. classB traffic is allocated with a CIR component. Any classB traffic amount beyond the allocated CIR is referred to as excess information rate (EIR) classB traffic. classB traffic (including classB-EIR) has precedence over classC traffic at the ingress to the ring. classC: classC service provides a best-effort traffic service with non allocated or guaranteed data rate, and no bounds on end-to-end delay or jitter. classC traffic has the lowest precedence for ingress to the ring. Both classB-EIR and classC 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. Internal to the RPR MAC, classA traffic is partitioned into two sub classes: subclassA0 and subclassA1. This partitioning is done in order to increase the ability of the ring to reclaim unused classA traffic. The RPR MAC is configured for a total classA amount, from which it determines how much is subclassA0 and subclassA1. The division of classA is based on ring circumference and the size of internal transit queues. The reclaimable bandwidth allocated to subclassA1 can be reclaimed by traffic of classB-EIR and classC when not being used by the station originating the classA traffic being reclaimed. Note that subclassA0 is not reclaimable, i.e. this Holness & Parsons Expires February 22, 2007 [Page 7]
Internet-Draft IPoRPR August 2006 bandwidth is reserved and not available for classB or classC traffic. 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. 2.2.4. IEEE 802.17 fairness The RPR fairness algorithm ensures proper partitioning of opportunistic traffic over the ring and governs classB-EIR and classC traffic. The mark_fe parameter indicate a request to mark and treat a frame as fairness eligible regardless of how it would have been marked or treated otherwise. This guides the MAC entity on how to set the fe (fairness eligible) field. 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. Holness & Parsons Expires February 22, 2007 [Page 8]
Internet-Draft IPoRPR August 2006 3. General mapping details This section covers issues that are common to IPv4, IPv6, and MPLS. 3.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. 3.1.1. Destination_address Is the 48-bit MAC address of the 802.17 station to which the packet is being transmitted. 3.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. 3.1.3. mac_service_data_unit This is the payload, including the protocol type field. See "Protocol Type Field" (Section 3.2), for more information. 3.1.4. frame_check_sequence The MAC will calculate the FCS 3.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 4.2 and Section 6.1. 3.1.6. ringlet_id The client SHOULD NOT specify the ringletID. The MAC will use its default algorithm to select a ringlet. 3.1.7. mac_protection This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will then use its default treatment Holness & Parsons Expires February 22, 2007 [Page 9]
Internet-Draft IPoRPR August 2006 3.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 4.2 and Section 6.1. 3.1.9. strict_order This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will then use its default treatment. 3.1.10. destination_address_extended This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary. 3.1.11. source_address_extended This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary. 3.1.12. flooding_form This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary. 3.2. Protocol Type Field The 16-bit protocol type field (or Ethertype) is set to a value to indicate the payload 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. 3.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 header. Holness & Parsons Expires February 22, 2007 [Page 10]
Internet-Draft IPoRPR August 2006 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. 3.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. 3.5. Ringlet 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. For basic mode ringlet selection is left to the MAC. 3.6. 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 February 22, 2007 [Page 11]
Internet-Draft IPoRPR August 2006 4. IPv4 specific mapping details 4.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. 4.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. 4.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 1. Holness & Parsons Expires February 22, 2007 [Page 12]
Internet-Draft IPoRPR August 2006 |---------------------|----------|-------------------| | IP Service Class | DSCP | Per Hop Behaviour | |=====================|==========|===================| | Standard | 000000 | Default Forwarding| |---------------------|----------|-------------------| | Low Priority Data | 001000 | Class Selector 1 | |---------------------|----------|-------------------| | High Throughput | 001010 | AF11 | | Data | 001100 | AF12 | | | 001110 | 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 1: 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 the packet within the AF class. A congested DS node tries to protect Holness & Parsons Expires February 22, 2007 [Page 13]
Internet-Draft IPoRPR August 2006 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 2. This is the default mapping for interoperablility, vendors/operators may choose to map differently. Note that four treatment aggregates are used as suggested by [10]. Holness & Parsons Expires February 22, 2007 [Page 14]
Internet-Draft IPoRPR August 2006 |----------|-------------------|-------------|-------------| | DSCP | RPR | RPR | Traffic | | | service_class | mark_fe | Allocation | |==========|===================|=============|=============| | 000000 | classC | ignore | EIR | | 001000 | | | | |----------|-------------------|-------------|-------------| | 001010 | | FALSE | classB-CIR | | | |-------------|-------------| | 001100 | | TRUE | classB-EIR | | 001110 | | | | |----------| |-------------|-------------| | 010000 | | FALSE | classB-CIR | |----------| classB |-------------|-------------| | 010010 | | FALSE | classB-CIR | | | |-------------|-------------| | 010100 | | TRUE | classB-EIR | | 010110 | | | | |----------| |-------------|-------------| | 011010 | | FALSE | classB-CIR | | | |-------------|-------------| | 011100 | | TRUE | classB-EIR | | 011110 | | | | |----------|-------------------|-------------|-------------| | 011000 | | | | |----------| | | | | 100000 | | | | |----------| | | | | 100010 | | | | | 100100 | classA | ignore | CIR | | 100110 | | | | |----------| | | | | 101000 | | | | |----------| | | | | 101110 | | | | |----------|-------------------|-------------|-------------| | | | | | | 110000 | classA | ignore | CIR | | | | | | |----------|-------------------|-------------|-------------| Table 2: IP DSCP to RPR Header Mapping Services marked with a DF and CS1 DSCP only an EIR component. Service marked with AF11, AF21, AF31 and CS2 DSCPs have an aggregated CIR and services marked with AF12, AF13, AF22, AF23, AF32 and AF33 have an aggregated EIR component. Holness & Parsons Expires February 22, 2007 [Page 15]
Internet-Draft IPoRPR August 2006 Traffic marked with CS6 DSCP class (routing control) also has only a CIR component. Further, it is recommended that CS6 marked traffic be assigned its own RPR service. These guidleines are provided so that congestion from other traffic sources does not cause routing instability since it is separated from the routing control traffic. As CS7 is for future use, no mapping is provided. classA traffic is not fairness eligible and classC traffic is fairness eligible. For classB traffic the client may request a specific treatment using the mark_fe parameter. For classA and classC traffic any mark_fe request would be ignored. 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 2). Holness & Parsons Expires February 22, 2007 [Page 16]
Internet-Draft IPoRPR August 2006 5. 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. 5.1. Stateless autoconfiguration IPv6 stateless autoconfiguration follows the rules and procedures in section 4 of RFC 2464 [5]. 5.2. Link local address IPv6 link-local addresses follow the rules and procedures in section 5 of RFC 2464 [5]. 5.3. Unicast address mappings IPv6 unicast address mappings follow the rules and procedures in section 6 of RFC 2464 [5]. 5.4. Multicast address mappings IPv6 multicast address mappings follow the rules and procedures in section 7 of RFC 2464 [5]. 5.5. Diffserv mapping The mapping is as specified in Section 4.2 Holness & Parsons Expires February 22, 2007 [Page 17]
Internet-Draft IPoRPR August 2006 6. MPLS specific details Transport of MPLS packets over IEEE 802.17 follows RFC 3032 [12]. 6.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). 6.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 3 for E-LSP. For L-LSP, only the drop precedence is encoded in the EXP bits. This is the default mapping for interoperablility, vendors/operators may choose to map differently. Note that four treatment aggregates are used as suggested by [10]. Holness & Parsons Expires February 22, 2007 [Page 18]
Internet-Draft IPoRPR August 2006 |-------------|-------------------|-------------|-------------| | MPLS | RPR | RPR | Traffic | | EXP | service_class | mark_fe | Allocation | |=============|===================|=============|=============| | 000 | classC | ignore | EIR | | 001 | | | | |-------------|-------------------|-------------|-------------| | 010 | | FALSE | classB-CIR | | | classB |-------------|-------------| | 011 | | TRUE | classB-EIR | |-------------|-------------------|-------------|-------------| | 100 | | | | | | classA | ignore | CIR | |101(reserved)| | | | |-------------|-------------------|-------------|-------------| | 110 | | | | | | classA | ignore | CIR | |111(reserved)| | | | |-------------|-------------------|-------------|-------------| Table 3: MPLS EXP to RPR header mapping Holness & Parsons Expires February 22, 2007 [Page 19]
Internet-Draft IPoRPR August 2006 7. Security considerations This specification provides no security measures. However, it should be noted that all of these vulnerabilities exist today for transport of IP and MPLS over Ethernet networks. 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, for example, 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. Holness & Parsons Expires February 22, 2007 [Page 20]
Internet-Draft IPoRPR August 2006 8. IANA considerations A new ARP codepoint is to be assigned by IANA per Section 4.1 Holness & Parsons Expires February 22, 2007 [Page 21]
Internet-Draft IPoRPR August 2006 9. Acknowledgements The authors acknowledge and appreciate the work and comments of the IETF IPoRPR working group and the IEEE 802.17 working group. Holness & Parsons Expires February 22, 2007 [Page 22]
Internet-Draft IPoRPR August 2006 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", RFC 4594, August 2006. [10] Chan, K., "Aggregation of Diffserv Service Classes.", draft-ietf-tsvwg-diffserv-class-aggr-00 (work in progress), June 2006. [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. [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", Holness & Parsons Expires February 22, 2007 [Page 23]
Internet-Draft IPoRPR August 2006 IEEE P802.17b. Holness & Parsons Expires February 22, 2007 [Page 24]
Internet-Draft IPoRPR August 2006 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 February 22, 2007 [Page 25]
Internet-Draft IPoRPR August 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). Holness & Parsons Expires February 22, 2007 [Page 26]
