JP5331123B2

JP5331123B2 - ルート・サーバの各種方式および装置

Info

Publication number: JP5331123B2
Application number: JP2010534087A
Authority: JP
Inventors: パターソンレイン; シュミットマルセロ; フードロバート; シーリゾジェフリー
Original assignee: イクイニクスインコーポレイテッド
Priority date: 2007-11-16
Filing date: 2008-10-28
Publication date: 2013-10-30
Anticipated expiration: 2028-10-28
Also published as: WO2009064612A1; US8645568B2; ATE505884T1; JP2011504047A; EP2218222A1; DE602008006263D1; US20090182896A1; EP2218222B1

Description

著作権の表示

本特許出願の開示の一部には著作権保護の対象となる資料が含まれている。著作権の所有者は、特許商標局の特許ファイルまたは記録に記載される通りに、他者がソフトウェアエンジンおよびそのモジュールを複製する場合、これに意義を申し立てないが、その他の場合のすべての著作権は如何なる場合にも保護される。

発明の分野

本発明の実施例はネットワーク通信に関し、特に、本発明の実施例の分野は複数のユーザを複数のネットワーク・プロバイダに接続するルート・サーバに関する。

発明の背景

各種帯域幅のプロバイダが存在するが、個人ユーザがネットワーク・サービスを使用するために必要な、長期契約や帯域幅の最低保証を要求するプロバイダーもいる。

ルート・サーバがネットワーク・ユーザをネットワーク・プロバイダに接続する方式、装置、およびシステム。実施例では、ルート・サーバを経由して、複数のインターネット・ネットワーク・サービス・プロバイダからルータを含む複数のユーザのネットワーク要素へ接続するプログラムのコードをルート・サーバに持たせることができる。また、複数のユーザおよび複数のインターネット・ネットワーク・サービス・プロバイダのためのルーティングを決定し、その決定をＢＧＰにより複数のインターネット・ネットワーク・サービス・プロバイダの１つ以上に伝えるようにプログラムしたコードをルート・サーバに持たせることもできる。また、ルーティング・テーブルの複数のビューを保持し、ルート・サーバの１つのインスタンスに異なる自律システムを表す複数のＢＧＰインスタンスを実装するようにプログラムしたコードをルート・サーバに持たせることもできる。第１ユーザのＩＰパケットを目的アドレスに届けるためのルート・テーブルを構築するため、ユーザの条件（criteria）に合わせ、第１ユーザが各インターネット・ネットワーク・サービスを使用するための最良経路だけでなく、各インターネット・ネットワーク・サービスから使用可能な宛先アドレスへの全経路のリストから選択できる経路を含み、第１ユーザおよび複数のインターネット・ネットワーク・サービス・プロバイダの両方から提供される条件に基づいて、第１ユーザを１つ以上のインターネット・ネットワーク・サービス・プロバイダに接続するようにプログラムしたコードをルート・サーバに持たせることもできる。

ネットワークに接続している複数のインターネット・ネットワーク・サービス・プロバイダ（ＩＳＰ）をルート・サーバを経由して複数のユーザーに接続するルート・サーバのブロック図である。ネットワークに接続している複数のインターネット・ネットワーク・サービス・プロバイダ（ＩＳＰ）をルート・サーバを経由して複数のユーザに接続するルート・サーバのブロック図である。ルート・サーバの同一インスタンスに、ルーティング・テーブルおよびＢＧＰの複数のインスタンスの複数のビューを保持するルート・サーバのブロック図である。ルート・サーバでスレッド化された複数のデーモンの実施例の機能ブロック図である。ルート・テーブルの実施例の図である。トラフィック・アカウンティングおよびルート・サーバのカスタム化経路部の実施例のブロック図である。メモリおよびビューを使用するルート・サーバの図である。

本発明は各種の変更および代替形態が可能であるが、具体的な実施例は図で示したものであり、以下にそれらを詳細に説明する。ただし、本発明は開示されている特定の形態に限定されるものではなく、本発明の精神と範囲を逸脱しないすべての変更、相当物、および代替物を含む。

以下の説明では、本発明を十分理解できるよう具体的なアルゴリズム、名前を付けたコンポーネント、接続、ルート・テーブルにある経路の数などの多数の具体的な詳細について説明する。ただし当業者には明らかなように、本発明ははこれらの具体的な詳細がない場合でも実行できる。他のインスタンスでは周知のコンポーネントや方式は詳細に説明していないが、このブロック図では不必要に本発明をあいまいにすることを避けるため詳細に説明する。更に、第１のＩＳＰなど具体的な番号を用いることもできる。ただし、具体的な番号は文字通り番号順に解釈すべきではなく、第１のＩＳＰは第２のＩＳＰとは異なると解釈すべきである。従って、具体的な詳細は単に例として記述するものである。具体的な詳細は、本発明の精神と範囲と異なることもあるがその範囲内で考えることもできる。

一般には、ルート・サーバがネットワーク・ユーザをネットワーク・プロバイダに接続する方式、装置、およびシステムを説明する。実施例では、ルート・サーバを経由して、複数のインターネット・ネットワーク・サービス・プロバイダからルータを含む複数のユーザのネットワーク・エレメントへ接続するようにプログラムしたコードをルート・サーバに持たせることができる。また、複数のユーザおよび複数のインターネット・ネットワーク・サービス・プロバイダのためにルーティングを決定し、ＢＧＰによりこれらの決定を複数のインターネット・ネットワーク・サービス・プロバイダの１つ以上に伝えるようにプログラムしたコードをルート・サーバに持たせることもできる。また、ルーティング・テーブルの複数のビューを保持し、ルート・サーバの１つのインスタンスに異なる自律システムを表す複数のＢＧＰインスタンスを実装するようにプログラムしたコードをルート・サーバに持たせることもできる。また、ユーザおよび複数のインターネット・ネットワーク・サービス・プロバイダの両方から提供される条件に基づいて、第1のユーザーを１つ以上のインターネット・ネットワーク・サービス・プロバイダに一致させるするようにプログラムしたコードをルート・サーバに持たせることもできる。その条件には、ユーザーのＩＰパケットを目的アドレスに届けるためのルート・テーブルを構築するために、ユーザの条件に合わせて、各インターネット・ネットワーク・サービスで使用できる最良経路だけでなく、各インターネット・ネットワーク・サービスから使用可能な宛先アドレスへの全経路のリストから選択できることが含まれる。ルート・サーバは、これらのセッションでこれらの全リストを受け取り、これらの追加セッションでピアと双方向の通信を行えるように、各ユーザーに追加のピアリング・セッションを許可する。

図１及び２は、ネットワークに接続している複数のインターネット・ネットワーク・サービス・プロバイダ（ＩＳＰ）をルート・サーバを経由して複数のユーザーに接続するルート・サーバのブロック図である。システムには１つ以上のルート・サーバ１０５，２０５があり、各ユーザのネットワークへの１回の接続による１回以上のセッションで１人以上のユーザ／バイヤ１３１、２３０に接続し、ＩＳＰ−１１２１およびＩＳＰ−２１２２を含む１つ以上のＩＳＰ２３０に接続する。

図１のルート・サーバ１０５は、ルート・サーバ１０５がグローバル・ルーティング・テーブルを参照する方法が標準ＢＧＰルータと異なる。標準ＢＧＰルータは、ルータがパケットを転送する場合に使用するビューと同じルーティング・テーブルのビューを１つだけ保持する。ルート・サーバ１０５は、ルーティング・テーブルの複数のビューを保持する。実施例では、次に、ルート・サーバ１０５は各ピアにルーティング・テーブルのカスタム・ビューを提供する。従って、ルート・サーバ１０５はルーティング・テーブルに多対多の複数のビューを保持する。実際のトラフィック転送は、ルート・サーバではなく、ルータにより実行される。ルート・サーバ１０５はルーターに対し、ルート・サーバ１０５が、ルート・テーブルなどのメカニズムを経由してトラフィックをどこに進めるべきだと考えているかを伝えるのみである。

ルート・サーバ１０５には、ルータを含む複数のネットワーク・エレメントを、インターネット・ネットワーク・サービス・プロバイダ１２１、１２２から、ルート・サーバ１０５を経由して各ユーザのネットワーク要素に接続するようにプログラムしたコードが含まれる。また、ルート・サーバ１０５に、複数のユーザ１３１および複数のインターネット・ネットワーク・サービス・プロバイダ１２１、１２２のためにルーティングを決定し、ＢＧＰによってこれらの決定を複数のインターネット・ネットワーク・サービス・プロバイダ(ピア)１２１、１２２の１つ以上に伝えるようにプログラムしたコードを含むことができる。例えば、ルート・サーバ１０５は、ルート・サーバ１０５が最良パスとして決定し、ユーザーの条件に一致するルータ・アドレスへＩＰ次ホップを設定するためにルート・テーブルのビューを作成できる。また、ルート・サーバ１０５が各ピアに参照させたい各ビューなど、ルーティング・テーブルの複数のビューを保持するようにプログラムしたコードをルート・サーバ１０５に含むこともできる。また、ルート・サーバ１０５の１つのインスタンスで複数のＢＧＰインスタンス(各インスタンスは異なる自律システムを表す)を実装するようにプログラムしたコードをルート・サーバ１０５に含むこともできる。また、ｂｕｙｅｒ−１１３１などの特定ユーザおよびインターネット・ネットワーク・サービス・プロバイダ１２１、１２２の両方に提供される条件に基づき、そのユーザーを１つ以上のインターネット・ネットワーク・サービス・プロバイダに一致させるようにプログラムしたコードをルート・サーバに持たせることもできる。各ユーザーおよび複数のインターネット・ネットワーク・サービス・プロバイダの両方により提供される条件には、第１のユーザーのＩＰパケットを宛先アドレスに届けるためのルート・テーブルを構築するために、各ＩＳＰによって通知された最良経路だけでなく、ユーザーの条件に一致する各宛先アドレスへのすべての最良経路のリストからユーザーが選択できることが含まれる。

ルータ・サーバー１０５は、ユーザ１３１をＩＳＰ１２１、１２２に接続するためにＢＧＰ−４などのＢＧＰを実装する。ＢＧＰは、自律システム間で使用する相互自律システムのルーティング・プロトコルである。自律システムは、共通の管理の下にあり共通のルーティング・ポリシーを持つネットワークまたはネットワーク・グループでもよい。ＢＧＰはインターネットのルーティング情報を交換する際に使用されるインターネット・サービス・プロバイダ（ＩＳＰ）間のプロトコルである。大学や企業などのユーザ・ネットワークでは、ルート・サーバ１０５を経由して複数のＩＳＰに接続し、ＩＳＰはＢＧＰを使用してカスタマおよびＩＳＰ経路を交換する。

ＢＧＰルータ・サーバは、一般的なルーターの１対多ではなく多対多のピア関係を制御する。ユーザーがＩＳＰをいくつ選択したかに拘わらず、ルート・サーバ１０５はルート・サーバ１０５に関連する各ネットワーク・エレメントから１つのＢＧＰフィードを受け取ることができるので便利である。

図３は、ルート・サーバの同一インスタンスにルーティング・テーブルおよびＢＧＰの複数のインスタンスの複数の表示を保持するルート・サーバのブロック図である。

ルート・サーバ３０５には、同じピアと交信するＢＧＰの複数のインスタンスをサポートするコードが含まれる。基本的に、ルート・サーバ３０５はネイバーがどのＩＰとピアとなるか決定し、それに基づいてそのＩＰアドレスを異なるビューで表示する。ＩＰアドレスを異なるビューに配置することにより、ルート・サーバ３０５はルーティング・テーブルの複数の異なるビューを単一ピアに送信できる。そのため、ルート・サーバ３０５では、バイヤーは複数のアップストリームからルーティング・テーブルを同時に参照することができる。複数のＢＧＰ「インスタンス」はルート・サーバ３０５で実行でき、ここでは各ＢＧＰインスタンスが独自のルータＩＤを持ち、異なるＩＰアドレスとＴＣＰソケットで受信することができ、すべてのＢＧＰインスタンスは同じＢＧＰ自律システム番号の一部となる。

図１のルート・サーバ１０５もまた、複数のＢＧＰインスタンスを使用できる。各プロバイダーのＢＧＰセッションでバイヤーは別のＩＰアドレスとピアを組み、特定のＩＳＰプロバイダから送られたこれらの経路のみを得る。以下の構成を持つスニペットは、例の基本レベルでどのように組み合わせるかを示している。このスニペットはＢＧＰインスタンスの相互作用を示す一例である。

view isp-1
class transit
import buyer-1 class buyer-1

view isp-1-out
import isp-1 transit
class isp-1-per-prov
prefix-map 10 buyer-1-list
set add-class isp-1-per-prov
set weight 65535

view isp-2
class transit
import buyer-1 class buyer-1

view isp-2-out
import isp-2 transit
class isp-2-per-prov
prefix-map 10 buyer-1-list
set add-class isp-2-per-prov
set weight 65535

view buyer-1
class buyer-1
import isp-1 class transit
import isp-2 class transit

view buyer-1-isp-1
import isp-1 class transit

view buyer-1-isp-2
import isp-2 class transit

router bgp main 65500 192.168.1.14/24 default
bgp router-id 192.168.1.14
neighbor 192.168.1.15 remote-as 65501
neighbor 192.168.1.15 view isp-1
neighbor 192.168.1.16 remote-as 65502
neighbor 192.168.1.16 view isp-2
neighbor 192.168.1.17 remote-as 65503
neighbor 192.168.1.17 view buyer-1

router bgp isp-1 65500 192.168.1.13/24
bgp router-id 192.168.1.13
neighbor 192.168.1.17 remote-as 65503
neighbor 192.168.1.17 view buyer-1-isp-1

router bgp isp-2 65500 192.168.1.12/24
bgp router-id 192.168.1.12
neighbor 192.168.1.17 remote-as 65503
neighbor 192.168.1.17 view buyer-1-isp-2

! prefix list buyer-1-list
ip prefix-list buyer-1-list 10 permit 192.168.1.17.0/24

上記の構成では、ＩＳＰ１２１でＧＰセッションを、ＩＳＰ１２２でＢＧＰセッションを、さらにＢｕｙｅｒ−１３１で３つの分離しているＢＧＰセッションを設定している。第１のＢＧＰセッション（ＢＧＰメイン・インスタンスのｂｕｙｅｒ−１ビューから)ではＩＳＰ１とＩＳＰ２から混合経路に通信し、Ｂｕｙｅｒ−１３１から経路を取り、それらをＩＳＰ１２１とＩＳＰ１２２に送る。他の双方向第２ＢＧＰセッションでは、ｉｓｐ−１とｉｓｐ−２インスタンスで、ＩＳＰ１２１とＩＳＰ１２２からそれぞれ最良経路を送るだけでなく、各ピアの全経路プレフィックスも送る。従って、双方向第２セッションは、ピアとルート・サーバ１０５間およびユーザ・クライアントとルート・サーバ１０５間でオープンになっている。ユーザ・クライアントとピアは、別のセッションではなく同じセッションで、ルート・サーバ１０５に各ピアの全経路プレフィックスを送信して各自律システムの全経路プレフィックスを得る。ユーザは、条件に一致するＩＰパケットの宛先アドレスへの最良経路だけでなく、各プロバイダから提供されたすべての可能な経路のリストから選択できる。

