Internet Engineering Task Force (IETF) Z. Li
Request for Comments: 9533 China Mobile
Category: Standards Track T. Zhou
ISSN: 2070-1721 Huawei
J. Guo
ZTE Corp.
G. Mirsky
Ericsson
R. Gandhi
Cisco Systems, Inc.
January 2024
This document defines extensions to the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance-based traffic steering policy across the member links.
このドキュメントでは、一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）への拡張を定義して、リンク集約グループ（LAG）のすべてのメンバーリンクにパフォーマンス測定を実装します。ラグの各メンバーリンクの測定されたメトリックを知ることで、オペレーターはメンバーリンク全体でパフォーマンスベースのトラフィックステアリングポリシーを実施できます。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9533.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9533で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Micro Sessions on a LAG
3. Micro OWAMP Session
3.1. Micro OWAMP-Control
3.2. Micro OWAMP-Test
4. Micro TWAMP Session
4.1. Micro TWAMP-Control
4.2. Micro TWAMP-Test
4.2.1. Sender Packet Format and Content
4.2.2. Sender Behavior
4.2.3. Reflector Packet Format and Content
4.2.4. Reflector Behavior
5. Applicability
6. IANA Considerations
6.1. Micro OWAMP-Control Command
6.2. Micro TWAMP-Control Command
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
A Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides mechanisms to combine multiple physical links into a single logical link. This logical link offers higher bandwidth and better resiliency because, if one of the physical member links fails, the aggregate logical link can continue to forward traffic over the remaining operational physical member links.
[IEEE802.1AX]で定義されているリンク集約グループ（LAG）は、複数の物理リンクを単一の論理リンクに結合するメカニズムを提供します。この論理リンクは、物理メンバーリンクの1つが失敗した場合、集計論理リンクが残りの運用物理メンバーリンクを介してトラフィックを転送し続けることができるため、より高い帯域幅とより良い回復力を提供します。
Usually, when forwarding traffic over a LAG, a hash-based mechanism is used to load balance the traffic across the LAG member links. The link delay might vary between member links because of different transport paths, especially when a LAG is used in a wide area network. To provide low-latency service for time-sensitive traffic, we need to explicitly steer the traffic across the LAG member links based on the link delay, loss, and so on. That requires a solution to measure the performance metrics of every member link of a LAG. Hence, the measured performance metrics can work together with Layer 2 bundle member link attributes advertisement [RFC8668] for traffic steering.
通常、トラフィックを遅延に転送する場合、ハッシュベースのメカニズムを使用して、ラグメンバーリンク全体のトラフィックのバランスを負担します。リンクの遅延は、特に広い領域ネットワークで遅れが使用される場合、輸送パスが異なるため、メンバーリンク間で異なる場合があります。時間に敏感なトラフィックのために低遅延サービスを提供するには、リンクの遅延、損失などに基づいて、LAGメンバーリンク全体でトラフィックを明示的に操縦する必要があります。これには、遅延のすべてのメンバーリンクのパフォーマンスメトリックを測定するソリューションが必要です。したがって、測定されたパフォーマンスメトリックは、トラフィックステアリングのレイヤー2バンドルメンバーリンク属性広告[RFC8668]と併用できます。
According to the classifications in [RFC7799], OWAMP [RFC4656] and TWAMP [RFC5357] are active measurement methods, and they can complement passive and hybrid methods. With either method, one test session over the LAG can be used to measure the performance of a member link using a specially constructed 5-tuple. The session can be used to measure an average of some or all member links of the LAG by varying one or more elements of that 5-tuple. However, without the knowledge of each member link, a test session cannot measure the performance of every physical member link.
[RFC7799]の分類によれば、OWAMP [RFC4656]およびTWAMP [RFC5357]はアクティブな測定方法であり、受動的およびハイブリッド方法を補完することができます。どちらの方法でも、ラグ上の1つのテストセッションを使用して、特別に構築された5タプルを使用してメンバーリンクのパフォーマンスを測定できます。セッションは、5タプルの1つ以上の要素を変化させることにより、遅延の平均またはすべてのメンバーリンクを測定するために使用できます。ただし、各メンバーリンクの知識がなければ、テストセッションでは、すべての物理メンバーリンクのパフォーマンスを測定することはできません。
This document extends OWAMP and TWAMP to implement performance measurement on every member link of a LAG. It can provide the same metrics as OWAMP and TWAMP can measure, such as delay, jitter, and packet loss.
このドキュメントは、OWAMPとTWAMPを拡張して、ラグのすべてのメンバーリンクにパフォーマンス測定を実装します。OwampとTwampが測定できるのと同じメトリックを提供できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document addresses the scenario where a LAG directly connects two nodes. An example of this is in Figure 1, where the LAG consisting of four links connects nodes A and B. The goal is to measure the performance of each link of the LAG.
このドキュメントでは、ラグが2つのノードを直接接続するシナリオを扱います。この例は、4つのリンクで構成されるラグがノードAとBを接続する図1にあります。目標は、ラグの各リンクのパフォーマンスを測定することです。
+---+ +---+
| |-----------------------| |
| A |-----------------------| B |
| |-----------------------| |
| |-----------------------| |
+---+ +---+
Figure 1: Performance Measurement on a LAG
図1：遅れのパフォーマンス測定
To measure the performance metrics of every member link of a LAG, multiple sessions (one session for each member link) need to be established between the two endpoints that are connected by the LAG. These sessions are called "micro sessions" in the remainder of this document. Although micro sessions are in fact OWAMP or TWAMP sessions established on member links of a LAG, test packets of micro TWAMP sessions MUST carry member link information for validation.
ラグのすべてのメンバーリンクのパフォーマンスメトリックを測定するには、ラグで接続されている2つのエンドポイント間で複数のセッション（各メンバーリンクに1つのセッション）を確立する必要があります。これらのセッションは、このドキュメントの残りの「マイクロセッション」と呼ばれます。マイクロセッションは実際には、LAGのメンバーリンクに確立されたOWAMPまたはTWAMPセッションですが、マイクロTwampセッションのテストパケットは、検証のためにメンバーリンク情報を伝達する必要があります。
All micro sessions of a LAG share the same Sender IP Address and Receiver IP Address. As for the UDP port, the micro sessions may share the same Sender Port and Receiver Port pair or each micro session may be configured with a different Sender Port and Receiver Port pair. From the operational point of view, the former is simpler and is RECOMMENDED.
LAGのすべてのマイクロセッションは、同じ送信者IPアドレスと受信機のIPアドレスを共有します。UDPポートに関しては、マイクロセッションは同じ送信者ポートとレシーバーポートペアを共有する場合があります。または、各マイクロセッションは、異なる送信者ポートとレシーバーポートペアで構成される場合があります。運用の観点からは、前者はよりシンプルで推奨されます。
Test packets of a micro session MUST carry the member link information for validation checks. For example, when a micro TWAMP Session-Sender receives a reflected test packet, it checks whether the test packet is from the expected member link.
マイクロセッションのテストパケットは、検証チェックのためにメンバーリンク情報を運ぶ必要があります。たとえば、Micro Twampセッションセンダーが反射テストパケットを受信すると、テストパケットが予想されるメンバーリンクからであるかどうかを確認します。
To support the micro OWAMP session, a new command, Request-OW-Micro-Sessions (5), is defined in this document. The Request-OW-Micro-Sessions command is based on the OWAMP Request-Session command and uses the message format as described in Section 3.5 of [RFC4656]. Test session creation of micro OWAMP sessions follows the same procedure as defined in Section 3.5 of [RFC4656] with the following additions:
Micro Owampセッションをサポートするために、このドキュメントでは、新しいコマンドであるリクエストオウミクロセッション（5）が定義されています。Request-Ow-Micro-Sessionsコマンドは、OWAMPリクエストセッションコマンドに基づいており、[RFC4656]のセクション3.5で説明されているメッセージ形式を使用します。マイクロオワンプセッションのテストセッションの作成は、[RFC4656]のセクション3.5で定義されているのと同じ手順に従い、次の追加が行われます。
When an OWAMP Server receives a Request-OW-Micro-Sessions command, if the request is accepted, the OWAMP Server MUST build a set of micro sessions for all the member links of the LAG from which the Request-OW-Micro-Sessions message is received.
OWAMPサーバーがリクエストオウミクロセッションコマンドを受信した場合、リクエストが受け入れられた場合、OWAMPサーバーは、リクエストオウミクロセッションメッセージのすべてのメンバーリンクのマイクロセッションのセットを構築する必要があります。受け取られます。
Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures as defined in Section 4 of [RFC4656] with the following additions:
Micro Owamp-Testは、[RFC4656]のセクション4で定義されているOwamp-Testパケット形式と手順を、次の追加で再利用します。
The micro OWAMP Session-Sender MUST send the micro OWAMP-Test packets over the member link with which the session is associated. When it receives a test packet, the micro OWAMP Session-Receiver MUST use the member link from which the test packet is received to correlate the micro OWAMP session. If there is no such session, the test packet MUST be discarded.
Micro Owampセッションセンダーは、セッションが関連付けられているメンバーリンク上にマイクロオウンプテストパケットを送信する必要があります。テストパケットを受信した場合、Micro Owamp Session-Receiverは、Micro Owampセッションを相関させるために、テストパケットが受信されるメンバーリンクを使用する必要があります。そのようなセッションがない場合は、テストパケットを破棄する必要があります。
To support the micro TWAMP session, a new command, Request-TW-Micro-Sessions (11), is defined in this document. The Request-TW-Micro-Sessions command is based on the TWAMP Request-Session command and uses the message format as described in Section 3.5 of [RFC5357]. Test session creation of micro TWAMP sessions follows the same procedure as defined in Section 3.5 of [RFC5357] with the following additions:
Micro Twampセッションをサポートするために、新しいコマンドであるRequest-TW-Micro-Sessions（11）をこのドキュメントで定義しています。Request-TW-Micro-Sessionsコマンドは、TWAMPリクエストセッションコマンドに基づいており、[RFC5357]のセクション3.5で説明されているメッセージ形式を使用します。テストセッションMicro Twampセッションの作成は、[RFC5357]のセクション3.5で定義されているのと同じ手順に従い、次の追加が行われます。
When a TWAMP Server receives a Request-TW-Micro-Sessions command, if the request is accepted, the TWAMP Server MUST build a set of micro sessions for all the member links of the LAG from which the Request-TW-Micro-Sessions message is received.
TWAMPサーバーがRequest-TW-Micro-Sessionsコマンドを受信した場合、リクエストが受け入れられた場合、TWAMPサーバーは、リクエストTw-Micro-Sessionsメッセージのすべてのメンバーリンクのマイクロセッションのセットを構築する必要があります。受け取られます。
The micro TWAMP-Test protocol is based on the TWAMP-Test protocol [RFC5357] with the extensions described in the following subsections.
Micro Twamp-Testプロトコルは、次のサブセクションで説明されている拡張機能を備えたTwamp-Testプロトコル[RFC5357]に基づいています。
The micro TWAMP Session-Sender packet format is based on the TWAMP Session-Sender packet format as defined in Section 4.1.2 of [RFC5357]. Two new fields (Sender Micro-session ID and Reflector Micro-session ID) are added to carry the LAG member link identifiers.
Micro Twampセッションセンダーパケット形式は、[RFC5357]のセクション4.1.2で定義されているTWAMPセッションセンダーパケット形式に基づいています。2つの新しいフィールド（送信者マイクロセッションIDとリフレクターマイクロセッションID）が追加され、LAGメンバーリンク識別子が携帯されています。
For unauthenticated mode, the format is as below:
認証されていないモードの場合、形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Micro Session-Sender Packet Format in Unauthenticated Mode
図2：認証されていないモードのマイクロセッションセンダーパケット形式
For authenticated and encrypted mode, the format is as below:
認証されたモードと暗号化モードの場合、形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Micro Session-Sender Packet Format in Authenticated Mode
図3：認証モードのマイクロセッションセンダーパケット形式
Except for the Sender Micro-session ID field and the Reflector Micro-session ID field, all the other fields are the same as defined in Section 4.1.2 of [RFC5357] and follow the procedure and guidelines defined therein.
送信者マイクロセッションIDフィールドとリフレクターマイクロセッションIDフィールドを除き、他のすべてのフィールドは[RFC5357]のセクション4.1.2で定義されているものと同じであり、そこに定義されている手順とガイドラインに従います。
Sender Micro-session ID (2 octets in length):
送信者マイクロセッションID（長さ2オクテット）：
This field is defined to carry the LAG member link identifier of the Sender side. In the future, it may be used generically to cover use cases beyond LAGs. The value of this field MUST be unique within a TWAMP session at the Session-Sender.
このフィールドは、送信者側のLAGメンバーリンク識別子を運ぶために定義されています。将来的には、ラグを超えてユースケースをカバーするために一般的に使用される場合があります。このフィールドの価値は、セッションセンダーのTwampセッション内で一意でなければなりません。
Reflector Micro-session ID (2 octets in length):
リフレクターマイクロセッションID（長さ2オクテット）：
This field is defined to carry the LAG member link identifier of the Reflector side. In the future, it may be used generically to cover use cases beyond LAGs. The value of this field MUST be unique within a TWAMP session at the Session-Reflector.
このフィールドは、リフレクター側のLAGメンバーリンク識別子を運ぶために定義されています。将来的には、ラグを超えてユースケースをカバーするために一般的に使用される場合があります。このフィールドの値は、セッションリフレクターのTwampセッション内で一意でなければなりません。
The micro TWAMP Session-Sender inherits the behaviors of the TWAMP Session-Sender as defined in Section 4.1 of [RFC5357]. In addition, the micro TWAMP Session-Sender MUST send the micro Session-Sender test packets over the member link with which the session is associated.
Micro Twampセッションセンダーは、[RFC5357]のセクション4.1で定義されているように、TWAMPセッションセンダーの動作を継承します。さらに、Micro Twampセッションセンダーは、セッションが関連付けられているメンバーリンク上にマイクロセッションセンダーテストパケットを送信する必要があります。
When sending the test packet, the micro TWAMP Session-Sender MUST put the Sender member link identifier that is associated with the micro TWAMP session in the Sender Micro-session ID. If the Session-Sender knows the Reflector member link identifier, the Reflector Micro-session ID field (see Figures 2 and 3) MUST be set. Otherwise, the Reflector Micro-session ID field MUST be zero.
テストパケットを送信するとき、Micro Twampセッションセンダーは、送信者マイクロセッションIDのMicro Twampセッションに関連付けられている送信者メンバーリンク識別子を配置する必要があります。セッションセンダーがリフレクターメンバーリンク識別子を知っている場合、リフレクターマイクロセッションIDフィールド（図2および3を参照）を設定する必要があります。それ以外の場合、リフレクターマイクロセッションIDフィールドはゼロでなければなりません。
A test packet with a Sender member link identifier is sent to the Session-Reflector and then is reflected with the same Sender member link identifier. So the Session-Sender can use the Sender member link identifier to check whether a reflected test packet is received from the member link associated with the correct micro TWAMP session.
送信者メンバーリンク識別子を備えたテストパケットがセッションリフレクターに送信され、同じ送信者メンバーリンク識別子に反映されます。そのため、セッションセンダーは、送信者メンバーリンク識別子を使用して、正しいMicro Twampセッションに関連付けられたメンバーリンクから反射テストパケットが受信されるかどうかを確認できます。
The Reflector member link identifier carried in the Reflector Micro-session ID field is used by the Session-Reflector to check whether a test packet is received from the member link associated with the correct micro TWAMP session. It means that the Session-Sender has to learn the Reflector member link identifier. Once the Session-Sender knows the Reflector member link identifier, it MUST put the identifier in the Reflector Micro-session ID field (see Figures 2 or 3) of the test packets that will be sent to the Session-Reflector. The Reflector member link identifier can be obtained from preconfiguration or learned from the data plane (e.g., the reflected test packet). This document does not specify the way to obtain the Reflector member link identifier.
リフレクターマイクロセッションIDフィールドに運ばれるリフレクターメンバーリンク識別子は、セッションリフレクターによって使用され、正しいマイクロトゥープセッションに関連付けられたメンバーリンクからテストパケットが受信されるかどうかを確認します。これは、セッションセンダーがリフレクターメンバーリンク識別子を学習する必要があることを意味します。セッションセンダーがリフレクターメンバーリンク識別子を把握したら、セッションリフレクターに送信されるテストパケットのリフレクターマイクロセッションIDフィールド（図2または3を参照）に識別子を配置する必要があります。リフレクターメンバーリンク識別子は、事前設定から取得するか、データプレーン（例：反射テストパケット）から学習できます。このドキュメントでは、リフレクターメンバーリンク識別子を取得する方法を指定していません。
When receiving a reflected test packet, the micro TWAMP Session-Sender MUST use the receiving member link to correlate the reflected test packet to a micro TWAMP session. If there is no such session, the reflected test packet MUST be discarded. If a matched session exists, the micro Session-Sender MUST use the Sender Micro-session ID to validate whether the reflected test packet is correctly received from the expected member link. If the validation fails, the test packet MUST be discarded. The micro Session-Sender MUST use the Reflector Micro-session ID to validate the Reflector's behavior. If the validation fails, the test packet MUST be discarded.
反射テストパケットを受信する場合、Micro Twampセッションセンダーは受信メンバーリンクを使用して、反射テストパケットをMicro Twampセッションに相関させる必要があります。そのようなセッションがない場合、反射されたテストパケットを破棄する必要があります。一致したセッションが存在する場合、マイクロセッションセンダーは送信者マイクロセッションIDを使用して、反射テストパケットが予想されるメンバーリンクから正しく受信されるかどうかを検証する必要があります。検証が失敗した場合、テストパケットを破棄する必要があります。マイクロセッションセンダーは、リフレクターマイクロセッションIDを使用して、リフレクターの動作を検証する必要があります。検証が失敗した場合、テストパケットを破棄する必要があります。
The micro TWAMP Session-Reflector packet format is based on the TWAMP Session-Reflector packet format as defined in Section 4.2.1 of [RFC5357]. Two new fields (Sender and Reflector Micro-session ID) are added to carry the LAG member link identifiers.
Micro Twampセッション - レフレクターパケット形式は、[RFC5357]のセクション4.2.1で定義されているTWAMPセッション - レフェクターパケット形式に基づいています。2つの新しいフィールド（送信者とリフレクターのマイクロセッションID）が追加され、LAGメンバーリンク識別子が携帯されています。
For unauthenticated mode, the format is as below:
認証されていないモードの場合、形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | Sender Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | MBZ | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Micro Session-Reflector Packet Format in Unauthenticated Mode
図4：無認定モードでのマイクロセッション - リフレクターパケット形式
For authenticated and encrypted mode, the format is as below:
認証されたモードと暗号化モードの場合、形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
| |
| MBZ (15 octets) |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Micro Session-Reflector Packet Format in Authenticated Mode
図5：認証されたモードのマイクロセッション - リフレクターパケット形式
Except for the Sender Micro-session ID field and the Reflector Micro-session ID field, all the other fields are the same as defined in Section 4.2.1 of [RFC5357] and follow the same procedure and guidelines defined therein.
送信者マイクロセッションIDフィールドとリフレクターマイクロセッションIDフィールドを除き、他のすべてのフィールドは[RFC5357]のセクション4.2.1で定義されているものと同じであり、そこに定義されているのと同じ手順とガイドラインに従います。
Sender Micro-session ID (2 octets in length):
送信者マイクロセッションID（長さ2オクテット）：
This field is defined to carry the LAG member link identifier of the Sender side. In the future, it may be used generically to cover use cases beyond LAGs. The value of this field MUST be unique within a TWAMP session at the Session-Sender.
このフィールドは、送信者側のLAGメンバーリンク識別子を運ぶために定義されています。将来的には、ラグを超えてユースケースをカバーするために一般的に使用される場合があります。このフィールドの価値は、セッションセンダーのTwampセッション内で一意でなければなりません。
Reflector Micro-session ID (2 octets in length):
リフレクターマイクロセッションID（長さ2オクテット）：
This field is defined to carry the LAG member link identifier of the Reflector side. In the future, it may be used generically to cover use cases beyond LAGs. The value of this field MUST be unique within a TWAMP session at the Session-Reflector.
このフィールドは、リフレクター側のLAGメンバーリンク識別子を運ぶために定義されています。将来的には、ラグを超えてユースケースをカバーするために一般的に使用される場合があります。このフィールドの値は、セッションリフレクターのTwampセッション内で一意でなければなりません。
The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP Session-Reflector as defined in Section 4.2 of [RFC5357].
Micro Twampセッションリフレクターは、[RFC5357]のセクション4.2で定義されているように、TWAMPセッションリフレクターの動作を継承します。
In addition, when receiving a test packet, the micro TWAMP Session-Reflector MUST use the receiving member link to correlate the test packet to a micro TWAMP session. If there is no such a session, the test packet MUST be discarded. If the Reflector Micro-session ID is not zero, the Reflector MUST use the Reflector Micro-session ID to validate whether it associates with the receiving member link. If the Reflector Micro-session ID is zero, it will not be verified. If the validation fails, the test packet MUST be discarded.
さらに、テストパケットを受信する場合、Micro Twampセッションリフレクターは受信メンバーリンクを使用して、テストパケットをMicro Twampセッションに相関させる必要があります。そのようなセッションがない場合は、テストパケットを破棄する必要があります。リフレクターマイクロセッションIDがゼロでない場合、リフレクターはリフレクターマイクロセッションIDを使用して、受信メンバーリンクと関連するかどうかを検証する必要があります。リフレクターのマイクロセッションIDがゼロの場合、検証されません。検証が失敗した場合、テストパケットを破棄する必要があります。
When sending a response to the received test packet, the micro TWAMP Session-Reflector MUST copy the Sender member link identifier from the received test packet and put it in the Sender Micro-session ID field of the reflected test packet (see Figures 4 and 5). In addition, the micro TWAMP Session-Reflector MUST fill the Reflector Micro-session ID field (see Figures 4 and 5) of the reflected test packet with the member link identifier that is associated with the micro TWAMP session.
受信したテストパケットに応答を送信するとき、Micro Twampセッションリフレクターは、受信したテストパケットから送信者メンバーリンク識別子をコピーし、反射テストパケットの送信者マイクロセッションIDフィールドに配置する必要があります（図4および5を参照してください）。さらに、Micro TwAMPセッションリフレクターは、反射テストパケットのリフレクターマイクロセッションIDフィールド（図4および5を参照）を、マイクロトワンプセッションに関連付けられているメンバーリンク識別子を埋める必要があります。
To set up the micro OWAMP sessions, the Control-Client sends the Request-OW-Micro-Sessions command to the OWAMP Server. The OWAMP Server accepts the request and builds a set of micro sessions for all the member links of the LAG.
Micro Owampセッションをセットアップするには、Control-ClientがRequest-Ow-Micro-SessionsコマンドをOwampサーバーに送信します。OWAMPサーバーはリクエストを受け入れ、ラグのすべてのメンバーリンクのマイクロセッションのセットを構築します。
For micro TWAMP sessions, a similar set up procedure is used. Then, the micro TWAMP Session-Sender sends micro Session-Sender packets with the Sender Micro-session ID and the Reflector Micro-session ID. If the Reflector Micro-session ID field is set, the micro Session-Reflector checks whether a test packet is received from the member link associated with the correct micro TWAMP session. When reflecting, the micro TWAMP Session-Reflector copies the Sender Micro-session ID from the received micro Session-Sender packet to the micro Session-Reflector packet; then, it sets the Reflector Micro-session ID field with the member link identifier that is associated with the micro TWAMP session. When receiving the micro TWAMP Session-Reflector packet, the micro Session-Sender uses the Sender Micro-session ID to check whether the packet is received from the member link associated with the correct micro TWAMP session. The micro Session-Sender also uses the Reflector Micro-session ID to validate the Reflector's behavior.
Micro Twampセッションの場合、同様のセットアップ手順が使用されます。次に、Micro Twampセッションセンダーは、送信者マイクロセッションIDとリフレクターマイクロセッションIDでマイクロセッションセンダーパケットを送信します。リフレクターマイクロセッションIDフィールドが設定されている場合、マイクロセッションリフレクターは、正しいマイクロトゥープセッションに関連付けられたメンバーリンクからテストパケットが受信されるかどうかをチェックします。反映するとき、Micro Twampセッションリフレクターは、受信したマイクロセッションセンダーパケットからMicro Session-Reflectorパケットに送信者マイクロセッションIDをコピーします。次に、Micro Twampセッションに関連付けられているメンバーリンク識別子を使用して、リフレクターマイクロセッションIDフィールドを設定します。Micro Twampセッションリフレクターパケットを受信するとき、Micro Session-SenderはSender Micro-Session IDを使用して、正しいMicro Twampセッションに関連付けられたメンバーリンクからパケットが受信されるかどうかを確認します。マイクロセッションセンダーは、リフレクターマイクロセッションIDを使用して、リフレクターの動作を検証します。
IANA has allocated the following command type from the "OWAMP-Control Command Numbers" registry.
IANAは、「Owamp-Controlコマンド番号」レジストリから次のコマンドタイプを割り当てました。
+=======+===========================+===============+
| Value | Description | Reference |
+=======+===========================+===============+
| 5 | Request-OW-Micro-Sessions | This document |
+-------+---------------------------+---------------+
Table 1: Request-OW-Micro-Sessions Command Number
表1：リクエスト - マイクロセッションコマンド番号
IANA has allocated the following command type from the "TWAMP-Control Command Numbers" registry.
IANAは、「Twamp-Controlコマンド番号」レジストリから次のコマンドタイプを割り当てました。
+=======+===========================+===============+
| Value | Description | Reference |
+=======+===========================+===============+
| 11 | Request-TW-Micro-Sessions | This document |
+-------+---------------------------+---------------+
Table 2: Request-TW-Micro-Sessions Command Number
表2：リクエストTw-Micro-Sessionsコマンド番号
This document does not introduce additional security requirements and mechanisms other than those described in [RFC4656] and [RFC5357].
このドキュメントでは、[RFC4656]および[RFC5357]に記載されているもの以外の追加のセキュリティ要件とメカニズムは導入されていません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.
[IEEE802.1AX]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks -- Link Aggregation", IEEE Std 802.1AX-2020,
DOI 10.1109/IEEESTD.2020.9105034, May 2020,
<https://ieeexplore.ieee.org/document/9105034>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
The authors would like to thank Fang Xin, Henrik Nydell, Mach Chen, Min Xiao, Jeff Tantsura, Marcus Ihlar, and Richard Foote for the valuable comments to this work.
著者は、Fang Xin、Henrik Nydell、Mach Chen、Min Xiao、Jeff Tantsura、Marcus Ihlar、およびRichard Footeに、この作品への貴重なコメントをしてくれたことに感謝します。
Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com