IP Over Resilient Packet Rings Kastenholz, Frank
Internet Draft Juniper Networks
Document <draft-ietf-iporpr-core-00.txt> December 2002
Category: Standards Track
A Core Standard For Transmission of IP Packets Over IEEE 802.17
(Resilient Packet Ring) Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Kastenholz Standards Track - Expires June 2003 1
IP Over Resilient Packet Rings December 2002
Table of Contents
1 Abstract...................................................2
2 Change Log.................................................2
3 Conventions used in this document..........................3
4 Overview of IEEE 802.17....................................3
5 General....................................................5
5.1 IEEE 802.17 MAC Service Parameters.....................6
5.2 Protocol Type Field....................................6
5.3 Payload................................................7
5.4 Byte Order.............................................7
5.5 Trailer Format.........................................7
5.6 Ringlet and Direction Selection........................7
5.7 Higher Layer TTL and Ring TTL..........................7
6 IPv4 Specific Details......................................8
6.1 Address Resolution.....................................8
7 IPv6 Specific Details......................................8
7.1 Stateless Autoconfiguration............................8
7.2 Link Local Address.....................................8
7.3 Unicast Address Mappings...............................8
7.4 Multicast Address Mappings.............................9
8 MPLS Specific Details......................................9
9 Security Considerations....................................9
10 IANA Considerations........................................9
11 References.................................................9
12 Author's Addresses........................................10
1 Abstract
This memo specifies a standard method of encapsulating IPv4,
IPv6, and MPLS datagrams for transmission over IEEE 802.17
Resilient Packet Ring (RPR) Networks. This method uses a
minimum of IEEE 802.17 functions and capabilities. The 802.17
network is treated as a simple, flat network, similar in many
ways to an Ethernet.
A later specification will build upon this standard. It will
make more of the features and capabilities of IEEE 802.17
networks available to IP and MPLS and specify the techniques to
use those features.
2 Change Log
This section shall be removed prior to publication as an RFC.
Kastenholz Standards Track - Expires June 2003 2
IP Over Resilient Packet Rings December 2002
Version 00
1. 802.17 path selection is not necessarily "shortest" --
change overview to reflect this.
2. The TTL and frame type are set by the MAC, not the client
3. We specify that a new ARP hardware type code be used
4. Note that DoS attacks are limited only to other class-C
traffic
5. Use 'ringlet' when we mean one of the two parts that make up
the ring.
6. Deleted unneeded text on padding from the Payload section
(section 5.3) as 802.17 does not do minimum frame sizes.
Included text that says that nodes should be able to handle
padded frames, should they happen by.
7. Stated that DSCP mappings are to be left to a later spec.
8. Deleted the 802.17 packet-format stuff and replaced it with
a description of the parameters of the MA_DATA.request MAC
service primitive, and then how the parameters should be
used for IP/MPLS.
9. Deleted MTU comments. Just wasn't relevant.
10. Several editorial changes, not mentioned.
3 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.
4 Overview of IEEE 802.17
This section gives a brief overview of the IEEE 802.17
protocol. The intent is to provide information needed to make
Kastenholz Standards Track - Expires June 2003 3
IP Over Resilient Packet Rings December 2002
sense of the rest of this note. This section is NOT intended
to be a technically rigorous description 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; others may be specified in the future. 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. Except for best-
efforts traffic, use of these features by IP and MPLS is beyond
the scope of this specification. Their use will be specified
in a later document.
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
Ethernet.
There is a TTL in the IEEE 802.17 frame headers. This TTL is
used to prevent frames from infinitely looping.
The IEEE 802.17 MAC Service Definition defines the
MA_DATA.request primitive which a station uses to transmit data
(see section 5.3.1 of [7]). This primitive takes several
parameters:
Kastenholz Standards Track - Expires June 2003 4
IP Over Resilient Packet Rings December 2002
destinationAddress
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.
sourceAddress
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.
mSDU
This is the payload, including the Ethernet type field.
This is a required parameter.
serviceClass
Identifies the class of service that the frame gets.
There are three classes: Class A which provides low
delay and low delay variation. Class B which has
committed and excess bandwidth components, and class C
is best-effort.
This is a required parameter.
ringletID
Identifies which ringlet the frame is to be transmitted
on.
This is an optional parameter. If the parameter is not
specified then the MAC uses its default algorithm to
select a ringlet.
markFE
Indicates whether a class-B frame is subject to the IEEE
IEEE 802.17 fairness algorithm or not.
This is an optional parameter. If the parameter is not
specified then the MAC uses its default algorithm.
5 General
This section covers issues that are common to IPv4, IPv6, and
MPLS.
Kastenholz Standards Track - Expires June 2003 5
IP Over Resilient Packet Rings December 2002
5.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 5.3.1.1 of [7]. This section specifies how those
parameters are to be used:
destinationAddress
Is the 48-bit MAC address of the 802.17 station to which
the packet is being transmitted.
sourceAddress
The sourceAddress SHOULD be the address assigned to the
station that is transmitting the packet. Per [7] if the
client omits this parameter then the MAC inserts the
correct address.
mSDU
This is the payload, including the Ethernet type field.
See section 5.2, "Protocol Type Field", for more
information.
serviceClass
The Service Class SHOULD be CLASS C, which ôprovides a
best-effort traffic service with no allocated or
guaranteed data rate and no bounds on end-to-end delay
or jitterö. The use of different service classes and,
in particular, the mapping of DSCPs to service classes,
is left for a later specification.
ringletID
The client SHOULD NOT specify the ringletID. The MAC
will use its default algorithm to select a ringlet.
markFE
This parameter is irrelevant since all packets sent in
accordance with this protocol are Class C and markFE
applies only to Class B traffic. However, for
completeness, this parameter SHOULD NOT be specified.
The IEEE 802.17 MAC will then use its default treatment.
5.2 Protocol Type Field
The 16-bit protocol type field is set to a value to indicate
the payloadÆs 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, or
Kastenholz Standards Track - Expires June 2003 6
IP Over Resilient Packet Rings December 2002
0x8848 if the payload contains a MPLS Multicast packet.
5.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.
5.4 Byte Order
As described in "APPENDIX B: Data Transmission Order" of
RFC791[2], 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.
5.5 Trailer Format
Trailer encapsulation is NOT specified for IEEE 802.17
networks.
5.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.
5.7 Higher Layer TTL and Ring TTL
There is no correlation or interaction between the Higher Layer
TTL and the IEEE 802.17 TTL.
Kastenholz Standards Track - Expires June 2003 7
IP Over Resilient Packet Rings December 2002
6 IPv4 Specific Details
6.1 Address Resolution
ARP[3] 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 [4]
Editor's Notes
The hardware type is to be allocated by IANA prior to
publication
We could overload the Ethernet 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 inany
danger of running out of ARP hardware codes, we'll get
an 802.17-specific one.
7 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.
7.1 Stateless Autoconfiguration
IPv6 stateless autoconfiguration follows the rules and
procedures in section 4 of RFC2464[5].
7.2 Link Local Address
IPv6 link-local addresses follow the rules and procedures in
section 5 of RFC2464[5].
7.3 Unicast Address Mappings
IPv6 unicast address mappings follow the rules and procedures
in section 6 of RFC2464[5].
Kastenholz Standards Track - Expires June 2003 8
IP Over Resilient Packet Rings December 2002
7.4 Multicast Address Mappings
IPv6 multicast address mappings follow the rules and procedures
in section 7 of RFC2464[5].
8 MPLS Specific Details
Transport of MPLS packets over IEEE 802.17 follows RFC3032[6].
As with IPv6, the intent is to allow the IEEE 802.17 network to
be treated as a simple Ethernet LAN.
9 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 efforts) 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.
10 IANA Considerations
There are no IANA considerations. This specification does not
define any number or name spaces that need to be centrally
managed.
11 References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14 RFC 2119, March 1997
[2] Postel, J., "Internet Protocol", RFC-791, USC/Information
Sciences Institute, September 1981.
[3] Plummer, D.C., "An Ethernet Address Resolution Protocol",
RFC826, November 1982.
Kastenholz Standards Track - Expires June 2003 9
IP Over Resilient Packet Rings December 2002
[4] IANA, "Address Resolution Protocol Parameters,
http://www.iana.org/assignments/arp-parameters 5 February
2002.
[5] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, December 1998.
[6] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[7] IEEE Draft P802.17 ôResilient Packet Ring Access Method and
Physical Layer Specifications û medium access control
parameters, physical layer interface, and management
parametersö. Draft D1.1, October 25, 2002.
Acknowledgments
The author acknowledges and appreciates the work and comments
of the IPoRPR working group and the IEEE 802.17 working group.
In particular, the review and comments by Albert Herrera, John
Lemon, Peter Jones, Leon Bruckman, and Vinay Bannai have been
greatly appreciated.
12 Author's Addresses
Frank Kastenholz
Juniper Networks
10 Technology Park
Westford, MA, 01886, USA
Phone: +1 978 589 0286
Email: fkastenholz@juniper.net
Kastenholz Standards Track - Expires June 2003 10
IP Over Resilient Packet Rings December 2002
Full Copyright Statement
"Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implmentation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
Kastenholz Standards Track - Expires June 2003 11
Datatracker
draft-ietf-iporpr-core-00
Expired Internet-Draft
(iporpr WG)
| Document | Document type |
Expired Internet-Draft
(iporpr WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Author |
Frank Kastenholz
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |