[要約] RFC 8237は、静的なPWの状態更新を削減するためのMPLS Label Switched Path (LSP) Pseudowire (PW)の仕様です。目的は、ネットワークの効率を向上させ、リソースの節約を図ることです。

Internet Engineering Task Force (IETF)                        L. Martini
Request for Comments: 8237                                   Monoski LLC
Category: Standards Track                                     G. Swallow
ISSN: 2070-1721                                                     SETC
                                                           E. Bellagamba
                                                                Ericsson
                                                            October 2017
        

MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs

静的PWのMPLSラベルスイッチドパス(LSP)疑似配線(PW)ステータスリフレッシュ削減

Abstract

概要

This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP.

このドキュメントでは、LSPで伝送される1つ以上のPWのステータスを示すために、マルチプロトコルラベルスイッチング(MPLS)ラベルスイッチドパス(LSP)で静的に構成されたPWに対して送信される集約疑似配線(PW)ステータスメッセージを生成する方法について説明します。

The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.

PWステータス情報の送信方法は新しいものではありません。ただし、このプロトコル拡張により、サービスプロバイダー(SP)は、複数の定期的なステータスメッセージでネットワークを圧倒することなく、個々のPWステータスを確実に監視できます。これは、同じLSPにグループ化されたすべてのPWに対して単一の累積サマリーステータス検証メッセージを送信することで実現されます。

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 7841.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、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/rfc8237.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8237で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2017 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 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トラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................4
      1.2. Terminology ................................................4
      1.3. Notational Conventions .....................................5
   2. PW Status Refresh Reduction Protocol ............................5
      2.1. Protocol States ............................................5
           2.1.1. INACTIVE ............................................5
           2.1.2. STARTUP .............................................6
           2.1.3. ACTIVE ..............................................6
      2.2. Timer Value Change Transition Procedure ....................6
   3. PW Status Refresh Reduction Procedure ...........................7
   4. PW Status Refresh Reduction Message Encoding ....................8
   5. PW Status Refresh Reduction Control Messages ...................11
      5.1. Notification Message ......................................12
      5.2. PW Configuration Message ..................................12
           5.2.1. MPLS-TP Tunnel ID ..................................13
           5.2.2. PW ID Configured List ..............................14
           5.2.3. PW ID Unconfigured List ............................15
   6. PW Provisioning Verification Procedure .........................15
      6.1. PW ID List Advertising and Processing .....................16
   7. Security Considerations ........................................16
   8. IANA Considerations ............................................17
      8.1. PW Status Refresh Reduction Message Types .................17
      8.2. PW Configuration Message Sub-TLVs .........................17
      8.3. PW Status Refresh Reduction Notification Codes ............18
      8.4. PW Status Refresh Reduction Message Flags .................18
      8.5. G-ACh Registry Allocation .................................19
      8.6. Guidance for Designated Experts ...........................19
   9. References .....................................................19
      9.1. Normative References ......................................19
      9.2. Informative References ....................................20
   Authors' Addresses ................................................20
        
1. Introduction
1. はじめに

When PWs use a Multiprotocol Label Switching (MPLS) network as the Packet Switched Network (PSN), they are set up using static label assignment per Section 4 of [RFC8077], and the PW status information is propagated using the method described in [RFC6478]. There are two basic modes of operation described in [RFC6478], Section 5.3: (1) periodic retransmission of non-zero status messages and (2) a simple acknowledgment of PW status (Section 5.3.1 of [RFC6478]). The LSP-level protocol described below applies to the case when PW status is acknowledged immediately with a requested refresh value of zero (no refresh). In this case, the PW status refresh reduction protocol is necessary for several reasons, such as the following:

PWがマルチプロトコルラベルスイッチング(MPLS)ネットワークをパケット交換ネットワーク(PSN)として使用する場合、[RFC8077]のセクション4に従って静的ラベル割り当てを使用してセットアップされ、[RFC6478]で説明されている方法を使用してPWステータス情報が伝達されます。 ]。 [RFC6478]のセクション5.3で説明されている2つの基本的な動作モードがあります:(1)ゼロ以外のステータスメッセージの定期的な再送信と(2)PWステータスの単純な確認応答([RFC6478]のセクション5.3.1)。以下で説明するLSPレベルのプロトコルは、要求されたリフレッシュ値がゼロ(リフレッシュなし)でPWステータスがすぐに確認される場合に適用されます。この場合、次のようないくつかの理由により、PWステータスリフレッシュ削減プロトコルが必要です。

i. The PW status refresh reduction protocol greatly increases the scalability of the PW status protocol by reducing the amount of messages that a Provider Edge (PE) needs to periodically send to its neighbors.

i. PWステータスリフレッシュ削減プロトコルは、プロバイダーエッジ(PE)が定期的にネイバーに送信する必要があるメッセージの量を減らすことにより、PWステータスプロトコルのスケーラビリティを大幅に向上させます。

ii. The PW status refresh reduction protocol will detect a remote PE restart.

ii。 PWステータスリフレッシュ削減プロトコルは、リモートPEの再起動を検出します。

iii. If the local state is lost for some reason, the PE needs to be able to request a status refresh reduction from the remote PE.

iii。何らかの理由でローカル状態が失われた場合、PEはリモートPEにステータスリフレッシュの削減を要求できる必要があります。

iv. The PW status refresh reduction protocol can optionally detect a remote PE provisioning change.

iv。 PWステータスリフレッシュ削減プロトコルは、オプションでリモートPEプロビジョニングの変更を検出できます。

1.1. Requirements Language
1.1. 要件言語

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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

1.2. Terminology
1.2. 用語

FEC: Forwarding Equivalence Class

FEC:転送同等クラス

LDP: Label Distribution Protocol

LDP:ラベル配布プロトコル

LSP: Label Switched Path

LSP:ラベルスイッチドパス

MS-PW: Multi-Segment Pseudowire

MS-PW:マルチセグメント疑似配線

PE: Provider Edge

PE:プロバイダーエッジ

PW: Pseudowire

説明:シュードビル

S-PE: Switching Provider Edge Node of MS-PW

S-PE:MS-PWのスイッチングプロバイダーエッジノード

SS-PW: Single-Segment Pseudowire

SS-PW:単一セグメント疑似配線

T-PE: Terminating Provider Edge Node of MS-PW

T-PE:MS-PWのプロバイダーエッジノードの終了

1.3. Notational Conventions
1.3. 表記規則

All multiple-word atomic identifiers use underscores ("_") between the words to join the words. Many of the identifiers are composed of a concatenation of other identifiers. These are expressed using double-colon ("::") notation.

すべての複数単語のアトミックIDは、単語を結合するために単語間にアンダースコア( "_")を使用します。識別子の多くは、他の識別子の連結で構成されています。これらは、ダブルコロン( "::")表記を使用して表されます。

Where the same identifier type is used multiple times in a concatenation, they are qualified by a prefix joined to the identifier by a dash ("-"). For example, Src-Node_ID is the Node_ID of a node referred to as "Src" ("Src" is short for "source").

同じ識別子タイプが連結で複数回使用される場合、それらはダッシュ( "-")によって識別子に結合された接頭辞によって修飾されます。たとえば、Src-Node_IDは、「Src」と呼ばれるノードのNode_IDです(「Src」は「ソース」の略)。

The notation does not define an implicit ordering of the information elements involved in a concatenated identifier.

この表記は、連結された識別子に含まれる情報要素の暗黙的な順序を定義していません。

2. PW Status Refresh Reduction Protocol
2. PWステータスリフレッシュ削減プロトコル

The PW status refresh reduction protocol consists of a simple message that is sent at the LSP level, using the MPLS Generic Associated Channel (G-ACh) [RFC5586].

PWステータスリフレッシュ削減プロトコルは、MPLS Generic Associated Channel(G-ACh)[RFC5586]を使用して、LSPレベルで送信される単純なメッセージで構成されます。

For a particular LSP where the PW status refresh reduction protocol is enabled, a PE using this protocol MUST send the PW status refresh reduction Message as soon as a PW is configured on that LSP. The message is then retransmitted at a locally configured interval indicated in the Refresh Timer field. If no acknowledgment is received, the protocol does not reach the ACTIVE state (Section 2.1.3), and the PE SHOULD NOT send any PW status messages with a Refresh Timer of zero as described in [RFC6478], Section 5.3.1.

PWステータスリフレッシュ削減プロトコルが有効になっている特定のLSPの場合、このプロトコルを使用するPEは、そのLSPでPWが構成されるとすぐに、PWステータスリフレッシュ削減メッセージを送信する必要があります。その後、メッセージは、Refresh Timerフィールドに示されているローカルに設定された間隔で再送信されます。 [RFC6478]のセクション5.3.1で説明されているように、確認応答が受信されない場合、プロトコルはACTIVE状態に到達せず(セクション2.1.3)、PEは更新タイマーがゼロのPWステータスメッセージを送信してはなりません(SHOULD NOT)。

It is worth noting that no relationship exists between the locally configured timer for the PW status refresh reduction protocol and the individual PW status Refresh Timers.

ローカルで設定されたPWステータスリフレッシュ削減プロトコルのタイマーと個々のPWステータスリフレッシュタイマーの間に関係はないことに注意してください。

2.1. Protocol States
2.1. プロトコルの状態

The protocol can be in three possible states: INACTIVE, STARTUP, and ACTIVE.

プロトコルは、INACTIVE、STARTUP、ACTIVEの3つの状態にあります。

2.1.1. INACTIVE
2.1.1. 非活性

This state is entered when the protocol is turned off. This state is also entered if all PWs on a specific LSP are deprovisioned.

プロトコルがオフになると、この状態になります。特定のLSP上のすべてのPWがプロビジョニング解除された場合も、この状態になります。

2.1.2. STARTUP
2.1.2. 起動

In this state, the PE transmits periodic PW status refresh reduction Messages with the Ack Session ID (Section 4) set to 0. The PE remains in this state until a PW status refresh message is received with the correct local Session ID in the Ack Session ID field. State can transition from the STARTUP state to the ACTIVE or INACTIVE state.

この状態では、PEは、AckセッションID(セクション4)が0に設定されたPWステータスリフレッシュ削減メッセージを定期的に送信します。PKステータスリフレッシュメッセージがAckセッションで正しいローカルセッションIDとともに受信されるまで、PEはこの状態のままです。 IDフィールド。状態は、STARTUP状態からACTIVEまたはINACTIVE状態に遷移できます。

2.1.3. ACTIVE
2.1.3. アクティブ

This state is entered once the PE receives a PW status refresh reduction Message with the correct local Session ID in the Ack Session ID field within 3.5 times the Refresh Timer field value of the last PW status refresh reduction Message transmitted. This state is immediately exited in the following scenarios:

最後に送信されたPWステータスリフレッシュ削減メッセージのリフレッシュタイマーフィールド値の3.5倍以内に、AckセッションIDフィールドに正しいローカルセッションIDを含むPWステータスリフレッシュ削減メッセージをPEが受信すると、この状態になります。この状態は、次のシナリオですぐに終了します。

i. A valid PW status refresh reduction Message is not received within 3.5 times the current Refresh Timer field value (assuming that a timer transition procedure is not in progress). New state: STARTUP.

i. 有効なPWステータスリフレッシュ削減メッセージが、現在のリフレッシュタイマーフィールド値の3.5倍以内に受信されません(タイマー遷移手順が進行中でないと想定)。新しい状態:STARTUP。

ii. A PW status refresh reduction Message is received with the wrong Ack Session ID field value or a zero Ack Session ID field value. New state: STARTUP.

ii。 PWステータスリフレッシュ削減メッセージが、誤ったAckセッションIDフィールド値またはゼロのAckセッションIDフィールド値とともに受信されます。新しい状態:STARTUP。

iii. All PWs using the particular LSP are deprovisioned, or the protocol is disabled. New state: INACTIVE.

iii。特定のLSPを使用するすべてのPWがプロビジョニング解除されるか、プロトコルが無効になります。新しい状態:INACTIVE。

2.2. Timer Value Change Transition Procedure
2.2. タイマー値変更の移行手順

If a PE needs to change the value of the Refresh Timer field while the PW status refresh reduction protocol is in the ACTIVE state, the following procedure must be followed:

PWステータスリフレッシュ削減プロトコルがACTIVE状態のときにPEが[Refresh Timer]フィールドの値を変更する必要がある場合は、次の手順に従う必要があります。

i. A PW status refresh reduction Message is transmitted with the new timer value.

i. PWステータスリフレッシュ削減メッセージが新しいタイマー値とともに送信されます。

