Skip to main content

Information Elements for Data Link Layer Traffic Measurement
draft-ietf-ipfix-data-link-layer-monitoring-08

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7133.
Authors Shingo Kashima , Atsushi Kobayashi , Paul Aitken
Last updated 2015-10-14 (Latest revision 2013-12-24)
Replaces draft-kashima-ipfix-data-link-layer-monitoring
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Eliot Lear
Shepherd write-up Show Last changed 2013-10-09
IESG IESG state Became RFC 7133 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Benoît Claise
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
draft-ietf-ipfix-data-link-layer-monitoring-08
IP Flow Information Export                                    S. Kashima
Internet-Draft                                                       NTT
Intended status: Standards Track                       A. Kobayashi, Ed.
Expires: June 27, 2014                                          NTT East
                                                               P. Aitken
                                                     Cisco Systems, Inc.
                                                       December 24, 2013

      Information Elements for Data Link Layer Traffic Measurement
             draft-ietf-ipfix-data-link-layer-monitoring-08

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 27, 2014.

Copyright Notice

   Copyright (c) 2013 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

Kashima, et al.           Expires June 27, 2014                 [Page 1]
Internet-Draft       Data Link Information Elements        December 2013

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  Extended Ethernet Technology  . . . . . . . . . . . . . . . .   4
     2.1.  Wide-Area Ethernet Technology Summary . . . . . . . . . .   4
     2.2.  Virtual Ethernet Technology Summary . . . . . . . . . . .   4
   3.  Information Elements Related to Data Link Layer . . . . . . .   5
     3.1.  Existing Information Elements . . . . . . . . . . . . . .   6
       3.1.1.  dataLinkFrameSize . . . . . . . . . . . . . . . . . .   7
       3.1.2.  dataLinkFrameSection  . . . . . . . . . . . . . . . .   7
     3.2.  New Information Elements  . . . . . . . . . . . . . . . .   8
       3.2.1.  dataLinkFrameType . . . . . . . . . . . . . . . . . .   9
       3.2.2.  sectionOffset . . . . . . . . . . . . . . . . . . . .   9
       3.2.3.  sectionExportedOctets . . . . . . . . . . . . . . . .  10
       3.2.4.  dot1qServiceInstanceTag . . . . . . . . . . . . . . .  11
       3.2.5.  dot1qServiceInstanceId  . . . . . . . . . . . . . . .  11
       3.2.6.  dot1qServiceInstancePriority  . . . . . . . . . . . .  11
       3.2.7.  dot1qCustomerSourceMacAddress . . . . . . . . . . . .  12
       3.2.8.  dot1qCustomerDestinationMacAddress  . . . . . . . . .  12
       3.2.9.  l2OctetDeltaCount . . . . . . . . . . . . . . . . . .  12
       3.2.10. postL2OctetDeltaCount . . . . . . . . . . . . . . . .  13
       3.2.11. postMCastL2OctetDeltaCount  . . . . . . . . . . . . .  13
       3.2.12. l2OctetTotalCount . . . . . . . . . . . . . . . . . .  14
       3.2.13. postL2OctetTotalCount . . . . . . . . . . . . . . . .  14
       3.2.14. postMCastL2OctetTotalCount  . . . . . . . . . . . . .  15
       3.2.15. minimumL2TotalLength  . . . . . . . . . . . . . . . .  15
       3.2.16. maximumL2TotalLength  . . . . . . . . . . . . . . . .  16
       3.2.17. droppedL2OctetDeltaCount  . . . . . . . . . . . . . .  16
       3.2.18. droppedL2OctetTotalCount  . . . . . . . . . . . . . .  17
       3.2.19. ignoredL2OctetTotalCount  . . . . . . . . . . . . . .  17
       3.2.20. notSentL2OctetTotalCount  . . . . . . . . . . . . . .  17
       3.2.21. l2OctetDeltaSumOfSquares  . . . . . . . . . . . . . .  18
       3.2.22. l2OctetTotalSumOfSquares  . . . . . . . . . . . . . .  18
   4.  Modification of Existing Information Elements Related to
       Packet Section  . . . . . . . . . . . . . . . . . . . . . . .  19
     4.1.  ipHeaderPacketSection . . . . . . . . . . . . . . . . . .  19
     4.2.  ipPayloadPacketSection  . . . . . . . . . . . . . . . . .  20
     4.3.  mplsLabelStackSection . . . . . . . . . . . . . . . . . .  21
     4.4.  mplsPayloadPacketSection  . . . . . . . . . . . . . . . .  22
   5.  Modification of Existing Information Elements Related to VLAN
       Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  dot1qVlanId . . . . . . . . . . . . . . . . . . . . . . .  23
     5.2.  dot1qPriority . . . . . . . . . . . . . . . . . . . . . .  24
     5.3.  dot1qCustomerVlanId . . . . . . . . . . . . . . . . . . .  24