各ユーザが提供する条件には、サブセットとして、使用可能な全経路のリストの受け取りを希望するインターネット・ネットワーク・サービス・プロバイダを含むことができる。ルート・サーバ１０５は、特定のユーザーが選択したサブセットの各インターネット・ネットワーク・サービス・プロバイダからのすべての経由経路を受けとるため、ルート・サーバ１０５と各ユーザのネットワーク要素間に１つ以上のＢＧＰピアリング・セッションを追加する。追加されたＢＧＰピアリング・セッションでは、ルート・サーバ１０５と各ユーザのネットワーク要素間に双方向の通信が確立される。ＢＧＰピアリング・セッションでは、ルート・サーバ１０５とユーザのネットワーク・エレメントが、ＩＳＰを経由するのではなく、直接トラフィックを相互に送信できる。特定のユーザは、追加ＢＧＰピアリング・セッションで１つ以上のＩＳＰに、メインのＢＧＰピアリング・セッションで通知した情報とは異なる情報を送り返すことができる。残りのオンネット・プロバイダは、常に、それぞれのネットワークへの最良経路のみを提供する。

実施例では、ユーザは、ルート・サーバ１０５により、さまざまなフィルタ１０２を全ルート・プレフィックスのリストに適用し、特定のＩＳＰからユーザに提示される希望しないルート・プレフィックスの量を削減することができる。ルート・サーバ１０５は、これらの経由経路上にあるさまざまなフィルタ１０２を、経由経路からの特定のルート・プレフィックスへのフィルタ・イン、フィルタ・アウト、フィルタ・インとフィルタ・アウトのいずれかに適用する。フィルタ１０２は、経路マップ、ＡＳパス、プレフィックスリスト・フィルタ、サード・パーティの経路承認データベース、サービス・クラス、または同様の条件など、ネットワーク経由パスをフィルターする際のユーザーの条件に合わせることができる。このように、ユーザーおよびルート・サーバ１０５は、各プロバイダにＢＧＰピアリング・セッションを確立できる。各プロバイダのＢＧＰピアリング・セッションでは、宛先アドレスにたどり着くために使用可能なすべての、または絞り込まれた経路リストが、ユーザにより選択された経由ＩＳＰプロバイダのみに使用できる。

プレフィックス・セットは、特定のＩＳＰから通知されたプレフィックスを、サード・パーティのプレフィックス番号を通知する権利を記録したサード・パーティ経路認証データベースと比較してフィルタリングする。従って、サード・パーティ経路認証データベースによりその経路の権利が別のＩＳＰに属している場合、ルート・サーバ１０５は第１ＩＳＰにより通知された経路を承認しない。

各プロバイダのＢＧＰセッションでは、バイヤーは各プロバイダに通知する内容をいつ通知するか、またバイヤーが各プロバイダから何を受け取るかの両方を制御できる。これにより、着信トラフィックと発信トラフィックに影響するルーティング・ポリシーを別々に制御できる。ユーザはプロバイダＡにあることを通知し、同じバイヤーはプロバイダーＢに別のことを通知できる。退出トラフィックは一般にユーザーの各プロバイダーのフィードのローカル・プレフィックス（Local-Pref）の設定に左右される。ユーザーは追加ピアリング・セッションを使用して退出および進入トラフィックを操作する。進入トラフィックは、一般に、ユーザーの各プロバイダのセッションでのＡＳパス長の通知に左右される。ユーザーのルータは、追加のＢＧＰセッション・フィードで選択した１つ以上のインターネットの全経路を格納するための追加負荷およびメモリ要件をサポートする必要がある。実施例では、ユーザーにより選択されたＩＳＰプロバイダのサブセットは、各プロバイダのＢＧＰセッションに最大３つまで構成できる。これらの各プロバイダーのＢＧＰセッションでは、ユーザーのメインＢＧＰセッションと同じピアのＡＳＮを使用する。そのプロバイダに対するユーザーの帯域幅が起動して十分なレベルに達するまで、特定のＩＳＰプロバイダの各ユーザによる各プロバイダのＢＧＰセッションでは始まらない。ルート・サーバ１０５は、ユーザに、選択されたＩＳＰプロバイダに対応するＩＰアドレスを伝える。その後、各ユーザは、各プロバイダが機能できるように新しいＢＧＰセッションを追加し、適切なルート・フィルタ１０２を構成する。例えばそれらのルータのメモリが不足している場合、ユーザはインターネットのＢＧＰルート・テーブルのサブセットを指定できる。

上述したように、一般的なＢＧＰルーティングの更新は、ユーザにとって最適かつ最良な宛先ネットワークへの経路のみを公開するが、ルート・サーバ１０５はユーザーが使用できる宛先ネットワークへの全経路をアドバタイズする。ＢＧＰは非常に頑健で拡張可能なルーティング・プロトコルである。インターネットのＢＧＰルーティング・テーブルには、１２０，０００経路以上のリストを含ませることができる。このレベルで拡張性を確保するために、ＢＧＰは特性などの多数の経路パラメーターを使用して経路ポリシーの定義付けを行い、安定した経路環境を保持する。各インタードメインはそのＢＧＰピアへの経路をアドバタイズする。ＢＧＰのネイバーは、ネイバー間のＴＣＰ接続を最初に確立したときに経路情報を交換する。一般に、ルーティング・テーブルが変更されたことが検出されると、ＢＧＰルータは変更された経路のみをネイバーに送る。

ルート・サーバ１０５はＢＧＰの最良のパス機能と、ユーザおよびプロバイダが提供した条件を使用して、ユーザからのＩＰパケット・トラフィックに最も一致するパスを決定する。ＢＧＰは、複数のＩＳＰソースから同じ経路に対して複数のアドバタイズを受け取ることもできる。ユーザおよびＩＳＰプロバイダから提供された条件は比較され、評価する経路が決定される。次に、一般にはＢＧＰは、ルーティング・テーブルに記入する最良パスとして経路を１つだけ選択する。経路が選択されると、ＢＧＰは選択された経路をＩＰルーティング・テーブルに加え、その経路をネイバーに伝播する。ＢＧＰコードは、Weight、Local preference、Multi-exit discriminator、Origin、AS_path、Next hop などのネットワーク基準例を使用し、宛先へのパスを選択する。重要なステートメントで特定のビューでピアにアドバタイズするためにどの経路を使用できるか決定すると、選択アルゴリズムを引き続き実行し、(１つ以上のバージョンがある場合は)どのバージョンの経路を送るか決定する。選択アルゴリズムは次の通りである。

１） next-hop フィールドが発信元のネイバーのＢＧＰインスタンスの正しいサブセットにあるかチェックする。正しくない、または next hop にアクセスできない場合、その経路を検討対象から除外する。
２）経路がダンプされる場合(つまりＢＧＰダンピング)、その経路は検討しない。
３）最大の WEIGHT を持つパスを指定する。
４）同じ WEIGHT を持つ経路が複数ある場合、ＢＧＰの最良パスの順序で定義付けを行うために、AS_PATH、MONETARY_COST、PACKET_LOSS、AVERAGE_RTT、および JITTER のメトリックスを比較する。
５）上記のすべてのメトリックスが同じですべての候補経路が同じネイバーのＡＳからの場合、最低の MULTI_EXIT_DISC を持つ経路を指定する(ＢＧＰの always-compare-med が設定されていない場合に限る。この場合は、ネイバーのＡＳが同じかどうかに拘わらず比較する)。
６）その他のものがすべて等しく、ＢＧＰの最良パスの compare-routerid が設定されていない場合に限り、最初に受け取った経路を指定する。設定されている場合は、最低の BGP ルータＩＤを持つ経路を指定する。

上記で推察したように、ＢＧＰ経由で認識された経路は、特定の宛先に到達する複数の経由が存在する場合に、宛先までの最良経路を決定するために使われる関連特性を持つ。これらの特性には、経路選択過程で使用するＢＧＰ属性が含まれる。その属性例を以下に説明する。

weight はCisco 仕様の属性で、ルータに対してローカルに割り当てられる。ルータが同じ宛先への経路を１つ以上認識した場合、最も大きな weight を持つ経路が指定される。ローカル自律システム（ＡＳ）の終了ポイントを選択するには、ローカル指定属性を使用する。ＡＳに終了ポイントが複数ある場合、特定の経路の終了ポイントを選択するには、ローカル指定属性を使用する。multi-exit discriminator （ＭＥＤ）またはメトリックス属性は、メトリックスをアドバタイズするＡＳへ指定した経路に関する外部ＡＳへの提案として使用する。origin 属性は、特定の経路についてＢＧＰがどのようにして認識したかを示す。通常、origin 属性は次の３つの値の１つである。経路が発生ＡＳの内部にある。経路は Exterior BGP (ＥＢＧＰ) を経由して学習される。経路の起源は未知である、または何らかの方法で認識された。ＡＳパス属性は、経路アドバタイズがいつ自律システムを通過するか示し、ＡＳ数の順序付きリストには経路アドバタイズが横断したＡＳ数が追加される。next-hop 属性は、アドバタイズ・ルータに到達するために使用するＩＰアドレスである。ＥＢＧＰピアでは、next-hop アドレスはピア間の接続のＩＰアドレスである。ＩＢＧＰでは、ＥＢＧＰの next-hop アドレスがローカルＡＳに持ち越される。コミュニティ属性は、(受け取り、指定、再配布などの)経路決定を適用できるコミュニティと呼ばれる宛先をまとめる方法を提供する。コミュニティ属性を設定するには経路マップを使用する。その他の全メトリックスが等しい場合、コードによりアップデート過程で既存のアドバイタイズメントを指定する。これにより、一般には最初に経路をアドバタイズしたピアが指定される。ルート・サーバ１０５は上記の属性および他のパラメーターを使用して最良経路を決定する。時には一見同じ経路がピアに２回送られる。これは、ルート・サーバが、ピアには見えない隠れたメトリックスを使用するためである。その経路が最良の選択であるが、何らかの理由によりその通知のメトリックスが変更されたが、それでもそのピアの経路は最良の選択であるため、ルート・サーバが特定の通知をピアに送る場合、その経路は再度アドバタイズされる。これは、ルート・サーバがその経路を異なるメトリックスを持った新しい通知であると考えるからである。

図３のルート・サーバ３０５も、ルート・サーバ３０５の１つのインスタンスで複数のＢＧＰインスタンス(異なる自律システムを表す)を実装できる。ルート・サーバ３０５はＢＧＰの複数のインスタンスをサポートし、各インスタンスは別のＩＰアドレスおよびＢＧＰポートを聞き取ることができる。ルート・サーバ３０５は追加する新しいピアのＢＧＰネイバーおよび削除するように設定解除されたピアがあるかチェックする。これは read_reconfig() によってチェックされる最大のセットである。ルート・サーバ３０５は新しいビュー、削除されたビュー、および現在ビューが欠如しているインポートをチェックする。

ルート・サーバ３０５は複数のＢＧＰインスタンスを持つことができるため、各ＢＧＰポートにはリスナー・チャンネルが割り当てられる。ＢＧＰインスタンスが未構成であることをルート・サーバ３０５が検出すると、該当するリスナーは閉じられる。実施例では、ルート・サーバ３０５の read_reconfig() ルーチンがすべてのＢＧＰインスタンスをループしてチャンネルを割り当て、まだ１つも割り当てられていないＢＧＰインスタンスのリスナーを開く。その後、ルート・サーバ３０５のread_reconfig() ルーチンは、構成の中にＢＧＰインスタンスなしで開いたままのＢＧＰリスナーがないか探しながらチャンネルをループし、それらを閉じる。

ＢＧＰネイバー

ルート・サーバ３０５の read_reconfig() ルーチンは各ＢＧＰインスタンスおよび各インスタンス内の各ＢＧＰネイバーをループする。実施例では、ルート・サーバ３０５の read_reconfig() ルーチンは、構成済みの各ネイバーをチェックする。
ピアテーブルにまだネイバーが存在しない場合、ＢＧＰネイバーに新しいスロットが割り当てられ、そのピアは初期化される。以降のステップもすべて実行される。
ピアに BGP_FLAGS_DECONFIG が設定されている場合、そのピアはハード・リセット用にマークされ、フラグは設定されない。
ネイバーがシャットダウンとして構成されている場合、ピアもシャットダウンとしてマークされる。ピアがまだ管理シャットダウンになっていない場合、そのピアをハード・リセットとしてマークする。ネイバーがシャットダウンとして構成されていない場合はそのピアのシャットダウン・フラグをクリアし、ピアがシャットダウンの場合は BGP_STATE_IDLE に入れる。
ネイバーが passive として構成されているかチェックする。構成されている場合はピアの passive フラグを設定する。構成されていない場合はピアの passive フラグをクリアする。このフラグではピアのリセットは必要ないため、フラグの設定およびクリアは、フラグの設定およびクリアをチェックする場合と同様に簡単である。実際、ルート・サーバ３０５では、必要な場合でも両方のアクション(チェックおよび変更)を実行して変更する必要はないので、むしろ簡単である。
ネイバーが 'fake’ ('fake’ ネイバーのデバッグ) として構成されているかチェックする。構成されている場合、ピアに適切なフラグを設定する。構成されておらずピアが fake の場合、BGP_FLAGS_FAKE をクリアしてピアをハードリセットに設定する。
ネイバーにコミュニティが送られないように設定されているかチェックする。ピアが異なって設定されている場合はハード・リセットとマークする。(ソフト・リセットでは経路を再送せず、更新のスレッドに経路の再送が必要か決定させる。)
ネイバーが no transparent-as として設定されているかチェックする。ピアが異なって設定されている場合はハード・リセットとマークする(ソフト・リセットでは経路を再送しない)。
ネイバーのＡＳ番号が変更されているかチェックする。変更されている場合、ピアのＡＳ番号を変更してハード・リセットとマークする。
ビューの名前およびＢＧＰインスタンス名を構成済みのネイバーから実行中のピアにコピーする。
現在のＢＧＰインスタンスがデフォルトとマークされている場合、そのピアに BGP_FLAGS_ON_DEFAULT を設定し、それ以外の場合はクリアにする。
ネイバーの weight をチェックする。ピアのものと異なっている場合、ピアのデフォルトの weight に一致するように変更し、そのピアをソフト・リセットとマークする。
保持時間およびキープアライブ間隔をピアの構成済み保持時間およびキープアライブ間隔にコピーする(アクティブなものではない。)。
ネイバーの最大プレフィックス設定をチェックする。ピアのものと異なっている場合、ピアの設定を変更し、そのピアをソフト・リセットとマークする。
ピアがハード・リセットとマークされているが BGP_STATE_IDLE になっていない場合、ピアの bgp_change_state_external() を呼び出してその状態を BGP_STATE_CLEANUP に設定する。
それ以外にピアがソフト・リセットとマークされている場合は RCOMMAND_CLEAR_SOFT を現在のピアの経路スレッドに送る。

このループが完了したら、ルート・サーバ３０５の read_reconfig() ルーチンはピア・テーブルをループして構成で削除されたピアを探す。ルート・サーバ３０５の read_reconfig() ルーチンがそれを見つけると、ルートサーバー 305 の read_reconfig() ルーチンがピアの BGP_FLAGS_DECONFIG を設定し、bgp_change_state_external() を呼び出してその状態を BGP_STATE_CLEANUP に変更する。

