Network Working Group H. Smit
Request for Comments: 3784 Procket Networks
Category: Informational T. Li
June 2004
Network Working Group H. Smit
Request for Comments: 3784 Procket Networks
Category: Informational T. Li
June 2004
Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)
交通工程（TE）的中间系统到中间系统（IS-IS）扩展
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 (2004).
版权所有（C）互联网协会（2004年）。
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 (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
本文档描述了中间系统到中间系统（IS-IS）协议的扩展，以支持流量工程（TE）。本文档通过指定中间系统（路由器）可以在链路状态协议（LSP）数据单元中放置的新信息来扩展IS-IS协议。此信息描述了有关网络状态的其他详细信息，这些信息对流量工程计算非常有用。
The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [3]. 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.
ISO 10589[1]中规定了IS-IS协议，RFC 1195[3]中规定了支持IPv4的扩展。每个中间系统（IS）（路由器）用路由信息播发一个或多个IS-IS链路状态协议数据单元（LSP）。每个LSP由一个固定的头和多个元组组成，每个元组由一个类型、一个长度和一个值组成。这种元组通常被称为TLV，是一种以灵活和可扩展的格式编码信息的好方法。
This document contains the design of new TLVs to replace the existing IS Neighbor TLV, 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 [4] (TE). 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特定链路特性的附加信息。交通工程[4]（TE）需要本文件中描述的特征。次要目标包括增加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的机制和程序。
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 (http://www.ietf.org/html.charters/isis-charter.html). 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工作组管理(http://www.ietf.org/html.charters/isis-charter.html). 在审查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 [1]) 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 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 RFC 2966 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.
现有IS可达性（ISO 10589[1]中定义的TLV类型2）包含一系列IS邻居的信息。对于每个邻居，都有一个包含默认度量、延迟、货币成本、可靠性和相邻邻居的7个八位组ID的结构。在这些信息中，通常使用默认度量。默认度量值当前为一个八位字节，其中一位用于指示度量值是内部还是外部，另一位最初未使用，但后来由RFC 2966定义为向上/向下位。剩余的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 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length of the value field of the sub-TLV 0-242 octets of value
7个系统Id的八位字节和伪节点编号3个默认度量的八位字节1个子TLV长度的八位字节0-244个子TLV长度的八位字节，其中每个子TLV由子TLV 0-242个值的值字段的1个子类型长度的八位字节的序列组成
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. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. 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 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）。
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 proposed here:
此处提出了某些子TLV：
Sub-TLV type Length (octets) Name 3 4 Administrative group (color) 6 4 IPv4 interface address 8 4 IPv4 neighbor address 9 4 Maximum link bandwidth 10 4 Reservable link bandwidth 11 32 Unreserved bandwidth 18 3 TE Default metric 250-254 Reserved for cisco specific extensions 255 Reserved for future expansion
子TLV类型长度（八位字节）名称3 4管理组（颜色）6 4 IPv4接口地址8 4 IPv4邻居地址9 4最大链路带宽10 4可保留链路带宽11 32未保留带宽18 3 TE默认度量250-254保留用于cisco特定扩展255保留用于未来扩展
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 RFC 1195 [3]) carry IP prefixes in a format that is analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four metrics, of which only the default metric is commonly used. The
现有的IP可达性TLV（TLV类型128和TLV类型130，在RFC 1195[3]中定义）以类似于ISO 10589[1]中的is邻居TLV的格式携带IP前缀。它们包含四个度量，其中只有默认度量是常用的。这个
default metric has a possible range of 0-63. We would like to remove this restriction.
默认度量值的可能范围为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. RFC 1195 [3] 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[3]允许路由器在级别层次结构中向上播发前缀。不幸的是，没有定义在级别层次结构中向下播发前缀的机制。
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 1 octet of control information, consisting of 1 bit of up/down information 1 bit indicating the presence of sub-TLVs 6 bits of prefix length 0-4 octet of IPv4 prefix 0-250 optional octets of sub-TLVs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length of the value field of the sub-TLV 0-247 octets of value
4个八位字节的度量信息1个八位字节的控制信息，包括1位向上/向下信息1位表示存在子TLV前缀长度为0-4个八位字节的IPv4前缀0-250可选八位字节的子TLV，如果存在，则包括1个八位字节的子TLV长度为0-249个八位字节的子TLV，其中，每个子TLV由子TLV值字段长度为0-247个八位字节的子类型1个八位字节的序列组成
This data structure can be replicated within the TLV, without exceeding the maximum length of the TLV.
此数据结构可以在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
有效位八位组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 RFC 1195 [3] 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[3]提出的解决方案是只允许在级别层次结构中向上显示前缀，而不允许在层次结构中向下显示前缀。
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 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.
为了防止级别之间的前缀循环，在新的扩展IP可达性TLV中定义了一个新的信息位。此位称为向上/向下位。当前缀首次注入is-is时，向上/向下位应设置为0。如果前缀从较高级别播发到较低级别（例如，从级别2到级别1），则该位必须设置为1，表示前缀已沿层次结构向下移动。向上/向下位设置为1的前缀只能在层次结构中向下播发，即播发到较低级别。
These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring 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 RFC 2966 [2].
新的扩展IP可达性TLV中的向上/向下位的语义与RFC 2966[2]中定义的向上/向下位的语义相同。
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的系统交互时导致转发循环。
This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV code-point 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 [5]).
此注册表包含TLV 22的子TLV的代码点。值的范围为0-255。注册中心内的分配需要记录拟使用的分配值，并由IESG指定的专家批准（见[5]）。
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-5 unassigned
6 IPv4 interface address
7 unassigned
8 IPv4 neighbor address
9 Maximum link bandwidth
10 Reservable link bandwidth
11 Unreserved bandwidth
12-17 unassigned
18 TE Default metric
19-254 unassigned
255 Reserved for future expansion
Type Description
---- -----------------------------------
0-2 unassigned
3 Administrative group (color)
4-5 unassigned
6 IPv4 interface address
7 unassigned
8 IPv4 neighbor address
9 Maximum link bandwidth
10 Reservable link bandwidth
11 Unreserved bandwidth
12-17 unassigned
18 TE Default metric
19-254 unassigned
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 [5]).
此注册表包含TLV 135子TLV的代码点。值的范围为0-255。注册中心内的分配需要记录分配值的使用情况，并由IESG指定的专家批准（见[5]）。
No codepoints are defined in this document.
本文档中未定义任何代码点。
[1] ISO, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589:2002, Second Edition
[1] ISO，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（ISO 8473）”，国际标准10589:2002，第二版
[2] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[2] Li，T.，Przygienda，T.和H.Smit，“具有两级IS-IS的域范围前缀分布”，RFC 2966，2000年10月。
[3] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990
[3] Callon，R.W.，“OSI IS-IS在TCP/IP和双环境中路由的使用”，RFC1195，1990年12月
[4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[4] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
This document raises no new security issues for IS-IS.
本文档没有为IS-IS提出新的安全问题。
The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work.
作者要感谢雅科夫·雷克特和戴夫·卡茨对这项工作的评论。
Henk Smit
亨克斯密特
EMail: hhwsmit@xs4all.nl
EMail: hhwsmit@xs4all.nl
Tony Li
李东尼
EMail: tony.li@tony.li
EMail: tony.li@tony.li
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。