相互接続実験で実装の相違による様々な出来事
MPLS JAPAN 2003
平成15年10月21日
古河電気工業株式会社
ファイテルネットワーク研究所
村上 哲也
murakami@inf.furukawa.co.jp
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

1古河電工（株）とは・・・
まだまだ、ルータメーカとしての知名度は低いですが・・・

ルータ作っています！！
ルータメーカとして約20年ほどの歴史があります！！
ルータメーカとしての知名度UPのため頑張ってます！！

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

2古河電工の提供するFITELnetシリーズ
2001

FITELnet-G12

FITELnet-Gシリーズ(メトロエッジルータ)

FITELnet-R10

FITELnet-G20/G21
2002

FITELnet-G80

FITELnet-Rシリーズ(Route Reflector専用装置)

2003

FITELnet-R20

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

3

次世代IX研究会
次世代IX研究会（Distix）にルータベンダとして参加

Distixとは、江崎 浩助教授を代表とする次世代IX技術の検証等を行う研究会
主に以下のワーキンググループで構成される。
•IXユーザワーキンググループ•IXプロバイダワーキンググループ•ルータ相互接続ワーキンググループ

古河は、ルータ相互接続ワーキンググループに参加しています!!

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

4ルータ相互接続ワーキンググループ
ルータ相互接続ワーキンググループでは、MPLSを応用したIXアーキテクチャに関して、マルチベンダ環境での相互接続性について、試験や検証を行っています（相互接続試験）。

相互接続試験にて・・・・
・実装が違う？？
・RFC（draft）と実装が違う？？
・RFC（draft）書いてない実装？？
実装の違いで接続できないことも・・・⇒ プロトコルの動作を調査すると・・・
思わぬ違いが！！
実装の修正（現地で？）Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

5

相互接続試験•第6回相互接続実験
期間：2003年4月14日〜2003年4月16日
試験内容•EoMPLS（PtoP)•Fast Reroute/Protection
参加団体
ネットマークス、日商エレクトロニクス、あやめプロジェクト、Riverstone、アジレント、東陽テクニカ、古河電工•第7回相互接続実験
期間：2003年8月19日〜2003年8月22日
試験内容•Fast Roroute/Protection
参加団体
ネットマークス、日商エレクトロニクス、あやめプロジェクト、Foundary、Cisco、富士通、アジレント、東陽テクニカ、古河電工
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

6実装の相違相互接続試験にてわかった実装の相違
RSVP-TE実装
Sender Tspec Object
 Local protection動作時のRe-optimize
 Local protection動作
 Explicit Route Object
EoMPLS実装
タグモードCopyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

7

RSVP-TEの実装 – Sender Tspec Object •Sender Tspec Object
Path message中のsender tspec objectの値によっては、sessionを受け付けてくれないルータもいる・・・(Sender Tspec)
minimum policed unit = 0
maximum policed unit = 65535

×拒否!!

Sender Tpsec objectのpoliced unitは、Head End(HE)が扱う最小・最大パケットサイズだが特にconfigもないので、基本的にはforwardingに使用するパラメータとは思えないがminimum policed unitを0、maximum policed unitを65535とSender Tspec Objectにセットするとsessionが拒絶されてしまう・・・

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

8

RSVP-TEの実装 – Sender Tspec Object •Minimum policed unitとMaximum policed unitの値がベンダにより異なる。
•最小を0、最大を65535と指定するルータ•最小を20、最大を1500と指定するルータ（Ethernetの場合）
policed unitは、ルータが扱えるIP datagramの最大と最小値なので、•最小を0、最大を65535と指定するのはおかしいような・・・•config等もなく特にforwardingに使用しない場合にsessionを拒絶するのもおかしいような・・・

そこでGシリーズでは、•Mediaにあわせてpoliced unitを指定するように実装