図４は、ルート・サーバでスレッド化された複数のデーモンの実施例の機能ブロック図である。ルート・サーバ４０５は、複数のスレッド化されたデーモンとして設計されている。ルート・サーバ４０５は、メイン・スレッドおよび４つ以上の独立した持続性スレッドで構成され、読み取り、書き込み、ルート・テーブルの管理、ＳＮＭＰやＢＧＰの更新処理などのタスクを実行する。実施例のデーモンは、読み取りスレッド４１０、書き込みスレッド４１６、経路テーブル・スレッド４１２、およびＢＧＰの更新スレッド４１４の持続性スレッドを持っている。デーモンは、ユーザーが直接制御するのではなく、バックグランドで実行されるコンピュータのプログラムである。ルート・サーバ４０５は、ＰＯＳＩＸスレッドをサポートするＰＯＳＩＸ準拠システムで実行されるマルチスレッドのデーモンとして設計されている。ＰＯＳＩＸスレッドは共通のスタンダードを使用して、スレッドの作成および操作で使用するＡＰＩを定義する。ＰＯＳＩＸスレッド・スタンダードを実装するライブラリーは Pthreads と呼ばれることがある。Pthreads はＣプログラミング言語のタイプと手続き呼び出しのセットを定義する。

ルート・サーバ４０５の初めての起動時には、通常、デーモンがラッパー・スクリプトから実行される。ラッパー・スクリプトはデフォルトの構成でルート・サーバ４０５を起動し、更に、デーモンが突然終了した場合にデーモンの再起動などを実行して、クラッシュ時に生成されたデバッグ用のコアファイルを圧縮、コピーする。デーモンの実行中に、デーモンはＢＧＰのステートマシンをコメントのリクエスト 1771 に従って実行する。メイン・スレッドは、ルート・サーバー４０５が最初に実行された時にコマンドラインで起動したスレッドである。メイン・スレッドはその他すべての独立永続性スレッドを起動する。その他の独立永続性スレッドが起動されると、メイン・スレッドは毎秒その他のスレッドを再開させる。また、メイン・スレッドは必要に応じてログファイルをローリングし、DEBUG_STATS が設定されている場合は定期的に統計を出力する。

実行時に、デーモンは、独立永続性スレッドを使用してＢＧＰステートマシンを実装する。具体的には、読み取りスレッド４１０はピアからすべてのＴＣＰトラフィックを実行し、アップデート・スレッド４１４はアドバタイズおよび取り消し(およびキープアライブ)を実行し、書き込みスレッド４１６はピアに実際のパケットを送り、経路テーブル・スレッド４１４は、ルート・テーブルの読み取りおよび書き込みアクセスを持つ唯一の永続性スレッドとしてすべてのピア用に１つのルート・テーブル４１８の整合性を保持する。経路テーブル・スレッド４１２は、全スレッドがルート・テーブル４１８に高速でアクセスするためにルート・テーブル４１８に書き込みを実行すると同時に、他の独立永続性スレッドにルート・テーブル４１８からの読み取りを可能にするが、経路テーブル・スレッド４１２のみがルート・テーブル４１８に変更できるのでスレッドをロックする必要がない唯一の永続性スレッドである。他の独立永続性スレッドの１つがデータ反応などを待機する間、ルート・サーバ４０５はプリエンプティブにスレッドを実装し、デーモン全体がハングしたりストールしないようにする。

４つの独立永続性スレッド４１０〜４１６は、相互に通過したキューの構造を介して互いに交信する。従って、スレッド間の交信はキューおよび条件変数により実行され、その後キューはパイプラインされて拡張性を実行するフラグを使用する。スレッドはある物をキュー(読み取りキュー、ルート・コマンド・キュー、アップデート・キュー、または書き込みキュー)に配置し、受信者側のスレッドがそれを実行する。ルート・サーバ４０５はＰＯＳＩＸスレッド (pthread) ＡＰＩを使用する。(pthread_cond_t タイプの) 条件変数は、その条件を待っているスレッドに「合図する」際に使用される。ルート・サーバ４０５はこれらを使用して、スレッドの「スリープを解除する」。例えば、メイン・スレッドは毎秒他の独立永続性スレッドを再開させる。

読み取りスレッド

読み取りスレッド４１０は新しいＴＣＰ接続を承諾して、ＴＣＰ接続からのデータを受け取り、接続エラーを検出する(本文において、「接続」とはＢＧＰピアまたは管理接続を意味する)。読み取りスレッド４０１はコマンドおよび構成パーサーを実行し、チャンネル・アレイを保持する。ルート・サーバ４０５のその他の永続性スレッド同様、読み取りスレッド４１０の本体は read_thread() と呼ばれる関数に実装され、特定の操作を実行する無限ループを構成する。read_thread() は以下のステップ例を実行する。

Ａ．読み取りスレッド４１０は、読み取るデータがあるチャネルを識別する。これは、２つの fd_sets (１つは読み取り、もう１つはエラー用)を使用し、ログチャンネルではなく、アクティブでインプットを無効にしていないチャンネルをマークして実行され、(チャンネルがＢＧＰチャンネルの場合)、読み取りキューは route server_READQ_MAX 上にはない。使用可能なチャンネルの socketid は fd_sets に追加される。
Ｂ．読み取りスレッド４１０は、ノンブロッキングの select() を使用して、使用可能なチャンネルの中から読み取りデータを持っているチャネルを識別する。
Ｃ．読み取りスレッド４１０は、各チャンネルをループし、処理待ちのデータを持つチャンネルがあるかどうかをチェックし、デーモンチャンネル (CHFLAG_ADMIND、CHFLAG_BGPD) を別途実行する。
Ｄ．読み取りスレッド４１０は、管理チャンネルおよびＢＧＰチャンネルに対し、インプットを実行する。管理チャンネルに対しては基本正常性チェックを実行する。読み取りに失敗した場合、あるいはゼロを戻す場合は、チャンネルは閉じている。読み取りに失敗した場合、PACKET_LEN バイトまではチャンネルの current_read パケットに読み込む。ＢＧＰチャンネルに対しては異なる正常性チェックを行った後、パケットを current_read にも読み込む。パケットが current_read にあり、しかも有効に見えるＢＧＰパケットの場合、読み取りキューに入れられ経路テーブル・スレッド４１２で作動する。
Ｅ．最後に、読み取りスレッド４１０が再度各チャンネルをループし、終了可能なチャンネルは終了される。

書き込みスレッド

書き込みスレッド４１６は、データ・パケットをピア接続に配信する。従って、書き込みスレッド４１６は (channel_write() により) 各チャンネルのキューに配置されたデータを該当するソケットに配信する。

write_thread() のメイン・ループでは、次のステップが実行される。

１． writefds (書き込みの準備ができているファイル記述子の fd_set) をクリアし、少なくとも１つの記述子を示すフラグを準備する。
２． us の下に変更しないように、チャンネル・テーブルで読み取りロックを取得する。
３．以下を実行しながら、テーブルの各チャンネルをループする。
・チャンネルが閉じている場合、書き込みキューに残っているデータをクリーンアップする。
・チャンネルの current_write にはデータはないが書き込みキューにデータがある場合、最初のパケットのキューを解除し、current_write に配置する。
・チャンネルの current_write にデータがある場合、フラグを設定して現在のチャンネルの最初のファイル記述子を writefds に追加する。
４．チャンネルのループが完了したら、書き込みの writefdsでselect() を選択する。select() が戻ったら、再度チャンネル・テーブルをループし、socketid が writefds にある各チャンネルに write_queue() を発行する(write_queue() 関数は、チャンネルの書き込みキューにすべてのデータの書き込みを試みる。全データを書き込めない場合、データは次回の書き込みに持ち越される)。
５．チャンネル・テーブルの読み取りロックを解除する。
６．条件変数 write_cond を待つ。
書き込みスレッド 416 は、上記のステップを無限にループする。

経路テーブル・スレッド

経路テーブル・スレッド４１２はルート・サーバ４０５の主要スレッドである。経路テーブル・スレッド４１２は、経路テーブルの読み取りおよび書き込みの両方を実行できる唯一の永続性スレッドである。経路テーブル・スレッド４１２は、ＢＧＰアップデート・パケットに基づきＢＧＰを発行し、経路テーブル４１８の更新を行う。経路テーブル・スレッド４１２は、アップデート・スレッド４１４がＢＧＰアップデートを送る際に使用する経路のリストを作成する。また、経路テーブル・スレッド４１２は、取り消し通知を出した後に古い経路を削除する。経路テーブル・スレッド４１２は経路変更を受け取ると、新しい経路をテーブルにエントリとして作成し、古いエントリを削除する(オプション)フラグを付けて、キューと並べてアップデート・スレッド４１４に送る、変更リクエストを作成する。また、このスレッドは他のスレッドからピア確立およびピア・ドロップに関する通知を受け取ることができる。このスレッドは、使用可能なすべてのプレフィックスを含む変更リクエストを作成する必要がある。経路テーブル・スレッド４１２は、アップデート・スレッド４１４がこの作業を行うために必要とする全ポインタを含む１つ以上の構造を作成してアップデートする。このようにすると、アップデート・スレッド４１４は毎回経路を探す必要がなくなる。

基本的な実施例では、ファイル route.c の route_thread() 関数で実装される経路テーブル・スレッド４１２のワークフローは、以下のようになる。

１．コマンドキューにあるすべてのコマンドを処理する。
２．読み取りキューで最大１０００ＢＧＰパケットまで処理する。
３．アップデート・キューにすでに route server_UPDATEQ_MAX エントリがある場合、現在の RouteList をアップデート・キューに追加して処理し、１秒間スロットルする。
４．ＢＧＰピアのテーブルをスキャンして、各ピアに対して次のチェックを実行する。
・必要に応じてキープアライブを送る。
・保持時間をチェックして、有効期限が切れている場合通知を送る。
・ネゴシエーション中にピアのタイムアウトをチェックする。
・ BGP_STATE_IDLE でピアへの接続を開始する。
・ BGP_STATE_CLEANUP でピアのシャットダウンを終了させる。
５．前回実行時から route server_GARBAGE_COLLECTION_TIME 秒以上経過している場合、ガーベジコレクタを実行する。
６．前回実行時から route server_DAMPENING_TIMER 秒以上経過している場合、route_dampening() を実行する。
７．ピアの最大プレフィックス設定をチェックする。

以下の説明では、これらの各操作を具体的に順番に説明する。

１．処理コマンド

経路テーブル・スレッド４１２で処理されるコマンドは、他のスレッドからroute_command キューを経由して送られる。他のスレッドがコマンドにより経路テーブル・スレッド４１２に情報を送り、経路テーブル・スレッド４１２が実際の作業を行うことができるように、時には、ルート・テーブルに書き込むものや経路テーブル・スレッド４１２の制御下で行うべきものを要求するスレッドもある。送信できるコマンドはすべて RCOMMAND のプレフィックスを持ち、ルート・テーブルで定義される。

#define RCOMMAND_SHOW_IP_ROUTE 3
#define RCOMMAND_SHOW_IP_ROUTE_SUMMARY 4
#define RCOMMAND_SHOW_IP_BGP_NEIGHBORS 5
#define RCOMMAND_CHANGE_STATE 6
#define RCOMMAND_FORCE_GC 7
#define RCOMMAND_SET_RTT 8
#define RCOMMAND_SET_JITTER 9
#define RCOMMAND_SET_COST 10
#define RCOMMAND_SET_LOSS 11
#define RCOMMAND_CLEAR_SOFT 12
#define RCOMMAND_CLEAR_DAMP 13

これらの各コマンドは、１つ以上の関数を呼び出して経路テーブル・スレッド４１２のプログラム中で実行させる。コマンドは関数によって次のように分類される。
RCOMMAND_SHOW_* コマンドは出力を管理ログインへ送る。経路テーブル・スレッド４１２に読み取り専用のポインタをルート・テーブルに生成する。
・ RCOMMAND_CHANGE_STATE は特定のピアの BGP 状態を変更する。
・ route server_GARBAGE_COLLECTION_TIME 秒経過していない場合でも、RCOMMAND_FORCE_GC は経路テーブル・スレッド４１２に対し、ガーベジ・コレクションを実行する。これを使用し、再構成で発生した変更を実行する。
・ RCOMMAND_SET_* コマンドは、パラメーターを特定の経路に設定する。
・ RCOMMAND_CLEAR_SOFT は、特定のピアのルートテーブルを再スキャンする。
・ RCOMMAND_CLEAR_DAMP は、特定のビューまたは経路の BGP ダンピング情報をクリアする。
経路テーブル・スレッド４１２は、ループを反復するたびにコマンドを１つのみ処理する。他のスレッドからのコマンドは、ＢＧＰパケットほど頻繁ではないものとする。

２．ＢＧＰパケットの処理

経路テーブル・スレッド４１２が処理待ちのコマンドのチェックを完了すると、経路テーブル・スレッド４１２は読み取りキューから送られて未処理のＢＧＰパケットを処理する。経路テーブル・スレッド４１２がピア・テーブル(キープアライブ用など)を確実に実行できるサイクルを持つためには、一度に処理するパケット数を route server_READQ_PROCESSに限定する。本申請書執筆時点では１０００に設定されている。(読み取りスレッド４１０はパケットを読み取りキューに並べ、route server_READQ_MAX パケットがある場合はスロットルする。デフォルトでは２０００に設定される。) .route_thread() 内のコードは単に route server_READQ_PROCESS 回までループして読み取りキューからパケットを取得し、それに続く各パケットの bgp_process_packet() を呼び出し、read_recycle_packet() を呼び出してそのパケットをリサイクルする。パケット作業の大半は、ファイル bgp.c で定義される bgp_process_packet() 関数で実行される。
bgp_process_packet() は比較的簡単な関数である。パケットの “type” フィールド(例えば、RFC 1771 に従うと１９番目のバイト)をチェックしてからパケットを処理する。

RFC1771 で定義される４種類のコードは次の通りである。

１． BGP_PACKET_OPEN ? パケット上に bgp_process_open() を呼び出す。
２． BGP_PACKET_UPDATE ? アップデートを受け取ったピアが確定しているかチェックする。確定していない場合はアップデートを静かにドロップする。確定している場合はパケットを bgp_process_update() に渡す。
３． BGP_PACKET_NOTIFICATION ? このピアから通知を受け取った場合、送られたメッセージをログしてピア側の通知番号を増加し、channel_close_start() を呼び出して、ピアが存在しているチャンネルの閉鎖過程を開始する。
４． BGP_PACKET_KEEPALIVE ? ピアが存在する場合、ピア側のキープアライブ番号を増加してから、ピアがどの状態にあるかによってパケットを処理する。ピアが存在しない (別のスレッドによりチャンネルが閉じられている) 場合はパケットを無視する。

３．現在の RouteList をアップデートキューに送る

実施例では、ルート・サーバはグローバル変数 route_rl により一度に１つの RouteList のみを生成する。コンパイル中の RouteList は、主にここでアップデート・キューに追加される(他のものは下記のガーベジコレクション中または route_rescan() の処理中)ので、アップデート・キューの長さが route server_UPDATEQ_MAX より長いかどうかチェックする(デフォルトは５００)。長い場合、デフォルトの９９９９９９で、route server_UPDATEQ_THROTTLE マイクロ秒間または１秒未満、経路テーブル・スレッド４１２をスロットルする。コードに注記するように、経路テーブル・スレッド４１２のスロットルは危険であるが、実行する必要がある。将来問題が発生した場合は、スロットル時間を短縮するか、アップデートキューの最大長を大きくする。

４．ピア・テーブルのスキャン

route_thread() の重要な機能の一つは、ピアのテーブルをスキャンし、更新する必要があるもすべての項目を更新することである。これにより正常なBGP状態を保持するために必要な項目を、ピアに対し定期的にチェックし確認する。ループ自体はシンプルなもの (;;)で、ピア全体のテーブルに対し、以下の条件で各ピアをチェックする。

