実装者から見た相互接続

古河電気工業株式会社
ファイテルネットワーク研究所 IPチーム
村井 朋生
murai@inf.furukawa.co.jp

November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

古河電工㈱について御存知のように電線メーカー巻線、裸線、被覆線、光ファイバーなど
昨年ルーセント 光ファイバー部門買収で有名？
最近新聞を賑わして、さらに有名？

ルータベンダーとしては実は約20年の歴史！
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

古河製ルータラインアップ
８３年 国産初のIEEE802.3準拠トランシーバを開発
８８年 マルチポートトランシーバ発売
９１年 SNMP １０ＢＡＳＥ−Ｔ用ＨＵＢ発売

９３年 ISDN対応リモートルータ発売（国産初）９５年 ＨＵＢ付きルータ「モデルータ」発売
９６年 センタールータ発売

９７年 SOHOルータ「 ＭＵＣＨＯ 」発売
INFONET AX-60

00年 PKI対応SOHOルータ

Mucho Eシリーズ

INFONET VP１００

FITELnet B10
November 8, 2002

０１年 メトロエッジルータ
FITELnet-Gシリーズ
GbEルータFITELnet-Bシリーズ
０２年 ルートリフレクタ
FITELnet-Rシリーズ

FITELnet G12

FITELnet R10
MPLS JAPAN ©Furukawa Electric co.,LTD.

私のMPLS開発に至るまで
・’95入社
ルータ IPフォワード部(L3)の開発を担当・手掛けたルータ
トークンリング対応ルータ
多ポート収容ISDNルータ(AX60)
IPsec対応 VPN ルータ(MuchoEV, VP100)

現在FITELnet GシリーズのMPLS開発担当
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

相互接続実験
次世代IX研究会(distix)にルータベンダーとして参加
distix主催の「相互接続実験」で気づいた点

他ベンダーと実装が結構違う！
アプローチ間違えた？
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

実装の相違点
例えば・・・
1. LDP label retention mode
2. Downstream LSRとしての label merge
3. Penultimate Hop Popping(PHP)など
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

実装の相違点
例えば・・・
1. LDP label retention mode
2. Downstream LSRとしての label merge
3. Penultimate Hop Popping(PHP)など
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

1. LDP label retention mode
Liberal mode = とりあえず全部保持
Conservative mode = 必要な分だけ保持、あとは捨て
相互接続実験参加ルータベンダーでConservative は古河だけ！？
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Conservative 動作 その１
ConservativeなLSR

LSR

label releaselabel mapping

LabelLabelmapping受信release送信

LSP

FECで経路表検索

DestNexthop

出力A

10.0.0.1

1

B

11.0.0.1

2

もし・・・経路表になかったら:bind せずに廃棄！

:

November 8, 2002:

MPLS JAPAN ©Furukawa Electric co.,LTD.

Conservative 動作 その２
ConservativeなLSR

LSR

label request
label mapping 経路追加の動作

LSP

 Downstream側にlabel request

送信 label mapping受信して remote bind

November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Conservative 動作 その２
ConservativeなLSR

label release 経路追加の動作

LSR

LSP

 Downstream側にlabel request

送信 label mapping受信して remote bind 経路削除の動作
 Downstream側にlabel release送信 bind table から廃棄
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Conservative の素晴らしい点
Request base で LSPを作れるので明確！
> 欲しいときに欲しい物(label)を。

経路制御で勝手に remote bind filter が出来る！
> 不要な bind情報を持たなくて良い、メモリも節約できる。
例えば・・
IXでMPLSを実現するとなると CE側にMPLSが伸びる> CEルータからたくさん mapping がやってくる可能性あり！
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Conservative の欠点
LSP

LiberalなLSR

mapping

LiberalなLSR

mapping

ConservativeなLSR

mapping
LiberalなLSR

requestmapping

mapping
notification
releasemapping

packet処理が多い！
せめて notify でも設定で止めておくか。。

トポロジー変化に弱い！
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

相互接続実験でのConservativeな事件
Upstream が Conservativeの場合にdownstream に label request 送信→ ごくごく稀に label requestに答えない奴が・・

