IP Flow Information Export S. Kashima Internet-Draft NTT Intended status: Standards Track A. Kobayashi Expires: August 21, 2013 NTT East P. Aitken Cisco Systems, Inc. February 22, 2013 Information Elements for Data Link Layer Traffic Measurement draft-ietf-ipfix-data-link-layer-monitoring-02 Abstract This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. 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 August 21, 2013. 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 the Trust Legal Provisions and are provided without warranty as Kashima, et al. Expires August 21, 2013 [Page 1] Internet-Draft Data Link Information Elements February 2013 described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Extended Ethernet Technology . . . . . . . . . . . . . . . . . 4 2.1. Wide-Area Ethernet Technology Summary . . . . . . . . . . 4 2.2. Virtual Ethernet Technology Summary . . . . . . . . . . . 5 3. New Information Elements . . . . . . . . . . . . . . . . . . . 6 3.1. dataLinkFrameSize . . . . . . . . . . . . . . . . . . . . 7 3.2. dataLinkFrameSection . . . . . . . . . . . . . . . . . . . 8 3.3. dataLinkFrameType . . . . . . . . . . . . . . . . . . . . 8 3.4. sectionOffset . . . . . . . . . . . . . . . . . . . . . . 9 3.5. sectionObservedOctets . . . . . . . . . . . . . . . . . . 9 3.6. dot1qTagProtocolIdentification . . . . . . . . . . . . . . 10 3.7. dot1qServiceInstanceTag . . . . . . . . . . . . . . . . . 10 3.8. dot1qServiceInstanceId . . . . . . . . . . . . . . . . . . 11 3.9. dot1qServiceInstancePriority . . . . . . . . . . . . . . . 11 3.10. dot1qCustomerDestinationMacAddress . . . . . . . . . . . . 11 3.11. dot1qCustomerSourceMacAddress . . . . . . . . . . . . . . 12 3.12. dot1brEchannelTag . . . . . . . . . . . . . . . . . . . . 12 3.13. dot1brEChannelPriority . . . . . . . . . . . . . . . . . . 13 3.14. l2OctetDeltaCount . . . . . . . . . . . . . . . . . . . . 13 3.15. postMCastL2OctetDeltaCount . . . . . . . . . . . . . . . . 13 3.16. postL2OctetDeltaCount . . . . . . . . . . . . . . . . . . 14 3.17. minimumL2TotalLength . . . . . . . . . . . . . . . . . . . 14 3.18. maximumL2TotalLength . . . . . . . . . . . . . . . . . . . 15 3.19. l2octetTotalCount . . . . . . . . . . . . . . . . . . . . 15 3.20. droppedL2OctetDeltaCount . . . . . . . . . . . . . . . . . 15 3.21. droppedL2OctetTotalCount . . . . . . . . . . . . . . . . . 16 3.22. ignoredL2OctetTotalCount . . . . . . . . . . . . . . . . . 16 3.23. notSentL2OctetTotalCount . . . . . . . . . . . . . . . . . 17 3.24. postL2OctetTotalCount . . . . . . . . . . . . . . . . . . 17 3.25. postMCastL2OctetTotalCount . . . . . . . . . . . . . . . . 17 Kashima, et al. Expires August 21, 2013 [Page 2] Internet-Draft Data Link Information Elements February 2013 3.26. l2octetDeltaSumOfSquares . . . . . . . . . . . . . . . . . 18 3.27. l2octetTotalSumOfSquares . . . . . . . . . . . . . . . . . 18 4. Modification of Existing Information Elements Related to Packet Section . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. ipHeaderPacketSection . . . . . . . . . . . . . . . . . . 19 4.2. ipPayloadPacketSection . . . . . . . . . . . . . . . . . . 19 4.3. mplsLabelStackSection . . . . . . . . . . . . . . . . . . 19 4.4. mplsPayloadPacketSection . . . . . . . . . . . . . . . . . 20 5. Modification of Existing Information Elements Related to VLAN Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. dot1qVlanId . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. dot1qPriority . . . . . . . . . . . . . . . . . . . . . . 21 5.3. dot1qCustomerVlanId . . . . . . . . . . . . . . . . . . . 21 5.4. dot1qCustomerPriority . . . . . . . . . . . . . . . . . . 22 6. The relationship between Ethernet header fields and Information Elements . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 Appendix A. Tagged Frame Formats . . . . . . . . . . . . . . . . 26 Appendix B. Template Formats Example . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Kashima, et al. Expires August 21, 2013 [Page 3] Internet-Draft Data Link Information Elements February 2013 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/PSAMP helps to resolve these problems. However, the PSAMP Information Model [RFC5477] and the IPFIX Information Model [RFC5101] are not yet enough for Information Elements related to data link layer, e.g., Ethernet header forms. This document describes the Information Elements related to data link layers that enable a more sophisticated traffic measurement method. 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 Kashima, et al. Expires August 21, 2013 [Page 4] Internet-Draft Data Link Information Elements February 2013 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 three challenges in the existing virtual switches environment in a data center. One is the overload on software-based virtual switch. The large volume traffic among virtual machines (VMs) consumes computing resource, then causes to reduce the host's computing resources for the applications on the each VM. Second is the lack of network management visibility. The limited feature on the virtual switch makes difficult to monitor traffic among VMs. Third is the lack of management scalability. Increasing the number of VMs in a data center causes the increase of number of virtual switches. It reaches the limitation of network management. To cope with these challenges, IEEE 802.1 Working Group standardizes two technologies; Virtual Ethernet Port Aggregator (VEPA) [IEEE802.1Qbg] and Bridge Port Extension [IEEE802.1BR]. Edge Virtual Bridging with VEPA removes the burden of host's computing resources by forwarding the traffic among VMs to adjacent physical switch using S-Channel. S-Channel over the link between an end station and its adjacent bridge uses S-TAG [IEEE802.1Q]. 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]. The traffic monitoring over S-Channel and E-Channel is required in order to get the visibility of VM-to-VM traffic. The Information Elements related to S-Channel and E-Channel are necessary. Frame format used in S-Channel is complied with S-TAG format. Frame Kashima, et al. Expires August 21, 2013 [Page 5] Internet-Draft Data Link Information Elements February 2013 format with E-TAG used in E-channel are shown in Appendix A. 3. New Information Elements 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 TBD09 are necessary for enabling the IPFIX and PSAMP traffic measurement for [IEEE802.1Q]. The following Information Elements whose ElementId are from TBD10 to TBD11 are necessary for enabling the IPFIX and PSAMP traffic measurement for [IEEE802.1BR]. The following Information Elements whose ElementId are TBD12 from to TBD25 are octet counter or packet length for layer 2, and are necessary for enabling the IPFIX and PSAMP traffic measurement for data link layer. Note that 312 and 315 are proposed IDs, subject to approval by IANA. Kashima, et al. Expires August 21, 2013 [Page 6] Internet-Draft Data Link Information Elements February 2013 +-----+------------------------------------+ | ID | Name | +-----+------------------------------------+ | 312 | dataLinkFrameSize | | 315 | dataLinkFrameSection | |TBD01| dataLinkFrameType | |TBD02| sectionOffset | |TBD03| sectionObservedOctets | |TBD04| dot1qTagProtocolIdentification | |TBD05| dot1qServiceInstanceTag | |TBD06| dot1qServiceInstanceId | |TBD07| dot1qServiceInstancePriority | |TBD08| dot1qCustomerDestinationMacAddress | |TBD09| dot1qCustomerSourceMacAddress | |TBD10| dot1brEChannelTag | |TBD11| dot1brEChannelPriority | |TBD12| l2octetDeltaCount | |TBD13| postMCastL2OctetDeltaCount | |TBD14| postL2OctetDeltaCount | |TBD15| minimumL2TotalLength | |TBD16| maximumL2TotalLength | |TBD17| l2octetTotalCount | |TBD18| droppedL2OctetDeltaCount | |TBD19| droppedL2OctetTotalCount | |TBD20| ignoredL2OctetTotalCount | |TBD21| notSentL2OctetTotalCount | |TBD22| postL2OctetTotalCount | |TBD23| postMCastL2OctetTotalCount | |TBD24| l2octetDeltaSumOfSquares | |TBD25| l2octetTotalSumOfSquares | +-----+------------------------------------+ Table 1: New Information Elements 3.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 Kashima, et al. Expires August 21, 2013 [Page 7] Internet-Draft Data Link Information Elements February 2013 Status: current 3.2. dataLinkFrameSection Description: This Information Element carries n octets from the data link frame of a selected frame, starting sectionOffset octets into the frame. The sectionObservedOctets expresses how much data was observed, while the remainder is padding. When the sectionObservedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or MAY have a variable length. When the sectionObservedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. 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 C. The data link layer is defined in [ISO_IEC.7498-1_1994]. Abstract Data Type: octetArray ElementId: 315 Status: current 3.3. dataLinkFrameType Description: This Information Element specifies the type of the selected data link frame. The following data link types are defined here. Kashima, et al. Expires August 21, 2013 [Page 8] Internet-Draft Data Link Information Elements February 2013 - 0x01 ETHERNET Further values may be assigned by IANA. The data link layer is defined in [ISO_IEC.7498-1_1994]. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: TBD01 Status: current 3.4. 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.5. sectionObservedOctets Description: Kashima, et al. Expires August 21, 2013 [Page 9] Internet-Draft Data Link Information Elements February 2013 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 sectionObservedOctets. In this case, octets in the packet section beyond the sectionObservedOctets MUST follow the [RFC5101] rules for padding (ie, be composed of zero (0) valued octets). Abstract Data Type: unsigned16 Data Type Semantics: quantity ElementId: TBD03 Status: current 3.6. dot1qTagProtocolIdentification Description: The value represents the Tag Protocol Identification (TPID) in [IEEE802.1Q] including an EtherType to identify the frame as a tagged frame. In the case of multi-tagged frame, it represents the TPID portion of the outer tag. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: TBD04 Status: current 3.7. dot1qServiceInstanceTag Description: This Information Element, which may have 16 octets length, represents the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [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 Kashima, et al. Expires August 21, 2013 [Page 10] Internet-Draft Data Link Information Elements February 2013 in [IEEE802.1Q]. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: TBD05 Status: current 3.8. 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: TBD06 Status: current 3.9. 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]. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: TBD07 Status: current 3.10. dot1qCustomerDestinationMacAddress Description: Kashima, et al. Expires August 21, 2013 [Page 11] Internet-Draft Data Link Information Elements February 2013 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.11. 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: TBD09 Status: current 3.12. dot1brEchannelTag Description: This Information Element, which has 6 octets length, represents the E-channel Tag (E-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1BR]. It encodes the Priority Code Point (E-PCP), Drop Eligible Indicator (E-DEI), ingress E-channel identifier (Ingress E-CID), and E-channel identifier (E-CID). The structure and semantics within the Tag Control Information field are defined in [IEEE802.1BR]. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: TBD10 Kashima, et al. Expires August 21, 2013 [Page 12] Internet-Draft Data Link Information Elements February 2013 Status: current 3.13. dot1brEChannelPriority Description: The value of the 3-bit E-channel Priority Code Point (E-PCP) portion of the E-channel Tag (E-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1BR]. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: TBD11 Status: current 3.14. l2OctetDeltaCount Description: The number of layer 2 octets since the previous report (if any) in incoming packets for this Flow at the Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. # memo: layer 2 version of octetDeltaCount (field #1) Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: TBD12 Status: current Units: octets 3.15. postMCastL2OctetDeltaCount Description: The number of layer 2 octets since the previous report (if any) in outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes layer 2 header(s) and layer 2 payload. Kashima, et al. Expires August 21, 2013 [Page 13] Internet-Draft Data Link Information Elements February 2013 # memo: layer 2 version of postMCastOctetDeltaCount (field #20) Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: TBD13 Status: current Units: octets 3.16. 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. # memo: layer 2 version of postOctetDeltaCount (field #23) Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: TBD14 Status: current Units: octets 3.17. 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. # memo: layer 2 version of minimumIpTotalLength (field #25) Abstract Data Type: unsigned64 ElementId: TBD15 Status: current Units: octets Kashima, et al. Expires August 21, 2013 [Page 14] Internet-Draft Data Link Information Elements February 2013 3.18. 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. # memo: layer 2 version of maximumIpTotalLength (field #26) Abstract Data Type: unsigned64 ElementId: TBD16 Status: current Units: octets 3.19. 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. # memo: layer 2 version of octetTotalCount (field #85) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD17 Status: current Units: octets 3.20. 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. # memo: layer 2 version of droppedOctetDeltaCount (field #132) Abstract Data Type: unsigned64 Kashima, et al. Expires August 21, 2013 [Page 15] Internet-Draft Data Link Information Elements February 2013 Data Type Semantics: deltaCounter ElementId: TBD18 Status: current Units: octets 3.21. 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. # memo: layer 2 version of droppedOctetTotalCount (field #134) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD19 Status: current Units: octets 3.22. 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. # memo: layer 2 version of ignoredOctetTotalCount (field #165) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD20 Status: current Units: octets Kashima, et al. Expires August 21, 2013 [Page 16] Internet-Draft Data Link Information Elements February 2013 3.23. notSentL2OctetTotalCount Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process. # memo: layer 2 version of notSentOctetTotalCount (field #168) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD21 Status: current Units: octets 3.24. 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. # memo: layer 2 version of postOctetTotalCount (field #171) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD22 Status: current Units: octets 3.25. 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 Kashima, et al. Expires August 21, 2013 [Page 17] Internet-Draft Data Link Information Elements February 2013 includes layer 2 header(s) and layer 2 payload. # memo: layer 2 version of postMCastOctetTotalCount (field #175) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD23 Status: current Units: octets 3.26. 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. # memo: layer 2 version of octetDeltaSumOfSquares (field #198) Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: TBD24 Status: current Units: octets 3.27. 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. # memo: layer 2 version of octetTotalSumOfSquares (field #199) Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: TBD25 Kashima, et al. Expires August 21, 2013 [Page 18] Internet-Draft Data Link Information Elements February 2013 Status: current Units: octets 4. Modification of Existing Information Elements Related to Packet Section --- This is open issue. --- New Information Elements related to packet section (ie, sectionOffset and sectionObservedOctets) can be applied to not only dataLinkFrameSection but also all kinds of packet section. In this case, existing Information Elements Description should be modified as follows: 4.1. ipHeaderPacketSection Description: TBD Abstract Data Type: octetArray ElementId: 313 Status: current 4.2. ipPayloadPacketSection Description: TBD Abstract Data Type: octetArray ElementId: 314 Status: current 4.3. mplsLabelStackSection Description: TBD Abstract Data Type: octetArray Kashima, et al. Expires August 21, 2013 [Page 19] Internet-Draft Data Link Information Elements February 2013 ElementId: 316 Status: current 4.4. mplsPayloadPacketSection Description: TBD Abstract Data Type: octetArray ElementId: 317 Status: current 5. Modification of Existing Information Elements Related to VLAN Tag The traffic measurement using IPFIX and PSAMP for a Provider Backbone Bridged Network requires the Information Elements related to Backbone Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG). The set of Information Elements related to I-TAG is added in section 3, because I-TAG structure and semantics are different from that of Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG). The set of Information Elements related to B-TAG reuses the existing Information Elements, because B-TAG structure and semantics are identical to that of C-TAG and S-TAG. This section modifies existing Descriptions and 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 server-network edge using VEPA- based switches, it represents the Service VLAN identifier indicating S-channel as described in [IEEE802.1Qbg]. Kashima, et al. Expires August 21, 2013 [Page 20] Internet-Draft Data Link Information Elements February 2013 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: 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 Kashima, et al. Expires August 21, 2013 [Page 21] Internet-Draft Data Link Information Elements February 2013 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 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. Kashima, et al. Expires August 21, 2013 [Page 22] Internet-Draft Data Link Information Elements February 2013 <----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) dot1qTagProtocolIdentification TBD04, 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) dot1qTagProtocolIdentification TBD04, 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 August 21, 2013 [Page 23] Internet-Draft Data Link Information Elements February 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) dot1qTagProtocolIdentification TBD04, dot1qVlanId 243, dot1qPriority 244 d.(Information Elements) dot1qServiceInstanceTag TBD05, or a set of dot1qServiceInstanceId TBD06, dot1qServiceInstancePriority TBD07, dot1qCustomerDestinationMacAddress TBD08, dot1qCustomerSourceMacAddress TBD09 e.(Information Elements) dot1qCustomerVlanId 245, dot1qCustomerPriority 246 f.(Information Element) ethernetType 256 Figure 3: Backbone VLAN tagged frame header fields <----6----><----6----><----6----><------2------> +----------+----------+----------+--------------+ + + + + + + C-DA + C-SA + E-TAG + Length/Type + + a + b + c + d + +----------+----------+----------+--------------+ a.(Information Element) destinationMacAddress 80 b.(Information Element) sourceMacAddress 56 c.(Information Elements) dot1brEChannelTag TBD10, dot1brPriority TBD11 d.(Information Element) ethernetType 256 Figure 4: E-channel tagging frame header fields 7. Security Considerations The recommendations in this document do not introduce any additional security issues to those already mentioned in [RFC5101] and [RFC5477]. Kashima, et al. Expires August 21, 2013 [Page 24] Internet-Draft Data Link Information Elements February 2013 8. IANA Considerations This document requests that the Information Element IDs are allocated as shown in section 3 In addition, the dataLinkFrameType Information Element requires the creation of new IANA registries. And this document requests that the existing Information Element Description are modified as shown in section 4 and 5 9. References 9.1. Normative References [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [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 Kashima, et al. Expires August 21, 2013 [Page 25] Internet-Draft Data Link Information Elements February 2013 (IPFIX)", RFC 6313, July 2011. 9.2. Informative References [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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-1: Untagged frame format Kashima, et al. Expires August 21, 2013 [Page 26] Internet-Draft Data Link Information Elements February 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 August 21, 2013 [Page 27] Internet-Draft Data Link Information Elements February 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 August 21, 2013 [Page 28] Internet-Draft Data Link Information Elements February 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 August 21, 2013 [Page 29] Internet-Draft Data Link Information Elements February 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 August 21, 2013 [Page 30] Internet-Draft Data Link Information Elements February 2013 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-6: S-TAG tagging frame format for S-Channel over the link between an end station and its adjacent bridge 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-TAG TPID=0x88a8 |S-PCP|D| S-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-TAG TPID=0x8100 |C-PCP|C| C-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kashima, et al. Expires August 21, 2013 [Page 31] Internet-Draft Data Link Information Elements February 2013 Figure A-7: S-TAG and C-TAG tagging frame format over the link between an end station and its adjacent bridge 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-8: E-TAG tagging frame format over the link between a Controlling Bridge and a Bridge Port Extender Kashima, et al. Expires August 21, 2013 [Page 32] Internet-Draft Data Link Information Elements February 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-9: E-TAG and C-TAG tagging frame format over the link between a Controlling Bridge and a Bridge Port Extender Kashima, et al. Expires August 21, 2013 [Page 33] Internet-Draft Data Link Information Elements February 2013 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 NTT Information Sharing Platform Lab. Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3894 Email: kashima@nttv6.net Kashima, et al. Expires August 21, 2013 [Page 34] Internet-Draft Data Link Information Elements February 2013 Atsushi Kobayashi NTT EAST IT Innovation Department 25F 3-20-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-1425 Japan Phone: +81 3 5353 3636 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 August 21, 2013 [Page 35]