[要約] RFC 7855は、ネットワーキングにおけるソースパケットルーティング（SPRING）の問題と要件に関するものです。このRFCの目的は、SPRINGの問題を明確にし、要件を定義することです。
Internet Engineering Task Force (IETF) S. Previdi, Ed.
Request for Comments: 7855 C. Filsfils, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
S. Litkowski
Orange
M. Horneffer
Deutsche Telekom
R. Shakir
Jive Communications, Inc.
May 2016
Source Packet Routing in Networking (SPRING) Problem Statement and Requirements
ネットワーキングにおけるソースパケットルーティング（SPRING）の問題の説明と要件
Abstract
概要
The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).
ノードが特定のパケットが通過する通常の最短パス以外の転送パスを指定できることは、多くのネットワーク機能に役立ちます。ソースベースのルーティングメカニズムは、以前はネットワークプロトコル用に指定されていましたが、広く採用されることはありませんでした。この文脈では、「ソース」という用語は「明示的なルートが課されるポイント」を意味します。したがって、それはパケットの発信元に限定されません（つまり、明示的なルートを課すノードは、オペレーターのネットワークの入口ノードである可能性があります）。
This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.
このドキュメントでは、ユニキャストトラフィックのネットワーク（SPRING）アーキテクチャのソースパケットルーティングで考慮する必要があるさまざまな使用例とその要件について概説します。マルチキャストの使用例と要件は、このドキュメントの範囲外です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7855.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7855で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Data Planes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IGP-Based MPLS Tunneling . . . . . . . . . . . . . . . . 4
3.1.1. Example of IGP-Based MPLS Tunnels . . . . . . . . . . 5
3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 6
3.3.1. Examples of Traffic-Engineering Use Cases . . . . . . 7
3.4. Interoperability with Non-SPRING Nodes . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Manageability Considerations . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The ability for a node to specify a unicast forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example:
ノードが、特定のパケットが通過するユニキャスト転送パス（通常の最短パス以外）を指定する機能は、次のような多くのネットワーク機能に役立ちます。
o Some types of network virtualization, including multi-topology networks and the partitioning of network resources for VPNs
o マルチトポロジネットワークやVPNのネットワークリソースの分割など、いくつかのタイプのネットワーク仮想化
o Network, link, path, and node protection such as fast reroute
o ネットワーク、リンク、パス、および高速再ルーティングなどのノード保護
o Network programmability
o ネットワークプログラマビリティ
o OAM techniques
o OAMテクニック
o Simplification and reduction of network signaling components
o ネットワークシグナリングコンポーネントの簡素化と削減
o Load balancing and traffic engineering
o 負荷分散とトラフィックエンジニアリング
Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering.
送信元ベースのルーティングメカニズムは、以前はネットワークプロトコル用に指定されていましたが、MPLSトラフィックエンジニアリング以外では広く採用されていません。
These network functions may require greater flexibility and more source-imposed routing than can be achieved through the use of the previously defined methods. In the context of this document, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network). Throughout this document, we refer to this definition of "source".
これらのネットワーク機能には、以前に定義された方法を使用して実現できるよりも、柔軟性とソースによるルーティングが必要になる場合があります。このドキュメントのコンテキストでは、「ソース」という用語は「明示的なルートが課されるポイント」を意味します。したがって、それはパケットの発信元に限定されません（つまり、明示的なルートを課すノードは、オペレーターのネットワークの入口ノードである可能性があります）。このドキュメント全体を通して、この「ソース」の定義を参照しています。
In this context, Source Packet Routing in Networking (SPRING) architecture is being defined in order to address the use cases and requirements described in this document.
このコンテキストでは、このドキュメントで説明されているユースケースと要件に対処するために、ネットワーキングにおけるソースパケットルーティング（SPRING）アーキテクチャが定義されています。
The SPRING architecture MUST allow incremental and selective deployment without any requirement of a flag day or massive upgrade of all network elements.
SPRINGアーキテクチャでは、すべてのネットワーク要素の旗艦日や大規模なアップグレードを必要とせずに、段階的で選択的な展開を許可する必要があります。
The SPRING architecture MUST allow putting the policy state in the packet header and not in the intermediate nodes along the path. Hence, the policy is instantiated in the packet header and does not requires any policy state in midpoints and tail-ends.
SPRINGアーキテクチャは、パスに沿った中間ノードではなく、パケットヘッダーにポリシー状態を置くことを許可する必要があります。したがって、ポリシーはパケットヘッダーでインスタンス化され、中間点とテールエンドでポリシー状態を必要としません。
The SPRING architecture objective is not to replace existing source-routing and traffic-engineering mechanisms, but rather to complement them and address use cases where removal of signaling and path state in the core is a requirement.
SPRINGアーキテクチャの目的は、既存のソースルーティングおよびトラフィックエンジニアリングメカニズムを置き換えることではなく、それらを補完し、コアのシグナリングとパス状態の削除が必要なユースケースに対処することです。
Multicast use cases and requirements are out of scope for this document.
マルチキャストの使用例と要件は、このドキュメントの範囲外です。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The SPRING architecture SHOULD be general in order to ease its applicability to different data planes.
SPRINGアーキテクチャは、さまざまなデータプレーンへの適用を容易にするために一般的である必要があります。
The SPRING architecture SHOULD leverage the existing MPLS data plane without any modification and leverage the IPv6 data plane with a new IPv6 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]) and a proposal for a new type of routing header is made by [SRH].
SPRINGアーキテクチャは、既存のMPLSデータプレーンを変更せずに活用し、IPv6データプレーンを新しいIPv6ルーティングヘッダータイプ（IPv6ルーティングヘッダーは[RFC2460]で定義されています）で活用する必要があります。新しいタイプのルーティングヘッダーの提案は、 [SRH]。
The SPRING architecture MUST allow interoperability between SPRING-capable and non-SPRING-capable nodes in both the MPLS and IPv6 data planes.
SPRINGアーキテクチャでは、MPLSおよびIPv6データプレーンの両方で、SPRING対応ノードと非SPRING対応ノード間の相互運用性を許可する必要があります。
The source-based routing model, applied to the MPLS data plane, offers the ability to tunnel services like VPN ([RFC4364]), Virtual Private LAN Service (VPLS) ([RFC4761], [RFC4762]) and Virtual Private Wire Service (VPWS) ([RFC6624]), from an ingress Provider Edge (PE) to an egress PE, with or without the expression of an explicit path and without requiring forwarding-plane or control-plane state in intermediate nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are outside the scope of this document.
MPLSデータプレーンに適用されるソースベースのルーティングモデルは、VPN（[RFC4364]）、仮想プライベートLANサービス（VPLS）（[RFC4761]、[RFC4762]）、仮想プライベートワイヤーサービス（ VPWS）（[RFC6624]）、入力プロバイダーエッジ（PE）から出力PEへ。明示的なパスの表現の有無にかかわらず、中間ノードでの転送プレーンまたはコントロールプレーンの状態は必要ありません。ポイントツーマルチポイントおよびマルチポイントツーマルチポイントトンネルは、このドキュメントの範囲外です。
This section illustrates an example use case.
このセクションでは、使用例を示します。
P1---P2
/ \
A---CE1---PE1 PE2---CE2---Z
\ /
P3---P4
Figure 1: IGP-Based MPLS Tunneling
図1：IGPベースのMPLSトンネリング
In Figure 1 above, the four nodes A, CE1, CE2, and Z are part of the same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to that route and propagates the route and its label via the Multiprotocol Border Gateway Protocol (MPBGP) to PE1 with next-hop address 192.0.2.2 (i.e., the local address of PE2). PE1 installs the VPN prefix Z in the appropriate VPN Routing and Forwarding table (VRF) and resolves the next hop onto the IGP-based MPLS tunnel to PE2.
上記の図1では、4つのノードA、CE1、CE2、およびZが同じVPNの一部です。 CE2はZへのルートをPE2にアドバタイズします。PE2はローカルラベルLZをそのルートにバインドし、マルチプロトコルボーダーゲートウェイプロトコル（MPBGP）を介してルートとそのラベルをネクストホップアドレス192.0.2.2（つまり、ローカルアドレス）でPE1に伝播します。 PE2）の。 PE1は、VPNプレフィックスZを適切なVPNルーティングおよび転送テーブル（VRF）にインストールし、IGPベースのMPLSトンネルへのネクストホップをPE2に解決します。
To cope with the reality of current deployments, the SPRING architecture MUST allow PE-to-PE forwarding according to the IGP shortest path without the addition of any other signaling protocol. The packet each PE forwards across the network will contain the necessary information derived from the topology database in order to deliver the packet to the remote PE.
現在の展開の現実に対処するために、SPRINGアーキテクチャでは、他のシグナリングプロトコルを追加せずに、IGP最短パスに従ってPE-to-PE転送を許可する必要があります。各PEがネットワークを介して転送するパケットには、リモートPEにパケットを配信するために、トポロジデータベースから派生した必要な情報が含まれます。
Fast Reroute (FRR) technologies have been deployed by network operators in order to cope with link or node failures through precomputation of backup paths.
Fast Reroute（FRR）テクノロジは、バックアップパスの事前計算を通じてリンクまたはノードの障害に対処するために、ネットワークオペレーターによって導入されています。
Illustration of the problem statement for FRR and micro-loop avoidance can be found in [SPRING-RESIL].
無料およびマイクロループ回避の問題ステートメントの図は、[SPRING-RESIL]にあります。
The SPRING architecture MUST address the following requirements:
SPRINGアーキテクチャは、次の要件に対処する必要があります。
o support of Fast Reroute (FRR) on any topology
o あらゆるトポロジでの高速リルート（FRR）のサポート
o precomputation and setup of backup path without any additional signaling (other than the regular IGP/BGP protocols)
o 追加のシグナリングなしのバックアップパスの事前計算とセットアップ（通常のIGP / BGPプロトコル以外）
o support of shared risk constraints o support of node and link protection
o共有リスク制約のサポートoノードおよびリンク保護のサポート
o support of micro-loop avoidance
o マイクロループ回避のサポート
Traffic Engineering (TE) is the term used to refer to techniques that enable operators to control how specific traffic flows are treated within their networks. Different contexts and modes have been defined (single vs. multiple domains, with or without bandwidth admission control, centralized vs. distributed path computation, etc.).
トラフィックエンジニアリング（TE）は、オペレーターがネットワーク内で特定のトラフィックフローをどのように処理するかを制御できるようにする技術を指す用語です。さまざまなコンテキストとモードが定義されています（単一ドメインと複数ドメイン、帯域幅アドミッションコントロールの有無にかかわらず、集中パスと分散パスの計算など）。
Some deployments have a limited use of TE, such as addressing specific application or customer requirements, or addressing specific bandwidth limitations in the network (tactical TE). In these situations, there is a need to reduce, as much as possible, the cost (such as the number of signaling protocols and the number of nodes requiring specific configurations/features). Some other deployments have a very high-scale use of TE, such as fine tuning flows at the application level. In this situation, there is a need for very high scalability, in particular on midpoints.
一部の展開では、特定のアプリケーションや顧客の要件への対応、またはネットワーク内の特定の帯域幅制限への対応（戦術TE）など、TEの使用が制限されています。これらの状況では、コスト（シグナリングプロトコルの数や特定の構成/機能を必要とするノードの数など）を可能な限り削減する必要があります。他のいくつかの展開では、アプリケーションレベルでのフローの微調整など、TEを非常に大規模に使用します。この状況では、特に中間点で、非常に高いスケーラビリティが必要です。
The source-based routing model allows traffic engineering to be implemented without the need for a signaling component.
ソースベースのルーティングモデルを使用すると、シグナリングコンポーネントを必要とせずにトラフィックエンジニアリングを実装できます。
The SPRING architecture MUST support the following traffic-engineering requirements:
SPRINGアーキテクチャは、次のトラフィックエンジニアリング要件をサポートする必要があります。
o loose or strict options
o 緩いまたは厳格なオプション
o bandwidth admission control
o 帯域幅アドミッションコントロール
o distributed vs. centralized model (e.g., Path Computation Element (PCE) [STATEFUL-PCE], Software-Defined Networking (SDN) Controller)
o 分散型モデルと集中型モデル（例：パス計算要素（PCE）[STATEFUL-PCE]、ソフトウェア定義ネットワーク（SDN）コントローラー）
o disjointness in dual-plane networks
o デュアルプレーンネットワークの素性
o egress peer engineering
o 出力ピアエンジニアリング
o load balancing among non-parallel links (i.e., links connected to different adjacent neighbors).
o 非並列リンク（つまり、異なる隣接ネイバーに接続されているリンク）間の負荷分散。
o limiting (scalable, preferably zero) per-service state and signaling on midpoint and tail-end routers.
o ミッドポイントおよびテールエンドルーターでのサービスごとの状態とシグナリングの制限（スケーラブル、できればゼロ）。
o ECMP-awareness o node resiliency property (i.e., the traffic-engineering policy is not anchored to a specific core node whose failure could impact the service).
o ECMP認識oノードの復元力プロパティ（つまり、トラフィックエンジニアリングポリシーは、障害がサービスに影響を与える可能性のある特定のコアノードに固定されていません）。
In most cases, traffic engineering makes use of the "loose" route option where most of the explicit paths can be expressed through a small number of hops. However, there are use cases where the "strict" option may be used and, in such cases, each individual hop in the explicit path is specified. This may result in a long list of hops that is instantiated into a MPLS label stack (in the MPLS data plane) or list of IPv6 addresses (in the IPv6 data plane).
ほとんどの場合、トラフィックエンジニアリングは「ルーズ」ルートオプションを利用しており、ほとんどの明示的なパスを少数のホップで表現できます。ただし、「strict」オプションを使用できるユースケースがあり、そのような場合は、明示的なパス内の個々のホップが指定されます。これにより、MPLSラベルスタック（MPLSデータプレーン内）またはIPv6アドレスのリスト（IPv6データプレーン内）にインスタンス化されるホップの長いリストが生成される場合があります。
It is obvious that, in the case of long, strict source-routed paths, the deployment is possible if the head-end of the explicit path supports the instantiation of long explicit paths.
長く厳密なソースルートパスの場合、明示的なパスのヘッドエンドが長い明示的なパスのインスタンス化をサポートしていれば、展開が可能であることは明らかです。
Alternatively, a controller could decompose the end-to-end path into a set of sub-paths such as each of these sub-paths is supported by its respective head-end and advertised with a single identifier. Hence, the concatenation (or stitching) of the sub-paths identifiers gives a compression scheme allowing an end-to-end path to be expressed in a smaller number of hops.
あるいは、コントローラはエンドツーエンドパスを一連のサブパスに分解できます。たとえば、これらの各サブパスはそれぞれのヘッドエンドによってサポートされ、単一の識別子でアドバタイズされます。したがって、サブパス識別子の連結（またはスティッチング）により、エンドツーエンドパスをより少ないホップ数で表現できる圧縮スキームが提供されます。
Below are descriptions of two sets of use cases:
以下は、2つの使用例の説明です。
o Traffic Engineering without Admission Control
o アドミッションコントロールなしのトラフィックエンジニアリング
o Traffic Engineering with Admission Control
o アドミッションコントロールを使用したトラフィックエンジニアリング
In this section, we describe Traffic Engineering use cases without bandwidth admission control.
このセクションでは、帯域幅アドミッション制御のないトラフィックエンジニアリングの使用例について説明します。
Many networks are built according to the dual-plane design, as illustrated in Figure 2:
図2に示すように、多くのネットワークはデュアルプレーン設計に従って構築されています。
Each aggregation region k is connected to the core by two C routers C1k and C2k, where k refers to the region.
各アグリゲーションリージョンkは、2つのCルータC1kおよびC2kによってコアに接続されています。ここで、kはリージョンを指します。
C1k is part of plane 1 and aggregation region k
C1kは平面1の一部であり、集約領域k
C2k is part of plane 2 and aggregation region k C1k has a link to C2j iff k = j.
C2kは平面2の一部であり、集約領域k C1kはk = jの場合にC2jへのリンクを持っています。
The core nodes of a given region are directly connected. Inter-region links only connect core nodes of the same plane.
特定のリージョンのコアノードは直接接続されています。リージョン間リンクは、同じプレーンのコアノードのみを接続します。
{C1k has a link to C1j} iff {C2k has a link to C2j}.
{C2kにC2jへのリンクがある場合} {C1kにはC1jへのリンクがあります}。
The distribution of these links depends on the topological properties of the core of the Autonomous System (AS). The design rule presented above specifies that these links appear in both core planes.
これらのリンクの分布は、自律システム（AS）のコアのトポロジ特性に依存します。上記のデザインルールは、これらのリンクが両方のコアプレーンに表示されることを指定しています。
We assume a common design rule found in such deployments: The inter-plane link costs (Cik - Cjk, where i != j) are set such that the route to an edge destination from a given plane stays within the plane unless the plane is partitioned.
このような展開で見られる一般的な設計ルールを想定します。プレーン間リンクコスト（Cik-Cjk、i！= j）は、プレーンが指定されていない限り、特定のプレーンからエッジ宛先へのルートがプレーン内に留まるように設定されます。分割されます。
Edge Router A
/ \
/ \
/ \ Agg Region A
/ \
/ \
C1A----------C2A
| \ | \
| \ | \
| C1B----------C2B
Plane1 | | | | Plane2
| | | |
C1C--|-----C2C |
\ | \ |
\ | \ |
C1Z----------C2Z
\ /
\ / Agg Region Z
\ /
\ /
Edge Router Z
Figure 2: Dual-Plane Network and Disjointness
図2：デュアルプレーンネットワークと素性
In this scenario, the operator requires the ability to deploy different strategies. For example, Edge Router A should be able to use the three following options:
このシナリオでは、オペレーターはさまざまな戦略を展開できる必要があります。たとえば、エッジルーターAは次の3つのオプションを使用できる必要があります。
o The traffic is load-balanced across any ECMP path through the network.
o トラフィックは、ネットワークを介したECMPパス全体で負荷分散されます。
o The traffic is load-balanced across any ECMP path within Plane1 of the network.
o トラフィックは、ネットワークのPlane1内のECMPパス全体で負荷分散されます。
o The traffic is load-balanced across any ECMP path within Plane2 of the network.
o トラフィックは、ネットワークのPlane2内のECMPパス全体で負荷分散されます。
Most of the data traffic from A to Z would use the first option, so as to exploit the capacity efficiently. The operator would use the two other choices for specific premium traffic that has requested disjoint transport.
AからZへのほとんどのデータトラフィックは、容量を効率的に活用するために、最初のオプションを使用します。オペレーターは、分離したトランスポートを要求した特定のプレミアムトラフィックに対して他の2つの選択肢を使用します。
The SPRING architecture MUST support this use case with the following requirements:
SPRINGアーキテクチャは、次の要件でこのユースケースをサポートする必要があります。
o Zero per-service state and signaling on midpoint and tail-end routers.
o ミッドポイントおよびテールエンドルーターでのサービスごとの状態およびシグナリングのゼロ。
o ECMP-awareness.
o ECMP認識。
o Node resiliency property: The traffic-engineering policy is not anchored to a specific core node whose failure could impact the service.
o ノードの回復力のプロパティ：トラフィックエンジニアリングポリシーは、障害がサービスに影響を与える可能性がある特定のコアノードに固定されていません。
+------+
| |
+---D F
+---------+ / | AS2 |\ +------+
| |/ +------+ \| Z |
A C | |
| |\ +------+ /| AS4 |
B AS1 | \ | |/ +------+
| | +---E G
+---------+ | AS3 |
+------+\
Figure 3: Egress Peering Traffic Engineering
図3：出力ピアリングトラフィックエンジニアリング
Let us assume, in the network depicted in Figure 3, that:
図3に示すネットワークで、次のことを想定します。
o C in AS1 learns about destination Z of AS4 via two BGP paths (AS2, AS4) and (AS3, AS4).
o AS1のCは、2つのBGPパス（AS2、AS4）と（AS3、AS4）を介してAS4の宛先Zについて学習します。
o C may or may not be configured to enforce the next-hop-self behavior before propagating the paths within AS1.
o Cは、AS1内のパスを伝播する前に次のホップの自己動作を強制するように構成されている場合とされていない場合があります。
o C may propagate all the paths to Z within AS1 (using BGP ADD-PATH as specified in [ADD-PATH]).
o Cは、AS1内のZへのすべてのパスを伝搬できます（[ADD-PATH]で指定されたBGP ADD-PATHを使用）。
o C may install in its Forwarding Information Base (FIB) only the route via AS2, or only the route via AS3, or both.
o Cは、その転送情報ベース（FIB）に、AS2経由のルートのみ、またはAS3経由のルートのみ、あるいはその両方をインストールできます。
In that context, the SPRING architecture MUST allow the operator of AS1 to apply a traffic-engineering policy such as the following one, regardless of the configured behavior of the next-hop-self:
そのコンテキストでは、SPRINGアーキテクチャは、AS1のオペレーターが、next-hop-selfの構成された動作に関係なく、次のようなトラフィックエンジニアリングポリシーを適用できるようにする必要があります。
o Steer 60% of the Z-destined traffic received at A via AS2 and 40% via AS3.
o AS経由でAで受信したZ宛てのトラフィックの60％、AS3経由で40％をステアリングします。
o Steer 80% of the Z-destined traffic received at B via AS2 and 20% via AS3.
o AS2を介してBで受信されたZ宛てのトラフィックの80％およびAS3を介して20％をステアリングします。
The SPRING architecture MUST allow an ingress node (i.e., an explicit route source node) to select the exit point of a packet as any combination of an egress node, an egress interface, a peering neighbor, and a peering AS.
SPRINGアーキテクチャでは、入口ノード（つまり、明示的なルートソースノード）がパケットの出口点を出口ノード、出口インターフェース、ピアリングネイバー、ピアリングASの任意の組み合わせとして選択できるようにする必要があります。
The use cases and requirements for egress peer engineering are described in [SR-BGP-EPE].
出力ピアエンジニアリングの使用例と要件は、[SR-BGP-EPE]で説明されています。
The SPRING architecture MUST allow a given node to load-share traffic across multiple non-parallel links (i.e., links connected to different adjacent routers), even if these lead to different neighbors. This may be useful for supporting traffic-engineering policies.
SPRINGアーキテクチャでは、特定のノードが複数の非並列リンク（つまり、異なる隣接ルーターに接続されているリンク）間でトラフィックを負荷共有することを許可する必要があります。これは、トラフィックエンジニアリングポリシーのサポートに役立つ場合があります。
+---C---D---+
| |
PE1---A---B-----F-----E---PE2
Figure 4: Multiple (Non-parallel) Adjacencies
図4：複数の（非並列）隣接関係
In the above example, the operator requires PE1 to load-balance its PE2-destined traffic between the ABCDE and ABFE equal-cost paths in a controlled way where the operator MUST be allowed to distribute traffic unevenly between paths (Weighted Equal-Cost Multipath (WECMP)).
上記の例では、オペレーターは制御された方法でABCDEとABFEの等コストパス間でPE2宛てのトラフィックを負荷分散するようにPE1に要求します。この場合、オペレーターはパス間でトラフィックを不均一に分散する必要があります（Weighted Equal-Cost Multipath（ WECMP））。
The implementation of bandwidth admission control within a network (and its possible routing consequence, which consists in routing along explicit paths where the bandwidth is available) requires a capacity-planning process.
ネットワーク内での帯域幅アドミッションコントロールの実装（および、帯域幅が利用可能な明示的なパスに沿ったルーティングで構成される、ルーティングの結果）には、容量計画プロセスが必要です。
The spreading of load among ECMP paths is a key attribute of the capacity-planning processes applied to packet-based networks.
ECMPパス間での負荷分散は、パケットベースのネットワークに適用される容量計画プロセスの重要な属性です。
Capacity planning anticipates the routing of the traffic matrix onto the network topology for a set of expected traffic and topology variations. The heart of the process consists in simulating the placement of the traffic along ECMP-aware shortest paths and accounting for the resulting bandwidth usage.
キャパシティプランニングでは、予想されるトラフィックとトポロジのバリエーションのセットについて、ネットワークトポロジへのトラフィックマトリックスのルーティングを予測します。プロセスの中心は、ECMP対応の最短パスに沿ったトラフィックの配置のシミュレーションと、結果として生じる帯域幅の使用量の計算にあります。
The bandwidth accounting of a demand along its shortest path is a basic capability of any planning tool or PCE server.
最短経路に沿った需要の帯域幅アカウンティングは、あらゆる計画ツールまたはPCEサーバーの基本的な機能です。
For example, in the network topology described below, and assuming a default IGP metric of 1 and IGP metric of 2 for link GF, a 1600 Mbps A-to-Z flow is accounted as consuming 1600 Mbps on links AB and FZ; 800 Mbps on links BC, BG, and GF; and 400 Mbps on links CD, DF, CE, and EF.
たとえば、以下で説明するネットワークトポロジでは、リンクGFのデフォルトのIGPメトリックが1で、IGPメトリックが2であると仮定すると、1600 MbpsのA-to-Zフローは、リンクABおよびFZで1600 Mbpsを消費していると見なされます。リンクBC、BG、およびGFで800 Mbps。リンクCD、DF、CE、およびEFで400 Mbps。
C-----D
/ \ \
A---B +--E--F--Z
\ /
G------+
Figure 5: Capacity Planning an ECMP-Based Demand
図5：ECMPベースの需要の容量計画
ECMP is extremely frequent in Service Provider (SP), enterprise, and data-center architectures and it is not rare to see as much as 128 different ECMP paths between a source and a destination within a single network domain. It is a key efficiency objective to spread the traffic among as many ECMP paths as possible.
ECMPは、サービスプロバイダー（SP）、エンタープライズ、およびデータセンターのアーキテクチャで非常に頻繁に発生し、単一のネットワークドメイン内のソースと宛先の間で128もの異なるECMPパスが表示されることは珍しくありません。できるだけ多くのECMPパス間でトラフィックを分散させることは、主要な効率目標です。
This is illustrated in the network diagram below, which consists of a subset of a network where already 5 ECMP paths are observed from A to M.
これは、次のネットワークダイアグラムに示されています。これは、AからMにすでに5つのECMPパスが観察されているネットワークのサブセットで構成されています。
C
/ \
B-D-L--
/ \ / \
A E \
\ M
\ G /
\ / \ /
F K
\ /
I
Figure 6: ECMP Topology Example
図6：ECMPトポロジーの例
When the capacity-planning process detects that a traffic growth scenario and topology variation would lead to congestion, a capacity increase is triggered, and if it cannot be deployed in due time, a traffic-engineering solution is activated within the network.
キャパシティプランニングプロセスで、トラフィックの増加シナリオとトポロジの変化により輻輳が発生することが検出されると、キャパシティの増加がトリガーされ、適時に展開できない場合は、ネットワーク内でトラフィックエンジニアリングソリューションがアクティブになります。
A basic traffic-engineering objective consists of finding the smallest set of demands that need to be routed off their shortest path to eliminate the congestion, and then to compute an explicit path for each of them and instantiate these traffic-engineered policies in the network.
基本的なトラフィックエンジニアリングの目的は、輻輳を解消するために最短パスからルーティングする必要のある最小の要求セットを見つけ、それぞれの明示的なパスを計算し、ネットワークでこれらのトラフィックエンジニアリングポリシーをインスタンス化することです。
The SPRING architecture MUST offer a simple support for ECMP-based shortest-path placement as well as for explicit path policy without incurring additional signaling in the domain. This includes:
SPRINGアーキテクチャは、ECMPベースの最短パス配置と、ドメインで追加のシグナリングを発生させずに明示的なパスポリシーをサポートする必要があります。これも：
o the ability to steer a packet across a set of ECMP paths
o ECMPパスのセット全体でパケットを操作する機能
o the ability to diverge from a set of ECMP shortest paths to one or more paths not in the set of shortest paths
o ECMP最短パスのセットから、最短パスのセットにない1つ以上のパスに分岐する機能
The SDN use case lies in the SDN controller, (e.g., Stateful PCE as described in [STATEFUL-PCE]).
SDNの使用例は、SDNコントローラーにあります（たとえば、[STATEFUL-PCE]で説明されているステートフルPCE）。
The SDN controller is responsible for controlling the evolution of the traffic matrix and topology. It accepts or denies the addition of new traffic into the network. It decides how to route the accepted traffic. It monitors the topology and, upon topological change, determines the minimum traffic that should be rerouted on an alternate path to alleviate a bandwidth congestion issue.
SDNコントローラーは、トラフィックマトリックスとトポロジの進化を制御します。ネットワークへの新しいトラフィックの追加を許可または拒否します。受け入れたトラフィックのルーティング方法を決定します。トポロジーを監視し、トポロジーの変化に応じて、帯域幅の輻輳の問題を緩和するために代替パスで再ルーティングする必要がある最小トラフィックを決定します。
The algorithms supporting this behavior are a local matter of the SDN controller and are outside the scope of this document.
この動作をサポートするアルゴリズムは、SDNコントローラーのローカルな問題であり、このドキュメントの範囲外です。
The means of collecting traffic and topology information are the same as what would be used with other SDN-based traffic-engineering solutions.
トラフィックとトポロジー情報を収集する方法は、他のSDNベースのトラフィックエンジニアリングソリューションで使用されるものと同じです。
The means of instantiating policy information at a traffic-engineering head-end are the same as what would be used with other SDN-based traffic-engineering solutions.
トラフィックエンジニアリングヘッドエンドでポリシー情報をインスタンス化する方法は、他のSDNベースのトラフィックエンジニアリングソリューションで使用される方法と同じです。
In the context of centralized optimization and the SDN use case, the SPRING architecture MUST have the following attributes:
集中最適化とSDNユースケースのコンテキストでは、SPRINGアーキテクチャは次の属性を持つ必要があります。
o Explicit routing capability with or without ECMP-awareness.
o ECMP対応の有無にかかわらず明示的なルーティング機能。
o No signaling hop-by-hop through the network.
o ネットワークを介したホップバイホップのシグナリングはありません。
o The policy state is only maintained at the policy head-end. No policy state is maintained at midpoints and tail-ends.
o ポリシーの状態は、ポリシーのヘッドエンドでのみ維持されます。ポリシーの状態は、中間点と終了点で維持されません。
o Automated guaranteed FRR for any topology.
o あらゆるトポロジの自動保証FRR。
o The policy state is in the packet header and not in the intermediate nodes along the path. The policy is absent from midpoints and tail-ends.
o ポリシーの状態はパケットヘッダーにあり、パスに沿った中間ノードにはありません。このポリシーは、中間点と終了点にはありません。
o Highly responsive to change: The SDN Controller only needs to apply a policy change at the head-end. No delay is introduced due to programming the midpoints and tail-end along the path.
o 変更に対する応答性が高い：SDNコントローラーは、ヘッドエンドでポリシー変更を適用するだけで済みます。パスに沿って中点と後端をプログラミングするため、遅延は発生しません。
SPRING nodes MUST interoperate with non-SPRING nodes and in both MPLS and IPv6 data planes in order to allow a gradual deployment of SPRING on existing MPLS and IPv6 networks.
SPRINGノードは、既存のMPLSおよびIPv6ネットワークにSPRINGを段階的に導入できるようにするために、非SPRINGノードと相互運用し、MPLSおよびIPv6データプレーンの両方で相互運用する必要があります。
SPRING reuses the concept of source routing by encoding the path in the packet. As with other similar source-routing architecture, an attacker may manipulate the traffic path by modifying the packet header. By manipulating the traffic path, an attacker may be able to cause outages on any part of the network.
SPRINGは、パケット内のパスをエンコードすることにより、ソースルーティングの概念を再利用します。他の同様のソースルーティングアーキテクチャと同様に、攻撃者はパケットヘッダーを変更してトラフィックパスを操作する可能性があります。攻撃者は、トラフィックパスを操作することにより、ネットワークの任意の部分で停止を引き起こす可能性があります。
SPRING adds some metadata on the packet, with the list of forwarding path elements that the packet must traverse. Depending on the data plane, this list may shrink as the packet traverses the network, by keeping only the next elements and forgetting the past ones.
SPRINGは、パケットが通過する必要のある転送パス要素のリストとともに、パケットにメタデータを追加します。データプレーンによっては、次の要素のみを保持し、過去の要素を無視することにより、パケットがネットワークを通過するときに、このリストが縮小する場合があります。
SPRING architecture MUST provide clear trust domain boundaries so that source-routing information is only usable within the trusted domain and never exposed to the outside world.
SPRINGアーキテクチャは、信頼できるドメインの境界を明確に提供する必要があるため、ソースルーティング情報は信頼できるドメイン内でのみ使用でき、外部に公開されることはありません。
From a network protection standpoint, there is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so. This is a significant change compared to plain IP offering the shortest-path routing, but not fundamentally different compared to existing techniques providing explicit routing capability. It is expected that, by default, the explicit routing information is not leaked through the boundaries of the administered domain.
ネットワーク保護の観点から、パケットに明示的なルートを課すすべてのノードが許可されていると想定されるような、信頼モデルが想定されています。これは、最短経路ルーティングを提供するプレーンIPと比較した場合の大幅な変更ですが、明示的なルーティング機能を提供する既存の技術とは基本的に異なりません。デフォルトでは、明示的なルーティング情報が管理対象ドメインの境界を介して漏洩しないことが期待されています。
Therefore, the data plane MUST NOT expose any source-routing information when a packet leaves the trusted domain. Special care will be required for the existing data planes like MPLS, especially for the inter-provider scenario where a third-party provider may push MPLS labels corresponding to a SPRING header anywhere in the stack. The architecture document MUST analyze the exact security considerations of such a scenario.
したがって、データプレーンは、パケットが信頼できるドメインを離れるときに、ソースルーティング情報を公開してはなりません（MUST NOT）。 MPLSなどの既存のデータプレーン、特にサードパーティプロバイダーがSPRINGヘッダーに対応するMPLSラベルをスタック内の任意の場所にプッシュする可能性があるプロバイダー間シナリオでは、特別な注意が必要です。アーキテクチャドキュメントは、そのようなシナリオの正確なセキュリティの考慮事項を分析する必要があります。
Filtering routing information is typically performed in the control plane, but an additional filtering in the forwarding plane is also required. In SPRING, as there is no control plane (related to source-routed paths) between the source and the midpoints, filtering in the control plane is not possible (or not required, depending on the point of view). Filtering MUST be performed on the forwarding plane on the boundaries and MAY require looking at multiple labels or instructions.
ルーティング情報のフィルタリングは通常、コントロールプレーンで実行されますが、転送プレーンでの追加のフィルタリングも必要です。 SPRINGでは、ソースと中間点の間に（ソースルートパスに関連する）コントロールプレーンがないため、コントロールプレーンでのフィルタリングは不可能です（または観点によっては必要ありません）。フィルタリングは境界のフォワーディングプレーンで実行する必要があり、複数のラベルまたは指示を確認する必要がある場合があります。
For the MPLS data plane, this is not a new requirement as the existing MPLS architecture already allows such source routing by stacking multiple labels. For security protection, Section 2.4 of [RFC4381] and Section 8.2 of [RFC5920] already call for the filtering of MPLS packets on trust boundaries.
MPLSデータプレーンの場合、これは新しい要件ではありません。既存のMPLSアーキテクチャでは、複数のラベルをスタックすることでこのようなソースルーティングがすでに許可されているためです。セキュリティ保護のため、[RFC4381]のセクション2.4および[RFC5920]のセクション8.2は、信頼境界でのMPLSパケットのフィルタリングをすでに要求しています。
If all MPLS labels are filtered at domain boundaries, then SPRING does not introduce any change. If only a subset of labels are filtered, then SPRING introduces a change since the border router is expected to determine which information (e.g., labels) is filtered, while the border router is not the originator of these label advertisements.
すべてのMPLSラベルがドメイン境界でフィルタリングされる場合、SPRINGは変更を導入しません。ラベルのサブセットのみがフィルタリングされる場合、ボーダールータはこれらのラベルアドバタイズメントの発信元ではなく、フィルタリングされる情報（ラベルなど）をボーダールータが決定することが予想されるため、SPRINGは変更を導入します。
As the SPRING architecture must be based on a clear trust domain, mechanisms allowing the authentication and validation of the source-routing information must be evaluated by the SPRING architecture in order to prevent any form of attack or unwanted source-routing information manipulation.
SPRINGアーキテクチャは明確な信頼ドメインに基づいている必要があるため、攻撃や不要なソースルーティング情報の操作を防ぐために、ソースルーティング情報の認証と検証を可能にするメカニズムをSPRINGアーキテクチャで評価する必要があります。
Data-plane security considerations MUST be addressed in each document related to the SPRING data plane (i.e., MPLS and IPv6).
データプレーンのセキュリティに関する考慮事項は、SPRINGデータプレーンに関連する各ドキュメント（MPLSやIPv6など）で対処する必要があります。
The IPv6 data plane proposes the use of a cryptographic signature of the source-routed path, which would ease this configuration. This is indeed needed more for the IPv6 data plane, which is end to end in nature, compared to the MPLS data plane, which is typically restricted to a controlled and trusted zone.
IPv6データプレーンは、この構成を容易にするソースルートパスの暗号化署名の使用を提案します。これは、通常、制御され信頼されたゾーンに制限されるMPLSデータプレーンと比較して、本質的にエンドツーエンドのIPv6データプレーンに必要です。
In the forwarding plane, data-plane extension documents MUST address the security implications of the required change.
フォワーディングプレーンでは、データプレーン拡張ドキュメントは、必要な変更のセキュリティへの影響に対処する必要があります。
In terms of privacy, SPRING does not propose change in terms of encryption. Each data plane may or may not provide existing or future encryption capability.
プライバシーの観点から、SPRINGは暗号化に関する変更を提案していません。各データプレーンは、既存または将来の暗号化機能を提供する場合と提供しない場合があります。
To build the source-routing information in the packet, a node in the SPRING architecture will require learning information from a control layer. As this control layer will be in charge of programming forwarding instructions, an attacker taking over this component may also manipulate the traffic path. Any control protocol used in the SPRING architecture SHOULD provide security mechanisms or design to protect against such a control-layer attacker. Control-plane security considerations MUST be addressed in each document related to the SPRING control plane.
パケット内のソースルーティング情報を構築するには、SPRINGアーキテクチャのノードがコントロールレイヤーから情報を学習する必要があります。この制御層は転送命令のプログラミングを担当するため、このコンポーネントを乗っ取った攻撃者もトラフィックパスを操作する可能性があります。 SPRINGアーキテクチャで使用されるすべての制御プロトコルは、そのような制御層の攻撃者から保護するためのセキュリティメカニズムまたは設計を提供する必要があります（SHOULD）。コントロールプレーンのセキュリティに関する考慮事項は、SPRINGコントロールプレーンに関連する各ドキュメントで対処する必要があります。
The SPRING WG MUST define Operations, Administration, and Maintenance (OAM) procedures applicable to SPRING-enabled networks.
SPRING WGは、SPRING対応ネットワークに適用可能な運用、管理、および保守（OAM）手順を定義する必要があります。
In SPRING networks, the path the packet takes is encoded in the header. SPRING architecture MUST include the necessary OAM mechanisms in order for the network operator to validate the effectiveness of a path as well as to check and monitor its liveness and performance. Moreover, in SPRING architecture, a path may be defined in the forwarding layer (in both MPLS and IPv6 data planes) or as a service path (formed by a set of service instances). The network operator MUST be capable to monitor, control, and manage paths (both network and service based) using OAM procedures.
SPRINGネットワークでは、パケットがたどるパスはヘッダーにエンコードされます。 SPRINGアーキテクチャには、ネットワークオペレーターがパスの有効性を検証し、パスの活性とパフォーマンスをチェックおよび監視するために必要なOAMメカニズムを含める必要があります。さらに、SPRINGアーキテクチャでは、パスは（MPLSとIPv6の両方のデータプレーンで）転送層で定義するか、（サービスインスタンスのセットによって形成される）サービスパスとして定義できます。ネットワークオペレーターは、OAM手順を使用して（ネットワークとサービスの両方に基づく）パスを監視、制御、および管理できる必要があります。
OAM use cases and requirements are detailed in [OAM-USE] and [SR-OAM].
OAMの使用例と要件については、[OAM-USE]と[SR-OAM]で詳しく説明しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[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] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、Ed。およびY. Rekhter編、「自動検出とシグナリングにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<http://www.rfc-editor.org/ info / rfc4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]ラッセール、M。、エド。およびV. Kompella編、「Label Distribution Protocol（LDP）Signalingを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<http://www.rfc-editor.org/ info / rfc4762>。
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <http://www.rfc-editor.org/info/rfc6624>.
[RFC6624] Kompella、K.、Kothari、B。、およびR. Cherukuri、「自動検出とシグナリングにBGPを使用するレイヤ2仮想プライベートネットワーク」、RFC 6624、DOI 10.17487 / RFC6624、2012年5月、<http：// www.rfc-editor.org/info/rfc6624>。
[ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", Work in Progress, draft-ietf-idr-add-paths-14, April 2016.
[パスの追加] Walton、D.、Retana、A.、Chen、E.、J。Scudder、「BGPでの複数パスのアドバタイズ」、Work in Progress、draft-ietf-idr-add-paths-14、 2016年4月。
[OAM-USE] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Dataplane Monitoring System", Work in Progress, draft-ietf-spring-oam-usecase-03, April 2016.
[OAM-USE] Geib、R.、Ed。、Filsfils、C.、Pignataro、C.、Ed。、and N. Kumar、 "A Scalable and Topology-Aware MPLS Dataplane Monitoring System"、Work in Progress、draft- ietf-spring-oam-usecase-03、2016年4月。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <http://www.rfc-editor.org/info/rfc4381>.
[RFC4381] Behringer、M。、「BGP / MPLS IP仮想プライベートネットワーク（VPN）のセキュリティの分析」、RFC 4381、DOI 10.17487 / RFC4381、2006年2月、<http://www.rfc-editor.org/ info / rfc4381>。
[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>。
[SPRING-RESIL] Francois, P., Filsfils, C., Decraene, B., and R. Shakir, "Use-cases for Resiliency in SPRING", Work in Progress, draft-ietf-spring-resiliency-use-cases-03, April 2016.
[SPRING-RESIL] Francois、P.、Filsfils、C.、Decraene、B。、およびR. Shakir、「SPRINGにおける回復力の使用例」、作業中、draft-ietf-spring-resiliency-use-cases 2016年4月3日。
[SR-BGP-EPE] Filsfils, C., Ed., Previdi, S., Ed., Ginsburg, D., and D. Afanasiev, "Segment Routing Centralized BGP Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-01, March 2016.
[SR-BGP-EPE] Filsfils、C.、Ed。、Previdi、S.、Ed。、Ginsburg、D。、およびD. Afanasiev、「Segment Routing Centralized BGP Peer Engineering」、Work in Progress、draft-ietf- spring-segment-routing-central-epe-01、2016年3月。
[SR-OAM] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., and S. Litkowski, "OAM Requirements for Segment Routing Network", Work in Progress, draft-ietf-spring-sr-oam-requirement-01, December 2015.
[SR-OAM] Kumar、N.、Pignataro、C.、Akiya、N.、Geib、R.、Mirsky、G。、およびS. Litkowski、「セグメントルーティングネットワークのOAM要件」、作業中、ドラフト- ietf-spring-sr-oam-requirement-01、2015年12月。
[SRH] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-01, March 2016.
[SRH] Previdi、S.、Filsfils、C.、Field、B.、Leung、I.、Linkova、J.、Kosugi、T.、Vyncke、E。、およびD. Lebrun、「IPv6セグメントルーティングヘッダー（SRH ） "、進行中の作業、draft-ietf-6man-segment-routing-header-01、2016年3月。
[STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-14, March 2016.
[STATEFUL-PCE] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「ステートフルPCEのPCEP拡張機能」、作業中、draft-ietf-pce-stateful-pce-14、3月2016。
Acknowledgements
謝辞
The authors would like to thank Yakov Rekhter for his contribution to this document.
著者は、この文書への貢献に対してYakov Rekhterに感謝します。
Contributors
貢献者
The following individuals substantially contributed to the content of this document:
次の個人は、このドキュメントの内容に大きく貢献しました。
Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Ruediger Geib Deutsche Telekom Heinrich Hertz Str。3-7ダルムシュタット64295ドイツ
Email: Ruediger.Geib@telekom.de
Robert Raszuk Mirantis Inc. 615 National Ave. 94043 Mountain View, CA United States
Robert Raszuk Mirantis Inc. 615 National Ave. 94043 Mountain View、CAアメリカ合衆国
Email: robert@raszuk.net
Authors' Addresses
著者のアドレス
Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
Stefano Previdi（編集者）Cisco Systems、Inc. Via Del Serafico、200 Rome 00142 Italy
Email: sprevidi@cisco.com
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com Bruno Decraene Orange France
メール：cfilsfil@cisco.com Bruno Decraene Orange France
Email: bruno.decraene@orange.com
Stephane Litkowski Orange France
ステファンリトコウスキーオレンジフランス
Email: stephane.litkowski@orange.com
Martin Horneffer Deutsche Telekom Muenster 48153 Germany
Martin Horneffer Deutsche Telekom Muenster 48153ドイツ
Email: Martin.Horneffer@telekom.de
Rob Shakir Jive Communications, Inc. 1275 West 1600 North, Suite 100 Orem, UT 84057 United States
Rob Shakir Jive Communications、Inc. 1275 West 1600 North、Suite 100 Orem、UT 84057アメリカ合衆国
Email: rjs@rob.sh