RFC3630 - TE Extensions to OSPF Version 2中文

Traffic Engineering (TE) Extensions to OSPF Version 2

该标准是RFC2370的更新。标准RFC2370是关于OSPFv2的Opaque LSA的扩展，在被更新以后，已经变为失效状态。

该标准脱胎于草案draft-katz-yeung-ospf-traffic，该草案从1999年10月开始，先后经历了12个草案版本，最终于2003年9月成为建议标准（Proposed Standard）。本文档的翻译时间开始于2016年5月12日。

该标准被OSPF的GMPLS扩展RFC4203，以及在OSPF-TE扩展中通告路由器的本地地址的标准RFC5786

本文档的状态

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.

版权声明

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

摘要

本文档描述了针对OSPF v2所做的支持intra-area的TE扩展，该扩展使用了Opaque LSA。

1. Introduction

本文档提供了一种在OSPF v2[1]中增加TE能力的方法。TE的结构在[5]中有所描述。本文档中的语义内容和对IS-IS的相应扩展[6]大致相同。预计OSPF的TE扩展将能够反映到IS-IS的扩展上。

这个扩展提供了一种描述TE拓扑（包括带宽和管理限制），以及在给定的OSPF area内部分发TE拓扑信息的方法。这个TE拓扑没有必要匹配常规的路由拓扑，尽管本标准依赖于network-LSAs来描述multi-access links。本文档不会解释此处描述的机制如何在多个OSPF areas中跨域应用；这个任务留给了未来的文档。更进一步，本文档没有对OSPFv2的泛洪操作做任何修改；尤其是，如果拓扑中存在不具备TE能力的节点，则它们MUST以type 10（area-local scope）的Opaque LSAs泛洪所有的TE LSAs（见3）。

1.1 Applicability

本文档中引入的很多扩展都符合[5]的需求，因此被认为是“traffic engineering extensions”，通常也被认为和MPLS Traffic Engineering有联系。一个更加明确（虽然普通）的设计是“extended link attributes”，作为建议，它简单地在OSPF通告中增加了一些links的属性。

这些扩展中包含的信息可以被用来构建一个扩展的LSDB，就像router-LSAs能用来构建一个“常规的”LSDB一样；不同之处在于扩展的LSDB（下面成为流量工程数据库，TED）有额外的链路属性。TED的使用包括：

• 监控扩展的链路属性；
• 本地基于限制的源路由；以及（local constraint-based source routing; and）
• 全局流量工程（global traffic engineering.）

比如，一个支持OSPF的设备能够参与到一个OSPF area中，它能构建一个TED，因此能报告在所在area的链路的预留状态（reservation state）。

在“本地基于限制的源路由”的说法中，一个路由器R能够计算从源节点A到目的节点B的路径；典型地，A就是R本身，B被指定为“router address”（见下）。这条路径可能会遵循多个其所经过的链路和节点上的属性的一些限制，比如说，使用非预留带宽（unreserved bandwidth）至少是10Mbps的绿色链路。这条路径接下来可以承载流量中的从A到B的一部分，形成一个简单但有效的流量工程的手段。穿过该路径的这部分流量如何确定，这个路径如何初始化，这些都超出了本文档的讨论范围；简单来说一种定义流量中指定部分的方式是“那些IP目的地址是从B学习到的”这样，一种初始化路径的方式是使用MPLS tunels。

顺便说一句，基于限制的路由可能是NP-hard问题，甚至是不可解的，这取决于链路和节点属性和限制的具体情况，因此很多真正的实现都会使用试探法（heuristics）。因此，我们在这里不会尝试去提出这样的算法。

最后，在“全局流量工程”的说法中，一个设备能构建TED，向TED中输入流量矩阵，以及优化函数，对信息进行处理，然后为整个网络计算出最优或近似最优的路由。这个设备还能监控流量工程拓扑，并且对于拓扑的改变能够重新计算最优路由。

1.2 Limitations

如上面所提到的，本文档所引入的扩展和处理流程仅仅涉及到流量工程信息在area内部的分发。inter-area和inter-AS的分发不在本文档讨论范围内。

本文档中引入的扩展能够捕获点到点链路的预留状态。多路访问链路的预留状态可能无法准确捕获，除了MA子网中只有两台设备这种特殊情况以外。对于超过两个设备的MA网络的操作没有明确禁止。关于对MA网络的预留状态的更明确的描述留待后来研究。

这个文档不支持unnumbered links。这一缺陷会在未来的文档中得到弥补；也可以见[7]和[8].

1.3 Conventions

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

2 LSA Format

2.1 LSA type

本扩展使用了opaque LSA [3]。

Opaque LSAs当前有三种存在，每种都有不同的泛洪范围。本文档中仅仅使用Type 10 LSAs，其泛洪范围是area内部。

需要定义一个新的LSA，即Traffic Engineering LSA。这种LSA描述了路由器，点到点链路，以及到MA网络的连接（类似于router-LSA）。为了达到流量工程的目的，当前已存在的network-LSA已经足以用来描述多路访问（MA， multi-access）链路了，所以不需要为它定义额外的LSA。

