GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7133

Internet Engineering Task Force (IETF) S. Kashima Request for Comments: 7133 NTT Category: Standards Track A. Kobayashi, Ed. ISSN: 2070-1721 NTT East

                                                             P. Aitken
                                                   Cisco Systems, Inc.
                                                              May 2014
    Information Elements for Data Link Layer Traffic Measurement

Abstract

 This document describes Information Elements related to the data link
 layer.  They are used by the IP Flow Information Export (IPFIX)
 protocol for encoding measured data link layer traffic information.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7133.

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Kashima, et al. Standards Track [Page 1] RFC 7133 Data Link Layer Information Elements May 2014

Table of Contents

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

Kashima, et al. Standards Track [Page 2] RFC 7133 Data Link Layer Information Elements May 2014

    5.4. dot1qCustomerPriority .....................................27
 6. The Relationship between Ethernet Header Fields and
    Information Elements ...........................................28
 7. Security Considerations ........................................29
 8. IANA Considerations ............................................29
 9. Acknowledgments ................................................30
 10. References ....................................................30
    10.1. Normative References .....................................30
    10.2. Informative References ...................................31
 Appendix A.  Frame Formats ........................................32
 Appendix B.  Template Format Example ..............................40

Kashima, et al. Standards Track [Page 3] RFC 7133 Data Link Layer Information Elements May 2014

1. Introduction

 Ethernet [IEEE802.1D] and VLAN (Virtual LAN) technologies had been
 used only in Local Area Networks.  Recently, they have been used in
 Wide Area Networks, e.g., Layer 2 VPN (L2 VPN) services.
 Accordingly, carrier networks using VLAN technologies have been
 enhanced to Provider Bridged Networks and Provider Backbone Bridged
 Networks [IEEE802.1Q].  In addition, Ethernet in data centers has
 also been enhanced for server virtualization and input/output (I/O)
 consolidation.
 While these innovations provide flexibility, scalability, and
 mobility to an existing network architecture, they increase the
 complexity of traffic measurement due to the existence of various
 Ethernet header formats.  To cope with this, a more sophisticated
 method of traffic measurement is required.
 IPFIX and Packet Sampling (PSAMP) help to resolve these problems.
 However, the PSAMP Information Model [RFC5477] and the IPFIX
 Information Model [RFC7011] don't yet contain enough Information
 Elements related to the data link layer, e.g., Ethernet header forms.
 This document describes existing and new Information Elements related
 to data link layers that enable a more sophisticated traffic
 measurement method.
 Note that this document does not update [RFC5477] or [RFC7011]
 because IANA's IPFIX registry [IANA-IPFIX] is the ultimate
 Information Element reference, per Section 1 of [RFC7012].

1.1. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

2. Extended Ethernet Technology

2.1. Wide-Area Ethernet Technology Summary

 Provider Bridge and Provider Backbone Bridge [IEEE802.1Q], which are
 standards for Wide-Area Ethernet, are described below.
 o  In Provider Bridge [IEEE802.1Q], there are two VLAN IDs: Service
    VLAN Identifier (S-VID) and Customer VLAN Identifier (C-VID).
    S-VID is assigned to an Ethernet frame by a service provider,
    while C-VID is independently assigned to an Ethernet frame by a
    customer.  Frame switching in a service provider network is based
    on only S-VID.

Kashima, et al. Standards Track [Page 4] RFC 7133 Data Link Layer Information Elements May 2014

 o  In Provider Backbone Bridge [IEEE802.1Q], new Ethernet fields,
    such as Backbone VLAN Identifier (B-VID) and Backbone Service
    Instance Identifier (I-SID), are introduced to overcome the
    limitations on the VLAN identifier space and to isolate the
    service provider and customer identifier spaces.  Frame switching
    is based on a 12-bit B-VID, and customer identification is based
    on a 24-bit I-SID.  A flexible network design has become possible
    because network management is separated from customer management.
    Other Ethernet fields that indicate quality of service (QoS) class
    are Backbone VLAN Priority Code Point (B-PCP), Backbone VLAN Drop
    Eligible Indicator (B-DEI), Backbone Service Instance Priority
    Code Point (I-PCP), and Backbone Service Instance Drop Eligible
    Indicator (I-DEI).
 The Provider Backbone Bridge technologies have enhanced a Wide-Area
 Ethernet service from a flat network to a hierarchical network
 consisting of a Provider Bridged Network and Provider Backbone
 Bridged Network.
 Frame formats used in Wide-Area Ethernet are shown in Appendix A.

2.2. Virtual Ethernet Technology Summary

 There have been several challenges in the existing virtual switches
 environment in a data center.  One is the lack of network management
 visibility: limited features on virtual switches make it difficult to
 monitor traffic among virtual machines (VMs).  Another is the lack of
 management scalability and flexibility: increasing the number of VMs
 for multi-tenant architecture causes an increase in the number of
 virtual switches and in the number of the traffic control policies,
 which reach the limitations of network management scalability and
 flexibility.
 In this situation, the IEEE 802.1 working group is standardizing
 virtual bridging technologies such as Edge Virtual Bridging (EVB),
 including two kinds of Edge Relays: Virtual Edge Bridge (VEB) and
 Virtual Edge Port Aggregator (VEPA) [IEEE802.1Qbg].  The VEB is a
 bridge that provides bridging among multiple VMs and the external
 bridging environment.  The VEPA is a bridge-like device on a host
 that forwards all internal traffic to the adjacent EVB bridge and
 then distributes any traffic received from the adjacent EVB bridge to
 VMs.  The VEPA makes all the VM-to-VM traffic visible to the EVB
 bridge so that the traffic can be monitored and so that the EVB
 bridge can apply filtering to the traffic.
 To improve flexibility, a virtual link between a host system and EVB
 bridge is standardized as S-channel.  S-channel allows a bridge to
 treat the traffic in the virtual link as if it comes in on a separate

