Network Working Group D. Meyer
Request for Comments: 4274 K. Patel
Category: Informational Cisco Systems
January 2006
Network Working Group D. Meyer
Request for Comments: 4274 K. Patel
Category: Informational Cisco Systems
January 2006
BGP-4 Protocol Analysis
BGP-4协议分析
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
本报告旨在记录边境网关协议第4版（BGP-4）如何满足将路由协议发布为互联网标准草案的要求。
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance.
本报告满足RFC 1264第6.0节所述的“第二份报告”要求。为了满足要求，本报告对RFC1774进行了扩充，总结了BGP-4的关键特性，并分析了协议的可扩展性和性能。
Table of Contents
目录
1. Introduction ....................................................2
2. Key Features and Algorithms of BGP ..............................3
2.1. Key Features ...............................................3
2.2. BGP Algorithms .............................................4
2.3. BGP Finite State Machine (FSM) .............................4
3. BGP Capabilities ................................................5
4. BGP Persistent Peer Oscillations ................................6
5. Implementation Guidelines .......................................6
6. BGP Performance Characteristics and Scalability .................6
6.1. Link Bandwidth and CPU Utilization .........................7
7. BGP Policy Expressiveness and its Implications ..................9
7.1. Existence of Unique Stable Routings .......................10
7.2. Existence of Stable Routings ..............................11
8. Applicability ..................................................12
9. Acknowledgements ...............................................12
10. Security Considerations .......................................12
11. References ....................................................13
11.1. Normative References ....................................13
11.2. Informative References ..................................14
1. Introduction ....................................................2
2. Key Features and Algorithms of BGP ..............................3
2.1. Key Features ...............................................3
2.2. BGP Algorithms .............................................4
2.3. BGP Finite State Machine (FSM) .............................4
3. BGP Capabilities ................................................5
4. BGP Persistent Peer Oscillations ................................6
5. Implementation Guidelines .......................................6
6. BGP Performance Characteristics and Scalability .................6
6.1. Link Bandwidth and CPU Utilization .........................7
7. BGP Policy Expressiveness and its Implications ..................9
7.1. Existence of Unique Stable Routings .......................10
7.2. Existence of Stable Routings ..............................11
8. Applicability ..................................................12
9. Acknowledgements ...............................................12
10. Security Considerations .......................................12
11. References ....................................................13
11.1. Normative References ....................................13
11.2. Informative References ..................................14
BGP-4 is an inter-autonomous system routing protocol designed for TCP/IP internets. Version 1 of BGP-4 was published in [RFC1105]. Since then, BGP versions 2, 3, and 4 have been developed. Version 2 was documented in [RFC1163]. Version 3 is documented in [RFC1267]. Version 4 is documented in [BGP4] (version 4 of BGP will hereafter be referred to as BGP). The changes between versions are explained in Appendix A of [BGP4]. Possible applications of BGP in the Internet are documented in [RFC1772].
BGP-4是一种为TCP/IP互联网设计的自治系统间路由协议。BGP-4的第1版发布于[RFC1105]。从那时起，BGP版本2、3和4已经开发出来。[RFC1163]中记录了版本2。[RFC1267]中记录了版本3。第4版记录在[BGP4]中（BGP第4版以下简称BGP）。[BGP4]的附录A解释了版本之间的变化。[RFC1772]中记录了BGP在互联网中的可能应用。
BGP introduced support for Classless Inter-Domain Routing (CIDR) [RFC1519]. Because earlier versions of BGP lacked the support for CIDR, they are considered obsolete and unusable in today's Internet.
BGP引入了对无类域间路由（CIDR）的支持[RFC1519]。因为早期版本的BGP缺乏对CIDR的支持，所以在今天的互联网上它们被认为是过时和不可用的。
The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
本报告旨在记录边境网关协议第4版（BGP-4）如何满足将路由协议发布为互联网标准草案的要求。
This report satisfies the requirement for "the second report", as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [RFC1774] and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance.
如[RFC1264]第6.0节所述，本报告满足“第二份报告”的要求。为了满足要求，本报告对[RFC1774]进行了扩充，总结了BGP-4的关键特性，并分析了协议的可扩展性和性能。
This section summarizes the key features and algorithms of BGP. BGP is an inter-autonomous system routing protocol; it is designed to be used between multiple autonomous systems. BGP assumes that routing within an autonomous system is done by an intra-autonomous system routing protocol. BGP also assumes that data packets are routed from source towards destination independent of the source. BGP does not make any assumptions about intra-autonomous system routing protocols deployed within the various autonomous systems. Specifically, BGP does not require all autonomous systems to run the same intra-autonomous system routing protocol (i.e., interior gateway protocol or IGP).
本节总结了BGP的关键特性和算法。BGP是一种自治系统间路由协议；它被设计用于多个自治系统之间。BGP假设自治系统内的路由由自治系统内路由协议完成。BGP还假设数据包从源路由到目的地，独立于源。BGP不对部署在各种自治系统中的自治系统内路由协议进行任何假设。具体而言，BGP不要求所有自治系统运行相同的自治系统内路由协议（即内部网关协议或IGP）。
Finally, note that BGP is a real inter-autonomous system routing protocol; and, as such, it imposes no constraints on the underlying interconnect topology of the autonomous systems. The information exchanged via BGP is sufficient to construct a graph of autonomous systems connectivity from which routing loops may be pruned, and many routing policy decisions at the autonomous system level may be enforced.
最后，请注意，BGP是一个真正的自治系统间路由协议；因此，它不会对自治系统的底层互连拓扑施加任何约束。通过BGP交换的信息足以构建自治系统连接图，从该图可以修剪路由循环，并且可以在自治系统级别强制执行许多路由策略决策。
The key features of the protocol are the notion of path attributes and aggregation of Network Layer Reachability Information (NLRI).
该协议的主要特点是路径属性的概念和网络层可达性信息（NLRI）的聚合。
Path attributes provide BGP with flexibility and extensibility. Path attributes are either well-known or optional. The provision for optional attributes allows experimentation that may involve a group of BGP routers without affecting the rest of the Internet. New optional attributes can be added to the protocol in much the same way that new options are added to, for example, the Telnet protocol [RFC854].
路径属性为BGP提供了灵活性和可扩展性。路径属性是已知的或可选的。提供可选属性允许进行可能涉及一组BGP路由器的实验，而不会影响互联网的其余部分。可以向协议添加新的可选属性，添加方式与向Telnet协议[RFC854]添加新选项的方式大致相同。
One of the most important path attributes is the Autonomous System Path, or AS_PATH. As the reachability information traverses the Internet, this (AS_PATH) information is augmented by the list of autonomous systems that have been traversed thus far, forming the AS_PATH. The AS_PATH allows straightforward suppression of the looping of routing information. In addition, the AS_PATH serves as a powerful and versatile mechanism for policy-based routing.
最重要的路径属性之一是自治系统路径或AS_路径。当可达性信息穿越互联网时，该（As_路径）信息被迄今为止已经穿越的自治系统列表所扩充，形成As_路径。AS_路径允许直接抑制路由信息的循环。此外，AS_路径还可以作为基于策略的路由的强大且通用的机制。
BGP enhances the AS_PATH attribute to include sets of autonomous systems as well as lists via the AS_SET attribute. This extended format allows generated aggregate routes to carry path information
BGP增强了AS_路径属性，通过AS_集属性包括自治系统集和列表。此扩展格式允许生成的聚合路由携带路径信息
from the more specific routes used to generate the aggregate. It should be noted, however, that as of this writing, AS_SETs are rarely used in the Internet [ROUTEVIEWS].
从用于生成聚合的更具体路由。然而，应该注意的是，在撰写本文时，as_集很少在互联网[RouteView]中使用。
BGP uses an algorithm that is neither a pure distance vector algorithm or a pure link state algorithm. Instead, it uses a modified distance vector algorithm, referred to as a "Path Vector" algorithm. This algorithm uses path information to avoid traditional distance vector problems. Each route within BGP pairs information about the destination with path information to that destination. Path information (also known as AS_PATH information) is stored within the AS_PATH attribute in BGP. The path information assists BGP in detecting AS loops, thereby allowing BGP speakers to select loop-free routes.
BGP使用的算法既不是纯距离向量算法，也不是纯链路状态算法。相反，它使用了一种改进的距离向量算法，称为“路径向量”算法。该算法利用路径信息避免了传统的距离向量问题。BGP中的每条路由将有关目标的信息与指向该目标的路径信息配对。路径信息（也称为_路径信息）存储在BGP中的as_Path属性中。路径信息有助于BGP检测AS环路，从而允许BGP扬声器选择无环路路由。
BGP uses an incremental update strategy to conserve bandwidth and processing power. That is, after initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. Such an incremental update design requires reliable transport between a pair of BGP routers in order to function correctly. BGP solves this problem by using TCP for reliable transport.
BGP使用增量更新策略来节省带宽和处理能力。也就是说，在初始交换完整的路由信息之后，一对BGP路由器只交换对该信息的更改。这种增量更新设计需要在一对BGP路由器之间进行可靠传输，以便正常运行。BGP通过使用TCP进行可靠传输来解决这个问题。
In addition to incremental updates, BGP has added the concept of route aggregation so that information about groups of destinations that use hierarchical address assignment (e.g., CIDR) may be aggregated and sent as a single Network Layer Reachability (NLRI).
除了增量更新之外，BGP还添加了路由聚合的概念，以便可以聚合使用分层地址分配（例如CIDR）的目的地组的信息，并将其作为单个网络层可达性（NLRI）发送。
Finally, note that BGP is a self-contained protocol. That is, BGP specifies how routing information is exchanged, both between BGP speakers in different autonomous systems, and between BGP speakers within a single autonomous system.
最后，请注意，BGP是一个自包含的协议。也就是说，BGP指定如何在不同自治系统中的BGP扬声器之间以及单个自治系统中的BGP扬声器之间交换路由信息。
The BGP FSM is a set of rules that is applied to a BGP speaker's set of configured peers for the BGP operation. A BGP implementation requires that a BGP speaker must connect to and listen on TCP port 179 for accepting any new BGP connections from its peers. The BGP Finite State Machine, or FSM, must be initiated and maintained for each new incoming and outgoing peer connection. However, in steady state operation, there will be only one BGP FSM per connection per peer.
BGP FSM是一组规则，应用于BGP扬声器为BGP操作配置的对等点集。BGP实现要求BGP扬声器必须连接到TCP端口179并在端口179上侦听，以接受来自对等方的任何新BGP连接。必须为每个新的传入和传出对等连接启动和维护BGP有限状态机（FSM）。但是，在稳态操作中，每个对等连接只有一个BGP FSM。
There may be a short period during which a BGP peer may have separate incoming and outgoing connections resulting in the creation of two different BGP FSMs relating to a peer (instead of one). This can be resolved by following the BGP connection collision rules defined in the [BGP4] specification.
可能会有一段短时间，在此期间，BGP对等方可能具有单独的传入和传出连接，从而导致创建与对等方相关的两个不同BGP FSM（而不是一个）。这可以通过遵循[BGP4]规范中定义的BGP连接冲突规则来解决。
The BGP FSM has the following states associated with each of its peers:
BGP FSM具有与其每个对等方关联的以下状态：
IDLE: State when BGP peer refuses any incoming connections.
IDLE：BGP对等方拒绝任何传入连接时的状态。
CONNECT: State in which BGP peer is waiting for its TCP connection to be completed.
连接：BGP对等方等待其TCP连接完成的状态。
ACTIVE: State in which BGP peer is trying to acquire a peer by listening and accepting TCP connection.
活动：BGP对等方试图通过侦听和接受TCP连接获取对等方的状态。
OPENSENT: BGP peer is waiting for OPEN message from its peer.
OPENSENT:BGP对等方正在等待来自其对等方的打开消息。
OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION message from its peer.
OPENCONFIRM:BGP对等方正在等待来自其对等方的KEEPALIVE或通知消息。
ESTABLISHED: BGP peer connection is established and exchanges UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
已建立：BGP对等连接已建立，并与其对等方交换更新、通知和保留消息。
There are a number of BGP events that operate on the above mentioned states of the BGP FSM for BGP peers. Support of these BGP events is either mandatory or optional. These events are triggered by the protocol logic as part of the BGP or by using an operator intervention via a configuration interface to the BGP protocol.
有许多BGP事件在BGP对等方的BGP FSM的上述状态下运行。对这些BGP事件的支持是强制性的或可选的。这些事件由作为BGP一部分的协议逻辑触发，或通过BGP协议的配置接口使用操作员干预触发。
These BGP events are of following types: Optional events linked to Optional Session attributes, Administrative Events, Timer Events, TCP Connection-based Events, and BGP Message-based Events. Both the FSM and the BGP events are explained in detail in [BGP4].
这些BGP事件有以下类型：链接到可选会话属性的可选事件、管理事件、计时器事件、基于TCP连接的事件和基于BGP消息的事件。[BGP4]详细解释了FSM和BGP事件。
The BGP capability mechanism [RFC3392] provides an easy and flexible way to introduce new features within the protocol. In particular, the BGP capability mechanism allows a BGP speaker to advertise to its peers during startup various optional features supported by the speaker (and receive similar information from the peers). This allows the base BGP to contain only essential functionality, while providing a flexible mechanism for signaling protocol extensions.
BGP能力机制[RFC3392]提供了在协议中引入新功能的简单而灵活的方法。特别是，BGP能力机制允许BGP演讲者在启动期间向其对等方播发演讲者支持的各种可选功能（并从对等方接收类似信息）。这允许基本BGP仅包含基本功能，同时为信令协议扩展提供灵活的机制。
Whenever a BGP speaker detects an error in a peer connection, it shuts down the peer and changes its FSM state to IDLE. BGP speaker requires a Start event to re-initiate an idle peer connection. If the error remains persistent and BGP speaker generates a Start event automatically, then it may result in persistent peer flapping. Although peer oscillation is found to be wide-spread in BGP implementations, methods for preventing persistent peer oscillations are outside the scope of base BGP specification.
每当BGP扬声器在对等连接中检测到错误时，就会关闭对等连接并将其FSM状态更改为空闲。BGP扬声器需要启动事件来重新启动空闲对等连接。如果错误持续存在且BGP speaker自动生成启动事件，则可能会导致持续的对等抖动。虽然对等振荡在BGP实现中广泛存在，但防止持续对等振荡的方法不在基本BGP规范的范围内。
A robust BGP implementation is "work conserving". This means that if the number of prefixes is bounded, arbitrarily high levels of route change can be tolerated. High levels can be tolerated with bounded impact on route convergence for occasional changes in generally stable routes.
健壮的BGP实现是“节省工作”。这意味着，如果前缀的数量是有界的，则可以容忍任意高级别的路由更改。对于一般稳定路线中的偶尔变化，可以容忍高水平，对路线收敛有一定影响。
A robust implementation of BGP should have the following characteristics:
BGP的稳健实施应具有以下特征：
1. It is able to operate in almost arbitrarily high levels of route flap without losing peerings (failing to send keepalives) or losing other protocol adjacencies as a result of BGP load.
1. 它能够在几乎任意高级别的路由中运行，而不会由于BGP负载而丢失对等（无法发送keepalives）或丢失其他协议邻接。
2. Instability of a subset of routes should not affect the route advertisements or forwarding associated with the set of stable routes.
2. 路由子集的不稳定性不应影响与稳定路由集相关联的路由播发或转发。
3. Instability should not be caused by peers with high levels of instability or with different CPU speed or load that result in faster or slower processing of routes. These instable peers should have a bounded impact on the convergence time for generally stable routes.
3. 不稳定不应由不稳定程度较高或CPU速度或负载不同导致路由处理速度更快或更慢的对等方引起。对于一般稳定的路由，这些不稳定的节点应该对收敛时间有一定的影响。
Numerous robust BGP implementations exist. Producing a robust implementation is not a trivial matter, but is clearly achievable.
存在许多健壮的BGP实现。生成健壮的实现不是一件小事，但显然是可以实现的。
In this section, we provide "order of magnitude" answers to the questions of how much link bandwidth, router memory and router CPU cycles BGP will consume under normal conditions. In particular, we will address the scalability of BGP and its limitations.
在本节中，我们提供了BGP在正常情况下消耗多少链路带宽、路由器内存和路由器CPU周期的“数量级”答案。特别是，我们将讨论BGP的可扩展性及其局限性。
Immediately after the initial BGP connection setup, BGP peers exchange complete sets of routing information. If we denote the total number of routes in the Internet as N, the total path attributes (for all N routes) received from a peer as A, and assume that the networks are uniformly distributed among the autonomous systems, then the worst-case amount of bandwidth consumed during the initial exchange between a pair of BGP speakers (P) is
初始BGP连接设置完成后，BGP对等方立即交换完整的路由信息集。如果我们将互联网中的路由总数表示为N，将从对等方接收的总路径属性（对于所有N条路由）表示为a，并假设网络均匀分布在自治系统之间，则在一对BGP扬声器（P）之间的初始交换期间消耗的最坏带宽量为
BW = O((N + A) * P)
BW = O((N + A) * P)
BGP-4 was created specifically to reduce the size of the set of NLRI entries, which has to be carried and exchanged by border routers. The aggregation scheme, defined in [RFC1519], describes the provider-based aggregation scheme in use in today's Internet.
创建BGP-4是为了减少NLRI条目集的大小，这些条目必须由边界路由器携带和交换。[RFC1519]中定义的聚合方案描述了当今互联网中使用的基于提供商的聚合方案。
Due to the advantages of advertising a few large aggregate blocks (instead of many smaller class-based individual networks), it is difficult to estimate the actual reduction in bandwidth and processing that BGP-4 has provided over BGP-3. If we simply enumerate all aggregate blocks into their individual, class-based networks, we would not take into account "dead" space that has been reserved for future expansion. The best metric for determining the success of BGP's aggregation is to sample the number NLRI entries in the globally-connected Internet today, and compare it to growth rates that were projected before BGP was deployed.
由于为几个较大的聚合块（而不是许多较小的基于类的单个网络）做广告的优势，很难估计BGP-4比BGP-3在带宽和处理方面的实际减少。如果我们简单地将所有聚合块枚举到它们各自的、基于类的网络中，我们就不会考虑为未来扩展保留的“死”空间。确定BGP聚合成功与否的最佳指标是对当前全球连接互联网中的NLRI条目的数量进行抽样，并将其与部署BGP之前预测的增长率进行比较。
At the time of this writing, the full set of exterior routes carried by BGP is approximately 134,000 network entries [ROUTEVIEWS].
在撰写本文时，BGP承载的全套外部路由约为134000个网络条目[RouteView]。
An important and fundamental feature of BGP is that BGP's CPU utilization depends only on the stability of its network which relates to BGP in terms of BGP UPDATE message announcements. If the BGP network is stable, all the BGP routers within its network are in the steady state. Thus, the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages. The KEEPALIVE messages are exchanged only between peers. The suggested frequency of the exchange is 30 seconds. The KEEPALIVE messages are quite short (19 octets) and require virtually no processing. As a result, the bandwidth consumed by the KEEPALIVE messages is about 5 bits/sec. Operational experience confirms that the overhead (in terms of bandwidth and CPU) associated with the KEEPALIVE messages should be viewed as negligible.
BGP的一个重要和基本特征是，BGP的CPU利用率仅取决于其网络的稳定性，这与BGP更新消息公告有关。如果BGP网络稳定，则其网络中的所有BGP路由器都处于稳定状态。因此，BGP消耗的唯一链路带宽和路由器CPU周期是由于交换BGP KEEPALIVE消息。KEEPALIVE消息仅在对等方之间交换。建议的交换频率为30秒。KEEPALIVE消息非常短（19个八位字节），几乎不需要处理。因此，KEEPALIVE消息消耗的带宽约为5位/秒。运营经验证实，与KEEPALIVE消息相关的开销（在带宽和CPU方面）应该可以忽略不计。
During periods of network instability, BGP routers within the network are generating routing updates that are exchanged using the BGP UPDATE messages. The greatest overhead per UPDATE message occurs when each UPDATE message contains only a single network. It should be pointed out that, in practice, routing changes exhibit strong locality with respect to the route attributes. That is, routes that change are likely to have common route attributes. In this case, multiple networks can be grouped into a single UPDATE message, thus significantly reducing the amount of bandwidth required (see also Appendix F.1 of [BGP4]).
在网络不稳定期间，网络中的BGP路由器生成路由更新，这些更新使用BGP更新消息进行交换。当每条更新消息只包含一个网络时，每条更新消息的最大开销就会出现。应该指出的是，在实践中，路由更改相对于路由属性表现出很强的局部性。也就是说，更改的路由可能具有公共路由属性。在这种情况下，可以将多个网络分组到一个更新消息中，从而显著减少所需的带宽量（另请参见[BGP4]的附录F.1）。
To quantify the worst-case memory requirements for BGP, we denote the total number of networks in the Internet as N, the mean AS distance of the Internet as M (distance at the level of an autonomous system, expressed in terms of the number of autonomous systems), the total number of unique AS paths as A. Then the worst-case memory requirements (MR) can be expressed as
为了量化BGP最坏情况下的内存需求，我们将互联网中的网络总数表示为N，互联网的平均距离表示为M（自治系统级别的距离，用自治系统的数量表示），唯一as路径的总数表示为A。然后是最坏情况内存需求（MR）可以表示为
MR = O(N + (M * A))
MR = O(N + (M * A))
Because a mean AS distance M is a slow moving function of the interconnectivity ("meshiness") of the Internet, for all practical purposes the worst-case router memory requirements are on the order of the total number of networks in the Internet multiplied by the number of peers that the local system is peering with. We expect that the total number of networks in the Internet will grow much faster than the average number of peers per router. As a result, BGP's memory-scaling properties are linearly related to the total number of networks in the Internet.
由于平均距离M是互联网互连（“网状度”）的缓慢移动函数，因此出于所有实际目的，最坏情况下的路由器内存需求是互联网中的网络总数乘以本地系统与之对等的节点数。我们预计，互联网中的网络总数将比每个路由器的平均对等数量增长得快得多。因此，BGP的内存扩展特性与Internet中的网络总数成线性关系。
The following table illustrates typical memory requirements of a
router running BGP. We denote the average number of routes
advertised by each peer as N, the total number of unique AS paths as
A, the mean AS distance of the Internet as M (distance at the level
of an autonomous system, expressed in terms of the number of
autonomous systems), the number of octets required to store a network
as R, and the number of bytes required to store one AS in an AS path
as P. It is assumed that each network is encoded as four bytes, each
AS is encoded as two bytes, and each networks is reachable via some
fraction of all the peers (# BGP peers/per net). For purposes of the
estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
The following table illustrates typical memory requirements of a
router running BGP. We denote the average number of routes
advertised by each peer as N, the total number of unique AS paths as
A, the mean AS distance of the Internet as M (distance at the level
of an autonomous system, expressed in terms of the number of
autonomous systems), the number of octets required to store a network
as R, and the number of bytes required to store one AS in an AS path
as P. It is assumed that each network is encoded as four bytes, each
AS is encoded as two bytes, and each networks is reachable via some
fraction of all the peers (# BGP peers/per net). For purposes of the
estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
# Networks Mean AS Distance # ASes # BGP peers/per net Memory Req
(N) (M) (A) (P) (MR)
---------- ---------------- ------ ------------------- -------------
100,000 20 3,000 20 10,400,000
100,000 20 15,000 20 20,000,000
120,000 10 15,000 100 78,000,000
140,000 15 20,000 100 116,000,000
# Networks Mean AS Distance # ASes # BGP peers/per net Memory Req
(N) (M) (A) (P) (MR)
---------- ---------------- ------ ------------------- -------------
100,000 20 3,000 20 10,400,000
100,000 20 15,000 20 20,000,000
120,000 10 15,000 100 78,000,000
140,000 15 20,000 100 116,000,000
In analyzing BGP's memory requirements, we focus on the size of the BGP RIB table (ignoring implementation details). In particular, we derive upper bounds for the size of the BGP RIB table. For example, at the time of this writing, the BGP RIB tables of a typical backbone router carry on the order of 120,000 entries. Given this number, one might ask whether it would be possible to have a functional router with a table containing 1,000,000 entries. Clearly, the answer to this question is more related to how BGP is implemented. A robust BGP implementation with a reasonable CPU and memory should not have issues scaling to such limits.
在分析BGP的内存需求时，我们关注BGP RIB表的大小（忽略实现细节）。特别是，我们推导了BGP RIB表大小的上界。例如，在撰写本文时，典型主干路由器的BGP RIB表包含120000个条目。考虑到这个数字，人们可能会问，是否可能有一个功能路由器，其表包含1000000个条目。显然，这个问题的答案更多地与BGP是如何实现的有关。具有合理CPU和内存的健壮BGP实现不应存在扩展到此类限制的问题。
BGP is unique among deployed IP routing protocols in that routing is determined using semantically rich routing policies. Although routing policies are usually the first BGP issue that comes to a network operator's mind, it is important to note that the languages and techniques for specifying BGP routing policies are not part of the protocol specification (see [RFC2622] for an example of such a policy language). In addition, the BGP specification contains few restrictions, explicit or implicit, on routing policy languages. These languages have typically been developed by vendors and have evolved through interactions with network engineers in an environment lacking vendor-independent standards.
BGP在部署的IP路由协议中是唯一的，因为路由是使用语义丰富的路由策略确定的。尽管路由策略通常是网络运营商想到的第一个BGP问题，但需要注意的是，用于指定BGP路由策略的语言和技术不是协议规范的一部分（此类策略语言的示例请参见[RFC2622]）。此外，BGP规范对路由策略语言几乎没有显式或隐式限制。这些语言通常由供应商开发，并在缺乏独立于供应商的标准的环境中通过与网络工程师的交互而发展。
The complexity of typical BGP configurations, at least in provider networks, has been steadily increasing. Router vendors typically provide hundreds of special commands for use in the configuration of BGP, and this command set is continually expanding. For example, BGP communities [RFC1997] allow policy writers to selectively attach tags to routes and to use these to signal policy information to other BGP-speaking routers. Many providers allow customers, and sometimes peers, to send communities that determine the scope and preference of their routes. Due to these developments, the task of writing BGP configurations has increasingly more aspects associated with open-ended programming. This has allowed network operators to encode complex policies in order to address many unforeseen situations, and has opened the door for a great deal of creativity and
典型BGP配置的复杂性（至少在提供商网络中）一直在稳步增加。路由器供应商通常提供数百个特殊命令用于BGP的配置，并且该命令集正在不断扩展。例如，BGP社区[RFC1997]允许策略编写者有选择地将标记附加到路由，并使用这些标记向其他讲BGP的路由器发送策略信息。许多提供商允许客户（有时是同行）发送社区，以确定其路线的范围和偏好。由于这些发展，编写BGP配置的任务越来越多地涉及到与开放式编程相关的方面。这使得网络运营商能够对复杂的政策进行编码，以应对许多不可预见的情况，并为大量创新和创新打开了大门
experimentation in routing policies. This policy flexibility is one of the main reasons why BGP is so well suited to the commercial environment of the current Internet.
路由策略的实验。这种政策灵活性是BGP如此适合当前互联网商业环境的主要原因之一。
However, this rich policy expressiveness has come with a cost that is often not recognized. In particular, it is possible to construct locally defined routing policies that can lead to protocol divergence and unexpected global routing anomalies such as (unintended) non-determinism. If the interacting policies causing such anomalies are defined in different autonomous systems, then these problems can be very difficult to debug and correct. In the following sections, we describe two such cases relating to the existence (or lack thereof) of stable routings.
然而，这种丰富的政策表现力带来的代价往往是不被承认的。特别是，可以构造本地定义的路由策略，这些策略可能导致协议分歧和意外的全局路由异常，例如（意外的）不确定性。如果导致这种异常的交互策略是在不同的自治系统中定义的，那么这些问题可能很难调试和纠正。在以下章节中，我们将描述两个与稳定路由的存在（或缺乏）相关的案例。
One can easily construct sets of policies for which BGP cannot guarantee that stable routings are unique. This is illustrated by the following simple example. Consider four Autonomous Systems, AS1, AS2, AS3, and AS4. AS1 and AS2 are peers, and they provide transit for AS3 and AS4, respectively. Suppose AS3 provides transit for AS4 (in this case AS3 is a customer of AS1, and AS4 is a multihomed customer of both AS3 and AS2). AS4 may want to use the link to AS3 as a "backup" link, and sends AS3 a community value that AS3 has configured to lower the preference of AS4's routes to a level below that of its upstream provider, AS1. The intended "backup routing" to AS4 is illustrated here:
我们可以很容易地构造BGP无法保证稳定路由唯一的策略集。下面的简单示例说明了这一点。考虑四个自治系统AS1、AS2、AS3和AS4。AS1和AS2是对等的，它们分别为AS3和AS4提供传输。假设AS3为AS4提供中转（在本例中，AS3是AS1的客户，AS4是AS3和AS2的多宿客户）。AS4可能希望使用到AS3的链接作为“备份”链接，并向AS3发送一个社区值，AS3已将该值配置为将AS4的路由首选项降低到低于其上游提供商AS1的级别。AS4的预期“备份路由”如下所示：
AS1 ------> AS2
/|\ |
| |
| |
| \|/
AS3 ------- AS4
AS1 ------> AS2
/|\ |
| |
| |
| \|/
AS3 ------- AS4
That is, the AS3-AS4 link is intended to be used only when the AS2- AS4 link is down (for outbound traffic, AS4 simply gives routes from AS2 a higher local preference). This is a common scenario in today's Internet. But note that this configuration has another stable solution:
也就是说，AS3-AS4链路仅在AS2-AS4链路断开时使用（对于出站流量，AS4仅为来自AS2的路由提供更高的本地偏好）。这是当今互联网上常见的情况。但请注意，此配置还有另一个稳定的解决方案：
AS1 ------- AS2
| |
| |
| |
\|/ \|/
AS3 ------> AS4
AS1 ------- AS2
| |
| |
| |
\|/ \|/
AS3 ------> AS4
In this case, AS3 does not translate the "depref my route" community received from AS4 into a "depref my route" community for AS1. Therefore, if AS1 hears the route to AS4 that transits AS3, it will prefer that route (because AS3 is a customer). This state could be reached, for example, by starting in the "correct" backup routing shown first, bringing down the AS2-AS4 BGP session, and then bringing it back up. In general, BGP has no way to prefer the "intended" solution over the anomalous one. The solution picked will depend on the unpredictable order of BGP messages.
在这种情况下，AS3不会将从AS4收到的“depref my route”社区转换为AS1的“depref my route”社区。因此，如果AS1听到到AS4的路由经过AS3，它会选择该路由（因为AS3是客户）。例如，可以通过首先显示的“正确”备份路由启动，关闭AS2-AS4 BGP会话，然后将其恢复，来达到此状态。一般来说，BGP无法选择“预期”解决方案而不是异常解决方案。选择的解决方案将取决于BGP消息的不可预测顺序。
While this example is relatively simple, many operators may fail to recognize that the true source of the problem is that the BGP policies of ASes can interact in unexpected ways, and that these interactions can result in multiple stable routings. One can imagine that the interactions could be much more complex in the real Internet. We suspect that such anomalies will only become more common as BGP continues to evolve with richer policy expressiveness. For example, extended communities provide an even more flexible means of signaling information within and between autonomous systems than is possible with [RFC1997] communities. At the same time, applications of communities by network operators are evolving to address complex issues of inter-domain traffic engineering.
虽然这个例子相对简单，但许多运营商可能没有认识到问题的真正根源是ASE的BGP策略可能以意外的方式相互作用，并且这些相互作用可能导致多个稳定路由。可以想象，在真实的互联网中，交互可能要复杂得多。我们怀疑，随着BGP继续以更丰富的政策表现力发展，这种异常现象只会变得更加普遍。例如，与[RFC1997]社区相比，扩展社区在自治系统内和自治系统之间提供了更灵活的信令信息方式。与此同时，网络运营商的社区应用正在发展，以解决域间流量工程的复杂问题。
One can also construct a set of policies for which BGP cannot guarantee that a stable routing exists (or, worse, that a stable routing will ever be found). For example, [RFC3345] documents several scenarios that lead to route oscillations associated with the use of the Multi-Exit Discriminator (MED) attribute. Route oscillation will happen in BGP when a set of policies has no solution. That is, when there is no stable routing that satisfies the constraints imposed by policy, BGP has no choice but to keep trying. In addition, even if BGP configurations can have a stable routing, the protocol may not be able to find it; BGP can "get trapped" down a blind alley that has no solution.
还可以构造一组BGP无法保证存在稳定路由（或者更糟糕的是，无法找到稳定路由）的策略。例如，[RFC3345]记录了导致与使用多出口鉴别器（MED）属性相关的路由振荡的几个场景。当一组策略没有解决方案时，BGP中会发生路由振荡。也就是说，当没有满足策略约束的稳定路由时，BGP别无选择，只能继续尝试。此外，即使BGP配置可以有一个稳定的路由，协议也可能无法找到它；BGP可能会被困在没有解决方案的死胡同中。
Protocol divergence is not, however, a problem associated solely with use of the MED attribute. This potential exists in BGP even without the use of the MED attribute. Hence, like the unintended nondeterminism described in the previous section, this type of protocol divergence is an unintended consequence of the unconstrained nature of BGP policy languages.
然而，协议分歧并不是仅与MED属性的使用相关的问题。即使不使用MED属性，BGP中也存在这种可能性。因此，与前一节中描述的意外不确定性一样，这种协议分歧是BGP策略语言的无约束性质的意外结果。
In this section we identify the environments for which BGP is well suited, and the environments for which it is not suitable. This question is partially answered in Section 2 of BGP [BGP4], which states:
在本节中，我们将确定BGP非常适合的环境和不适合的环境。BGP[BGP4]第2节部分回答了该问题，其中规定：
"To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that an AS advertises to its neighbor ASes only those routes that it itself uses. This rule reflects the "hop-by-hop" routing paradigm generally used throughout the current Internet. Note that some policies cannot be supported by the "hop-by-hop" routing paradigm and thus require techniques such as source routing to enforce. For example, BGP does not enable one AS to send traffic to a neighbor AS intending that the traffic take a different route from that taken by traffic originating in the neighbor AS. On the other hand, BGP can support any policy conforming to the "hop-by-hop" routing paradigm. Since the current Internet uses only the "hop-by-hop" routing paradigm and since BGP can support any policy that conforms to that paradigm, BGP is highly applicable as an inter-AS routing protocol for the current Internet."
“要描述可使用BGP强制执行的策略决策集，必须关注AS仅向其邻居播发其自身使用的路由的规则。此规则反映了当前Internet中普遍使用的“逐跳”路由范例。请注意，“逐跳”路由不支持某些策略路由范式，因此需要诸如源路由之类的技术来实施。例如，BGP不允许AS向邻居发送流量，因为其意图是该流量采用与源自该邻居AS的流量不同的路由。另一方面，BGP可以支持符合“逐跳”路由范式的任何策略。由于当前Internet仅使用“逐跳”路由模式，并且由于BGP可以支持符合该模式的任何策略，因此BGP非常适合作为当前Internet的as间路由协议。”
One of the important points here is that BGP contains only essential functionality, while at the same time providing a flexible mechanism within the protocol that allows us to extend its functionality. For example, BGP capabilities provide an easy and flexible way to introduce new features within the protocol. Finally, because BGP was designed to be flexible and extensible, new and/or evolving requirements can be addressed via existing mechanisms.
这里重要的一点是，BGP只包含基本功能，同时在协议中提供了一种灵活的机制，允许我们扩展其功能。例如，BGP功能提供了在协议中引入新功能的简单而灵活的方法。最后，由于BGP的设计具有灵活性和可扩展性，因此可以通过现有机制解决新的和/或不断发展的需求。
To summarize, BGP is well suited as an inter-autonomous system routing protocol for any internet that is based on IP [RFC791] as the internet protocol and the "hop-by-hop" routing paradigm.
总之，BGP非常适合作为基于IP[RFC791]作为互联网协议和“逐跳”路由范式的任何互联网的自治系统间路由协议。
We would like to thank Paul Traina for authoring previous versions of this document. Elwyn Davies, Tim Griffin, Randy Presuhn, Curtis Villamizar and Atanu Ghosh also provided many insightful comments on earlier versions of this document.
我们要感谢Paul Traina编写本文档的早期版本。Elwyn Davies、Tim Griffin、Randy Presohn、Curtis Villamizar和Atanu Ghosh也对本文件的早期版本提供了许多有见地的评论。
BGP provides flexible mechanisms with varying levels of complexity for security purposes. BGP sessions are authenticated using BGP session addresses and the assigned AS number. Because BGP sessions use TCP (and IP) for reliable transport, BGP sessions are further
出于安全目的，BGP提供了具有不同复杂度的灵活机制。BGP会话使用BGP会话地址和分配的AS编号进行身份验证。由于BGP会话使用TCP（和IP）进行可靠的传输，因此BGP会话更加安全
authenticated and secured by any authentication and security mechanisms used by TCP and IP.
通过TCP和IP使用的任何身份验证和安全机制进行身份验证和保护。
BGP uses TCP MD5 option for validating data and protecting against spoofing of TCP segments exchanged between its sessions. The usage of TCP MD5 option for BGP is described at length in [RFC2385]. The TCP MD5 Key management is discussed in [RFC3562]. BGP data encryption is provided using the IPsec mechanism, which encrypts the IP payload data (including TCP and BGP data). The IPsec mechanism can be used in both the transport mode and the tunnel mode. The IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option and the IPsec mechanism are not widely deployed security mechanisms for BGP in today's Internet. Hence, it is difficult to gauge their real performance impact when using with BGP. However, because both the mechanisms are TCP- and IP-based security mechanisms, the Link Bandwidth, CPU utilization and router memory consumed by BGP would be the same as any other TCP- and IP-based protocols.
BGP使用TCP MD5选项验证数据并防止会话之间交换的TCP段被欺骗。[RFC2385]中详细介绍了BGP的TCP MD5选项的使用。[RFC3562]中讨论了TCP MD5密钥管理。BGP数据加密使用IPsec机制提供，该机制加密IP有效负载数据（包括TCP和BGP数据）。IPsec机制可用于传输模式和隧道模式。[RFC2406]中描述了IPsec机制。TCP MD5选项和IPsec机制都不是当今互联网上广泛部署的BGP安全机制。因此，在使用BGP时，很难衡量它们对性能的实际影响。然而，由于这两种机制都是基于TCP和IP的安全机制，BGP消耗的链路带宽、CPU利用率和路由器内存将与任何其他基于TCP和IP的协议相同。
BGP uses the IP TTL value to protect its External BGP (EBGP) sessions from any TCP- or IP-based CPU-intensive attacks. It is a simple mechanism that suggests the use of filtering BGP (TCP) segments, using the IP TTL value carried within the IP header of BGP (TCP) segments that are exchanged between the EBGP sessions. The BGP TTL mechanism is described in [RFC3682]. Usage of [RFC3682] impacts performance in a similar way as using any access control list (ACL) policies for BGP.
BGP使用IP TTL值保护其外部BGP（EBGP）会话免受任何基于TCP或IP的CPU密集型攻击。这是一种简单的机制，建议使用过滤BGP（TCP）段，使用在EBGP会话之间交换的BGP（TCP）段的IP报头中携带的IP TTL值。[RFC3682]中描述了BGP TTL机制。[RFC3682]的使用影响性能的方式与对BGP使用任何访问控制列表（ACL）策略的方式类似。
Such flexible TCP- and IP-based security mechanisms, allow BGP to prevent insertion/deletion/modification of BGP data, any snooping of the data, session stealing, etc. However, BGP is vulnerable to the same security attacks that are present in TCP. The [BGP-VULN] explains in depth about the BGP security vulnerability. At the time of this writing, several efforts are underway for creating and defining an appropriate security infrastructure within the BGP protocol to provide authentication and security for its routing information; these efforts include [SBGP] and [SOBGP].
这种灵活的基于TCP和IP的安全机制允许BGP防止插入/删除/修改BGP数据、任何数据窥探、会话窃取等。但是，BGP容易受到TCP中存在的相同安全攻击。[BGP-VULN]深入解释了BGP安全漏洞。在撰写本文时，正在努力在BGP协议中创建和定义适当的安全基础设施，为其路由信息提供身份验证和安全性；这些努力包括[SBGP]和[SOBGP]。
[BGP4] Rekhter, Y., Li., T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP4]Rekhter，Y.，Li.，T.，和S.Hares，编辑，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519]Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，1996年8月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345]McPherson，D.，Gill，V.，Walton，D.，和A.Retana，“边界网关协议（BGP）持续路由振荡条件”，RFC 33452002年8月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]Gill，V.，Heasley，J.，和D.Meyer，“广义TTL安全机制（GTSM）”，RFC 3682，2004年2月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 3392，2002年11月。
[BGP-VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[BGP-VULN]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月。
[SBGP] Seo, K., S. Kent and C. Lynn, "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000, pp. 582- 592.
[SBGP]Seo，K.，S.Kent和C.Lynn，“安全边界网关协议（安全BGP）”，IEEE通信杂志第18卷，第4期，2000年4月，第582-592页。
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC854]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1105，1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1163，1990年6月。
[RFC1264] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC1264]Hinden，R.，“互联网路由协议标准化标准”，RFC 1264，1991年10月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267]Lougheed，K.和Y.Rekhter，“边境网关协议3（BGP-3）”，RFC 1267，1991年10月。
[RFC1772] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC1772]Rekhter，Y.和P.Gross，编辑，“互联网中边界网关协议的应用”，RFC 1772，1995年3月。
[RFC1774] Traina, P., "BGP-4 Protocol Analysis", RFC 1774, March 1995.
[RFC1774]Traina，P.，“BGP-4协议分析”，RFC17741995年3月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 26221999年6月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[ROUTEVIEWS] Meyer, D., "The Route Views Project", http://www.routeviews.org.
[ROUTEVIEWS]Meyer，D.，“路线视图项目”，http://www.routeviews.org.
[SOBGP] White, R., "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Work in Progress, May 2005.
[SOBGP]White，R.，“安全源BGP（SOBGP）的体系结构和部署注意事项”，正在进行的工作，2005年5月。
Authors' Addresses
作者地址
David Meyer
大卫·梅耶尔
EMail: dmm@1-4-5.net
EMail: dmm@1-4-5.net
Keyur Patel Cisco Systems
科尤尔帕特尔思科系统公司
EMail: keyupate@cisco.com
EMail: keyupate@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。