idnits 2.17.1 draft-ietf-isis-ext-eth-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 453 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 301 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 300 has weird spacing: '...ding on its...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE802.2' is mentioned on line 58, but not defined == Missing Reference: 'March 20' is mentioned on line 193, but not defined -- Looks like a reference, but probably isn't: '1997' on line 193 == Missing Reference: 'ETH' is mentioned on line 282, but not defined == Unused Reference: 'IEEE802' is defined on line 189, but no explicit reference was found in the text == Unused Reference: 'IEEE802.3Z' is defined on line 191, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-ISO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.3Z' Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jed Kaplan 2 Internet Draft P.J. Singh 3 Expiration Date: November 2001 Allegro Networks, Inc. 5 Mike O'Dell 7 John Hayes 8 Archduke Design, Inc. 10 Ted Schroeder 11 Alteon WebSystems, Inc. 13 Daemon Morrell 14 Juniper Networks, Inc. 16 Jennifer Hsu 18 Extended Ethernet Frame Size Support 20 draft-ietf-isis-ext-eth-01.txt 22 1. Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/lid-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 2. Abstract 46 This document presents an extension to current Ethernet Frame 47 specifications for hardware and frame format to support payloads 48 greater than 1500 Bytes for Type interpretation and Length 49 interpretation frames. This is useful for Gigabit Ethernet 50 technology, providing a means to carry large MTU packets without 51 fragmentation over a high-speed broadcast network. 53 3. Overview 55 There are two fundamental frame types defined for Ethernet: 56 Type interpretation [IEEE-ISO] [RFC894] and Length interpretation 57 [IEEE-ISO]. Length interpretation headers may be followed by a 58 Logical Link Control header, 802.2 [IEEE802.2]. Both types of 59 encapsulations can co-exist on the same media at the same time. 60 Encodings for Type interpretation and Length interpretation 61 frames evolved such that, as long as payloads were less than 1500 62 bytes, Type interpretation frames could always be distinguished from 63 Length interpretation frames. 65 However, when the payload is greater than 1500 bytes frames may 66 not be uniquely distinguishable as conforming to Type 67 interpretation or Length interpretation formats. This document 68 extends the Ethernet frame format to allow Type interpretation or 69 Length interpretation frame payloads larger than 1500 bytes to be 70 uniquely distinguished. 72 4. Ethernet Frame Formats 74 A. Type interpretation 76 +----+----+------+------+-----+ 77 | DA | SA | Type | Data | FCS | 78 +----+----+------+------+-----+ 80 DA Destination MAC Address (6 bytes) 81 SA Source MAC Address (6 bytes) 82 Type Protocol Type (2 bytes) 83 Data Protocol Data (46 - 1500 bytes) 84 FCS Frame Checksum (4 bytes) 86 B. Length interpretation and derivatives 88 +----+----+------+------+-----+ 89 | DA | SA | Len | Data | FCS | 90 +----+----+------+------+-----+ 92 DA Destination MAC Address (6 bytes) 93 SA Source MAC Address (6 bytes) 94 Len Length of Data field (2 bytes) 95 Data Protocol Data (46 - 1500 bytes) 96 FCS Frame Checksum (4 bytes) 98 The derivatives include LLC (802.2) and SNAP which prefix the 99 data field with an LLC header. In these instances the Len field 100 then corresponds to the combined size of both the data portion 101 of the frame and the LLC header. 103 On reception, the two formats are differentiated based on the 104 magnitude of the Type/Length field, as follows: 106 > 1536 bytes: value corresponds to a type field. The frame is an 107 Ethernet II frame, with type values starting at 1536 109 (600 hex). 111 <= maxValidFrame bytes: value corresponds to a length field. The 112 frame is an IEEE 802.3 format (or derivative) with a 114 maximum data length of 1500 bytes. 116 5. Problem with Large Length interpretation Frames in the presence of Type 117 Interpretation Frames 119 Some protocols commonly used in the Internet have no reserved 120 Ethertype. An example is the set of ISO Network layer protocols, 121 of which ISIS is a member. Such protocols are only defined to use 122 the IEEE 802.3/802.2 encoding, and so their packets are limited in 123 length to 1500 bytes. 125 Type Interpretation frames have no length field. Protocols 126 encapsulated in Type interpretation frames, such as IP, are not 127 limited in length to 1500 bytes by framing. 129 6. Proposed Ethernet Frame Extension 131 Large Length interpretation and Type interpretation frames can be 132 supported by the following: 134 + Define an Ethertype for 802.3, 0x8870, and encode large frames 135 (where the data field is greater than 1500 bytes), exclusive of 136 the Destination MAC address, Source MAC address, and Data length 137 fields, within Type interpretation frames. 139 Large 802.3/802.2 frames would have the following fields: 141 +----+----+------+------+------+------+------+-----+ 142 | DA | SA | Type | DSAP | SSAP | Ctrl | Data | FCS | 143 +----+----+------+------+------+------+------+-----+ 144 === 802.2 Header === 146 DA Destination MAC Address (6 bytes) 147 SA Source MAC Address (6 bytes) 148 Type 0x8870 (Ethertype) (2 bytes) 149 DSAP 802.2 Destination Service Access Point (1 byte) 150 SSAP 802.2 Source Service Access Point (1 byte) 151 Ctrl 802.2 Control Field (1 byte) 152 Data Protocol Data (46 bytes) 153 FCS Frame Checksum (4 bytes) 155 + Allow Type interpretation frames to have payloads greater than 156 1500 bytes. 158 There is no loss of information from 802.3/802.2 frames. Although 159 the 802.3 length field is missing, the frame length is known by 160 virtue of the frame being accepted by the network interface. 162 In this manner, all Type interpretation frames, including large 163 Length interpretation frames, can be longer than 1500 bytes, yet 164 are uniquely identified. 166 7. Default MTU 168 The motivation for this draft was support of FDDI MTU, 4470, 169 without fragmention. 171 Supporting MPLS over Ethernet without fragmentation requires 4 or 8 172 additional bytes beyond Ethernet MTU. 174 Some servers support MTU of 9180. Additionally RFC 1626 prescribes 175 an MTU of 9180 for ATM AAL5 supporting IP over ATM. Some equipment 176 providers claim significant cost to support this MTU. 178 Assuming that there isn't a great need for an MTU of 9180, an MTU 179 of 4470 is recommended, to support the expected predominate 180 applications of extended Ethernet frames, without causing undue 181 burden on equipment providers. 183 8. References 185 [IEEE-ISO] IEEE Std. 802.3 [2000 Edition], ISO/IEC 8802-3:2000. 187 [RFC894] IETF RFC 894 189 [IEEE802] IEEE Std 802 191 [IEEE802.3Z] IEEE Std 802.3z 193 [802.3X] IEEE Std. 802.3X [March 20, 1997], sec 4.2.7.1. 195 [EXT.FRAME] "Use of Extended Frame Sizes in Ethernet Networks", draft 2.1, 196 Alteon Networks, Inc. 198 9. Author's Addresses 200 Jed Kaplan 201 Allegro Networks, Inc. 202 12700 Failr Lakes Circle 203 Suite 100 204 Fairfax, Va 22033 205 email: jkaplan@allegronetworks.com 207 P.J. Singh 208 Allegro Networks, Inc. 209 6399 San Ignacio Blvd. 210 San Jose, Ca. 95119 211 408-281-5500 212 email: pjsingh@allegronetworks.com 214 Mike O'Dell 215 email: mo@ccr.net 217 John Hayes 218 Archduke Design, Inc. 219 24700 Skyland Road 220 Los Gatos, CA 95033 221 (408) 691-6891 222 email: hayes@archdukedesign.com 224 Ted Schroeder 225 email: ted@alteon.com 227 Daemon Morrell 228 Juniper Networks, Inc. 229 12343-D Sunrise Valley Drive 230 Reston, VA 20191 231 email: dmorrell@juniper.net 233 Jennifer Hsu 234 jhsu@mur.com 236 10. Appendix 1. Following is the response from the IEEE to 237 draft-kaplan-isis-ext-eth-02.txt. 239 From: Geoff Thompson, Chair, IEEE 802.3 240 To: Scott O. Bradner, IETF 241 Re: 802.3 Position on Extended Ethernet Frame Size Support 243 Scott- 245 This is in response to your query for a position regarding the 246 publication of Extended Ethernet Frame Size Support - 247 draft-kaplan-isis-ext-eth-02.txt - as an informational RFC. This 248 response was approved in concept and draft by 802.3 during its 249 closing plenary at Hilton Head on March 15. The final form was 250 drafted by myself and reviewed by an ad hoc that was formed during 251 our closing plenary. It should be considered the position of the 252 802.3 Working Group. 254 The response is composed of two parts, specific comments on the 255 draft and general comments on the use of jumbo frames in Ethernet 256 networks, however, virtually all traffic uses the type/length field 257 as a type field. It seems unlikely that the implementations using 258 the length format would take advantage of longer 259 packets. Therefore, the draft conveys a very limited value. 261 Specific comments on: Extended Ethernet Frame Size Support - 262 draft-kaplan-isis-ext-eth-02.txt 264 The draft makes no mention that extended frames are not likely to be 265 successfully handled by Ethernet equipment unless the network is 266 composed entirely of equipment that is specifically designed, beyond 267 the specifications of the Ethernet Standard, to relay extended size 268 frames. 270 In section 2, Abstract, the document asserts that it presents an 271 extension to the "current Ethernet Frame Standards to support 272 payloads greater than 1500 bytes..." Neither the original Ethernet 273 specification (it was not a "Standard") nor IEEE Std. 802.3 is a 274 "frame standard". They are, rather, complete specifications for 275 hardware and frame format with the expectation that parameters from 276 one portion of the standard can be taken as a given in other 277 portions of the Standard. Moreover, this draft is not an 278 "extension" to those documents but rather a proposal to violate 279 specific provisions of those documents. 281 In section 3, the draft refers to "Ethernet II [ETH] and points to 282 the reference [ETH] The reference, as cited, is incorrect or 283 incomplete. 285 Ethernet II would seem to point to Ethernet Version 2.0. That would 286 specifically not be "version 1.0...September 1980". The citation in 287 fact points to 2 different documents and fails to note that the 288 November 1982 edition is in fact Version 2.0. Further, both of these 290 are obsolete references and have been superceded by IEEE Std. 802.3 291 and ISO/IEC 8802-3. The current version of these Standards is IEEE 292 Std. 802.3 [2000 Edition] and ISO/IEC 8802-3 : 2000. 294 The details of section 4 are badly out of date. IEEE Std. 802.3 295 has included both Type and Length encoded packets ever since the 296 adoption of IEEE Std. 802.3x on March 20, 1997. The current text of 297 the 802.3 text covering this reads: 298 ================================================================ 299 3.2.6 Length/Type Field 300 This two-octet field takes one of two meanings,depending on its 301 numeric value. For numerical evaluation, the first octet is the most 302 significant octet of this field. 303 a)If the value of this field is less than or equal to the value of 304 maxValidFrame (as specified in 4.2.7.1), then the Length/Type 305 field indicates the number of MAC client data octets contained 306 in the subsequent data field of the frame (Length 307 interpretation). 308 b)If the value of this field is greater than or equal to 1536 309 decimal (equal to 0600 hexadecimal),then the Length/Type field 310 indicates the nature of the MAC client protocol (Type 311 interpretation). The Length and Type interpretations of this 312 field are mutually exclusive. 313 ================================================================ 314 Please note that any value over "the value of maxValidFrame" is NOT 315 a valid value for encoding length. Additionally, the values between 316 maxValidFrame and "1536 decimal" are undefined in the Ethernet 317 standard. The behavior of equipment at these values is not 318 specified and can not be depended on. The draft implies that these 319 values are valid type fields. This is not true. These values are 320 not valid for either Type or Length. 322 Section 4 Re: "...are not limited in length to 1500 bytes by 323 framing." While this seems to be true, it is not necessarily true 324 for a number of sometimes subtle reasons, some of which are noted 325 in the "General" section below. 327 Section 5: Regarding the statement "Although the 802.3 length field 328 is missing, the frame length is missing, the frame length is known 329 by virtue of the frame being accepted by the network interface." 330 This statement is not correct. Many Ethernet interfaces, 331 particularly those of relay equipment, accept frames without regard 332 for packet type or content. There is no reasonable expectation that 333 standards based Ethernet/802.3 equipment will reject the proposed 334 frames. They may very well accept the frame and corrupt it before 335 passing it on. This corruption may consist of truncation or 336 alteration of the data within the packet. 338 General comments on the use of jumbo frames in Ethernet networks: 340 Consideration #1: The expectation of no more than 15-1600 bytes 341 between frames and an interpacket gap before the next frame is 342 deeply ingrained throughout the design and implementation of 343 standardized Ethernet/802.3 hardware. This shows up in buffer 344 allocation schemes, clock skew and tolerance compensation and fifo 345 design. 347 Consideration #2: For some Ethernet/802.3 hardware (repeaters are 348 one specific example) it is not possible to design compliant 349 equipment which meets all of the requirements and will still pass 350 extra long frames. Further, since clock frequency may vary with 351 time and temperature, equipment may successfully pass long frames 352 at times and corrupt them at other times. Therefore, attempts to 353 verify the ability to send long frames over a path may produce 354 inaccurate results. 356 Consideration #3: The error checking mechanism embodied in the 4 357 byte checksum has not been well characterized at greater frame 358 lengths, but is known to degrade. Therefore the data reliability of 359 transfers in long frame transfers will have a greater rate of 360 undetected frame errors. 362 Consideration #4: The length of frames proposed by this draft can 363 not be assured to pass through standards conformant hardware. The 364 huge value of Ethernet/802.3 systems in the data networking 365 universe is their standardization and the resulting assurance that 366 systems will all interoperate. No such assurance can be provided 367 for oversize frames with both the current broadly accepted standard 368 and the large installed base ofstandards based equipment. 370 In summary with regard to greatly longer frames for Ethernet, much 371 of the gear produced today would be intolerant of greatly longer 372 frames. There is no way proposed to distinguish between frame 373 types in the network as they arrive from the media. Bridges might 374 and repeaters would drop or truncate frames (and cause errors doing 375 so) right and left for uncharacterized reasons. It would be a 376 mess. What might seem okay for small carefully characterized 377 networks would be enormously difficult or impossible to do across 378 the Standard. 380 The choice of frame size for Ethernet packets is really the domain 381 of 802.3 (CSMA/CD) and 802.1 (Bridging, VLANs). The only time the 382 frame size has been modified over the history of the Standard was 383 in order to increase maximum length by four bytes in order to 384 accommodate VLANs, 802.1 initiated this work and 802.3 also 385 modified the Ethernet standard to include these few extra 386 bytes. The people with the experience dealing with this sort of 387 thing attend IEEE 802. It's easy to define a new ethertype, but 388 it's not too easy to figure out what happens when these 389 non-standard frames are given to standardized transmission 390 equipment e.g. bridges. We would expect discussions of this type 391 to take place in both 802.3 & 802.1. 393 The giant frame issue has been mentioned several times over the 394 years in 802.3, discussed in the back halls and considered each 395 time we move to a higher speed. It has never had consensus support 396 in that context. It has never been brought forward as a separate 397 proposal. Backward compatibility has always been more important 398 than ease of performance improvement. The problem is that the 399 change is very easy to do in the standard and hard to do in the 400 world. It is just like changing the gauge on railroad tracks. All 401 you have to do is change one line in the standard, never mind all 402 of the rails you have to move. 404 The Kaplan draft is just meant for carrying IS-IS routing protocol 405 frames (the IS-IS working group is the intended sponsor of this 406 draft). We expect those vendors supporting the larger frame will 407 support this will show up and support this proposal. Those vendors 408 not supporting the larger frame as well as those protecting the 409 installed base will not support this activity nor having this sort 410 of item standardized outside IEEE 802.3. 412 With best regards, 414 Geoff Thompson, Chair, IEEE 802.3 416 11. Appendix 2. Comments from the draft's authors. 418 With respect to Consideration #2, paragraph 1: 420 With the advent of full duplex ethernet and higher speed ethernet 421 phys, transcievers have gone from transmitting when they have data 422 ready send to transmitting constantly, sending IDLEs when they have 423 nothing to send. Any clock drift due to time and temperature will 424 affect the system without regard to the frame lengths being used. 426 With respect to Consideration #3, paragraph 1: 428 The error checking mechanism of ethernet (CRC-32) was characterized 429 by R. Jain, "Error Characteristics of Fiber Distributed Data 430 Interface (FDDI)," IEEE Transactions on Communications, Vol. 38, 431 No. 8, August 1990, 432 pp. 1244-1252. http://www.cis.ohio-state.edu/~jain/papers/xie1.htm 434 FDDI and Ethernet use the same error checking mechanism; CRC-32. 435 The probability of undetected errors remains constant for frame 436 sizes between 3007 and 91639 bits (approximately 376 to 11455 437 bytes). Setting the maximum size of jumbo frames to 9018 bytes 438 falls well within this range. There is no increase in undetected 439 errors when using jumbo frames and the existing CRC-32 as the error 440 detection mechanism. 442 With respect to Consideration #4, paragraph 1: 444 This proposal provides a workable mechanism to identify and 445 handle jumbo frames through systems that do support jumbo frames.