RFC1937 日本語訳

Network Working Group                                         Y. Rekhter
Request for Comments: 1937                                 Cisco Systems
Category: Informational                                       D. Kandlur
                                  T.J. Watson Research Center, IBM Corp.
                                                                May 1996

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

  "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks

切り換えられたデータ・リンクサブネットワークでの「地方かリモートな」推進決定

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

要約

   The IP architecture assumes that each Data Link subnetwork is labeled
   with a single IP subnet number. A pair of hosts with the same subnet
   number communicate directly  (with no routers); a pair of hosts with
   different subnet numbers always communicate through one or more
   routers. As indicated in RFC1620, these assumptions may be too
   restrictive for large data networks, and specifically for networks
   based on switched virtual circuit (SVC) based technologies (e.g. ATM,
   Frame Relay, X.25), as these assumptions impose constraints on
   communication among hosts and routers through a network.  The
   restrictions may preclude full utilization of the capabilities
   provided by the underlying SVC-based Data Link subnetwork.  This
   document describes extensions to the IP architecture that relaxes
   these constraints, thus enabling the full utilization of the services
   provided by SVC-based Data Link subnetworks.

IPアーキテクチャは、それぞれのData Linkサブネットワークがただ一つのIPサブネット番号でラベルされると仮定します。 同じサブネット番号をもっている1組のホストは直接伝達します(ルータなしで)。 異なったサブネット番号をもっている1組のホストは1つ以上のルータを通っていつも交信します。 RFC1620にみられるように、大きいデータ網、および特に交換仮想回路の(SVC)ベースの技術(例えば、ATM、Frame Relay、X.25)に基づくネットワークにおいて、これらの仮定は制限し過ぎているかもしれません、これらの仮定がネットワークを通してホストとルータの中で規制をコミュニケーションに課すとき。 制限は基本的なSVCベースのData Linkサブネットワークによって提供された能力の完全利用を排除するかもしれません。 このドキュメントはこれらの規制を弛緩するIPアーキテクチャに拡大について説明します、その結果、SVCベースのData Linkサブネットワークによって提供されたサービスの完全利用を可能にします。

1.  Background

1. バックグラウンド

   The following briefly recaptures the concept of the IP Subnet.  The
   topology is assumed to be composed of hosts and routers
   interconnected via links (Data Link subnetworks).  An IP address of a
   host with an interface attached to a particular link is a tuple
   <prefix length, address prefix, host number>, where host number is
   unique within the subnet address prefix.  When a host needs to send
   an IP packet to a destination, the host needs to determine whether
   the destination address identifies an interface that is connected to
   one of the links the host is attached to, or not.  This referred to
   as the "local/remote" decision. The outcome of the "local/remote"
   decision is based on (a) the destination address, and (b) the address
   and the prefix length associated with the the local interfaces.  If
   the outcome is "local", then the host resolves the IP address to a
   Link Layer address (e.g. by using ARP), and then sends the packet

以下は簡潔にIP Subnetの概念を取り戻します。 リンク(データLinkサブネットワーク)を通してインタコネクトされたホストとルータでトポロジーが構成されると思われます。 インタフェースが特定のリンクに付けられているホストのIPアドレスはtuple<接頭語の長さです、アドレス接頭語、ホスト番号>、ホスト番号がサブネットアドレス接頭語の中でユニークであるところで。 ホストが、IPパケットを目的地に送る必要があると、ホストは、送付先アドレスがホストが付けられているリンクの1つに接続されるインタフェースを特定するかどうか決定する必要があります。 これは「地方かリモートな」決定を呼びました。 「地方かリモートな」決定の結果は(b) 局所界面に関連している(a) 送付先アドレス、アドレス、および接頭語の長さに基づいています。 結果が「地方である」なら、ホストは、Link Layerアドレス(例えば、ARPを使用するのによる)にIPアドレスを決議して、パケットを送ります。

