Network Working Group                                            D. Katz
Request for Comments: 3630                                   K. Kompella
Updates: 2370                                           Juniper Networks
Category: Standards Track                                       D. Yeung
                                                        Procket Networks
                                                          September 2003
Network Working Group                                            D. Katz
Request for Comments: 3630                                   K. Kompella
Updates: 2370                                           Juniper Networks
Category: Standards Track                                       D. Yeung
                                                        Procket Networks
                                                          September 2003

Traffic Engineering (TE) Extensions to OSPF Version 2


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.




This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.


1. Introduction
1. 介绍

This document specifies a method of adding traffic engineering capabilities to OSPF Version 2 [1]. The architecture of traffic engineering is described in [5]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS [6]. It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS.


The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Furthermore, no changes have been made to the operation of OSPFv2 flooding; in


particular, if non-TE capable nodes exist in the topology, they MUST flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs (see [3]).

特别是,如果拓扑中存在不支持TE的节点,则它们必须像任何其他类型10(区域局部范围)不透明LSA一样使用TE LSA(请参见[3])。

1.1. Applicability
1.1. 适用性

Many of the extensions specified in this document are in response to the requirements stated in [5], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements.


The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include:


o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering.

o 监控扩展链路属性;o基于局部约束的源路由;o全球交通工程。

For example, an OSPF-speaking device can participate in an OSPF area, build a traffic engineering database, and thereby report on the reservation state of links in that area.


In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated, is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP-hard, or even unsolvable, depending on the nature of the attributes and constraints, and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here.


Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes.


1.2. Limitations
1.2. 局限性

As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) distribution are not discussed here.


The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multi-access links may not be accurately reflected, except in the special case in which there are only two devices in the multi-access subnetwork. Operation over multi-access networks with more than two devices is not specifically prohibited. A more accurate description of the reservation state of multi-access networks is for further study.


This document also does not support unnumbered links. This deficiency will be addressed in future documents; see also [7] and [8].


1.3. Conventions
1.3. 习俗

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 [2].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。

2. LSA Format
2. LSA格式
2.1. LSA type
2.1. LSA型

This extension makes use of the Opaque LSA [3].


Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope.


One new LSA is defined, the Traffic Engineering LSA. This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA is sufficient for describing multi-access links, so no additional LSA is defined for this purpose.


2.2. LSA ID
2.2. LSA ID

The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type-specific data. The Traffic Engineering LSA uses type 1. The remaining 24 bits are the Instance field, as follows:

不透明LSA的LSA ID定义为具有8位类型数据和24位类型特定数据。交通工程LSA使用类型1。剩余的24位是实例字段,如下所示:

       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
      |       1       |                   Instance                    |
       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
      |       1       |                   Instance                    |

The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance.

实例字段是用于维护多个流量工程LSA的任意值。单个系统最多可提供16777216个流量工程LSA。LSA ID没有拓扑意义。

2.3. LSA Format Overview
2.3. LSA格式概述
2.3.1. LSA Header
2.3.1. LSA报头

The Traffic Engineering LSA starts with the standard LSA header:


       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
      |            LS age             |    Options    |      10       |
      |       1       |                   Instance                    |
      |                     Advertising Router                        |
      |                     LS sequence number                        |
      |         LS checksum           |             Length            |
       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
      |            LS age             |    Options    |      10       |
      |       1       |                   Instance                    |
      |                     Advertising Router                        |
      |                     LS sequence number                        |
      |         LS checksum           |             Length            |
2.3.2. TLV Header
2.3.2. TLV头

The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is:


       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
      |              Type             |             Length            |
      |                            Value...                           |
      .                                                               .
      .                                                               .
      .                                                               .
       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
      |              Type             |             Length            |
      |                            Value...                           |
      .                                                               .
      .                                                               .
      .                                                               .

The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored.


This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types.


2.4. LSA payload details
2.4. LSA有效载荷详细信息

An LSA contains one top-level TLV.


There are two top-level TLVs defined:


1 - Router Address 2 - Link


2.4.1. Router Address TLV
2.4.1. 路由器地址TLV

The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it; this is typically implemented as a "loopback address". The key attribute is that the address does not become unusable if an interface is down. In other protocols, this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID.


If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPF and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPF TE information. R may then appear as two separate nodes in S's TED. However, if both the IS-IS and OSPF LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single router.

