idnits 2.17.1 draft-eastlake-trill-cn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- 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 (January 4, 2013) is 4127 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) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Manoj Wadekar 4 Updates: 6325 QLogic 5 Anoop Ghanwani 6 Dell 7 Puneet Agarwal 8 Broadcom 9 Tal Mizrahi 10 Marvell 11 Expires: July 3, 2013 January 4, 2013 13 TRILL: Support of IEEE 802.1 Congestion Notification 14 16 Abstract 17 This document briefly explains the IEEE 802.1 Congestion Notification 18 standard and specifies the support of this standard in TRILL switches 19 (devices that implement the IETF TRILL protocol standard). It updates 20 RFC 6325. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Overview of These Standards............................3 49 1.2 Terminology............................................4 51 2. Congestion Notification.................................5 52 2.1 Congestion Notification Domains........................7 53 2.2 Congestion Notification Tag Details....................9 54 2.3 Congestion Notification Message Details................9 56 3 Addition to TRILL to Support Congestion Notification....11 57 3.1 TRILL Switch Ingress Details..........................12 58 3.2 Transit TRILL Switch Details..........................15 59 3.2.1 Transit TRILL Switch Input Port.....................15 60 3.2.2 Transit TRILL Switch Output Port....................15 61 3.3 TRILL Switch Egress Details...........................16 63 4. Management Considerations..............................17 64 5. IANA Considerations....................................17 65 6. Security Considerations................................17 66 7. References.............................................18 67 7.1 Normative References..................................18 68 7.2 Informative References................................18 70 Authors' Addresses........................................20 72 1. Introduction 74 IEEE 802.1 has developed various standards as part of its Data Center 75 Bridging (DCB) activity. The intent of thee of these standards is (1) 76 to efficiently minimize data loss due to queue overflow for selected 77 classes of traffic within Local Area Networks (LANs) meeting certain 78 conditions and (2) to provide limited means to allocate the available 79 bandwidth to different classes of traffic. Those three standards are 80 Priority Based Flow Control (IEEE [802.1Qbb]), Enhanced Tramission 81 Selection (IEEE [802.1Qaz]), and the Congestion Notification (CN) 82 feature in the IEEE [802.1Q] standard. Intended uses include the 83 support of loss sensitive services, such as Fiber Channel over 84 Ethernet [FCoE], in data centers. 86 PFC and ETS and their support in TRILL, which requires no changes to 87 TRILL, are described in [PfcEts]. 89 This document concerns the Congestion Notification (CN) feature in 90 the IEEE [802.1Q] standard. To support CN, a change to TRILL is 91 required as specified herein and for that reason this document 92 updates [RFC6325]. 94 The existing optional PAUSE feature of IEEE 802.3 (Annex 31B of 95 [802.3]) can, with appropriate engineering, also provide Ethernet 96 service without loss of frames due to queue overflow. However, PAUSE 97 has problems as described in [PfcEts]. 99 1.1 Overview of These Standards 101 An overview of the CN standard covered herein is given below. 103 Congestion Notification (CN) provides signaling of congestion on a 104 per flow basis to the end station source of the flow as specified in 105 [802.1Q]. As a part of CN, participating end stations are required to 106 implement per flow rate limiting. CN is enabled on a per priority 107 basis and, with appropriate engineering, minimizes frame drops due to 108 queue overflow in a LAN Congestion Notification Domain within which 109 all switches and end stations implement it. CN and Priority-based 110 Flow Control (PFC, see [PfcEts]) complement each other to help 111 eliminate such frame drops. CN reduces congestion by proactively 112 reducing frame ingress rates at the source end station(s) involved in 113 the congestion. For some congestion cases this may be insufficient to 114 stop buffer overflow at a congestion point. PFC provides an emergency 115 brake for such cases and avoids frame loss. Frames that require drops 116 due to congestion for flow control, such as those using TCP [RFC793] 117 can be assigned a priority for which CN is not enabled. CN is not 118 normally used to limit priorities 6 and 7 to avoid interfering with 119 time sensitive control frames that commonly use such priorities. And 120 CN acts by restraining end station flow sources rather than blocking 121 transmission on intermediate switch ports, which avoids congestion 122 spreading as discussed in [PfcEts]. Section 2 below provides 123 additional information on CN and specifies additions to the TRILL 124 protocol to support it. 126 The PFC, ETS, and CN standards may be implemented independently or in 127 any combination except that implementation of any of them implies 128 implementation of DCBX, specified in IEEE [802.1Qaz] and discussed in 129 [PfcEts]. 131 1.2 Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The following acronyms are used in this document in addition to those 138 defined in [RFC6325]. 140 CN - Congestion Notification [802.1Q] 142 CNM - Congestion Notification Message 144 CNtag - Congestion Notification tag 146 DCB - Data Center Bridging [802.1Qaz] 148 DCBX - DCB Exchange protocol [802.1Qaz] 150 ETS - Enhanced Transmission Selection [802.1Qaz] [PfcEts] 152 FCoE - Fiber Channel over Ethernet [FCoE] 154 LLDP - Link Layer Discovery Protocol [802.1AB] 156 PFC - Priority-based Flow Control [802.1Qbb] [802.3bd] [PfcEts] 158 RBridge - "Routing Bridge", an alternative name for a TRILL switch 160 TRILL Switch - A device implementing the TRILL protocol [RFC6325] 162 2. Congestion Notification 164 Congestion Notification (CN) can limit flows to minimize frame loss 165 by having congestion points that detect congestion send Congestion 166 Notification Messages (CNMs) back to reaction points in end stations 167 that can limit flows. See [802.1Q] for the specification of the CN 168 algorithms to perform at congestion and reaction points. Congestion 169 Notification is designed to operate best in minimizing frame loss of 170 unicast flows in a LAN composed of point-to-point physical links 171 where all switches have implemented Congestion Notification. 173 A TRILL switch that implements Congestion Notification may act as an 174 end point, for example when sourcing or sinking SNMP management 175 frames, and thus may contain one or more reaction points, as well as 176 implementing congestion points at its output queues. 178 Reaction points are in end stations where flows originate and are the 179 mechanism to limit flows. The granularity of reaction point flows is 180 beyond the scope of CN and this document but cannot be larger than a 181 priority at a source MAC address. If the granularity is smaller and 182 there are multiple reaction points in an end station for a given 183 priority, then the end station must label outgoing frames with a 184 Congestion Notification tag (CNtag) that includes an end station flow 185 ID. This flow ID is an opaque field to the rest or the network. 187 +-----------------------------------------------+ 188 | Ethernet Header (possibly including VLAN Tag) | 189 +-----------------------------------------------+ 190 | Optional CNtag | 191 +-----------------------------------------------+ 192 | Ethernet Payload | 193 +-----------------------------------------------+ 194 | Ethernet FCS | 195 +-----------------------------------------------+ 197 Figure 1: Native Ethernet Frame in a CN Domain 199 Congestion points are at queues in forwarding devices, normally port 200 output queues. The functions of a congestion point are (1) to 201 conditionally send Congestion Notification Messages (CNMs) to the 202 source of a frame and (2) to conditionally strip Congestion 203 Notification tags (CNtags) out of a frame being forwarded, for 204 example if it is being forwarded out of a congestion notification 205 domain. 207 When a frame is to be inserted into an output queue with a congestion 208 point, the procedures specified in IEEE [802.1Q] are used to 209 determine if a CNM should be sent to the frame's source and if so to 210 determine various fields in that CNM. When a frame is to be inserted 211 into an output queue with a congestion point, the congestion point 212 may remove any CNtag in the frame as discussed in Section 2.1. 213 Congestion points are implemented within the logic associated with a 214 port and require no changes to TRILL for the output of native frames, 215 as TRILL is implemented above such port logic as described in 216 [RFC6325]; however, when outputting a TRILL Data frame, any CNM 217 generated needs to be for the TRILL encapsulated frame rather than 218 for the entire TRILL Data frame. In that case there are some 219 differences between the details of the creation of a CNM at an TRILL 220 switch output port and at a bridge output port. This CNM also needs 221 to be TRILL encapsulated but this will happen automatically as the 222 CNM is specified by [802.1Q] to be treated as a native frame arriving 223 at the port. 225 +-----------------------------------------------+ 226 | Ethernet Header (possibly including VLAN Tag) | 227 +-----------------------------------------------+ 228 | CNtag | 229 +-----------------------------------------------+ 230 | Congestion Notification Message Fixed Fields | 231 + - - - - - - - - - - - - - - - - - - - - - - -+ 232 | Initial bytes of frame causing CNM | 233 +-----------------------------------------------+ 234 | Ethernet FCS | 235 +-----------------------------------------------+ 237 Figure 2: Native Congestion Notification Message 239 Within a contiguous part of the TRILL campus where Congestion 240 Notification is enabled (see Section 2.1), you would see the same 241 frames with the same tags as in a similar bridged LAN except that 242 those frames will be TRILL encapsulated as shown in Figures 3 and 4. 243 The exception is when a TRILL-ignorant bridge within the campus 244 produces a CNM in response to a TRILL data frame as shown in Figure 245 6. The resulting CNM is corrected by the first TRILL switch it 246 encounters, which will be the previous-hop TRILL switch. 248 +-----------------------------------------------+ 249 | Link Header | 250 +-----------------------------------------------+ 251 | TRILL Header | 252 +-----------------------------------------------+ 253 | CNtag | 254 +-----------------------------------------------+ 255 | Rest of Native Payload | 256 +-----------------------------------------------+ 257 | Link Trailer | 258 +-----------------------------------------------+ 260 Figure 3. TRILL Data Form of CNtagged Native Frame 262 +-----------------------------------------------+ 263 | Link Header | 264 +-----------------------------------------------+ 265 | TRILL Header | 266 +-----------------------------------------------+ 267 | CNtag | 268 +-----------------------------------------------+ 269 | Congestion Notification Message Fixed Fields | 270 + - - - - - - - - - - - - - - - - - - - - - - -+ 271 | Initial bytes of frame causing CNM | 272 +-----------------------------------------------+ 273 | Link Trailer | 274 +-----------------------------------------------+ 276 Figure 4: TRILL Data Form of Congestion Notification Message 278 2.1 Congestion Notification Domains 280 Congestion Notification (CN) reduces frame drops due to output queue 281 overflow in a Congestion Notification Domain. There could be many 282 such domains, each specified for a particular priority and contiguous 283 set of network stations (end stations, TRILL switches, or bridges), 284 within a TRILL campus. For example, two Congestion Notification 285 Domains, one at priority X and one at priority Y, could cover the 286 same set of contiguous stations, overlapping but different sets of 287 such stations, or completely disjoint sets of such stations, in a 288 campus. 290 CN includes mechanisms to "defend" Congestion Notification Domains, 291 that is, make sure only congestion managed flows of frames enter 292 congestion point queues. The edge of a domain, i.e. the set of 293 station ports in the domain directly connected to a station not in 294 the domain, is determined by a combination of auto-detection using 295 LLDP (see Section 4 of [PfcEts]) and management configuration. 296 Bridges that implement Congestion Notification defend a domain by the 297 following: 299 1. Prohibiting priority mapping inside the domain. 301 2. Mapping the priority of any frame entering the domain from a 302 station outside the domain to a priority that is not a congestion 303 managed priority. 305 3. Prohibiting the mapping of the priority of any frame entering the 306 domain from a station outside the domain to the domain's priority. 308 The station containing the reaction-point-equipped source of a flow 309 must be part of a Congestion Notification Domain at the flow's 310 priority along with all stations along the path to the flow's 311 destination and all of the queues involved with the flow must be 312 congestion-point-equipped in order for CN to be able to meet its 313 goals. 315 Because of item 2 in the list above, a station can be a member of no 316 more than 7 different Congestion Notification Domains because there 317 must be at least one priority that is not congestion managed for use 318 as the mapped priority of entering frames from outside the domain and 319 which are therefore not part of a congestion managed flow. As a 320 practical matter, it is unlikely that a station would be a member of 321 more than 4 or 5 different Congestion Notification Domains as 322 priorities 6 and 7 are normally used for high priority control frames 323 that are not congestion controlled and at least one low priority is 324 kept non-congestion managed for mapping as above. 326 The per port per priority state of a switch or end station will be 327 one of the following four values, which have the effects indicated: 329 o Disabled: 330 - On native frame input, frame priority can be mapped to or from 331 this priority. 332 - If this is an end-station output port, CNtags are not added. 333 - If this is a switch output port, CNtags are not stripped. 335 o Edge: 336 - On native frame input, a frame with this priority is mapped to 337 a non-CN priority and no native frame can be mapped to this 338 priority, regardless of the priority-mapping table at the port. 339 For TRILL Data frames, this also applies to the Inner.VLAN 340 priority. 341 - If this is an end-station output port, CNtags are not added. 342 - If this is a switch output port, CNtags are stripped including 343 any CNtag in the encapsulated frame if a TRILL Data frame is 344 being output. 346 o Interior: 347 - On frame input, a frame in this priority is not mapped to 348 another priority and no frame can be mapped to this priority, 349 regardless of the priority-mapping table at this port. For 350 TRILL Data frames, this also applies to the Inner.VLAN 351 priority. 352 - If this is an end-station output port, CNtags are not added. 353 - If this is a switch output port, CNtags are stripped including 354 any CNtag in the encapsulated frame if a TRILL Data frame is 355 being output. 357 o InteriorReady: 358 - On frame input, a frame in this priority is not mapped to 359 another priority and no frame can be mapped to this priority, 360 regardless of the priority-mapping table at this port. For 361 TRILL Data frames, this also applies to the Inner.VLAN 362 priority. 363 - If this is an end-station output port, CNtags may be added. 364 - If this is a switch output port, CNtags are not stripped. 366 Note that when the priority of a TRILL encapsulated frame is mapped, 367 the priority field in the Inner.VLAN tag MUST be changed. 369 2.2 Congestion Notification Tag Details 371 An end station originating a native frame may add a Congestion 372 Notification tag (CNtag) to identify the native frame's reaction 373 point in that end station, if the end station and the next hop device 374 are part of a Congestion Notification Domain. A CNtag is 4 bytes 375 long, consisting of a 2 bytes Ethertype (0x22E9) followed by a 2 376 bytes flow ID, and appears after any VLAN tag but before the frame 377 body. This CNtag flow ID is an opaque quantity only meaningful to the 378 originating end station. The inclusion of a CNtag is optional as the 379 originating end station may be able to identify the corresponding 380 reaction point from other information returned in a Congestion 381 Notification Message such as the priority. 383 As described in Section 2.3, CNtags are always added to Congestion 384 Notification Messages (CNM) when they are created. 386 2.3 Congestion Notification Message Details 388 A Congestion Notification Message (CNM) is, under certain 389 circumstances, created by a congestion point, as described in IEEE 391 [802.1Q], when a frame is entered into the queue associated with that 392 congestion point. The CNM frame always includes a Congestion 393 Notification tag (CNtag, see Section 2.2). The CNtag includes a zero 394 flow ID if the frame provoking the CNM did not have a CNtag. The body 395 of the CNM itself, after the CNtag, starts with the CNM Ethertype 396 (0x22E7) followed by the information below: 398 - CNM version information, currently zero 399 - Quantized congestion feedback information as specified in 400 [802.1Q] 401 - An 8 byte opaque ID of the congestion point generating the CNM 402 - The priority of the frame causing the CNM 403 - The destination MAC address of the frame causing the CNM 404 - The number of bytes included from the beginning of the body of 405 the frame causing the CNM 406 - The first up to 64 bytes of the body of the frame causing the 407 CNM 409 Except that input bytes/frame counters are not incremented, a CNM 410 generated at an output queue for a port is treated as if it had been 411 received on that port. CNMs are considered to be in the same VLAN as 412 the frame that provoked them and have configurable priority that 413 defaults to priority 6. 415 It is undesirable, but not an error, for a CNM to be sent in response 416 to a CNM frame which encounters congestion. This is normally avoided 417 by sending CNM frames with a priority which does not have congestion 418 notification enabled. 420 As described in Section 3.1.3 below, when a CNM is generated by an 421 TRILL switch when queuing a TRILL data frame, it is generated for the 422 enclosed frame, not for the entire TRILL data frame. This will cause 423 the CNM to be addressed to the source end station of the data. 425 3 Addition to TRILL to Support Congestion Notification 427 The figure below is used in the discussion in this section. The 428 assumption is that a frame is generated at End Station "a" (ESa) 429 destined for End Station "b" (ESb) and this frame is forwarded 430 through the sequence of 802.1 bridges (Bn) and TRILL switches 431 (RBridges, RBn) shown. For native frames from ESa, RB1 acts as the 432 ingress TRILL switch, encapsulating and directing them to egress 433 TRILL switch RB3 for decapsulation and delivery to ESb. The arrows 434 indicate the flow of a data frame. Any resulting CNM would flow in 435 the opposite direction; however, such a CNM would be independently 436 routed towards ESa and would not be constrained to follow the same 437 sequence of switches shown below. 439 +-----+ +-----+ +-----+ +-----+ 440 | ESa +-->--+ B1 | + RB3 |-->--+ B3 + 441 +-----+ +--+--+ +--+--+ +--+--+ 442 | | | 443 V ^ V 444 | | | 445 +--+--+ +-----+ +--+--+ +--+--+ 446 | RB1 +-->--+ RB2 +-->--+ B2 + | ESb | 447 +-----+ +-----+ +-----+ +-----+ 449 Figure 5: Example Frame Path 451 TRILL can make no change to the actions at any reaction points in ESa 452 or any congestion points at the output queues of B1, B2, or B3, since 453 they are not TRILL switches. Any CNM generated at B2 will be in 454 response to a TRILL frame and will need to be corrected by the 455 previous hop TRILL switch. The situation at the output queue of RB3 456 is actually the same as B3 since, as egress, RB3 will have 457 decapsulated any traffic for ESb before it tries to insert it in an 458 output queue. Thus the frame RB3 is enqueuing will be a native frame, 459 a congestion point at the RB3 output can act, for such a frame, 460 exactly as an IEEE 802.1 congestion point, and any CNM generated in 461 the RB3 output from that native frame will be treated as if it was 462 received by the RB3 port. 464 A CNM created at the RB1 or RB2 output queue is straightforward. 465 Assume the CNM is created in response to TRILL Data frame 1 (TDF1) 466 and the TDF1 encapsulates native frame 1 (NF1). The CNM would be 467 created as a TRILL encapsulated CNM with the ingress TRILL switch of 468 NF1 as its egress. The Inner.MacDA would be ESa. The Inner.MacSA 469 would be the MAC address of the port on which the TRILL encapsulated 470 CNM was initially sent, that is, the same as the Outer.MacSA. The 471 encapsulated CNM itself would be filled in as if in response to NF1, 472 not TDF1. 474 Similarly, a CNM created at B3 would have ESa as its destination 475 address and would be TRILL encapsulated when it arrived at RB3 as RB3 476 would be its ingress TRILL switch. 478 3.1 TRILL Switch Ingress Details 480 This section specifies special actions for CN at a TRILL switch input 481 port receiving a native frame, that is, the TRILL switch ingress 482 function. The usual processing on the priority of the input TRILL 483 data frame, modified as described in Section 2.1, is done. Special 484 actions are required only when the native frame received is a CNM. 486 The ingress process at a TRILL switch, say RB2, supporting CN MUST 487 detect the case of a native CNM created by a bridge in response to a 488 TRILL frame, say by B2 in Figure 4, and transform or discard it as 489 described below. No other changes are needed in the TRILL switch 490 ingress process. If such a CNM was generated in response to a TRILL 491 control (IS-IS) frame, it is discarded. 493 A native CNM requiring special actions is easily recognized on 494 ingress as it's MAC destination address will be the TRILL switch and 495 it will have the CNM Ethertype. (A CNM not addressed to the TRILL 496 switch must have been generated in response to an unencapsulated 497 native frame, for example at B3 in the diagram above, and can be 498 encapsulated by its Ingress TRILL switch and generally forwarded by 499 transit TRILL switches in the same way as other native frame.) 501 Such a native CNM resulting from a TRILL data frame at B2 has the 502 contents generally shown in Figure 6 and listed further below. 504 +-----------------------------------------------+ 505 | Ethernet Header (possibly including VLAN Tag} | 506 +-----------------------------------------------+ 507 | CNtag | 508 +-----------------------------------------------+ 509 | CNM Ethertype and Fixed Fields | 510 + - - - - - - - - - - - - - - - - - - - - - - -+ 511 | Up to 64 initial bytes of the following: | 512 | +-----------------------------------------+ | 513 | | TRILL Ethertype and Header | | 514 | +-----------------------------------------+ | 515 | | Optional CNtag | | 516 | +-----------------------------------------+ | 517 | | Native Payload | | 518 | +-----------------------------------------+ | 519 | | 520 +-----------------------------------------------+ 521 | Ethernet FCS | 522 +-----------------------------------------------+ 524 Figure 6: Native CNM Caused by a TRILL Data Frame 526 1 + Outer.MacDA, MAC address of RB2 527 2 + Outer.MacSA, MAC address of port on which B2, the bridge 528 generating this CNM, sent the CNM 529 3 + Outer.VLAN tag for the designated VLAN on the RB2 to RB3 link 530 with the priority configured at B2 for CNMs (default priority 6) 531 4 + CNtag (CNtag Ethertype 0x22E9 followed by Flow ID of zero) 532 + CNM 533 5 o CNM Ethertype 0x22E7 534 6 o CNM version information, quantized congestion feedback 535 information, and an 8 byte opaque ID of the congestion 536 point generating the CNM 537 7 o The priority of the TRILL encapsulated frame causing the 538 CNM 539 8 o The destination MAC address of the TRILL encapsulation 540 frame causing the CNM, RB3 in this case 541 9 o The number of bytes included below from the beginning of 542 the body of the TRILL encapsulation frame causing the CNM 543 + Initial bytes of body of TRILL encapsulation Data frame causing 544 the CNM 545 o TRILL Header of the frame causing the CNM 546 10 - TRILL Ethertype 0x22F3 547 11 - Flags, hop count, options length 548 12 - Egress nickname, RB3 in this case 549 13 - Ingress nickname, RB1 in this case 550 14 - Options, if any 551 15 o Inner.MacDA, MAC address of ESb 552 16 o Inner.MacSA, MAC address of ESa 553 17 o Inner.VLAN tag of the TRILL encapsulated frame causing the 554 CNM 555 18 o Optional CNtag 556 19 o Encapsulated native frame body 558 The ingressing TRILL switch RB2 transforms this CNM above into the 559 following TRILL encapsulated CNM. 561 + Outer.MacDA, MAC address of next hop RBridge (RB1) toward 562 originating end station 563 + Outer.MacSA, MAC address of RB2 port on which this TRILL 564 encapsulated CNM frame is to be sent 565 + Outer.VLAN tag for the designated VLAN on the RB2 to RB1 link 566 with priority copied from incoming Outer.VLAN, field #3 above 567 + TRILL Header to get the CNM to the right end station 568 o TRILL Ethertype 0x22F3 569 o Flags, hop count, options length 570 o Egress nickname, RB1 in this case, from ingress nickname in 571 the TRILL header in the received CNM, field #13 above 572 o Ingress nickname, RB2 in this case, the nickname of the 573 RBridge doing this transformation 574 o Options, if any 575 + Inner.MacDA, MAC address of ESa, field #16 above 576 + Inner.MacSA, MAC address of B2, field #2 above 577 + Inner.VLAN Tag with VLAN ID from field #17 above and priority 578 from field #3 above 579 + CNtag, with flow ID from field #18 above, if #18 is present, 580 otherwise flow ID of zero 581 + CNM 582 o CNM Ethertype 0x22E7 583 o CNM version information, quantized congestion feedback 584 information, and an 8 byte opaque ID of the congestion 585 point generating the CNM, field #6 above 586 o The priority of the native frame who's encapsulated form 587 caused the CNM, from Inner.VLAN, field #17 above 588 o The destination MAC address of the frame whose encapsulated 589 form caused the CNM, the Inner.MacDA, field #15 above 590 o The number of bytes included below from the beginning of 591 the body of the frame whose encapsulated form caused the 592 CNM. This will be 24 smaller (but not less than zero) than 593 the same field (#9) in the CNM tag received due to dropping 594 the TRILL Header (8 bytes), MAC addresses (12 bytes), and 595 Inner.VLAN (4 bytes). 596 + Initial bytes of the body of the frame whose encapsulated form 597 caused the CNM, field #19 above 599 Because of the reduction in the number of bytes of the body of the 600 frame that would have caused the CNM if it weren't TRILL 601 encapsulated, it is RECOMMENDED that bridges and TRILL switches 602 implementing Congestion Notification in a TRILL campus be configured 603 to include the maximum (64) number of bytes when generating a CNM. 605 3.2 Transit TRILL Switch Details 607 The subsections below describe transit TRILL switch support of 608 Congestion Notification at input and output ports. As this is a TRILL 609 switch in its transit role, only the handling of TRILL Data frames is 610 discussed. If the TRILL switch is receiving a native frame, it will 611 be an ingress as described in Section 3.1 and if it is sending a 612 native frame, it will be an egress as described in Section 3.3. 613 However, this section does apply to the output of an encapsulated 614 frame that was ingressed at a TRILL switch and to the input, in TRILL 615 encapsulated form, of a frame to be egressed at a TRILL switch. 617 3.2.1 Transit TRILL Switch Input Port 619 The usual 802.1Q processing on the priority of the input TRILL data 620 frame, modified as described in Section 2.1, is done. 622 3.2.2 Transit TRILL Switch Output Port 624 As discussed in Section 2.1, a CNtag is stripped under some 625 circumstances; however, such a CNtag will appear as part of the 626 encapsulated frame, not on the outside of the TRILL data frame, so 627 the CNtag is stripped from deeper in the frame. When there is a 628 Congestion Point enabled at a TRILL switch output queue, a CNM is not 629 generated as the result of trying to queue a TRILL control (IS-IS) 630 frame for output at a TRILL switch port. A TRILL encapsulated CNM is 631 generated in response to a TRILL Data frame composed as below, when 632 to do so is specified by [802.1Q]. The TRILL Data frame causing the 633 CNM is referred to as TDF1 and its encapsulated native frame as NF1. 635 + Outer.MacDA - MAC address of the next hop RBridge towards the 636 egress nickname used in the TRILL Header (see below) 637 + Outer.MacSA - MAC address of the output port on which the TRILL 638 encapsulated CNM is to be sent 639 + Outer.VLAN - Designated VLAN of the link on which the TRILL 640 encapsulated CNM is to be sent 641 + TRILL Header 642 o TRILL Ethertype 0x22F3 643 o Flags, hop count, options length 644 o Egress nickname, from ingress nickname in TDF1 645 o Ingress nickname, a nickname of the RBridge generating the 646 CNM 648 o Options, if any 649 + Inner.MacDA - set to the Inner.MacSA of TDF1, that is, the 650 source MAC address of NF1 651 + Inner.MacSA - same as Outer.MacSA of TDF1 652 + Inner.VLAN - same as the Inner.VLAN of TDF1, that is, the VLAN 653 tag of NF1 654 + CNtag - with flow ID from the CNtag of NF1 or zero if NF1 did 655 not have a CNtag 656 + CNM - message generated for NF1 658 3.3 TRILL Switch Egress Details 660 After decapsulation, processing of the decapsulated native frame is 661 the same as at any CN equipped output port. As discussed in Section 662 5.1, any CNtag present is stripped under some circumstances. If the 663 output queue is congested, then a native CNM may be generated in 664 response to the decapsulated native frame. This native CNM will then 665 be treated as if it had been received on the port. 667 4. Management Considerations 669 ---TBD--- 671 5. IANA Considerations 673 This document requires no IANA actions. RFC Editor: Please delete 674 this section before publication. 676 6. Security Considerations 678 See [RFC6325] for general RBridge Security Considerations. 680 ---more TBD--- 682 7. References 684 Normative and informational references for this document are given 685 below. 687 7.1 Normative References 689 [802.1Q] - IEEE, "IEEE Standard for Local and metropolitan area 690 networks / Virtual Bridged Local Area Networks", IEEE 691 802.1Q-2011, May 2011. 693 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, March 1997 696 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 697 Ghanwani, "Routing Bridges (RBridges): Base Protocol 698 Specification", RFC 6325, July 2011. 700 7.2 Informative References 702 [802.1Qaz] - IEEE, "Draft Standard for Local and Metropolitan Area 703 Networks / Virtual Bridged Local Area Networks / Amendment XX: 704 Enhanced Transmission Selection for Bandwidth Sharing Between 705 Traffic Classes", IEEE Std 802.1Qaz-2011, June 2011. 707 [802.1Qbb] - IEEE, "Draft Standard for Local and Metropolitan Area 708 Networks / Virtual Bridged Local Area Networks / Amendment: 709 Priority-based Flow Control", IEEE Std 802.1Qbb-2011, June 710 2011. 712 [802.3] IEEE, "IEEE Standard for Information technology / 713 Telecommunications and information exchange between systems / 714 Local and metropolitan area networks / Specific requirements 715 Part 3: Carrier sense multiple access with collision detection 716 (CSMA/CD) access method and physical layer specifications", 717 IEEE 802.3-2008, 26 December 2008. 719 [802.3bd] - IEEE 802.3, "Draft Standard for Information technology / 720 Telecommunications and information exchange between systems / 721 Local and Metropolitan Area Networks / Specific requirements 722 Part 3: Carrier Sense Multiple Access with Collision Detection 723 (CSMA/CD) Access Method and Physical Layer Specifications / 724 Amendment: MAC Control Frame for Priority-based Flow Control", 725 IEEE Std 802.3bd-2011, June 2011. 727 [FCoE] - http://fcoe.com/ 729 [RFC793] - Postel, J., "Transmission Control Protocol", STD 7, RFC 730 793, September 1981 732 [PfcEts] - draft-eastlake-trill-pfc-ets, work in progress. 734 Authors' Addresses 736 Donald Eastlake 3rd 737 Huawei Technologies 738 155 Beaver Street 739 Milford, MA 01757 USA 741 Tel: +1-508-333-2270 742 Email: d3e3e3@gmail.com 744 Manoj Wadekar 745 QLogic Corporation 746 26650 Aliso Viejo Pkwy 747 Aliso Viejo, CA 92656 USA 749 Tel: +1-949-389-6000 750 Email: manoj.wadekar@qlogic.com 752 Anoop Ghanwani 753 Dell 754 350 Holger Way 755 San Jose, CA 95134 USA 757 Phone: +1-408-571-3500 758 Email: anoop@alumni.duke.edu 760 Puneet Agarwal 761 Broadcom 762 3975 Freedom Circle 763 Santa Clara, CA 95054 USA 765 Phone: +1-949-926-5000 766 Email: pagarwal@broadcom.com 768 Tal Mizrahi 769 Marvell 770 6 Hamada Street 771 Yokneam, 20692 Israel 773 Email: talmi@marvell.com 775 Copyright, Disclaimer, and Additional IPR Provisions 777 Copyright (c) 2013 IETF Trust and the persons identified as the 778 document authors. All rights reserved. 780 This document is subject to BCP 78 and the IETF Trust's Legal 781 Provisions Relating to IETF Documents 782 (http://trustee.ietf.org/license-info) in effect on the date of 783 publication of this document. Please review these documents 784 carefully, as they describe your rights and restrictions with respect 785 to this document. Code Components extracted from this document must 786 include Simplified BSD License text as described in Section 4.e of 787 the Trust Legal Provisions and are provided without warranty as 788 described in the Simplified BSD License. The definitive version of 789 an IETF Document is that published by, or under the auspices of, the 790 IETF. Versions of IETF Documents that are published by third parties, 791 including those that are translated into other languages, should not 792 be considered to be definitive versions of IETF Documents. The 793 definitive version of these Legal Provisions is that published by, or 794 under the auspices of, the IETF. Versions of these Legal Provisions 795 that are published by third parties, including those that are 796 translated into other languages, should not be considered to be 797 definitive versions of these Legal Provisions. For the avoidance of 798 doubt, each Contributor to the IETF Standards Process licenses each 799 Contribution that he or she makes as part of the IETF Standards 800 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 801 language to the contrary, or terms, conditions or rights that differ 802 from or are inconsistent with the rights and licenses granted under 803 RFC 5378, shall have any effect and shall be null and void, whether 804 published or posted by such Contributor, or included with or in such 805 Contribution.