Kashima, et al. Standards Track [Page 5] RFC 7133 Data Link Layer Information Elements May 2014

 port.  For example, in the host, an S-channel may be attached to a
 VEB or a VEPA or directly to an internal port in order to apply each
 port-based filtering rule to the traffic.  S-channel over the link
 between a host and its adjacent bridge uses Service VLAN Tag (S-TAG)
 [IEEE802.1Q].  When S-channel is in use, frames on the link carry an
 S-TAG to identify the S-channel.
 On the other hand, Bridge Port Extension emulates single Extended
 Bridge from multiple physical switches and virtual switches, and it
 also simplifies network management.  Also, it solves the lack of
 network management visibility by forwarding all traffic into a
 central Controlling Bridge using E-channel.  E-channel over the link
 between a Bridge Port Extender and a Controlling Bridge uses E-TAG
 defined in [IEEE802.1BR].
 Traffic monitoring over S-channel and E-channel is required in order
 to get visibility of VM-to-VM traffic and visibility of each
 channel's traffic on a virtual link.
 Frame formats with E-TAG used in E-channel and S-TAG used in
 S-channel are shown in Appendix A.  Though these frames carry special
 tags while on the link, those tags identify a virtual port (or for
 multicast in the downstream direction, a set of virtual ports) to
 which they are destined.  These tag values only have local meaning,
 and the Flow would be reported as sent and arriving on the
 corresponding virtual ports.  Therefore, IPFIX does not need to
 monitor data based on these tags.

3. Modification and Addition of Information Elements Related to Data

  Link Layer
 The Information Elements listed in the upper section of Table 1 are
 necessary for enabling IPFIX and PSAMP traffic measurement for the
 data link layer, which is not limited to Ethernet because the method
 can be applied to other data link protocols as well.
 Information Elements in the middle section of Table 1 are necessary
 for enabling the IPFIX and PSAMP traffic measurement for
 [IEEE802.1Q].
 Information Elements in the lower section of Table 1 are octet
 counter or packet length for layer 2, and they are necessary for
 enabling IPFIX and PSAMP traffic measurement for the data link layer.

Kashima, et al. Standards Track [Page 6] RFC 7133 Data Link Layer Information Elements May 2014

             +-----+------------------------------------+
             | ID  | Name                               |
             +-----+------------------------------------+
             | 312 | dataLinkFrameSize                  |
             | 315 | dataLinkFrameSection               |
             | 408 | dataLinkFrameType                  |
             | 409 | sectionOffset                      |
             | 410 | sectionExportedOctets              |
             +-----+------------------------------------+
             | 411 | dot1qServiceInstanceTag            |
             | 412 | dot1qServiceInstanceId             |
             | 413 | dot1qServiceInstancePriority       |
             | 414 | dot1qCustomerSourceMacAddress      |
             | 415 | dot1qCustomerDestinationMacAddress |
             +-----+------------------------------------+
             | 352 | layer2OctetDeltaCount              |
             | 353 | layer2OctetTotalCount              |
             | 417 | postL2OctetDeltaCount              |
             | 418 | postMCastL2OctetDeltaCount         |
             | 420 | postL2OctetTotalCount              |
             | 421 | postMCastL2OctetTotalCount         |
             | 422 | minimumL2TotalLength               |
             | 423 | maximumL2TotalLength               |
             | 424 | droppedL2OctetDeltaCount           |
             | 425 | droppedL2OctetTotalCount           |
             | 426 | ignoredL2OctetTotalCount           |
             | 427 | notSentL2OctetTotalCount           |
             | 428 | layer2OctetDeltaSumOfSquares       |
             | 429 | layer2OctetTotalSumOfSquares       |
             | 430 | layer2FrameDeltaCount              |
             | 431 | layer2FrameTotalCount              |
             +-----+------------------------------------+
       Table 1: Information Elements Related to Data Link Layer

3.1. Existing Information Elements

 Some existing Information Elements are required for data link layer
 export.  Their details are reproduced here from IANA's IPFIX registry
 [IANA-IPFIX].  Additions per this document appear between *.
 Section 3.1.1 introduces the missing Data Type Semantics for the
 dataLinkFrameSize Information Element, which is held to be an
 interoperable change per #4 in Section 5.2 of [RFC7013].

Kashima, et al. Standards Track [Page 7] RFC 7133 Data Link Layer Information Elements May 2014

 Section 3.1.2 extends the definition of the dataLinkFrameSection
 Information Element with reference to the new sectionOffset
 Information Element, which is also an interoperable change per #4 in
 Section 5.2 of [RFC7013].
 The layer2OctetDeltaCount Information Element reports the number of
 layer 2 octets since the previous report in incoming packets for this
 Flow, while the layer2OctetTotalCount Information Element reports the
 total number of layer 2 octets in incoming packets for this Flow.
 The layer2FrameDeltaCount Information Element reports the number of
 incoming layer 2 frames since the previous report for this Flow,
 while layer2FrameTotalCount Information Element reports the total
 number of incoming layer 2 frames for this Flow.  All of these
 Information Elements are unchanged from the existing IANA
 [IANA-IPFIX] definitions, and are reproduced in Section 3.1.3 through
 Section 3.1.6 below for completeness.
 Therefore, these changes do not introduce any backward-compatibility
 issues.
 Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133]
 has been appended to the requester in IANA's IPFIX registry
 [IANA-IPFIX], the Information Element's revision number has been
 incremented by one, and the Information Element's revision date
 column has been updated.

3.1.1. dataLinkFrameSize

 Description:
    This Information Element specifies the length of the selected data
    link frame.
    The data link layer is defined in [ISO/IEC.7498-1:1994].
 Abstract Data Type: unsigned16
  • Data Type Semantics: quantity*
 ElementId: 312
 References: [ISO/IEC.7498-1:1994]
 Status: current

Kashima, et al. Standards Track [Page 8] RFC 7133 Data Link Layer Information Elements May 2014

3.1.2. dataLinkFrameSection

 Description:
    This Information Element carries n octets from the data link frame
    of a selected frame, starting sectionOffset octets into the frame.
  • However, if no sectionOffset field corresponding to this