2.2 LSA ID

Opaque LSA的LSA ID定义为8-bit的类型数据和24-bit的根据类型指定的数据。流量工程的LSA使用type 1.剩下的24-bit是Instance field，如下：

   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                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Instance field是一个任意值，用来维护多个TE LSAs。

流量工程的LSA的最大值16777216（2的24次方）可能由一个单独的系统采用（may be sourced by a single system）。LSA ID的值没有任何拓扑意义。

2.3 LSA Format Overview

2.3.1 LSA Header

TE LSA的构建开始于一个标准的LSA头：

   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

LSA的payload是由一个或者多个Type/Length/Value（TLV）元组组成的。每个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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Value...                           |
  .                                                               .
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length定义了以字节为单位的value部分的长度（因此没有value的TLV的长度为0）。TLV需要进行4-octet的对齐；对齐所增加的位数不包含在length的计算中（因此一个3-octet的value的lenght为3，但是整个TLV的长度却是8）。需要知道嵌入的TLV（即subtlv）也需要进行32-bit对齐。如果不能识别type，则忽略该TLV。

本文档定义了Type 1和Type 2的TLV。可从IANA Considerations小节看到新的Types的分配。

2.4 LSA payload details

一个LSA包含一个顶级的TLV。顶级TLV有两种定义：

• Router Address
• Link

2.4.1 Router Address TLV

Router Address TLV标明了一个通告路由器的稳定IP地址，但凡有到路由器的任何连接，这个路由器总是可达的；这个IP地址被成为“loopback address”。这个IP地址的关键属性是即便路由器的接口down了，这个地址仍然可以访问到路由器。在其它的协议中，这被称为“router ID”，但是出于显然的原因，该术语在本文档中不会这么用（Router ID在OSPF中表示其它的意思）。如果一个路由器在BGP的下一跳属性设置为BGP router ID，以此来声明BGP路由，则这个Router Address SHOULD和BGP的router ID一致。

不知道BGP的router ID是什么值？

如果IS-IS在这个domain中也在运行，这个地址也可以用来做OSPF和IS-IS拓扑之间的映射。比如，假设一个路由器R同时声明了IS-IS和OSPF TE LSAs，进一步假设某个路由器S基于IS-IS和OSPF TE信息构建了一个TED。则R有可能会在S的TED中作为两个独立的节点出现。然而，如果R生成的IS-IS和OSPF LSAs包含了相同的Router Address，则S能够判断接收到的这两个R发来的IS-IS TE LSA和OSPF TE LSA其实是同一个路由器。

这里的意思是IS-IS也有TE扩展哦。。。

Router Address TLV是type 1，length值为4，value就是4-octet的IP地址。由路由器生成的TE LSA中必须要包含这个TLV。

2.4.2 Link TLV

Link TLV描述了一个链路。它是由一系列的sub-TLVs组成的。这些sub-TLVs之间没有先后顺序。

考虑到拓扑中的变化的粒度，每个LSA只能包含一个Link TLV。

Link TLV的type为2，length是变量。

在Link TLV中有以下9种sub-TLV被定义：

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）

本文档中定义了1-9的sub-type。这些新sub-types的分配可见IANA Considerations小节。

Link Type和Link ID这俩sub-TLVs都是强制的，也就是说只能且必须出现一次。一个Link TLV中出现的其它sub-Tlv都最多出现一次。这些限制对于未来要定义的sub-TLVs并不是必须有效的。不能识别sub-type的sub-tlv会被忽略。

下面提到的不同的values都使用了32-bit的IEEE Floating Point format。其格式如下：

   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表示符号位，Exponent是以2为底的指数，使用了“excess 127”记号法，Fraction是尾数-1，其前面有一个隐含的二进制小数点。因此，上述字段表示的数值是：

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

更多细节可见[4]。

后面有些sub-tlv的value表示需要用到这个。不过这个的表示范围大小是从哪里到哪里呢？？？一会儿回头看看

2.5 Sub-TLV Details

2.5.1 Link Type

Link Type sub-TLV定义了链路的类型：

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

Link Type sub-TLV的type为1，length是1。

2.5.2 Link ID

Link ID sub-TLV是链路另一端的标识。对于点到点链路来说，就是邻居的Router ID。对于多路访问链路来说，就是DR的接口的地址。Link ID等于router-LSA中的这些链路类型的Link ID的内容。

Link ID sub-TLV的type是2，length是4。

2.5.3 Local Interface IP Address

Local Interface IP Address sub-TLV指定了这个link对应的接口的IP地址。如果链路上有多个本地地址，则将它们全部列在sub-TLV中。

Local Interface IP Address sub-TLV的type是3，length是4N，N是本地地址的个数。

2.5.4 Remote Interface IP Address

