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
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体系结构，该体系结构是一个标准的、可编程的接口，用于在Internet路由系统内外进行状态传输。它描述了高级体系结构、该高级体系结构的构建块及其接口，特别关注那些作为路由系统（I2RS）接口的一部分进行标准化的部分。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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是一个编程异步接口，用于将状态转移到Internet路由系统中或从中移出。该I2RS体系结构认识到路由系统和路由器的操作系统（OS）提供了应用程序可以利用的有用机制，以实现应用程序级目标。这些面向网络的应用程序可以利用I2RS编程接口创建新的方法，将检索Internet路由数据、分析这些数据和在路由器内设置状态结合起来。
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.
I2R的基础是清晰的数据模型，这些模型定义了可以写入和读取的信息的语义。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].
安全性是任何新i2r的关注点。第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体系结构有四个关键驱动因素。首先是需要一个编程和异步的接口，为原子操作提供快速、交互式的访问。第二是对结构化信息和状态的访问，这些信息和状态在现有的实现或配置协议中通常无法直接配置或建模。第三是能够从路由器订阅结构化、可过滤的事件通知。第四，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
这样的接口也有助于将短暂状态注入路由系统。路由器上的短暂状态是指路由设备重新启动或路由设备上处理I2RS软件的软件重新启动后无法生存的状态。非路由协议或应用程序可以通过I2RS的状态插入功能将状态注入路由元素，然后该状态可以分布在路由或信令协议和/或协议中
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仅允许通过本地配置修改状态；不设想对协议内部动态确定的数据进行直接操作。
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客户端可以提供对一个或多个应用程序的访问。该图还显示了与路由系统（动态配置、静态配置、本地配置以及路由和信令配置）相关联的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客户端可以访问一个或多个I2RS代理。在图1中，客户端B和P访问I2RS代理1和2。同样，I2RS代理可以向一个或多个客户端提供服务。在此图中，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显示了I2RS代理能够写入短暂的静态（如RIB条目）和读取动态静态（如MPLS标签交换路径标识符（LSP-ID）或活动BGP对等点的数量）。
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 *
******************************** ********************************
****************** ***************** *****************
* 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.,
* 具有转发平面和RIB管理器的路由器，运行IS-IS、OSPF、BGP、PIM等。，
* 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
* 一种标签交换路由器（LSR），其实现RSVP-TE、OSPF-TE和路径计算元件（PCE）通信协议（PCEP），并具有转发平面和相关的RIB管理器，以及
* 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.
路由和信令：此块表示实现部分Internet路由系统的路由元素部分。它不仅包括标准化协议（即IS-IS、OSPF、BGP、PIM、RSVP-TE、LDP等），还包括RIB管理层。
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代理需要访问路由子系统中包含的内容之外的路由元素上的状态。这种状态可能包括各种计数器、统计信息、流数据和本地事件。这是基于I2R的网络应用程序所需的操作状态子集，不包含在路由和信令信息中。如何将这些信息提供给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代理可以与多个客户端通信。每个客户端都可以向代理发送各种写入操作。为了使协议保持简单，两个客户端不应尝试在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.
此外，必须注意，写入操作之间可能存在间接交互。这方面的一个基本示例是，使用不同的转发行为写入两个不同但重叠的前缀。检测和避免此类交互不在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.
角色或安全角色：安全角色指定客户端或代理具有的范围、资源、优先级等。如果一个身份在安全系统中有多个角色，则允许该身份执行这些角色允许的任何操作。多个身份可以使用相同的安全角色。
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 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:
标识和范围：单个标识可以与多个角色关联。每个角色都有自己的作用域，与多个角色关联的标识可以使用其所有角色的组合作用域。更正式地说，每个身份都有：
* 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.
* 通知作用域，是与其角色关联的通知作用域的逻辑或。
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.
次要标识：I2RS客户端可以为次要标识提供次要不透明标识符，该标识符不由I2RS代理解释。当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]在管理组中使用术语“组”，该管理组支持根帐户和其他类型的特权较低的概念用户帐户之间的既定区别。“组”仍然是指由一组用户共享的单个标识（例如根）。
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层分组。短语“Internet路由系统”意味着将IP作为第3层的数据包。路由“子系统”表示路由软件/硬件只是另一个较大系统的子系统。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
多年来，人们一直在努力改进对路由和转发系统可用信息的访问。使这些信息对网络管理和应用程序可见和可用有许多众所周知的好处。这样做有两个相关的挑战。首先，潜在可用信息的数量和多样性非常大。其次，数据结构和所需操作类型的变化往往会引入协议复杂性。
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.
虽然此处考虑的操作类型在本质上是复杂的，但I2R的易部署性和健壮性至关重要。在满足已知和理解的需求所需的基础上增加复杂性将阻碍协议的易实现性、健壮性和可部署性。过于复杂的数据模型往往会通过试图描述和关闭每一个可能的选项来僵化信息集，从而使可扩展性变得复杂。
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的关键目标之一是保持协议和建模架构的简单。因此，对于每一个架构组件或方面，我们都会问自己，“我们需要这种复杂性，还是行为仅仅是一种美好的体验？”如果我们需要这种复杂性，我们应该问自己，“这是在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数据模型易于且高度可扩展以表示网络元件或网络系统的附加方面。将I2R中的数据模型与其他数据集成起来应该很容易。这加强了将数据模型设计为高度可扩展（最好是以常规和简单的方式）的重要性。
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协议的操作。当I2R的范围增加时，可以乐观地假设可能不需要更多不同的I2R。因此，重要的是不仅要考虑基础服务的数据模型的扩展性，还要考虑基元和协议操作的可扩展性。
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
I2RS的一个关键组件是标准信息和数据模型及其相关语义。虽然路由系统的许多组件都是标准化的，但它们的相关数据模型尚不可用。相反，每个路由器使用不同的信息、不同的机制和不同的CLI，这使得应用程序使用的标准接口在开发和维护时极其繁琐
maintain. Well-known data modeling languages exist and may be used for defining the data models for I2RS.
维持存在众所周知的数据建模语言，可用于定义I2R的数据模型。
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中重用的两个现有协议是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
由于I2RS体系结构的重用策略，本安全部分描述了I2RS的假定安全环境，并提供了关于a）身份和身份验证、b）授权和c）客户端冗余的其他详细信息。拟议的每项议定书
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协议和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.
首先，这里简要描述了I2R的假定安全环境。与路由元素关联的I2RS代理是该路由元素的受信任部分。例如，它可能是整个路由元素的供应商分布式签名软件映像的一部分，也可能是运营商安装的可信签名应用程序。假设I2RS代理具有单独的身份验证和授权通道，通过该通道，它可以验证与I2RS客户端关联的身份和权限。为了支持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客户端都与一个具有一组范围限制的标识相关联。使用I2RS客户端的应用程序应该知道，I2RS客户端的范围限制基于其标识（参见第4.1节）和该标识所具有的分配角色。角色对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
如果I2RS客户端充当多个应用程序的代理，则管理该通信的安全性、身份验证和授权超出范围；没有任何东西可以阻止代理使用I2RS协议和单独的身份验证和授权通道。无论采用何种机制，作为代理的I2RS客户端都要负责
determining that applications using it are trusted and permitted to make the particular requests.
确定使用它的应用程序是可信的，并允许其发出特定请求。
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.
不同级别的完整性、机密性和重播保护与I2R的不同方面相关。用于客户端身份验证然后由客户端用于写入数据的主通信通道需要完整性、机密性和重播保护。适当选择默认的所需传输协议是满足这些要求的首选方式。
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.
通过I2R进行的其他通信可能不需要完整性、保密性和重播保护。例如，如果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客户端可能代表其他应用程序运行。虽然认证或授权不需要这些应用程序的标识，但每个应用程序都应该有一个唯一的不透明标识符，I2RS客户端可以将该标识符提供给I2RS代理，以便跟踪操作归属于应用程序标识（以及从该标识到应用程序标识）。这种对应用程序操作的跟踪支持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.
所有使用I2R的操作，包括观察和操作，都应受到适当的授权控制。这种授权基于执行操作的I2RS客户端和网元中的I2RS代理的身份和分配的角色。多个标识可以使用相同的角色。如上文“身份”和“角色”的定义所述，如果多个角色与一个身份关联，则该身份被授权执行其任何角色授权的任何操作。
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客户机行事。因此，每个操作授权将基于代理本身和经过身份验证的客户端的两个权限中的较低者。在设备内应用此授权的机制不在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]中的标识可以指定为用户名或组用户名（例如，Root），该名称链接到一组访问控制规则中包含的范围策略。类似地，I2RS标识应该链接到一个角色，该角色具有一组访问控制规则指定的作用域策略。此范围策略可以通过本地配置、作为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代理的标识。
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客户端经过身份验证时，其标识将提供给I2RS代理，并且该标识链接到链接到作用域策略的角色。多个身份可能属于同一角色；例如，这样的角色可能是内部路由监视器，允许读取与AS中用于内部设备地址的IP前缀相关联的I2RS肋骨部分。
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.
I2R必须支持客户端冗余。最简单的方法是，让一个主网络应用程序和一个备份网络应用程序都使用相同的客户机标识，并且能够成功地进行身份验证，从而解决这一问题。由于I2RS不需要连续传输连接并支持多个传输会话，因此可以提供一些基本冗余。但是，它没有解决故障排除和网络更改日志记录的需要，以了解哪个网络应用程序实际处于活动状态。至少，可以使用标识记录有关每个连接和时间的基本传输信息。
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交互可能引发隐私问题的一个例子是，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客户端的代理应用程序通信。该代理应用程序需要用于面向网络的应用程序的身份验证和授权的附加功能；此类功能不在I2R的范围内，但与第4.2节所述类似的注意事项也适用。如第4.1节所述，broker I2RS客户端应该为使用它的每个面向网络的应用程序确定不同的不透明标识符。broker 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.
在第三架构中，使用I2RS客户端访问不同路由元素上的服务的路由元素或面向网络的应用程序也可以包含I2RS代理，以向其他面向网络的应用程序提供服务。然而，如果这些服务所需的信息和数据模型不同于传统路由元素的信息和数据模型，那么这些模型至少在最初不在i2r的范围之内。以下部分描述此类网络应用程序的示例。
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客户端，该客户端使用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
为了可伸缩性和通用性，I2RS代理可能负责从路由元素的各个部分收集和传递大量数据。这些部分可能是也可能不是单个物理设备的一部分。因此，为了实现可伸缩性和健壮性，该体系结构必须允许一组分布式报告组件提供从I2RS代理收集的数据
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代理。在这种情况下，它们必须具有它们所操纵的非重叠信息集。
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状态通常在检测到故障后不久或作为正常关机过程的一部分被删除。要处理这两种类型的故障，I2RS代理必须支持两种不同的通知：I2RS代理正常终止的通知，以及I2RS代理在意外故障后启动的通知。下面介绍这两个通知，然后介绍它们在意外故障和正常关机中的使用。
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.
通知\u I2RS\u代理\u终止：此通知报告关联的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.)
通知\u I2RS\u代理\u启动：此通知向I2RS客户端发出相关I2RS代理已启动的信号。它包括一个代理启动计数，该计数指示自相关路由元素重新启动以来I2RS代理重新启动的次数。代理启动计数允许I2RS客户端确定I2RS代理是否已重新启动。（注意：I2RS代理将在重新启动后向I2RS代理已知的I2RS客户端发送此通知。I2RS代理如何保留这些I2RS客户端的知识超出此体系结构的范围。）
There are two different failure types that are possible, and each has different behavior.
可能存在两种不同的故障类型，每种类型都有不同的行为。
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客户端发送一个通知。
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客户端发送终止通知。如果I2RS代理在正常终止后重新启动，它将向每个缓存的I2RS客户端发送一个启动通知。
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不同，在RIB中，多条管线以不同的首选项存储。（有关两个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).
更改可能来自本地配置或I2R。I2R存储的修改和数据独立于本地设备配置，但两者之间的冲突必须以符合操作员应用策略的确定方式解决。确定性方式是一般I2RS规则、系统规则、由操作员应用策略调整的旋钮以及与YANG数据模型相关联的规则（通常在依赖项的“必须”和“何时”子句中）的结果。
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.
这些操作员应用的策略旋钮可以通过多种方式实现。一种方法是路由元素在本地配置上配置优先级，在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。关于短暂状态，这三个路由器必须有两个操作员应用的策略旋钮。
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数据模型是否有任何与临时配置相关联的规则（例如“必须”或“何时”规则）？
For this example, there is no "MUST" or "WHEN" rule in the data being written.
在本例中，正在编写的数据中没有“必须”或“何时”规则。
The policy settings are:
策略设置包括：
Policy Knob 1 Policy Knob 2
=================== ==================
Router A ephemeral has ephemeral has
priority priority
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 ephemeral具有本地配置优先级has priority
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 | *
* +--------+ * * +--------+ *
********************************** ****************************
*************************** ************** *****************
* 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) | +------------+ *
* +-------------------+ +---------------+ *
**************************************************************
**************************************************************
* 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.
路由元素可以维护一个或多个信息库。示例包括路由信息库，如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或数据库不适用于I2R。
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的服务的协议（如BGP、LDP）（如伪线、L3VPN、L2VPN等）。这应包括有关在该路由元素中发起、传输或终止的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机制，包括影响本地路径计算和队列控制能力的旋钮。这些功能在不同的实现中差异很大，I2R无法对这些属性的全部信息收集或操作进行建模。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.
I2R在很大程度上依赖于要操作的路由元素的相关方面的信息模型。这些模型驱动I2R的数据模型和协议操作。重要的是，这些信息模型能够很好地处理路由元素的各种实际实现，如在不同的产品和不同的供应商之间所看到的。I2RS信息模型有三种方法可以解决这些变化：类或类型继承、可选特性和模板。
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从路由元素建模的信息可以用类、类型或对象来描述。可以应用不同的有效继承定义。I2R适合使用的内容在此体系结构中未确定；为简单起见，将使用“类”和“子类”作为示例术语。这种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.
例如，将流量分配给特定的服务类可以通过指定一个模板队列来完成，该模板队列中包含一个表示Gold、Silver或Best Effort的参数。如何执行的细节没有建模。这确实假设必要的模板通过I2R以外的机制在路由元素上可用。其思想是，通过为需要完成的任务提供合适的模板，并为不同类型的路由元素以不同的方式实现模板，客户机可以轻松地与路由元素交互，而无需考虑模板中包含的值所处理的变化。
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.
对象（在路由元素或其他元素中）不是孤立存在的。它们是相互关联的。类定义所做的重要事情之一是表示不同类的实例之间的关系。这些关系可能非常简单，也可能相当复杂。以下各节列出了信息模型需要支持的信息关系。
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.
最简单的关系是通过复制另一个对象实例来初始化一个对象实例。例如，可能有一个对象实例表示隧道的默认设置，如果未将所有新隧道的字段设置为建立的一部分，则所有新隧道都会从中复制字段。这与上面讨论的模板密切相关，但并不完全相同。由于关系只是暂时的，所以它通常不会在建模中正式表示，而只是在默认对象的语义描述中捕获。
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.
通常，在一个对象中指出它与第二个对象相关就足够了，而这两个对象之间没有强绑定。因此，标识符用于表示关系。这可以用于允许后期绑定或甚至不需要存在的弱绑定。对象中的策略名称可能表示，如果存在同名的策略，则在某些情况下将应用该策略。在建模中，这通常由值的类型表示。
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.
如果两个对象中的一个对象的变化总是反映在另一个对象的状态中，则对象之间的耦合形式会更强烈。例如，如果隧道具有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
该I2RS体系结构假设数据模型驱动协议，其中数据模型在YANG 1.1[YANG 1.1]和相关的基于YANG的模型文档[RFC6991]、[RFC7223]、[RFC7224]、[RFC7277]、[RFC7317]中定义。要扩展以支持I2RS协议的两个协议是NETCONF[RFC6241]和RESTCONF[RESTCONF]。这有助于实现简单性的目标，从而增强可部署性。I2RS协议可能需要使用几个底层传输（TCP、SCTP（流控制传输协议）、DCCP（数据报拥塞控制协议）），以及合适的身份验证和完整性保护机制。这些不同的传输可以支持不同类型的通信（例如，控制、读取、通知和信息收集）和不同的数据集
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.
数据无论数据交换使用何种传输方式，都必须支持合适的拥塞控制机制。选择的传输应该对操作员和实施者友好，以便于采用。
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客户机将具有唯一标识，并且可能具有辅助标识（见第2节），以帮助进行故障排除。如第4节所述，所有身份验证和授权机制都基于主标识，主标识链接到具有范围策略的角色，用于读取数据、写入数据和限制可以使用的资源。数据范围策略的规范（用于读、写或资源消耗）需要指定由策略控制的数据，以及数据的可接受值范围。
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
此类机制的一些示例包括以下内容。在一个选项中，如果特定的传输会话终止，客户端可以请求状态清理。第二个是允许状态过期，表示为与I2RS客户端的
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.
角色在策略指定的持续时间内，没有与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的另一个重要方面是，它旨在简化收集有关网络元素状态的信息。这包括获取关于网元当前状态的大量数据的快照，以及订阅对数据集或其子集的正在进行的更改的提要。由于信息速率和总容量的差异，这在体系结构上被认为是与通知分离的。
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.
尽管如此，还是会发生意外的交互，两个（或更多）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代理的具有多个操作的给定消息指示以下三种错误处理方法之一：
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.
资源限制：使用I2R，应用程序可以消耗资源，无论是时间范围内的操作、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.，和D.Ward，“路由系统接口问题声明”，RFC 7920，DOI 10.17487/RFC7920，2016年6月<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环境安全要求”，在建工程，草案-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安全相关要求”，在建工程，草案-ietf-I2RS-protocol-Security-Requirements-062016年5月。
[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协议”，正在进行的工作，草稿-ietf-netconf-RESTCONF-142016年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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（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，“网络配置协议（NETCONF）访问控制模型”，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]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年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.，“用于接口管理的YANG数据模型”，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接口类型YANG模块”，RFC 7224，DOI 10.17487/RFC72242014年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管理的杨氏数据模型”，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，“系统管理的杨数据模型”，RFC 7317，DOI 10.17487/RFC73172014年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.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，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.，“YANG 1.1数据建模语言”，正在进行的工作，草案-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
美国马萨诸塞州韦斯特福德科技园大道10号Alia Atlas Juniper Networks 01886
Email: akatlas@juniper.net
Email: akatlas@juniper.net
Joel Halpern Ericsson
乔尔·哈尔佩恩·爱立信
Email: Joel.Halpern@ericsson.com
Email: Joel.Halpern@ericsson.com
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States
Susan Hares华为7453美国密歇根州山核桃山盐碱地48176
Phone: +1 734-604-0332
Email: shares@ndzh.com
Phone: +1 734-604-0332
Email: shares@ndzh.com
Dave Ward Cisco Systems Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞市塔斯曼大道戴夫·沃德思科系统公司，邮编95134
Email: wardd@cisco.com
Email: wardd@cisco.com
Thomas D. Nadeau Brocade
托马斯·纳多·博科
Email: tnadeau@lucidvision.com
Email: tnadeau@lucidvision.com