Network Working Group JP. Vasseur, Ed.
Request for Comments: 5330 Cisco Systems, Inc
Category: Standards Track M. Meyer
BT
K. Kumaki
KDDI R&D Labs
A. Bonda
Telecom Italia
October 2008
Network Working Group JP. Vasseur, Ed.
Request for Comments: 5330 Cisco Systems, Inc
Category: Standards Track M. Meyer
BT
K. Kumaki
KDDI R&D Labs
A. Bonda
Telecom Italia
October 2008
A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link
一种链路类型的子TLV，用于传输在链路上以零保留带宽发送信号的流量工程标签交换路径的数量
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
摘要
Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link.
在多协议标签交换（MPLS）流量工程（TE）的背景下，为开放最短路径优先（OSPF）和中间系统到中间系统（IS-IS）定义了多个链路类型子类型长度值（子TLV），以便公布一些链路特性，如可用带宽、流量工程度量，管理组，等等。通过对以零带宽（本文中称为“无约束TE LSP”）发送信号的一组TE标签交换路径（LSP）上承载的聚合流量进行统计假设，可以设计算法，以便在一组等成本路径上平衡（现有或新配置）无约束TE LSP。这需要知道通过链路发送的无约束TE LSP的数量。本文件规定了一种新的链路类型流量工程子TLV，用于公布通过链路发送的无约束TE LSP的数量。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. Protocol Extensions .............................................4
3.1. IS-IS ......................................................4
3.2. OSPF .......................................................4
4. Elements of Procedure ...........................................5
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Acknowledgements ................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. Protocol Extensions .............................................4
3.1. IS-IS ......................................................4
3.2. OSPF .......................................................4
4. Elements of Procedure ...........................................5
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Acknowledgements ................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
It is not uncommon to deploy MPLS Traffic Engineering for the sake of fast recovery, relying on a local protection recovery mechanism such as MPLS TE Fast Reroute (see [RFC4090]). In this case, a deployment model consists of deploying a full mesh of TE LSPs signalled with zero bandwidth (also referred to as unconstrained TE LSP in this document) between a set of LSRs (Label Switching Routers) and protecting these TE LSPs against link, SRLG (Shared Risk Link Group), and/or node failures with pre-established backup tunnels. The traffic routed onto such unconstrained TE LSPs simply follows the IGP shortest path, but is protected with MPLS TE Fast Reroute. This is because the TE LSP computed by the path computation algorithm (e.g., CSPF) will be no different than the IGP (Interior Gateway Protocol) shortest path should the TE metric be equal to the IGP metric.
依靠本地保护恢复机制（如MPLS TE fast Reroute，请参阅[RFC4090]），为实现快速恢复而部署MPLS流量工程并不少见。在这种情况下，部署模型包括在一组LSR（标签交换路由器）之间部署以零带宽（在本文档中也称为无约束TE LSP）发送信号的TE LSP的完整网格，并使用预先建立的备份隧道保护这些TE LSP免受链路、SRLG（共享风险链路组）和/或节点故障的影响。路由到此类无约束TE LSP的流量仅遵循IGP最短路径，但受到MPLS TE快速重路由的保护。这是因为如果TE度量等于IGP度量，则通过路径计算算法（例如，CSPF）计算的TE LSP与IGP（内部网关协议）最短路径没有区别。
When a reoptimization process is triggered for an existing TE LSP, the decision on whether to reroute that TE LSP onto a different path is governed by the discovery of a lower cost path satisfying the constraints (other metrics, such as the percentage of reserved bandwidth or the number of hops, can also be used). Unfortunately, metrics such as the path cost or the number of hops may be ineffective in various circumstances. For example, in the case of a symmetrical network with ECMPs (Equal Cost Multi-Paths), if the network operator uses unconstrained TE LSP, this may lead to a poorly load balanced traffic; indeed, several paths between a source and a destination of a TE LSP may exist that have the same cost, and the reservable amount of bandwidth along each path cannot be used as a tie-breaker.
当为现有TE-LSP触发重新优化过程时，关于是否将该TE-LSP重新路由到不同路径上的决定由满足约束的较低成本路径的发现来控制（也可以使用其他度量，例如保留带宽的百分比或跳数）。不幸的是，路径成本或跳数等指标在各种情况下可能无效。例如，在具有ECMPs（等成本多路径）的对称网络的情况下，如果网络运营商使用无约束的TE LSP，这可能会导致负载平衡不良的流量；事实上，TE-LSP的源和目的地之间可能存在具有相同成本的多条路径，并且沿每条路径的可保留带宽量不能用作连接断路器。
By making statistical assumptions about the aggregated traffic carried by a set of unconstrained TE LSPs, algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSPs across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across each link.
通过对一组无约束TE LSP承载的聚合流量进行统计假设，可以设计算法，以便在一组等成本路径上平衡（现有或新配置）无约束TE LSP的负载。这需要知道通过每个链路发送的无约束TE LSP的数量。
Note that the specification of load balancing algorithms is outside the scope of this document and is referred to for the sake of illustration of the motivation for gathering such information.
请注意，负载平衡算法的规范不在本文档的范围内，为了说明收集此类信息的动机，请参考该规范。
Furthermore, the knowledge of the number of unconstrained TE LSPs signalled across each link can be used for other purposes -- for example, to evaluate the number of affected unconstrained TE LSPs in case of a link failure.
此外，关于通过每个链路发送的无约束TE LSP数量的知识可用于其他目的——例如，在链路故障的情况下评估受影响的无约束TE LSP的数量。
A set of Link-type sub-TLVs have been defined for OSPF and IS-IS (see [RFC3630] and [RFC5305]) in the context of MPLS Traffic Engineering in order to advertise various link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. As currently defined in [RFC3630] and [RFC5305], the information related to the number of unconstrained TE LSPs is not available. This document specifies a new Link-type Traffic Engineering sub-TLV used to indicate the number of unconstrained TE LSPs signalled across a link.
在MPLS流量工程的上下文中，已经为OSPF和IS-IS定义了一组链路类型子TLV（参见[RFC3630]和[RFC5305]），以便公布各种链路特性，例如可用带宽、流量工程度量、管理组等。根据[RFC3630]和[RFC5305]中的当前定义，与无约束TE LSP数量相关的信息不可用。本文件规定了一种新的链路类型流量工程子TLV，用于指示通过链路发出信号的无约束TE LSP的数量。
Unconstrained TE LSPs that are configured and provisioned through a management system MAY be omitted from the count that is reported.
可以从报告的计数中忽略通过管理系统配置和供应的无约束TE LSP。
Terminology used in this document:
本文件中使用的术语：
CSPF: Constrained Shortest Path First
约束最短路径优先
IGP : Interior Gateway Protocol
内部网关协议
LSA: Link State Advertisement
链接状态广告
LSP: Link State Packet
链路状态包
MPLS: Multiprotocol Label Switching
多协议标签交换
LSR: Label Switching Router
标签交换路由器
SRLG: Shared Risk Link Group
SRLG：共享风险链接组
TE LSP: Traffic Engineering Label Switched Path
TE LSP：流量工程标签交换路径
Unconstrained TE LSP: A TE LSP signalled with a bandwidth equal to 0
无约束TE LSP：带宽等于0的TE LSP信号
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]中所述进行解释。
Two Unconstrained TE LSP Count sub-TLVs are defined that specify the number of TE LSPs signalled with zero bandwidth across a link.
定义了两个无约束TE LSP计数子TLV，用于指定通过链路以零带宽发送信号的TE LSP数量。
The IS-IS Unconstrained TE LSP Count sub-TLV is OPTIONAL and MUST NOT appear more than once within the extended IS reachability TLV (type 22) specified in [RFC5305] or the Multi-Topology (MT) Intermediate Systems TLV (type 222) specified in [RFC5120]. If a second instance of the Unconstrained TE LSP Count sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV.
IS-IS无约束TE LSP计数子TLV是可选的，在[RFC5305]中指定的扩展IS可达性TLV（类型22）或[RFC5120]中指定的多拓扑（MT）中间系统TLV（类型222）中不得出现多次。如果存在无约束TE LSP计数子TLV的第二个实例，则接收系统必须仅处理子TLV的第一个实例。
The IS-IS Unconstrained TE LSP Count sub-TLV format is defined below:
IS-IS无约束TE LSP计数子TLV格式定义如下：
Type (1 octet): 23
类型（1个八位组）：23
Length (1 octet): 2
长度（1个八位组）：2
Value (2 octets): number of unconstrained TE LSPs signalled across the link.
值（2个八位字节）：通过链路发送的无约束TE LSP的数量。
The OSPF Unconstrained TE LSP Count sub-TLV is OPTIONAL and MUST NOT appear more than once within the Link TLV (Type 2) that is itself carried within either the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in [RFC5329]. If a second instance of the Unconstrained TE LSP Count sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV.
OSPF无约束TE LSP计数子TLV是可选的，在[RFC3630]中规定的流量工程LSA或[RFC5329]中定义的OSPFv3区域内TE LSA（功能代码10）中自身携带的链路TLV（类型2）中不得出现多次。如果存在无约束TE LSP计数子TLV的第二个实例，则接收系统必须仅处理子TLV的第一个实例。
The OSPF Unconstrained TE LSP Count sub-TLV format is defined below:
OSPF无约束TE LSP计数子TLV格式定义如下：
Type (2 octets): 23
类型（2个八位组）：23
Length (2 octets): 4
长度（2个八位字节）：4
Value (4 octets): number of unconstrained TE LSPs signalled across the link.
值（4个八位字节）：通过链路发送信号的无约束TE LSP数。
The absence of the Unconstrained TE LSP Count sub-TLV SHOULD be interpreted as an absence of information about the link.
不存在无约束的TE LSP计数子TLV应解释为缺少有关链路的信息。
Similar to other MPLS Traffic Engineering link characteristics, LSA/LSP origination trigger mechanisms are outside the scope of this document. Care must be given to not trigger the systematic flooding of a new IS-IS LSP or OSPF LSA with a too high granularity in case of change in the number of unconstrained TE LSPs.
与其他MPLS流量工程链路特性类似，LSA/LSP发起触发机制不在本文档范围内。在无约束TE LSP数量发生变化的情况下，必须注意不要触发粒度太高的新IS-IS LSP或OSPF LSA的系统泛洪。
IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS TLV 22 and has assigned a new TLV codepoint for the Unconstrained TE LSP Count sub-TLV carried within the TLV 22.
IANA已为IS-IS TLV 22中携带的子TLV定义了子注册表，并为TLV 22中携带的无约束TE LSP计数子TLV分配了新的TLV代码点。
Value TLV Name Reference
值TLV名称引用
23 Unconstrained TE LSP Count (sub-)TLV RFC 5330
23无约束TE LSP计数（子）TLV RFC 5330
IANA has defined a sub-registry for the sub-TLVs carried in an OSPF TE Link TLV (type 2) and has assigned a new sub-TLV codepoint for the Unconstrained TE LSP Count sub-TLV carried within the TE Link TLV.
IANA为OSPF TE链路TLV（类型2）中携带的子TLV定义了子注册表，并为TE链路TLV中携带的无约束TE LSP计数子TLV分配了新的子TLV码点。
Value TLV Name Reference
值TLV名称引用
23 Unconstrained TE LSP Count (sub-)TLV RFC 5330
23无约束TE LSP计数（子）TLV RFC 5330
The function described in this document does not create any new security issues for the OSPF and IS-IS protocols. Security considerations are covered in [RFC2328] and [RFC5340] for the base OSPF protocol and in [RFC1195] and [RFC5304] for IS-IS.
本文档中描述的功能不会给OSPF和IS-IS协议带来任何新的安全问题。基本OSPF协议的[RFC2328]和[RFC5340]以及IS-IS的[RFC1195]和[RFC5304]中都包含了安全注意事项。
A security framework for MPLS and Generalized MPLS can be found in [G/MPLS].
MPLS和广义MPLS的安全框架可在[G/MPLS]中找到。
The authors would like to thank Jean-Louis Le Roux, Adrian Farrel, Daniel King, Acee Lindem, Lou Berger, Attila Takacs, Pasi Eronen, Russ Housley, Tim Polk, and Loa Anderson for their useful inputs.
作者要感谢Jean-Louis Le Roux、Adrian Farrel、Daniel King、Acee Lindem、Lou Berger、Attila Takacs、Pasi Eronen、Russ Housley、Tim Polk和Loa Anderson提供的有用信息。
[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月。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC5304] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“中间系统到中间系统（IS-IS）加密认证”，RFC 5304，2008年10月。
[RFC5305] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.
[RFC5329]Ishiguro，K.，Manral，V.，Davey，A.，和A.Lindem，Ed.，“OSPF版本3的流量工程扩展”，RFC 53292008年9月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[G/MPLS] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work In Progress, July 2008.
[G/MPLS]Fang，L.，编辑，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年7月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，2008年2月。
Authors' Addresses
作者地址
JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（编辑）思科系统公司美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Matthew R. Meyer BT Boston, MA USA
马修·R·迈耶，美国马萨诸塞州波士顿
EMail: matthew.meyer@bt.com
EMail: matthew.meyer@bt.com
Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN
Kenji Kumaki KDDI研发实验室有限公司2-1-15 Ohara Fujimino Saitama 356-8502，日本
EMail: ke-kumaki@kddi.com
EMail: ke-kumaki@kddi.com
Alberto Tempia Bonda Telecom Italia via G. Reiss Romoli 274 Torino, 10148 ITALIA
阿尔贝托·坦皮亚·邦达意大利电信公司通过G.Reiss Romoli 274意大利都灵10148
EMail: alberto.tempiabonda@telecomitalia.it
EMail: alberto.tempiabonda@telecomitalia.it
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.