[要約] RFC 9270 は、GMPLS Signaling Extensions for Shared Mesh Protection に関する要件を提供し、ITU-T勧告G.808.3およびG.873.3に基づいて、SMPメカニズムの制御をサポートするためにRFC 4872および4873を更新します。その目的は、GMPLS信号拡張を通じてSMPメカニズムの制御を可能にすることです。
Internet Engineering Task Force (IETF) J. He
Request for Comments: 9270 I. Busi
Updates: 4872, 4873 Huawei Technologies
Category: Standards Track J. Ryoo
ISSN: 2070-1721 B. Yoon
ETRI
P. Park
KT
August 2022
GMPLS Signaling Extensions for Shared Mesh Protection
共有メッシュ保護のためのGMPLSシグナリング拡張機能
Abstract
概要
ITU-T Recommendation G.808.3 defines the generic aspects of a Shared Mesh Protection (SMP) mechanism, where the difference between SMP and Shared Mesh Restoration (SMR) is also identified. ITU-T Recommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network.
ITU-T推奨G.808.3は、SMPと共有メッシュ修復（SMR）の違いも特定されている共有メッシュ保護（SMP）メカニズムの一般的な側面を定義しています。ITU-Tの推奨G.873.3は、光データユニット（ODU）層でのSMPの保護スイッチング操作と関連プロトコルを定義します。RFC 7412は、マルチプロトコルラベルスイッチング - トランスポートプロファイル（MPLS-TP）ネットワークにSMPを実装するために使用されるメカニズムの要件を提供します。
This document updates RFCs 4872 and 4873 to provide extensions for Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism.
このドキュメントは、RFCS 4872および4873を更新して、SMPメカニズムの制御をサポートするために、一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングの拡張機能を提供します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9270.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9270で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. SMP Definition
4. Operation of SMP with GMPLS Signaling Extensions
5. GMPLS Signaling Extensions for SMP
5.1. Identifiers
5.2. Signaling Primary LSPs
5.3. Signaling Secondary LSPs
5.4. SMP Preemption Priority
5.5. Availability of Shared Resources: The Notify Message
5.6. SMP APS Configuration
6. Updates to PROTECTION Object
6.1. New Protection Type
6.2. Updates to Definitions of Notification and Operational Bits
6.3. Preemption Priority
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
RFC 4872 [RFC4872] defines extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration (SMR) mechanisms. SMR can be seen as a particular case of preplanned Label Switched Path (LSP) rerouting that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. The recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, and explicit restoration signaling is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP that was instantiated during the provisioning phase. RFC 4873 [RFC4873] details the encoding of the last 32-bit Reserved field of the PROTECTION object defined in [RFC4872].
RFC 4872 [RFC4872]は、リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）の拡張機能を定義して、共有メッシュ修復（SMR）メカニズムをサポートします。SMRは、複数の保護LSPが共通のリンクとノードリソースを共有できるようにすることにより、回復リソースの要件を減らすために、事前に計画されたラベルスイッチ付きパス（LSP）再ルーティングの特定のケースと見なすことができます。保護LSPの回復リソースは、プロビジョニングフェーズ中に事前に予約されており、プロビジョニングフェーズ中にインスタンス化された特定の保護LSPをアクティブにする（つまり、データプレーンでリソース割り当てをコミットする）明示的な回復シグナリングが必要です。RFC 4873 [RFC4873]は、[RFC4872]で定義されている保護オブジェクトの最後の32ビット予約フィールドのエンコードを詳述しています。
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a Shared Mesh Protection (SMP) mechanism, which are not specific to a particular network technology in terms of architecture types, preemption principle, path monitoring methods, etc. ITU-T Recommendation G.873.3 [G873.3] defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network.
ITU-T推奨G.808.3 [G808.3]は、共有メッシュ保護（SMP）メカニズムの一般的な側面を定義します。これは、アーキテクチャタイプ、プリエンプション原理、パス監視方法などの観点から特定のネットワークテクノロジーに固有のものではありません。ITU-T推奨G.873.3 [G873.3]は、光データユニット（ODU）層でのSMPの保護スイッチング操作と関連プロトコルを定義します。RFC 7412 [RFC7412]は、マルチプロトコルラベルスイッチング - 輸送プロファイル（MPLS-TP）ネットワークにSMPを実装するために使用されるあらゆるメカニズムの要件を提供します。
SMP differs from SMR in the activation/protection switching operation. The former activates a protecting LSP via the Automatic Protection Switching (APS) protocol in the data plane when the working LSP fails, while the latter does it via control plane signaling. It is therefore necessary to distinguish SMP from SMR during provisioning so that each node involved behaves appropriately in the recovery phase when activation of a protecting LSP is done. SMP has advantages with regard to the recovery speed compared with SMR.
SMPは、アクティベーション/保護スイッチング操作がSMRとは異なります。前者は、作業LSPが故障したときにデータプレーンの自動保護スイッチング（APS）プロトコルを介して保護LSPをアクティブにしますが、後者はコントロールプレーンシグナリングを介してそれを行います。したがって、プロビジョニング中にSMPとSMRを区別して、関連する各ノードが保護LSPの活性化が行われたときに回復段階で適切に動作するようにする必要があります。SMPには、SMRと比較して回復速度に関して利点があります。
This document updates [RFC4872] and [RFC4873] to provide extensions for Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism. Specifically, it
このドキュメントは、[RFC4872]および[RFC4873]を更新して、SMPメカニズムの制御をサポートする一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達の拡張を提供します。具体的には、それ
* defines a new LSP Protection Type, "Shared Mesh Protection", for the LSP Flags field [RFC4872] of the PROTECTION object (see Section 6.1),
* 保護オブジェクトのLSPフラグフィールド[RFC4872]の新しいLSP保護タイプ「共有メッシュ保護」を定義します（セクション6.1を参照）、
* updates the definitions of the Notification (N) and Operational (O) fields [RFC4872] of the PROTECTION object to take the new SMP type into account (see Section 6.2), and
* 新しいSMPタイプを考慮に入れるために、保護オブジェクトの通知（n）および操作（o）フィールド[RFC4872]の定義を更新します（セクション6.2を参照）、および
* updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to allocate 8 bits to signal the SMP preemption priority (see Section 6.3).
* 保護オブジェクトの16ビット予約フィールド[RFC4873]の定義を更新して、8ビットを割り当ててSMPプリエンプションの優先順位を合図します（セクション6.3を参照）。
Only the generic aspects for signaling SMP are addressed by this document. The technology-specific aspects are expected to be addressed by other documents.
このドキュメントでは、SMPのシグナリングの一般的な側面のみが対処されます。技術固有の側面は、他の文書で対処されることが期待されています。
RFC 8776 [RFC8776] defines a collection of common YANG data types for Traffic Engineering (TE) configuration and state capabilities. It defines several identities for LSP Protection Types. As this document introduces a new LSP Protection Type, [RFC8776] is expected to be updated to support the SMP mechanism specified in this document. [YANG-TE] defines a YANG data model for the provisioning and management of TE tunnels, LSPs, and interfaces. It includes some protection and restoration data nodes relevant to this document. Management aspects of the SMP mechanism are outside the scope of this document, and they are expected to be addressed by other documents.
RFC 8776 [RFC8776]は、トラフィックエンジニアリング（TE）の構成と状態機能に関する一般的なYangデータ型のコレクションを定義しています。LSP保護タイプのいくつかのアイデンティティを定義します。このドキュメントで新しいLSP保護タイプを導入すると、[RFC8776]は、このドキュメントで指定されたSMPメカニズムをサポートするために更新されると予想されます。[Yang-Te]は、TEトンネル、LSP、およびインターフェイスのプロビジョニングと管理のためのYangデータモデルを定義しています。これには、このドキュメントに関連するいくつかの保護および復元データノードが含まれています。SMPメカニズムの管理的側面は、このドキュメントの範囲外であり、他のドキュメントで対処されることが期待されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
In addition, the reader is assumed to be familiar with the terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372].
さらに、読者は[RFC4872]、RFC 4426 [RFC4426]、およびRFC 6372 [RFC6372]で使用されている用語に精通していると想定されています。
[G808.3] defines the generic aspects of an SMP mechanism. [G873.3] defines the protection switching operation and associated protocol for SMP at the ODU layer. [RFC7412] provides requirements for any mechanism that would be used to implement SMP in an MPLS-TP network.
[G808.3]は、SMPメカニズムの一般的な側面を定義します。[G873.3]は、ODU層でのSMPの保護スイッチング操作と関連するプロトコルを定義します。[RFC7412]は、MPLS-TPネットワークにSMPを実装するために使用されるメカニズムの要件を提供します。
The SMP mechanism is based on precomputed protecting LSPs that are preconfigured into the network elements. Preconfiguration here means pre-reserving resources for the protecting LSPs without activating a particular protecting LSP (e.g., in circuit networks, the cross-connects in the intermediate nodes of the protecting LSP are not preestablished). Preconfiguring but not activating protecting LSPs allows link and node resources to be shared by the protecting LSPs of multiple working LSPs (which are themselves disjoint and thus unlikely to fail simultaneously). Protecting LSPs are activated in response to failures of working LSPs or operator commands by means of the APS protocol, which operates in the data plane. The APS protocol messages are exchanged along the protecting LSP. SMP is always revertive.
SMPメカニズムは、ネットワーク要素に事前に構成されたLSPを事前に保護することに基づいています。ここでの事前設定とは、特定の保護LSPをアクティブにせずにLSPを保護するための事前にリセービングするリソースを意味します（たとえば、回路ネットワークでは、保護LSPの中間ノードのクロスコネクトは事前に確立されていません）。リンクの保護をアクティブにすることはできませんが、LSPを保護することにより、リンクとノードのリソースを複数の作業LSPの保護LSP（それ自体が見逃す可能性が低い）によって共有されます。LSPの保護は、データプレーンで動作するAPSプロトコルを使用して、LSPまたは演算子コマンドの動作の障害に応じてアクティブになります。APSプロトコルメッセージは、保護LSPに沿って交換されます。SMPは常に戻ります。
SMP is very similar to SMR, except that activation in the case of SMR is achieved by control plane signaling during the recovery operation, while the same is done for SMP by the APS protocol in the data plane.
SMPはSMRに非常に似ていますが、SMRの場合の活性化は、回復操作中のコントロールプレーンシグナリングによって達成されますが、データプレーンのAPSプロトコルによってSMPについても同じことが行われます。
Consider the network topology shown in Figure 1:
図1に示すネットワークトポロジを考えてみましょう。
A---B---C---D
\ /
E---F---G
/ \
H---I---J---K
Figure 1: An Example of an SMP Topology
図1：SMPトポロジの例
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they have the same Tunnel Endpoint Address (as part of their SESSION object). However, these addresses are not the same in this example. Similar to SMR, this document defines a new LSP Protection Type of the secondary LSP as "Shared Mesh Protection" (see Section 6.1) to allow resource sharing along nodes E, F, and G. Examples of shared resources include the capacity of a link and the cross-connects in a node. In this case, the protecting LSPs are not merged (which is useful, since the paths diverge at G), but the resources along E, F, and G can be shared.
動作するLSP [a、b、c、d]および[h、i、j、k]は、LSPを保護することによって保護される可能性があります[a、e、f、g、d]および[h、e、f、g、それぞれk]。RFC 3209 [RFC3209]ごとに、これらの保護LSPのシグナル伝達中にリソース共有を達成するために、彼らは同じトンネルエンドポイントアドレス（セッションオブジェクトの一部として）を持っています。ただし、これらのアドレスはこの例では同じではありません。SMRと同様に、このドキュメントでは、セカンダリLSPの新しいLSP保護タイプを「共有メッシュ保護」（セクション6.1を参照）として定義して、ノードE、F、およびGに沿ったリソース共有を許可します。ノード内のクロス接続。この場合、保護LSPはマージされていません（これは、gでパスが分岐するため有用です）が、E、F、およびGに沿ったリソースを共有できます。
When a failure, such as Signal Fail (SF) or Signal Degrade (SD), occurs on one of the working LSPs (say, working LSP [A,B,C,D]), the end node (say, node A) that detects the failure initiates the protection switching operation. End node A will send a protection switching request APS message (for example, SF) to its adjacent (downstream) intermediate node (say, node E) to activate the corresponding protecting LSP and will wait for a confirmation message from node E.
信号障害（SF）または信号分解（SD）などの障害が動作LSPの1つ（たとえば、LSP [a、b、c、d]）で発生する場合、エンドノード（たとえば、ノードA）障害を検出すると、保護スイッチング操作が開始されます。エンドノードAは、保護スイッチングリクエストAPSメッセージ（SFなど）を隣接する（下流）中間ノード（たとえば、ノードE）に送信して、対応する保護LSPをアクティブにし、ノードEからの確認メッセージを待ちます。
If the protection resource is available, node E will send the confirmation APS message to the end node (node A) and forward the switching request APS message to its adjacent (downstream) node (say, node F). When the confirmation APS message is received by node A, the cross-connection on node A is established. At this time, traffic is bridged to and selected from the protecting LSP at node A. After forwarding the switching request APS message, node E will wait for a confirmation APS message from node F, which triggers node E to set up the cross-connection for the protecting LSP being activated.
保護リソースが利用可能な場合、ノードEは確認APSメッセージをエンドノード（ノードA）に送信し、スイッチングリクエストAPSメッセージを隣接（下流）ノード（たとえば、ノードF）に転送します。確認APSメッセージがノードAによって受信されると、ノードAのクロス接続が確立されます。この時点で、トラフィックはノードAの保護LSPに橋渡しされ、選択されていますAPSメッセージを転送した後、ノードEはノードFからの確認APSメッセージを待ちます。保護されているLSPがアクティブ化されています。
If the protection resource is not available (due to failure or being used by higher-priority connections), the switching will not be successful; the intermediate node (node E) MUST send a message to notify the end node (node A) (see Section 5.5). If the resource is in use by a lower-priority protecting LSP, the lower-priority service will be removed, and the intermediate node will then follow the procedure as described for the case when the protection resource is available for the higher-priority protecting LSP.
保護リソースが利用できない場合（障害またはより優先度の高い接続で使用されているため）、スイッチングは成功しません。中間ノード（ノードE）は、エンドノード（ノードA）に通知するメッセージを送信する必要があります（セクション5.5を参照）。LSPが低優先度の保護によって使用されている場合、より低優先度サービスが削除され、中間ノードがLSPを保護するために保護リソースが利用可能である場合に説明されている場合の手順に従います。。
If node E fails to allocate the protection resource, it MUST send a message to notify node A (see Section 5.5). Then, node A will stop bridging and selecting traffic to/from the protecting LSP and proceed with the procedure of removing the protection allocation according to the APS protocol.
ノードEが保護リソースの割り当てに失敗した場合、ノードAに通知するメッセージを送信する必要があります（セクション5.5を参照）。次に、ノードAは、LSPを保護するためにブリッジングしてトラフィックの選択を停止し、APSプロトコルに従って保護割り当てを削除する手順を進めます。
The following subsections detail how LSPs using SMP can be signaled in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 3473 [RFC3473]). This signaling enables:
以下のサブセクションでは、GMPLS RSVP-TE拡張機能を使用して、SMPを使用したLSPを相互運用可能な方法でどのようにシグナル伝えるかを詳しく説明しています（RFC 3473 [RFC3473]を参照）。このシグナリングは次のことを可能にします：
(1) the ability to identify a "secondary protecting LSP" (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, here called the "secondary LSP") used to recover another "primary working LSP" (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, here called the "protected LSP"),
(1) 図1から「lsp [a、e、f、g、d]またはlsp [h、e、f、g、k]）（ここでは「二次lsp」と呼ばれる）（lsp [a、e、f、g、d]またはlsp [h、e、f、g、k]）を識別する能力別の「主要な作業LSP」（LSP [A、B、C、D]またはLSP [H、I、J、K]を図1から回復します。
(2) the ability to associate the secondary LSP with the protected LSP,
(2) 二次LSPを保護されたLSPに関連付ける能力、
(3) the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP,
(3) セカンダリLSPをインスタンス化する際に保護されたLSPが使用するリソースに関する情報を含める機能、
(4) the capability to instantiate several secondary LSPs efficiently during the provisioning phase, and
(4) プロビジョニングフェーズ中にいくつかの二次LSPを効率的にインスタンス化する機能、および
(5) the capability to support activation of a secondary LSP via the APS protocol in the data plane if a failure occurs.
(5) 障害が発生した場合、データプレーンのAPSプロトコルを介して二次LSPの活性化をサポートする機能。
To simplify association operations, both LSPs (i.e., the protected LSP and the secondary LSP) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP and the secondary LSP.
協会の操作を簡素化するために、LSP（つまり、保護されたLSPとセカンダリLSP）の両方が同じセッションに属します。したがって、セッションオブジェクトは両方のLSPで同じでなければなりません。ただし、LSP IDは、保護されたLSPとセカンダリLSPを区別するために異なる必要があります。
A new LSP Protection Type, "Shared Mesh Protection", is defined (see Section 6.1) for the LSP Flags field of the PROTECTION object (see [RFC4872]) to set up the two LSPs. This LSP Protection Type value is only applicable to bidirectional LSPs as required in [G808.3].
新しいLSP保護タイプ「共有メッシュ保護」は、保護オブジェクトのLSPフラグフィールド（[RFC4872]を参照）の定義（セクション6.1を参照）を定義して、2つのLSPをセットアップします。このLSP保護タイプの値は、[G808.3]で必要な双方向LSPにのみ適用できます。
The PROTECTION object (see [RFC4872]) is included in the Path message during signaling of the primary working LSPs, with the LSP Protection Type value set to "Shared Mesh Protection".
保護オブジェクト（[RFC4872]を参照）は、主要な作業LSPのシグナリング中にパスメッセージに含まれ、LSP保護タイプ値は「共有メッシュ保護」に設定されています。
Primary working LSPs are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and the N bit to 1; and setting in the ASSOCIATION object the Association ID to the associated secondary protecting LSP_ID.
プライマリ作業LSPは、保護オブジェクトにSビットを0、pビット0に、nビットを1に設定することによりシグナル伝達されます。Association Objectの設定LSP_IDを保護する関連する二次的なID。
Note: The N bit is set to indicate that the protection switching signaling is done via the data plane.
注：nビットは、保護スイッチングシグナリングがデータプレーンを介して行われることを示すように設定されています。
The PROTECTION object (see [RFC4872]) is included in the Path message during signaling of the secondary protecting LSPs, with the LSP Protection Type value set to "Shared Mesh Protection".
保護オブジェクト（[rfc4872]を参照）は、LSP保護タイプの値を「共有メッシュ保護」に設定して、二次保護LSPのシグナリング中にパスメッセージに含まれています。
Secondary protecting LSPs are signaled by setting in the PROTECTION object the S bit, the P bit, and the N bit to 1; and setting in the ASSOCIATION object the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP MUST include at least one PRIMARY_PATH_ROUTE object (see [RFC4872]) that further allows for recovery resource sharing at each intermediate node along the secondary path.
二次保護LSPは、保護オブジェクトにsビット、pビット、およびnビットを1に設定することによりシグナル伝達されます。アソシエーションオブジェクトでは、関連するプライマリワーキングLSP_IDへの関連付けIDを設定します。これは、セカンダリLSPのシグナリングの前に知られている必要があります。さらに、セカンダリLSPをインスタンス化するために使用されるパスメッセージには、セカンダリパスに沿った各中間ノードでの回復リソース共有をさらに可能にする少なくとも1つのプライマリ_Path_Routeオブジェクト（[RFC4872を参照]を参照）を含める必要があります。
With this setting, the resources for the secondary LSP MUST be pre-reserved but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this LSP. Activation of a secondary LSP and protection switching to the activated protecting LSP is done using the APS protocol in the data plane.
この設定では、セカンダリLSPのリソースは事前に予約されている必要がありますが、データプレーンレベルではコミットされていない必要があります。つまり、このLSPをアクティブにするために明示的なアクションが取られるまで、スイッチの内部を確立する必要はありません。二次LSPの活性化と活性化保護LSPへの保護の切り替えは、データプレーンのAPSプロトコルを使用して行われます。
After protection switching completes, the protecting LSP MUST be signaled by setting the S bit to 0 and the O bit to 1 in the PROTECTION object. At this point, the link and node resources MUST be allocated for this LSP, which becomes a primary LSP (ready to carry traffic). The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).
保護スイッチングが完了した後、保護オブジェクトのSビットを0に、Oビットを1に設定することにより、保護LSPを信号する必要があります。この時点で、このLSPにリンクリソースとノードリソースを割り当てる必要があります。このLSPは、プライマリLSP（トラフィックを運ぶ準備ができています）になります。以前に作業していたLSPは、Admin_Statusオブジェクトに少し設定されたものでシグナルを受けることができます（[RFC3473]を参照）。
Support for extra traffic in SMP is left for further study. Therefore, mechanisms to set up LSPs for extra traffic are outside the scope of this document.
SMPの追加トラフィックのサポートは、さらなる研究のために残されています。したがって、追加のトラフィックのためにLSPをセットアップするメカニズムは、このドキュメントの範囲外です。
The SMP preemption priority of a protecting LSP is used by the APS protocol to resolve competition for shared resources among multiple protecting LSPs and is indicated in the Preemption Priority field of the PROTECTION object in the Path message of the protecting LSP.
保護LSPのSMP先制優先度は、APSプロトコルによって使用され、複数の保護LSPの間で共有リソースの競争を解決し、保護LSPのパスメッセージの保護オブジェクトの先制優先フィールドに示されています。
The Setup and Holding priorities in the SESSION_ATTRIBUTE object can be used by GMPLS to control LSP preemption, but they are not used by the APS to resolve competition among multiple protecting LSPs. This avoids the need to define a complex policy for defining Setup and Holding priorities when used for both GMPLS control plane LSP preemption and SMP shared resource competition resolution.
session_attributeオブジェクトのセットアップと保持優先順位は、GMPLSによってLSPのプリエンプションを制御するために使用できますが、複数の保護LSP間の競争を解決するためにAPSによって使用されません。これにより、GMPLSコントロールプレーンLSPプリエンプションとSMP共有リソース競争の解決の両方に使用される場合、セットアップを定義し、優先順位を保持するための複雑なポリシーを定義する必要性が回避されます。
When an intermediate node on the protecting LSP receives the Path message, the priority value in the Preemption Priority field MUST be stored for that protecting LSP. When resource competition among multiple protecting LSPs occurs, the APS protocol will use their priority values to resolve this competition. A lower value has a higher priority.
保護LSPの中間ノードがパスメッセージを受信する場合、PREEPTION PRIORITYフィールドの優先度値は、LSPを保護するために保存する必要があります。複数の保護LSP間のリソース競合が発生すると、APSプロトコルは優先値を使用してこの競争を解決します。値が低いと優先度が高くなります。
In SMP, a preempted LSP MUST NOT be terminated even after its resources have been deallocated. Once the working LSP and the protecting LSP are configured or preconfigured, the end node MUST keep refreshing both working and protecting LSPs, regardless of failure or preemption status.
SMPでは、リソースが扱われた後でも、先制型LSPを終了してはなりません。動作LSPと保護LSPが構成または事前に構成されたら、故障状態や先制ステータスに関係なく、ENDノードが機能し、LSPを保護し続ける必要があります。
When a lower-priority protecting LSP is preempted, the intermediate node that performed the preemption MUST send a Notify message with error code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared resources unavailable" (17) to the end nodes of that protecting LSP. Upon receipt of this Notify message, the end node MUST stop sending and selecting traffic to/from its protecting LSP and try switching the traffic to another protecting LSP, if available.
LSPの低優先度保護が先制される場合、プリエンプションを実行した中間ノードは、エラーコード「Notify Error」（25）（[RFC4872]を参照）とエラーサブコード「共有リソースを利用できない」（17」で通知メッセージを送信する必要があります。）LSPを保護するその最終ノードに。この通知メッセージを受信すると、エンドノードは、LSPの保護との間でトラフィックの送信と選択を停止し、利用可能な場合はトラフィックを別の保護LSPに切り替えることを試みる必要があります。
When a protecting LSP occupies the shared resources and they become unavailable, the same Notify message MUST be generated by the intermediate node to all the end nodes of the protecting LSPs that have lower SMP preemption priorities than the one that has occupied the shared resources. If the shared resources become unavailable due to a failure in the shared resources, the same Notify message MUST be generated by the intermediate node to all the end nodes of the protecting LSPs that have been configured to use the shared resources. In the case of a failure of the working LSP, these end nodes MUST avoid trying to switch traffic to these protecting LSPs that have been configured to use the shared resources and try switching the traffic to other protecting LSPs, if available.
保護するLSPが共有リソースを占有し、利用できない場合、共有リソースを占有しているものよりもSMP先制優先度が低い保護LSPのすべてのエンドノードに対して、中間ノードによって同じ通知メッセージを生成する必要があります。共有リソースが共有リソースの障害により利用できなくなった場合、共有リソースを使用するように構成されている保護LSPのすべてのエンドノードに対して中間ノードによって同じ通知メッセージを生成する必要があります。作業LSPの障害の場合、これらのエンドノードは、共有リソースを使用するように構成されているこれらの保護LSPにトラフィックを切り替えようとすることを避け、利用可能な場合は他の保護LSPにトラフィックを切り替えることを試みる必要があります。
When the shared resources become available, a Notify message with error code "Notify Error" (25) and error sub-code "Shared resources available" (18) MUST be generated by the intermediate node. The recipients of this Notify message are the end nodes of the lower-priority protecting LSPs that have been preempted and/or all the end nodes of the protecting LSPs that have lower SMP preemption priorities than the one that does not need the shared resources anymore. Upon receipt of this Notify message, the end node is allowed to reinitiate the protection switching operation as described in Section 4, if it still needs the protection resource.
共有リソースが利用可能になると、エラーコード「Notify Error」（25）とエラーサブコード「共有リソースが利用可能」（18）を使用した通知メッセージは、中間ノードによって生成する必要があります。このNotifyメッセージの受信者は、Preemptedが先行しているLSPを保護する優先度の低いノードおよび/またはSMP先制優先度が低いLSPのすべてのエンドノードの最終ノードが、共有リソースを必要としないものよりも低いLSPです。この通知メッセージを受信すると、エンドノードは、保護リソースが必要な場合は、セクション4で説明されているように保護スイッチング操作を再現できます。
SMP relies on APS protocol messages being exchanged between the nodes along the path to activate a protecting LSP.
SMPは、パスに沿ってノード間で交換されているAPSプロトコルメッセージに依存して、保護LSPをアクティブにします。
In order to allow the exchange of APS protocol messages, an APS channel has to be configured between adjacent nodes along the path of the protecting LSP. This is done by means other than GMPLS signaling, before any protecting LSP has been set up. Therefore, there are likely additional requirements for APS configuration that are outside the scope of this document.
APSプロトコルメッセージの交換を許可するには、APSチャネルを保護LSPのパスに沿って隣接するノード間で構成する必要があります。これは、保護LSPがセットアップされる前に、GMPLSシグナリング以外の手段によって行われます。したがって、このドキュメントの範囲外のAPS構成には追加の要件がある可能性があります。
Depending on the APS protocol message format, the APS protocol may use different identifiers than GMPLS signaling to identify the protecting LSP.
APSプロトコルメッセージ形式に応じて、APSプロトコルは、保護LSPを識別するためにGMPLSシグナリングとは異なる識別子を使用する場合があります。
Since the APS protocol is left for further study per [G808.3], it can be assumed that the APS message format and identifiers are technology specific and/or vendor specific. Therefore, additional requirements for APS configuration are outside the scope of this document.
APSプロトコルは[G808.3]ごとにさらに調査するために残されているため、APSメッセージ形式と識別子はテクノロジー固有および/またはベンダー固有であると想定できます。したがって、APS構成の追加要件は、このドキュメントの範囲外です。
GMPLS extension requirements for SMP introduce several updates to the PROTECTION object (see [RFC4872]), as detailed below.
GMPLS SMPの拡張要件は、以下に詳述するように、保護オブジェクトにいくつかの更新を導入します（[RFC4872]を参照）。
A new LSP Protection Type, "Shared Mesh Protection", is added in the PROTECTION object. This LSP Protection Type value is only applicable to bidirectional LSPs.
新しいLSP保護タイプ「共有メッシュ保護」が保護オブジェクトに追加されます。このLSP保護タイプの値は、双方向LSPにのみ適用されます。
LSP (Protection Type) Flags:
LSP（保護タイプ）フラグ：
0x20: Shared Mesh Protection
0x20：共有メッシュ保護
The rules defined in Section 14.2 of [RFC4872] ensure that all the nodes along an SMP LSP are SMP aware. Therefore, there are no backward-compatibility issues.
[RFC4872]のセクション14.2で定義されているルールは、SMP LSPに沿ったすべてのノードがSMP認識であることを保証します。したがって、後方互換性の問題はありません。
The definitions of the N and O bits in Section 14.1 of [RFC4872] are replaced as follows:
[RFC4872]のセクション14.1のNおよびOビットの定義は、次のように置き換えられます。
Notification (N): 1 bit
通知（n）：1ビット
When set to 1, this bit indicates that the control plane message exchange is only used for notification during protection switching. When set to 0 (default), it indicates that the control plane message exchanges are used for purposes of protection switching. The N bit is only applicable when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). The N bit MUST be set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set to 1.
1に設定すると、このビットは、コントロールプレーンのメッセージ交換が保護スイッチング中の通知にのみ使用されることを示しています。0（デフォルト）に設定すると、コントロールプレーンのメッセージ交換が保護スイッチングの目的で使用されることを示します。nビットは、LSP保護タイプフラグが0x04（1：Nエクストラフィックのある保護）、0x08（1 1単方向保護）、0x10（1 1双方向保護）、または0x20（共有メッシュ保護）に設定されている場合にのみ適用可能です。。Nビットは、他の場合は0に設定する必要があります。0x20（SMP）の場合、Nビットを1に設定する必要があります。
Operational (O): 1 bit
操作（o）：1ビット
When set to 1, this bit indicates that the protecting LSP is carrying traffic after protection switching. The O bit is only applicable when (1) the P bit is set to 1 and (2) the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). The O bit MUST be set to 0 in any other case.
1に設定すると、このビットは、保護LSPが保護スイッチング後にトラフィックを運ぶことを示しています。oビットは、（1）pビットが1に設定され、（2）LSP保護タイプフラグが0x04（1：nトラフィック以外の保護）、0x08（1 1単方向保護）、0x10に設定されている場合にのみ適用されます。（1 1双方向保護）、または0x20（共有メッシュ保護）。O BITは、他の場合は0に設定する必要があります。
[RFC4872] reserved a 32-bit field in the PROTECTION object header. Subsequently, [RFC4873] allocated several bits from that field and left the remainder of the bits reserved. This specification further allocates the Preemption Priority field from the remaining formerly reserved bits. The 32-bit field in the PROTECTION object as defined in [RFC4872] and modified by [RFC4873] is updated by this document as follows:
[RFC4872]保護オブジェクトヘッダーに32ビットフィールドを予約しました。その後、[RFC4873]はそのフィールドからいくつかのビットを割り当て、残りのビットを予約したままにしました。この仕様では、以前は残りのビットからのプリエンプション優先度フィールドをさらに割り当てます。[RFC4872]で定義され、[RFC4873]によって変更された保護オブジェクトの32ビットフィールドは、次のようにこのドキュメントで更新されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved | Preempt Prio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority (Preempt Prio): 8 bits
プリエンプション優先度（Preempt Prio）：8ビット
This field indicates the SMP preemption priority of a protecting LSP, when the LSP Protection Type field indicates "Shared Mesh Protection". The SMP preemption priority value is configured at the end nodes of the protecting LSP by a network operator. A lower value has a higher priority. The decision regarding how many priority levels should be implemented in an SMP network is left to network operators.
このフィールドは、LSP保護タイプのフィールドが「共有メッシュ保護」を示す場合、LSPの保護のSMP先制優先度を示しています。SMPプリエンプションの優先順位値は、ネットワークオペレーターによってLSPを保護するエンドノードで構成されています。値が低いと優先度が高くなります。SMPネットワークに実装されるべき優先レベルの数に関する決定は、ネットワークオペレーターに任されています。
See [RFC4873] for the definitions of the other fields.
他のフィールドの定義については、[RFC4873]を参照してください。
IANA maintains a group of registries called "Resource Reservation Protocol (RSVP) Parameters", which includes the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. IANA has added the following values to the "Sub-Codes - 25 Notify Error" subregistry, which lists error value sub-codes that may be used with error code 25. IANA has allocated the following error value sub-codes (Table 1) for use with this error code as described in this document.
IANAは、「エラーコードとグローバルに定義されたエラー値サブコード」レジストリを含む「リソース予約プロトコル（RSVP）パラメーター」と呼ばれるレジストリのグループを維持しています。IANAは次の値を「サブコード-25通知エラー」サブレジストリに追加しました。これは、エラーコード25で使用できるエラー値サブコードをリストします。IANAは、次のエラー値サブコード（表1）を割り当てました（表1）このドキュメントで説明されているように、このエラーコードで使用します。
+=======+==============================+===========+
| Value | Description | Reference |
+=======+==============================+===========+
| 17 | Shared resources unavailable | RFC 9270 |
+-------+------------------------------+-----------+
| 18 | Shared resources available | RFC 9270 |
+-------+------------------------------+-----------+
Table 1: New Error Sub-Codes
表1：新しいエラーサブコード
Since this document makes use of the exchange of RSVP messages that include a Notify message, the security threats discussed in [RFC4872] also apply to this document.
このドキュメントでは、通知メッセージを含むRSVPメッセージの交換を使用しているため、[RFC4872]で説明されているセキュリティの脅威もこのドキュメントに適用されます。
Additionally, it may be possible to cause disruption to traffic on one protecting LSP by targeting a link used by the primary LSP of another, higher-priority LSP somewhere completely different in the network. For example, in Figure 1, assume that the preemption priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] and the protecting LSP [H,E,F,G,K] is being used to transport traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted. For this reason, it is important not only to use security mechanisms as discussed in [RFC4872] but also to acknowledge that detailed knowledge of a network's topology, including routes and priorities of LSPs, can help an attacker better target or improve the efficacy of an attack.
さらに、ネットワーク内で完全に異なる別のLSPのプライマリLSPが使用するリンクをターゲットにすることにより、LSPを保護する1つのLSPのトラフィックの破壊を引き起こすことが可能かもしれません。たとえば、図1では、LSP [a、e、f、g、d]の先制の優先度は、lsp [h、e、f、g、k]のそれよりも高いと仮定します。、f、g、k]はトラフィックの輸送に使用されています。Link B-Cが攻撃された場合、LSP [H、E、F、G、K]のトラフィックが破壊される可能性があります。このため、[RFC4872]で説明されているようにセキュリティメカニズムを使用するだけでなく、LSPのルートや優先順位を含むネットワークのトポロジの詳細な知識が、攻撃者のターゲットを改善または改善することが重要であることを認識することも重要です。攻撃。
[G808.3] International Telecommunication Union, "Generic protection switching - Shared mesh protection", ITU-T Recommendation G.808.3, October 2012, <https://www.itu.int/rec/T-REC-G.808.3>.
[G808.3] International Telecommunication Union、「一般的な保護スイッチング - 共有メッシュ保護」、ITU-T推奨G.808.3、2012年10月、<https://www.itu.int/rec/t-rec-g.808.3>。
[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>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSPトンネルのRSVPへの拡張"、RFC 3209、doi10.17487/rfc3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、DOI 10.17487/RFC3473、2003年1月、<HTTPS：//www.rfc-editor.org/info/rfc3473>。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, DOI 10.17487/RFC4426, March 2006, <https://www.rfc-editor.org/info/rfc4426>.
[RFC4426] Lang、J.、ed。、Rajagopalan、B.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様」、RFC 4426、DOI 10.17487/RFC4426、2006年3月、<https://www.rfc-editor.org/info/rfc4426>。
[RFC4872] Lang, J P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, <https://www.rfc-editor.org/info/rfc4872>.
[RFC4872] Lang、J P.、Ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンドの一般化マルチプロトコルラベルスイッチング（GMPLS）Recovery "、RFC 4872、DOI 10.17487/RFC4872、2007年5月、<https://www.rfc-editor.org/info/rfc4872>。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、DOI 10.17487/RFC4873、2007年5月、<https：//www.rfc-editor.org/info/rfc4873>。
[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>。
[G873.3] International Telecommunication Union, "Optical transport network - Shared mesh protection", ITU-T Recommendation G.873.3, September 2017, <https://www.itu.int/rec/T-REC-G.873.3-201709-I/en>.
[G873.3] International Telecommunication Union、「光学輸送ネットワーク - 共有メッシュ保護」、ITU-T推奨G.873.3、2017年9月、<https://www.itu.int/rec/t-rec-g.873.3-201709-I/en>。
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, DOI 10.17487/RFC6372, September 2011, <https://www.rfc-editor.org/info/rfc6372>.
[RFC6372] Sprecher、N.、ed。and A. Farrel、ed。、「MPLS輸送プロファイル（MPLS-TP）Survivability Framework」、RFC 6372、DOI 10.17487/RFC6372、2011年9月、<https://www.rfc-editor.org/info/rfc6372>。
[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, December 2014, <https://www.rfc-editor.org/info/rfc7412>.
[RFC7412] Weingarten、Y.、Aldrin、S.、Pan、P.、Ryoo、J。、およびG. Mirsky、「MPLS輸送プロファイルの要件（MPLS-TP）共有メッシュ保護」、RFC 7412、DOI 10.17487/RFC7412、2014年12月、<https://www.rfc-editor.org/info/rfc7412>。
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", RFC 8776, DOI 10.17487/RFC8776, June 2020, <https://www.rfc-editor.org/info/rfc8776>.
[RFC8776] Saad、T.、Gandhi、R.、Liu、X.、Beeram、V。、およびI. Bryskin、「トラフィックエンジニアリングの一般的なYangデータタイプ」、RFC 8776、DOI 10.17487/RFC8776、2020年6月、<https://www.rfc-editor.org/info/rfc8776>。
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V.P., Bryskin, I., and O. Gonzalez de Dios, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-30, 11 July 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-teas-yang-te-30>.
[Yang-Te] Saad、T.、Gandhi、R.、Liu、X.、Bearam、V.P.、Bryskin、I。、およびO. Gonzalez de Dios、「トラフィックエンジニアリングトンネルのヤンデータモデル、ラベルスイッチ付きパス、およびインターフェイス "、作業中の作業、インターネットドラフト、ドラフト-teas-yang-te-30、2022年7月11日、<https://datatracker.ietf.org/doc/html/ draft-ietf-teas-yang-TE-30>。
Acknowledgements
謝辞
The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram, Tom Petch, Ines Robles, John Scudder, Dale Worley, Dan Romascanu, Éric Vyncke, Roman Danyliw, Paul Wouters, Lars Eggert, Francesca Palombini, and Robert Wilton for their valuable comments and suggestions on this document.
著者は、エイドリアン・ファレル、ヴィシュヌ・パヴァン・ビアラム、トム・ペッチ、イネス・ロブレス、ジョン・スカダー、デール・ウォーリー、ダン・ロマスカヌ、エリック・ヴィンケ、ローマン・ダニリウ、ポール・ヴェルター、ラース・エガート、フランスカ・パロビニ、ロバート・ウィルトンの貴重なコメントに感謝します。このドキュメントに関する提案。
Contributors
貢献者
The following person contributed significantly to the content of this document and should be considered a coauthor.
次の人はこのドキュメントの内容に大きく貢献し、共著者と見なされるべきです。
Yuji Tochio Fujitsu Email: tochio@fujitsu.com
Yuji Tochio Fujitsuメール：tochio@fujitsu.com
Authors' Addresses
著者のアドレス
Jia He Huawei Technologies F3-1B, R&D Center, Huawei Industrial Base Bantian, Longgang District Shenzhen China Email: hejia@huawei.com
Jia He Huawei Technologies F3-1B、R＆D Center、Huawei Industrial Base Bantian、Longgang District Shenzhen China Email：hejia@huawei.com
Italo Busi Huawei Technologies Email: italo.busi@huawei.com
Italo Busi Huawei Technologies Email：Italo.busi@huawei.com
Jeong-dong Ryoo ETRI 218 Gajeongno Yuseong-gu Daejeon 34129 South Korea Phone: +82-42-860-5384 Email: ryoo@etri.re.kr
Jeong-Dong Ryoo Etri 218 Gajeongno Yusong-Gu Daejeon 34129韓国電話：82-42-860-5384メール：ryoo@etri.re.kr
Bin Yeong Yoon ETRI Email: byyun@etri.re.kr
Bin Yeong Yoon Etri Email：byyun@etri.re.kr
Peter Park KT Email: peter.park@kt.com
Peter Park KTメール：peter.park@kt.com