[要約] RFC 2383は、ST2+ over ATMプロトコルの仕様を定義しています。目的は、ATMネットワーク上でST2+プロトコルを使用して通信を行うためのガイドラインを提供することです。
Network Working Group M. Suzuki
Request for Comments: 2383 NTT
Category: Informational August 1998
ST2+ over ATM Protocol Specification - UNI 3.1 Version
ST2 + over ATMプロトコル仕様-UNI 3.1バージョン
Status of this 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）The Internet Society（1998）。全著作権所有。
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ベースのプロトコルを指定しています。 ST2 + over ATMプロトコルは、ST2 +ツリー構造ストリームの1つのホップと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.
ST2 + over ATMプロトコルは、ATMおよび非ATMネットワーク全体でリソース予約通信を実現し、UNI 3.1 / 4.0シグナリング機能を拡張し、UNI 4.0 LIJシグナリング制限を削減するように設計されています。
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.
ST2 + over ATMプロトコルの仕様は、RFC 1819 ST2 +の改訂と、B-ISDNプロトコル参照モデルの3つのプレーンに対応する、ユーザープレーン、管理プレーン、およびコントロールプレーン上のST2 +とATM間のプロトコル相互作用の仕様で構成されています。 。
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.
ST2 + over ATMプロトコルは、ST2 +ツリー構造ストリームの1つのホップと1つのATM接続のマッチングをサポートするように設計されています。ポイントツーマルチポイントATM接続のみでST2 +ツリー構造ストリーム全体をサポートするようには設計されていません。
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ネットワーク全体でリソース予約通信を可能にするように設計されています。
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 UNI 3.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サイズのネゴシエーションをサポートします。 UNI 3.1 / 4.0は、ポイントツーポイントコールの着信側との、またはポイントツーマルチポイントコールの最初のリーフとの最大CPCS_SDU（つまり、MTU）ネゴシエーションのみをサポートします。
o Reduces UNI 4.0 LIJ signaling limitations.
o UNI 4.0 LIJシグナリングの制限を緩和します。
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.
ST2 + over ATMプロトコルは、ST2 + SCMP拡張を使用して、ルートからリーフへのUNI 4.0 LIJコールID通知をサポートします。リーフでのLIJコールIDディスカバリーは、UNI 4.0の未解決の主要な問題の1つであり、ATMプロトコル上のST2 +がソリューションを提供します。
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.
注：UNI 3.1バージョンのST2 + over ATMプロトコルは、上記の機能をサポートしていません。 UNI 3.1 / 4.0バージョンでサポートされます。
The ST2+ over ATM protocol is designed to achieve the following goals.
ST2 + over ATMプロトコルは、次の目標を達成するように設計されています。
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フォーラムプライベートUNI 3.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.
注：ST2 + over ATMプロトコルのUNI 3.1バージョンは、UNI 4.0をサポートしていません。 UNI 3.1 / 4.0バージョンでサポートされます。
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に1つのVCを定義します。このVCは他のST2 +ホップと共有されておらず、このST2 +ホップは複数のVCに分割されていません。
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 RFC 1483 [16] IPv4カプセル化と共存します。
o Coexist with RFC 1577 [17] ATMarp.
o RFC 1577 [17] ATMarpと共存します。
o Coexist with RFC 1755 [18] ATM signaling for IPv4.
o RFC 1755 [18] IPv4の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アドレス解決プロトコルの両方から独立しているため、ST2 + over ATMプロトコルは次のプロトコルを指定しません。
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:
ST2 + over ATMプロトコルはUNIに指定されているため、次のものとは無関係です。
o NNI protocol
o プロトコル
o Router/switch architecture
o ルーター/スイッチのアーキテクチャ
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].
ST2 + over ATMプロトコルは、ユーザー、管理、およびコントロールプレーン上のST2 +とATM間の相互作用を指定します。これは、ITU-T勧告I.321 B-ISDNプロトコルリファレンスモデル[14]の3つのプレーンに対応しています。
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
+--------||-------
Fig. 2.1: User plane protocol stack.
図2.1：ユーザープレーンプロトコルスタック。
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|
+---------+ +---------+ +---------+---------+ +---------+
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でもサポートされます。これらのフィールドを相互にマッピングすることは可能です。 ST2 + over ATMプロトコルは、STヘッダーのPriフィールドをATMセルのCLPフィールドにマップするオプション機能を指定します。ただし、実装者は、現在のATM標準化はタグ付けをサポートしない傾向があることに注意する必要があります。
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.
管理プレーンは、UNI 3.1トラフィック管理用のNull FlowSpec、Controlled-Load Service [5] FlowSpec、Granted Service [6] FlowSpecマッピングルール[8]を指定します。管理プレーンプロトコルスタックを図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 |
| |
+---------------------------------+
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.
注：ST2 + over ATMプロトコルのUNI 3.1バージョンは保証サービスをサポートしていません。 UNI 3.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.
ST2 + over ATMプロトコルは、統合サービスのST FlowSpec形式を指定します。基本的に、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.
ST2 + over ATMプロトコルは、CHANGEメッセージのIビットが1に設定され、CHANGEメッセージがストリーム内のすべてのターゲットに影響を与える場合、CHANGEメッセージ（RFC 1819、セクション4.6.5）を使用してFlowSpecの変更をサポートします。これは、UNI 3.1がQoSの変更をサポートしていないためです。 ST2 + over ATMプロトコルは、古い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.
ST2 + over ATMプロトコルは、ストリームのプリエンプションをサポートしていません（RFC 1819、セクション6.3）。これは、統合サービスFlowSpecが優先順位の概念をサポートしていないためです。
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（RFC 1819、セクション9.2）はサポートしていません。 ST2 + FlowSpecは有用なサービスを指定しますが、レシーバーへの異種QoSをサポートするにはデータリンク層が必要です。現在のATM標準は、受信者への異種QoSをサポートしていません。
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.
コントロールプレーンは、ST2 + SCMP PDUをAAL5 [15] PDUにカプセル化するための規則、ST2 + SCMPとST2 +データのPVC管理間の関係、およびST2 + SCMPとUNI 3.1シグナリング間のプロトコル相互作用[10]を指定します。コントロールプレーンプロトコルスタックを図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
+--------||-------
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.
ST2 + over ATMプロトコルは、ST2 + SCMPを転送するVC（SVC / PVC）をカバーしません。 IPv4転送用のVCはST2 + SCMP転送に使用でき、実装ではST2 + SCMP転送用に特定のVCを提供できます。これらのVCの選択は、実装によって異なります。
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宛先アドレスにルーティングするためのST2 +とIPv4の方向が常に同じであるとは限らないことにも注意する必要があります。
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.
ST2 + over ATMプロトコルは、ST2 +データPDU転送用にSVCとPVCの両方をサポートします。 SVCを使用する場合、ST2 +およびATM層は、それぞれST2 + SCMPおよびUNI 3.1シグナリングを使用して、順次接続を確立します。 ST2 +データ接続を確立および解放するためのST2 + SCMPおよびUNI 3.1シグナリングメッセージフローの例を図2.5に示します。ここで、（S）はST2 +エンティティを、（Q）はUNI 3.1シグナリングエンティティを意味します。
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
Fig. 2.5: Example of ST2+ SCMP and UNI 3.1 signaling message flows.
図2.5：ST2 + SCMPおよびUNI 3.1シグナリングメッセージフローの例。
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.
UNI 3.1 / 4.0は、VCスタイルとして、PVC、ポイントツーポイントSVC、およびポイントツーマルチポイントSVCを指定します。ただし、実際のATMネットワーク環境、特に公衆ATM WANでは、PVCと双方向ポイントツーポイントSVCのみがサポートされます。さまざまなVCスタイルをサポートするために、ST2 + over ATMプロトコルは、ST2 +データPDU転送用に次のVCスタイルをサポートしています。
o PVC
o 塩ビ
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 ダウンストリーム側（LIJ）から開始されたポイントツーマルチポイントSVC。
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.
注：UNI 3.1バージョンのST2 + over ATMプロトコルは、LIJをサポートしていません。 LIJはUNI 3.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 +ストリーム構築プロセス（RFC 1819、セクション4.1.1）から独立していることに注意する必要があります。これは、ST2 + over ATMプロトコルがUNIでST2 +データホップを確立するためのプロセスを指定し、ST2 +ストリームの構築プロセスが別のレイヤーに属しているためです。 SVC開始側は、ST2 +エージェント間の運用ポリシーと請求ポリシーに基づいて決定する必要があります。これは基本的に、送信者指向および受信者指向のST2 +ストリーム構築プロセスから独立しています。
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 )
\ / \ /
~~~~~ ~~~~~
Fig. 2.6: Example of ST2+ SCMP interworking.
図2.6：ST2 + SCMPインターワーキングの例。
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.
ST2 + over ATMプロトコルを指定するには、RFC 1819 ST2 +の機能を拡張して、ATMをサポートする必要があります。ただし、現在のATM標準がRFC 1819 ST2 +の仕様の一部をサポートすることは困難です。このセクションでは、RFC 1819 ST2 +の拡張、制限、サポート、および変更された機能を指定します。 RFC 1819の正誤表は付録Aにあります。
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.
ST2 + over ATMプロトコルは、統合サービスのST FlowSpec形式を指定します。基本的に、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-Load 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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3.1: Format of ST FlowSpec for Controlled-Load Service.
図3.1：Controlled-LoadサービスのST FlowSpecのフォーマット。
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-Loadサービスの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バージョンを識別します。統合サービスのST FlowSpecバージョン番号は8です。
The Ver (Message Format Version) field identifies the Integrated Services FlowSpec message format version. The current version is zero.
Ver（メッセージフォーマットバージョン）フィールドは、Integrated Services FlowSpecメッセージフォーマットバージョンを識別します。現在のバージョンはゼロです。
The Overall Length field for the Controlled-Load Service is 7 words.
Controlled-Loadサービスの全長フィールドは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番号（サービスID番号）フィールドは、統合サービスを識別します。 Integrated Services FlowSpecがCONNECTまたはCHANGEメッセージにある場合、SVC番号フィールドの値は1です。ACCEPT、NOTIFY、またはSTATUS-RESPONSEメッセージにある場合、SVC番号フィールドの値は5です。
The SVC Length (Service-specific Data Length) field for the Controlled-Load Service is 6 words.
Controlled-LoadサービスのSVC長（サービス固有のデータ長）フィールドは6ワードです。
The Param Num (Parameter Number) field is 127.
パラメータ番号（パラメータ番号）フィールドは127です。
The Flags (Per-parameter Flags) field is zero.
フラグ（パラメーターごとのフラグ）フィールドはゼロです。
The Param Length (Length of Per-parameter Data) field is 5 words.
パラメータの長さ（パラメータごとのデータの長さ）フィールドは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.
トークンバケットレート[r]、トークンバケットサイズ[b]、ピークデータレート[p]、最小ポリシングユニット[m]、および最大パケットサイズ[M]フィールドの定義は、[5]に記載されています。詳細については、[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.
SCMPメッセージにFlowSpec要素を作成するST2 +エージェントは、すべてのフィールドに有効な値を割り当てる必要があります。他のエージェントは、要素の値を変更してはなりません。
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フィールドを使用して、オリジンまたはオリジンとして機能する中間エージェントに戻されます。
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-Loadサービスの元の定義では、[m]フィールドの値は[M]フィールドの値以下である必要があります。ただし、Controlled-Loadサービスの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]フィールドの値は65,535以下でなければなりません。 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メッセージを生成する必要があります。
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.
注：ST2 + over ATMプロトコルのUNI 3.1バージョンは保証サービスをサポートしていません。 UNI 3.1 / 4.0バージョンでサポートされます。
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.
ST2 + over ATMプロトコルは、さまざまなVCスタイルをサポートするために使用されるVCタイプを指定する追加の共通SCMP要素を指定します。 VCとのホップを確立するCONNECTメッセージとCHANGEメッセージには、VCタイプの共通SCMP要素が含まれている必要があります。この要素は、隣接するST2 +エージェント間で有効ですが、前のホップまたは次のホップのST2 +エージェントを超えて伝播してはなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
注：ST2 + over ATMプロトコルのUNI 3.1バージョンはVCType 5をサポートしていません。UNI3.1 / 4.0バージョンでサポートされます。
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コールIDを識別します。このフィールドは、VCTypeフィールドが5の場合にのみ有効です。
The extension of the Reason Code (RFC 1819, Section 10.5.3) to the ST2+ over ATM protocol is shown below.
理由コード（RFC 1819、セクション10.5.3）をST2 + over ATMプロトコルに拡張したものを以下に示します。
57 CantChange Partial changes not supported. 58 NoRecover Stream recovery not supported.
57 CantChange部分的な変更はサポートされていません。 58 NoRecoverストリームの回復はサポートされていません。
In the following case, the ST2+ over ATM protocol supports stream FlowSpec changes by using the CHANGE message.
次のケースでは、ST2 + over ATMプロトコルは、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およびNビットが1に設定され、ReasonCodeがCantChangeに設定されたREFUSEメッセージが上流に伝播されます。
o The I and/or G-bits are set to zero.
o IビットまたはGビット、あるいはその両方がゼロに設定されています。
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.
ST2 + over ATMプロトコルは、ST2 + FlowSpecをサポートしていません（RFC 1819、セクション9.2）。 ST2 + FlowSpecは有用なサービスを指定しますが、レシーバーへの異種QoSをサポートするにはデータリンク層が必要です。現在のATM標準は、受信者への異種QoSをサポートしていません。
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.
ST2 + over ATMプロトコルは、ストリームのプリエンプションをサポートしていません（RFC 1819、セクション6.3）。これは、統合サービスFlowSpecが優先順位の概念をサポートしていないためです。
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メッセージ（RFC 1819、セクション10.4.7）をサポートしていない可能性があるため、HELLOメッセージ（RFC 1819、セクション6.1.2）を使用したST2 +エージェント障害検出。これは、ATMには適切な障害検出メカニズムがあり、ST2 +データとST2 + SCMPが別のVCを介して転送されるため、ST2 + over ATMプロトコルでリンク障害を検出するにはHELLOメッセージでは不十分であるためです。
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ビットが1に設定されたCONNECTメッセージ（RFC 1819、セクション4.4.1）のNoRecoverオプションを選択する必要があります。これは、RFC 1819（セクション5.3.2、6.2、および6.2.1）は不明確で不完全です。したがって、リンク障害が発生し、複数の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.
ST2 + over ATMプロトコルは、ストリームの回復をサポートしていません。リカバリーが必要な場合、アプリケーションはそれをサポートする必要があります。 NoRecoverオプションが選択されていないCONNECTメッセージは失敗します。次に、Nビットが1に設定され、ReaseonCodeがNoRecoverに設定されたREFUSEメッセージがアップストリームに伝播されます。
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.
ST2 + over ATMプロトコルは、サブネットリソースの共有をサポートしていません（RFC 1819、セクション7.1.4）。これは、ATMがMAC層の概念をサポートしていないためです。
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.
ST2 + over ATMプロトコルは、このプロトコルにIPカプセル化を実装する必要がないため、STのIPカプセル化（RFC 1819、セクション8.7）をサポートしていません。
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.
ST2 + over ATMプロトコルは、IPマルチキャスト（RFC 1819、セクション8.8）をサポートしていません。これは、このプロトコルがSTのIPカプセル化をサポートしていないためです。
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 + over ATMプロトコルはST2 +プロトコル処理ルールを変更します。
Modifications of the CONNECT, JOIN, and JOIN-REJECT message processing rules in the ST2+ over ATM protocol are described in the following.
ST2 + over ATMプロトコルのCONNECT、JOIN、および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メッセージを作成するターゲットは、Referenceフィールドと同じ値をLnkReferenceフィールドに割り当てます。
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メッセージを作成するエージェントは、JOINメッセージのLnkReferenceフィールドと同じ値を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メッセージを作成するエージェントは、JOINメッセージのLnkReferenceフィールドと同じ値を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フィールド処理ルールとは異なることに注意してください。
The modified JOIN-REJECT control message in the ST2+ over ATM protocol is shown in Fig. 3.3
ST2 + over ATMプロトコルの変更されたJOIN-REJECTコントロールメッセージを図3.3に示します。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3.3: JOIN-REJECT Control Message.
図3.3：JOIN-REJECT制御メッセージ。
The TargetList is assigned the same TargetList in the JOIN message as the one that corresponds to the JOIN-REJECT message.
TargetListには、JOIN-REJECTメッセージに対応するものと同じTargetListがJOINメッセージで割り当てられます。
This section specifies the AAL5 PDU encapusulation for the ST2+ Data PDU.
このセクションでは、ST2 +データPDUのAAL5 PDUカプセル化を指定します。
The ST2+ data layer entity on the user plane of the ST2+ over ATM protocol provides the following services to the upper layer.
ST2 + over ATMプロトコルのユーザープレーン上のST2 +データレイヤーエンティティは、上位レイヤーに次のサービスを提供します。
o st2p_unitdata.req
o st2p_unitdata.req
o st2p_unitdata.ind
o st2p_unitdata.ind
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 ( pri, sid, data )
st2p_unitdata.reqプリミティブは、ST2 +データPDU転送の要求をST2 +データレイヤーエンティティに送信します。プリミティブのセマンティクスは次のとおりです。st2p_unitdata.req（pri、sid、data）
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を指定します。 dataパラメーターは、転送するST2 +データを指定します。
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 + Data PDUのSIDを示します。 dataパラメータは、配信されたST2 +データを示します。ステータスは、配信されたST2 +データが破損しているかどうかを示すオプションのパラメーターです。
The requirements for the AAL5 layer on the ST2+ over ATM user plane are as follows:
ST2 + over ATMユーザープレーンのAAL5レイヤーの要件は次のとおりです。
o The SSCS must be null.
o SSCSはnullでなければなりません。
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配信オプションの選択は実装によって異なるため、受信側がこのオプションを選択できる場合とできない場合があります。
The AAL5 layer entity on the ST2+ over ATM user plane provides the following services to the ST2+ data layer.
ST2 + over ATMユーザープレーンのAAL5レイヤーエンティティは、ST2 +データレイヤーに次のサービスを提供します。
o AAL5_UNITDATA.req
o AAL5_UNITDATA.req
o AAL5_UNITDATA.ind
o AAL5_UNITDATA.ind
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（DATA、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パラメーターは、転送されるユーザー間データを指定します。
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（DATA、CPCS_LP、CPCS_UU、STATUS [オプション]）
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配信オプションが選択されている場合にのみ有効です。
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 + Data PDUはAAL5 CPCS_PDUのペイロードにマッピングされます。
+-------+---------------------------+
| ST | ST2+ data | ST2+
| header| | Data PDU
+-------+---------------------------+
: :
: :
+---------------------------------------+--------+
| CPCS_PDU |PAD|CPCS_PDU| AAL5
| payload | |trailer | CPCS_PDU
+---------------------------------------+--------+
Fig. 4.1: Mapping of ST2+ data to AAL5 CPCS_PDU payload.
図4.1：ST2 +データのAAL5 CPCS_PDUペイロードへのマッピング。
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（低優先度）または0（高優先度）は永続的に割り当てられるか、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表示フィールドの値がゼロに設定されています。
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のステータスに割り当てられます。
The value of MTU is Maximum CPCS_SDU size.
MTUの値は、最大CPCS_SDUサイズです。
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.
管理プレーンは、UNI 3.1トラフィック管理用のヌルFlowSpec、制御負荷サービスFlowSpec、および保証サービスFlowSpecマッピングルールを指定します。
The Null FlowSpec is mapped to the UBR (VBR with the Best Effort Indicator).
Null FlowSpecはUBR（ベストエフォートインジケーター付きのVBR）にマップされます。
The value of the PCR (CLP=0+1) is shown in section 6.7.2.
PCRの値（CLP = 0 + 1）はセクション6.7.2に示されています。
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-Load 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,
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.
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-Load FlowSpecの[p]および[m]フィールドの値は無視されます。
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.
注：ST2 + over ATMプロトコルのUNI 3.1バージョンは保証サービスをサポートしていません。 UNI 3.1 / 4.0バージョンでサポートされます。
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 + SCMPとPVC管理との関係、およびST2 + SCMPとUNI 3.1シグナリング間のプロトコルの相互作用について説明します。
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互換のカプセル化、RFC 1483およびRFC 1483拡張に基づくAAL5カプセル化が指定されています。どちらを使用するかの選択は、実装によって異なります。
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.
ST2 + over ATMプロトコルは、ST2 + SCMPを転送するVC（SVC / PVC）をカバーしません。 IPv4転送用のVCはST2 + SCMP転送に使用でき、実装ではST2 + SCMP転送用に特定のVCを提供できます。これらのVCの選択は、実装によって異なります。
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 + Data 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
+---------------------------------------+--------+
Fig. 6.1: ST2+ Data PDU conpatible encapsulation.
図6.1：ST2 +データPDU互換カプセル化。
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.
RFC 1483ベースのカプセル化を図6.2に示します。ルーテッドプロトコル形式のRFC 1483 LLCカプセル化を備えた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
+---------------------------------------+--------+
Fig. 6.2: RFC 1483 base encapsulation.
図6.2：RFC 1483ベースのカプセル化。
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の値は0x00-00- 00、PIDの値は0x08-00です。 IPv4およびST2 + SCMPの分類は、IPv4またはSTヘッダーの最初の4ビットにあるIPバージョン番号によって決定されます。
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).
RFC 1483拡張ベースのカプセル化は、OUIの値が0x00-00-5E（IANA）であり、PIDの値が0xXX-XX（TBD）であることを除いて、RFC 1483ベースのカプセル化と同じです。
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のRFC 1483ベースのカプセル化は理想的ですが、WSまたはPCのドライバーソフトウェアでIPv4処理を変更する必要があります。したがって、RFC 1483ベースのカプセル化は実装が難しい場合があります。このカプセル化は、この問題を解決するように設計されています。
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.
RFC 1819 ST2 +はSCMPステートマシンを指定していません。また、ST2 + over ATMプロトコルは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、エラー、タイムアウト処理を終了し、信頼性の高い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このプリミティブは、CONNECTメッセージ転送の要求をST2 + SCMPレイヤーエンティティに送信します。
o change.req This primitive sends a request for a CHANGE message transfer to the ST2+ SCMP layer entity.
o change.reqこのプリミティブは、CHANGEメッセージ転送の要求をST2 + SCMPレイヤーエンティティに送信します。
o accept.ind This primitive indicates an ACCEPT message delivery from the ST2+ SCMP layer entity.
o accept.indこのプリミティブは、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このプリミティブは、DISCONNECTメッセージ転送の要求をST2 + SCMPレイヤーエンティティに送信します。
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このプリミティブは、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このプリミティブは、ST2 + SCMPレイヤーエンティティからのCONNECTメッセージ配信を示します。
o change.ind This primitive indicates a CHANGE message delivery from the ST2+ SCMP layer entity.
o change.indこのプリミティブは、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このプリミティブは、ACCEPTメッセージ転送の要求をST2 + SCMPレイヤーエンティティに送信します。
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このプリミティブは、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このプリミティブは、REFUSEメッセージ転送の要求をST2 + SCMPレイヤーエンティティに送信します。
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 machines. These are defined in [10, 12, 13].
ST2 + over ATMコントロールプレーンのUNI 3.1シグナリングレイヤエンティティは、ST2 + SCMPレイヤエンティティに次のサービスを提供します。 ST2 + over ATMプロトコルは、UNI 3.1シグナリングステートマシンを指定していません。これらは[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このプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.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このプリミティブは、UNI 3.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このプリミティブは、UNI 3.1シグナリングレイヤーエンティティからST2 + SCMPレイヤーエンティティへのSETUPメッセージ配信を示します。このプリミティブを受信したST2 + SCMPレイヤーエンティティは、確認応答を送信します。セットアップが受け入れられた場合、確認応答はsetup.respプリミティブであり、セットアップが拒否された場合、UNI 3.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このプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.1シグナリングレイヤーエンティティへのCONNECTメッセージ転送のリクエストを送信します。このプリミティブを送信したST2 + SCMPレイヤーエンティティは、確認応答を受け取ります。セットアップが完了した場合の確認はsetup-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 setup-complete.indこのプリミティブは、UNI 3.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このプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.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 to the ST2+ SCMP layer entity.
o release.confこのプリミティブは、RELEASE COMPLETEメッセージの配信を示すか、UNI 3.1シグナリングレイヤーエンティティのステータスがU11の場合のRELEASEメッセージの配信を示すか、UNI 3.1での不正なメッセージやタイムアウトなどの異常なステータスの検出を示します。 UNI 3.1信号層エンティティから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 release.indこのプリミティブは、UNI 3.1シグナリングレイヤーエンティティのステータスがU11以外の場合に、UNI 3.1シグナリングレイヤーエンティティからST2 + SCMPレイヤーエンティティへのRELEASEメッセージの配信を示します。このプリミティブを受信したST2 + SCMPレイヤーエンティティは、release.respプリミティブである確認応答を送信します。また、このプリミティブは、UNI 3.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このプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.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 add-party.reqこのプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.1シグナリングレイヤーエンティティへのADD PARTYメッセージ転送のリクエストを送信します。このプリミティブを送信したST2 + SCMPレイヤーエンティティは、確認応答を受け取ります。セットアップが成功した場合の確認はadd-party.confプリミティブであり、セットアップが失敗した場合はdrop-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 add-party.confこのプリミティブは、UNI 3.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 drop-party.reqこのプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.1シグナリングレイヤーエンティティへのDROP PARTYメッセージ転送のリクエストを送信します。このプリミティブを送信したST2 + SCMPレイヤーエンティティは、drop-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 drop-party.confこのプリミティブは、ADD PARTY REJECTメッセージの配信を示すか、DROP PARTY ACKNOWLEDGEメッセージの配信を示すか、UNI 3.1からのUNI 3.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+ SCMP layer entity that sent this primitive receives an acknowledgment that is a drop-party.resp primitive.
o drop-party.indこのプリミティブは、UNI 3.1シグナリングレイヤーエンティティからST2 + SCMPレイヤーエンティティへのDROP PARTYメッセージ配信を示します。このプリミティブを送信したST2 + SCMPレイヤーエンティティは、drop-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 drop-party.respこのプリミティブは、ST2 + SCMPレイヤーエンティティからUNI 3.1シグナリングレイヤーエンティティへのDROP PARTY ACKNOWLEDGEメッセージ転送のリクエストを送信します。
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.
ST2 + over ATMプロトコルは、PVC、双方向SVCの逆方向チャネル、ポイントツーポイントSVC、およびポイントツーマルチポイントSVCをサポートして、ST2 +データPDU転送をサポートします。また、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.
各PVCには、隣接するST2 +エージェント間で一意の32ビット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 + over 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.
このサブセクションでは、ST2 + over ATMプロトコルのVCスタイル選択基準の例を、実装者のためのリファレンスとして説明します。このサブセクションの以下の説明は、ST2 + over ATMプロトコル仕様の一部ではないことに注意してください。
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 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.
oネクストホップIPアドレスストリームのホップに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 発信元が指定されているストリームによる使用を許可または拒否します。
o Permit or deny use by a stream whose the SID is specified.
o SIDが指定されているストリームによる使用を許可または拒否します。
o Permit or deny use by a stream whose the target is specified.
o ターゲットが指定されているストリームによる使用を許可または拒否します。
o Permit or deny use by a stream whose the target and SAP are specified.
o ターゲットと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 +エージェントは、双方向SVCのリバースチャネルごとに次の情報を管理する必要があります。
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ストリームからの要件と一致しており、必要になる場合があります。
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 起点が順方向チャネルを占有するストリーム内のターゲットの1つであるストリームによる逆方向チャネルの再利用を許可します。
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 上記の任意の組み合わせ。
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 ターゲットとSAPが指定されているストリームのVCは、アップストリームまたはダウンストリームから開始されます。
o Any combination of the above.
o 上記の任意の組み合わせ。
This subsection specifies VC management in the ST2+ over ATM protocol.
このサブセクションでは、ST2 + over ATMプロトコルでのVC管理を指定します。
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プリミティブがUNI 3.1シグナリングレイヤーエンティティに送信されます。 UNI 3.1シグナリングレイヤエンティティがsetup.confプリミティブで応答する場合、コール処理は成功したと見なされます。 UNI 3.1シグナリングレイヤエンティティがこのプリミティブ以外で応答する場合、処理ルールはセクション6.5.4に示されているSVC切断処理と同じであり、発信コール処理は失敗したと見なされます。
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の後のリーフの発信コール処理が必要な場合、add-party.reqプリミティブがUNI 3.1シグナリングレイヤエンティティに送信されます。 UNI 3.1シグナリングレイヤエンティティがadd-party.confプリミティブで応答する場合、コール処理は成功したと見なされます。 UNI 3.1シグナリングレイヤエンティティがこのプリミティブ以外で応答する場合、処理ルールはセクション6.5.4に示されている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.
S2 +の着信コール処理が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レイヤーエンティティは、UNI 3.1シグナリングレイヤーエンティティからのsetup.indプリミティブな指示を待ちます。このプリミティブが示され、そのパラメーターが許容できる場合、ST2 + SCMPレイヤーエンティティはsetup.respプリミティブで応答します。パラメータが受け入れられない場合、ST2 + SCMPレイヤエンティティはタイマーを停止し、UNI 3.1シグナリングレイヤエンティティの状態がU6の場合、エンティティはrelease.respプリミティブで応答し、状態がこれ以外の場合は、エンティティは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 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.
ST2 + SCMPレイヤーエンティティがsetup.respプリミティブで応答する場合、エンティティは次のプリミティブが表示されるのを待ち、次のプリミティブが表示されると、ST2 + SCMPレイヤーエンティティはタイマーを停止します。 setup-complete.indプリミティブが示されている場合、着呼処理は成功したと見なされます。 UNI 3.1シグナリングレイヤーエンティティがこのプリミティブ以外で応答する場合、またはタイマーが期限切れになる場合、処理ルールはセクション6.5.4に示されているSVC切断処理と同じであり、着信呼び出し処理は失敗したと見なされます。
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.
ST2 + SCMPレイヤエンティティ内でVCリリースが必要な場合、前のホップまたはネクストホップが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に接続されている場合、前のホップがポイントツーマルチポイントSVCに接続されている場合、または次のホップがポイントツーポイントに接続されている場合-マルチポイントSVCおよびリーフの数が1の場合、ST2 + SCMPレイヤーエンティティはrelease.reqプリミティブをUNI 3.1シグナリングレイヤーエンティティに送信し、release.confプリミティブの指示を待ちます。いずれかが指示された場合、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.
ネクストホップがポイントツーマルチポイントSVCに接続されており、リーフの数が1以外の場合、ST2 + SCMPレイヤーエンティティはdrop-party.reqプリミティブをUNI 3.1シグナリングレイヤーエンティティに送信し、ドロップを待ちます。 -party.confプリミティブ表示。いずれかが指示された場合、VC解放処理が完了したと見なされます。
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レイヤーエンティティがUNI 3.1シグナリングレイヤーエンティティに対応し、ST2 + SCMPレイヤーエンティティにUNI。3.1シグナリングレイヤーエンティティからrelease.indプリミティブが送信された場合、その原因はRELEASEメッセージの配信であり、ST2 + SCMPレイヤーエンティティはrelease.respプリミティブで応答し、VC切断処理が完了したと見なされます。 ST2 + SCMPレイヤーエンティティにrelease.indプリミティブが送信され、その原因が前のケース以外の場合、ST2 + SCMPレイヤーエンティティはrelease.confプリミティブの応答を待ちます。 release.confプリミティブが示されている場合、VC切断処理は完了したと見なされます。
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レイヤーエンティティはUNI 3.1シグナリングレイヤーエンティティに対応することに注意してください。この場合、ST2 + SCMPレイヤーエンティティがUNI 3.1シグナリングレイヤーエンティティからrelease.indプリミティブを送信された場合、その原因はRELEASEメッセージの配信であり、ST2 + SCMPレイヤーエンティティの1つがrelease.respプリミティブで応答します。次に、release.indプリミティブが送信されたエンティティーのVC切断処理が完了したと見なされます。 ST2 + SCMPレイヤーエンティティにrelease.indプリミティブが送信された場合、その原因は前のケースとは異なり、ST2 + SCMPレイヤーエンティティはrelease.confプリミティブの応答を待ちます。 release.confプリミティブが示されると、release.indプリミティブが示されているエンティティーのVC切断処理が完了したと見なされます。
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.
ST2 + SCMPレイヤーエンティティにUNI 3.1シグナリングレイヤーエンティティからdrop-party.indプリミティブが送信されると、ST2 + SCMPレイヤーエンティティはdrop-party.respプリミティブで応答し、VC切断処理が完了したと見なされます。 ST2 + SCMPレイヤーエンティティにdrop-party.confプリミティブが送信されると、VC切断処理が完了したと見なされます。
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.
このサブセクションでは、RFC 1819 ST2 +プロトコル仕様で定義されている追加のSCMP処理ルールを指定します。次の追加ルールは、前のホップまたは次のホップがST2 + SCMPレイヤーエンティティのATM接続に接続されている場合に適用されます。
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.
connect.reqプリミティブがネクストホップのST2 + SCMPレイヤーエンティティに送信されると、エンティティはネクストホップの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メッセージを転送します。
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要素が含まれているかどうかを確認します。
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メッセージは前のホップに転送されます。
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.
change.reqプリミティブがネクストホップのST2 + SCMPレイヤーエンティティに送信されると、エンティティは、プロセスがセクション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メッセージを転送します。
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を指定している場合、その発呼者はアップストリームまたはダウンストリーム、またはポイントツーマルチポイントSVCであり、change.indプリミティブがルーティングマシンに送信されます。既存のストリームで使用される双方向ポイントツーポイントSVCのPVCまたはリバースチャネルが指定され、指定されたVCが存在する場合、VC状態は占有に設定され、change.indプリミティブがルーティングマシンに送信されます。それ以外の場合、REFUSEメッセージは前のホップに転送されます。
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 or U10, the accept.req primitive is queued and is processed after the state changes to U0 or U10.
accept.reqプリミティブが前のホップのST2 + SCMPレイヤーエンティティに送信されると、エンティティはUNI 3.1シグナリングレイヤーエンティティの状態を確認します。エンティティの状態がU0またはU10以外の場合、accept.reqプリミティブはキューに入れられ、状態がU0またはU10に変化した後に処理されます。
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を指定した場合、エンティティは前のホップのIPアドレスからATMアドレスに変換し、その後エンティティはセクション6.5.1に示す発信呼び出し。発信コール処理が成功すると、ACCEPTメッセージが前のホップに転送されます。上記以外の場合、または着信または発信の呼び出し処理が失敗した場合、REFUSEメッセージが前のホップに転送され、disconnect.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レイヤーエンティティで処理されると、エンティティはUNI 3.1シグナリングレイヤーエンティティの状態を確認します。エンティティの状態がU0またはU10以外の場合、ACCEPTメッセージはキューに入れられ、状態がU0またはU10に変化した後に処理されます。
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 sent to the routing machine and a DISCONNECT message is forwarded to the next hop.
そうでなく、ACCEPTメッセージに対応するCONNECTまたはCHANGEメッセージが、発呼側がアップストリームまたはポイントツーマルチポイントSVCであるポイントツーポイントSVCを指定した場合、エンティティは次のIPアドレスから変換されます。 ATMアドレスにホップすると、エンティティはセクション6.5.1に示す発信呼び出しを処理します。発信処理が成功すると、accept.indプリミティブがルーティングマシンに送信されます。 ACCEPTメッセージに対応するCONNECTまたはCHANGEメッセージが、発呼側がダウンストリームであるポイントツーポイントSVCを指定した場合、エンティティはセクション6.5.2に示す着信呼び出しを処理します。着信呼び出し処理が成功すると、accept.indプリミティブがルーティングマシンに送信されます。上記以外の場合、または着信または発信の呼び出し処理が失敗した場合、refuse.indプリミティブがルーティングマシンに送信され、DISCONNECTメッセージが次のホップに転送されます。
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.
そして、disconnect.req処理の後、エンティティのダウンストリームに接続されているターゲットがなく、エンティティがターゲットからのACCEPTまたはREFUSEメッセージの応答を待っていない場合、エンティティは、プロセスがセクションに示されているVCを解放します。 6.5.3。
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処理の後、前のホップのST2 + SCMPレイヤーエンティティの下流に接続されているターゲットがなく、エンティティがターゲットからのACCEPTまたはREFUSEメッセージの応答を待機していない場合、エンティティはそのプロセスがセクション6.5.3に示されているVC。
And then, the entity sends a disconnect.ind primitive to the routing machine.
次に、エンティティはdisconnect.indプリミティブをルーティングマシンに送信します。
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.
そして、refuse.req処理の後、エンティティの下流に接続されているターゲットがなく、エンティティがターゲットからのACCEPTまたはREFUSEメッセージの応答を待っていない場合、エンティティは、プロセスがセクションに示されているVCを解放します。 6.5.3。
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.
最初、refuse.ind処理の後、ネクストホップのST2 + SCMPレイヤーエンティティの下流に接続されているターゲットがなく、エンティティがターゲットからのACCEPTまたはREFUSEメッセージの応答を待機していない場合、エンティティはそのプロセスがセクション6.5.3に示されているVC。
And then, the entity sends a refuse.ind primitive to the routing machine.
次に、エンティティはrefuse.indプリミティブをルーティングマシンに送信します。
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.
前のホップのST2 + SCMPレイヤーエンティティにUNI 3.1シグナリングレイヤーエンティティからSVC切断処理が送信され、SVC切断処理が完了すると、エンティティは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.
ネクストホップのST2 + SCMPレイヤーエンティティにUNI 3.1シグナリングレイヤーエンティティからSVC切断処理が送信され、SVC切断処理が完了すると、エンティティはrefuse.indプリミティブをルーティングマシンに送信し、DISCONNECTメッセージをに転送します前のホップ。
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].
ST2 + over ATMプロトコルは、UNI 3.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 Transit network selection
oブロードバンド送信完了oトランジットネットワークの選択
o Endpoint reference
o エンドポイント参照
o Endpoint state
o エンドポイントの状態
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.
ST2 + over ATMプロトコルのSETUPおよびADD PARTYメッセージには、ATMアダプテーションレイヤーのパラメーター情報要素を含める必要があります。 CONNECTメッセージには、この要素が含まれる場合と含まれない場合があります。フィールドのコーディング規則は次のとおりです。
o The AAL Type is set to AAL5.
o AALタイプは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 maximum CPCS sizeフィールドの値は、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がポイントツーポイントコールとして確立されている場合、後方最大CPCSサイズフィールドの値は、前方最大CPCSサイズフィールドの値と同じに設定されます。 VCがポイントツーマルチポイントコールとして確立されている場合、Backward maximum CPCS sizeフィールドの値はゼロに設定されます。
o The SSCS type is set to null.
o SSCSタイプはnullに設定されます。
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.
ST2 + over ATMプロトコルでNull FlowSpecが指定されている場合、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）フィールドは、0〜16,777,215の任意の値に設定可能である必要があります。
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 ベストエフォートの表示が存在する必要があります。
If the Controlled-Load Service FlowSpec is specified, the coding rules for the fields are as follows.
Controlled-LoadサービスFlowSpecが指定されている場合、フィールドのコーディング規則は次のとおりです。
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）フィールドは、0〜16,777,215の任意の値に設定可能である必要があります。
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 [ベストエフォート]表示、[後方へのタグ付け]、および[前方へのタグ付け]フィールドが存在していてはなりません。
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.
ST2 + over ATMプロトコルでNull FlowSpecが指定されている場合、SETUPメッセージのブロードバンドベアラ機能情報要素のフィールドのコーディング規則は次のとおりです。
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 トラフィックタイプとタイミング要件フィールドは存在してはなりません。
o The Susceptibility to clipping field is set to not susceptible to clipping.
o [クリッピングの影響を受けやすい]フィールドは、クリッピングの影響を受けないように設定されています。
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がポイントツーポイントコールとして確立されている場合、ユーザープレーン接続構成フィールドはポイントツーポイントに設定され、VCがポイントツーマルチポイントコールとして確立されている場合は、ポイントに設定されますマルチポイントへ。
If the Controlled-Load Service FlowSpec is specified, the coding rules for the fields are as follows.
Controlled-Loadサービス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の場合、トラフィックタイプおよびタイミング要件フィールドは、ATMネットワークの仕様によって異なります。実装の各ATMインターフェイスのトラフィックタイプとタイミング要件フィールドは、それぞれ表示なしまたはVBRと不要のいずれかとして設定可能である必要があります。デフォルトの構成として、指示は推奨されません。 BearerクラスがBCOB-Cの場合、トラフィックタイプおよびタイミング要件フィールドが存在してはなりません。
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 クリッピングに対する感受性フィールドは、ATMネットワークの仕様によって異なります。実装の各ATMインターフェイスの[クリッピングに対する感受性]フィールドは、クリッピングの影響を受けないように、またはクリッピングの影響を受けやすいように構成可能である必要があります。デフォルトの構成として、クリッピングの影響を受けないようにすることをお勧めします。
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がポイントツーポイントコールとして確立されている場合、ユーザープレーン接続構成フィールドはポイントツーポイントに設定され、VCがポイントツーマルチポイントコールとして確立されている場合は、ポイントに設定されますマルチポイントへ。
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.
ST2 + over ATMプロトコルのSETUPおよびADD PARTYメッセージには、ブロードバンド高層情報情報要素が含まれている必要があります。フィールドのコーディング規則は次のとおりです。
o The High layer information type is set to User specific.
o 高層情報タイプはユーザー固有に設定されます。
o The first 6 bytes in the High layer information field are set to the SID of the stream corresponding to the VC.
o 高層情報フィールドの最初の6バイトは、VCに対応するストリームのSIDに設定されます。
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.
ST2 + over ATMプロトコルのSETUPおよびADD PARTYメッセージには、ブロードバンドの低層情報情報要素が含まれている必要があります。 CONNECTメッセージには、この要素が含まれる場合と含まれない場合があります。フィールドのコーディング規則は次のとおりです。
o The User information layer 3 protocol field is set to ISO/IEC TR 9577.
o ユーザー情報レイヤー3プロトコルフィールドはISO / IEC TR 9577に設定されます。
o The IPI field is set to IEEE 802.1 SNAP (0x80).
o IPIフィールドはIEEE 802.1 SNAP（0x80）に設定されます。
o The OUI field is set to IANA (0x00-00-5E).
o OUIフィールドはIANA（0x00-00-5E）に設定されます。
o The PID field is set to ST2+ (TBD).
o PIDフィールドはST2 +（TBD）に設定されます。
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.
ST2 + over ATMプロトコルでNull FlowSpecが指定されている場合、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-Loadサービス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は、デフォルトの構成として推奨されます。
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.
ST2 + over ATMプロトコルはRFC 1819 ST2 +プロトコルを変更しますが、基本的にこれらの変更は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.
ST2 + over ATMプロトコルは、ST2 +とUNI 3.1の間のプロトコル相互作用を指定します。これにより、UNI 3.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 network, then it is feasible to use the calling party number for part of the calling party authentication to strengthen security.
SVCの着信コールを処理するST2 +エージェントでは、着信SETUPメッセージに発呼者番号が含まれていて、ATMネットワークによって検証されて渡された場合、またはネットワークから提供された場合、発呼者を使用できます。セキュリティを強化するための発呼者認証の一部の番号。
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] Borden、M.、Crawley、E.、Davie、B。、およびS. Batsell、「IP-ATMネットワークアーキテクチャにおけるリアルタイムサービスの統合」、RFC 1821、1995年8月。
[2] Jackowski, S., "Native ATM Support for ST2+", RFC 1946, May 1996.
[2] Jackowski、S。、「Native ATM Support for ST2 +」、RFC 1946、1996年5月。
[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、「ATMを介した接続指向プロトコル：ケーススタディ」、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. Berger、編、「インターネットストリームプロトコルバージョン2（ST2）プロトコル仕様-バージョンST2 +」、RFC 1819、1995年8月。
[5] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[5] Wroclawski、J。、「Controlled-Load Network Element Serviceの仕様」、RFC 2211、1997年9月。
[6] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[6] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[7] Wroclawski、J。、「The Use of RSVP with IETF Integrated Services」、RFC 2210、1997年9月。
[8] Garrett, M., and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[8] Garrett、M。、およびM. Borden、「制御負荷サービスとATMによる保証サービスの相互運用」、RFC 2381、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。、およびV. Srinivasan、「共有および交換LANテクノロジーを介して統合サービスを提供するためのフレームワーク」、進行中の作業。
[10] The ATM Forum, "ATM User-Network Interface Specification Version 3.1", September 1994.
[10] ATMフォーラム、「ATM User-Network Interface Specification Version 3.1」、1994年9月。
[11] The ATM Forum, "ATM User-Network Interface (UNI) Signaling Specification Version 4.0", af-sig-0061.000, July 1996.
[11] ATMフォーラム、「ATM User-Network Interface（UNI）Signaling Specification Version 4.0」、af-sig-0061.000、1996年7月。
[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勧告Q.2931、1995年9月。
[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勧告Q.2971、1995年10月。
[14] ITU-T, "B-ISDN Protocol Reference Model and its Application", CCITT Recommendation I.321, April 1991.
[14] ITU-T、「B-ISDNプロトコル参照モデルとそのアプリケーション」、CCITT勧告I.321、1991年4月。
[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）タイプ5仕様」、ドラフトの新しいITU-T勧告I.363.5、1995年9月。
[16] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[16] Heinanen、J。、「ATMアダプテーションレイヤー5上のマルチプロトコルカプセル化」、RFC 1483、1993年7月。
[17] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, January 1994.
[17] Laubach、M。、「Classical IP and ARP over ATM」、RFC 1577、1994年1月。
[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。、およびA. Malis、「ATM Signaling Support for IP over ATM」、RFC 1755、1995年2月。
[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。、およびB. Cole、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
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は巨大なテクノロジーであり、ATMの研究開発に携わるNTTの多くの同僚の助けがなければ、このプロトコル仕様を完成させることは不可能でした。 NTTネットワーク戦略企画部の新井秀明、森田直孝、NTTネットワークサービスシステム研究所の栗林真一、荒海純、大場拓海、そしてNTTマルチメディアの魚瀬久雄、織田義和に感謝します。ネットワークラボ。彼らの貴重なコメントと議論のために。
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.
また、Gigapacket NetworksのEric Crawley、MITのJohn Wroclawski、Net ManageのSteven Jackowski、FORE SystemsのLouis Berger、Bay NetworksのSteven Willis、QosneticsのGreg Burch、そしてDenis Gallant、James Watt、そしてNewbridge NetworksのJoel Halpern氏の貴重なコメントと提案。
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.
また、この仕様は、NACSISとのNTTマルチメディア共同プロジェクトでのさまざまな議論に基づいています。この点について貴重な助言をしてくださった国立科学情報システム研究センターの浅野正一郎教授に感謝します。
Author's Address
著者のアドレス
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
Appendix A. RFC 1819 ST2+ Errata
付録A. RFC 1819 ST2 +エラッタ
The following sentence in the second paragraph:
2番目の段落の次の文：
< For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the
<一部のSCMPメッセージ（CONNECT、CHANGE、JOIN、およびSTATUS）では、
should be changed to
に変更する必要があります
> For some SCMP messages (CONNECT, CHANGE, and JOIN) the
>一部のSCMPメッセージ（CONNECT、CHANGE、およびJOIN）では、
The following sentence:
次の文：
< option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and < REFUSE messages. The format of the UserData parameter is shown in
<オプションは、ACCEPT、CHANGE、CONNECT、DISCONNECT、および<REFUSEメッセージに含めることができます。 UserDataパラメータの形式を次に示します。
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
>オプションは、ACCEPT、CHANGE、CONNECT、DISCONNECT、NOTIFY、およびREFUSEメッセージに含めることができます。 UserDataパラメータの形式を次に示します。
The following sentence:
次の文：
< CONNECT with a REFUSE message with the affected targets specified in < the TargetList and an appropriate ReasonCode (StreamExists).
<CONNECTとREFUSEメッセージを使用して、影響を受けるターゲットを<TargetListと適切なReasonCode（StreamExists）で指定します。
should be changed to
に変更する必要があります
> CONNECT with a REFUSE message with the affected targets specified in > the TargetList and an appropriate ReasonCode (TargetExists).
>影響を受けるターゲットがTargetListおよび適切なReasonCode（TargetExists）で指定されたREFUSEメッセージでCONNECTします。
The following sentence:
次の文：
< notifies the processing ST agent which should respond with ReasonCode < (FlowSpecMismatch).
<ReasonCode <（FlowSpecMismatch）で応答する必要がある処理STエージェントに通知します。
should be changed to
に変更する必要があります
> notifies the processing ST agent which should respond with a REFUSE > message with ReasonCode (FlowSpecMismatch).
> REFUSEメッセージで応答する必要がある処理STエージェントに通知します> ReasonCode（FlowSpecMismatch）。
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
<障害後しばらくしてから。その結果、<リカバリを試行しているSTエージェントは、<... <失敗である新しいCONNECTのエラーメッセージを受信する可能性があり、<ルーティングエラーが原因で新しいCONNECTを解釈します。 <適切なReasonCode（StreamExists）を含むERRORメッセージで応答します。壊れたストリームのST <... <残りがすぐにDISCONNECT <メッセージによって破棄されるというタイムアウトがあるため。したがって、<ReasonCode（StreamExists）を含むERRORメッセージを受信したSTエージェントは、後にCONNECTメッセージを再送信する必要があります。
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
>障害後しばらくしてから。その結果、回復を試行しているSTエージェントは、失敗した新しいCONNECTのREFUSEメッセージを受信する可能性があり、ルーティングの失敗が原因で新しいCONNECTを解釈します。 >適切なReasonCode（TargetExists）を含むREFUSEメッセージで応答します。 ST> ...>壊れたストリームの残りがタイムアウトになるため、DISCONNECTメッセージによってすぐに破棄されます。したがって、> ReasonCode（TargetExists）でREFUSEメッセージを受信するSTエージェントは、後にCONNECTメッセージを再送信する必要があります。
The following sentence:
次の文：
< (least important) to 256 (most important). This value is
<（最も重要でない）〜256（最も重要）。この値は
should be changed to
に変更する必要があります
> (least important) to 255 (most important). This value is
>（最も重要でない）〜255（最も重要）。この値は
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参照はトランザクション番号です。リクエストコントロール<メッセージの各送信者は、ストリームに対して一意の<参照番号をメッセージに割り当てます。
should be changed to
に変更する必要があります
>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参照はトランザクション番号です。要求制御>メッセージの各送信者は、各エージェントによって生成されたメッセージのストリームに関して、一意の参照番号をメッセージに割り当てます。
The following:
以下：
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< | PCode = 5 | PBytes | NextPcol |OriginSAPBytes |
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be changed to
に変更する必要があります
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | PCode = 4 | PBytes | NextPcol |OriginSAPBytes |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は、<ストリームが通過するIPカプセル化ホップの数です。このフィールドは、起点によってゼロに設定され、各IPカプセル化エージェントで<増分されます。
should be changed to
に変更する必要があります
>o IPHops is the number of IP encapsulated hops traversed by the > stream.
> o IPHopsは、ストリームが通過するIPカプセル化ホップの数です。
The following:
以下：
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< | OpCode = 2 | 0 | TotalBytes |
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be changed to
に変更する必要があります
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | OpCode = 2 | 0 | TotalBytes = 16 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following sentence:
次の文：
<o I (bit 7) is used to indicate that the LRM is permitted to interrupt
<o I（ビット7）は、LRMが割り込みを許可されていることを示すために使用されます
should be changed to
に変更する必要があります
>o I (bit 9) is used to indicate that the LRM is permitted to interrupt
> o I（ビット9）は、LRMが割り込みを許可されていることを示すために使用されます
The following:
以下：
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< | OpCode = 7 |R| 0 | TotalBytes |
< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be changed to
に変更する必要があります
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | OpCode = 7 |R| 0 | TotalBytes = 20 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following sentence:
次の文：
<o Reference contains a number assigned by the ST agent sending the < REFUSE for use in the acknowledging ACK.
<o参照には、確認応答ACKで使用するために<REFUSEを送信するSTエージェントによって割り当てられた番号が含まれています。
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参照には、確認応答ACKで使用するためにJOIN-REJECTを送信するSTエージェントによって割り当てられた番号が含まれます。
The following sentence:
次の文：
< possibly Groups of the stream. It the full target list can not fit in
<ストリームのグループ。完全なターゲットリストは収まりません
should be changed to
に変更する必要があります
> possibly Groups of the stream. If the full target list can not fit in
>おそらくストリームのグループ。完全なターゲットリストが収まらない場合
The following:
以下：
< 32 PCodeUnknown Control PDU has a parameter with an invalid < PCode.
<32 PCodeUnknown制御PDUに無効な<PCodeを持つパラメーターがあります。
should be removed because a common SCMP element with an unknown PCode is equivalent to the UserData (RFC 1819, Section 10.3.8).
不明なPCodeを持つ一般的なSCMP要素はUserData（RFC 1819、セクション10.3.8）と同等であるため、削除する必要があります。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。