Rekhter & Kandlur            Informational                      [Page 1]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[1ページ]のRFC1937

   directly to that destination (using the Link layer services).  If the
   outcome is "remote", then the host uses one of its first-hop routers
   (thus relying on the services provided by IP routing).

直接その目的地(Link層のサービスを利用する)に。 結果が「リモートである」なら、ホストは最初に、ホップルータの1つを使用します(その結果、IPルーティングで提供されたサービスに依存します)。

   To summarize, two of the important attributes of the IP subnet model
   are:

まとめる、IPサブネットモデルの2つの重要な属性は以下の通りです。

      hosts with a common subnet address prefix are assumed to be
      attached to a common link (subnetwork), and thus communicate with
      each other directly, without any routers - "local";

普通リンク(サブネットワーク)に付けられていて、その結果、一般的なサブネットアドレス接頭語をもっているホストが直接互いにコミュニケートすると思われます、少しもルータなしで--「地方です」。

      hosts with different subnet address prefixes are assumed to be
      attached to different links (subnetworks), and thus communicate
      with each other only through routers - "remote".

異なったリンク(サブネットワーク)に付けられていて、その結果、異なったサブネットアドレス接頭語をもっているホストがルータだけを通して互いにコミュニケートすると思われます--「リモートです」。

   A typical example of applying the IP subnet architecture to an SVC-
   based Data Link subnetwork is "Classical IP and ARP over ATM"
   (RFC1577).  RFC1577 provides support for ATM deployment that follows
   the traditional IP subnet model and introduces the notion of a
   Logical IP Subnetwork (LIS).  The consequence of this model is that a
   host is required to setup an ATM SVC to any host within its LIS; for
   destinations outside its LIS the host must forward packets through a
   router.  It is important to stress that this "local/remote" decision
   is based solely on the information carried by the destination address
   and the address and prefix lengths associated with the local
   interfaces.

SVCのベースのData LinkサブネットワークにIPサブネットアーキテクチャを適用する典型的な例は「気圧での古典的なIPとARP」(RFC1577)です。 RFC1577は伝統的なIPサブネットモデルに従うATM展開のサポートを提供して、Logical IP Subnetwork(LIS)の概念を紹介します。 このモデルの結果はホストがLISの中のどんなホストにもATM SVCをセットアップするのに必要であるということです。 LISの外の目的地に関しては、ホストはルータを通してパケットを進めなければなりません。 圧力に、この「地方かリモートな」決定が唯一送付先アドレスとアドレスによって運ばれた情報と局所界面に関連している接頭語の長さに基づいているのは、重要です。

2.  Motivations

2. 動機

   The diversity of TCP/IP applications results in a wide range of
   traffic characteristics.  Some applications last for a very short
   time and generate only a small number of packets between a pair of
   communicating hosts (e.g. ping, DNS). Other applications have a short
   lifetime, but generate a relatively large volume of packets (e.g.
   FTP). There are also applications that have a relatively long
   lifetime, but generate relatively few packets (e.g.  Telnet).
   Finally, we anticipate the emergence of applications that have a
   relatively long lifetime and generate a large volume of packets (e.g.
   video-conferencing).

TCP/IPアプリケーションの多様性はさまざまなトラフィックの特性をもたらします。 いくつかのアプリケーションが、1組の交信しているホストの間で非常に短い間続いて、少ない数のパケットだけを生成します(DNS、例えば、確認してください)。 他のアプリケーションは、短い生涯を持っていますが、パケット(例えば、FTP)の比較的大きいボリュームを生成します。 比較的長い生涯を持っている利用もありますが、比較的わずかなパケットが(例えば、Telnet)であると生成してください。 最終的に、私たちは比較的長い生涯を持って、多くのパケットを生成するアプリケーション(例えば、ビデオ会議)の出現を予期します。

   SVC-based Data Link subnetworks offer certain unique capabilities
   that are not present in other (non-SVC) subnetworks (e.g. Ethernet,
   Token Ring).  The ability to dynamically establish and tear-down SVCs
   between communicating entities attached to an SVC-based Data Link
   subnetwork enables the dynamic dedication and redistribution of
   certain communication resources (e.g. bandwidth) among the entities.
   This dedication and redistribution of resources could be accomplished
   by relying solely on the mechanism(s) provided by the Data Link

