idnits 2.17.1 draft-ietf-manet-dlep-credit-flow-control-02.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 (June 26, 2018) is 2121 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) == Outdated reference: A later version (-16) exists of draft-ietf-manet-dlep-da-credit-extension-05 == Outdated reference: A later version (-08) exists of draft-ietf-manet-dlep-pause-extension-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Cheng 3 Internet-Draft D. Wiggins 4 Intended status: Standards Track MIT Lincoln Laboratory 5 Expires: December 28, 2018 L. Berger 6 LabN Consulting, L.L.C. 7 June 26, 2018 9 DLEP Credit-Based Flow Control Messages and Data Items 10 draft-ietf-manet-dlep-credit-flow-control-02 12 Abstract 14 This document defines new DLEP protocol Data Items that are used to 15 support credit-based flow control. The Data Items enable separate 16 but related functions: traffic classification and credit window 17 control. Traffic classification information is used to identify 18 traffic flows based on frame/packet content such as destination 19 address. Credit window control is used to regulate when data may be 20 sent to an associated virtual or physical queue. The Data Items are 21 defined in an extensible and reusable fashion. Their use will be 22 mandated in other documents defining specific DLEP extensions. This 23 document also introduces DLEP sub data items. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 28, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Traffic Classification . . . . . . . . . . . . . . . . . . . 4 62 2.1. Traffic Classification Data Item . . . . . . . . . . . . 5 63 2.1.1. Traffic Classification Sub Data Item . . . . . . . . 6 64 2.2. DiffServ Traffic Classification Sub Data Item . . . . . . 7 65 2.2.1. Router Receive Processing . . . . . . . . . . . . . . 8 66 2.3. Ethernet Traffic Classification Sub Data Item . . . . . . 9 67 2.3.1. Router Receive Processing . . . . . . . . . . . . . . 10 68 3. Credit Window Control . . . . . . . . . . . . . . . . . . . . 10 69 3.1. Data Plane Considerations . . . . . . . . . . . . . . . . 12 70 3.2. Credit Window Messages . . . . . . . . . . . . . . . . . 12 71 3.2.1. Credit Control Message . . . . . . . . . . . . . . . 12 72 3.2.2. Credit Control Response Message . . . . . . . . . . . 13 73 3.3. Credit Window Control Data Items . . . . . . . . . . . . 14 74 3.3.1. Credit Window Initialization . . . . . . . . . . . . 14 75 3.3.2. Credit Window Associate . . . . . . . . . . . . . . . 16 76 3.3.3. Credit Window Grant . . . . . . . . . . . . . . . . . 17 77 3.3.4. Credit Window Status . . . . . . . . . . . . . . . . 19 78 3.3.5. Credit Window Request . . . . . . . . . . . . . . . . 20 79 3.4. Management Considerations . . . . . . . . . . . . . . . . 21 80 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 22 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 6.1. Message Values . . . . . . . . . . . . . . . . . . . . . 22 84 6.2. Data Item Values . . . . . . . . . . . . . . . . . . . . 22 85 6.3. DLEP Traffic Classification Sub Data Item Registry . . . 23 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 88 7.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Introduction 94 The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. 95 It provides the exchange of link related control information between 96 DLEP peers. DLEP peers are comprised of a modem and a router. DLEP 97 defines a base set of mechanisms as well as support for possible 98 extensions. DLEP defines Data Items which are sets of information 99 that can be reused in DLEP messaging. The base DLEP specification 100 does not include any flow identification beyond DLEP endpoints or 101 flow control capability. There are various flow control techniques 102 theoretically possible with DLEP. For example, a credit-window 103 scheme for destination-specific flow control which provides aggregate 104 flow control for both modem and routers has been proposed in 105 [I-D.ietf-manet-credit-window], and a control plane pause based 106 mechanism is defined in [I-D.ietf-manet-dlep-pause-extension]. 108 This document defines DLEP Data Items and Messages which provide flow 109 identification, and a flow control mechanism for traffic sent from a 110 router to a modem. Flow control is provided using one or more 111 logical "Credit Windows", each of which will typically be supported 112 by an associated virtual or physical queue. Traffic sent by a router 113 will use traffic flow classification information provided by the 114 modem to identify which traffic is associated with each credit 115 window. In this case, a flow is identified based on information 116 found in a data plane header and one or more matches are associated 117 with a single flow. (For general background on traffic 118 classification see [RFC2475] Section 2.3.) Credit windows may be 119 shared or dedicated on a per flow basis. The Data Items are 120 structured to allow for reuse of the defined traffic classification 121 information with non-credit window applications as well as reuse of 122 the credit window based flow control with different traffic 123 classification techniques. 125 This document defines traffic classification based on a DLEP 126 destination and flows identified by either DiffServ [RFC2475] DSCPs 127 (differentiated services codepoints) or IEEE 802.1Q 128 [IEEE.802.1Q_2014] Ethernet Priority Code Points (PCP). The defined 129 mechanism allows for credit windows to be shared across traffic sent 130 to multiple DLEP destinations and flows, or used exclusively for 131 traffic sent to a particular destination and/or flow. The extension 132 also supports the "wildcard" matching of any flow (DSCP or PCP). 133 Traffic classification information is provided such that it can be 134 readily extended to support other traffic classification techniques, 135 or be used by non-credit window related extensions, such as 136 [I-D.ietf-manet-dlep-pause-extension] or even 5-tuple IP flows. 138 Note that this document defines common Messages, Data Items and 139 mechanisms that are reusable. They are expected to be required by 140 DLEP extensions defined in other documents such as found in 141 [I-D.ietf-manet-dlep-da-credit-extension]. 143 This document defines support for traffic classification using a 144 single new Data Item in Section 2.1 for general support and two new 145 sub Data Items are defined to support identification of flows based 146 on DSCPs and PCPs. The document supports credit window control by 147 introducing two new DLEP messages in Section 3.2, and five new DLEP 148 Data Items in Section 3.3. 150 1.1. Key Words 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 2. Traffic Classification 160 The Traffic Classification Data Item is used to represent a list of 161 flows that may be used at the same time for traffic sent from a 162 router to a modem. The data plane information used to identify each 163 flow is represented in a separate sub Data Item. The Data Item and 164 Sub Data Item structure is intended to be independent of any specific 165 usage of the flow identification, e.g., flow control. The Sub Data 166 Item structure is also intended to allow for future traffic 167 classification types, e.g., 5-tuple flows. While the structure of 168 the Data Items is extensible, actual flow information is expected to 169 be used in an extension dependent manner. Support for DSCP and PCP- 170 based flows are defined via individual sub Data Items below. Other 171 types of flow identification, e.g., based on IP protocol and ports, 172 may be defined in the future via new sub Data Items. 174 The list of flows contained in the Data Item can be used per sender 175 or shared across multiple senders. Each list of flows is identified 176 using a "Traffic Classification Identifier" or "TID" and is expected 177 to represent a valid combination of data plane identifiers that may 178 be used at the same time. Each flow is identified via a "Flow 179 Identifier" or "FID". Each FID is defined in a sub Data Item which 180 carries the data plane identifier or identifiers used to associate 181 traffic with the flow. A DLEP destination address is also needed to 182 complete traffic classification information used in extensions such 183 as flow control. This information is expected to be provided in an 184 extension specific manner. For example, this address can be provided 185 by a modem when it identifies the traffic classification set in a 186 Destination Up Message using the Credit Window Associate Data Item 187 defined in Section 3.3.2. The scope of TID and FID values is a 188 modem. 190 2.1. Traffic Classification Data Item 192 This sections defines the Traffic Classification Data Item. This 193 Data Item is used by a modem to provide a router with traffic 194 classification information. When an extension requires use of this 195 Data Item the Traffic Classification Data Item SHOULD be included by 196 a modem in any Session Initialization Response Message that also 197 indicates support for an extension that requires support for the 198 credit window control mechanisms defined in this document, e.g., see 199 [I-D.ietf-manet-dlep-da-credit-extension]. Updates to previously 200 provided traffic classifications or new traffic classifications MAY 201 be sent by a modem by including the Data Item in Session Update 202 Messages. More than one Data Item MAY be included in a message to 203 provide information on multiple traffic classifiers. 205 The set of traffic classification information provided in the data 206 item is identified using a Traffic Classification Identifier, or TID. 207 The actual data plane related information used in traffic 208 classification is provided in a variable list of Traffic 209 Classification Sub Data Items. 211 The format of the Traffic Classification Data Item is: 213 0 1 2 3 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Data Item Type | Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |Traffic Class. Identifier (TID)| Num SDIs | Reserved | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Traffic Classification Sub Data Item 1 | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 : ... : 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Traffic Classification Sub Data Item n | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Data Item Type: TBA1 229 Length: Variable 231 Per [RFC8175] Length is the number of octets in the Data Item, 232 excluding the Type and Length fields. 234 Traffic Classification Identifier (TID): 236 A 16-bit unsigned integer identifying a traffic classification 237 set. There is no restriction on values used by a modem, and there 238 is no requirement for sequential or ordered values. 240 Num SDIs: 242 An 8-bit unsigned integer indicating the number of Traffic 243 Classification Sub Data Items included in the Data Item. A value 244 of zero (0) is allowed and indicates that no traffic should be 245 matched against this TID. 247 Reserved: 249 MUST be set to zero by the sender (a modem) and ignored by the 250 receiver (a router). 252 Traffic Classification Sub Data Item: 254 Zero or more Traffic Classification Sub Data Items of the format 255 defined below MAY be included. The number MUST match the value 256 carried in the Num SDIs field. 258 A router receiving the Traffic Classification Data Item MUST locate 259 the traffic classification information that is associated with the 260 TID indicated in each received Data Item. If no associated traffic 261 classification information is found, the router MUST initialize a new 262 information set using the values carried in the Data Item. When 263 associated traffic classification information is found, the router 264 MUST update the information using the values carried in the Data 265 Item. In both cases, a router MUST also ensure that any data plane 266 state, e.g., see Section 3.1, that is associated with the TID is 267 updated as needed. 269 2.1.1. Traffic Classification Sub Data Item 271 All Traffic Classification Sub Data Items share a common format that 272 is patterned after the standard DLEP Data Item format, see [RFC8175] 273 Section 11.3. There is no requirement on, or meaning to sub Data 274 Item ordering. Any errors or inconsistencies encountered in parsing 275 sub Data Items are handled in the same fashion as any other Data Item 276 parsing error encountered in DLEP. 278 The format of the Traffic Classification Sub Data Item is: 280 0 1 2 3 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Sub Data Item Type | Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Value... : 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Sub Data Item Type: 290 A 16-bit unsigned integer that indicates the type and 291 corresponding format of the Sub Data Item's Value field. Sub Data 292 Item Types are scoped within the Data Item in which they are 293 carried, i.e., the Sub Data Item Type field MUST be used together 294 with the Data Item Type to identify the format of the Sub Data 295 Item. Traffic Classification Sub Data Item Types are managed 296 according to the IANA registry described in Section 6.3. 298 Length: Variable 300 Copying [RFC8175], Length is a 16-bit unsigned integer that is the 301 number of octets in the sub Data Item, excluding the Type and 302 Length fields. 304 2.2. DiffServ Traffic Classification Sub Data Item 306 The DiffServ Traffic Classification Sub Data Item is used to identify 307 the set of DSCPs that should be treated as a single flow, i.e., 308 receive the same traffic treatment. DSCPs are identified in a list 309 of DiffServ fields. An implementation that does not support DSCPs 310 and wants the same traffic treatment for all traffic to a destination 311 or destinations would indicate 0 DSCPs. 313 The format of the DiffServ Traffic Classification Sub Data Item is: 315 0 1 2 3 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Must be one (1) | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Flow Identifier (FID) | Num DSCPs | DS Field 1 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | DS Field 2 | ... | DS Field n | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Length: Variable 326 Length is defined above. For this Sub Data Item, it is equal to 327 three (3) plus the value of the Num DSCPs field. 329 Flow Identifier (FID): 331 A 16-bit unsigned integer representing the data plane information 332 carried in the sub Data Item that is to be used in identifying a 333 flow. The value of 0xFFFF is reserved and MUST NOT be used in 334 this field. 336 Num DSCPs: 338 An 8-bit unsigned integer indicating the number of DSCPs carried 339 in the sub Data Item. A zero (0) indicates a (wildcard) match 340 against any DSCP value. 342 DS Field: 344 Each DS Field is an 8-bit whose definition is the same as 345 [RFC2474]. 347 0 1 2 3 4 5 6 7 348 +---+---+---+---+---+---+---+---+ 349 | DSCP | CU | 350 +---+---+---+---+---+---+---+---+ 352 DSCP: differentiated services codepoint 353 CU: currently unused, MUST be zero 355 2.2.1. Router Receive Processing 357 A router receiving the Traffic Classification Sub Data Item MUST 358 validate the information on receipt, prior to using the carried 359 information, including potentially updating the data behavior as 360 determined by the extension requiring the use of the Sub Data Item. 361 Validation failures MUST be treated as an error as described above. 363 Once validated, the receiver MUST ensure that each DS Field value is 364 listed only once across the whole Traffic Classification Data Item. 365 Note, this check is across the Data Item and not the individual sub 366 Data Item. If the same DS Field value is listed more than once 367 within the same Traffic Classification Data Item, the Data Item MUST 368 be treated as an error as described above. 370 2.3. Ethernet Traffic Classification Sub Data Item 372 The Ethernet Traffic Classification Sub Data Item is used to identify 373 the VLAN and PCPs that should be treated as a single flow, i.e., 374 receive the same traffic treatment. Ethernet Priority Code Point 375 support is defined as part of the IEEE 802.1Q [IEEE.802.1Q_2014] tag 376 format and includes a 3 bit "PCP" field. The tag format also 377 includes a 12 bit VLAN identifier (VID) field. PCPs are identified 378 in a list of priority fields. An implementation that does not 379 support PCPs and wants the same traffic treatment for all traffic to 380 a destination or destinations would indicate 0 PCPs. Such an 381 implementation could identify a VLAN to use per destination. 383 The format of the Ethernet Traffic Classification Sub Data Item is: 385 0 1 2 3 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Must be two (2) | Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Flow Identifier (FID) |NumPCPs| VLAN Identifier (VID) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Pri. 1| Pri. 2| ..... | ..... | ..... | Pad | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Length: Variable 397 Length is defined above. For this Sub Data Item, it is equal to 398 four (4) plus the number of octets needed to carry the carried 399 Priority fields is indicated by the NumPCPs field. Note that as 400 length is in octets and each Priority field is 4 bits, the 401 additional length is the value carried in the NumPCPs field 402 divided by two and rounded up to the next higher integer quantity. 404 Flow Identifier (FID): 406 A 16-bit unsigned integer representing the data plane information 407 carried in the sub Data Item that is to be used in identifying a 408 flow. The value of 0xFFFF is reserved and MUST NOT be used in 409 this field. 411 Num PCPs: 413 A 4-bit unsigned integer indicating the number of Priority fields 414 carried in the sub Data Item. A zero (0) indicates a (wildcard) 415 match against any PCP value. 417 VLAN identifier (VID): 419 A 12-bit unsigned integer field indicating the VLAN to be used in 420 traffic classification. A value of zero (0) indicates that the 421 VID is to be ignored and any VID is to be accepted during traffic 422 classification. 424 Priority: 426 Each Priority Field is 4-bits long and indicates a PCP field 427 defined in [IEEE.802.1Q_2014]. Note that zero (0) is a valid 428 value for either PCP or DEI. 430 0 1 2 3 431 +---+---+---+---+ 432 | PCP |DEI| 433 +---+---+---+---+ 435 PCP: Priority code point 436 DEI: currently unused, MUST be zero 438 Pad: 440 A 4-bit long field included when NumPCPs is an odd number. This 441 field MUST be set to zero when added, and MIST be ignored on 442 receipt. 444 2.3.1. Router Receive Processing 446 A router receiving the Traffic Classification Sub Data Item MUST 447 validate the information on receipt, prior to the using the carried 448 information, including potentially updating the data behavior as 449 determined by the extension requiring the use of the Sub Data Item. 450 Validation failures MUST be treated as an error as described above. 452 Once validated, the receiver MUST ensure that each Priority Field 453 value is listed only once across the whole Traffic Classification 454 Data Item. Note, this check is across the Data Item and not the 455 individual sub Data Item. If the same Priority Field value is listed 456 more than once within the same Traffic Classification Data Item, the 457 Data Item MUST be treated as an error as described above. 459 3. Credit Window Control 461 This section defines additions to DLEP used in credit based flow 462 control. In addition to the Traffic Classification Data Item, two 463 new messages and five Data Items are defined to support credit window 464 control. The use of credit window control impacts the data plane. 466 The credit window control mechanisms defined in this document support 467 credit based flow control of traffic sent from a router to a modem. 468 The mapping of specific flows of traffic to a particular credit 469 window is based on the Traffic Classification Data Item defined in 470 Section 2.1. Both types of DLEP endpoints, i.e., a router and a 471 modem, negotiate the use of extension during session initialization, 472 e.g., see [I-D.ietf-manet-dlep-da-credit-extension]. When using 473 credit windows, data traffic is only allowed to be sent by the router 474 to the modem when there are credits available. 476 Credits are managed on a per logical "Credit Windows" basis. Each 477 credit window can be thought of as corresponding to a queue within a 478 modem. Credit windows may be shared across, or dedicated to, 479 destinations and data plane identifiers, e.g., DSCPs, at a 480 granularity that is appropriate for a modem's implementation and its 481 attached transmission technology. As defined below, there is a 482 direct one-for-one mapping of credit windows to flows as identified 483 by FIDs carried within the Traffic Classification Data Item. Modems 484 pass to the router information on their credit windows and FIDs prior 485 to a router being able to send data when an extension requiring the 486 use of credit window control is used. In addition to the traffic 487 classification information associated with an FID, routers provide an 488 initial credit window size, as well as the maximum size of the 489 logical queue associated with each credit window. The maximum size 490 is included for informative and potential future uses. 492 Modems provide an initial credit window size at the time of "Credit 493 Window Initialization". Such initialization can take place during 494 session initiation or any point thereafter. It can also take place 495 when rate information changes. Additional "Credit Grants", i.e., 496 increments to Credit Window size, are provided using a Destination Up 497 or the new "Credit Control" Message. A router provides its view of 498 the Credit Window, which is known as "Status", in Destination Up 499 Response and the new "Credit Control Response" Messages. Routers can 500 also request credits using the new "Credit Control" Message. 502 When modems provide credits to a router, they will need to take into 503 account any overhead of their attached transmission technology and 504 map it into the credit semantics defined in this document. In 505 particular, the credit window is defined below to include per frame 506 (packet) MAC headers, and this may not match the actual overhead of 507 the modem attached transmission technology. In that case a direct 508 mapping, or an approximation will need to be made by the modem to 509 provide appropriate credit values. 511 Actual flows of traffic are mapped to credit windows based on flow 512 identification information provided by modems in the Traffic 513 Classification Data item defined in Section 2. This data item 514 supports traffic classification on a per destination or more fine 515 grain level. Routers use the combination of the DLEP identified 516 destination and flow information associated with a credit window in 517 order to match traffic they send to specific credit windows. 519 When a destination becomes reachable, a modem "Associates" 520 (identifies) the appropriate traffic classification information via 521 the TID to be used for traffic sent by the router to that 522 destination. As defined, each credit window has a corresponding FID. 523 This means that the use of FIDs, TIDs and the association of a TID to 524 a DLEP destination enables a modem to share or dedicate resources as 525 needed to match the specifics of its implementation and its attached 526 transmission technology. 528 The defined credit window control has similar objectives as the 529 control found in [I-D.ietf-manet-credit-window]. One notable 530 difference from that credit control is that in this document, credits 531 are never provided by the router to the modem. 533 3.1. Data Plane Considerations 535 When credit windowing is used, a router MUST NOT send data traffic to 536 a modem for forwarding when there are no credits available in the 537 associated Credit Window. This document defines credit windows in 538 octets. A credit window value MUST be larger than the number of 539 octets contained in a packet, including any MAC headers used between 540 the router and the modem, in order for the router to send the packet 541 to a modem for forwarding. The credit window is decremented by the 542 number of sent octets. 544 A router MUST identify the credit window associated with traffic sent 545 to a modem based on the traffic classification information provided 546 in the Data Items defined in this document. Note that routers will 547 typically view a DLEP destination as the next hop MAC address. 549 3.2. Credit Window Messages 551 Two new messages are defined in support for credit window control: 552 the Credit Control and the Credit Control Response Message. Sending 553 and receiving both message types is REQUIRED to support the credit 554 window control defined in this document. 556 3.2.1. Credit Control Message 558 Credit Control Messages are sent by modems and routers. Each sender 559 is only permitted to have one message outstanding at one time. That 560 is, a sender (i.e., modem or router) MUST NOT send a second or any 561 subsequent Credit Control Message until a Credit Control Response 562 Message is received from its peer (i.e., router or modem). 564 Credit Control Messages are sent by modems to provide credit window 565 increases. Modems send credit increases when there is transmission 566 or local queue availability that exceeds the credit window value 567 previous provided to the router. Modems will need to balance the 568 load generated by sending and processing frequent credit window 569 increases against a router having data traffic available to send, but 570 no credits available. 572 Credit Control Messages MAY be sent by routers to request credits and 573 provide window status. Routers will need to balance the load 574 generated by sending and processing frequent credit window requests 575 against a having data traffic available to send, but no credits 576 available. 578 The Message Type value in the DLEP Message Header is set to TBA2. 580 A message sent by a modem, MUST contain one or more Credit Window 581 Grant Data Items as defined below in Section 3.3.3. A router 582 receiving this message MUST respond with a Credit Control Response 583 Message. 585 A message sent by a router, MUST contain one or more Credit Window 586 Request Data Items defined below in Section 3.3.5 and SHOULD contain 587 a Credit Window Status Data Item, defined in Section 3.3.4, 588 corresponding to each credit window request. A modem receiving this 589 message MUST respond with a Credit Control Response Message based on 590 the received message and Data Item and the processing defined below, 591 which will typically result in credit window increments being 592 provided. 594 Specific processing associated with each Credit Data Item is provided 595 below. 597 3.2.2. Credit Control Response Message 599 Credit Control Response Messages are sent by routers to report the 600 current Credit Window for a destination. A message sent by a router, 601 MUST contain one or more Credit Window Status Data Items as defined 602 below in Section 3.3.4. Specific receive processing associated with 603 the Credit Window Status Data Item is provided below. 605 Credit Control Response Messages sent by modems MUST contain one or 606 more Credit Window Grant Data Items. A Data Item for every Credit 607 Window Request Data Item contained in the corresponding Credit 608 Control Response Message received by the modem MUST be included. 610 Each Credit Grant Data Item MAY provide zero or more additional 611 credits based on the modem's transmission or local queue 612 availability. Specific receive processing associated with each Grant 613 Data Item is provided below. 615 The Message Type value in the DLEP Message Header is set to TBA3. 617 3.3. Credit Window Control Data Items 619 Five new Data Items are defined to support credit window control. 620 The Credit Window Initialization Data Item is used by a modem to 621 identify a credit window and set its size. The Credit Window 622 Association Data Item is used by a modem to identify which traffic 623 classification identifiers (flows) should be used when sending 624 traffic to a particular DLEP identified destination. The Credit 625 Window Grant is used by a modem to provide additional credits to a 626 router. The Credit Request is used by a router to request additional 627 credits. The Credit Window Status is used to advertise the sender's 628 view of number of available credits for state synchronization 629 purposes. 631 Any errors or inconsistencies encountered in parsing Data Items are 632 handled in the same fashion as any other data item parsing error 633 encountered in DLEP, see [RFC8175]. In particular, the node parsing 634 the Data Item MUST terminate the session with a Status Data Item 635 indicating Invalid Data. 637 3.3.1. Credit Window Initialization 639 The Credit Window Initialization Data Item is used by a modem to 640 identify a credit window and set its size. This Data Item SHOULD be 641 included in any Session Initialization Response Message that also 642 indicates support for an extension that requires support for the 643 credit window control mechanisms defined in this document, e.g., see 644 [I-D.ietf-manet-dlep-da-credit-extension]. Updates to previously 645 identified credit windows or new credit windows MAY be sent by a 646 modem by including the Data Item in Session Update Messages. More 647 than one data item MAY be included in a message to provide 648 information on multiple credit windows. 650 The Credit Window Initialization Data Item identifies a credit window 651 using a Flow Identifier, or FID. It also provides the size of the 652 identified credit window. Finally, a queue size (in bytes) is 653 provided for informational purposes. Note that to be used, a FID 654 must be defined within a Traffic Classification Data Item and the 655 associated TID must be provided via a Credit Window Association Data 656 Item. 658 The format of the Credit Window Initialization Data Item is: 660 0 1 2 3 661 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Data Item Type | Length (16) | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Flow Identifier (FID) | Reserved | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Credit Value : 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 : Credit Value | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Scale | Credit Window Size | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Data Item Type: TBA4 676 Length: 16 678 Per [RFC8175] Length is the number of octets in the Data Item. It 679 MUST be equal to sixteen (16). 681 Flow Identifier (FID): 683 A flow identifier as defined by the Traffic Classification Data 684 Item. The FID also uniquely identifies a credit window. 686 Reserved: 688 MUST be set to zero by the sender (a modem) and ignored by the 689 receiver (a router). 691 Credit Value: 693 A 64-bit unsigned integer representing the credits, in octets, to 694 be applied to the Credit Window. This value includes MAC headers 695 as seen on the link between the modem and router. 697 Scale: 699 An 8-bit unsigned integer indicating the scale used in the Credit 700 Window Size fields. The valid values are: 702 Value Scale 703 ------------ 704 0 B - Bytes (Octets) 705 1 KB - Kilobytes (B/1024) 706 2 MB - Megabytes (KB/1024) 707 3 GB - Gigabytes (MB/1024) 709 Credit Window Size: 711 A 24-bit unsigned integer representing the maximum size, in the 712 octet scale indicated by the Scale field, of the associated credit 713 window. 715 A router that receives a Credit Window Initialization Data Item MUST 716 ensure that the FID field value has been provided by the modem in a 717 Traffic Classification Data Item carried in either the current or 718 previous message. If the FID cannot be found the router SHOULD 719 report or log this information. Note that no traffic will be 720 associated with the credit window in this case. After FID 721 validation, the router MUST locate the credit window that is 722 associated with the FID indicated in each received Data Item. If no 723 associated credit window is found, the router MUST initialize a new 724 credit window using the values carried in the Data Item. When an 725 associated credit window is found, the router MUST update the credit 726 window and associated data plane state using the values carried in 727 the Data Item. It is worth noting, that such updates can result in a 728 credit window size being reduced, for example, due to a transmission 729 rate change on the modem. 731 3.3.2. Credit Window Associate 733 The Credit Window Associate Data Item is used by a modem to associate 734 traffic classification information with a destination. The traffic 735 classification information is identified using a TID value that has 736 previously been sent by the modem or is listed in a Traffic 737 Classification Data Item carried in the same message as the Data 738 Item. 740 A single Credit Window Associate Data Item MUST be included in all 741 Destination Up and Destination Update Messages sent by a modem when 742 the credit window control defined in this document is used. Note 743 that a TID will not be used unless it is listed in a Credit Window 744 Associate Data Item. 746 The format of the Credit Window Associate Data Item is: 748 0 1 2 3 749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Data Item Type | Length (2) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 |Traffic Class. Identifier (TID)| 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Data Item Type: TBA5 758 Length: 2 760 Per [RFC8175] Length is the number of octets in the Data Item. It 761 MUST be equal to two (2). 763 Traffic Classification Identifier (TID): 765 A 16-bit unsigned integer identifying a traffic classification set 766 that has been identified in a Traffic Classification Data Item, 767 see Section 2.1. 769 A router that receives the Credit Window Associate Data Item MUST 770 locate the traffic classification information indicated by the 771 received TID. If no corresponding information can be located, the 772 Data Item MUST be treated as an error as described above. Once the 773 traffic classification information is located, it MUST be associated 774 with the destination and the router MUST ensure that any data plane 775 state, see Section 3.1, that is associated with the TID and its 776 corresponding FIDs is updated as needed. 778 3.3.3. Credit Window Grant 780 The Credit Window Grant Data Item is used by a modem to provide 781 credits to a router. One or more Credit Window Grant Data Items MAY 782 be carried in the DLEP Destination Up, Destination Announce Response, 783 Destination Update, Credit Control Messages, and Credit Control 784 Response Messages. Multiple Credit Window Grant Data Items in a 785 single message are used to indicate different credit values for 786 different credit windows. In all message types, this Data Item 787 provides an additional number of octets to be added to the indicated 788 credit window. Credit windows are identified using FID values that 789 have been previously been sent by the modem or are listed in a Credit 790 Window Initialization Data Item carried in the same messages as the 791 Data Item. 793 The format of the Credit Window Grant Data Item is: 795 0 1 2 3 796 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Data Item Type | Length (12) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Flow Identifier (FID) | Reserved | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Additional Credits : 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 : Additional Credits | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Data Item Type: TBA6 809 Length: 12 811 Per [RFC8175], Length is the number of octets in the Data Item. 812 It MUST be equal to twelve (12). 814 Flow Identifier (FID): 816 A flow identifier as defined by the Traffic Classification Data 817 Item. The FID also uniquely identifies a credit window. 819 Additional Credit: 821 A 64-bit unsigned integer representing the credits, in octets, to 822 be added to the Credit Window. This value includes MAC headers as 823 seen on the link between the modem and router. A value of zero 824 indicates that no additional credits are being provided. 826 When receiving this Data Item, a router MUST identify the credit 827 window indicated by the FID. If the FID is not known to the router, 828 it SHOULD report or log this information and discard the Data Item. 829 It is important to note that while this Data Item can be received in 830 a destination specific message, credit windows are managed 831 independently from the destination identified in the message carrying 832 this Data Item, and the indicated FID MAY even be disjoint from the 833 identified destination. 835 Once the credit window is identified, the credit window size MUST be 836 increased by the value contained in the Additional Credits field. If 837 the increase results in a window overflow, i.e., the size of the 838 credit window after the increase is smaller than the original credit 839 window size, the Credit Window must be set to its maximum 840 (0xFFFFFFFFFFFFFFFF). 842 No response is sent by the router to a modem after processing a 843 Credit Window Grant Data Item received in a Credit Control Response 844 Message. In other cases, the receiving router MUST send a Credit 845 Window Status Data Item or items reflecting the resulting Credit 846 Window value of the updated credit window. When the Credit Grant 847 Data Item is received in a Destination Up Message, the Credit Window 848 Status Data Item(s) MUST be sent in the corresponding Destination Up 849 Response Message. Otherwise, a Credit Control Message MUST be sent. 851 3.3.4. Credit Window Status 853 The Credit Window Status Data Item is used by a router to report the 854 current credit window size to its peer modem. One or more Credit 855 Window Status Data Items MAY be carried in a Destination Up Response 856 Message or a Credit Control Response Message. As discussed above, 857 the Destination Up Response Message is used when the Data Item is 858 sent in response to a Destination Up Message, and the Credit Control 859 Response Message is sent in response to a Credit Control Message. 860 Multiple Credit Window Status Data Items in a single message are used 861 to indicate different sizes of different credit windows. Similar to 862 the Credit Window Grant, credit windows are identified using FID 863 values that have been previously been sent by the modem. 865 The format of the Credit Window Status Data Item is: 867 0 1 2 3 868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Data Item Type | Length (12) | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Flow Identifier (FID) | Reserved | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Credit Window Size : 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 : Credit Window Size | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Data Item Type: TBA7 881 Length: 12 883 Per [RFC8175] Length is the number of octets in the Data Item. It 884 MUST be equal to twelve (12). 886 Flow Identifier (FID): 888 A flow identifier as defined by the Traffic Classification Data 889 Item. The FID also uniquely identifies a credit window. 891 Credit Window Size: 893 A 64-bit unsigned integer, indicating the current number of 894 credits, in octets, available for the router to send to the modem. 895 This is referred to as the Modem Receive Window in 896 [I-D.ietf-manet-credit-window]. 898 When receiving this Data Item, a modem MUST identify the credit 899 window indicated by the FID. If the FID is not known to the modem, 900 it SHOULD report or log this information and discard the Data Item. 901 As with the Credit Window Grant Data Item, the FID MAY be unrelated 902 to the Destination indicated in the message carrying the Data Item. 904 Once the credit window is identified, the modem SHOULD check the 905 received Credit Window Size field value against the outstanding 906 credit window's available credits at the time the most Credit Window 907 Initialization or Grant Data Item associated with the indicated FID 908 was sent. If the values significantly differ, i.e., greater than can 909 be accounted for based on observed data frames, then the modem SHOULD 910 send a Credit Window Initialization Data Item to reset the associated 911 credit window size to the modem's current view of the available 912 credits. As defined above, Credit Window Initialization Data Items 913 are sent in Session Update Messages. When multiple Data Items need 914 to be sent, they SHOULD be combined into a single message when 915 possible. Alternatively, and also in cases where there are small 916 differences, the modem MAY adjust the values sent in Credit Window 917 Grant Data Items to account for the reported Credit Window. 919 3.3.5. Credit Window Request 921 The Credit Window Request Data Item is used by a router to request 922 additional credits for particular credit windows. Credit Window 923 Request Data Items are carried in Credit Control Messages, and one or 924 more Credit Window Request Data Items MAY be present in a message. 926 Credit windows identified using a FID as defined above in 927 Section 3.3.1. Multiple FIDs MAY be present to allow for the case 928 where the router identifies that credits are needed in multiple 929 credit windows. A special FID value, as defined below, is used to 930 indicate that a credit request is being made across all queues. 932 The format of the Credit Window Request Data Item is: 934 0 1 2 3 935 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Data Item Type | Length | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Flow Identifier (FID) | ... : 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 : ... | Flow Identifier (FID) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Data Item Type: TBA8 946 Length: Variable 948 Per [RFC8175] Length is the number of octets in the Data Item, 949 excluding the Type and Length fields. It will equal the number of 950 FID fields carried in the Data Item times 2 and MUST be at least 951 2. 953 Flow Identifier (FID): 955 A flow identifier as defined by the Traffic Classification Data 956 Item. The FID also uniquely identifies a credit window. The 957 special value of 0xFFFF indicates that the request applies to all 958 FIDs. 960 A modem receiving this Data Item MUST provide a Credit Increment for 961 the indicated credit windows via Credit Window Grant Data Items 962 carried in a new Credit Control Message. Multiple values and queue 963 indexes SHOULD be combined into a single Credit Control Message when 964 possible. Unknown FID values SHOULD be reported or logged and then 965 ignored by the modem. 967 3.4. Management Considerations 969 This section provides several network management guidelines to 970 implementations supporting the credit window mechanisms defined in 971 this document. 973 Modems MAY support the configuration of the number of credit windows 974 (queues) to advertise to a router. 976 Routers may have limits on the number of queues that they can support 977 and, perhaps, even limits in supported credit window combinations, 978 e.g., if per destination queues can even be supported at all. When 979 modem-provided credit window information exceeds the capabilities of 980 a router, the router MAY use a subset of the provided credit windows. 981 Alternatively, a router MAY reset the session and indicate that the 982 extension is not supported. In either case, the mismatch of 983 capabilities SHOULD be reported to the user via normal network 984 management mechanisms, e.g., user interface or error logging. 986 4. Compatibility 988 The data items defined in this document will only be used when 989 extensions require their use. 991 5. Security Considerations 993 This document introduces credit window control and flow mechanisms to 994 DLEP. These mechanisms do not inherently introduce any additional 995 threats above those documented in [RFC8175]. The approach taken to 996 Security in that document applies equally to the mechanism defined in 997 this document. 999 6. IANA Considerations 1001 This document requests the assignment of several values by IANA. All 1002 assignments are to registries defined by [RFC8175]. 1004 6.1. Message Values 1006 This document requests 2 new assignments to the DLEP Message Registry 1007 named "Message Values" in the range with the "Specification Required" 1008 policy. The requested values are as follows: 1010 +-----------+-------------------------+ 1011 | Type Code | Description | 1012 +-----------+-------------------------+ 1013 | TBA2 | Credit Control | 1014 | | | 1015 | TBA3 | Credit Control Response | 1016 +-----------+-------------------------+ 1018 Table 1: Requested Message Values 1020 6.2. Data Item Values 1022 This document requests the following new assignments to the DLEP Data 1023 Item Registry named "Data Item Type Values" in the range with the 1024 "Specification Required" policy. The requested values are as 1025 follows: 1027 +-----------+------------------------------+ 1028 | Type Code | Description | 1029 +-----------+------------------------------+ 1030 | TBA1 | Traffic Classification | 1031 | | | 1032 | TBA4 | Credit Window Initialization | 1033 | | | 1034 | TBA5 | Credit Window Association | 1035 | | | 1036 | TBA6 | Credit Window Grant | 1037 | | | 1038 | TBA7 | Credit Window Status | 1039 | | | 1040 | TBA8 | Credit Window Request | 1041 +-----------+------------------------------+ 1043 Table 2: Requested Data Item Values 1045 6.3. DLEP Traffic Classification Sub Data Item Registry 1047 Upon approval of this document, IANA is requested to create a new 1048 DLEP registry, named "Traffic Classification Sub Data Item Type 1049 Values". The registry shall identify the type code value, the Data 1050 Item which may use the value, and a description of the value. While 1051 the same value may be reused in different Data Items, this is not 1052 recommended at this time. 1054 The following table provides initial registry values and the 1055 [RFC8126] defined policies that should apply to the registry: 1057 +-------------+---------------------------------+ 1058 | Type Code | Description | 1059 +-------------+---------------------------------+ 1060 | 0 | Reserved | 1061 | | | 1062 | 1 | DiffServ Traffic Classification | 1063 | | | 1064 | 2 | Ethernet Traffic Classification | 1065 | | | 1066 | 3-65407 | Specification Required | 1067 | | | 1068 | 65408-65534 | Private Use | 1069 | | | 1070 | 65535 | Reserved | 1071 +-------------+---------------------------------+ 1073 Table 3: Initial Registry Values 1075 7. References 1077 7.1. Normative References 1079 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1080 Requirement Levels", BCP 14, RFC 2119, 1081 DOI 10.17487/RFC2119, March 1997, 1082 . 1084 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1085 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1086 May 2017, . 1088 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 1089 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 1090 DOI 10.17487/RFC8175, June 2017, 1091 . 1093 7.2. Informative References 1095 [I-D.ietf-manet-credit-window] 1096 Ratliff, S., "Credit Windowing extension for DLEP", draft- 1097 ietf-manet-credit-window-07 (work in progress), November 1098 2016. 1100 [I-D.ietf-manet-dlep-da-credit-extension] 1101 Cheng, B., Wiggins, D., and L. Berger, "DLEP DiffServ 1102 Aware Credit Window Extension", draft-ietf-manet-dlep-da- 1103 credit-extension-05 (work in progress), May 2018. 1105 [I-D.ietf-manet-dlep-pause-extension] 1106 Cheng, B., Wiggins, D., and L. Berger, "DLEP Control Plane 1107 Based Pause Extension", draft-ietf-manet-dlep-pause- 1108 extension-03 (work in progress), March 2018. 1110 [IEEE.802.1Q_2014] 1111 IEEE, "IEEE Standard for Local and metropolitan area 1112 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 1113 DOI 10.1109/ieeestd.2014.6991462, December 2014, 1114 . 1117 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1118 "Definition of the Differentiated Services Field (DS 1119 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1120 DOI 10.17487/RFC2474, December 1998, 1121 . 1123 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1124 and W. Weiss, "An Architecture for Differentiated 1125 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1126 . 1128 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1129 Writing an IANA Considerations Section in RFCs", BCP 26, 1130 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1131 . 1133 Appendix A. Acknowledgments 1135 The sub Data Item format was inspired by Rick Taylor's "Data Item 1136 Containers". He also proposed the separation of credit windows from 1137 traffic classification at IETF98. Many useful comments were received 1138 from contributors to the MANET working group. This document was 1139 derived from [I-D.ietf-manet-dlep-da-credit-extension] as a result of 1140 discussions at IETF101. 1142 Authors' Addresses 1144 Bow-Nan Cheng 1145 MIT Lincoln Laboratory 1146 Massachusetts Institute of Technology 1147 244 Wood Street 1148 Lexington, MA 02421-6426 1150 Email: bcheng@ll.mit.edu 1152 David Wiggins 1153 MIT Lincoln Laboratory 1154 Massachusetts Institute of Technology 1155 244 Wood Street 1156 Lexington, MA 02421-6426 1158 Email: David.Wiggins@ll.mit.edu 1160 Lou Berger 1161 LabN Consulting, L.L.C. 1163 Email: lberger@labn.net