[要約] RFC 8577は、共有MPLS転送プレーン上でのRSVP-TEトンネルのシグナリングに関する標準化ドキュメントです。このRFCの目的は、複数のネットワークオペレーターが同じMPLSネットワークを共有する場合に、RSVP-TEトンネルのシグナリングを効果的に行うためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) H. Sitaraman
Request for Comments: 8577 V. Beeram
Category: Standards Track Juniper Networks
ISSN: 2070-1721 T. Parikh
Verizon
T. Saad
Cisco Systems
April 2019
Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane
共有MPLS転送プレーンでのRSVP-TEトンネルのシグナリング
Abstract
概要
As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.
MPLS RSVP-TEネットワークの規模が拡大するにつれて、個々のネットワーク要素でサポートされるラベルスイッチドパス（LSP）の数が増加しています。コントロールプレーンの状態情報の結果として生じる増加を管理するために、さまざまな実装の推奨事項が提案されています。
However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.
ただし、これらの変更は、中継ラベルスイッチングルータ（LSR）がフォワーディングプレーンでサポートする必要があるラベルの数に影響を与えていません。この数は、LSRで通過または終了するLSPの数によって決まり、コントロールプレーンのLSP状態全体に直接関連しています。
This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.
このドキュメントでは、LSRのラベルスペース制限の最大サイズが、そのノードのコントロールプレーンスケーリングの制約にならないようにするメカニズムを定義しています。これらのTEリンクを通過するMPLS RSVP-TE LSPで共有できる、事前にインストールされた「TEごとのリンクラベル」の概念を紹介します。このアプローチにより、多数のLSPをサポートするために必要なフォワーディングプレーンの状態が大幅に削減されます。これは、RSVP-TEコントロールプレーンの機能上の利点と、セグメントルーティング（SR）MPLSフォワーディングプレーンのシンプルさを組み合わせたものです。
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/rfc8577.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8577で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 6
4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 6
5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 8
5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8
5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 9
5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 10
5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 11
5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 11
5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 11
6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 13
7. Construction of Label Stacks . . . . . . . . . . . . . . . . 14
8. Facility Backup Protection . . . . . . . . . . . . . . . . . 14
8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 14
9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 15
9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 16
9.3. RRO Label Sub-object Flag: TE Link Label . . . . . . . . 16
9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 16
9.5. RRO Label Sub-object Flag: Delegation Label . . . . . . . 17
9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 17
9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 18
10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 19
11.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 19
11.3. Record Route Label Sub-object Flags: TE Link Label,
Delegation Label . . . . . . . . . . . . . . . . . . . . 20
11.4. Error Codes and Error Values . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
The scaling of RSVP-TE [RFC3209] control-plane implementations can be improved by adopting the guidelines and mechanisms described in [RFC2961] and [RFC8370]. These documents do not affect the forwarding-plane state required to handle the control-plane state. The forwarding-plane state remains unchanged and is directly proportional to the total number of Label Switching Paths (LSPs) supported by the control plane.
RSVP-TE [RFC3209]コントロールプレーン実装のスケーリングは、[RFC2961]と[RFC8370]で説明されているガイドラインとメカニズムを採用することで改善できます。これらのドキュメントは、コントロールプレーンの状態を処理するために必要なフォワーディングプレーンの状態には影響しません。フォワーディングプレーンの状態は変更されず、コントロールプレーンによってサポートされるラベルスイッチングパス（LSP）の総数に直接比例します。
This document describes a mechanism that prevents the size of the platform-specific label space on a Label Switching Router (LSR) from being a constraint to pushing the limits of control-plane scaling on that node.
このドキュメントでは、ラベルスイッチングルータ（LSR）のプラットフォーム固有のラベルスペースのサイズが、そのノードのコントロールプレーンスケーリングの限界を押し上げる制約になるのを防ぐメカニズムについて説明します。
This work introduces the notion of preinstalled 'per-TE link labels' that are allocated by an LSR. Each such label is installed in the MPLS forwarding plane with a 'pop' operation and instructions to forward the received packet over the TE link. An LSR advertises this label in the Label object of a Resv message as LSPs are set up, and they are recorded hop by hop in the Record Route Object (RRO) of the Resv message as it traverses the network. The ingress Label Edge Router (LER) constructs and pushes a stack of labels [RFC3031] using the labels received in the RRO. These 'TE link labels' can be shared by MPLS RSVP-TE LSPs that traverse the same TE link.
この作業では、LSRによって割り当てられる、プリインストールされた「TEごとのリンクラベル」の概念を紹介します。そのような各ラベルは、「ポップ」操作とTEリンクを介して受信したパケットを転送するための指示とともにMPLS転送プレーンにインストールされます。 LSRが設定されると、LSRはこのラベルをResvメッセージのLabelオブジェクトでアドバタイズし、ネットワークを通過するときにResvメッセージのRecord Route Object（RRO）にホップバイホップで記録されます。入力ラベルエッジルーター（LER）は、RROで受信されたラベルを使用して、ラベルのスタック[RFC3031]を構築およびプッシュします。これらの「TEリンクラベル」は、同じTEリンクを通過するMPLS RSVP-TE LSPで共有できます。
This forwarding-plane behavior fits in the MPLS architecture [RFC3031] and is the same as that exhibited by Segment Routing (SR) [RFC8402] when using an MPLS forwarding plane and a series of adjacency segments [SEG-ROUTING]. This work couples the feature benefits of the RSVP-TE control plane with the simplicity of the SR MPLS forwarding plane.
このフォワーディングプレーンの動作は、MPLSアーキテクチャ[RFC3031]に適合し、MPLSフォワーディングプレーンと一連の隣接セグメント[SEG-ROUTING]を使用するときにセグメントルーティング（SR）[RFC8402]が示す動作と同じです。この作業は、RSVP-TEコントロールプレーンの機能上の利点とSR MPLSフォワーディングプレーンのシンプルさを組み合わせたものです。
RSVP-TE using a shared MPLS forwarding plane offers the following benefits:
共有MPLSフォワーディングプレーンを使用するRSVP-TEには、次の利点があります。
1. Shared labels: The transit label on a TE link is shared among RSVP-TE tunnels traversing the link and is used independently of the ingress and egress of the LSPs.
1. 共有ラベル：TEリンクの中継ラベルは、リンクを通過するRSVP-TEトンネル間で共有され、LSPの入力と出力に関係なく使用されます。
2. Faster LSP setup time: No forwarding-plane state needs to be programmed during LSP setup and teardown, resulting in faster provisioning and deprovisioning of LSPs.
2. LSPのセットアップ時間の短縮：LSPのセットアップとティアダウン中にフォワーディングプレーンの状態をプログラムする必要がないため、LSPのプロビジョニングとプロビジョニング解除が高速になります。
3. Hitless rerouting: New transit labels are not required during make-before-break (MBB) in scenarios where the new LSP instance traverses the exact same path as the old LSP instance. This saves the ingress LER and the services that use the tunnel from needing to update the forwarding plane with new tunnel labels, thereby making MBB events faster. Periodic MBB events are relatively common in networks that deploy the 'auto-bandwidth' feature on RSVP-TE LSPs to monitor bandwidth utilization and periodically adjust LSP bandwidth.
3.ヒットレス再ルーティング：新しいLSPインスタンスが古いLSPインスタンスとまったく同じパスを通過するシナリオでは、make-before-break（MBB）中に新しいトランジットラベルは必要ありません。これにより、トンネルを使用する入力LERおよびサービスが転送トンネルを新しいトンネルラベルで更新する必要がなくなり、MBBイベントがより高速になります。定期的なMBBイベントは、RSVP-TE LSPに「自動帯域幅」機能を導入して帯域幅の使用率を監視し、定期的にLSP帯域幅を調整するネットワークでは比較的一般的です。
4. Mix-and-match labels: Both 'TE link labels' and regular labels can be used on transit hops for a single RSVP-TE tunnel (see Section 6). This allows backward compatibility with transit LSRs that provide regular labels in Resv messages.
4. ミックスアンドマッチラベル：「TEリンクラベル」と通常のラベルの両方を、単一のRSVP-TEトンネルのトランジットホップで使用できます（セクション6を参照）。これにより、Resvメッセージで通常のラベルを提供する中継LSRとの下位互換性が可能になります。
No additional extensions to routing protocols are required in order to support key functionalities such as bandwidth admission control, LSP priorities, preemption, and auto-bandwidth on this shared MPLS forwarding plane. This document also discusses how Fast Reroute [RFC4090] via facility backup link protection using regular bypass tunnels can be supported on this forwarding plane.
この共有MPLSフォワーディングプレーンで帯域幅アドミッション制御、LSP優先度、プリエンプション、自動帯域幅などの主要な機能をサポートするために、ルーティングプロトコルをさらに拡張する必要はありません。このドキュメントでは、通常のバイパストンネルを使用したファシリティバックアップリンク保護による高速リルート[RFC4090]がこの転送プレーンでどのようにサポートされるかについても説明します。
The signaling procedures and extensions discussed in this document do not apply to Point to Multipoint (P2MP) RSVP-TE tunnels.
このドキュメントで説明されているシグナリング手順と拡張機能は、ポイントツーマルチポイント（P2MP）RSVP-TEトンネルには適用されません。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
TE link label: An incoming label at an LSR that will be popped by the LSR with the packet being forwarded over a specific outgoing TE link to a neighbor.
TEリンクラベル：LSRによってポップされるLSRの着信ラベル。パケットは特定の発信TEリンクを介してネイバーに転送されます。
Shared MPLS forwarding plane: An MPLS forwarding plane where every participating LSR uses TE link labels on every LSP.
共有MPLSフォワーディングプレーン：参加しているすべてのLSRがすべてのLSPでTEリンクラベルを使用するMPLSフォワーディングプレーン。
Segment Routed RSVP-TE tunnel: An MPLS RSVP-TE tunnel that requests the use of a shared MPLS forwarding plane at every hop of the LSP. The corresponding LSPs are referred to as "Segment Routed RSVP-TE LSPs".
セグメントルーテッドRSVP-TEトンネル：LSPのすべてのホップで共有MPLS転送プレーンの使用を要求するMPLS RSVP-TEトンネル。対応するLSPは「セグメントルーテッドRSVP-TE LSP」と呼ばれます。
Delegation hop: A transit hop of a Segment Routed RSVP-TE LSP that is selected to assist in the imposition of the label stack in scenarios where the ingress LER cannot impose the full label stack. There can be multiple delegation hops along the path of a Segment Routed RSVP-TE LSP.
委任ホップ：セグメントルーテッドRSVP-TE LSPのトランジットホップ。これは、入力LERが完全なラベルスタックを強制できないシナリオで、ラベルスタックの付加を支援するために選択されます。セグメントルーテッドRSVP-TE LSPのパスに沿って複数の委任ホップが存在する可能性があります。
Delegation label: A label assigned at the delegation hop to represent a set of labels that will be pushed at this hop.
委任ラベル：このホップでプッシュされるラベルのセットを表すために委任ホップで割り当てられたラベル。
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]で説明されているように解釈されます。
An LSR that participates in a shared MPLS forwarding plane MUST allocate a unique TE link label for each TE link. When an LSR encounters a TE link label at the top of the label stack, it MUST pop the label and forward the packet over the TE link to the downstream neighbor on the RSVP-TE tunnel.
共有MPLSフォワーディングプレーンに参加するLSRは、各TEリンクに一意のTEリンクラベルを割り当てなければなりません（MUST）。 LSRがラベルスタックの最上部でTEリンクラベルを検出すると、ラベルをポップし、TEリンクを介してパケットをRSVP-TEトンネルのダウンストリームネイバーに転送する必要があります。
Multiple TE link labels MAY be allocated for the TE link to accommodate tunnels requesting protection.
保護を要求するトンネルに対応するために、TEリンクに複数のTEリンクラベルを割り当てることができます。
Implementations that maintain per-label bandwidth accounting at each hop must aggregate the reservations made for all the LSPs using the shared TE link label.
各ホップでラベルごとの帯域幅アカウンティングを維持する実装では、共有TEリンクラベルを使用して、すべてのLSPに対して行われた予約を集約する必要があります。
This section provides an example of how the RSVP-TE signaling procedure works to set up a tunnel utilizing a shared MPLS forwarding plane. The sample topology below is used to explain the example. Labels shown at each node are TE link labels that, when present at the top of the label stack, indicate that they should be popped and that the packet should be forwarded on the TE link to the neighbor.
このセクションでは、RSVP-TEシグナリング手順が、共有MPLS転送プレーンを利用してトンネルをセットアップするためにどのように機能するかの例を示します。次のサンプルトポロジを使用して、例を説明します。各ノードに表示されるラベルはTEリンクラベルであり、ラベルスタックの最上部にある場合、それらはポップされ、パケットはTEリンクでネイバーに転送される必要があることを示します。
+---+100 +---+150 +---+200 +---+250 +---+
| A |-----| B |-----| C |-----| D |-----| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I |
+---+300 +---+350 +---+700 +---+
Figure 1: Sample Topology -- TE Link Labels
図1：サンプルトポロジ-TEリンクラベル
Consider two tunnels:
2つのトンネルについて考えてみましょう。
RSVP-TE tunnel T1: From A to E on path A-B-C-D-E
RSVP-TEトンネルT1：パスA-B-C-D-EのAからEへ
RSVP-TE tunnel T2: From F to E on path F-B-C-D-E
RSVP-TEトンネルT2：パスF-B-C-D-EのFからEへ
Both tunnels share the TE links B-C, C-D, and D-E.
両方のトンネルがTEリンクB-C、C-D、およびD-Eを共有します。
RSVP-TE is used to signal the setup of tunnel T1 (using the TE link label attributes flag defined in Section 9.2). When LSR D receives the Resv message from the egress LER E, it checks the next-hop TE link (D-E) and provides the TE link label (250) in the Resv message for the tunnel placing the label value in the Label object. It also provides the TE link label (250) in the Label sub-object carried in the RRO and sets the TE link label flag as defined in Section 9.3.
RSVP-TEは、トンネルT1の設定を通知するために使用されます（セクション9.2で定義されたTEリンクラベル属性フラグを使用）。 LSR Dは、出口LER EからResvメッセージを受信すると、ネクストホップTEリンク（D-E）をチェックし、ラベル値をLabelオブジェクトに配置するトンネルのResvメッセージにTEリンクラベル（250）を提供します。また、RROで運ばれるLabelサブオブジェクトにTEリンクラベル（250）を提供し、9.3節で定義されているようにTEリンクラベルフラグを設定します。
Similarly, LSR C provides the TE link label (200) for the TE link C-D, and LSR B provides the TE link label (150) for the TE link B-C.
同様に、LSR CはTEリンクC-DにTEリンクラベル（200）を提供し、LSR BはTEリンクB-CにTEリンクラベル（150）を提供します。
For tunnel T2, the transit LSRs provide the same TE link labels as described for tunnel T1 as the links B-C, C-D, and D-E are common between the two LSPs.
トンネルT2の場合、トランジットLSRは、リンクB-C、C-D、およびD-Eが2つのLSP間で共通であるため、トンネルT1について説明したのと同じTEリンクラベルを提供します。
The ingress LERs (A and F) will push the same stack of labels (from top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and T2, respectively.
入力LER（AとF）は、トンネルT1とT2に対してそれぞれ同じラベルスタック（スタックの最上部から最下部まで）{150、200、250}をプッシュします。
It should be noted that a transit LSR does not swap the top TE link label on an incoming packet (the label that it advertised in the Resv message it sent); all it has to do is pop the top label and forward the packet.
トランジットLSRは着信パケットの最上位TEリンクラベル（送信したResvメッセージでアドバタイズしたラベル）をスワップしないことに注意してください。トップラベルをポップしてパケットを転送するだけです。
The values in the Label sub-objects in the RRO are of interest to the ingress LERs when constructing the stack of labels to impose on the packets.
RROのラベルサブオブジェクトの値は、パケットに課すラベルのスタックを構築するときに、入力LERにとって重要です。
If, in this example, there were another RSVP-TE tunnel T3 from F to I on path F-B-C-D-E-I, then this tunnel would also share the TE links B-C, C-D, and D-E and traverse link E-I. The label stack used by F would be {150, 200, 250, 850}. Hence, regardless of where the LSPs start and end, they will share LSR labels at shared hops in the shared MPLS forwarding plane.
この例では、パスF-B-C-D-E-IにFからIへの別のRSVP-TEトンネルT3があった場合、このトンネルはTEリンクB-C、C-D、D-EとトラバースリンクE-Iも共有します。 Fが使用するラベルスタックは{150、200、250、850}です。したがって、LSPの開始位置と終了位置に関係なく、LSPは共有MPLS転送プレーンの共有ホップでLSRラベルを共有します。
There MAY be a local operator policy at the ingress LER that influences the maximum depth of the label stack that can be pushed for a Segment Routed RSVP-TE tunnel. Prior to signaling the LSP, the ingress LER may determine that it is unable to push a label stack containing one label for each hop along the path. In some scenarios, the ingress LER may not have sufficient information to make that determination. In these cases, the LER SHOULD adopt the techniques described in Section 5.
セグメントルーテッドRSVP-TEトンネルにプッシュできるラベルスタックの最大深度に影響を与えるローカルオペレーターポリシーが入力LERにある場合があります。入力LERは、LSPをシグナリングする前に、パスに沿ったホップごとに1つのラベルを含むラベルスタックをプッシュできないと判断する場合があります。一部のシナリオでは、入力LERにその決定を行うための十分な情報がない場合があります。これらの場合、LERはセクション5で説明されている手法を採用する必要があります（SHOULD）。
One or more transit LSRs can assist the ingress LER by imposing part of the label stack required for the path. Consider the example in Figure 2 with an RSVP-TE tunnel from A to L on path A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A to impose the full label stack, so it uses the assistance of delegation hops LSR D and LSR I to impose parts of the label stack.
1つ以上の中継LSRは、パスに必要なラベルスタックの一部を課すことにより、入力LERを支援できます。パスA-B-C-D-E-F-G-H-I-J-K-L上のAからLへのRSVP-TEトンネルを使用した図2の例を考えてみます。この場合、LSPは長すぎてLER Aが完全なラベルスタックを課すことができないため、委任ホップLSR DおよびLSR Iの支援を使用して、ラベルスタックの一部を課します。
Each delegation hop allocates a delegation label to represent a set of labels that will be pushed at this hop. When a packet arrives at a delegation hop LSR with a delegation label, the LSR pops the label and pushes a set of labels before forwarding the packet.
各委任ホップは、このホップでプッシュされるラベルのセットを表す委任ラベルを割り当てます。パケットが委任ラベル付きの委任ホップLSRに到着すると、LSRはラベルをポップし、一連のラベルをプッシュしてからパケットを転送します。
1250d
+---+100p +---+150p +---+200p +---+250p +---+300p +---+
| A |------| B |------| C |------| D |------| E |------| F |
+---+ +---+ +---+ +---+ +---+ +---+
|350p
|
1500d |
+---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+
| L |------| K |------| J |------| I |------| H |------+ G +
+---+ +---+ +---+ +---+ +---+ +---+
Notation: <Label>p - TE link label
<Label>d - Delegation label
Figure 2: Delegating Label Stack Imposition
図2：ラベルスタックの面付けの委任
When delegation labels come into play, there are two stacking approaches from which the ingress can choose. Section 7 explains how the label stack can be constructed.
委任ラベルが機能する場合、イングレスが選択できる2つのスタッキングアプローチがあります。セクション7では、ラベルスタックの作成方法について説明します。
In this approach, the stack pushed by the ingress carries a set of labels that will take the packet to the first delegation hop. When this approach is employed, the set of labels represented by a delegation label at a given delegation hop will include the corresponding delegation label from the next delegation hop. As a result, this delegation label can only be shared among LSPs that are destined to the same egress and traverse the same downstream path.
このアプローチでは、入力によってプッシュされたスタックは、パケットを最初の委任ホップに運ぶ一連のラベルを保持します。このアプローチが採用されると、特定の委任ホップで委任ラベルによって表されるラベルのセットには、次の委任ホップからの対応する委任ラベルが含まれます。その結果、この委任ラベルは、同じ出口を宛先とし、同じダウンストリームパスを通過するLSP間でのみ共有できます。
This approach is shown in Figure 3. The delegation label 1250 represents the stack {300, 350, 400, 450, 1500}, and the delegation label 1500 represents the label stack {550, 600}.
このアプローチを図3に示します。委任ラベル1250はスタック{300、350、400、450、1500}を表し、委任ラベル1500はラベルスタック{550、600}を表します。
+---+ +---+ +---+
| A |-----.....-----| D |-----.....-----| I |-----.....
+---+ +---+ +---+
Pop 1250 & Pop 1500 &
Push Push Push
...... ...... ......
: 150: 1250->: 300: 1500->: 550:
: 200: : 350: : 600:
:1250: : 400: ......
...... : 450:
:1500:
......
Figure 3: Stack to Reach Delegation Hop
図3：委任ホップに到達するスタック
With this approach, the ingress LER A will push {150, 200, 1250} for the tunnel in Figure 2. At LSR D, the delegation label 1250 will get popped, and {300, 350, 400, 450, 1500} will get pushed. At LSR I, the delegation label 1500 will get popped, and the remaining set of labels {550, 600} will get pushed.
このアプローチでは、入口LER Aは、図2のトンネルに対して{150、200、1250}をプッシュします。LSRDでは、委任ラベル1250がポップされ、{300、350、400、450、1500}が取得されます押した。 LSR Iでは、委任ラベル1500がポップされ、残りのラベルセット{550、600}がプッシュされます。
In this approach, the stack pushed by the ingress carries a set of labels that will take the packet all the way to the egress so that all the delegation labels are part of the stack. When this approach is employed, the set of labels represented by a delegation label at a given delegation hop will not include the corresponding delegation label from the next delegation hop. As a result, this delegation label can be shared among all LSPs traversing the segment between the two delegation hops.
このアプローチでは、入力によってプッシュされたスタックは、パケットを出力に至る一連のラベルを運び、すべての委任ラベルがスタックの一部になるようにします。このアプローチを採用すると、特定の委任ホップで委任ラベルによって表されるラベルのセットには、次の委任ホップからの対応する委任ラベルが含まれません。その結果、この委任ラベルは、2つの委任ホップ間のセグメントを通過するすべてのLSP間で共有できます。
The downside of this approach is that the number of hops that the LSP can traverse is dictated by the label stack push limit of the ingress.
このアプローチの欠点は、LSPが通過できるホップの数が、入力のラベルスタックプッシュ制限によって決まることです。
This approach is shown in Figure 4. The delegation label 1250 represents the stack {300, 350, 400, 450}, and the delegation label 1500 represents the label stack {550, 600}.
このアプローチを図4に示します。委任ラベル1250はスタック{300、350、400、450}を表し、委任ラベル1500はラベルスタック{550、600}を表します。
+---+ +---+ +---+
| A |-----.....-----| D |-----.....-----| I |-----.....
+---+ +---+ +---+
Pop 1250 & Pop 1500 &
Push Push Push
...... ...... ......
: 150: 1250->: 300: 1500->: 550:
: 200: : 350: : 600:
:1250: : 400: ......
:1500: : 450:
...... ......
|1500|
......
Figure 4: Stack to Reach Egress
図4：下りに到達するスタック
With this approach, the ingress LER A will push {150, 200, 1250, 1500} for the tunnel in Figure 2. At LSR D, the delegation label 1250 will get popped, and {300, 350, 400, 450} will get pushed. At LSR I, the delegation label 1500 will get popped, and the remaining set of labels {550, 600} will get pushed. The signaling extension required for the ingress to indicate the chosen stacking approach is defined in Section 9.6.
このアプローチでは、入口LER Aは、図2のトンネルに対して{150、200、1250、1500}をプッシュします。LSRDでは、委任ラベル1250がポップされ、{300、350、400、450}が取得されます押した。 LSR Iでは、委任ラベル1500がポップされ、残りのラベルセット{550、600}がプッシュされます。入力が選択したスタッキングアプローチを示すために必要なシグナリング拡張は、セクション9.6で定義されています。
In this delegation option, the ingress LER can explicitly delegate one or more specific transit LSRs to handle pushing labels for a certain number of their downstream hops. In order to accurately pick the delegation hops, the ingress needs to be aware of the label stack depth push limit (total number of MPLS labels that can be imposed, including all service/transport/special labels) of each of the transit LSRs prior to initiating the signaling sequence. The mechanism by which the ingress or controller (hosting the path computation element) learns this information is outside the scope of this document. Base MPLS Imposition MSD (BMI-MSD) advertisement, specified in [RFC8491], is an example of such a mechanism.
この委任オプションでは、入力LERは1つ以上の特定のトランジットLSRを明示的に委任して、特定の数のダウンストリームホップのプッシュラベルを処理できます。委任ホップを正確に選択するために、イングレスは、事前に各トランジットLSRのラベルスタック深度プッシュ制限（インポーズできるMPLSラベルの総数（すべてのサービス/トランスポート/特殊ラベルを含む））を認識する必要がありますシグナリングシーケンスを開始します。入力またはコントローラ（パス計算要素をホストする）がこの情報を学習するメカニズムは、このドキュメントの範囲外です。 [RFC8491]で指定されているベースMPLSインポジションMSD（BMI-MSD）アドバタイズは、そのようなメカニズムの例です。
The signaling extension required for the ingress LER to explicitly delegate one or more specific transit hops is defined in Section 9.4. The extension required for the delegation hop to indicate that the recorded label is a delegation label is defined in Section 9.5.
入力LERが1つ以上の特定の中継ホップを明示的に委任するために必要なシグナリング拡張は、セクション9.4で定義されています。委任ホップが、記録されたラベルが委任ラベルであることを示すために必要な拡張子は、セクション9.5で定義されています。
In this approach, the ingress LER lets the downstream LSRs automatically pick suitable delegation hops during the initial signaling sequence. The ingress does not need to be aware up front of the label stack depth push limit of each of the transit LSRs. This approach SHOULD be used if there are loose hops [RFC3209] in the explicit route. The delegation hops are picked based on a per-hop signaled attribute called the Effective Transport Label-Stack Depth (ETLD), as described in the next section.
このアプローチでは、入力LERにより、ダウンストリームLSRが最初のシグナリングシーケンス中に適切な委任ホップを自動的に選択できます。入力は、各トランジットLSRのラベルスタック深度プッシュ制限の前にあることを認識する必要はありません。このアプローチは、明示的なルートにルーズホップ[RFC3209]がある場合に使用する必要があります。次のセクションで説明するように、委任ホップは、有効トランスポートラベルスタック深度（ETLD）と呼ばれるホップごとの信号属性に基づいて選択されます。
The ETLD is signaled as a per-hop recorded attribute in the Path message [RFC7570]. When automatic delegation is requested, the ingress MUST populate the ETLD with the maximum number of transport labels that it can potentially send to its downstream hop. This value is then decremented at each successive hop. If a node is reached and it is determined that this hop cannot support automatic delegation, then it MUST NOT use TE link labels and use regular labels instead. If a node is reached where the ETLD set from the previous hop is 1, then that node MUST select itself as the delegation hop. If a node is reached and it is determined that this hop cannot receive more than one transport label, then that node MUST select itself as the delegation hop. If there is a node or a sequence of nodes along the path of the LSP that do not support ETLD, then the immediate hop that supports ETLD MUST select itself as the delegation hop. The ETLD MUST be decremented at each non-delegation transit hop by either 1 or some appropriate number based on the local policy. For example, consider a transit node with a local policy that mandates it to take the label stack read limit into account when decrementing the ETLD. With this policy, the ETLD is decremented in such a way that the transit hop does not receive more labels in the stack than it can read. At each delegation hop, the ETLD MUST be reset to the maximum number of transport labels that the hop can send, and the ETLD decrements start again at each successive hop until either a new delegation hop is selected or the egress is reached. As a result, by the time the Path message reaches the egress, all delegation hops are selected. During the Resv processing, at each delegation hop, a suitable delegation label is selected (either an existing label is reused or a new label is allocated) and recorded in the Resv message.
ETLDは、パスメッセージ[RFC7570]でホップごとに記録される属性として通知されます。自動委任が要求された場合、イングレスはダウンストリームホップに送信できるトランスポートラベルの最大数をETLDに入力する必要があります。この値は、その後の各ホップで減少します。ノードに到達し、このホップが自動委任をサポートできないと判断された場合、TEリンクラベルを使用してはならず、代わりに通常のラベルを使用してはなりません（MUST NOT）。前のホップから設定されたETLDが1であるノードに到達した場合、そのノードは自身を委任ホップとして選択する必要があります。ノードに到達し、このホップが複数のトランスポートラベルを受信できないと判断された場合、そのノードは自身を委任ホップとして選択する必要があります。 ETLDをサポートしないLSPのパスに沿ったノードまたはノードのシーケンスがある場合、ETLDをサポートする即時ホップは、それ自体を委任ホップとして選択する必要があります。 ETLDは、非委任トランジットホップごとに、ローカルポリシーに基づいて1または適切な数だけデクリメントする必要があります。たとえば、ETLDをデクリメントするときにラベルスタックの読み取り制限を考慮するように指示するローカルポリシーを持つトランジットノードについて考えます。このポリシーでは、トランジットホップが読み取ることができるより多くのラベルをスタックで受信しないように、ETLDが減少します。各委任ホップでは、ホップが送信できるトランスポートラベルの最大数にETLDをリセットする必要があります。ETLDの減少は、新しい委任ホップが選択されるか、出口に到達するまで、連続する各ホップで再開されます。その結果、Pathメッセージが出力に到達するまでに、すべての委任ホップが選択されます。 Resv処理中、各委任ホップで、適切な委任ラベルが選択され（既存のラベルが再利用されるか、新しいラベルが割り当てられる）、Resvメッセージに記録されます。
Consider the example shown in Figure 5. Let's assume ingress LER A can push up to three transport labels while the remaining nodes can push up to five transport labels. The ingress LER A signals the initial Path message with ETLD set to 3. The ETLD value is adjusted at each successive hop and signaled downstream as shown. By the time the Path message reaches the egress LER L, LSRs D and I are automatically selected as delegation hops.
図5の例を考えてみましょう。残りのノードが最大5つのトランスポートラベルをプッシュできるのに対し、入口LER Aは最大3つのトランスポートラベルをプッシュできると仮定します。入力LER Aは、ETLDが3に設定された初期パスメッセージを通知します。ETLD値は、連続する各ホップで調整され、図のようにダウンストリームに通知されます。 Pathメッセージが出力LER Lに到達するまでに、LSR DとIは委任ホップとして自動的に選択されます。
ETLD:3 ETLD:2 ETLD:1 ETLD:5 ETLD:4
-----> -----> -----> -----> ----->
1250d
+---+100p +---+150p +---+200p +---+250p +---+300p +---+
| A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3
+---+ +---+ +---+ +---+ +---+ +---+ |
|350p |
| |
1500d | |
+---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ v
| L |-----| K |-----| J |-----| I |-----| H |-----+ G +
+---+ +---+ +---+ +---+ +---+ +---+
ETLD:3 ETLD:4 ETLD:5 ETLD:1 ETLD:2
<----- <----- <----- <----- <-----
Figure 5: ETLD
図5：ETLD
When an LSP that requests automatic delegation also requests facility backup protection [RFC4090], the ingress or the delegation hop MUST account for the bypass tunnel's label(s) when populating the ETLD. Hence, when a regular bypass tunnel is used to protect the facility, the ETLD that gets populated on these nodes is one less than what gets populated for a corresponding unprotected LSP.
自動委任を要求するLSPがファシリティバックアップ保護も要求する場合[RFC4090]、入口または委任ホップは、ETLDに入力するときにバイパストンネルのラベルを考慮する必要があります。したがって、通常のバイパストンネルを使用してファシリティを保護する場合、これらのノードに読み込まれるETLDは、対応する保護されていないLSPに読み込まれるETLDより1つ少なくなります。
Signaling extension for the ingress LER to request automatic delegation is defined in Section 9.4. The extension for signaling the ETLD is defined in Section 9.7. The extension required for the delegation hop to indicate that the recorded label is a delegation label is defined in Section 9.5.
入力LERが自動委任を要求するためのシグナリング拡張は、セクション9.4で定義されています。 ETLDをシグナリングするための拡張は、セクション9.7で定義されています。委任ホップが、記録されたラベルが委任ラベルであることを示すために必要な拡張子は、セクション9.5で定義されています。
Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP. Certain LSRs can use TE link labels and others can use regular labels. The ingress can construct a label stack appropriately based on what type of label is recorded from every transit LSR.
ラベルは、単一のMPLS RSVP-TE LSPのトランジットホップ間で混合できます。特定のLSRはTEリンクラベルを使用でき、他のLSRは通常のラベルを使用できます。入力は、すべてのトランジットLSRから記録されるラベルのタイプに基づいて、ラベルスタックを適切に構築できます。
(#) (#)
+---+100 +---+150 +---+200 +---+250 +---+
| A |-----| B |-----| C |-----| D |-----| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I |
+---+300 +---+350 +---+700 +---+
Notation: (#) denotes regular labels Other labels are TE link labels
表記：（＃）は通常のラベルを示します他のラベルはTEリンクラベルです
Figure 6: Sample Topology -- TE Link Labels and Regular Labels
図6：サンプルトポロジ-TEリンクラベルと通常のラベル
If the transit LSR allocates a regular label to be sent upstream in the Resv, then the label operation at the LSR is a swap to the label received from the downstream LSR. If the transit LSR is using a TE link label to be sent upstream in the Resv, then the label operation at the LSR is a pop and forward regardless of any label received from the downstream LSR. There is no change in the behavior of a penultimate hop popping (PHP) LSR [RFC3031].
中継LSRがResvでアップストリームに送信される通常のラベルを割り当てる場合、LSRでのラベル操作は、ダウンストリームLSRから受信したラベルへのスワップです。トランジットLSRがTEリンクラベルを使用してResvのアップストリームに送信される場合、ダウンストリームLSRから受信したラベルに関係なく、LSRでのラベル操作はポップアンドフォワードです。最後から2番目のホップポップ（PHP）LSR [RFC3031]の動作に変更はありません。
Section 7 explains how the label stack can be constructed. For example, the LSP from A to I using path A-B-C-D-E-I will use a label stack of {150, 200}.
セクション7では、ラベルスタックの作成方法について説明します。たとえば、パスA-B-C-D-E-Iを使用するAからIへのLSPは、{150、200}のラベルスタックを使用します。
The ingress LER or delegation hop MUST check the type of label received from each transit hop as recorded in the RRO in the Resv message and generate the appropriate label stack to reach the next delegation hop or the egress.
入力LERまたは委任ホップは、ResvメッセージのRROに記録されている各中継ホップから受信したラベルのタイプを確認し、次の委任ホップまたは出力に到達するための適切なラベルスタックを生成する必要があります。
The following logic is used by the node constructing the label stack:
次のロジックは、ラベルスタックを構築するノードによって使用されます。
Each RRO label sub-object MUST be processed starting with the label sub-object from the first downstream hop. Any label provided by the first downstream hop MUST always be pushed on the label stack regardless of the label type. If the label type is a TE link label, then any label from the next downstream hop MUST also be pushed on the constructed label stack. If the label type is a regular label, then any label from the next downstream hop MUST NOT be pushed on the constructed label stack. If the label type is a delegation label, then the type of stacking approach chosen by the ingress for this LSP (Section 5.1) MUST be used to determine how the delegation labels are pushed in the label stack.
各RROラベルサブオブジェクトは、最初のダウンストリームホップのラベルサブオブジェクトから処理する必要があります。最初のダウンストリームホップによって提供されるラベルは、ラベルタイプに関係なく、常にラベルスタックにプッシュされる必要があります。ラベルタイプがTEリンクラベルの場合、次のダウンストリームホップからのラベルも、構築されたラベルスタックにプッシュする必要があります。ラベルタイプが通常のラベルの場合、次のダウンストリームホップからのラベルは、構築されたラベルスタックにプッシュしてはなりません（MUST NOT）。ラベルタイプが委任ラベルである場合、このLSPの入口によって選択されたスタックアプローチのタイプ（セクション5.1）を使用して、委任ラベルがラベルスタックにプッシュされる方法を決定する必要があります。
The following section describes how link protection works with facility backup protection [RFC4090] using regular bypass tunnels for the Segment Routed RSVP-TE tunnels. The procedures for supporting node protection are not discussed in this document. The use of Segment Routed bypass tunnels for providing facility protection is left for further study.
次のセクションでは、セグメントルーテッドRSVP-TEトンネルに通常のバイパストンネルを使用して、リンク保護がファシリティバックアップ保護[RFC4090]とどのように連携するかについて説明します。このドキュメントでは、ノード保護をサポートする手順については説明しません。施設の保護を提供するためのセグメントルーテッドバイパストンネルの使用は、今後の検討課題です。
To provide link protection at a Point of Local Repair (PLR) with a shared MPLS forwarding plane, the LSR MUST allocate a separate TE link label for the TE link that will be used for RSVP-TE tunnels that request link protection from the ingress. No signaling extensions are required to support link protection for RSVP-TE tunnels over the shared MPLS forwarding plane.
共有MPLSフォワーディングプレーンでPoint of Local Repair（PLR）にリンク保護を提供するために、LSRは、入口からのリンク保護を要求するRSVP-TEトンネルに使用されるTEリンクに個別のTEリンクラベルを割り当てる必要があります。共有MPLSフォワーディングプレーン上のRSVP-TEトンネルのリンク保護をサポートするために、シグナリング拡張は必要ありません。
At each LSR, link-protected TE link labels can be allocated for each TE link, and a link-protecting facility backup LSP can be created to protect the TE link. The link-protected TE link label can be sent by the LSR for LSPs requesting link protection over the specific TE link. Since the facility backup terminates at the next hop (merge point), the incoming label on the packet will be what the merge point expects.
各LSRでは、リンク保護されたTEリンクラベルを各TEリンクに割り当てることができ、リンク保護機能のバックアップLSPを作成してTEリンクを保護できます。リンク保護されたTEリンクラベルは、LSRが特定のTEリンクを介してリンク保護を要求するLSPに対して送信できます。ファシリティバックアップはネクストホップ（マージポイント）で終了するため、パケットの着信ラベルはマージポイントが予期するものになります。
Consider the network shown in Figure 7. LSR B can install a facility backup LSP for the link-protected TE link label 151. When the TE link B-C is up, LSR B will pop 151 and send the packet to C. If the TE link B-C is down, the LSR can pop 151 and send the packet via the facility backup to C.
図7に示すネットワークを検討してください。LSRBは、リンク保護されたTEリンクラベル151のファシリティバックアップLSPをインストールできます。TEリンクBCが起動すると、LSR Bは151をポップし、パケットをCに送信します。TEリンクがBCがダウンしている場合、LSRは151をポップし、ファシリティバックアップを介してパケットをCに送信できます。
101(*) 151(*) 201(*) 251(*)
+---+100 +---+150 +---+200 +---+250 +---+
| A |------| B |------| C |------| D |------| E |
+---+ +---+ +---+ +---+ +---+
|110 |450 |550 |650 |850
| | | | |
| |400 |500 |600 |800
| +---+ +---+ +---+ +---+
+--------| F |------|G |------|H |------|I |
+---+300 +---+350 +---+700 +---+
Notation: (*) denotes link-protected TE link labels
表記：（*）はリンク保護されたTEリンクラベルを示します
Figure 7: Link Protection Topology
図7：リンク保護トポロジ
The functionality discussed in this document imposes the following requirements on the signaling protocol.
このドキュメントで説明する機能は、シグナリングプロトコルに次の要件を課します。
o The ingress of the LSP needs to have the ability to mandate/ request the use and recording of TE link labels at all hops along the path of the LSP.
o LSPの入口には、LSPのパスに沿ったすべてのホップでのTEリンクラベルの使用と記録を要求/要求する機能が必要です。
o When the use of TE link labels is mandated/requested for the path:
o TEリンクラベルの使用がパスに対して必須/要求されている場合：
* the node recording the TE link label needs to have the ability to indicate whether the recorded label is a TE link label.
* TEリンクラベルを記録するノードには、記録されたラベルがTEリンクラベルであるかどうかを示す機能が必要です。
* the ingress needs to have the ability to delegate label stack imposition by:
* イングレスには、次の方法でラベルスタックの面付けを委任する機能が必要です。
+ explicitly mandating specific hops to be delegation hops, or
+ 特定のホップを委任ホップに明示的に強制する、または
+ requesting automatic delegation.
+ 自動委任を要求します。
* When explicit delegation is mandated or automatic delegation is requested:
* 明示的な委任が義務付けられている場合、または自動委任が要求されている場合：
+ the ingress needs to have the ability to indicate the chosen stacking approach, and
+ イングレスには、選択したスタッキングアプローチを示す機能が必要です。
+ the delegation hop needs to have the ability to indicate that the recorded label is a delegation label.
+ 委任ホップには、記録されたラベルが委任ラベルであることを示す機能が必要です。
Bit Number 16: TE Link Label
ビット番号16：TEリンクラベル
The presence of this flag in the LSP_ATTRIBUTES/ LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message indicates that the ingress has requested/mandated the use and recording of TE link labels at all hops along the path of this LSP. When a node that recognizes this flag but does not cater to the mandate because of local policy receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object with this flag set, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'TE link label usage failure (70)'. A transit hop that caters to this request/mandate MUST also check for the presence of other Attribute Flags introduced in this document (Sections 9.4 and 9.6) and process them as specified. An ingress LER that sets this bit MUST also set the "label recording desired" flag [RFC3209] in the SESSION_ATTRIBUTE object.
パスメッセージのLSP_ATTRIBUTES / LSP_REQUIRED_ATTRIBUTESオブジェクト[RFC5420]にこのフラグが存在することは、入力がこのLSPのパスに沿ったすべてのホップでのTEリンクラベルの使用と記録を要求/強制したことを示します。このフラグを認識しているが、ローカルポリシーのために委任に応じないノードが、このフラグが設定されたLSP_REQUIRED_ATTRIBUTESオブジェクトを運ぶPathメッセージを受信した場合、「ルーティングの問題（24）」のエラーコードを含むPathErrメッセージを送信する必要があります。エラー値「TEリンクラベルの使用失敗（70）」。このリクエスト/委任に応じるトランジットホップは、このドキュメント（セクション9.4および9.6）で導入された他の属性フラグの存在を確認し、指定どおりに処理する必要があります。このビットを設定する入口LERは、SESSION_ATTRIBUTEオブジェクトの「ラベル記録希望」フラグ[RFC3209]も設定する必要があります。
Flag (0x02): TE Link Label
フラグ（0x02）：TEリンクラベル
The presence of this flag indicates that the recorded label is a TE link label. This flag MUST be used by a node only if the use and recording of TE link labels are requested/mandated for the LSP.
このフラグの存在は、記録されたラベルがTEリンクラベルであることを示します。 LSPに対してTEリンクラベルの使用と記録が要求/義務付けられている場合にのみ、このフラグをノードで使用する必要があります。
Bit Number 17: Label Stack Imposition - Delegation (LSI-D)
ビット番号17：ラベルスタックの面付け-委任（LSI-D）
Automatic Delegation: The presence of this flag in the LSP_ATTRIBUTES object of a Path message indicates that the ingress has requested automatic delegation of label stack imposition. This flag MUST be set in the LSP_ATTRIBUTES object of a Path message only if the use and recording of TE link labels are requested/mandated for this LSP. If the transit hop does not support this flag, it MUST NOT use TE link labels and use regular labels instead. If the use of TE link labels was mandated in the LSP_REQUIRED_ATTRIBUTES object, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'TE link label usage failure (70)'.
自動委任：PathメッセージのLSP_ATTRIBUTESオブジェクトにこのフラグが存在することは、入力がラベルスタックインポジションの自動委任を要求したことを示しています。このLSPに対してTEリンクラベルの使用と記録が要求/義務付けられている場合にのみ、PathメッセージのLSP_ATTRIBUTESオブジェクトでこのフラグを設定する必要があります。中継ホップがこのフラグをサポートしない場合、TEリンクラベルを使用してはならず、代わりに通常のラベルを使用してはなりません。 LSP_REQUIRED_ATTRIBUTESオブジェクトでTEリンクラベルの使用が義務付けられている場合は、エラーコード「Routing Problem（24）」とエラー値「TE link label usage failure（70）」を含むPathErrメッセージを送信する必要があります。
Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES sub-object [RFC7570] of an Explicit Route Object (ERO) in the Path message indicates that the hop identified by the preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object has been picked as an explicit delegation hop. The HOP_ATTRIBUTES sub-object carrying this flag MUST have the R (Required) bit set. This flag MUST be set in the HOP_ATTRIBUTES sub-object of an ERO object in the Path message only if the use and recording of TE link labels are requested/ mandated for this LSP. If the hop recognizes this flag but is not able to comply with this mandate because of local policy, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'Label stack imposition failure (71)'.
明示的な委任：パスメッセージの明示的なルートオブジェクト（ERO）のHOP_ATTRIBUTESサブオブジェクト[RFC7570]にこのフラグが存在することは、先行するIPv4またはIPv6または番号なしのインターフェイスIDサブオブジェクトによって識別されるホップが選択されたことを示します。明示的な委任ホップとして。このフラグを運ぶHOP_ATTRIBUTESサブオブジェクトには、R（必須）ビットが設定されている必要があります。このLSPに対してTEリンクラベルの使用と記録が要求/義務付けられている場合にのみ、Pathメッセージ内のEROオブジェクトのHOP_ATTRIBUTESサブオブジェクトにこのフラグを設定する必要があります。ホップがこのフラグを認識しても、ローカルポリシーのためにこのマンデートに準拠できない場合は、エラーコード「Routing Problem（24）」とエラー値「Label stack imposition failure（71 ） '。
Flag (0x04): Delegation Label
フラグ（0x04）：委任ラベル
The presence of this flag indicates that the recorded label is a delegation label. This flag MUST be used by a node only if the use and recording of TE link labels and delegation are requested/mandated for the LSP.
このフラグの存在は、記録されたラベルが委任ラベルであることを示します。 LSPに対してTEリンクラベルと委任の使用と記録が要求/義務付けられている場合にのみ、このフラグをノードで使用する必要があります。
Bit Number 18: Label Stack Imposition - Delegation - Stack to Reach Egress (LSI-D-S2E)
ビット番号18：ラベルスタックの面付け-委任-出力に到達するスタック（LSI-D-S2E）
The presence of this flag in the LSP_ATTRIBUTES object of a Path message indicates that the ingress has chosen to use the "Stack to reach egress" approach for stacking. The absence of this flag in the LSP_ATTRIBUTES object of a Path message indicates that the ingress has chosen to use the "Stack to reach delegation hop" approach for stacking. This flag MUST be set in the LSP_ATTRIBUTES object of a Path message only if the use and recording of TE link labels and delegation are requested/mandated for this LSP. If the transit hop is not able to support the "Stack to reach egress" approach, it MUST send a PathErr message with an error code of 'Routing Problem (24)' and an error value of 'Label stack imposition failure (71)'.
PathメッセージのLSP_ATTRIBUTESオブジェクトにこのフラグが存在することは、スタッキングに「スタックが出口に到達する」アプローチを使用することを入口が選択したことを示しています。 PathメッセージのLSP_ATTRIBUTESオブジェクトにこのフラグが存在しない場合は、イングレスが「スタックから委任ホップに到達する」アプローチを使用してスタックすることを選択したことを示しています。このLSPに対してTEリンクラベルと委任の使用と記録が要求/義務付けられている場合にのみ、このフラグをPathメッセージのLSP_ATTRIBUTESオブジェクトに設定する必要があります。トランジットホップが「下りで到達するスタック」アプローチをサポートできない場合、「ルーティングの問題（24）」のエラーコードと「ラベルスタックインポジションの失敗（71）」のエラー値を含むPathErrメッセージを送信する必要があります。 。
The format of the ETLD Attributes TLV is shown in Figure 8. The Attribute TLV Type is 6.
ETLD属性TLVのフォーマットを図8に示します。属性TLVタイプは6です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ETLD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The ETLD Attributes TLV
図8：ETLD属性TLV
The presence of this TLV in the HOP_ATTRIBUTES sub-object of an RRO object in the Path message indicates that the hop identified by the preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object supports automatic delegation. This attribute MUST be used only if the use and recording of TE link labels are requested/mandated and automatic delegation is requested for the LSP.
PathメッセージのRROオブジェクトのHOP_ATTRIBUTESサブオブジェクトにこのTLVが存在することは、先行するIPv4またはIPv6またはUnnumbered Interface IDサブオブジェクトによって識別されるホップが自動委任をサポートしていることを示しています。この属性は、TEリンクラベルの使用と記録が要求/義務付けられており、LSPに自動委任が要求されている場合にのみ使用する必要があります。
The ETLD field specifies the effective number of transport labels that this hop (in relation to its position in the path) can potentially send to its downstream hop. It MUST be set to a non-zero value.
ETLDフィールドは、このホップ（パス内の位置に関連）がダウンストリームホップに送信できるトランスポートラベルの有効数を指定します。ゼロ以外の値に設定する必要があります。
The Reserved field is for future specification. It SHOULD be set to zero on transmission and MUST be ignored on receipt to ensure future compatibility.
予約フィールドは将来の仕様用です。送信時にゼロに設定する必要があり（SHOULD）、受信時に無視して、将来の互換性を確保する必要があります。
MPLS LSP ping and traceroute [RFC8029] are applicable for Segment Routed RSVP-TE tunnels. The existing procedures allow for the label stack imposed at a delegation hop to be reported back in the Label Stack Sub-TLV in the MPLS echo reply for traceroute.
MPLS LSP pingおよびtraceroute [RFC8029]は、セグメントルーテッドRSVP-TEトンネルに適用できます。既存の手順では、委任ホップで課されたラベルスタックをtracerouteのMPLSエコー応答のラベルスタックサブTLVに報告することができます。
IANA manages the 'Attribute Flags' subregistry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry located at <http://www.iana.org/assignments/ rsvp-te-parameters>. This document introduces three new Attribute Flags:
IANAは、<http://www.iana.org/assignments/ rsvp-te-parameters>にある「リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）パラメータ」レジストリの一部として「属性フラグ」サブレジストリを管理します。このドキュメントでは、3つの新しい属性フラグを紹介します。
Bit Name Attribute Attribute RRO ERO Reference No Flags Path Flags Resv
ビット名属性属性RRO ERO参照フラグなしパスフラグResv
16 TE Link Label Yes No No No [RFC8577], Section 9.2
16 TEリンクラベルはいいいえいいえいいえ[RFC8577]、セクション9.2
17 LSI-D Yes No No Yes [RFC8577], Section 9.4
17 LSI-Dはいいいえいいえはい[RFC8577]、セクション9.4
18 LSI-D-S2E Yes No No No [RFC8577], Section 9.6
18 LSI-D-S2Eはいいいえいいえいいえ[RFC8577]、セクション9.6
IANA manages the "Attribute TLV Space" registry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry located at <http://www.iana.org/assignments/ rsvp-te-parameters>. This document introduces a new Attribute TLV.
IANAは、「属性TLVスペース」レジストリを、<http://www.iana.org/assignments/ rsvp-te-parameters>にある「Resource Reservation Protocol-Traffic Engineering（RSVP-TE）Parameters」レジストリの一部として管理します。このドキュメントでは、新しい属性TLVを紹介します。
Type Name Allowed on Allowed on Allowed on Reference LSP_ATTRIBUTES LSP_REQUIRED LSP Hop _ATTRIBUTES Attributes
タイプ名Allowed on Allowed on Allowed on Reference LSP_ATTRIBUTES LSP_REQUIRED LSP Hop _ATTRIBUTES属性
6 ETLD No No Yes [RFC8577], Section 9.7
6 ETLDいいえいいえはい[RFC8577]、セクション9.7
11.3. Record Route Label Sub-object Flags: TE Link Label, Delegation Label
11.3. ルートラベルサブオブジェクトフラグの記録：TEリンクラベル、委任ラベル
IANA manages the "Record Route Object Sub-object Flags" registry as part of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located at <http://www.iana.org/assignments/ rsvp-te-parameters>. Prior to this document, this registry did not include Label Sub-object Flags. This document creates the addition of a new subregistry for Label Sub-object Flags as shown below.
IANAは、<http://www.iana.org/assignments/ rsvp-teにある「Resource Reservation Protocol-Traffic Engineering（RSVP-TE）Parameters」レジストリの一部として「Record Route Object Sub-object Flags」レジストリを管理します-parameters>。このドキュメントの前は、このレジストリにはラベルサブオブジェクトフラグが含まれていませんでした。このドキュメントでは、次に示すように、ラベルサブオブジェクトフラグの新しいサブレジストリを追加します。
Flag Name Reference
フラグ名リファレンス
0x1 Global Label [RFC3209] 0x02 TE Link Label [RFC8577], Section 9.3 0x04 Delegation Label [RFC8577], Section 9.5
0x1グローバルラベル[RFC3209] 0x02 TEリンクラベル[RFC8577]、セクション9.3 0x04委任ラベル[RFC8577]、セクション9.5
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". Within this subregistry is a definition of the "Routing Problem" Error Code (24). The definition lists a number of error values that may be used with this error code. IANA has allocated further error values for use with this Error Code as described in this document. The resulting entry in the registry is as follows.
IANAは、「リソース予約プロトコル（RSVP）パラメータ」と呼ばれるレジストリを、「エラーコードとグローバルに定義されたエラー値のサブコード」と呼ばれるサブレジストリで管理しています。このサブレジストリ内には、「ルーティング問題」エラーコード（24）の定義があります。定義には、このエラーコードで使用できるいくつかのエラー値がリストされています。 IANAは、このドキュメントで説明されているように、このエラーコードで使用するためにさらにエラー値を割り当てています。レジストリの結果のエントリは次のとおりです。
24 Routing Problem [RFC3209]
24ルーティングの問題[RFC3209]
This Error Code has the following globally defined Error Value sub-codes:
このエラーコードには、グローバルに定義された次のエラー値サブコードがあります。
70 = TE link label usage failure [RFC8577] 71 = Label stack imposition failure [RFC8577]
70 = TEリンクラベル使用エラー[RFC8577] 71 =ラベルスタックインポジションエラー[RFC8577]
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] and RSVP-TE [RFC3209] and those that are described in [RFC5920] remain relevant.
このドキュメントでは、新しいセキュリティの問題は紹介していません。元のRSVPプロトコル[RFC2205]とRSVP-TE [RFC3209]に関連するセキュリティの考慮事項、および[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.、and 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>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[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：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
[RFC4090] Pan、P。、編、Swallow、G、編、A。Atlas、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月、<https://www.rfc-editor.org/info/rfc4090>。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>.
[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<https://www.rfc-editor.org/info/rfc5420>。
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <https://www.rfc-editor.org/info/rfc7570>.
[RFC7570]マーガリア、C。、編、マルティネリ、G。、ボール、S。、およびB.ライト、「明示的ルートオブジェクト（ERO）のラベルスイッチドパス（LSP）属性」、RFC 7570、DOI 10.17487 / RFC7570、2015年7月、<https://www.rfc-editor.org/info/rfc7570>。
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S.、and M. Chen、 "Detecting Multiprotocol Label Switched（MPLS）Data-Plane Failures、" RFC 8029、DOI 10.17487 / RFC8029、2017年3月、<https://www.rfc-editor.org/info/rfc8029>。
[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>。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, <https://www.rfc-editor.org/info/rfc2961>.
[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVPリフレッシュオーバーヘッド削減拡張機能」、RFC 2961、DOI 10.17487 / RFC2961、4月2001、<https://www.rfc-editor.org/info/rfc2961>。
[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>。
[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, <https://www.rfc-editor.org/info/rfc8370>.
[RFC8370] Beeram、V.、Ed。、Minei、I.、Shakir、R.、Pacella、D。、およびT. Saad、「RSVP-TE展開のスケーラビリティを改善するための手法」、RFC 8370、DOI 10.17487 / RFC8370、2018年5月、<https://www.rfc-editor.org/info/rfc8370>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, <https://www.rfc-editor.org/info/rfc8491>.
[RFC8491] Tantsura、J.、Chunduri、U.、Aldrin、S。、およびL. Ginsberg、「IS-ISを使用したシグナリングの最大SID深度（MSD）」、RFC 8491、DOI 10.17487 / RFC8491、2018年11月、<https ：//www.rfc-editor.org/info/rfc8491>。
[SEG-ROUTING] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-18, December 2018.
[SEG-ROUTING] Bashandy、A.、Ed。、Filsfils、C.、Ed。、Previdi、S.、Decraene、B.、Litkowski、S.、and R. Shakir、 "Segment Routing with MPLS data plane"、 Work in Progress、draft-ietf-spring-segment-routing-mpls-18、2018年12月。
Acknowledgements
謝辞
The authors would like to thank Adrian Farrel, Kireeti Kompella, Markus Jork, and Ross Callon for their input from discussions. Adrian Farrel provided a review and a text suggestion for clarity and readability.
議論からの情報提供に対して、著者はAdrian Farrel、Kireeti Kompella、Markus Jork、Ross Callonに感謝します。エイドリアン・ファレルは、明快さと読みやすさのためにレビューとテキストの提案を提供しました。
Contributors
貢献者
The following individuals contributed to this document:
以下の個人がこの文書に貢献しました：
Raveendra Torvi Juniper Networks Email: rtorvi@juniper.net
Raveendra Torvi Juniper Networksメール：rtorvi@juniper.net
Chandra Ramachandran Juniper Networks Email: csekar@juniper.net
チャンドララマチャンドランジュニパーネットワークスメール：csekar@juniper.net
George Swallow Email: swallow.ietf@gmail.com
ジョージスワローメール：swallow.ietf@gmail.com
Authors' Addresses
著者のアドレス
Harish Sitaraman Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Harish Sitaraman Juniper Networks 1133 Innovation Wayサニーベール、カリフォルニア州94089アメリカ合衆国
Email: harish.ietf@gmail.com
Vishnu Pavan Beeram Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Vishnu Pavan Beeram Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: vbeeram@juniper.net
Tejal Parikh Verizon 400 International Parkway Richardson, TX 75081 United States of America
Tejal Parikh Verizon 400 International Parkway Richardson、TX 75081アメリカ合衆国
Email: tejal.parikh@verizon.com
Tarek Saad Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Tareq Saeed Cisco Systems T00イノベーションドライブカナダ、オンタリオK2K3A ৮カナダ
Email: tsaad.net@gmail.com