Network Working Group                                        K. Kompella
Request for Comments: 3480                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
                                                             A. Kullberg
                                                        NetPlane Systems
                                                           February 2003
        
Network Working Group                                        K. Kompella
Request for Comments: 3480                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
                                                             A. Kullberg
                                                        NetPlane Systems
                                                           February 2003
        

Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)

CR-LDP(约束路由标签分发协议)中未编号链路的信令

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) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

Abstract

摘要

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links.

多协议标签交换流量工程(MPLS TE)使用的当前信令不支持未编号的链路。本文档定义了约束路由标签分发协议(CR-LDP)的程序和扩展,CR-LDP是支持无编号链路所需的MPLS TE信令协议之一。

Specification of Requirements

需求说明

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 BCP 14, RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。

1. Overview
1. 概述

Supporting MPLS TE over unnumbered links (i.e., links that do not have IP addresses) involves two components: (a) the ability to carry (TE) information about unnumbered links in IGP TE extensions (ISIS or OSPF), and (b) the ability to specify unnumbered links in MPLS TE signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The focus of this document is on the latter.

在未编号链路(即,没有IP地址的链路)上支持MPLS TE涉及两个组成部分:(a)在IGP TE扩展(ISIS或OSPF)中承载(TE)有关未编号链路的信息的能力,以及(b)在MPLS TE信令中指定未编号链路的能力。前者包含在[GMPLS-ISIS,GMPLS-OSPF]中。本文件的重点是后者。

Current signalling used by MPLS TE does not provide support for unnumbered links because the current signalling does not provide a way to indicate an unnumbered link in its Explicit Route Objects. This document proposes simple procedures and extensions that allow CR-LDP signalling [CR-LDP] to be used with unnumbered links.

MPLS TE使用的当前信令不支持未编号的链路,因为当前信令不提供在其显式路由对象中指示未编号链路的方法。本文件提出了允许CR-LDP信令[CR-LDP]用于无编号链路的简单程序和扩展。

2. Link Identifiers
2. 链接标识符

An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then the IS-IS and/or OSPF and CR-LDP modules on an LSR must agree on the identifiers.

未编号的链接必须是点对点链接。未编号链路两端的LSR为该链路分配一个标识符。此标识符是一个非零32位数字,在分配它的LSR范围内是唯一的。如果使用OSPF或ISIS作为IGP以支持流量工程,则LSR上的is-is和/或OSPF和CR-LDP模块必须就标识符达成一致。

There is no a priori relationship between the identifiers assigned to a link by the LSRs at each end of that link.

链路两端的LSR分配给链路的标识符之间没有先验关系。

LSRs at the two end points of an unnumbered link exchange with each other the identifiers they assign to the link. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP ([LMP]), by means of CR-LDP (especially in the case where a link is a Forwarding Adjacency, see below), or by means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]).

未编号链路两端的LSR相互交换分配给链路的标识符。可通过配置、借助诸如LMP([LMP])、借助CR-LDP(尤其是在链路是转发邻接的情况下,参见下文)或借助is-is或OSPF扩展([ISIS-GMPLS]、[OSPF-GMPLS])来完成标识符的交换。

Consider an (unnumbered) link between LSRs A and B. LSR A chooses an identifier for that link. So does LSR B. From A's perspective, we refer to the identifier that A assigned to the link as the "link local identifier" (or just "local identifier"), and to the identifier that B assigned to the link as the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective, the identifier that B assigned to the link is the local identifier, and the identifier that A assigned to the link is the remote identifier.

考虑LSR A和B之间的(未编号)链路,LSR A选择该链路的标识符。LSR B也是如此。从A的角度来看,我们将A分配给链路的标识符称为“链路本地标识符”(或简称“本地标识符”),将B分配给链路的标识符称为“链路远程标识符”(或简称“远程标识符”)。同样,从B的角度来看,B分配给链路的标识符是本地标识符,A分配给链路的标识符是远程标识符。

In the context of this document, the term "Router ID" means a stable IP address of an LSR that is always reachable if there is any connectivity to the LSR. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface on the LSR is down. In some cases, this value will need to be configured. If one is using OSPF or ISIS as the IGP in support of traffic engineering, then it is RECOMMENDED for the Router ID to be set to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE].