如果IS-IS在域中也处于活动状态,则此地址也可用于计算OSPF和IS-IS拓扑之间的映射。例如,假设路由器R正在宣传is-is和OSPF流量工程lsa,并且进一步假设一些路由器S正在基于is-is和OSPF-TE信息构建单个流量工程数据库(TED)。然后,R可能会在S的TED中显示为两个单独的节点。然而,如果由R生成的IS-IS和OSPF LSA都包含相同的路由器地址,则S可以确定来自R的IS-IS TE LSA和OSPF TE LSA确实来自单个路由器。

The router address TLV is type 1, has a length of 4, and a value that is the four octet IP address. It must appear in exactly one Traffic Engineering LSA originated by a router.


2.4.2. Link TLV
2.4.2. 链路TLV

The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs.


Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology.


The Link TLV is type 2, and the length is variable.


The following sub-TLVs of the Link TLV are defined:


1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets)


This memo defines sub-Types 1 through 9. See the IANA Considerations section for allocation of new sub-Types.


The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.


Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows:


       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
      |S|    Exponent   |                  Fraction                   |
       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
      |S|    Exponent   |                  Fraction                   |

S is the sign, Exponent is the exponent base 2 in "excess 127" notation, and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus, the above represents the value:


      (-1)**(S) * 2**(Exponent-127) * (1 + Fraction)
      (-1)**(S) * 2**(Exponent-127) * (1 + Fraction)

For more details, refer to [4].


2.5. Sub-TLV Details
2.5. 子TLV详细信息
2.5.1. Link Type
2.5.1. 链接类型

The Link Type sub-TLV defines the type of the link:


1 - Point-to-point 2 - Multi-access


The Link Type sub-TLV is TLV type 1, and is one octet in length.


2.5.2. Link ID
2.5.2. 链接ID

The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the contents of the Link ID field in the Router LSA for these link types.


The Link ID sub-TLV is TLV type 2, and is four octets in length.


2.5.3. Local Interface IP Address
2.5.3. 本地接口IP地址

The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV.


The Local Interface IP Address sub-TLV is TLV type 3, and is 4N octets in length, where N is the number of local addresses.


2.5.4. Remote Interface IP Address
2.5.4. 远程接口IP地址

The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multi-access, the Remote Interface IP Address is set to; alternatively, an implementation MAY choose not to send this sub-TLV.


The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N octets in length, where N is the number of neighbor addresses.


2.5.5. Traffic Engineering Metric
2.5.5. 交通工程度量

The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network administrator.


The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length.


2.5.6. Maximum Bandwidth
2.5.6. 最大带宽

The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link, in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second.

Maximum Bandwidth sub TLV以IEEE浮点格式指定此链路在该方向(从发起LSA的系统到其邻居)上可使用的最大带宽。这是真正的链路容量。单位为每秒字节数。

The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length.


2.5.7. Maximum Reservable Bandwidth
2.5.7. 最大可保留带宽

The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second.

Maximum Reservable Bandwidth sub TLV以IEEE浮点格式指定此链路上沿此方向可保留的最大带宽。请注意,这可能大于最大带宽(在这种情况下,链路可能被超额订阅)。这应该是用户可配置的;默认值应为最大带宽。单位为每秒字节数。

The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length.


2.5.8. Unreserved Bandwidth
2.5.8. 无保留带宽

The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. 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. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second.

Unreserved Bandwidth sub TLV指定在IEEE浮点格式的八个优先级中的每个优先级上尚未保留的带宽量。这些值对应于可保留的带宽,设置优先级为0到7,按递增顺序排列,优先级0出现在子TLV的开始处,优先级7出现在子TLV的结束处。初始值(保留任何带宽之前)均设置为最大可保留带宽。每个值都将小于或等于最大可保留带宽。单位为每秒字节数。

The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length.


2.5.9. Administrative Group
2.5.9. 管理组

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. A link may belong to multiple groups.


By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'.


The Administrative Group is also called Resource Class/Color [5].


The Administrative Group sub-TLV is TLV type 9, and is four octets in length.


3. Elements of Procedure
3. 程序要素

Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1].


Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No Shortest Path First (SPF) or other route calculations are necessary.


4. Compatibility Issues
4. 兼容性问题

There should be no interoperability issues with routers that do not implement these extensions, as the Opaque LSAs will be silently ignored.


The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces. However, if the topology is connected, TE paths can still be calculated and ought to work.


5. Security Considerations
5. 安全考虑