Information Element is present, then a sectionOffset of zero

    applies, and the octets MUST be from the start of the data link
    frame.*
    The sectionExportedOctets expresses how much data was observed,
    while the remainder is padding.
    When the sectionExportedOctets field corresponding to this
    Information Element exists, this Information Element MAY have a
    fixed length and MAY be padded, or it MAY have a variable length.
    When the sectionExportedOctets field corresponding to this
    Information Element does not exist, this Information Element
    SHOULD have a variable length and MUST NOT be padded.  In this
    case, the size of the exported section may be constrained due to
    limitations in the IPFIX protocol.
    Further Information Elements, i.e., dataLinkFrameType and
    dataLinkFrameSize, are needed to specify the data link type and
    the size of the data link frame of this Information Element.  A
    set of these Information Elements MAY be contained in a structured
    data type, as expressed in [RFC6313].  Or a set of these
    Information Elements MAY be contained in one Flow Record as shown
    in Appendix B of [RFC7133].
    The data link layer is defined in [ISO/IEC.7498-1:1994].
 Abstract Data Type: octetArray
 ElementId: 315
 References: [RFC6313] [RFC7133] [ISO/IEC.7498-1:1994]
 Status: current

3.1.3. layer2OctetDeltaCount

 The layer2OctetDeltaCount Information Element is unchanged from the
 existing IANA [IANA-IPFIX] definition and is reproduced here for
 reference only.

Kashima, et al. Standards Track [Page 9] RFC 7133 Data Link Layer Information Elements May 2014

 Description
    The number of layer 2 octets since the previous report (if any) in
    incoming packets for this Flow at the Observation Point.  The
    number of octets includes layer 2 header(s) and layer 2 payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 Units: octets
 ElementId: 352
 Status: current

3.1.4. layer2OctetTotalCount

 The layer2OctetTotalCount Information Element is unchanged from the
 existing IANA [IANA-IPFIX] definition and is reproduced here for
 reference only.
 Description:
    The total number of layer 2 octets in incoming packets for this
    Flow at the Observation Point since the Metering Process
    (re-)initialization for this Observation Point.  The number of
    octets includes layer 2 header(s) and layer 2 payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 Units: octets
 ElementId: 353
 Status: current

3.1.5. layer2FrameDeltaCount

 The layer2FrameDeltaCount Information Element is unchanged from the
 existing IANA [IANA-IPFIX] definition and is reproduced here for
 reference only.

Kashima, et al. Standards Track [Page 10] RFC 7133 Data Link Layer Information Elements May 2014

 Description:
    The number of incoming layer 2 frames since the previous report
    (if any) for this Flow at the Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 Units: frames
 ElementId: 430
 Status: current

3.1.6. layer2FrameTotalCount

 The layer2FrameTotalCount Information Element is unchanged from the
 existing IANA [IANA-IPFIX] definition and is reproduced here for
 reference only.
 Description:
    The total number of incoming layer 2 frames for this Flow at the
    Observation Point since the Metering Process (re-)initialization
    for this Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 Units: frames
 ElementId: 431
 Status: current

3.2. New Information Elements

 The following new Information Elements have been added for data link
 layer monitoring.
 In IANA's IPFIX registry [IANA-IPFIX], the Requester has been set to
 [RFC7133], the Information Element's Revision has been set to zero,
 and the Information Element's Date set to the date upon which the new
 Information Elements have been added to the registry.  All other

Kashima, et al. Standards Track [Page 11] RFC 7133 Data Link Layer Information Elements May 2014

 columns that are not explicitly mentioned below (e.g., Units, Range,
 References) are not applicable and are to be left blank since the
 registry does not explicitly record "not applicable".

3.2.1. dataLinkFrameType

 Description:
    This Information Element specifies the type of the selected data
    link frame.
    The following data link types are defined here:
  1. 0x01 IEEE802.3 ETHERNET [IEEE802.3]
  1. 0x02 IEEE802.11 MAC Frame format [IEEE802.11]
    Further values may be assigned by IANA.  Note that the assigned
    values are bits so that multiple observations can be OR'd
    together.
    The data link layer is defined in [ISO/IEC.7498-1:1994].
 Abstract Data Type: unsigned16
 Data Type Semantics: flags
 ElementId: 408
 References: [IEEE802.3] [IEEE802.11] [ISO/IEC.7498-1:1994]
 Status: current

3.2.2. sectionOffset

 Description:
    This Information Element specifies the offset of the packet
    section (e.g., dataLinkFrameSection, ipHeaderPacketSection,
    ipPayloadPacketSection, mplsLabelStackSection, and
    mplsPayloadPacketSection).  If this Information Element is
    omitted, it defaults to zero (i.e., no offset).
    If multiple sectionOffset Information Elements are specified
    within a single Template, then they apply to the packet section
    Information Elements in order: the first sectionOffset applies to
    the first packet section, the second to the second, and so on.
    Note that the "closest" sectionOffset and packet section

Kashima, et al. Standards Track [Page 12] RFC 7133 Data Link Layer Information Elements May 2014

    Information Elements within a given Template are not necessarily
    related.  If there are fewer sectionOffset Information Elements
    than packet section Information Elements, then subsequent packet
    section Information Elements have no offset, i.e., a sectionOffset
    of zero applies to those packet section Information Elements.  If
    there are more sectionOffset Information Elements than the number
    of packet section Information Elements, then the additional
    sectionOffset Information Elements are meaningless.
 Abstract Data Type: unsigned16
 Data Type Semantics: quantity
 ElementId: 409
 Status: current

3.2.3. sectionExportedOctets

 Description:
    This Information Element specifies the observed length of the
    packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection,
    ipPayloadPacketSection, mplsLabelStackSection, and
    mplsPayloadPacketSection) when padding is used.
    The packet section may be of a fixed size larger than the
    sectionExportedOctets.  In this case, octets in the packet section
    beyond the sectionExportedOctets MUST follow the [RFC7011] rules
    for padding (i.e., be composed of zero (0) valued octets).
 Abstract Data Type: unsigned16
 Data Type Semantics: quantity
 ElementId: 410
 References: [RFC7011]
 Status: current

