IP Flow Information Export S. Kashima
Internet-Draft NTT
Intended status: Standards Track A. Kobayashi, Ed.
Expires: April 12, 2014 NTT East
P. Aitken
Cisco Systems, Inc.
October 09, 2013
Information Elements for Data Link Layer Traffic Measurement
draft-ietf-ipfix-data-link-layer-monitoring-05
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 April 12, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kashima, et al. Expires April 12, 2014 [Page 1]
Internet-Draft Data Link Information Elements October 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . 4
3. Information Elements Related to Data Link Layer . . . . . . . 6
3.1. Existing Information Elements . . . . . . . . . . . . . . 7
3.1.1. dataLinkFrameSize . . . . . . . . . . . . . . . . . . 7
3.1.2. dataLinkFrameSection . . . . . . . . . . . . . . . . 7
3.2. New Information Elements . . . . . . . . . . . . . . . . 8
3.2.1. dataLinkFrameType . . . . . . . . . . . . . . . . . . 8
3.2.2. sectionOffset . . . . . . . . . . . . . . . . . . . . 9
3.2.3. sectionExportedOctets . . . . . . . . . . . . . . . . 9
3.2.4. dot1qServiceInstanceTag . . . . . . . . . . . . . . . 10
3.2.5. dot1qServiceInstanceId . . . . . . . . . . . . . . . 10
3.2.6. dot1qServiceInstancePriority . . . . . . . . . . . . 10
3.2.7. dot1qCustomerSourceMacAddress . . . . . . . . . . . . 11
3.2.8. dot1qCustomerDestinationMacAddress . . . . . . . . . 11
3.2.9. l2OctetDeltaCount . . . . . . . . . . . . . . . . . . 11
3.2.10. postL2OctetDeltaCount . . . . . . . . . . . . . . . . 12
3.2.11. postMCastL2OctetDeltaCount . . . . . . . . . . . . . 12
3.2.12. l2OctetTotalCount . . . . . . . . . . . . . . . . . . 13
3.2.13. postL2OctetTotalCount . . . . . . . . . . . . . . . . 13
3.2.14. postMCastL2OctetTotalCount . . . . . . . . . . . . . 14
3.2.15. minimumL2TotalLength . . . . . . . . . . . . . . . . 14
3.2.16. maximumL2TotalLength . . . . . . . . . . . . . . . . 15
3.2.17. droppedL2OctetDeltaCount . . . . . . . . . . . . . . 15
3.2.18. droppedL2OctetTotalCount . . . . . . . . . . . . . . 16
3.2.19. ignoredL2OctetTotalCount . . . . . . . . . . . . . . 16
3.2.20. notSentL2OctetTotalCount . . . . . . . . . . . . . . 16
3.2.21. l2OctetDeltaSumOfSquares . . . . . . . . . . . . . . 17
3.2.22. l2OctetTotalSumOfSquares . . . . . . . . . . . . . . 17
4. Modification of Existing Information Elements Related to
Packet Section . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. ipHeaderPacketSection . . . . . . . . . . . . . . . . . . 18
4.2. ipPayloadPacketSection . . . . . . . . . . . . . . . . . 19
Kashima, et al. Expires April 12, 2014 [Page 2]
Internet-Draft Data Link Information Elements October 2013
4.3. mplsLabelStackSection . . . . . . . . . . . . . . . . . . 20
4.4. mplsPayloadPacketSection . . . . . . . . . . . . . . . . 21
5. Modification of Existing Information Elements Related to VLAN
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. dot1qVlanId . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. dot1qPriority . . . . . . . . . . . . . . . . . . . . . . 22
5.3. dot1qCustomerVlanId . . . . . . . . . . . . . . . . . . . 23
5.4. dot1qCustomerPriority . . . . . . . . . . . . . . . . . . 23
6. The relationship between Ethernet header fields and
Information Elements . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Tagged Frame Formats . . . . . . . . . . . . . . . . 27
Appendix B. Template Formats Example . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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, the carrier
networks using the VLAN technologies have been enhanced to Provider
Bridged Network and Provider Backbone Bridged Networks [IEEE802.1Q].
And, Ethernet in data center also has been enhanced for server
virtualization and I/O consolidation.
While these innovations provide flexibility, scalability, and
mobility to an existing network architecture, it increases the
complexity of traffic measurement due to the existence of various
Ethernet header formats. To cope with this, a more sophisticated
method is required.
IPFIX and PSAMP helps to resolve these problems. However, the PSAMP
Information Model [RFC5477] and the IPFIX Information Model [RFC7011]
are not yet enough for Information Elements related to data link
layer, e.g., Ethernet header forms. This document describes the
Information Elements related to data link layers that enable a more
sophisticated traffic measurement method.
Kashima, et al. Expires April 12, 2014 [Page 3]
Internet-Draft Data Link Information Elements October 2013
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 the 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). Also, the lack of
management scalability and flexibility: increasing the number of VMs
Kashima, et al. Expires April 12, 2014 [Page 4]
Internet-Draft Data Link Information Elements October 2013
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.
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.
Kashima, et al. Expires April 12, 2014 [Page 5]
Internet-Draft Data Link Information Elements October 2013
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
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
Kashima, et al. Expires April 12, 2014 [Page 6]
Internet-Draft Data Link Information Elements October 2013
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 *.
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, when the sectionOffset field corresponding to this
Information Element does not exist, 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 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. Expires April 12, 2014 [Page 7]
Internet-Draft Data Link Information Elements October 2013
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.
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
Kashima, et al. Expires April 12, 2014 [Page 8]
Internet-Draft Data Link Information Elements October 2013
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).
If multiple sectionOffset IEs are specified within a single
Template, then they apply to the packet section IEs in order. ie,
the first sectionOffset applies to the first packet section, etc.
Note that the "closest" sectionOffset and packet section IEs
within a given Template are not necessarily related. If there are
less sectionOffset IEs than packet section IEs, then subsequent
packet section IEs have no offset. If there are more
sectionOffset IEs than the number of packet section IEs, then the
additional sectionOffset IEs are meaningless.
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
Kashima, et al. Expires April 12, 2014 [Page 9]
Internet-Draft Data Link Information Elements October 2013
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
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)
Kashima, et al. Expires April 12, 2014 [Page 10]
Internet-Draft Data Link Information Elements October 2013
Tag Control Information (TCI) field of an Ethernet frame as
described in [IEEE802.1Q].
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 April 12, 2014 [Page 11]
Internet-Draft Data Link Information Elements October 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.
The Information Element is 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.
The Information Element is 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:
Kashima, et al. Expires April 12, 2014 [Page 12]
Internet-Draft Data Link Information Elements October 2013
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.
The Information Element is 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.
The Information Element is 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
Kashima, et al. Expires April 12, 2014 [Page 13]
Internet-Draft Data Link Information Elements October 2013
it reports a potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
The Information Element is 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.
The Information Element is 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.
Kashima, et al. Expires April 12, 2014 [Page 14]
Internet-Draft Data Link Information Elements October 2013
The Information Element is layer 2 version of minimumIpTotalLength
(ElementId #25) in [RFC5477].
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.
The Information Element is 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.
The Information Element is layer 2 version of
droppedOctetDeltaCount (ElementId #132) in [RFC5477].
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: TBD17
Status: current
Kashima, et al. Expires April 12, 2014 [Page 15]
Internet-Draft Data Link Information Elements October 2013
Units: octets
3.2.18. droppedL2OctetTotalCount
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.
The Information Element is 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.
The Information Element is 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 April 12, 2014 [Page 16]
Internet-Draft Data Link Information Elements October 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.
The Information Element is 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.
The Information Element is 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 April 12, 2014 [Page 17]
Internet-Draft Data Link Information Elements October 2013
The Information Element is 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, when the sectionOffset field corresponding to this
Information Element does not exist, the octets MUST be from the
start of the IP header.
With sufficient length, this element also reports octets from the
IP payload, subject to [RFC2804]. See the Security Considerations
section in [RFC5477].
The sectionExportedOctets expresses how much data was exported,
while the remainder is padding.
Kashima, et al. Expires April 12, 2014 [Page 18]
Internet-Draft Data Link Information Elements October 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
The 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, when the sectionOffset field corresponding to this
Information Element does not exist, 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 April 12, 2014 [Page 19]
Internet-Draft Data Link Information Elements October 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
The 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, when the sectionOffset field corresponding to this
Information Element does not exist, the octets MUST be from the
head of the MPLS label stack.
With sufficient length, this element also reports octets from the
MPLS payload, subject to [RFC2804]. See the Security
Considerations section in [RFC5477].
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.
Kashima, et al. Expires April 12, 2014 [Page 20]
Internet-Draft Data Link Information Elements October 2013
Abstract Data Type: octetArray
ElementId: 316
Status: current
4.4. mplsPayloadPacketSection
The 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, when the sectionOffset field corresponding to this
Information Element does not exist, 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
5. Modification of Existing Information Elements Related to VLAN Tag
Kashima, et al. Expires April 12, 2014 [Page 21]
Internet-Draft Data Link Information Elements October 2013
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]
5.2. dot1qPriority
Description:
Kashima, et al. Expires April 12, 2014 [Page 22]
Internet-Draft Data Link Information Elements October 2013
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:
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
Kashima, et al. Expires April 12, 2014 [Page 23]
Internet-Draft Data Link Information Elements October 2013
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
<--- 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. Expires April 12, 2014 [Page 24]
Internet-Draft Data Link Information Elements October 2013
<--- 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
The recommendations in this document do not introduce any additional
security issues beyond those already mentioned in [RFC7011] and
[RFC5477].
8. IANA Considerations
This document requests that existing IPFIX Information Elements
[IANA-IPFIX] are modified as indicated in sections 3.1, 4, and 5
above.
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 IPFIX members 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
Kashima, et al. Expires April 12, 2014 [Page 25]
Internet-Draft Data Link Information Elements October 2013
[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.
[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.
[RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May
2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
Kashima, et al. Expires April 12, 2014 [Page 26]
Internet-Draft Data Link Information Elements October 2013
[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.
[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.
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 | |
Kashima, et al. Expires April 12, 2014 [Page 27]
Internet-Draft Data Link Information Elements October 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ 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
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 ~
~ ~
Kashima, et al. Expires April 12, 2014 [Page 28]
Internet-Draft Data Link Information Elements October 2013
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kashima, et al. Expires April 12, 2014 [Page 29]
Internet-Draft Data Link Information Elements October 2013
| C-SA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A-5: B-TAG and I-TAG tagging frame format in Provider Backbone
Bridged Networks
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| B-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-TAG TPID=0x88a8 |B-PCP|D| B-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-TAG TPID=0x88e7 |I-PCP|D|U| Res | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-SA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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
0 1 2 3
Kashima, et al. Expires April 12, 2014 [Page 30]
Internet-Draft Data Link Information Elements October 2013
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 April 12, 2014 [Page 31]
Internet-Draft Data Link Information Elements October 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
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 ~
~ ~
Kashima, et al. Expires April 12, 2014 [Page 32]
Internet-Draft Data Link Information Elements October 2013
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
Kashima, et al. Expires April 12, 2014 [Page 33]
Internet-Draft Data Link Information Elements October 2013
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. Expires April 12, 2014 [Page 34]