No route時 downstreamから受け取ったmapping に対して label release 送信→ ごくごく稀に release に驚いたのか再度mapping を送ってくる奴が・・
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Conservative vs Liberal
皆 Liberal だけども。。。
Conservative も使い方によっては結構必要な実装果たしてどっちがいいのだろう？
→ 一長一短古河は次は Liberal もやります！
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

実装の相違点
例えば・・・
1. LDP label retention mode
2. Downstream LSRとしての label merge
3. Penultimate Hop Popping(PHP)など
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

2. Downstream LSR としてのlabel merge
upstream
LSP
X はlabel：16
FEC X
X はlabel：16

downstream
LSP

upstream
November 8, 2002

図 label merge
MPLS JAPAN ©Furukawa Electric co.,LTD.

古河は label non-merge
upstream
LSP
X はlabel：16
FEC X
X はlabel：17

downstream
LSP

upstream
November 8, 2002

図 label non-merge
MPLS JAPAN ©Furukawa Electric co.,LTD.

Non-merge 利点／欠点利点
neighbor毎に LSP管理(MIB)できる！
→ MPLS-IXでBGPピア毎のLSPトラフィック取得もlabel spoofing 防止も→ interface と label だけ checkすれば良い。

欠点
Scalability→ label いっぱい使ってしまう。
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Non-merge も。。
LSP管理、label spoofing って運用側から見ると結構重要な問題・・となると 環境、システムによっては、non-mergeも必要な実装では？
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

VPN label
VPN label(2547bis) はどうだろう？
per prefix
per vrf

で distribute するインプリがあるが・・・
古河は per vrf
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

per prefix vs per vrflabelLSP管理

C’sC

per prefix 無

prefix毎実現容易

per vrf

vrf毎実現困難？

Scalability

有vrf 毎のLSP管理ってちょっと。。
November 8, 2002

C’sCかぁ。。
MPLS JAPAN ©Furukawa Electric co.,LTD.

per vrf で一応は。。
prefix毎 LSP管理(MIB)は？
→ static vpn label にすれば一応はできる。
→ 逆に、管理をまとめたいサイトを同一の staticvpn label とかにすると結構良い？

C’sCの実現は？
→ 使い方を限定(例えば 1vrf 1CE)すれば可能？

per vrf でも結構使える？

November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

実装の相違点
例えば・・・
1. LDP label retention mode
2. Downstream LSRとしての label merge3. Penultimate Hop Popping(PHP)など
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

3. Penultimate HopPopping(PHP)
古河はPHPしません。
→実は知らなかったという噂も。。（＾＾！

確かにPHPしないと forwarder は大変→性能、無限POP?、VPN label との区別 など

November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

PHP なしも必要！
でも頑張れば結構いいことある！
Egress edge で LSP毎の管理(MIB)できる。
MPLS-IXでは必須だったりしない？

tracerouteとかも正確にできる？
VPN edgeの時でも対応できる。

どうやらinter domain（ASBR間）でも大丈夫らしい。

PHPなしの実装も必要では？
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

実装の相違 まとめ
Conservative, label non-merge, PHPなし
間違ったアプローチではなかったと思うけども、環境、システムによっては一長一短。

他社の実装状況、広くシステムを考えると、Liberal, label merge, PHP は必要！
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

古河の今後のアプローチ
Conservative, label non-merge, PHPなし
も継続して当然実装しますが、Liberal, label merge, PHPもすぐに実装します！できます！
今ラボでは動いています。
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

今後の相互接続について実装の相違も使い方次第→ 選択（設定）できるのが望ましい。
かつ、相互接続性ではないだろうか。

実装の相違により発生する運用面での利点、欠点の議論→ 我々ルータベンダー側から積極的に
November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

今後の相互接続について
次世代IX研究会(distix)はとても有効なCommunity
熱い議論で使い勝手の良いMPLSを！

November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.

Thanks!
murai@inf.furukawa.co.jp

November 8, 2002

MPLS JAPAN ©Furukawa Electric co.,LTD.