在本文件的上下文中,术语“路由器ID”是指LSR的稳定IP地址,如果与LSR存在任何连接,则该地址始终可访问。这通常实现为“环回地址”;关键属性是,如果LSR上的接口关闭,地址不会变得不可用。在某些情况下,需要配置此值。如果使用OSPF或ISIS作为IGP以支持流量工程,则建议将路由器ID设置为[OSPF-TE]中定义的“路由器地址”,或[ISIS-TE]中定义的“流量工程路由器ID”。

This section is equally applicable to the case of unnumbered component links (see [LINK-BUNDLE]).

本节同样适用于未编号组件链接的情况(见[链接束])。

3. Unnumbered Forwarding Adjacencies
3. 无编号转发邻接

If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR uses the Forwarding Adjacency formed by this LSP as an unnumbered component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST allocate an identifier to that Forwarding Adjacency (just like for any other unnumbered link). Moreover, the REQUEST message used for establishing the LSP that forms the Forwarding Adjacency MUST contain an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's Router ID set to the head end's Router ID, and the Interface ID set to the identifier that the LSR allocated to the Forwarding Adjacency.

如果发起LSP的LSR在IS-IS或OSPF中将此LSP作为未编号的转发邻接播发(请参见[LSP-HIER]),或者LSR将此LSP形成的转发邻接用作捆绑链路的未编号组件链路(请参见[link-BUNDLE]),则LSR必须为该转发邻接分配一个标识符(与任何其他未编号的链路一样)。此外,用于建立形成转发邻接的LSP的请求消息必须包含LSP_TUNNEL_INTERFACE_ID TLV(如下所述),LSR的路由器ID设置为前端的路由器ID,接口ID设置为LSR分配给转发邻接的标识符。

If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then the tail-end LSR MUST allocate an identifier to that Forwarding Adjacency (just like for any other unnumbered link). Furthermore, the MAPPING message for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the tail-end's Router ID, and the Interface ID set to the identifier allocated by the tail-end LSR.

如果请求消息包含LSP_TUNNEL_INTERFACE_ID TLV,那么后端LSR必须为该转发邻接分配一个标识符(就像任何其他未编号的链路一样)。此外,LSP的映射消息必须包含LSP_TUNNEL_INTERFACE_ID TLV,LSR的路由器ID设置为终端的路由器ID,接口ID设置为终端LSR分配的标识符。

For the purpose of processing the Explicit Route TLV and the Interface ID TLV, an unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link or an unnumbered component link as follows. The LSR that originates the Adjacency sets the link local identifier for that link to the value that the LSR allocates to that Forwarding Adjacency, and the link remote identifier to the value carried in the Interface ID field of the Reverse Interface ID TLV (for the definition of Reverse Interface ID TLV see below). The LSR that is a tail-end of that Forwarding Adjacency sets the link local identifier for that link to the value that the LSR allocates to that Forwarding Adjacency, and the link remote identifier to the value carried in the Interface ID field of the Forward Interface ID TLV (for the definition of Forward Interface ID see below).

为了处理显式路由TLV和接口ID TLV,未编号的转发邻接被视为未编号(TE)链路或未编号的组件链路,如下所示。发起邻接的LSR将该链路的链路本地标识符设置为LSR分配给该转发邻接的值,将链路远程标识符设置为反向接口ID TLV的接口ID字段中携带的值(反向接口ID TLV的定义见下文)。作为该转发邻接的尾端的LSR将该链路的链路本地标识符设置为LSR分配给该转发邻接的值,将链路远程标识符设置为转发接口ID TLV的接口ID字段中携带的值(有关转发接口ID的定义,请参阅下文)。

3.1. LSP_TUNNEL_INTERFACE_ID TLV
3.1. LSP_隧道_接口_ID TLV

The LSP_TUNNEL_INTERFACE ID TLV has Type 0x0836 and length 8. The format is given below.

LSP_TUNNEL_接口ID TLV的类型为0x0836,长度为8。格式如下所示。

Figure 1: LSP_TUNNEL_INTERFACE_ID TLV