Kashima, et al.           Expires June 27, 2014                 [Page 2]
Internet-Draft       Data Link Information Elements        December 2013

     5.4.  dot1qCustomerPriority . . . . . . . . . . . . . . . . . .  24
   6.  The relationship between Ethernet header fields and
       Information Elements  . . . . . . . . . . . . . . . . . . . .  25
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  27
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     10.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Appendix A.  Tagged Frame Formats . . . . . . . . . . . . . . . .  29
   Appendix B.  Template Formats Example . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

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., L2-VPN services.  Accordingly, carrier
   networks using VLAN technologies have been enhanced to Provider
   Bridged Network and Provider Backbone Bridged Networks [IEEE802.1Q].
   And, Ethernet in data centers has also been enhanced for server
   virtualization and 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 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 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].

Kashima, et al.           Expires June 27, 2014                 [Page 3]
Internet-Draft       Data Link Information Elements        December 2013

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.

   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 Eligibility
      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 Provider Bridge Network and Provider Backbone Bridge
   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 makes 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 causes an increase of the number of virtual
   switches and of the number of the traffic control policies, which
   reaches the limitations of network management scalability and
   flexibility.

Kashima, et al.           Expires June 27, 2014                 [Page 4]
Internet-Draft       Data Link Information Elements        December 2013

   In this situation, the IEEE 802.1 Working Group is standardizing
   virtual bridging technologies as Edge Virtual Bridge (EVB) including
   two kinds of Edge Relay (ER): Virtual Edge Bridge (VEB) and Virtual
   Edge Port Aggregator (VEPA) [IEEE802.1Qbg].  The VEB is a bridge that
   provides a 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 EVB bridge so that
   the traffic can be monitored and so 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
   port.  For example, in the host, an S-channel may be attached to a
   VEB or a VEPA or directly an internal port in order to apply each
   port-based filtering rules to the traffic.  S-channel over the link
   between a host and its adjacent bridge uses 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
   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.  Information Elements Related to Data Link Layer

   The following Information Elements whose ElementId are from 312 to
   TBD03 are necessary for enabling the IPFIX and PSAMP traffic
   measurement for data link layer, which is not limited to Ethernet

