[要約] RFC 8232は、状態を持つPCEのためのラベルスイッチパスの状態同期手順の最適化に関するものです。このRFCの目的は、状態同期の効率を向上させるための手順を提案することです。
Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8232 Oracle
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
J. Medved
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
X. Zhang
D. Dhody
Huawei Technologies
September 2017
Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE
ステートフルPCEのラベルスイッチドパス状態同期手順の最適化
Abstract
概要
A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.
ステートフルパス計算要素（PCE）は、ネットワークのInterior Gateway Protocol（IGP）によって配布された情報だけでなく、アクティブパスのセットとその計算用に予約されているリソースにもアクセスできます。追加のラベルスイッチドパス（LSP）状態情報により、PCEは個別のLSPとその相互作用を考慮しながら、制約されたパスを計算できます。これには、PCEとネットワーク、PCEとパス計算クライアント（PCC）、および協調PCEの間の状態同期メカニズムが必要です。状態同期の基本メカニズムは、ステートフルPCE仕様の一部です。このドキュメントでは、基本状態同期手順を最適化する動機を示し、必要なパス計算要素通信プロトコル（PCEP）拡張を指定します。
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/rfc8232.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8232で入手できます。
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 ....................................................4
1.1. Requirements Language ......................................4
2. Terminology .....................................................5
3. State Synchronization Avoidance .................................5
3.1. Motivation .................................................5
3.2. State Synchronization Avoidance Procedure ..................5
3.2.1. IP Address Change during Session Re-establishment ..10
3.3. PCEP Extensions ...........................................11
3.3.1. LSP-DB Version Number TLV ..........................11
3.3.2. Speaker Entity Identifier TLV ......................12
4. Incremental State Synchronization ..............................13
4.1. Motivation ................................................13
4.2. Incremental Synchronization Procedure .....................14
5. PCE-Triggered Initial Synchronization ..........................17
5.1. Motivation ................................................17
5.2. PCE-Triggered Initial State Synchronization Procedure .....18
6. PCE-Triggered Resynchronization ................................19
6.1. Motivation ................................................19
6.2. PCE-Triggered State Resynchronization Procedure ...........19
7. Advertising Support of Synchronization Optimizations ...........20
8. IANA Considerations ............................................21
8.1. PCEP-Error Object .........................................21
8.2. PCEP TLV Type Indicators ..................................22
8.3. STATEFUL-PCE-CAPABILITY TLV ...............................22
9. Manageability Considerations ...................................22
9.1. Control of Function and Policy ............................22
9.2. Information and Data Models ...............................22
9.3. Liveness Detection and Monitoring .........................23
9.4. Verify Correct Operations .................................23
9.5. Requirements on Other Protocols ...........................23
9.6. Impact on Network Operations ..............................23
10. Security Considerations .......................................23
11. References ....................................................24
11.1. Normative References .....................................24
11.2. Informative References ...................................24
Acknowledgments ...................................................25
Contributors ......................................................25
Authors' Addresses ................................................26
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
パス計算要素通信プロトコル（PCEP）は、パス計算要素（PCE）がパス計算クライアント（PCC）要求に応答してパス計算を実行するためのメカニズムを提供します。
[RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and the PCC, and cooperating PCEs. [RFC8231] describes the basic mechanism for State Synchronization. This document specifies following optimizations for State Synchronization and the corresponding PCEP procedures and extensions:
[RFC8231]は、ステートフルコントロールを提供するPCEPの一連の拡張機能について説明しています。ステートフルPCEは、ネットワークのInterior Gateway Protocol（IGP）によって伝達される情報だけでなく、アクティブパスのセットとその計算用に予約されているリソースにもアクセスできます。追加の状態により、PCEは個別のLSPとその相互作用を考慮しながら、制約されたパスを計算できます。これには、PCEとネットワーク、PCEとPCC、および連携するPCE間の状態同期メカニズムが必要です。 [RFC8231]は、状態同期の基本的なメカニズムを説明しています。このドキュメントでは、状態同期とそれに対応するPCEPの手順と拡張機能について、次の最適化を指定しています。
o State Synchronization Avoidance: To skip State Synchronization if the state has survived and not changed during session restart. (See Section 3.)
o 状態同期の回避：状態が存続し、セッションの再起動中に変更されていない場合は、状態同期をスキップします。 （セクション3を参照。）
o Incremental State Synchronization: To do incremental (delta) State Synchronization when possible. (See Section 4.)
o 増分状態同期：可能な場合、増分（デルタ）状態同期を実行します。 （セクション4を参照。）
o PCE-Triggered Initial Synchronization: To let PCE control the timing of the initial State Synchronization. (See Section 5.)
o PCEによってトリガーされる初期同期：PCEに初期状態同期のタイミングを制御させます。 （セクション5を参照。）
o PCE-Triggered Resynchronization: To let PCE resynchronize the state for sanity check. (See Section 6.)
o PCEトリガーによる再同期：PCEが状態チェックのために状態を再同期できるようにします。 （セクション6を参照。）
Support for each of the synchronization optimization capabilities is advertised during the PCEP initialization phase. See Section 7 for the new flags defined in this document. The handling of each flag is described in the relevant section.
PCEPの初期化フェーズ中に、各同期最適化機能のサポートが通知されます。このドキュメントで定義されている新しいフラグについては、セクション7を参照してください。各フラグの処理については、関連するセクションで説明しています。
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]で説明されているように解釈されます。
This document uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP Peer.
このドキュメントでは、[RFC5440]で定義されているPCC、PCE、PCEPピアという用語を使用しています。
This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation, and LSP State Database (LSP-DB).
このドキュメントでは、[RFC8051]で定義されている次の用語を使用しています。ステートフルPCE、委任、およびLSP状態データベース（LSP-DB）。
This document uses the following terms defined in [RFC8231]: Redelegation Timeout Interval, LSP State Report, and LSP Update Request.
このドキュメントでは、[RFC8231]で定義されている次の用語を使用します。再委任タイムアウト間隔、LSP状態レポート、およびLSP更新要求。
Within this document, when describing PCE-PCE communications, the requesting PCE fills the role of a PCC as usual.
このドキュメントでは、PCE-PCE通信について説明する場合、要求するPCEが通常どおりPCCの役割を果たします。
The purpose of State Synchronization is to provide a checkpoint-in-time state replica of a PCC's LSP state in a stateful PCE. State Synchronization is performed immediately after the initialization phase [RFC5440]. [RFC8231] describes the basic mechanism for State Synchronization.
状態同期の目的は、ステートフルPCEでPCCのLSP状態のチェックポイントインタイム状態レプリカを提供することです。状態同期は、初期化フェーズの直後に実行されます[RFC5440]。 [RFC8231]は、状態同期の基本的なメカニズムを説明しています。
State Synchronization is not always necessary following a PCEP session restart. If the state of both PCEP peers did not change, the synchronization phase may be skipped. This can result in significant savings in both control-plane data exchanges and the time it takes for the stateful PCE to become fully operational.
PCEPセッションの再起動後、状態の同期は常に必要なわけではありません。両方のPCEPピアの状態が変化しなかった場合、同期フェーズはスキップされる可能性があります。これにより、コントロールプレーンのデータ交換と、ステートフルPCEが完全に機能するようになるまでの時間の両方を大幅に節約できます。
State Synchronization MAY be skipped following a PCEP session restart if the state of both PCEP peers did not change during the period prior to session re-initialization. To be able to make this determination, state must be exchanged and maintained by both PCE and PCC during normal operation. This is accomplished by keeping track of the changes to the LSP-DB, using a version tracking field called the LSP-DB Version Number.
セッションの再初期化前の期間中に両方のPCEPピアの状態が変化しなかった場合、PCEPセッションの再起動後に状態同期がスキップされる場合があります。この決定を行うことができるようにするには、通常の操作中にPCEとPCCの両方で状態を交換して維持する必要があります。これは、LSP-DBバージョン番号と呼ばれるバージョン追跡フィールドを使用して、LSP-DBへの変更を追跡することによって実現されます。
The INCLUDE-DB-VERSION (S) bit in the STATEFUL-PCE-CAPABILITY TLV (Section 7) is advertised on a PCEP session during session startup to indicate that the LSP-DB Version Number is to be included when the LSPs are reported to the PCE. The LSP-DB Version Number, carried in LSP-DB-VERSION TLV (see Section 3.3.1), is owned by a PCC, and it MUST be incremented by 1 for each successive change in the PCC's LSP-DB. The LSP-DB Version Number MUST start at 1 and may wrap around.
STATEFUL-PCE-CAPABILITY TLV（セクション7）のINCLUDE-DB-VERSION（S）ビットは、セッションの起動中にPCEPセッションでアドバタイズされ、LSPが報告されたときにLSP-DBバージョン番号が含まれることを示します。 PCE。 LSP-DB-VERSION TLV（セクション3.3.1を参照）で運ばれるLSP-DBバージョン番号はPCCによって所有され、PCCのLSP-DBで連続する変更ごとに1ずつインクリメントされる必要があります。 LSP-DBバージョン番号は1から開始する必要があり、ラップアラウンドする場合があります。
Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of the two values are used during LSP State (re)Synchronization, the PCE speaker receiving this value MUST send back a PCEP Error (PCErr) with Error-type=20 and Error-value=6 'Received an invalid LSP-DB Version Number', and close the PCEP session. Operations that trigger a change to the local LSP-DB include a change in the LSP operational state, delegation of an LSP, removal or setup of an LSP, or change in any of the LSP attributes that would trigger a report to the PCE.
値0および0xFFFFFFFFFFFFFFFFは予約済みです。 LSP状態（再）同期中に2つの値のいずれかが使用される場合、この値を受信するPCEスピーカーは、Error-type = 20およびError-value = 6のPCEPエラー（PCErr）を返送する必要があります '無効なLSP-DBを受信しましたバージョン番号」をクリックし、PCEPセッションを閉じます。ローカルLSP-DBへの変更をトリガーする操作には、LSP動作状態の変更、LSPの委任、LSPの削除またはセットアップ、またはPCEへのレポートをトリガーするLSP属性の変更が含まれます。
If the include LSP-DB version capability is enabled, a PCC MUST increment its LSP-DB Version Number when the 'Redelegation Timeout Interval' timer expires (see [RFC8231] for the use of the Redelegation Timeout Interval).
LSP-DBバージョンを含める機能が有効になっている場合、PCCは「再委任タイムアウト間隔」タイマーの期限が切れたときにLSP-DBバージョン番号をインクリメントする必要があります（再委任タイムアウト間隔の使用については[RFC8231]を参照）。
If both PCEP speakers set the S flag in the OPEN object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV in each LSP object of the Path Computation LSP State Report (PCRpt) message. If the LSP-DB-VERSION TLV is missing in a PCRpt message, the PCE will generate an error with Error-type=6 (Mandatory Object missing) and Error-value=12 'LSP-DB-VERSION TLV missing', and close the session. If the include LSP-DB version capability has not been enabled on a PCEP session, the PCC SHOULD NOT include the LSP-DB-VERSION TLV in the LSP Object, and the PCE MUST ignore it, were it to receive one.
両方のPCEPスピーカーがOPENオブジェクトのSTATEFUL-PCE-CAPABILITY TLVのSフラグを1に設定した場合、PCCはパス計算LSP状態レポート（PCRpt）メッセージの各LSPオブジェクトにLSP-DB-VERSION TLVを含める必要があります。 LSP-DB-VERSION TLVがPCRptメッセージにない場合、PCEはError-type = 6（Mandatory Object missing）およびError-value = 12 'LSP-DB-VERSION TLV missing'のエラーを生成し、閉じます。セッション。 PCSPセッションでLSP-DBバージョンのインクルード機能が有効になっていない場合、PCCはLSPオブジェクトにLSP-DB-VERSION TLVを含めるべきではなく（SHOULD NOT）、PCEはそれを受信する場合は無視する必要があります（MUST）。
If a PCE's LSP-DB survived the restart of a PCEP session, the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and the TLV will contain the last LSP-DB Version Number received on an LSP State Report from the PCC in the previous PCEP session. If a PCC's LSP-DB survived the restart of a PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN object, and the TLV will contain the latest LSP-DB Version Number. If a PCEP speaker's LSP-DB did not survive the restart of a PCEP session or at startup when the database is empty, the PCEP speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN object.
PCEのLSP-DBがPCEPセッションの再開後も存続した場合、PCEはLSP-DB-VERSION TLVをOPENオブジェクトに含め、TLVはLSP状態レポートで受信した最後のLSP-DBバージョン番号を含みます。前のPCEPセッションのPCC。 PCCのLSP-DBがPCEPセッションの再開後も存続した場合、PCCはLSP-DB-VERSION TLVをOPENオブジェクトに含め、TLVには最新のLSP-DBバージョン番号が含まれます。 PCEPスピーカーのLSP-DBがPCEPセッションの再起動後、またはデータベースが空の起動時に存続しなかった場合、PCEPスピーカーはLSP-DB-VERSION TLVをOPENオブジェクトに含めてはなりません（MUST NOT）。
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN object and the TLV values match, the PCC MAY skip State Synchronization, and the PCE does not wait for the end-of-synchronization marker [RFC8231]. Otherwise, the PCC MUST perform full State Synchronization (see [RFC8231]) or incremental State Synchronization (see Section 4 if this capability is advertised) to the stateful PCE. In other words, if the incremental State Synchronization capability is not advertised by the peers, based on the LSP-DB Version Number match, either the State Synchronization is skipped or a full State Synchronization is performed. If the PCC attempts to skip State Synchronization, by setting the SYNC flag to 0 and PLSP-ID to a non-zero value on the first LSP State Report from the PCC as per [RFC8231], the PCE MUST send back a PCErr with Error-type=20 and Error-value=2 'LSP-DB version mismatch', and close the PCEP session.
両方のPCEPスピーカーがOPENオブジェクトにLSP-DB-VERSION TLVを含み、TLV値が一致する場合、PCCは状態同期をスキップでき、PCEは同期終了マーカー[RFC8231]を待ちません。それ以外の場合、PCCはステートフルPCEに対して完全な状態同期（[RFC8231]を参照）または増分状態同期（この機能がアドバタイズされている場合はセクション4を参照）を実行する必要があります。つまり、LSP-DBバージョン番号の一致に基づいて、増分状態同期機能がピアによってアドバタイズされない場合、状態同期がスキップされるか、完全な状態同期が実行されます。 PCCが[RFC8231]に従ってPCCからの最初のLSP状態レポートでSYNCフラグを0に設定し、PLSP-IDをゼロ以外の値に設定することで状態同期をスキップしようとした場合、PCEはエラーのあるPCErrを返送する必要があります-type = 20およびError-value = 2 'LSP-DBバージョンの不一致'、PCEPセッションを閉じます。
If State Synchronization is required, then prior to completing the initialization phase, the PCE MUST mark any LSPs in the LSP-DB that were previously reported by the PCC as stale. When the PCC reports an LSP during State Synchronization, if the LSP already exists in the LSP-DB, the PCE MUST update the LSP-DB and clear the stale marker from the LSP. When it has finished State Synchronization, the PCC MUST immediately send an end-of-synchronization marker. The end-of-synchronization marker is a PCRpt message with an LSP object containing a PLSP-ID of 0 and with the SYNC flag set to 0 [RFC8231]. The LSP-DB-VERSION TLV MUST be included in this PCRpt message. On receiving this state report, the PCE MUST purge any LSPs from the LSP-DB that are still marked as stale.
状態同期が必要な場合、初期化フェーズを完了する前に、PCEは、以前にPCCによって古いと報告されたLSP-DB内のLSPをマークする必要があります。 PCCが状態同期中にLSPを報告するとき、LSPがすでにLSP-DBに存在する場合、PCEはLSP-DBを更新し、LSPから古いマーカーをクリアする必要があります。状態の同期が完了すると、PCCは直ちに同期終了マーカーを送信する必要があります。同期終了マーカーは、PLSP-IDが0で、SYNCフラグが0に設定されたLSPオブジェクトを含むPCRptメッセージです[RFC8231]。 LSP-DB-VERSION TLVは、このPCRptメッセージに含まれている必要があります。この状態レポートを受信すると、PCEは、古いとしてマークされているLSPをLSP-DBから削除する必要があります。
Note that a PCE/PCC MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object.
PCE / PCCは、そのOPENオブジェクトにLSP-DB-VERSION TLVを含めないことで、状態同期を強制できることに注意してください。
Since a PCE does not make changes to the LSP-DB Version Number, a PCC should never encounter this TLV in a message from the PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB-VERSION TLV, were it to receive one from a PCE.
PCEはLSP-DBバージョン番号を変更しないため、PCCは、PCEからのメッセージ（OPENメッセージ以外）でこのTLVに遭遇することはありません。 PCCは、LSE-DB-VERSION TLVを無視する必要があります（PCEから受信する場合）。
Figure 1 shows an example sequence where the State Synchronization is skipped.
図1は、状態同期がスキップされたシーケンスの例を示しています。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| S=1 \ / DBv=42 |
| \/ S=1 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
| |
|--PCRpt,DBv=43,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->|
| |
Figure 1: State Synchronization Skipped
図1：スキップされた状態同期
Figure 2 shows an example sequence where the State Synchronization is performed due to LSP-DB version mismatch during the PCEP session setup. Note that the same State Synchronization sequence would happen if either the PCC or the PCE would not include the LSP-DB-VERSION TLV in their respective Open messages.
図2は、PCEPセッションのセットアップ中にLSP-DBバージョンの不一致が原因で状態同期が実行されるシーケンスの例を示しています。 PCCまたはPCEがそれぞれのOpenメッセージにLSP-DB-VERSION TLVを含めない場合、同じ状態同期シーケンスが発生することに注意してください。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| S=1 \ / DBv=42 |
| \/ S=1 |
| /\ |
| / `-------->| (Expect sync)
(Do sync) |<--------` |
| |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done)
| . | (Purge LSP state
| . | if applicable)
| . |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 2: State Synchronization Performed
図2：実行された状態同期
Figure 3 shows an example sequence where the State Synchronization is skipped, but because one or both PCEP speakers set the S flag to 0, the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt messages to the PCE. If the current PCEP session restarts, the PCEP speakers will have to perform State Synchronization, since the PCE does not know the PCC's latest LSP-DB Version Number information.
図3は、状態同期がスキップされたシーケンスの例を示していますが、一方または両方のPCEPスピーカーがSフラグを0に設定しているため、PCCは後続のPCRptメッセージでLSP-DB-VERSION TLVをPCEに送信しません。現在のPCEPセッションが再開した場合、PCEはPCCの最新のLSP-DBバージョン番号情報を認識していないため、PCEPスピーカーは状態同期を実行する必要があります。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| S=0 \ / DBv=42 |
| \/ S=0 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->|
| |
Figure 3: State Synchronization Skipped; No LSP-DB-VERSION TLVs Sent from the PCC
図3：スキップされた状態同期。 PCCから送信されたLSP-DB-VERSION TLVはありません
There could be a case during PCEP session re-establishment when the PCC's or PCE's IP address can change. This includes, but is not limited to, the following cases:
PCEPの再確立中に、PCCまたはPCEのIPアドレスが変更される場合があります。これには、次の場合が含まれますが、これらに限定されません。
o A PCC could use a physical interface IP address to connect to the PCE. In this case, if the line card that the PCC connects from changes, then the PCEP session goes down and comes back up again, with a different IP address associated with a new line card.
o PCCは、物理インターフェイスIPアドレスを使用してPCEに接続できます。この場合、PCCが接続するラインカードが変更されると、PCEPセッションがいったん停止し、新しいラインカードに関連付けられた別のIPアドレスで再び起動します。
o The PCC or PCE may move in the network, either physically or logically, which may cause its IP address to change. For example, the PCE may be deployed as a virtual network function (VNF), and another virtualized instance of the PCE may be populated with the original PCE instance's state, but it may be given a different IP address.
o PCCまたはPCEは、物理的または論理的にネットワーク内を移動する可能性があり、IPアドレスが変更される可能性があります。たとえば、PCEを仮想ネットワーク機能（VNF）として展開し、PCEの別の仮想化インスタンスに元のPCEインスタンスの状態を設定できますが、異なるIPアドレスが与えられる場合があります。
To ensure that a PCEP peer can recognize a previously connected peer, each PCEP peer includes the SPEAKER-ENTITY-ID TLV described in Section 3.3.2 in the OPEN message.
PCEPピアが以前に接続されたピアを確実に認識できるようにするために、各PCEPピアには、OPENメッセージのセクション3.3.2で説明されているSPEAKER-ENTITY-ID TLVが含まれています。
This TLV is used during the State Synchronization procedure to identify the PCEP session as a re-establishment of a previous session that went down. Then State Synchronization optimizations such as state sync avoidance can be applied to this session. Note that this usage is only applicable within the State Timeout Interval [RFC8231]. After the State Timeout Interval expires, all state associated with the PCEP session is removed, which includes the SPEAKER-ENTITY-ID received. Note that the PCEP session initialization [RFC5440] procedure remains unchanged.
このTLVは、状態同期手順中に、PCEPセッションを、ダウンした前のセッションの再確立として識別するために使用されます。次に、状態同期回避などの状態同期最適化をこのセッションに適用できます。この使用法は、状態タイムアウト間隔[RFC8231]内でのみ適用できることに注意してください。状態タイムアウト間隔が経過すると、PCEPセッションに関連付けられているすべての状態が削除されます。これには、受信したSPEAKER-ENTITY-IDが含まれます。 PCEPセッションの初期化[RFC5440]の手順は変更されていないことに注意してください。
A new INCLUDE-DB-VERSION (S) bit is added in the stateful capabilities TLV (see Section 7 for details).
新しいINCLUDE-DB-VERSION（S）ビットがステートフル機能TLVに追加されました（詳細はセクション7を参照）。
The LSP-DB Version Number (LSP-DB-VERSION) TLV is an optional TLV that MAY be included in the OPEN object and the LSP object.
LSP-DBバージョン番号（LSP-DB-VERSION）TLVは、OPENオブジェクトとLSPオブジェクトに含めることができるオプションのTLVです。
This TLV is included in the LSP object in the PCRpt message to indicate the LSP-DB version at the PCC. This TLV SHOULD NOT be included in other PCEP messages (Path Computation Update Request (PCUpd), Path Computation Request (PCReq), and Path Computation Reply (PCRep)) and MUST be ignored if received.
このTLVはPCRptメッセージのLSPオブジェクトに含まれ、PCCでのLSP-DBバージョンを示します。このTLVは、他のPCEPメッセージ（パス計算更新要求（PCUpd）、パス計算要求（PCReq）、およびパス計算応答（PCRep））に含めるべきではなく（SHOULD NOT）、受け取った場合は無視する必要があります。
The format of the LSP-DB-VERSION TLV is shown in the following figure:
LSP-DB-VERSION 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=23 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-DB Version Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LSP-DB-VERSION TLV Format
図4：LSP-DB-VERSION TLV形式
The type of the TLV is 23, and it has a fixed length of 8 octets. The value contains a 64-bit unsigned integer, carried in network byte order, representing the LSP-DB Version Number.
TLVのタイプは23で、8オクテットの固定長です。この値には、LSP-DBバージョン番号を表す64ビットの符号なし整数がネットワークバイトオーダーで含まれています。
The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional TLV that MAY be included in the OPEN object when a PCEP speaker wishes to determine if State Synchronization can be skipped when a PCEP session is restarted. It contains a unique identifier for the node that does not change during the lifetime of the PCEP speaker. It identifies the PCEP speaker to its peers even if the speaker's IP address is changed.
Speaker Entity Identifier TLV（SPEAKER-ENTITY-ID）はオプションのTLVであり、PCEPセッションの再起動時にPCEPスピーカーが状態同期をスキップできるかどうかを判断する場合に、OPENオブジェクトに含めることができます。これには、PCEPスピーカーの有効期間中に変更されないノードの一意の識別子が含まれています。スピーカーのIPアドレスが変更された場合でも、ピアに対してPCEPスピーカーを識別します。
In case of a remote peer IP address change, a PCEP speaker would learn the Speaker Entity Identifier on receiving the open message, but it MAY have already sent its open message without realizing that it is a known PCEP peer. In such a case, either a full synchronization is done or the PCEP session is terminated. This may be a local policy decision. The new IP address is associated with the Speaker Entity Identifier for the future either way. In the latter case when the PCEP session is re-established, it would be correctly associated with the Speaker Entity Identifier and not be considered as an unknown peer.
リモートピアのIPアドレスが変更された場合、PCEPスピーカーはオープンメッセージを受信するとスピーカーエンティティIDを学習しますが、既知のPCEPピアであることを認識せずに、オープンメッセージをすでに送信している場合があります。このような場合、完全同期が行われるか、PCEPセッションが終了します。これは地方の政策決定かもしれません。新しいIPアドレスは、いずれかの方法で将来の話者エンティティ識別子に関連付けられます。後者の場合、PCEPセッションが再確立されると、それはスピーカーエンティティIDに正しく関連付けられ、不明なピアとは見なされません。
The format of the SPEAKER-ENTITY-ID TLV is shown in the following figure:
SPEAKER-ENTITY-ID 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=24 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Speaker Entity Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SPEAKER-ENTITY-ID TLV Format
図5：SPEAKER-ENTITY-ID TLVフォーマット
The type of the TLV is 24, and it has a variable length, which MUST be greater than 0. The value is padded to a 4-octet alignment. The padding is not included in the Length field. The value contains the Speaker Entity Identifier (an identifier of the PCEP speaker transmitting this TLV). This identifier is required to be unique within its scope of visibility, which is usually limited to a single domain. It MAY be configured by the operator. Alternatively, it can be derived automatically from a suitably stable unique identifier, such as a Media Access Control (MAC) address, serial number, Traffic Engineering Router ID, or similar. In the case of inter-domain connections, the speaker SHOULD prefix its usual identifier with the domain identifier of its residence, such as an Autonomous System number, an IGP area identifier, or similar to make sure it remains unique.
TLVのタイプは24で、可変長であり、0より大きい必要があります。値は、4オクテットアライメントになるように埋め込まれます。パディングは[長さ]フィールドには含まれません。値には、Speaker Entity Identifier（このTLVを送信するPCEPスピーカーの識別子）が含まれます。この識別子は、可視性の範囲内で一意である必要があります。これは通常、単一のドメインに限定されます。これは、オペレーターが構成できます。または、メディアアクセスコントロール（MAC）アドレス、シリアル番号、トラフィックエンジニアリングルーターIDなど、適切に安定した一意の識別子から自動的に取得することもできます。ドメイン間接続の場合、スピーカーは、通常の識別子の前に、自律システム番号、IGPエリア識別子などの固有のドメイン識別子を付加して、一意であることを確認する必要があります（SHOULD）。
The relationship between this identifier and entities in the Traffic Engineering database is intentionally left undefined.
この識別子と交通工学データベースのエンティティとの関係は、意図的に未定義のままにしています。
From a manageability point of view, a PCE or PCC implementation SHOULD allow the operator to configure this Speaker Entity Identifier.
管理性の観点から、PCEまたはPCC実装では、オペレーターがこのスピーカーエンティティ識別子を構成できるようにする必要があります（SHOULD）。
If a PCEP speaker receives the SPEAKER-ENTITY-ID on a new PCEP session, that matches with an existing alive PCEP session, the PCEP speaker MUST send a PCErr with Error-type=20 and Error-value=7 'Received an invalid Speaker Entity Identifier', and close the PCEP session.
PCEPスピーカーが既存の有効なPCEPセッションと一致する新しいPCEPセッションでSPEAKER-ENTITY-IDを受信した場合、PCEPスピーカーはError-type = 20およびError-value = 7のPCErrを送信する必要があります '無効なスピーカーを受信しましたEntity Identifier '、PCEPセッションを閉じます。
[RFC8231] describes the LSP State Synchronization mechanism between PCCs and stateful PCEs. During the State Synchronization, a PCC sends the information of all its LSPs (i.e., the full LSP-DB) to the stateful PCE. In order to reduce the State Synchronization overhead when there is a small number of LSP state changes in the network between the PCEP session restart, this section defines a mechanism for incremental (Delta) LSP-DB synchronization.
[RFC8231]は、PCCとステートフルPCE間のLSP状態同期メカニズムについて説明しています。状態同期中に、PCCはそのすべてのLSP（つまり、完全なLSP-DB）の情報をステートフルPCEに送信します。 PCEPセッションの再起動の間にネットワークでLSP状態の変化が少ない場合に状態同期のオーバーヘッドを削減するために、このセクションでは、増分（デルタ）LSP-DB同期のメカニズムを定義します。
According to [RFC8231], if a PCE restarts and its LSP-DB survived, PCCs with a mismatched LSP-DB Version Number will send all their LSPs information (full LSP-DB) to the stateful PCE, even if only a small number of LSPs underwent state change. It can take a long time and consume large communication channel bandwidth.
[RFC8231]によれば、PCEが再起動し、そのLSP-DBが存続した場合、LSP-DBバージョン番号が一致しないPCCは、LSP-DBのすべての情報（完全なLSP-DB）をステートフルPCEに送信します。 LSPの状態が変化しました。時間がかかり、大きな通信チャネル帯域幅を消費する可能性があります。
Figure 6 shows an example of LSP State Synchronization.
図6に、LSP状態同期の例を示します。
+-----+
| PCE |
+-----+
/
/
/
/
+------+ +------+
| PCC1 |------------| PCC2 |
+------+ +------+
| |
| |
+------+ +------+
| PCC3 |------------| PCC4 |
+------+ +------+
Figure 6: Topology Example
図6：トポロジの例
Assume that there are 320 LSPs in the network, with each PCC having 80 LSPs. During the time when the PCEP session is down, 20 LSPs of each PCC (i.e., 80 LSPs in total), are changed. Hence, when the PCEP session restarts, the stateful PCE needs to synchronize 320 LSPs with all PCCs. But actually, 240 LSPs stay the same. If performing full LSP State Synchronization, it can take a long time to carry out the synchronization of all LSPs. It is especially true when only a low bandwidth communication channel is available (e.g., in-band control channel for optical transport networks), and there is a substantial number of LSPs in the network. Another disadvantage of full LSP synchronization is that it is a waste of communication bandwidth to perform full LSP synchronization given the fact that the number of LSP changes can be small during the time when the PCEP session is down.
ネットワークに320のLSPがあり、各PCCに80のLSPがあるとします。 PCEPセッションがダウンしている間に、各PCCの20 LSP（つまり、合計80 LSP）が変更されます。したがって、PCEPセッションが再開すると、ステートフルPCEは320のLSPをすべてのPCCと同期する必要があります。しかし、実際には、240のLSPは同じままです。完全なLSP状態同期を実行すると、すべてのLSPの同期を実行するのに長時間かかる場合があります。これは特に、低帯域幅の通信チャネルのみが利用可能であり（たとえば、光トランスポートネットワークの帯域内制御チャネル）、ネットワークにかなりの数のLSPがある場合に当てはまります。完全なLSP同期のもう1つの欠点は、PCEPセッションがダウンしているときにLSP変更の数が少ない場合があるため、完全なLSP同期を実行すると通信帯域幅が無駄になることです。
An incremental (Delta) LSP-DB State Synchronization is described in this section, where only the LSPs that underwent state change are synchronized between the session restart. This may include new/modified/deleted LSPs.
このセクションでは、増分（Delta）LSP-DB状態同期について説明します。この場合、状態の変更を受けたLSPのみがセッションの再起動間で同期されます。これには、新規/変更/削除されたLSPが含まれる場合があります。
[RFC8231] describes State Synchronization and Section 3 of this document describes State Synchronization avoidance by using LSP-DB-VERSION TLV in its OPEN object. This section extends this idea to only synchronize the delta (changes) in case of version mismatch.
[RFC8231]は状態同期について説明しており、このドキュメントのセクション3では、OPENオブジェクトでLSP-DB-VERSION TLVを使用することによる状態同期の回避について説明しています。このセクションでは、この考えを拡張して、バージョンが一致しない場合にのみデルタ（変更）を同期するようにします。
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN object and the LSP-DB-VERSION TLV values match, the PCC MAY skip State Synchronization. Otherwise, the PCC MUST perform State Synchronization. Incremental State Synchronization capability is advertised on a PCEP session during session startup using the DELTA-LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see Section 7). Instead of dumping full LSP-DB to the stateful PCE again, the PCC synchronizes the delta (changes) as described in Figure 7 when the D and S flags are set to 1 by both the PCC and PCE. Other combinations of D and S flags set by the PCC and PCE result in full LSP-DB synchronization procedures as described in [RFC8231]. By setting the D flag to zero in the OPEN message, a PCEP speaker can skip the incremental synchronization optimization, resulting in a full LSP-DB synchronization.
両方のPCEPスピーカーがOPENオブジェクトにLSP-DB-VERSION TLVを含み、LSP-DB-VERSION TLV値が一致する場合、PCCは状態同期をスキップできます（MAY）。それ以外の場合、PCCは状態同期を実行する必要があります。 Incremental State Synchronization機能は、機能TLVのDELTA-LSP-SYNC-CAPABILITY（D）ビットを使用して、セッションの起動中にPCEPセッションでアドバタイズされます（セクション7を参照）。完全なLSP-DBを再度ステートフルPCEにダンプする代わりに、PCCは、PCCとPCEの両方によってDフラグとSフラグが1に設定されている場合、図7で説明されているようにデルタ（変更）を同期します。 [RFC8231]で説明されているように、PCCとPCEによって設定されるDフラグとSフラグの他の組み合わせは、完全なLSP-DB同期手順になります。 OPENメッセージでDフラグをゼロに設定することにより、PCEPスピーカーは増分同期の最適化をスキップして、完全なLSP-DB同期を実現できます。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| S=1 \ / DBv=42 |
| D=1 \/ S=1 |
| /\ D=1 |
| / \ |
| / `-------->| (Expect delta sync)
(Do sync)|<--------` | (DO NOT purge LSP
(Delta) | | state)
| |
(Delta sync starts) |--PCRpt,DBv=46,SYNC=1-->|
| . |
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done,
| | PLSP-ID=0)
| |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 7: Incremental Synchronization Procedure
図7：増分同期手順
As per Section 3, the LSP-DB Version Number is incremented each time a change is made to the PCC's local LSP-DB. Each LSP is associated with the DB version at the time of its state change. This is needed to determine which LSP and what information needs to be synchronized in incremental State Synchronization. The incremental state sync is done from the last LSP-DB version received by the PCE to the latest DB version at the PCC. Note that the LSP-DB Version Number can wrap around, in which case the incremental state sync would also wrap till the latest LSP-DB Version Number at the PCC.
セクション3に従って、LSC-DBバージョン番号は、PCCのローカルLSP-DBに変更が加えられるたびに増分されます。各LSPは、状態が変化した時点のDBバージョンに関連付けられています。これは、増分状態同期で同期する必要があるLSPと情報を決定するために必要です。増分状態同期は、PCEが受信した最後のLSP-DBバージョンからPCCの最新のDBバージョンに行われます。 LSP-DBバージョン番号はラップアラウンドできることに注意してください。その場合、PCCで最新のLSP-DBバージョン番号まで増分状態同期もラップします。
In order to carry out incremental State Synchronization, it is not necessary for a PCC to store a complete history of LSP-DB change for all time, but remember the LSP state changes (including LSP modification, setup, and deletion) that the PCE did not get to process during the session down. Note that, a PCC would be unaware that a particular LSP report has been processed by the PCE before the session to the PCE went down. So a PCC implementation MAY choose to store the LSP-DB Version Number with each LSP at the time its status changed, so that when a session is re-established, an incremental synchronization can be attempted based on the PCE's last LSP-DB Version Number. For an LSP that is deleted at the PCC, the PCC implementation would need to remember the deleted LSP in some way to make sure this could be reported as part of incremental synchronization later. The PCC would discard this information based on a local policy or when it determines that this information is no longer needed with sufficient confidence. In the example shown in Figure 7, the PCC needs to store the LSP state changes that happened between DB Versions 43 to 46 and synchronize these changes, when performing incremental LSP state update.
増分状態同期を実行するために、PCCが常にLSP-DB変更の完全な履歴を保存する必要はありませんが、PCEが行ったLSP状態変更（LSPの変更、セットアップ、削除を含む）を覚えておいてくださいセッションがダウンしている間は処理できません。 PCEへのセッションがダウンする前に、PCCは特定のLSPレポートがPCEによって処理されたことを認識しないことに注意してください。したがって、PCC実装は、ステータスが変更されたときに各LSPとともにLSP-DBバージョン番号を保存することを選択できます。これにより、セッションが再確立されたときに、PCEの最後のLSP-DBバージョン番号に基づいて増分同期を試行できます。 。 PCCで削除されたLSPの場合、PCC実装は、削除されたLSPを何らかの方法で記憶して、後で増分同期の一部として報告できるようにする必要があります。 PCCは、ローカルポリシーに基づいて、またはこの情報が十分な自信を持って不要になったと判断したときに、この情報を破棄します。図7に示す例では、PCCは、増分LSP状態更新を実行するときに、DBバージョン43から46の間で発生したLSP状態の変更を保存し、これらの変更を同期する必要があります。
If a PCC finds out it does not have sufficient information to complete incremental synchronization after advertising incremental LSP State Synchronization capability, it MUST send a PCErr with Error-type=20 and Error-value=5 'A PCC indicates to a PCE that it can not complete the State Synchronization' (defined in [RFC8231]), and terminate the session. The PCC SHOULD re-establish the session with the D bit set to 0 in the OPEN message.
PCCが、インクリメンタルLSP状態同期機能をアドバタイズした後にインクリメンタル同期を完了するのに十分な情報がないことを検出した場合、PCCはError-type = 20およびError-value = 5のPCErrを送信する必要があります。 （[RFC8231]で定義されている）状態同期を完了せず、セッションを終了します。 PCCは、OPENメッセージでDビットを0に設定してセッションを再確立する必要があります（SHOULD）。
The other procedures and error checks remain unchanged from the full State Synchronization [RFC8231].
その他の手順とエラーチェックは、完全な状態同期[RFC8231]から変更されていません。
In networks such as optical transport networks, the control channel between network nodes can be realized through in-band overhead, thus it has limited bandwidth. With a stateful PCE connected to the network via one network node, it is desirable to control the timing of PCC State Synchronization so as not to overload the low communication channel available in the network during the initial synchronization (be it incremental or full) when the session restarts, when there is a comparatively large amount of control information needing to be synchronized between the stateful PCE and the network. The method proposed, i.e., allowing PCE to trigger the State Synchronization, is similar to the function proposed in Section 6 but is used in different scenarios and for different purposes.
光トランスポートネットワークなどのネットワークでは、ネットワークノード間の制御チャネルは帯域内オーバーヘッドによって実現できるため、帯域幅が制限されます。 1つのネットワークノードを介してネットワークに接続されたステートフルPCEでは、PCC状態同期のタイミングを制御して、初期同期（インクリメンタルまたはフル）中にネットワークで利用可能な低通信チャネルが過負荷にならないようにすることが望ましいです。ステートフルPCEとネットワークの間で同期する必要がある比較的大量の制御情報がある場合、セッションが再開します。提案された方法、つまりPCEが状態同期をトリガーできるようにすることは、セクション6で提案された機能に似ていますが、さまざまなシナリオで、さまざまな目的で使用されます。
Support of PCE-triggered initial State Synchronization is advertised during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7).
PCEによってトリガーされる初期状態同期のサポートは、STATEFUL-PCE-CAPABILITY TLVのTRIGGERED-INITIAL-SYNC（F）ビットを使用してセッションの起動中に通知されます（セクション7を参照）。
In order to allow a stateful PCE to control the LSP-DB synchronization after establishing a PCEP session, both PCEP speakers MUST set the F bit to 1 in the OPEN message. If the LSP-DB-VERSION TLV is included by both PCEP speakers and the TLV value matches, the State Synchronization can be skipped as described in Section 3.2. If the TLV is not included or the LSP-DB Version is mismatched, the PCE can trigger the State Synchronization process by sending a PCUpd message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD include an empty Explicit Route Object (ERO) (with no ERO sub-object and object length of 4) as its intended path and SHOULD NOT include the optional objects for its attributes for any parameter update. The PCC MUST ignore such an update when the SYNC flag is set. If the TRIGGERED-INITIAL-SYNC capability is not advertised by a PCE and the PCC receives a PCUpd with the SYNC flag set to 1, the PCC MUST send a PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and Error-value=4 'Attempt to trigger a synchronization when the PCE triggered synchronization capability has not been advertised' (see Section 8.1). If the TRIGGERED-INITIAL-SYNC capability is advertised by a PCE and the PCC, the PCC MUST NOT trigger State Synchronization on its own. If the PCE receives a PCRpt message before the PCE has triggered the State Synchronization, the PCE MUST send a PCErr with Error-type=20 and Error-value=3 'Attempt to trigger synchronization before PCE trigger' (see Section 8.1).
PCEPセッションの確立後にステートフルPCEがLSP-DB同期を制御できるようにするには、両方のPCEPスピーカーがOPENメッセージのFビットを1に設定する必要があります。 LSP-DB-VERSION TLVが両方のPCEPスピーカーに含まれていて、TLV値が一致している場合、セクション3.2で説明されているように、状態同期をスキップできます。 TLVが含まれていないか、LSP-DBバージョンが一致しない場合、PCEは、PLSP-ID = 0およびSYNC = 1のPCUpdメッセージを送信することにより、状態同期プロセスをトリガーできます。PCUpdメッセージには、空の明示的ルートオブジェクト（ ERO）（EROサブオブジェクトがなく、オブジェクト長が4である）を目的のパスとして使用し、パラメーターの更新の属性にオプションのオブジェクトを含めないでください。 PCCは、SYNCフラグが設定されている場合、そのような更新を無視する必要があります。 TRIGGERED-INITIAL-SYNC機能がPCEによってアドバタイズされておらず、PCCがSYNCフラグが1に設定されたPCUpdを受信する場合、PCCはPCUpdのSRP-ID-number、Error-type = 20でPCErrを送信する必要があります。 、およびError-value = 4 'PCEトリガー同期機能がアドバタイズされていないときに同期をトリガーする試み'（セクション8.1を参照）。 TRIGGERED-INITIAL-SYNC機能がPCEおよびPCCによって通知される場合、PCCはそれ自体で状態同期をトリガーしてはなりません（MUST NOT）。 PCEが状態同期をトリガーする前にPCEがPCRptメッセージを受信する場合、PCEはError-type = 20およびError-value = 3 'PCEトリガーの前に同期をトリガーする試み'（セクション8.1を参照）でPCErrを送信する必要があります。
In this way, the PCE can control the sequence of LSP synchronization among all the PCCs that are re-establishing PCEP sessions with it. When the capability of PCE control is enabled, only after a PCC receives this message, it will start sending information to the PCE. This PCE-triggering capability can be applied to both full and incremental State Synchronization. If applied to the latter, the PCCs only send information that PCE does not possess, which is inferred from the LSP-DB version information exchanged in the OPEN message (see Section 4.2 for a detailed procedure).
このようにして、PCEは、PCEPセッションを再確立しているすべてのPCC間のLSP同期のシーケンスを制御できます。 PCE制御の機能が有効な場合、PCCがこのメッセージを受信した後にのみ、PCEへの情報の送信を開始します。このPCEトリガー機能は、完全状態同期と増分状態同期の両方に適用できます。後者に適用した場合、PCCはPCEが所有していない情報のみを送信します。これは、OPENメッセージで交換されたLSP-DBバージョン情報から推論されます（詳細な手順については、セクション4.2を参照）。
Once the initial State Synchronization is triggered by the PCE, the procedures and error checks remain unchanged [RFC8231].
PCEによって初期状態同期がトリガーされると、手順とエラーチェックは変更されません[RFC8231]。
If a PCC implementation that does not implement this extension should not receive a PCUpd message to trigger State Synchronization as per the capability advertisement, but if it were to receive it, it will behave as per [RFC8231].
この拡張機能を実装していないPCC実装が、機能のアドバタイズに従って状態同期をトリガーするPCUpdメッセージを受信してはならない場合、それを受信すると、[RFC8231]のように動作します。
The accuracy of the computations performed by the PCE is tied to the accuracy of the view the PCE has on the state of the LSPs. Therefore, it can be beneficial to be able to resynchronize this state even after the session has been established. The PCE may use this approach to continuously sanity check its state against the network or to recover from error conditions without having to tear down sessions.
PCEによって実行される計算の精度は、PCEがLSPの状態に対して持つビューの精度に関連付けられています。したがって、セッションが確立された後でも、この状態を再同期できると便利です。 PCEはこのアプローチを使用して、ネットワークに対する状態を継続的に正常性チェックしたり、セッションを終了したりせずにエラー状態から回復したりできます。
Support of PCE-triggered state resynchronization is advertised by both PCEP speakers during session startup using the TRIGGERED-RESYNC (T) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7). The PCE can choose to resynchronize its entire LSP-DB or a single LSP.
PCEトリガー状態の再同期のサポートは、STATEFUL-PCE-CAPABILITY TLVのTRIGGERED-RESYNC（T）ビットを使用して、セッションの起動時に両方のPCEPスピーカーによって通知されます（セクション7を参照）。 PCEは、LSP-DB全体を再同期するか、単一のLSPを再同期するかを選択できます。
To trigger resynchronization for an LSP, the PCE sends a Path Computation State Update (PCUpd) for the LSP, with the SYNC flag in the LSP object set to 1. The PCE SHOULD NOT include any parameter updates for the LSP, and the PCC MUST ignore such an update when the SYNC flag is set. The PCC MUST respond with a PCRpt message with the LSP state, SYNC flag set to 0 and MUST include the SRP-ID-number of the PCUpd message that triggered the resynchronization. If the PCC cannot find the LSP in its database, PCC MUST also set the R (remove) flag [RFC8231] in the LSP object in the PCRpt message.
LSPの再同期をトリガーするために、PCEはLSPオブジェクトのSYNCフラグを1に設定して、LSPのパス計算状態更新（PCUpd）を送信します。PCEは、LSPのパラメーター更新を含めないでください。PCCは、 SYNCフラグが設定されている場合は、このような更新を無視してください。 PCCは、LSP状態、SYNCフラグが0に設定されたPCRptメッセージで応答する必要があり、再同期をトリガーしたPCUpdメッセージのSRP-ID-numberを含める必要があります。 PCCがデータベースでLSPを見つけられない場合、PCCはPCRptメッセージのLSPオブジェクトにR（削除）フラグ[RFC8231]も設定する必要があります。
The PCE can also trigger resynchronization of the entire LSP-DB. The PCE MUST first mark all LSPs in the LSP-DB that were previously reported by the PCC as stale, and then send a PCUpd with an LSP object containing a PLSP-ID of 0 and with the SYNC flag set to 1. The PCUpd message MUST include an empty ERO (with no ERO sub-object and object length of 4) as its intended path and SHOULD NOT include the optional objects for its attributes for any parameter update. The PCC MUST ignore such update if the SYNC flag is set. This PCUpd message is the trigger for the PCC to enter the synchronization phase as described in [RFC8231] and start sending PCRpt messages. After the receipt of the end-of-synchronization marker, the PCE will purge LSPs that were not refreshed. The SRP-ID-number of the PCUpd that triggered the resynchronization SHOULD be included in each of the PCRpt messages. If the PCC cannot resynchronize the entire LSP-DB, the PCC MUST respond with a PCErr message with Error-type=20 and Error-value=5 'cannot complete the State Synchronization' [RFC8231], and it MAY terminate the session. The PCE MUST remove the stale mark for the LSPs that were previously reported by the PCC. Based on the local policy, the PCE MAY reattempt synchronization at a later time.
PCEは、LSP-DB全体の再同期もトリガーできます。 PCEはまず、以前にPCCによって失効として報告されたLSP-DB内のすべてのLSPをマークし、次に、PLSP-IDが0で、SYNCフラグが1に設定されたLSPオブジェクトを使用してPCUpdを送信する必要があります。PCUpdメッセージ意図したパスとして空のERO（EROサブオブジェクトなし、オブジェクト長4）を含めなければならず（MUST）、パラメータ更新の属性にオプションのオブジェクトを含めてはなりません（SHOULD NOT）。 PCCは、SYNCフラグが設定されている場合、そのような更新を無視する必要があります。このPCUpdメッセージは、PCCが[RFC8231]で説明されている同期フェーズに入り、PCRptメッセージの送信を開始するためのトリガーです。同期終了マーカーの受信後、PCEは更新されなかったLSPを削除します。再同期をトリガーしたPCUpdのSRP-ID-numberは、各PCRptメッセージに含まれる必要があります（SHOULD）。 PCCがLSP-DB全体を再同期できない場合、PCCはPCErrメッセージでError-type = 20およびError-value = 5で応答する必要があります（「状態の同期を完了できません」[RFC8231]）。セッションを終了できます（MAY）。 PCEは、以前にPCCによって報告されたLSPの古いマークを削除する必要があります。ローカルポリシーに基づいて、PCEは後で同期を再試行する場合があります。
If the TRIGGERED-RESYNC capability is not advertised by a PCE and the PCC receives a PCUpd with the SYNC flag set to 1, it MUST send a PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and Error-value=4 'Attempt to trigger a synchronization when the PCE triggered synchronization capability has not been advertised' (see Section 8.1).
TRIGGERED-RESYNC機能がPCEによってアドバタイズされておらず、PCCがSYNCフラグが1に設定されたPCUpdを受信する場合、PCUpdのSRP-ID-number、Error-type = 20、およびErrorを含むPCErrを送信する必要があります。 -value = 4 'PCEトリガー同期機能がアドバタイズされていない場合に同期をトリガーする試み'（セクション8.1を参照）。
Once the state resynchronization is triggered by the PCE, the procedures and error checks remain unchanged from the full state synchronization [RFC8231]. This would also include the PCE triggering multiple state resynchronization requests while synchronization is in progress.
PCEによって状態の再同期がトリガーされると、手順とエラーチェックは完全な状態の同期[RFC8231]から変更されません。これには、同期の進行中にPCEが複数の状態の再同期要求をトリガーすることも含まれます。
If a PCC implementation that does not implement this extension should not receive a PCUpd message to trigger resynchronization as per the capability advertisement, but if it were to receive it, it will behave as per [RFC8231].
この拡張機能を実装していないPCC実装が、機能アドバタイズに従って再同期をトリガーするPCUpdメッセージを受信してはならない場合、それを受信すると、[RFC8231]に従って動作します。
Support for each of the optimizations described in this document requires advertising the corresponding capabilities during session establishment time.
このドキュメントで説明する各最適化をサポートするには、セッションの確立時に対応する機能をアドバタイズする必要があります。
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]. This document defines the following new flags in the STATEFUL-PCE-CAPABILITY TLV:
STATEFUL-PCE-CAPABILITY TLVは[RFC8231]で定義されています。このドキュメントでは、STATEFUL-PCE-CAPABILITY TLVで次の新しいフラグを定義しています。
Bit Description
------------------------- ---------------------------------
30 S bit (INCLUDE-DB-VERSION)
27 D bit (DELTA-LSP-SYNC-CAPABILITY)
26 F bit (TRIGGERED-INITIAL-SYNC)
28 T bit (TRIGGERED-RESYNC)
If the S bit (INCLUDE-DB-VERSION) is set to 1 by both PCEP speakers, the PCC will include the LSP-DB-VERSION TLV in each LSP object. See Section 3.2 for details.
両方のPCEPスピーカーによってSビット（INCLUDE-DB-VERSION）が1に設定されている場合、PCCは各LSPオブジェクトにLSP-DB-VERSION TLVを含めます。詳細については、セクション3.2を参照してください。
If the D bit (DELTA-LSP-SYNC-CAPABILITY) is set to 1 by a PCEP speaker, it indicates that the PCEP speaker allows incremental (delta) State Synchronization. See Section 4.2 for details.
Dビット（DELTA-LSP-SYNC-CAPABILITY）がPCEPスピーカーによって1に設定されている場合、PCEPスピーカーが増分（デルタ）状態同期を許可していることを示します。詳細については、セクション4.2を参照してください。
If the F bit (TRIGGERED-INITIAL-SYNC) is set to 1 by both PCEP speakers, the PCE SHOULD trigger initial (first) State Synchronization. See Section 5.2 for details.
両方のPCEPスピーカーによってFビット（TRIGGERED-INITIAL-SYNC）が1に設定されている場合、PCEは初期（最初の）状態同期をトリガーする必要があります（SHOULD）。詳細については、セクション5.2を参照してください。
If the T bit (TRIGGERED-RESYNC) is set to 1 by both PCEP speakers, the PCE can trigger resynchronization of LSPs at any point in the life of the session. See Section 6.2 for details.
両方のPCEPスピーカーによってTビット（TRIGGERED-RESYNC）が1に設定されている場合、PCEはセッションの存続期間の任意の時点でLSPの再同期をトリガーできます。詳細については、セクション6.2を参照してください。
See Section 8.3 for IANA allocations.
IANAの割り当てについては、セクション8.3を参照してください。
IANA has allocated code points for the protocol elements defined in this document.
IANAは、このドキュメントで定義されているプロトコル要素にコードポイントを割り当てています。
IANA has allocated the following values in the "PCEP-ERROR Object Error Types and Values" registry.
IANAは、「PCEP-ERRORオブジェクトのエラータイプと値」レジストリに次の値を割り当てました。
Error-Type Meaning Reference
------------------------------------------------------------
6 Mandatory Object missing [RFC5440]
Error-value 12: LSP-DB-VERSION TLV missing This document
エラー値12：LSP-DB-VERSION TLVがこのドキュメントにありません
20 LSP State Synchronization Error [RFC8231]
20 LSP状態同期エラー[RFC8231]
Error-value 2: LSP-DB version mismatch. This document
エラー値2：LSP-DBバージョンの不一致。このドキュメント
3: Attempt to trigger This document synchronization before PCE trigger.
3：PCEトリガーの前にこのドキュメントの同期をトリガーしようとしました。
4: Attempt to trigger a This document synchronization when the PCE triggered synchronization capability has not been advertised.
4：PCEトリガー同期機能がアドバタイズされていないときに、このドキュメントの同期をトリガーしようとしました。
6: Received an invalid This document LSP-DB Version Number.
6：無効なこのドキュメントのLSP-DBバージョン番号を受け取りました。
7: Received an invalid This document Speaker Entity Identifier.
7：無効なこのドキュメントのスピーカーエンティティIDを受け取りました。
IANA has allocated the following values in the "PCEP TLV Type Indicators" registry.
IANAは、「PCEP TLV Type Indicators」レジストリに次の値を割り当てました。
Value Meaning Reference
------------------------- ----------------- -------------
23 LSP-DB-VERSION This document
24 SPEAKER-ENTITY-ID This document
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]. The "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry has been created to manage the flags in the TLV. IANA has allocated the following values in this registry.
STATEFUL-PCE-CAPABILITY TLVは[RFC8231]で定義されています。 「STATEFUL-PCE-CAPABILITY TLVフラグフィールド」レジストリは、TLVのフラグを管理するために作成されました。 IANAは、このレジストリに次の値を割り当てました。
Bit Description Reference
-------------------------- -------------------------- -------------
26 TRIGGERED-INITIAL-SYNC This document
27 DELTA-LSP-SYNC-CAPABILITY This document
28 TRIGGERED-RESYNC This document
30 INCLUDE-DB-VERSION This document
All manageability requirements and considerations listed in [RFC5440] and [RFC8231] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]と[RFC8231]にリストされているすべての管理要件と考慮事項は、このドキュメントで定義されているPCEPプロトコル拡張に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
A PCE or PCC implementation MUST allow configuring the State Synchronization optimization capabilities as described in this document. The implementation SHOULD also allow the operator to configure the Speaker Entity Identifier (Section 3.3.2). Further, the operator SHOULD be to be allowed to trigger the resynchronization procedures as per Section 6.2.
PCEまたはPCC実装では、このドキュメントで説明されているように、状態同期最適化機能の構成を許可する必要があります。実装は、オペレーターが話者エンティティ識別子を構成することも許可する必要があります（セクション3.3.2）。さらに、オペレーターは、セクション6.2に従って再同期手順をトリガーできるようにする必要があります（SHOULD）。
An implementation SHOULD allow the operator to view the stateful capabilities advertised by each peer and the current synchronization status with each peer. To serve this purpose, the PCEP YANG module [PCEP-YANG] can be extended to include advertised stateful capabilities and synchronization status.
実装は、オペレーターが各ピアによってアドバタイズされたステートフル機能と各ピアとの現在の同期ステータスを表示できるようにする必要があります（SHOULD）。この目的を果たすために、PCEP YANGモジュール[PCEP-YANG]を拡張して、アドバタイズされたステートフル機能と同期ステータスを含めることができます。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出と監視の要件を意味するものではありません。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231].
このドキュメントで定義されているメカニズムは、[RFC5440]と[RFC8231]にすでにリストされているメカニズムに加えて、新しい動作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルに対する新しい要件を意味するものではありません。
Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document.
[RFC5440]と[RFC8231]で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張にも適用されます。
The State Synchronization optimizations described in this document can result in a reduction of the amount of data exchanged and the time taken for a stateful PCE to be fully operational when a PCEP session is re-established. The ability to trigger resynchronization by the PCE can be utilized by the operator to sanity check its state and recover from any mismatch in state without tearing down the session.
このドキュメントで説明する状態同期の最適化により、PCEPセッションが再確立されたときに、交換されるデータの量と、ステートフルPCEが完全に動作するのにかかる時間を削減できます。オペレーターは、PCEによる再同期をトリガーする機能を利用して、その状態を正常性チェックし、セッションを破棄せずに状態の不一致から回復できます。
The security considerations listed in [RFC8231] apply to this document as well. However, this document also introduces some new attack vectors. An attacker could spoof the SPEAKER-ENTITY-ID and pretend to be another PCEP speaker. An attacker may flood the PCC with triggered resynchronization requests at a rate that exceeds the PCC's ability to process them by either spoofing messages or compromising the PCE itself. The PCC can respond with a PCErr message as described in Section 6.2 and terminate the session. Thus, securing the PCEP session using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED. An administrator could also expose the Speaker Entity Identifier as part of the certificate, for the peer identity verification.
[RFC8231]に記載されているセキュリティの考慮事項は、このドキュメントにも適用されます。ただし、このドキュメントでは、いくつかの新しい攻撃方法も紹介しています。攻撃者はSPEAKER-ENTITY-IDを偽装し、別のPCEPスピーカーのふりをする可能性があります。攻撃者は、メッセージのなりすましまたはPCE自体の侵害によって、PCCの処理能力を超える速度で、トリガーされた再同期要求でPCCをフラッディングする可能性があります。 PCCは、セクション6.2で説明されているようにPCErrメッセージで応答し、セッションを終了できます。したがって、[RFC7525]の推奨事項と現在のベストプラクティスに従って、トランスポート層セキュリティ（TLS）[PCEPS]を使用してPCEPセッションを保護することをお勧めします。管理者は、ピアの身元確認のために、証明書の一部として話者エンティティ識別子を公開することもできます。
[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>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[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>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <http://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< http://www.rfc-editor.org/info/rfc8231>。
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, July 2017.
[PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V.、j。 jefftant@gmail.com、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、draft-ietf-pce-pcep-yang-05、2017年7月。
[PCEPS] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-18, September 2017.
[PCEPS] Lopez、D.、Dios、O.、Wu、Q。、およびD. Dhody、「Secure Transport for PCEP」、Work in Progress、draft-ietf-pce-pceps-18、2017年9月。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]張、X。、エド。 I. Minei、編、「Stateful Path Computation Element（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
Acknowledgments
謝辞
We would like to thank Young Lee, Sergio Belotti, and Cyril Margaria for their comments and discussions.
Young Lee、Sergio Belotti、Cyril Margariaのコメントと議論に感謝します。
Thanks to Jonathan Hardwick for being the document shepherd and providing comments and guidance.
ドキュメントシェパードであり、コメントとガイダンスを提供してくれたJonathan Hardwickに感謝します。
Thanks to Tomonori Takeda for the Routing Area Directorate review.
ルーティングエリア総局のレビューをしてくれた武田智則に感謝します。
Thanks to Adrian Farrel for the TSVART review and providing detailed comments and suggestions.
TSVARTレビューと詳細なコメントと提案を提供してくれたAdrian Farrelに感謝します。
Thanks to Daniel Franke for the SECDIR review.
SECDIRレビューを行ったDaniel Frankeに感謝します。
Thanks to Alvaro Retana, Kathleen Moriarty, and Stephen Farrell for comments during the IESG evaluation.
IESG評価中のコメントについては、Alvaro Retana、Kathleen Moriarty、およびStephen Farrellに感謝します。
Thanks to Deborah Brungard for being the responsible AD and guiding the authors as needed.
責任あるADであり、必要に応じて著者を指導してくれたDeborah Brungardに感謝します。
Contributors
貢献者
Gang Xie Huawei Technologies F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong, 518129 China Email: xiegang09@huawei.com
ギャングX IE hu Aは技術F3-5-br＆Dセンター、hu Aは産業基地、禁止日、長いギャング地区は非常に現実的、GUケースGビルディング、518129中国メール：スラッシュ09 @ Huawei.com
Authors' Addresses
著者のアドレス
Edward Crabbe Oracle Email: edward.crabbe@gmail.com
Edward Crabbe Oracleメール：edward.crabbe@gmail.com
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: inaminei@google.com
Ina Minei Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 United States Email：inaminei@google.com
Jan Medved Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America Email: jmedved@cisco.com
Jan Medved Cisco Systems、Inc. 170 West Tasman Dr. San Jose、CA 95134アメリカ合衆国メール：jmedved@cisco.com
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56 Bratislava 821 05 Slovakia Email: robert.varga@pantheon.tech
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56ブラチスラバ821 05スロバキアメール：robert.varga@pantheon.tech
Xian Zhang Huawei Technologies F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 China Email: zhang.xian@huawei.com
Xian Zhang Huawei Technologies F3-5-B R＆D Center、Huawei Industrial Base、Bantian、Longgang District Shenzhen、Guangdong 518129 Chinaメール：zhang.xian@huawei.com
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com
Dhruv Dhodoi Huawei Technologies Divyashari Techno Park、Wheatfish Bangalore、Karnataka 2008 Indiaメール：Dhruv.atfogmail.com