idnits 2.17.1 draft-eastlake-trill-pfc-ets-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 -- The document date (January 2, 2013) is 4131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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: Informational Manoj Wadekar 4 QLogic 5 Anoop Ghanwani 6 Dell 7 Puneet Agarwal 8 Broadcom 9 Tal Mizrahi 10 Marvell 11 Expires: July 1, 2013 January 2, 2013 13 TRILL: Support of IEEE 802.1 Priority-based Flow Control 14 and Enhanced Transmission Selection 15 17 Abstract 18 This document briefly explains the IEEE 802.1 Priority-based Flow 19 Control and Enhanced Transmission standards and discusses the support 20 of these standards in TRILL switches (devices that implement the IETF 21 TRILL protocol standard). 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the authors. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 Overview of PFC and ETS................................4 50 1.2 Terminology............................................4 52 2. Priority-Based Flow Control.............................6 53 3. Enhanced Transmission Selection.........................7 54 4. The DCB Exchange Protocol...............................8 56 5. Management Considerations...............................9 57 6. IANA Considerations.....................................9 58 7. Security Considerations.................................9 59 8. References.............................................10 60 8.1 Normative References..................................10 61 8.2 Informative References................................10 63 1. Introduction 65 IEEE 802.1 has developed various standards as part of its Data Center 66 Bridging (DCB) activity. The intent of these standards is (1) to 67 efficiently minimize data loss due to queue overflow for selected 68 classes of traffic within Local Area Networks (LANs) meeting certain 69 conditions and (2) to provide limited means to allocate the available 70 bandwidth to different classes of traffic. Those standardes are 71 Priority Based Flow Control (the IEEE [802.1Qbb] standard), Enhanced 72 Tramission Selection (the IEEE [802.1Qaz] standard), and the 73 Congestion Notification (CN) feature in the IEEE [802.1Q] standard. 74 Intended uses include the support of loss sensitive services, such as 75 Fiber Channel over Ethernet [FCoE], in data centers. 77 Because they are primarily implemented at the port level, no changes 78 in the TRILL protocol are required to support PFC or ETS which are 79 discussed in this document. CN support by TRILL may be considered in 80 a separate document. 82 The existing optional PAUSE feature of IEEE 802.3 (Annex 31B of 83 [802.3]) can, with appropriate engineering, also provide Ethernet 84 service without loss of frames due to queue overflow. However, PAUSE 85 has problems as follows: 87 1. Traffic for some protocols, for example TCP [RFC793], requires 88 frame losses to signal congestion for flow control. Elimination of 89 frame drops due to congestion would prevent TCP flow control, 90 unless some other mechanism were added. 92 2. Some traffic consists of time critical network control frames, for 93 example IS-IS Hellos [IS-IS]. PAUSE is relatively indiscriminant 94 and pauses such frames, except for some MAC Control frames such as 95 PAUSE control frames themselves, along with less critical traffic. 96 Pausing such critical network control frames can compromise 97 transport connectivity. 99 3. PAUSE can result in intermittent waves of spreading traffic 100 paralysis, crippling network throughput, as follows: When a switch 101 S1 receives a PAUSE on a port P1 and can no longer transmit frames 102 out that port it is likely that output queues to P1 will fill up 103 quickly. As soon as one output queue to P1 is full or almost so 104 then, to avoid frame loss, S1 must send PAUSE frames out on each 105 of its ports that might receive a frame for output to P1. For 106 example, it might have to PAUSE input on P2 through P9, 107 unnecessarily blocking traffic between any pair of those ports, to 108 be sure it will not receive input on any of them for P1. This can 109 repeat in switches connected to S1, switches connected to switches 110 connected to S1, etc. 112 1.1 Overview of PFC and ETS 114 Overviews of the PFC and ETS standards covered herein are given 115 below. IEEE 802.1 has specified these standards and the behavior 116 needed to support them in bridges and end stations. This document 117 discusses the support of these standards in TRILL switches [RFC6325]. 119 IEEE [802.1Qbb], Priority-based Flow Control (PFC), provides a frame 120 priority based refinement of the Ethernet PAUSE feature as described 121 in Section 2. To the extent that a switch implements separate queues 122 for different priorities at each port, this can eliminate the first 123 and second of the PAUSE problems listed above. Traffic requiring 124 frame drops due to congestion can be assigned a priority for which 125 PFC is not enabled. PFC is not normally enabled for the two highest 126 priorities, 6 and 7, which are typically used for time sensitive 127 control frames. PFC also reduces the third problem as any congestion 128 spreading would affect only priorities with PFC enabled. 130 IEEE [802.1Qaz] is a standard covering two things: One, Enhanced 131 Transmission Selection (ETS), allocates bandwidth between traffic 132 class groups indicated by priority. It is described in Section 3. 133 Second, [802.1Qaz] contains the specification of the Data Center 134 Bridging Exchange Protocol (DCBX) for discovering and configuring the 135 three standards that this document covers, as described in Section 4. 137 PFC and ETS may be implemented independently or in any combination 138 except that implementation of either of them implies implementation 139 of DCBX, specified in IEEE [802.1Qaz]. 141 1.2 Terminology 143 The following acronyms are used in this document in addition to those 144 defined in [RFC6325]. 146 AVB - Audio-Visual Bridging 148 CN - Congestion Notification [802.1Q] 150 DCB - Data Center Bridging [802.1Qaz] 152 DCBX - DCB Exchange protocol [802.1Qaz] 154 ETS - Enhanced Transmission Selection [802.1Qaz] 156 FCoE - Fiber Channel over Ethernet [FCoE] 158 LLDP - Link Layer Discovery Protocol (IEEE 802.1AB) 159 PFC - Priority-based Flow Control [802.1Qbb] [802.3bd] 161 RBridge - "Routing Bridge", an alternative name for a TRILL switch 162 [RFC6325] 164 TRILL Switch - A device implementing the TRILL protocol [RFC6325] 166 2. Priority-Based Flow Control 168 IEEE [802.1Qbb], Priority-Based Flow Control (PFC), refines the IEEE 169 [802.3] PAUSE feature to permit separately requesting the pausing and 170 unpausing the traffic of each of the eight available frame priority 171 levels. The actual priority-based pause control frame is specified in 172 IEEE [802.3bd]. 174 Such queue pausing occurs within the transmission logic associated 175 with a port and requires no changes to the TRILL protocol, which is 176 implemented above such port logic, as described in [RFC6325]. 177 LLDP/DCBX is used in PFC discovery and agreement with peers as 178 described in Section 4. A TRILL switch implementing the PFC standard 179 should implement DCBX, signaling PFC support and configuration. 180 Guarantee of lossless handling of frames with a particular priority 181 in a TRILL campus requires implementation and enablement of PFC for 182 that priority at all end stations that originate frames and all TRILL 183 switches and bridges in that campus as well as meeting the PFC 184 engineering requirements in [802.1Qbb]. 186 The PFC control frames specified in [802.3bd] are MAC control frames 187 that are not VLAN tagged. Their transmission normally bypasses the 188 output queue at a port so they are transmitted immediately, or as 189 soon as the frame currently being transmitted is sent, so as to meet 190 the timing requirements of PFC. 192 3. Enhanced Transmission Selection 194 Enhanced Transmission Selection (ETS), specified in IEEE [802.1Qaz], 195 allocates bandwidth, between traffic classes, through each of the 196 ports of a switch or end station. (To be more precise, it modifies 197 the algorithm used to select, from multiple priority-based output 198 queues at a port, the next frame to transmit. Provision is made for 199 proprietary algorithms and 802.1 has also specified an algorithm in 200 connection with precise frame timing (AVB), but we are only concerned 201 with the default algorithm.) 203 Transmission selection occurs within the logic associated with a port 204 and requires no changes to the TRILL protocol, which is implemented 205 above such port logic, as described in [RFC6325]. A TRILL switch 206 implementing the ETS standard should implement DCBX (see Section 4) 207 signaling of ETS support and configuration. For ETS to be effective, 208 traffic in different ETS groups cannot share an output queue. 210 4. The DCB Exchange Protocol 212 The DCB Exchange Protocol (DCBX) is specified in IEEE [802.1Qaz], 213 which also specifies ETS as described in Section 3. 215 DCBX is built on the Link Layer Discovery Protocol (LLDP), which is 216 specified in IEEE [802.1AB]. DCBX is used for the discovery of DCB 217 capabilities of peer switches, for the detection of inconsistent 218 configuration of DCB features between peer switches, and for the 219 propagation of DCB features to switches configured to accept 220 configuration via DCBX. For purposes of TRILL protocol peering, TRILL 221 switches ignore intervening bridges, but for the purposes of LLDP and 222 DCBX all stations, including TRILL switches, 802.1 bridges, and end 223 stations are considered peers. 225 TRILL switches implementing PFC or ETS should also implement DCBX. 227 5. Management Considerations 229 ---TBD--- 231 6. IANA Considerations 233 This document requires no IANA actions. This section should be 234 deleted by the RFC Editor before publication. 236 7. Security Considerations 238 See [RFC6325] for general RBridge Security Considerations. 240 ---more TBD--- 242 8. References 244 Normative and informational references for this document are given 245 below. 247 8.1 Normative References 249 As this is an informational document, there are no normative 250 references. 252 8.2 Informative References 254 [IS-IS] - ISO/IEC, "Intermediate system to Intermediate system 255 routeing information exchange protocol for use in conjunction 256 with the Protocol for providing the Connectionless-mode Network 257 Service (ISO 8473)", ISO/IEC 10589:2002. 259 [802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area 260 networks / Station and Media Access Control Connectivity 261 Discovery", IEEE 802.1AB-2009, 17 September 2009. 263 [802.1Q] - IEEE, "IEEE Standard for Local and metropolitan area 264 networks / Virtual Bridged Local Area Networks", IEEE 265 802.1Q-2011, May 2011. 267 [802.1Qaz] - IEEE, "Draft Standard for Local and Metropolitan Area 268 Networks / Virtual Bridged Local Area Networks / Amendment XX: 269 Enhanced Transmission Selection for Bandwidth Sharing Between 270 Traffic Classes", IEEE Std 802.1Qaz-2011, June 2011. 272 [802.1Qbb] - IEEE, "Draft Standard for Local and Metropolitan Area 273 Networks / Virtual Bridged Local Area Networks / Amendment: 274 Priority-based Flow Control", IEEE Std 802.1Qbb-2011, June 275 2011. 277 [802.3] IEEE, "IEEE Standard for Information technology / 278 Telecommunications and information exchange between systems / 279 Local and metropolitan area networks / Specific requirements 280 Part 3: Carrier sense multiple access with collision detection 281 (CSMA/CD) access method and physical layer specifications", 282 IEEE 802.3-2008, 26 December 2008. 284 [802.3bd] - IEEE 802.3, "Draft Standard for Information technology / 285 Telecommunications and information exchange between systems / 286 Local and Metropolitan Area Networks / Specific requirements 287 Part 3: Carrier Sense Multiple Access with Collision Detection 288 (CSMA/CD) Access Method and Physical Layer Specifications / 289 Amendment: MAC Control Frame for Priority-based Flow Control", 290 IEEE Std 802.3bd-2011, June 2011. 292 [FCoE] - http://fcoe.com/ 294 [RFC793] - Postel, J., "Transmission Control Protocol", STD 7, RFC 295 793, September 1981 297 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 298 Ghanwani, "Routing Bridges (RBridges): Base Protocol 299 Specification", RFC 6325, July 2011. 301 Authors' Addresses 303 Donald Eastlake 3rd 304 Huawei Technologies 305 155 Beaver Street 306 Milford, MA 01757 USA 308 Tel: +1-508-333-2270 309 Email: d3e3e3@gmail.com 311 Manoj Wadekar 312 QLogic Corporation 313 26650 Aliso Viejo Pkwy 314 Aliso Viejo, CA 92656 USA 316 Tel: +1-949-389-6000 317 Email: manoj.wadekar@qlogic.com 319 Anoop Ghanwani 320 Dell 321 350 Holger Way 322 San Jose, CA 95134 USA 324 Phone: +1-408-571-3500 325 Email: anoop@alumni.duke.edu 327 Puneet Agarwal 328 Broadcom 329 3975 Freedom Circle 330 Santa Clara, CA 95054 USA 332 Phone: +1-949-926-5000 333 Email: pagarwal@broadcom.com 335 Tal Mizrahi 336 Marvell 337 6 Hamada Street 338 Yokneam, 20692 Israel 340 Email: talmi@marvell.com 342 Copyright, Disclaimer, and Additional IPR Provisions 344 Copyright (c) 2013 IETF Trust and the persons identified as the 345 document authors. All rights reserved. 347 This document is subject to BCP 78 and the IETF Trust's Legal 348 Provisions Relating to IETF Documents 349 (http://trustee.ietf.org/license-info) in effect on the date of 350 publication of this document. Please review these documents 351 carefully, as they describe your rights and restrictions with respect 352 to this document. Code Components extracted from this document must 353 include Simplified BSD License text as described in Section 4.e of 354 the Trust Legal Provisions and are provided without warranty as 355 described in the Simplified BSD License. The definitive version of 356 an IETF Document is that published by, or under the auspices of, the 357 IETF. Versions of IETF Documents that are published by third parties, 358 including those that are translated into other languages, should not 359 be considered to be definitive versions of IETF Documents. The 360 definitive version of these Legal Provisions is that published by, or 361 under the auspices of, the IETF. Versions of these Legal Provisions 362 that are published by third parties, including those that are 363 translated into other languages, should not be considered to be 364 definitive versions of these Legal Provisions. For the avoidance of 365 doubt, each Contributor to the IETF Standards Process licenses each 366 Contribution that he or she makes as part of the IETF Standards 367 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 368 language to the contrary, or terms, conditions or rights that differ 369 from or are inconsistent with the rights and licenses granted under 370 RFC 5378, shall have any effect and shall be null and void, whether 371 published or posted by such Contributor, or included with or in such 372 Contribution.