SVCベースのData Linkサブネットワークは他の(非SVC)サブネットワーク(例えば、イーサネット、Token Ring)で存在していないユニークなある能力を提供します。 SVCベースのData Linkサブネットワークに付けられた実体を伝えることの間のダイナミックに確立する能力と分解SVCsは実体の中で、あるコミュニケーションリソース(例えば、帯域幅)のダイナミックな奉納と再分配を可能にします。 唯一Data Linkによって提供されたメカニズムを当てにすることによって、この奉納と資源の再分配を実行できるでしょう。

Rekhter & Kandlur            Informational                      [Page 2]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[2ページ]のRFC1937

   layer.

層にしてください。

   The unique capabilities provided by SVC-based Data Link subnetworks
   do not come "for free".  The mechanisms that provide dedication and
   redistribution of resources have certain overhead (e.g. the time
   needed to establish an SVC, resources associated with maintaining a
   state for an SVC). There may also be a monetary cost associated with
   establishing and maintaining an SVC. Therefore, it is very important
   to be cognizant of such an overhead and to carefully balance the
   benefits provided by the mechanisms against the overhead introduced
   by such mechanisms.

SVCベースのData Linkサブネットワークによって提供されたユニークな能力は「ただで」来ません。 奉納と資源の再分配を提供するメカニズムはあるオーバーヘッドを持っています(例えば、時間は、SVCを設立する必要がありました、SVCのために状態を維持すると関連しているリソース)。 また、SVCを設立して、維持すると関連している貨幣原価があるかもしれません。 したがって、そのようなオーバーヘッドにおいて認識力があって、慎重にメカニズムによってそのようなメカニズムによって導入されたオーバーヘッドに対して提供された利益のバランスをとるのは非常に重要です。

   One of the key issues for using SVC-based Data Link subnetworks in
   the TCP/IP environment is the issue of switched virtual circuit (SVC)
   management.  This includes SVC establishment and tear-down, class of
   service specification, and SVC sharing.  At one end of the spectrum
   one could require SVC establishment between communicating entities
   (on a common Data Link subnetwork) for any application. At the other
   end of the spectrum, one could require communicating entities to
   always go through a router, regardless of the application.  Given the
   diversity of TCP/IP applications, either extreme is likely to yield a
   suboptimal solution with respect to the ability to efficiently
   exploit capabilities provided by the underlying Data Link layer.

TCP/IP環境でSVCベースのData Linkサブネットワークを使用するための主要な問題の1つは交換仮想回路(SVC)管理の問題です。 これはSVC設立、分解、サービス仕様のクラス、およびSVC共有を含んでいます。 スペクトルの片端では、人はどんなアプリケーションのためにも、実体(一般的なData Linkサブネットワークの)を伝えることの間のSVC設立を必要とすることができました。 範囲内で対照的に一方の側に、人は、いつもルータに直面するために実体を伝えるのを必要とすることができました、アプリケーションにかかわらず。 TCP/IPアプリケーションの多様性を考えて、どちらかの極端が効率的に基本的なData Link層で提供された能力を開発する能力に関して準最適のソリューションをもたらしそうです。

   The traditional IP subnet model is too restrictive for flexible and
   adaptive use of SVC-based Data Link subnetworks - the use of a
   subnetwork is driven by information completely unrelated to the
   characteristics of individual applications.  To illustrate the
   problem consider "Classical IP and ARP over ATM" (RFC1577).  RFC1577
   provides support for ATM deployment that follows the traditional IP
   subnet model, and introduces the notion of a Logical IP Subnetwork
   (LIS).  The consequence of this model is that a host is required to
   setup an SVC to any host within its LIS, and it must forward packets
   to destinations outside its LIS through a router.  This
   "local/remote" forwarding decision, and consequently the SVC
   management, is based solely on the information carried in the source
   and destination addresses and the subnet mask associated with the
   source address and has no relation to the nature of the applications
   that generated these packets.

