RFC1946 日本語訳
1946 Native ATM Support for ST2+. S. Jackowski. May 1996. (Format: TXT=50430 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Jackowski Request for Comments: 1946 NetManage Incorporated Category: Informational May 1996
Jackowskiがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1946年のNetManageの法人組織のカテゴリ: 情報の1996年5月
Native ATM Support for ST2+
ST2+のネイティブの気圧サポート
Status of This 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
要約
As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS).
ネットワークでつながれたリアルタイムでサービスの需要が増大するので、共用回線網が決定論的なデリバリ・サービスを提供する必要性もそうします。 そのような決定論的なデリバリ・サービスは、ソースアプリケーションとネットワークインフラの両方にはデータの配送を要求して、セットアップして、実施する能力があるのを要求します。 これらのサービスはService(QoS)の帯域幅の予約とQualityとまとめて、呼ばれます。
The IETF is currently working on an integrated services model to support realtime services on the Internet The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.)
IETFは、現在、IETFが共有されたワイヤの上のリアルタイムで交通の配送のためにまだATM、固有のQoS、および帯域幅配分メカニズムの統合に焦点を合わせていないインターネットでリアルタイムでサービスを支持するために統合サービスモデルに取り組んでいます。 (ATMハードウェアとインタフェースは、しかしながら、determiniticデータ配送、ホストの居住者のためのネットワークインフラにプロトコル・スタックを提供して、より多くの注意をアプリケーションの必要性に提供します。)
Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component.
IPにおけるATM(ipatm)ワーキンググループの上の進行中の現在のIETFの努力は、ATMのためにQoS問題を記述するためにintserv、rsvp、およびST2を当てにします。 そういうものとして、RFC1577とATM ForumのランEmulationはダイレクトQoSと帯域幅配分能力をネットワーク応用に提供しません。 予約スタイルQoSに関するマッピングをATM合図に提供しないで、ATMは共有されたメディア・インフラコンポーネントよりむしろ'ワイヤ'のままで残るでしょう。
This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments:
このメモはアプリケーションが直接以下の環境におけるATMサービスを呼び出すのを可能にする働く実現について説明します:
- ATM to internet,
- internet to ATM, and
- internet to internet across ATM.
- そして、インターネットへのATM--ATMへのインターネット、--ATMの向こう側のインターネットへのインターネット。
Jackowski Informational [Page 1] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[1ページ]のRFC1946のネイティブの気圧サポート
Table of Contents
目次
1.0 Introduction...............................................2 2.0 ST-2 and ST-2+.............................................5 3.0 Implementation Issues for Reservations over ATM............6 3.1 Addressing.................................................6 3.2 Changes to Bandwidth and QoS...............................6 3.3 Multicasting...............................................7 3.4 Receiver Initiated JOIN Requests to Multicast Groups.......8 3.5 Computation of QoS Parameters..............................8 3.6 Use of HELLOs..............................................9 4.0 Reservation Signalling with ATM............................9 4.1 Embedded Reservation Signalling within Q.2931.............10 4.2 In-Band Reservation Signalling............................11 4.3 Dedicated Virtual Circuits for Reservation Signalling.....12 4.4 Reservation Signalling via IP over ATM or LAN Emulation...13 4.5 Summary of Reservation Signalling Options.................14 5.0 Mapping Reservation QoS to ATM QoS........................15 5.1 CPCS-SDU Size Computation.................................16 5.2 PCR Computation...........................................17 5.3 Maximum End to End Transit Delay..........................17 5.4 Maximum Bit Error Rate....................................18 5.5 Accumulated Mean Delay....................................18 5.6 Accumulated Delay Variance (jitter).......................18 6.0 Data Stream Transmission..................................18 7.0 Implementation Considerations and Conclusions.............19 8.0 Security Considerations...................................20 9.0 References................................................20 10.0 Author's Address..........................................21
1.0序論…そして、2標準時2.0-2、-2第+………………………………………5 3.0 気圧での予約のための実現問題…6 3.1 記述します。6 3.2 帯域幅とQoSに変化します…6 3.3マルチキャスティング…3.4受信機が開始した7はマルチキャストグループに要求に参加します…8 QoSパラメタの3.5計算…8 3.6 HELLOsの使用…9 4.0 気圧との予約合図…9 4.1はQ.2931の中の予約合図を埋め込みました…10 4.2 バンドにおける予約合図…11 4.3は予約合図のために仮想のサーキットを捧げました…12 4.4 ATMかLAN Emulationの上のIPを通した予約Signalling…13 予約合図オプションの4.5概要…14 5.0 予約QoSを気圧QoSに写像します…15 5.1CPCS-SDUサイズ計算…16 5.2PCR計算…17 トランジット遅れを終わらせる5.3の最大の終わり…17 5.4の最大のビット誤り率…18 5.5は意地悪な遅れを蓄積しました…18 5.6は遅れ変化(ジター)を蓄積しました…18 6.0のデータがトランスミッションを流します…18 7.0の実現問題と結論…19 8.0 セキュリティ問題…20 9.0の参照箇所…20 10.0作者のアドレス…21
1.0 Introduction
1.0 序論
The ATM Forum and the IETF seem to approach ATM networking differently.
ATM ForumとIETFは、ATMネットワークに異なってアプローチするように思えます。
The ATM forum appeaars to believe that host systems require no protocols beyond OSI layer 2 to deal with ATM. They define a layer 2 API and Q.2931 signaling for all new applications.
ホストシステムがOSIを超えてプロトコルを全く必要としないと信じるATMフォーラムappeaarsは、ATMに対処するために2を層にします。 彼らはすべての新しいアプリケーションのために合図する2APIとQ.2931層を定義します。
LAN Emulation, a mechanism to make the ATM interface appear to be a LAN/internet, is intended to support 'legacy' network applications. LAN emulation does not provide applications any visibility of the ATM features, nor does it provide a mechanism to allow applications to request specific ATM services. With LAN Emulation, application traffic shares virtual circuits with no policing or guarantees of service. LAN Emulation simply extends LAN characteristics to ATM.
LAN Emulation(ATMインタフェースをLAN/インターネットであるように見えさせるメカニズム)が'遺産'ネットワーク応用を支持することを意図します。 LANエミュレーションはATMの特徴の少しの目に見えることもアプリケーションに提供しません、そして、それはアプリケーションが特定のATMサービスを要求するのを許容するためにメカニズムを提供しません。 LAN Emulationと、アプリケーション交通はサービスの取り締まりも保証なしで仮想のサーキットを共有します。 LAN Emulationは単にLANの特性をATMに与えます。
Jackowski Informational [Page 2] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[2ページ]のRFC1946のネイティブの気圧サポート
Thus far, the IETF, through RFC 1577[1] treats an ATM network as a wire. The ipatm working group has explicitly left issues of specific QoS handling out of their specifications and working documents. Current approaches do not give the application access to individual virtualcircuits and their associated guaranteed bandwidth and QoS. Instead, all IP traffic between two hosts shares virtual circuits with no granularity assigned to application-specific traffic or QoS requirements.
これまでのところ、IETFであり、RFC 1577[1]を通して、ワイヤとしてのATMネットワークは扱われています。 ipatmワーキンググループには、明らかに彼らの仕様からの特定のQoS取り扱いの問題に残されて、扱っているドキュメントがあります。 現在のアプローチは彼らの個々のvirtualcircuits、関連保証された帯域幅、およびQoSへのアプリケーションアクセスを与えません。 代わりに、2人のホストの間のすべてのIP交通がアプリケーション特有の交通かQoS要件に割り当てられない粒状と全く仮想のサーキットを共有します。
Thus, neither LAN Emulation nor RFC 1577 (IP over ATM) uses the features of ATM that make it a unique and desirable technology. RFC 1821 (Integration of Realtime Services in an IP-ATM Network Architecture) [2] raises many of the issues associated with current IETF efforts towards integrating ATM into the Internet, but it does not propose any solutions.
したがって、LAN EmulationもRFC1577(ATMの上のIP)もそれをユニークで望ましい技術にするATMの特徴を使用しません。 RFC1821(IP-ATM Network ArchitectureのRealtime Servicesの統合)[2]はATMをインターネットと統合する現在のIETFの努力に関連している問題の多くを提起しますが、それは少しの解決策も提案しません。
This document offers a framework for provision of native ATM circuits for applications which require bandwidth guarantees and QoS. It identifies the requirements of a native ATM protocol which is complementary to standard IP and describes one working implementation.
このドキュメントは帯域幅保証とQoSを必要とするアプリケーションのためのネイティブのATMサーキットの設備のために枠組みを提供します。 それは、標準のIPを補足する固有のATMプロトコルの要件を特定して、1つの働く実現について説明します。
This document recognizes the fact that it is critical that such a native ATM protocol is consistent in the four topologies described in [2]:
このドキュメントはそのような固有のATMプロトコルが[2]で説明された4topologiesで一貫しているのが、批判的であるという事実を認識します:
* Communication across an ATM-only network between two hosts
directly connected to the ATM network,
* Communication between ATM connected hosts which involves some
non-ATM subnets,
* Communication between a host on a non-ATM subnet and a host
directly connected to ATM,
* Communication between two hosts, neither of which has a direct
ATM connection, but which may make use of one or more ATM
networks for some part of the path.
* **直接ATMネットワークに接続された2人のホストの間のATMだけネットワークの向こう側のコミュニケーション、ATMの接続ホストのいくつかの非ATMサブネットにかかわるコミュニケーション、非ATMサブネットのホストとホストとのコミュニケーションは直接ATM、2人のホストの*コミュニケーションに接続しました。(そのホストは、それのどちらもダイレクトATM接続がありませんが、経路の何らかの地域に1つ以上のATMネットワークを利用するかもしれません)。
That is, to the host systems, the underlying type of network remains transparent even when QoS is involved in internet, ATM, and mixed networking environments. To make this consistency possible, the 'native ATM' protocol must also be:
QoSがインターネット、ATM、および複雑なネットワーク環境にかかわるときさえ、すなわち、ホストシステムに、ネットワークの基底型は透明なままで残っています。 また、'ネイティブのATM'プロトコルは、この一貫性を可能にするためには、以下の通りでなければなりません。
* Multicast capable, to optimize transmission overhead and
support ATM multipoint facilities,
* Routable, to enable transmissions across subnets and
internets,
* QoS knowledgeable, to take advantage of ATM QoS facilities,
* Capable of Bandwidth/QoS Reservation to allocate proper
facilities for application traffic as it travels across
* **マルチキャストできます、Routable、博識なQoS、トランスミッションオーバーヘッドを最適化して、ATM多点施設を支持するなら、サブネットとインターネットの向こう側にトランスミッションを可能にするなら、ATM QoS施設を利用するために、それとして適切な施設をアプリケーション交通に割り当てるBandwidth/QoS予約ができる*は横切って旅行します。
Jackowski Informational [Page 3] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[3ページ]のRFC1946のネイティブの気圧サポート
different types of networks: to effectively extend virtual
circuits across internets, and
* Capable of policing to ensure proper packet scheduling
behavior and to protect guaranteed services at merge points.
異なったタイプのネットワーク: 事実上、仮想のサーキットに達するために、適切なパケットスケジューリングの振舞いを確実にして、保護するために取り締まることができるインターネット、および*はマージポイントでアフターサービスを保証しました。
Clearly the protocol should support reservations. Reservation protocols enable creation of 'virtual circuits' with guaranteed bandwidth and QoS on the LAN or internet, and simultaneously can act as signaling mechanisms to routers or ATM interfaces to request provisioning of circuits. Use of a reservation protocol makes characteristics of mixed networks (LANs, internet, ATM, ISDN) transparent to the host systems. That is, a reservation will allow the host or router to provision ATM circuits which match the reservation, but in mixed networks, will allow routers and host to provide bandwidth reservation and QoS across the non-ATM interfaces as well. Effectively, the reservation maps ATM virtual circuits to reservations on subnets and internets.
明確に、プロトコルは予約を支持するべきです。 予約プロトコルは、LANかインターネットで保証された帯域幅とQoSとの'仮想のサーキット'の創造を可能にして、サーキットの食糧を供給することを要求するようにルータかATMインタフェースへのメカニズムに合図するとして同時に、機能できます。 予約プロトコルの使用は複雑なネットワークの特性をホストシステムに透明な(LAN、インターネット、ATM、ISDN)にします。すなわち、予約は、予約に合っている支給ATMサーキットにホストかルータを許容しますが、複雑なネットワークで許容するでしょう、とまた、非ATMインタフェースの向こう側に帯域幅の予約とQoSを提供するルータとホストは許すでしょう。 事実上、予約はATMの仮想のサーキットをサブネットとインターネットの予約に写像します。
This creates a consistent End-to-End, QoS-guaranteed service for mixed network topologies.
これは混ぜられたネットワークtopologiesのために一貫したEndから終わり、QoSによって保証されたサービスを作成します。
While it is beyond the scope of this document, the same requirements apply to mixed ISDN networks and are currently being explored by the ITU for their H.323, H.223, and T.123 standards.
このドキュメントの範囲を超えている間、同じ要件は、複雑なISDNネットワークに申し込んで、現在、それらのH.323、H.223、およびT.123規格のためにITUによって調査されています。
Arguably, the reservation protocol that provides this end-to-end guaranteed service should be connection-oriented to facilitate mapping of real connections (ATM or ISDN) with virtual connections on the LAN/internet. [2] points out the shortcomings of IP and RSVP [3] in the ATM environment. Most notable among these are the difficulty of mapping connectionless traffic to ATM connections, the constant softstate refreshes of RSVP (and merging of RESV messages), the receiver orientation of RSVP, and the dependence on IP multicast.
論証上、提供される予約プロトコルは、この終わりから終わりにサービスがLAN/インターネットにおける仮想接続との本当の接続(ATMかISDN)の容易にするためには接続指向のマッピングであることを保証しました。 [2]はATM環境でIPとRSVP[3]の短所を指摘します。 このうち最も注目に値するのは、ATM接続へのコネクションレスな交通を写像するという困難と、softstateがリフレッシュするRSVPの定数(RESVメッセージを合併して)と、RSVPの受信機オリエンテーションと、IPマルチキャストへの依存です。
[6] is an excellent document that proposes solutions to many of the issues raised in [2], but the solutions recommend modifications to the current RSVP and ATM implementations. Recently, issues of incompatibility with the current IP over ATM model, VC explosions due to use of multicast groups and VC explosions due to features associated with heterogeneous receivers suggest that the current version of RSVP may be inappropriate for ATM implementations.
[6] 問題の多くの解決策を提案する素晴らしいドキュメントは[2]で上げられますが、解決策は現在のRSVPとATM実現への変更を推薦します。 最近、ATMモデルの上の現在のIP、マルチキャストグループの使用によるVC爆発、および異種の受信機に関連している特徴によるVC爆発がある不一致の問題は、ATM実現に、RSVPの最新版が不適当であるかもしれないと示唆します。
Since ATM is connection-oriented, hard state, and origin-oriented for transmission, signaling, and multicast, and is bandwidth and QoS knowledgeable, perhaps the simplest and most elegant approach to a native protocol for ATM would include a protocol that shares these characteristics.
ATMが接続指向であって、固い状態と、トランスミッション、シグナリング、およびマルチキャストにおいて起源指向であり、帯域幅と博識なQoSであるので、恐らくATMのための固有のプロトコルへの最も簡単で最も上品なアプローチはこれらの特性を共有するプロトコルを含んでいるでしょう。
Jackowski Informational [Page 4] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[4ページ]のRFC1946のネイティブの気圧サポート
In surveying protocols described in IETF RFCs and Internet Drafts, only two seem to meet these requirements: Experimental Internet Stream Protocol: Version 2 (RFC 1190) [4] and Internet STream Protocol Version 2+ (RFC 1819) [5]; ST2 and ST2+ respectively.
IETF RFCsとインターネットDraftsで説明された測量学プロトコルでは、2だけがこれらの必要条件を満たすように思えます: 実験インターネット流れのプロトコル: バージョン2(RFC1190)[4]とインターネットはプロトコルバージョン2+(RFC1819)[5]を流します。 ST2とST2+、それぞれ。
2.0 ST2 and ST2+
2.0 ST2とST2+
Both ST2 and ST2+ have been given the Internet Protocol Version 5 (IPv5) designation. In fact, ST2+ is an updated version of ST2. Both protocols are origin-oriented reservation and multicast protocols that provide bandwidth and QoS guarantees through internets. Unlike IPv4 or IPv6, ST2 and ST2+ are connection- oriented, subscribing to the philosophy that once a connection is established, protocol and routing overhead can be substantially reduced. This carries forward to QoS and Bandwidth Reservation as well, simplifying the implementation of QoS guarantees. THESE PROTOCOLS WERE INTENDED TO COMPLEMENT STANDARD CONNECTIONLESS IP, RECOGNIZING THAT WHILE MOST INTERNET TRAFFIC BENEFITS FROM CONNECTIONLESS NETWORKING, PERFORMANCE AND QoS GUARANTEES COULD BE ACHIEVED MOST EASILY WITH INTERNET CONNECTIONS.
インターネットプロトコルバージョン5(IPv5)名称をST2とST2+の両方に与えました。 事実上、ST2+はST2のアップデートされたバージョンです。 両方のプロトコルは、起源指向の予約とインターネットを通して帯域幅とQoSに保証を供給するマルチキャストプロトコルです。 IPv4かIPv6と異なって、ST2とST2+は接続がいったん確立されると、議定書を作ってください。そうすれば、かなりルーティングオーバーヘッドは下げることができるという哲学に加入して、適応する接続です。 QoS保証の実現を簡素化して、これはQoSへのフォワードとまた、Bandwidth予約を運びます。 これらのプロトコルは意図して、そして、標準のコネクションレスなIP、ほとんどのインターネットTRAFFICがコネクションレスなネットワークの利益を得ている間、それを認識する性能の補足となるように、インターネット接続と共にQoS保証を最も容易に達成できたということでした。
Both ST2 and ST2+ really consist of two protocols: SCMP and ST. SCMP is analogous to ICMP in that it is the control and signaling protocol, while ST is the low-overhead streaming protocol. ST-2 uses standard IP addresses during connection setup, but then reduces header overhead by including a stream identifier in each data packet.
ST2とST2+の両方が本当に2つのプロトコルから成ります: SCMPとST. SCMPはそれがコントロールとシグナリングプロトコルであるという点でICMPに類似しています、STは低いオーバーヘッドのストリーミングのプロトコルですが。 ST-2は接続設定の間標準のIPアドレスを使用しますが、各データ・パケットに流れの識別子を含んでいるのによるヘッダーオーバーヘッドはその時、減少します。
ST2+ includes simplification of many of the original ST2 features as well as clarification of the ST2 specification. Among these simplifications and clarifications are:
ST2+はST2仕様の明確化と同様に元のST2の特徴の多くの簡素化を含んでいます。 このうち、簡素化と明確化は以下の通りです。
1) Much simpler connection setup.
2) Flow Specification independence and consolidation of experimental
Flow Specifications.
3) Clarification on the implementation of Groups of Streams.
4) Clarification of leaf-initiated JOINs in multicast trees (several
ST2 implementations had done this).
1) はるかに簡単な接続設定。 2) 実験的なFlow Specificationsの流れSpecification独立と強化。 3) Streams4の)Groupsの実現の明確化 マルチキャスト木(いくつかのST2実現がこれをした)での葉で開始しているJOINsの明確化。
While there continues to be a dramatic increase in the use of ST2 for videoconferencing, video on demand, telemetry applications and networked virtual reality, ST2+ has no commercial implementations and is not yet supported by any router vendors. This is because ST2+ was released as an RFC late in the summer of 1995. It is expected that several implementations will appear over the coming months. As such, the approach described in this document applies to both protocols, and, in fact, would be valid for any other similar protocol used to establish 'native' ATM circuits. Since ST2 and ST2+ are so similar, this document will refer to 'the ST2 protocols'
急騰が続く間、ST2のテレビ会議とビデオオンデマンドと遠隔測定法のアプリケーションとネットワークでつながれたバーチャルリアリティ、ST2の使用で、+はどんな商業実現も持たないで、またどんなルータ業者によってもまだ支持されていません。 これはST2+が1995年夏遅くRFCとしてリリースされたからです。 いくつかの実現が来たる数カ月現れると予想されます。 そういうものとして、本書では説明されたアプローチは、両方のプロトコルに適用して、'ネイティブ'のATMサーキットを証明するのに使用されるいかなる他の同様のプロトコルにも、事実上、有効でしょう。 ST2とST2+が非常に同様であるので、このドキュメントは'ST2プロトコル'について言及するでしょう。
Jackowski Informational [Page 5] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[5ページ]のRFC1946のネイティブの気圧サポート
generically in describing an implementation approach to both. Where particular features of ST2+ are required or affect implementation, 'ST2+ ' will be used specifically.
実現について説明する際に一般的に両方にアプローチしてください。 ST2+の特定の特徴が必要である、または実現に影響するところでは、'ST2+'は明確に使用されるでしょう。
3.0 Implementation Issues for Reservations over ATM
3.0 気圧での予約のための実現問題
As described above, ST is a connection-oriented, hard state, origin- oriented multicast protocol and thus maps fairly well to ATM. However, ST-2 has several features that may be difficult to support in the current version of ATM signaling with Q.2931 and UNI 3.1. Among these are:
STが上で説明されるように接続指向の、そして、固い状態である、起源は、ATMにかなりよくマルチキャストプロトコルを適応させて、その結果、地図を適応させました。 しかしながら、ST-2には、いくつかのQ.2931とUNI3.1と共にATMシグナリングの最新版で支持するのが難しいかもしれない特徴があります。 これらの中に、以下があります。
1) Addressing. 2) Changes to Bandwidth and QoS. 3) Multicasting. 4) Receiver initiated JOINs to multicast groups. 5) Computation of certain QoS parameters. 6) Use of HELLOs.
1) 記述します。 2) 帯域幅とQoSへの変化。 3) マルチキャスティング。 4) 受信機はマルチキャストグループにJOINsを開始しました。 5) あるQoSパラメタの計算。 6) HELLOsの使用。
The degree of difficulty in supporting these functions is dependent on the signaling mechanism chosen. See Section 4 for descriptions of possible signaling approaches and their respective impact on the features listed above.
これらの機能をサポートすることにおける難易度は選ばれたシグナル伝達機構に依存しています。 上にリストアップされた特徴への可能なシグナリングアプローチとそれらのそれぞれの影響の記述に関してセクション4を見てください。
3.1 Addressing
3.1 アドレシング
Of course mapping an Internet address to ATM address is always problematic. It would be possible to set up a well known ARP server to resolve the IP addresses of targets. However, the widespread deployment of IP over ATM and LAN emulation in host-based ATM drivers, and the assumption that most host systems will be running some IP applications that do not need specific QoS and bandwidth provisioning, suggests that use of ARP facilities provided by IP over ATM and LAN Emulation is the most obvious choice for address resolution.
もちろんATMアドレスにインターネット・アドレスを写像するのはいつも問題が多いです。 目標のIPアドレスを決議するためによく知られているARPサーバをセットアップするのは可能でしょう。 しかしながら、ホストベースのATMドライバーのATMとLANエミュレーションの上のIPの広範囲の展開、およびほとんどのホストシステムが特定のQoSを必要としないいくつかのIPアプリケーションと帯域幅の食糧を供給することを走らせるという仮定は、IPによってATMとLAN Emulationの上に提供されたARP施設の使用がアドレス解決のための最も明白な選択であると示唆します。
It should be noted that ATMARP returns the ATM address. For some implementations (particularly kernel-based protocols), an NSAP address is also required. Since these addresses are often difficult to get from the ATM network itself in advance of the connection, it may be necessary to invoke out-of-band signaling mechanisms to pass this address, or it may be better to create an NSAP address server.
ATMARPがATMアドレスを返すことに注意されるべきです。 また、いくつかの実現(特にカーネルベースのプロトコル)において、NSAPアドレスが必要です。 これらのアドレスは接続の前にATMネットワーク自体から得るのがしばしば難しいので、このアドレスを通過するためにバンドの外にシグナル伝達機構を呼び出すのが必要であるかもしれないか、またはNSAPアドレスサーバを作成しているほうがよいかもしれません。
3.2 Changes to Bandwidth and QoS
3.2 帯域幅とQoSへの変化
Both ST-2 and ST-2+ allow the origin to dynamically change the QoS and Bandwidth of a particular stream. At this time Q.2931 and UNI 3.1 do not support this feature. Until this capability is available,
ST-2とST-2+の両方で、起源はダイナミックに特定の流れのQoSとBandwidthを変えることができます。 このとき、Q.2931とUNI3.1はこの特徴を支持しません。 この能力が利用可能になるまで
Jackowski Informational [Page 6] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[6ページ]のRFC1946のネイティブの気圧サポート
full support of the SCMP CHANGE message for dedicated ATM circuits (one reservation = one ATM circuit) can only be implemented by tearing down the existing VC for a stream and establishing a new one if efficient use of ATM resources are to be preserved.
流れのために既存のVCを取りこわして、ATMリソースの効率的な使用が保存されることであるなら新しいものを確立することによって、専用ATMサーキット(1つの予約が1個のATMサーキットと等しい)へのSCMP CHANGEメッセージの全面的な支援を実行できるだけです。
Of course, the CHANGE message can simply be passed across the ATM virtual circuit to the hosts or routers. This would allow the hosts to relax resource requirements locally, and permit routers to relax access to downstream circuits, but the ATM VC itself, would still retain excessive bandwidth.
もちろん、ATMの仮想のサーキットの向こう側に単にCHANGEメッセージをホストかルータに渡すことができます。 これで、ホストは局所的にリソース要件を弛緩できるでしょう、そして、川下のサーキットへのアクセスを弛緩する許可証ルータ(ATM VC自身だけ)はまだ過度の帯域幅を保有しているでしょう。
In addition, if the implementation allows sharing of virtual circuits by multiple streams, the bandwidth/QoS of individual streams within the VC can be CHANGEd.
さらに、実現で複数の流れで仮想のサーキットを共有するなら、VCの中の個々の流れの帯域幅/QoSはCHANGEdであるかもしれません。
3.3 Multicasting
3.3 マルチキャスティング
ST-2 and ST-2+ support origin-oriented multicasting. That is, the origin of a stream explicitly specifies the addresses of the targets it wants involved in the connection. In addition, the origin can Add or drop targets as desired. Aside from receiver-initiated JOINs (discussed in section 3.4), there is a one to one mapping between ST-2 multicast and ATM multipoint connections. Origin-initiated additions can be accomplished through an ADDPARTY, and drops can be done through DROPPARTY.
ST-2とST-2+は起源指向のマルチキャスティングを支持します。 すなわち、流れの起源は明らかにそれが接続にかかわって欲しい目標のアドレスを指定します。 さらに、起源は必要な同じくらいAddか低下同じくらい目標をそうすることができます。 受信機で開始しているJOINs(セクション3.4で、議論する)は別として、ST-2マルチキャストとATMマルチポイント接続の間には、1〜1つのマッピングがあります。 ADDPARTYを通して起源で開始している追加を実行できます、そして、DROPPARTYを通して低下できます。
A key goal in implementation of a native ATM protocol is to ensure consistent implementation for unicast and multicast data transfers. One difficulty in doing this with ATM Virtual Circuits is the fact that point-to-point circuits are duplex, while multipoint circuits are simplex. This means that for multicast connections to be mapped to multipoint ATM Virtual Circuits, any two-way, end-to-end signaling must be done out of band. An alternative is to let the local reservation agent act as a split/merge point for the connection by establishing point-to-point Virtual Circuits for each member of the multicast group directly connected to the ATM network. For multicast group members not directly connected to the ATM network, traffic can be multicast to the router connected at the edge across a single virtual circuit associated with the reservation.
固有のATMプロトコルの実現における主要な目標はユニキャストのための一貫した実現とマルチキャストデータ転送を確実にすることです。 ATM Virtual Circuitsと共にこれをすることにおける1つの苦労が二地点間サーキットが複式であるという事実です、多点サーキットはシンプレクスですが。 これは、マルチキャスト接続が多点ATM Virtual Circuits、どんなツーウェイにも写像されるために、バンドから終わりから終わりへのシグナリングをしなければならないことを意味します。 代替手段は接続のためのマルチキャストグループの各メンバーのためにポイントツーポイントVirtual Circuitsを設立するのによる分裂/マージポイントが直接ATMネットワークに接続したので地元の予約エージェントを行動させることです。 直接ATMネットワークに接続されなかったマルチキャストグループのメンバーにとって、交通は予約に関連しているただ一つの仮想のサーキットの向こう側に縁で接続されたルータへのマルチキャストであるかもしれません。
Section 4 describes alternative mechanisms for implementing signaling.
セクション4は、シグナリングを実行するために代替のメカニズムについて説明します。
Included in each discussion is the optimal means for mapping multicast to ATM point-to-point or multipoint circuits.
各議論に含まれているのは、ATMポイントツーポイントか多点サーキットにマルチキャストを写像するための最適の手段です。
Note that the fact that ST-2 does not rely on IP multicast is a strong advantage in implementation of a native protocol for ATM. The
ST-2がIPマルチキャストを当てにしないという事実がATMのための固有のプロトコルの実現で強い利点であることに注意してください。 The
Jackowski Informational [Page 7] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[7ページ]のRFC1946のネイティブの気圧サポート
one-to-one mapping of ST-2 multicast connections to ATM multipoint virtual circuits minimizes the number of circuits required to support large multicast groups.
ATMの多点の仮想のサーキットとのST-2マルチキャスト接続に関する1〜1つのマッピングが大きいマルチキャストグループを支持しなければならなかったサーキットの数を最小にします。
3.4 Receiver Initiated JOINs to Multicast Groups
開始された3.4受信機はマルチキャストグループにつなぎます。
ST-2+ provides an in-band mechanism to permit receivers to join an existing stream. Based on an origin-established authorization level, the JOIN can be refused immediately, can be allowed with notification of the origin, or can be allowed without notifying the origin. This capability is made available through a new SCMP JOIN message. If the receiver knows the IP address of the origin and the Stream ID, he can join the stream if authorized to do so.
+が受信機が既存の流れに参加することを許可するためにバンドにおけるメカニズムを供給するST-2。 起源で確立した認可レベルに基づいて、起源に通知しないで、JOINをすぐに拒否できるか、起源の通知で許容できるか、または許容できます。 この能力を新しいSCMP JOINメッセージを通して利用可能にします。 受信機が起源とStream IDのIPアドレスを知っているなら、そうするのが認可されるなら、彼は流れに参加できます。
Note that since the JOIN flows from the receiver to the origin, there will be issues in trying to support this feature with Q.2931 and UNI 3.1. The JOIN may have to be sent out of band depending on the signaling mechanism chosen (section 4) because of the uni-directional flow for point to multipoint ATM connections. This is supposed to change with availability of UNI 4.0.
JOINが受信機から起源まで流れるので、Q.2931とUNI3.1と共にこの特徴を支持しようとするのにおいて問題があることに注意してください。 JOINをuni方向の流れのためにポイントのために(セクション4)に選ばれたシグナル伝達機構によるバンドから多点ATM接続に送らなければならないかもしれません。 これはUNI4.0の有用性を交換するべきです。
ST-2 did not support receiver initiated JOINs (unlike ST-2+). However, most implementations created an out-of-band, or SCMP extension to support this facility. Again, depending on the SCMP signaling mechanism chosen, this feature may be difficult to support.
ST-2は受信機の開始しているJOINs(ST-2+と異なった)を支持しませんでした。 しかしながら、ほとんどの実現が、この施設を支持するためにバンドのアウト、またはSCMP拡張子を作成しました。 選ばれたSCMPシグナル伝達機構によって、一方、この特徴は支持するのが難しいかもしれません。
3.5 Computation of QoS Parameters
3.5 QoSパラメタの計算
The recommended flow specifications (flowspecs) for ST-2 and ST-2+ include parameters that are not currently available to ATM virtual circuits through Q.2931 and UNI 3.1. The mapping of packet rate to cell rate, packet delay to cell delay, and other translatable QoS parameters is described in section 5. However, the ST-2 flowspecs also include parameters like accumulated end-to-end delay and accumulated jitter. These parameters assume that the SCMP messages follow the same path as the data. Depending on the signaling mechanism chosen, this may not be true with ATM and thus certain QoS parameters may be rendered useless.
ST-2とST-2+におけるお勧めの流れ仕様(flowspecs)は現在Q.2931とUNI3.1を通してATMの仮想のサーキットに利用可能でないパラメタを含んでいます。 セルレートへのパケットレート、セル遅れへのパケット遅れ、および他の翻訳できるQoSパラメタに関するマッピングはセクション5で説明されます。 しかしながら、また、ST-2 flowspecsは終わりから終わりへの蓄積された遅れと蓄積されたジターのようなパラメタを含んでいます。 これらのパラメタは、SCMPメッセージがデータと同じ経路に続くと仮定します。 選ばれたシグナル伝達機構によって、これは、QoSパラメタが役に立たなく表されるかもしれないのをATMで本当であって、その結果、確信していないかもしれません。
It should also be noted that since ST-2 connections are simplex, all QoS parameters are specified separately for each direction of data transfer. Thus two connections and two QoS negotiations are required for a duplex connection. To take advantage of the full duplex nature of point-to-point ATM connections, special multiplexing of ST connections would be required by ST-2 agents.
また、すべてのQoSパラメタがST-2接続がシンプレクスであるので別々にデータ転送の各方向に指定されることに注意されるべきです。 したがって、2つの接続と2つのQoS交渉が重複の接続に必要です。 二地点間ATM接続の全二重本質を利用するために、ST接続の特別なマルチプレクシングはST-2エージェントによって必要とされるでしょう。
Jackowski Informational [Page 8] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[8ページ]のRFC1946のネイティブの気圧サポート
3.6 Use of HELLOs
3.6 HELLOsの使用
Both ST-2 and ST-2+ support HELLO messages. HELLOs are intended to assure that the neighboring agent is alive. Failure to respond to a HELLO indicates that the connection is down and that the reservation for that particular link should be freed.
ST-2とST-2+サポートHELLOメッセージの両方。 HELLOsが、隣接しているエージェントが生きていることを保証することを意図します。 HELLOに応じない場合、接続が下がっていて、その特定のリンクの予約が解放されるべきであるのを示します。
While the ATM network will notify an ST-2 agent if the network connection is down, there is still the possibility that the connection is intact but that the ST-2 agent itself is down. Knowledge of the neighboring agent's status is increasingly important when multiple ST-2 connections share virtual circuits, when the neighboring agents are routers, and when there are multiple dedicated virtual circuits between agents.
ネットワーク接続が下がっていると、ATMネットワークはST-2エージェントに通知するでしょうが、接続が完全ですが、ST-2エージェント自身が下がっている可能性がまだあります。 隣接しているエージェントの状態に関する知識は隣接しているエージェントであるときに、複数のST-2接続が仮想のサーキットを共有するとますます重要であるのが、ルータといつ、エージェントの間には、複数の専用仮想のサーキットがあるかということであるということです。
As such, HELLO is a desirable feature. Note that some signaling schemes (section 4), provide less than optimal support for HELLO.
そういうものとして、HELLOは望ましい特徴です。 何らかのシグナリングが(セクション4)を計画することに注意してくださいといって、HELLOの最適のサポートほど前提としないでください。
4.0 Reservation Signaling with ATM
4.0 気圧がある予約シグナリング
Use of Permanent Virtual Circuits (PVCs) for reservation signaling presents no problem for ST-2, ST-2+, or RSVP. Each circuit is considered to be a dedicated link to the next hop. If the PVCs are to be shared, reservation protocols can divide and regulate the bandwidth just as they would with any other link type.
Permanent Virtual Circuits(PVCs)の予約シグナリングの使用はST-2、ST-2+、またはRSVPのために問題を全く提示しません。 各サーキットは次のホップへの専用リンクであると考えられます。 PVCsが共有されるつもりであるなら、予約プロトコルは、ちょうどいかなる他のリンク型でも規制するように帯域幅を分割して、規制できます。
Where ATM connections become more interesting is when the ATM network takes on the role of an extended LAN or internet. To do this, Switched Virtual Circuits are used to establish dynamic connections to various endpoints and routers. The ITU-TS Q.2931 SETUP message is used to request a connection from the network with specific bandwidth and QoS requirements, and a CONNECT message is received by the origin to indicate that connection establishment is complete.
ATM接続がどこで、よりおもしろくなるかは、ATMネットワークが拡張LANかインターネットの役割を引き受ける時です。 これをするなら、Switched Virtual Circuitsは、様々な終点とルータにダイナミックな接続を証明するのに使用されます。 特定の帯域幅とQoS要件でネットワークから接続を要求するのにITU-TS Q.2931 SETUPメッセージを使用します、そして、起源でCONNECTメッセージを受け取って、コネクション確立が完全であることを示します。
For IP over ATM and LAN Emulation, SVCs are established between endpoints and data traffic for a given destination shares the SVCs. There is no mechanism to allow specific QoS guarantees for the traffic, nor is there a mechanism to set up virtual circuits with specific bandwidth and QoS for a particular type of traffic. This is what reservation protocols will attempt to do. The goal is to use reservations to request establishment of individual virtual circuits with matching bandwidth and QoS for each reservation. This will guarantee the requirements of the application while taking full advantage of the ATM network's capabilities.
ATMとLAN Emulationの上のIPに関しては、SVCsは終点の間に設立されます、そして、与えられた目的地のためのデータ通信量はSVCsを共有します。 交通のための特定のQoS保証を許容するために、メカニズムは全くありません、そして、特定の帯域幅とQoSがある仮想のサーキットを特定のタイプの交通に準備させるために、メカニズムはありません。 これはどんな予約プロトコルがしようとして未遂に終わるかということです。 目標は各予約のために合っている帯域幅とQoSとの個々の仮想のサーキットの設立を要求するのに予約を使用することです。 これはATMネットワークの能力を最大限に利用している間、アプリケーションの要件を保証するでしょう。
There are four possible mechanisms to perform reservation signaling over ATM:
ATMの上で予約シグナリングを実行するために、4台の可能なメカニズムがあります:
Jackowski Informational [Page 9] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[9ページ]のRFC1946のネイティブの気圧サポート
1) Embedding reservation signaling equivalents within the ATM Q.2931
controls.
2) Signaling in-band with the data.
3) Signaling over dedicated signaling VCs.
4) Implicitly sharing existing VCs for IP over ATM or LAN Emulation.
1) ATM Q.2931の中で予約シグナリング同等物を埋め込むのは制御されます。 2) データによるバンドのシグナリング。 3) 専用シグナリングVCsの上で合図します。 4) それとなく、IPのためにATMかLAN Emulationの上で既存のVCsを共有します。
Note that ATM circuits are not necessarily reliable. As such, the reliability mechanisms provided by SCMP must be maintained to assure delivery of all reservation signaling messages.
ATMサーキットが必ず信頼できるというわけではないことに注意してください。 そういうものとして、すべての予約シグナリングメッセージを配送に保証するためにSCMPによって提供された信頼性のメカニズムを維持しなければなりません。
4.1 Embedded Reservation Signaling Equivalents within ATM Q.2931
Controls
4.1 気圧Q.2931コントロールの中の埋め込まれた予約シグナリング同等物
The basic idea in embedding reservation signaling within the ATM controls is to use the Q.2931 SETUP and CONNECT messages to establish both reservations and dedicated data paths (virtual circuits) across the ATM network. This eliminates the need for dedicated signaling channels, in-band signaling, or out of band mechanisms to communicate between endpoints. Since SETUP and CONNECT include bandwidth and QoS information, the basic concept is sound. In fact, this approach will speed network connection by preventing multiple passes at establishing a reservation and associated connection. This normally results from the fact that most higher layer protocols (network and transport) first require a link to signal their connection requirements. As such, with ATM, the ATM virtual circuit must be established before the network and/or transport protocols can do their own signaling.
ATMコントロールの中で予約シグナリングを埋め込むことにおける基本的な考え方はQ.2931 SETUPとATMネットワークの向こう側に予約とひたむきなデータ経路(仮想のサーキット)の両方を確立するCONNECTメッセージを使用することです。 合図するか、または終点の間で伝えるバンドメカニズムから排除して、これはバンドのひたむきなシグナリングチャンネルの必要性を排除します。 SETUPとCONNECTが帯域幅とQoS情報を含んでいるので、基本概念は論理的に正しいです。 事実上、このアプローチは、予約と関連接続を確立するのに複数のパスを防ぐことによって、ネットワーク接続を促進するでしょう。 通常、これはほとんどの、より高い層のプロトコル(ネットワークでつないで、輸送する)が最初にそれらの接続要件に合図するためにリンクを必要とするという事実から生じます。 そういうものとして、ネットワーク、そして/または、トランスポート・プロトコルがそれら自身のシグナリングができる前にATMと共に、ATMの仮想のサーキットを確立しなければなりません。
Embedded reservation signaling allows the reservation information to be carried in the SETUP and CONNECT messages, allowing the reservation protocol to do its signaling simultaneously with the ATM signaling.
埋め込まれた予約シグナリングは、予約情報がSETUPとCONNECTメッセージで運ばれるのを許容します、ATMが合図している状態で予約プロトコルが同時にシグナリングをするのを許容して。
[7] describes a clever way of combining the reservation signaling with the ATM control plane signaling for ST-2. This 'simultaneous connection establishment' process will optimize the establishment of circuits and minimize connection setup time while simultaneously eliminating unnecessary network layer signaling in ST-2. To be effective, [7] requires enhancements to Q.2931 signaling and to the ST-2 protocol implementations. In addition, it currently only applies to point-to-point connections and will not work with multipoint largely due to the simplex nature of multipoint communication in current ATM implementations.
[7]はST-2のために合図するATM制御飛行機に予約シグナリングを結合する賢明な方法を述べます。 この'同時接続設立'の過程は同時にST-2で不要なネットワーク層シグナリングを排除する間、サーキットの設立を最適化して、接続準備時間を最小にするでしょう。 有効に、なるように、[7]はQ.2931シグナリングと、そして、ST-2プロトコル実現に増進を必要とします。 さらに、それは、現在、二地点間接続に適用するだけであり、多点で主に現在のATM実現におけるマルチポイント通信のシンプレクス本質のため取り組まないでしょう。
Implementation of multicast for Embedded Reservation Signaling is done as described above: the reservation agent at the edge of the ATM network must create point-to-point virtual circuits for each target that is directly connected to the ATM network, and for each router
以下の上で説明されるようにEmbedded予約Signalingのためのマルチキャストの実現をします。 ATMネットワークの縁の予約エージェントは直接ATMネットワークに接続される各目標、および各ルータのために二地点間仮想のサーキットを作成しなければなりません。
Jackowski Informational [Page 10] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[10ページ]のRFC1946のネイティブの気圧サポート
that supports downstream targets. This ensures two-way signaling between targets and the origin.
それは下流標的を支えます。 これは目標と起源の間で合図するツーウェイを確実にします。
Signaling itself is quite simple:
シグナリング自体はかなり簡単です:
CONNECT maps directly to one or more (multicast) Q.2931
SETUPs and CONNECTs.
ACCEPT maps directly to Q.2931 CONNECTACK.
CHANGE/CHANGE REQUEST are not supported.
DISCONNECT maps directly to Q.2931 RELEASE.
HELLOs are not needed.
CONNECTは直接1つ(マルチキャスト)以上にQ.2931 SETUPsとCONNECTsを写像します。 直接Q.2931 CONNECTACKへのACCEPT地図。 CHANGE/CHANGE REQUESTは支持されません。 直接Q.2931 RELEASEへのDISCONNECT地図。 HELLOsは必要ではありません。
Unfortunately, the flowspec in the reservation protocol CONNECT message cannot be passed across the ATM network in the signaling messages and thus must be regenerated by the receiving agent.
残念ながら、予約プロトコルCONNECTメッセージのflowspecをシグナリングメッセージのATMネットワークの向こう側に渡すことができないで、その結果、受信エージェントは作り直さなければなりません。
In addition, User Data, which can be sent in most SCMP messages cannot be supported without substantial changes to current Q.2931 signaling.
添加、User Dataでは、現在のQ.2931シグナリングへの大きな変化なしでほとんどのSCMPメッセージでどれを送ることができるか支持できません。
One of the additional complexities with embedding the reservation signaling occurs in heterogeneous networks. Since ATM signaling only operates point to point across the ATM network itself, if the endpoints reside on other types of networks or subnets, the routers at the edge of the ATM networks must generate and regenerate endpoint-based signaling messages on behalf of the host reservation agents. In particular, CONNECT and ACCEPT messages and their associated flowspecs must be regenerated. Refer to Section 5 for details on the QoS mappings and on which QoS parameters can be recreated for the generated flowspecs.
予約シグナリングを埋め込む追加複雑さの1つは異機種ネットワークで起こります。 ATMシグナリングがATMネットワーク自体の向こう側にポイント・ツー・ポイントを操作するだけであるので、終点が他のタイプのネットワークかサブネットに住んでいるなら、ATMネットワークの縁のルータは、ホスト予約エージェントを代表して終点ベースのシグナリングメッセージを発生して、作り直さなければなりません。 特に、CONNECT、ACCEPTメッセージ、およびそれらの関連flowspecsを作り直さなければなりません。 QoSマッピングに関する詳細のためのセクション5と発生しているflowspecsのためにどのQoSパラメタを休養させることができるかに関して、参照してください。
This approach is worth revisiting as an optimal signaling method in pure ATM network environments once ATM signaling capabilities expand.
純粋なATMの最適のシグナリング方法がかつてのATMが広がると能力に合図する環境をネットワークでつなぐとき、このアプローチは再訪する価値があります。
However, for heterogeneous networks, other signaling mechanisms may be more appropriate.
しかしながら、異機種ネットワークにおいて、他のシグナル伝達機構は、より適切であるかもしれません。
4.2 In-Band Reservation Signaling
4.2 バンドにおける予約シグナリング
In-Band Reservation Signaling is the easiest signaling mechanism to implement. When the applications requests a reservation, the reservation agent simply sets up ATM virtual circuits to the endpoints with the QoS specified in the CONNECT request. When ACCEPTed, all subsequent data transmissions proceed on the virtual circuits.
バンドにおける予約Signalingは実行する中で最も簡単なシグナル伝達機構です。 予約、予約エージェントが単にセットアップするというアプリケーション要求であるときに、QoSがある終点へのATMの仮想のサーキットはCONNECT要求で指定しました。 ACCEPTedであるときに、すべての順次データ送信が仮想のサーキットの上に続きます。
Once again, to support multicast, the reservation agent must create individual point-to-point virtual circuits to the targets which are
マルチキャストを支持するために、もう一度、予約エージェントは個々の二地点間仮想のサーキットをそうする目標に作成しなければなりません。
Jackowski Informational [Page 11] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[11ページ]のRFC1946のネイティブの気圧サポート
directly connected to the ATM network, as well as to routers which can access downstream targets.
直接ATMネットワークと、そして、下流標的にアクセスできるルータに関連しています。
Since signaling is done in-band, all reservation signaling messages can be passed between agents. However, some minimal additional bandwidth must be allocated in the Q.2931 SETUP to allow for the signaling messages themselves.
シグナリングが完了しているので、バンドであり、エージェントの間ですべての予約シグナリングメッセージを通過できます。 しかしながら、シグナリングメッセージ自体を考慮するためにQ.2931 SETUPにいくらかの最小量の追加帯域幅を割り当てなければなりません。
Note that the primary disadvantage to In-Band Reservation Signaling is the fact that it does not make use of the multipoint capabilities of ATM and will thus overreserve ATM network bandwidth and create a larger than necessary number of virtual circuits.
その結果、overreserve ATMは帯域幅をネットワークでつなぐでしょう、そして、In-バンド予約Signalingへの第一の不都合がATMの多点能力を利用しないという事実であることに注意してください、そして、必要とするより多くの仮想のサーキットを作成してください。
4.3 Dedicated Reservation Signaling Virtual Circuits
4.3 専用予約シグナリング仮想のサーキット
One mechanism that can be used to take advantage of the full data transmission capabilities of ATM networks is to use Dedicated Virtual Circuits for reservation signaling. This guarantees a two-way signaling pipe between the endpoints in a connection while enabling the data transmission to take advantage of the multipoint capabilities of ATM. Data and Signaling are done over separate virtual circuits.
ATMネットワークの完全なデータ伝送能力を利用するのに使用できる1つのメカニズムは予約シグナリングにDedicated Virtual Circuitsを使用することです。 データ伝送がATMの多点能力を利用するのを可能にしている間、これは接続における終点の間の両用シグナリングパイプを保証します。 別々の仮想のサーキットの上にデータとSignalingをします。
When an application requests a reservation, the reservation agent reviews the list of targets in the CONNECT request. For any targets which have no current signaling virtual circuits established, the agent establishes UBR (unspecified bit rate) virtual circuits and forwards the CONNECT message to the targets over these virtual circuits. ATMARP is used to resolve any endpoint addresses. For any targets for which there already exist signaling virtual circuits, the agent simply forwards the CONNECT message over the existing virtual circuit.
アプリケーションが予約を要求するとき、予約エージェントはCONNECT要求で目標のリストを再検討します。 仮想のサーキットが確立した現在のシグナリングがないのを持っているどんな目標のためにも、エージェントは、UBR(不特定のビット伝送速度)の仮想のサーキットを確立して、これらの仮想のサーキットの上の目標にCONNECTメッセージを転送します。 ATMARPは、どんな終点アドレスも決議するのに使用されます。 合図している仮想のサーキットが既に存在するどんな目標のためにも、エージェントは単に既存の仮想のサーキットの上にCONNECTメッセージを転送します。
Once an ACCEPT message is received, the agent issues a Q.2931 SETUP to the associated target. Upon receipt of a CONNECTACK, data can begin to flow. As additional ACCEPTs are received, the Q.2931 ADDPARTY message is used to add a target to the multicast and multipoint connection. Depending on the cause of any ADDPARTY failure, the agent may attempt to establish a dedicated point-to- point virtual circuit to complete the multicast group.
ACCEPTメッセージがいったん受信されるようになると、エージェントは関連目標にQ.2931 SETUPを発行します。 CONNECTACKを受け取り次第、データは流れ始めることができます。 追加ACCEPTsが受け取られているので、Q.2931 ADDPARTYメッセージはマルチキャストとマルチポイント接続に目標を加えるのに使用されます。 どんなADDPARTYの故障の原因にもよって、エージェントは、マルチキャストグループを完成するために専用ポイントからポイントへの仮想のサーキットを確立するのを試みるかもしれません。
DISCONNECT requests result in Q.2931 DROPPARTY messages and will cause a member to be dropped from a multicast and multipoint connection. When all targets are dropped from a multipoint connection, a RELEASE can be issued to take down the virtual circuit.
DISCONNECT要求は、Q.2931 DROPPARTYメッセージをもたらして、マルチキャストとマルチポイント接続からメンバーを落とされるでしょう。 すべての目標がマルチポイント接続から落とされるとき、仮想のサーキットを降ろすためにRELEASEを発行できます。
Signaling virtual circuits are shared among reservations while data circuits are dedicated to a particular reservation. Once all
データ回線は特定の予約に捧げられますが、合図している仮想のサーキットは予約の中で共有されます。 一度すべて
Jackowski Informational [Page 12] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[12ページ]のRFC1946のネイティブの気圧サポート
reservations to a given endpoint are terminated, the signaling virtual circuit to that endpoint can be RELEASEd.
与えられた終点への予約が終えられる、その終点への合図している仮想のサーキットはRELEASEdであるかもしれません。
Note that this approach would allow the NSAP address to be passed as user data in the ACCEPT message to enable a kernel-based reservation protocol to establish the dedicated data circuit. In addition, because the connectivity to the endpoint is identical to that of the data circuit, this approach assures the fact that accumulated information in the flowspecs retains it validity.
カーネルベースの予約を可能にするACCEPTメッセージの利用者データが専用データ回線を証明するために議定書を作るときNSAPアドレスがこのアプローチで通ることに注意してください。 このアプローチは終点への接続性が添加データ回線のものと同じであるので、flowspecsの蓄積された情報がそれを保有するという事実を保証します。正当性。
4.4 Reservation Signaling via IP over ATM or LAN Emulation
4.4 ATMかLAN Emulationの上のIPを通した予約Signaling
As described in the previous section, it would be possible to set up unique SVCs for SCMP signaling, however, since the streaming, connection-oriented data transport offered by ST-2 is intended to be complementary to IP and other connectionless protocol implementations, it would be simpler and more elegant to simply use classical IP over ATM (RFC 1577) mechanisms, or to use LAN Emulation. The widespread deployment of IP over ATM and LAN emulation in host- based ATM drivers, and the assumption that most host systems will be running applications that do not need specific QoS and bandwidth provisioning, makes this the most straightforward (if not performance optimal) solution for signaling. Once an end-to-end acceptance of a reservation request is completed via normal LAN or IP transmission, then a unique direct virtual circuit can be established for each data flow.
ST-2によって提供されたストリーミングの、そして、接続指向のデータ伝送がIPと他のコネクションレスプロトコル実現を補足していることを意図するので、しかしながら、ATM(RFC1577)メカニズムの上で単に古典的なIPを使用するか、またはLAN Emulationを使用するのが、SCMPシグナリングのためにユニークなSVCsをセットアップするのが前項で説明されるように可能であるだろう、より簡単であって、より上品でしょう。 ホストのベースのATMドライバーのATMとLANエミュレーションの上のIPの広範囲の展開、およびほとんどのホストシステムが特定のQoSと帯域幅の食糧を供給することを必要としないアプリケーションを実行しているという仮定はシグナリングのこの最も簡単で(性能最適)の解決策を作ります。 一度、終わりから終わりへの予約の要請の承認は正常なLANかIPトランスミッションで終了していて、次に、各データフローのためにユニークなダイレクト仮想のサーキットは確立できます。
If LAN Emulation is used, as long as the ST-2 implementation allows for different paths for SCMP and data, there would be no changes to the signaling mechanisms employed by the reservation agent.
ST-2実現がSCMPとデータに関して異なった経路を考慮する限り、LAN Emulationが使用されているなら、予約エージェントによって使われたシグナル伝達機構への変化が全くないでしょう。
For IP over ATM, all SCMP messages would be encapsulated in IP as described in both RFC 1190 and RFC 1819. This is required because current ATM drivers will not accept Ipv5 packets, and most drivers do not provide direct access to the shared signaling virtual circuits used for IP.
ATMの上のIPに関しては、すべてのSCMPメッセージがRFC1190とRFC1819の両方で説明されるようにIPで要約されるでしょう。 現在のATMドライバーがIpv5パケットを受け入れないで、またほとんどのドライバーが仮想のサーキットがIPに使用した共有されたシグナリングに直接アクセスを提供しないので、これが必要です。
In either case, LAN Emulation or IP over ATM, the reservation agent would handle SCMP messages as it normally does. However, once the first ACCEPT is received for a reservation request, a dedicated virtual circuit is established for the data flow. Subsequent ACCEPTs will result in the use of ADDPARTY to add multicast targets to the multipoint virtual circuit. In fact, processing of multipoint/multicast is identical to that described in section 4.3.
ケース、LAN EmulationかATMの上のIPのどちらかでは、通常、エージェントがそれとしてSCMPメッセージを扱うだろうという条件はします。 しかしながら、予約の要請のためにいったん最初のACCEPTを受け取ると、データフローのために専用仮想のサーキットを確立します。 その後のACCEPTsは、多点の仮想のサーキットにマルチキャスト目標を加えるためにADDPARTYの使用で結果になるでしょう。 事実上、多点/マルチキャストの処理はセクション4.3で説明されたそれと同じです。
Once again, the use of an out-of-band signaling mechanism makes it possible to carry the NSAP address of the target in the ACCEPT message.
もう一度、バンドで出ているシグナル伝達機構の使用でACCEPTメッセージで目標のNSAPアドレスを運ぶのは可能になります。
Jackowski Informational [Page 13] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[13ページ]のRFC1946のネイティブの気圧サポート
One potential drawback to using LAN Emulation or SCMP messages encapsulated in IP over ATM, is the fact that there is no guarantee that the connectivity achieved to reach the target via signaling has any relationship to the data path. This means that accumulated values in the flowspec may be rendered useless.
IPでATMの上に要約されたLAN EmulationかSCMPメッセージを使用することへの1つの潜在的欠点がシグナリングで目標に達するように達成された接続性がデータ経路とのどんな関係も持っているという保証が全くないという事実です。 flowspecに値を蓄積したこの手段は役に立たなく表されるかもしれません。
In addition, it is possible that the targets will actually reside outside the ATM network. That is, there may be no direct ATM access to the Targets and it may be difficult to identify ATM addresses of the associated ATM connected routers. This approach will involve some additional complexity in routing to the targets. However, since ST-2 is intended to run with IP, if ATM vendors would accept IPv5 packets or would allow direct access to the IP over ATM signaling virtual circuits, this approach would be optimal in minimizing the number of virtual circuits required.
さらに、目標が実際にATMネットワークの外にあるのは、可能です。 すなわち、TargetsへのどんなダイレクトATMアクセスもないかもしれません、そして、関連ATM接続ルータのATMアドレスを特定するのは難しいかもしれません。 このアプローチはルーティングにおける何らかの追加複雑さを目標に伴うでしょう。 しかしながら、ST-2がIPと共に走ることを意図するので、ATM業者がIPv5パケットを受け入れるだろうか、または仮想のサーキットに合図するATMの上のIPに直接アクセスを許すなら、このアプローチは仮想のサーキットの数が必要とした最小にすることで最適でしょう。
4.5 Summary of Reservation Signaling Approaches
4.5 予約シグナリングアプローチの概要
Embedded Reservation Signaling (section 4.1) is ideal for homogeneous ATM connections, but requires extensions to existing ATM signaling to support multipoint connections. In-Band Reservation Signaling (section 4.2) is the easiest to implement, but cannot employ multipoint connections either.
埋め込まれた予約Signaling(セクション4.1)は均質のATM接続に理想的ですが、マルチポイント接続を支持すると合図する既存のATMに拡大を必要とします。 バンドにおける予約Signaling(セクション4.2)は実行するのが最も簡単ですが、マルチポイント接続を雇うことができません。
Perhaps the simplest way to do this is similar to what is suggested in [6]: separate the reservation signaling from the actual data flows, mapping the data flows directly to ATM circuits while doing the signaling separately.
これをする恐らく最も簡単な方法は[6]に示されることと同様です: 実際のデータフローと予約シグナリングを切り離してください、別々にシグナリングをしている間、直接ATMサーキットにデータフローを写像して。
While there is significant complexity in doing this for IP traffic and RSVP, the ST2 protocols lend themselves to this quite well. In fact, because SCMP reservation signaling results in streaming, multicast connections, the 'Shortcut' mechanism described in [6], which can bypass routers where direct ATM connections are possible, is automatically available to ST2 streams.
IP交通とRSVPのためにこれをするのにおいて重要な複雑さがある間、ST2プロトコルは自分たちをこれに全くよく与えます。 事実上、SCMP予約シグナリングがストリーミングのマルチキャスト接続をもたらすので、[6]で説明された'近道'メカニズムは自動的にST2の流れに利用可能です。ダイレクトATM接続が可能であるところで[6]はルータを迂回させることができます。
Using Reservation Signaling over LAN Emulation or IP over ATM (section 4.4) is one multipoint-capable approach to implement in hosts since most ATM drivers shipping today provide both IP over ATM and LAN Emulation, as well as associated address resolution mechanisms. However, it is not complete in its ability to accurately depict flowspec parameters or to resolve host ATM addresses. In addition, to be optimal, ATM vendors would either have to support IPv5 in their drivers or allow direct access to the IP signaling virtual circuits. Thus the current ideal approach to implementation of the ST2 protocols over ATM is to use shared Dedicated Reservation Signaling Virtual Circuits (section 4.3) for signaling of reservations, and then to establish appropriate multipoint ATM
今日出荷しているほとんどのATMドライバーがATMの上のIPとLAN Emulationの両方を提供するので、ATM(セクション4.4)の上でLAN EmulationかIPの上で予約Signalingを使用するのは、ホストで実行する1つの多点できるアプローチです、関連アドレス解決メカニズムと同様に。しかしながら、それは正確にflowspecパラメタについて表現するか、またはホストATMアドレスを決議する性能で完全ではありません。 さらに、ATM業者は、彼らのドライバーでIPv5を支持しなければならないか、または最適に、なるように仮想のサーキットに合図するIPに直接アクセスを許さなければならないでしょう。 したがって、ATMの上のST2プロトコルの実現への現在の理想的なアプローチは、予約のシグナリングに、共有されたDedicated予約Signaling Virtual Circuits(セクション4.3)を使用して、そして、適切な多点ATMを設立することです。
Jackowski Informational [Page 14] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[14ページ]のRFC1946のネイティブの気圧サポート
virtual circuits for the data flows.
データフローのための仮想のサーキット。
5.0 Mapping of Reservation QoS to ATM QoS
5.0 気圧QoSへの予約QoSに関するマッピング
QoS negotiation in ST-2 (and ST-2+) is done via a two-way negotiation.
両用交渉でST-2(そして、ST-2+)でのQoS交渉をします。
The origin proposes a QoS for the connection in a Flow Specification (Flowspec) associated with the CONNECT message. Most of the network-significant QoS parameters in the Flowspec include both a minimum and a desired value. Each ST agent along the path to the Target validates its ability to provide the specified QoS (at least the minimum value for each), updates certain values in the Flowspec, and propagates the CONNECT until it reaches the Target. The Target can either ACCEPT the Flowspec or REFUSE it if it cannot meet at least the minimum QoS requirements. Negotiation takes place as part of the process in that the Target can specify changes to the desired QoS values as long as the new value meets at least the minimum requirements specified by the Origin system. In addition, both the Target and the Origin can assess actual network performance by reviewing the values that are accumulated along the path.
起源はCONNECTメッセージに関連しているFlow Specification(Flowspec)での接続のためにQoSを提案します。 Flowspecのネットワーク重要なQoSパラメタの大部分は最小限と目標値の両方を含んでいます。 Targetへの経路に沿ったそれぞれのSTエージェントは、指定されたQoS(それぞれのための少なくとも最小値)を提供する性能を有効にして、Flowspecで、ある値をアップデートして、Targetに達するまで、CONNECTを伝播します。 Target缶のACCEPT FlowspecかREFUSEのどちらか、それはそれであるなら少なくとも最小のQoS必要条件を満たすことができません。 新しい値が少なくとも必要最小限を満たす限り、Targetが必要なQoS値への変化を指定できるので過程の一部がOriginシステムで指定したように交渉は行われます。 さらに、TargetとOriginの両方が経路に沿って蓄積される値を見直すのによる実際のネットワーク性能を評価できます。
The primary Reservation QoS parameters that impact an ATM network are:
ATMネットワークに影響を与える第一の予約QoSパラメタは以下の通りです。
ST-2 (RFC 1190) ST-2+ (RFC 1819)
-2番目、(RFC1190)、-2第+(RFC1819)
Desired PDU Bytes, Desired Message Size, Limit on PDU Bytes (minimum). Limit on Message Size.
必要なPDUバイト、必要なメッセージサイズ、PDUバイトにおける限界(最小の)。 メッセージでサイズを制限してください。
Desired PDU Rate, Desired Rate, Limit on PDU Rate (minimum). Limit on Rate. Minimum Transmission Rate in Bytes.
必要なPDUレート、必要なレート、PDUレート(最小限)における限界。 レートでは、制限します。 バイトで表現される最小の通信速度。
Limit on Delay (maximum). Desired Delay,
Limit on Delay.
Maximum Bit Error Rate.
遅れ(最大の)では、制限します。 必要な遅れ、遅れにおける限界。 最大のビット誤り率。
Accumulated Delay. Accumulated Delay Variance (Jitter).
遅れを蓄積しました。 遅れ変化(ジター)を蓄積しました。
Q.2931 ATM signaling offers the following QoS parameters:
Q.2931 ATMシグナリングは以下のQoSパラメタを提供します:
- Cumulative Transit Delay, - Maximum End to End Transit Delay.
- 累積しているトランジット遅れ--トランジット遅れを終わらせる最大の終わり。
- Forward Peak Cell Rate (PCR), - Backward Peak Cell Rate (PCR).
- 前進のピークセルレート(PCR)--後方では、セルレート(PCR)はピークに達します。
Jackowski Informational [Page 15] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[15ページ]のRFC1946のネイティブの気圧サポート
- Forward Maximum CPCS-SDU size, - Backward Maximum CPCS-SDU size.
- サイズをMaximum CPCS-SDUに送ってください--後方のMaximum CPCS-SDUサイズ。
- Forward QoS Class, - Backward QoS Class.
- クラスをQoSに送ってください--後方のQoSのクラス。
- B-LLI (one byte user protocol information).
- B-LLI(1バイトのユーザプロトコル情報)。
As previously noted, reservation protocols (ST and RSVP) make QoS reservations in one direction only. Thus, depending on the type of signaling used (see Section 4), the 'Backward' ATM parameters may not be useful. In particular, if Multipoint ATM connections are used to map multicast reservations, these parameters are not available.
上述しているように、予約プロトコル(STとRSVP)は一方向だけでQoSを予約にします。 したがって、'後方'のATMパラメタは役に立つかもしれなくても、使用される(セクション4を見ます)シグナリングのタイプに頼っていません。 Multipoint ATM接続がマルチキャストの予約を写像するのに使用されるなら、これらのパラメタは特に、利用可能ではありません。
However, it would be possible to implement a multiplexing scheme to enable reservations to share bi-directional point-to-point ATM connections if the reservation agent creates a split/merge point at the ATM boundary and sets up only point-to-point VC connections to targets.
しかしながら、予約エージェントがATM境界で分裂/マージポイントを作成して、二地点間VC接続だけを目標にセットアップするなら、予約が双方向の二地点間ATM接続を共有するのを可能にするためにマルチプレクシング計画を実行するのは可能でしょう。
The CPCS-SDU parameters are AAL Parameters which are used by the AAL entity to break packets into cells. As such, these parameters are not modified by the network and could conceivably be used for additional end-to-end signaling, along with the B-LLI.
CPCS-SDUパラメタはAAL実体によって使用される、パケットをセルに細かく分けるAAL Parametersです。 そういうものとして、これらのパラメタは、ネットワークによって変更されないで、終わりから終わりへの追加シグナリングに多分使用されるかもしれません、B-LLIと共に。
Finally, QoS Class is somewhat limited in its use and implementation. While IP over ATM recommends use of Class 0 (Unspecified QoS), this is not sufficient for guaranteed connections. Instead, Class 1 with CLP=0 will provide at least minimum QoS services for the traffic.
最終的に、QoS Classはその使用と実現がいくらか限られています。 ATMの上のIPはClass0(不特定のQoS)の使用を推薦しますが、これは保証された接続では十分ではありません。 代わりに、CLP=0とClass1は交通のための少なくとも最小のQoSサービスを提供するでしょう。
5.1 CPCS-SDU Size Computation
5.1 CPCS-SDUサイズ計算
The CPCS-SDU size computation is the easiest QoS mapping. Since ST-2 does not require a Service Specific Convergence Sublayer (SSCS), if AAL 5 is used, the ST packet size plus 8 bytes (for the AAL 5 Trailer) will be the CPCS-SDU size. Note that the ST-2 packet size also includes an 8-byte header for ST-2. Thus the CPCS-SDU size is:
CPCS-SDUサイズ計算は最も簡単なQoSマッピングです。 AAL5が使用されているならST-2がService Specific Convergence Sublayer(SSCS)を必要としないので、STパケットサイズと8バイト(AAL5Trailerのための)はCPCS-SDUサイズになるでしょう。 また、ST-2パケットサイズがST-2のための8バイトのヘッダーを含んでいることに注意してください。 したがって、CPCS-SDUサイズは以下の通りです。
CPCS-SDUsize = PDUbytes + 8 + 8.
CPCS-SDUsize=PDUbytes+8+8。
For ST-2+, the header is larger than for ST-2, so the CPCS-SDU size is:
ST-2に関しては、+、ヘッダーがST-2より大きいので、CPCS-SDUサイズがあります:
CPCS-SDUsize = PDUbytes + 12 + 8.
CPCS-SDUsize=PDUbytes+12+8。
Jackowski Informational [Page 16] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[16ページ]のRFC1946のネイティブの気圧サポート
5.2 PCR Computation
5.2 PCR計算
The Peak Cell Rate (PCR) computation is only slightly more complex. The PCR will be the peak packet rate divided by the ATM payload size.
Peak Cell Rate(PCR)計算はわずかにだけ複雑です。 PCRはピークパケットレートになるでしょうATMペイロードサイズが割られた。
Since PDU rates in ST-2 are specified in tenths of packets per second, AAL 5 requires an 8 byte trailer, and the ATM payload size is 48 bytes, the computation for PCR proceeds as follows:
ST-2のPDUレートが1秒あたりのパケットの10分の1で指定されて、AAL5が8バイトのトレーラを必要として、ATMペイロードサイズが48バイトであるので、PCRのための計算は以下の通り続きます:
The requested maximum byte transmission rate for ST-2 is:
要求されたST-2に、最大のバイト通信速度は以下の通りです。
PDUbytes * PDUrate * 10.
PDUbytes*PDUrate*10。
Accounting for the AAL 5 and ST headers, the maximum byte rate
is:
AAL5とSTヘッダーの原因になって、最大のバイトレートは以下の通りです。
Bytes per second = (PDUbytes + 8 + 8) * PDUrate * 10.
1秒あたりのバイトは(PDUbytes+8+8)*PDUrate*10と等しいです。
Translating into cells and eliminating the possibility of a
fractional PDU:
セルへの翻訳と断片的なPDUの可能性を排除します:
PCR = ((PDUbytes + 8 + 8 + 48) / 48) * PDUrate * 10.
PCRは((PDUbytes+8+8+48)/48)*PDUrate*10と等しいです。
For ST-2+, not only is the header size 12 bytes, but the Rate is in messages per second, not tenths of packets per second. Thus, the PCR for ST-2+ is:
ST-2+に関しては、ヘッダーサイズが12バイトだけであるのではなく、Rateが1秒あたりのパケットの10分の1ではなく、1秒あたりのメッセージにあります。 したがって、ST-2+のためのPCRは以下の通りです。
PCR = ((PDUbytes + 12 + 8 + 48) / 48) * PDUrate.
PCRは((PDUbytes+12+8+48)/48)*PDUrateと等しいです。
5.3 Maximum End to End Transit Delay.
トランジット遅れを終わらせる5.3の最大の終わり。
The End to End Transit Delay is a little more complex. The requested end to end delay must account for not only the PDU size as requested by the user, but the additional 8-byte AAL 5 header as well. The translation of the user-requested LimitOn Delay is preserved as long as the delay computation is based on the CPCS-SDU size instead of the PDU size.
End Transit DelayへのEndはもう少し複雑です。 遅れを終わらせる要求された終わりは要求された通りしかし、ユーザ、また、追加8バイトのAAL5ヘッダーでPDUサイズだけを説明してはいけません。 遅れ計算がPDUサイズの代わりにCPCS-SDUサイズに基づいている限り、ユーザによって要求されたLimitOn Delayに関する翻訳は保存されます。
In addition to the end to end delay introduced by the ATM network, there is additional delay created by the fragmentation of packets. Reassembly of these packets can only be accomplished at the rate at which they are received. The time (in milliseconds) required to receive a cell (inter-cell arrival time) is:
ATMネットワークによって導入された遅れを終わらせる終わりに加えて、パケットの断片化で作成された追加遅れがあります。 それらが受け取られているレートでこれらのパケットのReassemblyを達成できるだけです。 セル(相互セル到着時間)を受けるのに必要である時間(ミリセカンドによる)は以下の通りです。
T = 1000 / PCR.
Tは1000 / PCRと等しいです。
Jackowski Informational [Page 17] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[17ページ]のRFC1946のネイティブの気圧サポート
The number of cells in a CPCS-SDU is:
CPCS-SDUのセルの数は以下の通りです。
C = (CPCS-SDUsize + 48) / 48.
C=(CPCS-SDUsize+48)/48。
Thus the delay for a packet is:
したがって、パケットのための遅れは以下の通りです。
LimitonDelay = (C - 1) * T + MaxCellTransitDelay.
LimitonDelayは*T+MaxCellTransitDelayと等しいです(C--1)。
Therefore, the requested Maximum End to End Transit delay is:
したがって、End Transit遅れへの要求されたMaximum Endは以下の通りです。
MaxCellTransitDelay = Limiton Delay - (C-1) * T.
MaxCellTransitDelayはLimiton遅れと等しいです--(C-1)*T。
5.4 Maximum Bit Error Rate
5.4 最大のビット誤り率
Q.2931 signaling does not offer the ability to directly specify the requested bit error rate or a corresponding cell error rate. Instead, this service is supposed to be offered through selection of QoS class.
Q.2931シグナリングは直接要求されたビット誤り率か対応するセル誤り率を指定する能力を提供しません。 代わりに、このサービスによってQoSのクラスの選択で提供されるべきです。
Since these classes have few actual implementations, at this time, there is no effective mapping for bit error rate.
これらのクラスにはわずかな実際の実現しかないので、このとき、ビット誤り率のためのどんな有効なマッピングもありません。
5.5 Accumulated Mean Delay
5.5 蓄積された意地悪な遅れ
ST allows accumulation of the Mean Delay generated by each ST agent node and intervening circuits. With an ATM circuit each agent should factor in the overhead of the ATM connection. The delay associated with the ATM circuit is reflected in the Q.2931 CONNECT message as the Cummulative Transit Delay. Since this is a cell-based computation, the delay experienced for an ST packet, including the CPCS-SDU header and ST header is, as computed in Section 5.3:
STはそれぞれのSTエージェントノードと介入しているサーキットで発生するMean Delayの蓄積を許します。 各エージェントがATM接続のオーバーヘッドで因数分解するべきであるATMサーキットで。 ATMサーキットに関連している遅れはCummulative Transit DelayとしてQ.2931 CONNECTメッセージに反映されます。 CPCS-SDUヘッダーとSTヘッダーを含むのは、そうです、STパケットのために経験された遅れ、これがセルベースの計算であるので、セクション5.3で計算されるように、計算します:
Delay = (C - 1) * T + CummulativeTransit Delay.
遅れは*T+CummulativeTransit遅れと等しいです(C--1)。
5.6 Accumulated Delay Variance (Jitter)
5.6 蓄積された遅れ変化(ジター)
Cell Delay Variance is not currently available as a Q.2931 parameter.
セルDelay Varianceは現在、Q.2931パラメタとして利用可能ではありません。
Thus, we can assume that the reassembly of cells into packets will be consistent, since the cell transmission rate should be constant for each packet. As such, except as noted by the specific ATM service, the ST agent should use its standard mechanisms for tracking packet arrival times and use this for Accumulated Delay Variance.
したがって、私たちは、パケットへのセルの再アセンブリが一貫すると思うことができます、各パケットに、セル通信速度が一定であるべきであるので。 そういうものとして、特定のATMサービスで注意されるのを除いて、STエージェントは、追跡パケット到着時間に標準のメカニズムを使用して、Accumulated Delay Varianceにこれを使用するべきです。
6.0 Data Stream Transmission
6.0 データ・ストリームトランスミッション
Once virtual circuits for data transmission are established though one of the mechanisms described in section 4, the ST data must be
セクション4、STデータで説明されたメカニズムの1つは確立しているに違いありませんが、一度、データ伝送のための仮想のサーキットはそうです。
Jackowski Informational [Page 18] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[18ページ]のRFC1946のネイティブの気圧サポート
transmitted over the connection. RFC 1483 describes mechanisms for encapsulating packet transmissions over AAL5. While the LLC encapsulation could be used, it is not necessary. If it is used, the computations in section 5 should be redone to include the LLC headers in addition to the AAL5 trailer currently used. These new values should be substituted for the QoS values in the SETUP message.
接続の上に伝えられます。 RFC1483は、AAL5の上にパケット伝送を要約するためにメカニズムについて説明します。 LLCカプセル化を使用できましたが、それは必要ではありません。 それが使用されているなら、セクション5での計算は、現在使用されているAAL5トレーラに加えてLLCヘッダーを含むようにやり直されるべきです。 SETUPメッセージのQoS値にこれらの新しい値を代入するべきです。
Instead, ST data packets can be encapsulated in standard AAL5 format with an 8 byte trailer and sent directly over the data virtual circuit. The mechanisms for computing the QoS values in the SETUP message are described in section 5.
代わりに、STデータ・パケットを8バイトのトレーラで標準のAAL5形式でカプセルに入れって、データの仮想のサーキットの直接上に送ることができます。 SETUPメッセージのQoS値を計算するためのメカニズムはセクション5で説明されます。
7.0 Implementation Experience and Conclusions
7.0 実現経験と結論
All of the signaling mechanisms described in Section 4 were implemented and tested in a mixed ATM network/routed LAN environment.
セクション4で説明されたシグナル伝達機構のすべてが、LAN環境を実行されて、複雑なATMネットワークでテストしたか、または発送しました。
Initially it appeared that the best approach was to do signaling via IP over ATM or LANE. However, because it required IP encapsulation of the SCMP packets (for IP over ATM), and because some applications use the accumulated values in the flowspecs (which are not guaranteed to be accurate in LANE and IP/ATM), using virtual circuits dedicated to SCMP signaling turned out to be the best implementation for taking full advantage of the ATM features.
初めは、最も良いアプローチがATMかレインの上のIPを通してシグナリングをすることであるように見えました。 しかしながら、SCMPパケットのIPカプセル化を必要として(ATMの上のIPのために)、いくつかのアプリケーションがflowspecsで蓄積された値を使用するので(正直なところレインとIP/ATMで保証されません)、SCMPシグナリングに捧げられた仮想のサーキットを使用するのはATMの特徴を最大限に利用するための最も良い実現であると判明しました。
Also, the issue of mapping ATM address to E.164 NSAP addresses was resolved through an external signaling mechanism (the User Data field of the ST-2 CONNECT and ACCEPT messages). It appears that ATM vendors need to implement a consistent addressing mechanism throughout their interfaces.
また、E.164 NSAPアドレスへのマッピングATMアドレスの問題は外部のシグナル伝達機構(通り-2CONNECTとACCEPTメッセージのUser Data分野)を通して解決されました。 ATM業者が、彼らのインタフェース中で一貫したアドレシングメカニズムを実行する必要なように見えます。
From a performance point of view, using ST over ATM provided more than triple the performance of raw IP. The differences became increasingly clear as more simultaneous applications were run. This resulted in dedicated virtual circuits for the ST traffic while the IP traffic suffered (saw inconsistent performance) over shared circuits. Even more dramatic were results in mixed network environments where all traffic shared the same LAN/router connections, and, when both IP and ST traffic was sent, the ST traffic maintained its quality while the IP traffic saw increasing variation in performance.
性能観点から、ATMの上でSTを使用すると、生のIPの性能はより多くの三重に提供されました。 より同時のアプリケーションが実行されたとき、違いはますます明確になりました。 IP交通に共有されたサーキットに関して苦しみましたが(無節操な性能を見ました)、もたらされるこれは仮想のサーキットをST交通に捧げました。 IP交通は性能の増加する変化を見ましたが、さらに劇的であるのは、すべての交通が同じLAN/ルータ接続、およびIPとST交通の両方を送ったときの品質であることが支持されたST交通を共有した混合ネットワーク環境において結果でした。
Clearly, using a connection-oriented, origin-oriented reservation protocol to provide consistent end-to-end guaranteed QoS and bandwidth in mixed ATM/internet environments is not only feasible, it results in dramatic performance and quality improvements for transmission of realtime traffic.
明確に、終わりから終わりへの一貫した保証されたQoSと帯域幅を複雑なATM/インターネット環境に供給するのに接続指向の、そして、起源指向の予約プロトコルを使用するのが可能であるだけではない、それはリアルタイムで交通の送信のための演芸と品質改良をもたらします。
Jackowski Informational [Page 19] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[19ページ]のRFC1946のネイティブの気圧サポート
8.0 Security Considerations
8.0 セキュリティ問題
This memo raises no security considerations. However, with their connection-oriented and origin controlled natures, ST-2 and ST-2+ lend themselves to better internet security. Discussion of this is beyond the scope of this document.
このメモはセキュリティ問題を全く提起しません。 しかしながら、彼らの接続指向と起源の制御本質と共に、ST-2とST-2+は、より良いインターネットセキュリティに自分たちを与えます。 この議論はこのドキュメントの範囲を超えています。
9.0 References
9.0の参照箇所
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett
Packard Laboratories, December, 1993.
[1]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、ヒューレットパッカード研究所12月、1993
[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
of Real-time Services in an IP-ATM network Architecture", RFC
1821, August 1995.
[2]ボーデン、M.、クローリー、E.、デイビー、B.、およびS.Batsell、「IP-ATMネットワークArchitectureのレアル-時間Servicesの統合」、RFC1821(1995年8月)。
[3] Braden, R., Zhang, L., Estrin, D., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP Version 1 Functional
Specification", Work in Progress, November 1995.
[3] ブレーデン、R.、チャン、L.、Estrin、D.、ハーツォグ、S.、およびS.ジャマン、「資源予約プロトコル、(RSVPバージョン1の機能的な仕様、」、進行中(1995年11月)では、働いてください。
[4] Topolcic, C., "Experimental Internet Stream Protocol: Version 2
(ST-II)", RFC 1190, October 1990.
[4]Topolcic、C.、「実験的なインターネットの流れは以下について議定書の中で述べます」。 「バージョン2、(第-、II、)、」、RFC1190、10月1990日
[5] DelGrossi, L., and L. Berger, "Internet STream Protocol Version
2+", RFC 1819, July 1995.
[5] DelGrossi、L.、およびL.バーガー、「インターネット流れのプロトコルバージョン2+」、RFC1819、1995年7月。
[6] V. Firoiu, R. Guerin, D. Kandlur, A. Birman "Provisioning of
RSVP-based Services over a Large ATM Network', IBM T.J. Watson
Research Center, October 1995.
'[6] V.Firoiu、R.ゲラン、D.Kandlur、「大きい気圧ネットワークの上のRSVPベースのサービスの食糧を供給する'A.バーマンIBM T.J.ワトソン研究所(1995インチ年10月)。
[7] S. Damaskos, A. Anastassios Gavras, "Connection Oriented
Protocols over ATM: A Case Study", German National Research
Corporation for Mathematics and Data Processing (GMD) and
Research Centre for Open Communications Systems (FOKUS), February
1994.
[7] S.Damaskos、A.Anastassios Gavras、「接続は気圧でプロトコルを適応しました」。 「ケーススタディ」、(GMD)と研究がオープンコミュニケーションシステム(FOKUS)、1994年2月に集中させる数学とデータ処理のためのドイツの国家の研究社。
[8] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[8] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[9] M. Graf, T. Kober, H. Stuttgen, "ST-II over ATM Implementation
Issues", IBM European Networking Center, October 1995.
[9] M.グラフ、T.コーバー、H.シュトゥットゲン、「第-、II、IBMのヨーロッパ人がセンターをネットワークでつなぐ10月1995日以上気圧導入問題」
Jackowski Informational [Page 20] RFC 1946 Native ATM Support for ST2+ May 1996
1996年ST2+5月のJackowskiの情報[20ページ]のRFC1946のネイティブの気圧サポート
10.0 Author's Address
10.0 作者のアドレス
Steve Jackowski
NetManage Incorporated
269 Mt. Hermon Road, Suite 201
Scotts Valley, Ca 95066
スティーブJackowski NetManageは269Hermon Road山、スイート201Scottsバレー、Ca95066を組み込みました。
Phone: (408) 439-6834
Fax: (408) 438-5115
EMail: Stevej@NetManage.com
以下に電話をしてください。 (408) 439-6834 Fax: (408) 438-5115 メールしてください: Stevej@NetManage.com
Jackowski Informational [Page 21]
Jackowski情報です。[21ページ]
一覧
スポンサーリンク
