[要約] 要約：RFC 7921は、ルーティングシステムへのインターフェースのアーキテクチャに関するガイドラインを提供しています。 目的：このRFCの目的は、異なるネットワークデバイスやプロトコル間の統一されたインターフェースを定義し、効率的なルーティングシステムの設計と展開を促進することです。
Internet Engineering Task Force (IETF) A. Atlas
Request for Comments: 7921 Juniper Networks
Category: Informational J. Halpern
ISSN: 2070-1721 Ericsson
S. Hares
Huawei
D. Ward
Cisco Systems
T. Nadeau
Brocade
June 2016
An Architecture for the Interface to the Routing System
ルーティングシステムへのインターフェイスのアーキテクチャ
Abstract
概要
This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).
このドキュメントでは、インターネットルーティングシステムとの間で状態を転送するための標準的なプログラムインターフェイスのIETFアーキテクチャについて説明します。ルーティングシステムへのインターフェース（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/rfc7921.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7921で入手できます。
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 ....................................................4
1.1. Drivers for the I2RS Architecture ..........................5
1.2. Architectural Overview .....................................6
2. Terminology ....................................................11
3. Key Architectural Properties ...................................13
3.1. Simplicity ................................................13
3.2. Extensibility .............................................14
3.3. Model-Driven Programmatic Interfaces ......................14
4. Security Considerations ........................................15
4.1. Identity and Authentication ...............................17
4.2. Authorization .............................................18
4.3. Client Redundancy .........................................19
4.4. I2RS in Personal Devices ..................................19
5. Network Applications and I2RS Client ...........................19
5.1. Example Network Application: Topology Manager .............20
6. I2RS Agent Role and Functionality ..............................20
6.1. Relationship to Its Routing Element .......................20
6.2. I2RS State Storage ........................................21
6.2.1. I2RS Agent Failure .................................21
6.2.2. Starting and Ending ................................22
6.2.3. Reversion ..........................................23
6.3. Interactions with Local Configuration .....................23
6.3.1. Examples of Local Configuration vs. I2RS
Ephemeral Configuration ............................24
6.4. Routing Components and Associated I2RS Services ...........26
6.4.1. Routing and Label Information Bases ................28
6.4.2. IGPs, BGP, and Multicast Protocols .................28
6.4.3. MPLS ...............................................29
6.4.4. Policy and QoS Mechanisms ..........................29
6.4.5. Information Modeling, Device Variation, and
Information Relationships ..........................29
6.4.5.1. Managing Variation: Object
Classes/Types and Inheritance .............29
6.4.5.2. Managing Variation: Optionality ...........30
6.4.5.3. Managing Variation: Templating ............31
6.4.5.4. Object Relationships ......................31
6.4.5.4.1. Initialization .................31
6.4.5.4.2. Correlation Identification .....32
6.4.5.4.3. Object References ..............32
6.4.5.4.4. Active References ..............32
7. I2RS Client Agent Interface ....................................32
7.1. One Control and Data Exchange Protocol ....................32
7.2. Communication Channels ....................................33
7.3. Capability Negotiation ....................................33
7.4. Scope Policy Specifications ...............................34
7.5. Connectivity ..............................................34
7.6. Notifications .............................................35
7.7. Information Collection ....................................35
7.8. Multi-headed Control ......................................36
7.9. Transactions ..............................................36
8. Operational and Manageability Considerations ...................37
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................38
Acknowledgements ..................................................39
Authors' Addresses ................................................40
Routers that form the Internet routing infrastructure maintain state at various layers of detail and function. For example, a typical router maintains a Routing Information Base (RIB) and implements routing protocols such as OSPF, IS-IS, and BGP to exchange reachability information, topology information, protocol state, and other information about the state of the network with other routers.
インターネットルーティングインフラストラクチャを形成するルーターは、詳細および機能のさまざまなレイヤーで状態を維持します。たとえば、一般的なルーターはルーティング情報ベース（RIB）を維持し、OSPF、IS-IS、BGPなどのルーティングプロトコルを実装して、到達可能性情報、トポロジ情報、プロトコル状態、およびネットワークの状態に関するその他の情報を他の情報と交換します。ルーター。
Routers convert all of this information into forwarding entries, which are then used to forward packets and flows between network elements. The forwarding plane and the specified forwarding entries then contain active state information that describes the expected and observed operational behavior of the router and that is also needed by the network applications. Network-oriented applications require easy access to this information to learn the network topology, to verify that programmed state is installed in the forwarding plane, to measure the behavior of various flows, routes or forwarding entries, as well as to understand the configured and active states of the router. Network-oriented applications also require easy access to an interface, which will allow them to program and control state related to forwarding.
ルーターは、このすべての情報を転送エントリに変換します。転送エントリは、ネットワーク要素間でパケットとフローを転送するために使用されます。フォワーディングプレーンと指定されたフォワーディングエントリには、ルータの予想および観察された動作動作を説明し、ネットワークアプリケーションでも必要となるアクティブな状態情報が含まれます。ネットワーク指向のアプリケーションは、ネットワークトポロジを学習し、プログラムされた状態が転送プレーンにインストールされていることを確認し、さまざまなフロー、ルート、または転送エントリの動作を測定し、構成されたアクティブを理解するために、この情報に簡単にアクセスする必要があります。ルータの状態。また、ネットワーク指向のアプリケーションでは、インターフェースに簡単にアクセスできる必要があります。これにより、アプリケーションは転送に関連する状態をプログラムおよび制御できます。
This document sets out an architecture for a common, standards-based interface to this information. This Interface to the Routing System (I2RS) facilitates control and observation of the routing-related state (for example, a Routing Element RIB manager's state), as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the Internet routing system. This I2RS architecture recognizes that the routing system and a router's Operating System (OS) provide useful mechanisms that applications could harness to accomplish application-level goals. These network-oriented applications can leverage the I2RS programmatic interface to create new ways to combine retrieving Internet routing data, analyzing this data, and setting state within routers.
このドキュメントでは、この情報に対する一般的な標準ベースのインターフェイスのアーキテクチャについて説明します。ルーティングシステム（I2RS）へのこのインターフェイスは、ルーティング関連の状態（たとえば、ルーティングエレメントRIBマネージャーの状態）の制御と監視を容易にし、ネットワーク指向のアプリケーションを今日のルーティングされたネットワークの上に構築できるようにします。 I2RSは、インターネットルーティングシステムとの間で状態を転送するためのプログラムによる非同期インターフェイスです。このI2RSアーキテクチャは、ルーティングシステムとルーターのオペレーティングシステム（OS）が、アプリケーションレベルの目標を達成するためにアプリケーションが利用できる有用なメカニズムを提供することを認識しています。これらのネットワーク指向のアプリケーションは、I2RSプログラムインターフェイスを利用して、インターネットルーティングデータの取得、このデータの分析、ルーター内の状態の設定を組み合わせる新しい方法を作成できます。
Fundamental to I2RS are clear data models that define the semantics of the information that can be written and read. I2RS provides a way for applications to customize network behavior while leveraging the existing routing system as desired. I2RS provides a framework for applications (including controller applications) to register and to request the appropriate information for each particular application.
I2RSの基礎となるのは、読み書き可能な情報のセマンティクスを定義する明確なデータモデルです。 I2RSは、既存のルーティングシステムを必要に応じて活用しながら、アプリケーションがネットワークの動作をカスタマイズする方法を提供します。 I2RSは、アプリケーション（コントローラーアプリケーションを含む）が特定のアプリケーションごとに適切な情報を登録および要求するためのフレームワークを提供します。
Although the I2RS architecture is general enough to support information and data models for a variety of data, and aspects of the I2RS solution may be useful in domains other than routing, I2RS and this document are specifically focused on an interface for routing data.
I2RSアーキテクチャは、さまざまなデータの情報とデータモデルをサポートするのに十分一般的であり、I2RSソリューションの側面はルーティング以外のドメインでも役立つ場合がありますが、I2RSとこのドキュメントは、ルーティングデータのインターフェイスに特に焦点を当てています。
Security is a concern for any new I2RS. Section 4 provides an overview of the security considerations for the I2RS architecture. The detailed requirements for I2RS protocol security are contained in [I2RS-PROT-SEC], and the detailed security requirements for environment in which the I2RS protocol exists are contained in [I2RS-ENV-SEC].
セキュリティは、新しいI2RSの懸念事項です。セクション4では、I2RSアーキテクチャのセキュリティに関する考慮事項の概要を示します。 I2RSプロトコルセキュリティの詳細な要件は[I2RS-PROT-SEC]に含まれており、I2RSプロトコルが存在する環境の詳細なセキュリティ要件は[I2RS-ENV-SEC]に含まれています。
There are four key drivers that shape the I2RS architecture. First is the need for an interface that is programmatic and asynchronous and that offers fast, interactive access for atomic operations. Second is the access to structured information and state that is frequently not directly configurable or modeled in existing implementations or configuration protocols. Third is the ability to subscribe to structured, filterable event notifications from the router. Fourth, the operation of I2RS is to be data-model-driven to facilitate extensibility and provide standard data models to be used by network applications.
I2RSアーキテクチャを形成する4つの主要なドライバーがあります。 1つ目は、プログラムおよび非同期で、アトミック操作に高速でインタラクティブなアクセスを提供するインターフェイスの必要性です。 2つ目は、既存の実装や構成プロトコルで直接構成したりモデル化したりできないことが多い、構造化された情報や状態へのアクセスです。 3つ目は、ルーターからの構造化されたフィルター可能なイベント通知をサブスクライブする機能です。第4に、I2RSの操作は、拡張性を促進し、ネットワークアプリケーションで使用される標準データモデルを提供するために、データモデル駆動型である必要があります。
I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [RFC7920].
I2RSは非同期プログラムインターフェースとして記述されており、その主要なプロパティは[RFC7920]のセクション5で説明されています。
The I2RS architecture facilitates obtaining information from the router. The I2RS architecture provides the ability to not only read specific information, but also to subscribe to targeted information streams, filtered events, and thresholded events.
I2RSアーキテクチャは、ルーターからの情報の取得を容易にします。 I2RSアーキテクチャは、特定の情報を読み取るだけでなく、対象となる情報ストリーム、フィルタリングされたイベント、およびしきい値付きイベントをサブスクライブする機能も提供します。
Such an interface also facilitates the injection of ephemeral state into the routing system. Ephemeral state on a router is the state that does not survive the reboot of a routing device or the reboot of the software handling the I2RS software on a routing device. A non-routing protocol or application could inject state into a routing element via the state-insertion functionality of I2RS and that state could then be distributed in a routing or signaling protocol and/or be used locally (e.g., to program the co-located forwarding plane). I2RS will only permit modification of state that would be possible to modify via Local Configuration; no direct manipulation of protocol-internal, dynamically determined data is envisioned.
そのようなインターフェースは、ルーティングシステムへの一時的な状態の注入も容易にします。ルーターのエフェメラル状態は、ルーティングデバイスの再起動、またはルーティングデバイス上のI2RSソフトウェアを処理するソフトウェアの再起動に耐えられない状態です。非ルーティングプロトコルまたはアプリケーションは、I2RSの状態挿入機能を介してルーティング要素に状態を挿入し、その状態をルーティングプロトコルまたはシグナリングプロトコルで配布したり、ローカルで使用したりできます（たとえば、同じ場所に配置するためにフォワーディングプレーン）。 I2RSは、ローカル構成を介して変更できる状態の変更のみを許可します。プロトコル内部で動的に決定されるデータを直接操作することは想定されていません。
Figure 1 shows the basic architecture for I2RS between applications using I2RS, their associated I2RS clients, and I2RS agents. Applications access I2RS services through I2RS clients. A single I2RS client can provide access to one or more applications. This figure also shows the types of data models associated with the routing system (dynamic configuration, static configuration, Local Configuration, and routing and signaling configuration) that the I2RS agent data models may access or augment.
図1は、I2RSを使用するアプリケーション、関連するI2RSクライアント、およびI2RSエージェント間のI2RSの基本アーキテクチャを示しています。アプリケーションは、I2RSクライアントを介してI2RSサービスにアクセスします。単一のI2RSクライアントが1つ以上のアプリケーションへのアクセスを提供できます。この図は、I2RSエージェントデータモデルがアクセスまたは拡張できるルーティングシステムに関連するデータモデルのタイプ（動的構成、静的構成、ローカル構成、ルーティングとシグナリング構成）も示しています。
Figure 1 is similar to Figure 1 in [RFC7920], but the figure in this document shows additional detail on how the applications utilize I2RS clients to interact with I2RS agents. It also shows a logical view of the data models associated with the routing system rather than a functional view (RIB, Forwarding Information Base (FIB), topology, policy, routing/signaling protocols, etc.)
図1は[RFC7920]の図1に似ていますが、このドキュメントの図は、アプリケーションがI2RSクライアントを利用してI2RSエージェントと対話する方法の詳細を示しています。また、機能ビュー（RIB、転送情報ベース（FIB）、トポロジー、ポリシー、ルーティング/シグナリングプロトコルなど）ではなく、ルーティングシステムに関連付けられたデータモデルの論理ビューも表示されます。
In Figure 1, Clients A and B each provide access to a single application (Applications A and B, respectively), while Client P provides access to multiple applications.
図1では、クライアントAおよびBはそれぞれ単一のアプリケーション（それぞれアプリケーションAおよびB）へのアクセスを提供し、クライアントPは複数のアプリケーションへのアクセスを提供します。
Applications can access I2RS services through local or remote clients. A local client operates on the same physical box as the routing system. In contrast, a remote client operates across the network. In the figure, Applications A and B access I2RS services through local clients, while Applications C, D, and E access I2RS services through a remote client. The details of how applications communicate with a remote client is out of scope for I2RS.
アプリケーションは、ローカルまたはリモートクライアントを介してI2RSサービスにアクセスできます。ローカルクライアントは、ルーティングシステムと同じ物理ボックスで動作します。対照的に、リモートクライアントはネットワーク全体で動作します。この図では、アプリケーションAおよびBはローカルクライアントを介してI2RSサービスにアクセスし、アプリケーションC、D、およびEはリモートクライアントを介してI2RSサービスにアクセスします。アプリケーションがリモートクライアントと通信する方法の詳細は、I2RSの範囲外です。
An I2RS client can access one or more I2RS agents. In Figure 1, Clients B and P access I2RS agents 1 and 2. Likewise, an I2RS agent can provide service to one or more clients. In this figure, I2RS agent 1 provides services to Clients A, B, and P while Agent 2 provides services to only Clients B and P.
I2RSクライアントは、1つ以上のI2RSエージェントにアクセスできます。図1では、クライアントBおよびPがI2RSエージェント1および2にアクセスします。同様に、I2RSエージェントは1つ以上のクライアントにサービスを提供できます。この図では、I2RSエージェント1はクライアントA、B、およびPにサービスを提供し、エージェント2はクライアントBおよびPのみにサービスを提供しています。
I2RS agents and clients communicate with one another using an asynchronous protocol. Therefore, a single client can post multiple simultaneous requests, either to a single agent or to multiple agents. Furthermore, an agent can process multiple requests, either from a single client or from multiple clients, simultaneously.
I2RSエージェントとクライアントは、非同期プロトコルを使用して相互に通信します。したがって、単一のクライアントは、単一のエージェントまたは複数のエージェントのいずれかに、複数の同時要求をポストできます。さらに、エージェントは、単一のクライアントまたは複数のクライアントからの複数の要求を同時に処理できます。
The I2RS agent provides read and write access to selected data on the routing element that are organized into I2RS services. Section 4 describes how access is mediated by authentication and access control mechanisms. Figure 1 shows I2RS agents being able to write ephemeral static state (e.g., RIB entries) and to read from dynamic static (e.g., MPLS Label Switched Path Identifier (LSP-ID) or number of active BGP peers).
I2RSエージェントは、I2RSサービスに編成されたルーティング要素上の選択されたデータへの読み取りおよび書き込みアクセスを提供します。セクション4では、アクセスが認証およびアクセス制御メカニズムによってどのように仲介されるかについて説明します。図1は、一時的な静的状態（RIBエントリなど）を書き込み、動的静的（MPLSラベルスイッチドパス識別子（LSP-ID）またはアクティブなBGPピアの数など）から読み取ることができるI2RSエージェントを示しています。
In addition to read and write access, the I2RS agent allows clients to subscribe to different types of notifications about events affecting different object instances. One example of a notification of such an event (which is unrelated to an object creation, modification or deletion) is when a next hop in the RIB is resolved in a way that allows it to be used by a RIB manager for installation in the forwarding plane as part of a particular route. Please see Sections 7.6 and 7.7 for details.
読み取りおよび書き込みアクセスに加えて、I2RSエージェントを使用すると、クライアントは、さまざまなオブジェクトインスタンスに影響を与えるイベントに関するさまざまなタイプの通知をサブスクライブできます。そのようなイベント（オブジェクトの作成、変更、または削除とは無関係）の通知の一例は、RIBマネージャーで転送のインストールに使用できるようにRIBのネクストホップが解決されたときです。特定のルートの一部としての飛行機。詳細については、セクション7.6および7.7を参照してください。
The scope of I2RS is to define the interactions between the I2RS agent and the I2RS client and the associated proper behavior of the I2RS agent and I2RS client.
I2RSの範囲は、I2RSエージェントとI2RSクライアント間の相互作用、およびI2RSエージェントとI2RSクライアントの関連する適切な動作を定義することです。
****************** ***************** *****************
* Application C * * Application D * * Application E *
****************** ***************** *****************
^ ^ ^
|--------------| | |--------------|
| | |
v v v
***************
* Client P *
***************
^ ^
| |-------------------------|
*********************** | *********************** |
* Application A * | * Application B * |
* * | * * |
* +----------------+ * | * +----------------+ * |
* | Client A | * | * | Client B | * |
* +----------------+ * | * +----------------+ * |
******* ^ ************* | ***** ^ ****** ^ ****** |
| | | | |
| |-------------| | | |-----|
| | -----------------------| | |
| | | | |
************ v * v * v ********* ***************** v * v ********
* +---------------------+ * * +---------------------+ *
* | Agent 1 | * * | Agent 2 | *
* +---------------------+ * * +---------------------+ *
* ^ ^ ^ ^ * * ^ ^ ^ ^ *
* | | | | * * | | | | *
* v | | v * * v | | v *
* +---------+ | | +--------+ * * +---------+ | | +--------+ *
* | Routing | | | | Local | * * | Routing | | | | Local | *
* | and | | | | Config | * * | and | | | | Config | *
* |Signaling| | | +--------+ * * |Signaling| | | +--------+ *
* +---------+ | | ^ * * +---------+ | | ^ *
* ^ | | | * * ^ | | | *
* | |----| | | * * | |----| | | *
* v | v v * * v | v v *
* +----------+ +------------+ * * +----------+ +------------+ *
* | Dynamic | | Static | * * | Dynamic | | Static | *
* | System | | System | * * | System | | System | *
* | State | | State | * * | State | | State | *
* +----------+ +------------+ * * +----------+ +------------+ *
* * * *
* Routing Element 1 * * Routing Element 2 *
******************************** ********************************
Figure 1: Architecture of I2RS Clients and Agents
図1：I2RSクライアントとエージェントのアーキテクチャ
Routing Element: A Routing Element implements some subset of the routing system. It does not need to have a forwarding plane associated with it. Examples of Routing Elements can include:
ルーティング要素：ルーティング要素は、ルーティングシステムのサブセットを実装します。フォワーディングプレーンを関連付ける必要はありません。ルーティング要素の例には次のものがあります。
* A router with a forwarding plane and RIB Manager that runs IS-IS, OSPF, BGP, PIM, etc.,
* IS-IS、OSPF、BGP、PIMなどを実行するフォワーディングプレーンとRIB Managerを備えたルータ、
* A BGP speaker acting as a Route Reflector,
* ルートリフレクターとして機能するBGPスピーカー、
* A Label Switching Router (LSR) that implements RSVP-TE, OSPF-TE, and the Path Computation Element (PCE) Communication Protocol (PCEP) and has a forwarding plane and associated RIB Manager, and
* RSVP-TE、OSPF-TE、およびパス計算エレメント（PCE）通信プロトコル（PCEP）を実装し、転送プレーンと関連するRIBマネージャーを持つラベルスイッチングルーター（LSR）、および
* A server that runs IS-IS, OSPF, and BGP and uses Forwarding and Control Element Separation (ForCES) to control a remote forwarding plane.
* IS-IS、OSPF、およびBGPを実行し、転送および制御要素分離（ForCES）を使用してリモート転送プレーンを制御するサーバー。
A Routing Element may be locally managed, whether via command-line interface (CLI), SNMP, or the Network Configuration Protocol (NETCONF).
ルーティング要素は、コマンドラインインターフェイス（CLI）、SNMP、またはネットワーク構成プロトコル（NETCONF）のいずれを介しても、ローカルで管理できます。
Routing and Signaling: This block represents that portion of the Routing Element that implements part of the Internet routing system. It includes not merely standardized protocols (i.e., IS-IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager layer.
ルーティングとシグナリング：このブロックは、インターネットルーティングシステムの一部を実装するルーティング要素の部分を表します。標準化されたプロトコル（IS-IS、OSPF、BGP、PIM、RSVP-TE、LDPなど）だけでなく、RIB Managerレイヤーも含まれます。
Local Configuration: The black box behavior for interactions between the ephemeral state that I2RS installs into the routing element; Local Configuration is defined by this document and the behaviors specified by the I2RS protocol.
ローカル構成：I2RSがルーティング要素にインストールする一時的な状態間の相互作用のブラックボックスの動作。ローカル構成は、このドキュメントとI2RSプロトコルで指定された動作によって定義されています。
Dynamic System State: An I2RS agent needs access to state on a routing element beyond what is contained in the routing subsystem. Such state may include various counters, statistics, flow data, and local events. This is the subset of operational state that is needed by network applications based on I2RS that is not contained in the routing and signaling information. How this information is provided to the I2RS agent is out of scope, but the standardized information and data models for what is exposed are part of I2RS.
動的システム状態：I2RSエージェントは、ルーティングサブシステムに含まれているものを超えてルーティング要素の状態にアクセスする必要があります。このような状態には、さまざまなカウンタ、統計、フローデータ、およびローカルイベントが含まれます。これは、ルーティングおよびシグナリング情報に含まれていないI2RSに基づくネットワークアプリケーションに必要な動作状態のサブセットです。この情報がI2RSエージェントに提供される方法は範囲外ですが、公開されるものの標準化された情報とデータモデルはI2RSの一部です。
Static System State: An I2RS agent needs access to static state on a routing element beyond what is contained in the routing subsystem. An example of such state is specifying queueing behavior for an interface or traffic. How the I2RS agent modifies or obtains this information is out of scope, but the standardized information and data models for what is exposed are part of I2RS.
静的システム状態：I2RSエージェントは、ルーティングサブシステムに含まれているものを超えて、ルーティング要素の静的状態にアクセスする必要があります。このような状態の例として、インターフェイスまたはトラフィックのキューイング動作の指定があります。 I2RSエージェントがこの情報を変更または取得する方法は範囲外ですが、公開されるものの標準化された情報とデータモデルはI2RSの一部です。
I2RS agent: See the definition in Section 2.
I2RSエージェント：セクション2の定義を参照してください。
Application: A network application that needs to observe the network or manipulate the network to achieve its service requirements.
アプリケーション：サービス要件を達成するためにネットワークを監視したり、ネットワークを操作したりする必要があるネットワークアプリケーション。
I2RS client: See the definition in Section 2.
I2RSクライアント：セクション2の定義を参照してください。
As can be seen in Figure 1, an I2RS client can communicate with multiple I2RS agents. Similarly, an I2RS agent may communicate with multiple I2RS clients -- whether to respond to their requests, to send notifications, etc. Timely notifications are critical so that several simultaneously operating applications have up-to-date information on the state of the network.
図1に示すように、I2RSクライアントは複数のI2RSエージェントと通信できます。同様に、I2RSエージェントは複数のI2RSクライアントと通信する可能性があります-要求に応答するかどうか、通知を送信するかどうかなど。同時に動作する複数のアプリケーションがネットワークの状態に関する最新の情報を得るには、タイムリーな通知が重要です。
As can also be seen in Figure 1, an I2RS agent may communicate with multiple clients. Each client may send the agent a variety of write operations. In order to keep the protocol simple, two clients should not attempt to write (modify) the same piece of information on an I2RS agent. This is considered an error. However, such collisions may happen and Section 7.8 ("Multi-headed Control") describes how the I2RS agent resolves collision by first utilizing priority to resolve collisions and second by servicing the requests in a first-in, first-served basis. The I2RS architecture includes this definition of behavior for this case simply for predictability, not because this is an intended result. This predictability will simplify error handling and suppress oscillations. If additional error cases beyond this simple treatment are required, these error cases should be resolved by the network applications and management systems.
図1にも示されているように、I2RSエージェントは複数のクライアントと通信できます。各クライアントは、エージェントにさまざまな書き込み操作を送信できます。プロトコルをシンプルに保つために、2つのクライアントはI2RSエージェントに同じ情報を書き込もう（変更）ことを試みるべきではありません。これはエラーと見なされます。ただし、このような衝突が発生する可能性があり、セクション7.8（「マルチヘッド制御」）では、I2RSエージェントが最初に衝突を解決するために優先度を使用して衝突を解決し、次に、先入れ先出しで要求を処理することによって衝突を解決する方法について説明します。 I2RSアーキテクチャには、このケースの動作の定義が含まれています。これは、意図した結果ではなく、単に予測可能にするためです。この予測可能性により、エラー処理が簡素化され、発振が抑制されます。この単純な処理を超える追加のエラーケースが必要な場合は、これらのエラーケースをネットワークアプリケーションと管理システムで解決する必要があります。
In contrast, although multiple I2RS clients may need to supply data into the same list (e.g., a prefix or filter list), this is not considered an error and must be correctly handled. The nuances so that writers do not normally collide should be handled in the information models.
対照的に、複数のI2RSクライアントが同じリスト（たとえば、プレフィックスまたはフィルターリスト）にデータを提供する必要がある場合でも、これはエラーとは見なされず、正しく処理する必要があります。ライターが通常衝突しないようにするためのニュアンスは、情報モデルで処理する必要があります。
The architectural goal for I2RS is that such errors should produce predictable behaviors and be reportable to interested clients. The details of the associated policy is discussed in Section 7.8. The same policy mechanism (simple priority per I2RS client) applies to interactions between the I2RS agent and the CLI/SNMP/NETCONF as described in Section 6.3.
I2RSのアーキテクチャ上の目標は、そのようなエラーが予測可能な動作を生成し、関心のあるクライアントに報告できることです。関連するポリシーの詳細については、セクション7.8で説明します。セクション6.3で説明されているように、同じポリシーメカニズム（I2RSクライアントごとの単純な優先度）がI2RSエージェントとCLI / SNMP / NETCONF間の相互作用に適用されます。
In addition, it must be noted that there may be indirect interactions between write operations. A basic example of this is when two different but overlapping prefixes are written with different forwarding behavior. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation.
さらに、書き込み操作の間に間接的な相互作用がある場合があることに注意する必要があります。この基本的な例は、2つの異なるが重複するプレフィックスが異なる転送動作で記述されている場合です。そのような相互作用の検出と回避は、I2RSの作業の範囲外であり、エージェントの設計と実装に任されています。
The following terminology is used in this document.
このドキュメントでは、次の用語が使用されています。
agent or I2RS agent: An I2RS agent provides the supported I2RS services from the local system's routing subsystems by interacting with the routing element to provide specified behavior. The I2RS agent understands the I2RS protocol and can be contacted by I2RS clients.
エージェントまたはI2RSエージェント：I2RSエージェントは、ルーティング要素と対話して指定された動作を提供することにより、ローカルシステムのルーティングサブシステムからサポートされているI2RSサービスを提供します。 I2RSエージェントはI2RSプロトコルを理解しており、I2RSクライアントからアクセスできます。
client or I2RS client: A client implements the I2RS protocol, uses it to communicate with I2RS agents, and uses the I2RS services to accomplish a task. It interacts with other elements of the policy, provisioning, and configuration system by means outside of the scope of the I2RS effort. It interacts with the I2RS agents to collect information from the routing and forwarding system. Based on the information and the policy-oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of their associated routing systems to achieve operational goals. An I2RS client can be seen as the part of an application that uses and supports I2RS and could be a software library.
クライアントまたはI2RSクライアント：クライアントはI2RSプロトコルを実装し、それを使用してI2RSエージェントと通信し、I2RSサービスを使用してタスクを実行します。 I2RSの取り組みの範囲外で、ポリシー、プロビジョニング、構成システムの他の要素とやり取りします。 I2RSエージェントと対話して、ルーティングおよび転送システムから情報を収集します。 I2RSクライアントは、情報とポリシー指向の対話に基づいて、I2RSエージェントと対話して、関連するルーティングシステムの状態を変更し、運用目標を達成することもできます。 I2RSクライアントは、I2RSを使用およびサポートするアプリケーションの一部と見なすことができ、ソフトウェアライブラリである可能性があります。
service or I2RS service: For the purposes of I2RS, a service refers to a set of related state access functions together with the policies that control their usage. The expectation is that a service will be represented by a data model. For instance, 'RIB service' could be an example of a service that gives access to state held in a device's RIB.
サービスまたはI2RSサービス：I2RSの目的で、サービスとは、関連する状態アクセス機能のセットと、その使用を制御するポリシーを指します。期待は、サービスがデータモデルによって表されることです。たとえば、「RIBサービス」は、デバイスのRIBに保持されている状態へのアクセスを提供するサービスの例です。
read scope: The read scope of an I2RS client within an I2RS agent is the set of information that the I2RS client is authorized to read within the I2RS agent. The read scope specifies the access restrictions to both see the existence of data and read the value of that data.
読み取りスコープ：I2RSエージェント内のI2RSクライアントの読み取りスコープは、I2RSクライアントがI2RSエージェント内で読み取ることを許可されている情報のセットです。読み取りスコープは、データの存在を確認し、そのデータの値を読み取るためのアクセス制限を指定します。
notification scope: The notification scope is the set of events and associated information that the I2RS client can request be pushed by the I2RS agent. I2RS clients have the ability to register for specific events and information streams, but must be constrained by the access restrictions associated with their notification scope.
通知スコープ：通知スコープは、I2RSクライアントがI2RSエージェントによってプッシュすることを要求できるイベントと関連情報のセットです。 I2RSクライアントは、特定のイベントと情報ストリームに登録することができますが、通知スコープに関連付けられたアクセス制限によって制約を受ける必要があります。
write scope: The write scope is the set of field values that the I2RS client is authorized to write (i.e., add, modify or delete). This access can restrict what data can be modified or created, and what specific value sets and ranges can be installed.
書き込みスコープ：書き込みスコープは、I2RSクライアントが書き込み（つまり、追加、変更、または削除）を許可されているフィールド値のセットです。このアクセスにより、変更または作成できるデータ、およびインストールできる特定の値セットと範囲を制限できます。
scope: When unspecified as either read scope, write scope, or notification scope, the term "scope" applies to the read scope, write scope, and notification scope.
スコープ：読み取りスコープ、書き込みスコープ、または通知スコープとして指定されていない場合、「スコープ」という用語は読み取りスコープ、書き込みスコープ、および通知スコープに適用されます。
resources: A resource is an I2RS-specific use of memory, storage, or execution that a client may consume due to its I2RS operations. The amount of each such resource that a client may consume in the context of a particular agent may be constrained based upon the client's security role. An example of such a resource could include the number of notifications registered for. These are not protocol-specific resources or network-specific resources.
リソース：リソースは、メモリ、ストレージ、または実行のI2RS固有の使用であり、I2RS操作が原因でクライアントが消費する可能性があります。クライアントが特定のエージェントのコンテキストで消費するそのような各リソースの量は、クライアントのセキュリティロールに基づいて制限される場合があります。そのようなリソースの例には、登録された通知の数を含めることができます。これらは、プロトコル固有のリソースやネットワーク固有のリソースではありません。
role or security role: A security role specifies the scope, resources, priorities, etc., that a client or agent has. If an identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role.
ロールまたはセキュリティロール：セキュリティロールは、クライアントまたはエージェントが持つスコープ、リソース、優先度などを指定します。 IDがセキュリティシステムで複数の役割を持っている場合、そのIDは、それらの役割のいずれかが許可する操作を実行することを許可されます。複数のIDが同じセキュリティロールを使用する場合があります。
identity: A client is associated with exactly one specific identity. State can be attributed to a particular identity. It is possible for multiple communication channels to use the same identity; in that case, the assumption is that the associated client is coordinating such communication.
identity：クライアントは、1つの特定のIDに関連付けられています。状態は特定のアイデンティティに起因する可能性があります。複数の通信チャネルが同じIDを使用する可能性があります。その場合、関連するクライアントがそのような通信を調整していると想定されます。
identity and scope: A single identity can be associated with multiple roles. Each role has its own scope, and an identity associated with multiple roles can use the combined scope of all its roles. More formally, each identity has:
IDとスコープ：単一のIDを複数のロールに関連付けることができます。各役割には独自のスコープがあり、複数の役割に関連付けられたIDは、そのすべての役割を組み合わせたスコープを使用できます。より正式には、各アイデンティティには次のものが含まれます。
* a read scope that is the logical OR of the read scopes associated with its roles,
* ロールに関連付けられた読み取りスコープの論理ORである読み取りスコープ
* a write scope that is the logical OR of the write scopes associated with its roles, and
* 役割に関連付けられた書き込みスコープの論理ORである書き込みスコープ
* a notification scope that is the logical OR of the notification scopes associated with its roles.
* 役割に関連付けられた通知スコープの論理ORである通知スコープ。
secondary identity: An I2RS client may supply a secondary opaque identifier for a secondary identity that is not interpreted by the I2RS agent. An example of the use of the secondary opaque identifier is when the I2RS client is a go-between for multiple applications and it is necessary to track which application has requested a particular operation.
セカンダリID：I2RSクライアントは、I2RSエージェントによって解釈されないセカンダリIDのセカンダリ不透明識別子を提供する場合があります。セカンダリ不透明識別子の使用例は、I2RSクライアントが複数のアプリケーションの中間にあり、どのアプリケーションが特定の操作を要求したかを追跡する必要がある場合です。
ephemeral data: Ephemeral data is data that does not persist across a reboot (software or hardware) or a power on/off condition. Ephemeral data can be configured data or data recorded from operations of the router. Ephemeral configuration data also has the property that a system cannot roll back to a previous ephemeral configuration state.
エフェメラルデータ：エフェメラルデータは、再起動（ソフトウェアまたはハードウェア）または電源のオン/オフの状態が続くと保持されないデータです。エフェメラルデータは、設定されたデータまたはルータの操作から記録されたデータです。エフェメラル構成データには、システムが以前のエフェメラル構成状態にロールバックできないという特性もあります。
group: The NETCONF Access Control Model [RFC6536] uses the term "group" in terms of an administrative group that supports the well-established distinction between a root account and other types of less-privileged conceptual user accounts. "Group" still refers to a single identity (e.g., root) that is shared by a group of users.
グループ：NETCONFアクセス制御モデル[RFC6536]では、ルートグループと他のタイプのより権限の少ない概念的なユーザーアカウントとの間の確立された区別をサポートする管理グループの観点から「グループ」という用語を使用します。 「グループ」は依然として、ユーザーのグループによって共有される単一のID（例：root）を指します。
routing system/subsystem: A routing system or subsystem is a set of software and/or hardware that determines where packets are forwarded. The I2RS agent is a component of a routing system. The term "packets" may be qualified to be layer 1 frames, layer 2 frames, or layer 3 packets. The phrase "Internet routing system" implies the packets that have IP as layer 3. A routing "subsystem" indicates that the routing software/hardware is only the subsystem of another larger system.
ルーティングシステム/サブシステム：ルーティングシステムまたはサブシステムは、パケットの転送先を決定するソフトウェアおよび/またはハードウェアのセットです。 I2RSエージェントはルーティングシステムのコンポーネントです。 「パケット」という用語は、レイヤー1フレーム、レイヤー2フレーム、またはレイヤー3パケットと見なすことができます。 「インターネットルーティングシステム」という語句は、レイヤ3としてIPを持つパケットを意味します。ルーティング「サブシステム」は、ルーティングソフトウェア/ハードウェアが別のより大きなシステムのサブシステムにすぎないことを示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Several key architectural properties for the I2RS protocol are elucidated below (simplicity, extensibility, and model-driven programmatic interfaces). However, some architectural properties such as performance and scaling are not described below because they are discussed in [RFC7920] and because they may vary based on the particular use cases.
I2RSプロトコルのいくつかの主要なアーキテクチャプロパティを以下に説明します（単純性、拡張性、およびモデル駆動型プログラムインターフェイス）。ただし、パフォーマンスやスケーリングなどの一部のアーキテクチャプロパティは、[RFC7920]で説明されているため、および特定のユースケースに基づいて異なる場合があるため、以下では説明しません。
There have been many efforts over the years to improve access to the information available to the routing and forwarding system. Making such information visible and usable to network management and applications has many well-understood benefits. There are two related challenges in doing so. First, the quantity and diversity of information potentially available is very large. Second, the variation both in the structure of the data and in the kinds of operations required tends to introduce protocol complexity.
ルーティングおよび転送システムで利用可能な情報へのアクセスを改善するために、長年にわたって多くの努力が払われてきました。このような情報をネットワーク管理やアプリケーションで表示して使用できるようにすることには、よく理解されている多くの利点があります。これには2つの関連する課題があります。まず、潜在的に利用可能な情報の量と多様性は非常に大きいです。第二に、データの構造と必要な操作の種類の両方の変化により、プロトコルが複雑になる傾向があります。
While the types of operations contemplated here are complex in their nature, it is critical that I2RS be easily deployable and robust. Adding complexity beyond what is needed to satisfy well known and understood requirements would hinder the ease of implementation, the robustness of the protocol, and the deployability of the protocol. Overly complex data models tend to ossify information sets by attempting to describe and close off every possible option, complicating extensibility.
ここで考えられる操作の種類は本質的に複雑ですが、I2RSを簡単に展開して堅牢にすることが重要です。よく知られ、理解されている要件を満たすために必要なものを超えて複雑さを追加すると、実装の容易さ、プロトコルの堅牢性、およびプロトコルの展開可能性が妨げられます。過度に複雑なデータモデルは、可能なオプションをすべて記述して閉じようとすることで情報セットを骨化し、拡張性を複雑にする傾向があります。
Thus, one of the key aims for I2RS is to keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves, "Do we need this complexity, or is the behavior merely nice to have?" If we need the complexity, we should ask ourselves, "Is this the simplest way to provide this complexity in the I2RS external interface?"
したがって、I2RSの主要な目的の1つは、プロトコルとモデリングアーキテクチャをシンプルに保つことです。したがって、各アーキテクチャコンポーネントまたはアスペクトについて、「この複雑さが必要なのか、それとも単にその振る舞いがいいのか」と自問しています。複雑さが必要な場合は、「これがI2RS外部インターフェイスでこの複雑さを実現する最も簡単な方法ですか？」と自問する必要があります。
Extensibility of the protocol and data model is very important. In particular, given the necessary scope limitations of the initial work, it is critical that the initial design include strong support for extensibility.
プロトコルとデータモデルの拡張性は非常に重要です。特に、初期の作業に必要な範囲の制限がある場合、初期の設計に拡張性を強力にサポートすることが重要です。
The scope of I2RS work is being designed in phases to provide deliverable and deployable results at every phase. Each phase will have a specific set of requirements, and the I2RS protocol and data models will progress toward these requirements. Therefore, it is clearly desirable for the I2RS data models to be easily and highly extensible to represent additional aspects of the network elements or network systems. It should be easy to integrate data models from I2RS with other data. This reinforces the criticality of designing the data models to be highly extensible, preferably in a regular and simple fashion.
I2RSの作業範囲は段階的に設計されており、すべての段階で成果物と展開可能な結果を提供します。各フェーズには特定の要件セットがあり、I2RSプロトコルとデータモデルはこれらの要件に向かって進みます。したがって、I2RSデータモデルは、ネットワーク要素またはネットワークシステムの追加の側面を表すために簡単かつ高度に拡張可能であることが明らかに望ましいです。 I2RSのデータモデルを他のデータと簡単に統合できるはずです。これにより、データモデルを非常に拡張可能に、できれば定期的かつ単純な方法で設計することの重要性が強化されます。
The I2RS Working Group is defining operations for the I2RS protocol. It would be optimistic to assume that more and different ones may not be needed when the scope of I2RS increases. Thus, it is important to consider extensibility not only of the underlying services' data models, but also of the primitives and protocol operations.
I2RSワーキンググループは、I2RSプロトコルの操作を定義しています。 I2RSのスコープが増加した場合、さらに多くの異なるものは必要ない可能性があると想定するのは楽観的です。したがって、基礎となるサービスのデータモデルだけでなく、プリミティブとプロトコル操作の拡張性を考慮することが重要です。
A critical component of I2RS is the standard information and data models with their associated semantics. While many components of the routing system are standardized, associated data models for them are not yet available. Instead, each router uses different information, different mechanisms, and different CLI, which makes a standard interface for use by applications extremely cumbersome to develop and maintain. Well-known data modeling languages exist and may be used for defining the data models for I2RS.
I2RSの重要なコンポーネントは、関連するセマンティクスを持つ標準情報とデータモデルです。ルーティングシステムの多くのコンポーネントは標準化されていますが、それらに関連するデータモデルはまだ利用できません。代わりに、各ルーターは異なる情報、異なるメカニズム、および異なるCLIを使用するため、アプリケーションが使用する標準インターフェイスは、開発および保守が非常に煩雑になります。よく知られているデータモデリング言語が存在し、I2RSのデータモデルの定義に使用できます。
There are several key benefits for I2RS in using model-driven architecture and protocol(s). First, it allows for data-model-focused processing of management data that provides modular implementation in I2RS clients and I2RS agents. The I2RS client only needs to implement the models the I2RS client is able to access. The I2RS agent only needs to implement the data models the I2RS agent supports.
I2RSには、モデル駆動型のアーキテクチャとプロトコルを使用することで、いくつかの重要な利点があります。まず、I2RSクライアントとI2RSエージェントでモジュール式の実装を提供する、管理データのデータモデルに焦点を合わせた処理が可能になります。 I2RSクライアントは、I2RSクライアントがアクセスできるモデルを実装するだけで済みます。 I2RSエージェントは、I2RSエージェントがサポートするデータモデルのみを実装する必要があります。
Second, tools can automate checking and manipulating data; this is particularly valuable for both extensibility and for the ability to easily manipulate and check proprietary data models.
次に、ツールはデータのチェックと操作を自動化できます。これは、拡張性と、プロプライエタリデータモデルを簡単に操作およびチェックする機能の両方にとって特に価値があります。
The different services provided by I2RS can correspond to separate data models. An I2RS agent may indicate which data models are supported.
I2RSによって提供されるさまざまなサービスは、個別のデータモデルに対応できます。 I2RSエージェントは、サポートされているデータモデルを示す場合があります。
The purpose of the data model is to provide a definition of the information regarding the routing system that can be used in operational networks. If routing information is being modeled for the first time, a logical information model may be standardized prior to creating the data model.
データモデルの目的は、運用ネットワークで使用できるルーティングシステムに関する情報の定義を提供することです。ルーティング情報が初めてモデル化される場合、データモデルを作成する前に論理情報モデルを標準化することができます。
This I2RS architecture describes interfaces that clearly require serious consideration of security. As an architecture, I2RS has been designed to reuse existing protocols that carry network management information. Two of the existing protocols that are being reused for the I2RS protocol version 1 are NETCONF [RFC6241] and RESTCONF [RESTCONF]. Additional protocols may be reused in future versions of the I2RS protocol.
このI2RSアーキテクチャは、セキュリティの真剣な考慮が明らかに必要なインターフェースを記述しています。 I2RSは、アーキテクチャとして、ネットワーク管理情報を運ぶ既存のプロトコルを再利用するように設計されています。 I2RSプロトコルバージョン1で再利用されている既存のプロトコルの2つは、NETCONF [RFC6241]とRESTCONF [RESTCONF]です。追加のプロトコルは、I2RSプロトコルの将来のバージョンで再利用される可能性があります。
The I2RS protocol design process will be to specify additional requirements (including security) for the existing protocols in order in order to support the I2RS architecture. After an existing protocol (e.g., NETCONF or RESTCONF) has been altered to fit the I2RS requirements, then it will be reviewed to determine if it meets these requirements. During this review of changes to existing protocols to serve the I2RS architecture, an in-depth security review of the revised protocol should be done.
I2RSプロトコル設計プロセスでは、I2RSアーキテクチャをサポートするために、既存のプロトコルの追加の要件（セキュリティを含む）を指定します。既存のプロトコル（NETCONFやRESTCONFなど）がI2RS要件に合わせて変更された後、これらの要件が満たされているかどうかを確認するためにレビューされます。 I2RSアーキテクチャを提供するための既存のプロトコルへの変更のこのレビュー中に、改訂されたプロトコルの詳細なセキュリティレビューを行う必要があります。
Due to the reuse strategy of the I2RS architecture, this security section describes the assumed security environment for I2RS with additional details on a) identity and authentication, b) authorization, and c) client redundancy. Each protocol proposed for inclusion as an I2RS protocol will need to be evaluated for the security constraints of the protocol. The detailed requirements for the I2RS protocol and the I2RS security environment will be defined within these global security environments.
I2RSアーキテクチャの再利用戦略により、このセキュリティセクションでは、I2RSの想定されるセキュリティ環境について、a）アイデンティティと認証、b）承認、c）クライアントの冗長性について詳しく説明します。 I2RSプロトコルとして含めるために提案された各プロトコルは、プロトコルのセキュリティ制約について評価する必要があります。 I2RSプロトコルとI2RSセキュリティ環境の詳細な要件は、これらのグローバルセキュリティ環境内で定義されます。
The I2RS protocol security requirements for I2RS protocol version 1 are contained in [I2RS-PROT-SEC], and the global I2RS security environment requirements are contained [I2RS-ENV-SEC].
I2RSプロトコルバージョン1のI2RSプロトコルセキュリティ要件は[I2RS-PROT-SEC]に含まれ、グローバルI2RSセキュリティ環境要件は[I2RS-ENV-SEC]に含まれています。
First, here is a brief description of the assumed security environment for I2RS. The I2RS agent associated with a Routing Element is a trusted part of that Routing Element. For example, it may be part of a vendor-distributed signed software image for the entire Routing Element, or it may be a trusted signed application that an operator has installed. The I2RS agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and permissions associated with an I2RS client. To support numerous and speedy interactions between the I2RS agent and I2RS client, it is assumed that the I2RS agent can also cache that particular I2RS clients are trusted and their associated authorized scope. This implies that the permission information may be old either in a pull model until the I2RS agent re-requests it or in a push model until the authentication and authorization channel can notify the I2RS agent of changes.
最初に、I2RSの想定されるセキュリティ環境について簡単に説明します。ルーティング要素に関連付けられたI2RSエージェントは、そのルーティング要素の信頼できる部分です。たとえば、ルーティング要素全体のベンダー配布の署名済みソフトウェアイメージの一部である場合や、オペレータがインストールした信頼できる署名済みアプリケーションである場合があります。 I2RSエージェントには、I2RSクライアントに関連付けられたIDとアクセス許可の両方を検証できる個別の認証および承認チャネルがあると想定されています。 I2RSエージェントとI2RSクライアント間の多数の高速な対話をサポートするために、I2RSエージェントは特定のI2RSクライアントが信頼されていること、および関連する承認されたスコープをキャッシュすることもできると想定されています。これは、I2RSエージェントが再要求するまでプルモデルで、または認証および承認チャネルがI2RSエージェントに変更を通知できるまでプッシュモデルで、許可情報が古い可能性があることを意味します。
Mutual authentication between the I2RS client and I2RS agent is required. An I2RS client must be able to trust that the I2RS agent is attached to the relevant Routing Element so that write/modify operations are correctly applied and so that information received from the I2RS agent can be trusted by the I2RS client.
I2RSクライアントとI2RSエージェント間の相互認証が必要です。 I2RSクライアントは、I2RSエージェントが関連するルーティング要素に接続されていることを信頼できる必要があります。これにより、書き込み/変更操作が正しく適用され、I2RSエージェントから受信した情報をI2RSクライアントが信頼できるようになります。
An I2RS client is not automatically trustworthy. Each I2RS client is associated with an identity with a set of scope limitations. Applications using an I2RS client should be aware that the scope limitations of an I2RS client are based on its identity (see Section 4.1) and the assigned role that the identity has. A role sets specific authorization limits on the actions that an I2RS client can successfully request of an I2RS agent (see Section 4.2). For example, one I2RS client may only be able to read a static route table, but another client may be able add an ephemeral route to the static route table.
I2RSクライアントは自動的に信頼できるわけではありません。各I2RSクライアントは、一連のスコープ制限を持つIDに関連付けられています。 I2RSクライアントを使用するアプリケーションは、I2RSクライアントのスコープ制限がそのID（セクション4.1を参照）とIDに割り当てられた役割に基づいていることに注意する必要があります。ロールは、I2RSクライアントがI2RSエージェントに正常にリクエストできるアクションに特定の認証制限を設定します（セクション4.2を参照）。たとえば、あるI2RSクライアントは静的ルートテーブルを読み取ることしかできないかもしれませんが、別のクライアントは静的ルートテーブルに一時的なルートを追加できるかもしれません。
If the I2RS client is acting as a broker for multiple applications, then managing the security, authentication, and authorization for that communication is out of scope; nothing prevents the broker from using the I2RS protocol and a separate authentication and authorization channel from being used. Regardless of the mechanism, an I2RS client that is acting as a broker is responsible for determining that applications using it are trusted and permitted to make the particular requests.
I2RSクライアントが複数のアプリケーションのブローカーとして機能している場合、その通信のセキュリティ、認証、および承認の管理は範囲外です。ブローカーがI2RSプロトコルを使用することを妨げるものはなく、個別の認証および承認チャネルが使用されることはありません。メカニズムに関係なく、ブローカーとして機能しているI2RSクライアントは、それを使用するアプリケーションが信頼され、特定の要求を行うことが許可されていることを確認する責任があります。
Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection. Appropriate selection of a default required transport protocol is the preferred way of meeting these requirements.
I2RSのさまざまな側面には、さまざまなレベルの整合性、機密性、およびリプレイ保護が関連しています。クライアント認証に使用され、クライアントがデータを書き込むために使用するプライマリ通信チャネルには、整合性、機密性、および再生保護が必要です。これらの要件を満たすには、デフォルトの必須トランスポートプロトコルを適切に選択することが推奨されます。
Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection. Similarly, an information stream of interface statistics may not even require guaranteed delivery. In Section 7.2, additional logins regarding multiple communication channels and their use is provided. From the security perspective, it is critical to realize that an I2RS agent may open a new communication channel based upon information provided by an I2RS client (as described in Section 7.2). For example, an I2RS client may request notifications of certain events, and the agent will open a communication channel to report such events. Therefore, to avoid an indirect attack, such a request must be done in the context of an authenticated and authorized client whose communications cannot have been altered.
I2RSを介したその他の通信では、整合性、機密性、およびリプレイ保護を必要としない場合があります。たとえば、I2RSクライアントがOSPFからのプレフィックスアナウンスの情報ストリームにサブスクライブする場合、それらには整合性が必要ですが、おそらく機密性や再生保護は必要ありません。同様に、インターフェース統計の情報ストリームは、保証された配信を必要としない場合もあります。セクション7.2では、複数の通信チャネルとその使用に関する追加のログインが提供されます。セキュリティの観点からは、I2RSエージェントがI2RSクライアントから提供された情報に基づいて新しい通信チャネルを開く可能性があることを理解することが重要です（セクション7.2で説明）。たとえば、I2RSクライアントは特定のイベントの通知を要求し、エージェントはそのようなイベントを報告するために通信チャネルを開きます。したがって、間接的な攻撃を回避するには、そのような要求は、通信が変更されていない可能性のある認証および承認されたクライアントのコンテキストで実行する必要があります。
As discussed above, all control exchanges between the I2RS client and agent should be authenticated and integrity-protected (such that the contents cannot be changed without detection). Further, manipulation of the system must be accurately attributable. In an ideal architecture, even information collection and notification should be protected; this may be subject to engineering trade-offs during the design.
上で説明したように、I2RSクライアントとエージェント間のすべての制御交換は、認証され、整合性が保護されている必要があります（検出なしにコンテンツを変更できないようにする）。さらに、システムの操作は正確に起因する必要があります。理想的なアーキテクチャでは、情報の収集と通知でさえ保護する必要があります。これは、設計時にエンジニアリングのトレードオフの影響を受ける可能性があります。
I2RS clients may be operating on behalf of other applications. While those applications' identities are not needed for authentication or authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations to an application identifier (and from that to the application's identity). This tracking of operations to an application supports I2RS functionality for tracing actions (to aid troubleshooting in routers) and logging of network changes.
I2RSクライアントが他のアプリケーションに代わって動作している可能性があります。これらのアプリケーションのIDは認証や承認には必要ありませんが、各アプリケーションには一意の不透明な識別子が必要です。この識別子は、I2RSクライアントからI2RSエージェントに提供され、アプリケーション識別子への操作の属性を追跡する目的で（およびそれからアプリケーションのID）。アプリケーションに対する操作のこの追跡は、アクションの追跡（ルーターでのトラブルシューティングを支援するため）およびネットワーク変更のログ記録のためのI2RS機能をサポートしています。
All operations using I2RS, both observation and manipulation, should be subject to appropriate authorization controls. Such authorization is based on the identity and assigned role of the I2RS client performing the operations and the I2RS agent in the network element. Multiple identities may use the same role(s). As noted in the definitions of "identity" and "role" above, if multiple roles are associated with an identity then the identity is authorized to perform any operation authorized by any of its roles.
I2RSを使用するすべての操作（監視と操作の両方）は、適切な承認制御の対象となる必要があります。このような許可は、操作を実行するI2RSクライアントとネットワーク要素のI2RSエージェントのIDと割り当てられた役割に基づいています。複数のIDが同じロールを使用する場合があります。上記の「ID」と「ロール」の定義で述べたように、IDに複数のロールが関連付けられている場合、IDは、そのロールのいずれかによって許可された操作を実行することを許可されます。
I2RS agents, in performing information collection and manipulation, will be acting on behalf of the I2RS clients. As such, each operation authorization will be based on the lower of the two permissions of the agent itself and of the authenticated client. The mechanism by which this authorization is applied within the device is outside of the scope of I2RS.
I2RSエージェントは、情報の収集と操作を行う際に、I2RSクライアントに代わって行動します。そのため、各操作の許可は、エージェント自体と認証済みクライアントの2つの許可のうちの低い方に基づいています。この認証がデバイス内で適用されるメカニズムは、I2RSの範囲外です。
The appropriate or necessary level of granularity for scope can depend upon the particular I2RS service and the implementation's granularity. An approach to a similar access control problem is defined in the NETCONF Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be specified for a data node instance identifier while defining meaningful manipulable defaults. The identity within NACM [RFC6536] can be specified as either a user name or a group user name (e.g., Root), and this name is linked a scope policy that is contained in a set of access control rules. Similarly, it is expected the I2RS identity links to one role that has a scope policy specified by a set of access control rules. This scope policy can be provided via Local Configuration, exposed as an I2RS service for manipulation by authorized clients, or via some other method (e.g., Authentication, Authorization, and Accounting (AAA) service)
スコープの適切または必要なレベルの細分性は、特定のI2RSサービスと実装の細分性に依存する可能性があります。同様のアクセス制御問題へのアプローチは、NETCONFアクセス制御モデル（NACM）[RFC6536]で定義されています。意味のある操作可能なデフォルトを定義しながら、データノードインスタンス識別子に任意のアクセスを指定できます。 NACM [RFC6536]内のIDは、ユーザー名またはグループユーザー名（Rootなど）のいずれかとして指定でき、この名前は、一連のアクセス制御規則に含まれるスコープポリシーにリンクされます。同様に、I2RS IDは、一連のアクセス制御ルールによって指定されたスコープポリシーを持つ1つのロールにリンクすることが期待されています。このスコープポリシーは、許可されたクライアントによる操作のためにI2RSサービスとして公開されたローカル構成を介して、またはその他の方法（認証、承認、およびアカウンティング（AAA）サービスなど）を介して提供できます。
While the I2RS agent allows access based on the I2RS client's scope policy, this does not mean the access is required to arrive on a particular transport connection or from a particular I2RS client by the I2RS architecture. The operator-applied scope policy may or may not restrict the transport connection or the identities that can access a local I2RS agent.
I2RSエージェントはI2RSクライアントのスコープポリシーに基づいてアクセスを許可しますが、これは、I2RSアーキテクチャによって特定のトランスポート接続または特定のI2RSクライアントから到達するためにアクセスが必要であることを意味しません。オペレーターが適用したスコープポリシーは、トランスポート接続またはローカルI2RSエージェントにアクセスできるIDを制限する場合としない場合があります。
When an I2RS client is authenticated, its identity is provided to the I2RS agent, and this identity links to a role that links to the scope policy. Multiple identities may belong to the same role; for example, such a role might be an Internal-Routes-Monitor that allows reading of the portion of the I2RS RIB associated with IP prefixes used for internal device addresses in the AS.
I2RSクライアントが認証されると、そのIDがI2RSエージェントに提供され、このIDはスコープポリシーにリンクするロールにリンクします。複数のIDが同じロールに属する場合があります。たとえば、そのような役割は、ASの内部デバイスアドレスに使用されるIPプレフィックスに関連付けられたI2RS RIBの部分の読み取りを許可する内部ルートモニターである場合があります。
I2RS must support client redundancy. At the simplest, this can be handled by having a primary and a backup network application that both use the same client identity and can successfully authenticate as such. Since I2RS does not require a continuous transport connection and supports multiple transport sessions, this can provide some basic redundancy. However, it does not address the need for troubleshooting and logging of network changes to be informed about which network application is actually active. At a minimum, basic transport information about each connection and time can be logged with the identity.
I2RSはクライアントの冗長性をサポートする必要があります。簡単に言えば、これは、同じクライアントIDを使用し、正常に認証できるプライマリおよびバックアップネットワークアプリケーションを持つことで処理できます。 I2RSは継続的なトランスポート接続を必要とせず、複数のトランスポートセッションをサポートするため、これにより基本的な冗長性が提供されます。ただし、どのネットワークアプリケーションが実際にアクティブであるかを通知するためのネットワーク変更のトラブルシューティングとロギングの必要性については触れていません。少なくとも、各接続と時間に関する基本的なトランスポート情報をIDで記録できます。
If an I2RS agent or I2RS client is tightly correlated with a person (such as if an I2RS agent is running on someone's phone to control tethering), then this usage can raise privacy issues, over and above the security issues that normally need to be handled in I2RS. One example of an I2RS interaction that could raise privacy issues is if the I2RS interaction enabled easier location tracking of a person's phone. The I2RS protocol and data models should consider if privacy issues can arise when clients or agents are used for such use cases.
I2RSエージェントまたはI2RSクライアントが人と密接に相関している場合（テザリングを制御するためにI2RSエージェントが誰かの電話で実行されている場合など）、この使用法は、通常処理する必要があるセキュリティ問題に加えて、プライバシーの問題を引き起こす可能性があります。 I2RSで。プライバシーの問題を引き起こす可能性のあるI2RSインタラクションの1つの例は、I2RSインタラクションが人の電話のより簡単な位置追跡を可能にした場合です。 I2RSプロトコルとデータモデルは、クライアントまたはエージェントがそのようなユースケースに使用されたときにプライバシーの問題が発生する可能性があるかどうかを検討する必要があります。
I2RS is expected to be used by network-oriented applications in different architectures. While the interface between a network-oriented application and the I2RS client is outside the scope of I2RS, considering the different architectures is important to sufficiently specify I2RS.
I2RSは、さまざまなアーキテクチャのネットワーク指向アプリケーションで使用されることが期待されています。ネットワーク指向のアプリケーションとI2RSクライアント間のインターフェイスはI2RSの範囲外ですが、I2RSを十分に指定するには、異なるアーキテクチャを検討することが重要です。
In the simplest architecture of direct access, a network-oriented application has an I2RS client as a library or driver for communication with routing elements.
直接アクセスの最も単純なアーキテクチャでは、ネットワーク指向のアプリケーションに、ルーティング要素との通信用のライブラリまたはドライバーとしてI2RSクライアントがあります。
In the broker architecture, multiple network-oriented applications communicate in an unspecified fashion to a broker application that contains an I2RS client. That broker application requires additional functionality for authentication and authorization of the network-oriented applications; such functionality is out of scope for I2RS, but similar considerations to those described in Section 4.2 do apply. As discussed in Section 4.1, the broker I2RS client should determine distinct opaque identifiers for each network-oriented application that is using it. The broker I2RS client can pass along the appropriate value as a secondary identifier, which can be used for tracking attribution of operations.
ブローカーアーキテクチャでは、複数のネットワーク指向のアプリケーションが、I2RSクライアントを含むブローカーアプリケーションと不特定の方法で通信します。そのブローカーアプリケーションには、ネットワーク指向アプリケーションの認証と承認のための追加機能が必要です。このような機能はI2RSの範囲外ですが、セクション4.2で説明されているものと同様の考慮事項が適用されます。セクション4.1で説明したように、ブローカーI2RSクライアントは、それを使用しているネットワーク指向のアプリケーションごとに異なる不透明な識別子を決定する必要があります。ブローカーのI2RSクライアントは、適切な値をセカンダリ識別子として渡すことができます。これは、操作の属性の追跡に使用できます。
In a third architecture, a routing element or network-oriented application that uses an I2RS client to access services on a different routing element may also contain an I2RS agent to provide services to other network-oriented applications. However, where the needed information and data models for those services differs from that of a conventional routing element, those models are, at least initially, out of scope for I2RS. The following section describes an example of such a network application.
3番目のアーキテクチャでは、I2RSクライアントを使用して別のルーティング要素のサービスにアクセスするルーティング要素またはネットワーク指向のアプリケーションに、他のネットワーク指向のアプリケーションにサービスを提供するI2RSエージェントが含まれている場合があります。ただし、これらのサービスに必要な情報とデータモデルが従来のルーティング要素のものと異なる場合、これらのモデルは、少なくとも最初はI2RSの範囲外です。次のセクションでは、このようなネットワークアプリケーションの例について説明します。
A Topology Manager includes an I2RS client that uses the I2RS data models and protocol to collect information about the state of the network by communicating directly with one or more I2RS agents. From these I2RS agents, the Topology Manager collects routing configuration and operational data, such as interface and Label Switched Path (LSP) information. In addition, the Topology Manager may collect link-state data in several ways -- via I2RS models, by peering with BGP-LS [RFC7752], or by listening into the IGP.
トポロジマネージャーには、I2RSデータモデルとプロトコルを使用して、1つ以上のI2RSエージェントと直接通信することにより、ネットワークの状態に関する情報を収集するI2RSクライアントが含まれています。これらのI2RSエージェントから、トポロジーマネージャーはルーティング構成と、インターフェイスやラベルスイッチドパス（LSP）情報などの運用データを収集します。さらに、トポロジーマネージャーは、I2RSモデルを介して、BGP-LS [RFC7752]とピアリングすることによって、またはIGPをリッスンすることによって、いくつかの方法でリンク状態データを収集できます。
The set of functionality and collected information that is the Topology Manager may be embedded as a component of a larger application, such as a path computation application. As a stand-alone application, the Topology Manager could be useful to other network applications by providing a coherent picture of the network state accessible via another interface. That interface might use the same I2RS protocol and could provide a topology service using extensions to the I2RS data models.
トポロジマネージャである一連の機能と収集された情報は、パス計算アプリケーションなどのより大きなアプリケーションのコンポーネントとして埋め込むことができます。スタンドアロンアプリケーションとして、トポロジーマネージャーは、別のインターフェイスを介してアクセス可能なネットワーク状態の一貫した全体像を提供することにより、他のネットワークアプリケーションに役立つ可能性があります。そのインターフェイスは、同じI2RSプロトコルを使用する場合があり、I2RSデータモデルの拡張を使用してトポロジサービスを提供できます。
The I2RS agent is part of a routing element. As such, it has relationships with that routing element as a whole and with various components of that routing element.
I2RSエージェントはルーティング要素の一部です。そのため、全体としてそのルーティング要素と、そのルーティング要素のさまざまなコンポーネントと関係があります。
A Routing Element may be implemented with a wide variety of different architectures: an integrated router, a split architecture, distributed architecture, etc. The architecture does not need to affect the general I2RS agent behavior.
ルーティング要素は、統合ルーター、分割アーキテクチャ、分散アーキテクチャなど、さまざまな異なるアーキテクチャで実装できます。アーキテクチャは、I2RSエージェントの一般的な動作に影響を与える必要はありません。
For scalability and generality, the I2RS agent may be responsible for collecting and delivering large amounts of data from various parts of the routing element. Those parts may or may not actually be part of a single physical device. Thus, for scalability and robustness, it is important that the architecture allow for a distributed set of reporting components providing collected data from the I2RS agent back to the relevant I2RS clients. There may be multiple I2RS agents within the same router. In such a case, they must have non-overlapping sets of information that they manipulate.
スケーラビリティと一般性のために、I2RSエージェントは、ルーティング要素のさまざまな部分から大量のデータを収集して配信する責任があります。これらのパーツは、実際には単一の物理デバイスの一部である場合とそうでない場合があります。したがって、スケーラビリティと堅牢性のためには、I2RSエージェントから収集されたデータを関連するI2RSクライアントに提供するレポートコンポーネントの分散セットをアーキテクチャが許可することが重要です。同じルーター内に複数のI2RSエージェントが存在する場合があります。そのような場合、操作する情報の重複しないセットが必要です。
To facilitate operations, deployment, and troubleshooting, it is important that traceability of the requests received by I2RS agent's and actions taken be supported via a common data model.
運用、展開、トラブルシューティングを容易にするために、I2RSエージェントが受け取った要求の追跡可能性と実行されたアクションが共通のデータモデルを介してサポートされることが重要です。
State modification requests are sent to the I2RS agent in a routing element by I2RS clients. The I2RS agent is responsible for applying these changes to the system, subject to the authorization discussed above. The I2RS agent will retain knowledge of the changes it has applied, and the client on whose behalf it applied the changes. The I2RS agent will also store active subscriptions. These sets of data form the I2RS datastore. This data is retained by the agent until the state is removed by the client, it is overridden by some other operation such as CLI, or the device reboots. Meaningful logging of the application and removal of changes are recommended. I2RS-applied changes to the routing element state will not be retained across routing element reboot. The I2RS datastore is not preserved across routing element reboots; thus, the I2RS agent will not attempt to reapply such changes after a reboot.
状態変更要求は、I2RSクライアントによってルーティング要素のI2RSエージェントに送信されます。 I2RSエージェントは、これらの変更をシステムに適用する責任があります。 I2RSエージェントは、それが適用した変更と、それを代理して変更を適用したクライアントの情報を保持します。 I2RSエージェントはアクティブなサブスクリプションも保存します。これらのデータセットがI2RSデータストアを形成します。このデータは、状態がクライアントによって削除されるか、CLIなどの他の操作によって上書きされるか、デバイスが再起動するまで、エージェントによって保持されます。アプリケーションの意味のあるロギングと変更の削除をお勧めします。 I2RSが適用したルーティング要素の状態の変更は、ルーティング要素の再起動後は保持されません。 I2RSデータストアは、ルーティング要素の再起動後は保持されません。したがって、I2RSエージェントは再起動後にそのような変更を再適用しようとしません。
It is expected that an I2RS agent may fail independently of the associated routing element. This could happen because I2RS is disabled on the routing element or because the I2RS agent, which may be a separate process or even running on a separate processor, experiences an unexpected failure. Just as routing state learned from a failed source is removed, the ephemeral I2RS state will usually be removed shortly after the failure is detected or as part of a graceful shutdown process. To handle these two types of failures, the I2RS agent MUST support two different notifications: a notification for the I2RS agent terminating gracefully, and a notification for the I2RS agent starting up after an unexpected failure. The two notifications are described below followed by a description of their use in unexpected failures and graceful shutdowns.
I2RSエージェントは、関連するルーティング要素とは関係なく失敗する可能性があることが予想されます。これは、ルーティング要素でI2RSが無効になっている、または別のプロセスであるか別のプロセッサで実行されているI2RSエージェントで予期しない障害が発生したために発生する可能性があります。障害が発生したソースから学習したルーティング状態が削除されるのと同じように、一時的なI2RS状態は通常、障害が検出された直後または正常なシャットダウンプロセスの一部として削除されます。これらの2種類の障害を処理するには、I2RSエージェントは2つの異なる通知をサポートする必要があります。I2RSエージェントが正常に終了する通知と、予期しない障害の後に起動するI2RSエージェントの通知です。 2つの通知について以下に説明し、その後に予期しない障害と正常なシャットダウンでの使用について説明します。
NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that the associated I2RS agent is shutting down gracefully and that I2RS ephemeral state will be removed. It can optionally include a timestamp indicating when the I2RS agent will shut down. Use of this timestamp assumes that time synchronization has been done, and the timestamp should not have granularity finer than one second because better accuracy of shutdown time is not guaranteed.
NOTIFICATION_I2RS_AGENT_TERMINATING：この通知は、関連するI2RSエージェントが正常にシャットダウンしており、I2RSの一時的な状態が削除されることを報告します。オプションで、I2RSエージェントがシャットダウンするタイミングを示すタイムスタンプを含めることができます。このタイムスタンプの使用は、時刻の同期が行われていることを前提としています。シャットダウン時刻の精度が保証されないため、タイムスタンプの精度が1秒より細かいはずです。
NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the I2RS client(s) that the associated I2RS agent has started. It includes an agent-boot-count that indicates how many times the I2RS agent has restarted since the associated routing element restarted. The agent-boot-count allows an I2RS client to determine if the I2RS agent has restarted. (Note: This notification will be sent by the I2RS agent to I2RS clients that are known by the I2RS agent after a reboot. How the I2RS agent retains the knowledge of these I2RS clients is out of scope of this architecture.)
NOTIFICATION_I2RS_AGENT_STARTING：この通知は、関連するI2RSエージェントが開始したことをI2RSクライアントに通知します。これには、関連するルーティング要素が再起動してからI2RSエージェントが再起動した回数を示すagent-boot-countが含まれています。 agent-boot-countにより、I2RSクライアントはI2RSエージェントが再起動したかどうかを判断できます。 （注：この通知は、再起動後にI2RSエージェントによって認識されるI2RSクライアントにI2RSエージェントによって送信されます。I2RSエージェントがこれらのI2RSクライアントの情報を保持する方法は、このアーキテクチャの範囲外です。）
There are two different failure types that are possible, and each has different behavior.
可能性のある2種類の障害タイプがあり、それぞれに異なる動作があります。
Unexpected failure: In this case, the I2RS agent has unexpectedly crashed and thus cannot notify its clients of anything. Since I2RS does not require a persistent connection between the I2RS client and I2RS agent, it is necessary to have a mechanism for the I2RS agent to notify I2RS clients that had subscriptions or written ephemeral state; such I2RS clients should be cached by the I2RS agent's system in persistent storage. When the I2RS agent starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each cached I2RS client.
予期しないエラー：この場合、I2RSエージェントが予期せずクラッシュしたため、クライアントに何も通知できません。 I2RSはI2RSクライアントとI2RSエージェント間の永続的な接続を必要としないため、I2RSエージェントがサブスクリプションまたは一時的な状態を書き込んだI2RSクライアントに通知するメカニズムが必要です。このようなI2RSクライアントは、I2RSエージェントのシステムによって永続ストレージにキャッシュされる必要があります。 I2RSエージェントが開始すると、キャッシュされた各I2RSクライアントにNOTIFICATION_I2RS_AGENT_STARTINGを送信する必要があります。
Graceful shutdowns: In this case, the I2RS agent can do specific limited work as part of the process of being disabled. The I2RS agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its cached I2RS clients. If the I2RS agent restarts after a graceful termination, it will send a NOTIFICATION_I2RS_AGENT_STARTING to each cached I2RS client.
グレースフルシャットダウン：この場合、I2RSエージェントは、無効化プロセスの一部として、特定の限られた作業を実行できます。 I2RSエージェントは、キャッシュされたすべてのI2RSクライアントにNOTIFICATION_I2RS_AGENT_TERMINATINGを送信する必要があります。正常な終了後にI2RSエージェントが再起動すると、キャッシュされた各I2RSクライアントにNOTIFICATION_I2RS_AGENT_STARTINGが送信されます。
When an I2RS client applies changes via the I2RS protocol, those changes are applied and left until removed or the routing element reboots. The network application may make decisions about what to request via I2RS based upon a variety of conditions that imply different start times and stop times. That complexity is managed by the network application and is not handled by I2RS.
I2RSクライアントがI2RSプロトコルを介して変更を適用すると、それらの変更が適用され、削除されるかルーティング要素が再起動するまでそのままになります。ネットワークアプリケーションは、開始時刻と終了時刻が異なることを意味するさまざまな条件に基づいて、I2RSを介して何を要求するかを決定します。この複雑さはネットワークアプリケーションによって管理され、I2RSでは処理されません。
An I2RS agent may decide that some state should no longer be applied. An I2RS client may instruct an agent to remove state it has applied. In all such cases, the state will revert to what it would have been without the I2RS client-agent interaction; that state is generally whatever was specified via the CLI, NETCONF, SNMP, etc., I2RS agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. (For I2RS state in the presence of two I2RS clients, please see Sections 1.2 and 7.8)
I2RSエージェントは、一部の状態を適用しないことを決定する場合があります。 I2RSクライアントは、適用した状態を削除するようにエージェントに指示する場合があります。このような場合はすべて、状態はI2RSクライアントとエージェントの相互作用がない場合の状態に戻ります。その状態は通常、CLI、NETCONF、SNMPなどを介して指定されたものです。I2RSエージェントは複数の代替状態を保存せず、そのような複数の状態のどれにフォールバックするかを決定しようとしません。したがって、従うモデルは、複数のルートが異なる設定で保存されるRIBとは異なります。 （2つのI2RSクライアントが存在する場合のI2RS状態については、セクション1.2および7.8を参照してください）
An I2RS client may register for notifications, subject to its notification scope, regarding state modification or removal by a particular I2RS client.
I2RSクライアントは、特定のI2RSクライアントによる状態の変更または削除に関する通知スコープに従って、通知を登録できます。
Changes may originate from either Local Configuration or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved in a deterministic manner that respects operator-applied policy. The deterministic manner is the result of general I2RS rules, system rules, knobs adjusted by operator-applied policy, and the rules associated with the YANG data model (often in "MUST" and "WHEN" clauses for dependencies).
変更は、ローカル構成またはI2RSから発生する可能性があります。 I2RSによって保存される変更とデータはローカルデバイス構成とは異なりますが、2つ間の競合は、オペレーターが適用したポリシーを尊重する決定論的な方法で解決する必要があります。確定的な方法は、一般的なI2RSルール、システムルール、オペレーターが適用したポリシーによって調整されたノブ、およびYANGデータモデルに関連付けられたルール（多くの場合、依存関係の「MUST」および「WHEN」句で）の結果です。
The operator-applied policy knobs can determine whether the Local Configuration overrides a particular I2RS client's request or vice versa. Normally, most devices will have an operator-applied policy that will prioritize the I2RS client's ephemeral configuration changes so that ephemeral data overrides the Local Configuration.
オペレーターが適用したポリシーノブは、ローカル構成が特定のI2RSクライアントの要求を上書きするか、またはその逆かを決定できます。通常、ほとんどのデバイスには、オペレーターが適用したポリシーがあり、I2RSクライアントの一時的な構成の変更を優先して、一時的なデータがローカル構成を上書きするようにします。
These operator-applied policy knobs can be implemented in many ways. One way is for the routing element to configure a priority on the Local Configuration and a priority on the I2RS client's write of the ephemeral configuration. The I2RS mechanism would compare the I2RS client's priority to write with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS client's write of ephemeral data wins.
オペレーターが適用するこれらのポリシーノブは、さまざまな方法で実装できます。 1つの方法は、ルーティング要素がローカル構成に優先度を構成し、I2RSクライアントの一時構成の書き込みに優先度を構成することです。 I2RSメカニズムは、I2RSクライアントの書き込み優先度とローカル構成に割り当てられた優先度を比較して、ローカル構成またはI2RSクライアントのエフェメラルデータの書き込みが優先されるかどうかを判断します。
To make sure the I2RS client's requests are what the operator desires, the I2RS data modules have a general rule that, by default, the Local Configuration always wins over the I2RS ephemeral configuration.
I2RSクライアントの要求がオペレーターの希望するものであることを確認するために、I2RSデータモジュールには、デフォルトでローカル構成が常にI2RS一時構成より優先されるという一般的なルールがあります。
The reason for this general rule is if there is no operator-applied policy to turn on I2RS ephemeral overwrites of Local Configuration, then the I2RS overwrites should not occur. This general rule allows the I2RS agents to be installed in routing systems and the communication tested between I2RS clients and I2RS agents without the I2RS agent overwriting configuration state. For more details, see the examples below.
この一般的なルールの理由は、ローカル設定のI2RS一時的な上書きをオンにするオペレーターが適用したポリシーがない場合、I2RSの上書きは発生しないはずです。この一般的なルールにより、I2RSエージェントをルーティングシステムにインストールし、I2RSエージェントが構成状態を上書きすることなく、I2RSクライアントとI2RSエージェント間で通信をテストできます。詳細については、以下の例を参照してください。
In the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value, it is installed instead of the Local Configuration state value. The Local Configuration information is stored so that if/when an I2RS client removes I2RS ephemeral state, the Local Configuration state can be restored.
I2RSの一時的な状態が常にデータモデルで優先される場合、I2RSの一時的な状態の値があれば、ローカル構成の状態の値の代わりにインストールされます。ローカル構成情報は、I2RSクライアントがI2RS一時的な状態を削除した場合にローカル構成状態を復元できるように保存されます。
When the Local Configuration always wins, some communication between that subsystem and the I2RS agent is still necessary. As an I2RS agent connects to the routing subsystem, the I2RS agent must also communicate with the Local Configuration to exchange model information so the I2RS agent knows the details of each specific device configuration change that the I2RS agent is permitted to modify. In addition, when the system determines that a client's I2RS state is preempted, the I2RS agent must notify the affected I2RS clients; how the system determines this is implementation dependent.
ローカル構成が常に優先される場合でも、そのサブシステムとI2RSエージェント間の何らかの通信が依然として必要です。 I2RSエージェントがルーティングサブシステムに接続すると、I2RSエージェントはローカル構成と通信してモデル情報を交換し、I2RSエージェントがI2RSエージェントが変更を許可されている特定の各デバイス構成変更の詳細を知るようにする必要があります。さらに、クライアントのI2RS状態がプリエンプトされたとシステムが判断した場合、I2RSエージェントは影響を受けるI2RSクライアントに通知する必要があります。システムがこれをどのように決定するかは実装依存です。
It is critical that policy based upon the source is used because the resolution cannot be time based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic.
解決は時間ベースではないため、ソースに基づくポリシーを使用することが重要です。最新の状態を優先させるだけでは、最終状態が繰り返し確定的でない競合状態が発生する可能性があります。
A set of examples is useful in order to illustrated these architecture principles. Assume there are three routers: Router A, Router B, and Router C. There are two operator-applied policy knobs that these three routers must have regarding ephemeral state.
これらのアーキテクチャの原則を説明するには、一連の例が役立ちます。ルーターA、ルーターB、ルーターCの3つのルーターがあると想定します。これらの3つのルーターが一時的な状態に関して持つ必要のある、オペレーターが適用する2つのポリシーノブがあります。
o Policy Knob 1: Ephemeral configuration overwrites Local Configuration.
o ポリシーノブ1：エフェメラル構成はローカル構成を上書きします。
o Policy Knob 2: Update of Local Configuration value supersedes and overwrites the ephemeral configuration.
o ポリシーノブ2：ローカル設定値の更新は、一時的な設定を上書きし、上書きします。
For Policy Knob 1, the routers with an I2RS agent receiving a write for an ephemeral entry in a data model must consider the following:
ポリシーノブ1の場合、データモデル内の一時エントリの書き込みを受信するI2RSエージェントを持つルーターは、以下を考慮する必要があります。
1. Does the operator policy allow the ephemeral configuration changes to have priority over existing Local Configuration?
1. オペレーターポリシーにより、一時的な構成の変更を既存のローカル構成よりも優先させることができますか？
2. Does the YANG data model have any rules associated with the ephemeral configuration (such as the "MUST" or "WHEN" rule)?
2. YANGデータモデルには、エフェメラル構成に関連付けられたルールがありますか（「MUST」または「WHEN」ルールなど）？
For this example, there is no "MUST" or "WHEN" rule in the data being written.
この例では、書き込まれるデータに「MUST」または「WHEN」のルールはありません。
The policy settings are:
ポリシー設定は次のとおりです。
Policy Knob 1 Policy Knob 2
=================== ==================
Router A ephemeral has ephemeral has
priority priority
Router B Local Configuration Local Configuration has priority has priority
ルーターBのローカル構成ローカル構成が優先されます
Router C ephemeral has Local Configuration priority has priority
ルーターCエフェメラルにはローカル構成の優先順位があります
Router A has the normal operator policy in Policy Knob 1 and Policy Knob 2 that prioritizes ephemeral configuration over Local Configuration in the I2RS agent. An I2RS client sends a write to an ephemeral configuration value via an I2RS agent in Router A. The I2RS agent overwrites the configuration value in the intended configuration, and the I2RS agent returns an acknowledgement of the write. If the Local Configuration value changes, Router A stays with the ephemeral configuration written by the I2RS client.
ルーターAには、ポリシーノブ1とポリシーノブ2に通常のオペレーターポリシーがあり、I2RSエージェントのローカル構成よりも一時的な構成を優先します。 I2RSクライアントはルーターAのI2RSエージェントを介してエフェメラル構成値への書き込みを送信します。I2RSエージェントは目的の構成の構成値を上書きし、I2RSエージェントは書き込みの確認を返します。ローカル構成の値が変更された場合、ルーターAはI2RSクライアントによって書き込まれた一時的な構成のままになります。
Router B's operator has no desire to allow ephemeral writes to overwrite Local Configuration even though it has installed an I2RS agent. Router B's policy prioritizes the Local Configuration over the ephemeral write. When the I2RS agent on Router B receives a write from an I2RS client, the I2RS agent will check the operator Policy Knob 1 and return a response to the I2RS client indicating the operator policy did not allow the overwriting of the Local Configuration.
ルーターBのオペレーターは、I2RSエージェントをインストールしていても、一時的な書き込みでローカル構成を上書きできるようにすることを望んでいません。ルーターBのポリシーは、一時的な書き込みよりもローカル構成を優先します。ルーターBのI2RSエージェントがI2RSクライアントから書き込みを受信すると、I2RSエージェントはオペレーターのポリシーノブ1をチェックし、オペレーターポリシーがローカル構成の上書きを許可していないことを示す応答をI2RSクライアントに返します。
The Router B case demonstrates why the I2RS architecture sets the default to the Local Configuration wins. Since I2RS functionality is new, the operator must enable it. Otherwise, the I2RS ephemeral functionality is off. Router B's operators can install the I2RS code and test responses without engaging the I2RS overwrite function.
ルーターBのケースは、I2RSアーキテクチャがデフォルトをローカル構成に設定する理由を示しています。 I2RS機能は新しいため、オペレーターはそれを有効にする必要があります。それ以外の場合、I2RS一時的機能はオフになります。ルーターBのオペレーターは、I2RSの上書き機能を使用せずに、I2RSコードをインストールして応答をテストできます。
Router C's operator sets Policy Knob 1 for the I2RS clients to overwrite existing Local Configuration and Policy Knob 2 for the Local Configuration changes to update ephemeral state. To understand why an operator might set the policy knobs this way, consider that Router C is under the control of an operator that has a back-end system that re-writes the Local Configuration of all systems at 11 p.m. each night. Any ephemeral change to the network is only supposed to last until 11 p.m. when the next Local Configuration changes are rolled out from the back-end system. The I2RS client writes the ephemeral state during the day, and the I2RS agent on Router C updates the value. At 11 p.m., the back-end configuration system updates the Local Configuration via NETCONF, and the I2RS agent is notified that the Local Configuration updated this value. The I2RS agent notifies the I2RS client that the value has been overwritten by the Local Configuration. The I2RS client in this use case is a part of an application that tracks any ephemeral state changes to make sure all ephemeral changes are included in the next configuration run.
ルーターCのオペレーターは、I2RSクライアントが既存のローカル構成を上書きするようにポリシーノブ1を設定し、ローカル構成の変更が一時的な状態を更新するためのポリシーノブ2を設定します。オペレーターがポリシーノブをこのように設定する理由を理解するために、ルーターCが、午後11時にすべてのシステムのローカル構成を書き換えるバックエンドシステムを持つオペレーターの制御下にあると考えてください。毎晩。ネットワークへの一時的な変更は、午後11時までしか持続しないことになっています。次のローカル構成の変更がバックエンドシステムからロールアウトされたとき。 I2RSクライアントは日中に一時的な状態を書き込み、ルーターCのI2RSエージェントは値を更新します。午後11時、バックエンド構成システムはNETCONFを介してローカル構成を更新し、I2RSエージェントはローカル構成がこの値を更新したことを通知されます。 I2RSエージェントは、値がローカル構成によって上書きされたことをI2RSクライアントに通知します。この使用例のI2RSクライアントは、一時的な状態の変更を追跡してすべての一時的な変更が次の構成の実行に含まれるようにするアプリケーションの一部です。
For simplicity, each logical protocol or set of functionality that can be compactly described in a separable information and data model is considered as a separate I2RS service. A routing element need not implement all routing components described nor provide the associated I2RS services. I2RS services should include a capability model so that peers can determine which parts of the service are supported. Each I2RS service requires an information model that describes at least the following: data that can be read, data that can be written, notifications that can be subscribed to, and the capability model mentioned above.
簡単にするために、分離可能な情報およびデータモデルでコンパクトに記述できる各論理プロトコルまたは機能セットは、個別のI2RSサービスと見なされます。ルーティング要素は、説明されているすべてのルーティングコンポーネントを実装したり、関連するI2RSサービスを提供したりする必要はありません。 I2RSサービスには、ピアがサービスのどの部分がサポートされているかを判断できるように、機能モデルを含める必要があります。各I2RSサービスには、少なくとも以下を記述する情報モデルが必要です。読み取り可能なデータ、書き込み可能なデータ、サブスクライブ可能な通知、および上記の機能モデル。
The initial services included in the I2RS architecture are as follows.
I2RSアーキテクチャに含まれる初期サービスは次のとおりです。
*************************** ************** *****************
* I2RS Protocol * * * * Dynamic *
* * * Interfaces * * Data & *
* +--------+ +-------+ * * * * Statistics *
* | Client | | Agent | * ************** *****************
* +--------+ +-------+ *
* * ************** *************
*************************** * * * *
* Policy * * Base QoS *
******************** ******** * Templates * * Templates *
* +--------+ * * * * * *************
* BGP | BGP-LS | * * PIM * **************
* +--------+ * * *
******************** ******** ****************************
* MPLS +---------+ +-----+ *
********************************** * | RSVP-TE | | LDP | *
* IGPs +------+ +------+ * * +---------+ +-----+ *
* +--------+ | OSPF | |IS-IS | * * +--------+ *
* | Common | +------+ +------+ * * | Common | *
* +--------+ * * +--------+ *
********************************** ****************************
**************************************************************
* RIB Manager *
* +-------------------+ +---------------+ +------------+ *
* | Unicast/multicast | | Policy-Based | | RIB Policy | *
* | RIBs & LIBs | | Routing | | Controls | *
* | route instances | | (ACLs, etc) | +------------+ *
* +-------------------+ +---------------+ *
**************************************************************
Figure 2: Anticipated I2RS Services
図2：予想されるI2RSサービス
There are relationships between different I2RS services -- whether those be the need for the RIB to refer to specific interfaces, the desire to refer to common complex types (e.g., links, nodes, IP addresses), or the ability to refer to implementation-specific functionality (e.g., pre-defined templates to be applied to interfaces or for QoS behaviors that traffic is directed into). Section 6.4.5 discusses information modeling constructs and the range of relationship types that are applicable.
異なるI2RSサービスの間には関係があります-RIBが特定のインターフェイスを参照する必要性、一般的な複雑なタイプ（リンク、ノード、IPアドレスなど）を参照する必要性、実装を参照する機能のいずれであっても、特定の機能（たとえば、インターフェイスに適用される、またはトラフィックが送信されるQoS動作に適用される定義済みテンプレート）。セクション6.4.5では、情報モデリングの構成要素と、適用可能な関係タイプの範囲について説明します。
Routing elements may maintain one or more information bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per platform, per interface, or per context. This functionality, exposed via an I2RS service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources. Conceptually, this can be handled by having the I2RS agent communicate with a RIB Manager as a separate routing source.
ルーティング要素は、1つ以上の情報ベースを維持できます。例には、IPv4 / IPv6ユニキャストまたはIPv4 / IPv6マルチキャストなどのルーティング情報ベースが含まれます。別のそのような例には、プラットフォームごと、インターフェイスごと、またはコンテキストごとのMPLSラベル情報ベースが含まれます。 I2RSサービスを介して公開されるこの機能は、ルーティング要素が複数のソースからのRIB入力を処理するためにすでに使用しているのと同じメカニズムとスムーズに相互作用する必要があります。概念的には、これは、I2RSエージェントが個別のルーティングソースとしてRIBマネージャーと通信することで処理できます。
The point-to-multipoint state added to the RIB does not need to match to well-known multicast protocol installed state. The I2RS agent can create arbitrary replication state in the RIB, subject to the advertised capabilities of the routing element.
RIBに追加されたポイントツーマルチポイント状態は、既知のマルチキャストプロトコルがインストールされた状態と一致する必要はありません。 I2RSエージェントは、ルーティング要素のアドバタイズされた機能に従って、RIBに任意の複製状態を作成できます。
A separate I2RS service can expose each routing protocol on the device. Such I2RS services may include a number of different kinds of operations:
個別のI2RSサービスは、デバイス上の各ルーティングプロトコルを公開できます。このようなI2RSサービスには、さまざまな種類の操作が含まれる場合があります。
o reading the various internal RIB(s) of the routing protocol is often helpful for understanding the state of the network. Directly writing to these protocol-specific RIBs or databases is out of scope for I2RS.
o ルーティングプロトコルのさまざまな内部RIBを読み取ることは、ネットワークの状態を理解するのに役立つことがよくあります。これらのプロトコル固有のRIBまたはデータベースへの直接書き込みは、I2RSの範囲外です。
o reading the various pieces of policy information the particular protocol instance is using to drive its operations.
o 特定のプロトコルインスタンスが操作を実行するために使用しているさまざまなポリシー情報を読み取る。
o writing policy information such as interface attributes that are specific to the routing protocol or BGP policy that may indirectly manipulate attributes of routes carried in BGP.
o ルーティングプロトコルに固有のインターフェイス属性や、BGPで伝送されるルートの属性を間接的に操作する可能性があるBGPポリシーなどのポリシー情報を書き込む。
o writing routes or prefixes to be advertised via the protocol.
o プロトコルを介してアドバタイズされるルートまたはプレフィックスを記述します。
o joining/removing interfaces from the multicast trees.
o マルチキャストツリーからのインターフェイスへの参加/削除。
o subscribing to an information stream of route changes.
o ルート変更の情報ストリームにサブスクライブします。
o receiving notifications about peers coming up or going down.
o ピアのアップまたはダウンに関する通知の受信
For example, the interaction with OSPF might include modifying the local routing element's link metrics, announcing a locally attached prefix, or reading some of the OSPF link-state database. However, direct modification of the link-state database must not be allowed in order to preserve network state consistency.
たとえば、OSPFとの対話には、ローカルルーティング要素のリンクメトリックの変更、ローカルに接続されたプレフィックスのアナウンス、または一部のOSPFリンク状態データベースの読み取りが含まれる場合があります。ただし、ネットワーク状態の一貫性を維持するために、リンク状態データベースを直接変更することはできません。
I2RS services will be needed to expose the protocols that create transport LSPs (e.g., LDP and RSVP-TE) as well as protocols (e.g., BGP, LDP) that provide MPLS-based services (e.g., pseudowires, L3VPNs, L2VPNs, etc). This should include all local information about LSPs originating in, transiting, or terminating in this Routing Element.
I2RSサービスは、トランスポートLSP（LDPやRSVP-TEなど）を作成するプロトコルと、MPLSベースのサービス（疑似配線、L3VPN、L2VPNなど）を提供するプロトコル（BGP、LDPなど）を公開するために必要です。 。これには、このルーティング要素で発信、通過、または終了するLSPに関するすべてのローカル情報が含まれている必要があります。
Many network elements have separate policy and QoS mechanisms, including knobs that affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS information models and supported in the expected interfaces between the I2RS agent and the network element, in order to provide basic capabilities and the hooks for future extensibility.
多くのネットワーク要素には、ローカルパス計算とキュー制御機能に影響を与えるノブを含む、個別のポリシーとQoSメカニズムがあります。これらの機能は実装によって大きく異なり、I2RSはこれらの属性の情報収集または操作の全範囲をモデル化することはできません。基本機能と将来の拡張性のためのフックを提供するために、コアセットはI2RS情報モデルに含まれ、I2RSエージェントとネットワーク要素の間の予想されるインターフェイスでサポートされる必要があります。
By taking advantage of extensibility and subclassing, information models can specify use of a basic model that can be replaced by a more detailed model.
拡張性とサブクラス化を利用することで、情報モデルは、より詳細なモデルに置き換えることができる基本モデルの使用を指定できます。
6.4.5. Information Modeling, Device Variation, and Information Relationships
6.4.5. 情報モデリング、デバイスのバリエーション、および情報の関係
I2RS depends heavily on information models of the relevant aspects of the Routing Elements to be manipulated. These models drive the data models and protocol operations for I2RS. It is important that these information models deal well with a wide variety of actual implementations of Routing Elements, as seen between different products and different vendors. There are three ways that I2RS information models can address these variations: class or type inheritance, optional features, and templating.
I2RSは、操作されるルーティング要素の関連する側面の情報モデルに大きく依存しています。これらのモデルは、I2RSのデータモデルとプロトコル操作を駆動します。さまざまな製品やさまざまなベンダー間で見られるように、これらの情報モデルがルーティング要素のさまざまな実際の実装を適切に処理することが重要です。 I2RS情報モデルがこれらのバリエーションに対処するには、クラスまたはタイプの継承、オプション機能、およびテンプレートの3つの方法があります。
Information modeled by I2RS from a Routing Element can be described in terms of classes or types or object. Different valid inheritance definitions can apply. What is appropriate for I2RS to use is not determined in this architecture; for simplicity, "class" and "subclass" will be used as the example terminology. This I2RS architecture does require the ability to address variation in Routing Elements by allowing information models to define parent or base classes and subclasses.
ルーティング要素からI2RSによってモデル化された情報は、クラス、タイプ、またはオブジェクトの観点から説明できます。異なる有効な継承定義を適用できます。 I2RSの使用に適切なものは、このアーキテクチャでは決定されていません。簡単にするために、用語の例として「クラス」と「サブクラス」を使用します。このI2RSアーキテクチャでは、情報モデルが親または基本クラスとサブクラスを定義できるようにすることで、ルーティング要素のバリエーションに対処する機能が必要です。
The base or parent class defines the common aspects that all Routing Elements are expected to support. Individual subclasses can represent variations and additional capabilities. When applicable, there may be several levels of refinement. The I2RS protocol can then provide mechanisms to allow an I2RS client to determine which classes a given I2RS agent has available. I2RS clients that only want basic capabilities can operate purely in terms of base or parent classes, while a client needing more details or features can work with the supported subclass(es).
基本クラスまたは親クラスは、すべてのルーティング要素がサポートすることが期待される共通の側面を定義します。個々のサブクラスは、バリエーションと追加機能を表すことができます。該当する場合、いくつかのレベルの調整が行われる場合があります。その後、I2RSプロトコルは、I2RSクライアントが、特定のI2RSエージェントが使用できるクラスを判別できるようにするメカニズムを提供できます。基本的な機能のみを必要とするI2RSクライアントは、基本クラスまたは親クラスの観点から純粋に動作できますが、詳細または機能を必要とするクライアントは、サポートされているサブクラスを操作できます。
As part of I2RS information modeling, clear rules should be specified for how the parent class and subclass can relate; for example, what changes can a subclass make to its parent? The description of such rules should be done so that it can apply across data modeling tools until the I2RS data modeling language is selected.
I2RS情報モデリングの一部として、親クラスとサブクラスがどのように関係するかについて明確なルールを指定する必要があります。たとえば、サブクラスはその親にどのような変更を加えることができますか？このようなルールの説明は、I2RSデータモデリング言語が選択されるまでデータモデリングツール全体に適用できるようにする必要があります。
I2RS information models must be clear about what aspects are optional. For instance, must an instance of a class always contain a particular data field X? If so, must the client provide a value for X when creating the object or is there a well-defined default value? From the Routing Element perspective, in the above example, each information model should provide information regarding the following questions:
I2RS情報モデルは、どの側面がオプションであるかについて明確でなければなりません。たとえば、クラスのインスタンスには常に特定のデータフィールドXが含まれている必要がありますか？その場合、クライアントはオブジェクトの作成時にXの値を提供する必要がありますか、それとも明確に定義されたデフォルト値がありますか？上記の例では、ルーティング要素の観点から、各情報モデルは次の質問に関する情報を提供する必要があります。
o Is X required for the data field to be accepted and applied?
o データフィールドを受け入れて適用するにはXが必要ですか？
o If X is optional, then how does "X" as an optional portion of the data field interact with the required aspects of the data field?
o Xがオプションの場合、データフィールドのオプション部分としての「X」は、データフィールドの必要な側面とどのように相互作用しますか？
o Does the data field have defaults for the mandatory portion of the field and the optional portions of the field?
o データフィールドには、フィールドの必須部分とオプション部分のデフォルトがありますか？
o Is X required to be within a particular set of values (e.g., range, length of strings)?
o Xは特定の値のセット（範囲、文字列の長さなど）内にある必要がありますか？
The information model needs to be clear about what read or write values are set by the client and what responses or actions are required by the agent. It is important to indicate what is required or optional in client values and agent responses/actions.
情報モデルは、クライアントが設定する読み取り値または書き込み値、およびエージェントが必要とする応答またはアクションについて明確にする必要があります。クライアントの値とエージェントの応答/アクションで何が必須または任意であるかを示すことが重要です。
A template is a collection of information to address a problem; it cuts across the notions of class and object instances. A template provides a set of defined values for a set of information fields and can specify a set of values that must be provided to complete the template. Further, a flexible template scheme may allow some of the defined values to be overwritten.
テンプレートは、問題に対処するための情報の集まりです。クラスとオブジェクトのインスタンスの概念を横断します。テンプレートは、一連の情報フィールドに一連の定義済みの値を提供し、テンプレートを完成させるために提供する必要がある一連の値を指定できます。さらに、柔軟なテンプレートスキームでは、定義された値の一部を上書きできます。
For instance, assigning traffic to a particular service class might be done by specifying a template queueing with a parameter to indicate Gold, Silver, or Best Effort. The details of how that is carried out are not modeled. This does assume that the necessary templates are made available on the Routing Element via some mechanism other than I2RS. The idea is that by providing suitable templates for tasks that need to be accomplished, with templates implemented differently for different kinds of Routing Elements, the client can easily interact with the Routing Element without concern for the variations that are handled by values included in the template.
たとえば、特定のサービスクラスにトラフィックを割り当てるには、ゴールド、シルバー、またはベストエフォートを示すパラメータを使用してテンプレートキューイングを指定します。その実行方法の詳細はモデル化されていません。これは、必要なテンプレートがI2RS以外のメカニズムを介してルーティング要素で利用可能になることを前提としています。アイデアは、達成する必要のあるタスクに適切なテンプレートを提供することにより、異なる種類のルーティング要素に対して異なる方法で実装されたテンプレートにより、クライアントは、テンプレートに含まれる値によって処理される変動を気にすることなく、ルーティング要素と簡単に対話できるということです。 。
If implementation variation can be exposed in other ways, templates may not be needed. However, templates themselves could be objects referenced in the protocol messages, with Routing Elements being configured with the proper templates to complete the operation. This is a topic for further discussion.
実装のバリエーションを他の方法で公開できる場合、テンプレートは必要ない場合があります。ただし、テンプレート自体は、プロトコルメッセージで参照されるオブジェクトであり、ルーティング要素は、操作を完了するための適切なテンプレートで構成されています。これは、さらに議論するためのトピックです。
Objects (in a Routing Element or otherwise) do not exist in isolation. They are related to each other. One of the important things a class definition does is represent the relationships between instances of different classes. These relationships can be very simple or quite complicated. The following sections list the information relationships that the information models need to support.
（ルーティングエレメント内などの）オブジェクトは分離して存在しません。それらは互いに関連しています。クラス定義で重要なことの1つは、異なるクラスのインスタンス間の関係を表すことです。これらの関係は非常に単純な場合もあれば、非常に複雑な場合もあります。次のセクションでは、情報モデルがサポートする必要のある情報の関係を示します。
The simplest relationship is that one object instance is initialized by copying another. For example, one may have an object instance that represents the default setup for a tunnel, and all new tunnels have fields copied from there if they are not set as part of establishment. This is closely related to the templates discussed above, but not identical. Since the relationship is only momentary, it is often not formally represented in modeling but only captured in the semantic description of the default object.
最も単純な関係は、1つのオブジェクトインスタンスが別のインスタンスをコピーすることによって初期化されることです。たとえば、トンネルのデフォルト設定を表すオブジェクトインスタンスがあり、確立の一部として設定されていない場合、すべての新しいトンネルにはそこからコピーされたフィールドがあります。これは上記のテンプレートと密接に関連していますが、同一ではありません。関係は一時的なものであるため、モデリングでは正式に表現されないことが多く、デフォルトオブジェクトのセマンティック記述でのみ取得されます。
Often, it suffices to indicate in one object that it is related to a second object, without having a strong binding between the two. So an identifier is used to represent the relationship. This can be used to allow for late binding or a weak binding that does not even need to exist. A policy name in an object might indicate that if a policy by that name exists, it is to be applied under some circumstance. In modeling, this is often represented by the type of the value.
多くの場合、2つのオブジェクト間の強い結合がなくても、1つのオブジェクトで2つ目のオブジェクトに関連していることを示すだけで十分です。したがって、識別子は関係を表すために使用されます。これは、遅延バインディングや、存在する必要さえない弱いバインディングを可能にするために使用できます。オブジェクト内のポリシー名は、その名前のポリシーが存在する場合、ある状況下で適用されることを示している場合があります。モデリングでは、これはしばしば値のタイプによって表されます。
Sometimes the relationship between objects is stronger. A valid ARP entry has to point to the active interface over which it was derived. This is the classic meaning of an object reference in programming. It can be used for relationships like containment or dependence. This is usually represented by an explicit modeling link.
オブジェクト間の関係がより強い場合があります。有効なARPエントリは、それが導出されたアクティブなインターフェイスを指す必要があります。これは、プログラミングにおけるオブジェクト参照の古典的な意味です。封じ込めや依存関係などの関係に使用できます。これは通常、明示的なモデリングリンクによって表されます。
There is an even stronger form of coupling between objects if changes in one of the two objects are always to be reflected in the state of the other. For example, if a tunnel has an MTU (maximum transmit unit), and link MTU changes need to immediately propagate to the tunnel MTU, then the tunnel is actively coupled to the link interface. This kind of active state coupling implies some sort of internal bookkeeping to ensure consistency, often conceptualized as a subscription model across objects.
2つのオブジェクトの一方の変更が常にもう一方の状態に反映される場合、オブジェクト間の結合のさらに強力な形式があります。たとえば、トンネルにMTU（最大送信単位）があり、リンクMTUの変更がトンネルMTUにすぐに伝播する必要がある場合、トンネルはリンクインターフェイスにアクティブに結合されます。この種のアクティブな状態の結合は、一貫性を確保するためのある種の内部簿記を意味し、オブジェクト全体のサブスクリプションモデルとして概念化されることがよくあります。
This I2RS architecture assumes a data-model-driven protocol where the data models are defined in YANG 1.1 [YANG1.1] and associated YANG based model documents [RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]. Two of the protocols to be expanded to support the I2RS protocol are NETCONF [RFC6241] and RESTCONF [RESTCONF]. This helps meet the goal of simplicity and thereby enhances deployability. The I2RS protocol may need to use several underlying transports (TCP, SCTP (Stream Control Transport Protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity-protection mechanisms. These different transports can support different types of communication (e.g., control, reading, notifications, and information collection) and different sets of data. Whatever transport is used for the data exchange, it must also support suitable congestion-control mechanisms. The transports chosen should be operator and implementor friendly to ease adoption.
このI2RSアーキテクチャは、データモデルがYANG 1.1 [YANG1.1]および関連するYANGベースのモデルドキュメント[RFC6991]、[RFC7223]、[RFC7224]、[RFC7277]、[RFC7317]で定義されているデータモデル駆動型プロトコルを想定しています。 。 I2RSプロトコルをサポートするために拡張される2つのプロトコルは、NETCONF [RFC6241]とRESTCONF [RESTCONF]です。これにより、シンプルさという目標を達成し、展開性を向上させることができます。 I2RSプロトコルは、適切な認証および完全性保護メカニズムを備えた、いくつかの基本的なトランスポート（TCP、SCTP（ストリーム制御トランスポートプロトコル）、DCCP（データグラム輻輳制御プロトコル））を使用する必要がある場合があります。これらのさまざまなトランスポートは、さまざまな種類の通信（制御、読み取り、通知、情報収集など）とさまざまなデータセットをサポートできます。データ交換に使用されるトランスポートは何でも、適切な輻輳制御メカニズムもサポートする必要があります。選択したトランスポートは、採用を容易にするために、オペレーターと実装者に優しいものでなければなりません。
Each version of the I2RS protocol will specify the following: a) which transports may be used by the I2RS protocol, b) which transports are mandatory to implement, and c) which transports are optional to implement.
I2RSプロトコルの各バージョンでは、次のことを指定します。a）I2RSプロトコルで使用できるトランスポート、b）実装に必須のトランスポート、c）実装にオプションのトランスポート。
Multiple communication channels and multiple types of communication channels are required. There may be a range of requirements (e.g., confidentiality, reliability), and to support the scaling, there may need to be channels originating from multiple subcomponents of a routing element and/or to multiple parts of an I2RS client. All such communication channels will use the same higher-layer I2RS protocol (which combines secure transport and I2RS contextual information). The use of additional channels for communication will be coordinated between the I2RS client and the I2RS agent using this protocol.
複数の通信チャネルと複数のタイプの通信チャネルが必要です。さまざまな要件（機密性、信頼性など）があり、スケーリングをサポートするために、ルーティング要素の複数のサブコンポーネントから発生したチャネル、および/またはI2RSクライアントの複数の部分へのチャネルが必要な場合があります。そのようなすべての通信チャネルは、同じ上位層のI2RSプロトコル（安全なトランスポートとI2RSコンテキスト情報を組み合わせたもの）を使用します。通信用の追加チャネルの使用は、このプロトコルを使用してI2RSクライアントとI2RSエージェント間で調整されます。
I2RS protocol communication may be delivered in-band via the routing system's data plane. I2RS protocol communication might be delivered out-of-band via a management interface. Depending on what operations are requested, it is possible for the I2RS protocol communication to cause the in-band communication channels to stop working; this could cause the I2RS agent to become unreachable across that communication channel.
I2RSプロトコル通信は、ルーティングシステムのデータプレーンを介してインバンドで配信できます。 I2RSプロトコル通信は、管理インターフェースを介して帯域外で配信される場合があります。要求される操作に応じて、I2RSプロトコル通信が帯域内通信チャネルの動作を停止させる可能性があります。これにより、I2RSエージェントがその通信チャネルを介して到達不能になる可能性があります。
The support for different protocol capabilities and I2RS services will vary across I2RS clients and Routing Elements supporting I2RS agents. Since each I2RS service is required to include a capability model (see Section 6.4), negotiation at the protocol level can be restricted to protocol specifics and which I2RS services are supported.
さまざまなプロトコル機能とI2RSサービスのサポートは、I2RSクライアントと、I2RSエージェントをサポートするルーティング要素によって異なります。各I2RSサービスには機能モデルが含まれている必要があるため（セクション6.4を参照）、プロトコルレベルでのネゴシエーションをプロトコル固有のものと、サポートされているI2RSサービスに制限できます。
Capability negotiation (such as which transports are supported beyond the minimum required to implement) will clearly be necessary. It is important that such negotiations be kept simple and robust, as such mechanisms are often a source of difficulty in implementation and deployment.
機能のネゴシエーション（実装に必要な最小を超えてサポートされるトランスポートなど）は明らかに必要です。このようなメカニズムは多くの場合、実装と展開の困難さの原因となるため、このような交渉はシンプルかつ堅牢に保つことが重要です。
The protocol capability negotiation can be segmented into the basic version negotiation (required to ensure basic communication), and the more complex capability exchange that can take place within the base protocol mechanisms. In particular, the more complex protocol and mechanism negotiation can be addressed by defining information models for both the I2RS agent and the I2RS client. These information models can describe the various capability options. This can then represent and be used to communicate important information about the agent and the capabilities thereof.
プロトコル機能ネゴシエーションは、基本バージョンネゴシエーション（基本的な通信を保証するために必要）と、基本プロトコルメカニズム内で実行できるより複雑な機能交換に分割できます。特に、I2RSエージェントとI2RSクライアントの両方の情報モデルを定義することで、より複雑なプロトコルとメカニズムのネゴシエーションに対応できます。これらの情報モデルは、さまざまな機能オプションを説明できます。これは、エージェントとその機能に関する重要な情報を表すために使用できます。
As Sections 4.1 and 4.2 describe, each I2RS client will have a unique identity and may have a secondary identity (see Section 2) to aid in troubleshooting. As Section 4 indicates, all authentication and authorization mechanisms are based on the primary identity, which links to a role with scope policy for reading data, for writing data, and for limiting the resources that can be consumed. The specifications for data scope policy (for read, write, or resources consumption) need to specify the data being controlled by the policy, and acceptable ranges of values for the data.
セクション4.1および4.2で説明されているように、各I2RSクライアントは一意のIDを持ち、トラブルシューティングに役立つセカンダリID（セクション2を参照）を持つ場合があります。セクション4が示すように、すべての認証および承認メカニズムは、データの読み取り、データの書き込み、および消費可能なリソースの制限のためのスコープポリシーを持つロールにリンクするプライマリIDに基づいています。データスコープポリシー（読み取り、書き込み、またはリソース消費）の仕様では、ポリシーによって制御されるデータと、データの許容値の範囲を指定する必要があります。
An I2RS client may or may not maintain an active communication channel with an I2RS agent. Therefore, an I2RS agent may need to open a communication channel to the client to communicate previously requested information. The lack of an active communication channel does not imply that the associated I2RS client is non-functional. When communication is required, the I2RS agent or I2RS client can open a new communication channel.
I2RSクライアントは、I2RSエージェントとのアクティブな通信チャネルを維持する場合と維持しない場合があります。したがって、I2RSエージェントは、以前に要求された情報を通信するために、クライアントへの通信チャネルを開く必要がある場合があります。アクティブな通信チャネルがないことは、関連するI2RSクライアントが機能していないことを意味するものではありません。通信が必要な場合、I2RSエージェントまたはI2RSクライアントは新しい通信チャネルを開くことができます。
State held by an I2RS agent that is owned by an I2RS client should not be removed or cleaned up when a client is no longer communicating, even if the agent cannot successfully open a new communication channel to the client.
I2RSクライアントが所有するI2RSエージェントが保持する状態は、エージェントがクライアントへの新しい通信チャネルを正常に開くことができない場合でも、クライアントが通信しなくなったときに削除またはクリーンアップしないでください。
For many applications, it may be desirable to clean up state if a network application dies before removing the state it has created. Typically, this is dealt with in terms of network application redundancy. If stronger mechanisms are desired, mechanisms outside of I2RS may allow a supervisory network application to monitor I2RS clients and, based on policy known to the supervisor, clean up state if applications die. More complex mechanisms instantiated in the I2RS agent would add complications to the I2RS protocol and are thus left for future work.
多くのアプリケーションでは、作成した状態を削除する前にネットワークアプリケーションが停止した場合、状態をクリーンアップすることが望ましい場合があります。通常、これはネットワークアプリケーションの冗長性の観点から処理されます。より強力なメカニズムが必要な場合、I2RSの外部のメカニズムにより、監視ネットワークアプリケーションがI2RSクライアントを監視し、スーパーバイザが認識しているポリシーに基づいて、アプリケーションが停止した場合に状態をクリーンアップできます。 I2RSエージェントでインスタンス化されたより複雑なメカニズムは、I2RSプロトコルに複雑さを追加するため、将来の作業に残されます。
Some examples of such a mechanism include the following. In one option, the client could request state cleanup if a particular transport session is terminated. The second is to allow state expiration, expressed as a policy associated with the I2RS client's role. The state expiration could occur after there has been no successful communication channel to or from the I2RS client for the policy-specified duration.
このようなメカニズムのいくつかの例には、次のものがあります。 1つのオプションでは、特定のトランスポートセッションが終了した場合、クライアントは状態のクリーンアップを要求できます。 2つ目は、I2RSクライアントの役割に関連付けられたポリシーとして表される状態の期限切れを許可することです。状態の有効期限は、ポリシーで指定された期間、I2RSクライアントとの間の通信チャネルが成功しなかった後に発生する可能性があります。
As with any policy system interacting with the network, the I2RS client needs to be able to receive notifications of changes in network state. Notifications here refer to changes that are unanticipated, represent events outside the control of the systems (such as interface failures on controlled devices), or are sufficiently sparse as to be anomalous in some fashion. A notification may also be due to a regular event.
ネットワークとやり取りするポリシーシステムと同様に、I2RSクライアントはネットワーク状態の変化の通知を受信できる必要があります。ここでの通知とは、予期しない変更、システムの制御外のイベント（制御されたデバイスのインターフェース障害など）を表す、または何らかの方法で異常であるほど十分にまばらな変更を指します。通知は、定期的なイベントによるものである場合もあります。
Such events may be of interest to multiple I2RS clients controlling data handled by an I2RS agent and to multiple other I2RS clients that are collecting information without exerting control. The architecture therefore requires that it be practical for I2RS clients to register for a range of notifications and for the I2RS agents to send notifications to a number of clients. The I2RS client should be able to filter the specific notifications that will be received; the specific types of events and filtering operations can vary by information model and need to be specified as part of the information model.
このようなイベントは、I2RSエージェントによって処理されるデータを制御する複数のI2RSクライアント、および制御を発揮せずに情報を収集している他の複数のI2RSクライアントにとって重要な場合があります。したがって、このアーキテクチャでは、I2RSクライアントが一連の通知を登録し、I2RSエージェントが多数のクライアントに通知を送信することが実用的である必要があります。 I2RSクライアントは、受信される特定の通知をフィルタリングできる必要があります。特定のタイプのイベントとフィルタリング操作は、情報モデルによって異なり、情報モデルの一部として指定する必要があります。
The I2RS information model needs to include representation of these events. As discussed earlier, the capability information in the model will allow I2RS clients to understand which events a given I2RS agent is capable of generating.
I2RS情報モデルには、これらのイベントの表現を含める必要があります。前述のように、モデルの機能情報により、I2RSクライアントは、特定のI2RSエージェントが生成できるイベントを理解できます。
For performance and scaling by the I2RS client and general information confidentiality, an I2RS client needs to be able to register for just the events it is interested in. It is also possible that I2RS might provide a stream of notifications via a publish/subscribe mechanism that is not amenable to having the I2RS agent do the filtering.
I2RSクライアントによるパフォーマンスとスケーリング、および一般的な情報の機密性のために、I2RSクライアントは、関心のあるイベントだけに登録できる必要があります。I2RSは、次のパブリッシュ/サブスクライブメカニズムを介して通知のストリームを提供することもできます。 I2RSエージェントにフィルタリングを実行させることはできません。
One of the other important aspects of I2RS is that it is intended to simplify collecting information about the state of network elements. This includes both getting a snapshot of a large amount of data about the current state of the network element and subscribing to a feed of the ongoing changes to the set of data or a subset thereof. This is considered architecturally separate from notifications due to the differences in information rate and total volume.
I2RSの他の重要な側面の1つは、ネットワーク要素の状態に関する情報の収集を簡略化することを目的としていることです。これには、ネットワーク要素の現在の状態に関する大量のデータのスナップショットを取得することと、データのセットまたはそのサブセットに対する進行中の変更のフィードを購読することの両方が含まれます。これは、情報レートと総量が異なるため、アーキテクチャ上は通知とは別のものと見なされます。
As described earlier, an I2RS agent interacts with multiple I2RS clients who are actively controlling the network element. From an architecture and design perspective, the assumption is that by means outside of this system, the data to be manipulated within the network element is appropriately partitioned so that any given piece of information is only being manipulated by a single I2RS client.
前述のように、I2RSエージェントは、ネットワーク要素をアクティブに制御している複数のI2RSクライアントと対話します。アーキテクチャと設計の観点から、このシステムの外部の手段によって、ネットワーク要素内で操作されるデータが適切に分割され、特定の情報が単一のI2RSクライアントによってのみ操作されることが想定されています。
Nonetheless, unexpected interactions happen, and two (or more) I2RS clients may attempt to manipulate the same piece of data. This is considered an error case. This architecture does not attempt to determine what the right state of data should be when such a collision happens. Rather, the architecture mandates that there be decidable means by which I2RS agents handle the collisions. The mechanism for ensuring predictability is to have a simple priority associated with each I2RS client, and the highest priority change remains in effect. In the case of priority ties, the first I2RS client whose attribution is associated with the data will keep control.
それにもかかわらず、予期しない相互作用が発生し、2つ（またはそれ以上）のI2RSクライアントが同じデータを操作しようと試みる可能性があります。これはエラーケースと見なされます。このアーキテクチャは、このような衝突が発生したときにデータの正しい状態を判断しようとはしません。むしろ、アーキテクチャは、I2RSエージェントが衝突を処理するための決定可能な手段が存在することを義務付けています。予測可能性を確保するためのメカニズムは、各I2RSクライアントに関連付けられた単純な優先度を持つことであり、最高の優先度の変更が引き続き有効です。優先順位の関係の場合、属性がデータに関連付けられている最初のI2RSクライアントが制御を続けます。
In order for this approach to multi-headed control to be useful for I2RS clients, it is necessary that an I2RS client can register to receive notifications about changes made to writeable data, whose state is of specific interest to that I2RS client. This is included in the I2RS event mechanisms. This also needs to apply to changes made by CLI/NETCONF/SNMP within the write scope of the I2RS agent, as the same priority mechanism (even if it is "CLI always wins") applies there. The I2RS client may then respond to the situation as it sees fit.
マルチヘッドコントロールへのこのアプローチをI2RSクライアントに役立つようにするには、I2RSクライアントを登録して、書き込み可能なデータに加えられた変更に関する通知を受信できるようにする必要があります。その状態は、そのI2RSクライアントに特に関係があります。これは、I2RSイベントメカニズムに含まれています。これは、I2RSエージェントの書き込みスコープ内でCLI / NETCONF / SNMPによって行われた変更にも適用する必要があります。これは、同じ優先度メカニズム（「CLIが常に優先される」であっても）が適用されるためです。 I2RSクライアントは、状況に応じて状況に応答します。
In the interest of simplicity, the I2RS architecture does not include multi-message atomicity and rollback mechanisms. Rather, it includes a small range of error handling for a set of operations included in a single message. An I2RS client may indicate one of the following three methods of error handling for a given message with multiple operations that it sends to an I2RS agent:
簡単にするため、I2RSアーキテクチャにはマルチメッセージの原子性とロールバックメカニズムは含まれていません。むしろ、単一のメッセージに含まれる一連の操作に対する小さな範囲のエラー処理が含まれます。 I2RSクライアントは、I2RSエージェントに送信する複数の操作で、特定のメッセージの次の3つのエラー処理方法のいずれかを示す場合があります。
Perform all or none: This traditional SNMP semantic indicates that the I2RS agent will keep enough state when handling a single message to roll back the operations within that message. Either all the operations will succeed, or none of them will be applied, and an error message will report the single failure that caused them not to be applied. This is useful when there are, for example, mutual dependencies across operations in the message.
すべて実行するか、まったく実行しない：この従来のSNMPセマンティクスは、単一のメッセージを処理してそのメッセージ内の操作をロールバックするときに、I2RSエージェントが十分な状態を維持することを示しています。すべての操作が成功するか、どれも適用されず、エラーメッセージが適用されない原因となった単一の失敗を報告します。これは、たとえば、メッセージ内の操作間で相互依存関係がある場合に役立ちます。
Perform until error: In this case, the operations in the message are applied in the specified order. When an error occurs, no further operations are applied, and an error is returned indicating the failure. This is useful if there are dependencies among the operations and they can be topologically sorted.
エラーになるまで実行：この場合、メッセージ内の操作は指定された順序で適用されます。エラーが発生すると、それ以上の操作は適用されず、失敗を示すエラーが返されます。これは、操作間に依存関係があり、トポロジ的にソートできる場合に役立ちます。
Perform all storing errors: In this case, the I2RS agent will attempt to perform all the operations in the message and will return error indications for each one that fails. This is useful when there is no dependency across the operation or when the I2RS client would prefer to sort out the effect of errors on its own.
すべての保存エラーを実行します。この場合、I2RSエージェントはメッセージ内のすべての操作を実行しようとし、失敗した操作ごとにエラー表示を返します。これは、操作全体に依存関係がない場合、またはI2RSクライアントがエラーの影響を独自に整理することを希望する場合に役立ちます。
In the interest of robustness and clarity of protocol state, the protocol will include an explicit reply to modification or write operations even when they fully succeed.
プロトコル状態の堅牢性と明快さのために、プロトコルには、変更または書き込み操作が完全に成功した場合でも、明示的な応答が含まれます。
In order to facilitate troubleshooting of routing elements implementing I2RS agents, the routing elements should provide for a mechanism to show actively provisioned I2RS state and other I2RS agent internal information. Note that this information may contain highly sensitive material subject to the security considerations of any data models implemented by that agent and thus must be protected according to those considerations. Preferably, this mechanism should use a different privileged means other than simply connecting as an I2RS client to learn the data. Using a different mechanism should improve traceability and failure management.
I2RSエージェントを実装するルーティング要素のトラブルシューティングを容易にするために、ルーティング要素は、アクティブにプロビジョニングされたI2RS状態と他のI2RSエージェントの内部情報を表示するメカニズムを提供する必要があります。この情報には、そのエージェントによって実装されたデータモデルのセキュリティに関する考慮事項に従う非常に機密性の高い資料が含まれている可能性があるため、それらの考慮事項に従って保護する必要があることに注意してください。このメカニズムは、データを学習するために単にI2RSクライアントとして接続する以外に、別の特権手段を使用することが望ましいです。別のメカニズムを使用すると、トレーサビリティと障害管理が向上します。
Manageability plays a key aspect in I2RS. Some initial examples include:
I2RSでは、管理性が重要な要素です。最初の例は次のとおりです。
Resource Limitations: Using I2RS, applications can consume resources, whether those be operations in a time frame, entries in the RIB, stored operations to be triggered, etc. The ability to set resource limits based upon authorization is important.
リソースの制限：I2RSを使用すると、アプリケーションは、時間枠内の操作、RIB内のエントリ、トリガーされるストアドオペレーションなど、リソースを消費できます。承認に基づいてリソース制限を設定する機能は重要です。
Configuration Interactions: The interaction of state installed via I2RS and via a router's configuration needs to be clearly defined. As described in this architecture, a simple priority that is configured is used to provide sufficient policy flexibility.
構成の相互作用：I2RSおよびルーターの構成を介してインストールされた状態の相互作用は、明確に定義する必要があります。このアーキテクチャーで説明されているように、構成された単純な優先順位は、十分なポリシーの柔軟性を提供するために使用されます。
Traceability of Interactions: The ability to trace the interactions of the requests received by the I2RS agent's and actions taken by the I2RS agents is needed so that operations can monitor I2RS agents during deployment, and troubleshoot software or network problems.
相互作用の追跡可能性：運用中にI2RSエージェントを監視し、ソフトウェアまたはネットワークの問題をトラブルシューティングできるように、I2RSエージェントが受信した要求とI2RSエージェントが実行したアクションの相互作用を追跡する機能が必要です。
Notification Subscription Service: The ability for an I2RS client to subscribe to a notification stream pushed from the I2RS agent (rather than having I2RS client poll the I2RS agent) provides a more scalable notification handling for the I2RS agent-client interactions.
通知サブスクリプションサービス：I2RSクライアントがI2RSエージェントからプッシュされた通知ストリームにサブスクライブする機能（I2RSクライアントにI2RSエージェントをポーリングさせるのではなく）は、I2RSエージェントとクライアントの相互作用に対してよりスケーラブルな通知処理を提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7920, DOI 10.17487/RFC7920, June 2016, <http://www.rfc-editor.org/info/rfc7920>.
[RFC7920] Atlas、A.、Ed。、Nadeau、T.、Ed。、and D. Ward、 "Problem Statement for the Interface to the Routing System"、RFC 7920、DOI 10.17487 / RFC7920、June 2016、<http： //www.rfc-editor.org/info/rfc7920>。
[I2RS-ENV-SEC] Migault, D., Ed., Halpern, J., and S. Hares, "I2RS Environment Security Requirements", Work in Progress, draft-ietf-i2rs-security-environment-reqs-01, April 2016.
[I2RS-ENV-SEC] Migault、D.、Ed。、Halpern、J。、およびS. Hares、「I2RS Environment Security Requirements」、Work in Progress、draft-ietf-i2rs-security-environment-reqs-01、 2016年4月。
[I2RS-PROT-SEC] Hares, S., Migault, D., and J. Halpern, "I2RS Security Related Requirements", Work in Progress, draft-ietf-i2rs-protocol-security-requirements-06, May 2016.
[I2RS-PROT-SEC] Hares、S.、Migault、D。、およびJ. Halpern、「I2RS Security Related Requirements」、Work in Progress、draft-ietf-i2rs-protocol-security-requirements-06、May 2016。
[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", Work in Progress, draft-ietf-netconf-restconf-14, June 2016.
[RESTCONF] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONF Protocol」、Work in Progress、draft-ietf-netconf-restconf-14、2016年6月。
[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>。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、DOI 10.17487 / RFC6536、2012年3月、<http://www.rfc-editor.org/info/ rfc6536>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <http://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<http://www.rfc-editor.org/info/rfc6991>。
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>.
[RFC7223] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 7223、DOI 10.17487 / RFC7223、2014年5月、<http://www.rfc-editor.org/info/rfc7223>。
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, <http://www.rfc-editor.org/info/rfc7224>.
[RFC7224] Bjorklund、M。、「IANA Interface Type YANG Module」、RFC 7224、DOI 10.17487 / RFC7224、2014年5月、<http://www.rfc-editor.org/info/rfc7224>。
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, <http://www.rfc-editor.org/info/rfc7277>.
[RFC7277] Bjorklund、M。、「IP管理用のYANGデータモデル」、RFC 7277、DOI 10.17487 / RFC7277、2014年6月、<http://www.rfc-editor.org/info/rfc7277>。
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, <http://www.rfc-editor.org/info/rfc7317>.
[RFC7317] Bierman、A。およびM. Bjorklund、「システム管理のためのYANGデータモデル」、RFC 7317、DOI 10.17487 / RFC7317、2014年8月、<http://www.rfc-editor.org/info/rfc7317> 。
[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>。
[YANG1.1] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", Work in Progress, draft-ietf-netmod-rfc6020bis-14, June 2016.
[YANG1.1] Bjorklund、M.、Ed。、「The YANG 1.1 Data Modeling Language」、Work in Progress、draft-ietf-netmod-rfc6020bis-14、2016年6月。
Acknowledgements
謝辞
Significant portions of this draft came from "Interface to the Routing System Framework" (February 2013) and "A Policy Framework for the Interface to the Routing System" (February 2013).
このドラフトの重要な部分は、「ルーティングシステムフレームワークへのインターフェース」（2013年2月）と「ルーティングシステムへのインターフェースのポリシーフレームワーク」（2013年2月）に由来しています。
The authors would like to thank Nitin Bahadur, Shane Amante, Ed Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk, Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin Wu, Ahmed Abro, Salman Asadullah, Eric Yu, Deborah Brungard, Russ Housley, Russ White, Charlie Kaufman, Benoit Claise, Spencer Dawkins, and Stephen Farrell for their suggestions and review.
著者は、ニティン・バハドゥール、シェーン・アマンテ、エド・クラブ、ケン・グレイ、カルロス・ピニャタロ、ウェス・ジョージ、ロン・ボニカ、ジョー・クラーク、ユルゲン・シェーンヴァルダー、ジェフ・ハース、ジャマル・ハディ・サリム、スコット・ブリム、トーマス・ナルテン、ディーン・ボグダノビッチ、トムに感謝しますペッチ、ロバートラズク、スリガネシニ、ジョンマットソン、ナンシーカムウィンゲット、ダチェンチャン、キンウー、アーメドアブロ、サルマンアサドゥラ、エリックユー、デボラブランガード、ラスハウズリー、ラスホワイト、チャーリーカウフマン、ブノワクレイズ、スペンサードーキンス、そして彼らの提案とレビューのためのスティーブンファレル。
Authors' Addresses
著者のアドレス
Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States
Alia Atlas Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: akatlas@juniper.net
Joel Halpern Ericsson
ジョエル・ハルパーン・エリクソン
Email: Joel.Halpern@ericsson.com
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States
Susan Hares Huawei 7453 Hickory Hill Saline、MI 48176アメリカ合衆国
Phone: +1 734-604-0332
Email: shares@ndzh.com
Dave Ward Cisco Systems Tasman Drive San Jose, CA 95134 United States
Dave Ward Cisco Systems Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: wardd@cisco.com
Thomas D. Nadeau Brocade
トーマス・D・ナドー・ブロケード
Email: tnadeau@lucidvision.com