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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Settings 設定

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

上に戻る