RFC1676 日本語訳

Network Working Group                                        A. Ghiselli
Request for Comments: 1676                                   D. Salomoni
Category: Informational                                       C. Vistoli
                                                               INFN/CNAF
                                                             August 1994

Ghiselliがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1676年のD.Salomoniカテゴリ: 情報のC.Vistoli INFN/CNAF1994年8月

                     INFN Requirements for an IPng

IPngのためのINFN要件

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.

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

Overview

概要

   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 メーリングリストにコメントを提出するべきです。

Abstract

要約

   This white paper is sent by INFN network team, the Italian National
   Institute for nuclear physics, whose network, named INFNet, is a
   nationwide network founded to provide the access to existing national
   and international HEP laboratory and to facilitate communications
   between the researchers.  With this paper we would like to emphasize
   the key points that we would to consider if charged with IPng plan.
   We do not really expect to add original items to the selection, but
   we think that it could be useful to submit the opinions and ideas
   that come from our network experience.

この白書はINFNネットワークチーム、核物理学のためのINFNetというネットワークが既存の国家的、そして、国際的なHEP実験室へのアクセスを提供して、研究者のコミュニケーションを容易にするために設立された全国中継であるイタリアのNational Instituteによって送られます。 IPngで告発するなら考えるために、私たちが強調する要点を強調したいと思うこの紙で、計画してください。 オリジナルの項目を選択に加えると本当に予想しませんが、私たちは、私たちのネットワーク経験から来る意見と考えを提出するのが役に立つかもしれないと思います。

1. General Requirements

1. 一般要件

   The problems that are to be solved in IP internet are mainly three:

IPインターネットで解決されることになっている問題は主に3です:

      1. address exhaustion

1. アドレス疲労困憊

      2. flat address space

2. フラットアドレス空間

      3. routing efficiency, flexibility and capacity.

3. ルーティング効率、柔軟性、および容量。

   The aim of IPng study should be to define a plan that solves all
   these problems as a whole and not each of them separately.

IPng研究の目的は別々にそれぞれのそれらではなく、全体でこれらのすべての問題を解決するプランを定義することであるべきです。

   The general requirements that we underline for this transition are:

私たちがこの変遷のためにアンダーラインを引く一般的な要件は以下の通りです。

Ghiselli, Salomoni & Vistoli                                    [Page 1]

RFC 1676             INFN Requirements for an IPng           August 1994

IPng1994年8月のためのGhiselli、Salomoni、およびVistoli[1ページ]RFC1676INFN要件

      - transparency to the final user: user applications should not be
        influenced.

- 最終的なユーザへの透明: ユーザアプリケーションに影響を及ぼすべきではありません。

      - flexibility: Simplify the suitability to new communication
        technology and to topology changes due to new services provided
        or to different users needs.

- 柔軟性: 新しい通信技術と、そして、新種業務による変化が提供したトポロジー、または、異なったユーザの必要性への適合を簡素化してください。

2. Application and Transport Level

2. アプリケーションと輸送レベル

   Starting from the top of the OSI model, we think that the users
   applications should not be influenced by the migration plan.  It
   means that the TCP (the transport layer) must maintain the same
   interfaces and services to the upper layers.  Anyway, it is also
   necessary to foresee the use of a different transport services. The
   possibility to use different transport should be offered to the
   applications.  Therefore a transport selector field is needed.

OSIモデルの先端から始めて、私たちは、ユーザアプリケーションが移行プランによって影響を及ぼされるべきでないと思います。 それは、TCP(トランスポート層)が同じインタフェースと上側の層に対するサービスを維持しなければならないことを意味します。 また、とにかく、異なった輸送サービスの使用について見通すのも必要です。 異なった輸送を使用する可能性をアプリケーションに提供するべきです。 したがって、輸送セレクタ分野が必要です。

3. Network layer: service and address

3. ネットワーク層: サービスとアドレス

   We assume that the network layer must continue to provide the same
   datagram service as IP does.  CLNS could be a solution and a reliable
   starting point for the IPng.  The main advantage is that this
   solution has been profitable tested and it is already available on
   many systems.  It is not, of course, deployed as widely as IPv4 is,
   since it is a newer technology, but it is widely configured and and
   there is already operational experience.  The corresponding address,
   the NSAP, is 20 bytes long.  It is long enough to scale the future
   data network environment.  Its hierarchical format can be organized
   in a really flexible way, satisfying hierarchical routing and policy
   based routing needs and simplifying the distributed administration
   and management.  A lot of work has been already done in the majority
   of the countries in order to define NSAP formats satisfying both the
   requirements of administrative delegation and routing performances.

