idnits 2.17.1 draft-ietf-ccamp-ethernet-traffic-parameters-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 138 has weird spacing: '... frames witho...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 20, 2010) is 5209 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) == Missing Reference: '0xF8' is mentioned on line 304, but not defined == Missing Reference: '0xFF' is mentioned on line 304, but not defined == Missing Reference: '0x00' is mentioned on line 310, but not defined == Missing Reference: '0x07' is mentioned on line 310, but not defined -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ESVCS' Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Papadimitriou 3 Internet Draft Alcatel-Lucent 4 Updates: 3471, 3473 January 20, 2010 5 Intended status: Standards Track 6 Expires: July 19, 2010 8 Ethernet Traffic Parameters 10 draft-ietf-ccamp-ethernet-traffic-parameters-10.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright and License Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described 46 in Section 4.e of the Trust Legal Provisions and are provided 47 without warranty as described in the BSD License. 49 Abstract 51 This document describes the support of Metro Ethernet Forum (MEF) 52 Ethernet Traffic Parameters as described in MEF10.1 when using 53 Generalized Multi-Protocol Label Switching (GMPLS) Resource 54 ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. 56 1. Introduction 58 Per [RFC3471], Generalized Multi-Protocol Label Switching (GMPLS) 59 allows the inclusion of technology specific parameters in 60 signaling. Ethernet SENDER_TSPEC and FLOWSPEC specific objects 61 are introduced in this document that supports Metro Ethernet 62 Forum (MEF) Ethernet traffic parameters as specified in [MEF10.1] 63 and ITU-T Ethernet Service Switching as discussed in [GMPLS- 64 ESVCS]. For example: 66 o For Ethernet Private Line (EPL) services [MEF6], these traffic 67 parameters are applicable to each Ethernet Virtual Connection 68 (EVC) crossing a given port. 70 o For Ethernet Virtual Private Line (EVPL) services [MEF6], these 71 traffic parameters are applicable per Ethernet Virtual 72 Connection (EVC) with single or multiple Class of Service 73 (CoS), independent of its associated (set of) Virtual LAN ID 74 (VID). 76 Association between EVC and VIDs is detailed in [MEF10.1]. The 77 format and encoding of the (set of) VIDs is documented in a 78 companion document [GMPLS-ESVCS]. 80 This does not preclude broader usage of the Ethernet SENDER_TSPEC 81 and FLOWSPEC specific objects specified this document. For 82 instance, they may also be used for signaling Ethernet Label 83 Switched Paths (LSP): in the Generalized Label Request (see 84 [RFC3471]), the Switching Type field is set to Layer 2 Switching 85 Capability (L2SC) and the LSP Encoding Type field to Ethernet. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 90 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in 92 RFC-2119 [RFC2119]. 94 Moreover, the reader is assumed to be familiar with the 95 terminology [MEF10.1] as well as [RFC3471] and [RFC3473]. 97 3. Overview 99 In GMPLS RSVP-TE [RFC3473] the SENDER_TSPEC object is used on a 100 Path message to indicate the bandwidth that is requested for the 101 LSP being established, and the FLOWSPEC object is used on a Resv 102 message to indicate the bandwidth actually reserved for the LSP. 103 The Ethernet SENDER_TSPEC/FLOWSPEC object includes the Ethernet 104 link type (switching granularity) of the requested LSP and the 105 MTU value for the LSP. Other information about the requested 106 bandwidth characteristics of the LSP are carried in the Bandwidth 107 Profile as a TLV within the Ethernet SENDER_TSPEC/FLOWSPEC 108 object. 110 The Ethernet SENDER_TSPEC/FLOWSPEC object includes the Ethernet 111 link type (switching granularity) of the requested LSP and the 112 MTU value for the LSP. 114 The Bandwidth Profile defines the set of traffic parameters 115 applicable to a sequence of Service Frames, referred to as 116 bandwidth profile parameters (as specified in [MEF10.1]): 118 o Committed Rate: indicates the rate at which traffic commits to 119 be sent to the Ethernet LSP. The Committed Rate is described in 120 terms of the CIR (Committed Information Rate) and CBS 121 (Committed Burst Size) traffic parameters. 123 o CIR is defined as the average rate (in bytes per unit of 124 time) up to which the network is committed to transfer frames 125 and meets its performance objectives. 127 o CBS defines a limit on the maximum number of information 128 units (e.g., bytes) available for a burst of frames sent at 129 the interface speed to remain CIR-conformant. 131 o Excess Rate: indicates the extent by which the traffic sent on 132 an Ethernet LSP exceeds the committed rate. The Excess Rate is 133 described in terms of the EIR (Excess Information Rate) and EBS 134 (Excess Burst Size) traffic parameters. 136 o EIR is defined as the average rate (in bytes per unit of 137 time), in excess of the CIR, up to which the network may 138 transfer frames without any performance objectives. 140 o EBS defines a limit on the maximum number of information unit 141 (e.g., bytes) available for a burst of frames sent at the 142 interface speed to remain EIR-conformant. 144 o Color mode (CM): indicates whether the "color-aware" or "color- 145 blind" property is employed by the bandwidth profile. 147 o Coupling flag (CF): allows the choice between two modes of 148 operation of the rate enforcement algorithm. 150 4. Ethernet SENDER_TSPEC Object 152 The Ethernet SENDER_TSPEC object (Class-Num = 12, Class-Type = 153 TBA by IANA, with recommended value 6) has the following format: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Length | Class-Num (12)| C-Type (6) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Switching Granularity | MTU | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 ~ TLVs ~ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Switching Granularity (SG): 16 bits 169 This field indicates the type of link that comprises the 170 requested Ethernet LSP. 172 The permitted Ethernet Link Type values are: 174 Value Switching Granularity 175 ----- --------------------- 176 0 Provided in signaling. See [GMPLS-ESVCS] 177 1 Ethernet Port (for port-based service) 178 2 Ethernet Frame (for EVC-based service) 179 255 Reserved value 181 Values 0 through 239, and 255 are assigned by IANA via IETF 182 Standards Action. Value 255 is reserved by the 183 present document. 185 Values 240 through 254 are reserved for Private Use. 187 Values 256 through 65535 are not to be assigned at this time. 189 MTU: 16 bits 191 This is a two-octet value indicating the MTU in octets. 193 The MTU field MUST NOT take a value smaller than 46 bytes for 194 Ethernet V2 [ETHv2] and 38 bytes for IEEE 802.3 [IEEE802.3]. 196 TLV (Type-Length-Value): 198 The Ethernet SENDER_TSPEC object MUST include at least one TLV 199 and MAY include more than one TLV. 201 Each TLV MUST have the following format: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 ~ Value ~ 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Type: 16 bits 215 Defined values are: 217 Type Length Format Description 218 ------------------------------------------------------ 219 0 TBD Reserved Reserved value 220 1 TBD Reserved Reserved value 221 2 24 see Section 3.1 Ethernet Bandwidth 222 Profile [MEF10.1] 223 3 8 [GMPLS-ESVCS] Layer 2 Control 224 Processing (L2CP) 225 255 TBD Reserved Reserved value 227 Values 0 through 239, and 255 are assigned by IANA via IETF 228 Standards Action. Values 0 and 255 are reserved 229 by the present document. 231 Values 240 through 254 are reserved for Private Use. 233 Values 256 through 65535 are not to be assigned at this 234 time. 236 Length: 16 bits 238 Indicates the length in bytes of the whole TLV including 239 the Type and Length fields. A value field whose length is 240 not a multiple of four MUST be zero-padded (with trailing 241 zeros) so that the TLV is four-octet aligned. 243 4.1. Ethernet Bandwidth Profile TLV 245 The Type 2 TLV specifies the Ethernet Bandwidth Profile (BW 246 profile). It defines an upper bound on the volume of the expected 247 service frames belonging to a particular Ethernet service 248 instance. The Ethernet SENDER_TSPEC object MAY include more than 249 one Ethernet Bandwidth Profile TLV. 251 The Type 2 TLV has the following format: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Profile | Index | Reserved | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | CIR | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | CBS | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | EIR | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | EBS | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Profile: 8 bits (this field is to be registered by IANA) 269 This field is defined as a bit vector of binary flags. The 270 following flags are defined: 272 Flag 1 (bit 0): coupling flag (CF) 273 Flag 2 (bit 1): color mode (CM) 275 Where bit 0 is the low order bit. Other flags are reserved, 276 they SHOULD be set to zero when sent, and SHOULD be ignored 277 when received. 279 A flag is set to value 1 to indicate that the corresponding 280 metering profile is requested. 282 The Flag 1 (CF) allows the choice between two modes of 283 operation of the rate enforcement algorithm. 285 The Flag 2 (CM) indicates whether the color-aware or color- 286 blind property is employed by the bandwidth profile. When Flag 287 2 is set to value 0 (1), the bandwidth profile algorithm is 288 said to be in color blind (color aware) mode. 290 Index: 8 bits 292 The index field is used to reference bandwidth allocated for a 293 given traffic class in case a multiple-class LSP is being 294 requested. The index field value MUST correspond to at least 295 one of the Class-Type values included either in the CLASSTYPE 296 object [RFC4124] or in the EXTENDED_CLASSTYPE object [MCOS]. 298 A given index value j can be associated to at most N Class- 299 Type values CTi (i =< N) of the EXTENDED_CLASSTYPE object. 300 This applies in case a set of one or more CTi maps a single 301 (shared) BW profile. An example of value setting consists then 302 in assigning an arbitrary value comprised within the range 303 [0x08,0xF8[ associated to a set of CTi, the values in the 304 range [0xF8,0xFF] being selected for reserved sets. This 305 allows mapping to one of 248 pre-defined CTi sets. 307 A given index value j can be associated to a single CTi (1:1 308 correspondence). In this case, the index value setting 309 consists then in assigning the 3 LSB of the index field itself 310 to the CTi value itself (comprised in the range [0x00,0x07]). 311 This applies in case a single CTi maps a single (dedicated) BW 312 profile or multiple (dedicated) BW profiles. In the former 313 case (single BW profile), the Ethernet SENDER_TSPEC object 314 includes a single Ethernet Bandwidth Profile TLV. In the 315 second case, the Ethernet SENDER_TSPEC includes a set of more 316 than one Ethernet Bandwidth Profile TLVs (whose respective 317 Index value is associated to a single CTi value). 319 Note that the current specification allows for combining 320 shared and dedicated BW profiles to the same LSP. That is, an 321 Ethernet SENDER_TSPEC object MAY include multiple Ethernet 322 Bandwidth Profile TLVs whose respective index can be 323 associated on a 1:1 basis to a single CTi or to a set of 324 multiple CTi. 326 For each subobject of the EXTENDED_CLASSTYPE object [MCOS]: 327 o Each CTi value SHOULD correspond 1:1 to MEF CE VLAN-CoS 328 o The BW requested per CTi field MAY be used for bandwidth 329 accounting purposes. 331 By default, the value of the Index field MUST be set to 0. 333 Reserved: 16 bits 335 These bits SHOULD be set to zero when sent and MUST be ignored 336 when received. 338 CIR (Committed Information Rate): 32 bits 340 The value of the CIR is in units of bytes per second. The CIR 341 is encoded as a 32-bit IEEE single-precision floating-point 342 number (see [RFC4506]). 344 The CIR value MUST be greater than or equal to 0. 346 CBS (Committed Burst Size): 32 bits 348 The value of the CBS is in units of bytes. The CBS is encoded 349 as a 32-bit IEEE single-precision floating-point number (see 350 [RFC4506]). 352 When CIR is strictly greater than 0 (CIR > 0), the CBS MUST be 353 greater than or equal to the maximum frame size. 355 EIR (Excess Information Rate): 32 bits 357 The value of the EIR is in units of bytes per second. The EIR 358 is encoded as a 32-bit IEEE single-precision floating-point 359 number (see [RFC4506]). 361 The EIR value MUST be greater than or equal to 0. 363 EBS (Excess Burst Size): 32 bits 365 The value of the EBS is in units of bytes. The EBS is encoded 366 as a 32-bit IEEE single-precision floating-point number (see 367 [RFC4506]). 369 When EIR is strictly greater than 0 (EIR > 0), the EBS MUST be 370 greater than or equal to the maximum frame size. 372 5. Ethernet FLOWSPEC Object 374 The Ethernet FLOWSPEC object (Class-Num = 12, Class-Type = TBA by 375 IANA, with recommended value 6) has the same format as the 376 Ethernet SENDER_TSPEC object. 378 6. Ethernet ADSPEC Object 380 There is no ADSPEC object associated with the Ethernet 381 SENDER_TSPEC object. 383 Either the ADSPEC object is omitted or an IntServ ADSPEC with the 384 Default General Characterization Parameters and Guaranteed 385 Service fragment is used, see [RFC2210]. 387 7. Processing 389 The Ethernet SENDER_TSPEC and FLOWSPEC objects specified in this 390 document MAY be used for signaling Ethernet LSP. For signaling 391 such LSP, in the Generalized LABEL_REQUEST object (see 392 [RFC3471]), the Switching Type field MUST be set to the value 51 393 (L2SC) and the LSP Encoding Type field MUST be set to the value 2 394 (Ethernet). 396 The Ethernet SENDER_TSPEC object carries the traffic 397 specification generated by the RSVP session sender. The Ethernet 398 SENDER_TSPEC object SHOULD be forwarded and delivered unchanged 399 to both intermediate and egress nodes. 401 The Ethernet FLOWSPEC object carries reservation request 402 information generated by receivers. As with any FLOWSPEC object, 403 Ethernet FLOWSPEC object flows upstream toward the ingress node. 405 Intermediate and egress nodes MUST verify that the node itself 406 and the interfaces on which the LSP will be established can 407 support the requested Switching Granularity, MTU and values 408 included in sub-object TLVs. These nodes MUST be configured with 409 the same pre-defined CT sets as the index value signaled as part 410 of the index field of the Ethernet Bandwidth Profile TLV (see 411 Section 4.1). If the requested value(s) can not be supported, the 412 receiver node MUST generate a PathErr message with the error code 413 "Traffic Control Error" and the error value "Service unsupported" 414 (see [RFC2205]). 416 In addition, if the MTU field is received with a value smaller 417 than the minimum transfer unit size of the Ethernet frame (e.g. 418 46 bytes for Ethernet V2, 38 bytes for IEEE 802.3), the node MUST 419 generate a PathErr message with the error code "Traffic Control 420 Error" and the error value "Bad Tspec value" (see [RFC2205]). 422 Error processing of the CLASSTYPE object follows rules defined in 423 [RFC4124]. Error processing of the EXTENDED_CLASSTYPE object 424 follows rules defined in [MCOS]. Moreover, an LSR receiving a 425 Path message with the EXTENDED_CLASSTYPE object, which recognizes 426 the object and the particular Class-Type but does detect a 427 mismatch in the index values, MUST send a PathErr message towards 428 the sender with the error code "Extended Class-Type Error" and 429 the error value "Class-Type mismatch" (see [RFC2205]). 431 8. Security Considerations 433 This document introduces no new security considerations to either 434 [RFC3473]. 436 GMPLS security is described in section 11 of [RFC3471] and refers 437 to [RFC3209] for RSVP-TE. Further details of MPLS-TE and GMPLS 438 security can be found in [MPLS-SEC]. 440 9. IANA Considerations 442 IANA maintain registries and sub-registries for RSVP-TE as used 443 by GMPLS. IANA is requested to make allocations from these 444 registries as set out in the following sections. 446 9.1. RSVP Objects Class Types 448 This document introduces two new Class Types for existing RSVP 449 objects. IANA is requested to make allocations from the "Resource 450 ReSerVation Protocol (RSVP) Parameters" registry using the "Class 451 Names, Class Numbers, and Class Types" sub-registry. 453 Class Number Class Name Reference 454 ------------ ----------------------- --------- 455 9 FLOWSPEC [RFC2205] 457 Class Type (C-Type): 459 6 Ethernet SENDER_TSPEC [This.I-D] 461 Class Number Class Name Reference 462 ------------ ----------------------- --------- 463 12 SENDER_TSPEC [RFC2205] 465 Class Type (C-Type): 467 6 Ethernet SENDER_TSPEC [This.I-D] 469 9.2. Ethernet Switching Granularities 471 IANA maintains a registry of GMPLS parameters called "Generalized 472 Multi-Protocol Label Switching (GMPLS) Signaling Parameters". 474 IANA is requested to create a new sub-registry called "Ethernet 475 Switching Granularities" to contain the values that may be 476 carried in the Switching Granularity field of the Ethernet 477 SENDER_TSPEC object. 479 Values shall be assigned as follows: 481 000-239,255 Assigned by IANA via IETF Standards Action 482 240-254 Reserved for Vendor Specific Usage 483 256-65535 Not assigned at this point in time 485 Values 256 through 65535 are not to be assigned at this time. 486 Before any assignments can be made in this range, there MUST be a 487 Standards Action that specifies IANA Considerations that covers 488 the range being assigned. 490 Initial entries in this sub-registry are as follows: 492 Value Switching Granularity Reference 493 ----- -------------------------------------- ---------- 494 0 Provided in signaling. [GMPLS-ESVCS] 495 1 Ethernet Port (for port-based service) [This.I-D] 496 2 Ethernet Frame (for EVC-based service) [This.I-D] 497 255 Reserved Value [This.I-D] 499 9.3. Ethernet Sender TSpec TLVs 501 IANA maintains a registry of GMPLS parameters called "Generalized 502 Multi-Protocol Label Switching (GMPLS) Signaling Parameters". 504 IANA is requested to create a new sub-registry called "Ethernet 505 SENDER_TSPEC TLVs" to contain the TLV type values for TLVs 506 carried in the Ethernet SENDER_TSPEC object. 508 Values shall be assigned as follows: 510 000-239,255 Assigned by IANA via IETF Standards Action 511 240-254 Reserved for Private Use 512 256-65535 Not assigned at this point in time 514 Values 256 through 65535 are not to be assigned at this time. 515 Before any assignments can be made in this range, there MUST be a 516 Standards Action that specifies IANA Considerations that covers 517 the range being assigned. 519 Initial entries in this sub-registry are as follows: 521 Type Description Reference 522 ----- -------------------------------- --------- 523 0 Reserved Value [This.I-D] 524 1 Reserved Value [This.I-D] 525 2 Ethernet Bandwidth Profile [This.I-D] 526 3 Layer 2 Control Processing (L2CP) [This.I-D] 527 255 Reserved Value [This.I-D] 529 9.4. Ethernet Bandwidth Profiles 531 IANA maintains a registry of GMPLS parameters called "Generalized 532 Multi-Protocol Label Switching (GMPLS) Signaling Parameters". 534 IANA is requested to create a new sub-registry called "Ethernet 535 Bandwidth Profiles" to contain bit flags carried in the Ethernet 536 Bandwidth Profile TLV of the Ethernet SENDER_TSPEC object. 538 Bits are to be allocated by IETF Standards Action. Bits are 539 numbered from bit 0 as the low order bit. 541 Bit Hex Description Reference 542 --- ---- -------------------------- ------------- 543 0 0x01 Coupling flag (CF) [This.I-D] 544 1 0x02 Color mode (CM) [This.I-D] 546 10. Acknowledgments 548 Many thanks to Adrian Farrel for his comments. Lou Berger 549 provided the input on control traffic processing. 551 11. References 553 11.1. Normative References 555 [GMPLS-ESVCS] Berger, L., et al., "Generalized MPLS (GMPLS) 556 Support for Metro Ethernet Forum and G.8011 557 Ethernet Services", draft-berger-ccamp-gmpls- 558 ether-svcs, work in progress. 560 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 561 Jamin, "Resource ReSerVation Protocol (RSVP) -- 562 Version 1 Functional Specification", RFC 2205, 563 September 1997. 565 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 566 Services", RFC 2210, September 1997. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 572 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 573 LSP Tunnels", RFC 3209, December 2001. 575 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 576 Switching (GMPLS) Signaling Functional Description", 577 RFC 3471, January 2003. 579 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 580 Switching (GMPLS) Signaling Resource ReserVation 581 Protocol-Traffic Engineering (RSVP-TE) Extensions", 582 RFC 3473, January 2003. 584 [RFC4124] Le Faucheur, F. et al, "Protocol extensions for 585 support of Diff-Serv-aware MPLS Traffic Engineering", 586 RFC 4124, June 2005. 588 [RFC4506] Eisler, M., Ed. "XDR: External Data Representation 589 Standard", RFC 4506, STD 67, May 2006. 591 11.2. Informative References 593 [ETHv2] Digital, Intel, and Xerox, "The Ethernet -- A Local 594 Area Network: Data Link Layer and Physical Layer 595 Specifications", Version 2.0, November 1982. 597 [IEEE802.3] IEEE 802.3 LAN/MAN CSMA/CD (Ethernet) Access 598 Method, IEEE Standard for Information technology- 599 Specific requirements - Part 3: Carrier Sense 600 Multiple Access with Collision Detection (CMSA/CD) 601 Access Method and Physical Layer Specifications, 602 IEEE 802.3-2008. 604 [MEF10.1] The MEF Technical Specification, "Ethernet Services 605 Attributes Phase 2", MEF 10.1, November 2006. 607 [MEF6] The Metro Ethernet Forum, "Ethernet Services 608 Definitions - Phase I", MEF 6, June 2004. 610 [MCOS] Minei, I., et al., "Extensions for Differentiated 611 Services-aware Traffic Engineered LSPs", draft-minei- 612 diffserv-te-multi-class, work in progress. 614 [MPLS-SEC] Fang, L. et al., "Security Framework for MPLS and 615 GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- 616 security-framework, work in progress. 618 Author's Addresses 620 Dimitri Papadimitriou 621 Alcatel-Lucent Bell 622 Copernicuslaan 50 623 B-2018 Antwerpen, Belgium 624 Phone: +32 3 2408491 625 E-mail: dimitri.papadimitriou@alcatel-lucent.be