ii. If the new value is greater than the original one, the PE will operate according to the new timer value immediately.

ii。新しい値が元の値より大きい場合、PEはすぐに新しいタイマー値に従って動作します。

iii. If the new value is smaller than the original one, the PE will operate according to the original timer value for a period 3.5 times the original timer value or until the first valid PW status refresh reduction Message is received.

iii。新しい値が元の値よりも小さい場合、PEは元のタイマー値に従って、元のタイマー値の3.5倍、または最初の有効なPWステータスリフレッシュ削減メッセージが受信されるまで動作します。

A PE receiving a PW status refresh reduction Message with a new timer value will immediately acknowledge the new value via a PW status refresh reduction Message and will start operating according to the new timer value.

新しいタイマー値を含むPWステータスリフレッシュ削減メッセージを受信したPEは、PWステータスリフレッシュ削減メッセージを介してすぐに新しい値を確認し、新しいタイマー値に従って動作を開始します。

3. PW Status Refresh Reduction Procedure
3. PWステータスリフレッシュ削減手順

When the PW status refresh reduction protocol on a particular LSP is in the ACTIVE state, the PE can send all PW status messages, for PWs on that LSP, with a Refresh Timer value of zero. This greatly decreases the amount of messages that the PE needs to transmit to the remote PE because once the PW status message for a particular PW is acknowledged, further repetitions of that message are no longer necessary.

特定のLSPのPWステータスリフレッシュ削減プロトコルがACTIVE状態の場合、PEは、そのLSPのPWに対して、リフレッシュタイマー値がゼロのすべてのPWステータスメッセージを送信できます。これにより、特定のPWのPWステータスメッセージが確認されると、そのメッセージをさらに繰り返す必要がなくなるため、PEがリモートPEに送信する必要のあるメッセージの量が大幅に減少します。

To further reduce the amount of possible messages when an LSP starts forwarding traffic, care should be taken to permit the PW status refresh reduction protocol to reach the ACTIVE state quickly, and before the first PW status Refresh Timer expires. This can be achieved by using a PW status refresh reduction Message Refresh Timer value that is much smaller than the PW status message Refresh Timer value in use (Section 5.3.1 of [RFC6478]).

LSPがトラフィックの転送を開始するときに可能なメッセージの量をさらに削減するには、PWステータスリフレッシュ削減プロトコルが最初のPWステータスリフレッシュタイマーが期限切れになる前にすばやくACTIVE状態に到達できるように注意する必要があります。これは、使用中のPWステータスメッセージリフレッシュタイマー値([RFC6478]のセクション5.3.1)よりもはるかに小さいPWステータスリフレッシュ削減メッセージリフレッシュタイマー値を使用することで実現できます。

If the PW status refresh reduction protocol session is terminated by entering the INACTIVE state or the STARTUP state, the PE MUST immediately resend all the previously sent PW status messages for that particular LSP for which the session was terminated. In this case, the Refresh Timer value MUST NOT be set to 0 and MUST be set according to the local policy of the PE router. Implementations MUST take care to avoid flooding the remote PE with a large number of PW status messages at once. If the PW status refresh reduction protocol session is terminated for administrative reasons and the local PE can still communicate with the remote PE, the local PE SHOULD pace the transmission of PW status messages to the remote PE.

PWステータスリフレッシュ削減プロトコルセッションがINACTIVE状態またはSTARTUP状態に入って終了した場合、PEは、セッションが終了した特定のLSPに対して以前に送信されたすべてのPWステータスメッセージを直ちに再送信する必要があります。この場合、リフレッシュタイマーの値は0に設定してはならず(MUST NOT)、PEルーターのローカルポリシーに従って設定する必要があります。実装は、一度に大量のPWステータスメッセージでリモートPEをあふれさせないように注意する必要があります。 PWステータスリフレッシュ削減プロトコルセッションが管理上の理由で終了し、ローカルPEがリモートPEと通信できる場合、ローカルPEは、リモートPEへのPWステータスメッセージの送信のペースを調整する必要があります。

4. PW Status Refresh Reduction Message Encoding
4. PWステータスリフレッシュ削減メッセージエンコーディング

The packet containing the PW status refresh reduction Message is encoded as follows (omitting link-layer information):

PWステータスリフレッシュ削減メッセージを含むパケットは、次のようにエンコードされます(リンク層情報は省略)。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MPLS LSP (tunnel) Label Stack Entry             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              GAL                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|   Reserved    | 0x29 PW OAM Message           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Session ID           |         Ack Session ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Refresh Timer         |     Total Message Length      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Checksum              |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Last Received Sequence Number | Message Type  |U|C|   Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     Control Message Body                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

This message contains the following fields:

このメッセージには次のフィールドが含まれます。

* MPLS LSP (tunnel) Label Stack Entry

* MPLS LSP(トンネル)ラベルスタックエントリ

The label stack is explained in [RFC3031].

ラベルスタックは[RFC3031]で説明されています。

* GAL

* GAL

The G-ACh Label (GAL) and the next 4 octets (including the PW OAM Message field as the Channel Type) are explained in Section 2.1 of [RFC5586].

G-AChラベル(GAL)と次の4オクテット(チャネルタイプとしてPW OAMメッセージフィールドを含む)は、[RFC5586]のセクション2.1で説明されています。

* PW OAM Message

* PW OAMメッセージ

This field indicates the Channel Type in the G-ACh header, as described in Section 2.1 of [RFC5586].

[RFC5586]のセクション2.1で説明されているように、このフィールドはG-AChヘッダーのチャネルタイプを示します。

* Session ID

* セッションID

A non-zero locally selected session number that is not preserved if the local PE restarts.

ローカルPEを再起動しても保持されない、ゼロ以外のローカルに選択されたセッション番号。

In order to get a locally unique Session ID, the recommended choice is to perform a CRC-16 ("CRC" stands for "Cyclic Redundancy Check"), giving as input the following data:

ローカルで一意のセッションIDを取得するには、CRC-16(「CRC」は「巡回冗長検査」の略)を実行し、入力として次のデータを指定することをお勧めします。

|YY|MM|DD|HHMMSSLLL|

| YY | MM | DD | HHMMSSLLL |

Where: YY = the last two decimal digits of the current year MM = the two decimal digits of the current month DD = the two decimal digits of the current day HHMMSSLLL = the decimal digits of the current time, expressed in hours (HH), minutes (MM), seconds (SS), and milliseconds (LLL)

