IPv6用RIPng(出力処理)

広告

広告

原文

最終更新
2006-11-01T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2080/rfc2080_25.html#source

IPv6用RIPng(和訳)

最終更新
2006-11-03T21:24:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2080/rfc2080_25.html#translation

2.5 出力処理

   This section describes the processing used to create response
   messages that contain all or part of the routing table.  This
   processing may be triggered in any of the following ways:

   - By input processing, when a Request is received.  In this case, the
     Response is sent to only one destination (i.e. the unicast address
     of the requestor).

   - By the regular routing update.  Every 30 seconds, a Response
     containing the whole routing table is sent to every neighboring
     router.

   - By triggered updates.  Whenever the metric for a route is changed,
     an update is triggered.

この章では、ルーティングテーブルの全てか一部を含む応答メッセージを生成するために用いる処理について触れる。この処理は、次の方法のいずれかでトリガされる。

   The special processing required for a Request is described in section
   2.4.1.

リクエストに要求される特別な処理は、2.4.1 リクエストメッセージで触れている。

   When a Response is to be sent to all neighbors (i.e., a regular or
   triggered update), a Response message is multicast to the multicast
   group FF02::9, the all-rip-routers multicast group, on all connected
   networks that support broadcasting or are point-to-point links. RIPng
   handles point-to-point links just like multicast links as
   multicasting can be trivially provided on such links.  Thus, one
   Response is prepared for each directly-connected network, and sent to
   the all-rip-routers multicast group.  In most cases, this reaches all
   neighboring routers.  However, there are some cases where this may
   not be good enough. This may involve a network that is not a
   broadcast network (e.g., the ARPANET), or a situation involving dumb
   routers.  In such cases, it may be necessary to specify an actual
   list of neighboring routers and send a datagram to each one
   explicitly.  It is left to the implementor to determine whether such
   a mechanism is needed, and to define how the list is specified.

応答が全ての隣接ノードに送信される際(つまり、通常のアップデートかトリガアップデート)、応答メッセージはブロードキャストもしくはポイントツーポイントリンクをサポートする全てのネットワークで、全RIPルータマルチキャストグループであるFF02::9にマルチキャストされる。マルチキャストが当然そのようなリンクを提供されるのと同様に、RIPngはポイントツーポイントリンクを調度マルチキャストリンクのように扱う。従って、1つの応答は直接接続されたそれぞれのネットワーク用に準備されており、全てのRIPルータマルチキャストグループに送信される。大抵の場合、これは全ての隣接ルータに届く。しかし、これでは十分でないいくつかの場合がある。これは、ブロードキャストネットワークでない場合や(例えばARPANET)、ダンプルータを含む状況である。このような場合、隣接ルータの実際のリストをを指定し、明示的に各データグラムを送信する必要があるかもしれない。このようなメカニズムが必要かどうかと、どのようにリストを指定するかの定義は実装者に任される。

2.5.1 トリガアップデート

   Triggered updates require special handling for two reasons.  First,
   experience shows that triggered updates can cause excessive loads on
   networks with limited capacity or networks with many routers on them.
   Therefore, the protocol requires that implementors include provisions
   to limit the frequency of triggered updates.  After a triggered
   update is sent, a timer should be set for a random interval between 1
   and 5 seconds.  If other changes that would trigger updates occur
   before the timer expires, a single update is triggered when the timer
   expires.  The timer is then reset to another random value between 1
   and 5 seconds.  Triggered updates may be suppressed if a regular
   update is due by the time the triggered update would be sent.

トリガアップデートは、2つの理由から特別な処理が要求される。1つめの理由として、経験上トリガアップデートはキャパシティに制限されたネットワークもしくは多くのルータを持つネットワークで極度の負荷を引き起こす。そのため、プロトコルは実装者がトリガアップデートの頻度を制限する機能の提供を要求される。トリガアップデートが送信された後、タイマは1秒から5秒の間のランダムな間隔を設定されるべきである。タイマ満了前にトリガアップデートを発生させる他の変更が生じる場合、単一のアップデートがタイマ満了時になされる。通常のアップデートがトリガアップデートが送信される時までに予定されているのであれば、トリガアップデートは抑えられるかもしれない。

   Second, triggered updates do not need to include the entire routing
   table.  In principle, only those routes which have changed need to be
   included.  Therefore messages generated as part of a triggered update
   must include at least those routes that have their route change flag
   set.  They may include additional routes, at the discretion of the
   implementor; however, sending complete routing updates is strongly
   discouraged.  When a triggered update is processed, messages should
   be generated for every directly-connected network.  Split Horizon
   processing is done when generating triggered updates as well as
   normal updates (see section 2.6).  If, after Split Horizon processing
   for a given network, a changed route will appear unchanged on that
   network (e.g., it appears with an infinite metric), the route need
   not be sent.  If no routes need be sent on that network, the update
   may be omitted.  Once all of the triggered updates have been
   generated, the route change flags should be cleared.

2つ目に、トリガアップデートは全てのルーティングテーブルを含む必要がない。原則として、変更された経路のみを含まれる必要がある。従って、トリガアップデートの部分として生成されたメッセージは、少なくとも経路変更フラグが設定されている経路を含まなくてはならない。実装者の裁量で追加の経路を含むこともあるが、完全なルーティングアップデートの送信はされるべきではない。トリガアップデートを処理する際、メッセージは全ての直接接続されたネットワークで生成されるべきである。スプリットホライズン処理は、通常のアップデート同様にトリガアップデートを生成する際になされる(2.6 スプリットホライズンを参照)。与えられたネットワークのスプリットホライズン処理の後に、変更された経路がそのネットワークにおいて変更がないと見えるのであれば(例えば、距離が無限大)、その経路を送信する必要はない。ネットワークに送信される経路がなければ、アップデートは省略されるかもしれない。トリガアップデートが生成される場合は常に、経路変更フラグはクリアされるべきである。

   If input processing is allowed while output is being generated,
   appropriate interlocking must be done.  The route change flags should
   not be changed as a result of processing input while a triggered
   update message is being generated.