１．ピアが確立され、かつ保持タイムが > 0 で設定されている場合、キープアライブを送信するタイミングをチェックする。また、ピアの保持タイムが規定時間を越えていないかチェックする。タイムがキープアライブになっている場合、現在のピアに対してbgp_send_keepalive() をコールする。もしピアの保持時間が超過した場合、現在のピアに対して bgp_send_notification() を BGP_ERR_HOLDTIMER の値でコールする。
２．次に、ピアが BGP オープンネゴシエーションの間にタイムアウトしたかどうかチェックする。タイムアウトの場合、現在のピアに対しBGP_ERR_HOLDTIMER の値でbgp_send_notification() をコールする。
３．ピアが BGP_IDLE の状態で、「passive」として設定されていない場合、かつroute server_BGP_CONNECT_WAIT 秒数がピアの最後のデータから過ぎている場合は、bgp_intiate_open() をコールしピアへの接続を試みる。
４．ピアが「fake」として構成されている場合、デバッグし、かつ現在BGP_IDLE の状態の場合、ピアを特定する。
５．ピアが BGP_STATE_CLEANUP の状態の場合、route_peer_shutdown() を現在のピアに対しコールし、last_send 値を現行時間に設定する。ピアがチャンネルと関連している場合は、channel_close_start() をコールする。

５．ガーベジコレクション

ガーベジ・コレクションは、使用されていないデータ構造をクリーンアップし、使用されなくなったリソースを解放するプロセスである。このプロセスはまた、更新に伴う必要な変更を実施したり、停止したスレッドを表示するために使用される。ガーベジ・コレクションは定期的に実行される必要があるが、実行間隔はクリティカルなものではない。「数分間隔」で十分である。ガーベジ・コレクションの実行頻度は、コンパイル時定数であるroute server__GARBAGE_COLLECTION_TIME により制御される。デフォルトは毎３００秒である。ガーベジ・コレクションは、不使用のピア、ビュー、およびパス属性などの削除を伴うため、その最中に他のスレッドが重要なデータ構造を読みこまないようにすることが大切である。command_freeze lock は、これらの構造を読み込む特定のコマンドが進行されるのを許可するかどうかを制御する。ガーベジ・コレクションを実行する前に、経路テーブル・スレッド４１２は command_freeze に排他的な (読み込み／書き込み) ロックをかけようとする。ロックが成功した場合、route_garbage_collect() をコールし、ガーベジ・コレクションを実行する。ロックが失敗した場合、ガーベジ・コレクションをroute server_GC_POSTPONE 秒 (デフォルトは１０秒)先に延期する。ガーベジ・コレクションは時間的にクリティカルではないのて、待機して問題はない。

route_garbage_collect() が実行されると、最初にＢＧＰピア・テーブルをロックし、次にピアの中をループする。ガーベジ・コレクションの対象となるピアが見つかった場合、そのピアが保持していたビューに対する参照カウントはデクリメントされ、ピアのＢＧＰパス属性は解放され、ピア構造はクリアにされる。ピアが参照カウント０のＢＧＰパス属性を持っていた場合、そのパス属性は解放される。最後に、そのピアが新しいビューを持っていた場合、そのビューはインストールされ、古いビューに対する参照カウントはデクリメントされる。ピア・ループが完了後、参照カウント０を持つすべてのビューが解放される。その後、ＢＧＰピア・テーブルはロック解除され、route_garbage_collect() が回復する。

６．ＢＧＰルート・ラップ・ダンピング

ＢＧＰルート・フラップ・ダンピングは、RFC2439に記述のとおり、グローバル・インターネット環境でのルーティングの不安定性を減少するための、重要な手段となりうる。ダンピング・タイマー (route server_DAMPENING_TIMER ：デフォルトは３０) が有効時間を過ぎた場合、route_dampening() 関数がコールされる。route_dampening() は最初に、ＢＧＰピア・テーブルをロックし、ルート・テーブルのスキャンをし、各経由に関連するすべての BGPannc 構造を参照してアナウンスメントに関連したペナルティがあるかどうかをチェックする。該当するhalf-life-timeが経過している場合、ペナルティの値は軽減される。もし、ペナルティがreuse thresholdを下回っており、かつアナウンスメントが前回ダンプされている場合、アナウンスメントのダンプを取り下げる。ルート・テーブル４１８のスキャンが完了後、該当するピアのダンピングタイマーをリセットする。

route_thread() ループの完了

route_thread() のループの最後尾に到達した場合、読み取りキューの中にパケットがないかどうか、また、コマンド・キューの中にコマンドがないかどうかチェックする。ない場合、スレッドは route_cond 条件変数の順番を待つ。この変数は、ルート・テーブル・スレッド４１２に対して、実行すべき作業があることを示すために、他のスレッドにより使用される。いずれかのキューが空でない場合、スレッドはただちにループバックする。

スレッドの更新

ＢＧＰアップデート・スレッド４１４は、それぞれのＢＧＰピアに対して、アドバタイズあるいは引き下げを行う必要のあるプレフィクス(すなわち、ルート)の決定を担当する。アップデート・スレッド４１４は、ルート・テーブル・スレッドからアップデート構造を受け取り、次に、それぞれ確立したＢＧＰピアに対する決定を行う。アップデート・スレッド４１４は各ピア・ビューのコピーを保持し、ビューの実際の変更に対してのみルーティング・アップデートを発行する。

実施例では、update_thread() の機能自体は非常にシンプルなものである。ループ内で、アップデート・スレッド４１４はルート・リストをアップデート・キューから取り除き、アップデート・スレッド４１４、update_process_peer()の下で作動する一次機能へ送信する。ルート・リストは、特定のピアあるいはすべてのピアを対象にするのかに応じて、若干違った取り扱いをされる。すべてのピアを対象とする場合、ルート・リストはテーブル中に確立したそれぞれのＢＧＰピアに対し、update_process_peer() へ送られる。

update_process_peer() 関数は、ルート・サーバ４０５の大関数の１つである。パフォーマンス上の理由により、bgp.c の関数に依存せずに独自のＧＰパケットを生成する。

update_process_peer() に送信されるルートリストには、該当するプレフィクスならびに関連する BGPattrsを示す、RLIST_ROUTE と RLIST_ATTR のみがエントリされているべきである。update_process_peer() は特定の BGP に対してコールされるので、その中で特定のピアに対し、更新または取り下げを実行するか否かを決定する。ルート・リストのそれぞれのプレフィクスに対し、この関数は最良の属性を選択する。選択された属性がなく、ピアに前回送信されていた場合、そのルートは取り下げられる。選択された属性が、前回そのピアに対しアナウンスされたものと同一のものである場合、何も実行されない。属性が選択されると(あるいは選択されないと)同時に、ＢＧＰパケットが生成される。可能な限り、複数の更新と取り下げは単一のパケットに統合される。このため、コードを読み込む際には注意が必要である。パケットが一杯の場合(あるいは、さまざまな属性を持つ更新パケットを生成する必要がある場合)、そのパケットは適切なチャンネルの書き込みキューに配置され、新しいパケットが開始される。

ルート・テーブル・プリント・スレッド

ルート・テーブル・プリント・スレッドは、上記のダイアグラムにある「コマンド・スレッド」のインスタンスである。ルート・サーバ４０５のその他のスレッドと違い、コマンド・スレッドは短命である。必要な場合に生成され、タスクを実行し、終了される。ルート・テーブル・プリント・スレッドは一つの機能として、大量の情報をユーザに非同期的に送信する。このタスクのために作成されたスレッドがコマンド・アウトプットを抑制して、無制限の書き込みキューがチャネルに発生することを回避する。

コンフィギュレーション／コマンド・スレッド

大量の出力を発生させるコマンドのために、新しいスレッドが作成されることがある(例:show ip bgp)。生産されたスレッドは、過多の出力をバッファしないようにする (フロー制御)。

実施例では、シンプル・ネットワーク管理プロトコル(ＳＮＭＰ)の問題のハンドリング用にコード化された永続的スレッドが、デーモンの一部を形成する。ＳＮＭＰはネットワーク管理システムに使用され、管理作業の条件に合わせてネットワークに接続するデバイスのモニタリングを行う。ＳＮＭＰはネットワーク管理のため標準規格のセットで構成され、その中にはアプリケーション層プロトコル、データベース・スキーマ、およびデータ・オブジェクトの1セットが含まれる。ＳＮＭＰは、管理システム上に変数の形式でデータを表示し、またそれはシステムのコンフィギュレーションを示す。

ロック

ルート・サーバ４０５上では、クリティカルなデータ構造はpthread ロッキング・プリミティブによって保護される。基本的なロック・タイプは pthread_mutex_t と pthread_rwlock_t である。mutex (相互排他ロック)とrwlock (読み込み/書き込みロック)の主な違いは、mutex では一度に１つのスレッドしかホールドできないが、rwlock では複数のスレッドが同時に読み込みロックをホールドできる。しかし、書き込みロックは１つのスレッドしかホールドできない。(読み込みあるいは書き込みロックが他のスレッドにより保持されていない場合に限り、一つの書き込みロックをホールドできる)。この例として、所定のリソースに多くの読み手がいるが、書き手は１人しかいない。読み込み／書き込みロックは、ルート・サーバ４０５がＢＧＰピア・テーブル、チャンネル・テーブルならびにガーベジ・コレクションを保護するため非常に有効な手立てとなる。キューを保護するためには、相互排他ロックを使用する。ルート・テーブル４１８自体はロックで保護されていないこと、ルート・サーバ４０５は、ルート・テーブル・スレッド４１２のみがルート・テーブル４１８に書き込みをするように、ルート・テーブル４１８の読み込みを安全に確保する仕様で設計されていることに注意すること(理由の一つとしては、経路が割り当て解除されることはないため、これに変更するには、パフォーマンスペナルティによりロッキングを付加する必要がある場合がある)。さらに重要なことには、アナウンスメントはガーベジコレクションまで割り当て解除されない。つまり、アップデート・スレッド４１４は、たとえアナウンスメントが廃棄される過程にあっても、その読み込みを続けることができるのである。

ルート・テーブル

図５はルート実行のダイアグラムを図で示したものである。ルート・サーバは、複数の内部的データ構造を持つことができる。プライマリデータ構造は、ルート・テーブル５１８であり、これはリンク・リストとＢツリーのハイブリッド・コンビネーションである。ルート・テーブル５１８のコンフィギュレーションは、６ルーツなど、上限つき最大深度を持っている。これにより非再帰的な検索やパフォーマンスを最大化するための挿入が可能になる。実質的に、ルート・サーバにより行われるデータ処理のほとんどが、ルート・テーブル５１８へ向け読み取り専用ポインタを送ることとなる。これにより、単一の永続的スレッドであるルート・テーブル５１８のスレッドのみが、テーブルに対するすべての書き込みを行うと同時に、他のスレッドによるルート・テーブル５１８からの読み込みを可能とする。ルート・テーブル５１８は、複数のスレッドがルート・テーブル５１８に格納された情報を読み込むことを可能にする一方、ルート・テーブル５１８への書き込みはルート・スレッドのみに許可する。

ルート・テーブル５１８の構造では、ツリーの各ルートが特定のネットマスク長を扱う。ルートは最初、特定のプレフィクス長によってルート・テーブル５１８に配置され、経路データのためにスキャンされるルートが１つ選ばれる。ルート・テーブル５１８の構造はまた、ルーティング・テーブルで可能なすべてのプレフィクスのためのメモリ・スペースが、あらかじめ割り当てられる。従って、ルート・テーブル５１８は、各ルート用のネットマスク長により予めバランスがとれた構成となっている。そして、ネットマスク長のルート内にあるすべての可能なプレフィクスに関するフィールド・エントリにより、ルート・テーブル５１８はランタイム中に再度バランスが取られる必要はないのである。さらに、すべてのアナウンスされた経路は、永久にルート・テーブル５１８のあらかじめ割り当てられたメモリ・スペースに保持される。これにより、新しいＢＧＰセッションが確立された場合でも、ルート・テーブル５１８の既存のルートを付加したり削除する必要がなくなり、ポインタを更新するだけで、該当するプレフィクスと関連する属性を変更することができる。したがって、一度ルート・テーブル５１８に入力されたルートは、アナウンスされなくなってもルート・テーブル５１８から削除されない。ルート・サーバは、新しいＢＧＰセッションが確立されるたびにすべてのルートを再認識する必要はない。ほとんどの場合、いくつかのポインタを更新するだけでよいのである。

ルートが受け取られると、通常、ルート・サーバがプレフィクスを調べるのは一度だけである。このことより、ルート・テーブル５１８の構造は、Ｂ−ツリーとリンク・リストとのハイブリッド・クロスになっている。初めに、ルート・テーブル５１８のＢ−ツリーの部分が、ツリーの特定のルートを決定するためにルート・アドレスの初期ビットを検証する。正確なルートが割り出されると、分類されたルートのリンク・リストが検証される。

Ｂ−ツリーの部分はデータを保存するためにツリー・データ構造を使用する。これにより対数償却時間でデータの挿入と削除が可能になる。Ｂ−ツリーでは、ルーツは事前に定義された特定範囲のネットマスク長を持つことができる。

ルート・テーブル５１８ルックアップは、ルート・サーバで最もよく実行される単一のアクションであり、ルート・テーブル５１８ルックアップを最適化する。ツリーの各ルートは、特定のネットマスク長を持つルートを扱う。すなわち、１番目のルートが /0 から /4 のマスクを扱い、２番目のルートが /5 から /8、３番目のルートが /9 から /12、４番目のルートが /13 から /16、５番目のルートが /17 から /20、６番目のルートが /21 以上のマスクを扱う。決定は、「６番目のルートにある /24 より長いすべてのプレフィクスを含む」、というものだった。なぜなら、運用上は、そのような長さのルートが公共のインターネットに存在することは極めて希だからである。ルート・サーバが今までより長いプレフィクスルートが一般的であるような環境に配置された場合、この構造を調整できる。通常の 4-ビットが示唆しているように、「１番目のルートのノードは /0 から /3 ではなく、/0 から /4 を扱う」、ことに注意する。これは、「/0」が実際にはデフォルトのルートの省略表現に過ぎないためである。これは１番目のルートに可能な経路の数を16〜17まで増加させる。

正しいルートが割り出されると、ソートされたルートのリンク・リストができる。ルート・テーブル５１８の構造の各ノードは、ルートのリンク・リストを含んでいる。リンク・リストの部分は、ノードのシーケンスから成るデータ構造を用いる。各ノードは任意のデータ・フィールドを持ち、１つもしくは２つのリファレンス(リンク)が次のノード、または前のノードをポイントする。通常の配列に対するリンク・リストの主な長所は、「リンクされたアイテムの順番が、メモリまたはディスク上に保存されたデータ・アイテムの順番と異なっていても構わない」、ということである。これにより、アイテムのリストはさまざまな順番で並べ替えることが可能になる。リンク・リストは自己参照的なデータ・タイプである。なぜなら、これは同じタイプの別のデータへのポインタまたはリンクを含んでいるからである。一般にリンク・リストは、リスト上のどこでも、常にノードの挿入と排除を可能にする。

その結果、192.168.25.0/24 など、各特定のプレフィクス(経路)は、プレフィックスを生成または受け取るピアの数に拘わらず、テーブル中で一つの構造ルートとのみ関連付けされる。このようにルート・テーブル５１８のツリーを参照すると、作業時間の短縮につながる。なぜなら、ルート・テーブル５１８のすべてのエントリをスキャンする必要がないからである。チェックされたプレフィクスのネットマスク長範囲に該当する、rootだけが割り出される。ルート・テーブル５１８のこの構造により、ルート情報を検索する必要があるたびに、ルート・テーブル５１８のフル・スキャンをする必要はなくなる。