私たちは、ネットワーク層が、IPとしてのサービスがする同じデータグラムを提供し続けなければならないと思います。 CLNSはソリューションとIPngにおいて、信頼できる出発点であるかもしれません。 主な利点はこのソリューションがテストされていた状態で有益であり、それが多くのシステムの上で既に利用可能であるということです。それはもちろんより新しい技術であることでIPv4広く配布されませんが、そして、そこで広く構成されているのが、既に操作上の経験であるということです。 対応するアドレス(NSAP)は20バイト長です。 それは将来のデータ網環境をスケーリングできるくらい長いです。 本当にフレキシブルな方法で階層的な形式を組織化できます、階層型ルーティングとベースのルーティングが必要とする方針を満たして、分散型管理と管理を簡素化して。 NSAP書式を定義するために管理委譲とルーティング性能の両方の要件を満たしながら、国の大部分で既に多くの仕事をしました。

4. Routing protocols

4. ルーティング・プロトコル

   We don't consider the decision about the routing protocol to be
   adopted for the IPng to be fundamental.  Even if this choice is very
   important to obtain good performances, the routing protocols can be
   changed or improved at any time, because there is no influence into
   the End Systems configuration.  Relationships between NSAP
   aggregation, hierarchical topology and hierarchical routing algorithm
   must be taken into account in IPng plan.  These issues could improve
   administration and topological flexibility of the IPng and solve the
   flat problem of the IPv4.  The IPng routing protocols should include
   policy-based features.  The IPv4 network topology is very complex and
   it will continue to enlarge during the transition. It would be very
   difficult or impossible to manage it without the "policy" tools.  The

私たちは、採用されるというルーティング・プロトコルに関する決定はIPngが基本的であると考えません。 この選択が望ましい市場成果を得るために非常に重要であっても、いつでもルーティング・プロトコルを変えるか、または改良できます、End Systems構成には影響が全くないので。 IPngプランでNSAP集合と、階層的なトポロジーと階層的なルーティング・アルゴリズムとの関係を考慮に入れなければなりません。 これらの問題は、IPngの管理と位相的な柔軟性を改良して、IPv4の平坦な問題を解決するかもしれません。 IPngルーティング・プロトコルは方針ベースの特徴を含むべきです。 IPv4ネットワーク形態は非常に複雑です、そして、それは変遷の間、拡大し続けるでしょう。 「方針」ツールなしでそれを管理するのは、非常に難しいか、または不可能でしょう。 The

Ghiselli, Salomoni & Vistoli                                    [Page 2]

RFC 1676             INFN Requirements for an IPng           August 1994

IPng1994年8月のためのGhiselli、Salomoni、およびVistoli[2ページ]RFC1676INFN要件

   multicast capability as well as any other new features that fit in a
   datagram network should be supported.  Regarding the Source Routing
   feature, since we think that it deeply modifies the aim and the
   "philosophy" of a connectionless network and it also introduces an
   heavy complication in the end nodes and routers software, we don't
   consider it a major issue.

データグラム・ネットワークをうまくはめ込むいかなる他の新機能と同様にマルチキャスト能力はサポートされるべきです。 Sourceルート設定機能に関して、私たちが、それが深くコネクションレスなネットワークの目的と「哲学」を変更すると考えて、また、それがエンドノードとルータソフトウェアにおける重い複雑さを導入するので、私たちは、それが主要な問題であると考えません。

5. Layer 2 or communication infrastructure media support.

5. 2かコミュニケーションインフラストラクチャメディアサポートを層にしてください。

   This is an open field, rapidly changing, then it must be left open to
   any evolution. What it should be recommended is to be compatible with
   the above network layer.

急速に変化して、これが開電場である、そして、それをどんな発展にも開かれているままにしなければなりません。 それが推薦されるべきであることは上のネットワーク層と互換性があることになっています。

6. Transition and Deployment

6. 変遷と展開

   We faced the problem of the transition of the DECNET global network
   to DECNET/OSI over CLNS. This activity is now proceeding to the last
   step and based on this experience we would underline some points that
   we found important during the transition deployment.  The transitions
   must be planned and developed in a distributed way.  This means that
   every organization should have the possibility to plan and start
   their network migration without loosing connectivity with the
   existing global internet.  Of course, the compatibility with the IPv4
   world must be maintained, this mean that a new generation system must
   interwork with both the IPv4 and IPng nodes, using the same
   applications.

