[要約] RFC 7491は、アプリケーションベースのネットワークオペレーションのためのPCEベースのアーキテクチャに関するものです。このRFCの目的は、ネットワークオペレーションをアプリケーションの要件に基づいて効率的に実行するための枠組みを提供することです。
Internet Engineering Task Force (IETF) D. King
Request for Comments: 7491 Old Dog Consulting
Category: Informational A. Farrel
ISSN: 2070-1721 Juniper Networks
March 2015
A PCE-Based Architecture for Application-Based Network Operations
アプリケーションベースのネットワーク運用のためのPCEベースのアーキテクチャ
Abstract
概要
Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.
コンテンツ配信、分散データベース、データセンター間接続などのサービスは、ネットワークの運用に一連の新しい要件を課します。さまざまなネットワークアプリケーション（ポイントツーポイント接続、ネットワーク仮想化、モバイルバックホールなど）とネットワーク内のネットワーク接続、信頼性、およびリソース（帯域幅など）のオンデマンドおよびアプリケーション固有の予約が必要です。パケット（IP / MPLS）から光通信までの幅広いネットワーク技術。これらのタイプの要件を満たすように動作する環境には、アプリケーションベースのネットワーク操作（ABNO）があると言われています。 ABNOは多くの既存のテクノロジーを統合し、いくつかの新しい要素で強化された既存のコンポーネントのツールボックスの使用と見なされる場合があります。
This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.
このドキュメントでは、ABNOのアーキテクチャとフレームワークについて説明し、これらのコンポーネントを組み合わせる方法を示します。アーキテクチャを満たし、アプリケーションのニーズを満たすために、既存のテクノロジーのクックブックを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7491.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7491で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................5
2. Application-Based Network Operations (ABNO) .....................6
2.1. Assumptions ................................................6
2.2. Implementation of the Architecture .........................6
2.3. Generic ABNO Architecture ..................................7
2.3.1. ABNO Components .....................................8
2.3.2. Functional Interfaces ..............................15
3. ABNO Use Cases .................................................24
3.1. Inter-AS Connectivity .....................................24
3.2. Multi-Layer Networking ....................................30
3.2.1. Data Center Interconnection across
Multi-Layer Networks ...............................34
3.3. Make-before-Break .........................................37
3.3.1. Make-before-Break for Reoptimization ...............37
3.3.2. Make-before-Break for Restoration ..................38
3.3.3. Make-before-Break for Path Test and Selection ......40
3.4. Global Concurrent Optimization ............................42
3.4.1. Use Case: GCO with MPLS LSPs .......................43
3.5. Adaptive Network Management (ANM) .........................45
3.5.1. ANM Trigger ........................................46
3.5.2. Processing Request and GCO Computation .............46
3.5.3. Automated Provisioning Process .....................47
3.6. Pseudowire Operations and Management ......................48
3.6.1. Multi-Segment Pseudowires ..........................48
3.6.2. Path-Diverse Pseudowires ...........................50
3.6.3. Path-Diverse Multi-Segment Pseudowires .............51
3.6.4. Pseudowire Segment Protection ......................52
3.6.5. Applicability of ABNO to Pseudowires ...............52
3.7. Cross-Stratum Optimization (CSO) ..........................53
3.7.1. Data Center Network Operation ......................53
3.7.2. Application of the ABNO Architecture ...............56
3.8. ALTO Server ...............................................58
3.9. Other Potential Use Cases .................................61
3.9.1. Traffic Grooming and Regrooming ....................61
3.9.2. Bandwidth Scheduling ...............................62
4. Survivability and Redundancy within the ABNO Architecture ......62
5. Security Considerations ........................................63
6. Manageability Considerations ...................................63
7. Informative References .........................................64
Appendix A. Undefined Interfaces ..................................69
Acknowledgements ..................................................70
Contributors ......................................................71
Authors' Addresses ................................................71
Networks today integrate multiple technologies allowing network infrastructure to deliver a variety of services to support the different characteristics and demands of applications. There is an increasing demand to make the network responsive to service requests issued directly from the application layer. This differs from the established model where services in the network are delivered in response to management commands driven by a human user.
今日のネットワークは複数のテクノロジーを統合し、ネットワークインフラストラクチャがさまざまなサービスを提供して、アプリケーションのさまざまな特性と要求をサポートできるようにします。アプリケーション層から直接発行されたサービス要求にネットワークを応答させる要求が高まっています。これは、人間のユーザーによって駆動される管理コマンドに応答してネットワーク内のサービスが提供される確立されたモデルとは異なります。
These application-driven requests and the services they establish place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet this type of application-aware requirement is said to have Application-Based Network Operations (ABNO).
これらのアプリケーション主導の要求とそれらが確立するサービスは、ネットワークの運用に一連の新しい要件を課します。さまざまなネットワークアプリケーション（ポイントツーポイント接続、ネットワーク仮想化、モバイルバックホールなど）とネットワーク内のネットワーク接続、信頼性、およびリソース（帯域幅など）のオンデマンドおよびアプリケーション固有の予約が必要です。パケット（IP / MPLS）から光通信までの幅広いネットワーク技術。このタイプのアプリケーション認識要件を満たすように動作する環境は、アプリケーションベースのネットワーク操作（ABNO）を持つと言われます。
The Path Computation Element (PCE) [RFC4655] was developed to provide path computation services for GMPLS- and MPLS-controlled networks. The applicability of PCEs can be extended to provide path computation and policy enforcement capabilities for ABNO platforms and services.
パス計算要素（PCE）[RFC4655]は、GMPLSおよびMPLS制御ネットワークにパス計算サービスを提供するために開発されました。 PCEの適用性を拡張して、ABNOプラットフォームおよびサービスにパス計算およびポリシー実施機能を提供できます。
ABNO can provide the following types of service to applications by coordinating the components that operate and manage the network:
ABNOは、ネットワークを操作および管理するコンポーネントを調整することにより、次のタイプのサービスをアプリケーションに提供できます。
- Optimization of traffic flows between applications to create an overlay network for communication in use cases such as file sharing, data caching or mirroring, media streaming, or real-time communications described as Application-Layer Traffic Optimization (ALTO) [RFC5693].
- アプリケーション間のトラフィックフローを最適化して、ファイル共有、データキャッシングまたはミラーリング、メディアストリーミング、またはアプリケーションレイヤートラフィック最適化（ALTO）[RFC5693]と呼ばれるリアルタイム通信などのユースケースでの通信用のオーバーレイネットワークを作成します。
- Remote control of network components allowing coordinated programming of network resources through such techniques as Forwarding and Control Element Separation (ForCES) [RFC3746], OpenFlow [ONF], and the Interface to the Routing System (I2RS) [I2RS-Arch], or through the control plane coordinated through the PCE Communication Protocol (PCEP) [PCE-Init-LSP].
- 転送および制御要素分離（ForCES）[RFC3746]、OpenFlow [ONF]、およびルーティングシステムへのインターフェイス（I2RS）[I2RS-Arch]などの手法、またはPCE通信プロトコル（PCEP）[PCE-Init-LSP]を通じて調整されるコントロールプレーン。
- Interconnection of Content Delivery Networks (CDNi) [RFC6707] through the establishment and resizing of connections between content distribution networks. Similarly, ABNO can coordinate inter-data center connections.
- コンテンツ配信ネットワーク間の接続の確立とサイズ変更によるコンテンツ配信ネットワーク（CDNi）[RFC6707]の相互接続。同様に、ABNOはデータセンター間の接続を調整できます。
- Network resource coordination to automate provisioning, and to facilitate traffic grooming and regrooming, bandwidth scheduling, and Global Concurrent Optimization using PCEP [RFC5557].
- プロビジョニングを自動化し、トラフィックのグルーミングとグルーミング、帯域幅のスケジューリング、PCEPを使用したグローバル同時最適化を容易にするためのネットワークリソースの調整[RFC5557]。
- Virtual Private Network (VPN) planning in support of deployment of new VPN customers and to facilitate inter-data center connectivity.
- 新しいVPN顧客の展開をサポートし、データセンター間の接続を容易にする仮想プライベートネットワーク（VPN）計画。
This document outlines the architecture and use cases for ABNO, and shows how the ABNO architecture can be used for coordinating control system and application requests to compute paths, enforce policies, and manage network resources for the benefit of the applications that use the network. The examination of the use cases shows the ABNO architecture as a toolkit comprising many existing components and protocols, and so this document looks like a cookbook. ABNO is compatible with pre-existing Network Management System (NMS) and Operations Support System (OSS) deployments as well as with more recent developments in programmatic networks such as Software-Defined Networking (SDN).
このドキュメントでは、ABNOのアーキテクチャと使用例の概要を説明し、ABNOアーキテクチャを使用して制御システムとアプリケーションの要求を調整し、パスを計算し、ポリシーを適用し、ネットワークを管理して、ネットワークを使用するアプリケーションのためにネットワークリソースを管理する方法を示します。ユースケースを調べると、ABNOアーキテクチャは多くの既存のコンポーネントとプロトコルを含むツールキットとして示されているため、このドキュメントはクックブックのように見えます。 ABNOは、既存のネットワーク管理システム（NMS）と運用サポートシステム（OSS）の展開、およびソフトウェア定義ネットワーク（SDN）などのプログラムによるネットワークの最近の開発と互換性があります。
This document describes a toolkit. It shows how existing functional components described in a large number of separate documents can be brought together within a single architecture to provide the function necessary for ABNO.
このドキュメントでは、ツールキットについて説明します。これは、多数の個別のドキュメントで説明されている既存の機能コンポーネントを単一のアーキテクチャ内にまとめて、ABNOに必要な機能を提供する方法を示しています。
In many cases, existing protocols are known to be good enough or almost good enough to satisfy the requirements of interfaces between the components. In these cases, the protocols are called out as suitable candidates for use within an implementation of ABNO.
多くの場合、既存のプロトコルは、コンポーネント間のインターフェースの要件を満たすのに十分またはほぼ十分であることが知られています。これらの場合、プロトコルはABNOの実装内での使用に適した候補として呼び出されます。
In other cases, it is clear that further work will be required, and in those cases a pointer to ongoing work that may be of use is provided. Where there is no current work that can be identified by the authors, a short description of the missing interface protocol is given in Appendix A.
それ以外の場合は、さらに作業が必要になることは明らかであり、そのような場合には、役立つかもしれない進行中の作業へのポインタが提供されます。著者が特定できる現在の作業がない場合、不足しているインターフェイスプロトコルの簡単な説明を付録Aに示します。
Thus, this document may be seen as providing an applicability statement for existing protocols, and guidance for developers of new protocols or protocol extensions.
したがって、このドキュメントは、既存のプロトコルの適用性に関する記述、および新しいプロトコルまたはプロトコル拡張の開発者向けのガイダンスを提供するものと見なすことができます。
The principal assumption underlying this document is that existing technologies should be used where they are adequate for the task. Furthermore, when an existing technology is almost sufficient, it is assumed to be preferable to make minor extensions rather than to invent a whole new technology.
このドキュメントの根底にある主な前提は、既存のテクノロジーがタスクに適している場合に使用する必要があるということです。さらに、既存の技術で十分な場合は、まったく新しい技術を発明するよりも、少し拡張するほうが望ましいと考えられます。
Note that this document describes an architecture. Functional components are architectural concepts and have distinct and clear responsibilities. Pairs of functional components interact over functional interfaces that are, themselves, architectural concepts.
このドキュメントではアーキテクチャについて説明していることに注意してください。機能コンポーネントはアーキテクチャの概念であり、明確で明確な責任があります。機能コンポーネントのペアは、それ自体がアーキテクチャの概念である機能インターフェースを介して相互作用します。
It needs to be strongly emphasized that this document describes a functional architecture. It is not a software design. Thus, it is not intended that this architecture constrain implementations. However, the separation of the ABNO functions into separate functional components with clear interfaces between them enables implementations to choose which features to include and allows different functions to be distributed across distinct processes or even processors.
このドキュメントは機能的なアーキテクチャを説明していることを強く強調する必要があります。ソフトウェアの設計ではありません。したがって、このアーキテクチャが実装を制約することは意図されていません。ただし、ABNO関数を明確なインターフェイスを備えた個別の機能コンポーネントに分離することにより、実装でどの機能を含めるかを選択し、異なる機能を異なるプロセスまたはプロセッサに分散させることができます。
An implementation of this architecture may make several important decisions about the functional components:
このアーキテクチャーの実装は、機能コンポーネントに関していくつかの重要な決定を行う可能性があります。
- Multiple functional components may be grouped together into one software component such that all of the functions are bundled and only the external interfaces are exposed. This may have distinct advantages for fast paths within the software and can reduce interprocess communication overhead.
- 複数の機能コンポーネントを1つのソフトウェアコンポーネントにグループ化して、すべての機能がバンドルされ、外部インターフェイスのみが公開されるようにすることができます。これには、ソフトウェア内の高速パスに明確な利点があり、プロセス間通信のオーバーヘッドを減らすことができます。
For example, an Active, Stateful PCE could be implemented as a single server combining the ABNO components of the PCE, the Traffic Engineering Database, the Label Switched Path Database, and the Provisioning Manager (see Section 2.3).
たとえば、アクティブなステートフルPCEは、PCEのABNOコンポーネント、トラフィックエンジニアリングデータベース、ラベルスイッチドパスデータベース、プロビジョニングマネージャーを組み合わせた単一サーバーとして実装できます（セクション2.3を参照）。
- The functional components could be distributed across separate processes, processors, or servers so that the interfaces are exposed as external protocols.
- 機能コンポーネントは、インターフェースが外部プロトコルとして公開されるように、別々のプロセス、プロセッサー、またはサーバーに分散させることができます。
For example, the Operations, Administration, and Maintenance (OAM) Handler (see Section 2.3.1.6) could be presented on a dedicated server in the network that consumes all status reports from the network, aggregates them, correlates them, and then dispatches notifications to other servers that need to understand what has happened.
たとえば、Operations、Administration、and Maintenance（OAM）ハンドラー（セクション2.3.1.6を参照）は、ネットワーク内のすべてのステータスレポートを使用し、それらを集約し、それらを関連付けて、通知を送信するネットワーク内の専用サーバーに表示できます。何が起こったかを理解する必要がある他のサーバーに。
- There could be multiple instances of any or each of the components. That is, the function of a functional component could be partitioned across multiple software components with each responsible for handling a specific feature or a partition of the network.
- コンポーネントのいずれかまたはそれぞれの複数のインスタンスが存在する可能性があります。つまり、機能コンポーネントの機能を複数のソフトウェアコンポーネントに分割して、それぞれが特定の機能やネットワークのパーティションを処理することができます。
For example, there may be multiple Traffic Engineering Databases (see Section 2.3.1.8) in an implementation, with each holding the topology information of a separate network domain (such as a network layer or an Autonomous System). Similarly, there could be multiple PCE instances, each processing a different Traffic Engineering Database, and potentially distributed on different servers under different management control. As a final example, there could be multiple ABNO Controllers, each with capability to support different classes of application or application service.
たとえば、実装には複数のトラフィックエンジニアリングデータベース（セクション2.3.1.8を参照）があり、それぞれが個別のネットワークドメイン（ネットワークレイヤーや自律システムなど）のトポロジ情報を保持している場合があります。同様に、複数のPCEインスタンスがあり、それぞれが異なるトラフィックエンジニアリングデータベースを処理し、異なる管理制御下の異なるサーバーに分散される可能性があります。最後の例として、複数のABNOコントローラーがあり、それぞれに異なるクラスのアプリケーションまたはアプリケーションサービスをサポートする機能があります。
The purpose of the description of this architecture is to facilitate different implementations while offering interoperability between implementations of key components, and easy interaction with the applications and with the network devices.
このアーキテクチャの説明の目的は、主要なコンポーネントの実装間の相互運用性、およびアプリケーションやネットワークデバイスとの簡単な相互作用を提供しながら、さまざまな実装を容易にすることです。
Figure 1 illustrates the ABNO architecture. The components and functional interfaces are discussed in Sections 2.3.1 and 2.3.2, respectively. The use cases described in Section 3 show how different components are used selectively to provide different services. It is important to understand that the relationships and interfaces shown between components in this figure are illustrative of some of the common or likely interactions; however, this figure does not preclude other interfaces and relationships as necessary to realize specific functionality.
図1は、ABNOアーキテクチャーを示しています。コンポーネントと機能インターフェイスについては、それぞれセクション2.3.1と2.3.2で説明します。セクション3で説明する使用例は、さまざまなコンポーネントを選択してさまざまなサービスを提供する方法を示しています。この図のコンポーネント間に示されている関係とインターフェースは、一般的な、または可能性のある相互作用の一部を示していることを理解することが重要です。ただし、この図は、特定の機能を実現するために必要な他のインターフェイスや関係を排除するものではありません。
+----------------------------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+-+---+---+----+-----------+---------------------------------+---+
| | | | | |
...|...|...|....|...........|.................................|......
: | | | | +----+----------------------+ | :
: | | | +--+---+ | | +---+---+ :
: | | | |Policy+--+ ABNO Controller +------+ | :
: | | | |Agent | | +--+ | OAM | :
: | | | +-+--+-+ +-+------------+----------+-+ | |Handler| :
: | | | | | | | | | | | :
: | | +-+---++ | +----+-+ +-------+-------+ | | +---+---+ :
: | | |ALTO | +-+ VNTM |--+ | | | | :
: | | |Server| +--+-+-+ | | | +--+---+ | :
: | | +--+---+ | | | PCE | | | I2RS | | :
: | | | +-------+ | | | | |Client| | :
: | | | | | | | | +-+--+-+ | :
: | +-+----+--+-+ | | | | | | | :
: | | Databases +-------:----+ | | | | | :
: | | TED | | +-+---+----+----+ | | | | :
: | | LSP-DB | | | | | | | | | :
: | +-----+--+--+ +-+---------------+-------+-+ | | | :
: | | | | Provisioning Manager | | | | :
: | | | +-----------------+---+-----+ | | | :
...|.......|..|.................|...|....|...|.......|..|.....|......
| | | | | | | | | |
| +-+--+-----------------+--------+-----------+----+ |
+----/ Client Network Layer \--+
| +----------------------------------------------------+ |
| | | | | |
++------+-------------------------+--------+----------+-----+-+
/ Server Network Layers \
+-----------------------------------------------------------------+
Figure 1: Generic ABNO Architecture
図1：一般的なABNOアーキテクチャ
This section describes the functional components shown as boxes in Figure 1. The interactions between those components, the functional interfaces, are described in Section 2.3.2.
このセクションでは、図1でボックスとして示されている機能コンポーネントについて説明します。これらのコンポーネント間の相互作用である機能インターフェースについては、セクション2.3.2で説明します。
A Network Management System (NMS) or an Operations Support System (OSS) can be used to control, operate, and manage a network. Within the ABNO architecture, an NMS or OSS may issue high-level service requests to the ABNO Controller. It may also establish policies for the activities of the components within the architecture.
ネットワーク管理システム（NMS）または運用サポートシステム（OSS）を使用して、ネットワークを制御、操作、および管理できます。 ABNOアーキテクチャー内では、NMSまたはOSSがABNOコントローラーに高レベルのサービス要求を発行できます。また、アーキテクチャ内のコンポーネントのアクティビティのポリシーを確立することもあります。
The NMS and OSS can be consumers of network events reported through the OAM Handler and can act on these reports as well as displaying them to users and raising alarms. The NMS and OSS can also access the Traffic Engineering Database (TED) and Label Switched Path Database (LSP-DB) to show the users the current state of the network.
NMSとOSSは、OAMハンドラーを介して報告されるネットワークイベントのコンシューマーになることができ、これらのレポートを操作するだけでなく、それらをユーザーに表示してアラームを発生させることができます。 NMSおよびOSSは、トラフィックエンジニアリングデータベース（TED）およびラベルスイッチドパスデータベース（LSP-DB）にアクセスして、ユーザーにネットワークの現在の状態を表示することもできます。
Lastly, the NMS and OSS may utilize a direct programmatic or configuration interface to interact with the network elements within the network.
最後に、NMSとOSSは、直接のプログラムインターフェイスまたは構成インターフェイスを利用して、ネットワーク内のネットワーク要素と対話することができます。
In addition to the NMS and OSS, services in the ABNO architecture may be requested by or on behalf of applications. In this context, the term "application" is very broad. An application may be a program that runs on a host or server and that provides services to a user, such as a video conferencing application. Alternatively, an application may be a software tool that a user uses to make requests to the network to set up specific services such as end-to-end connections or scheduled bandwidth reservations. Finally, an application may be a sophisticated control system that is responsible for arranging the provision of a more complex network service such as a virtual private network.
NMSとOSSに加えて、ABNOアーキテクチャのサービスは、アプリケーションによって、またはアプリケーションに代わって要求される場合があります。この文脈では、「アプリケーション」という用語は非常に広範です。アプリケーションは、ホストまたはサーバーで実行され、ビデオ会議アプリケーションなどのユーザーにサービスを提供するプログラムです。あるいは、アプリケーションは、エンドツーエンド接続やスケジュールされた帯域幅予約などの特定のサービスをセットアップするためにユーザーがネットワークに要求を出すために使用するソフトウェアツールである場合があります。最後に、アプリケーションは、仮想プライベートネットワークなどのより複雑なネットワークサービスの提供を手配する高度な制御システムである場合があります。
For the sake of this architecture, all of these concepts of an application are grouped together and are shown as the Application Service Coordinator, since they are all in some way responsible for coordinating the activity of the network to provide services for use by applications. In practice, the function of the Application Service Coordinator may be distributed across multiple applications or servers.
このアーキテクチャーのために、アプリケーションのこれらの概念はすべてグループ化され、アプリケーションサービスコーディネーターとして示されています。これらはすべて、何らかの方法でネットワークのアクティビティを調整して、アプリケーションが使用するサービスを提供する責任があるためです。実際には、アプリケーションサービスコーディネーターの機能は、複数のアプリケーションまたはサーバーに分散されている場合があります。
The Application Service Coordinator communicates with the ABNO Controller to request operations on the network.
アプリケーションサービスコーディネーターはABNOコントローラーと通信して、ネットワーク上の操作を要求します。
The ABNO Controller is the main gateway to the network for the NMS, OSS, and Application Service Coordinator for the provision of advanced network coordination and functions. The ABNO Controller governs the behavior of the network in response to changing network conditions and in accordance with application network requirements and policies. It is the point of attachment, and it invokes the right components in the right order.
ABNOコントローラーは、高度なネットワークの調整と機能を提供するためのNMS、OSS、およびアプリケーションサービスコーディネーターのネットワークへのメインゲートウェイです。 ABNOコントローラーは、ネットワークの状態の変化に応じて、アプリケーションネットワークの要件とポリシーに従って、ネットワークの動作を制御します。これはアタッチメントのポイントであり、適切なコンポーネントを適切な順序で呼び出します。
The use cases in Section 3 provide a clearer picture of how the ABNO Controller interacts with the other components in the ABNO architecture.
セクション3の使用例は、ABNOコントローラーがABNOアーキテクチャーの他のコンポーネントとどのように相互作用するかをより明確に示しています。
Policy plays a very important role in the control and management of the network. It is, therefore, significant in influencing how the key components of the ABNO architecture operate.
ポリシーは、ネットワークの制御と管理において非常に重要な役割を果たします。したがって、ABNOアーキテクチャの主要コンポーネントの動作に影響を与える上で重要です。
Figure 1 shows the Policy Agent as a component that is configured by the NMS/OSS with the policies that it applies. The Policy Agent is responsible for propagating those policies into the other components of the system.
図1は、NMS / OSSが適用するポリシーを使用して構成されたコンポーネントとしてのポリシーエージェントを示しています。ポリシーエージェントは、それらのポリシーをシステムの他のコンポーネントに伝播する責任があります。
Simplicity in the figure necessitates leaving out many of the policy interactions that will take place. Although the Policy Agent is only shown interacting with the ABNO Controller, the ALTO Server, and the Virtual Network Topology Manager (VNTM), it will also interact with a number of other components and the network elements themselves. For example, the Path Computation Element (PCE) will be a Policy Enforcement Point (PEP) [RFC2753] as described in [RFC5394], and the Interface to the Routing System (I2RS) Client will also be a PEP as noted in [I2RS-Arch].
図が単純であるため、実行されるポリシーの相互作用の多くを除外する必要があります。ポリシーエージェントは、ABNOコントローラー、ALTOサーバー、および仮想ネットワークトポロジマネージャー（VNTM）との相互作用のみが示されていますが、他の多くのコンポーネントおよびネットワーク要素自体とも相互作用します。たとえば、[RFC5394]で説明されているように、パス計算要素（PCE）はポリシー実施ポイント（PEP）[RFC2753]であり、[I2RS]で説明されているように、ルーティングシステム（I2RS）クライアントへのインターフェイスもPEPです。 -アーチ]。
The Interface to the Routing System (I2RS) is described in [I2RS-Arch]. The interface provides a programmatic way to access (for read and write) the routing state and policy information on routers in the network.
ルーティングシステム（I2RS）へのインターフェイスは、[I2RS-Arch]で説明されています。このインターフェイスは、ネットワーク内のルーターのルーティング状態とポリシー情報に（読み取りおよび書き込み用に）プログラムでアクセスする方法を提供します。
The I2RS Client is introduced in [I2RS-PS]. Its purpose is to manage information requests across a number of routers (each of which runs an I2RS Agent) and coordinate setting or gathering state to/from those routers.
I2RSクライアントは[I2RS-PS]で導入されました。その目的は、多数のルーター（それぞれがI2RSエージェントを実行する）全体で情報要求を管理し、それらのルーターとの間で状態を収集または収集することを調整することです。
Operations, Administration, and Maintenance (OAM) plays a critical role in understanding how a network is operating, detecting faults, and taking the necessary action to react to problems in the network.
運用、管理、および保守（OAM）は、ネットワークの動作を理解し、障害を検出し、ネットワーク内の問題に対応するために必要なアクションを実行する上で重要な役割を果たします。
Within the ABNO architecture, the OAM Handler is responsible for receiving notifications (often called alerts) from the network about potential problems, for correlating them, and for triggering other components of the system to take action to preserve or recover the services that were established by the ABNO Controller. The OAM Handler also reports network problems and, in particular, service-affecting problems to the NMS, OSS, and Application Service Coordinator.
ABNOアーキテクチャー内では、OAMハンドラーは、潜在的な問題に関するネットワークからの通知（アラートと呼ばれることが多い）の受信、それらの関連付け、およびシステムの他のコンポーネントのトリガーによる、確立されたサービスの保存または回復のためのアクションの実行を担当します。 ABNOコントローラー。 OAMハンドラーは、ネットワークの問題、特にサービスに影響を与える問題もNMS、OSS、およびアプリケーションサービスコーディネーターに報告します。
Additionally, the OAM Handler interacts with the devices in the network to initiate OAM actions within the data plane, such as monitoring and testing.
さらに、OAMハンドラーはネットワーク内のデバイスと対話して、監視やテストなどのデータプレーン内でOAMアクションを開始します。
PCE is introduced in [RFC4655]. It is a functional component that services requests to compute paths across a network graph. In particular, it can generate traffic-engineered routes for MPLS-TE and GMPLS Label Switched Paths (LSPs). The PCE may receive these requests from the ABNO Controller, from the Virtual Network Topology Manager, or from network elements themselves.
PCEは[RFC4655]で導入されました。これは、ネットワークグラフ全体のパスを計算する要求を処理する機能コンポーネントです。特に、MPLS-TEおよびGMPLSラベルスイッチドパス（LSP）のトラフィックエンジニアリングされたルートを生成できます。 PCEは、これらの要求をABNOコントローラー、仮想ネットワークトポロジーマネージャー、またはネットワーク要素自体から受信します。
The PCE operates on a view of the network topology stored in the Traffic Engineering Database (TED). A more sophisticated computation may be provided by a Stateful PCE that enhances the TED with a database (the LSP-DB -- see Section 2.3.1.8.2) containing information about the LSPs that are provisioned and operational within the network as described in [RFC4655] and [Stateful-PCE].
PCEは、トラフィックエンジニアリングデータベース（TED）に格納されているネットワークトポロジのビューで動作します。 [で説明されているようにネットワーク内でプロビジョニングされて動作しているLSPに関する情報を含むデータベース（LSP-DB-セクション2.3.1.8.2を参照）でTEDを拡張するステートフルPCEにより、より高度な計算が提供される場合があります。 RFC4655]および[Stateful-PCE]。
Additional functionality in an Active PCE allows a functional component that includes a Stateful PCE to make provisioning requests to set up new services or to modify in-place services as described in [Stateful-PCE] and [PCE-Init-LSP]. This function may directly access the network elements or may be channeled through the Provisioning Manager.
アクティブPCEの追加機能により、ステートフルPCEを含む機能コンポーネントは、[ステートフルPCE]および[PCE-Init-LSP]で説明されているように、プロビジョニング要求を行って新しいサービスをセットアップしたり、インプレースサービスを変更したりできます。この機能は、ネットワーク要素に直接アクセスすることも、プロビジョニングマネージャを介してチャネル化することもできます。
Coordination between multiple PCEs operating on different TEDs can prove useful for performing path computation in multi-domain or multi-layer networks. A domain in this case might be an Autonomous System (AS), thus enabling inter-AS path computation.
異なるTEDで動作する複数のPCE間の調整は、マルチドメインまたはマルチレイヤーネットワークでパス計算を実行するのに役立ちます。この場合のドメインは自律システム（AS）である可能性があるため、AS間パスの計算が可能になります。
Since the PCE is a key component of the ABNO architecture, a better view of its role can be gained by examining the use cases described in Section 3.
PCEはABNOアーキテクチャの主要なコンポーネントであるため、セクション3で説明されているユースケースを調べることにより、PCEの役割をよりよく理解できます。
The ABNO architecture includes a number of databases that contain information stored for use by the system. The two main databases are the TED and the LSP Database (LSP-DB), but there may be a number of other databases used to contain information about topology (ALTO Server), policy (Policy Agent), services (ABNO Controller), etc.
ABNOアーキテクチャには、システムで使用するために保存された情報を含む多数のデータベースが含まれています。 2つのメインデータベースはTEDとLSPデータベース（LSP-DB）ですが、トポロジ（ALTOサーバー）、ポリシー（ポリシーエージェント）、サービス（ABNOコントローラー）などに関する情報を格納するために使用される他のデータベースがいくつかある場合があります。 。
In the text that follows, specific key components that are consumers of the databases are highlighted. It should be noted that the databases are available for inspection by any of the ABNO components. Updates to the databases should be handled with some care, since allowing multiple components to write to a database can be the cause of a number of contention and sequencing problems.
次のテキストでは、データベースのコンシューマである特定の主要コンポーネントが強調表示されています。データベースは、ABNOコンポーネントのいずれかによる検査に使用できることに注意してください。データベースへの書き込みを複数のコンポーネントに許可すると、多くの競合と順序付けの問題が発生する可能性があるため、データベースの更新は慎重に処理する必要があります。
The TED is a data store of topology information about a network that may be enhanced with capability data (such as metrics or bandwidth capacity) and active status information (such as up/down status or residual unreserved bandwidth).
TEDは、ネットワークに関するトポロジー情報のデータストアであり、機能データ（メトリックや帯域幅容量など）とアクティブステータス情報（アップ/ダウンステータスや予約されていない残りの帯域幅など）で拡張できます。
The TED may be built from information supplied by the network or from data (such as inventory details) sourced through the NMS/OSS.
TEDは、ネットワークから提供された情報、またはNMS / OSSから供給されたデータ（在庫詳細など）から構築できます。
The principal use of the TED in the ABNO architecture is to provide the raw data on which the Path Computation Element operates. But the TED may also be inspected by users at the NMS/OSS to view the current status of the network and may provide information to application services such as Application-Layer Traffic Optimization (ALTO) [RFC5693].
ABNOアーキテクチャでのTEDの主な用途は、パス計算要素が動作する生データを提供することです。しかし、TEDはNMS / OSSのユーザーによって検査されてネットワークの現在のステータスが表示され、アプリケーション層トラフィック最適化（ALTO）[RFC5693]などのアプリケーションサービスに情報が提供される場合があります。
The LSP-DB is a data store of information about LSPs that have been set up in the network or that could be established. The information stored includes the paths and resource usage of the LSPs.
LSP-DBは、ネットワークに設定されている、または確立できるLSPに関する情報のデータストアです。保存される情報には、LSPのパスとリソースの使用状況が含まれます。
The LSP-DB may be built from information generated locally. For example, when LSPs are provisioned, the LSP-DB can be updated. The database can also be constructed from information gathered from the network by polling or reading the state of LSPs that have already been set up.
LSP-DBは、ローカルで生成された情報から構築できます。たとえば、LSPがプロビジョニングされると、LSP-DBを更新できます。データベースは、すでにセットアップされているLSPの状態をポーリングまたは読み取ることにより、ネットワークから収集された情報から構築することもできます。
The main use of the LSP-DB within the ABNO architecture is to enhance the planning and optimization of LSPs. New LSPs can be established to be path-disjoint from other LSPs in order to offer protected services; LSPs can be rerouted in order to put them on more optimal paths or to make network resources available for other LSPs; LSPs can be rapidly repaired when a network failure is reported; LSPs can be moved onto other paths in order to avoid resources that have planned maintenance outages. A Stateful PCE (see Section 2.3.1.7) is a primary consumer of the LSP-DB.
ABNOアーキテクチャー内でのLSP-DBの主な用途は、LSPの計画と最適化を強化することです。新しいLSPは、保護されたサービスを提供するために、他のLSPからパスディスジョイントになるように確立できます。 LSPは、より最適なパスに配置したり、ネットワークリソースを他のLSPが利用できるようにするために再ルーティングできます。 LSPは、ネットワーク障害が報告されたときに迅速に修復できます。 LSPは、メンテナンス停止が計画されているリソースを回避するために、他のパスに移動できます。ステートフルPCE（セクション2.3.1.7を参照）は、LSP-DBの主要なコンシューマーです。
The TED may, itself, be supplemented by SRLG information that assigns to each network resource one or more identifiers that associate the resource with other resources in the same TED that share the same risk of failure.
TED自体は、SRLG情報で補足できます。SRLG情報は、リソースを同じTED内の他のリソースと関連付ける1つ以上の識別子を割り当て、同じ失敗のリスクを共有します。
While this information can be highly useful, it may be supplemented by additional detailed information maintained in a separate database and indexed using the SRLG identifier from the TED. Such a database can interpret SRLG information provided by other networks (such as server networks), can provide failure probabilities associated with each SRLG, can offer prioritization when SRLG-disjoint paths cannot be found, and can correlate SRLGs between different server networks or between different peer networks.
この情報は非常に有用ですが、別のデータベースで維持され、TEDからのSRLG識別子を使用してインデックスが付けられた追加の詳細情報によって補足される場合があります。このようなデータベースは、他のネットワーク（サーバーネットワークなど）から提供されたSRLG情報を解釈し、各SRLGに関連付けられた障害確率を提供し、SRLG非結合パスが見つからない場合に優先順位を提供し、異なるサーバーネットワーク間または異なるサーバー間でSRLGを関連付けることができます。ピアネットワーク。
There may be other databases that are built within the ABNO system and that are referenced when operating the network. These databases might include information about, for example, traffic flows and demands, predicted or scheduled traffic demands, link and node failure and repair history, network resources such as packet labels and physical labels (i.e., MPLS and GMPLS labels), etc.
ABNOシステム内に構築され、ネットワークの操作時に参照される他のデータベースが存在する場合があります。これらのデータベースには、たとえば、トラフィックフローと需要、予測またはスケジュールされたトラフィック需要、リンクとノードの障害と修復履歴、パケットラベルや物理ラベル（MPLSラベルやGMPLSラベルなど）などのネットワークリソースに関する情報が含まれる場合があります。
As mentioned in Section 2.3.1.8.1, the TED may be enhanced by inventory information. It is quite likely in many networks that such an inventory is held in a separate database (the Inventory Database) that includes details of the manufacturer, model, installation date, etc.
セクション2.3.1.8.1で述べたように、TEDは在庫情報によって強化される場合があります。多くのネットワークでは、そのような在庫が、製造元、モデル、設置日などの詳細を含む別個のデータベース（在庫データベース）に保持されている可能性が非常に高いです。
The ALTO Server provides network information to the application layer based on abstract maps of a network region. This information provides a simplified view, but it is useful to steer application-layer traffic. ALTO services enable service providers to share information about network locations and the costs of paths between them. The selection criteria to choose between two locations may depend on information such as maximum bandwidth, minimum cross-domain traffic, lower cost to the user, etc.
ALTOサーバーは、ネットワーク地域の抽象的なマップに基づいて、アプリケーション層にネットワーク情報を提供します。この情報は簡略化されたビューを提供しますが、アプリケーション層のトラフィックを誘導するのに役立ちます。 ALTOサービスを使用すると、サービスプロバイダーはネットワークの場所とそれらの間のパスのコストに関する情報を共有できます。 2つの場所から選択する選択基準は、最大帯域幅、最小のクロスドメイントラフィック、ユーザーへの低コストなどの情報に依存する場合があります。
The ALTO Server generates ALTO views to share information with the Application Service Coordinator so that it can better select paths in the network to carry application-layer traffic. The ALTO views are computed based on information from the network databases, from policies configured by the Policy Agent, and through the algorithms used by the PCE.
ALTOサーバーは、ALTOビューを生成してアプリケーションサービスコーディネーターと情報を共有し、ネットワーク内のパスをより適切に選択して、アプリケーション層トラフィックを伝送できるようにします。 ALTOビューは、ネットワークデータベースからの情報、ポリシーエージェントによって構成されたポリシーからの情報、およびPCEによって使用されるアルゴリズムを介して計算されます。
Specifically, the base ALTO protocol [RFC7285] defines a single-node abstract view of a network to the Application Service Coordinator. Such a view consists of two maps: a network map and a cost map. A network map defines multiple Provider-defined Identifiers (PIDs), which represent entrance points to the network. Each node in the application layer is known as an End Point (EP), and each EP is assigned to a PID, because PIDs are the entry points of the application in the network. As defined in [RFC7285], a PID can denote a subnet, a set of subnets, a metropolitan area, a Point of Presence (PoP), etc. Each such network region can be a single domain or multiple networks; it is just the view that the ALTO Server is exposing to the application layer. A cost map provides costs between EPs and/or PIDs. The criteria that the Application Service Coordinator uses to choose application routes between two locations may depend on attributes such as maximum bandwidth, minimum cross-domain traffic, lower cost to the user, etc.
具体的には、ベースALTOプロトコル[RFC7285]は、アプリケーションサービスコーディネーターへのネットワークの単一ノード抽象ビューを定義します。このようなビューは、ネットワークマップとコストマップの2つのマップで構成されています。ネットワークマップは、ネットワークへの入り口を表す複数のプロバイダー定義識別子（PID）を定義します。アプリケーション層の各ノードはエンドポイント（EP）と呼ばれ、PIDはネットワーク内のアプリケーションのエントリポイントであるため、各EPはPIDに割り当てられます。 [RFC7285]で定義されているように、PIDはサブネット、サブネットのセット、大都市圏、Point of Presence（PoP）などを表すことができます。このような各ネットワーク地域は、単一のドメインまたは複数のネットワークにすることができます。これは、ALTOサーバーがアプリケーション層に公開している単なるビューです。コストマップは、EPやPID間のコストを提供します。 Application Service Coordinatorが2つの場所間のアプリケーションルートを選択するために使用する基準は、最大帯域幅、最小クロスドメイントラフィック、ユーザーへの低コストなどの属性に依存する場合があります。
A Virtual Network Topology (VNT) is defined in [RFC5212] as a set of one or more LSPs in one or more lower-layer networks that provides information for efficient path handling in an upper-layer network. For instance, a set of LSPs in a wavelength division multiplexed (WDM) network can provide connectivity as virtual links in a higher-layer packet-switched network.
仮想ネットワークトポロジ（VNT）は、[RFC5212]で、1つ以上の下位層ネットワークの1つ以上のLSPのセットとして定義され、上位層ネットワークでの効率的なパス処理に関する情報を提供します。たとえば、波長分割多重（WDM）ネットワーク内の一連のLSPは、上位層のパケット交換ネットワーク内の仮想リンクとして接続を提供できます。
The VNT enhances the physical/dedicated links that are available in the upper-layer network and is configured by setting up or tearing down the lower-layer LSPs and by advertising the changes into the higher-layer network. The VNT can be adapted to traffic demands so that capacity in the higher-layer network can be created or released as needed. Releasing unwanted VNT resources makes them available in the lower-layer network for other uses.
VNTは、上位層ネットワークで利用可能な物理/専用リンクを拡張し、下位層LSPをセットアップまたはティアダウンし、上位層ネットワークに変更を通知することによって構成されます。 VNTはトラフィック要求に適合させることができるため、上位層ネットワークの容量を必要に応じて作成または解放できます。不要なVNTリソースを解放すると、下位層ネットワークで他の用途に使用できるようになります。
The creation of virtual topology for inclusion in a network is not a simple task. Decisions must be made about which nodes in the upper layer it is best to connect, in which lower-layer network to provision LSPs to provide the connectivity, and how to route the LSPs in the lower-layer network. Furthermore, some specific actions have to be taken to cause the lower-layer LSPs to be provisioned and the connectivity in the upper-layer network to be advertised.
ネットワークに含める仮想トポロジの作成は簡単な作業ではありません。接続に最適な上位層のノード、接続を提供するためにLSPをプロビジョニングする下位層ネットワーク、および下位層ネットワークでLSPをルーティングする方法について決定する必要があります。さらに、下位層のLSPがプロビジョニングされ、上位層ネットワークの接続がアドバタイズされるようにするには、いくつかの特定のアクションを実行する必要があります。
[RFC5623] describes how the VNTM may instantiate connections in the server layer in support of connectivity in the client layer. Within the ABNO architecture, the creation of new connections may be delegated to the Provisioning Manager as discussed in Section 2.3.1.11.
[RFC5623]は、VNTMがクライアント層での接続をサポートするためにサーバー層で接続をインスタンス化する方法を説明しています。セクション2.3.1.11で説明したように、ABNOアーキテクチャー内では、新しい接続の作成をプロビジョニングマネージャーに委任できます。
All of these actions and decisions are heavily influenced by policy, so the VNTM component that coordinates them takes input from the Policy Agent. The VNTM is also closely associated with the PCE for the upper-layer network and each of the PCEs for the lower-layer networks.
これらのアクションと決定はすべてポリシーの影響を強く受けるため、それらを調整するVNTMコンポーネントはポリシーエージェントから入力を受け取ります。 VNTMは、上位層ネットワークのPCEおよび下位層ネットワークの各PCEとも密接に関連しています。
The Provisioning Manager is responsible for making or channeling requests for the establishment of LSPs. This may be instructions to the control plane running in the networks or may involve the programming of individual network devices. In the latter case, the Provisioning Manager may act as an OpenFlow Controller [ONF].
プロビジョニングマネージャーは、LSPの確立を求める要求の作成またはチャネリングを担当します。これは、ネットワークで実行されているコントロールプレーンへの指示である場合と、個々のネットワークデバイスのプログラミングが含まれる場合があります。後者の場合、プロビジョニングマネージャーはOpenFlowコントローラー[ONF]として機能します。
See Section 2.3.2.6 for more details of the interactions between the Provisioning Manager and the network.
Provisioning Managerとネットワーク間の相互作用の詳細については、セクション2.3.2.6を参照してください。
The client and server networks are shown in Figure 1 as illustrative examples of the fact that the ABNO architecture may be used to coordinate services across multiple networks where lower-layer networks provide connectivity in upper-layer networks.
図1に、クライアントネットワークとサーバーネットワークを示します。ABNOアーキテクチャを使用して、下位層のネットワークが上位層のネットワークに接続を提供する複数のネットワーク間でサービスを調整できることを示しています。
Section 3.2 describes a set of use cases for multi-layer networking.
セクション3.2では、マルチレイヤネットワーキングの一連の使用例について説明します。
This section describes the interfaces between functional components that might be externalized in an implementation allowing the components to be distributed across platforms. Where existing protocols might provide all or most of the necessary capabilities, they are noted. Appendix A notes the interfaces where more protocol specification may be needed.
このセクションでは、コンポーネントをプラットフォーム全体に分散できるようにする実装で外部化できる機能コンポーネント間のインターフェースについて説明します。既存のプロトコルが必要な機能のすべてまたはほとんどを提供する可能性がある場合は、それらが記載されています。付録Aでは、より多くのプロトコル仕様が必要になる可能性のあるインターフェースについて説明しています。
As noted at the top of Section 2.3, it is important to understand that the relationships and interfaces shown between components in Figure 1 are illustrative of some of the common or likely interactions; however, this figure and the descriptions in the subsections below do not preclude other interfaces and relationships as necessary to realize specific functionality. Thus, some of the interfaces described below might not be visible as specific relationships in Figure 1, but they can nevertheless exist.
セクション2.3の冒頭で述べたように、図1のコンポーネント間に示されている関係とインターフェースは、一般的な、または可能性のある相互作用の一部を示していることを理解することが重要です。ただし、この図と以下のサブセクションの説明は、特定の機能を実現するために必要な他のインターフェイスと関係を排除するものではありません。したがって、以下に説明するインターフェースの一部は、図1では特定の関係として表示されていない場合がありますが、それでも存在する可能性があります。
The network devices may be configured or programmed directly from the NMS/OSS. Many protocols already exist to perform these functions, including the following:
ネットワークデバイスは、NMS / OSSから直接設定またはプログラムできます。これらの機能を実行するために、以下を含む多くのプロトコルがすでに存在しています。
- SNMP [RFC3412]
- SNMP [RFC3412]
- The Network Configuration Protocol (NETCONF) [RFC6241]
- ネットワーク構成プロトコル（NETCONF）[RFC6241]
- RESTCONF [RESTCONF]
- RESTCONF [RESTCONF]
- The General Switch Management Protocol (GSMP) [RFC3292]
- 汎用スイッチ管理プロトコル（GSMP）[RFC3292]
- ForCES [RFC5810]
- ForCES [RFC5810]
- OpenFlow [ONF]
- OpenFlow [ONF]
- PCEP [PCE-Init-LSP]
- PCEP [PCE-Init-LSP]
The TeleManagement Forum (TMF) Multi-Technology Operations Systems Interface (MTOSI) standard [TMF-MTOSI] was developed to facilitate application-to-application interworking and provides network-level management capabilities to discover, configure, and activate resources. Initially, the MTOSI information model was only capable of representing connection-oriented networks and resources. In later releases, support was added for connectionless networks. MTOSI is, from the NMS perspective, a north-bound interface and is based on SOAP web services.
TeleManagement Forum（TMF）Multi-Technology Operations Systems Interface（MTOSI）標準[TMF-MTOSI]は、アプリケーション間の相互作用を促進するために開発され、ネットワークレベルの管理機能を提供して、リソースを検出、構成、およびアクティブ化します。当初、MTOSI情報モデルは、接続指向のネットワークとリソースを表すことしかできませんでした。以降のリリースでは、コネクションレス型ネットワークのサポートが追加されました。 MTOSIは、NMSの観点からは、ノースバウンドインターフェイスであり、SOAP Webサービスに基づいています。
From the ABNO perspective, network configuration is a pass-through function. It can be seen represented on the left-hand side of Figure 1.
ABNOの観点からは、ネットワーク構成はパススルー機能です。図1の左側に表示されています。
As described in Section 2.3.1.8, the TED provides details of the capabilities and state of the network for use by the ABNO system and the PCE in particular.
セクション2.3.1.8で説明されているように、TEDは、ABNOシステム、特にPCEが使用するネットワークの機能と状態の詳細を提供します。
The TED can be constructed by participating in the IGP-TE protocols run by the networks (for example, OSPF-TE [RFC3630] and IS-IS TE [RFC5305]). Alternatively, the TED may be fed using link-state distribution extensions to BGP [BGP-LS].
TEDは、ネットワークで実行されるIGP-TEプロトコル（たとえば、OSPF-TE [RFC3630]およびIS-IS TE [RFC5305]）に参加することで構築できます。あるいは、TEDは、BGP [BGP-LS]へのリンク状態配布拡張機能を使用して供給されます。
The ABNO system may maintain a single TED unified across multiple networks or may retain a separate TED for each network.
ABNOシステムは、複数のネットワークにわたって統合された単一のTEDを維持するか、ネットワークごとに個別のTEDを保持します。
Additionally, an ALTO Server [RFC5693] may provide an abstracted topology from a network to build an application-level TED that can be used by a PCE to compute paths between servers and application-layer entities for the provision of application services.
さらに、ALTOサーバー[RFC5693]は、ネットワークから抽象化されたトポロジを提供して、アプリケーションサービスのプロビジョニングのためにサーバーとアプリケーション層エンティティ間のパスを計算するためにPCEで使用できるアプリケーションレベルのTEDを構築できます。
The TED may be enhanced by inventory information supplied from the NMS/OSS. This may supplement the data collected as described in Section 2.3.2.2 with information that is not normally distributed within the network, such as node types and capabilities, or the characteristics of optical links.
TEDは、NMS / OSSから提供される在庫情報によって強化できます。これは、セクション2.3.2.2で説明されているように収集されたデータを、ノードのタイプや機能、または光リンクの特性など、ネットワーク内で通常は配信されない情報で補足する場合があります。
No protocol is currently identified for this interface, but the protocol developed or adopted to satisfy the requirements of the Interface to the Routing System (I2RS) [I2RS-Arch] may be a suitable candidate because it is required to be able to distribute bulk routing state information in a well-defined encoding language. Another candidate protocol may be NETCONF [RFC6241] passing data encoded using YANG [RFC6020].
現在このインターフェースのプロトコルは識別されていませんが、ルーティングシステムへのインターフェース（I2RS）[I2RS-Arch]の要件を満たすために開発または採用されたプロトコルは、バルクルーティングを分散できる必要があるため、適切な候補である可能性があります明確に定義されたエンコーディング言語での状態情報。別の候補プロトコルは、NETCONF [RFC6241]であり、YANG [RFC6020]を使用してエンコードされたデータを渡します。
Note that, in general, any combination of protocol and encoding that is suitable for presenting the TED as described in Section 2.3.2.4 will likely be suitable (or could be made suitable) for enabling write-access to the TED as described in this section.
一般に、セクション2.3.2.4で説明されているTEDの提示に適したプロトコルとエンコーディングの組み合わせは、このセクションで説明されているTEDへの書き込みアクセスを可能にするのに適している（または適切になる可能性がある）ことに注意してください。 。
The TED may be presented north-bound from the ABNO system for use by an NMS/OSS or by the Application Service Coordinator. This allows users and applications to get a view of the network topology and the status of the network resources. It also allows planning and provisioning of application services.
TEDは、NMS / OSSまたはアプリケーションサービスコーディネーターが使用するために、ABNOシステムから北向きに提示されます。これにより、ユーザーとアプリケーションは、ネットワークトポロジとネットワークリソースのステータスを確認できます。また、アプリケーションサービスの計画とプロビジョニングも可能です。
There are several protocols available for exporting the TED north-bound:
TEDノースバウンドのエクスポートに使用できるプロトコルはいくつかあります。
- The ALTO protocol [RFC7285] is designed to distribute the abstracted topology used by an ALTO Server and may prove useful for exporting the TED. The ALTO Server provides the cost between EPs or between PIDs, so the application layer can select which is the most appropriate connection for the information exchange between its application end points.
-ALTOプロトコル[RFC7285]は、ALTOサーバーが使用する抽象化されたトポロジを配布するように設計されており、TEDのエクスポートに役立つ場合があります。 ALTOサーバーは、EP間またはPID間のコストを提供するため、アプリケーションレイヤーは、アプリケーションエンドポイント間の情報交換に最適な接続を選択できます。
- The same protocol used to export topology information from the network can be used to export the topology from the TED [BGP-LS].
- ネットワークからトポロジー情報をエクスポートするために使用されるのと同じプロトコルを使用して、TED [BGP-LS]からトポロジーをエクスポートできます。
- The I2RS [I2RS-Arch] will require a protocol that is capable of handling bulk routing information exchanges that would be suitable for exporting the TED. In this case, it would make sense to have a standardized representation of the TED in a formal data modeling language such as YANG [RFC6020] so that an existing protocol such as NETCONF [RFC6241] or the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] could be used.
- I2RS [I2RS-Arch]には、TEDのエクスポートに適したバルクルーティング情報交換を処理できるプロトコルが必要です。この場合、NETCONF [RFC6241]またはExtensible Messaging and Presence Protocol（XMPP）などの既存のプロトコルになるように、YANG [RFC6020]などの正式なデータモデリング言語でTEDの標準化された表現を持つことは理にかなっています。 RFC6120]を使用できます。
Note that export from the TED can be a full dump of the content (expressed in a suitable abstraction language) as described above, or it could be an aggregated or filtered set of data based on policies or specific requirements. Thus, the relationships shown in Figure 1 may be a little simplistic in that the ABNO Controller may also be involved in preparing and presenting the TED information over a north-bound interface.
TEDからのエクスポートは、上記のように（適切な抽象化言語で表現された）コンテンツの完全なダンプである場合もあれば、ポリシーまたは特定の要件に基づいてデータの集合またはフィルター処理されたセットである場合もあります。したがって、図1に示す関係は、ABNOコントローラーがノースバウンドインターフェイスを介したTED情報の準備と提示にも関与する可能性があるという点で、少し単純化している可能性があります。
As originally specified in the PCE architecture [RFC4655], network elements can make path computation requests to a PCE using PCEP [RFC5440]. This facilitates the network setting up LSPs in response to simple connectivity requests, and it allows the network to reoptimize or repair LSPs.
PCEアーキテクチャ[RFC4655]で最初に指定されたように、ネットワーク要素はPCEP [RFC5440]を使用してPCEへのパス計算要求を行うことができます。これにより、ネットワークは簡単な接続要求に応じてLSPをセットアップしやすくなり、ネットワークがLSPを再最適化または修復できるようになります。
As described in Section 2.3.1.11, the Provisioning Manager makes or channels requests to provision resources in the network. These operations can take place at two levels: there can be requests to program/configure specific resources in the data or forwarding planes, and there can be requests to trigger a set of actions to be programmed with the assistance of a control plane.
2.3.1.11項で説明したように、プロビジョニングマネージャは、ネットワーク内のリソースをプロビジョニングするためのリクエストを作成またはチャネリングします。これらの操作は2つのレベルで実行できます。データプレーンまたは転送プレーンで特定のリソースをプログラム/構成する要求があり、コントロールプレーンの支援によりプログラムされる一連のアクションをトリガーする要求がある場合があります。
A number of protocols already exist to provision network resources, as follows:
次のように、ネットワークリソースをプロビジョニングするためのプロトコルはすでにいくつか存在します。
o Program/configure specific network resources
o 特定のネットワークリソースのプログラム/構成
- ForCES [RFC5810] defines a protocol for separation of the control element (the Provisioning Manager) from the forwarding elements in each node in the network.
- ForCES [RFC5810]は、ネットワーク内の各ノードの転送要素から制御要素（プロビジョニングマネージャ）を分離するためのプロトコルを定義しています。
- The General Switch Management Protocol (GSMP) [RFC3292] is an asymmetric protocol that allows one or more external switch controllers (such as the Provisioning Manager) to establish and maintain the state of a label switch such as an MPLS switch.
- General Switch Management Protocol（GSMP）[RFC3292]は、1つ以上の外部スイッチコントローラー（Provisioning Managerなど）がMPLSスイッチなどのラベルスイッチの状態を確立および維持できるようにする非対称プロトコルです。
- OpenFlow [ONF] is a communications protocol that gives an OpenFlow Controller (such as the Provisioning Manager) access to the forwarding plane of a network switch or router in the network.
- OpenFlow [ONF]は、OpenFlowコントローラー（プロビジョニングマネージャーなど）に、ネットワーク内のネットワークスイッチまたはルーターの転送プレーンへのアクセスを提供する通信プロトコルです。
- Historically, other configuration-based mechanisms have been used to set up the forwarding/switching state at individual nodes within networks. Such mechanisms have ranged from non-standard command line interfaces (CLIs) to various standards-based options such as Transaction Language 1 (TL1) [TL1] and SNMP [RFC3412]. These mechanisms are not designed for rapid operation of a network and are not easily programmatic. They are not proposed for use by the Provisioning Manager as part of the ABNO architecture.
- これまで、ネットワーク内の個々のノードで転送/スイッチング状態を設定するために、他の構成ベースのメカニズムが使用されてきました。このようなメカニズムは、非標準のコマンドラインインターフェイス（CLI）から、トランザクション言語1（TL1）[TL1]やSNMP [RFC3412]などのさまざまな標準ベースのオプションにまで及んでいます。これらのメカニズムは、ネットワークの迅速な運用を目的として設計されておらず、簡単にプログラム化することはできません。これらは、プロビジョニングマネージャーによるABNOアーキテクチャの一部としての使用は提案されていません。
- NETCONF [RFC6241] provides a more active configuration protocol that may be suitable for bulk programming of network resources. Its use in this way is dependent on suitable YANG modules being defined for the necessary options. Early work in the IETF's NETMOD working group is focused on a higher level of routing function more comparable with the function discussed in Section 2.3.2.8; see [YANG-Rtg].
- NETCONF [RFC6241]は、ネットワークリソースの一括プログラミングに適した、よりアクティブな構成プロトコルを提供します。この方法での使用は、必要なオプションに対して定義されている適切なYANGモジュールに依存しています。 IETFのNETMODワーキンググループでの初期の作業は、セクション2.3.2.8で説明した機能と比較できる、より高いレベルのルーティング機能に焦点を当てています。 [YANG-Rtg]を参照してください。
- The [TMF-MTOSI] specification provides provisioning, activation, deactivation, and release of resources via the Service Activation Interface (SAI). The Common Communication Vehicle (CCV) is the middleware required to implement MTOSI. The CCV is then used to provide middleware abstraction in combination with the Web Services Description Language (WSDL) to allow MTOSIs to be bound to different middleware technologies as needed.
- [TMF-MTOSI]仕様は、Service Activation Interface（SAI）を介したリソースのプロビジョニング、アクティブ化、非アクティブ化、およびリリースを提供します。 Common Communication Vehicle（CCV）は、MTOSIの実装に必要なミドルウェアです。次にCCVを使用して、Webサービス記述言語（WSDL）と組み合わせてミドルウェアを抽象化し、必要に応じてMTOSIをさまざまなミドルウェアテクノロジーにバインドできます。
o Trigger actions through the control plane
o コントロールプレーンを介してアクションをトリガーする
- LSPs can be requested using a management system interface to the head end of the LSP using tools such as CLIs, TL1 [TL1], or SNMP [RFC3412]. Configuration at this granularity is not as time-critical as when individual network resources are programmed, because the main task of programming end-to-end connectivity is devolved to the control plane. Nevertheless, these mechanisms remain unsuitable for programmatic control of the network and are not proposed for use by the Provisioning Manager as part of the ABNO architecture.
- LSPは、CLI、TL1 [TL1]、SNMP [RFC3412]などのツールを使用して、LSPのヘッドエンドへの管理システムインターフェイスを使用して要求できます。エンドツーエンドの接続をプログラミングする主なタスクはコントロールプレーンに委譲されるため、この粒度での構成は、個々のネットワークリソースがプログラミングされるときほど重要ではありません。それでも、これらのメカニズムはネットワークのプログラムによる制御には依然として不適切であり、プロビジョニングマネージャーによるABNOアーキテクチャの一部としての使用は提案されていません。
- As noted above, NETCONF [RFC6241] provides a more active configuration protocol. This may be particularly suitable for requesting the establishment of LSPs. Work would be needed to complete a suitable YANG module.
- 上記のように、NETCONF [RFC6241]はよりアクティブな構成プロトコルを提供します。これは、LSPの確立を要求する場合に特に適しています。適切なYANGモジュールを完成させるには、作業が必要になります。
- The PCE Communication Protocol (PCEP) [RFC5440] has been proposed as a suitable protocol for requesting the establishment of LSPs [PCE-Init-LSP]. This works well, because the protocol elements necessary are exactly the same as those used to respond to a path computation request.
- PCE通信プロトコル（PCEP）[RFC5440]は、LSPの確立を要求するための適切なプロトコルとして提案されています[PCE-Init-LSP]。必要なプロトコル要素はパス計算要求への応答に使用されるものとまったく同じであるため、これはうまく機能します。
The functional element that issues PCEP requests to establish LSPs is known as an "Active PCE"; however, it should be noted that the ABNO functional component responsible for requesting LSPs is the Provisioning Manager. Other controllers like the VNTM and the ABNO Controller use the services of the Provisioning Manager to isolate the twin functions of computing and requesting paths from the provisioning mechanisms in place with any given network.
LSPを確立するためにPCEP要求を発行する機能要素は、「アクティブPCE」として知られています。ただし、LSPの要求を担当するABNO機能コンポーネントはプロビジョニングマネージャであることに注意してください。 VNTMやABNOコントローラーのような他のコントローラーは、プロビジョニングマネージャーのサービスを使用して、特定のネットワークに配置されているプロビジョニングメカニズムから、計算とリクエストの2つの機能を分離します。
Note that I2RS does not provide a mechanism for control of network resources at this level, as it is designed to provide control of routing state in routers, not forwarding state in the data plane.
I2RSは、データプレーンの転送状態ではなく、ルーターのルーティング状態の制御を提供するように設計されているため、このレベルでネットワークリソースを制御するメカニズムを提供しないことに注意してください。
Once resources have been provisioned or connections established in the network, it is important that the ABNO system can determine the state of the network. Similarly, when provisioned resources are modified or taken out of service, the changes in the network need to be understood by the ABNO system. This function falls into four categories:
リソースがプロビジョニングされるか、ネットワークで接続が確立されたら、ABNOシステムがネットワークの状態を判別できることが重要です。同様に、プロビジョニングされたリソースが変更またはサービスから除外された場合、ネットワークの変更をABNOシステムで理解する必要があります。この関数は4つのカテゴリに分類されます。
- Updates to the TED are gathered as described in Section 2.3.2.2.
- セクション2.3.2.2で説明されているように、TEDの更新が収集されます。
- Explicit notification of the successful establishment and the subsequent state of the LSP can be provided through extensions to PCEP as described in [Stateful-PCE] and [PCE-Init-LSP].
- [Stateful-PCE]および[PCE-Init-LSP]で説明されているように、PCEPへの拡張を通じて、LSPの正常な確立とそれに続く状態の明示的な通知を提供できます。
- OAM can be commissioned and the results inspected by the OAM Handler as described in Section 2.3.2.14.
- セクション2.3.2.14で説明されているように、OAMを委託して結果をOAMハンドラーで検査できます。
- A number of ABNO components may make inquiries and inspect network state through a variety of techniques, including I2RS, NETCONF, or SNMP.
- 多くのABNOコンポーネントは、I2RS、NETCONF、SNMPなどのさまざまな手法を使用して問い合わせを行い、ネットワークの状態を検査します。
As discussed in Section 2.3.1.5, the Interface to the Routing System (I2RS) provides a programmatic way to access (for read and write) the routing state and policy information on routers in the network. The I2RS Client issues requests to routers in the network to establish or retrieve routing state. Those requests utilize the I2RS protocol, which will be based on a combination of NETCONF [RFC6241] and RESTCONF [RESTCONF] with some additional features.
セクション2.3.1.5で説明したように、ルーティングシステムへのインターフェース（I2RS）は、ネットワーク内のルーターのルーティング状態とポリシー情報に（読み取りおよび書き込み用に）プログラムでアクセスする方法を提供します。 I2RSクライアントは、ネットワーク内のルーターに要求を発行して、ルーティング状態を確立または取得します。これらのリクエストは、NETCONF [RFC6241]とRESTCONF [RESTCONF]といくつかの追加機能の組み合わせに基づくI2RSプロトコルを利用します。
The ABNO Controller needs to be able to consult the PCE to determine what services can be provisioned in the network. There is no reason why this interface cannot be based on standard PCEP as defined in [RFC5440].
ABNOコントローラーは、PCEを参照して、ネットワークでプロビジョニングできるサービスを判別できる必要があります。 [RFC5440]で定義されているように、このインターフェイスが標準のPCEPに基づくことができない理由はありません。
There are two interactions between the Virtual Network Topology Manager and the PCE:
Virtual Network Topology ManagerとPCEの間には2つの相互作用があります。
The first interaction is used when VNTM wants to determine what LSPs can be set up in a network: in this case, it uses the standard PCEP interface [RFC5440] to make path computation requests.
最初の対話は、VNTMがネットワークにセットアップできるLSPを決定するときに使用されます。この場合、標準のPCEPインターフェイス[RFC5440]を使用してパス計算要求を行います。
The second interaction arises when a PCE determines that it cannot compute a requested path or notices that (according to some configured policy) a network is low on resources (for example, the capacity on some key link is nearly exhausted). In this case, the PCE may notify the VNTM, which may (again according to policy) act to construct more virtual topology. This second interface is not currently specified, although it may be that the protocol selected or designed to satisfy I2RS will provide suitable features (see Section 2.3.2.8); alternatively, an extension to the PCEP Notify message (PCNtf) [RFC5440] could be made.
2番目の相互作用は、PCEが要求されたパスを計算できないと判断した場合、または（構成されたポリシーに従って）ネットワークのリソースが不足している（たとえば、一部の主要リンクの容量がほとんど使い果たされていない）ことに気付いた場合に発生します。この場合、PCEはVNTMに通知し、VNTMは（ポリシーに従って）より多くの仮想トポロジを構築するように動作します。この2番目のインターフェースは現在指定されていませんが、I2RSを満たすように選択または設計されたプロトコルが適切な機能を提供する場合があります（セクション2.3.2.8を参照）。あるいは、PCEP通知メッセージ（PCNtf）[RFC5440]を拡張することもできます。
The north-bound interface from the ABNO Controller is used by the NMS, OSS, and Application Service Coordinator to request services in the network in support of applications. The interface will also need to be able to report the asynchronous completion of service requests and convey changes in the status of services.
ABNOコントローラーからのノースバウンドインターフェイスは、NMS、OSS、およびアプリケーションサービスコーディネーターによって、アプリケーションをサポートするネットワーク内のサービスを要求するために使用されます。インターフェイスは、サービス要求の非同期完了を報告し、サービスのステータスの変化を伝えることができる必要もあります。
This interface will also need strong capabilities for security, authentication, and policy.
このインターフェイスには、セキュリティ、認証、およびポリシーのための強力な機能も必要です。
This interface is not currently specified. It needs to be a transactional interface that supports the specification of abstract services with adequate flexibility to facilitate easy extension and yet be concise and easily parsable.
このインターフェースは現在指定されていません。これは、簡単な拡張を容易にし、しかも簡潔で簡単に解析できるように、十分な柔軟性を備えた抽象サービスの仕様をサポートするトランザクションインターフェイスである必要があります。
It is possible that the protocol designed to satisfy I2RS will provide suitable features (see Section 2.3.2.8).
I2RSを満たすように設計されたプロトコルが適切な機能を提供する可能性があります（セクション2.3.2.8を参照）。
Under some circumstances, the ABNO Controller may make requests directly to the Provisioning Manager. For example, if the Provisioning Manager is acting as an SDN Controller, then the ABNO Controller may use one of the APIs defined to allow requests to be made to the SDN Controller (such as the Floodlight REST API [Flood]). Alternatively, since the Provisioning Manager may also receive instructions from a Stateful PCE, the use of PCEP extensions might be appropriate in some cases [PCE-Init-LSP].
状況によっては、ABNOコントローラーがプロビジョニングマネージャーに直接要求する場合があります。たとえば、プロビジョニングマネージャーがSDNコントローラーとして機能している場合、ABNOコントローラーは、定義されているAPIの1つを使用して、SDNコントローラーへのリクエストを許可できます（Floodlight REST API [Flood]など）。または、プロビジョニングマネージャーはステートフルPCEからの指示も受信する場合があるため、場合によってはPCEP拡張の使用が適切な場合があります[PCE-Init-LSP]。
As described in Section 2.3.1.4 and throughout this document, policy forms a critical component of the ABNO architecture. The role of policy will include enforcing the following rules and requirements:
セクション2.3.1.4およびこのドキュメント全体で説明されているように、ポリシーはABNOアーキテクチャの重要なコンポーネントを形成します。ポリシーの役割には、次のルールと要件の適用が含まれます。
- Adding resources on demand should be gated by the authorized capability.
- オンデマンドでのリソースの追加は、許可された機能によってゲート制御される必要があります。
- Client microflows should not trigger server-layer setup or allocation.
- クライアントマイクロフローは、サーバー層のセットアップまたは割り当てをトリガーしないでください。
- Accounting capabilities should be supported.
- 会計機能をサポートする必要があります。
- Security mechanisms for authorization of requests and capabilities are required.
- リクエストと機能を承認するためのセキュリティメカニズムが必要です。
Other policy-related functionality in the system might include the policy behavior of the routing and forwarding system, such as:
システムの他のポリシー関連機能には、ルーティングおよび転送システムのポリシー動作が含まれる場合があります。
- ECMP behavior
- ECMPの動作
- Classification of packets onto LSPs or QoS categories.
- LSPまたはQoSカテゴリへのパケットの分類。
Various policy-capable architectures have been defined, including a framework for using policy with a PCE-enabled system [RFC5394]. However, the take-up of the IETF's Common Open Policy Service protocol (COPS) [RFC2748] has been poor.
PCE対応システム[RFC5394]でポリシーを使用するためのフレームワークを含む、さまざまなポリシー対応アーキテクチャが定義されています。ただし、IETFのCommon Open Policy Serviceプロトコル（COPS）[RFC2748]の採用は不十分です。
New work will be needed to define all of the policy interfaces within the ABNO architecture. Work will also be needed to determine which are internal interfaces and which may be external and so in need of a protocol specification. There is some discussion that the I2RS protocol may support the configuration and manipulation of policies.
ABNOアーキテクチャー内のすべてのポリシー・インターフェースを定義するには、新しい作業が必要になります。内部インターフェースと外部インターフェースのどちらがプロトコル仕様を必要とするかを判別する作業も必要になります。 I2RSプロトコルがポリシーの構成と操作をサポートする可能性があるという議論があります。
The OAM Handler must interact with the network to perform several actions:
OAMハンドラーは、ネットワークと対話して、いくつかのアクションを実行する必要があります。
- Enabling OAM function within the network.
- ネットワーク内でOAM機能を有効にします。
- Performing proactive OAM operations in the network.
- ネットワークでの予防的OAM操作の実行。
- Receiving notifications of network events.
- ネットワークイベントの通知を受け取ります。
Any of the configuration and programmatic interfaces described in Section 2.3.2.1 may serve this purpose. NETCONF notifications are described in [RFC5277], and OpenFlow supports a number of asynchronous event notifications [ONF]. Additionally, Syslog [RFC5424] is a protocol for reporting events from the network, and IP Flow Information Export (IPFIX) [RFC7011] is designed to allow network statistics to be aggregated and reported.
セクション2.3.2.1で説明されている構成およびプログラムインターフェイスのいずれかがこの目的に使用できます。 NETCONF通知は[RFC5277]で説明されており、OpenFlowは多数の非同期イベント通知[ONF]をサポートしています。さらに、Syslog [RFC5424]はネットワークからのイベントを報告するためのプロトコルであり、IPフロー情報エクスポート（IPFIX）[RFC7011]はネットワーク統計を集約して報告できるように設計されています。
The OAM Handler also correlates events reported from the network and reports them onward to the ABNO Controller (which can apply the information to the recovery of services that it has provisioned) and to the NMS, OSS, and Application Service Coordinator. The reporting mechanism used here can be essentially the same as the mechanism used when events are reported from the network; no new protocol is needed, although new data models may be required for technology-independent OAM reporting.
また、OAMハンドラーは、ネットワークから報告されたイベントを相互に関連付け、ABNOコントローラー（プロビジョニングしたサービスの回復に情報を適用できる）とNMS、OSS、およびアプリケーションサービスコーディネーターにイベントを報告します。ここで使用されるレポートメカニズムは、イベントがネットワークからレポートされるときに使用されるメカニズムと基本的に同じです。新しいプロトコルは必要ありませんが、テクノロジーに依存しないOAMレポートには新しいデータモデルが必要になる場合があります。
This section provides a number of examples of how the ABNO architecture can be applied to provide application-driven and NMS/OSS-driven network operations. The purpose of these examples is to give some concrete material to demonstrate the architecture so that it may be more easily comprehended, and to illustrate that the application of the architecture is achieved by "profiling" and by selecting only the relevant components and interfaces.
このセクションでは、ABNOアーキテクチャを適用して、アプリケーション駆動型およびNMS / OSS駆動型のネットワーク操作を提供する方法の例をいくつか示します。これらの例の目的は、アーキテクチャをより具体的に理解できるように具体的な資料を示し、アーキテクチャの適用が「プロファイリング」によって、関連するコンポーネントとインターフェースのみを選択することによって達成されることを示すことです。
Similarly, it is not the intention that this section contain a complete list of all possible applications of ABNO. The examples are intended to broadly cover a number of applications that are commonly discussed, but this does not preclude other use cases.
同様に、このセクションがABNOのすべての可能なアプリケーションの完全なリストを含むことは意図されていません。これらの例は、一般的に議論されている多くのアプリケーションを幅広くカバーすることを目的としていますが、これは他の使用例を排除するものではありません。
The descriptions in this section are not fully detailed applicability statements for ABNO. It is anticipated that such applicability statements, for the use cases described and for other use cases, could be suitable material for separate documents.
このセクションの説明は、ABNOの完全な適用性ステートメントではありません。このような適用性の説明は、説明されている使用例や他の使用例については、個別のドキュメントに適した資料になると予想されます。
The following use case describes how the ABNO framework can be used to set up an end-to-end MPLS service across multiple Autonomous Systems (ASes). Consider the simple network topology shown in Figure 2. The three ASes (ASa, ASb, and ASc) are connected at AS Border Routers (ASBRs) a1, a2, b1 through b4, c1, and c2. A source node (s) located in ASa is to be connected to a destination node (d) located in ASc. The optimal path for the LSP from s to d must be computed, and then the network must be triggered to set up the LSP.
次の使用例では、ABNOフレームワークを使用して、複数の自律システム（AS）全体にエンドツーエンドのMPLSサービスをセットアップする方法を説明します。図2に示す単純なネットワークトポロジを考えます。3つのAS（ASa、ASb、およびASc）は、ASボーダールーター（ASBR）a1、a2、b1〜b4、c1、およびc2で接続されています。 ASaにある送信元ノードは、AScにある送信先ノード（d）に接続されます。 sからdへのLSPの最適パスを計算し、次にネットワークをトリガーしてLSPをセットアップする必要があります。
+--------------+ +-----------------+ +--------------+
|ASa | | ASb | | ASc |
| +--+ | | +--+ +--+ | | +--+ |
| |a1|-|-|-|b1| |b3|-|-|-|c1| |
| +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
| |s| | | | | |d| |
| +-+ +--+ | | +--+ +--+ | | +--+ +-+ |
| |a2|-|-|-|b2| |b4|-|-|-|c2| |
| +--+ | | +--+ +--+ | | +--+ |
| | | | | |
+--------------+ +-----------------+ +--------------+
Figure 2: Inter-AS Domain Topology with Hierarchical PCE (Parent PCE)
図2：階層PCE（親PCE）を使用したAS間ドメイントポロジ
The following steps are performed to deliver the service within the ABNO architecture:
ABNOアーキテクチャー内でサービスを提供するために、以下のステップが実行されます。
1. Request Management
1. リクエスト管理
As shown in Figure 3, the NMS/OSS issues a request to the ABNO Controller for a path between s and d. The ABNO Controller verifies that the NMS/OSS has sufficient rights to make the service request.
図3に示すように、NMS / OSSは、sとdの間のパスを求める要求をABNOコントローラーに発行します。 ABNOコントローラーは、NMS / OSSにサービス要求を行うための十分な権限があることを確認します。
+---------------------+
| NMS/OSS |
+----------+----------+
|
V
+--------+ +-----------+-------------+
| Policy +-->-+ ABNO Controller |
| Agent | | |
+--------+ +-------------------------+
Figure 3: ABNO Request Management
図3：ABNOリクエスト管理
2. Service Path Computation with Hierarchical PCE
2. 階層型PCEによるサービスパスの計算
The ABNO Controller needs to determine an end-to-end path for the LSP. Since the ASes will want to maintain a degree of confidentiality about their internal resources and topology, they will not share a TED and each will have its own PCE. In such a situation, the Hierarchical PCE (H-PCE) architecture described in [RFC6805] is applicable.
ABNOコントローラは、LSPのエンドツーエンドパスを決定する必要があります。 ASは、内部リソースとトポロジについてある程度の機密性を維持する必要があるため、TEDを共有せず、それぞれに独自のPCEがあります。このような状況では、[RFC6805]で説明されているHierarchical PCE（H-PCE）アーキテクチャが適用されます。
As shown in Figure 4, the ABNO Controller sends a request to the parent PCE for an end-to-end path. As described in [RFC6805], the parent PCE consults its TED, which shows the connectivity between ASes. This helps it understand that the end-to-end path must cross each of ASa, ASb, and ASc, so it sends individual path computation requests to each of PCEs a, b, and c to determine the best options for crossing the ASes.
図4に示すように、ABNOコントローラーはエンドツーエンドパスの要求を親PCEに送信します。 [RFC6805]で説明されているように、親PCEはAS間の接続を示すTEDを調べます。これは、エンドツーエンドパスがASa、ASb、およびAScのそれぞれを通過する必要があることを理解するのに役立ちます。これにより、個々のパス計算要求を各PCE a、b、cに送信して、ASを通過するための最適なオプションを決定します。
Each child PCE applies policy to the requests it receives to determine whether the request is to be allowed and to select the types of network resources that can be used in the computation result. For confidentiality reasons, each child PCE may supply its computation responses using a path key [RFC5520] to hide the details of the path segment it has computed.
各子PCEは、受信した要求にポリシーを適用して、要求を許可するかどうかを決定し、計算結果で使用できるネットワークリソースのタイプを選択します。機密性の理由から、各子PCEは、パスキー[RFC5520]を使用して計算応答を提供し、計算したパスセグメントの詳細を非表示にする場合があります。
+-----------------+
| ABNO Controller |
+----+-------+----+
| A
V |
+--+-------+--+ +--------+
+--------+ | | | |
| Policy +-->-+ Parent PCE +---+ AS TED |
| Agent | | | | |
+--------+ +-+----+----+-+ +--------+
/ | \
/ | \
+-----+-+ +---+---+ +-+-----+
| | | | | |
| PCE a | | PCE b | | PCE c |
| | | | | |
+---+---+ +---+---+ +---+---+
| | |
+--+--+ +--+--+ +--+--+
| TEDa| | TEDb| | TEDc|
+-----+ +-----+ +-----+
Figure 4: Path Computation Request with Hierarchical PCE
図4：階層PCEを使用したパス計算要求
The parent PCE collates the responses from the children and applies its own policy to stitch them together into the best end-to-end path, which it returns as a response to the ABNO Controller.
親PCEは子からの応答を照合し、独自のポリシーを適用してそれらを最良のエンドツーエンドパスにつなぎ、ABNOコントローラーへの応答として返します。
3. Provisioning the End-to-End LSP
3. エンドツーエンドLSPのプロビジョニング
There are several options for how the end-to-end LSP gets provisioned in the ABNO architecture. Some of these are described below.
エンドツーエンドLSPをABNOアーキテクチャでプロビジョニングする方法には、いくつかのオプションがあります。これらのいくつかを以下に説明します。
3a. Provisioning from the ABNO Controller with a Control Plane
3a。コントロールプレーンを使用したABNOコントローラーからのプロビジョニング
Figure 5 shows how the ABNO Controller makes a request through the Provisioning Manager to establish the end-to-end LSP. As described in Section 2.3.2.6, these interactions can use the NETCONF protocol [RFC6241] or the extensions to PCEP described in [PCE-Init-LSP]. In either case, the provisioning request is sent to the head-end Label Switching Router (LSR), and that LSR signals in the control plane (using a protocol such as RSVP-TE [RFC3209]) to cause the LSP to be established.
図5は、ABNOコントローラーがプロビジョニングマネージャーを通じてエンドツーエンドLSPを確立するように要求する方法を示しています。セクション2.3.2.6で説明されているように、これらの相互作用はNETCONFプロトコル[RFC6241]または[PCE-Init-LSP]で説明されているPCEPの拡張機能を使用できます。どちらの場合も、プロビジョニング要求はヘッドエンドのラベルスイッチングルータ（LSR）に送信され、そのLSRは（RSVP-TE [RFC3209]などのプロトコルを使用して）コントロールプレーンで信号を送り、LSPを確立します。
+-----------------+
| ABNO Controller |
+--------+--------+
|
V
+------+-------+
| Provisioning |
| Manager |
+------+-------+
|
V
+--------------------+------------------------+
/ Network \
+-------------------------------------------------+
Figure 5: Provisioning the End-to-End LSP
図5：エンドツーエンドLSPのプロビジョニング
3b. Provisioning through Programming Network Resources
3b。ネットワークリソースのプログラミングによるプロビジョニング
Another option is that the LSP is provisioned hop by hop from the Provisioning Manager using a mechanism such as ForCES [RFC5810] or OpenFlow [ONF] as described in Section 2.3.2.6. In this case, the picture is the same as that shown in Figure 5. The interaction between the ABNO Controller and the Provisioning Manager will be PCEP or NETCONF as described in option 3a, and the Provisioning Manager will be responsible for fanning out the requests to the individual network elements.
別のオプションは、セクション2.3.2.6で説明されているように、ForCES [RFC5810]やOpenFlow [ONF]などのメカニズムを使用して、プロビジョニングマネージャからホップバイホップでLSPをプロビジョニングすることです。この場合、図は図5に示すものと同じです。ABNOコントローラーとプロビジョニングマネージャーの間の相互作用は、オプション3aで説明されているようにPCEPまたはNETCONFであり、プロビジョニングマネージャーは要求を展開します。個々のネットワーク要素。
3c. Provisioning with an Active Parent PCE
3c。アクティブな親PCEを使用したプロビジョニング
The Active PCE is described in Section 2.3.1.7, based on the concepts expressed in [PCE-Init-LSP]. In this approach, the process described in option 3a is modified such that the PCE issues a direct PCEP command to the network, without a response being first returned to the ABNO Controller.
[PCE-Init-LSP]で表現された概念に基づいて、アクティブPCEをセクション2.3.1.7で説明します。このアプローチでは、オプション3aで説明されているプロセスが変更され、PCEがネットワークに直接PCEPコマンドを発行し、最初にABNOコントローラーに応答が返されないようにします。
This situation is shown in Figure 6 and could be modified so that the Provisioning Manager still programs the individual network elements as described in option 3b.
この状況は図6に示されていますが、オプション3bで説明されているようにProvisioning Managerが個々のネットワーク要素をプログラムするように変更することができます。
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--+----------+ +--------------+
+--------+ | | | Provisioning |
| Policy +-->-+ Parent PCE +---->----+ Manager |
| Agent | | | | |
+--------+ +-+----+----+-+ +-----+--------+
/ | \ |
/ | \ |
+-----+-+ +---+---+ +-+-----+ V
| | | | | | |
| PCE a | | PCE b | | PCE c | |
| | | | | | |
+-------+ +-------+ +-------+ |
|
+--------------------------------+------------+
/ Network \
+-------------------------------------------------+
Figure 6: LSP Provisioning with an Active PCE
図6：アクティブなPCEを使用したLSPプロビジョニング
3d. Provisioning with Active Child PCEs and Segment Stitching
3d。アクティブな子PCEとセグメントステッチを使用したプロビジョニング
A mixture of the approaches described in options 3b and 3c can result in a combination of mechanisms to program the network to provide the end-to-end LSP. Figure 7 shows how each child PCE can be an Active PCE responsible for setting up an edge-to-edge LSP segment across one of the ASes. The ABNO Controller then uses the Provisioning Manager to program the inter-AS connections using ForCES or OpenFlow, and the LSP segments are stitched together following the ideas described in [RFC5150]. Philosophers may debate whether the parent PCE in this model is active (instructing the children to provision LSP segments) or passive (requesting path segments that the children provision).
オプション3bと3cで説明したアプローチを組み合わせると、ネットワークをプログラムしてエンドツーエンドのLSPを提供するメカニズムを組み合わせて使用できます。図7は、各子PCEが、いずれかのASにエッジツーエッジのLSPセグメントを設定するアクティブPCEになる方法を示しています。次に、ABNOコントローラはプロビジョニングマネージャを使用して、ForCESまたはOpenFlowを使用してAS間接続をプログラムし、LSPセグメントは[RFC5150]で説明されているアイデアに従って結合されます。哲学者は、このモデルの親PCEがアクティブ（LSPセグメントをプロビジョニングするように子供に指示する）であるか、パッシブ（子供がプロビジョニングするパスセグメントを要求する）であるかを議論します。
+-----------------+
| ABNO Controller +-------->--------+
+----+-------+----+ |
| A |
V | |
+--+-------+--+ |
+--------+ | | |
| Policy +-->-+ Parent PCE | |
| Agent | | | |
+--------+ ++-----+-----++ |
/ | \ |
/ | \ |
+---+-+ +--+--+ +-+---+ |
| | | | | | |
|PCE a| |PCE b| |PCE c| |
| | | | | | V
+--+--+ +--+--+ +---+-+ |
| | | |
V V V |
+----------+-+ +------------+ +-+----------+ |
|Provisioning| |Provisioning| |Provisioning| |
|Manager | |Manager | |Manager | |
+-+----------+ +-----+------+ +-----+------+ |
| | | |
V V V |
+--+-----+ +----+---+ +--+-----+ |
/ AS a \=====/ AS b \=====/ AS c \ |
+------------+ A +------------+ A +------------+ |
| | |
+-----+----------------+-----+ |
| Provisioning Manager +----<-------+
+----------------------------+
Figure 7: LSP Provisioning with Active Child PCEs and Stitching
図7：アクティブな子PCEとステッチを使用したLSPプロビジョニング
4. Verification of Service
4. サービスの確認
The ABNO Controller will need to ascertain that the end-to-end LSP has been set up as requested. In the case of a control plane being used to establish the LSP, the head-end LSR may send a notification (perhaps using PCEP) to report successful setup, but to be sure that the LSP is up, the ABNO Controller will request the OAM Handler to perform Continuity Check OAM in the data plane and report back that the LSP is ready to carry traffic.
ABNOコントローラーは、エンドツーエンドLSPが要求どおりにセットアップされていることを確認する必要があります。 LSPの確立にコントロールプレーンが使用されている場合、ヘッドエンドLSRは通知（おそらくPCEPを使用）を送信してセットアップの成功を報告しますが、LSPが起動していることを確認するには、ABNOコントローラーがOAMを要求しますデータプレーンでContinuity Check OAMを実行し、LSPがトラフィックを伝送する準備ができていることを報告するハンドラー。
5. Notification of Service Fulfillment
5. サービス履行の通知
Finally, when the ABNO Controller is satisfied that the requested service is ready to carry traffic, it will notify the NMS/OSS. The delivery of the service may be further checked through auditing the network, as described in Section 2.3.2.7.
最後に、ABNOコントローラは、要求されたサービスがトラフィックを伝送する準備ができていることを確認すると、NMS / OSSに通知します。セクション2.3.2.7で説明されているように、サービスの配信はネットワークの監査を通じてさらにチェックできます。
Networks are typically constructed using multiple layers. These layers represent separations of administrative regions or of technologies and may also represent a distinction between client and server networking roles.
ネットワークは通常、複数のレイヤーを使用して構築されます。これらのレイヤーは、管理領域またはテクノロジの分離を表し、クライアントとサーバーのネットワークの役割の違いを表すこともあります。
It is preferable to coordinate network resource control and utilization (i.e., consideration and control of multiple layers), rather than controlling and optimizing resources at each layer independently. This facilitates network efficiency and network automation and may be defined as inter-layer traffic engineering.
各層のリソースを個別に制御および最適化するのではなく、ネットワークリソースの制御と利用を調整する（つまり、複数の層の検討と制御）ことが望ましいこれにより、ネットワークの効率とネットワークの自動化が促進され、レイヤー間のトラフィックエンジニアリングと定義できます。
The PCE architecture supports inter-layer traffic engineering [RFC5623] and, in combination with the ABNO architecture, provides a suite of capabilities for network resource coordination across multiple layers.
PCEアーキテクチャは、レイヤー間のトラフィックエンジニアリング[RFC5623]をサポートし、ABNOアーキテクチャと組み合わせて、複数のレイヤー間でネットワークリソースを調整するための一連の機能を提供します。
The following use case demonstrates ABNO used to coordinate allocation of server-layer network resources to create virtual topology in a client-layer network in order to satisfy a request for end-to-end client-layer connectivity. Consider the simple multi-layer network in Figure 8.
次の使用例は、サーバーレイヤーネットワークリソースの割り当てを調整して、エンドツーエンドのクライアントレイヤー接続の要求を満たすために、クライアントレイヤーネットワークで仮想トポロジを作成するために使用されるABNOを示しています。図8の単純な多層ネットワークを考えてみます。
+--+ +--+ +--+ +--+ +--+ +--+
|P1|---|P2|---|P3| |P4|---|P5|---|P6|
+--+ +--+ +--+ +--+ +--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
Figure 8: Multi-Layer Network
図8：多層ネットワーク
There are six packet-layer routers (P1 through P6) and three optical-layer lambda switches (L1 through L3). There is connectivity in the packet layer between routers P1, P2, and P3, and also between routers P4, P5, and P6, but there is no packet-layer connectivity between these two islands of routers, perhaps because of a network failure or perhaps because all existing bandwidth between the islands has already been used up. However, there is connectivity in the optical layer between switches L1, L2, and L3, and the optical network is connected out to routers P3 and P4 (they have optical line cards). In this example, a packet-layer connection (an MPLS LSP) is desired between P1 and P6.
6つのパケット層ルーター（P1〜P6）と3つの光層ラムダスイッチ（L1〜L3）があります。ルーターP1、P2、およびP3の間、およびルーターP4、P5、およびP6の間のパケットレイヤー接続はありますが、おそらくネットワーク障害またはおそらくはルーターのこれら2つのアイランド間にパケットレイヤー接続がありませんアイランド間の既存の帯域幅はすべて使い果たされているためです。ただし、スイッチL1、L2、およびL3の間の光レイヤーには接続があり、光ネットワークはルーターP3およびP4に接続されています（光ラインカードがあります）。この例では、P1とP6の間にパケット層接続（MPLS LSP）が必要です。
In the ABNO architecture, the following steps are performed to deliver the service.
ABNOアーキテクチャでは、サービスを提供するために次の手順が実行されます。
1. Request Management
1. リクエスト管理
As shown in Figure 9, the Application Service Coordinator issues a request for connectivity from P1 to P6 in the packet-layer network. That is, the Application Service Coordinator requests an MPLS LSP with a specific bandwidth to carry traffic for its application. The ABNO Controller verifies that the Application Service Coordinator has sufficient rights to make the service request.
図9に示すように、アプリケーションサービスコーディネーターは、パケットレイヤーネットワークでP1からP6への接続を要求します。つまり、アプリケーションサービスコーディネーターは、アプリケーションのトラフィックを伝送するために、特定の帯域幅を持つMPLS LSPを要求します。 ABNOコントローラーは、アプリケーションサービスコーディネーターがサービス要求を行うための十分な権限を持っていることを確認します。
+---------------------------+
| Application Service |
| Coordinator |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
Figure 9: Application Service Coordinator Request Management
図9：アプリケーションサービスコーディネーターの要求管理
2. Service Path Computation in the Packet Layer
2. パケットレイヤーでのサービスパス計算
The ABNO Controller sends a path computation request to the packet-layer PCE to compute a suitable path for the requested LSP, as shown in Figure 10. The PCE uses the appropriate policy for the request and consults the TED for the packet layer. It determines that no path is immediately available.
図10に示すように、ABNOコントローラーはパス計算要求をパケット層PCEに送信して、要求されたLSPに適したパスを計算します。PCEは要求に適切なポリシーを使用し、パケット層のTEDを調べます。すぐに利用できるパスがないと判断します。
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| Policy +-->--+ Packet-Layer +---+ Packet |
| Agent | | PCE | | TED |
+--------+ +--------------+ +--------+
Figure 10: Path Computation Request
図10：パス計算リクエスト
3. Invocation of VNTM and Path Computation in the Optical Layer
3. 光レイヤーでのVNTMとパス計算の呼び出し
After the path computation failure in step 2, instead of notifying the ABNO Controller of the failure, the PCE invokes the VNTM to see whether it can create the necessary link in the virtual network topology to bridge the gap.
手順2でパス計算エラーが発生した後、PCNOはABNOコントローラーにエラーを通知する代わりに、VNTMを呼び出して、仮想ネットワークトポロジに必要なリンクを作成してギャップを埋めることができるかどうかを確認します。
As shown in Figure 11, the packet-layer PCE reports the connectivity problem to the VNTM, and the VNTM consults policy to determine what it is allowed to do. Assuming that the policy allows it, the VNTM asks the optical-layer PCE to find a path across the optical network that could be provisioned to provide a virtual link for the packet layer. In addressing this request, the optical-layer PCE consults a TED for the optical-layer network.
図11に示すように、パケット層PCEは接続の問題をVNTMに報告し、VNTMはポリシーを参照して、許可されていることを決定します。ポリシーで許可されていると仮定すると、VNTMは光レイヤーPCEに、パケットレイヤーに仮想リンクを提供するためにプロビジョニングできる光ネットワーク全体のパスを見つけるように要求します。この要求に対処する際に、光学層PCEは光学層ネットワークのTEDに問い合わせます。
+------+
+--------+ | | +--------------+
| Policy +-->--+ VNTM +--<--+ Packet-Layer |
| Agent | | | | PCE |
+--------+ +---+--+ +--------------+
|
V
+---------------+ +---------+
| Optical-Layer +---+ Optical |
| PCE | | TED |
+---------------+ +---------+
Figure 11: Invocation of VNTM and Optical-Layer Path Computation
図11：VNTMと光レイヤーパス計算の呼び出し
4. Provisioning in the Optical Layer
4. 光レイヤーでのプロビジョニング
Once a path has been found across the optical-layer network, it needs to be provisioned. The options follow those in step 3 of Section 3.1. That is, provisioning can be initiated by the optical-layer PCE or by its user, the VNTM. The command can be sent to the head end of the optical LSP (P3) so that the control plane (for example, GMPLS RSVP-TE [RFC3473]) can be used to provision the LSP. Alternatively, the network resources can be provisioned directly, using any of the mechanisms described in Section 2.3.2.6.
光レイヤネットワーク全体でパスが見つかったら、プロビジョニングする必要があります。オプションは、セクション3.1のステップ3のオプションに従います。つまり、プロビジョニングは、光学層PCEまたはそのユーザーであるVNTMによって開始できます。コマンドを光LSP（P3）のヘッドエンドに送信すると、コントロールプレーン（たとえば、GMPLS RSVP-TE [RFC3473]）を使用してLSPをプロビジョニングできます。または、セクション2.3.2.6で説明されているメカニズムを使用して、ネットワークリソースを直接プロビジョニングすることもできます。
5. Creation of Virtual Topology in the Packet Layer
5. パケットレイヤーでの仮想トポロジの作成
Once the LSP has been set up in the optical layer, it can be made available in the packet layer as a virtual link. If the GMPLS signaling used the mechanisms described in [RFC6107], this process can be automated within the control plane; otherwise, it may require a specific instruction to the head-end router of the optical LSP (for example, through I2RS).
LSPが光レイヤでセットアップされると、仮想レイヤとしてパケットレイヤで使用できるようになります。 GMPLSシグナリングが[RFC6107]で説明されているメカニズムを使用した場合、このプロセスはコントロールプレーン内で自動化できます。それ以外の場合は、光LSPのヘッドエンドルータへの特定の指示が必要になることがあります（たとえば、I2RSを介して）。
Once the virtual link is created as shown in Figure 12, it is advertised in the IGP for the packet-layer network, and the link will appear in the TED for the packet-layer network.
図12に示すように仮想リンクが作成されると、それはパケット層ネットワークのIGPでアドバタイズされ、リンクはパケット層ネットワークのTEDに表示されます。
+--------+
| Packet |
| TED |
+------+-+
A
|
+--+ +--+
|P3|....................|P4|
+--+ +--+
\ /
\ /
+--+ +--+ +--+
|L1|--|L2|--|L3|
+--+ +--+ +--+
Figure 12: Advertisement of a New Virtual Link
図12：新しい仮想リンクの通知
6. Path Computation Completion and Provisioning in the Packet Layer
6. パケット層でのパス計算の完了とプロビジョニング
Now there are sufficient resources in the packet-layer network. The PCE for the packet layer can complete its work, and the MPLS LSP can be provisioned as described in Section 3.1.
これで、パケット層ネットワークに十分なリソースがあります。パケットレイヤのPCEはその作業を完了でき、セクション3.1で説明されているようにMPLS LSPをプロビジョニングできます。
7. Verification and Notification of Service Fulfillment
7. サービス履行の確認と通知
As discussed in Section 3.1, the ABNO Controller will need to verify that the end-to-end LSP has been correctly established before reporting service fulfillment to the Application Service Coordinator.
セクション3.1で説明したように、ABNOコントローラーは、サービスフルフィルメントをアプリケーションサービスコーディネーターに報告する前に、エンドツーエンドLSPが正しく確立されていることを確認する必要があります。
Furthermore, it is highly likely that service verification will be necessary before the optical-layer LSP can be put into service as a virtual link. Thus, the VNTM will need to coordinate with the OAM Handler to ensure that the LSP is ready for use.
さらに、光レイヤLSPを仮想リンクとして使用する前に、サービスの検証が必要になる可能性が高くなります。したがって、VNTMはOAMハンドラーと調整して、LSPを使用する準備ができていることを確認する必要があります。
In order to support new and emerging cloud-based applications, such as real-time data backup, virtual machine migration, server clustering, or load reorganization, the dynamic provisioning and allocation of IT resources and the interconnection of multiple, remote Data Centers (DCs) is a growing requirement.
リアルタイムのデータバックアップ、仮想マシンの移行、サーバーのクラスタリング、負荷の再編成、ITリソースの動的なプロビジョニングと割り当て、複数のリモートデータセンター（DC）の相互接続など、新しく出現したクラウドベースのアプリケーションをサポートするため）は、増大する要件です。
These operations require traffic being delivered between data centers, and, typically, the connections providing such inter-DC connectivity are provisioned using static circuits or dedicated leased lines, leading to an inefficiency in terms of resource utilization. Moreover, a basic requirement is that such a group of remote DCs can be operated logically as one.
これらの操作では、データセンター間でトラフィックを配信する必要があり、通常、このようなDC間接続を提供する接続は、静的回線または専用線を使用してプロビジョニングされるため、リソースの利用効率が低下します。さらに、基本的な要件は、そのようなリモートDCのグループを論理的に1つとして操作できることです。
In such environments, the data plane technology is operator and provider dependent. Their customers may rent lambda switch capable (LSC), packet switch capable (PSC), or time division multiplexing (TDM) services, and the application and usage of the ABNO architecture and Controller enable the required dynamic end-to-end network service provisioning, regardless of underlying service and transport layers.
このような環境では、データプレーンテクノロジーはオペレーターとプロバイダーに依存します。顧客はラムダスイッチ対応（LSC）、パケットスイッチ対応（PSC）、または時分割多重（TDM）サービスをレンタルでき、ABNOアーキテクチャとコントローラーのアプリケーションと使用により、必要な動的エンドツーエンドネットワークサービスプロビジョニングが可能になります。基礎となるサービスおよびトランスポート層に関係なく。
Consequently, the interconnection of DCs may involve the operation, control, and management of heterogeneous environments: each DC site and the metro-core network segment used to interconnect them, with regard to not only the underlying data plane technology but also the control plane. For example, each DC site or domain could be controlled locally in a centralized way (e.g., via OpenFlow [ONF]), whereas the metro-core transport infrastructure is controlled by GMPLS. Although OpenFlow is specially adapted to single-domain intra-DC networks (packet-level control, lots of routing exceptions), a standardized GMPLS-based architecture would enable dynamic optical resource allocation and restoration in multi-domain (e.g., multi-vendor) core networks interconnecting distributed data centers.
その結果、DCの相互接続には、異種環境の運用、制御、および管理が含まれる可能性があります。各DCサイトとそれらを相互接続するために使用されるメトロコアネットワークセグメントは、基盤となるデータプレーンテクノロジーだけでなく、コントロールプレーンに関してもです。たとえば、メトロコアのトランスポートインフラストラクチャはGMPLSによって制御されているのに対し、各DCサイトまたはドメインは集中管理された方法（OpenFlow [ONF]など）でローカルに制御できます。 OpenFlowは、単一ドメインのイントラDCネットワーク（パケットレベルの制御、多数のルーティング例外）に特別に適合していますが、標準化されたGMPLSベースのアーキテクチャにより、マルチドメイン（たとえば、マルチベンダー）での動的な光リソースの割り当てと復元が可能になります。分散データセンターを相互接続するコアネットワーク。
The application of an ABNO architecture and related procedures would involve the following aspects:
ABNOアーキテクチャと関連手順の適用には、次の側面が含まれます。
1. Request from the Application Service Coordinator or NMS
1. アプリケーションサービスコーディネーターまたはNMSからの要求
As shown in Figure 13, the ABNO Controller receives a request from the Application Service Coordinator or from the NMS, in order to create a new end-to-end connection between two end points. The actual addressing of these end points is discussed in the next section. The ABNO Controller asks the PCE for a path between these two end points, after considering any applicable policy as defined by the Policy Agent (see Figure 1).
図13に示すように、ABNOコントローラは、2つのエンドポイント間に新しいエンドツーエンド接続を作成するために、アプリケーションサービスコーディネータまたはNMSから要求を受信します。これらのエンドポイントの実際のアドレス指定については、次のセクションで説明します。 ABNOコントローラーは、ポリシーエージェントによって定義された適用可能なポリシーを検討した後、これら2つのエンドポイント間のパスをPCEに要求します（図1を参照）。
+---------------------------+
| Application Service |
| Coordinator or NMS |
+-------------+-------------+
|
V
+------+ +------------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +-------------------------+
Figure 13: Application Service Coordinator Request Management
図13：アプリケーションサービスコーディネーターの要求管理
2. Address Mapping
2. アドレスマッピング
In order to compute an end-to-end path, the PCE needs to have a unified view of the overall topology, which means that it has to consider and identify the actual end points with regard to the client network addresses. The ABNO Controller and/or the PCE may need to translate or map addresses from different address spaces. Depending on how the topology information is disseminated and gathered, there are two possible scenarios:
エンドツーエンドパスを計算するために、PCEはトポロジ全体の統一されたビューを持っている必要があります。つまり、PCEは、クライアントネットワークアドレスに関して実際のエンドポイントを考慮および識別する必要があります。 ABNOコントローラーやPCEは、異なるアドレススペースからのアドレスを変換またはマップする必要がある場合があります。トポロジ情報がどのように配布および収集されるかに応じて、2つのシナリオが考えられます。
2a. The Application Layer Knows the Client Network Layer
2a。アプリケーション層はクライアントネットワーク層を認識している
Entities belonging to the application layer may have an interface with the TED or with an ALTO Server allowing those entities to map the high-level end points to network addresses. The mechanism used to enable this address correlation is out of scope for this document but relies on direct interfaces to other ABNO components in addition to the interface to the ABNO Controller.
アプリケーション層に属するエンティティには、TEDまたはALTOサーバーとのインターフェースがあり、これらのエンティティが高レベルのエンドポイントをネットワークアドレスにマッピングできるようにします。このアドレス相関を有効にするために使用されるメカニズムは、このドキュメントの範囲外ですが、ABNOコントローラーへのインターフェイスに加えて、他のABNOコンポーネントへの直接インターフェイスに依存しています。
In this scenario, the request from the NMS or Application Service Coordinator contains addresses in the client-layer network. Therefore, when the ABNO Controller requests the PCE to compute a path between two end points, the PCE is able to use the supplied addresses, compute the path, and continue the workflow in communication with the Provisioning Manager.
このシナリオでは、NMSまたはアプリケーションサービスコーディネーターからの要求に、クライアント層ネットワークのアドレスが含まれています。したがって、ABNOコントローラーがPCEに2つのエンドポイント間のパスの計算を要求すると、PCEは提供されたアドレスを使用してパスを計算し、プロビジョニングマネージャーと通信してワークフローを続行できます。
2b. The Application Layer Does Not Know the Client Network Layer
2b。アプリケーション層はクライアントネットワーク層を認識していません
In this case, when the ABNO Controller receives a request from the NMS or Application Service Coordinator, the request contains only identifiers from the application-layer address space. In order for the PCE to compute an end-to-end path, these identifiers must be converted to addresses in the client-layer network. This translation can be performed by the ABNO Controller, which can access the TED and ALTO databases allowing the path computation request that it sends to the PCE to simply be contained within one network and TED. Alternatively, the computation request could use the application-layer identifiers, leaving the job of address mapping to the PCE.
この場合、ABNOコントローラーがNMSまたはアプリケーションサービスコーディネーターから要求を受信すると、要求にはアプリケーション層アドレス空間からの識別子のみが含まれます。 PCEがエンドツーエンドパスを計算するには、これらの識別子をクライアント層ネットワークのアドレスに変換する必要があります。この変換は、ABNOコントローラーによって実行できます。ABNOコントローラーは、TEDおよびALTOデータベースにアクセスして、PCEに送信するパス計算要求を1つのネットワークとTEDに単純に含めることができます。あるいは、計算要求でアプリケーション層識別子を使用して、アドレスマッピングのジョブをPCEに任せることもできます。
Note that in order to avoid any confusion both approaches in this scenario require clear identification of the address spaces that are in use.
混乱を避けるために、このシナリオの両方のアプローチでは、使用中のアドレススペースを明確に識別する必要があることに注意してください。
3. Provisioning Process
3. プロビジョニングプロセス
Once the path has been obtained, the Provisioning Manager receives a high-level provisioning request to provision the service. Since, in the considered use case, the network elements are not necessarily configured using the same protocol, the end-to-end path is split into segments, and the ABNO Controller coordinates or orchestrates the establishment by adapting and/or translating the abstract provisioning request to concrete segment requests by means of a VNTM or PCE that issues the corresponding commands or instructions. The provisioning may involve configuring the data plane elements directly or delegating the establishment of the underlying connection to a dedicated control plane instance responsible for that segment.
パスが取得されると、プロビジョニングマネージャは、サービスをプロビジョニングするための高レベルのプロビジョニング要求を受け取ります。考慮されるユースケースでは、ネットワーク要素は必ずしも同じプロトコルを使用して構成されているわけではないため、エンドツーエンドのパスはセグメントに分割され、ABNOコントローラーは、抽象プロビジョニングを適合または変換することにより、施設を調整または調整します対応するコマンドまたは命令を発行するVNTMまたはPCEによる具体的なセグメント要求への要求。プロビジョニングには、データプレーン要素を直接構成するか、基になる接続の確立をそのセグメントを担当する専用のコントロールプレーンインスタンスに委任することが含まれます。
The Provisioning Manager could use a number of mechanisms to program the network elements, as shown in Figure 14. It learns which technology is used for the actual provisioning at each segment by either manual configuration or discovery.
図14に示すように、プロビジョニングマネージャーはいくつかのメカニズムを使用してネットワーク要素をプログラムできます。手動で構成するか検出することにより、各セグメントで実際のプロビジョニングに使用されるテクノロジーを学習します。
+-----------------+
| ABNO Controller |
+-------+---------+
|
|
V
+------+ +------+-------+
| VNTM +--<--+ PCE |
+---+--+ +------+-------+
| |
V V
+-----+---------------+------------+
| Provisioning Manager |
+----------------------------------+
| | | | |
V | V | V
OpenFlow V ForCES V PCEP
NETCONF SNMP
Figure 14: Provisioning Process
図14：プロビジョニングプロセス
4. Verification and Notification of Service Fulfillment
4. サービス履行の確認と通知
Once the end-to-end connectivity service has been provisioned, and after the verification of the correct operation of the service, the ABNO Controller needs to notify the Application Service Coordinator or NMS.
エンドツーエンドの接続サービスがプロビジョニングされ、サービスが正しく動作することを確認した後、ABNOコントローラーはアプリケーションサービスコーディネーターまたはNMSに通知する必要があります。
A number of different services depend on the establishment of a new LSP so that traffic supported by an existing LSP can be switched with little or no disruption. This section describes those use cases, presents a generic model for make-before-break within the ABNO architecture, and shows how each use case can be supported by using elements of the generic model.
多くの異なるサービスは、新しいLSPの確立に依存しているため、既存のLSPでサポートされているトラフィックをほとんどまたはまったく中断することなく切り替えることができます。このセクションでは、それらのユースケースについて説明し、ABNOアーキテクチャ内のmake-before-breakの一般的なモデルを示し、一般的なモデルの要素を使用して各ユースケースをサポートする方法を示します。
Make-before-break is a mechanism supported in RSVP-TE signaling where a new LSP is set up before the LSP it replaces is torn down [RFC3209]. This process has several benefits in situations such as reoptimization of in-service LSPs.
Make-before-breakは、RSVP-TEシグナリングでサポートされるメカニズムであり、置換するLSPが破棄される前に新しいLSPがセットアップされます[RFC3209]。このプロセスには、稼働中のLSPの再最適化などの状況でいくつかの利点があります。
The process is simple, and the example shown in Figure 15 utilizes a Stateful PCE [Stateful-PCE] to monitor the network and take reoptimization actions when necessary. In this process, a service request is made to the ABNO Controller by a requester such as the OSS. The service request indicates that the LSP should be reoptimized under specific conditions according to policy. This allows the ABNO Controller to manage the sequence and prioritization of reoptimizing multiple LSPs using elements of Global Concurrent Optimization (GCO) as described in Section 3.4, and applying policies across the network so that, for instance, LSPs for delay-sensitive services are reoptimized first.
プロセスは単純で、図15に示す例では、ステートフルPCE [Stateful-PCE]を使用してネットワークを監視し、必要に応じて再最適化アクションを実行します。このプロセスでは、OSSなどのリクエスターによってABNOコントローラーに対してサービス要求が行われます。サービスリクエストは、ポリシーに従って特定の条件下でLSPを再最適化する必要があることを示しています。これにより、ABNOコントローラーは、セクション3.4で説明されているように、グローバル同時最適化（GCO）の要素を使用して複数のLSPを再最適化するシーケンスと優先順位を管理し、ネットワーク全体にポリシーを適用して、たとえば遅延の影響を受けやすいサービスのLSPを再最適化できます。最初。
The ABNO Controller commissions the PCE to compute and set up the initial path.
ABNOコントローラーはPCEに初期パスの計算とセットアップを依頼します。
Over time, the PCE monitors the changes in the network as reflected in the TED, and according to the configured policy may compute and set up a replacement path, using make-before-break within the network.
時間の経過とともに、PCEはTEDに反映されたネットワークの変更を監視し、構成されたポリシーに従って、ネットワーク内のmake-before-breakを使用して置換パスを計算および設定できます。
Once the new path has been set up and the network reports that it is being used correctly, the PCE tears down the old path and may report the reoptimization event to the ABNO Controller.
新しいパスがセットアップされ、ネットワークがそれが正しく使用されていることをネットワークが報告すると、PCEは古いパスを破棄し、再最適化イベントをABNOコントローラーに報告します。
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------------+------------+
| ABNO Controller |
+------------+------------+
|
+------+ +-------+-------+ +-----+
|Policy+-----+ PCE +-----+ TED |
|Agent | +-------+-------+ +-----+
+------+ |
|
+----------------------+----------------------+
/ Network \
+-------------------------------------------------+
Figure 15: The Make-before-Break Process
図15：Make-before-Breakプロセス
Make-before-break may also be used to repair a failed LSP where there is a desire to retain resources along some of the path, and where there is the potential for other LSPs to "steal" the resources if the failed LSP is torn down first. Unlike the example in Section 3.3.1, this case addresses a situation where the service is interrupted, but this interruption arises from the break in service introduced by the network failure. Obviously, in the case of a point-to-multipoint LSP, the failure might only affect part of the tree and the disruption will only be to a subset of the destination leaves so that a make-before-break restoration approach will not cause disruption to the leaves that were not affected by the original failure.
Make-before-breakは、パスの一部に沿ってリソースを保持したい場合や、失敗したLSPが破壊された場合に他のLSPがリソースを「盗む」可能性がある場合に、失敗したLSPを修復するためにも使用できます。最初。セクション3.3.1の例とは異なり、このケースはサービスが中断された状況に対処しますが、この中断はネットワーク障害によって導入されたサービスの中断から発生します。明らかに、ポイントツーマルチポイントLSPの場合、障害はツリーの一部にのみ影響する可能性があり、中断は宛先リーフのサブセットにのみ影響するため、make-before-break復元アプローチが中断を引き起こさないようにします。元の失敗の影響を受けなかった葉に。
Figure 16 shows the components that interact for this use case. A service request is made to the ABNO Controller by a requester such as the OSS. The service request indicates that the LSP may be restored after failure and should attempt to reuse as much of the original path as possible.
図16は、このユースケースで相互作用するコンポーネントを示しています。サービス要求は、OSSなどのリクエスターによってABNOコントローラーに対して行われます。サービスリクエストは、LSPが障害後に復元される可能性があることを示しており、元のパスを可能な限り再利用する必要があります。
The ABNO Controller commissions the PCE to compute and set up the initial path. The ABNO Controller also requests the OAM Handler to initiate OAM on the LSP and to monitor the results.
ABNOコントローラーはPCEに初期パスの計算とセットアップを依頼します。 ABNOコントローラーは、LSPでOAMを開始して結果を監視するようにOAMハンドラーにも要求します。
At some point, the network reports a fault to the OAM Handler, which notifies the ABNO Controller.
ある時点で、ネットワークは障害をOAMハンドラーに報告し、それがABNOコントローラーに通知します。
The ABNO Controller commissions the PCE to compute a new path, reusing as much of the original path as possible, and the PCE sets up the new LSP.
ABNOコントローラーはPCEに新しいパスの計算を依頼し、元のパスを可能な限り再利用して、PCEが新しいLSPをセットアップします。
Once the new path has been set up and the network reports that it is being used correctly, the ABNO Controller instructs the PCE to tear down the old path.
新しいパスがセットアップされ、ネットワークがそれが正しく使用されていることをレポートすると、ABNOコントローラーはPCEに古いパスを破棄するように指示します。
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------------+------------+ +-------+
| ABNO Controller +---+ OAM |
+------------+------------+ |Handler|
| +---+---+
+-------+-------+ |
| PCE | |
+-------+-------+ |
| |
+----------------------+--------------------+-+
/ Network \
+-------------------------------------------------+
Figure 16: The Make-before-Break Restoration Process
図16：Make-before-Break復元プロセス
In a more complicated use case, an LSP may be monitored for a number of attributes, such as delay and jitter. When the LSP falls below a threshold, the traffic may be moved to another LSP that offers the desired (or at least a better) quality of service. To achieve this, it is necessary to establish the new LSP and test it, and because the traffic must not be interrupted, make-before-break must be used.
より複雑な使用例では、LSPは遅延やジッターなどの多くの属性について監視される場合があります。 LSPがしきい値を下回ると、トラフィックは、望ましい（または少なくともより良い）サービス品質を提供する別のLSPに移動される場合があります。これを実現するには、新しいLSPを確立してテストする必要があります。トラフィックが中断されないようにする必要があるため、make-before-breakを使用する必要があります。
Moreover, it may be the case that no new LSP can provide the desired attributes and that a number of LSPs need to be tested so that the best can be selected. Furthermore, even when the original LSP is set up, it could be desirable to test a number of LSPs before deciding which should be used to carry the traffic.
さらに、新しいLSPが目的の属性を提供できず、最適なものを選択できるようにいくつかのLSPをテストする必要がある場合もあります。さらに、元のLSPがセットアップされている場合でも、トラフィックの伝送に使用するLSPを決定する前に、いくつかのLSPをテストすることが望ましい場合があります。
Figure 17 shows the components that interact for this use case. Because multiple LSPs might exist at once, a distinct action is needed to coordinate which one carries the traffic, and this is the job of the I2RS Client acting under the control of the ABNO Controller.
図17は、このユースケースで相互作用するコンポーネントを示しています。一度に複数のLSPが存在する可能性があるため、トラフィックを運ぶLSPを調整するための個別のアクションが必要です。これは、ABNOコントローラーの制御下で動作するI2RSクライアントの仕事です。
The OAM Handler is responsible for initiating tests on the LSPs and for reporting the results back to the ABNO Controller. The OAM Handler can also check end-to-end connectivity test results across a multi-domain network even when each domain runs a different technology. For example, an end-to-end path might be achieved by stitching together an MPLS segment, an Ethernet/VLAN segment, another IP segment, etc.
OAMハンドラーは、LSPのテストを開始し、結果をABNOコントローラーに報告します。 OAMハンドラーは、各ドメインが異なるテクノロジーを実行している場合でも、マルチドメインネットワーク全体のエンドツーエンドの接続テスト結果をチェックすることもできます。たとえば、エンドツーエンドのパスは、MPLSセグメント、イーサネット/ VLANセグメント、別のIPセグメントなどをつなぎ合わせることで実現できます。
Otherwise, the process is similar to that for reoptimization as discussed in Section 3.3.1.
それ以外は、プロセスはセクション3.3.1で説明した再最適化のプロセスと同様です。
+---------------------------------------------+
| OSS / NMS / Application Service Coordinator |
+----------------------+----------------------+
|
+------+ +------------+------------+ +-------+
|Policy+---+ ABNO Controller +----+ OAM |
|Agent | | +--+ |Handler|
+------+ +------------+------------+ | +---+---+
| | |
+-------+-------+ +--+---+ |
| PCE | | I2RS | |
+-------+-------+ |Client| |
| +--+---+ |
| | |
+-----------------------+---------------+-----+-+
/ Network \
+---------------------------------------------------+
Figure 17: The Make-before-Break Path Test and Selection Process
図17：Make-before-Break Pathテストと選択プロセス
The pseudocode that follows gives an indication of the interactions between ABNO components.
次の疑似コードは、ABNOコンポーネント間の相互作用を示しています。
OSS requests quality-assured service
OSSが品質保証サービスを要求
:Label1
：Label1
DoWhile not enough LSPs (ABNO Controller) Instruct PCE to compute and provision the LSP (ABNO Controller) Create the LSP (PCE) EndDo
DoWhile not LSPs（ABNO Controller）PCEにLSP（ABNO Controller）を計算してプロビジョニングするように指示するLSP（PCE）EndDoを作成する
:Label2
：Label2
DoFor each LSP (ABNO Controller) Test LSP (OAM Handler) Report results to ABNO Controller (OAM Handler) EndDo
DoFor each LSP（ABNO Controller）Test LSP（OAM Handler）Report results to ABNO Controller（OAM Handler）EndDo
Evaluate results of all tests (ABNO Controller) Select preferred LSP and instruct I2RS Client (ABNO Controller) Put traffic on preferred LSP (I2RS Client)
すべてのテストの結果を評価します（ABNOコントローラー）優先LSPを選択し、I2RSクライアント（ABNOコントローラー）に指示しますトラフィックを優先LSP（I2RSクライアント）に配置します
DoWhile too many LSPs (ABNO Controller) Instruct PCE to tear down unwanted LSP (ABNO Controller) Tear down unwanted LSP (PCE) EndDo DoUntil trigger (OAM Handler, ABNO Controller, Policy Agent) keep sending traffic (Network) Test LSP (OAM Handler) EndDo
DoWhile too many LSPs（ABNO Controller）PCEにティアダウンして不要なLSP（ABNO Controller）ティアダウンする不要なLSP（PCE）EndDo DoUntilトリガー（OAMハンドラー、ABNOコントローラー、ポリシーエージェント）トラフィックを送信し続ける（ネットワーク）テストLSP（OAMハンドラー） ）EndDo
If there is already a suitable LSP (ABNO Controller) GoTo Label2 Else GoTo Label1 EndIf
すでに適切なLSP（ABNOコントローラー）がある場合GoTo Label2 Else GoTo Label1 EndIf
Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents a key technology for maximizing network efficiency by computing a set of traffic-engineered paths concurrently. A GCO path computation request will simultaneously consider the entire topology of the network, and the complete set of new LSPs together with their respective constraints. Similarly, GCO may be applied to recompute the paths of a set of existing LSPs.
グローバル同時最適化（GCO）は[RFC5557]で定義されており、トラフィックエンジニアリングされたパスのセットを同時に計算することによりネットワーク効率を最大化するための重要なテクノロジーを表しています。 GCOパス計算リクエストでは、ネットワークのトポロジ全体と、それぞれの制約とともに新しいLSPの完全なセットが同時に考慮されます。同様に、GCOを適用して、既存の一連のLSPのパスを再計算することができます。
GCO may be requested in a number of scenarios. These include:
GCOは、いくつかのシナリオで要求される場合があります。これらには以下が含まれます：
o Routing of new services where the PCE should consider other services or network topology.
o PCEが他のサービスまたはネットワークトポロジを考慮する必要がある新しいサービスのルーティング。
o A reoptimization of existing services due to fragmented network resources or suboptimized placement of sequentially computed services.
o 断片化されたネットワークリソースまたは逐次計算されたサービスの最適化されていない配置による既存のサービスの再最適化。
o Recovery of connectivity for bulk services in the event of a catastrophic network failure.
o 壊滅的なネットワーク障害が発生した場合の、バルクサービスの接続の回復。
A service provider may also want to compute and deploy new bulk services based on a predicted traffic matrix. The GCO functionality and capability to perform concurrent computation provide a significant network optimization advantage, thus utilizing network resources optimally and avoiding blocking.
サービスプロバイダーは、予測されたトラフィックマトリックスに基づいて、新しいバルクサービスを計算して展開することもできます。同時計算を実行するGCOの機能と機能は、ネットワークの最適化に大きな利点をもたらし、ネットワークリソースを最適に利用してブロックを回避します。
The following use case shows how the ABNO architecture and components are used to achieve concurrent optimization across a set of services.
次の使用例は、ABNOアーキテクチャとコンポーネントを使用して、一連のサービス全体で同時最適化を実現する方法を示しています。
When considering the GCO path computation problem, we can split the GCO objective functions into three optimization categories:
GCOパス計算問題を検討するとき、GCO目的関数を3つの最適化カテゴリに分割できます。
o Minimize aggregate Bandwidth Consumption (MBC).
o 総帯域幅消費（MBC）を最小限に抑えます。
o Minimize the load of the Most Loaded Link (MLL).
o 最多負荷リンク（MLL）の負荷を最小限に抑えます。
o Minimize Cumulative Cost of a set of paths (MCC).
o パスのセット（MCC）の累積コストを最小化します。
This use case assumes that the GCO request will be offline and be initiated from an NMS/OSS; that is, it may take significant time to compute the service, and the paths reported in the response may want to be verified by the user before being provisioned within the network.
この使用例では、GCO要求がオフラインであり、NMS / OSSから開始されることを想定しています。つまり、サービスの計算にはかなりの時間がかかる可能性があり、応答で報告されたパスは、ネットワーク内でプロビジョニングされる前にユーザーによる検証が必要になる場合があります。
1. Request Management
1. リクエスト管理
The NMS/OSS issues a request for new service connectivity for bulk services. The ABNO Controller verifies that the NMS/OSS has sufficient rights to make the service request and apply a GCO attribute with a request to Minimize aggregate Bandwidth Consumption (MBC), as shown in Figure 18.
NMS / OSSは、バルクサービスの新しいサービス接続を要求します。図18に示すように、ABNOコントローラは、NMS / OSSがサービスリクエストを作成し、GCO属性を適用して総帯域幅消費量（MBC）を最小化する十分な権限を持っていることを確認します。
+---------------------+
| NMS/OSS |
+----------+----------+
|
V
+--------+ +-----------+-------------+
| Policy +-->-+ ABNO Controller |
| Agent | | |
+--------+ +-------------------------+
Figure 18: NMS Request to ABNO Controller
図18：ABNOコントローラーへのNMS要求
1a. Each service request has a source, destination, and bandwidth request. These service requests are sent to the ABNO Controller and categorized as GCO requests. The PCE uses the appropriate policy for each request and consults the TED for the packet layer.
1a。各サービス要求には、送信元、宛先、および帯域幅要求があります。これらのサービス要求はABNOコントローラーに送信され、GCO要求として分類されます。 PCEは各要求に適切なポリシーを使用し、パケットレイヤーのTEDを調べます。
2. Service Path Computation in the Packet Layer
2. パケットレイヤーでのサービスパス計算
To compute a set of services for the GCO application, PCEP supports synchronization vector (SVEC) lists for synchronized dependent path computations as defined in [RFC5440] and described in [RFC6007].
GCOアプリケーションの一連のサービスを計算するために、PCEPは、[RFC5440]で定義され、[RFC6007]で説明されている同期従属パス計算の同期ベクトル（SVEC）リストをサポートしています。
2a. The ABNO Controller sends the bulk service request to the GCO-capable packet-layer PCE using PCEP messaging. The PCE uses the appropriate policy for the request and consults the TED for the packet layer, as shown in Figure 19.
2a。 ABNOコントローラーは、PCEPメッセージングを使用して、バルクサービス要求をGCO対応のパケット層PCEに送信します。図19に示すように、PCEは要求に適切なポリシーを使用し、パケットレイヤーのTEDを調べます。
+-----------------+
| ABNO Controller |
+----+------------+
|
V
+--------+ +--+-----------+ +--------+
| | | | | |
| Policy +-->--+ GCO-Capable +---+ Packet |
| Agent | | Packet-Layer | | TED |
| | | PCE | | |
+--------+ +--------------+ +--------+
Figure 19: Path Computation Request from GCO-Capable PCE
図19：GCO対応PCEからのパス計算要求
2b. Upon receipt of the bulk (GCO) service requests, the PCE applies the MBC objective function and computes the services concurrently.
2b。バルク（GCO）サービス要求を受信すると、PCEはMBC目的関数を適用し、サービスを同時に計算します。
2c. Once the requested GCO service path computation completes, the PCE sends the resulting paths back to the ABNO Controller. The response includes a fully computed explicit path for each service (TE LSP).
2c。要求されたGCOサービスパスの計算が完了すると、PCEは結果のパスをABNOコントローラーに送り返します。応答には、各サービス（TE LSP）の完全に計算された明示的なパスが含まれます。
3. The concurrently computed solution received from the PCE is sent back to the NMS/OSS by the ABNO Controller as a PCEP response, as shown in Figure 20. The NMS/OSS user can then check the candidate paths and either provision the new services or save the solution for deployment in the future.
3. PCEから受信した同時に計算されたソリューションは、図20に示すように、PCEP応答としてABNOコントローラーによってNMS / OSSに送り返されます。NMS/ OSSユーザーは、候補パスを確認し、新しいサービスをプロビジョニングするか、保存することができます。将来の展開のためのソリューション。
+---------------------+
| NMS/OSS |
+----------+----------+
^
|
+----------+----------+
| ABNO Controller |
| |
+---------------------+
Figure 20: ABNO Sends Solution to the NMS/OSS
図20：ABMSがNMS / OSSにソリューションを送信
The ABNO architecture provides the capability for reactive network control of resources relying on classification, profiling, and prediction based on current demands and resource utilization. Server-layer transport network resources, such as Optical Transport Network (OTN) time-slicing [G.709], or the fine granularity grid of wavelengths with variable spectral bandwidth (flexi-grid) [G.694.1], can be manipulated to meet current and projected demands in a model called Elastic Optical Networks (EON) [EON].
ABNOアーキテクチャは、現在の需要とリソース使用率に基づく分類、プロファイリング、および予測に依存するリソースのリアクティブネットワーク制御の機能を提供します。オプティカルトランスポートネットワーク（OTN）タイムスライシング[G.709]、または可変スペクトル帯域幅の波長の細かい粒度のグリッド（フレキシグリッド）[G.694.1]などのサーバー層のトランスポートネットワークリソースは、次のように操作できます。 Elastic Optical Networks（EON）[EON]と呼ばれるモデルで、現在および将来の需要に対応します。
EON provides spectrum-efficient and scalable transport by introducing flexible granular traffic grooming in the optical frequency domain. This is achieved using arbitrary contiguous concatenation of the optical spectrum that allows the creation of custom-sized bandwidth. This bandwidth is defined in slots of 12.5 GHz.
EONは、光周波数ドメインで柔軟なきめ細かいトラフィックグルーミングを導入することにより、スペクトル効率が高くスケーラブルなトランスポートを提供します。これは、カスタムサイズの帯域幅の作成を可能にする光スペクトルの任意の連続した連結を使用して達成されます。この帯域幅は、12.5 GHzのスロットで定義されます。
Adaptive Network Management (ANM) with EON allows appropriately sized optical bandwidth to be allocated to an end-to-end optical path. In flexi-grid, the allocation is performed according to the traffic volume, optical modulation format, and associated reach, or following user requests, and can be achieved in a highly spectrum-efficient and scalable manner. Similarly, OTN provides for flexible and granular provisioning of bandwidth on top of Wavelength Switched Optical Networks (WSONs).
EONを使用したAdaptive Network Management（ANM）により、適切なサイズの光帯域幅をエンドツーエンドの光パスに割り当てることができます。フレキシグリッドでは、割り当てはトラフィック量、光変調フォーマット、および関連するリーチ、またはユーザーの要求に従って行われ、スペクトル効率が高くスケーラブルな方法で実現できます。同様に、OTNはWavelength Switched Optical Network（WSON）に加えて、帯域幅を柔軟かつきめ細かくプロビジョニングできます。
To efficiently use optical resources, a system is required that can monitor network resources and decide the optimal network configuration based on the status, bandwidth availability, and user service. We call this ANM.
光リソースを効率的に使用するには、ネットワークリソースを監視し、ステータス、帯域幅の可用性、ユーザーサービスに基づいて最適なネットワーク構成を決定できるシステムが必要です。これをANMと呼びます。
There are different reasons to trigger an adaptive network management process; these include:
適応型ネットワーク管理プロセスをトリガーする理由はいくつかあります。これらには以下が含まれます：
o Measurement: Traffic measurements can be used in order to cause spectrum allocations that fit the traffic needs as efficiently as possible. This function may be influenced by measuring the IP router traffic flows, by examining traffic engineering or link state databases, by usage thresholds for critical links in the network, or by requests from external entities. Nowadays, network operators have active monitoring probes in the network that store their results in the OSS. The OSS or OAM Handler components activate this measurement-based trigger, so the ABNO Controller would not be directly involved in this case.
o 測定：トラフィック測定は、トラフィックのニーズにできるだけ効率的に適合するスペクトル割り当てを引き起こすために使用できます。この機能は、IPルーターのトラフィックフローの測定、トラフィックエンジニアリングまたはリンク状態データベースの調査、ネットワーク内の重要なリンクの使用量のしきい値、または外部エンティティからの要求によって影響を受ける可能性があります。現在、ネットワークオペレーターは、ネットワークにアクティブな監視プローブを備えており、その結果をOSSに保存しています。 OSSまたはOAMハンドラーコンポーネントは、この測定ベースのトリガーをアクティブにするため、この場合、ABNOコントローラーは直接関与しません。
o Human: Operators may request ABNO to run an adaptive network planning process via an NMS.
o 人間：事業者は、NMSを介して適応型ネットワーク計画プロセスを実行するようにABNOに要求できます。
o Periodic: An adaptive network planning process can be run periodically to find an optimum configuration.
o 定期的：最適な構成を見つけるために、適応型ネットワーク計画プロセスを定期的に実行できます。
An ABNO Controller would receive a request from an OSS or NMS to run an adaptive network manager process.
ABNOコントローラーは、OSSまたはNMSから、適応型ネットワークマネージャープロセスを実行する要求を受け取ります。
Based on the human or periodic trigger requests described in the previous section, the OSS or NMS will send a request to the ABNO Controller to perform EON-based GCO. The ABNO Controller will select a set of services to be reoptimized and choose an objective function that will deliver the best use of network resources. In making these choices, the ABNO Controller is guided by network-wide policy on the use of resources, the definition of optimization, and the level of perturbation to existing services that is tolerable.
前のセクションで説明した人的または定期的なトリガー要求に基づいて、OSSまたはNMSはENOベースのGCOを実行する要求をABNOコントローラーに送信します。 ABNOコントローラーは、再最適化するサービスのセットを選択し、ネットワークリソースを最大限に活用する目的関数を選択します。これらの選択を行う際、ABNOコントローラーは、リソースの使用、最適化の定義、および許容できる既存のサービスへの摂動のレベルに関するネットワーク全体のポリシーによって導かれます。
This request for GCO is passed to the PCE, along the lines of the description in Section 3.4. The PCE can then consider the end-to-end paths and every channel's optimal spectrum assignment in order to satisfy traffic demands and optimize the optical spectrum consumption within the network.
このGCOの要求は、セクション3.4の説明に従ってPCEに渡されます。 PCEは、トラフィックの需要を満たし、ネットワーク内の光スペクトル消費を最適化するために、エンドツーエンドパスとすべてのチャネルの最適なスペクトル割り当てを検討できます。
The PCE will operate on the TED but is likely to also be stateful so that it knows which LSPs correspond to which waveband allocations on which links in the network. Once the PCE arrives at an answer, it returns a set of potential paths to the ABNO Controller, which passes them on to the NMS or OSS to supervise/select the subsequent path setup/modification process.
PCEはTEDで動作しますが、ステートフルである可能性が高いため、ネットワーク内のどのリンクでどのLSPがどの波長帯域割り当てに対応するかがわかります。 PCEが回答に到達すると、一連の潜在的なパスがABNOコントローラーに返され、それがNMSまたはOSSに渡されて、後続のパスのセットアップ/変更プロセスを監視/選択します。
This exchange is shown in Figure 21. Note that the figure does not show the interactions used by the OSS/NMS for establishing or modifying LSPs in the network.
この交換を図21に示します。この図は、ネットワークでLSPを確立または変更するためにOSS / NMSが使用する相互作用を示していないことに注意してください。
+---------------------------+
| OSS or NMS |
+-----------+---+-----------+
| ^
V |
+------+ +----------+---+----------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+---+----------+
| ^
V |
+-----+---+----+
+ PCE |
+--------------+
Figure 21: Adaptive Network Management with Human Intervention
図21：人間の介入による適応型ネットワーク管理
Although most network operations are supervised by the operator, there are some actions that may not require supervision, like a simple modification of a modulation format in a Bit-rate Variable Transponder (BVT) (to increase the optical spectrum efficiency or reduce energy consumption). In this process, where human intervention is not required, the PCE sends the Provisioning Manager a new configuration to configure the network elements, as shown in Figure 22.
ほとんどのネットワーク操作はオペレーターによって監視されますが、ビットレート可変トランスポンダー（BVT）の変調形式の単純な変更（光スペクトル効率を上げる、またはエネルギー消費を減らすため）のように、監視を必要としないアクションもあります。 。このプロセスでは、人間の介入が不要な場合、PCEはプロビジョニングマネージャーに新しい構成を送信して、ネットワーク要素を構成します（図22を参照）。
+------------------------+
| OSS or NMS |
+-----------+------------+
|
V
+------+ +----------+------------+
|Policy+->-+ ABNO Controller |
|Agent | | |
+------+ +----------+------------+
|
V
+------+------+
+ PCE |
+------+------+
|
V
+----------------------------------+
| Provisioning Manager |
+----------------------------------+
Figure 22: Adaptive Network Management without Human Intervention
図22：人の介入なしの適応型ネットワーク管理
Pseudowires in an MPLS network [RFC3985] operate as a form of layered network over the connectivity provided by the MPLS network. The pseudowires are carried by LSPs operating as transport tunnels, and planning is necessary to determine how those tunnels are placed in the network and which tunnels are used by any pseudowire.
MPLSネットワーク[RFC3985]の疑似配線は、MPLSネットワークによって提供される接続を介して、レイヤードネットワークの形式として動作します。疑似配線は、トランスポートトンネルとして動作するLSPによって伝送されます。これらのトンネルをネットワークに配置する方法、およびどの疑似配線でどのトンネルを使用するかを決定するための計画が必要です。
This section considers four use cases: multi-segment pseudowires, path-diverse pseudowires, path-diverse multi-segment pseudowires, and pseudowire segment protection. Section 3.6.5 describes the applicability of the ABNO architecture to these four use cases.
このセクションでは、マルチセグメントの疑似配線、パスダイバースの疑似配線、パスダイバースの複数セグメントの疑似配線、および疑似配線セグメント保護の4つの使用例について検討します。セクション3.6.5は、これら4つの使用例へのABNOアーキテクチャの適用性を説明しています。
[RFC5254] describes the architecture for multi-segment pseudowires. An end-to-end service, as shown in Figure 23, can consist of a series of stitched segments shown in the figure as AC, PW1, PW2, PW3, and AC. Each pseudowire segment is stitched at a "stitching Provider Edge" (S-PE): for example, PW1 is stitched to PW2 at S-PE1. Each access circuit (AC) is stitched to a pseudowire segment at a "terminating PE" (T-PE): for example, PW1 is stitched to the AC at T-PE1.
[RFC5254]は、マルチセグメント疑似配線のアーキテクチャについて説明しています。図23に示すように、エンドツーエンドサービスは、図にAC、PW1、PW2、PW3、およびACとして示されている一連のステッチされたセグメントで構成できます。各疑似配線セグメントは「ステッチングプロバイダーエッジ」（S-PE）でステッチされます。たとえば、PW1はS-PE1でPW2にステッチされます。各アクセス回路（AC）は、「終端PE」（T-PE）で疑似配線セグメントにステッチされます。たとえば、PW1はT-PE1でACにステッチされます。
Each pseudowire segment is carried across the MPLS network in an LSP operating as a transport tunnel: for example, PW1 is carried in LSP1. The LSPs between PE nodes may traverse different MPLS networks with the PEs as border nodes, or the PEs may lie within the network such that each LSP spans only part of the network.
各疑似配線セグメントは、トランスポートトンネルとして動作するLSPのMPLSネットワークを介して伝送されます。たとえば、PW1はLSP1で伝送されます。 PEノード間のLSPは、境界ノードとしてPEを使用して異なるMPLSネットワークを通過する場合があります。または、PEがネットワーク内にあり、各LSPがネットワークの一部のみにまたがる場合があります。
----- ----- ----- -----
--- |T-PE1| LSP1 |S-PE1| LSP2 |S-PE3| LSP3 |T-PE2| +---+
| | AC | |=======| |=======| |=======| | AC | |
|CE1|----|........PW1........|..PW2........|..PW3........|----|CE2|
| | | |=======| |=======| |=======| | | |
--- | | | | | | | | +---+
----- ----- ----- -----
Figure 23: Multi-Segment Pseudowire
図23：マルチセグメント疑似配線
While the topology shown in Figure 23 is easy to navigate, the reality of a deployed network can be considerably more complex. The topology in Figure 24 shows a small mesh of PEs. The links between the PEs are not physical links but represent the potential of MPLS LSPs between the PEs.
図23に示すトポロジーは簡単にナビゲートできますが、展開されたネットワークの現実はかなり複雑になる可能性があります。図24のトポロジは、PEの小さなメッシュを示しています。 PE間のリンクは物理リンクではありませんが、PE間のMPLS LSPの可能性を表しています。
When establishing the end-to-end service between Customer Edge nodes (CEs) CE1 and CE2, some choice must be made about which PEs to use. In other words, a path computation must be made to determine the pseudowire segment "hops", and then the necessary LSP tunnels must be established to carry the pseudowire segments that will be stitched together.
カスタマーエッジノード（CE）CE1とCE2の間でエンドツーエンドサービスを確立する場合、使用するPEについて何らかの選択を行う必要があります。つまり、疑似配線セグメントの「ホップ」を決定するためにパス計算を行う必要があり、次に、ステッチされる疑似配線セグメントを伝送するために必要なLSPトンネルを確立する必要があります。
Of course, each LSP may itself require a path computation decision to route it through the MPLS network between PEs.
もちろん、各LSP自体が、PE間のMPLSネットワークを介してそれをルーティングするために、パス計算の決定を必要とする場合があります。
The choice of path for the multi-segment pseudowire will depend on such issues as:
マルチセグメント疑似配線のパスの選択は、次のような問題によって異なります。
- MPLS connectivity
- MPLS接続
- MPLS bandwidth availability
- MPLS帯域幅の可用性
- pseudowire stitching capability and capacity at PEs
- PEでの疑似配線ステッチ機能と容量
- policy and confidentiality considerations for use of PEs
- PEの使用に関するポリシーと機密性の考慮事項
-----
|S-PE5|
/-----\
--- ----- -----/ \----- ----- ---
|CE1|----|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|----|CE2|
--- -----\ -----\ ----- /----- ---
\ | ------- | /
\ ----- \----- /
-----|S-PE2|-------|S-PE4|-----
----- -----
Figure 24: Multi-Segment Pseudowire Network Topology
図24：マルチセグメント疑似配線ネットワークトポロジ
The connectivity service provided by a pseudowire may need to be resilient to failure. In many cases, this function is provided by provisioning a pair of pseudowires carried by path-diverse LSPs across the network, as shown in Figure 25 (the terminology is inherited directly from [RFC3985]). Clearly, in this case, the challenge is to keep the two LSPs (LSP1 and LSP2) disjoint within the MPLS network. This problem is not different from the normal MPLS path-diversity problem.
疑似配線によって提供される接続サービスは、障害に強い必要がある場合があります。多くの場合、この機能は、図25に示すように、ネットワーク全体でパスダイバースLSPによって運ばれる疑似配線のペアをプロビジョニングすることによって提供されます（用語は[RFC3985]から直接継承されます）。明らかに、この場合の課題は、2つのLSP（LSP1とLSP2）をMPLSネットワーク内で互いに素に保つことです。この問題は、通常のMPLSパスダイバーシティの問題と同じです。
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
----...................PW1...................----
--- - / | |=======================| | \ -----
| |/ | | | | \| |
| CE1 + | | MPLS Network | | + CE2 |
| |\ | | | | /| |
--- - \ | |=======================| | / -----
----...................PW2...................----
AC | |=======================| | AC
| | LSP2 | |
------- -------
Figure 25: Path-Diverse Pseudowires
図25：パス多様な疑似配線
The path-diverse pseudowire is developed in Figure 26 by the "dual-homing" of each CE through more than one PE. The requirement for LSP path diversity is exactly the same, but it is complicated by the LSPs having distinct end points. In this case, the head-end router (e.g., PE1) cannot be relied upon to maintain the path diversity through the signaling protocol because it is aware of the path of only one of the LSPs. Thus, some form of coordinated path computation approach is needed.
図26では、複数のPEを介した各CEの「デュアルホーミング」によって、パスダイバース疑似配線が開発されています。 LSPパスダイバーシティの要件はまったく同じですが、LSPに異なるエンドポイントがあるために複雑になります。この場合、ヘッドエンドルーター（PE1など）は、LSPの1つだけのパスを認識しているため、シグナリングプロトコルを介してパスダイバーシティを維持することはできません。したがって、何らかの形の協調パス計算アプローチが必要です。
------- -------
| PE1 | LSP1 | PE2 |
AC | |=======================| | AC
---...................PW1...................---
/ | |=======================| | \
----- / | | | | \ -----
| |/ ------- ------- \| |
| CE1 + MPLS Network + CE2 |
| |\ ------- ------- /| |
----- \ | PE3 | | PE4 | / -----
\ | |=======================| | /
---...................PW2...................---
AC | |=======================| | AC
| | LSP2 | |
------- -------
Figure 26: Path-Diverse Pseudowires with Disjoint PEs
図26：ばらばらのPEを持つパスダイバース疑似配線
Figure 27 shows how the services in the previous two sections may be combined to offer end-to-end diverse paths in a multi-segment environment. To offer end-to-end resilience to failure, two entirely diverse, end-to-end multi-segment pseudowires may be needed.
図27は、前の2つのセクションのサービスを組み合わせて、マルチセグメント環境でエンドツーエンドの多様なパスを提供する方法を示しています。障害に対するエンドツーエンドの復元力を提供するには、2つの完全に多様なエンドツーエンドのマルチセグメント疑似配線が必要になる場合があります。
----- -----
|S-PE5|--------------|T-PE4|
/-----\ ----- \
----- -----/ \----- ----- \ ---
|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|--|CE2|
--- / -----\ -----\ ----- /----- ---
|CE1|< ------- | ------- | /
--- \ ----- \----- \----- /
|T-PE3|-------|S-PE2|-------|S-PE4|-----
----- ----- -----
Figure 27: Path-Diverse Multi-Segment Pseudowire Network Topology
図27：パスダイバースマルチセグメント疑似配線ネットワークトポロジ
Just as in any diverse-path computation, the selection of the first path needs to be made with awareness of the fact that a second, fully diverse path is also needed. If a sequential computation was applied to the topology in Figure 27, the first path CE1,T-PE1,S-PE1, S-PE3,T-PE2,CE2 would make it impossible to find a second path that was fully diverse from the first.
多様なパスの計算と同様に、最初のパスの選択は、2番目の完全に多様なパスも必要であることを認識した上で行う必要があります。図27のトポロジに逐次計算が適用された場合、最初のパスCE1、T-PE1、S-PE1、S-PE3、T-PE2、CE2は、完全に異なる2番目のパスを見つけることを不可能にします。最初。
But the problem is complicated by the multi-layer nature of the network. It is not enough that the PEs are chosen to be diverse because the LSP tunnels between them might share links within the MPLS network. Thus, a multi-layer planning solution is needed to achieve the desired level of service.
しかし、問題はネットワークのマルチレイヤーの性質によって複雑になっています。 PE間のLSPトンネルがMPLSネットワーク内のリンクを共有する可能性があるため、PEが多様であるように選択されるだけでは十分ではありません。したがって、必要なレベルのサービスを実現するには、多層計画ソリューションが必要です。
An alternative to the end-to-end pseudowire protection service enabled by the mechanism described in Section 3.6.3 can be achieved by protecting individual pseudowire segments or PEs. For example, in Figure 27, the pseudowire between S-PE1 and S-PE5 may be protected by a pair of stitched segments running between S-PE1 and S-PE5, and between S-PE5 and S-PE3. This is shown in detail in Figure 28.
個別の疑似配線セグメントまたはPEを保護することにより、セクション3.6.3で説明されているメカニズムによって有効になるエンドツーエンドの疑似配線保護サービスの代替手段を実現できます。たとえば、図27では、S-PE1とS-PE5の間の疑似配線は、S-PE1とS-PE5の間、およびS-PE5とS-PE3の間を走るステッチセグメントのペアによって保護できます。これを図28に詳しく示します。
------- ------- -------
| S-PE1 | LSP1 | S-PE5 | LSP3 | S-PE3 |
| |============| |============| |
| .........PW1..................PW3.......... | Outgoing
Incoming | : |============| |============| : | Segment
Segment | : | ------- | :..........
...........: | | : |
| : | | : |
| : |=================================| : |
| .........PW2............................... |
| |=================================| |
| | LSP2 | |
------- -------
Figure 28: Fragment of a Segment-Protected Multi-Segment Pseudowire
図28：セグメント保護されたマルチセグメント疑似配線のフラグメント
The determination of pseudowire protection segments requires coordination and planning, and just as in Section 3.6.5, this planning must be cognizant of the paths taken by LSPs through the underlying MPLS networks.
疑似配線保護セグメントの決定には調整と計画が必要であり、セクション3.6.5と同様に、この計画は、基になるMPLSネットワークを介してLSPがたどるパスを認識する必要があります。
The ABNO architecture lends itself well to the planning and control of pseudowires in the use cases described above. The user or application needs a single point at which it requests services: the ABNO Controller. The ABNO Controller can ask a PCE to draw on the topology of pseudowire stitching-capable PEs as well as additional information regarding PE capabilities, such as load on PEs and administrative policies, and the PCE can use a series of TEDs or other PCEs for the underlying MPLS networks to determine the paths of the LSP tunnels. At the time of this writing, PCEP does not support path computation requests and responses concerning pseudowires, but the concepts are very similar to existing uses and the necessary extensions would be very small.
ABNOアーキテクチャは、上記のユースケースでの疑似配線の計画と制御に適しています。ユーザーまたはアプリケーションは、サービスを要求する単一のポイント、つまりABNOコントローラーを必要とします。 ABNOコントローラーは、疑似配線スティッチング対応PEのトポロジー、およびPEの負荷や管理ポリシーなどのPE機能に関する追加情報をPCEに要求することができ、PCEは一連のTEDまたは他のPCEを使用して、 LSPトンネルのパスを決定するための基盤となるMPLSネットワーク。これを書いている時点では、PCEPは疑似配線に関するパス計算要求と応答をサポートしていませんが、概念は既存の使用法と非常に似ており、必要な拡張は非常に小さくなります。
Once the paths have been computed, a number of different provisioning systems can be used to instantiate the LSPs and provision the pseudowires under the control of the Provisioning Manager. The ABNO Controller will use the I2RS Client to instruct the network devices about what traffic should be placed on which pseudowires and, in conjunction with the OAM Handler, can ensure that failure events are handled correctly, that service quality levels are appropriate, and that service protection levels are maintained.
パスが計算されると、いくつかの異なるプロビジョニングシステムを使用して、LSPをインスタンス化し、Provisioning Managerの制御下で疑似配線をプロビジョニングできます。 ABNOコントローラーは、I2RSクライアントを使用して、どの疑似配線にどのトラフィックを配置する必要があるかをネットワークデバイスに指示し、OAMハンドラーと組み合わせて、障害イベントが正しく処理され、サービス品質レベルが適切であり、そのサービスが保証されるようにします。保護レベルは維持されます。
In many respects, the pseudowire network forms an overlay network (with its own TED and provisioning mechanisms) carried by underlying packet networks. Further client networks (the pseudowire payloads) may be carried by the pseudowire network. Thus, the problem space being addressed by ABNO in this case is a classic multi-layer network.
多くの点で、疑似配線ネットワークは、基盤となるパケットネットワークによって運ばれる（独自のTEDおよびプロビジョニングメカニズムを備えた）オーバーレイネットワークを形成します。さらなるクライアントネットワーク（疑似配線ペイロード）は、疑似配線ネットワークによって運ばれるかもしれない。したがって、この場合、ABNOによって対処される問題空間は、古典的なマルチレイヤーネットワークです。
Considering the term "stratum" to broadly differentiate the layers of most concern to the application and to the network in general, the need for Cross-Stratum Optimization (CSO) arises when the application stratum and network stratum need to be coordinated to achieve operational efficiency as well as resource optimization in both application and network strata.
「層」という用語を、アプリケーションとネットワーク全体の最も重要な層を広く区別することを考えると、運用層とネットワーク層を調整して運用効率を達成する必要がある場合、層間最適化（CSO）が必要になります。アプリケーションとネットワークの両方の階層でのリソースの最適化。
Data center-based applications can provide a wide variety of services such as video gaming, cloud computing, and grid applications. High-bandwidth video applications are also emerging, such as remote medical surgery, live concerts, and sporting events.
データセンターベースのアプリケーションは、ビデオゲーム、クラウドコンピューティング、グリッドアプリケーションなど、さまざまなサービスを提供できます。遠隔医療手術、ライブコンサート、スポーツイベントなど、高帯域幅のビデオアプリケーションも登場しています。
This use case for the ABNO architecture is mainly concerned with data center applications that make substantial bandwidth demands either in aggregate or individually. In addition, these applications may need specific bounds on QoS-related parameters such as latency and jitter.
ABNOアーキテクチャのこの使用例は、主に、合計または個別にかなりの帯域幅を要求するデータセンターアプリケーションに関係しています。さらに、これらのアプリケーションでは、待ち時間やジッターなどのQoS関連パラメーターに特定の境界が必要になる場合があります。
Data centers come in a wide variety of sizes and configurations, but all contain compute servers, storage, and application control. Data centers offer application services to end-users, such as video gaming, cloud computing, and others. Since the data centers used to provide application services may be distributed around a network, the decisions about the control and management of application services, such as where to instantiate another service instance or to which data center a new client is assigned, can have a significant impact on the state of the network. Conversely, the capabilities and state of the network can have a major impact on application performance.
データセンターにはさまざまなサイズと構成がありますが、すべてに計算サーバー、ストレージ、およびアプリケーション制御が含まれています。データセンターは、ビデオゲーム、クラウドコンピューティングなどのアプリケーションサービスをエンドユーザーに提供します。アプリケーションサービスを提供するために使用されるデータセンターはネットワーク全体に分散される可能性があるため、アプリケーションサービスの制御と管理に関する決定（別のサービスインスタンスをインスタンス化する場所や新しいクライアントが割り当てられるデータセンターなど）は重要な場合があります。ネットワークの状態への影響。逆に、ネットワークの機能と状態は、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。
These decisions are typically made by applications with very little or no information concerning the underlying network. Hence, such decisions may be suboptimal from the application's point of view or considering network resource utilization and quality of service.
これらの決定は通常、基盤となるネットワークに関する情報がほとんどまたはまったくないアプリケーションによって行われます。したがって、そのような決定は、アプリケーションの観点から、またはネットワークリソースの使用率とサービスの品質を考慮して、最適とはいえない可能性があります。
Cross-Stratum Optimization is the process of optimizing both the application experience and the network utilization by coordinating decisions in the application stratum and the network stratum. Application resources can be roughly categorized into computing resources (i.e., servers of various types and granularities, such as Virtual Machines (VMs), memory, and storage) and content (e.g., video, audio, databases, and large data sets). By "network stratum" we mean the IP layer and below (e.g., MPLS, Synchronous Digital Hierarchy (SDH), OTN, WDM). The network stratum has resources that include routers, switches, and links. We are particularly interested in further unleashing the potential presented by MPLS and GMPLS control planes at the lower network layers in response to the high aggregate or individual demands from the application layer.
Cross-Stratum Optimizationは、アプリケーション層とネットワーク層の決定を調整することにより、アプリケーションエクスペリエンスとネットワーク使用率の両方を最適化するプロセスです。アプリケーションリソースは、コンピューティングリソース（つまり、仮想マシン（VM）、メモリ、ストレージなどのさまざまなタイプと粒度のサーバー）とコンテンツ（ビデオ、オーディオ、データベース、大きなデータセットなど）に大別できます。 「ネットワークストラタム」とは、IP層以下を意味します（例：MPLS、同期デジタル階層（SDH）、OTN、WDM）。ネットワーク層には、ルーター、スイッチ、リンクなどのリソースがあります。アプリケーション層からの高い集約的または個別の要求に応じて、下位のネットワーク層でMPLSおよびGMPLSコントロールプレーンによって示される可能性をさらに引き出すことに特に関心があります。
This use case demonstrates that the ABNO architecture can allow cross-stratum application/network optimization for the data center use case. Other forms of Cross-Stratum Optimization (for example, for peer-to-peer applications) are out of scope.
このユースケースは、ABNOアーキテクチャがデータセンターのユースケースのクロスストラタムアプリケーション/ネットワーク最適化を可能にすることを示しています。他の形式のストラタム間最適化（たとえば、ピアツーピアアプリケーションの場合）は範囲外です。
A key enabler for data center cost savings, consolidation, flexibility, and application scalability has been the technology of compute virtualization provided through Virtual Machines (VMs). To the software application, a VM looks like a dedicated processor with dedicated memory and a dedicated operating system.
データセンターのコスト削減、統合、柔軟性、およびアプリケーションのスケーラビリティを実現する主な要因は、仮想マシン（VM）を通じて提供されるコンピューティング仮想化のテクノロジーです。ソフトウェアアプリケーションから見ると、VMは専用メモリと専用オペレーティングシステムを備えた専用プロセッサのように見えます。
VMs not only offer a unit of compute power but also provide an "application environment" that can be replicated, backed up, and moved. Different VM configurations may be offered that are optimized for different types of processing (e.g., memory intensive, throughput intensive).
VMは、計算能力の単位を提供するだけでなく、複製、バックアップ、移動が可能な「アプリケーション環境」も提供します。さまざまなタイプの処理（たとえば、メモリ集約型、スループット集約型）向けに最適化されたさまざまなVM構成が提供される場合があります。
VMs may be moved between compute resources in a data center and could be moved between data centers. VM migration serves to balance load across data center resources and has several modes:
VMはデータセンター内のコンピューティングリソース間で移動でき、データセンター間で移動できます。 VMの移行は、データセンターのリソース全体で負荷を分散するのに役立ち、いくつかのモードがあります。
(i) scheduled vs. dynamic;
（i）スケジュール済みと動的。
(ii) bulk vs. sequential;
（ii）バルクとシーケンシャル。
(iii) point-to-point vs. point-to-multipoint
（iii）ポイントツーポイントとポイントツーマルチポイント
While VM migration may solve problems of load or planned maintenance within a data center, it can also be effective to reduce network load around the data center. But the act of migrating VMs, especially between data centers, can impact the network and other services that are offered.
VMの移行により、データセンター内の負荷や計画的なメンテナンスの問題が解決される場合がありますが、データセンター周辺のネットワーク負荷を軽減することも効果的です。ただし、特にデータセンター間でVMを移行する行為は、ネットワークや提供される他のサービスに影響を与える可能性があります。
For certain applications such as disaster recovery, bulk migration is required on the fly, which may necessitate concurrent computation and path setup dynamically.
災害復旧などの特定のアプリケーションでは、オンザフライでの一括移行が必要であり、計算とパスの動的な同時設定が必要になる場合があります。
Thus, application stratum operations must also take into account the situation in the network stratum, even as the application stratum actions may be driven by the status of the network stratum.
したがって、アプリケーション層のアクションはネットワーク層のステータスによって駆動される場合でも、アプリケーション層の操作では、ネットワーク層の状況も考慮する必要があります。
Application servers may be instantiated in many data centers located in different parts of the network. When an end-user makes an application request, a decision has to be made about which data center should host the processing and storage required to meet the request. One of the major drivers for operating multiple data centers (rather than one very large data center) is so that the application will run on a machine that is closer to the end-users and thus improve the user experience by reducing network latency. However, if the network is congested or the data center is overloaded, this strategy can backfire.
アプリケーションサーバーは、ネットワークのさまざまな部分にある多くのデータセンターでインスタンス化できます。エンドユーザーがアプリケーション要求を行う場合、要求を満たすために必要な処理とストレージをホストするデータセンターを決定する必要があります。 （1つの非常に大規模なデータセンターではなく）複数のデータセンターを運用するための主要なドライバーの1つは、アプリケーションがエンドユーザーに近いマシンで実行されるようにし、ネットワークの待ち時間を減らすことでユーザーエクスペリエンスを向上させることです。ただし、ネットワークが混雑している場合やデータセンターが過負荷の場合、この戦略は逆効果となる可能性があります。
Thus, the key factors to be considered in choosing the server on which to instantiate a VM for an application include:
したがって、アプリケーションのVMをインスタンス化するサーバーを選択する際に考慮すべき重要な要素は次のとおりです。
- The utilization of the servers in the data center
- データセンターのサーバーの利用
- The network load conditions within a data center
- データセンター内のネットワーク負荷状態
- The network load conditions between data centers
- データセンター間のネットワーク負荷状況
- The network conditions between the end-user and data center Again, the choices made in the application stratum need to consider the situation in the network stratum.
-エンドユーザーとデータセンター間のネットワーク条件繰り返しますが、アプリケーション層で行われる選択は、ネットワーク層の状況を考慮する必要があります。
This section shows how the ABNO architecture is applicable to the cross-stratum data center issues described in Section 3.7.1.
このセクションでは、セクション3.7.1で説明されているクロスストラタムデータセンターの問題にABNOアーキテクチャを適用する方法を示します。
Figure 29 shows a diagram of an example data center-based application. A carrier network provides access for an end-user through PE4. Three data centers (DC1, DC2, and DC3) are accessed through different parts of the network via PE1, PE2, and PE3.
図29に、データセンターベースのアプリケーション例の図を示します。キャリアネットワークは、PE4を介してエンドユーザーにアクセスを提供します。 3つのデータセンター（DC1、DC2、およびDC3）は、PE1、PE2、およびPE3を介してネットワークのさまざまな部分からアクセスされます。
The Application Service Coordinator receives information from the end-user about the desired services and converts this information to service requests that it passes to the ABNO Controller. The end-users may already know which data center they wish to use, or the Application Service Coordinator may be able to make this determination; otherwise, the task of selecting the data center must be performed by the ABNO Controller, and this may utilize a further database (see Section 2.3.1.8) to contain information about server loads and other data center parameters.
アプリケーションサービスコーディネーターは、エンドユーザーから目的のサービスに関する情報を受け取り、この情報をサービス要求に変換して、ABNOコントローラーに渡します。エンドユーザーは、使用したいデータセンターをすでに知っているか、アプリケーションサービスコーディネーターがこの決定を行うことができる場合があります。それ以外の場合は、データセンターを選択するタスクをABNOコントローラーで実行する必要があります。これには、追加のデータベース（セクション2.3.1.8を参照）を利用して、サーバーの負荷やその他のデータセンターパラメーターに関する情報を含めることができます。
The ABNO Controller examines the network resources using information gathered from the other ABNO components and uses those components to configure the network to support the end-user's needs.
ABNOコントローラーは、他のABNOコンポーネントから収集された情報を使用してネットワークリソースを調べ、それらのコンポーネントを使用してエンドユーザーのニーズをサポートするようにネットワークを構成します。
+----------+ +---------------------------------+
| End-User |--->| Application Service Coordinator |
+----------+ +---------------------------------+
| |
| v
| +-----------------+
| | ABNO Controller |
| +-----------------+
| |
| v
| +---------------------+ +--------------+
| |Other ABNO Components| | o o o DC 1 |
| +---------------------+ | \|/ |
| | ------|---O |
| v | | |
| --------------------------|-- +--------------+
| / Carrier Network PE1 | \
| / .....................O \ +--------------+
| | . | | o o o DC 2 |
| | PE4 . PE2 | | \|/ |
---------|----O........................O---|--|---O |
| . | | |
| . PE3 | +--------------+
\ .....................O /
\ | / +--------------+
--------------------------|-- | o o o DC 3 |
| | \|/ |
------|---O |
| |
+--------------+
Figure 29: The ABNO Architecture in the Context of Cross-Stratum Optimization for Data Centers
図29：データセンターのクロスストラタム最適化のコンテキストでのABNOアーキテクチャ
The ABNO Controller will need to utilize a number of components to realize the CSO functions described in Section 3.7.1.
ABNOコントローラーは、セクション3.7.1で説明されているCSO機能を実現するために、いくつかのコンポーネントを利用する必要があります。
The ALTO Server provides information about topological proximity and appropriate geographical location to servers with respect to the underlying networks. This information can be used to optimize the selection of peer location, which will help reduce the path of IP traffic or can contain it within specific service providers' networks. ALTO in conjunction with the ABNO Controller and the Application Service Coordinator can address general problems such as the selection of application servers based on resource availability and usage of the underlying networks.
ALTOサーバーは、基盤となるネットワークに関して、トポロジー的近接性とサーバーへの適切な地理的位置に関する情報を提供します。この情報を使用して、ピアの場所の選択を最適化できます。これにより、IPトラフィックのパスを削減したり、特定のサービスプロバイダーのネットワーク内に含めることができます。 ALTOは、ABNOコントローラーおよびアプリケーションサービスコーディネーターと連携して、リソースの可用性に基づくアプリケーションサーバーの選択や、基盤となるネットワークの使用状況などの一般的な問題に対処できます。
The ABNO Controller can also formulate a view of current network load from the TED and from the OAM Handler (for example, by running diagnostic tools that measure latency, jitter, and packet loss). This view obviously influences not just how paths from the end-user to the data center are provisioned but can also guide the selection of which data center should provide the service and possibly even the points of attachment to be used by the end-user and to reach the chosen data center. A view of how the PCE can fit in with CSO is provided in [CSO-PCE], on which the content of Figure 29 is based.
ABNOコントローラーは、TEDおよびOAMハンドラーからの現在のネットワーク負荷のビューを作成することもできます（たとえば、遅延、ジッター、およびパケット損失を測定する診断ツールを実行することにより）。このビューは明らかに、エンドユーザーからデータセンターへのパスがどのようにプロビジョニングされるかに影響するだけでなく、サービスを提供するデータセンターの選択や、エンドユーザーが使用する接続ポイントまでをガイドすることもできます。選択したデータセンターに到達します。 PCEがCSOにどのように適合するかを示す図は、[CSO-PCE]で提供されており、図29の内容はこの図に基づいています。
As already discussed, the combination of the ABNO Controller and the Application Service Coordinator will need to be able to select (and possibly migrate) the location of the VM that provides the service for the end-user. Since a common technique used to direct the end-user to the correct VM/server is to employ DNS redirection, an important capability of the ABNO Controller will be the ability to program the DNS servers accordingly.
すでに説明したように、ABNOコントローラーとアプリケーションサービスコーディネーターの組み合わせは、エンドユーザーにサービスを提供するVMの場所を選択（および場合によっては移行）できる必要があります。エンドユーザーを正しいVM /サーバーに導くために使用される一般的な手法はDNSリダイレクションを使用することであるため、ABNOコントローラーの重要な機能は、それに応じてDNSサーバーをプログラムする機能です。
Furthermore, as already noted in other sections of this document, the ABNO Controller can coordinate the placement of traffic within the network to achieve load balancing and to provide resilience to failures. These features can be used in conjunction with the functions discussed above, to ensure that the placement of new VMs, the traffic that they generate, and the load caused by VM migration can be carried by the network and do not disrupt existing services.
さらに、このドキュメントの他のセクションですでに述べたように、ABNOコントローラはネットワーク内のトラフィックの配置を調整して、ロードバランシングを実現し、障害に対する回復力を提供できます。これらの機能を上記の機能と組み合わせて使用すると、新しいVMの配置、VMが生成するトラフィック、およびVMの移行によって発生する負荷がネットワークによって伝達され、既存のサービスを中断することがなくなります。
The ABNO architecture allows use cases with joint network and application-layer optimization. In such a use case, an application is presented with an abstract network topology containing only information relevant to the application. The application computes its application-layer routing according to its application objective. The application may interact with the ABNO Controller to set up explicit LSPs to support its application-layer routing.
ABNOアーキテクチャは、共同ネットワークとアプリケーション層の最適化を伴う使用例を可能にします。このような使用例では、アプリケーションに関連する情報のみを含む抽象的なネットワークトポロジがアプリケーションに提示されます。アプリケーションは、アプリケーションの目的に応じて、アプリケーション層のルーティングを計算します。アプリケーションはABNOコントローラーと対話して、明示的なLSPをセットアップし、そのアプリケーション層ルーティングをサポートします。
The following steps are performed to illustrate such a use case.
次の手順は、このような使用例を示すために実行されます。
1. Application Request of Application-Layer Topology
1. アプリケーション層トポロジのアプリケーション要求
Consider the network shown in Figure 30. The network consists of five nodes and six links.
図30に示すネットワークについて考えてみます。このネットワークは、5つのノードと6つのリンクで構成されています。
The application, which has end points hosted at N0, N1, and N2, requests network topology so that it can compute its application-layer routing, for example, to maximize the throughput of content replication among end points at the three sites.
N0、N1、およびN2でホストされるエンドポイントを持つアプリケーションは、ネットワークトポロジを要求します。これにより、アプリケーションレイヤーのルーティングを計算して、たとえば、3つのサイトのエンドポイント間のコンテンツレプリケーションのスループットを最大化できます。
+----+ L0 Wt=10 BW=50 +----+
| N0 |............................| N3 |
+----+ +----+
| \ L4 |
| \ Wt=7 |
| \ BW=40 |
| \ |
L1 | +----+ |
Wt=10 | | N4 | L2 |
BW=45 | +----+ Wt=12 |
| / BW=30 |
| / L5 |
| / Wt=10 |
| / BW=45 |
+----+ +----+
| N1 |............................| N2 |
+----+ L3 Wt=15 BW=35 +----+
Figure 30: Raw Network Topology
図30：生のネットワークトポロジ
The request arrives at the ABNO Controller, which forwards the request to the ALTO Server component. The ALTO Server consults the Policy Agent, the TED, and the PCE to return an abstract, application-layer topology.
要求はABNOコントローラーに到着し、ABNOコントローラーがその要求をALTOサーバーコンポーネントに転送します。 ALTOサーバーは、ポリシーエージェント、TED、およびPCEに問い合わせて、抽象的なアプリケーション層トポロジを返します。
For example, the policy may specify that the bandwidth exposed to an application may not exceed 40 Mbps. The network has precomputed that the route from N0 to N2 should use the path N0->N3->N2, according to goals such as GCO (see Section 3.4). The ALTO Server can then produce a reduced topology for the application, such as the topology shown in Figure 31.
たとえば、ポリシーでは、アプリケーションに公開される帯域幅が40 Mbpsを超えないように指定できます。ネットワークは、N0からN2へのルートが、GCOなどの目標に従って、パスN0-> N3-> N2を使用する必要があることを事前に計算しています（セクション3.4を参照）。次に、ALTOサーバーは、図31に示すトポロジーなど、アプリケーションのトポロジーを削減できます。
+----+
| N0 |............
+----+ \
| \ \
| \ \
| \ \
| | \ AL0M2
L1 | | AL4M5 \ Wt=22
Wt=10 | | Wt=17 \ BW=30
BW=40 | | BW=40 \
| | \
| / \
| / \
| / \
+----+ +----+
| N1 |........................| N2 |
+----+ L3 Wt=15 BW=35 +----+
Figure 31: Reduced Graph for a Particular Application
図31：特定のアプリケーションの縮小グラフ
The ALTO Server uses the topology and existing routing to compute an abstract network map consisting of three PIDs. The pair-wise bandwidth as well as shared bottlenecks will be computed from the internal network topology and reflected in cost maps.
ALTOサーバーは、トポロジと既存のルーティングを使用して、3つのPIDで構成される抽象的なネットワークマップを計算します。ペアワイズ帯域幅と共有ボトルネックは、内部ネットワークトポロジから計算され、コストマップに反映されます。
2. Application Computes Application Overlay
2. アプリケーションがアプリケーションオーバーレイを計算する
Using the abstract topology, the application computes an application-layer routing. For concreteness, the application may compute a spanning tree to maximize the total bandwidth from N0 to N2. Figure 32 shows an example of application-layer routing, using a route of N0->N1->N2 for 35 Mbps and N0->N2 for 30 Mbps, for a total of 65 Mbps.
抽象トポロジを使用して、アプリケーションはアプリケーション層のルーティングを計算します。具体的には、アプリケーションはスパニングツリーを計算して、N0からN2までの合計帯域幅を最大化できます。図32は、35 MbpsでN0-> N1-> N2のルートを使用し、30 MbpsでN0-> N2のルートを使用して、合計65 Mbpsのアプリケーションレイヤールーティングの例を示しています。
+----+
| N0 |----------------------------------+
+----+ AL0M2 BW=30 |
| |
| |
| |
| |
| L1 |
| |
| BW=35 |
| |
| |
| |
V V
+----+ L3 BW=35 +----+
| N1 |...............................>| N2 |
+----+ +----+
Figure 32: Application-Layer Spanning Tree
図32：アプリケーション層のスパニングツリー
3. Application Path Set Up by the ABNO Controller
3. ABNOコントローラーによってセットアップされるアプリケーションパス
The application may submit its application routes to the ABNO Controller to set up explicit LSPs to support its operation. The ABNO Controller consults the ALTO maps to map the application-layer routing back to internal network topology and then instructs the Provisioning Manager to set up the paths. The ABNO Controller may re-trigger GCO to reoptimize network traffic engineering.
アプリケーションは、アプリケーションルートをABNOコントローラーに送信して、その操作をサポートする明示的なLSPを設定できます。 ABNOコントローラーは、ALTOマップを調べて、アプリケーション層ルーティングを内部ネットワークトポロジにマップし、プロビジョニングマネージャーにパスを設定するように指示します。 ABNOコントローラーはGCOを再トリガーして、ネットワークトラフィックエンジニアリングを再最適化します。
This section serves as a placeholder for other potential use cases that might get documented in future documents.
このセクションは、将来のドキュメントで文書化される可能性がある他の潜在的な使用事例のプレースホルダーとして機能します。
This use case could cover the following scenarios:
この使用例では、次のシナリオをカバーできます。
- Nested LSPs
- ネストされたLSP
- Packet Classification (IP flows into LSPs at edge routers)
- パケット分類（エッジルーターでLSPにIPフロー）
- Bucket Stuffing
- バケット詰め
- IP Flows into ECMP Hash Bucket
- ECMPハッシュバケットへのIPフロー
Bandwidth scheduling consists of configuring LSPs based on a given time schedule. This can be used to support maintenance or operational schedules or to adjust network capacity based on traffic pattern detection.
帯域幅スケジューリングは、所定のタイムスケジュールに基づいてLSPを構成することで構成されます。これを使用して、メンテナンスまたは運用スケジュールをサポートしたり、トラフィックパターン検出に基づいてネットワーク容量を調整したりできます。
The ABNO framework provides the components to enable bandwidth scheduling solutions.
ABNOフレームワークは、帯域幅スケジューリングソリューションを可能にするコンポーネントを提供します。
The ABNO architecture described in this document is presented in terms of functional units. Each unit could be implemented separately or bundled with other units into single programs or products. Furthermore, each implemented unit or bundle could be deployed on a separate device (for example, a network server) or on a separate virtual machine (for example, in a data center), or groups of programs could be deployed on the same processor. From the point of view of the architectural model, these implementation and deployment choices are entirely unimportant.
このドキュメントで説明されているABNOアーキテクチャは、機能単位の観点から提示されています。各ユニットは個別に実装するか、他のユニットとバンドルして単一のプログラムまたは製品にすることができます。さらに、実装された各ユニットまたはバンドルを個別のデバイス（ネットワークサーバーなど）または個別の仮想マシン（データセンターなど）に展開したり、プログラムのグループを同じプロセッサに展開したりできます。アーキテクチャモデルの観点からは、これらの実装と展開の選択はまったく重要ではありません。
Similarly, the realization of a functional component of the ABNO architecture could be supported by more than one instance of an implementation, or by different instances of different implementations that provide the same or similar function. For example, the PCE component might have multiple instantiations for sharing the processing load of a large number of computation requests, and different instances might have different algorithmic capabilities so that one instance might serve parallel computation requests for disjoint paths, while another instance might have the capability to compute optimal point-to-multipoint paths.
同様に、ABNOアーキテクチャの機能コンポーネントの実現は、実装の複数のインスタンス、または同じまたは類似の機能を提供する異なる実装の異なるインスタンスによってサポートできます。たとえば、PCEコンポーネントには、多数の計算リクエストの処理負荷を共有するための複数のインスタンスがあり、インスタンスごとに異なるアルゴリズム機能を備えているため、1つのインスタンスが互いに素なパスの並列計算リクエストを処理し、別のインスタンスが最適なポイントツーマルチポイントパスを計算する機能。
This ability to have multiple instances of ABNO components also enables resiliency within the model, since in the event of the failure of one instance of one component (because of software failure, hardware failure, or connectivity problems) other instances can take over. In some circumstances, synchronization between instances of components may be needed in order to facilitate seamless resiliency.
ABNOコンポーネントの複数のインスタンスを持つこの機能により、1つのコンポーネントの1つのインスタンスに障害が発生した場合（ソフトウェアの障害、ハードウェアの障害、または接続の問題により）、他のインスタンスが引き継ぐことができるため、モデル内の復元力も有効になります。状況によっては、シームレスな復元力を促進するために、コンポーネントのインスタンス間の同期が必要になる場合があります。
How these features are achieved in an ABNO implementation or deployment is outside the scope of this document.
ABNOの実装または展開でこれらの機能を実現する方法は、このドキュメントの範囲外です。
The ABNO architecture describes a network system, and security must play an important part.
ABNOアーキテクチャはネットワークシステムを表し、セキュリティが重要な役割を果たす必要があります。
The first consideration is that the external protocols (those shown as entering or leaving the big box in Figure 1) must be appropriately secured. This security will include authentication and authorization to control access to the different functions that the ABNO system can perform, to enable different policies based on identity, and to manage the control of the network devices.
最初の考慮事項は、外部プロトコル（図1で大きなボックスに出入りするもの）を適切に保護する必要があることです。このセキュリティには、ABNOシステムが実行できるさまざまな機能へのアクセスを制御し、IDに基づいてさまざまなポリシーを有効にし、ネットワークデバイスの制御を管理するための認証と承認が含まれます。
Secondly, the internal protocols that are used between ABNO components must also have appropriate security, particularly when the components are implemented on separate network nodes.
第2に、ABNOコンポーネント間で使用される内部プロトコルは、特にコンポーネントが個別のネットワークノードに実装されている場合は、適切なセキュリティも必要です。
Considering that the ABNO system contains a lot of data about the network, the services carried by the network, and the services delivered to customers, access to information held in the system must be carefully managed. Since such access will be largely through the external protocols, the policy-based controls enabled by authentication will be powerful. But it should also be noted that any data sent from the databases in the ABNO system can reveal details of the network and should, therefore, be considered as a candidate for encryption. Furthermore, since ABNO components can access the information stored in the database, care is required to ensure that all such components are genuine and to consider encrypting data that flows between components when they are implemented at remote nodes.
ABNOシステムには、ネットワーク、ネットワークによって運ばれるサービス、および顧客に提供されるサービスに関する多くのデータが含まれていることを考えると、システムに保持されている情報へのアクセスは慎重に管理する必要があります。このようなアクセスは主に外部プロトコルを介して行われるため、認証によって有効化されるポリシーベースの制御は強力になります。ただし、ABNOシステムのデータベースから送信されたデータはネットワークの詳細を明らかにする可能性があるため、暗号化の候補と見なす必要があることにも注意してください。さらに、ABNOコンポーネントはデータベースに格納されている情報にアクセスできるため、そのようなコンポーネントがすべて本物であることを確認し、コンポーネントがリモートノードに実装されるときにコンポーネント間を流れるデータを暗号化することを検討する必要があります。
The conclusion is that all protocols used to realize the ABNO architecture should have rich security features.
結論として、ABNOアーキテクチャを実現するために使用されるすべてのプロトコルは、豊富なセキュリティ機能を備えている必要があります。
The whole of the ABNO architecture is essentially about managing the network. In this respect, there is very little extra to say. ABNO provides a mechanism to gather and collate information about the network, reporting it to management applications, storing it for future inspection, and triggering actions according to configured policies.
ABNOアーキテクチャー全体は、基本的にネットワークの管理に関するものです。この点で、言うべき追加はほとんどありません。 ABNOは、ネットワークに関する情報を収集および照合し、管理アプリケーションに報告し、将来の検査のために保存し、構成されたポリシーに従ってアクションをトリガーするメカニズムを提供します。
The ABNO system will, itself, need monitoring and management. This can be seen as falling into several categories:
ABNOシステム自体は、監視と管理が必要です。これは、いくつかのカテゴリに分類されると見なすことができます。
- Management of external protocols
- 外部プロトコルの管理
- Management of internal protocols
- 内部プロトコルの管理
- Management and monitoring of ABNO components
- ABNOコンポーネントの管理と監視
- Configuration of policy to be applied across the ABNO system
- ABNOシステム全体に適用されるポリシーの構成
[BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, draft-ietf-idr-ls-distribution-10, January 2015.
[BGP-LS] Gredler、H.、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンク状態およびTE情報の北限定分布」、作業中、 draft-ietf-idr-ls-distribution-10、2015年1月。
[CSO-PCE] Dhody, D., Lee, Y., Contreras, LM., Gonzalez de Dios, O., and N. Ciulli, "Cross Stratum Optimization enabled Path Computation", Work in Progress, draft-dhody-pce-cso-enabled-path-computation-07, January 2015.
[CSO-PCE] Dhody、D.、Lee、Y.、Contreras、LM。、Gonzalez de Dios、O。、およびN. Ciulli、「クロス層最適化が有効なパス計算」、Work in Progress、draft-dhody-pce -cso-enabled-path-computation-07、2015年1月。
[EON] Gerstel, O., Jinno, M., Lord, A., and S.J.B. Yoo, "Elastic optical networking: a new dawn for the optical layer?", IEEE Communications Magazine, Volume 50, Issue 2, ISSN 0163-6804, February 2012.
[EON] Gerstel、O.、Jinno、M.、Lord、A.、S.J.B。 Yoo、「Elastic Optical Networking：a New Dawn for the Optical Layer？」、IEEE Communications Magazine、Volume 50、Issue 2、ISSN 0163-6804、February 2012。
[Flood] Project Floodlight, "Floodlight REST API", <http://www.projectfloodlight.org>.
[Flood]プロジェクトFloodlight、「Floodlight REST API」、<http://www.projectfloodlight.org>。
[G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", February 2012.
[G.694.1] ITU-T勧告G.694.1、「WDMアプリケーションのスペクトルグリッド：DWDM周波数グリッド」、2012年2月。
[G.709] ITU-T Recommendation G.709, "Interface for the optical transport network", February 2012.
[G.709] ITU-T勧告G.709、「光トランスポートネットワークのインターフェイス」、2012年2月。
[I2RS-Arch] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", Work in Progress, draft-ietf-i2rs-architecture-09, March 2015.
[I2RS-Arch] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「ルーティングシステムへのインターフェイスのアーキテクチャ」、作業中、draft-ietf- i2rs-architecture-09、2015年3月。
[I2RS-PS] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Interface to the Routing System Problem Statement", Work in Progress, draft-ietf-i2rs-problem-statement-06, January 2015.
[I2RS-PS] Atlas、A.、Ed。、Nadeau、T.、Ed。、and D. Ward、 "Interface to the Routing System Problem Statement"、Work in Progress、draft-ietf-i2rs-problem-statement- 2015年1月6日。
[ONF] Open Networking Foundation, "OpenFlow Switch Specification Version 1.4.0 (Wire Protocol 0x05)", October 2013.
[ONF] Open Networking Foundation、「OpenFlow Switch Specification Version 1.4.0（Wire Protocol 0x05）」、2013年10月。
[PCE-Init-LSP] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-03, March 2015.
[PCE-Init-LSP] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのPCEP拡張機能」、作業中、draft-ietf -pce-pce-initiated-lsp-03、2015年3月。
[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", Work in Progress, draft-ietf-netconf-restconf-04, January 2015.
[RESTCONF] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONF Protocol」、Work in Progress、draft-ietf-netconf-restconf-04、2015年1月。
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000, <http://www.rfc-editor.org/info/rfc2748>.
[RFC2748]ダーラム、D。、編、ボイル、J。、コーエン、R。、ヘルツォーク、S。、ラジャン、R。、およびA.サストリー、「COPS（Common Open Policy Service）Protocol」、RFC 2748 、2000年1月、<http://www.rfc-editor.org/info/rfc2748>。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000, <http://www.rfc-editor.org/info/rfc2753>.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「A Framework for Policy-based Admission Control」、RFC 2753、2000年1月、<http://www.rfc-editor.org/info/ rfc2753>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 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、12月2001、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002, <http://www.rfc-editor.org/info/rfc3292>.
[RFC3292] Doria、A.、Hellstrand、F.、Sundell、K。、およびT. Worster、「General Switch Management Protocol（GSMP）V3」、RFC 3292、2002年6月、<http：//www.rfc-editor .org / info / rfc3292>。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002, <http://www.rfc-editor.org/info/rfc3412>.
[RFC3412] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「メッセージ処理および簡易ネットワーク管理プロトコル（SNMP）のディスパッチ」、STD 62、RFC 3412、2002年12月、<http ：//www.rfc-editor.org/info/rfc3412>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 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、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, 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、2003年9月、<http://www.rfc-editor.org/ info / rfc3630>。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「Forwarding and Control Element Separation（ForCES）Framework」、RFC 3746、2004年4月、<http：//www.rfc- editor.org/info/rfc3746>。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。 .org / info / rfc3985>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, 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、2006年8月、<http：//www.rfc-editor .org / info / rfc4655>。
[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, 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、2008年2月、<http： //www.rfc-editor.org/info/rfc5150>。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008, <http://www.rfc-editor.org/info/rfc5212>.
[RFC5212]塩本K.、パパディミトリウD.、ルルーJL。、ビグールーM.、D。ブルガード、「GMPLSベースのマルチリージョンおよびマルチレイヤーネットワーク（MRN / MLN）の要件」、 RFC 5212、2008年7月、<http://www.rfc-editor.org/info/rfc5212>。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008, <http://www.rfc-editor.org/info/rfc5254>.
[RFC5254] Bitar、N.、Ed。、Bocci、M.、Ed。、and L. Martini、Ed。、 "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge（PWE3）"、RFC 5254、October 2008 、<http://www.rfc-editor.org/info/rfc5254>。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008, <http://www.rfc-editor.org/info/rfc5277>.
[RFC5277] Chisholm、S。およびH. Trevino、「NETCONFイベント通知」、RFC 5277、2008年7月、<http://www.rfc-editor.org/info/rfc5277>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305>。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008, <http://www.rfc-editor.org/info/rfc5394>.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「Policy-Enabled Path Computation Framework」、RFC 5394、2008年12月、<http://www.rfc-editor.org / info / rfc5394>。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424] Gerhards、R。、「The Syslog Protocol」、RFC 5424、2009年3月、<http://www.rfc-editor.org/info/rfc5424>。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux、Ed。、 "Path Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、March 2009、<http://www.rfc-editor.org/info/rfc5440>。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R.、Ed。、Vasseur、JP。、and A. Farrel、 "Preserving Topology Confidentiality in Inter-domain Path Computation Using a Path-Key-Based Mechanism"、RFC 5520、April 2009、<http： //www.rfc-editor.org/info/rfc5520>。
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5557] Lee、Y.、Le Roux、JL。、King、D。、およびE. Oki、「Path Computation Element Communication Protocol（PCEP）Requirements and Protocol Extensions Supporting Support for Global Concurrent Optimization」、RFC 5557、2009年7月、<http://www.rfc-editor.org/info/rfc5557>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖、E、武田、T。、ルルー、J.、A。ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、2009年9月、<http：/ /www.rfc-editor.org/info/rfc5623>。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、2009年10月、<http://www.rfc-editor.org/info/rfc5693>。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5810]ドリア、A。、編、ハディサリム、J。、編、ハース、R。、編、コスラビ、H。、編、王、W。、編、ドン、L。、ゴパル、R。、およびJ. Halpern、「Forwarding and Control Element Separation（ForCES）Protocol Specification」、RFC 5810、2010年3月、<http://www.rfc-editor.org/info/rfc5810>。
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, September 2010, <http://www.rfc-editor.org/info/rfc6007>.
[RFC6007] Nishioka、I. and D. King、 "Use of the Synchronization VECtor（SVEC）List for Synchronized Dependent Path Computations"、RFC 6007、2010年9月、<http://www.rfc-editor.org/info/ rfc6007>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、2010年10月、<http://www.rfc-editor.org/info/rfc6020 >。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, 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、February 2011、<http://www.rfc-editor.org/info / rfc6107>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月、<http://www.rfc-editor.org/info/rfc6120>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R.、Ed。、Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、and A. Bierman、Ed。、 "Network Configuration Protocol（NETCONF）"、RFC 6241、June 2011、 <http://www.rfc-editor.org/info/rfc6241>。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707] Niven-Jenkins、B.、Le Faucheur、F。、およびN. Bitar、「Content Distribution Network Interconnection（CDNI）Problem Statement」、RFC 6707、2012年9月、<http：//www.rfc-editor。 org / info / rfc6707>。
[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, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド、およびA.ファレル、エド、「MPLSおよびGMPLSにおけるドメインのシーケンスの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、2012年11月、<http ：//www.rfc-editor.org/info/rfc6805>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 2013年9月、<http://www.rfc-editor.org/info/rfc7011>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、エド。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、2014年9月、<http://www.rfc-editor.org/info/rfc7285>。
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, July 2014, <http://www.rfc-editor.org/info/rfc7297>.
[RFC7297] Boucadair、M.、Jacquenet、C。、およびN. Wang、「IP接続プロビジョニングプロファイル（CPP）」、RFC 7297、2014年7月、<http://www.rfc-editor.org/info/rfc7297 >。
[Stateful-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
[ステートフルPCE] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「ステートフルPCEのPCEP拡張機能」、作業中、draft-ietf-pce-stateful-pce-10、10月2014。
[TL1] Telcorida, "Operations Application Messages - Language For Operations Application Messages", GR-831, November 1996.
[TL1] Telcorida、「Operations Application Messages-Language for Operations Application Messages」、GR-831、1996年11月。
[TMF-MTOSI] TeleManagement Forum, "Multi-Technology Operations Systems Interface (MTOSI)", <https://www.tmforum.org/MTOSI/2319/home.html>.
[TMF-MTOSI] TeleManagement Forum、「Multi-Technology Operations Systems Interface（MTOSI）」、<https://www.tmforum.org/MTOSI/2319/home.html>。
[YANG-Rtg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", Work in Progress, draft-ietf-netmod-routing-cfg-17, March 2015.
[YANG-Rtg] Lhotka、L。およびA. Lindem、「ルーティング管理のためのYANGデータモデル」、作業中、draft-ietf-netmod-routing-cfg-17、2015年3月。
This appendix provides a brief list of interfaces that are not yet defined at the time of this writing. Interfaces where there is a choice of existing protocols are not listed.
この付録では、この記事の執筆時点でまだ定義されていないインターフェイスの簡単なリストを提供します。既存のプロトコルを選択できるインターフェースはリストされていません。
o An interface for adding additional information to the Traffic Engineering Database is described in Section 2.3.2.3. No protocol is currently identified for this interface, but candidates include:
o トラフィックエンジニアリングデータベースに追加情報を追加するためのインターフェースについては、セクション2.3.2.3で説明します。このインターフェイスのプロトコルは現在識別されていませんが、候補には次のものがあります。
- The protocol developed or adopted to satisfy the requirements of I2RS [I2RS-Arch]
- I2RSの要件を満たすために開発または採用されたプロトコル[I2RS-Arch]
- NETCONF [RFC6241]
- NETCONF [RFC6241]
o The protocol to be used by the Interface to the Routing System is described in Section 2.3.2.8. The I2RS working group has determined that this protocol will be based on a combination of NETCONF [RFC6241] and RESTCONF [RESTCONF] with further additions and modifications as deemed necessary to deliver the desired function. The details of the protocol are still to be determined.
o ルーティングシステムへのインターフェースで使用されるプロトコルについては、セクション2.3.2.8で説明します。 I2RSワーキンググループは、このプロトコルはNETCONF [RFC6241]とRESTCONF [RESTCONF]の組み合わせに基づいており、必要な機能を提供するために必要と思われる追加および変更を加えていると判断しました。プロトコルの詳細はまだ決定されていません。
o As described in Section 2.3.2.10, the Virtual Network Topology Manager needs an interface that can be used by a PCE or the ABNO Controller to inform it that a client layer needs more virtual topology. It is possible that the protocol identified for use with I2RS will satisfy this requirement, or this could be achieved using extensions to the PCEP Notify message (PCNtf).
o 2.3.2.10項で説明したように、Virtual Network Topology Managerには、PCEまたはABNOコントローラーがクライアントレイヤーにさらに多くの仮想トポロジが必要であることを通知するために使用できるインターフェースが必要です。 I2RSで使用するために識別されたプロトコルがこの要件を満たす可能性があります。または、これはPCEP通知メッセージ（PCNtf）の拡張機能を使用して実現できます。
o The north-bound interface from the ABNO Controller is used by the NMS, OSS, and Application Service Coordinator to request services in the network in support of applications as described in Section 2.3.2.11.
o ABNOコントローラーからのノースバウンドインターフェースは、セクション2.3.2.11で説明されているように、NMS、OSS、およびアプリケーションサービスコーディネーターによって使用され、アプリケーションをサポートするネットワーク内のサービスを要求します。
- It is possible that the protocol selected or designed to satisfy I2RS will address the requirement.
- I2RSを満たすように選択または設計されたプロトコルが要件に対処する可能性があります。
- A potential approach for this type of interface is described in [RFC7297] for a simple use case.
- このタイプのインターフェースの潜在的なアプローチは、単純な使用例として[RFC7297]で説明されています。
o As noted in Section 2.3.2.14, there may be layer-independent data models for offering common interfaces to control, configure, and report OAM.
o セクション2.3.2.14で述べたように、OAMを制御、構成、およびレポートするための共通のインターフェースを提供するために、レイヤーに依存しないデータモデルが存在する場合があります。
o As noted in Section 3.6, the ABNO model could be applied to placing multi-segment pseudowires in a network topology made up of S-PEs and MPLS tunnels. The current definition of PCEP [RFC5440] and associated extensions that are works in progress do not include all of the details to request such paths, so some work might be necessary, although the general concepts will be easily reusable. Indeed, such work may be necessary for the wider applicability of PCEs in many networking scenarios.
o セクション3.6で述べたように、ABNOモデルは、S-PEとMPLSトンネルで構成されるネットワークトポロジにマルチセグメント疑似配線を配置するために適用できます。現在進行中のPCEP [RFC5440]の定義と進行中の作業である関連拡張には、そのようなパスを要求するための詳細のすべてが含まれていないため、一般的な概念は簡単に再利用できますが、いくつかの作業が必要になる場合があります。実際、このような作業は、多くのネットワークシナリオでPCEをより広く適用するために必要になる場合があります。
Acknowledgements
謝辞
Thanks for discussions and review are due to Ken Gray, Jan Medved, Nitin Bahadur, Diego Caviglia, Joel Halpern, Brian Field, Ori Gerstel, Daniele Ceccarelli, Cyril Margaria, Jonathan Hardwick, Nico Wauters, Tom Taylor, Qin Wu, and Luis Contreras. Thanks to George Swallow for suggesting the existence of the SRLG database. Tomonori Takeda and Julien Meuric provided valuable comments as part of their Routing Directorate reviews. Tina Tsou provided comments as part of her Operational Directorate review.
ディスカッションとレビューに感謝するのは、ケングレイ、ヤンメドヴェッド、ニティンバハドゥール、ディエゴカビリア、ジョエルハルパーン、ブライアンフィールド、オリガーステル、ダニエレチェッカレリ、キリルマルガリア、ジョナサンハードウィック、ニコワウターズ、トムテイラー、キンウー、ルイスコントレラスによるものです。 。 SRLGデータベースの存在を提案してくれたGeorge Swallowに感謝します。武田友紀とジュリアン・ムーリックは、ルーティング総局のレビューの一部として貴重なコメントを提供しました。 Tina Tsouは、彼女の運用総局のレビューの一部としてコメントを提供しました。
This work received funding from the European Union's Seventh Framework Programme for research, technological development, and demonstration, through the PACE project under grant agreement number 619712 and through the IDEALIST project under grant agreement number 317999.
この作品は、研究、技術開発、および実証のための欧州連合の第7次フレームワークプログラムから、助成金契約番号619712に基づくPACEプロジェクトおよび助成金契約番号317999に基づくIDEALISTプロジェクトから資金を受け取りました。
Contributors
貢献者
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States EMail: qzhao@huawei.com
Quintin Zhao Huawei Technologies 125 Nagog Technology Parkアクトン、マサチューセッツ州01719アメリカ合衆国Eメール：qzhao@huawei.com
Victor Lopez Telefonica I+D EMail: vlopez@tid.es
Victor Lopez Telefonica I + Dメール：vlopez@tid.es
Ramon Casellas CTTC EMail: ramon.casellas@cttc.es
Ramon Casellas CTTCメール：ramon.casellas@cttc.es
Yuji Kamite NTT Communications Corporation EMail: y.kamite@ntt.com
UG Commit Nutt Communications Corporationメール：y.commit@nutet.com
Yosuke Tanaka NTT Communications Corporation EMail: yosuke.tanaka@ntt.com
よすけ たなか んっｔ こっむにかちおんｓ こｒぽらちおん えまいｌ： よすけ。たなか＠んっｔ。こｍ
Young Lee Huawei Technologies EMail: leeyoung@huawei.com
Young Lee Huawei Technologies EMail：leeyoung@huawei.com
Y. Richard Yang Yale University EMail: yry@cs.yale.edu
Y.リチャードヤンイェール大学Eメール：yry@cs.yale.edu
Authors' Addresses
著者のアドレス
Daniel King Old Dog Consulting
Daniel King Old Dog Consulting
EMail: daniel@olddog.co.uk
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
EMail: adrian@olddog.co.uk