idnits 2.17.1 draft-ietf-manet-dlep-traffic-classification-04.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 (December 4, 2020) is 1232 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-06 == Outdated reference: A later version (-16) exists of draft-ietf-manet-dlep-da-credit-extension-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Cheng 3 Internet-Draft D. Wiggins 4 Intended status: Standards Track MIT Lincoln Laboratory 5 Expires: June 7, 2021 L. Berger 6 LabN Consulting, L.L.C. 7 December 4, 2020 9 DLEP Traffic Classification Data Item 10 draft-ietf-manet-dlep-traffic-classification-04 12 Abstract 14 This document defines a new Dynamic Link Exchange Protocol (DLEP) 15 Data Item that is used to support traffic classification. Traffic 16 classification information is used to identify traffic flows based on 17 frame/packet content such as destination address. The Data Item is 18 defined in an extensible and reusable fashion. It's use will be 19 mandated in other documents defining specific DLEP extensions. This 20 document also introduces DLEP sub data items, and sub data items are 21 defined to support 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 June 7, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 . . . . . . 7 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 . . . . . . . . . . . . . . 10 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 . . . 11 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 6.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 Traffic Classification Data Item Type to identify the 262 format of the Sub Data Item. Traffic Classification Sub Data Item 263 Types are managed according to the IANA registry described in 264 Section 5.2. 266 Length: Variable 268 Copying [RFC8175], Length is a 16-bit unsigned integer that is the 269 number of octets in the sub Data Item, excluding the Type and 270 Length fields. 272 2.2. DiffServ Traffic Classification Sub Data Item 274 The DiffServ Traffic Classification Sub Data Item is used to identify 275 the set of DSCPs that should be treated as a single flow, i.e., 276 receive the same traffic treatment. DSCPs are identified in a list 277 of DiffServ fields. An implementation that does not support DSCPs 278 and wants the same traffic treatment for all traffic to a destination 279 or destinations would indicate 0 DSCPs. 281 The format of the DiffServ Traffic Classification Sub Data Item is: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Must be one (1) | Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Flow Identifier (FID) | Num DSCPs | DS Field 1 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | DS Field 2 | ... | DS Field n | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Length: Variable 295 Length is defined above. For this Sub Data Item, it is equal to 296 three (3) plus the value of the Num DSCPs field. 298 Flow Identifier (FID): 300 A 16-bit unsigned integer representing the data plane information 301 carried in the sub Data Item that is to be used in identifying a 302 flow. The value of 0xFFFF is reserved and MUST NOT be used in 303 this field. 305 Num DSCPs: 307 An 8-bit unsigned integer indicating the number of DSCPs carried 308 in the sub Data Item. A zero (0) indicates a (wildcard) match 309 against any DSCP value. 311 DS Field: 313 Each DS Field is an 8-bit whose definition is the same as 314 [RFC2474]. 316 0 1 2 3 4 5 6 7 317 +---+---+---+---+---+---+---+---+ 318 | DSCP | CU | 319 +---+---+---+---+---+---+---+---+ 321 DSCP: differentiated services codepoint 322 CU: currently unused, MUST be zero 324 2.2.1. Router Receive Processing 326 A router receiving the Traffic Classification Sub Data Item MUST 327 validate the information on receipt, prior to using the carried 328 information, including potentially updating the data behavior as 329 determined by the extension requiring the use of the Sub Data Item. 330 Validation failures MUST be treated as an error as described above. 332 Once validated, the receiver MUST ensure that each DS Field value is 333 listed only once across the whole Traffic Classification Data Item. 334 Note, this check is across the Data Item and not the individual sub 335 Data Item. If the same DS Field value is listed more than once 336 within the same Traffic Classification Data Item, the Data Item MUST 337 be treated as an error as described above. 339 2.3. Ethernet Traffic Classification Sub Data Item 341 The Ethernet Traffic Classification Sub Data Item is used to identify 342 the VLAN and PCPs that should be treated as a single flow, i.e., 343 receive the same traffic treatment. Ethernet Priority Code Point 344 support is defined as part of the IEEE 802.1Q [IEEE.802.1Q_2014] tag 345 format and includes a 3 bit "PCP" field. The tag format also 346 includes a 12 bit VLAN identifier (VID) field. PCPs are identified 347 in a list of priority fields. An implementation that does not 348 support PCPs and wants the same traffic treatment for all traffic to 349 a destination or destinations would indicate 0 PCPs. Such an 350 implementation could identify a VLAN to use per destination. 352 The format of the Ethernet Traffic Classification Sub Data Item is: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Must be two (2) | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Flow Identifier (FID) |NumPCPs| VLAN Identifier (VID) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Pri. 1| Pri. 2| ..... | ..... | ..... | Pad | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Length: Variable 366 Length is defined above. For this Sub Data Item, it is equal to 367 four (4) plus the number of octets needed to carry the carried 368 Priority fields is indicated by the NumPCPs field. Note that as 369 length is in octets and each Priority field is 4 bits, the 370 additional length is the value carried in the NumPCPs field 371 divided by two and rounded up to the next higher integer quantity. 373 Flow Identifier (FID): 375 A 16-bit unsigned integer representing the data plane information 376 carried in the sub Data Item that is to be used in identifying a 377 flow. The value of 0xFFFF is reserved and MUST NOT be used in 378 this field. 380 Num PCPs: 382 A 4-bit unsigned integer indicating the number of Priority fields 383 carried in the sub Data Item. A zero (0) indicates a (wildcard) 384 match against any PCP value. 386 VLAN identifier (VID): 388 A 12-bit unsigned integer field indicating the VLAN to be used in 389 traffic classification. A value of zero (0) indicates that the 390 VID is to be ignored and any VID is to be accepted during traffic 391 classification. 393 Priority: 395 Each Priority Field is 4-bits long and indicates a PCP field 396 defined in [IEEE.802.1Q_2014]. Note that zero (0) is a valid 397 value for either PCP or DEI. 399 0 1 2 3 400 +---+---+---+---+ 401 | PCP |DEI| 402 +---+---+---+---+ 404 PCP: Priority code point 405 DEI: currently unused, MUST be zero 407 Pad: 409 A 4-bit long field included when NumPCPs is an odd number. This 410 field MUST be set to zero when added, and MIST be ignored on 411 receipt. 413 2.3.1. Router Receive Processing 415 A router receiving the Traffic Classification Sub Data Item MUST 416 validate the information on receipt, prior to the using the carried 417 information, including potentially updating the data behavior as 418 determined by the extension requiring the use of the Sub Data Item. 419 Validation failures MUST be treated as an error as described above. 421 Once validated, the receiver MUST ensure that each Priority Field 422 value is listed only once across the whole Traffic Classification 423 Data Item. Note, this check is across the Data Item and not the 424 individual sub Data Item. If the same Priority Field value is listed 425 more than once within the same Traffic Classification Data Item, the 426 Data Item MUST be treated as an error as described above. 428 3. Compatibility 430 The formats defined in this document will only be used when 431 extensions require their use. 433 4. Security Considerations 435 This document introduces finer grain flow identification mechanisms 436 to DLEP. These mechanisms do not inherently introduce any additional 437 vulnerabilities above those documented in [RFC8175]. The approach 438 taken to Security in that document applies equally to the mechanism 439 defined in this document. 441 5. IANA Considerations 443 This document requests the assignment of several values by IANA. All 444 assignments are to registries defined by [RFC8175]. 446 5.1. Data Item Values 448 This document requests the following new assignments to the DLEP Data 449 Item Registry named "Data Item Type Values" in the range with the 450 "Specification Required" policy. The requested values are as 451 follows: 453 +-----------+------------------------+ 454 | Type Code | Description | 455 +-----------+------------------------+ 456 | TBA1 | Traffic Classification | 457 +-----------+------------------------+ 459 Table 1: Requested Data Item Values 461 5.2. DLEP Traffic Classification Sub Data Item Registry 463 Upon approval of this document, IANA is requested to create a new 464 DLEP registry, named "Traffic Classification Sub Data Item Type 465 Values". 467 The following table provides initial registry values and the 468 [RFC8126] defined policies that should apply to the registry: 470 +-------------+---------------------------------+ 471 | Type Code | Description | 472 +-------------+---------------------------------+ 473 | 0 | Reserved | 474 | | | 475 | 1 | DiffServ Traffic Classification | 476 | | | 477 | 2 | Ethernet Traffic Classification | 478 | | | 479 | 3-65407 | Specification Required | 480 | | | 481 | 65408-65534 | Private Use | 482 | | | 483 | 65535 | Reserved | 484 +-------------+---------------------------------+ 486 Table 2: Initial Registry Values 488 6. References 490 6.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 498 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 499 May 2017, . 501 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 502 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 503 DOI 10.17487/RFC8175, June 2017, 504 . 506 6.2. Informative References 508 [I-D.ietf-manet-dlep-credit-flow-control] 509 Cheng, B., Wiggins, D., Berger, L., and S. Ratliff, "DLEP 510 Credit-Based Flow Control Messages and Data Items", draft- 511 ietf-manet-dlep-credit-flow-control-06 (work in progress), 512 June 2020. 514 [I-D.ietf-manet-dlep-da-credit-extension] 515 Cheng, B., Wiggins, D., and L. Berger, "DLEP DiffServ 516 Aware Credit Window Extension", draft-ietf-manet-dlep-da- 517 credit-extension-09 (work in progress), June 2020. 519 [I-D.ietf-manet-dlep-pause-extension] 520 Cheng, B., Wiggins, D., and L. Berger, "DLEP Control Plane 521 Based Pause Extension", draft-ietf-manet-dlep-pause- 522 extension-08 (work in progress), June 2019. 524 [IEEE.802.1Q_2014] 525 IEEE, "IEEE Standard for Local and metropolitan area 526 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 527 DOI 10.1109/ieeestd.2014.6991462, December 2014, 528 . 531 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 532 "Definition of the Differentiated Services Field (DS 533 Field) in the IPv4 and IPv6 Headers", RFC 2474, 534 DOI 10.17487/RFC2474, December 1998, 535 . 537 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 538 and W. Weiss, "An Architecture for Differentiated 539 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 540 . 542 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 543 Writing an IANA Considerations Section in RFCs", BCP 26, 544 RFC 8126, DOI 10.17487/RFC8126, June 2017, 545 . 547 Appendix A. Acknowledgments 549 The sub Data Item format was inspired by Rick Taylor's "Data Item 550 Containers". He also proposed the separation of credit windows from 551 traffic classification at IETF98. Many useful comments were received 552 from contributors to the MANET working group. This document was 553 derived from [I-D.ietf-manet-dlep-da-credit-extension] as a result of 554 discussions at IETF101. 556 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