Ethernetの場合、最小を20、最大を1500としてTspec Objectを指定•Policed unitの値として、0や65535のような値が指定されていても、特にforwarding動作に関係ない場合には、そのsessionを受け付けるように実装

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

9実装の相違相互接続試験にてわかった実装の相違
RSVP-TE実装
Sender Tspec Object
 Local protection動作時のRe-optimize
 Local protection動作
 Explicit Route Object


EoMPLS実装
タグモードCopyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

10

RSVP-TEの実装 – local protection時のre-optimize動作RSVPのProtection動作としては、•Head End(HE)で行うGlobal Repair(protect, route)•Protect - あらかじめbackup側のLSPを形成•Reroute – 障害時にbackup側のLSPを形成•Point of Local Repair(PLR)で行うLocal Repair

Local Repairだけの運用は、ありえない？？
確かにLocal Repairは高速にbypass pathへの切り替えが行われるが・・・
HEでbypass pathがどのような経路を通っているかわからない⇒Local Rapairにてbypass pathへの切り替え後、HEにて最適pathへの切り替えを行う（Local RpairとGlobal Repairの併用）

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

11

RSVP-TEの実装 – local protection時のre-optimize動作-×
re-optimize
して欲しいなぁ

Local Repairの実装において、Head End（HE）でのre-optimize動作が前提となっているルータがある。
⇒PLRが回線復旧できり戻す動作をしない。
Local Repairされていることを検出した場合、HEは、Global repairによりre-optimize動作をする必要あり。
もし、re-optimizeしないと・・・
Path messageを送信するとno route notifyが返されsessionがdown!!
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

12

RSVP-TEの実装 – local protection時のre-optimize動作–
たしかに、Local Repairだと・・・•bypass tunnelのpathが、HEにはわからない。
•HEにてTEまでのpathを把握できない。
HEでTEまでのpathを管理したい⇒Local Repairの動作でGlobal Repairは必須!!
確かに、Local RepairとGlobal Repairの併用は必要だと思うが、だからといってLocal Repairした後きり戻しを行わないくてよいとは思えない・・・
HEがGlobal Repairに失敗した場合やサポートしていない場合等を考えるとPLRでのLocal RepairがHEでのGlobal Repairを前提として動作するのはおかしい。

⇒PLRでbypass tunnelからきり戻す処理も必要

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

13実装の相違相互接続試験にてわかった実装の相違
RSVP-TE実装
Sender Tspec Object
 Local protection動作時のRe-optimize
 Local protection動作
 Explicit Route Object


EoMPLS実装


タグモード

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

14

RSVP-TE – local protection動作 –×Local repair時protectしているはずのsessionがdownとして表示される。

Local repair時PLRがHEからのRSVP messageをLSPに載せるため、localrepairされているsessionは見えない。

あるルータがPLRになると・・・
Local Repairにより、HEからのsessionはprotectされているはずなのにPLRのsession状態では、downと表示される・・・⇒Local Repairによりprotectしているのにdownと表示されるのは変？
Local Repairしているのならsession状態はupとして表示すべき
ただし、Local Repairによりprotectされていることも同時に表示するべき
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

15

RSVP-TE – local protection動作 –×

Local repiar時protectしているはずのsessionがdownとして表示される。

Local repair時PLRがHEからのRSVPmessageをLSPに載せるため、local repairされているsessionは見えない。

Local Repair時、HEからのpath messageをbypass LSP上で転送している。
•Bypass tunnel上のルータには、HEからのsessionはみえない・・・
Bypass tunnel上で転送することでExplicit Route Object（ERO）を特に書き換えなくても大丈夫？？
⇒実際にEROの書き換えを行わないルータもあった。

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

16

RSVP-TE – local protection動作 –Local Repair時、Bypass LSP上でHEからのRSVP messageを転送するほうがよい
Bypass tunnel上のルータにはHEからのsessionを隠蔽する。
相互接続試験時には、LSP上にのせていませんでした・・・（古河だけ）
EROの書き換えをがんばって実装していました・・・

今は、bypass LSPで転送できるように実装しています！

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

17実装の相違相互接続試験にてわかった実装の相違
RSVP-TE実装
Sender Tspec Object
 Local protection動作時のRe-optimize Local protection動作
 Explicit Route Object


EoMPLS実装
タグモードCopyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

18

RSVP-TE – Explicit Route Object HEからのPath messageにてExplicit Route Object（ERO）を指定した場合、Path messageのIPヘッダのdestination addressをnexthopにして送信すると・・・⇒sessionを確立することは可能
でも、PLRがLocal Repairすると・・・
あるルータでは、•protectされたsessionのpath messageに対するresv messageをPLRはHEに送信してこない。
ちがうルータでは、•protectされたlinkの復旧時にpath errorやresv errorをPLRがHEに送信してくる。

⇒せっかくprotectされたLSPがdownしてしまう。

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

19

RSVP-TEの実装 – Explicit Route Object –必ずHEが送信するpath messageのIPヘッダのdestination addressは、TE宛にする必要がある。
⇒EROが指定してあれば、特にIPヘッダのdestination addressはnexthopでも問題ないように思えるが・・・
Session Object内でもTunnel End Point Addressを指定している
のに・・・
Session自体は問題なく確立するが、Local Repairされると問題が・・・
Bypass LSP上でRSVP messageも転送するための制限？？
PLRとなるルータのLocal Repairの実装次第？？
結局・・・
送信するpath messageのIPヘッダのdestination addressはTEに固定
但し、PLRとして動作する際はIPヘッダのdestination addressは特に使用せずnexthop、TEのどちらでも受け入れられるように実装
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

20実装の相違相互接続試験にてわかった実装の相違


RSVP-TE実装
Sender Tspec Object
 Local protection動作時のRe-optimize
 Local protection動作
 Explicit Route Object


EoMPLS実装
タグモードCopyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

21

EoMPLS – タグモード tagged frame
CEルータ

PEルータ

CEルータからのtagged frameどのようにencapsulationすべきか？
•etherモードならCE側からのフレームはそのままencapsulation•vlanモードならそのまま？？vlan tagを取り外す？？
古河以外のルータでは、CE側から受信したLayer2 frameをそのままencapsulationしていた・・・
そのままencapsulationするとegress router側のvlan tagとingress router側のvlan tagが一致しないと疎通できない・・・・
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

22

EoMPLS – タグモード tagged frame
PEルータ
CEルータ
Gシリーズでは、以下の2つのモードを提供していた・・•透過モードCE側から受信したLayer2フレームをそのままencapsulation•終端モードCE側から受信したLayer2フレームのvlan tagをはずした後、encapsulationegress routerにてラベルの取り外しと同時にCE側vlan tagをつける
PtoMP等も考えるとegress routerにてCE側のLayer2 frameのvlan tagを書き換える動作は必須!!
⇒現在のGシリーズでは、Ingress側ではそのままencapsulationし、Egress側にてvlan tagを書き換えるような動作をデフォルトとした。
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

23

こらからの実装他社の後追いで実装するのは楽だけど・・・

古河は新しいことにチャレンジしていきます!!
最近では、他社ルータにない機能も開発しています。
これからは、メーカ単体ではなく、実際にルータを使用していただくユーザの方々と一緒により良い製品がつくれるよう実装をしていきたいです！！
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

24実装者から見た相互接続試験
いろいろな機能を実装していく上で・・・
実装者にとって相互接続試験は、今後必要とされる機能を知ることが出来る実装の正当性（妥当性）の確認ができる
他社の実装が垣間見える
etc…
非常によい場!!

今後もその場で古河は、様々なことにチャレンジしていきます!!
Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

25

ありがとうございます。
murakami@inf.furukawa.co.jp

Copyright (c) 2003 The Furukawa Electric Co., Ltd. All Rights Reserved.

26