実施例では、各ノードはツリーの次のroot 用に 16 のエントリを持つ。１６．の比較を避けるため、かつツリーのバランスを取るために、これらの１６．のエントリはネットワーク・アドレスの４つのビットを表わす。各root は、それぞれ4-ビットのネットマスクを持った経路を含む。従って、最初のノードは、/4 以下(インターネット上では存在しない)のすべての経路を含む。このノードは次のレイヤ(/5、/6、/7 および /8 のネットマスクを持つ)に対して１６のポインタを持つ。これはシフトと「AND」操作によって実行され、次のノードにインデックスを生成する。この時点では、ネットマスクのみを比較する必要がある(もう１つのANDの操作)。

通常、リンク・リストは小さいものになる(１〜６のエントリ)。ツリーの最大深度は６(/21 〜 /24)である。なぜなら、関数コールのための帰納がパフォーマンスを低下させる可能性があるからである。/24よりも大きいすべての経路がこの深度に含まれる。なぜなら、それらは非存在であるべきで、リンク・リスト長への付加はあまりないからである。最大深度により、ルート・サーバは非ロール検索対再帰的プロシージャ・コールを実行することができる。

従って、構造ツリー・ノードのポインタの配置は、それぞれネットワーク番号の4-ビットを表わすノードを向く。例となるプレフィクスは、192.100.81.0/24 のベース-10 アドレスを持っているが、11000000.11000100.10100001.00000000 のアドレスに変換され、ルート・テーブル５１８で検証することができる。検索／挿入アルゴリズムはtree_find()関数で次のように機能する。検索または挿入された経路のマスクが１番目のroot に一致した場合、その経路は現在のrootにおいて、分類された経路のリンク・リストの中にある(必要がある)。ない場合、ネットワーク・アドレスの最初の４つのビットを取り、これらのビットに対応する次のポインタをチェックすること。そのポインタを次のrootノードまでたどる(存在しない場合は作成する)。マスクが現在のrootに一致した場合、その経路はノードのリンク・リストの中にある。ない場合、ネットワーク・アドレスの２番目の４つのビットを取る。そして、対応する次のポインタを追っていく。これを繰り返し、現在のプレフィクスのマスク長に該当するroot にたどり着くまで続けるのである。

ツリーの各ノードは、以下の構造を使用することで実装することができる。

struct treenode {
struct treenode *next [16];
struct route *route; /* sorted linked list of routes */
};
;

実施例では、非ロール検索の速度を向上させるため、最大で１６の固定経路しか持つことができない。実施例では、リンクリストを使う代わりに、ルート・サーバは１６個の配列ポインタを使用する。この配列はより多くのメモリを占有するが、リンク・リストのスキャンをすべて行う必要は生じなくなる。そのため、この配列の最大深度は８になる。

テーブルに存在するプレフィクスがルート・サーバに入った場合、新しく割り当てられる経路構造はない。新しいＢＧＰ属性は、プレフィクスのＢＧＰ属性(ＡＳパスなど)がピアによってアナウンスされた他のプレフィクスと同じでない場合のみ割り当てられる。したがって、新しいプレフィクスが受け取られた時に、経路構造が割り当てられる。１つのプレフィクスに１つの経路構造のみとなる。実行された割り当てが解除されることはない。実施例では、ルート・サーバはガーベジ・コレクションのプロセスの時に、経路構造の割り当て不可を付加する場合がある。しかし、通常は、経路構造は割り当て不可にならない。プレフィクスが取り下げられた場合でも、そのプレフィクスの再アナウンスが比較的早くされる可能性が高いからである。

したがって、プレフィクスがメモリにいったん割り当てると、それが解放されることはない。これにより、ルート・サーバが非常に速く効率的になる。メモリ内の経路オブジェクトを決して解放しないため、ルート・サーバは高価なブロッキング・フリー()・カーネル・コールを回避することができ、かつ経路取り下げ操作(ＢＧＰセッションの再設定に不可欠)がブロッキング状態なしで実行されることを可能にする。また、経路オブジェクトを解放しないことにより、新しい経路がアナウンスされた際でも、ルート・サーバはそれをメモリに書き込む必要はない。ルート・サーバは、新しいポインタをメモリに存在する経路に更新するだけでいいのである。これは高価なメモリ書き込みサイクルを節約する。経路の取り下げと新しい経路の認識は、ルートフラップの中では非常に類似した機能になるので、ルート・サーバはシステムを最適化し、他の実装において高価なＢＧＰ計算を引き起こす、ネットワーク上の一時的障害による影響に備えることができる。
struct route {
struct route *next;
uint32_t network, netlen, netmask;
BGPattr const *peerview [the route server_MAX_BGPPEERS];
uint32_t annc_num, annc_max;
BGPannc *announcements;
};

ピアビュー配列はピアにアナウンスされている現在の属性に対するポインタに相当するものである。config.h 変数をroute server_MAX_BGPPEERS に対して調整することで、メモリ消費に対する大きな効果を実現することができる。アクティブなピアの数が変更されるたびに、malloc() または realloc() をコールすることを避ける目的で、これは静的配列として実装された。すべてのピアがピアビューの決定を必要とするため、動的なものではない。一方、アナウンスメントは動的に割り当てられる。個々のプレフィクスがそれほど多くのピアによってアナウンスされることはないからである。入ってくるアナウンスメントは以下の構造で格納される。

typedef struct BGPannc_t {
BGPattr *attr;
uint16_t peerid;
uint16_t penalty; /* dampening penalty */
} BGPannc;

BGPannc 構造については、ダンプペナルティが割り当てられている場合には、取り下げ後も保持されることに注意すること。ゼロになるまで、ペナルティは保持されなければならない。これらの構造は定期的なガーベジ・コレクションの間に、時折クリーンアップされる。

ルートテーブルのスキャン

ルート・テーブル５１８はツリーであるが、非再帰的なアルゴリズムを使用することでそれをスキャンできる。ルート・テーブル５１８には６つのルーツなど、既知の最大深度があるからである。他のスレッドへの送信に伴いルート・リストを作成するために、ルート・テーブル５１８をスキャンする必要がある場合は、非再帰的なアルゴリズムを使用する。そのツリーが、既知の最大深度を持っているからである。非再帰的なスキャンは再帰アルゴリズムによって必要とされる付加的な関数呼出しオーバヘッドを排除する。スキャン・アルゴリズムは#定義のマクロを使って実行される。そのため、速度が必要とされるすべての場所においてスキャンを含めることができる。ルート・テーブル５１８を使用する必要がある機能は、さまざまなTREEWALKマクロを使う。TREEWALK_LOCALS は、関数が必要とするローカルの変数を定義する。TREEWALKは通っていくための構造経路*、TREEWALK_LOOP_START はループを設定し、そして TREEWALK_LOOP_END がそれを終了させる。ツリーを通るインライン・コードの最低限の関数は以下のように設定される。

void proc (...) {
TREEWALK_LOCALS;

TREEWALK_LOOP_START {
printf (“route is %08x\n”, TREEWALK->network);
} TREEWALK_LOOP_END
};

基本的に、TREEWALK_LOCALS はツリーをスキャンするのに必要な変数を定義する。TREEWALK_LOOP_START と TREEWALK_LOOPEND がそのアルゴリズムの主要部分である。どのコードもループの途中で入れることができる。そして、TREEWALK が構造ルートのエントリに向けられる。

ルート・テーブル管理

ルート・テーブル５１８は絶えず更新され、ルート・サーバは定期的に更新されたルート・テーブル５１８をすべてのスレッドと共有する。情報が共有される必要があるときは、ルート・スレッド以外のスレッドは、ルート・テーブル５１８から読み込みを行うことができる。これは、ルート・スレッドから伝達されたルート・リストを通して行う。ルートとそのアナウンスメントは、ルート・リストの中に置かれて、その他の永続的なスレッドの１つに伝達される。次に、その他の永続的なスレッドはルート・リストの中に置かれたポインタはすべて、ポインタがまだ存在していることが分かっている場合、読むことができる。伝達されたルート・リストにより、他のスレッドがルート・テーブル５１８自体をスキャンする必要がなくなる。これは変化する可能性があり、スレッドを割り当てのないスペースに送ることができる。

一方、ルートスレッドは、使われなくなった構造をクリーンアップために、他のスレッドがテーブルを読み込みするのを止めるまで待たなければならないことがある。他のスレッドがビジーになっている場合、ルート・スレッドはガーベジ・コレクションを延期して、再度試みる。

#define ROUTE_LIST_MAX 13100
typedef struct route_list {
int peerid; /* specific peer, or -1 = all peers */
int num; /* number of entries in this table */
uint8_t type [ROUTE_LIST_MAX];
void *ptr [ROUTE_LIST_MAX];
} RouteList;

ルート・スレッドは必要な数のルート・リストをすべて作成し、そのデータを必要とするスレッドに伝達する。通常これはアップデート・スレッドであるが、「show ip bgp」のようなコマンドは印刷するためのルートのリストを必要とする場合がある。アップデート・スレッドに対し、更新をどのピアに適用するのかを通知するのは、peerid である。-1 は、すべてのピアがスキャンされなければならないことを示す。特定のピアが使われるのは、通常、ピアが設定されてルートを送る必要がある場合である。あるいは、ピアのアクセス・リストが変更された時である。

構造経路

ルート・サーバが操作する主たるアイテムは経路である。ルート・テーブル５１８構造の各ノードはルートのリンク・リストを含んでいる。これが構造経路のタイプである。

struct route {
struct route *next;
uint32_t network, netlen, netmask;
BGPattr const *peerview [the route server_MAX_BGPPEERS];
uint32_t annc_num, annc_max;
BGPannc *announcements;
};

この構造は、ルート・サーバの重要なコンセプトを示すことに役立つ。192.168.25.0/24 など、それぞれの特定のプレフィクス(または経路)は、それに関連してテーブルで１つの構造経路しかもたない。これは、どれだけ多くのピアがプレフィクスを生み出していても、または受け取っていても変わらない。補助的詳細事項、すなわち、経路はそのピアから情報を受け取っているのか、経路はどのピアにアナウンスされるべきなのか、アナウンスメントと関連しているBGP パス属性は、構造ルートの別のフィールドにより示される。

Uint32_t ネットワーク、netlen、ネットマスク

３つの32ビット数量が、ネットワークアドレスなど、対象となるプレフィクスに関する基礎的情報を提供する。この場合、実施例のネットワークは、「192.168.25.0」であるため、ネットワーク・フィールドは32ビットの同等物、0xc0a81900 を含むこととなる。netlen とネットマスクのフィールドは同じ情報を異なったフォーマットで含まれている。すなわち、対象となるネットワークのマスクで、いくつのビット数が関連しているかを告げるものである。この場合、netlenは24(/24 以上)で、0xffffff00のネットマスクに対応する。この情報がなぜ２個の異なった形式で格納される必要があるかというと、それを絶えず前後に変換しなければならないからである。すなわち、入力の時点で変換が実行されると、それ以後は、追加変換なしで必要なバージョンが使用できる。ルート・サーバの実行では、32-ビットより小さいタイプのものでなく(8-ビットあるいは 16-ビットタイプでなく)、32-ビットと同等物が使われる。ルート・サーバは32ビット・データのロードを行うプロセッサ・モデルのために最適化されるからである。ルート・サーバの実施例では、予期されるトラフィックに対して最適化されず、そのために構造経路の途中でより小さいフィールドを持つことがある。これにより他のフィールドがもはや32-ビット制限に対して調整されなくなる。これは、ほとんどの32ビット・プロセッサにおいてパフォーマンスを顕著に低下させる原因となる。従って、ルート・サーバの実施例、予期されるトラフィックに対して最適化されるべきである。

BGPattr const *ピアビュー [route server_MAX_BGPPEERS];

各ピアは、所定のプレフィクスをさまざまな BGP 属性を持つルート・サーバにアナウンスできる。peerviewは当社が各ピアに送った現在の属性のポインタである。BGPattr構造に対するピアごとのポインタで、BGPattr 構造は下記のようになる。

typedef struct BGPattr_t {
uint32_t refcount;
the route server_CLASS_TYPE class;
uint32_t peerid;
uint32_t next_hop;
uint32_t med;
uint32_t cost;
uint16_t loss, rtt;
uint16_t jitter, weight;
uint32_t attr_len;
uint16_t as_ptr, as_segments, as_len, community_ptr, community_num;
uint8_t origin;
uint8_t not_missing; /* flags */
u_char packet [4]; /* note: open ended array, using malloc */
} BGPattr;

BGPattr 構造は、ＢＧＰアップデート・メッセージからのパス属性情報を得るように設計されている。この時のフォーマットはルート・サーバ内で関連情報を比較するのに使用しやすいものであるばかりでなく、ルート・サーバによって始めに受け取られた形式でそれらの属性を保存できる。

Uint32_t annc_num、annc_max;

annc_num は下記のアナウンスメント・フィールドにおける BGPannc 構造の数である。annc_max はアナウンスメントに現在割り当てられたスペースに適合するBGPannc 構造の最大数である。

BGPannc *アナウンスメント

アナウンスメント・フィールドはBGPannc構造のブロックに対するポインタで、malloc() を使って動的に割り当てられたものである。より多くのスペースがアナウンスメントに必要で、malloc()の実行数を制限するためには、ルート・サーバ_MALLOC_ANNC (デフォルトは 4)が一度に割り当てられる。より多くのスペースが必要な場合、ストレージの容量を増加させるため realloc()がコールされる。現在、ルート・サーバがBGPannc構造に割り当てられたメモリを再要求することはない。過度のメモリ・コピーが引き起こすパフォーマンスへの影響のためである。また、プレフィクスのアナウンスメントの最大数が同じままである傾向がある、もしくは時の経過と共に増加することはあっても、減少する傾向はないと想定されるからである。将来的にアナウンスメントのためのガーベジ・コレクションプロセスでは、パフォーマンスへのインパクトの可能性について慎重に考慮する必要がある。

BGPannc 構造は下記のようになる。

typedef struct BGPannc_t {
BGPattr *attr;
uint16_t peerid;
uint16_t penalty; /* dampening penalty */
} BGPannc;

基本的に、ＢＧＰピアとダンピング・ペナルティはBGPattrと関連している。これにより、ルートのインスタンスに関して詳細なトラッキングができる。すなわち、ルート・サーバがどのピアからアナウンスメントを受け取ったのか、インスタンスの持つ属性、などの詳細である。

ルートリスト

ルート・スレッド以外のスレッドは、ルート・スレッドから伝達されたルート・リストを経由してテーブルから読み込みされる。書き込みを単一のスレッドに制限することは、読み込み・ロックを経由してテーブル管理を非常に簡単なものにする。複数のスレッドをテーブルから同時に読み込みできる。書き込みロックはルート・スレッドしか実行できないため、同期的な問題はほとんどない。

ルート・リストの構造として、読み込み専用のポインタはルート・テーブル５１８に保持される。ルート・スレッドが、ルート(およびビュー)に関する情報を、その上方を必要とする他のスレッドに伝達する。ルート・リストの基本構造は配列(ペイロード・メンバー)のそれと同じである。

