RFC2098 日本語訳
2098 Toshiba's Router Architecture Extensions for ATM : Overview. Y.Katsube, K. Nagami, H. Esaki. February 1997. (Format: TXT=43622 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Katsube
Request for Comments: 2098 K. Nagami
Category: Informational H. Esaki
Toshiba R&D Center
February 1997
Katsubeがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2098年のK.Nagamiカテゴリ: 情報のH.江崎東芝研究開発センター1997年2月
Toshiba's Router Architecture Extensions for ATM : Overview
気圧のための東芝のルータ構造拡大: 概観
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "Cell Switch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such as RSVP.
このメモは有効にATMの特性を利用する新しいインターネットワーキング構造について説明します。 ホップごとの経路に沿ってルータでIPデータグラムを移しますが、必ず提案された構造の個々のルータでデータグラムアセンブリ/分解とIPヘッダー処理を行うというわけではありません。 「セルスイッチルータ(CSR)」の概念は新しいインターネットワーキング設備として紹介されます。(それは、従来のIPデータグラム推進に加えたATMセルスイッチング能力を持っています)。 提案された構造は現在のルータベースのインターネットワーキング概念を保有している間、高生産性と低遅延ATMパイプをアプリケーションに提供できます。 また、それは、RSVPなどのインターネットワーキングレベル資源予約プロトコルに協力することによって、特定のQoS/帯域幅をアプリケーションに提供します。
1. Introduction
1. 序論
The Internet is growing both in its size and its traffic volume. In addition, recent applications often require guaranteed bandwidth and QoS rather than best effort. Such changes make the current hop-by- hop datagram forwarding paradigm inadequate, then accelerate investigations on new internetworking architectures.
インターネットがサイズとその交通量に生えています。 さらに、最近のアプリケーションはしばしば保証された帯域幅とベストエフォート型であるよりむしろQoSを必要とします。 そのような変化は、近く現在の跳びホップをデータグラム推進パラダイム不十分にして、次に、新しいインターネットワーキング構造で調査を加速します。
Roughly two distinct approaches can be seen as possible solutions; the use of ATM to convey IP datagrams, and the revision of IP to support flow concept and resource reservation. Integration or interworking of these approaches will be necessary to provide end hosts with high throughput and QoS guaranteed internetworking services over any datalink platforms as well as ATM.
およそ2つの異なったアプローチを可能な解決策と考えることができます。 IPデータグラム、およびIPの改正をサポートフロー概念と資源予約に伝えるATMの使用。 これらのアプローチを統合か織り込むことが、ATMと同様にどんなデータリンクプラットホームにわたっても高生産性とインターネットワーキングサービスが保証されたQoSを終わりのホストに提供するために必要になるでしょう。
New internetworking architecture proposed in this draft is based on "Cell Switch Router (CSR)" which has the following properties.
この草稿で提案された新しいインターネットワーキング構造は以下の特性を持っている「セルスイッチルータ(CSR)」に基づいています。
Katsube, et. al. Informational [Page 1] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[1ページ]のRFC2098東芝のルータ拡大
- It makes the best use of ATM's property while retaining current
router-based internetworking and routing architecture.
- それは現在のルータベースのインターネットワーキングとルーティング構造を保有している間、有効にATMの特性を利用します。
- It takes into account interoperability with future IP that
supports flow concept and resource reservations.
- それは将来のIPがあるフロー概念を支持する相互運用性と資源予約を考慮に入れます。
Section 2 of this draft explains background and motivations of our proposal. Section 3 describes an overview of the proposed internetworking architecture and its several remarkable features. Section 4 discusses control architectures for CSR, which will need to be further investigated.
この草稿のセクション2は私たちの提案のバックグラウンドと動機について説明します。 セクション3は提案されたインターネットワーキング構造とそのいくつかの顕著な特徴の概観について説明します。 セクション4はCSRのために規制構造について論じます。(CSRはさらに調査される必要があるでしょう)。
2. Background and Motivation
2. バックグラウンドと動機
It is considered that the current hop-by-hop best effort datagram forwarding paradigm will not be adequate to support future large scale Internet which accommodates huge amount of traffic with certain QoS requirements. Two major schools of investigations can be seen in IETF whose main purpose is to improve ability of the Internet with regard to its throughput and QoS. One is to utilize ATM technology as much as possible, and the other is to introduce the concept of resource reservation and flow into IP.
ホップごとの現在のベストエフォート型データグラム推進パラダイムが、あるQoS要件と共に交通の膨大な量を収容する将来の大規模インターネットを支持するために適切にならないと考えられます。 そのスループットとQoSに関してインターネットの能力を改良するIETFの主な目的がことである調査の2つの主要な学校を見ることができます。 1つはATM技術をできるだけ利用することになっています、そして、もう片方は資源予約と流れの概念をIPに紹介することです。
1) Utilization of ATM
1) 気圧の利用
Although basic properties of ATM; necessity of connection setup, necessity of traffic contract, etc.; is not necessarily suited to conventional IP datagram transmission, its excellent throughput and delay characteristics let us to investigate the realization of IP datagram transmission over ATM.
ATMの基礎特性ですが。 接続設定の必要性、交通契約の必要性など。 特性が調査するために私たちをさせるその必ず従来のIPに合ったデータグラムトランスミッション、素晴らしいスループット、および遅れはATMの上のIPデータグラムトランスミッションの実現ではありませんか?
A typical internetworking architecture is the "Classical IP Model" [RFC1577]. This model allows direct ATM connectivities only between nodes that share the same IP address prefix. IP datagrams should traverse routers whenever they go beyond IP subnet boundaries even though their source and destination are accommodated in the same ATM cloud. Although an ATMARP is introduced which is not based on legacy datalink broadcast but on centralized ATMARP servers, this model does not require drastic changes to the legacy internetworking architectures with regard to the IP datagram forwarding process. This model still has problems of limited throughput and large latency, compared with the ability of ATM, due to IP header processing at every router. It will become more critical when multimedia applications that require much larger bandwidth and lower latency become dominant in the near future.
典型的なインターネットワーキング構造は「古典的なIPモデル」[RFC1577]です。 このモデルは同じIPアドレス接頭語を共有するノードだけの間のダイレクトATMの接続性を許容します。 同じATM雲でそれらのソースと目的地に対応しますが、IPサブネット境界を越えるときはいつも、IPデータグラムはルータを横断するはずです。 遺産データリンク放送に基づいているのではなく、集結されたATMARPサーバにあるATMARPを導入しますが、このモデルはIPデータグラム推進の過程に関して遺産インターネットワーキング構造に飛躍的な変化を必要としません。 このモデルには、限られたスループットと大きい潜在の問題がまだあります、ATMの能力と比べて、あらゆるルータにおけるIPヘッダー処理のため。 はるかに大きい帯域幅と下側の潜在を必要とするマルチメディア応用が近い将来優位になると、それは、より批判的になるでしょう。
Katsube, et. al. Informational [Page 2] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[2ページ]のRFC2098東芝のルータ拡大
Another internetworking architecture is "NHRP (Next Hop Resolution Protocol) Model" [NHRP09]. This model aims at resolving throughput and latency problems in the Classical IP Model and making the best use of ATM. ATM connections can be directly established from an ingress point to an egress point of an ATM cloud even when they do not share the same IP address prefix. In order to enable it, the Next Hop Server [KAT95] is introduced which can find an egress point of the ATM cloud nearest to the given destination and resolves its ATM address. A sort of query/response protocols between the server(s) and clients and possibly server and server are specified. After the ATM address of a desired egress point is resolved, the client establishes a direct ATM connection to that point through ATM signaling procedures [ATM3.1]. Once a direct ATM connection has been set up through this procedure, IP datagrams do not have to experience hop-by-hop IP processing but can be transmitted over the direct ATM connection. Therefore, high throughput and low latency communications become possible even if they go beyond IP subnet boundaries. It should be noted that the provision of such direct ATM connections does not mean disappearance of legacy routers which interconnect distinct ATM-based IP subnets. For example, hop-by-hop IP datagram forwarding function would still be required in the following cases:
別のインターネットワーキング構造は「NHRP(次のホップ解決プロトコル)モデル」[NHRP09]です。 このモデルはClassical IP Modelのスループットと潜在問題を解決して、有効にATMを利用するのを目的とします。 彼らが同じIPアドレス接頭語を共有さえしないとき、イングレスポイントからATM雲の出口ポイントまで直接ATM接続を確立できます。 それを可能にするために、与えられた目的地に最も近いATM雲の出口点を見つけることができて、ATMアドレスを決議するNext Hop Server[KAT95]を導入します。 サーバと、クライアントと、ことによるとサーバとサーバの間の質問/応答プロトコルの種類は指定されています。 必要な出口ポイントのATMアドレスが決議された後に、ATMシグナリング手順[ATM3.1]でクライアントはダイレクトATM接続をそのポイントに確立します。 ダイレクトATM接続がこの手順でいったんセットアップされると、IPデータグラムをホップごとのIP処理を経験する必要はありませんが、ダイレクトATM接続の上に送ることができます。 したがって、IPサブネット境界を越えても、高生産性と低遅延コミュニケーションは可能になります。 そのようなダイレクトATM接続の支給が異なったATMベースのIPサブネットとインタコネクトする遺産ルータの消滅を意味しないことに注意されるべきです。 例えば、ホップごとのIPデータグラム推進機能が以下の場合でまだ必要でしょう:
- When you want to transmit IP datagrams before direct ATM connection
from an ingress point to an egress point of the ATM cloud is
established
- イングレスポイントからATM雲の出口ポイントまでのダイレクトATM接続が確立される前にあなたがIPデータグラムを送りたがっているとき
- When you neither require a certain QoS nor transmit large amount of
IP datagrams for some communication
- あなたが何らかのコミュニケーションのためにあるQoSを必要としないで、また多量のIPデータグラムを送らないとき
- When the direct ATM connection is not allowed by security or policy
reasons
- ダイレクトATM接続がセキュリティか方針理由によって許されていないとき
2) IP level resource reservation and flow support
2) IPの平らな資源予約と流れサポート
Apart from investigation on specific datalink technology such as ATM, resource reservation technologies for desired IP level flows have been studied and are still under discussion. Their typical examples are RSVP [RSVP13] and STII [RFC1819].
ATMなどの特定のデータリンク技術における調査は別として、必要なIPレベルが流れるので、資源予約技術は、研究されて、まだ議論であります。 それらの典型的な例は、RSVP[RSVP13]とSTII[RFC1819]です。
RSVP itself is not a connection oriented technology since datagrams can be transmitted regardless of the result of the resource reservation process. After a resource reservation process from a receiver (or receivers) to a sender (or senders) is successfully completed, RSVP-capable routers along the path of the flow reserve their resources for datagram forwarding according to the requested flow spec.
資源予約の過程の結果にかかわらずデータグラムを送ることができるので、RSVP自身は接続指向の技術ではありません。 受信機(または、受信機)から送付者(または、送付者)までの資源予約の過程が首尾よく完了した後に、要求された流れ仕様に従って、流れの経路に沿ったRSVPできるルータはデータグラム推進のためのそれらのリソースを予約します。
Katsube, et. al. Informational [Page 3] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[3ページ]のRFC2098東芝のルータ拡大
STII is regarded as a connection oriented IP which requires connection setup process from a sender to a receiver (or receivers) before transmitting datagrams. STII-capable routers along the path of the requested connection reserve their resources for datagram forwarding according to the flow spec.
接続がデータグラムを送る前に送付者から受信機(または、受信機)まで接続設定の過程を必要とするIPを適応させたので、STIIは見なされます。流れ仕様に従って、要求された接続の経路に沿ったSTIIできるルータはデータグラム推進のためのそれらのリソースを予約します。
Neither RSVP nor STII restrict underlying datalink networks since their primary purpose is to let routers provide each IP flow with desired forwarding quality (by controlling their datagram scheduling rules). Since various datalink networks will coexist as well as ATM in the future, these IP level resource reservation technologies would be necessary in order to provide end-to-end IP flow with desired bandwidth and QoS.
RSVPもSTIIも、それらの第一の目的がルータに必要な推進品質(それらのデータグラムスケジューリング規則を制御するのによる)をそれぞれのIP流動に提供させることであるので、基本的なデータリンクネットワークを制限しません。 様々なデータリンクネットワークが将来ATMと同様に共存するので、これらのIPの平らな資源予約技術が終わりから終わりへのIP流動に必要な帯域幅とQoSを提供するのに必要でしょう。
aking this background into consideration, we should be aware of several issues which motivate our proposal.
aking、考慮へのこのバックグラウンドであり、私たちは私たちの提案を動機づけるいくつかの問題を意識しているべきです。
- As of the time of writing, the ATM specific internetworking
architecture proposed does not take into account interoperability
with IP level resource reservation or connection setup protocols.
In particular, operating RSVP in the NHRP-based ATM cloud seems to
require much effort since RSVP is a soft-state receiver-oriented
protocol with multicast capability as a default, while ATM with
NHRP is a hard-state sender-oriented protocol which does not
support multicast yet.
- 書くことの時現在、構造が提案したATMの特定のインターネットワーキングはIPの平らな資源予約か接続設定プロトコルでアカウント相互運用性を連れていきません。 特に、NHRPベースのATM雲でRSVPを操作するのはRSVPがデフォルトとしてのマルチキャスト能力がある軟性国家の受信機指向のプロトコルであるので多くの努力を必要とするように思えます、NHRPとATMはまだマルチキャストを支持していない固い州の送付者指向のプロトコルですが。
- Although RSVP or STII-based routers will provide each IP flow with
a desired bandwidth and QoS, they have some native throughput
limitations due to the processor-based IP forwarding mechanism
compared with the hardware switching mechanism of ATM.
- RSVPかSTIIベースのルータが必要な帯域幅とQoSをそれぞれのIP流動に提供するでしょうが、彼らには、ATMのハードウェアスイッチ開閉装置と比べてプロセッサベースのIP推進メカニズムによるいくつかのネイティブのスループット制限があります。
The main objective of our proposal is to resolve the above issues.
私たちの提案の主な目標は上記の問題を解決することです。
The proposed internetworking architecture makes the best use of the property of ATM by extending legacy routers to handle future IP features such as flow support and resource reservation with the help of ATM's cell switching capabilities.
提案されたインターネットワーキング構造は、ATMのセルスイッチング能力の助けで流れサポートや資源予約などの将来のIPの特徴を扱うために遺産ルータを広げることによって、有効にATMの特性を利用します。
3. Internetworking Architecture Based On the Cell Switch Router (CSR)
3. セルスイッチルータに基づくインターネットワーキング構造(CSR)
3.1 Overview
3.1 概観
The Cell Switch Router (CSR) is a key network element of the proposed internetworking architecture. The CSR provides cell switching functionality in addition to conventional IP datagram forwarding. Communications with high throughput and low latency, that are native properties of ATM, become possible by using this cell switching functionality even when the communications pass through IP subnetwork
Cell Switch Router(CSR)は提案されたインターネットワーキング構造の主要なネットワーク原理です。 CSRは従来のIPデータグラム推進に加えてセル切り換えの機能性を提供します。 高生産性と低遅延とのコミュニケーションであり、それはATMの固有の特性であり、コミュニケーションがIPサブネットワークを通り抜けるときさえこのセル切り換えの機能性を使用することによって、可能になってください。
Katsube, et. al. Informational [Page 4] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[4ページ]のRFC2098東芝のルータ拡大
boundaries. In an ATM internet composed of CSRs, VPI/VCI-based cell switching which bypasses datagram assembly/disassembly and IP header processing is possible at every CSR for communications which lend themselves to such (e.g., communications which require certain amount of bandwidth and QoS), while conventional hop-by-hop datagram forwarding based on the IP header is also possible at every CSR for other conventional communications.
境界。 CSRsで構成されたATMインターネットでは、そのような(例えば、ある量の帯域幅を必要とするコミュニケーションとQoS)に自分たちを与えるコミュニケーションに、データグラムアセンブリ/分解を迂回させるVPI/VCIベースのセルの切り換えとIPヘッダー処理はあらゆるCSRで可能です、また、他の従来のコミュニケーションに、ホップごとのIPヘッダーに基づく従来のデータグラム推進もあらゆるCSRで可能ですが。
By using such cell-level switching capabilities, the CSR is able to concatenate incoming and outgoing ATM VCs, although the concatenation in this case is controlled outside the ATM cloud (ATM's control/ management-plane) unlike conventional ATM switch nodes. That is, the CSR is attached to ATM networks via an ATM-UNI instead of NNI. By carrying out such VPI/VCI concatenations at multiple CSRs consecutively, ATM level connectivity composed of multiple ATM VCs, each of which connects adjacent CSRs (or CSR and hosts/routers), can be provided. We call such an ATM pipe "ATM Bypass-pipe" to differentiate it from "ATM VCC (VC connection)" provided by a single ATM datalink cloud through ATM signaling.
そのようなセルレベルスイッチング能力を使用することによって、CSRは送受信のATM VCsを連結できます、この場合、連結がATM雲(ATMの管理コントロール/飛行機)の外で従来のATMスイッチノードと異なって制御されますが。 すなわち、CSRはNNIの代わりにATM-UNIを通してATMネットワークに取り付けられます。 複数のCSRsで連続してそのようなVPI/VCI連結を行うことによって、それのそれぞれが隣接しているCSRs(または、CSRとホスト/ルータ)を接続する複数のATM VCsで構成されたATMの平らな接続性は提供できます。 そのようなATMパイプ「気圧迂回パイプ」と、私たちは、単一のATMデータリンク雲によって提供された「ATM VCC(VC接続)」からATMシグナリングまでそれを微分するために呼びます。
Example network configurations based on CSRs are shown in figure 1. An ATM datalink network may be a large cloud which accommodates multiple IP subnets X, Y and Z. Or several distinct ATM datalinks may accommodate single IP subnet X, Y and Z respectively. The latter configuration would be straightforward in discussing the CSR, but the CSR is also applicable to the former configuration as well. In addition, the CSR would be applicable as a router which interconnects multiple NHRP-based ATM clouds.
CSRsに基づく例のネットワーク・コンフィギュレーションは図1に示されます。 ATMデータリンクネットワークはいくつかの異なったATMデータリンクが収容するかもしれない複数のIPサブネットのX、Y、およびZ.Orを収容する大きい雲がそれぞれIPサブネットX、Y、およびZを選抜するということであるかもしれません。 後者の構成はCSRについて議論するのにおいて簡単でしょうが、また、CSRもまた、前の構成に適切です。 さらに、CSRは複数のNHRPベースのATM雲とインタコネクトするルータとして適切でしょう。
Two different kinds of ATM VCs are defined between adjacent CSRs or between CSR and ATM-attached hosts/routers.
ATM VCsの2つの異種が隣接しているCSRsの間、または、CSRとATMが付属しているホスト/ルータの間で定義されます。
1) Default-VC
1) デフォルト-VC
It is a general purpose VC used by any communications which select conventional hop-by-hop IP routed paths. All incoming cells received from this VC are assembled to IP datagrams and handled based on their IP headers. VCs set up in the Classical IP Model are classified into this category.
それはVCがどんなコミュニケーションIPが発送したどの選んだホップごとに従来経路でも使用した汎用です。 このVCから受け取られたすべての入って来るセルが、IPデータグラムに組み立てられて、彼らのIPヘッダーに基づいて扱われます。 Classical IP ModelでセットアップされたVCsはこのカテゴリに分類されます。
2) Dedicated-VC
2) 専用VC
It is used by specific communications (IP flows) which are specified by, for example, any combination of the destination IP address/port, the source IP address/port or IPv6 flow label. It can be concatenated with other Dedicated-VCs which accommodate the same IP flow as it, and can constitute an ATM Bypass-pipe for those IP flows.
例えば、目的地IPアドレス/港、ソースIPアドレス/港またはIPv6流れラベルのどんな組み合わせでも指定される特定のコミュニケーション(IPは流れる)によってそれは使用されます。 それは、それと同じIP流動に対応する他のDedicated-VCsと共に連結できて、それらのIP流れのためにATM Bypass-パイプを構成できます。
Katsube, et. al. Informational [Page 5] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[5ページ]のRFC2098東芝のルータ拡大
Ingress/egress nodes of the Bypass-pipe can be either CSRs or ATM- attached routers/hosts both of which speak a Bypass-pipe control protocol. (we call that "Bypass-capable nodes") On the other hand, intermediate nodes of the Bypass-pipe should be CSRs since they need to have cell switching capabilities as well as to speak the Bypass- pipe control protocol.
Bypass-パイプのイングレス/出口ノードは、ホストのそれのルータ/両方がBypass-パイプ制御プロトコルを話す添付のCSRsかATMのどちらかであるかもしれません。 (私たちは、それを「迂回できるノード」と呼びます) 他方では、彼らがセルスイッチング能力を持って、Bypassパイプ制御プロトコルを話す必要があるので、Bypass-パイプの中間的ノードはCSRsであるべきです。
The route for a Bypass-pipe follows IP routing information in each CSR. In figure 1, IP datagrams from a source host or router X.1 to a destination host or router Z.1 are transferred over the route X.1 -> CSR1 -> CSR2 -> Z.1 regardless of whether the communication is on a hop-by-hop basis or Bypass-pipe basis. Routes for individual Dedicated-VCs which constitutes the Bypass-pipe X.1 --> Z.1 (X.1 -> CSR1, CSR1 -> CSR2, CSR2 -> Z.1) would be determined based on ATM routing protocols such as PNNI [PNNI1.0], and would be independent of IP level routing.
Bypass-パイプのためのルートは各CSRのIPルーティング情報に従います。 送信元ホストからの1、IPデータグラムが中で計算するか、またはコミュニケーションがホップごとの基礎かBypass-パイプベースにあることにかかわらずルートX.1->CSR1->CSR2->Z.1の上にあて先ホストへのルータX.1かルータZ.1を移します。 Bypass-パイプX.1を構成する個々のDedicated-VCsのためのルート-->Z.1(X.1->CSR1、CSR1->CSR2、CSR2->Z.1)はPNNI[PNNI1.0]などのATMルーティング・プロトコルに基づいて断固としていて、IPの平らなルーティングから独立しているでしょう。
An example of IP datagram transmission mechanism is as follows.
IPデータグラム効果波及経路の例は以下の通りです。
o The host/router X.1 checks an identifier of each IP datagram,
which may be the "destination IP address (prefix)",
"source/destination IP address (prefix) pair", "destination IP
address and port", "source IP address and Flow label (in IPv6)",
and so on. Based on either of those identifiers, it determines
over which VC the datagram should be transmitted.
o ホスト/ルータX.1はそれぞれのIPデータグラムと、どれが「送付先IPアドレス(接頭語)」と、「ソース/目的地IPアドレス(接頭語)組」と、「送付先IPアドレスとポート」であるかもしれないか、そして、「ソースIPアドレスとFlowラベル(IPv6の)」に関する識別子などをチェックします。 それらの識別子のどちらかに基づいて、それは、データグラムがどのVCの上に送られるべきであるかを決定します。
o The CSR1/2 checks the VPI/VCI value of each incoming cell. When
the mapping from the incoming interface/VPI/VCI to outgoing
interface/VPI/VCI is found in an ATM routing table, it is directly
forwarded to the specified interface through an ATM switch module.
When the mapping in not found in the ATM routing table (or the
table shows an IP module as an output interface), the cell is
assembled to an IP datagram and then forwarded to an appropriate
outgoing interface/VPI/VCI based on an identifier of the datagram.
o CSR1/2はそれぞれの入って来るセルのVPI/VCI値をチェックします。 ATM経路指定テーブルで入って来るインタフェース/VPI/VCIから出発しているインタフェース/VPI/VCIまでのマッピングを見つけるとき、ATMスイッチモジュールで指定されたインタフェースに直接それを送ります。 中のマッピングがATMで経路指定テーブル(テーブルは出力インタフェースとしてIPモジュールを示している)を見つけなかったなら、セルをIPデータグラムに組み立てて、データグラムに関する識別子に基づく適切な出発しているインタフェース/VPI/VCIに送ります。
Katsube, et. al. Informational [Page 6] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[6ページ]のRFC2098東芝のルータ拡大
IP subnet X IP subnet Y IP subnet Z
<---------------------> <-----------------> <--------------------->
IPサブネットX IPサブネットY IPサブネットZ<。---------------------><。-----------------><。--------------------->。
+-------+ Default +-------+ Default +-------+ Default +-------+
| | -VC | CSR 1 | -VC | CSR 2 | -VC | |
| Host +=============+ +===============+ +=============+ Host |
| X.1 +-------------+++++---------------+++++-------------+ Z.1 |
| +-------------+++++---------------+++++-------------+ |
| +-------------+++++---------------+++++-------------+ |
| |Dedicated | | Dedicated | |Dedicated | |
+-------+ -VCs +-------+ -VCs +-------+ -VCs +-------+
<--------------------------------------------------->
Bypass-pipe
+-------+ デフォルト+-------+ デフォルト+-------+ デフォルト+-------+ | | -VC| CSR1| -VC| CSR2| -VC| | | ホスト+=============+ +===============+ +=============+ ホスト| | X.1+-------------+++++---------------+++++-------------+ Z.1| | +-------------+++++---------------+++++-------------+ | | +-------------+++++---------------+++++-------------+ | | |捧げられます。| | 捧げられます。| |捧げられます。| | +-------+ -VCs+-------+ -VCs+-------+ -VCs+-------+ <。--------------------------------------------------->迂回パイプ
Figure 1 Internetworking Architecture based on CSR
図1 CSRに基づくInternetworking Architecture
3.2 Features
3.2 特徴
The main feature of the CSR-based internetworking architecture is the same as that of the NHRP-based architecture in the sense that they both provide direct ATM level connectivity beyond IP subnet boundaries. There are, however, several notable differences in the CSR-based architecture compared with the NHRP-based one as follows.
CSRベースのインターネットワーキング構造の主な出し物はそれらの両方がIPサブネット境界を超えてダイレクトATM平らな接続性を提供するという意味におけるNHRPベースの構造のものと同じです。 しかしながら、NHRPベースのものは以下の通りで比べて、CSRベースの構造のいくつかの注目に値する違いがあります。
1) Relationship between IP routing and ATM routing
1) IPルーティングとATMルーティングとの関係
In the NHRP model, an egress point of the ATM network is first determined in the next hop resolution phase based on IP level routing information. Then the actual route for an ATM-VC to the obtained egress point is determined in the ATM connection setup phase based on ATM level routing information. Both kinds of routing information would be calculated according to factors such as network topology and available bandwidth for the large ATM cloud. The ATM routing will be based on PNNI phase1 [PNNI1.0] while the IP routing will be based on OSPF, BGP, IS-IS, etc. We need to manage two different routing protocols over the large ATM cloud until Integtrated-PNNI [IPNNI96] which takes both ATM level metric and IP level metric into account will be phased in in the future.
NHRPモデルでは、ATMネットワークの出口ポイントは最初に、IPの平らなルーティング情報に基づく次のホップ解決フェーズで決定しています。 その時、得られた出口ポイントへのATM-VCのための実際のルートはATMの平らなルーティング情報に基づくATM接続設定フェーズで決定しています。 ネットワーク形態や利用可能な帯域幅などの要素に従って、両方の種類のルーティング情報は大きいATM雲のために計算されるでしょう。 IPルーティングがOSPFに基づいている間、ATMルーティングはPNNI phase1[PNNI1.0]に基づくでしょう、BGP、-、など 私たちは、メートル法でATMが平らにする両方を取るIntegtrated-PNNI[IPNNI96]とアカウントへのメートル法のIPレベルが将来段階的に導入されるまで大きいATM雲の上で2つの異なったルーティング・プロトコルを管理する必要があります。
In the CSR model, IP level routing determines an egress point of the ATM cloud as well as determines inter-subnet level path to the point that shows which CSRs it should pass through. ATM level routing determines an intra-subnet level path for ATM-VCs (both Dedicated-VC and Default-VC) only between adjacent nodes (CSRs or ATM-attached hosts/routers). Since the roles of routing are hierarchically subdivided into inter-subnet level (router level) and intra-subnet level (ATM SW level), ATM routing does not have to operate all over
CSRモデルでは、IPの平らなルーティングは、ATM雲の出口ポイントを決定して、それがどのCSRsを通り抜けるべきであるかを示す肝心の相互サブネット平らな経路を決定します。 ATMの平らなルーティングは隣接しているノード(CSRsかATMが付属しているホスト/ルータ)だけの間のATM-VCs(Dedicated-VCとDefault-VCの両方)のためにイントラサブネットの平らな経路を決定します。 ルーティングの役割が階層的で相互サブネットレベル(ルータレベル)とイントラサブネットレベル(ATM SWレベル)に細分されるので、ATMルーティングはくまなく作動する必要はありません。
Katsube, et. al. Informational [Page 7] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[7ページ]のRFC2098東芝のルータ拡大
the ATM cloud but only in individual IP subnets independent from each other. This will decrease the amount of information for ATM routing protocol handling. But an end-to-end ATM path may not be optimal compared with the NHRP model since the path should go through routers at subnet boundaries in the CSR model.
しかし、ATMは互いから独立している個々のIPサブネットだけで曇ります。 これはATMルーティング・プロトコル取り扱いのために情報量を減少させるでしょう。 しかし、経路がCSRモデルにおけるサブネット境界でルータに直面するべきであるので、終わりから端へのATM経路はNHRPモデルと比べて最適でないかもしれません。
2) Dynamic routing and redundancy support
2) ダイナミックルーティングと冗長サポート
A CSR-based network can dynamically change routes for Bypass-pipes when related IP level routing information changes. Bypass-pipes related to the routing changes do not have to be torn down nor established from scratch since intermediate CSRs related to IP routing changes can follow them and change routes for related Bypass-pipes by themselves.
関連するIP平らなルーティング情報が変化するとき、CSRを拠点とするネットワークはBypass-パイプのためにダイナミックにルートを変えることができます。 IPルーティング変化に関連する中間的CSRsが関連するBypass-パイプのために自分たちでそれらに続いて、ルートを変えることができるので、ルーティング変化に関連する迂回パイプは、取りこわされて、最初から、設立される必要はありません。
The same things apply when some error or outage happens in any ATM nodes/links/routers on the route of a Bypass-pipe. CSRs that have noticed such errors or outages would change routes for related Bypass-pipes by themselves.
何らかの誤りか供給停止がBypass-パイプのルートの上のどんなATMノード/リンク/ルータでも起こると、同じものは適用されます。 そのような誤りか供給停止に気付いたCSRsは関連するBypass-パイプのために自分たちでルートを変えるでしょう。
3) Interoperability with IP level resource reservation protocols in multicast environments
3) マルチキャスト環境におけるIPの平らな資源予約プロトコルがある相互運用性
As current NHRP specification assumes application of NHRP to unicast environments only, multicast IP flows should still be carried based on a hop-by-hop manner with multicast routers. In addition, realization of IP level resource reservation protocols such as RSVP over NHRP environments requires further investigation.
現在のNHRP仕様がユニキャスト環境だけにNHRPのアプリケーションを仮定するとき、マルチキャストIP流れはホップごとのマルチキャストルータがある方法に基づいてまだ運ばれているべきです。 さらに、NHRP環境の上のRSVPなどのIPの平らな資源予約プロトコルの実現はさらなる調査を必要とします。
The CSR-based internetworking architecture which keeps subnet-by- subnet internetworking with regard to any control protocol sequence can provide multicast Bypass-pipes without requiring any modifications in IP multicast over ATM [IPMC96] or multicast routing techniques. In addition, since the CSR can handle RSVP messages which are transmitted in a hop-by-hop manner, it can provide Bypass- pipes which satisfy QoS requirements by the cooperation of the RSVP and the Bypass-pipe control protocol.
変更を必要としないで、どんな制御プロトコル系列に関しても近くサブネットサブネットがインターネットワーキングであることを保つCSRベースのインターネットワーキング構造はATM[IPMC96]かマルチキャストルーティングのテクニックの上でマルチキャストBypass-パイプをIPマルチキャストに提供できます。 さらに、CSRがホップごとの方法で送られるRSVPメッセージを扱うことができるので、それはRSVPの協力とBypass-パイプ制御プロトコルでQoS要件を満たすBypassパイプを提供できます。
4. Control Architecture for CSR
4. CSRのための規制構造
Several issues with regard to a control architecture for the CSR are discussed in this section.
このセクションでCSRのための規制構造に関するいくつかの問題について議論します。
4.1 Network Reference Model
4.1 ネットワーク規範モデル
In order to help understanding discussions in this section, the following network reference model is assumed. Source hosts S1, S2, and destination hosts D1, D2 are attached to Ethernets, while S3 and
このセクションで議論を理解しているのを助けるために、以下のネットワーク規範モデルは思われます。 そして送信元ホストのS1、S2、およびあて先ホストD1、D2がS3である間、Ethernetsに取り付けられる。
Katsube, et. al. Informational [Page 8] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[8ページ]のRFC2098東芝のルータ拡大
D3 are attached to the ATM. Routers R1 and R5 are attached to Ethernets only, while R2, R3 and R4 are attached to the ATM. The ATM datalink for subnet #3 and subnet #4 can either be physically separated datalinks or be the same datalink. In other words, R3 can be either one-port or multi-port router.
D3はATMに取り付けられます。 ルータのR1とR5はEthernetsだけに取り付けられますが、R2、R3、およびR4はATMに取り付けられます。 サブネット#3とサブネット#4のためのATMデータリンクは、物理的に切り離されたデータリンクであるか同じデータリンクであるかもしれません。 言い換えれば、R3は1ポートかマルチポートルータのどちらかであるかもしれません。
Ether Ether ATM ATM Ether Ether
| | +-----+ +-----+ | |
| | | | | | | |
S1--| S2---| S3---| | | |---D3 |---D2 |--D1
| | | | | | | |
|---R1---|---R2---| |--R3--| |---R4---|---R5---|
| | | | | | | |
| | +-----+ +-----+ | |
subnet subnet subnet subnet subnet subnet
#1 #2 #3 #4 #5 #6
エーテルエーテル気圧気圧エーテルエーテル| | +-----+ +-----+ | | | | | | | | | | S1--| S2---| S3---| | | |---D3|---D2|--D1| | | | | | | | |---R1---|---R2---| |--R3--| |---R4---|---R5---| | | | | | | | | | | +-----+ +-----+ | | サブネットサブネットサブネットサブネットサブネットサブネット#1#2#3#4#5#6
Figure 2 Network Reference Model
図2 ネットワーク規範モデル
Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4]. That means that S3, D3, R2, R3 and R4 need to speak Bypass-pipe control protocol, and means that R3 needs to be the CSR. We use term "Bypass-capable nodes" for hosts/routers which can speak Bypass-pipe control protocol but are not necessarily CSRs.
迂回パイプは構成された[S3かR2](>R3)>であるかもしれません[D3かR4]。 それは、S3、D3、R2、R3、およびR4が、Bypass-パイプ制御プロトコルを話す必要を意味して、R3が、CSRである必要を意味します。 私たちはBypass-パイプ制御プロトコルを話すことができますが、必ずCSRsであるというわけではないホスト/ルータに「迂回できるノード」という用語を使用します。
As shown in this reference model, Bypass-pipe can be configured from host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host to router (S3-->R3-->R4), and router to router (R2-->R3-->R4).
この規範モデルで示されるように、(S3-->R3-->D3)、接待するルータ(R2-->R3-->D3)、ルータへのホスト(S3-->R3-->R4)、およびルータへのルータ(R2-->R3-->R4)を接待するためにホストからBypass-パイプを構成できます。
4.2 Possible Use of Bypass-pipe
4.2 迂回パイプの活用可能性
Possible use (or purposes) of Bypass-pipe provided by CSRs, in other words, possible triggers that initiate Bypass-pipe setup procedure, is discussed in this subsection.
この小区分でCSRsによって提供されたBypass-パイプの活用可能性(または、目的)(言い換えれば、Bypass-パイプセットアップ手順に着手する可能な引き金)について議論します。
Following two purposes for Bypass-pipe setup are assumed at present;
Bypass-パイプセットアップのための次の2つの目的が現在のところ、想定されます。
a) Provision of low latency path
a) 低遅延経路の支給
This indicates cases in which end hosts or routers initiate a Bypass-pipe setup procedure when they will transmit large amount of datagrams toward a specific destination. For instance,
これは彼らが多量のデータグラムを特定の目的地に向かって送るとき終わりのホストかルータがBypass-パイプセットアップ手順に着手する場合を示します。 例えば
- End hosts or routers initiate Bypass-pipe setup procedures based
on the measurement of IP datagrams transmitted toward a certain
destination.
- 終わりのホストかルータが、ある目的地に向かって送られたIPデータグラムの測定に基づくBypass-パイプセットアップ手順に着手します。
Katsube, et. al. Informational [Page 9] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[9ページ]のRFC2098東芝のルータ拡大
- End hosts or routers initiate Bypass-pipe setup procedures when
it detects datagrams with certain higher layer protocols such as
ftp, nntp, http, etc.
- ftp、nntp、httpなどのあるより高い層のプロトコルがあるデータグラムを検出するとき、終わりのホストかルータがBypass-パイプセットアップ手順に着手します。
Other triggers may be possible depending on the policy in each network. In any case, the purpose of Bypass-pipe setup in each of these cases is to reduce IP processing burden at intermediate routers as well as to provide a communication path with low latency for burst data transfer, rather than to provide end host applications with specific bandwidth/QoS.
各ネットワークで方針によって、他の引き金は可能であるかもしれません。 どのような場合でも、それぞれのこれらの場合におけるBypass-パイプセットアップの目的は、中間的ルータにおけるIP処理負担を減少させて、特定の帯域幅/QoSをエンドホストアプリケーションに提供するというよりむしろ炸裂データ転送のために低遅延を通信路に提供することです。
There would be no rule for determining bandwidth for such kinds of Bypass-pipes since no explicit information about bandwidth/QoS requirement by end hosts is available without IP-level resource reservation protocols such as RSVP. Using UBR VCs as components of the Bypass-pipe would be the easiest choice although there is no guarantees for cell loss quality, while using other services such as CBR/VBR/ABR with an adequate parameter tuning would be possible.
終わりのホストによる帯域幅/QoS要件に関するどんな明示的な情報もRSVPなどのIP-レベル資源予約プロトコルなしで利用可能でないのでそのような種類のBypass-パイプのために帯域幅を決定するための規則が全くないでしょう。 細胞消失品質のための保証が全くありませんが、Bypass-パイプの部品としてUBR VCsを使用するのは、最も簡単な選択でしょう、適切なパラメタ調律によるCBR/VBR/ABRなどの他のサービスを利用するのが可能でしょうが。
b) Provision of specific bandwidth/QoS requested by hosts
b) ホストによって要求された特定の帯域幅/QoSの設備
This indicates cases in which routers or end hosts initiate a Bypass-pipe setup procedure by triggers related to IP-level bandwidth/QoS request from end hosts. The "resource management entity" in the host or router, which has received bandwidth/QoS requests from applications or adjacent nodes may choose to accommodate the requested IP flow to an existing VC or choose to allocate a new Dedicated-VC for the requested IP flow. Selecting the latter choice at each router can correspond to the trigger for constituting a Bypass-pipe. When both an incoming VC and an outgoing VC (or VCs) are dedicated to the same IP flow(s), those VCs can be concatenated at the CSR (ATM cut-through) to constitute a Bypass- pipe. Bandwidth for the Bypass-pipe (namely, individual VCs constituting the Bypass-pipe) in this case would be determined based on the bandwidth/QoS requirements by the end host which is conveyed by, e.g., RSVP messages. The ATM service classes; e.g., CBR/VBR/ABR; that would be selected depends on the IP-level service classes requested by the end hosts.
これは、ルータか終わりのホストがIP-レベル帯域幅/QoSに関連する引き金でBypass-パイプセットアップ手順に着手する場合が終わりからホストを要求するのを示します。 ホストかルータにおける「リソース経営体」は、既存のVCへの要求されたIP流動に対応するか、または要求されたIP流動のために新しいDedicated-VCを割り当てるのを選ぶのを選ぶかもしれません。(ルータはアプリケーションか隣接しているノードから帯域幅/QoS要求を受け取りました)。 各ルータで後者の選択を選択するのはBypass-パイプを構成するための引き金に対応できます。 入って来るVCと出発しているVCの両方(または、VCs)が同じIP流動に捧げられるとき、Bypassパイプを構成するためにCSR(深く切られたATM)でそれらのVCsを連結できます。 この場合、Bypass-パイプ(すなわち、Bypass-パイプを構成する個々のVCs)のための帯域幅は終わりまでに要件が運ばれるものを接待する帯域幅/QoSに基づいて断固としているでしょう、例えば、RSVPメッセージ。 ATMサービスは属します。 例えば、CBR/VBR/ABR。 それは選択されるでしょう。終わりのホストによって要求されたIP-レベルサービスのクラスに依存します。
Bypass-pipe provision for the purpose of b) will surely be beneficial in the near future when related IP-level resource reservation protocol will become available as well as when definitions of individual service classes and flow specs offered to applications become clear. On the other hand, Bypass-pipe setup for the purpose of a) may be beneficial right now since it does not require availability of IP-level resource reservation protocols. In that sense, a) can be regarded as a kind of short-term use while b) is a long-term use.
b)の目的への迂回パイプ支給は関連するIP-レベル資源予約プロトコルが利用可能になって、個々のサービスのクラスとアプリケーションに提供された流れ仕様の定義が明確になる近い将来、確実に有益になるでしょう。 他方では、IP-レベル資源予約プロトコルの有用性を必要としないので、a)の目的のためのBypass-パイプセットアップはたった今、有益であるかもしれません。 その意味で、b)が長期の使用である間、a)を一種の短期的な使用と見なすことができます。
Katsube, et. al. Informational [Page 10] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[10ページ]のRFC2098東芝のルータ拡大
4.3 Variations of Bypass-pipe Control Architecture
迂回パイプの4.3回の変化が構造を制御します。
A number of variations regarding Bypass-pipe control architecture are introduced. Items which are related to architectural variations are;
Bypass-パイプ規制構造に関する多くの変化を導入します。 建築変化に関連する項目はそうです。
o Ways of providing Dedicated-VCs
o 専用VCsを提供する方法
o Channels for Bypass-pipe control message transfer
o Bypass-パイプコントロールメッセージ転送のためのチャンネル
o Bypass-pipe control procedures
o 迂回パイプコントロール手順
Each of these items are discussed below.
以下でそれぞれのこれらの項目について議論します。
4.3.1 Ways of Providing Dedicated-VCs
4.3.1 専用VCsを提供する方法
There are roughly three alternatives regarding the way of providing Dedicated-VCs in individual IP subnets as components of a Bypass- pipe.
Bypassの部品が運ばれながら個々のIPサブネットにDedicated-VCsを提供する方法に関するおよそ3つの選択肢があります。
a) On-demand SVC setup
a) 要求次第のSVCセットアップ
Dedicated-VCs are set up in individual IP subnets each time you want to set up a Bypass-pipe through the ATM signaling procedure.
あなたがATMシグナリング手順でBypass-パイプをセットアップしたがっているたびに専用VCsは個々のIPサブネットでセットアップされます。
b) Picking up one from a bunch of (semi-)PVCs
b) aからの1つを拾うのが束になる、(準、)、PVCs
Several VCs are set up beforehand between CSR and CSR, or CSR and other ATM-attached nodes (hosts/router) in each IP subnet. Unused VC is picked up as a Dedicated-VC from these PVCs in each IP subnet when a Bypass-pipe is set up.
数個のVCsがあらかじめ、CSRとCSRか、CSRと他のATMが添付のノード(ホスト/ルータ)の間でそれぞれのIPサブネットでセットアップされます。 Bypass-パイプがセットアップされるとき、未使用のVCはDedicated-VCとしてこれらのPVCsからそれぞれのIPサブネットで拾われます。
c) Picking up one VCI in PVP/SVP
c) PVP/SVPのピックアップ1VCI
PVPs or SVPs are set up between CSR and CSR, or CSR and other ATM- attached nodes (hosts/routers) in each IP subnet. PVPs would be set up as a router/host initialization procedure, while SVPs, on the other hand, would be set up through ATM signaling when the first VC (either Default- or Dedicated-) setup request is initiated by either of some peer nodes. Then, Unused VCI value is picked up as a Dedicated-VC in the PVP/SVP in each IP subnet when a Bypass-pipe is set up. The SVP can be released through ATM signaling when no VCI value is in active state.
PVPsかSVPsがCSRとCSRの間でセットアップされたか、またはCSRと他のATMはそれぞれのIPサブネットでノード(ホスト/ルータ)を添付しました。 PVPsはルータ/ホスト初期化手順として上がっているセットです、最初のVC(DefaultかDedicatedのどちらか)セットアップ要求がいくつかの同輩ノードのどちらかによって開始されるとき、SVPsが他方ではATMシグナリングを通してセットアップされるでしょうが。 そして、Bypass-パイプがセットアップされるとき、Unused VCI値はDedicated-VCとしてPVP/SVPでそれぞれのIPサブネットで拾われます。 VCI値が全く活動的な状態にないとき、ATMシグナリングを通してSVPをリリースできます。
The best choice will be a) with regard to efficient network resource usage. However, you may go through three steps, ATMARP (for unicast [RFC1577] or multicast [IPMC96] in each IP subnet), SVC setup (in each IP subnet) and exchange of Bypass-pipe control message in this case. Whether a) is practical choice or not will depend on whether
最も良い選択は効率的なネットワーク資源用法に関するa)になるでしょう。 しかしながら、あなたはこの場合Bypass-パイプコントロールメッセージの3ステップ、ATMARP(ユニキャスト[RFC1577]かそれぞれのIPサブネットにおけるマルチキャスト[IPMC96]のための)、SVCセットアップ(それぞれのIPサブネットにおける)、および交換に直面できます。 どんなa)が実用的な選択であるかどうかも意志もよりません。
Katsube, et. al. Informational [Page 11] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[11ページ]のRFC2098東芝のルータ拡大
you can allow larger Bypass-pipe setup time due to three-step procedure mentioned above, or whether you can send datagrams over Default-VCs in a hop-by-hop manner while waiting for the Bypass-pipe set up.
前記のように、またはセットアップされたBypass-パイプを待っている間、ホップごとの方法でDefault-VCsの上にデータグラムを送ることができることにかかわらずあなたは3ステップの手順のためより大きいBypass-パイプ準備時間を許すことができます。
In the case of b) or c), the issue of Bypass-pipe setup time will be improved since SVC setup step can be skipped. In b), each node (CSR or ATM-attached host/router) should specify some traffic descriptors even for unused VCs, and the ATM datalink should reserve its desired resource (such as VCI value and bandwidth) for them. In addition, the ATM datalink may have to carry out UPC functions for those unused VCs. Such burden would be reduced when you use UBR-PVCs and set peak cell rate for each of them equal to link rate, but bandwidth/QoS for the Bypass-pipe is not provided in this case. In c), on the other hand, traffic descriptors which should be specified by each node for the ATM datalink is not each VC's but VP's only. Resource reservations for individual VCs will be carried out not as a functionality of the ATM datalink but of each CSR or ATM-attached host/router if necessary. A functionality which need to be provided by the ATM datalink is control of VPs' bandwidth only such as UPC and dynamic bandwidth negotiation if it would be widely available.
b)かc)の場合では、Bypass-パイプ準備時間の問題は、SVCセットアップステップをサボることができるので、改良されるでしょう。 b)では、各ノード(CSRかATMが付属しているホスト/ルータ)は未使用のVCsさえのためのいくつかの交通記述子を指定するはずです、そして、ATMデータリンクは彼らのための必要なリソース(VCI値や帯域幅などの)を予約するべきです。 さらに、ATMデータリンクはそれらの未使用のVCsのためにUPC機能を行わなければならないかもしれません。 あなたがUBR-PVCsを使用して、レートをリンクするために等しい状態でそれぞれの彼らのピークセルレートを設定するとき、そのような負担は減少するでしょうが、Bypass-パイプのための帯域幅/QoSはこの場合提供されません。 他方では、ATMデータリンクのための各ノードによって指定されるべきである交通記述子はc)ではVCの各ものではありませんが、VPは唯一です。 必要なら、個々のVCsの資源予約がATMデータリンクの機能性について行われるのではなく、それぞれのCSRかATMが付属しているホスト/ルータについて行われるでしょう。 それが広く利用可能であるならそれのATMデータリンクによって提供されるべき必要性がUPCやダイナミックな帯域幅交渉だけなどのVPsの帯域幅のコントロールである機能性。
4.3.2 Channels for Bypass-pipe Control Message Transfer
4.3.2 迂回パイプコントロールメッセージ転送のためのチャンネル
There are several alternatives regarding the channels for managing (setting up, releasing, and possibly changing the route of) a Bypass-pipe. This subsection explains these alternatives and discusses their properties.
管理するためのチャンネルに関するいくつかの選択肢がある、(セットアップして、リリースして、ことによるとルートを変える、)、Bypass-パイプ。 この小区分は、これらの代替手段を説明して、彼らの特性について議論します。
Three alternatives are discussed, Inband control message, Outband control message, and use of ATM signaling.
3つの選択肢について議論して、Inbandはメッセージ、Outbandコントロールメッセージ、およびATMシグナリングの使用を制御します。
i) Inband Control Message
i) Inbandコントロールメッセージ
When setting up a Bypass-pipe, control messages are transmitted over a Dedicated-VC which will eventually be used as a component of the Bypass-pipe. These messages are handled at each CSR, and similar messages are transmitted to the next-hop node over a Dedicated-VC along the selected route (based on IP routing table). Unlike outband message protocol described in ii), each message does not have to indicate a Dedicated-VC which will be used since the message itself is carried over "that" VC.
Bypass-パイプをセットアップするとき、コントロールメッセージは結局Bypass-パイプの部品として使用されるDedicated-VCの上に送られます。 これらのメッセージは各CSRで扱われます、そして、同様のメッセージは選択されたルート(IP経路指定テーブルに基づいている)に沿ったDedicated-VCの上の次のホップノードに送られます。 ii)で説明された「外-バンド」メッセージプロトコルと異なって、各メッセージはメッセージ自体が「それ」VCに伝えられるので使用されるDedicated-VCを示す必要はありません。
The inband control message can be either "datagram dedicated for Bypass-pipe control" or "actual IP datagram" sent by user application. Actual IP datagrams can be transmitted over Bypass-pipe after it has been set up in the former case. In the latter case, on the other hand, the first (or several) IP datagram(s) received from
「不-バンド」コントロールメッセージは、「Bypass-パイプ制御装置のために捧げられたデータグラム」かユーザアプリケーションで送られた「実際のIPデータグラム」のどちらかであることができます。 それが前の場合でセットアップされた後に実際のIPデータグラムにBypass運んだ状態で伝えることができます。 他方では、後者では、(s)が受信した最初(または、数個)のIPデータグラムをケースに入れてください。
Katsube, et. al. Informational [Page 12] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[12ページ]のRFC2098東芝のルータ拡大
an unused Dedicated-VC are analyzed at IP level and transmitted toward adequate next hop over an unused Dedicated-VC. Then incoming Dedicated-VC and outgoing Dedicated-VC are concatenated to construct a Bypass-pipe.
未使用のDedicated-VCは未使用のDedicated-VCの上でIPレベルで分析されて、次の適切なホップに向かって伝えられます。 そして、入って来るDedicated-VCと出発しているDedicated-VCは、Bypass-パイプを組み立てるために連結されます。
In inband control, Bypass-pipe control messages transmitted after a Bypass-pipe has been set up cannot be identified at intermediate CSRs since those messages are forwarded at cell level there. As a possible solution for this issue, intermediate CSRs can identify Bypass-pipe control messages by marking cell headers, e.g., PTI bit which indicates F5 OAM cell. With regard to Bypass-pipe release, explicit release message may not be necessary if individual CSRs administer the amount of traffic over each Dedicated-VC and deletes concatenation information for an inactive Bypass-pipe with their own decision.
「不-バンド」コントロールでは、セルレベルでそれらのメッセージをそこに転送するので、中間的CSRsでBypass-パイプがセットアップされた後に送られたBypass-パイプコントロールメッセージは特定できません。 この問題の可能な解決として、中間的CSRsは、セルヘッダー(例えば、F5 OAMセルを示すPTIビット)をマークすることによって、Bypass-パイプコントロールメッセージを特定できます。 Bypass-パイプリリースに関して、個々のCSRsが各Dedicated-VCの上で交通の量を管理して、それら自身の決定で不活発なBypass-パイプのための連結情報を削除するなら、明白なリリースメッセージは必要でないかもしれません。
ii) Outband Control Message
ii) Outbandコントロールメッセージ
When a Bypass-pipe is set up or released, control messages are transmitted over VCs which are different from Dedicated-VCs used as components of the Bypass-pipe. Unlike inband message protocol described in i), each message has to indicate which Dedicated-VCs the message would like to control. Therefore, an identifier that uniquely discriminates a VC, which is not a VPI/VCI that is not identical at both endpoints of the VC, need to be defined and be given at VC initiation phase. However, an issue of control message transmission after a Bypass-pipe has been set up in inband case does not exist.
Bypass-パイプがセットアップされるか、または放出されるとき、コントロールメッセージはBypass-パイプの部品として使用されるDedicated-VCsと異なったVCsの上に送られます。 i)で説明された「不-バンド」メッセージプロトコルと異なって、各メッセージは、メッセージがどのDedicated-VCsを制御したいかを示さなければなりません。 したがって、唯一VCを差別して、VC(定義された、VC起因過程で与えられるべき必要性)の両方の終点で同じでないVPI/VCIでない識別子。 しかしながら、Bypass-パイプが「不-バンド」場合でセットアップされた後にコントロールメッセージ送信の問題は存在していません。
Four alternatives are possible regarding how to convey Bypass-pipe control messages hop-by-hop over ATM datalink networks.
4つの選択肢がどうATMデータリンクネットワークの上のホップごとのBypass-パイプコントロールメッセージを伝えるかに関して可能です。
1) Defines VC for Bypass-pipe control messages only.
1) Bypass-パイプコントロールメッセージだけのためにVCを定義します。
2) Uses Default-VC and discriminates Bypass-pipe control messages
from user datagrams by an LLC/SANP value in RFC1483 encapsulation.
2) Default-VCを使用して、RFC1483カプセル化におけるLLC/SANP値でユーザデータグラムとBypass-パイプコントロールメッセージを区別します。
3) Uses Default-VC and discriminates Bypass-pipe control messages
from user datagrams by a protocol field value in IP header.
3) Default-VCを使用して、IPヘッダーでプロトコル分野価値でユーザデータグラムとBypass-パイプコントロールメッセージを区別します。
4) Uses Default-VC and discriminates Bypass-pipe control messages
from user datagrams by a port ID in the UDP frame.
4) Default-VCを使用して、UDPフレームのポートIDはユーザデータグラムとBypass-パイプコントロールメッセージを区別します。
When we take into account interoperability with Bypass-incapable routers, 1) will not be a good choice. Whether we select 2) or 3) 4) depends on whether we should consider multiprotocol rather than IP only.
私たちがBypass不可能なルータでアカウント相互運用性を連れていくとき、1は)良い選択でないでしょう。 私たちが2か)3を)選択して 4) 私たちがIPだけよりむしろ「マルチ-プロトコル」を考えるべきであるかどうかによります。
Katsube, et. al. Informational [Page 13] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[13ページ]のRFC2098東芝のルータ拡大
In the case of IP multicast, point-to-multipoint VCs in individual subnets are concatenated at CSRs consecutively in order to constitute end-to-end multicast tree. Above four alternatives may require the same number of point-to-multipoint Defalut-VCs as the number of requested point-to-multipoint Dedicated-VCs in multicast case. The fifth alternative which can reduce the necessary number of VCs to convey control messages in a multicast environment is;
IPマルチキャストの場合では、個々のサブネットにおけるポイントツーマルチポイントVCsは、終わりから終わりへのマルチキャスト木を構成するためにCSRsで連続して連結されます。 4つの選択肢を超えて、マルチキャスト場合における、要求されたポイントツーマルチポイントDedicated-VCsの数としてのポイントツーマルチポイントDefalut-VCsの同じ数を必要とするかもしれません。 マルチキャスト環境におけるコントロールメッセージを伝えるためにVCsの必要な数を減少させることができる5番目の代替手段はそうです。
5) Defines point-to-multipoint VC whose leaves are members of
multicast group 224.0.0.1. All nodes which are members of at
least one of active multicast group would become leaves of this
point-to-multipoint VC.
5) 葉がマルチキャストグループ224.0.0.1歳のメンバーであるポイントツーマルチポイントVCを定義します。 少なくとも1歳のメンバーである活動的なマルチキャストグループのすべてのノードがこのポイントツーマルチポイントVCの葉になるでしょう。
Each upstream node may become a root of the point-to-multipoint VC, or a sort of multicast server to which each upstream node transmits cells over a point-to-point VC may become a root of that. In any case, Bypass-pipe control messages for every multicast group are transmitted to all nodes which are members of either of the group. When a downstream node has received control messages which are not related to a multicast group it belongs, it should discard them by referring to a destination group address on their IP header. Donwstream node would still need to use point-to-point VC to send control messages toward upstream.
それぞれの上流のノードがポイントツーマルチポイントVCの根になるかもしれませんか、またはそれぞれの上流のノードが二地点間VCの上のセルを伝える一種のマルチキャストサーバがその根になるかもしれません。 どのような場合でも、あらゆるマルチキャストグループへのBypass-パイプコントロールメッセージはグループのどちらかのメンバーであるすべてのノードに送られます。 川下のノードがマルチキャストグループに関連しないコントロールメッセージを受け取ったとき、属して、彼らのIPヘッダーに関する送付先グループアドレスを参照することによって、それらを捨てるべきです。 Donwstreamノードは、まだコントロールメッセージを上流に向かって送るのにポイントツーポイントVCを使用する必要があるでしょう。
iii) Use of ATM Signaling Message
iii) 気圧シグナリングメッセージの使用
Supposing that ATM signaling messages can convey IP addresses (and possibly port IDs) of source and destination, it may be possible that ATM signaling messages be used as Bypass-pipe control messages also. In that case, an ATM connection setup message indicates a setup of a Dedicated-VC to an ATM address of a desirable next-hop IP node, and also indicates a setup of a Bypass-pipe to an IP address (and possibly port ID) of a target destination node. Information elements for the Dedicated-VC setup (ATM address of a next-hop node, bandwidth, QoS, etc.) are handled at ATM nodes, while information elements for the Bypass-pipe setup (source and destination IP addresses, possibly their port IDs, or flow label for IPv6, etc.) are transparently transferred to the next-hop IP node. The next-hop IP node accepts Dedicated-VC setup and handles such IP level information elements.
ATMシグナリングメッセージがソースと目的地のIPアドレス(ことによるとIDを移植する)を伝えることができると思って、ATMシグナリングメッセージがBypass-パイプコントロールメッセージとしても使用されるのは、可能であるかもしれません。 その場合、ATM接続設定メッセージは、望ましい次のホップIPノードのATMアドレスにDedicated-VCのセットアップを示して、また、目標目的地ノードのIPアドレス(ことによるとIDを移植する)にBypass-パイプのセットアップを示します。 Dedicated-VCセットアップ(次のホップノード、帯域幅、QoSなどのATMアドレス)のための情報要素はATMノードで扱われます、透明にBypass-パイプセットアップ(IPv6などのためのソースと送付先IPアドレスか、ことによるとそれらのポートIDか、流れラベル)のための情報要素を次のホップIPノードに移しますが。 次のホップIPノードはDedicated-VCセットアップを受け入れます、そして、そのようなハンドルIPは情報要素を平らにします。
ATM signaling messages can be transferred from receiver to sender as well as sender to receiver when you set zero Forward Cell Rate and non-zero Backward Cell Rate as an ATM traffic descriptor information element in unicast case, or when Leaf Initiated Join capabilities will become available in multicast case.
ユニキャスト場合におけるATM交通記述子情報要素かそれともLeaf Initiated Join能力がいつマルチキャスト場合で利用可能になるかとしてあなたがForward Cell Rateと非ゼロBackward Cell Rateを全く設定しないとき、受信機から送付者と送付者から受信機までATMシグナリングメッセージを移すことができます。
Katsube, et. al. Informational [Page 14] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[14ページ]のRFC2098東芝のルータ拡大
Issues in this method are,
この方法による問題はそうです。
- Information elements which specify IP level (and port level)
information need to be defined, e.g., B-HLI or B-UUI, as an ATM
signaling specification.
- IPを指定する情報要素がATMシグナリング仕様としての定義されるべき情報の必要性、例えば、B-HLIまたはB-UUIを平らにします(レベルを移植してください)。
- It would be difficult to support soft-state Bypass-pipe control
which transmits control messages periodically since ATM signaling
is a hard-state protocol.
- ATMシグナリングが固い州のプロトコルであるので定期的にコントロールメッセージを送る軟性国家Bypass-パイプ制御装置を支持するのは難しいでしょう。
4.3.3 Bypass-pipe Control Procedures
4.3.3 迂回パイプコントロール手順
This subsection discusses several items with regard to actual procedures for Bypass-pipe control.
この小区分はBypass-パイプ制御装置のための実際の手順に関して数個の項目について議論します。
a) Distributed trigger vs. Centralized (restricted) trigger
a) 分配された引き金対Centralized(制限される)引き金
The first item to be discussed is whether the functionality of detecting a trigger of Dedicated-VC/Bypass-pipe control is distributed to all the nodes (including CSRs and hosts/edge devices) or restricted to specific nodes.
議論されるべき最初の項目は迂回Dedicated-VC/パイプ制御装置の引き金を検出する機能性がすべてのノード(CSRsとホスト/エッジデバイスを含んでいる)に分配されるか、または特定のノードに制限されるということです。
In the case of the distributed trigger, every node is regarded as having a capability of detecting a trigger of Bypass-pipe setup or termination. For example, every node detects datagrams for ftp, and sets up (or fetches) a Dedicated-VC individually to construct a Bypass-pipe. After setting up or fetching the Dedicated-VCs, messages which informs (or requests) the transmission of the IP flow over the Dedicated-VC are exchanged between adjacent nodes. That enables peer nodes to share the same knowledge about the mapping relationship between the IP flow and the Dedicated-VC. There is no end-to-end message transmission in the Bypass-pipe control procedure itself, but transmission between adjacent nodes only.
分配された引き金の場合では、あらゆるノードがBypass-パイプセットアップか終了の引き金を検出する能力を持っていると見なされます。 例えば、あらゆるノードが、Bypass-パイプを組み立てるために個別にftpのためにデータグラムを検出して、Dedicated-VCをセットアップします(または、フェッチ)。 Dedicated-VCsをセットアップするか、またはとって来た後に、隣接しているノードの間でDedicated-VCの上のIP流動の送信を知らせる(または、要求)メッセージを交換します。 それは、同輩ノードがIP流動とDedicated-VCとのマッピング関係に関する同じ知識を共有するのを可能にします。 隣接しているノードだけの間には、Bypass-パイプコントロール手順自体における終わりから終わりへのメッセージ送信がない、しかし、トランスミッションがあります。
In the case of the centralized (or restricted) trigger, capability of detecting a trigger of Bypass-pipe setup or termination is restricted to nodes which are located at "the boundary of the CSR-cloud". The boundary of the CSR-cloud signifies, for individual IP flows, the node which is the first-hop or the last-hop CSR-capable node. For example, a node which detects datagrams for ftp can initiate Bypass- pipe setup procedure only when its previous hop is non-ATM or CSR- incapable. In this case, Bypass-pipe control messages are originated at the boundary of the CSR-cloud, and forwarded hop-by-hop toward another side of the boundary, which is similar to ATM signaling messages. The semantics of the messages may be the request of end- to-end Bypass-pipe setup as well as notification or request of mapping relationship between the IP flow and the Dedicated-VC.
集結された(または、制限される)引き金の場合では、Bypass-パイプセットアップか終了の引き金を検出する能力は「CSR-雲の境界」に位置しているノードに制限されます。 CSR-雲の境界は意味します、個々のIP流れ、最初に、ホップであるノードまたは最後のホップのCSRできるノードのために。 前のホップが非ATMか不可能なCSRであるときにだけ、例えば、ftpのためにデータグラムを検出するノードはBypassパイプセットアップ手順に着手できます。 この場合、Bypass-パイプコントロールメッセージをCSR-雲の境界で溯源して、ホップごとに境界の別の側に向かって転送します。側はATMシグナリングメッセージと同様です。 メッセージの意味論は、通知と同様に終わりの終わりまでのBypass-パイプセットアップの要求かIP流動とDedicated-VCとのマッピング関係の要求であるかもしれません。
Katsube, et. al. Informational [Page 15] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[15ページ]のRFC2098東芝のルータ拡大
b) Upstream-initiated control vs. Downstream-initiated control
b) 上流へ開始しているコントロール対Downstreamによって開始されたコントロール
The second item to be discussed is whether the setup of a Dedicated- VC and the control procedure for constructing a Bypass-pipe are initiated by upstream side or downstream side.
第2議論されるべき項目はBypass-パイプを組み立てるためのDedicated- VCのセットアップとコントロール手順に上流側で着手されるかどうかということであるか川下で面があってください。
In the case of the upstream-initiated control, the upstream node takes the initiative when setting up a Dedicated-VC for a specific IP flow and creating the mapping relationship between the IP flow and the Dedicated-VC. For example, a CSR which detects datagrams for ftp sets up (or fetches) a Dedicated-VC toward its downstream neighbor and notifies its downstream neighbor that it will transmit a specific IP flow over the Dedicated-VC. This means that the downstream node is requested to receive datagrams from the Dedicated-VC.
上流へ開始しているコントロールの場合では、特定のIP流動のためにDedicated-VCをセットアップして、IP流動とDedicated-VCとのマッピング関係を作成するとき、上流のノードはイニシアチブを取ります。 例えば、ftpのためにデータグラムを検出するCSRは、川下の隣人に向かってDedicated-VCをセットアップして(または、フェッチ)、特定のIP流動をDedicated-VCの上に伝えるように川下の隣人に通知します。 これは、川下のノードがDedicated-VCからデータグラムを受け取るよう要求されていることを意味します。
In the case of the downstream-initiated control, the downstream node takes the initiative when setting up a Dedicated-VC for a specific IP flow and creating the mapping relationship between the IP flow and the Dedicated-VC. For example, a CSR which detects datagrams for ftp sets up (or fetches) a Dedicated-VC toward its upstream neighbor and requests its upstream neighbor to transmit a specific IP flow over the Dedicated-VC. This means that the upstream node is requested to transmit the IP flow over the Dedicated-VC.
川下で開始しているコントロールの場合では、特定のIP流動のためにDedicated-VCをセットアップして、IP流動とDedicated-VCとのマッピング関係を作成するとき、川下のノードはイニシアチブを取ります。 例えば、ftpのためにデータグラムを検出するCSRは、上流の隣人に向かってDedicated-VCをセットアップして(または、フェッチ)、特定のIP流動をDedicated-VCの上に伝えるよう上流の隣人に要求します。 これは、上流のノードがIP流動をDedicated-VCの上に伝えるよう要求されていることを意味します。
c) Hard-state management vs. Soft-state management
c) 困難な国家管理対Soft-国家管理
The third item to be discussed is whether the control (setup, maintain, and release) of the Bypass-pipe is based on hard-state or soft-state.
第3議論されるべき項目はBypass-パイプのコントロール(セットアップして、維持して、リリースする)が固い状態か軟性国家に基づいているかどうかということです。
In hard-state management, individual nodes transmit Bypass-pipe control messages only when they want to notify or request any change in their neighbors' state. They should wait for an acknowledgement of the message before they change their internal state. For example, after setting up a Bypass-pipe, it is maintained until either of a peer nodes transmits a message to release the Bypass-pipe.
困難な国家管理では、彼らの隣人の状態のどんな変化も通知したいか、または要求したがっているときだけ、個々のノードはBypass-パイプコントロールメッセージを送ります。 自分達の内部の状態を変える前に彼らはメッセージの承認を待つべきです。 例えば、Bypass-パイプをセットアップした後に、同輩ノードのどちらかがBypass-パイプを放出するメッセージを送るまで、それは維持されます。
In soft-state management, individual nodes periodically transmit Bypass-pipe control messages in order to maintain their neighbors' state. They do not have to wait for an acknowledgement of the message before they changes its internal state. For example, even after setting up a Bypass-pipe, either of a peer nodes is required to periodically transmit refresh messages to its neighbor in order to maintain the Bypass-pipe.
軟性国家管理では、個々のノードは、彼らの隣人の状態を維持するためにBypass-パイプコントロールメッセージを定期的に送ります。 内部の状態を変える前に彼らはメッセージの承認を待つ必要はありません。 定期的に伝えるBypass-パイプ、同輩ノードのどちらかが必要であるセットアップするのがBypass-パイプを維持するために例えば隣人にメッセージをリフレッシュした後にさえ。
5. Security Considerations
5. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Katsube, et. al. Informational [Page 16] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[16ページ]のRFC2098東芝のルータ拡大
6. Summary
6. 概要
Basic concept of Cell Switch Router (CSR) are clarified and control architecture for CSR is discussed. A number of methods to control Bypass-pipe will be possible each of which has its own advantages and disadvantages. Further investigation and discussion will be necessary to design control protocol which may depend on the requirements by users.
Cell Switch Router(CSR)に関する基本概念ははっきりさせられます、そして、CSRのための規制構造について議論します。 どれにそれ自身の利点と損失があるかにBypass-パイプを制御する多くの方法がそれぞれ可能になるでしょう。 さらなる調査と議論は、ユーザで要件によるかもしれない制御プロトコルを設計するために必要になるでしょう。
7. References
7. 参照
[IPMC96] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[IPMC96] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification, v.3.1", Sept. 1994.
[ATM3.1] ATM-フォーラム、「ATM User-ネットワークInterface Specification、v.3.1"、1994年9月。」
[RSVP13] Braden, R., et al., "Resource ReSerVation Protocol (RSVP), Version 1 Functional Specification", Work in Progress.
[RSVP13]ブレーデン、R.、他、「資源予約プロトコル(RSVP)、バージョン1の機能的な仕様」、ProgressのWork。
[IPNNI96] R. Callon, et al., "Issues and Approaches for Integrated PNNI", The ATM Forum Contribution No. 96-0355, April 1996.
R.Callon(他)が「統合PNNIのために発行して、アプローチする」[IPNNI96]、ATM Forum Contribution No.96-0355、1996年4月。
[NHRP09] Luciani, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress.
[NHRP09] Luciani、J.、他、「次のNBMAは解決プロトコル(NHRP)を飛び越す」ProgressのWork。
[PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0", March 1996.
[PNNI1.0] 気圧フォーラム、「P-NNI、仕様バージョン1インチと、1996インチ年3月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[RFC1577] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, October 1993.
[RFC1577] Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、10月1993日
[RFC1819] Delgrossi, L, and L. Berger, "Internet STream Protocol Version 2 (STII) Protocol Specification Version ST2+", RFC 1819, August 1995.
[RFC1819] Delgrossi、L、およびL.バーガー、「インターネット流れのプロトコルバージョン2(STII)プロトコル仕様バージョンST2+」、RFC1819 1995年8月。
Katsube, et. al. Informational [Page 17] RFC 2098 Toshiba's Router Extension for ATM February 1997
et Katsube、アル。 気圧1997年2月のための情報[17ページ]のRFC2098東芝のルータ拡大
8. Authors' Addresses
8. 作者のアドレス
Yasuhiro Katsube R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : katsube@isl.rdc.toshiba.co.jp
Yasuhiro Katsube研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: katsube@isl.rdc.toshiba.co.jp
Ken-ichi Nagami R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : nagami@isl.rdc.toshiba.co.jp
健一Nagami研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: nagami@isl.rdc.toshiba.co.jp
Hiroshi Esaki R&D Center, Toshiba 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 EMail : hiroshi@isl.rdc.toshiba.co.jp
Hiroshi江崎研究開発センター、幸区、日本川崎210が電話をする東芝1Komukai東芝町: +81-44-549-2238 メールしてください: hiroshi@isl.rdc.toshiba.co.jp
Katsube, et. al. Informational [Page 18]
et Katsube、アル。 情報[18ページ]
一覧
スポンサーリンク
