One document matched: draft-ietf-ipfix-data-link-layer-monitoring-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5101 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml'>
<!ENTITY rfc5477 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5477.xml'>
<!ENTITY rfc6313 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6313.xml'>
<!ENTITY rfc6325 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6325.xml'>
<!ENTITY VXLAN PUBLIC 'VXLAN'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mahalingam-dutt-dcops-vxlan.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc autobreaks="yes" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<rfc category="std" ipr="pre5378Trust200902" docName="draft-ietf-ipfix-data-link-layer-monitoring-01">
<front>
<title abbrev='Data Link Information Elements'>Information Elements for Data Link Layer Traffic Measurement</title>
<author initials='S.K.' surname="Kashima" fullname='Shingo Kashima'>
<organization abbrev='NTT'>NTT Information Sharing Platform Lab.</organization>
<address>
<postal>
<street>Midori-Cho 3-9-11</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<phone>+81 422 59 3894</phone>
<email>kashima@nttv6.net</email>
</address>
</author>
<author initials='A.K.' surname="Kobayashi" fullname='Atsushi Kobayashi'>
<organization abbrev='NTT East'>NTT EAST IT Innovation Department</organization>
<address>
<postal>
<street>25F 3-20-2 Nishi-shinjuku</street>
<city>Shinjuku-ku</city>
<region>Tokyo</region>
<code>163-1425</code>
<country>Japan</country>
</postal>
<phone>+81 3 5353 3636</phone>
<email>akoba@nttv6.net</email>
</address>
</author>
<author initials='P.A.' surname="Aitken" fullname='Paul Aitken'>
<organization abbrev='Cisco Systems, Inc.'>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>96 Commercial Quay</street>
<city>Commercial Street</city>
<region>Edinburgh</region>
<code>EH6 6LX</code>
<country>United Kingdom</country>
</postal>
<phone>+44 131 561 3616</phone>
<email>paitken@cisco.com</email>
</address>
</author>
<date month="October" year="2012"/>
<area></area>
<workgroup>IP Flow Information Export</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.</t>
</abstract>
</front>
<middle>
<section title="Introduction"> <!-- 1 -->
<t>Ethernet <xref target="IEEE802.1D" /> and VLAN (Virtual LAN) <xref target="IEEE802.1Q-2005" /> technologies used to be used only in Local Area Networks. Recently, they have been used in Wide Area Networks, e.g., L2-VPN services. Accordingly, the IEEE802.1Q standard has been enhanced to <xref target="IEEE802.1ad-2005">IEEE802.1ad</xref> and <xref target="IEEE802.1ah-2008">IEEE802.1ah</xref>. And, Ethernet in data center also has been enhanced for server virtualization and I/O consolidation.</t>
<t>While these innovations provide flexibility, scalability, and mobility to an existing network architecture, it increases the complexity of traffic measurement due to the existence of various Ethernet header formats. To cope with this, a more sophisticated method is required.</t>
<t>IPFIX/PSAMP helps to resolve these problems. However, the PSAMP Information Model <xref target="RFC5477" /> and the IPFIX Information Model <xref target="RFC5101" /> are not yet enough for Information Elements related to data link layer, e.g., Ethernet header forms. This document describes the Information Elements related to data link layers that enable a more sophisticated traffic measurement method.</t>
<section title="Conventions Used in This Document"> <!-- 1.1 -->
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Extended Ethernet Technology"> <!-- 2 -->
<section title="Wide-Area Ethernet Summary"> <!-- 2.1 -->
<t><xref target="IEEE802.1ad-2005">Provider Bridge</xref> and <xref target="IEEE802.1ah-2008">Provider Backbone Bridge</xref>, which are standards for the Wide-Area Ethernet, are described below.</t>
<t>
<list style="symbols">
<t>In <xref target="IEEE802.1ad-2005">Provider Bridge</xref>, 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.</t>
<t>In <xref target="IEEE802.1ah-2008">Provider Backbone Bridge</xref>, 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 on <xref target="IEEE802.1ad-2005">IEEE802.1ad</xref> 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 B-PCP, B-DEI, I-PCP, and I-DEI.</t>
</list>
</t>
<t>Provider Backbone Bridge enables a wide-area Ethernet service to be improved from a flat network to a hierarchical network co-existing Provider Bridge and Provider Backbone Bridge.</t>
<t>Frame formats used in Wide-Area Ethernet are shown in Appendix A.</t>
</section>
<section title="Data Center Bridging Summary"> <!-- 2.2 -->
<t>
In data center networks, Ethernet needs to be enhanced to provide the flexibility, mobility for server virtualization, and I/O consolidation. In IEEE802.1 Data Center Bridging Task Group, several Ethernet header formats are proposed to enable a simplifying networks and server managements. <!--Not yet, they are -->
</t>
<t>The one of the enhanced methods is <xref target="IEEE802.1BR">Bridge Port Extension</xref>, which brings a traffic exchange point to upper bridges. Bridge Port Extension introduces a Ethernet format named Extension Tag (E-TAG) in addition to existing Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG) to move the policy enhancement to upper bridges in data center network. On the other hand, the complexity for traffic measurement would be increased, because multiple Ethernet header formats as shown in Appendix B co-exist in the same network.
</t>
</section>
<section title="Multiple Path Ethernet Summary"> <!-- 2.3 -->
<t>Inside data center networks, Ethernet need to be enhanced to support multiple path for effective utilization of bandwidth. Existing Ethernet does not support multiple path because it is based on <xref target="IEEE802.1D">STP (Spanning Tree Protocol)</xref>.</t>
<t>Two solutions for multiple path Ethernet are discussed for standardization. One is <xref target="IEEE802.1aq">Shortest Path Bridging</xref> in IEEE 802, the other is <xref target="RFC6325">TRILL (Transparent Interconnection of Lots of Links)</xref> in IETF. Both solutions realize multiple path with <xref target="ISO_IEC.10589_2002">IS-IS</xref> and Layer 2 over Layer 2 encapsulation. Shortest Path Bridging uses <xref target="IEEE802.1ah-2008">IEEE802.1ah</xref> header as an encapsulation technology and TRILL uses an unique header as shown in Section 3 of <xref target="RFC6325" />.</t>
<t>In multiple path Ethernet network, a traffic measurement based on MAC address and VLAN Tag is more important than single path Ethernet network in which traffic measurement is based on only VLAN Tag.</t>
</section>
<section title="VXLAN Summary"> <!-- 2.4 -->
<t>Inside and between data center networks, the existing Ethernet and VLAN technologies have two problems. One is that 12 bit of VLAN ID does not have enough length for identifying a lot of tenants. The other is that it is difficult to place same VLAN in multiple data centers.</t>
<t>The solution for the problems is <xref target="I-D.mahalingam-dutt-dcops-vxlan">VXLAN</xref>. VXLAN has 24 bit length of identifier named VXLAN Segment ID/VXLAN Network Identifier (VNI) and uses Layer 2 over Layer 3 encapsulation with the frame format as show in Section 5 of <xref target="I-D.mahalingam-dutt-dcops-vxlan" />.</t>
<t>In VXLAN networks, a traffic measurement based on multiple kinds of IP/MAC address and new VXLAN header is more important than existing Ethernet network in which traffic measurement is based on only VLAN Tag.</t>
</section>
</section>
<section title="New Information Elements"> <!-- 3 -->
<t>The following Information Elements whose ElementId are from 312 to TBD03 are necessary for enabling the IPFIX/PSAMP traffic measurement for data link layer, which is not limited to Ethernet because the method can be applied to other data link protocols as well.</t>
<t>The following Information Elements whose ElementId are from TBD04 to TBD08 are necessary for enabling the IPFIX/PSAMP traffic measurement for IEEE 802.1ah.</t>
<t>The following Information Elements whose ElementId are TBD09 from to TBD22 are octet counter or packet length for layer 2, and are necessary for enabling the IPFIX/PSAMP traffic measurement for data link layer.</t>
<t>Note that 312 and 315 are proposed IDs, subject to approval by IANA.</t>
<figure title="Table 1: New Information Elements">
<artwork><![CDATA[
+-----+------------------------------------+
| ID | Name |
+-----+------------------------------------+
| 312 | dataLinkFrameSize |
| 315 | dataLinkFrameSection |
|TBD01| dataLinkFrameType |
|TBD02| sectionOffset |
|TBD03| sectionObservedOctets |
|TBD04| dot1qServiceInstanceTag |
|TBD05| dot1qServiceInstanceId |
|TBD06| dot1qServiceInstancePriority |
|TBD07| dot1qCustomerDestinationMacAddress |
|TBD08| dot1qCustomerSourceMacAddress |
|TBD09| l2octetDeltaCount |
|TBD10| postMCastL2OctetDeltaCount |
|TBD11| postL2OctetDeltaCount |
|TBD12| minimumL2TotalLength |
|TBD13| maximumL2TotalLength |
|TBD14| l2octetTotalCount |
|TBD15| droppedL2OctetDeltaCount |
|TBD16| droppedL2OctetTotalCount |
|TBD17| ignoredL2OctetTotalCount |
|TBD18| notSentL2OctetTotalCount |
|TBD19| postL2OctetTotalCount |
|TBD20| postMCastL2OctetTotalCount |
|TBD21| l2octetDeltaSumOfSquares |
|TBD22| l2octetTotalSumOfSquares |
+-----+------------------------------------+
]]></artwork>
</figure>
<section title="dataLinkFrameSize">
<t>Description:</t>
<t>
<list>
<t>This Information Element specifies the length of the selected data link frame.</t>
<t></t>
<t>The data link layer is defined in <xref target="ISO_IEC.7498-1_1994"/>.</t>
</list>
</t>
<t>Abstract Data Type: unsigned16</t>
<t>Data Type Semantics: quantity</t>
<t>ElementId: 312</t>
<t>Status: current</t>
</section>
<section title="dataLinkFrameSection">
<t>Description:</t>
<t>
<list>
<t>This Information Element carries n octets from the data link frame of a selected frame, starting sectionOffset octets into the frame.</t>
<t></t>
<t>The sectionObservedOctets expresses how much data was observed, while the remainder is padding.</t>
<t></t>
<t>When the sectionObservedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length.</t>
<t></t>
<t>When the sectionObservedOctets 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.</t>
<t></t>
<t>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
<xref target="RFC6313"/>. Or a set of these Information Elements MAY be contained in one Flow Record as shown in Appendix C.</t>
<t></t>
<t>The data link layer is defined in <xref target="ISO_IEC.7498-1_1994"/>.</t>
</list>
</t>
<t>Abstract Data Type: octetArray</t>
<t>ElementId: 315</t>
<t>Status: current</t>
</section>
<section title="dataLinkFrameType">
<t>Description:</t>
<t>
<list>
<t>This Information Element specifies the type of the selected data link frame.</t>
<t></t>
<t>The following data link types are defined here.</t>
<t></t>
<t>- 0x01 ETHERNET</t>
<t></t>
<t>Further values may be assigned by IANA.</t>
<t></t>
<t>The data link layer is defined in <xref target="ISO_IEC.7498-1_1994"/>.</t>
</list>
</t>
<t>Abstract Data Type: unsigned16</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: TBD01</t>
<t>Status: current</t>
</section>
<section title="sectionOffset">
<t>Description:</t>
<t>
<list>
<t>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 (ie, no offset).</t>
<t>If multiple sectionOffset IEs are specified within a single Template, then they apply to the packet section IEs in order. ie, the first sectionOffset applies to the first packet section, etc. Note that the "closest" sectionOffset and packet section IEs within a given Template are not necessarily related. If there are less sectionOffset IEs than packet section IEs, then subsequent packet section IEs have no offset. If there are more sectionOffset IEs than the number of packet section IEs, then the additional sectionOffset IEs are meaningless.</t>
</list>
</t>
<t>Abstract Data Type: unsigned16</t>
<t>Data Type Semantics: quantity</t>
<t>ElementId: TBD02</t>
<t>Status: current</t>
</section>
<section title="sectionObservedOctets">
<t>Description:</t>
<t>
<list>
<t>This Information Element specifies the observed length of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection and mplsPayloadPacketSection) when padding is used.</t>
<t></t>
<t>The packet section may be of a fixed size larger than the sectionObservedOctets. In this case, octets in the packet section beyond the sectionObservedOctets MUST follow the <xref target="RFC5101"/> rules for padding (ie, be composed of zero (0) valued octets).</t></list>
</t>
<t>Abstract Data Type: unsigned16</t>
<t>Data Type Semantics: quantity</t>
<t>ElementId: TBD03</t>
<t>Status: current</t>
</section>
<section title="dot1qServiceInstanceTag">
<t>Description:</t>
<t>
<list>
<t>This Information Element, which may have 16 octets length, represents the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in <xref target="IEEE802.1ah-2008" />. It encodes the Backbone Service Instance Priority Code Point (I-PCP), Drop Eligible Indicator (I-DEI), Use Customer Addresses (UCA), Backbone Service Instance Identifier (I-SID), Encapsulated Customer Destination Address (C-DA), Encapsulated Customer Source Address (C-SA) and reserved fields.</t>
</list>
</t>
<t>Abstract Data Type: octetArray</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: TBD04</t>
<t>Status: current</t>
</section>
<section title="dot1qServiceInstanceId">
<t>Description:</t>
<t>
<list>
<t>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 section 9.8 of <xref target="IEEE802.1ah-2008" />. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah.</t>
</list>
</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: TBD05</t>
<t>Status: current</t>
</section>
<section title="dot1qServiceInstancePriority">
<t>Description:</t>
<t>
<list>
<t>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 section 9.8 of <xref target="IEEE802.1ah-2008" />. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: TBD06</t>
<t>Status: current</t>
</section>
<section title="dot1qCustomerDestinationMacAddress">
<t>Description:</t>
<t>
<list>
<t>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 section 9.8 of <xref target="IEEE802.1ah-2008" />. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah.</t>
</list>
</t>
<t>Abstract Data Type: macAddress</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: TBD07</t>
<t>Status: current</t>
</section>
<section title="dot1qCustomerSourceMacAddress">
<t>Description:</t>
<t>
<list>
<t>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 section 9.8 of <xref target="IEEE802.1ah-2008" />. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah.</t>
</list>
</t>
<t>Abstract Data Type: macAddress</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: TBD08</t>
<t>Status: current</t>
</section>
<section title="l2OctetDeltaCount">
<t>Description:</t>
<t>
<list>
<t>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. </t>
<t># memo: layer 2 version of octetDeltaCount (field #1)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: deltaCounter</t>
<t>ElementId: TBD09</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="postMCastL2OctetDeltaCount">
<t>Description:</t>
<t>
<list>
<t>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.
</t>
<t># memo: layer 2 version of postMCastOctetDeltaCount (field #20)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: deltaCounter</t>
<t>ElementId: TBD10</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="postL2OctetDeltaCount">
<t>Description:</t>
<t>
<list>
<t>The definition of this Information Element is identical to the definition of Information Element 'l2OctetDeltaCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point.</t>
<t># memo: layer 2 version of postOctetDeltaCount (field #23)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: deltaCounter</t>
<t>ElementId: TBD11</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="minimumL2TotalLength">
<t>Description:</t>
<t>
<list>
<t>Layer 2 length of the smallest packet observed for this Flow. The packet length includes the layer 2 header(s) length and the layer 2 payload length.</t>
<t># memo: layer 2 version of minimumIpTotalLength (field #25)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>ElementId: TBD12</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="maximumL2TotalLength">
<t>Description:</t>
<t>
<list>
<t>Layer 2 length of the largest packet observed for this Flow. The packet length includes the layer 2 header(s) length and the layer 2 payload length.</t>
<t># memo: layer 2 version of maximumIpTotalLength (field #26)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>ElementId: TBD13</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="l2octetTotalCount">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of octetTotalCount (field #85)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD14</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="droppedL2OctetDeltaCount">
<t>Description:</t>
<t>
<list>
<t>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 2payload.</t>
<t># memo: layer 2 version of droppedOctetDeltaCount (field #132)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: deltaCounter</t>
<t>ElementId: TBD15</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="droppedL2OctetTotalCount">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of droppedOctetTotalCount (field #134)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD16</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="ignoredL2OctetTotalCount">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of ignoredOctetTotalCount (field #165)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD17</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="notSentL2OctetTotalCount">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of notSentOctetTotalCount (field #168)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD18</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="postL2OctetTotalCount">
<t>Description:</t>
<t>
<list>
<t>The definition of this Information Element is identical to the definition of Information Element 'l2OctetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point.</t>
<t># memo: layer 2 version of postOctetTotalCount (field #171)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD19</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="postMCastL2OctetTotalCount">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of postMCastOctetTotalCount (field #175)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD20</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="l2octetDeltaSumOfSquares">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of octetDeltaSumOfSquares (field #198)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: deltaCounter</t>
<t>ElementId: TBD21</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
<section title="l2octetTotalSumOfSquares">
<t>Description:</t>
<t>
<list>
<t>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.</t>
<t># memo: layer 2 version of octetTotalSumOfSquares (field #199)</t>
</list>
</t>
<t>Abstract Data Type: unsigned64</t>
<t>Data Type Semantics: totalCounter</t>
<t>ElementId: TBD22</t>
<t>Status: current</t>
<t>Units: octets</t>
</section>
</section>
<section title="Modification of Existing Information Elements Related to Packet Section"> <!-- 4 -->
<t>--- This is open issue. --- </t>
<t></t>
<t>New Information Elements related to packet section (ie, sectionOffset and sectionObservedOctets) can be applied to not only dataLinkFrameSection but also all kinds of packet section. In this case, existing Information Elements Description should be modified as follows:</t>
<section title="ipHeaderPacketSection">
<t>Description:</t>
<t>
<list>
<t>TBD</t>
</list>
</t>
<t>Abstract Data Type: octetArray</t>
<t>ElementId: 313</t>
<t>Status: current</t>
</section>
<section title="ipPayloadPacketSection">
<t>Description:</t>
<t>
<list>
<t>TBD</t>
</list>
</t>
<t>Abstract Data Type: octetArray</t>
<t>ElementId: 314</t>
<t>Status: current</t>
</section>
<section title="mplsLabelStackSection">
<t>Description:</t>
<t>
<list>
<t>TBD</t>
</list>
</t>
<t>Abstract Data Type: octetArray</t>
<t>ElementId: 316</t>
<t>Status: current</t>
</section>
<section title="mplsPayloadPacketSection">
<t>Description:</t>
<t>
<list>
<t>TBD</t>
</list>
</t>
<t>Abstract Data Type: octetArray</t>
<t>ElementId: 317</t>
<t>Status: current</t>
</section>
</section>
<section title="Modification of Existing Information Elements Related to VLAN Tag"> <!-- 5 -->
<t>Information Elements related to Backbone Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG) are required in order to monitor IEEE802.1ah traffic with IPFIX/PSAMP. New Information Elements related to I-TAG are added in section 3 because I-TAG has different structure and semantics from Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG). On the other hand, Information Elements related to B-TAG reuse existing Information Elements related to C-TAG and S-TAG because B-TAG has same structure and semantics with C-TAG and S-TAG, Though they reuse existing Information Elements, it required to modify existing Descriptions and Reference as follows:</t>
<section title="dot1qVlanId">
<t>Description:</t>
<t>
<list>
<t>The value of the 12-bit VLAN Identifier portion of the Tag Control Information field of an Ethernet frame as described in section 3.5.5 of <xref target="IEEE802.3-2005" />. The structure and semantics within the Tag Control Information field are defined in IEEE P802.1Q. In case of a QinQ frame it represents the outer tag's VLAN identifier, in case of an IEEE 802.1ad frame it represents the Service VLAN identifier in the S-TAG Tag Control Information (TCI) field as described in <xref target="IEEE802.1ad-2005" /> and in case of an IEEE 802.1ah frame it represents the Backbone VLAN identifier in the B-TAG Tag Control Information (TCI) field as described in <xref target="IEEE802.1ah-2008" />.</t>
</list>
</t>
<t>Abstract Data Type: unsigned16</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: 243</t>
<t>Status: current</t>
<t>Reference:</t>
<t>
<list style="format (%d)" counter="1">
<t><xref target="IEEE802.3-2005" /></t>
<t><xref target="IEEE802.1ad-2005" /></t>
<t><xref target="IEEE802.1ah-2008" /></t>
</list>
</t>
</section>
<section title="dot1qPriority">
<t>Description:</t>
<t>
<list>
<t>The value of the 3-bit User Priority portion of the Tag Control Information field of an Ethernet frame as described in section 3.5.5 of <xref target="IEEE802.3-2005" />. The structure and semantics within the Tag Control Information field are defined in IEEE P802.1Q. In case of a QinQ frame it represents the outer tag's 3-bit Class of Service (CoS) identifier, in case of an IEEE 802.1ad frame it represents the 3-bit Priority Code Point (PCP) portion of the S-TAG Tag Control Information (TCI) field as described in <xref target="IEEE802.1ad-2005" /> and in case of an IEEE 802.1ah frame it represents the 3-bit Priority Code Point (PCP) portion of the B-TAG Tag Control Information (TCI) field as described in <xref target="IEEE802.1ah-2008" />.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: 244</t>
<t>Status: current</t>
<t>Reference:</t>
<t>
<list style="format (%d)" counter="2">
<t><xref target="IEEE802.3-2005" /></t>
<t><xref target="IEEE802.1ad-2005" /></t>
<t><xref target="IEEE802.1ah-2008" /></t>
</list>
</t>
</section>
<section title="dot1qCustomerVlanId">
<t>Description:</t>
<t>
<list>
<t>In case of a QinQ frame it represents the inner tag's (*) VLAN identifier, in case of an IEEE 802.1ad frame it represents the Customer VLAN identifier in the C-TAG Tag Control Information (TCI) field as described in <xref target="IEEE802.1ad-2005" /> and in case of an IEEE 802.1ah frame it represents the Customer VLAN identifier in the C-TAG Tag Control Information (TCI) field in encapsulated IEEE 802.1ad or IEEE 802.1Q frame as described in <xref target="IEEE802.1ah-2008" />.</t>
<t>(*) Note: the 802.1Q tag directly following the outer one.</t>
</list>
</t>
<t>Abstract Data Type: unsigned16</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: 245</t>
<t>Status: current</t>
<t>Reference:</t>
<t>
<list style="format (%d)" counter="3">
<t><xref target="IEEE802.1ad-2005" /></t>
<t><xref target="IEEE802.1Q-2005" /></t>
<t><xref target="IEEE802.1ah-2008" /></t>
</list>
</t>
</section>
<section title="dot1qCustomerPriority">
<t>Description:</t>
<t>
<list>
<t>In case of a QinQ frame it represents the inner tag's (*) Class of Service (CoS) identifier, in case of an IEEE 802.1ad frame it represents the 3-bit Priority Code Point (PCP) portion of the C-TAG Tag Control Information (TCI) field as described in <xref target="IEEE802.1ad-2005" /> and in case of an IEEE 802.1ah frame it represents the 3-bit Priority Code Point (PCP) portion of the C-TAG Tag Control Information (TCI) field in encapsulated IEEE 802.1ad or IEEE 802.1Q frame as described in <xref target="IEEE802.1ad-2005" />.</t>
<t>(*) Note: the 802.1Q tag directly following the outer one.</t>
</list>
</t>
<t>Abstract Data Type: unsigned8</t>
<t>Data Type Semantics: identifier</t>
<t>ElementId: 246</t>
<t>Status: current</t>
<t>Reference:</t>
<t>
<list style="format (%d)" counter="4">
<t><xref target="IEEE802.1ad-2005" /></t>
<t><xref target="IEEE802.1Q-2005" /></t>
<t><xref target="IEEE802.1ah-2008" /></t>
</list>
</t>
</section>
</section>
<section title="The relationship between Ethernet header fields and Information Elements"> <!-- 5 -->
<t></t>
<t>The following figures shows summary of various Ethernet header fields and the Informational Elements which would be used to represent each of the fields.</t>
<figure title="Figure 1: IEEE 802.1Q header fields">
<artwork><![CDATA[
<----6----><----6----><----4----><------2------>
+----------+----------+----------+--------------+
+ + + + +
+ C-DA + C-SA + C-TAG + Length/Type +
+ a + b + c + d +
+----------+----------+----------+--------------+
a.(Existing Information Element) destinationMacAddress 80
b.(Existing Information Element) sourceMacAddress 56
c.(Existing Information Elements) dot1qVlanId 243, dot1qPriority 244
d.(Existing Information Element) ethernetType 256
]]></artwork>
</figure>
<figure title="Figure 2: IEEE 802.1ad header fields">
<artwork><![CDATA[
<----6----><----6----><----4----><----4----><------2------>
+----------+----------+----------+----------+--------------+
+ + + + + +
+ C-DA + C-SA + S-TAG + C-TAG + Length/Type +
+ a + b + c + d + e +
+----------+----------+----------+----------+--------------+
a.(Existing Information Element) destinationMacAddress 80
b.(Existing Information Element) sourceMacAddress 56
c.(Existing Information Elements) dot1qVlanId 243, dot1qPriority 244
d.(Existing Information Elements) dot1qCustomerVlanId 245, dot1qCustomerPriority 246
e.(Existing Information Element) ethernetType 256
]]></artwork>
</figure>
<figure title="Figure 3: IEEE 802.1ah header fields">
<artwork><![CDATA[
<----6----><----6----><----4----><------18------><----4----><------2------>
+----------+----------+----------+---------------+----------+--------------+
+ + + + + + +
+ B-DA + B-SA + B-TAG + I-TAG + C-TAG + Length/Type +
+ a + b + c + d + e + f +
+----------+----------+----------+---------------+----------+--------------+
a.(Existing Information Element) destinationMacAddress 80
b.(Existing Information Element) sourceMacAddress 56
c.(Existing Information Elements) dot1qVlanId 243, dot1qPriority 244
d.(New Information Elements) defined in section 3.6, 3.7, 3.8, 3.9 and 3.10 of this draft
e.(Existing Information Elements) dot1qCustomerVlanId 245, dot1qCustomerPriority 246
f.(Existing Information Element) ethernetType 256
]]></artwork>
</figure>
</section>
<section title="Security Considerations"> <!-- 7 -->
<t>The recommendations in this document do not introduce any additional security issues to those already mentioned in <xref target="RFC5101"/> and <xref target="RFC5477"/>.</t>
</section>
<section title="IANA Considerations"> <!-- 8 -->
<t>This document requests that the Information Element IDs are allocated as shown in section 3</t>
<t>In addition, the dataLinkFrameType Information Element requires the creation of new IANA registries.</t>
<t>And this document requests that the existing Information Element Description are modified as shown in section 4 and 5</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
<reference anchor="IEEE802.3-2005">
<front>
<title>IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="IEEE Std" value="802.3-2005" />
</reference>
<reference anchor="IEEE802.1D">
<front>
<title>IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="June" year="2004" />
</front>
<seriesInfo name="IEEE Std" value="802.1D-2004" />
</reference>
<reference anchor="IEEE802.1Q-2005">
<front>
<title>IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="May" year="2006" />
</front>
<seriesInfo name="IEEE Std" value="802.1Q-2005" />
</reference>
<reference anchor="IEEE802.1ad-2005">
<front>
<title>IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="May" year="2006" />
</front>
<seriesInfo name="IEEE Std" value="802.1ad-2005" />
</reference>
<reference anchor="IEEE802.1ah-2008">
<front>
<title>IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="August" year="2008" />
</front>
<seriesInfo name="IEEE Std" value="802.1ah-2008" />
</reference>
<reference anchor="IEEE802.1BR">
<front>
<title>Draft Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment: Bridge Port Extension</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="February" year="2011" />
</front>
<seriesInfo name="IEEE Std" value="P802.1BR/D1.1" />
</reference>
<reference anchor="IEEE802.1aq">
<front>
<title>Draft Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment: Shortest Path Bridging</title>
<author initials="" surname="" fullname="">
<organization abbrev="">IEEE Computer Society</organization>
</author>
<date month="February" year="2011" />
</front>
<seriesInfo name="IEEE Std" value="P802.1aq/D3.6" />
</reference>
<reference anchor="ISO_IEC.10589_2002">
<front>
<title>Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)</title>
<author initials="" surname="" fullname="">
<organization abbrev="International Organization for Standardization">International Organization for Standardization</organization>
</author>
<date month="November" year="2002" />
</front>
<seriesInfo name="ISO Standard" value="10589:2002" />
</reference>
<reference anchor="ISO_IEC.7498-1_1994">
<front>
<title>Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Mode</title>
<author initials="" surname="" fullname="">
<organization abbrev="International Organization for Standardization">International Organization for Standardization</organization>
</author>
<date month="June" year="1996" />
</front>
<seriesInfo name="ISO Standard" value="7498-1:1994" />
</reference>
&rfc5101;
&rfc5477;
&rfc6313;
&rfc6325;
&VXLAN;
</references>
<section title="Frame Formats in Wide-Area Ethernet Network">
<figure title="Figure A-1: IEEE802.1D Frame Format in Customer Bridged Network">
<artwork><![CDATA[
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 ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure A-2: IEEE802.1Q Frame Format in Customer Bridged Network">
<artwork><![CDATA[
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 TCI=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure A-3: IEEE802.1ad (no C-Tag) Frame Format in Provider Bridged Network">
<artwork><![CDATA[
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 TCI=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure A-4: IEEE802.1ad (C-Tagged) Frame Format in Provider Bridged Network">
<artwork><![CDATA[
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 TCI=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TCI=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure A-5: IEEE802.1ah (no C-Tag) Frame Format in Provider Backbone Bridged Network">
<artwork><![CDATA[
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 TCI=0x88a8 |B-PCP|D| B-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-TAG TCI=0x88e7 |I-PCP|D|U| Res | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-SA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure A-6: IEEE802.1ah (C-Tagged) Frame Format in Provider Backbone Bridged Network">
<artwork><![CDATA[
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 TCI=0x88a8 |B-PCP|D| B-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-TAG TCI=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 ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Frame Formats in Data Center Network">
<figure title="Figure B-1: IEEE802.1BR (S-TAG) Frame Format in Data Center Network">
<artwork><![CDATA[
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 TCI=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure B-2: IEEE802.1BR (S-TAG+C-TAG) Frame Format in Data Center Network">
<artwork><![CDATA[
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 TCI=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TCI=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure B-3: IEEE802.1BR (E-TAG) Frame Format in Data Center Network">
<artwork><![CDATA[
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 TCI=0x893F |E-PCP|D| Ingress_E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|GRP| E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_E-CID_ext | E-CID_ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure title="Figure B-4: IEEE802.1BR (E-TAG+C-TAG) Frame Format in Data Center Network">
<artwork><![CDATA[
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 TCI=0x893F |E-PCP|D| Ingress_E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|GRP| E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_E-CID_ext | E-CID_ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TCI=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Template Formats Example">
<figure title="Figure C-1: Template Format Example">
<artwork><![CDATA[
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 (0x0002) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (0x0103) | Field Count (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface (0x000A) | Field Length (0x0004) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface (0x000E) | Field Length (0x0004) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|observationTimeSeconds (0x0142)| Field Length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dataLinkFrameSize (0x0138) | Field Length (0x0002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dataLinkFrameSection (0x013B) | Field Length (0xFF40) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dataLinkFrameType (0x015B) | Field Length (0x0002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sectionOffset (0x015C) | Field Length (0x0002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sectionObservedOctets (0x015D) | Field Length (0x0002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:02:11 |