Remote Interface IP Address sub-TLV指定了这个link对应的邻居的接口的IP地址。这个地址和上面的本地地址一起被用作多条平行链路的判定。如果Link Type是Multi-access，Remote Interface IP Address设置为0.0.0.0；具体的实现MAY选择不去发送这样的sub-TLV。

Remote Interface IP Address sub-TLV的type是4，length是4N，N是邻居地址的数量。

2.5.5 Traffic Engineering Metric

Traffic Engineering Metric sub-TLV指定了用于流量工程的链路metric。这个metric可能和标准的OSPF的link metric不不相等。一般来说，metric的值是由网络管理员指定的。

Traffic Engineering Metric sub-TLV的type是5，length是4。

2.5.6 Maximum Bandwidth

Maximum Bandwidth sub-TLV指定了在这条链路上的这个方向（从生成这个LSA的路由器到它的对端的邻居的方向）的能够通行的最大带宽，表示格式是IEEE floating point format。它表示了链路真实的能力，单位是bytes per second。

Maximum Bandwidth sub-TLV的type是6，length是4。

2.5.7 Maximum Reservable Bandwidth

Maximum Reservable Bandwidth sub-TLV指定了这条链路的这个方向上要预留的最大带宽，表示格式是IEEE floating point format。需要知道，这个值可能会比maximum bandwodth更大（这种情况下link可能会预订过载oversubscribed）。这个值SHOULD对用户来说是可配置的；默认值应该就是Maximum Bandwodth。其单位是bytes per second。

Maximum Reservable Bandwidth sub-TLV的type是7，length是4。

对于这个预留带宽的理解不是很清晰？是指预订了但是没有分配的吗？？？那么是谁预订的，又是怎样进行分配的呢？

2.5.8 Unreserved Bandwidth

Unreserved Bandwidth sub-TLV指定了在8个优先级别的每个级别上还没有预留的带宽的总和，其表示格式是IEEE floating point format。这些对应的带宽值能以0-7的启动级别被预留，其顺序是从级别0，到sub-TLV的终点级别7。在带宽被预留之前，所有级别的初始值都是Maximum Reservable Bandwidth。其单位是bytes per second。

Unreserved Bandwidth sub-TLV的type是8，长度是32个octets。

2.5.9 Administrative Group

Administrative Group sub-TLV包含了被网络管理员指定的4-octet长度的掩码。每个bit的设置都对应一个指定给接口的管理组（administrative group）。一个链路可能属于多个管理组。

按照管理，最低位bit被称为“group 0”，最高位bit被称为“group 31”。

Administrative Group也被称为Resource Class/Color [5]。

Administrative Group sub-TLV的type是9，length是4

type1-4这四种sub-tlv都可以在OSPFv2的前五种TLV中获取，还专门定义了这样的sub-TLV？？？TED的构建是不是完全不需要借力于LSDB呢？？？

3 Elements of Procedure

无论何时，只要LSA内容改变，以及OSPF的其它要求出现（比如LSA的刷新），路由器都应该生成TE LSAs。需要知道这并不意味着每个改变都必须要被立即泛洪；具体实现的时候MAY设置触发即时泛洪的阈值（比如，带宽改变阈值），以及较短时间间隔之后开始泛洪其它的改变。在任何情况下，TE LSAs的产生SHOULD有频率限制，生成时间间隔最短不能短于MinLSInterval[1]。

收到一个更改的TE LSA或者network-LSA（因为它们都要用于TE的计算）后，路由器应该更新它的TED。不需要执行SPF或者其它的路由算法。

4 Compatibility Issues

没有实现本文档的扩展的路由器之间不应该存在互操作性的问题，因为Opaque LSAs会被忽略。

网络中存在没有实现这些扩展的路由器的后果就是流量工程拓扑会有缺失，不能完全反映真实拓扑。然而，如果拓扑仍然是联通的，则TE路径仍然能够计算并且正常工作。

5 Security Considerations

本文档采用了OSPFv2中的Opaque LSAs来传递TE信息。由于Opaque LSAs不会用于最短路径计算或者正常的路由，本文档中引入的扩展对于IP路由没有什么影响。然而，针对TE LSAs的篡改会影响到流量工程的计算，出于安全考虑，任何一般OSPF LSAs传输所采用的保障安全的机制都应该等同地应用在所有的Opaque LSAs上，其中就包括这里提到的TE LSAs。

都不知道有啥保障安全的机制？？？

需要直到[1和[9]中提到的机制被应用于Opaque LSAs。建议未来提出的任何保障/认证OSPFv2 LSA 交换的机制都应该足以应用在Opaque LSAs上。

6 IANA Considerations

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.

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

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

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

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

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

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

7 Intellectual Property Rights Statement

知识产权声明。无用。

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.1 Normative References

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

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

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

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

8.2 Informative References

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

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

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

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

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

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

9 Authors’ Address

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

Phone: +1 408 745 2000
EMail: dkatz@juniper.net


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

Phone: +1 408 635-7900
EMail: myeung@procket.com


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

Phone: +1 408 745 2000
EMail: kireeti@juniper.net