ネットワークエンジニアになろう！

前回のSTP を究める 基礎編 (6)Root Path Cost (ルートパスコスト)で、Root Path Cost（ルートパスコスト）を判断基準として、Root Bridge までの最短パスを探し出すことをお話ししました。

あるブリッジからRoot Bridge への最短パスとなるポートを、そのブリッジのRoot Port（ルートポート）と呼びます。

Root Bridge 以外のブリッジは、必ずRoot Port を一つ持ちます（※）。
Root Port はそのブリッジにとって、もっともRoot Bridge に近いポートであると言えます。

ブリッジ上の複数のポートからRoot Bridge へ到達することができる場合、最もRoot Path Cost が小さいポートが、そのブリッジのRoot Port となります。

下図のBridged-LAN では、Bridge-A がRoot Bridge となっています。
Bridge-B、C のどちらも、Root Bridge へのパスが二つあります（Port1、2）。
Port1 とPort 2 の間でRoot Path Cost を比較した結果、どちらのブリッジも、Port1 がRoot Port となります。

※ CatOS で動作するCatalyst は、Root Bridge となっている場合でも、Root Port が表示されます。

ポート番号1/0 は、実際には存在しない番号であることに注意して下さい。
1/0 は、Slot1（Supervisor モジュール）のポート0を意味します。
ブリッジとしてのCatalyst の視点から見て、内部ポート1/0 に接続されているCPU（＝自分自身）にRoot Bridge が存在することを表現しています。

ブリッジが2台以上存在する場合、個々のブリッジを特定するための名前（ID: Identifier）が必要だと、STP を究める 基礎編 (5)Bridge ID とRoot Bridge (ルートブリッジ)でお話しました。

つまり、ブリッジに限らず、二つ以上存在するものには、区別するための名前が必要ということです。

多くの場合、Bridged-LAN には2台以上のブリッジが存在します。
視点を変えて、Bridged-LAN の中の1台のブリッジに注目してみましょう。

ブリッジの中にも、二つ以上存在するものがあります。

ポートです。
そもそも、二つ以上のLAN を接続するための（逆に言えば、一つのLAN を二つ以上に分割するための）機器がブリッジです。
複数のLAN に接続するため、ブリッジには必ず二つ以上のポートが存在します。

複数存在する以上、ポートにも区別するための名前が必要です。

ポートに割り当てられている名前を、Port ID（ポートID）と呼びます。
Bridge ID と同様にポートID も、各ポートの優先度を意味するPort Priority（ポートプライオリティ）という値とポート番号を合わせた値を使います。

Port Priority は、0から255（10進数）の間で設定可能です。
IEEE 802.1D で推奨するデフォルト値は128(16進数の0x80) で、Cisco のCatalyst を含め多くの機器はこの値をデフォルト値にしています。

Bridge ID は、ブリッジ同士で比較してRoot Bridge を決定するために使われました。
Port ID も、同じように比較するために使われます。
この場合、比較の対象となるのは他のブリッジではなく、同一ブリッジ内のポート同士です。

Port ID を比較しなければならないのは、どのような状況でしょうか？

下図のBridged-LAN では、Bridge-A がRoot Bridge となっています。
Bridge-B のPort1 と2はどちらも、LAN-1 に接続されており、Bridge-A からまったく同じデータを受信します。

このように、ブリッジ上の複数のポートがまったく同じデータを受信し、且つ、ポートに設定されたコストが同じ場合、どちらがRoot Bridge への最短パスか、判断できません。
そのような状況で、最短パスを選択するための判断基準として用いられるのが、Port ID です。

上図の説明に戻ります。
Bridge-B のPort1 とPort2 はどちらもLAN-1 に接続されており、Bridge-A から同じデータを受信します。
どちらのポートもCost は10に設定されています。
二つのポートのPort ID はそれぞれ、80:1 と80:2 です（Port Priority = 0x80 とポート番号）。
両者のPort ID を比較した結果、 Port ID が小さいPort1 がRoot Port となります。

STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
これらの拡張仕様については、応用編にて説明する予定です。

投稿者: msori 日時: 00:13 | パーマリンク

特集 - トウキョウトッキョキョカキョクのインデックスページです。

はじめに

UPTO (United States Patent and Trademark Office)

特許文書の閲覧・ダウンロード

トウキョウトッキョキョカキョク (1) UDLD (Uni-Directional Link Detection)

投稿者: msori 日時: 00:06 | パーマリンク

System and method for detecting unidirectional links

合衆国特許番号：6,765,877
特許登録日：2004年7月20日
発明者：Foschiano; Marco (San Jose, CA); Fung; Hei Tao (Santa Clara, CA); Annaamalai; Alagu (Cupertino, CA)
特許出願人：Cisco Technology, Inc.(San Jose, CA)
出願番号：386534
出願日：1999年8月30日

UDLD (Uni-Directional Link Detection) は、Catalyst シリーズのLAN スイッチに実装されている技術です。
Ethernet のポート、送信または受信ができなくなる状態を検知し閉塞させることで、障害範囲を局所化することを目的としています。

UDLD の詳細は、特集 - UDLD を究めるを参照してください。

気になるのは、出願者のCisco Technology, Inc. です。
シスコシステムズの正式な社名はCisco Systems, Inc. のはずです。

Cisco Technology, Inc. の企業情報を入手してみたのですが、Cisco Systems, Inc. の100%子会社であることと、本社所在地がCisco Systems, Inc. と同じ170 West Tasman Drive, San Jose, California であることを以上のことは分かりませんでした。

シスコの特許のほとんどで、出願者がCisco Technology, Inc. となっていることから考えると、おそらくシスコ社の知財を管理する会社ではないでしょうか。

余談ですが、UDLD は現在、IETF ドラフト (Informational)として公開されています(2006年3月現在、Revision 01。2006年8月にExpiration 予定)。

しかし、

とあるので、他社への普及を目指したものではなさそうです。

ファウンドリネットワークス社のスイッチにも、UDLD という機能があります。
マニュアルを読むと、シスコのUDLD と同じ目的の機能のようです。
しかし、シスコとの互換性はないと思われます。
仮に相互接続できたとしても、おそらくシスコはサポートしないでしょう。

投稿者: msori 日時: 00:04 | パーマリンク

USPTO が公開している特許の文書は、TIFF 形式の画像ファイルです。

TIFF に対応している画像表示ツールであればどれでも問題ありませんが、USPTO は、AlternaTIFF というフリーウェアの使用を推奨しています。

