[要約] RFC 7926は、トラフィックエンジニアリングされたネットワーク間の情報交換の問題とアーキテクチャに関するものです。その目的は、異なるネットワーク間でのトラフィックエンジニアリング情報の効果的な共有を実現することです。
Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 7926 J. Drake
BCP: 206 Juniper Networks
Category: Best Current Practice N. Bitar
ISSN: 2070-1721 Nokia
G. Swallow
Cisco Systems, Inc.
D. Ceccarelli
Ericsson
X. Zhang
Huawei
July 2016
Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
相互接続されたトラフィックエンジニアリングネットワーク間の情報交換のための問題ステートメントとアーキテクチャ
Abstract
概要
In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.
トラフィックエンジニアリング（TE）システムでは、送信元から宛先への1つ以上のネットワーク全体に一連の制約（帯域幅など）を設定して、エンドツーエンドのTEパスを確立することが望ましい場合があります。 TE情報は、TEパスを選択するプロセスで使用されるノードおよびTEリンクに関するデータです。 TE情報は通常、ネットワーク内でのみ利用可能です。このようなTE情報の可視領域をドメインと呼びます。ドメインの例としては、IGPエリアや自律システムなどがあります。
In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.
接続された一連のネットワークを介してTEパスを確立する可能性を判断するには、各ネットワークに関する一定量のTE情報を利用できるようにする必要があります。これは、各ネットワーク内で利用可能なTE情報の完全なセットである必要はありませんが、TE接続を提供する可能性を表す必要があります。 TE情報のこのサブセットは、TE到達可能性情報と呼ばれます。
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.
このドキュメントでは、エンドツーエンドのTEパスの確立をサポートする相互接続されたTEネットワーク間でのTE情報の交換に関する問題ステートメントを示し、この問題ステートメントを満たすための現在のベストプラクティスアーキテクチャについて説明します。このドキュメントで説明する理由により、この作業は、TEの到達可能性を決定する単純なTE制約と情報に限定されます。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 7841のセクション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/rfc7926.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7926で入手できます。
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 ....................................................5
1.1. Terminology ................................................6
1.1.1. TE Paths and TE Connections .........................6
1.1.2. TE Metrics and TE Attributes ........................6
1.1.3. TE Reachability .....................................7
1.1.4. Domain ..............................................7
1.1.5. Server Network ......................................7
1.1.6. Client Network ......................................7
1.1.7. Aggregation .........................................7
1.1.8. Abstraction .........................................8
1.1.9. Abstract Link .......................................8
1.1.10. Abstract Node or Virtual Node ......................8
1.1.11. Abstraction Layer Network ..........................9
2. Overview of Use Cases ...........................................9
2.1. Peer Networks ..............................................9
2.2. Client-Server Networks ....................................11
2.3. Dual-Homing ...............................................15
2.4. Requesting Connectivity ...................................15
2.4.1. Discovering Server Network Information .............17
3. Problem Statement ..............................................18
3.1. Policy and Filters ........................................18
3.2. Confidentiality ...........................................19
3.3. Information Overload ......................................19
3.4. Issues of Information Churn ...............................20
3.5. Issues of Aggregation .....................................21
4. Architecture ...................................................22
4.1. TE Reachability ...........................................22
4.2. Abstraction, Not Aggregation ..............................22
4.2.1. Abstract Links .....................................23
4.2.2. The Abstraction Layer Network ......................23
4.2.3. Abstraction in Client-Server Networks ..............26
4.2.4. Abstraction in Peer Networks .......................32
4.3. Considerations for Dynamic Abstraction ....................34
4.4. Requirements for Advertising Links and Nodes ..............35
4.5. Addressing Considerations .................................36
5. Building on Existing Protocols .................................36
5.1. BGP-LS ....................................................37
5.2. IGPs ......................................................37
5.3. RSVP-TE ...................................................37
5.4. Notes on a Solution .......................................37
6. Application of the Architecture to Optical Domains and
Networks .......................................................39
7. Application of the Architecture to the User-Network Interface ..44
8. Application of the Architecture to L3VPN Multi-AS Environments .46
9. Scoping Future Work ............................................47
9.1. Limiting Scope to Only Part of the Internet ...............47
9.2. Working with "Related" Domains ............................47
9.3. Not Finding Optimal Paths in All Situations ...............48
9.4. Sanity and Scaling ........................................48
10. Manageability Considerations ..................................48
10.1. Managing the Abstraction Layer Network ...................49
10.2. Managing Interactions of Abstraction Layer and
Client Networks ..........................................49
10.3. Managing Interactions of Abstraction Layer and
Server Networks ..........................................50
11. Security Considerations .......................................51
12. Informative References ........................................52
Appendix A. Existing Work .........................................58
A.1. Per-Domain Path Computation ...............................58
A.2. Crankback .................................................59
A.3. Path Computation Element ..................................59
A.4. GMPLS UNI and Overlay Networks ............................61
A.5. Layer 1 VPN ...............................................62
A.6. Policy and Link Advertisement .............................62
Appendix B. Additional Features ...................................63
B.1. Macro Shared Risk Link Groups .............................63
B.2. Mutual Exclusivity ........................................64
Acknowledgements ..................................................65
Contributors ......................................................66
Authors' Addresses ................................................67
Traffic-Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS [RFC3945] offer a way to establish paths through a network in a controlled way that reserves network resources on specified links. TE paths are computed by examining the Traffic Engineering Database (TED) and selecting a sequence of links and nodes that are capable of meeting the requirements of the path to be established. The TED is constructed from information distributed by the Interior Gateway Protocol (IGP) running in the network -- for example, OSPF-TE [RFC3630] or ISIS-TE [RFC5305].
MPLS-TE [RFC2702]やGMPLS [RFC3945]などのトラフィックエンジニアリング（TE）システムは、指定されたリンク上のネットワークリソースを予約する制御された方法でネットワークを介してパスを確立する方法を提供します。 TEパスは、トラフィックエンジニアリングデータベース（TED）を調べて、確立するパスの要件を満たすことができる一連のリンクとノードを選択することによって計算されます。 TEDは、OSPF-TE [RFC3630]やISIS-TE [RFC5305]など、ネットワークで実行されているInterior Gateway Protocol（IGP）によって配布された情報から構築されます。
It is sometimes desirable to establish an end-to-end TE path that crosses more than one network or administrative domain as described in [RFC4105] and [RFC4216]. In these cases, the availability of TE information is usually limited to within each network. Such networks are often referred to as domains [RFC4726], and we adopt that definition in this document; viz.,
[RFC4105]と[RFC4216]で説明されているように、複数のネットワークまたは管理ドメインを横断するエンドツーエンドTEパスを確立することが望ましい場合があります。これらの場合、TE情報の可用性は通常、各ネットワーク内に制限されます。このようなネットワークはしばしばドメインと呼ばれ[RFC4726]、このドキュメントではその定義を採用しています。つまり、
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems (ASes).
このドキュメントでは、ドメインは、アドレス管理またはパス計算の責任という共通の領域内のネットワーク要素のコレクションと見なされます。このようなドメインの例には、IGPエリアや自律システム（AS）などがあります。
In order to determine the potential to establish a TE path through a series of connected domains and to choose the appropriate domain connection points through which to route a path, it is necessary to have available a certain amount of TE information about each domain. This need not be the full set of TE information available within each domain but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. The TE reachability information can be exchanged between domains based on the information gathered from the local routing protocol, filtered by configured policy, or statically configured.
一連の接続されたドメインを介してTEパスを確立する可能性を判断し、パスをルーティングする適切なドメイン接続ポイントを選択するには、各ドメインに関する一定量のTE情報を利用できる必要があります。これは、各ドメイン内で利用可能なTE情報の完全なセットである必要はありませんが、TE接続を提供する可能性を表す必要があります。 TE情報のこのサブセットは、TE到達可能性情報と呼ばれます。 TEの到達可能性情報は、ローカルルーティングプロトコルから収集した情報に基づいてドメイン間で交換したり、設定済みのポリシーでフィルタリングしたり、静的に設定したりできます。
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. The scope of this document is limited to the simple TE constraints and information (such as TE metrics, hop count, bandwidth, delay, shared risk) necessary to determine TE reachability: discussion of multiple additional constraints that might qualify the reachability can significantly complicate aggregation of information and the stability of the mechanism used to present potential connectivity, as is explained in the body of this document.
このドキュメントでは、エンドツーエンドのTEパスの確立をサポートする相互接続されたTEネットワーク間でのTE情報の交換に関する問題ステートメントを示し、この問題ステートメントを満たすための現在のベストプラクティスアーキテクチャについて説明します。このドキュメントの範囲は、TEの到達可能性を決定するために必要な単純なTE制約と情報（TEメトリック、ホップカウント、帯域幅、遅延、共有リスクなど）に限定されます。このドキュメントの本文で説明されているように、接続の可能性を示すために使用されるメカニズムと情報の安定性。
Appendix A summarizes relevant existing work that is used to route TE paths across multiple domains.
付録Aは、複数のドメイン間でTEパスをルーティングするために使用される関連する既存の作業をまとめたものです。
This section introduces some key terms that need to be understood to arrive at a common understanding of the problem space. Some of the terms are defined in more detail in the sections that follow (in which case forward pointers are provided), and some terms are taken from definitions that already exist in other RFCs (in which case references are given, but no apology is made for repeating or summarizing the definitions here).
このセクションでは、問題空間の一般的な理解に到達するために理解する必要があるいくつかの重要な用語を紹介します。一部の用語は次のセクションでより詳細に定義されており（その場合、前方ポインターが提供されます）、一部の用語は、他のRFCに既に存在する定義から採用されています（この場合、参照が提供されますが、謝罪は行われません）ここで定義を繰り返すか要約するため）。
A TE connection is a Label Switched Path (LSP) through an MPLS-TE or GMPLS network that directs traffic along a particular path (the TE path) in order to provide a specific service such as bandwidth guarantee, separation of traffic, or resilience between a well-known pair of end points.
TE接続は、MPLS-TEまたはGMPLSネットワークを介したラベルスイッチドパス（LSP）であり、帯域幅保証、トラフィックの分離、相互間の回復力などの特定のサービスを提供するために、特定のパス（TEパス）に沿ってトラフィックを送信しますよく知られたエンドポイントのペア。
"TE metrics" and "TE attributes" are terms applied to parameters of links (and possibly nodes) in a network that is traversed by TE connections. The TE metrics and TE attributes are used by path computation algorithms to select the TE paths that the TE connections traverse. A TE metric is a quantifiable value (including measured characteristics) describing some property of a link or node that can be used as part of TE routing or planning, while a TE attribute is a wider term (i.e., including the concept of a TE metric) that refers to any property or characteristic of a link or node that can be used as part of TE routing or planning. Thus, the delay introduced by transmission of a packet on a link is an example of a TE metric, while the geographic location of a router is an example of a more general attribute.
「TEメトリック」および「TE属性」は、TE接続が通過するネットワーク内のリンク（および場合によってはノード）のパラメーターに適用される用語です。 TEメトリックおよびTE属性は、TE接続が通過するTEパスを選択するためにパス計算アルゴリズムによって使用されます。 TEメトリックは、TEルーティングまたは計画の一部として使用できるリンクまたはノードのいくつかのプロパティを説明する定量化可能な値（測定された特性を含む）であり、TE属性はより広い用語です（つまり、TEメトリックの概念を含みます） ）これは、TEルーティングまたは計画の一部として使用できるリンクまたはノードのプロパティまたは特性を指します。したがって、リンク上のパケットの送信によって導入される遅延はTEメトリックの例であり、ルータの地理的位置はより一般的な属性の例です。
Provisioning a TE connection through a network may result in dynamic changes to the TE metrics and TE attributes of the links and nodes in the network.
ネットワークを介してTE接続をプロビジョニングすると、ネットワーク内のリンクとノードのTEメトリックとTE属性が動的に変化する可能性があります。
These terms are also sometimes used to describe the end-to-end characteristics of a TE connection and can be derived according to a formula from the TE metrics and TE attributes of the links and nodes that the TE connection traverses. Thus, for example, the end-to-end delay for a TE connection is usually considered to be the sum of the delay on each link that the connection traverses.
これらの用語は、TE接続のエンドツーエンドの特性を説明するために使用されることもあり、TEメトリックと、TE接続が通過するリンクおよびノードのTE属性からの式に従って導出できます。したがって、たとえば、TE接続のエンドツーエンドの遅延は、通常、接続が通過する各リンクの遅延の合計と見なされます。
In an IP network, reachability is the ability to deliver a packet to a specific address or prefix, i.e., the existence of an IP path to that address or prefix. TE reachability is the ability to reach a specific address along a TE path. More specifically, it is the ability to establish a TE connection in an MPLS-TE or GMPLS sense. Thus, we talk about TE reachability as the potential of providing TE connectivity.
IPネットワークでは、到達可能性とは、特定のアドレスまたはプレフィックスにパケットを配信する機能です。つまり、そのアドレスまたはプレフィックスへのIPパスが存在します。 TE到達可能性は、TEパスに沿って特定のアドレスに到達する機能です。具体的には、MPLS-TEまたはGMPLSの意味でTE接続を確立する機能です。したがって、TEの接続性を提供する可能性として、TEの到達可能性について説明します。
TE reachability may be unqualified (there is a TE path, but no information about available resources or other constraints is supplied); this is helpful especially in determining a path to a destination that lies in an unknown domain or that may be qualified by TE attributes and TE metrics such as hop count, available bandwidth, delay, and shared risk.
TEの到達可能性が不適格である可能性があります（TEパスはありますが、利用可能なリソースやその他の制約に関する情報が提供されていません）;これは、不明なドメインにある、またはホップカウント、使用可能な帯域幅、遅延、共有リスクなどのTE属性とTEメトリックによって修飾される可能性がある宛先へのパスを決定する場合に特に役立ちます。
As defined in [RFC4726], a domain is any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and ASes.
[RFC4726]で定義されているように、ドメインは、アドレス管理またはパス計算の責任の一般的な範囲内のネットワーク要素のコレクションです。そのようなドメインの例には、IGPエリアとASが含まれます。
A Server Network is a network that provides connectivity for another network (the Client Network) in a client-server relationship. A Server Network is sometimes referred to as an underlay network.
サーバーネットワークは、クライアントとサーバーの関係で別のネットワーク（クライアントネットワーク）に接続を提供するネットワークです。サーバーネットワークは、アンダーレイネットワークと呼ばれることもあります。
A Client Network is a network that uses the connectivity provided by a Server Network. A Client Network is sometimes referred to as an overlay network.
クライアントネットワークは、サーバーネットワークによって提供される接続を使用するネットワークです。クライアントネットワークは、オーバーレイネットワークと呼ばれることもあります。
The concept of aggregation is discussed in Section 3.5. In aggregation, multiple network resources from a domain are represented outside the domain as a single entity. Thus, multiple links and nodes forming a TE connection may be represented as a single link, or a collection of nodes and links (perhaps the whole domain) may be represented as a single node with its attachment links.
集計の概念については、セクション3.5で説明します。集約では、ドメインからの複数のネットワークリソースは、ドメインの外部で単一のエンティティとして表されます。したがって、TE接続を形成する複数のリンクとノードは単一のリンクとして表されるか、ノードとリンクのコレクション（おそらくドメイン全体）は、その接続リンクを持つ単一のノードとして表されます。
Section 4.2 introduces the concept of abstraction and distinguishes it from aggregation. Abstraction may be viewed as "policy-based aggregation" where the policies are applied to overcome the issues with aggregation as identified in Section 3 of this document.
セクション4.2では、抽象化の概念を紹介し、それを集約と区別します。このドキュメントのセクション3で特定されているように、抽象化は「ポリシーベースの集約」と見なされ、集約に関する問題を克服するためにポリシーが適用されます。
Abstraction is the process of applying policy to the available TE information within a domain, to produce selective information that represents the potential ability to connect across the domain. Thus, abstraction does not necessarily offer all possible connectivity options, but it presents a general view of potential connectivity according to the policies that determine how the domain's administrator wants to allow the domain resources to be used.
抽象化は、ドメイン内で利用可能なTE情報にポリシーを適用して、ドメイン全体に接続する潜在的な能力を表す選択的な情報を生成するプロセスです。したがって、抽象化は必ずしもすべての可能な接続オプションを提供するわけではありませんが、ドメインの管理者がドメインリソースの使用を許可する方法を決定するポリシーに従って、潜在的な接続の一般的なビューを示します。
An abstract link is the representation of the characteristics of a path between two nodes in a domain produced by abstraction. The abstract link is advertised outside that domain as a TE link for use in signaling in other domains. Thus, an abstract link represents the potential to connect between a pair of nodes.
抽象リンクは、抽象化によって生成されたドメイン内の2つのノード間のパスの特性の表現です。抽象リンクは、他のドメインでのシグナリングに使用するTEリンクとして、そのドメインの外部でアドバタイズされます。したがって、抽象リンクは、ノードのペア間を接続する可能性を表します。
More details regarding abstract links are provided in Section 4.2.1.
抽象リンクに関する詳細は、セクション4.2.1を参照してください。
An abstract node was defined in [RFC3209] as a group of nodes whose internal topology is opaque to an ingress node of the LSP. More generally, an abstract node is the representation as a single node in a TE topology of some or all of the resources of one or more nodes and the links that connect them. An abstract node may be advertised outside the domain as a TE node for use in path computation and signaling in other domains.
抽象ノードは、内部トポロジーがLSPの入力ノードに対して不透明であるノードのグループとして[RFC3209]で定義されました。より一般的には、抽象ノードは、1つ以上のノードとそれらを接続するリンクの一部またはすべてのリソースのTEトポロジにおける単一ノードとしての表現です。抽象ノードは、他のドメインでのパス計算とシグナリングに使用するために、TEノードとしてドメインの外側でアドバタイズされます。
The term "virtual node" has typically been applied to the aggregation of a domain (that is, a collection of nodes and links that operate as a single administrative entity for TE purposes) into a single entity that is treated as a node for the purposes of end-to-end traffic engineering. Virtual nodes are often considered a way to present islands of single-vendor equipment in an optical network.
「仮想ノード」という用語は、通常、ドメイン（TEの目的で単一の管理エンティティとして動作するノードとリンクのコレクション）を、目的のノードとして扱われる単一のエンティティに集約することに適用されています。エンドツーエンドのトラフィックエンジニアリング。仮想ノードは、多くの場合、光ネットワークで単一ベンダーの機器の島を提示する方法と考えられています。
Sections 3.5 and 4.2.2.1 provide more information about the uses and issues of abstract nodes and virtual nodes.
セクション3.5および4.2.2.1では、抽象ノードと仮想ノードの使用法と問題について詳しく説明しています。
The abstraction layer network is introduced in Section 4.2.2. It may be seen as a brokerage-layer network between one or more server networks and one or more client networks. The abstraction layer network is the collection of abstract links that provide potential connectivity across the server networks and on which path computation can be performed to determine edge-to-edge paths that provide connectivity as links in the client network.
抽象化層ネットワークは、セクション4.2.2で紹介されています。これは、1つ以上のサーバーネットワークと1つ以上のクライアントネットワークの間の仲介層ネットワークと見なすことができます。抽象化レイヤーネットワークは、サーバーネットワーク全体に潜在的な接続を提供する抽象リンクの集合であり、クライアントネットワークでリンクとして接続を提供するエッジツーエッジパスを決定するためにパス計算を実行できます。
In the simplest case, the abstraction layer network is just a set of edge-to-edge connections (i.e., abstract links), but to make the use of server network resources more flexible, the abstract links might not all extend from edge to edge but might offer connectivity between server network nodes to form a more complex network.
最も単純なケースでは、抽象化層ネットワークは単なるエッジツーエッジ接続（つまり、抽象リンク）ですが、サーバーネットワークリソースの使用をより柔軟にするために、抽象リンクがすべてエッジからエッジに拡張されない場合がありますしかし、サーバーネットワークノード間の接続を提供して、より複雑なネットワークを形成する場合があります。
The peer network use case can be most simply illustrated by the example in Figure 1. A TE path is required between the source (Src) and destination (Dst), which are located in different domains. There are two points of interconnection between the domains, and selecting the wrong point of interconnection can lead to a suboptimal path or even fail to make a path available. Note that peer networks are assumed to have the same technology type -- that is, the same "switching capability", to use the term from GMPLS [RFC3945].
ピアネットワークの使用例は、図1の例で最も簡単に説明できます。送信元（Src）と宛先（Dst）の間には、異なるドメインにあるTEパスが必要です。ドメイン間の相互接続には2つのポイントがあり、相互接続の間違ったポイントを選択すると、パスが最適でなくなるか、パスを使用できない場合があります。 GMPLS [RFC3945]の用語を使用するために、ピアネットワークは同じテクノロジータイプ、つまり同じ「スイッチング機能」を持っていると想定されていることに注意してください。
-------------- --------------
| Domain A | x1 | Domain Z |
| ----- +----+ ----- |
| | Src | +----+ | Dst | |
| ----- | x2 | ----- |
-------------- --------------
Figure 1: Peer Networks
図1：ピアネットワーク
For example, when Domain A attempts to select a path, it may determine that adequate bandwidth is available from Src through both interconnection points x1 and x2. It may pick the path through x1 for local policy reasons: perhaps the TE metric is smaller. However, if there is no connectivity in Domain Z from x1 to Dst, the path cannot be established. Techniques such as crankback may be used to alleviate this situation, but such techniques do not lead to rapid setup or guaranteed optimality. Furthermore, RSVP signaling creates state in the network that is immediately removed by the crankback procedure. Frequent events of this kind will impact scalability in a non-deterministic manner. More details regarding crankback can be found in Appendix A.2.
たとえば、ドメインAがパスを選択しようとすると、Srcから相互接続ポイントx1とx2の両方で適切な帯域幅が利用可能であると判断される場合があります。ローカルポリシーの理由により、x1を通るパスを選択する場合があります。おそらくTEメトリックが小さいためです。ただし、ドメインZにx1からDstへの接続がない場合、パスを確立できません。クランクバックなどの手法を使用してこの状況を緩和することもできますが、そのような手法は迅速なセットアップや最適性の保証にはつながりません。さらに、RSVPシグナリングは、ネットワークに状態を作成します。この状態は、クランクバック手順によってすぐに削除されます。この種の頻繁なイベントは、非決定的な方法でスケーラビリティに影響を与えます。クランクバックの詳細については、付録A.2を参照してください。
There are countless more complicated examples of the problem of peer networks. Figure 2 shows the case where there is a simple mesh of domains. Clearly, to find a TE path from Src to Dst, Domain A must not select a path leaving through interconnect x1, since Domain B has no connectivity to Domain Z. Furthermore, in deciding whether to select interconnection x2 (through Domain C) or interconnection x3 through Domain D, Domain A must be sensitive to the TE connectivity available through each of Domains C and D, as well as the TE connectivity from each of interconnections x4 and x5 to Dst within Domain Z. The problem may be further complicated when the source domain does not know in which domain the destination node is located, since the choice of a domain path clearly depends on the knowledge of the destination domain: this issue is obviously mitigated in IP networks by inter-domain routing [RFC4271].
ピアネットワークの問題には、さらに複雑な例が無数にあります。図2は、ドメインの単純なメッシュがある場合を示しています。明らかに、SrcからDstへのTEパスを見つけるために、ドメインBはドメインZに接続していないため、ドメインAは相互接続x1を経由するパスを選択してはなりません。さらに、相互接続x2（ドメインCを介する）または相互接続を選択するかどうかを決定する際にドメインAは、ドメインDを介してx3、ドメインCおよびDのそれぞれを介して利用可能なTE接続、およびドメインZ内の相互接続x4およびx5からDstへのTE接続に敏感でなければなりません。問題がさらに複雑になる場合があります。ドメインパスの選択は宛先ドメインの知識に明らかに依存するため、ソースドメインは宛先ノードがどのドメインにあるかを認識していません。この問題は、ドメイン間ルーティング[RFC4271]によってIPネットワークで明らかに軽減されます。
Of course, many network interconnection scenarios are going to be a combination of the situations expressed in these two examples. There may be a mesh of domains, and the domains may have multiple points of interconnection.
もちろん、多くのネットワーク相互接続シナリオは、これら2つの例で表された状況の組み合わせになります。ドメインのメッシュが存在する場合があり、ドメインには複数の相互接続ポイントがある場合があります。
--------------
| Domain B |
| |
| |
/--------------
/
/x1
--------------/ --------------
| Domain A | | Domain Z |
| | -------------- | |
| ----- | x2| Domain C | x4| ----- |
| | Src | +---+ +---+ | Dst | |
| ----- | | | | ----- |
| | -------------- | |
--------------\ /--------------
\x3 /
\ /
\ /x5
\--------------/
| Domain D |
| |
| |
--------------
Figure 2: Peer Networks in a Mesh
図2：メッシュ内のピアネットワーク
Two major classes of use case relate to the client-server relationship between networks. These use cases have sometimes been referred to as overlay networks. In both of these classes of use case, the client and server networks may have the same switching capability, or they may be built from nodes and links that have different technology types in the client and server networks.
ユースケースの2つの主要なクラスは、ネットワーク間のクライアント/サーバー関係に関連しています。これらの使用例は、オーバーレイネットワークと呼ばれることもあります。これらのクラスの使用例の両方で、クライアントとサーバーのネットワークは同じスイッチング機能を備えているか、クライアントとサーバーのネットワークで異なるテクノロジータイプを持つノードとリンクから構築されている場合があります。
The first group of use cases, shown in Figure 3, occurs when domains belonging to one network are connected by a domain belonging to another network. In this scenario, once connectivity is formed across the lower-layer network, the domains of the upper-layer network can be merged into a single domain by running IGP adjacencies and by treating the server-network-layer connectivity as links in the higher-layer network. The TE relationship between the domains (higher and lower layers) in this case is reduced to determining what server network connectivity to establish, how to trigger it, how to route it in the server network, and what resources and capacity to assign within the server network layer. As the demands in the higher-layer (client) network vary, the connectivity in the server network may need to be modified. Section 2.4 explains in a little more detail how connectivity may be requested.
図3に示す最初の使用例は、あるネットワークに属するドメインが別のネットワークに属するドメインによって接続されている場合に発生します。このシナリオでは、下位層ネットワーク全体で接続が形成されると、IGP隣接関係を実行し、サーバーネットワーク層接続を上位層のリンクとして扱うことにより、上位層ネットワークのドメインを単一のドメインに結合できます。レイヤーネットワーク。この場合のドメイン（上位層と下位層）間のTE関係は、確立するサーバーネットワーク接続、トリガー方法、サーバーネットワークでのルーティング方法、サーバー内に割り当てるリソースと容量を決定するために削減されます。ネットワーク層。上位層（クライアント）ネットワークでの要求は変化するため、サーバーネットワークでの接続を変更する必要がある場合があります。セクション2.4では、接続が要求される方法についてもう少し詳しく説明します。
---------------- ----------------
| Client Network | | Client Network |
| Domain A | | Domain B |
| | | |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
----------------\ /----------------
\x1 x2/
\ /
\ /
\----------------/
| Server Network |
| Domain |
| |
----------------
Figure 3: Client-Server Networks
図3：クライアントサーバーネットワーク
The second class of use case relating to client-server networking is for Virtual Private Networks (VPNs). In this case, as opposed to the former one, it is assumed that the client network has a different address space than that of the server network, where non-overlapping IP addresses between the client and the server networks cannot be guaranteed. A simple example is shown in Figure 4. The VPN sites comprise a set of domains that are interconnected over a core domain (i.e., the provider network) that is the server network in our model.
クライアント/サーバーネットワーキングに関連する2番目の使用例は、仮想プライベートネットワーク（VPN）です。この場合、前者とは異なり、クライアントネットワークにはサーバーネットワークとは異なるアドレススペースがあり、クライアントとサーバーネットワーク間のIPアドレスが重複しないことは保証されません。簡単な例を図4に示します。VPNサイトは、モデルのサーバーネットワークであるコアドメイン（つまり、プロバイダーネットワーク）を介して相互接続された一連のドメインで構成されています。
Note that in the use cases shown in Figures 3 and 4 the client network domains may (and, in fact, probably do) operate as a single connected network.
図3および4に示す使用例では、クライアントネットワークドメインが単一の接続されたネットワークとして動作する場合があります（実際、おそらく動作します）。
-------------- --------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| | | |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
--------------\ /--------------
\x1 x2/
\ /
\ /
\---------------/
| Core Domain |
| |
| |
/---------------\
/ \
/ \
/x3 x4\
--------------/ \--------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
| | | |
-------------- --------------
Figure 4: A Virtual Private Network
図4：仮想プライベートネットワーク
Both use cases in this section become "more interesting" when combined with the use case in Section 2.1 -- that is, when the connectivity between higher-layer domains or VPN sites is provided by a sequence or mesh of lower-layer domains. Figure 5 shows how this might look in the case of a VPN.
このセクションの両方のユースケースは、セクション2.1のユースケースと組み合わせると、「より興味深い」ものになります。つまり、上位層ドメインまたはVPNサイト間の接続が、下位層ドメインのシーケンスまたはメッシュによって提供される場合です。図5は、VPNの場合の外観を示しています。
------------ ------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
------------\ /------------
\x1 x2/
\ /
\ /
\---------- ----------/
| Domain X |x5 | Domain Y |
| (core) +---+ (core) |
| | | |
| +---+ |
| |x6 | |
/---------- ----------\
/ \
/ \
/x3 x4\
------------/ \------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------
Figure 5: A VPN Supported over Multiple Server Domains
図5：複数のサーバードメインでサポートされるVPN
A further complication may be added to the client-server relationship described in Section 2.2 by considering what happens when a client network domain is attached to more than one domain in the server network or has two points of attachment to a server network domain. Figure 6 shows an example of this for a VPN.
クライアントネットワークドメインがサーバーネットワークの複数のドメインに接続されている場合、またはサーバーネットワークドメインに2つの接続ポイントがある場合に何が起こるかを検討することにより、セクション2.2で説明するクライアント/サーバー関係にさらに複雑さが加わることがあります。図6は、VPNのこの例を示しています。
------------
| Domain B |
| (VPN site) |
------------ | ----- |
| Domain A | | | Src | |
| (VPN site) | | ----- |
| | | |
------------\ -+--------+-
\x1 | |
\ x2| |x3
\ | | ------------
\--------+- -+-------- | Domain C |
| Domain X | x8 | Domain Y | x4 | (VPN site) |
| (core) +----+ (core) +----+ ----- |
| | | | | | Dst | |
| +----+ +----+ ----- |
| | x9 | | x5 | |
/---------- ----------\ ------------
/ \
/ \
/x6 x7\
------------/ \------------
| Domain D | | Domain E |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------
Figure 6: Dual-Homing in a Virtual Private Network
図6：仮想プライベートネットワークのデュアルホーミング
The relationship between domains can be entirely under the control of management processes, dynamically triggered by the client network, or some hybrid of these cases. In the management case, the server network may be asked to establish a set of LSPs to provide client network connectivity. In the dynamic case, the client network may make a request to the server network exerting a range of controls over the paths selected in the server network. This range extends from no control (i.e., a simple request for connectivity), through a set of constraints (latency, path protection, etc.), up to and including full control of the path and resources used in the server network (i.e., the use of explicit paths with label subobjects).
ドメイン間の関係は、完全に管理プロセスの制御下にあるか、クライアントネットワークによって動的にトリガーされるか、またはこれらのケースのハイブリッドになります。管理の場合、サーバーネットワークは、クライアントネットワーク接続を提供する一連のLSPを確立するように要求される場合があります。動的な場合、クライアントネットワークは、サーバーネットワークで選択されたパスに対してさまざまな制御を実行する要求をサーバーネットワークに送信します。この範囲は、制御なし（つまり、接続の単純な要求）から一連の制約（待ち時間、パス保護など）を介して、サーバーネットワークで使用されるパスとリソースの完全な制御（つまり、ラベルサブオブジェクトでの明示的なパスの使用）。
There are various models by which a server network can be asked to set up the connections that support a service provided to the client network. These requests may come from management systems, directly from the client network control plane, or through an intermediary broker such as the Virtual Network Topology Manager (VNTM) [RFC5623].
サーバーネットワークがクライアントネットワークに提供されるサービスをサポートする接続をセットアップするように要求できるさまざまなモデルがあります。これらの要求は、管理システムから直接、クライアントネットワークコントロールプレーンから、または仮想ネットワークトポロジマネージャー（VNTM）[RFC5623]などの中間ブローカーを介して送信されます。
The trigger that causes the request to the server network is also flexible. It could be that the client network discovers a pressing need for server network resources (such as the desire to provision an end-to-end connection in the client network or severe congestion on a specific path), or it might be that a planning application has considered how best to optimize traffic in the client network or how to handle a predicted traffic demand.
サーバーネットワークへの要求を引き起こすトリガーも柔軟です。クライアントネットワークがサーバーネットワークリソースの差し迫った必要性を発見した可能性があります（クライアントネットワークでエンドツーエンド接続をプロビジョニングしたい、または特定のパスで深刻な輻輳が発生したいなど）、または計画アプリケーションである可能性があります。クライアントネットワークのトラフィックを最適化する方法、または予測されるトラフィック需要を処理する方法を検討しました。
In all cases, the relationship between client and server networks is subject to policy so that server network resources are under the administrative control of the operator or the server network and are only used to support a client network in ways that the server network operator approves.
すべての場合において、クライアントネットワークとサーバーネットワーク間の関係はポリシーの対象となるため、サーバーネットワークリソースはオペレーターまたはサーバーネットワークの管理下にあり、サーバーネットワークオペレーターが承認する方法でクライアントネットワークをサポートするためにのみ使用されます。
As just noted, connectivity requests issued to a server network may include varying degrees of constraint upon the choice of path that the server network can implement.
前述のように、サーバーネットワークに発行される接続要求には、サーバーネットワークが実装できるパスの選択に対するさまざまな程度の制約が含まれる場合があります。
o "Basic provisioning" is a simple request for connectivity. The only constraints are the end points of the connection and the capacity (bandwidth) that the connection will support for the client network. In the case of some server networks, even the bandwidth component of a basic provisioning request is superfluous because the server network has no facility to vary bandwidth and can offer connectivity only at a default capacity.
o 「基本的なプロビジョニング」は、接続の単純な要求です。唯一の制約は、接続のエンドポイントと、接続がクライアントネットワークでサポートする容量（帯域幅）です。一部のサーバーネットワークの場合、サーバーネットワークには帯域幅を変更する機能がなく、デフォルトの容量でのみ接続を提供できるため、基本的なプロビジョニング要求の帯域幅コンポーネントも不要です。
o "Basic provisioning with optimization" is a service request that indicates one or more metrics that the server network must optimize in its selection of a path. Metrics may be hop count, path length, summed TE metric, jitter, delay, or any number of technology-specific constraints.
o 「最適化を伴う基本的なプロビジョニング」は、パスの選択においてサーバーネットワークが最適化する必要がある1つ以上のメトリックを示すサービスリクエストです。メトリックは、ホップカウント、パス長、合計TEメトリック、ジッター、遅延、または任意の数のテクノロジー固有の制約です。
o "Basic provisioning with optimization and constraints" enhances the optimization process to apply absolute constraints to functions of the path metrics. For example, a connection may be requested that optimizes for the shortest path but in any case requests that the end-to-end delay be less than a certain value.
o 「最適化と制約付きの基本的なプロビジョニング」は、最適化プロセスを拡張して、絶対制約をパスメトリックの関数に適用します。たとえば、最短パスを最適化する接続が要求されることがありますが、いずれの場合も、エンドツーエンドの遅延が特定の値よりも小さいことが要求されます。
Equally, optimization may be expressed in terms of the impact on the network. For example, a service may be requested in order to leave maximal flexibility to satisfy future service requests.
同様に、最適化はネットワークへの影響の観点から表現することもできます。たとえば、将来のサービス要求を満たすために最大限の柔軟性を残すために、サービスが要求される場合があります。
o "Fate diversity requests" ask the server network to provide a path that does not use any network resources (usually links and nodes) that share fate (i.e., can fail as the result of a single event) as the resources used by another connection. This allows the client network to construct protection services over the server network -- for example, by establishing links that are known to be fate diverse. The connections that have diverse paths need not share end points.
o 「運命の多様性の要求」は、別の接続で使用されるリソースとして運命を共有する（つまり、単一のイベントの結果として失敗する可能性がある）ネットワークリソース（通常はリンクとノード）を使用しないパスを提供するようにサーバーネットワークに要求します。これにより、クライアントネットワークはサーバーネットワークを介して保護サービスを構築できます。たとえば、運命が多様であることがわかっているリンクを確立することにより、多様なパスを持つ接続は、エンドポイントを共有する必要はありません。
o "Provisioning with fate sharing" is the exact opposite of fate diversity. In this case, two or more connections are requested to follow the same path in the server network. This may be requested, for example, to create a bundled or aggregated link in the client network where each component of the client-layer composite link is required to have the same server network properties (metrics, delay, etc.) and the same failure characteristics.
o 「運命の共有によるプロビジョニング」は、運命の多様性の正反対です。この場合、サーバーネットワーク内の同じパスをたどるには、2つ以上の接続が要求されます。これは、たとえば、クライアントレイヤーの複合リンクの各コンポーネントが同じサーバーネットワークプロパティ（メトリック、遅延など）と同じ障害を必要とするクライアントネットワークにバンドルまたは集約リンクを作成するために要求される場合があります。特性。
o "Concurrent provisioning" enables the interrelated connection requests described in the previous two bullets to be enacted through a single, compound service request.
o 「同時プロビジョニング」により、前の2つの箇条書きで説明した相互に関連する接続リクエストを、単一の複合サービスリクエストを通じて制定できます。
o "Service resilience" requests that the server network provide connectivity for which the server network takes responsibility to recover from faults. The resilience may be achieved through the use of link-level protection, segment protection, end-to-end protection, or recovery mechanisms.
o 「サービスの回復力」は、サーバーネットワークが障害から回復する責任を負う接続をサーバーネットワークに提供することを要求します。回復力は、リンクレベルの保護、セグメントの保護、エンドツーエンドの保護、または回復メカニズムを使用して実現できます。
Although the topology and resource availability information of a server network may be hidden from the client network, the service request interface may support features that report details about the services and potential services that the server network supports.
サーバーネットワークのトポロジとリソースの可用性情報はクライアントネットワークから隠されている場合がありますが、サービス要求インターフェイスは、サーバーネットワークがサポートするサービスと潜在的なサービスに関する詳細を報告する機能をサポートしている場合があります。
o Reporting of path details, service parameters, and issues such as path diversity of LSPs that support deployed services allows the client network to understand to what extent its requests were satisfied. This is particularly important when the requests were made as "best effort".
o パスの詳細、サービスパラメータ、および展開されたサービスをサポートするLSPのパスの多様性などの問題のレポートにより、クライアントネットワークは、要求がどの程度満たされたかを理解できます。これは、リクエストが「ベストエフォート」として行われた場合に特に重要です。
o A server network may support requests of the form "If I were to ask you for this service, would you be able to provide it?" -- that is, a service request that does everything except actually provision the service.
o サーバーネットワークは、「このサービスを要求した場合、それを提供できますか？」という形式の要求をサポートする場合があります。 -つまり、実際にサービスをプロビジョニングする以外のすべてを実行するサービス要求。
The problem statement presented in this section is as much about the issues that may arise in any solution (and so have to be avoided) and the features that are desirable within a solution, as it is about the actual problem to be solved.
このセクションで示す問題の説明は、解決すべき実際の問題に関するものであるので、ソリューションで発生する可能性のある問題（および回避する必要がある）とソリューション内で望ましい機能についてです。
The problem can be stated very simply and with reference to the use cases presented in the previous section.
この問題は、前のセクションで示した使用例を参照して、非常に簡単に説明できます。
A mechanism is required that allows TE path computation in one domain to make informed choices about the TE capabilities and exit points from the domain when signaling an end-to-end TE path that will extend across multiple domains.
複数のドメインにまたがるエンドツーエンドのTEパスをシグナリングするときに、1つのドメインでのTEパス計算がTE機能とドメインからの出口点について情報に基づいた選択を行えるようにするメカニズムが必要です。
Thus, the problem is one of information collection and presentation, not about signaling. Indeed, the existing signaling mechanisms for TE LSP establishment are likely to prove adequate [RFC4726] with the possibility of minor extensions. Similarly, TE information may currently be distributed in a domain by TE extensions to one of the two IGPs as described in OSPF-TE [RFC3630] and ISIS-TE [RFC5305], and TE information may be exported from a domain (for example, northbound) using link-state extensions to BGP [RFC7752].
したがって、問題は情報収集と提示の1つであり、シグナリングに関するものではありません。実際、TE LSP確立のための既存のシグナリングメカニズムは、マイナーな拡張の可能性がある適切な[RFC4726]を証明する可能性があります。同様に、現在、OSPF-TE [RFC3630]およびISIS-TE [RFC5305]で説明されているように、TE情報は2つのIGPの1つへのTE拡張によってドメインに配信され、TE情報はドメインからエクスポートされます（たとえば、 northbound）BGP [RFC7752]へのリンクステート拡張を使用。
An interesting annex to the problem is how the path is made available for use. For example, in the case of a client-server network, the path established in the server network needs to be made available as a TE link to provide connectivity in the client network.
問題の興味深い別館は、パスがどのように使用可能にされるかです。たとえば、クライアントサーバーネットワークの場合、サーバーネットワークで確立されたパスをTEリンクとして利用できるようにして、クライアントネットワークに接続を提供する必要があります。
A solution must be amenable to the application of policy and filters. That is, the operator of a domain that is sharing information with another domain must be able to apply controls to what information is shared. Furthermore, the operator of a domain that has information shared with it must be able to apply policies and filters to the received information.
ソリューションは、ポリシーとフィルターの適用に対応できる必要があります。つまり、別のドメインと情報を共有しているドメインのオペレーターは、共有する情報に制御を適用できる必要があります。さらに、情報が共有されているドメインのオペレーターは、受信した情報にポリシーとフィルターを適用できる必要があります。
Additionally, the path computation within a domain must be able to weight the information received from other domains according to local policy such that the resultant computed path meets the local operator's needs and policies rather than those of the operators of other domains.
さらに、ドメイン内のパス計算は、ローカルポリシーに従って他のドメインから受信した情報に重みを付け、他のドメインのオペレーターではなくローカルオペレーターのニーズとポリシーを満たすように計算結果のパスを満たせるようにする必要があります。
A feature of the policy described in Section 3.1 is that an operator of a domain may desire to keep confidential the details about its internal network topology and loading. This information could be construed as commercially sensitive.
セクション3.1で説明されているポリシーの特徴は、ドメインのオペレーターが内部ネットワークトポロジーとロードに関する詳細を機密にしたい場合があることです。この情報は、商業上機密であると解釈される可能性があります。
Although it is possible that TE information exchange will take place only between parties that have significant trust, there are also use cases (such as the VPN supported over multiple server network domains described in Section 2.2) where information will be shared between domains that have a commercial relationship but a low level of trust.
TEの情報交換は、信頼関係が非常に深い関係者間でのみ行われる可能性がありますが、（2.2で説明されている複数のサーバーネットワークドメインでサポートされるVPNなど）、商業的関係はあるが信頼度は低い。
Thus, it must be possible for a domain to limit the shared information to only that which the computing domain needs to know, with the understanding that the less information that is made available the more likely it is that the result will be a less optimal path and/or more crankback events.
したがって、ドメインが共有情報をコンピューティングドメインが知る必要のある情報のみに制限することが可能でなければなりません。利用できる情報が少ないほど、結果は最適ではなくなります。および/またはより多くのクランクバックイベント。
One reason that networks are partitioned into separate domains is to reduce the set of information that any one router has to handle. This also applies to the volume of information that routing protocols have to distribute.
ネットワークが個別のドメインに分割される1つの理由は、1つのルーターが処理する必要がある情報のセットを減らすことです。これは、ルーティングプロトコルが配布する必要がある情報の量にも当てはまります。
Over the years, routers have become more sophisticated, with greater processing capabilities and more storage; the control channels on which routing messages are exchanged have become higher capacity; and the routing protocols (and their implementations) have become more robust. Thus, some of the arguments in favor of dividing a network into domains may have been reduced. Conversely, however, the size of networks continues to grow dramatically with a consequent increase in the total amount of routing-related information available. Additionally, in this case, the problem space spans two or more networks.
何年にもわたって、ルーターはより高度になり、処理能力とストレージが向上しています。ルーティングメッセージが交換される制御チャネルの容量が大きくなりました。ルーティングプロトコル（およびその実装）がより堅牢になりました。したがって、ネットワークをドメインに分割することを支持するいくつかの議論は減らされているかもしれません。ただし、逆に、利用可能なルーティング関連情報の総量が増加する結果、ネットワークのサイズは劇的に増加し続けます。さらに、この場合、問題空間は2つ以上のネットワークに広がります。
Any solution to the problems voiced in this document must be aware of the issues of information overload. If the solution was to simply share all TE information between all domains in the network, the effect from the point of view of the information load would be to create one single flat network domain. Thus, the solution must deliver enough information to make the computation practical (i.e., to solve the problem) but not so much as to overload the receiving domain. Furthermore, the solution cannot simply rely on the policies and filters described in Section 3.1 because such filters might not always be enabled.
このドキュメントで述べられている問題の解決策は、情報過多の問題を認識している必要があります。ソリューションがネットワーク内のすべてのドメイン間ですべてのTE情報を単に共有することであった場合、情報の負荷の観点からの効果は、単一のフラットネットワークドメインを作成することです。したがって、ソリューションは、計算を実用的にする（つまり、問題を解決する）ために十分な情報を提供する必要がありますが、受信ドメインを過負荷にするほどではありません。さらに、セクション3.1で説明されているポリシーやフィルターを必ずしも有効にできるとは限らないため、このソリューションは単純に依存することはできません。
As LSPs are set up and torn down, the available TE resources on links in the network change. In order to reliably compute a TE path through a network, the computation point must have an up-to-date view of the available TE resources. However, collecting this information may result in considerable load on the distribution protocol and churn in the stored information. In order to deal with this problem even in a single domain, updates are sent at periodic intervals or whenever there is a significant change in resources, whichever happens first.
LSPがセットアップされて破棄されると、ネットワーク内のリンクで使用可能なTEリソースが変わります。ネットワークを介したTEパスを確実に計算するには、計算ポイントに利用可能なTEリソースの最新のビューが必要です。ただし、この情報を収集すると、配信プロトコルにかなりの負荷がかかり、格納された情報が解約される可能性があります。単一のドメインでもこの問題に対処するために、更新は定期的な間隔で送信されるか、リソースに大きな変化があるたびに、どちらか早い方に送信されます。
Consider, for example, that a TE LSP may traverse ten links in a network. When the LSP is set up or torn down, the resources available on each link will change, resulting in a new advertisement of the link's capabilities and capacity. If the arrival rate of new LSPs is relatively fast, and the hold times relatively short, the network may be in a constant state of flux. Note that the problem here is not limited to churn within a single domain, since the information shared between domains will also be changing. Furthermore, the information that one domain needs to share with another may change as the result of LSPs that are contained within or cross the first domain but that are of no direct relevance to the domain receiving the TE information.
たとえば、TE LSPがネットワーク内の10個のリンクをトラバースする可能性があることを考慮してください。 LSPがセットアップまたは破棄されると、各リンクで使用可能なリソースが変更され、リンクの機能と容量の新しい通知が行われます。新しいLSPの到着率が比較的速く、ホールドタイムが比較的短い場合、ネットワークは一定のフラックス状態にある可能性があります。ドメイン間で共有される情報も変更されるため、ここでの問題は単一ドメイン内のチャーンに限定されないことに注意してください。さらに、あるドメインが別のドメインと共有する必要のある情報は、最初のドメイン内に含まれる、または最初のドメインと交差するが、TE情報を受信するドメインに直接関係のないLSPの結果として変化する場合があります。
In packet networks, where the capacity of an LSP is often a small fraction of the resources available on any link, this issue is partially addressed by the advertising routers. They can apply a threshold so that they do not bother to update the advertisement of available resources on a link if the change is less than a configured percentage of the total (or, alternatively, the remaining) resources. The updated information in that case will be disseminated based on an update interval rather than a resource change event.
LSPの容量がリンクで利用可能なリソースのごく一部であることが多いパケットネットワークでは、この問題はアドバタイズルーターによって部分的に対処されます。変更が合計（または、代わりに残りの）リソースの構成されたパーセンテージよりも小さい場合に、リンクで使用可能なリソースのアドバタイズメントを更新しなくても済むように、しきい値を適用できます。その場合の更新情報は、リソース変更イベントではなく更新間隔に基づいて配布されます。
In non-packet networks, where link resources are physical switching resources (such as timeslots or wavelengths), the capacity of an LSP may more frequently be a significant percentage of the available link resources. Furthermore, in some switching environments, it is necessary to achieve end-to-end resource continuity (such as using the same wavelength on the whole length of an LSP), so it is far more desirable to keep the TE information held at the computation points up to date. Fortunately, non-packet networks tend to be quite a bit smaller than packet networks, the arrival rates of non-packet LSPs are much lower, and the hold times are considerably longer. Thus, the information churn may be sustainable.
リンクリソースが物理的なスイッチングリソース（タイムスロットや波長など）である非パケットネットワークでは、LSPの容量が使用可能なリンクリソースのかなりの割合を占める頻度が高くなる場合があります。さらに、一部のスイッチング環境では、エンドツーエンドのリソースの連続性（LSPの全長で同じ波長を使用するなど）を達成する必要があるため、TE情報を計算で保持しておくことがはるかに望ましい最新のポイント。幸い、非パケットネットワークはパケットネットワークよりもかなり小さい傾向があり、非パケットLSPの到着率ははるかに低く、ホールドタイムはかなり長くなります。したがって、情報のチャーンは持続可能である可能性があります。
One possible solution to the issues raised in other subsections of this section is to aggregate the TE information shared between domains. Two aggregation mechanisms are often considered:
このセクションの他のサブセクションで提起された問題に対する1つの可能な解決策は、ドメイン間で共有されるTE情報を集約することです。多くの場合、2つの集約メカニズムが考慮されます。
- Virtual node model. In this view, the domain is aggregated as if it was a single node (or router/switch). Its links to other domains are presented as real TE links, but the model assumes that any LSP entering the virtual node through a link can be routed to leave the virtual node through any other link (although recent work on "limited cross-connect switches" may help with this problem [RFC7579]).
- 仮想ノードモデル。このビューでは、ドメインは1つのノード（またはルーター/スイッチ）であるかのように集約されます。他のドメインへのリンクは実際のTEリンクとして提示されますが、モデルは、リンクを介して仮想ノードに入るすべてのLSPをルーティングして、他のリンクを介して仮想ノードを離れることができることを前提としています（ただし、「限られたクロスコネクトスイッチ」での最近の作業はこの問題を解決する可能性があります[RFC7579]）。
- Virtual link model. In this model, the domain is reduced to a set of edge-to-edge TE links. Thus, when computing a path for an LSP that crosses the domain, a computation point can see which domain entry points can be connected to which others, and with what TE attributes.
- 仮想リンクモデル。このモデルでは、ドメインは一連のエッジツーエッジTEリンクに縮小されます。したがって、ドメインを横断するLSPのパスを計算するとき、計算ポイントは、どのドメインエントリポイントが他のどのドメインエントリポイントに接続でき、どのTE属性を持つかを確認できます。
Part of the nature of aggregation is that information is removed from the system. This can cause inaccuracies and failed path computation. For example, in the virtual node model there might not actually be a TE path available between a pair of domain entry points, but the model lacks the sophistication to represent this "limited cross-connect capability" within the virtual node. On the other hand, in the virtual link model it may prove very hard to aggregate multiple link characteristics: for example, there may be one path available with high bandwidth, and another with low delay, but this does not mean that the connectivity should be assumed or advertised as having both high bandwidth and low delay.
集約の性質の一部は、情報がシステムから削除されることです。これにより、不正確さが生じ、パス計算が失敗する可能性があります。たとえば、仮想ノードモデルでは、実際にはドメインエントリポイントのペア間でTEパスが利用できない場合がありますが、モデルには、仮想ノード内のこの「制限された相互接続機能」を表す高度な機能がありません。一方、仮想リンクモデルでは、複数のリンク特性を集約することが非常に困難であることが判明する場合があります。たとえば、1つのパスが高帯域幅で利用可能であり、別のパスが低遅延で利用可能である場合がありますが、これは接続が高帯域幅と低遅延の両方があると想定または宣伝されている。
The trick to this multidimensional problem, therefore, is to aggregate in a way that retains as much useful information as possible while removing the data that is not needed. An important part of this trick is a clear understanding of what information is actually needed.
したがって、この多次元問題の秘訣は、不要なデータを削除しながら、できるだけ多くの有用な情報を保持する方法で集約することです。このトリックの重要な部分は、実際に必要な情報を明確に理解することです。
It should also be noted in the context of Section 3.4 that changes in the information within a domain may have a bearing on what aggregated data is shared with another domain. Thus, while the data shared is reduced, the aggregation algorithm (operating on the routers responsible for sharing information) may be heavily exercised.
セクション3.4のコンテキストでは、ドメイン内の情報の変更が、どの集約データが別のドメインと共有されるかに影響を与える可能性があることにも注意する必要があります。したがって、共有されるデータが減少する一方で、（情報の共有を担当するルーターで動作する）集約アルゴリズムの負荷が大きくなる可能性があります。
As described in Section 1.1, TE reachability is the ability to reach a specific address along a TE path. The knowledge of TE reachability enables an end-to-end TE path to be computed.
セクション1.1で説明したように、TE到達可能性は、TEパスに沿って特定のアドレスに到達する機能です。 TEの到達可能性の知識により、エンドツーエンドのTEパスを計算できます。
In a single network, TE reachability is derived from the Traffic Engineering Database (TED), which is the collection of all TE information about all TE links in the network. The TED is usually built from the data exchanged by the IGP, although it can be supplemented by configuration and inventory details, especially in transport networks.
単一のネットワークでは、TE到達可能性は、ネットワーク内のすべてのTEリンクに関するすべてのTE情報のコレクションであるトラフィックエンジニアリングデータベース（TED）から導出されます。 TEDは通常、IGPによって交換されるデータから構築されますが、特にトランスポートネットワークでは、構成とインベントリの詳細によって補足することができます。
In multi-network scenarios, TE reachability information can be described as "You can get from node X to node Y with the following TE attributes." For transit cases, nodes X and Y will be edge nodes of the transit network, but it is also important to consider the information about the TE connectivity between an edge node and a specific destination node. TE reachability may be qualified by TE attributes such as TE metrics, hop count, available bandwidth, delay, and shared risk.
マルチネットワークシナリオでは、TE到達可能性情報は、「次のTE属性を使用してノードXからノードYに到達できる」と説明できます。トランジットの場合、ノードXおよびYはトランジットネットワークのエッジノードになりますが、エッジノードと特定の宛先ノード間のTE接続に関する情報を考慮することも重要です。 TEの到達可能性は、TEメトリック、ホップカウント、使用可能な帯域幅、遅延、共有リスクなどのTE属性によって修飾できます。
TE reachability information can be exchanged between networks so that nodes in one network can determine whether they can establish TE paths across or into another network. Such exchanges are subject to a range of policies imposed by the advertiser (for security and administrative control) and by the receiver (for scalability and stability).
TE到達可能性情報はネットワーク間で交換できるため、1つのネットワーク内のノードは、別のネットワーク全体または別のネットワークへのTEパスを確立できるかどうかを判断できます。このような交換は、広告主（セキュリティと管理上の制御）と受信者（スケーラビリティと安定性）によって課されるさまざまなポリシーの対象となります。
Aggregation is the process of synthesizing from available information. Thus, the virtual node and virtual link models described in Section 3.5 rely on processing the information available within a network to produce the aggregate representations of links and nodes that are presented to the consumer. As described in Section 3, dynamic aggregation is subject to a number of pitfalls.
集約は、利用可能な情報から合成するプロセスです。したがって、セクション3.5で説明する仮想ノードと仮想リンクモデルは、ネットワーク内で利用可能な情報を処理して、コンシューマに提示されるリンクとノードの集約表現を生成することに依存しています。セクション3で説明したように、動的集計には多くの落とし穴があります。
In order to distinguish the architecture described in this document from the previous work on aggregation, we use the term "abstraction" in this document. The process of abstraction is one of applying policy to the available TE information within a domain, to produce selective information that represents the potential ability to connect across the domain.
このドキュメントで説明されているアーキテクチャを、以前の集約に関する作業と区別するために、このドキュメントでは「抽象化」という用語を使用しています。抽象化のプロセスは、ドメイン内の利用可能なTE情報にポリシーを適用して、ドメイン全体に接続する潜在的な能力を表す選択的な情報を生成するプロセスの1つです。
Abstraction does not offer all possible connectivity options (refer to Section 3.5) but does present a general view of potential connectivity. Abstraction may have a dynamic element but is not intended to keep pace with the changes in TE attribute availability within the network.
抽象化はすべての可能な接続オプション（セクション3.5を参照）を提供するわけではありませんが、潜在的な接続の一般的なビューを提供します。抽象化には動的な要素が含まれる場合がありますが、ネットワーク内のTE属性の可用性の変化に対応することは意図されていません。
Thus, when relying on an abstraction to compute an end-to-end path, the process might not deliver a usable path. That is, there is no actual guarantee that the abstractions are current or feasible.
したがって、エンドツーエンドパスを計算するために抽象化に依存している場合、プロセスは使用可能なパスを提供しない可能性があります。つまり、抽象化が最新または実行可能であるという実際の保証はありません。
Although abstraction uses available TE information, it is subject to policy and management choices. Thus, not all potential connectivity will be advertised to each client network. The filters may depend on commercial relationships, the risk of disclosing confidential information, and concerns about what use is made of the connectivity that is offered.
抽象化は利用可能なTE情報を使用しますが、それはポリシーと管理の選択に従います。したがって、すべての潜在的な接続が各クライアントネットワークにアドバタイズされるわけではありません。フィルターは、商業的な関係、機密情報を開示するリスク、および提供される接続の使用に関する懸念に依存する場合があります。
An abstract link is a measure of the potential to connect a pair of points with certain TE parameters. That is, it is a path and its characteristics in the server network. An abstract link represents the possibility of setting up an LSP, and LSPs may be set up over the abstract link.
抽象リンクは、ポイントのペアを特定のTEパラメータと接続する可能性の尺度です。つまり、サーバーネットワーク内のパスとその特性です。抽象リンクはLSPを設定する可能性を表し、LSPは抽象リンク上に設定できます。
When looking at a network such as the network shown in Figure 7, the link from CN1 to CN4 may be an abstract link. It is easy to advertise it as a link by abstracting the TE information in the server network, subject to policy.
図7に示すネットワークなどのネットワークを見ると、CN1からCN4へのリンクは抽象リンクである可能性があります。ポリシーに従って、サーバーネットワーク内のTE情報を抽象化することで、リンクとして簡単にアドバタイズできます。
The path (i.e., the abstract link) represents the possibility of establishing an LSP from client network edge to client network edge across the server network. There is not necessarily a one-to-one relationship between the abstract link and the LSP, because more than one LSP could be set up over the path.
パス（つまり、抽象的なリンク）は、サーバーネットワーク全体でクライアントネットワークエッジからクライアントネットワークエッジへのLSPを確立する可能性を表します。パス上に複数のLSPを設定できるため、抽象リンクとLSPの間に必ずしも1対1の関係があるとは限りません。
Since the client network nodes do not have visibility into the server network, they must rely on abstraction information delivered to them by the server network. That is, the server network will report on the potential for connectivity.
クライアントネットワークノードはサーバーネットワークを認識できないため、サーバーネットワークからノードに配信される抽象化情報に依存する必要があります。つまり、サーバーネットワークは接続の可能性について報告します。
Figure 7 introduces the abstraction layer network. This construct separates the client network resources (nodes C1, C2, C3, and C4, and the corresponding links) and the server network resources (nodes CN1, CN2, CN3, and CN4, and the corresponding links). Additionally, the architecture introduces an intermediary network layer called the abstraction layer. The abstraction layer contains the client network edge nodes (C2 and C3), the server network edge nodes (CN1 and CN4), the client-server links (C2-CN1 and CN4-C3), and the abstract link (CN1-CN4).
図7は、抽象化層ネットワークを紹介しています。この構成により、クライアントネットワークリソース（ノードC1、C2、C3、およびC4、および対応するリンク）とサーバーネットワークリソース（ノードCN1、CN2、CN3、およびCN4、および対応するリンク）が分離されます。さらに、このアーキテクチャでは、抽象化レイヤーと呼ばれる中間ネットワークレイヤーが導入されています。抽象化レイヤーには、クライアントネットワークエッジノード（C2およびC3）、サーバーネットワークエッジノード（CN1およびCN4）、クライアント/サーバーリンク（C2-CN1およびCN4-C3）、および抽象リンク（CN1-CN4）が含まれています。 。
The client network is able to operate as normal. Connectivity across the network can be either found or not found, based on links that appear in the client network TED. If connectivity cannot be found, end-to-end LSPs cannot be set up. This failure may be reported, but no dynamic action is taken by the client network.
クライアントネットワークは通常どおりに動作できます。ネットワークを介した接続は、クライアントネットワークTEDに表示されるリンクに基づいて、検出される場合と検出されない場合があります。接続が見つからない場合、エンドツーエンドのLSPをセットアップできません。この障害は報告される可能性がありますが、クライアントネットワークは動的なアクションを実行しません。
The server network also operates as normal. LSPs across the server network between client network edges are set up in response to management commands or in response to signaling requests.
サーバーネットワークも通常どおり動作します。クライアントネットワークエッジ間のサーバーネットワーク全体のLSPは、管理コマンドに応答して、またはシグナリング要求に応答して設定されます。
The abstraction layer consists of the physical links between the two networks, and also the abstract links. The abstract links are created by the server network according to local policy and represent the potential connectivity that could be created across the server network and that the server network is willing to make available for use by the client network. Thus, in this example, the diameter of the abstraction layer network is only three hops, but an instance of an IGP could easily be run so that all nodes participating in the abstraction layer (and, in particular, the client network edge nodes) can see the TE connectivity in the layer.
抽象化レイヤーは、2つのネットワーク間の物理リンクと抽象リンクで構成されます。抽象リンクは、ローカルポリシーに従ってサーバーネットワークによって作成され、サーバーネットワーク全体で作成される可能性があり、サーバーネットワークがクライアントネットワークで使用できるようにする用意があることを示します。したがって、この例では、抽象化レイヤーネットワークの直径は3ホップにすぎませんが、IGPのインスタンスは簡単に実行できるため、抽象化レイヤーに参加するすべてのノード（特に、クライアントネットワークエッジノード）はレイヤのTE接続を確認してください。
-- -- -- --
|C1|--|C2| |C3|--|C4| Client Network
-- | | | | --
| | | | . . . . . . . . . . .
| | | |
| | | |
| | --- --- | | Abstraction
| |---|CN1|================|CN4|---| | Layer Network
-- | | | | --
| | | | . . . . . . . . . . . . . .
| | | |
| | | |
| | --- --- | | Server Network
| |--|CN2|--|CN3|--| |
--- --- --- ---
Key
--- Direct connection between two nodes
=== Abstract link
Figure 7: Architecture for Abstraction Layer Network
図7：抽象化レイヤーネットワークのアーキテクチャ
When the client network needs additional connectivity, it can make a request to the abstraction layer network. For example, the operator of the client network may want to create a link from C2 to C3. The abstraction layer can see the potential path C2-CN1-CN4-C3 and can set up an LSP C2-CN1-CN4-C3 across the server network and make the LSP available as a link in the client network.
クライアントネットワークが追加の接続を必要とする場合、抽象化層ネットワークに要求を出すことができます。たとえば、クライアントネットワークのオペレータは、C2からC3へのリンクを作成したい場合があります。抽象化レイヤーは、潜在的なパスC2-CN1-CN4-C3を確認し、サーバーネットワーク全体にLSP C2-CN1-CN4-C3を設定して、クライアントネットワークでLSPをリンクとして使用可能にすることができます。
Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the requirements for connectivity in client-server networks and in peer networks.
セクション4.2.3および4.2.4は、このモデルを使用して、クライアント/サーバーネットワークおよびピアネットワークの接続要件を満たす方法を示しています。
Figure 7 shows a very simplified network diagram, and the reader would be forgiven for thinking that only client network edge nodes and server network edge nodes may appear in the abstraction layer network. But this is not the case: other nodes from the server network may be present. This allows the abstraction layer network to be more complex than a full mesh with access spokes.
図7は非常に簡略化されたネットワーク図を示しており、クライアントレイヤーエッジノードとサーバーネットワークエッジノードのみが抽象化レイヤーネットワークに表示される可能性があると読者が考えることは許されます。しかし、そうではありません。サーバーネットワークからの他のノードが存在する可能性があります。これにより、抽象化レイヤーネットワークを、アクセススポークを備えたフルメッシュよりも複雑にすることができます。
Thus, as shown in Figure 8, a transit node in the server network (here, the node is CN3) can be exposed as a node in the abstraction layer network with abstract links connecting it to other nodes in the abstraction layer network. Of course, in the network shown in Figure 8, there is little if any value in exposing CN3, but if it had other abstract links to other nodes in the abstraction layer network and/or direct connections to client network nodes, then the resulting network would be richer.
したがって、図8に示すように、サーバーネットワークのトランジットノード（ここではノードはCN3）は、抽象化レイヤーネットワーク内のノードとして公開され、抽象化リンクが抽象化レイヤーネットワーク内の他のノードに接続します。もちろん、図8に示すネットワークでは、CN3を公開する価値はほとんどありませんが、抽象化レイヤーネットワーク内の他のノードへの他の抽象リンクやクライアントネットワークノードへの直接接続がある場合、結果のネットワークより豊かになります。
-- -- -- -- Client
|C1|--|C2| |C3|--|C4| Network
-- | | | | --
| | | | . . . . . . . . .
| | | |
| | | |
| | --- --- --- | | Abstraction
| |--|CN1|========|CN3|========|CN5|--| | Layer Network
-- | | | | | | --
| | | | | | . . . . . . . . . . . .
| | | | | |
| | | | | | Server
| | --- | | --- | | Network
| |--|CN2|-| |-|CN4|--| |
--- --- --- --- ---
Figure 8: Abstraction Layer Network with Additional Node
図8：追加ノードを含む抽象化レイヤーネットワーク
It should be noted that the nodes included in the abstraction layer network in this way are not "abstract nodes" in the sense of a virtual node described in Section 3.5. Although it is the case that the policy point responsible for advertising server network resources into the abstraction layer network could choose to advertise abstract nodes in place of real physical nodes, it is believed that doing so would introduce significant complexity in terms of:
このように抽象化層ネットワークに含まれるノードは、3.5節で説明した仮想ノードの意味での「抽象ノード」ではないことに注意してください。サーバーネットワークリソースをアブストラクションレイヤーネットワークにアドバタイズするポリシーポイントが、実際の物理ノードの代わりにアブストラクトノードをアドバタイズすることを選択できる場合もありますが、そうすることで次の点でかなりの複雑さが生じると考えられています。
- Coordination between all of the external interfaces of the abstract node.
- 抽象ノードのすべての外部インターフェース間の調整。
- Management of changes in the server network that lead to limited capabilities to reach (cross-connect) across the abstract node. There has been recent work on control-plane extensions to describe and operate devices (such as asymmetrical switches) that have limited cross-connect capabilities [RFC7579] [RFC7580]. These or similar extensions could be used to represent the same type of limitations, as they also apply in an abstract node.
- 抽象ノード全体に到達（クロスコネクト）する機能が制限されるサーバーネットワークの変更の管理。クロスコネクト機能が制限されたデバイス（非対称スイッチなど）を記述および操作するためのコントロールプレーン拡張に関する最近の作業があります[RFC7579] [RFC7580]。これらの拡張または類似の拡張は、抽象的なノードにも適用されるため、同じタイプの制限を表すために使用できます。
Figure 9 shows the basic architectural concepts for a client-server network. The nodes in the client network are C1, C2, CE1, CE2, C3, and C4, where the client edge (CE) nodes are CE1 and CE2. The core (server) network nodes are CN1, CN2, CN3, and CN4. The interfaces CE1-CN1 and CE2-CN4 are the interfaces between the client and server networks.
図9は、クライアントサーバーネットワークの基本的なアーキテクチャの概念を示しています。クライアントネットワークのノードはC1、C2、CE1、CE2、C3、およびC4で、クライアントエッジ（CE）ノードはCE1およびCE2です。コア（サーバー）ネットワークノードは、CN1、CN2、CN3、およびCN4です。インターフェースCE1-CN1およびCE2-CN4は、クライアントネットワークとサーバーネットワーク間のインターフェースです。
The technologies (switching capabilities) of the client and server networks may be the same or different. If they are different, the client network traffic must be tunneled over a server network LSP. If they are the same, the client network LSP may be routed over the server network links, tunneled over a server network LSP, or constructed from the concatenation (stitching) of client network and server network LSP segments.
クライアントとサーバーのネットワークのテクノロジー（スイッチング機能）は、同じでも異なっていてもかまいません。それらが異なる場合は、クライアントネットワークトラフィックをサーバーネットワークLSP経由でトンネリングする必要があります。それらが同じである場合、クライアントネットワークLSPは、サーバーネットワークリンクを介してルーティングされるか、サーバーネットワークLSPを介してトンネリングされるか、またはクライアントネットワークとサーバーネットワークLSPセグメントの連結（ステッチング）から構築されます。
: :
Client Network : Server Network : Client Network
: :
-- -- --- --- -- --
|C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|
-- -- | | --- --- | | -- --
| |===|CN1|================|CN4|===| |
| |---| | | |---| |
--- | | --- --- | | ---
| |--|CN2|--|CN3|--| |
--- --- --- ---
Key
--- Direct connection between two nodes
... CE-to-CE LSP tunnel
=== Potential path across the server network (abstract link)
Figure 9: Architecture for Client-Server Network
図9：クライアントサーバーネットワークのアーキテクチャ
The objective is to be able to support an end-to-end connection, C1-to-C4, in the client network. This connection may support TE or normal IP forwarding. To achieve this, CE1 is to be connected to CE2 by a link in the client network. This enables the client network to view itself as connected and to select an end-to-end path.
目的は、クライアントネットワークでC1からC4へのエンドツーエンド接続をサポートできるようにすることです。この接続は、TEまたは通常のIP転送をサポートする場合があります。これを実現するには、CE1をクライアントネットワークのリンクでCE2に接続します。これにより、クライアントネットワークはそれ自体が接続されていると見なし、エンドツーエンドパスを選択できます。
As shown in the figure, three abstraction layer links are formed: CE1-CN1, CN1-CN2, and CN4-CE2. A three-hop LSP is then established from CE1 to CE2 that can be presented as a link in the client network.
図に示すように、CE1-CN1、CN1-CN2、およびCN4-CE2の3つの抽象層リンクが形成されます。その後、CE1からCE2への3ホップLSPが確立され、クライアントネットワークでリンクとして提示できます。
The practicalities of how the CE1-CE2 LSP is carried across the server network LSP may depend on the switching and signaling options available in the server network. The CE1-CE2 LSP may be tunneled down the server network LSP using the mechanisms of a hierarchical LSP [RFC4206], or the LSP segments CE1-CN1 and CN4-CE2 may be stitched to the server network LSP as described in [RFC5150].
CE1-CE2 LSPがサーバーネットワークLSP全体でどのように運ばれるかについての実用性は、サーバーネットワークで利用可能なスイッチングおよびシグナリングオプションに依存する場合があります。 CE1-CE2 LSPは、階層型LSP [RFC4206]のメカニズムを使用してサーバーネットワークLSPをトンネリングするか、[RFC5150]で説明されているように、LSPセグメントCE1-CN1およびCN4-CE2をサーバーネットワークLSPにステッチすることができます。
Section 4.2.2 has already introduced the concept of the abstraction layer network through an example of a simple layered network. But it may be helpful to expand on the example using a slightly more complex network.
4.2.2項では、単純な階層型ネットワークの例を通じて、抽象化層ネットワークの概念をすでに紹介しています。ただし、少し複雑なネットワークを使用して例を拡張すると役立つ場合があります。
Figure 10 shows a multi-layer network comprising client network nodes (labeled as Cn for n = 0 to 9) and server network nodes (labeled as Sn for n = 1 to 9).
図10は、クライアントネットワークノード（n = 0〜9の場合はCnとラベル付け）とサーバーネットワークノード（n = 1〜9の場合はSnとラベル付け）を含む多層ネットワークを示しています。
-- --
|C3|---|C4|
/-- --\
-- -- -- -- --/ \--
|C1|---|C2|---|S1|---|S2|----|S3| |C5|
-- /-- --\ --\ --\ /--
/ \-- \-- \-- --/ --
/ |S4| |S5|----|S6|---|C6|---|C7|
/ /-- --\ /-- /-- --
--/ -- --/ -- \--/ --/
|C8|---|C9|---|S7|---|S8|----|S9|---|C0|
-- -- -- -- -- --
Figure 10: An Example Multi-Layer Network
図10：多層ネットワークの例
If the network in Figure 10 is operated as separate client and server networks, then the client network topology will appear as shown in Figure 11. As can be clearly seen, the network is partitioned, and there is no way to set up an LSP from a node on the left-hand side (say C1) to a node on the right-hand side (say C7).
図10のネットワークが個別のクライアントネットワークとサーバーネットワークとして動作している場合、クライアントネットワークトポロジは図11のようになります。明確にわかるように、ネットワークは分割されており、LSPをセットアップする方法はありません。左側のノード（たとえばC1）から右側のノード（たとえばC7）へ。
-- --
|C3|---|C4|
-- --\
-- -- \--
|C1|---|C2| |C5|
-- /-- /--
/ --/ --
/ |C6|---|C7|
/ /-- --
--/ -- --/
|C8|---|C9| |C0|
-- -- --
Figure 11: Client Network Topology Showing Partitioned Network
図11：分割されたネットワークを示すクライアントネットワークトポロジ
For reference, Figure 12 shows the corresponding server network topology.
参考のために、図12は対応するサーバーネットワークトポロジを示しています。
-- -- --
|S1|---|S2|----|S3|
--\ --\ --\
\-- \-- \--
|S4| |S5|----|S6|
/-- --\ /--
--/ -- \--/
|S7|---|S8|----|S9|
-- -- --
Figure 12: Server Network Topology
図12：サーバーネットワークトポロジ
Operating on the TED for the server network, a management entity or a software component may apply policy and consider what abstract links it might offer for use by the client network. To do this, it obviously needs to be aware of the connections between the layers (there is no point in offering an abstract link S2-S8, since this could not be of any use in this example).
サーバーネットワーク、管理エンティティ、またはソフトウェアコンポーネントのTEDで操作すると、ポリシーを適用し、クライアントネットワークで使用するために提供する抽象リンクを検討できます。これを行うには、明らかにレイヤー間の接続を認識する必要があります（この例ではこれが役に立たないため、抽象リンクS2-S8を提供しても意味がありません）。
In our example, after consideration of which LSPs could be set up in the server network, four abstract links are offered: S1-S3, S3-S6, S1-S9, and S7-S9. These abstract links are shown as double lines on the resulting topology of the abstraction layer network in Figure 13. As can be seen, two of the links must share part of a path (S1-S9 must share with either S1-S3 or S7-S9). This could be achieved using distinct resources (for example, separate lambdas) where the paths are common, but it could also be done using resource sharing.
この例では、サーバーネットワークにセットアップできるLSPを検討した後、4つの抽象リンクS1-S3、S3-S6、S1-S9、およびS7-S9が提供されます。これらの抽象リンクは、図13の抽象化レイヤーネットワークのトポロジで二重線として示されています。ご覧のように、2つのリンクはパスの一部を共有する必要があります（S1-S9はS1-S3またはS7-と共有する必要があります） S9）。これは、パスが共通である個別のリソース（たとえば、個別のラムダ）を使用して実現できますが、リソース共有を使用して実現することもできます。
--
|C3|
/--
-- -- --/
|C2|---|S1|==========|S3|
-- --\\ --\\
\\ \\
\\ \\-- --
\\ |S6|---|C6|
\\ -- --
-- -- \\-- --
|C9|---|S7|=====|S9|---|C0|
-- -- -- --
Figure 13: Abstraction Layer Network with Abstract Links
図13：抽象リンクを含む抽象化レイヤーネットワーク
That would mean that when both paths S1-S3 and S7-S9 carry client-edge-to-client-edge LSPs, the resources on path S1-S9 are used and might be depleted to the point that the path is resource constrained and cannot be used.
つまり、パスS1-S3とS7-S9の両方がクライアントエッジからクライアントエッジへのLSPを伝送する場合、パスS1-S9上のリソースが使用され、パスがリソースに制約されてリソースが不足するまで枯渇する可能性があります。利用される。
The separate IGP instance running in the abstraction layer network means that this topology is visible at the edge nodes (C2, C3, C6, C9, and C0) as well as at a Path Computation Element (PCE) if one is present.
抽象化レイヤーネットワークで実行されている別のIGPインスタンスは、このトポロジーがエッジノード（C2、C3、C6、C9、およびC0）と、存在する場合はパス計算要素（PCE）で表示されることを意味します。
Now the client network is able to make requests to the abstraction layer network to provide connectivity. In our example, it requests that C2 be connected to C3 and that C2 be connected to C0. This results in several actions:
これで、クライアントネットワークは、アブストラクションレイヤーネットワークにリクエストを送信して接続を提供できるようになります。この例では、C2をC3に接続し、C2をC0に接続するように要求します。これにより、いくつかのアクションが発生します。
1. The management component for the abstraction layer network asks its PCE to compute the paths necessary to make the connections. This yields C2-S1-S3-C3 and C2-S1-S9-C0.
1. 抽象層ネットワークの管理コンポーネントは、PCEに接続を確立するために必要なパスを計算するように要求します。これにより、C2-S1-S3-C3およびC2-S1-S9-C0が生成されます。
2. The management component for the abstraction layer network instructs C2 to start the signaling process for the new LSPs in the abstraction layer.
2. 抽象化層ネットワークの管理コンポーネントは、C2に抽象化層の新しいLSPのシグナリングプロセスを開始するように指示します。
3. C2 signals the LSPs for setup using the explicit routes C2-S1-S3-C3 and C2-S1-S9-C0.
3. C2は、明示的なルートC2-S1-S3-C3およびC2-S1-S9-C0を使用して、セットアップ用のLSPをシグナリングします。
4. When the signaling messages reach S1 (in our example, both LSPs traverse S1), the server network may support them by a number of means, including establishing server network LSPs as tunnels, depending on the mismatch of technologies between the client and server networks. For example, S1-S2-S3 and S1-S2-S5-S9 might be traversed via an LSP tunnel, using LSPs stitched together, or simply by routing the client network LSP through the server network. If server network LSPs are needed, they can be signaled at this point.
4. シグナリングメッセージがS1に到達すると（この例では、両方のLSPがS1を通過します）、サーバーネットワークは、クライアントとサーバーネットワーク間のテクノロジーの不一致に応じて、サーバーネットワークLSPをトンネルとして確立するなど、さまざまな方法でメッセージをサポートします。たとえば、S1-S2-S3とS1-S2-S5-S9は、LSPトンネルを介して、LSPをつなぎ合わせて、または単にクライアントネットワークLSPをサーバーネットワーク経由でルーティングすることでトラバースできます。サーバーネットワークLSPが必要な場合は、この時点で通知できます。
5. Once any server network LSPs that are needed have been established, S1 can continue to signal the client-edge-to-client-edge LSP across the abstraction layer, using the server network LSPs as either tunnels or stitching segments, or simply routing through the server network.
5. 必要なサーバーネットワークLSPが確立されると、S1は、サーバーレイヤーLSPをトンネルまたはステッチセグメントとして使用するか、または単にサーバーネットワーク。
6. Finally, once the client-edge-to-client-edge LSPs have been set up, the client network can be informed and can start to advertise the new TE links C2-C3 and C2-C0. The resulting client network topology is shown in Figure 14.
6. 最後に、クライアントエッジ間LSPがセットアップされると、クライアントネットワークに通知され、新しいTEリンクC2-C3およびC2-C0のアドバタイズを開始できます。結果のクライアントネットワークトポロジを図14に示します。
-- --
|C3|-|C4|
/-- --\
/ \--
-- --/ |C5|
|C1|---|C2| /--
-- /--\ --/ --
/ \ |C6|---|C7|
/ \ /-- --
/ \--/
--/ -- |C0|
|C8|---|C9| --
-- --
Figure 14: Connected Client Network with Additional Links
図14：リンクが追加された接続済みクライアントネットワーク
7. Now the client network can compute an end-to-end path from C1 to C7.
7. これで、クライアントネットワークはC1からC7へのエンドツーエンドパスを計算できます。
A single server network may support multiple client networks. This is not an uncommon state of affairs -- for example, when the server network provides connectivity for multiple customers.
1つのサーバーネットワークで複数のクライアントネットワークをサポートできます。これは珍しいことではありません。たとえば、サーバーネットワークが複数の顧客に接続を提供する場合などです。
In this case, the abstraction provided by the server network may vary considerably according to the policies and commercial relationships with each customer. This variance would lead to a separate abstraction layer network maintained to support each client network.
この場合、サーバーネットワークによって提供される抽象化は、ポリシーや各顧客との商業的関係によってかなり異なる場合があります。この差異は、各クライアントネットワークをサポートするために維持された別個の抽象化レイヤーネットワークにつながります。
On the other hand, it may be that multiple client networks are subject to the same policies and the abstraction can be identical. In this case, a single abstraction layer network can support more than one client.
一方、複数のクライアントネットワークが同じポリシーの対象であり、抽象化が同一である可能性があります。この場合、単一の抽象層ネットワークが複数のクライアントをサポートできます。
The choices here are made as an operational issue by the server network.
ここでの選択は、サーバーネットワークによる運用上の問題として行われます。
A single client network may be supported by multiple server networks. The server networks may provide connectivity between different parts of the client network or may provide parallel (redundant) connectivity for the client network.
単一のクライアントネットワークが複数のサーバーネットワークでサポートされている場合があります。サーバーネットワークは、クライアントネットワークの異なる部分間の接続を提供するか、クライアントネットワークに並列（冗長）接続を提供します。
In this case, the abstraction layer network should contain the abstract links from all server networks so that it can make suitable computations and create the correct TE links in the client network.
この場合、抽象化レイヤーネットワークには、適切な計算を行い、クライアントネットワークに正しいTEリンクを作成できるように、すべてのサーバーネットワークからの抽象リンクが含まれている必要があります。
That is, the relationship between the client network and the abstraction layer network should be one to one.
つまり、クライアントネットワークと抽象化レイヤーネットワークの関係は1対1である必要があります。
Figure 15 shows the basic architectural concepts for connecting across peer networks. Nodes from four networks are shown: A1 and A2 come from one network; B1, B2, and B3 from another network; etc. The interfaces between the networks (sometimes known as External Network Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1.
図15は、ピアネットワーク間で接続するための基本的なアーキテクチャの概念を示しています。 4つのネットワークからのノードが示されています。A1とA2は1つのネットワークからのものです。別のネットワークからのB1、B2、およびB3。ネットワーク間のインターフェース（外部ネットワークネットワークインターフェース-ENNIとも呼ばれます）は、A2-B1、B3-C1、およびC3-D1です。
The objective is to be able to support an end-to-end connection, A1-to-D2. This connection is for TE connectivity.
目的は、エンドツーエンド接続、A1-to-D2をサポートできるようにすることです。この接続はTE接続用です。
As shown in the figure, abstract links that span the transit networks are used to achieve the required connectivity. These links form the key building blocks of the end-to-end connectivity. An end-to-end LSP uses these links as part of its path. If the stitching capabilities of the networks are homogeneous, then the end-to-end LSP may simply traverse the path defined by the abstract links across the various peer networks or may utilize stitching of LSP segments that each traverse a network along the path of an abstract link. If the network switching technologies support or necessitate the use of LSP hierarchies, the end-to-end LSP may be tunneled across each network using hierarchical LSPs that each traverse a network along the path of an abstract link.
図に示すように、必要な接続を実現するために、トランジットネットワークにまたがる抽象的なリンクが使用されます。これらのリンクは、エンドツーエンド接続の主要なビルディングブロックを形成します。エンドツーエンドLSPは、これらのリンクをパスの一部として使用します。ネットワークのスティッチ機能が同種である場合、エンドツーエンドのLSPは、さまざまなピアネットワーク全体の抽象リンクによって定義されたパスを単に通過するか、それぞれがネットワークのパスに沿ってネットワークを通過するLSPセグメントのスティッチを利用します。抽象リンク。ネットワークスイッチングテクノロジーがLSP階層の使用をサポートまたは必要とする場合、エンドツーエンドLSPは、抽象リンクのパスに沿ってネットワークを横断する階層型LSPを使用して、各ネットワーク間でトンネリングされます。
: : :
Network A : Network B : Network C : Network D
: : :
-- -- -- -- -- -- -- -- -- --
|A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2|
-- -- | | -- | | | | -- | | -- --
| |========| | | |========| |
-- -- -- --
Key
--- Direct connection between two nodes
=== Abstract link across transit network
Figure 15: Architecture for Peering
図15：ピアリングのアーキテクチャ
Peer networks exist in many situations in the Internet. Packet networks may peer as IGP areas (levels) or as ASes. Transport networks (such as optical networks) may peer to provide concatenations of optical paths through single-vendor environments (see Section 6). Figure 16 shows a simple example of three peer networks (A, B, and C) each comprising a few nodes.
ピアネットワークは、インターネットの多くの状況で存在します。パケットネットワークは、IGPエリア（レベル）またはASとしてピアリングできます。トランスポートネットワーク（光ネットワークなど）は、単一ベンダー環境を介して光パスの連結を提供するためにピアリングする場合があります（セクション6を参照）。図16は、それぞれがいくつかのノードで構成される3つのピアネットワーク（A、B、C）の簡単な例を示しています。
Network A : Network B : Network C
: :
-- -- -- : -- -- -- : -- --
|A1|---|A2|----|A3|---|B1|---|B2|---|B3|---|C1|---|C2|
-- --\ /-- : -- /--\ -- : -- --
\--/ : / \ :
|A4| : / \ :
--\ : / \ :
-- \-- : --/ \-- : -- --
|A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
-- -- : -- -- : -- --
: :
: :
Figure 16: A Network Comprising Three Peer Networks
図16：3つのピアネットワークで構成されるネットワーク
As discussed in Section 2, peered networks do not share visibility of their topologies or TE capabilities for scaling and confidentiality reasons. That means, in our example, that computing a path from A1 to C4 can be impossible without the aid of cooperating PCEs or some form of crankback.
セクション2で説明したように、ピアリングされたネットワークは、スケーリングや機密性の理由から、トポロジやTE機能の可視性を共有しません。つまり、この例では、A1からC4へのパスを計算することは、協力するPCEまたは何らかの形のクランクバックの支援なしでは不可能である可能性があることを意味します。
But it is possible to produce abstract links for reachability across transit peer networks and to create an abstraction layer network. That network can be enhanced with specific reachability information if a destination network is partitioned, as is the case with Network C in Figure 16.
しかし、トランジットピアネットワークを介した到達可能性のための抽象リンクを作成し、抽象化レイヤーネットワークを作成することは可能です。図16のネットワークCの場合のように、宛先ネットワークが分割されている場合、そのネットワークは特定の到達可能性情報で拡張できます。
Suppose that Network B decides to offer three abstract links B1-B3, B4-B3, and B4-B6. The abstraction layer network could then be constructed to look like the network in Figure 17.
ネットワークBが3つの抽象リンクB1-B3、B4-B3、およびB4-B6を提供すると決定したとします。抽象化層ネットワークは、図17のネットワークのように構築できます。
-- -- -- --
|A3|---|B1|====|B3|----|C1|
-- -- //-- --
//
//
//
-- --// -- --
|A6|---|B4|=====|B6|---|C3|
-- -- -- --
Figure 17: Abstraction Layer Network for the Peer Network Example
図17：ピアネットワークの例の抽象化レイヤーネットワーク
Using a process similar to that described in Section 4.2.3, Network A can request connectivity to Network C, and abstract links can be advertised that connect the edges of the two networks and that can be used to carry LSPs that traverse both networks. Furthermore, if Network C is partitioned, reachability information can be exchanged to allow Network A to select the correct abstract link, as shown in Figure 18.
セクション4.2.3で説明したのと同様のプロセスを使用して、ネットワークAはネットワークCへの接続を要求でき、2つのネットワークのエッジを接続し、両方のネットワークを通過するLSPの伝送に使用できる抽象リンクをアドバタイズできます。さらに、図18に示すように、ネットワークCが分割されている場合、到達可能性情報を交換して、ネットワークAが正しい抽象リンクを選択できるようにすることができます。
Network A : Network C
:
-- -- -- : -- --
|A1|---|A2|----|A3|=========|C1|.....|C2|
-- --\ /-- : -- --
\--/ :
|A4| :
--\ :
-- \-- : -- --
|A5|---|A6|=========|C3|.....|C4|
-- -- : -- --
Figure 18: Tunnel Connections to Network C with TE Reachability
図18：TEの到達可能性を備えたネットワークCへのトンネル接続
Peer networking cases can be made far more complex by dual-homing between network peering nodes (for example, A3 might connect to B1 and B4 in Figure 17) and by the networks themselves being arranged in a mesh (for example, A6 might connect to B4 and C1 in Figure 17).
ピアネットワーキングケースは、ネットワークピアリングノード間のデュアルホーミング（たとえば、A3が図17のB1およびB4に接続する）とメッシュ自体に配置されるネットワーク自体（たとえば、A6が図17のB4とC1）。
These additional complexities can be handled gracefully by the abstraction layer network model.
これらの追加の複雑さは、抽象化レイヤーネットワークモデルによって適切に処理できます。
Further examples of abstraction in peer networks can be found in Sections 6 and 8.
ピアネットワークにおける抽象化のさらなる例は、セクション6および8にあります。
It is possible to consider a highly dynamic system where the server network adaptively suggests new abstract links into the abstraction layer, and where the abstraction layer proactively deploys new client-edge-to-client-edge LSPs to provide new links in the client network. Such fluidity is, however, to be treated with caution. In particular, in the case of client-server networks of differing technologies where hierarchical server network LSPs are used, this caution is needed for three reasons: there may be longer turn-up times for connections in some server networks; the server networks are likely to be sparsely connected; and expensive physical resources will only be deployed where there is believed to be a need for them. More significantly, the complex commercial, policy, and administrative relationships that may exist between client and server network operators mean that stability is more likely to be the desired operational practice.
サーバーネットワークが新しい抽象リンクを抽象化レイヤーに適応的に提案し、抽象化レイヤーがクライアントエッジ間LSPを積極的に展開してクライアントネットワークに新しいリンクを提供する、非常に動的なシステムを検討することが可能です。ただし、このような流動性は慎重に扱う必要があります。特に、階層型サーバーネットワークLSPが使用されるさまざまなテクノロジーのクライアントサーバーネットワークの場合、この注意が必要な理由は3つあります。サーバーネットワークによっては、接続のターンアップ時間が長くなる場合があります。サーバーネットワークが疎に接続されている可能性があります。高価な物理リソースは、それらが必要であると考えられる場所にのみ配置されます。さらに重要なことに、クライアントとサーバーのネットワークオペレーター間に存在する可能性のある複雑な商業、ポリシー、および管理関係は、安定性が望ましい運用慣行である可能性が高いことを意味します。
Thus, proposals for fully automated multi-layer networks based on this architecture may be regarded as forward-looking topics for research both in terms of network stability and with regard to economic impact.
したがって、このアーキテクチャに基づく完全に自動化されたマルチレイヤネットワークの提案は、ネットワークの安定性の観点と経済的影響の両方の観点から、研究の将来を見据えたトピックと見なすことができます。
However, some elements of automation should not be discarded. A server network may automatically apply policy to determine the best set of abstract links to offer and the most suitable way for the server network to support them. And a client network may dynamically observe congestion, lack of connectivity, or predicted changes in traffic demand and may use this information to request additional links from the abstraction layer. And, once policies have been configured, the whole system should be able to operate independently of operator control (which is not to say that the operator will not have the option of exerting control at every step in the process).
ただし、自動化の一部の要素は破棄しないでください。サーバーネットワークは自動的にポリシーを適用して、提供する抽象リンクの最適なセットと、サーバーネットワークがそれらをサポートするための最適な方法を決定します。また、クライアントネットワークは、輻輳、接続の欠如、またはトラフィック需要の予測される変化を動的に観察し、この情報を使用して、抽象化レイヤーからの追加リンクを要求する場合があります。また、ポリシーが設定されると、システム全体がオペレーターの制御とは独立して動作できるようになります（つまり、オペレーターがプロセスのすべてのステップで制御を実行するオプションがないわけではありません）。
The abstraction layer network is "just another network layer". The links and nodes in the network need to be advertised along with their associated TE information (metrics, bandwidth, etc.) so that the topology is disseminated and so that routing decisions can be made.
抽象化層ネットワークは「単なる別のネットワーク層」です。ネットワーク内のリンクとノードは、関連するTE情報（メトリック、帯域幅など）とともにアドバタイズされる必要があります。これにより、トポロジが普及し、ルーティングの決定が可能になります。
This requires a routing protocol running between the nodes in the abstraction layer network. Note that this routing information exchange could be piggybacked on an existing routing protocol instance (subject to different switching capabilities applying to the links in the different networks, or to adequate address space separation) or use a new instance (or even a new protocol). Clearly, the information exchanged is only information that has been created as part of the abstraction function according to policy.
これには、抽象層ネットワークのノード間で実行されるルーティングプロトコルが必要です。このルーティング情報の交換は、既存のルーティングプロトコルインスタンス（さまざまなネットワークのリンクに適用されるさまざまなスイッチング機能、または適切なアドレス空間の分離に従う）に便乗するか、新しいインスタンス（または新しいプロトコル）を使用する可能性があることに注意してください。明らかに、交換される情報は、ポリシーに従って抽象化機能の一部として作成された情報のみです。
It should be noted that in many cases the abstract link represents the potential for connectivity across the server network but that no such connectivity exists. In this case, we may ponder how the routing protocol in the abstraction layer will advertise topology information for, and over, a link that has no underlying connectivity. In other words, there must be a communication channel between the abstraction layer nodes so that the routing protocol messages can flow. The answer is that control-plane connectivity already exists in the server network and on the client-server edge links, and this can be used to carry the routing protocol messages for the abstraction layer network. The same consideration applies to the advertisement, in the client network, of the potential connectivity that the abstraction layer network can provide, although it may be more normal to establish that connectivity before advertising a link in the client network.
多くの場合、抽象リンクはサーバーネットワーク全体の接続の可能性を表しますが、そのような接続は存在しないことに注意してください。この場合、抽象化層のルーティングプロトコルが、基礎となる接続を持たないリンクのトポロジ情報をどのようにしてアドバタイズするかについて考えます。つまり、ルーティングプロトコルメッセージが流れるように、抽象化層ノード間に通信チャネルが必要です。その答えは、コントロールプレーン接続がサーバーネットワークとクライアント/サーバーエッジリンクに既に存在していることであり、これを使用して、抽象化レイヤーネットワークのルーティングプロトコルメッセージを運ぶことができます。クライアントネットワークでリンクをアドバタイズする前にその接続を確立するのがより一般的かもしれませんが、同じ考慮事項が、アブストラクションレイヤーネットワークが提供できる接続のクライアントのアドバタイズにも適用されます。
The network layers in this architecture should be able to operate with separate address spaces, and these may overlap without any technical issues. That is, one address may mean one thing in the client network, yet the same address may have a different meaning in the abstraction layer network or the server network. In other words, there is complete address separation between networks.
このアーキテクチャのネットワークレイヤーは、個別のアドレススペースで動作できる必要があり、これらは技術的な問題なくオーバーラップできます。つまり、1つのアドレスがクライアントネットワークで1つのことを意味する場合がありますが、抽象化レイヤーネットワークまたはサーバーネットワークでは同じアドレスが異なる意味を持つ場合があります。つまり、ネットワーク間に完全なアドレス分離があります。
However, this will require some care, both because human operators may well become confused, and because mapping between address spaces is needed at the interfaces between the network layers. That mapping requires configuration so that, for example, when the server network announces an abstract link from A to B, the abstraction layer network must recognize that A and B are server network addresses and must map them to abstraction layer addresses (say P and Q) before including the link in its own topology. And similarly, when the abstraction layer network informs the client network that a new link is available from S to T, it must map those addresses from its own address space to that of the client network.
ただし、人間のオペレーターが混乱する可能性があり、ネットワークレイヤー間のインターフェースでアドレス空間間のマッピングが必要になるため、これには注意が必要です。たとえば、サーバーネットワークがAからBへの抽象リンクをアナウンスするとき、抽象化レイヤーネットワークは、AおよびBがサーバーネットワークアドレスであることを認識し、それらを抽象化レイヤーアドレス（たとえば、PおよびQ）にマッピングする必要があります。 ）独自のトポロジにリンクを含める前。同様に、抽象化層ネットワークがクライアントネットワークにSからTへの新しいリンクが利用可能であることを通知する場合、抽象化ネットワークはそれらのアドレスを自身のアドレス空間からクライアントネットワークのアドレス空間にマッピングする必要があります。
This form of address mapping will become particularly important in cases where one abstraction layer network is constructed from connectivity in multiple server networks, or where one abstraction layer network provides connectivity for multiple client networks.
この形式のアドレスマッピングは、1つの抽象層ネットワークが複数のサーバーネットワークの接続から構成される場合、または1つの抽象層ネットワークが複数のクライアントネットワークに接続を提供する場合に特に重要になります。
This section is non-normative and is not intended to prejudge a solutions framework or any applicability work. It does, however, very briefly serve to note the existence of protocols that could be examined for applicability to serve in realizing the model described in this document.
このセクションは非規範的であり、ソリューションフレームワークまたは適用性の作業を予断することを意図していません。ただし、このドキュメントで説明されているモデルを実現するために適用できるかどうかを調べることができるプロトコルの存在に注目するのに非常に簡単に役立ちます。
The general principle of protocol reuse is preferred over the invention of new protocols or additional protocol extensions, and it would be advantageous to make use of an existing protocol that is commonly implemented on network nodes and is currently deployed, or to use existing computational elements such as PCEs. This has many benefits in network stability, time to deployment, and operator training.
プロトコルの再利用の一般的な原則は、新しいプロトコルや追加のプロトコル拡張の発明よりも優先され、ネットワークノードに一般的に実装され、現在展開されている既存のプロトコルを利用するか、既存の計算要素を使用することが有利です。 PCEとして。これには、ネットワークの安定性、導入までの時間、およびオペレーターのトレーニングにおいて多くの利点があります。
It is recognized, however, that existing protocols are unlikely to be immediately suitable to this problem space without some protocol extensions. Extending protocols must be done with care and with consideration for the stability of existing deployments. In extreme cases, a new protocol can be preferable to a messy hack of an existing protocol.
ただし、既存のプロトコルは、一部のプロトコル拡張なしでは、この問題空間にすぐには適さない可能性が高いことが認識されています。プロトコルの拡張は、既存のデプロイメントの安定性を考慮して、注意深く行う必要があります。極端なケースでは、新しいプロトコルは、既存のプロトコルの乱雑なハックよりも望ましい場合があります。
BGP - Link State (BGP-LS) is a set of extensions to BGP, as described in [RFC7752]. Its purpose is to announce topology information from one network to a "northbound" consumer. Application of BGP-LS to date has focused on a mechanism to build a TED for a PCE. However, BGP's mechanisms would also serve well to advertise abstract links from a server network into the abstraction layer network or to advertise potential connectivity from the abstraction layer network to the client network.
BGP-リンク状態（BGP-LS）は、[RFC7752]で説明されているように、BGPへの拡張のセットです。その目的は、1つのネットワークから「ノースバウンド」コンシューマにトポロジ情報を通知することです。これまでのBGP-LSの適用は、PCE用のTEDを構築するメカニズムに重点を置いてきました。ただし、BGPのメカニズムは、抽象リンクをサーバーネットワークから抽象層ネットワークにアドバタイズしたり、抽象層ネットワークからクライアントネットワークへの潜在的な接続をアドバタイズしたりするのにも役立ちます。
Both OSPF and IS-IS have been extended through a number of RFCs to advertise TE information. Additionally, both protocols are capable of running in a multi-instance mode either as ships that pass in the night (i.e., completely separate instances using different address spaces) or as dual instances on the same address space. This means that either OSPF or IS-IS could probably be used as the routing protocol in the abstraction layer network.
OSPFとIS-ISの両方が、TE情報をアドバタイズするためにいくつかのRFCを通じて拡張されています。さらに、両方のプロトコルは、夜間に通過する船（つまり、異なるアドレススペースを使用する完全に独立したインスタンス）または同じアドレススペースのデュアルインスタンスとして、マルチインスタンスモードで実行できます。つまり、OSPFまたはIS-ISのいずれかが、抽象化層ネットワークのルーティングプロトコルとして使用される可能性があります。
RSVP-TE signaling can be used to set up all TE LSPs demanded by this model, without the need for any protocol extensions.
RSVP-TEシグナリングを使用すると、プロトコル拡張を必要とせずに、このモデルが要求するすべてのTE LSPをセットアップできます。
If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can be used to carry LSPs over the server network, again without needing any protocol extensions.
必要に応じて、LSP階層[RFC4206]またはLSPスティッチング[RFC5150]を使用して、プロトコル拡張を必要とせずに、サーバーネットワーク経由でLSPを伝送できます。
Furthermore, the procedures in [RFC6107] allow the dynamic signaling of the purpose of any LSP that is established. This means that when an LSP tunnel is set up, the two ends can coordinate into which routing protocol instance it should be advertised and can also agree on the addressing to be said to identify the link that will be created.
さらに、[RFC6107]の手順では、確立されているLSPの目的を動的にシグナリングできます。これは、LSPトンネルが設定されると、2つのエンドがアドバタイズするルーティングプロトコルインスタンスを調整し、作成されるリンクを識別するためのアドレッシングについて合意できることを意味します。
This section is not intended to be prescriptive or dictate the protocol solutions that may be used to satisfy the architecture described in this document, but it does show how the existing protocols listed in the previous sections can be combined, with only minor modifications, to provide a solution.
このセクションは、規範となることを意図したものではなく、このドキュメントで説明されているアーキテクチャを満たすために使用できるプロトコルソリューションを規定するものではありませんが、前のセクションでリストされた既存のプロトコルを、わずかな変更のみで組み合わせて、解決策。
A server network can be operated using GMPLS routing and signaling protocols. Using information gathered from the routing protocol, a TED can be constructed containing resource availability information and Shared Risk Link Group (SRLG) details. A policy-based process can then determine which nodes and abstract links it wishes to advertise to form the abstraction layer network.
サーバーネットワークは、GMPLSルーティングおよびシグナリングプロトコルを使用して操作できます。ルーティングプロトコルから収集した情報を使用して、リソースの可用性情報と共有リスクリンクグループ（SRLG）の詳細を含むTEDを構築できます。ポリシーベースのプロセスは、抽象化レイヤーネットワークを形成するためにアドバタイズするノードと抽象リンクを決定できます。
The server network can now use BGP-LS to advertise a topology of links and nodes to form the abstraction layer network. This information would most likely be advertised from a single point of control that made all of the abstraction decisions, but the function could be distributed to multiple server network edge nodes. The information can be advertised by BGP-LS to multiple points within the abstraction layer (such as all client network edge nodes) or to a single controller.
これで、サーバーネットワークはBGP-LSを使用してリンクとノードのトポロジを通知し、抽象化レイヤーネットワークを形成できます。ほとんどの場合、この情報は、すべての抽象化の決定を行った単一の制御ポイントから通知されますが、機能は複数のサーバーネットワークエッジノードに分散できます。情報は、BGP-LSによって抽象化レイヤー内の複数のポイント（すべてのクライアントネットワークエッジノードなど）または単一のコントローラーにアドバタイズできます。
Multiple server networks may advertise information that is used to construct an abstraction layer network, and one server network may advertise different information in different instances of BGP-LS to form different abstraction layer networks. Furthermore, in the case of one controller constructing multiple abstraction layer networks, BGP-LS uses the route target mechanism defined in [RFC4364] to distinguish the different applications (effectively abstraction layer network VPNs) of the exported information.
複数のサーバーネットワークが抽象化レイヤーネットワークの構築に使用される情報をアドバタイズし、1つのサーバーネットワークがBGP-LSの異なるインスタンスで異なる情報をアドバタイズして、異なる抽象化レイヤーネットワークを形成します。さらに、1つのコントローラーが複数の抽象化レイヤーネットワークを構築している場合、BGP-LSは[RFC4364]で定義されているルートターゲットメカニズムを使用して、エクスポートされた情報のさまざまなアプリケーション（事実上抽象化レイヤーネットワークVPN）を区別します。
Extensions may be made to BGP-LS to allow advertisement of Macro Shared Risk Link Groups (MSRLGs) (Appendix B.1) and the identification of mutually exclusive links (Appendix B.2), and to indicate whether the abstract link has been pre-established or not. Such extensions are valid options but do not form a core component of this architecture.
BGP-LSを拡張して、マクロ共有リスクリンクグループ（MSRLG）（付録B.1）のアドバタイズと相互に排他的なリンクの識別（付録B.2）を可能にし、抽象リンクが事前に作成されているかどうかを示すことができます。 -確立されたかどうか。そのような拡張は有効なオプションですが、このアーキテクチャのコアコンポーネントを形成しません。
The abstraction layer network may operate under central control or use a distributed control plane. Since the links and nodes may be a mix of physical and abstract links, and since the nodes may have diverse cross-connect capabilities, it is most likely that a GMPLS routing protocol will be beneficial for collecting and correlating the routing information and for distributing updates. No special additional features are needed beyond adding those extra parameters just described for BGP-LS, but it should be noted that the control plane of the abstraction layer network must run in an out-of-band control network because the data-bearing links might not yet have been established via connections in the server network.
抽象層ネットワークは、中央制御下で動作するか、分散制御プレーンを使用します。リンクとノードは物理リンクと抽象リンクの混合であり、ノードにはさまざまな相互接続機能がある可能性があるため、GMPLSルーティングプロトコルはルーティング情報の収集と関連付け、および更新の配布に役立つ可能性が高いです。 。 BGP-LSについて説明した追加のパラメーターを追加する以外に特別な追加機能は必要ありませんが、データベアリングリンクが存在する可能性があるため、抽象化レイヤーネットワークの制御プレーンは帯域外制御ネットワークで実行する必要があることに注意してください。サーバーネットワークの接続を介してまだ確立されていません。
The abstraction layer network is also able to determine potential connectivity from client network edge to client network edge. It will determine which client network links to create according to policy and subject to requests from the client network, and will take four steps:
抽象化層ネットワークは、クライアントネットワークエッジからクライアントネットワークエッジへの接続の可能性を判断することもできます。ポリシーに従って作成するクライアントネットワークリンクを決定し、クライアントネットワークからの要求に応じて、次の4つの手順を実行します。
- First, it will compute a path across the abstraction layer network.
- まず、抽象化レイヤーネットワーク全体のパスを計算します。
- Then, if support of the abstract links requires the use of server network LSPs for tunneling or stitching and if those LSPs are not already established, it will ask the server layer to set them up.
- 次に、抽象リンクのサポートでトンネリングまたはスティッチングにサーバーネットワークLSPを使用する必要があり、それらのLSPがまだ確立されていない場合は、サーバーレイヤーにそれらをセットアップするように要求します。
- Then, it will signal the client-edge-to-client-edge LSP.
- 次に、クライアントエッジからクライアントエッジへのLSPを通知します。
- Finally, the abstraction layer network will inform the client network of the existence of the new client network link.
- 最後に、抽象化層ネットワークは、クライアントネットワークに新しいクライアントネットワークリンクの存在を通知します。
This last step can be achieved by either (1) coordination of the end points of the LSPs that span the abstraction layer (these points are client network edge nodes) using mechanisms such as those described in [RFC6107] or (2) using BGP-LS from a central controller.
この最後のステップは、（1）[RFC6107]で説明されているようなメカニズムを使用して、抽象化レイヤー（これらのポイントはクライアントネットワークエッジノードです）にまたがるLSPのエンドポイントを調整するか、（2）BGPを使用して中央コントローラーからのLS。
Once the client network edge nodes are aware of a new link, they will automatically advertise it using their routing protocol and it will become available for use by traffic in the client network.
クライアントネットワークエッジノードは、新しいリンクを認識すると、ルーティングプロトコルを使用して自動的にアドバタイズし、クライアントネットワークのトラフィックで使用できるようになります。
Sections 6, 7, and 8 discuss the applicability of this architecture to different network types and problem spaces, while Section 9 gives some advice about scoping future work. Section 10 ("Manageability Considerations") is particularly relevant in the context of this section because it contains a discussion of the policies and mechanisms for indicating connectivity and link availability between network layers in this architecture.
セクション6、7、および8では、このアーキテクチャのさまざまなネットワークタイプおよび問題空間への適用性について説明し、セクション9では、将来の作業のスコープについていくつかのアドバイスを提供します。セクション10（「管理性に関する考慮事項」）は、このアーキテクチャのネットワークレイヤー間の接続とリンクの可用性を示すためのポリシーとメカニズムの説明が含まれているため、このセクションのコンテキストに特に関連しています。
Many optical networks are arranged as a set of small domains. Each domain is a cluster of nodes, usually from the same equipment vendor and with the same properties. The domain may be constructed as a mesh or a ring, or maybe as an interconnected set of rings.
多くの光ネットワークは、一連の小さなドメインとして配置されます。各ドメインはノードのクラスターであり、通常は同じ機器ベンダーの同じプロパティを使用しています。ドメインは、メッシュまたはリングとして、あるいは相互接続されたリングのセットとして構築できます。
The network operator seeks to provide end-to-end connectivity across a network constructed from multiple domains, and so (of course) the domains are interconnected. In a network under management control, such as through an Operations Support System (OSS), each domain is under the operational control of a Network Management System (NMS).
ネットワークオペレーターは、複数のドメインで構成されたネットワーク全体にエンドツーエンドの接続を提供しようとするため、（もちろん）ドメインは相互接続されます。運用サポートシステム（OSS）などの管理制御下にあるネットワークでは、各ドメインはネットワーク管理システム（NMS）の運用制御下にあります。
In this way, an end-to-end path may be commissioned by the OSS instructing each NMS, and the NMSes setting up the path fragments across the domains.
このようにして、エンドツーエンドパスは、OSSが各NMSに指示し、NMSがドメイン全体にパスフラグメントをセットアップすることにより、コミッションされる可能性があります。
However, in a system that uses a control plane, there is a need for integration between the domains.
ただし、コントロールプレーンを使用するシステムでは、ドメイン間の統合が必要です。
Consider a simple domain, D1, as shown in Figure 19. In this case, nodes A through F are arranged in a topological ring. Suppose that there is a control plane in use in this domain and that OSPF is used as the TE routing protocol.
図19に示すように、単純なドメインD1を考えます。この場合、ノードAからFはトポロジーリングに配置されます。このドメインで使用中のコントロールプレーンがあり、TEルーティングプロトコルとしてOSPFが使用されているとします。
-----------------
| D1 |
| B---C |
| / \ |
| / \ |
| A D |
| \ / |
| \ / |
| F---E |
| |
-----------------
Figure 19: A Simple Optical Domain
図19：単純な光学ドメイン
Now consider that the operator's network is built from a mesh of such domains, D1 through D7, as shown in Figure 20. It is possible that these domains share a single, common instance of OSPF, in which case there is nothing further to say because that OSPF instance will distribute sufficient information to build a single TED spanning the whole network, and an end-to-end path can be computed. A more likely scenario is that each domain is running its own OSPF instance. In this case, each is able to handle the peculiarities (or, rather, advanced functions) of each vendor's equipment capabilities.
図20に示すように、オペレーターのネットワークがD1からD7のようなドメインのメッシュから構築されていると考えてください。これらのドメインがOSPFの単一の共通インスタンスを共有している可能性があります。 OSPFインスタンスは、ネットワーク全体にまたがる単一のTEDを構築するのに十分な情報を配布し、エンドツーエンドのパスを計算できます。より可能性の高いシナリオは、各ドメインが独自のOSPFインスタンスを実行していることです。この場合、各ベンダーは、各ベンダーの機器機能の特性（むしろ、高度な機能）を処理できます。
------ ------ ------ ------
| | | | | | | |
| D1 |---| D2 |---| D3 |---| D4 |
| | | | | | | |
------\ ------\ ------\ ------
\ | \ | \ |
\------ \------ \------
| | | | | |
| D5 |---| D6 |---| D7 |
| | | | | |
------ ------ ------
Figure 20: A Mesh of Simple Optical Domains
図20：単純な光学ドメインのメッシュ
The question now is how to combine the multiple sets of information distributed by the different OSPF instances. Three possible models suggest themselves, based on pre-existing routing practices.
ここでの問題は、異なるOSPFインスタンスによって配布された複数の情報セットを組み合わせる方法です。既存のルーティング手法に基づいて、3つのモデルが考えられます。
o In the first model (the area-based model), each domain is treated as a separate OSPF area. The end-to-end path will be specified to traverse multiple areas, and each area will be left to determine the path across the nodes in the area. The feasibility of an end-to-end path (and, thus, the selection of the sequence of areas and their interconnections) can be derived using hierarchical PCEs.
o 最初のモデル（エリアベースモデル）では、各ドメインは個別のOSPFエリアとして扱われます。エンドツーエンドパスは、複数のエリアを横断するように指定され、各エリアは、エリア内のノード間のパスを決定するために残されます。エンドツーエンドパスの実現可能性（したがって、エリアのシーケンスとその相互接続の選択）は、階層型PCEを使用して導出できます。
This approach, however, fits poorly with established use of the OSPF area: in this form of optical network, the interconnection points between domains are likely to be links, and the mesh of domains is far more interconnected and unstructured than we are used to seeing in the normal area-based routing paradigm.
ただし、このアプローチは、OSPFエリアの確立された使用にはあまり適合しません。この形式の光ネットワークでは、ドメイン間の相互接続ポイントはリンクである可能性が高く、ドメインのメッシュは、私たちが見慣れているよりもはるかに相互接続され、構造化されていません。通常のエリアベースのルーティングパラダイムで。
Furthermore, while hierarchical PCEs may be able to resolve this type of network, the effort involved may be considerable for more than a small collection of domains.
さらに、階層型PCEはこのタイプのネットワークを解決できる可能性がありますが、関与する労力はドメインの小さなコレクション以上のものに対して相当なものになる可能性があります。
o Another approach (the AS-based model) treats each domain as a separate Autonomous System (AS). The end-to-end path will be specified to traverse multiple ASes, and each AS will be left to determine the path across the nodes in that AS.
o 別のアプローチ（ASベースのモデル）では、各ドメインを個別の自律システム（AS）として扱います。エンドツーエンドパスは複数のASを通過するように指定され、各ASはそのAS内のノード間のパスを決定するために残されます。
This model sits more comfortably with the established routing paradigm but causes a massive escalation of ASes in the global Internet. It would, in practice, require that the operator use private AS numbers [RFC6996], of which there are plenty.
このモデルは、確立されたルーティングパラダイムに快適に対応できますが、グローバルインターネットでASの大規模なエスカレーションを引き起こします。実際には、事業者はプライベートAS番号[RFC6996]を使用する必要があります。
Then, as suggested in the area-based model, hierarchical PCEs could be used to determine the feasibility of an end-to-end path and to derive the sequence of domains and the points of interconnection to use. But just as in the area-based model, the scalability of this model using a hierarchical PCE must be questioned, given the sheer number of ASes and their interconnectivity.
次に、エリアベースのモデルで提案されているように、階層型PCEを使用して、エンドツーエンドパスの実現可能性を判断し、使用するドメインのシーケンスと相互接続のポイントを導出できます。ただし、エリアベースのモデルと同様に、ASの数とそれらの相互接続性を考慮すると、階層型PCEを使用したこのモデルのスケーラビリティに疑問が生じます。
Furthermore, determining the mesh of domains (i.e., the inter-AS connections) conventionally requires the use of BGP as an inter-domain routing protocol. However, not only is BGP not normally available on optical equipment, but this approach indicates that the TE properties of the inter-domain links would need to be distributed and updated using BGP -- something for which it is not well suited.
さらに、ドメインのメッシュ（つまり、AS間接続）を決定するには、従来、ドメイン間ルーティングプロトコルとしてBGPを使用する必要があります。ただし、BGPが通常光機器で利用できないだけでなく、このアプローチは、ドメイン間リンクのTEプロパティをBGPを使用して配布および更新する必要があることを示しています。
o The third approach (the Automatically Switched Optical Network (ASON) model) follows the architectural model set out by the ITU-T [G.8080] and uses the routing protocol extensions described in [RFC6827]. In this model, the concept of "levels" is introduced to OSPF. Referring back to Figure 20, each OSPF instance running in a domain would be construed as a "lower-level" OSPF instance and would leak routes into a "higher-level" instance of the protocol that runs across the whole network.
o 3番目のアプローチ（自動切り替え光ネットワーク（ASON）モデル）は、ITU-T [G.8080]によって設定されたアーキテクチャモデルに従い、[RFC6827]で説明されているルーティングプロトコル拡張を使用します。このモデルでは、OSPFに「レベル」の概念が導入されています。図20を再び参照すると、ドメインで実行されている各OSPFインスタンスは、「下位レベル」のOSPFインスタンスと解釈され、ネットワーク全体で実行されるプロトコルの「上位」インスタンスにルートをリークします。
This approach handles the awkwardness of representing the domains as areas or ASes by simply considering them as domains running distinct instances of OSPF. Routing advertisements flow "upward" from the domains to the high-level OSPF instance, giving it a full view of the whole network and allowing end-to-end paths to be computed. Routing advertisements may also flow "downward" from the network-wide OSPF instance to any one domain so that it can see the connectivity of the whole network.
このアプローチは、ドメインをOSPFの個別のインスタンスを実行しているドメインと見なすだけで、ドメインをエリアまたはASとして表すという厄介な問題に対処します。ルーティングアドバタイズメントはドメインから上位のOSPFインスタンスに「上向き」に流れ、ネットワーク全体の完全なビューを提供し、エンドツーエンドのパスを計算できるようにします。ルーティングアドバタイズは、ネットワーク全体のOSPFインスタンスから任意の1つのドメインに「下向き」に流れ、ネットワーク全体の接続を確認できます。
Although architecturally satisfying, this model suffers from having to handle the different characteristics of different equipment vendors. The advertisements coming from each low-level domain would be meaningless when distributed into the other domains, and the high-level domain would need to be kept up to date with the semantics of each new release of each vendor's equipment. Additionally, the scaling issues associated with a well-meshed network of domains, each with many entry and exit points and each with network resources that are continually being updated, reduces to the same problem, as noted in the virtual link model. Furthermore, in the event that the domains are under the control of different administrations, the domains would not want to distribute the details of their topologies and TE resources.
アーキテクチャ的には満足のいくものですが、このモデルは、さまざまな機器ベンダーのさまざまな特性を処理する必要があるという欠点があります。各低レベルドメインからのアドバタイズは、他のドメインに配信されても意味がなく、高レベルドメインは、各ベンダーの機器の新しいリリースごとのセマンティクスで最新に保つ必要があります。さらに、ドメインの適切にメッシュ化されたネットワークに関連するスケーリングの問題、それぞれに多数のエントリポイントと出口ポイントがあり、それぞれが継続的に更新されるネットワークリソースがあるため、仮想リンクモデルで指摘されているように、同じ問題が発生します。さらに、ドメインが異なる管理の制御下にある場合、ドメインはトポロジとTEリソースの詳細を配布することを望まないでしょう。
Practically, this third model turns out to be very close to the methodology described in this document. As noted in Section 6.1 of [RFC6827], there are policy rules that can be applied to define exactly what information is exported from or imported to a low-level OSPF instance. [RFC6827] even notes that some forms of aggregation may be appropriate. Thus, we can apply the following simplifications to the mechanisms defined in [RFC6827]:
実際には、この3番目のモデルは、このドキュメントで説明されている方法論に非常に近いことがわかります。 [RFC6827]のセクション6.1に記載されているように、低レベルのOSPFインスタンスからエクスポートまたはインポートされる情報を正確に定義するために適用できるポリシールールがあります。 [RFC6827]は、いくつかの形式の集約が適切であるかもしれないとさえ述べています。したがって、[RFC6827]で定義されているメカニズムに次の簡略化を適用できます。
- Zero information is imported to low-level domains.
- ゼロ情報は低レベルドメインにインポートされます。
- Low-level domains export only abstracted links as defined in this document and according to local abstraction policy, and with appropriate removal of vendor-specific information.
- 低レベルドメインは、このドキュメントで定義されているように、ローカルの抽象化ポリシーに従って抽象化されたリンクのみをエクスポートし、ベンダー固有の情報を適切に削除します。
- There is no need to formally define routing levels within OSPF.
- OSPF内でルーティングレベルを正式に定義する必要はありません。
- Export of abstracted links from the domains to the network-wide routing instance (the abstraction routing layer) can take place through any mechanism, including BGP-LS or direct interaction between OSPF implementations.
- ドメインからネットワーク全体のルーティングインスタンス（抽象化ルーティングレイヤー）への抽象リンクのエクスポートは、BGP-LSやOSPF実装間の直接の相互作用など、任意のメカニズムを通じて実行できます。
With these simplifications, it can be seen that the framework defined in this document can be constructed from the architecture discussed in [RFC6827], but without needing any of the protocol extensions defined in that document. Thus, using the terminology and concepts already established, the problem may be solved as shown in Figure 21. The abstraction layer network is constructed from the inter-domain links, the domain border nodes, and the abstracted (cross-domain) links.
これらの簡素化により、このドキュメントで定義されているフレームワークは、[RFC6827]で説明されているアーキテクチャから構築できることがわかりますが、そのドキュメントで定義されているプロトコル拡張は必要ありません。したがって、すでに確立されている用語と概念を使用して、図21に示すように問題を解決できます。抽象化レイヤーネットワークは、ドメイン間リンク、ドメイン境界ノード、および抽象化された（クロスドメイン）リンクから構築されます。
Abstraction Layer
-- -- -- -- -- --
| |===========| |--| |===========| |--| |===========| |
| | | | | | | | | | | |
..| |...........| |..| |...........| |..| |...........| |......
| | | | | | | | | | | |
| | -- -- | | | | -- -- | | | | -- -- | |
| |_| |_| |_| | | |_| |_| |_| | | |_| |_| |_| |
| | | | | | | | | | | | | | | | | | | | | | | |
-- -- -- -- -- -- -- -- -- -- -- --
Domain 1 Domain 2 Domain 3
Key Optical Layer
... Layer separation
--- Physical link
=== Abstract link
Figure 21: The Optical Network Implemented through the Abstraction Layer Network
図21：アブストラクションレイヤーネットワークを介して実装された光ネットワーク
The User-Network Interface (UNI) is an important architectural concept in many implementations and deployments of client-server networks, especially those where the client and server network have different technologies. The UNI is described in [G.8080], and the GMPLS approach to the UNI is documented in [RFC4208]. Other GMPLS-related documents describe the application of GMPLS to specific UNI scenarios: for example, [RFC6005] describes how GMPLS can support a UNI that provides access to Ethernet services.
ユーザーネットワークインターフェイス（UNI）は、クライアントサーバーネットワークの多くの実装と展開、特にクライアントネットワークとサーバーネットワークに異なるテクノロジが存在する場合の重要なアーキテクチャコンセプトです。 UNIは[G.8080]で説明されており、UNIへのGMPLSアプローチは[RFC4208]で文書化されています。他のGMPLS関連のドキュメントでは、特定のUNIシナリオへのGMPLSの適用について説明しています。たとえば、[RFC6005]は、GMPLSがイーサネットサービスへのアクセスを提供するUNIをサポートする方法を説明しています。
Figure 1 of [RFC6005] is reproduced here as Figure 22. It shows the Ethernet UNI reference model, and that figure can serve as an example for all similar UNIs. In this case, the UNI is an interface between client network edge nodes and the server network. It should be noted that neither the client network nor the server network need be an Ethernet switching network.
[RFC6005]の図1は、ここでは図22として再現されています。これはイーサネットUNI参照モデルを示しており、その図はすべての類似UNIの例として機能します。この場合、UNIはクライアントネットワークエッジノードとサーバーネットワーク間のインターフェイスです。クライアントネットワークもサーバーネットワークもイーサネットスイッチングネットワークである必要はないことに注意してください。
There are three network layers in this model: the client network, the "Ethernet service network", and the server network. The so-called Ethernet service network consists of links comprising the UNI links and the tunnels across the server network, and nodes comprising the client network edge nodes and various server network nodes. That is, the Ethernet service network is equivalent to the abstraction layer network, with the UNI links being the physical links between the client and server networks, the client edge nodes taking the role of UNI Client-side (UNI-C) nodes, and the server edge nodes acting as the UNI Network-side (UNI-N) nodes.
このモデルには、クライアントネットワーク、「イーサネットサービスネットワーク」、およびサーバーネットワークの3つのネットワーク層があります。いわゆるイーサネットサービスネットワークは、サーバーネットワーク全体のUNIリンクとトンネルで構成されるリンクと、クライアントネットワークエッジノードとさまざまなサーバーネットワークノードで構成されるノードで構成されます。つまり、イーサネットサービスネットワークは抽象層ネットワークと同等であり、UNIリンクはクライアントネットワークとサーバーネットワーク間の物理リンクであり、クライアントエッジノードはUNIクライアント側（UNI-C）ノードの役割を果たします。 UNIネットワーク側（UNI-N）ノードとして機能するサーバーエッジノード
Client Client
Network +----------+ +-----------+ Network
-------------+ | | | | +-------------
+----+ | | +-----+ | | +-----+ | | +----+
------+ | | | | | | | | | | | | +------
------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------
| | | +--+--| +-+-+ | | +--+-----+-+ |
+----+ | | | +--+--+ | | | +--+--+ | | +----+
| | | | | | | | | |
-------------+ | | | | | | | | +-------------
| | | | | | | |
-------------+ | | | | | | | | +-------------
| | | +--+--+ | | | +--+--+ | |
+----+ | | | | | | +--+--+ | | | +----+
------+ +-+--+ | | CN +-+----+--+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | | +-----+ | | +-----+ | | | |
+----+ | | | | | | +----+
| +----------+ |-----------+ |
-------------+ Server Networks +-------------
Client UNI UNI Client
Network <-----> <-----> Network
Scope of This Document
Legend: EN - Client Network Edge Node CN - Server Network (Core) Node
ぇげんｄ： えん ー Ｃぃえんｔ ねとぉｒｋ えｄげ ので Ｃん ー せｒゔぇｒ ねとぉｒｋ （これ） ので
Figure 22: Ethernet UNI Reference Model
図22：イーサネットUNI参照モデル
An issue that is often raised relates to how a dual-homed client network edge node (such as that shown at the bottom left-hand corner of Figure 22) can make determinations about how they connect across the UNI. This can be particularly important when reachability across the server network is limited or when two diverse paths are desired (for example, to provide protection). However, in the model described in this network, the edge node (the UNI-C node) is part of the abstraction layer network and can see sufficient topology information to make these decisions. If the approach introduced in this document is used to model the UNI as described in this section, there is no need to enhance the signaling protocols at the GMPLS UNI nor to add routing exchanges at the UNI.
よく発生する問題は、デュアルホームのクライアントネットワークエッジノード（図22の左下隅に示されているノードなど）がUNIを介して接続する方法を決定する方法に関連しています。これは、サーバーネットワーク全体の到達可能性が制限されている場合、または2つの異なるパスが必要な場合（たとえば、保護を提供する場合）に特に重要です。ただし、このネットワークで説明されているモデルでは、エッジノード（UNI-Cノード）は抽象化レイヤーネットワークの一部であり、これらの決定を行うのに十分なトポロジ情報を確認できます。このドキュメントで紹介したアプローチを使用して、このセクションで説明するようにUNIをモデル化する場合、GMPLS UNIでシグナリングプロトコルを拡張したり、UNIでルーティング交換を追加したりする必要はありません。
Serving Layer 3 VPNs (L3VPNs) across a multi-AS or multi-operator environment currently provides a significant planning challenge. Figure 6 shows the general case of the problem that needs to be solved. This section shows how the abstraction layer network can address this problem.
マルチASまたはマルチオペレーター環境全体でレイヤー3 VPN（L3VPN）を提供することは、現在、計画上の大きな課題を提供しています。図6は、解決する必要がある問題の一般的なケースを示しています。このセクションでは、抽象化層ネットワークがこの問題にどのように対処できるかを示します。
In the VPN architecture, the CE nodes are the client network edge nodes, and the PE nodes are the server network edge nodes. The abstraction layer network is made up of the CE nodes, the CE-PE links, the PE nodes, and PE-PE tunnels that are the abstract links.
VPNアーキテクチャでは、CEノードはクライアントネットワークエッジノードであり、PEノードはサーバーネットワークエッジノードです。抽象層ネットワークは、抽象リンクであるCEノード、CE-PEリンク、PEノード、およびPE-PEトンネルで構成されます。
In the multi-AS or multi-operator case, the abstraction layer network also includes the PEs (maybe Autonomous System Border Routers (ASBRs)) at the edges of the multiple server networks, and the PE-PE (maybe inter-AS) links. This gives rise to the architecture shown in Figure 23.
マルチASまたはマルチオペレーターの場合、抽象化レイヤーネットワークには、複数のサーバーネットワークのエッジにあるPE（おそらく自律システムボーダールーター（ASBR））と、PE-PE（AS間）リンクも含まれます。これにより、図23に示すアーキテクチャが生まれます。
The policy for adding abstract links to the abstraction layer network will be driven substantially by the needs of the VPN. Thus, when a new VPN site is added and the existing abstraction layer network cannot support the required connectivity, a new abstract link will be created out of the underlying network.
抽象リンクを抽象レイヤーネットワークに追加するためのポリシーは、実質的にVPNのニーズによって決定されます。したがって、新しいVPNサイトが追加され、既存の抽象化レイヤーネットワークが必要な接続をサポートできない場合、新しい抽象リンクが基本的なネットワークから作成されます。
........... .............
VPN Site : : VPN Site
-- -- : : -- --
|C1|-|CE| : : |CE|-|C2|
-- | | : : | | --
| | : : | |
| | : : | |
| | : : | |
| | : -- -- -- -- : | |
| |----|PE|=========|PE|---|PE|=====|PE|----| |
-- : | | | | | | | | : --
........... | | | | | | | | ............
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | - - | | | | - | |
| |-|P|-|P|-| | | |-|P|-| |
-- - - -- -- - --
Figure 23: The Abstraction Layer Network for a Multi-AS VPN
図23：マルチAS VPNの抽象化レイヤーネットワーク
It is important to note that each VPN instance can have a separate abstraction layer network. This means that the server network resources can be partitioned and that traffic can be kept separate.
各VPNインスタンスが個別の抽象化レイヤーネットワークを持つことができることに注意することが重要です。つまり、サーバーのネットワークリソースを分割して、トラフィックを分離しておくことができます。
This can be achieved even when VPN sites from different VPNs connect at the same PE. Alternatively, multiple VPNs can share the same abstraction layer network if that is operationally preferable.
これは、異なるVPNのVPNサイトが同じPEで接続している場合でも実現できます。または、運用上望ましい場合は、複数のVPNが同じ抽象化レイヤーネットワークを共有できます。
Lastly, just as for the UNI discussed in Section 7, the issue of dual-homing of VPN sites is a function of the abstraction layer network and so is just a normal routing problem in that network.
最後に、セクション7で説明したUNIと同様に、VPNサイトのデュアルホーミングの問題は、抽象化レイヤーネットワークの機能であり、そのネットワークでの通常のルーティング問題にすぎません。
This section is provided to help guide the work on this problem. The overarching view is that it is important to limit and focus the work on those things that are core and necessary to achieve the main function, and to not attempt to add unnecessary features or to over-complicate the architecture or the solution by attempting to address marginal use cases or corner cases. This guidance is non-normative for this architecture description.
このセクションは、この問題の作業をガイドするために提供されています。包括的なビューは、主要な機能を達成するためにコアで必要なものに作業を制限して集中させることが重要であり、不要な機能を追加したり、アーキテクチャやソリューションを過度に複雑にしたりしないようにすることです。限界ユースケースまたはコーナーケース。このガイダンスは、このアーキテクチャの説明では規範的ではありません。
The scope of the use cases and problem statement in this document is limited to "some small set of interconnected domains." In particular, it is not the objective of this work to turn the whole Internet into one large, interconnected TE network.
このドキュメントの使用例と問題の説明の範囲は、「相互接続されたドメインのいくつかの小さなセット」に限定されています。特に、インターネット全体を相互接続された1つの大きなTEネットワークに変えることは、この作業の目的ではありません。
Starting with this subsection, the intention of this work is to solve the TE interconnectivity for only "related" domains. Such domains may be under common administrative operation (such as IGP areas within a single AS, or ASes belonging to a single operator) or may have a direct commercial arrangement for the sharing of TE information to provide specific services. Thus, in both cases, there is a strong opportunity for the application of policy.
このサブセクションから始めて、この作業の目的は、「関連する」ドメインのみのTE相互接続性を解決することです。このようなドメインは、一般的な管理操作（単一のAS内のIGPエリア、または単一のオペレーターに属するASなど）の下にあるか、TE情報を共有して特定のサービスを提供するための直接的な商業的取り決めを持っている場合があります。したがって、どちらの場合でも、ポリシーを適用するための強力な機会があります。
As has been well described in this document, abstraction necessarily involves compromises and removal of information. That means that it is not possible to guarantee that an end-to-end path over interconnected TE domains follows the absolute optimal (by any measure of optimality) path. This is taken as understood, and future work should not attempt to achieve such paths, which can only be found by a full examination of all network information across all connected networks.
このドキュメントで十分に説明されているように、抽象化には必然的に妥協と情報の削除が含まれます。つまり、相互接続されたTEドメイン上のエンドツーエンドのパスが絶対的な（最適性の測定によって）パスに従うことを保証することは不可能です。これは理解されていると見なされ、今後の作業では、接続されているすべてのネットワーク全体のすべてのネットワーク情報を完全に調査することによってのみ見つけることができるようなパスを達成しようとするべきではありません。
All of the above points play into a final observation. This work is intended to "bite off" a small problem for some relatively simple use cases as described in Section 2. It is not intended that this work will be immediately (or even soon) extended to cover many large interconnected domains. Obviously, the solution should, as far as possible, be designed to be extensible and scalable; however, it is also reasonable to make trade-offs in favor of utility and simplicity.
上記のすべてのポイントは、最終的な観察に役立ちます。この作業は、セクション2で説明されているように、いくつかの比較的単純なユースケースの小さな問題を「食い止める」ことを目的としています。この作業がすぐに（またはすぐに）多くの相互接続ドメインをカバーするように拡張されることを意図していません。明らかに、ソリューションは可能な限り拡張可能でスケーラブルに設計する必要があります。ただし、実用性とシンプルさを優先してトレードオフを行うことも妥当です。
Manageability should not be a significant additional burden. Each layer in the network model can, and should, be managed independently.
管理性は、重要な追加の負担であってはなりません。ネットワークモデルの各層は、個別に管理できます。
That is, each client network will run its own management systems and tools to manage the nodes and links in the client network: each client network link that uses an abstract link will still be available for management in the client network as any other link.
つまり、各クライアントネットワークは、独自の管理システムとツールを実行して、クライアントネットワーク内のノードとリンクを管理します。抽象リンクを使用する各クライアントネットワークリンクは、他のリンクと同様にクライアントネットワークで引き続き管理できます。
Similarly, each server network will run its own management systems and tools to manage the nodes and links in that network just as normal.
同様に、各サーバーネットワークは独自の管理システムとツールを実行して、そのネットワーク内のノードとリンクを通常どおりに管理します。
Three issues remain for consideration:
検討すべき問題が3つ残っています。
- How is the abstraction layer network managed?
- 抽象化層ネットワークはどのように管理されますか？
- How is the interface between the client network and the abstraction layer network managed?
- クライアントネットワークと抽象化レイヤーネットワーク間のインターフェイスはどのように管理されますか？
- How is the interface between the abstraction layer network and the server network managed?
- 抽象化レイヤーネットワークとサーバーネットワーク間のインターフェイスはどのように管理されますか？
Management of the abstraction layer network differs from the client and server networks because not all of the links that are visible in the TED are real links. That is, it is not possible to run Operations, Administration, and Maintenance (OAM) on the links that constitute the potential of a link.
TEDに表示されるすべてのリンクが実際のリンクであるとは限らないため、抽象化レイヤーネットワークの管理は、クライアントおよびサーバーネットワークとは異なります。つまり、リンクの可能性を構成するリンク上で運用、管理、および保守（OAM）を実行することはできません。
Other than that, however, the management of the abstraction layer network should be essentially the same. Routing and signaling protocols can be run in the abstraction layer (using out-of-band channels for links that have not yet been established), and a centralized TED can be constructed and used to examine the availability and status of the links and nodes in the network.
それ以外は、抽象層ネットワークの管理は基本的に同じである必要があります。ルーティングおよびシグナリングプロトコルは抽象化レイヤーで実行でき（まだ確立されていないリンクに帯域外チャネルを使用）、集中型TEDを構築して、リンクとノードの可用性とステータスを調べるために使用できますネットワーク。
Note that different deployment models will place the "ownership" of the abstraction layer network differently. In some cases, the abstraction layer network will be constructed by the operator of the server network and run by that operator as a service for one or more client networks. In other cases, one or more server networks will present the potential of links to an abstraction layer network run by the operator of the client network. And it is feasible that a business model could be built where a third-party operator manages the abstraction layer network, constructing it from the connectivity available in multiple server networks and facilitating connectivity for multiple client networks.
配置モデルが異なると、抽象化レイヤーネットワークの「所有権」も異なることに注意してください。場合によっては、抽象化レイヤーネットワークはサーバーネットワークのオペレーターによって構築され、そのオペレーターによって1つ以上のクライアントネットワークのサービスとして実行されます。他の場合では、1つ以上のサーバーネットワークが、クライアントネットワークのオペレーターによって実行される抽象化レイヤーネットワークへのリンクの可能性を示します。また、サードパーティのオペレーターが抽象化レイヤーネットワークを管理し、複数のサーバーネットワークで利用可能な接続からネットワークを構築し、複数のクライアントネットワークの接続を容易にするビジネスモデルを構築することも可能です。
The interaction between the client network and the abstraction layer network is a management task. It might be automated (software driven), or it might require manual intervention.
クライアントネットワークと抽象化層ネットワーク間の相互作用は、管理タスクです。自動化（ソフトウェア駆動）する場合と、手動での介入が必要な場合があります。
This is a two-way interaction:
これは双方向の相互作用です。
- The client network can express the need for additional connectivity. For example, the client network may try, and fail, to find a path across the client network and may request additional, specific connectivity (this is similar to the situation with the Virtual Network Topology Manager (VNTM) [RFC5623]). Alternatively, a more proactive client network management system may monitor traffic demands (current and predicted), network usage, and network "hot spots" and may request changes in connectivity by both releasing unused links and requesting new links.
- クライアントネットワークは、追加の接続の必要性を表現できます。たとえば、クライアントネットワークは、クライアントネットワーク全体のパスを見つけようとして失敗する場合があり、追加の特定の接続を要求する場合があります（これは、Virtual Network Topology Manager（VNTM）[RFC5623]の状況に似ています）。また、より積極的なクライアントネットワーク管理システムは、トラフィックの需要（現在および予測）、ネットワークの使用状況、およびネットワークの「ホットスポット」を監視し、未使用のリンクの解放と新しいリンクの要求の両方によって接続の変更を要求する場合があります。
- The abstraction layer network can make links available to the client network or can withdraw them. These actions can be in response to requests from the client network or can be driven by processes within the abstraction layer (perhaps reorganizing the use of server network resources). In any case, the presentation of new links to the client network is heavily subject to policy, since this is both operationally key to the success of this architecture and the central plank of the commercial model described in this document. Such policies belong to the operator of the abstraction layer network and are expected to be fully configurable.
- アブストラクションレイヤーネットワークは、クライアントネットワークがリンクを利用できるようにしたり、リンクを撤回したりできます。これらのアクションは、クライアントネットワークからの要求に応答することも、抽象化レイヤー内のプロセスによって駆動することもできます（おそらくサーバーネットワークリソースの使用を再編成します）。いずれの場合も、クライアントネットワークへの新しいリンクの提示は、このアーキテクチャの成功とこのドキュメントで説明する商用モデルの中心的な板の両方の運用上重要であるため、ポリシーに強く依存します。このようなポリシーは、アブストラクションレイヤーネットワークのオペレーターに属し、完全に構成可能であることが期待されています。
Once the abstraction layer network has decided to make a link available to the client network, it will install it at the link end points (which are nodes in the client network) such that it appears and can be advertised as a link in the client network.
抽象化層ネットワークは、リンクをクライアントネットワークで利用可能にすることを決定すると、リンクエンドポイント（クライアントネットワークのノード）にインストールして、クライアントネットワークでリンクとして表示され、アドバタイズできるようにします。 。
In all cases, it is important that the operators of both networks are able to track the requests and responses, and the operator of the client network should be able to see which links in that network are "real" physical links and which links are presented by the abstraction layer network.
すべての場合において、両方のネットワークのオペレーターが要求と応答を追跡できることが重要であり、クライアントネットワークのオペレーターは、そのネットワーク内のどのリンクが「実際の」物理リンクであり、どのリンクが提示されているかを確認できる必要があります。抽象化層ネットワークによる。
The interactions between the abstraction layer network and the server network are similar to those described in Section 10.2, but there is a difference in that the server network is more likely to offer up connectivity and the abstraction layer network is less likely to ask for it.
抽象化レイヤーネットワークとサーバーネットワーク間の相互作用は、セクション10.2で説明したものと似ていますが、サーバーネットワークが接続性を提供する可能性が高く、抽象化レイヤーネットワークが接続を要求する可能性が低いという違いがあります。
That is, the server network will, according to policy that may include commercial relationships, offer the abstraction layer network a "set" of potential connectivity that the abstraction layer network can treat as links. This server network policy will include:
つまり、サーバーネットワークは、商業的関係を含む可能性のあるポリシーに従って、抽象化レイヤーネットワークに、抽象化レイヤーネットワークがリンクとして扱うことができる潜在的な接続の「セット」を提供します。このサーバーネットワークポリシーには次のものが含まれます。
- how much connectivity to offer
- 提供する接続性
- what level of server network redundancy to include
- 含めるサーバーネットワークの冗長性のレベル
- how to support the use of the abstract links This process of offering links from the server network may include a mechanism to indicate which links have been pre-established in the server network and can include other properties, such as:
-抽象リンクの使用をサポートする方法サーバーネットワークからリンクを提供するこのプロセスには、サーバーネットワークでどのリンクが事前に確立されているかを示すメカニズムが含まれる場合があり、次のような他のプロパティを含めることができます。
- link-level protection [RFC4202]
- リンクレベルの保護[RFC4202]
- SRLGs and MSRLGs (see Appendix B.1)
- SRLGおよびMSRLG（付録B.1を参照）
- mutual exclusivity (see Appendix B.2)
- 相互排他性（付録B.2を参照）
The abstraction layer network needs a mechanism to tell the server network which links it is using. This mechanism could also include the ability to request additional connectivity from the server network, although it seems most likely that the server network will already have presented as much connectivity as it is physically capable of, subject to the constraints of policy.
抽象化層ネットワークには、使用しているリンクをサーバーネットワークに通知するメカニズムが必要です。このメカニズムには、サーバーネットワークに追加の接続を要求する機能も含まれますが、ポリシーの制約により、サーバーネットワークは物理的に可能な限り多くの接続をすでに提供しているようです。
Finally, the server network will need to confirm the establishment of connectivity, withdraw links if they are no longer feasible, and report failures.
最後に、サーバーネットワークは、接続の確立を確認し、リンクが実現可能でなくなった場合はリンクを撤回し、障害を報告する必要があります。
Again, it is important that the operators of both networks are able to track the requests and responses, and the operator of the server network should be able to see which links are in use.
ここでも、両方のネットワークのオペレーターが要求と応答を追跡でき、サーバーネットワークのオペレーターがどのリンクが使用されているかを確認できることが重要です。
Security of signaling and routing protocols is usually administered and achieved within the boundaries of a domain. Thus, and for example, a domain with a GMPLS control plane [RFC3945] would apply the security mechanisms and considerations that are appropriate to GMPLS [RFC5920]. Furthermore, domain-based security relies strongly on ensuring that control-plane messages are not allowed to enter the domain from outside.
シグナリングおよびルーティングプロトコルのセキュリティは、通常、ドメインの境界内で管理および実現されます。したがって、たとえば、GMPLSコントロールプレーンを備えたドメイン[RFC3945]は、GMPLS [RFC5920]に適切なセキュリティメカニズムと考慮事項を適用します。さらに、ドメインベースのセキュリティは、コントロールプレーンメッセージが外部からドメインに入ることを許可されないようにすることに強く依存しています。
In this context, additional security considerations arising from this document relate to the exchange of control-plane information between domains. Messages are passed between domains using control-plane protocols operating between peers that have predictable relationships (for example, UNI-C to UNI-N, between BGP-LS speakers, or between peer domains). Thus, the security that needs to be given additional attention for inter-domain TE concentrates on authentication of peers; assertion that messages have not been tampered with; and, to a lesser extent, protecting the content of the messages from inspection, since that might give away sensitive information about the networks. The protocols described in Appendix A, which are likely to provide the foundation for solutions to this architecture, already include such protection and also can be run over protected transports such as IPsec [RFC6071], Transport Layer Security (TLS) [RFC5246], and the TCP Authentication Option (TCP-AO) [RFC5925].
このコンテキストでは、このドキュメントから生じる追加のセキュリティの考慮事項は、ドメイン間のコントロールプレーン情報の交換に関連しています。メッセージは、予測可能な関係を持つピア間で動作するコントロールプレーンプロトコルを使用して、ドメイン間で渡されます（たとえば、UNI-CからUNI-N、BGP-LSスピーカー間、またはピアドメイン間）。したがって、ドメイン間TEに追加の注意を払う必要があるセキュリティは、ピアの認証に集中します。メッセージが改ざんされていないという主張;また、ネットワークに関する機密情報を漏らす可能性があるため、メッセージの内容を検査から保護する程度は低くなります。付録Aで説明されているプロトコルは、このアーキテクチャのソリューションの基盤を提供する可能性が高く、すでにそのような保護が含まれており、IPsec [RFC6071]、トランスポート層セキュリティ（TLS）[RFC5246]などの保護されたトランスポート上で実行することもできます。 TCP認証オプション（TCP-AO）[RFC5925]。
It is worth noting that the control plane of the abstraction layer network is likely to be out of band. That is, control-plane messages will be exchanged over network links that are not the links to which they apply. This models the facilities of GMPLS (but not of MPLS-TE), and the security mechanisms can be applied to the protocols operating in the out-of-band network.
抽象層ネットワークのコントロールプレーンが帯域外になる可能性が高いことは注目に値します。つまり、コントロールプレーンメッセージは、メッセージが適用されるリンクではないネットワークリンクを介して交換されます。これはGMPLSの機能をモデル化します（MPLS-TEの機能はモデル化しません）。セキュリティメカニズムは、帯域外ネットワークで動作するプロトコルに適用できます。
[G.8080] International Telecommunication Union, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080/Y.1304, February 2012, <https://www.itu.int/rec/T-REC-G.8080-201202-I/en>.
[G.8080]国際電気通信連合、「自動切り替え光ネットワークのアーキテクチャ」、ITU-T勧告G.8080 / Y.1304、2012年2月、<https://www.itu.int/rec/T-REC -G.8080-201202-I / en>。
[GMPLS-ENNI] Bryskin, I., Ed., Doonan, W., Beeram, V., Ed., Drake, J., Ed., Grammel, G., Paul, M., Kunze, R., Armbruster, F., Margaria, C., Gonzalez de Dios, O., and D. Ceccarelli, "Generalized Multiprotocol Label Switching (GMPLS) External Network Network Interface (E-NNI): Virtual Link Enhancements for the Overlay Model", Work in Progress, draft-beeram-ccamp-gmpls-enni-03, September 2013.
[GMPLS-ENNI]ブリスキン、I。、編、ドゥーナン、W。、ビーラム、V。、編、ドレイク、J。編、グラメル、G。、ポール、M。、クンツェ、R。、アームブルスター、F.、Margaria、C.、Gonzalez de Dios、O。、およびD. Ceccarelli、「Generalized Multiprotocol Label Switching（GMPLS）External Network Network Interface（E-NNI）：Virtual Link Enhancements for the Overlay Model」、Work in進捗状況、draft-beeram-ccamp-gmpls-enni-03、2013年9月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <http://www.rfc-editor.org/info/rfc2702>.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLSを介したトラフィックエンジニアリングの要件」、RFC 2702、DOI 10.17487 / RFC2702、1999年9月、 <http://www.rfc-editor.org/info/rfc2702>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<http：//www.rfc -editor.org/info/rfc3630>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487 / RFC3945、2004年10月、<http://www.rfc-editor.org/info/ rfc3945>。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, DOI 10.17487/RFC4105, June 2005, <http://www.rfc-editor.org/info/rfc4105>.
[RFC4105] Le Roux、J.-L.、Ed。、Vasseur、J.-P.、Ed。、and J. Boyle、Ed。、 "Requirements for Inter-Area MPLS Traffic Engineering"、RFC 4105、DOI 10.17487 / RFC4105、2005年6月、<http://www.rfc-editor.org/info/rfc4105>。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202] Kompella、K。、編、およびY. Rekhter、編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、DOI 10.17487 / RFC4202、2005年10月、<http： //www.rfc-editor.org/info/rfc4202>。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <http://www.rfc-editor.org/info/rfc4206>.
[RFC4206] Kompella、K。およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、DOI 10.17487 / RFC4206、2005年10月、<http ：//www.rfc-editor.org/info/rfc4206>。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, <http://www.rfc-editor.org/info/rfc4208>.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「Generalized Multiprotocol Label Switching（GMPLS）User-Network Interface（UNI）：Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、DOI 10.17487 / RFC4208、2005年10月、<http://www.rfc-editor.org/info/rfc4208>。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, DOI 10.17487/RFC4216, November 2005, <http://www.rfc-editor.org/info/rfc4216>.
[RFC4216] Zhang、R.、Ed。、およびJ.-P. Vasseur編、「MPLS Inter-Autonomous System（AS）Traffic Engineering（TE）Requirements」、RFC 4216、DOI 10.17487 / RFC4216、2005年11月、<http://www.rfc-editor.org/info/rfc4216> 。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。
[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>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：// www.rfc-editor.org/info/rfc4655>。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、DOI 10.17487 / RFC4726、2006年11月、<http：/ /www.rfc-editor.org/info/rfc4726>。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, April 2007, <http://www.rfc-editor.org/info/rfc4847>.
[RFC4847] Takeda、T.、Ed。、 "Framework and Requirements for Layer 1 Virtual Private Networks"、RFC 4847、DOI 10.17487 / RFC4847、April 2007、<http://www.rfc-editor.org/info/rfc4847 >。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC4874] Lee、CY。、Farrel、A。、およびS. De Cnodder、「Exclude Routes-Extension to Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）」、RFC 4874、DOI 10.17487 / RFC4874、2007年4月、< http://www.rfc-editor.org/info/rfc4874>。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, <http://www.rfc-editor.org/info/rfc4920>.
[RFC4920] Farrel、A.、Ed。、Satyanarayana、A.、Iwata、A.、Fujita、N。、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナリング拡張機能」、RFC 4920、DOI 10.17487 / RFC4920、2007年7月、<http://www.rfc-editor.org/info/rfc4920>。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, <http://www.rfc-editor.org/info/rfc5150>.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、JP。、およびA. Farrel、「Generalized Multiprotocol Label Switching Traffic Engineering（GMPLS TE）によるラベルスイッチドパスステッチング」、RFC 5150、DOI 10.17487 / RFC5150、2月2008、<http://www.rfc-editor.org/info/rfc5150>。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、DOI 10.17487 / RFC5152、2008年2月、<http://www.rfc-editor.org/info/rfc5152>。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, DOI 10.17487/RFC5195, June 2008, <http://www.rfc-editor.org/info/rfc5195>.
[RFC5195] Ould-Brahim、H.、Fedyk、D。、およびY. Rekhter、「レイヤ1 VPNのBGPベースの自動検出」、RFC 5195、DOI 10.17487 / RFC5195、2008年6月、<http：// www.rfc-editor.org/info/rfc5195>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, DOI 10.17487/RFC5251, July 2008, <http://www.rfc-editor.org/info/rfc5251>.
[RFC5251] Fedyk、D。、編、Rekhter、Y。、編、Papadimitriou、D.、Rabbat、R。、およびL. Berger、「Layer 1 VPN Basic Mode」、RFC 5251、DOI 10.17487 / RFC5251 2008年7月、<http://www.rfc-editor.org/info/rfc5251>。
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, DOI 10.17487/RFC5252, July 2008, <http://www.rfc-editor.org/info/rfc5252>.
[RFC5252] Bryskin、I。およびL. Berger、「OSPFベースのレイヤー1 VPN自動検出」、RFC 5252、DOI 10.17487 / RFC5252、2008年7月、<http://www.rfc-editor.org/info/ rfc5252>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<http://www.rfc-editor.org/info/rfc5440>。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<http：//www.rfc- editor.org/info/rfc5441>。
[RFC5523] Berger, L., "OSPFv3-Based Layer 1 VPN Auto-Discovery", RFC 5523, DOI 10.17487/RFC5523, April 2009, <http://www.rfc-editor.org/info/rfc5523>.
[RFC5523] Berger、L。、「OSPFv3ベースのレイヤー1 VPN自動検出」、RFC 5523、DOI 10.17487 / RFC5523、2009年4月、<http://www.rfc-editor.org/info/rfc5523>。
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, <http://www.rfc-editor.org/info/rfc5553>.
[RFC5553] Farrel、A.、Ed。、Bradford、R.、JP。 Vasseur、「Resource Reservation Protocol（RSVP）Extensions for Path Key Support」、RFC 5553、DOI 10.17487 / RFC5553、2009年5月、<http://www.rfc-editor.org/info/rfc5553>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖E.、武田T.、ルルーJL、およびA.ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、DOI 10.17487 / RFC5623、2009年9月、<http://www.rfc-editor.org/info/rfc5623>。
[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>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<http://www.rfc-editor.org/info / rfc5925>。
[RFC6005] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)", RFC 6005, DOI 10.17487/RFC6005, October 2010, <http://www.rfc-editor.org/info/rfc6005>.
[RFC6005] Berger、L。およびD. Fedyk、「Metro Ethernet ForumおよびG.8011 User Network Interface（UNI）のGeneralized MPLS（GMPLS）Support」、RFC 6005、DOI 10.17487 / RFC6005、2010年10月、<http：/ /www.rfc-editor.org/info/rfc6005>。
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <http://www.rfc-editor.org/info/rfc6071>.
[RFC6071]フランケルS.およびS.クリシュナン、「IP Security（IPsec）and Internet Key Exchange（IKE）Document Roadmap」、RFC 6071、DOI 10.17487 / RFC6071、2011年2月、<http：//www.rfc-editor .org / info / rfc6071>。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, DOI 10.17487/RFC6107, February 2011, <http://www.rfc-editor.org/info/rfc6107>.
[RFC6107] Shiomoto、K.、Ed。、and A. Farrel、Ed。、 "Procedures for Dynamicly Signaled Hierarchical Label Switched Paths"、RFC 6107、DOI 10.17487 / RFC6107、February 2011、<http：//www.rfc- editor.org/info/rfc6107>。
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド、およびA.ファレル、エド、「MPLSおよびGMPLSにおけるドメインのシーケンスの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、DOI 10.17487 / RFC6805、 2012年11月、<http://www.rfc-editor.org/info/rfc6805>。
[RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, Ed., "Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols", RFC 6827, DOI 10.17487/RFC6827, January 2013, <http://www.rfc-editor.org/info/rfc6827>.
[RFC6827] Malis、A。、編、Lindem、A。、編、およびD. Papadimitriou、編、「OSPFv2プロトコル用の自動切り替え光ネットワーク（ASON）ルーティング」、RFC 6827、DOI 10.17487 / RFC6827、1月2013、<http://www.rfc-editor.org/info/rfc6827>。
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <http://www.rfc-editor.org/info/rfc6996>.
[RFC6996] Mitchell、J。、「プライベート使用のための自律システム（AS）予約」、BCP 6、RFC 6996、DOI 10.17487 / RFC6996、2013年7月、<http://www.rfc-editor.org/info/rfc6996 >。
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <http://www.rfc-editor.org/info/rfc7399>.
[RFC7399] Farrel、A。およびD. King、「Path Computation Element Architectureにおける未回答の質問」、RFC 7399、DOI 10.17487 / RFC7399、2014年10月、<http://www.rfc-editor.org/info/rfc7399 >。
[RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015, <http://www.rfc-editor.org/info/rfc7579>.
[RFC7579] Bernstein、G.、Ed。、Lee、Y.、Ed。、Li、D.、Imajuku、W.、and J. Han、 "General Network Element Constraint Encoding for GMPLS-Controlled Networks"、RFC 7579、 DOI 10.17487 / RFC7579、2015年6月、<http://www.rfc-editor.org/info/rfc7579>。
[RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, "OSPF-TE Extensions for General Network Element Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, <http://www.rfc-editor.org/info/rfc7580>.
[RFC7580] Zhang、F.、Lee、Y.、Han、J.、Bernstein、G。、およびY. Xu、「OSPF-TE Extensions for General Network Element Constraints」、RFC 7580、DOI 10.17487 / RFC7580、June 2015 、<http://www.rfc-editor.org/info/rfc7580>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<http://www.rfc-editor.org/info/rfc7752>。
[RSVP-TE-EXCL] Ali, Z., Ed., Swallow, G., Ed., Zhang, F., Ed., and D. Beller, Ed., "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route", Work in Progress, draft-ietf-teas-lsp-diversity-05, June 2016.
[RSVP-TE-EXCL] Ali、Z.、Ed。、Swallow、G.、Ed。、Zhang、F.、Ed。、and D. Beller、Ed。、 "Resource ReserVation Protocol-Traffic Engineering（RSVP-TE ）除外ルートを使用したパスの多様性」、作業中、draft-ietf-teas-lsp-diversity-05、2016年6月。
[RSVP-TE-EXT] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Hartley, M., Ali, Z., and C. Margaria, "RSVP-TE Extensions for Collecting SRLG Information", Work in Progress, draft-ietf-teas-rsvp-te-srlg-collect-06, May 2016.
[RSVP-TE-EXT] Zhang、F.、Ed。、Gonzalez de Dios、O.、Ed。、Hartley、M.、Ali、Z.、and C. Margaria、 "RSVP-TE Extensions for Collecting SRLG Information" 、Work in Progress、draft-ietf-teas-rsvp-te-srlg-collect-06、2016年5月。
[RSVP-TE-METRIC] Ali, Z., Swallow, G., Filsfils, C., Hartley, M., Kumaki, K., and R. Kunze, "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path", Work in Progress, draft-ietf-teas-te-metric-recording-04, March 2016.
[RSVP-TE-METRIC] Ali、Z.、Swallow、G.、Filsfils、C.、Hartley、M.、Kumaki、K.、R。Kunze、「Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）extensionラベルスイッチドパスのTEメトリックの記録用」、作業中、draft-ietf-teas-te-metric-recording-04、2016年3月。
This appendix briefly summarizes relevant existing work that is used to route TE paths across multiple domains. It is non-normative.
この付録では、複数のドメイン間でTEパスをルーティングするために使用される関連する既存の作業を簡単にまとめています。それは非規範的です。
The mechanism for per-domain path establishment is described in [RFC5152], and its applicability is discussed in [RFC4726]. In summary, this mechanism assumes that each domain entry point is responsible for computing the path across the domain but that details regarding the path in the next domain are left to the next domain entry point. The computation may be performed directly by the entry point or may be delegated to a computation server.
ドメインごとのパス確立のメカニズムは[RFC5152]で説明されており、その適用性は[RFC4726]で議論されています。要約すると、このメカニズムは、各ドメインエントリポイントがドメイン全体のパスの計算を担当するが、次のドメインのパスに関する詳細は次のドメインエントリポイントに任せることを前提としています。計算は、エントリポイントによって直接実行することも、計算サーバーに委任することもできます。
This basic mode of operation can run into many of the issues described alongside the use cases in Section 2. However, in practice it can be used effectively, with a little operational guidance.
この基本的な操作モードでは、セクション2の使用例と一緒に説明されている多くの問題が発生する可能性があります。しかし、実際には、少しの操作ガイダンスで効果的に使用できます。
For example, RSVP-TE [RFC3209] includes the concept of a "loose hop" in the explicit path that is signaled. This allows the original request for an LSP to list the domains or even domain entry points to include on the path. Thus, in the example in Figure 1, the source can be told to use interconnection x2. Then, the source computes the path from itself to x2 and initiates the signaling. When the signaling message reaches Domain Z, the entry point to the domain computes the remaining path to the destination and continues the signaling.
たとえば、RSVP-TE [RFC3209]には、シグナリングされる明示的なパスに「ルーズホップ」の概念が含まれています。これにより、LSPに対する元の要求で、パスに含めるドメインまたはドメインエントリポイントをリストできます。したがって、図1の例では、ソースに相互接続x2を使用するように指示できます。次に、ソースはそれ自体からx2へのパスを計算し、シグナリングを開始します。シグナリングメッセージがドメインZに到達すると、ドメインへのエントリポイントは宛先への残りのパスを計算し、シグナリングを続行します。
Another alternative suggested in [RFC5152] is to make TE routing attempt to follow inter-domain IP routing. Thus, in the example shown in Figure 2, the source would examine the BGP routing information to determine the correct interconnection point for forwarding IP packets and would use that to compute and then signal a path for Domain A. Each domain in turn would apply the same approach so that the path is progressively computed and signaled domain by domain.
[RFC5152]で提案されている別の代替案は、ドメイン間IPルーティングに従うようにTEルーティングを試行することです。したがって、図2に示す例では、ソースはBGPルーティング情報を調べて、IPパケットを転送するための正しい相互接続ポイントを決定し、それを使用してドメインAのパスを計算して信号を送信します。各ドメインは、パスが徐々に計算され、ドメインごとに信号が送られるようにする同じアプローチ。
Although the per-domain approach has many issues and drawbacks in terms of achieving optimal (or, indeed, any) paths, it has been the mainstay of inter-domain LSP setup to date.
ドメインごとのアプローチには、最適な（実際にはすべての）パスを実現するという点で多くの問題と欠点がありますが、これまでドメイン間のLSPセットアップの主力でした。
Crankback addresses one of the main issues with per-domain path computation: What happens when an initial path is selected that cannot be completed toward the destination? For example, what happens if, in Figure 2, the source attempts to route the path through interconnection x2 but Domain C does not have the right TE resources or connectivity to route the path further?
クランクバックは、ドメインごとのパス計算の主な問題の1つに対処します。宛先に向かって完了できない最初のパスが選択された場合はどうなりますか？たとえば、図2で、ソースが相互接続x2を介してパスをルーティングしようとしたが、ドメインCにパスをさらにルーティングするための適切なTEリソースまたは接続がない場合はどうなりますか？
Crankback for MPLS-TE and GMPLS networks is described in [RFC4920] and is based on a concept similar to the Acceptable Label Set mechanism described for GMPLS signaling in [RFC3473]. When a node (i.e., a domain entry point) is unable to compute a path further across the domain, it returns an error message in the signaling protocol that states where the blockage occurred (link identifier, node identifier, domain identifier, etc.) and gives some clues about what caused the blockage (bad choice of label, insufficient bandwidth available, etc.). This information allows a previous computation point to select an alternative path, or to aggregate crankback information and return it upstream to a previous computation point.
MPLS-TEおよびGMPLSネットワークのクランクバックは[RFC4920]で説明されており、[RFC3473]でGMPLSシグナリングについて説明されているAcceptable Label Setメカニズムと同様の概念に基づいています。ノード（つまり、ドメインエントリポイント）がドメイン全体のパスを計算できない場合、閉塞が発生した場所（リンク識別子、ノード識別子、ドメイン識別子など）を示すエラーメッセージがシグナリングプロトコルに返されます。閉塞の原因についての手掛かりをいくつか示します（ラベルの選択の誤り、使用可能な帯域幅の不足など）。この情報により、以前の計算ポイントで代替パスを選択したり、クランクバック情報を集約して上流の以前の計算ポイントに戻したりできます。
Crankback is a very powerful mechanism and can be used to find an end-to-end path in a multi-domain network if one exists.
クランクバックは非常に強力なメカニズムであり、マルチドメインネットワークでエンドツーエンドパスが存在する場合、それを見つけるために使用できます。
On the other hand, crankback can be quite resource-intensive, as signaling messages and path setup attempts may "wander around" in the network, attempting to find the correct path for a long time. Since (1) RSVP-TE signaling ties up network resources for partially established LSPs, (2) network conditions may be in flux, and (3) most particularly, LSP setup within well-known time limits is highly desirable, crankback is not a popular mechanism.
一方、シグナルバックメッセージとパスセットアップの試行がネットワーク内を「あちこち」に移動し、正しいパスを長時間見つけようとするため、クランクバックはかなりのリソースを消費する可能性があります。 （1）RSVP-TEシグナリングは、部分的に確立されたLSPのネットワークリソースを拘束するため、（2）ネットワークの状態が不安定になる可能性があり、（3）特に、既知の制限時間内のLSPセットアップが非常に望ましいため、クランクバックは人気のメカニズム。
Furthermore, even if crankback can always find an end-to-end path, it does not guarantee that the optimal path will be found. (Note that there have been some academic proposals to use signaling-like techniques to explore the whole network in order to find optimal paths, but these tend to place even greater burdens on network processing.)
さらに、クランクバックが常にエンドツーエンドのパスを見つけることができる場合でも、最適なパスが見つかることは保証されません。 （最適なパスを見つけるために、シグナリングのような手法を使用してネットワーク全体を探索するといういくつかの学術的提案がありましたが、これらはネットワーク処理にさらに大きな負担をかける傾向があります。）
The Path Computation Element (PCE) is introduced in [RFC4655]. It is an abstract functional entity that computes paths. Thus, in the example of per-domain path computation (see Appendix A.1), both the source node and each domain entry point are PCEs. On the other hand, the PCE can also be realized as a separate network element (a server) to which computation requests can be sent using the Path Computation Element Communication Protocol (PCEP) [RFC5440].
パス計算要素（PCE）は[RFC4655]で導入されました。パスを計算する抽象的な機能エンティティです。したがって、ドメインごとのパス計算の例（付録A.1を参照）では、ソースノードと各ドメインエントリポイントの両方がPCEです。一方、PCEは、パス計算要素通信プロトコル（PCEP）[RFC5440]を使用して計算要求を送信できる別のネットワーク要素（サーバー）として実現することもできます。
Each PCE is responsible for computations within a domain and has visibility of the attributes within that domain. This immediately enables per-domain path computation with the opportunity to offload complex, CPU-intensive, or memory-intensive computation functions from routers in the network. But the use of PCEs in this way does not solve any of the problems articulated in Appendices A.1 and A.2.
各PCEはドメイン内の計算を担当し、そのドメイン内の属性を可視化します。これにより、ドメインごとのパス計算がすぐに可能になり、複雑なCPU集約型またはメモリ集約型の計算機能をネットワーク内のルーターからオフロードできます。ただし、この方法でPCEを使用しても、付録A.1およびA.2に記載されている問題は解決されません。
Two significant mechanisms for cooperation between PCEs have been described. These mechanisms are intended to specifically address the problems of computing optimal end-to-end paths in multi-domain environments.
PCE間の協力に関する2つの重要なメカニズムが説明されています。これらのメカニズムは、マルチドメイン環境での最適なエンドツーエンドパスの計算の問題に特に対処することを目的としています。
- The Backward-Recursive PCE-Based Computation (BRPC) mechanism [RFC5441] involves cooperation between the set of PCEs along the inter-domain path. Each one computes the possible paths from the domain entry point (or source node) to the domain exit point (or destination node) and shares the information with its upstream neighbor PCE, which is able to build a tree of possible paths rooted at the destination. The PCE in the source domain can select the optimal path.
- 後方再帰PCEベースの計算（BRPC）メカニズム[RFC5441]には、ドメイン間パスに沿ったPCEのセット間の協調が含まれます。それぞれが、ドメインエントリポイント（またはソースノード）からドメイン出口ポイント（または宛先ノード）への可能なパスを計算し、その情報を上流の隣接PCEと共有します。これにより、宛先をルートとする可能なパスのツリーを構築できます。 。ソースドメインのPCEは、最適なパスを選択できます。
BRPC is sometimes described as "crankback at computation time". It is capable of determining the optimal path in a multi-domain network but depends on knowing the domain that contains the destination node. Furthermore, the mechanism can become quite complicated and can involve a lot of data in a mesh of interconnected domains. Thus, BRPC is most often proposed for a simple mesh of domains and specifically for a path that will cross a known sequence of domains, but where there may be a choice of domain interconnections. In this way, BRPC would only be applied to Figure 2 if a decision had been made (externally) to traverse Domain C rather than Domain D (notwithstanding that it could functionally be used to make that choice itself), but BRPC could be used very effectively to select between interconnections x1 and x2 in Figure 1.
BRPCは「計算時のクランクバック」と表現されることもあります。マルチドメインネットワークで最適なパスを決定することができますが、宛先ノードを含むドメインを知ることに依存します。さらに、メカニズムは非常に複雑になり、相互接続されたドメインのメッシュに大量のデータが含まれる可能性があります。したがって、BRPCは、ドメインの単純なメッシュに対して、特にドメインの既知のシーケンスと交差するパスに対して提案されますが、ドメインの相互接続の選択肢がある場合に最もよく提案されます。このように、BRPCは、ドメインDではなくドメインCをトラバースする決定が（外部で）行われた場合にのみ、図2に適用されます（ただし、機能的にその選択自体を行うために使用できます）が、BRPCは非常に使用できます。図1の相互接続x1とx2を効果的に選択します。
- The Hierarchical PCE (H-PCE) [RFC6805] mechanism offers a parent PCE that is responsible for navigating a path across the domain mesh and for coordinating intra-domain computations by the child PCEs responsible for each domain. This approach makes computing an end-to-end path across a mesh of domains far more tractable. However, it still leaves unanswered the issue of determining the location of the destination (i.e., discovering the destination domain) as described in Section 2.1. Furthermore, it raises the question of who operates the parent PCE, especially in networks where the domains are under different administrative and commercial control.
- 階層PCE（H-PCE）[RFC6805]メカニズムは、ドメインメッシュ全体のパスをナビゲートし、各ドメインを担当する子PCEによるドメイン内計算の調整を担当する親PCEを提供します。このアプローチにより、ドメインのメッシュ全体にわたるエンドツーエンドパスの計算がはるかに扱いやすくなります。ただし、セクション2.1で説明されているように、宛先の場所を決定する（つまり、宛先ドメインを検出する）問題は未解決のままです。さらに、特にドメインが異なる管理上および商業上の制御下にあるネットワークでは、誰が親PCEを運用するのかという疑問が生じます。
It should also be noted that [RFC5623] discusses how PCEs are used in a multi-layer network with coordination between PCEs operating at each network layer. Further issues and considerations regarding the use of PCEs can be found in [RFC7399].
また、[RFC5623]は、各ネットワークレイヤで動作するPCE間の調整により、PCEがマルチレイヤネットワークでどのように使用されるかを説明していることにも注意してください。 PCEの使用に関するその他の問題と考慮事項は、[RFC7399]にあります。
[RFC4208] defines the GMPLS User-Network Interface (UNI) to present a routing boundary between an overlay (client) network and the server network, i.e., the client-server interface. In the client network, the nodes connected directly to the server network are known as edge nodes, while the nodes in the server network are called core nodes.
[RFC4208]は、GMPLSユーザーネットワークインターフェース（UNI）を定義して、オーバーレイ（クライアント）ネットワークとサーバーネットワーク、つまりクライアントサーバーインターフェースの間にルーティング境界を提示します。クライアントネットワークでは、サーバーネットワークに直接接続されているノードはエッジノードと呼ばれ、サーバーネットワーク内のノードはコアノードと呼ばれます。
In the overlay model defined by [RFC4208], the core nodes act as a closed system and the edge nodes do not participate in the routing protocol instance that runs among the core nodes. Thus, the UNI allows access to, and limited control of, the core nodes by edge nodes that are unaware of the topology of the core nodes. This respects the operational and layer boundaries while scaling the network.
[RFC4208]で定義されたオーバーレイモデルでは、コアノードはクローズドシステムとして機能し、エッジノードはコアノード間で実行されるルーティングプロトコルインスタンスに参加しません。したがって、UNIは、コアノードのトポロジを認識しないエッジノードによるコアノードへのアクセスと制限された制御を許可します。これは、ネットワークをスケーリングしながら、運用とレイヤーの境界を尊重します。
[RFC4208] does not define any routing protocol extension for the interaction between core and edge nodes but allows for the exchange of reachability information between them. In terms of a VPN, the client network can be considered as the customer network comprised of a number of disjoint sites, and the edge nodes match the VPN CE nodes. Similarly, the provider network in the VPN model is equivalent to the server network.
[RFC4208]は、コアノードとエッジノード間の相互作用のためのルーティングプロトコル拡張を定義していませんが、それらの間の到達可能性情報の交換を許可しています。 VPNに関しては、クライアントネットワークは、多数の独立したサイトで構成されるカスタマーネットワークと考えることができ、エッジノードはVPN CEノードと一致します。同様に、VPNモデルのプロバイダーネットワークはサーバーネットワークと同等です。
[RFC4208] is, therefore, a signaling-only solution that allows edge nodes to request connectivity across the server network and leaves the server network to select the paths for the LSPs as they traverse the core nodes (setting up hierarchical LSPs if necessitated by the technology). This solution is supplemented by a number of signaling extensions, such as [RFC4874], [RFC5553], [RSVP-TE-EXCL], [RSVP-TE-EXT], and [RSVP-TE-METRIC], to give the edge node more control over the path within the server network and by allowing the edge nodes to supply additional constraints on the path used in the server network. Nevertheless, in this UNI/overlay model, the edge node has limited information regarding precisely what LSPs could be set up across the server network and what TE services (diverse routes for end-to-end protection, end-to-end bandwidth, etc.) can be supported.
したがって、[RFC4208]はシグナリングのみのソリューションであり、エッジノードがサーバーネットワーク全体の接続を要求し、サーバーノードがコアノードを通過する際にLSPのパスを選択できるようにします（必要に応じて階層型LSPを設定します）。技術）。このソリューションは、[RFC4874]、[RFC5553]、[RSVP-TE-EXCL]、[RSVP-TE-EXT]、[RSVP-TE-METRIC]などの多くのシグナリング拡張機能によって補完され、エッジを提供しますノードは、サーバーネットワーク内のパスをさらに制御し、エッジノードがサーバーネットワークで使用されるパスに追加の制約を提供できるようにします。それにもかかわらず、このUNI /オーバーレイモデルでは、エッジノードには、サーバーネットワーク全体に設定できるLSPとTEサービス（エンドツーエンド保護、エンドツーエンド帯域幅などのさまざまなルートなど）に関する正確な情報が限られています。 。）をサポートできます。
A Layer 1 VPN (L1VPN) is a service offered by a Layer 1 server network to provide Layer 1 connectivity (Time-Division Multiplexing (TDM), Lambda Switch Capable (LSC)) between two or more customer networks in an overlay service model [RFC4847].
レイヤー1 VPN（L1VPN）は、レイヤー1サーバーネットワークによって提供されるサービスで、オーバーレイサービスモデルの2つ以上の顧客ネットワーク間でレイヤー1接続（時分割多重（TDM）、ラムダスイッチ対応（LSC））を提供します。 RFC4847]。
As in the UNI case, the customer edge has some control over the establishment and type of connectivity. In the L1VPN context, three different service models have been defined, classified by the semantics of information exchanged over the customer interface: the management-based model, the signaling-based (a.k.a. basic) service model, and the signaling and routing (a.k.a. enhanced) service model.
UNIの場合と同様に、カスタマーエッジは接続の確立とタイプをある程度制御します。 L1VPNコンテキストでは、3つの異なるサービスモデルが定義されており、カスタマーインターフェイスを介して交換される情報のセマンティクスによって分類されています。管理ベースのモデル、シグナリングベースの（別名基本）サービスモデル、およびシグナリングとルーティング（別名拡張） ）サービスモデル。
In the management-based model, all edge-to-edge connections are set up using configuration and management tools. This is not a dynamic control-plane solution and need not concern us here.
管理ベースのモデルでは、すべてのエッジツーエッジ接続は、構成ツールと管理ツールを使用してセットアップされます。これは動的なコントロールプレーンソリューションではないため、ここで考慮する必要はありません。
In the signaling-based (basic) service model [RFC5251], the CE-PE interface allows only for signaling message exchange, and the provider network does not export any routing information about the server network. VPN membership is known a priori (presumably through configuration) or is discovered using a routing protocol [RFC5195] [RFC5252] [RFC5523], as is the relationship between CE nodes and ports on the PE. This service model is much in line with GMPLS UNI as defined in [RFC4208].
シグナリングベースの（基本）サービスモデル[RFC5251]では、CE-PEインターフェイスはシグナリングメッセージ交換のみを許可し、プロバイダーネットワークはサーバーネットワークに関するルーティング情報をエクスポートしません。 VPNメンバーシップは、先験的に（おそらく構成によって）知られているか、ルーティングノード[RFC5195] [RFC5252] [RFC5523]を使用して検出されます。これは、CEノードとPE上のポートの関係と同じです。このサービスモデルは、[RFC4208]で定義されているGMPLS UNIとほぼ一致しています。
In the signaling and routing (enhanced) service model, there is an additional limited exchange of routing information over the CE-PE interface between the provider network and the customer network. The enhanced model considers four different types of service models, namely the overlay extension, virtual node, virtual link, and per-VPN service models. All of these represent particular cases of the TE information aggregation and representation.
シグナリングおよびルーティング（拡張）サービスモデルでは、プロバイダーネットワークとカスタマーネットワーク間のCE-PEインターフェイスを介したルーティング情報の交換がさらに制限されます。拡張モデルでは、オーバーレイ拡張、仮想ノード、仮想リンク、およびVPNごとのサービスモデルという4つの異なるタイプのサービスモデルが考慮されます。これらはすべて、TE情報の集約と表現の特定のケースを表しています。
Inter-domain networking relies on policy and management input to coordinate the allocation of resources under different administrative control. [RFC5623] introduces a functional component called the VNTM for this purpose.
ドメイン間ネットワーキングは、ポリシーと管理の入力に依存して、さまざまな管理制御の下でリソースの割り当てを調整します。 [RFC5623]は、この目的のためにVNTMと呼ばれる機能コンポーネントを導入しています。
An important companion to this function is determining how connectivity across the abstraction layer network is made available as a TE link in the client network. Obviously, if the connectivity is established using management intervention, the consequent client network TE link can also be configured manually. However, if connectivity from client edge to client edge is achieved using dynamic signaling, then there is need for the end points to exchange the link properties that they should advertise within the client network, and in the case of support for more than one client network, it will be necessary to indicate which client network or networks can use the link. This capability it provided in [RFC6107].
この機能の重要なコンパニオンは、抽象化レイヤーネットワーク全体の接続をクライアントネットワークのTEリンクとして利用できるようにする方法を決定することです。明らかに、管理介入を使用して接続が確立されている場合、結果として生じるクライアントネットワークTEリンクも手動で構成できます。ただし、ダイナミックシグナリングを使用してクライアントエッジからクライアントエッジへの接続が実現される場合、エンドポイントがクライアントネットワーク内でアドバタイズする必要があるリンクプロパティを交換する必要があり、複数のクライアントネットワークがサポートされている場合、リンクを使用できるクライアントネットワークを指定する必要があります。この機能は、[RFC6107]で提供されていました。
This appendix describes additional features that may be desirable and that can be achieved within this architecture. It is non-normative.
この付録では、このアーキテクチャ内で実現可能な、望ましい機能について説明します。それは非規範的です。
Network links often share fate with one or more other links. That is, a scenario that may cause a link to fail could cause one or more other links to fail. This may occur, for example, if the links are supported by the same fiber bundle, or if some links are routed down the same duct or in a common piece of infrastructure such as a bridge. A common way to identify the links that may share fate is to label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202].
多くの場合、ネットワークリンクは1つ以上の他のリンクと運命を共有します。つまり、リンクが失敗する可能性のあるシナリオでは、1つ以上の他のリンクが失敗する可能性があります。これは、たとえば、リンクが同じファイバーバンドルでサポートされている場合、または一部のリンクが同じダクトを経由してルーティングされている場合や、ブリッジなどのインフラストラクチャの共通部分でルーティングされている場合に発生する可能性があります。運命を共有する可能性のあるリンクを識別する一般的な方法は、リンクを共有リスクリンクグループ（SRLG）[RFC4202]に属するものとしてラベル付けすることです。
TE links created from LSPs in lower layers may also share fate, and it can be hard for a client network to know about this problem because it does not know the topology of the server network or the path of the server network LSPs that are used to create the links in the client network.
下位層のLSPから作成されたTEリンクも運命を共有する可能性があり、サーバーネットワークのトポロジまたはサーバーネットワークLSPのパスがわからないため、クライアントネットワークがこの問題を認識しにくい場合があります。クライアントネットワークにリンクを作成します。
For example, looking at the example used in Section 4.2.3 and considering the two abstract links S1-S3 and S1-S9, there is no way for the client network to know whether links C2-C0 and C2-C3 share fate. Clearly, if the client layer uses these links to provide a link-diverse end-to-end protection scheme, it needs to know that the links actually share a piece of network infrastructure (the server network link S1-S2).
たとえば、セクション4.2.3で使用されている例を見て、2つの抽象リンクS1-S3とS1-S9を検討すると、リンクC2-C0とC2-C3が運命を共有しているかどうかをクライアントネットワークが知る方法はありません。明らかに、クライアントレイヤーがこれらのリンクを使用してリンクの多様なエンドツーエンドの保護スキームを提供する場合、リンクが実際にネットワークインフラストラクチャ（サーバーネットワークリンクS1-S2）を共有していることを知る必要があります。
Per [RFC4202], an SRLG represents a shared physical network resource upon which the normal functioning of a link depends. Multiple SRLGs can be identified and advertised for every TE link in a network. However, this can produce a scalability problem in a multi-layer network that equates to advertising in the client network the server network route of each TE link.
[RFC4202]によると、SRLGは、リンクの通常の機能が依存する共有物理ネットワークリソースを表します。ネットワーク内のすべてのTEリンクについて、複数のSRLGを識別してアドバタイズできます。ただし、これにより、マルチレイヤネットワークでスケーラビリティの問題が発生し、クライアントネットワークでの各TEリンクのサーバーネットワークルートのアドバタイズと同等になる可能性があります。
Macro SRLGs (MSRLGs) address this scaling problem and are a form of abstraction performed at the same time that the abstract links are derived. In this way, links that actually share resources in the server network are advertised as having the same MSRLG, rather than advertising each SRLG for each resource on each path in the server network. This saving is possible because the abstract links are formulated on behalf of the server network by a central management agency that is aware of all of the link abstractions being offered.
マクロSRLG（MSRLG）は、このスケーリングの問題に対処するものであり、抽象リンクの導出と同時に実行される抽象化の形式です。このようにして、サーバーネットワークの各パスの各リソースの各SRLGをアドバタイズするのではなく、サーバーネットワークのリソースを実際に共有するリンクは、同じMSRLGを持つものとしてアドバタイズされます。抽象リンクは、提供されているすべてのリンク抽象化を認識している中央管理機関によってサーバーネットワークに代わって作成されるため、この節約は可能です。
It may be noted that a less optimal alternative path for the abstract link S1-S9 exists in the server network (S1-S4-S7-S8-S9). It would be possible for the client network request for C2-C0 connectivity to also ask that the path be maximally disjoint from path C2-C3. Although nothing can be done about the shared link C2-S1, the abstraction layer could make a request to use link S1-S9 in a way that is diverse from the use of link S1-S3, and this request could be honored if the server network policy allows it.
抽象リンクＳ１〜Ｓ９のより最適ではない代替経路がサーバーネットワーク（Ｓ１〜Ｓ４〜Ｓ７〜Ｓ８〜Ｓ９）に存在することに留意されたい。 C2-C0接続のクライアントネットワーク要求が、パスをパスC2-C3から最大限に切り離すように要求することもできます。共有リンクC2-S1については何も実行できませんが、抽象化レイヤーは、リンクS1-S3の使用とは異なる方法でリンクS1-S9を使用するように要求を行うことができ、この要求はサーバーがネットワークポリシーで許可されています。
Note that SRLGs and MSRLGs may be very hard to describe in the case of multiple server networks because the abstraction points will not know whether the resources in the various server layers share physical locations.
さまざまなサーバーレイヤーのリソースが物理的な場所を共有しているかどうかが抽象化ポイントで認識されないため、複数のサーバーネットワークの場合、SRLGとMSRLGの説明は非常に難しい場合があります。
As noted in the discussion of Figure 13, it is possible that some abstraction layer links cannot be used at the same time. This arises when the potentiality of the links is indicated by the server network, but the use of the links would actually compete for server network resources. Referring to Figure 13, this situation would arise when both link S1-S3 and link S7-S9 are used to carry LSPs: in that case, link S1-S9 could no longer be used.
図13の説明で述べたように、一部の抽象化レイヤーリンクを同時に使用できない場合があります。これは、リンクの可能性がサーバーネットワークによって示されている場合に発生しますが、リンクの使用はサーバーネットワークリソースを実際に競合します。図13を参照すると、この状況は、リンクS1-S3とリンクS7-S9の両方を使用してLSPを伝送する場合に発生します。その場合、リンクS1-S9は使用できなくなります。
Such a situation need not be an issue when client-edge-to-client-edge LSPs are set up one by one, because the use of one abstraction layer link and the corresponding use of server network resources will cause the server network to withdraw the availability of the other abstraction layer links, and these will become unavailable for further abstraction layer path computations.
クライアントエッジからクライアントエッジへのLSPが1つずつ設定されている場合、このような状況は問題ではありません。1つの抽象化レイヤーリンクの使用とサーバーネットワークリソースの対応する使用により、サーバーネットワークが他の抽象化レイヤーリンクの可用性。これらは、さらなる抽象化レイヤーパス計算では利用できなくなります。
Furthermore, in deployments where abstraction layer links are only presented as available after server network LSPs have been established to support them, the problem is unlikely to exist.
さらに、それらをサポートするためにサーバーネットワークLSPが確立された後でのみ抽象化レイヤーリンクが利用可能であるように表示される展開では、問題が発生する可能性はほとんどありません。
However, when the server network is constrained but chooses to advertise the potential of multiple abstraction layer links even though they compete for resources, and when multiple client-edge-to-client-edge LSPs are computed simultaneously (perhaps to provide protection services), there may be contention for server network resources. In the case where protected abstraction layer LSPs are being established, this situation would be avoided through the use of SRLGs and/or MSRLGs, since the two abstraction layer links that compete for server network resources must also fate-share across those resources. But in the case where the multiple client-edge-to-client-edge LSPs do not care about fate sharing, it may be necessary to flag the mutually exclusive links in the abstraction layer TED so that path computation can avoid accidentally attempting to utilize two of a set of such links at the same time.
ただし、サーバーネットワークは制約されているが、リソースを求めて競合している場合でも、複数の抽象化レイヤーリンクの可能性をアドバタイズすることを選択した場合、および複数のクライアントエッジ間LSPが同時に計算される場合（おそらく保護サービスを提供するため）、サーバーネットワークリソースの競合が発生している可能性があります。保護された抽象化レイヤーLSPが確立されている場合、SRLGやMSRLGを使用することでこの状況を回避できます。サーバーネットワークリソースを奪い合う2つの抽象化レイヤーリンクもこれらのリソース間で運命を共有する必要があるためです。しかし、複数のクライアントエッジからクライアントエッジへのLSPが運命の共有を気にしない場合は、抽象化レイヤーTEDで相互に排他的なリンクにフラグを立てて、パス計算で誤って2つを利用しようとしないようにする必要があります。同時にそのようなリンクのセットの。
Acknowledgements
謝辞
Thanks to Igor Bryskin for useful discussions in the early stages of this work and to Gert Grammel for discussions on the extent of aggregation in abstract nodes and links.
この作業の初期の段階で有用な議論をしてくれたIgor Bryskinに、そして抽象ノードとリンクの集約の程度について議論をしてくれたGert Grammelに感謝します。
Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam Somasundaram, Hannes Gredler, Stewart Bryant, Brian Carpenter, and Hilarie Orman for review and input.
レビューと入力をしてくれたDeborah Brungard、Dieter Beller、Dhruv Dhody、Vallinayakam Somasundaram、Hannes Gredler、Stewart Bryant、Brian Carpenter、およびHilarie Ormanに感謝します。
Particular thanks to Vishnu Pavan Beeram for detailed discussions and white-board scribbling that made many of the ideas in this document come to life.
このドキュメントのアイデアの多くを実現した詳細な議論とホワイトボードの落書きについては、特にVishnu Pavan Beeramに感謝します。
Text in Section 4.2.3 is freely adapted from the work of Igor Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel, Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria, Oscar Gonzalez de Dios, and Daniele Ceccarelli in [GMPLS-ENNI], for which the authors of this document express their thanks.
セクション4.2.3のテキストは、Igor Bryskin、Wes Doonan、Vishnu Pavan Beeram、John Drake、Gert Grammel、Manuel Paul、Ruediger Kunze、Friedrich Armbruster、Cyril Margaria、Oscar Gonzalez de Dios、Daniele Ceccarelliの著作から自由に改変されています。 [GMPLS-ENNI]。このドキュメントの作成者に感謝の意を表します。
Contributors
貢献者
Gert Grammel Juniper Networks Email: ggrammel@juniper.net
Gert Grammel Juniper Networksメール：ggrammel@juniper.net
Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net
Vishnu Pavan Beeram Juniper Networksメール：vbeeram@juniper.net
Oscar Gonzalez de Dios Email: ogondio@tid.es
オスカーゴンザレスデディオスメール：ogondio@tid.es
Fatai Zhang Email: zhangfatai@huawei.com
Fatai Zhangメール：zhangfatai@huawei.com
Zafar Ali Email: zali@cisco.com
ドファール、アリメール：Zal@esco.com
Rajan Rao Email: rrao@infinera.com
Rajan Raoメール：rrofinor.com
Sergio Belotti Email: sergio.belotti@alcatel-lucent.com
セルジオベロッティメール：sergio.belotti@alcatel-lucent.com
Diego Caviglia Email: diego.caviglia@ericsson.com
ディエゴカビリアメール：diego.caviglia@ericsson.com
Jeff Tantsura Email: jeff.tantsura@ericsson.com
Jeff Tantsuraメール：jeff.tantsura@ericsson.com
Khuzema Pithewan Email: kpithewan@infinera.com
Khuzema Pithewanメール：kpithewan@infinera.com
Cyril Margaria Email: cyril.margaria@googlemail.com
Cyril Margariaメール：cyril.margaria@googlemail.com
Victor Lopez Email: vlopez@tid.es
ビクターロペスEメール：vlopez@tid.es
Authors' Addresses
著者のアドレス
Adrian Farrel (editor) Juniper Networks
エイドリアン・ファレル（編集者）ジュニパーネットワークス
Email: adrian@olddog.co.uk
John Drake Juniper Networks
ジョンドレイクジュニパーネットワークス
Email: jdrake@juniper.net
Nabil Bitar Nokia
ナビルビタールノキア
Email: nbitar40@gmail.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719
George Swallow Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、MA 01719
Email: swallow@cisco.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Daniele Ceccarelli Ericsson Via A. Negrone 1 / A Genoa-セストリポネンテイタリア
Email: daniele.ceccarelli@ericsson.com
Xian Zhang Huawei Technologies
X Ian Zhang hu Aはテクノロジーです
Email: zhang.xian@huawei.com