YY =現在の年の最後の2桁MM =現在の月の2桁の数字DD =現在の日の2桁の数字HHMMSSLLL =時間(HH)で表された現在の時刻の10進数分(MM)、秒(SS)、ミリ秒(LLL)

If the calculation results in an already-existing Session ID, a unique Session ID can be generated by adding 1 to the result until the Session ID is unique. Any other method to generate a locally unique Session ID is also acceptable.

計算の結果、既存のセッションIDが得られる場合は、セッションIDが一意になるまで結果に1を加えることにより、一意のセッションIDを生成できます。ローカルで一意のセッションIDを生成する他の方法も受け入れられます。

* Ack Session ID

* AckセッションID

The Acknowledgment Session ID received from the remote PE.

リモートPEから受信した確認応答セッションID。

* Refresh Timer

* タイマーを更新

A non-zero unsigned 16-bit integer value greater than or equal to 10, expressed in milliseconds, that indicates the desired refresh interval. The default value of 30000 is RECOMMENDED.

ミリ秒で表される、10以上のゼロ以外の符号なし16ビット整数値。これは、必要なリフレッシュ間隔を示します。デフォルト値の30000はRECOMMENDEDです。

* Total Message Length

* 合計メッセージ長

Total length in octets of the Checksum, Message Type, Flags, Message Sequence Number, and Control Message Body. A value of zero means that no control message is present and, therefore, that no Checksum or subsequent fields are present either.

チェックサム、メッセージタイプ、フラグ、メッセージシーケンス番号、および制御メッセージ本文のオクテット単位の全長。ゼロの値は、制御メッセージが存在しないこと、したがってチェックサムまたは後続のフィールドも存在しないことを意味します。

* Checksum

* チェックサム

A 16-bit field containing the one's complement of the one's complement sum of the entire message (including the G-ACh header), with the Checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. Note that when the checksum is not computed, the header of the bundle message will not be covered by any checksum.

メッセージ全体(G-AChヘッダーを含む)の1の補数の1の補数を含む16ビットフィールド。チェックサムを計算するために、チェックサムフィールドがゼロに置き換えられています。すべてゼロの値は、チェックサムが送信されなかったことを意味します。チェックサムが計算されない場合、バンドルメッセージのヘッダーはチェックサムの対象にはなりません。

* Message Sequence Number

* メッセージシーケンス番号

An unsigned 16-bit integer that is started from 1 when the protocol enters the ACTIVE state. The sequence number wraps back to 1 when the maximum value is reached. The value 0 is reserved and MUST NOT be used.

プロトコルがACTIVE状態になったときに1から始まる符号なし16ビット整数。最大値に達すると、シーケンス番号は1に戻ります。値0は予約されており、使用してはなりません。

* Last Received Message Sequence Number

* 最後に受信したメッセージのシーケンス番号

The sequence number of the last message received. If no message has yet been received during this session, this field is set to 0.

受信した最後のメッセージのシーケンス番号。このセッション中にまだメッセージが受信されていない場合、このフィールドは0に設定されます。

* Message Type

* メッセージタイプ

The type of control message that follows. Control message types are allocated in this document and by IANA.

後に続く制御メッセージのタイプ。制御メッセージタイプは、このドキュメントおよびIANAによって割り当てられます。

* (U) Unknown flag bit

* (U)不明なフラグビット

Upon receipt of an unknown message or TLV, if U is clear (0), a notification message with code "Unknown TLV (U-Bit=0)" (code 0x4) MUST be sent to the remote PE, and the keepalive session MUST be terminated by entering the STARTUP state; if U is set (1), the unknown message, or message containing an unknown TLV, MUST be acknowledged and silently ignored, and the following messages, or TLVs, if any, processed as if the unknown message or TLV did not exist. In this case, the PE MAY send back a single notification message per keepalive session with code "Unknown TLV (U-Bit=1)". This last step is OPTIONAL.

不明なメッセージまたはTLVの受信時に、Uがクリア(0)の場合、コード「Unknown TLV(U-Bit = 0)」(コード0x4)の通知メッセージをリモートPEに送信する必要があり、キープアライブセッションはSTARTUP状態に入ると終了します。 Uが設定されている場合(1)、不明なメッセージ、または不明なTLVを含むメッセージは確認され、黙って無視されなければならず、次のメッセージまたはTLVがある場合は、不明なメッセージまたはTLVが存在しないかのように処理されます。この場合、PEは、コード「Unknown TLV(U-Bit = 1)」を使用して、キープアライブセッションごとに単一の通知メッセージを送信できます(MAY)。この最後のステップはオプションです。

* (C) Configuration flag bit

* (C)構成フラグビット

The C-Bit is used to signal the end of PW configuration transmission. If it is set, the sending PE has finished sending all of its current configuration information.

Cビットは、PW構成の送信の終了を通知するために使用されます。設定されている場合、送信側PEは現在の構成情報の送信をすべて完了しています。

* Flags

* 旗

The remaining 6 bits of PW status refresh reduction Message Flags to be allocated by IANA. These unallocated bits MUST be set to 0 on transmission and ignored on reception.

IANAによって割り当てられるPWステータスリフレッシュ削減メッセージフラグの残りの6ビット。これらの未割り当てビットは送信時に0に設定されなければならず、受信時には無視されなければなりません。

* Control Message Body

* コントロールメッセージ本文

The Control Message Body is defined in Section 5 and is specific to the type of message.

制御メッセージ本文はセクション5で定義されており、メッセージのタイプに固有です。

It should be noted that the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and Control Message Body are OPTIONAL. The Total Message Length field is used to parse how many optional fields are included. Hence, all optional fields that precede a specific field that needs to be included in a specific implementation MUST be included if that optional field is also included.

チェックサム、メッセージシーケンス番号、最後に受信したメッセージシーケンス番号、メッセージタイプ、フラグ、および制御メッセージ本文はオプションであることに注意してください。 Total Message Lengthフィールドは、含まれるオプションフィールドの数を解析するために使用されます。したがって、特定の実装に含める必要がある特定のフィールドの前にあるすべてのオプションのフィールドは、そのオプションのフィールドも含まれている場合は、含まれている必要があります。

If any of the above values are outside the specified range, a notification message is returned with code "PW configuration not supported", and the message is ignored.