SVCベースのData Linkサブネットワークのフレキシブルで適応型の使用において、伝統的なIPサブネットモデルは制限し過ぎています--サブネットワーク利用は個々のアプリケーションの特性に完全に関係ない情報によって促進されます。 問題を例証するには、「気圧での古典的なIPとARP」(RFC1577)を考えてください。 RFC1577は伝統的なIPサブネットモデルに従うATM展開のサポートを提供して、Logical IP Subnetwork(LIS)の概念を紹介します。 このモデルの結果はホストがLISの中のどんなホストにもSVCをセットアップするのに必要であるということです、そして、それはルータを通してLISの外の目的地にパケットを送らなければなりません。 この「地方かリモートな」推進決定、およびその結果SVC管理は、唯一ソースアドレスに関連しているソース、送付先アドレス、およびサブネットマスクで運ばれた情報に基づいていて、これらのパケットを生成したアプリケーションの本質に関係がありません。

3.  QoS/Traffic Driven "Local/Remote" Decision

3. QoS/トラフィックの駆動「地方かリモートな」決定

   Consider a host attached to an SVC-based Data Link subnetwork, and
   assume that the "local/remote" decision the host could make is not
   constrained by the IP subnet model. When such a host needs to send a
   packet to a destination, the host might consider any of the following
   options:

SVCベースのData Linkサブネットワークに付けられたホストを考えてください、そして、ホストがすることができた「地方かリモートな」決定がIPサブネットモデルによって抑制されないと思ってください。 そのようなホストが、パケットを目的地に送る必要があると、ホストは以下のオプションのどれかを考えるかもしれません:

Rekhter & Kandlur            Informational                      [Page 3]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[3ページ]のRFC1937

      Use a best-effort SVC to the first hop router.

最初のホップルータにベストエフォート型SVCを使用してください。

      Use an SVC to the first hop router dedicated to a particular type
      of service (ie: predictive real time).

特定のタイプのサービス(ie: 予言のリアルタイム)に捧げられた最初のホップルータにSVCを使用してください。

      Use a dedicated SVC to the first hop router.

最初のホップルータに専用SVCを使用してください。

      Use a best-effort SVC to a router closer to the destination than
      the first hop router.

目的地の最初のホップルータより近くでベストエフォート型SVCをルータに使用してください。

      Use an SVC to a router closer to the destination than the first
      hop router dedicated to a particular type of service.

目的地の特定のタイプのサービスに捧げられた最初のホップルータより近くでルータにSVCを使用してください。

      Use a dedicated SVC to a router closer to the destination than the
      first hop router.

目的地の最初のホップルータより近くで専用SVCをルータに使用してください。

      Use a best-effort SVC directly to the destination (if the
      destination is on the same Data Link subnetwork as the host).

直接目的地にベストエフォート型SVCを使用してください(ホストと同じData Linkサブネットワークの上に目的地があるなら)。

      Use an SVC directly to the destination dedicated to a particular
      type of service (if the destination is on the same Data Link
      subnetwork as the host).

直接特定のタイプのサービスに捧げられた目的地にSVCを使用してください(ホストと同じData Linkサブネットワークの上に目的地があるなら)。

      Use a dedicated SVC directly to the destination (if the
      destination is on the same Data Link subnetwork as the host).

直接目的地に専用SVCを使用してください(ホストと同じData Linkサブネットワークの上に目的地があるなら)。

   In the above we observe that the forwarding decision at the host is
   more flexible than the "local/remote" decision of the IP subnet
   model. We also observe that the host's forwarding decision may take
   into account QoS and/or traffic requirements of the applications
   and/or cost factors associated with establishing and maintaining a
   VC, and thus improve the overall SVC management. Therefore, removing
   constraints imposed by the IP subnet model is an important step
   towards better SVC management.