图1:LSP_隧道_接口_ID TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|            Type           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LSR's Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Interface ID (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|            Type           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LSR's Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Interface ID (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

This TLV can optionally appear in either a REQUEST message or a MAPPING message. In the former case, we call it the "Forward Interface ID" for that LSP; in the latter case, we call it the "Reverse Interface ID" for the LSP.

此TLV可以选择显示在请求消息或映射消息中。在前一种情况下,我们称之为该LSP的“转发接口ID”;在后一种情况下,我们称之为LSP的“反向接口ID”。

4. Signalling Unnumbered Links in Explicit Route TLV
4. 显式路由TLV中未编号链路的信令

A new Type of ER-Hop TLV of the Explicit Route TLV is used to specify unnumbered links. This Type is called Unnumbered Interface ID, and has the following format:

显式路由TLV的新型ER-Hop TLV用于指定未编号的链路。此类型称为无编号接口ID,其格式如下:

The Type is 0x0837, and the Length is 12. The L bit is set to indicate a loose hop, and cleared to indicate a strict hop.

类型为0x0837,长度为12。L位设置为指示松散跃点,清除为指示严格跃点。

The Interface ID is the identifier assigned to the link by the LSR specified by the router ID.

接口ID是由路由器ID指定的LSR分配给链路的标识符。

Figure 2: Unnumbered Interface ID

图2:未编号的接口ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|          Type             |            Length = 12        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Interface ID (32 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|          Type             |            Length = 12        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Interface ID (32 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
4.1. Processing the IF_ID TLV
4.1. 处理IF_ID TLV

When an LSR receives a REQUEST message containing the IF_ID (Interface ID) TLV (see [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as follows. The LSR must have information about the identifiers assigned by its neighbors to the unnumbered links between the neighbors and the LSR. The LSR uses this information to find a link with tuple <Router ID, local identifier> matching the tuple <IP Address, Interface ID> carried in the IF_INDEX TLV. If the matching tuple is found, the match identifies the link for which the LSR has to perform label allocation.

当LSR接收到包含IF_ID(接口ID)TLV(参见[GMPLS-CRLDP])和IF_索引TLV的请求消息时,LSR按如下方式处理该TLV。LSR必须具有由其邻居分配给邻居和LSR之间未编号链路的标识符的信息。LSR使用此信息查找元组<路由器ID,本地标识符>与IF_索引TLV中携带的元组<IP地址,接口ID>匹配的链接。如果找到匹配的元组,则匹配项将标识LSR必须为其执行标签分配的链接。

Otherwise, the LSR SHOULD return an error.

否则,LSR将返回一个错误。

4.2. Processing the Unnumbered Interface ID ER-Hop TLV
4.2. 处理未编号的接口ID ER Hop TLV

The Unnumbered Interface ID ER-Hop is defined to be a part of a particular abstract node if that node has the Router ID that is equal to the Router ID field in the Unnumbered Interface ID ER-Hop, and if the node has an (unnumbered) link or an (unnumbered) Forwarding Adjacency whose local identifier (from that node's point of view) is equal to the value carried in the Interface ID field of the Unnumbered Interface ID ER-Hop.

如果特定抽象节点的路由器ID等于未编号接口ID ER Hop中的路由器ID字段,并且该节点具有(未编号的)链路或(未编号的)转发邻接,且其本地标识符(从该节点的角度)为,则未编号接口ID ER Hop被定义为该节点的一部分等于未编号的接口ID ER Hop的接口ID字段中携带的值。

With this in mind, the Explicit Route TLV processing in the presence of the Unnumbered Interface ID ER-Hop follows the rules specified in section 4.8.1 of [CR-LDP].

考虑到这一点,在没有编号的接口ID ER Hop存在的情况下,显式路由TLV处理遵循[CR-LDP]第4.8.1节中规定的规则。

As part of the Explicit Route TLV processing, or to be more precise, as part of the next hop selection, if the outgoing link is unnumbered, the REQUEST message that the node sends to the next hop MUST include the IF_ID TLV, with the IP address field of that TLV set to the Router ID of the node, and the Interface ID field of that TLV set to the identifier assigned to the link by the node.

作为显式路由TLV处理的一部分,或者更准确地说,作为下一跳选择的一部分,如果传出链路未编号,则节点发送到下一跳的请求消息必须包括if_ID TLV,并且该TLV的IP地址字段设置为节点的路由器ID,以及将该TLV的接口ID字段设置为节点分配给链路的标识符。

5. IANA Considerations
5. IANA考虑

RFC 3036 [LDP] defines the LDP TLV name space. RFC 3212 [CD-LDP] further subdivides the range of that TLV space for TLVs associated with the CR-LDP in the range 0x0800 - 0x08FF, and defines the rules for the assignment of TLVs within that range using the terminology of BCP 26, RFC 2434, "Guidelines for Writing an IANA Considerations Section in RFCs". Those rules apply to the assignment of TLV Types for the Unnumbered Interface ID and LSP_TUNNEL_INTERFACE_ID TLVs defined in this document.

RFC 3036[LDP]定义LDP TLV名称空间。RFC 3212[CD-LDP]进一步将与CR-LDP关联的TLV的TLV空间范围细分为0x0800-0x08FF范围,并使用BCP 26、RFC 2434“在RFC中编写IANA注意事项部分的指南”中的术语定义该范围内TLV的分配规则。这些规则适用于本文件中定义的未编号接口ID和LSP_TUNNEL_Interface_ID TLV的TLV类型分配。

6. Security Considerations
6. 安全考虑

This document extends CR-LDP and raises no new security issues. CR-LDP inherits the same security mechanism described in Section 4.0 of [LDP] to protect against the introduction of spoofed TCP segments into LDP session connection streams.

本文件扩展了CR-LDP,没有提出新的安全问题。CR-LDP继承了[LDP]第4.0节中描述的相同安全机制,以防止将伪造TCP段引入LDP会话连接流。

7. Acknowledgments
7. 致谢

Thanks to Rahul Aggarwal for his comments on the text. Thanks also to Bora Akyol, Vach Kompella, and George Swallow.

感谢拉胡尔·阿加瓦尔对文本的评论。也要感谢博拉·阿克约尔、瓦赫·科佩拉和乔治·斯沃恩。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

[CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.

[CR-LDP]Jamoussi,B.,Andersson,L.,Callon,R.,Dantu,R.,Wu,L.,Doolan,P.,Worster,T.,Feldman,N.,Fredette,A.,Girish,M.,Gray,E.,Heinanen,J.,Kilty,T.和A.Malis,“使用LDP的基于约束的LSP设置”,RFC 3212,2002年1月。

[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[GMPLS-SIG]Berger,L.“通用多协议标签交换(GMPLS)信令功能描述”,RFC 3471,2003年1月。

[GMPLS-CRLDP] Ashwood, P., Ed. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472 January 2003.

[GMPLS-CRLDP]Ashwood,P.,Ed.和L.Berger,“基于广义多协议标签交换(GMPLS)信令约束的路由标签分发协议(CR-LDP)扩展”,RFC 3472,2003年1月。

[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001

[LDP]Andersson,L.,Doolan,P.,Feldman,N.,Fredette,A.和B.Thomas,“LDP规范”,RFC 3036,2001年1月

[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月。

8.2. Informative References
8.2. 资料性引用

[LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", Work in Progress.

[LINK-BUNDLE]Kompella,K.,Rekhter,Y.,和Berger,L.,“MPLS流量工程中的链路捆绑”,正在进行中。

[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Work in Progress.

[LSP-HIER]Kompella,K.和Rekhter,Y.,“具有MPLS TE的LSP层次结构”,正在进行中。

[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", Work in Progress.

[LMP]Lang,J.,Mitra,K.,等,“链路管理协议(LMP)”,正在进行的工作。

[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS Extensions in Support of Generalized MPLS", Work in Progress.

[GMPLS-ISIS]Kompella,K.,Rekhter,Y.,Banerjee,A.等人,“支持广义MPLS的IS-IS扩展”,工作正在进行中。

[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF Extensions in Support of Generalized MPLS", Work in Progress.

[GMPLS-OSPF]Kompella,K.,Rekhter,Y.,Banerjee,A.等人,“支持广义MPLS的OSPF扩展”,正在进行中。

[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", Work in Progress.

[OSPF-TE]Katz,D.,Yeung,D.,Kompella,K.,“OSPF版本2的交通工程扩展”,正在进行中。

[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", Work in Progress.

[ISIS-TE]Li,T.,Smit,H.,“交通工程的IS-IS扩展”,正在进行的工作。

9. Authors' Addresses
9. 作者地址

Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089

Kireeti Kompella Juniper Networks,Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号,邮编94089

   EMail: kireeti@juniper.net
        
   EMail: kireeti@juniper.net
        

Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089

Yakov Rekhter Juniper Networks,Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号,邮编94089

   EMail: yakov@juniper.net
        
   EMail: yakov@juniper.net
        

Alan Kullberg NetPlane Systems, Inc. Westwood Executive Center 200 Lowder Brook Drive Westwood, MA 02090

Alan Kullberg NetPlane Systems,Inc.威斯特伍德行政中心,马萨诸塞州威斯特伍德市洛德布鲁克大道200号,邮编02090

   EMail: akullber@netplane.com
        
   EMail: akullber@netplane.com
        
10. Full Copyright Statement
10. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。