Network Modeling Group                                        S.N.M.P.
Request for Comments: 7743                          National Museum of
Category: Experimental                 Emerging Science and Innovation
                                                          1 April 2004



              Modeling the Internet using Rolling Balls

Status of this Memo

   このメモは、2001年7月に開館した日本科学未来館におけるインターネット
   をモデル化した展示物について、制作過程における経緯を述べたものであ
   る。この展示物は実験的なものであり、実用を目的としたものではない。
   このメモの配布は無制限である。

Abstract

   我々は来館者にインターネットの仕組みをわかりやすく伝える展示物の構
   築についての検討を行なった。様々な検討の結果、IP(Internet Protocol) 
   によるパケット通信のモデル化に重点を置き、それを転がる玉(Rolling
   Balls)を用いた物理モデルによって表現することとした。モデル化におけ
   る議論および具体的な物理モデルにおける詳細を述べる。

Overview and Rational

   現実にあるシステムをどのようにモデル化することが、最もわかりやすく
   伝えることになるのだろうか。二つの原則を考えた。

   ・ブラックボックスをなくすこと
   ・シンプルであること

   現実にあるシステムは様々な構造が階層的に折り重なり、本当の構造と言
   える部分はユーザの視点からは見えないようになっている。しかしこのよ
   うな展示物においては、ブラックボックスにより隠されている部分を、目
   に見えるものとして表面に出すことが重要である。またその過程において、
   本質には関係無い要素については、思いきって簡略化する必要がある。イ
   ンターネットをモデル化した展示物として重要な事は、入力された情報が
   様々なルートを転送され最終的に出力されるまでの間を、一切ブラックボッ
   クスによって隠すことなく、見せてやることだと考えた。そこで、転がる
   玉を用いてデータの流れを表現し、最初から最後までデータの移動を目で
   追えるようなものという物理モデルにより表現することにした。また、来
   館者から見て隠されているところのないモデルとすることが重要な点で、
   全てを物理的な機構として実現するが目標ではない。簡素化することが重
   要な部分については、エレクトロニクスを含め適宜使用することとした。





S.N.M.P.                                                        [Page 1]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


   転がる玉による展示物そのものは昔から存在するが、それらは単純な物理
   法則に従い動くのみで、情報の流れが表現されているわけではない。今回、
   玉の流れそのものを電子による情報の流れのメタファーととらえ、それに
   より全体の機構が動くモデルとする。このモデルにおいては、どこかに全
   体を制御するようなコントローラは存在しない。

   以下の仕様において、モデルにおける一連の流れについての詳細を述べる。

Specifications

   モデルにおける全体の流れを概観すると以下のようになる。

   玉そのものが1ビットを表し、それが16個連なったものを1パケットと定義
   する。来館者は端末上で玉を並べることによりパケットを作成し、送信す
   ることができる。パケットは、LAN、ルータを通過し、適切な宛先である端
   末へと届く。受信されたパケットは表示装置によってデコードされ、文字
   が表示される。

   個々の要素について詳細を述べていく。

Bit Format

   白玉・黒玉という二種類の玉を用意し、1ビットを表現する。白と黒のどち
   らが0・1を表すかは恣意的に決定されるが、ここでは白が0、黒が1である
   ものと仮定する。玉は直径37mm、重さ34gのプラスチック製とする。

Packet Format

   1パケットは2バイトの長さからなる。1バイトがヘッダで、そこに連なる
   1バイトがデータとなる。1バイトは8ビットからなり、1パケットは2バイト
   (=16ビット)となる。1パケットは16ビットの完全固定長であるため、終端
   は定義されていない。玉のサイズから、1パケット長は592mm、重さは544g
   となる。

   パケットの例:

             +--Address--------------+--Data-----------------+

             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   1 packet  |○|●|○|○|○|○|●|○|●|○|●|●|○|○|○|●|
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+










S.N.M.P.                                                        [Page 2]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


Address Format

   それぞれの端末には、ネットワークアドレスとホストアドレスという二つ
   のアドレスが振られ、来館者はその二つのアドレスを参照し、端末から宛
   先アドレスを構成していく。アドレスのネットワーク部とホスト部は、そ
   れぞれ4ビットづつである。

                      +--Network--+--Host-----+
                      +--Address--+--Address--+

                      +--+--+--+--+--+--+--+--+
                      |○|●|○|○|○|○|●|○|
                      +--+--+--+--+--+--+--+--+

   エンコーディングは2進数ではなく、0の中のどこに1があるかで決定される。
   4ビットで4種類の状態を表すことができる。(何もない状態を含めると5種
   類である。)