上記では、私たちは、ホストでの推進決定がIPサブネットモデルの「地方かリモートな」決定よりフレキシブルであることを観測します。 私たちは、また、ホストの推進決定がVCを設立して、維持すると関連しているアプリケーション、そして/または、コスト要因のQoS、そして/または、トラフィック要件を考慮に入れるかもしれないのを観測して、その結果、総合的なSVC管理を改良します。 したがって、IPサブネットモデルによって課された規制を取り除くのは、より良いSVC管理に向かった重要なステップです。

3.1 Extending the scope of possible "local" outcomes

3.1 可能な「地方」の結果の範囲を広げること。

   A source may have an SVC (either dedicated or shared) to a
   destination if both the source and the destination are on a common
   Data Link subnetwork. The ability to create and use the SVC (either
   dedicated or shared) is completely decoupled from the source and
   destination IP addresses, but is instead coupled to the QoS and/or
   traffic characteristics of the application. In other words, the
   ability to establish a direct VC (either dedicated or shared) between
   a pair of hosts on a common Data Link subnetwork has nothing to do
   with the IP addresses of the hosts. In contrast with the IP subnet
   model (or the LIS mode), the "local" outcome becomes divorced from
   the addressing information.

一般的なData Linkサブネットワークの上にソースと目的地の両方があるなら、ソースはSVC(捧げられるか、または共有される)を目的地に持っているかもしれません。 SVC(捧げられるか、または共有される)を作成して、使用する能力は、IPが演説するソースと目的地から完全に衝撃を吸収されますが、代わりにアプリケーションのQoS、そして/または、トラフィックの特性と結合されます。 言い換えれば、一般的なData Linkサブネットワークの上に1組のホストの間のダイレクトVC(捧げられるか、または共有される)を設立する能力はホストのIPアドレスと関係ありません。 IPサブネットモデル(または、LISモード)と比べて、「地方」の結果はアドレス指定情報から離婚するようになります。

Rekhter & Kandlur            Informational                      [Page 4]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[4ページ]のRFC1937

3.2 Allowing the "remote" outcome where applicable

3.2 適切であるところに「リモートな」結果を許容すること。

   A source may go through one or more routers to reach a destination if
   either (a) the destination is not on the same Data Link subnetwork as
   the source, or (b) the destination is on the same Data Link
   subnetwork as the source, but the QoS and/or traffic requirements of
   the application on the source do not justify a direct (either
   dedicated or shared) VC.

(a) ソースと同じData Linkサブネットワークの上に目的地がないか、またはソースと同じData Linkサブネットワークの上に(b) 目的地があるなら、ソースは目的地に達するように1つ以上のルータに直面するかもしれませんが、ソースにおけるアプリケーションのQoS、そして/または、トラフィック要件はダイレクトな(捧げられるか、または共有される)VCを正当化しません。

   When the destination is not on the same Data Link subnetwork as the
   source, the source may select between either (a) using its first-hop
   (default) router, or (b) establishing a "shortcut" to a router closer
   to the destination than the first-hop router.  The source should be
   able to select between these two choices irrespective of the source
   and destination IP addresses.

(a) 最初に、ホップ(デフォルト)ルータを使用するか、または(b) 目的地の最初に、ホップルータより近くにルータへの「近道」を設立するとき、ソースは、ソースと同じData Linkサブネットワークで目的地がいつでないかを選択するかもしれません。 ソースはソースと目的地において関係ないこれらの2つの選択の間でIPアドレスを選択できるべきです。

   When the destination is on the same Data Link subnetwork as the
   source, but the QoS and/or traffic requirements do not justify a
   direct VC, the source should be able to go through a router
   irrespective of the source and destination IP addresses.

ソースと同じData Linkサブネットワークの上に目的地がありますが、QoS、そして/または、トラフィック要件がダイレクトVCを正当化しないとき、ソースはIPが演説するソースと目的地の如何にかかわらずルータに直面できるべきです。

   In contrast with the IP subnet model (or the LIS model) the "remote"
   outcome, and its particular option (first-hop router versus router
   closer to the destination than the first-hop router), becomes
   decoupled from the addressing information.

