IP Over Resilient Packet Rings Kastenholz, Frank Internet Draft Juniper Networks Document 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