[要約] RFC 8359は、ネットワークによって割り当てられる上流ラベルに関する仕様です。その目的は、ネットワークの効率を向上させ、ラベルの割り当てをより効果的に行うことです。
Internet Engineering Task Force (IETF) X. Zhang, Ed.
Request for Comments: 8359 Huawei Technologies
Updates: 3471, 3473, 6205 V. Beeram, Ed.
Category: Standards Track Juniper Networks
ISSN: 2070-1721 I. Bryskin
Huawei Technologies
D. Ceccarelli
Ericsson
O. Gonzalez de Dios
Telefonica
March 2018
Network-Assigned Upstream Label
ネットワーク割り当てのアップストリームラベル
Abstract
概要
This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.
このドキュメントでは、ネットワークが双方向ラベルスイッチドパス（LSP）のアップストリームラベルを割り当てることを可能にする、トラフィックエンジニアリング（RSVP-TE）メカニズムを備えた汎用マルチプロトコルラベルスイッチング（GMPLS）リソースreSerVationプロトコルについて説明します。これは、特定のノードに適切な上流ラベルを独自に割り当てるのに十分な情報がなく、適切なラベルを選択するために下流ノードに依存する必要があるシナリオで役立ちます。このドキュメントは、UPSTREAM_LABELオブジェクトの特別なラベル値の処理を定義しているため、RFC 3471、3473、および6205を更新しています。
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/rfc8359.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8359で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3
3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5
4. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5
4.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
A functional description of the Generalized Multi-Protocol Label Switching (GMPLS) signaling extensions for setting up a bidirectional Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions for setting up a bidirectional LSP are specified in [RFC3473]. The bidirectional LSP setup is indicated by the presence of an UPSTREAM_LABEL object in the Path message. As per the existing setup procedure outlined for a bidirectional LSP, each upstream node must allocate a valid upstream label on the outgoing interface before sending the initial Path message downstream. However, there are certain scenarios (see Section 4) where it is not desirable or possible for a given node to pick the upstream label on its own.
双方向ラベルスイッチドパス（LSP）を設定するための一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング拡張の機能説明は、[RFC3471]で提供されています。双方向LSPをセットアップするためのGMPLS Resource reSerVation Protocol with Traffic Engineering（RSVP-TE）extensionsは、[RFC3473]で指定されています。双方向LSPセットアップは、Pathメッセージ内のUPSTREAM_LABELオブジェクトの存在によって示されます。双方向LSPで説明されている既存のセットアップ手順に従って、各アップストリームノードは、初期Pathメッセージをダウンストリームに送信する前に、発信インターフェイスに有効なアップストリームラベルを割り当てる必要があります。ただし、特定のノードが独自にアップストリームラベルを選択することが望ましくない、または不可能である特定のシナリオ（セクション4を参照）があります。
This document defines the protocol mechanism to be used in such scenarios. This mechanism enables a given node to offload the task of assigning the upstream label for a given bidirectional LSP to nodes downstream in the network. It is meant to be used only for bidirectional LSPs that assign symmetric labels at each hop along the path of the LSP. Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda labels (format specified in [RFC6205]) at each hop along the path of the LSP.
このドキュメントでは、そのようなシナリオで使用されるプロトコルメカニズムを定義します。このメカニズムにより、特定のノードは、特定の双方向LSPのアップストリームラベルをネットワークのダウンストリームノードに割り当てるタスクをオフロードできます。これは、LSPのパスに沿った各ホップで対称ラベルを割り当てる双方向LSPに対してのみ使用されることを意図しています。双方向ラムダスイッチ対応（LSC）LSPは、LSPのパスに沿った各ホップで対称ラムダラベル（[RFC6205]で指定された形式）を使用します。
As per the bidirectional LSP setup procedures specified in [RFC3471] and [RFC3473], the UPSTREAM_LABEL object must indicate a label that is valid for forwarding. This document updates that by allowing the UPSTREAM_LABEL object to indicate a special label that isn't valid for forwarding. As per the bidirectional LSC LSP setup procedures specified in [RFC6205], the LABEL_SET object and the UPSTREAM_LABEL object must contain the same label value. This document updates that by allowing the UPSTREAM_LABEL object to carry a special label value that is different from the one used in the LABEL_SET object.
[RFC3471]と[RFC3473]で指定されている双方向のLSPセットアップ手順に従って、UPSTREAM_LABELオブジェクトは転送に有効なラベルを示す必要があります。このドキュメントでは、UPSTREAM_LABELオブジェクトが転送に無効な特別なラベルを示すことを許可することで、このドキュメントを更新しています。 [RFC6205]で指定されている双方向LSC LSPセットアップ手順に従って、LABEL_SETオブジェクトとUPSTREAM_LABELオブジェクトには同じラベル値が含まれている必要があります。このドキュメントでは、UPSTREAM_LABELオブジェクトがLABEL_SETオブジェクトで使用されているものとは異なる特別なラベル値を運ぶことができるようにすることで、そのことを更新しています。
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 defines a special label value -- "0xFFFFFFFF" (for a 4-octet label) -- to indicate an Unassigned Upstream Label. Similar "all-ones" patterns are expected to be used for labels of other sizes.
このドキュメントでは、「0xFFFFFFFF」（4オクテットラベルの場合）という特別なラベル値を定義して、未割り当てのアップストリームラベルを示しています。同様の「すべて1」のパターンは、他のサイズのラベルに使用されることが期待されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern
図1：割り当てられていないUPSTREAM_LABEL-「すべて1」のパターン
The presence of this value in the UPSTREAM_LABEL object of a Path message indicates that the upstream node has not assigned an upstream label on its own and has requested the downstream node to provide a label that it can use in both the forward and reverse directions.
PathメッセージのUPSTREAM_LABELオブジェクトにこの値が存在することは、上流ノードが独自に上流ラベルを割り当てておらず、下流ノードに、順方向と逆方向の両方で使用できるラベルを提供するように要求していることを示します。
The presence of this value in the UPSTREAM_LABEL object of a Path message MUST also be interpreted by the receiving node as a request to mandate symmetric labels for the LSP.
PathメッセージのUPSTREAM_LABELオブジェクトにこの値が存在することも、LSPの対称ラベルを要求する要求として受信ノードによって解釈される必要があります。
The scope of the procedures is limited to the exchange and processing of messages between an upstream node and its immediate downstream node. The Unassigned Upstream Label is used by an upstream node when it is not in a position to pick the upstream label on its own. In such a scenario, the upstream node sends a Path message downstream with an Unassigned Upstream Label and requests the downstream node to provide a symmetric label. If the upstream node desires to make the downstream node aware of its limitations with respect to label selection, it MUST specify a list of valid labels via the LABEL_SET object as specified in [RFC3473].
手順の範囲は、上流ノードとその直下の下流ノードの間のメッセージの交換と処理に限定されます。未割り当てのアップストリームラベルは、アップストリームラベルを独自に選択する位置にないときに、アップストリームノードによって使用されます。このようなシナリオでは、アップストリームノードは、未割り当てのアップストリームラベルとともにパスメッセージをダウンストリームに送信し、ダウンストリームノードに対称ラベルを提供するように要求します。上流ノードが下流ノードにラベル選択に関する制限を認識させたい場合、[RFC3473]で指定されているように、LABEL_SETオブジェクトを介して有効なラベルのリストを指定する必要があります。
In response, the downstream node picks an appropriate symmetric label and sends it via the LABEL object in the Resv message. The upstream node would then start using this symmetric label for both directions of the LSP. If the downstream node cannot pick the symmetric label, it MUST issue a PathErr message with a "Routing Problem/Unacceptable Label Value" indication. If the upstream node that signals an Unassigned Upstream Label receives a label with the "all-ones" pattern or any other unacceptable label in the LABEL object of the Resv message, it MUST issue a ResvErr message with a "Routing Problem/Unacceptable Label Value" indication.
それに応答して、ダウンストリームノードは適切な対称ラベルを選択し、ResvメッセージのLABELオブジェクトを介して送信します。アップストリームノードは、LSPの両方向でこの対称ラベルの使用を開始します。ダウンストリームノードが対称ラベルを選択できない場合、「ルーティングの問題/許容できないラベル値」を示すPathErrメッセージを発行する必要があります。未割り当てのアップストリームラベルを通知するアップストリームノードが、ResvメッセージのLABELオブジェクトで「すべて1」パターンのラベルまたはその他の許容できないラベルを受信した場合、「ルーティングの問題/許容できないラベルの値」を含むResvErrメッセージを発行する必要があります。 "表示。
The upstream node will continue to signal the Unassigned Upstream Label in the Path message even after it receives an appropriate symmetric label in the Resv message. This is done to make sure that the downstream node would pick a different symmetric label if and when it needs to change the label at a later time. If the upstream node receives an unacceptable changed label, then it MUST issue a ResvErr message with a "Routing Problem/Unacceptable Label Value" indication.
アップストリームノードは、Resvメッセージで適切な対称ラベルを受信した後でも、Pathメッセージで未割り当てのアップストリームラベルを通知し続けます。これは、後でラベルを変更する必要がある場合に、ダウンストリームノードが異なる対称ラベルを選択するようにするために行われます。アップストリームノードが受け入れられない変更されたラベルを受信した場合、「ルーティングの問題/受け入れられないラベル値」を示すResvErrメッセージを発行する必要があります。
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
Path
Upstream Label (Unassigned)
Label-Set (L1, L2 ... Ln)
------------------->
Resv
Label (Assigned - L2)
<-------------------
Figure 2: Signaling Sequence
図2：シグナリングシーケンス
If the downstream node is running an implementation that doesn't support the semantics of an Unassigned UPSTREAM LABEL, it will either (a) reject the special label value and generate an error as specified in Section 3.1 of [RFC3473] or (b) accept it and treat it as a valid label.
ダウンストリームノードが未割り当てのUPSTREAM LABELのセマンティクスをサポートしない実装を実行している場合、（a）特別なラベル値を拒否し、[RFC3473]のセクション3.1で指定されているエラーを生成するか、または（b）受け入れるそれを有効なラベルとして扱います。
If the behavior that is exhibited is (a), then there are no backwards compatibility concerns. If the behavior that is exhibited is (b), then the downstream node will send a label with the "all-ones" pattern in the LABEL object of the Resv message. In response, the upstream node will issue a ResvErr message with a "Routing Problem/ Unacceptable Label Value" indication.
示されている動作が（a）の場合、後方互換性の問題はありません。示されている動作が（b）の場合、ダウンストリームノードは、ResvメッセージのLABELオブジェクトに「すべて1」のパターンのラベルを送信します。それに応じて、上流ノードは「ルーティングの問題/許容できないラベル値」を示すResvErrメッセージを発行します。
Consider the network topology depicted in Figure 3. Nodes A and B are client IP routers that are connected to an optical Wavelength Division Multiplexing (WDM) transport network. F and I represent WDM nodes. The transponder sits on the router and is directly connected to the add-drop port on a WDM node.
図3に示すネットワークトポロジを考えてみます。ノードAおよびBは、光波長分割多重（WDM）トランスポートネットワークに接続されているクライアントIPルーターです。 FとIはWDMノードを表します。トランスポンダはルータ上にあり、WDMノードのアド/ドロップポートに直接接続されています。
The optical signal originating on "Router A" is tuned to a particular wavelength. On "WDM-Node F", it gets multiplexed with optical signals at other wavelengths. Depending on the implementation of this multiplexing function, it may not be acceptable to have the router send the signal into the optical network unless it is at the appropriate wavelength. In other words, having the router send signals with a wrong wavelength may adversely impact existing optical trails. If the clients do not have full visibility into the optical network, they are not in a position to pick the correct wavelength in advance.
「ルーターA」から発信される光信号は、特定の波長に調整されます。 「WDM-Node F」では、他の波長の光信号と多重化されます。この多重化機能の実装によっては、適切な波長でない限り、ルーターが信号を光ネットワークに送信することが受け入れられない場合があります。言い換えると、ルータに間違った波長の信号を送信させると、既存の光跡に悪影響を与える可能性があります。クライアントが光ネットワークを完全に認識できない場合、クライアントは事前に正しい波長を選択することができません。
The rest of this section examines how the protocol mechanism proposed in this document allows the optical network to select and communicate the correct wavelength to its clients.
このセクションの残りの部分では、このドキュメントで提案されているプロトコルメカニズムを使用して、光ネットワークが正しい波長を選択し、クライアントに通信する方法について説明します。
+---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
Path
Upstream Label (Unassigned/0xFFFFFFFF)
--------------------->
-- ~~ -- ~~ -->
Path
-------------------->
Resv
<--------------------
<-- ~~ -- ~~ --
Resv
Label (Assigned)
<---------------------
Figure 3: Initial Setup Sequence
図3：初期セットアップシーケンス
Steps:
手順：
o "Router A" does not have enough information to pick an appropriate client wavelength. It sends a Path message downstream requesting the network to assign an appropriate symmetric label for its use. Since the client wavelength is unknown, the laser is off at the ingress client.
o 「ルーターA」には、適切なクライアント波長を選択するのに十分な情報がありません。それは、その使用のために適切な対称ラベルを割り当てるようネットワークに要求するPathメッセージを下流に送信します。クライアントの波長が不明であるため、入力クライアントでレーザーがオフになっています。
o The downstream node (Node F) receives the Path message, chooses the appropriate wavelength values, and forwards them in appropriate label fields to the egress client ("Router B").
o ダウンストリームノード（ノードF）はPathメッセージを受信し、適切な波長値を選択して、適切なラベルフィールドで出力クライアント（「ルーターB」）に転送します。
o "Router B" receives the Path message, turns the laser ON and tunes it to the appropriate wavelength (received in the UPSTREAM_LABEL/ LABEL_SET of the Path) and sends a Resv message upstream.
o 「ルーターB」はパスメッセージを受信し、レーザーをオンにして、適切な波長（パスのUPSTREAM_LABEL / LABEL_SETで受信）に調整し、Resvメッセージをアップストリームに送信します。
o The Resv message received by the ingress client carries a valid symmetric label in the LABEL object. "Router A" turns on the laser and tunes it to the wavelength specified in the network assigned symmetric LABEL.
o 入力クライアントが受信したResvメッセージは、LABELオブジェクトで有効な対称ラベルを伝達します。 「ルーターA」は、レーザーをオンにして、対称LABELが割り当てられたネットワークで指定された波長に調整します。
For cases where the egress-node relies on RSVP signaling to determine exactly when to start using the LSP, implementations may choose to integrate the above sequence with any of the existing graceful setup procedures:
出力ノードがRSVPシグナリングに依存してLSPの使用をいつ開始するかを正確に決定する場合、実装では、上記のシーケンスを既存の適切なセットアップ手順と統合することを選択できます。
o "ResvConf" setup procedure ([RFC2205])
o 「ResvConf」設定手順（[RFC2205]）
o Two-step "ADMIN STATUS" based setup procedure ("A" bit set in the first step; "A" bit cleared when the LSP is ready for use) ([RFC3473])
o 2ステップの「ADMIN STATUS」ベースのセットアップ手順（最初のステップで「A」ビットが設定され、LSPが使用可能になると「A」ビットがクリアされる）（[RFC3473]）
After the LSP is set up, the network may decide to change the wavelength for the given LSP. This could be for a variety of reasons including policy reasons, restoration within the core, preemption, etc.
LSPがセットアップされた後、ネットワークは特定のLSPの波長を変更することを決定できます。これには、ポリシー上の理由、コア内での復元、プリエンプションなど、さまざまな理由が考えられます。
In such a scenario, if the ingress client receives a changed label via the LABEL object in a modified Resv message, it retunes the laser at the ingress to the new wavelength. Similarly, if the egress client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a modified Path message, it retunes the laser at the egress to the new wavelength.
このようなシナリオでは、入力クライアントが変更されたResvメッセージでLABELオブジェクトを介して変更されたラベルを受信すると、入力でレーザーを新しい波長に再調整します。同様に、出力クライアントが変更されたパスメッセージでUPSTREAM_LABEL / LABEL_SETを介して変更されたラベルを受信すると、出力でレーザーを新しい波長に再調整します。
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. IANA has added a new subregistry titled "Special Purpose Generalized Label Values". New values are assigned according to Standards Action [RFC8126].
IANAは、「一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリングパラメータ」レジストリを維持しています。 IANAは、「特別目的の一般化されたラベル値」というタイトルの新しいサブレジストリを追加しました。新しい値は、標準アクション[RFC8126]に従って割り当てられます。
Special Purpose Generalized Label Values
特別な目的の一般化されたラベル値
Pattern/ Label Name Applicable Reference
Value Objects
-------- ---------------- -------------- ----------
all-ones Unassigned UPSTREAM_LABEL [RFC8359]
Upstream Label
This document defines a special label value to be carried in the UPSTREAM_LABEL object of a Path message. This special label value is used to enable the function of requesting network assignment of an upstream label. The changes proposed in this document pertain to the semantics of a specific field in an existing RSVP object and the corresponding procedures. Thus, there are no new security implications raised by this document and the security considerations discussed by [RFC3473] still apply.
このドキュメントは、PathメッセージのUPSTREAM_LABELオブジェクトで運ばれる特別なラベル値を定義します。この特別なラベル値は、アップストリームラベルのネットワーク割り当てを要求する機能を有効にするために使用されます。このドキュメントで提案されている変更は、既存のRSVPオブジェクトの特定のフィールドのセマンティクスと、対応する手順に関連しています。したがって、このドキュメントによって引き起こされる新しいセキュリティの影響はなく、[RFC3473]で説明されているセキュリティの考慮事項が引き続き適用されます。
For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920].
MPLSおよびGMPLS関連のセキュリティ問題に関する一般的な説明については、MPLS / GMPLSセキュリティフレームワーク[RFC5920]を参照してください。
[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>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<https://www.rfc-editor.org/ info / rfc3471>。
[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。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https： //www.rfc-editor.org/info/rfc3473>。
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011, <https://www.rfc-editor.org/info/rfc6205>.
[RFC6205] Otani、T.、Ed。 D. Li、Ed。、「Lambda-Switch-Capable（LSC）Label Switching Routersの一般化されたラベル」、RFC 6205、DOI 10.17487 / RFC6205、2011年3月、<https://www.rfc-editor.org/info / rfc6205>。
[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>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgements
謝辞
The authors would like to thank Adrian Farrel and Chris Bowers for their inputs.
著者は、それらの入力のためにエイドリアンファレルとクリスバウアーズに感謝したいと思います。
Contributors
貢献者
John Drake Juniper Networks Email: jdrake@juniper.net
ジョンドレイクジュニパーネットワークスメール：jdrake@juniper.net
Gert Grammel Juniper Networks Email: ggrammel@juniper.net
Gert Grammel Juniper Networksメール：ggrammel@juniper.net
Pawel Brzozowski ADVA Optical Networking Email: pbrzozowski@advaoptical.com
Pawel Brzozowski ADVAオプティカルネットワーキングメール：pbrzozowski@advaoptical.com
Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com
Zafar Ali Cisco Systems、Inc.メール：zali@cisco.com
Authors' Addresses
著者のアドレス
Xian Zhang (editor) Huawei Technologies
X Ian Zhang（編集者）hu Aはテクノロジー
Email: zhang.xian@huawei.com
Vishnu Pavan Beeram (editor) Juniper Networks
Vishnu Pawan Biran（編集者）Juniper Networks
Email: vbeeram@juniper.net
Igor Bryskin Huawei Technologies
Igor Bryskin Huawei Technologies
Email: igor.bryskin@huawei.com
Daniele Ceccarelli Ericsson
ダニエレ・セカレッリ・エリクソン
Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios Telefonica
オスカーゴンザレスデディオステレフォニカ
Email: ogondio@tid.es