メインコンテンツまでスキップ

RFC 3209 - RSVP-TE: LSPトンネルのためのRSVP拡張

  • ステータス: Proposed Standard
  • 発行日: December 2001
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要 (Abstract)​

本書は、マルチプロトコルラベルスイッチング（MPLS）ネットワークにおいて、リソース予約プロトコル（RSVP）を使用してラベルスイッチパス（LSP）を確立する方法について記述しています。RSVPを使用して確立されたLSPは、明示的ルーティング機能の有無にかかわらず使用できます。明示的ルーティングが使用される場合、RSVP-TEは、ネットワーク層のルーティングプロトコルによって計算された最短パスとは異なるLSPをインスタンス化することを可能にします。この機能は、トラフィックエンジニアリングや差別化サービスの提供において極めて重要です。

1. はじめに (Introduction)​

マルチプロトコルラベルスイッチング（MPLS）[2]は、ラベルスイッチング転送とネットワーク層ルーティングを組み合わせた技術です。MPLSの基本的なアプリケーションの一つは、トラフィックエンジニアリング（TE）[3]です。トラフィックエンジニアリングにより、ネットワークオペレーターは、リソース利用率とネットワークパフォーマンスを最適化するために、ネットワークを通るトラフィックの経路を制御できます。

MPLSトラフィックエンジニアリングをサポートするためには、ラベルスイッチパス（LSP）を確立および維持するメカニズムが必要です。RSVP [1]は成熟したシグナリングプロトコルであり、LSPの確立をサポートするために拡張されています。本書は、特にトラフィックエンジニアリングアプリケーション向けに、MPLS LSPの確立をサポートするためのRSVPの拡張を定義しています。

本書で定義されている拡張により、RSVPは以下の用途に使用可能となります：

  1. 明示的にルーティングされたLSPの確立。
  2. 「メイク・ビフォア・ブレイク」（切断前接続）方式によるLSPのリルート。
  3. LSPのループ検出のサポート。
  4. LSP確立プロセス中のラベル配布のサポート。

2. 用語 (Terminology)​

本書では、RFC 3031 [2]およびRFC 2205 [1]で定義されている用語を使用します。さらに、以下の用語も使用されます：

  • LSPトンネル (LSP Tunnel)：MPLSネットワークにおいて、ラベルスイッチパスによって確立されるトンネル。
  • LSP ID：特定のLSPを識別するための識別子。
  • トンネルID (Tunnel ID)：1つ以上のLSPを含む可能性のあるトラフィックエンジニアリングトンネルを識別するための識別子。
  • 拡張トンネルID (Extended Tunnel ID)：トンネルをグローバルに一意に識別するための識別子。

3. RSVP拡張の概要 (Overview of RSVP Extensions)​

RSVPプロトコルは、PathおよびResvメッセージを通じてリソース予約状態を確立および維持します。LSPトンネルをサポートするために、いくつかの新しいオブジェクトが導入されました：

  • LABEL_REQUEST オブジェクト：Pathメッセージで伝送され、ダウンストリームノードに対してラベルの割り当てを要求します。
  • LABEL オブジェクト：Resvメッセージで伝送され、割り当てられたラベルをアップストリームノードに配布します。
  • EXPLICIT_ROUTE オブジェクト (ERO)：Pathメッセージで伝送され、LSPが通過しなければならない明示的な経路を指定します。
  • RECORD_ROUTE オブジェクト (RRO)：PathおよびResvメッセージで伝送され、LSPが実際に通過した経路とラベルを記録します。
  • SESSION_ATTRIBUTE オブジェクト：Pathメッセージで伝送され、優先度、プリエンプション、アフィニティ（親和性）などのLSP属性を制御します。

4. オブジェクト定義 (Object Definitions)​

4.1. LABEL オブジェクト​

LABELオブジェクトは、Resvメッセージで割り当てられたラベルを伝送するために使用されます。

