RFC 7133
Information Elements for Data Link Layer Traffic Measurement
RFC 7133 💖 Information Elements for Data Link Layer Traffic Measurement (part 1 of 7 🎀)
okay bestie, let's get into it ✨ this one is from the IETF (the crew that writes the Internet's rulebook 📜) and it's a Standards Track doc, so it's the real deal, not a someday-maybe idea 💅
- RFC number: 7133
- Title: Information Elements for Data Link Layer Traffic Measurement
- Authors: S. Kashima (NTT), A. Kobayashi, Ed. (NTT East), and P. Aitken (Cisco Systems, Inc.) 👯♀️
- Category: Standards Track 🦋
- ISSN: 2070-1721
- Date: May 2014 🌸
- Obsoletes: nothing ✅
- Updates: nothing, and it actually says it does not update [RFC5477] or [RFC7011] 🙅♀️
Abstract
okay so this doc is about Information Elements for the data link layer 🔗 basically the little labelled fields that IPFIX (the IP Flow Information Export protocol 📊) uses when it's writing down measured data link layer traffic info 📝 it's giving very "measure the thing, label the thing" 💜
Status of This Memo
this one is an Internet Standards Track document 🌈
it's a product of the IETF, which means it's a consensus of the whole IETF community 🫶 it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more on Internet Standards, check out Section 2 of RFC 5741 🔍
info about its current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7133 🎀
Copyright Notice
ngl the legal part is important so here it is, fully intact 💅
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. please read these carefully because they spell out your rights and restrictions for this doc 📜 and any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜
Table of Contents
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
2. Extended Ethernet Technology ....................................4
2.1. Wide-Area Ethernet Technology Summary ......................4
2.2. Virtual Ethernet Technology Summary ........................5
3. Modification and Addition of Information Elements
Related to Data Link Layer ......................................6
3.1. Existing Information Elements ..............................7
3.1.1. dataLinkFrameSize ...................................8
3.1.2. dataLinkFrameSection ................................9
3.1.3. layer2OctetDeltaCount ...............................9
3.1.4. layer2OctetTotalCount ..............................10
3.1.5. layer2FrameDeltaCount ..............................10
3.1.6. layer2FrameTotalCount ..............................11
3.2. New Information Elements ..................................11
3.2.1. dataLinkFrameType ..................................12
3.2.2. sectionOffset ......................................12
3.2.3. sectionExportedOctets ..............................13
3.2.4. dot1qServiceInstanceTag ............................13
3.2.5. dot1qServiceInstanceId .............................14
3.2.6. dot1qServiceInstancePriority .......................14
3.2.7. dot1qCustomerSourceMacAddress ......................15
3.2.8. dot1qCustomerDestinationMacAddress .................15
3.2.9. postL2OctetDeltaCount ..............................16
3.2.10. postMCastL2OctetDeltaCount ........................16
3.2.11. postL2OctetTotalCount .............................17
3.2.12. postMCastL2OctetTotalCount ........................17
3.2.13. minimumL2TotalLength ..............................18
3.2.14. maximumL2TotalLength ..............................18
3.2.15. droppedL2OctetDeltaCount ..........................19
3.2.16. droppedL2OctetTotalCount ..........................19
3.2.17. ignoredL2OctetTotalCount ..........................20
3.2.18. notSentL2OctetTotalCount ..........................20
3.2.19. layer2OctetDeltaSumOfSquares ......................21
3.2.20. layer2OctetTotalSumOfSquares ......................21
4. Modification of Existing Information Elements Related
to Packet Section ..............................................22
4.1. ipHeaderPacketSection .....................................22
4.2. ipPayloadPacketSection ....................................23
4.3. mplsLabelStackSection .....................................24
4.4. mplsPayloadPacketSection ..................................25
5. Modification of Existing Information Elements Related
to VLAN Tag ....................................................26
5.1. dot1qVlanId ...............................................26
5.2. dot1qPriority .............................................27
5.3. dot1qCustomerVlanId .......................................27
5.4. dot1qCustomerPriority .....................................27
6. The Relationship between Ethernet Header Fields and
Information Elements ...........................................28
7. Security Considerations ........................................29
8. IANA Considerations ............................................29
9. Acknowledgments ................................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Frame Formats ........................................32
Appendix B. Template Format Example ..............................401. Introduction ✨
okay so Ethernet [IEEE802.1D] and VLAN (Virtual LAN) tech used to be only for Local Area Networks 🏠 but lately they've moved into Wide Area Networks too, like Layer 2 VPN (L2 VPN) services 🌍 which is so iconic of them. carrier networks using VLAN tech got upgraded into Provider Bridged Networks and Provider Backbone Bridged Networks [IEEE802.1Q] 🎀 and Ethernet in data centers got glow-ups for server virtualization and input/output (I/O) consolidation 💻
these innovations are giving flexibility, scalability, and mobility for the existing network architecture 🦋 BUT they make traffic measurement way messier because there are so many different Ethernet header formats 😭 so we need a more sophisticated way to measure traffic. periodt 💅
IPFIX and Packet Sampling (PSAMP) help solve this 🧚 however, the PSAMP Information Model [RFC5477] and the IPFIX Information Model [RFC7011] still don't have enough data link layer Information Elements, like Ethernet header forms 🙈 this doc describes existing and new data link layer Information Elements that enable a more sophisticated traffic measurement method 🔥
quick note: this doc does not update [RFC5477] or [RFC7011], because IANA's IPFIX registry [IANA-IPFIX] is the ultimate Information Element reference, per Section 1 of [RFC7012] 📚
1.1. Conventions Used in This Document
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119] 🫶 these are the capital-letter requirement words, so read them carefully bestie 🔍
2. Extended Ethernet Technology 🌈
2.1. Wide-Area Ethernet Technology Summary
okay so Provider Bridge and Provider Backbone Bridge [IEEE802.1Q] are the standards for Wide-Area Ethernet, and here's the tea 🍵
- Provider Bridge [IEEE802.1Q]: there are two VLAN IDs here 👯♀️ the Service VLAN Identifier (S-VID) and the Customer VLAN Identifier (C-VID). the service provider assigns the S-VID to an Ethernet frame, while the customer independently assigns the C-VID 💜 and frame switching in a service provider network is based on only the S-VID 🙌
- Provider Backbone Bridge [IEEE802.1Q]: new Ethernet fields show up here, like the Backbone VLAN Identifier (B-VID) and the Backbone Service Instance Identifier (I-SID) 🌸 they fix the limits on the VLAN ID space and keep the service provider and customer ID spaces separate 🧚 frame switching is based on a 12-bit B-VID, and customer identification is based on a 24-bit I-SID 🔥 this makes flexible network design possible, because network management is separated from customer management 👑 the other QoS class fields are the Backbone VLAN Priority Code Point (B-PCP), Backbone VLAN Drop Eligible Indicator (B-DEI), Backbone Service Instance Priority Code Point (I-PCP), and Backbone Service Instance Drop Eligible Indicator (I-DEI) 💅
the Provider Backbone Bridge tech leveled up Wide-Area Ethernet from a flat network into a hierarchical one, made of a Provider Bridged Network and a Provider Backbone Bridged Network 🦋
frame formats used in Wide-Area Ethernet are shown in Appendix A 🎀
(end of part 1 of 7 — part 2 picks up with Section 2.2 💖)
2.2. Virtual Ethernet Technology Summary 🌸
okay so data center virtual switches have some serious drama 💀. First, there's a lack of network management visibility: virtual switches have limited features, so it's really hard to monitor traffic among virtual machines (VMs). Second, there's a lack of management scalability and flexibility. When you add more VMs for a multi-tenant architecture, you get more virtual switches and more traffic control policies, and that hits the limits of network management scalability and flexibility. literally the worst 😭
so the IEEE 802.1 working group is standardizing virtual bridging tech like Edge Virtual Bridging (EVB) [IEEE802.1Qbg]. It includes two kinds of Edge Relays: Virtual Edge Bridge (VEB) and Virtual Edge Port Aggregator (VEPA). A VEB is a bridge that does bridging among multiple VMs and the external bridging environment. A VEPA is a bridge-like device on a host that forwards all internal traffic to the adjacent EVB bridge, then distributes any traffic it gets back from that EVB bridge to the VMs. The VEPA makes all the VM-to-VM traffic visible to the EVB bridge, so it can be monitored and the EVB bridge can apply filtering to it. 👑
to get more flexibility, a virtual link between a host system and an EVB bridge is standardized as an S-channel 🦋. An S-channel lets a bridge treat the traffic on that virtual link as if it came in on a separate port. For example, in the host, an S-channel may be attached to a VEB or a VEPA, or directly to an internal port, so that each port-based filtering rule can be applied to the traffic. S-channel over the link between a host and its adjacent bridge uses Service VLAN Tag (S-TAG) [IEEE802.1Q]. When S-channel is in use, frames on the link carry an S-TAG to identify the S-channel.
on the other hand, Bridge Port Extension emulates a single Extended Bridge from multiple physical switches and virtual switches, and it simplifies network management too 🧚. It also fixes the visibility problem by forwarding all traffic into a central Controlling Bridge using an E-channel. E-channel over the link between a Bridge Port Extender and a Controlling Bridge uses E-TAG, which is defined in [IEEE802.1BR].
Traffic monitoring over S-channel and E-channel is required in order to get visibility of VM-to-VM traffic and visibility of each channel's traffic on a virtual link. ✨
Frame formats with E-TAG (used in E-channel) and S-TAG (used in S-channel) are shown in Appendix A. Even though these frames carry special tags while on the link, those tags identify the virtual port (or, for multicast in the downstream direction, a set of virtual ports) they're headed to. These tag values only have local meaning, and the Flow would be reported as sent and arriving on the corresponding virtual ports. So IPFIX does not need to monitor data based on these tags 💖
3. Modification and Addition of Information Elements Related to Data Link Layer 🎀
The Information Elements in the upper section of Table 1 are needed for enabling IPFIX and PSAMP traffic measurement for the data link layer. This isn't limited to Ethernet, because the method can be applied to other data link protocols as well 🌈
The Information Elements in the middle section of Table 1 are needed for enabling IPFIX and PSAMP traffic measurement for [IEEE802.1Q].
The Information Elements in the lower section of Table 1 are octet counters or packet length for layer 2, and they're needed for enabling IPFIX and PSAMP traffic measurement for the data link layer.
+-----+------------------------------------+
| ID | Name |
+-----+------------------------------------+
| 312 | dataLinkFrameSize |
| 315 | dataLinkFrameSection |
| 408 | dataLinkFrameType |
| 409 | sectionOffset |
| 410 | sectionExportedOctets |
+-----+------------------------------------+
| 411 | dot1qServiceInstanceTag |
| 412 | dot1qServiceInstanceId |
| 413 | dot1qServiceInstancePriority |
| 414 | dot1qCustomerSourceMacAddress |
| 415 | dot1qCustomerDestinationMacAddress |
+-----+------------------------------------+
| 352 | layer2OctetDeltaCount |
| 353 | layer2OctetTotalCount |
| 417 | postL2OctetDeltaCount |
| 418 | postMCastL2OctetDeltaCount |
| 420 | postL2OctetTotalCount |
| 421 | postMCastL2OctetTotalCount |
| 422 | minimumL2TotalLength |
| 423 | maximumL2TotalLength |
| 424 | droppedL2OctetDeltaCount |
| 425 | droppedL2OctetTotalCount |
| 426 | ignoredL2OctetTotalCount |
| 427 | notSentL2OctetTotalCount |
| 428 | layer2OctetDeltaSumOfSquares |
| 429 | layer2OctetTotalSumOfSquares |
| 430 | layer2FrameDeltaCount |
| 431 | layer2FrameTotalCount |
+-----+------------------------------------+
Table 1: Information Elements Related to Data Link Layer3.1. Existing Information Elements 💅
Some existing Information Elements are required for data link layer export. Their details are reproduced here from IANA's IPFIX registry [IANA-IPFIX]. Additions per this document appear between *.
Section 3.1.1 adds the missing Data Type Semantics for the dataLinkFrameSize Information Element. This counts as an interoperable change per #4 in Section 5.2 of [RFC7013] 🔥
Section 3.1.2 extends the definition of the dataLinkFrameSection Information Element with a reference to the new sectionOffset Information Element. This is also an interoperable change per #4 in Section 5.2 of [RFC7013] 🫶
The layer2OctetDeltaCount Information Element reports the number of layer 2 octets since the previous report in incoming packets for this Flow. Meanwhile, the layer2OctetTotalCount Information Element reports the total number of layer 2 octets in incoming packets for this Flow. The layer2FrameDeltaCount Information Element reports the number of incoming layer 2 frames since the previous report for this Flow, while layer2FrameTotalCount reports the total number of incoming layer 2 frames for this Flow. All of these are unchanged from the existing IANA [IANA-IPFIX] definitions, and they're reproduced in Section 3.1.3 through Section 3.1.6 below for completeness 🧠
Therefore, these changes do not introduce any backward-compatibility issues. no notes 🙌
Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133] has been appended to the requester in IANA's IPFIX registry [IANA-IPFIX], the Information Element's revision number has been incremented by one, and the Information Element's revision date column has been updated 📋
3.1.1. dataLinkFrameSize 🍓
Description:
This Information Element specifies the length of the selected data link frame. The data link layer is defined in [ISO/IEC.7498-1:1994].
- Abstract Data Type:
unsigned16 - Data Type Semantics: quantity
- ElementId:
312 - References: [ISO/IEC.7498-1:1994]
- Status: current
3.1.2. dataLinkFrameSection 🦋
Description:
This Information Element carries n octets from the data link frame of a selected frame, starting sectionOffset octets into the frame. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the data link frame. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Further Information Elements, i.e., dataLinkFrameType and dataLinkFrameSize, are needed to specify the data link type and the size of the data link frame of this Information Element. A set of these Information Elements MAY be contained in a structured data type, as expressed in [RFC6313]. Or a set of these Information Elements MAY be contained in one Flow Record as shown in Appendix B of [RFC7133]. The data link layer is defined in [ISO/IEC.7498-1:1994].
- Abstract Data Type:
octetArray - ElementId:
315 - References: [RFC6313] [RFC7133] [ISO/IEC.7498-1:1994]
- Status: current
3.1.3. layer2OctetDeltaCount 🌸
The layer2OctetDeltaCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
Description:
The number of layer 2 octets since the previous report (if any) in incoming packets for this Flow at the Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload.
- Abstract Data Type:
unsigned64 - Data Type Semantics:
deltaCounter - Units:
octets - ElementId:
352 - Status: current
3.1.4. layer2OctetTotalCount ✨
The layer2OctetTotalCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
Description:
The total number of layer 2 octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload.
- Abstract Data Type:
unsigned64 - Data Type Semantics:
totalCounter - Units:
octets - ElementId:
353 - Status: current
3.1.5. layer2FrameDeltaCount 🧚
The layer2FrameDeltaCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
Description:
The number of incoming layer 2 frames since the previous report (if any) for this Flow at the Observation Point.
- Abstract Data Type:
unsigned64 - Data Type Semantics:
deltaCounter - Units:
frames - ElementId:
430 - Status: current
3.1.6. layer2FrameTotalCount 👑
The layer2FrameTotalCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
Description:
The total number of incoming layer 2 frames for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
- Abstract Data Type:
unsigned64 - Data Type Semantics:
totalCounter - Units:
frames - ElementId:
431 - Status: current
3.2. New Information Elements
okay so this is where we add the brand-new Information Elements for data link layer monitoring 💅✨ In IANA's IPFIX registry [IANA-IPFIX], the Requester gets set to [RFC7133], the Information Element's Revision gets set to zero, and the Date gets set to the day the new Information Elements were added to the registry 🗓️ Every other column that isn't mentioned below (like Units, Range, or References) is not applicable, so it stays blank, since the registry doesn't actually have a "not applicable" option 🙈
3.2.1. dataLinkFrameType
Description:
This one tells you what kind of data link frame you've got 🎀 Right now there are two types defined:
0x01 IEEE802.3 ETHERNET [IEEE802.3]0x02 IEEE802.11 MAC Frame format [IEEE802.11]
IANA can assign more values later 🦋 The values are bits, so you can OR multiple observations together, which is honestly so clever 🧠 The data link layer itself is defined in [ISO/IEC.7498-1:1994].
Abstract Data Type: unsigned16
Data Type Semantics: flags
ElementId: 408
References: [IEEE802.3] [IEEE802.11] [ISO/IEC.7498-1:1994]
Status: current
3.2.2. sectionOffset
Description:
This is the offset of the packet section, so the dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, or mplsPayloadPacketSection stuff 🧚 If you leave it out, it defaults to zero, which means no offset at all.
If you put multiple sectionOffset Information Elements in a single Template, they apply to the packet section Information Elements in order 📋 The first sectionOffset goes with the first packet section, the second goes with the second, and so on. Quick heads-up, the "closest" sectionOffset and packet section in a Template aren't necessarily related, so don't assume they're a couple 💀 If you have fewer sectionOffsets than packet sections, the leftover packet sections get no offset, which is the same as a sectionOffset of zero. If you have more sectionOffsets than packet sections, the extra ones are meaningless 🙃
Abstract Data Type: unsigned16
Data Type Semantics: quantity
ElementId: 409
Status: current
3.2.3. sectionExportedOctets
Description:
This one is the observed length of the packet section (same list as before: dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection) when padding is in use 🌸
The packet section might be a fixed size that's bigger than the sectionExportedOctets. In that case, the octets past the sectionExportedOctets MUST follow the [RFC7011] rules for padding, meaning they're made up of zero (0) valued octets. Padding has to be all zeros, no exceptions, bestie 🔥
Abstract Data Type: unsigned16
Data Type Semantics: quantity
ElementId: 410
References: [RFC7011]
Status: current
3.2.4. dot1qServiceInstanceTag
Description:
This 16-octet-long Information Element represents the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame, as described in [IEEE802.1Q] 💜 It holds the Backbone Service Instance Priority Code Point (I-PCP), the Backbone Service Instance Drop Eligible Indicator (I-DEI), the Use Customer Addresses (UCAs), the Backbone Service Instance Identifier (I-SID), the Encapsulated Customer Destination Address (C-DA), the Encapsulated Customer Source Address (C-SA), and some reserved fields. The structure and semantics inside the Tag Control Information field are defined in [IEEE802.1Q], so go check there for the details 📖
Abstract Data Type: octetArray
Data Type Semantics: default
ElementId: 411
References: [IEEE802.1Q]
Status: current
3.2.5. dot1qServiceInstanceId
Description:
This is the value of the 24-bit Backbone Service Instance Identifier (I-SID) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame, as described in [IEEE802.1Q] 🦄
Abstract Data Type: unsigned32
Data Type Semantics: identifier
ElementId: 412
References: [IEEE802.1Q]
Status: current
Range: The valid range is 0 - 16777215 (i.e., 24 bits).
3.2.6. dot1qServiceInstancePriority
Description:
This is the value of the 3-bit Backbone Service Instance Priority Code Point (I-PCP) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame, as described in [IEEE802.1Q] 🍓
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 413
References: [IEEE802.1Q]
Status: current
Range: The valid range is 0-7.
3.2.7. dot1qCustomerSourceMacAddress
Description:
This is the value of the Encapsulated Customer Source Address (C-SA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame, as described in [IEEE802.1Q] 🌈
Abstract Data Type: macAddress
Data Type Semantics: default
ElementId: 414
References: [IEEE802.1Q]
Status: current
3.2.8. dot1qCustomerDestinationMacAddress
Description:
This is the value of the Encapsulated Customer Destination Address (C-DA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame, as described in [IEEE802.1Q] 🫶
Abstract Data Type: macAddress
Data Type Semantics: default
ElementId: 415
References: [IEEE802.1Q]
Status: current
3.2.9. postL2OctetDeltaCount
Description:
This one is basically identical to layer2OctetDeltaCount, with one twist: it reports a potentially modified value that a middlebox function caused after the packet passed the Observation Point 🔀 It's the layer 2 version of postOctetDeltaCount (ElementId #23) ✨
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 417
References: [RFC5477]
Status: current
Units: octets
3.2.10. postMCastL2OctetDeltaCount
Description:
This is the number of layer 2 octets since the previous report (if there is one) in outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain 📡 You can't necessarily observe this at the Observation Point, but you might be able to retrieve it some other way. The octet count includes the layer 2 header(s) and the layer 2 payload 📦
This is the layer 2 version of postMCastOctetDeltaCount (ElementId #20) 💖
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 418
References: [RFC5477]
Status: current
Units: octets
3.2.11. postL2OctetTotalCount
Description:
Same energy as layer2OctetTotalCount, except this one reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point 🛠️ It's the layer 2 version of postOctetTotalCount (ElementId #171) 🌟
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 420
References: [RFC5477]
Status: current
Units: octets
3.2.12. postMCastL2OctetTotalCount
Description:
This is the total number of layer 2 octets in outgoing multicast packets sent for packets of this Flow by a multicast daemon in the Observation Domain, counted since the Metering Process (re-)initialization ⏱️ Again, it might not be observable at the Observation Point, but you can retrieve it by other means. The octets include the layer 2 header(s) and the layer 2 payload 🧾
This is the layer 2 version of postMCastOctetTotalCount (ElementId #175) 🥰
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 421
References: [RFC5477]
Status: current
Units: octets
3.2.13. minimumL2TotalLength
Description:
This is the layer 2 length of the smallest packet observed for this Flow 🐣 The packet length includes the length of the layer 2 header(s) and the length of the layer 2 payload.
This is the layer 2 version of minimumIpTotalLength (ElementId #25) 🌷
Abstract Data Type: unsigned64
ElementId: 422
References: [RFC5477]
Status: current
Units: octets
3.2.14. maximumL2TotalLength
Description:
This is the layer 2 length of the largest packet observed for this Flow 🐘 The packet length includes the length of the layer 2 header(s) and the length of the layer 2 payload.
This is the layer 2 version of maximumIpTotalLength (ElementId #26) 👑
Abstract Data Type: unsigned64
ElementId: 423
References: [RFC5477]
Status: current
Units: octets
3.2.15. droppedL2OctetDeltaCount
Description:
This is the number of layer 2 octets since the previous report (if there is one) in packets of this Flow that were dropped by packet treatment 🗑️ The octet count includes the layer 2 header(s) and the layer 2 payload.
This is the layer 2 version of droppedOctetDeltaCount (ElementId #132) 💅
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 424
References: [RFC5477]
Status: current
Units: octets
3.2.16. droppedL2OctetTotalCount
Description:
This is the total number of octets in observed layer 2 packets (including the layer 2 header) that were dropped by packet treatment since the (re-)initialization of the Metering Process 📉
This is the layer 2 version of droppedOctetTotalCount (ElementId #134) 🎀
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 425
References: [RFC5477]
Status: current
Units: octets
3.2.17. ignoredL2OctetTotalCount
Description:
This is the total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process 🙈
This is the layer 2 version of ignoredOctetTotalCount (ElementId #165) 🌸
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 426
References: [RFC5477]
Status: current
Units: octets
3.2.18. notSentL2OctetTotalCount
Description:
This is the total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process 🚫 Yes, this description is the same as ignoredL2OctetTotalCount, and yes, I noticed too 😭
This is the layer 2 version of notSentOctetTotalCount (ElementId #168) 🦋
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 427
References: [RFC5477]
Status: current
Units: octets
3.2.19. layer2OctetDeltaSumOfSquares 🦋
Description:
okay so this one is the sum of the squared numbers of layer 2 octets per incoming packet since the previous report (if any) for this Flow at the Observation Point 💅 and the octets count includes the layer 2 header(s) AND the layer 2 payload 🫶
this is basically the layer 2 version of octetDeltaSumOfSquares (ElementId #198) and it's giving main character energy ✨
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 428
References: [RFC5477]
Status: current
Units: octets
3.2.20. layer2OctetTotalSumOfSquares 🌸
Description:
ngl this one is the total sum of the squared numbers of layer 2 octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point 🔥 again the octets include layer 2 header(s) and layer 2 payload, no cap 💜
this is the layer 2 version of octetTotalSumOfSquares (ElementId #199) and honestly iconic 👑
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 429
References: [RFC5477]
Status: current
Units: octets
- Modification of Existing Information Elements Related to Packet Section 🎀
okay bestie so the new Information Elements related to packet section (sectionOffset and sectionExportedOctets) can be applied to not only dataLinkFrameSection but ALSO to all kinds of packet section (ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, and mplsPayloadPacketSection, all defined in [RFC5477]) 🧚 so the existing Information Elements Descriptions should be modified as follows 💖
4.1. ipHeaderPacketSection 🌈
This Information Element is defined in [RFC5477]. The description has been updated from [RFC5477] ✨
Description:
this one carries a series of n octets from the IP header of a sampled packet, starting sectionOffset octets into the IP header 🦋
however, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the IP header 💅
with sufficient length, this element also reports octets from the IP payload 🙈 but full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804] 🚫
the sectionExportedOctets expresses how much data was exported, while the remainder is padding 🎀
when the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length 🌸
when the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded 😭 in this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol 🫶
Abstract Data Type: octetArray
ElementId: 313
References: [RFC2804] [RFC5477]
Status: current
4.2. ipPayloadPacketSection 💖
This Information Element is defined in [RFC5477]. The description is updated from [RFC5477] 🧚
Description:
this Information Element carries a series of n octets from the IP payload of a sampled packet, starting sectionOffset octets into the IP payload 🦋
however, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the IP payload 💅
the IPv4 payload is that part of the packet that follows the IPv4 header and any options, which [RFC0791] refers to as "data" or "data octets" 🍓 for example, see the examples in [RFC0791], Appendix A 📖
the IPv6 payload is the rest of the packet following the 40-octet IPv6 header 🌈 note that any extension headers present are considered part of the payload ✨ see [RFC2460] for the IPv6 specification 💜
the sectionExportedOctets expresses how much data was observed, while the remainder is padding 🎀
when the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length 🌸
when the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded 😭 in this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol 🫶
Abstract Data Type: octetArray
ElementId: 314
References: [RFC0791] [RFC2460]
Status: current
4.3. mplsLabelStackSection 🦋
This Information Element is defined in [RFC5477]. The description is updated from [RFC5477] 💅
Description:
this one carries a series of n octets from the MPLS label stack of a sampled packet, starting sectionOffset octets into the MPLS label stack 🫶
however, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the head of the MPLS label stack 🔥
with sufficient length, this element also reports octets from the MPLS payload 🙈 but full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804] 🚫
see [RFC3031] for the specification of MPLS packets 📖
see [RFC3032] for the specification of the MPLS label stack 📖
the sectionExportedOctets expresses how much data was observed, while the remainder is padding 🎀
when the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length 🌸
when the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded 😭 in this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol 🫶
Abstract Data Type: octetArray
ElementId: 316
References: [RFC2804] [RFC3031] [RFC3032] [RFC5477]
Status: current
4.4. mplsPayloadPacketSection 🧚
This Information Element is defined in [RFC5477]. The description is updated from [RFC5477] 🌈
Description:
the mplsPayloadPacketSection carries a series of n octets from the MPLS payload of a sampled packet, starting sectionOffset octets into the MPLS payload, since it's the data that comes right after the MPLS label stack 💖
however, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the MPLS payload 💅
see [RFC3031] for the specification of MPLS packets 📖
see [RFC3032] for the specification of the MPLS label stack 📖
the sectionExportedOctets expresses how much data was observed, while the remainder is padding 🎀
when the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length 🌸
when the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded 😭 in this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol 🫶
Abstract Data Type: octetArray
ElementId: 317 References: [RFC3031] [RFC3032]
Status: current
- Modification of Existing Information Elements Related to VLAN Tag 🍓
the traffic measurement using IPFIX and PSAMP for a Provider Backbone Bridged Network requires the Information Elements related to Backbone Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG) 🌈 the set of Information Elements related to I-TAG is added in Section 3, because I-TAG structure and semantics are different from that of Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG) 💅 the set of Information Elements related to B-TAG reuses the existing Information Elements, because B-TAG structure and semantics are identical to that of C-TAG and S-TAG ✨ this section modifies existing descriptions and references related to C-TAG and S-TAG as follows 🦋
5.1. dot1qVlanId 💖
Description:
the value of the 12-bit VLAN Identifier portion of the Tag Control Information field of an Ethernet frame 🫶 the structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q] 📖 in Provider Bridged Networks, it represents the Service VLAN identifier in the Service VLAN Tag (S-TAG) Tag Control Information (TCI) field or the Customer VLAN identifier in the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q] 🧚 in Provider Backbone Bridged Networks, it represents the Backbone VLAN identifier in the Backbone VLAN Tag (B-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q] 🌸 in a virtual link between a host system and EVB bridge, it represents the Service VLAN identifier indicating S-channel as described in [IEEE802.1Qbg] 🔥
in the case of a multi-tagged frame, it represents the outer tag's VLAN identifier, except for I-TAG 👑
Abstract Data Type: unsigned16
Data Type Semantics: identifier
ElementId: 243
Status: current
References: [IEEE802.1Q] [IEEE802.1Qbg]
5.2. dot1qPriority 🌈
Description:
the value of the 3-bit User Priority portion of the Tag Control Information field of an Ethernet frame 💅 the structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q] 📖 in the case of a multi-tagged frame, it represents the 3-bit Priority Code Point (PCP) portion of the outer tag's Tag Control Information (TCI) field as described in [IEEE802.1Q], except for I-TAG 💜
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 244
Status: current
References: [IEEE802.1Q]
5.3. dot1qCustomerVlanId 🦋
Description:
the value represents the Customer VLAN identifier in the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q] 🫶
Abstract Data Type: unsigned16
Data Type Semantics: identifier
ElementId: 245
Status: current
References: [IEEE802.1Q]
5.4. dot1qCustomerPriority 🎀
Description:
the value represents the 3-bit Priority Code Point (PCP) portion of the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q] 🌸
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 246
Status: current
References: [IEEE802.1Q]
6. The Relationship between Ethernet Header Fields and Information Elements 🎀
Okay so this part is basically a cheat sheet 💅 It shows a bunch of Ethernet header fields and which Information Elements get used to represent each one. Three frame types, three little diagrams, and the vibes are immaculate ✨
<-- 6 --> <-- 6 --> <-- 4 --> <---- 2 ---->
+---------+---------+---------+-------------+
| | | | |
| C-DA | C-SA | C-TAG | Length/Type |
| a | b | c | d |
+---------+---------+---------+-------------+
a.(Information Element) destinationMacAddress (80)
b.(Information Element) sourceMacAddress (56)
c.(Information Elements) dot1qVlanId (243), dot1qPriority (244)
d.(Information Element) ethernetType (256)
Figure 1: Customer-Tagged Frame Header FieldsFigure 1 is the customer-tagged one 🦋 The C-TAG field is the one that gets split into dot1qVlanId and dot1qPriority, so it's giving two bffs 👯♀️
<-- 6 --> <-- 6 --> <-- 4 --> <-- 4 --> <---- 2 ---->
+---------+---------+---------+---------+-------------+
| | | | | |
| C-DA | C-SA | S-TAG | C-TAG | Length/Type |
| a | b | c | d | e |
+---------+---------+---------+---------+-------------+
a.(Information Element) destinationMacAddress (80)
b.(Information Element) sourceMacAddress (56)
c.(Information Elements) dot1qVlanId (243), dot1qPriority (244)
d.(Information Elements) dot1qCustomerVlanId (245),
dot1qCustomerPriority (246)
e.(Information Element) ethernetType (256)
Figure 2: Service-Tagged Frame Header FieldsFigure 2 is the service-tagged one 🌸 Now there's an S-TAG and a C-TAG stacked up, and each tag has its own set of Information Elements. Layers on layers, I'm obsessed 😭
<-- 6 --> <-- 6 --> <-- 4 --> <--- 16 ---> <-- 4 --> <---- 2 ---->
+---------+---------+---------+------------+---------+-------------+
| | | | | | |
| B-DA | B-SA | B-TAG | I-TAG | C-TAG | Length/Type |
| a | b | c | d | e | f |
+---------+---------+---------+------------+---------+-------------+
a.(Information Element) destinationMacAddress (80)
b.(Information Element) sourceMacAddress (56)
c.(Information Elements) dot1qVlanId (243), dot1qPriority (244)
d.(Information Elements) dot1qServiceInstanceTag (411), or
a set of dot1qServiceInstanceId (412),
dot1qServiceInstancePriority (413),
dot1qCustomerSourceMacAddress (414)
dot1qCustomerDestinationMacAddress (415),
e.(Information Elements) dot1qCustomerVlanId (245),
dot1qCustomerPriority (246)
f.(Information Element) ethernetType (256)
Figure 3: Backbone-VLAN-Tagged Frame Header FieldsAnd Figure 3 is the backbone-VLAN-tagged one 👑 This is the full glam look: B-TAG, I-TAG, and C-TAG all in one frame. The I-TAG can be represented either as a single dot1qServiceInstanceTag (411) or as a whole set of smaller Elements, so pick your fighter 💖
7. Security Considerations 🔒
Real talk, bestie 🫶 Reporting more granular data can make DoS attacks against a Collector more likely. Protection against DoS attacks is covered in Section 11.4 of [RFC7011].
Heads up: this is a serious one, so read Section 11.4 of [RFC7011] before you go wild with granular reporting 🙈
The recommendations in this document don't add any other security issues beyond the ones already covered in [RFC7011] and [RFC5477]. So you're not walking into anything new, just the usual stuff 💜
8. IANA Considerations 🧚
Existing IPFIX Information Elements [IANA-IPFIX] have been modified as indicated in Sections 3.1, 4, and 5. Those are the ones getting the glow-up ✨
Per Section 5.2 of [RFC7013], each of these changes gets [RFC7133] appended to the Requester in IANA's IPFIX registry [IANA-IPFIX]. The Information Element's Revision number goes up by one, and its revision Date column gets updated. Paper trail, very important 📝
New IPFIX Information Elements [IANA-IPFIX] have been allocated as shown in Section 3.2. Fresh faces in the registry, iconic 🌈
9. Acknowledgments 🌷
Big thanks to Brian Trammell and the IPFIX working group participants who joined the mailing-list discussions throughout the development of this document. You all carried 🫶
Special shoutout to Pat Thaler for her help with the IEEE 802 aspects of this work. Literally the MVP for the IEEE 802 side of things 👑
10. References 📚
10.1. Normative References
- [IEEE802.11] IEEE, "IEEE Standard for Information technology. Telecommunications and information exchange between systems Local and metropolitan area networks. Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, March 2012.
- [IEEE802.1BR] IEEE, "IEEE Standard for Local and metropolitan area networks: Virtual Bridged Local Area Networks: Bridge Port Extension", IEEE Std 802.1BR-2012, July 2012.
- [IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
- [IEEE802.1Qbg] IEEE, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks: Amendment 21: Edge Virtual Bridging", IEEE Std 802.1Qbg-2012, July 2012.
- [IEEE802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2012, December 2012.
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
- [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
- [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
- [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
10.2. Informative References
- [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
<http://www.iana.org/assignments/ipfix>. - [IEEE802.1D] IEEE, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges", IEEE Std 802.1D-2004, June 2004.
- [ISO/IEC.7498-1:1994] International Organization for Standardization, "Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Mode", ISO Standard 7498-1:1994, June 1996.
- [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
- [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
- [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013.
Appendix A. Frame Formats 🧚
These are the frame layouts, and they're gorgeous 🦋 Each one is a little bit of bit-level art.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A-1: Untagged Frame FormatFigure A-1 is the untagged frame 🌸 Simple, clean, no extra tags, just vibes.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TPID=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A-2: C-TAG Tagging Frame FormatFigure A-2 adds the C-TAG, with its TPID set to 0x8100 and the C-PCP, C, and C-VID fields all in there 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-TAG TPID=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A-3: S-TAG Tagging Frame Format in Provider Bridged NetworksFigure A-3 is the S-TAG version for Provider Bridged Networks, with TPID 0x88a8 and the S-PCP, D, and S-VID fields 🦋 Frame formats, all served ✨
okay bestie, the frame diagrams are literally the best part 🎀 these are the pictures that show exactly where every field sits in the bits, so no cap, we copy them exactly 💅
Figure A-4 is the S-TAG and C-TAG tagging frame format in Provider Bridged Networks 🌸
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-TAG TPID=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TPID=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-4: S-TAG and C-TAG Tagging Frame Format in Provider Bridged Networks
Figure A-5 is the B-TAG and I-TAG tagging frame format in Provider Backbone Bridged Networks ✨
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| B-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-TAG TPID=0x88a8 |B-PCP|D| B-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-TAG TPID=0x88e7 |I-PCP|D|U| Res | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-SA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-5: B-TAG and I-TAG Tagging Frame Format in Provider Backbone Bridged Networks
Figure A-6 is the B-TAG, I-TAG, and C-TAG tagging frame format in Provider Backbone Bridged Networks, so it's a whole stack of tags 🧚
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| B-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-TAG TPID=0x88a8 |B-PCP|D| B-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-TAG TPID=0x88e7 |I-PCP|D|U| Res | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-SA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C-TAG TCI=0x8100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C-PCP|C| C-VID | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-6: B-TAG, I-TAG, and C-TAG Tagging Frame Format in Provider Backbone Bridged Networks
Figure A-7 is the S-TAG tagging frame format for the S-channel over the link between an end station and its adjacent bridge 🦋
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-TAG TPID=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-7: S-TAG Tagging Frame Format for S-channel over the Link between an End Station and Its Adjacent Bridge
Note: The frame format in Figure A-7 is identical to the format in Figure A-3.
Figure A-8 is the S-TAG and C-TAG tagging frame format over the link between an end station and its adjacent bridge 💖
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-TAG TPID=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TPID=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-8: S-TAG and C-TAG Tagging Frame Format over the Link between an End Station and Its Adjacent Bridge
Note: The frame format in Figure A-8 is identical to the format in Figure A-4.
Figure A-9 is the E-TAG tagging frame format over the link between a controlling bridge and a bridge port extender 🌈
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-TAG TPID=0x893F |E-PCP|D| Ingress_E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|GRP| E-CID_base |Ingre_E-CID_ext| E-CID_ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-9: E-TAG Tagging Frame Format over the Link between a Controlling Bridge and a Bridge Port Extender
Last one in this batch, Figure A-10 is the E-TAG and C-TAG tagging frame format over the link between a controlling bridge and a bridge port extender ✨🫶
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-TAG TPID=0x893F |E-PCP|D| Ingress_E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|GRP| E-CID_base |Ingre_E-CID_ext| E-CID_ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TPID=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure A-10: E-TAG and C-TAG Tagging Frame Format over the Link between a Controlling Bridge and a Bridge Port Extender
Appendix B. Template Format Example ✨
okay bestie, here's the template format example laid out bit by bit 🧚💜
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (256) | Field Count (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface (10) | Field Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface (14) | Field Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| observationTimeSeconds (322) | Field Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dataLinkFrameSize (312) | Field Length (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dataLinkFrameSection (315) | Field Length (65535) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dataLinkFrameType (408) | Field Length (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sectionOffset (409) | Field Length (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sectionExportedOctets (410) | Field Length (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B-1: Template Format ExampleAuthors' Addresses 💌
here are the authors' details, so you know exactly who to reach out to about this one 🫶
Shingo Kashima Nippon Telegraph and Telephone Corporation 1-5-1 Otemachi Chiyoda-ku, Tokyo 100-8116 Japan
Phone: +81 3 6838 5267 EMail: kashima@nttv6.net
Atsushi Kobayashi Nippon Telegraph and Telephone East Corporation 3-19-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8019 Japan
Phone: +81 3 5359 4351 EMail: akoba@nttv6.net
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street, Edinburgh EH6 6LX United Kingdom
Phone: +44 131 561 3616 EMail: paitken@cisco.com
📦 where this page comes from
- ietf: rfc7133 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms