社団法人 電子情報通信学会THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報TECHNICAL REPORT OF IEICE.

GMPLSシグナリングによるE-tree確立に向けたRSVP-TE拡張の実装菊田 洸† 石井 大介† 岡本 聡† 山中 直明†

† 慶應義塾大学 大学院 理工学研究科 〒 212–0032 川崎市幸区新川崎 7-1 I棟 101E-mail: †kikuta@yamanaka.ics.keio.ac.jp

あらまし 本研究では，次世代の広域イーサネットを想定し，複数拠点間接続サービスである E-tree 実現ためのP2MP(Point-to-MultiPoint)パスの確立を，独自実装したGMPLSプログラムを用いて実験ネットワークで確認した．GMPLSシグナリングによる P2MPパスの確立手法は IETFの発行する標準化提案 “RFC4875”によって定められているが，具体的なノードの振る舞いなどについては言及されていない．そこで，本研究では “RFC4875”に基づいて拡張されたプロトタイプの RSVP-TEを実装し，具体的なノードの振る舞いを定義することで，GMPLSシグナリングによる P2MPパスの確立を行った結果を報告する．キーワード GMPLS，RSVP-TE，P2MP，E-tree

Implementation of RSVP-TE extension for establishment E-tree in

GMPLS framework

Kou KIKUTA†, Daisuke ISHII†, Satoru OKAMOTO†, and Naoaki YAMANAKA†

† Graduate School of Science and Technology, Keio UniversityI–101, 7–1 Shinkawasaki, Saiwai-ku, Kawasaki, 212–0032 JAPAN

E-mail: †kikuta@yamanaka.ics.keio.ac.jp

Abstract In this paper, experimental results of GMPLS controlled P2MP (Point-to-MultiPoint) path setup on

a testbed Ethernet based Wide-Area-Ethernet are reported. With this P2MP path provision, a bi-directional con-

nection service among multiple points will be achieved. The IETF published a proposed standard document for

the (G)MPLS signaling of P2MP path establishment, “RFC4875”, but this document did not specify the detail of

node behavior. To clarify node behavior, we implemented a prototype RSVP-TE program based on “RFC4875”

and successfully achieved P2MP path provisioning with GMPLS signaling.

Key words GMPLS, RSVP-TE, P2MP, E-tree

1. 背 景

近年，イーサネット通信速度の高速化は進み，10Gbpsの超高速インタフェースが実用化されている．これに伴い，通信事業者による広域イーサネットサービスの提供が注目を浴びている．広域イーサネットサービスとは，「広域に分散している加入者の拠点間において，イーサネットフレームをそのままの形で伝送する通信技術」[1]により提供されるサービスであり，仮想専用線や VPN(Virtual Private Network)提供技術の 1つである．このサービスにより接続された LAN上のユーザは，広域ネットワークを意識することなく，あたかも同一 LAN上のように対地間の通信を行うことが可能となり，企業の拠点間 LAN

接続技術としての需要が高い．通信事業者が広域イーサネットサービスを提供する手段としては，主に a) Native Ethernet

方式，b) SDH/OTN伝達方式，c) Ethernet over MPLS方式の 3種類に分類される [2]．イーサネットの低価格性や高速性を生かすために，広域ネットワーク内でもイーサネットスイッチを使用してデータを転送する方式が a)の Native Ethernet 方式で，具体的には PB(Provider Bridges) [3]や PBB(Provider

Backbone Bridges) [4]のような VLAN (Virtual LAN)スタック技術や Mac-in-Mac 技術を利用する．一方，SONET/SDH

(Synchronous Optical NETwork /Synchronous Digital Hier-

archy)や OTN (Optical Transport Network)によって構築された既存のパスネットワークを通して，イーサネットフレームを転送する方式 (Ethernet over SDH/OTN) が b) である．そしてパケット伝送技術であるMPLS (Multi-Protocol Label

Switching) によりイーサネットフレームをカプセル化し転送を行う方式が C)の Ethernet over MPLS方式である．これら

— 1 —

Customer LAN

Customer LAN

Customer LAN

Customer LAN

Customer LAN

E-line

E-tree

GMPLS Control-Plane

GMPLS Data-Plane

INGRESS node

RSVP-TE message

RSVP-TE Signaling

OSPF-TE messageEGRESS node

An Ethernet frame with

VLAN Tag Headder (ID = 50)

Point-to-MultiPoint PATH

with VLAN ID = 300

Point-to-Point PATH with VLAN ID = 50

Provider Network Switch

Customer Network Switch

Control Node

図 1 ネットワークアーキテクチャ

の 3 つの方式は実現化のための様々な研究開発がなされているが，中でも a) の Native Ethernet 方式は，通信速度に関して非常に優れた費用対効果を発揮する．現在，イーサネットは100Gbpsに達する超高速通信に向けた標準化がすすめられており，SONET/SDHに代わる新たな通信事業者ネットワークの通信技術としてイーサネットは大きな期待を浴びている．国内外を問わず，Native Ethernet方式を用いた広域イーサネットの提供に向けて，大きな期待がかかっている [5]．ただし，Native

Ethernet方式においても，イーサネットスイッチ間の伝送技術として OTNを利用する事も十分に考えられる．広域イーサネットでは，E-line [6]という基本サービスによっ

て 2つの拠点間を接続する．Native Ethernet方式で E-lineを提供するためには，ネットワーク上のスイッチはVLANの技術を用い，拠点間を結ぶ Point-to-Pointのパスを確立する．ネットワーク上には複数のユーザへとサービスを提供するための複数のパスが同時に存在し，各スイッチは到着するフレームに付与された VLANタグを基にして，そのフレームがどのパスに帰属しているかを識別し転送を行う．しかし，このパスを確立するためには広域ネットワーク上に存在するスイッチのVLAN

を適切に設定する必要があり，このVLANの効果的な設定が広域イーサネットにおける最重要課題といえる．この課題を解決するべく IETF (Internet Engineering Task Force)は，GELS

(GMPLS controlled Ethernet Label Switching) [7] と呼ばれる VLANの自動設定に向けたフレームワークの標準化に向けた取り組みを行っており，ネットワーク制御プロトコルであるGMPLS (Generalized Multi-Protocol Label Switching) [8]をトラヒックエンジニアリング可能な VLAN設定プロトコルとして用いることにより，自律分散的な Point-to-Pointパス自動制御が達成される．

GMPLS は，ネットワーク制御のための各種プロトコルの集合であり，SONET/SDH や OTN など様々なネットワークに対しパス設定の自動化を行う．GMPLS で制御されるネッ

トワークは IP ネットワークとは異なり，データ転送に先立って LSP (Label Switched Path) と呼ばれる通信路を確立するというコネクションオリエンテッドと呼ばれる大きな特徴を持つ．LSP の確立を自律分散制御により実現するためには，ネットワーク上のスイッチが互いに情報を交換し，ルーチングプロトコルやシグナリングプロトコルを利用する．GMPLS

では，シグナリングプロトコルとして RSVP-TE (Resource

reSer-Vation Protocol-Traffic Engineering) [9]，ルーチングプロトコルとして OSPF-TE (Open Shortest Path First-Traffic

Engineering) [10]，リンク管理プロトコルとして LMP (Link

Management Protocol) [11]の 3つのプロトコルが定められており，これらのプロトコルに基づいた制御により，ユーザからの要求に応じて LSPが確立される．GMPLSは，国際的な標準化が進められており，様々なネットワーク装置を統一的に制御するためには，実装ネットワーク上での実証実験による仕様へのフィードバックが重要である．イーサネットが持つ別の特徴として，複数のあて先への同

じデータの送信，すなわちマルチキャスト／ブロードキャストが標準的にサポートされているという点が挙げられる．近年ではビデオストリーミングやテレビ会議など，マルチキャストを必要とする様々なアプリケーションの普及が進んでおり，また広域イーサネットにおいても複数拠点を接続する要求はきわめて高い．そのため広域イーサネット上で複数拠点を接続する E-tree サービスの提供は通信事業者に取って必要不可欠である．この E-tree の提供のためには，ネットワーク上に P2MP (Point-to-MultiPoint)パスを確立することが前提となる．しかし，P2MPパスは経路にいくつもの分岐点を含み，Point-to-Pointパスに比べてネットワークの制御やパスの管理が複雑となることは明らかである．そのため，GMPLSによるP2MP LSP確立自動化は，広域イーサネット上での E-treeの実現にむけて非常に期待の高い技術であると言える．本研究では，2007 年 5 月に IETF より発行された標準化

— 2 —

提案，“RFC4875 Extensions to Resource Reservation Proto-

col - Traffic Engineering (RSVP-TE) for Point-to-Multipoint

TE Label Switched Paths (LSPs)” [12]に基づき，プロトタイプの RSVP-TE プログラムの拡張を行い，広域イーサネット網を想定した実験ネットワークにおいて P2MP LSPの確立自動化を実現した．これにより，GMPLS制御による広域イーサネット上へと，E-treeサービスが実現されることを示した．

2. ネットワークアーキテクチャ

2. 1 想定ネットワーク図 1に，対象とする広域イーサネットのネットワークアーキ

テクチャを示す．このネットワークはGMPLSによって制御されており，論理的に制御プレーン (Control-Plane)とデータプレーン (Data-Plane)に分離される．LSPはデータプレーン上に確立され，この LSPにより E-lineや E-treeのサービスが提供される．図 1のネットワークは Native Ethernet方式によりこれらのサービスを提供しており，データプレーン上に分布するスイッチは VLANタグに基づいた転送を行う．制御プレーンでは LSP確立のための制御情報の交換が行われる．LSP確立の要求が生じた際には，その LSP 経路上の全のスイッチにVLANを設定することにより LSPを確立する．新たな LSPを確立するために必要な処理は，1)ネットワー

クトポロジを確認し，経路の候補を決定．2) 経路上の全てのリンクの，空いている帯域を確認．3)経路上の全てのスイッチで使用可能な VLAN ID の確認．4) 経路上の全てのスイッチへと，パス確立のための VLAN ID と帯域の通知．の 4 つである．本稿では 4)のシグナリングに焦点を当て，P2MP LSP

のための拡張に関して述べる．前提として，経路情報の交換はOSPF-TEプロトコルによって行われ，すべてのスイッチへのシグナリングは RSVP-TEプロトコルによって行われる．リンクプロパティの交換や，リンクの正常性確認などを行う LMP

については，本稿の範囲外とする．

2. 2 RSVP-TEの拡張LSPの確立のために，RSVP-TEプロトコルに基づいた制御

メッセージによるやりとりが経路上の全てのスイッチの間で必要となる．この制御メッセージは要求を受けたノード (INGRESS)

からあて先のノード (EGRESS) まで，実際の LSP の経路に沿って転送され，EGRESS ノードで折り返して戻ってくる．LSP確立のために INGRESSノードが EGRESSノードへ送る制御メッセージを PATHメッセージといい，予約されたリソースに関する情報を通知するため，EGRESS ノードから戻ってくる制御メッセージを RESVメッセージと呼ぶ．

PATH および RESV のメッセージは TLV (Type-Length-

Value) エンコード形式により記述されており，メッセージは可変長で様々な情報を運ぶことができる．RSVP-TE では制御情報を含むそれぞれの TLV の単位をオブジェクトと呼び，RSVP-TEが拡張されるたびに新しいオブジェクトが定義される．オブジェクトには，メッセージと LSP と関連づけるオブ

ジェクトや，送信ノードの特徴，送信されるトラヒックの特徴，割り当てられたラベル，経路を表すオブジェクトなどが存在する．現在定義されているオブジェクトの種類と，そのオブジェクトが参照する標準化書類の一覧は，[13]に記述されている．

3. 実 装

3. 1 新規オブジェクトの定義E-tree 実現のために，RSVP-TE を拡張し，P2MP パスの

確立を可能とした．この実装のために使用した標準化提案，“RFC4875”において，新たに定義されたオブジェクトのいくつかを次に示す．

3. 1. 1 SESSIONオブジェクトの追加まず，確立されるセッションが P2MPであることを表すため

に，SESSIONオブジェクトに新たな P2MP LSP Tunnel IPv4

(および IPv6) SESSIONオブジェクトが定義された．このオブジェクトは P2MP, Tunnel ID, Extended Tunnel IDの情報を持つが，従来と異なる点としてDestination AddressやTunnel

End Point Address が P2MP に置き換えられている．P2MP

ID は P2MP セッションの識別子を提供し，<P2MP, Tunnel

ID, Extended Tunnel ID> の組により P2MP Tunnel が識別される．P2MP LSP Tunnel IPv4 SESSION オブジェクトのC-type(Class type)は 13であり，IPv6の場合は 14である．

3. 1. 2 SENDER TEMPLATEオブジェクトの追加SENDER TEMPLATE オ ブ ジェク ト に も 拡 張 が な

され，新たな P2MP LSP Tunnel IPv4(および IPv6)

SENDER TEMPLATE オブジェクトが定義された．このオブジェクトは Tunnel Sender Address, LSP ID, Sub-Group

Originator ID, Sub-Group IDの 4つの情報を持つ．<Tunnel

Sender Address, LSP ID> の組は，先の SESSION オブジェクトの <P2MP, Tunnel ID, Extended Tunnel ID>の組と共に P2MP LSPの識別に用いる．そして新たに加えられた Sub-

Group Originator IDおよび Sub-Group IDは，複数のRSVP

メッセージによりシグナリングが行われる場合，複製されたそれぞれのメッセージを識別するために使用される．Sub-Group

Originator ID はメッセージを複製したノードのアドレスが書き込まれ，その Sub-Group Originator ID 上で固有な値がSub-Group IDへと書き込まれる．すなわち，1つのノードで複製されたメッセージを複数生成する場合，Sub-Group IDは異なる値をとる．Sub-Group Originator ID および Sub-Group

ID の書き換えについては 3. 2 節にて説明する．P2MP LSP

Tunnel IPv4 SENDER TEMPLATE ObjectオブジェクトのC-typeは 12で，IPv6の場合は 13である．

3. 1. 3 S2L SUB LSPオブジェクトの定義S2L(Source-to-Leaf) Sub-LSP と は ，Source ノ ー ド

(INGRESS ノード) からそれぞれの Leaf ノード (EGRESS

ノード) までの Point-to-Point パスを示し，P2MP LSP は複数の S2L Sub-LSPの集合である．1つの S2L Sub-LSPを表す

— 3 —

A

B

C

F

D

E

G

H I

INGRESS node

(1)

(3)

(4)(2)

(5)

EGRESS nodes

S2L_SUB_LSP: E

S2L_SUB_LSP: F

SERO : C - F

ERO : B - C - D - E

S2L_SUB_LSP: H

SERO : C - G - H

S2L_SUB_LSP: I

SERO : H - I

ERO : G - H

S2L_SUB_LSP: H

S2L_SUB_LSP: I

SERO : H - I

S2L_SUB_LSP: F

ERO : F

S2L_SUB_LSP: I

ERO : I

S2L_SUB_LSP: E

ERO : D - E

to (2)

to (3)

to (4)

図 2 P2MP シグナリングの例

