Internet Engineering Task Force (IETF) A. Atlas, Ed.
Request for Comments: 7920 Juniper Networks
Category: Informational T. Nadeau, Ed.
ISSN: 2070-1721 Brocade
D. Ward
Cisco Systems
June 2016
Internet Engineering Task Force (IETF) A. Atlas, Ed.
Request for Comments: 7920 Juniper Networks
Category: Informational T. Nadeau, Ed.
ISSN: 2070-1721 Brocade
D. Ward
Cisco Systems
June 2016
Problem Statement for the Interface to the Routing System
路由系统接口的问题陈述
Abstract
摘要
Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.
传统上，路由系统已经实现路由和信令（例如，MPLS）来控制网络中的业务转发。路由计算由定义链路成本、路由成本或导入和导出路由策略的相对静态策略控制。由于高度动态的数据中心网络、按需广域网服务、动态策略驱动的流量控制和服务链的出现，以及通过流量控制对实时安全威胁响应的需要，对路由系统的动态管理和编程提出了更高的要求，以及将基于策略的决策与路由器本身分离的范例。这些要求应允许控制路由信息和流量路径，并从路由系统中提取网络拓扑信息、流量统计和其他网络分析。
This document proposes meeting this need via an Interface to the Routing System (I2RS).
本文件建议通过与路由系统（I2RS）的接口满足这一需求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/rfc7920.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7920.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（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 ....................................................3
2. I2RS Model and Problem Area for the IETF ........................4
3. Standard Data Models of Routing State for Installation ..........6
4. Learning Router Information .....................................7
5. Aspects to be Considered for an I2RS Protocol ...................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Existing Management Interfaces .......................11
Acknowledgements ..................................................12
Authors' Addresses ................................................12
1. Introduction ....................................................3
2. I2RS Model and Problem Area for the IETF ........................4
3. Standard Data Models of Routing State for Installation ..........6
4. Learning Router Information .....................................7
5. Aspects to be Considered for an I2RS Protocol ...................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Existing Management Interfaces .......................11
Acknowledgements ..................................................12
Authors' Addresses ................................................12
Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. The advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself has created the need to more dynamically manage and program routing systems in order to control routing information and traffic paths and to extract network topology information, traffic statistics, and other network analytics from routing systems.
传统上，路由系统已经实现路由和信令（例如，MPLS）来控制网络中的业务转发。路由计算由定义链路成本、路由成本或导入和导出路由策略的相对静态策略控制。高度动态的数据中心网络、按需广域网服务、动态策略驱动的流量控制和服务链的出现，以及通过流量控制实现实时安全威胁响应的需要，而将基于策略的决策与路由器本身分离的范例使得需要更加动态地管理和编程路由系统，以控制路由信息和流量路径，并从路由系统中提取网络拓扑信息、流量统计和其他网络分析。
As modern networks continue to grow in scale and complexity and desired policy has become more complex and dynamic, there is a need to support rapid control and analytics. The scale of modern networks and data centers and the associated operational expense drives the need to automate even the simplest operations. The ability to quickly interact via more complex operations to support dynamic policy is even more critical.
随着现代网络的规模和复杂性不断增长，所需的政策变得更加复杂和动态，需要支持快速控制和分析。现代网络和数据中心的规模以及相关的运营费用使得即使是最简单的操作也需要自动化。通过更复杂的操作快速交互以支持动态策略的能力更为关键。
In order to enable network applications to have access to and control over information in the different vendors' routing systems, a publicly documented interface is required. The interface needs to support real-time, asynchronous interactions using efficient data models and encodings that are based on and extend those previously defined. Furthermore, the interface must be tailored to provide a solid base on which a variety of use cases can be supported.
为了使网络应用程序能够访问和控制不同供应商路由系统中的信息，需要一个公开记录的接口。该接口需要使用基于和扩展先前定义的高效数据模型和编码来支持实时、异步交互。此外，必须对接口进行定制，以提供支持各种用例的坚实基础。
To support the requirements of orchestration software and automated network applications to dynamically modify the network, there is a need to learn topology, network analytics, and existing state from the network as well as to create or modify routing information and network paths. A feedback loop is needed so that changes made can be verifiable and so that these applications can learn and react to network changes.
为了支持编排软件和自动化网络应用程序动态修改网络的要求，需要从网络中了解拓扑、网络分析和现有状态，以及创建或修改路由信息和网络路径。需要一个反馈回路，以便可以验证所做的更改，并使这些应用程序能够了解网络更改并作出反应。
Proprietary solutions to partially support the requirements outlined above have been developed to handle specific situations and needs. Standardizing an interface to the routing system will make it easier to integrate use of it into a network. Because there are proprietary partial solutions already, the standardization of a common interface should be feasible.
已开发出部分支持上述要求的专有解决方案，以处理特定情况和需求。标准化路由系统的接口将使其更容易集成到网络中。因为已经有专有的部分解决方案，所以通用接口的标准化应该是可行的。
It should be noted that during the course of this document, the term "applications" is used. This is meant to refer to an executable program of some sort that has access to a network, such as an IP or MPLS network, via a routing system.
应注意的是，在本文件的编写过程中，使用了“应用”一词。这是指通过路由系统访问网络（如IP或MPLS网络）的某种可执行程序。
Managing a network of systems running a variety of routing protocols and/or providing one or more additional services (e.g., forwarding, classification and policing, firewalling) involves interactions between multiple components within these systems. Some of these systems or system components may be virtualized, co-located within the same physical system, or distributed. In all cases, it is desirable to enable network applications to manage and control the services provided by many, if not all, of these components, subject to authenticated and authorized access and policies.
管理运行各种路由协议和/或提供一个或多个附加服务（例如，转发、分类和监控、防火墙）的系统网络涉及这些系统内多个组件之间的交互。其中一些系统或系统组件可能是虚拟化的、位于同一物理系统内的或分布式的。在所有情况下，都希望使网络应用程序能够管理和控制这些组件中的许多（如果不是全部的话）所提供的服务，并遵守经过身份验证和授权的访问和策略。
A data-model-driven interface to the routing system is needed. This will allow expansion of what information can be read and controlled and allow for future flexibility. At least one accompanying protocol with clearly defined operations is needed; the suitable protocol(s) can be identified and expanded to support the requirements of an Interface to the Routing System (I2RS). These solutions must be designed to facilitate rapid, isolated, secure, and dynamic changes to a device's routing system. These would facilitate wide-scale deployment of interoperable applications and routing systems.
需要路由系统的数据模型驱动接口。这将允许扩展可以读取和控制的信息，并允许将来的灵活性。至少需要一个带有明确定义操作的附带协议；可以识别和扩展合适的协议，以支持路由系统（I2RS）接口的要求。这些解决方案的设计必须便于对设备的路由系统进行快速、隔离、安全和动态的更改。这将促进可互操作应用程序和路由系统的大规模部署。
The I2RS model and problem area for IETF work is illustrated in Figure 1. This document uses terminology defined in [RFC7921]. The I2RS agent is associated with a routing element, which may or may not be co-located with a data plane. The I2RS client could be integrated in a network application or controlled and used by one or more separate network applications. For instance, an I2RS client could be provided by a network controller or a network orchestration system that provides a non-I2RS interface to network applications and an I2RS interface to I2RS agents on the systems being managed. The scope of the data models used by I2RS extends across the entire routing system and the selected protocol(s) for I2RS.
IETF工作的I2RS模型和问题区域如图1所示。本文件使用[RFC7921]中定义的术语。I2RS代理与路由元素相关联，路由元素可能与数据平面位于同一位置，也可能不与数据平面位于同一位置。I2RS客户端可以集成在网络应用程序中，也可以由一个或多个单独的网络应用程序控制和使用。例如，I2RS客户端可以由网络控制器或网络编排系统提供，该网络控制器或网络编排系统向网络应用程序提供非I2RS接口，并向被管理系统上的I2RS代理提供I2RS接口。I2RS使用的数据模型的范围扩展到整个路由系统和I2RS所选的协议。
As depicted in Figure 1, the I2RS client and I2RS agent in a routing system are objects with in the I2RS scope. The selected protocol(s) for I2RS extend between the I2RS client and I2RS agent. All other objects and interfaces in Figure 1 are outside the I2RS scope for standardization.
如图1所示，路由系统中的I2RS客户端和I2RS代理是I2RS范围内的对象。为I2RS选择的协议在I2RS客户端和I2RS代理之间扩展。图1中的所有其他对象和接口都不在I2RS标准化范围内。
+***************+ +***************+ +***************+
* Application * * Application * * Application *
+***************+ +***************+ +***************+
| I2RS Client | ^ ^
+---------------+ * *
^ * ****************
| * *
| v v
| +---------------+ +-------------+
| | I2RS Client |<------->| Other I2RS |
| +---------------+ | Agents |
| ^ +-------------+
|________________ |
| | <== I2RS Protocol
| |
...........................|..|..................................
. v v .
. +*************+ +---------------+ +****************+ .
. * Policy * | | * Routing & * .
. * Database *<***>| I2RS Agent |<****>* Signaling * .
. +*************+ | | * Protocols * .
. +---------------+ +****************+ .
. ^ ^ ^ ^ .
. +*************+ * * * * .
. * Topology * * * * * .
. * Database *<*******+ * * v .
. +*************+ * * +****************+ .
. * +********>* RIB Manager * .
. * +****************+ .
. * ^ .
. v * .
. +*******************+ * .
. * Subscription & * * .
. * Configuration * v .
. * Templates for * +****************+ .
. * Measurements, * * FIB Manager * .
. * Events, QoS, etc. * * & Data Plane * .
. +*******************+ +****************+ .
.................................................................
+***************+ +***************+ +***************+
* Application * * Application * * Application *
+***************+ +***************+ +***************+
| I2RS Client | ^ ^
+---------------+ * *
^ * ****************
| * *
| v v
| +---------------+ +-------------+
| | I2RS Client |<------->| Other I2RS |
| +---------------+ | Agents |
| ^ +-------------+
|________________ |
| | <== I2RS Protocol
| |
...........................|..|..................................
. v v .
. +*************+ +---------------+ +****************+ .
. * Policy * | | * Routing & * .
. * Database *<***>| I2RS Agent |<****>* Signaling * .
. +*************+ | | * Protocols * .
. +---------------+ +****************+ .
. ^ ^ ^ ^ .
. +*************+ * * * * .
. * Topology * * * * * .
. * Database *<*******+ * * v .
. +*************+ * * +****************+ .
. * +********>* RIB Manager * .
. * +****************+ .
. * ^ .
. v * .
. +*******************+ * .
. * Subscription & * * .
. * Configuration * v .
. * Templates for * +****************+ .
. * Measurements, * * FIB Manager * .
. * Events, QoS, etc. * * & Data Plane * .
. +*******************+ +****************+ .
.................................................................
<--> interfaces inside the scope of I2RS Protocol
<-->I2RS协议范围内的接口
+--+ objects inside the scope of I2RS-defined behavior
+--+ objects inside the scope of I2RS-defined behavior
<**> interfaces NOT within the scope of I2RS Protocol
<**> interfaces NOT within the scope of I2RS Protocol
+**+ objects NOT within the scope of I2RS-defined behavior
+**+ objects NOT within the scope of I2RS-defined behavior
<== used to point to the interface where the I2RS Protocol would be used
<==用于指向将使用I2RS协议的接口
.... boundary of a router supporting I2RS
.... boundary of a router supporting I2RS
Figure 1: I2RS Model and Problem Area
图1:I2RS模型和问题区域
The protocol(s) used to carry messages between I2RS clients and I2RS agents should provide the key features specified in Section 5.
用于在I2RS客户端和I2RS代理之间传输消息的协议应提供第5节中规定的关键功能。
I2RS will use a set of meaningful data models for information in the routing system and in a topology database. Each data model should describe the meaning and relationships of the modeled items. The data models should be separable across different features of the managed components, versioned, and extendable. As shown in Figure 1, I2RS needs to interact with several logical components of the routing element: policy database, topology database, subscription and configuration for dynamic measurements/events, routing and signaling protocols, and its Routing Information Base (RIB) manager. This interaction is both for writing (e.g., to policy databases or RIB manager) as well as for reading (e.g., dynamic measurement or topology database). An application should be able to combine data from individual routing elements to provide network-wide data model(s).
I2RS将使用一组有意义的数据模型来获取路由系统和拓扑数据库中的信息。每个数据模型都应该描述建模项的含义和关系。数据模型应可在托管组件的不同功能中分离、版本化和可扩展。如图1所示，I2RS需要与路由元素的几个逻辑组件交互：策略数据库、拓扑数据库、动态测量/事件的订阅和配置、路由和信令协议及其路由信息库（RIB）管理器。此交互既用于写入（例如，策略数据库或RIB管理器），也用于读取（例如，动态测量或拓扑数据库）。应用程序应该能够组合来自各个路由元素的数据，以提供网络范围的数据模型。
The data models should translate into a concise transfer syntax, sent via the I2RS protocol, that is straightforward for applications to use (e.g., a web services design paradigm). The information transfer should use existing transport protocols to provide the reliability, security, and timeliness appropriate for the particular data.
数据模型应转换为简洁的传输语法，通过I2RS协议发送，便于应用程序使用（例如，web服务设计范例）。信息传输应使用现有的传输协议，以提供适用于特定数据的可靠性、安全性和及时性。
As described in Section 1, there is a need to be able to precisely control routing and signaling state based upon policy or external measures. One set of data models that I2RS should focus on is for interacting with the RIB layer (e.g., RIB, Label Information Base (LIB), multicast RIB, policy-based routing) to provide flexibility and routing abstractions. As an example, the desired routing and signaling state might range from simple static routes to policy-based
如第1节所述，需要能够基于策略或外部措施精确控制路由和信令状态。I2RS应该关注的一组数据模型用于与RIB层交互（例如，RIB、标签信息库（LIB）、多播RIB、基于策略的路由），以提供灵活性和路由抽象。例如，所需的路由和信令状态可能从简单的静态路由到基于策略的路由
routing to static multicast replication and routing state. This means that, to usefully model next hops, the data model employed needs to handle next-hop indirection and recursion (e.g., a prefix X is routed like prefix Y) as well as different types of tunneling and encapsulation.
路由到静态多播复制和路由状态。这意味着，为了有效地对下一跳进行建模，所采用的数据模型需要处理下一跳间接寻址和递归（例如，前缀X像前缀Y一样路由）以及不同类型的隧道和封装。
Efforts to provide this level of control have focused on standardizing data models that describe the forwarding plane (e.g., Forwarding and Control Element Separation (ForCES) [RFC3746]). I2RS recognizes that the routing system and a router's OS provide useful mechanisms that applications could usefully harness to accomplish application-level goals. Using routing indirection, recursion, and common routing abstractions (e.g., tunnels, Label Switched Paths (LSPs), etc.) provides significant flexibility and functionality over collapsing the state to individual routes in the Forwarding Information Base (FIB) that need to be individually modified when a change occurs.
提供这一控制水平的努力集中于标准化描述转发平面的数据模型（例如，转发和控制元素分离（ForCES）[RFC3746]）。I2RS认识到路由系统和路由器的操作系统提供了有用的机制，应用程序可以利用这些机制来实现应用程序级目标。使用路由间接、递归和通用路由抽象（例如，隧道、标签交换路径（LSP）等）提供了极大的灵活性和功能性，可以将状态折叠到转发信息库（FIB）中需要在发生更改时单独修改的各个路由。
In addition to interfaces to control the RIB layer, there is a need to dynamically configure policies and parameter values for the various routing and signaling protocols based upon application-level policy decisions.
除了控制RIB层的接口外，还需要根据应用程序级策略决策动态配置各种路由和信令协议的策略和参数值。
A router has information that applications may require so that they can understand the network, verify that programmed state is installed, measure the behavior of various flows, and understand the existing configuration and state of the router. I2RS should provide a framework so that applications can register for asynchronous notifications and can make specific requests for information.
路由器具有应用程序可能需要的信息，以便它们能够了解网络、验证已安装编程状态、测量各种流的行为以及了解路由器的现有配置和状态。I2RS应该提供一个框架，以便应用程序可以注册异步通知，并可以发出特定的信息请求。
Although there are efforts to extend the topological information available, even the best of these (e.g., BGP-LS [RFC7752]) still only provide the current active state as seen at the IGP and BGP layers. Detailed topological state that provides more information than the current functional status (e.g., active paths and links) is needed by applications. Examples of missing information include paths or links that are potentially available (e.g., administratively down) or unknown (e.g., to peers or customers) to the routing topology.
尽管有人努力扩展可用的拓扑信息，但即使是最好的拓扑信息（如BGP-LS[RFC7752]）也只能提供IGP和BGP层的当前活动状态。应用程序需要提供比当前功能状态（如活动路径和链接）更多信息的详细拓扑状态。丢失信息的示例包括路由拓扑可能可用（例如，管理停机）或未知（例如，对等方或客户）的路径或链接。
For applications to have a feedback loop that includes awareness of the relevant traffic, an application must be able to request the measurement and timely, scalable reporting of data. While a mechanism such as IP Flow Information Export (IPFIX) [RFC5470] may be the facilitator for delivering the data, providing the ability for an application to dynamically request that measurements be taken and data delivered is important.
对于具有反馈循环（包括对相关流量的感知）的应用程序，应用程序必须能够请求数据的测量和及时、可伸缩的报告。虽然诸如IP流信息导出（IPFIX）[RFC5470]之类的机制可能是传递数据的促进者，但为应用程序提供动态请求进行测量和传递数据的能力非常重要。
There is a wide range of events that applications could use to support verification of router state before other network state is changed (e.g., that a route has been installed) and to allow timely action in response to changes of relevant routes by others or to router events (e.g., link up/down). While a few of these (e.g., link up/down) may be available via MIB notifications today, the full range is not (e.g., route installed, route changed, primary LSP changed, etc.)
应用程序可以使用各种各样的事件来支持在其他网络状态更改（例如，已安装路由）之前对路由器状态的验证，并允许及时响应其他方对相关路由的更改或路由器事件（例如，链路上/下）。虽然其中一些（例如，链路上/下）现在可以通过MIB通知获得，但全范围（例如，路由已安装、路由已更改、主LSP已更改等）不可用
This section describes required aspects of a protocol that could support I2RS. Whether such a protocol is built upon extending existing mechanisms or requires a new mechanism requires further investigation.
本节描述了支持I2R的协议所需的方面。这种协议是建立在扩展现有机制的基础上，还是需要一种新的机制，还需要进一步研究。
The key aspects needed in an interface to the routing system are:
路由系统接口所需的关键方面包括：
Multiple Simultaneous Asynchronous Operations: A single application should be able to send multiple independent atomic operations via I2RS without being required to wait for each to complete before sending the next.
多个同步异步操作：单个应用程序应该能够通过I2R发送多个独立的原子操作，而无需等待每个操作完成后再发送下一个操作。
Very Fine Granularity of Data Locking for Writing: When an I2RS operation is processed, it is required that the data locked for writing be very granular (e.g., a particular prefix and route) rather than extremely coarse, as is done for writing configuration. This should improve the number of concurrent I2RS operations that are feasible and reduce blocking delays.
非常精细的写入数据锁定粒度：当处理I2RS操作时，要求为写入锁定的数据非常精细（例如，特定前缀和路由），而不是像写入配置那样非常粗糙。这将提高可行的并发I2RS操作的数量，并减少阻塞延迟。
Multi-Headed Control: Multiple applications may communicate to the same I2RS agent in a minimally coordinated fashion. It is necessary that the I2RS agent can handle multiple requests in a well-known policy-based fashion. Data written can be owned by different I2RS clients at different times; data may even be overwritten by a different I2RS client. The details of how this should be handled are described in [RFC7921].
多头控制：多个应用程序可以以最小协调方式与同一I2RS代理通信。I2RS代理必须能够以众所周知的基于策略的方式处理多个请求。写入的数据可以在不同的时间归不同的I2RS客户端所有；数据甚至可能被不同的I2RS客户端覆盖。[RFC7921]中描述了如何处理此问题的详细信息。
Duplex: Communications can be established by either the I2RS client (i.e., that resides within the application or is used by it to communicate with the I2RS agent) or the I2RS agent. Similarly, events, acknowledgements, failures, operations, etc., can be sent at any time by both the router and the application. The I2RS is not a pure pull model where only the application queries to pull responses.
双工：可以由I2RS客户端（即驻留在应用程序内或由其用于与I2RS代理通信的客户端）或I2RS代理建立通信。类似地，事件、确认、故障、操作等可由路由器和应用程序随时发送。I2RS不是一个纯粹的pull模型，其中只有应用程序查询pull响应。
High Throughput: At a minimum, the I2RS agent and associated router should be able to handle a considerable number of operations per second (for example, 10,000 per second to handle many individual subscriber routes changing simultaneously).
高吞吐量：I2RS代理和相关路由器至少应能够每秒处理相当数量的操作（例如，每秒10000次以处理同时更改的多个单独订户路由）。
Low Latency: Within a sub-second timescale, it should be possible to complete simple operations (e.g., reading or writing a single prefix route).
低延迟：在亚秒的时间范围内，应该可以完成简单的操作（例如，读取或写入单个前缀路由）。
Multiple Channels: It should be possible for information to be communicated via the interface from different components in the router without requiring going through a single channel. For example, for scaling, some exported data or events may be better sent directly from the forwarding plane, while other interactions may come from the control plane. One channel, with authorization and authentication, may be considered primary; only an authorized client can then request that information be delivered on a different channel. Writes from a client are only expected on channels that provide authorization and authentication.
多通道：信息应该可以通过接口从路由器中的不同组件进行通信，而无需通过单个通道。例如，对于缩放，一些导出的数据或事件最好直接从转发平面发送，而其他交互可能来自控制平面。一个具有授权和认证的通道可被视为主要通道；然后，只有经过授权的客户才能请求通过不同的渠道传递信息。只有在提供授权和身份验证的通道上才需要从客户端写入。
Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs in an operation requesting data or requesting an asynchronous notification is very valuable.
可伸缩、可过滤的信息访问：为了以可伸缩的方式提取信息，使应用程序更容易使用，在请求数据或请求异步通知的操作中指定过滤结构的能力是非常有价值的。
Secure Control and Access: Any ability to manipulate routing state must be subject to authentication and authorization. Sensitive routing information also may need to be provided via secure access back to the I2RS client. Such communications must be integrity protected. Most communications will also require confidentiality.
安全控制和访问：任何操纵路由状态的能力都必须经过身份验证和授权。还可能需要通过安全访问返回I2RS客户端来提供敏感路由信息。此类通信必须受到完整性保护。大多数通信也需要保密。
Extensibility and Interoperability: Both the I2RS protocol and models must be extensible and interoperate between different versions of protocols and models.
可扩展性和互操作性：I2RS协议和模型都必须是可扩展的，并在不同版本的协议和模型之间进行互操作。
Security is a key aspect of any protocol that allows state installation and extracting of detailed router state. The need for secure control and access is mentioned in Section 5. More architectural security considerations are discussed in [RFC7921]. Briefly, the I2RS agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and the permissions associated with an I2RS client. Mutual authentication between the I2RS agent and I2RS client is required. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS.
安全性是任何允许状态安装和提取详细路由器状态的协议的关键方面。第5节提到了安全控制和访问的必要性。[RFC7921]中讨论了更多的体系结构安全注意事项。简单地说，假设I2RS代理具有单独的身份验证和授权通道，通过该通道它可以验证与I2RS客户端相关联的身份和权限。I2RS代理和I2RS客户端之间需要相互验证。不同级别的完整性、机密性和重播保护与I2R的不同方面相关。
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://www.rfc-editor.org/info/rfc7921>.
[RFC7921]Atlas，A.，Halpern，J.，Hares，S.，Ward，D.，和T.Nadeau，“路由系统接口架构”，RFC 7921，DOI 10.17487/RFC7921，2016年6月<http://www.rfc-editor.org/info/rfc7921>.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC3746]Yang，L.，Dantu，R.，Anderson，T.，和R.Gopal，“前进和控制分队（部队）框架”，RFC 3746，DOI 10.17487/RFC3746，2004年4月<http://www.rfc-editor.org/info/rfc3746>.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, <http://www.rfc-editor.org/info/rfc5470>.
[RFC5470]Sadasivan，G.，Brownlee，N.，Claise，B.，和J.Quitek，“IP流信息导出的体系结构”，RFC 5470，DOI 10.17487/RFC5470，2009年3月<http://www.rfc-editor.org/info/rfc5470>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，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>.
[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>.
This section discusses as a single entity the combination of the abstract data models, their representation in a data language, and the transfer protocol commonly used with them. While other combinations of these existing standard technologies are possible, the ways described are ones that have significant deployment.
本节将作为单个实体讨论抽象数据模型的组合、它们在数据语言中的表示以及常用的传输协议。虽然这些现有标准技术的其他组合是可能的，但所描述的方法具有重要的部署意义。
There are three basic ways that routers are managed. The most popular is the command-line interface (CLI), which allows both configuration and learning of device state. This is a proprietary interface resembling a UNIX shell that allows for very customized control and observation of a device, and, specifically of interest in this case, its routing system. Some form of this interface exists on almost every device (virtual or otherwise). Processing of information returned to the CLI (called "screen scraping") is a burdensome activity because the data is normally formatted for use by a human operator and because the layout of the data can vary from device to device and between different software versions. Despite its ubiquity, this interface has never been standardized and is unlikely to ever be standardized. CLI standardization is not considered as a candidate solution for the problems motivating I2RS.
管理路由器有三种基本方式。最流行的是命令行界面（CLI），它允许配置和了解设备状态。这是一个类似于UNIX shell的专有接口，允许对设备进行非常定制的控制和观察，尤其是在本例中感兴趣的设备的路由系统。这种接口的某种形式几乎存在于每个设备上（虚拟或其他）。处理返回到CLI的信息（称为“屏幕抓取”）是一项繁重的活动，因为数据通常被格式化以供人工操作员使用，而且数据的布局可能因设备和不同软件版本而异。尽管这个接口无处不在，但它从未被标准化，也不太可能被标准化。CLI标准化不被视为激发I2R的问题的候选解决方案。
The second most popular interface for interrogation of a device's state, statistics, and configuration is the Simple Network Management Protocol (SNMP) and a set of relevant standards-based and proprietary Management Information Base (MIB) modules. SNMP has a strong history of being used by network managers to gather statistical and state information about devices, including their routing systems. However, SNMP is very rarely used to configure a device or any of its systems for reasons that vary depending upon the network operator. Some example reasons include complexity, the lack of desired configuration semantics (e.g., configuration rollback, sandboxing, or configuration versioning) and the difficulty of using the semantics (or lack thereof) as defined in the MIB modules to configure device features. Therefore, SNMP is not considered as a candidate solution for the problems motivating I2RS.
查询设备状态、统计信息和配置的第二个最流行的接口是简单网络管理协议（SNMP）和一组相关的基于标准的专有管理信息库（MIB）模块。SNMP在网络管理器收集有关设备（包括其路由系统）的统计和状态信息方面有着悠久的历史。但是，SNMP很少用于配置设备或其任何系统，原因因网络运营商而异。一些示例原因包括复杂性、缺少所需的配置语义（例如，配置回滚、沙箱或配置版本控制）以及难以使用MIB模块中定义的语义（或缺少语义）来配置设备功能。因此，SNMP不被视为激发I2R的问题的候选解决方案。
Finally, the IETF's Network Configuration Protocol (NETCONF) [RFC6241] has made many strides at overcoming most of the limitations around configuration that were just described. However, as a new technology and with the initial lack of standard data models, the adoption of NETCONF has been slow. As needed, I2RS will identify and define information and data models to support I2RS applications. Additional extensions to handle multi-headed control may need to be added to NETCONF and/or appropriate data models.
最后，IETF的网络配置协议（NETCONF）[RFC6241]在克服刚才描述的大多数配置限制方面取得了很大进步。然而，作为一项新技术，由于最初缺乏标准数据模型，NETCONF的采用一直很缓慢。根据需要，I2RS将识别和定义支持I2RS应用程序的信息和数据模型。处理多头控制的附加扩展可能需要添加到NETCONF和/或适当的数据模型中。
Acknowledgements
致谢
The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah Brungard, and Sarah Banks for their suggestions and review.
作者要感谢Ken Gray、Ed Crabbe、Nic Leymann、Carlos Pignataro、Kwang Kog Lee、Linda Dunbar、Sue Hares、Russ Housley、Eric Gray、Qin Wu、Stephen Kent、Nabil Bitar、Deborah Brungard和Sarah Banks的建议和评论。
Authors' Addresses
作者地址
Alia Atlas (editor) Juniper Networks
Alia Atlas（编辑）Juniper Networks
Email: akatlas@juniper.net
Email: akatlas@juniper.net
Thomas D. Nadeau (editor) Brocade
托马斯·纳多（编辑）博科
Email: tnadeau@lucidvision.com
Email: tnadeau@lucidvision.com
Dave Ward Cisco Systems
戴夫沃德思科系统公司
Email: wardd@cisco.com
Email: wardd@cisco.com