Network Working Group P. Marques
Request for Comments: 5575 Cisco Systems
Category: Standards Track N. Sheth
Juniper Networks
R. Raszuk
Cisco Systems
B. Greene
Juniper Networks
J. Mauch
NTT America
D. McPherson
Arbor Networks
August 2009
Network Working Group P. Marques
Request for Comments: 5575 Cisco Systems
Category: Standards Track N. Sheth
Juniper Networks
R. Raszuk
Cisco Systems
B. Greene
Juniper Networks
J. Mauch
NTT America
D. McPherson
Arbor Networks
August 2009
Dissemination of Flow Specification Rules
流程规范规则的传播
Abstract
摘要
This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
本文档定义了一种新的边界网关协议网络层可达性信息（BGP NLRI）编码格式，可用于分发流量规范。这允许路由系统传播关于由IP目的地前缀定义的流量聚合的更具体组件的信息。
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.
此外，它还定义了该编码格式的两个应用程序：一个可用于自动进行域间流量过滤协调，如缓解（分布式）拒绝服务攻击所需的内容，另一个应用程序用于在BGP/MPLS VPN服务的上下文中提供流量过滤。
The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements.
信息通过BGP传输，从而重用协议算法、操作经验和管理过程，如提供商间对等协议。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions of Terms Used in This Memo ..........................5
3. Flow Specifications .............................................5
4. Dissemination of Information ....................................6
5. Traffic Filtering ..............................................12
5.1. Order of Traffic Filtering Rules ..........................13
6. Validation Procedure ...........................................14
7. Traffic Filtering Actions ......................................15
8. Traffic Filtering in BGP/MPLS VPN Networks .....................17
9. Monitoring .....................................................18
10. Security Considerations .......................................18
11. IANA Considerations ...........................................19
12. Acknowledgments ...............................................20
13. Normative References ..........................................21
1. Introduction ....................................................3
2. Definitions of Terms Used in This Memo ..........................5
3. Flow Specifications .............................................5
4. Dissemination of Information ....................................6
5. Traffic Filtering ..............................................12
5.1. Order of Traffic Filtering Rules ..........................13
6. Validation Procedure ...........................................14
7. Traffic Filtering Actions ......................................15
8. Traffic Filtering in BGP/MPLS VPN Networks .....................17
9. Monitoring .....................................................18
10. Security Considerations .......................................18
11. IANA Considerations ...........................................19
12. Acknowledgments ...............................................20
13. Normative References ..........................................21
Modern IP routers contain both the capability to forward traffic according to IP prefixes as well as to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies.
现代IP路由器既具有根据IP前缀转发流量的能力，也具有根据管理定义的策略对数据包进行分类、成形、速率限制、过滤或重定向的能力。
These traffic policy mechanisms allow the router to define match rules that operate on multiple fields of the packet header. Actions such as the ones described above can be associated with each rule.
这些流量策略机制允许路由器定义在数据包报头的多个字段上操作的匹配规则。上述操作可以与每个规则关联。
The n-tuple consisting of the matching criteria defines an aggregate traffic flow specification. The matching criteria can include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers.
由匹配条件组成的n元组定义了聚合交通流规范。匹配条件可以包括源和目标地址前缀、IP协议和传输协议端口号等元素。
This document defines a general procedure to encode flow specification rules for aggregated traffic flows so that they can be distributed as a BGP [RFC4271] NLRI. Additionally, we define the required mechanisms to utilize this definition to the problem of immediate concern to the authors: intra- and inter-provider distribution of traffic filtering rules to filter (distributed) denial-of-service (DoS) attacks.
本文档定义了一个通用程序，用于对聚合流量的流量规范规则进行编码，以便将其作为BGP[RFC4271]NLRI分发。此外，我们还定义了所需的机制，以利用此定义解决作者直接关心的问题：在提供商内部和提供商之间分发流量过滤规则以过滤（分布式）拒绝服务（DoS）攻击。
By expanding routing information with flow specifications, the routing system can take advantage of the ACL (Access Control List) or firewall capabilities in the router's forwarding path. Flow specifications can be seen as more specific routing entries to a unicast prefix and are expected to depend upon the existing unicast data information.
通过使用流规范扩展路由信息，路由系统可以利用路由器转发路径中的ACL（访问控制列表）或防火墙功能。流规范可以被看作是单播前缀的更具体的路由条目，并且期望依赖于现有的单播数据信息。
A flow specification received from an external autonomous system will need to be validated against unicast routing before being accepted. If the aggregate traffic flow defined by the unicast destination prefix is forwarded to a given BGP peer, then the local system can safely install more specific flow rules that may result in different forwarding behavior, as requested by this system.
从外部自治系统接收的流规范在被接受之前需要根据单播路由进行验证。如果由单播目的地前缀定义的聚合流量被转发到给定的BGP对等方，则本地系统可以安全地安装可能导致不同转发行为的更具体的流量规则，如该系统所请求的。
The key technology components required to address the class of problems targeted by this document are:
解决本文件所针对问题类别所需的关键技术组件包括：
1. Efficient point-to-multipoint distribution of control plane information.
1. 控制平面信息的有效点对多点分布。
2. Inter-domain capabilities and routing policy support.
2. 域间功能和路由策略支持。
3. Tight integration with unicast routing, for verification purposes.
3. 与单播路由紧密集成，用于验证目的。
Items 1 and 2 have already been addressed using BGP for other types of control plane information. Close integration with BGP also makes it feasible to specify a mechanism to automatically verify flow information against unicast routing. These factors are behind the choice of BGP as the carrier of flow specification information.
对于其他类型的控制平面信息，已经使用BGP解决了第1项和第2项。与BGP的紧密集成还可以指定一种机制，根据单播路由自动验证流信息。这些因素是选择BGP作为流规范信息载体的背后原因。
As with previous extensions to BGP, this specification makes it possible to add additional information to Internet routers. These are limited in terms of the maximum number of data elements they can hold as well as the number of events they are able to process in a given unit of time. The authors believe that, as with previous extensions, service providers will be careful to keep information levels below the maximum capacity of their devices.
与以前对BGP的扩展一样，此规范使向Internet路由器添加附加信息成为可能。在给定的时间单位内，它们可以保存的最大数据元素数量以及能够处理的事件数量都是有限的。作者相信，与以前的扩展一样，服务提供商将小心地将信息级别保持在设备的最大容量以下。
It is also expected that, in many initial deployments, flow specification information will replace existing host length route advertisements rather than add additional information.
在许多初始部署中，还预计流规范信息将取代现有的主机长度路由播发，而不是添加其他信息。
Experience with previous BGP extensions has also shown that the maximum capacity of BGP speakers has been gradually increased according to expected loads. Taking into account Internet unicast routing as well as additional applications as they gain popularity.
先前BGP扩展的经验还表明，BGP扬声器的最大容量已根据预期负载逐渐增加。考虑到互联网单播路由以及其他应用程序的普及。
From an operational perspective, the utilization of BGP as the carrier for this information allows a network service provider to reuse both internal route distribution infrastructure (e.g., route reflector or confederation design) and existing external relationships (e.g., inter-domain BGP sessions to a customer network).
从操作角度来看，利用BGP作为该信息的载体，允许网络服务提供商重用内部路由分发基础设施（例如，路由反射器或联盟设计）和现有外部关系（例如，到客户网络的域间BGP会话）。
While it is certainly possible to address this problem using other mechanisms, the authors believe that this solution offers the substantial advantage of being an incremental addition to already deployed mechanisms.
虽然使用其他机制解决这个问题当然是可能的，但作者认为，这个解决方案提供了一个实质性的优势，即对已经部署的机制进行增量添加。
In current deployments, the information distributed by the flow-spec extension is originated both manually as well as automatically. The latter by systems that are able to detect malicious flows. When automated systems are used, care should be taken to ensure their correctness as well as to limit the number and advertisement rate of flow routes.
在当前部署中，flow spec扩展分发的信息是手动和自动生成的。后者由能够检测恶意流的系统实现。使用自动化系统时，应注意确保其正确性，并限制流动路线的数量和广告率。
This specification defines required protocol extensions to address most common applications of IPv4 unicast and VPNv4 unicast filtering. The same mechanism can be reused and new match criteria added to address similar filtering needs for other BGP address families (for example, IPv6 unicast). The authors believe that those would be best to be addressed in a separate document.
本规范定义了所需的协议扩展，以解决IPv4单播和VPNv4单播过滤的最常见应用。可以重用相同的机制，并添加新的匹配条件，以满足其他BGP地址系列（例如，IPv6单播）的类似过滤需求。作者认为，最好在单独的文件中解决这些问题。
NLRI - Network Layer Reachability Information
NLRI-网络层可达性信息
RIB - Routing Information Base
路由信息库
Loc-RIB - Local RIB
局部肋骨
AS - Autonomous System number
AS-自治系统编号
VRF - Virtual Routing and Forwarding instance
VRF-虚拟路由和转发实例
PE - Provider Edge router
PE-Provider边缘路由器
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
A flow specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined flow if it matches all the specified criteria.
流规范是一个n元组，由几个可应用于IP流量的匹配条件组成。如果给定的IP数据包符合所有指定的条件，则称其符合定义的流。
A given flow may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP). Well-known or AS-specific community attributes can be used to encode a set of predetermined actions.
根据特定应用，给定流可与一组属性相关联；这些属性可能包括也可能不包括可达性信息（即，下一跳）。众所周知或特定的社区属性可用于编码一组预先确定的动作。
A particular application is identified by a specific (Address Family Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs should be treated independently from each other in order to assure non-interference between distinct applications.
特定应用程序由特定（地址族标识符、后续地址族标识符（AFI、SAFI））对[RFC4760]标识，并对应于一组不同的肋骨。这些肋条应相互独立处理，以确保不同应用之间的不干扰。
BGP itself treats the NLRI as an opaque key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent. This is consistent with existing BGP applications. For instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics being associated with them until installed in the Loc-RIB.
BGP本身将NLRI视为其数据库中某个条目的不透明密钥。然后，放置在Loc RIB中的条目与给定的语义集相关联，该语义集依赖于应用程序。这与现有的BGP应用程序一致。例如，IP单播路由（AFI=1，SAFI=1）和IP多播反向路径信息（AFI=1，SAFI=2）由BGP处理，在安装到Loc RIB之前，没有任何特定语义与它们关联。
Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix and community matching, SHOULD apply to the newly defined NLRI-type. Network operators can also control propagation of such routing updates by enabling or disabling the exchange of a particular (AFI, SAFI) pair on a given BGP peering session.
标准的BGP策略机制，例如通过NLRI前缀进行更新筛选和社区匹配，应该应用于新定义的NLRI类型。网络运营商还可以通过在给定BGP对等会话上启用或禁用特定（AFI、SAFI）对的交换来控制此类路由更新的传播。
We define a "Flow Specification" NLRI type that may include several components such as destination prefix, source prefix, protocol, ports, etc. This NLRI is treated as an opaque bit string prefix by BGP. Each bit string identifies a key to a database entry with which a set of attributes can be associated.
我们定义了一个“流规范”NLRI类型，该类型可能包括多个组件，如目标前缀、源前缀、协议、端口等。BGP将该NLRI视为不透明的位字符串前缀。每个位字符串标识一个数据库项的键，该数据库项可以与一组属性相关联。
This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in RFC 4760 [RFC4760]. Whenever the corresponding application does not require Next-Hop information, this shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI attribute and ignored on receipt.
该NLRI信息使用RFC 4760[RFC4760]中定义的MP_REACH_NLRI和MP_UNREACH_NLRI属性进行编码。当相应的应用程序不需要下一跳信息时，应在MP_REACH_NLRI属性中将其编码为0八位组长度的下一跳，并在收到时忽略。
The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1- or 2-octet NLRI length field followed by a variable-length NLRI value. The NLRI length is expressed in octets.
MP_REACH_NLRI和MP_UNREACH_NLRI的NLRI字段编码为1或2个八位组NLRI长度字段，后跟可变长度NLRI值。NLRI长度以八位字节表示。
+------------------------------+
| length (0xnn or 0xfn nn) |
+------------------------------+
| NLRI value (variable) |
+------------------------------+
+------------------------------+
| length (0xnn or 0xfn nn) |
+------------------------------+
| NLRI value (variable) |
+------------------------------+
flow-spec NLRI
流量规格NLRI
If the NLRI length value is smaller than 240 (0xf0 hex), the length field can be encoded as a single octet. Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble of the first byte is all ones.
如果NLRI长度值小于240（0xf0十六进制），则长度字段可以编码为单个八位字节。否则，它将被编码为扩展长度2八位字节值，其中第一个字节的最高有效半字节为全1。
In the figure above, values less-than 240 are encoded using two hex digits (0xnn). Values above 240 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. The value 241 is encoded as 0xf0f1.
在上图中，小于240的值使用两个十六进制数字（0xnn）进行编码。240以上的值使用3个十六进制数字（0xFNN）进行编码。此编码可以表示的最高值为4095。值241被编码为0xf0f1。
The Flow specification NLRI-type consists of several optional subcomponents. A specific packet is considered to match the flow specification when it matches the intersection (AND) of all the components present in the specification.
流量规范NLRI类型由几个可选的子组件组成。当特定数据包与规范中存在的所有组件的交叉点（和）匹配时，它被视为与流规范匹配。
The following component types are defined:
定义了以下组件类型：
Type 1 - Destination Prefix
类型1-目的地前缀
Encoding: <type (1 octet), prefix length (1 octet), prefix>
Encoding: <type (1 octet), prefix length (1 octet), prefix>
Defines the destination prefix to match. Prefixes are encoded as in BGP UPDATE messages, a length in bits is followed by enough octets to contain the prefix information.
定义要匹配的目标前缀。前缀按照BGP更新消息中的编码方式进行编码，以位为单位的长度后跟足够的八位字节以包含前缀信息。
Type 2 - Source Prefix
类型2-源前缀
Encoding: <type (1 octet), prefix-length (1 octet), prefix>
Encoding: <type (1 octet), prefix-length (1 octet), prefix>
Defines the source prefix to match.
定义要匹配的源前缀。
Type 3 - IP Protocol
类型3-IP协议
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Contains a set of {operator, value} pairs that are used to match the IP protocol value byte in IP packets.
包含一组{运算符，值}对，用于匹配IP数据包中的IP协议值字节。
The operator byte is encoded as:
运算符字节编码为：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+
Numeric operator
数字运算符
e - end-of-list bit. Set in the last {op, value} pair in the list.
e-列表结束位。在列表的最后一个{op，value}对中设置。
a - AND bit. If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It should be unset in the first operator byte of a sequence. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.
一点一滴。如果未设置，则前一项与当前项在逻辑上进行或运算。如果设置，则操作是逻辑AND。它应该在序列的第一个运算符字节中取消设置。AND运算符的优先级高于或，用于计算逻辑表达式。
len - The length of the value field for this operand is given as (1 << len).
len—此操作数的值字段的长度表示为（1<<len）。
lt - less than comparison between data and value.
lt-小于数据和值之间的比较。
gt - greater than comparison between data and value.
gt-大于数据和值之间的比较。
eq - equality between data and value.
eq-数据和值之间的相等性。
The bits lt, gt, and eq can be combined to produce "less or equal", "greater or equal", and inequality values.
比特lt、gt和eq可以组合以产生“小于或等于”、“大于或等于”和不相等值。
Type 4 - Port
类型4-端口
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs that matches source OR destination TCP/UDP ports. This list is encoded using the numeric operand format defined above. Values are encoded as 1- or 2-byte quantities.
定义与源或目标TCP/UDP端口匹配的{operation，value}对列表。此列表使用上面定义的数字操作数格式进行编码。值被编码为1字节或2字节数量。
Port, source port, and destination port components evaluate to FALSE if the IP protocol field of the packet has a value other than TCP or UDP, if the packet is fragmented and this is not the first fragment, or if the system in unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
如果数据包的IP协议字段的值不是TCP或UDP，如果数据包是分段的且不是第一个分段，或者如果系统无法定位传输标头，则端口、源端口和目标端口组件的计算结果为FALSE。在存在IP选项或封装安全有效负载（ESP）NULL[RFC4303]加密的情况下，不同的实现可能能够或可能无法解码传输报头。
Type 5 - Destination port
类型5-目的港
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the destination port of a TCP or UDP packet. Values are encoded as 1- or 2-byte quantities.
定义用于匹配TCP或UDP数据包的目标端口的{operation，value}对列表。值被编码为1字节或2字节数量。
Type 6 - Source port
类型6-源端口
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the source port of a TCP or UDP packet. Values are encoded as 1- or 2-byte quantities.
定义用于匹配TCP或UDP数据包源端口的{operation，value}对列表。值被编码为1字节或2字节数量。
Type 7 - ICMP type
类型7-ICMP类型
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the type field of an ICMP packet. Values are encoded using a single byte.
定义用于匹配ICMP数据包类型字段的{operation，value}对列表。使用单个字节对值进行编码。
The ICMP type and code specifiers evaluate to FALSE whenever the protocol value is not ICMP.
当协议值不是ICMP时，ICMP类型和代码说明符的计算结果为FALSE。
Type 8 - ICMP code
类型8-ICMP代码
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the code field of an ICMP packet. Values are encoded using a single byte.
定义用于匹配ICMP数据包的代码字段的{operation，value}对的列表。使用单个字节对值进行编码。
Type 9 - TCP flags
类型9-TCP标志
Encoding: <type (1 octet), [op, bitmask]+>
Encoding: <type (1 octet), [op, bitmask]+>
Bitmask values can be encoded as a 1- or 2-byte bitmask. When a single byte is specified, it matches byte 13 of the TCP header [RFC0793], which contains bits 8 though 15 of the 4th 32-bit word. When a 2-byte encoding is used, it matches bytes 12 and 13 of the TCP header with the data offset field having a "don't care" value.
位掩码值可以编码为1字节或2字节位掩码。当指定单个字节时，它与TCP头[RFC0793]的字节13匹配，该字节包含第4个32位字的位8到15。当使用2字节编码时，它将TCP头的字节12和13与具有“不在乎”值的数据偏移量字段相匹配。
As with port specifiers, this component evaluates to FALSE for packets that are not TCP packets.
与端口说明符一样，对于不是TCP数据包的数据包，此组件的计算结果为FALSE。
This type uses the bitmask operand format, which differs from the numeric operator format in the lower nibble.
此类型使用位掩码操作数格式，它不同于下半字节中的数字运算符格式。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+
e, a, len - Most significant nibble: (end-of-list bit, AND bit, and length field), as defined for in the numeric operator format.
e、 a，len-最高有效半字节：（列表末尾位、位和长度字段），如数字运算符格式中的定义。
not - NOT bit. If set, logical negation of operation.
不是，不是一点点。如果设置，则为操作的逻辑求反。
m - Match bit. If set, this is a bitwise match operation defined as "(data & value) == value"; if unset, (data & value) evaluates to TRUE if any of the bits in the value mask are set in the data.
m-匹配位。如果设置，这是一个按位匹配操作，定义为“（数据和值）==value”；如果未设置，则如果在数据中设置了值掩码中的任何位，（数据和值）将计算为TRUE。
Type 10 - Packet length
类型10-数据包长度
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Match on the total IP packet length (excluding Layer 2 but including IP header). Values are encoded using 1- or 2-byte quantities.
匹配总IP数据包长度（不包括第2层，但包括IP报头）。使用1字节或2字节数量对值进行编码。
Type 11 - DSCP (Diffserv Code Point)
类型11-DSCP（区分服务代码点）
Encoding: <type (1 octet), [op, value]+>
Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the 6-bit DSCP field [RFC2474]. Values are encoded using a single byte, where the two most significant bits are zero and the six least significant bits contain the DSCP value.
定义用于匹配6位DSCP字段[RFC2474]的{operation，value}对的列表。值使用单个字节编码，其中两个最高有效位为零，六个最低有效位包含DSCP值。
Type 12 - Fragment
12型-片段
Encoding: <type (1 octet), [op, bitmask]+>
Encoding: <type (1 octet), [op, bitmask]+>
Uses bitmask operand format defined above.
使用上面定义的位掩码操作数格式。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+
Bitmask values:
位掩码值：
+ Bit 7 - Don't fragment (DF)
+ 第7位-不分段（DF）
+ Bit 6 - Is a fragment (IsF)
+ 第6位-是一个片段（IsF）
+ Bit 5 - First fragment (FF)
+ 第5位-第一个片段（FF）
+ Bit 4 - Last fragment (LF)
+ 第4位-最后一个片段（LF）
Flow specification components must follow strict type ordering. A given component type may or may not be present in the specification, but if present, it MUST precede any component of higher numeric type value.
流量规格组件必须遵循严格的类型订购。给定的组件类型可能存在于规范中，也可能不存在于规范中，但如果存在，则必须位于数值类型值较高的任何组件之前。
If a given component type within a prefix in unknown, the prefix in question cannot be used for traffic filtering purposes by the receiver. Since a flow specification has the semantics of a logical AND of all components, if a component is FALSE, by definition it cannot be applied. However, for the purposes of BGP route
如果前缀中的给定组件类型未知，则接收器无法将相关前缀用于流量过滤目的。由于流规范具有逻辑和所有组件的语义，因此如果组件为FALSE，根据定义，它将无法应用。但是，出于BGP路由的目的
propagation, this prefix should still be transmitted since BGP route distribution is independent on NLRI semantics.
由于BGP路由分布独立于NLRI语义，因此仍应传输此前缀。
The <type, value> encoding is chosen in order to account for future extensibility.
选择<type，value>编码是为了考虑将来的扩展性。
An example of a flow specification encoding for: "all packets to 10.0.1/24 and TCP port 25".
流规范编码示例：“所有数据包到10.0.1/24和TCP端口25”。
+------------------+----------+----------+
| destination | proto | port |
+------------------+----------+----------+
| 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 |
+------------------+----------+----------+
+------------------+----------+----------+
| destination | proto | port |
+------------------+----------+----------+
| 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 |
+------------------+----------+----------+
Decode for protocol:
对协议进行解码：
+-------+----------+------------------------------+
| Value | | |
+-------+----------+------------------------------+
| 0x03 | type | |
| 0x81 | operator | end-of-list, value size=1, = |
| 0x06 | value | |
+-------+----------+------------------------------+
+-------+----------+------------------------------+
| Value | | |
+-------+----------+------------------------------+
| 0x03 | type | |
| 0x81 | operator | end-of-list, value size=1, = |
| 0x06 | value | |
+-------+----------+------------------------------+
An example of a flow specification encoding for: "all packets to 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}".
流规范编码的示例：“从192/8和端口{range[137，139]或8080}到10.0.1/24的所有数据包”。
+------------------+----------+-------------------------+
| destination | source | port |
+------------------+----------+-------------------------+
| 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
+------------------+----------+-------------------------+
+------------------+----------+-------------------------+
| destination | source | port |
+------------------+----------+-------------------------+
| 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
+------------------+----------+-------------------------+
Decode for port:
对端口进行解码：
+--------+----------+------------------------------+
| Value | | |
+--------+----------+------------------------------+
| 0x04 | type | |
| 0x03 | operator | size=1, >= |
| 0x89 | value | 137 |
| 0x45 | operator | &, value size=1, <= |
| 0x8b | value | 139 |
| 0x91 | operator | end-of-list, value-size=2, = |
| 0x1f90 | value | 8080 |
+--------+----------+------------------------------+
+--------+----------+------------------------------+
| Value | | |
+--------+----------+------------------------------+
| 0x04 | type | |
| 0x03 | operator | size=1, >= |
| 0x89 | value | 137 |
| 0x45 | operator | &, value size=1, <= |
| 0x8b | value | 139 |
| 0x91 | operator | end-of-list, value-size=2, = |
| 0x1f90 | value | 8080 |
+--------+----------+------------------------------+
This constitutes an NLRI with an NLRI length of 16 octets.
这构成一个NLRI，NLRI长度为16个八位字节。
Implementations wishing to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in RFC 4760 [RFC4760]. The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be the same as the one used to identify a particular application that uses this NLRI-type.
希望交换流规范规则的实现必须使用BGP的能力公告功能来交换RFC 4760[RFC4760]中定义的多协议扩展能力代码（代码1）。多协议扩展功能中携带的（AFI，SAFI）对必须与用于标识使用此NLRI类型的特定应用程序的（AFI，SAFI）对相同。
Traffic filtering policies have been traditionally considered to be relatively static.
传统上，流量过滤策略被认为是相对静态的。
The popularity of traffic-based, denial-of-service (DoS) attacks, which often requires the network operator to be able to use traffic filters for detection and mitigation, brings with it requirements that are not fully satisfied by existing tools.
基于流量的拒绝服务（DoS）攻击的流行，通常要求网络运营商能够使用流量过滤器进行检测和缓解，带来了现有工具无法完全满足的需求。
Increasingly, DoS mitigation requires coordination among several service providers in order to be able to identify traffic source(s) and because the volumes of traffic may be such that they will otherwise significantly affect the performance of the network.
DoS缓解越来越需要多个服务提供商之间的协调，以便能够识别流量源，因为流量可能会严重影响网络的性能。
Several techniques are currently used to control traffic filtering of DoS attacks. Among those, one of the most common is to inject unicast route advertisements corresponding to a destination prefix being attacked. One variant of this technique marks such route advertisements with a community that gets translated into a discard Next-Hop by the receiving router. Other variants attract traffic to a particular node that serves as a deterministic drop point.
目前有几种技术用于控制DoS攻击的流量过滤。其中，最常见的方法之一是注入与被攻击的目的地前缀相对应的单播路由广告。这种技术的一种变体是使用一个社区来标记这种路由广告，该社区被接收路由器转换为丢弃下一跳。其他变体将流量吸引到充当确定性下降点的特定节点。
Using unicast routing advertisements to distribute traffic filtering information has the advantage of using the existing infrastructure and inter-AS communication channels. This can allow, for instance, a service provider to accept filtering requests from customers for address space they own.
使用单播路由广告来分发流量过滤信息具有使用现有基础设施和内部AS通信信道的优点。例如，这可以允许服务提供商接受客户对其拥有的地址空间的过滤请求。
There are several drawbacks, however. An issue that is immediately apparent is the granularity of filtering control: only destination prefixes may be specified. Another area of concern is the fact that filtering information is intermingled with routing information.
然而，有几个缺点。一个显而易见的问题是过滤控制的粒度：只能指定目标前缀。另一个值得关注的领域是，过滤信息与路由信息混杂在一起。
The mechanism defined in this document is designed to address these limitations. We use the flow specification NLRI defined above to convey information about traffic filtering rules for traffic that should be discarded.
本文件中定义的机制旨在解决这些限制。我们使用上面定义的流规范NLRI来传递关于应该丢弃的流量的流量过滤规则的信息。
This mechanism is primarily designed to allow an upstream autonomous system to perform inbound filtering in their ingress routers of traffic that a given downstream AS wishes to drop.
该机制主要设计用于允许上游自治系统在其入口路由器中对给定下游想要丢弃的流量执行入站过滤。
In order to achieve this goal, we define an application-specific NLRI identifier (AFI=1, SAFI=133) along with specific semantic rules.
为了实现这一目标，我们定义了一个特定于应用程序的NLRI标识符（AFI=1，SAFI=133）以及特定的语义规则。
BGP routing updates containing this identifier use the flow specification NLRI encoding to convey particular aggregated flows that require special treatment.
包含此标识符的BGP路由更新使用流规范NLRI编码来传递需要特殊处理的特定聚合流。
Flow routing information received via this (AFI, SAFI) pair is subject to the validation procedure detailed below.
通过该（AFI，SAFI）对接收的流量路由信息应遵循以下详细验证程序。
With traffic filtering rules, more than one rule may match a particular traffic flow. Thus, it is necessary to define the order at which rules get matched and applied to a particular traffic flow. This ordering function must be such that it must not depend on the arrival order of the flow specification's rules and must be constant in the network.
使用流量过滤规则，可以有多个规则与特定流量相匹配。因此，有必要定义规则匹配和应用于特定交通流的顺序。该排序函数必须不依赖于流规范规则的到达顺序，并且必须在网络中保持不变。
The relative order of two flow specification rules is determined by comparing their respective components. The algorithm starts by comparing the left-most components of the rules. If the types differ, the rule with lowest numeric type value has higher precedence (and thus will match before) than the rule that doesn't contain that component type. If the component types are the same, then a type-specific comparison is performed.
通过比较两个流规范规则各自的组件，确定其相对顺序。该算法首先比较规则中最左边的部分。如果类型不同，则具有最低数值类型值的规则比不包含该组件类型的规则具有更高的优先级（因此将在之前匹配）。如果组件类型相同，则执行特定于类型的比较。
For IP prefix values (IP destination and source prefix) precedence is given to the lowest IP value of the common prefix length; if the common prefix is equal, then the most specific prefix has precedence.
对于IP前缀值（IP目的地和源前缀），优先于公共前缀长度的最低IP值；如果公共前缀相等，则最特定的前缀具有优先权。
For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by the ISO C standard. For strings of different lengths, the common prefix is compared. If equal, the longest string is considered to have higher precedence than the shorter one.
对于所有其他组件类型，除非另有规定，否则通过使用ISO C标准定义的memcmp（）函数将组件数据作为二进制字符串进行比较来执行比较。对于不同长度的字符串，比较公共前缀。如果相等，则认为最长字符串的优先级高于较短字符串。
Pseudocode:
伪代码：
flow_rule_cmp (a, b)
{
comp1 = next_component(a);
comp2 = next_component(b);
while (comp1 || comp2) {
// component_type returns infinity on end-of-list
if (component_type(comp1) < component_type(comp2)) {
return A_HAS_PRECEDENCE;
}
if (component_type(comp1) > component_type(comp2)) {
return B_HAS_PRECEDENCE;
}
flow_rule_cmp (a, b)
{
comp1 = next_component(a);
comp2 = next_component(b);
while (comp1 || comp2) {
// component_type returns infinity on end-of-list
if (component_type(comp1) < component_type(comp2)) {
return A_HAS_PRECEDENCE;
}
if (component_type(comp1) > component_type(comp2)) {
return B_HAS_PRECEDENCE;
}
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) {
common = MIN(prefix_length(comp1), prefix_length(comp2));
cmp = prefix_compare(comp1, comp2, common);
// not equal, lowest value has precedence
// equal, longest match has precedence
} else {
common =
MIN(component_length(comp1), component_length(comp2));
cmp = memcmp(data(comp1), data(comp2), common);
// not equal, lowest value has precedence
// equal, longest string has precedence
}
}
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) {
common = MIN(prefix_length(comp1), prefix_length(comp2));
cmp = prefix_compare(comp1, comp2, common);
// not equal, lowest value has precedence
// equal, longest match has precedence
} else {
common =
MIN(component_length(comp1), component_length(comp2));
cmp = memcmp(data(comp1), data(comp2), common);
// not equal, lowest value has precedence
// equal, longest string has precedence
}
}
return EQUAL;
}
return EQUAL;
}
Flow specifications received from a BGP peer and that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of two routes for the same flow specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise.
从BGP对等方接收并在各自的Adj RIB in中接受的流量规格用作路线选择过程的输入。虽然同一流规范前缀的两条路由的转发属性可能相同，但BGP仍需要执行其路径选择算法，以便选择要播发的正确属性集。
The first step of the BGP Route Selection procedure (Section 9.1.2 of [RFC4271]) is to exclude from the selection procedure routes that are considered non-feasible. In the context of IP routing information, this step is used to validate that the NEXT_HOP attribute of a given route is resolvable.
BGP路由选择程序的第一步（RFC4271第9.1.2节）是将被认为不可行的路由排除在选择程序之外。在IP路由信息的上下文中，此步骤用于验证给定路由的下一跳属性是否可解析。
The concept can be extended, in the case of flow specification NLRI, to allow other validation procedures.
在流量规范NLRI的情况下，可以扩展该概念，以允许其他验证程序。
A flow specification NLRI must be validated such that it is considered feasible if and only if:
必须对流量规范NLRI进行验证，以确保其在以下情况下可行：
a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.
a) 流规范的发起者为嵌入在流规范中的目的地前缀匹配最佳匹配单播路由的发起者。
b) There are no more specific unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in step a).
b) 与流目的地前缀相比，从不同的相邻AS接收到的特定单播路由不比在步骤a）中确定的最佳匹配单播路由更多。
By originator of a BGP route, we mean either the BGP originator path attribute, as used by route reflection, or the transport address of the BGP peer, if this path attribute is not present.
所谓BGP路由的发起者，我们指的是路由反射使用的BGP发起者路径属性，或者BGP对等方的传输地址（如果该路径属性不存在）。
The underlying concept is that the neighboring AS that advertises the best unicast route for a destination is allowed to advertise flow-spec information that conveys a more or equally specific destination prefix. Thus, as long as there are no more specific unicast routes, received from a different neighboring AS, which would be affected by that filtering rule.
基本概念是，允许为目的地播发最佳单播路由的相邻AS播发传递更多或同等特定目的地前缀的流规范信息。因此，只要不存在从不同的相邻as接收的更具体的单播路由，其将受到该过滤规则的影响。
The neighboring AS is the immediate destination of the traffic described by the flow specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it.
相邻AS是流量规范中描述的流量的直接目的地。如果它请求删除这些流，则可以满足该请求，而不必担心它本身表示拒绝服务。据推测，流量正在被下游自治系统丢弃，而将流量传送到下游自治系统并没有任何附加值。
BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it for security reasons.
BGP实现还必须强制通过外部边界网关协议（eBGP）接收的路由的AS_路径属性包含位于AS_路径属性最左侧位置的相邻AS。虽然此规则在BGP规范中是可选的，但出于安全原因，有必要强制执行此规则。
This specification defines a minimum set of filtering actions that it standardizes as BGP extended community values [RFC4360]. This is not meant to be an inclusive list of all the possible actions, but only a subset that can be interpreted consistently across the network.
本规范定义了一组最小的过滤操作，并将其标准化为BGP扩展社区值[RFC4360]。这并不意味着包含所有可能的操作，而只是可以在整个网络中一致解释的子集。
Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to filtering actions that require different mappings in different systems in the network. For instance, providing packets with a worse-than-best-effort, per-hop behavior is a functionality that is likely to be implemented differently in different systems and for which no standard behavior is currently known. Rather than attempting to define it here, this can be accomplished by mapping a user-defined community value to platform-/network-specific behavior via user configuration.
实现应提供将任意BGP社区值（正常或扩展）映射到网络中不同系统中需要不同映射的过滤操作的机制。例如，以比最佳努力更差的方式提供数据包，每跳行为是一种可能在不同系统中以不同方式实现的功能，目前还没有已知的标准行为。这可以通过用户配置将用户定义的社区价值映射到特定于平台/网络的行为来实现，而不是试图在这里定义它。
The default action for a traffic filtering flow specification is to accept IP traffic that matches that particular rule.
流量过滤流规范的默认操作是接受与该特定规则匹配的IP流量。
The following extended community values can be used to specify particular actions.
以下扩展社区值可用于指定特定操作。
+--------+--------------------+--------------------------+
| type | extended community | encoding |
+--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action | bitmask |
| 0x8008 | redirect | 6-byte Route Target |
| 0x8009 | traffic-marking | DSCP value |
+--------+--------------------+--------------------------+
+--------+--------------------+--------------------------+
| type | extended community | encoding |
+--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action | bitmask |
| 0x8008 | redirect | 6-byte Route Target |
| 0x8009 | traffic-marking | DSCP value |
+--------+--------------------+--------------------------+
Traffic-rate: The traffic-rate extended community is a non-transitive extended community across the autonomous-system boundary and uses following extended community encoding:
流量率：流量率扩展社区是跨越自治系统边界的非传递性扩展社区，并使用以下扩展社区编码：
The first two octets carry the 2-octet id, which can be assigned from a 2-byte AS number. When a 4-byte AS number is locally present, the 2 least significant bytes of such an AS number can be used. This value is purely informational and should not be interpreted by the implementation.
前两个八位字节携带2个八位字节id，可以从2字节作为数字分配。当本地存在4字节AS编号时，可以使用此类AS编号的2个最低有效字节。此值纯粹是信息性的，不应由实现进行解释。
The remaining 4 octets carry the rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded.
其余4个八位字节以IEEE浮点[IEEE.754.1985]格式携带速率信息，单位为每秒字节。对于要丢弃的特定流，所有流量的流量率应为0。
Traffic-action: The traffic-action extended community consists of 6 bytes of which only the 2 least significant bits of the 6th byte (from left to right) are currently defined.
Traffic action：Traffic action extended community由6个字节组成，其中当前仅定义了第6个字节（从左到右）中的2个最低有效位。
40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+
| reserved | S | T |
+---+---+---+---+---+---+---+---+
40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+
| reserved | S | T |
+---+---+---+---+---+---+---+---+
* Terminal Action (bit 47): When this bit is set, the traffic filtering engine will apply any subsequent filtering rules (as defined by the ordering procedure). If not set, the evaluation of the traffic filter stops when this rule is applied.
* 终端操作（位47）：当设置此位时，流量过滤引擎将应用任何后续过滤规则（由订购程序定义）。如果未设置，则应用此规则时，流量过滤器的评估将停止。
* Sample (bit 46): Enables traffic sampling and logging for this flow specification.
* 样本（位46）：启用此流量规范的流量采样和日志记录。
Redirect: The redirect extended community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the Route Target extended community [RFC4360].
重定向：重定向扩展社区允许将流量重定向到VRF路由实例，该实例在其导入策略中列出指定的路由目标。如果多个本地实例符合此条件，则它们之间的选择是本地问题（例如，可以选择具有最低路由区分器值的实例）。此扩展社区使用与路由目标扩展社区[RFC4360]相同的编码。
Traffic Marking: The traffic marking extended community instructs a system to modify the DSCP bits of a transiting IP packet to the corresponding value. This extended community is encoded as a sequence of 5 zero bytes followed by the DSCP value encoded in the 6 least significant bits of 6th byte.
流量标记：流量标记扩展社区指示系统将传输IP数据包的DSCP位修改为相应的值。该扩展社区被编码为5个零字节的序列，后跟在第6字节的6个最低有效位中编码的DSCP值。
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ MPLS IP VPN [RFC4364] control plane, have different traffic filtering requirements than Internet service providers.
基于提供商的第3层VPN网络，例如使用BGP/MPLS IP VPN[RFC4364]控制平面的网络，与Internet服务提供商具有不同的流量过滤要求。
In these environments, the VPN customer network often has traffic filtering capabilities towards their external network connections (e.g., firewall facing public network connection). Less common is the presence of traffic filtering capabilities between different VPN attachment sites. In an any-to-any connectivity model, which is the default, this means that site-to-site traffic is unfiltered.
在这些环境中，VPN客户网络通常具有针对其外部网络连接的流量过滤功能（例如，面向防火墙的公共网络连接）。不太常见的是不同VPN连接站点之间存在流量过滤功能。在任意对任意连接模型（默认）中，这意味着未过滤站点到站点的流量。
In circumstances where a security threat does get propagated inside the VPN customer network, there may not be readily available mechanisms to provide mitigation via traffic filter.
在安全威胁确实在VPN客户网络内传播的情况下，可能没有现成的机制通过流量过滤器提供缓解措施。
This document proposes an additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used to propagate traffic filtering information in a BGP/MPLS VPN environment.
本文档提出了一个额外的BGP NLRI类型（AFI=1，SAFI=134）值，可用于在BGP/MPLS VPN环境中传播流量过滤信息。
The NLRI format for this address family consists of a fixed-length Route Distinguisher field (8 bytes) followed by a flow specification, following the encoding defined in this document. The NLRI length field shall include both the 8 bytes of the Route Distinguisher as well as the subsequent flow specification.
此地址族的NLRI格式由一个固定长度的路由标识符字段（8字节）组成，后跟一个流规范，遵循本文档中定义的编码。NLRI长度字段应包括路由识别器的8个字节以及后续流量规范。
Propagation of this NLRI is controlled by matching Route Target extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as described in "BGP/ MPLS IP VPNs" [RFC4364] .
此NLRI的传播通过使用“BGP/MPLS IP VPN”[RFC4364]中描述的相同机制，将与BGP路径公告相关联的路由目标扩展社区与VRF导入策略相匹配来控制。
Flow specification rules received via this NLRI apply only to traffic that belongs to the VRF(s) in which it is imported. By default, traffic received from a remote PE is switched via an MPLS forwarding decision and is not subject to filtering.
通过此NLRI接收的流量规范规则仅适用于属于其导入的VRF的流量。默认情况下，从远程PE接收的流量通过MPLS转发决策进行切换，并且不受过滤的影响。
Contrary to the behavior specified for the non-VPN NLRI, flow rules are accepted by default, when received from remote PE routers.
与为非VPN NLRI指定的行为相反，当从远程PE路由器接收时，默认情况下接受流规则。
Traffic filtering applications require monitoring and traffic statistics facilities. While this is an implementation-specific choice, implementations SHOULD provide:
流量过滤应用程序需要监控和流量统计设施。虽然这是一种特定于实现的选择，但实现应提供：
o A mechanism to log the packet header of filtered traffic.
o 一种记录过滤流量的数据包头的机制。
o A mechanism to count the number of matches for a given flow specification rule.
o 计算给定流规范规则的匹配数的机制。
Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not provide service.
提供者间路由是基于信任网的。邻近的自治系统被信任来公布有效的可达性信息。如果违反此信任模型，相邻的自治系统可能会通过公布其不提供服务的给定前缀的可达性信息而导致拒绝服务攻击。
As long as traffic filtering rules are restricted to match the corresponding unicast routing paths for the relevant prefixes, the security characteristics of this proposal are equivalent to the existing security properties of BGP unicast routing.
只要流量过滤规则被限制为匹配相应前缀的单播路由路径，该方案的安全特性就相当于BGP单播路由的现有安全特性。
Where it is not the case, this would open the door to further denial-of-service attacks.
如果情况并非如此，这将为进一步的拒绝服务攻击打开大门。
Enabling firewall-like capabilities in routers without centralized management could make certain failures harder to diagnose. For example, it is possible to allow TCP packets to pass between a pair of addresses but not ICMP packets. It is also possible to permit packets smaller than 900 or greater than 1000 bytes to pass between a
在没有集中管理的路由器中启用类似防火墙的功能可能会使某些故障更难诊断。例如，允许TCP数据包在一对地址之间传递，但不允许ICMP数据包。还可以允许小于900字节或大于1000字节的数据包在两台计算机之间传输
pair of addresses, but not packets whose length is in the range 900- 1000. Such behavior may be confusing and these capabilities should be used with care whether manually configured or coordinated through the protocol extensions described in this document.
一对地址，但不是长度在900-1000范围内的数据包。这种行为可能令人困惑，无论是手动配置还是通过本文档中描述的协议扩展进行协调，都应小心使用这些功能。
A flow specification consists of a sequence of flow components, which are identified by a an 8-bit component type. Types must be assigned and interpreted uniquely. The current specification defines types 1 though 12, with the value 0 being reserved.
流规范由一系列流组件组成，这些组件由8位组件类型标识。类型必须被唯一地分配和解释。当前规范定义类型1到12，保留值0。
For the purpose of this work, IANA has allocated values for two SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules and SAFI 134 for VPNv4 dissemination of flow specification rules.
为了完成这项工作，IANA为两个SAFI分配了值：用于IPv4流量规范规则分发的SAFI 133和用于VPNv4流量规范规则分发的SAFI 134。
The following traffic filtering flow specification rules have been allocated by IANA from the "BGP Extended Communities Type - Experimental Use" registry as follows:
IANA已从“BGP扩展社区类型-实验使用”注册表中分配以下流量过滤流规范规则，如下所示：
0x8006 - Flow spec traffic-rate
0x8006-流量规格流量率
0x8007 - Flow spec traffic-action
0x8007-流量规格流量动作
0x8008 - Flow spec redirect
0x8008-流规范重定向
0x8009 - Flow spec traffic-remarking
0x8009-流规范流量注释
IANA created and maintains a new registry entitled: "Flow Spec Component Types". The following component types have been registered:
IANA创建并维护了一个名为“Flow Spec Component Types”的新注册表。已注册以下组件类型：
Type 1 - Destination Prefix
类型1-目的地前缀
Type 2 - Source Prefix
类型2-源前缀
Type 3 - IP Protocol
类型3-IP协议
Type 4 - Port
类型4-端口
Type 5 - Destination port
类型5-目的港
Type 6 - Source port
类型6-源端口
Type 7 - ICMP type
类型7-ICMP类型
Type 8 - ICMP code
类型8-ICMP代码
Type 9 - TCP flags
类型9-TCP标志
Type 10 - Packet length
类型10-数据包长度
Type 11 - DSCP
类型11-DSCP
Type 12 - Fragment
12型-片段
In order to manage the limited number space and accommodate several usages, the following policies defined by RFC 5226 [RFC5226] are used:
为了管理有限的数字空间并适应多种用途，使用RFC 5226[RFC5226]定义的以下策略：
+--------------+-------------------------------+
| Range | Policy |
+--------------+-------------------------------+
| 0 | Invalid value |
| [1 .. 12] | Defined by this specification |
| [13 .. 127] | Specification Required |
| [128 .. 255] | First Come First Served |
+--------------+-------------------------------+
+--------------+-------------------------------+
| Range | Policy |
+--------------+-------------------------------+
| 0 | Invalid value |
| [1 .. 12] | Defined by this specification |
| [13 .. 127] | Specification Required |
| [128 .. 255] | First Come First Served |
+--------------+-------------------------------+
The specification of a particular "flow component type" must clearly identify what the criteria used to match packets forwarded by the router is. This criteria should be meaningful across router hops and not depend on values that change hop-by-hop such as TTL or Layer 2 encapsulation.
特定“流组件类型”的规范必须明确识别用于匹配路由器转发的数据包的标准。这个标准应该在路由器跳数之间有意义，而不依赖于逐跳改变的值，例如TTL或第2层封装。
The "traffic-action" extended community defined in this document has 46 unused bits, which can be used to convey additional meaning. IANA created and maintains a new registry entitled: "Traffic Action Fields". These values should be assigned via IETF Review rules only. The following traffic-action fields have been allocated:
本文档中定义的“交通行动”扩展社区有46个未使用的位，可用于传达其他含义。IANA创建并维护了一个名为“交通行动字段”的新注册表。这些值只能通过IETF评审规则分配。已分配以下交通行动字段：
47 Terminal Action
47终端作用
46 Sample
46样本
0-45 Unassigned
0-45未分配
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris Morrow, Charlie Kaufman, and David Smith for their comments.
作者要感谢亚科夫·雷克特、丹尼斯·弗格森、克里斯·莫罗、查理·考夫曼和大卫·史密斯的评论。
Chaitanya Kodeboyina helped design the flow validation procedure.
柴坦尼亚Kodeboyina帮助设计了流量验证程序。
Steven Lin and Jim Washburn ironed out all the details necessary to produce a working implementation.
Steven Lin和Jim Washburn完成了生成工作实现所需的所有细节。
[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
[IEEE.754.1985]电气和电子工程师协会，“二进制浮点运算标准”，IEEE标准754，1985年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Pedro Marques Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US EMail: roque@cisco.com
Pedro Marques Cisco Systems 170西塔斯曼大道圣何塞，加利福尼亚州95134美国电子邮件：roque@cisco.com
Nischal Sheth Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: nsheth@juniper.net
Nischal Sheth Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：nsheth@juniper.net
Robert Raszuk Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US EMail: raszuk@cisco.com
Robert Raszuk Cisco Systems 170西塔斯曼大道圣何塞，加利福尼亚州95134美国电子邮件：raszuk@cisco.com
Barry Greene Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: bgreene@juniper.net
Barry Greene Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：bgreene@juniper.net
Jared Mauch NTT America 101 Park Ave 41st Floor New York, NY 10178 US EMail: jmauch@us.ntt.net
Jared Mauch NTT America 101纽约州纽约市公园大道41楼10178美国电子邮件：jmauch@us.ntt.net
Danny McPherson Arbor Networks EMail: danny@arbor.net
Danny McPherson Arbor Networks电子邮件：danny@arbor.net