私たちはCLNSの上でDECNET世界的なネットワークのDECNET/OSIへの変遷の問題に直面していました。 この活動は今最後のステップに進んでいます、そして、この経験に基づいて、私たちは変遷展開の間に重要であることがわかった諸点にアンダーラインを引くでしょう。 分配された方法で変遷を計画されて、開発しなければなりません。 これは、あらゆる組織には既存のグローバルなインターネットで接続性を発射しないでそれらのネットワーク移行を計画して、始める可能性があるべきであることを意味します。 もちろん、IPv4世界との互換性を維持しなければなりません、新しい世代システムがIPv4とIPngノードの両方で織り込まなければならないこの平均、同じアプリケーションを使用して。

   However, it is important to define a deadline for the backward
   compatibility in order to avoid huge software maintenance in the user
   systems and a "multi-topology" management.  We think that a dual
   stack approach could simplify very much the transition, whereas a
   translation mechanism would need a widely and deep coordination in
   order to maintain the global connectivity during the transition
   period.  The dual stack is simpler and could be easily developed, but
   it is important to push in order to have pure IPng with global
   connectivity as soon as possible; this could happen when there are no
   more "IPv4 only" hosts.

しかしながら、後方の互換性のための締め切りを定義するのは、ユーザシステムにおける巨大なソフトウェア・メンテナンスと「マルチトポロジー」管理を避けるために重要です。 私たちが、デュアルスタックアプローチが変遷をたいへん簡素化するかもしれないと思いますが、変換メカニズムがaを広さと深く必要とするだろう、コーディネート、過渡期の間、グローバルな接続性を維持してください。 デュアルスタックは、より簡単であり、容易に開発できましたが、押すのはできるだけ早くグローバルな接続性がある純粋なIPngを持つために重要です。 それ以上の「IPv4専用」ホストが全くいないとき、これは起こることができました。

   Indeed, the drawback of the dual stack configuration is that you
   continue to suffer for the IPv4 address space exhaustion and that you
   must continue to support the IPv4 routing protocols and
   infrastructure.  We don't think that the tunnel solution to
   interconnect the IPv4 isle could give good performances to the users.
   Then, it is important to maintain the IPv4 connectivity and the dual
   stack software support in the End System software in a determined
   timeframe, or the transition will never end.

本当に、デュアルスタック構成の欠点はあなたがIPv4アドレス空間疲労困憊のためにずっと苦しんで、IPv4ルーティング・プロトコルとインフラストラクチャをサポートし続けなければならないということです。 私たちは、IPv4島とインタコネクトするトンネルソリューションが望ましい市場成果をユーザに与えるかもしれないと思いません。 次に、断固とした時間枠でEnd SystemソフトウェアにおけるIPv4の接続性とデュアルスタックソフトウェアサポートを維持するのが重要であるか、または変遷は決して終わらないでしょう。

Ghiselli, Salomoni & Vistoli                                    [Page 3]

RFC 1676             INFN Requirements for an IPng           August 1994

IPng1994年8月のためのGhiselli、Salomoni、およびVistoli[3ページ]RFC1676INFN要件

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

Authors' Addresses

作者のアドレス

   Davide Salomoni
   INFN-CNAF
   National Institute of Nuclear Physics - National Networking Center
   V.le Ercolani, 8
   40138 Bologna - Italy

核物理学--8歳のセンターのV.leエルコラーニのために40138ボローニャをネットワークでつないでいる国立--イタリアのダビデSalomoni INFN-CNAF国家の研究所

   Phone:  +39 51 6098-260
   Fax:    +39 51 6098 135
   EMail: Salomoni@infn.it

以下に電話をしてください。 +39 51 6098-260Fax: +39 51 6098 135メール: Salomoni@infn.it

   Cristina Vistoli
   INFN-CNAF
   National Institute of Nuclear Physics - National Networking Center
   V.le Ercolani, 8
   40138 Bologna - Italy

核物理学--8歳のセンターのV.leエルコラーニのために40138ボローニャをネットワークでつないでいる国立--イタリアのクリスティーナVistoli INFN-CNAF国家の研究所

   Phone:  +39 51 6098-260
   Fax:    +39 51 6098 135
   EMail: Vistoli@infn.it

以下に電話をしてください。 +39 51 6098-260Fax: +39 51 6098 135メール: Vistoli@infn.it

   Antonia Ghiselli
   INFN-CNAF
   National Institute of Nuclear Physics - National Networking Center
   V.le Ercolani, 8
   40138 Bologna - Italy

核物理学--8歳のセンターのV.leエルコラーニのために40138ボローニャをネットワークでつないでいる国立--イタリアのアントニアGhiselli INFN-CNAF国家の研究所

   Phone:  +39 51 6098-267
   Fax:    +39 51 6098 135
   EMail: Ghiselli@infn.it

以下に電話をしてください。 +39 51 6098-267Fax: +39 51 6098 135メール: Ghiselli@infn.it

Ghiselli, Salomoni & Vistoli                                    [Page 4]

Ghiselli、Salomoni、およびVistoli[4ページ]