IPv6 on MPLS networks- AYAME Update 2001-2002 Zin Uda <zin@jaist.ac.jp>
北陸先端科学技術大学院大学
あやめ Project

Agenda

6PE による IPv6 on MPLS
概要
 あやめの実装と実験
 Operational Issue

6PE のその次は?
IPv6 Native support へ向けた課題

最近のあやめな活動IPv6 on MPLS network (1)IPv6 トラフィックを MPLS 網で transit したい
IPv6 雲間で IPv6 パケットが通ればよい PE 間の IPv6 transit ができればよい

PE

IPv6IPv6cloud
cloud

MPLS
MPLScloud
cloud
IPv6
IPv6
cloud
cloud

PEPE

IPv6IPv6cloud
cloud6PE model

Edge LSR のみの拡張で、Edge LSR 間のIPv6 transit を実現する
MPLS network

IPv6IPv6cloudcloudCCoo
Edge
Edgerrby BGPLSP
LSR Route eXchangeLSRee
Label Signaling on IPv4

IPv6IPv6
cloudcloud6PE model (2)利点
既設 MPLS 網の有効利用
 必要なポイントのみへの対応で OK 既に実装がある!! 明日からでも使える!!


不安
実際のトラフィックとは別のプロトコル上で経路制御が動作 (障害時の動作) 実装が複雑か!?
6PE model (3)

BGP での IPv6 経路交換


広報経路の NEXT_HOP には自 IPv4 アドレスIPv4-mapped IPv6 address を用いたエンコード

ラベルの配布 (任意)
Using VPN SAFI (128) -- RFC 2547bis-- RFC 3107
 Using Label SAFI (4)6PE: Interoperability Issue
single label vs. double label
Single Label:
BGP でラベルを広報しない
 Core 網を流れる IPv6 パケットにはラベルが１段Double Label:
BGP でラベルを広報する (2547bis / 3107)
 Core 網を流れる IPv6 パケットにはラベルが２段
BGP session
IPv4 traffic
IPv6 traffic
IPv6 traffic

BGP session
IPv4 traffic
IPv6 traffic
IPv6 traffic

6PE: Interoperability Issue
single label vs. double label (2)Single Label:
Edge LSR 間に張った土管
 MPLS-IX モデルで IPv6 拡張していくと…


Double Label:
MPLS 網上に IPv6 専用仮想ネットワーク
 MPLS-VPN モデルから IPv6 網提供を考えると...
BGP session
IPv4 traffic
IPv6 traffic
IPv6 traffic

BGP sessionIPv4 traffic
IPv6 traffic
IPv6 traffic

6PE: Interoperability Issue
single label vs. double label (3)Single Label:

利点:
構造がシンプル / 実装が容易!?
 Label TAX が安い!?




欠点:
Edge LSR で IPv4 / IPv6 の判別に迷う Tunneling over IPv4/GRE tunnel との判別不能
 PHP の問題を考慮する必要がある

6PE: Interoperability Issue
single label vs. double label (4)Double Label:
利点:
Tunneling over MPLS LSP だと断定できる
 Edge LSR で確実に IPv6 だと判断できる
 Edge LSR で label switch 可能 (実装次第)


欠点:
BGP でラベルを扱わないと…
 IPv4 なら single label でも運用できるのに、IPv6 はdouble labels じゃないと運用できないの?
6PE: Interoperability Issue
single label vs. double label (5)まとめるとSingle Label Double Labels (RFC 2547bis)
 Double Labels (RFC 3107)


どの方式が主流になるか
Double Labels
 BGP capability neg. でラベル広告手法は選択可VPN サービスでの IPv6 を扱うにはどうする?


とりあえず IPv6 Exp. NULL でお茶を濁すって訳にいかなくなる。(ベンダー各社様に期待!!)6PE: あやめの場合

IPv6 に対応せよ!!との期待を受けいち早く実装し、動作実験を開始
独自方式
 実は、Single Label の方式


Implementation
NetBSD Kernel の拡張 (IPv6/MPLS 対応)
 Zebra の拡張6PE: 運用実験(1)目的6PE 方式の運用からの知見の取得
 我々の実装の安定性の検証




トポロジ

JAIST IPv6 Network

MPLS Test-bed
operated by HTnet

HTnet IPv6 Network

E-BGP

A
AYAME
LSR

LSP#1
Cisco
7200

Cisco
6400

B
AYAME
LSR

6PE: 運用実験(2)6PE model を用いることでIPv6 に対応していない MPLS 網を介したIPv6 転送ができることを確認
 実装の安定性


