idnits 2.17.1 draft-ietf-ipfix-data-link-layer-monitoring-08.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 24, 2013) is 3770 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.11' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1BR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Qbg' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.3' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Flow Information Export S. Kashima 3 Internet-Draft NTT 4 Intended status: Standards Track A. Kobayashi, Ed. 5 Expires: June 27, 2014 NTT East 6 P. Aitken 7 Cisco Systems, Inc. 8 December 24, 2013 10 Information Elements for Data Link Layer Traffic Measurement 11 draft-ietf-ipfix-data-link-layer-monitoring-08 13 Abstract 15 This document describes Information Elements related to the data link 16 layer. They are used by the IP Flow Information Export (IPFIX) 17 protocol for encoding measured data link layer traffic information. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 27, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. Extended Ethernet Technology . . . . . . . . . . . . . . . . 4 56 2.1. Wide-Area Ethernet Technology Summary . . . . . . . . . . 4 57 2.2. Virtual Ethernet Technology Summary . . . . . . . . . . . 4 58 3. Information Elements Related to Data Link Layer . . . . . . . 5 59 3.1. Existing Information Elements . . . . . . . . . . . . . . 6 60 3.1.1. dataLinkFrameSize . . . . . . . . . . . . . . . . . . 7 61 3.1.2. dataLinkFrameSection . . . . . . . . . . . . . . . . 7 62 3.2. New Information Elements . . . . . . . . . . . . . . . . 8 63 3.2.1. dataLinkFrameType . . . . . . . . . . . . . . . . . . 9 64 3.2.2. sectionOffset . . . . . . . . . . . . . . . . . . . . 9 65 3.2.3. sectionExportedOctets . . . . . . . . . . . . . . . . 10 66 3.2.4. dot1qServiceInstanceTag . . . . . . . . . . . . . . . 11 67 3.2.5. dot1qServiceInstanceId . . . . . . . . . . . . . . . 11 68 3.2.6. dot1qServiceInstancePriority . . . . . . . . . . . . 11 69 3.2.7. dot1qCustomerSourceMacAddress . . . . . . . . . . . . 12 70 3.2.8. dot1qCustomerDestinationMacAddress . . . . . . . . . 12 71 3.2.9. l2OctetDeltaCount . . . . . . . . . . . . . . . . . . 12 72 3.2.10. postL2OctetDeltaCount . . . . . . . . . . . . . . . . 13 73 3.2.11. postMCastL2OctetDeltaCount . . . . . . . . . . . . . 13 74 3.2.12. l2OctetTotalCount . . . . . . . . . . . . . . . . . . 14 75 3.2.13. postL2OctetTotalCount . . . . . . . . . . . . . . . . 14 76 3.2.14. postMCastL2OctetTotalCount . . . . . . . . . . . . . 15 77 3.2.15. minimumL2TotalLength . . . . . . . . . . . . . . . . 15 78 3.2.16. maximumL2TotalLength . . . . . . . . . . . . . . . . 16 79 3.2.17. droppedL2OctetDeltaCount . . . . . . . . . . . . . . 16 80 3.2.18. droppedL2OctetTotalCount . . . . . . . . . . . . . . 17 81 3.2.19. ignoredL2OctetTotalCount . . . . . . . . . . . . . . 17 82 3.2.20. notSentL2OctetTotalCount . . . . . . . . . . . . . . 17 83 3.2.21. l2OctetDeltaSumOfSquares . . . . . . . . . . . . . . 18 84 3.2.22. l2OctetTotalSumOfSquares . . . . . . . . . . . . . . 18 85 4. Modification of Existing Information Elements Related to 86 Packet Section . . . . . . . . . . . . . . . . . . . . . . . 19 87 4.1. ipHeaderPacketSection . . . . . . . . . . . . . . . . . . 19 88 4.2. ipPayloadPacketSection . . . . . . . . . . . . . . . . . 20 89 4.3. mplsLabelStackSection . . . . . . . . . . . . . . . . . . 21 90 4.4. mplsPayloadPacketSection . . . . . . . . . . . . . . . . 22 91 5. Modification of Existing Information Elements Related to VLAN 92 Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.1. dot1qVlanId . . . . . . . . . . . . . . . . . . . . . . . 23 94 5.2. dot1qPriority . . . . . . . . . . . . . . . . . . . . . . 24 95 5.3. dot1qCustomerVlanId . . . . . . . . . . . . . . . . . . . 24 96 5.4. dot1qCustomerPriority . . . . . . . . . . . . . . . . . . 24 97 6. The relationship between Ethernet header fields and 98 Information Elements . . . . . . . . . . . . . . . . . . . . 25 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 104 10.2. Informative References . . . . . . . . . . . . . . . . . 28 105 Appendix A. Tagged Frame Formats . . . . . . . . . . . . . . . . 29 106 Appendix B. Template Formats Example . . . . . . . . . . . . . . 36 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 109 1. Introduction 111 Ethernet [IEEE802.1D] and VLAN (Virtual LAN) technologies had been 112 used only in Local Area Networks. Recently, they have been used in 113 Wide Area Networks, e.g., L2-VPN services. Accordingly, carrier 114 networks using VLAN technologies have been enhanced to Provider 115 Bridged Network and Provider Backbone Bridged Networks [IEEE802.1Q]. 116 And, Ethernet in data centers has also been enhanced for server 117 virtualization and I/O consolidation. 119 While these innovations provide flexibility, scalability, and 120 mobility to an existing network architecture, they increase the 121 complexity of traffic measurement due to the existence of various 122 Ethernet header formats. To cope with this, a more sophisticated 123 method of traffic measurement is required. 125 IPFIX and PSAMP help to resolve these problems. However, the PSAMP 126 Information Model [RFC5477] and the IPFIX Information Model [RFC7011] 127 don't yet contain enough Information Elements related to data link 128 layer, e.g., Ethernet header forms. This document describes existing 129 and new Information Elements related to data link layers that enable 130 a more sophisticated traffic measurement method. 132 Note that this document does not update [RFC5477] or [RFC7011] 133 because IANA's IPFIX registry [IANA-IPFIX] is the ultimate 134 Information Element reference, per section 1 of [RFC7012]. 136 1.1. Conventions Used in This Document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Extended Ethernet Technology 144 2.1. Wide-Area Ethernet Technology Summary 146 Provider Bridge and Provider Backbone Bridge [IEEE802.1Q], which are 147 standards for Wide-Area Ethernet, are described below. 149 o In Provider Bridge [IEEE802.1Q], there are two VLAN IDs: Service 150 VLAN Identifier (S-VID) and Customer VLAN Identifier (C-VID). 151 S-VID is assigned to an Ethernet frame by a service provider, 152 while C-VID is independently assigned to an Ethernet frame by a 153 customer. Frame switching in a service provider network is based 154 on only S-VID. 156 o In Provider Backbone Bridge [IEEE802.1Q], new Ethernet fields, 157 such as Backbone VLAN Identifier (B-VID) and Backbone Service 158 Instance Identifier (I-SID), are introduced to overcome the 159 limitations on the VLAN identifier space and to isolate the 160 service provider and customer identifier spaces. Frame switching 161 is based on a 12-bit B-VID, and customer identification is based 162 on a 24-bit I-SID. A flexible network design has become possible 163 because network management is separated from customer management. 164 Other Ethernet fields that indicate quality of service (QoS) class 165 are Backbone VLAN priority code point (B-PCP), Backbone VLAN drop 166 eligible indicator (B-DEI), Backbone Service Instance priority 167 code point (I-PCP), and Backbone Service Instance Drop Eligibility 168 Indicator (I-DEI). 170 The Provider Backbone Bridge technologies have enhanced a wide-area 171 Ethernet service from a flat network to a hierarchical network 172 consisting of Provider Bridge Network and Provider Backbone Bridge 173 Network. 175 Frame formats used in Wide-Area Ethernet are shown in Appendix A. 177 2.2. Virtual Ethernet Technology Summary 179 There have been several challenges in the existing virtual switches 180 environment in a data center. One is the lack of network management 181 visibility: limited features on virtual switches makes it difficult 182 to monitor traffic among virtual machines (VMs). Another is the lack 183 of management scalability and flexibility: increasing the number of 184 VMs for multi-tenant causes an increase of the number of virtual 185 switches and of the number of the traffic control policies, which 186 reaches the limitations of network management scalability and 187 flexibility. 189 In this situation, the IEEE 802.1 Working Group is standardizing 190 virtual bridging technologies as Edge Virtual Bridge (EVB) including 191 two kinds of Edge Relay (ER): Virtual Edge Bridge (VEB) and Virtual 192 Edge Port Aggregator (VEPA) [IEEE802.1Qbg]. The VEB is a bridge that 193 provides a bridging among multiple VMs and the external bridging 194 environment. The VEPA is a bridge-like device on a host that 195 forwards all internal traffic to the adjacent EVB bridge and then 196 distributes any traffic received from the adjacent EVB bridge to VMs. 197 The VEPA makes all the VM-to-VM traffic visible to EVB bridge so that 198 the traffic can be monitored and so the EVB bridge can apply 199 filtering to the traffic. 201 To improve flexibility, a virtual link between a host system and EVB 202 bridge is standardized as S-channel. S-channel allows a bridge to 203 treat the traffic in the virtual link as if it comes in on a separate 204 port. For example, in the host, an S-channel may be attached to a 205 VEB or a VEPA or directly an internal port in order to apply each 206 port-based filtering rules to the traffic. S-channel over the link 207 between a host and its adjacent bridge uses S-TAG [IEEE802.1Q]. When 208 S-channel is in use, frames on the link carry an S-TAG to identify 209 the S-channel. 211 On the other hand, Bridge Port Extension emulates single Extended 212 Bridge from multiple physical switches and virtual switches, and 213 simplifies network management. Also, it solves the lack of network 214 management visibility by forwarding all traffic into a central 215 Controlling Bridge using E-channel. E-channel over the link between 216 a Bridge Port extender and a Controlling Bridge uses E-TAG defined in 217 [IEEE802.1BR]. 219 Traffic monitoring over S-channel and E-channel is required in order 220 to get visibility of VM-to-VM traffic, and visibility of each 221 channel's traffic on a virtual link. 223 Frame formats with E-TAG used in E-channel and S-TAG used in 224 S-channel are shown in Appendix A. Though these frames carry special 225 tags while on the link, those tags identify a virtual port (or for 226 multicast in the downstream direction, a set of virtual ports) to 227 which they are destined. These tag values only have local meaning 228 and the flow would be reported as sent and arriving on the 229 corresponding virtual ports. Therefore, IPFIX does not need to 230 monitor data based on these tags. 232 3. Information Elements Related to Data Link Layer 234 The following Information Elements whose ElementId are from 312 to 235 TBD03 are necessary for enabling the IPFIX and PSAMP traffic 236 measurement for data link layer, which is not limited to Ethernet 237 because the method can be applied to other data link protocols as 238 well. 240 The following Information Elements whose ElementId are from TBD04 to 241 TBD08 are necessary for enabling the IPFIX and PSAMP traffic 242 measurement for [IEEE802.1Q]. 244 The following Information Elements whose ElementId are from TBD09 to 245 TBD22 are octet counter or packet length for layer 2, and are 246 necessary for enabling the IPFIX and PSAMP traffic measurement for 247 data link layer. 249 +-----+------------------------------------+ 250 | ID | Name | 251 +-----+------------------------------------+ 252 | 312 | dataLinkFrameSize | 253 | 315 | dataLinkFrameSection | 254 |TBD01| dataLinkFrameType | 255 |TBD02| sectionOffset | 256 |TBD03| sectionExportedOctets | 257 |TBD04| dot1qServiceInstanceTag | 258 |TBD05| dot1qServiceInstanceId | 259 |TBD06| dot1qServiceInstancePriority | 260 |TBD07| dot1qCustomerSourceMacAddress | 261 |TBD08| dot1qCustomerDestinationMacAddress | 262 |TBD09| l2OctetDeltaCount | 263 |TBD10| postL2OctetDeltaCount | 264 |TBD11| postMCastL2OctetDeltaCount | 265 |TBD12| l2OctetTotalCount | 266 |TBD13| postL2OctetTotalCount | 267 |TBD14| postMCastL2OctetTotalCount | 268 |TBD15| minimumL2TotalLength | 269 |TBD16| maximumL2TotalLength | 270 |TBD17| droppedL2OctetDeltaCount | 271 |TBD18| droppedL2OctetTotalCount | 272 |TBD19| ignoredL2OctetTotalCount | 273 |TBD20| notSentL2OctetTotalCount | 274 |TBD21| l2OctetDeltaSumOfSquares | 275 |TBD22| l2OctetTotalSumOfSquares | 276 +-----+------------------------------------+ 278 Table 1: Information Elements related to data link layer 280 3.1. Existing Information Elements 282 Some existing Information Elements are required for data link layer 283 export. Their details are reproduced here from IANA's IPFIX registry 284 [IANA-IPFIX], except for additions as marked *. 286 Section 3.1.1 introduces the missing Data Type Semantics for the 287 dataLinkFrameSize Information Element which is held to be an 288 interoperable change per section 5.2 subsection 4 of [RFC7013]. 290 Section 3.1.2 extends the definition of the 291 dataLinkFrameSection Information Element with reference to the new 292 sectionOffset Information Element, which is also an interoperable 293 change per section 5.2 subsection 4 of [RFC7013]. 295 Therefore these changes introduce no backwards compatibility issues. 297 Per section 5.2 of [RFC7013], for each of these changes, 298 [RFCEDITOR:thisRFC] is to be appended to the requestor in IANA's 299 IPFIX registry [IANA-IPFIX], the Information Elelement's revision 300 number is to be incremented by one, and the Information Element's 301 revision date column is to be updated. 303 3.1.1. dataLinkFrameSize 305 Description: 307 This Information Element specifies the length of the selected data 308 link frame. 310 The data link layer is defined in [ISO_IEC.7498-1_1994]. 312 Abstract Data Type: unsigned16 314 *Data Type Semantics: quantity* 316 ElementId: 312 318 Status: current 320 3.1.2. dataLinkFrameSection 322 Description: 324 This Information Element carries n octets from the data link frame 325 of a selected frame, starting sectionOffset octets into the frame. 327 *However, if no sectionOffset field corresponding to this 328 Information Element is present then a sectionOffset of zero 329 applies, and the octets MUST be from the start of the data link 330 frame.* 331 The sectionExportedOctets expresses how much data was observed, 332 while the remainder is padding. 334 When the sectionExportedOctets field corresponding to this 335 Information Element exists, this Information Element MAY have a 336 fixed length and MAY be padded, or MAY have a variable length. 338 When the sectionExportedOctets field corresponding to this 339 Information Element does not exist, this Information Element 340 SHOULD have a variable length and MUST NOT be padded. In this 341 case, the size of the exported section may be constrained due to 342 limitations in the IPFIX protocol. 344 Further Information Elements, i.e., dataLinkFrameType and 345 dataLinkFrameSize, are needed to specify the data link type and 346 the size of the data link frame of this Information Element. A 347 set of these Information Elements MAY be contained in a structured 348 data type, as expressed in [RFC6313]. Or a set of these 349 Information Elements MAY be contained in one Flow Record as shown 350 in Appendix B of [RFCEDITOR:thisRFC]. 352 The data link layer is defined in [ISO_IEC.7498-1_1994]. 354 Abstract Data Type: octetArray 356 ElementId: 315 358 Status: current 360 3.2. New Information Elements 362 The following new Information Elements are added for data link layer 363 monitoring. 365 In IANA's IPFIX registry [IANA-IPFIX], the Requester is to be set to 366 [RFCEDITOR:thisRFC], the Information Element's Revision is to be set 367 to zero, and the Information Element's Date set to the date upon 368 which the new Information Elements are added to the registry. All 369 other columns which are not explicitly mentioned below (eg, Units, 370 Range, References) are not applicable, and are to be left blank since 371 the registry does not explicitly record "not applicable". 373 3.2.1. dataLinkFrameType 375 Description: 377 This Information Element specifies the type of the selected data 378 link frame. 380 The following data link types are defined here. 382 - 0x01 IEEE802.3 ETHERNET [IEEE802.3] 384 - 0x02 IEEE802.11 MAC Frame format [IEEE802.11] 386 Further values may be assigned by IANA. Note that the assigned 387 values are bits so that multiple observations can be OR'd 388 together. 390 The data link layer is defined in [ISO_IEC.7498-1_1994]. 392 Abstract Data Type: unsigned16 394 Data Type Semantics: flags 396 ElementId: TBD01 398 Status: current 400 3.2.2. sectionOffset 402 Description: 404 This Information Element specifies the offset of the packet 405 section (e.g., dataLinkFrameSection, ipHeaderPacketSection, 406 ipPayloadPacketSection, mplsLabelStackSection and 407 mplsPayloadPacketSection). If this Information Element is 408 omitted, it defaults to zero (ie, no offset). 410 If multiple sectionOffset Information Elements are specified 411 within a single Template, then they apply to the packet section 412 Information Elements in order: the first sectionOffset applies to 413 the first packet section, the second to the second, and so on. 414 Note that the "closest" sectionOffset and packet section 415 Information Elements within a given Template are not necessarily 416 related. If there are fewer sectionOffset Information Elements 417 than packet section Information Elements then subsequent packet 418 section Information Elements have no offset, i.e. a sectionOffset 419 of zero applies to those packet section Information Elements. If 420 there are more sectionOffset Information Elements than the number 421 of packet section Information Elements, then the additional 422 sectionOffset Information Elements are meaningless. 424 Abstract Data Type: unsigned16 426 Data Type Semantics: quantity 428 ElementId: TBD02 430 Status: current 432 3.2.3. sectionExportedOctets 434 Description: 436 This Information Element specifies the observed length of the 437 packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, 438 ipPayloadPacketSection, mplsLabelStackSection and 439 mplsPayloadPacketSection) when padding is used. 441 The packet section may be of a fixed size larger than the 442 sectionExportedOctets. In this case, octets in the packet section 443 beyond the sectionExportedOctets MUST follow the [RFC7011] rules 444 for padding (ie, be composed of zero (0) valued octets). 446 Abstract Data Type: unsigned16 448 Data Type Semantics: quantity 450 ElementId: TBD03 452 Status: current 454 3.2.4. dot1qServiceInstanceTag 456 Description: 458 This Information Element, which is 16 octets long, represents the 459 Backbone Service Instance Tag (I-TAG) Tag Control Information 460 (TCI) field of an Ethernet frame as described in [IEEE802.1Q]. It 461 encodes the Backbone Service Instance Priority Code Point (I-PCP), 462 Drop Eligible Indicator (I-DEI), Use Customer Addresses (UCA), 463 Backbone Service Instance Identifier (I-SID), Encapsulated 464 Customer Destination Address (C-DA), Encapsulated Customer Source 465 Address (C-SA) and reserved fields. The structure and semantics 466 within the Tag Control Information field are defined in 467 [IEEE802.1Q]. 469 Abstract Data Type: octetArray 471 Data Type Semantics: identifier 473 ElementId: TBD04 475 Status: current 477 3.2.5. dot1qServiceInstanceId 479 Description: 481 The value of the 24-bit Backbone Service Instance Identifier 482 (I-SID) portion of the Backbone Service Instance Tag (I-TAG) Tag 483 Control Information (TCI) field of an Ethernet frame as described 484 in [IEEE802.1Q]. 486 Abstract Data Type: unsigned32 488 Data Type Semantics: identifier 490 ElementId: TBD05 492 Status: current 494 3.2.6. dot1qServiceInstancePriority 496 Description: 498 The value of the 3-bit Backbone Service Instance Priority Code 499 Point (I-PCP) portion of the Backbone Service Instance Tag (I-TAG) 500 Tag Control Information (TCI) field of an Ethernet frame as 501 described in [IEEE802.1Q]. 503 Abstract Data Type: unsigned8 505 Data Type Semantics: identifier 507 ElementId: TBD06 509 Status: current 511 3.2.7. dot1qCustomerSourceMacAddress 513 Description: 515 The value of the Encapsulated Customer Source Address (C-SA) 516 portion of the Backbone Service Instance Tag (I-TAG) Tag Control 517 Information (TCI) field of an Ethernet frame as described in 518 [IEEE802.1Q]. 520 Abstract Data Type: macAddress 522 Data Type Semantics: identifier 524 ElementId: TBD07 526 Status: current 528 3.2.8. dot1qCustomerDestinationMacAddress 530 Description: 532 The value of the Encapsulated Customer Destination Address (C-DA) 533 portion of the Backbone Service Instance Tag (I-TAG) Tag Control 534 Information (TCI) field of an Ethernet frame as described in 535 [IEEE802.1Q]. 537 Abstract Data Type: macAddress 539 Data Type Semantics: identifier 541 ElementId: TBD08 543 Status: current 545 3.2.9. l2OctetDeltaCount 547 Description: 549 The number of layer 2 octets since the previous report (if any) in 550 incoming packets for this Flow at the Observation Point. The 551 number of octets includes layer 2 header(s) and layer 2 payload. 553 This Information Element is the layer 2 version of octetDeltaCount 554 (ElementId #1) in [RFC5477]. 556 Abstract Data Type: unsigned64 558 Data Type Semantics: deltaCounter 560 ElementId: TBD09 562 Status: current 564 Units: octets 566 3.2.10. postL2OctetDeltaCount 568 Description: 570 The definition of this Information Element is identical to the 571 definition of Information Element 'l2OctetDeltaCount', except that 572 it reports a potentially modified value caused by a middlebox 573 function after the packet passed the Observation Point. 575 This Information Element is the layer 2 version of 576 postOctetDeltaCount (ElementId #23) in [RFC5477]. 578 Abstract Data Type: unsigned64 580 Data Type Semantics: deltaCounter 582 ElementId: TBD10 584 Status: current 586 Units: octets 588 3.2.11. postMCastL2OctetDeltaCount 590 Description: 592 The number of layer 2 octets since the previous report (if any) in 593 outgoing multicast packets sent for packets of this Flow by a 594 multicast daemon within the Observation Domain. This property 595 cannot necessarily be observed at the Observation Point, but may 596 be retrieved by other means. The number of octets includes layer 597 2 header(s) and layer 2 payload. 599 This Information Element is the layer 2 version of 600 postMCastOctetDeltaCount (ElementId #20) in [RFC5477]. 602 Abstract Data Type: unsigned64 604 Data Type Semantics: deltaCounter 606 ElementId: TBD11 608 Status: current 610 Units: octets 612 3.2.12. l2OctetTotalCount 614 Description: 616 The total number of layer 2 octets in incoming packets for this 617 Flow at the Observation Point since the Metering Process 618 (re-)initialization for this Observation Point. The number of 619 octets includes layer 2 header(s) and layer 2 payload. 621 This Information Element is the layer 2 version of octetTotalCount 622 (ElementId #85) in [RFC5477]. 624 Abstract Data Type: unsigned64 626 Data Type Semantics: totalCounter 628 ElementId: TBD12 630 Status: current 632 Units: octets 634 3.2.13. postL2OctetTotalCount 636 Description: 638 The definition of this Information Element is identical to the 639 definition of Information Element 'l2OctetTotalCount', except that 640 it reports a potentially modified value caused by a middlebox 641 function after the packet passed the Observation Point. 643 This Information Element is the layer 2 version of 644 postOctetTotalCount (ElementId #171) in [RFC5477]. 646 Abstract Data Type: unsigned64 648 Data Type Semantics: totalCounter 650 ElementId: TBD13 652 Status: current 654 Units: octets 656 3.2.14. postMCastL2OctetTotalCount 658 Description: 660 The total number of layer 2 octets in outgoing multicast packets 661 sent for packets of this Flow by a multicast daemon in the 662 Observation Domain since the Metering Process (re-)initialization. 663 This property cannot necessarily be observed at the Observation 664 Point, but may be retrieved by other means. The number of octets 665 includes layer 2 header(s) and layer 2 payload. 667 This Information Element is the layer 2 version of 668 postMCastOctetTotalCount (ElementId #175) in [RFC5477]. 670 Abstract Data Type: unsigned64 672 Data Type Semantics: totalCounter 674 ElementId: TBD14 676 Status: current 678 Units: octets 680 3.2.15. minimumL2TotalLength 682 Description: 684 Layer 2 length of the smallest packet observed for this Flow. The 685 packet length includes the layer 2 header(s) length and the layer 686 2 payload length. 688 This Information Element is the layer 2 version of 689 minimumIpTotalLength (ElementId #25) in [RFC5477]. 691 Abstract Data Type: unsigned64 693 ElementId: TBD15 695 Status: current 697 Units: octets 699 3.2.16. maximumL2TotalLength 701 Description: 703 Layer 2 length of the largest packet observed for this Flow. The 704 packet length includes the layer 2 header(s) length and the layer 705 2 payload length. 707 This Information Element is the layer 2 version of 708 maximumIpTotalLength (ElementId #26) in [RFC5477]. 710 Abstract Data Type: unsigned64 712 ElementId: TBD16 714 Status: current 716 Units: octets 718 3.2.17. droppedL2OctetDeltaCount 720 Description: 722 The number of layer 2 octets since the previous report (if any) in 723 packets of this Flow dropped by packet treatment. The number of 724 octets includes layer 2 header(s) and layer 2payload. 726 This Information Element is the layer 2 version of 727 droppedOctetDeltaCount (ElementId #132) in [RFC5477]. 729 Abstract Data Type: unsigned64 731 Data Type Semantics: deltaCounter 733 ElementId: TBD17 735 Status: current 737 Units: octets 739 3.2.18. droppedL2OctetTotalCount 741 Description: 743 The total number of octets in observed layer 2 packets (including 744 the layer 2 header) that were dropped by packet treatment since 745 the (re-)initialization of the Metering Process. 747 This Information Element is the layer 2 version of 748 droppedOctetTotalCount (ElementId #134) in [RFC5477]. 750 Abstract Data Type: unsigned64 752 Data Type Semantics: totalCounter 754 ElementId: TBD18 756 Status: current 758 Units: octets 760 3.2.19. ignoredL2OctetTotalCount 762 Description: 764 The total number of octets in observed layer 2 packets (including 765 the layer 2 header) that the Metering Process did not process 766 since the (re-)initialization of the Metering Process. 768 This Information Element is the layer 2 version of 769 ignoredOctetTotalCount (ElementId #165) in [RFC5477]. 771 Abstract Data Type: unsigned64 773 Data Type Semantics: totalCounter 775 ElementId: TBD19 777 Status: current 779 Units: octets 781 3.2.20. notSentL2OctetTotalCount 783 Description: 785 The total number of octets in observed layer 2 packets (including 786 the layer 2 header) that the Metering Process did not process 787 since the (re-)initialization of the Metering Process. 789 This Information Element is the layer 2 version of 790 notSentOctetTotalCount (ElementId #168) in [RFC5477]. 792 Abstract Data Type: unsigned64 794 Data Type Semantics: totalCounter 796 ElementId: TBD20 798 Status: current 800 Units: octets 802 3.2.21. l2OctetDeltaSumOfSquares 804 Description: 806 The sum of the squared numbers of layer 2 octets per incoming 807 packet since the previous report (if any) for this Flow at the 808 Observation Point. The number of octets includes layer 2 809 header(s) and layer 2 payload. 811 This Information Element is the layer 2 version of 812 octetDeltaSumOfSquares (ElementId #198) in [RFC5477]. 814 Abstract Data Type: unsigned64 816 Data Type Semantics: deltaCounter 818 ElementId: TBD21 820 Status: current 822 Units: octets 824 3.2.22. l2OctetTotalSumOfSquares 826 Description: 828 The total sum of the squared numbers of layer 2 octets in incoming 829 packets for this Flow at the Observation Point since the Metering 830 Process (re-)initialization for this Observation Point. The 831 number of octets includes layer 2 header(s) and layer 2 payload. 833 This Information Element is the layer 2 version of 834 octetTotalSumOfSquares (ElementId #199) in [RFC5477]. 836 Abstract Data Type: unsigned64 838 Data Type Semantics: totalCounter 840 ElementId: TBD22 842 Status: current 844 Units: octets 846 4. Modification of Existing Information Elements Related to Packet 847 Section 849 The new Information Elements related to packet section (ie, 850 sectionOffset and sectionExportedOctets) can be applied to not only 851 dataLinkFrameSection but also all kinds of packet section (ie, 852 ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, 853 and mplsPayloadPacketSection defined in [RFC5477]). Therefore 854 existing Information Elements Descriptions should be modified as 855 follows: 857 4.1. ipHeaderPacketSection 859 This Information Element is defined in [RFC5477]. The description is 860 updated from [RFC5477]. 862 Description: 864 This Information Element carries a series of n octets from the IP 865 header of a sampled packet, starting sectionOffset octets into the 866 IP header. 868 However, if no sectionOffset field corresponding to this 869 Information Element is present then a sectionOffset of zero 870 applies, and the octets MUST be from the start of the IP header. 872 With sufficient length, this element also reports octets from the 873 IP payload. However full packet capture of arbitrary packet 874 streams is explicitly out of scope per the Security Considerations 875 section of [RFC5477] and [RFC2804]. 877 The sectionExportedOctets expresses how much data was exported, 878 while the remainder is padding. 880 When the sectionExportedOctets field corresponding to this 881 Information Element exists, this Information Element MAY have a 882 fixed length and MAY be padded, or MAY have a variable length. 884 When the sectionExportedOctets field corresponding to this 885 Information Element does not exist, this Information Element 886 SHOULD have a variable length and MUST NOT be padded. In this 887 case, the size of the exported section may be constrained due to 888 limitations in the IPFIX protocol. 890 Abstract Data Type: octetArray 892 ElementId: 313 894 Status: current 896 4.2. ipPayloadPacketSection 898 This Information Element is defined in [RFC5477]. The description is 899 updated from [RFC5477]. 901 Description: 903 This Information Element carries a series of n octets from the IP 904 payload of a sampled packet, starting sectionOffset octets into 905 the IP payload. 907 However, if no sectionOffset field corresponding to this 908 Information Element is present then a sectionOffset of zero 909 applies, and the octets MUST be from the start of the IP payload. 911 The IPv4 payload is that part of the packet that follows the IPv4 912 header and any options, which [RFC0791] refers to as "data" or 913 "data octets". For example, see the examples in [RFC0791], 914 Appendix A. 916 The IPv6 payload is the rest of the packet following the 40-octet 917 IPv6 header. Note that any extension headers present are 918 considered part of the payload. See [RFC2460] for the IPv6 919 specification. 921 The sectionExportedOctets expresses how much data was observed, 922 while the remainder is padding. 924 When the sectionExportedOctets field corresponding to this 925 Information Element exists, this Information Element MAY have a 926 fixed length and MAY be padded, or MAY have a variable length. 928 When the sectionExportedOctets field corresponding to this 929 Information Element does not exist, this Information Element 930 SHOULD have a variable length and MUST NOT be padded. In this 931 case, the size of the exported section may be constrained due to 932 limitations in the IPFIX protocol. 934 Abstract Data Type: octetArray 936 ElementId: 314 938 Status: current 940 4.3. mplsLabelStackSection 942 This Information Element is defined in [RFC5477]. The description is 943 updated from [RFC5477]. 945 Description: 947 This Information Element carries a series of n octets from the 948 MPLS label stack of a sampled packet, starting sectionOffset 949 octets into the MPLS label stack. 951 However, if no sectionOffset field corresponding to this 952 Information Element is present then a sectionOffset of zero 953 applies, and the octets MUST be from the head of the MPLS label 954 stack. 956 With sufficient length, this element also reports octets from the 957 MPLS payload. However full packet capture of arbitrary packet 958 streams is explicitly out of scope per the Security Considerations 959 section of [RFC5477] and [RFC2804]. 961 See [RFC3031] for the specification of MPLS packets. 963 See [RFC3032] for the specification of the MPLS label stack. 965 The sectionExportedOctets expresses how much data was observed, 966 while the remainder is padding. 968 When the sectionExportedOctets field corresponding to this 969 Information Element exists, this Information Element MAY have a 970 fixed length and MAY be padded, or MAY have a variable length. 972 When the sectionExportedOctets field corresponding to this 973 Information Element does not exist, this Information Element 974 SHOULD have a variable length and MUST NOT be padded. In this 975 case, the size of the exported section may be constrained due to 976 limitations in the IPFIX protocol. 978 Abstract Data Type: octetArray 980 ElementId: 316 982 Status: current 984 4.4. mplsPayloadPacketSection 986 This Information Element is defined in [RFC5477]. The description is 987 updated from [RFC5477]. 989 Description: 991 The mplsPayloadPacketSection carries a series of n octets from the 992 MPLS payload of a sampled packet, starting sectionOffset octets 993 into the MPLS payload, being data that follows immediately after 994 the MPLS label stack. 996 However, if no sectionOffset field corresponding to this 997 Information Element is present then a sectionOffset of zero 998 applies, and the octets MUST be from the start of the MPLS 999 payload. 1001 See [RFC3031] for the specification of MPLS packets. 1003 See [RFC3032] for the specification of the MPLS label stack. 1005 The sectionExportedOctets expresses how much data was observed, 1006 while the remainder is padding. 1008 When the sectionExportedOctets field corresponding to this 1009 Information Element exists, this Information Element MAY have a 1010 fixed length and MAY be padded, or MAY have a variable length. 1012 When the sectionExportedOctets field corresponding to this 1013 Information Element does not exist, this Information Element 1014 SHOULD have a variable length and MUST NOT be padded. In this 1015 case, the size of the exported section may be constrained due to 1016 limitations in the IPFIX protocol. 1018 Abstract Data Type: octetArray 1020 ElementId: 317 1022 Status: current 1024 5. Modification of Existing Information Elements Related to VLAN Tag 1026 The traffic measurement using IPFIX and PSAMP for a Provider Backbone 1027 Bridged Network requires the Information Elements related to Backbone 1028 Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG). The set 1029 of Information Elements related to I-TAG is added in section 3, 1030 because I-TAG structure and semantics are different from that of 1031 Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG). The set of 1032 Information Elements related to B-TAG reuses the existing Information 1033 Elements, because B-TAG structure and semantics are identical to that 1034 of C-TAG and S-TAG. This section modifies existing Descriptions and 1035 Reference related to C-TAG and S-TAG as follows: 1037 5.1. dot1qVlanId 1039 Description: 1041 The value of the 12-bit VLAN Identifier portion of the Tag Control 1042 Information field of an Ethernet frame. The structure and 1043 semantics within the Tag Control Information field are defined in 1044 [IEEE802.1Q]. In Provider Bridged Networks, it represents the 1045 Service VLAN identifier in the S-TAG Tag Control Information (TCI) 1046 field or the Customer VLAN identifier in the C-TAG Tag Control 1047 Information (TCI) field as described in [IEEE802.1Q]. In Provider 1048 Backbone Bridged Networks, it represents the Backbone VLAN 1049 identifier in the B-TAG Tag Control Information (TCI) field as 1050 described in [IEEE802.1Q]. In a virtual link between a host 1051 system and EVB bridge, it represents the Service VLAN identifier 1052 indicating S-channel as described in [IEEE802.1Qbg]. 1054 In the case of multi-tagged frame, it represents the outer tag's 1055 VLAN identifier except for I-TAG. 1057 Abstract Data Type: unsigned16 1059 Data Type Semantics: identifier 1061 ElementId: 243 1063 Status: current 1065 Reference: 1067 (1) [IEEE802.1Q] 1069 (2) [IEEE802.1Qbg] 1071 5.2. dot1qPriority 1073 Description: 1075 The value of the 3-bit User Priority portion of the Tag Control 1076 Information field of an Ethernet frame. The structure and 1077 semantics within the Tag Control Information field are defined in 1078 [IEEE802.1Q]. In the case of multi-tagged frame, it represents 1079 the 3-bit Priority Code Point (PCP) portion of the outer tag's Tag 1080 Control Information (TCI) field as described in [IEEE802.1Q] 1081 except for I-TAG. 1083 Abstract Data Type: unsigned8 1085 Data Type Semantics: identifier 1087 ElementId: 244 1089 Status: current 1091 Reference: 1093 (1) [IEEE802.1Q] 1095 5.3. dot1qCustomerVlanId 1097 Description: 1099 The value represents the Customer VLAN identifier in the C-TAG Tag 1100 Control Information (TCI) field as described in [IEEE802.1Q]. 1102 Abstract Data Type: unsigned16 1104 Data Type Semantics: identifier 1106 ElementId: 245 1108 Status: current 1110 Reference: 1112 (1) [IEEE802.1Q] 1114 5.4. dot1qCustomerPriority 1116 Description: 1118 The value represents the 3-bit Priority Code Point (PCP) portion 1119 of the C-TAG Tag Control Information (TCI) field as described in 1120 [IEEE802.1Q]. 1122 Abstract Data Type: unsigned8 1124 Data Type Semantics: identifier 1126 ElementId: 246 1128 Status: current 1130 Reference: 1132 (1) [IEEE802.1Q] 1134 6. The relationship between Ethernet header fields and Information 1135 Elements 1137 The following figures shows summary of various Ethernet header fields 1138 and the Informational Elements which would be used to represent each 1139 of the fields. 1141 <-- 6 --> <-- 6 --> <-- 4 --> <---- 2 ----> 1142 +---------+---------+---------+-------------+ 1143 | | | | | 1144 | C-DA | C-SA | C-TAG | Length/Type | 1145 | a | b | c | d | 1146 +---------+---------+---------+-------------+ 1148 a.(Information Element) destinationMacAddress (80) 1149 b.(Information Element) sourceMacAddress (56) 1150 c.(Information Elements) dot1qVlanId (243), dot1qPriority (244) 1151 d.(Information Element) ethernetType (256) 1153 Figure 1: Customer tagged frame header fields 1155 <-- 6 --> <-- 6 --> <-- 4 --> <-- 4 --> <---- 2 ----> 1156 +---------+---------+---------+---------+-------------+ 1157 | | | | | | 1158 | C-DA | C-SA | S-TAG | C-TAG | Length/Type | 1159 | a | b | c | d | e | 1160 +---------+---------+---------+---------+-------------+ 1162 a.(Information Element) destinationMacAddress (80) 1163 b.(Information Element) sourceMacAddress (56) 1164 c.(Information Elements) dot1qVlanId (243), dot1qPriority (244) 1165 d.(Information Elements) dot1qCustomerVlanId (245), 1166 dot1qCustomerPriority (246) 1167 e.(Information Element) ethernetType (256) 1169 Figure 2: Service tagged frame header fields 1171 <-- 6 --> <-- 6 --> <-- 4 --> <--- 16 ---> <-- 4 --> <---- 2 ----> 1172 +---------+---------+---------+------------+---------+-------------+ 1173 | | | | | | | 1174 | B-DA | B-SA | B-TAG | I-TAG | C-TAG | Length/Type | 1175 | a | b | c | d | e | f | 1176 +---------+---------+---------+------------+---------+-------------+ 1178 a.(Information Element) destinationMacAddress (80) 1179 b.(Information Element) sourceMacAddress (56) 1180 c.(Information Elements) dot1qVlanId (243, dot1qPriority (244) 1181 d.(Information Elements) dot1qServiceInstanceTag (TBD04), or 1182 a set of dot1qServiceInstanceId (TBD05), 1183 dot1qServiceInstancePriority (TBD06), 1184 dot1qCustomerSourceMacAddress (TBD07) 1185 dot1qCustomerDestinationMacAddress (TBD08), 1186 e.(Information Elements) dot1qCustomerVlanId (245), 1187 dot1qCustomerPriority (246) 1188 f.(Information Element) ethernetType (256) 1190 Figure 3: Backbone VLAN tagged frame header fields 1192 7. Security Considerations 1194 Reporting more granular data may increase the risk of DoS attacks 1195 against a Collector. Protection against DoS Attacks is discussed in 1196 section 11.4 of [RFC7011]. 1198 The recommendations in this document do not otherwise introduce any 1199 additional security issues beyond those already mentioned in 1200 [RFC7011] and [RFC5477]. 1202 8. IANA Considerations 1204 RFCEDITOR: please assign TBDnn throughout this document. 1206 This document requests that existing IPFIX Information Elements 1207 [IANA-IPFIX] are modified as indicated in sections 3.1, 4, and 5 1208 above. 1210 Per section 5.2 of [RFC7013], for each of these changes, 1211 [RFCEDITOR:thisRFC] is to be appended to the requestor in IANA's 1212 IPFIX registry [IANA-IPFIX], the Information Elelement's revision 1213 number is to be incremented by one, and the Information Element's 1214 revision date column is to be updated. 1216 This document requests that new IPFIX Information Elements 1217 [IANA-IPFIX] are allocated as shown in section 3.2 above. 1219 9. Acknowledgments 1221 Thanks to Brian Trammell and the IPFIX working group participants who 1222 contributed to mailing-list discussions throughout the development of 1223 this document, and especially to Pat Thaler for her help with the 1224 IEEE 802 aspects of this work. 1226 10. References 1228 10.1. Normative References 1230 [IEEE802.11] 1231 IEEE Computer Society, "IEEE Standard for Information 1232 technology. Telecommunications and information exchange 1233 between systems Local and metropolitan area networks. 1234 Specific requirements Part 11: Wireless LAN Medium Access 1235 Control (MAC) and Physical Layer (PHY) Specifications", 1236 IEEE Std 802.11-2012, March 2012. 1238 [IEEE802.1BR] 1239 IEEE Computer Society, "IEEE Standard for Local and 1240 metropolitan area networks: Virtual Bridged Local Area 1241 Networks: Bridge Port Extension", IEEE Std 802.1BR-2012, 1242 July 2012. 1244 [IEEE802.1Q] 1245 IEEE Computer Society, "IEEE Standard for Local and 1246 metropolitan area networks: Media Access Control (MAC) 1247 Bridges and Virtual Bridged Local Area Networks", IEEE Std 1248 802.1Q-2011, August 2011. 1250 [IEEE802.1Qbg] 1251 IEEE Computer Society, "IEEE Standard for Local and 1252 metropolitan area networks: Media Access Control (MAC) 1253 Bridges and Virtual Bridged Local Area Networks: Amendment 1254 21: Edge Virtual Bridging", IEEE Std 802.1Qbg-2012, July 1255 2012. 1257 [IEEE802.3] 1258 IEEE Computer Society, "IEEE Standard for Ethernet", IEEE 1259 Std 802.3-2012, December 2012. 1261 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1262 1981. 1264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1265 Requirement Levels", BCP 14, RFC 2119, March 1997. 1267 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1268 (IPv6) Specification", RFC 2460, December 1998. 1270 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1271 Label Switching Architecture", RFC 3031, January 2001. 1273 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1274 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1275 Encoding", RFC 3032, January 2001. 1277 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1278 Carle, "Information Model for Packet Sampling Exports", 1279 RFC 5477, March 2009. 1281 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 1282 "Export of Structured Data in IP Flow Information Export 1283 (IPFIX)", RFC 6313, July 2011. 1285 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 1286 the IP Flow Information Export (IPFIX) Protocol for the 1287 Exchange of Flow Information", STD 77, RFC 7011, September 1288 2013. 1290 10.2. Informative References 1292 [IANA-IPFIX] 1293 Internet Assigned Numbers Authority, "IANA IPFIX 1294 Information Element Registry", 1295 http://www.iana.org/assignments/ipfix/ipfix.xhtml. 1297 [IEEE802.1D] 1298 IEEE Computer Society, "IEEE Standard for Local and 1299 metropolitan area networks: Media Access Control (MAC) 1300 Bridges", IEEE Std 802.1D-2004, June 2004. 1302 [ISO_IEC.7498-1_1994] 1303 International Organization for Standardization, 1304 "Information technology -- Open Systems Interconnection -- 1305 Basic Reference Model: The Basic Mode", ISO Standard 1306 7498-1:1994, June 1996. 1308 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 1309 2000. 1311 [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow 1312 Information Export (IPFIX)", RFC 7012, September 2013. 1314 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 1315 Reviewers of IP Flow Information Export (IPFIX) 1316 Information Elements", BCP 184, RFC 7013, September 2013. 1318 Appendix A. Tagged Frame Formats 1320 0 1 2 3 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | C-DA | 1324 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | | | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1327 | C-SA | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Length/Type | | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1331 | | 1332 ~ Customer Data ~ 1333 ~ ~ 1334 | | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 Figure A-1: Untagged frame format 1339 0 1 2 3 1340 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 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | C-DA | 1343 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | | | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1346 | C-SA | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | C-TAG TPID=0x8100 |C-PCP|C| C-VID | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Length/Type | | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1352 | | 1353 ~ Customer Data ~ 1354 ~ ~ 1355 | | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 Figure A-2: C-TAG tagging frame format 1360 0 1 2 3 1361 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 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | C-DA | 1364 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | | | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1367 | C-SA | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | S-TAG TPID=0x88a8 |S-PCP|D| S-VID | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Length/Type | | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1373 | | 1374 ~ Customer Data ~ 1375 ~ ~ 1376 | | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Figure A-3: S-TAG tagging frame format in Provider Bridged Networks 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | C-DA | 1385 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | | | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1388 | C-SA | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | S-TAG TPID=0x88a8 |S-PCP|D| S-VID | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | C-TAG TPID=0x8100 |C-PCP|C| C-VID | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Length/Type | | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1396 | | 1397 ~ Customer Data ~ 1398 ~ ~ 1399 | | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 Figure A-4: S-TAG and C-TAG tagging frame format in Provider Bridged 1403 Networks 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | B-DA | 1409 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | | | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1412 | B-SA | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | B-TAG TPID=0x88a8 |B-PCP|D| B-VID | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | I-TAG TPID=0x88e7 |I-PCP|D|U| Res | I-SID | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | I-SID | | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1420 | C-DA | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | C-SA | 1423 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | | Length/Type | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | | 1427 ~ Customer Data ~ 1428 ~ ~ 1429 | | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Figure A-5: B-TAG and I-TAG tagging frame format in Provider Backbone 1433 Bridged Networks 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | B-DA | 1439 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | | | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1442 | B-SA | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | B-TAG TPID=0x88a8 |B-PCP|D| B-VID | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | I-TAG TPID=0x88e7 |I-PCP|D|U| Res | I-SID | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | I-SID | | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1450 | C-DA | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | C-SA | 1453 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | | C-TAG TCI=0x8100 | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 |C-PCP|C| C-VID | Length/Type | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | | 1459 ~ Customer Data ~ 1460 ~ ~ 1461 | | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 Figure A-6: B-TAG, I-TAG and C-TAG tagging frame format in Provider 1465 Backbone Bridged Networks 1467 0 1 2 3 1468 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 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | C-DA | 1471 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | | | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1474 | C-SA | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | S-TAG TPID=0x88a8 |S-PCP|D| S-VID | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Length/Type | | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1480 | | 1481 ~ Customer Data ~ 1482 ~ ~ 1483 | | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 Figure A-7: S-TAG tagging frame format for S-channel over the link 1487 between an end station and its adjacent bridge 1489 Note that this frame format is identical to the format in Figure A-3. 1491 0 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | C-DA | 1495 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | | | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1498 | C-SA | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | S-TAG TPID=0x88a8 |S-PCP|D| S-VID | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | C-TAG TPID=0x8100 |C-PCP|C| C-VID | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Length/Type | | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1506 | | 1507 ~ Customer Data ~ 1508 ~ ~ 1509 | | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 Figure A-8: S-TAG and C-TAG tagging frame format over the link 1513 between an end station and its adjacent bridge 1515 This frame format is identical to the format in Figure A-4. 1517 0 1 2 3 1518 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 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | C-DA | 1521 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | | | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1524 | C-SA | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | E-TAG TPID=0x893F |E-PCP|D| Ingress_E-CID_base | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 |Res|GRP| E-CID_base |Ingre_E-CID_ext| E-CID_ext | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Length/Type | | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1532 | | 1533 ~ Customer Data ~ 1534 ~ ~ 1535 | | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 Figure A-9: E-TAG tagging frame format over the link between a 1539 Controlling Bridge and a Bridge Port Extender 1541 0 1 2 3 1542 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 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | C-DA | 1545 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | | | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1548 | C-SA | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | E-TAG TPID=0x893F |E-PCP|D| Ingress_E-CID_base | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 |Res|GRP| E-CID_base |Ingre_E-CID_ext| E-CID_ext | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | C-TAG TPID=0x8100 |C-PCP|C| C-VID | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Length/Type | | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1558 | | 1559 ~ Customer Data ~ 1560 ~ ~ 1561 | | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 Figure A-10: E-TAG and C-TAG tagging frame format over the link 1565 between a Controlling Bridge and a Bridge Port Extender 1567 Appendix B. Template Formats Example 1568 0 1 2 3 1569 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 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | Set ID (0x0002) | Length | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | Template ID (0x0103) | Field Count (0x0008) | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | ingressInterface (0x000A) | Field Length (0x0004) | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | egressInterface (0x000E) | Field Length (0x0004) | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 |observationTimeSeconds (0x0142)| Field Length (0x0008) | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | dataLinkFrameSize (0x0138) | Field Length (0x0002) | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | dataLinkFrameSection (0x013B) | Field Length (0xFF40) | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | dataLinkFrameType (0x015B) | Field Length (0x0002) | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | sectionOffset (0x015C) | Field Length (0x0002) | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 |sectionObservedOctets (0x015D) | Field Length (0x0002) | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Figure B-1: Template Format Example 1594 Authors' Addresses 1596 Shingo Kashima 1597 Nippon Telegraph and Telephone Corporation 1598 Midori-Cho 3-9-11 1599 Musashino-shi, Tokyo 180-8585 1600 Japan 1602 Phone: +81 422 59 3894 1603 Email: kashima@nttv6.net 1605 Atsushi Kobayashi 1606 Nippon Telegraph and Telephone East Corporation 1607 3-19-2 Nishi-shinjuku 1608 Shinjuku-ku, Tokyo 163-8019 1609 Japan 1611 Phone: +81 3 5359 4351 1612 Email: akoba@nttv6.net 1613 Paul Aitken 1614 Cisco Systems, Inc. 1615 96 Commercial Quay 1616 Commercial Street, Edinburgh EH6 6LX 1617 United Kingdom 1619 Phone: +44 131 561 3616 1620 Email: paitken@cisco.com