Kashima, et al.           Expires June 27, 2014                 [Page 5]
Internet-Draft       Data Link Information Elements        December 2013

   because the method can be applied to other data link protocols as
   well.

   The following Information Elements whose ElementId are from TBD04 to
   TBD08 are necessary for enabling the IPFIX and PSAMP traffic
   measurement for [IEEE802.1Q].

   The following Information Elements whose ElementId are from TBD09 to
   TBD22 are octet counter or packet length for layer 2, and are
   necessary for enabling the IPFIX and PSAMP traffic measurement for
   data link layer.

   +-----+------------------------------------+
   | ID  | Name                               |
   +-----+------------------------------------+
   | 312 | dataLinkFrameSize                  |
   | 315 | dataLinkFrameSection               |
   |TBD01| dataLinkFrameType                  |
   |TBD02| sectionOffset                      |
   |TBD03| sectionExportedOctets              |
   |TBD04| dot1qServiceInstanceTag            |
   |TBD05| dot1qServiceInstanceId             |
   |TBD06| dot1qServiceInstancePriority       |
   |TBD07| dot1qCustomerSourceMacAddress      |
   |TBD08| dot1qCustomerDestinationMacAddress |
   |TBD09| l2OctetDeltaCount                  |
   |TBD10| postL2OctetDeltaCount              |
   |TBD11| postMCastL2OctetDeltaCount         |
   |TBD12| l2OctetTotalCount                  |
   |TBD13| postL2OctetTotalCount              |
   |TBD14| postMCastL2OctetTotalCount         |
   |TBD15| minimumL2TotalLength               |
   |TBD16| maximumL2TotalLength               |
   |TBD17| droppedL2OctetDeltaCount           |
   |TBD18| droppedL2OctetTotalCount           |
   |TBD19| ignoredL2OctetTotalCount           |
   |TBD20| notSentL2OctetTotalCount           |
   |TBD21| l2OctetDeltaSumOfSquares           |
   |TBD22| l2OctetTotalSumOfSquares           |
   +-----+------------------------------------+

         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], except for additions as marked *.

Kashima, et al.           Expires June 27, 2014                 [Page 6]
Internet-Draft       Data Link Information Elements        December 2013

   Section 3.1.1 introduces the missing Data Type Semantics for the
   dataLinkFrameSize Information Element which is held to be an
   interoperable change per section 5.2 subsection 4 of [RFC7013].

   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 section 5.2 subsection 4 of [RFC7013].

   Therefore these changes introduce no backwards compatibility issues.

   Per section 5.2 of [RFC7013], for each of these changes,
   [RFCEDITOR:thisRFC] is to be appended to the requestor in IANA's
   IPFIX registry [IANA-IPFIX], the Information Elelement's revision
   number is to be incremented by one, and the Information Element's
   revision date column is to be 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

   Status: current

3.1.2.  dataLinkFrameSection

   Description:

      This Information Element carries n octets from the data link frame
      of a selected frame, starting sectionOffset octets into the frame.

      *However, if no sectionOffset field corresponding to this
      Information Element is present then a sectionOffset of zero
      applies, and the octets MUST be from the start of the data link
      frame.*

Kashima, et al.           Expires June 27, 2014                 [Page 7]
Internet-Draft       Data Link Information Elements        December 2013

      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 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 [RFCEDITOR:thisRFC].

      The data link layer is defined in [ISO_IEC.7498-1_1994].

   Abstract Data Type: octetArray

   ElementId: 315

   Status: current

