RFC1668 日本語訳

Network Working Group                                          D. Estrin
Request for Comments: 1668                                           USC
Category: Informational                                            T. Li
                                                           Cisco Systems
                                                              Y. Rekhter
                                  T.J. Watson Research Center, IBM Corp.
                                                             August 1994

Estrinがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1668年のUSCカテゴリ: 情報のT.のシスコシステムズY.Rekhter T.J.李ワトソン研究所、IBM社の1994年8月

                 Unified Routing Requirements for IPng

IPngのための統一されたルート設定要件

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the big-internet@munnari.oz.au mailing list.

RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。

1. IPng Requirements

1. IPng要件

   The following list provides requirements on the IPng from the
   perspective of the Unified Routing Architecture, as describe in RFC
   1322.

以下のリストはUnifiedルート設定Architectureの見解からIPngに関する要件を提供します、RFCで1322について説明するとき。

   1. To provide scalable routing, IPng addressing must provide support
      for topologically significant address assignment.

1. スケーラブルなルーティング、必須がサポートを位相的に提供するIPngアドレシングを提供してください。重要なアドレス課題。

   2. Since it is hard to predict how routing information will be
      aggregated, the IPng addressing structure should impose as few
      preconditions as possible on the number of levels in the hierarchy.
      Specifically, the number of levels must be allowed to be different
      at different parts in the hierarchy. Further, the levels must not
      be statically tied to particular parts (fields) in the addressing
      information.

2. ルーティング情報がどう集められるかを予測しにくいので、構造を記述するIPngはできるだけわずかな前提条件しか階層構造のレベルの数に課すはずがありません。 明確に、異なった部品で階層構造において異なるのをレベルの数を許容しなければなりません。 さらに、静的にアドレス指定情報の特定の部分(分野)にレベルを結んではいけません。

   3. Hop-by-hop forwarding algorithm requires IPng to carry enough
      information in the Network Layer header to unambiguously determine
      a particular next hop. Unless mechanisms to compute
      context-sensitive forwarding tables and provide consistent
      forwarding are defined, the requirement assumes the presence of
      full hierarchical addresses.  Therefore, IPng packet format must
      provide efficient determination of the full hierarchical

3. ホップごとの推進アルゴリズムは、IPngがNetwork Layerヘッダーの明白に次の特定のホップを決定できるくらいの情報を運ぶのを必要とします。 文脈依存推進テーブルを計算して、一貫した推進を提供するメカニズムが定義されない場合、要件は完全な階層的なアドレスの存在を仮定します。 したがって、IPngパケット・フォーマットは階層的に完全の効率的な決断を提供しなければなりません。

Estrin, Li & Rekhter                                            [Page 1]

RFC 1668         Unified Routing Requirements for IPng       August 1994

Estrin、李、およびRekhter[1ページ]RFC1668は1994年8月にIPngのためのルート設定要件を統一しました。

      destination address.

送付先アドレス。

   4. Hierarchical address assignment should not imply strictly
      hierarchical routing. Therefore, IPng should carry enough
      information to provide forwarding along both hierarchical and
      non-hierarchical routes.

4. 階層的なアドレス課題は厳密に階層的なルーティングを含意するべきではありません。 したがって、IPngは階層的なものと同様に非階層的なルートに沿って提供できるくらいの情報を進展させるはずです。

   5. The IPng packet header should accommodate a "routing label" or
      "route ID". This label will be used to identify a particular FIB
      to be used for packet forwarding by each router.

5. IPngパケットのヘッダーは「ルーティングラベル」か「ルートID」を収容するべきです。 このラベルは、パケット推進に各ルータによって使用されるために特定のFIBを特定するのに使用されるでしょう。

      Two types of routing labels should be supported: "strong" and
      "weak".

2つのタイプのルーティングラベルは支えられるべきです: 「強く」「弱いです」。

      When a packet carries a "strong" routing label and a router does
      not have a FIB with this label, the packet is discarded (and an
      error message is sent back to the source).

パケットが「強い」ルーティングラベルを運んで、ルータがこのラベルがあるFIBを持っていないと、パケットは捨てられます(エラーメッセージはソースに送り返されます)。

      When a packet carries a "weak" routing label and a router does not
      have a FIB with this label, the packet should be forwarded via a
      "default" FIB, i.e., according to the destination address. In
      addition, the packet should carry an indication that somewhere
      along the path the desired routing label was unavailable.

パケットが「弱い」ルーティングラベルを運んで、ルータがこのラベルがあるFIBを持っていないと、「デフォルト」FIBを通してパケットを進めるべきです、すなわち、送付先アドレスによると。 さらに、パケットは経路に沿ったどこかでは、必要なルーティングラベルが入手できなかったという指示を運ぶはずです。

   6. IPng should provide a source routing mechanism with the following
      capabilities (i.e., flexibility):

6. IPngは以下の能力(すなわち、柔軟性)をソースルーティングメカニズムに提供するはずです:

       - Specification of either individual routers or collections of
         routers as the entities in the source route.

- 送信元経路による実体としてのルータの個々のルータか収集のどちらかの仕様。

       - The option to indicate that two consecutive entities in a
         source route must share a common subnet in order for the
         source route to be valid.

- 示すソースの2つの連続した実体が発送するオプションは、送信元経路が有効であるように一般的なサブネットを共有しなければなりません。

       - Specification of the default behavior when the route to
         the next entry in the source route is unavailable:

- 送信元経路による次のエントリーへのルートが入手できなくデフォルトの振舞いの仕様:

       - The packet is discarded, or

- またはパケットが捨てられる。

       - The source route is ignored and the packet is forwarded based
         only on the destination address (and the packet header will
         indicate this action).

- 送信元経路を無視します、そして、送付先アドレスだけに基づいた状態でパケットを進めます(パケットのヘッダーはこの動作を示すでしょう)。

       - A mechanism to verify the feasibility of a source route.

- 送信元経路に関する実現の可能性について確かめるメカニズム。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Estrin, Li & Rekhter                                            [Page 2]

RFC 1668         Unified Routing Requirements for IPng       August 1994

Estrin、李、およびRekhter[2ページ]RFC1668は1994年8月にIPngのためのルート設定要件を統一しました。

Authors' Addresses

作者のアドレス

   Deborah Estrin
   University of Southern California
   Computer Science Department, MC 0782
   Los Angeles, California 90089-0782

南カリフォルニアコンピュータ理学部、ロサンゼルスのM.C.0782、カリフォルニア90089-0782のデボラEstrin大学

   Phone: (310) 740-4524
   EMail: estrin@usc.edu

以下に電話をしてください。 (310) 740-4524 メールしてください: estrin@usc.edu

   Tony Li
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

トニー李コクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025

   EMail: tli@cisco.com

メール: tli@cisco.com

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱218ヨークタウンの高さ、10598

   Phone:  (914) 945-3896
   EMail:  yakov@watson.ibm.com

以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@watson.ibm.com

Estrin, Li & Rekhter                                            [Page 3]

Estrin、李、およびRekhter[3ページ]