[要約] RFC 7032は、Seamless MPLSにおけるLDP Downstream-on-Demandの仕様を定義しています。この仕様の目的は、ネットワークの効率性を向上させ、リソースの最適化を実現することです。
Internet Engineering Task Force (IETF) T. Beckhaus, Ed.
Request for Comments: 7032 Deutsche Telekom AG
Category: Standards Track B. Decraene
ISSN: 2070-1721 Orange
K. Tiruveedhula
Juniper Networks
M. Konstantynowicz, Ed.
L. Martini
Cisco Systems, Inc.
October 2013
LDP Downstream-on-Demand in Seamless MPLS
シームレスMPLSのLDPダウンストリームオンデマンド
Abstract
概要
Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.
シームレスなMPLS設計により、単一のIP / MPLSネットワークを、標準化されたIP / MPLSプロトコルを使用して、大規模なパケットネットワークインフラストラクチャのコア、メトロ、およびアクセス部分に拡張できます。シームレスMPLSの主要な目標の1つは、多数のデバイス、ネットワークトポロジでのデバイスの位置、状態アクセスデバイスが保持できる計算量とメモリの制約など、アクセスネットワーク固有の要件を満たすことです。これは、LDPダウンストリームオンデマンド（DoD）ラベルアドバタイズメントで実現できます。このドキュメントでは、LDP DoDの使用例について説明し、シームレスMPLS設計のコンテキストで必要なLDP DoD手順を示します。
In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.
さらに、LDPラベル要求メッセージ内の新しいオプションのTLVタイプは、高速アップコンバージェンス用に定義されています。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7032.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7032で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Reference Topologies ............................................6
2.1. Access Topologies with Static Routing ......................6
2.2. Access Topologies with Access IGP .........................10
3. LDP DoD Use Cases ..............................................11
3.1. Initial Network Setup .....................................12
3.1.1. AN with Static Routing .............................12
3.1.2. AN with Access IGP .................................13
3.2. Service Provisioning and Activation .......................14
3.3. Service Changes and Decommissioning .......................16
3.4. Service Failure ...........................................17
3.5. Network Transport Failure .................................17
3.5.1. General Notes ......................................17
3.5.2. AN Failure .........................................18
3.5.3. AN/AGN Link Failure ................................19
3.5.4. AGN Failure ........................................20
3.5.5. AGN Network-Side Reachability Failure ..............20
4. LDP DoD Procedures .............................................20
4.1. LDP Label Distribution Control and Retention Modes ........21
4.2. LDP DoD Session Negotiation ...............................23
4.3. Label Request Procedures ..................................23
4.3.1. Access LSR/ABR Label Request .......................23
4.3.2. Label Request Retry ................................24
4.4. Label Withdraw ............................................25
4.5. Label Release .............................................26
4.6. Local-Repair ..............................................27
5. LDP Extension for LDP DoD Fast-Up Convergence ..................27
6. IANA Considerations ............................................29
6.1. LDP TLV Type ..............................................29
7. Security Considerations ........................................29
7.1. LDP DoD Native Security Properties ........................30
7.2. Data-Plane Security .......................................31
7.3. Control-Plane Security ....................................31
8. Acknowledgements ...............................................32
9. References .....................................................33
9.1. Normative References ......................................33
9.2. Informative References ....................................33
Seamless MPLS design [SEAMLESS-MPLS] enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold.
シームレスなMPLS設計[SEAMLESS-MPLS]により、単一のIP / MPLSネットワークを、標準化されたIP / MPLSプロトコルを使用して、大規模なパケットネットワークインフラストラクチャのコア、メトロ、およびアクセス部分に拡張できます。シームレスMPLSの主要な目標の1つは、多数のデバイス、ネットワークトポロジにおけるデバイスの位置、デバイスが保持できる状態アクセスの量を制限する計算およびメモリの制約など、アクセス固有の要件を満たすことです。
In general, MPLS Label Switching Routers (LSRs) implement either LDP or RSVP for MPLS label distribution.
一般に、MPLSラベルスイッチングルータ（LSR）は、MPLSラベル配布用にLDPまたはRSVPを実装します。
The focus of this document is on LDP, as Seamless MPLS design does not include a requirement for general-purpose explicit traffic engineering and bandwidth reservation. This document concentrates on the unicast connectivity only. Multicast connectivity is a subject for further study.
シームレスMPLS設計には、汎用の明示的なトラフィックエンジニアリングと帯域幅予約の要件が含まれていないため、このドキュメントの焦点はLDPにあります。このドキュメントでは、ユニキャスト接続のみに焦点を当てています。マルチキャスト接続は、今後の検討課題です。
In Seamless MPLS design [SEAMLESS-MPLS], IP/MPLS protocol optimization is possible due to relatively simple access network topologies. Examples of such topologies involving access nodes (ANs) and aggregation nodes (AGNs) include:
シームレスMPLS設計[SEAMLESS-MPLS]では、比較的単純なアクセスネットワークトポロジにより、IP / MPLSプロトコルの最適化が可能です。アクセスノード（AN）および集約ノード（AGN）を含むこのようなトポロジの例には、次のものがあります。
a. A single AN homed to a single AGN.
a. 単一のAGNをホームとする単一のAN。
b. A single AN dual-homed to two AGNs.
b. 2つのAGNにデュアルホーム接続された単一のAN。
c. Multiple ANs daisy-chained via a hub-AN to a single AGN.
c. ハブANを介して単一のAGNにデイジーチェーン接続された複数のAN。
d. Multiple ANs daisy-chained via a hub-AN to two AGNs.
d. ハブAを介して2つのAGNにデイジーチェーン接続された複数のANd。
e. Two ANs dual-homed to two AGNs.
e. 2つのANdが2つのAGNにデュアルホーム接続されています。
f. Multiple ANs chained in a ring and dual-homed to two AGNs.
f. リングでチェーン化され、2つのAGNにデュアルホーム接続された複数のAN。
The amount of IP Routing Information Base (RIB) and Forwarding Information Base (FIB) state on ANs can be easily controlled in the listed access topologies by using simple IP routing configuration with either static routes or dedicated access IGP. Note that in all of the above topologies, AGNs act as the access area border routers (access ABRs) connecting the access topology to the rest of the network. Hence, in many cases, it is sufficient for ANs to have a default route pointing towards AGNs in order to achieve complete network connectivity from ANs to the network.
静的ルートまたは専用アクセスIGPのいずれかを使用した単純なIPルーティング構成を使用することにより、ANのIPルーティング情報ベース（RIB）および転送情報ベース（FIB）の状態を、リストされたアクセストポロジで簡単に制御できます。上記のすべてのトポロジで、AGNはアクセストポロジを残りのネットワークに接続するアクセスエリア境界ルーター（アクセスABR）として機能することに注意してください。したがって、多くの場合、ANからネットワークへの完全なネットワーク接続を実現するには、ANがAGNに向かうデフォルトルートを持っているだけで十分です。
However, the amount of MPLS forwarding state requires additional consideration. In general, MPLS routers implement LDP Downstream Unsolicited (LDP DU) label advertisements [RFC5036] and advertise MPLS labels for all valid routes in their RIB tables. This is seen as an inadequate approach for ANs, which require a small subset of the total routes (and associated labels) based on the required connectivity for the provisioned services. Although filters can be applied to those LDP DU label advertisements, it is not seen as a suitable tool to facilitate any-to-any AN-driven connectivity between access and the rest of the MPLS network.
ただし、MPLSフォワーディングステートの量には、追加の考慮事項が必要です。一般に、MPLSルーターはLDPダウンストリーム非要請（LDP DU）ラベルアドバタイズメント[RFC5036]を実装し、RIBテーブル内のすべての有効なルートのMPLSラベルをアドバタイズします。これは、プロビジョニングされたサービスに必要な接続に基づいて、ルート全体（および関連するラベル）の小さなサブセットを必要とするANには不適切なアプローチと見なされます。フィルターはこれらのLDP DUラベルアドバタイズメントに適用できますが、アクセスとMPLSネットワークの残りの部分との間のAny-to-Any AN駆動の接続を容易にする適切なツールとは見なされていません。
This document describes an AN-driven "subscription model" for label distribution in the access network. The approach relies on the standard LDP DoD label advertisements as specified in [RFC5036]. LDP DoD enables on-demand label distribution ensuring that only required labels are requested, provided, and installed. Procedures described in this document are equally applicable to LDP IPv4 and IPv6 address families. For simplicity, the document provides examples based on the LDP IPv4 address family.
このドキュメントでは、アクセスネットワークでのラベル配布のためのAN駆動の「サブスクリプションモデル」について説明します。このアプローチは、[RFC5036]で指定されている標準のLDP DoDラベルアドバタイズに依存しています。 LDP DoDはオンデマンドのラベル配布を可能にし、必要なラベルのみが要求、提供、インストールされるようにします。このドキュメントで説明されている手順は、LDP IPv4およびIPv6アドレスファミリに等しく適用されます。簡単にするために、このドキュメントではLDP IPv4アドレスファミリに基づく例を提供します。
The following sections describe a set of reference access topologies considered for LDP DoD usage and their associated IP routing configurations, followed by LDP DoD use cases and LDP DoD procedures in the context of Seamless MPLS design.
次のセクションでは、LDP DoDの使用とそれに関連するIPルーティング構成について考慮された一連の参照アクセストポロジについて説明し、その後にシームレスMPLS設計のコンテキストでのLDP DoDの使用例とLDP DoDの手順を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
LDP DoD use cases are described in the context of a generic reference end-to-end network topology based on Seamless MPLS design [SEAMLESS-MPLS] as shown in Figure 1.
LDP DoDの使用例は、図1に示すように、シームレスMPLS設計[SEAMLESS-MPLS]に基づく一般的な参照エンドツーエンドネットワークトポロジのコンテキストで説明されています。
+-------+ +-------+ +------+ +------+
---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN
+--------+/ +-------+ +-------+ +------+ +------+
| Access | \/ \/
| Network| /\ /\
+--------+ +-------+ +-------+ +------+ +------+
\---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN
+-------+ +-------+ +------+ +------+
static routes
or access IGP IGP area IGP area
<----Access----><--Aggregation Domain--><----Core----->
<------------------------- MPLS ---------------------->
Figure 1: Seamless MPLS End-to-End Reference Network Topology
図1：シームレスなMPLSエンドツーエンド参照ネットワークトポロジ
The access network is either single- or dual-homed to AGN1x, with either a single parallel link or multiple parallel links to AGN1x.
アクセスネットワークは、AGN1xへのシングルホームまたはデュアルホームであり、AGN1xへの単一のパラレルリンクまたは複数のパラレルリンクを備えています。
Seamless MPLS access network topologies can range from a single- or dual-homed access node to a chain or ring of access nodes, and it can use either static routing or access IGP (IS-IS or OSPF). The following sections describe reference access topologies in more detail.
シームレスなMPLSアクセスネットワークトポロジは、シングルまたはデュアルホームアクセスノードからアクセスノードのチェーンまたはリングまでさまざまで、静的ルーティングまたはアクセスIGP（IS-ISまたはOSPF）を使用できます。次のセクションでは、参照アクセストポロジについて詳しく説明します。
In most cases, access nodes connect to the rest of the network using very simple topologies. Here, static routing is sufficient to provide the required IP connectivity. The following topologies are considered for use with static routing and LDP DoD:
ほとんどの場合、アクセスノードは非常に単純なトポロジを使用して残りのネットワークに接続します。ここでは、必要なIP接続を提供するには静的ルーティングで十分です。次のトポロジは、静的ルーティングおよびLDP DoDでの使用が検討されています。
a. [I1] topology - a single AN homed to a single AGN.
a. [I1]トポロジ-単一のAGNをホームとする単一のAN。
b. [I] topology - multiple ANs daisy-chained to a single AGN.
b. [I]トポロジー-単一のAGNにデイジーチェーン接続された複数のANd。
c. [V] topology - a single AN dual-homed to two AGNs.
c. [V]トポロジー-2つのAGNにデュアルホーム接続された単一のAN。
d. [U2] topology - two ANs dual-homed to two AGNs.
d. [U2]トポロジ-2つのANdが2つのAGNにデュアルホーム接続されています。
e. [Y] topology - multiple ANs daisy-chained to two AGNs.
e. [Y]トポロジー-2つのAGNにデイジーチェーン接続された複数のAN。
The reference static routing and LDP configuration for [V] access topology is shown in Figure 2. The same static routing and LDP configuration also applies to the [I1] topology.
[V]アクセストポロジの参照静的ルーティングとLDP構成を図2に示します。同じ静的ルーティングとLDP構成が[I1]トポロジにも適用されます。
+----+ +-------+
|AN1 +------------------------+ AGN11 +-------
| +-------\ /-----------+ +-\ /
+----+ \ / +-------+ \ /
\/ \/
/\ /\
+----+ / \ +-------+ / \
|AN2 +-------/ \-----------+ AGN12 +-/ \
| +------------------------+ +-------
+----+ +-------+
--(u)-> <-(d)--
<----- static routing -------> <------ IGP ------>
<---- LDP DU ----->
<--------- LDP DoD ----------> <-- labeled BGP -->
(u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks
Figure 2: [V] Access Topology with Static Routes
図2：[V]静的ルートを使用したアクセストポロジ
In line with the Seamless MPLS design, static routes configured on AGN1x and pointing towards the access network are redistributed in either IGP or BGP labeled IP routes [RFC3107].
シームレスMPLS設計に従って、AGN1xで構成され、アクセスネットワークを指す静的ルートは、IGPまたはBGPラベル付きIPルート[RFC3107]で再配布されます。
The reference static routing and LDP configuration for [U2] access topology is shown in Figure 3.
[U2]アクセストポロジの参照静的ルーティングとLDP構成を図3に示します。
+----+ +-------+
(d1) |AN1 +------------------------+ AGN11 +-------
| | + + +-\ /
v +-+--+ +-------+ \ /
| \/
| /\
^ +-+--+ +-------+ / \
| |AN2 + + AGN12 +-/ \
(d2) | +------------------------+ +-------
+----+ +-------+
--(u)-> <-(d)--
<----- static routing -------> <------ IGP ------>
<---- LDP DU ----->
<--------- LDP DoD ----------> <-- labeled BGP -->
(u) static route 0/0 default, (optional) /32 routes (d) static route for AN loopbacks (d1) static route for AN2 loopback and 0/0 default with lower preference (d2) static route for AN1 loopback and 0/0 default with lower preference
（u）スタティックルート0/0デフォルト、（オプション）/ 32ルート（d）ANループバックのスタティックルート（d1）AN2ループバックのスタティックルート、優先度の低い0/0デフォルト（d2）AN1ループバックのスタティックルートおよび0 / 0優先度の低いデフォルト
Figure 3: [U2] Access Topology with Static Routes
図3：[U2]静的ルートを使用したアクセストポロジ
The reference static routing and LDP configuration for [Y] access topology is shown in Figure 4. The same static routing and LDP configuration also applies to the [I] topology.
[Y]アクセストポロジの参照静的ルーティングとLDP構成を図4に示します。同じ静的ルーティングとLDP構成が[I]トポロジにも適用されます。
+-------+
| |---/
/----+ AGN11 |
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
<-(d2)-- <-(d1)-- | |---\
--(u)-> --(u)-> --(u)-> +-------+
<-(d)--
<------- static routing --------> <------ IGP ------>
<---- LDP DU ----->
<----------- LDP DoD -----------> <-- labeled BGP -->
(u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks [1..n]
(d1) static routes: AN loopbacks [2..n]
(d2) static routes: AN loopbacks [3..n]
Figure 4: [Y] Access Topology with Static Routes
図4：[Y]静的ルートを使用したアクセストポロジ
Note that in all of the above topologies, parallel Equal-Cost Multipath (ECMP) (or Layer 2 Link Aggregation Group (L2 LAG)) links can be used between the nodes.
上記のすべてのトポロジでは、ノード間で並列等コストマルチパス（ECMP）（またはレイヤー2リンク集約グループ（L2 LAG））リンクを使用できます。
ANs support Inter-area LDP [RFC5283] in order to use the IP default route to match the LDP Forwarding Equivalence Class (FEC) advertised by AGN1x and other ANs.
ANは、AGN1xおよび他のANによってアドバタイズされたLDP Forwarding Equivalence Class（FEC）と一致するIPデフォルトルートを使用するために、エリア間LDP [RFC5283]をサポートしています。
A dedicated access IGP instance is used in the access network to perform the internal routing between AGN1x and connected AN devices. Examples of such an IGP could be IS-IS, OSPFv2 and v3, or RIPv2 and RIPng. This access IGP instance is distinct from the IGP of the aggregation domain.
専用アクセスIGPインスタンスがアクセスネットワークで使用され、AGN1xと接続されたANデバイス間の内部ルーティングを実行します。そのようなIGPの例は、IS-IS、OSPFv2およびv3、またはRIPv2およびRIPngです。このアクセスIGPインスタンスは、集約ドメインのIGPとは異なります。
The following topologies are considered for use with access IGP routing and LDP DoD:
次のトポロジは、アクセスIGPルーティングおよびLDP DoDでの使用が検討されています。
a. [U] topology - multiple ANs chained in an open ring and dual-homed to two AGNs.
a. [U]トポロジ-オープンリングでチェーン化され、2つのAGNにデュアルホーム接続された複数のAN。
b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two AGNs.
b. [Y]トポロジ-ハブANを介して2つのAGNにデイジーチェーン接続された複数のAN。
The reference access IGP and LDP configuration for [U] access
topology is shown in Figure 5.
+-------+
+-----+ +-----+ +----+ | +---/
| AN3 |---| AN2 |---|AN1 +-----+ AGN11 |
+-----+ +-----+ +----+ | +---\
. +-------+
.
. +-------+
+-----+ +-----+ +----+ | +---/
|ANn-2|---|ANn-1|---|ANn +-----+ AGN12 |
+-----+ +-----+ +----+ | +---\
+-------+
<---------- access IGP ------------> <------ IGP ------>
<---- LDP DU ----->
<------------ LDP DoD -------------> <-- labeled BGP -->
Figure 5: [U] Access Topology with Access IGP
図5：[U] Access IGPによるアクセストポロジ
The reference access IGP and LDP configuration for [Y] access
topology is shown in Figure 6.
+-------+
| |---/
/----+ AGN11 |2
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
| |---\
+-------+
<---------- access IGP ------------> <------ IGP ------>
<---- LDP DU ----->
<------------ LDP DoD -------------> <-- labeled BGP -->
Figure 6: [Y] Access Topology with Access IGP
図6：[IG] Access IGPを使用したアクセストポロジ
Note that in all of the above topologies, parallel ECMP (or L2 LAG) links can be used between the nodes.
上記のトポロジのすべてで、ノード間で並列ECMP（またはL2 LAG）リンクを使用できることに注意してください。
In both of the above topologies, ANs (ANn ... AN1) and AGN1x share the access IGP and advertise their IPv4 and IPv6 loopbacks and link addresses. AGN1x advertises a default route into the access IGP.
上記のトポロジの両方で、AN（ANn ... AN1）とAGN1xはアクセスIGPを共有し、IPv4およびIPv6ループバックとリンクアドレスをアドバタイズします。 AGN1xは、デフォルトルートをアクセスIGPにアドバタイズします。
ANs support Inter-area LDP [RFC5283] in order to use the IP default route for matching the LDP FECs advertised by AGN1x or other ANs.
ANは、AGN1xまたは他のANによってアドバタイズされたLDP FECを照合するためにIPデフォルトルートを使用するために、エリア間LDP [RFC5283]をサポートします。
LDP DoD use cases described in this document are based on the Seamless MPLS scenarios listed in Seamless MPLS design [SEAMLESS-MPLS]. This section illustrates these use cases focusing on services provisioned on the access nodes and clarifies expected LDP DoD operation on the AN and AGN1x devices. Two representative service types are used to illustrate the service use cases: MPLS Pseudowire Edge-to-Edge (PWE3) [RFC4447] and BGP/MPLS IP VPN [RFC4364].
このドキュメントで説明されているLDP DoDの使用例は、シームレスMPLS設計[SEAMLESS-MPLS]に記載されているシームレスMPLSシナリオに基づいています。このセクションでは、アクセスノードにプロビジョニングされたサービスに焦点を当てたこれらの使用例を示し、ANおよびAGN1xデバイスで予想されるLDP DoD動作を明らかにします。サービスの使用例を示すために、2つの代表的なサービスタイプ、MPLS疑似配線エッジツーエッジ（PWE3）[RFC4447]とBGP / MPLS IP VPN [RFC4364]が使用されています。
Described LDP DoD operations apply equally to all reference access topologies described in Section 2. Operations that are specific to certain access topologies are called out explicitly.
説明されているLDP DoD操作は、セクション2で説明されているすべての参照アクセストポロジに等しく適用されます。特定のアクセストポロジに固有の操作は、明示的に呼び出されます。
References to upstream and downstream nodes are made in line with the definition of upstream and downstream LSRs [RFC3031].
アップストリームおよびダウンストリームノードへの参照は、アップストリームおよびダウンストリームLSR [RFC3031]の定義に沿って行われます。
An access node is commissioned without any services provisioned on it. The AN can request labels for loopback addresses of any AN, AGN, or other nodes within the Seamless MPLS network for operational and management purposes. It is assumed that AGN1x has the required IP/MPLS configuration for network-side connectivity in line with Seamless MPLS design [SEAMLESS-MPLS].
アクセスノードは、サービスがプロビジョニングされていない状態で稼働しています。 ANは、運用および管理の目的で、シームレスMPLSネットワーク内のAN、AGN、またはその他のノードのループバックアドレスのラベルを要求できます。 AGN1xには、シームレスMPLS設計[SEAMLESS-MPLS]に沿ったネットワーク側の接続に必要なIP / MPLS構成があると想定されています。
LDP sessions are configured between adjacent ANs and AGN1x using their respective loopback addresses.
LDPセッションは、それぞれのループバックアドレスを使用して、隣接するANとAGN1xの間で構成されます。
If access static routing is used, ANs are provisioned with the following static IP routing entries (topology references from Section 2 are listed in square brackets):
アクセススタティックルーティングを使用する場合、ANdには次のスタティックIPルーティングエントリがプロビジョニングされます（セクション2のトポロジ参照は角括弧内に記載されています）。
a. [I1, V, U2] - Static default route 0/0 pointing to links connected to AGN1x. Requires support for Inter-area LDP [RFC5283].
a. [I1、V、U2]-AGN1xに接続されたリンクを指す静的デフォルトルート0/0。エリア間LDP [RFC5283]のサポートが必要です。
b. [U2] - Static /32 routes pointing to the other AN. Lower preference static default route 0/0 pointing to links connected to the other AN. Requires support for Inter-area LDP [RFC5283].
b. [U2]-他のANを指す静的/ 32ルート。優先順位の低い静的デフォルトルート0/0は、他のANに接続されたリンクを指します。エリア間LDP [RFC5283]のサポートが必要です。
c. [I, Y] - Static default route 0/0 pointing to links leading towards AGN1x. Requires support for Inter-area LDP [RFC5283].
c. [I、Y]-AGN1xにつながるリンクを指す静的デフォルトルート0/0。エリア間LDP [RFC5283]のサポートが必要です。
d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing to links towards those ANs.
d. [I、Y]-デイジーチェーン内のすべてのANへのスタティック/ 32ルートは、それらのANへのリンクを指します。
e. [I1, V, U2] - Optional - Static /32 routes for specific nodes within the Seamless MPLS network, pointing to links connected to AGN1x.
e. [I1、V、U2]-オプション-シームレスMPLSネットワーク内の特定のノードの静的/ 32ルート。AGN1xに接続されたリンクを指します。
f. [I, Y] - Optional - Static /32 routes for specific nodes within the Seamless MPLS network, pointing to links leading towards AGN1x.
f. [I、Y]-オプション-シームレスMPLSネットワーク内の特定のノードの静的/ 32ルート。AGN1xにつながるリンクを指します。
The upstream AN/AGN1x requests labels over an LDP DoD session(s) from downstream AN/AGN1x for configured static routes if those static routes are configured with an LDP DoD request policy and if they are pointing to a next hop selected by routing. It is expected that all configured /32 static routes to be used for LDP DoD are configured with such a policy on an AN/AGN1x.
設定されたスタティックルートがLDP DoD要求ポリシーで設定され、ルーティングによって選択されたネクストホップを指している場合、アップストリームAN / AGN1xは、設定されたスタティックルートのダウンストリームAN / AGN1xからのLDP DoDセッションでラベルを要求します。 LDP DoDに使用されるすべての構成済み/ 32静的ルートは、AN / AGN1xでこのようなポリシーを使用して構成されていることが予想されます。
The downstream AN/AGN1x responds to the Label Request from the upstream AN/AGN1x with a label mapping if the requested route is present in its RIB and there is a valid label binding from its downstream neighbor or if it is the egress node. In such a case, the downstream AN/AGN1x installs the advertised label as an incoming label in its label information base (LIB) and its label forwarding information base (LFIB). The upstream AN/AGN1x also installs the received label as an outgoing label in its LIB and LFIB. If the downstream AN/AGN1x does have the route present in its RIB, but does not have a valid label binding from its downstream neighbor, it forwards the request to its downstream neighbor.
要求されたルートがRIBに存在し、下流のネイバーからの有効なラベルバインディングがある場合、またはそれが出力ノードである場合、ダウンストリームAN / AGN1xは、ラベルマッピングでアップストリームAN / AGN1xからのラベル要求に応答します。そのような場合、ダウンストリームAN / AGN1xは、そのラベル情報ベース（LIB）とそのラベル転送情報ベース（LFIB）に着信ラベルとしてアドバタイズされたラベルをインストールします。アップストリームのAN / AGN1xも、LIBとLFIBに受信ラベルを発信ラベルとしてインストールします。ダウンストリームAN / AGN1xには、RIBにルートが存在するが、ダウンストリームネイバーからの有効なラベルバインディングがない場合、要求をダウンストリームネイバーに転送します。
In order to facilitate ECMP and IP Fast Reroute (IPFRR) Loop-Free Alternate (LFA) local-repair [RFC5286], the upstream AN/AGN1x also sends LDP DoD Label Requests to alternate next hops per its RIB, and installs received labels as alternate entries in its LIB and LFIB.
ECMPおよびIP高速リルート（IPFRR）ループフリー代替（LFA）ローカル修復[RFC5286]を容易にするために、上流のAN / AGN1xはLDP DoDラベル要求をそのRIBごとに代替ネクストホップに送信し、受信したラベルを次のようにインストールします。 LIBおよびLFIBの代替エントリ。
The AGN1x on the network side can use BGP labeled IP routes [RFC3107] in line with the Seamless MPLS design [SEAMLESS-MPLS]. In such a case, AGN1x will redistribute its static routes pointing to local ANs into BGP labeled IP routes to facilitate network-to-access traffic flows. Likewise, to facilitate access-to-network traffic flows, AGN1x will respond to access-originated LDP DoD Label Requests with label mappings based on its BGP labeled IP routes reachability for requested FECs.
ネットワーク側のAGN1xは、シームレスMPLS設計[SEAMLESS-MPLS]に従って、BGPラベル付きIPルート[RFC3107]を使用できます。このような場合、AGN1xは、ローカルANを指す静的ルートをBGPラベル付きIPルートに再配布して、ネットワークからアクセスへのトラフィックフローを促進します。同様に、ネットワークへのアクセストラフィックフローを容易にするために、AGN1xは、アクセス元のLDP DoDラベル要求に、要求されたFECのBGPラベル付きIPルート到達可能性に基づくラベルマッピングで応答します。
If access IGP is used, an AN(s) advertises its loopbacks over the access IGP with configured metrics. The AGN1x advertises a default route over the access IGP.
アクセスIGPが使用されている場合、ANは設定されたメトリックを使用して、アクセスIGPを介してループバックをアドバタイズします。 AGN1xは、アクセスIGPを介してデフォルトルートをアドバタイズします。
Routers request labels over LDP DoD session(s) according to their needs for MPLS connectivity (via Label Switching Paths (LSPs)). In particular, if AGNs, as per Seamless MPLS design [SEAMLESS-MPLS], redistribute routes from the IGP into BGP labeled IP routes [RFC3107], they request labels over LDP DoD session(s) for those routes.
ルータは、MPLS接続の必要性に応じて（ラベルスイッチングパス（LSP）を介して）LDP DoDセッションを介してラベルを要求します。特に、シームレスMPLS設計[SEAMLESS-MPLS]のようにAGNがIGPからBGPラベル付きIPルート[RFC3107]にルートを再配布する場合、それらのルートのLDP DoDセッションでラベルを要求します。
Identical to the static route case, the downstream AN/AGN1x responds to the Label Request from the upstream AN/AGN1x with a label mapping (if the requested route is present in its RIB and there is a valid label binding from its downstream neighbor), and installs the advertised label as an incoming label in its LIB and LFIB. The upstream AN/AGN1x also installs the received label as an outgoing label in its LIB and LFIB.
スタティックルートの場合と同様に、ダウンストリームAN / AGN1xは、上流AN / AGN1xからのラベル要求にラベルマッピングで応答します（要求されたルートがRIBに存在し、その下流ネイバーからの有効なラベルバインディングがある場合）。アドバタイズされたラベルを着信ラベルとしてLIBおよびLFIBにインストールします。アップストリームのAN / AGN1xも、LIBとLFIBに受信ラベルを発信ラベルとしてインストールします。
Identical to the static route case, in order to facilitate ECMP and IPFRR LFA local-repair, the upstream AN/AGN1x also sends LDP DoD Label Requests to alternate next hops per its RIB, and it installs received labels as alternate entries in its LIB and LFIB.
スタティックルートの場合と同様に、ECMPおよびIPFRR LFAローカル修復を容易にするために、アップストリームAN / AGN1xは、RIBごとに代替ネクストホップにLDP DoDラベル要求も送信し、受信したラベルをそのLIBの代替エントリとしてインストールします。 LFIB。
The AGN1x on the network side can use labeled BGP [RFC3107] in line with Seamless MPLS design [SEAMLESS-MPLS]. In such a case, AGN1x will redistribute routes received over the access IGP (and pointing to local ANs), into BGP labeled IP routes to facilitate network-to-access traffic flows. Likewise, to facilitate access-to-network traffic flows, the AGN1x will respond to access-originated LDP DoD Label Requests with label mappings based on its BGP labeled IP routes reachability for requested FECs.
ネットワーク側のAGN1xは、シームレスMPLS設計[SEAMLESS-MPLS]に沿ってラベル付きBGP [RFC3107]を使用できます。このような場合、AGN1xは、アクセスIGPを介して受信された（ローカルANを指している）ルートをBGPラベル付きIPルートに再配布して、ネットワークからアクセスへのトラフィックフローを促進します。同様に、ネットワークトラフィックフローへのアクセスを容易にするために、AGN1xは、アクセス元のLDP DoDラベル要求に、要求されたFECのBGPラベル付きIPルート到達可能性に基づくラベルマッピングで応答します。
Following the initial setup phase described in Section 3.1, a specific access node, referred to as AN*, is provisioned with a network service. AN* relies on LDP DoD to request the required MPLS LSP(s) label(s) from the downstream AN/AGN1x node(s). Note that LDP DoD operations are service agnostic; that is, they are the same independently of the services provisioned on the AN*.
セクション3.1で説明した初期設定フェーズに続いて、AN *と呼ばれる特定のアクセスノードにネットワークサービスがプロビジョニングされます。 AN *はLDP DoDに依存して、ダウンストリームAN / AGN1xノードから必要なMPLS LSPラベルを要求します。 LDP DoD操作はサービスに依存しないことに注意してください。つまり、AN *でプロビジョニングされたサービスとは無関係に同じです。
For illustration purposes, two service types are described: MPLS PWE3 [RFC4447] service and BGP/MPLS IPVPN [RFC4364].
説明のために、MPLS PWE3 [RFC4447]サービスとBGP / MPLS IPVPN [RFC4364]という2つのサービスタイプについて説明します。
MPLS PWE3 service: For description simplicity, it is assumed that a single segment pseudowire is signaled using targeted LDP (tLDP) FEC128 (0x80), and it is provisioned with the pseudowire ID and the loopback IPv4 address of the destination node. The following IP/MPLS operations need to be completed on the AN* to successfully establish such PWE3 service:
MPLS PWE3サービス：説明を簡単にするために、単一セグメントの疑似配線がターゲットLDP（tLDP）FEC128（0x80）を使用してシグナリングされ、疑似配線IDと宛先ノードのループバックIPv4アドレスがプロビジョニングされていると想定しています。このようなPWE3サービスを正常に確立するには、AN *で次のIP / MPLS操作を完了する必要があります。
a. LSP labels for destination /32 FEC (outgoing label) and the local /32 loopback (incoming label) need to be signaled using LDP DoD.
a. 宛先/ 32 FEC（発信ラベル）およびローカル/ 32ループバック（着信ラベル）のLSPラベルは、LDP DoDを使用して通知する必要があります。
b. A tLDP session over an associated TCP/IP connection needs to be established to the PWE3 destination Provider Edge (PE). This is triggered either by an explicit tLDP session configuration on the AN* or automatically at the time of provisioning the PWE3 instance.
b. 関連するTCP / IP接続を介したtLDPセッションは、PWE3宛先プロバイダーエッジ（PE）に対して確立する必要があります。これは、AN *の明示的なtLDPセッション構成によって、またはPWE3インスタンスのプロビジョニング時に自動的にトリガーされます。
c. Local and remote PWE3 labels for specific FEC128 PW ID need to be signaled using tLDP and PWE3 signaling procedures [RFC4447].
c. 特定のFEC128 PW IDのローカルおよびリモートのPWE3ラベルは、tLDPおよびPWE3シグナリング手順[RFC4447]を使用してシグナリングする必要があります。
d. Upon successful completion of the above operations, AN* programs its RIB/LIB and LFIB tables and activates the MPLS PWE3 service.
d. 上記の操作が正常に完了すると、AN *はRIB / LIBおよびLFIBテーブルをプログラムし、MPLS PWE3サービスをアクティブにします。
Note: Only minimum operations applicable to service connectivity have been listed. Other non-IP/non-MPLS connectivity operations that are required for successful service provisioning and activation are out of scope in this document.
注：サービス接続に適用できる最小限の操作のみがリストされています。サービスのプロビジョニングとアクティブ化を成功させるために必要なその他の非IP /非MPLS接続操作は、このドキュメントの範囲外です。
BGP/MPLS IPVPN service: For description simplicity, it is assumed that the AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for short) [RFC4364]. The following IP/MPLS operations need to be completed on the AN* to successfully establish VPNv4 service:
BGP / MPLS IPVPNサービス：説明を簡単にするために、AN *にはユニキャストIPv4 IPVPNサービス（略してVPNv4）[RFC4364]がプロビジョニングされていると想定しています。 VPNv4サービスを正常に確立するには、AN *で次のIP / MPLS操作を完了する必要があります。
a. BGP peering sessions with associated TCP/IP connections need to be established with the remote destination VPNv4 PEs or Route Reflectors.
a. 関連するTCP / IP接続を使用するBGPピアリングセッションは、リモート宛先VPNv4 PEまたはルートリフレクターを使用して確立する必要があります。
b. Based on configured BGP policies, VPNv4 BGP Network Layer Reachability Information (NLRI) needs to be exchanged between AN* and its BGP peers.
b. 構成済みのBGPポリシーに基づいて、VPNv4 BGPネットワーク層到達可能性情報（NLRI）をAN *とそのBGPピア間で交換する必要があります。
c. Based on configured BGP policies, VPNv4 routes need to be installed in the AN* VPN Routing and Forwarding (VRF) RIB and FIB, with corresponding BGP next hops.
c. 構成されたBGPポリシーに基づいて、VPNv4ルートは、対応するBGPネクストホップと共に、AN * VPNルーティングおよび転送（VRF）RIBおよびFIBにインストールする必要があります。
d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) and the local /32 loopback (incoming label) need to be signaled using LDP DoD.
d. 宛先BGPネクストホップ/ 32 FEC（発信ラベル）およびローカル/ 32ループバック（着信ラベル）のLSPラベルは、LDP DoDを使用してシグナリングする必要があります。
e. Upon successful completion of above operations, AN* programs its RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN service.
e. 上記の操作が正常に完了すると、AN *はRIB / LIBおよびLFIBテーブルをプログラムし、BGP / MPLS IPVPNサービスをアクティブにします。
Note: Only minimum operations applicable to service connectivity have been listed. Other non-IP/-MPLS connectivity operations that are required for successful service provisioning are out of scope in this document.
注：サービス接続に適用できる最小限の操作のみがリストされています。サービスのプロビジョニングを成功させるために必要なその他の非IP / -MPLS接続操作は、このドキュメントの範囲外です。
To establish an LSP for destination /32 FEC for any of the above services, AN* looks up its local routing table for a matching route and selects the best next hop(s) and associated outgoing link(s).
上記のサービスのいずれかで宛先/ 32 FECのLSPを確立するために、AN *はローカルルーティングテーブルを検索して一致するルートを探し、最適なネクストホップと関連する発信リンクを選択します。
If a label for this /32 FEC is not already installed based on the configured static route with LDP DoD request policy or access IGP RIB entry, AN* sends an LDP DoD label mapping request. A downstream AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and associated valid outgoing label binding, and if both are present, replies with its label for this FEC and installs this label as incoming in its LIB and LFIB. Upon receiving the label mapping, the AN* accepts this label based on the exact route match of the advertised FEC and route entry in its RIB or based on the longest match in line with Inter-area LDP [RFC5283]. If the AN* accepts the label, it installs it as an outgoing label in its LIB and LFIB.
この/ 32 FECのラベルが、LDP DoD要求ポリシーまたはアクセスIGP RIBエントリで構成された静的ルートに基づいてまだインストールされていない場合、AN *はLDP DoDラベルマッピング要求を送信します。ダウンストリームAN / AGN1x LSRは、要求された/ 32および関連する有効な発信ラベルバインディングの存在についてRIBをチェックし、両方が存在する場合、このFECのラベルで応答し、このラベルをLIBおよびLFIBの着信としてインストールします。ラベルマッピングを受信すると、AN *は、アドバタイズされたFECとRIBのルートエントリの正確なルート一致に基づいて、またはエリア間LDP [RFC5283]に沿った最長一致に基づいて、このラベルを受け入れます。 AN *がラベルを受け入れる場合、AN *はそのラベルを発信ラベルとしてLIBおよびLFIBにインストールします。
In access topologies [V] and [Y], if AN* is dual-homed to two AGN1x and routing entries for these AGN1x's are configured as equal-cost paths, AN* sends LDP DoD Label Requests to both AGN1x devices and installs all received labels in its LIB and LFIB.
アクセストポロジ[V]と[Y]で、AN *が2つのAGN1xにデュアルホーム接続され、これらのAGN1xのルーティングエントリが等コストパスとして構成されている場合、AN *はLDP DoDラベル要求を両方のAGN1xデバイスに送信し、受信したすべてをインストールしますLIBおよびLFIBのラベル。
In order for AN* to implement IPFRR LFA local-repair, AN* also sends LDP DoD Label Requests to alternate next hops per its RIB, and installs received labels as alternate entries in its LIB and LFIB.
AN *がIPFRR LFAローカル修復を実装するために、AN *はLDP DoDラベル要求をそのRIBごとの代替ネクストホップに送信し、受信したラベルをそのLIBおよびLFIBの代替エントリとしてインストールします。
When forwarding PWE3 or VPNv4 packets, AN* chooses the LSP label based on the locally configured static /32 or default route or default route signaled via access IGP. If a route is reachable via multiple interfaces to AGN1x nodes and the route has multiple equal-cost paths, AN* implements ECMP functionality. This involves AN* using a hash-based load-balancing mechanism and sending the PWE3 or VPNv4 packets in a flow-aware manner with appropriate LSP labels via all equal-cost links.
PWE3またはVPNv4パケットを転送するとき、AN *はローカルに構成された静的/ 32またはデフォルトルート、またはアクセスIGPを介して通知されるデフォルトルートに基づいてLSPラベルを選択します。 AGN1xノードへの複数のインターフェースを介してルートに到達でき、ルートに複数の等コストパスがある場合、AN *はECMP機能を実装します。これには、ハッシュベースのロードバランシングメカニズムを使用するAN *と、すべての等コストリンクを介した適切なLSPラベルを使用したフロー認識方式でのPWE3またはVPNv4パケットの送信が含まれます。
The ECMP mechanism is applicable in an equal manner to parallel links between two network elements and multiple paths towards the destination. The traffic demand is distributed over the available paths.
ECMPメカニズムは、2つのネットワーク要素間の並列リンクと宛先への複数のパスに同様に適用できます。トラフィックの需要は、利用可能なパスに分散されます。
The AGN1x on the network side can use labeled BGP [RFC3107] in line with Seamless MPLS design [SEAMLESS-MPLS]. In such a case, the AGN1x will redistribute its static routes (or routes received from the access IGP) pointing to local ANs into BGP labeled IP routes to facilitate network-to-access traffic flows. Likewise, to facilitate access-to-network traffic flows, the AGN1x will respond to access-originated LDP DoD Label Requests with label mappings based on its BGP labeled IP routes reachability for requested FECs.
ネットワーク側のAGN1xは、シームレスMPLS設計[SEAMLESS-MPLS]に沿ってラベル付きBGP [RFC3107]を使用できます。このような場合、AGN1xは、ローカルANを指す静的ルート（またはアクセスIGPから受信したルート）をBGPラベル付きIPルートに再配布して、ネットワークからアクセスへのトラフィックフローを促進します。同様に、ネットワークトラフィックフローへのアクセスを容易にするために、AGN1xは、アクセス元のLDP DoDラベル要求に、要求されたFECのBGPラベル付きIPルート到達可能性に基づくラベルマッピングで応答します。
Whenever the AN* service gets decommissioned or changed and connectivity to a specific destination is no longer required, the associated MPLS LSP label resources are to be released on AN*.
AN *サービスが廃止または変更され、特定の宛先への接続が不要になった場合は常に、関連するMPLS LSPラベルリソースがAN *で解放されます。
MPLS PWE3 service: If the PWE3 service gets decommissioned and it is the last PWE3 to a specific destination node, the tLDP session is no longer needed and is to be terminated (automatically or by configuration). The MPLS LSP(s) to that destination is no longer needed either.
MPLS PWE3サービス：PWE3サービスが廃止され、それが特定の宛先ノードへの最後のPWE3である場合、tLDPセッションは不要になり、終了します（自動または構成により）。その宛先へのMPLS LSPも不要になりました。
BGP/MPLS IPVPN service: Deletion of a specific VPNv4 (VRF) instance via local or remote reconfiguration can result in a specific BGP next hop(s) no longer being needed. The MPLS LSP(s) to that destination is no longer needed either.
BGP / MPLS IPVPNサービス：ローカルまたはリモートの再構成を介して特定のVPNv4（VRF）インスタンスを削除すると、特定のBGPネクストホップが不要になる可能性があります。その宛先へのMPLS LSPも不要になりました。
In all of the above cases, the following operations related to LDP DoD apply:
上記のすべてのケースで、LDP DoDに関連する次の操作が適用されます。
o If the /32 FEC label for the aforementioned destination node was originally requested based on either tLDP session configuration and default route or required BGP next hop and default route, AN* deletes the label from its LIB and LFIB, and releases it from the downstream AN/AGN1x by using LDP DoD procedures.
o 前述の宛先ノードの/ 32 FECラベルがtLDPセッション構成とデフォルトルート、または必要なBGPネクストホップとデフォルトルートに基づいて最初に要求された場合、AN *はそのラベルをLIBおよびLFIBから削除し、ダウンストリームANから解放します/ AGN1x（LDP DoDプロシージャを使用）。
o If the /32 FEC label was originally requested based on the static /32 route configuration with LDP DoD request policy, the label is retained by AN*.
o / 32 FECラベルが元々、LDP DoD要求ポリシーを使用した静的/ 32ルート構成に基づいて要求された場合、そのラベルはAN *によって保持されます。
A service instance can stop being operational due to a local or remote service failure event.
ローカルまたはリモートのサービス障害イベントが原因で、サービスインスタンスが動作を停止する可能性があります。
In general, unless the service failure event modifies required MPLS connectivity, there is no impact on the LDP DoD operation.
一般に、サービス障害イベントによって必要なMPLS接続が変更されない限り、LDP DoD動作に影響はありません。
If the service failure event does modify the required MPLS connectivity, LDP DoD operations apply as described in Sections 3.2 and 3.3.
サービス障害イベントによって必要なMPLS接続が変更される場合、セクション3.2および3.3で説明されているように、LDP DoD操作が適用されます。
A number of different network events can impact services on AN*. The following sections describe network event types that impact LDP DoD operation on AN and AGN1x nodes.
さまざまなネットワークイベントがAN *のサービスに影響を与える可能性があります。次のセクションでは、ANおよびAGN1xノードでのLDP DoD動作に影響を与えるネットワークイベントタイプについて説明します。
If service on any of the ANs is affected by any network failure and there is no network redundancy, the service goes into a failure state. Upon recovery from network failure, the service is to be re-established automatically.
いずれかのANのサービスがネットワーク障害の影響を受け、ネットワークの冗長性がない場合、サービスは障害状態になります。ネットワーク障害から回復すると、サービスは自動的に再確立されます。
The following additional LDP-related functions need to be supported to comply with Seamless MPLS [SEAMLESS-MPLS] fast service restoration requirements: a. Local-repair: AN and AGN1x support local-repair for adjacent link or node failure for access-to-network, network-to-access, and access-to-access traffic flows. Local-repair is to be implemented by using either IPFRR LDP LFA, simple ECMP, or primary/backup switchover upon failure detection.
シームレスMPLS [SEAMLESS-MPLS]高速サービス復元要件に準拠するには、次の追加のLDP関連機能をサポートする必要があります。ローカル修復：ANおよびAGN1xは、ネットワークへのアクセス、ネットワークへのアクセス、およびアクセスからアクセスへのトラフィックフローの隣接リンクまたはノード障害に対するローカル修復をサポートします。ローカル修復は、IPFRR LDP LFA、シンプルECMP、または障害検出時のプライマリ/バックアップスイッチオーバーのいずれかを使用して実装されます。
b. LDP session protection: LDP sessions are configured with LDP session protection to avoid delay upon the recovery from link failure. LDP session protection ensures that FEC label binding is maintained in the control plane as long as the LDP session stays up.
b. LDPセッション保護：LDPセッションはLDPセッション保護で構成され、リンク障害からの回復時の遅延を回避します。 LDPセッション保護は、LDPセッションが稼働している限り、FECラベルバインディングがコントロールプレーンで維持されることを保証します。
c. IGP-LDP synchronization: If access IGP is used, LDP sessions between ANs, and between ANs and AGN1x, are configured with IGP-LDP synchronization to avoid unnecessary traffic loss in case the access IGP converged before LDP and there is no LDP label binding to the best downstream next hop.
c. IGP-LDP同期：アクセスIGPが使用される場合、AN間、およびANとAGN1x間のLDPセッションは、IGP-LDP同期で構成され、アクセスIGPがLDPの前に収束し、LDPラベルバインディングがない場合に、不要なトラフィック損失を回避します。最良のダウンストリームネクストホップ。
If the AN fails, adjacent AN/AGN1x nodes remove all routes pointing to the failed node from their RIB tables (including /32 loopback belonging to the failed AN and any other routes reachable via the failed AN). In turn, this triggers the removal of associated outgoing /32 FEC labels from their LIB and LFIB tables.
ANに障害が発生すると、隣接するAN / AGN1xノードは、障害が発生したノードを指すすべてのルートをRIBテーブルから削除します（障害が発生したANに属する/ 32ループバック、および障害が発生したAN経由で到達可能なその他のルートを含む）。次に、これにより、関連する発信/ 32 FECラベルがLIBおよびLFIBテーブルから削除されます。
If access IGP is used, the AN failure will be propagated via IGP link updates across the access topology.
アクセスIGPが使用されている場合、AN障害はIGPリンクの更新を介してアクセストポロジ全体に伝播されます。
If a specific /32 FEC(s) is no longer reachable from those ANs/AGN1x's, they also send LDP Label Withdraw messages to their upstream LSRs to notify them about the failure, and remove the associated incoming label(s) from their LIB and LFIB tables. Upstream LSRs, upon receiving a Label Withdraw, remove the signaled labels from their LIB/LFIB tables, and propagate LDP Label Withdraws across their upstream LDP DoD sessions.
特定の/ 32 FECがこれらのAN / AGN1xから到達できなくなった場合、それらはまた、LDPラベルウィズドローメッセージを上流のLSRに送信して、障害について通知し、関連する着信ラベルをLIBおよびLFIBテーブル。上流のLSRは、Label Withdrawを受信すると、シグナリングされたラベルをLIB / LFIBテーブルから削除し、LDP Label Withdrawsを上流のLDP DoDセッション全体に伝播します。
In the [U] topology, there may be an alternative path to routes previously reachable via the failed AN. In this case, adjacent AN/AGN1x pairs invoke local-repair (IPFRR LFA, ECMP) and switch over to an alternate next hop to reach those routes.
[U]トポロジでは、障害が発生したANを介して以前に到達できたルートへの代替パスが存在する場合があります。この場合、隣接するAN / AGN1xペアがローカル修復（IPFRR LFA、ECMP）を呼び出し、これらのルートに到達するために代替ネクストホップに切り替えます。
AGN1x is notified about the AN failure via access IGP (if used) and/or cascaded LDP DoD Label Withdraw(s). AGN1x implements all relevant global-repair IP/MPLS procedures to propagate the AN failure towards the core network. This involves removing associated routes (in the access IGP case) and labels from its LIB and LFIB tables, and propagating the failure on the network side using labeled BGP and/or core IGP/LDP DU procedures.
AGN1xは、アクセスIGP（使用されている場合）やカスケードされたLDP DoDラベルの撤回を介して、AN障害について通知されます。 AGN1xは、関連するすべてのグローバル修復IP / MPLS手順を実装して、AN障害をコアネットワークに伝搬します。これには、関連するルート（アクセスIGPの場合）およびラベルをそのLIBおよびLFIBテーブルから削除し、ラベル付きのBGPやコアIGP / LDP DU手順を使用してネットワーク側で障害を伝播することが含まれます。
Upon the AN coming back up, adjacent AN/AGN1x nodes automatically add routes pointing to recovered links based on the configured static routes or access IGP adjacency and link state updates. This is then followed by LDP DoD label signaling and subsequent binding and installation of labels in LIB and LFIB tables.
ANが復旧すると、隣接するAN / AGN1xノードは、設定されたスタティックルートに基づいて、回復されたリンクを指すルートを自動的に追加するか、IGP隣接およびリンクステートアップデートにアクセスします。次に、LDP DoDラベルシグナリングと、それに続くLIBおよびLFIBテーブルへのラベルのバインドとインストールが続きます。
Depending on the access topology and the failed link location, different cases apply to the network operation after AN link failure (topology references from Section 2 in square brackets):
アクセストポロジと障害が発生したリンクの場所に応じて、ANリンク障害後のネットワーク操作には異なるケースが適用されます（角括弧内のセクション2のトポロジ参照）：
a. [all] - link failed, but at least one ECMP parallel link remains. Nodes on both sides of the failed link stop using the failed link immediately (local-repair) and keep using the remaining ECMP parallel links.
a. [すべて]-リンクに失敗しましたが、少なくとも1つのECMP並列リンクが残っています。障害が発生したリンクの両側のノードは、障害が発生したリンクの使用を直ちに停止し（ローカル修復）、残りのECMPパラレルリンクの使用を継続します。
b. [I1, I, Y] - link failed, and there are no ECMP or alternative links and paths. Nodes on both sides of the failed link remove routes pointing to the failed link immediately from the RIB, remove associated labels from their LIB and LFIB tables, and send LDP Label Withdraw(s) to their upstream LSRs.
b. [I1、I、Y]-リンクが失敗し、ECMPまたは代替リンクとパスがありません。失敗したリンクの両側のノードは、失敗したリンクを指すルートをRIBから即座に削除し、関連するラベルをLIBおよびLFIBテーブルから削除し、LDPラベルの取り消しを上流のLSRに送信します。
c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate path remains. The AN/AGN1x node stops using the failed link and immediately switches over (local-repair) to the remaining ECMP path or alternate path. The AN/AGN1x removes affected next hops and labels. If there is an AGN1x terminating the failed link, it immediately removes routes pointing to the failed link from the RIB, removes any associated labels from the LIB and LFIB tables, and propagates the failure on the network side using labeled BGP and/or core IGP procedures.
c. [U2、U、V、Y]-リンクに失敗しましたが、少なくとも1つのECMPまたは代替パスが残っています。 AN / AGN1xノードは、障害が発生したリンクの使用を停止し、すぐに残りのECMPパスまたは代替パスに切り替えます（ローカル修復）。 AN / AGN1xは、影響を受けるネクストホップとラベルを削除します。失敗したリンクを終端するAGN1xがある場合、失敗したリンクを指すルートをRIBから即座に削除し、関連するラベルをLIBおよびLFIBテーブルから削除し、ラベル付きのBGPまたはコアIGP、あるいはその両方を使用してネットワーク側に障害を伝播します。手順。
If access IGP is used, AN/AGN1x link failure will be propagated via IGP link updates across the access topology.
アクセスIGPが使用されている場合、AN / AGN1xリンク障害は、アクセストポロジ全体のIGPリンク更新を介して伝播されます。
LDP DoD will also propagate the link failure by sending Label Withdraws to upstream AN/AGN1x nodes, and Label Release messages to downstream AN/AGN1x nodes.
LDP DoDはまた、Label Withdrawsを上流のAN / AGN1xノードに送信し、Label Releaseメッセージを下流のAN / AGN1xノードに送信することにより、リンク障害を伝播します。
If an AGN1x fails adjacent access then, depending on the access topology, the following cases apply to the network operation (topology references from Section 2 are shown in square brackets):
AGN1xが隣接アクセスに失敗した場合、アクセストポロジに応じて、次のケースがネットワーク操作に適用されます（セクション2のトポロジ参照は角括弧で示されています）。
a. [I1, I] - ANs are isolated from the network - An AN adjacent to the failure immediately removes routes pointing to the failed AGN1x from the RIB, removes associated labels from the LIB and LFIB tables, and sends LDP Label Withdraw message(s) to its upstream neighbors. If access IGP is used, an IGP link update is sent.
a. [I1、I]-ANはネットワークから分離されます-障害に隣接するANは、障害のあるAGN1xを指すルートをRIBから即座に削除し、関連するラベルをLIBおよびLFIBテーブルから削除し、LDPラベルの取り消しメッセージを送信しますその上流の隣人に。 IGPアクセスが使用されている場合、IGPリンクアップデートが送信されます。
b. [U2, U, V, Y] - at least one ECMP or alternate path remains. AN adjacent to failed AGN1x stops using the failed link and immediately switches over (local-repair) to the remaining ECMP path or alternate path by following LDP [RFC5036] procedures. (Appendix A.1.7 "Detect Change in FEC Next Hop")
b. [U2、U、V、Y]-少なくとも1つのECMPまたは代替パスが残ります。障害が発生したAGN1xに隣接するANは、障害が発生したリンクの使用を停止し、LDP [RFC5036]の手順に従って、残りのECMPパスまたは代替パスに即座に切り替えます（ローカル修復）。 （付録A.1.7「FECネクストホップの変更の検出」）
Network-side procedures for handling AGN1x failure have been described in Seamless MPLS [SEAMLESS-MPLS].
AGN1x障害を処理するためのネットワーク側の手順は、シームレスMPLS [SEAMLESS-MPLS]で説明されています。
If AGN1x loses network reachability to a specific destination or set of network-side destinations, AGN1x sends LDP Label Withdraw messages to its upstream ANs, withdrawing labels for all affected /32 FECs. Upon receiving those messages, ANs remove those labels from their LIB and LFIB tables, and use alternative LSPs instead (if available) as part of global-repair.
AGN1xが特定の宛先またはネットワーク側宛先のセットへのネットワーク到達可能性を失うと、AGN1xはLDP Label Withdrawメッセージを上流のANに送信し、影響を受けるすべての/ 32 FECのラベルを取り消します。これらのメッセージを受信すると、ANはそれらのラベルをLIBおよびLFIBテーブルから削除し、代わりに（利用可能な場合）グローバル修復の一部として代替LSPを使用します。
If access IGP is used, and AGN1x gets completely isolated from the core network, it stops advertising the default route 0/0 into the access IGP.
アクセスIGPが使用され、AGN1xがコアネットワークから完全に分離されると、デフォルトルート0/0のアクセスIGPへのアドバタイズを停止します。
All LDP Downstream-on-Demand implementations follow the Label Distribution Protocol as specified in [RFC5036]. This section does not update [RFC5036] procedures, but illustrates LDP DoD operations in the context of use cases identified in Section 3 in this document, for information only.
すべてのLDPダウンストリームオンデマンド実装は、[RFC5036]で指定されているラベル配布プロトコルに従います。このセクションでは、[RFC5036]の手順を更新しませんが、情報のみを目的として、このドキュメントのセクション3で特定されたユースケースのコンテキストでLDP DoD操作を示します。
In the MPLS architecture [RFC3031], network traffic flows from the upstream LSR to the downstream LSR. The use cases in this document rely on the downstream assignment of labels, where labels are assigned by the downstream LSR and signaled to the upstream LSR as shown in Figure 7.
MPLSアーキテクチャ[RFC3031]では、ネットワークトラフィックはアップストリームLSRからダウンストリームLSRに流れます。このドキュメントの使用例は、ラベルのダウンストリーム割り当てに依存しています。ラベルはダウンストリームLSRによって割り当てられ、図7に示すようにアップストリームLSRに通知されます。
+----------+ +------------+
| upstream | | downstream |
------+ LSR +------+ LSR +----
traffic | | | | address
source +----------+ +------------+ (/32 for IPv4)
traffic
label distribution for IPv4 FEC destination
<-------------------------
traffic flow
------------------------->
Figure 7: LDP Label Assignment Direction
図7：LDPラベルの割り当て方向
The LDP specification [RFC5036] defines two modes for label distribution control, following the definitions in the MPLS architecture [RFC3031]:
LDP仕様[RFC5036]は、MPLSアーキテクチャ[RFC3031]の定義に従って、ラベル配布制御の2つのモードを定義しています。
o Independent mode: An LSR recognizes a particular FEC and makes a decision to bind a label to the FEC independently from distributing that label binding to its label distribution peers. A new FEC is recognized whenever a new route becomes valid on the LSR.
o 独立モード：LSRは特定のFECを認識し、そのラベルバインディングをそのラベル配布ピアに配布することから独立して、ラベルをFECにバインドすることを決定します。 LSRで新しいルートが有効になるたびに、新しいFECが認識されます。
o Ordered mode: An LSR needs to bind a label to a particular FEC if it knows how to forward packets for that FEC (i.e., it has a route corresponding to that FEC) and if it has already received at least one Label Request message from an upstream LSR.
o 順序付きモード：LSRは、そのFECのパケットを転送する方法を知っている（つまり、そのFECに対応するルートを持っている）場合、LSRが特定のFECにラベルをバインドする必要があります。アップストリームLSR。
Using independent label distribution control with LDP DoD and access static routing would prevent the access LSRs from propagating label binding failure along the access topology, making it impossible for an upstream LSR to be notified about the downstream failure and for an application using the LSP to switch over to an alternate path, even if such a path exists.
LDP DoDとアクセススタティックルーティングで独立したラベル配布制御を使用すると、アクセスLSRがアクセストポロジに沿ってラベルバインディング障害を伝播することが防止され、ダウンストリーム障害についてアップストリームLSRに通知されなくなり、LSPを使用するアプリケーションが切り替えられなくなります。そのようなパスが存在する場合でも、代替パスに移動します。
The LDP specification [RFC5036] defines two modes for label retention, following the definitions in the MPLS architecture [RFC3031]:
LDP仕様[RFC5036]は、MPLSアーキテクチャ[RFC3031]の定義に従って、ラベル保持の2つのモードを定義しています。
o Conservative label retention mode: If operating in DoD mode, an LSR will request label mappings only from the next-hop LSR according to routing. The main advantage of the conservative label retention mode is that only the labels that are required for the forwarding of data are allocated and maintained. This is particularly important in LSRs where the label space is inherently limited, such as in an ATM switch. A disadvantage of the conservative label retention mode is that if routing changes the next hop for a given destination, a new label must be obtained from the new next hop before labeled packets can be forwarded.
o保守的なラベル保持モード：DoDモードで動作している場合、LSRはルーティングに従ってネクストホップLSRからのみラベルマッピングを要求します。保守的なラベル保持モードの主な利点は、データの転送に必要なラベルのみが割り当てられ、維持されることです。これは、ATMスイッチなど、ラベルスペースが本質的に制限されているLSRで特に重要です。保守的なラベル保持モードの欠点は、ルーティングによって特定の宛先のネクストホップが変更された場合、ラベル付きパケットを転送する前に、新しいネクストホップから新しいラベルを取得する必要があることです。
o Liberal label retention mode: When operating in DoD mode with liberal label retention mode, an LSR might choose to request label mappings for all known prefixes from all peer LSRs. The main advantage of the liberal label retention mode is that reaction to routing changes can be quick because labels already exist. The main disadvantage of the liberal label retention mode is that unneeded label mappings are distributed and maintained.
o リベラルラベル保持モード：リベラルラベル保持モードでDoDモードで動作している場合、LSRはすべてのピアLSRからのすべての既知のプレフィックスのラベルマッピングを要求することを選択する場合があります。リベラルラベル保持モードの主な利点は、ラベルがすでに存在しているため、ルーティングの変更に対する反応が速くなることです。リベラルラベル保持モードの主な欠点は、不要なラベルマッピングが分散および維持されることです。
Note that the conservative label retention mode would prevent LSRs from requesting and maintaining label mappings for any backup routes that are not used for forwarding. In turn, this would prevent the access LSRs (AN and AGN1x nodes) from implementing any local protection schemes that rely on using alternate next hops in case of the primary next-hop failure. Such schemes include IPFRR LFA if access IGP is used, or a primary and backup static route configuration. Using LDP DoD in combination with liberal label retention mode allows the LSR to request labels for the specific FEC from primary next-hop LSR(s) and the alternate next-hop LSR(s) for this FEC.
保守的なラベル保持モードでは、LSRが転送に使用されていないバックアップルートのラベルマッピングを要求および維持することができないことに注意してください。次に、これにより、アクセスLSR（ANおよびAGN1xノード）が、プライマリネクストホップに障害が発生した場合に代替ネクストホップの使用に依存するローカル保護スキームを実装できなくなります。そのようなスキームには、アクセスIGPが使用されている場合のIPFRR LFA、またはプライマリおよびバックアップの静的ルート構成が含まれます。 LDP DoDをリベラルラベル保持モードと組み合わせて使用すると、LSRは、このFECのプライマリネクストホップLSRおよび代替ネクストホップLSRから特定のFECのラベルを要求できます。
Note that even though LDP DoD operates in a liberal label retention mode, if used with access IGP and if no LFA exists, the LDP DoD will introduce additional delay in traffic restoration as the labels for the new next hop will be requested only after the access IGP convergence.
LDP DoDはリベラルラベル保持モードで動作しますが、アクセスIGPで使用され、LFAが存在しない場合、新しいネクストホップのラベルはアクセス後にのみ要求されるため、LDP DoDはトラフィックの復元に追加の遅延を導入します。 IGPコンバージェンス。
Adhering to the overall design goals of Seamless MPLS [SEAMLESS-MPLS], specifically achieving a large network scale without compromising fast service restoration, all access LSRs (AN and AGN1x nodes) use LDP DoD advertisement mode with:
シームレスMPLS [SEAMLESS-MPLS]の全体的な設計目標を順守し、特に高速サービス復元を損なうことなく大規模なネットワークスケールを達成し、すべてのアクセスLSR（ANおよびAGN1xノード）は、次のLDP DoDアドバタイズメントモードを使用します
o Ordered label distribution control: enables propagation of label binding failure within the access topology.
o 順序付けられたラベル配布制御：アクセストポロジ内でラベルバインディング障害の伝播を有効にします。
o Liberal label retention mode: enables pre-programming of alternate next hops with associated FEC labels.
o リベラルラベル保持モード：関連するFECラベルを持つ代替ネクストホップの事前プログラミングを有効にします。
In Seamless MPLS [SEAMLESS-MPLS], an AGN1x acts as an access ABR connecting access and metro domains. To enable failure propagation between those domains, the access ABR implements ordered label distribution control when redistributing routes/FECs between the access side (using LDP DoD and static or access IGP) and the network side (using labeled BGP [RFC3107] or core IGP with LDP Downstream Unsolicited label advertisements).
シームレスMPLS [SEAMLESS-MPLS]では、AGN1xはアクセスドメインとメトロドメインを接続するアクセスABRとして機能します。これらのドメイン間の障害伝播を有効にするために、アクセス側（LDP DoDおよび静的またはアクセスIGPを使用）とネットワーク側（ラベル付きBGP [RFC3107]またはコアIGPを使用）の間でルート/ FECを再配布するときに、アクセスABRは順序付きラベル配布制御を実装します。 LDPダウンストリーム非送信請求ラベルアドバタイズメント）。
An access LSR/ABR proposes the DoD label advertisement by setting the "A" value to 1 in the Common Session Parameters TLV of the Initialization message. The rules for negotiating the label advertisement mode are specified in the LDP specification [RFC5036].
アクセスLSR / ABRは、初期化メッセージのCommon Session Parameters TLVで「A」値を1に設定することにより、DoDラベルアドバタイズを提案します。ラベルアドバタイズメントモードをネゴシエートするためのルールは、LDP仕様[RFC5036]で指定されています。
To establish a DoD session between the two access LSR/ABRs, both propose the DoD label advertisement mode in the Initialization message. If the access LSR only supports LDP DoD and the access ABR proposes the Downstream Unsolicited mode, the access LSR sends a Notification message with status "Session Rejected/Parameters Advertisement Mode" and then closes the LDP session as specified in the LDP specification [RFC5036].
2つのアクセスLSR / ABR間にDoDセッションを確立するには、どちらも初期化メッセージでDoDラベルアドバタイズメントモードを提案します。アクセスLSRがLDP DoDのみをサポートし、アクセスABRがダウンストリーム非請求モードを提案する場合、アクセスLSRはステータスが「セッション拒否/パラメータアドバタイズメントモード」の通知メッセージを送信し、LDP仕様[RFC5036]で指定されているようにLDPセッションを閉じます。 。
If an access LSR is acting in an active role, it re-attempts the LDP session immediately. If the access LSR receives the same Downstream Unsolicited mode again, it follows the exponential backoff algorithm as defined in the LDP specification [RFC5036] with a delay of 15 seconds and subsequent delays growing to a maximum delay of 2 minutes.
アクセスLSRがアクティブな役割で動作している場合、すぐにLDPセッションを再試行します。アクセスLSRが同じダウンストリーム非送信請求モードを再度受信した場合、LDP仕様[RFC5036]で定義されている指数バックオフアルゴリズムに従い、15秒の遅延とその後の遅延が最大2分の遅延に増加します。
In case a PWE3 service is required between the adjacent access LSR/ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same LDP session is used for PWE3 FECs. Even if the LDP DoD label advertisement has been negotiated for IPv4 and IPv6 LDP FECs as described earlier, the LDP session uses a Downstream Unsolicited label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447].
隣接するアクセスLSR / ABR間でPWE3サービスが必要で、IPv4およびIPv6 FECに対してLDP DoDがネゴシエートされている場合、同じLDPセッションがPWE3 FECに使用されます。 LDP DoDラベルアドバタイズメントがIPv4およびIPv6 LDP FECについてネゴシエートされている場合でも、LDPセッションは、PWE3 LDP [RFC4447]で指定されているPWE3 FECのダウンストリーム非請求ラベルアドバタイズメントを使用します。
The upstream access LSR/ABR will request label bindings from an adjacent downstream access LSR/ABR based on the following trigger events:
アップストリームアクセスLSR / ABRは、次のトリガーイベントに基づいて、隣接するダウンストリームアクセスLSR / ABRからのラベルバインディングを要求します。
a. An access LSR/ABR is configured with /32 static route with LDP DoD Label Request policy in line with the initial network setup use case described in Section 3.1.
a. アクセスLSR / ABRは、セクション3.1で説明されている初期ネットワークセットアップの使用例に沿って、LDP DoDラベル要求ポリシーを使用した/ 32スタティックルートで構成されています。
b. An access LSR/ABR is configured with a service in line with service use cases described in Sections 3.2 and 3.3.
b. アクセスLSR / ABRは、セクション3.2および3.3で説明されているサービスの使用例に沿ったサービスで構成されます。
c. Configuration with access static routes: An access LSR/ABR link to an adjacent node comes up, and an LDP DoD session is established. In this case, the access LSR sends Label Request messages for all /32 static routes configured with an LDP DoD policy and all /32 routes related to provisioned services that are covered by the default route.
c. アクセススタティックルートの設定：隣接ノードへのアクセスLSR / ABRリンクがアップし、LDP DoDセッションが確立されます。この場合、アクセスLSRは、LDP DoDポリシーで構成されたすべての/ 32静的ルートと、デフォルトルートでカバーされるプロビジョニングされたサービスに関連するすべての/ 32ルートにラベル要求メッセージを送信します。
d. Configuration with access IGP: An access LSR/ABR link to an adjacent node comes up, and an LDP DoD session is established. In this case, the access LSR sends Label Request messages for all /32 routes learned over the access IGP and all /32 routes related to provisioned services that are covered by access IGP routes.
d. アクセスIGPの構成：隣接ノードへのアクセスLSR / ABRリンクが起動し、LDP DoDセッションが確立されます。この場合、アクセスLSRは、アクセスIGPを介して学習されたすべての/ 32ルートと、アクセスIGPルートによってカバーされるプロビジョニングされたサービスに関連するすべての/ 32ルートのラベル要求メッセージを送信します。
e. In all above cases, requests are sent to any next-hop LSRs and alternate LSRs.
e. 上記のすべてのケースで、要求はネクストホップLSRおよび代替LSRに送信されます。
The downstream access LSR/ABR will respond with a Label Mapping message with a non-null label if any of the below conditions are met:
ダウンストリームアクセスLSR / ABRは、以下の条件のいずれかが満たされた場合に、null以外のラベルが付いたラベルマッピングメッセージで応答します。
a. Downstream access LSR/ABR: The requested FEC is an IGP or static route, and there is an LDP label already learned from the next-next-hop downstream LSR (by LDP DoD or LDP DU). If there is no label for the requested FEC and there is an LDP DoD session to the next-next-hop downstream LSR, the downstream LSR sends a Label Request message for the same FEC to the next-next-hop downstream LSR. In such a case, the downstream LSR will respond back to the requesting upstream access LSR only after getting a label from the next-next-hop downstream LSR peer.
a. ダウンストリームアクセスLSR / ABR：要求されたFECはIGPまたは静的ルートであり、次のネクストホップダウンストリームLSRから（LDP DoDまたはLDP DUによって）学習済みのLDPラベルがあります。要求されたFECのラベルがなく、ネクストネクストホップのダウンストリームLSRへのLDP DoDセッションがある場合、ダウンストリームLSRは同じFECのラベル要求メッセージをネクストネクストホップのダウンストリームLSRに送信します。このような場合、ダウンストリームLSRは、次のネクストホップのダウンストリームLSRピアからラベルを取得した後にのみ、要求元のアップストリームアクセスLSRに応答します。
b. Downstream access ABR only: The requested FEC is a BGP labeled IP routes [RFC3107], and this BGP route is the best selected for this FEC.
b. ダウンストリームアクセスABRのみ：要求されたFECはBGPラベル付きIPルート[RFC3107]であり、このBGPルートはこのFECに最適なルートです。
The downstream access LSR/ABR can respond with a label mapping with an explicit-null or implicit-null label if it is acting as an egress for the requested FEC, or it can respond with a "No Route" notification if no route exists.
ダウンストリームアクセスLSR / ABRは、要求されたFECの出力として機能している場合は、明示的ヌルまたは暗黙的ヌルラベルのラベルマッピングで応答できます。ルートが存在しない場合は、「ルートなし」通知で応答できます。
Following the LDP specification [RFC5036], if an access LSR/ABR receives a "No Route" notification in response to its Label Request message, it retries using an exponential backoff algorithm similar to the backoff algorithm mentioned in the LDP session negotiation described in Section 4.2.
LDP仕様[RFC5036]に従って、アクセスLSR / ABRがラベル要求メッセージに応答して「ルートなし」通知を受信した場合、セクションで説明されているLDPセッションネゴシエーションで言及されているバックオフアルゴリズムと同様の指数バックオフアルゴリズムを使用して再試行します。 4.2。
If there is no response to the Label Request message sent, the LDP specification [RFC5036] (Section A.1.1) states that the LSR does not send another request for the same label to the peer and mandates that a duplicate Label Request be considered a protocol error and be dropped by the receiving LSR by sending a Notification message.
送信されたラベル要求メッセージへの応答がない場合、LDP仕様[RFC5036]（セクションA.1.1）は、LSRが同じラベルに対する別の要求をピアに送信せず、重複するラベル要求は、プロトコルエラーが発生し、通知メッセージを送信することにより、受信側のLSRによってドロップされます。
Thus, if there is no response from the downstream peer, the access LSR/ABR does not send a duplicate Label Request message.
したがって、ダウンストリームピアからの応答がない場合、アクセスLSR / ABRは重複したラベル要求メッセージを送信しません。
If the static route corresponding to the FEC gets deleted or if the DoD request policy is modified to reject the FEC before receiving the Label Mapping message, then the access LSR/ABR sends a Label Abort message to the downstream LSR.
FECに対応するスタティックルートが削除されるか、DoD要求ポリシーがラベルマッピングメッセージを受信する前にFECを拒否するように変更された場合、アクセスLSR / ABRはラベル中止メッセージをダウンストリームLSRに送信します。
To address the case of slower convergence resulting from described LDP behavior in line with the LDP specification [RFC5036], a new LDP TLV extension is proposed and described in Section 5.
LDP仕様[RFC5036]に沿って記述されたLDP動作から生じるより遅い収束のケースに対処するために、新しいLDP TLV拡張が提案され、セクション5で説明されています。
If an MPLS label on the downstream access LSR/ABR is no longer valid, the downstream access LSR/ABR withdraws this FEC/label binding from the upstream access LSR/ABR with the Label Withdraw message [RFC5036] with a specified label TLV or with an empty label TLV.
ダウンストリームアクセスLSR / ABRのMPLSラベルが有効ではなくなった場合、ダウンストリームアクセスLSR / ABRは、指定されたラベルTLVまたはラベルウィズドロウメッセージ[RFC5036]を使用して、このFEC /ラベルバインディングをアップストリームアクセスLSR / ABRから撤回します。空のラベルTLV。
The downstream access LSR/ABR withdraws a label for a specific FEC in the following cases:
ダウンストリームアクセスLSR / ABRは、次の場合に特定のFECのラベルを取り消します。
a. If an LDP DoD ingress label is associated with an outgoing label assigned by a labeled BGP route and this route is withdrawn.
a. LDP DoD入力ラベルがラベル付きBGPルートによって割り当てられた発信ラベルに関連付けられている場合、このルートは取り消されます。
b. If an LDP DoD ingress label is associated with an outgoing label assigned by LDP (DoD or DU), and the IGP route is withdrawn from the RIB or the downstream LDP session is lost.
b. LDP DoD入力ラベルがLDP（DoDまたはDU）によって割り当てられた発信ラベルに関連付けられている場合、IGPルートがRIBから取り消されるか、ダウンストリームLDPセッションが失われます。
c. If an LDP DoD ingress label is associated with an outgoing label assigned by LDP (DoD or DU) and the outgoing label is withdrawn by the downstream LSR.
c. LDP DoD入力ラベルがLDP（DoDまたはDU）によって割り当てられた発信ラベルに関連付けられ、発信ラベルがダウンストリームLSRによって取り消された場合。
d. If an LDP DoD ingress label is associated with an outgoing label assigned by LDP (DoD or DU), the next hop in the route has changed, and
d. LDP DoD入力ラベルがLDP（DoDまたはDU）によって割り当てられた発信ラベルに関連付けられている場合、ルートのネクストホップが変更され、
* there is no LDP session to the new next hop. To minimize the probability of this, the access LSR/ABR implements LDP-IGP synchronization procedures as specified in [RFC5443].
* 新しいネクストホップへのLDPセッションはありません。これの確率を最小にするために、アクセスLSR / ABRは[RFC5443]で指定されるようにLDP-IGP同期手順を実装します。
* there is an LDP session but no label from a downstream LSR. See note below.
* LDPセッションはありますが、ダウンストリームLSRからのラベルはありません。以下の注を参照してください。
e. If an access LSR/ABR is configured with a policy to reject exporting label mappings to an upstream LSR.
e. アクセスLSR / ABRに、上流LSRへのラベルマッピングのエクスポートを拒否するポリシーが構成されている場合。
The upstream access LSR/ABR responds to the Label Withdraw message with the Label Release message [RFC5036].
アップストリームアクセスLSR / ABRは、Label WithdrawメッセージにLabel Releaseメッセージ[RFC5036]で応答します。
After sending the Label Release message to the downstream access LSR/ABR, the upstream access LSR/ABR resends the Label Request message, assuming the upstream access LSR/ABR still requires the label.
ラベル解放メッセージをダウンストリームアクセスLSR / ABRに送信した後、アップストリームアクセスLSR / ABRがまだラベルを必要とすると、アップストリームアクセスLSR / ABRはラベル要求メッセージを再送信します。
The downstream access LSR/ABR withdraws a label if the local route configuration (e.g., /32 loopback) is deleted.
ローカルルート構成（/ 32ループバックなど）が削除されると、ダウンストリームアクセスLSR / ABRはラベルを取り消します。
Note: For any events inducing next-hop change, a downstream access LSR/ABR attempts to converge the LSP locally before withdrawing the label from an upstream access LSR/ABR. For example, if the next hop changes for a particular FEC and if the new next hop allocates labels by the LDP DoD session, then the downstream access LSR/ABR sends a Label Request on the new next-hop session. If the downstream access LSR/ABR doesn't get a label mapping for some duration, then and only then does the downstream access LSR/ABR withdraw the upstream label.
注：ネクストホップの変更を引き起こすイベントの場合、ダウンストリームアクセスLSR / ABRは、アップストリームアクセスLSR / ABRからラベルを撤回する前に、LSPをローカルに収束しようとします。たとえば、特定のFECのネクストホップが変更され、新しいネクストホップがLDP DoDセッションによってラベルを割り当てる場合、ダウンストリームアクセスLSR / ABRは新しいネクストホップセッションでラベル要求を送信します。ダウンストリームアクセスLSR / ABRが一定期間ラベルマッピングを取得しない場合、ダウンストリームアクセスLSR / ABRはアップストリームラベルを取り消すだけです。
If an access LSR/ABR no longer needs a label for a FEC, it sends a Label Release message [RFC5036] to the downstream access LSR/ABR with or without the label TLV.
アクセスLSR / ABRがFECのラベルを必要としなくなった場合、ラベルTLVの有無にかかわらず、ラベル解放メッセージ[RFC5036]をダウンストリームアクセスLSR / ABRに送信します。
If an upstream access LSR/ABR receives an unsolicited label mapping on a DoD session, it releases the label by sending a Label Release message.
アップストリームアクセスLSR / ABRがDoDセッションで非送信請求ラベルマッピングを受信すると、Label Releaseメッセージを送信してラベルを解放します。
The access LSR/ABR sends a Label Release message to the downstream LSR in the following cases:
次の場合、アクセスLSR / ABRはラベル解放メッセージをダウンストリームLSRに送信します。
a. If it receives a Label Withdraw from the downstream access LSR/ABR.
a. ダウンストリームアクセスLSR / ABRからラベル撤回を受信した場合。
b. If the /32 static route with LDP DoD Label Request policy is deleted.
b. LDP DoDラベル要求ポリシーを使用した/ 32スタティックルートが削除された場合。
c. If the service gets decommissioned and there is no corresponding /32 static route with LDP DoD Label Request policy configured.
c. サービスが廃止され、LDP DoDラベル要求ポリシーが設定された対応する/ 32スタティックルートがない場合。
d. If the next hop in the route has changed and the label does not point to the best or alternate next hop.
d. ルートのネクストホップが変更され、ラベルが最良または代替ネクストホップを指していない場合。
e. If it receives a Label Withdraw from a downstream DoD session.
e. ダウンストリームDoDセッションからLabel Withdrawを受信した場合。
To support local-repair with ECMP and IPFRR LFA, the access LSR/ABR requests labels on both the best next-hop and the alternate next-hop LDP DoD sessions, as specified in the Label Request procedures in Section 4.3. If remote LFA is enabled, the access LSR/ABR needs a label from its alternate next hop toward the PQ node and needs a label from the remote PQ node toward its FEC/destination [RLFA]. If the access LSR/ABR doesn't already know those labels, it requests them.
ECMPおよびIPFRR LFAでのローカル修復をサポートするために、アクセスLSR / ABRは、セクション4.3のラベル要求手順で指定されているように、最良のネクストホップと代替のネクストホップLDP DoDセッションの両方でラベルを要求します。リモートLFAが有効になっている場合、アクセスLSR / ABRには、代替ネクストホップからPQノードに向かうラベルが必要であり、リモートPQノードからそのFEC /宛先[RLFA]に向かうラベルが必要です。アクセスLSR / ABRがこれらのラベルをまだ認識していない場合は、ラベルを要求します。
This will enable the access LSR/ABR to pre-program the alternate forwarding path with the alternate label(s) and invoke the IPFRR LFA switchover procedure if the primary next-hop link fails.
これにより、アクセスLSR / ABRは、代替ラベルを使用して代替転送パスを事前にプログラムし、プライマリネクストホップリンクに障害が発生した場合にIPFRR LFAスイッチオーバー手順を呼び出すことができます。
In some conditions, the exponential backoff algorithm usage described in Section 4.3.2 can result in a wait time that is longer than desired to get a successful LDP label-to-route mapping. An example is when a specific route is unavailable on the downstream LSR when the label mapping request from the upstream is received, but later comes back. In such a case, using the exponential backoff algorithm can result in a max delay wait time before the upstream LSR sends another LDP Label Request.
一部の条件では、セクション4.3.2で説明されている指数バックオフアルゴリズムの使用により、LDPラベルからルートへのマッピングを正常に行うために必要な待機時間が長くなる場合があります。例としては、アップストリームからのラベルマッピング要求を受信したときに、ダウンストリームLSRで特定のルートが使用できないが、後で戻ってきた場合があります。このような場合、指数バックオフアルゴリズムを使用すると、アップストリームLSRが別のLDPラベルリクエストを送信する前に最大遅延待機時間が発生する可能性があります。
This section describes an extension to the LDP DoD procedure to address fast-up convergence, and as such is to be treated as a normative reference. The downstream and upstream LSRs SHOULD implement this extension if fast-up convergence is desired.
このセクションでは、高速アップコンバージェンスに対処するためのLDP DoDプロシージャの拡張について説明します。そのため、これは規範的な参照として扱われます。高速アップコンバージェンスが必要な場合、ダウンストリームおよびアップストリームLSRはこの拡張を実装する必要があります（SHOULD）。
The extension consists of the upstream LSR indicating to the downstream LSR that the Label Request SHOULD be queued on the downstream LSR until the requested route is available.
拡張は、要求されたルートが利用可能になるまで、ダウンストリームLSRでラベル要求をキューに入れる必要があることをダウンストリームLSRに示すアップストリームLSRで構成されます。
To implement this behavior, a new Optional Parameter is defined for use in the Label Request message:
この動作を実装するために、ラベルオプションメッセージで使用する新しいオプションパラメータが定義されています。
Optional Parameter Length Value Queue Request TLV 0 see below
オプションのパラメーター長さ値キュー要求TLV 0以下を参照
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|0| Queue Request (0x0971) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit = 1 Unknown TLV bit. Upon receipt of an unknown TLV, due to the U-bit being set (=1), the unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. In case the requested route is not available, the downstream LSR MUST ignore this unknown TLV and send a "No Route" notification back. This ensures backward compatibility.
Uビット= 1不明なTLVビット。不明なTLVを受信すると、Uビットが設定されている（= 1）ため、不明なTLVは暗黙的に無視され、残りのメッセージは不明なTLVが存在しないかのように処理される必要があります。要求されたルートが利用できない場合、ダウンストリームLSRはこの未知のTLVを無視し、「ルートなし」通知を送り返さなければなりません（MUST）。これにより、下位互換性が保証されます。
F-bit = 0 Forward unknown TLV bit. This bit applies only when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. Due to the F-bit being clear (=0), the unknown TLV is not forwarded with the message.
Fビット= 0不明なTLVビットを転送します。このビットは、Uビットが設定されていて、不明なTLVを含むLDPメッセージが転送される場合にのみ適用されます。 Fビットがクリア（= 0）であるため、不明なTLVはメッセージとともに転送されません。
Type = 0x0971 Queue Request TLV (allocated by IANA).
タイプ= 0x0971キュー要求TLV（IANAによって割り当てられます）。
Length = 0x00 Specifies the length of the Value field in octets.
長さ= 0x00値フィールドの長さをオクテットで指定します。
The specified operation is as follows.
指定された操作は次のとおりです。
To benefit from the fast-up convergence improvement, the upstream LSR sends a Label Request message with a Queue Request TLV.
高速化されたコンバージェンスの改善の恩恵を受けるために、アップストリームLSRはキュー要求TLVとともにラベル要求メッセージを送信します。
If the downstream LSR supports the Queue Request TLV, it verifies if a route is available; if so, it replies with a label mapping as per existing LDP procedures. If the route is not available, the downstream LSR queues the request and replies as soon as the route becomes available. In the meantime, it does not send a "No Route" notification back. When sending a Label Request with the Queue Request TLV, the upstream LSR does not retry the Label Request message if it does not receive a reply from its downstream peer.
ダウンストリームLSRがキュー要求TLVをサポートしている場合、ルートが使用可能かどうかを確認します。存在する場合は、既存のLDP手順に従ってラベルマッピングで応答します。ルートが利用できない場合、ダウンストリームLSRは要求をキューに入れ、ルートが利用可能になるとすぐに応答します。その間、「ルートなし」通知は送り返されません。キュー要求TLVでラベル要求を送信するとき、ダウンストリームピアから応答を受信しない場合、アップストリームLSRはラベル要求メッセージを再試行しません。
If the upstream LSR wants to abort an outstanding Label Request while the Label Request is queued in the downstream LSR, the upstream LSR sends a Label Abort Request message, making the downstream LSR remove the original request from the queue and send back a Label Request Aborted notification [RFC5036].
ラベル要求がダウンストリームLSRにキューイングされているときに、上流LSRが未処理のラベル要求を中止したい場合、上流LSRはラベル中止要求メッセージを送信し、ダウンストリームLSRが元の要求をキューから削除して、ラベル要求中止を送り返します通知[RFC5036]。
If the downstream LSR does not support the Queue Request TLV, and the requested route is not available, it ignores this unknown TLV and sends a "No Route" notification back, in line with [RFC5036]. In this case, the upstream LSR invokes the exponential backoff algorithm described in Section 4.3.2, following the LDP specification [RFC5036].
ダウンストリームLSRがキュー要求TLVをサポートせず、要求されたルートが利用できない場合、この不明なTLVを無視し、[RFC5036]に沿って「ルートなし」通知を送り返します。この場合、アップストリームLSRは、LDP仕様[RFC5036]に従って、セクション4.3.2で説明されている指数バックオフアルゴリズムを呼び出します。
This procedure ensures backward compatibility.
この手順により、下位互換性が保証されます。
This document uses a new Optional Parameter, Queue Request TLV, in the Label Request message defined in Section 5. IANA already maintains a registry of LDP parameters called the "TLV Type Name Space" registry, as defined by RFC 5036. The following assignment has been made:
このドキュメントでは、セクション5で定義されたラベルリクエストメッセージで新しいオプションパラメータキューリクエストTLVを使用します。IANAは、RFC 5036で定義されている「TLV Type Name Space」レジストリと呼ばれるLDPパラメータのレジストリをすでに維持しています。次の割り当てでは、作られた：
TLV type Description 0x0971 Queue Request TLV
TLVタイプ説明0x0971キュー要求TLV
MPLS LDP DoD deployment in the access network is subject to the same security threats as any MPLS LDP deployment. It is recommended that baseline security measures be considered, as described in "Security Framework for MPLS and GMPLS Networks" [RFC5920] and the LDP specification [RFC5036] including ensuring authenticity and integrity of LDP messages, as well as protection against spoofing and denial-of-service attacks.
アクセスネットワークでのMPLS LDP DoD展開は、他のMPLS LDP展開と同じセキュリティ上の脅威の影響を受けます。 「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]およびLDP仕様[RFC5036]で説明されているように、LDPメッセージの信頼性と整合性、およびなりすましと拒否からの保護を含む、ベースラインのセキュリティ対策を検討することをお勧めします。サービス攻撃。
Some deployments require increased measures of network security if a subset of access nodes are placed in locations with lower levels of physical security, e.g., street cabinets (common practice for Very high bit-rate Digital Subscriber Line (VDSL) access). In such cases, it is the responsibility of the system designer to take into account the physical security measures (environmental design, mechanical or electronic access control, intrusion detection) as well as monitoring and auditing measures (configuration and Operating System changes, reloads, route advertisements).
一部の展開では、アクセスノードのサブセットがストリートキャビネットなどの物理的なセキュリティレベルの低い場所に配置されている場合、ネットワークセキュリティの測定を強化する必要があります（非常に高いビットレートのデジタル加入者線（VDSL）アクセスの一般的な方法）。このような場合、物理的なセキュリティ対策（環境設計、機械的または電子的アクセス制御、侵入検知）と監視および監査対策（構成とオペレーティングシステムの変更、リロード、ルーティング）を考慮するのはシステム設計者の責任です広告）。
But even with all this in mind, the designer still needs to consider network security risks and adequate measures arising from the lower level of physical security of those locations.
しかし、これらすべてを念頭に置いても、設計者は、ネットワークセキュリティのリスクと、それらの場所の物理的なセキュリティレベルの低さから生じる適切な対策を考慮する必要があります。
MPLS LDP DoD operation is request driven, and unsolicited label mappings are not accepted by upstream LSRs by design. This inherently limits the potential of an unauthorized third party injecting unsolicited label mappings on the wire.
MPLS LDP DoD操作は要求駆動型であり、非送信請求ラベルマッピングは上流のLSRによって設計上受け入れられません。これにより、権限のない第三者が未承諾のラベルマッピングをワイヤに挿入する可能性が本質的に制限されます。
This native security property enables an ABR LSR to act as a gateway to the MPLS network and to control the requests coming from any access LSR and prevent cases when the access LSR attempts to get access to an unauthorized FEC or remote LSR after being compromised.
このネイティブセキュリティプロパティにより、ABR LSRはMPLSネットワークへのゲートウェイとして機能し、アクセスLSRからのリクエストを制御し、アクセスLSRが不正使用されたFECまたはリモートLSRにアクセスしようとするケースを防止できます。
In the event that an access LSR gets compromised and manages to advertise a FEC belonging to another LSR (e.g., in order to 'steal' third-party data flows, or breach the privacy of a VPN), such an access LSR would also have to influence the routing decision for affected FECs on the ABR LSR to attract the flows. The following measures need to be considered on an ABR LSR to prevent such an event from occurring:
アクセスLSRが危険にさらされ、別のLSRに属するFECをアドバタイズする場合（たとえば、サードパーティのデータフローを「盗む」、またはVPNのプライバシーを侵害するため）、そのようなアクセスLSRはフローを引き付けるために、ABR LSR上の影響を受けるFECのルーティング決定に影響を与えるため。このようなイベントの発生を防ぐには、ABR LSRで次の対策を検討する必要があります。
a. Access with static routes: An access LSR cannot influence ABR LSR routing decisions due to the static nature of routing configuration, a native property of the design.
a. 静的ルートによるアクセス：デザインのネイティブプロパティであるルーティング構成の静的な性質により、アクセスLSRはABR LSRルーティングの決定に影響を与えることができません。
b. Access with IGP - access FEC "stealing": If the compromised access LSR is a leaf in the access topology (leaf node in topologies I1, I, V, Y described earlier), this will not have any adverse effect, due to the leaf IGP metrics being configured on the ABR LSR. If the compromised access LSR is a transit LSR in the access topology (transit node in topologies I, Y, U), it is only possible for this access LSR to attract traffic destined to the nodes upstream from it. Such a 'man-in-the-middle attack' can quickly be detected by upstream access LSRs not receiving traffic and by the LDP TCP session being lost.
b. IGPを使用したアクセス-アクセスFECの「盗用」：侵害されたアクセスLSRがアクセストポロジーのリーフ（前述のトポロジーI1、I、V、Yのリーフノード）である場合、リーフのために悪影響はありません。 ABR LSRで構成されているIGPメトリック。侵害されたアクセスLSRがアクセストポロジーのトランジットLSR（トポロジーI、Y、Uのトランジットノード）である場合、このアクセスLSRは、その上流のノード宛てのトラフィックを引き付けることができるだけです。このような「中間者攻撃」は、トラフィックを受信しないアップストリームアクセスLSRによって、およびLDP TCPセッションが失われることによって、すばやく検出できます。
c. Access with IGP - network FEC "stealing": The compromised access LSR can use IGP to advertise a "stolen" FEC prefix belonging to the network side. This case can be prevented by giving a better administrative preference to the BGP labeled IP routes versus access IGP routes.
c. IGPによるアクセス-ネットワークFECの「盗用」：侵害されたアクセスLSRは、IGPを使用して、ネットワーク側に属する「盗まれた」FECプレフィックスをアドバタイズできます。このケースは、IGPルートへのアクセスよりも、BGPラベル付きのIPルートの管理を優先することで防ぐことができます。
In summary, the native properties of MPLS in access design with LDP DoD prevent a number of security attacks and make their detection quick and straightforward.
要約すると、LDP DoDを使用したアクセス設計におけるMPLSのネイティブプロパティは、多数のセキュリティ攻撃を防止し、それらの検出を迅速かつ簡単にします。
The following two sections describe other security considerations applicable to general MPLS deployments in the access network.
次の2つのセクションでは、アクセスネットワークでの一般的なMPLS展開に適用可能なその他のセキュリティの考慮事項について説明します。
Data-plane security risks applicable to the access MPLS network include:
アクセスMPLSネットワークに該当するデータプレーンのセキュリティリスクには、次のものがあります。
a. Labeled packets from a specific access LSR that are sent to an unauthorized destination.
a. 不正な宛先に送信される、特定のアクセスLSRからのラベル付きパケット。
b. Unlabeled packets that are sent by an access LSR to remote network nodes.
b. アクセスLSRによってリモートネットワークノードに送信されるラベルなしパケット。
The following mechanisms apply to MPLS access design with LDP DoD that address listed data-plane security risks:
次のメカニズムは、リストされているデータプレーンセキュリティリスクに対処するLDP DoDを使用したMPLSアクセス設計に適用されます。
1. addressing (a): Access and ABR LSRs do not accept labeled packets over a particular data link, unless from the access or ABR LSR perspective this data link is known to attach to a trusted system based on control-plane security as described in Section 7.3 and the top label has been distributed to the upstream neighbor by the receiving access or ABR LSR.
1. アドレッシング（a）：アクセスおよびABR LSRは、アクセスまたはABR LSRの観点から、このデータリンクがセクション7.3で説明されているコントロールプレーンセキュリティに基づいて信頼できるシステムに接続されていることがわかっている場合を除き、特定のデータリンク上のラベル付きパケットを受け入れません。トップラベルは、受信アクセスまたはABR LSRによってアップストリームネイバーに配布されています。
2. addressing (a) - The ABR LSR restricts network reachability for access devices to a subset of remote network LSRs, based on control-plane security as described in Section 7.3, FEC filters, and routing policy.
2. アドレッシング（a）-ABR LSRは、セクション7.3、FECフィルター、およびルーティングポリシーで説明されているコントロールプレーンセキュリティに基づいて、アクセスデバイスのネットワーク到達可能性をリモートネットワークLSRのサブセットに制限します。
3. addressing (a): Control-plane authentication as described in Section 7.3 is used.
3. アドレッシング（a）：セクション7.3で説明されているコントロールプレーン認証が使用されます。
4. addressing (b): The ABR LSR restricts IP network reachability to and from the access LSR.
4. アドレッシング（b）：ABR LSRは、アクセスLSRとの間のIPネットワーク到達可能性を制限します。
Similar to Inter-AS MPLS/VPN deployments [RFC4364], control-plane security is a prerequisite for data-plane security.
AS間MPLS / VPN配置[RFC4364]と同様に、コントロールプレーンセキュリティは、データプレーンセキュリティの前提条件です。
To ensure control-plane security access, LDP DoD sessions are established only with LDP peers that are considered trusted from the local LSR perspective, meaning they are reachable over a data link that is known to attach to a trusted system based on employed authentication mechanism(s) on the local LSR.
コントロールプレーンのセキュリティアクセスを確保するために、LDP DoDセッションは、ローカルLSRの観点から信頼されていると見なされるLDPピアでのみ確立されます。つまり、採用されている認証メカニズムに基づいて、信頼できるシステムに接続されていることがわかっているデータリンクを介して到達可能です（ s）ローカルLSR。
The security of LDP sessions is analyzed in the LDP specification [RFC5036] and in [RFC6952] ("Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide"). Both documents state that LDP is subject to two different types of attacks: spoofing and denial-of-service attacks.
LDPセッションのセキュリティは、LDP仕様[RFC5036]と[RFC6952]で分析されています（「ルーティングプロトコルのキーイングと認証（KARP）設計ガイドによるBGP、LDP、PCEP、MSDPの問題の分析」）。どちらの文書にも、LDPは2つの異なるタイプの攻撃、つまり、なりすまし攻撃とサービス拒否攻撃の影響を受けることが記載されています。
The threat of spoofed LDP Hello messages can be reduced by following guidelines listed in the LDP specification [RFC5036]: accepting Basic Hellos only on interfaces connected to trusted LSRs, ignoring Basic Hellos that are not addressed to all routers in this subnet multicast group, and using access lists. LDP Hello messages can also be secured using an optional Cryptographic Authentication TLV as specified in "LDP Hello Cryptographic Authentication" [CRYPTO-AUTH] that further reduces the threat of spoofing during the LDP discovery phase.
スプーフィングされたLDP Helloメッセージの脅威は、LDP仕様[RFC5036]に記載されているガイドラインに従うことで軽減できます。信頼できるLSRに接続されたインターフェースでのみBasic Helloを受け入れ、このサブネットマルチキャストグループ内のすべてのルーターにアドレス指定されていないBasic Helloを無視します。アクセスリストを使用する。 LDP Helloメッセージは、「LDP Hello暗号認証」[CRYPTO-AUTH]で指定されているオプションの暗号認証TLVを使用して保護することもできます。これにより、LDPディスカバリフェーズ中のなりすましの脅威がさらに軽減されます。
Spoofing during the LDP session communication phase can be prevented by using the TCP Authentication Option (TCP-AO) [RFC5925], which uses a stronger hashing algorithm, e.g., SHA1 as compared to the traditionally used MD5 authentication. TCP-AO is recommended as being more secure as compared to the TCP/IP MD5 authentication option [RFC5925].
LDPセッション通信フェーズ中のなりすましは、TCP認証オプション（TCP-AO）[RFC5925]を使用することで防止できます。これは、従来から使用されているMD5認証と比較して、SHA1などの強力なハッシュアルゴリズムを使用します。 TCP-AOは、TCP / IP MD5認証オプション[RFC5925]と比較してより安全であるため推奨されています。
The threat of a denial-of-service attack targeting a well-known UDP port for LDP discovery or a TCP port for LDP session establishment can be reduced by following the guidelines listed in [RFC5036] and in [RFC6952].
[RFC5036]と[RFC6952]に記載されているガイドラインに従うことにより、LDPディスカバリ用の既知のUDPポートまたはLDPセッション確立用のTCPポートをターゲットとするサービス拒否攻撃の脅威を軽減できます。
Access IGP (if used) and any routing protocols used in the access network for signaling service routes also need to be secured following best practices in routing protocol security. Refer to the KARP IS-IS security analysis document [KARP-ISIS] and to [RFC6863] ("Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide") for further analysis of security properties of IS-IS and OSPF IGP routing protocols.
ルーティングプロトコルセキュリティのベストプラクティスに従って、アクセスIGP（使用されている場合）およびシグナリングサービスルートのアクセスネットワークで使用されるルーティングプロトコルも保護する必要があります。 ISのセキュリティプロパティの詳細な分析については、KARP IS-ISセキュリティ分析ドキュメント[KARP-ISIS]および[RFC6863]（「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるOSPFセキュリティの分析」）を参照してください。 -ISおよびOSPF IGPルーティングプロトコル。
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray, and Lizhong Jin for their suggestions and review. Additional thanks go to Adrian Farrel for thorough pre-publication review, and to Stephen Kent for review and guidance specifically for the security section.
著者は、彼らの提案とレビューをしてくれたNischal Sheth、Nitin Bahadur、Nicolai Leymann、George Swallow、Geraldine Calvignac、Ina Minei、Eric Gray、Lizhong Jinに感謝します。公開前の徹底的なレビューについてはAdrian Farrelに、特にセキュリティセクションに関するレビューとガイダンスについてはStephen Kentに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「Pseudowire Setup and Maintenance Using a Label Distribution Protocol（LDP）」、RFC 4447、2006年4月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008.
[RFC5283] Decraene、B.、Le Roux、JL。、およびI. Minei、「LDP Extension for Inter-Area Label Switched Paths（LSPs）」、RFC 5283、2008年7月。
[CRYPTO-AUTH] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, August 2013.
[CRYPTO-AUTH] Zheng、L.、Chen、M、M。Bhatia、「LDP Hello Cryptographic Authentication」、Work in Progress、2013年8月。
[KARP-ISIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", Work in Progress, March 2013.
[KARP-ISIS] Chunduri、U.、Tian、A。、およびW. Lu、「KARP IS-ISセキュリティ分析」、Work in Progress、2013年3月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y。およびE. Rosen、「Carrying Label Information in BGP-4」、RFC 3107、2001年5月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286] Atlas、A。およびA. Zinin、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、2008年9月。
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[RFC5443] Jork、M.、Atlas、A。、およびL. Fang、「LDP IGP Synchronization」、RFC 5443、2009年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6863] Hartman、S。、およびD. Zhang、「Analysis of OSPF Security Using the Keying and Authentication for Routing Protocols（KARP）Design Guide」、RFC 6863、2013年3月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの分析によるルーティングプロトコルのキーイングおよび認証（KARP）設計ガイド」、RFC 6952、5月2013。
[RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote LFA FRR", Work in Progress, May 2013.
[RLFA]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートLFA FRR」、作業中、2013年5月。
[SEAMLESS-MPLS] Leymann, N., Ed., Decraene, B., Filsfils, C., Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, July 2013.
[シームレス-MPLS]レイマンN.、編、デクラーン、B。、フィルスフィルス、C。、コンスタンティノヴィッチ、編、D。スタインバーグ、「シームレスMPLSアーキテクチャ」、作業中、2013年7月。
Authors' Addresses
著者のアドレス
Thomas Beckhaus (editor) Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
Thomas Beckhaus（編集者）Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7ダルムシュタット64307ドイツ
Phone: +49 6151 58 12825
EMail: thomas.beckhaus@telekom.de
Bruno Decraene Orange 38-40 rue du General Leclerc Issy Moulineaux cedex 9 92794 France
Bruno Decraene Orange 38-40 rue du General Leclerc Issy Moulineaux cedex 9 92794 France
EMail: bruno.decraene@orange.com
Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford, Massachusetts 01886 USA
Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford、Massachusetts 01886 USA
Phone: 1-(978)-589-8861
EMail: kishoret@juniper.net
Maciek Konstantynowicz (editor) Cisco Systems, Inc. 10 New Square Park, Bedfont Lakes London United Kingdom
Maciek Konstantynowicz（editor）Cisco Systems、Inc. 10 New Square Park、Bedfont Lakes London United Kingdom
EMail: maciek@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 USA
Luca Martini Cisco Systems、Inc. 9155 East Nichols Avenue、Suite 400 Englewood、CO 80112 USA
EMail: lmartini@cisco.com