RFC1932 日本語訳
1932 IP over ATM: A Framework Document. R. Cole, D. Shur, C.Villamizar. April 1996. (Format: TXT=68031 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Cole
Request for Comments: 1932 D. Shur
Category: Informational AT&T Bell Laboratories
C. Villamizar
ANS
April 1996
コメントを求めるワーキンググループR.コールの要求をネットワークでつないでください: 1932年のD.シュルカテゴリ: 情報のAT&Tベル研究所C.Villamizar ANS1996年4月
IP over ATM: A Framework Document
気圧でのIP: フレームワークドキュメント
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 discussions of the IP over ATM working group over the last several years have produced a diverse set of proposals, some of which are no longer under active consideration. A categorization is provided for the purpose of focusing discussion on the various proposals for IP over ATM deemed of primary interest by the IP over ATM working group. The intent of this framework is to help clarify the differences between proposals and identify common features in order to promote convergence to a smaller and more mutually compatible set of standards. In summary, it is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.
ここ数年間のATMワーキンググループの上のIPの議論はさまざまの提案を起こしました。その或るものはもう活発な考慮でないのであります。 IPのためにATMワーキンググループの上で主要な関心についてIPによって考えられたATMの上で様々な提案に議論の焦点を合わせる目的に分類を提供します。 このフレームワークの意図は、より小さくて互いによりコンパチブルセットの規格に集合を促進するために提案の違いをはっきりさせて、共通点を特定するのを助けることです。 概要では、アプローチと問題が助けるATMを分類することにおけるこのドキュメントがATMワーキンググループの方向の上でIPの焦点を合わせることが望まれています。
1. Introduction
1. 序論
The IP over ATM Working Group of the Internet Engineering Task Force (IETF) is chartered to develop standards for routing and forwarding IP packets over ATM sub-networks. This document provides a classification/taxonomy of IP over ATM options and issues and then describes various proposals in these terms.
ATMインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の上のIPは、ルーティングとATMサブネットワークの上にIPパケットを送る規格を開発するためにチャーターされます。 このドキュメントは、IPの分類/分類学をATMオプションと問題の上に提供して、次に、これらの用語で様々な提案について説明します。
The remainder of this memorandum is organized as follows:
このメモの残りは以下の通り組織化されます:
o Section 2 defines several terms relating to networking and
internetworking.
o セクション2は、ネットワークとインターネットワーキングに関連しながら、いくつかの用語を定義します。
o Section 3 discusses the parameters for a taxonomy of the
different ATM models under discussion.
o セクション3は議論で異なったATMモデルの分類学のためのパラメタについて論じます。
o Section 4 discusses the options for low level encapsulation.
o セクション4は低い平らなカプセル化のためのオプションについて論じます。
Cole, Shur & Villamizar Informational [Page 1] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[1ページ]のRFC1932IP: フレームワークドキュメント1996年4月
o Section 5 discusses tradeoffs between connection oriented and
connectionless approaches.
o セクション5は接続指向の、そして、コネクションレスなアプローチの間の見返りを論じます。
o Section 6 discusses the various means of providing direct
connections across IP subnet boundaries.
o セクション6はIPサブネット境界の向こう側にダイレクト接続を提供する様々な手段を論じます。
o Section 7 discusses the proposal to extend IP routing to better
accommodate direct connections across IP subnet boundaries.
o セクション7はIPサブネット境界の向こう側にダイレクト接続をよりよく収容するためにIPルーティングを広げるという提案について論じます。
o Section 8 identifies several prominent IP over ATM proposals that
have been discussed within the IP over ATM Working Group and
their relationship to the framework described in this document.
o セクション8はATM作業部会の上でIPの中で議論したATM提案と本書では説明されたフレームワークとのそれらの関係の上で数個の際立ったIPを特定します。
o Section 9 addresses the relationship between the documents
developed in the IP over ATM and related working groups and the
various models discussed.
o セクション9はATM、関連するワーキンググループ、および議論した様々なモデルの上でIPで開発されたドキュメントの間の関係を扱います。
2. Definitions and Terminology
2. 定義と用語
We define several terms:
私たちはいくつかの用語を定義します:
A Host or End System: A host delivers/receives IP packets to/from
other systems, but does not relay IP packets.
ホストかエンドシステム: ホストは、他のシステムからの/にIPパケットを提供するか、または受けますが、IPパケットをリレーしません。
A Router or Intermediate System: A router delivers/receives IP
packets to/from other systems, and relays IP packets among
systems.
ルータか中間システム: ルータは、他のシステムからの/にIPパケットを提供するか、または受けて、システムの中でIPパケットをリレーします。
IP Subnet: In an IP subnet, all members of the subnet are able to
transmit packets to all other members of the subnet directly,
without forwarding by intermediate entities. No two subnet
members are considered closer in the IP topology than any other.
From an IP routing and IP forwarding standpoint a subnet is
atomic, though there may be repeaters, hubs, bridges, or switches
between the physical interfaces of subnet members.
IPサブネット: IPサブネットでは、サブネットのすべてのメンバーが直接サブネットの他のすべてのメンバーにパケットを伝えることができます、中間的実体による推進なしで。 いいえtwo、サブネットメンバーはいかなる他のもIPトポロジーの近くで考えられます。 IPルーティングとIP推進見地から、サブネットは原子です、サブネットメンバーの物理インターフェースの間には、リピータ、ハブ、ブリッジ、またはスイッチがあるかもしれませんが。
Bridged IP Subnet: A bridged IP subnet is one in which two or
more physically disjoint media are made to appear as a single IP
subnet. There are two basic types of bridging, media access
control (MAC) level, and proxy ARP (see section 6).
ブリッジしているIPサブネット: ブリッジしているIPサブネットは2以上がメディアを物理的にばらばらにならせるものはただ一つのIPサブネットとして現れさせられるということです。 2人の基本型をブリッジすること、メディアアクセス制御(MAC)レベル、およびプロキシARPがあります(セクション6を見てください)。
A Broadcast Subnet: A broadcast network supports an arbitrary
number of hosts and routers and additionally is capable of
transmitting a single IP packet to all of these systems.
放送サブネット: 放送網は、ホストとルータの特殊活字の数字をサポートして、さらに、単一のIPパケットをこれらのシステムのすべてに伝えることができます。
A Multicast Capable Subnet: A multicast capable subnet supports
a facility to send a packet which reaches a subset of the
destinations on the subnet. Multicast setup may be sender
マルチキャストのできるサブネット: マルチキャストのできるサブネットは、サブネットの目的地の部分集合に達するパケットを送るために施設をサポートします。 マルチキャストセットアップは送付者であるかもしれません。
Cole, Shur & Villamizar Informational [Page 2] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[2ページ]のRFC1932IP: フレームワークドキュメント1996年4月
initiated, or leaf initiated. ATM UNI 3.0 [4] and UNI 3.1
support only sender initiated while IP supports leaf initiated
join. UNI 4.0 will support leaf initiated join.
開始されるか、または開始されて、ページをめくります。 ATM UNI3.0[4]とUNI3.1は葉が開始したIPサポートが接合しますが、開始された送付者だけをサポートします。 4.0が開始された葉を支えるUNIは接合します。
A Non-Broadcast Multiple Access (NBMA) Subnet: An NBMA supports
an arbitrary number of hosts and routers but does not
natively support a convenient multi-destination connectionless
transmission facility, as does a broadcast or multicast capable
subnetwork.
非放送複数のアクセス(NBMA)サブネット: NBMAは、ホストとルータの特殊活字の数字をサポートしますが、便利なマルチの目的地がコネクションレスな通信施設であるとネイティブにサポートしません、放送やマルチキャストのできるサブネットワークのように。
An End-to-End path: An end-to-end path consists of two hosts which
can communicate with one another over an arbitrary number of
routers and subnets.
Endから端への経路: 終わりから端への経路は2人のホストから成ります(ルータとサブネットの特殊活字の数字の上でお互いにコミュニケートできます)。
An internetwork: An internetwork (small "i") is the concatenation
of networks, often of various different media and lower level
encapsulations, to form an integrated larger network supporting
communication between any of the hosts on any of the component
networks. The Internet (big "I") is a specific well known
global concatenation of (over 40,000 at the time of writing)
component networks.
インターネットワーク: インターネットワーク(小さい「i」)は、コンポーネントネットワークのいずれでもホストのどれかのコミュニケーションをサポートする統合より大きいネットワークを形成するためにはしばしばネットワーク、様々な異なったメディア、および下のレベルカプセル化の連結です。 インターネット(大きい「私」)は(書くこと時点の4万以上)コンポーネントネットワークの特定のよく知られているグローバルな連結です。
IP forwarding: IP forwarding is the process of receiving a packet
and using a very low overhead decision process determining how
to handle the packet. The packet may be delivered locally
(for example, management traffic) or forwarded externally. For
traffic that is forwarded externally, the IP forwarding process
also determines which interface the packet should be sent out on,
and if necessary, either removes one media layer encapsulation
and replaces it with another, or modifies certain fields in the
media layer encapsulation.
IP推進: IP推進はパケットを受けて、パケットを扱う方法を決定しながら非常に低い頭上の決定プロセスを使用するプロセスです。 パケットを局所的(例えば、管理トラフィック)に提供するか、または外部的に進めるかもしれません。 外部的に進めて、また、IP推進プロセスが、パケットがどのインタフェースに出されるべきであるかを決定して、必要なら、どちらかが1つのメディア層のカプセル化を移して、それを別のものに取り替えるか、またはメディアで、ある一定の分野を変更するということであるトラフィックには、カプセル化を層にしてください。
IP routing: IP routing is the exchange of information that takes
place in order to have available the information necessary to
make a correct IP forwarding decision.
IPルーティング: IPルーティングは正しいIP推進決定をするのに必要な利用可能な情報を持つために起こる情報交換です。
IP address resolution: A quasi-static mapping exists between IP
address on the local IP subnet and media address on the local
subnet. This mapping is known as IP address resolution.
An address resolution protocol (ARP) is a protocol supporting
address resolution.
IPアドレス解決: 準静的なマッピングはローカルアイピーサブネットに関するIPアドレスと地方のサブネットに関するメディアアドレスの間に存在しています。 このマッピングはIPアドレス解決として知られています。 アドレス解決プロトコル(ARP)はアドレスが解決であるとサポートするプロトコルです。
In order to support end-to-end connectivity, two techniques are used. One involves allowing direct connectivity across classic IP subnet boundaries supported by certain NBMA media, which includes ATM. The other involves IP routing and IP forwarding. In essence, the former technique is extending IP address resolution beyond the boundaries of the IP subnet, while the latter is interconnecting IP subnets.
終わりから終わりへの接続性をサポートするために、2つのテクニックが使用されています。 1つは、境界が、あるNBMAメディアでサポートした古典的なIPサブネットの向こう側にダイレクト接続性を許容することを伴います。サブネットはATMを含んでいます。 もう片方がIPルーティングとIP推進にかかわります。 本質では、IPサブネットの境界を超えて前のテクニックはIPアドレス解決を広げます、後者がIPサブネットとインタコネクトしている間。
Cole, Shur & Villamizar Informational [Page 3] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[3ページ]のRFC1932IP: フレームワークドキュメント1996年4月
Large internetworks, and in particular the Internet, are unlikely to be composed of a single media, or a star topology, with a single media at the center. Within a large network supporting a common media, typically any large NBMA such as ATM, IP routing and IP forwarding must always be accommodated if the internetwork is larger than the NBMA, particularly if there are multiple points of interconnection with the NBMA and/or redundant, diverse interconnections.
ただ一つのメディア、またはスタートポロジーで大きいインターネットワーク、および特にインターネットは構成されそうにはありません、ただ一つのメディアがセンターにある状態で。 一般的なメディアをサポートする大きいネットワークの中では、インターネットワークがNBMAより大きいなら、いつも通常ATMや、IPルーティングやIP推進などの大きいどんなNBMAも収容しなければなりません、特にNBMA、そして/または、余分で、さまざまのインタコネクトがある複数のポイントのインタコネクトがあれば。
Routing information exchange in a very large internetwork can be quite dynamic due to the high probability that some network elements are changing state. The address resolution space consumption and resource consumption due to state change, or maintenance of state information is rarely a problem in classic IP subnets. It can become a problem in large bridged networks or in proposals that attempt to extend address resolution beyond the IP subnet. Scaling properties of address resolution and routing proposals, with respect to state information and state change, must be considered.
非常に大きいインターネットワークにおけるルート設定情報交換はいくつかのネットワーク要素が状態を変えているという高い確率のためにかなりダイナミックである場合があります。 状態によるアドレス解決宇宙消費とリソース消費は変化するか、めったに州の情報のメインテナンスが古典的なIPサブネットで問題ではありません。 それは大きいブリッジしているネットワークかIPサブネットを超えてアドレス解決を広げるのを試みる提案における問題になることができます。 アドレス解決のスケーリング特性と州の情報と州の変化に関するルーティング提案を検討しなければなりません。
3. Parameters Common to IP Over ATM Proposals
3. 気圧提案の上でIPに共通のパラメタ
In some discussion of IP over ATM distinctions have made between local area networks (LANs), and wide area networks (WANs) that do not necessarily hold. The distinction between a LAN, MAN and WAN is a matter of geographic dispersion. Geographic dispersion affects performance due to increased propagation delay.
ATMの上のIPの何らかの議論では、区別はローカル・エリア・ネットワークの間で(LAN)、および広域ネットワークを必ず成立するというわけではない(WAN)にしました。 LANと、MANとWANの区別は地理的な分散の問題です。 地理的な分散は増強された伝播遅延による性能に影響します。
LANs are used for network interconnections at the the major Internet traffic interconnect sites. Such LANs have multiple administrative authorities, currently exclusively support routers providing transit to multihomed internets, currently rely on PVCs and static address resolution, and rely heavily on IP routing. Such a configuration differs from the typical LANs used to interconnect computers in corporate or campus environments, and emphasizes the point that prior characterization of LANs do not necessarily hold. Similarly, WANs such as those under consideration by numerous large IP providers, do not conform to prior characterizations of ATM WANs in that they have a single administrative authority and a small number of nodes aggregating large flows of traffic onto single PVCs and rely on IP routers to avoid forming congestion bottlenecks within ATM.
LANは主要なインターネットトラフィック内部連絡サイトのネットワーク相互接続に使用されます。 そのようなLANには、複数の職務権限があります、現在の排他的にサポートルータがインターネットを「マルチ-家へ帰」らせて、現在PVCsと静的なアドレス解決に依存して、大いにIPルーティングを当てにするためにトランジットを提供して。 そのような構成は、法人かキャンパス環境でコンピュータとインタコネクトするのに使用される典型的なLANと異なっていて、LANの先の特殊化が必ず成立するというわけではないというポイントを強調します。 同様である、WAN、考慮しているそれらとして多数の大きいIPプロバイダーであれほどです、彼らがただ一つの職務権限と少ない数のノードにトラフィックの大きい流れに独身のPVCsに集めさせて、ATMの中で混雑ボトルネックを形成するのを避けるためにIPルータを当てにするので、ATM WANの先の特殊化に従わないでください。
The following characteristics of the IP over ATM internetwork may be independent of geographic dispersion (LAN, MAN, or WAN).
ATMインターネットワークの上のIPの以下の特性は地理的な分散(LAN、MAN、またはWAN)から独立しているかもしれません。
o The size of the IP over ATM internetwork (number of nodes).
o ATMインターネットワーク(ノードの数)の上のIPのサイズ。
o The size of ATM IP subnets (LIS) in the ATM Internetwork.
o ATM InternetworkのATM IPサブネット(LIS)のサイズ。
Cole, Shur & Villamizar Informational [Page 4] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[4ページ]のRFC1932IP: フレームワークドキュメント1996年4月
o Single IP subnet vs multiple IP subnet ATM internetworks.
o ただ一つのIPサブネット対複数のIPサブネットATMインターネットワーク
o Single or multiple administrative authority.
o 単一であるか複数の職務権限。
o Presence of routers providing transit to multihomed internets.
o 「マルチ-家へ帰」っているインターネットにトランジットを提供するルータの存在。
o The presence or absence of dynamic address resolution.
o ダイナミックなアドレス解決の存在か欠如。
o The presence or absence of an IP routing protocol.
o IPルーティング・プロトコルの存在か欠如。
IP over ATM should therefore be characterized by:
したがって、ATMの上のIPは以下によって特徴付けられるべきです。
o Encapsulations below the IP level.
o IPレベルの下におけるカプセル化。
o Degree to which a connection oriented lower level is available
and utilized.
o 接続が下のレベルを適応させた度合いは、利用可能で利用されています。
o Type of address resolution at the IP subnet level (static or
dynamic).
o IPサブネットにおけるアドレス解決のタイプは(静電気か動力)を平らにします。
o Degree to which address resolution is extended beyond the IP
subnet boundary.
o 度合いはIPサブネット境界を超えてどのアドレス解決に広げられるか。
o The type of routing (if any) supported above the IP level.
o IPレベルを超えてサポートされたルーティング(もしあれば)のタイプ。
ATM-specific attributes of particular importance include:
ATM特有の特別に重要な属性は:
o The different types of services provided by the ATM Adaptation
Layers (AAL). These specify the Quality-of-Service, the
connection-mode, etc. The models discussed within this document
assume an underlying connection-oriented service.
o ATM Adaptation Layers(AAL)で異なったサービスのタイプは提供しました。 これらはサービスのQuality、接続モードなどを指定します。 このドキュメントの中に議論したモデルは基本的なコネクション型サービスを仮定します。
o The type of virtual circuits used, i.e., PVCs versus SVCs. The
PVC environment requires the use of either static tables for
ATM-to-IP address mapping or the use of inverse ARP, while the
SVC environment requires ARP functionality to be provided.
o すなわち、使用される、仮想の回路、PVCs対SVCsのタイプ。 PVC環境はATMからIPへのアドレス・マッピングのための静的なテーブルか逆さのARPの使用のどちらかの使用を必要とします、SVC環境が、ARPの機能性が提供されるのを必要としますが。
o The type of support for multicast services. If point-to-point
services only are available, then a server for IP multicast is
required. If point-to-multipoint services are available, then
IP multicast can be supported via meshes of point-to-multipoint
connections (although use of a server may be necessary due to
limits on the number of multipoint VCs able to be supported or to
maintain the leaf initiated join semantics).
o マルチキャストサービスのサポートのタイプ。 二点間輸送だけが利用可能であるなら、IPマルチキャストのためのサーバが必要です。 ポイントツーマルチポイントサービスが利用可能であるなら、ポイントツーマルチポイント接続のメッシュを通してIPマルチキャストをサポートすることができます(サーバの使用が支えられるか、または葉を維持できるVCsが着手した多点の数における限界のために必要であるかもしれませんが、意味論を接合してください)。
o The presence of logical link identifiers (VPI/VCIs) and the
various information element (IE) encodings within the ATM SVC
signaling specification, i.e., the ATM Forum UNI version 3.1.
o 論理的なリンク識別子(VPI/VCIs)の存在とATM SVCシグナリング仕様(すなわち、ATM Forum UNIバージョン3.1)の中の様々な情報要素(IE)encodings。
Cole, Shur & Villamizar Informational [Page 5] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[5ページ]のRFC1932IP: フレームワークドキュメント1996年4月
This allows a VC originator to specify a range of "layer"
entities as the destination "AAL User". The AAL specifications
do not prohibit any particular "layer X" from attaching
directly to a local AAL service. Taken together these points
imply a range of methods for encapsulation of upper layer
protocols over ATM. For example, while LLC/SNAP encapsulation is
one approach (the default), it is also possible to bind virtual
circuits to higher level entities in the TCP/IP protocol stack.
Some examples of the latter are single VC per protocol binding,
TULIP, and TUNIC, discussed further in Section 4.
これで、VC創始者は目的地「AALユーザ」としてさまざまな「層」実体を指定できます。 AAL仕様は付くのから直接地方のAALサービスまでどんな特定の「層X」も禁止しません。 一緒に取って、これらのポイントは上側の層のプロトコルのカプセル化のためにATMの上でさまざまなメソッドを含意します。 例えば、LLC/SNAPカプセル化は1つのアプローチ(デフォルト)ですが、また、TCP/IPプロトコル・スタックの、より高い平らな実体に仮想の回路を縛るのも可能です。 後者に関するいくつかの例が、セクション4で、より詳しく議論したプロトコル結合あたりの独身のVCと、TULIPと、TUNICです。
o The number and type of ATM administrative domains/networks, and
type of addressing used within an administrative domain/network.
In particular, in the single domain/network case, all attached
systems may be safely assumed to be using a single common
addressing format, while in the multiple domain case, attached
stations may not all be using the same common format,
with corresponding implications on address resolution. (See
Appendix A for a discussion of some of the issues that arise
when multiple ATM address formats are used in the same logical
IP subnet (LIS).) Also security/authentication is much more of a
concern in the multiple domain case.
o 管理ドメイン/ネットワークの中で使用されたATMの管理ドメイン/ネットワーク、およびタイプのアドレシングの数とタイプ。 単一領域/ネットワーク場合では、特に、安全にすべての付属システムがただ一つの一般的なアドレス指定形式を使用していると思われるかもしれません、複数のドメイン場合に、付属ステーションがすべて、同じ一般的な形式を使用していないかもしれない間、アドレス解決での対応する含意で。 (複数のATMアドレス形式が同じ論理的なIPサブネット(LIS)に使用されるとき起こるいくつかの問題の議論に関してAppendix Aを見てください。) また、セキュリティ/認証は複数のドメイン場合における関心の多くの以上です。
IP over ATM proposals do not universally accept that IP routing over an ATM network is required. Certain proposals rely on the following assumptions:
提案が一般に受け入れないATMの上のATMネットワークの上のIPルーティングがそうであるIPが必要です。 ある提案は以下の仮定に依存します:
o The widespread deployment of ATM within premises-based networks,
private wide-area networks and public networks, and
o そして構内を拠点とするネットワークの中のATMの広範囲の展開、個人的な広域ネットワーク、および公衆通信回線。
o The definition of interfaces, signaling and routing protocols
among private ATM networks.
o 私設のATMネットワークの中のインタフェース、シグナリング、およびルーティング・プロトコルの定義。
The above assumptions amount to ubiquitous deployment of a seamless ATM fabric which serves as the hub of a star topology around which all other media is attached. There has been a great deal of discussion over when, if ever, this will be a realistic assumption for very large internetworks, such as the Internet. Advocates of such approaches point out that even if these are not relevant to very large internetworks such as the Internet, there may be a place for such models in smaller internetworks, such as corporate networks.
スタートポロジーのハブとしてどの他のメディアの周りで勤めるシームレスのATM骨組みの遍在している展開への上の仮定量は付属しています。 いつに関して大きな議論があったか、これがかつて非常に大きいインターネットワークのために現実的な想定になるなら、インターネットなどのように。 そのようなアプローチの支持者は、これらがインターネットなどの非常に大きいインターネットワークに関連していなくても、より小さいインターネットワークにはそのようなモデルのための場所があるかもしれないと指摘します、企業ネットワークなどのように。
The NHRP protocol (Section 8.2), not necessarily specific to ATM, would be particularly appropriate for the case of ubiquitous ATM deployment. NHRP supports the establishment of direct connections across IP subnets in the ATM domain. The use of NHRP does not require ubiquitous ATM deployment, but currently imposes topology constraints to avoid routing loops (see Section 7). Section 8.2
遍在しているATM展開に関するケースには、必ずATMに特定であるというわけではないNHRPプロトコル(セクション8.2)は特に適切でしょう。 NHRPはATMドメインのIPサブネットの向こう側にダイレクト接続の設立をサポートします。 NHRPの使用は、遍在しているATM展開を必要としませんが、現在、輪を発送するのを避けるというトポロジー規制を課します(セクション7を見てください)。 セクション8.2
Cole, Shur & Villamizar Informational [Page 6] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[6ページ]のRFC1932IP: フレームワークドキュメント1996年4月
describes NHRP in greater detail.
詳細によりすばらしいNHRPについて説明します。
The Peer Model assumes that internetwork layer addresses can be mapped onto ATM addresses and vice versa, and that reachability information between ATM routing and internetwork layer routing can be exchanged. This approach has limited applicability unless ubiquitous deployment of ATM holds. The peer model is described in Section 8.4.
Peer Modelは逆もまた同様にインターネットワーク層のアドレスをATMアドレスに写像できて、ATMルーティングとインターネットワーク層のルーティングの間の可到達性情報を交換できると仮定します。 ATMの遍在している展開が成立しない場合、このアプローチは適用性を制限しました。 同輩モデルはセクション8.4で説明されます。
The Integrated Model proposes a routing solution supporting an exchange of routing information between ATM routing and higher level routing. This provides timely external routing information within the ATM routing and provides transit of external routing information through the ATM routing between external routing domains. Such proposals may better support a possibly lengthy transition during which assumptions of ubiquitous ATM access do not hold. The Integrated Model is described in Section 8.5.
Integrated ModelはATMルーティングと、より高いレベルの間のルーティング情報の交換にルーティングをサポートするルーティング解決を提案します。 これは、ATMルーティングの中でタイムリーな外部のルーティング情報を提供して、外部の経路ドメインの間でATMを通した外部のルーティング情報のトランジットにルーティングを提供します。 そのような提案は遍在しているATMアクセスの仮定が成立しないことによると長い変遷をサポートするほうがよいです。 Integrated Modelはセクション8.5で説明されます。
The Multiprotocol over ATM (MPOA) Sub-Working Group was formed by the ATM Forum to provide multiprotocol support over ATM. The MPOA effort is at an early stage at the time of this writing. An MPOA baseline document has been drafted, which provides terminology for further discussion of the architecture. This document is available from the FTP server ftp.atmforum.com in pub/contributions as the file atm95- 0824.ps or atm95-0824.txt.
ATM(MPOA)サブ作業部会の上のMultiprotocolは、「マルチ-プロトコル」サポートをATMの上に供給するためにATM Forumによって形成されました。 この書くこと時点で、初期のときに、MPOA取り組みがあります。 MPOA基線ドキュメント(アーキテクチャのさらなる議論に用語を提供する)は作成されました。 このドキュメントはファイルatm95の0824.psかatm95-0824.txtとしてパブ/貢献におけるFTPサーバftp.atmforum.comから利用可能です。
4. Encapsulations and Lower Layer Identification
4. カプセル化と下層識別
Data encapsulation, and the identification of VC endpoints, constitute two important issues that are somewhat orthogonal to the issues of network topology and routing. The relationship between these two issues is also a potential sources of confusion. In conventional LAN technologies the 'encapsulation' wrapped around a packet of data typically defines the (de)multiplexing path within source and destination nodes (e.g. the Ethertype field of an Ethernet packet). Choice of the protocol endpoint within the packet's destination node is essentially carried 'in-band'.
データカプセル化、およびVC終点の識別はネットワーク形態とルーティングの問題といくらか直交した2つの切迫した課題を構成します。 また、これらの2冊の間の関係は混乱の可能な源です。 従来のLAN技術では、データのパケットに巻きつけられた'カプセル化'はソースと目的地ノード(例えば、イーサネットパケットのEthertype分野)の中で(de)マルチプレクシング経路を通常定義します。 パケットの目的地ノードの中のプロトコル終点の選択は'バンド'で本質的には運ばれます。
As the multiplexing is pushed towards ATM and away from LLC/SNAP mechanism, a greater burden will be placed upon the call setup and teardown capacity of the ATM network. This may result in some questions being raised regarding the scalability of these lower level multiplexing options.
マルチプレクシングがATMに向かって押されてLLC/SNAPメカニズムから離れているとき、より大きい負担はATMネットワークの呼び出しセットアップと分解容量にかけられるでしょう。 これはこれらの下のレベル多重伝送オプションのスケーラビリティに関して引き起こされるいくつかの疑問をもたらすかもしれません。
With the ATM Forum UNI version 3.1 service the choice of endpoint within a destination node is made 'out of band' - during the Call Setup phase. This is quite independent of any in-band encapsulation mechanisms that may be in use. The B-LLI Information Element allows Layer 2 or Layer 3 entities to be specified as a VC's endpoint. When
ATM Forum UNIバージョン3.1サービスで、Call Setup段階の間、'バンド'で目的地ノードの中の終点の選択をします。 これはバンドにおけるどんな使用中であるかもしれないカプセル化メカニズムからもかなり独立しています。 B-LLI情報Elementは、Layer2かLayer3実体がVCの終点として指定されるのを許容します。 いつ
Cole, Shur & Villamizar Informational [Page 7] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[7ページ]のRFC1932IP: フレームワークドキュメント1996年4月
faced with an incoming SETUP message the Called Party will search locally for an AAL User that claims to provide the service of the layer specified in the B-LLI. If one is found then the VC will be accepted (assuming other conditions such as QoS requirements are also met).
Calledパーティが局所的にB-LLIで指定された層のサービスを提供すると主張するAAL Userを捜す入って来るSETUPメッセージで、顔です。 1つを見つけると、VCを受け入れるでしょう(また、QoS要件などの他の条件が満たされると仮定して)。
An obvious approach for IP environments is to simply specify the Internet Protocol layer as the VCs endpoint, and place IP packets into AAL--SDUs for transmission. This is termed 'VC multiplexing' or 'Null Encapsulation', because it involves terminating a VC (through an AAL instance) directly on a layer 3 endpoint. However, this approach has limitations in environments that need to support multiple layer 3 protocols between the same two ATM level endpoints. Each pair of layer 3 protocol entities that wish to exchange packets require their own VC.
IP環境のための明白なアプローチは、単にVCs終点としてインターネットプロトコル層を指定して、場所IPパケットをAALに指定することです--トランスミッションのためのSDUs。 これは'''ヌルEncapsulationを多重送信するVC'と呼ばれます、直接層の3終点でVCを終えることを(AALインスタンスを通して)伴うので。 しかしながら、このアプローチは同じ2つのATMの平らな終点の間に複数の層が3つのプロトコルであるとサポートする必要がある環境における制限を持っています。 パケットを交換したがっている層3のプロトコル実体の各組がそれら自身のVCを必要とします。
Cole, Shur & Villamizar Informational [Page 8] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[8ページ]のRFC1932IP: フレームワークドキュメント1996年4月
RFC-1483 [6] notes that VC multiplexing is possible, but focuses on
describing an alternative termed 'LLC/SNAP Encapsulation'. This
allows any set of protocols that may be uniquely identified by an
LLC/SNAP header to be multiplexed onto a single VC. Figure 1 shows
how this works for IP packets - the first 3 bytes indicate that the
payload is a Routed Non-ISO PDU, and the Organizationally Unique
Identifier (OUI) of 0x00-00-00 indicates that the Protocol Identifier
(PID) is derived from the EtherType associated with IP packets
(0x800). ARP packets are multiplexed onto a VC by using a PID of
0x806 instead of 0x800.
.---------------.
: :
: IP Packet :
: :
---------------
: :
: :
8 byte header V V
.-------------.-------------.------------.---------------.
: : : : :
: : : : Encapsulated :
: 0xAA-AA-03 : 0x00-00-00 : 0x08-00 : Payload :
: : : : :
-------------^-------------^------------^---------------
: : : :
: (LLC) (OUI) (PID) : : :
V V V V
.----------------------------------------------------------.
: :
: AAL SDU :
: :
----------------------------------------------------------
Figure 1: IP packet encapsulated in an AAL5 SDU
RFC-1483[6]は、VCマルチプレクシングが可能であることに注意しますが、'LLC/SNAP Encapsulation'と呼ばれた代替手段を説明するのは焦点を合わせます。 これは、LLC/SNAPヘッダーによって唯一特定されるかもしれないどんなセットのプロトコルも独身のVCに多重送信されるのを許容します。 図1はこれがIPパケットのためにどう働いているかを示しています--最初の3バイトは、ペイロードがRouted Non-ISO PDUであることを示します、そして、0×00 00-00のOrganizationally Unique Identifier(OUI)はプロトコルIdentifier(PID)がIPパケット(0×800)に関連しているEtherTypeから得られるのを示します。 0×800の代わりに0×806のPIDを使用することによって、ARPパケットをVCに多重送信します。 .---------------. : : : IPパケット: : : --------------- : : : : 8バイトヘッダーV V。-------------.-------------.------------.---------------. : : : : : : : : : カプセル化される: : 0xAA-AA-03: 0×00 00-00: 0×08 00: 有効搭載量: : : : : : -------------^-------------^------------^--------------- : : : : : (LLC) (OUI) (PID) : : : V V V V。----------------------------------------------------------. : : : AAL SDU: : : ---------------------------------------------------------- 図1: AAL5 SDUでカプセルに入れられたIPパケット
Cole, Shur & Villamizar Informational [Page 9] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[9ページ]のRFC1932IP: フレームワークドキュメント1996年4月
.----------. .----------. .---------. .----------.
: : : : : : : :
: IP : : ARP : :AppleTalk: : etc... :
: : : : : : : :
---------- ---------- --------- ----------
^ : ^ : ^ : ^ :
: : : : : : : :
: V : V : V : V
.-----------------------------------------------------------.
: :
: 0x800 0x806 0x809 other :
: :
: Instance of layer using LLC/SNAP header to :
: perform multiplexing/demultiplexing :
: :
-----------------------------------------------------------
^ :
: :
: V
.------------------.
: :
: Instance of AAL5 :
: terminating :
: one VCC :
: :
------------------
.----------. .----------. .---------. .----------. : : : : : : : : : IP: : アルプ: :AppleTalk: : など。 : : : : : : : : : ---------- ---------- --------- ---------- ^ : ^ : ^ : ^ : : : : : : : : : : V: V: V: V。-----------------------------------------------------------. : : : 0×800 0×806 0×809 他: : : : 以下のことにLLC/SNAPヘッダーを使用する層のインスタンス : マルチプレクシング/逆多重化を実行してください: : : ----------------------------------------------------------- ^ : : : : V。------------------. : : : AAL5のインスタンス: : 終わります: : 1VCC: : : ------------------
Figure 2: LLC/SNAP encapsulation allows more than just
IP or ARP per VC.
図2: LLC/SNAPカプセル化はまさしく1VCあたりのIPかARP以上を許容します。
Whatever layer terminates a VC carrying LLC/SNAP encapsulated traffic must know how to parse the AAL--SDUs in order to retrieve the packets. The recently approved signalling standards for IP over ATM are more explicit, noting that the default SETUP message used to establish IP over ATM VCs must carry a B-LLI specifying an ISO 8802/2 Layer 2 (LLC) entity as each VCs endpoint. More significantly, there is no information carried within the SETUP message about the identity of the layer 3 protocol that originated the request - until the packets begin arriving the terminating LLC entity cannot know which one or more higher layers are packet destinations.
層が何を終えても、トラフィックであるとカプセル化されたLLC/SNAPを運ぶVCはAALを分析する方法を知らなければなりません--、SDUs、パケットを検索してください。 ATMの上のIPの最近承認された合図規格は、より明白です、ATM VCsの上でIPを証明するのに使用されるデフォルトSETUPメッセージがそれぞれのVCs終点としてISO8802/2Layer2(LLC)実体を指定するB-LLIを運ばなければならないことに注意して。 よりかなり、要求を溯源した層3のプロトコルのアイデンティティに関するSETUPメッセージの中で運ばれた情報が全くありません--パケットが到着し始めるまで、終わっているLLC実体は、どちらの1つ以上のより高い層がパケットの目的地であるかを知ることができません。
Taken together, this means that hosts require a protocol entity to register with the host's local UNI 3.1 management layer as being an LLC entity, and this same entity must know how to handle and generate LLC/SNAP encapsulated packets. The LLC entity will also require mechanisms for attaching to higher layer protocols such as IP and ARP. Figure 2 attempts to show this, and also highlights the fact that such an LLC entity might support many more than just IP and ARP.
一緒に取って、これは、ホストがLLC実体であるとしてホストの地方のUNI3.1管理層とともに記名するためにプロトコル実体を必要とすることを意味して、この同じ実体はどのようにパケットであるとカプセル化されたLLC/SNAPを扱って、生成するかを知らなければなりません。 また、LLC実体は、IPやARPなどの、より高い層のプロトコルに付くためにメカニズムを必要とするでしょう。 図2は、これを示すのを試みて、また、そのようなLLC実体がまさしくIPとARPよりずっと多くをサポートするかもしれないという事実を目立たせます。
Cole, Shur & Villamizar Informational [Page 10] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[10ページ]のRFC1932IP: フレームワークドキュメント1996年4月
In fact the combination of RFC 1483 LLC/SNAP encapsulation, LLC entities terminating VCs, and suitable choice of LLC/SNAP values, can go a long way towards providing an integrated approach to building multiprotocol networks over ATM.
事実上、RFC1483LLC/SNAPカプセル化の組み合わせ(VCsを終えるLLC実体、およびLLC/SNAP値の適当な選択)は、ATMの上に「マルチ-プロトコル」ネットワークを造ることへの統合的アプローチを提供することに向かってはるばる行くことができます。
The processes of actually establishing AAL Users, and identifying them to the local UNI 3.1 management layers, are still undefined and are likely to be very dependent on operating system environments.
地方のUNI3.1管理層に実際にAAL Usersを設立して、彼らを特定するプロセスは、まだ未定義であり、オペレーティングシステム環境に非常に依存している傾向があります。
Two encapsulations have been discussed within the IP over ATM working group which differ from those given in RFC-1483 [6]. These have the characteristic of largely or totally eliminating IP header overhead. These models were discussed in the July 1993 IETF meeting in Amsterdam, but have not been fully defined by the working group.
ATMワーキンググループの上でIPの中で2つのカプセル化について議論しました(RFC-1483[6]で与えられたものと異なっています)。 これらには、主にか完全に排泄しているIPヘッダーオーバーヘッドの特性があります。 これらのモデルは、アムステルダムでの1993年7月のIETFミーティングで議論しましたが、ワーキンググループによって完全に定義されるというわけではありませんでした。
TULIP and TUNIC assume single hop reachability between IP entities. Following name resolution, address resolution, and SVC signaling, an implicit binding is established between entities in the two hosts. In this case full IP headers (and in particular source and destination addresses) are not required in each data packet.
TULIPとTUNICはIP実体の間のただ一つのホップの可到達性を仮定します。 名前解決、アドレス解決、およびSVCシグナリングに続いて、暗黙の結合は実体の間で2人のホストに確立されます。 この場合、完全なIPヘッダー(そして、特にソースと送付先アドレス)は各データ・パケットで必要ではありません。
o The first model is "TCP and UDP over Lightweight IP" (TULIP)
in which only the IP protocol field is carried in each packet,
everything else being bound at call set-up time. In this
case the implicit binding is between the IP entities in each
host. Since there is no further routing problem once the binding
is established, since AAL5 can indicate packet size, since
fragmentation cannot occur, and since ATM signaling will handle
exception conditions, the absence of all other IP header fields
and of ICMP should not be an issue. Entry to TULIP mode would
occur as the last stage in SVC signaling, by a simple extension
to the encapsulation negotiation described in RFC-1755 [10].
o 第1代モデルはIPプロトコル野原だけが各パケットで運ばれる「軽量のIPの上のTCPとUDP」(TULIP)です、ものが呼び出しセットアップ時間に他の何もかも制限されていて。 この場合、各ホストのIP実体の間には、暗黙の結合があります。 結合がいったん確立されるとさらなるルーティング問題が全くなくて、断片化が起こることができないのでAAL5がパケットサイズを示すことができて、ATMシグナリングが例外条件を扱うので、他のすべてのIPヘッダーフィールドとICMPの不在は問題であるべきではありません。 TULIPモードへのエントリーはSVCシグナリングにおける最後のステージとして現れるでしょう、RFC-1755[10]で説明されたカプセル化交渉への単純拡大で。
TULIP changes nothing in the abstract architecture of the IP
model, since each host or router still has an IP address which is
resolved to an ATM address. It simply uses the point-to-point
property of VCs to allow the elimination of some per-packet
overhead. The use of TULIP could in principle be negotiated on a
per-SVC basis or configured on a per-PVC basis.
TULIPはIPモデルの抽象的な構造の何も変えません、各ホストかルータにはATMアドレスに決議されているIPアドレスがまだあるので。 それは、何らかの1パケットあたりのオーバーヘッドの除去を許容するのに単にVCsの二地点間特性を使用します。 原則としてTULIPの使用を1SVCあたり1個のベースに関して交渉したか、または1PVCあたり1個のベースで構成できました。
o The second model is "TCP and UDP over a Nonexistent IP
Connection" (TUNIC). In this case no network-layer information
is carried in each packet, everything being bound at virtual
circuit set-up time. The implicit binding is between two
applications using either TCP or UDP directly over AAL5 on a
dedicated VC. If this can be achieved, the IP protocol field has
no useful dynamic function. However, in order to achieve binding
between two applications, the use of a well-known port number
o 第2代モデルは「実在しないIP接続の上のTCPとUDP」(TUNIC)です。 この場合、すべてが仮想のサーキットセットアップ時間に制限されていて、ネットワーク層情報は全く各パケットで運ばれません。 2つのアプリケーションの間には、暗黙の結合が、専用VCの上のAAL5の直接上でTCPかUDPのどちらかを使用することであります。 これを達成できるなら、IPプロトコル分野には、どんな役に立つ動態関数もありません。 しかしながら、2つのアプリケーションの間の結合を達成するウェルノウン・ポート番号の使用
Cole, Shur & Villamizar Informational [Page 11] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[11ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
in classical IP or in TULIP mode may be necessary during call
set-up. This is a subject for further study and would require
significant extensions to the use of SVC signaling described in
RFC-1755 [10].
古典的なIPかTULIPでは、モードが呼び出しセットアップの間、必要であるかもしれません。 これは、さらなる研究への対象であり、RFC-1755[10]で説明されたSVCシグナリングの使用に重要な拡大を必要とするでしょう。
Encapsulation In setup message Demultiplexing
-------------+--------------------------+------------------------
SNAP/LLC _ nothing _ source and destination
_ _ address, protocol
_ _ family, protocol, ports
_ _
NULL encaps _ protocol family _ source and destination
_ _ address, protocol, ports
_ _
TULIP _ source and destination _ protocol, ports
_ address, protocol family _
_ _
TUNIC - A _ source and destination _ ports
_ address, protocol family _
_ protocol _
_ _
TUNIC - B _ source and destination _ nothing
_ address, protocol family _
_ protocol, ports _
カプセル化InセットアップメッセージDemultiplexing-------------+--------------------------+------------------------ ポートの_ソースと送付先_ _アドレス(プロトコル_ _家族)が議定書の中で述べないものは何、ポート_ _NULL encaps_プロトコル家族_ソース、および送付先_ _アドレスでも議定書の中で述べるSNAP/LLC_、_ _TULIP_ソース、および目的地_は議定書を作って、ポートプロトコル家族_ _ _TUNIC--_ _ __ソースと送付先_ポート_アドレス、プロトコル家族_ _プロトコルTUNIC--_アドレス、B_ソース、および目的地_は_が記述するものは何でもありません、プロトコル家族_ _プロトコル、ポート_
Table 1: Summary of Encapsulation Types
テーブル1: カプセル化タイプの概要
TULIP/TUNIC can be presented as being on one end of a continuum opposite the SNAP/LLC encapsulation, with various forms of null encapsulation somewhere in the middle. The continuum is simply a matter of how much is moved from in-stream demultiplexing to call setup demultiplexing. The various encapsulation types are presented in Table 1.
SNAP/LLCカプセル化の反対側に連続の片端にあるとしてTULIP/TUNICを寄贈できます、様々なフォームのヌルカプセル化が中央のどこかにある状態で。 連続は単にセットアップを逆多重化と呼ぶのでどのくらいが流れにおける逆多重化から動かされるかに関する問題です。 様々なカプセル化タイプはTable1に提示されます。
Encapsulations such as TULIP and TUNIC make assumptions with regard to the desirability to support connection oriented flow. The tradeoffs between connection oriented and connectionless are discussed in Section 5.
TULIPやTUNICなどのカプセル化は、接続指向の流れを支持するために願わしさに関して仮定をします。 セクション5で接続指向でコネクションレスであることの間の見返りについて議論します。
Cole, Shur & Villamizar Informational [Page 12] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[12ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
5. Connection Oriented and Connectionless Tradeoffs
5. 接続指向の、そして、コネクションレスな見返り
The connection oriented and connectionless approaches each offer advantages and disadvantages. In the past, strong advocates of pure connection oriented and pure connectionless architectures have argued intensely. IP over ATM does not need to be purely connectionless or purely connection oriented.
接続指向の、そして、コネクションレスなアプローチはそれぞれ利点と損失を示します。 純粋な接続の過去の、そして、強い支持者では、指向の、そして、純粋なコネクションレスな構造は激しく論争しました。 純粋にコネクションレスであるか、またはATMの上のIPは接続純粋に指向している必要はありません。
APPLICATION Pure Connection Oriented Approach
----------------+-------------------------------------------------
General _ Always set up a VC
_
Short Duration _ Set up a VC. Either hold the packet during VC
UDP (DNS) _ setup or drop it and await a retransmission.
_ Teardown on a timer basis.
_
Short Duration _ Set up a VC. Either hold packet(s) during VC
TCP (SMTP) _ setup or drop them and await retransmission.
_ Teardown on detection of FIN-ACK or on a timer
_ basis.
_
Elastic (TCP) _ Set up a VC same as above. No clear method to
Bulk Transfer _ set QoS parameters has emerged.
_
Real Time _ Set up a VC. QoS parameters are assumed to
(audio, video) _ precede traffic in RSVP or be carried in some
_ form within the traffic itself.
アプリケーションの純粋な接続指向のアプローチ----------------+------------------------------------------------- 一般_AlwaysはVC_Short Duration_SetをVCにセットアップします。 VC UDP(DNS)_セットアップの間、パケットを保持してくださいか、「再-トランスミッション」を止めて、待ってください。 _ タイマベースに関する分解。 _ 短期間_はVCをセットアップします。 VC TCP(SMTP)_セットアップの間、パケットを保持するか、それらを落としてください、そして、または「再-トランスミッション」を待ってください。 _ FIN-ACKの検出かタイマ_ベースに関する分解。 _ VC以下同文への弾性の(TCP)_Set。 Bulk Transfer_セットQoSパラメタへのクリア方法は全く現れていません。 _ リアルタイムの_はVCをセットアップしました。 QoSは(オーディオ、ビデオ)_にRSVPの交通に先行するか、パラメタが思われるまたは交通自体の中で何らかの_フォームで運ばれてください。
Table 2: Connection Oriented vs. Connectionless - a) a pure
connection oriented approach
テーブル2: 接続Oriented対Connectionless--a) 純粋な接続はアプローチを適応させました。
ATM with basic AAL 5 service is connection oriented. The IP layer above ATM is connectionless. On top of IP much of the traffic is supported by TCP, a reliable end-to-end connection oriented protocol. A fundamental question is to what degree is it beneficial to map different flows above IP into separate connections below IP. There is a broad spectrum of opinion on this.
基本的なAAL5サービスがあるATMは適応する接続です。 ATMの上のIP層はコネクションレスです。 IPの上では、交通の大部分は信頼できるTCP、接続が適応させた終わりから端へのプロトコルによって支持されます。 IPの下にどの程度がそれであるかには基本的な質問がIPの上で異なった流れを別々の接続に写像するのに有益な状態であります。 広範囲の意見がこれにあります。
As stated in section 4, at one end of the spectrum, IP would remain highly connectionless and set up single VCs between routers which are adjacent on an IP subnet and for which there was active traffic flow. All traffic between the such routers would be multiplexed on a single ATM VC. At the other end of the spectrum, a separate ATM VC would be created for each identifiable flow. For every unique TCP or UDP address and port pair encountered a new VC would be required. Part of the intensity of early arguments has been over failure to recognize that there is a middle ground.
セクション4で述べられているスペクトルの片端では、IPはIPサブネットで隣接していて、アクティブな交通の流れがあったルータの間で非常にコネクションレスな状態で留まっていて、独身のVCsをセットアップするでしょう。 独身のATM VCでそのようなルータの間のすべての交通を多重送信するでしょう。 範囲内で対照的に一方の側に、別々のATM VCはそれぞれの身元保証可能な流れのために作成されるでしょう。 遭遇するすべてのユニークなTCPかUDPアドレスとポート組において、新しいVCが必要でしょう。 妥協点があると認めないことの上に早めの議論の強度の一部がありました。
Cole, Shur & Villamizar Informational [Page 13] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[13ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
ATM offers QoS and traffic management capabilities that are well suited for certain types of services. It may be advantageous to use separate ATM VC for such services. Other IP services such as DNS, are ill suited for connection oriented delivery, due to their normal very short duration (typically one packet in each direction). Short duration transactions, even many using TCP, may also be poorly suited for a connection oriented model due to setup and state overhead. ATM QoS and traffic management capabilities may be poorly suited for elastic traffic.
ATMはあるタイプのサービスによく合っている能力をQoSと輸送管理に提供します。 そのようなサービスに別々のATM VCを使用するのは有利であるかもしれません。 DNSが接続指向の配送にほとんど合っていないとき、他のIPはそのようなものを修理します、彼らの正常な非常に短い持続時間(通常各方向への1つのパケット)のため。 短期間取引、多くさえ、TCPを使用して、また、セットアップと州のオーバーヘッドのため接続指向のモデルに不十分に合うかもしれません。 ATM QoSと輸送管理能力は弾性の交通に不十分に合うかもしれません。
APPLICATION Middle Ground
----------------+-------------------------------------------------
General _ Use RSVP or other indication which clearly
_ indicate a VC is needed and what QoS parameters
_ are appropriate.
_
Short Duration _ Forward hop by hop. RSVP is unlikely to precede
UDP (DNS) _ this type of traffic.
_
Short Duration _ Forward hop by hop unless RSVP indicates
TCP (SMTP) _ otherwise. RSVP is unlikely to precede this
_ type of traffic.
_
Elastic (TCP) _ By default hop by hop forwarding is used.
Bulk Transfer _ However, RSVP information, local configuration
_ about TCP port number usage, or a locally
_ implemented method for passing QoS information
_ from the application to the IP/ATM driver may
_ allow/suggest the establishment of direct VCs.
_
Real Time _ Forward hop by hop unless RSVP indicates
(audio, video) _ otherwise. RSVP will indicate QoS requirements.
_ It is assumed RSVP will generally be used for
_ this case. A local decision can be made as to
_ whether the QoS is better served by a separate
_ VC.
アプリケーション妥協点----------------+------------------------------------------------- 一般_Use RSVPか他の指示、どれ、明確に、_は、a VCが必要であることを示して、どんなQoSパラメタ_が適切ですか? _ 短いDuration_Forwardはホップで跳びます。 RSVPはこれがタイプする交通のUDP(DNS)_に先行しそうにはありません。 _ RSVPが_別の方法で、TCP(SMTP)を示さない場合、短いDuration_Forwardはホップで跳びます。 RSVPはこの_タイプの交通に先行しそうにはありません。 _ ホップ推進による弾性の(TCP)_Byデフォルトホップは使用されています。 TCPポートナンバー用法、またはaに関してTransfer_However、RSVP情報、地方の構成_を局所的に膨らませてください。_アプリケーションからIP/ATMドライバーまでの_がそうする情報をQoSに通過するための_が設立を許容するか、または示す実行された方法はVCsを指示します。 _ RSVPが_別の方法で(オーディオ、ビデオ)を示さない場合、本当のTime_Forwardはホップで跳びます。 RSVPはQoS要件を示すでしょう。 _ 一般に、RSVPが_本件に使用されると思われます。 QoSが別々の_VCによって役立たれるほうがよいか否かに関係なく、_に関してローカルの決定をすることができます。
Table 3: Connection Oriented vs. Connectionless - b) a middle ground
approach
テーブル3: 接続Oriented対Connectionless--b) 妥協点アプローチ
Cole, Shur & Villamizar Informational [Page 14] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[14ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
APPLICATION Pure Connectionless Approach
----------------+-------------------------------------------------
General _ Always forward hop by hop. Use queueing
_ algorithms implemented at the IP layer to
_ support reservations such as those specified by
_ RSVP.
_
Short Duration _ Forward hop by hop.
UDP (DNS) _
_
Short Duration _ Forward hop by hop.
TCP (SMTP) _
_
Elastic (TCP) _ Forward hop by hop. Assume ability of TCP to
Bulk Transfer _ share bandwidth (within a VBR VC) works as well
_ or better than ATM traffic management.
_
Real Time _ Forward hop by hop. Assume that queueing
(audio, video) _ algorithms at the IP level can be designed to
_ work with sufficiently good performance
_ (e.g., due to support for predictive
_ reservation).
アプリケーションの純粋なコネクションレスなアプローチ----------------+------------------------------------------------- Alwaysが進める一般_はホップで跳びます。 IP層で__RSVPによって指定されたものなどのサポートの予約に実行された待ち行列_アルゴリズムを使用してください。 _ 短いDuration_Forwardはホップで跳びます。 UDP(DNS)_ _Short Duration_Forwardはホップで跳びます。 TCP(SMTP)_ _Elastic(TCP)_Forwardはホップで跳びます。 Bulk Transfer_シェア帯域幅(VBR VCの中の)へのTCPの能力がATM輸送管理より十分_か良いとして働くと仮定してください。 _ 本当のTime_Forwardはホップで跳びます。 IPレベルにおける待ち行列(オーディオ、ビデオ)_アルゴリズムが_十分良い性能_(例えば、予言の_の予約のサポートによる)との仕事に設計される場合があると仮定してください。
Table 4: Connection Oriented vs. Connectionless - c) a pure
connectionless approach
テーブル4: 接続Oriented対Connectionless--c) 純粋なコネクションレスなアプローチ
Work in progress is addressing how QoS requirements might be expressed and how the local decisions might be made as to whether those requirements are best and/or most cost effectively accomplished using ATM or IP capabilities. Table 2, Table 3, and Table 4 describe typical treatment of various types of traffic using a pure connection oriented approach, middle ground approach, and pure connectionless approach.
それらの要件が最も良く、事実上、ほとんどの費用がATMを使用するか、IP能力を実行したかどうかに関して処理中の作業はQoS要件がどう言い表されるかもしれないか、そして、どうローカルの決定をするかもしれないかを記述することです。 テーブル2、Table3、およびTable4は、純粋な接続指向のアプローチ、妥協点アプローチ、および純粋なコネクションレスなアプローチを使用することで様々なタイプの交通の典型的な処理について説明します。
The above qualitative description of connection oriented vs connectionless service serve only as examples to illustrate differing approaches. Work in the area of an integrated service model, QoS and resource reservation are related to but outside the scope of the IP over ATM Work Group. This work falls under the Integrated Services Work Group (int-serv) and Reservation Protocol Work Group (rsvp), and will ultimately determine when direct connections will be established. The IP over ATM Work Group can make more rapid progress if concentrating solely on how direct connections are established.
相違を例証するために例だけとしてコネクションレス型サービスサーブに対して適応する接続の上の質的な記述にアプローチします。 統合サービスモデルの領域での仕事、QoSと資源予約は範囲にもかかわらず、ATM Work Groupの上のIPの範囲の外で関係づけられます。 この仕事は、Integrated Services Work Group(int-serv)と予約プロトコルWork Group(rsvp)の下で低下して、結局、ダイレクト接続がいつ確立されるかを決定するでしょう。 ATM Work Groupの上のIPは唯一接続がどれくらいダイレクトに確立されるかに集中するなら、より急速な進歩をすることができます。
Cole, Shur & Villamizar Informational [Page 15] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[15ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
6. Crossing IP Subnet Boundaries
6. IPサブネット境界に交差しています。
A single IP subnet will not scale well to a large size. Techniques which extend the size of an IP subnet in other media include MAC layer bridging, and proxy ARP bridging.
ただ一つのIPサブネットは大判によく比例しないでしょう。 他のメディアにおける、IPサブネットのサイズを広げるテクニックがMAC層の橋を架けるのと、プロキシARPのおよび橋を架けることを含んでいます。
MAC layer bridging alone does not scale well. Protocols such as ARP rely on the media broadcast to exchange address resolution information. Most bridges improve scaling characteristics by capturing ARP packets and retaining the content, and distributing the information among bridging peers. The ARP information gathered from ARP replies is broadcast only where explicit ARP requests are made. This technique is known as proxy ARP.
MAC層の橋を架けることだけがよく比例しません。 ARPなどのプロトコルは、アドレス解決情報を交換するためにメディア放送に依存します。 ほとんどの橋が、ARPパケットを捕らえて、内容を保有することによって特性をスケーリングして、橋を架ける同輩に情報を分配しながら、向上します。 ARP回答から集められたARP情報は明白なARP要求がされるところだけで放送されます。 このテクニックはプロキシARPとして知られています。
Proxy ARP bridging improves scaling by reducing broadcast traffic, but still suffers scaling problems. If the bridged IP subnet is part of a larger internetwork, a routing protocol is required to indicate what destinations are beyond the IP subnet unless a statically configured default route is used. A default route is only applicable to a very simple topology with respect to the larger internet and creates a single point of failure. Because internets of enormous size create scaling problems for routing protocols, the component networks of such large internets are often partitioned into areas, autonomous systems or routing domains, and routing confederacies.
減少することによって比例しているARPの橋を架けるのが改良するプロキシが、交通を放送しますが、まだスケーリング問題に苦しんでいます。橋を架けられたIPサブネットが、より大きいインターネットワークの一部であるなら、ルーティング・プロトコルが、静的に構成されたデフォルトルートが使用されていない場合どんな目的地がIPサブネットを超えているかを示すのに必要です。 デフォルトルートは、より大きいインターネットに関して単に非常に簡単なトポロジーに適切であり、1ポイントの失敗を作成します。 莫大なサイズのインターネットがルーティング・プロトコルのためのスケーリング問題を生じさせるので、そのような大きいインターネットのコンポーネントネットワークはしばしば領域か自律システムか経路ドメインと、ルーティング連盟に仕切られます。
The scaling limits of the simple IP subnet require a large network to be partitioned into smaller IP subnets. For NBMA media like ATM, there are advantages to creating direct connections across the entire underlying NBMA network. This leads to the need to create direct connections across IP subnet boundaries.
簡単なIPサブネットのスケーリング限界は、大きいネットワークが、より小さいIPサブネットに仕切られるのを必要とします。 ATMのようなNBMAメディアのために、全体の基本的なNBMAネットワークの向こう側にダイレクト接続を創造する利点があります。 これはIPサブネット境界の向こう側にダイレクト接続を創造する必要性に通じます。
Cole, Shur & Villamizar Informational [Page 16] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[16ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
.----------.
---------< Non-ATM :
.-------. / /-< Subnet >-\
:Sub-ES >--/ : ---------- :
------- : :
: :
.--^---. .--^---.
:Router: :Router:
-v-v-- -v-v--
: : : :
.--------. : : .--------. : : .--------.
.-------. : >-/ \-< >-/ \-< : .-------.
:Sub-ES :---: Subnet :-----: Subnet :-----: Subnet :---:Sub-ES :
------- : : : : : : -------
-------- ---v---- --------
:
.--^----.
:Sub-ES :
-------
.----------. ---------<非気圧: .-------. >-\: //-<サブネットサブES>--、/: ---------- : ------- : : : : .--^---. .--^---. :ルータ: :ルータ: -v-v(-v-v): : : : .--------. : : .--------. : : .--------. .-------. : >。/\\-<>/<: .-------. :サブES:---: サブネット:-----: サブネット:-----: サブネット:---:サブES: ------- : : : : : : ------- -------- ---v---- -------- : .--^----. :サブES: -------
Figure 3: A configuration with both ATM-based and non-ATM based
subnets.
図3: 両方がATMベースと非ATMである構成はサブネットを基礎づけました。
For example, figure 3 shows an end-to-end configuration consisting of four components, three of which are ATM technology based, while the fourth is a standard IP subnet based on non-ATM technology. End- systems (either hosts or routers) attached to the ATM-based networks may communicate either using the Classical IP model or directly via ATM (subject to policy constraints). Such nodes may communicate directly at the IP level without necessarily needing an intermediate router, even if end-systems do not share a common IP-level network prefix. Communication with end-systems on the non-ATM-based Classical IP subnet takes place via a router, following the Classical IP model (see Section 8.1 below).
例えば、3が標準のIPサブネットであることを終わりから終わりへの3つのそれが4日である間基づくATM技術である4つのコンポーネントから成る構成に示す図は非ATM技術を基礎づけました。 ATMを拠点とするネットワークに取り付けられたエンドシステム(ホストかルータのどちらか)は、IPモデルか直接ATM(方針規制を条件とした)を通してClassicalを使用することで交信するかもしれません。 必ず中間的ルータを必要とするというわけではなくて、そのようなノードはIPレベルで直接伝達するかもしれません、エンドシステムが一般的なIP-レベルネットワーク接頭語を共有しないでも。 非ATMベースのClassical IPサブネットのエンドシステムとのコミュニケーションはルータで行われます、Classical IPモデルに従って(以下のセクション8.1を見てください)。
Many of the problems and issues associated with creating such direct connections across subnet boundaries were originally being addressed in the IETF's IPLPDN working group and the IP over ATM working group. This area is now being addressed in the Routing over Large Clouds working group. Examples of work performed in the IPLPDN working group include short-cut routing (proposed by P. Tsuchiya) and directed ARP RFC-1433 [5] over SMDS networks. The ROLC working group has produced the distributed ARP server architectures and the NBMA Address Resolution Protocol (NARP) [7]. The Next Hop Resolution Protocol (NHRP) is still work in progress, though the ROLC WG is considering advancing the current document. Questions/issues specifically related to defining a capability to cross IP subnet boundaries include:
サブネット境界の向こう側にそのようなダイレクト接続を創造すると関連している問題と問題の多くが元々、ATMワーキンググループの上にIETFのIPLPDNワーキンググループとIPで記述されていました。 この領域は現在、Large Cloudsワーキンググループの上のルート設定で記述されています。 IPLPDNワーキンググループで行われた仕事に関する例はショートカットルーティングを含んでいます。(P.Tsuchiyaによって提案されます。) そして、SMDSネットワークの上の指示されたARP RFC-1433[5]。 ROLCワーキンググループは分配されたARPサーバー・アーキテクチャとNBMA Address Resolutionプロトコル(NARP)[7]を作成しました。 それでも、Next Hop Resolutionプロトコル(NHRP)は処理中の作業です、ROLC WGは、現在のドキュメントを進めると考えていますが。 明確にIPサブネット境界に交差する能力を定義すると関連する質問/問題は:
Cole, Shur & Villamizar Informational [Page 17] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[17ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
o How can routing be optimized across multiple logical IP subnets
over both a common ATM based and a non-ATM based infrastructure.
For example, in Figure 3, there are two gateways/routers between
the non-ATM subnet and the ATM subnets. The optimal path
from end-systems on any ATM-based subnet to the non ATM-based
subnet is a function of the routing state information of the two
routers.
o 一般的なATMが基礎づけた両方と非ATMのベースのインフラストラクチャの上で複数の論理的なIPサブネットの向こう側にどうしたらルーティングを最適化できますか? 例えば、図3に、非ATMサブネットとATMサブネットの間には、2つのゲートウェイ/ルータがあります。 どんなATMベースのサブネットのエンドシステムから非ATMベースのサブネットまでの最適経路も2つのルータのルーティング州の情報の機能です。
o How to incorporate policy routing constraints.
o 方針ルーティング規制を取り入れる方法。
o What is the proper coupling between routing and address
resolution particularly with respect to off-subnet communication.
o 特にオフサブネットコミュニケーションに関するルーティングとアドレス解決の間の適切なカップリングであること。
o What are the local procedures to be followed by hosts and
routers.
o 何がホストとルータがあとに続くローカルの手順ですか?
o Routing between hosts not sharing a common IP-level (or L3)
network prefix, but able to be directly connected at the NBMA
media level.
o 一般的なIP-レベル(または、L3)ネットワーク接頭語にもかかわらず、NBMAメディアレベルで直接接続できて共有していないホストの間で掘ります。
o Defining the details for an efficient address resolution
architecture including defining the procedures to be followed by
clients and servers (see RFC-1433 [5], RFC-1735 [7] and NHRP).
o クライアントとサーバ(RFC-1433[5]、RFC-1735[7]、およびNHRPを見る)があとに続くように手順を定義するのを含む効率的なアドレス解決構造のための詳細を定義します。
o How to identify the need for and accommodate special purpose SVCs
for control or routing and high bandwidth data transfers.
o コントロールかルーティングと高帯域データ転送のために必要性を特定して、専用SVCsを収容する方法。
For ATM (unlike other NBMA media), an additional complexity in supporting IP routing over these ATM internets lies in the multiplicity of address formats in UNI 3.0 [4]. NSAP modeled address formats only are supported on "private ATM" networks, while either 1) E.164 only, 2) NSAP modeled formats only, or 3) both are supported on "public ATM" networks. Further, while both the E.164 and NSAP modeled address formats are to be considered as network points of attachment, it seems that E.164 only networks are to be considered as subordinate to "private networks", in some sense. This leads to some confusion in defining an ARP mechanism in supporting all combinations of end-to-end scenarios (refer to the discussion in Appendix A on the possible scenarios to be supported by ARP).
ATM(他のNBMAメディアと異なった)に関しては、UNI3.0[4]のアドレス形式の多様性にはこれらのATMインターネットの上でIPルーティングを支持することにおける追加複雑さがあります。 NSAP、モデル化されたアドレス形式だけが1である間、)「個人的なATM」ネットワークでサポートされます。 E.164、2だけ) NSAPが形式だけをモデル化したか、または3の両方が)「公共のATM」ネットワークで支持されます。 さらに、アドレス形式がE.164とNSAPの両方がモデル化されていた間、ネットワークポイントの付属であるとみなされることであり、「私設のネットワーク」においてネットワークだけが部下と考えられることになっているそのE.164に思えます、何らかの意味で。 これは終わりから終わりへのシナリオ(ARPによって支持されるように、可能なシナリオのAppendix Aでの議論について言及する)のすべての組み合わせをサポートする際にARPメカニズムを定義する際に何らかの混乱に通じます。
7. Extensions to IP Routing
7. IPルート設定への拡大
RFC-1620 [3] describes the problems and issues associated with direct connections across IP subnet boundaries in greater detail, as well as possible solution approaches. The ROLC WG has identified persistent routing loop problems that can occur if protocols which lose information critical to path vector routing protocol loop suppression are used to accomplish direct connections across IP subnet
RFC-1620[3]は、よりすばらしい詳細におけるIPサブネット境界の向こう側にダイレクト接続に関連している問題と問題について説明します、可能な解決策アプローチと同様に。 ROLC WGは経路ベクトルルーティング・プロトコル輪の抑圧に重要な情報を失うプロトコルがIPサブネットの向こう側にダイレクト接続を実行するのに使用されるなら起こることができるしつこいルーティング輪の問題を特定しました。
Cole, Shur & Villamizar Informational [Page 18] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[18ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
boundaries.
境界。
The problems may arise when a destination network which is not on the NBMA network is reachable via different routers attached to the NBMA network. This problem occurs with proposals that attempt to carry reachability information, but do not carry full path attributes (for path vector routing) needed for inter-AS path suppression, or full metrics (for distance vector or link state routing even if path vector routing is not used) for intra-AS routing.
NBMAネットワークにない送信先ネットワークがNBMAネットワークに付けられた異なったルータで届いているとき、問題は起こるかもしれません。 相互AS経路抑圧のために提案で可到達性情報を運びますが、属性(経路ベクトルルーティングのための)が必要としたフルパスは運ばないその試みを生じるか、またはこの問題はイントラ-ASルーティングのために、完全な測定基準(経路ベクトルルーティングが使用されていなくても掘られる距離ベクトルかリンク状態への)を生じます。
For example, the NHRP protocol may be used to support the establishment of direct connections across subnetwork boundaries. NHRP assumes that routers do run routing protocols (intra and/or inter domain) and/or static routing. NHRP further assumes that forwarding tables constructed by these protocols result in a steady state loop-free forwarding. Note that these two assumptions do not impose any additional requirements on routers, beyond what is required in the absence of NHRP.
例えば、NHRPプロトコルは、サブネットワーク境界の向こう側にダイレクト接続の設立を支持するのに使用されるかもしれません。 NHRPは、ルータがルーティング・プロトコル(イントラ、そして/または、間のドメイン)、そして/または、スタティックルーティングを走らせると仮定します。 NHRPは、これらのプロトコルによって組み立てられた推進テーブルが定常状態無輪の推進をもたらすとさらに仮定します。 NHRPが不在のとき必要であることを超えてこれらの2つの仮定がどんな追加要件もルータに課さないことに注意してください。
NHRP runs in addition to routing protocols, and provides the information that allows the elimination of multiple IP hops (the multiple IP hops result from the forwarding tables constructed by the routing protocols) when traversing an NBMA network. The IPATM and ROLC WGs have both expended considerable effort in discussing and coming to understand these limitations.
NHRPはルーティング・プロトコルに加えて走って、NBMAネットワークを横断するとき複数のIPホップ(推進テーブルからの結果がルーティング・プロトコルで組み立てた複数のIPホップ)の除去を許容する情報を提供します。 IPATMとROLC WGsは議論とこれらの制限を理解するようになる際にともにかなりの努力を費やしました。
It is well-known that truncating path information in Path Vector protocols (e.g., BGP) or losing metric information in Distance Vector protocols (e.g., RIP) could result in persistent forwarding loops. These loops could occur without ATM and without NHRP.
Path Vectorプロトコルの経路情報(例えば、BGP)かDistance Vectorプロトコルの損をしているメートル法の情報(例えば、RIP)に先端を切らせるとしつこい推進輪がもたらされるかもしれないのは、周知のことです。 これらの輪はATMなしでNHRPなしで現れることができました。
The combination of NHRP and static routing alone cannot be used in some topologies where some of the destinations are served by multiple routers on the NBMA. The combination of NHRP and an intra-AS routing protocol that does not carry inter-AS routing path attributes alone cannot be used in some topologies in which the NBMA will provide inter-AS transit connectivity to destinations from other AS served by multiple routers on the NBMA.
目的地のいくつかがNBMAの上の複数のルータによって役立たれているいくらかのtopologiesでNHRPとスタティックルーティングだけの組み合わせを使用できません。 NBMAが相互ASトランジットの接続性をNBMAの上の複数のルータによって役立たれる他のASから目的地に提供するいくらかのtopologiesで単独で相互ASルーティング経路属性を運ばないNHRPの組み合わせとイントラ-ASルーティング・プロトコルは使用できません。
Figure 4 provides an example of the routing loops that may be formed in these circumstances. The example illustrates how the use of NHRP in the environment where forwarding loops could exist even without NHRP (due to either truncated path information or loss of metric information) would still produce forwarding loops.
図4はこういう事情ですから形成されるかもしれないルーティング輪に関する例を提供します。 例は、輪を進めながら、推進輪がNHRP(端が欠けている経路情報かメートル法の情報の損失のどちらかによる)がなくても存在できた環境におけるNHRPの使用にどうまだ生産されているだろうかを例証します。
There are many potential scenarios for routing loops. An example is given in Figure 4. It is possible to produce a simpler example where a loop can form. The example in Figure 4 illustrates a loop which
ルーティング輪のための多くの潜在的シナリオがあります。 例は図4で出されます。 輪を形成できるより簡単な例を作り出すのは可能です。 図4の例が輪を例証する、どれ
Cole, Shur & Villamizar Informational [Page 19] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[19ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
will persist even if the protocol on the NBMA supports redirects or can invalidate any route which changes in any way, but does not support the communication of full metrics or path attributes.
NBMAサポートでのプロトコルが何か何らかの方法で変化しますが、完全な測定基準か経路属性に関するコミュニケーションを支持しないルートを向け直す、または無効にすることができても、固執するでしょう。
.----. .----.
: H1 >----< S1 : Notes:
---- vvvv H#n == host #n
/ : \ R#n == router #n
/ : \ S#n == subnet #n
/------/ : \
: : \ S2 to R3 breaks
.--^---. .----. .-^--.
: : : R4 : : R6 :
: NBMA : --v- --v- See the text for
: : : : details of the
-v--v- = = looping conditions
: \ = SLOW = and mechanisms
: .-^--. = LINK =
: : R2 : = =
: --v- : :
: : .--^-. .--^-.
.-^--. : : R5 : : R7 :
: R8 : : --v- --v-
--v- \ : :
: \ / :
\ .-^^-. .--^-.
\ : S2 : : S4 :
\ --v- --v-
\ \ /
\ \ /
\ .^--^.
\ : R3 : path before the break is
\ -v-- H1->S1->R1->NBMA->R2->S2->R3->H2
\ /
.----. .-^^-. path after the break is
: H2 >---< S3 : H1->S1->R1->NBMA->R2->S2->R5->R4->S1
---- ---- \------<--the-loop--<-------/
.----. .----. : H1>。----<S1: 注意: ---- ホスト#vvvv H#n=n/: ルータ#n\R#n=/: サブネット#n\S#n=/------/ : \ : : R3への\S2が壊れる、--、^---. .----. .-^--. : : : R4: : R6: : NBMA: --v- --v以下のためにテキストを見てください。 : : : -vの細部--v=はループ状態と等しいです: \はSLOW=とメカニズムと等しいです: .-^--. = =をリンクしてください: : R2: = = : --v: : : : .--^-. .--^-. .-^--. : : R5: : R7: : R8: : --v- --v- --v\: : : \ / : \ .-^^-. .--^-. \ : S2: : S4: \--v- --v\\/\\/\^--^\: R3: 休みの前の経路は\-vです--、H1、-、>S1->、R1、-、>NBMA->、R2、-、>S2->、R3、-、>H2\/。----. .、-^^-. 休みの後の経路は以下の通りです。 H2>。---<S3: H1、-、>S1->、R1、-、>NBMA->、R2、-、>S2->、R5、-、>R4->、S1---- ---- \------<---輪にしてください、--、<。-------/
Figure 4: A Routing Loop Due to Lost PV Routing Attributes.
図4: 無くなっているPVルート設定属性によるルート設定輪。
In the example in Figure 4, Host 1 is sending traffic toward Host 2. In practice, host routes would not be used, so the destination for the purpose of routing would be Subnet 3. The traffic travels by way of Router 1 which establishes a "cut-through" SVC to the NBMA next- hop, shown here as Router 2. Router 2 forwards traffic destined for Subnet 3 through Subnet 2 to Router 3. Traffic from Host 1 would then reach Host 2.
図4の例では、Host1はHost2に向かって交通を送ります。 実際には、ホストルートは使用されないでしょう、したがって、ルーティングの目的のための目的地がSubnet3でしょう。 交通はRouter2としてここに示された次のNBMAへの「通じて、切れ」SVCホップを設立するRouter1を通して伝わります。 ルータ2はSubnet3のためにSubnet2を通してRouter3に運命づけられた交通を進めます。 そして、Host1からの交通はHost2に達するでしょう。
Cole, Shur & Villamizar Informational [Page 20] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[20ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
Router 1's cut-through routing implementation caches an association between Host 2's IP address (or more likely all of Subnet 3) and Router 2's NBMA address. While the cut-through SVC is still up, Link 1 fails. Router 5 loses it's preferred route through Router 3 and must direct traffic in the other direction. Router 2 loses a route through Router 3, but picks up an alternate route through Router 5. Router 1 is still directing traffic toward Router 2 and advertising a means of reaching Subnet 3 to Subnet 1. Router 5 and Router 2 will see a route, creating a loop.
ルータ1の深く切っているルーティング実現はHost2のIPアドレス(または、おそらくSubnet3のすべて)とRouter2のNBMAアドレスとの協会をキャッシュします。 切られたSVCはまだ上がっていますが、Link1は失敗します。 ルータ5は、Router3を通してそれの都合のよいルートをなくして、もう片方の方向に交通整理しなければなりません。 ルータ2は、Router3を通してルートをなくしますが、Router5を通して代替経路を拾います。 ルータ1は、まだRouter2に向かって交通整理していて、Subnet3に達する手段のSubnet1に広告を出しています。 輪を作成して、ルータ5とRouter2はルートを見るでしょう。
This loop would not form if path information normally carried by interdomain routing protocols such as BGP and IDRP were retained across the NBMA. Router 2 would reject the initial route from Router 5 due to the path information. When Router 2 declares the route to Subnet 3 unreachable, Router 1 withdraws the route from routing at Subnet 1, leaving the route through Router 4, which would then reach Router 5, and would reach Router 2 through both Router 1 and Router 5. Similarly, a link state protocol would not form such a loop.
通常、BGPやIDRPなどのinterdomainルーティング・プロトコルによって運ばれた経路情報がNBMAの向こう側に保有されるなら、この輪は形成されないでしょうに。 ルータ2は経路情報のためRouter5から初期のルートを拒絶するでしょう。 Router2が、Subnet3へのルートが手が届かないと宣言するとき、Router1はSubnet1でのルーティングからルートを引っ込めます、Router4を通してルートを出て。Routerは次に、Router5に達して、Router1とRouter5の両方を通してRouter2に達するでしょう。 同様に、リンク州のプロトコルはそのような輪を形成しないでしょう。
Two proposals for breaking this form of routing loop have been discussed. Redirect in this example would have no effect, since Router 2 still has a route, just has different path attributes. A second proposal is that is that when a route changes in any way, the advertising NBMA cut-through router invalidates the advertisement for some time period. This is similar to the notion of Poison Reverse in distance vector routing protocols. In this example, Router 2 would eventually readvertise a route since a route through Router 6 exists. When Router 1 discovers this route, it will advertise it to Subnet 1 and form the loop. Without path information, Router 1 cannot distinguish between a loop and restoration of normal service through the link L1.
この形式のルーティング輪を壊すための2つの提案について議論しました。 Router2にはルートがまだあるので、いいえがこの例で作用する再直接のコネはただ異なった経路属性を持っています。 すなわち、2番目の提案はルートが何らかの方法で変化するとき、広告NBMA通じて切れルータがしばらく広告を無効にするということです。期間。 これは距離ベクトルルーティング・プロトコルにおいてPoison Reverseの概念と同様です。 この例では、Router6を通したルートが存在しているので、Router2は結局、ルートの「再-広告を出」すでしょう。 Router1がこのルートを発見するとき、それは、Subnet1にそれの広告を出して、輪を形成するでしょう。 経路情報がなければ、Router1はリンクL1を通した通常のサービスの輪と回復を見分けることができません。
The loop in Figure 4 can be prevented by configuring Router 4 or Router 5 to refuse to use the reverse path. This would break backup connectivity through Router 8 if L1 and L3 failed. The loop can also be broken by configuring Router 2 to refuse to use the path through Router 5 unless it could not reach the NBMA. Special configuration of Router 2 would work as long as Router 2 was not distanced from Router 3 and Router 5 by additional subnets such that it could not determine which path was in use. If Subnet 1 is in a different AS or RD than Subnet 2 or Subnet 4, then the decision at Router 2 could be based on path information.
逆の経路を使用するのを拒否するためにRouter4かRouter5を構成することによって、図4の輪を防ぐことができます。 L1とL3が失敗するなら、これはRouter8を通してバックアップの接続性を知らせるでしょうに。 また、NBMAに達するかもしれないならRouter5を通して経路を使用するのを拒否するためにRouter2を構成することによって、輪を壊すことができます。 Router2がどの経路が使用中であったかを決定できないように追加サブネットによってRouter3とRouter5から遠ざけられなかった限り、Router2の特別な構成は働いているでしょう。 Subnet1がSubnet2かSubnet4より異なったASかRDにあるなら、Router2での決定は経路情報に基づくかもしれません。
Cole, Shur & Villamizar Informational [Page 21] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[21ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
.--------. .--------.
: Router : : Router :
--v-v--- ---v-v--
: : : :
.--------. .--------. : : .--------. : : .--------. .--------.
: Sub-ES :---: Subnet :-/ \-: Subnet :-/ \-: Subnet :---: Sub-ES :
-------- -------- -------- -------- --------
.--------. .--------. : ルータ: : ルータ: --v-v--- ---v-v--、: : : : .--------. .--------. : : .--------. : : .--------. .--------. : サブES:---: サブネット:-/\: サブネット:-/\: サブネット:---: サブES: -------- -------- -------- -------- --------
Figure 5: The Classical IP model as a concatenation of three separate
ATM IP subnets.
図5: 3の連結としてのClassical IPモデルはATM IPサブネットを切り離します。
In order for loops to be prevented by special configuration at the NBMA border router, that router would need to know all paths that could lead back to the NBMA. The same argument that special configuration could overcome loss of path information was posed in favor of retaining the use of the EGP protocol defined in the now historic RFC-904 [11]. This turned out to be unmanageable, with routing problems occurring when topology was changed elsewhere.
輪がNBMA境界ルータにおける特別な構成によって防がれるために、そのルータは、行くとNBMAへ戻るかもしれないすべての経路を知る必要があるでしょう。 現在歴史的なRFC-904[11]で定義されたEGPプロトコルの使用を保有することを支持して特別な構成が経路情報の損失を克服するかもしれないという同じ主張は引き起こされました。 これはほかの場所でトポロジーを変えたとき、起こることにおけるルーティング問題で「非-処理しやす」であると判明しました。
8. IP Over ATM Proposals
8. 気圧提案の上のIP
8.1 The Classical IP Model
8.1 古典的なIPモデル
The Classical IP Model was suggested at the Spring 1993 IETF meeting [8] and retains the classical IP subnet architecture. This model simply consists of cascading instances of IP subnets with IP-level (or L3) routers at IP subnet borders. An example realization of this model consists of a concatenation of three IP subnets. This is shown in Figure 5. Forwarding IP packets over this Classical IP model is straight forward using already well established routing techniques and protocols.
Classical IP ModelはSpring1993IETFミーティング[8]で勧められて、古典的なIPサブネット構造を保有します。 IP-レベル(または、L3)ルータがIPサブネット境界にある状態で、このモデルはIPサブネットの滝の例から単に成ります。 このモデルの例の実現は3つのIPサブネットの連結から成ります。 これは図5に示されます。 IPパケットを進めて、テクニックとプロトコルを発送するのが、まっすぐ前方にこのClassical IPモデルの上に、既に確固とした状態で使用することであります。
SVC-based ATM IP subnets are simplified in that they:
SVCベースのATM IPサブネットがそれで簡素化される、それら:
o limit the number of hosts which must be directly connected at any
given time to those that may actually exchange traffic.
o 直接その時々で実際に交通を交換するかもしれないものに接続しなければならないホストの数を制限してください。
o The ATM network is capable of setting up connections between
any pair of hosts. Consistent with the standard IP routing
algorithm [2] connectivity to the "outside" world is achieved
only through a router, which may provide firewall functionality
if so desired.
o ATMネットワークはどんな組のホストの間の接続をセットアップできます。 一貫、標準のIPと共に、「外」の世界へのルーティング・アルゴリズム[2]接続性はルータだけを通して達成されます。そう望まれているなら、ルータはファイアウォールの機能性を提供するかもしれません。
o The IP subnet supports an efficient mechanism for address
resolution.
o IPサブネットはアドレス解決のために効率的なメカニズムをサポートします。
Issues addressed by the IP Over ATM Working Group, and some of the resolutions, for this model are:
このモデルのためのIP Over ATM作業部会によって記述された問題、および解決のいくつかは以下の通りです。
Cole, Shur & Villamizar Informational [Page 22] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[22ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
o Methods of encapsulation and multiplexing. This issue is
addressed in RFC-1483 [6], in which two methods of encapsulation
are defined, an LLC/SNAP and a per-VC multiplexing option.
o カプセル化とマルチプレクシングの方法。 この問題はRFC-1483[6]に記述されます、カプセル化のどの2つの方法が定義されるか、そして、LLC/SNAPと1VCあたり1つの多重伝送オプションで。
o The definition of an address resolution server (defined in
RFC-1577).
o アドレス解決サーバ(RFC-1577では、定義される)の定義。
o Defining the default MTU size. This issue is addressed in
RFC-1626 [1] which proposes the use of the MTU discovery
protocol (RFC-1191 [9]).
o デフォルトMTUサイズを定義します。 この問題はMTU発見プロトコルの使用を提案するRFC-1626[1]に記述されます。(RFC-1191[9])。
o Support for IP multicasting. In the summer of 1994, work began
on the issue of supporting IP multicasting over the SVC LATM
model. The proposal for IP multicasting is currently defined by
a set of IP over ATM WG Works in Progress, referred to collectively
as the IPMC documents. In order to support IP multicasting the
ATM subnet must either support point-to- multipoint SVCs, or
multicast servers, or both.
o IPには、マルチキャスティングを支持してください。 1994年夏に、仕事はSVC LATMモデルの上でIPを支持する問題でマルチキャスティングを始めました。 IPマルチキャスティングのための提案は現在、IPMCドキュメントとまとめて呼ばれたProgressのATM WG Worksの上でIPの1セットによって定義されます。 IPマルチキャスティングを支持するために、ATMサブネットはサポートポイントから多点へのSVCsか、マルチキャストサーバか両方のどちらかがそうしなければなりません。
o Defining interim SVC parameters, such as QoS parameters and
time-out values.
o QoSパラメタやタイムアウト値などの当座のSVCパラメタを定義します。
o Signaling and negotiations of parameters such as MTU size
and method of encapsulation. RFC-1755 [10] describes an
implementation agreement for routers signaling the ATM network
to establish SVCs initially based upon the ATM Forum's UNI
version 3.0 specification [4], and eventually to be based
upon the ATM Forum's UNI version 3.1 and later specifications.
Topics addressed in RFC-1755 include (but are not limited to)
VC management procedures, e.g., when to time-out SVCs, QOS
parameters, service classes, explicit setup message formats for
various encapsulation methods, node (host or router) to node
negotiations, etc.
o MTUサイズなどのパラメタのシグナリングと交渉とカプセル化の方法。 RFC-1755[10]はATM ForumのUNIバージョン3.0仕様[4]と、結局初めはATM ForumのUNIバージョン3.1以降仕様に基づくように基づいたSVCsを設立するようにATMネットワークに示すルータのための実現協定について説明します。 しかし、話題がRFC-1755にインクルードを記述した、(制限されない、)、VC管理手順、例えば、タイムアウトSVCs、QOSパラメタ、サービスのクラス、様々なカプセル化方法のための明白なセットアップメッセージ・フォーマット、ノード交渉へのノード(ホストかルータ)などへのいつ?
RFC-1577 is also applicable to PVC-based subnets. Full mesh PVC connectivity is required.
また、RFC-1577もPVCベースのサブネットに適切です。 完全なメッシュPVCの接続性が必要です。
For more information see RFC-1577 [8].
詳しい情報に関しては、RFC-1577[8]を見てください。
8.2 The ROLC NHRP Model
8.2 ROLC NHRPモデル
The Next Hop Resolution Protocol (NHRP), currently a work in progress defined by the Routing Over Large Clouds Working Group (ROLC), performs address resolution to accomplish direct connections across IP subnet boundaries. NHRP can supplement RFC-1577 ARP. There has been recent discussion of replacing RFC-1577 ARP with NHRP. NHRP can also perform a proxy address resolution to provide the address of the border router serving a destination off of the NBMA which is only
Next Hop Resolutionプロトコル(NHRP)(現在のルート設定Over Large Clouds作業部会(ROLC)によって定義された処理中の作業)はIPサブネット境界の向こう側にダイレクト接続を実行するアドレス解決を実行します。 NHRPはRFC-1577 ARPを補うことができます。 RFC-1577 ARPをNHRPに取り替える最近の議論がありました。 また、NHRPはそうするNBMAだけから目的地に役立つ境界ルータのアドレスを提供するプロキシアドレス解決を実行できます。
Cole, Shur & Villamizar Informational [Page 23] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[23ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
served by a single router on the NBMA. NHRP as currently defined cannot be used in this way to support addresses learned from routers for which the same destinations may be heard at other routers, without the risk of creating persistent routing loops.
NBMAの上のただ一つのルータで、役立たれています。 同じ目的地が他のルータで聞かれるかもしれないルータから学習されたアドレスをサポートするこのように現在定義されているとしてのNHRPを使用できません、しつこいルーティング輪を作成するというリスクなしで。
8.3 "Conventional" Model
8.3 「従来」のモデル
The "Conventional Model" assumes that a router can relay IP packets cell by cell, with the VPI/VCI identifying a flow between adjacent routers rather than a flow between a pair of nodes. A latency advantage can be provided if cell interleaving from multiple IP packets is allowed. Interleaving frames within the same VCI requires an ATM AAL such as AAL3/4 rather than AAL5. Cell forwarding is accomplished through a higher level mapping, above the ATM VCI layer.
「従来機」は、ルータがセルでIPパケットセルをリレーできると仮定します、VPI/VCIが1組のノードの間の流れよりむしろ隣接しているルータの間の流れを特定していて。 複数のIPパケットからのセルインターリービングを許容するなら、潜在利点を提供できます。 同じVCIの中でフレームをはさみ込むのはAAL5よりむしろAAL3/4などのATM AALを必要とします。 セル推進はATM VCI層を超えたより高い平らなマッピングを通して実行されます。
The conventional model is not under consideration by the IP/ATM WG. The COLIP WG has been formed to develop protocols based on the conventional model.
従来機がIP/ATM WGによる考慮でありません。 COLIP WGは、従来機に基づくプロトコルを開発するために形成されました。
8.4 The Peer Model
8.4 同輩モデル
The Peer Model places IP routers/gateways on an addressing peer basis with corresponding entities in an ATM cloud (where the ATM cloud may consist of a set of ATM networks, inter-connected via UNI or P-NNI interfaces). ATM network entities and the attached IP hosts or routers exchange call routing information on a peer basis by algorithmically mapping IP addressing into the NSAP space. Within the ATM cloud, ATM network level addressing (NSAP-style), call routing and packet formats are used.
Peer Modelは対応する実体でATM雲(ATM雲が1セットのUNIを通してインタコネクトされたATMネットワークかP-NNIインタフェースから成るかもしれないところ)でIPルータ/ゲートウェイをアドレシング同輩ベースに置きます。 ホストかルータが交換するATMネットワーク実体と付属IPは、NSAPスペースにルーティングをalgorithmicallyにIPアドレシングを写像することによって、同輩ベースの情報と呼びます。 ATM雲の中では、(NSAP-スタイル)を記述するATMネットワークレベル、呼び出しルーティング、およびパケット・フォーマットは使用されています。
In the Peer Model no provision is made for selection of primary path and use of alternate paths in the event of primary path failure in reaching multihomed non-ATM destinations. This will limit the topologies for which the peer model alone is applicable to only those topologies in which non-ATM networks are singly homed, or where loss of backup connectivity is not an issue. The Peer Model may be used to avoid the need for an address resolution protocol and in a proxy- ARP mode for stub networks, in conjunction with other mechanisms suitable to handle multihomed destinations.
Peer Modelでは、第一の経路の選択に備えて、代替パスの達することにおける第一の経路失敗の場合、使用は非ATMの目的地を「マルチ-家へ帰」らせました。 唯一の同輩モデルがどれであるかに、それらだけに適切なtopologiesがネットワークがどの非ATMであるかで単独でtopologiesするこの意志の限界はバックアップの接続性の損失が問題でないところと家へ帰りました。 Peer Modelはアドレス解決プロトコルの必要性を避けるのに使用されたかもしれなくて、扱うのにおいて適当な他のメカニズムに関連したスタッブネットワークのためのプロキシARPモードで目的地を「マルチ-家へ帰」らせました。
During the discussions of the IP over ATM working group, it was felt that the problems with the end-to-end peer model were much harder than any other model, and had more unresolved technical issues. While encouraging interested individuals/companies to research this area, it was not an initial priority of the working group to address these issues. The ATM Forum Network Layer Multiprotocol Working Group has reached a similar conclusion.
ATMワーキンググループの上のIPの議論の間、それは、終わりから終わりへの同輩モデルに関する問題がいかなる他のモデルよりもはるかに困難であると感じられて、より未定の専門的な問題を持っていました。 関心がある個人/会社がこの領域について研究するよう奨励している間、これらの問題を記述するのは、ワーキンググループの初期の優先ではありませんでした。 ATM Forum Network Layer Multiprotocol作業部会は同様の結論に達しました。
Cole, Shur & Villamizar Informational [Page 24] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[24ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
8.5 The PNNI and the Integrated Models
8.5 PNNIと統合モデル
The Integrated model (proposed and under study within the Multiprotocol group of ATM Forum) considers a single routing protocol to be used for both IP and for ATM. A single routing information exchange is used to distribute topological information. The routing computation used to calculate routes for IP will take into account the topology, including link and node characteristics, of both the IP and ATM networks and calculates an optimal route for IP packets over the combined topology.
Integratedモデル(提案されてATM ForumのMultiprotocolグループの中の研究での)は、ただ一つのルーティング・プロトコルがIPとATMのための両方に使用されると考えます。 ただ一つのルーティング情報交換は、位相的な情報を分配するのに使用されます。 ルーティング計算は、以前はよくIPのためのルートがIPとATMネットワークの両方のリンクとノード特性を含んでいて、トポロジーを考慮に入れて、結合したトポロジーの上でIPパケットのための最適のルートを計算すると見込んでいました。
The PNNI is a hierarchical link state routing protocol with multiple link metrics providing various available QoS parameters given current loading. Call route selection takes into account QoS requirements. Hysteresis is built into link metric readvertisements in order to avoid computational overload and topological hierarchy serves to subdivide and summarize complex topologies, helping to bound computational requirements.
PNNIは現在のローディングを考えて、複数のリンク測定基準が様々な利用可能なQoSパラメタを提供している階層的なリンク州のルーティング・プロトコルです。 呼び出しルート選択はQoS要件を考慮に入れます。 リンクのメートル法の再広告は、複雑なtopologies(制限されたコンピュータの要件への一杯)を細分して、まとめるためにコンピュータのオーバーロードと位相的な階層構造サーブを避けるためにヒステリシスに組み込まれます。
Integrated Routing is a proposal to use PNNI routing as an IP routing protocol. There are several sets of technical issues that need to be addressed, including the interaction of multiple routing protocols, adaptation of PNNI to broadcast media, support for NHRP, and others. These are being investigated. However, the ATM Forum MPOA group is not currently performing this investigation. Concerned individuals are, with an expectation of bringing the work to the ATM Forum and the IETF.
統合ルート設定はIPルーティング・プロトコルとしてPNNIルーティングを使用するという提案です。 記述される必要がある数セットの専門的な問題があります、複数のルーティング・プロトコルの相互作用、電波媒体へのPNNIの適合、NHRPのサポート、および他のものを含んでいて。 これらは調査されています。 しかしながら、ATM Forum MPOAグループは現在、この調査を実行していません。 関係がある個人はATM ForumとIETFに仕事をもたらすことへの期待と共にいます。
PNNI has provisions for carrying uninterpreted information. While not yet defined, a compatible extension of the base PNNI could be used to carry external routing attributes and avoid the routing loop problems described in Section 7.
PNNIには、非解釈された情報を運ぶための条項があります。 まだ定義されていない間、外部のルーティング属性を運んで、セクション7で説明されたルーティング輪の問題を避けるのにベースPNNIのコンパチブル拡張子を使用できました。
Cole, Shur & Villamizar Informational [Page 25] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[25ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
++++++++++++++++++++++++++++++++++++++++++
+ .------------. .------------. +
.---------. + .-: :-. .-: :-. +
: Host or >-+-< : Single ATM : >--< : Single ATM : >-+-----\
: Router : + : : Domain : : : : Domain : : + :
--------- + -: :- -: :- + .---^----.
+ ------------ ------------ + : Router :
+ .------------. + ---v----
.---------. + .-: :-. + :
: Host or >-+- ... ... --< : Single ATM : >-+-----/
: Router : + : : Domain : : +
--------- + ATM Cloud -: :- +
+ ------------ +
++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++ + .------------. .------------. + .---------. + .-: :-. .-: :-. + : ホストか>+<: ただ一つの気圧: >--<: ただ一つの気圧: >。+-----\ : ルータ: + : : ドメイン: : : : ドメイン: : + : --------- + -: :- -: :- + .---^----. + ------------ ------------ + : ルータ: + .------------. + ---v---- .---------. + .-: :-. + : : ホストか>+、-、… ... --<: ただ一つの気圧: >。+-----/ : ルータ: + : : ドメイン: : + --------- + 気圧雲、-、: :- + + ------------ + ++++++++++++++++++++++++++++++++++++++++++
Note: IS within ATM cloud are ATM IS
以下に注意してください。 ATM雲の中に、ATM ISがあるということです。
Figure 6: The ATM transition model assuming the presence of gateways
or routers between the ATM networks and the ATM peer networks.
図6: ATMネットワークとATM同輩ネットワークの間のゲートウェイかルータの存在を仮定するATM変遷モデル。
8.6 Transition Models
8.6 変遷モデル
Finally, it is useful to consider transition models, lying somewhere between the Classical IP Models and the Peer and Integrated Models. Some possible architectures for transition models have been suggested by Fong Liaw. Others are possible, for example Figure 6 showing a Classical IP transition model which assumes the presence of gateways between ATM networks and ATM Peer networks.
最終的に、変遷モデルを考えるのは役に立ちます、Classical IP Modelsと、PeerとIntegrated Modelsの間のどこかに横たわっていて。 いくつかの変遷モデルに、可能な構造がフォンLiawによって勧められました。 他のものは可能です、例えば、図6が、どれがATMネットワークとATM Peerネットワークの間のゲートウェイの存在を仮定するかをClassical IP変遷モデルに示して。
Some of the models described in the prior sections, most notably the Integrated Model, anticipate the need for mixed environment with complex routing topologies. These inherently support transition (possibly with an indefinite transition period). Models which provide no transition support are primarily of interest to new deployments which make exclusive, or near exclusive use of ATM or deployments capable of wholesale replacement of existing networks or willing to retain only non-ATM stub networks.
先のセクションで説明されたモデルの何人か(最も著しくIntegrated Model)が複雑なルーティングtopologiesで複雑な環境の必要性を予期します。 これらは本来変遷(ことによると無期過渡期がある)を支持します。 変遷サポートを全く提供しないモデルは、主としてATMの排他的であるか、近い専用を作る新しい展開か既存のネットワークの大量の交換ができる展開に興味があるか非ATMスタッブネットワークだけを保有しても構わないと思っています。
For some models, most notably the Peer Model, the ability to attach to a large non-ATM or mixed internetwork is infeasible without routing support at a higher level, or at best may pose interconnection topology constraints (for example: single point of attachment and a static default route). If a particular model requires routing support at a higher level a large deployment will need to be subdivided to provide scalability at the higher level, which for some models degenerates back to the Classical model.
何人かのモデル、最も著しくPeer Modelに関しては、大きい非ATMか複雑なインターネットワークに付く能力は、ルーティングサポートなしで、より高いレベルで実行不可能であるか、またはインタコネクトトポロジー規制(: 例えば、単一の接着点と静的なデフォルトルート)をせいぜい引き起こすかもしれません。 特定のモデルが、より高いレベルでスケーラビリティを提供するために細分されるために大きい展開が必要とするより高いレベルでサポートを発送するのを必要とするなら。何人かのモデルのために、レベルはClassicalモデルに退化して戻っています。
Cole, Shur & Villamizar Informational [Page 26] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[26ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
9. Application of the Working Group's and Related Documents
9. 作業部会と関連ドキュメントのアプリケーション
The IP Over ATM Working Group has generated several Works in Progress and RFCs. This section identifies the relationship of these and other related documents to the various IP Over ATM Models identified in this document. The documents and RFCs produced to date are the following references, RFC-1483 [6], RFC-1577 [8], RFC-1626 [1], RFC- 1755 [10] and the IPMC documents. The ROLC WG has produced the NHRP document. Table 5 gives a summary of these documents and their relationship to the various IP Over ATM Models.
IP Over ATM作業部会はProgressとRFCsの数個のWorksを発生させました。 このセクションは本書では特定された様々なIP Over ATM Modelsにこれらと他の関連するドキュメントの関係を特定します。 ドキュメントとこれまで製作されたRFCsは以下の参照と、RFC-1483[6]と、RFC-1577[8]と、RFC-1626[1]と、RFC1755[10]とIPMCドキュメントです。 ROLC WGはNHRPドキュメントを製作しました。 テーブル5は様々なIP Over ATM Modelsとのこれらのドキュメントとそれらの関係の概要をします。
Acknowledgments
承認
This memo is the direct result of the numerous discussions of the IP over ATM Working Group of the Internet Engineering Task Force. The authors also had the benefit of several private discussions with H. Nguyen of AT&T Bell Laboratories. Brian Carpenter of CERN was kind enough to contribute the TULIP and TUNIC sections to this memo. Grenville Armitage of Bellcore was kind enough to contribute the sections on VC binding, encapsulations and the use of B-LLI information elements to signal such bindings. The text of Appendix A was pirated liberally from Anthony Alles' of Cisco posting on the IP over ATM discussion list (and modified at the authors' discretion). M. Ohta provided a description of the Conventional Model (again which the authors modified at their discretion). This memo also has benefitted from numerous suggestions from John T. Amenyo of ANS, Joel Halpern of Newbridge, and Andy Malis of Ascom-Timplex. Yakov Rekhter of Cisco provided valuable comments leading to the clarification of normal loop free NHRP operation and the potential for routing loop problems only with the improper use of NHRP.
このメモはインターネット・エンジニアリング・タスク・フォースのATM作業部会の上のIPの頻繁な議論の直接の結果です。 また、作者には、AT&Tベル研究所のH.Nguyenとのいくつかの個人的な議論の恩恵がありました。 CERNのブライアンCarpenterはTULIPとTUNIC部をこのメモに寄付するほど親切でした。 Bellcoreのグレンビルアーミテージはそのような結合に合図するためにB-LLI情報要素のVC結合でのセクション、カプセル化、および使用を寄付するほど親切でした。 'ATM議論リスト(そして、作者では、'の思慮深さを変更する)の上のIPでシスコの任命のアンソニーAllesからAppendix Aのテキストについて気前よく著作権を侵害しました。 M。 太田がConventional Modelの記述を提供した、(再び作者が自己判断で変更したもの) このメモもANSのジョンT.Amenyo、Newbridgeのジョエル・アルペルン、およびAscom-TimplexのアンディMalisから頻繁な提案の利益を得ました。 シスコのヤコフRekhterはNHRPの不適当な使用だけに関するルーティング輪の問題の無料のNHRP操作と可能性を正常な輪の明確化に導く貴重なコメントを提供しました。
Documents Summary
----------------+-------------------------------------------------
RFC-1483 _ How to identify/label multiple
_ packet/frame-based protocols multiplexed over
_ ATM AAL5. Applies to any model dealing with IP
_ over ATM AAL5.
_
RFC-1577 _ Model for transporting IP and ARP over ATM AAL5
_ in an IP subnet where all nodes share a common
_ IP network prefix. Includes ARP server/Inv-ARP
_ packet formats and procedures for SVC/PVC
_ subnets.
_
RFC-1626 _ Specifies default IP MTU size to be used with
_ ATM AAL5. Requires use of PATH MTU discovery.
_ Applies to any model dealing with IP over ATM
_ AAL5
ドキュメント概要----------------+------------------------------------------------- フレーム複数の_パケット/ベースのプロトコルを特定するか、またはラベルするRFC-1483_Howは_ATM AAL5の上で多重送信しました。 ATM AAL5の上でIP_に対処するどんなモデルにも適用します。 _ IPサブネットですべてのノードが一般的な_IPを共有するところにATM AAL5_の上のIPとARPを輸送するためのRFC-1577_Modelは接頭語をネットワークでつなぎます。 SVC/PVC_サブネットのためのARPサーバ/Inv-ARP_パケット・フォーマットと手順を含んでいます。 _ _ATM AAL5と共に使用されるべきRFC-1626_SpecifiesデフォルトIP MTUサイズ。 PATH MTU発見の使用を必要とします。 _ ATM_AAL5の上でIPと取り引きするどんなモデルにも適用します。
Cole, Shur & Villamizar Informational [Page 27] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[27ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
_
RFC-1755 _ Defines how implementations of IP over ATM
_ should use ATM call control signaling
_ procedures, and recommends values of mandatory
_ and optional IEs focusing particularly on the
_ Classical IP model.
_
IPMC _ Defines how to support IP multicast in Classical
_ IP model using either (or both) meshes of
_ point-to-multipoint ATM VCs, or multicast
_ server(s). IPMC is work in progress.
_
NHRP _ Describes a protocol that can be used by hosts
_ and routers to determine the NBMA next hop
_ address of a destination in "NBMA
_ connectivity"
_ of the sending node. If the destination is not
_ connected to the NBMA fabric, the IP and NBMA
_ addresses of preferred egress points are
_ returned. NHRP is work in progress (ROLC WG).
_ATM_の上のIPの実現がATM呼び出しコントロールシグナリング_手順を用いるべきであり、特に_Classical IPモデルに焦点を合わせる義務的な_と任意のIEsの値を推薦するRFC-1755_Defines。 _ _ClassicalでIPマルチキャストを支持するために、IPが_ポイントツーマルチポイントATM VCs、またはマルチキャスト_サーバのメッシュを使用のどちらか(ともに)でモデル化されるIPMC_Defines。 IPMCは処理中の作業です。 _ 使用できるNHRP_Describes aプロトコルは_を接待します、そして、NBMA次を決定するルータは送付ノードの「NBMA_接続性」_を_目的地のアドレスを飛び越します。 目的地がNBMA織物に接続された_でないなら、_が演説する都合のよい出口ポイントのIPとNBMAは返された_です。 NHRPは処理中の作業(ROLC WG)です。
Table 5: Summary of WG Documents
テーブル5: WGドキュメントの概要
References
参照
[1] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626,
Naval Research Laboratory, May 1994.
[1] アトキンソン、R.、「ATM AAL5"、RFC1626、海軍研究試験所、1994年5月の間の使用のためのデフォルトIP MTU。」
[2] Braden, R., and J. Postel, "Requirements for Internet Gateways",
STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[2] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」STD4、RFC1009、科学が1987年6月に設けるUSC/情報。
[3] Braden, R., Postel, J., and Y. Rekhter, "Internet Architecture
Extensions for Shared Media", RFC 1620, USC/Information Sciences
Institute, IBM Research, May 1994.
[3] ブレーデンとR.とポステル、J.とY.Rekhter、「共有されたメディアのためのインターネット構造拡大」RFC1620、科学が設けるUSC/情報(IBMの研究)は1994がそうするかもしれません。
[4] ATM Forum, "ATM User-Network Interface Specification", Prentice
Hall, September 1993.
[4]気圧フォーラム、「気圧ユーザネットワーク・インターフェース仕様」、新米のホール、1993年9月。
[5] Garrett, J., Hagan, J., and J. Wong, "Directed ARP", RFC 1433,
AT&T Bell Labs, University of Pennsylvania, March 1993.
[5] ギャレットとJ.とハーガン、J.とJ.ウォン、「指示されたARP」RFC1433、AT&Tベル研究所、ペンシルバニア大学、1993年3月。
[6] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, Telecom Finland, July 1993.
[6] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は5インチと、RFC1483、テレコムフィンランド1993年7月に層にします」。
[7] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol
(NARP)", RFC 1735, Telecom Finland, USC/Information Sciences
Institute, December 1994.
[7] Heinanen、J.、およびR.Govindan、「NBMAアドレス解決プロトコル(NARP)」とRFC1735、テレコムフィンランドUSC/情報科学は、1994年12月に設けます。
Cole, Shur & Villamizar Informational [Page 28] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[28ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
[8] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[8]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、ヒューレット・パッカード研究所、1月1994
[9] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
[9] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。
[10] Perez, M., Liaw, F., Grossman, D., Mankin, A., and A. Hoffman,
"ATM signalling support for IP over ATM", RFC 1755,
USC/Information Sciences Institute, FORE Systems, Inc., Motorola
Codex, Ascom Timeplex, Inc., January 1995.
[10] ペレス、M.、Liaw、F.、グロースマン、D.、マンキン、A.、およびA.ホフマン、「ATMの上でIPのサポートに合図するATM」、RFC1755、USC/情報Sciences Institute、FORE Systems Inc.、モトローラCodex、Ascom Timeplex Inc.(1995年1月)。
[11] Mills, D., "Exterior Gateway Protocol Formal Specification",
STD 18, RFC 904, BBN, April 1984.
[11] 工場、D.、「外のゲートウェイプロトコル形式仕様」、STD18、RFC904、BBN、1984年4月。
A Potential Interworking Scenarios to be Supported by ARP
ARPによるSupportedであるPotential Interworking Scenarios
The architectural model of the VC routing protocol, being defined by the Private Network-to-Network Interface (P-NNI) working group of the ATM Forum, categorizes ATM networks into two types:
ATM Forumの兵士のNetworkからネットワークへのInterface(P-NNI)ワーキンググループによって定義されたVCルーティング・プロトコルの建築モデルはATMネットワークを2つのタイプに分類します:
o Those that participate in the VC routing protocols and use NSAP
modeled addresses UNI 3.0 [4] (referred to as private networks,
for short), and
o そしてNSAPがモデル化したVCルーティング・プロトコルと使用に参加する人がUNI3.0[4](ショートのために私設のネットワークと呼ばれる)を記述する。
o Those that do not participate in the VC routing protocol.
Typically, but possibly not in all cases, public ATM networks
that use native mode E.164 addresses UNI 3.0 [4] will fall into
this later category.
o VCルーティングに参加しないものが議定書を作ります。 すべてのケース、通常にもかかわらず、ことによるとネイティブモードE.164アドレスを使用するどんな公立のATMネットワークでも、UNI3.0[4]はこの後のカテゴリにならないでしょう。
The issue for ARP, then is to know what information must be returned to allow such connectivity. Consider the following scenarios:
ARPのための問題であり、その時は、そのような接続性を許容するためにどんな情報を返さなければならないかを知ることになっています。 以下のシナリオを考えてください:
o Private host to Private Host, no intervening public transit
network(s): Clearly requires that ARP return only the NSAP
modeled address format of the end host.
o 兵士のHostの介入している公立のトランジットネットワークがない個人的なホスト: 明確に、ARPが終わりのホストのモデル化されたアドレス形式をNSAPだけに返すのが必要です。
o Private host to Private host, through intervening public
networks: In this case, the connection setup from host A to host
B must transit the public network(s). This requires that at
each ingress point to the public network that a routing decision
be made as to which is the correct egress point from that public
network to the next hop private ATM switch, and that the native
E.164 address of that egress point be found (finding this is a VC
routing problem, probably requiring configuration of the public
network links and connectivity information). ARP should return,
at least, the NSAP address of the endpoint in which case the
mapping of the NSAP addresses to the E.164 address, as specified
in [4], is the responsibility of ingress switch to the public
o 介入している公衆通信回線を通した兵士のホストの個人的なホスト: この場合、ホストAからホストBまでの接続設定は公衆通信回線を通過しなければなりません。 これはその公衆通信回線から個人的なATMが切り換えて、ネイティブのE.164が記述するその出口ポイントの次のホップまでどれが正しい出口ポイントであるかに見つけられるようにルーティング決定をするという公衆通信回線へのそれぞれのイングレスポイントでそれを必要とします(これを見つけるのは、VCルーティング問題です、たぶん公衆通信回線リンクと接続性情報の構成を必要として)。 ARPは少なくとも終点のNSAPアドレスを返すはずです、その場合、[4]で指定されるE.164アドレスへのNSAPアドレスに関するマッピングが公衆へのイングレススイッチの責任です。
Cole, Shur & Villamizar Informational [Page 29] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[29ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
network.
ネットワークでつなぎます。
o Private Network Host to Public Network Host: To get connectivity
between the public node and the private nodes requires the
same kind of routing information discussed above - namely, the
directly attached public network needs to know the (NSAP format)
ATM address of the private station, and the native E.164 address
of the egress point from the public network to that private
network (or to that of an intervening transit private network
etc.). There is some argument, that the ARP mechanism could
return this egress point native E.164 address, but this may
be considered inconsistent for ARP to return what to some is
clearly routing information, and to others is required signaling
information.
o 公衆通信回線ホストの個人的なネットワークホスト: 公共のノードと個人的なノードの間から接続性を抜くのは上で議論した同じ種類のルーティング情報を必要とします--すなわち、直接付属している公衆通信回線は、公衆通信回線から私設のそのネットワーク(またはネットワークの介入しているトランジット個人的ななどのものに)まで私設放送局の(NSAP形式)ATMアドレス、および出口ポイントの固有のE.164アドレスを知る必要があります。 ARPメカニズムがネイティブのE.164が記述するこの出口ポイントを返すかもしれないという何らかの主張がありますが、これは、ARPが明確に情報をいくつかに発送しているものを返すように矛盾していると考えられるかもしれなくて、他のものにとって必要なシグナリング情報です。
In the opposite direction, the private network node can use, and should only get, the E.164 address of the directly attached public node. What format should this information be carried in? This question is clearly answered, by Note 9 of Annex A of UNI 3.0 [4], vis:
逆方向に、個人的なネットワーク・ノードは、直接添付の公共のノードのE.164アドレスを使用できて、得るだけであるはずです。 どんな形式に、この情報は運ばれるべきですか? この質問はUNI3.0[4]のAnnex A、visのNote9によって明確に答えられます:
"A call originated on a Private UNI destined for an host which
only has a native (non-NSAP) E.164 address (i.e. a system
directly attached to a public network supporting the native E.164
format) will code the Called Party number information element in
the (NSAP) E.164 private ATM Address Format, with the RD, AREA,
and ESI fields set to zero. The Called Party Subaddress
information element is not used."
「呼び出しはホストのために運命づけられた兵士のUNIで由来しました(E.164アドレス(すなわち、直接ネイティブのE.164形式を支持する公衆通信回線に取り付けられたシステム)がゼロに合わせるために用意ができているRD、AREA、およびESI分野がある(NSAP)E.164の個人的なATM Address FormatのCalledパーティ数の情報要素をコード化するネイティブ(非NSAP)がいるだけです)。」 「CalledパーティSubaddress情報要素は使用されていません。」
Hence, in this case, ARP should return the E.164 address of the public ATM station in NSAP format. This is essentially implying an algorithmic resolution between the native E.164 and NSAP addresses of directly attached public stations.
したがって、この場合、ARPはNSAP形式で公立のATMステーションのE.164アドレスを返すはずです。 これは本質的には直接付属している公営放送局のネイティブのE.164とNSAPアドレスの間のアルゴリズムの解決を含意しています。
o Public network host to Public network host, no intervening
private network: In this case, clearly the Q.2931 requests would
use native E.164 address formats.
o 介入している私設のネットワークがないPublicネットワークホストの公衆通信回線ホスト: この場合、明確に、Q.2931要求は固有のE.164アドレス形式を使用するでしょう。
o Public network host to Public network host, intervening private
network: same as the case immediately above, since getting
to and through the private network is a VC routing, not an
addressing issue.
o 介入している私設のネットワークのPublicネットワークホストの公衆通信回線ホスト: ネットワークと、そして、私設のネットワークを通して得て以来のすぐに上のケースと同じことはアドレシング問題ではなく、VCルーティングです。
So several issues arise for ARP in supporting arbitrary connections between hosts on private and public network. One is how to distinguish between E.164 address and E.164 encoded NSAP modeled address. Another is what is the information to be supplied by ARP, e.g., in the public to private scenario should ARP return only the
それで、いくつかの問題がARPのために個人的におけるホストの間の任意の接続と公衆通信回線を支持する際に起こります。 1つはE.164アドレスとE.164を見分けるために、コード化されたNSAPがどうアドレスをモデル化したかということです。 別のものはARPが戻るならARP、例えば、個人的なシナリオへの公衆で提供される情報である唯一のものです。
Cole, Shur & Villamizar Informational [Page 30] RFC 1932 IP over ATM: A Framework Document April 1996
気圧でのコール、シュル、およびVillamizarの情報[30ページ]のRFC1932IP: 枠組みのドキュメント1996年4月
private NSAP modeled address or both an E.164 address, for a point of attachment between the public and private networks, along with the private NSAP modeled address.
個人的なNSAPがアドレスをモデル化したか、またはE.164が記述する両方が個人的なNSAPと共に公共の、そして、私設のネットワークの間の接着点にアドレスをモデル化しました。
Authors' Addresses
作者のアドレス
Robert G. Cole AT&T Bell Laboratories 101 Crawfords Corner Road, Rm. 3L-533 Holmdel, NJ 07733
Rm、ロバートG.コールAT&Tベル研究所101Crawfordsは道路を追い詰めます。 3L-533 Holmdel、ニュージャージー 07733
Phone: (908) 949-1950 Fax: (908) 949-8887 EMail: rgc@qsun.att.com
以下に電話をしてください。 (908) 949-1950 Fax: (908) 949-8887 メールしてください: rgc@qsun.att.com
David H. Shur AT&T Bell Laboratories 101 Crawfords Corner Road, Rm. 1F-338 Holmdel, NJ 07733
Rm、デヴィッドH.シュルAT&Tベル研究所101Crawfordsは道路を追い詰めます。 1F338Holmdel、ニュージャージー 07733
Phone: (908) 949-6719 Fax: (908) 949-5775 EMail: d.shur@att.com
以下に電話をしてください。 (908) 949-6719 Fax: (908) 949-5775 メールしてください: d.shur@att.com
Curtis Villamizar ANS 100 Clearbrook Road Elmsford, NY 10523
カーティスVillamizar ANS100Clearbrook Roadエルムスフォード、ニューヨーク 10523
EMail: curtis@ans.net
メール: curtis@ans.net
Cole, Shur & Villamizar Informational [Page 31]
コール、シュル、およびVillamizar情報です。[31ページ]
一覧
スポンサーリンク