"Images" ボタン(上図のオレンジ色の矢印）をクリックすると、文書を閲覧するページが開きます。

画像を白黒反転させます。
見易いので、私は黒ベースの白抜き文字で閲覧しています。

AlternaTIFF のメニューが表示されます。

Open in New Window で、そのページを別ウィンドウで表示させると、読みやすい大きさになります。

投稿者: msori 日時: 00:01 | パーマリンク

UPTO は、日本の特許庁にあたる、アメリカ合衆国の連邦政府機関です

通信機器メーカの多くはアメリカ合衆国を本拠地としており、それらの企業が所持する特許は、UPTO のホームページ上で無料で閲覧することが出来ます。

UPTO (United States Patent and Trademark Office

トップページの左上、上図の赤枠で囲まれた部分に、特許情報を検索するページへのリンクがあります（その下のリンクからは、商標情報を検索できます）。

左上の緑色の部分から、登録済の特許を検索することが出来ます。
右上の黄色の部分では、出願されたものもまだ登録されていない案件を検索できます(※)。

本特集では左側（緑色）を使用します。

※
検索可能な登録案件は、2001年3月15日以降に出願された案件のみです。
アメリカ合衆国には、2001年まで出願早期公開制度がありませんでした。
特許が登録されるまでは、内容を第三者が閲覧することができず、同じ内容の出願がされることによる弊害が指摘されていました。
（出願が特許として登録されるまでには数年掛かるため、2番目以降の人は、自分が一番ではないことを知らないまま時間を無駄にすることになる）

2001年に改正された合衆国特許法により出願早期公開制度が採用され、出願から18ヶ月経過した案件は公開されることとなりました。

登録済の特許（左側の緑色）は、1790年以降すべて閲覧可能です。

Quick Search で、Assignee Name (出願者) に 会社名（Cisco Systems など）を入力して "Search" をクリックすると、その会社が出願して登録された特許の一覧が出力されます。

閲覧したい特許をクリックすると、内容が表示されます。

�@ United States Patent

合衆国特許番号。右側にある7桁の数字が特許番号です。

�A 発明者

通常、出願者(企業)の社員名が入ります。et alとある場合、複数人の発明者のうちの代表者であることを意味します。

�B 概要 (Abstract)

特許の概要です。

�C 発明者 (Inventors)

発明者全員の名前です。

�D 出願者 (Assignee)

特許を出願した人の名前が入ります。通常は、ここに企業名が入ります。

�E Appl. No.

出願番号

�F Filed

出願日

�G Current U.S. Class

特許のカテゴリ。スラッシュの左側がメインカテゴリで、右側がサブカテゴリです。カテゴリは、こちらで検索できます。。


�H 登録日

特許の登録日

そのほか、以下の項目があります。

References Cited

この特許が引用した、他の特許と資料

Claims

この特許が主張する項目。いわゆる請求項



投稿者: msori 日時: 23:54 | パーマリンク

ここで改めて言うまでもなく、通信技術は標準規格をベースとして成り立っています。

標準規格には、IETF やATM Forum といった業界標準（デファクトスタンダード）、ITU やJIS などの公的な標準（デジュールスタンダード）があります。

どのような規格であれその規格に則って設計されたシステムは、互換性が保証されているわけです（※）

※ 必ずしもそうは行かないのが世の常ですが・・・

完全に規格に則ったシステムであれば、だれが作ってもまったく同じものが出来ます。
つまり、没個性です。

国や自治体が提供するサービスであれば、それでも差し支えありませんが、営利企業の作るものには差別化（個性）が必要です。

多くのメーカは、標準規格をベースにして他社製システムとの互換性を保ちながら、独自機能を加えることで他社との差別化を図っています。

独自機能は、自社製品を売り込むための重要なセールスポイントです。
「うちの製品を使えば、こんなに便利になりますよ」というわけです。
他社にマネをされてしまうと、（そのメーカにとっては）価値がなくなってしまいます。

マネをされることを防ぐため、多くのメーカは独自機能を特許出願しています。
通信機器業界の巨人、シスコシステムズも例外ではありません。

本特集では、シスコシステムズを中心に、通信機器メーカが出願している特許をご紹介します。

通信機器メーカが出願している特許には、独自プロトコルや機器の設計手法、プログラミング手法に関するものなど、さまざまな種類があります。

今回は、実際に通信機器を扱っているエンジニアが実感しやすい、コマンドなどで設定可能な、つまり筐体の外から目に見える機能やプロトコルに関する特許を取り扱うこととします。

投稿者: msori 日時: 23:53 | パーマリンク

Vine Linux でサーバを構築するための情報を発信しているウェブサイトです。

ハードウェアのパーツ選定から、OS のインストール、サーバの構築まで網羅されています。

質問用の掲示板もあるので、困ったときは質問できますよ。

Windows のファイアウォールやアンチウィルスソフトの情報もあります。

VINE MEMO

投稿者: msori 日時: 09:47 | パーマリンク

本特集の第一回:スパニングツリーとルーティングプロトコルで、STP の目的はRoot Bridge(ルートブリッジ)への最短パスを探し出すことだ、とお話しました。

ルートブリッジへのパスが複数ある場合、最短パス以外を閉塞（ブロッキング）させることで、ループ状態を回避します。

複数のパスから最短パスを特定するための判断基準 (尺度)として、コストを用います。

ポートに設定されているコストを、Path Cost (パスコスト)と呼びます。
Root Bridge までのパス上に存在する各ブリッジのPath Cost を合計したものを、Root Path Cost (ルートパスコスト)と呼びます。

Root Bridgeは、ツリートポロジの基点となるブリッジです。このRoot Bridge をコスト0(ゼロ)とします。
Root Bridge からトポロジの周縁部に向かってブリッジを越えるたびに、コストを加算していきます。
あるブリッジからRoot Bridge へのパスが複数ある場合、加算されたコストを比較し、最もコストが小さいパスが選択され、そのほかのパスは閉塞されます。

Path Cost は、ブリッジの各ポートに設定される値です。

上図では、左側のBrige-A がRoot Bridge になっています。
右側のBridge-B のPort 1 と2 には、Path Cost がそれぞれ10 と20に設定されています。
この場合、Port 1のPath Cost の方がPort 2と比べて小さいので、Root Bridge (Bridge-A) までのコストが小さいと判断されます。
Path Cost は一台のブリッジに一つではなく、ポート毎に保持する値である点に注意してください。

Root Path Cost はブリッジを越えるたびに加算されます。
Root Bridge との間に他のブリッジが存在する場合、通過した全てのブリッジのコストを合計した値が、そのポートのRoot Path Cost となります。

Root Path Cost の加算は、Root Bridge からのデータ(※)を受信したポートで行われます。
上図で、Bridge-B のPort 2のコスト(5)が、加算の対象となっていないのはそのためです。

※
Root Bridge から送信される（他のブリッジにより中継される）データを、BPDU (Bridge Protocol Data Unit) と呼びます。
BPDU については、「STP を究める 基礎編 (9)Configuration BPDU (コンフィグレーションBPDU)のフォーマット」で説明します。

IEEE 802.1D では、ポートに設定可能なPath Cost を以下のように定めています。
(1998年版 IEEE 802.1D - Table 8.5 Path Cost Parameter Values より抜粋)

STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
これらの拡張仕様については、応用編にて説明する予定です。

投稿者: msori 日時: 17:36 | パーマリンク