RFC2009 日本語訳
2009 GPS-Based Addressing and Routing. T. Imielinski, J. Navas. November 1996. (Format: TXT=66229 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Imielinski
Request for Comments: 2009 J. Navas
Category: Experimental Rutgers University
November 1996
コメントを求めるワーキンググループT.イメリンスキーの要求をネットワークでつないでください: 2009年のJ.Navasカテゴリ: 実験的なラトガース大学1996年11月
GPS-Based Addressing and Routing
GPSベースのアドレシングとルート設定
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IANA Note:
IANAは以下に注意します。
This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. Please note that these addresses and names are not registered, assigned, allocated, or delegated to the use suggested here.
このドキュメントは地理的なアドレスで可能な実験について説明します。 それは、概念を理解する際に支援するのに具体的な実例として議論にいくつかの特定のIPアドレスとドメイン名を使用します。 これらのアドレスと名前をここに示された使用へ、登録もしませんし、割り当てもしませんし、割り当てもしませんし、代表として派遣もしません。
Table of Contents
目次
1. Introduction...................................... 2
1b. General Architecture...................... 3
1c. Scenarios of Usage: Interface Issues...... 3
2. Addressing Model.................................. 4
2a. Using GPS for Destination Addresses....... 5
3. Routing........................................... 7
3a. GPS Multicast Routing Scheme (GPSM)...... 7
3a-i. Multicast Trees................... 8
3a-ii. Determining the GPS Multicast
Addressing........................ 10
3a-iii. Building Multicast Trees.......... 11
3a-iv. Routing........................... 12
3a-v. DNS Issues........................ 12
3a-vi. Estimations....................... 12
3b. "Last Mile" Routing..................... 13
3b-i. Application Level Filtering....... 13
3b-ii. Multicast Filtering............... 13
3b-iii. Computers on Fixed Networks....... 14
3c. Geometric Routing Scheme (GEO)........... 14
3c-i. Routing Overview.................. 14
3c-ii. Supporting Long-Duration GPScasts. 16
3c-iii. Discovering A Router's Service Area 17
1. 序論… 2 1b。 一般構造… 3 1c。 用法のシナリオ: 問題を連結してください… 3 2. モデルに演説します… 4 2a。 送付先アドレスにGPSを使用します… 5 3. ルート設定… 7 3a。 GPSマルチキャストルート設定計画(GPSM)… 7 3a-i。 マルチキャスト木… 8 3a-ii。 GPSマルチキャストアドレシングを決定します… 10 3a-iii。 ビルマルチキャスト木… 11 3a-iv。 ルート設定… 12 3a-v。 DNS問題… 12 3a-vi。 見積り… 12 3b。 「最後のマイル」ルート設定… 13 3b-i。 アプリケーションレベルフィルタリング… 13 3b-ii。 マルチキャストフィルタリング… 13 3b-iii。 固定ネットワークのコンピュータ… 14 3c。 幾何学上ルート設定計画(GEO)… 14 3c-i。 ルート設定概観… 14 3c-ii。 長い持続時間GPScastsを支持します。 16 3c-iii。 ルータのサービスエリア17を発見します。
Imielinski & Navas Experimental [Page 1] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[1ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
3c-iv. Hierarchical Router Structure and
Multicast Groups.................. 18
3c-v. Routing Optimizations............. 19
3c-vi. Router-Failure Recovery Scheme.... 19
3c-vii. Domain Name Service Issues........ 20
4. Router Daemon and Host Library.................... 21
4a. GPS Address Library - SendToGPS()......... 21
4b. Establishing A Default GPS Router......... 22
4c. GPSRouteD................................. 22
4c-i. Configuration...................... 23
4d. Multicast Address Resolution Protocol (MARP) 23
4e. Internet GPS Management Protocol (IGPSMP). 24
5. Working Without GPS Information................... 25
5a. Users Without GPS Modules................. 25
5b. Buildings block GPS radio frequencies
What then?................................ 25
6. Application Layer Solution........................ 25
7. Reliability....................................... 26
8. Security Considerations........................... 27
9. References........................................ 27
10. Authors' Addresses................................ 27
3c-iv。 階層的なルータ構造とマルチキャストグループ… 18 3c-v。 ルート設定最適化… 19 3c-vi。 ルータ失敗回復計画… 19 3c-vii。 ドメイン名サービス問題… 20 4. ルータデーモンとホスト図書館… 21 4a。 GPSは図書館に演説します--SendToGPS() 21 4b。 デフォルトGPSルータを確立します… 22 4c。 GPSRouteD… 22 4c-i。 構成… 23 4d。 マルチキャストアドレス解決プロトコル(MARP)23 4e。 インターネットGPS経営者側は(IGPSMP)について議定書の中で述べます。 24 5. GPS情報なしで働いています… 25 5a。 GPSモジュールのないユーザ… 25 5b。 そしてビルブロックGPS無線周波数What? 25 6. 応用層溶液… 25 7. 信頼性… 26 8. セキュリティ問題… 27 9. 参照… 27 10. 作者のアドレス… 27
1. Introduction
1. 序論
In the near future GPS will be widely used allowing a broad variety of location dependent services such as direction giving, navigation, etc. In this document we propose a family of protocols and addressing methods to integrate GPS into the Internet Protocol to enable the creation of location dependent services such as:
GPSが指示付与、ナビゲーションなどの依存するサービスを広いバラエティーの位置に許しながら広く使用される近い将来 本書では私たちはプロトコルの家族を提案します、そして、位置の創造を可能にするためにインターネットプロトコルとGPSを統合する方法を記述して、扶養家族は以下としてそのようなものを修理します。
o Multicasting selectively only to specific geographical
regions defined by latitude and longitude. For example,
sending an emergency message to everyone who is currently
in a specific area, such as a building or train station.
o 緯度と経度によって選択的に特定の地理的な領域だけと定義されたマルチキャスティング。 例えば、現在、ビルか鉄道駅などの特定の領域にいる皆に緊急メッセージを送ること。
o Providing a given service only to clients who are within a
certain geographic range from the server (which may be mobile
itself), say within 2 miles.
o ある一定の地理的な範囲の中でサーバ(それ自体で可動であるかもしれない)から来ているクライアントだけに対する与えられたサービスを提供して、2マイル以内で言ってください。
o Advertising a given service in a range restricted way, say,
within 2 miles from the server,
o 範囲に当然のことのサービスの広告を出すと、サーバからのマイルはたとえば2のずっと中で制限されました。
Imielinski & Navas Experimental [Page 2] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[2ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
o Providing contiguous information services for mobile users
when information depends on the user's location. In
particular providing location dependent book-marks, which
provides the user with any important information which
happens to be local (within a certain range) possibly
including other mobile servers.
o 情報がユーザの位置によると、隣接の情報サービスを可動のユーザに提供します。 特に依存するブックマークを位置に提供しますことによると他のモバイルサーバを含むことにおいてたまたま地方である(ある一定の範囲の中の)どんな重要情報もユーザに提供される。
The solutions which we present are flexible (scalable) in terms of the target accuracy of the GPS. We also discuss cases when GPS cannot be used (like inside buildings).
私たちが提示する解決策はGPSの目標精度でフレキシブルです(スケーラブルな)。また、GPSを使用できないとき(ビルの中で好きです)、私たちはケースについて議論します。
The main challenge is to integrate the concept of physical location into the current design of the Internet which relies on logical addressing. We see the following general families of solutions:
主な挑戦は論理的なアドレシングを当てにするインターネットの現在のデザインと物理的な位置の概念を統合することです。 私たちは解決策の以下の一般的な家族を見ます:
a) Unicast IP routing extended to deal with GPS addresses
a) GPSアドレスに対処するために広げられたユニキャストIPルーティング
b) GPS-Multicast solution
b) GPS-マルチキャスト解決策
c) Application Layer Solution using extended DNS
c) 拡張DNSを使用するアプリケーションLayerソリューション
The first two solutions are presented in this memo. We only sketch the third solution.
最初の2つの解決策がこのメモに提示されます。 私たちは3番目の解決策をスケッチするだけです。
1b. General Architecture
1b。 一般構造
We will assume a general cellular architecture with base stations called Mobile Support Stations (MSS). We will consider a wide variety of cells, including outdoor and indoor cells. We will discuss both cases when the mobile client has a GPS card on his machine and cases when the GPS card does not work (i.e. - inside buildings).
私たちは基地局がモバイルSupport駅(MSS)と呼ばれている一般的なセル構造を仮定するつもりです。 私たちは野外の、そして、屋内のセルを含むさまざまなセルを考えるつもりです。 GPSカードが動作しないと私たちが可動のクライアントが彼のマシンの上のGPSカードを持っているときのケースとケースの両方について議論するつもりである、(すなわち--、内面のビル)
We will assume that each MSS covers a cell with a well defined range specified as a polygon of spatial coordinates and that the MSS is aware of its own range.
私たちは各MSSが空間的な座標の多角形として指定されるよく定義された範囲でセルを覆って、MSSがそれ自身の範囲を意識していると思うつもりです。
1c. Scenarios of Usage and Interface Issues
1c。 用法とインタフェース問題のシナリオ
Below, we list some possible scenarios of usage for the geographic messaging.
以下では、私たちが地理的なメッセージングのために用法のいくつかの可能なシナリオを記載します。
Consider an example situation, of an area of land near a river. During a severe rain storm, the local authorities may wish to send a flood warning to all people living within a hundred meters of the river.
川の近くで陸の領域の例の状況を考えてください。激しい暴風雨の間、地方公共団体は川の100個のメーターの中で暮らすすべての人々に洪水警報を送りたがっていてもよいです。
Imielinski & Navas Experimental [Page 3] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[3ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
For the interface to such messaging system we propose to use a zoom- able map similar to the U.S. Census Bureau's Tiger Map Service. This map would allow a user to view a geographical area at varying degrees of magnitude. He could then use a pointing device, such as a mouse, to draw a bounding polygon around the area which will receive the message to be sent. The computer would then translate the drawn polygon into GPS coordinates and use those coordinates when sending and routing the message. Geographical regions specified using this zoom-able map could be stored and recalled at a later time. This zoom-able map is analogous to the IP address books found in many email programs.
そのようなメッセージシステムへのインタフェースに関しては、私たちは、米国勢調査局のタイガーMap Serviceと同様のズームできる地図を使用するよう提案します。 この地図で、ユーザは異なった度の大きさで地理的な領域を見ることができるでしょう。 そして、彼は、送られるべきメッセージを受け取る領域の周りの制限多角形を描くのにマウスなどのポインティング・デバイスを使用できました。 メッセージを送って、発送するとき、コンピュータは、次に、描かれた多角形をGPS座標に翻訳して、それらの座標を使用するでしょう。 後でこのズームできる地図を使用することで指定された地理的な領域は、格納して、思い出すことができました。 このズームできる地図は多くのメールプログラムで見つけられたIPアドレス帳に類似しています。
To continue with the above example, local officials would call up a map containing the river in danger of overflowing. They would then hand-draw a bounding polygon around all of the areas at least a hundred yards from the river. They would specify this to be the destination for a flood warning email to all residents in the area. The warning email would then be sent. Similar applications include traffic management (for example, reaching vehicles which are stuck in traffic) and security enforcement.
上記の例を続行するために、地方公務員はオーバフローという危険が存在川を含む地図を呼び出すでしょう。 次に、彼らは手で川から少なくとも100ヤード離れたところの領域のすべて周りの制限多角形を描くでしょう。それらは、その領域のすべての居住者への洪水警告メールのための目的地になるようにこれを指定するでしょう。 そして、警告メールを送るでしょう。 同様のアプリケーションは輸送管理(例えば、渋滞にはまる乗り物に達する)とセキュリティー施行を含んでいます。
Other applications involve general client server applications where servers are selected on the basis of the geographic distance. For example, one may be interested in finding out all car dealers within 2 miles from his/her location. This leads to an extension of the Web concept in which location and distance play important roles in selecting information. We are currently in the process of implementing location dependent book-marks (hot lists) in which pages associated with static and mobile servers which are present within a certain distance from the client are displayed on the client's terminal.
他のアプリケーションはサーバが地理的な距離に基づいて選択される一般的なクライアントサーバ・アプリケーションにかかわります。 例えば、その人の位置から2マイル以内ですべての自動車売買業者を見つけたがっているかもしれません。 これは位置と距離が情報を選択することにおける重要な役割を果たすウェブ概念の拡大に通じます。 現在、ある一定の距離の中にクライアントから存在している静的でモバイルのサーバに関連しているページがクライアントの端末で表示される位置の依存するブックマーク(ホットリスト)を実行することの途中に私たちはいます。
2. Addressing Model
2. アドレシングモデル
Two-dimensional GPS positioning offers latitude and longitude information as a four dimensional vector:
二次元GPS位置決めは4の次元ベクトルとして緯度と経度情報を提供します:
<Direction, hours, minutes, seconds>
<指示、何時間もの、数分、秒>。
where Direction is one of the four basic values: N, S, W, E; hours ranges from 0 to 180 (for latitude) and 0 to 90 for longitude, and, finally, minutes and seconds range from 0 to 60.
Directionが4つの基礎価格の1つであるところ: N、S、W、E。 何時間も0から180(緯度のための)、経度への0〜90、および最終的に数分に変化します、そして、秒は0〜60まで変化します。
Thus <W, 122, 56, 89> is an example of longitude and <N, 85, 66, 43> is an example of latitude.
したがって、<W、122、56、89>は経度に関する例です、そして、<N、85、66、43>は緯度に関する例です。
Imielinski & Navas Experimental [Page 4] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[4ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Four bytes of addressing space (one byte for each of the four dimensions) are necessary to store latitude and four bytes are also sufficient to store longitude. Thus eight bytes total are necessary to address the whole surface of earth with precision down to 0.1 mile! Notice that if we desired precision down to 0.001 mile (1.8 meters) then we would need just five bytes for each component, or ten bytes together for the full address (as military versions provide).
スペース(それぞれの4つの寸法のための1バイト)を4バイトの記述するのが緯度を格納するのに必要です、そして、また、4バイトも、経度を格納するために十分です。 したがって、合計でバイトがなる8が、精度で全体の地表を0.1マイルまで記述するのに必要です! 私たちが精度を0.001マイル(1.8メーター)まで望むなら、ちょうど5バイトを各コンポーネントに必要とするか、または完全なアドレスのために一緒に10バイトを必要とするのに注意してください(軍事のバージョンが提供されるとき)。
The future version of IP (IP v6) will certainly have a sufficient number of bits in its addressing space to provide an address for even smaller GPS addressable units. In this proposal, however, we assume the current version of IP (IP v4) and we make sure that we manage the addressing space more economically than that. We will call the smallest GPS addressable unit a GPS-square.
確かに、それがさらに小さいGPSアドレス可能単位アドレスを提供するためにスペースを記述する際にIP(IP v6)の将来のバージョンは十分な数のビットを持つでしょう。 しかしながら、この提案では、私たちはIP(IP v4)の最新版を思います、そして、アドレシングスペースをそれより経済的に管理するのを確実にします。 私たちは、最も小さいGPSアドレス可能単位をGPS-正方形と呼ぶつもりです。
2a. Using GPS for Destination Addresses
2a。 送付先アドレスにGPSを使用します。
A destination GPS address would be represented by one of the following:
送付先GPSアドレスは以下の1つによって表されるでしょう:
o Some closed polygon such as:
o 或るものは以下などの多角形を閉じました。
circle( center point, radius )
円(天元、半径)
polygon( point1, point2, point3, ... , pointn)
多角形(point1、point2、point3、…、pointn)
where each point would be expressed using GPS-square
addresses. This notation would send a message to anyone
within the specified geographical area defined by the closed
polygon.
各ポイントがGPS-正方形アドレスを使用することで言い表されるだろうところで。 この記法は閉じている多角形によって定義された指定された地理的な領域の中でメッセージをだれにも送るでしょう。
o site-name as a geographic access path
o 地理的なアクセス経路としてのサイト名
This notation would simulate the postal mail service. In
this manner, a message can be sent to a specific site by
specifying its location in terms of real-world names
such as the name of a specific site, city, township,
county, state, etc. This format would make use of the
directory service detailed later.
この記法は郵便サービスをシミュレートするでしょう。 この様に、特定のサイト、都市、郡区、カウンティー、状態などの名前などの本当の世界名で位置を指定することによって、特定のサイトにメッセージを送ることができます。 この形式は後で詳細な電話番号案内を利用するでしょう。
Imielinski & Navas Experimental [Page 5] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[5ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
For example, if we were to send a message to city hall in Fresno, California, we could send it by specifying either a bounding polygon or the mail address. If we specify a bounding polygon, then we could specify the GPS limits of the city hall as a series of connected lines that form a closed polygon surrounding it. Since we have a list of connected lines, we just have to record the endpoints of the lines. Therefore the address of the city hall in Fresno could look like:
例えば、私たちがフレスノ(カリフォルニア)の市役所にメッセージを送るなら、制限多角形か郵便の宛先のどちらかを指定することによって、それを送ることができるでしょう。 制限多角形を指定するなら、私たちはそれを囲む閉じている多角形を形成する一連の関連線として市役所のGPS限界を指定するかもしれません。 関連線のリストがあるので、私たちはただ線の終点を記録しなければなりません。 したがって、フレスノの市役所のアドレスに似ることができました:
polygon([N 45 58 23, W 34 56 12], [N 23 45 56, W 12 23 34], ... )
多角形[N、45 58 23、W34 56 12] [N23 45 56、W12 23 34]…、)
Alternatively, since city hall in Fresno is a well-defined geographical area, it would be simpler to merely name the destination. This would be done by specifying "postal-like" address such as city_hall.Fresno.California.USA.
あるいはまた、フレスノの市役所が明確な地理的な領域であるので、単に目的地を命名するのは、より簡単でしょう。 都市_hall.Fresno.California.USAなどの「郵便のような」アドレスを指定することによって、これをするでしょう。
For "ad hoc" specified areas such as, say a quad between 5th and 6th Avenue and 43 and 46 street in New York, the polygon addressing will be used.
あれほど、「臨時に」という指定された領域に、言ってください。ニューヨークの5番目と、第6アベニューと、43と46通りの間の回路であり、多角形アドレシングは使用されるでしょう。
Unfortunately, we will not be able to assume that we have enough addressing space available in the IP packet addressing space to address all GPS squares. Instead we will propose a solution which is flexible in terms of the smallest GPS addressable units which we call atoms. In our solution, a smaller available addressing space (in the IP packet) will translate into bigger atoms. Obviously, we can use as precise addressing as we want to in the body of the geographic messages - the space limitations apply only to the IP addressing space.
残念ながら、私たちは、スペースを記述するIPパケットで利用可能なすべてのGPS正方形を記述できるくらいのアドレシングスペースがあると仮定できないでしょう。 代わりに、私たちは私たちが原子と呼ぶ中で最も小さいGPSアドレス可能単位でフレキシブルな解決策を提案するつもりです。--記述したいと思うので地理的なメッセージのボディーに記述して、明らかに、私たちが正確であるとして使用できる解決策(スペース(IPパケットの)が、より大きい原子に翻訳するより小さい利用可能なアドレシング)では、宇宙制限はスペースを記述するIPだけに適用されます。
By a geographic address we mean an IP address assigned to a geographic area or point of interest. Our solution will be flexible in terms of the geographic addressing space.
地理的なアドレスで、私たちは興味がある地理的な領域かポイントに割り当てられたIPアドレスを言っています。 地理的なアドレシングスペースには変更の余地が私たちの解決策にあるでしょう。
Below, we will use the following two terms:
以下では、私たちが次の2つの用語を使用するつもりです:
o Atoms: for smallest geographic areas which have
geographic address.
o 原子: 地理的なアドレスを持っている最も小さい地理上の区域に。
Thus, atoms could be as small as GPS squares but could be
larger
したがって、原子は、同じくらい小さいかもしれませんが、GPSが二乗するより大きいかもしれません。
o Partitions: These are larger, geographical areas, which will
also have a geographic address. A state, county, town etc.
may constitute a partition. A partition will contain a number
of atoms.
o パーティション: これらは、より大きくて、地理的な地域です。(その地域には、また、地理的なアドレスがあるでしょう)。 状態、町のカウンティーなどはパーティションを構成するかもしれません。 パーティションは原子数を含むでしょう。
Imielinski & Navas Experimental [Page 6] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[6ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Here are some examples of possible atoms and partitions:
ここに、可能な原子とパーティションに関するいくつかの例があります:
o A rectangle, defined by truncating either longitude or
latitude part of the GPS address by skipping one or more
least significant digits
o GPSアドレスの経度か緯度部分のどちらかに1つ以上の最下位桁をスキップすることによって先端を切らせることによって定義された長方形
o A circle, centered in a specific GPS address with a
prespecified radius.
o 特定のGPSアドレスの前指定された半径で中心に置かれた円。
o Irregular shapes such as administrative domains: states,
counties, townships, boroughs, cities etc
o 管理ドメインなどの異形: 州、カウンティー、郡区、都市の自治区など
Partitions and Atoms (which are of course special atomic partitions) will therefore have geographic addresses which will be used by routers. Areas of smaller size than atoms, or of "irregular shape" will not have corresponding geographic addresses and will have to handled with the help of application layer.
したがって、パーティションとAtoms(もちろん特別な原子パーティションである)には、ルータによって使用される地理的なアドレスがあるでしょう。 対応する地理的なアドレスと意志が意志で応用層の助けで扱われるのに持っていない原子より小さいサイズ、または「異形」の領域。
3. Routing
3. ルート設定
Let us now describe the suggested routing schemes responsible for delivering a message to any geographical destination.
現在、どんな地理的な目的地にも伝言をもたらすのに原因となる提案されたルーティング計画について説明しましょう。
We will distinguish between two legs of the connection from the sender to the receiver: the first leg from the sender to the MSS (base station) and the second leg from the MSS to the receiver residing in its cell. Our two solutions will differ on the first leg of the connection and use the same options for the second leg, which we call "last mile".
私たちは送付者から受信機までの接続の2つの行程を見分けるつもりです: 最初の送付者からMSS(基地局)までの脚と2番目はMSSからセルの中に住んでいる受信機まで急いで歩かれます。 私たちの2つの解決策が、接続の最初の行程について異なる意見をもって、2番目の脚に同じオプションを使用するでしょう。(私たちはそれを「最後のマイル」と呼びます)。
3a. GPS-Multicast Routing Scheme
3a。 GPS-マルチキャストルート設定計画
Here, we discuss the first leg of routing: from the sender to the MSS. We start with the multicasting solution.
ここで、私たちはルーティングの最初の脚について議論します: 送付者からMSSまで。 私たちはマルチキャスティング解決策から始まります。
Each partition and atom is mapped to a multicast address. The exact form of this mapping is discussed further in this subsection. We first sketch the basic idea.
各パーティションと原子はマルチキャストアドレスに写像されます。 この小区分で、より詳しくこのマッピングの正確なフォームについて議論します。 私たちは最初に、基本的な考え方についてスケッチします。
Imielinski & Navas Experimental [Page 7] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[7ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
This solution provides flexible mix of the multicast and application level filtering for the geographic addressing. The key idea here is to approximate the addressing polygon of the smallest partition which contains it and using the multicast address corresponding to that partition as the IP address of that message. The original polygon is a part of the packet's body and the exact matching is done on the application layer in the second leg of the route.
この解決策はマルチキャストとアプリケーションレベルフィルタリングのフレキシブルなミックスを地理的なアドレシングに提供します。 ここの主要な考えはそのメッセージのIPアドレスとしてそれを含む最も小さいパーティションとそのパーティションに対応するマルチキャストアドレスを使用するアドレシング多角形に近似することです。 オリジナルの多角形はルートの2番目の脚で応用層でパケットのボディーと正確なマッチングの一部をするということです。
How is the multicast routing performed?
マルチキャストルーティングはどのように実行されますか?
3a-i. Multicast Trees
3a-i。 マルチキャスト木
The basic idea for the first level of routing using multicast is to have each base station join multicast groups for all partitions which intersect its range. Thus, MSS is not only aware of its own range but also has a complete information about system defined partitions which its range intersects. This information can be obtained upon MSS installation, from the geographic database stored as a part of DNS.
マルチキャストを使用する最初のレベルのルーティングのための基本的な考え方は各基地局に交差するすべてのパーティションをマルチキャストグループと一緒に楽しませることです。その範囲。 その結果、MSSには、それ自身の範囲を意識しているだけではありませんが、システムの定義されたパーティションに関して完全な情報がまたある、どれ、範囲は横切られるか。 MSSインストールのときにDNSの一部として格納された地理的なデータベースからこの情報を得ることができます。
If the proper multicast trees are constructed (using for example link state multicast protocol) than the sender can simply determine the multicast address of the partition which covers the original polygon he wants to send his message to, use this multicast address as the address on the packet and put the original polygon specification into the packet content. In this way, multicast will assure that the packet will be delivered to the proper MSS.
適切なマルチキャスト木が送付者が単に組み立てることができるより組み立てられるなら(例えばリンク州のマルチキャストプロトコルを使用して)、彼のメッセージを送る彼が欲しいオリジナルの多角形をカバーするパーティションのマルチキャストアドレスを決定してください、そして、パケットに関するアドレスとしてこのマルチキャストアドレスを使用してください、そして、当初の多角形仕様をパケット含有量に入れてください。 このように、マルチキャストは、パケットが適切なMSSに渡されることを保証するでしょう。
Example
例
For instance the MSS in New Brunswick may have its range intersect the following atoms and partitions: Busch, College Avenue, Douglass and Livingston Campuses of Rutgers University (atoms), New Brunswick downtown area (atom), the Middlesex county partition and the NJ state partition. Each of these atoms and partitions will be mapped into a multicast address and the New Brunswick's MSS will have to join all such multicast groups.
例えば、ニューブランズウィックのMSSが範囲を横切らせるかもしれない、以下の原子とパーティション: ブッシュ、Collegeアベニュー、ラトガース大学(原子)のダグラスとリビングストンCampuses、ニューブランズウィック繁華街(原子)、ミドルセックスカウンティーのパーティション、およびニュージャージーはパーティションを述べます。 それぞれのこれらの原子とパーティションはマルチキャストアドレスに写像されるでしょう、そして、ニューブランズウィックのMSSはそのようなすべてのマルチキャストグループに加わらなければならないでしょう。
The message will be then specified and sent as follows:
以下の通りメッセージを次に、指定して、送るでしょう:
The user will obtain the map of the New Brunswick area possibly from the DNS extended properly with relevant maps. He will specify the intended destination by drawing a polygon on the map which will be translated into the sequence of coordinates. In the same time the polygon will be "approximated" by the smallest partition which contains that polygon. The multicast address corresponding to that partition will be the IP address for packets carrying our message. The exact destination polygon will be a part of each packet's body. In this way the packet will be delivered using multicast routing to
ユーザはことによると関連地図で適切に広げられたDNSからニューブランズウィックの地域の地図を入手するでしょう。 彼は、座標の系列に翻訳される地図に多角形を引き込むことによって、意図している目的地を指定するでしょう。 同時間、その多角形を含む最も小さいパーティションで多角形は「近似されるでしょう」。 そのパーティションに対応するマルチキャストアドレスは私たちのメッセージを伝えるパケットのためにIPアドレスになるでしょう。 正確な目的地多角形は各パケットの身体の一部になるでしょう。 パケットが渡された使用しているマルチキャストルーティングであるために望んでいるこのように
Imielinski & Navas Experimental [Page 8] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[8ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
the set of MSS which are members of the specified multicast group (that is all MSS whose ranges intersect the given partition). Each such MSS now will follow the "last mile" routing which is described in detail, further in the proposal. Briefly speaking, the MSS could then multicast the message further on the same multicast address and the client will perform the final filtering o application layer, matching its location (obtained from GPS) with the polygon specified in the packet's body. Other solutions based entirely on multicasting are also possible as described below.
指定されたマルチキャストグループのメンバーであるMSSのセット、(それ、範囲が横切られるすべてのMSSが与えられたパーティションである、) そのような各MSSは今、提案で詳細に、より詳しく説明される「最後のマイル」ルーティングに従うでしょう。 簡潔に話すなら、MSSは話すかもしれません、次に、メッセージが同じマルチキャストアドレスとクライアントの上で促進するマルチキャストは最終的なフィルタリングo応用層を実行するでしょう、位置(GPSから、得る)をパケットのボディーで指定される多角形に合わせて。 また、マルチキャスティングに完全に基づく他の解決策も以下で説明されるように可能です。
End_Example
終わり_例
However, things cannot be as simple as described. For such a large potential number of multicast groups if we build entire multicast trees, the routing tables could be too large. Fortunately it is not necessary to build complete multicast trees. Indeed, it in not important to know precise location of each atom in California, from a remote location, say in NJ.
しかしながら、いろいろなことは説明されるのと同じくらい簡単であるはずがありません。 多くのマルチキャストグループにおいて、私たちが全体のマルチキャスト木を建てるなら、経路指定テーブルは大き過ぎるかもしれません。 幸い、完全なマルチキャスト木を建てるのは必要ではありません。 本当に、それは重要でないところでカリフォルニアのそれぞれの原子の正確な位置がニュージャージーで離れた場所から言うのを知っています。
Thus, we modify our simple solution by implementing the following intuition:
したがって、私たちは以下の直観を実行することによって、簡単な解決策を変更します:
The smaller is the size of the partition (atom) the more locally is the information about that partition (atom) propagated.
パーティション(原子)のサイズが小さければ小さいほど、そのパーティション(原子)の情報は、より局所的に伝播されますか?
Thus, only multicast group membership for very large partitions will be propagated across the whole country.
非常に大きいパーティションのためのマルチキャストグループ会員資格だけが全国に伝播されるでしょう。
For example, a base station in Menlo Park, California can intersect several atoms ) and several larger which cover Menlo Park, such say a partition which covers the entire San Mateo county, next which cover the entire California and finally next which may cover the entire west coast. This base station will have to join multicast groups which correspond to all these rectangles. However, only the information about multicast group corresponding to the West Coast partition will be propagated to the East Coast routers.
例えば、メンローパーク(カリフォルニア)の基地局が横切られることができる、いくつかの原子)、数個、多大である、メンローパーク、たとえば、全体のサンマテオカウンティーを覆うそのようなパーティション、全体のカリフォルニアを覆う次、および最終的に全体の西海岸を含むかもしれない次を含んでいる。 この基地局はこれらのすべての長方形に一致しているマルチキャストグループに加わらなければならないでしょう。 しかしながら、西海岸のパーティションへのマルチキャストグループ対応の情報だけが東海岸ルータに伝播されるでしょう。
However, a simple address aggregation scheme in which only a "more significant portion" of address propagates far away would not work. Indeed, in this case a remote router, say in NJ, could have several aggregate links leading to California - in fact, in the worst case, all its links could point to California since it could have received a routing information to some location in California on any of those links.
しかしながら、アドレスの「より重要な部分」だけ、が遠くに伝播される簡単なアドレス集合計画はうまくいかないでしょう。 本当に、この場合リモートルータ、ニュージャージーで言って、数個の集合リンクにカリフォルニアに通じさせることができました--それらのリンクのどれかにカリフォルニアのいくらかの位置にルーティング情報を受け取ったかもしれないので、事実上、最悪の場合には、すべてのリンクがカリフォルニアを示すかもしれません。
To avoid this, for each partition we distinguish one or a few MSS which act as designated router(s) for that partition. For example, the California partition, may have only three designated routers, one
各パーティションのためにこれを避けるために、私たちはそのパーティションのためにルータに指定されるように行動する1かいくつかのMSSを区別します。 例えば、カリフォルニアのパーティション、ルータ、1つに3だけを指定させるかもしれません。
Imielinski & Navas Experimental [Page 9] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[9ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
in Eureka, another in Sacramento and yet another in LA. Only the routing entries from the designated routers would be aggregated into the aggregate address for California. Information coming from other city routers will simply be dropped and not aggregated at all. This, in addition to a standard selection of the shortest routes, would restrict the number of links which lead to an aggregate address. In particular, when there is only one designated router per partition, there would only be one aggregate link in any router. This could lead to non-optimal routing but will solve the problem of redundant links.
ユーレカ計画、LAのサクラメントにもかかわらず、別のものの別のもので。 代表ルータからのルーティングエントリーだけがカリフォルニアへの集合アドレスに集められるでしょう。 他の都市のルータから来る情報は、絶対に落とされて、全く集められないでしょう。 最も短いルートの標準の品揃えに加えて、これは集合アドレスに通じるリンクの数を制限するでしょう。 1パーティションあたり1つの代表ルータしかないとき、どんなルータにも特に、1個の集合リンクしかないでしょう。 これは、非最適ルーティングに通じることができましたが、余分なリンクの問題を解決するでしょう。
Even with a designated routers, it may happen that the same packet will arrive at a given base station more than once due to different alternative routes. Thus, a proper mechanism for discarding redundant copies of the same packet should still be in place. In fact, due to the possible intersections between ranges of the base stations the possibility of receiving redundant copies of the same packets always exist and has to be dealt with as a part of any solution.
代表ルータがあっても、同じパケットが異なった代替のルートのため一度より多くの与えられた基地局に到着するのは起こるかもしれません。 したがって、余分なコピーの同じパケットを捨てるための適切なメカニズムが適所にまだあるはずです。 事実上、受信の余分なコピーの同じパケットの可能性は、基地局の範囲の間の可能な交差点のため、いつも存在していて、どんな解決策の一部としても対処されなければなりません。
3a-ii. Determining the geographic Multicast Addressing
3a-ii。 地理的なMulticast Addressingを決定します。
Here we describe more specifically, the proposed addressing scheme and the corresponding routing.
ここで、私たちは明確に提案されたアドレシング計画と対応するルーティングについてさらに説明します。
The addressing will be hierarchical. We will use the following convention - each multicast address corresponding to a partitions or an atoms will have the following format:
アドレシングは階層的になるでしょう。 私たちは以下のコンベンションを使用するつもりです--パーティションか原子に対応するそれぞれのマルチキャストアドレスには、以下の形式があるでしょう:
1111.GPS.S.C.x
1111. GPS.S.C.x
where GPS is the specific code corresponding to the geographic addressing subspace of the overall multicast addressing space. The S, C and x parts are described below:
GPSがスペースを記述する総合的なマルチキャストの地理的なアドレシング部分空間に対応する特定のコードであるところ。 S、C、およびxの部品は以下で説明されます:
S - Encoding of the state.
Each state partition will have the address S/0/0.
S--状態はコード化されます。 それぞれの州のパーティションには、アドレスS/0/0があるでしょう。
C - County within a state.
Each county partition having the address S/C/0.
C--州の中のカウンティー。 アドレスS/C/0があるそれぞれのカウンティーのパーティション。
x - Atom within a county.
x--カウンティーの中の原子。
where 0's refer to the sequences of 0 bits on positions corresponding to the "C part" and "x part" of address.
0がアドレスの「C一部」と「x部分」に対応する位置の0ビットの系列を呼ぶところ。
For example if GPS part is 6 bit,s which gives 1/64 of existing multicast addresses to the geographic addressing we have 22 bits left. The S part will take first 6 bits, C part next 6 bits (say) and then the next 10 bits encode different atoms (within a county).
例えば、GPS部分が6ビットであるなら、私たちが22ビット持っている地理的なアドレシングに1/64の既存のマルチキャストアドレスを与えるsがいなくなりました。 S部分が最初の6ビット取って、C一部が次の6ビット(言う)であり、次に、次の10ビットのエンコードは異なった原子(カウンティーの中で)です。
Imielinski & Navas Experimental [Page 10] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[10ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Thus, in our terminology the proposed addressing scheme has two types of partitions: states and counties.
したがって、私たちの用語では、提案されたアドレシング計画は2つのタイプのパーティションを持っています: 州とカウンティー。
We will assume that the GPS network will consist of all base stations (MSS) in addition the rest of the fixed network infrastructure. The designated GPS routers however, will only be selected from the population of MSS. Specifically, there will be state dedicated and county dedicated routers.
私たちは、GPSネットワークがすべての基地局(MSS)からさらに、成ると思うつもりです。固定ネットワークインフラの残り。 しかしながら、GPSルータに指定されて、MSSの人口から選択されるだけでしょう。 捧げられた州とカウンティーがルータを捧げたという明確に、そこでは、ことでしょう。
The concept of the designation will be implemented as follows. From the set of all MSS, only certain MSS will play a role of designated routers for county and state partitions. Non-designated MSS will only join multicast groups which correspond to the GPS atoms but not GPS partitions that they intersect. The MSS which is a designated router for a county partition will join the multicast group of the county in which it is located, but not the state. Finally the state designated router will also join the multicast address corresponding to the state it is located in.
名称の概念は以下の通り実行されるでしょう。 すべてのMSSのセットから、あるMSSだけがカウンティーと州のパーティションのために代表ルータの役割を果たすでしょう。 非指定されたMSSはGPSパーティションではなく、GPS原子に一致しているマルチキャストグループに加わるだけでしょう。それらは交差しています。 カウンティーのパーティションのための代表ルータであるMSSは状態ではなく、それが位置しているカウンティーのマルチキャストグループに加わるでしょう。 また、最終的に州の代表ルータはそれが位置している状態に対応するマルチキャストアドレスを接合するでしょう。
3a-iii. Building Multicast Trees
3a-iii。 ビルマルチキャスト木
We assume that each router has geographic information attached to it - in the same format as we use for multicast mapping, S/C/x - it encodes the atom that contains the router.
私たちは、各ルータで地理的な情報をそれに添付すると思います--同じ形式に、マルチキャストに私たちのようにマッピングを使用してください、S/C/x--それはルータを含む原子をコード化します。
The multicast tree is built by a router propagating its multicast memberships to the neighboring routers. A given router will only retain certain addresses though, to follow the intuition of not retaining a specific information which is far away.
マルチキャスト木はマルチキャスト会員資格を隣接しているルータに伝播するルータによって建てられます。 もっとも、与えられたルータは、ほど遠い特殊情報を保有しない直観に続くようにあるアドレスを保有するだけでしょう。
This is done as follows: the router (not necessarily the MSS based router) with the address S/C/x will only retain addresses about S'/0/0, S/C'/0 for S' and C' different from S and C and S/C/x for all x. Thus, it will drop all the addresses of the form S'/C'/y for all S' different that S except those with C'=0 and y=0, as well as all the addresses of the form S/C'/y with C' different from C except those with y=0. Hence, these addresses will not be forwarded any further either.
これは以下の通り完了しています: 'S/C/xが保有するだけであるアドレスがあるルータ(必ずMSSのベースのルータであるというわけではない)はすべてのxのためのS、C、およびS/C/xと異なったSとC'のためにS'/0/0、およそ分のS C'/0を記述します。 'その結果、そのS CがあるSのすべての異なったそれらのためにフォームS'/C'/yのすべてのアドレスを落とすこと'は0とy=0と等しいです、y=0があるそれらを除いて、Cと異なったC'があるフォームS/C'/yのすべてのアドレスと同様に。 したがって、これらのアドレスはこれ以上転送されないでしょう。
Thus, notice that only the information coming from designated routers will be forwarded further away, since the non-designated routers are not allowed to join the multicast groups which correspond to the states and counties. Consequently, their multicast membership information will be not be propagated.
したがって、代表ルータから来る情報だけがさらに遠く転送されるのに注意してください、非代表ルータが州とカウンティーに一致しているマルチキャストグループに加わることができないので。 その結果、それらのマルチキャスト会員資格情報はないことであるために伝播されていた状態で望んでいます。
In this way a router at S/C/x will not bother about specific locations within S'/C'/y since they are "too far".
'それらが「遠過ぎる」ので、S/C/xのルータはS'/C'/yの中でこのように、特定の位置を心配しないでしょう。
Imielinski & Navas Experimental [Page 11] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[11ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Notice that this service may not be provided everywhere so we may not have to use all multicast addresses even within those assigned for geographic addresses.
このサービスがいたる所に提供されないかもしれないのに注意して、私たちは地理的なアドレスのために割り当てられたものの中のすべてのマルチキャストアドレスさえ使用する必要はないかもしれなくなってください。
Notice also that all of this is flexible - if we have more multicast addresses available (IP v 6) we will get more precise addressing due to smaller atoms.
また、このすべてがフレキシブルであるのに注意してください--利用可能なより多くのマルチキャストアドレス(IP対6)があるなら、私たちは、より小さい原子のためより正確なアドレシングを得るつもりです。
3a-iv. GPS Routing
3a-iv。 GPSルート設定
Given a packet we always look for the "closest" match in the routing table. If there is a complete match we follow such a link, if not we follow the address with the x-part 0'd in (county address) if there is none with the county which agrees with the destination county than we look at the entry which agrees with the state part of the destination address.
私たちが「最も近いところで」いつも探すパケットを考えて、経路指定テーブルで合ってください。 私たちはそのようなリンクの後をつけます、そうでなければ完全なマッチがあれば、私たちは送付先アドレスの州の部分に同意するエントリーへの目的地カウンティーに同意するカウンティーがあるなにも私たちほどなければ0が(カウンティーのアドレス)でそうするx-部分一見でアドレスに従います。
3a-v. DNS Issues
3a-v。 DNS問題
How does the client find out the multicast address on which the packet is to be sent? We assume that the local name server has the complete state/county hierarchy and that each county map can be provided possibly with the "grid" of atoms and partitions already clearly marked.
クライアントはどのように、パケットが送られることになっているマルチキャストアドレスを見つけますか? 私たちは地方名サーバには完全な状態/カウンティーの階層構造があって、既に明確にマークされた原子とパーティションの「格子」はそれぞれのカウンティーの地図に提供できると思います。
Points of interests within a county can be attached multicast address just as atoms. Then a given base station would have to join multicast groups of the points of interests that it covers.
カウンティーの中のポイントの関心はちょうど原子として添付のマルチキャスト演説であるかもしれません。次に、与えられた基地局はそれが隠す関心のポイントのマルチキャストグループに加わらなければならないでしょう。
The final stage is for the receiver to look at the polygon (point of interest) which is encoded in the body of the multicast packet and decide on the basis of its own GPS location if this packet is to be received or not. Doing it on the application layer simplifies many routing issues. There is a tradeoff, however, specially when we have very short S/C/x addresses and base stations which do not cover the given polygon in fact are reached unnecessarily. This may happen and it needs to be determined what is the number of the multicast addresses which are necessary to reduce this "false" alarms to the minimum.
最終段階は、受信機が、マルチキャストパケットのボディーでコード化される多角形(興味があるポイント)を見て、それ自身のGPS位置に基づいてこのパケットを受け取られていさせるつもりであるかどうか決めることです。 応用層でそれをすると、多くのルーティング問題が簡略化します。 しかしながら、私たちに非常に短いS/C/xアドレスがあるとき、特に、見返りがあります、そして、事実上、与えられた多角形をカバーしない基地局に不必要に達しています。 これは起こるかもしれません、そして、それは何がこれを「虚偽で」減少させるのに必要なマルチキャストアドレスの数であるかが最小限に驚かせると決心している必要があります。
3a-vi. Estimations
3a-vi。 見積り
Assume average cell size of, say, 2km x 2km and the average state size: say 200,000 square km, the average county size: say 4,000 square km.
たとえば、2km xの平均したセルサイズが2kmと平均した州のサイズであると仮定してください: 正方形の20万km、平均したカウンティーのサイズを言ってください: 正方形の4,000kmを言ってください。
A reasonable size of the atom is around the size of the cell since then we do not hit wrong cells too often.
原子の妥当なサイズはそれ以来のセルのサイズの周りでは、私たちがあまりにも頻繁に間違ったセルを殴らないということです。
Imielinski & Navas Experimental [Page 12] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[12ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Therefore we need the x addressing part of the S/C/x to encode 4,000/4 cells: 1.000 atoms. Thus we need 10 bits for x part. With 6 bits for the state and 6 bits for the county that gives 22 bits which is 1/64 of the total IP v4 multicast addressing space.
したがって、私たちは4,000/4のセルをコード化するためにS/C/xの一部を記述しながら、xを必要とします: 1.000の原子したがって、私たちはx部分に10ビットを必要とします。 状態への6ビットとカウンティーへの6ビットで、それはスペースを記述する1/64の総IP v4マルチキャストである22ビットを与えます。
With IPv6 we will have, of course, much more addressing space which we can use for the GPS multicast routing.
IPv6があるので、私たちには、GPSマルチキャストルーティングに使用できるずっと多くのアドレシングスペースがもちろんあるつもりです。
3b. "Last Mile" Routing
3b。 「最後のマイル」ルート設定
Multicasting will be used for the last mile routing in both our solutions (i.e the one just discussed and the geometric routing solution described next), but in different ways.
マルチキャスティングは、私たちの両方の解決策(ただ議論したものと幾何学上ルーティング解決が次に説明したi.e)で掘られる最後のマイルに使用されますが、異なった方法で使用になるでしょう。
3b-i. Application Level Filtering
3b-i。 アプリケーションレベルフィルタリング
The MSS will forward the geographic message on its wireless link under a multicast address. This multicast address will either be the same for all locations in the range of the MSS's cell or, there will be several addresses corresponding to atoms which intersect the given cell. Additionally, a complete GPS address (for example in the form of the polygon) will be provided in the body of the packet and the exact address matching will be performed on the application layer. The receiver, knowing its GPS position uses it to match against the polygon address. The GPS position can be obtained by the receiver either from the GPS card or, indoors, from the indoor base station which itself knows its GPS position as a part of configuration file.
MSSはマルチキャストアドレスの下における無線のリンクに関する地理的なメッセージを転送するでしょう。 このマルチキャストアドレスがMSSのセルの範囲のすべての位置に同じになるだろうか、またはそこでは、交差する原子に対応するいくつかのアドレスが与えられたセルであったなら同じでしょう。 さらに、完全なGPSアドレス(例えば、多角形の形の)をパケットのボディーに提供するでしょう、そして、正確な送付先マッチングを応用層に実行するでしょう。 受信機であり、GPS位置を知っていると、それは、多角形アドレスに対して合うのに使用されます。 受信機はGPSカード、または、屋内構成ファイルの一部としてGPS位置を知っている屋内のベースステーション自体からGPS位置を得ることができます。
3b-ii. Multicast Filtering
3b-ii。 マルチキャストフィルタリング
In multicast level filtering, the base station assigns a temporary multicast address to the addressing polygon in a message. It will send out a directive on the cell's specially assigned multicast address. All mobile clients who reside in that cell are members of that special multicast group (one per MSS). The directive sent by the MSS will contain the pair consisting of the temporary multicast address together with the polygon. To improve the reliability this message will be multicast several times. The clients, knowing their GPS positions will than join the temporary multicast groups if their current locations are within the advertised polygon. The MSS will then send out the real message using the temporary multicast address.
マルチキャストレベルフィルタリングでは、基地局は一時的なマルチキャストアドレスをメッセージのアドレシング多角形に割り当てます。 それはセルの特に、割り当てられたマルチキャストアドレスに指示を出すでしょう。 そのセルの中に住んでいるすべての可動のクライアントがその特別なマルチキャストグループ(1MSSあたり1つ)のメンバーです。 MSSによって送られた指示は多角形と共に一時的なマルチキャストアドレスから成る組を含むでしょう。 信頼性を改良するために、このメッセージは何度かマルチキャストになるでしょう。 クライアント、彼らのGPS位置を知っているのは広告を出している多角形の中にそれらの現在の位置があるなら一時的なマルチキャストグループに加わるよりそうするでしょう。 そして、MSSは、一時的なマルチキャストアドレスを使用することで本当のメッセージを出すでしょう。
The temporary multicast address would be cached for a period of time. If more packets for the same polygon arrive in a short period of time, they will be sent out on the same multicast address. If not, then the multicast address is dropped and purged from the cache. Filtering on the client's station is then performed entirely on the IP level. This solution introduces additional delay (needed to join
一時的なマルチキャストアドレスはしばらく、キャッシュされるでしょう。 同じ多角形のための、より多くのパケットが短時間に到着すると、同じマルチキャストアドレスでそれらを出すでしょう。 そうでなければ、落とされて、次に、マルチキャストアドレスはキャッシュを追放されます。 そして、クライアントのステーションのフィルタリングは完全なIPレベルに実行されます。 この解決策が追加遅れを導入する、(接合するのが必要です。
Imielinski & Navas Experimental [Page 13] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[13ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
the temporary multicast group) but reduces the number of irrelevant packets received by the client. This especially important for very long messages.
しかし、一時的なマルチキャストグループ)、クライアントによって受け取られた無関係のパケットの数を減少させます。 非常に長いメッセージには特にこれほど重要です。
3b-iii. Computers on Fixed Networks
3b-iii。 固定ネットワークのコンピュータ
Fixed-network computers should also monitor all of the mandatory multicast addresses for their site and GPS square. In this manner, the fixed computers will also receive messages sent to specific GPS- addresses.
また、固定ネットワーク・コンピュータはそれらのサイトとGPS正方形のための義務的なマルチキャストアドレスのすべてをモニターするはずです。 また、この様に、固定コンピュータは特定のGPSアドレスに送られたメッセージを受け取るでしょう。
Modified base stations would still be in charge of multicasting the messages to the computers. These base stations would have the same GPS-routing functionality as the mobile computer base stations. Their main difference would be that the mobile computer base stations would use radio frequencies to multicast their messages and the fixed network base stations use the local Ethernet or Token Ring network.
マルチキャスティングを担当して、変更された基地局はまだコンピュータへのメッセージでしょう。 これらの基地局には、モーバイルコンピュータ基地局と同じGPS-ルーティングの機能性があるでしょう。 それらの主な違いはモーバイルコンピュータ基地局がマルチキャストに無線周波数を使用するだろうということでしょう。それらのメッセージと固定ネットワーク基地局は地方のイーサネットかToken Ringネットワークを使用します。
The next scheme differs from the GPS multicast scheme described above only on the first leg of the route, from the sender to the MSS. The "last mile" from the MSS to the final destination will have the same options as described above.
次の計画はルートの最初の脚だけの上で上で説明されたGPSマルチキャスト計画と異なっています、送付者からMSSまで。 MSSから最終的な目的地までの「最後のマイル」には、上で説明されるのと同じオプションがあるでしょう。
3c. Geometric Routing Scheme (GEO)
3c。 幾何学上ルート設定計画(ジオ)
The Geometric Routing Scheme (GEO) uses the polygonal geographic destination information in the GPScast header directly for routing. GEO routing is going to be implemented in the Internet Protocol (IP) Network layer in a manner similar to the way multicast routing was first implemented. That is, a virtual network which uses GPS addresses for routing will be overlayed onto the current IP internetwork. We would accomplish this by creating our own GPS- address routers. These routers would use tunnels to ship data packets between them and between the routers and base stations.
Geometricルート設定Scheme(GEO)は直接ルーティングにGPScastヘッダーで多角形の地理的な目的地情報を使用します。 GEOルーティングはインターネットプロトコル(IP)ネットワーク層でマルチキャストルーティングが最初に実行された方法と同様の方法で実行されるでしょう。 すなわち、ルーティングにGPSアドレスを使用する仮想ネットワークは現在のIPインターネットワークにかぶせられるでしょう。 私たちは、私たち自身のGPSアドレスルータを作成することによって、これを達成するでしょう。 これらのルータは、それらの間と、そして、ルータと基地局の間にデータ・パケットを出荷するのにトンネルを使用するでしょう。
3c-i. Routing Overview
3c-i。 ルート設定概観
Sending a GPScast message involves three steps: sending the message, shuttling the message between routers, and receiving the message.
GPScastメッセージを送ると、以下の3ステップはかかわります: メッセージを送って、ルータの間のメッセージを往復させて、メッセージを受け取ります。
Sending a GPScast message is very similar to sending a UDP datagram. The programmer would use the GPScast library routine SendToGPS(). Among other parameters, this routine will accept the GPS polygonal destination address and the body of the message. The SendToGPS() routine will encapsulate the GPScast message in a UDP datagram and send it to the class E address 240.0.0.0. Previously, the system administrator will have specified in the /etc/rc.local or /etc/rc.ip file a route command that will specify that packets with the address
GPScastメッセージを送るのはUDPデータグラムを送るのと非常に同様です。 プログラマはGPScastライブラリ・ルーチンSendToGPS()を使用するでしょう。 他のパラメタの中では、このルーチンはGPSの多角形の送付先アドレスとメッセージ欄を受け入れるでしょう。 SendToGPS()ルーチンがUDPデータグラムでGPScastメッセージを要約して、クラスEアドレスにそれを送る、240.0、.0、.0 以前、システム管理者は/etc/rc.localか/etc/rc.ipファイルでアドレスでそのパケットを指定するルートコマンドを指定してしまうでしょう。
Imielinski & Navas Experimental [Page 14] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[14ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
240.0.0.0 will instead be sent to the address of the local GPS router. This will have the effect of sending the datagram to the nearest GPS router.
240.0.0.0 代わりに、地方のGPSルータのアドレスに送るでしょう。 これには、最も近いGPSルータにデータグラムを送るという効果があるでしょう。
Before explaining how the GPS routers shuttle the GPScast message to its destination, an introduction to routers and their different parts is in order. For scalability purposes, GPS routers are arranged in a hierarchical fashion. Each layer would correspond to a distinct geographic area, such as a state or a city. At the top would be country-wide routers in charge of moving messages from one end of the country to another. At the bottom would be campus or department routers in charge of moving messages between the base stations. See Figure 1.
GPSルータがGPScastメッセージを目的地にどう往復させるかを説明する前に、ルータと彼らの異なった部品への序論は整然としています。 スケーラビリティ目的のために、GPSルータは階級的なファッションでアレンジされます。 各層は州か都市などの異なった地理的な領域に対応しているでしょう。 感動的な国の片端から別の片端までのメッセージ担当の全国的なルータはトップでしょう。 下部に、基地局の間の感動的なメッセージ担当のキャンパスか部のルータがあるでしょう。 図1を参照してください。
Country-Router(s)
/ \
State-Router(s)
/ \
City-Router(s)
/ \
Router Router
/ | \ | \
Base Base Base Base Base
国ルータ/\州ルータ/\市ルータ/\ルータルータ/| \ | \基地の基地の基地の基地の基地
Figure 1: Hierarchy of routers.
図1: ルータの階層構造。
A GPS router essentially consists of three parts: a service area table containing the geographic area serviced by the router and each of its hierarchical children, a hashed cache of previous actions, and a table containing the IP addresses of at least the router's children and the router's parent. In the case of a bottom-layer campus router, the service area table will contain polygons describing the geographic reach of each child base station's cell. The polygon created from the union of all of the router's child base stations' polygons defines the service area of the router.
GPSルータは3つの部品から本質的には成ります: 少なくともルータの子供とルータの親のIPアドレスを含むルータによって修理された地理的な領域を含むサービスエリアテーブル、階層的な子供各人、前の動作の論じ尽くされたキャッシュ、およびテーブル。 下部層のキャンパスルータの場合では、サービスエリアテーブルはそれぞれの子供基地局のセルの地理的な範囲について説明する多角形を含むでしょう。 ルータの子供基地局の多角形のすべての組合から作成された多角形はルータのサービスエリアを定義します。
Once the datagram arrives at a GPS router, the router strips the datagram off, thereby, leaving it with the original GPScast message. First the router must determine if it services any part of the area of the destination polygon. To do this, the router finds the intersection between the destination polygon and the polygon describing the router's service area. The polygon intersection algorithm used is described by O'Rourke in his paper, A New Linear Algorithm for Intersecting Convex Polygons. This algorithm requires order N-squared time in the worst case. If the intersection result is null, then the router simply sends the message to its parent router.
一度、データグラムはGPSルータに届きます、その結果、ルータがオリジナルのGPScastメッセージにそれを預けながら、データグラムを全部はぎ取ります。 まず最初に、ルータは、それが何か目的地多角形の領域の地域を調整するかどうか決定しなければなりません。 これをするために、ルータによって、目的地多角形と多角形の間の交差点がルータのサービスエリアについて説明しているのがわかります。 使用される多角形交差点アルゴリズムは彼の論文、Intersecting Convex PolygonsのためのA New Linear Algorithmでオロークによって説明されます。 このアルゴリズムは最悪の場合にはオーダーNで二乗された時間を必要とします。 交差点結果がヌルであるなら、ルータは単に親ルータにメッセージを送ります。
Imielinski & Navas Experimental [Page 15] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[15ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
------ Destination Polygon
| A |
--------------
| | B | | Router's Service Area Polygon
--------------
| C |
------
------ 目的地多角形| A| -------------- | | B| | ルータのサービスエリア多角形-------------- | C| ------
Figure 2: Polygon Difference
図2: 多角形差
However, if the result is not null, then the router does service the area described by the intersection polygon. The router now subtracts its service area from the destination polygon and sends the rest to it's parent router. This subtraction step is actually a by-product of the intersection algorithm. Using the example in Figure 2, the destination polygon and the router's service area polygon intersect at the region labeled B. Therefore, the router will subtract out the B section and send the remaining sections A and C to its parent router.
しかしながら、結果がヌルでないなら、ルータは交差点多角形によって説明された領域を修理します。 ルータは、現在、目的地多角形からサービスエリアを引き算して、それの親ルータに残りを送ります。 この引き算ステップは実際に交差点アルゴリズムの副産物です。 図2の例を使用する、目的地多角形、およびルータのサービスエリア多角形がB.Thereforeとラベルされた領域で交差していて、ルータは、親ルータに外でBセクションを引き算して、残っているセクションAとCを送るでしょう。
Continuing with the example, the router now uses the intersection polygon B to to determine which base station (or stations) will receive the GPScast message. The router finds the intersection between the region B and the polygon of each base station's cell. Those base station polygons which intersect the region B will be sent the GPScast message. Processes on Mobile Hosts serviced by these base stations will now use the routine RecvFromGPS() to receive the GPScast message.
例を続行して、現在がどの基地局(または、ステーション)を決定するかに交差点多角形Bを使用するルータはGPScastメッセージを受け取るでしょう。 ルータは各基地局のセルの領域Bと多角形の間の交差点を見つけます。 ものは交差するステーション多角形を基礎づけます。GPScastメッセージを領域Bに送るでしょう。 これらの基地局によって調整されたモバイルHostsの過程は、現在、GPScastメッセージを受け取るのに通常のRecvFromGPS()を使用するでしょう。
3c-ii. Supporting Long-Duration GPScasts
3c-ii。 長い持続時間GPScastsを支持します。
Most likely, there will be a need to support sending real-time continuous media to a GPS destination. This continuous media could be an audio GPScast or a video GPScast. This would require that jitter be reduced in order to minimize disturbing artifacts in the audio or video playback. Continually checking the destination geometry of each packet would incur unnecessary delays and may promote jitter.
たぶん、リアルタイムの連続したメディアをGPSの目的地に送るのを支持する必要があるでしょう。 この連続したメディアはオーディオのGPScastであるかもしれませんかビデオがGPScastです。 これは、ジターがオーディオかビデオの再生で不穏な人工物を最小にするために減少するのを必要とするでしょう。 絶えずそれぞれのパケットの目的地幾何学をチェックすると、不要な遅れが被られて、ジターは促進されるかもしれません。
Therefore, the router will keep a hashed cache of the latest GPScast packets and their destinations. Each cache item will be hashed using the Sender Identification included in the header of GPScast messages as the key. Each cache item will contain a time stamp and a list of the next hops for that GPScast. When the time stamp exceeds a certain limit, then the cache item will be dropped. The list of next hops is a list of the IP addresses of the base stations, peer routers, and parent router which are to receive a copy of the GPScast messages.
したがって、ルータは、最新のGPScastの論じ尽くされたキャッシュがパケットとそれらの目的地であることを保つでしょう。 それぞれのキャッシュ項目は、キーとしてGPScastメッセージのヘッダーに含まれていたSender Identificationを使用することで論じ尽くされるでしょう。 それぞれのキャッシュ項目はそのGPScastのための次のホップのタイムスタンプとリストを含むでしょう。 タイムスタンプが、ある限界を超えていると、キャッシュ商品は落とされるでしょう。 次のホップのリストは基地局、同輩ルータ、およびGPScastメッセージのコピーを受け取ることである親ルータのIPアドレスのリストです。
Imielinski & Navas Experimental [Page 16] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[16ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
When a router receives a GPScast packet, it will use the incoming packet's Sender Id as a key into the hashed cache. If this is not the first packet to arrive for this destination and if the timer on the hash table entry has not yet expired, then the hashed cache will return a list of all of the destination addresses to which copies of the packet must be sent. Copies of the packet are sent to all of these destinations and the hash entry's time stamp is updated.
ルータがGPScastパケットを受けるとき、それはキーとして入って来るパケットのSender Idを論じ尽くされたキャッシュに使用するでしょう。 これがこの目的地に到着する最初のパケットでなく、またハッシュ表エントリーでのタイマがまだ期限が切れていないと、論じ尽くされたキャッシュはパケットのコピーを送らなければならない送付先アドレスのすべてのリストを返すでしょう。 これらの目的地のすべてにパケットのコピーを送ります、そして、細切れ肉料理エントリーのタイムスタンプをアップデートします。
If no hash table entry is found (i.e.- this is the first packet encountered for this destination address), then the normal geometry checking routine would take over. A new cache entry is made recording all of the next-hop destination addresses of the GPScast. In this manner, if several other packets with the same GPS destination follow this first packet, the router can use the hash table to look-up the destination base stations instead of calculating it using geometry.
ハッシュ表エントリーが全く見つけられないなら(すなわち、これはこの送付先アドレスのために遭遇する最初のパケットです)、通常の幾何学照合ルーチンは引き継ぐでしょう。GPScastの次のホップ送付先アドレスのすべてを記録しながら、新しいキャッシュエントリーをします。 この様に、同じGPSの目的地がある他のいくつかのパケットがこの最初のパケットに続くなら、ルータは幾何学を使用することでそれについて計算することの代わりに目的地ベースが配置するルックアップにハッシュ表を使用できます。
3c-iii. Discovering A Router's Service Area
3c-iii。 ルータのサービスエリアを発見します。
When the router is initiated, it will consult its configuration file. One of the items it will find in the file will be the multicast address of the base station group to which all of its child base stations are members. The router will join this group and then send out Service Area Query messages to this multicast group periodically to discover and to refresh its knowledge of its children base stations and the geographical areas serviced by them.
ルータが開始されるとき、それは構成ファイルに相談するでしょう。 それがファイルで見つける項目の1つは子供基地局のすべてがメンバーである基地局グループのマルチキャストアドレスになるでしょう。 ルータは、定期的に発見するこのマルチキャストグループにこのグループに加わって、次に、Service Area Queryメッセージを出すでしょう、そして、リフレッシュするために、子供に関する知識はステーションとそれらによってサービスを提供された地理的な領域を基礎づけます。
Queries are issued infrequently (no more than once every five minutes) so as to keep the IGPSMP overhead on the network very low. However, since the query is issued using unreliable multicast datagrams, there is a chance that some base stations may not receive the query. This is important in two cases: when a child node fails and when a router first boots up. The case of a failed child node will be explained later. However, when a router first boots up, it can issue several queries in a small amount of time in order to guarantee that base stations will receive the query and to, therefore, build up its knowledge about its child base stations quickly.
質問は、ネットワークのIGPSMPオーバーヘッドを非常に低く保つためにまれに(かつての5分だけ毎)発行されます。 しかしながら、質問が頼り無いマルチキャストデータグラムを使用することで発行されるので、いくつかの基地局が質問を受けないかもしれないという見込みがあります。 これは2つの場合で重要です: 子供ノードが失敗して、ルータが最初に起動するとき。 失敗した子供ノードに関するケースは後で説明されるでしょう。 しかしながら、ルータが最初に起動するとき、それは基地局が質問を受けるのを保証して、したがって急速に子供基地局に関する知識を確立する少量の時間、いくつかの質問を発行できます。
Base stations respond to a Service Area Query by issuing a Service Area Report. This report is issued on the same multicast group address that all of the base stations have joined. The report contains the geographical service area of the base station. In order to avoid a sudden congestion of reports being sent at the same time, each base station will initiate a random delay timer. Only when the timer expires will the base station send its report.
基地局は、Service Area Reportを発行することによって、Service Area Queryに応じます。 基地局のすべてが接合したのと同じマルチキャストグループアドレスでこのレポートを発行します。 レポートは基地局の地理的なサービスエリアを含んでいます。 同時に送られるレポートの突然の混雑を避けるために、各基地局は無作為のディレイタイマを開始するでしょう。 タイマが期限が切れる場合にだけ、基地局はレポートを送るでしょう。
Imielinski & Navas Experimental [Page 17] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[17ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
For every base station that responds, the router will create an IP tunnel between it and the base station. This tunnel will carry the GPScast packet traffic between the base station and the router. Each responding base station and its geographic area of service will also be included in the router's geometric routing table as a possible destination for GPScast packets. Any base station that does not respond for ten continuous Service Area Queries will be considered unreachable and will be dropped from the routing table.
応じるあらゆる基地局に関しては、ルータはそれと基地局の間のIPトンネルを作成するでしょう。 このトンネルは基地局とルータの間のGPScastパケット交通を運ぶでしょう。 また、それぞれ、基地局とその地理的なサービスの領域を反応させるのはGPScastパケットのための可能な目的地としてルータの幾何学上経路指定テーブルに含まれるでしょう。 10連続したService Area Queriesのために応じない少しの基地局も、手が届かないと考えられて、経路指定テーブルから落とされるでしょう。
3c-iv. Hierarchical Router Structure and Multicast Groups
3c-iv。 階層的なルータ構造とマルチキャストグループ
R5----------------------R6
/ \ / \
R1---------R2 R3---------R4
/ | \ / | \ / | \ / | \
b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12
R5----------------------R6/\/\R1---------R2 R3---------R4/| \ / | \ / | \ / | \b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12
Figure 3: Two peer routers (R5 and R6) cooperatively servicing four
child routers (R1 - R4).
図3: 協力して、4つの子供ルータ(R1--R4)を修理する2同輩ルータ(R5とR6。)
For scalability purposes, a hierarchy of routers is used to transport messages from a sender to a receiver. Each layer of peer routers would have its own multicast group address for the exchange of Service Area Queries and Reports between the peer routers. However, routers in distinct subtrees need not know about the routers in other subtrees. Therefore, multicast group addresses will also differ between hierarchy subtrees. See figure 3. For instance, routers R1 and R2 would share a multicast group and would know about each other. At the same time, routers R3 and R4 would share a different multicast group and would know about each other. However, routers R1 and R2 would not know about R3 and R4, and vice versa.
スケーラビリティ目的において、ルータの階層構造は、送付者から受信機までメッセージを輸送するのに使用されます。それぞれの層の同輩ルータは同輩ルータでService Area QueriesとReportsの交換のためのそれ自身のマルチキャストグループ住所を知っているでしょう。 しかしながら、異なった下位木におけるルータは他の下位木におけるルータに関して知る必要はありません。 したがって、また、マルチキャストグループアドレスは階層構造下位木の間で異なるでしょう。 3が計算するのを確実にしてください。 例えば、ルータのR1とR2はマルチキャストグループを共有して、互いに関して知っているでしょう。 同時に、ルータのR3とR4は異なったマルチキャストグループを共有して、互いに関して知っているでしょう。 しかしながら、ルータのR1とR2はR3とR4に関して知らないでしょう、そして、逆もまた同様です。
But how will the router know the location and number of its peer routers and who its parent router is? As mentioned before, the router consults its configuration file upon start-up. Included in this configuration file will be the the address of its parent router and the multicast group address that the peer routers will use. This peer multicast group address will be used in the same manner as the base station multicast group address. It will be used to send and receive Service Area Queries and Reports between the parent router and the peer routers. There is only one difference. When a router sends a Service Area Report, in addition to reporting its geographical service area, a router will include the multicast address of its children base stations. The reason for this is explained in the router-failure recovery scheme described below.
しかし、ルータはどのように同輩ルータと親ルータが人であるのに関する位置と数を知るでしょうか? 以前言及されるように、ルータは上にから始まるのに関する構成ファイルに相談します。 この構成ファイルに含まれているのは、親ルータのアドレスとマルチキャストグループアドレスに同輩ルータが使用するなるでしょう。 この同輩マルチキャストグループアドレスは基地局マルチキャストグループアドレスと同じ方法で使用されるでしょう。 それは、親ルータと同輩ルータの間にService Area QueriesとReportsを送って、受け取るのに使用されるでしょう。 1つの違いしかありません。 地理的なサービスエリアを報告することに加えてルータがService Area Reportを送るとき、ルータは子供基地局のマルチキャストアドレスを含むでしょう。 この理由は以下で説明されたルータ失敗回復計画で説明されます。
Imielinski & Navas Experimental [Page 18] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[18ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
3c-v. Routing Optimizations
3c-v。 ルート設定最適化
The optimization described here attempts to reduce the latency of a GPScast. It does so by reducing the the number of hops a packet must traverse before finding its destination. The intuition behind the idea is this: instead of going to the parent router and then to the sibling, simply go to the sibling directly. As an additional benefit, this method prevents the parent router from becoming a bottleneck or a point of failure in the routing scheme.
ここで説明された最適化は、GPScastのレイテンシを減少させるのを試みます。 それは、目的地を見つける前にパケットが横断しなければならないホップの数を減少させることによって、そうします。 考えの後ろの直観はこれです: 親ルータと、そして、そして、兄弟に行くことの代わりに、単に直接兄弟に行ってください。 追加利益として、この方法は、親ルータがルーティング計画における、ボトルネックか失敗のポイントになるのを防ぎます。
In this optimization, when a router attempts to determine who will receive the GPS packet, it considers its peer routers as if they were also its children in the routing hierarchy. This means that the router will consider its service area to be the union of the service areas of its children and its peer routers. Also, when the destination polygon intersects the router's service area polygon, the router will forward a copy of the GPScast packet to any child or peer router whose geographic service area contains or touches the packet's GPS destination polygon.
ルータが、だれがGPSパケットを受けるかを決定するのを試みるときのこの最適化では、それはまるでまた、彼らがルーティング階層構造の子供であるかのように同輩ルータを考えます。 これは、ルータが、サービスエリアが子供とその同輩ルータのサービスエリアの組合であると考えることを意味します。 また、目的地多角形が交差していると、ルータのものは領域多角形を修理して、ルータは地理的なサービスエリアがパケットのGPS目的地多角形に含んでいるか、または触れるどんな子供や同輩ルータにもGPScastパケットのコピーを送るでしょう。
However, before it sends a copy of the packet to a peer router, it first finds the polygon:
しかしながら、パケットのコピーを同輩ルータに送る前に最初に、多角形を見つけます:
P = D /\ S
PはD/\Sと等しいです。
where D stands for the packet's destination GPS polygon, S is the polygon representing the service area of the peer router, and P is the polygon that represents the intersection of D and S. The polygon P is substituted for the destination polygon D in the packet and only then is the packet forwarded to the peer router. This is necessary because the peer router will be using that same routing algorithm. Therefore, if the peer router receives a packet with the original destination polygon D, it will also route copies of the packet to all of its qualifying peer routers causing a chain of packet copies being bounced back and forth.
Dがパケットの目的地GPS多角形を表して、Sが同輩ルータのサービスエリアを表す多角形であり、PがDの交差点を表す多角形であり、S. 多角形Pが目的地多角形Dに代入されるところに、同輩ルータに送られたパケットがその時、あるだけです。 同輩ルータがその同じルーティング・アルゴリズムを使用するので、これが必要です。 したがって、また、同輩ルータがオリジナルの目的地多角形Dでパケットを受けると、それは前後に弾むパケットコピーのチェーンを引き起こす資格を得ている同輩ルータのすべてへのパケットのコピーを発送するでしょう。
3c-vi. Router-Failure Recovery Scheme
3c-vi。 ルータ失敗回復計画
In the case of a router failure, the system should be able to route around the failed router and continue to service GPScast messages. The responsibility of detecting whether a router has failed or not falls to the parent router. Using Figure 3 as an example router hierarchy, the parent router R5 periodically sends out Service Area Query IGPSMP messages on its children's multicast group address. Thus, the child routers R1 and R2 will both receive this query. Normally, both routers will respond with a Service Area Report message. This message contains a polygon describing their service areas and the multicast group address of their children.
ルータ失敗の場合では、システムは、サービスGPScastメッセージに失敗したルータの周りで発送して、続くことができるはずです。 ルータが失敗したかどうか検出する責任は親ルータに落下します。 例のルータ階層構造として図3を使用して、親ルータR5は定期的に子供のマルチキャストグループアドレスにService Area Query IGPSMPメッセージを出します。 したがって、子供ルータのR1とR2はともにこの質問を受けるでしょう。 通常、両方のルータはService Area Reportメッセージで応じるでしょう。 このメッセージはそれらのサービスエリアについて説明する多角形と彼らの子供のマルチキャストグループアドレスを含んでいます。
Imielinski & Navas Experimental [Page 19] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[19ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
However, if a router, R1, does not respond to ten continuous queries, then it must be considered to have failed. Upon detecting this, the parent router R5 will send a Set Service Area message to the child router, R2 telling it to assume responsibility for the base stations underneath the failed R1 router. In this Set Service Area message, the parent router includes the multicast group address of R1's children. The R2 router uses this multicast address to learn the service areas and IP addresses of R1's children. The R2 router then issues a Service Area Report advertising its new enlarged service area responsibilities. All peer and parent routers will then update their routing tables to include this new information. When the failed router, R1, restarts, it will declare that it is alive and that it is again servicing its area. All routers will then again update their routing tables.
しかしながら、ルータ(R1)が10の連続した質問まで応じないなら、失敗したのは考えなければなりません。 これを検出すると、親ルータR5は子供ルータ(失敗したR1ルータの下で基地局への責任を負うようにそれに言うR2)にSet Service Areaメッセージを送るでしょう。 このSet Service Areaメッセージでは、親ルータはR1の子供のマルチキャストグループアドレスを含んでいます。 R2ルータは、R1の子供のサービスエリアとIPアドレスを学ぶのにこのマルチキャストアドレスを使用します。 そして、R2ルータは新しい拡大したサービスエリア責任をService Area Report広告に発行します。 そして、すべての同輩と親ルータは、この新情報を含むようにそれらの経路指定テーブルをアップデートするでしょう。 失敗したルータ(R1)が再開すると、それはそれが生きていて、再び領域を修理していると宣言するでしょう。 そして、すべてのルータが再びそれらの経路指定テーブルをアップデートするでしょう。
In the case that there is no parent router, such as at the top of the routing hierarchy, then each peer router will keep track of its neighbors. If a neighbor router fails, then the first neighbor router to declare that it is taking over the base stations for the failed router will take responsibility. The rest continues as before.
ルーティング階層構造の最上部などの親ルータが全くなくて、そして、それぞれの同輩ルータは隣人の動向をおさえるでしょう。 隣人ルータが失敗すると、失敗したルータのために基地局を占領していると宣言する最初の隣人ルータは責任を取るでしょう。 残りは従来と同様続きます。
3c-vii. Domain Name Service Issues
3c-vii。 ドメイン名サービス問題
Domain Name Servers (DNS) could be used to facilitate the use of GPS geographic addressing for sites of interest. The aim is to describe specific geographic sites in a more natural and real-world manner using a postal-service like addressing method. Essentially, the DNS would resolve a postal-service like address, such as City_Hall.New_York_City.New_York, into the IP address of the GPS router responsible for that site. The GPS router would then route the message to all available recipients in the site.
GPSの地理的なアドレシングの興味深いサイトの使用を容易にするのにドメインName Servers(DNS)を使用できました。 目的は方法を記述するような郵便業務を使用しながらより多くの自然で本当の世界の方法で特定の地理的なサイトについて説明することです。 本質的には、DNSはアドレスのような郵便業務を決議するでしょう、市の_Hall.New_ヨーク・_City.New_ヨークなどのように、そのサイトに原因となるGPSルータのIPアドレスに。 そして、GPSルータはサイトのすべての手があいている受取人にメッセージを発送するでしょう。
The DNS would be used when a message is sent using the
使用をメッセージに送るとき、DNSを使用するでしょう。
site-code.city-code.state-code.country-code
サイト-code.city-code.state-code.country-code
addressing scheme. The DNS would evaluate the address in reverse starting with the country code, then the state code, etc. This is the same method used currently by the IP DNS service to return IP addresses based on the country or geographic domains.
体系を扱います。 DNSが国名略号からの逆の始めにおけるアドレスを評価して、その時は、州のコードですなど。 これは国か地理的なドメインに基づくIPアドレスを返すのに現在、IP DNSサービスで使用される同じメソッドです。
Imielinski & Navas Experimental [Page 20] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[20ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
4. Router Daemon and Host Library
4. ルータデーモンとホスト図書館
4a. GPS Address Library - SendToGPS()
4a。 GPSアドレス図書館--SendToGPS()
A library for GPS address routing will be constructed. The main routines contained in this library will be the SendToGPS() and RecvFromGPS() commands. SendToGPS() has the following syntax:
GPSアドレスルーティングのためのライブラリは構成されるでしょう。 この図書館に保管されていたメインルーチンは、SendToGPS()とRecvFromGPS()コマンドになるでしょう。 SendToGPS()には、以下の構文があります:
SendToGPS(int socket, GPS-Address *address, char *message, int size)
SendToGPS(intソケット、GPS-アドレス*アドレス、炭*メッセージ、intサイズ)
where socket is a previously created datagram socket, address is a
filled GPS-Address structure with the following form:
typedef _GPS-Address {
enum { point, circle, polygon } type;
char *mail-address;
struct
{
enum { North, South, West, East } dir;
int hours, minutes, seconds;
} *points;
ソケットが以前に作成されたデータグラムソケットであるところでは、アドレスは以下のフォームがあるいっぱいにされたGPS-アドレス構造です: typedef_GPS-アドレス、enumに、北部、西の、そして、東の南部はdirされます;int時間、数分、structに秒、enumに、ポイント、円、多角形はタイプします; *郵便の宛先を炭にしてください; *は指します。
} GPS-Address;
} GPS-アドレス。
and message and size specify the actual message and its size. The SendToGPS() routine will take the GPS-addressed message, encapsulate it in an IP packet, and then send it as a normal IP datagram. The message is encapsulated in the following manner:
そして、メッセージとサイズは実際のメッセージとそのサイズを指定します。 SendToGPS()ルーチンは、GPSによって扱われた伝言を受け取て、IPパケットでそれをカプセル化して、次に、正常なIPデータグラムとしてそれを送るでしょう。 メッセージは以下の方法でカプセル化されます:
--------------------------------------------------------
| IP Header with destination address set to 240.0.0.0 |
--------------------------------------------------------
| Sender Identifier |
--------------------------------------------------------
| Address Type - Circle|Polygon |
--------------------------------------------------------
| Actual GPS Address (see below) |
--------------------------------------------------------
| Body of Message |
--------------------------------------------------------
-------------------------------------------------------- | 送付先アドレスがあるIP Headerが240.0に.0を設定する、.0| -------------------------------------------------------- | 送付者識別子| -------------------------------------------------------- | アドレスタイプ--旋回してください。|多角形| -------------------------------------------------------- | 実際のGPS Address(以下を見ます)| -------------------------------------------------------- | メッセージのボディー| --------------------------------------------------------
where the Sender Identifier would consist of a combination of the sender's process id, host IP address, and the center of the destination polygon. The Actual Address would be one of the following:
Sender Identifierが送付者のプロセスイドの組み合わせから成るところでは、IPアドレス、および目的地多角形のセンターをホスティングしてください。 Actual Addressは以下のひとりでしょう:
circle - single GPS address and range measured in centiminutes.
旋回してください--ただ一つのGPSアドレスとcentiminutesで測定された範囲。
Imielinski & Navas Experimental [Page 21] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[21ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
polygon - list of GPS addresses terminated by the impossible
address: N 255 255 255.
多角形--GPSアドレスのリストは不可能なアドレスで終わりました: N255 255 255。
RecvFromGPS() has the following syntax:
RecvFromGPS()には、以下の構文があります:
RecvFromGPS(int socket,GPS-Address *address,char *message,int size)
RecvFromGPS(intソケット、GPS-アドレス*アドレス、炭*メッセージ、intサイズ)
where socket is a previously created datagram socket, address is an empty GPS-Address structure, and message and size specify message buffer and its size.
ソケットが以前に作成されたデータグラムソケットであるところでは、アドレスは空のGPS-アドレス構造です、そして、メッセージとサイズはメッセージ・バッファとそのサイズを指定します。
4b. Establishing A Default GPS Router
4b。 デフォルトGPSルータを確立します。
The default GPS router is determined using the unicast routing table found in the UNIX kernel. The local system administrator will have previously adjusted the table so that all GPScast messages are sent to the local GPS router. However, if there is no route for GPScast messages in the table, then all messages will, by default, be sent to the default gateway. If the default gateway does not support GPScast messages, then all attempts to send a GPScast will return an error.
デフォルトGPSルータは、UNIXカーネルで見つけられたユニキャスト経路指定テーブルを使用することで決定しています。 ローカルシステム管理者が以前にテーブルを調整してしまうだろうので、すべてのGPScastメッセージを地方のGPSルータに送ります。 しかしながら、テーブルのGPScastメッセージのためのルートが全くないと、デフォルトですべてのメッセージをデフォルトゲートウェイに送るでしょう。 デフォルトゲートウェイがGPScastにメッセージをサポートしないと、GPScastを送るすべての試みが誤りを返すでしょう。
By default, all GPScast messages will initially have as their destination the class E address 240.0.0.0. A route will be added to the kernel routing table by the system administrator for this address. The route will specify the location of the local GPS router. The "route" command will be used to affect the routing table and it can be placed in the /etc/rc.local or /etc/rc.ip files so that it will take effect each time the computer is booted. For example, to specify that GPScast messages addressed to 240.0.0.0 should, by default, be sent to the router which resides on a computer on the same subnet with local address 128.6.5.53, use the following:
デフォルトで、すべてのGPScastメッセージには、初めは、それらの目的地としてクラスEアドレス240.0.0.0があるでしょう。 ルートはこのアドレスのためにシステム管理者によってカーネル経路指定テーブルに加えられるでしょう。 ルートは地方のGPSルータの位置を指定するでしょう。 経路指定テーブルに影響するのに「ルート」コマンドを使用するでしょう、そして、コンピュータが起動されている各回効くように/etc/rc.localか/etc/rc.ipファイルにそれを置くことができます。 例えば、GPScastメッセージが240.0に.0を扱ったと指定するために、デフォルトでローカルアドレスで同じサブネットのコンピュータであるルータに.0を送るべきである、128.6、.5、.53、以下を使用してください:
/etc/route add host 240.0.0.0 128.6.5.53 0
/etc/routeはホスト240.0.0.0 128.6.5.53 0を加えます。
If the default destination for GPScast messages is a host that does not support GPS addressing, then Network Unreachable errors will be returned to any process attempting to route GPScasts through that host.
GPScastメッセージのためのデフォルトの目的地がGPSがアドレシングであるとサポートしないホストであるなら、Network Unreachable誤りはそのホストを通してGPScastsを発送するのを試みるどんなプロセスにも返されるでしょう。
4c. GPSRouteD
4c。 GPSRouteD
In order to provide the capability of GPS address routing throughout an IPv4-based internetwork, special-purpose routers will be created to support GPS address routing on top of the current Internet. These routers, which will be called GPSRouteD, will use virtual point-to- point links called tunnels in order to connect two GPSRouteDs together over regular unicast networks. The tunnels work by encapsulating the GPS address messages in IP datagrams and then
IPv4ベースのインターネットワーク中でGPSアドレスルーティングの能力を提供して、専用ルータは、現在のインターネットの上でGPSアドレスがルーティングであるとサポートするために作成されるでしょう。 これらのルータ(GPSRouteDと呼ばれる)は仮想のポイントからポイントへの通常のユニキャストネットワークの上に2GPSRouteDsを一緒に接続するためにトンネルと呼ばれるリンクを使用するでしょう。 IPデータグラムとその時GPSアドレスがメッセージであるとカプセル化することによって、トンネルは働いています。
Imielinski & Navas Experimental [Page 22] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[22ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
transmitting the message to the host on the other end of the tunnel. In this manner, the GPS address messages look like normal unicast packets to all IPv4 routers in between the two GPS address routers. At the end of the tunnel, the receiving GPSRouteD removes the GPS address message from the datagram and continues the routing process.
トンネルのもう一方の端でメッセージをホストに送ります。 この様に、GPSアドレスメッセージは2つのGPSアドレスルータの間のすべてのIPv4ルータに正常なユニキャストパケットに似ています。 トンネルの端では、受信GPSRouteDはデータグラムからGPSアドレスメッセージを取り除いて、ルーティングプロセスを持続させます。
By using tunnels, the GPS routers can be established as a virtual internetwork throughout the current Internet without regard for the physical properties of the underlying networks. Moreover, the use of tunnels means that the host on which the router daemon is running need not be connected to more than one subnet in order for the router to forward GPS messages. This virtual internetwork would be responsible for routing GPS address messages only. This virtual network, however, is not intended to be a permanent solution and is only intended to provide a means of supporting GPS address routing until it gains wider acceptance and support in the Internet infrastructure.
トンネルを使用することによって、現在のインターネット中に基本的なネットワークの物理的性質への尊敬なしで仮想のインターネットワークとGPSルータが書き立てられることができます。 そのうえ、ルータがメッセージをGPSに転送するように、トンネルの使用は、ルータデーモンが稼働する予定であるホストが1つ以上にサブネット整然とした状態で接される必要はないことを意味します。 この仮想のインターネットワークはルーティングGPSアドレスメッセージだけに原因となるでしょう。 この仮想ネットワークは、しかしながら、恒久的な解決であることを意図しないで、より広い承認とサポートを獲得するまでGPSアドレスがルーティングであるとサポートする手段をインターネット基盤に提供することを意図するだけです。
4c-i. Configuration
4c-i。 構成
When a GPSRouteD initially executes, it first checks the file /etc/GPSRouteD.conf for configuration commands to add tunnel and multicast links to other GPS address routers. There are two kinds of configuration commands:
いつ、a GPSRouteDが初めは実行するか、構成コマンドが、トンネルを堀ってください。そうすれば、他のGPSへのマルチキャストリンクがルータを扱うと言い足すように、それは最初に、ファイル/etc/GPSRouteD.confをチェックします。 2種類の構成コマンドがあります:
multicast <multicast-address> <peer|child>
マルチキャスト<マルチキャストアドレス><はじっと見ます。|子供>。
tunnel <local-addr> <remote-addr>
<parent|peer|child|host> <service-area>
地方のaddrの<の><リモートaddrの><親にトンネルを堀ってください。|同輩|子供|ホスト><サービスエリア>。
The tunnel command is used to create a tunnel between the local host on which the GPSRouteD executes and a remote host on which another GPSRouteD executes. The tunnel must be set up in the GPSRouteD.conf files at both ends before it will be used.
別のGPSRouteDが実行する使用されるGPSRouteDが実行するローカル・ホストの間でオンなトンネルとリモートホストを創造するトンネルコマンド。 それが使用される前に両端のGPSRouteD.confファイルにトンネルを設定しなければなりません。
The multicast command tells the router which multicast addresses to join. These addresses will carry IGPSMP messages and replies. The router will use these IGPSMP messages to build up and keep current its own internal routing table.
マルチキャストコマンドは、接合するようにマルチキャストが扱うルータに言います。 これらのアドレスはIGPSMPメッセージと回答を載せるでしょう。 ルータは現在のそれ自身の内部の経路指定テーブルを確立して、保つこれらのIGPSMPメッセージを使用するでしょう。
4d. Multicast Address Resolution Protocol (MARP)
4d。 マルチキャストアドレス解決プロトコル(MARP)
Of course, this begs the question, how will the individual computers know which multicast addresses to join? For example, an MH would have to join the multicast address of its current cell so that it can receive GPScast messages (using application-level filtering) or directions to join other multicast groups (using multicast filtering). We have designed a protocol called Multicast Address
もちろん、これは論点を巧みに避けて、個々のコンピュータは、接合するためにどのようにどのマルチキャストアドレスを知るでしょうか? 例えば、MHは、他のマルチキャストグループに加わるためにGPScastメッセージ(アプリケーションレベルフィルタリングを使用する)か方向を受け取ることができる(マルチキャストフィルタリングを使用して)ように、現在のセルのマルチキャストアドレスを接合しなければならないでしょう。 私たちはMulticast Addressと呼ばれるプロトコルを設計しました。
Imielinski & Navas Experimental [Page 23] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[23ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Resolution Protocol (MARP) that works the same way as Reverse Address Resolution Protocol (RARP). However, instead of returning the IP address of the MH, it will return multicast group address of the cell the MH is currently in. The MH would then join this multicast group.
逆アドレス解決プロトコルと同じよう(RARP)に働いている解決プロトコル(MARP)。 しかしながら、MHのIPアドレスを返すことの代わりに、それは現在、MHがいるセルのマルチキャストグループアドレスを返すでしょう。 そして、MHはこのマルチキャストグループに加わるでしょう。
4e. Internet GPS Management Protocol (IGPSMP)
4e。 インターネットGPS管理プロトコル(IGPSMP)
The Internet GPS Management Protocol (IGPSMP) is used by GPS routers to report, query, and inform their router counterparts about their geographical service areas. The IGPSMP will also be used to verify that routers are correctly functioning.
彼らの地理的なサービスエリアに関して彼らのルータ対応者にインターネットGPS Managementプロトコル(IGPSMP)はGPSルータによって使用されて、報告して、質問して、知らせます。 また、IGPSMPは、ルータが正しく機能していることを確かめるのに使用されるでしょう。
The vocabulary of IGPSMP will consist of six words:
IGPSMPのボキャブラリーは6つの単語から成るでしょう:
o set service area - Used by the parent router to set the
geographic service area of a router. This is needed in
order to automatically respond to router failure or new
router boot-up.
o サービスエリア--親ルータによって使用されて、ルータの地理的なサービスエリアを設定するように設定してください。 これが、自動的にルータ失敗か新しいルータ起動に応じるのに必要です。
o confirm service area - confirms that a router has received
its service area.
o サービスエリアを確認してください。--ルータがサービスエリアを受けたと確認します。
o geographical service area query - This message will be used
by a router to build up its geographical routing table.
It is sent to all routers on the same level.
o 地理的なサービスエリア質問--このメッセージはルータによって使用されて、地理的な経路指定テーブルを確立するでしょう。 同じレベルですべてのルータにそれを送ります。
o service area report - This message is sent in response to a
query request. It contains a bounding closed polygon
described using GPS coordinates which contains the service
area for the router.
o サービスエリアレポート--質問要求に対応してこのメッセージを送ります。 それはGPS座標を使用することで説明された制限の閉じている多角形を含んでいます(ルータのためのサービスエリアを含んでいます)。
o ping - This message is sent periodically to ascertain whether
the router is currently functioning properly. Usually sent
by the parent router in the hierarchy tree.
o ピング--ルータが現在適切に機能しているかどうかを確かめるために定期的にこのメッセージを送ります。 通常、階層構造木の親ルータは送ります。
o alive signal - Usually sent as a reply to the ping message.
Used by a router to indicate that it is functioning
correctly. It is also sent immediately after a router
boots.
o 生きている、合図してください--通常、回答としてピングメッセージに送ります。 ルータによって使用されて、それが正しく機能しているのを示します。 また、ルータブーツ直後それを送ります。
All of IGPSMP messages will be sent on an all-routers multicast address for a particular hierarchy level. The exact multicast address can be set in the router configuration file.
特定の階層構造レベルのためのオールルータマルチキャストアドレスでIGPSMPメッセージのすべてを送るでしょう。 ルータ構成ファイルに正確なマルチキャストアドレスを設定できます。
Note that for the GPS-Multicast routing scheme, the time-to-live value of the service area reports will be varied in order to control the distribution of the information. In GPS-Multicast routing, only
情報の分配を制御するためにGPS-マルチキャストルーティング体系において、サービスエリアレポートの生きる時間値が変えられることに注意してください。 中、GPS-マルチキャストルーティングで、唯一
Imielinski & Navas Experimental [Page 24] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[24ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
the multicast group membership for very large partitions will be distributed throughout the country. Smaller partition may only be distributed to neighbor routers.
非常に大きいパーティションのためのマルチキャストグループ会員資格は全国いたる所で分配されるでしょう。 より小さいパーティションは隣人ルータに広げられるだけであるかもしれません。
5. Working Without GPS Information
5. GPS情報なしで働いています。
5a. Users Without GPS Modules
5a。 GPSモジュールのないユーザ
Mobile users without GPS modules can still participate - though at a very reduced level. When an MH enters a cell, it can use an MARP to discover the local multicast group for that cell or atom. As the user roams from cell to cell, the mobile host can keep track of the current cell that the user is in and adds or drops the multicast groups pertaining to those cells. The user's GPS address can be set to be the center of the current cell.
GPSモジュールのないモバイルユーザはまだ参加できます--もっとも非常に減少しているレベルで。 MHがセルを入れるとき、それは、そのセルか原子のためにローカルのマルチキャストグループを発見するのにMARPを使用できます。 ユーザがセルからセルまで歩き回るとき、モバイルホストは、それらのセルに関係するマルチキャストグループの、ユーザがいる現在のセルの動向をおさえることができて、加えるか、または下げます。 現在のセルのセンターであるようにユーザのGPSアドレスを設定できます。
5b. Buildings block GPS radio frequencies. What then?
5b。 ビルはGPS無線周波数を妨げます。 次は何?
Each room can have a radio beacon placed on the ceiling. The beacon will be weak enough so that it will not penetrate walls. Each radio beacon will have its own GPS-address associated with it which it will broadcast. When a mobile user enters a room, his MH will detect the beacon and read the beacon's GPS address. The GPS-address of the MH will be set to the GPS-address of the beacon. The MH will then use this beacon's GPS address in order to perform any message filtering that it needs to do. Now the mobile user can have a GPS-address associated with him even though he is indoors and his GPS-module is useless.
各余地で、ラジオビーコンを天井に置くことができます。 標識は、壁に入り込まないように、十分弱くなるでしょう。 各ラジオビーコンはそれが放送するそれ自身のそれに関連しているGPS-住所を知っているでしょう。 モバイルユーザが部屋に入るとき、彼のMHは標識を検出して、標識のGPSアドレスを読むでしょう。 MHのGPS-アドレスは標識のGPS-アドレスに設定されるでしょう。 そして、MHは、それがする必要があるどんなメッセージフィルタリングも実行するのにこの標識のGPSアドレスを使用するでしょう。 今、彼は屋内にいます、そして、彼のGPS-モジュールは役に立たないのですが、モバイルユーザは彼に関連しているGPS-アドレスを持つことができます。
6. Application Layer Solution
6. 応用層溶液
In this subsection we sketch a third solution which relies more heavily on the DNS.
この小区分では、私たちは、より大いにDNSを当てにする3番目のソリューションについてスケッチします。
In the application layer solution the geographic information is added to the DNS which provides the full directory information down to the level of the IP address of each base station and its area of coverage represented as a polygon of coordinates.
応用層溶液では、地理情報は完全なディレクトリ情報を座標の多角形として表された各基地局とその適用範囲の領域のIPアドレスのレベルまで提供するDNSに加えられます。
A new first level domain - "geographic" is added to the set of first level domains. The second level domain names include states, the third, counties and finally, the fourth: polygons of coordinates, or so called points of interests. We can also allow, polygons to occur as elements of second, third domains to enable sending messages to larger areas.
新しい最初の平らなドメイン--「地理的」は最初に、平らなドメインのセットに追加されます。 セカンドレベルドメイン名は州と3番目とカウンティーと最終的に4番目を含んでいます: 座標の多角形、またはいわゆるポイントの関心。 また、私たちが許すことができる、可能にする2番目、3番目のドメインの要素として起こるより広大な地域にメッセージを送る多角形。
Imielinski & Navas Experimental [Page 25] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[25ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Thus a typical geographic address can look like
したがって、典型的な地理的なアドレスに似ることができます。
city-hall-Palo-Alto.San-Mateo-County.California.geographic
都市のホールパロAlto.San-Mateo-County.California.geographic
or
または
Polygon.San-Mateo-County.California.geographic
Polygon.San-Mateo-County.California.geographic
where Polygon is a sequence of coordinates.
Polygonが座標の系列であるところ。
This geographic address is resolved in a similar way as the standard domain addresses are resolved today into a set of IP addresses of base stations which cover that geographic area. There are several possibilities here:
標準のドメインアドレスが今日その地理的な領域をカバーする基地局のIPアドレスのセットに変えられるとき、この地理的なアドレスは同様の方法で決議されています。 いくつかの可能性がここにあります:
a. A set of unicast messages is sent to all base stations corresponding to the IP addresses returned by the DNS. Each base station then forwards the message using either of the two last link solutions: application level or network level filtering.
a。 DNSによって返されたIPアドレスに対応するすべての基地局に1セットのユニキャストメッセージを送ります。 次に、各基地局は最後の2つのリンクソリューションのどちらかを使用することでメッセージを転送します: アプリケーションは、平らなフィルタリングを平らにするか、またはネットワークでつなぎます。
b. All the base stations join the temporary multicast group for the geographic area specified in the message. In this way we may avoid sending the same message across the same link several times. Thus, after the set of relevant base stations is determined by the DNS, the temporary multicast group is established and all packets with that multicast address are sent on that multicast address.
b。 すべての基地局がメッセージで指定された地理的な領域を一時的なマルチキャストグループと一緒に楽しみます。 私たちが、同じように同じメッセージを使いにやるのを避けるかもしれないこのように、何度かリンクしてください。 したがって、関連基地局のセットがDNSによって決定された後に一時的なマルチキャストグループを設立します、そして、そのマルチキャストアドレスでそのマルチキャストアドレスがあるすべてのパケットを送ります。
c. Only one, central to the polygon base station is returned by the DNS just as in the IP unicast solution. However that "central" base station will have to forward messages to the other base stations within the polygon.
c。 多角形基地局に主要な1つはそうにすぎません。ちょうどIPユニキャストソリューションのようにDNSによって返されます。 しかしながら、その「中央」の基地局は多角形の中で他の基地局にメッセージを転送しなければならないでしょう。
Notice that we should distinguish between "small area" and "wide area" geographic mail. The "small area" mail will be most common and will most likely involve just one base station, favoring a simple form of solution (a).
私たちが「狭い面積」と「広い領域」地理的なメールを見分けるべきであるのに注意してください。 「狭い面積」メールは、最も一般的であり、たぶんちょうど1つの基地局を伴うでしょう、単純形のソリューション(a)を支持して。
7. Reliability
7. 信頼性
Should the geographic messages be acknowledged?
地理的なメッセージは承認されるべきですか?
Since we have no control if users are present in the target geographic area where the mail is distributed we do not see a need for individual acknowledgments from the message recipients. However, we believe that the base stations (MSS) covering the target area of geographic mail should acknowledge the messages.
ユーザがメールが分配された私たちである地理的な領域がそうしない目標に出席しているなら私たちにはコントロールが全くないので、メッセージ受取人から個々の承認の必要性を認めてください。 しかしながら、私たちは、地理的なメールの目標地域をカバーする基地局(MSS)がメッセージを承認するべきであると信じています。
Imielinski & Navas Experimental [Page 26] RFC 2009 GPS-Based Addressing and Routing November 1996
イメリンスキーとNavasの実験的な[26ページ]RFC2009のGPSベースのアドレシングとルート設定1996年11月
Typically only a few base stations will be involved since typically we will not cover very broad geographic areas anyway. We assume that the base stations, additionally to forwarding the the messages on their wireless interfaces will buffer them, either to periodically multicast them (emergency response) or to provide them to users who just entered a cell and download the "emergency stack" of messages for that area as a part of the service hand-off protocol.
私たちがとにかく非常に広い地理上の区域を通常カバーするつもりでないので、通常ほんのいくつかの基地局がかかわるでしょう。 または、私たちは、それが基地局であると思って、さらに、推進に、それらのワイヤレスインターフェースに関するメッセージはそれらをバッファリングするでしょう、どちらか定期的にマルチキャスト、それら(非常時の応答)、ただセルを入れたユーザにそれらを提供して、サービスハンドオフの一部としてメッセージの「非常時のスタック」をその領域にダウンロードするには、議定書を作ってください。
8. Security Considerations
8. セキュリティ問題
Some method of determining who has permission to send messages to a large geographical area is needed. For instance, perhaps only the mayor of New York City has permission to send a message to all of New York City.
だれに広大な地理的な地域にメッセージを送る許可があるかを決定する何らかのメソッドが必要です。 例えば、恐らく、ニューヨーク市の市長だけには、ニューヨーク市のすべてにメッセージを送る許可があります。
9. References
9. 参照
Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
S. Deering. Multicast Routing in a Datagram Internetwork. Ph.D. Thesis, Stanford University, (December 1991).
S.デアリング。 データグラムインターネットワークにおけるマルチキャストルート設定。 博士Thesis、スタンフォード大学(1991年12月)。
J. O'Rourke, C.B. Chien, T. Olson, and D. Naddor, A new linear algorithm for intersecting convex polygons, Computer Graphics and Image Processing 19, 384-391 (1982).
交差している凸多角形とコンピュータGraphicsとイメージ加工19(384-391(1982))のためのJ.オロークとC.B.Chien、T.オルソンとD.Naddor、A新しい直線的なアルゴリズム。
J. Ioannidis, D. Duchamp, and G. Q. Maquire. IP-Based Protocols for Mobile Internetworking. Proc. of ACM SIGCOMM Symposium on Communication, Architectures and Protocols, pages 235-245, (September, 1991).
J.Ioannidis、D.デュシャン、およびG.Q.Maquire。 モバイルインターネットワーキングのためのIPベースのプロトコル。 Proc Communication、Architectures、およびプロトコルのACM SIGCOMM Symposium、235-245ページ(1991年9月)について。
10. Authors' Addresses
10. 作者のアドレス
Tomasz Imielinski and Julio C. Navas
Computer Science Department
Busch Campus
Rutgers, The State University
Piscataway, NJ
08855
トマシュ・イメリンスキーとフリオC.Navasコンピュータサイエンス部のブッシュキャンパスラトガース、ピスキャタウェイ、州立大学ニュージャージー 08855
Phone: 908-445-3551
EMail: {imielins,navas}@cs.rutgers.edu
以下に電話をしてください。 908-445-3551 メールしてください: imielins、navas、@cs.rutgers.edu
Imielinski & Navas Experimental [Page 27]
イメリンスキーとNavas実験的です。[27ページ]
一覧
スポンサーリンク