オブジェクトが S2L SUB LSPオブジェクトクラスであり，その S2L SUB LSPオブジェクトは EGRESSノードのアドレスを含む．EGRESSノードのアドレスを IPv4 (および IPv6)によって表す S2L SUB LSP IPv4 (IPv6)オブジェクトが定義されている．RSVPメッセージには，確立される P2MP LSPのEGRESSノードの数だけ S2L SUB LSPオブジェクトが含まれている．S2L SUB LSPオブジェクトクラスのクラス番号は50で，S2L SUB LSP IPv4オブジェクトのC-typeは 1，IPv6

の場合は 2である．

3. 1. 4 SEROの追加SECONDARY EXPLICIT ROUTE Object (SERO) は

LSP 上の二つ目の経路を表すオブジェクトであり，障害回復のための代替経路を表すオブジェクトとして RFC4873 [14]

において定義されている．P2MP LSPの場合は，分岐ノードからの経路が SEROによって表されており，そのオブジェクトはP2MP SECONDARY EXPLICIT ROUTEオブジェクトと呼ばれる．RSVP メッセージ内では，P2MP SERO オブジェクトは関連する S2L SUB LSP オブジェクトの直後にエンコードされることにより，その S2L Sub-LSP の経路を示す．メッセージのサイズを最低限にするために，P2MP SERO は分岐ノードからの経路しか示されていないことに注意が必要である．また，メッセージの最初に登場する S2L SUB LSPオブジェクトの直後に SERO は必要なく，この S2L Sub-LSP の経路はExplicit Route Object (ERO)にて表されている．P2MP SEC-

ONDARY EXPLICIT ROUTEオブジェクトのフォーマットは SEROおよび EROと同じであり，C-typeは 2である．

3. 2 P2MPシグナリングP2MP LSP のシグナリングにおいて，分岐ノードでのメッ

セージ処理は非常に重要である．ここでは例として，図 2を用いて説明する．図 2では INGRESSノードであるノード Aから，EGRESSノードであるノード E, F, H, Iへと P2MP LSP

を確立しようとしている．ノード Aから送られるメッセージ (1)には，EGRESSノー

ドであるノード E, F, H, I それぞれを表すために 4 つのS2L SUB LSP オブジェクトが含まれている．メッセージ内での S2L SUB LSP オブジェクトの順序は，経路情報であるEROや SEROへと影響するため，E，F，H，Iという順序に注意が必要である．最初の S2L SUB LSPオブジェクトによって示されるノード Eについては，[→B→C→D→E]という経路をメッセージ内の EROへとエンコードする．それ以外のノードF, H, Iのための経路は SEROによって表し，これらの SERO

は対応する S2L SUB LSPオブジェクトの直後へとエンコードする．ノード Fの SEROは [→C→F]，ノード Hの SEROは[→C→G→H]，ノード Iの SEROは [→H→I]であり，これらの経路は分岐ノードであるノード Cや Hからの経路しか含まれていない．P2MPシグナリングでは，メッセージのサイズを可能な限り小さくするために，P2MP LSP の経路は最低限の情報で記述されている．メッセージ (1) がノード C へと到着すると，ノード C は

メッセージの複製処理を行う．この処理ではメッセージ (1)

を基にしてメッセージ (3) および (4) を生成する．メッセージ (3) と (4) は，S2L SUB LSP オブジェクトおよび SERO

を除いた全てのオブジェクトがメッセージ (1) の複製である．そして，生成されたそれぞれのメッセージの識別のために，SENDER TEMPLATE オブジェクトの Sub-Group Origina-

tor ID および Sub-Group ID の書き換えを行う．まず，メッセージ (3) と (4) の Sub-Group Originator ID へ，複製したノードであるノード Cのアドレスを代入する．次に，メッセージ (3)と (4)の Sub-Group IDへと，それぞれ異なる値を代入する．これらの 2 つの ID により，複製されたメッセージ (3)