IPサブネットと比べて「リモートな」結果、およびその特定のオプションをモデル化してください、(または、LISモデル)(最初に、ホップルータ対ルータ、最初に、ホップルータより目的地について近い)、アドレス指定情報から衝撃を吸収されるようになります。

3.3 Sufficient conditions for direct connectivity

3.3 ダイレクト接続性のための十分条件

   The ability of a host to establish an SVC to a peer  on a common
   switched Data Link subnetwork is predicated on its knowledge  of the
   Link Layer address of the peer or an intermediate point closer to the
   destination.  This document assumes the existence of mechanism(s)
   that can provide the host with this information. Some of the possible
   alternatives are NHRP, ARP, or static configuration; other
   alternatives are not precluded.  The ability to acquire the Link
   Layer address of the peer should not be viewed as an indication that
   the host and the peer can establish an SVC - the two may be on
   different Data Link subnetworks, or may be on a common Data Link
   subnetwork that is partitioned.

ホストが一般的な切り換えられたData Linkサブネットワークの上に同輩にSVCを設立する能力は目的地の、より近くで同輩のLink Layerアドレスか中間的ポイントに関する知識で叙述されます。 このドキュメントはこの情報をホストに提供できるメカニズムの存在を仮定します。 可能な代替手段のいくつかが、NHRP、ARP、または静的な構成です。 他の代替手段は排除されません。 ホストと同輩がSVCを設立できるという指示として同輩のLink Layerアドレスを習得する能力を見なすべきではありません--2は、異なったData Linkサブネットワークの上にあるか、または仕切られる一般的なData Linkサブネットワークの上にあるかもしれません。

3.4 Some of the implications

3.4 含意のいくつか

   Since the "local/remote" decision would depend on factors other than
   the addresses of the source and the destination, a pair of hosts may
   simultaneously be using two different means to reach each other,
   forwarding traffic for applications with different QoS/and or traffic
   characteristics differently.

ソースのアドレス以外の要素に依存して、目的地であり同時に、1組のホストがいるかもしれないという「地方かリモートな」決定以来、互いに届く2つの異なった手段を使用して、進めて、特性を異なって異なったQoS/とのアプリケーションのために取引して、または、取引してください。

Rekhter & Kandlur            Informational                      [Page 5]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[5ページ]のRFC1937

3.5 Address assignment

3.5 アドレス課題

   It is expected that if the total number of hosts and routers on a
   common SVC-based Data Link subnetwork is sufficiently large, then the
   hosts and routers could be partitioned into groups, called Local
   Addressing Groups (LAGs). Each LAG would have hosts and routers. The
   routers within a LAG would act as the first-hop routers for the hosts
   in the LAG. If the total number of hosts and routers is not large,
   then all these hosts and routers could form a single LAG. Criteria
   for determining LAG sizes are outside the scope of this document.

Local Addressing Groups(LAGs)は、一般的なSVCベースのData Linkサブネットワークの上のホストとルータの総数が十分大きいならホストとルータがグループに仕切られるかもしれないと予想されると呼びました。 各LAGには、ホストとルータがあるでしょう。 LAGの中のルータはホストのための最初に、ホップルータとしてLAGで機能するでしょう。 ホストとルータの総数が大きくないなら、これらのすべてのホストとルータが独身のLAGを形成するかもしれません。 このドキュメントの範囲の外にLAGサイズを決定する評価基準があります。

   To provide scalable routing each LAG should be given an IP address
   prefix, and elements within the LAG should be assigned addresses out
   of this prefix. The routers in a LAG would then advertise (via
   appropriate routing protocols) routes to the prefix associated with
   the LAG. These routes would be advertised as "directly reachable"
   (with metric 0). Thus, routers within a LAG would act as the last-hop
   routers for the hosts within the LAG.

各LAGをスケーラブルなルーティングに提供するのにIPアドレス接頭語を与えるべきです、そして、LAGの中の要素はこの接頭語からの割り当てられたアドレスであるべきです。 そして、LAGのルータはLAGに関連している接頭語にルートの広告を出すでしょう(適切なルーティング・プロトコルで)。 「直接届く」(メートル法の0がある)としてこれらのルートの広告を出すでしょう。 したがって、LAGの中のルータはホストのための最後のホップルータとしてLAGの中で機能するでしょう。

4. Conclusions

4. 結論

   Different approaches to SVC-based Data Link subnetworks used by
   TCP/IP yield substantially different results with respect to the
   ability of TCP/IP applications to efficiently exploit the
   functionality provided by such subnetworks.  For example, in the case
   of ATM both LAN Emulation [LANE] and "classical" IP over ATM
   [RFC1577] localize host changes below the IP layer, and therefore may
   be good first steps in the ATM deployment.  However, these approaches
   alone are likely to be inadequate for the full utilization of ATM.

TCP/IPによって使用されるSVCベースのData Linkサブネットワークへの異なるアプローチはTCP/IPアプリケーションが効率的にそのようなサブネットワークによって提供された機能性を利用する能力に関して実質的に異なった結果をもたらします。 例えば、ATMの場合では、LAN Emulation[レーン]とATMの上の「古典的な」IP[RFC1577]の両方が、IP層の下でホストに変化を局部にとどめて、したがって、ATM展開で良い第一歩であるかもしれません。 しかしながら、これらのアプローチだけがATMの完全利用に不十分である傾向があります。

   It appears that any model that does not allow SVC management based on
   QoS and/or traffic requirements will preempt the full use of SVC-
   based Data Link subnetworks.  Enabling more direct connectivity for
   applications that could benefit from the functionality provided by
   SVC-based Data Link subnetworks, while relying on strict hop by hop
   paths for other applications, could facilitate exploration of the
   capabilities provided by these subnetworks.

QoSに基づくSVC管理、そして/または、要件が先取りするトラフィックにSVCの完全利用を許容しないどんなモデルもData Linkサブネットワークを基礎づけたように見えます。 他のアプリケーションのためにホップ経路のそばで厳しいホップを当てにしている間にSVCベースのData Linkサブネットワークによって提供された機能性の利益を得ることができたアプリケーションのために、よりダイレクトな接続性を可能にすると、これらのサブネットワークによって提供された能力の探検は容易にされるかもしれません。

   While this document does not define any specific coupling between
   various QoS, traffic characteristics and other parameters, and SVC
   management, it is important to stress that efforts towards
   standardization of various QoS, traffic characteristics, and other
   parameters than an application could use (through an appropriate API)
   to influence SVC management are essential for flexible and adaptive
   use of SVC-based Data Link subnetworks.

このドキュメントは様々なQoSと、トラフィックの特性と、他のパラメタと、SVC管理の間のどんな特定のカップリングも定義しませんが、SVCベースのData Linkサブネットワークのフレキシブルで適応型の使用に、様々なQoS、トラフィックの特性、およびアプリケーションがSVC管理に影響を及ぼすのに使用するかもしれないこと(適切なAPIを通して)以外のパラメタの標準化に向かった取り組みが不可欠であることは、圧力に重要です。

Rekhter & Kandlur            Informational                      [Page 6]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[6ページ]のRFC1937

   The proposed model utilizes the SVC-based infrastructure for the
   applications that could benefit from the capabilities supported
   within such an infrastructure, and takes advantage of a router-based
   overlay for all other applications.  As such it provides a balanced
   mix of router-based and switch-based infrastructures, where the
   balance could be determined by the applications requirements.

提案されたモデルは、そのようなインフラストラクチャの中でサポートされた能力の利益を得ることができたアプリケーションにSVCベースのインフラストラクチャを利用して、他のすべてのアプリケーションにルータベースのオーバレイを利用します。 そういうものとして、それはルータベースの、そして、スイッチベースのインフラストラクチャのバランスのとれているミックスを提供します。(そこでは、バランスがアプリケーション要件で決定するかもしれません)。

5. Security Considerations

5. セキュリティ問題

   Security issues are not discussed in this memo.

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

6. Acknowledgements

6. 承認

   The authors would like to thank Joel Halpern (NewBridge), Allison
   Mankin (ISI), Tony Li (cisco Systems), Andrew Smith (BayNetworks),
   and Curtis Villamizar (ANS) for their review and comments.

作者は彼らのレビューとコメントについてジョエル・アルペルン(NewBridge)、アリソン・マンキン(ISI)、トニー・李(コクチマスSystems)、アンドリュー・スミス(BayNetworks)、およびカーティスVillamizar(ANS)に感謝したがっています。

References

参照

   [LANE] "LAN Emulation over ATM specification - version 1", ATM Forum,
   Feb.95.

[レーン]、「ATM仕様の上のLAN Emulation--バージョン1インチ、ATM Forum、Feb.95、」

   [Postel 81] Postel, J., Sunshine, C., Cohen, D., "The ARPA Internet
   Protocol", Computer Networks, 5, pp. 261-271, 1983.

[ポステル81]ポステル、J.、サンシャイン、C.、コーエン、D.、「アルパインターネットプロトコル」、コンピュータNetworks、5、ページ 261-271, 1983.

   [RFC792]  Postel, J., "Internet Control Message Protocol- DARPA
   Internet Program Protocol Specification", STD 5, RFC 792, ISI,
   September 1981.

[RFC792] ポステル、J.、「インターネット規制メッセージプロトコルDARPAインターネットプログラムプロトコル仕様」、STD5、RFC792、ISI、1981年9月。

   [RFC1122]  Braden, R., Editor, "Requirements for Internet Hosts -
   Communication Layers", STD 3, RFC 1122, USC/ISI, October 1989.

[RFC1122] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、USC/ISI、10月1989日

   [RFC1577] Laubach, M., "Classical IP and ARP over ATM", January 1994.

1994年1月の[RFC1577]Laubachと、M.と、「気圧での古典的なIPとARP」

   [RFC1620] Braden, R., Postel, J., Rekhter, Y., "Internet Architecture
   Extensions for Shared Media", May 1994.

R.、ポステル、J.、Rekhter、Y.、「共有されたメディアのためのインターネットアーキテクチャ拡大」という[RFC1620]ブレーデンは1994がそうするかもしれません。

   [RFC1755] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E.,
   Malis, A., "ATM Signalling Support for IP over ATM", January 1995.

[RFC1755] ペレス、M.、Liaw、F.、グロースマン、D.、マンキン、A.、ホフマン、E.、Malis、A.、「気圧でのIPの気圧合図サポート」、1995年1月。

Rekhter & Kandlur            Informational                      [Page 7]

RFC 1937        Forwarding in Switched Data Link Subnets        May 1996

1996年5月に切り換えられたデータ・リンクでサブネットを進めるRekhter&Kandlurの情報[7ページ]のRFC1937

14.  Authors' Addresses

14. 作者のアドレス

   Yakov Rekhter
   Cisco Systems
   170 West Tasman Drive,
   San Jose, CA 95134-1706

ヤコフRekhterシスコシステムズ170の西タスマンDrive、サンノゼ、カリフォルニア95134-1706

   Phone:  (914) 528-0090
   EMail:  yakov@cisco.com

以下に電話をしてください。 (914) 528-0090 メールしてください: yakov@cisco.com

   Dilip Kandlur
   T.J. Watson Research Center IBM Corporation
   P.O. Box 704
   Yorktown Heights, NY 10598

ニューヨーク ディリップKandlur T.J.ワトソン研究所IBM社の私書箱704ヨークタウンの高さ、10598

   Phone:  (914) 784-7722
   EMail:  kandlur@watson.ibm.com

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

Rekhter & Kandlur            Informational                      [Page 8]

Rekhter&Kandlur情報です。[8ページ]