idnits 2.17.1 draft-ietf-manet-dlep-da-credit-extension-03.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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A 16-bit unsigned integer identifying a credit window. The value of 0xFFFFFFFF is reserved and MUST not be used in this data item. There is no other restriction on values used by a modem, and there is no requirement for sequential or ordered values. -- The document date (November 11, 2017) is 2357 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 issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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 Lincoln Laboratory 5 Expires: May 15, 2018 L. Berger 6 LabN Consulting, L.L.C. 7 November 11, 2017 9 DLEP DiffServ Aware Credit Windowing Extension 10 draft-ietf-manet-dlep-da-credit-extension-03 12 Abstract 14 This document defines an extension to the DLEP protocol that enables 15 a DiffServ aware credit-windowing scheme for destination-specific and 16 shared flow control. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 15, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 55 3. Extension Usage and Identification . . . . . . . . . . . . . 5 56 4. Data Plane Considerations . . . . . . . . . . . . . . . . . . 5 57 5. Extension Messages . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Credit Control Message . . . . . . . . . . . . . . . . . 5 59 5.2. Credit Control Response Message . . . . . . . . . . . . . 6 60 6. Extension Data Items . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Credit Window Initialization . . . . . . . . . . . . . . 7 62 6.2. Credit Window Traffic Classification . . . . . . . . . . 9 63 6.2.1. Traffic Classification Sub Data Item . . . . . . . . 11 64 6.2.2. DiffServ Traffic Classification Sub Data Item . . . . 12 65 6.3. Credit Window Associate . . . . . . . . . . . . . . . . . 13 66 6.4. Credit Window Credit Grant . . . . . . . . . . . . . . . 14 67 6.5. Credit Window Status . . . . . . . . . . . . . . . . . . 16 68 6.6. Credit Window Request . . . . . . . . . . . . . . . . . . 17 69 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 72 9.1. Extension Type Value . . . . . . . . . . . . . . . . . . 19 73 9.2. Message Values . . . . . . . . . . . . . . . . . . . . . 19 74 9.3. Data Item Values . . . . . . . . . . . . . . . . . . . . 19 75 9.4. DLEP Sub Data Item Registry . . . . . . . . . . . . . . . 20 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 78 10.2. Informative References . . . . . . . . . . . . . . . . . 21 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 80 Appendix B. Open and Resolved Issues . . . . . . . . . . . . . . 22 81 B.1. Merge with [I-D.ietf-manet-credit-window] . . . . . . . . 22 82 B.2. Supporting Router Limits . . . . . . . . . . . . . . . . 22 83 B.3. Absolute vs Increment . . . . . . . . . . . . . . . . . . 23 84 B.4. Bidirectional Flow 85 Control (closed) . . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 88 1. Introduction 90 The Dynamic Link Event Protocol (DLEP) is defined in [RFC8175]. It 91 provides the exchange of link related control information between 92 DLEP peers. DLEP peers are comprised of a modem and a router. DLEP 93 defines a base set of mechanisms as well as support for possible 94 extensions. This document defines one such extension. 96 The base DLEP specification does not include any flow control 97 capability. There are various flow control theoretically possible 98 with DLEP. For example, a credit-windowing scheme for destination- 99 specific flow control which provides aggregate flow control for both 100 modem and routers has been proposed in 101 [I-D.ietf-manet-credit-window]. 103 This document defines a DLEP extension which provides an alternate 104 flow control mechanism for traffic sent from a router to a modem. 105 Flow control is provide using one or more logical "Credit Windows", 106 each of which will typically be supported by an associated virtual or 107 physical queue. Traffic sent by a router will use traffic 108 classification information provided by the modem to identify which 109 traffic is associated with each credit window. (For general 110 background on traffic classification see [RFC2475] Section 2.3.) 111 This document supports traffic classification based on DLEP 112 destination and DiffServ [RFC2475] DSCPs (differentiated services 113 codepoints). Credit windows may be shared or dedicated on a per 114 {destination, DSCP} tuple basis. Said another way, the defined 115 mechanism allows for credit windows to be shared across traffic sent 116 to multiple DLEP destinations and DSCPs, or used exclusively for 117 traffic sent to a particular destination and/or DSCP. The extension 118 also supports the "wildcard" matching of any DSCP. 120 The extension defined in this document is referred to as "DiffServ 121 Aware Credit Windowing" or, more simply, the "DA Credit" extension. 122 The extension is structured to allow for reuse of the defined credit 123 window based flow control with traffic classification techniques 124 other than DiffServ, e.g., IEEE 802.1 Q priority code points or even 125 5-tuple IP flows. 127 This document defines a new DLEP Extension Type Value in Section 3 128 which is used to indicate the use of the extension. Two new messages 129 are defined in Section 5, and six new DLEP Data Items in Section 6. 131 1.1. Key Words 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2. Extension Overview 141 The DA Credit extension can be used to support credit based flow 142 control of traffic sent from a router to a modem. The extension can 143 be used to support DiffServ and non-DiffServ based flow control. 144 Both types of DLEP endpoints, i.e., a router and a modem, negotiate 145 the use of extension during session initialization, see Section 5.2 147 [RFC8175]. When using this extension, data traffic is allowed to be 148 sent by the router to the modem only when there are credits 149 available. 151 Credits are managed on a per logical "Credit Windows" basis. Each 152 credit window can be thought of as corresponding to a queue within a 153 modem. Modems pass to the router information on its credit windows 154 and identify each via a "Credit Window Identifier", or "CID". In 155 addition to the CID, credit window information includes an initial 156 credit window size, as well as the maximum size of the logical queue 157 associated with each CID. The maximum size is included for 158 informative and, potential, future uses. 160 As mentioned above, traffic classification supported by this document 161 is performed on a per {destination, DSCP} tuple basis. This means 162 that, routers need the combination of the DLEP identified destination 163 and DSCP associated with a CID in order to match traffic it sends to 164 specific credit windows. Modems provide the mapping of DSCPs to CIDs 165 in sets, each of which is identified via a "Traffic Classification 166 Identifier" or "TID". When a destination becomes reachable, a modem 167 "Associates" (identifies) the TID to be used for traffic sent by the 168 router to that destination. This use of CIDs, TIDs and association 169 of a TID to a DLEP destination enables modem to share or dedicate 170 resources as needed to match the specifics of its implementation and 171 its attached transmission technology. 173 Modems provide an initial credit window size at the time of "Credit 174 Window Initialization". Such initialization can take place during 175 session initiation or any point thereafter. It can also take place 176 when rate information changes. Additional "Credit Grants", i.e., 177 increments to Credit Window size, are provided using a Destination Up 178 or the new "Credit Control" Message. A router provides its view of 179 the Credit Window, which is known as "Status", in Destination Up 180 Response and the new "Credit Control Response" Messages. Routers can 181 also request credits using the new "Credit Control" Message. 183 When modems provide credits to a router, they will need to take into 184 account any overhead of their attached transmission technology and 185 map it into the credit semantics defined in this document. In 186 particular, the credit window is defined below to include per frame 187 (packet) MAC headers and this may not match the actual overhead of 188 the modem attached transmission technology. In that case a direct 189 mapping or an approximation will need to be made by the modem to 190 provide appropriate credit values. 192 3. Extension Usage and Identification 194 The use of the extension defined in this document SHOULD be 195 configurable. To indicate that the DiffServ Aware Credit Windowing 196 Extension is to be used, an implementation MUST include the DiffServ 197 Aware Credit Windowing Type Value in the Extensions Supported Data 198 Item. The Extensions Supported Data Item is sent and processed 199 according to [RFC8175]. 201 The DiffServ Aware Credit Windowing Extension Type Value is TBA1, see 202 Section 9. 204 4. Data Plane Considerations 206 When the use of the extension defined in this document is agreed upon 207 per standard DLEP processing, see Section 3, a router MUST NOT send 208 data traffic to a modem for forwarding when there are no credits 209 available in the associated Credit Window. This document defines 210 credit windows in octets. A credit window value MUST be larger than 211 the number of octets contained in a packet, including any MAC headers 212 used between the router and the modem, in order for the router to 213 send the packet to a modem for forwarding. The credit window is 214 decremented by the number of sent octets. 216 A router MUST identify the credit window associated with traffic sent 217 to a modem based on the traffic classification information provided 218 in the data items defined in this document. The definitions support 219 identification based on DLEP destination and, at the modem's 220 discretion, DSCPs. Note that routers will typically view a DLEP 221 destination as the next hop. 223 5. Extension Messages 225 Two new messages are defined by this extension: the Credit Control 226 and the Credit Control Response Message. Sending and receiving both 227 message types MUST be supported by any implementation that advertises 228 use of this extension per Section 3. 230 5.1. Credit Control Message 232 Credit Control Messages are sent by modems and routers. Each sender 233 is only permitted to have one message outstanding at one time. That 234 is, a sender (modem or router) MUST NOT send a second (or any 235 subsequent) Credit Control Message until a Credit Control Response 236 Message is received from its peer (router or modem). 238 Credit Control Messages are sent by modems to provide credit window 239 increases. Modems send credit increases when there is transmission 240 or local queue availability that exceeds the credit window value 241 previous provided to the router. Modems will need to balance the 242 load generated by sending and processing frequent credit window 243 increases against a router having data traffic available to send, but 244 no credits available. 246 Credit Control Messages MAY be sent by routers to request credits and 247 provide window status. Routers will need to balance the load 248 generated by sending and processing frequent credit window requests 249 against a having data traffic available to send, but no credits 250 available. 252 The Message Type value in the DLEP Message Header is set to TBA2. 254 A message sent by a modem, MUST contain one or more Credit Window 255 Grant Data Items as defined below in Section 6.4. A router receiving 256 this message MUST respond with a Credit Control Response Message. 258 A message sent by a router, MUST contain one or more Credit Window 259 Request Data Items defined below in Section 6.6 and SHOULD contain a 260 Credit Window Status Data Item, defined in Section 6.5, corresponding 261 to each credit window request. A modem receiving this message MUST 262 respond with a Credit Control Response Message based on the received 263 message and data item and the processing defined below, which will 264 typically result in credit window increments being provided. 266 Specific processing associated with each Credit Data Item is provided 267 below. 269 5.2. Credit Control Response Message 271 Credit Control Response Messages are sent by routers to report the 272 current Credit Window for a destination. A message sent by a router, 273 MUST contain one or more Credit Window Status Data Items as defined 274 below in Section 6.5. Specific receive processing associated with 275 the Credit Window Window Status Data Item is provided below. 277 Credit Control Response Messages sent by modems MUST contain one or 278 more Credit Window Credit Grant Data Items. A data item for every 279 Credit Window Request data item contained in the for Credit Control 280 Response Message sent by the router MUST be included. Each Grant 281 Data Item MAY provide zero or more additional credits based on a the 282 modem;s transmission or local queue availability. Specific receive 283 processing associated with each Grant Data Item is provided below. 285 The Message Type value in the DLEP Message Header is set to TBA3. 287 6. Extension Data Items 289 Six data items are defined by this extension. The Credit Window 290 Initialization Data Item is used by a modem to identify a credit 291 window and set its size. The Credit Window Traffic Classification 292 Data Item is used by a modem to identify a set which identifies which 293 DSCPs are mapped to a credit window. The Credit Window Association 294 Data Item is used by a modem to identify which traffic classification 295 set should be used when sending traffic to a particular DLEP 296 identified destination. The Credit Window Grant is used by a modem 297 to provide additional credits to a router. The Credit Request is 298 used by a router to request additional credits. The Credit Window 299 Status is used to advertise the sender's view of number of available 300 credits for state synchronization purposes. 302 Any errors or inconsistencies encountered in parsing data items are 303 handled in the same fashion as any other data dtem parsing error 304 encountered in DLEP, see [RFC8175]. In particular, the node parsing 305 the data item MUST terminate the session with a Status Data Item 306 indicating Invalid Data. 308 The defined data items and operations have similar objectives as 309 those found in [I-D.ietf-manet-credit-window]. One notable 310 difference from this extension is that in this document credits are 311 never provided by the router to the modem. 313 6.1. Credit Window Initialization 315 The Credit Window Initialization Data Item is used by a modem to 316 identify a credit window and set its size. This Data Item SHOULD be 317 included in any Session Initialization Response Message that also 318 contains the DiffServ Aware Credit Windowing Extension Type Value in 319 the Extensions Supported Data Item. Updates to previously identified 320 credit windows or new credit windows MAY be sent by a modem by 321 including the data item in Session Update Messages. More than one 322 data item MAY be included in a message to provide information on 323 multiple credit windows. 325 The Credit Window Initialization Data Item identifies a credit window 326 using a Credit Window Identifier, or CID. It also provides the size 327 of the identified credit window. Finally, a queue size (in bytes) is 328 provided for informational purposes. Note that to be used, a CID 329 must be listed in a Credit Window Traffic Classification Data Item. 331 The format of the Credit Window Initialization Data Item is: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Data Item Type | Length (16) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Credit Window Identifier (CID)| Reserved | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Credit Value : 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 : Credit Value | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Scale | Credit Window Size | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Data Item Type: TBA4 349 Length: 16 351 Per [RFC8175] Length is the number of octets in the data item, 352 excluding the Type and Length fields. 354 Credit Window Identifier (CID): 356 A 16-bit unsigned integer identifying a credit window. The value 357 of 0xFFFFFFFF is reserved and MUST not be used in this data item. 358 There is no other restriction on values used by a modem, and there 359 is no requirement for sequential or ordered values. 361 Reserved: 363 MUST be set to zero by the sender (a modem) and ignored by the 364 receiver (a router). 366 Credit Value: 368 A 64-bit unsigned integer representing the credits, in octets, to 369 be applied to the Credit Window. This value includes MAC headers 370 as seen on the link between the modem and router. 372 Scale: 374 An 8-bit unsigned integer indicating the scale used in the Credit 375 Window Size fields. The valid values are: 377 Value Scale 378 ------------ 379 0 B - Bytes (Octets) 380 1 KB - Kilobytes (B/1024) 381 2 MB - Megabytes (KB/1024) 382 3 GB - Gigabytes (MB/1024) 384 Credit Window Size: 386 A 24-bit unsigned integer representing the maximum size, in the 387 octet scale indicated by the Scale field, of the associated credit 388 window. 390 A router that receives a Credit Window Initialization Data Item MUST 391 locate the credit window that is associated with the CID indicated in 392 each received data item. If no associated credit window is found, 393 the router MUST initialize a new credit window using the values 394 carried in the data item. When an associated credit window is found, 395 the router MUST update the credit window using the values carried in 396 the Data Item. It is worth noting, that such updates can result in a 397 credit window size being reduced, for example, due to a transmission 398 rate change on the modem. 400 6.2. Credit Window Traffic Classification 402 The Credit Window Traffic Classification Data Item is used by a modem 403 to provide information to enable router to identify the credit window 404 associated with traffic the router sends. Each data item includes a 405 set of credit windows and provides traffic classification for each 406 window. The data item is defined to support classification based on 407 DSCPs, but is designed to be extensible for future traffic 408 classification types. The data item is not required to provide full 409 traffic classification information. In the context of the definition 410 included in this document, the DLEP destination address needed to 411 complete the traffic classification information is provided by a 412 modem when it identifies the traffic classification set in a 413 Destination Up Message using the Credit Window Associate Data Item 414 defined below. 416 The Credit Window Traffic Classification Data Item SHOULD be included 417 by a modem in any Session Initialization Response Message that also 418 contains the DiffServ Aware Credit Windowing Extension Type Value in 419 the Extensions Supported Data Item. Updates to previously provided 420 traffic classifications or new traffic classifications MAY be sent by 421 a modem by including the data item in Session Update Messages. More 422 than one data item MAY be included in a message to provide 423 information on multiple traffic classifiers. 425 The set of traffic classification information provided in the data 426 item is identified using a Traffic Classification Identifier, or TID. 427 Addition information, e.g., the list DSCPs associated with a credit 428 window, is provided in a variable series of Queue Parameter sub-data 429 items. Note that to be used, a TID must be listed in a Credit Window 430 Associate Data Item. 432 The format of the Credit Window Traffic Classification Data Item is: 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Data Item Type | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |Traffic Class. Identifier (TID)| Num SDIs | Reserved | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Traffic Classification Sub Data Item 1 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 : ... : 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Traffic Classification Sub Data Item n | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Data Item Type: TBA5 450 Length: Variable 452 Per [RFC8175] Length is the number of octets in the data item, 453 excluding the Type and Length fields. 455 Traffic Classification Identifier (TID): 457 A 16-bit unsigned integer identifying a traffic classification 458 set. There is no restriction on values used by a modem, and there 459 is no requirement for sequential or ordered values. 461 Num SDIs: 463 An 8-bit unsigned integer indicating the number of Traffic 464 Classification Sub Data Items included in the data item. A value 465 of zero (0) is allowed and indicates that no traffic should be 466 matched against this TID. 468 Reserved: 470 MUST be set to zero by the sender (a modem) and ignored by the 471 receiver (a router). 473 Traffic Classification Sub Data Item: 475 Zero or more Traffic Classification Sub Data Items of the format 476 defined below MAY be included. The number MUST match the value 477 carried in the Num SDIs field. 479 A router receiving the Traffic Classification Data Item MUST locate 480 the traffic classification information that is associated with the 481 TID indicated in each received data item. If no associated traffic 482 classification information is found, the router MUST initialize a new 483 information set using the values carried in the data item. When 484 associated traffic classification information is found, the router 485 MUST update the information using the values carried in the Data 486 Item. In both cases, a router MUST also ensure that any data plane 487 state, see Section 4, that is associated with the TID is updated as 488 needed. 490 6.2.1. Traffic Classification Sub Data Item 492 All Traffic Classification Sub Data Items share a common format that 493 is patterned after the standard DLEP data item format, see [RFC8175] 494 Section 11.3. There is no requirement on, or meaning to sub data 495 item ordering. Any errors or inconsistencies encountered in parsing 496 sub data items are handled in the same fashion as any other data item 497 parsing error encountered in DLEP. 499 The format of the Traffic Classification Sub Data Item is: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Sub Data Item Type | Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Value... : 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Sub Data Item Type: 511 A 16-bit unsigned integer that indicates the type and 512 corresponding format of the data item's Value field. Sub Data 513 Item Types are managed according to the IANA registry described in 514 Section 9.4. 516 Length: Variable 518 Copying [RFC8175], Length a 16-bit unsigned integer that is the 519 number of octets in the sub data item, excluding the Type and 520 Length fields. 522 6.2.2. DiffServ Traffic Classification Sub Data Item 524 The DiffServ Traffic Classification Sub Data Item is used to identify 525 the DSCPs associated with a specific credit window. Credit windows 526 are identified using CID values that have been previously been sent 527 by the modem or are listed in a Credit Window Initialization Data 528 Item carried in the same messages as the sub data item. DSCPs are 529 identified in a list of DiffServ fields. An implementation that does 530 not support DSCPs, and wants to use credit window flow control for 531 all traffic to a destination or destinations, would indicate with 0 532 DSCPs. 534 The format of the DiffServ Traffic Classification Sub Data Item is: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Must be two (2) | Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Credit Window Identifier (CID)| Num DSCPs | DS Field 1 | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | DS Field 2 | ... | DS Field n | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Length: Variable 548 Length is the number of octets in the sub data item. It is equal 549 to seven (7) plus the value of the Num DSCPs field. 551 Credit Window Identifier (CID): 553 A 16-bit unsigned integer identifying a credit window that has 554 been identified in a Credit Window Initialization Data Item, see 555 Section 6.1. Unknown CID values SHOULD be reported and result in 556 associated traffic being dropped. 558 Num DSCPs: 560 An 8-bit unsigned integer indicating the number of DSCPs carried 561 in the sub data item. A zero (0) indicates a (wildcard) match 562 against any DSCP value. 564 DS Field: 566 Each DS Field is an 8-bit whose definition is the same as 567 [RFC2474]. 569 0 1 2 3 4 5 6 7 570 +---+---+---+---+---+---+---+---+ 571 | DSCP | CU | 572 +---+---+---+---+---+---+---+---+ 574 DSCP: differentiated services codepoint 575 CU: currently unused, MUST be zero 577 A router receiving the DiffServ Traffic Classification Sub Data Item 578 MUST validate the information on receipt prior to the information and 579 data plan update described earlier in this section. The credit 580 window associated with the CID indicated in each data item must be 581 located. It is important to note that the CID value may be present 582 in a Credit Window Initialization Data Item carried in the same 583 message as the sub data item. If the CID is not located, the it MUST 584 be treated as an error as described above. 586 In the case there are no unknown CIDs, the receiver MUST ensure that 587 each DS Field value is listed only once across the whole Credit 588 Window Traffic Classification Data Item. Note, this check is across 589 the data item and not the individual sub data item. If the same DS 590 Field value is listed more than once within the same Credit Window 591 Traffic Classification Data Item, the data item MUST be treated as an 592 error as described above. 594 6.3. Credit Window Associate 596 The Credit Window Associate Data Item is used by a modem to associate 597 traffic classification information with a destination. The traffic 598 classification information is identified using a TID value that has 599 been previously been sent by the modem or is listed in a Credit 600 Window Traffic Classification Data Item carried in the same message 601 as the data item. 603 A single Credit Window Associate Data Item MUST be included in all 604 Destination Up and Destination Update Messages sent by a modem when 605 the use of the extension defined in this document is agreed upon, see 606 Section 3. 608 The format of the Credit Window Associate Data Item is: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Data Item Type | Length (2) | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |Traffic Class. Identifier (TID)| 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Data Item Type: TBA6 620 Length: 2 622 Per [RFC8175] Length is the number of octets in the data item, 623 excluding the Type and Length fields. 625 Traffic Classification Identifier (TID): 627 A 16-bit unsigned integer identifying a traffic classification set 628 that has been identified in a Credit Window Traffic Classification 629 Data Item, see Section 6.2. Unknown TID values SHOULD be reported 630 and result in associated traffic being dropped. 632 A router that receives the Credit Window Associate Data Item MUST 633 locate the traffic classification information indicated by the 634 received TID. If no corresponding information can be located, the 635 data item MUST be treated as an error as described above. Once the 636 traffic classification information is located, it MUST be associated 637 with the destination and the router MUST ensure that any data plane 638 state, see Section 4, that is associated with the TID is updated as 639 needed. 641 6.4. Credit Window Credit Grant 643 The Credit Window Credit Grant data item is used by a modem to 644 provide credits to a router. One or more Credit Window Grant Data 645 Items MAY be carried in the DLEP Destination Up, Destination Announce 646 Response, Destination Update, Credit Control Messages, and Credit 647 Control Response Messages. Multiple Credit Window Grant Data Items 648 in a single message are used to indicate different credit values for 649 different credit windows. In all message types, this data item 650 provides an additional number of octets to be added to the indicated 651 credit window. Credit window are identified via using using CID 652 values that have been previously been sent by the modem or are listed 653 in a Credit Window Initialization Data Item carried in the same 654 messages as the data item. 656 The format of the Credit Window Grant Data Item is: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Data Item Type | Length (12) | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Credit Window Identifier (CID)| Reserved | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Additional Credits : 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 : Additional Credits | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Data Item Type: TBA7 672 Length: 12 674 Per [RFC8175], Length is the number of octets in the data item, 675 excluding the Type and Length fields. It will equal 8 plus the 676 number of CID fields carried in the data item and MUST be at least 677 9. 679 Credit Window Identifier (CID): 681 A 16-bit unsigned integer identifying a credit window that has 682 been identified in a Credit Window Initialization Data Item, see 683 Section 6.1. Unknown CID values SHOULD be reported and ignored. 685 Additional Credit: 687 A 64-bit unsigned integer representing the credits, in octets, to 688 be added to the Credit Window. This value includes MAC headers as 689 seen on the link between the modem and router. A value of zero 690 indicates that no additional credits are being provided. 692 When receiving this data item, a router MUST identify the credit 693 window indicated by the CID. If the CID is not known to the router, 694 it SHOULD report or log this information and discard the Data Item. 695 It is important to note that while this data item can be received in 696 a destination specific message, credit windows are managed 697 independently from the destination identified in the message carrying 698 this Data Item, and the indicated CID MAY even be disjoint from the 699 identified destination. 701 Once the credit window is identified, the credit window size MUST be 702 increased by the value contained in the Additional Credits field. If 703 the increase results in a window overflow, i.e., the size of the 704 credit window after the increase is smaller than the original credit 705 window size, the Credit Window must be set to its maximum 706 (0xFFFFFFFFFFFFFFFF). 708 No response is sent by the router to a modem after processing a 709 Credit Window Grant Data Item received in a Credit Control Response 710 Message. In other cases, the receiving router MUST send a Credit 711 Window Status data item or items reflecting the resulting Credit 712 Window value of the updated credit window. When the Credit Grant 713 data item is received in a Destination Up Message, the Credit Window 714 Status data item(s) MUST be sent in the corresponding Destination Up 715 Response Message. Otherwise, a Credit Control Message MUST be sent. 717 6.5. Credit Window Status 719 The Credit Window Status data item is used by a router to report the 720 current credit window size to its peer modem. One or more Credit 721 Window Status data items MAY be carried in a Destination Up Response 722 Message or a Credit Control Response Message. As discussed above, 723 the Destination Up Response Message is used when the data item is 724 sent in response to a Destination Up Message, and the Credit Control 725 Response Message is sent in response to a Credit Control Message. 726 Multiple Credit Window Status data items in a single message are used 727 to indicated different sizes of different credit windows. Similar to 728 the Credit Window Grant, credit windows are identified using CID 729 values that have been previously been sent by the modem. 731 The format of the Credit Window Status Data Item is: 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Data Item Type | Length (12) | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Credit Window Identifier (CID)| Reserved | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Credit Window Size : 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 : Credit Window Size | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Data Item Type: TBA8 747 Length: 12 749 Per [RFC8175] Length is the number of octets in the data item, 750 excluding the Type and Length fields. It will equal 8 plus the 751 number of CID fields carried in the data item and MUST be at least 752 9. 754 Credit Window Identifier (CID): 756 A 16-bit unsigned integer identifying a credit window that has 757 been identified in a Credit Window Initialization Data Item, see 758 Section 6.1. 760 Credit Window Size: 762 A 64-bit unsigned integer, indicating the current number of 763 credits, in octets, available for the router to send to the modem. 764 This is referred to as the Modem Receive Window in 765 [I-D.ietf-manet-credit-window]. 767 When receiving this data item, a modem MUST identify the credit 768 window indicated by the CID. If the CID is not known to the modem, 769 it SHOULD report or log this information and discard the data item. 770 As with the Credit Window Grant Data Item, the CID MAY be unrelated 771 to the Destination indicated in the message carrying the data item. 773 Once the credit window is identified, the modem SHOULD check the 774 received Credit Window Size field value against the outstanding 775 credit window's available credits at the time the most Credit Window 776 Initialization or Grant data item associated with the indicated CID 777 was sent. If the values significantly differ, i.e., greater than can 778 be accounted for based on observed data frames, then the modem SHOULD 779 send a Credit Window Initialization Data Item to reset the associated 780 credit window size to the modem's current view of the available 781 credits. As defined above, Credit Window Initialization Data Items 782 are sent in Session Update Messages. When multiple data items need 783 to be sent, they SHOULD be combined into a single message when 784 possible. Alternatively, and also in cases where there are small 785 differences, the modem MAY adjust the values sent in Credit Window 786 Grant data items to account for the reported Credit Window. 788 6.6. Credit Window Request 790 The Credit Window Request Data Item is used by a router to request 791 additional credits for particular credit windows. Credit Window 792 Request Data Items are carried in Credit Control Messages, and one or 793 more Credit Window Request Data Items MAY be present in a message. 795 Credit windows identified using a CID as defined above in 796 Section 6.1. Multiple CIDs MAY be present to allow for the case 797 where the router identifies that credits are needed in multiple 798 credit windows. The special CID value of 0xFFFFFFFF is used to 799 indicate that a credit request is being made across all queues. 801 The format of the Credit Window Request Data Item is: 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Data Item Type | Length | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Credit Window Identifier (CID)| ... : 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 : ... | Credit Window Identifier (CID)| 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 [LB note: a list of CIDs is now supported as is special value 255.] 815 Data Item Type: TBA9 817 Length: Variable 819 Per [RFC8175] Length is the number of octets in the data item, 820 excluding the Type and Length fields. It will equal the number of 821 CID fields carried in the data item and MUST be at least 1. 823 Credit Window Identifier (CID): 825 One or more 16-bit fields used to indicate a credit window that 826 has been identified in a Credit Window Initialization Data Item, 827 see Section 6.1. The special value of 0xFFFFFFFF indicates that 828 the request applies to all CIDs. 830 A modem receiving this data item MUST provide a Credit Increment for 831 the indicated credit windows via Credit Window Grant Data Items 832 carried in a new Credit Control Message. Multiple values and queue 833 indexes SHOULD be combined into a single Credit Control Message when 834 possible. Unknown CID values SHOULD be reported or logged and then 835 ignored by the modem. 837 7. Compatibility 839 Sessions established with both peers identified as supporting the 840 DiffServ Aware Credit Windowing Extension Type, see Section 3, MUST 841 NOT use the [I-D.ietf-manet-credit-window] defined Credit data items. 842 If a node supporting the extension defined in this document, receives 843 a [I-D.ietf-manet-credit-window] defined data item, the recipient 844 MUST ignore the received information. 846 8. Security Considerations 848 The extension introduces a DiffServ awareness to the mechanisms 849 defined in [I-D.ietf-manet-credit-window]. The extension does not 850 inherently introduce any additional threats above those documented in 852 [RFC8175]. The approach taken to Security in that document and 853 [I-D.ietf-manet-credit-window] apply equally when running the 854 extension defined in this document. 856 9. IANA Considerations 858 This document requests the assignment of 5 values by IANA. All 859 assignments are to registries defined by [RFC8175]. 861 9.1. Extension Type Value 863 This document requests 1 new assignment to the DLEP Extensions 864 Registry named "Extension Type Values" in the range with the 865 "Specification Required" policy. The requested value is as follows: 867 +------+---------------------------------+ 868 | Code | Description | 869 +------+---------------------------------+ 870 | TBA1 | DiffServ Aware Credit Windowing | 871 +------+---------------------------------+ 873 Table 1: Requested Extension Type Value 875 9.2. Message Values 877 This document requests 2 new assignments to the DLEP Message Registry 878 named "Message Values" in the range with the "Specification Required" 879 policy. The requested values are as follows: 881 +-----------+-------------------------+ 882 | Type Code | Description | 883 +-----------+-------------------------+ 884 | TBA2 | Credit Control | 885 | | | 886 | TBA3 | Credit Control Response | 887 +-----------+-------------------------+ 889 Table 2: Requested Message Values 891 9.3. Data Item Values 893 This document requests the following new assignments to the DLEP Data 894 Item Registry named "Data Item Values" in the range with the 895 "Specification Required" policy. The requested values are as 896 follows: 898 +-----------+--------------------------------------+ 899 | Type Code | Description | 900 +-----------+--------------------------------------+ 901 | TBA4 | Credit Window Initialization | 902 | | | 903 | TBA5 | Credit Window Traffic Classification | 904 | | | 905 | TBA6 | Credit Window Association | 906 | | | 907 | TBA7 | Credit Window Grant | 908 | | | 909 | TBA8 | Credit Window Status | 910 | | | 911 | TBA9 | Credit Window Request | 912 +-----------+--------------------------------------+ 914 Table 3: Requested Data Item Values 916 9.4. DLEP Sub Data Item Registry 918 Upon approval of this document, IANA is requested to create a new 919 DLEP registry, named "Sub Data Item Type Values". The registry shall 920 identify the type code value, the Data Item which may use the value, 921 and a description of the value. While the same value may be reused 922 in different data items, this is not recommended at this time. 924 The following table provides initial registry values and the 925 [RFC8126] defined policies that should apply to the registry: 927 +-------------+-----------------------------+-----------------------+ 928 | Type Code | Valid Data Items | Description | 929 +-------------+-----------------------------+-----------------------+ 930 | 0 | N/A | Reserved | 931 | | | | 932 | 1 | N/A | Reserved (for pause | 933 | | | sub-DI) | 934 | | | | 935 | 2 | (TBD4) Credit Window | DiffServ Traffic | 936 | | Traffic Classification | Classification | 937 | | | | 938 | 2-65407 | | Specification | 939 | | | Required | 940 | | | | 941 | 65408-65534 | | Private Use | 942 | | | | 943 | 65535 | | Reserved | 944 +-------------+-----------------------------+-----------------------+ 946 Table 4: Initial Registry Values 948 10. References 950 10.1. Normative References 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, 954 DOI 10.17487/RFC2119, March 1997, 955 . 957 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 958 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 959 May 2017, . 961 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 962 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 963 DOI 10.17487/RFC8175, June 2017, 964 . 966 10.2. Informative References 968 [I-D.ietf-manet-credit-window] 969 Ratliff, S., "Credit Windowing extension for DLEP", draft- 970 ietf-manet-credit-window-07 (work in progress), November 971 2016. 973 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 974 "Definition of the Differentiated Services Field (DS 975 Field) in the IPv4 and IPv6 Headers", RFC 2474, 976 DOI 10.17487/RFC2474, December 1998, 977 . 979 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 980 and W. Weiss, "An Architecture for Differentiated 981 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 982 . 984 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 985 Writing an IANA Considerations Section in RFCs", BCP 26, 986 RFC 8126, DOI 10.17487/RFC8126, June 2017, 987 . 989 Appendix A. Acknowledgments 991 The sub data item format was inspired by Rick Taylor's "Data Item 992 Containers". He also proposed the separation of credit windows from 993 traffic classification at IETF98. 995 Appendix B. Open and Resolved Issues 997 This section captures issues that are open or have been addressed 998 since the document has become a WG draft. This section will be 999 removed before submission for publication. 1001 B.1. Merge with [I-D.ietf-manet-credit-window] 1003 There has been discussion within the WG that this document should be 1004 merged with [I-D.ietf-manet-credit-window]. The timing of this is 1005 TBD. The authors would like to reach closure on some of the 1006 remaining open issues before embarking on this merge, but are open to 1007 discussion with the WG and other authors. 1009 B.2. Supporting Router Limits 1011 Routers may have limits on the number of queues that they can support 1012 and, perhaps, if per destination queues can even be supported at all. 1013 There is no current way for a router to communicate these limits to a 1014 modem or for a router to indicate that the identified queue 1015 information cannot be supported. Support for these cases clearly 1016 needs to be addressed. 1018 This issue was reported by Stan Ratliff . 1020 B.3. Absolute vs Increment 1022 Stan Ratliff suggested an approach to 1023 simplify credit synchronization and re-synchronization by always 1024 passing the credit window size rather than credit window increments. 1025 This is an interesting idea that needs to be explored and perhaps 1026 experimented with. 1028 B.4. Bidirectional Flow Control (closed) 1030 One of the key differences between this draft and 1031 [I-D.ietf-manet-credit-window] is that this document only supports 1032 flow control in one direction, i.e., for traffic sent from a router 1033 to a modem, while the other credit-window draft supports it in both 1034 directions. 1036 This was a conscious choice, made out of the desire to keep the 1037 extension as simple as possible and to provide what is really 1038 expected to be used. Clearly the reason for being able to control 1039 traffic that is sent from the router to the modem/radio is pretty 1040 easily understood. Also, while bidirectional flow control existed in 1041 pre-dlep solutions, it wasn't really used. There is also no reason 1042 why router to modem flow control can't be defined at a later time - 1043 once there is an actual need. 1045 Based on a brief discussion on the WG list, and the absence of any 1046 advocates for bidirectional flow control, there is no current plan to 1047 add bidirectional flow control to this document. 1049 Authors' Addresses 1051 Bow-Nan Cheng 1052 Lincoln Laboratory 1053 Massachusetts Institute of Technology 1054 244 Wood Street 1055 Lexington, MA 02421-6426 1057 Email: bcheng@ll.mit.edu 1059 David Wiggins 1060 Lincoln Laboratory 1061 Massachusetts Institute of Technology 1062 244 Wood Street 1063 Lexington, MA 02421-6426 1065 Email: David.Wiggins@ll.mit.edu 1066 Lou Berger 1067 LabN Consulting, L.L.C. 1069 Email: lberger@labn.net