typedef struct route_list {
int peerid; /* specific peer, or -1 = all peers */
int num; /* number of entries in this table */
uint8_t type [ROUTE_LIST_MAX];
union {
void *ptr;
BGPattr *attr;
struct {
uint16_t peerid;
uint16_t penalty;
} peer;
} payload [ROUTE_LIST_MAX];
} RouteList;

実施例では、この配列は常に同じサイズになる。

ROUTE_LIST_MAX

ROUTE_LIST_MAX のデフォルト値は１３１０００である。32-ビット・ポインタが使用される場合、ルート・リストが６５５３６バイト（６４ｋ）内に適合するからである。メモリをそれほど頻繁に割り当てない場合には、十分な容量となる。また、ルート・リストに１つか２つのエントリしかない場合には、容量が小さくなるため多くのスペースを浪費しなくてすむ。配列は常に同じサイズである。所定の時刻にリスト上に存在するアクティブなエントリの数は、フィールド・ナムにより指定される。ルート・サーバ上のその他のデータ構造同様、ルート・リストは割り当てたり再使用できるが、破棄されることはない。ルート・リストは永続性のある存在なので、可能な限り柔軟性をもたせたほうがよい。その中心にはユニオンがある。これにより、ルート・リストは、void*、BGPattr*、または２つの16-ビット整数で構成された構造を格納できる。

ルート・リストは各ペイロード・スロットに以下のそれぞれを保存できる。

構造ルートへのポインタ(RLIST_ROUTE)、
BGPattrへのポインタ(RLIST_ATTR)、
別のルートリストｘへのポインタ(RLIST_ATTR)、および
BGPannc 構造の一部 (RLIST_ANNC または RLIST_ANNC2)。

ペイロードがポインタとなる事例は比較的簡単なもので、タイプ・フィールドは単にどのタイプのデータが指向されているかを示すだけである。RLIST_ANNCとRLIST_ANNC2の事例は幾分違っている。その際にペイロードは実際の構造のコピーを含むが、それに対するポインタは含まない。BGPannc 構造は単一のポインタよりも大きいので、２つの連続したルート・リストのスロットに保存される。ポインタを伝達するのでなくBGPannc をコピーする理由は、ルート・リストが伝達されたスレッドがデータを読み込む前に、ポイントされたデータが解放される場合があるからである。コマンド・スレッドが長時間動作しているコマンド(show ip bgp など)の出力に対応するために生成された場合には、これがバグになって、ルートサーバをクラッシュする可能性がある。

ルート・サーバはそのルート・テーブル５１８にプレフィクス割り当てのために大きな容量を持つことができる。これは、ルート・テーブル５１８の構造およびルート・サーバのメモリ・アラインメントによるものである。ルート・サーバのルート・トラフィックは、リアルタイム/何分の１秒の感覚で要求を出す。この時、何十万というルートを含んでいる多量のルーティング・テーブルを使用する。

図６は、トラフィック計算の実行のブロック・ダイアグラムテーブルおよびルート・サーバにおけるルートのカスタマイズ部分を図示したものである。ルート・サーバ６０５は、ユーザ・インターフェース６２１をユーザに表示するようプログラムされたコードを保持している。これはユーザ条件を収集して、そのユーザ条件をＩＳＰが供給した情報に一致させるためのものである。これにより自動的にＩＳＰサービスが各ユーザに送られるが、それは当該ユーザとＩＳＰプロバイダの両方が提供した条件に基づき実行される。ルート・サーバ６０５はこの条件に沿い自動的にＩＳＰサービスをユーザに提供する。これは、長期的トラフィックまたは契約上の責任なく行われる。ルート・サーバ６０５は直接、複数のユーザが持つネットワーク・エレメントに接続する。これは、Border Gateway Protocolを使ってインターネット・パケットに経路をつけるため、そして、自動的にインターネット・ネットワーク・サービス・プロバイダを選択するためである。データベース６７０は、各ユーザが行った変更要求におけるインターネット・ネットワーク・サービスにかかわる複数のユーザ条件を保存する。また、複数のインターネット・ネットワーク・サービス・プロバイダからのネットワーク・サービスの情報も保存する。ルート・サーバ６０５は自動的にネットワーク・サービスの再ルート化を行いる。これには、１人もしくは複数のユーザからインターネット・パケットを受け取ることも含まれる。これは、インターネット・ネットワーク・サービス・プロバイダからの変更要求ならびに、ユーザにより提供されデータベースに保存された、変更要求の中で定められる条件に基づいて行われる。

ルート・サーバ６０５はユーザ・インターフェース６２１を持っている。これによりユーザは変更要求を出すことができる。変更要求は、ネットワーク・サービス条件を含むことができる。ネットワーク・サービス条件はネットワーク・サービスを定めるもので、選択されたネットワーク・サービス・プロバイダのルータによって提供される。ネットワーク・サービス条件は拒絶するべきネットワーク・サービス・プロバイダ・ルータを定める。データベースはまた特定のユーザが持つネットワーク上にある各ネットワーク・エレメントのメディア・アクセス・コントロール・アドレスを保存する。そして、複数のインターネット・サービス・プロバイダからのネットワーク・エレメントのメディア・アクセス・コントロール・アドレスも保存する。これは、経路カスタマイズ・サーバがインターネット・サービス・プロバイダを選んで、インターネット・パケットを含むネットワーク・サービスを自動的に、複数のユーザの中で少なくとも一人のために、再経路化するためである。

ネットワーク・サービス・プロバイダの複数のルータは、ネットワーク・サービスの価格設定情報、帯域幅、経路回数などをユーザ・インターフェース６２１を経由してルート・サーバ６０５に送る。ルート・サーバ６０５は、複数ユーザの１人のピア化を、提供されたネットワーク情報に基き、１つもしくは複数のインターネット・ネットワーク・サービス・プロバイダのために選択する。ユーザが経路カスタマイズを変更した場合、portalRouteConfigなどの関数はコンフィギュレーションを再生成して、ルート・サーバ６０５へ送信する。

基本設定はコンフィギュレーション・テンプレートで管理され、１つのＩＢＸごとにデータベースに保存される。ピアメッシュ生成のため、テンプレートは、コマンドと特別の portalRouteConfig コマンドで構成される。

トラフィック計算サーバ６４０は、選択されたインターネット・ネットワーク・サービス・プロバイダが提供するネットワーク・サービスに基づき、請求書情報を複数のユーザに送信する。請求書情報は、１つもしくは複数のメディア・アクセス・コントロール・（ＭＡＣ）アドレスに基づくものである。ＭＡＣアドレスは、当該ユーザに関連したネットワーク・エレメントに関連している。請求書情報は、選択されたネットワーク・サービス・プロバイダのルータが持つネットワーク・トラフィックの量に基づく。ネットワーク・トラフィックは複数のデータ・パケットを含む。タイムスタンプおよびＭＡＣのアドレスが最低１つ存在する。トラフィック計算サーバ６４０が、ＭＡＣアドレスに基づいて各ユーザが使用するネットワークの総量を決定し、そしてそのネットワーク総使用量に基づいて各ユーザのために請求書情報を計算する。トラフィック計算サーバ６４０は定期的にネットワーク・トラフィック情報を受け取って、９５パーセンタイル・アルゴリズムに基づいてネットワーク総使用量を計算するためのインプットを持っている。トラフィック計算サーバ６４０は、電子請求書により各ユーザに請求書情報を提供する。

図７はメモリを使用するルート・サーバのダイアグラムを図示している。ルート・サーバ７０５は、すべての利用可能なプレフィクス/経路の全セットを含む大きなルート・テーブルを使用してリアルタイム／何分の１秒の間隔でトラフィック要求を指示する。ルート・サーバ７０５はトラフィック要求をすぐに満期とする。ルート・テーブルおよびメモリ７３０のアラインメントにおけるプレフィクスの割り当てに大きな容量があるためである。ルート・サーバ７０５はまたリサイクル・キューを使うことで、キャッシュ・ロードをよりうまく使用できる。これは、連続的に使用されるグローバル変数を相互にメモリ７３０の近くに単一のファイルで保存することにより実行する。メモリ７３０のプレフィクスがいったんメモリ７３０に割り当てられると、解放されることはない。その他の効率性も向上する。

リサイクルされたキュー

ルート・サーバ７０５が使用するキューの実行はかなり簡単なものである。しかし、malloc()/free()の活動の量を減らすためにスレッド・ロック化して、キュー・エントリのプールを保持することが例外になる。それは基本的に２つのリンク・リストに過ぎない。アクティブなキュー・エントリのアイテム、および再使用に的確なキュー・エントリのアイテムである。

ルート・サーバ７０５は１つもしくはそれ以上のキュー構造を使用する。これは、内蔵のスレッド・ロック化と信号化機能によって設定される。例となる構造は以下の通りである。

typedef struct QueueEntry {
struct QueueEntry *next;
void *dataptr;
} QueueEntry;

typedef struct Queue {
QueueEntry *first, *last, *reuse;
u_int count; /* how many entries are in the queue */
u_int initcount; /* how many entries to init during malloc */
pthread_mutex_t lock;
pthread_cond_t cond;
} Queue;

Queue *queue_new (u_int initcount);
u_int queue_size (Queue *q);
void queue_add (Queue *q, void *dataptr);
void *queue_get (Queue *q, int wait);
void *queue_get_locked (Queue *q);
#define QUEUE_WAIT 1
#define QUEUE_NOWAIT 0

initcountパラメータは、mallocステートメントを使用して複数のキュー・エントリ構造を一度に割り当てるためのキュー・コマンドを示す。従って、queue_new()へのコールで１つのキューが最初に設定された時には、malloc()のためにinitcountのパラメータがキュー・エントリ構造の数に応じて設定される。これはキューを大きくする必要があるたびに行われる。

理想的には、ルート・サーバ７０５ができるだけデータを動かさないのが望ましい。多くのデータ・フローはポインタを動かすことにより実施される。パケットとシステム内部の構造は解放されるのでなく、リサイクル・パイルの中に配置される。これによりmalloc()/free()に対する多くのコールが節約できるが、スレッドの発行を避けるためには、ロックを獲得する必要がある。ルートサーバ７０５は、これを利用してmalloc()の活動量を制限する。

新しいエントリはすべて「リサイクル」リストに付加される。リサイクル・リストのキュー・エントリのプールは、キュー・エントリ構造の再使用に使用される。そのためルート・サーバ７０５は、絶えずmalloc()やfree()をキュー・エントリ構造に対して行う必要がない(mallocとfreeはロッキングの原因となる)。従って、キューエントリが処理される時には、それはfree()とされるのでなく、むしろキューの再利用リストに付加される。malloc()とfree()はロッキングの原因になるからである。ルート・サーバ７０５では、ロッキングをできるだけ少なくすることが望ましい。mallocは動的なメモリ割り当てを使用する。メモリ７３０はより簡単にかつより柔軟に管理される。これは、当該目的のため構造化されたメモリ７３０の領域通常ヒープからメモリ７３０を割り当てることで行う。Ｃにおいては、メモリのブロックをヒープに割り当てるためにライブラリ関数 malloc を使う。このプログラムは、mallocが戻したポインタを経由してメモリのブロックにアクセスする。メモリが必要でなくなると、ポインタが送られてメモリの割り当てを解除し、別の目的に使われるようにする。従って、キューはまた「空の」キュー・エントリ構造を再利用目的でホールドするために使われる。現在のスキームでは、キューは解放されない。なぜなら、それらが再度必要とされる可能性が高いからである。「queue_get」は待機パラメータQUEUE_WAIT、またはQUEUE_NOWAITを使う。待機が選択された場合、キューは queue_add からの信号を待つ。

キュー・エントリの構造は決して解放されることはないので、１回だけのイベントのためにキューが非常に大きくなった場合、メモリはルート・サーバ７０５が再起動されるまで再要求されることはないことに注意するべきである。しかし、実際には、これが問題となる可能性は少ない。

ルート・サーバ７０５はまたreallocを使用し、メモリのブロックを大きくしたり縮小したりする。reallocはポインタを規定されたサイズのメモリ領域に戻す。このメモリ領域は、ポインタが示した古い領域と同じデータを持っている (データは、新規あるいは旧サイズの最小値にトランケートされている)。

キューのついたすべてのメモリ・ポインタは、割り当てと解放のコーリング・ルーチンの責任を持つ。従って、キューを使うルーチンは、そのキューに伝達されたすべてのメモリ・ポインタを、割り当てたり解放するのに責任を持つ。通常、これらのキューからデータが除去された後で、コーリング・スレッドがデータ・ポインタを自身のリサイクル・キューに配置し、将来の使用に備える。例えば、読み込みスレッドがパケットを読み込み・キューに配置する。アップデート・スレッドがパケットを処理し、使用済みのパケットをread_recycleキューに置きかえる。読み込みキューはread_recycleキューを使う。これにより大量のメモリ割り当てや割り当て解除を回避することができ、連続する構造を大量に割り当てることが可能になる。

ルート・サーバ７０５では、キューはスレッド間の通信のためのプライマリ手段として使われる。データ・ポインタの実際の内容はキューごとに異なる。例えば、読み込みスレッドはピアから受け取ったＢＧＰパケットを読み込みキューに配置する(ルート・テーブル・スレッドで処理するため)。アップデート・スレッドはＢＧＰアップデート・パケットを特定のピアのチャンネルにある書き込みキューに配置する。それは、当該ピアに書き込みスレッドを使って送られる。

メモリ使用

ルート・サーバ７０５は、メモリ速度と効率化のために、使用済み変数をメモリ７３０の近くに連続的に保存する。ルート・サーバ７０５にあるすべてのグローバル変数は、vars.cファイルなど単一のファイルに収集される。このように最も頻繁にアクセスされる変数を一緒に保存することは、キャッシュで保存する際に役立つ。これはパフォーマンスの観点で重要なことである。高い使用頻度が予想される関数の例としては、ルート・サーバ７０５に利用可能なチャンネルとＢＧＰピア、インポート・マスクのＮ×Ｎアレイ、重要なキューのポインタ、アクティブ・コンフィグのポインタ、ルート・テーブルのポインタ、さまざまなロックとグローバル・カウンタなどがある。ライブ・アップデート中の多くのmemcpy()を回避するため、ルート・アップデート用にグローバルの一次格納領域がある。ルート・サーバ７０５は、前後で使用された変数をメモリ７３０中の近くの位置に保存することで、キャッシュ・ロードをよりよく使用する。

ルート・サーバ７０５は、ピアの最大数を制御するコンパイル・タイム・ノブ保持する。この制御により、ルート・サーバ７０５はメモリ７３０の一定の領域を予め割り当てる。そして、メモリの帯域幅を大量に節約する。この帯域幅は、制御がない場合は、動的にサイズが決められたデータのスキャンに使用される。ピアの最大数をコントロールすることで、類似のデータベースを近接してメモリ７３０内に格納することができる。これにより、キャッシュが効率的になる。

実施例では、キャッシュ・ロードも最適化される。ルート・サーバ７０５は３２ビット・メモリ・モデルを使用する。メモリ・バス上のデータ移動は、ポインタ・スキャンとコピーで行うためである。プロセッサはデータをメモリから外部のキャッシュへ一度に６４バイトの量で移動させる。キャッシュ・ラインのロードは６クロック・サイクルで行う。８バイトを外部キャッシュから内部キャッシュに移動するには、２クロック・サイクルが必要である。内部キャッシュはプロセッサ速度で働く。ルート・サーバ７０５が６４ビット・ポインタを使った場合、ルート・サーバ７０５はＩ−キャッシュをＥ−キャッシュへ増加し、外部メモリは最低２で転送する。より多くのシステム・オーバヘッドが２倍のメモリ・ページに対処する際に存在し、６４ビット・モードは３２ビット・モードより低速で実行できる。

