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.

版權聲明

摘要

本文檔描述了針對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被定義：

Link type（1 octet）
Link ID（4 octets）
Local interface IP address（4 octets）
Remote interface IP address（4 octets）
Traffic engineering metric（4 octets）
Maximum bandwidth（4 octets）
Maximum reservable bandwidth（4 octets）
Unreserved bandwidth（32 octets）
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定義了鏈路的類型：

Point-to-point
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.

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: [email protected]


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

Phone: +1 408 635-7900
EMail: [email protected]


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

Phone: +1 408 745 2000
EMail: [email protected]

RFC3630 - TE Extensions to OSPF Version 2中文