| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Folks, An updated draft of the IPoRPR basic mapping is attached. The changes are mostly editorial based on comments from IEEE 802.17. The most significant changes are to the RPR nomenclature in Tables 2 & 3. This version will not be in the Internet Draft archives until after the IETF meeting. Also, note that the primary review mechanism is to submit comments to the IETF IPoRPR mailing list -- and you must be a member to post (and get past the spam filter :-). There is currently no plan for an IPoRPR WG meeting at IETF 64 in Vancouver. However, there is agenda time at the IEEE 802.17 meeting in Vancouver next week to discuss this draft. Cheers, Glenn PS. The drafts are posted here as well: http://standards.nortel.com/iporpr
IPoRPR Working Group M. Holness
Internet-Draft G. Parsons
Expires: May 10, 2006 Nortel
November 6, 2005
Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring)
Networks
draft-ietf-iporpr-basic-01.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 May 10, 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 May 10, 2006 [Page 1]
Internet-Draft IPoRPR November 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 May 10, 2006 [Page 2]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 3]
Internet-Draft IPoRPR November 2005
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 contains
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 May 10, 2006 [Page 4]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 5]
Internet-Draft IPoRPR November 2005
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.
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
Holness & Parsons Expires May 10, 2006 [Page 6]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 7]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 8]
Internet-Draft IPoRPR November 2005
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.
0x8100 if the payload contains an Ethernet VLAN/Priority tagged
packet.
Holness & Parsons Expires May 10, 2006 [Page 9]
Internet-Draft IPoRPR November 2005
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.
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 May 10, 2006 [Page 10]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 11]
Internet-Draft IPoRPR November 2005
|---------------------|----------|-------------------|
| 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 |
| | 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 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 May 10, 2006 [Page 12]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 13]
Internet-Draft IPoRPR November 2005
|----------|-------------------|-------------|-------------|
| 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 | | | |
| 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
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
Holness & Parsons Expires May 10, 2006 [Page 14]
Internet-Draft IPoRPR November 2005
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.
Services marked with a DF and CS1 DSCP do not have a small amount of
assured bandwidth component. That is, they have only 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 have only a CIR component. Routing traffic
marked with CS6 DSCP class also has only a CIR component. 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 May 10, 2006 [Page 15]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 16]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 17]
Internet-Draft IPoRPR November 2005
|-------------|-------------------|-------------|-------------|
| 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 May 10, 2006 [Page 18]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 19]
Internet-Draft IPoRPR November 2005
8. IANA considerations
A new ARP codepoint is to be assigned by IANA per Section 4.1
Holness & Parsons Expires May 10, 2006 [Page 20]
Internet-Draft IPoRPR November 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 May 10, 2006 [Page 21]
Internet-Draft IPoRPR November 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.
Holness & Parsons Expires May 10, 2006 [Page 22]
Internet-Draft IPoRPR November 2005
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 May 10, 2006 [Page 23]
Internet-Draft IPoRPR November 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 May 10, 2006 [Page 24]
Title: Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks
|
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 May 10, 2006.
Copyright © The Internet Society (2005).
This document specifies a basic standard method of encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient packet ring (RPR) datagrams.
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirements Levels,” March 1997.) [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.
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.
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 (, “Resilient packet ring access method and physical Layer specifications - medium access control parameters, physical layer interface, and management parameters,” July 2004.) [2] or amendments IEEE 802.17a (, “Media Access Control (MAC) Bridges - Amendment 1: Bridging of 802.17,” October 2004.) [14], and IEEE 802.17b (, “Resilient Packet Ring Access Method and Physical Layer Specifications - Amendment 1: Spatially Aware Sublayer,” .) [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 contains in Clause 6 of 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 measure and limit the lifetime of frames on a ring.
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] (, “Resilient packet ring access method and physical Layer specifications - medium access control parameters, physical layer interface, and management parameters,” July 2004.)). 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
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.
The MAC SDU [mac_service_data_unit] is the RPR payload. It includes the entire IP/MPLS packet prefaced with the protocol type field. This is a required parameter.
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.
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 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.
This section covers issues that are common to IPv4, IPv6, and MPLS.
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] (, “Resilient packet ring access method and physical Layer specifications - medium access control parameters, physical layer interface, and management parameters,” July 2004.)). This section specifies how those parameters are to be used.
Is the 48-bit MAC address of the 802.17 station to which the packet is being transmitted.
The source_address SHOULD be the address assigned to the station that is transmitting the packet. Per [2] (, “Resilient packet ring access method and physical Layer specifications - medium access control parameters, physical layer interface, and management parameters,” July 2004.) if the client omits this parameter then the MAC inserts the correct address.
This is the payload, including the protocol type field. See "Protocol Type Field" (Protocol Type Field), for more information.
The MAC will calculate the FCS
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 (IP Differentiated Service (DSCP) mapping to RPR) and Section 6.1 (MPLS EXP bit Mapping to RPR).
The client SHOULD NOT specify the ringletID. The MAC will use its default algorithm to select a ringlet.
This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will then use its default treatment
This parameter SHOULD NOT be specified unless the RPR service class is CLASS B as indicated from the mappings in Section 4.2 (IP Differentiated Service (DSCP) mapping to RPR) and Section 6.1 (MPLS EXP bit Mapping to RPR).
This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will then use its default treatment.
This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary.
This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary.
This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will populate if necessary.
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.
- 0x8100 if the payload contains an Ethernet VLAN/Priority tagged packet.
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.
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.
As described in "APPENDIX B: Data Transmission Order" of RFC 791 (Postel, J., “Internet Protocol,” September 1981.) [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.
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.
There is no correlation or interaction between the higher layer TTL and the IEEE 802.17 TTL.
ARP (Plummer, D., “An Ethernet Address Resolution Protocol,” November 1982.) [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.
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.
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] (Nichols, K., “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.,” December 1998.), [7] (Heinanen, J., “Assured Forwarding PHB Group.,” June 1999.), [8] (Jacobson, V., “An Expedited Forwarding PHB Group.,” June 1999.) and [9] (Babiarz, J., “Configuration Guidelines for Diffserv Service Classes,” June 2005.), the DSCP field description is illustrated in Table 1.
|---------------------|----------|-------------------|
| 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 |
| | 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 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 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] (Chan, K., “Aggregation of Diffserv Service Classes.,” February 2005.).
|----------|-------------------|-------------|-------------|
| 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 | | | |
| 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
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.
Services marked with a DF and CS1 DSCP do not have a small amount of assured bandwidth component. That is, they have only 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 have only a CIR component. Routing traffic marked with CS6 DSCP class also has only a CIR component. 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] (Ramakrishnan, K., “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.), 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).
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.
IPv6 stateless autoconfiguration follows the rules and procedures in section 4 of RFC 2464 (Crawford, ., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.) [5].
IPv6 link-local addresses follow the rules and procedures in section 5 of RFC 2464 (Crawford, ., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.) [5].
IPv6 unicast address mappings follow the rules and procedures in section 6 of RFC 2464 (Crawford, ., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.) [5].
IPv6 multicast address mappings follow the rules and procedures in section 7 of RFC 2464 (Crawford, ., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.) [5].
The mapping is as specified in Section 4.2 (IP Differentiated Service (DSCP) mapping to RPR)
Transport of MPLS packets over IEEE 802.17 follows RFC 3032 (Rosen, E., “MPLS Label Stack Encoding,” January 2001.) [12].
MPLS support for DiffServ is defined in RFC 3270 (Le Faucheur, F., “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services,” May 2002.) [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] (Rosen, E., “MPLS Label Stack Encoding,” January 2001.)does not recommend specific EXP values for DiffServ PHB (e.g., EF, AF, DF).
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] (Chan, K., “Aggregation of Diffserv Service Classes.,” February 2005.).
|-------------|-------------------|-------------|-------------|
| 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
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:
A new ARP codepoint is to be assigned by IANA per Section 4.1 (Address resolution)
The authors acknowledge and appreciate the work and comments of the IETF IPoRPR working group and the IEEE 802.17 working group.
| 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 |
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.
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 © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.