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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

compress ファイルを圧縮・展開する(拡張子.Z)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る