Data Format

   データ部は1バイト(=8ビット)のバイナリによって表される。このデータは
   二種類の解釈がなされる可能性がある。一つは文字コード、もう一つはビッ
   トマップ画像データである。

   文字コードの場合は、ASCII [Cerf69]およびJIS X 0201 [JISX0201]のKana
   セットによって1バイトの文字がエンコードされる。受信端末はそれをデコー
   ドし、文字として表示する。使用可能コードはASCIIに属するアルファベッ
   ト・記号、およびJISで定義されたカタカナである。漢字キャラクタ、多言
   語化への対応は将来への課題である。

   また、1バイトの値をエンコードされた数値としてではなく、画像データの
   一部として解釈することもできる。その場合は8パケット分のデータが集ま
   ることによって、8×8の二値ビットマップ画像データが転送されることに
   なる。

   データ部が文字であるか、画像であるかを示すフラグは用意していない。
   受けとったデータの解釈は、受信者が行うものとする。

Network Topology

   展示空間内には、ルータが4基、LANが3基、端末が6台配置される。

   三つのルータが相互接続され、残りのルータはそのうちの一つのルータか
   ら間接接続されるというネットワーク・トポロジーである。このネットワー
   ク・トポロジは、1969年12月当時のARPANETのIMP接続トポロジを模してい
   る[RFC4]。それぞれのルータにはLANが接続されているが、一つのルータだ
   けは接続されていない。これにより接続が集約されたルータを表現してい
   る。ここでLANと呼ぶものは、概念的な意味でのローカルネットワークを表
   現したものであり、特にEthernetをモデル化したものではない。


S.N.M.P.                                                        [Page 3]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


   それぞれの端末はまずLANに接続されている。同様にルータもLANに接続さ
   れている。端末から発っせられたパケットは、まずLANを流れルータに行き
   つき、ルータ間を移動し、宛先となるネットワーク・アドレスのLANに入り、
   宛先となる端末へと到着する。

   それぞれのLANには、1〜3のネットワークアドレスが振られている。

   ネットワークアドレス対照表:

                        Bits    Network Address

                        0001    "1"
                        0010    "2"
                        0100    "3"

   ネットワークアドレスとホストアドレスの組により、端末のアドレスが
   決定される。

   端末アドレス対照表:

                     Bits        Terminal Address

                     00010001    "1-1"
                     00010010    "1-2"
                     00100001    "2-1"
                     00100010    "2-2"
                     01000001    "3-1"
                     01000010    "3-1"

Terminal Input Area

   端末は入力エリアと表示エリアにわかれている。少し傾斜のついた机のよ
   うな形をしており、下の部分に玉を保管する玉溜めが用意されている。

   入力は玉16個分の入力エリアに玉を並べていくことで行う。左半分がアド
   レス入力エリア、右半分がデータ入力エリアである。端末下にある玉溜め
   から白玉・黒玉をとりだし、入力エリアに並べていく。

   アドレス入力は、上記端末アドレス対照表に従い、送り先となる端末のア
   ドレスからビット列を参照し、アドレス入力エリアに玉を並べていく。同
   様にデータ部においてもコード表から送りたい文字を参照し、それに従い
   データ入力エリアに玉を並べていく。

   アドレス入力、データ入力を補助する仕組みが用意されている。端末には
   左右にダイヤルが設置され、左側のダイヤルを送りたいホストのアドレス
   に合わせるとアドレス入力エリアに対応した玉の並びが表示される。表示
   に従い、玉を並べることによってアドレスが入力される。同様に端末右側
   のダイヤルから送りたい文字を選び、データ入力エリアに表示された玉の
   並び通りに玉を置くことのより、データが入力される。