3.2.4. dot1qServiceInstanceTag

 Description:
    This Information Element, which is 16 octets long, represents the
    Backbone Service Instance Tag (I-TAG) Tag Control Information
    (TCI) field of an Ethernet frame as described in [IEEE802.1Q].  It

Kashima, et al. Standards Track [Page 13] RFC 7133 Data Link Layer Information Elements May 2014

    encodes the Backbone Service Instance Priority Code Point (I-PCP),
    Backbone Service Instance Drop Eligible Indicator (I-DEI), Use
    Customer Addresses (UCAs), Backbone Service Instance Identifier
    (I-SID), Encapsulated Customer Destination Address (C-DA),
    Encapsulated Customer Source Address (C-SA), and reserved fields.
    The structure and semantics within the Tag Control Information
    field are defined in [IEEE802.1Q].
 Abstract Data Type: octetArray
 Data Type Semantics: default
 ElementId: 411
 References: [IEEE802.1Q]
 Status: current

3.2.5. dot1qServiceInstanceId

 Description:
    The value of the 24-bit Backbone Service Instance Identifier
    (I-SID) portion of the Backbone Service Instance Tag (I-TAG) Tag
    Control Information (TCI) field of an Ethernet frame as described
    in [IEEE802.1Q].
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 412
 References: [IEEE802.1Q]
 Status: current
 Range: The valid range is 0 - 16777215 (i.e., 24 bits).

3.2.6. dot1qServiceInstancePriority

 Description:
    The value of the 3-bit Backbone Service Instance Priority Code
    Point (I-PCP) portion of the Backbone Service Instance Tag (I-TAG)
    Tag Control Information (TCI) field of an Ethernet frame as
    described in [IEEE802.1Q].

Kashima, et al. Standards Track [Page 14] RFC 7133 Data Link Layer Information Elements May 2014

 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 413
 References: [IEEE802.1Q]
 Status: current
 Range: The valid range is 0-7.

3.2.7. dot1qCustomerSourceMacAddress

 Description:
    The value of the Encapsulated Customer Source Address (C-SA)
    portion of the Backbone Service Instance Tag (I-TAG) Tag Control
    Information (TCI) field of an Ethernet frame as described in
    [IEEE802.1Q].
 Abstract Data Type: macAddress
 Data Type Semantics: default
 ElementId: 414
 References: [IEEE802.1Q]
 Status: current

3.2.8. dot1qCustomerDestinationMacAddress

 Description:
    The value of the Encapsulated Customer Destination Address (C-DA)
    portion of the Backbone Service Instance Tag (I-TAG) Tag Control
    Information (TCI) field of an Ethernet frame as described in
    [IEEE802.1Q].
 Abstract Data Type: macAddress
 Data Type Semantics: default
 ElementId: 415

Kashima, et al. Standards Track [Page 15] RFC 7133 Data Link Layer Information Elements May 2014

 References: [IEEE802.1Q]
 Status: current

