RFC1674 日本語訳

1674 A Cellular Industry View of IPng. M. Taylor. August 1994. (Format: TXT=6157 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          M. Taylor
Request for Comments: 1674                               CDPD Consortium
Category: Informational                                      August 1994

コメントを求めるワーキンググループM.テイラーの要求をネットワークでつないでください: 1674年のCDPD共同体カテゴリ: 情報の1994年8月

                    A Cellular Industry View of 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 memo is a response to RFC 1550, "IP: Next Generation (IPng)
   White Paper Solicitation".  The statements in this paper are intended
   as input to the technical discussions within IETF, and do not
   represent any endorsement or commitment on the part of the cellular
   industry, the Cellular Digital Packet Data (CDPD) consortium of
   service providers or any of its constituent companies.

このメモがRFC1550への応答である、「IP:」 「次世代(IPng)白書懇願。」 この紙での声明は、技術面の協議に入力されるようにIETFの中で意図して、セル産業(サービスプロバイダーか構成会社のどれかのアナログ式の携帯電話通信網を利用してパケット交換方式のデジタル無線データ通信を提供するサービス(CDPD)共同体)側の少しの裏書きや委任も表しません。

Introduction

序論

   This is a draft of the requirements for IPng as envisioned by
   representatives of the Cellular Digital Packet Data (CDPD) consortium
   of service providers.  As the leading service providers for this
   nascent technology, which will provide the capability for mobility of
   native mainstream connectionless network layer-based applications it
   is our intention to support whatever form IPng takes.  However, there
   are several requirements which we feel IPng must meet.

サービスプロバイダーのアナログ式の携帯電話通信網を利用してパケット交換方式のデジタル無線データ通信を提供するサービス(CDPD)共同体の代表によって思い描かれるようにこれはIPngのための要件の草稿です。 この初期の技術のための主なサービスプロバイダーとして、それはIPngが取るどんな形も支えるという私たちの意志です。(技術は固有の主流のコネクションレスなネットワーク層ベースのアプリケーションの移動性に能力を提供するでしょう)。 しかしながら、私たちが、IPngが満たさなければならないと感じるいくつかの必要条件があります。

Mobility

移動性

   Since we will offer mobile services, our primary requirement is that
   IPng not inhibit our support of mobility.  IPng must not impede
   devices from being able to operate anywhere anytime.  Applications on
   these mobile devices must look and feel the same to the user
   regardless of location.  NPDUs should be self-contained and not
   disallow the redirection inherent to our mobility solution, i.e.,
   IPng must be connectionless.

私たちがモバイルサービスを提供するつもりであるので、私たちのプライマリ要件はIPngが私たちの移動性のサポートを抑制しないということです。 IPngは、どこでもいつでも作動できるので、デバイスを妨害してはいけません。 これらのモバイル機器におけるアプリケーションは、位置にかかわらずユーザにとって同じであると見て、感じられるに違いありません。 NPDUsは自己充足的であり、私たちの移動性ソリューションに固有のリダイレクションを禁じるはずがありません、すなわち、IPngはコネクションレスであるに違いありません。

   Further, since IPng provides an opportunity for design enhancements
   above and beyond IPv4, we propose that native support for mobility be
   regarded as an explicit IPng requirement.  Local area and wide area
   wireless technology creates new opportunities for both TCP/IP and the
   Internet.  Although the capability for mobility is orthogonal to the
   wired or wireless nature of the data link in use, the rapid

さらに、IPngがIPv4を超えたデザイン増進に機会を与えるので、私たちは、移動性のネイティブのサポートが明白なIPng要件と見なされるよう提案します。 局部と広い領域無線技術はTCP/IPとインターネットの両方の新しい機会を作成します。 移動性のための能力はデータのワイヤードであるかワイヤレスの本質と直交していますが、使用、急速でリンクしてください。

Taylor                                                          [Page 1]

RFC 1674            A Cellular Industry View of IPng         August 1994

テイラー[1ページ]RFC1674 IPng1994年8月のセル企業側の見解

   deployment wireless technology amplifies the requirement for
   topological flexibility.

展開無線技術は位相的な柔軟性のための要件を増幅します。

   As a by-product of mobility, the significance of "occasionally-
   connected hosts" increases.  The ability to accommodate
   occasionally-connected hosts in IPng is a requirement.

移動性の副産物として、「時折接続されたホスト」の意味は増加します。 IPngに時折接続されたホストを収容する能力は要件です。

Scale

スケール

   In terms of scale, we envision some 20 to 40 million users by the
   year 2007.  In this context a "user" can be anything from a vending
   machine to a "road warrior".  These numbers are for North America
   alone.  Worldwide, we anticipate that IPng should be able to support
   billions of "users".  Of course, the sparseness of network address
   assignments which is necessary for subnetting, etc., dictates that
   IPng should support at least tens or hundreds of billions of
   addresses.

スケールに関して、私たちは2007年までにおよそ20〜4000万人のユーザを思い描きます。 自動販売機から「道行く戦士」までこのような関係においては「ユーザ」は何かであるかもしれません。 北アメリカにはこれらの数が単独であります。 世界中では、私たちは、IPngが何十億「ユーザ」をサポートするはずであることができると予期します。 もちろん、ネットワーク・アドレス課題のサブネッティングなどに必要な希薄性はIPngが少なくとも10か何千億ものアドレスをサポートするはずであると決めます。

Addressing

アドレシング

   In terms of addressing, we would expect addresses to be hierarchical.
   In addition, a node with multiple links should require only a single
   address although more than one address should also be possible.  The
   mapping of names to addresses should be independent of location; an
   address should be an address, not a route.  Variable-length
   addressing is also required to ensure continued protocol (IPng)
   extensibility.  Administration of address assignments should be
   distributed and not centralized as it is now.

アドレシングで、私たちは、アドレスが階層的であると予想するでしょう。 さらに、また、1つ以上のアドレスも可能であるべきですが、複数のリンクがあるノードはただ一つのアドレスだけを必要とするはずです。 アドレスへの名前のマッピングは位置から独立しているべきです。 アドレスはルートではなく、アドレスであるべきです。 また、可変長のアドレシングが、継続的なプロトコル(IPng)伸展性を確実にするのに必要です。 現在ので、アドレス課題の政権を広げて、集結するべきではありません。

Security

セキュリティ

   IPng should also support security mechanisms which will grow
   increasingly important on the proverbial "information highway" for
   commercial users.  Security services which may optionally be expected
   from a Layer 3 entity such as IPng include peer entity
   authentication, data confidentiality, traffic flow confidentiality,
   data integrity and location confidentiality.

また、IPngは、セキュリティがますますことわざの「情報ハイウェイ」で営利的ユーザには重要になるメカニズムであるとサポートするはずです。 IPngなどのLayer3実体から任意に予想されるかもしれないセキュリティー・サービスは同輩実体認証、データの機密性、交通の流れ秘密性、データ保全、および位置の秘密性を含んでいます。

Accounting

会計

   The ability to do accounting at Layer 3 is a requirement.  The CDPD
   specification can be used as a model of the type of accounting
   services that we need.

Layer3に会計をする能力は要件です。 私たちが必要とする会計サービスのタイプのモデルとしてCDPD仕様を使用できます。

Taylor                                                          [Page 2]

RFC 1674            A Cellular Industry View of IPng         August 1994

テイラー[2ページ]RFC1674 IPng1994年8月のセル企業側の見解

Route Selection

ルート選択

   In the voice communications arena, "equal access" and choice of an
   "interexchange carrier (IXC)" are issues that must be addressed.
   Similar requirements for data may also exist.

声のコミュニケーションアリーナでは、「同等のアクセス」と「相互交換接続キャリア(IXC)」の選択は扱わなければならない問題です。 また、データのための同様の要件は存在するかもしれません。

   Source- and policy-based routing for inter-domain traffic can address
   this requirement.  IPng must allow the selection of at least the
   first transient network service provider based on the source host.

相互ドメイントラフィックのためのソースと方針ベースのルーティングはこの要件を扱うことができます。 IPngは第1代少なくとも送信元ホストに基づく一時的なネットワークサービスプロバイダーの選択を許さなければなりません。

Data Efficiency

データ効率

   The bandwidth of wide area wireless networks is a precious resource,
   the use of which must be optimized.  IPng must allow optimal use of
   the underlying Layer 2 medium.  Layer 3 Protocol Control Information
   (PCI) should be as condensed as possible.  The protocol should be
   optimized for data efficiency.

広い領域ワイヤレス・ネットワークの帯域幅は貴重なリソースです。それの使用を最適化しなければなりません。 IPngは基本的なLayer2媒体の最適の使用を許さなければなりません。 層3のプロトコルControl情報(PCI)はできるだけ凝縮しているべきです。 プロトコルはデータ効率のために最適化されるべきです。

   Packet prioritization must also be supported by IPng in order to
   optimize the use of low speed networks.  This requirement includes
   both class and grade of service definitions for flexibility.

また、IPngは、低速ネットワークの使用を最適化するためにパケット優先順位づけをサポートしなければなりません。 この要件はクラスと柔軟性のためのサービス定義のグレードの両方を含んでいます。

Transition

変遷

   The final requirement for IPng is that it must interoperate with IP
   for the foreseeable future.  Bridging mechanisms must be supported
   and a strategy for the transition from IPv4 to IPng must be defined.
   Use of options fields, etc., are one mechanism to support the
   requirement for IPng protocols to support IP addresses and headers.

IPngのための最終的な要件は予見できる未来のIPと共に共同利用しなければならないということです。 メカニズムをブリッジするのをサポートしなければなりません、そして、IPv4からIPngまでの変遷のための戦略を定義しなければなりません。 オプション分野などの使用はIPngプロトコルがIPがアドレスとヘッダーであるとサポートするという要件をサポートする1つのメカニズムです。

Security Considerations

セキュリティ問題

   See section on Security.

Securityの上のセクションを見てください。

Author's Address

作者のアドレス

   Mark S. Taylor
   Director of System Development
   McCaw Cellular Communications, Inc.
   Wireless Data Division
   10230 NE Points Drive
   Kirkland, WA 98033-7869 USA

S.テイラーがシステム開発マッコー移動体通信Inc.の指導官であるとワイヤレスの10230データ部NeポイントDriveワシントン98033-7869カークランド(米国)マークしてください。

   EMail: mark.s.taylor@airdata.com

メール: mark.s.taylor@airdata.com

Taylor                                                          [Page 3]

テイラー[3ページ]

一覧

 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 

スポンサーリンク

Date.getUTCDate

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

上に戻る