S.N.M.P.                                                        [Page 4]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


   データ入力エリアの上方には8パケット分の送りたいデータを貯めておくこ
   とができる入力バッファが用意される。ビットマップ画像データを送信す
   る場合はこの入力バッファを使用することができる。画像データ入力を補
   助する仕組みとして、何種類かの画像テンプレート板が用意される。

   入力エリアに玉を並べ終ったら、送信レバーを操作することにより、1パケッ
   ト分の玉がsend bufferに送られる。玉が16個以下の場合はレバーが作動し
   ない仕組みとなっている。send bufferでは、一旦玉が16個まとめられ、
   LANへと送られる。

   表示エリアについては、最後の段落で説明する。

LAN (Local Area Network)

   端末から送信されたパケットは、一旦send bufferに溜り、16個の固まりに
   まとめられる。send bufferからLANのCarrier Senseを行い、1パケット分
   の空きエリアがあるかどうかを見る。空きエリアが無い場合は待つ。空き
   エリアがある場合はその空きエリアにちょうどはまるよう玉を流す。その
   間、パケットの衝突が生じるのを防ぐため、次のパケットの流れはふさい
   でおく。

   LANの上は傾きがついており、玉はフリーランにより動く。LANの端の部分
   にはロータリーリフトが付いており、玉を上に上げる役目を果す。これに
   よりLANに入ったパケットはLAN上を回転しつづける。

   LANにはいくつかのアドレス検出器がついている。アドレスが一致した場合
   はその接続された機器へと方向を変え、流れていく。LANはRouterおよび
   Terminalに接続されている。

Address Matching

   アドレス一致検出は、二種類の動作を行う。ネットワークアドレス一致検
   出と、ホストアドレス一致検出。

   まず流れてきたパケットは、アドレス検出器のゲートにより一旦停止する。

   ネットワークアドレス一致検出だった場合は、先頭の4ビットをリファレン
   スと対照し、リファレンスビット列と検出対象のビット列とのANDをとり、
   これが0かどうかを判定する。これにより、複数のネットワークアドレスと
   の比較を一つの検出器により同時に判定できる。

   ホストアドレス一致検出だった場合は、同様にリファレンス・ビット列が
   置かれてあり、ネッワークアドレス、ホストアドレスを一組とした完全一
   致判定を行う。

   リファレンスと一致したと判定された場合、検出器はボールがのっている
   レールごと下に傾き、別のレールへと接続される。ビットの検出は、白玉・
   黒玉識別センサで行う。LEDと光センサの組で行う。



S.N.M.P.                                                        [Page 5]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


Router

   LANから自身のネットワークアドレスと違うパケットは、接続されたルータ
   へと流れる。

   Routerに入ったパケットは、一旦受信バッファにまとめられる。そこで
   Round Robin方式により排他制御され、転送されるパケットが順に選ばれる。
   転送されるパケットはリフトにより上方に上がり、ルータ最外郭のRouting
   Spiralをフリーランにより降りていく。スパイラルの途中では、LANにある
   ものと同様なアドレス一致検出器があり、そこで一旦停止し、判定する。
   行き先が無いパケットは、ルータの下にボールを溜める玉溜めが設けてあ
   り、そこに捨てられる。

Terminal Display Area

   端末の表示エリアは、縦8×横8のエリアで、送られてきたデータを保持す
   る。LANから受信したパケットは、1パケットづつ表示エリアに溜っていく。
   データ部の側にはデコードされた文字がLED表示装置により表示される。受
   信パケットは8個まで溜まり、9個目が送られてきたとき、最初の一つが破
   棄され、玉保管庫に落ちる。表示エリアをクリアするためのフラッシュボ
   タンも用意される。

Conclusion

   以上の一連の流れにより、端末から入力された情報がネットワークを通じ
   て目的となる端末へ到達するという動作が表現された。

Discussion

   モデル化における諸問題について、様々な議論を行なった。ここに列挙し
   ておく。

   ・輻輳は起りうるか。その場合パケットはどこに捨てられるのか。

   輻輳はありうる。ルータの出口(他のルータやLANへの経路への入り口)部
   分でそれ以上の玉が入らない場合、その場で捨てられ、ルータ下部の玉溜
   めにたまる。

   ・動的経路制御はあるうるか。どこかのルートが故障した場合の対応は。

   今回検討した物理モデルでは、動的経路制御の機構を実装することは、原
   理的には可能である。しかし、ボールの流れがそのままユーザの操作に起
   因する情報の流れを表現しているというシンプルさを損なわぬよう、動的
   経路制御のために独自の情報を表現の中に付加することは今回行なわない
   ものとする。

   ルートに障害が発生した場合は、関連するルータの判定機にセットされた
   リファレンス用の白黒の玉を手動で操作することにより、故障したルート
   を迂回する経路を静的に設定し、パケット転送を正常化させることができる。