上記の値のいずれかが指定範囲外の場合、通知メッセージがコード「PW構成はサポートされていません」とともに返され、メッセージは無視されます。

5. PW Status Refresh Reduction Control Messages
5. PWステータスリフレッシュ削減制御メッセージ

PW status refresh reduction Control Messages consist of the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and Control Message Body.

PWステータスリフレッシュ削減制御メッセージは、チェックサム、メッセージシーケンス番号、最後に受信したメッセージシーケンス番号、メッセージタイプ、フラグ、および制御メッセージ本文で構成されます。

When a PW status refresh reduction Control Message needs to be sent, the system can attach it to a scheduled PW status refresh reduction Message or send one ahead of time. In any case, PW status refresh reduction Control Messages always piggyback on normal messages.

PWステータスリフレッシュ削減制御メッセージを送信する必要がある場合、システムはそれをスケジュールされたPWステータスリフレッシュ削減メッセージに添付するか、事前に送信できます。いずれの場合も、PWステータスリフレッシュ削減制御メッセージは常に通常のメッセージに便乗します。

A PW status refresh reduction Message is also called a PW status refresh reduction Control Message if it contains a control message construct.

PWステータスリフレッシュ削減メッセージは、制御メッセージ構造が含まれている場合、PWステータスリフレッシュ削減制御メッセージとも呼ばれます。

There can only be one control message construct per PW status refresh reduction Message. If the U-Bit is set and a PE receiving the PW status refresh reduction Message does not understand the control message, the control message MUST be silently ignored. However, the Message Sequence Number MUST still be acknowledged by sending a Null Notification message back with the appropriate value in the Last Message Received field. If a control message is not acknowledged after 3.5 times the value of the Refresh Timer, a fatal notification -- "Unacknowledged control message" -- MUST be sent, and the PW status refresh reduction session MUST be terminated.

PWステータスリフレッシュ削減メッセージごとに制御メッセージ構造は1つしかありません。 Uビットが設定され、PWステータスリフレッシュ削減メッセージを受信するPEが制御メッセージを理解できない場合、制御メッセージは黙って無視されなければなりません(MUST)。ただし、メッセージシーケンス番号は、最後に受信したメッセージフィールドに適切な値を含むNull通知メッセージを送信することにより、引き続き確認する必要があります。リフレッシュタイマーの値の3.5倍後にコントロールメッセージが確認されない場合、致命的な通知「未確認のコントロールメッセージ」を送信する必要があり、PWステータスリフレッシュ削減セッションを終了する必要があります。

If a PE does not want or need to send a control message, the Checksum and all subsequent fields MUST NOT be sent, and the Total Message Length field is then set to 0.

PEが制御メッセージを送信したくない、または送信する必要がない場合は、チェックサムおよび後続のすべてのフィールドを送信してはならず(MUST NOT)、Total Message Lengthフィールドは0に設定されます。

5.1. Notification Message
5.1. 通知メッセージ

The most common use of the notification message is to acknowledge the reception of a message by indicating the received Message Sequence Number in the Last Received Sequence Number field. The notification message is encoded as follows:

通知メッセージの最も一般的な使用法は、最後に受信したシーケンス番号フィールドに受信したメッセージシーケンス番号を示すことにより、メッセージの受信を確認することです。通知メッセージは次のようにエンコードされます。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Checksum              |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Last Received Sequence Number |  Type=0x01    |U|C|   Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Notification Code                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The message type is set to 0x01, and the U-Bit is treated as described in Section 4. The Notification Codes are 32-bit quantities assigned by IANA (see the IANA Considerations section). Notification codes are considered either "Error codes" or simple notifications. If the Notification Code is an Error code as indicated in the IANA allocation registry, the keepalive session MUST be terminated by entering the STARTUP state.

メッセージタイプは0x01に設定され、Uビットはセクション4で説明されているように扱われます。通知コードはIANAによって割り当てられた32ビットの数量です(IANAの考慮事項セクションを参照)。通知コードは、「エラーコード」または単純な通知と見なされます。 IANA割り当てレジストリに示されているように、通知コードがエラーコードである場合、キープアライブセッションは、STARTUP状態になることによって終了する必要があります。

When there is no notification information to be sent, the notification code is set to 0 to indicate a "Null Notification". The C-Bit MUST always be set to 0 in this type of message. The remaining 6 bits of PW status refresh reduction Message Flags are to be allocated by IANA. These unallocated bits MUST be set to 0 on transmission and ignored on reception.

送信する通知情報がない場合、通知コードは0に設定され、「Null通知」を示します。このタイプのメッセージでは、Cビットを常に0に設定する必要があります。 PWステータスリフレッシュ削減メッセージフラグの残りの6ビットは、IANAによって割り当てられます。これらの未割り当てビットは、送信時に0に設定し、受信時に無視する必要があります。

5.2. PW Configuration Message
5.2. PW構成メッセージ

The PW status refresh reduction TLVs are informational TLVs that allow the remote PE to verify certain provisioning information. This message contains a series of sub-TLVs, in no particular order, that contain PW and LSP configuration information. The message has no preset length limit; however, its total length will be limited by the transport network's Maximum Transmission Unit (MTU). PW status refresh reduction Messages MUST NOT be fragmented. If a sender has more configuration information to send than will fit into one PW Configuration Message, it may send additional messages carrying additional TLVs.

PWステータスリフレッシュ削減TLVは、リモートPEが特定のプロビジョニング情報を確認できるようにする情報TLVです。このメッセージには、PWおよびLSP構成情報を含む一連のサブTLVが特定の順序で含まれていません。メッセージには事前に設定された長さ制限はありません。ただし、その全長はトランスポートネットワークの最大伝送ユニット(MTU)によって制限されます。 PWステータスリフレッシュ削減メッセージは断片化してはいけません。送信者が1つのPW構成メッセージに収まらないより多くの構成情報を送信する場合、追加のTLVを運ぶ追加のメッセージを送信することがあります。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Checksum              |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Last Received Sequence Number |  Type=0x02    |U|C|   Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |                PW Configuration Message Sub-TLVs              |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The PW Configuration Message type is set to 0x02. For this message, the U-Bit is set to 1, as processing of these messages is OPTIONAL.

PW構成メッセージタイプは0x02に設定されます。このメッセージでは、これらのメッセージの処理はオプションであるため、Uビットは1に設定されます。