Class = 16, C_Type = 1

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           (Label)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. LABEL_REQUEST オブジェクト​

LABEL_REQUESTオブジェクトは、Pathメッセージでラベルバインディングを要求するために使用されます。

Class = 19, C_Type = 1 (ラベル範囲なし)

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

L3PIDは、このパス上で伝送されるレイヤ3プロトコル（通常はEthertype）を識別します。

4.3. EXPLICIT_ROUTE オブジェクト (ERO)​

EROは、明示的な経路を指定するために使用されます。これは一連のサブオブジェクト（Subobjects）を含み、各サブオブジェクトは経路上の抽象ノードを表します。

Class = 20, C_Type = 1

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (Subobjects)                          //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

サブオブジェクトのタイプには以下が含まれます：

  • Type 1: IPv4プレフィックス
  • Type 2: IPv6プレフィックス
  • Type 32: 自律システム番号 (AS Number)

各サブオブジェクトにはLビット（Loose bit）もあります。L=0の場合、厳密なホップ（Strict hop）を示し、L=1の場合、緩やかなホップ（Loose hop）を示します。

4.4. RECORD_ROUTE オブジェクト (RRO)​

RROは、LSPが実際に通過した経路を記録するために使用されます。ラベル情報を含めることもできます。

Class = 21, C_Type = 1

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (Subobjects)                          //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5. SESSION_ATTRIBUTE オブジェクト​

このオブジェクトは、優先度やリソースアフィニティなどのセッション属性を制御します。

Class = 207, C_Type = 7 (LSP_TUNNEL)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//          Session Name      (NULL padded display string)      //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flagsフィールドは以下のフラグを定義します：

  • 0x01: Local protection desired（ローカル保護/高速リルートを希望）
  • 0x02: Label recording desired（ラベル記録を希望）
  • 0x04: SE Style desired（SEスタイルを希望、メイク・ビフォア・ブレイクに使用）

4.6. SESSION および SENDER_TEMPLATE オブジェクト​

LSPトンネルをサポートするために新しいC-Typeが定義されました。

  • LSP_TUNNEL_IPv4 Session Object (C-Type = 7)
  • LSP_TUNNEL_IPv6 Session Object (C-Type = 8)

Tunnel IDおよびExtended Tunnel IDを含みます。

  • LSP_TUNNEL_IPv4 Sender Template Object (C-Type = 7)
  • LSP_TUNNEL_IPv6 Sender Template Object (C-Type = 8)

LSP IDを含みます。

5. Hello 拡張 (Hello Extension)​

RSVP Hello拡張により、RSVPノードは隣接ノードが到達不能になったことを検出できます。これにより、ノード間の障害検出メカニズムが提供されます。

Helloメッセージフォーマット：

<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>

HELLOオブジェクト (Class 22) には2つのタイプがあります：

  • HELLO REQUEST (C-Type = 1)
  • HELLO ACK (C-Type = 2)

これらは、ノードの再起動や通信の損失を検出するための送信元インスタンス（Src_Instance）および宛先インスタンス（Dst_Instance）の値を含みます。

6. セキュリティに関する考慮事項 (Security Considerations)​

原則として、これらの拡張はRFC 2205 [1]以上のセキュリティリスクをもたらすものではありません。しかし、信頼モデルには若干の変更があります。トラフィックはラベルに基づいて転送されるため、管理者はLSPトンネルを確立できるドメインを制限したいと考えるかもしれません。

7. IANA に関する考慮事項 (IANA Considerations)​

本書は、新しいオブジェクトクラス（Class Numbers）とタイプ（C-Types）、およびエラーコードを定義しています。

8. 参考文献 (References)​

[1] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205. [2] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031. [3] Awduche, D., et al., "Requirements for Traffic Engineering over MPLS", RFC 2702.

翻訳者注: 本書はRFC 3209の日本語参考訳です。

に最終更新