実運用ネットワークでの数ヶ月にわたる運用
 実運用にも耐えられる安定性6PE: 運用実験 (3)さらにトラフィックのかかる運用
 トポロジWIDE 6Bone
MPLS Network
AYAME LSR
HTnet IPv6 Network
AYAME LSRAYAME LSR
JAIST IPv6 Network6PE: Operational Issue (1)6PE では、実トラフィックは IPv6 だが、経路交換には IPv4 が使われる
障害時に何が起こるのか?

“データパス消滅 & 経路交換継続” を防ぐデータパス(LSP)を死守する!!
 データパス消滅時に経路交換を止める

MPLS-IX モデルでの運用

データパス(LSP)消滅とともにeBGPセッションが落ちることで経路が正しく消える6PE: Operational Issue (2)iBGP での経路交換
“TTL 1 の iBGP & フルメッシュ” で MPLS-IX モ
デルと同様な状況を作る

そんなの可能?

6PE

6PE

6PE

6PE

6PE: Operational Issue (3)iBGP での経路交換


MPLS 網に接続しない BGP ルータの存在

BGP

6PE な BGP attribute を送って来られても困る

iBGP だけでの解決は困難?

BGP

6PE

6PE

6PE

6PE

BGP

6PE: Operational Issue (4)SubAS への分割による解決 (例)6PE LSR 毎に SubAS に分割し、6PE LSR 間は eBGP 接続とする

BGP
SubAS
6PE
BGP SubAS 6PE

6PE

SubAS

6PE
SubAS

BGP

6PE: Operational Issue (5)SubAS 分割による解決
解決
LSP 消滅時の経路制御の問題
 MPLS 網に非接続の BGP ルータに関する問題




検討課題




ほんとに綺麗に分割できるようなトポロジか?

問題
経路制御が複雑になる
 AS 内経路制御が BGP となり、経路メトリックの微調整が困難
IPv6 Native support
IPv4 is going to become HISTORICAL!?
 MPLS 網での IPv6 サポート

6PE さえあれば、IPv6 パケットは transit できる
 網自体の制御に IPv4 をいつまで使い続ける?
MPLS 網の制御を IPv6 化するためには?
L3 経路制御機構 (IGP / EGP) の IPv6 対応
 ラベル配布シグナリングの IPv6 対応
 監視系などの IPv6 対応
IPv6 native support (2)L3 経路制御機構 / 監視系
基本的なものは既にほぼ出揃った IPv6 の普及に伴い、急速に実装がすすんでいる

ラベル配布シグナリング
ほとんど動きがない 実装が進んでいるという噂も聞かない?
(実は既にサポートしているベンダさん居ますか?) プロトコルスペック的には大丈夫そうIPv6 address のための TLV など定義済作れば動くのだろうか?

IPv6 native support (3)

ラベル配布シグナリングの IPv6 対応
とりあえず、“IPv6 も” 定義してみたとの感が…
 “IPv4 のような” 網構成なら動くような気もする IPv6 っぽい構成に手を出すと、


リンクにアドレスを付けない(リンクローカルアドレスのみで動かす)

IPv6 native support (4)(例) LDP / CR-LDP とリンクローカルアドレス
アドレスメッセージで隣接 LSR のアドレスを知る
リンクローカルアドレスを渡されても…
 どのインタフェイスのアドレスか判別不能

L3 経路制御は、普通リンクローカルで動いている

RIB の gateway を見ても、どの LSR なのか判別不能とか言うことになるんじゃなかろうか…

IPv6 native support (5)

まじめに考えなきゃマズイんじゃないだろうか
考えただけでも動かなそうな気がする 実装してみると、きっともっと動かない

いつまで制御に IPv4 を使い続けますか?

おまけ: AYAME の最近の取り組み

IPv6 support


MPLS Multicast

手を付けられるところから始めよう

細粒度トラフィック制御 / 動的 SLA 提供

ここまでで話したようなことなど

MPLS Japan 2001 で取り上げました

Misc.
エンドユーザに LSP が届くと何が起こるか?
 各種運用 / 人柱 (Operation Issue の収集)


戯言: (おまけ)ネットワーク性能にシビアな人々ジッタ / RTT / ホップ数 などにシビアな人々
エンドユーザからの問い合わせの増大 ちょっとでもパケットを落とそうものなら…


ネットワーク性能にシビアなアプリケーション
VoIP?
 ネットワークゲーム


プロトコルがなっていない!?

彼らは precedence service を求めている?


やっぱり動的 SLA とか…

*** おしまい ***AYAME Project
http://www.ayame.org/