This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. However, tampering with TE LSAs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal OSPF LSAs be applied equally to all Opaque LSAs, including the TE LSAs specified here.

本文件规定了OSPFv2中不透明LSA的内容。由于不透明LSA不用于SPF计算或正常路由,因此此处指定的扩展对IP路由没有影响。然而,篡改TE LSA可能会对流量工程计算产生影响,并且建议用于确保正常OSPF LSA传输的任何机制应平等地应用于所有不透明LSA,包括此处规定的TE LSA。

Note that the mechanisms in [1] and [9] apply to Opaque LSAs. It is suggested that any future mechanisms proposed to secure/authenticate OSPFv2 LSA exchanges be made general enough to be used with Opaque LSAs.

注意,[1]和[9]中的机制适用于不透明LSA。建议将来提出的任何保护/认证OSPFv2 LSA交换的机制应足够通用,以便与不透明LSA一起使用。

6. IANA Considerations
6. IANA考虑

The top level Types in a TE LSA, as well as Types for sub-TLVs for each top level Type, have been registered with IANA, except as noted.

TE LSA中的顶级类型以及每个顶级类型的子TLV类型已向IANA注册,除非另有说明。

Here are the guidelines (using terms defined in [10]) for the assignment of top level Types in TE LSAs:

以下是在TE LSA中分配顶级类型的指南(使用[10]中定义的术语):

o Types in the range 3-32767 are to be assigned via Standards Action.

o 3-32767范围内的类型将通过标准行动进行分配。

o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.

o 32768-32777范围内的类型用于实验用途;这些将不会在IANA注册,RFC不得提及。

o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.

o 此时不分配32778-65535范围内的类型。在此范围内进行任何分配之前,必须有一个标准跟踪RFC,指定涵盖所分配范围的IANA注意事项。

The guidelines for the assignment of types for sub-TLVs in a TE LSA are as follows:

TE LSA子TLV类型分配指南如下:

o Types in the range 10-32767 are to be assigned via Standards Action.

o 范围为10-32767的类型将通过标准行动进行分配。

o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.

o 32768-32777范围内的类型用于实验用途;这些将不会在IANA注册,RFC不得提及。

o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.

o 此时不分配32778-65535范围内的类型。在此范围内进行任何分配之前,必须有一个标准跟踪RFC,指定涵盖所分配范围的IANA注意事项。

7. Intellectual Property Rights Statement
7. 知识产权声明

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.


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

[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[1] Moy,J.,“OSPF版本2”,STD 54,RFC 23281998年4月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[3] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.

[3] Coltun,R.,“OSPF不透明LSA选项”,RFC 23701998年7月。

[4] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

[4] IEEE,“二进制浮点运算的IEEE标准”,标准754-1985,1985(ISBN 1-5593-7653-8)。

8.2. Informative References
8.2. 资料性引用

[5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.

[5] Awduche,D.,Malcolm,J.,Agogbua,J.,O'Dell,M.和J.McManus,“MPLS上的流量工程要求”,RFC 2702,1999年9月。

[6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering", work in progress.

[6] Smit,H.和T.Li,“ISIS交通工程扩展”,正在进行中。

[7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.

[7] Kompella,K.和Y.Rekhter,“资源预留协议中未编号链路的信令-流量工程(RSVP-TE)”,RFC 3477,2003年1月。

[8] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.

[8] Kompella,K.,Rekhter,Y.和A.Kullberg,“CR-LDP(约束路由标签分发协议)中的无编号链路信令”,RFC 3480,2003年2月。

[9] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.

[9] Murphy,S.,Badger,M.和B.Wellington,“具有数字签名的OSPF”,RFC 2154,1997年6月。

[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[10] Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 2434,1998年10月。

9. Authors' Addresses
9. 作者地址

Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA

Dave Katz Juniper Networks美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号,邮编94089

   Phone: +1 408 745 2000
   Phone: +1 408 745 2000

Derek M. Yeung Procket Networks, Inc. 1100 Cadillac Court Milpitas, CA 95035 USA

Derek M.Yeung Procket Networks,Inc.美国加利福尼亚州米尔皮塔斯市凯迪拉克球场1100号,邮编95035

   Phone: +1 408 635-7900
   Phone: +1 408 635-7900

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

Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave.Sunnyvale,加利福尼亚州94089

   Phone: +1 408 745 2000
   Phone: +1 408 745 2000
10. Full Copyright Statement
10. 完整版权声明

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


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 assignees.






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