The C-Bit is used to signal the end of PW configuration transmission. If it is set, the sending PE has finished sending all of its current configuration information. The PE transmitting the configuration MUST set the C-Bit on the last PW Configuration Message when all current PW configuration information has been sent.

Cビットは、PW構成の送信の終了を通知するために使用されます。設定されている場合、送信側PEは現在の構成情報の送信をすべて完了しています。現在のすべてのPW構成情報が送信されたとき、構成を送信するPEは最後のPW構成メッセージにCビットを設定する必要があります。

PW Configuration Message sub-TLVs have the following generic format:

PW構成メッセージのサブTLVの一般的な形式は次のとおりです。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type        |  Length       |        Value                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |                      Value (Continued)                        |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
5.2.1. MPLS-TP Tunnel ID
5.2.1. MPLS-TPトンネルID

This TLV contains the MPLS-TP Tunnel ID ("MPLS-TP" stands for "MPLS Transport Profile"). When the configuration message is used for a particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be sent at least once.

このTLVには、MPLS-TPトンネルIDが含まれています(「MPLS-TP」は「MPLSトランスポートプロファイル」を表します)。構成メッセージが特定のキープアライブセッションに使用される場合、MPLS-TPトンネルIDサブTLVは少なくとも1回送信される必要があります。

The MPLS-TP Tunnel ID is encoded as follows:

MPLS-TPトンネルIDは次のようにエンコードされます。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=0x01   |  Length=20    |      MPLS-TP Tunnel ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |           MPLS-TP Tunnel ID (Continued) (20 octets)           |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The MPLS point-to-point tunnel ID is defined in [RFC6370]. The coding used by the node that is the source of a message is:

MPLSポイントツーポイントトンネルIDは、[RFC6370]で定義されています。メッセージのソースであるノードが使用するコーディングは次のとおりです。

      Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
      Dst-Tunnel_Num
        

Note that a single tunnel ID is enough to identify the tunnel and the source end of the message.

トンネルとメッセージのソース側を識別するには、単一のトンネルIDで十分です。

5.2.2. PW ID Configured List
5.2.2. PW ID構成済みリスト

This OPTIONAL sub-TLV contains a list of the provisioned PWs on the LSP.

このオプションのサブTLVには、LSPでプロビジョニングされたPWのリストが含まれています。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=0x02   |    Length     |         PW Path ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      PW Path ID (Continued)                   |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The PW Path ID is a 32-octet PW path identifier [RFC6370]. The coding used by the node that is the source of a message is:

PWパスIDは、32オクテットのPWパス識別子です[RFC6370]。メッセージのソースであるノードが使用するコーディングは次のとおりです。

      AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
      Dst-Global_ID::Dst-Node_ID::Dst-AC_ID
        

The number of PW Path IDs in the TLV will be inferred by the length of the TLV, up to a maximum of 8. The procedure for processing this TLV will be described in Section 6.

TLVのPWパスIDの数は、最大8までのTLVの長さから推測されます。このTLVを処理する手順については、セクション6で説明します。

5.2.3. PW ID Unconfigured List
5.2.3. PW ID未構成リスト

This OPTIONAL sub-TLV contains a list of the PWs that have been deprovisioned on the LSP. Note that sending the same PW address in both the PW ID Configured List sub-TLV and the PW ID Unconfigured List sub-TLV in the same configuration message constitutes a fatal session error. If this error occurs, an error notification message is returned with the Error code "PW Configuration TLV conflict", and the session is terminated by entering the STARTUP state.

このOPTIONALサブTLVには、LSPでデプロビジョニングされたPWのリストが含まれています。同じ構成メッセージでPW ID構成済みリストサブTLVとPW ID未構成リストサブTLVの両方で同じPWアドレスを送信すると、致命的なセッションエラーが発生することに注意してください。このエラーが発生すると、エラー通知メッセージがエラーコード「PW Configuration TLV conflict」とともに返され、セッションはSTARTUP状態になることによって終了します。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=0x03   |    Length     |         PW Path ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      PW Path ID (Continued)                   |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The PW Path ID is a 32-octet PW path identifier as defined in Section 5.2.2.

PWパスIDは、セクション5.2.2で定義されている32オクテットのPWパス識別子です。

The number of PW Path IDs in the TLV will be inferred by the length of the TLV, up to a maximum of 8.

TLV内のPWパスIDの数は、最大8までのTLVの長さから推測されます。

6. PW Provisioning Verification Procedure
6. PWプロビジョニング検証手順

The advertisement of the PW Configuration Message is OPTIONAL.

PW構成メッセージの通知はオプションです。

A PE that desires to use the PW Configuration Message to verify the configuration of PWs on a particular LSP should advertise its PW configuration to the remote PE on LSPs that have active keepalive sessions. When a PE receives PW configuration information using this protocol and it does not support processing the information or is not willing to process it, it MUST acknowledge all the PW Configuration Messages with the notification code "PW configuration not supported". In this case, the information in the PW Configuration Message is silently ignored. If a PE receives such a notification, it SHOULD stop sending PW Configuration Messages for the duration of the PW status refresh reduction keepalive session.

PW設定メッセージを使用して特定のLSP上のPWの設定を確認する必要があるPEは、アクティブなキープアライブセッションを持つLSP上のリモートPEにそのPW設定をアドバタイズする必要があります。 PEがこのプロトコルを使用してPW構成情報を受信し、その情報の処理をサポートしていない、または処理する意思がない場合、PEは通知コード「PW configuration not supported」ですべてのPW構成メッセージを確認する必要があります。この場合、PW構成メッセージの情報は無視されます。 PEがそのような通知を受信した場合、PWステータスリフレッシュ削減キープアライブセッションの間、PW構成メッセージの送信を停止する必要があります。

If PW configuration information is received, it is used to verify the accuracy of the local configuration information against the remote PE's configuration information. If a configuration mismatch is detected, where a particular PW is configured locally but not on the remote PE, the following actions SHOULD be taken:

PW構成情報が受信されると、それは、リモートPEの構成情報に対するローカル構成情報の正確さを検証するために使用されます。特定のPWがローカルに構成されているがリモートPEには構成されていない構成の不一致が検出された場合、次のアクションを実行する必要があります。

i. The local PW MUST be considered in "Not Forwarding" state (Section 6.3.2 of [RFC8077]).