と (4)および基にしたメッセージ (1)の識別が可能となる．メッセージ (1)に含まれていた S2L SUB LSPオブジェクト

および SEROは複製せずにメッセージ (2)，(3)，(4)へと適切に分配する．メッセージ (1)の 4つの S2L SUB LSPオブジェクトのうち，ノード E を示す S2L SUB LSP オブジェクトは(2)へ，ノード Fを示す S2L SUB LSPオブジェクトは (3)へ，ノードHおよび Iを示す 2つの S2L SUB LSPオブジェクトは(4)へと分配する．SEROも関連する S2L SUB LSPオブジェクトを含むメッセージへと分配されるが，最初の S2L SUB LSP

オブジェクトの直後の SEROは EROへと変換されなければならない．例えば，メッセージ (4)の最初の S2L SUB LSPオブジェクトはノード Hを示し，2つ目の S2L SUB LSPオブジェクトはノード Iを示す．最初の S2L SUB LSPオブジェクトまでの経路は EROによって表す決まりであるため，生成されたメッセージ (4)は，Hまでの経路を EROへエンコードしている必要がある．そのため，メッセージ (4)の EROへと，メッセージ (1)に含まれるノード Hまでの SEROである [→G→H]

をエンコードする．同様に，メッセージ (3) やメッセージ (5)

の複製処理においても，SEROから EROの変換が行われる．

— 4 —

1.1.1.1

3.3.3.3

4.4.4.4

5.5.5.5

6.6.6.6 8.8.8.8

7.7.7.7

9.9.9.9

2.2.2.2

GMPLS Data-plane

GMPLS Control-plane

Sender

Receivers

Ethernet Switch

Control node

図 3 実験ネットワーク

3. 3 メッセージの処理図 2の例を用いて，メッセージ処理の流れを説明する．メッ

セージを受け取った全てのノードは，まずメッセージに含まれる全ての SEROをチェックし，SEROの最初の 1ホップ目が自分のアドレスを示していないかチェックする．もしも自分のアドレスだった場合，そのノードは分岐ノードである．ノード Cは受信したメッセージ (1)をチェックし，最初に出現するノード F

あての SEROの 1ホップ目が自分のアドレスを示していることを発見する．その後，ノード Fを表す S2L SUB LSPオブジェクト以降を切り離し，メッセージ (3)の生成の準備をする．ここで，ノードCで複数の分岐が起こることに注意が必要である．切り離されたメッセージにはノード Hの SEROやノード IのSEROを含み，これらはメッセージ (4)としてノードGへと転送されなければならない．つまり，切り離されたメッセージについては，引き続き SEROのチェックが必要となる．ノード C

は，ノードH宛の SEROの 1ホップ目も自分のアドレスを示すことを発見し，ノードHを表す S2L SUB LSPオブジェクト以降を切り離す．全ての SEROのチェックが終了すると，切り離された 2つのメッセージに対して SEROから EROの変換を行い，また Sub-Group Originator IDおよび Sub-group IDの書き換えを行う．これらにより，異なる SENDER TEMPLATE

の値を持つメッセージ (2)，(3)，(4)が生成される．その後の各メッセージの処理は Point-to-Pointと同様で，自分のノードがEGRESSであるかの確認を行う．EGRESSの場合 RESVメッセージの生成を行い，そうでない場合は下流側ラベルの確保と，上流ラベルと関連付けを行う．P2MPの場合は，EGRESSノードのアドレスは SESSIONオブジェクトではなく，メッセージ内で最初に出現する S2L SUB LSPオブジェクトによって表されていることに注意が必要である．

4. 実験および結果

図 3に，本実験における実験ネットワーク構成を示す．このネットワークは図 1の広域イーサネットを想定したもので，1

Gigabit Ethernet Switches (NETGEAR, GSM7212)

RS-232C

Extended GMPLS programs on Linux PCs

Control-Plane

Data-Plane

GMPLS node

図 4 実 験 装 置