出力が生成されている間に入力処理が認められるのであれば、適切な連結を行わなければならない。トリガアップデートメッセージが生成されている間に、経路変更フラグは入力処理の結果として変更されるべきではない。

   The only difference between a triggered update and other update
   messages is the possible omission of routes that have not changed.
   The remaining mechanisms, described in the next section, must be
   applied to all updates.

トリガアップデートと他のアップデートの唯一の違いは、変更のない経路を省略できるかどうかである。次章で触れる残りのメカニズムは、全てのアップデートで用いられなくてはならない。

2.5.2 応答メッセージの生成

   This section describes how a Response message is generated for a
   particular directly-connected network:

この章では、どのように応答メッセージが特定の直接接続ネットワークで生成されるかについて触れる。

   The IPv6 source address must be a link-local address of the possible
   addresses of the sending router's interface, except when replying to
   a unicast Request Message from a port other than the RIPng port.  In
   the latter case, the source address must be a globaly valid address.
   In the former case, it is important to use a link-local address
   because the source address is put into routing tables (as the next
   hop) in the routers which receive this Response.  If an incorrect
   source address is used, other routers may be unable to route
   datagrams.  Sometimes routers are set up with multiple IPv6 addresses
   on a single physical interface.  Normally, this means that several
   logical IPv6 networks are being carried over one physical medium.  It
   is possible that a router may have multiple link-local addresses for
   a single interface. In this case, the router must only originate a
   single Response message with a source address of the designated
   link-local address for a given interface.  The choice of which link-
   local address to use should only change when the current choice is no
   longer valid.  This is necessary because nodes receiving Response
   messages use the source address to identify the sender.  If multiple
   packets from the same router contain different source addresses,
   nodes will assume they come from different routers, leading to
   undesirable behavior.

IPv6発信元アドレスは、RIPngポート以外のポートからのユニキャストリクエストメッセージに対する応答を除いて、送信ルータインターフェイスのリンクローカルアドレスでなければならない。後者の場合、発信元アドレスはグローバルで有効なアドレスでなければならない。前者の場合、発信元アドレスはこの応答を受け取ったルータのルーティングテーブル(ネクストホップのように)を設定するので、リンクローカルアドレスを用いることは重要である。正しくない発信元アドレスが用いられるのであれば、他のルータはデータグラムの経路を決めることができないかもしれない。ルータは、1つの物理的なインターフェイスに複数のIPv6アドレスを設定されることがある。通常、これはいくつかの論理的なIPv6ネットワークが1つの物理メディア上にあることを意味する。ルータは1つのインターフェイスの複数のリンクローカルアドレスを持つことが可能である。この場合、ルータは与えられたインターフェイスに割り当てられたリンクローカルアドレスの発信元アドレスを持つ1つの応答メッセージのみを生成する。用いるリンクローカルアドレスの選択は、現在選択しているアドレスが無効になった場合のみ変更をすべきである。応答メッセージを受け取るノードが送信者を識別するために発信元アドレスを用いるので、これは必要となる。同じルータからの複数のパケットが異なる発信元アドレスを含むなら、ノードは異なるルータからそれらが来たと想定し、望ましくない処理がなされることとなるだろう。

   Set the version number to the current version of RIPng.  The version
   described in this document is version 1.  Set the command to
   Response.  Set the bytes labeled "must be zero" to zero.  Start
   filling in RTEs.  Recall that the maximum datagram size is limited by
   the network's MTU.  When there is no more space in the datagram, send
   the current Response and start a new one.

バージョンナンバにRIPngの現在のバージョンを設定する。この文書で記されたバージョンは1である。コマンドに応答を設定する。"ゼロの設定"を指定されたバイトにゼロを設定する。RTEの記入を始める。最大データグラムサイズがネットワークのMTUによって制限されることを思い出す。データグラムにこれ以上の空きがない場合は、現在の応答を送り、新しい応答を始める。

   To fill in the RTEs, examine each route in the routing table.  Routes
   to link-local addresses must never be included in an RTE.  If a
   triggered update is being generated, only entries whose route change
   flags are set need be included.  If, after Split Horizon processing,
   the route should not be included, skip it.  If the route is to be
   included, then the destination prefix, prefix length, and metric are
   put into the RTE.  The route tag is filled in as defined in section
   2.1.  Routes must be included in the datagram even if their metrics
   are infinite.

RTEの記入のため、ルーティングテーブルの各経路を調査する。リンクローカルアドレスへの経路は、RTEに含まれてはならない。トリガアップデータが生成されているのであれば、経路変更フラグが設定されたエントリのみを含む必要がある。スプリットホライズン処理の後に、経路が含まれないのであれば、それはスキップされる。経路が含まれるのであれば、宛先プレフィックス、プレフィックス長、距離がRTEに記入される。経路タグは、2.1 メッセージフォーマットで定義されたように記入される。経路は、例えその距離が無限大であっても、データグラムに含めなければならない。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年11月01日 最終更新:2006年11月03日