[要約] 要約：RFC 7625は、IP/MPLSネットワークのアーキテクチャにおけるハードニングパイプの実装に関するガイドラインを提供しています。目的：このRFCの目的は、ネットワークのセキュリティを向上させるために、ハードニングパイプの使用方法と実装の詳細を説明することです。
Independent Submission J. T. Hao
Request for Comments: 7625 Huawei Technologies Co., Ltd
Category: Informational P. Maheshwari
ISSN: 2070-1721 Bharti Airtel, Ltd.
R. Huang
L. Andersson
M. Chen
Huawei Technologies Co., Ltd
August 2015
Architecture of an IP/MPLS Network with Hardened Pipes
強化されたパイプを使用したIP / MPLSネットワークのアーキテクチャ
Abstract
概要
This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the "Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".
このドキュメントでは、2つ以上の階層に分離できるインフラストラクチャを備えたIP / MPLSネットワークについて説明します。このドキュメントで説明されている実装では、インフラストラクチャは2つの層に分かれています。1つは「ハードパイプ」と呼ばれる「ハードパイプストラタム」用、もう1つは「通常のIP / MPLS」と呼ばれる通常のIP / MPLSトラフィック用です。層」。
This document introduces the concept of a Hard Pipe -- an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.
このドキュメントでは、ハードパイプの概念を紹介します。MPLSラベルスイッチドパス（LSP）または疑似配線（PW）は、帯域幅が保証されており、超過も侵害もできない帯域幅を備えています。
The Hard Pipe stratum does not use statistical multiplexing; for the LSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.
ハードパイプ層は統計的多重化を使用しません。このストラタム内に設定されたLSPおよびPWの場合、帯域幅はエンドツーエンドで保証されます。
The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.
このドキュメントでは、新しいプロトコルや手順は指定されていません。従来の仮想専用線（VLL）サービスを提供する事業者からの要件を満たすために、MPLS標準の実装がどのように展開および運用されているかを説明しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7625.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7625で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. The Stratified Network . . . . . . . . . . . . . . . . . . . 5
2.1. The Physical Network . . . . . . . . . . . . . . . . . . 6
2.2. The Hard Pipe Stratum . . . . . . . . . . . . . . . . . . 6
2.3. The Normal IP/MPLS Stratum . . . . . . . . . . . . . . . 7
2.4. Stratum Networks . . . . . . . . . . . . . . . . . . . . 7
3. Configuring the Leased Lines in the Hard Pipe Stratum . . . . 8
4. Efficient State Management . . . . . . . . . . . . . . . . . 9
4.1. State in the Forwarding Plane . . . . . . . . . . . . . . 9
4.2. State in the NMS/Controller . . . . . . . . . . . . . . . 10
4.3. Annotations for Configuring Leased Lines . . . . . . . . 10
5. Setting Up Leased Lines . . . . . . . . . . . . . . . . . . . 12
6. Leased Line Protection . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
IP leased line services, Ethernet Private Line (EPL), and Time-Division Multiplexed (TDM) leased line services are commonly offered by operators worldwide.
IP専用線サービス、イーサネット専用線（EPL）、および時分割多重（TDM）専用線サービスは、世界中のオペレーターによって一般的に提供されています。
There are customers, e.g., many enterprises, that insist on TDM leased line services. They do so regardless of the fact that the same operators often offer IP leased line services and EPL services at a lower price and with a guaranteed bandwidth.
多くの企業など、TDM専用回線サービスを要求する顧客がいます。同じ事業者がIP専用線サービスとEPLサービスを低価格で保証された帯域幅で提供することが多いという事実に関係なく、それらはそうします。
Today we see a trend that TDM (in particular, Synchronous Digital Hierarchy / Synchronous Optical Network (SDH/SONET)) networks are gradually carrying less and less traffic, and many operators want to shut their TDM networks down to reduce costs.
今日、TDM（特に、同期デジタル階層/同期光ネットワーク（SDH / SONET））ネットワークのトラフィックが次第に少なくなり、多くのオペレーターがTDMネットワークをシャットダウンしてコストを削減しようとする傾向にあります。
In light of these trends, vendors and operators have built and deployed the Hard Pipe service described in this document. It is a way to introduce leased line service with the same characteristics as TDM leased line services in IP/MPLS networks.
これらの傾向に照らして、ベンダーとオペレーターは、このドキュメントで説明されているハードパイプサービスを構築して展開しています。これは、IP / MPLSネットワークでTDM専用回線サービスと同じ特性を持つ専用回線サービスを導入する方法です。
Even if leased line has been the initial motivation to define the Hard Pipe technology, the Hard Pipe is by no means limited to support leased line services. When guaranteed bandwidth is the priority, Virtual Private Wire Services (VPWS), Virtual Private LAN Services (VPLS), L3 Virtual Private Networks (L3VPN), and IP-only Private LAN Services can be mapped to a tunnel in the Hard Pipe stratum.
専用線がハードパイプテクノロジを定義する最初の動機であったとしても、ハードパイプは専用線サービスのサポートに限定されることは決してありません。保証された帯域幅が優先される場合、仮想プライベートワイヤーサービス（VPWS）、仮想プライベートLANサービス（VPLS）、L3仮想プライベートネットワーク（L3VPN）、およびIP専用プライベートLANサービスをハードパイプストラタムのトンネルにマップできます。
EPL and Ethernet Private LAN (EPLAN) are out of scope for this document.
EPLおよびイーサネットプライベートLAN（EPLAN）は、このドキュメントの範囲外です。
Virtual Leased Line service is used in examples throughout this document.
このドキュメント全体の例では、仮想専用線サービスが使用されています。
The solution soon to be deployed has an Ethernet infrastructure that has been split into two parallel logical networks -- two parallel strata. The first stratum -- the Hard Pipe Stratum -- does not use statistical multiplexing, and bandwidth is guaranteed end to end. The second stratum -- the Normal IP/MPLS Stratum -- works as a normal IP/MPLS network. The two strata share the same physical network, i.e., routers and links, but the resource reserved for the Hard Pipe stratum will never be preempted by the Normal IP/MPLS stratum.
間もなく展開されるソリューションには、2つの並列論理ネットワーク（2つの並列層）に分割されたイーサネットインフラストラクチャがあります。最初の層-ハードパイプ層-は統計的多重化を使用せず、帯域幅はエンドツーエンドで保証されます。 2番目の層、つまり通常のIP / MPLS層は、通常のIP / MPLSネットワークとして機能します。 2つの層は同じ物理ネットワーク、つまりルーターとリンクを共有しますが、ハードパイプ層用に予約されたリソースが通常のIP / MPLS層によってプリエンプトされることはありません。
The routers will handle the traffic belonging to one stratum differently from how traffic from the other stratum is handled. This separation in traffic handling is based on support in hardware.
ルーターは、1つの層に属するトラフィックを、他の層からのトラフィックとは異なる方法で処理します。トラフィック処理におけるこの分離は、ハードウェアでのサポートに基づいています。
The reader of this document is assumed to be familiar with RFC 3031 [RFC3031] and RFC 5921 [RFC5921].
このドキュメントの読者は、RFC 3031 [RFC3031]およびRFC 5921 [RFC5921]に精通していることを前提としています。
This document has the following purposes:
このドキュメントには次の目的があります。
o to introduce a two strata IP/MPLS network: the purpose of one of the strata is to provide capabilities for services that are, from a customer's point of view, functionally identical to TDM-like leased lines; and
o 2層のIP / MPLSネットワークを導入する：層の1つの目的は、顧客の観点からは、TDMのような専用回線と機能的に同一であるサービスに機能を提供することです。そして
o to indicate how a router differentiates the traffic of the two strata.
o ルータが2つの層のトラフィックをどのように区別するかを示します。
CC: Continuity Check
CC：導通チェック
CV: Connection Verification
CV：接続検証
L-label: Leased Line label
L-ラベル：専用線ラベル
LSP: Label Switched Path LSR: Label Switching Router
LSP：ラベルスイッチドパスLSR：ラベルスイッチングルータ
MPLS-TP: MPLS Transport Profile
MPLS-TP：MPLSトランスポートプロファイル
NMS: Network Management System
NMS：ネットワーク管理システム
OAM: Operations, Administration, and Maintenance
OAM：運用、管理、およびメンテナンス
P: Provider Router
P：プロバイダールーター
PE: Provider Edge Router
PE：プロバイダーエッジルーター
PW: Pseudowire
説明：シュードビル
T-label: Tunnel label
T-label：トンネルラベル
TDM: Time-Division Multiplexing
TDM：時分割多重化
tLDP: Targeted LDP
tLDP：ターゲットLDP
VLL: Virtual Leased Line
VLL：バーチャル専用線
VPLS: Virtual Private LAN Service
VPLS：仮想プライベートLANサービス
VPWS: Virtual Private Wire Service
VPWS：Virtual Private Wire Service
The concept of stratified or strata networks has been around for some time. It appears to have different meaning in different contexts. The way we use the concept is that we logically assign certain characteristics to part of the network. The part of the network that has the special characteristics form one stratum, and the "remainder" forms a second stratum. The network described in this document uses a single link-layer technology, Ethernet.
層別ネットワークまたは層ネットワークの概念は、かなり以前からあります。文脈によって意味が異なるようです。この概念の使用方法は、特定の特性をネットワークの一部に論理的に割り当てることです。特別な特性を持つネットワークの部分が1つの層を形成し、「残り」が2番目の層を形成します。このドキュメントで説明するネットワークは、単一のリンク層テクノロジーであるイーサネットを使用しています。
In many cases, a whole physical interface is assigned to a single hard stratum, especially in the scenario where there are many physical links between two nodes.
多くの場合、特に2つのノード間に多くの物理リンクがあるシナリオでは、物理インターフェイス全体が単一のハードストラタムに割り当てられます。
This document does not address the network configuration possibilities for Hard Pipe and IP/MPLS strata in detail. There are configuration options, the basic configuration is that one Hard Pipe stratum and one IP/MPLS stratum are provisioned.
このドキュメントでは、ハードパイプおよびIP / MPLS層のネットワーク構成の可能性については詳しく説明していません。構成オプションがあり、基本構成は、1つのハードパイプ層と1つのIP / MPLS層がプロビジョニングされることです。
However, it is also possible to provision more than one Hard Pipe stratum, e.g., if customers want enhanced separation for their leased line. Even though the main driver for the Hard Pipe technology is the leased lines, any service for which an operator does not want to use statistical multiplexing will benefit from using the Hard Pipes.
ただし、たとえば、顧客が専用回線の分離を強化したい場合など、複数のハードパイプストラタムをプロビジョニングすることもできます。ハードパイプテクノロジーの主なドライバーは専用回線ですが、オペレーターが統計的多重化を使用したくないサービスであれば、ハードパイプを使用するとメリットがあります。
Consider a network with 10 routers and all the links between are 10G Ethernet, such as shown in Figure 1. This is the network topology we've used for this model and also (with topology variations) in our first deployment.
図1に示すように、ルーターが10台あり、その間のすべてのリンクが10Gイーサネットであるネットワークを考えてみます。これは、このモデルで使用したネットワークトポロジであり、最初の展開でも（トポロジバリエーションあり）使用しています。
+---+ 10G +---+ 10G +---+ 10G +---+
+---| B |-----------| C |-----------| D |----------| E |---+
10G | +---+ +---+ +---+ +---+ | 10G
| | | | | |
+---+ | 10G 10G | 10G | 10G | +---+
--| F | | | | | | G |--
+---+ | | | | +---+
| | | | | |
10G | +---+ +---+ +---+ +---+ | 10G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 10G +---+ 10G +---+ 10G +---+
Figure 1
図1
In this document, we use the terms "traffic matrix" or "estimated traffic matrix" to indicate an estimate of how much traffic will flow between the ingress and egress (PE) nodes. This may be translated into how much bandwidth is needed per link in the Hard Pipe stratum.
このドキュメントでは、「トラフィックマトリックス」または「推定トラフィックマトリックス」という用語を使用して、入口ノードと出口（PE）ノード間で流れるトラフィックの推定量を示します。これは、ハードパイプストラタムのリンクごとに必要な帯域幅に変換できます。
When the intention is to define a Hard Pipe stratum, it is, for example, possible to start from an estimated traffic matrix to estimate how much bandwidth to reserve on the links of the Ethernet link-layer network for the Hard Pipes.
たとえば、ハードパイプストラタムを定義する場合は、推定トラフィックマトリックスから開始して、ハードパイプ用のイーサネットリンク層ネットワークのリンクで予約する帯域幅の量を推定できます。
Note that the implication is that the normal traffic gets the remainder of the available bandwidth. Thus, the link-layer network will be split into two logical networks, or two strata -- one stratum for the hardened pipe network and the other for the "normal" IP and MPLS traffic. This is shown in Figures 2 and 3.
含意は、通常のトラフィックが使用可能な帯域幅の残りを取得するということです。したがって、リンク層ネットワークは2つの論理ネットワークまたは2つの層に分割されます。1つは強化されたパイプネットワーク用で、もう1つは「通常の」IPおよびMPLSトラフィック用です。これを図2および3に示します。
+---+ 2G +---+ +---+
+---| B |-----------| C | | E |---+
1G | +---+ +---+ +---+ | 2G
| | | |
+---+ 2G | 1G | +---+
--| F | | | | G |--
+---+ | | +---+
| | | |
1G | +---+ +---+ +---+ +---+ | 2G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 2G +---+ 4G +---+ 4G +---+
Figure 2: The Hard Pipe Stratum
図2：ハードパイプ層
It is worth noting that even if the figures in this document are drawn to indicate "bandwidth on the link", the only bandwidth information that the nodes have available is the bandwidth assigned to the Hard Pipe stratum and the Normal IP/MPLS stratum. All other information is kept on the NMS/Controller. The NMS/Controller keeps a global bandwidth resource table for the Hard Pipe stratum.
このドキュメントの図が「リンク上の帯域幅」を示すように描かれている場合でも、ノードが使用できる唯一の帯域幅情報は、ハードパイプストラタムと通常のIP / MPLSストラタムに割り当てられている帯域幅です。他のすべての情報はNMS / Controllerに保持されます。 NMS /コントローラは、ハードパイプストラタムのグローバル帯域幅リソーステーブルを保持します。
Given that the starting point is the physical network in Figure 1 and the Hard Pipe stratum as defined in Figure 2, the Normal IP/MPLS stratum will look as is shown in Figure 3:
図1の物理ネットワークと図2で定義されているハードパイプストラタムが開始点であるとすると、通常のIP / MPLSストラタムは図3のようになります。
+---+ 8G +---+ 10G +---+ 10G +---+
+---| B |-----------| C |-----------| D |----------| E |---+
9G | +---+ +---+ +---+ +---+ | 8G
| | | | | |
+---+ | 10G 8G | 10G | 9G | +---+
--| F | | | | | | G |--
+---+ | | | | +---+
| | | | | |
9G | +---+ +---+ +---+ +---+ | 9G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 8G +---+ 6G +---+ 6G +---+
Figure 3: The Normal IP/MPLS Stratum
図3：通常のIP / MPLSストラタム
In this document, the concept of stratum network is used to indicate basically parallel logical networks with strictly separated resources. Traffic sent over one stratum network can not infringe on traffic in the other stratum network.
このドキュメントでは、層ネットワークの概念は、厳密に分離されたリソースを持つ基本的に並列の論理ネットワークを示すために使用されます。 1つのストラタムネットワークを介して送信されるトラフィックは、他のストラタムネットワークのトラフィックを侵害することはできません。
In the case described here, all the traffic in the Hard Pipe stratum is MPLS encapsulated. A number of the labels have been set aside so other applications can't allocate them and so the routers recognize them as belonging to the Hard Pipe application.
ここで説明するケースでは、ハードパイプ層のすべてのトラフィックはMPLSカプセル化されています。他のアプリケーションがそれらを割り当てることができず、ルーターがそれらをハードパイプアプリケーションに属しているものとして認識するように、いくつかのラベルは別に設定されています。
When the strata are provisioned, the IP/MPLS stratum is set up exactly as any other IP/MPLS network. The one small difference between provisioning the Hard Pipe stratum and the IP/MPLS stratum is that no overbooking is done for the Hard Pipe stratum.
層がプロビジョニングされると、IP / MPLS層は他のIP / MPLSネットワークとまったく同じように設定されます。ハードパイプ層とIP / MPLS層のプロビジョニングの1つの小さな違いは、ハードパイプ層に対してオーバーブッキングが行われないことです。
Overbooking and/or congestion in the IP/MPLS stratum can not affect the Hard Pipe stratum.
IP / MPLSストラタムのオーバーブッキングや輻輳は、ハードパイプストラタムには影響しません。
All labels used for the Hard Pipe stratum are "Configured Labels", i.e., labels that are provisioned and reclaimed by management actions. These management actions can be by manual actions or by an NMS/Controller or a centralized controller. For the size of network being deployed, manual configuration is not practical; we are both provisioning and reclaiming a label from an NMS/Controller.
ハードパイプ層に使用されるすべてのラベルは「構成済みラベル」です。つまり、管理アクションによってプロビジョニングおよび再利用されるラベルです。これらの管理アクションは、手動アクション、NMS /コントローラー、または集中コントローラーのいずれかです。展開されるネットワークのサイズでは、手動構成は実用的ではありません。 NMS /コントローラーからのラベルのプロビジョニングと再利用の両方を行っています。
o If an operator wants to set up a leased line, it is first checked if there is a path available in the Hard Pipe stratum that matches the criteria (e.g., bandwidth) for the requested leased line.
o オペレーターが専用回線をセットアップする場合は、最初に、要求された専用回線の基準（帯域幅など）に一致するハードパイプストラタムに使用可能なパスがあるかどうかがチェックされます。
* If such a path does exist, it is checked if there is a matching MPLS tunnel available over that path.
* そのようなパスが存在する場合、そのパス上で使用可能な一致するMPLSトンネルがあるかどうかがチェックされます。
+ If such a tunnel exists, it is used to establish the leased line by adding L-labels forming an LSP that are carried by the tunnel. L-labels are known only by the ingress and egress LSRs. They are local to the endpoints the same way that the label signaled by Targeted LDP (tLDP) is local to the endpoints of a targeted session LSP. (Here, "Targeted LDP" means LDP as defined in RFC 5036 [RFC5036], using Targeted Hello messages.)
+ そのようなトンネルが存在する場合は、トンネルによって運ばれるLSPを形成するLラベルを追加することにより、専用回線を確立するために使用されます。 Lラベルは、入力および出力LSRのみが認識します。それらは、ターゲットLDP（tLDP）によって通知されたラベルがターゲットセッションLSPのエンドポイントに対してローカルであるのと同じ方法で、エンドポイントに対してローカルです。 （ここで、「ターゲットLDP」とは、RFC 5036 [RFC5036]で定義されているLDPを意味し、ターゲットHelloメッセージを使用します。）
At the same time, the available bandwidth in the Hard Pipe stratum is decremented by the bandwidth that is needed for the leased line for every hop across this stratum in the global resource table (for the Hard Pipe stratum).
同時に、ハードパイプストラタムで使用可能な帯域幅は、（ハードパイプストラタムの）グローバルリソーステーブルのこのストラタム全体のすべてのホップの専用回線に必要な帯域幅によって減少します。
+ If such a tunnel does not exist, it can be established so that the leased line can be set up as above.
+ そのようなトンネルが存在しない場合は、専用回線を上記のように設定できるように確立できます。
* If the path does not exist (not enough bandwidth in the Hard Pipe stratum for the leased line), available bandwidth on the links is checked to see if the stratum can be expanded to accommodate such a path.
* パスが存在しない場合（専用回線用のハードパイプストラタムに十分な帯域幅がない場合）、リンクで利用可能な帯域幅がチェックされ、そのようなパスに対応するためにストラタムを拡張できるかどうかが確認されます。
+ If the Hard Pipe stratum can be expanded, this is done and the tunnel for the leased line is established as described above.
+ ハードパイプストラタムを拡張できる場合、これが行われ、上記のように専用回線のトンネルが確立されます。
It is likely that other modifications of the Hard Pipe stratum, e.g., consolidating already set up Hard IP tunnels on to existing links so that room for new leased lines are created, may have implications that go well outside the leased line service, and it is currently not viewed as a fully automated operation.
ハードパイプストラタムの他の変更、たとえば、セットアップ済みのハードIPトンネルを既存のリンクに統合して、新しい専用回線用のスペースが作成されるようにすると、専用回線サービスの範囲外になる可能性があります。現在、完全に自動化された操作とは見なされていません。
+ If it is not possible to expand the Hard Pipe stratum to accommodate the new path, set up of the leased line will need to be declined.
+ ハードパイプ層を拡張して新しいパスに対応できない場合は、専用回線の設定を拒否する必要があります。
Thus, given the existence of a viable Hard Pipe stratum, leased lines are configured in two very simple steps. First, establish a hop-by-hop tunnel (T-labels), and second, configure the leased lines (L-labels). The T-labels need to be configured on both the PE and P routers while L-labels only need to be configured on the PE routers.
したがって、実行可能なハードパイプ層が存在する場合、専用回線は2つの非常に簡単な手順で構成されます。最初に、ホップバイホップトンネル（Tラベル）を確立し、次に、専用回線（Lラベル）を構成します。 TラベルはPEルーターとPルーターの両方で構成する必要がありますが、LラベルはPEルーターでのみ構成する必要があります。
Note that L-labels may be used for normal IP service [RFC3031], BGP/MPLS VPNs [RFC4364], or PWs [RFC3985].
Lラベルは通常のIPサービス[RFC3031]、BGP / MPLS VPN [RFC4364]、またはPW [RFC3985]に使用できることに注意してください。
The system as described here generates a very small amount of state, and most of it is kept in the NMS/Controller.
ここで説明するシステムは非常に少量の状態を生成し、そのほとんどはNMS /コントローラーに保持されます。
The only configured information that is actually kept on the LSRs is
LSRに実際に保持される構成済みの情報は、
o the information needed for the label swapping procedures, i.e., incoming label to outgoing label and port, and whether the label belongs to the set of labels that are set aside for the Hard Pipe stratum tunnels; and
o ラベル交換手順に必要な情報、つまり、着信ラベルと発信ラベルおよびポート、およびラベルがハードパイプ層トンネル用に確保されている一連のラベルに属しているかどうか。そして
o the bandwidth available for the Hard Pipe stratum and the Normal IP/MPLS stratum.
o ハードパイプストラタムと通常のIP / MPLSストラタムで使用可能な帯域幅。
The following state needs to be kept in the NMS/Controller:
次の状態をNMS /コントローラに保持する必要があります。
o the topology and bandwidth resources available in the Hard Pipe network; see Figure 2.
o ハードパイプネットワークで使用可能なトポロジおよび帯域幅リソース。図2を参照してください。
o the total and available bandwidth per link in the Hard Pipe network; see Figure 4.
o ハードパイプネットワークのリンクごとの合計および使用可能な帯域幅。図4を参照してください。
o the T-label mappings; see Figure 5.
o Tラベルのマッピング。図5を参照してください。
o the L-label mappings; see Figure 6.
o Lラベルのマッピング。図6を参照してください。
o the reserved bandwidth, as well as other constraints and the path per L-label.
o 予約済み帯域幅、その他の制約、およびLラベルごとのパス。
The annotations given below are neither a programming guideline nor an indication how this architecture could be implemented. It is rather an indication of how much data needs to be saved for each stratum and leased line, as well as where this data could be stored.
以下に示す注釈は、プログラミングガイドラインでも、このアーキテクチャを実装する方法を示すものでもありません。これは、各ストラタムと専用回線について保存する必要があるデータの量と、このデータを保存できる場所を示すものです。
Considering the Hard Pipe stratum as it has been outlined in Figure 2, there is actually some additional information related to the Hard Pipe stratum that not is shown in the figure.
図2に概要が示されているハードパイプ層を検討すると、実際には、図には示されていないハードパイプ層に関連する追加情報がいくつかあります。
Looking explicitly on the link between LSR J and K we find:
LSR JとKの間のリンクを明示的に見ると、次のことがわかります。
+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,0]G
Figure 4
図4
The annotation [4,0]G means that 4G is allocated to the stratum on the link between J and K, and of these, 0G has been allocated to a service.
注釈[4,0] Gは、4GがJとKの間のリンク上のストラタムに割り当てられ、そのうち0Gがサービスに割り当てられていることを意味します。
If we were to allocate two tunnels labels from the labels that have been configured to work within the Hard Pipe stratum, the resource view would look like this:
ハードパイプストラタム内で機能するように構成されたラベルから2つのトンネルラベルを割り当てると、リソースビューは次のようになります。
+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,0]G T1 ,T2
Figure 5
図5
Note that allocating the tunnel labels does not reserve bandwidth for the tunnel from the Hard Pipe stratum.
トンネルラベルを割り当てても、ハードパイプストラタムからのトンネルの帯域幅は予約されないことに注意してください。
When the L-labels are assigned, this will consume bandwidth; so we need to keep track of the bandwidth per leased line and the total of bandwidth allocated from the Hard Pipe stratum.
Lラベルが割り当てられると、帯域幅が消費されます。したがって、専用回線あたりの帯域幅と、ハードパイプストラタムから割り当てられた帯域幅の合計を追跡する必要があります。
The annotation for the link between J and K could look like this:
JとKの間のリンクの注釈は次のようになります。
+---+ +---+ +---+ +---+
---| H |-----------| J |-----------| K |----------| L |---
+---+ +---+ +---+ +---+
[4,1.5]G, T1, L1 [.5], L2 [.5], T2, L1 [.5]
Figure 6
図6
The line [4,1.5]G, T1, L1 [.5], L2 [.5], T2, L1 [.5] would be interpreted as follows:
行[4,1.5] G、T1、L1 [.5]、L2 [.5]、T2、L1 [.5]は、次のように解釈されます。
The Hard Pipe stratum link between nodes J and K has 4G bandwidth allocated; of the total bandwidth, 1.5G is allocated for leased lines.
ノードJとKの間のハードパイプ層リンクには、4Gの帯域幅が割り当てられています。総帯域幅の1.5Gが専用回線に割り当てられます。
Tunnel label T1 carries two leased lines, each of 0.5G, and tunnel label T2 carries a third leased line of 0.5G.
トンネルラベルT1は、それぞれ0.5Gの2つの専用回線を伝送し、トンネルラベルT2は、0.5Gの3番目の専用回線を伝送します。
Note that it is not necessary to keep this information in the nodes; it is held within the NMS/Controller. Also, it is not necessary to keep the bandwidth per leased line, but some operations are simplified (e.g., removing a leased line) if this is done.
この情報をノードに保持する必要はないことに注意してください。 NMS /コントローラー内に保持されます。また、専用回線ごとに帯域幅を維持する必要はありませんが、これを行うと、一部の操作が簡略化されます（専用回線の削除など）。
Consider the case where an operator wants to set up a leased line of 0.4G from F to G in the Hard Pipe stratum in Figure 2.
オペレーターが、図2のハードパイプストラタムにFからGへの0.4Gの専用回線をセットアップする場合を考えます。
Since there are no constraints other than bandwidth and ingress and egress PEs, the shortest path will be chosen. A tunnel will be configured from F to G over the nodes F, H, J, K, L, and G, and a Leased Line label (a) will be configured on F and G, and the available resources will be recalculated.
帯域幅と入力および出力PE以外の制約がないため、最短パスが選択されます。ノードF、H、J、K、L、およびGを介してトンネルがFからGに構成され、専用線ラベル（a）がFおよびGに構成され、使用可能なリソースが再計算されます。
A second leased line of 0.3G between the same PEs is easily configured by adding a new Leased Line label (b) at the ingress and egress PEs.
同じPE間の0.3Gの2番目の専用回線は、入力および出力PEに新しい専用回線ラベル（b）を追加することで簡単に構成できます。
After these operations, a view of the Hard Pipe stratum resources (available bandwidth) would look like this:
これらの操作の後、ハードパイプストラタムリソース（使用可能な帯域幅）のビューは次のようになります。
+---+ 2G +---+ +---+
+---| B |-----------| C | | E |---+
1G | +---+ +---+ +---+ | 2G
| | | |
+---+ 2G | 1G | +---+
--| F | | | | G |--
+---+ | | +---+
| | | |
.3G | +---+ +---+ +---+ +---+ | 1.3G
+---| H |-----------| J |-----------| K |----------| L |---+
+---+ 1.3G +---+ 3.3G +---+ 3.3G +---+
Figure 7: The Hard Pipe Stratum after Operations
図7：運用後のハードパイプ層
If the operator now wishes to establish a new leased line with the criteria being that it should originate from F and terminate at G, have 0.4G bandwidth, and pass through node E, then analysis of the Hard Pipe stratum (after establishing the first two listed lines) and the criteria for the new leased line would give the following:
オペレーターがFから始まり、Gで終端し、0.4Gの帯域幅を持ち、ノードEを通過するという基準で新しい専用回線を確立する場合、ハードパイプ層の分析（最初の2つを確立した後）リストされた回線）と新しい専用回線の基準は、次のようになります。
o The existing tunnel cannot be used since it does not pass through E; a new tunnel need to be established.
o Eを通過しないため、既存のトンネルは使用できません。新しいトンネルを確立する必要があります。
o The hop from F to H cannot be used since the available bandwidth is insufficient.
o FからHへのホップは、使用可能な帯域幅が不足しているため使用できません。
o Since no existing tunnels meet the criteria requested, a new tunnel will be set up from F, to B, C, J, K, L, E (the criteria to pass through E), and to G.
o 要求された基準を満たす既存のトンネルがないため、FからB、C、J、K、L、E（Eを通過する基準）、およびGへの新しいトンネルがセットアップされます。
A new L-label (c) to be carried over T2 will be configured on F and G, and the available resources of the Hard Pipe stratum will be recalculated.
T2に引き継がれる新しいLラベル（c）がFとGで構成され、ハードパイプ層の使用可能なリソースが再計算されます。
This leased line service uses the MPLS Transport Profile (MPLS-TP) line protection as it is defined in RFC 6378 [RFC6378] and is updated as specified in RFC 7271 [RFC7271] and RFC 7324 [RFC7324]
この専用回線サービスは、RFC 6378 [RFC6378]で定義され、RFC 7271 [RFC7271]およびRFC 7324 [RFC7324]での指定に従って更新されるため、MPLSトランスポートプロファイル（MPLS-TP）回線保護を使用します。
The CV and CC are run over the tunnels between the Maintenance Entity Group End Points (MEP) at each end, i.e., the entire tunnel is protected end to end.
CVとCCは、両端のメンテナンスエンティティグループエンドポイント（MEP）間のトンネルを介して実行されます。つまり、トンネル全体がエンドツーエンドで保護されます。
In general, all of the MPLS-TP Operations, Administration, and Maintenance (OAM) as defined in RFC 6371 [RFC6371] is v applicable.
一般に、RFC 6371 [RFC6371]で定義されているすべてのMPLS-TP運用、管理、および保守（OAM）が適用されます。
The security considerations as defined in "Security Framework for MPLS and GMPLS Networks" (RFC 5920 [RFC5920]) and "MPLS Transport Profile (MPLS-TP) Security Framework" (RFC 6941 [RFC6941]) apply to this document.
「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」（RFC 5920 [RFC5920]）および「MPLSトランスポートプロファイル（MPLS-TP）セキュリティフレームワーク」（RFC 6941 [RFC6941]）で定義されているセキュリティの考慮事項は、このドキュメントに適用されます。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<http://www.rfc-editor.org/info / rfc3031>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<http://www.rfc-editor.org/info/rfc3985 >。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<http：// www。 rfc-editor.org/info/rfc5036>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 DOI 10.17487 / RFC5921、2010年7月、<http://www.rfc-editor.org/info/rfc5921>。
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6371] Busi、I.、Ed。およびD. Allan編、「MPLSベースのトランスポートネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、DOI 10.17487 / RFC6371、2011年9月、<http://www.rfc-editor.org/info/ rfc6371>。
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <http://www.rfc-editor.org/info/rfc6378>.
[RFC6378] Weingarten、Y。、編、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、編、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、 DOI 10.17487 / RFC6378、2011年10月、<http://www.rfc-editor.org/info/rfc6378>。
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013, <http://www.rfc-editor.org/info/rfc6941>.
[RFC6941] Fang、L.、Ed。、Niven-Jenkins、B.、Ed。、Mansfield、S.、Ed。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、DOI 10.17487 / RFC6941、2013年4月、<http://www.rfc-editor.org/info/rfc6941>。
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, <http://www.rfc-editor.org/info/rfc7271>.
[RFC7271] Ryoo、J.、Ed。、Gray、E.、Ed。、van Helvoort、H.、D'Alessandro、A.、Cheung、T。、およびE. Osborne、「MPLS Transport Profile（MPLS-TP ）同期デジタル階層、光トランスポートネットワーク、およびイーサネットトランスポートネットワークオペレーターの運用上の期待に一致する線形保護」、RFC 7271、DOI 10.17487 / RFC7271、2014年6月、<http://www.rfc-editor.org/info/ rfc7271>。
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014, <http://www.rfc-editor.org/info/rfc7324>.
[RFC7324] Osborne、E。、「Updates to MPLS Transport Profile Linear Protection」、RFC 7324、DOI 10.17487 / RFC7324、2014年7月、<http://www.rfc-editor.org/info/rfc7324>。
Acknowledgements
謝辞
The authors want to thank Andy Malis for detailed technical and language review and for valuable comments.
著者は、詳細な技術および言語のレビューと貴重なコメントを提供してくれたAndy Malisに感謝します。
Authors' Addresses
著者のアドレス
JiangTao Hao Huawei Technologies Co., Ltd Q13 Huawei Campus No. 156 Beiqing Road Hai-dian District Beijing 100095 China Email: haojiangtao@huawei.com
Jiang tao ha oh UA is technologies co。、Ltd Q13 hu A is campus no。156 be i青road H艾-pointdistrict Beijing 100095 China email：号江涛@ Huawei.com
Praveen Maheshwari Bharti Airtel, Ltd. Plot No. 16, Udyog Bihar, Phase IV, Gurgaon - 122015 Haryana India Email: Praveen.Maheshwari@in.airtel.com
Praveen Maheshwari Bharti Airtel、Ltd.プロット番号16、Udyog Bihar、フェーズIV、グルガオン-122015ハリヤーナ州インドメール：Praveen.Maheshwari@in.airtel.com
River Huang Huawei Technologies Co., Ltd Q13 Huawei Campus No. 156 Beiqing Road Hai-dian District Beijing 100095 China Email: river.huang@huawei.com
River Huang hu Aはテクノロジー株式会社向けQ13 hu Aはキャンパス番号156向けi iroad H H Ai-dot地区北京100095中国Eメール：river。黄@华华.com
Loa Andersson Huawei Technologies Co., Ltd Stockholm Sweden Email: loa@mail01.huawei.com
Loa Andersson Huawei Technologies Co.、Ltd Stockholm Swedenメール：loa@mail01.huawei.com
Mach(Guoyi) Chen Huawei Technologies Co., Ltd Q14 Huawei Campus No. 156 Beiqing Road Hai-dian District Beijing 100095 China Email: mach.chen@huawei.com
Mach（GU O一）Chen hu A is Technologies co。、Ltd Q14 hu A is campus no。156 be iblueroad H Ai-dian District Beijing 100095 China email：Ma Chao。陈@华华.com