図 5 RSVP メッセージのキャプチャ

つの送信ノードから 4 つの受信ノードまでの P2MP LSP を1.1.1.1から 9.9.9.9までの 9つのノード間に確立した．図 4に，本実験にて使用した装置を示す．制御プレーンは 2台の Linux

PCから構成され，それぞれに仮想マシンを 4台稼働させ，各仮想マシンにおいてプロトタイプの拡張 RSVP-TE プログラムを動かす事により，仮想的に 8 台の GMPLS 制御ノードを構築した．このプロトタイプの拡張 RSVP-TEプログラムは，NTT-ATにより開発された GMPLSミドルウェア，“GMPLS

Engine”のソースコードを基に，P2MP LSP確立の機能を独自に拡張したものである．データプレーンは市販の NETGEAR

社製イーサネットスイッチを 8台使用し，シリアルケーブルを介して制御プレーンの各 GMPLS 制御ノードによって制御される．図 5 に，実装ネットワーク上にて交換された PATH メ

— 5 —

ッセージを示す．SESSION オブジェクトは C-type が 13，SENDER TEMPLATEオブジェクトの C-typeが 12であり，いずれも IPv4の P2MP LSPを表す．SESSIONには Tunnel

End Point Addressの代わりにP2MP IDが含まれており，またSENDER TEMPLATE オブジェクトにも Sub-Group Origi-

nator ID および Sub-Group ID が加えられている．そしてEGRESSノードのアドレスを表す S2L SUB LSPオブジェクトは 4つ含まれており，1つめの S2L SUB LSPオブジェクトにより表される 5.5.5.5 への経路は ERO へと，それ以外の経路は S2L SUB LSP オブジェクトの直後にある SERO によって分岐ノードからの経路として表されている．本実験では，広域イーサネットを想定した実装ネットワーク

を，RFC4875により拡張されたプロトタイプ RSVP-TEプログラムを用いて制御し，パス確立自動化の実験を行った．拡張された RSVP-TEは適切に制御メッセージを交換し，これにより P2MP LSPが自律分散的に確立され，E-treeが構築されることを確認した．

5. MP2MPに向けた今後の検討課題

本実験では，E-treeを想定した P2MP LSPの確立を行った．しかし，イーサネットは双方向通信技術であり，Point-to-Point

での受信ノード同士の通信，すなわちMP2MP (MultiPoint-to-

MultiPoint)のための LSPも広域イーサネット上では容易に確立できるだろう．本稿は，広域イーサネット上でのMP2MP確立の第一歩として，P2MPを実現したものである．このMP2MP

LSP を確立する上で，今後に検討すべき事項を 3 点述べる．(1)MP2MP LSPにて許容するトポロジ．複数の拠点から拠点へと送信されるトラヒックを一点に集中させるスター型のトポロジか，それとも分散される他のトポロジであるべきかという問題がある．広域イーサネットのように STP (Spanning Tree

Protocol)を利用しない場合は，MP2MPのトポロジに閉回路を持つことが望ましくない事を考慮する必要がある．(2)トラヒック帯域表示．Point-to-Pointや P2MPでは送信ノードは 1

つであるが，MP2MPではエッジ／リーフの各ノードから他のエッジ／リーフノードへとトラヒックが発生することが一般的である．従って，確保すべき帯域はリンクごとに，また方向ごとに異なる．これらを全て RSVP-TE上で表すためには，現状の非対称帯域確保を目的とした “RFC5467” [15]では不十分であり，何らかの拡張が必要である．(3)LSP生成／削除の管理問題．P2MP LSPでは送信ノードは 1つであるため，INGRESS

ノードが LSPから離脱するということはありえない．もし離脱するならば，E-tree サービス終了に伴う P2MP LSP の全体削除である．しかしMP2MP LSPでは，INGRESSノード(Initiator) が LSP から離脱した場合にも，他のノード同士が通信するために LSPを残す可能性もある．そのため，MP2MP

