idnits 2.17.1 draft-berger-manet-dlep-ether-credit-extension-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 (May 1, 2018) is 2187 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) -- No information found for draft-ietf-manet-credit-flow-control - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-manet-credit-flow-control' == Outdated reference: A later version (-16) exists of draft-ietf-manet-dlep-da-credit-extension-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wiggins 3 Internet-Draft Lincoln Laboratory 4 Intended status: Standards Track L. Berger 5 Expires: November 2, 2018 LabN Consulting, L.L.C. 6 May 1, 2018 8 DLEP IEEE 802.1Q Aware Credit Window Extension 9 draft-berger-manet-dlep-ether-credit-extension-00 11 Abstract 13 This document defines an extension to the DLEP protocol that enables 14 a Ethernet IEEE 802.1Q aware credit-window scheme for destination- 15 specific and shared flow control. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 2, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Extension Usage and Identification . . . . . . . . . . . . . 3 54 3. Management Considerations . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Extension Type Value . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 6.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. 67 It provides the exchange of link related control information between 68 DLEP peers. DLEP peers are comprised of a modem and a router. DLEP 69 defines a base set of mechanisms as well as support for possible 70 extensions. This document defines one such extension. 72 The base DLEP specification does not include any flow control 73 capability. There are various flow control techniques theoretically 74 possible with DLEP. For example, a DiffServ aware credit window 75 extension is defined in [I-D.ietf-manet-dlep-da-credit-extension]. 77 This document defines a DLEP extension which provides a flow control 78 mechanism for traffic sent from a router to a modem. Flow control is 79 provided using one or more logical "Credit Windows", each of which 80 will typically be supported by an associated virtual or physical 81 queue. Traffic sent by a router will use traffic flow classification 82 information provided by the modem to identify which traffic is 83 associated with each credit window. (For general background on 84 traffic classification see [RFC2475] Section 2.3.) Credit windows 85 may be shared or dedicated on a per flow basis. The extension is 86 structured to allow for reuse of the defined credit window based flow 87 control with different traffic classification techniques. 89 This document uses the traffic classification and credit window 90 control mechanisms defined in [I-D.ietf-manet-credit-flow-control] to 91 provided credit window based flow control based on on DLEP 92 destination and Ethernet VLANs and Priority Code Points. Ethernet 93 Priority Code Point support is defined as part of the IEEE 802.1Q 94 [IEEE.802.1Q_2014] tag format and includes a 3 bit "PCP" field. The 95 tag format also includes a 12 bit VLAN identifier (VID) field. The 96 defined mechanism allows for credit windows to be shared across 97 traffic sent to multiple DLEP destinations VLANs, and PCPs, or used 98 exclusively for traffic sent to a particular destination and/or VLAN 99 and/or PCP. The extension also supports the "wildcard" matching of 100 any PCP or VID. 102 The extension defined in this document is referred to as "IEEE 802.1Q 103 Aware Credit Window" or, more simply, the "Ethernet Credit" 104 extension. The reader should be familiar with both the traffic 105 classification and credit window control mechanisms defined in 106 [I-D.ietf-manet-credit-flow-control]. 108 This document defines a new DLEP Extension Type Value in Section 2 109 which is used to indicate support for the extension. 111 1.1. Key Words 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 2. Extension Usage and Identification 121 The extension defined in this document is composed of the mechanisms 122 and processing defined in [I-D.ietf-manet-credit-flow-control]. To 123 indicate that the IEEE 802.1Q Aware Credit Window Extension is to be 124 used, an implementation MUST include the IEEE 802.1Q Aware Credit 125 Window Type Value in the Extensions Supported Data Item. The 126 Extensions Supported Data Item is sent and processed according to 127 [RFC8175]. Any implementation that indicates use of the IEEE 802.1Q 128 Aware Credit Window Extension MUST support all Messages, Data Items, 129 the Ethernet Traffic Classification Sub Data Item, and all related 130 processing defined in [I-D.ietf-manet-credit-flow-control]. 132 The IEEE 802.1Q Aware Credit Window Extension Type Value is TBA1, see 133 Section 5. 135 3. Management Considerations 137 This section provides several network management guidelines to 138 implementations supporting the IEEE 802.1Q Aware Credit Window 139 Extension. 141 The use of the extension defined in this document SHOULD be 142 configurable on both modems and routers. 144 Modems SHOULD support the configuration of PCP to credit window 145 (queue) mapping. 147 Modems MAY support the configuration of PCP to credit window (queue) 148 mapping on a per VLAN basis. Note that VID value of zero (0) is used 149 by [I-D.ietf-manet-credit-flow-control] to indicate that VID is 150 ignored and any VID value is used in traffic classification. 152 When VLANs are supported by a modem without support from PCPs, the 153 modem SHOULD support the configuration of VLAN to credit window 154 (queue) mapping. 156 Modems MAY support the configuration of the number of credit windows 157 (queues) to advertise to a router. 159 Routers may have limits on the number of queues that they can support 160 and, perhaps, even limits in supported credit window combinations, 161 e.g., if per destination queues can even be supported at all. When 162 modem-provided credit window information exceeds the capabilities of 163 a router, the router MAY use a subset of the provided credit windows. 164 Alternatively, a router MAY reset the session and indicate that the 165 extension is not supported. In either case, the mismatch of 166 capabilities SHOULD be reported to the user via normal network 167 management mechanisms, e.g., user interface or error logging. 169 4. Security Considerations 171 This document defines a DLEP extension that uses base DLEP mechanisms 172 and the credit window control and flow mechanisms defined in 173 [I-D.ietf-manet-credit-flow-control]. The use of those mechanisms, 174 and the introduction of a new extension, do not inherently introduce 175 any additional threats above those documented in [RFC8175]. The 176 approach taken to Security in that document applies equally to the 177 mechanism defined in this document. 179 5. IANA Considerations 181 This document requests one assignment by IANA. All assignments are 182 to registries defined by [RFC8175]. 184 5.1. Extension Type Value 186 This document requests 1 new assignment to the DLEP Extensions 187 Registry named "Extension Type Values" in the range with the 188 "Specification Required" policy. The requested value is as follows: 190 +------+---------------------------------+ 191 | Code | Description | 192 +------+---------------------------------+ 193 | TBA1 | IEEE 802.1Q Aware Credit Window | 194 +------+---------------------------------+ 196 Table 1: Requested Extension Type Value 198 6. References 200 6.1. Normative References 202 [I-D.ietf-manet-credit-flow-control] 203 IETF, "DLEP Credit-Based Flow Control Messages and Data 204 Items", April 2018. 206 [IEEE.802.1Q_2014] 207 IEEE, "IEEE Standard for Local and metropolitan area 208 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 209 DOI 10.1109/ieeestd.2014.6991462, December 2014, 210 . 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, 216 . 218 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 219 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 220 May 2017, . 222 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 223 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 224 DOI 10.17487/RFC8175, June 2017, 225 . 227 6.2. Informative References 229 [I-D.ietf-manet-dlep-da-credit-extension] 230 Cheng, B., Wiggins, D., and L. Berger, "DLEP DiffServ 231 Aware Credit Window Extension", draft-ietf-manet-dlep-da- 232 credit-extension-04 (work in progress), March 2018. 234 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 235 and W. Weiss, "An Architecture for Differentiated 236 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 237 . 239 Appendix A. Acknowledgments 241 The document was motivated by discussions in the MANET working group. 242 Many useful comments were received from contributors to the MANET 243 working group. 245 Authors' Addresses 247 David Wiggins 248 Lincoln Laboratory 249 Massachusetts Institute of Technology 250 244 Wood Street 251 Lexington, MA 02421-6426 253 Email: David.Wiggins@ll.mit.edu 255 Lou Berger 256 LabN Consulting, L.L.C. 258 Email: lberger@labn.net