RFC2383 日本語訳
2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M.Suzuki. August 1998. (Format: TXT=99889 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Suzuki Request for Comments: 2383 NTT Category: Informational August 1998
コメントを求めるワーキンググループM.鈴木の要求をネットワークでつないでください: 2383年のNTTカテゴリ: 情報の1998年8月
ST2+ over ATM
Protocol Specification - UNI 3.1 Version
気圧プロトコル仕様の上のST2+--UNI3.1バージョン
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document specifies an ATM-based protocol for communication between ST2+ agents. The ST2+ over ATM protocol supports the matching of one hop in an ST2+ tree-structure stream with one ATM connection. In this document, ATM is a subnet technology for the ST2+ stream.
このドキュメントはST2+エージェントのコミュニケーションにATMベースのプロトコルを指定します。 ATMの上のST2+はST2+木構造におけるワンバウンドのマッチングが1つのATM接続と共に流すサポートについて議定書の中で述べます。 本書では、ATMはST2+ストリームのためのサブネット技術です。
The ST2+ over ATM protocol is designed to achieve resource- reservation communications across ATM and non-ATM networks, to extend the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ signaling limitations.
ATMプロトコルの上のST2+は、ATMと非ATMネットワークの向こう側にリソース予約コミュニケーションを達成して、機能を示すUNI3.1/4.0を広げて、制限に合図するUNI4.0LIJを減少させるように設計されています。
The specifications of the ST2+ over ATM protocol consist of a revision of RFC 1819 ST2+ and specifications of protocol interaction between ST2+ and ATM on the user plane, management plane, and control plane which correspond to the three planes of the B-ISDN protocol reference model.
ATMプロトコルの上のST2+の仕様はRFC1819ST2+の改正とB-ISDNプロトコル規範モデルの3機の飛行機に対応するユーザ飛行機、管理飛行機、および制御飛行機の上のST2+とATMとのプロトコル相互作用の仕様から成ります。
1. Introduction
1. 序論
1.1 Purpose of Document
1.1 ドキュメントの目的
The purpose of this document is to specify an ATM-based protocol for communication between ST2+ agents.
このドキュメントの目的はST2+エージェントのコミュニケーションにATMベースのプロトコルを指定することです。
The ST2+ over ATM protocol is designed to support the matching of one hop in an ST2+ tree-structure stream with one ATM connection; it is not designed to support an entire ST2+ tree-structure stream with a point-to-multipoint ATM connection only.
ATMプロトコルの上のST2+は1つのATM接続に伴うST2+木構造ストリームにおけるワンバウンドのマッチングをサポートするように設計されています。 それは、ポイントツーマルチポイントATM接続だけと共に全体のST2+木構造ストリームをサポートするように設計されていません。
Suzuki Informational [Page 1] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[1ページ]のRFC2383ST2+
Therefore, in this document, ATM is only a subnet technology for the ST2+ stream. This specification is designed to enable resource- reservation communications across ATM and non-ATM networks.
したがって、本書では、ATMはST2+ストリームのためのサブネット技術にすぎません。 この仕様は、ATMと非ATMネットワークの向こう側にリソース予約コミュニケーションを可能にするように設計されています。
1.2 Features of ST2+ over ATM Protocol
気圧でのST2+の1.2の特徴が議定書を作ります。
o Enables resource-reservation communications across ATM and non-ATM
networks.
o ATMと非ATMネットワークの向こう側に資源予約コミュニケーションを可能にします。
ATM native API supports resource-reservation communications only
within an ATM network; it cannot support interworking with non-ATM
networks. This is because
ATMのネイティブのAPIは、ATMネットワークだけの中で資源予約がコミュニケーションであるとサポートします。 それは非ATMネットワークによる織り込むことをサポートすることができません。 これはそうです。
- ATM native API cannot connect terminals without an ATM interface.
- ATMのネイティブのAPIはATMインタフェースなしで端末をつなげることができません。
- ATM native API does not support IP addressing and SAP (port)
addressing systems.
- ATMのネイティブのAPIは、IPアドレシングとSAP(ポート)がアドレス指定方式であるとサポートしません。
o Extends UNI 3.1/4.0 signaling functions.
o 機能を示すUNI3.1/4.0を広げています。
ST2+ SCMP supports MTU-size negotiation at all hops in an ST2+
tree-structure stream. UNI 3.1/4.0 supports only max CPCS_SDU
(i.e., MTU) negotiation with the called party of a point-to-point
call or with the first leaf of a point-to-multipoint call.
ST2+SCMPは、すべてのホップでST2+木構造ストリームでMTU-サイズが交渉であるとサポートします。 UNI3.1/4.0は、唯一の最大CPCS_SDU(すなわち、MTU)が二地点間呼び出しの被呼者かポイントツーマルチポイント呼び出しの最初の葉との交渉であるとサポートします。
o Reduces UNI 4.0 LIJ signaling limitations.
o 制限に合図するUNI4.0LIJを減少させます。
The ST2+ over ATM protocol supports UNI 4.0 LIJ Call Identifier
notification from the root to the leaf by using an ST2+ SCMP
extension. LIJ Call Identifier discovery at the leaf is one of the
major unsolved problems of UNI 4.0, and the ST2+ over ATM protocol
provides a solution.
ATMプロトコルの上のST2+は、根から葉までUNI4.0がLIJ Call Identifier通知であるとST2+SCMP拡張子を使用することによって、サポートします。 葉でのLIJ Call Identifier発見はUNI4.0の主要な未解決の問題、およびATMプロトコルの上の+が解決法を供給するST2の1つです。
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
support the above feature. It will be supported by the UNI 3.1/4.0
version.
以下に注意してください。 ATMプロトコルの上の+が上記の特徴をサポートしないST2のUNI3.1バージョン。 それはUNI3.1/4.0バージョンによってサポートされるでしょう。
1.3 Goals and Non-goals of ST2+ over ATM Protocol
気圧でのST2+の1.3の目標と非目標は議定書を作ります。
The ST2+ over ATM protocol is designed to achieve the following goals.
ATMプロトコルの上のST2+は、以下の目標を達成するように設計されています。
o Specify protocol interaction between ST2+ [4] and ATM on the ATM
Forum Private UNI 3.1/4.0 (Sb point) [10, 11].
o ATM Forum兵士のUNI3.1/4.0(Sbポイント)[10、11]でST2+[4]とATMとのプロトコル相互作用を指定してください。
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
support UNI 4.0. It will be supported by the UNI 3.1/4.0 version.
以下に注意してください。 ATMプロトコルの上の+がUNI4.0をサポートしないST2のUNI3.1バージョン。 それはUNI3.1/4.0バージョンによってサポートされるでしょう。
Suzuki Informational [Page 2] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[2ページ]のRFC2383ST2+
o Support ST2+ stream across ATM and non-ATM networks.
o ATMと非ATMネットワークの向こう側にST2+ストリームをサポートしてください。
o Define one VC on the UNI corresponding to one ST2+ hop; this VC is
not shared with other ST2+ hops, and also this ST2+ hop is not
divided into multiple VCs.
o 1つのST2+ホップに対応するUNIの上の1VCを定義してください。 このVCは他のST2+ホップと共有されません、そして、また、このST2+ホップは複数のVCsに分割されません。
o Support both SVC and PVC.
o SVCとPVCの両方をサポートしてください。
o Not require any ATM specification changes.
o 仕様が変えるどんなATMも必要ではありません。
o Coexist with RFC 1483 [16] IPv4 encapsulation.
o RFC1483[16]IPv4カプセル化と共存してください。
o Coexist with RFC 1577 [17] ATMarp.
o RFC1577[17]ATMarpと共存してください。
o Coexist with RFC 1755 [18] ATM signaling for IPv4.
o IPv4のために合図するRFC1755[18]ATMに共存してください。
o Coexist with NHRP [19].
o NHRP[19]と共存してください。
Because ST2+ is independent of both routing and IP address resolution protocols, the ST2+ over ATM protocol does not specify the following protocols.
ST2+がルーティングとIPアドレス解決プロトコルの両方から独立しているので、ATMプロトコルの上の+がするST2は以下のプロトコルを指定しません。
o IP-ATM address resolution protocol
o IP-ATMアドレス解決プロトコル
o Routing protocol
o ルーティング・プロトコル
Because the ST2+ over ATM protocol is specified for the UNI, it is independent of:
ATMプロトコルの上のST2+がUNIに指定されるので、それは以下から独立しています。
o NNI protocol
o NNIプロトコル
o Router/switch architecture
o ルータ/スイッチアーキテクチャ
Suzuki Informational [Page 3] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[3ページ]のRFC2383ST2+
2. Protocol Architecture
2. プロトコルアーキテクチャ
The ST2+ over ATM protocol specifies the interaction between ST2+ and ATM on the user, management, and control planes, which correspond to the three planes in ITU-T Recommendation I.321 B-ISDN Protocol Reference Model [14].
ATMプロトコルの上のST2+はITU-T Recommendation I.321B-ISDNプロトコルReference Model[14]の3機の飛行機に対応するユーザ、管理、および制御飛行機の上のST2+とATMとの相互作用を指定します。
2.1 User Plane Architecture
2.1 ユーザ飛行機アーキテクチャ
The user plane specifies the rules for encapsulating the ST2+ Data PDU into the AAL5 [15] PDU. An user plane protocol stack is shown in Fig. 2.1.
ユーザ飛行機はST2+データPDUをAAL5[15]PDUにカプセル化するための規則を指定します。 ユーザ飛行機プロトコル・スタックは図2.1に示されます。
+---------------------------------+
| RFC 1819 ST2+ |
| (ST2+ Data) |
+---------------------------------+ Point of ST2+ over ATM
|/////////////////////////////////| <--- protocol specification of
+---------------------------------+ user plane
| |
| |
| I.363.5 |
| |
| AAL5 |
| |
| |
+---------------------------------+
| I.361 ATM |
+---------------------------------+
| PHY |
+----------------+----------------+
| UNI
+--------||-------
+---------------------------------+ | RFC1819ST2+| | (ST2+データ) | +---------------------------------+ 気圧でのST2+の先|/////////////////////////////////| <-- +に関するプロトコル仕様---------------------------------+ ユーザ飛行機| | | | | I.363.5| | | | AAL5| | | | | +---------------------------------+ | I.361気圧| +---------------------------------+ | PHY| +----------------+----------------+ | UNI+--------||-------
Fig. 2.1: User plane protocol stack.
図2.1: ユーザ飛行機プロトコル・スタック。
Suzuki Informational [Page 4] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[4ページ]のRFC2383ST2+
An example of interworking from an ATM network to an IEEE 802.X LAN is shown in Fig. 2.2.
ATMネットワークからIEEE 802.X LANまで織り込むのに関する例は図2.2に示されます。
ST2+ ST2+ ST2+
Origin ATM Cloud Intermediate Agent Target
+---------+ +---------+
| AP |--------------------------------------------->| AP |
+---------+ +-------------------+ +---------+
|ST2+ Data|------------------>| RFC 1819 ST2+ Data|----->|ST2+ Data|
+---------+ +---------+---------+ +---------+
|I.363 AAL|------------------>|I.363 AAL| SNAP |----->| SNAP |
+---------+ +---------+ +---------+---------+ +---------+
|I.361 ATM|--->|I.361 ATM|--->|I.361 ATM| LLC |----->| LLC |
+---------+ +---------+ +---------+---------+ +---------+
| | | | | |IEEE802.X| |IEEE802.X|
| PHY |--->| PHY |--->| PHY | & 802.1p|----->| & 802.1p|
+---------+ +---------+ +---------+---------+ +---------+
ST2+ST2+ST2+発生源気圧雲の仲介物質目標+---------+ +---------+ | AP|--------------------------------------------->| AP| +---------+ +-------------------+ +---------+ |ST2+データ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| RFC1819ST2+データ|、-、-、-、--、>|ST2+データ| +---------+ +---------+---------+ +---------+ |I.363 AAL|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|I.363 AAL| スナップ|、-、-、-、--、>| スナップ| +---------+ +---------+ +---------+---------+ +---------+ |I.361気圧|、-、--、>|I.361気圧|、-、--、>|I.361気圧| LLC|、-、-、-、--、>| LLC| +---------+ +---------+ +---------+---------+ +---------+ | | | | | |IEEE802.X| |IEEE802.X| | PHY|、-、--、>| PHY|、-、--、>| PHY| 802.1p|、-、-、-、--、>| 802.1p| +---------+ +---------+ +---------+---------+ +---------+
Fig. 2.2: Example of interworking from
an ATM network to an IEEE 802.X LAN.
図2.2: ATMネットワークからIEEE 802.X LANまで織り込むのに関する例。
The ATM cell supports priority indication using the CLP field; indication is also supported by the ST2+ Data PDU by using the Pri field. It may be feasible to map these fields to each other. The ST2+ over ATM protocol specifies an optional function that maps the Pri field in the ST header to the CLP field in the ATM cell. However, implementors should note that current ATM standardization tends not to support tagging.
ATMセルは、優先権が指示であることをCLP分野を使用することで支えます。 また、指示は、Pri分野を使用することによって、ST2+データPDUによってサポートされます。 これらの分野を互いに写像するのは可能であるかもしれません。 ATMプロトコルの上のST2+はSTヘッダーのPri分野をATMセルのCLP分野に写像する任意の機能を指定します。 しかしながら、作成者は、現在のATM標準化が、タグ付けをサポートしない傾向があることに注意するべきです。
Suzuki Informational [Page 5] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[5ページ]のRFC2383ST2+
2.2 Management Plane Architecture
2.2 管理飛行機アーキテクチャ
The management plane specifies the Null FlowSpec, the Controlled-Load Service [5] FlowSpec, and the Guaranteed Service [6] FlowSpec mapping rules [8] for UNI 3.1 traffic management. A management plane protocol stack is shown in Fig. 2.3.
管理飛行機はNull FlowSpec、Controlled-負荷Service[5]FlowSpec、およびGuaranteed Service[6]FlowSpec配置規則[8]をUNI3.1輸送管理に指定します。 管理飛行機プロトコル・スタックは図2.3に示されます。
+---------------------------------+ | Null FlowSpec | |Controlled-Load Service FlowSpec | | Guaranteed Service FlowSpec | +---------------------------------+ Point of ST2+ over ATM |/////////////////////////////////| <--- protocol specification of +---------------------------------+ management plane | | | UNI 3.1 | | | | | | Traffic Management | | | | | | VBR/UBR | | | +---------------------------------+
+---------------------------------+ | ヌルFlowSpec| |制御負荷サービスFlowSpec| | 保証されたサービスFlowSpec| +---------------------------------+ 気圧でのST2+の先|/////////////////////////////////| <-- +に関するプロトコル仕様---------------------------------+ 管理飛行機| | | UNI3.1| | | | | | 輸送管理| | | | | | VBR/UBR| | | +---------------------------------+
Fig. 2.3: Management plane protocol stack.
図2.3: 管理飛行機プロトコル・スタック。
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not support Guaranteed Services. It will be supported by the UNI 3.1/4.0 version.
以下に注意してください。 ATMプロトコルの上の+がGuaranteed ServicesをサポートしないST2のUNI3.1バージョン。 それはUNI3.1/4.0バージョンによってサポートされるでしょう。
The ST2+ over ATM protocol specifies the ST FlowSpec format for the Integrated Services. Basically, FlowSpec parameter negotiation, except for the MTU, is not supported. This is because, in the ST2+ environment, negotiated FlowSpec parameters are not always unique to each target. The current ATM standard does not support heterogeneous QoS to receivers.
ATMプロトコルの上のST2+はST FlowSpec形式をIntegrated Servicesに指定します。 基本的に、MTU以外に、FlowSpecパラメタ交渉はサポートされません。 これはST2+環境で、交渉されたFlowSpecパラメタがいつも各目標にユニークであるというわけではないからです。 現在のATM規格は異種のQoSを受信機にサポートしません。
The ST2+ over ATM protocol supports FlowSpec changes by using the CHANGE message (RFC 1819, Section 4.6.5) if the I-bit in the CHANGE message is set to one and if the CHANGE message affects all targets in the stream. This is because the UNI 3.1 does not support QoS changes. The ST2+ over ATM protocol supports FlowSpec changes by releasing old ATM connections and establishing new ones.
ATMプロトコルの上のST2+は、CHANGEメッセージのI-ビットが1つに設定されて、CHANGEメッセージがストリームですべての目標に影響するならCHANGEメッセージ(RFC1819、セクション4.6.5)を使用することによって、FlowSpecに変化をサポートします。 これはUNI3.1が、QoSが変化であるとサポートしないからです。 ATMプロトコルの上のST2+は、年取ったATM接続を釈放して、新しいものを確立することによって、FlowSpecに変化をサポートします。
The ST2+ over ATM protocol does not support stream preemption (RFC 1819, Section 6.3). This is because the Integrated Services FlowSpec does not support the concept of precedence.
ATMプロトコルの上の+がするST2は、ストリーム先取りが(RFC1819、セクション6.3)であるとサポートしません。 これはIntegrated Services FlowSpecが先行の概念をサポートしないからです。
Suzuki Informational [Page 6] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[6ページ]のRFC2383ST2+
It does not support the ST2+ FlowSpec (RFC 1819, Section 9.2). ST2+ FlowSpec specifies useful services, but requires a datalink layer to support heterogeneous QoS to receivers. The current ATM standard does not support heterogeneous QoS to receivers.
それは、ST2+FlowSpecが(RFC1819、セクション9.2)であるとサポートしません。 ST2+FlowSpecは、異種のQoSを受信機にサポートするために役に立つサービスを指定しますが、データリンク層を必要とします。 現在のATM規格は異種のQoSを受信機にサポートしません。
2.3 Control Plane Architecture
2.3 規制飛行機アーキテクチャ
The control plane specifies the rules for encapsulating the ST2+ SCMP PDU into the AAL5 [15] PDU, the relationship between ST2+ SCMP and PVC management for ST2+ data, and the protocol interaction between ST2+ SCMP and UNI 3.1 signaling [10]. A control plane protocol stack is shown in Fig. 2.4.
制御飛行機はAAL5[15]へのST2+SCMP PDUがPDUと、ST2+データのためのST2+SCMPとPVC管理との関係と、[10]に合図するST2+SCMPとUNI3.1とのプロトコル相互作用であるとカプセル化するための規則を指定します。 コントロール飛行機プロトコル・スタックは図2.4に示されます。
+---------------------------------+
| RFC 1819 ST2+ |
| (ST2+ SCMP) |
+---------------------------------+ Point of ST2+ over ATM
|/////////////////////////////////| <--- protocol specification of
+------------+---+----------------+ control plane
| IEEE 802 | |UNI3.1 Signaling|
| SNAP | +----------------+
+------------+ | Q.2130 SSCF |
| ISO 8802-2 | +----------------+
| LLC Type1 | | Q.2110 SSCOP |
+------------+ +----------------+
| I.363.5 AAL5 |
+---------------------------------+
| I.361 ATM |
+---------------------------------+
| PHY |
+----------------+----------------+
| UNI
+--------||-------
+---------------------------------+ | RFC1819ST2+| | (ST2+SCMP) | +---------------------------------+ 気圧でのST2+の先|/////////////////////////////////| <-- +に関するプロトコル仕様------------+---+----------------+ 制御飛行機| IEEE802| |UNI3.1シグナリング| | スナップ| +----------------+ +------------+ | Q.2130 SSCF| | ISO8802-2| +----------------+ | LLC Type1| | Q.2110 SSCOP| +------------+ +----------------+ | I.363.5 AAL5| +---------------------------------+ | I.361気圧| +---------------------------------+ | PHY| +----------------+----------------+ | UNI+--------||-------
Fig. 2.4: Control plane protocol stack.
図2.4: 飛行機プロトコル・スタックを制御してください。
The ST2+ over ATM protocol does not cover a VC (SVC/PVC) that transfers ST2+ SCMP. VCs for IPv4 transfer may be used for ST2+ SCMP transfer, and implementations may provide particular VCs for ST2+ SCMP transfer. Selection of these VCs depends on the implementation.
ATMプロトコルの上の+がするST2はST2+SCMPを移すVC(SVC/PVC)をカバーしていません。 IPv4転送のためのVCsはST2+SCMP転送に使用されるかもしれません、そして、実装はST2+SCMP転送に特定のVCsを提供するかもしれません。 これらのVCsの品揃えは実装によります。
Implementors should note that when ST2+ data and SCMP belong to a stream, the routing directions on the ST2+ layer must be the same. Implementors should also note that ST2+ and IPv4 directions for routing to the same IP destination address are not always the same.
作成者は、ST2+データとSCMPがストリームに属すとき、ST2+層のルーティング方向が同じであるに違いないことに注意するべきです。 また、作成者は、同じIPの目的地へのルーティングのための+とIPv4方向が扱うST2がいつも同じであるというわけではないことに注意するべきです。
Suzuki Informational [Page 7] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[7ページ]のRFC2383ST2+
The ST2+ over ATM protocol supports both SVC and PVC for ST2+ Data PDU transfer. If SVC is used, the ST2+ and ATM layers establish a connection sequentially by using respectively ST2+ SCMP and UNI 3.1 signaling. An example of ST2+ SCMP and UNI 3.1 signaling message flows for establishing and releasing of ST2+ data connections is shown in Fig. 2.5, where (S) means an ST2+ entity and (Q) means a UNI 3.1 signaling entity.
ATMの上のST2+はSVCとST2+データPDUのためのPVCの両方が移すサポートについて議定書の中で述べます。 SVCが使用されていて、ST2が+であり、ATMが層であるなら、それぞれST2+SCMPとUNI3.1シグナリングを使用することによって、連続して取引関係を築いてください。 ST2+SCMPとUNI3.1シグナリングメッセージに関する例は設立のために流れます、そして、ST2+データ接続の解放は図2.5に示されます、そして、(Q)はUNI3.1シグナリング実体を意味します。(そこでは、(S)がST2+実体を意味します)。
ATM SW ATM SW
+------------+ UNI +----+ NNI +----+ UNI +------------+
____|Intermediate|--||--| \/ |______| \/ |--||--|Intermediate|____
| (Upstream) | | /\ | | /\ | |(Downstream)|
+------------+ +----+ +----+ +------------+
SCMP
------->(S)<------------------------------------------>(S)<-------
\ UNI Sig. UNI Sig. /
CONNECT | (Q)<--------->(Q)<-------->(Q)<--------->(Q) |
-------->| |
ACK <----|--------------------CONNECT------------------>| CONNECT
|<---------------------ACK---------------------|-------->
| |<--- ACK
| | ACCEPT
| |<--------
|<-------------------ACCEPT--------------------|---> ACK
|----------------------ACK-------------------->|
| |
|->|----SETUP--->| | | |
| |<-CALL PROC--|----------->|----SETUP--->|->|
| | | |<----CONN----|<-|
ACCEPT | |<----CONN----|<-----------|--CONN ACK-->|->|
<--------|<-|--CONN ACK-->| | | |
ACK ---->| |
| |
-------\ |--------------------------------------------\ |-------\
>| ST2+ Data >| >
-------/ |--------------------------------------------/ |-------/
| |
DISCONN | |
-------->| |
ACK <----|-------------------DISCONNECT---------------->|
|<---------------------ACK---------------------|
| |
|->|---RELEASE-->| | | |
|<-|<--REL COMP--|----------->|---RELEASE-->|->| DISCONN
| | | |<--REL COMP--|<-|-------->
| |<--- ACK
気圧SW気圧SW+------------+ UNI+----+ NNI+----+ UNI+------------+ ____|中間的|--||--| \/ |______| \/ |--||--|中間的|____ | (上流) | | /\ | | /\ | |(川下)| +------------+ +----+ +----+ +------------+ SCMP------->(S)<------------------------------------------>(S)<、-、-、-、-、-、-- \UNI Sig。 UNI Sig。 /は接続します。| (Q)<、-、-、-、-、-、-、-、-->(Q)<、-、-、-、-、-、-、-->(Q)<、-、-、-、-、-、-、-、-->(Q) | -------->|、| ACK<。----|--------------------接続してください。------------------>| 接続してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ACK---------------------|、-、-、-、-、-、-、--、>| | <、-、-- ACK| | 受け入れてください。| | <、-、-、-、-、-、-、-- | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--受け入れてください。--------------------|--->ACK|----------------------ACK-------------------->|、|、| |、-、>|、-、-、--セットアップ--->|、|、|、|、| | <、-PROCに電話をしてください--|、-、-、-、-、-、-、-、-、-、--、>|、-、-、--セットアップ--->|、-、>|、|、|、| | <、-、-、--コン----| <、-、| 受け入れてください。| | <、-、-、--コン----| <、-、-、-、-、-、-、-、-、-、--、|、--コンACK-->|、-、>| <、-、-、-、-、-、-、--、| <、-、|、--コンACK-->|、|、|、| ACK---->|、|、|、| -------\ |--------------------------------------------\ |-------\ >| ST2+データ>| >。-------/ |--------------------------------------------/ |-------/ | | DISCONN| | -------->|、| ACK<。----|-------------------分離---------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ACK---------------------| | | |、-、>|、-、--リリース-->|、|、|、| | <、-、| <--RELコンピュータ--|、-、-、-、-、-、-、-、-、-、--、>|、-、--リリース-->|、-、>| DISCONN| | | | <--RELコンピュータ--| <、-、|、-、-、-、-、-、-、--、>| | <、-、-- ACK
Fig. 2.5: Example of ST2+ SCMP and UNI 3.1 signaling message flows.
図2.5: ST2+SCMPとUNI3.1シグナリングメッセージに関する例は流れます。
Suzuki Informational [Page 8] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[8ページ]のRFC2383ST2+
UNI 3.1/4.0 specifies PVC, point-to-point SVC, and point-to- multipoint SVC as VC styles. However, in actual ATM network environments, especially public ATM WANs, only PVC and bi-directional point-to-point SVC may be supported. To support the diverse VC styles, the ST2+ over ATM protocol supports the following VC styles for ST2+ Data PDU transfer.
UNI3.1/4.0はVCスタイルとしてPVC、ポイントツーポイントSVC、およびポイントから多点へのSVCを指定します。 しかしながら、実際のATMネットワーク環境で、特に公共のATM WAN、PVC、および双方向のポイントツーポイントSVCだけを支持してもよいです。 さまざまのVCスタイル、ST2を支持するために、ATMプロトコルの上の+はST2+データPDUのためのスタイルが移す以下のVCを支持します。
o PVC
o PVC
o Reuse of reverse channel of bi-directional point-to-point SVC that
is used by existing stream.
o 既存の流れで使用される双方向のポイントツーポイントSVCの逆のチャンネルの再利用。
o Point-to-point SVC initiated from upstream side.
o 上流から開始されたポイントツーポイントSVCは面があります。
o Point-to-multipoint SVC initiated from upstream side.
o 上流から開始されたポイントツーマルチポイントSVCは面があります。
o Point-to-point SVC initiated from downstream side.
o 川下から開始されたポイントツーポイントSVCは面があります。
o Point-to-multipoint SVC initiated from downstream side (LIJ).
o ポイントツーマルチポイントSVCは川下側から(LIJ)を開始しました。
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
support LIJ. LIJ will be supported by the UNI 3.1/4.0 version.
以下に注意してください。 サポートLIJではなく、ATMプロトコルの上の+がするST2のUNI3.1バージョン。 LIJはUNI3.1/4.0バージョンによって支持されるでしょう。
The second style is needed in environments supporting bi-directional point-to-point SVC only. The selection of PVC and SVC styles in the ST2+ agent is based on preconfigured implementation-dependent rules.
2番目のスタイルが双方向のポイントツーポイントSVCだけを支持する環境で必要です。 ST2+エージェントのPVCとSVCスタイルの品揃えはあらかじめ設定された実現依存する規則に基づいています。
SVC supports both upstream and downstream call initiation styles. Implementors should note that this is independent of the sender- oriented and receiver-oriented ST2+ stream-building process (RFC 1819, Section 4.1.1). This is because the ST2+ over ATM protocol specifies the process for establishing ST2+ data hops on the UNI, and because the ST2+ stream building process belongs to another layer. The SVC initiation side should be determined based on the operational and billing policies between ST2+ agents; this is basically independent of the sender-oriented and receiver-oriented ST2+ stream-building process.
SVCは上流の、そして、川下の両方の呼び出し開始スタイルを支持します。 作成者は、これが流れ送付者の指向の、そして、受信機指向のST2+建築の過程(RFC1819、セクション4.1.1)から独立していることに注意するべきです。 これはATMプロトコルの上の+がST2+データを確立しながら過程を指定するST2がUNIに跳び乗って、ST2+流れの建築の過程が別の層に属すからです。 SVC開始側はST2+エージェントの間の操作上と支払い方針に基づいて決定しているべきです。 これは送付者指向の、そして、受信機指向の流れST2+建築の過程から基本的に独立しています。
Suzuki Informational [Page 9] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[9ページ]のRFC2383ST2+
An example of ST2+ SCMP interworking is shown in Fig. 2.6.
ST2+SCMPの織り込むのに関する例は図2.6に示されます。
_____
/ \
(Origin )
\ /
A ~~|~~ A
| = | UNI Signaling
| | |
| +-+-+ V
| | X | ATM SW
| +-+-+ A
SCMP | | | NNI Signaling
| +-+-+ V
| | X | ATM SW
| +-+-+ A
| | |
| = | UNI Signaling
V | V
+-----+------+ IEEE 802.X & 802.1p
| |<---------------------+
|Intermediate|--------------------+ |
| |<-----------------+ | |
+------------+ L2 Signaling| | |
A | A | | |
| = | UNI Signaling | | | SCMP
| | | | | |
| +-+-+ V | | |
| | X | ATM SW V | |
| +-+-+ A +---+-|-+
SCMP | | | NNI Signaling | \ /| |
| +-+-+ V | X | |LAN SW
| | X | ATM SW | / \| |
| +-+-+ A +---+-|-+
| | | A | |
| = | UNI Signaling | | |
V __|__ V V_|_V
/ \ / \
(Target ) (Target )
\ / \ /
~~~~~ ~~~~~
_____ /\(起源)\/は~~です。|~~ A| = | UNIシグナリング| | | | +++V| | X| 気圧SW| +++はSCMPです。| | | NNIシグナリング| +++V| | X| 気圧SW| +++A| | | | = | UNIシグナリングV| +に対して-----+------+ IEEE 802.Xと802.1p| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ |中間的|--------------------+ | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | +------------+ L2シグナリング| | | A| A| | | | = | UNIシグナリング| | | SCMP| | | | | | | +++V| | | | | X| 気圧SW V| | | +++は+です。---+-|-+ SCMP| | | NNIシグナリング| \ /| | | +++V| X| |ランSW| | X| 気圧SW| / \| | | +++は+です。---+-|-+ | | | A| | | = | UNIシグナリング| | | V__|__ V V_|_V/\/\(目標)(目標)\/\/~~~~~ ~~~~~
Fig. 2.6: Example of ST2+ SCMP interworking.
図2.6: ST2+SCMPの織り込むのに関する例。
Suzuki Informational [Page 10] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[10ページ]のRFC2383ST2+
3. Revision of RFC 1819 ST2+
3. RFC1819ST2+の改正
To specify the ST2+ over ATM protocol, the functions in RFC 1819 ST2+ must be extended to support ATM. However, it is difficult for the current ATM standard to support part of the specifications in RFC 1819 ST2+. This section specifies the extended, restricted, unsupported, and modified functions in RFC 1819 ST2+. Errata for RFC 1819 appears in Appendix A.
ATMプロトコルの上のST2+、RFC1819ST2での機能を指定するために、サポートATMに+を広げなければなりません。 しかしながら、現在のATM規格がRFC1819ST2+の仕様の一部を支えるのは、難しいです。このセクションは広げられて、制限を指定して、RFC1819ST2でのサポートされなくて、変更された機能は+です。RFC1819のための誤字はAppendix Aに現れます。
3.1 Extended Functions of RFC 1819 ST2+
3.1 RFC1819ST2+の拡張機能
3.1.1 ST FlowSpec for Controlled-Load Service
制御負荷サービスのための3.1.1 ST FlowSpec
The ST2+ over ATM protocol specifies the ST FlowSpec format for the Integrated Services. Basically, FlowSpec parameter negotiation, except for the MTU, is not supported. The ST2+ intermediate agent and the target decide whether to accept or refuse the FlowSpec parameters, except for the MTU. Therefore, each of the FlowSpec parameter values other than MTU is the same at each target in the stream.
ATMプロトコルの上のST2+はST FlowSpec形式をIntegrated Servicesに指定します。 基本的に、MTU以外に、FlowSpecパラメタ交渉は支持されません。 ST2+仲介物質と目標は、MTU以外のFlowSpecパラメタを受け入れるか、または拒否するかを決めます。 したがって、MTU以外のそれぞれのFlowSpecパラメタ値は各目標で流れで同じです。
The format of the ST FlowSpec for the Controlled-Load Service is shown in Fig. 3.1.
Controlled-負荷ServiceのためのST FlowSpecの書式は図3.1に示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 1 | PBytes = 36 | ST FS Ver = 8 | 0(unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | 0(reserved) | Overall Length = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SVC Number |0| 0(reserved) | SVC Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Param Num = 127| Flags = 0 | Param Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [M] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=1| PBytes=36| FS Ver第=8| 0(未使用の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver=0| 0(予約されます)| 全長=7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SVC番号|0| 0(予約されます)| SVCの長さ=6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Paramヌム=127| 旗=0| Paramの長さ=5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 象徴Bucket Rate[r](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 象徴Bucket Size[b](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ピークData Rate[p](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小の取り締まられた単位[m]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のパケットサイズ[M]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3.1: Format of ST FlowSpec for Controlled-Load Service.
図3.1: 制御負荷サービスのための第FlowSpecの形式。
Suzuki Informational [Page 11] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[11ページ]のRFC2383ST2+
The PCode field identifies common SCMP elements. The PCode value
for the ST2+ FlowSpec is 1.
PCode分野は一般的なSCMP要素を特定します。 ST2+FlowSpecのためのPCode値は1です。
The PBytes field for the Controlled-Load Service is 36 bytes.
Controlled-負荷ServiceのためのPBytes分野は36バイトです。
The ST FS Ver (ST FlowSpec Version) field identifies the ST
FlowSpec version. The ST FlowSpec version number for the
Integrated Services is 8.
ST FS Ver(ST FlowSpecバージョン)分野はST FlowSpecバージョンを特定します。 Integrated ServicesのST FlowSpecバージョン番号は8です。
The Ver (Message Format Version) field identifies the Integrated
Services FlowSpec message format version. The current version is
zero.
Ver(メッセージFormatバージョン)分野はIntegrated Services FlowSpecメッセージ・フォーマットバージョンを特定します。 最新版はゼロです。
The Overall Length field for the Controlled-Load Service is 7
words.
Controlled-負荷ServiceのためのOverall Length分野は7つの単語です。
The SVC Number (Service ID Number) field identifies the Integrated
Services. If the Integrated Services FlowSpec appears in the
CONNECT or CHANGE message, the value of the SVC Number field is 1.
If it appears in the ACCEPT, NOTIFY, or STATUS-RESPONSE message,
the value of the SVC Number field is 5.
SVC Number(サービスID Number)分野はIntegrated Servicesを特定します。 Integrated Services FlowSpecがCONNECTかCHANGEメッセージに現れるなら、SVC Number分野の値は1です。 ACCEPT、NOTIFY、またはSTATUS-RESPONSEメッセージに現れるなら、SVC Number分野の値は5です。
The SVC Length (Service-specific Data Length) field for the
Controlled-Load Service is 6 words.
Controlled-負荷ServiceのためのSVC Length(サービス特有のData Length)分野は6つの単語です。
The Param Num (Parameter Number) field is 127.
Paramヌム(パラメタNumber)分野は127です。
The Flags (Per-parameter Flags) field is zero.
Flags(1パラメタあたりのFlags)分野はゼロです。
The Param Length (Length of Per-parameter Data) field is 5 words.
Param Length(Per-パラメタDataの長さ)分野は5つの単語です。
Definitions of the Token Bucket Rate [r], the Token Bucket Size
[b], the Peak Data Rate [p], the Minimum Policed Unit [m], and the
Maximum Packet Size [M] fields are given in [5]. See section 5 of
[5] for details.
[5]でToken Bucket Rate[r]、Token Bucket Size[b]、Peak Data Rate[p]、Minimum Policed Unit[m]、およびMaximum Packet Size[M]分野の定義を与えます。 詳細のための[5]のセクション5を見てください。
The ST2+ agent, that creates the FlowSpec element in the SCMP message, must assign valid values to all fields. The other agents must not modify any values in the element.
ST2+エージェントであり、それは、SCMPメッセージでFlowSpec要素を作成して、すべての分野に有効値を割り当てなければなりません。 他のエージェントは要素の少しの値も変更してはいけません。
The MaxMsgSize field in the CONNECT message is assigned by the origin or the intermediate agent acting as origin, and updated by each agent based on the MTU value of the datalink layer.
CONNECTメッセージのMaxMsgSize分野は、起源として務めている起源か仲介物質によって割り当てられて、データリンク層のMTU値に基づく各エージェントによってアップデートされます。
The negotiated value of MaxMsgSize is set back to the origin or the intermediate agent acting as origin using the [M] field and the MaxMsgSize field in the ACCEPT message that corresponds to the CONNECT message.
MaxMsgSizeの交渉された値は起源としてCONNECTメッセージに対応するACCEPTメッセージで[M]分野とMaxMsgSize分野を使用することで務めている起源か仲介物質に遅らせられます。
Suzuki Informational [Page 12] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[12ページ]のRFC2383ST2+
In the original definition of the Controlled-Load Service, the value of the [m] field must be less than or equal to the value of the [M] field. However, in the ST FlowSpec for the Controlled-Load Service, if the value of the [m] field is more than that of the [M] field, the value of the [m] field is regarded as the same value as the [M] field, and must not generate an error. This is because there is a possibility that the value of the [M] field in the ACCEPT message may be decreased by negotiation.
Controlled-負荷Serviceのオリジナルの定義では、[m]分野の値は[M]分野の、より値以下でなければなりません。 しかしながら、Controlled-負荷ServiceのためのST FlowSpecでは、[m]分野の値が[M]分野のもの以上なら、[M]と同じ値が誤りをさばいて、発生させてはいけないとき、[m]分野の値は見なされます。 これはACCEPTメッセージの[M]分野の値が交渉で減少するかもしれない可能性があるからです。
In the ST2+ SCMP messages, the value of the [M] field must be equal to or less than 65,535. In the ACCEPT message that responds to CONNECT, or the NOTIFY message that contains the FlowSpec field, the value of the [M] field must be equal to the MaxMsgSize field in the message. If these values are not the same, FlowSpec is regarded as an error.
ST2+SCMPメッセージでは、[M]分野の値は、6万5535より等しいか、または少ないに違いありません。 CONNECTに応じるACCEPTメッセージ、またはFlowSpec分野を含むNOTIFYメッセージでは、[M]分野の値はメッセージのMaxMsgSize分野と等しいに違いありません。 これらの値が同じでないなら、FlowSpecは誤りと見なされます。
If the ST2+ agent receives the CONNECT message that contains unacceptable FlowSpec, the agent must generate a REFUSE message.
ST2+エージェントが容認できないFlowSpecを含むCONNECTメッセージを受け取るなら、エージェントはREFUSEメッセージを発生させなければなりません。
3.1.2 ST FlowSpec for Guaranteed Service
保証されたサービスのための3.1.2 ST FlowSpec
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not support Guaranteed Services. It will be supported by the UNI 3.1/4.0 version.
以下に注意してください。 サポートGuaranteed Servicesではなく、ATMプロトコルの上の+がするST2のUNI3.1バージョン。 それはUNI3.1/4.0バージョンによって支持されるでしょう。
3.1.3 VC-type common SCMP element
3.1.3 VC-タイプの一般的なSCMP要素
The ST2+ over ATM protocol specifies an additional common SCMP element that designates the VC type used to support the diverse VC styles. The CONNECT and CHANGE messages that establish a hop with a VC must contain a VC-type common SCMP element. This element is valid between neighboring ST2+ agents, but must not propagate beyond the previous-hop or next-hop ST2+ agent.
ATMプロトコルの上の+がタイプにVCを指定する追加一般的なSCMP要素に指定するST2は以前はよくさまざまのVCスタイルを支持していました。 VCと共にホップを設立するCONNECTとCHANGEメッセージはVC-タイプの一般的なSCMP要素を含まなければなりません。 この要素は、隣接しているST2+エージェントの間で有効ですが、前のホップか次のホップST2+エージェントを超えて伝播されてはいけません。
Suzuki Informational [Page 13] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[13ページ]のRFC2383ST2+
The format of the VC-type common SCMP element is shown in Fig. 3.2.
VC-タイプの一般的なSCMP要素の書式は図3.2に示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 8 | PBytes = 20 | VCType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PVCIdentifer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0(unused) | UniqueID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LIJCallIdentifer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=8| PBytes=20| VCType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PVCIdentifer| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0(未使用の)| UniqueID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OriginIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LIJCallIdentifer| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3.2: Format of VC-type common SCMP element.
図3.2: VC-タイプの一般的なSCMP要素の形式。
The PCode field identifies the common SCMP elements. The PCode
value for the VC type is 8.
PCode分野は一般的なSCMP要素を特定します。 VCタイプのためのPCode値は8です。
The PBytes field for the VC type is 20 bytes.
VCタイプのためのPBytes分野は20バイトです。
The VCType field identifies the VC type. The correspondence
between the value in this field and the meaning is as follows:
VCType分野はVCタイプを特定します。 この分野の値と意味との通信は以下の通りです:
0: ST2+ data stream uses a PVC.
0: ST2+データ・ストリームはPVCを使用します。
1: ST2+ data stream uses the reverse channel of the bi-
directional point-to-point SVC used by the existing stream.
1: ST2+データ・ストリームはSVCが既存のストリームで使用した両性愛者の方向のポイントツーポイントの逆のチャンネルを使用します。
2: ST2+ data stream is established by a point-to-point SVC
initiated from the upstream side.
2: ST2+データ・ストリームは上流側から開始された二地点間SVCによって確立されます。
3: ST2+ data stream is established by a point-to-multipoint SVC
initiated from the upstream side.
3: ST2+データ・ストリームはSVCが上流側から開始したポイントツーマルチポイントによって確立されます。
4: ST2+ data stream is established by a point-to-point SVC
initiated from the downstream side.
4: ST2+データ・ストリームは川下側から開始された二地点間SVCによって確立されます。
5: ST2+ data stream is established by a point-to-multipoint SVC
initiated from the downstream side.
5: ST2+データ・ストリームはSVCが川下側から開始したポイントツーマルチポイントによって確立されます。
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not
support VCType 5. It will be supported by the UNI 3.1/4.0
version.
以下に注意してください。 ATMプロトコルの上の+がVCType5をサポートしないST2のUNI3.1バージョン。 それはUNI3.1/4.0バージョンによってサポートされるでしょう。
Suzuki Informational [Page 14] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[14ページ]のRFC2383ST2+
The PVCIdentifer field identifies the PVC identifier uniquely
assigned between neighboring ST2+ agents. This field is valid only
when the VCType field is zero.
PVCIdentifer分野は隣接しているST2+エージェントの間で唯一割り当てられたPVC識別子を特定します。 VCType分野がゼロであるときにだけ、この分野は有効です。
The UniqueID and OriginIPAddress fields identify the reverse
channel of the bi-directional point-to-point SVC that is used by
this SID. These fields are valid only when the VCType field is 1.
UniqueIDとOriginIPAddress分野はこのSIDによって使用される双方向の二地点間SVCの逆のチャンネルを特定します。 VCType分野が1であるときにだけ、これらの分野は有効です。
The LIJCallIdentifer field identifies the LIJ Call Identifier for
point-to-multipoint SVC. This field is valid only when the VCType
field is 5.
LIJCallIdentifer分野はポイントツーマルチポイントSVCのためにLIJ Call Identifierを特定します。 VCType分野が5であるときにだけ、この分野は有効です。
3.1.4 Reason Code
3.1.4 理由コード
The extension of the Reason Code (RFC 1819, Section 10.5.3) to the ST2+ over ATM protocol is shown below.
ATMプロトコルの上の+が以下に示されるST2へのReason Code(RFC1819、セクション10.5.3)の拡大。
57 CantChange Partial changes not supported.
58 NoRecover Stream recovery not supported.
57 変化がサポートしなかったCantChange Partial。 58 回復がサポートしなかったNoRecover Stream。
3.2 Restricted Functions of RFC 1819 ST2+
3.2 RFC1819ST2+の制限された機能
3.2.1 FlowSpec changes
3.2.1 FlowSpec変化
In the following case, the ST2+ over ATM protocol supports stream FlowSpec changes by using the CHANGE message.
以下の場合では、ATMプロトコルサポートの上のST2+は、CHANGEメッセージを使用することによって、FlowSpec変化を流します。
o The I-bit is set to 1 and the G-bit is set to 1.
o I-ビットは1に設定されます、そして、G-ビットは1に設定されます。
In the following case, the CHANGE fails and a REFUSE message, with the E and N-bits set to 1 and the ReasonCode set to CantChange, is propagated upstream.
以下の場合では、CHANGEは失敗します、そして、EがあるREFUSEメッセージ、1に設定されたN-ビット、およびCantChangeに用意ができているReasonCodeは上流へ伝播されます。
o The I and/or G-bits are set to zero.
o I、そして/または、G-ビットはゼロに設定されます。
3.3 Unsupported Functions of RFC 1819 ST2+
3.3 RFC1819ST2+のサポートされない機能
3.3.1 ST2+ FlowSpec
3.3.1 ST2+FlowSpec
The ST2+ over ATM protocol does not support the ST2+ FlowSpec (RFC 1819, Section 9.2). The ST2+ FlowSpec specifies useful services, but requires the datalink layer to support heterogeneous QoS to receivers. The current ATM standard does not support heterogeneous QoS to receivers.
ATMプロトコルの上の+がするST2は、ST2+FlowSpecが(RFC1819、セクション9.2)であるとサポートしません。 ST2+FlowSpecは、異種のQoSを受信機にサポートするために役に立つサービスを指定しますが、データリンク層を必要とします。 現在のATM規格は異種のQoSを受信機にサポートしません。
Suzuki Informational [Page 15] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[15ページ]のRFC2383ST2+
3.3.2 Stream preemption
3.3.2 ストリーム先取り
The ST2+ over ATM protocol does not support stream preemption (RFC 1819, Section 6.3). This is because the Integrated Services FlowSpec does not support the concept of precedence.
ATMプロトコルの上の+がするST2は、ストリーム先取りが(RFC1819、セクション6.3)であるとサポートしません。 これはIntegrated Services FlowSpecが先行の概念をサポートしないからです。
3.3.3 HELLO message
3.3.3 HELLOメッセージ
Implementations may not support the HELLO message (RFC 1819, Section 10.4.7) and thus ST2+ agent failure detection using the HELLO message (RFC 1819, Section 6.1.2). This is because ATM has an adequate failure detection mechanism, and the HELLO message is not sufficient for detecting link failure in the ST2+ over ATM protocol, because the ST2+ data and the ST2+ SCMP are forwarded through another VC.
実装は、HELLOメッセージが(RFC1819、セクション10.4.7)とその結果、ST2+エージェント失敗検出であるとHELLOメッセージ(RFC1819、セクション6.1.2)を使用することでサポートしないかもしれません。 これがATMには適切な失敗検出メカニズムがあるからであるHELLOメッセージはATMプロトコルの上にST2+にリンクの故障を検出するのに十分ではありません、別のVCを通してST2+データとST2+SCMPを転送するので。
3.3.4 Stream recovery
3.3.4 ストリーム回復
Implementors must select the NoRecover option of the CONNECT message (RFC 1819, Section 4.4.1) with the S-bit set to 1. This is because the descriptions of the stream recovery process in RFC 1819 (Sections 5.3.2, 6.2, and 6.2.1) are unclear and incomplete. It is thus possible that if a link failure occurs and several ST2+ agents detect it simultaneously, the recovery process may encounter problems.
作成者はS-ビットセットでCONNECTメッセージ(RFC1819、セクション4.4.1)のNoRecoverオプションを1に選択しなければなりません。 これはストリーム回復の記述がRFC1819で処理されるからです。(セクション5.3.2、.1は、)6.2、および6.2に、不明瞭であって、不完全です。 その結果、リンクの故障が起こって、数人のST2+エージェントが同時にそれを検出するなら、回復プロセスが問題に行きあたるのは、可能です。
The ST2+ over ATM protocol does not support stream recovery. If recovery is needed, the application should support it. A CONNECT message in which the NoRecover option is not selected will fail; a REFUSE message in which the N-bit is set to 1 and the ReaseonCode is set to NoRecover is then propagated upstream.
ATMプロトコルの上の+がするST2はストリーム回復をサポートしません。 回復が必要であるなら、アプリケーションはそれをサポートするべきです。 NoRecoverオプションが選択されないCONNECTメッセージは失敗するでしょう。 そして、N-ビットが1に設定されて、ReaseonCodeがNoRecoverに用意ができているREFUSEメッセージは上流へ伝播されます。
3.3.5 Subnet Resources Sharing
3.3.5 サブネットリソース共有
The ST2+ over ATM protocol does not support subnet resources sharing (RFC 1819, Section 7.1.4). This is because ATM does not support the concept of the MAC layer.
ATMプロトコルの上の+がするST2は、サブネットが(RFC1819、セクション7.1.4)を共有するリソースであるとサポートしません。 これはATMがMAC層の概念をサポートしないからです。
3.3.6 IP encapsulation of ST
3.3.6 STのIPカプセル化
The ST2+ over ATM protocol does not support IP encapsulation of ST (RFC 1819, Section 8.7), because there is no need to implement IP encapsulation in this protocol.
ATMプロトコルの上の+がするST2はST(RFC1819、セクション8.7)のIPカプセル化をサポートしません、このプロトコルにはIPカプセル化を実装する必要は全くないので。
3.3.7 IP Multicasting
3.3.7 IPマルチキャスティング
The ST2+ over ATM protocol does not support IP multicasting (RFC 1819, Section 8.8), because this protocol does not support IP encapsulation of ST.
ATMプロトコルの上の+がするST2は、IPマルチキャスティングが(RFC1819、セクション8.8)であるとサポートしません、このプロトコルがSTのIPカプセル化をサポートしないので。
Suzuki Informational [Page 16] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[16ページ]のRFC2383ST2+
3.4 Modified Functions of RFC 1819 ST2+
3.4 RFC1819ST2+の変更された機能
The ST2+ receiver-oriented stream creation procedure has some fatal problems: the value of the LnkReferecnce field in the CONNECT message that is a response to a JOIN message is not valid, ST2+ agent cannot update the LnkReference field in the JOIN-REJECT message, and ST2+ agent cannot deliver the JOIN-REJECT message to the target because the JOIN-REJECT message does not contain a TargetList field. To solve these problems, the ST2+ over ATM protocol modifies the ST2+ protocol processing rules.
受信機ST2+指向のストリーム作成手順に、いくつかの致命的な問題があります: JOINメッセージへの応答であるCONNECTメッセージのLnkReferecnce分野の値は有効ではありません、そして、ST2+エージェントはJOIN-REJECTメッセージのLnkReference分野をアップデートできません、そして、JOIN-REJECTメッセージがTargetList分野を含まないので、ST2+エージェントはJOIN-REJECTメッセージを目標に提供できません。 これらの問題、ST2を解決するために、ATMプロトコルの上の+はST2+プロトコル処理規則を変更します。
3.4.1 Modifications of Message Processing Rules
3.4.1 メッセージ処理規則の変更
Modifications of the CONNECT, JOIN, and JOIN-REJECT message processing rules in the ST2+ over ATM protocol are described in the following.
CONNECT、JOIN、およびATMプロトコルの上のST2+のJOIN-REJECTメッセージ処理規則の変更は以下で説明されます。
o The target that creates a JOIN message assigns the same value as in
the Reference field to the LnkReference field.
o JOINメッセージを作成する目標はLnkReference分野へのReference分野のように同じ値を割り当てます。
o The agent that creates a CONNECT message as a response to a JOIN
message assigns the same value as in the LnkReference field in the
JOIN message to the LnkReference field. In other cases, the value
of the LnkReference field in a CONNECT message is zero.
o JOINメッセージへの応答としてCONNECTメッセージを作成するエージェントはLnkReference分野へのJOINメッセージのLnkReference分野のように同じ値を割り当てます。 他の場合では、CONNECTメッセージのLnkReference分野の値はゼロです。
o The agent that creates a JOIN-REJECT message assigns the same value
as in the LnkReference field in the JOIN message to the
LnkReference field.
o JOIN-REJECTメッセージを作成するエージェントはLnkReference分野へのJOINメッセージのLnkReference分野のように同じ値を割り当てます。
o An intermediate agent must not modify the value of the LnkReference
field in the CONNECT, JOIN, or JOIN-REJECT message. Note that this
rule differs from the LnkReference field processing rule in the
ACCEPT and REFUSE messages.
o 仲介物質はCONNECT、JOIN、またはJOIN-REJECTメッセージのLnkReference分野の値を変更してはいけません。 この規則がACCEPTとREFUSEメッセージのLnkReferenceフィールド処理規則と異なっていることに注意してください。
Suzuki Informational [Page 17] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[17ページ]のRFC2383ST2+
3.4.2 Modified JOIN-REJECT Control Message
3.4.2 廃棄物を接合している変更されたコントロールメッセージ
The modified JOIN-REJECT control message in the ST2+ over ATM protocol is shown in Fig. 3.3
ATMプロトコルの上の+が図3.3に示されるST2の変更されたJOIN-REJECTコントロールメッセージ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 9 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode=9| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GeneratorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3.3: JOIN-REJECT Control Message.
図3.3: 廃棄物を接合しているコントロールメッセージ。
The TargetList is assigned the same TargetList in the JOIN message as the one that corresponds to the JOIN-REJECT message.
同じTargetListはJOIN-REJECTメッセージに対応するものとしてJOINメッセージでTargetListに割り当てられます。
4. Protocol Specification of the User Plane
4. ユーザ飛行機に関するプロトコル仕様
This section specifies the AAL5 PDU encapusulation for the ST2+ Data PDU.
このセクションはST2+データPDUにAAL5 PDU encapusulationを指定します。
4.1 Service Primitives Provided by User Plane
4.1 ユーザ飛行機によって提供されたサービス基関数
4.1.1 Overview of interactions
4.1.1 相互作用の概要
The ST2+ data layer entity on the user plane of the ST2+ over ATM protocol provides the following services to the upper layer.
ST2+データはATMプロトコルの上の+が上側の層に対する以下のサービスを供給するST2のユーザ飛行機の上で実体を層にします。
o st2p_unitdata.req
o st2p_unitdata.req
o st2p_unitdata.ind
o st2p_unitdata.ind
4.1.1.1 St2p_unitdata.req
4.1.1.1 St2p_unitdata.req
The st2p_unitdata.req primitive sends a request for an ST2+ Data PDU transfer to the ST2+ data layer entity. The semantics of the primitive are as follows:
st2p_unitdata.req基関数はST2+データPDU転送を求める要求をST2+データ層の実体に送ります。 原始の意味論は以下の通りです:
Suzuki Informational [Page 18] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[18ページ]のRFC2383ST2+
st2p_unitdata.req (
pri,
sid,
data
)
st2p_unitdata.req(pri、sid、データ)
The pri parameter specifies priority of ST2+ Data PDU. The sid parameter specifies SID of ST2+ Data PDU. The data parameter specifies ST2+ data to be transferred.
priパラメタはST2+データPDUの優先権を指定します。 sidパラメタはST2+データPDUのSIDを指定します。 データパラメタは、移すためにST2+データを指定します。
4.1.1.2 St2p_unitdata.ind
4.1.1.2 St2p_unitdata.ind
The st2p_unitdata.ind primitive indicates an ST2+ Data PDU delivery from the ST2+ data layer entity. The semantics of the primitive are as follows:
st2p_unitdata.ind基関数はST2+データ層の実体からST2+データPDU配送を示します。 原始の意味論は以下の通りです:
st2p_unitdata.ind (
pri [optional],
sid,
data,
status [optional]
)
st2p_unitdata.ind(pri[任意の]、sid、データ、状態[任意の])
The pri parameter indicates priority of ST2+ Data PDU, if AAL5 is used for encapsulating the ST2+ Data PDU. The sid parameter indicates SID of ST2+ Data PDU. The data parameter indicates delivered ST2+ data. The status is an optional parameter that indicates whether the delivered ST2+ data is corrupt or not.
AAL5がST2+データPDUをカプセル化するのに使用されるなら、priパラメタはST2+データPDUの優先権を示します。 sidパラメタはST2+データPDUのSIDを示します。 データパラメタは提供されたST2+データを示します。 状態は提供されたST2+データが間違っているかどうかを示す任意のパラメタです。
4.2 Service Primitives Provided by AAL5
4.2 AAL5によって提供されたサービス基関数
4.2.1 Requirements for AAL5
4.2.1 AAL5のための要件
The requirements for the AAL5 layer on the ST2+ over ATM user plane are as follows:
ATMユーザ飛行機の上のST2+の上のAAL5層のための要件は以下の通りです:
o The SSCS must be null.
o SSCSはヌルであるに違いありません。
o Implementations must use message-mode service.
o 実装はメッセージモードサービスを利用しなければなりません。
Note: Selection of the corrupted SDU delivery option on the
receiver side depends on the implementation, so the receiver may or
may not be able to select this option.
以下に注意してください。 受信機側における崩壊したSDU配送オプションの選択が実装によるので、受信機はこのオプションを選択できるかもしれません。
4.2.2 Overview of Interactions
4.2.2 相互作用の概要
The AAL5 layer entity on the ST2+ over ATM user plane provides the following services to the ST2+ data layer.
AAL5はATMユーザ飛行機の上の+がST2+データ層に対する以下のサービスを供給するST2で実体を層にします。
Suzuki Informational [Page 19] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[19ページ]のRFC2383ST2+
o AAL5_UNITDATA.req
o AAL5_UNITDATA.req
o AAL5_UNITDATA.ind
o AAL5_UNITDATA.ind
4.2.2.1 AAL5_UNITDATA.req
4.2.2.1 AAL5_UNITDATA.req
The AAL5_UNITDATA.req primitive sends a request for an AAL5 data (AAL5 CPCS_SDU) transfer from the ST2+ data layer entity to the AAL5 layer entity. The semantics of the primitive are as follows:
AAL5_UNITDATA.req基関数はST2+データ層の実体からAAL5層の実体までのAAL5データ(AAL5 CPCS_SDU)転送を求める要求を送ります。 原始の意味論は以下の通りです:
AAL5_UNITDATA.req (
DATA,
CPCS_LP,
CPCS_UU
)
AAL5_UNITDATA.req(データ、CPCS_LP、CPCS_UU)
The DATA parameter specifies the AAL5 data to be transferred. The CPCS_LP parameter specifies the value of the CLP field in the ATM cell. The CPCS_UU parameter specifies the user-to-user data to be transferred.
DATAパラメタは、移すためにAAL5データを指定します。 CPCS_LPパラメタはATMセルの中のCLP分野の値を指定します。 CPCS_UUパラメタは、移すためにユーザから利用者データを指定します。
4.2.2.2 AAL5_UNITDATA.ind
4.2.2.2 AAL5_UNITDATA.ind
The AAL5_UNITDATA.ind indicates an AAL5 data (AAL5 CPCS_SDU) delivery from the AAL5 layer entity to the ST2+ data layer entity. The semantics of the primitive are as follows:
AAL5_UNITDATA.indはAAL5層の実体からST2+データ層の実体までのAAL5データ(AAL5 CPCS_SDU)配送を示します。 原始の意味論は以下の通りです:
AAL5_UNITDATA.ind (
DATA,
CPCS_LP,
CPCS_UU,
STATUS [optional]
)
AAL5_UNITDATA.ind(データ、CPCS_LP、CPCS_UU、状態[任意の])
The DATA parameter indicates the delivered AAL5 data. The CPCS_LP parameter indicates the value of the CLP field in the ATM cell. The CPCS_UU parameter indicates the delivered user-to-user data. The STATUS parameter indicates whether the delivered AAL5 data is corrupt or not. The STATUS parameter is an optional parameter, and valid only when the corrupted SDU delivery option is selected.
DATAパラメタは提供されたAAL5データを示します。 CPCS_LPパラメタはATMセルの中のCLP分野の値を示します。 CPCS_UUパラメタは提供されたユーザから利用者データを示します。 STATUSパラメタは、提供されたAAL5データが間違っているかどうかを示します。 STATUSパラメタは、任意のパラメタであって、崩壊したSDU配送オプションが選択される場合にだけ、有効です。
4.3 AAL5 Encapsulation for ST2+ Data PDU
4.3 ST2+データPDUのためのAAL5カプセル化
4.3.1 Mapping from st2_unitdata.req to AAL5_UNITDATA.req
4.3.1 st2_unitdata.reqからAAL5まで_UNITDATA.reqを写像します。
The ST2+ Data PDU is directly assigned to the DATA parameter in AAL5_UNITDATA.req. That is, as shown in Fig. 4.1, the ST2+ Data PDU is mapped to the payload of AAL5 CPCS_PDU.
ST2+データPDUは直接AAL5_UNITDATA.reqのDATAパラメタに割り当てられます。 すなわち、図4.1に示されるように、ST2+データPDUはAAL5 CPCS_PDUのペイロードに写像されます。
Suzuki Informational [Page 20] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[20ページ]のRFC2383ST2+
+-------+---------------------------+ | ST | ST2+ data | ST2+ | header| | Data PDU +-------+---------------------------+ : : : : +---------------------------------------+--------+ | CPCS_PDU |PAD|CPCS_PDU| AAL5 | payload | |trailer | CPCS_PDU +---------------------------------------+--------+
+-------+---------------------------+ | st| ST2+データ| ST2+| ヘッダー| | データPDU+-------+---------------------------+ : : : : +---------------------------------------+--------+ | CPCS_PDU|パッド|CPCS_PDU| AAL5| ペイロード| |トレーラ| CPCS_PDU+---------------------------------------+--------+
Fig. 4.1: Mapping of ST2+ data to AAL5 CPCS_PDU payload.
図4.1: AAL5 CPCS_PDUペイロードへのST2+データに関するマッピング。
The value of CPCS_LP in AAL5_UNITDATA.req depends on the implementation: 1 (low priority) or zero (high priority) may be assigned permanently, or they may be assigned depending on the value of pri in st2_unitdata.req.
AAL5_UNITDATA.reqのCPCS_LPの値を実装に依存します: 1 (低い優先度)かゼロ(高い優先度)が永久に、割り当てられるか、またはst2_unitdata.reqのpriの値によって、それらは割り当てられるかもしれません。
The value of the CPCS_UU indication field in AAL5_UNITDATA.req is set to zero.
AAL5_UNITDATA.reqのCPCS_UU指示分野の値はゼロに設定されます。
4.3.2 Mapping from AAL5_UNITDATA.ind to st2p_unitdata.ind
4.3.2 AAL5_UNITDATA.indからst2pまで_unitdata.indを写像します。
The DATA parameter in AL5_UNITDATA.ind is directly assigned to the ST2+ Data PDU. That is, the payload in AAL5 CPCS_PDU is mapped to the ST2+ Data PDU.
AL5_UNITDATA.indのDATAパラメタは直接ST2+データPDUに割り当てられます。 すなわち、AAL5 CPCS_PDUのペイロードはST2+データPDUに写像されます。
If the value of STATUS in AAL5_UNITDATA.ind is valid, it is assigned to the status in st2p_unitdata.ind.
AAL5_UNITDATA.indのSTATUSの値が有効であるなら、それはst2p_unitdata.indの状態に割り当てられます。
4.3.3 Value of MTU
4.3.3 MTUの値
The value of MTU is Maximum CPCS_SDU size.
MTUの値はMaximum CPCS_SDUサイズです。
5. Protocol Specification of the Management Plane
5. 管理飛行機に関するプロトコル仕様
The management plane specifies the Null FlowSpec, the Controlled-Load Service FlowSpec, and the Guaranteed Service FlowSpec mapping rules for UNI 3.1 traffic management.
管理飛行機はNull FlowSpec、Controlled-負荷Service FlowSpec、およびGuaranteed Service FlowSpec配置規則をUNI3.1輸送管理に指定します。
5.1 Mapping of the Null FlowSpec
5.1 ヌルFlowSpecに関するマッピング
The Null FlowSpec is mapped to the UBR (VBR with the Best Effort Indicator).
Null FlowSpecはUBR(Best Effort IndicatorとVBR)に写像されます。
The value of the PCR (CLP=0+1) is shown in section 6.7.2.
PCR(CLP=0+1)の値はセクション6.7.2で示されます。
Suzuki Informational [Page 21] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[21ページ]のRFC2383ST2+
5.2 Mapping of the Controlled-Load Service FlowSpec
5.2 制御負荷サービスFlowSpecに関するマッピング
The Controlled-Load FlowSpec is mapped to the VBR whose PCR (CLP=0+1), SCR (CLP=0+1), and MBS (CLP=0+1) are specified.
Controlled-負荷FlowSpecはPCR(CLP=0+1)、SCR(CLP=0+1)、およびMBS(CLP=0+1)が指定されるVBRに写像されます。
The value of the PCR (CLP=0+1) is shown in section 6.7.2.
PCR(CLP=0+1)の値はセクション6.7.2で示されます。
Let scr be the calculated value of the SCR (CLP=0+1). Based on the
value of the [r] field in the Controlled-Load FlowSpec, it is given
by:
scr = ([r] / 48) * S,
scrがSCR(CLP=0+1)の計算された値であることをさせてください。 Controlled-負荷FlowSpecの[r]分野の値に基づいて、以下はそれを与えます。 scr=([r]/48) *S
where S is the coefficient of segmentation, and in an implementation, it must be configurable to any value between 1.0 and 56.0. The recommended default value is 1.2. The value of the SCR (CLP=0+1) is a minimum integer equal to or more than the calculated value of the scr.
Sが分割の係数であるところ、および実装では、それは1.0〜56.0にどんな値にも構成可能でなければなりません。 お勧めのデフォルト値は1.2です。 SCR(CLP=0+1)の値はscrにおいて、等しいか計算された値より多くの最小の整数です。
Let mbs be the calculated value of the MBS (CLP=0+1). Based on the
value of the [b] field in the Controlled-Load FlowSpec, it is given
by:
mbs = ([b] / 48) * S.
mbがMBS(CLP=0+1)の計算された値であることをさせてください。 Controlled-負荷FlowSpecの[b]分野の値に基づいて、以下はそれを与えます。 mb=([b]/48) *S。
The value of the MBS (CLP=0+1) is a minimum integer equal to or more than the calculated value of the mbs.
MBS(CLP=0+1)の値はmbにおいて、等しいか計算された値より多くの最小の整数です。
The values of the [p] and [m] fields in the Controlled-Load FlowSpec are ignored.
Controlled-負荷FlowSpecの[p]と[m]分野の値は無視されます。
5.3 Mapping of the Guaranteed Service FlowSpec
5.3 保証されたサービスFlowSpecに関するマッピング
Note: The UNI 3.1 version of the ST2+ over ATM protocol does not support Guaranteed Services. It will be supported by the UNI 3.1/4.0 version.
以下に注意してください。 サポートGuaranteed Servicesではなく、ATMプロトコルの上の+がするST2のUNI3.1バージョン。 それはUNI3.1/4.0バージョンによって支持されるでしょう。
6. Protocol Specification of the Control Plane
6. 制御飛行機に関するプロトコル仕様
This section specifies the rules for encapsulating the ST2+ SCMP PDU into the AAL5 PDU, the relationship between ST2+ SCMP and PVC management for ST2+ data, and the protocol interaction between ST2+ SCMP and UNI 3.1 signaling.
このセクションはST2+SCMP PDUをAAL5 PDUに要約するための規則、ST2+データのためのST2+SCMPとPVC管理との関係、およびST2+SCMPとUNI3.1シグナリングとのプロトコル相互作用を指定します。
6.1 AAL5 Encapsulation for ST2+ SCMP PDU
6.1 ST2+SCMP PDUのためのAAL5カプセル化
This subsection describes AAL5 PDU encapsulation for the ST2+ SCMP PDU. ST2+ Data PDU compatible encapsulation, AAL5 encapsulation based on RFC 1483, and on the RFC 1483 extension are specified. Selection of which one to use depends on the implementation.
この小区分はST2+SCMP PDUのためにAAL5 PDUカプセル化について説明します。 ST2+データのPDUコンパチブルカプセル化、RFC1483に基づいた1483年のRFC拡張子でのAAL5カプセル化は指定されます。 どれを使用したらよいかに関する選択は実現によります。
Suzuki Informational [Page 22] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[22ページ]のRFC2383ST2+
The ST2+ over ATM protocol does not cover a VC (SVC/PVC) that transfers ST2+ SCMP. VCs for IPv4 transfer may be used for ST2+ SCMP transfer, and implementations may provide particular VCs for ST2+ SCMP transfer. Selection of these VCs depends on the implementation.
ATMプロトコルの上の+がするST2はST2+SCMPを移すVC(SVC/PVC)を覆っていません。 IPv4転送のためのVCsはST2+SCMP転送に使用されるかもしれません、そして、実現はST2+SCMP転送に特定のVCsを提供するかもしれません。 これらのVCsの品揃えは実現によります。
6.1.1 ST2+ Data PDU compatible encapsulation
6.1.1 ST2+データのPDUコンパチブルカプセル化
The ST2+ Data PDU compatible encapsulation is shown in Fig. 6.1: the ST2+ SCMP PDU is mapped to the payload of AAL5 CPCS_PDU. Implementors should note that this encapsulation is not applicable when the ST2+ SCMP PDU is multiplexed with other protocols.
ST2+データのPDUコンパチブルカプセル化は図6.1に示されます: ST2+SCMP PDUはAAL5 CPCS_PDUのペイロードに写像されます。 作成者は、他のプロトコルと共にST2+SCMP PDUを多重送信するとき、このカプセル化が適切でないことに注意するべきです。
+-------+---------------------------+ | ST | ST2+ SCMP | ST2+ | header| | SCMP PDU +-------+---------------------------+ : : : : +---------------------------------------+--------+ | CPCS_PDU |PAD|CPCS_PDU| AAL5 | payload | |trailer | CPCS_PDU +---------------------------------------+--------+
+-------+---------------------------+ | st| ST2+SCMP| ST2+| ヘッダー| | SCMP PDU+-------+---------------------------+ : : : : +---------------------------------------+--------+ | CPCS_PDU|パッド|CPCS_PDU| AAL5| ペイロード| |トレーラ| CPCS_PDU+---------------------------------------+--------+
Fig. 6.1: ST2+ Data PDU conpatible encapsulation.
図6.1: ST2+データPDU conpatibleカプセル化。
6.1.2 RFC 1483 base encapsulation
6.1.2 RFC1483ベースカプセル化
The RFC 1483 base encapsulation is shown in Fig. 6.2: the ST2+ SCMP PDU with the RFC 1483 LLC encapsulation for routed protocol format is mapped to the payload in AAL5 CPCS_PDU.
RFC1483ベースカプセル化は図6.2に示されます: 発送されたプロトコル形式のためのRFC1483LLCカプセル化があるST2+SCMP PDUはAAL5 CPCS_PDUのペイロードに写像されます。
+------+----------------+
| ST | ST2+ SCMP | ST2+
|header| | SCMP PDU
+------+----------------+
: :
+---+---+---+-----------------------+
|LLC|OUI|PID| Information | IEEE 802 SNAP
| | | | | ISO 8802-2 LLC
+---+---+---+-----------------------+
: :
+---------------------------------------+--------+
| CPCS_PDU |PAD|CPCS_PDU| AAL5
| payload | |trailer | CPCS_PDU
+---------------------------------------+--------+
+------+----------------+ | st| ST2+SCMP| ST2+|ヘッダー| | SCMP PDU+------+----------------+ : : +---+---+---+-----------------------+ |LLC|OUI|PID| 情報| IEEE802は折ります。| | | | | ISO8802-2LLC+---+---+---+-----------------------+ : : +---------------------------------------+--------+ | CPCS_PDU|パッド|CPCS_PDU| AAL5| ペイロード| |トレーラ| CPCS_PDU+---------------------------------------+--------+
Fig. 6.2: RFC 1483 base encapsulation.
図6.2: RFC1483はカプセル化を基礎づけます。
Suzuki Informational [Page 23] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[23ページ]のRFC2383ST2+
The value of the LLC is 0xAA-AA-03, the value of the OUI is 0x00-00- 00, and the value of the PID is 0x08-00. The classification of the IPv4 and the ST2+ SCMP is determined by the IP version number, which is located in the first four bits of the IPv4 or ST headers.
LLCの値は0xAA-AA-03です、そして、OUIの値は0×00 00- 00です、そして、PIDの値は0×08-00です。 IPバージョン番号に従って、IPv4とST2+SCMPの分類は決定しています。(それは、IPv4かSTヘッダーの最初の4ビットに位置しています)。
6.1.3 RFC 1483 extension base encapsulation
6.1.3 RFC1483拡大ベースカプセル化
The RFC 1483 extension base encapsulation is the same as for RFC 1483 base encapsulation, except that the value of the OUI is 0x00-00-5E (IANA) and the value of the PID is 0xXX-XX (TBD).
RFC1483拡大ベースカプセル化はRFC1483ベースカプセル化のように同じです、OUIの値が0×00 00-5Eであり(IANA)、PIDの値が0xXX-XX(TBD)であることを除いて。
The RFC 1483 base encapsulation for the SCMP is ideal, but requires modifying the IPv4 processing in the driver software of the WS or PC. Therefore, the RFC 1483 base encapsulation may be difficult to implement. This encapsulation is designed to solve this problem.
SCMPのためのRFC1483ベースカプセル化は、理想的ですが、WSかPCのドライバソフトウェアにおけるIPv4処理を変更するのを必要とします。 したがって、RFC1483ベースカプセル化は実行するのが難しいかもしれません。 このカプセル化は、この問題を解決するように設計されています。
6.2 Service Primitives Provided by Control Plane
6.2 制御飛行機によって提供されたサービス基関数
RFC 1819 ST2+ does not specify SCMP state machines. And the ST2+ over ATM protocol does not correspond to SCMP state machines. Therefore, the control plane specification assumes the following.
+がするRFC1819ST2はSCMP州のマシンを指定しません。 そして、ATMプロトコルの上の+がするST2はSCMP州のマシンに対応していません。 したがって、コントロール飛行機仕様は以下を仮定します。
o The ST2+ agent has ST2+ SCMP layer entities that correspond to the
next hops and the previous hop in the stream.
o ST2+エージェントには、流れで次のホップと前のホップに対応するST2+SCMP層の実体があります。
o The SCMP layer entity terminates ACK, ERROR, and timeout processing
and provides reliable SCMP delivery.
o SCMP層の実体は、ACK、ERROR、およびタイムアウト処理を終えて、信頼できるSCMP配送を提供します。
o The origin consists of an upper layer entity, ST2+ SCMP layer
entities for next hops, and a routing machine that delivers SCMP
messages between these entities.
o 起源は上側の層の実体、次のホップのためのST2+SCMP層の実体、およびこれらの実体の間でメッセージをSCMPに渡すルータ・マシンから成ります。
o The intermediate agent consists of ST2+ SCMP layer entities for a
previous hop and for next hops and a routing machine that delivers
SCMP messages between these entities.
o 仲介物質は前のホップと次のホップのためのST2+SCMP層の実体とこれらの実体の間でメッセージをSCMPに渡すルータ・マシンから成ります。
o The target consists of an upper layer entity, an ST2+ SCMP layer
entity for a previous hop, and a routing machine that delivers SCMP
messages between these entities.
o 目標は上側の層の実体、前のホップのためのST2+SCMP層の実体、およびこれらの実体の間でメッセージをSCMPに渡すルータ・マシンから成ります。
At least, the ST2+ SCMP layer entity for the next hop provides the following services to the routing machine.
少なくとも、次のホップのためのST2+SCMP層の実体はルータ・マシンに対する以下のサービスを提供します。
o connect.req
This primitive sends a request for a CONNECT message transfer to
the ST2+ SCMP layer entity.
o connect.req This基関数はST2+SCMP層の実体にCONNECTメッセージ転送を求める要求を送ります。
Suzuki Informational [Page 24] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[24ページ]のRFC2383ST2+
o change.req
This primitive sends a request for a CHANGE message transfer to the
ST2+ SCMP layer entity.
o change.req This基関数はST2+SCMP層の実体にCHANGEメッセージ転送を求める要求を送ります。
o accept.ind
This primitive indicates an ACCEPT message delivery from the ST2+
SCMP layer entity.
o accept.ind This基関数はST2+SCMP層の実体からACCEPTメッセージ配送を示します。
o disconnect.req
This primitive sends a request for a DISCONNECT message transfer to
the ST2+ SCMP layer entity.
o disconnect.req This基関数はST2+SCMP層の実体にDISCONNECTメッセージ転送を求める要求を送ります。
o refuse.ind
This primitive indicates a REFUSE message delivery from the ST2+
SCMP layer entity, or indicates detection of an abnormal status
such as an illegal message or timeout in the ST2+ SCMP layer
entity.
o refuse.ind This基関数は、ST2+SCMP層の実体からREFUSEメッセージ配送を示すか、またはST2+SCMP層の実体における不法なメッセージかタイムアウトなどの異常な状態の検出を示します。
At least, the ST2+ SCMP layer entity for the previous hop provides the following services to the routing machine.
少なくとも、前のホップのためのST2+SCMP層の実体はルータ・マシンに対する以下のサービスを提供します。
o connect.ind
This primitive indicates a CONNECT message delivery from the ST2+
SCMP layer entity.
o connect.ind This基関数はST2+SCMP層の実体からCONNECTメッセージ配送を示します。
o change.ind
This primitive indicates a CHANGE message delivery from the ST2+
SCMP layer entity.
o change.ind This基関数はST2+SCMP層の実体からCHANGEメッセージ配送を示します。
o accept.req
This primitive sends a request for an ACCEPT message transfer to
the ST2+ SCMP layer entity.
o accept.req This基関数はST2+SCMP層の実体にACCEPTメッセージ転送を求める要求を送ります。
o disconnect.ind
This primitive indicates a DISCONNECT message delivery from the
ST2+ SCMP layer entity, or indicates detection of an abnormal
status such as an illegal message or timeout in the ST2+ SCMP layer
entity.
o disconnect.ind This基関数は、ST2+SCMP層の実体からDISCONNECTメッセージ配送を示すか、またはST2+SCMP層の実体における不法なメッセージかタイムアウトなどの異常な状態の検出を示します。
o refuse.req
This primitive sends a request for a REFUSE message transfer to the
ST2+ SCMP layer entity.
o refuse.req This基関数はST2+SCMP層の実体にREFUSEメッセージ転送を求める要求を送ります。
6.3 Service Primitives Provided by UNI 3.1 Signaling
6.3 UNI3.1シグナリングによって提供されたサービス基関数
The UNI 3.1 signaling layer entity on the ST2+ over ATM control plane provides the following services to the ST2+ SCMP layer entity. The ST2+ over ATM protocol does not specify the UNI 3.1 signaling state
ATM制御飛行機の上の+がST2+SCMP層の実体に対する以下のサービスを供給するST2の上のUNI3.1シグナリング層の実体。 ATMプロトコルの上の+がするST2はUNI3.1シグナリング状態を指定しません。
Suzuki Informational [Page 25] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[25ページ]のRFC2383ST2+
machines. These are defined in [10, 12, 13].
機械加工します。 これらは[10、12、13]で定義されます。
o setup.req
This primitive sends a request for a SETUP message transfer from
the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity.
The ST2+ SCMP layer entity that sent this primitive receives an
acknowledgment. If the setup succeeds the acknowledgment is a
setup.conf primitive and if the setup fails it is a release.ind or
release.conf primitive.
o setup.req This基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのSETUPメッセージ転送を求める要求を送ります。 原始的にこれを送ったST2+SCMP層の実体は承認を受けます。 セットアップが承認を引き継ぐなら、setup.confは原始的です、そして、セットアップがそれに失敗するなら、release.indかrelease.confが原始的ですか?
o setup.conf
This primitive indicates a CONNECT message delivery from the UNI
3.1 signaling layer entity to the ST2+ SCMP layer entity.
o setup.conf This基関数はUNI3.1シグナリング層の実体からST2+SCMP層の実体までのCONNECTメッセージ配送を示します。
o setup.ind
This primitive indicates a SETUP message delivery from the UNI 3.1
signaling layer entity to the ST2+ SCMP layer entity. The ST2+
SCMP layer entity that received this primitive sends an
acknowledgment. If the setup is accepted the acknowledgment is a
setup.resp primitive and if the setup is rejected it is a
release.resp primitive if the state of the UNI 3.1 signaling layer
entity is U6; otherwise it is a release.req primitive.
o setup.ind This基関数はUNI3.1シグナリング層の実体からST2+SCMP層の実体までのSETUPメッセージ配送を示します。 原始的にこれを受けたST2+SCMP層の実体は承認を送ります。 セットアップを受け入れるなら、承認はsetup.resp基関数です、そして、セットアップが拒絶されるなら、UNI3.1シグナリング層の実体の状態がU6であるなら、それはrelease.resp基関数です。 さもなければ、それはrelease.req基関数です。
o setup.resp
This primitive sends a request for a CONNECT message transfer from
the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity.
The ST2+ SCMP layer entity that sent this primitive receives an
acknowledgment. If the setup is completed the acknowledgment is a
setup-complete.ind primitive and if the setup fails it is a
release.ind or release.conf primitive.
o setup.resp This基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのCONNECTメッセージ転送を求める要求を送ります。 原始的にこれを送ったST2+SCMP層の実体は承認を受けます。 セットアップが失敗するなら、それは、セットアップが終了されているなら、承認がセットアップ-complete.ind基関数であり、release.indかrelease.conf基関数です。
o setup-complete.ind
This primitive indicates a CONNECT ACKNOWLEDGE message delivery
from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer
entity.
o セットアップ-complete.ind This基関数はUNI3.1シグナリング層の実体からST2+SCMP層の実体までのCONNECT ACKNOWLEDGEメッセージ配送を示します。
o release.req
This primitive sends a request for a RELEASE message transfer from
the ST2+ SCMP layer entity to the UNI 3.1 signaling layer entity.
The ST2+ SCMP layer entity that sent this primitive receives an
acknowledgment that is a release.conf primitive.
o release.req This基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのRELEASEメッセージ転送を求める要求を送ります。 原始的にこれを送ったST2+SCMP層の実体は原始的にrelease.confである承認を受けます。
o release.conf
This primitive indicates a RELEASE COMPLETE message delivery, or
indicates a RELEASE message delivery when the status of the UNI 3.1
signaling layer entity is U11, or indicates detection of an
abnormal status such as an illegal message or timeout in the UNI
3.1 signaling layer entity, from the UNI 3.1 signaling layer entity
o release.conf This基関数は、UNI3.1シグナリング層の実体の状態がU11であるときに、RELEASE COMPLETEメッセージ配送を示すか、RELEASEメッセージ配送を示す、またはUNI3.1シグナリング層の実体における不法なメッセージかタイムアウトなどの異常な状態の検出を示します、UNI3.1シグナリング層の実体から
Suzuki Informational [Page 26] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[26ページ]のRFC2383ST2+
to the ST2+ SCMP layer entity.
ST2+SCMPに、実体を層にしてください。
o release.ind
This primitive indicates a RELEASE message delivery from the UNI
3.1 signaling layer entity to the ST2+ SCMP layer entity when the
status of the UNI 3.1 signaling layer entity is other than U11.
The ST2+ SCMP layer entity that received this primitive sends an
acknowledgment that is a release.resp primitive. And this
primitive also indicates detection of an abnormal status such as an
illegal message or timeout in the UNI 3.1 signaling layer entity
and then a REFUSE message is transferred. In this case, the ST2+
SCMP layer entity that received this primitive receives a
release.conf primitive in succession.
o U11を除いて、UNI3.1シグナリング層の実体の状態がいるとき、release.ind This基関数はUNI3.1シグナリング層の実体からST2+SCMP層の実体までのRELEASEメッセージ配送を示します。 原始的にこれを受けたST2+SCMP層の実体は原始的にrelease.respである承認を送ります。 そして、また、この基関数は、UNI3.1シグナリング層の実体と次に、REFUSEメッセージにおける不法なメッセージかタイムアウトなどの異常な状態の検出がわたっているのを示します。 この場合、原始的にこれを受けたST2+SCMP層の実体は継承における原始のrelease.confを受けます。
o release.resp
This primitive sends a request for a RELEASE COMPLETE message
transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling
layer entity.
o release.resp This基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのRELEASE COMPLETEメッセージ転送を求める要求を送ります。
o add-party.req
This primitive sends a request for an ADD PARTY message transfer
from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer
entity. The ST2+ SCMP layer entity that sent this primitive
receives an acknowledgment. If the setup is succeeds the
acknowledgment is an add-party.conf primitive and if the setup
fails it is a drop-party.conf primitive.
o party.req Thisについて付記している基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのADD PARTYメッセージ転送を求める要求を送ります。 原始的にこれを送ったST2+SCMP層の実体は承認を受けます。 セットアップがそうである、成功、承認はparty.confについて付記している基関数であり、セットアップが失敗するなら、それは低下-party.conf基関数です。
o add-party.conf
This primitive indicates an ADD PARTY ACKNOWLEDGE message delivery
from the UNI 3.1 signaling layer entity to the ST2+ SCMP layer
entity.
o party.conf Thisについて付記している基関数はUNI3.1シグナリング層の実体からST2+SCMP層の実体までのADD PARTY ACKNOWLEDGEメッセージ配送を示します。
o drop-party.req
This primitive sends a request for a DROP PARTY message transfer
from the ST2+ SCMP layer entity to the UNI 3.1 signaling layer
entity. The ST2+ SCMP layer entity that sent this primitive
receives an acknowledgment that is a drop-party.conf primitive.
o 低下-party.req This基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのDROP PARTYメッセージ転送を求める要求を送ります。 原始的にこれを送ったST2+SCMP層の実体は原始的に低下-party.confである承認を受けます。
o drop-party.conf
This primitive indicates an ADD PARTY REJECT message delivery, or
indicates a DROP PARTY ACKNOWLEDGE message delivery, or indicates
detection of an abnormal status such as an illegal message or
timeout in the UNI 3.1 signaling layer entity, from the UNI 3.1
signaling layer entity to the ST2+ SCMP layer entity.
o 低下-party.conf This基関数は、ADD PARTY REJECTメッセージ配送を示すか、DROP PARTY ACKNOWLEDGEメッセージ配送を示す、またはUNI3.1シグナリング層の実体における不法なメッセージかタイムアウトなどの異常な状態の検出を示します、UNI3.1シグナリング層の実体からST2+SCMP層の実体まで。
o drop-party.ind
This primitive indicates a DROP PARTY message delivery from the UNI
3.1 signaling layer entity to the ST2+ SCMP layer entity. The ST2+
o 低下-party.ind This基関数はUNI3.1シグナリング層の実体からST2+SCMP層の実体までのDROP PARTYメッセージ配送を示します。 ST2+
Suzuki Informational [Page 27] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[27ページ]のRFC2383ST2+
SCMP layer entity that sent this primitive receives an
acknowledgment that is a drop-party.resp primitive.
原始的にこれを送ったSCMP層の実体が原始的に低下-party.respである承認を受けます。
o drop-party.resp
This primitive sends a request for a DROP PARTY ACKNOWLEDGE message
transfer from the ST2+ SCMP layer entity to the UNI 3.1 signaling
layer entity.
o 低下-party.resp This基関数はST2+SCMP層の実体からUNI3.1シグナリング層の実体までのDROP PARTY ACKNOWLEDGEメッセージ転送を求める要求を送ります。
6.4 VC Style Selection Criteria
6.4 VC様式選択評価基準
The ST2+ over ATM protocol supports PVC, the reverse channel of bi- directional SVC, point-to-point SVC, and point-to-multipoint SVC for ST2+ Data PDU transfer. And SVC supports both upstream and downstream call initiation styles.
ATMプロトコルの上のST2+はPVCを支持します、両性愛者の方向のSVCの逆のチャンネル、ポイントツーポイントSVC、そして、ST2+データPDUのためのポイントツーマルチポイントSVCが移します。 そして、SVCは上流の、そして、川下の両方の呼び出し開始スタイルを支持します。
A 32-bit PVC identifier that is unique between neighboring ST2+ agents is assigned to each PVC. And the reverse channel of the bi- directional point-to-point SVC used by the existing stream is identified by the SID of the stream that occupies the forward channel.
隣接しているST2+エージェントの間でユニークな32ビットのPVC識別子は各PVCに割り当てられます。 そして、SVCが既存の流れで使用した両性愛者の方向のポイントツーポイントの逆のチャンネルは順方向通信路を専念させる流れのSIDによって特定されます。
When the ST2+ agent sets up a stream or changes QoS, the ST2+ agent must select one VC style from these SVC and PVC styles as a hop that is part of the stream. In the ST2+ over ATM protocol, VC style selection criteria depend on the implementation.
ST2+エージェントが流れか変化QoSをセットアップするとき、ST2+エージェントは流れの一部であるホップとしてこれらのSVCとPVCスタイルから1つのVCスタイルを選定しなければなりません。 ST2では、ATMプロトコルの上の+、VCスタイル選択評価基準は実現に依存します。
This subsection describes examples of VC style selection criteria for the ST2+ over ATM protocol as a reference for implementors. Note that the following descriptions in this subsection are not part of the ST2+ over ATM protocol specification.
この小区分は、ATMプロトコルの上でST2+のVCスタイル選択評価基準に関する例を作成者の参照と説明します。 この小区分における以下の記述がATMプロトコル仕様の上のST2+の一部でないことに注意してください。
6.4.1 Examples of PVC selection criteria
6.4.1 PVC選択評価基準に関する例
At least, the ST2+ agent may have to manage the following information for each PVC that can be used by ST2+ Data PDU transfer.
少なくとも、ST2+エージェントはST2+データPDU転送で使用できる各PVCのための以下の情報を管理しなければならないかもしれません。
o PVC identifier
o PVC識別子
o ATM interface identifier in the ST2+ agent
o ST2+エージェントのATMインタフェース識別子
o VPI/VCI
o VPI/VCI
o State of VC: e.g. enabled or disabled, occupied or vacant
o VCの州: 例えば、可能にされる、障害がある、占領される空
o QoS of VC
o VCのQoS
o Nexthop IP address
o Nexthop IPアドレス
Suzuki Informational [Page 28] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[28ページ]のRFC2383ST2+
When a PVC is selected for a hop of a stream, at least confirmations, that is the state of the PVC is vacant and the next hop IP address and QoS are consistent with the requirements from the stream, may be needed.
PVCが流れ、少なくとも確認のホップのために選択されて、すなわち、PVCの州が空であり、次のホップIPアドレスとQoSが流れからの要件と一致しているとき、必要であるかもしれません。
It is also feasible to introduce access lists to each PVC and to consider the access lists in the selection process. Examples of an access list are shown in the following.
また、各PVCにアクセスリストを紹介して、選択の過程によるアクセスリストを考えるのも可能です。 アクセスリストに関する例は以下に示されます。
o Permit or deny use by a stream whose the previous hop is specified.
o 流れで使用を可能にするか、または否定してください。前がだれのものを飛び越すかは指定されます。
o Permit or deny use by a stream whose the origin is specified.
o 可能にするか、または使用がaでだれのものを流すことを否定してください。起源は指定されます。
o Permit or deny use by a stream whose the SID is specified.
o 可能にするか、または使用がaでだれのものを流すことを否定してください。SIDは指定されます。
o Permit or deny use by a stream whose the target is specified.
o 可能にするか、または使用がaでだれのものを流すことを否定してください。目標は指定されます。
o Permit or deny use by a stream whose the target and SAP are
specified.
o 可能にするか、または使用がaでだれのものを流すことを否定してください。目標とSAPは指定されます。
o Any combination of the above.
o 上記のどんな組み合わせ。
6.4.2 Examples of reverse channel of bi-directional SVC selection
criteria
6.4.2 双方向のSVC選択評価基準の逆のチャンネルに関する例
At least, the ST2+ agent may have to manage the following information for each reverse channel of bi-directional SVCs.
少なくとも、ST2+エージェントは双方向のSVCsのそれぞれの逆のチャンネルのために以下の情報を管理しなければならないかもしれません。
o SID of the stream that occupies the forward channel
o 順方向通信路を専念させる流れのSID
o ATM interface identifier in the ST2+ agent
o ST2+エージェントのATMインタフェース識別子
o VPI/VCI
o VPI/VCI
o State of the reverse channel in the VC: e.g. enabled or disabled,
occupied or vacant
o VCの逆のチャンネルの州: 例えば、可能にされる、障害がある、占領される空
o QoS of VC
o VCのQoS
o Nexthop IP address
o Nexthop IPアドレス
When a reverse channel of the bi-directional point-to-point SVC used by the existing stream is selected for a hop of a stream, at least confirmations, that is the state of the channel is vacant and the next hop IP address and QoS are consistent with the requirements from the stream, may be needed.
SVCが既存の流れで使用した双方向のポイントツーポイントの逆のチャンネルが流れ、少なくとも確認のホップのために選ばれて、すなわち、チャンネルの状態が空であり、次のホップIPアドレスとQoSが流れからの要件と一致しているとき、必要であるかもしれません。
Suzuki Informational [Page 29] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[29ページ]のRFC2383ST2+
It is also feasible to introduce selection rules to the ST2+ agent. Examples of selection rule are shown in the following.
また、ST2+エージェントに選択規則を紹介するのも可能です。 選択規則に関する例は以下に示されます。
o Permit reuse of the reverse channel by a stream whose the origin is
one of targets in the stream that occupies the forward channel.
o 流れによる逆チャンネルの再利用を可能にしてください。起源がだれのものでものであるかは中で順方向通信路を専念させる流れを狙います。
o Permit reuse of the reverse channel by a stream whose one of
targets is the origin in the stream that occupies the forward
channel.
o 順方向通信路を専念させる流れで目標の1つが起源である流れによる逆のチャンネルの再利用を可能にしてください。
o Permit reuse of the reverse channel by a stream whose the previous
hop is one of the next hops in the stream that occupies the forward
channel.
o 流れによる逆チャンネルの再利用を可能にしてください。前がだれのものを飛び越すかは、順方向通信路を専念させる流れにおける次のホップの1つです。
o Any combination of the avobe.
o avobeのどんな組み合わせ。
6.4.3 Examples of SVC selection criteria
6.4.3 SVC選択評価基準に関する例
When an SVC is used for a hop of a stream, at first, the ST2+ agent must select point-to-point or point-to-multipoint SVC. Examples of this selection rule are shown in the following.
SVCが初めに流れのホップに使用されるとき、ST2+エージェントはポイントツーポイントかポイントツーマルチポイントSVCを選択しなければなりません。 この選択規則に関する例は以下に示されます。
o If the network supports only point-to-point SVC, select it.
o ネットワークがポイントツーポイントだけSVCを支持するなら、それを選択してください。
o If the network supports point-to-multipoint SVC, select it.
o ネットワークがポイントツーマルチポイントSVCを支持するなら、それを選択してください。
If point-to-point SVC is selected, the ST2+ agent must select upstream or downstream call initiation style. Examples of this selection rule are shown in the following.
ポイントツーポイントSVCが選択されるなら、ST2+エージェントは上流の、または、川下の呼び出し開始スタイルを選択しなければなりません。 この選択規則に関する例は以下に示されます。
o A VC for a stream whose previous hop is specified is initiated from
upstream or downstream.
o 前のホップが指定される流れのためのVCは上流か川下から開始されます。
o A VC for a stream whose next hop is specified is initiated from
upstream or downstream.
o 次のホップが指定される流れのためのVCは上流か川下から開始されます。
o A VC for a stream whose origin is specified is initiated from
upstream or downstream.
o 起源が指定される流れのためのVCは上流か川下から開始されます。
o A VC for a stream whose SID is specified is initiated from upstream
or downstream.
o SIDが指定される流れのためのVCは上流か川下から開始されます。
o A VC for a stream whose target is specified is initiated from
upstream or downstream.
o 目標が指定される流れのためのVCは上流か川下から開始されます。
o A VC for a stream whose target and SAP are specified is initiated
from upstream or downstream.
o だれのaの流れの目標とSAPが指定されるかVCは上流か川下から開始されます。
Suzuki Informational [Page 30] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[30ページ]のRFC2383ST2+
o Any combination of the above.
o 上記のどんな組み合わせ。
6.5 VC Management
6.5 VC管理
This subsection specifies VC management in the ST2+ over ATM protocol.
この小区分はATMプロトコルの上でST2+でVC管理を指定します。
6.5.1 Outgoing call processing of SVC
6.5.1 SVCの発信電話処理
When outgoing call processing of the first leaf of a point-to- multipoint SVC or a point-to-point SVC is required inside the ST2+ SCMP layer entity, a setup.req primitive is sent to the UNI 3.1 signaling layer entity. If the UNI 3.1 signaling layer entity responds with a setup.conf primitive, the call processing is assumed to have succeeded. If the UNI 3.1 signaling layer entity responds with anything other than this primitive, the processing rule is the same as the SVC disconnect processing that is shown in section 6.5.4 and the outgoing call processing is assumed to have failed.
ポイントから多点へのSVCか二地点間SVCの最初の葉の処理がST2+SCMP層の実体、setup.reqの中で原始的に必要であるという外向的な要求がそうときに、UNI3.1に送って、シグナリングは実体を層にします。 setup.confが原始的にUNI3.1シグナリング層の実体が応じるなら、呼び出し処理が成功したと思われます。 UNI3.1シグナリング層の実体がこれを除いた何かで原始的に応じるなら、処理規則はSVCがセクション6.5.4と発信電話で処理が失敗したと思われるのが示される処理を外すのと同じです。
When outgoing call processing of a later leaf of a point-to- multipoint SVC is required, an add-party.req primitive is sent to the UNI 3.1 signaling layer entity. If the UNI 3.1 signaling layer entity responds with an add-party.conf primitive, the call processing is assumed to have succeeded. If the UNI 3.1 signaling layer entity responds with anything other than this primitive, the processing rule is the same as the SVC disconnect processing that is shown in section 6.5.4 and the outgoing call processing is assumed to have failed.
ポイントから多点へのSVCの後の葉の発信電話処理を必要とするとき、UNI3.1シグナリング層の実体にparty.reqについて付記している基関数を送ります。 UNI3.1シグナリング層の実体がparty.confについて付記している基関数で応じるなら、呼び出し処理が成功したと思われます。 UNI3.1シグナリング層の実体がこれを除いた何かで原始的に応じるなら、処理規則はSVCがセクション6.5.4と発信電話で処理が失敗したと思われるのが示される処理を外すのと同じです。
6.5.2 Incoming call processing of SVC
6.5.2 SVCのかかってきた電話処理
When an incoming call processing of SVC is required inside the ST2+ SCMP layer entity, it sets a watchdog timer. The time interval of the timer depends on the implementation.
SVCのかかってきた電話処理がST2+SCMP層の実体で必要であるときに、それはウオッチドッグタイマーを設定します。 タイマの時間間隔は実現によります。
The ST2+ SCMP layer entity waits for a setup.ind primitive indication from the UNI 3.1 signaling layer entity. When this primitive is indicated and the parameters in it are acceptable, the ST2+ SCMP layer entity responds with a setup.resp primitive. If the parameters are not acceptable, the ST2+ SCMP layer entity stops the timer, and if the state of the UNI 3.1 signaling layer entity is U6, the entity responds with a release.resp primitive, and if the state is other than this, the entity responds with a release.req primitive, and then waits for a release.conf primitive response and the incoming call processing is assumed to have failed.
ST2+SCMP層の実体はUNI3.1シグナリング層の実体からsetup.indの原始の指示を待っています。 この基関数が示されて、それのパラメタが許容できるとき、setup.respが原始的にST2+SCMP層の実体は応じます。 パラメタが許容できないで、ST2+SCMP層の実体がタイマを止めて、release.respが原始的に実体がUNI3.1シグナリング層の実体の状態がU6であるなら、応じて、これを除いて、状態があるなら、実体は、release.reqが原始的に応じて、release.confの原始の応答を待っています、そして、かかってきた電話処理が失敗したと思われます。
If the ST2+ SCMP layer entity responds with a setup.resp primitive, then the entity waits for the next primitive indication, and when the next primitive is indicated, the ST2+ SCMP layer entity stops the
setup.respが原始的にST2+SCMP層の実体が応じるなら、実体は次の原始の指示を待っています、そして、次の基関数が示されるとき、ST2+SCMP層の実体は止まります。
Suzuki Informational [Page 31] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[31ページ]のRFC2383ST2+
timer. If a setup-complete.ind primitive is indicated, the incoming call processing is assumed to have succeeded. If the UNI 3.1 signaling layer entity responds with anything other than this primitive or if the timer expires, the processing rule is the same as the SVC disconnect processing that is shown in section 6.5.4 and the incoming call processing is assumed to have failed.
タイマ。 セットアップ-complete.ind基関数が示されるなら、かかってきた電話処理が成功したと思われます。 UNI3.1シグナリング層の実体がこれを除いた何かで原始的に応じるか、またはタイマが期限が切れるなら、処理規則はSVCがセクション6.5.4とかかってきた電話で処理が失敗したと思われるのが示される処理を外すのと同じです。
6.5.3 VC release processing inside ST2+ SCMP layer
6.5.3 VCリリース処理内部のST2+SCMPは層にします。
When a VC release is required inside an ST2+ SCMP layer entity, if the previous hop or next hop is connected with a PVC, the PVC state is set to vacant and the VC release processing is assumed to be completed.
VCリリースがST2+SCMP層の実体で必要であるときに、前のホップか次のホップがPVCに接続されるなら、PVC状態は空の状態で設定されます、そして、VCリリース処理が完成されると思われます。
If the previous hop or next hop is connected with a point-to-point SVC whose reverse channel is occupied, the state of the channel in the VC is set to vacant, the SID information of the VC is updated, and the VC release processing is assumed to be completed.
逆のチャンネルが占領されている二地点間SVCに前のホップか次のホップを接続するなら、空の状態でVCのチャンネルの状態を設定します、そして、VCのSID情報をアップデートします、そして、完成されるとVCリリース処理を思います。
If the previous hop or next hop is connected with a point-to-point SVC whose reverse channel is vacant, if the previous hop is connected with a point-to-multipoint SVC, or if the next hop is connected with a point-to-multipoint SVC and the number of leaves is 1, then the ST2+ SCMP layer entity sends a release.req primitive to the UNI 3.1 signaling layer entity, then waits for a release.conf primitive indication; when one is indicated, the VC release processing is assumed to be completed.
前のホップか次のホップが逆のチャンネルが空である二地点間SVCに接続されるなら、ST2+SCMP層の実体は、前のホップがポイントツーマルチポイントSVCに接続されるか、次のホップがポイントツーマルチポイントに接続されるなら葉のSVCと数が1であるならUNI3.1シグナリング層の実体への原始のrelease.reqを送って、release.confの原始の指示を待っています。 1が示されるとき、VCリリース処理が完成されると思われます。
If the next hop is connected with a point-to-multipoint SVC and the number of leaves is other than 1, the ST2+ SCMP layer entity sends a drop-party.req primitive to the UNI 3.1 signaling layer entity, then waits for a drop-party.conf primitive indication; when one is indicated, the VC release processing is assumed to be completed.
次のホップがポイントツーマルチポイントに接続されるなら1を除いて、葉のSVCと数があって、ST2+SCMP層の実体は、UNI3.1シグナリング層の実体への原始の低下-party.reqを送って、次に、低下-party.confの原始の指示を待っています。 1が示されるとき、VCリリース処理が完成されると思われます。
6.5.4 VC disconnect processing from UNI 3.1 signaling layer
6.5.4 VCはUNI3.1シグナリング層から処理を外します。
If an ST2+ SCMP layer entity corresponds to a UNI 3.1 signaling layer entity, and if the ST2+ SCMP layer entity is sent a release.ind primitive from the UNI 3.1 signaling layer entity, whose cause is a delivery of a RELEASE message, the ST2+ SCMP layer entity responds with a release.resp primitive, and then the VC disconnect processing is assumed to be completed. If the ST2+ SCMP layer entity is sent a release.ind primitive, whose cause is other than the previous case, the ST2+ SCMP layer entity waits for a release.conf primitive response. When a release.conf primitive is indicated, the VC disconnect processing is assumed to be completed.
ST2+SCMP層の実体がUNI3.1シグナリング層の実体に対応している、原因がRELEASEメッセージの配送であるUNI3.1シグナリング層の実体からの原始のrelease.indをST2+SCMP層の実体に送るなら、release.respが原始的にST2+SCMP層の実体はこたえます、そして、次に、VC分離処理が完成されると思われます。 ST2+SCMP層の実体にrelease.indを原始的に送るなら、先の事件、ST2+SCMP層の実体を除いて、原因がだれのものであるかはrelease.confの原始の応答を待っています。 release.conf基関数が示されるとき、VC分離処理が完成されると思われます。
Suzuki Informational [Page 32] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[32ページ]のRFC2383ST2+
Note that if next hops from ST2+ SCMP layer entities are connected with a point-to-multipoint SVC, the ST2+ SCMP layer entities to next hops correspond to a UNI 3.1 signaling layer entity. In this case, if the ST2+ SCMP layer entities are sent release.ind primitives from the UNI 3.1 signaling layer entity, whose cause is the delivery of a RELEASE message, one of the ST2+ SCMP layer entities responds with a release.resp primitive, and then the VC disconnect processing in the entities that are sent release.ind primitives are assumed to be completed. If the ST2+ SCMP layer entities are sent release.ind primitives, whose cause is other than the previous case, the ST2+ SCMP layer entities wait for release.conf primitives responses. When release.conf primitives are indicated, the VC disconnect processing in the entities that are indicated release.ind primitives are assumed to be completed.
ST2+SCMP層の実体からの次のホップがポイントツーマルチポイントSVCに接続されるなら、次のホップへのST2+SCMP層の実体がUNI3.1シグナリング層の実体に対応することに注意してください。 この場合、release.ind基関数を原因がRELEASEメッセージの配送であるUNI3.1シグナリング層の実体からST2+SCMP層の実体に送るなら、release.respが原始的にST2+SCMP層の実体の1つは応じます、そして、次に、VCは基関数が完成されると思われるrelease.indが送られる実体における処理を外します。 release.ind基関数(先の事件を除いて、原因がある)をST2+SCMP層の実体に送るなら、ST2+SCMP層の実体はrelease.conf基関数応答を待っています。 release.conf基関数が示されるとき、VCは基関数が完成されると思われる示されたrelease.indである実体における処理を外します。
If the ST2+ SCMP layer entity is sent a drop-party.ind primitive from the UNI 3.1 signaling layer entity, the ST2+ SCMP layer entity responds with a drop-party.resp primitive, and then the VC disconnect processing is assumed to be completed. If the ST2+ SCMP layer entity is sent a drop-party.conf primitive, the VC disconnect processing is assumed to be completed.
UNI3.1シグナリング層の実体からの原始の低下-party.indをST2+SCMP層の実体に送るなら、ST2+SCMP層の実体は低下-party.respで原始的に応じます、そして、VC分離処理が完成されると思われます。 ST2+SCMP層の実体に低下-party.confを原始的に送るなら、完成されるとVC分離処理を思います。
6.6 Additional SCMP Processing Rules
6.6 追加SCMP処理規則
This subsection specifies the additional SCMP processing rules that are defined in RFC 1819 ST2+ protocol specification. The following additional rules are applied when the previous hop or next hop is connected with an ATM connection in the ST2+ SCMP layer entity.
この小区分はRFC1819ST2+プロトコル仕様に基づき定義される追加SCMP処理規則を指定します。 前のホップか次のホップがST2+SCMP層の実体におけるATM接続に接続されるとき、以下の付則は適用されています。
6.6.1 Additional connect.req processing rules
6.6.1 追加connect.req処理規則
When a connect.req primitive is sent to the ST2+ SCMP layer entity for the next hop, the entity confirms whether or not the VC for the next hop exists.
次のホップのためにST2+SCMP層の実体にconnect.req基関数を送るとき、実体は、次のホップのためのVCが存在するかどうか確認します。
If it does, the entity forwards a CONNECT message that does not include a VC-type common SCMP element to the next hop.
そうするなら、実体はVC-タイプの一般的なSCMP要素を次のホップに含んでいないCONNECTメッセージを転送します。
If it does not, the entity selects a VC style. If the result is a PVC or a reverse channel of a bi-directional point-to-point SVC used by an existing stream, the VC state is set to occupied. The entity forwards a CONNECT message with a VC-type common SCMP element that reflects the result of the selection to the next hop.
そうしないなら、実体はVCスタイルを選択します。 結果がSVCが既存の流れで使用した双方向のポイントツーポイントのPVCか逆のチャンネルであるなら、VC状態は占領されるのに設定されます。 実体は選択の結果を次のホップに反映するVC-タイプの一般的なSCMP要素でCONNECTメッセージを転送します。
6.6.2 Additional connect.ind processing rules
6.6.2 追加connect.ind処理規則
The ST2+ SCMP layer entity for the previous hop confirms whether or not the CONNECT message includes a VC-type common SCMP element.
前のホップのためのST2+SCMP層の実体は、CONNECTメッセージがVC-タイプの一般的なSCMP要素を含んでいるかどうか確認します。
Suzuki Informational [Page 33] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[33ページ]のRFC2383ST2+
If a VC-type common SCMP element is not included and the VC for the next hop exists, a connect.ind primitive is sent to the routing machine. If the VC for the next hop does not exist, a REFUSE message is forwarded to the previous hop.
VC-タイプの一般的なSCMP要素が含まれていなくて、次のホップのためのVCが存在しているなら、connect.ind基関数をルータ・マシンに送ります。 次のホップのためのVCが存在していないなら、REFUSEメッセージを前のホップに転送します。
If a VC-type common SCMP element is included and a point-to-point SVC, whose calling party is the upstream or downstream, or a point- to-multipoint SVC is specified, a connect.ind primitive is sent to the routing machine. If a PVC or a reverse channel of a bi- directional point-to-point SVC used by an existing stream is specified and the specified VC exists, the VC state is set to occupied and a connect.ind primitive is sent to the routing machine. Otherwise, a REFUSE message is forwarded to the previous hop.
VC-タイプの一般的なSCMP要素が含まれているか、そして、二地点間SVC、だれが、パーティーを召集するかは、上流か川下であるか多点へのポイントSVCを指定して、connect.ind基関数をルータ・マシンに送ります。 SVCが既存の流れで使用した両性愛者の方向のポイントツーポイントのPVCか逆のチャンネルが指定されて、指定されたVCが存在しているなら、VC状態を占領されるのに設定します、そして、connect.ind基関数をルータ・マシンに送ります。 さもなければ、REFUSEメッセージを前のホップに転送します。
6.6.3 Additional change.req processing rules
6.6.3 Additional change.req処理規則
When a change.req primitive is sent to the ST2+ SCMP layer entity for the next hop, the entity releases the VC whose process is shown in section 6.5.3.
次のホップのためにST2+SCMP層の実体にchange.req基関数を送るとき、実体は過程がセクション6.5.3で示されるVCをリリースします。
Then, the entity selects a VC style. If the result is a PVC or a reverse channel of a bi-directional point-to-point SVC used by an existing stream, the VC state is set to occupied. The entity forwards a CHANGE message with a VC-type common SCMP element that reflects the result of the selection to the next hop.
そして、実体はVCスタイルを選択します。 結果がSVCが既存の流れで使用した双方向のポイントツーポイントのPVCか逆のチャンネルであるなら、VC状態は占領されるのに設定されます。 実体は選択の結果を次のホップに反映するVC-タイプの一般的なSCMP要素でCHANGEメッセージを転送します。
6.6.4 Additional change.ind processing rules
6.6.4 Additional change.ind処理規則
The ST2+ SCMP layer entity for the previous hop confirms whether the CHANGE message includes a VC-type common SCMP element. If a VC-type common SCMP element is not included, a REFUSE message is forwarded to the previous hop.
前のホップのためのST2+SCMP層の実体は、CHANGEメッセージがVC-タイプの一般的なSCMP要素を含んでいるかどうか確認します。 VC-タイプの一般的なSCMP要素が含んでいないなら、REFUSEメッセージを前のホップに転送します。
If a VC-type common SCMP element is included, the entity releases the VC whose process is shown in section 6.5.3. If the element specifies a point-to-point SVC, whose calling party is the upstream or downstream, or a point-to-multipoint SVC, a change.ind primitive is sent to the routing machine. If a PVC or a reverse channel of a bi- directional point-to-point SVC used by an existing stream is specified and the specified VC exists, the VC state is set to occupied and a change.ind primitive is sent to the routing machine. Otherwise, a REFUSE message is forwarded to the previous hop.
VC-タイプの一般的なSCMP要素が含まれているなら、実体は過程がセクション6.5.3で示されるVCをリリースします。 要素が二地点間SVC(起呼側は、上流、川下、またはaポイントツーマルチポイントSVCである)を指定するなら、change.ind基関数をルータ・マシンに送ります。 SVCが既存の流れで使用した両性愛者の方向のポイントツーポイントのPVCか逆のチャンネルが指定されて、指定されたVCが存在しているなら、VC状態を占領されるのに設定します、そして、change.ind基関数をルータ・マシンに送ります。 さもなければ、REFUSEメッセージを前のホップに転送します。
6.6.5 Additional accept.req processing rules
6.6.5 追加accept.req処理規則
When an accept.req primitive is sent to the ST2+ SCMP layer entity for the previous hop, the entity confirms the state of the UNI 3.1 signaling layer entity. If the state of the entity is other than U0
前のホップのためにST2+SCMP層の実体にaccept.req基関数を送るとき、実体はUNI3.1シグナリング層の実体の状態を確認します。 U0を除いて、実体の状態があるなら
Suzuki Informational [Page 34] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[34ページ]のRFC2383ST2+
or U10, the accept.req primitive is queued and is processed after the state changes to U0 or U10.
U10、または、状態がU0かU10に変化した後に、accept.req基関数は、列に並ばせられて、処理されます。
If the state of the entity is U0 or U10, the ST2+ SCMP layer entity confirms whether or not the VC for the previous hop exists. If it does, an ACCEPT message is forwarded to the previous hop.
実体の状態がU0かU10であるなら、ST2+SCMP層の実体は、前のホップのためのVCが存在するかどうか確認します。 そうするなら、ACCEPTメッセージを前のホップに転送します。
If it does not and the CONNECT or CHANGE message that corresponds to the accept.req primitive specified a point-to-point SVC whose calling party is the upstream or a point-to-multipoint SVC, then the entity processes an incoming call that is shown in section 6.5.2. If the incoming call processing succeeds, an ACCEPT message is forwarded to the previous hop. If the CONNECT or CHANGE message that corresponds to the accept.req primitive specified a point-to-point SVC whose calling party is downstream, the entity converts from the IP address of the previous hop to the ATM address, and then the entity processes an outgoing call that is shown in section 6.5.1. If the outgoing call processing succeeds, an ACCEPT message is forwarded to the previous hop. For cases other than those described above or if the incoming or outgoing call processing fails, a REFUSE message is forwarded to the previous hop and a disconnect.ind primitive is sent to the routing machine.
accept.reqに原始的に対応するそれがそうしないか、そして、CONNECTかCHANGEメッセージが起呼側が上流かポイントツーマルチポイントSVCである二地点間SVCを指定して、次に、実体の過程はセクション6.5.2で示されるかかってきた電話です。 かかってきた電話処理が成功するなら、ACCEPTメッセージを前のホップに転送します。 accept.reqに原始的に対応するCONNECTかCHANGEメッセージが起呼側が川下である二地点間SVCを指定したなら、実体はATMアドレス、および前のホップのIPアドレスから次に、実体の過程までセクション6.5.1で示される発信電話を変換します。 発信電話処理が成功するなら、ACCEPTメッセージを前のホップに転送します。 それら以外のケースが上について説明したか、または入って来るか外向的な呼び出し処理が失敗するなら、REFUSEメッセージを前のホップに転送します、そして、disconnect.ind基関数をルータ・マシンに送ります。
6.6.6 Additional accept.ind processing rules
6.6.6 追加accept.ind処理規則
When an ACCEPT message is processed in the ST2+ SCMP layer entity for the next hop, the entity confirms the state of the UNI 3.1 signaling layer entity. If the state of the entity is other than U0 or U10, the ACCEPT message is queued and is processed after the state changes to U0 or U10.
ACCEPTメッセージが次のホップのためにST2+SCMP層の実体で処理されるとき、実体はUNI3.1シグナリング層の実体の状態を確認します。 U0かU10を除いて、実体の状態があるなら、状態がU0かU10に変化した後に、ACCEPTメッセージは、列に並ばせられて、処理されます。
If the state of the entity is U0 or U10, the ST2+ SCMP layer entity confirms whether or not the VC for the next hop exists. If it does, an accept.ind primitive is sent to the routing machine.
実体の状態がU0かU10であるなら、ST2+SCMP層の実体は、次のホップのためのVCが存在するかどうか確認します。 それがそうするなら、accept.ind基関数をルータ・マシンに送ります。
If it does not and the CONNECT or CHANGE message that corresponds to the ACCEPT message specified a point-to-point SVC whose calling party is the upstream or a point-to-multipoint SVC, then the entity converts from the IP address of the next hop to the ATM address, and then the entity processes an outgoing call that is shown in section 6.5.1. If the outgoing call processing succeeds, an accept.ind primitive is sent to the routing machine. If the CONNECT or CHANGE message that corresponds to the ACCEPT message specified a point-to- point SVC whose calling party is downstream, the entity processes an incoming call that is shown in section 6.5.2. If the incoming call processing succeeds, an accept.ind primitive is sent to the routing machine. For cases other than those described above or if the incoming or outgoing call processing fails, a refuse.ind primitive is
ACCEPTメッセージに対応するそれがそうしないか、そして、CONNECTかCHANGEメッセージが起呼側が上流かポイントツーマルチポイントSVCである二地点間SVCを指定しました、IPからの実体転向者が扱うATMアドレスへの次のホップのその時、そして、実体はセクション6.5.1で示される発信電話を処理します。 発信電話処理が成功するなら、accept.ind基関数をルータ・マシンに送ります。 ACCEPTメッセージに対応するCONNECTかCHANGEメッセージがポイントからポイントへの起呼側が川下であるSVCを指定したなら、実体はセクション6.5.2で示されるかかってきた電話を処理します。 かかってきた電話処理が成功するなら、accept.ind基関数をルータ・マシンに送ります。 それら以外のケースが上について説明したか、または入って来るか外向的な呼び出し処理が失敗するなら、refuse.ind基関数は失敗します。
Suzuki Informational [Page 35] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[35ページ]のRFC2383ST2+
sent to the routing machine and a DISCONNECT message is forwarded to the next hop.
ルータ・マシンとDISCONNECTに送って、次のホップにメッセージを転送します。
6.6.7 Additional disconnect.req processing rules
6.6.7 追加disconnect.req処理規則
At first, the ST2+ SCMP layer entity for the next hop forwards a DISCONNECT message to the next hop.
初めに、次のホップのためのST2+SCMP層の実体はDISCONNECTメッセージを次のホップに転送します。
And then, after the disconnect.req processing, if there are no more targets that are connected downstream of the entity and the entity is not waiting for an ACCEPT or REFUSE message response from targets, the entity releases the VC whose process is shown in section 6.5.3.
そして、川下に接続される実体のそれ以上の目標が全くなくて、また実体が目標からACCEPTかREFUSEメッセージ応答を待っていないなら、disconnect.req処理の後に、実体はプロセスがセクション6.5.3で見せられるVCをリリースします。
6.6.8 Additional disconnect.ind processing rules
6.6.8 追加disconnect.ind処理規則
AT first, after the disconnect.ind processing, if there are no more targets that are connected downstream of the ST2+ SCMP layer entity for the previous hop and the entity is not waiting for an ACCEPT or REFUSE message response from targets, the entity releases the VC whose process is shown in section 6.5.3.
最初に、disconnect.ind処理の後のAT、川下に接続される前のホップのためのST2+SCMP層の実体のそれ以上の目標が全くなくて、また実体が目標からACCEPTかREFUSEメッセージ応答を待っていないなら、実体はプロセスがセクション6.5.3で見せられるVCをリリースします。
And then, the entity sends a disconnect.ind primitive to the routing machine.
そして、実体はルータ・マシンへの原始のdisconnect.indを送ります。
6.6.9 Additional refuse.req processing rules
6.6.9 追加refuse.req処理規則
At first, the ST2+ SCMP layer entity for the previous hop forwards a REFUSE message to the previous hop.
初めに、前のホップのためのST2+SCMP層の実体はREFUSEメッセージを前のホップに転送します。
And then, after the refuse.req processing, if there are no more targets that are connected downstream of the entity and the entity is not waiting for an ACCEPT or REFUSE message response from targets, the entity releases the VC whose process is shown in section 6.5.3.
そして、川下に接続される実体のそれ以上の目標が全くなくて、また実体が目標からACCEPTかREFUSEメッセージ応答を待っていないなら、refuse.req処理の後に、実体はプロセスがセクション6.5.3で見せられるVCをリリースします。
6.6.10 Additional refuse.ind processing rules
6.6.10 追加refuse.ind処理規則
At first, after the refuse.ind processing, if there are no more targets that are connected downstream of the ST2+ SCMP layer entity for the next hop and the entity is not waiting for an ACCEPT or REFUSE message response from targets, the entity releases the VC whose process is shown in section 6.5.3.
初めに、川下に接続される次のホップのためのST2+SCMP層の実体のそれ以上の目標が全くなくて、また実体が目標からACCEPTかREFUSEメッセージ応答を待っていないなら、refuse.ind処理の後に、実体はプロセスがセクション6.5.3で見せられるVCをリリースします。
And then, the entity sends a refuse.ind primitive to the routing machine.
そして、実体はルータ・マシンへの原始のrefuse.indを送ります。
Suzuki Informational [Page 36] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[36ページ]のRFC2383ST2+
6.6.11 SVC disconnect processing
6.6.11 SVCは処理から切断します。
When the ST2+ SCMP layer entity for the previous hop is sent a SVC disconnect processing from the UNI 3.1 signaling layer entity and then the SVC disconnect processing is completed, the entity forwards a REFUSE message to the previous hop and sends a disconnect.ind primitive to the routing machine.
SVC分離処理をUNI3.1シグナリング層の実体から前のホップに送って、次に、SVCが処理から切断するのでST2+SCMP層の実体が完成するとき、実体は、REFUSEメッセージを前のホップに転送して、ルータ・マシンへの原始のdisconnect.indを送ります。
When the ST2+ SCMP layer entity for the next hop is sent a SVC disconnect processing from the UNI 3.1 signaling layer entity and then the SVC disconnect processing is completed, the entity sends a refuse.ind primitive to the routing machine and forwards a DISCONNECT message to the previous hop.
SVC分離処理をUNI3.1シグナリング層の実体から次のホップに送って、次に、SVCが処理から切断するのでST2+SCMP層の実体が完成するとき、実体は、ルータ・マシンへの原始のrefuse.indを送って、DISCONNECTメッセージを前のホップに転送します。
6.7 UNI 3.1 Signaling Information Element Coding Rules
6.7 規則をコード化するUNI3.1シグナリング情報要素
The ST2+ over ATM protocol does not specify the coding rules needed for the following information elements in UNI 3.1 signaling. The usages of these information elements are specified in [10].
ATMプロトコルの上の+がするST2はUNI3.1シグナリングで以下の情報要素に必要であるコード化規則を指定しません。 これらの情報要素の使用法は[10]で指定されます。
o Protocol discriminator
o プロトコル識別子
o Call reference
o 参照に電話をしてください。
o Message type
o メッセージタイプ
o Message length
o メッセージ長
o Call state
o 呼び出し状態
o Called party number
o パーティー番号と呼ばれます。
o Called party subaddress
o パーティー「副-アドレス」と呼ばれます。
o Calling party number
o 起呼側番号
o Calling party subaddress
o 起呼側「副-アドレス」
o Cause
o 原因
o Connection identifier
o 接続識別子
o Broadband repeat indicator
o 広帯域の反復インディケータ
o Restart indicator
o 再開インディケータ
o Broadband sending complete
o 完全な状態で発信するブロードバンド
Suzuki Informational [Page 37] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[37ページ]のRFC2383ST2+
o Transit network selection
o トランジットネットワーク選択
o Endpoint reference
o 終点参照
o Endpoint state
o 終点州
6.7.1 ATM adaptation layer parameters coding
6.7.1 ATM適合層のパラメタコード化
The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must include an ATM adaptation layer parameters information element. The CONNECT message may or may not include this element. The coding rules for the fields are as follows.
ATMプロトコルの上の+がそうしなければならないST2のSETUPとADD PARTYメッセージはATM適合層のパラメタ情報要素を含んでいます。 CONNECTメッセージはこの要素を含むかもしれません。 分野へのコード化規則は以下の通りです。
o The AAL Type is set to AAL5.
o AAL TypeはAAL5に用意ができています。
o The value of the Forward maximum CPCS size field is set to the same
as that of the MaxMsgSize field in the CONNECT SCMP message
corresponding to the SETUP or ADD PARTY message.
o Forwardの最大のCPCSサイズ分野の値はSETUPかADD PARTYメッセージに対応するCONNECT SCMPメッセージのMaxMsgSize分野のものと同じくらいへのセットです。
o If the VC is established as a point-to-point call, the value of the
Backward maximum CPCS size field is set the same as that of the
Forward maximum CPCS size field. If the VC is established as a
point-to-multipoint call, the value of the Backward maximum CPCS
size field is set to zero.
o VCが電話すると二地点間書き立てられるなら、Backwardの最大のCPCSサイズ分野の値はForwardの最大のCPCSサイズ分野のものとして同じように設定されます。 VCがポイントツーマルチポイント電話すると書き立てられるなら、Backwardの最大のCPCSサイズ分野の値はゼロに設定されます。
o The SSCS type is set to null.
o SSCSタイプはヌルに用意ができています。
6.7.2 ATM traffic descriptor coding
6.7.2 ATMトラフィック記述子コード化
If the Null FlowSpec is specified in the ST2+ over ATM protocol, the coding rules for the fields in the ATM traffic descriptor information element in the SETUP message are as follows.
Null FlowSpecがATMプロトコルの上でST2+で指定されるなら、SETUPメッセージのATMトラフィック記述子情報要素の分野へのコード化規則は以下の通りです。
o The value of the Forward PCR (CLP=0+1) field depends on the
specification of the ATM network. The Forward PCR (CLP=0+1) field
in each ATM interface in an implementation must be configurable to
any value between zero and 16,777,215.
o Forward PCR(CLP=0+1)分野の値はATMネットワークの仕様に依存します。 実装におけるそれぞれのATMインタフェースのForward PCR(CLP=0+1)分野はゼロと1677万7215の間のどんな値にも構成可能であるに違いありません。
o If the VC is established as a point-to-point call, the value of the
Backward PCR (CLP=0+1) field is set the same as that of the Forward
PCR (CLP=0+1) field. If the VC is established as a point-to-
multipoint call, the value of the Backward PCR (CLP=0+1) field is
set to zero.
o VCが電話すると二地点間書き立てられるなら、Backward PCR(CLP=0+1)分野の値はForward PCR(CLP=0+1)分野のものとして同じように設定されます。 VCが電話するとポイントから多点に書き立てられるなら、Backward PCR(CLP=0+1)分野の値はゼロに設定されます。
o The Best effort indication must be present.
o Best取り組み指示は存在していなければなりません。
If the Controlled-Load Service FlowSpec is specified, the coding rules for the fields are as follows.
Controlled-負荷Service FlowSpecが指定されるなら、分野へのコード化規則は以下の通りです。
Suzuki Informational [Page 38] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[38ページ]のRFC2383ST2+
o The value of the Forward PCR (CLP=0+1) field depends on the
specification of the ATM network. The Forward PCR (CLP=0+1) field
in each ATM interface in an implementation must be configurable to
any value between zero and 16,777,215.
o Forward PCR(CLP=0+1)分野の値はATMネットワークの仕様に依存します。 実装におけるそれぞれのATMインタフェースのForward PCR(CLP=0+1)分野はゼロと1677万7215の間のどんな値にも構成可能であるに違いありません。
o If the VC is established as a point-to-point call, the value of the
Backward PCR (CLP=0+1) field is set the same as that of the Forward
PCR (CLP=0+1) field. If the VC is established as a point-to-
multipoint call, the value of the Backward PCR (CLP=0+1) field is
set to zero.
o VCが電話すると二地点間書き立てられるなら、Backward PCR(CLP=0+1)分野の値はForward PCR(CLP=0+1)分野のものとして同じように設定されます。 VCが電話するとポイントから多点に書き立てられるなら、Backward PCR(CLP=0+1)分野の値はゼロに設定されます。
o The method for calculating the Forward SCR (CLP=0+1) field is shown
in section 5.
o Forward SCR(CLP=0+1)分野について計算するためのメソッドはセクション5で示されます。
o If the VC is established as a point-to-point call, the value of the
Backward SCR (CLP=0+1) field is set the same as that of the Forward
SCR (CLP=0+1) field. If the VC is established as a point-to-
multipoint call, this field must not be present.
o VCが電話すると二地点間書き立てられるなら、Backward SCR(CLP=0+1)分野の値はForward SCR(CLP=0+1)分野のものとして同じように設定されます。 VCが電話するとポイントから多点に書き立てられるなら、この分野は存在しているはずがありません。
o The method for calculating the Forward MBS (CLP=0+1) field is shown
in section 5.
o Forward MBS(CLP=0+1)分野について計算するためのメソッドはセクション5で示されます。
o If the VC is established as a point-to-point call, the value of the
Backward MBS (CLP=0+1) field is set the same as that of the Forward
MBS (CLP=0+1) field. If the VC is established as a point-to-
multipoint call, this field must not be present.
o VCが電話すると二地点間書き立てられるなら、Backward MBS(CLP=0+1)分野の値はForward MBS(CLP=0+1)分野のものとして同じように設定されます。 VCが電話するとポイントから多点に書き立てられるなら、この分野は存在しているはずがありません。
o The Best effort indication, Tagging backward, and Tagging forward
fields must not be present.
o Best取り組み指示、Tagging、後方とTaggingの前進の分野は存在しているはずがありません。
6.7.3 Broadband bearer capability coding
6.7.3 広帯域の運搬人能力コード化
If the Null FlowSpec is specified in the ST2+ over ATM protocol, the coding rules for the fields in the Broadband bearer capability information element in the SETUP message are as follows.
Null FlowSpecがATMプロトコルの上でST2+で指定されるなら、SETUPメッセージのBroadband運搬人能力情報要素の分野へのコード化規則は以下の通りです。
o The Bearer class depends on the specification of the ATM network.
The Bearer class in each ATM interface in an implementation must be
configurable as either BCOB-X or BCOB-C. BCOB-X is recommended as
the default configuration.
o BearerのクラスはATMネットワークの仕様に依存します。 実装におけるそれぞれのATMインタフェースのBearerのクラスはBCOB-XかBCOB-Cのどちらかとして構成可能であるに違いありません。 BCOB-Xはデフォルト設定としてお勧めです。
o The Traffic type and Timing requirements fields must not be
present.
o Trafficはタイプします、そして、Timing要件分野は存在しているはずがありません。
o The Susceptibility to clipping field is set to not susceptible to
clipping.
o 切り取り分野へのSusceptibilityは切り取りように影響されやすく用意ができていません。
Suzuki Informational [Page 39] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[39ページ]のRFC2383ST2+
o If the VC is established as a point-to-point call, the User plane
connection configuration field is set to point-to-point, and if the
VC is established as a point-to-multipoint call, it is set to
point-to-multipoint.
o VCが電話すると二地点間書き立てられるなら、User飛行機接続構成分野はポイントツーポイントに設定されます、そして、VCがポイントツーマルチポイント電話すると書き立てられるなら、それはポイントツーマルチポイントに設定されます。
If the Controlled-Load Service FlowSpec is specified, the coding rules for the fields are as follows.
Controlled-負荷Service FlowSpecが指定されるなら、分野へのコード化規則は以下の通りです。
o The Bearer class depends on the specification of the ATM network.
The Bearer class in each ATM interface in an implementation must be
configurable as either BCOB-X or BCOB-C. BCOB-X is recommended as
the default configuration.
o BearerのクラスはATMネットワークの仕様に依存します。 実装におけるそれぞれのATMインタフェースのBearerのクラスはBCOB-XかBCOB-Cのどちらかとして構成可能であるに違いありません。 BCOB-Xはデフォルト設定としてお勧めです。
o If the Bearer class is BCOB-X, the Traffic type and Timing
requirements fields depend on the specification of the ATM network.
The Traffic type and Timing requirements fields in each ATM
interface in an implementation must be configurable as either no
indication or VBR and Not required, respectively. No indication is
recommended as the default configuration. If the Bearer class is
BCOB-C, the Traffic type and Timing requirements fields must not be
present.
o BearerのクラスがBCOB-Xであるなら、Trafficはタイプします、そして、Timing要件分野はATMネットワークの仕様に依存します。 Trafficはタイプします、そして、VBRと指示がないNotのどちらかがそれぞれ必要であるように実装におけるそれぞれのATMインタフェースのTiming要件分野は構成可能であるに違いありません。 どんな指示もデフォルト設定としてお勧めではありません。 BearerのクラスがBCOB-Cであるなら、Trafficはタイプします、そして、Timing要件分野は存在しているはずがありません。
o The Susceptibility to clipping field depends on the specification
of the ATM network. The Susceptibility to clipping field in each
ATM interface in an implementation must be configurable as either
not susceptible to clipping or susceptible to clipping. Not
susceptible to clipping is recommended as the default
configuration.
o 切り取り分野へのSusceptibilityはATMネットワークの仕様によります。 実装におけるそれぞれのATMインタフェースの切り取り分野へのSusceptibilityは切り取りように切り取りように影響されやすくないか影響されやすいとして構成可能であるに違いありません。 影響されやすくない、デフォルト設定として切り取りに推薦されます。
o If the VC is established as a point-to-point call, the User plane
connection configuration field is set to point-to-point, and if the
VC is established as a point-to-multipoint call, it is set to
point-to-multipoint.
o VCが電話すると二地点間書き立てられるなら、User飛行機接続構成分野はポイントツーポイントに設定されます、そして、VCがポイントツーマルチポイント電話すると書き立てられるなら、それはポイントツーマルチポイントに設定されます。
6.7.4 Broadband high layer information coding
6.7.4 広帯域の高い層の情報コード化
The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must include a Broadband high layer information information element. The coding rules for the fields are as follows.
ATMプロトコルの上の+がそうしなければならないST2のSETUPとADD PARTYメッセージはBroadbandの高い層の情報情報要素を含んでいます。 分野へのコード化規則は以下の通りです。
o The High layer information type is set to User specific.
o High層の情報タイプはUserに特定のセットです。
o The first 6 bytes in the High layer information field are set to
the SID of the stream corresponding to the VC.
o High層の情報フィールドの最初の6バイトはVCに対応するストリームのSIDに設定されます。
Suzuki Informational [Page 40] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[40ページ]のRFC2383ST2+
6.7.5 Broadband low layer information coding
6.7.5 広帯域の低い層の情報コード化
The SETUP and ADD PARTY messages in the ST2+ over ATM protocol must include a Broadband low layer information information element. The CONNECT message may or may not include this element. The coding rules for the fields are as follows.
ATMプロトコルの上の+がそうしなければならないST2のSETUPとADD PARTYメッセージはBroadbandの低層の情報情報要素を含んでいます。 CONNECTメッセージはこの要素を含むかもしれません。 分野へのコード化規則は以下の通りです。
o The User information layer 3 protocol field is set to ISO/IEC TR
9577.
o User情報層3のプロトコル分野はISO/IEC TR9577に設定されます。
o The IPI field is set to IEEE 802.1 SNAP (0x80).
o IPI分野はIEEE802.1SNAP(0×80)に設定されます。
o The OUI field is set to IANA (0x00-00-5E).
o OUI分野はIANA(0×00 00-5E)に設定されます。
o The PID field is set to ST2+ (TBD).
o PID分野はST2+(TBD)に設定されます。
6.7.6 QoS parameter coding
6.7.6 QoSパラメータ符号化
If the Null FlowSpec is specified in the ST2+ over ATM protocol, the coding rules for the fields in the QoS parameter in the SETUP message are as follows.
Null FlowSpecがATMプロトコルの上でST2+で指定されるなら、SETUPメッセージのQoSパラメタの分野へのコード化規則は以下の通りです。
o The QoS class forward and QoS class backward fields are set to QoS
class 0.
o QoSクラスフォワードとQoSのクラスの後方の分野はQoSクラス0に設定されます。
If the Controlled-Load Service FlowSpec is specified, the coding rules for the fields are as follows.
Controlled-負荷Service FlowSpecが指定されるなら、分野へのコード化規則は以下の通りです。
o The QoS class forward and QoS class backward fields depend on the
specification of the ATM network. The QoS class forward and QoS
class backward fields in each ATM interface in an implementation
must be configurable as either QoS class 0 or QoS class 3. QoS
class 0 is recommended as the default configuration.
o QoSクラスフォワードとQoSのクラスの後方の分野はATMネットワークの仕様に依存します。 実装におけるそれぞれのATMインタフェースのQoSクラスフォワードとQoSのクラスの後方の分野はQoSクラス0かQoSクラス3のどちらかとして構成可能であるに違いありません。 QoSクラス0はデフォルト設定としてお勧めです。
7. Security Considerations
7. セキュリティ問題
The ST2+ over ATM protocol modifies RFC 1819 ST2+ protocol, but basically these modifications are minimum extensions for ATM support and bug fixes, so they do not weaken the security of the ST2+ protocol.
ATMプロトコルの上のST2+がRFC1819ST2+プロトコルを変更しますが、基本的に、これらの変更がATMサポートとバグフィックスのための最小の拡大であるので、それらはST2+プロトコルのセキュリティを弱めません。
The ST2+ over ATM protocol specifies protocol interaction between ST2+ and UNI 3.1, and this does not weaken the security of the UNI 3.1 protocol.
ATMプロトコルの上の+が指定するST2はST2+とUNI3.1との相互作用について議定書の中で述べます、そして、これはUNI3.1プロトコルのセキュリティを弱めません。
In an ST2+ agent that processes an incoming call of SVC, if the incoming SETUP message contains the calling party number and if it is verified and passed by the ATM network or it is provided by the
入って来るSETUPメッセージが起呼側番号を含んでいて、ATMネットワークがそれを確かめて、通過するか、またはそれで提供するならSVCのかかってきた電話を処理するST2+エージェント
Suzuki Informational [Page 41] RFC 2383 ST2+ over ATM August 1998
気圧1998年8月での鈴木の情報[41ページ]のRFC2383ST2+
network, then it is feasible to use the calling party number for part of the calling party authentication to strengthen security.
ネットワーク、その時、起呼側認証の一部が安全を強化するのに起呼側番号を使用するのは可能です。
References
参照
[1] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
of Real-time Services in an IP-ATM Network Architecture", RFC
1821, August 1995.
[1]ボーデン、M.、クローリー、E.、デイビー、B.、およびS.Batsell、「IP-気圧ネットワークアーキテクチャにおけるリアルタイムでサービスの統合」、RFC1821(1995年8月)。
[2] Jackowski, S., "Native ATM Support for ST2+", RFC 1946, May 1996.
[2] Jackowski(S.、「ST2+のネイティブの気圧サポート」、RFC1946)は1996がそうするかもしれません。
[3] S. Damaskos and A. Gavras, "Connection Oriented Protocols over
ATM: A case study", Proc. SPIE, Vol. 2188, pp.226-278, February
1994.
[3] S.DamaskosとA.Gavras、「接続は気圧でプロトコルを適応しました」。 「ケーススタディ」、Proc。 SPIE、Vol.2188、pp.226-278、1994年2月。
[4] Delgrossi, L., and L. Berger, Ed., "Internet Stream Protocol
Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819,
August 1995.
[4] Delgrossi、L.、およびL.バーガー(エド)、「インターネットストリームプロトコルバージョン2(ST2)は仕様を議定書の中で述べます--バージョンST2+」、RFC1819、1995年8月。
[5] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[5]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[6] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997.
1997年9月の[6]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[7]Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[8] Garrett, M., and M. Borden, "Interoperation of Controlled-Load
Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[8] ギャレット、M.、およびM.ボーデン、「気圧との制御負荷サービスと保証されたサービスのInteroperation」、RFC2381、1998年8月。
[9] Ghanwani, A., Pace, J., and V. Srinivasan, "A Framework for
Providing Integrated Services Over Shared and Switched LAN
Technologies", Work in Progress.
[9] Ghanwani, A., Pace, J., and V. Srinivasan, "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", Work in Progress.
[10] The ATM Forum, "ATM User-Network Interface Specification
Version 3.1", September 1994.
[10] The ATM Forum, "ATM User-Network Interface Specification Version 3.1", September 1994.
[11] The ATM Forum, "ATM User-Network Interface (UNI) Signaling
Specification Version 4.0", af-sig-0061.000, July 1996.
[11] The ATM Forum, "ATM User-Network Interface (UNI) Signaling Specification Version 4.0", af-sig-0061.000, July 1996.
[12] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)-
Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network
Interface (UNI) Layer 3 Specification for Basic Call/Connection
Control", ITU-T Recommendation Q.2931, September 1995.
[12] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)- Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control", ITU-T Recommendation Q.2931, September 1995.
Suzuki Informational [Page 42] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 42] RFC 2383 ST2+ over ATM August 1998
[13] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)-
Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network
Interface Layer 3 Specification for Point-to-Multipoint
Call/Connection Control", ITU-T Recommendation Q.2971, October
1995.
[13] ITU-T, "Broadband Integrated Services Digital Network (B-ISDN)- Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface Layer 3 Specification for Point-to-Multipoint Call/Connection Control", ITU-T Recommendation Q.2971, October 1995.
[14] ITU-T, "B-ISDN Protocol Reference Model and its Application",
CCITT Recommendation I.321, April 1991.
[14] ITU-T, "B-ISDN Protocol Reference Model and its Application", CCITT Recommendation I.321, April 1991.
[15] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) type 5 specification",
Draft new ITU-T Recommendation I.363.5, September 1995.
[15] ITU-T, "B-ISDN ATM Adaptation Layer (AAL) type 5 specification", Draft new ITU-T Recommendation I.363.5, September 1995.
[16] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[16] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[17] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January
1994.
[17] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January 1994.
[18] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
February 1995.
[18] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
[19] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next
Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[19] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
Suzuki Informational [Page 43] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 43] RFC 2383 ST2+ over ATM August 1998
Acknowledgments
Acknowledgments
ATM is a huge technology and without the help of many colleagues at NTT who are involved in ATM research and development, it would have been impossible for me to complete this protocol specification. I would like to thank Hideaki Arai and Naotaka Morita of the NTT Network Strategy Planning Dept., Shin-ichi Kuribayashi, Jun Aramomi, and Takumi Ohba of the NTT Network Service Systems Labs., and also Hisao Uose and Yoshikazu Oda of the NTT Multimedia Networks Labs. for their valuable comments and discussions.
ATM is a huge technology and without the help of many colleagues at NTT who are involved in ATM research and development, it would have been impossible for me to complete this protocol specification. I would like to thank Hideaki Arai and Naotaka Morita of the NTT Network Strategy Planning Dept., Shin-ichi Kuribayashi, Jun Aramomi, and Takumi Ohba of the NTT Network Service Systems Labs., and also Hisao Uose and Yoshikazu Oda of the NTT Multimedia Networks Labs. for their valuable comments and discussions.
And I would also like to especially thank Eric Crawley of Gigapacket Networks, John Wroclawski of MIT, Steven Jackowski of Net Manage, Louis Berger of FORE Systems, Steven Willis of Bay Networks, Greg Burch of Qosnetics, and Denis Gallant, James Watt, and Joel Halpern of Newbridge Networks for their valuable comments and suggestions.
And I would also like to especially thank Eric Crawley of Gigapacket Networks, John Wroclawski of MIT, Steven Jackowski of Net Manage, Louis Berger of FORE Systems, Steven Willis of Bay Networks, Greg Burch of Qosnetics, and Denis Gallant, James Watt, and Joel Halpern of Newbridge Networks for their valuable comments and suggestions.
Also this specification is based on various discussions during NTT Multimedia Joint Project with NACSIS. I would like to thank Professor Shoichiro Asano of the National Center for Science Information Systems for his invaluable advice in this area.
Also this specification is based on various discussions during NTT Multimedia Joint Project with NACSIS. I would like to thank Professor Shoichiro Asano of the National Center for Science Information Systems for his invaluable advice in this area.
Author's Address
Author's Address
Muneyoshi Suzuki NTT Multimedia Networks Laboratories 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585, Japan
Muneyoshi Suzuki NTT Multimedia Networks Laboratories 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585, Japan
Phone: +81-422-59-2119 Fax: +81-422-59-2829 EMail: suzuki@nal.ecl.net
Phone: +81-422-59-2119 Fax: +81-422-59-2829 EMail: suzuki@nal.ecl.net
Suzuki Informational [Page 44] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 44] RFC 2383 ST2+ over ATM August 1998
Appendix A. RFC 1819 ST2+ Errata
Appendix A. RFC 1819 ST2+ Errata
A.1 4.3 SCMP Reliability
A.1 4.3 SCMP Reliability
The following sentence in the second paragraph:
The following sentence in the second paragraph:
< For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the
< For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the
should be changed to
should be changed to
> For some SCMP messages (CONNECT, CHANGE, and JOIN) the
> For some SCMP messages (CONNECT, CHANGE, and JOIN) the
A.2 4.4.4 User Data
A.2 4.4.4 User Data
The following sentence:
The following sentence:
< option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and < REFUSE messages. The format of the UserData parameter is shown in
< option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and < REFUSE messages. The format of the UserData parameter is shown in
should be changed to
should be changed to
> option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, NOTIFY, > and REFUSE messages. The format of the UserData parameter is shown in
> option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, NOTIFY, > and REFUSE messages. The format of the UserData parameter is shown in
A.3 5.3.2 Other Cases
A.3 5.3.2 Other Cases
The following sentence:
The following sentence:
< CONNECT with a REFUSE message with the affected targets specified in < the TargetList and an appropriate ReasonCode (StreamExists).
< CONNECT with a REFUSE message with the affected targets specified in < the TargetList and an appropriate ReasonCode (StreamExists).
should be changed to
should be changed to
> CONNECT with a REFUSE message with the affected targets specified in > the TargetList and an appropriate ReasonCode (TargetExists).
> CONNECT with a REFUSE message with the affected targets specified in > the TargetList and an appropriate ReasonCode (TargetExists).
A.4 5.5.1 Mismatched FlowSpecs
A.4 5.5.1 Mismatched FlowSpecs
The following sentence:
The following sentence:
< notifies the processing ST agent which should respond with ReasonCode < (FlowSpecMismatch).
< notifies the processing ST agent which should respond with ReasonCode < (FlowSpecMismatch).
should be changed to
should be changed to
> notifies the processing ST agent which should respond with a REFUSE > message with ReasonCode (FlowSpecMismatch).
> notifies the processing ST agent which should respond with a REFUSE > message with ReasonCode (FlowSpecMismatch).
Suzuki Informational [Page 45] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 45] RFC 2383 ST2+ over ATM August 1998
A.5 6.2.1 Problems in Stream Recovery
A.5 6.2.1 Problems in Stream Recovery
The following sentence:
The following sentence:
< some time after a failure. As a result, the ST agent attempting the < recovery may receive ERROR messages for the new CONNECTs that are < ... < failure, and will interpret the new CONNECT as resulting from a < routing failure. It will respond with an ERROR message with the < appropriate ReasonCode (StreamExists). Since the timeout that the ST < ... < remnants of the broken stream will soon be torn down by a DISCONNECT < message. Therefore, the ST agent that receives the ERROR message with < ReasonCode (StreamExists) should retransmit the CONNECT message after
< some time after a failure. As a result, the ST agent attempting the < recovery may receive ERROR messages for the new CONNECTs that are < ... < failure, and will interpret the new CONNECT as resulting from a < routing failure. It will respond with an ERROR message with the < appropriate ReasonCode (StreamExists). Since the timeout that the ST < ... < remnants of the broken stream will soon be torn down by a DISCONNECT < message. Therefore, the ST agent that receives the ERROR message with < ReasonCode (StreamExists) should retransmit the CONNECT message after
should be changed to
should be changed to
> some time after a failure. As a result, the ST agent attempting the > recovery may receive REFUSE messages for the new CONNECTs that are > ... > failure, and will interpret the new CONNECT as resulting from a > routing failure. It will respond with a REFUSE message with the > appropriate ReasonCode (TargetExists). Since the timeout that the ST > ... > remnants of the broken stream will soon be torn down by a DISCONNECT > message. Therefore, the ST agent that receives the REFUSE message with > ReasonCode (TargetExists) should retransmit the CONNECT message after
> some time after a failure. As a result, the ST agent attempting the > recovery may receive REFUSE messages for the new CONNECTs that are > ... > failure, and will interpret the new CONNECT as resulting from a > routing failure. It will respond with a REFUSE message with the > appropriate ReasonCode (TargetExists). Since the timeout that the ST > ... > remnants of the broken stream will soon be torn down by a DISCONNECT > message. Therefore, the ST agent that receives the REFUSE message with > ReasonCode (TargetExists) should retransmit the CONNECT message after
A.6 6.3 Stream Preemption}
A.6 6.3 Stream Preemption}
The following sentence:
The following sentence:
< (least important) to 256 (most important). This value is
< (least important) to 256 (most important). This value is
should be changed to
should be changed to
> (least important) to 255 (most important). This value is
> (least important) to 255 (most important). This value is
A.7 10.2 Control PDUs
A.7 10.2 Control PDUs
The following sentence:
The following sentence:
<o Reference is a transaction number. Each sender of a request control < message assigns a Reference number to the message that is unique < with respect to the stream.
<o Reference is a transaction number. Each sender of a request control < message assigns a Reference number to the message that is unique < with respect to the stream.
should be changed to
should be changed to
Suzuki Informational [Page 46] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 46] RFC 2383 ST2+ over ATM August 1998
>o Reference is a transaction number. Each sender of a request control > message assigns a Reference number to the message that is unique > with respect to the stream for messages generated by each agent.
>o Reference is a transaction number. Each sender of a request control > message assigns a Reference number to the message that is unique > with respect to the stream for messages generated by each agent.
A.8 10.3.4 Origin
A.8 10.3.4 Origin
The following:
The following:
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | PCode = 5 | PBytes | NextPcol |OriginSAPBytes | < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | PCode = 5 | PBytes | NextPcol |OriginSAPBytes | < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be changed to
should be changed to
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PCode = 4 | PBytes | NextPcol |OriginSAPBytes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PCode = 4 | PBytes | NextPcol |OriginSAPBytes | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.9 10.4.1 ACCEPT
A.9 10.4.1 ACCEPT
The following sentence:
The following sentence:
<o IPHops is the number of IP encapsulated hops traversed by the < stream. This field is set to zero by the origin, and is incremented < at each IP encapsulating agent.
<o IPHops is the number of IP encapsulated hops traversed by the < stream. This field is set to zero by the origin, and is incremented < at each IP encapsulating agent.
should be changed to
should be changed to
>o IPHops is the number of IP encapsulated hops traversed by the > stream.
>o IPHops is the number of IP encapsulated hops traversed by the > stream.
A.10 10.4.2 ACK
A.10 10.4.2 ACK
The following:
The following:
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | OpCode = 2 | 0 | TotalBytes | < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | OpCode = 2 | 0 | TotalBytes | < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be changed to
should be changed to
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OpCode = 2 | 0 | TotalBytes = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OpCode = 2 | 0 | TotalBytes = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suzuki Informational [Page 47] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 47] RFC 2383 ST2+ over ATM August 1998
A.11 10.4.3 CHANGE
A.11 10.4.3 CHANGE
The following sentence:
The following sentence:
<o I (bit 7) is used to indicate that the LRM is permitted to interrupt
<o I (bit 7) is used to indicate that the LRM is permitted to interrupt
should be changed to
should be changed to
>o I (bit 9) is used to indicate that the LRM is permitted to interrupt
>o I (bit 9) is used to indicate that the LRM is permitted to interrupt
A.12 10.4.7 HELLO
A.12 10.4.7 HELLO
The following:
The following:
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | OpCode = 7 |R| 0 | TotalBytes | < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | OpCode = 7 |R| 0 | TotalBytes | < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be changed to
should be changed to
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OpCode = 7 |R| 0 | TotalBytes = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OpCode = 7 |R| 0 | TotalBytes = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.13 10.4.9 JOIN-REJECT
A.13 10.4.9 JOIN-REJECT
The following sentence:
The following sentence:
<o Reference contains a number assigned by the ST agent sending the < REFUSE for use in the acknowledging ACK.
<o Reference contains a number assigned by the ST agent sending the < REFUSE for use in the acknowledging ACK.
should be changed to
should be changed to
>o Reference contains a number assigned by the ST agent sending the > JOIN-REJECT for use in the acknowledging ACK.
>o Reference contains a number assigned by the ST agent sending the > JOIN-REJECT for use in the acknowledging ACK.
A.14 10.4.13 STATUS-RESPONSE
A.14 10.4.13 STATUS-RESPONSE
The following sentence:
The following sentence:
< possibly Groups of the stream. It the full target list can not fit in
< possibly Groups of the stream. It the full target list can not fit in
should be changed to
should be changed to
> possibly Groups of the stream. If the full target list can not fit in
> possibly Groups of the stream. If the full target list can not fit in
Suzuki Informational [Page 48] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 48] RFC 2383 ST2+ over ATM August 1998
A.15 10.5.3 ReasonCode
A.15 10.5.3 ReasonCode
The following:
The following:
< 32 PCodeUnknown Control PDU has a parameter with an invalid < PCode.
< 32 PCodeUnknown Control PDU has a parameter with an invalid < PCode.
should be removed because a common SCMP element with an unknown PCode is equivalent to the UserData (RFC 1819, Section 10.3.8).
should be removed because a common SCMP element with an unknown PCode is equivalent to the UserData (RFC 1819, Section 10.3.8).
Suzuki Informational [Page 49] RFC 2383 ST2+ over ATM August 1998
Suzuki Informational [Page 49] RFC 2383 ST2+ over ATM August 1998
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Suzuki Informational [Page 50]
Suzuki Informational [Page 50]
一覧
スポンサーリンク
