====================================================================== 本文章は draft-yu-routing-scaling-01 を日本語に訳したものであり、原文 と語彙あるいは解釈の相違が生じる場合は原文を正しいものとする。訳者およ び日本語訳に関わった全ての関係者は、本文書によって読者が被り得る如何な る損害の責任をも負わない。 前村 昌紀 maem@mesh.ad.jp NEC 友近 剛史 tomo@byd.ocn.ad.jp NTT Communications 近藤 邦昭 kuniaki@iij.ad.jp IIJ 訳語が一般化されていないと考えられる単語に関して、本翻訳で採用している 訳語を以下に挙げる。参考にされたい。 scale, scalable... 規模対応する，規模対応可能な... adjacency 隣接関係 flooding 一斉広告 (packet) forwarding パケット転送 route flapping 経路のばたつき route dampening 経路抑制 path 方路 ===================================================================== Internet Engineering Task Force Jieyun (Jessica) Yu INTERNET DRAFT UUNET Expires in December, 1999 June, 1999 draft-yu-routing-scaling-01.txt Scalable Routing Design Principles 規模対応性の高い経路制御設計の指針 このメモの状態 このドキュメントは、インターネットドラフトであり、 RFC2026 の第10章 の全ての条項に完全に適合する。 インターネットドラフトは、インターネットエンジニアリングタスクフォ ース( IETF )、関連するエリア、そして、関連するワーキンググループの 作業中のドキュメントである。注意すべきことは、他のグループもまたイ ンターネットドラフトのような作業ドキュメントを配布しているかもしれ ないということである。 インターネットドラフトは、ドラフトドキュメントとして最大で6月間の有 効期限をもち、他のドキュメントによっていつでも、更新、変更または廃 止する可能性がある。このため、インターネットドラフトを「作業中」と いう扱い以外で参考資料として用いたり引用したりすることは不適切であ る。 最新のインターネットドラフトのリストは、 http://www.ietf.org/ietf/1id-abstracts.txt から入手できる。 インターネットドラフトのリストの写しのディレクトリは、 http://www.ietf.org/shadow.html から入手できる。 このメモの配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 概要 経路制御はネットワークに不可欠であり、経路制御の規模対応性は、大規 模ネットワークに不可欠である。経路制御が規模対応しないとき、ネット ワークのパフォーマンスと安定性に直接的な影響をおよぼすであろう。こ のため、経路制御の規模対応性は、特に大規模なネットワークにおいては 重要な問題となる。このドキュメントは、大規模ネットワークでの経路制 御設計の基本的な指針とともに経路制御の規模対応性が影響を及ぼす主要 な事柄について紹介する。 目次 1 序章 2 経路制御設計の一般的な目的 3 今日の大規模ネットワークの特徴 4 経路制御の規模対応問題 4.1 ルータの資源消費 4.2 経路制御の複雑さ 5 経路制御プロトコルの規模対応性 5.1 IS-IS と OSPF 5.2 BGP 6 規模対応性の高い経路制御設計の指針 6.1 階層構造 6.2 区画化 6.3 適当な調整をすること 6.4 経路情報処理の負荷を少なくする 6.4.1 経路制御知能 6.4.2 経路と経路情報を少なくする 6.4.2.1 CIDR と経路集成 6.4.2.2 できるところであればデフォルト経路を利用す 6.4.2.3 代わりの方路を少なくする 6.4.2.4 新しい技術を利用する 6.4.3 エッジで静的経路を使う 6.4.4 経路のばたつきの影響を最小化する 6.5 規模対応性の高い経路制御ポリシと規模対応性の高い実装 6.6 Out-of-Band プロセス 7 結論 8 セキュリティに対する配慮 9 謝辞 10 参考文献 付録 A Out-of-Band 経路制御処理 1. 序章 経路制御はネットワークに不可欠である。経路制御がなくては、パケット は希望する対地へ配送されず、ネットワークは機能しない。ISP のバック ボーンネットワークのような、大規模ネットワークに対する経路制御設計 の課題は、そのネットワークを動かすことだけではなく、そのネットワー クを規模対応させることである。規模対応可能な経路制御システムがない 場合ネットワークは厳しいパフォーマンス上の制約を受ける可能性があり、 大規模ネットワークでは不運な大事故となりかねない。この文書は、経路 制御の規模対応性に関する問題を解析し、そして、大規模ネットワークに 対する規模対応性の高い経路制御システムの設計に関する指針を明らかに することを試みる。 この文書の構成を以下に示す。2章は、経路制御機能と設計の目的について 記述する。3章と4章は、今日の大規模ネットワークの特徴と関連する規模 対応経路制御に関する問題について議論する。5章は、経路制御プロトコル の規模対応性の探求をおこない、そして、6章で規模対応性の高い経路制御 設計の指針を紹介する。7章は、文書の結論を示す。 2. 経路制御設計の一般的な目的 経路制御システムは、基本的に以下に示す様な事柄を達成することが目的 である。 o 規模対応性が高いこと o 冗長性があり、かつ、強靭であること o 妥当な収束時間であること o 経路情報が完全であること o 経路制御ポリシが実用的かつ管理可能であること 大規模ネットワークでの経路制御設計への課題は、これらの基本的な目的 を達成するだけではなく、経路制御システムを規模対応させることである。 3. 今日の大規模ネットワークの特徴 今日の典型的な大規模ネットワークは、以下に示すような特徴もっている。 o 典型的には数百であるような、大量の(ルータやスイッチなどの)ノー ドで構成される。いくつかのプロバイダのネットワークには、その管 理領域の内部に数千ノードにも及ぶ顧客の客先構内ルータが含まれる。 o 冗長性、強靭性の要求を満たすために豊富な接続性を持つが、その結 果トポロジが複雑になる。 o それらは、default-freeである。これは、インターネット全体に知ら される経路を伝搬するということである。今日では、その総数はおよ そ60,000である。 o 顧客集線ルータは、ときとして何百もの顧客ルータを接続する。 これらの特徴により、ネットワークの規模対応性経路制御への直接的な課 題をもつことになる。 4. 経路制御の規模対応問題 今日の経路制御の規模対応性をとりまく問題は、過度にルータ資源を消費 するところにある。この問題は、潜在的にネットワークを不安定にさせる ことができる。そして貧弱なネットワーク管理の結果、複雑な経路制御に なり、サービス品質の低下に繋がる。 4.1. ルータの資源消費 経路制御プロセスは、ルータの負荷を爆発的に上げる、特に、不安定なネ ットワーク環境ではそうである。極端な場合、経路制御プロセスはルータ から利用可能な全ての資源を取得してしまい、経路制御の収束が遅くなる か、または収束しないなどの結果となる。ネットワークは、内部経路情報 が収束しないときに麻痺する。 経路制御プロセスと転送プロセスがかたく結び付いている様な構造を持つ ルータは負荷が過度になる傾向があることに注意したほうがよい。新しい 世代のルータに現れている経路制御と転送に利用する資源の分割は、より よい規模対応性を期待している。 今日の典型的な大規模ネットワークは、内部経路制御プロトコル( IGP )に IS-IS[1,2] または OSPF[3] 、外部経路制御プロトコル( EGP )に BGP[4] を用いる。 IGP はネットワーク内のルータに関する経路情報を管理するも のである。 BGP は、ネットワーク内の外部経路情報を処理し、そして伝え る。ひとつのネットワークに大量のルータと隣接関係がある場合、不安定 なリンクによる度重なるトポロジの変化は、内部経路制御において極端な ルータ資源の消費の一因となるであろう。外部経路制御においては、BGP システムの大量のルータに加えて度重なる経路更新(経路のばたつき)は、 ルータに過大な負荷をかける。5章では、 IS-IS 、 OSPF そして BGP に於 ける詳細な規模対応性の問題を説明する。 補足であるが、複数方路をもつ経路制御システムでの多くの経路は、 BGP で下記に示す規模対応の問題点と関連する。 o それぞれに複数方路を持つ大量の経路は、経路選択、経路制御ポリシ の適用、そしてフィルタリングに対して経路制御処理のコストを増加 させる。 o 複数方路を持つ経路があまりにたくさんある場合、ルータはその蓄積 のために大量なメモリを必要とする。この必要性は、 NAP のような 相互接続点においても高い。 o 大量の経路がある場合、経路のばたつき現象が起こる機会が非常に多 くなり、そして、その結果として BGP の経路更新が多くなる。[5] によって集められた統計によれば、15分間に数千回の BGP の更新が 起こる可能性があり、 NAP にある典型的な default-free なルータ でこの現象を起こすことができる。 経路のばたつきとは、不安定なネットワークにおいて発生する非常に多 くの経路更新をさす。例えば、ネットワークの物理的接続の状態が変動 しているときや、 BGP の接続が落とされ、そして再び接続を確立する ようなことが短い時間間隔で何度も行われるようなことである。 早く収束させることを容易にするためには、トポロジ変更の情報は時々 刻々とその構成が伝搬されなくてはならない。経路が存在しなくなった り、削除されたとき、その情報は一般的にただちに送られる。もし、有 効な経路がグローバルなインターネットに広告されているならば、更新 情報は、おそらくインターネット全体に伝搬されている。 経路のばたつきは、 BGP が稼働しているルータにおいて深刻な打撃を 与える。ルータは、頻繁に経路情報を処理する必要があり、これには、 非常に多くの資源を使う。ローカルな経路やリンクが発振するとき、内 部経路制御は過度なトポロジ情報の一斉広告と最短方路計算によって同 様に不安定となる。しかしながら、 OSPF (または、 IS-IS )は、ルー タの負荷を減少させるため、そのような動きに制限を負わせる。例えば、 OSPF は個々の SLA が最大で5秒に1回更新されるように定義する。これ が経路ばたつきの抑制というものである。 さらに、1つのルータによって処理される多くの E-BGP 接続は、規模対応 の問題を作り出す可能性がある。大規模ネットワークは、しばしば非常に 多くの顧客が加入し接続を持つ。ハードウエアとネットワーク上のノード の数に規模対応するために、プロバイダは一定の数のルータを顧客集線専 用として、できるだけ多くの顧客の客先構内ルータに接続しようとする傾 向がある。この結果、顧客集線ルータが BGP 接続の処理と管理、経路制御 処理、フィルタリング、そして経路の記憶という潜在的な問題を負うよう な何百もの E-BGP 接続を持つことは珍しいことではない。 4.2. 経路制御の複雑さ 経路制御の複雑さは、障害解析と問題の早期解決に影響を与え、ネットワ ーク管理を難しくする場合がある。それは、ネットワーク全体として望ま れるサービス品質が得られない結果となる。複雑な経路制御ポリシとネッ トワーク設計における特例や例外は、大規模システムにおいて複雑な経路 制御の一因となる。 経路制御ポリシは、一般的な経路方路選択と経路フィルタの方式において、 経路情報を扱うための管理上の基準によって決まる。経路情報の扱われ方 によっては、ドメインのいたるところ、そして、ネットワーク内において トラヒックの流れに直接的な影響を与える。その結果、異なるネットワー クとの間でのビジネス上の合意に影響を与える。それゆえに、経路制御ポ リシの確定は、ビジネス上考慮するような非技術的な配慮によって大部分 が支配されている。経路制御ポリシは、規模対応性の低くするような設定 と管理を行うことにより非常に複雑なものになり得る。 経路制御の複雑さを軽減に導く鍵は、一貫しているだけでなく体系的な経 路制御機構と、簡素ではあるが管理ポリシの要求に適合する経路制御ポリ シである。 経路制御管理の複雑さに関するもう一つの要因は、プリフィックスを対象 とするフィルタである。良く知られているように、プリフィックスを対象 とするフィルタは、経路制御システムの完全性を維持するという目的にお いて必要である。今日では the Internet 上に知らされる経路数は約 60,000にものぼるため、これは課題となる。 5. 経路制御プロトコルの規模対応性 今日、一般的に配置されている経路制御プロトコルは、( IGP として知ら れている)内部経路制御には IS-IS や OSPF 、そして、( EGP としてしら れている)外部経路制御には BGP である。規模対応や他の観点において、 これらのプロトコルは既に RIP や EGP にような前の世代のプロトコルか ら改善されている。しかしながら、規模対応性は、ネットワークが大規模 であるとき、経路制御設計が規模対応に関する問題をあまり考慮していな いか、または、プロトコルの実装が非効率であるようなとき、主な問題と していまだに存在する。 5.1. IS-ISとOSPF 前述のとおり、IS-IS と OSPF はリンクステート型の経路制御プロトコル である。リンクステート型経路制御プロトコルの基本的要素は、与えられ る経路制御範囲の経路制御トポロジとデータベースにあるトポロジ情報を 基とする経路計算によって示されるリンクステートデータベース ( LSDB ) の保全と生成である。経路制御範囲内のそれぞれのノードは、リンクステ ート広告 ( LSA ) もしくは、 LSA ( IS-IS の場合は LSP ) でのローカル な経路制御トポロジの状態に対して責任を負う。それぞれのルータは、経 路制御範囲全体の経路制御トポロジを反映するリンクステートデータベー スを形成する他の全てのルータから LSA を受信する。 規模対応性に主に関連する問題は、リンクステートの一斉広告と経路計算 の複雑さである。加えて、経路計算とルータのメモリ資源のコストに起因 する LSDB の大きさである。 一斉広告は、接続状態が変化した場合に範囲内のルータの休止に自分がオ リジナルとなるような LSA を配布するルータに対して処理を行う。 一斉広告は、リンク状態が変わった場合に領域内の残りのルータに対して、 自身で生成したLSAを配布するプロセスである。ルータは、その全てのイン タフェースを経由して LSA を送る。 LSA の更新を受け取ったとき、ルー タは情報を有効にし、そしてオリジナルの LSA の更新を受信した1つのイ ンターフェースを除く全てのインターフェースを経由してその LSA を送出 する前に自分自身の LSDB を更新する。 IS-IS や OSPFの一斉広告の特徴 を示すと、N台のルータによるフルメッシュのネットワークは、1つのリン クが故障したとき、ネットワーク内に LSA の一斉広告を O(N^2) 持たせる であろう。1つのルータの故障は、システムに O(N^3) の単位で一斉広告さ れる LSA を発生させるであろう。 OSPFの場合、プロトコルは安定状態においても30分ごとにリフレッシュま たは一斉広告を行い、既に高負荷となっているルータの状態を悪化させる ことがある。 以上の議論から容易に次のことが言える。リンクステート型IGPの経路制御 領域やルータ隣接区域にルータや隣接関係が多くなれば多くなるほど、そ れぞれのルータのCPU負荷はより大きくなる。さらに、ネットワークが不安 定なときは、ルータの負荷はさらに大きくなる。 リンクステート型プロトコルは、典型的に経路計算の方法として Dijkstra の最短方路優先( SPF )アルゴリズムを利用する。 Dijkstra アルゴリズム は、ノードの数が N のとき、 O(N^2) の単位でおおきくなる。アルゴリズ ムは、l がネットワーク内の接続の数であり、 N がルータもしくは対地の 数であるとき O(l*logN) の単位で改善される [6] 。 したがって、リンクステート型経路制御プロトコルは、一定の領域内にた くさんのルータと過度な隣接関係があるネットワークトポロジでは規模対 応しない。ネットワーク構成が不安定なとき、計算、処理そして容量のコ ストは、ルータ資源の極端な消費の発生によって非常に大きくなる。不安 定によって IS-IS や OSPF が隣接関係を保全することができないとき、ネ ットワークの経路制御のメルトダウンを発生させる。 ノード隣接は、それぞれのルータから定期的に送出する HELLO メッセージ の交換を通して発見され、そして保守される。ルータが一定の時間間隔 ( OSPF は40秒、 IS-IS はそれ以下)でその隣接ルータからの HELLO メッ セージを受信することに失敗したとき、その隣接ルータがダウンしている ことを判断する。一斉広告があるとき、再計算、そして他の動きによって ルータの資源が乏しくなるようなことが起きると、ルータはHELLO パケット を処理したり、それを送信するための CPU 時間を配置することができない かもしれない。やがてネットワーク内のルータは隣接関係を失い、不安定さ を増大させる。その結果、切り離された不安定部分は全ネットワークの経路 制御障害へと発展し得る。 リンクステート型の IGP は、今日の the Internetで知られている60,000 経路にもおよぶ大量な経路をうまく伝搬することにも規模対応しない。外部 経路がリンクステートデータベース、そして LSA ( IS-IS は LSP )に含ま れるため、接続容量とルータのメモリ消費は、すさまじくなるであろう。 さらに、 LSA の更新の大きさが大きいために、それは、特に不安定なネッ トワークの状態下では、一斉広告される LSA の処理で資源を消費すること によりルータの状態を悪化させるであろう。 総括として、規模対応性の高い設計は、 IGP の経路制御範囲内に多くのル ータを含むこと、多くの外部経路を IGP によって伝搬されることを避ける べきであり、そしてさらに重要なことは、経路制御範囲内に極端に多くの 隣接ルータをおくことを避けるべきである。 5.2. BGP BGP は、異なる自律システムネットワーク間で経路制御情報または到達可 能性情報の交換を可能にするドメイン間経路制御プロトコルである。機能 上、 BGP は外部 BGP ( E-BGP )と内部 BGP ( I-BGP )で構成される。 E-BGP は、外部経路の交換に対して利用され、一般的には I-BGP が AS 内部で得た経路を外部に配布ことに利用される。 BGP の一般的なコストは以下のようなものである。 o BGP セッションの確立における CPU 消費、経路選択、経路制御情報処 理、そして経路更新の取扱い o 経路と経路に関係する複数方路を導入するためのルータのメモリ BGP に関連する主な規模対応性の問題は、フルメッシュでの I-BGP 接続に ある。前の節で述べたように、取得した外部のプリフィックスを伝搬する ことに IGP が規模対応しない以上、 I-BGP はこの義務を引き受けことに なる。経路のループを防ぐために、 I-BGP 経由から得たプリフィックスは 他の I-BGP ルータへ広告されることを禁じる。その結果、 AS 内のルータ の間で I-BGP セッションのフルメッシュが要求される。 N 台のルータが ある AS において、それぞれのルータは N-1 のルータと I-BGP セッショ ンを確立しなければならず、そして、システムの複雑さは O(N^2) の単位 となる。それゆえに、 I-BGP のメッシュ構造に関係するルータの数が多い 時、BGP の規模対応性は不十分である。 大規模ネットワークでは通常、 the Internet で知り得るおおよそ60,000 の全ての経路を得る。 I-BGP はこれら全ての経路を伝搬する必要がある。 大量の I-BGP セッションと経路は、それぞれのルータからすさまじい資源 を消費する、特に、 BGP セッションを確立している間と激しい経路ばたつ きが発生している間はそうである。 しばしば起こる経路の更新は、大規模ネットワークにおいてもう一つの規 模対応の問題でとなる可能性がある。 BGP は、差分更新を利用する、そし て、収束時間を減らすために素早く到達不能な経路に関する経路情報を送 出する。これは、 EGP からの偉大な改善であり、これにより経路テーブル 全体は定期的に更新される。しかしながら、ネットワークが不安定なとき、 たとえば、経路がばたついている、 BGP セッションが発振しているような とき、更新情報、特に経路の削除が含まれている更新情報がつぎつぎ送出 され、広範な BGP の更新が発生する。その結果、不安定さは、 the Internet 全体にこの更新が引金となってネットワークのいたるところ に伝搬されることになる。この影響は、大量な経路が the Internet に存 在するとき拡大され、 BGP に加わるルータを過負荷にする。 BGP への経路の階層構造の導入は、 I-BGP のルートリフレクタ [7] と BGP コンフェデレーション [8] を通して、たとえば、フルメッシュの I-BGP 確立の要求によって発生する規模対応の問題を軽減する手助けをす るであろう。 もう一つの解決方法としての可能性は、 I-BGP 接続の組のようなフルメッ シュの要求を避けることである。これは、 BGP が I-BGP ピアの間に経路 情報を配布する方法を変えるであろう。考慮すべき価値のある仕組みは、 情報を配布するためにマルチキャストを利用していることであり、 IS-IS や OSPF ではそれらに良く似た一斉広告を行う仕組みを採用し利用してい ることである。 経路抑制 [9] は、経路のばたつきが引金となる過度の更新を減らす一つの 方法である。早期収束とネットワークの安定性とのバランスについては、 6.3節の議論で考慮されるべきである。 6. 規模対応性の高い経路制御設計の指針 大規模ネットワークは、2章で述べたように、正確性、安定性、冗長性、収 束性を実現できるような、規模対応性の高いやりかたで経路制御すべきで ある。 経路制御がどのくらいの規模対応性をもつかは、プロトコル設計、プロト コルの実装、ネットワーク設計の3つによって影響される。ネットワークエ ンジニアはネットワークを直接的に設計することができ、また、プロトコ ルの設計と実装に十分な影響を与えることができる。この文書ではネット ワーク設計を焦点として述べていく。 大規模ネットワークの経路制御が規模対応性をもつための設計指針を以下 に述べる。 o 階層構造にすること o 区画化すること o 適当な調整をすること o 経路制御処理の負担を減らすこと o 規模対応性の高い経路制御ポリシーと実装を明確にすること o out-of-band 経路処理を利用しパケット転送処理を軽くすること 6.1. 階層構造 5.1節で述べたとおり、ネットワークに多くのルータがあるとき、特に多数 の隣接 ( adjacency ) ノードがあるとき、OSPF や IS-IS の規模対応性は 悪くなる。このことは不幸にも、すべてのルータをフルメッシュに隣接さ せたIP over ATM のネットワークによって証明されている。非能率的なプ ロトコルで結合されたフルメッシュの設計は悲惨なネットワークの停止を 引き起こす。このことから、大規模でフラットな経路制御構成のネットワ ークでは、フルメッシュで結合されたトポロジを避けるべきだということ がわかる。 大規模ネットワークにおいて規模対応性をもたせるためには、経路制御構 成を階層化することが鍵となる。この文書で先に述べたとおり、通常、大 規模ネットワークは複雑なトポロジで多くのルータにより成り立っており、 ルータは多数のルータと隣接関係を持っている。これもまた先に述べたこ とであるが、現在のルーティングプロトコルは経路制御ドメイン内にたく さんのルータを持つか、ルータ間で多数の隣接関係をもつことにより、規 模対応性が悪くなる。ゆえに、経路制御ドメイン内において、隣接関係を 少なくするのが正しい方法であるのと同様に、ルータの数を少なくするた めに経路制御を階層化することは正しい方法である。 現在の一般的な方法は、中心部 (トランジットコアネットワーク) の周り にたくさんの外縁部 (アクセスネットワーク） を配す二階層構造を取る方 法である。コアネットワークはサービスしているすべての地理的な範囲を カバーし、各々のアクセスネットワーク (地域ネットワークとして知られ ている) は、一地域をカバーする。通常、地域ネットワーク間は直接の回 線はなく、ある地域ネットワークから他の地域ネットワークへのトラヒッ クはコアネットワークを通過することになる。また、顧客のネットワーク はアクセスネットワーク (地域ネットワーク) だけにつながる。上記に述 べたような階層的なネットワークトポロジにする方法に加えて、経路制御 を階層構造にする方法はたくさんある。 1. 経路制御ドメインを完全に分ける方法 この方法は、コアネットワークと各々の地域ネットワークを、経路制御 について完全に独立した AS として扱い、各々の AS (構成部分) で独 立した IGP を動かす方法である。各々の地域ネットワークでは、経路 制御情報を交換するためにコアネットワークと E-BGP で接続する。す べての I-BGP 接続は各々の構成部分の中だけで必要となる。この方法 では、IGP ドメイン内の最大ノード数は、各々の構成部分の中のルータ の数となる。その結果、IGP 処理の負荷は軽減され、また、ネットワー ク経路制御システム内で I-BGP 接続する数も劇的に減少する。 この方法のもう一つの利点は、経路制御体系を区分することであり、そ のためある構成部分が不安定になっても、全体のシステムとしての影響 は少なくて済む。詳細は次の6.2節で述べる。 この方法の主なデメリットは BGP を通じて the Internet へ広告する とき、AS_PATH に余分な AS が一つ挿入されてしまうことである。 AS_PATH に余分な AS が入っていると、他プロバイダーにとって経路選 択が困難になることがある。 2. 一つのドメインで、IGP や BGP で階層構造をもつ方法 この方法は、コアネットワークと、地域ネットワークを一つのドメイン にする。IS-IS や OSPF のマルチエリアと、BGP コンフェデレーション や I-BGP リフレクタやこの二つの組み合わせを使うことによって、経 路制御の階層構造が実現される。 この方法は、余分な AS を外部に広告することがなく、このことについ て言えば上記1. で述べた方法より好都合である。しかしながら、大規 模ネットワークは IGP としてたいてい IS-IS を使用しており、IS-IS は十分なマルチレベルに対応していないため、最近は IGP のマルチエ リアの階層構造はめったに使われない。例え IS-IS がマルチエリアに 対応したとしても、IS-IS はバックボーンとサブエリア間に厳密な階層 構造を課しており、バックボーンエリアからサブエリアにはデフォルト 経路だけしか広告できず、特定の経路を広告することができない。この 制限は、サブエリアのトポロジが単純なネットワークに向いている。し かしながら、大規模ネットワークの地域ネットワークやアクセスネット ワークなどのサブエリアは複雑なトポロジになっている。デフォルト経 路のような非常に抽象的な経路情報を受け取ることは、トラヒック制御 に必要な経路選択の能力に影響を与える。また、例えば BGP Multi-Exit-Discriminator ( MED ) のように IGP に由来する情報を外 部の AS に伝えることも制限されてしまう。 3. IGP は一つのエリア、BGP は階層構造を持つ方法 マルチエリア IS-IS ではなくて、全体のネットワークを IGP に関して は一つのドメインにし BGP に関しては階層構造にすることによって、 経路制御の階層構造を実現することができる。幸運にもこの場合、階層 的なネットワークトポロジは経路制御ドメインの中の隣接関係を減らす ことに役に立つ (ネットワークの第２階層部分同士には接続がないこと を思い出して下さい) 。加えて、隣接関係を最小限にするようにし、そ れでもなお良い冗長性を達成するように注意深く整頓することにより、 隣接関係をさらに減らすような改善ができるだろう。しかしながら、一 つの IGP ドメインしかないときは、ルータ数は変わらないので、SPF 計算の負荷を増大させるわけで、理想とは言えない。おまけに、依然と して地域ネットワーク内の不安定さが全体のネットワークに影響を与え る (つまり、欠点が孤立しないのである) 。 ひとつの IGP ドメインでも、I-BGP の規模対応性を高くするために、 BGP を階層構造にすることは可能である。BGP リフレクタと BGP コン フェデレーションは、I-BGP のフルメッシュの規模対応性の問題を解決 するための、現存する仕組みである。 さらに、異なる層の間の相互作用がルーティングループを起こすことの ないように注意深く考慮さえすれば、BGP リフレクタは階層を2つ以上 構成することができる。 尋ねるに値する質問がある。「規模対応性問題を解決するためには、経路 制御の階層構造は2層で十分だろうか？」「本当に階層構造は2層以上必要 なのだろうか？」 地域ネットワークのような第2層のサブドメインが、ルーティングプロトコ ルが動かせないほど大きく成長したときは、もう一つの階層を取り入れる ことが必要になるか、またはサブドメインを複数の第2層のサブドメインに 分ける必要がある。 階層構造を2層のままとし、サブドメインを増やす方が、もう一つの階層を 加えるよりも扱いやすいように見える。しかしながら、第1層やコアネット ワークにノードを加えるような、規模対応性を低くするようなことは避け るべきである。分割したサブエリアを同じコアルータに接続すれば、推奨 される以上のノードをコアエリアに加える必要はないだろう。 2層以上の階層を持つことは、今日定義されているIGPの能力を上回ること になるだろう。例えば OSPF については、すべてのエリアはバックボーン エリアに接続されなければならないため、2層以上の階層構造を持つことは できない。IS-IS についても同様の制限がある。それゆえに、プロトコル の特定エリアは再定義されることが必要で、IGP は2階層以上もつことが望 ましいだろう。2階層以上もつマルチレイヤ IS-IS の作る作業が進行中で ある。 階層の数が増えると、プロトコルと管理の複雑さも増す。[6] によると、 何年かで見つけられた OSPF プロトコルのバグの多くは、経路制御エリア のサポートに関係するところである。複数の層の間の相互作用は、管理と デバッグの複雑さを増大させるため、階層の数を最低限に保つことが望ま れる。 6.2. 区画化 大規模ネットワークの規模対応性のある経路制御設計は、問題や失敗を一 地域内にくいとめることができるべきだ。このようにして、ネットワーク のルータの資源の消耗が全体のネットワークに広がってしまったり、ネッ トワークが広範囲に不安定になることを防ぐことができる。これを区画化 という。 大規模ネットワークの経路制御設計の区画化を達成するためには、全体の 大規模ネットワークを、一つのフラットな経路制御システムまたは経路制 御ドメインとして設計することを避ける必要がある。これが、全世界的な 経路制御システムが内部と外部の経路制御に分かれて構成されている理由 である。ネットワーク内は、複数の経路制御ドメインまたは複数の経路制 御エリアに分けることが最良である。例えば OSPF では、個々のエリア経 路よりむしろ経路を要約したリンクステート広告だけがエリアを越えて一 斉広告される。エリア境界ルータがサブエリアで経路を要約しているとき は、要約経路情報を含むどの経路の不安定さも他エリアのリンクステート の一斉広告を引き起こさない。結果として、他エリアのルータ資源は、一 斉広告や SPF 再計算に消耗されない。言い換えれば、エリア内の不安定さ が全体の経路制御ドメインに広がることを妨げられる。 経路制御の階層化は本質的に大きな経路制御エリアをより小さなエリアや ドメインに分割することであるから、階層化することにより区画化が達成 できる。 6.3. 適当な調整をすること 大規模ネットワークの経路制御を設計するとき、経路制御の規模対応性と 安定性を考慮することに、全体としての目標を置くべきである。目標と衝 突することとの調整を考慮しなくてはいけない。例えば、冗長性対規模対 応性や、収束性対安定性である。 冗長性は、ネットワークトポロジに複雑さや、隣接関係の増加を持ち込む。 冗長性はまた、各々の経路にできるだけ多くの代用の方路をもつことを課 し、それは経路処理や記憶装置の負荷を増加させる。これらの問題のため、 絶対的な冗長性を犠牲にし、経路制御体系によりよい規模対応性を与える 合理的なレベルを選ぶ必要があるかもしれない。 早い収束性のためには、ネットワークトポロジの変化をできるだけ速く伝 達することが必要である。これは経路制御の更新を増加させ、その結果、 経路処理の負荷を増加させる。通常の大規模ネットワークのようにネット ワークがインターネットのすべての経路制御情報を持っているときや、ト ポロジーは頻繁に変化するときは、負荷はさらに悪化する。絶対的な収束 性を犠牲にして安定さを達成するために、経路抑制は必要かもしれない。 6.4. 経路情報処理の負荷を少なくする 経路制御処理の負荷を減らす「任務」は、戦略的にネットワーク内の経路 制御知能を配置し、必要でない経路情報を運ぶのを避け、経路のばたつき の衝撃を減少させることを含む。 6.4.1. 経路制御知能 ( Routing Intelligence ) の配置 経路制御のポリシーを実行し、経路のフィルタリングや、経路抑制を実行 するルータは経路制御知能を持っている。1) ネットワークの実体のところ で経路制御ポリシーとしてビジネス上の取り決めを実行するため、2) ネッ トワーク内の経路情報の完全な状態を守るため、そして時には3) インター ネットのほかのところで起こった不安定さからネットワークを保護するた め、経路制御知能はネットワークにとって必要なのである。 ルータが経路制御知能を多く持てば持つほど、関連する仕事のためルータ の資源もより多く必要となる。それなら、パケット転送やパケット交換の 仕事ですでに重い負荷となっているルータには、できるだけ少ない知能を 配置させることが論理的である。 通常、トラヒックはネットワークの中心でひどく集中されている。トラヒ ックはネットワークの端から中心に向かって集まるため、トラヒックはネ ットワークの端ではあまり集中されていない。従って、規模対応性のある 経路制御体系を作るためには、ネットワークの端に経路制御知能を配置す ることが賢明な方法であり、転送処理と経路制御が十分に分離されていな いルータがネットワークに配備されている場合は特にそうである。さらに、 経路制御知能をできるだけネットワークの端に押しやることは、コンピュ ータを使い設定する負荷をすべてのルータに分配する目的にも役立つ。 経路制御の重い負荷を out-of-band な処理装置に移し、パケット転送や処 理のためにもっと多くのネットワークルータの資源を解放することもまた 望ましい。 6.4.2. 経路と経路情報を少なくする 4.1節で議論したとおり、システムの中に非常に多数の経路があることは、 経路規模対応性問題の主な犯人のひとつである。必要な経路情報を失わず にシステムの経路を少なくするのが最良である。 6.4.2.1. CIDR と経路集成 [10] で詳しく述べているとおり CIDR は、IP アドレス空間を効率的に利 用し全世界の経路テーブルの数を減らすために経路を集成する仕組みを提 供する。CIDR は経路情報を要約する方法を提供し、それは今日のインター ネットにおける経路の安定の鍵の一つである。 経路を集成することは、全世界のインターネットの規模対応性を助けるだ けでなく、地域ネットワークの規模対応性にも貢献する。全体としてのゴ ールはバックボーンの経路を最小限にとどめることである。 ネットワーク内でよりよい集成を達成するためには、つまりネットワーク の経路を減らすためには、地域ネットワークがその経路をコアネットワー クに知らせるときに集成できるように、連続した IP アドレスのブロック が各々のアクセスネットワークまたは地域ネットワークに割り振られるべ きである。この方法では、コアネットワークと他の地域ネットワークは、 特定のアクセスネットワークの細かく具体的なプリフィックスを知る必要 はないだろう。プロバイダーブロックから顧客アドレスへの割当は、集成 のサポートを予定するべきであるが、その努力はやるだけの価値はある。 6.4.2.2. できるところであればデフォルト経路を利用する デフォルト経路を使用することは、経路情報を最低限に減らす究極の経路 集約の方法である。経路集約は経路のばたつきのような個々の経路に関係 する不安定さを覆い隠しもする。適切なところでデフォルト経路を利用す ることはネットワークにとって有益である。例えば、ある第2層の地域ネッ トワークがあって、そこがスタブであり、インターネットのすべての経路 情報を要求する顧客がいない場合、その地域ネットワークは単純にデフォ ルトをコアネットワークに向けることができる。しかし、経路情報の集約 しすぎには「経路制御の細やかさ」を失う危険性があり、結果としてトラ ヒックエンジニアリングなどのネットワーク管理を抑制するだろう。 6.4.2.3. 代用の方路を少なくする 信頼性の要求のために、インターネットの接続は特定の対地に向けてたく さんの方路があるという「贅沢な」結果となっている。言い換えると、同 じ対地へ向けて BGP 経路テーブルには多くの代用の方路があるということ であり、これはルータのメモリや、経路制御の処理の負荷を消耗している。 経路制御の規模対応性を高くするためには、代用の方路を減らし、手頃な 冗長性を維持することがのぞましい。例えば、ある ( NAP ルータのような) 境界ルータでは、一つの第一方路と、もう一つの代用方路が手頃な冗長性 と言えるべきだろう。この場合、3番目の方路または4番目の代用経路でさ えも、規模対応性のため捨てることができる。このように、すべてのネッ トワーク管理者がその人のネットワークの特別な要求に基づいて、調整を 決定する必要がある。 6.4.2.4. 新しい技術を利用する MPLS [11,12] のような新しい技術は、大規模ネットワークの IGP 規模対 応問題を楽にするだろう。SONET over MPLS 技術を使用するネットワーク は IP over ATM 技術よりも IGP 隣接を非常に少なくするであろう。この 削減は、IGP は物理リンクよりむしろ仮想リンクにだけに流れるという事 実のおかげであり、それゆえに IGP は隣接トポロジをフルメッシュにする 必要はない。加えて、MPLS の開発はコアネットワークのルータをすべての 外部経路を運ぶことから解放するだろうし、そのことはこれらのルータに よって処理され運ばれる経路の全体量を減らすであろう。MPLS ドメインで は、ラベル交換される方路 ( LSP ) がコアネットワーク内で確立されるこ とができるため、この削減が可能なのである。ラベルスイッチルータ ( LSR ) として機能する入り口のエッジルータはパケットにラベルを割り 当てることができる。コアにある LSP に沿った各々の LSR は、ラベルに 基づいてパケットを転送するため、コアですべての経路を知ることが必要 でなくなるわけだ。 6.4.3. エッジで静的経路を使う 前述の通り、大規模ネットワークにおける規模対応問題の一つは、一つの ルータが数百の顧客ルータに扇のように回線を伸ばし接続される可能性が あることである。その結果、もし顧客集線ルータが全ての顧客ルータと BGP セッションを確立する場合、資源消費が非常に集中するであろう。顧 客ネットワークが管理が異なるシステム (つまり別の AS ) であるという 点では、大規模なネットワークとそこに接続される顧客ネットワークが BGP を介して経路情報を交換するということは一見理に適っているように 思える。しかし不必要な場合もある。顧客ネットワークがシングルホーム の場合、つまり大規模ネットワークとの間の接続が単一であり、顧客ネッ トワークが広告する経路が多数でない場合、静的経路制御が機能しうる。 顧客ネットワークはシングルホームであるから、動的経路制御は不必要で あり、静的経路制御はサービスに悪い影響を与えない。この利点は顧客集 線ルータが扱わなければならない E-BGP セッションを少なくなり、静的 に定義された顧客経路は経路のばたつきを起こさないところにある。 顧客の静的経路をプロバイダの集線ルータで設定することは、特に顧客が 多数の経路を広告する場合に管理上のオーバーヘッドを大きくする可能性 があるが、これは採用する価値のある選択である。 6.4.4. 経路のばたつきの影響を最小化する 前述の通り、経路のばたつきは不安定なリンクや the Internet 上の過度 な経路更新を引き起こす BGP セッションの不安定によって引き起こされる ことが多い。経路のばたつきはグローバルインターネットのどこででも起 き、また the Internet の経路制御メッシュ ( BGP メッシュ) にある全て のネットワークに影響を及ぼす可能性がある。the Internet では 60,000 経路が知られ、経路のばたつきを遮断するものがほとんどないものだとす ると、どんなネットワーク上のルータでも経路のばたつきの扱うことは避 けられない。 経路のばたつきの弊害を軽減する方法の一つは、[10] に規定されている経 路抑制を起動することである。経路抑制は不安定な経路情報を安定するま で抑制するというものである。現在の利用法は、各 ISP の境界ルータにお いて経路抑制を起動するという方法である。これによって境界において過 度な経路更新を止めることができる。 理想的なモデルは、ばたついている経路の広告を正に生成源で抑制するこ とである。これを実現する方法の一つは、直接接続されるリンクによって 引き起こる不安定をルータ自身が検知し、経路の広告を抑制することであ る。現状そのような実装はないが、このアプローチは探求されるべきであ る。 経路集成は、集成経路の構成要素 (よりスペシフィックな経路) のばたつ きが集成経路に影響を及ぼさないため、経路のばたつきを防ぐことができ る。それゆえ CIDR の利用も経路のばたつきの軽減に役立つであろう。 6.5. 規模対応性の高い経路制御ポリシと規模対応性の高い実装 経路制御ポリシは、2つ以上の到達経路が利用可能である場合に、それらの 経路を広告/受領すること，およびそれらに対する優先性に関する決定を含 んでいる。経路制御ポリシはネットワーク間のビジネス上の取り決めを実 現し、また多分に非技術的条件によって左右されるが、本質的には経路制 御ポリシは経路選択と経路フィルタリングの条件を決定することの2つを示 す。 経路フィルタリングはある面で、経路制御ドメインまたは異なるプロバイ ダネットワーク間のトラヒック制御を実現しなければならない。それぞれ のプリフィックス毎にポリシを定めることは、the Internet の 60,000プ リフィックスには規模対応しないため、この場合避けるべきである。ある プリフィックス群を管理上代表する AS によってポリシを定めるほうが規 模対応性は高い。 経路フィルタリングのもう一つの目的は、トラヒックをブラックホールに 導く誤広告経路情報の受領を防ぎ、経路情報の完全性を守ることである。 この場合、プリフィックスによるフィルタリング以外の方法はその目的を 充分に達成することができない。プリフィックスによるフィルタリングは 直接顧客のネットワーク及びピアするネットワーク群との境界においてな される必要がある。ピアするネットワークは通常大量のプリフィックスを 広告するため、ピアするネットワーク群との境界においてこのフィルタリ ングを管理することは難しい。前述の通り the Internet には 60,000 ほ どの経路が知られている。これは default-free なネットワークでは数十 万単位、また一つの経路は2つ以上の生成源から広告されている可能性があ ることからそれ以上の数の経路をフィルタリングする必要がある。全面的 な規模でプリフィックスがフィルタリングされることは、ルータのコンフ ィグレーションメモリとコンフィグレーションの管理に試練を与えること となる。これを規模対応させるためには、生成源から受領/拒否されるべき プリフィックスを区分する out-of-band なプロセスの助けを借りる必要が あるであろう。IRR [13] と DNS [14] がプリフィックスによるフィルタリ ング実現の機構として現在提案されている。 経路選択ポリシはどの方路がある対地に対してトラヒックを送るのに用い られるかを決定する。これは、例えばあるネットワークが別のネットワー クに対して2つの接続を持っておりそれぞれの接続から経路を得る場合に、 重要である。この決定は他のネットワークの向こうに接続されている顧客 に対してトラヒックを送る場合にも含まれるであろう。典型的な選択肢は 以下の通り。 o ネットワークを出て行くトラヒックをもっとも近い方路に向かわせる。 このポリシはホットポテトルーティング ( Hot-Potato-Routing ) と しても知られている。 o 最適なネットワークの出口に向かわせる。最適な出口はネットワーク 管理者による一定の条件を基に決定され、必ずしも最も近い出口とは 限らない。 o 常に直接接続される顧客が広告している経路を好む o 他のネットワークや顧客に方路決定させることを許可する 一つポリシが決定された場合、規模対応可能な実現方法との係わり合いが 考慮される必要がある。例えば、顧客にどの方路にトラヒックを流すかを 決定されることを許可するポリシの場合、プロバイダではなく顧客が、彼 らの望む方路を経路制御機構が好むように経路制御パラメータを設定する ことが要求されるべきである。顧客は BGP コミュニティや MED のような 仕組みを使って、より規模対応性の良い方法で経路制御の優先性を設定す ることができる。そうするとこのような経路制御管理の負担をプロバイダ だけが負うことを避けられることとなる。経路制御管理の負担を分散させ ることは、ポリシ実装をより規模対応可能とする。 もう一つの規模対応の方法は、複雑なポリシ策定を避けることである。経 路制御ポリシが複雑である場合、ルータのコンフィグレーションや障害解 析などの運営が問題となる。最終目的は、ネットワークを運営可能とする ことである。 以下の基本指針は経路制御ポリシ運営の規模対応の助けとなるであろう。 o 要件を満たす範囲で可能な限りポリシを簡素にする o 間違いの起こりやすい手作業を避け、可能な限り自動化する o 経路制御の完全性のためにプリフィックスによる経路フィルタリング を実施することは例外として、プリフィックス毎のポリシは可能な限 り避ける o 例外を作ることを避ける o 可能であれば out-of-band な経路制御ポリシプロセスを使う。 6.6. Out-of-Band プロセス 典型的なルータは経路制御とパケット転送の機能を果たすが、概念的には 経路制御とパケット転送は2つの別々の処理である。ルータの根本的な仕事 は、経路情報から引き出される転送テーブルに従ってパケットを転送する ことである。経路制御の規模対応の問題の主要な原因の一つは、経路制御 にあまりに多大な処理が要求されるためルータが力を使い果たすことにあ る。ルータはパケットを転送しなければならないのであって、経路情報の やりとり，処理，また経路制御ポリシの実行は必要ない。これらの仕事は どこか他のところで行われれば良いのである。つまり質問はこうである。 ルータの負担を軽減するために、経路制御の処理を取り除くことが可能で あろうか。経路制御処理をルータから他のシステムに移すことが、 out-of-band 経路処理と呼ばれるものである。 手短に言うと、out-of-band 経路処理は過酷な経路制御タスクを実行する。 ルータのために転送テーブルを作成し、予め定義されたポリシに基づいて 経路選択を行い、経路をフィルタリングし、経路のばたつきからルータを 守る。 out-of-band 経路制御処理の欠点は、経路制御の変化に対する遅れを引き 起こすこと， 経路制御とフォワーディングを引き離し、不正確な経路情報 を生み出すこと， 新たな装置のためのコスト，である。 付録 A では、out-of-band 経路処理の実例を示し、同時に他の方法の可能 性を示す。 7. 結論と議論 経路制御がどれだけ規模対応するかは、ネットワークの安定性と性能に直 接影響を与える。the Internet の速い成長とそれに伴うプロバイダのネッ トワークの速い拡張によって、経路制御の規模対応はますます重要な問題 となっている。この文書は経路制御の規模対応性に影響する主要な要因を 洗い出し、大きなネットワークにおいて規模対応可能な経路制御設計のた めの基本指針を定めるものである。 我々が今日直面している主要な経路制御の規模対応性の問題は、経路制御 処理の負担による過剰なルータの資源消費がネットワークの不安定を引き 起こすことと、経路制御が複雑になることで管理と障害解析を困難にし、 サービスの品質低下を引き起こすことである。 概説してきた規模対応可能な経路制御システムの設計に関する原則は、経 路制御の階層化，可能な部分で経路制御処理を減らすこと，管理可能な経 路制御ポリシを定めること，及び out-of-band な経路制御処理の助けを借 りること、である。 out-of-band な資源を経路制御処理の補助に用いることは、相互接続点で 使われるだけの概念であったが、経路制御の規模対応性問題に対処するた めネットワークの中で使われる可能性が多分にある。これは更なる探求に 値する事項である。 経路制御プロトコルとその実装は、規模対応問題をよりうまく扱うために、 未だ改良，拡張の余地がある。例えば IS-IS のマルチプルエリア機構は大 規模ネットワークにおいて IGP を規模対応させるために必要とされる。ま た、マルチキャストや信頼性の高い一斉広告機構を I-BGP の経路更新に用 いてフルメッシュピアリングの代用とすることは、調査に値するものであ る。 DWDM，MPLS などなどの新技術が今後展開されてもなお、基本的な経路制御 の体系は現在の IGP/BGP の枠組みの中に留まるであろうと我々は信じてい る。よって本文書で概説された規模対応可能な経路制御設計の指針は新技 術が展開されても適用されるべきである。 8. セキュリティに対する配慮 　セキュリティに対する配慮は、本文書の範囲外である。 9. 謝辞 Curtis Villamizar の本文書の広範な吟味と有益なコメントと，Dave Katz と Yakov Rekhter の見識深いコメントに感謝する。 10. 参考文献 [1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990. [2] R. Callon. "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments.", RFC 1195, December 1990. [3] J. Moy. "OSPF Version 2." RFC 2328, April 1998 [4] Y. Rekhter, T. Li. "A Border Gateway Protocol 4 (BGP-4)." RFC 1771, March 1995 [5] C. Labovitz, R. Malan, F. Jahanian, ``Origins of Internet Routing Instability," in the Proceedings of INFOCOM99, New York, NY, June, 1999. [6] J. Moy, "OSPF- Anatomy of an Internet Routing Protocol." Addison- Wesley, January 1998. [7] T. Bates, R. Chandra, E. Chen, "An alternative to full mesh IBGP" Working in Progress [8] P. Traina, "Autonomous System Confederation Approach to Solving the I-BGP Scaling Problem." RFC1965, June 1996 [9] V. Curtis, R. Chandra, R. Govindan, "BGP Route Flap Damping." RFC 2439, November 1998. [10] V. Fuller, T. Li, J. Yu, K. Varadhan "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy." RFC 1519, September 1993. [11] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture for MPLS", Work in Progress. [12] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, "A Framework for Multiprotocol Label Switching." Work in Progress. [13] V. Curtis, C. Alaettinoglu, R. Govindan, D. Meyer, "Distributed Routing Policy System." Internet Draft, February, 1999. [14] T. Bates, R. Bush, T. Li, Y. Rekhter, "DNS-based NLRI origin AS verification in BGP." Working in Progress. [15] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services." RFC 2475, December 1998. [16] Y.Bernet, et al "A Framework for Differentiated Services." Internet Draft, February 1999. [17] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS. " Internet-Draft, October 1998. Author's Address Jieyun (Jessica) Yu UUNET Technology 880 Technology Dr. Ann Arbor, MI 48108 Phone: (734) 214-7314 EMail: jyy@uu.net 付録 A. out-of-band 経路制御処理 NAP におけるルートサーバ ( RS, Route Server ) の利用は、out-of-band 経路制御処理によって経路制御の規模対応を達成する例である。NAP は ISP のネットワークがトラヒックを交換する公開された相互接続点である。 NAP のISP ルータは BGP ピアセッションを相互に確立している。その結果 システム全体としては O(N^2) の複雑性を持つフルメッシュの E-BGP ピア リングとなり、RS が置かれる場合、各ルータは RS (及びバックアップ) と ピアすることによって、必要な経路情報 (より正確に言うと、必要となる転 送先情報）を手にいれることができる。また RS は各プロバイダのルータに 対して経路フィルタポリシを施行し、全てのルータにかかる負担を更に軽減 する。ルートサーバの考え方は、大きなネットワークにおいて経路制御の規 模対応の助けともなりえる。 1) RS を顧客ルータと顧客集線ルータの間のピアリングの助けに使う 現在、典型的な大規模プロバイダネットワークにおいては、顧客集線ルー タに数百の顧客ルータがつながることは珍しいことではない。これは顧客 集線ルータが集百の E-BGP セッションと膨大な数のプリフィックスフィル タを取り扱わなければならないということを意味している。これらの任務は 集線ルータに重い負担を課すであろう。集線ルータ一台当たりの顧客ルータ の数を減らすことは、全ネットワークの経路制御システムにより多くのルー タを導入することになって、バックボーンの経路制御の規模対応性を低くす るとともにコスト効率も悪くなるため選択するべき方法ではない。RS を顧 客とプロバイダの顧客集線ルータの間で使うことは、ルータの負荷を軽減す る魅力的な選択となる。 図1 は、プロバイダの顧客集線ルータと顧客ルータの間に RS ルータを組み 入れる方法を示したものである。 --------------------------- POP の LAN メディア | | ----- ----- |CR | |RS | ----- ----- / | / | C1 C2..Cn 図1: RS を顧客集線ルータと顧客ルータとの接続において利用する RS がない場合、顧客集線ルータ ( CR ) は顧客ルータ C1, C2 ... Cn (n は数百になりえる) とピアしなければならない。RS ルータが導入される場 合、CR, C1, C2 ...Cn はそれぞれ替わりに RS ルータとピアし、RS はポ リシとフィルタに従って処理された経路制御情報 (あるいはパケット転送 情報) を渡す。 優位性は明白である。 o 顧客集線ルータは数百の顧客ルータとの替わりにRS ルータとだけピアす ればよい。 o 顧客集線ルータは経路制御ポリシの適用やプリフィックスのフィルタリ ングを行う必要がなく、資源はパケット転送処理のために解放される。 RS ルータ利用に関する一般的な関心は、経路制御の上での隣接関係と物理 的隣接関係が一致しない可能性がある点である。例えば CR と C1 の間の リンクがダウンし、かつ RS ルータがその故障を検知しない場合、RS は C1 からの経路を顧客集線ルータに渡しつづけ、これらの経路に従うトラヒ ックが black hole されるだろう。しかし、ここで示したケースではこれ は問題にはならない。それは RS ルータは、C1, C2 ... Cn とのピアが集 線ルータを通過するため、このリンクがダウンしている場合 C1 は RS ル ータからアクセス不能となり、経路情報はこれら2つの間で交換されるこ とはない。結果的に RS は C1 に関係する経路のアナウンスをしない。 もう一つの関心は single point of failure が発生することである。RS ルータがダウンする場合、顧客集線ルータと C1, C2 ... Cn の間で経路情 報の交換は行われず、トラヒックはこれらの間には流れない。この問題は バックアップとして2つ目の RS ルータを付け加えることで対処可能であろ う。 この場合、RS は CR を介して C1 ... Cn とピアしているため、RS ルータ が経路情報を C1...Cn に渡す場合、CR の IP アドレスをネクストホップ として指定する必要がある。同様に RS ルータは各顧客ルータから集線ル ータに経路情報を渡す場合、経路情報に正しいネクストホップを置く必要 がある。このような機能を実現するため、RS のコードは修正される必要が ある。 2) 相互接続点におけるプライベート RS ルータ 大きなプロバイダネットワークでは、相互接続点，NAP，プライベート相互 接続などにおいてたくさんの BGP ピアを持つことが多い。これはボーダル ータがたくさんの E-BGP セッションの取り扱わなければならないというこ とを意味する。相互接続点は通常 ISP の管理境界であるため、ポリシや経 路フィルタリングが非常に要求される。このことは、ボーダルータに対し て規模対応の問題を課す。 負荷分散のために多数のルータを配置することは高価な解決方法である。 ハードウェアやポートの追加には金がかかる。RS ルータに経路制御の負担 を移すのは期待できる解決方法である。プライベートな相互接続点におけ る複数のピアに RS を用いる場合、シナリオは上の 1) に述べたように顧 客集線ルータと顧客ルータの間に RS を用いるのと似ている。NAP のピア のような場合はプライベート RS は NAP の LAN 上にも ISP の NAP ルー タと RS の間の LAN にも置くことができる。 3) 大規模ネットワークの各 POP に RS ルータを置く 階層的経路制御構造を持つネットワークにおいても、サブエリアが大きく なりすぎ、I-BGP フルメッシュが規模対応問題を持ちこむ場合がある。こ れに対処する方法の別の方法は、サブエリアを分割したり、I-BGP リフレ クタ構造に新たな階層を加えることである。またもう一つの解決方法とし てありえるのは、I-BGP サーバとして RS ルータを使うことである。POP のトポロジによってこの解決方法は適不適が分かれるであろう。POP にお いて RS ルータを使うことは更に研究されるべきである。 ---------+---------+---------+---------+---------+---------+---------+