3.2.  New Information Elements

   The following new Information Elements are added for data link layer
   monitoring.

   In IANA's IPFIX registry [IANA-IPFIX], the Requester is to be set to
   [RFCEDITOR:thisRFC], the Information Element's Revision is to be set
   to zero, and the Information Element's Date set to the date upon
   which the new Information Elements are added to the registry.  All
   other columns which are not explicitly mentioned below (eg, Units,

Kashima, et al.           Expires June 27, 2014                 [Page 8]
Internet-Draft       Data Link Information Elements        December 2013

   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: TBD01

   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 (ie, no offset).

Kashima, et al.           Expires June 27, 2014                 [Page 9]
Internet-Draft       Data Link Information Elements        December 2013

      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
      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: TBD02

   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 (ie, be composed of zero (0) valued octets).

   Abstract Data Type: unsigned16

   Data Type Semantics: quantity

   ElementId: TBD03

   Status: current

Kashima, et al.           Expires June 27, 2014                [Page 10]
Internet-Draft       Data Link Information Elements        December 2013

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
      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.  The structure and semantics
      within the Tag Control Information field are defined in
      [IEEE802.1Q].

   Abstract Data Type: octetArray

   Data Type Semantics: identifier

   ElementId: TBD04

   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: TBD05

   Status: current

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.           Expires June 27, 2014                [Page 11]
Internet-Draft       Data Link Information Elements        December 2013

   Abstract Data Type: unsigned8

   Data Type Semantics: identifier

   ElementId: TBD06

   Status: current

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: identifier

   ElementId: TBD07

   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: identifier

   ElementId: TBD08

   Status: current

3.2.9.  l2OctetDeltaCount

   Description:

Kashima, et al.           Expires June 27, 2014                [Page 12]
Internet-Draft       Data Link Information Elements        December 2013

      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.

      This Information Element is the layer 2 version of octetDeltaCount
      (ElementId #1) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   ElementId: TBD09

   Status: current

   Units: octets

3.2.10.  postL2OctetDeltaCount

   Description:

      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.

      This Information Element is the layer 2 version of
      postOctetDeltaCount (ElementId #23) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   ElementId: TBD10

   Status: current

   Units: octets

3.2.11.  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

Kashima, et al.           Expires June 27, 2014                [Page 13]
Internet-Draft       Data Link Information Elements        December 2013

      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) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   ElementId: TBD11

   Status: current

   Units: octets

3.2.12.  l2OctetTotalCount

   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.

      This Information Element is the layer 2 version of octetTotalCount
      (ElementId #85) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD12

   Status: current

   Units: octets

3.2.13.  postL2OctetTotalCount

   Description:

      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.

Kashima, et al.           Expires June 27, 2014                [Page 14]
Internet-Draft       Data Link Information Elements        December 2013

      This Information Element is the layer 2 version of
      postOctetTotalCount (ElementId #171) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD13

   Status: current

   Units: octets

3.2.14.  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) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD14

   Status: current

   Units: octets

3.2.15.  minimumL2TotalLength

   Description:

      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.

      This Information Element is the layer 2 version of
      minimumIpTotalLength (ElementId #25) in [RFC5477].

Kashima, et al.           Expires June 27, 2014                [Page 15]
Internet-Draft       Data Link Information Elements        December 2013

   Abstract Data Type: unsigned64

   ElementId: TBD15

   Status: current

   Units: octets

3.2.16.  maximumL2TotalLength

   Description:

      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.

      This Information Element is the layer 2 version of
      maximumIpTotalLength (ElementId #26) in [RFC5477].

   Abstract Data Type: unsigned64

   ElementId: TBD16

   Status: current

   Units: octets

3.2.17.  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 2payload.

      This Information Element is the layer 2 version of
      droppedOctetDeltaCount (ElementId #132) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   ElementId: TBD17

   Status: current

   Units: octets

Kashima, et al.           Expires June 27, 2014                [Page 16]
Internet-Draft       Data Link Information Elements        December 2013

3.2.18.  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) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD18

   Status: current

   Units: octets

3.2.19.  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) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD19

   Status: current

   Units: octets

3.2.20.  notSentL2OctetTotalCount

   Description:

Kashima, et al.           Expires June 27, 2014                [Page 17]
Internet-Draft       Data Link Information Elements        December 2013

      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) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD20

   Status: current

   Units: octets

3.2.21.  l2OctetDeltaSumOfSquares

   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) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   ElementId: TBD21

   Status: current

   Units: octets

3.2.22.  l2OctetTotalSumOfSquares

   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.

Kashima, et al.           Expires June 27, 2014                [Page 18]
Internet-Draft       Data Link Information Elements        December 2013

      This Information Element is the layer 2 version of
      octetTotalSumOfSquares (ElementId #199) in [RFC5477].

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   ElementId: TBD22

   Status: current

   Units: octets

4.  Modification of Existing Information Elements Related to Packet
    Section

   The new Information Elements related to packet section (ie,
   sectionOffset and sectionExportedOctets) can be applied to not only
   dataLinkFrameSection but also all kinds of packet section (ie,
   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 is
   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
      section of [RFC5477] and [RFC2804].

      The sectionExportedOctets expresses how much data was exported,
      while the remainder is padding.

Kashima, et al.           Expires June 27, 2014                [Page 19]
Internet-Draft       Data Link Information Elements        December 2013

      When the sectionExportedOctets 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.

      When the sectionExportedOctets field corresponding to this
      Information Element does not exist, this Information Element
      SHOULD have a variable length and MUST NOT be padded.  In this
      case, the size of the exported section may be constrained due to
      limitations in the IPFIX protocol.

   Abstract Data Type: octetArray

   ElementId: 313

   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 MAY have a variable length.

Kashima, et al.           Expires June 27, 2014                [Page 20]
Internet-Draft       Data Link Information Elements        December 2013

      When the sectionExportedOctets field corresponding to this
      Information Element does not exist, this Information Element
      SHOULD have a variable length and MUST NOT be padded.  In this
      case, the size of the exported section may be constrained due to
      limitations in the IPFIX protocol.

   Abstract Data Type: octetArray

   ElementId: 314

   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
      section 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 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

Kashima, et al.           Expires June 27, 2014                [Page 21]
Internet-Draft       Data Link Information Elements        December 2013

      case, the size of the exported section may be constrained due to
      limitations in the IPFIX protocol.

   Abstract Data Type: octetArray

   ElementId: 316

   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, being 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 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

   Status: current

Kashima, et al.           Expires June 27, 2014                [Page 22]
Internet-Draft       Data Link Information Elements        December 2013

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
   Reference 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 S-TAG Tag Control Information (TCI)
      field or the Customer VLAN identifier in the 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 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 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

   Reference:

   (1)  [IEEE802.1Q]

   (2)  [IEEE802.1Qbg]

Kashima, et al.           Expires June 27, 2014                [Page 23]
Internet-Draft       Data Link Information Elements        December 2013

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 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

   Reference:

   (1)  [IEEE802.1Q]

5.3.  dot1qCustomerVlanId

   Description:

      The value represents the Customer VLAN identifier in the C-TAG Tag
      Control Information (TCI) field as described in [IEEE802.1Q].

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   ElementId: 245

   Status: current

   Reference:

   (1)  [IEEE802.1Q]

5.4.  dot1qCustomerPriority

   Description:

Kashima, et al.           Expires June 27, 2014                [Page 24]
Internet-Draft       Data Link Information Elements        December 2013

      The value represents the 3-bit Priority Code Point (PCP) portion
      of the C-TAG Tag Control Information (TCI) field as described in
      [IEEE802.1Q].

   Abstract Data Type: unsigned8

   Data Type Semantics: identifier

   ElementId: 246

   Status: current

   Reference:

   (1)  [IEEE802.1Q]

6.  The relationship between Ethernet header fields and Information
    Elements

   The following figures shows summary of various Ethernet header fields
   and the Informational Elements which 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

Kashima, et al.           Expires June 27, 2014                [Page 25]
Internet-Draft       Data Link Information Elements        December 2013

    <-- 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

    <-- 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 (TBD04), or
                            a set of dot1qServiceInstanceId (TBD05),
                            dot1qServiceInstancePriority (TBD06),
                            dot1qCustomerSourceMacAddress (TBD07)
                            dot1qCustomerDestinationMacAddress (TBD08),
   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].

Kashima, et al.           Expires June 27, 2014                [Page 26]
Internet-Draft       Data Link Information Elements        December 2013

8.  IANA Considerations

   RFCEDITOR: please assign TBDnn throughout this document.

   This document requests that existing IPFIX Information Elements
   [IANA-IPFIX] are modified as indicated in sections 3.1, 4, and 5
   above.

   Per section 5.2 of [RFC7013], for each of these changes,
   [RFCEDITOR:thisRFC] is to be appended to the requestor in IANA's
   IPFIX registry [IANA-IPFIX], the Information Elelement's revision
   number is to be incremented by one, and the Information Element's
   revision date column is to be updated.

   This document requests that new IPFIX Information Elements
   [IANA-IPFIX] are allocated as shown in section 3.2 above.

9.  Acknowledgments

   Thanks to Brian Trammell and the IPFIX working group participants who
   contributed to mailing-list discussions throughout the development of
   this document, and especially to Pat Thaler for her help with the
   IEEE 802 aspects of this work.

10.  References

10.1.  Normative References

   [IEEE802.11]
              IEEE Computer Society, "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 Computer Society, "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 Computer Society, "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.

Kashima, et al.           Expires June 27, 2014                [Page 27]
Internet-Draft       Data Link Information Elements        December 2013

   [IEEE802.1Qbg]
              IEEE Computer Society, "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 Computer Society, "IEEE Standard for Ethernet", IEEE
              Std 802.3-2012, December 2012.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
              Carle, "Information Model for Packet Sampling Exports",
              RFC 5477, March 2009.

   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", RFC 6313, July 2011.

   [RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
              the IP Flow Information Export (IPFIX) Protocol for the
              Exchange of Flow Information", STD 77, RFC 7011, September
              2013.

10.2.  Informative References

   [IANA-IPFIX]
              Internet Assigned Numbers Authority, "IANA IPFIX
              Information Element Registry",
              http://www.iana.org/assignments/ipfix/ipfix.xhtml.

Kashima, et al.           Expires June 27, 2014                [Page 28]
Internet-Draft       Data Link Information Elements        December 2013

   [IEEE802.1D]
              IEEE Computer Society, "IEEE Standard for Local and
              metropolitan area networks: Media Access Control (MAC)
              Bridges", IEEE Std 802.1D-2004, June 2004.

   [ISO_IEC.7498-1_1994]
              International Organization for Standardization,
              "Information technology -- Open Systems Interconnection --
              Basic Reference Model: The Basic Mode", ISO Standard
              7498-1:1994, June 1996.

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May
              2000.

   [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
              Information Export (IPFIX)", RFC 7012, September 2013.

   [RFC7013]  Trammell, B. and B. Claise, "Guidelines for Authors and
              Reviewers of IP Flow Information Export (IPFIX)
              Information Elements", BCP 184, RFC 7013, September 2013.

Appendix A.  Tagged 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

Kashima, et al.           Expires June 27, 2014                [Page 29]
Internet-Draft       Data Link Information Elements        December 2013

   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

   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

Kashima, et al.           Expires June 27, 2014                [Page 30]
Internet-Draft       Data Link Information Elements        December 2013

   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.           Expires June 27, 2014                [Page 31]
Internet-Draft       Data Link Information Elements        December 2013

   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.           Expires June 27, 2014                [Page 32]
Internet-Draft       Data Link Information Elements        December 2013

   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.           Expires June 27, 2014                [Page 33]
Internet-Draft       Data Link Information Elements        December 2013

   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 that this frame format is identical to the format in Figure A-3.

   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

Kashima, et al.           Expires June 27, 2014                [Page 34]
Internet-Draft       Data Link Information Elements        December 2013

   This frame format is identical to the format in Figure A-4.

   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.           Expires June 27, 2014                [Page 35]
Internet-Draft       Data Link Information Elements        December 2013

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              C-DA                             |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                              C-SA                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        E-TAG TPID=0x893F      |E-PCP|D|   Ingress_E-CID_base  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res|GRP|      E-CID_base       |Ingre_E-CID_ext|    E-CID_ext  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        C-TAG TPID=0x8100      |C-PCP|C|         C-VID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Length/Type          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ~                         Customer Data                         ~
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure A-10: E-TAG and C-TAG tagging frame format over the link
          between a Controlling Bridge and a Bridge Port Extender

Appendix B.  Template Formats Example

Kashima, et al.           Expires June 27, 2014                [Page 36]
Internet-Draft       Data Link Information Elements        December 2013

   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)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure B-1: Template Format Example

Authors' Addresses

   Shingo Kashima
   Nippon Telegraph and Telephone Corporation
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81 422 59 3894
   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

Kashima, et al.           Expires June 27, 2014                [Page 37]
Internet-Draft       Data Link Information Elements        December 2013

   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.           Expires June 27, 2014                [Page 38]