idnits 2.17.1 draft-ietf-iporpr-core-00.txt: ** The Abstract section seems to be numbered -(445): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 484 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2002) is 7796 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Over Resilient Packet Rings Kastenholz, Frank 3 Internet Draft Juniper Networks 4 Document December 2002 5 Category: Standards Track 7 A Core Standard For Transmission of IP Packets Over IEEE 802.17 8 (Resilient Packet Ring) Networks 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at http://www.ietf.org/shadow.html. 32 IP Over Resilient Packet Rings December 2002 34 Table of Contents 35 1 Abstract...................................................2 36 2 Change Log.................................................2 37 3 Conventions used in this document..........................3 38 4 Overview of IEEE 802.17....................................3 39 5 General....................................................5 40 5.1 IEEE 802.17 MAC Service Parameters.....................6 41 5.2 Protocol Type Field....................................6 42 5.3 Payload................................................7 43 5.4 Byte Order.............................................7 44 5.5 Trailer Format.........................................7 45 5.6 Ringlet and Direction Selection........................7 46 5.7 Higher Layer TTL and Ring TTL..........................7 47 6 IPv4 Specific Details......................................8 48 6.1 Address Resolution.....................................8 49 7 IPv6 Specific Details......................................8 50 7.1 Stateless Autoconfiguration............................8 51 7.2 Link Local Address.....................................8 52 7.3 Unicast Address Mappings...............................8 53 7.4 Multicast Address Mappings.............................9 54 8 MPLS Specific Details......................................9 55 9 Security Considerations....................................9 56 10 IANA Considerations........................................9 57 11 References.................................................9 58 12 Author's Addresses........................................10 60 1 Abstract 62 This memo specifies a standard method of encapsulating IPv4, 63 IPv6, and MPLS datagrams for transmission over IEEE 802.17 64 Resilient Packet Ring (RPR) Networks. This method uses a 65 minimum of IEEE 802.17 functions and capabilities. The 802.17 66 network is treated as a simple, flat network, similar in many 67 ways to an Ethernet. 69 A later specification will build upon this standard. It will 70 make more of the features and capabilities of IEEE 802.17 71 networks available to IP and MPLS and specify the techniques to 72 use those features. 74 2 Change Log 76 This section shall be removed prior to publication as an RFC. 78 Kastenholz Standards Track - Expires June 2003 2 79 IP Over Resilient Packet Rings December 2002 81 Version 00 83 1. 802.17 path selection is not necessarily "shortest" -- 84 change overview to reflect this. 86 2. The TTL and frame type are set by the MAC, not the client 88 3. We specify that a new ARP hardware type code be used 90 4. Note that DoS attacks are limited only to other class-C 91 traffic 93 5. Use 'ringlet' when we mean one of the two parts that make up 94 the ring. 96 6. Deleted unneeded text on padding from the Payload section 97 (section 5.3) as 802.17 does not do minimum frame sizes. 98 Included text that says that nodes should be able to handle 99 padded frames, should they happen by. 101 7. Stated that DSCP mappings are to be left to a later spec. 103 8. Deleted the 802.17 packet-format stuff and replaced it with 104 a description of the parameters of the MA_DATA.request MAC 105 service primitive, and then how the parameters should be 106 used for IP/MPLS. 108 9. Deleted MTU comments. Just wasn't relevant. 110 10. Several editorial changes, not mentioned. 112 3 Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 115 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described 117 in RFC-2119 [1]. 119 The term "Higher Layer" refers to IPv4, IPv6, and MPLS when 120 they act as clients of the IEEE 802.17 network. 122 "IP" refers to both IPv4 and IPv6. The terms "IPv4" and "IPv6" 123 are used only when a specific version of IP is meant. 125 4 Overview of IEEE 802.17 127 This section gives a brief overview of the IEEE 802.17 128 protocol. The intent is to provide information needed to make 130 Kastenholz Standards Track - Expires June 2003 3 131 IP Over Resilient Packet Rings December 2002 133 sense of the rest of this note. This section is NOT intended 134 to be a technically rigorous description of IEEE 802.17. 136 IEEE 802.17 is a dual, counter-rotating, ring network 137 technology with destination stripping. In the event of a fault 138 (such as a fiber cut) the stations on each side of the fault 139 can continue to function by wrapping the ring and/or by 140 steering away from the fault and towards the operational path. 141 When the fault clears, the ring reverts to normal operation. 143 The ring is composed of two ringlets, called ringlet0 and 144 ringlet1. 146 A station may transmit a frame in either direction around the 147 ring. IEEE 802.17 includes MAC-level protocols to determine 148 the "best" path to each destination. The determination of 149 "best" may be by any of several algorithms, including shortest 150 path. Normally, the 802.17 MAC layer will automatically send 151 frames via the "best" path. Alternatively, higher layers (such 152 as IP) may explicitly specify the ringlet to use. 154 All stations on the ring have 48-bit IEEE 802 addresses. 156 IEEE 802.17 is a media-independent network protocol that is 157 layered over several different physical media. SONET/SDH, 158 Gigabit Ethernet and 10-Gigabit Ethernet are currently 159 specified; others may be specified in the future. The higher 160 layers are shielded from any media dependencies. 162 There are fairness and bandwidth-management elements. There 163 are three service classes: Class A provides low delay and low 164 delay variation, class B has committed and excess bandwidth 165 components, and class C is best-effort. Except for best- 166 efforts traffic, use of these features by IP and MPLS is beyond 167 the scope of this specification. Their use will be specified 168 in a later document. 170 There are several frame types, one of which is a data frame. 171 The data frame contains a payload (such as an IPv4, IPv6, or 172 MPLS packet). The type of the payload is indicated by a 2-byte 173 type field. The type-field is identical to the type field in 174 Ethernet. 176 There is a TTL in the IEEE 802.17 frame headers. This TTL is 177 used to prevent frames from infinitely looping. 179 The IEEE 802.17 MAC Service Definition defines the 180 MA_DATA.request primitive which a station uses to transmit data 181 (see section 5.3.1 of [7]). This primitive takes several 182 parameters: 184 Kastenholz Standards Track - Expires June 2003 4 185 IP Over Resilient Packet Rings December 2002 187 destinationAddress 188 Is the 48-bit MAC address of the destination station. 189 This may be a multicast or broadcast address. This 190 address is an IEEE 802 address. 192 This is a required parameter. 194 sourceAddress 195 Is the 48-bit MAC address of the source station. This 196 address is an IEEE 802 address. 198 This is an optional parameter. If it is omitted, the 199 MAC uses the source address that is assigned to the 200 station. 202 mSDU 203 This is the payload, including the Ethernet type field. 205 This is a required parameter. 207 serviceClass 208 Identifies the class of service that the frame gets. 209 There are three classes: Class A which provides low 210 delay and low delay variation. Class B which has 211 committed and excess bandwidth components, and class C 212 is best-effort. 214 This is a required parameter. 216 ringletID 217 Identifies which ringlet the frame is to be transmitted 218 on. 220 This is an optional parameter. If the parameter is not 221 specified then the MAC uses its default algorithm to 222 select a ringlet. 224 markFE 225 Indicates whether a class-B frame is subject to the IEEE 226 IEEE 802.17 fairness algorithm or not. 228 This is an optional parameter. If the parameter is not 229 specified then the MAC uses its default algorithm. 231 5 General 233 This section covers issues that are common to IPv4, IPv6, and 234 MPLS. 236 Kastenholz Standards Track - Expires June 2003 5 237 IP Over Resilient Packet Rings December 2002 239 5.1 IEEE 802.17 MAC Service Parameters 241 When transmitting an IP or MPLS packet, a host or router 242 indicates various parameters to the IEEE 802.17 MAC layer (see 243 section 5.3.1.1 of [7]. This section specifies how those 244 parameters are to be used: 246 destinationAddress 247 Is the 48-bit MAC address of the 802.17 station to which 248 the packet is being transmitted. 250 sourceAddress 251 The sourceAddress SHOULD be the address assigned to the 252 station that is transmitting the packet. Per [7] if the 253 client omits this parameter then the MAC inserts the 254 correct address. 256 mSDU 257 This is the payload, including the Ethernet type field. 258 See section 5.2, "Protocol Type Field", for more 259 information. 261 serviceClass 262 The Service Class SHOULD be CLASS C, which �provides a 263 best-effort traffic service with no allocated or 264 guaranteed data rate and no bounds on end-to-end delay 265 or jitter�. The use of different service classes and, 266 in particular, the mapping of DSCPs to service classes, 267 is left for a later specification. 269 ringletID 270 The client SHOULD NOT specify the ringletID. The MAC 271 will use its default algorithm to select a ringlet. 273 markFE 274 This parameter is irrelevant since all packets sent in 275 accordance with this protocol are Class C and markFE 276 applies only to Class B traffic. However, for 277 completeness, this parameter SHOULD NOT be specified. 278 The IEEE 802.17 MAC will then use its default treatment. 280 5.2 Protocol Type Field 282 The 16-bit protocol type field is set to a value to indicate 283 the payload�s protocol. The values for IPv4, IPv6, and MPLS 284 are: 285 0x0800 If the payload contains an IPv4 packet. 286 0x0806 If the payload contains an ARP packet. 287 0x86DD If the payload contains an IPv6 packet. 288 0x8847 If the payload contains a MPLS Unicast packet, or 290 Kastenholz Standards Track - Expires June 2003 6 291 IP Over Resilient Packet Rings December 2002 293 0x8848 if the payload contains a MPLS Multicast packet. 295 5.3 Payload 297 The payload contains the IPv4, IPv6, or MPLS packet. The first 298 byte of the IPv4 header, IPv6 header, or top MPLS label begins 299 immediately after the 802.17 headers. 301 Note that in 802.17 there is no minimum size for frames carried 302 over Ethernet physical layers, thus there is no need to pad 303 frames that are shorter than the minimum size. However, the 304 robustness principle dictates that nodes be able to handle 305 frames that are padded. 307 5.4 Byte Order 309 As described in "APPENDIX B: Data Transmission Order" of 310 RFC791[2], IP and MPLS datagrams are transmitted over the IEEE 311 802.17 network as a series of 8-bit bytes in "big endian" 312 order. This is the same byte order as used for Ethernet. 314 5.5 Trailer Format 316 Trailer encapsulation is NOT specified for IEEE 802.17 317 networks. 319 5.6 Ringlet and Direction Selection 321 IEEE 802.17 allows the Higher Layer to select the direction 322 around the ring that traffic is to go. If the Higher Layer 323 does not make the selection then the IEEE 802.17 MAC makes the 324 decision. 326 Ringlet and Direction selection are left to the MAC. The 327 advanced version of this specification may change this. 329 5.7 Higher Layer TTL and Ring TTL 331 There is no correlation or interaction between the Higher Layer 332 TTL and the IEEE 802.17 TTL. 334 Kastenholz Standards Track - Expires June 2003 7 335 IP Over Resilient Packet Rings December 2002 337 6 IPv4 Specific Details 339 6.1 Address Resolution 341 ARP[3] is used to map IPv4 addresses to the appropriate MAC 342 address. 344 The "Hardware Address Space" parameter (ar$hrd) used for IEEE 345 802.17 networks is TBD. ARP parameter assignments may be found 346 at [4] 348 Editor's Notes 349 The hardware type is to be allocated by IANA prior to 350 publication 352 We could overload the Ethernet hardware type value since 353 802.17 addresses are the same size and format as 354 Ethernet addresses. However, it is not inconceivable 355 that overloading this value may turn out to have 356 unforeseen undesired consequences. As we are not inany 357 danger of running out of ARP hardware codes, we'll get 358 an 802.17-specific one. 360 7 IPv6 Specific Details 362 Transport of IPv6 packets over IEEE 802.17 networks is designed 363 to be as similar to IPv6 over Ethernet as possible. The intent 364 is to minimize time and risk in developing both the standard 365 and the implementations. 367 7.1 Stateless Autoconfiguration 369 IPv6 stateless autoconfiguration follows the rules and 370 procedures in section 4 of RFC2464[5]. 372 7.2 Link Local Address 374 IPv6 link-local addresses follow the rules and procedures in 375 section 5 of RFC2464[5]. 377 7.3 Unicast Address Mappings 379 IPv6 unicast address mappings follow the rules and procedures 380 in section 6 of RFC2464[5]. 382 Kastenholz Standards Track - Expires June 2003 8 383 IP Over Resilient Packet Rings December 2002 385 7.4 Multicast Address Mappings 387 IPv6 multicast address mappings follow the rules and procedures 388 in section 7 of RFC2464[5]. 390 8 MPLS Specific Details 392 Transport of MPLS packets over IEEE 802.17 follows RFC3032[6]. 393 As with IPv6, the intent is to allow the IEEE 802.17 network to 394 be treated as a simple Ethernet LAN. 396 9 Security Considerations 398 This specification provides no security measures. 400 In particular 401 1. Masquerading and spoofing are possible. There is no strong 402 authentication. 403 2. Traffic analysis and snooping is possible since no 404 encryption is provided, either by this specification or by 405 IEEE 802.17 406 3. Limited denial of Service attacks are possible by, eg, 407 flooding the IEEE 802.17 network with ARP broadcasts. These 408 attacks are limited to other class-C (best efforts) traffic. 409 4. Attacks against the IEEE 802.17 ring management protocols 410 are possible by stations that are directly connected to the 411 ring. 412 We note that all of these vulnerabilities exist today for 413 transport of IP and MPLS over Ethernet networks. 415 10 IANA Considerations 417 There are no IANA considerations. This specification does not 418 define any number or name spaces that need to be centrally 419 managed. 421 11 References 423 [1] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirements Levels", BCP 14 RFC 2119, March 1997 426 [2] Postel, J., "Internet Protocol", RFC-791, USC/Information 427 Sciences Institute, September 1981. 429 [3] Plummer, D.C., "An Ethernet Address Resolution Protocol", 430 RFC826, November 1982. 432 Kastenholz Standards Track - Expires June 2003 9 433 IP Over Resilient Packet Rings December 2002 435 [4] IANA, "Address Resolution Protocol Parameters, 436 http://www.iana.org/assignments/arp-parameters 5 February 437 2002. 439 [5] Crawford, M., "Transmission of IPv6 Packets over Ethernet 440 Networks", RFC2464, December 1998. 442 [6] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, 443 January 2001. 445 [7] IEEE Draft P802.17 �Resilient Packet Ring Access Method and 446 Physical Layer Specifications � medium access control 447 parameters, physical layer interface, and management 448 parameters�. Draft D1.1, October 25, 2002. 450 Acknowledgments 452 The author acknowledges and appreciates the work and comments 453 of the IPoRPR working group and the IEEE 802.17 working group. 454 In particular, the review and comments by Albert Herrera, John 455 Lemon, Peter Jones, Leon Bruckman, and Vinay Bannai have been 456 greatly appreciated. 458 12 Author's Addresses 460 Frank Kastenholz 461 Juniper Networks 462 10 Technology Park 463 Westford, MA, 01886, USA 465 Phone: +1 978 589 0286 466 Email: fkastenholz@juniper.net 468 Kastenholz Standards Track - Expires June 2003 10 469 IP Over Resilient Packet Rings December 2002 471 Full Copyright Statement 473 "Copyright (C) The Internet Society 2002. All Rights Reserved. 475 This document and translations of it may be copied and 476 furnished to others, and derivative works that comment on or 477 otherwise explain it or assist in its implmentation may be 478 prepared, copied, published and distributed, in whole or in 479 part, without restriction of any kind, provided that the above 480 copyright notice and this paragraph are included on all such 481 copies and derivative works. However, this document itself may 482 not be modified in any way, such as by removing the copyright 483 notice or references to the Internet Society or other Internet 484 organizations, except as needed for the purpose of developing 485 Internet standards in which case the procedures for copyrights 486 defined in the Internet Standards process must be followed, or 487 as required to translate it into languages other than English. 489 The limited permissions granted above are perpetual and will 490 not be revoked by the Internet Society or its successors or 491 assigns. 493 This document and the information contained herein is provided 494 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 495 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 496 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 497 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 498 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 499 PARTICULAR PURPOSE." 501 Kastenholz Standards Track - Expires June 2003 11