i. ローカルPWは「転送しない」状態([RFC8077]のセクション6.3.2)であると見なす必要があります。

ii. The PW Attachment Circuit status is set to reflect the PW fault.

ii。 PW接続回路のステータスは、PW障害を反映するように設定されています。

iii. An alarm SHOULD be raised to a network management system.

iii。アラームはネットワーク管理システムに送られる必要があります。

iv. A notification message with the notification code "PW configuration mismatch" MUST be sent to the remote PE. Only one such message is REQUIRED per configuration message even if the configuration message is split into multiple configuration messages due to individual message-size restrictions on a particular link. Upon receipt of such a message, the receiving PE MAY raise an alarm to a network management system. This alarm MAY be cleared when the configuration is updated.

iv。通知コード「PW構成の不一致」を含む通知メッセージをリモートPEに送信する必要があります。特定のリンクの個々のメッセージサイズの制限により、構成メッセージが複数の構成メッセージに分割されている場合でも、構成メッセージごとに必要なメッセージは1つだけです。そのようなメッセージを受信すると、受信側PEはネットワーク管理システムにアラームを発生させる場合があります。このアラームは、設定が更新されたときにクリアされる場合があります。

6.1. PW ID List Advertising and Processing
6.1. PW IDリストの広告と処理

When configuration messages are advertised on a particular LSP, the PE sending the messages needs to checkpoint the configuration information sent by setting the C-Bit when all currently known configuration information has been sent. This process allows the receiving PE to immediately proceed to verify all the currently configured PWs on that LSP, eliminating the need for a long waiting period.

構成メッセージが特定のLSPでアドバタイズされると、メッセージを送信するPEは、現在既知の構成情報がすべて送信されたときに、Cビットを設定して送信された構成情報にチェックポイントを設定する必要があります。このプロセスにより、受信側PEはすぐにそのLSPで現在設定されているすべてのPWの確認に進むことができ、長い待機期間の必要がなくなります。

If a new PW is added to a particular LSP, the PE MUST place the configuration verification of this PW on hold for a period of at least 30 seconds. This is necessary to minimize false-positive events of misconfiguration due to the ends of the PW being slightly out of sync.

新しいPWが特定のLSPに追加された場合、PEはこのPWの構成検証を少なくとも30秒間ホールドする必要があります。これは、PWの両端がわずかに同期していないために発生する誤設定の誤検知イベントを最小限に抑えるために必要です。

7. Security Considerations
7. セキュリティに関する考慮事項

The security considerations discussed in [RFC6478] are adequate for the mechanism described in this document, since the operating environment is almost identical to the one where this protocol would be deployed. It should also be noted that since this protocol is designed to be deployed between two adjacent PEs connected by a physical link, it is not possible to misdirect or inject traffic without compromising the PW transport link itself.

[RFC6478]で説明されているセキュリティの考慮事項は、動作環境がこのプロトコルが展開される環境とほぼ同じであるため、このドキュメントで説明されているメカニズムには適切です。また、このプロトコルは物理リンクで接続された2つの隣接するPEの間に配置されるように設計されているため、PWトランスポートリンク自体を危険にさらすことなく、トラフィックを誤って送信したり注入したりすることはできません。

8. IANA Considerations
8. IANAに関する考慮事項

The registries in this section have been created or updated as appropriate in the "Pseudowire Name Spaces (PWE3)" registry or the "Generic Associated Channel (G-ACh) Parameters" registry. For the allocation ranges designated as "vendor-proprietary extensions", the respective IANA registry contains the vendor name in brackets at the end of the Description field.

このセクションのレジストリは、「Pseudowire Name Spaces(PWE3)」レジストリまたは「Generic Associated Channel(G-ACh)Parameters」レジストリで適切に作成または更新されています。 「ベンダー独自の拡張機能」として指定された割り当て範囲の場合、それぞれのIANAレジストリの[説明]フィールドの末尾に括弧で囲まれたベンダー名が含まれています。

8.1. PW Status Refresh Reduction Message Types
8.1. PWステータスリフレッシュ削減メッセージタイプ

IANA has set up the "PW Status Refresh Reduction Control Messages" registry. This registry contains 8-bit values. Type values 1 and 2 are defined in this document. Type values 3 through 64 and 128 through 254 are to be assigned by IANA using the "Expert Review" policy defined in [RFC8126]. Type values 65 through 127, 0, and 255 are to be allocated using the "IETF Review" policy defined in [RFC8126].

IANAは「PWステータスリフレッシュ削減制御メッセージ」レジストリを設定しました。このレジストリには8ビット値が含まれています。このドキュメントでは、タイプ値1と2が定義されています。タイプ値3〜64および128〜254は、[RFC8126]で定義されている「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられます。タイプ値65〜127、0、および255は、[RFC8126]で定義されている「IETFレビュー」ポリシーを使用して割り当てられます。

The Type values are assigned as follows:

タイプの値は次のように割り当てられます。

      Type   Message Description
      ----   ------------------------
      0x01   Notification message
      0x02   PW Configuration Message
        
8.2. PW Configuration Message Sub-TLVs
8.2. PW構成メッセージのサブTLV

IANA has set up the "PW Status Refresh Reduction Configuration Message Sub-TLVs" registry. This registry contains 8-bit values. Type values 1 through 3 are defined in this document. Type values 4 through 64 and 128 through 254 are to be assigned by IANA using the "Expert Review" policy defined in [RFC8126]. Type values 65 through 127, 0, and 255 are to be allocated using the "IETF Review" policy defined in [RFC8126].

IANAは、「PWステータスリフレッシュ削減構成メッセージサブTLV」レジストリをセットアップしました。このレジストリには8ビット値が含まれています。このドキュメントでは、タイプ値1〜3が定義されています。タイプ値4〜64および128〜254は、[RFC8126]で定義されている「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられます。タイプ値65〜127、0、および255は、[RFC8126]で定義されている「IETFレビュー」ポリシーを使用して割り当てられます。

The Type values are assigned as follows:

タイプの値は次のように割り当てられます。

      Sub-TLV Type    Description
      ------------    -----------------------
      0x01            MPLS-TP Tunnel ID
      0x02            PW ID Configured List
      0x03            PW ID Unconfigured List
        
8.3. PW Status Refresh Reduction Notification Codes
8.3. PWステータスリフレッシュ削減通知コード