インストラクションサイズは、６４ビット・モードに、３２ビット・モードを持っている場合がある。これは、直定数は多くの場合１６ビットに制限されているということを意味する。ポインタやその他の３２ビット定数値をロードするには２つの命令が必要である。(最初の１６ビット、または２番目の１６ビットをloadhi する)。６４ビット・モードでは、６つの命令を必要とする(２つのloadhi、１つのsllx(左シフト)、および３つのor)。それは、addxタイプの命令を発行するが、データ・ロードは３２ビットで行う。ルート・サーバ７０５は、３２ビットにアクセスしたすべてのものを調整することでデータを割り当てる。

入力と出力の交信は、チャンネル経由で行う。基本的にチャンネルはソケットに何らかの追加的なビットをプラスしたものである。チャンネルへのソケット記述子であるsocketidや、チャンネルが関連するピアであるsocketidなどである。これはデーモン・チャンネル(ＢＧＰと管理接続のために働く)、ログ・チャンネル(ファイル、syslog、stderr)、ＢＧＰピア、および管理ログインを含んでいる。チャンネルは静的にコンパイル時間で割り当てられ、config.hが定義のルート・サーバ７０５MAX_CHANNELSでコントロールされる。これは、メモリの同じ領域で共通して使われるすべてのデータを保存するように行われる。できるだけキャッシュから多くの利益を得るためである。ルート・サーバ７０５はこれをルート・サーバ７０５_MAX_BGPPEERS に近づくように設定することで、キャッシュ・スペースとメモリ帯域幅を節約する。また、ログ・ファイル、デーモン、およびログインのための余地を残す。

ＢＧＰピアも、同様の理由により、静的に割り当てられた配列に保存される。ＢＧＰピア構造は、シャットダウンのために構成される場合も、構成されたすべてのピアのために存在する。ピアが除去された場合、「deconfig」の状態で現われる。ピアの最終的除去は、ガーベジ・コレクションの時に発生する。

入ってくるＢＧＰ属性は分類された動的配列の中に保存されることに注意すること。同様のピアからの類似した経路が同じ属性を共有するということが頻繁に起こる。プレフィクスの間の属性を共有することは、ルート・サーバ７０５にとって大きな利益となる。最終的に未使用の属性はガーベジ・コレクションプロセスの間に取り除かれる。

図５を参照すると、ルート・サーバが使用するタイプを想定することで、ルート・サーバがそのメモリ使用をできるだけ効率的なものにしようとしていることが分かる。ルート・サーバはインターネット・ルーティング・テーブルで使うルート・サーバとして設計されるため、ルート・サーバはピアからのプレフィクスで典型的なセットを受け取るよう想定されている。トランジットＩＳＰプロバイダは、完全なセットのプレフィクスを送る必要がある。その数はおよそ、１２万９０００個のユニークなプレフィクスに相当するものである。プレフィクスは、始めと終わりのアドレス、および所定のルート長の両方を指定するコード文字列になる。Route server _MAX_BGPPEERS はデフォルトを１００にして３２−ビット・ポインタに設定する。そのため、それぞれのユニークなプレフィクスは最低４２８バイトのメモリを使いる。(注:構造経路のサイズは、route server _MAX_BGPPEERSに依存する)。しかしながら、インターネット上の多くのデフォルト・フリーのホストは非常に類似したセットのプレフィクスを持つため、１０個のピアがそれぞれ１２９，０００のプレフィクスを送る場合でも、ユニークなプレフィクスは１２９，０００しか存在しない場合がある。ルート・テーブル５１８に既にあるプレフィクスがルート・サーバに入った場合、新しい経路構造が割り当てられることはない。そして、新しいBGPattrが割り当てられるのは、このプレフィクスの属性 (ＡＳ−パス、など)がこのピアによってアナウンスされた他のプレフィクスとは違う場合のみである。BGPannc構造はroute server _MALLOC_ANNC で大量に割り当てられ、該当するプレフィクスの構造経路に付加される。ライブのアナウンスメントをカバーするのに十分な量のものが常にある。したがって、プレフィクスがメモリにいったん割り当てると、それは決して解放されない。このため、ルート・サーバが非常に速く効率的になる。

従って、割り当てるメモリの容量は潜在的に大きなものとなる。しかし、予期される作業負荷(多くのアナウンサーがいる多くのプレフィクスだが、ほとんどのアナウンサーが類似したセットのプレフィクスをアナウンスしている)を考えると、いったんプレフィクスがアナウンスされると、それはおそらく「永遠」的なものになるであろうと想定して間違いない。たとえ現在のアナウンサーがそれを取り下げても、誰かがおそらくそれをアナウンスするだろう。ルートサーバがこれをmalloc()の活動量の最大限まで利用すると、プレフィクスがいったん割り当てられた場合、それは決して解放されない。これにより、ルート・サーバが多くのメモリ・スラッシングを避けることができる。しかし、犠牲になるものがある。ピアが何か間違ったことをして、例えば、通常は短いプレフィクスを、より長いプレフィクスのサブネットで送った場合 (集約解除)、ルート・サーバがより多くのメモリを割り当てることになり、ルート・サーバが再開されるまで、それが解放されることはない。

図７は、複数のクラスに複数のビューを維持しているルート・サーバのダイアグラムを図示している。ルート・サーバ７０５は、一つの経路にまとめられた自立システムの中で、ピアノグループのビューを保持している。各ビューは関連した複数のクラスを持ち、１つとみなされる経路のそれぞれは、クラス数がゼロまたは複数になる。一つとみなされる経路は、ネットワーク属性条件に基づきクラスに割り当てられる。この場合ビューはルータのようなものだといえる。各ビューはピアのグループで構成され、通常は同じ自立システムにある。その経路は一緒であるとみなされ、他のビューから同じセットの経路を送られる。

ルート・サーバ７０５も、ビューとクラスを使って入力時間で経路の分類をサポートする。各ビューはそのビューにおけるクラスの数を定義し、経路はそのクラスの１つもしくは複数に属することができる。クラスはさまざまなクラス(所定のＩＳＰプロバイダが提供するもの)のサービスに使用できる。例えば、ＩＰトランジットは１つのクラスで、オンネットは別のものになることがある。また、所定のクラスにおける単なる１セットのルートが、別のピアのビューにインポートされてもかまわない。

パフォーマンスを考慮すると、ルート・サーバ７０５は他のルータに比べて、経路をフィルタしたり変更したりするような、細かな制御はできない。フィルタリングの主たる手段はルート分類である。これはピアがルートを受け取ったときに実行される。４つの主なマッチ用のタイプ(prefix-map、aspath-map、community-map、および nexthop-map)を使うことで、ルートはインポートされた様々なクラスに加えられる。各ビューは最大３２個のクラスを持つことができる。そして、各経路は、ゼロまたはそれ以上のクラスに存在する。どのクラスにも分類されない経路は、どのピアにも伝達されない。経路は、それがどのクラスにあるかに基づいて、他のビューによって考慮の対象になる。このためには、インポート・ステートメントが使われる。クラスは、第１クラスのバックアップ経路、別のクラスの米国専用経路、第３クラスのヨーロッパ専用経路、そして第４クラスの経路用の料率などを定義したり、含んだりする。

図２と下記のコード・スニペットを参照すると、バイヤー１はisp-1とisp-2の両方から購入しているが、バイヤー２はisp-2からしか購入していない。バイヤー１のビューはisp-1の「オンネット」クラスの経路から選択をするが、バイヤー２のビューはisp-2の「オンネット」および「ヨーロッパ専用」クラスの経路から選択をする。このコード・スニペットは実際の分類用ビットを示すものではないということに注意すること。

view name isp-1
two classes
class transit
class on-net
member in view structure points to import buyer-1 class buyer-1

view isp-2
class transit
class on-net
class Europe-only
import buyer-1 class buyer-1
import buyer-2 class buyer-2

view buyer-1
class buyer-1
import isp-1 class on-net
import isp-2 class transit

view buyer-2
class buyer-2
import isp-2 class on-net Europe-only

エクスポート・コマンドがないことに注意すること。経路の分類は、エクスポートのためにルートをタグすることである。クラスをインポートすると、そのクラスに関連したすべての経路が、ビューのピアを送るのに有効としてマークされる。次に、Best Path の処理がどの経路を実際に送るかを決定する。ただし、ユーザによってルートの全リストを送るように選択された ISP プロバイダの部分集合を除くこと。

ビューはＢＧＰのピア化構造とは別に保存され、複数のＢＧＰピアと共有することができる。ベスト・パス変数におけるビット・パッキングに注意すること。これは頻繁に参照されるので、レジスタとローカル・キャッシュに保存しておくのがよいだろう。

ビュー構造はルーティング・テーブルのビューに関連した情報のすべてを保持している。ビュー構造は、パービュー・ベースでセットできる情報のすべてを保持している。そうした情報には、ベスト・パス発注情報、ＢＧＰダンピング設定、インポート・リスト、クラス名、さまざまなマップ、およびその他の類似した情報などがある。また、参照カウントもあり、ガーベジ・コレクタはビューの安全な削除タイミング、ならびにピア(つまり、実際の経路)に関連しているビューの名前が分かる。

ビュー構造は直接ルート自体に関してどんな情報も含んでいない。class_meshはピアのビューに含むことのできるピアををトラッキングするのみで、class_meshの情報はインポートのリストからview_change()によって生成される。以下は実際のビュー構造の例である。

typedef struct View_t {
struct View_t *next;
/* packed 32bit int as follows:
* bottom 8 bits: flags (0x000000ff)
* next 8 bits: unused (0x0000ff00)
* top 16 bits are best path order..3 bits at a time
* 1st comparison: 0x00070000 0000 0000 0000 0111
* 2nd comparison: 0x00380000 0000 0000 0011 1000
* 3rd comparison: 0x01c00000 0000 0001 1100 0000
* 4th comparison: 0x0e000000 0000 1110 0000 0000
* 5th comparison: 0x70000000 0111 0000 0000 0000
* last bit unused: 0x80000000 1000 0000 0000 0000
*/
uint32_t best path;
uint16_t dampening_penalty; /* 0 = no dampening */
uint16_t dampening_halflife;
uint16_t dampening_reuse;
uint16_t dampening_supress;
uint16_t dampening_maxsupress;
uint16_t dampening_maxpenalty;

uint8_t obsolete;
ViewImport *imports;
PrefixMap *prefix_map;
CommunityMap *community_map;
NexthopMap *nexthop_map;
ASpathMap *aspath_map;

int refcount;
char class_name [EDRS_CLASS_BITS][EDRS_NAME_MAX_LEN + 1];
char name [EDRS_NAME_MAX_LEN + 1];
} View;

実施例では、各ビューがさまざまなクラスを入ってくるプレフィクスに割り当てることができる。１つのビューに最大で 32 個のクラスがある。各クラスに名前を付け、ビット・ポジションに割り当てる。これで、ＢＧＰ広告がどのクラスにあるかを発表する際に、単一の３２ビット整数を使用できる。

他のビューからのインポート・リストを３２ビット整数にまとめることができる。各ピアはカスタム・インポート・リストをお互いのピアのために必要とするため、最終的には非常ににコンパクトな３２ビット整数のＮ×Ｎ配列を作成した。これはすべてのピアを表現できるものである。これがアナウンスメントの初期のフィルタリングを非常に高速化する。使用しているのはすべてが論理的なＡＮＤだからである。基本的に、アルゴリズムは以下の通りである。

announcement->class AND class_mesh [from][to].
/* class mesh: [x][y] x=from y=to */
extern EDRS_CLASS_TYPE class_mesh [EDRS_MAX_BGPPEERS][EDRS_MAX_BGPPEERS];

実装には、EDRS_CLASS_TYPEを使うということに注意すること。それは３２ビット整数に分類される。必要なら 64 ビット整数にするのが比較的簡単だろう。しかし、３２ビットを引き受けるコードにそのような(マークされた) 場所は少ししかない。

ルート・サーバ７０５も特定の経路を特定のピアからマークするための手段にすぎない。このマークは、特定のセット(別のピアのビューにインポートされる)の経路に所属するものとしてなされるものである。これが意図された使用法は、例えば、ＩＳＰが一部の経路を「有料ピア化」ルートとしてマークしたり、「トランジット」ルート、「ヨーロッパ」ルート、そして「北米」ルートとしてマークできるようにすることである。そして、バイヤーによって購入されたルートだけをバイヤーのビューにインポートするのである。

class_mesh は EDRS_CLASS_TYPE 変数のグローバルＮ×Ｎ配列で、どのアナウンスメントがどのピアに送られたかの情報を保持するように設計されている。クラス・ナンバーシップという考え方により、１つのピアの経路のどの部分が別のピアに送られるのかについて細かいコントロールができる。これはルート・フィルタリングのためにクラスが使えるからである。

class_meshの各スロットはビットマスクでピア、および各ピアが経路を受け取るのに適格なクラスを表わす。それぞれのBGPattrはクラス・フィールドを持っているので、update_process_peer()で簡単にチェックできる。これにより、ＥＤＲＳが特定のプレフィクスを特定のピアに送るべきかどうかを判断することができる。

/* check to see if the class is being imported */
if ((attr->class & class_mesh [attr->peerid][peerid]) == 0)
continue;

これはビットのためのAND (&)であって、Boolean (&&)操作のためではないことに注意すること。class_meshの各スロットは関数view_change_slot()にセットされ、ガーベジ・コレクションの間にコールされる。

実施例では、上記のアルゴリズムルーチン、構造などを促進するために使われるソフトウェアは読み取り可能な機器媒体で実行できる。読み取り可能な機器媒体は、機械で読み込みできる形式になっている情報を提供できる(例えば、保存や伝達など)あらゆるメカニズムを含んでいる(例えば、コンピュータ)。読み取り可能な機器媒体には、読み込み専用メモリ(ROM)、ランダム・アクセス・メモリ(RAM)、磁気ディスク記憶媒体、光記憶メディア、フラッシュ・メモリ・デバイス、デジタル・ビデオ・ディスク (DVD)、EPROM、EEPROM、FLASH メモリ、磁気または光学式カード、または電子指示を保存するのに適当なあらゆるタイプの媒体などが含まれる。

上記の詳細な説明の一部は、アルゴリズムの形式やコンピュータメモリ内にあるデータ・ビットの操作をシンボルで表現することで提示される。これらのアルゴリズム的な記述や表現はデータ処理技術に優れた人が用いる手段である。これにより、人的作業が別の熟練技術者に非常に効率的に伝達できるのである。ここにあるアルゴリズムは一般に首尾一貫したステップのシーケンスとみなされており、望ましい結果が得られるものとなっている。このステップは、物理的数量に物理的操作を必要とするものである。通常、必ずしもそうでないかもしれないが、これらの数量は電気的または磁気的信号の形を取る。そうした信号は保存、転送、結合、比較、あるいはその他の形で操作できるものである。それは時には便利なものになる。主たる理由は、共通に使える、信号をビット、バリュー、エレメント、シンボル、キャラクター、用語、数字、あるいはその他のものとして表わすことができるということである。これらのアルゴリズムは多くの異なったソフトウェアプログラミング言語で書くことができる。