S.N.M.P.                                                        [Page 6]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


   各ルータの判定機にセットされたリファレンス用の玉は、そのままそのルー
   タのルーティングテーブルを表現することになるため、その操作を係員、
   あるいは来館者が行えるようにしておくことは、ルーティング機構の理解
   を促すためにも有効と考えられる。

   ・TCP, DNSなどの上位層のプロトコルについては。

   今回のモデルでは上位層にあたるプロトコルについては扱わないものとす
   る。ワークショップなどで、TCPの仕組みを実際に自分で試してみることに
   よって理解する方法が考えられる。

   ・パケット長が2バイトである理由は。

   データ長を多バイト長としたり可変長とすることは、入力機構、ルーティ
   ング機構などのどの部分をとっても複雑となりすぎてしまう。今回は、で
   きるだけ機構をシンプルで最小限なものとするために2バイトとした。

Considerations

   以下のような検討課題が存在する。課題は優先順位に従い並べられている。

   1.  経路を変更可能とする

   ルータとそれぞれのネットワークとの接点では、物理的な指示機構によっ
   て制御されたルーティング・テーブルが設定されており、手動で設定しな
   おすことができる。来館者は適切なインストラクションの元に、このルー
   ティング・テーブルを書き換え、手動で経路制御することができる。動的
   経路制御を実体験により学ぶワークショップなども考えられる。

   2.  自動的に異なった経路を選択する仕組み

   故障した経路を回避するための迂回ルートの設定を、なんらかの形で自動化
   することはできないか。RIPのような、ネットワーク上を経路制御情報が
   流れる方法でなくてもよい。

   ある外部ネットワークへの経路が混雑している場合、自動的に次の経路を
   選択するような機構を導入し、混雑時の迂回ルート選択を可能とする機構
   を検討する。

   RIPのような経路制御情報がネットワーク上を流れるような機構については、
   その情報が来館者によるパケットと混乱する可能性があるため、採用しない。

   3.  マルチキャスト

   複数の端末に同時に届くパケットを定義できないか。電気信号なら簡単で
   あるが、物理的な玉では難しいかもしれない。





S.N.M.P.                                                        [Page 7]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


   マルチキャストはそもそも電気信号の特性から可能になっているもので、
   それを物理的な玉にあてはめることは非常に困難である。複製のための機
   構は複雑なものになると予想される。またより重要として、物理的な玉が
   複製されるということは直観に反する。そのため、今回はマルチキャスト
   については採用しないこととした。

References

      [RFC4] Shapiro, E., "Network Timetable", RFC 4, SRI,
      March 1969.

      [Cerf69] Cerf, V., "ASCII format for Network Interchange",
      RFC 20, UCLA, October 1969.

      [JISX0201] Japanese Standards Association, "Code for Information
      Interchange", JIS X 0201-1976.

Acknowledgements

   このメモは、制作チームの議論の過程から生み出されたものである。また、
   監修者である村井純教授には特に有益な助言をいただいた。ここに感謝の
   意を表する。

Security Considerations

   途中の経路において、来館者が手動によりパケットの進行を妨げる可能性
   があるが、これは意図した動作であり、ネットワークの障害を模したもの
   と考えられる。通信の経路は全て目に見える仕組みとなっているため通信
   の秘密を保持できないが、これも意図した動作である。






















S.N.M.P.                                                        [Page 8]

RFC 7743      Modeling the Internet using Rolling Balls     1 April 2004


Author of this Document

   Kouichirou Eto
   National Institute of Advanced Industrial Science and Technology
   Information Technology Research Institute

   EMail: 2004 at eto dot com

Author of the work

   Sensorium Network Modeling Project (S.N.M.P.)

   Ichiro Higashiizumi

   Satoshi Sugihara

   Takuya Shimada

   Ryuichi Iwamasa

   Kouichirou Eto






























S.N.M.P.                                                        [Page 9]























































































created by Kouichirou Eto, posted at 1 Apr 2004
home