IP Flow Information Export S. Kashima Internet-Draft K. Nakata Intended status: Standards Track NTT Expires: March 17, 2012 A. Kobayashi NTT East September 14, 2011 Information Elements for Data Link Layer Traffic Measurement draft-kashima-ipfix-data-link-layer-monitoring-06 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 March 17, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kashima, et al. Expires March 17, 2012 [Page 1] Internet-Draft Data Link Information Elements September 2011 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. Kashima, et al. Expires March 17, 2012 [Page 2] Internet-Draft Data Link Information Elements September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Extended Ethernet Technology . . . . . . . . . . . . . . . . . 4 2.1. Wide-Area Ethernet Summary . . . . . . . . . . . . . . . . 4 2.2. Data Center Bridging Summary . . . . . . . . . . . . . . . 5 2.3. Multiple Path Ethernet Summary . . . . . . . . . . . . . . 5 2.4. VXLAN Summary . . . . . . . . . . . . . . . . . . . . . . 6 3. New Information Elements . . . . . . . . . . . . . . . . . . . 6 3.1. dataLinkFrameSize . . . . . . . . . . . . . . . . . . . . 6 3.2. dataLinkFrameSection . . . . . . . . . . . . . . . . . . . 7 3.3. dataLinkFrameType . . . . . . . . . . . . . . . . . . . . 8 3.4. sectionOffset . . . . . . . . . . . . . . . . . . . . . . 8 3.5. sectionObservedOctets . . . . . . . . . . . . . . . . . . 8 3.6. dot1qServiceInstanceTag . . . . . . . . . . . . . . . . . 9 3.7. dot1qServiceInstanceId . . . . . . . . . . . . . . . . . . 9 3.8. dot1qServiceInstancePriority . . . . . . . . . . . . . . . 10 3.9. dot1qCustomerDestinationMacAddress . . . . . . . . . . . . 10 3.10. dot1qCustomerSourceMacAddress . . . . . . . . . . . . . . 10 4. Modification of Existing Information Elements Related to Packet Section . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. ipHeaderPacketSection . . . . . . . . . . . . . . . . . . 11 4.2. ipPayloadPacketSection . . . . . . . . . . . . . . . . . . 11 4.3. mplsLabelStackSection . . . . . . . . . . . . . . . . . . 11 4.4. mplsPayloadPacketSection . . . . . . . . . . . . . . . . . 12 5. Modification of Existing Information Elements Related to VLAN Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. dot1qVlanId . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. dot1qPriority . . . . . . . . . . . . . . . . . . . . . . 13 5.3. dot1qCustomerVlanId . . . . . . . . . . . . . . . . . . . 14 5.4. dot1qCustomerPriority . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Frame Formats in Wide-Area Ethernet Network . . . . . 18 Appendix B. Frame Formats in Data Center Network . . . . . . . . 22 Appendix C. Template Formats Example . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Kashima, et al. Expires March 17, 2012 [Page 3] Internet-Draft Data Link Information Elements September 2011 1. Introduction Ethernet [IEEE802.1D] and VLAN (Virtual LAN) [IEEE802.1Q-2005] technologies used to be used only in Local Area Networks. Recently, they have been used in Wide Area Networks, e.g., L2-VPN services. Accordingly, the IEEE802.1Q standard has been enhanced to IEEE802.1ad [IEEE802.1ad-2005] and IEEE802.1ah [IEEE802.1ah-2008]. 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 Summary Provider Bridge [IEEE802.1ad-2005] and Provider Backbone Bridge [IEEE802.1ah-2008], which are standards for the Wide-Area Ethernet, are described below. o In Provider Bridge [IEEE802.1ad-2005], 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.1ah-2008], new Ethernet fields, such as Backbone VLAN Identifier (B-VID) and Backbone Service Instance Identifier (I-SID), are introduced to overcome the limitations on the VLAN identifier space on IEEE802.1ad Kashima, et al. Expires March 17, 2012 [Page 4] Internet-Draft Data Link Information Elements September 2011 [IEEE802.1ad-2005] and to isolate the service provider and customer identifier spaces. Frame switching is based on a 12-bit B-VID, and customer identification is based on a 24-bit I-SID. A flexible network design has become possible because network management is separated from customer management. Other Ethernet fields that indicate quality of service (QoS) class are B-PCP, B-DEI, I-PCP, and I-DEI. Provider Backbone Bridge enables a wide-area Ethernet service to be improved from a flat network to a hierarchical network co-existing Provider Bridge and Provider Backbone Bridge. Frame formats used in Wide-Area Ethernet are shown in Appendix A. 2.2. Data Center Bridging Summary In data center networks, Ethernet needs to be enhanced to provide the flexibility, mobility for server virtualization, and I/O consolidation. In IEEE802.1 Data Center Bridging Task Group, several Ethernet header formats are proposed to enable a simplifying networks and server managements. The one of the enhanced methods is Bridge Port Extension [IEEE802.1Qbh], which brings a traffic exchange point to upper bridges. Bridge Port Extension introduces a Ethernet format named Extension Tag (E-TAG) in addition to existing Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG) to move the policy enhancement to upper bridges in data center network. On the other hand, the complexity for traffic measurement would be increased, because multiple Ethernet header formats as shown in Appendix B co-exist in the same network. 2.3. Multiple Path Ethernet Summary Inside data center networks, Ethernet need to be enhaced to support multiple path for effective utilization of bandwidth. Existing Ethernet does not support multiple path because it is based on STP (Spanning Tree Protocol) [IEEE802.1D]. Two solutions for multiple path Ethernet are discussed for standardization. One is Shortest Path Bridging [IEEE802.1aq] in IEEE 802, the other is TRILL (Transparent Interconnection of Lots of Links) [RFC6325] in IETF. Both solutions realize multiple path with IS-IS [ISO_IEC.10589_2002] and Layer 2 over Layer 2 encapsulation. Shortest Path Bridging uses IEEE802.1ah [IEEE802.1ah-2008] header as an encapsulation technology and TRILL uses an unique header as shown in Section 3 of [RFC6325]. Kashima, et al. Expires March 17, 2012 [Page 5] Internet-Draft Data Link Information Elements September 2011 In multiple path Ehternet network, a traffic measurement based on MAC address and VLAN Tag is more important than single path Ethernet network in which traffic measurement is based on only VLAN Tag. 2.4. VXLAN Summary Inside and between data center networks, the existing Ethernet and VLAN technologies have two problems. One is that 12 bit of VLAN ID does not have enough length for identifying a lot of tenants. The other is that it is difficult to place same VLAN in multiple data centers. The solution for the problems is VXLAN [I-D.mahalingam-dutt-dcops-vxlan]. VXLAN has 24 bit length of identifier named VXLAN Segment ID/VXLAN Network Identifier (VNI) and uses Layer 2 over Layer 3 encapsulation with the frame format as show in Section 5 of [I-D.mahalingam-dutt-dcops-vxlan]. 3. New Information Elements The following Information Elements are necessary for enabling the IPFIX/PSAMP traffic measurement for data link layer, which is not limited to Ethernet because the method can be applied to other data link protocols as well. Note that these are proposed IDs, subject to approval by IANA. +-----+------------------------------------+ | ID | Name | +-----+------------------------------------+ | 312 | dataLinkFrameSize | | 315 | dataLinkFrameSection | | 347 | dataLinkFrameType | | 348 | sectionOffset | | 349 | sectionObservedOctets | | 350 | dot1qServiceInstanceTag | | 351 | dot1qServiceInstanceId | | 352 | dot1qServiceInstancePriority | | 353 | dot1qCustomerDestinationMacAddress | | 354 | dot1qCustomerSourceMacAddress | +-----+------------------------------------+ 3.1. dataLinkFrameSize Description: Kashima, et al. Expires March 17, 2012 [Page 6] Internet-Draft Data Link Information Elements September 2011 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.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 Kashima, et al. Expires March 17, 2012 [Page 7] Internet-Draft Data Link Information Elements September 2011 3.3. dataLinkFrameType Description: This Information Element specifies the type of the selected data link frame. The following data link types are defined here. - 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: 347 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. Abstract Data Type: unsigned16 Data Type Semantics: quantity ElementId: 348 Status: current 3.5. sectionObservedOctets Description: This Information Element specifies the observed length of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection and Kashima, et al. Expires March 17, 2012 [Page 8] Internet-Draft Data Link Information Elements September 2011 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: 349 Status: current 3.6. dot1qServiceInstanceTag Description: This Information Element, which may have 16 octets length, carries the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1ah-2008]. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 350 Status: current 3.7. dot1qServiceInstanceId 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 section 9.8 of [IEEE802.1ah-2008]. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 351 Kashima, et al. Expires March 17, 2012 [Page 9] Internet-Draft Data Link Information Elements September 2011 Status: current 3.8. dot1qServiceInstancePriority 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 section 9.8 of [IEEE802.1ah-2008]. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 352 Status: current 3.9. dot1qCustomerDestinationMacAddress Description: The value of the Customer Destination Address (C-DA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in section 9.8 of [IEEE802.1ah-2008]. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah. Abstract Data Type: macAddress Data Type Semantics: identifier ElementId: 353 Status: current 3.10. dot1qCustomerSourceMacAddress Description: The value of the Customer Source Address (C-SA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in section 9.8 of [IEEE802.1ah-2008]. The structure and semantics within the Tag Control Information field are defined in IEEE802.1ah. Kashima, et al. Expires March 17, 2012 [Page 10] Internet-Draft Data Link Information Elements September 2011 Abstract Data Type: macAddress Data Type Semantics: identifier ElementId: 354 Status: current 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: Kashima, et al. Expires March 17, 2012 [Page 11] Internet-Draft Data Link Information Elements September 2011 TBD Abstract Data Type: octetArray 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 Information Elements related to Backbone Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG) are required in order to monitor IEEE802.1ah traffic with IPFIX/PSAMP. Because I-TAG has different structure and semantics from Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG), new Information Elements related to I-TAG are added in section 3. But because B-TAG has same different structure and semantics with C-TAG and S-TAG, Information Elements related to B-TAG reuse existing Information Elements related to C-TAG and S-TAG. Though they reuse existing Information Elements, it required to modify existing Descriptions and Reference 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 as described in section 3.5.5 of [IEEE802.3-2005]. The structure and semantics within the Tag Control Information field are defined in IEEE P802.1Q. In case of a QinQ frame it represents the outer tag's VLAN identifier, in case of an IEEE 802.1ad frame it represents the Service VLAN identifier in the S-TAG Tag Control Information (TCI) field as described in [IEEE802.1ad-2005] and in case of an IEEE 802.1ah frame it represents the Backbone VLAN identifier in the B-TAG Tag Control Information (TCI) field as described in Kashima, et al. Expires March 17, 2012 [Page 12] Internet-Draft Data Link Information Elements September 2011 [IEEE802.1ah-2008]. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 243 Status: current Reference: (1) [IEEE802.3-2005] (2) [IEEE802.1ad-2005] (3) [IEEE802.1ah-2008] 5.2. dot1qPriority Description: The value of the 3-bit User Priority portion of the Tag Control Information field of an Ethernet frame as described in section 3.5.5 of [IEEE802.3-2005]. The structure and semantics within the Tag Control Information field are defined in IEEE P802.1Q. In case of a QinQ frame it represents the outer tag's 3-bit Class of Service (CoS) identifier, in case of an IEEE 802.1ad frame it represents the 3-bit Priority Code Point (PCP) portion of the S-TAG Tag Control Information (TCI) field as described in [IEEE802.1ad-2005] and in case of an IEEE 802.1ah frame it represents the 3-bit Priority Code Point (PCP) portion of the B-TAG Tag Control Information (TCI) field as described in [IEEE802.1ah-2008]. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 244 Status: current Reference: (1) [IEEE802.3-2005] Kashima, et al. Expires March 17, 2012 [Page 13] Internet-Draft Data Link Information Elements September 2011 (2) [IEEE802.1ad-2005] (3) [IEEE802.1ah-2008] 5.3. dot1qCustomerVlanId Description: In case of a QinQ frame it represents the inner tag's (*) VLAN identifier, in case of an IEEE 802.1ad frame it represents the Customer VLAN identifier in the C-TAG Tag Control Information (TCI) field as described in [IEEE802.1ad-2005] and in case of an IEEE 802.1ah frame it represents the Customer VLAN identifier in the C-TAG Tag Control Information (TCI) field in encapsulated IEEE 802.1ad or IEEE 802.1Q frame as described in [IEEE802.1ah-2008]. (*) Note: the 802.1Q tag directly following the outer one. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 245 Status: current Reference: (1) [IEEE802.1ad-2005] (2) [IEEE802.1Q-2005] (3) [IEEE802.1ah-2008] 5.4. dot1qCustomerPriority Description: In case of a QinQ frame it represents the inner tag's (*) Class of Service (CoS) identifier, in case of an IEEE 802.1ad frame it represents the 3-bit Priority Code Point (PCP) portion of the C-TAG Tag Control Information (TCI) field as described in [IEEE802.1ad-2005] and in case of an IEEE 802.1ah frame it represents the 3-bit Priority Code Point (PCP) portion of the C-TAG Tag Control Information (TCI) field in encapsulated IEEE 802.1ad or IEEE 802.1Q frame as described in [IEEE802.1ad-2005]. (*) Note: the 802.1Q tag directly following the outer one. Abstract Data Type: unsigned8 Data Type Semantics: identifier Kashima, et al. Expires March 17, 2012 [Page 14] Internet-Draft Data Link Information Elements September 2011 ElementId: 246 Status: current Reference: (1) [IEEE802.1ad-2005] (2) [IEEE802.1Q-2005] (3) [IEEE802.1ah-2008] 6. Security Considerations The recommendations in this document do not introduce any additional security issues to those already mentioned in [RFC5101] and [RFC5477]. 7. 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 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.mahalingam-dutt-dcops-vxlan] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-00 (work in progress), August 2011. [IEEE802.1D] IEEE Computer Society, "IEEE Standards for Local and Kashima, et al. Expires March 17, 2012 [Page 15] Internet-Draft Data Link Information Elements September 2011 Metropolitan Area Networks: Media Access Control (MAC) Bridges", IEEE Std 802.1D-2004, June 2004. [IEEE802.1Q-2005] IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2005, May 2006. [IEEE802.1Qbh] IEEE Computer Society, "Draft Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment: Bridge Port Extension", IEEE Std P802.1Qbh/D1.1, February 2011. [IEEE802.1ad-2005] IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges", IEEE Std 802.1ad- 2005, May 2006. [IEEE802.1ah-2008] IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges", IEEE Std 802.1ah-2008, August 2008. [IEEE802.1aq] IEEE Computer Society, "Draft Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment: Shortest Path Bridging", IEEE Std P802.1aq/D3.6, February 2011. [IEEE802.3-2005] IEEE Computer Society, "IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2005, December 2005. [ISO_IEC.10589_2002] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network Kashima, et al. Expires March 17, 2012 [Page 16] Internet-Draft Data Link Information Elements September 2011 service (ISO 8473)", ISO Standard 10589:2002, November 2002. [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. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009. [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. [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. Kashima, et al. Expires March 17, 2012 [Page 17] Internet-Draft Data Link Information Elements September 2011 Appendix A. Frame Formats in Wide-Area Ethernet Network 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: IEEE802.1D Frame Format in Customer Bridged Network 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-TAG TCI=0x8100 |C-PCP|C| C-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-2: IEEE802.1Q Frame Format in Customer Bridged Network Kashima, et al. Expires March 17, 2012 [Page 18] Internet-Draft Data Link Information Elements September 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-TAG TCI=0x88a8 |S-PCP|D| S-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-3: IEEE802.1ad (no C-Tag) Frame Format in Provider Bridged Network 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-TAG TCI=0x88a8 |S-PCP|D| S-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-TAG TCI=0x8100 |C-PCP|C| C-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-4: IEEE802.1ad (C-Tagged) Frame Format in Provider Bridged Network Kashima, et al. Expires March 17, 2012 [Page 19] Internet-Draft Data Link Information Elements September 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-TAG TCI=0x88a8 |B-PCP|D| B-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-TAG TCI=0x88e7 |I-PCP|D|U| Res | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-DA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Length/Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-5: IEEE802.1ah (no C-Tag) Frame Format in Provider Backbone Bridged Network Kashima, et al. Expires March 17, 2012 [Page 20] Internet-Draft Data Link Information Elements September 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-TAG TCI=0x88a8 |B-PCP|D| B-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-TAG TCI=0x88e7 |I-PCP|D|U| Res | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-DA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | C-TAG TCI=0x8100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C-PCP|C| C-VID | Length/Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-6: IEEE802.1ah (C-Tagged) Frame Format in Provider Backbone Bridged Network Kashima, et al. Expires March 17, 2012 [Page 21] Internet-Draft Data Link Information Elements September 2011 Appendix B. Frame Formats in Data Center Network 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-TAG TCI=0x88a8 |S-PCP|D| S-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B-1: IEEE802.1Qbh (S-TAG) Frame Format in Data Center Network 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-TAG TCI=0x88a8 |S-PCP|D| S-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-TAG TCI=0x8100 |C-PCP|C| C-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B-2: IEEE802.1Qbh (S-TAG+C-TAG) Frame Format in Data Center Network Kashima, et al. Expires March 17, 2012 [Page 22] Internet-Draft Data Link Information Elements September 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-TAG TCI=0xXXXX |S-PCP|D| Ingress_E-CID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| E-CID | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B-3: IEEE802.1Qbh (E-TAG) Frame Format in Data Center Network 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-DA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C-SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-TAG TCI=0xXXXX |S-PCP|D| Ingress_E-CID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| E-CID | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-TAG TCI=0x8100 |C-PCP|C| C-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Customer Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B-4: IEEE802.1Qbh (E-TAG+C-TAG) Frame Format in Data Center Kashima, et al. Expires March 17, 2012 [Page 23] Internet-Draft Data Link Information Elements September 2011 Network Appendix C. 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 C-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 March 17, 2012 [Page 24] Internet-Draft Data Link Information Elements September 2011 Kensuke Nakata NTT Information Sharing Platform Lab. Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 6958 Email: nakata@nttv6.net 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 Kashima, et al. Expires March 17, 2012 [Page 25]