[要約] RFC 7133は、データリンク層トラフィックの測定に使用される情報要素についての標準化を提案しています。このRFCの目的は、ネットワーク管理者がデータリンク層のトラフィックを効果的に監視し、問題を特定するための共通の情報要素を提供することです。
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.
このドキュメントでは、データリンク層に関連する情報要素について説明します。これらは、測定されたデータリンク層のトラフィック情報をエンコードするために、IPフロー情報エクスポート（IPFIX）プロトコルで使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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
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.
イーサネット[IEEE802.1D]およびVLAN（仮想LAN）テクノロジは、ローカルエリアネットワークでのみ使用されていました。最近、それらは広域ネットワーク、例えば、レイヤー2 VPN（L2 VPN）サービスで使用されています。したがって、VLANテクノロジーを使用するキャリアネットワークは、プロバイダーブリッジネットワークとプロバイダーバックボーンブリッジネットワークに拡張されています[IEEE802.1Q]。さらに、データセンターのイーサネットもサーバーの仮想化と入力/出力（I / O）統合のために強化されています。
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.
IPFIXとパケットサンプリング（PSAMP）は、これらの問題の解決に役立ちます。ただし、PSAMP情報モデル[RFC5477]およびIPFIX情報モデル[RFC7011]には、イーサネットヘッダーフォームなど、データリンク層に関連する十分な情報要素がまだ含まれていません。このドキュメントでは、より高度なトラフィック測定方法を可能にするデータリンク層に関連する既存および新しい情報要素について説明します。
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].
[RFC7012]のセクション1によると、IANAのIPFIXレジストリ[IANA-IPFIX]は最終的な情報要素参照であるため、このドキュメントは[RFC5477]または[RFC7011]を更新しないことに注意してください。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Provider Bridge and Provider Backbone Bridge [IEEE802.1Q], which are standards for Wide-Area Ethernet, are described below.
ワイドエリアイーサネットの標準であるプロバイダーブリッジおよびプロバイダーバックボーンブリッジ[IEEE802.1Q]について、以下に説明します。
o In Provider Bridge [IEEE802.1Q], there are two VLAN IDs: Service VLAN Identifier (S-VID) and Customer VLAN Identifier (C-VID). S-VID is assigned to an Ethernet frame by a service provider, while C-VID is independently assigned to an Ethernet frame by a customer. Frame switching in a service provider network is based on only S-VID.
o プロバイダーブリッジ[IEEE802.1Q]には、サービスVLAN識別子（S-VID）とカスタマーVLAN識別子（C-VID）の2つのVLAN IDがあります。 S-VIDはサービスプロバイダーによってイーサネットフレームに割り当てられますが、C-VIDはお客様によってイーサネットフレームに個別に割り当てられます。サービスプロバイダーネットワークでのフレームスイッチングは、S-VIDのみに基づいています。
o In Provider Backbone Bridge [IEEE802.1Q], new Ethernet fields, such as Backbone VLAN Identifier (B-VID) and Backbone Service Instance Identifier (I-SID), are introduced to overcome the limitations on the VLAN identifier space and to isolate the service provider and customer identifier spaces. Frame switching is based on a 12-bit B-VID, and customer identification is based on a 24-bit I-SID. A flexible network design has become possible because network management is separated from customer management. Other Ethernet fields that indicate quality of service (QoS) class are Backbone VLAN Priority Code Point (B-PCP), Backbone VLAN Drop Eligible Indicator (B-DEI), Backbone Service Instance Priority Code Point (I-PCP), and Backbone Service Instance Drop Eligible Indicator (I-DEI).
o プロバイダーバックボーンブリッジ[IEEE802.1Q]では、バックボーンVLAN ID（B-VID）やバックボーンサービスインスタンスID（I-SID）などの新しいイーサネットフィールドが導入され、VLAN IDスペースの制限を克服し、サービスプロバイダーおよび顧客IDスペース。フレームスイッチングは12ビットのB-VIDに基づいており、顧客の識別は24ビットのI-SIDに基づいています。ネットワーク管理と顧客管理を分離したことで、柔軟なネットワーク設計が可能になりました。サービス品質（QoS）クラスを示す他のイーサネットフィールドは、バックボーンVLAN優先コードポイント（B-PCP）、バックボーンVLANドロップ適格インジケーター（B-DEI）、バックボーンサービスインスタンス優先コードポイント（I-PCP）、およびバックボーンサービスです。インスタンスドロップ適格インジケーター（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.
ワイドエリアイーサネットで使用されるフレームフォーマットを付録Aに示します。
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.
データセンターの既存の仮想スイッチ環境にはいくつかの課題がありました。 1つは、ネットワーク管理の可視性の欠如です。仮想スイッチの制限された機能により、仮想マシン（VM）間のトラフィックを監視することが困難になります。もう1つは、管理のスケーラビリティと柔軟性の欠如です。マルチテナントアーキテクチャのVMの数を増やすと、仮想スイッチの数とトラフィック制御ポリシーの数が増え、ネットワーク管理のスケーラビリティと柔軟性の限界に達します。
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.
この状況では、IEEE 802.1ワーキンググループは、仮想エッジブリッジ（VEB）と仮想エッジポートアグリゲーター（VEPA）[IEEE802.1Qbg]の2種類のエッジリレーを含む、エッジ仮想ブリッジング（EVB）などの仮想ブリッジングテクノロジーを標準化しています。 VEBは、複数のVMと外部ブリッジング環境間のブリッジングを提供するブリッジです。 VEPAは、すべての内部トラフィックを隣接するEVBブリッジに転送し、隣接するEVBブリッジから受信したトラフィックをVMに配信する、ホスト上のブリッジのようなデバイスです。 VEPAは、すべてのVM-to-VMトラフィックをEVBブリッジから見えるようにして、トラフィックを監視し、EVBブリッジがトラフィックにフィルタリングを適用できるようにします。
To improve flexibility, a virtual link between a host system and EVB bridge is standardized as S-channel. S-channel allows a bridge to treat the traffic in the virtual link as if it comes in on a separate port. For example, in the host, an S-channel may be attached to a VEB or a VEPA or directly 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.
柔軟性を向上させるために、ホストシステムとEVBブリッジ間の仮想リンクはSチャネルとして標準化されています。 Sチャネルを使用すると、ブリッジは仮想リンクのトラフィックを別のポートに着信したかのように処理できます。たとえば、ホストでは、各ポートベースのフィルタリングルールをトラフィックに適用するために、VEBまたはVEPAに、または直接内部ポートにSチャネルを接続できます。ホストとその隣接ブリッジ間のリンク上のSチャネルは、サービスVLANタグ（S-TAG）[IEEE802.1Q]を使用します。 Sチャネルが使用中の場合、リンク上のフレームはSチャネルを識別するS-TAGを伝送します。
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].
一方、Bridge Port Extensionは、複数の物理スイッチおよび仮想スイッチからの単一の拡張ブリッジをエミュレートし、ネットワーク管理も簡素化します。また、Eチャネルを使用してすべてのトラフィックを中央の制御ブリッジに転送することにより、ネットワーク管理の可視性の欠如を解決します。 Bridge Port ExtenderとControlling Bridge間のリンク上のEチャネルは、[IEEE802.1BR]で定義されたE-TAGを使用します。
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.
VM間のトラフィックの可視性と仮想リンク上の各チャネルのトラフィックの可視性を取得するには、SチャネルとEチャネル上のトラフィック監視が必要です。
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.
Eチャネルで使用されるE-TAGおよびSチャネルで使用されるS-TAGを使用したフレームフォーマットは、付録Aに示されています。これらのフレームはリンク上に特別なタグを持っていますが、これらのタグは仮想ポート（またはダウンストリームでのマルチキャスト用）を識別します方向、仮想ポートのセット）宛先。これらのタグ値はローカルの意味のみを持ち、フローは送信され、対応する仮想ポートに到着すると報告されます。したがって、IPFIXはこれらのタグに基づいてデータを監視する必要はありません。
3. Modification and Addition of Information Elements Related to Data Link Layer
3. データリンク層に関連する情報要素の変更と追加
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.
表1の上部にリストされている情報要素は、データリンク層のIPFIXおよびPSAMPトラフィック測定を有効にするために必要です。この方法は他のデータリンクプロトコルにも適用できるため、イーサネットに限定されません。
Information Elements in the middle section of Table 1 are necessary for enabling the IPFIX and PSAMP traffic measurement for [IEEE802.1Q].
[IEEE802.1Q]のIPFIXおよびPSAMPトラフィック測定を有効にするには、表1の中央セクションの情報要素が必要です。
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.
表1の下のセクションの情報要素は、レイヤー2のオクテットカウンターまたはパケット長であり、データリンクレイヤーのIPFIXおよびPSAMPトラフィック測定を有効にするために必要です。
+-----+------------------------------------+
| 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
表1：データリンク層に関連する情報要素
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 *.
データリンク層のエクスポートには、いくつかの既存の情報要素が必要です。それらの詳細は、IANAのIPFIXレジストリ[IANA-IPFIX]からここに再現されています。このドキュメントごとの追加は*の間に表示されます。
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].
セクション3.1.1では、dataLinkFrameSize情報要素に欠落しているデータ型セマンティクスが導入されています。これは、[RFC7013]のセクション5.2の＃4による相互運用可能な変更であるとされています。
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].
セクション3.1.2は、dataLinkFrameSection情報要素の定義を、新しいsectionOffset情報要素を参照して拡張します。これは、[RFC7013]のセクション5.2の＃4による相互運用可能な変更でもあります。
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.
layer2OctetDeltaCount情報要素は、このフローの着信パケットの前回のレポート以降のレイヤー2オクテットの数を報告し、layer2OctetTotalCount情報要素は、このフローの着信パケットのレイヤー2オクテットの総数を報告します。 layer2FrameDeltaCount情報要素は、このフローの前回のレポート以降の着信レイヤー2フレームの数を報告し、layer2FrameTotalCount情報要素は、このフローの着信レイヤー2フレームの総数を報告します。これらの情報要素はすべて、既存のIANA [IANA-IPFIX]定義から変更されていません。完全を期すために、以下のセクション3.1.3からセクション3.1.6に複製されています。
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.
[RFC7013]のセクション5.2に従い、これらの変更ごとに、[RFC7133]がIANAのIPFIXレジストリ[IANA-IPFIX]のリクエスタに追加され、情報要素のリビジョン番号が1つ増え、情報要素のリビジョン日列を更新しました。
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].
データリンク層は、[ISO / IEC.7498-1：1994]で定義されています。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
*Data Type Semantics: quantity*
ElementId: 312
ElementId：312
References: [ISO/IEC.7498-1:1994]
Status: current
ステータス：現在
Description:
説明：
This Information Element carries n octets from the data link frame of a selected frame, starting sectionOffset octets into the frame.
この情報要素は、選択されたフレームのデータリンクフレームからnオクテットを伝送し、フレームへのsectionOffsetオクテットを開始します。
*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.*
*ただし、この情報要素に対応するsectionOffsetフィールドが存在しない場合は、sectionOffsetがゼロになり、オクテットはデータリンクフレームの先頭からである必要があります。*
The sectionExportedOctets expresses how much data was observed, while the remainder is padding.
sectionExportedOctetsは観測されたデータ量を表し、残りはパディングされます。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在する場合、この情報要素は固定長であり、パディングすることができます（MAY）、または可変長にすることができます（MAY）。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在しない場合、この情報要素は可変長である必要があり、パディングしてはなりません。この場合、IPFIXプロトコルの制限により、エクスポートされるセクションのサイズが制限される可能性があります。
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].
この情報要素のデータリンクタイプとデータリンクフレームのサイズを指定するには、dataLinkFrameTypeとdataLinkFrameSizeなどの追加情報要素が必要です。これらの情報要素のセットは、[RFC6313]で表現されているように、構造化データタイプに含まれる場合があります。または、[RFC7133]の付録Bに示すように、これらの情報要素のセットを1つのフローレコードに含めることができます。
The data link layer is defined in [ISO/IEC.7498-1:1994].
データリンク層は、[ISO / IEC.7498-1：1994]で定義されています。
Abstract Data Type: octetArray
抽象データ型：octetArray
ElementId: 315
ElementId：315
References: [RFC6313] [RFC7133] [ISO/IEC.7498-1:1994]
Status: current
ステータス：現在
The layer2OctetDeltaCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
layer2OctetDeltaCount情報要素は、既存のIANA [IANA-IPFIX]定義から変更されておらず、参照用としてここに複製されています。
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.
観測ポイントでのこのフローの着信パケットの前回のレポート（存在する場合）からのレイヤー2オクテットの数。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: deltaCounter
データ型のセマンティクス：deltaCounter
Units: octets
単位：オクテット
ElementId: 352
ElementId：352
Status: current
ステータス：現在
The layer2OctetTotalCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
layer2OctetTotalCount情報要素は、既存のIANA [IANA-IPFIX]定義から変更されておらず、参照用としてここに複製されています。
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.
この観測ポイントの計測プロセス（再）初期化以降の、観測ポイントでのこのフローの着信パケット内のレイヤー2オクテットの総数。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
Units: octets
単位：オクテット
ElementId: 353
ElementId：353
Status: current
ステータス：現在
The layer2FrameDeltaCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
layer2FrameDeltaCount情報要素は、既存のIANA [IANA-IPFIX]定義から変更されておらず、参照用としてここに複製されています。
Description:
説明：
The number of incoming layer 2 frames since the previous report (if any) for this Flow at the Observation Point.
観測ポイントでのこのフローの前回のレポート（存在する場合）からの着信レイヤー2フレームの数。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: deltaCounter
データ型のセマンティクス：deltaCounter
Units: frames
単位：フレーム
ElementId: 430
ElementId：430
Status: current
ステータス：現在
The layer2FrameTotalCount Information Element is unchanged from the existing IANA [IANA-IPFIX] definition and is reproduced here for reference only.
layer2FrameTotalCount情報要素は、既存のIANA [IANA-IPFIX]定義から変更されておらず、参照用としてここに複製されています。
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.
この観測ポイントのメータリングプロセス（再）初期化以降の、観測ポイントでのこのフローの着信レイヤー2フレームの総数。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
Units: frames
単位：フレーム
ElementId: 431
ElementId：431
Status: current
ステータス：現在
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 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".
IANAのIPFIXレジストリ[IANA-IPFIX]で、リクエスタは[RFC7133]に設定され、情報要素のリビジョンはゼロに設定され、情報要素の日付は新しい情報要素が追加された日付に設定されていますレジストリ。以下で明示的に言及されていない他のすべての列（Units、Range、Referencesなど）は適用されず、レジストリには「適用されない」と明示的に記録されていないため、空白のままにします。
Description:
説明：
This Information Element specifies the type of the selected data link frame.
この情報要素は、選択されたデータリンクフレームのタイプを指定します。
The following data link types are defined here:
ここでは、次のデータリンクタイプが定義されています。
- 0x01 IEEE802.3 ETHERNET [IEEE802.3]
- 0x01 IEEE802.3 ETHERNET [IEEE802.3]
- 0x02 IEEE802.11 MAC Frame format [IEEE802.11]
- 0x02 IEEE802.11 MACフレーム形式[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.
IANAによってさらに値が割り当てられる場合があります。割り当てられた値はビットであるため、複数の観測値のORをとることができます。
The data link layer is defined in [ISO/IEC.7498-1:1994].
データリンク層は、[ISO / IEC.7498-1：1994]で定義されています。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
Data Type Semantics: flags
データ型セマンティクス：フラグ
ElementId: 408
ElementId：408
References: [IEEE802.3] [IEEE802.11] [ISO/IEC.7498-1:1994]
Status: current
ステータス：現在
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).
この情報要素は、パケットセクションのオフセットを指定します（たとえば、dataLinkFrameSection、ipHeaderPacketSection、ipPayloadPacketSection、mplsLabelStackSection、およびmplsPayloadPacketSection）。この情報要素を省略すると、デフォルトでゼロになります（つまり、オフセットなし）。
If multiple sectionOffset Information Elements are specified within a single Template, then they apply to the packet section Information Elements in order: the first sectionOffset applies to the first packet section, the second to the second, and so on. Note that the "closest" sectionOffset and packet section Information Elements within a given Template are not necessarily related. If there are fewer sectionOffset Information Elements than packet section Information Elements, then subsequent packet section Information Elements have no offset, i.e., a sectionOffset of zero applies to those packet section Information Elements. If there are more sectionOffset Information Elements than the number of packet section Information Elements, then the additional sectionOffset Information Elements are meaningless.
1つのテンプレート内で複数のsectionOffset情報要素が指定されている場合、それらは順番にパケットセクション情報要素に適用されます。最初のsectionOffsetは最初のパケットセクションに、2番目は2番目にというように続きます。特定のテンプレート内の「最も近い」sectionOffsetおよびパケットセクション情報要素は、必ずしも関連しているわけではないことに注意してください。パケットセクション情報要素よりもsectionOffset情報要素が少ない場合、後続のパケットセクション情報要素にはオフセットがありません。つまり、ゼロのsectionOffsetがそれらのパケットセクション情報要素に適用されます。パケットセクション情報要素の数よりも多くのsectionOffset情報要素がある場合、追加のsectionOffset情報要素は無意味です。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
Data Type Semantics: quantity
データ型セマンティクス：数量
ElementId: 409
ElementId：409
Status: current
ステータス：現在
Description:
説明：
This Information Element specifies the observed length of the packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, and mplsPayloadPacketSection) when padding is used.
この情報要素は、パディングが使用される場合に、パケットセクションの観測された長さ（たとえば、dataLinkFrameSection、ipHeaderPacketSection、ipPayloadPacketSection、mplsLabelStackSection、およびmplsPayloadPacketSection）を指定します。
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).
パケットセクションは、sectionExportedOctetsよりも大きい固定サイズである場合があります。この場合、sectionExportedOctetsを超えたパケットセクションのオクテットは、パディングに関する[RFC7011]ルールに従う必要があります（つまり、ゼロ（0）の値のオクテットで構成されている必要があります）。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
Data Type Semantics: quantity
データ型セマンティクス：数量
ElementId: 410
ElementId：410
References: [RFC7011]
参照：[RFC7011]
Status: current
ステータス：現在
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
この情報要素は16オクテットであり、[IEEE802.1Q]で説明されているように、イーサネットフレームのバックボーンサービスインスタンスタグ（I-TAG）タグ制御情報（TCI）フィールドを表します。それ
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].
バックボーンサービスインスタンスプライオリティコードポイント（I-PCP）、バックボーンサービスインスタンスドロップ適格インジケーター（I-DEI）、カスタマーアドレスの使用（UCA）、バックボーンサービスインスタンス識別子（I-SID）、カプセル化されたカスタマー宛先アドレス（C- DA）、カプセル化顧客ソースアドレス（C-SA）、および予約済みフィールド。タグ制御情報フィールド内の構造とセマンティクスは、[IEEE802.1Q]で定義されています。
Abstract Data Type: octetArray
抽象データ型：octetArray
Data Type Semantics: default
データ型セマンティクス：デフォルト
ElementId: 411
ElementId：411
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
Status: current
ステータス：現在
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].
[IEEE802.1Q]で説明されているイーサネットフレームのバックボーンサービスインスタンスタグ（I-TAG）タグ制御情報（TCI）フィールドの24ビットバックボーンサービスインスタンス識別子（I-SID）部分の値。
Abstract Data Type: unsigned32
抽象データ型：unsigned32
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 412
ElementId：412
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
Status: current
ステータス：現在
Range: The valid range is 0 - 16777215 (i.e., 24 bits).
範囲：有効な範囲は0-16777215（つまり、24ビット）です。
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].
[IEEE802.1Q]で説明されているイーサネットフレームのバックボーンサービスインスタンスタグ（I-TAG）タグ制御情報（TCI）フィールドの3ビットバックボーンサービスインスタンス優先コードポイント（I-PCP）部分の値。
Abstract Data Type: unsigned8
抽象データ型：unsigned8
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 413
ElementId：413
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
Status: current
ステータス：現在
Range: The valid range is 0-7.
範囲：有効な範囲は0〜7です。
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].
[IEEE802.1Q]で説明されているイーサネットフレームのバックボーンサービスインスタンスタグ（I-TAG）タグ制御情報（TCI）フィールドのカプセル化カスタマーソースアドレス（C-SA）部分の値。
Abstract Data Type: macAddress
抽象データ型：macAddress
Data Type Semantics: default
データ型セマンティクス：デフォルト
ElementId: 414
ElementId：414
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
Status: current
ステータス：現在
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].
[IEEE802.1Q]で説明されているイーサネットフレームのバックボーンサービスインスタンスタグ（I-TAG）タグ制御情報（TCI）フィールドのカプセル化された顧客宛先アドレス（C-DA）部分の値。
Abstract Data Type: macAddress
抽象データ型：macAddress
Data Type Semantics: default
データ型セマンティクス：デフォルト
ElementId: 415 References: [IEEE802.1Q]
ElementId：415参照：[IEEE802.1Q]
Status: current
ステータス：現在
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.
この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、layer2OctetDeltaCount情報要素の定義と同じです。
This Information Element is the layer 2 version of postOctetDeltaCount (ElementId #23).
この情報要素は、postOctetDeltaCount（ElementId＃23）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: deltaCounter
データ型のセマンティクス：deltaCounter
ElementId: 417
ElementId：417
References: [RFC5477]
参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
監視ドメイン内のマルチキャストデーモンによってこのフローのパケットに対して送信された発信マルチキャストパケットの前回のレポート（存在する場合）以降のレイヤー2オクテットの数。このプロパティは、必ずしも観測ポイントで観測できるとは限りませんが、他の方法で取得できます。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
This Information Element is the layer 2 version of postMCastOctetDeltaCount (ElementId #20).
この情報要素は、postMCastOctetDeltaCount（ElementId＃20）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: deltaCounter
データ型のセマンティクス：deltaCounter
ElementId: 418 References: [RFC5477]
ElementId：418参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる可能性のある変更された値を報告することを除いて、layer2OctetTotalCount情報要素の定義と同じです。
This Information Element is the layer 2 version of postOctetTotalCount (ElementId #171).
この情報要素は、postOctetTotalCount（ElementId＃171）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
ElementId: 420
ElementId：420
References: [RFC5477]
参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
メータリングプロセス（再）初期化以降に、観測ドメインのマルチキャストデーモンによってこのフローのパケット用に送信された発信マルチキャストパケットのレイヤ2オクテットの総数。このプロパティは、必ずしも観測ポイントで観測できるとは限りませんが、他の方法で取得できます。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
This Information Element is the layer 2 version of postMCastOctetTotalCount (ElementId #175).
この情報要素は、postMCastOctetTotalCount（ElementId＃175）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter ElementId: 421
データ型のセマンティクス：totalCounter ElementId：421
References: [RFC5477]
参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
このフローで観測された最小パケットのレイヤー2の長さ。パケット長には、レイヤー2ヘッダーの長さとレイヤー2ペイロードの長さが含まれます。
This Information Element is the layer 2 version of minimumIpTotalLength (ElementId #25).
この情報要素は、minimumIpTotalLength（ElementId＃25）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
ElementId: 422
ElementId：422
References: [RFC5477]
参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
このフローで観測された最大パケットのレイヤー2の長さ。パケット長には、レイヤー2ヘッダーの長さとレイヤー2ペイロードの長さが含まれます。
This Information Element is the layer 2 version of maximumIpTotalLength (ElementId #26).
この情報要素は、maximumIpTotalLength（ElementId＃26）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
ElementId: 423
ElementId：423
References: [RFC5477] Status: current
参照：[RFC5477]ステータス：現在
Units: octets
単位：オクテット
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.
パケット処理によってドロップされた、このフローのパケットの前回のレポート（存在する場合）以降のレイヤー2オクテットの数。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
This Information Element is the layer 2 version of droppedOctetDeltaCount (ElementId #132).
この情報要素は、droppedOctetDeltaCount（ElementId＃132）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: deltaCounter
データ型のセマンティクス：deltaCounter
ElementId: 424
ElementId：424
References: [RFC5477]
参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
メータリングプロセスの（再）初期化以降にパケット処理によってドロップされた、監視対象のレイヤー2パケット（レイヤー2ヘッダーを含む）のオクテットの総数。
This Information Element is the layer 2 version of droppedOctetTotalCount (ElementId #134).
この情報要素は、droppedOctetTotalCount（ElementId＃134）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
ElementId: 425
ElementId：425
References: [RFC5477] Status: current
参照：[RFC5477]ステータス：現在
Units: octets
単位：オクテット
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.
メータリングプロセスの（再）初期化以降にメータリングプロセスが処理しなかった、観測されたレイヤ2パケット（レイヤ2ヘッダーを含む）のオクテットの総数。
This Information Element is the layer 2 version of ignoredOctetTotalCount (ElementId #165).
この情報要素は、ignoredOctetTotalCount（ElementId＃165）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
ElementId: 426
ElementId：426
References: [RFC5477]
参照：[RFC5477]
Status: current
Status: current
Units: octets
単位：オクテット
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.
メータリングプロセスの（再）初期化以降にメータリングプロセスが処理しなかった、観測されたレイヤ2パケット（レイヤ2ヘッダーを含む）のオクテットの総数。
This Information Element is the layer 2 version of notSentOctetTotalCount (ElementId #168).
この情報要素は、notSentOctetTotalCount（ElementId＃168）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
ElementId: 427
ElementId：427
References: [RFC5477] Status: current
参照：[RFC5477]ステータス：現在
Units: octets
単位：オクテット
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.
観測ポイントでのこのフローの前回のレポート（存在する場合）以降の、着信パケットごとのレイヤー2オクテットの2乗数の合計。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
This Information Element is the layer 2 version of octetDeltaSumOfSquares (ElementId #198).
この情報要素は、octetDeltaSumOfSquaresのレイヤー2バージョンです（ElementId＃198）。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: deltaCounter
データ型のセマンティクス：deltaCounter
ElementId: 428
ElementId：428
References: [RFC5477]
参照：[RFC5477]
Status: current
ステータス：現在
Units: octets
単位：オクテット
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.
この観測ポイントの計量プロセス（再）初期化以降の、観測ポイントでのこのフローの着信パケット内のレイヤー2オクテットの2乗数の合計。オクテットの数には、レイヤー2ヘッダーとレイヤー2ペイロードが含まれます。
This Information Element is the layer 2 version of octetTotalSumOfSquares (ElementId #199).
この情報要素は、octetTotalSumOfSquares（ElementId＃199）のレイヤー2バージョンです。
Abstract Data Type: unsigned64
抽象データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
ElementId: 429
ElementId：429
References: [RFC5477] Status: current
参照：[RFC5477]ステータス：現在
Units: octets
単位：オクテット
4. Modification of Existing Information Elements Related to Packet Section
4. パケットセクションに関連する既存の情報要素の変更
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.
パケットセクションに関連する新しい情報要素（つまり、sectionOffsetおよびsectionExportedOctets）は、dataLinkFrameSectionだけでなく、すべての種類のパケットセクション（つまり、[RFC5477]で定義されているipHeaderPacketSection、ipPayloadPacketSection、mplsLabelStackSection、およびmplsPayloadPacketSection）にも適用できます。したがって、既存の情報要素の説明は、次のように変更する必要があります。
This Information Element is defined in [RFC5477]. The description has been updated from [RFC5477].
この情報要素は[RFC5477]で定義されています。 [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.
この情報要素は、サンプリングされたパケットのIPヘッダーから一連のnオクテットを運び、sectionOffsetオクテットをIPヘッダーに開始します。
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.
ただし、この情報要素に対応するsectionOffsetフィールドが存在しない場合は、sectionOffsetがゼロになり、オクテットはIPヘッダーの先頭からである必要があります。
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].
十分な長さのこの要素は、IPペイロードからのオクテットも報告します。ただし、任意のパケットストリームの完全なパケットキャプチャは、[RFC5477]と[RFC2804]のセキュリティに関する考慮事項のセクションでは明らかに範囲外です。
The sectionExportedOctets expresses how much data was exported, while the remainder is padding.
セクションExportedOctetsは、エクスポートされたデータ量を表し、残りはパディングされます。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在する場合、この情報要素は固定長であり、パディングすることができます（MAY）、または可変長にすることができます（MAY）。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在しない場合、この情報要素は可変長である必要があり、パディングしてはなりません。この場合、IPFIXプロトコルの制限により、エクスポートされるセクションのサイズが制限される可能性があります。
Abstract Data Type: octetArray
抽象データ型：octetArray
ElementId: 313
ElementId: 313
References: [RFC2804] [RFC5477]
参照：[RFC2804] [RFC5477]
Status: current
ステータス：現在
This Information Element is defined in [RFC5477]. The description is updated from [RFC5477].
この情報要素は[RFC5477]で定義されています。 [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.
この情報要素は、サンプリングされたパケットのIPペイロードから一連のnオクテットを運び、sectionOffsetオクテットをIPペイロードに開始します。
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.
ただし、この情報要素に対応するsectionOffsetフィールドが存在しない場合は、sectionOffsetがゼロになり、オクテットはIPペイロードの先頭からである必要があります。
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.
IPv4ペイロードは、IPv4ヘッダーとオプションに続くパケットの一部であり、[RFC0791]は「データ」または「データオクテット」と呼んでいます。たとえば、[RFC0791]、付録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.
IPv6ペイロードは、40オクテットIPv6ヘッダーに続くパケットの残りの部分です。存在する拡張ヘッダーはペイロードの一部と見なされることに注意してください。 IPv6仕様については、[RFC2460]を参照してください。
The sectionExportedOctets expresses how much data was observed, while the remainder is padding.
sectionExportedOctetsは観測されたデータ量を表し、残りはパディングされます。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在する場合、この情報要素は固定長であり、パディングすることができます（MAY）、または可変長にすることができます（MAY）。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在しない場合、この情報要素は可変長である必要があり、パディングしてはなりません。この場合、IPFIXプロトコルの制限により、エクスポートされるセクションのサイズが制限される可能性があります。
Abstract Data Type: octetArray
抽象データ型：octetArray
ElementId: 314
ElementId: 314
References: [RFC0791] [RFC2460]
参照：[RFC0791] [RFC2460]
Status: current
Status: current
This Information Element is defined in [RFC5477]. The description is updated from [RFC5477].
この情報要素は[RFC5477]で定義されています。 [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.
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.
ただし、この情報要素に対応するsectionOffsetフィールドが存在しない場合は、sectionOffsetがゼロになり、オクテットはMPLSラベルスタックの先頭からのものでなければなりません。
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].
十分な長さのこの要素は、MPLSペイロードからのオクテットも報告します。ただし、任意のパケットストリームの完全なパケットキャプチャは、[RFC5477]と[RFC2804]のセキュリティに関する考慮事項のセクションでは明らかに範囲外です。
See [RFC3031] for the specification of MPLS packets.
MPLSパケットの仕様については、[RFC3031]を参照してください。
See [RFC3032] for the specification of the MPLS label stack.
MPLSラベルスタックの仕様については、[RFC3032]を参照してください。
The sectionExportedOctets expresses how much data was observed, while the remainder is padding.
sectionExportedOctetsは観測されたデータ量を表し、残りはパディングされます。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在する場合、この情報要素は固定長であり、パディングすることができます（MAY）、または可変長にすることができます（MAY）。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在しない場合、この情報要素は可変長である必要があり、パディングしてはなりません。この場合、IPFIXプロトコルの制限により、エクスポートされるセクションのサイズが制限される可能性があります。
Abstract Data Type: octetArray
Abstract Data Type: octetArray
ElementId: 316
ElementId: 316
References: [RFC2804] [RFC3031] [RFC3032] [RFC5477]
参照：[RFC2804] [RFC3031] [RFC3032] [RFC5477]
Status: current
ステータス：現在
This Information Element is defined in [RFC5477]. The description is updated from [RFC5477].
この情報要素は[RFC5477]で定義されています。 [RFC5477]から更新されました。
Description:
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.
mplsPayloadPacketSectionは、サンプリングされたパケットのMPLSペイロードから一連のnオクテットを運び、sectionOffsetオクテットを開始してMPLSペイロードに入れます。これは、MPLSラベルスタックの直後に続くデータだからです。
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.
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.
MPLSパケットの仕様については、[RFC3031]を参照してください。
See [RFC3032] for the specification of the MPLS label stack.
See [RFC3032] for the specification of the MPLS label stack.
The sectionExportedOctets expresses how much data was observed, while the remainder is padding.
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在する場合、この情報要素は固定長であり、パディングすることができます（MAY）、または可変長にすることができます（MAY）。
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.
この情報要素に対応するsectionExportedOctetsフィールドが存在しない場合、この情報要素は可変長である必要があり、パディングしてはなりません。この場合、IPFIXプロトコルの制限により、エクスポートされるセクションのサイズが制限される可能性があります。
Abstract Data Type: octetArray
Abstract Data Type: octetArray
ElementId: 317 References: [RFC3031] [RFC3032]
ElementId：317参照：[RFC3031] [RFC3032]
Status: current
Status: current
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.
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.
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].
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.
マルチタグフレームの場合、I-TAGを除いて、外部タグのVLAN識別子を表します。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
Data Type Semantics: identifier
Data Type Semantics: identifier
ElementId: 243
ElementId: 243
Status: current
Status: current
References: [IEEE802.1Q] [IEEE802.1Qbg]
参照：[IEEE802.1Q] [IEEE802.1Qbg]
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.
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
抽象データ型：unsigned8
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 244
ElementId：244
Status: current
Status: current
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
Description:
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].
[IEEE802.1Q]で説明されているように、値はカスタマーVLANタグ（C-TAG）タグ制御情報（TCI）フィールドのカスタマーVLAN識別子を表します。
Abstract Data Type: unsigned16
抽象データ型：unsigned16
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 245
ElementId：245
Status: current
ステータス：現在
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
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].
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].
Abstract Data Type: unsigned8
抽象データ型：unsigned8
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 246
ElementId：246
Status: current
ステータス：現在
References: [IEEE802.1Q]
参照：[IEEE802.1Q]
6. The Relationship between Ethernet Header Fields and Information Elements
6. イーサネットヘッダーフィールドと情報要素の関係
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)
a。（情報要素）destinationMacAddress（80）b。（情報要素）sourceMacAddress（56）c。（情報要素）dot1qVlanId（243）、dot1qPriority（244）d。（情報要素）ethernetType（256）
Figure 1: Customer-Tagged Frame Header Fields
図1：顧客タグ付きフレームヘッダーフィールド
<-- 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)
a。（情報要素）destinationMacAddress（80）b。（情報要素）sourceMacAddress（56）c。（情報要素）dot1qVlanId（243）、dot1qPriority（244）d。（情報要素）dot1qCustomerVlanId（245）、dot1qCustomerPriority（246） e。（情報要素）ethernetType（256）
Figure 2: Service-Tagged Frame Header Fields
図2：サービスタグ付きフレームヘッダーフィールド
<-- 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)
a。（情報要素）destinationMacAddress（80）b。（情報要素）sourceMacAddress（56）c。（情報要素）dot1qVlanId（243）、dot1qPriority（244）d。（情報要素）dot1qServiceInstanceTag（411）、または一連のdot1qServiceInstanceId（412）、dot1qServiceInstancePriority（413）、dot1qCustomerSourceMacAddress（414）dot1qCustomerDestinationMacAddress（415）、e。（情報要素）dot1qCustomerVlanId（245）、dot1qCustomerPriority（246）f。（情報要素）ethernetType（256）
Figure 3: Backbone-VLAN-Tagged Frame Header Fields
図3：バックボーンVLANタグ付きフレームヘッダーフィールド
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].
より詳細なデータを報告すると、コレクタに対するDoS攻撃のリスクが高まる可能性があります。 DoS攻撃に対する保護については、[RFC7011]のセクション11.4で説明されています。
The recommendations in this document do not otherwise introduce any additional security issues beyond those already mentioned in [RFC7011] and [RFC5477].
このドキュメントの推奨事項では、[RFC7011]と[RFC5477]ですでに言及されている問題以外に、その他のセキュリティ問題が発生することはありません。
Existing IPFIX Information Elements [IANA-IPFIX] have been modified as indicated in Sections 3.1, 4, and 5.
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.
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.
セクション3.2に示すように、新しいIPFIX情報要素[IANA-IPFIX]が割り当てられました。
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.
このドキュメントの作成を通じてメーリングリストでの議論に貢献してくれたBrian TrammellとIPFIXワーキンググループの参加者に感謝します。この作業のIEEE 802の側面に関する支援をしてくれたPat Thalerに特に感謝します。
[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.11] IEEE、「IEEE Standard for Information technology。Telecommunications and information exchange between system Local and metropolitan area network。Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、IEEE Std 802.11-2012、2012年3月。
[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.1BR] IEEE、「IEEE Standard for Local and Metropolitan Area Networks：Virtual Bridged Local Area Networks：Bridge Port Extension」、IEEE Std 802.1BR-2012、2012年7月。
[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.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.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、2012年7月。
[IEEE802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2012, December 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.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F。、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月。
[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.
[RFC7011] Claise、B.、Trammell、B。、およびP. Aitken、「Specification of the IP Flow Information Export（IPFIX）Protocol for the Exchange of Flow Information of Exchange」、STD 77、RFC 7011、2013年9月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix>.
[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.
[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.
[ISO / IEC.7498-1：1994]国際標準化機構、「情報技術-オープンシステム相互接続-基本参照モデル：基本モード」、ISO標準7498-1：1994、1996年6月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804] IABおよびIESG、「盗聴に関するIETFポリシー」、RFC 2804、2000年5月。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012] Claise、B。およびB. Trammell、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、2013年9月。
[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.
[RFC7013] Trammell、B。およびB. Claise、「作成者とIPフロー情報エクスポート（IPFIX）情報要素のレビューアのためのガイドライン」、BCP 184、RFC 7013、2013年9月。
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
図A-1：タグなしフレーム形式
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
図A-2：C-TAGタグ付けフレームフォーマット
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
図A-3：プロバイダーブリッジネットワークのS-TAGタグ付けフレームフォーマット
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
図A-4：プロバイダーブリッジネットワークのS-TAGおよびC-TAGタグ付けフレームフォーマット
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
図A-5：プロバイダーバックボーンブリッジネットワークのB-TAGおよびI-TAGタグ付けフレームフォーマット
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
図A-6：プロバイダーバックボーンブリッジネットワークのB-TAG、I-TAG、およびC-TAGタギングフレーム形式
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
図A-7：端末とその隣接ブリッジ間のリンク上のSチャネルのS-TAGタグ付けフレームフォーマット
Note: The frame format in Figure A-7 is identical to the format in Figure A-3.
注：図A-7のフレーム形式は、図A-3の形式と同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-TAG TPID=0x88a8 |S-PCP|D| S-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-TAG TPID=0x8100 |C-PCP|C| C-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A-8: S-TAG and C-TAG Tagging Frame Format over the Link between an End Station and Its Adjacent Bridge
図A-8：端末とその隣接ブリッジ間のリンク上のS-TAGおよびC-TAGタグ付けフレームフォーマット
Note: The frame format in Figure A-8 is identical to the format in Figure A-4.
注：図A-8のフレーム形式は、図A-4の形式と同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-DA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| C-SA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-TAG TPID=0x893F |E-PCP|D| Ingress_E-CID_base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|GRP| E-CID_base |Ingre_E-CID_ext| E-CID_ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length/Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Customer Data ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A-9: E-TAG Tagging Frame Format over the Link between a Controlling Bridge and a Bridge Port Extender
図A-9：制御ブリッジとブリッジポートエクステンダー間のリンク上のE-TAGタグ付けフレームフォーマット
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
図A-10：制御ブリッジとブリッジポートエクステンダー間のリンク上のE-TAGおよびC-TAGタグ付けフレームフォーマット
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
図B-1：テンプレート形式の例
Authors' Addresses
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
Paul Aitken Cisco Systems、Inc. 96 Commercial Quay Commercial Street、Edinburgh EH6 6LX United Kingdom
Phone: +44 131 561 3616
EMail: paitken@cisco.com