doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc7133.txt b/doc/rfc/rfc7133.txt
new file mode 100644
index 0000000..a8dde38
--- /dev/null
+++ b/doc/rfc/rfc7133.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+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
+
+
+      Information Elements for Data Link Layer Traffic Measurement
+
+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 Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7133.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) 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.
+
+
+
+
+
+
+Kashima, et al.              Standards Track                    [Page 1]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Conventions Used in This Document ..........................4
+   2. Extended Ethernet Technology ....................................4
+      2.1. Wide-Area Ethernet Technology Summary ......................4
+      2.2. Virtual Ethernet Technology Summary ........................5
+   3. Modification and Addition of Information Elements
+      Related to Data Link Layer ......................................6
+      3.1. Existing Information Elements ..............................7
+           3.1.1. dataLinkFrameSize ...................................8
+           3.1.2. dataLinkFrameSection ................................9
+           3.1.3. layer2OctetDeltaCount ...............................9
+           3.1.4. layer2OctetTotalCount ..............................10
+           3.1.5. layer2FrameDeltaCount ..............................10
+           3.1.6. layer2FrameTotalCount ..............................11
+      3.2. New Information Elements ..................................11
+           3.2.1. dataLinkFrameType ..................................12
+           3.2.2. sectionOffset ......................................12
+           3.2.3. sectionExportedOctets ..............................13
+           3.2.4. dot1qServiceInstanceTag ............................13
+           3.2.5. dot1qServiceInstanceId .............................14
+           3.2.6. dot1qServiceInstancePriority .......................14
+           3.2.7. dot1qCustomerSourceMacAddress ......................15
+           3.2.8. dot1qCustomerDestinationMacAddress .................15
+           3.2.9. postL2OctetDeltaCount ..............................16
+           3.2.10. postMCastL2OctetDeltaCount ........................16
+           3.2.11. postL2OctetTotalCount .............................17
+           3.2.12. postMCastL2OctetTotalCount ........................17
+           3.2.13. minimumL2TotalLength ..............................18
+           3.2.14. maximumL2TotalLength ..............................18
+           3.2.15. droppedL2OctetDeltaCount ..........................19
+           3.2.16. droppedL2OctetTotalCount ..........................19
+           3.2.17. ignoredL2OctetTotalCount ..........................20
+           3.2.18. notSentL2OctetTotalCount ..........................20
+           3.2.19. layer2OctetDeltaSumOfSquares ......................21
+           3.2.20. layer2OctetTotalSumOfSquares ......................21
+   4. Modification of Existing Information Elements Related
+      to Packet Section ..............................................22
+      4.1. ipHeaderPacketSection .....................................22
+      4.2. ipPayloadPacketSection ....................................23
+      4.3. mplsLabelStackSection .....................................24
+      4.4. mplsPayloadPacketSection ..................................25
+   5. Modification of Existing Information Elements Related
+      to VLAN Tag ....................................................26
+      5.1. dot1qVlanId ...............................................26
+      5.2. dot1qPriority .............................................27
+      5.3. dot1qCustomerVlanId .......................................27
+
+
+
+Kashima, et al.              Standards Track                    [Page 2]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+      5.4. dot1qCustomerPriority .....................................27
+   6. The Relationship between Ethernet Header Fields and
+      Information Elements ...........................................28
+   7. Security Considerations ........................................29
+   8. IANA Considerations ............................................29
+   9. Acknowledgments ................................................30
+   10. References ....................................................30
+      10.1. Normative References .....................................30
+      10.2. Informative References ...................................31
+   Appendix A.  Frame Formats ........................................32
+   Appendix B.  Template Format Example ..............................40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                    [Page 3]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+1.  Introduction
+
+   Ethernet [IEEE802.1D] 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 [IEEE802.1Q].  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 [RFC5477] and the IPFIX
+   Information Model [RFC7011] 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 [RFC5477] or [RFC7011]
+   because IANA's IPFIX registry [IANA-IPFIX] is the ultimate
+   Information Element reference, per Section 1 of [RFC7012].
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Extended Ethernet Technology
+
+2.1.  Wide-Area Ethernet Technology Summary
+
+   Provider Bridge and Provider Backbone Bridge [IEEE802.1Q], which are
+   standards for Wide-Area Ethernet, are described below.
+
+   o  In Provider Bridge [IEEE802.1Q], 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.
+
+
+
+Kashima, et al.              Standards Track                    [Page 4]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   o  In Provider Backbone Bridge [IEEE802.1Q], 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 Appendix A.
+
+2.2.  Virtual Ethernet Technology Summary
+
+   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) [IEEE802.1Qbg].  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
+
+
+
+Kashima, et al.              Standards Track                    [Page 5]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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)
+   [IEEE802.1Q].  When S-channel is in use, frames on the link carry an
+   S-TAG to identify the S-channel.
+
+   On the other hand, Bridge Port Extension emulates 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 [IEEE802.1BR].
+
+   Traffic monitoring over S-channel and E-channel is required in order
+   to get visibility of VM-to-VM traffic and visibility of each
+   channel's traffic on a virtual link.
+
+   Frame formats with E-TAG used in E-channel and S-TAG used in
+   S-channel are shown in Appendix A.  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.
+
+3.  Modification and Addition of Information Elements Related to Data
+    Link Layer
+
+   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
+   [IEEE802.1Q].
+
+   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.
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                    [Page 6]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+               +-----+------------------------------------+
+               | 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
+
+3.1.  Existing Information Elements
+
+   Some existing Information Elements are required for data link layer
+   export.  Their details are reproduced here from IANA's IPFIX registry
+   [IANA-IPFIX].  Additions per this document appear between *.
+
+   Section 3.1.1 introduces the missing Data Type Semantics for the
+   dataLinkFrameSize Information Element, which is held to be an
+   interoperable change per #4 in Section 5.2 of [RFC7013].
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                    [Page 7]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Section 3.1.2 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
+   Section 5.2 of [RFC7013].
+
+   The layer2OctetDeltaCount Information Element reports the number of
+   layer 2 octets since the previous report in incoming packets for this
+   Flow, 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
+   [IANA-IPFIX] definitions, and are reproduced in Section 3.1.3 through
+   Section 3.1.6 below for completeness.
+
+   Therefore, these changes do not introduce any backward-compatibility
+   issues.
+
+   Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133]
+   has been appended to the requester in IANA's IPFIX registry
+   [IANA-IPFIX], the Information Element's revision number has been
+   incremented by one, and the Information Element's revision date
+   column has been updated.
+
+3.1.1.  dataLinkFrameSize
+
+   Description:
+
+      This Information Element specifies the length of the selected data
+      link frame.
+
+      The data link layer is defined in [ISO/IEC.7498-1:1994].
+
+   Abstract Data Type: unsigned16
+
+   *Data Type Semantics: quantity*
+
+   ElementId: 312
+
+   References: [ISO/IEC.7498-1:1994]
+
+   Status: current
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                    [Page 8]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+3.1.2.  dataLinkFrameSection
+
+   Description:
+
+      This Information Element carries n octets from the data link frame
+      of a selected frame, starting sectionOffset octets into the frame.
+
+      *However, if no sectionOffset field corresponding to this
+      Information Element is present, then a sectionOffset of zero
+      applies, and the octets MUST be from the start of the data link
+      frame.*
+
+      The sectionExportedOctets expresses how much data was observed,
+      while the remainder is padding.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element exists, this Information Element MAY have a
+      fixed length and MAY be padded, or it MAY have a variable length.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element does not exist, this Information Element
+      SHOULD have a variable length and MUST NOT be padded.  In this
+      case, the size of the exported section may be constrained due to
+      limitations in the IPFIX protocol.
+
+      Further Information Elements, i.e., dataLinkFrameType and
+      dataLinkFrameSize, are needed to specify the data link type and
+      the size of the data link frame of this Information Element.  A
+      set of these Information Elements MAY be contained in a structured
+      data type, as expressed in [RFC6313].  Or a set of these
+      Information Elements MAY be contained in one Flow Record as shown
+      in Appendix B of [RFC7133].
+
+      The data link layer is defined in [ISO/IEC.7498-1:1994].
+
+   Abstract Data Type: octetArray
+
+   ElementId: 315
+
+   References: [RFC6313] [RFC7133] [ISO/IEC.7498-1:1994]
+
+   Status: current
+
+3.1.3.  layer2OctetDeltaCount
+
+   The layer2OctetDeltaCount Information Element is unchanged from the
+   existing IANA [IANA-IPFIX] definition and is reproduced here for
+   reference only.
+
+
+
+Kashima, et al.              Standards Track                    [Page 9]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Description
+
+      The number of layer 2 octets since the previous report (if any) in
+      incoming packets for this Flow at the Observation Point.  The
+      number of octets includes layer 2 header(s) and layer 2 payload.
+
+   Abstract Data Type: unsigned64
+
+   Data Type Semantics: deltaCounter
+
+   Units: octets
+
+   ElementId: 352
+
+   Status: current
+
+3.1.4.  layer2OctetTotalCount
+
+   The layer2OctetTotalCount Information Element is unchanged from the
+   existing IANA [IANA-IPFIX] definition and is reproduced here for
+   reference only.
+
+   Description:
+
+      The total number of layer 2 octets in incoming packets for this
+      Flow at the Observation Point since the Metering Process
+      (re-)initialization for this Observation Point.  The number of
+      octets includes layer 2 header(s) and layer 2 payload.
+
+   Abstract Data Type: unsigned64
+
+   Data Type Semantics: totalCounter
+
+   Units: octets
+
+   ElementId: 353
+
+   Status: current
+
+3.1.5.  layer2FrameDeltaCount
+
+   The layer2FrameDeltaCount Information Element is unchanged from the
+   existing IANA [IANA-IPFIX] definition and is reproduced here for
+   reference only.
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 10]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Description:
+
+      The number of incoming layer 2 frames since the previous report
+      (if any) for this Flow at the Observation Point.
+
+   Abstract Data Type: unsigned64
+
+   Data Type Semantics: deltaCounter
+
+   Units: frames
+
+   ElementId: 430
+
+   Status: current
+
+3.1.6.  layer2FrameTotalCount
+
+   The layer2FrameTotalCount Information Element is unchanged from the
+   existing IANA [IANA-IPFIX] definition and is reproduced here for
+   reference only.
+
+   Description:
+
+      The total number of incoming layer 2 frames for this Flow at the
+      Observation Point since the Metering Process (re-)initialization
+      for this Observation Point.
+
+   Abstract Data Type: unsigned64
+
+   Data Type Semantics: totalCounter
+
+   Units: frames
+
+   ElementId: 431
+
+   Status: current
+
+3.2.  New Information Elements
+
+   The following new Information Elements have been added for data link
+   layer monitoring.
+
+   In IANA's IPFIX registry [IANA-IPFIX], the Requester has been set to
+   [RFC7133], 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
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 11]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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".
+
+3.2.1.  dataLinkFrameType
+
+   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 [IEEE802.3]
+
+      - 0x02 IEEE802.11 MAC Frame format [IEEE802.11]
+
+      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: [IEEE802.3] [IEEE802.11] [ISO/IEC.7498-1:1994]
+
+   Status: current
+
+3.2.2.  sectionOffset
+
+   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
+
+
+
+Kashima, et al.              Standards Track                   [Page 12]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+      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
+
+3.2.3.  sectionExportedOctets
+
+   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 [RFC7011] rules
+      for padding (i.e., be composed of zero (0) valued octets).
+
+   Abstract Data Type: unsigned16
+
+   Data Type Semantics: quantity
+
+   ElementId: 410
+
+   References: [RFC7011]
+
+   Status: current
+
+3.2.4.  dot1qServiceInstanceTag
+
+   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 [IEEE802.1Q].  It
+
+
+
+Kashima, et al.              Standards Track                   [Page 13]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+      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 [IEEE802.1Q].
+
+   Abstract Data Type: octetArray
+
+   Data Type Semantics: default
+
+   ElementId: 411
+
+   References: [IEEE802.1Q]
+
+   Status: current
+
+3.2.5.  dot1qServiceInstanceId
+
+   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 [IEEE802.1Q].
+
+   Abstract Data Type: unsigned32
+
+   Data Type Semantics: identifier
+
+   ElementId: 412
+
+   References: [IEEE802.1Q]
+
+   Status: current
+
+   Range: The valid range is 0 - 16777215 (i.e., 24 bits).
+
+3.2.6.  dot1qServiceInstancePriority
+
+   Description:
+
+      The value of the 3-bit Backbone Service Instance Priority Code
+      Point (I-PCP) portion of the Backbone Service Instance Tag (I-TAG)
+      Tag Control Information (TCI) field of an Ethernet frame as
+      described in [IEEE802.1Q].
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 14]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Abstract Data Type: unsigned8
+
+   Data Type Semantics: identifier
+
+   ElementId: 413
+
+   References: [IEEE802.1Q]
+
+   Status: current
+
+   Range: The valid range is 0-7.
+
+3.2.7.  dot1qCustomerSourceMacAddress
+
+   Description:
+
+      The value of the Encapsulated Customer Source Address (C-SA)
+      portion of the Backbone Service Instance Tag (I-TAG) Tag Control
+      Information (TCI) field of an Ethernet frame as described in
+      [IEEE802.1Q].
+
+   Abstract Data Type: macAddress
+
+   Data Type Semantics: default
+
+   ElementId: 414
+
+   References: [IEEE802.1Q]
+
+   Status: current
+
+3.2.8.  dot1qCustomerDestinationMacAddress
+
+   Description:
+
+      The value of the Encapsulated Customer Destination Address (C-DA)
+      portion of the Backbone Service Instance Tag (I-TAG) Tag Control
+      Information (TCI) field of an Ethernet frame as described in
+      [IEEE802.1Q].
+
+   Abstract Data Type: macAddress
+
+   Data Type Semantics: default
+
+   ElementId: 415
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 15]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   References: [IEEE802.1Q]
+
+   Status: current
+
+3.2.9.  postL2OctetDeltaCount
+
+   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: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.10.  postMCastL2OctetDeltaCount
+
+   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
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 16]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   References: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.11.  postL2OctetTotalCount
+
+   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: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.12.  postMCastL2OctetTotalCount
+
+   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
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 17]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   ElementId: 421
+
+   References: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.13.  minimumL2TotalLength
+
+   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: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.14.  maximumL2TotalLength
+
+   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: [RFC5477]
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 18]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Status: current
+
+   Units: octets
+
+3.2.15.  droppedL2OctetDeltaCount
+
+   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: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.16.  droppedL2OctetTotalCount
+
+   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: [RFC5477]
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 19]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Status: current
+
+   Units: octets
+
+3.2.17.  ignoredL2OctetTotalCount
+
+   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: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.18.  notSentL2OctetTotalCount
+
+   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: [RFC5477]
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 20]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Status: current
+
+   Units: octets
+
+3.2.19.  layer2OctetDeltaSumOfSquares
+
+   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: [RFC5477]
+
+   Status: current
+
+   Units: octets
+
+3.2.20.  layer2OctetTotalSumOfSquares
+
+   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: [RFC5477]
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 21]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Status: current
+
+   Units: octets
+
+4.  Modification of Existing Information Elements Related to Packet
+    Section
+
+   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 [RFC5477]).  Therefore,
+   existing Information Elements Descriptions should be modified as
+   follows.
+
+4.1.  ipHeaderPacketSection
+
+   This Information Element is defined in [RFC5477].  The description
+   has been updated from [RFC5477].
+
+   Description:
+
+      This 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 [RFC5477] and [RFC2804].
+
+      The sectionExportedOctets expresses how much data was exported,
+      while the remainder is padding.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element exists, this Information Element MAY have a
+      fixed length and MAY be padded, or it MAY have a variable length.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element does not exist, this Information Element
+      SHOULD have a variable length and MUST NOT be padded.  In this
+      case, the size of the exported section may be constrained due to
+      limitations in the IPFIX protocol.
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 22]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Abstract Data Type: octetArray
+
+   ElementId: 313
+
+   References: [RFC2804] [RFC5477]
+
+   Status: current
+
+4.2.  ipPayloadPacketSection
+
+   This Information Element is defined in [RFC5477].  The description is
+   updated from [RFC5477].
+
+   Description:
+
+      This Information Element carries a series of n octets from the IP
+      payload of a sampled packet, starting sectionOffset octets into
+      the IP payload.
+
+      However, if no sectionOffset field corresponding to this
+      Information Element is present, then a sectionOffset of zero
+      applies, and the octets MUST be from the start of the IP payload.
+
+      The IPv4 payload is that part of the packet that follows the IPv4
+      header and any options, which [RFC0791] refers to as "data" or
+      "data octets".  For example, see the examples in [RFC0791],
+      Appendix A.
+
+      The IPv6 payload is the rest of the packet following the 40-octet
+      IPv6 header.  Note that any extension headers present are
+      considered part of the payload.  See [RFC2460] for the IPv6
+      specification.
+
+      The sectionExportedOctets expresses how much data was observed,
+      while the remainder is padding.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element exists, this Information Element MAY have a
+      fixed length and MAY be padded, or it MAY have a variable length.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element does not exist, this Information Element
+      SHOULD have a variable length and MUST NOT be padded.  In this
+      case, the size of the exported section may be constrained due to
+      limitations in the IPFIX protocol.
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 23]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Abstract Data Type: octetArray
+
+   ElementId: 314
+
+   References: [RFC0791] [RFC2460]
+
+   Status: current
+
+4.3.  mplsLabelStackSection
+
+   This Information Element is defined in [RFC5477].  The description is
+   updated from [RFC5477].
+
+   Description:
+
+      This 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 [RFC5477] and [RFC2804].
+
+      See [RFC3031] for the specification of MPLS packets.
+
+      See [RFC3032] for the specification of the MPLS label stack.
+
+      The sectionExportedOctets expresses how much data was observed,
+      while the remainder is padding.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element exists, this Information Element MAY have a
+      fixed length and MAY be padded, or it MAY have a variable length.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element does not exist, this Information Element
+      SHOULD have a variable length and MUST NOT be padded.  In this
+      case, the size of the exported section may be constrained due to
+      limitations in the IPFIX protocol.
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 24]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Abstract Data Type: octetArray
+
+   ElementId: 316
+
+   References: [RFC2804] [RFC3031] [RFC3032] [RFC5477]
+
+   Status: current
+
+4.4.  mplsPayloadPacketSection
+
+   This Information Element is defined in [RFC5477].  The description is
+   updated from [RFC5477].
+
+   Description:
+
+      The mplsPayloadPacketSection carries a series of n octets from the
+      MPLS payload of a sampled packet, starting sectionOffset octets
+      into the MPLS payload, 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 [RFC3031] for the specification of MPLS packets.
+
+      See [RFC3032] for the specification of the MPLS label stack.
+
+      The sectionExportedOctets expresses how much data was observed,
+      while the remainder is padding.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element exists, this Information Element MAY have a
+      fixed length and MAY be padded, or it MAY have a variable length.
+
+      When the sectionExportedOctets field corresponding to this
+      Information Element does not exist, this Information Element
+      SHOULD have a variable length and MUST NOT be padded.  In this
+      case, the size of the exported section may be constrained due to
+      limitations in the IPFIX protocol.
+
+   Abstract Data Type: octetArray
+
+   ElementId: 317
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 25]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   References: [RFC3031] [RFC3032]
+
+   Status: current
+
+5.  Modification of Existing Information Elements Related to VLAN Tag
+
+   The traffic measurement using IPFIX and PSAMP for a Provider Backbone
+   Bridged Network requires the Information Elements related to Backbone
+   Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG).  The set
+   of Information Elements related to I-TAG is added in Section 3,
+   because I-TAG structure and semantics are different from that of
+   Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG).  The set of
+   Information Elements related to B-TAG reuses the existing Information
+   Elements, because B-TAG structure and semantics are identical to that
+   of C-TAG and S-TAG.  This section modifies existing descriptions and
+   references related to C-TAG and S-TAG as follows.
+
+5.1.  dot1qVlanId
+
+   Description:
+
+      The value of the 12-bit VLAN Identifier portion of the Tag Control
+      Information field of an Ethernet frame.  The structure and
+      semantics within the Tag Control Information field are defined in
+      [IEEE802.1Q].  In Provider Bridged Networks, it represents the
+      Service VLAN identifier in the Service VLAN Tag (S-TAG) Tag
+      Control Information (TCI) field or the Customer VLAN identifier in
+      the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field
+      as described in [IEEE802.1Q].  In Provider Backbone Bridged
+      Networks, it represents the Backbone VLAN identifier in the
+      Backbone VLAN Tag (B-TAG) Tag Control Information (TCI) field as
+      described in [IEEE802.1Q].  In a virtual link between a host
+      system and EVB bridge, it represents the Service VLAN identifier
+      indicating S-channel as described in [IEEE802.1Qbg].
+
+      In the case of a multi-tagged frame, it represents the outer tag's
+      VLAN identifier, except for I-TAG.
+
+   Abstract Data Type: unsigned16
+
+   Data Type Semantics: identifier
+
+   ElementId: 243
+
+   Status: current
+
+   References: [IEEE802.1Q] [IEEE802.1Qbg]
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 26]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+5.2.  dot1qPriority
+
+   Description:
+
+      The value of the 3-bit User Priority portion of the Tag Control
+      Information field of an Ethernet frame.  The structure and
+      semantics within the Tag Control Information field are defined in
+      [IEEE802.1Q].  In the case of a multi-tagged frame, it represents
+      the 3-bit Priority Code Point (PCP) portion of the outer tag's Tag
+      Control Information (TCI) field as described in [IEEE802.1Q],
+      except for I-TAG.
+
+   Abstract Data Type: unsigned8
+
+   Data Type Semantics: identifier
+
+   ElementId: 244
+
+   Status: current
+
+   References: [IEEE802.1Q]
+
+5.3.  dot1qCustomerVlanId
+
+   Description:
+
+      The value represents the Customer VLAN identifier in the Customer
+      VLAN Tag (C-TAG) Tag Control Information (TCI) field as described
+      in [IEEE802.1Q].
+
+   Abstract Data Type: unsigned16
+
+   Data Type Semantics: identifier
+
+   ElementId: 245
+
+   Status: current
+
+   References: [IEEE802.1Q]
+
+5.4.  dot1qCustomerPriority
+
+   Description:
+
+      The value represents the 3-bit Priority Code Point (PCP) portion
+      of the Customer VLAN Tag (C-TAG) Tag Control Information (TCI)
+      field as described in [IEEE802.1Q].
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 27]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   Abstract Data Type: unsigned8
+
+   Data Type Semantics: identifier
+
+   ElementId: 246
+
+   Status: current
+
+   References: [IEEE802.1Q]
+
+6.  The Relationship between Ethernet Header Fields and Information
+    Elements
+
+   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
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 28]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+    <-- 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
+
+7.  Security Considerations
+
+   Reporting more granular data may increase the risk of DoS attacks
+   against a Collector.  Protection against DoS attacks is discussed in
+   Section 11.4 of [RFC7011].
+
+   The recommendations in this document do not otherwise introduce any
+   additional security issues beyond those already mentioned in
+   [RFC7011] and [RFC5477].
+
+8.  IANA Considerations
+
+   Existing IPFIX Information Elements [IANA-IPFIX] have been modified
+   as indicated in Sections 3.1, 4, and 5.
+
+   Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133]
+   has been appended to the Requester in IANA's IPFIX registry
+   [IANA-IPFIX], the Information Element's Revision number has been
+   incremented by one, and the Information Element's revision Date
+   column has been updated.
+
+   New IPFIX Information Elements [IANA-IPFIX] have been allocated as
+   shown in Section 3.2.
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 29]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+9.  Acknowledgments
+
+   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.
+
+10.  References
+
+10.1.  Normative References
+
+   [IEEE802.11]   IEEE, "IEEE Standard for Information technology.
+                  Telecommunications and information exchange between
+                  systems Local and metropolitan area networks.
+                  Specific requirements Part 11: Wireless LAN Medium
+                  Access Control (MAC) and Physical Layer (PHY)
+                  Specifications", IEEE Std 802.11-2012, March 2012.
+
+   [IEEE802.1BR]  IEEE, "IEEE Standard for Local and metropolitan area
+                  networks: Virtual Bridged Local Area Networks: Bridge
+                  Port Extension", IEEE Std 802.1BR-2012, July 2012.
+
+   [IEEE802.1Q]   IEEE, "IEEE Standard for Local and metropolitan area
+                  networks: Media Access Control (MAC) Bridges and
+                  Virtual Bridged Local Area Networks", IEEE Std
+                  802.1Q-2011, August 2011.
+
+   [IEEE802.1Qbg] IEEE, "IEEE Standard for Local and metropolitan area
+                  networks: Media Access Control (MAC) Bridges and
+                  Virtual Bridged Local Area Networks: Amendment 21:
+                  Edge Virtual Bridging", IEEE Std 802.1Qbg-2012, July
+                  2012.
+
+   [IEEE802.3]    IEEE, "IEEE Standard for Ethernet", IEEE Std
+                  802.3-2012, December 2012.
+
+   [RFC0791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
+                  September 1981.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
+                  6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3031]      Rosen, E., Viswanathan, A., and R. Callon,
+                  "Multiprotocol Label Switching Architecture", RFC
+                  3031, January 2001.
+
+
+
+Kashima, et al.              Standards Track                   [Page 30]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   [RFC3032]      Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                  Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+                  Encoding", RFC 3032, January 2001.
+
+   [RFC5477]      Dietz, T., Claise, B., Aitken, P., Dressler, F., and
+                  G.  Carle, "Information Model for Packet Sampling
+                  Exports", RFC 5477, March 2009.
+
+   [RFC6313]      Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
+                  "Export of Structured Data in IP Flow Information
+                  Export (IPFIX)", RFC 6313, July 2011.
+
+   [RFC7011]      Claise, B., Trammell, B., and P. Aitken,
+                  "Specification of the IP Flow Information Export
+                  (IPFIX) Protocol for the Exchange of Flow
+                  Information", STD 77, RFC 7011, September 2013.
+
+10.2.  Informative References
+
+   [IANA-IPFIX]   IANA, "IP Flow Information Export (IPFIX) Entities",
+                  <http://www.iana.org/assignments/ipfix>.
+
+   [IEEE802.1D]   IEEE, "IEEE Standard for Local and metropolitan area
+                  networks: Media Access Control (MAC) Bridges", IEEE
+                  Std 802.1D-2004, June 2004.
+
+   [ISO/IEC.7498-1:1994]
+                  International Organization for Standardization,
+                  "Information technology -- Open Systems
+                  Interconnection -- Basic Reference Model: The Basic
+                  Mode", ISO Standard 7498-1:1994, June 1996.
+
+   [RFC2804]      IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
+                  May 2000.
+
+   [RFC7012]      Claise, B. and B. Trammell, "Information Model for IP
+                  Flow Information Export (IPFIX)", RFC 7012, September
+                  2013.
+
+   [RFC7013]      Trammell, B. and B. Claise, "Guidelines for Authors
+                  and Reviewers of IP Flow Information Export (IPFIX)
+                  Information Elements", BCP 184, RFC 7013, September
+                  2013.
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 31]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+Appendix A.  Frame Formats
+
+   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
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 32]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 33]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 34]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 35]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 36]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 37]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 38]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 39]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+Appendix B.  Template Format Example
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 40]
+
+RFC 7133          Data Link Layer Information Elements          May 2014
+
+
+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: kashima@nttv6.net
+
+
+   Atsushi Kobayashi
+   Nippon Telegraph and Telephone East Corporation
+   3-19-2 Nishi-shinjuku
+   Shinjuku-ku, Tokyo  163-8019
+   Japan
+
+   Phone: +81 3 5359 4351
+   EMail: akoba@nttv6.net
+
+
+   Paul Aitken
+   Cisco Systems, Inc.
+   96 Commercial Quay
+   Commercial Street, Edinburgh  EH6 6LX
+   United Kingdom
+
+   Phone: +44 131 561 3616
+   EMail: paitken@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kashima, et al.              Standards Track                   [Page 41]
+