これらの用語およびそれに類似の用語は、適切な物理的数量と関連しており、そして、物理的数量の内容を表す用語に過ぎないということに留意すること。具体的に別の趣旨の記述がない限り、上記の説明の中で「処理」、「電子計算」、「計算」、「決定」、あるいは「表示」といった用語が使われていた場合、それはコンピュータ・システムまたはそれに類似の電子計算装置のアクションやプロセスを指したものである。こうした装置は、コンピュータ内のレジスターやメモリ内に物理的 (電子的) 数量で表示されたデータを操作して別のデータに変換し、コンピュータ内のレジスターやメモリ内で、もしくはその他の情報ストレージ装置、や伝達装置または表示装置内で、同様な物理的数量で表示されるようにするものである。

発明についていくつかの具体化事例が示されていても、発明はその具体化事例に制限されない。例えば、電子ハードウェア・コンポーネントが実行したほとんどの機能が、ソフトウェア・エミュレーションでコピーされることがある。したがって、同じ機能を達成するために書かれたソフトウェア・プログラムが、入出力回路におけるハードウェア・コンポーネントの機能性をエミュレートする場合がある。この発明は本件に記載の具体的実現にのみ限定されるものとして理解されるべきでなく、追加された当社の主張事項の範囲によってのみ限定されるものとして理解されるべきである。

Claims

複数のインターネット・ネットワーク・サービス・プロバイダから複数のユーザのネットワーク要素（elements）へと、ネットワーク要素を接続するようにプログラムされたコードを有し、かつルータを含む、ルート・サーバを包含する装置であって、
前記ルート・サーバは、前記複数のユーザと前記複数のインターネット・ネットワーク・サービス・プロバイダとのために、ルーティング決定を行うようにプログラムされたコードをも有すると共に、これらの決定を、ブローダ・ゲートウェイ・プロトコル（Broader Gateway Protocol:以下、ＧＢＰと略記）を介して、前記複数のインターネット・ネットワーク・サービス・プロバイダの１又は２以上に伝達し、
前記ルート・サーバは、ルーティング・テーブルの複数のビューを維持（maintain）すると共に、複数のＢＧＰインスタンスを実行するようにプログラムされたコードをも有し、かつ各インスタンスは、前記ルート・サーバの単一のインスタンスにおいて、異なる自立システムとなり、
前記ルート・サーバは、第１のユーザと複数の前記インターネット・ネットワーク・サービス・プロバイダとの双方により提供される条件（criteria）に基づいて、第１のユーザをインターネット・ネットワーク・サービス・プロバイダの１又は２以上に適合させるようにプログラムされたコードをも有し、
前記条件に基づいて前記第１のユーザを前記インターネット・ネットワーク・サービス・プロバイダに適合させた後、前記第１のユーザは、前記第１のユーザのＩＰパケットを宛先アドレスに届けるためのルート・テーブルを構築するために、前記ユーザの条件と適合した各インターネット・ネットワーク・サービス・プロバイダからの、各インターネット・ネットワーク・サービス・プロバイダの最良の可能ルートのみならず、宛先アドレスへの全ての可能ルートの全リストから選択することができる、装置。
前記ユーザの条件は、使用可能なインターネット・ネットワーク・サービス・プロバイダのサブセットを含み、かつ前記ルート・サーバは、前記第１のユーザが選択したサブセットにおいて、各インターネット・サービス・プロバイダから、全トランジット・ルート（full transit route）を受け取るために、前記ルート・サーバと前記第１のユーザの前記ネットワーク要素との間に、１又は２以上の追加のＢＧＰピアリング・セッション（peering session）を育成する（bring up）ようにプログラムされたコードをも有する、請求項１に記載の装置。
前記ルート・サーバは、ネットワーク・トランジット・パス（paths）をフィルタリングすることについてのユーザの条件と適合する全トランジット・ルートから、特別なルート・プレフィックス（route prefixes）を、フィルター・イン（filter in）、フィルター・アウト（filter out）、又はフィルター・インとフィルター・アウトの双方を行うために、これらの全トランジット・ルートにフィルターを適用（apply）するようにプログラムされたコードをも有する、請求項２に記載の装置。
前記追加のＢＧＰピアリング・セッションは、前記ルート・サーバと前記第１のユーザのネットワーク要素との間に、プロバイダの（per-provider）セッションのための、双方向通信（bidirectional communication）を確立し、そのプロバイダのセッションにおいては、前記第１のユーザのネットワーク要素は、前記追加のＢＧＰピアリング・セッションを通じて、前記ルート・サーバの主たるＢＧＰピアリング・セッションを通じて折返し通知される（announced back）情報とは異なる情報を、前記追加のＢＧＰピアリング・セッションを通じて、１又は２以上のＩＳＰに通知することができる、請求項２に記載の装置。
前記ルート・サーバは、前記ユーザの条件を集める（gather）ために、前記ユーザに対して、ユーザ・インタフェースを提示（present）し、かつ前記第１のユーザとＩＳＰプロバイダとの双方により提供される条件に基づいて、前記ＩＳＰが前記第１のユーザに対してＩＳＰサービスを自動的に提供することにより提供される情報に、前記ユーザの条件を適合させるように、プログラムされたコードをも有する、請求項２に記載の装置。
前記ルート・サーバは、各ＢＧＰインスタンスが自己のルータＩＤを有し、異なるＩＰアドレス及びＴＣＰソケットについて聞き（listens）、かつ全てのＢＧＰインスタンスが同一の自立システム番号の一部である場合には、同一のピア（peers）に話す（talking）多数の（multiple）インスタンスをサポートするようにプログラムされたコードをも有し、それにより、バイヤー（buyers）が個別の（separate）ＩＰアドレスとピアすることができ、かつ特定のＩＳＰプロバイダにより送られたそれらのルートを単に取得できる場合には、前記ルート・サーバは、プロバイダのＢＧＰセッションのために、ＢＧＰの多数のインスタンスを使用する、請求項１に記載の装置。
前記ルート・サーバは、多数の（multiple）スレッド・デーモン（threaded daemon）としてコード化されており、かつ前記多数のスレッド・デーモンは、主スレッド（main thread）と４個又はそれを超える数の独立した永続的スレッド（persistent thread）とからなり、さらに
ピアからの伝送制御プロトコル（ＴＣＰ）・トラフィックを取り扱い、新しいＴＣＰ接続を受け入れ、かつ失敗した接続を検出するようにプログラムされたコードを有するリード・スレッドと、
実際のデータパケットをピア接続へと送るようにプログラムされたコードを有するライト・スレッドと、
いずれのプレフィックス（prefix）が、各ＢＧＰピアに対して、通告される（advertised）べきか又は取り下げられる（withdrawn）べきかを決定するようにプログラムされたコードを有するアップデート・スレッドと、
前記ルート・テーブルへのリード及びライトの双方のアクセスにおける唯一の永続的スレッドとなることにより、全てのピアのために維持される単一のルート・テーブルを維持するようにプログラムされたコードを有するルート・テーブル・スレッドとを含み、
前記ルート・テーブル・スレッドのみが前記ルート・テーブルを変更することできるので、他の独立した永続的なスレッドが、前記テーブルから、同時にかつスレッドをロックさせることなく、読み出すことを許容することにより、全てのスレッドにより前記ルート・テーブルへの高速アクセスを許容するために、前記ルート・テーブル・スレッドは、前記ルート・テーブルに書き込むことができる唯一の永続的なスレッドとなる、請求項１に記載の装置。
前記永続的な独立スレッドは、互いの間を通過するキュー構造（queue structure）と状態変数（condition variables）とを介して交信（communicate）し、その後、前記キューをパイプライン処理し、拡張性（scalability）を達成するためにフラグを使用する、請求項７に記載の装置。
前記ルート・サーバは、リンク・リストとＢトリーとのハイブリッド・コンビネーションであるルート・テーブルを有し、前記ルート・テーブルは、前記ルート・テーブルが実行中に再びバランスをとる必要がないことを確かなものとする（make sure）ために、ネットマスク長のルート内に、各ルートのネットマスク長により予めバランスのとられた組織（organization）と、全ての可能なプレフィックスのためのフィールド・エントリーとを有し、
新たなＢＧＰセッションが確立するときに、前記ルート・テーブル内において、既存のルートを追加したり削除したりする理由がなくなるように、むしろ、幾つかのポインタの更新により、与えられたプレフィックスと関連する幾つかの特性を変化させるように、全ての通知されたルートは、前記ルート・テーブルの予め割り当てられたメモリ空間に永久的に保存（kept）される、請求項１に記載の装置。
前記ルート・サーバは、リンク・リストとＢトリーとのハイブリッド・コンビネーションであるルート・テーブルを有し、前記ルートテーブルは、非再帰的アルゴリズム（non-recursive algorithm）によるスキャンを許容するために、有界の最大深さを有し、かつ
前記ルート・サーバによるデータ・ハンドリングは、前記ルート・テーブル内を循環するリード・オンリー・ポインタからなり、
他のスレッドに送るためのルートリストを作成するために、ルート・テーブルがスキャンされる必要があるときには、既知の有界最大深さで使用される非再帰的アルゴリズムが、再帰的アルゴリズムが必要である如何なる特別なファンクション・コール・オーバーヘッドも除去する、請求項１に記載の装置。
前記ルート・サーバは、リンク・リストとＢトリーとのハイブリッド・コンビネーションであるルート・テーブルを有し、前記ルート・テーブルの構築は、前記トリーの各ルートが特定のネットマスク長のルートを取り扱い、前記テーブルに既に存在するルートが前記ルート・サーバに到来すると、新規のルート構造は割り当てられず、このルートのＢＧＰ特性が、このピアにより通知された他のいかなるプレフィックスとも同一でないときに限り、新規のＢＧＰ特性が割り当てられる、請求項１に記載の装置。
情報が共有される必要があるときには、前記ルート・スレッド以外のスレッドが、前記ルート・スレッドからパスされたルート・リストを経由して、前記ルート・テーブルからリードすることができ、前記ルート及びその通知は、ルート・リストに置かれ、他の永続的なスレッドの１つに通知され（communicated）、その後、他の永続的なスレッドが、それらがなおも存在することを知っている、前記ルート・リストに置かれたなんらかのポインタをリードすることが許容され、前記通知されたルート・リストが、割り当てられていない空間にスレッドオフを送り込んだりすると言った、他の永続的なスレッドが前記ルート・テーブル自身をスキャンする必要を妨げる、請求項７に記載の装置。
前記ルート・サーバは、スレッド・ロッキングの原因となるメモリ割り当て動作の量を減少させるために、キュー・エントリーのプール（pool）を維持することにより、キューをリサイクルし、かつキュー・エントリーのプールにおける全ての新しいエントリーは、再使用リストに加えられる、ようにプログラムされたコードをも有する、請求項１に記載の装置。
前記ルート・サーバは、単一のファイル内における前記メモリ内の互いに近接するグローバル変数の繰り返しかつ順序的使用を維持することにより、キャッシュロードのより良い使用をなすようにプログラムされたコードをも有する、請求項１に記載の装置。
前記ルート・サーバは、ルーティング・テーブルの各ビューが、そのピアが見る（see）ことを望むルーティング・テーブルのカスタムビューである場合には、ルーティング・テーブルの多対多のビューを維持する、請求項１に記載の装置。
前記ルート・サーバは、そのルートが一緒と考えられる自立システムにおける一群のビューを維持するものであり、一緒と考えられるルートの各々が複数のクラスのうちのゼロ又は１以上であり、かつ一緒と考えられるルートが、ネットワーキング特性条件に基づいて、クラスに割り当てられる場合、前記ビューは、そのビューと関連する複数のクラスをも有する、請求項１に記載の装置。
前記ルート・サーバは、各ビューがクラスの数を定義しており、ルートが１又は２以上のクラスに属することができ、与えられたＩＳＰプロバイダが申し出るサービスのクラスを異ならせるためにクラスが使用される場合には、ビュー及びクラスの入力時におけるルートのクラスをサポートするようにプログラムされたコードをも有する、請求項１に記載の装置。
ルート・サーバのための方法であって、
前記ルート・サーバを介して、複数のインターネット・ネットワーク・サービス・プロバイダから複数のユーザのネットワーク要素へと、ネットワーク要素を接続するステップと、
前記複数のユーザと前記複数のインターネット・ネットワーク・サービス・プロバイダとのためにルーティング決定を行うと共に、ボーダ・ゲートウェイ・プロトコル（Boader Gateway Protocol）を介して、これらの決定を、構築されたルート・テーブルを介して、前記複数のインターネット・ネットワーク・サービス・プロバイダの１又は２以上に通知（communicate）するステップと、
前記ルーティング・テーブルの、前記ルート・サーバが、そのピアのそれぞれが、多数の（multiple）ＢＧＰインスタンスを見ると共に実行することを欲する、多数のビューを維持すると共に、前記ルート・サーバの単一インスタンスにおける異なる自立システムを表す（representing）ステップと、
第１のユーザと前記複数のインターネット・ネットワーク・サービス・プロバイダとの双方により提供される条件（criteria）に基づいて、前記第１のユーザを、前記インターネット・ネットワーク・サービス・プロバイダの１又は２以上に適合させ、前記条件に基づいて前記第１のユーザを前記インターネット・ネットワーク・サービス・プロバイダに適合させた後、前記第１のユーザは、前記第１のユーザのＩＰパケットを宛先アドレスに届けるためのルート・テーブルを構築するために、前記ユーザの条件と適合した各インターネット・ネットワーク・サービス・プロバイダからの、各インターネット・ネットワーク・サービス・プロバイダの最良の可能ルートのみならず、宛先アドレスへの全ての可能ルートの全リストから選択することができ、さらに前記ユーザの条件は、あり得る（possible）インターネット・ネットワーク・サービス・プロバイダのサブセットを含み得る、ステップと、
前記第１のユーザが選択した前記サブセットにおいて、各インターネット・サービス・プロバイダから、全トランジット・ルート（full transit route）を受け取るために、前記ルート・サーバと前記第１のユーザの前記ネットワーク要素との間に、１又は２以上の追加のＢＧＰピアリング・セッション（peering session）を育成する（bring up）ステップと、
を包含する方法。
前記ルート・サーバと前記第１のユーザのネットワーク要素との間に、プロバイダの（per-provider）セッションのための、双方向通信（bidirectional communication）を確立し、そのプロバイダのセッションにおいては、前記第１のユーザのネットワーク要素は、前記追加のＢＧＰピアリング・セッションを通じて、前記ルート・サーバの主たるＢＧＰピアリング・セッションを通じて折返し通知される（announced back）情報とは異なる情報を、前記追加のＢＧＰピアリング・セッションを通じて、１又は２以上のＩＳＰに通知することができるステップと、
前記ルーティング・テーブル内の全てのあり得るプレフィックスのための予め割り当てられたメモリ空間を有する前記ルートテーブル内に、はじめに、ルートを置く（locating）ステップと、
前記ルート・テーブルに、ひとたび、置かれた（entered）場合には、そのルートが、最早、通知されたルートであったとしても、前記ルート・テーブルからルートを消去しないステップと、
このルートの前記ＢＧＰ特性が、このピアにより通知された他の如何なるプレフィックスとも同一でないときに限り、新規のＢＧＰ特性を割り当てるステップと、
をさらに包含する請求項１８に記載の方法。
各ビューがクラスの数を定義しており、ルートが１又は２以上のクラスに属することができ、与えられたＩＳＰプロバイダが申し出るサービスのクラスを異ならせるためにクラスが使用され、かつ与えられたクラス内の一組のルートが、単に、前記ルーティング・テーブルのもう一つのピアのビューへと導入される（imported）ものである場合には、ビュー及びクラスの入力時におけるルートのクラスをサポートするステップをさらに包含する、請求項１８に記載の方法。