[要約] RFC 7920は、ルーティングシステムへのインターフェースの問題を述べたものであり、その目的は、ネットワークの効率的なルーティングと管理を支援するための標準化を促進することです。
Internet Engineering Task Force (IETF) A. Atlas, Ed.
Request for Comments: 7920 Juniper Networks
Category: Informational T. Nadeau, Ed.
ISSN: 2070-1721 Brocade
D. Ward
Cisco Systems
June 2016
Problem Statement for the Interface to the Routing System
ルーティングシステムへのインターフェイスの問題ステートメント
Abstract
概要
Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.
従来、ルーティングシステムは、ルーティングとシグナリング（MPLSなど）を実装して、ネットワーク内のトラフィック転送を制御してきました。ルート計算は、リンクコスト、ルートコスト、またはインポートとエクスポートのルーティングポリシーを定義する比較的静的なポリシーによって制御されています。非常に動的なデータセンターネットワーキング、オンデマンドWANサービス、動的なポリシー駆動型のトラフィックステアリングとサービスチェーン、トラフィックを介したリアルタイムのセキュリティ脅威への対応の必要性の出現により、ルーティングシステムをより動的に管理およびプログラミングする要件が出現しました。制御、およびポリシーベースの意思決定をルータ自体から分離するパラダイム。これらの要件により、ルーティング情報とトラフィックパスを制御し、ルーティングシステムからネットワークトポロジ情報、トラフィック統計、およびその他のネットワーク分析を抽出できます。
This document proposes meeting this need via an Interface to the Routing System (I2RS).
このドキュメントでは、ルーティングシステム（I2RS）へのインターフェイスを介してこのニーズを満たすことを提案しています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7920.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7920で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. I2RS Model and Problem Area for the IETF ........................4
3. Standard Data Models of Routing State for Installation ..........6
4. Learning Router Information .....................................7
5. Aspects to be Considered for an I2RS Protocol ...................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Existing Management Interfaces .......................11
Acknowledgements ..................................................12
Authors' Addresses ................................................12
Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. The advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself has created the need to more dynamically manage and program routing systems in order to control routing information and traffic paths and to extract network topology information, traffic statistics, and other network analytics from routing systems.
従来、ルーティングシステムは、ルーティングとシグナリング（MPLSなど）を実装して、ネットワーク内のトラフィック転送を制御してきました。ルート計算は、リンクコスト、ルートコスト、またはインポートとエクスポートのルーティングポリシーを定義する比較的静的なポリシーによって制御されています。非常に動的なデータセンターネットワーキング、オンデマンドWANサービス、動的なポリシー主導のトラフィックステアリングとサービスチェーンの出現、トラフィック制御によるリアルタイムのセキュリティ脅威への対応の必要性、およびポリシーベースの意思決定を分離するパラダイムルーター自体から、ルーティング情報とトラフィックパスを制御し、ルーティングシステムからネットワークトポロジ情報、トラフィック統計、およびその他のネットワーク分析を抽出するために、ルーティングシステムをより動的に管理およびプログラミングする必要性が生じています。
As modern networks continue to grow in scale and complexity and desired policy has become more complex and dynamic, there is a need to support rapid control and analytics. The scale of modern networks and data centers and the associated operational expense drives the need to automate even the simplest operations. The ability to quickly interact via more complex operations to support dynamic policy is even more critical.
現代のネットワークの規模と複雑さが増し続け、望ましいポリシーがより複雑で動的になるにつれて、迅速な制御と分析をサポートする必要があります。最新のネットワークとデータセンターの規模、および関連する運用コストにより、最も単純な運用でさえも自動化する必要性が高まっています。より複雑な操作を介して迅速に対話して動的ポリシーをサポートする機能は、さらに重要です。
In order to enable network applications to have access to and control over information in the different vendors' routing systems, a publicly documented interface is required. The interface needs to support real-time, asynchronous interactions using efficient data models and encodings that are based on and extend those previously defined. Furthermore, the interface must be tailored to provide a solid base on which a variety of use cases can be supported.
ネットワークアプリケーションがさまざまなベンダーのルーティングシステム内の情報にアクセスして制御できるようにするには、公に文書化されたインターフェイスが必要です。インターフェイスは、以前に定義されたものに基づいて拡張した効率的なデータモデルとエンコーディングを使用して、リアルタイムの非同期相互作用をサポートする必要があります。さらに、さまざまなユースケースをサポートできる強固な基盤を提供するように、インターフェースを調整する必要があります。
To support the requirements of orchestration software and automated network applications to dynamically modify the network, there is a need to learn topology, network analytics, and existing state from the network as well as to create or modify routing information and network paths. A feedback loop is needed so that changes made can be verifiable and so that these applications can learn and react to network changes.
オーケストレーションソフトウェアと自動ネットワークアプリケーションがネットワークを動的に変更する要件をサポートするには、トポロジ、ネットワーク分析、およびネットワークからの既存の状態を学習し、ルーティング情報とネットワークパスを作成または変更する必要があります。フィードバックループは、加えられた変更を検証可能にし、これらのアプリケーションがネットワークの変更を学習してそれに対応できるようにするために必要です。
Proprietary solutions to partially support the requirements outlined above have been developed to handle specific situations and needs. Standardizing an interface to the routing system will make it easier to integrate use of it into a network. Because there are proprietary partial solutions already, the standardization of a common interface should be feasible.
上記の要件を部分的にサポートする独自のソリューションは、特定の状況とニーズに対応するために開発されました。ルーティングシステムへのインターフェイスを標準化すると、その使用をネットワークに統合しやすくなります。すでに独自の部分的なソリューションがあるため、共通のインターフェースの標準化は実現可能です。
It should be noted that during the course of this document, the term "applications" is used. This is meant to refer to an executable program of some sort that has access to a network, such as an IP or MPLS network, via a routing system.
このドキュメントでは、「アプリケーション」という用語が使用されていることに注意してください。これは、ルーティングシステムを介してIPネットワークやMPLSネットワークなどのネットワークにアクセスできるある種の実行可能プログラムを指すことを意味します。
Managing a network of systems running a variety of routing protocols and/or providing one or more additional services (e.g., forwarding, classification and policing, firewalling) involves interactions between multiple components within these systems. Some of these systems or system components may be virtualized, co-located within the same physical system, or distributed. In all cases, it is desirable to enable network applications to manage and control the services provided by many, if not all, of these components, subject to authenticated and authorized access and policies.
さまざまなルーティングプロトコルを実行しているシステムのネットワークを管理したり、1つ以上の追加サービス（転送、分類、ポリシング、ファイアウォールなど）を提供したりするには、これらのシステム内の複数のコンポーネント間の相互作用が必要です。これらのシステムまたはシステムコンポーネントの一部は、仮想化、同じ物理システム内の同じ場所に配置、または分散することができます。すべての場合において、認証および承認されたアクセスとポリシーに従って、これらのコンポーネントのすべてではないにしても多くによって提供されるサービスをネットワークアプリケーションが管理および制御できるようにすることが望ましいです。
A data-model-driven interface to the routing system is needed. This will allow expansion of what information can be read and controlled and allow for future flexibility. At least one accompanying protocol with clearly defined operations is needed; the suitable protocol(s) can be identified and expanded to support the requirements of an Interface to the Routing System (I2RS). These solutions must be designed to facilitate rapid, isolated, secure, and dynamic changes to a device's routing system. These would facilitate wide-scale deployment of interoperable applications and routing systems.
ルーティングシステムへのデータモデル駆動型インターフェイスが必要です。これにより、どの情報を読み取って制御できるかを拡張でき、将来の柔軟性が可能になります。明確に定義された操作を伴う少なくとも1つの付随するプロトコルが必要です。ルーティングシステムへのインターフェース（I2RS）の要件をサポートするために、適切なプロトコルを特定および拡張できます。これらのソリューションは、デバイスのルーティングシステムへの迅速で隔離された安全な動的変更を容易にするように設計する必要があります。これらにより、相互運用可能なアプリケーションとルーティングシステムの大規模な展開が容易になります。
The I2RS model and problem area for IETF work is illustrated in Figure 1. This document uses terminology defined in [RFC7921]. The I2RS agent is associated with a routing element, which may or may not be co-located with a data plane. The I2RS client could be integrated in a network application or controlled and used by one or more separate network applications. For instance, an I2RS client could be provided by a network controller or a network orchestration system that provides a non-I2RS interface to network applications and an I2RS interface to I2RS agents on the systems being managed. The scope of the data models used by I2RS extends across the entire routing system and the selected protocol(s) for I2RS.
IETF作業のI2RSモデルと問題領域を図1に示します。このドキュメントでは、[RFC7921]で定義されている用語を使用しています。 I2RSエージェントはルーティング要素に関連付けられています。ルーティング要素は、データプレーンと同じ場所にある場合とない場合があります。 I2RSクライアントは、ネットワークアプリケーションに統合することも、1つ以上の個別のネットワークアプリケーションで制御および使用することもできます。たとえば、I2RSクライアントは、ネットワークコントローラーまたはネットワークオーケストレーションシステムによって提供され、ネットワークアプリケーションに非I2RSインターフェイスを提供し、管理対象システム上のI2RSエージェントにI2RSインターフェイスを提供します。 I2RSで使用されるデータモデルの範囲は、ルーティングシステム全体と、I2RS用に選択されたプロトコルにまで及びます。
As depicted in Figure 1, the I2RS client and I2RS agent in a routing system are objects with in the I2RS scope. The selected protocol(s) for I2RS extend between the I2RS client and I2RS agent. All other objects and interfaces in Figure 1 are outside the I2RS scope for standardization.
図1に示すように、ルーティングシステムのI2RSクライアントとI2RSエージェントは、I2RSスコープ内のオブジェクトです。 I2RS用に選択されたプロトコルは、I2RSクライアントとI2RSエージェント間で拡張されます。図1の他のすべてのオブジェクトとインターフェイスは、標準化のためにI2RSの範囲外です。
+***************+ +***************+ +***************+
* Application * * Application * * Application *
+***************+ +***************+ +***************+
| I2RS Client | ^ ^
+---------------+ * *
^ * ****************
| * *
| v v
| +---------------+ +-------------+
| | I2RS Client |<------->| Other I2RS |
| +---------------+ | Agents |
| ^ +-------------+
|________________ |
| | <== I2RS Protocol
| |
...........................|..|..................................
. v v .
. +*************+ +---------------+ +****************+ .
. * Policy * | | * Routing & * .
. * Database *<***>| I2RS Agent |<****>* Signaling * .
. +*************+ | | * Protocols * .
. +---------------+ +****************+ .
. ^ ^ ^ ^ .
. +*************+ * * * * .
. * Topology * * * * * .
. * Database *<*******+ * * v .
. +*************+ * * +****************+ .
. * +********>* RIB Manager * .
. * +****************+ .
. * ^ .
. v * .
. +*******************+ * .
. * Subscription & * * .
. * Configuration * v .
. * Templates for * +****************+ .
. * Measurements, * * FIB Manager * .
. * Events, QoS, etc. * * & Data Plane * .
. +*******************+ +****************+ .
.................................................................
<--> interfaces inside the scope of I2RS Protocol
<-> I2RSプロトコルのスコープ内のインターフェース
+--+ objects inside the scope of I2RS-defined behavior
<**> interfaces NOT within the scope of I2RS Protocol
+**+ objects NOT within the scope of I2RS-defined behavior
<== used to point to the interface where the I2RS Protocol would be used
<== I2RSプロトコルが使用されるインターフェースを指すために使用されます
.... boundary of a router supporting I2RS
Figure 1: I2RS Model and Problem Area
図1：I2RSモデルと問題領域
The protocol(s) used to carry messages between I2RS clients and I2RS agents should provide the key features specified in Section 5.
I2RSクライアントとI2RSエージェント間でメッセージを伝送するために使用されるプロトコルは、セクション5で指定された主要な機能を提供する必要があります。
I2RS will use a set of meaningful data models for information in the routing system and in a topology database. Each data model should describe the meaning and relationships of the modeled items. The data models should be separable across different features of the managed components, versioned, and extendable. As shown in Figure 1, I2RS needs to interact with several logical components of the routing element: policy database, topology database, subscription and configuration for dynamic measurements/events, routing and signaling protocols, and its Routing Information Base (RIB) manager. This interaction is both for writing (e.g., to policy databases or RIB manager) as well as for reading (e.g., dynamic measurement or topology database). An application should be able to combine data from individual routing elements to provide network-wide data model(s).
I2RSは、ルーティングシステム内およびトポロジデータベース内の情報に一連の意味のあるデータモデルを使用します。各データモデルは、モデル化されたアイテムの意味と関係を記述する必要があります。データモデルは、管理対象コンポーネントのさまざまな機能間で分離可能で、バージョン管理され、拡張可能である必要があります。図1に示すように、I2RSはルーティング要素のいくつかの論理コンポーネント（ポリシーデータベース、トポロジデータベース、動的測定/イベントのサブスクリプションと構成、ルーティングとシグナリングプロトコル、およびそのルーティング情報ベース（RIB）マネージャー）と対話する必要があります。この対話は、書き込み（ポリシーデータベースやRIBマネージャーなど）と読み取り（動的測定データベースやトポロジデータベースなど）の両方を対象としています。アプリケーションは、個々のルーティング要素からのデータを組み合わせて、ネットワーク全体のデータモデルを提供できる必要があります。
The data models should translate into a concise transfer syntax, sent via the I2RS protocol, that is straightforward for applications to use (e.g., a web services design paradigm). The information transfer should use existing transport protocols to provide the reliability, security, and timeliness appropriate for the particular data.
データモデルは、I2RSプロトコルを介して送信される簡潔な転送構文に変換する必要があります。これは、アプリケーションで使用するのが簡単です（たとえば、Webサービス設計パラダイム）。情報の転送では、既存の転送プロトコルを使用して、特定のデータに適した信頼性、セキュリティ、適時性を提供する必要があります。
As described in Section 1, there is a need to be able to precisely control routing and signaling state based upon policy or external measures. One set of data models that I2RS should focus on is for interacting with the RIB layer (e.g., RIB, Label Information Base (LIB), multicast RIB, policy-based routing) to provide flexibility and routing abstractions. As an example, the desired routing and signaling state might range from simple static routes to policy-based routing to static multicast replication and routing state. This means that, to usefully model next hops, the data model employed needs to handle next-hop indirection and recursion (e.g., a prefix X is routed like prefix Y) as well as different types of tunneling and encapsulation.
セクション1で説明したように、ポリシーや外部測定に基づいてルーティングとシグナリングの状態を正確に制御できる必要があります。 I2RSが焦点を当てるべきデータセットの1つは、RIBレイヤー（RIB、ラベル情報ベース（LIB）、マルチキャストRIB、ポリシーベースルーティングなど）と対話して、柔軟性とルーティングの抽象化を提供することです。例として、必要なルーティングとシグナリングの状態は、単純な静的ルートからポリシーベースのルーティング、静的なマルチキャストレプリケーションとルーティング状態までさまざまです。つまり、ネクストホップを効果的にモデル化するには、採用されているデータモデルがネクストホップの間接化と再帰（たとえば、プレフィックスXがプレフィックスYのようにルーティングされる）だけでなく、さまざまな種類のトンネリングとカプセル化を処理する必要があります。
Efforts to provide this level of control have focused on standardizing data models that describe the forwarding plane (e.g., Forwarding and Control Element Separation (ForCES) [RFC3746]). I2RS recognizes that the routing system and a router's OS provide useful mechanisms that applications could usefully harness to accomplish application-level goals. Using routing indirection, recursion, and common routing abstractions (e.g., tunnels, Label Switched Paths (LSPs), etc.) provides significant flexibility and functionality over collapsing the state to individual routes in the Forwarding Information Base (FIB) that need to be individually modified when a change occurs.
このレベルの制御を提供する取り組みは、フォワーディングプレーンを説明するデータモデルの標準化に重点を置いています（たとえば、Forwarding and Control Element Separation（ForCES）[RFC3746]）。 I2RSは、ルーティングシステムとルーターのOSが、アプリケーションレベルの目標を達成するためにアプリケーションが有効に活用できる有用なメカニズムを提供することを認識しています。ルーティングの間接化、再帰、および一般的なルーティングの抽象化（たとえば、トンネル、ラベルスイッチドパス（LSP）など）を使用すると、個別に行う必要がある転送情報ベース（FIB）の個々のルートに状態を折りたたむよりも、かなりの柔軟性と機能が提供されます。変更が発生すると変更されます。
In addition to interfaces to control the RIB layer, there is a need to dynamically configure policies and parameter values for the various routing and signaling protocols based upon application-level policy decisions.
RIB層を制御するためのインターフェイスに加えて、アプリケーションレベルのポリシー決定に基づいて、さまざまなルーティングおよびシグナリングプロトコルのポリシーとパラメーター値を動的に構成する必要があります。
A router has information that applications may require so that they can understand the network, verify that programmed state is installed, measure the behavior of various flows, and understand the existing configuration and state of the router. I2RS should provide a framework so that applications can register for asynchronous notifications and can make specific requests for information.
ルーターには、アプリケーションがネットワークを理解し、プログラムされた状態がインストールされていることを確認し、さまざまなフローの動作を測定し、ルーターの既存の構成と状態を理解するために必要な情報があります。 I2RSは、アプリケーションが非同期通知に登録し、特定の情報を要求できるように、フレームワークを提供する必要があります。
Although there are efforts to extend the topological information available, even the best of these (e.g., BGP-LS [RFC7752]) still only provide the current active state as seen at the IGP and BGP layers. Detailed topological state that provides more information than the current functional status (e.g., active paths and links) is needed by applications. Examples of missing information include paths or links that are potentially available (e.g., administratively down) or unknown (e.g., to peers or customers) to the routing topology.
利用可能なトポロジー情報を拡張する取り組みがありますが、これらの最高のもの（BGP-LS [RFC7752]など）でも、IGPおよびBGPレイヤーで見られる現在のアクティブ状態のみを提供します。アプリケーションには、現在の機能状態（アクティブなパスやリンクなど）よりも多くの情報を提供する詳細なトポロジ状態が必要です。欠落している情報の例には、ルーティングトポロジで利用できる可能性がある（管理上のダウンなど）または不明な（たとえば、ピアや顧客にとって）パスまたはリンクが含まれます。
For applications to have a feedback loop that includes awareness of the relevant traffic, an application must be able to request the measurement and timely, scalable reporting of data. While a mechanism such as IP Flow Information Export (IPFIX) [RFC5470] may be the facilitator for delivering the data, providing the ability for an application to dynamically request that measurements be taken and data delivered is important.
アプリケーションが関連するトラフィックの認識を含むフィードバックループを持つためには、アプリケーションが測定とタイムリーでスケーラブルなデータのレポートを要求できる必要があります。 IPフロー情報エクスポート（IPFIX）[RFC5470]などのメカニズムは、データを配信するためのファシリテーターである場合がありますが、測定が行われ、データが配信されるようにアプリケーションに動的に要求する機能を提供することが重要です。
There is a wide range of events that applications could use to support verification of router state before other network state is changed (e.g., that a route has been installed) and to allow timely action in response to changes of relevant routes by others or to router events (e.g., link up/down). While a few of these (e.g., link up/down) may be available via MIB notifications today, the full range is not (e.g., route installed, route changed, primary LSP changed, etc.)
他のネットワーク状態が変更される前に（たとえば、ルートがインストールされているなど）、ルーターの状態の検証をサポートし、他のユーザーやルーターへの関連するルートの変更に応じてタイムリーなアクションを実行できるようにするために、アプリケーションが使用できる幅広いイベントがあります。イベント（リンクアップ/ダウンなど）。これらのいくつか（リンクアップ/ダウンなど）は、今日のMIB通知を介して利用できる可能性がありますが、全範囲は利用できません（たとえば、ルートのインストール、ルートの変更、プライマリLSPの変更など）。
This section describes required aspects of a protocol that could support I2RS. Whether such a protocol is built upon extending existing mechanisms or requires a new mechanism requires further investigation.
このセクションでは、I2RSをサポートできるプロトコルの必要な側面について説明します。このようなプロトコルが既存のメカニズムの拡張に基づいて構築されているか、新しいメカニズムが必要かどうかは、さらに調査する必要があります。
The key aspects needed in an interface to the routing system are:
ルーティングシステムへのインターフェイスに必要な主要な側面は次のとおりです。
Multiple Simultaneous Asynchronous Operations: A single application should be able to send multiple independent atomic operations via I2RS without being required to wait for each to complete before sending the next.
複数の同時非同期操作：単一のアプリケーションは、それぞれが完了するのを待ってから次の送信を行う前に、I2RSを介して複数の独立したアトミック操作を送信できる必要があります。
Very Fine Granularity of Data Locking for Writing: When an I2RS operation is processed, it is required that the data locked for writing be very granular (e.g., a particular prefix and route) rather than extremely coarse, as is done for writing configuration. This should improve the number of concurrent I2RS operations that are feasible and reduce blocking delays.
書き込み用のデータロックの非常に細かい単位：I2RS操作が処理されるとき、書き込み用にロックされたデータは、構成の書き込みで行われるような非常に粗いものではなく、非常に細かいもの（たとえば、特定のプレフィックスとルート）である必要があります。これにより、実行可能な同時I2RS操作の数が改善され、ブロッキングの遅延が減少します。
Multi-Headed Control: Multiple applications may communicate to the same I2RS agent in a minimally coordinated fashion. It is necessary that the I2RS agent can handle multiple requests in a well-known policy-based fashion. Data written can be owned by different I2RS clients at different times; data may even be overwritten by a different I2RS client. The details of how this should be handled are described in [RFC7921].
マルチヘッドコントロール：複数のアプリケーションが、最小限の調整で同じI2RSエージェントと通信できます。 I2RSエージェントが、よく知られているポリシーベースの方法で複数の要求を処理できる必要があります。書き込まれたデータは、さまざまな時点でさまざまなI2RSクライアントが所有できます。データは別のI2RSクライアントによって上書きされることもあります。これがどう扱われるべきかの詳細は[RFC7921]で説明されています。
Duplex: Communications can be established by either the I2RS client (i.e., that resides within the application or is used by it to communicate with the I2RS agent) or the I2RS agent. Similarly, events, acknowledgements, failures, operations, etc., can be sent at any time by both the router and the application. The I2RS is not a pure pull model where only the application queries to pull responses.
デュプレックス：通信は、I2RSクライアント（つまり、アプリケーション内に常駐するか、アプリケーションがI2RSエージェントとの通信に使用する）またはI2RSエージェントのいずれかによって確立できます。同様に、イベント、確認、障害、操作などは、ルーターとアプリケーションの両方からいつでも送信できます。 I2RSは、アプリケーションだけが応答をプルするクエリを実行する純粋なプルモデルではありません。
High Throughput: At a minimum, the I2RS agent and associated router should be able to handle a considerable number of operations per second (for example, 10,000 per second to handle many individual subscriber routes changing simultaneously).
高スループット：少なくとも、I2RSエージェントおよび関連するルーターは、1秒あたりかなりの数の操作を処理できる必要があります（たとえば、同時に変化する多くの個々のサブスクライバールートを処理するには、1秒あたり10,000）。
Low Latency: Within a sub-second timescale, it should be possible to complete simple operations (e.g., reading or writing a single prefix route).
低レイテンシ：1秒未満のタイムスケール内で、単純な操作（単一のプレフィックスルートの読み取りまたは書き込みなど）を完了することが可能である必要があります。
Multiple Channels: It should be possible for information to be communicated via the interface from different components in the router without requiring going through a single channel. For example, for scaling, some exported data or events may be better sent directly from the forwarding plane, while other interactions may come from the control plane. One channel, with authorization and authentication, may be considered primary; only an authorized client can then request that information be delivered on a different channel. Writes from a client are only expected on channels that provide authorization and authentication.
複数のチャネル：単一のチャネルを経由せずに、ルーターのさまざまなコンポーネントからインターフェイス経由で情報を通信できるようにする必要があります。たとえば、スケーリングの場合、一部のエクスポートされたデータまたはイベントは、転送プレーンから直接送信するほうがよい場合がありますが、他の相互作用はコントロールプレーンから送信される場合があります。許可と認証を備えた1つのチャネルがプライマリと見なされます。許可されたクライアントのみが、別のチャネルで情報を配信するよう要求できます。クライアントからの書き込みは、承認と認証を提供するチャネルでのみ期待されます。
Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs in an operation requesting data or requesting an asynchronous notification is very valuable.
スケーラブルでフィルター可能な情報アクセス：アプリケーションでより簡単に使用できるスケーラブルな方法で情報を抽出するには、データを要求する操作または非同期通知を要求する操作でフィルター構成を指定する機能が非常に役立ちます。
Secure Control and Access: Any ability to manipulate routing state must be subject to authentication and authorization. Sensitive routing information also may need to be provided via secure access back to the I2RS client. Such communications must be integrity protected. Most communications will also require confidentiality.
安全な制御とアクセス：ルーティング状態を操作する機能には、認証と承認が必要です。機密ルーティング情報は、I2RSクライアントへの安全なアクセスを介して提供する必要がある場合もあります。このような通信は完全性を保護する必要があります。ほとんどの通信では機密性も要求されます。
Extensibility and Interoperability: Both the I2RS protocol and models must be extensible and interoperate between different versions of protocols and models.
拡張性と相互運用性：I2RSプロトコルとモデルの両方が拡張可能で、プロトコルとモデルの異なるバージョン間で相互運用できる必要があります。
Security is a key aspect of any protocol that allows state installation and extracting of detailed router state. The need for secure control and access is mentioned in Section 5. More architectural security considerations are discussed in [RFC7921]. Briefly, the I2RS agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and the permissions associated with an I2RS client. Mutual authentication between the I2RS agent and I2RS client is required. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS.
セキュリティは、状態のインストールと詳細なルーター状態の抽出を可能にするプロトコルの重要な側面です。安全な制御とアクセスの必要性については、セクション5で説明しています。アーキテクチャのセキュリティに関するその他の考慮事項については、[RFC7921]で説明しています。簡単に言うと、I2RSエージェントは、I2RSクライアントに関連付けられたIDとアクセス許可の両方を検証できる個別の認証および承認チャネルを持っていると想定されています。 I2RSエージェントとI2RSクライアント間の相互認証が必要です。 I2RSのさまざまな側面には、さまざまなレベルの整合性、機密性、およびリプレイ保護が関連しています。
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://www.rfc-editor.org/info/rfc7921>.
[RFC7921] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「An Routing for the Interface to the Routing System」、RFC 7921、DOI 10.17487 / RFC7921、2016年6月、<http://www.rfc-editor.org/info/rfc7921>。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, 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、DOI 10.17487 / RFC3746、2004年4月、<http：/ /www.rfc-editor.org/info/rfc3746>。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, <http://www.rfc-editor.org/info/rfc5470>.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、DOI 10.17487 / RFC5470、2009年3月、<http：// www。 rfc-editor.org/info/rfc5470>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<http://www.rfc-editor.org/info/rfc7752>。
This section discusses as a single entity the combination of the abstract data models, their representation in a data language, and the transfer protocol commonly used with them. While other combinations of these existing standard technologies are possible, the ways described are ones that have significant deployment.
このセクションでは、1つのエンティティとして、抽象データモデルの組み合わせ、データ言語でのそれらの表現、およびそれらで一般的に使用される転送プロトコルについて説明します。これらの既存の標準テクノロジの他の組み合わせも可能ですが、説明されている方法は、重要な展開を伴うものです。
There are three basic ways that routers are managed. The most popular is the command-line interface (CLI), which allows both configuration and learning of device state. This is a proprietary interface resembling a UNIX shell that allows for very customized control and observation of a device, and, specifically of interest in this case, its routing system. Some form of this interface exists on almost every device (virtual or otherwise). Processing of information returned to the CLI (called "screen scraping") is a burdensome activity because the data is normally formatted for use by a human operator and because the layout of the data can vary from device to device and between different software versions. Despite its ubiquity, this interface has never been standardized and is unlikely to ever be standardized. CLI standardization is not considered as a candidate solution for the problems motivating I2RS.
ルーターを管理する基本的な方法は3つあります。最も人気のあるのは、デバイスの状態の構成と学習の両方を可能にするコマンドラインインターフェイス（CLI）です。これは、デバイスの非常にカスタマイズされた制御と監視を可能にするUNIXシェルに似た独自のインターフェイスであり、特にこの場合に重要なのはルーティングシステムです。このインターフェイスの一部の形式は、ほとんどすべてのデバイス（仮想またはその他）に存在します。 CLIに返される情報の処理（「画面スクレイピング」と呼ばれます）は、データが通常は人間のオペレーターが使用するためにフォーマットされ、データのレイアウトがデバイスごとに、また異なるソフトウェアバージョン間で異なるため、厄介なアクティビティです。ユビキタスにもかかわらず、このインターフェイスは標準化されたことはなく、標準化される可能性はほとんどありません。 CLIの標準化は、I2RSを動機付ける問題の候補ソリューションとは見なされません。
The second most popular interface for interrogation of a device's state, statistics, and configuration is the Simple Network Management Protocol (SNMP) and a set of relevant standards-based and proprietary Management Information Base (MIB) modules. SNMP has a strong history of being used by network managers to gather statistical and state information about devices, including their routing systems. However, SNMP is very rarely used to configure a device or any of its systems for reasons that vary depending upon the network operator. Some example reasons include complexity, the lack of desired configuration semantics (e.g., configuration rollback, sandboxing, or configuration versioning) and the difficulty of using the semantics (or lack thereof) as defined in the MIB modules to configure device features. Therefore, SNMP is not considered as a candidate solution for the problems motivating I2RS.
デバイスの状態、統計、構成の問い合わせに使用される2番目に人気のあるインターフェースは、シンプルネットワーク管理プロトコル（SNMP）と、関連する標準ベースの独自の管理情報ベース（MIB）モジュールのセットです。 SNMPには、ネットワーク管理者がルーティングシステムを含むデバイスに関する統計情報や状態情報を収集するために使用されてきた強い歴史があります。ただし、SNMPは、ネットワークオペレーターによって異なる理由により、デバイスまたはそのシステムの構成に使用されることはほとんどありません。いくつかの例の理由には、複雑さ、必要な構成セマンティクスの欠如（構成のロールバック、サンドボックス化、構成のバージョン管理など）、およびデバイスの機能を構成するためのMIBモジュールで定義されているセマンティクスの使用の困難さ（またはその欠如）が含まれます。したがって、SNMPはI2RSを動機付ける問題の候補ソリューションとは見なされません。
Finally, the IETF's Network Configuration Protocol (NETCONF) [RFC6241] has made many strides at overcoming most of the limitations around configuration that were just described. However, as a new technology and with the initial lack of standard data models, the adoption of NETCONF has been slow. As needed, I2RS will identify and define information and data models to support I2RS applications. Additional extensions to handle multi-headed control may need to be added to NETCONF and/or appropriate data models.
最後に、IETFのネットワーク構成プロトコル（NETCONF）[RFC6241]は、説明したばかりの構成に関するほとんどの制限を克服するために多くの進歩を遂げました。ただし、新しいテクノロジーとして、最初は標準データモデルが不足していたため、NETCONFの採用は遅れていました。必要に応じて、I2RSはI2RSアプリケーションをサポートするための情報とデータモデルを識別および定義します。マルチヘッドコントロールを処理する追加の拡張機能をNETCONFや適切なデータモデルに追加する必要がある場合があります。
Acknowledgements
謝辞
The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah Brungard, and Sarah Banks for their suggestions and review.
著者は、ケン・グレイ、エド・クラブ、ニック・レイマン、カルロス・ピグナタロ、クワンクグ・リー、リンダ・ダンバー、スー・ヘアス、ラス・ハスリー、エリック・グレイ、キン・ウー、スティーブン・ケント、ナビル・ビター、デボラ・ブルガード、サラ・バンクスに感謝します彼らの提案とレビューのために。
Authors' Addresses
著者のアドレス
Alia Atlas (editor) Juniper Networks
Alia Atlas（編集者）ジュニパーネットワークス
Email: akatlas@juniper.net
Thomas D. Nadeau (editor) Brocade
トーマスD.ナドー（編集者）ブロケード
Email: tnadeau@lucidvision.com
Dave Ward Cisco Systems
Dave Ward Cisco Systems
Email: wardd@cisco.com