LSPでは，インターネット上の Peer-to-Peer Networkにおける権限移譲のように，INGRESS 以外のノードも対等に LSP

のステートを保持するなどの拡張が必要になる．

6. 結 論

本稿では，Native Ethernet方式を用いた GMPLS制御の広域イーサネットを想定し，テストネットワーク上にて P2MP

LSPの確立に成功したことを報告した．P2MP LSP確立のための RSVP-TE拡張は RFC4875に基づいて行い，プロトタイプの RSVP-TEプログラムを用いて，イーサネットスイッチ 8

台から構成されるテストネットワーク上へ P2MP LSPを確立した．本実験結果により，GMPLS制御による広域イーサネット上にて，E-treeサービスを実現可能であることを示した．

謝辞 本研究の一部は，独立行政法人情報通信研究機構(NICT)の委託研究「λアクセス」技術の研究開発の一環として行われた．関係者各位に深謝する．

文 献[1] 阿留多伎 明良, “広域イーサネット技術概論,” 電子情報通信学

会, ISBN:4-88552-211-0, 2005 年 7 月.

[2] 岡本 聡, “キャリアイーサネットにおけるコントロールプレーン技術,” 電子情報通信学会, 信学ソサエティ大会 2009, BP-3-5,

2009 年 9 月.

[3] IEEE Std 802.1ad, “IEEE Standards for Local and

Metropolitan Area Networks - Virtual Bridged Local Area

Networks Amendment 4: Provider Bridges,” IEEE Stan-

dard, May 2006

[4] IEEE Std 802.1ad, “IEEE Standards for Local and

Metropolitan Area Networks - Virtual Bridged Local Area

Networks Amendment 7: Provider Backbone Bridges,”

IEEE Standard, May 2006

[5] Kerim Fouli, et al, “The Road to Carrier-Grade Ethernet,”

IEEE Communications Magazine, Vol.47, No.3, pp.S30-S38,

March 2009.

[6] METRO ETHERNET FORUM (MEF) Technical Spec-

ification 10.1, “Ethernet Services Attributes Phase 2,”

http://metroethernetforum.org/, June 2008

[7] Don Fedyk, et al, “Generalized Multi-Protocol Label

Switching (GMPLS) Ethernet Label Switching Architecture

and Framework,” IETF Internet Draft, draft-ietf-ccamp-

gmpls-ethernet-arch-05, Spt. 2009.

[8] E. Mannie. (Editor), “Generalized Multi-Protocol Label

Switching (GMPLS) Architecture,” IETF RFC 3945, Oct.

2004

[9] D. Katz (Editor), et al. “Generalized Multi-Protocol

Label Switching (GMPLS) Signaling Resource ReserVa-

tion Protocol-Traffic Engineering (RSVP-TE) Extentions,”

IETF RFC 3473, Jan. 2003.

[10] L. Berger (Editor), “Traffic Engineering (TE) Extensions to

OSPF Version 2,” IETF RFC 3630, Sept. 2003.

[11] J. Lang (Editor), “Link Management Protocol (LMP),”

IETF RFC 4204, Oct. 2005.

[12] R. Aggarwal (Editor), et al. “Extensions to Resource Reser-

vation Protocol - Traffic Engineering (RSVP-TE) for Point-

to-Multipoint TE Label Switched Paths (LSPs),” IETF

RFC 4875, May 2007.

[13] Internet Assigned Numbers Authority, “Resource Reserva-

tion Protocol (RSVP) Parameters,” http://www.iana.org/

assignments/rsvp-parameters, Spt. 2009.

[14] L. Berger (Editor), et al. “GMPLS Segment Recovery,”

IETF RFC 4873, May 2007.

[15] L. Berger (Editor), et al. “GMPLS Asymmetric Bandwidth

Bidirectional Label Switched Paths (LSPs),” IETF RFC

5467, May 2009.

— 6 —