7133
PROPOSED STANDARD
Information Elements for Data Link Layer Traffic Measurement
Authors: S. Kashima, A. Kobayashi, P. Aitken
Date: May 2014
Area: ops
Working Group: ipfix
Stream: IETF
Abstract
This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.
RFC 7133
PROPOSED STANDARD
Internet Engineering Task Force (IETF) S. Kashima
Request for Comments: 7133 NTT
Category: Standards Track A. Kobayashi, Ed.
ISSN: 2070-1721 NTT East
P. Aitken
Cisco Systems, Inc.
May 2014
<span class="h1">Information Elements for Data Link Layer Traffic Measurement</span>
Abstract
This document describes Information Elements related to the data link
layer. They are used by the IP Flow Information Export (IPFIX)
protocol for encoding measured data link layer traffic information.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc7133">http://www.rfc-editor.org/info/rfc7133</a>.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Kashima, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Extended Ethernet Technology ....................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Wide-Area Ethernet Technology Summary ......................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Virtual Ethernet Technology Summary ........................<a href="#page-5">5</a>
3. Modification and Addition of Information Elements
Related to Data Link Layer ......................................<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Existing Information Elements ..............................<a href="#page-7">7</a>
<a href="#section-3.1.1">3.1.1</a>. dataLinkFrameSize ...................................<a href="#page-8">8</a>
<a href="#section-3.1.2">3.1.2</a>. dataLinkFrameSection ................................<a href="#page-9">9</a>
<a href="#section-3.1.3">3.1.3</a>. layer2OctetDeltaCount ...............................<a href="#page-9">9</a>
<a href="#section-3.1.4">3.1.4</a>. layer2OctetTotalCount ..............................<a href="#page-10">10</a>
<a href="#section-3.1.5">3.1.5</a>. layer2FrameDeltaCount ..............................<a href="#page-10">10</a>
<a href="#section-3.1.6">3.1.6</a>. layer2FrameTotalCount ..............................<a href="#page-11">11</a>
<a href="#section-3.2">3.2</a>. New Information Elements ..................................<a href="#page-11">11</a>
<a href="#section-3.2.1">3.2.1</a>. dataLinkFrameType ..................................<a href="#page-12">12</a>
<a href="#section-3.2.2">3.2.2</a>. sectionOffset ......................................<a href="#page-12">12</a>
<a href="#section-3.2.3">3.2.3</a>. sectionExportedOctets ..............................<a href="#page-13">13</a>
<a href="#section-3.2.4">3.2.4</a>. dot1qServiceInstanceTag ............................<a href="#page-13">13</a>
<a href="#section-3.2.5">3.2.5</a>. dot1qServiceInstanceId .............................<a href="#page-14">14</a>
<a href="#section-3.2.6">3.2.6</a>. dot1qServiceInstancePriority .......................<a href="#page-14">14</a>
<a href="#section-3.2.7">3.2.7</a>. dot1qCustomerSourceMacAddress ......................<a href="#page-15">15</a>
<a href="#section-3.2.8">3.2.8</a>. dot1qCustomerDestinationMacAddress .................<a href="#page-15">15</a>
<a href="#section-3.2.9">3.2.9</a>. postL2OctetDeltaCount ..............................<a href="#page-16">16</a>
<a href="#section-3.2.10">3.2.10</a>. postMCastL2OctetDeltaCount ........................<a href="#page-16">16</a>
<a href="#section-3.2.11">3.2.11</a>. postL2OctetTotalCount .............................<a href="#page-17">17</a>
<a href="#section-3.2.12">3.2.12</a>. postMCastL2OctetTotalCount ........................<a href="#page-17">17</a>
<a href="#section-3.2.13">3.2.13</a>. minimumL2TotalLength ..............................<a href="#page-18">18</a>
<a href="#section-3.2.14">3.2.14</a>. maximumL2TotalLength ..............................<a href="#page-18">18</a>
<a href="#section-3.2.15">3.2.15</a>. droppedL2OctetDeltaCount ..........................<a href="#page-19">19</a>
<a href="#section-3.2.16">3.2.16</a>. droppedL2OctetTotalCount ..........................<a href="#page-19">19</a>
<a href="#section-3.2.17">3.2.17</a>. ignoredL2OctetTotalCount ..........................<a href="#page-20">20</a>
<a href="#section-3.2.18">3.2.18</a>. notSentL2OctetTotalCount ..........................<a href="#page-20">20</a>
<a href="#section-3.2.19">3.2.19</a>. layer2OctetDeltaSumOfSquares ......................<a href="#page-21">21</a>
<a href="#section-3.2.20">3.2.20</a>. layer2OctetTotalSumOfSquares ......................<a href="#page-21">21</a>
4. Modification of Existing Information Elements Related
to Packet Section ..............................................<a href="#page-22">22</a>
<a href="#section-4.1">4.1</a>. ipHeaderPacketSection .....................................<a href="#page-22">22</a>
<a href="#section-4.2">4.2</a>. ipPayloadPacketSection ....................................<a href="#page-23">23</a>
<a href="#section-4.3">4.3</a>. mplsLabelStackSection .....................................<a href="#page-24">24</a>
<a href="#section-4.4">4.4</a>. mplsPayloadPacketSection ..................................<a href="#page-25">25</a>
5. Modification of Existing Information Elements Related
to VLAN Tag ....................................................<a href="#page-26">26</a>
<a href="#section-5.1">5.1</a>. dot1qVlanId ...............................................<a href="#page-26">26</a>
<a href="#section-5.2">5.2</a>. dot1qPriority .............................................<a href="#page-27">27</a>
<a href="#section-5.3">5.3</a>. dot1qCustomerVlanId .......................................<a href="#page-27">27</a>
<span class="grey">Kashima, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<a href="#section-5.4">5.4</a>. dot1qCustomerPriority .....................................<a href="#page-27">27</a>
6. The Relationship between Ethernet Header Fields and
Information Elements ...........................................<a href="#page-28">28</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-29">29</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-29">29</a>
<a href="#section-9">9</a>. Acknowledgments ................................................<a href="#page-30">30</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-30">30</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-30">30</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-31">31</a>
<a href="#appendix-A">Appendix A</a>. Frame Formats ........................................<a href="#page-32">32</a>
<a href="#appendix-B">Appendix B</a>. Template Format Example ..............................<a href="#page-40">40</a>
<span class="grey">Kashima, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Ethernet [<a href="#ref-IEEE802.1D" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges"">IEEE802.1D</a>] and VLAN (Virtual LAN) technologies had been
used only in Local Area Networks. Recently, they have been used in
Wide Area Networks, e.g., Layer 2 VPN (L2 VPN) services.
Accordingly, carrier networks using VLAN technologies have been
enhanced to Provider Bridged Networks and Provider Backbone Bridged
Networks [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. In addition, Ethernet in data centers has
also been enhanced for server virtualization and input/output (I/O)
consolidation.
While these innovations provide flexibility, scalability, and
mobility to an existing network architecture, they increase the
complexity of traffic measurement due to the existence of various
Ethernet header formats. To cope with this, a more sophisticated
method of traffic measurement is required.
IPFIX and Packet Sampling (PSAMP) help to resolve these problems.
However, the PSAMP Information Model [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>] and the IPFIX
Information Model [<a href="./rfc7011" title=""Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information"">RFC7011</a>] don't yet contain enough Information
Elements related to the data link layer, e.g., Ethernet header forms.
This document describes existing and new Information Elements related
to data link layers that enable a more sophisticated traffic
measurement method.
Note that this document does not update [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>] or [<a href="./rfc7011" title=""Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information"">RFC7011</a>]
because IANA's IPFIX registry [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] is the ultimate
Information Element reference, per <a href="./rfc7012#section-1">Section 1 of [RFC7012]</a>.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Extended Ethernet Technology</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Wide-Area Ethernet Technology Summary</span>
Provider Bridge and Provider Backbone Bridge [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>], which are
standards for Wide-Area Ethernet, are described below.
o In Provider Bridge [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>], there are two VLAN IDs: Service
VLAN Identifier (S-VID) and Customer VLAN Identifier (C-VID).
S-VID is assigned to an Ethernet frame by a service provider,
while C-VID is independently assigned to an Ethernet frame by a
customer. Frame switching in a service provider network is based
on only S-VID.
<span class="grey">Kashima, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
o In Provider Backbone Bridge [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>], new Ethernet fields,
such as Backbone VLAN Identifier (B-VID) and Backbone Service
Instance Identifier (I-SID), are introduced to overcome the
limitations on the VLAN identifier space and to isolate the
service provider and customer identifier spaces. Frame switching
is based on a 12-bit B-VID, and customer identification is based
on a 24-bit I-SID. A flexible network design has become possible
because network management is separated from customer management.
Other Ethernet fields that indicate quality of service (QoS) class
are 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 technologies have enhanced a Wide-Area
Ethernet service from a flat network to a hierarchical network
consisting of a Provider Bridged Network and Provider Backbone
Bridged Network.
Frame formats used in Wide-Area Ethernet are shown in <a href="#appendix-A">Appendix A</a>.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Virtual Ethernet Technology Summary</span>
There have been several challenges in the existing virtual switches
environment in a data center. One is the lack of network management
visibility: limited features on virtual switches make it difficult to
monitor traffic among virtual machines (VMs). Another is the lack of
management scalability and flexibility: increasing the number of VMs
for multi-tenant architecture causes an increase in the number of
virtual switches and in the number of the traffic control policies,
which reach the limitations of network management scalability and
flexibility.
In this situation, the IEEE 802.1 working group is standardizing
virtual bridging technologies such as Edge Virtual Bridging (EVB),
including two kinds of Edge Relays: Virtual Edge Bridge (VEB) and
Virtual Edge Port Aggregator (VEPA) [<a href="#ref-IEEE802.1Qbg" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks: Amendment 21: Edge Virtual Bridging"">IEEE802.1Qbg</a>]. The VEB is a
bridge that provides bridging among multiple VMs and the external
bridging environment. The VEPA is a bridge-like device on a host
that forwards all internal traffic to the adjacent EVB bridge and
then distributes any traffic received from the adjacent EVB bridge to
VMs. The VEPA makes all the VM-to-VM traffic visible to the EVB
bridge so that the traffic can be monitored and so that the EVB
bridge can apply filtering to the traffic.
To improve flexibility, a virtual link between a host system and EVB
bridge is standardized as S-channel. S-channel allows a bridge to
treat the traffic in the virtual link as if it comes in on a separate
<span class="grey">Kashima, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
port. For example, in the host, an S-channel may be attached to a
VEB or a VEPA or directly to an internal port in order to apply each
port-based filtering rule to the traffic. S-channel over the link
between a host and its adjacent bridge uses Service VLAN Tag (S-TAG)
[<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. 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 single Extended
Bridge from multiple physical switches and virtual switches, and it
also simplifies network management. Also, it solves the lack of
network management visibility by forwarding all traffic into a
central Controlling Bridge using E-channel. E-channel over the link
between a Bridge Port Extender and a Controlling Bridge uses E-TAG
defined in [<a href="#ref-IEEE802.1BR" title=""IEEE Standard for Local and metropolitan area networks: Virtual Bridged Local Area Networks: Bridge Port Extension"">IEEE802.1BR</a>].
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 <a href="#appendix-A">Appendix A</a>. Though these frames carry special
tags while on the link, those tags identify a virtual port (or for
multicast in the downstream direction, a set of virtual ports) to
which they are destined. These tag values only have local meaning,
and the Flow would be reported as sent and arriving on the
corresponding virtual ports. Therefore, IPFIX does not need to
monitor data based on these tags.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Modification and Addition of Information Elements Related to Data</span>
<span class="h2"> Link Layer</span>
The Information Elements listed in the upper section of Table 1 are
necessary for enabling IPFIX and PSAMP traffic measurement for the
data link layer, which is not limited to Ethernet because the method
can be applied to other data link protocols as well.
Information Elements in the middle section of Table 1 are necessary
for enabling the IPFIX and PSAMP traffic measurement for
[<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
Information Elements in the lower section of Table 1 are octet
counter or packet length for layer 2, and they are necessary for
enabling IPFIX and PSAMP traffic measurement for the data link layer.
<span class="grey">Kashima, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
+-----+------------------------------------+
| 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 Layer
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Existing Information Elements</span>
Some existing Information Elements are required for data link layer
export. Their details are reproduced here from IANA's IPFIX registry
[<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>]. Additions per this document appear between *.
<a href="#section-3.1.1">Section 3.1.1</a> introduces the missing Data Type Semantics for the
dataLinkFrameSize Information Element, which is held to be an
interoperable change per #4 in <a href="./rfc7013#section-5.2">Section 5.2 of [RFC7013]</a>.
<span class="grey">Kashima, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<a href="#section-3.1.2">Section 3.1.2</a> extends the definition of the dataLinkFrameSection
Information Element with reference to the new sectionOffset
Information Element, which is also an interoperable change per #4 in
<a href="./rfc7013#section-5.2">Section 5.2 of [RFC7013]</a>.
The layer2OctetDeltaCount Information Element reports the number of
layer 2 octets since the previous report in incoming packets for this
Flow, while 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 Information Element reports the total
number of incoming layer 2 frames for this Flow. All of these
Information Elements are unchanged from the existing IANA
[<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] definitions, and are reproduced in <a href="#section-3.1.3">Section 3.1.3</a> through
<a href="#section-3.1.6">Section 3.1.6</a> below for completeness.
Therefore, these changes do not introduce any backward-compatibility
issues.
Per <a href="./rfc7013#section-5.2">Section 5.2 of [RFC7013]</a>, for each of these changes, [<a href="./rfc7133">RFC7133</a>]
has been appended to the requester in IANA's IPFIX registry
[<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>], the Information Element's revision number has been
incremented by one, and the Information Element's revision date
column has been updated.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. dataLinkFrameSize</span>
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
<span class="grey">Kashima, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. dataLinkFrameSection</span>
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 [<a href="./rfc6313" title=""Export of Structured Data in IP Flow Information Export (IPFIX)"">RFC6313</a>]. Or a set of these
Information Elements MAY be contained in one Flow Record as shown
in <a href="./rfc7133#appendix-B">Appendix B of [RFC7133]</a>.
The data link layer is defined in [ISO/IEC.7498-1:1994].
Abstract Data Type: octetArray
ElementId: 315
References: [<a href="./rfc6313" title=""Export of Structured Data in IP Flow Information Export (IPFIX)"">RFC6313</a>] [<a href="./rfc7133">RFC7133</a>] [ISO/IEC.7498-1:1994]
Status: current
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. layer2OctetDeltaCount</span>
The layer2OctetDeltaCount Information Element is unchanged from the
existing IANA [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] definition and is reproduced here for
reference only.
<span class="grey">Kashima, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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
<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>. layer2OctetTotalCount</span>
The layer2OctetTotalCount Information Element is unchanged from the
existing IANA [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] 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
<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>. layer2FrameDeltaCount</span>
The layer2FrameDeltaCount Information Element is unchanged from the
existing IANA [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] definition and is reproduced here for
reference only.
<span class="grey">Kashima, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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
<span class="h4"><a class="selflink" id="section-3.1.6" href="#section-3.1.6">3.1.6</a>. layer2FrameTotalCount</span>
The layer2FrameTotalCount Information Element is unchanged from the
existing IANA [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] 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
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. New Information Elements</span>
The following new Information Elements have been added for data link
layer monitoring.
In IANA's IPFIX registry [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>], the Requester has been set to
[<a href="./rfc7133">RFC7133</a>], the Information Element's Revision has been set to zero,
and the Information Element's Date set to the date upon which the new
Information Elements have been added to the registry. All other
<span class="grey">Kashima, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
columns that are not explicitly mentioned below (e.g., Units, Range,
References) are not applicable and are to be left blank since the
registry does not explicitly record "not applicable".
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. dataLinkFrameType</span>
Description:
This Information Element specifies the type of the selected data
link frame.
The following data link types are defined here:
- 0x01 IEEE802.3 ETHERNET [<a href="#ref-IEEE802.3" title=""IEEE Standard for Ethernet"">IEEE802.3</a>]
- 0x02 IEEE802.11 MAC Frame format [<a href="#ref-IEEE802.11" title=""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"">IEEE802.11</a>]
Further values may be assigned by IANA. Note that the assigned
values are bits so that multiple observations can be OR'd
together.
The data link layer is defined in [ISO/IEC.7498-1:1994].
Abstract Data Type: unsigned16
Data Type Semantics: flags
ElementId: 408
References: [<a href="#ref-IEEE802.3" title=""IEEE Standard for Ethernet"">IEEE802.3</a>] [<a href="#ref-IEEE802.11" title=""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"">IEEE802.11</a>] [ISO/IEC.7498-1:1994]
Status: current
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. sectionOffset</span>
Description:
This Information Element specifies the offset of the packet
section (e.g., dataLinkFrameSection, ipHeaderPacketSection,
ipPayloadPacketSection, mplsLabelStackSection, and
mplsPayloadPacketSection). If this Information Element is
omitted, it defaults to zero (i.e., no offset).
If multiple sectionOffset Information Elements are specified
within a single Template, then they apply to the packet section
Information Elements in order: the first sectionOffset applies to
the first packet section, the second to the second, and so on.
Note that the "closest" sectionOffset and packet section
<span class="grey">Kashima, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Information Elements within a given Template are not necessarily
related. If there are fewer sectionOffset Information Elements
than packet section Information Elements, then subsequent packet
section Information Elements have no offset, i.e., a sectionOffset
of zero applies to those packet section Information Elements. If
there are more sectionOffset Information Elements than the number
of packet section Information Elements, then the additional
sectionOffset Information Elements are meaningless.
Abstract Data Type: unsigned16
Data Type Semantics: quantity
ElementId: 409
Status: current
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. sectionExportedOctets</span>
Description:
This Information Element specifies the observed length of the
packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection,
ipPayloadPacketSection, mplsLabelStackSection, and
mplsPayloadPacketSection) when padding is used.
The packet section may be of a fixed size larger than the
sectionExportedOctets. In this case, octets in the packet section
beyond the sectionExportedOctets MUST follow the [<a href="./rfc7011" title=""Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information"">RFC7011</a>] rules
for padding (i.e., be composed of zero (0) valued octets).
Abstract Data Type: unsigned16
Data Type Semantics: quantity
ElementId: 410
References: [<a href="./rfc7011" title=""Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information"">RFC7011</a>]
Status: current
<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>. dot1qServiceInstanceTag</span>
Description:
This Information Element, which is 16 octets long, represents the
Backbone Service Instance Tag (I-TAG) Tag Control Information
(TCI) field of an Ethernet frame as described in [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. It
<span class="grey">Kashima, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
encodes the Backbone Service Instance Priority Code Point (I-PCP),
Backbone Service Instance Drop Eligible Indicator (I-DEI), Use
Customer Addresses (UCAs), Backbone Service Instance Identifier
(I-SID), Encapsulated Customer Destination Address (C-DA),
Encapsulated Customer Source Address (C-SA), and reserved fields.
The structure and semantics within the Tag Control Information
field are defined in [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
Abstract Data Type: octetArray
Data Type Semantics: default
ElementId: 411
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
Status: current
<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>. dot1qServiceInstanceId</span>
Description:
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 [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
Abstract Data Type: unsigned32
Data Type Semantics: identifier
ElementId: 412
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
Status: current
Range: The valid range is 0 - 16777215 (i.e., 24 bits).
<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>. dot1qServiceInstancePriority</span>
Description:
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 [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
<span class="grey">Kashima, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 413
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
Status: current
Range: The valid range is 0-7.
<span class="h4"><a class="selflink" id="section-3.2.7" href="#section-3.2.7">3.2.7</a>. dot1qCustomerSourceMacAddress</span>
Description:
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
[<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
Abstract Data Type: macAddress
Data Type Semantics: default
ElementId: 414
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
Status: current
<span class="h4"><a class="selflink" id="section-3.2.8" href="#section-3.2.8">3.2.8</a>. dot1qCustomerDestinationMacAddress</span>
Description:
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
[<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
Abstract Data Type: macAddress
Data Type Semantics: default
ElementId: 415
<span class="grey">Kashima, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
Status: current
<span class="h4"><a class="selflink" id="section-3.2.9" href="#section-3.2.9">3.2.9</a>. postL2OctetDeltaCount</span>
Description:
The definition of this Information Element is identical to the
definition of the layer2OctetDeltaCount Information Element,
except that it reports a potentially modified value caused by a
middlebox function after the packet passed the Observation Point.
This Information Element is the layer 2 version of
postOctetDeltaCount (ElementId #23).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 417
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.10" href="#section-3.2.10">3.2.10</a>. postMCastL2OctetDeltaCount</span>
Description:
The number of layer 2 octets since the previous report (if any) in
outgoing multicast packets sent for packets of this Flow by a
multicast daemon within the Observation Domain. This property
cannot necessarily be observed at the Observation Point but may be
retrieved by other means. The number of octets includes layer 2
header(s) and layer 2 payload.
This Information Element is the layer 2 version of
postMCastOctetDeltaCount (ElementId #20).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 418
<span class="grey">Kashima, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.11" href="#section-3.2.11">3.2.11</a>. postL2OctetTotalCount</span>
Description:
The definition of this Information Element is identical to the
definition of the layer2OctetTotalCount Information Element,
except that it reports a potentially modified value caused by a
middlebox function after the packet passed the Observation Point.
This Information Element is the layer 2 version of
postOctetTotalCount (ElementId #171).
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 420
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.12" href="#section-3.2.12">3.2.12</a>. postMCastL2OctetTotalCount</span>
Description:
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 since the Metering Process (re-)initialization.
This property cannot necessarily be observed at the Observation
Point but may be retrieved by other means. The number of octets
includes layer 2 header(s) and layer 2 payload.
This Information Element is the layer 2 version of
postMCastOctetTotalCount (ElementId #175).
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
<span class="grey">Kashima, et al. Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
ElementId: 421
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.13" href="#section-3.2.13">3.2.13</a>. minimumL2TotalLength</span>
Description:
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 Information Element is the layer 2 version of
minimumIpTotalLength (ElementId #25).
Abstract Data Type: unsigned64
ElementId: 422
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.14" href="#section-3.2.14">3.2.14</a>. maximumL2TotalLength</span>
Description:
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 Information Element is the layer 2 version of
maximumIpTotalLength (ElementId #26).
Abstract Data Type: unsigned64
ElementId: 423
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
<span class="grey">Kashima, et al. Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.15" href="#section-3.2.15">3.2.15</a>. droppedL2OctetDeltaCount</span>
Description:
The number of layer 2 octets since the previous report (if any) in
packets of this Flow dropped by packet treatment. The number of
octets includes layer 2 header(s) and layer 2 payload.
This Information Element is the layer 2 version of
droppedOctetDeltaCount (ElementId #132).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 424
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.16" href="#section-3.2.16">3.2.16</a>. droppedL2OctetTotalCount</span>
Description:
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 Information Element is the layer 2 version of
droppedOctetTotalCount (ElementId #134).
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 425
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
<span class="grey">Kashima, et al. Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.17" href="#section-3.2.17">3.2.17</a>. ignoredL2OctetTotalCount</span>
Description:
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 Information Element is the layer 2 version of
ignoredOctetTotalCount (ElementId #165).
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 426
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.18" href="#section-3.2.18">3.2.18</a>. notSentL2OctetTotalCount</span>
Description:
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 Information Element is the layer 2 version of
notSentOctetTotalCount (ElementId #168).
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 427
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
<span class="grey">Kashima, et al. Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.19" href="#section-3.2.19">3.2.19</a>. layer2OctetDeltaSumOfSquares</span>
Description:
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. The number of octets includes layer 2
header(s) and layer 2 payload.
This Information Element is the layer 2 version of
octetDeltaSumOfSquares (ElementId #198).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 428
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
Units: octets
<span class="h4"><a class="selflink" id="section-3.2.20" href="#section-3.2.20">3.2.20</a>. layer2OctetTotalSumOfSquares</span>
Description:
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. The
number of octets includes layer 2 header(s) and layer 2 payload.
This Information Element is the layer 2 version of
octetTotalSumOfSquares (ElementId #199).
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 429
References: [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
<span class="grey">Kashima, et al. Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Status: current
Units: octets
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Modification of Existing Information Elements Related to Packet</span>
<span class="h2"> Section</span>
The new Information Elements related to packet section (i.e.,
sectionOffset and sectionExportedOctets) can be applied to not only
dataLinkFrameSection but also to all kinds of packet section (i.e.,
ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection,
and mplsPayloadPacketSection defined in [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]). Therefore,
existing Information Elements Descriptions should be modified as
follows.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. ipHeaderPacketSection</span>
This Information Element is defined in [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]. The description
has been updated from [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>].
Description:
This Information Element 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. However, full packet capture of arbitrary packet
streams is explicitly out of scope per the Security Considerations
sections of [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>] and [<a href="./rfc2804" title=""IETF Policy on Wiretapping"">RFC2804</a>].
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.
<span class="grey">Kashima, et al. Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Abstract Data Type: octetArray
ElementId: 313
References: [<a href="./rfc2804" title=""IETF Policy on Wiretapping"">RFC2804</a>] [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. ipPayloadPacketSection</span>
This Information Element is defined in [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]. The description is
updated from [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>].
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 [<a href="./rfc0791" title=""Internet Protocol"">RFC0791</a>] refers to as "data" or
"data octets". For example, see the examples in <a href="./rfc0791#appendix-A">[RFC0791],
Appendix A</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 [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] 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.
<span class="grey">Kashima, et al. Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Abstract Data Type: octetArray
ElementId: 314
References: [<a href="./rfc0791" title=""Internet Protocol"">RFC0791</a>] [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]
Status: current
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. mplsLabelStackSection</span>
This Information Element is defined in [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]. The description is
updated from [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>].
Description:
This Information Element 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. However, full packet capture of arbitrary packet
streams is explicitly out of scope per the Security Considerations
sections of [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>] and [<a href="./rfc2804" title=""IETF Policy on Wiretapping"">RFC2804</a>].
See [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>] for the specification of MPLS packets.
See [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] 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.
<span class="grey">Kashima, et al. Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Abstract Data Type: octetArray
ElementId: 316
References: [<a href="./rfc2804" title=""IETF Policy on Wiretapping"">RFC2804</a>] [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>] [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]
Status: current
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. mplsPayloadPacketSection</span>
This Information Element is defined in [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>]. The description is
updated from [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>].
Description:
The mplsPayloadPacketSection carries a series of n octets from the
MPLS payload of a sampled packet, starting sectionOffset octets
into the MPLS payload, as it is data that follows immediately
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 [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>] for the specification of MPLS packets.
See [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] 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
<span class="grey">Kashima, et al. Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
References: [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>] [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>]
Status: current
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Modification of Existing Information Elements Related to VLAN Tag</span>
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 <a href="#section-3">Section 3</a>,
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.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. dot1qVlanId</span>
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
[<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. 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 [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. 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 [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. In a virtual link between a host
system and EVB bridge, it represents the Service VLAN identifier
indicating S-channel as described in [<a href="#ref-IEEE802.1Qbg" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks: Amendment 21: Edge Virtual Bridging"">IEEE802.1Qbg</a>].
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: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>] [<a href="#ref-IEEE802.1Qbg" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks: Amendment 21: Edge Virtual Bridging"">IEEE802.1Qbg</a>]
<span class="grey">Kashima, et al. Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. dot1qPriority</span>
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
[<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]. 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 [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>],
except for I-TAG.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 244
Status: current
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. dot1qCustomerVlanId</span>
Description:
The value represents the Customer VLAN identifier in the Customer
VLAN Tag (C-TAG) Tag Control Information (TCI) field as described
in [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
Abstract Data Type: unsigned16
Data Type Semantics: identifier
ElementId: 245
Status: current
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. dot1qCustomerPriority</span>
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 [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>].
<span class="grey">Kashima, et al. Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 246
Status: current
References: [<a href="#ref-IEEE802.1Q" title=""IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks"">IEEE802.1Q</a>]
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. The Relationship between Ethernet Header Fields and Information</span>
<span class="h2"> Elements</span>
The following figures show a summary of various Ethernet header
fields and the Informational Elements that would be used to represent
each of the fields.
<-- 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 Fields
<-- 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 Fields
<span class="grey">Kashima, et al. Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<-- 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 Fields
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Reporting more granular data may increase the risk of DoS attacks
against a Collector. Protection against DoS attacks is discussed in
<a href="./rfc7011#section-11.4">Section 11.4 of [RFC7011]</a>.
The recommendations in this document do not otherwise introduce any
additional security issues beyond those already mentioned in
[<a href="./rfc7011" title=""Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information"">RFC7011</a>] and [<a href="./rfc5477" title=""Information Model for Packet Sampling Exports"">RFC5477</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
Existing IPFIX Information Elements [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] have been modified
as indicated in Sections <a href="#section-3.1">3.1</a>, <a href="#section-4">4</a>, and <a href="#section-5">5</a>.
Per <a href="./rfc7013#section-5.2">Section 5.2 of [RFC7013]</a>, for each of these changes, [<a href="./rfc7133">RFC7133</a>]
has been appended to the Requester in IANA's IPFIX registry
[<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>], the Information Element's Revision number has been
incremented by one, and the Information Element's revision Date
column has been updated.
New IPFIX Information Elements [<a href="#ref-IANA-IPFIX" title=""IP Flow Information Export (IPFIX) Entities"">IANA-IPFIX</a>] have been allocated as
shown in <a href="#section-3.2">Section 3.2</a>.
<span class="grey">Kashima, et al. Standards Track [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
Thanks to Brian Trammell and the IPFIX working group participants who
contributed to mailing-list discussions throughout the development of
this document. Special thanks to Pat Thaler for her help with the
IEEE 802 aspects of this work.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-IEEE802.11">IEEE802.11</a>] 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.
[<a id="ref-IEEE802.1BR">IEEE802.1BR</a>] IEEE, "IEEE Standard for Local and metropolitan area
networks: Virtual Bridged Local Area Networks: Bridge
Port Extension", IEEE Std 802.1BR-2012, July 2012.
[<a id="ref-IEEE802.1Q">IEEE802.1Q</a>] 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.
[<a id="ref-IEEE802.1Qbg">IEEE802.1Qbg</a>] 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.
[<a id="ref-IEEE802.3">IEEE802.3</a>] IEEE, "IEEE Standard for Ethernet", IEEE Std
802.3-2012, December 2012.
[<a id="ref-RFC0791">RFC0791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-RFC3031">RFC3031</a>] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", <a href="./rfc3031">RFC</a>
<a href="./rfc3031">3031</a>, January 2001.
<span class="grey">Kashima, et al. Standards Track [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
[<a id="ref-RFC3032">RFC3032</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.
[<a id="ref-RFC5477">RFC5477</a>] Dietz, T., Claise, B., Aitken, P., Dressler, F., and
G. Carle, "Information Model for Packet Sampling
Exports", <a href="./rfc5477">RFC 5477</a>, March 2009.
[<a id="ref-RFC6313">RFC6313</a>] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information
Export (IPFIX)", <a href="./rfc6313">RFC 6313</a>, July 2011.
[<a id="ref-RFC7011">RFC7011</a>] Claise, B., Trammell, B., and P. Aitken,
"Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of Flow
Information", STD 77, <a href="./rfc7011">RFC 7011</a>, September 2013.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-IANA-IPFIX">IANA-IPFIX</a>] IANA, "IP Flow Information Export (IPFIX) Entities",
<<a href="http://www.iana.org/assignments/ipfix">http://www.iana.org/assignments/ipfix</a>>.
[<a id="ref-IEEE802.1D">IEEE802.1D</a>] 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.
[<a id="ref-RFC2804">RFC2804</a>] IAB and IESG, "IETF Policy on Wiretapping", <a href="./rfc2804">RFC 2804</a>,
May 2000.
[<a id="ref-RFC7012">RFC7012</a>] Claise, B. and B. Trammell, "Information Model for IP
Flow Information Export (IPFIX)", <a href="./rfc7012">RFC 7012</a>, September
2013.
[<a id="ref-RFC7013">RFC7013</a>] Trammell, B. and B. Claise, "Guidelines for Authors
and Reviewers of IP Flow Information Export (IPFIX)
Information Elements", <a href="https://www.rfc-editor.org/bcp/bcp184">BCP 184</a>, <a href="./rfc7013">RFC 7013</a>, September
2013.
<span class="grey">Kashima, et al. Standards Track [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Frame Formats</span>
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 Format
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 Format
<span class="grey">Kashima, et al. Standards Track [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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 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
<span class="grey">Kashima, et al. Standards Track [Page 33]</span><span id="page-34" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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
<span class="grey">Kashima, et al. Standards Track [Page 34]</span><span id="page-35" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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
<span class="grey">Kashima, et al. Standards Track [Page 35]</span><span id="page-36" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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.
<span class="grey">Kashima, et al. Standards Track [Page 36]</span><span id="page-37" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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.
<span class="grey">Kashima, et al. Standards Track [Page 37]</span><span id="page-38" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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
<span class="grey">Kashima, et al. Standards Track [Page 38]</span><span id="page-39" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
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
<span class="grey">Kashima, et al. Standards Track [Page 39]</span><span id="page-40" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Template Format Example</span>
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 Example
<span class="grey">Kashima, et al. Standards Track [Page 40]</span><span id="page-41" ></span>
<span class="grey"><a href="./rfc7133">RFC 7133</a> Data Link Layer Information Elements May 2014</span>
Authors' Addresses
Shingo Kashima
Nippon Telegraph and Telephone Corporation
1-5-1 Otemachi
Chiyoda-ku, Tokyo 100-8116
Japan
Phone: +81 3 6838 5267
EMail: [email protected]
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: [email protected]
Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Commercial Street, Edinburgh EH6 6LX
United Kingdom
Phone: +44 131 561 3616
EMail: [email protected]
Kashima, et al. Standards Track [Page 41]
Annotations
Select text to annotate