IANA has set up the "PW Status Refresh Reduction Notification Codes" registry. This registry contains 32-bit values. Type values 0 through 7 are defined in this document. Type values 8 through 65536 and 134,217,729 through 4,294,967,294 are to be assigned by IANA using the "Expert Review" policy defined in [RFC8126]. Type values 65537 through 134,217,728, 0, and 4,294,967,295 are to be allocated using the "IETF Review" policy defined in [RFC8126].

IANAは「PWステータスリフレッシュ削減通知コード」レジストリを設定しました。このレジストリには32ビット値が含まれています。このドキュメントでは、タイプ値0〜7が定義されています。タイプ値8〜65536および134,217,729〜4,294,967,294は、[RFC8126]で定義されている「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられます。タイプ値65537〜134,217,728、0、および4,294,967,295は、[RFC8126]で定義されている「IETFレビュー」ポリシーを使用して割り当てられます。

For each value assigned, IANA should also track whether the value constitutes an error as described in Section 5.1. When values are assigned by IETF Review, the settings in the "Error?" column must be documented in the RFC that requests the allocation. For "Expert Review" assignments, the settings in the "Error?" column must be made clear by the requester at the time of assignment.

割り当てられた値ごとに、IANAは、セクション5.1で説明されているように、値がエラーを構成するかどうかも追跡する必要があります。 IETFレビューによって値が割り当てられると、「エラー?」の設定列は、割り当てを要求するRFCに文書化されている必要があります。 「エキスパートレビュー」の割り当ての場合、「エラー?」の設定列は、割り当て時に要求者が明確にする必要があります。

The Type values are assigned as follows:

タイプの値は次のように割り当てられます。

      Code          Error?    Description
      ----------    ------    ------------------------------
      0x00000000    No        Null Notification
      0x00000001    No        PW configuration mismatch
      0x00000002    Yes       PW Configuration TLV conflict
      0x00000003    No        Unknown TLV (U-Bit=1)
      0x00000004    Yes       Unknown TLV (U-Bit=0)
      0x00000005    No        Unknown Message Type
      0x00000006    No        PW configuration not supported
      0x00000007    Yes       Unacknowledged control message
        
8.4. PW Status Refresh Reduction Message Flags
8.4. PWステータスリフレッシュ削減メッセージフラグ

IANA has set up the "PW Status Refresh Reduction Message Flags" registry. This is an 8-bit registry, with the first two most significant bits allocated by this document as follows:

IANAは「PWステータスリフレッシュ削減メッセージフラグ」レジストリを設定しました。これは8ビットのレジストリで、このドキュメントで最初の2つの最上位ビットが次のように割り当てられています。

      Bit Position  Name    Description
      ------------  ----    ----------------------
           0        U       Unknown flag bit
           1        C       Configuration flag bit
        

The remaining bits are to be allocated using the "IETF Review" policy defined in [RFC8126].

残りのビットは、[RFC8126]で定義されている「IETFレビュー」ポリシーを使用して割り当てられます。

8.5. G-ACh Registry Allocation
8.5. G-AChレジストリの割り当て

IANA maintains a registry called "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)". IANA has allocated a new value as follows:

IANAは、「MPLS Generalized Associated Channel(G-ACh)Types(Pseudowire Associated Channel Types)」と呼ばれるレジストリを維持しています。 IANAは次のように新しい値を割り当てました。

      Value     Description                     Reference
      -----     ---------------------------     ---------
      0x29      PW Status Refresh Reduction     RFC 8237
        
8.6. Guidance for Designated Experts
8.6. 指定専門家のためのガイダンス

In all cases of review by the Designated Expert (DE) described here, the DE is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and to verify that the document is permanently and publicly available. The DE is also expected to check that the clarity of purpose and use of the requested code points fit the general architecture and intended purpose of the respective message or TLV. Lastly, the DE should check that any assignment does not duplicate or conflict with work that is active or already published within the IETF.

ここで説明されている指定専門家(DE)によるレビューのすべての場合において、DEは、[RFC8126]で説明されている適切な文書(仕様)の存在を確認し、その文書が永続的かつ一般に入手可能であることを確認する必要があります。 DEは、目的の明確さと要求されたコードポイントの使用が、それぞれのメッセージまたはTLVの一般的なアーキテクチャと意図された目的に適合することを確認することも期待されています。最後に、DEは、割り当てが、IETF内でアクティブまたは既に公開されている作業と重複または競合していないことを確認する必要があります。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[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>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。

[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <https://www.rfc-editor.org/info/rfc6370>.

[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile(MPLS-TP)Identifiers」、RFC 6370、DOI 10.17487 / RFC6370、2011年9月、<https://www.rfc- editor.org/info/rfc6370>。

[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, DOI 10.17487/RFC6478, May 2012, <https://www.rfc-editor.org/info/rfc6478>.

[RFC6478]マティーニ、L。、スワロー、G。、ヘロン、G。、およびM.ボッチ、「静的な疑似配線の疑似配線ステータス」、RFC 6478、DOI 10.17487 / RFC6478、2012年5月、<https://www.rfc -editor.org/info/rfc6478>。

[RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.

[RFC8077] Martini、L.、Ed。、and G. Heron、Ed。、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol(LDP)"、STD 84、RFC 8077、DOI 10.17487 / RFC8077、February 2017、<https ://www.rfc-editor.org/info/rfc8077>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]綿、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https:// www .rfc-editor.org / info / rfc8126>。

[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>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

9.2. Informative References
9.2. 参考引用

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.

[RFC5586] Bocci、M。、編、Vigoureux、M、編、およびS. Bryant、編、「MPLS Generic Associated Channel」、RFC 5586、DOI 10.17487 / RFC5586、2009年6月、<https:// www.rfc-editor.org/info/rfc5586>。

Authors' Addresses

著者のアドレス

Luca Martini Monoski LLC

ルカ・マルティーニ・モノスキーLLC

   Email: lmartini@monoski.com
        

George Swallow Southend Technical Center

ジョージスワローサウスエンドテクニカルセンター

   Email: swallow.ietf@gmail.com
        

Elisa Bellagamba Ericsson EAB Torshamnsgatan 48 16480, Stockholm Sweden

Elisa Bellagamba Ericsson EAB Torshamnsgatan 48 16480、ストックホルムスウェーデン

   Email: elisa.bellagamba@gmail.com