3.2.9. postL2OctetDeltaCount

 Description:
    The definition of this Information Element is identical to the
    definition of the layer2OctetDeltaCount Information Element,
    except that it reports a potentially modified value caused by a
    middlebox function after the packet passed the Observation Point.
    This Information Element is the layer 2 version of
    postOctetDeltaCount (ElementId #23).
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 417
 References: [RFC5477]
 Status: current
 Units: octets

3.2.10. postMCastL2OctetDeltaCount

 Description:
    The number of layer 2 octets since the previous report (if any) in
    outgoing multicast packets sent for packets of this Flow by a
    multicast daemon within the Observation Domain.  This property
    cannot necessarily be observed at the Observation Point but may be
    retrieved by other means.  The number of octets includes layer 2
    header(s) and layer 2 payload.
    This Information Element is the layer 2 version of
    postMCastOctetDeltaCount (ElementId #20).
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 418

Kashima, et al. Standards Track [Page 16] RFC 7133 Data Link Layer Information Elements May 2014

 References: [RFC5477]
 Status: current
 Units: octets

3.2.11. postL2OctetTotalCount

 Description:
    The definition of this Information Element is identical to the
    definition of the layer2OctetTotalCount Information Element,
    except that it reports a potentially modified value caused by a
    middlebox function after the packet passed the Observation Point.
    This Information Element is the layer 2 version of
    postOctetTotalCount (ElementId #171).
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 420
 References: [RFC5477]
 Status: current
 Units: octets

3.2.12. postMCastL2OctetTotalCount

 Description:
    The total number of layer 2 octets in outgoing multicast packets
    sent for packets of this Flow by a multicast daemon in the
    Observation Domain since the Metering Process (re-)initialization.
    This property cannot necessarily be observed at the Observation
    Point but may be retrieved by other means.  The number of octets
    includes layer 2 header(s) and layer 2 payload.
    This Information Element is the layer 2 version of
    postMCastOctetTotalCount (ElementId #175).
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter

Kashima, et al. Standards Track [Page 17] RFC 7133 Data Link Layer Information Elements May 2014

 ElementId: 421
 References: [RFC5477]
 Status: current
 Units: octets

3.2.13. minimumL2TotalLength

 Description:
    Layer 2 length of the smallest packet observed for this Flow.  The
    packet length includes the length of the layer 2 header(s) and the
    length of the layer 2 payload.
    This Information Element is the layer 2 version of
    minimumIpTotalLength (ElementId #25).
 Abstract Data Type: unsigned64
 ElementId: 422
 References: [RFC5477]
 Status: current
 Units: octets

3.2.14. maximumL2TotalLength

 Description:
    Layer 2 length of the largest packet observed for this Flow.  The
    packet length includes the length of the layer 2 header(s) and the
    length of the layer 2 payload.
    This Information Element is the layer 2 version of
    maximumIpTotalLength (ElementId #26).
 Abstract Data Type: unsigned64
 ElementId: 423
 References: [RFC5477]

Kashima, et al. Standards Track [Page 18] RFC 7133 Data Link Layer Information Elements May 2014

 Status: current
 Units: octets

3.2.15. droppedL2OctetDeltaCount

 Description:
    The number of layer 2 octets since the previous report (if any) in
    packets of this Flow dropped by packet treatment.  The number of
    octets includes layer 2 header(s) and layer 2 payload.
    This Information Element is the layer 2 version of
    droppedOctetDeltaCount (ElementId #132).
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 424
 References: [RFC5477]
 Status: current
 Units: octets

3.2.16. droppedL2OctetTotalCount

 Description:
    The total number of octets in observed layer 2 packets (including
    the layer 2 header) that were dropped by packet treatment since
    the (re-)initialization of the Metering Process.
    This Information Element is the layer 2 version of
    droppedOctetTotalCount (ElementId #134).
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 425
 References: [RFC5477]

Kashima, et al. Standards Track [Page 19] RFC 7133 Data Link Layer Information Elements May 2014

 Status: current
 Units: octets

3.2.17. ignoredL2OctetTotalCount

 Description:
    The total number of octets in observed layer 2 packets (including
    the layer 2 header) that the Metering Process did not process
    since the (re-)initialization of the Metering Process.
    This Information Element is the layer 2 version of
    ignoredOctetTotalCount (ElementId #165).
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 426
 References: [RFC5477]
 Status: current
 Units: octets

3.2.18. notSentL2OctetTotalCount

 Description:
    The total number of octets in observed layer 2 packets (including
    the layer 2 header) that the Metering Process did not process
    since the (re-)initialization of the Metering Process.
    This Information Element is the layer 2 version of
    notSentOctetTotalCount (ElementId #168).
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 427
 References: [RFC5477]

Kashima, et al. Standards Track [Page 20] RFC 7133 Data Link Layer Information Elements May 2014

 Status: current
 Units: octets

3.2.19. layer2OctetDeltaSumOfSquares

 Description:
    The sum of the squared numbers of layer 2 octets per incoming
    packet since the previous report (if any) for this Flow at the
    Observation Point.  The number of octets includes layer 2
    header(s) and layer 2 payload.
    This Information Element is the layer 2 version of
    octetDeltaSumOfSquares (ElementId #198).
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 428
 References: [RFC5477]
 Status: current
 Units: octets

3.2.20. layer2OctetTotalSumOfSquares

 Description:
    The total sum of the squared numbers of layer 2 octets in incoming
    packets for this Flow at the Observation Point since the Metering
    Process (re-)initialization for this Observation Point.  The
    number of octets includes layer 2 header(s) and layer 2 payload.
    This Information Element is the layer 2 version of
    octetTotalSumOfSquares (ElementId #199).
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 429
 References: [RFC5477]

Kashima, et al. Standards Track [Page 21] RFC 7133 Data Link Layer Information Elements May 2014

 Status: current
 Units: octets

4. Modification of Existing Information Elements Related to Packet

  Section
 The new Information Elements related to packet section (i.e.,
 sectionOffset and sectionExportedOctets) can be applied to not only
 dataLinkFrameSection but also to all kinds of packet section (i.e.,
 ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection,
 and mplsPayloadPacketSection defined in [RFC5477]).  Therefore,
 existing Information Elements Descriptions should be modified as
 follows.

4.1. ipHeaderPacketSection

 This Information Element is defined in [RFC5477].  The description
 has been updated from [RFC5477].
 Description:
    This Information Element carries a series of n octets from the IP
    header of a sampled packet, starting sectionOffset octets into the
    IP header.
    However, if no sectionOffset field corresponding to this
    Information Element is present, then a sectionOffset of zero
    applies, and the octets MUST be from the start of the IP header.
    With sufficient length, this element also reports octets from the
    IP payload.  However, full packet capture of arbitrary packet
    streams is explicitly out of scope per the Security Considerations
    sections of [RFC5477] and [RFC2804].
    The sectionExportedOctets expresses how much data was exported,
    while the remainder is padding.
    When the sectionExportedOctets field corresponding to this
    Information Element exists, this Information Element MAY have a
    fixed length and MAY be padded, or it MAY have a variable length.
    When the sectionExportedOctets field corresponding to this
    Information Element does not exist, this Information Element
    SHOULD have a variable length and MUST NOT be padded.  In this
    case, the size of the exported section may be constrained due to
    limitations in the IPFIX protocol.

Kashima, et al. Standards Track [Page 22] RFC 7133 Data Link Layer Information Elements May 2014

 Abstract Data Type: octetArray
 ElementId: 313
 References: [RFC2804] [RFC5477]
 Status: current

4.2. ipPayloadPacketSection

 This Information Element is defined in [RFC5477].  The description is
 updated from [RFC5477].
 Description:
    This Information Element carries a series of n octets from the IP
    payload of a sampled packet, starting sectionOffset octets into
    the IP payload.
    However, if no sectionOffset field corresponding to this
    Information Element is present, then a sectionOffset of zero
    applies, and the octets MUST be from the start of the IP payload.
    The IPv4 payload is that part of the packet that follows the IPv4
    header and any options, which [RFC0791] refers to as "data" or
    "data octets".  For example, see the examples in [RFC0791],
    Appendix A.
    The IPv6 payload is the rest of the packet following the 40-octet
    IPv6 header.  Note that any extension headers present are
    considered part of the payload.  See [RFC2460] for the IPv6
    specification.
    The sectionExportedOctets expresses how much data was observed,
    while the remainder is padding.
    When the sectionExportedOctets field corresponding to this
    Information Element exists, this Information Element MAY have a
    fixed length and MAY be padded, or it MAY have a variable length.
    When the sectionExportedOctets field corresponding to this
    Information Element does not exist, this Information Element
    SHOULD have a variable length and MUST NOT be padded.  In this
    case, the size of the exported section may be constrained due to
    limitations in the IPFIX protocol.

Kashima, et al. Standards Track [Page 23] RFC 7133 Data Link Layer Information Elements May 2014

 Abstract Data Type: octetArray
 ElementId: 314
 References: [RFC0791] [RFC2460]
 Status: current

4.3. mplsLabelStackSection

 This Information Element is defined in [RFC5477].  The description is
 updated from [RFC5477].
 Description:
    This Information Element carries a series of n octets from the
    MPLS label stack of a sampled packet, starting sectionOffset
    octets into the MPLS label stack.
    However, if no sectionOffset field corresponding to this
    Information Element is present, then a sectionOffset of zero
    applies, and the octets MUST be from the head of the MPLS label
    stack.
    With sufficient length, this element also reports octets from the
    MPLS payload.  However, full packet capture of arbitrary packet
    streams is explicitly out of scope per the Security Considerations
    sections of [RFC5477] and [RFC2804].
    See [RFC3031] for the specification of MPLS packets.
    See [RFC3032] for the specification of the MPLS label stack.
    The sectionExportedOctets expresses how much data was observed,
    while the remainder is padding.
    When the sectionExportedOctets field corresponding to this
    Information Element exists, this Information Element MAY have a
    fixed length and MAY be padded, or it MAY have a variable length.
    When the sectionExportedOctets field corresponding to this
    Information Element does not exist, this Information Element
    SHOULD have a variable length and MUST NOT be padded.  In this
    case, the size of the exported section may be constrained due to
    limitations in the IPFIX protocol.

Kashima, et al. Standards Track [Page 24] RFC 7133 Data Link Layer Information Elements May 2014

 Abstract Data Type: octetArray
 ElementId: 316
 References: [RFC2804] [RFC3031] [RFC3032] [RFC5477]
 Status: current

4.4. mplsPayloadPacketSection

 This Information Element is defined in [RFC5477].  The description is
 updated from [RFC5477].
 Description:
    The mplsPayloadPacketSection carries a series of n octets from the
    MPLS payload of a sampled packet, starting sectionOffset octets
    into the MPLS payload, as it is data that follows immediately
    after the MPLS label stack.
    However, if no sectionOffset field corresponding to this
    Information Element is present, then a sectionOffset of zero
    applies, and the octets MUST be from the start of the MPLS
    payload.
    See [RFC3031] for the specification of MPLS packets.
    See [RFC3032] for the specification of the MPLS label stack.
    The sectionExportedOctets expresses how much data was observed,
    while the remainder is padding.
    When the sectionExportedOctets field corresponding to this
    Information Element exists, this Information Element MAY have a
    fixed length and MAY be padded, or it MAY have a variable length.
    When the sectionExportedOctets field corresponding to this
    Information Element does not exist, this Information Element
    SHOULD have a variable length and MUST NOT be padded.  In this
    case, the size of the exported section may be constrained due to
    limitations in the IPFIX protocol.
 Abstract Data Type: octetArray
 ElementId: 317

Kashima, et al. Standards Track [Page 25] RFC 7133 Data Link Layer Information Elements May 2014

 References: [RFC3031] [RFC3032]
 Status: current

5. Modification of Existing Information Elements Related to VLAN Tag

 The traffic measurement using IPFIX and PSAMP for a Provider Backbone
 Bridged Network requires the Information Elements related to Backbone
 Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG).  The set
 of Information Elements related to I-TAG is added in Section 3,
 because I-TAG structure and semantics are different from that of
 Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG).  The set of
 Information Elements related to B-TAG reuses the existing Information
 Elements, because B-TAG structure and semantics are identical to that
 of C-TAG and S-TAG.  This section modifies existing descriptions and
 references related to C-TAG and S-TAG as follows.

5.1. dot1qVlanId

 Description:
    The value of the 12-bit VLAN Identifier portion of the Tag Control
    Information field of an Ethernet frame.  The structure and
    semantics within the Tag Control Information field are defined in
    [IEEE802.1Q].  In Provider Bridged Networks, it represents the
    Service VLAN identifier in the Service VLAN Tag (S-TAG) Tag
    Control Information (TCI) field or the Customer VLAN identifier in
    the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field
    as described in [IEEE802.1Q].  In Provider Backbone Bridged
    Networks, it represents the Backbone VLAN identifier in the
    Backbone VLAN Tag (B-TAG) Tag Control Information (TCI) field as
    described in [IEEE802.1Q].  In a virtual link between a host
    system and EVB bridge, it represents the Service VLAN identifier
    indicating S-channel as described in [IEEE802.1Qbg].
    In the case of a multi-tagged frame, it represents the outer tag's
    VLAN identifier, except for I-TAG.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 243
 Status: current
 References: [IEEE802.1Q] [IEEE802.1Qbg]

Kashima, et al. Standards Track [Page 26] RFC 7133 Data Link Layer Information Elements May 2014

5.2. dot1qPriority

 Description:
    The value of the 3-bit User Priority portion of the Tag Control
    Information field of an Ethernet frame.  The structure and
    semantics within the Tag Control Information field are defined in
    [IEEE802.1Q].  In the case of a multi-tagged frame, it represents
    the 3-bit Priority Code Point (PCP) portion of the outer tag's Tag
    Control Information (TCI) field as described in [IEEE802.1Q],
    except for I-TAG.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 244
 Status: current
 References: [IEEE802.1Q]

5.3. dot1qCustomerVlanId

 Description:
    The value represents the Customer VLAN identifier in the Customer
    VLAN Tag (C-TAG) Tag Control Information (TCI) field as described
    in [IEEE802.1Q].
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 245
 Status: current
 References: [IEEE802.1Q]

5.4. dot1qCustomerPriority

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

Kashima, et al. Standards Track [Page 27] RFC 7133 Data Link Layer Information Elements May 2014

 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 246
 Status: current
 References: [IEEE802.1Q]

6. The Relationship between Ethernet Header Fields and Information

  Elements
 The following figures show a summary of various Ethernet header
 fields and the Informational Elements that would be used to represent
 each of the fields.
  <-- 6 --> <-- 6 --> <-- 4 --> <---- 2 ---->
 +---------+---------+---------+-------------+
 |         |         |         |             |
 |  C-DA   |  C-SA   |  C-TAG  | Length/Type |
 |    a    |    b    |    c    |      d      |
 +---------+---------+---------+-------------+
 a.(Information Element)  destinationMacAddress (80)
 b.(Information Element)  sourceMacAddress (56)
 c.(Information Elements) dot1qVlanId (243), dot1qPriority (244)
 d.(Information Element)  ethernetType (256)
             Figure 1: Customer-Tagged Frame Header Fields
  <-- 6 --> <-- 6 --> <-- 4 --> <-- 4 --> <---- 2 ---->
 +---------+---------+---------+---------+-------------+
 |         |         |         |         |             |
 |  C-DA   |  C-SA   |  S-TAG  |  C-TAG  | Length/Type |
 |    a    |    b    |    c    |    d    |      e      |
 +---------+---------+---------+---------+-------------+
 a.(Information Element)  destinationMacAddress (80)
 b.(Information Element)  sourceMacAddress (56)
 c.(Information Elements) dot1qVlanId (243), dot1qPriority (244)
 d.(Information Elements) dot1qCustomerVlanId (245),
                          dot1qCustomerPriority (246)
 e.(Information Element)  ethernetType (256)
             Figure 2: Service-Tagged Frame Header Fields

Kashima, et al. Standards Track [Page 28] RFC 7133 Data Link Layer Information Elements May 2014

  <-- 6 --> <-- 6 --> <-- 4 --> <--- 16 ---> <-- 4 --> <---- 2 ---->
 +---------+---------+---------+------------+---------+-------------+
 |         |         |         |            |         |             |
 |  B-DA   |  B-SA   |  B-TAG  |   I-TAG    |  C-TAG  | Length/Type |
 |    a    |    b    |    c    |     d      |    e    |      f      |
 +---------+---------+---------+------------+---------+-------------+
 a.(Information Element)  destinationMacAddress (80)
 b.(Information Element)  sourceMacAddress (56)
 c.(Information Elements) dot1qVlanId (243), dot1qPriority (244)
 d.(Information Elements) dot1qServiceInstanceTag (411), or
                          a set of dot1qServiceInstanceId (412),
                          dot1qServiceInstancePriority (413),
                          dot1qCustomerSourceMacAddress (414)
                          dot1qCustomerDestinationMacAddress (415),
 e.(Information Elements) dot1qCustomerVlanId (245),
                          dot1qCustomerPriority (246)
 f.(Information Element)  ethernetType (256)
          Figure 3: Backbone-VLAN-Tagged Frame Header Fields

7. Security Considerations

 Reporting more granular data may increase the risk of DoS attacks
 against a Collector.  Protection against DoS attacks is discussed in
 Section 11.4 of [RFC7011].
 The recommendations in this document do not otherwise introduce any
 additional security issues beyond those already mentioned in
 [RFC7011] and [RFC5477].

8. IANA Considerations

 Existing IPFIX Information Elements [IANA-IPFIX] have been modified
 as indicated in Sections 3.1, 4, and 5.
 Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133]
 has been appended to the Requester in IANA's IPFIX registry
 [IANA-IPFIX], the Information Element's Revision number has been
 incremented by one, and the Information Element's revision Date
 column has been updated.
 New IPFIX Information Elements [IANA-IPFIX] have been allocated as
 shown in Section 3.2.

Kashima, et al. Standards Track [Page 29] RFC 7133 Data Link Layer Information Elements May 2014

9. Acknowledgments

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

10. References

10.1. Normative References

 [IEEE802.11]   IEEE, "IEEE Standard for Information technology.
                Telecommunications and information exchange between
                systems Local and metropolitan area networks.
                Specific requirements Part 11: Wireless LAN Medium
                Access Control (MAC) and Physical Layer (PHY)
                Specifications", IEEE Std 802.11-2012, March 2012.
 [IEEE802.1BR]  IEEE, "IEEE Standard for Local and metropolitan area
                networks: Virtual Bridged Local Area Networks: Bridge
                Port Extension", IEEE Std 802.1BR-2012, July 2012.
 [IEEE802.1Q]   IEEE, "IEEE Standard for Local and metropolitan area
                networks: Media Access Control (MAC) Bridges and
                Virtual Bridged Local Area Networks", IEEE Std
                802.1Q-2011, August 2011.
 [IEEE802.1Qbg] IEEE, "IEEE Standard for Local and metropolitan area
                networks: Media Access Control (MAC) Bridges and
                Virtual Bridged Local Area Networks: Amendment 21:
                Edge Virtual Bridging", IEEE Std 802.1Qbg-2012, July
                2012.
 [IEEE802.3]    IEEE, "IEEE Standard for Ethernet", IEEE Std
                802.3-2012, December 2012.
 [RFC0791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.
 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
                6 (IPv6) Specification", RFC 2460, December 1998.
 [RFC3031]      Rosen, E., Viswanathan, A., and R. Callon,
                "Multiprotocol Label Switching Architecture", RFC
                3031, January 2001.

Kashima, et al. Standards Track [Page 30] RFC 7133 Data Link Layer Information Elements May 2014

 [RFC3032]      Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                Encoding", RFC 3032, January 2001.
 [RFC5477]      Dietz, T., Claise, B., Aitken, P., Dressler, F., and
                G.  Carle, "Information Model for Packet Sampling
                Exports", RFC 5477, March 2009.
 [RFC6313]      Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
                "Export of Structured Data in IP Flow Information
                Export (IPFIX)", RFC 6313, July 2011.
 [RFC7011]      Claise, B., Trammell, B., and P. Aitken,
                "Specification of the IP Flow Information Export
                (IPFIX) Protocol for the Exchange of Flow
                Information", STD 77, RFC 7011, September 2013.

10.2. Informative References

 [IANA-IPFIX]   IANA, "IP Flow Information Export (IPFIX) Entities",
                <http://www.iana.org/assignments/ipfix>.
 [IEEE802.1D]   IEEE, "IEEE Standard for Local and metropolitan area
                networks: Media Access Control (MAC) Bridges", IEEE
                Std 802.1D-2004, June 2004.
 [ISO/IEC.7498-1:1994]
                International Organization for Standardization,
                "Information technology -- Open Systems
                Interconnection -- Basic Reference Model: The Basic
                Mode", ISO Standard 7498-1:1994, June 1996.
 [RFC2804]      IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
                May 2000.
 [RFC7012]      Claise, B. and B. Trammell, "Information Model for IP
                Flow Information Export (IPFIX)", RFC 7012, September
                2013.
 [RFC7013]      Trammell, B. and B. Claise, "Guidelines for Authors
                and Reviewers of IP Flow Information Export (IPFIX)
                Information Elements", BCP 184, RFC 7013, September
                2013.

Kashima, et al. Standards Track [Page 31] RFC 7133 Data Link Layer Information Elements May 2014

Appendix A. Frame Formats

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure A-1: Untagged Frame Format
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        C-TAG TPID=0x8100      |C-PCP|C|         C-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure A-2: C-TAG Tagging Frame Format

Kashima, et al. Standards Track [Page 32] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        S-TAG TPID=0x88a8      |S-PCP|D|         S-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure A-3: S-TAG Tagging Frame Format in Provider Bridged Networks
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        S-TAG TPID=0x88a8      |S-PCP|D|         S-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        C-TAG TPID=0x8100      |C-PCP|C|         C-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure A-4: S-TAG and C-TAG Tagging Frame Format in Provider Bridged
                               Networks

Kashima, et al. Standards Track [Page 33] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              B-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              B-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        B-TAG TPID=0x88a8      |B-PCP|D|         B-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        I-TAG TPID=0x88e7      |I-PCP|D|U| Res |     I-SID     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             I-SID             |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-DA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-SA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |          Length/Type          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure A-5: B-TAG and I-TAG Tagging Frame Format in Provider Backbone
                           Bridged Networks

Kashima, et al. Standards Track [Page 34] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              B-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              B-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        B-TAG TPID=0x88a8      |B-PCP|D|         B-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        I-TAG TPID=0x88e7      |I-PCP|D|U| Res |     I-SID     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             I-SID             |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-DA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-SA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |        C-TAG TCI=0x8100       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |C-PCP|C|         C-VID         |          Length/Type          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure A-6: B-TAG, I-TAG, and C-TAG Tagging Frame Format in Provider
                       Backbone Bridged Networks

Kashima, et al. Standards Track [Page 35] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        S-TAG TPID=0x88a8      |S-PCP|D|         S-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure A-7: S-TAG Tagging Frame Format for S-channel over the Link
            between an End Station and Its Adjacent Bridge
 Note: The frame format in Figure A-7 is identical to the format in
 Figure A-3.

Kashima, et al. Standards Track [Page 36] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        S-TAG TPID=0x88a8      |S-PCP|D|         S-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        C-TAG TPID=0x8100      |C-PCP|C|         C-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure A-8: S-TAG and C-TAG Tagging Frame Format over the Link
            between an End Station and Its Adjacent Bridge
 Note: The frame format in Figure A-8 is identical to the format in
 Figure A-4.

Kashima, et al. Standards Track [Page 37] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        E-TAG TPID=0x893F      |E-PCP|D|   Ingress_E-CID_base  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Res|GRP|      E-CID_base       |Ingre_E-CID_ext|    E-CID_ext  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure A-9: E-TAG Tagging Frame Format over the Link between a
             Controlling Bridge and a Bridge Port Extender

Kashima, et al. Standards Track [Page 38] RFC 7133 Data Link Layer Information Elements May 2014

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              C-DA                             |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                              C-SA                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        E-TAG TPID=0x893F      |E-PCP|D|   Ingress_E-CID_base  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Res|GRP|      E-CID_base       |Ingre_E-CID_ext|    E-CID_ext  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        C-TAG TPID=0x8100      |C-PCP|C|         C-VID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Length/Type          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Customer Data                         ~
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure A-10: E-TAG and C-TAG Tagging Frame Format over the Link
        between a Controlling Bridge and a Bridge Port Extender

Kashima, et al. Standards Track [Page 39] RFC 7133 Data Link Layer Information Elements May 2014

Appendix B. Template Format Example

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Set ID (2)             |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Template ID (256)        |     Field Count (8)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   ingressInterface (10)       |     Field Length (4)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   egressInterface (14)        |     Field Length (4)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | observationTimeSeconds (322)  |     Field Length (8)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   dataLinkFrameSize (312)     |     Field Length (2)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | dataLinkFrameSection (315)    |     Field Length (65535)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   dataLinkFrameType (408)     |     Field Length (2)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     sectionOffset (409)       |     Field Length (2)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | sectionExportedOctets (410)   |     Field Length (2)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure B-1: Template Format Example

Kashima, et al. Standards Track [Page 40] RFC 7133 Data Link Layer Information Elements May 2014

Authors' Addresses

 Shingo Kashima
 Nippon Telegraph and Telephone Corporation
 1-5-1 Otemachi
 Chiyoda-ku, Tokyo  100-8116
 Japan
 Phone: +81 3 6838 5267
 EMail: kashima@nttv6.net
 Atsushi Kobayashi
 Nippon Telegraph and Telephone East Corporation
 3-19-2 Nishi-shinjuku
 Shinjuku-ku, Tokyo  163-8019
 Japan
 Phone: +81 3 5359 4351
 EMail: akoba@nttv6.net
 Paul Aitken
 Cisco Systems, Inc.
 96 Commercial Quay
 Commercial Street, Edinburgh  EH6 6LX
 United Kingdom
 Phone: +44 131 561 3616
 EMail: paitken@cisco.com

Kashima, et al. Standards Track [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7133.txt · Last modified: 2014/05/22 01:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki