idnits 2.17.1 draft-ietf-manet-dlep-traffic-classification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2018) is 2092 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 (-13) exists of draft-ietf-manet-dlep-credit-flow-control-02 == 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-04 Summary: 0 errors (**), 0 flaws (~~), 4 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: February 3, 2019 L. Berger 6 LabN Consulting, L.L.C. 7 August 2, 2018 9 DLEP Traffic Classification Data Item 10 draft-ietf-manet-dlep-traffic-classification-00 12 Abstract 14 This document defines a new DLEP protocol Data Item that is used to 15 support traffic classification. Traffic classification information 16 is used to identify traffic flows based on frame/packet content such 17 as destination address. The Data Item is defined in an extensible 18 and reusable fashion. It's use will be mandated in other documents 19 defining specific DLEP extensions. This document aloas introduces 20 DLEP sub data items, and sub data items are defined to support 21 DiffServ and Ethernet traffic classification. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 3, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Traffic Classification . . . . . . . . . . . . . . . . . . . 3 60 2.1. Traffic Classification Data Item . . . . . . . . . . . . 4 61 2.1.1. Traffic Classification Sub Data Item . . . . . . . . 6 62 2.2. DiffServ Traffic Classification Sub Data Item . . . . . . 6 63 2.2.1. Router Receive Processing . . . . . . . . . . . . . . 8 64 2.3. Ethernet Traffic Classification Sub Data Item . . . . . . 8 65 2.3.1. Router Receive Processing . . . . . . . . . . . . . . 9 66 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Data Item Values . . . . . . . . . . . . . . . . . . . . 10 70 5.2. DLEP Traffic Classification Sub Data Item Registry . . . 10 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 6.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. 80 It provides the exchange of link related control information between 81 DLEP peers. DLEP peers are comprised of a modem and a router. DLEP 82 defines a base set of mechanisms as well as support for possible 83 extensions. DLEP defines Data Items which are sets of information 84 that can be reused in DLEP messaging. The base DLEP specification 85 does not include any flow identification beyond DLEP endpoints. This 86 document defines DLEP Data Item formats which provide flow 87 identification on a more granular basis. Specifically it enables 88 traffic sent by a router to use traffic flow classification 89 information provided by the modem to identify which traffic flows. 90 In this case, a flow is identified based on information found in a 91 data plane header and one or more matches are associated with a 92 single flow. (For general background on traffic classification see 93 [RFC2475] Section 2.3.) Credit windows may be shared or dedicated on 94 a per flow basis. The Data Item is structured to allow for reuse of 95 the defined traffic classification information with applications such 96 as credit window control, such as found in 97 [I-D.ietf-manet-dlep-da-credit-extension] 99 This document defines traffic classification based on a DLEP 100 destination and flows identified by either DiffServ [RFC2475] DSCPs 101 (differentiated services codepoints) or IEEE 802.1Q 102 [IEEE.802.1Q_2014] Ethernet Priority Code Points (PCP). The defined 103 mechanism allows for flows to be described in a flexible fashion and 104 when combined with applications such as credit window control, allows 105 credit windows to be shared across traffic sent to multiple DLEP 106 destinations and flows, or used exclusively for traffic sent to a 107 particular destination and/or flow. The extension also supports the 108 "wildcard" matching of any flow (DSCP or PCP). Traffic 109 classification information is provided such that it can be readily 110 extended to support other traffic classification techniques, or be 111 used by non-credit window related extensions, such as 112 [I-D.ietf-manet-dlep-pause-extension] or even 5-tuple IP flows. 114 This document defines support for traffic classification using a 115 single new Data Item in Section 2.1 for general support and two new 116 sub Data Items are defined to support identification of flows based 117 on DSCPs and PCPs. 119 1.1. Key Words 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Traffic Classification 129 The Traffic Classification Data Item is used to represent a list of 130 flows that may be used at the same time for traffic sent from a 131 router to a modem. The data plane information used to identify each 132 flow is represented in a separate sub Data Item. The Data Item and 133 Sub Data Item structure is intended to be independent of any specific 134 usage of the flow identification, e.g., flow control. The Sub Data 135 Item structure is also intended to allow for future traffic 136 classification types, e.g., 5-tuple flows. While the structure of 137 the Data Items is extensible, actual flow information is expected to 138 be used in an extension dependent manner. Support for DSCP and PCP- 139 based flows are defined via individual sub Data Items below. Other 140 types of flow identification, e.g., based on IP protocol and ports, 141 may be defined in the future via new sub Data Items. 143 The list of flows contained in the Data Item can be used per sender 144 or shared across multiple senders. Each list of flows is identified 145 using a "Traffic Classification Identifier" or "TID" and is expected 146 to represent a valid combination of data plane identifiers that may 147 be used at the same time. Each flow is identified via a "Flow 148 Identifier" or "FID". Each FID is defined in a sub Data Item which 149 carries the data plane identifier or identifiers used to associate 150 traffic with the flow. A DLEP destination address is also needed to 151 complete traffic classification information used in extensions such 152 as flow control. This information is expected to be provided in an 153 extension specific manner. For example, this address can be provided 154 by a modem when it identifies the traffic classification set in a 155 Destination Up Message using the Credit Window Associate Data Item 156 defined in [I-D.ietf-manet-dlep-credit-flow-control]. The scope of 157 TID and FID values is a modem. 159 2.1. Traffic Classification Data Item 161 This sections defines the Traffic Classification Data Item. This 162 Data Item is used by a modem to provide a router with traffic 163 classification information. When an extension requires use of this 164 Data Item the Traffic Classification Data Item SHOULD be included by 165 a modem in any Session Initialization Response Message, e.g., see 166 [I-D.ietf-manet-dlep-da-credit-extension]. Updates to previously 167 provided traffic classifications or new traffic classifications MAY 168 be sent by a modem by including the Data Item in Session Update 169 Messages. More than one Data Item MAY be included in a message to 170 provide information on multiple traffic classifiers. 172 The set of traffic classification information provided in the data 173 item is identified using a Traffic Classification Identifier, or TID. 174 The actual data plane related information used in traffic 175 classification is provided in a variable list of Traffic 176 Classification Sub Data Items. 178 The format of the Traffic Classification Data Item is: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Data Item Type | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |Traffic Class. Identifier (TID)| Num SDIs | Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Traffic Classification Sub Data Item 1 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 : ... : 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Traffic Classification Sub Data Item n | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Data Item Type: TBA1 196 Length: Variable 198 Per [RFC8175] Length is the number of octets in the Data Item, 199 excluding the Type and Length fields. 201 Traffic Classification Identifier (TID): 203 A 16-bit unsigned integer identifying a traffic classification 204 set. There is no restriction on values used by a modem, and there 205 is no requirement for sequential or ordered values. 207 Num SDIs: 209 An 8-bit unsigned integer indicating the number of Traffic 210 Classification Sub Data Items included in the Data Item. A value 211 of zero (0) is allowed and indicates that no traffic should be 212 matched against this TID. 214 Reserved: 216 MUST be set to zero by the sender (a modem) and ignored by the 217 receiver (a router). 219 Traffic Classification Sub Data Item: 221 Zero or more Traffic Classification Sub Data Items of the format 222 defined below MAY be included. The number MUST match the value 223 carried in the Num SDIs field. 225 A router receiving the Traffic Classification Data Item MUST locate 226 the traffic classification information that is associated with the 227 TID indicated in each received Data Item. If no associated traffic 228 classification information is found, the router MUST initialize a new 229 information set using the values carried in the Data Item. When 230 associated traffic classification information is found, the router 231 MUST update the information using the values carried in the Data 232 Item. In both cases, a router MUST also ensure that any data plane 233 state, e.g., [I-D.ietf-manet-dlep-credit-flow-control], that is 234 associated with the TID is updated as needed. 236 2.1.1. Traffic Classification Sub Data Item 238 All Traffic Classification Sub Data Items share a common format that 239 is patterned after the standard DLEP Data Item format, see [RFC8175] 240 Section 11.3. There is no requirement on, or meaning to sub Data 241 Item ordering. Any errors or inconsistencies encountered in parsing 242 sub Data Items are handled in the same fashion as any other Data Item 243 parsing error encountered in DLEP. 245 The format of the Traffic Classification Sub Data Item is: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Sub Data Item Type | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Value... : 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Sub Data Item Type: 257 A 16-bit unsigned integer that indicates the type and 258 corresponding format of the Sub Data Item's Value field. Sub Data 259 Item Types are scoped within the Data Item in which they are 260 carried, i.e., the Sub Data Item Type field MUST be used together 261 with the Data Item Type to identify the format of the Sub Data 262 Item. Traffic Classification Sub Data Item Types are managed 263 according to the IANA registry described in Section 5.2. 265 Length: Variable 267 Copying [RFC8175], Length is a 16-bit unsigned integer that is the 268 number of octets in the sub Data Item, excluding the Type and 269 Length fields. 271 2.2. DiffServ Traffic Classification Sub Data Item 273 The DiffServ Traffic Classification Sub Data Item is used to identify 274 the set of DSCPs that should be treated as a single flow, i.e., 275 receive the same traffic treatment. DSCPs are identified in a list 276 of DiffServ fields. An implementation that does not support DSCPs 277 and wants the same traffic treatment for all traffic to a destination 278 or destinations would indicate 0 DSCPs. 280 The format of the DiffServ Traffic Classification Sub Data Item is: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Must be one (1) | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Flow Identifier (FID) | Num DSCPs | DS Field 1 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | DS Field 2 | ... | DS Field n | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Length: Variable 294 Length is defined above. For this Sub Data Item, it is equal to 295 three (3) plus the value of the Num DSCPs field. 297 Flow Identifier (FID): 299 A 16-bit unsigned integer representing the data plane information 300 carried in the sub Data Item that is to be used in identifying a 301 flow. The value of 0xFFFF is reserved and MUST NOT be used in 302 this field. 304 Num DSCPs: 306 An 8-bit unsigned integer indicating the number of DSCPs carried 307 in the sub Data Item. A zero (0) indicates a (wildcard) match 308 against any DSCP value. 310 DS Field: 312 Each DS Field is an 8-bit whose definition is the same as 313 [RFC2474]. 315 0 1 2 3 4 5 6 7 316 +---+---+---+---+---+---+---+---+ 317 | DSCP | CU | 318 +---+---+---+---+---+---+---+---+ 320 DSCP: differentiated services codepoint 321 CU: currently unused, MUST be zero 323 2.2.1. Router Receive Processing 325 A router receiving the Traffic Classification Sub Data Item MUST 326 validate the information on receipt, prior to using the carried 327 information, including potentially updating the data behavior as 328 determined by the extension requiring the use of the Sub Data Item. 329 Validation failures MUST be treated as an error as described above. 331 Once validated, the receiver MUST ensure that each DS Field value is 332 listed only once across the whole Traffic Classification Data Item. 333 Note, this check is across the Data Item and not the individual sub 334 Data Item. If the same DS Field value is listed more than once 335 within the same Traffic Classification Data Item, the Data Item MUST 336 be treated as an error as described above. 338 2.3. Ethernet Traffic Classification Sub Data Item 340 The Ethernet Traffic Classification Sub Data Item is used to identify 341 the VLAN and PCPs that should be treated as a single flow, i.e., 342 receive the same traffic treatment. Ethernet Priority Code Point 343 support is defined as part of the IEEE 802.1Q [IEEE.802.1Q_2014] tag 344 format and includes a 3 bit "PCP" field. The tag format also 345 includes a 12 bit VLAN identifier (VID) field. PCPs are identified 346 in a list of priority fields. An implementation that does not 347 support PCPs and wants the same traffic treatment for all traffic to 348 a destination or destinations would indicate 0 PCPs. Such an 349 implementation could identify a VLAN to use per destination. 351 The format of the Ethernet Traffic Classification Sub Data Item is: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Must be two (2) | Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Flow Identifier (FID) |NumPCPs| VLAN Identifier (VID) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Pri. 1| Pri. 2| ..... | ..... | ..... | Pad | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Length: Variable 365 Length is defined above. For this Sub Data Item, it is equal to 366 four (4) plus the number of octets needed to carry the carried 367 Priority fields is indicated by the NumPCPs field. Note that as 368 length is in octets and each Priority field is 4 bits, the 369 additional length is the value carried in the NumPCPs field 370 divided by two and rounded up to the next higher integer quantity. 372 Flow Identifier (FID): 374 A 16-bit unsigned integer representing the data plane information 375 carried in the sub Data Item that is to be used in identifying a 376 flow. The value of 0xFFFF is reserved and MUST NOT be used in 377 this field. 379 Num PCPs: 381 A 4-bit unsigned integer indicating the number of Priority fields 382 carried in the sub Data Item. A zero (0) indicates a (wildcard) 383 match against any PCP value. 385 VLAN identifier (VID): 387 A 12-bit unsigned integer field indicating the VLAN to be used in 388 traffic classification. A value of zero (0) indicates that the 389 VID is to be ignored and any VID is to be accepted during traffic 390 classification. 392 Priority: 394 Each Priority Field is 4-bits long and indicates a PCP field 395 defined in [IEEE.802.1Q_2014]. Note that zero (0) is a valid 396 value for either PCP or DEI. 398 0 1 2 3 399 +---+---+---+---+ 400 | PCP |DEI| 401 +---+---+---+---+ 403 PCP: Priority code point 404 DEI: currently unused, MUST be zero 406 Pad: 408 A 4-bit long field included when NumPCPs is an odd number. This 409 field MUST be set to zero when added, and MIST be ignored on 410 receipt. 412 2.3.1. Router Receive Processing 414 A router receiving the Traffic Classification Sub Data Item MUST 415 validate the information on receipt, prior to the using the carried 416 information, including potentially updating the data behavior as 417 determined by the extension requiring the use of the Sub Data Item. 418 Validation failures MUST be treated as an error as described above. 420 Once validated, the receiver MUST ensure that each Priority Field 421 value is listed only once across the whole Traffic Classification 422 Data Item. Note, this check is across the Data Item and not the 423 individual sub Data Item. If the same Priority Field value is listed 424 more than once within the same Traffic Classification Data Item, the 425 Data Item MUST be treated as an error as described above. 427 3. Compatibility 429 The formats defined in this document will only be used when 430 extensions require their use. 432 4. Security Considerations 434 This document introduces finer grain flow identification mechanisms 435 to DLEP. These mechanisms do not inherently introduce any additional 436 threats above those documented in [RFC8175]. The approach taken to 437 Security in that document applies equally to the mechanism defined in 438 this document. 440 5. IANA Considerations 442 This document requests the assignment of several values by IANA. All 443 assignments are to registries defined by [RFC8175]. 445 5.1. Data Item Values 447 This document requests the following new assignments to the DLEP Data 448 Item Registry named "Data Item Type Values" in the range with the 449 "Specification Required" policy. The requested values are as 450 follows: 452 +-----------+------------------------+ 453 | Type Code | Description | 454 +-----------+------------------------+ 455 | TBA1 | Traffic Classification | 456 +-----------+------------------------+ 458 Table 1: Requested Data Item Values 460 5.2. DLEP Traffic Classification Sub Data Item Registry 462 Upon approval of this document, IANA is requested to create a new 463 DLEP registry, named "Traffic Classification Sub Data Item Type 464 Values". The registry shall identify the type code value, the Data 465 Item which may use the value, and a description of the value. While 466 the same value may be reused in different Data Items, this is not 467 recommended at this time. 469 The following table provides initial registry values and the 470 [RFC8126] defined policies that should apply to the registry: 472 +-------------+---------------------------------+ 473 | Type Code | Description | 474 +-------------+---------------------------------+ 475 | 0 | Reserved | 476 | | | 477 | 1 | DiffServ Traffic Classification | 478 | | | 479 | 2 | Ethernet Traffic Classification | 480 | | | 481 | 3-65407 | Specification Required | 482 | | | 483 | 65408-65534 | Private Use | 484 | | | 485 | 65535 | Reserved | 486 +-------------+---------------------------------+ 488 Table 2: Initial Registry Values 490 6. References 492 6.1. Normative References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, 496 DOI 10.17487/RFC2119, March 1997, 497 . 499 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 500 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 501 May 2017, . 503 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 504 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 505 DOI 10.17487/RFC8175, June 2017, 506 . 508 6.2. Informative References 510 [I-D.ietf-manet-dlep-credit-flow-control] 511 Cheng, B., Wiggins, D., and L. Berger, "DLEP Credit-Based 512 Flow Control Messages and Data Items", draft-ietf-manet- 513 dlep-credit-flow-control-02 (work in progress), June 2018. 515 [I-D.ietf-manet-dlep-da-credit-extension] 516 Cheng, B., Wiggins, D., and L. Berger, "DLEP DiffServ 517 Aware Credit Window Extension", draft-ietf-manet-dlep-da- 518 credit-extension-05 (work in progress), May 2018. 520 [I-D.ietf-manet-dlep-pause-extension] 521 Cheng, B., Wiggins, D., and L. Berger, "DLEP Control Plane 522 Based Pause Extension", draft-ietf-manet-dlep-pause- 523 extension-04 (work in progress), June 2018. 525 [IEEE.802.1Q_2014] 526 IEEE, "IEEE Standard for Local and metropolitan area 527 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 528 DOI 10.1109/ieeestd.2014.6991462, December 2014, 529 . 532 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 533 "Definition of the Differentiated Services Field (DS 534 Field) in the IPv4 and IPv6 Headers", RFC 2474, 535 DOI 10.17487/RFC2474, December 1998, 536 . 538 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 539 and W. Weiss, "An Architecture for Differentiated 540 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 541 . 543 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 544 Writing an IANA Considerations Section in RFCs", BCP 26, 545 RFC 8126, DOI 10.17487/RFC8126, June 2017, 546 . 548 Appendix A. Acknowledgments 550 The sub Data Item format was inspired by Rick Taylor's "Data Item 551 Containers". He also proposed the separation of credit windows from 552 traffic classification at IETF98. Many useful comments were received 553 from contributors to the MANET working group. This document was 554 derived from [I-D.ietf-manet-dlep-da-credit-extension] as a result of 555 discussions at IETF101. 557 Authors' Addresses 558 Bow-Nan Cheng 559 MIT Lincoln Laboratory 560 Massachusetts Institute of Technology 561 244 Wood Street 562 Lexington, MA 02421-6426 564 Email: bcheng@ll.mit.edu 566 David Wiggins 567 MIT Lincoln Laboratory 568 Massachusetts Institute of Technology 569 244 Wood Street 570 Lexington, MA 02421-6426 572 Email: David.Wiggins@ll.mit.edu 574 Lou Berger 575 LabN Consulting, L.L.C. 577 Email: lberger@labn.net