draft of a core protocol spec
Frank Kastenholz <[email protected]> Tue, 05 Nov 2002 10:02:42 -0500
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <5.1.1.5.2.20021105094827.032dc190@uniwest2> |
IPoRPR-people
Yesterday I promised a draft specification for the
core IP over RPR protocol work. Here it is.
For those that don't recall, the core protocol is the
basic protocol functions needed to carry IP and MPLS
packets over an 802.17 network. In the interests of
simplicity, speed-of-development, and time-to-market,
this specification treats the 802.17 network as if it
was a simple fat-yellow-cable-Ethernet. All the other
features of 802.17 are intentionally left out of this
spec (again, the walk-before-we-run principle).
A later spec will address using the advanced features
of 802.17, should the WG decided to go down that path.
This draft has not been sent to the ID repository since
the repository is now closed, pending the IETF meeting
later this month. I'm soliciting comments and discussion
now to get a round of discussion and editing done and
then will publish the document as an ID.
Frank Kastenholz
o /
--------------------------------x----------------------
O \
IP Over Resilient Packet Rings Kastenholz, Frank
Internet Draft Juniper Networks
Document <> November 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 [1].
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 May 2003 1
IP Over Resilient Packet Rings November 2002
Table of Contents
1 Abstract........................................................2
2 Conventions used in this document...............................3
3 Overview of IEEE 802.17.........................................3
4 General.........................................................5
4.1 IEEE 802.17 Header.....................................6
4.2 Protocol Type Field....................................6
4.3 Payload................................................6
4.4 Byte Order.............................................7
4.5 Trailer Format.........................................7
4.6 MTU....................................................7
4.7 Ring and Direction Selection...........................7
4.8 Higher Layer TTL and Ring Hop Count....................7
5 IPv4 Specific Details...........................................8
5.1 Address Resolution.....................................8
6 IPv6 Specific Details...........................................8
6.1 Stateless Autoconfiguration............................8
6.2 Link Local Address.....................................8
6.3 Unicast Address Mappings...............................8
6.4 Multicast Address Mappings.............................9
7 MPLS Specific Details...........................................9
8 Security Considerations.........................................9
9 IANA Considerations.............................................9
10 References.....................................................9
11 Author's Addresses............................................10
1 Abstract
This memo specifies a standard method of encapsulating IPv4,
IPv6, and MPLS datagrams in IEEE 802.17 Resilient Packet Ring
Networks. This method uses a minimum of IEEE 802.17 functions
and capabilities. As far as IP and MPLS are concerned, 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.
Kastenholz Standards Track - Expires May 2002 2
IP Over Resilient Packet Rings November 2002
2 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 [2].
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.
3 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
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 nodes 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 "unwraps" and/or the effected source
nodes "re-steer" their traffic.
The two rings are called the Inner ring and Outer ring.
A node may transmit a packet in either direction around the
ring. IEEE 802.17 includes MAC-level protocols to determine
the shortest path to each destination. Normally, the 802.17
MAC layer will automatically send packets via the shortest
path. Alternatively, higher layers (such as IP) may explicitly
specify the ring to use.
All nodes 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 and
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 high, medium, and low priority services. Use of these
features by IP and MPLS is beyond the scope of this
specification. Their use will be specified in a later
document.
Kastenholz Standards Track - Expires May 2002 3
IP Over Resilient Packet Rings November 2002
The IEEE 802.17 packet is similar to an Ethernet packet. Its
format is:
+--------------------+
| IEEE 802.17 Header |
| (16 bits) |
+--------------------+
| Destination MAC |
| Address (48 bits) |
+--------------------+
| Source MAC Address |
| (48 bits) |
+--------------------+
| Protocol Type |
| Field (16 bits) |
+--------------------+
| Header Checksum |
| (16 bits) |
+--------------------+
| Payload |
| |
+--------------------+
| FCS |
+--------------------+
Where
IEEE 802.17 Header
Is a 16-bit IEEE 802.17 header.
The format of the RPR header is:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |RI|FE| PT | SC |WE|E |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where
TTL
Is the Time To Live for the packet. It is decremented
by each station on the IEEE 802.17 ring. If the TTL
reaches 0 it is removed from the ring. This field is
set by the interface hardware.
NOTE WELL that this TTL is not related in any way to
the TTL in IPv4 and MPLS headers nor the hop-count in
IPv6 headers.
RI Ring Identifier
Which the ring on which the packet was originally
transmitted.
Kastenholz Standards Track - Expires May 2002 4
IP Over Resilient Packet Rings November 2002
FE Fairness Eligible
Indicates whether the packet is subject to the IEEE
802.17 fairness algorithm or not.
PT Packet Type
Is a type field used to discriminate various IEEE
802.17 management and control packets from data
packets.
SC Service Class
WE Is the Wrap Eligible bit. It indicates whether the
packet may be wrapped when the ring is wrapped.
R Is reserved.
Destination MAC Address
Is the 48-bit MAC address of the destination node. This
may be a multicast or broadcast address. This address is
an IEEE 802 address.
Source MAC Address
Is the 48-bit MAC address of the source node. This may be
a multicast or broadcast address. This address is an IEEE
802 address.
Protocol Type
This is the 16-bit type field. It identifies the protocol
of the payload
Header Checksum
Is a HEC-16 over the 802.17 header, Source and Destination
MAC addresses, and Protocol Type.
Payload
Is the IEEE 802.17 packets payload. This is the IP or
MPLS packet.
FCS
Is a CRC-32 over the entire IEEE 802.17 packet.
4 General
This section covers issues that are common to IPv4, IPv6, and
MPLS.
Kastenholz Standards Track - Expires May 2002 5
IP Over Resilient Packet Rings November 2002
4.1 IEEE 802.17 Header
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 [8]. This section specifies how those
parameters are to be used:
TTL In the absence of any recommended value in IEEE 802.17,
the TTL SHOULD be set to 255.
RING
The ringlet on which a packet is transmitted SHOULD be
selected by the IEEE 802.17 MAC layers Ringlet Selection
Process. The higher layers SHOULD NOT select the ringlet.
FE Fairness Eligible
No value should be specified for Fairness Eligible. The
default treatment, specified in [8] is used..
PT Packet Type
The packet type is data packet.
SC 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. Use of different service classes is left for a
later specification.
4.2 Protocol Type Field
The 16-bit protocol type field is set to a value to indicate
the payloads protocol. The values for IPv4, IPv6, and MPLS
are:
0x0800 If the payload contains an IPv4 packet.
0x86DD If the payload contains an IPv6 packet.
0x8847 If the payload contains a MPLS Unicast packets, or
0x8848 if the payload contains a MPLS Multicast packet.
4.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 Checksum.
The payload is padded to meet any minimum frame size
requirements. Note well that IEEE 802.17 is specified to
operate over both SONET/SDH, which does NOT have a minimum
frame size requirement, and Gigabit Ethernet, which does. This
specification requires that IP and MPLS be unaware of the exact
Kastenholz Standards Track - Expires May 2002 6
IP Over Resilient Packet Rings November 2002
physical medium over which the 802.17 ring is built.
Therefore, IP and MPLS MUST always pad packets to the minimum
Ethernet frame size (46 bytes) and IP and MPLS MUST always
expect to receive packets with padding.
4.4 Byte Order
As described in "APPENDIX B: Data Transmission Order" of
RFC791[3], IP and MPLS datagrams are transmitted over the IEEE
802.17 network as a series of 8-bit bytes in "big endian"
order.
4.5 Trailer Format
Trailer encapsulation is NOT specified for IEEE 802.17
networks.
4.6 MTU
The default MTU of IEEE 802.17 networks is 1500 bytes.
The MTU may be changed by administrative command or IPv6 Router
Advertisement.
4.7 Ring 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 makes the
decision.
Ring and Direction selection are left to the hardware. The
advanced version of this specification may change this.
4.8 Higher Layer TTL and Ring Hop Count
The Higher Layer TTL is decremented by 1 for the entire IEEE
802.17 ring, NOT by 1 per station on the ring.
IEEE 802.17 networks consist of a number of stations. This
specification treats the IEEE 802.17 network as a single "LAN".
Therefore, the TTL is decremented by 1, just as it would be if
the IEEE 802.17 network was a big Ethernet.
Kastenholz Standards Track - Expires May 2002 7
IP Over Resilient Packet Rings November 2002
5 IPv4 Specific Details
5.1 Address Resolution
ARP[4] is used to map IPv4 addresses to the appropriate MAC
address.
The hardware addresses used in IEEE 802.17 are the same size
and format as Ethernet addresses. Therefore, to minimize the
impact on software, the "Hardware Address Space" parameter
(ar$hrd) used for IEEE 802.17 networks is 1[5].
Editors Note
This does overload the Ethernet Hardware Type value to
include 802.17, which is certainly undesirable from a
purists point of view. However, I believe that the
costs are minimal. If the working group would prefer,
we can get a new hardware type code from IANA.
6 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. This is possible because the IEEE
802.17 network can appear as a simple Ethernet.
6.1 Stateless Autoconfiguration
IPv6 stateless autoconfiguration follows the rules and
procedures in section 4 of RFC2464[6].
6.2 Link Local Address
IPv6 link-local addresses follow the rules and procedures in
section 5 of RFC2464[6].
6.3 Unicast Address Mappings
IPv6 unicast address mappings follow the rules and procedures
in section 6 of RFC2464[6].
Kastenholz Standards Track - Expires May 2002 8
IP Over Resilient Packet Rings November 2002
6.4 Multicast Address Mappings
IPv6 multicast address mappings follow the rules and procedures
in section 7 of RFC2464[6].
7 MPLS Specific Details
Transport of MPLS packets over IEEE 802.17 follows RFC3032[7].
As with IPv6, the intent is to allow the IEEE 802.17 network to
be treated as a simple Ethernet LAN.
8 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. Denial of Service attacks are possible by, eg, flooding the
IEEE 802.17 network with ARP broadcasts.
4. Attacks against the IEEE 802.17 ring management protocols
are possible by nodes 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.
9 IANA Considerations
There are no IANA considerations. This specification does not
define any number or name spaces that need to be centrally
managed.
10 References
[1] Bradner, S., "The Internet Standards Process Revision 3",
BCP9, RFC2026, October 1996
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14 RFC 2119, March 1997
[3] Postel, J., "Internet Protocol", RFC-791, USC/Information
Sciences Institute, September 1981.
Kastenholz Standards Track - Expires May 2002 9
IP Over Resilient Packet Rings November 2002
[4] Plummer, D.C., "An Ethernet Address Resolution Protocol",
RFC826, November 1982.
[5] IANA, "Address Resolution Protocol Parameters,
http://www.iana.org/assignments/arp-parameters 5 February
2002.
[6] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, December 1998.
[7] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[8] 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.0, August 12, 2002.
Acknowledgments
The authors acknowledge and appreciate the work and comments of
the IPoRPR working group, the IEEE 802.17 working group. In
particular, the review and comments by Albert Herrera have been
greatly appreciated.
11 Author's Addresses
Frank Kastenholz
Juniper Networks
10 Technology Park
Westford, MA, 01886, USA
Phone: +1 978 589 0286
Email: [email protected]
Kastenholz Standards Track - Expires May 2002 10
IP Over Resilient Packet Rings November 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
Kastenholz Standards Track - Expires May 2002 11
IP Over Resilient Packet Rings November 2002
Kastenholz Standards Track - Expires May 2002 12