idnits 2.17.1 draft-ietf-manet-dlep-pause-extension-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 (October 30, 2017) is 2341 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 (~~), 1 warning (==), 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 3, 2018 L. Berger, Ed. 6 LabN Consulting, L.L.C. 7 October 30, 2017 9 DLEP Control Plane Based Pause Extension 10 draft-ietf-manet-dlep-pause-extension-02 12 Abstract 14 This document defines an extension to the DLEP protocol that enables 15 a modem to use DLEP messages to pause and resume data traffic coming 16 from its peer router. 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 3, 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 Usage and Identification . . . . . . . . . . . . . 3 55 3. Extension Data Items . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Queue Parameters . . . . . . . . . . . . . . . . . . . . 3 57 3.1.1. Queue Parameter Sub Data Item . . . . . . . . . . . . 5 58 3.2. Pause . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Restart . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 5.1. Extension Type Value . . . . . . . . . . . . . . . . . . 9 63 5.2. Data Item Values . . . . . . . . . . . . . . . . . . . . 9 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 6.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The Dynamic Link Event Protocol (DLEP) is defined in [RFC8175]. It 73 provides the exchange of link related control information between 74 DLEP peers. DLEP peers are comprised of a modem and a router. DLEP 75 defines a base set of mechanisms as well as support for possible 76 extensions. This document defines one such extension. 78 The base DLEP specification does not include any data plane flow 79 control capability. Various flow control methods are possible, e.g., 80 see [I-D.ietf-manet-credit-window]. The extension defined in this 81 document supports flow control of data traffic based on explicit 82 messages sent via DLEP by a modem to indicate when a router should 83 hold off sending traffic, and when it should resume. The extension 84 also optionally supports DSCP (differentiated services codepoint) 85 aware, see [RFC2475], flow control. The extension defined in this 86 document is referred to as "Control Plane Based Pause". Note that 87 this mechanism only controls traffic that is to be transmitted on the 88 modem's attached data channel and not to DLEP control messages 89 themselves. 91 This document defines a new DLEP Extension Type Value in Section 2 92 which is used to indicate the use of the extension, and three new 93 DLEP Data Items in Section 3. 95 1.1. Key Words 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Extension Usage and Identification 105 The use of the Control Plane Based Pause Extension SHOULD be 106 configurable. To indicate that the Control Plane Based Pause 107 Extension is to be used, an implementation MUST include the Control 108 Plane Based Pause Extension Type Value in the Extensions Supported 109 Data Item. The Extensions Supported Data Item is sent and processed 110 according to [RFC8175]. 112 The Control Plane Based Pause Extension Type Value is TBA1, see 113 Section 5. 115 3. Extension Data Items 117 Three data items are defined by this extension. The Queue Parameters 118 Data Item is used by a modem to provide information on the DSCPs it 119 uses in forwarding. The Pause Data Item is used by a modem to 120 indicate when a router should cease sending packets and the Restart 121 Data Item is used by a modem to indicate when a router can resume 122 sending packets. 124 3.1. Queue Parameters 126 The Queue Parameters Data Item is used by a modem to indicate DSCP 127 values that may be independently paused. This data item MUST be 128 included in a Session Initialization Response Message that also 129 contains the Control Plane Based Pause Extension Type Value in the 130 Extensions Supported Data Item. Updates to these parameters MAY be 131 sent by a modem by including the data item in Session Update 132 Messages. 134 The Queue Parameters Data Item identifies DSCPs based on groups of 135 logical queues, each of which is referred to via a "Queue Index". 136 The number of logical queues, or queue indexes, is variable as is the 137 number of DSCPs associated with each queue. A queue size (in bytes) 138 is provided for informational purposes. Queue Indexes are numbered 139 sequentially from zero, where queue index zero is a special case 140 covering DSCPs which are not otherwise associated with Queue Index. 142 An implementation that does not support DSCPs would indicate 1 queue 143 with 0 DSCPs, and the number of bytes that may be in its associated 144 link transmit queue. Additional logical queues are represented in a 145 variable series of Queue Parameter sub-data items. 147 The format of the Queue Parameters Data Item is: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Data Item Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Num Queues | Scale | Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Reserved | Queue Size Q0 | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Queue Parameter Sub Data Item 1 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 : ... : 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Queue Parameter Sub Data Item n | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Data Item Type: TBA2 167 Length: Variable 169 Per [RFC8175] Length is the number of octets in the data item, 170 excluding the Type and Length fields. 172 Num Queues: 174 An 8-bit unsigned integer indicating the number of queues 175 represented in the data item. This field MUST contain a value of 176 at least one (1), and is equal to one greater than the number of 177 included Queue Parameter Sub Data Items. 179 Scale: 181 An 4-bit unsigned integer indicating the scale used in the Queue 182 Size fields. The valid values are: 184 Value Scale 185 ------------ 186 0 B - Bytes (Octets) 187 1 KB - Kilobytes (B/1024) 188 2 MB - Megabytes (KB/1024) 189 3 GB - Gigabytes (MB/1024) 191 Reserved: 193 MUST be set to zero by the sender (a modem) and ignored by the 194 receiver (a router). 196 Queue Size Q0: 198 A 24-bit unsigned integer representing the size, in the octet 199 scale indicated by the Scale field, of queue index zero. 201 3.1.1. Queue Parameter Sub Data Item 203 Queue Parameter Sub Data Items are an ordered list composed of sub 204 data items with a common format. The first sub data item is assigned 205 a Queue Index value of 1, and subsequent data items are numbered 206 incrementally. The format of the Queue Parameter Sub Data Item is 207 patterned after the standard DLEP data item format, see [RFC8175] 208 Section 11.3. Any errors or inconsistencies encountered in parsing 209 Sub Data Items are handled in the same fashion as any other Data Item 210 parsing error encountered in DLEP. 212 The format of the Queue Parameter Sub Data Item is: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Must be one (1) | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Value... : 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 and Value has the format: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Num DSCPs Qn | Queue Size Qn | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | DS Field Qn | DS Field Qn | ... : 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 : ... | DS Field Qn | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Length: Variable 236 Copying [RFC8175], Length is the number of octets in the sub data 237 item, excluding the Type and Length fields. 239 Num DSCPs Qn: 241 An 8-bit unsigned integer indicating the number of DSCPs 242 associated with the queue index associated with the sub data item. 243 This field MUST contain a value of at least one (1). 245 Queue Size Qn: 247 A 24-bit unsigned integer representing the size, in the octet 248 scale indicated by the Scale field, of the queue supporting 249 traffic with the DSCPs associated with the queue index. 251 DS Field Qn: 253 The data item contains a sequence of 8 bit DS Fields. The 254 position in the sequence identifies the associated queue index. 255 The number of DS Fields present should equal the sum of all Num 256 DSCPs field values. 258 The DS Field structure is the same as [RFC2474]. 260 0 1 2 3 4 5 6 7 261 +---+---+---+---+---+---+---+---+ 262 | DSCP | CU | 263 +---+---+---+---+---+---+---+---+ 265 DSCP: differentiated services codepoint 266 CU: currently unused, MUST be zero 268 3.2. Pause 270 The Pause Data Item is used by a modem to indicate to its peer that 271 traffic is to be suppressed. An example of when a modem might send 272 this data item is when an internal queue length exceeds a particular 273 threshold. 275 A modem may indicate that traffic is to be suppressed on a device 276 wide or destination specific basis. An example of when a modem might 277 use device wide indications is when output queues are shared across 278 all destinations, and destination specific might be used when per 279 destination queuing is used. To indicate that suppression applies to 280 all destinations, a modem MAY send the Pause Data Item in a Session 281 Update Message. To indicate that suppression applies to a particular 282 destination a modem MAY send the Pause Data Item in a Destination 283 Update Message. 285 Each Pause Data Item identifies the traffic to be suppressed by the 286 Queue Index defined by Section 3.1, which in turn indicates a set of 287 traffic identified by DSCPs. The special value of 255 is used to 288 indicate that all traffic is to be suppressed. 290 While there is no restriction on the number of Messages containing 291 Pause Data Item that may be sent by a modem, a modem SHOULD include 292 multiple queue indexes in the same message when possible. 294 A router which receives the Pause Data Item MUST cease sending the 295 identified traffic to the modem. This may of course translate into 296 the router's queues exceeding their own thresholds. If a received 297 Pause Data Item contains a Queue Index value other than 0, 255, or a 298 queue index established by a Session Initialization or Session Update 299 Message, the router MUST terminate the session with a Status Data 300 Item indicating Invalid Data. 302 The format of the Pause Data Item is: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Data Item Type | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Queue Index | ... : 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 : ... | Queue Index | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Data Item Type: TBA3 316 Length: Variable 318 Per [RFC8175] Length is the number of octets in the data item, 319 excluding the Type and Length fields. It will equal the number of 320 Queue Index fields carried in the data item. 322 Queue Index: 324 One or more 8-bit fields used to indicate a queue index defined by 325 a Queue Parameters Data Item. The special value of 255 indicates 326 all traffic is to be suppressed to the modem, when the data item 327 is carried in a Session Update Message, or a destination, when the 328 data item is carried in Destination Update Message. 330 3.3. Restart 332 The Restart Data Item is used by a modem to indicate to its peer that 333 transmission of previously suppressed traffic may be resumed. An 334 example of when a modem might send this data item is when an internal 335 queue length drops below a particular threshold. 337 The sending of this data item parallels the Pause Data Item, see the 338 previous section, and follows the same rules. This includes that to 339 indicate that transmission can resume to all destinations, a modem 340 MAY send the Restart Data Item in a Session Update Message. It also 341 includes that to indicate that transmission can resume to a 342 particular destination a modem MAY send the Pause Restart Item in a 343 Destination Update Message. Finally, the same rules apply to queue 344 indexes. 346 A router which receives the Restart Data Item SHOULD resume 347 transmission of the identified traffic to the modem. 349 The format of the Restart Data Item matches the Pause Data Item and 350 is: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Data Item Type | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Queue Index | ... : 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 : ... | Queue Index | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Data Item Type: TBA4 364 Length: See Section 3.2. 366 Queue Index: See Section 3.2. 368 4. Security Considerations 370 The extension introduces a new mechanism for flow control between a 371 router and modem using the DLEP protocol. The extension does not 372 inherently introduce any additional threats above those documented in 373 [RFC8175]. The approach taken to Security in that document applies 374 equally when running the extension defined in this document. 376 5. IANA Considerations 378 This document requests the assignment of 4 values by IANA. All 379 assignments are to registries defined by [RFC8175]. 381 5.1. Extension Type Value 383 This document requests 1 new assignment to the DLEP Extensions 384 Registry named "Extension Type Values" in the range with the 385 "Specification Required" policy. The requested value is as follows: 387 +------+---------------------------+ 388 | Code | Description | 389 +------+---------------------------+ 390 | TBA1 | Control Plane Based Pause | 391 +------+---------------------------+ 393 Table 1: Requested Extension Type Value 395 5.2. Data Item Values 397 This document requests 3 new assignments to the DLEP Data Item 398 Registry named "Data Item Values" in the range with the 399 "Specification Required" policy. The requested values are as 400 follows: 402 +-----------+------------------+ 403 | Type Code | Description | 404 +-----------+------------------+ 405 | TBA2 | Queue Parameters | 406 | | | 407 | TBA3 | Pause | 408 | | | 409 | TBA4 | Restart | 410 +-----------+------------------+ 412 Table 2: Requested Data Item Values 414 6. References 416 6.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 424 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 425 May 2017, . 427 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 428 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 429 DOI 10.17487/RFC8175, June 2017, 430 . 432 6.2. Informative References 434 [I-D.ietf-manet-credit-window] 435 Ratliff, S., "Credit Windowing extension for DLEP", draft- 436 ietf-manet-credit-window-07 (work in progress), November 437 2016. 439 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 440 "Definition of the Differentiated Services Field (DS 441 Field) in the IPv4 and IPv6 Headers", RFC 2474, 442 DOI 10.17487/RFC2474, December 1998, 443 . 445 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 446 and W. Weiss, "An Architecture for Differentiated 447 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 448 . 450 Appendix A. Acknowledgments 452 The sub data item format was inspired by Rick Taylor's "Data Item 453 Containers". 455 Authors' Addresses 457 Bow-Nan Cheng 458 Lincoln Laboratory 459 Massachusetts Institute of Technology 460 244 Wood Street 461 Lexington, MA 02421-6426 463 Email: bcheng@ll.mit.edu 465 David Wiggins 466 Lincoln Laboratory 467 Massachusetts Institute of Technology 468 244 Wood Street 469 Lexington, MA 02420-9108 471 Email: David.Wiggins@ll.mit.edu 472 Lou Berger (editor) 473 LabN Consulting, L.L.C. 475 Email: lberger@labn.net