Network Working Group T. Li
Request for Comments: 5305 Redback Networks, Inc.
Obsoletes: 3784 H. Smit
Category: Standards Track October 2008
Network Working Group T. Li
Request for Comments: 5305 Redback Networks, Inc.
Obsoletes: 3784 H. Smit
Category: Standards Track October 2008
IS-IS Extensions for Traffic Engineering
IS-IS交通工程扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
本文档描述了中间系统到中间系统（IS-IS）协议的扩展，以支持流量工程（TE）。本文档通过指定中间系统（路由器）可以放置在链路状态协议数据单元（LSP）中的新信息来扩展IS-IS协议。此信息描述了有关网络状态的其他详细信息，这些信息对流量工程计算非常有用。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Introducing Sub-TLVs ............................................3
3. The Extended IS Reachability TLV ................................3
3.1. Sub-TLV 3: Administrative Group (color, resource class) ....6
3.2. Sub-TLV 6: IPv4 Interface Address ..........................6
3.3. Sub-TLV 8: IPv4 Neighbor Address ...........................6
3.4. Sub-TLV 9: Maximum Link Bandwidth ..........................7
3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth ..............7
3.6. Sub-TLV 11: Unreserved Bandwidth ...........................7
3.7. Sub-TLV 18: Traffic Engineering Default Metric .............8
4. The Extended IP Reachability TLV ................................8
4.1. The up/down Bit ...........................................10
4.2. Expandability of the Extended IP Reachability TLV
with Sub-TLVs .............................................11
4.3. The Traffic Engineering Router ID TLV .....................11
5. IANA Considerations ............................................12
5.1. TLV Codepoint Allocations .................................12
5.2. New Registries ............................................13
5.2.1. Sub-TLVs for the Extended IS Reachability TLV ......13
5.2.2. Sub-TLVs for the Extended IP Reachability TLV ......15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Introducing Sub-TLVs ............................................3
3. The Extended IS Reachability TLV ................................3
3.1. Sub-TLV 3: Administrative Group (color, resource class) ....6
3.2. Sub-TLV 6: IPv4 Interface Address ..........................6
3.3. Sub-TLV 8: IPv4 Neighbor Address ...........................6
3.4. Sub-TLV 9: Maximum Link Bandwidth ..........................7
3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth ..............7
3.6. Sub-TLV 11: Unreserved Bandwidth ...........................7
3.7. Sub-TLV 18: Traffic Engineering Default Metric .............8
4. The Extended IP Reachability TLV ................................8
4.1. The up/down Bit ...........................................10
4.2. Expandability of the Extended IP Reachability TLV
with Sub-TLVs .............................................11
4.3. The Traffic Engineering Router ID TLV .....................11
5. IANA Considerations ............................................12
5.1. TLV Codepoint Allocations .................................12
5.2. New Registries ............................................13
5.2.1. Sub-TLVs for the Extended IS Reachability TLV ......13
5.2.2. Sub-TLVs for the Extended IP Reachability TLV ......15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
The IS-IS protocol is specified in ISO 10589 [ISO-10589], with extensions for supporting IPv4 specified in [RFC1195]. Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing information. Each LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format.
IS-IS协议在ISO 10589[ISO-10589]中规定，支持IPv4的扩展在[RFC1195]中规定。每个中间系统（IS）（路由器）用路由信息播发一个或多个IS-IS链路状态协议数据单元（LSP）。每个LSP由一个固定的头和多个元组组成，每个元组由一个类型、一个长度和一个值组成。这种元组通常被称为TLV，是一种以灵活和可扩展的格式编码信息的好方法。
This document contains the design of new TLVs to replace the existing IS Neighbor TLV and IP Reachability TLV, and to include additional information about the characteristics of a particular link to an IS-IS LSP. The characteristics described in this document are needed for traffic engineering [RFC2702]. Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes.
本文件包含新TLV的设计，以取代现有IS邻居TLV和IP可达性TLV，并包括有关IS-IS LSP特定链路特性的附加信息。交通工程[RFC2702]需要本文件中描述的特性。次要目标包括增加IS-IS度量的动态范围和改进IP前缀的编码。
The router ID is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router.
路由器ID对于流量工程非常有用，因为它描述了一个始终可以用来引用特定路由器的地址。
Mechanisms and procedures to migrate to the new TLVs are not discussed in this document.
本文件不讨论迁移到新TLV的机制和程序。
A prior version of this document was published as [RFC3784] with Informational status. This version is on the standards track.
本文件的前一版本发布为[RFC3784]，具有信息状态。此版本已进入标准轨道。
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]中所述进行解释。
This document introduces a new way to encode routing information in IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to regular TLVs. They use the same concepts as regular TLVs. The difference is that TLVs exist inside IS-IS packets, while sub-TLVs exist inside TLVs. TLVs are used to add extra information to IS-IS packets. Sub-TLVs are used to add extra information to particular TLVs. Each sub-TLV consists of three fields, a one-octet Type field, a one-octet Length field, and zero or more octets of Value. The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field in octets. Each sub-TLV can potentially hold multiple items. The number of items in a sub-TLV can be computed from the length of the whole sub-TLV, when the length of each item is known. Unknown sub-TLVs are to be ignored and skipped upon receipt.
本文档介绍了一种在IS-IS中编码路由信息的新方法。新对象称为子TLV。子TLV与常规TLV相似。它们使用与常规TLV相同的概念。区别在于TLV存在于is-is数据包中，而子TLV存在于TLV中。TLV用于向IS-IS数据包添加额外信息。子TLV用于向特定TLV添加额外信息。每个子TLV由三个字段组成，一个八位组类型字段、一个八位组长度字段和零个或多个值八位组。类型字段指示值字段中项目的类型。长度字段以八位字节表示值字段的长度。每个子TLV可能容纳多个项目。当每个项目的长度已知时，可以从整个子TLV的长度计算子TLV中的项目数。收到未知子TLV后，将忽略并跳过该子TLV。
The Sub-TLV type space is managed by the IETF IS-IS WG [ISIS-WG]. New type values are allocated following review on the IETF IS-IS mailing list. This will normally require publication of additional documentation describing how the new type is used. In the event that the IS-IS working group has disbanded, the review shall be performed by a Designated Expert assigned by the responsible Area Director.
子TLV类型空间由IETF is-is WG[ISIS-WG]管理。在审查IETF IS-IS邮件列表后，分配新的类型值。这通常需要发布描述如何使用新类型的附加文档。如果IS-IS工作组解散，应由负责区域主任指定的指定专家进行审查。
The extended IS reachability TLV is TLV type 22.
扩展IS可达性TLV为TLV类型22。
The existing IS reachability (TLV type 2, defined in ISO 10589 [ISO-10589]) contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the
现有IS可达性（ISO 10589[ISO-10589]中定义的TLV类型2）包含一系列IS邻居的信息。对于每个邻居，都有一个包含默认度量、延迟、货币成本、可靠性和可用性的结构
7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate whether the metric is internal or external, and one bit that was originally unused, but which was later defined by [RFC5302] to be the up/down bit. The remaining 6 bits are used to store the actual metric, resulting in a possible metric range of 0-63. This limitation is one of the restrictions that we would like to lift.
相邻邻居的7个八位组ID。在这些信息中，通常使用默认度量。默认度量值当前为一个八位字节，其中一位用于指示度量值是内部还是外部，另一位最初未使用，但后来由[RFC5302]定义为向上/向下位。剩余的6位用于存储实际度量，因此可能的度量范围为0-63。这是我们希望取消的限制之一。
The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system ID, typically 6 octets, plus one octet indicating the pseudonode number. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors.
其余三个指标（延迟、货币成本和可靠性）通常未实施，反映了TLV中未使用的开销。邻居通过其系统ID（通常为6个八位字节）加上一个表示伪节点号的八位字节来识别。因此，现有TLV每个邻居消耗11个八位字节，4个八位字节用于度量，7个八位字节用于邻居识别。为了指示多个邻接，此结构在is可达性TLV中重复。由于TLV的内容限制为255个八位字节，因此单个TLV最多可以描述23个邻居。IS可达性TLV可以在LSP片段内重复，以描述进一步的邻居。
The proposed extended IS reachability TLV contains a new data structure, consisting of:
建议的扩展IS可达性TLV包含一个新的数据结构，包括：
7 octets of system ID and pseudonode number
系统ID和伪节点号的7个八位字节
3 octets of default metric
默认度量的3个八位字节
1 octet of length of sub-TLVs
子TLV长度的1个八位组
0-244 octets of sub-TLVs, where each sub-TLV consists of a sequence of
子TLV的0-244个八位组，其中每个子TLV由一系列
1 octet of sub-type
子类型的1个八位组
1 octet of length of the Value field of the sub-TLV
子TLV值字段长度的1个八位字节
0-242 octets of value
值的0-242个八位字节
Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. There is no defined mechanism for extending the sub-TLV space. Thus, wasting sub-TLV space is discouraged.
因此，如果不使用子TLV，新编码需要11个八位字节，最多可以包含23个相邻字节。请注意，虽然编码允许255个八位字节的子TLV，但最大值不能包含在整个IS可达性TLV中。实际最大值为255个八位字节减去上述11个八位字节，即244个八位字节。没有定义扩展子TLV空间的机制。因此，不鼓励浪费子TLV空间。
The metric octets are encoded as a 24-bit unsigned integer. Note that the Metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the Metric field of an inter-area route.
度量八位字节编码为24位无符号整数。请注意，新的扩展IP可达性TLV中的度量字段编码为32位无符号整数。选择这些不同的大小是为了使区域内路由的成本不太可能被削减以适应区域间路由的度量字段。
To preclude overflow within a traffic engineering Shortest Path First (SPF) implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
为防止流量工程最短路径优先（SPF）实施中的溢出，大于或等于最大路径度量的所有度量应被视为具有最大路径度量。最容易选择MAX_PATH_METRIC，这样MAX_PATH_METRIC加上一个链路度量不会溢出用于内部度量计算的位数。我们假设这是32位。因此，我们选择最大路径度量为4261412864（0xFE000000，2^32-2^25）。
If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation. This will allow advertisement of a link for purposes other than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing.
如果使用最大链路度量（2^24-1）播发链路，则在正常SPF计算期间不得考虑此链路。这将允许出于构建正常最短路径树以外的目的发布链接。例如，链路可用于流量工程，但不适用于逐跳路由。
Certain sub-TLVs are established here:
此处建立了某些子TLV：
+------------+----------------+-------------------------------------+
| Sub-TLV | Length | Name |
| type | (octets) | |
+------------+----------------+-------------------------------------+
| 3 | 4 | Administrative group (color) |
| | | |
| 6 | 4 | IPv4 interface address |
| | | |
| 8 | 4 | IPv4 neighbor address |
| | | |
| 9 | 4 | Maximum link bandwidth |
| | | |
| 10 | 4 | Maximum reservable link bandwidth |
| | | |
| 11 | 32 | Unreserved bandwidth |
| | | |
| 18 | 3 | TE Default metric |
| | | |
| 250-254 | | Reserved for Cisco specific |
| | | extensions |
| | | |
| 255 | | Reserved for future expansion |
+------------+----------------+-------------------------------------+
+------------+----------------+-------------------------------------+
| Sub-TLV | Length | Name |
| type | (octets) | |
+------------+----------------+-------------------------------------+
| 3 | 4 | Administrative group (color) |
| | | |
| 6 | 4 | IPv4 interface address |
| | | |
| 8 | 4 | IPv4 neighbor address |
| | | |
| 9 | 4 | Maximum link bandwidth |
| | | |
| 10 | 4 | Maximum reservable link bandwidth |
| | | |
| 11 | 32 | Unreserved bandwidth |
| | | |
| 18 | 3 | TE Default metric |
| | | |
| 250-254 | | Reserved for Cisco specific |
| | | extensions |
| | | |
| 255 | | Reserved for future expansion |
+------------+----------------+-------------------------------------+
Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV.
下面描述了这些子TLV中的每一个。除非另有说明，否则子TLV的多个内含物支持信息的多次出现。
The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface.
管理组子TLV包含由网络管理员分配的4位八位元掩码。每个设置位对应于分配给接口的一个管理组。
By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'.
按照惯例，最低有效位称为“组0”，最高有效位称为“组31”。
This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
此子TLV是可选的。此子TLV在每个扩展IS可达性TLV中最多应出现一次。
This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times.
此子TLV包含（主）TLV描述的接口的4个八位IPv4地址。此子TLV可能发生多次。
Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV.
实现不得将接口地址的/32前缀插入其路由或转发表中，因为在与不支持此子TLV的系统交互时，这可能导致转发循环。
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV.
如果路由器实现了本文档中的基本TLV扩展，它可以在邻接描述中添加或省略此子TLV。如果路由器实施流量工程，它必须包括此子TLV。
This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times.
此子TLV包含此链路上相邻路由器的单个IPv4地址。此子TLV可能发生多次。
Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV.
实现不得将邻居地址的/32前缀插入其路由或转发表中，因为这可能导致在与不支持此子TLV的系统交互时出现转发循环。
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV on point-to-point adjacencies.
如果路由器实现了本文档中的基本TLV扩展，它可以在邻接描述中添加或省略此子TLV。如果路由器实施流量工程，它必须在点对点邻接中包含此子TLV。
This sub-TLV contains the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors). This is useful for traffic engineering.
此子TLV包含此链路在该方向上可使用的最大带宽（从发起LSP的系统到其邻居）。这对交通工程很有用。
The maximum link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second.
最大链路带宽以32位IEEE浮点格式编码。单位为每秒字节（不是位！）。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
此子TLV是可选的。此子TLV在每个扩展IS可达性TLV中最多应出现一次。
This sub-TLV contains the maximum amount of bandwidth that can be reserved in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.
此子TLV包含可在此链路上沿此方向保留的最大带宽量。请注意，出于超额订阅的目的，这可能大于链路的带宽。
The maximum reservable link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second.
最大可保留链路带宽以32位IEEE浮点格式编码。单位为每秒字节（不是位！）。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
此子TLV是可选的。此子TLV在每个扩展IS可达性TLV中最多应出现一次。
This sub-TLV contains the amount of bandwidth reservable in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.
此子TLV包含此链路上此方向可保留的带宽量。请注意，出于超额订阅的目的，这可能大于链路的带宽。
Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32-bit IEEE floating point numbers. The units are bytes (not bits!) per second. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV.
由于需要优先级和抢占，每个前端需要知道每个优先级的保留带宽量。因此，该子TLV包含八个32位IEEE浮点数。单位为每秒字节（不是位！）。这些值对应于可保留的带宽，设置优先级为0到7，按递增顺序排列，优先级0出现在子TLV的开始处，优先级7出现在子TLV的结束处。
For stability reasons, rapid changes in the values in this sub-TLV SHOULD NOT cause rapid generation of LSPs.
出于稳定性原因，该子TLV值的快速变化不应导致LSP的快速生成。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
此子TLV是可选的。此子TLV在每个扩展IS可达性TLV中最多应出现一次。
This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations.
此子TLV包含一个24位无符号整数。该度量是管理分配的，可用于向流量工程SPF计算提供不同加权拓扑。
To preclude overflow within a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
为了防止流量工程SPF实施中的溢出，所有大于或等于MAX_PATH_METRIC的度量应被视为具有MAX_PATH_METRIC的度量。最容易选择MAX_PATH_METRIC，这样MAX_PATH_METRIC加上一个链路度量不会溢出用于内部度量计算的位数。我们假设这是32位。因此，我们选择最大路径度量为4261412864（0xFE000000，2^32-2^25）。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV. If a link is advertised without this sub-TLV, traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV.
此子TLV是可选的。此子TLV在每个扩展IS可达性TLV中最多应出现一次。如果在没有该子TLV的情况下公布链路，则流量工程SPF计算必须使用该链路的正常默认度量，该度量在扩展is可达性TLV的固定部分公布。
The extended IP reachability TLV is TLV type 135.
扩展IP可达性TLV是TLV类型135。
The existing IP reachability TLVs (TLV type 128 and TLV type 130, defined in [RFC1195]) carry IP prefixes in a format that is analogous to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four metrics, of which only the default metric is commonly used. The default metric has a possible range of 0-63. We would like to remove this restriction.
现有的IP可达性TLV（TLV类型128和TLV类型130，在[RFC1195]中定义）以类似于ISO 10589[ISO-10589]中的is邻居TLV的格式携带IP前缀。它们包含四个度量，其中只有默认度量是常用的。默认度量的可能范围为0-63。我们想取消这个限制。
In addition, route redistribution (a.k.a. route leaking) has a key problem that was not fully addressed by the existing IP reachability TLVs. [RFC1195] allows a router to advertise prefixes upwards in the level hierarchy. Unfortunately, there were no mechanisms defined to advertise prefixes downwards in the level hierarchy.
此外，路由重新分配（也称为路由泄漏）有一个关键问题，现有的IP可达性TLV没有完全解决这个问题。[RFC1195]允许路由器在级别层次结构中向上播发前缀。不幸的是，没有定义在级别层次结构中向下播发前缀的机制。
To address these two issues, the proposed extended IP reachability TLV provides for a 32-bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy.
为了解决这两个问题，建议的扩展IP可达性TLV提供了一个32位的度量，并添加了一位来表示前缀已在层次结构中“向下”重新分配。
The proposed extended IP reachability TLV contains a new data structure, consisting of:
拟议的扩展IP可达性TLV包含一个新的数据结构，包括：
4 octets of metric information
度量信息的4个八位字节
1 octet of control information, consisting of
控制信息的1个八位组，包括
1 bit of up/down information
1位向上/向下信息
1 bit indicating the presence of sub-TLVs
1位，表示存在子TLV
6 bits of prefix length
前缀长度的6位
0-4 octets of IPv4 prefix
IPv4前缀的0-4个八位字节
0-250 optional octets of sub-TLVs, if present consisting of
子TLV的0-250个可选八位字节，如果存在，包括
1 octet of length of sub-TLVs
子TLV长度的1个八位组
0-249 octets of sub-TLVs, where each sub-TLV consists of a sequence of
子TLV的0-249个八位字节，其中每个子TLV由一系列
1 octet of sub-type
子类型的1个八位组
1 octet of length of the Value field of the sub-TLV
子TLV值字段长度的1个八位字节
0-247 octets of value
0-247个八进制值
This data structure can be replicated within the TLV, as long as the maximum length of the TLV is not exceeded.
只要不超过TLV的最大长度，就可以在TLV内复制此数据结构。
The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of octets for the given number of significant bits. This implies:
前缀长度的6位可以具有0-32的值，并指示前缀中有效位的数量。前缀以给定有效位数的最小八位字节数编码。这意味着：
+------------------+--------+
| Significant bits | Octets |
+------------------+--------+
| 0 | 0 |
| | |
| 1-8 | 1 |
| | |
| 9-16 | 2 |
| | |
| 17-24 | 3 |
| | |
| 25-32 | 4 |
+------------------+--------+
+------------------+--------+
| Significant bits | Octets |
+------------------+--------+
| 0 | 0 |
| | |
| 1-8 | 1 |
| | |
| 9-16 | 2 |
| | |
| 17-24 | 3 |
| | |
| 25-32 | 4 |
+------------------+--------+
The remaining bits of prefix are transmitted as zero and ignored upon receipt.
前缀的剩余位作为零传输，并在接收时忽略。
If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table.
如果使用大于最大路径度量（0xFE000000，见第3.0段）的度量播发前缀，则在正常SPF计算期间不得考虑该前缀。这允许出于构建正常IP路由表以外的目的播发前缀。
If routers were allowed to redistribute IP prefixes freely in both directions between level 1 and level 2 without any additional mechanisms, those routers would not be able to determine looping of routing information. A problem occurs when a router learns a prefix via level 2 routing and advertises that prefix down into a level 1 area, where another router might pick up the route and advertise the prefix back up into the level 2 backbone. If the original source withdraws the prefix, those two routers might end up having a routing loop between them, where part of the looped path is via level 1 routing and the other part of the looped path is via level 2 routing. The solution that [RFC1195] poses is to allow only advertising prefixes upward in the level hierarchy, and to disallow the advertising of prefixes downward in the hierarchy.
如果允许路由器在级别1和级别2之间自由地在两个方向上重新分配IP前缀，而不使用任何附加机制，那么这些路由器将无法确定路由信息的循环。当一个路由器通过二级路由学习一个前缀并将该前缀向下播发到一级区域时，就会出现问题，在该区域中，另一个路由器可能会拾取该路由并将该前缀重新播发到二级主干网中。如果原始源撤回前缀，那么这两个路由器可能最终在它们之间有一个路由循环，其中一部分循环路径通过级别1路由，另一部分循环路径通过级别2路由。[RFC1195]提出的解决方案是只允许级别层次结构中向上的前缀广告，而不允许层次结构中向下的前缀广告。
To prevent this looping of prefixes between levels, a new bit of information is defined in the new extended IP reachability TLV. This bit is called the up/down bit. The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g., level 2 to
为了防止级别之间的前缀循环，在新的扩展IP可达性TLV中定义了一个新的信息位。此位称为向上/向下位。当前缀首次注入is-is时，向上/向下位应设置为0。如果前缀从较高级别播发到较低级别（例如，级别2到
level 1), the bit MUST be set to 1, indicating that the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e., to lower levels.
级别1），该位必须设置为1，表示前缀已沿层次结构向下移动。向上/向下位设置为1的前缀只能在层次结构中向下播发，即播发到较低级别。
These semantics apply even if IS-IS is extended in the future to have additional levels. By ensuring that prefixes follow only the IS-IS hierarchy, we have ensured that the information does not loop, thereby ensuring that there are no persistent forwarding loops.
即使将来扩展IS-IS以增加级别，这些语义也适用。通过确保前缀只遵循IS-IS层次结构，我们确保了信息不会循环，从而确保没有持久转发循环。
If a prefix is advertised from one area to another at the same level, then the up/down bit SHALL be set to 1. This situation can arise when a router implements multiple virtual routers at the same level, but in different areas.
如果前缀在同一级别从一个区域播发到另一个区域，则向上/向下位应设置为1。当路由器在同一级别但在不同区域实现多个虚拟路由器时，可能会出现这种情况。
The semantics of the up/down bit in the new extended IP reachability TLV are identical to the semantics of the up/down bit defined in [RFC5302].
新的扩展IP可达性TLV中的向上/向下位的语义与[RFC5302]中定义的向上/向下位的语义相同。
The extended IP reachability TLV can hold sub-TLVs that apply to a particular prefix. This allows for easy future extensions. If there are no sub-TLVs associated with a prefix, the bit indicating the presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the first octet after the prefix will be interpreted as the length of all sub-TLVs associated with this IPv4 prefix. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets.
扩展IP可达性TLV可以容纳应用于特定前缀的子TLV。这使得将来的扩展变得容易。如果没有与前缀关联的子TLV，则表示存在子TLV的位应设置为0。如果此位设置为1，则前缀后的第一个八位字节将被解释为与此IPv4前缀关联的所有子TLV的长度。请注意，虽然编码允许255个八位字节的子TLV，但最大值不能适应整个扩展IP可达性TLV。实际最大值为255个八位字节减去上述5-9个八位字节，或250个八位字节。
This document does not define any sub-TLVs for the extended IP reachability TLV.
本文档没有为扩展IP可达性TLV定义任何子TLV。
The Traffic Engineering router ID TLV is TLV type 134.
流量工程路由器ID TLV是TLV类型134。
The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards:
路由器ID TLV包含发起LSP的路由器的4位八位组路由器ID。这在几个方面很有用：
For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces.
对于流量工程，它保证了我们有一个稳定的地址，无论节点接口的状态如何，该地址始终可以在多跳之外的路径中引用。
If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies.
如果OSPF在域中也处于活动状态，则流量工程可以计算OSPF和is-is拓扑之间的映射。
If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements traffic engineering, it MUST include this TLV in its LSP. This TLV SHOULD not be included more than once in an LSP.
如果路由器没有实现流量工程，它可以添加或省略流量工程路由器ID TLV。如果路由器实施流量工程，它必须在其LSP中包含此TLV。该TLV不应在LSP中包含多次。
If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises prefixes via the Border Gateway Protocol (BGP) with the BGP next hop attribute set to the BGP router ID, the Traffic Engineering router ID SHOULD be the same as the BGP router ID.
如果路由器在其LSP中播发流量工程路由器ID TLV，并且如果路由器通过边界网关协议（BGP）播发前缀，且BGP下一跳属性设置为BGP路由器ID，则流量工程路由器ID应与BGP路由器ID相同。
Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table because this can lead to forwarding loops when interacting with systems that do not support this TLV.
实现不得将路由器ID的/32前缀插入其转发表中，因为这可能会在与不支持此TLV的系统交互时导致转发循环。
Prior IANA requests for this purpose were covered as part of [RFC3784]. The text of those requests is reproduced here for completeness and consistency.
[RFC3784]涵盖了之前IANA为此目的提出的请求。为了完整性和一致性，此处转载了这些请求的文本。
This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV codepoint registry:
本文件定义了以下新的IS-IS TLV类型，这些类型已反映在ISIS TLV代码点注册表中：
+------+---------------------------------------+-----+-----+-----+
| Type | Description | IIH | LSP | SNP |
+------+---------------------------------------+-----+-----+-----+
| 22 | The extended IS reachability TLV | n | y | n |
| | | | | |
| 134 | The Traffic Engineering router ID TLV | n | y | n |
| | | | | |
| 135 | The extended IP reachability TLV | n | y | n |
+------+---------------------------------------+-----+-----+-----+
+------+---------------------------------------+-----+-----+-----+
| Type | Description | IIH | LSP | SNP |
+------+---------------------------------------+-----+-----+-----+
| 22 | The extended IS reachability TLV | n | y | n |
| | | | | |
| 134 | The Traffic Engineering router ID TLV | n | y | n |
| | | | | |
| 135 | The extended IP reachability TLV | n | y | n |
+------+---------------------------------------+-----+-----+-----+
IANA has created the following new registries.
IANA已经创建了以下新的注册中心。
This registry contains codepoints for sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the proposed use of the allocated value and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
此注册表包含TLV 22的子TLV的代码点。值的范围为0-255。注册中心内的分配需要记录拟使用的分配值，并由IESG指定的专家批准（见[RFC5226]）。
Taking into consideration allocations specified in this document, the registry has been initialized as follows:
考虑到本文件中规定的分配，注册表已按如下方式初始化：
+--------+------------------------------------+
| Type | Description |
+--------+------------------------------------+
| 0-2 | unassigned |
| | |
| 3 | Administrative group (color) |
| | |
| 4 | Link Local/Remote Identifiers |
| | |
| 5 | unassigned |
| | |
| 6 | IPv4 interface address |
| | |
| 7 | unassigned |
| | |
| 8 | IPv4 neighbor address |
| | |
| 9 | Maximum link bandwidth |
| | |
| 10 | Maximum Reservable link bandwidth |
| | |
| 11 | Unreserved bandwidth |
| | |
| 12-17 | unassigned |
| | |
| 18 | TE Default metric |
| | |
| 19 | Link-attributes |
| | |
| 20 | Link Protection Type |
| | |
| 21 | Interface Switching Capability |
| | Descriptor |
| | |
| 22 | Bandwidth Constraints |
| | |
| 23-249 | unassigned |
| | |
| 250-254| Reserved for Cisco specific |
| | extensions |
| | |
| 255 | Reserved for future expansion |
+--------+------------------------------------+
+--------+------------------------------------+
| Type | Description |
+--------+------------------------------------+
| 0-2 | unassigned |
| | |
| 3 | Administrative group (color) |
| | |
| 4 | Link Local/Remote Identifiers |
| | |
| 5 | unassigned |
| | |
| 6 | IPv4 interface address |
| | |
| 7 | unassigned |
| | |
| 8 | IPv4 neighbor address |
| | |
| 9 | Maximum link bandwidth |
| | |
| 10 | Maximum Reservable link bandwidth |
| | |
| 11 | Unreserved bandwidth |
| | |
| 12-17 | unassigned |
| | |
| 18 | TE Default metric |
| | |
| 19 | Link-attributes |
| | |
| 20 | Link Protection Type |
| | |
| 21 | Interface Switching Capability |
| | Descriptor |
| | |
| 22 | Bandwidth Constraints |
| | |
| 23-249 | unassigned |
| | |
| 250-254| Reserved for Cisco specific |
| | extensions |
| | |
| 255 | Reserved for future expansion |
+--------+------------------------------------+
This registry contains codepoints for sub-TLVs of TLV 135. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [RFC5226]). No codepoints are defined in this document.
此注册表包含TLV 135子TLV的代码点。值的范围为0-255。注册中心内的分配需要记录分配值的使用情况，并由IESG指定的专家批准（见[RFC5226]）。本文档中未定义任何代码点。
This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC5304].
本文件未对IS-IS提出新的安全问题；有关IS-IS的一般安全注意事项，请参见[RFC5304]。
The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work. This work was funded in part by Procket Networks and Juniper Networks.
作者要感谢雅科夫·雷克特和戴夫·卡茨对这项工作的评论。这项工作的部分资金来自Procket Networks和Juniper Networks。
[ISO-10589] ISO, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589: 2002, Second Edition, 2002.
[ISO-10589]ISO，“与提供无连接模式网络服务协议（ISO 8473）一起使用的中间系统到中间系统域内路由信息交换协议”，国际标准10589:2002，第二版，2002年。
[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月。
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, October 2008.
[RFC5302]Li，T.，Smit，H.，和T.Przygienda，“具有两级IS-IS的域范围前缀分布”，RFC 5302，2008年10月。
[ISIS-WG] IS-IS for IP Internets (isis)
<http://www.ietf.org/html.charters/isis-charter.html>
[ISIS-WG] IS-IS for IP Internets (isis)
<http://www.ietf.org/html.charters/isis-charter.html>
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[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月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
Authors' Addresses
作者地址
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
Tony Li Redback Networks，Inc.美国加利福尼亚州圣何塞霍尔格大道300号，邮编95134
Phone: +1 408 750 5160
EMail: tony.li@tony.li
Phone: +1 408 750 5160
EMail: tony.li@tony.li
Henk Smit
亨克斯密特
EMail: hhw.smit@xs4all.nl
EMail: hhw.smit@xs4all.nl
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.