RFC3057 日本語訳
3057 ISDN Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M.Kalla, G. Sidebottom. February 2001. (Format: TXT=13601 bytes) (Obsoleted by RFC4233) (Updated by RFC3807) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Morneault
Request for Comments: 3057 Cisco Systems
Category: Standards Track S. Rengasami
M. Kalla
Telcordia Technologies
G. Sidebottom
Nortel Networks
February 2001
Morneaultがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3057年のシスコシステムズカテゴリ: 規格は2001年2月にS.Rengasami M.カッラTelcordia技術G.Sidebottomノーテルネットワークを追跡します。
ISDN Q.921-User Adaptation Layer
ISDN Q.921-ユーザ適合層
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
このドキュメントは、IPの上でISDN Q.921 UserメッセージをbackhaulingするようにStream Control Transmissionプロトコル(SCTP)を使用することでプロトコルを定義します。 このプロトコルはSignalingゲートウェイ(SG)とメディアゲートウェイController(MGC)の間で使用されるでしょう。 SGが標準のISDNインタフェースの上にISDNシグナリングを受けると思われます。
Morneault, et al. Standards Track [Page 1] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[1ページ]。
Table of Contents
目次
1. Introduction................................................. 2
1.1 Scope..................................................... 2
1.2 Terminology............................................... 3
1.3 IUA Overview.............................................. 4
1.4 Services Provided by the IUA Layer........................ 9
1.5 Functions Implemented by the IUA Layer.................... 12
1.6 Definition of IUA Boundaries.............................. 14
2. Conventions.................................................. 16
3. Protocol Elements............................................ 17
3.1 Common Message Header..................................... 17
3.2 IUA Message Header........................................ 20
3.3 Description of Messages................................... 22
4. Procedures................................................... 45
4.1 Procedures to Support Service in Section 1.4.1............ 45
4.2 Procedures to Support Service in Section 1.4.2............ 46
4.3 Procedures to Support Service in Section 1.4.3............ 47
5. Examples...................................................... 56
5.1 Establishment of associations between SG and MGC examples.. 56
5.2 ASP Traffic Fail-over Examples............................. 58
5.3 Q.921/Q.931 primitives backhaul Examples................... 59
5.4 Layer Management Communication Examples.................... 61
6. Security..................................................... 61
6.1 Threats.................................................... 61
6.2 Protecting Confidentiality ................................ 62
7. IANA Considerations.......................................... 62
7.1 SCTP Payload Protocol Identifier........................... 62
7.2 IUA Protocol Extensions.................................... 62
8. Acknowledgements............................................. 64
9. References................................................... 64
10. Authors' Addresses........................................... 65
11. Full Copyright Statement..................................... 66
1. 序論… 2 1.1範囲… 2 1.2用語… 3 1.3IUA概要… 4 IUAによって提供された1.4のサービスが層にされます… 9 IUAによって実装された1.5の機能が層にされます… 12 1.6 IUA境界の定義… 14 2. コンベンション… 16 3. Elementsについて議定書の中で述べてください… 17 3.1の一般的なメッセージヘッダー… 17 3.2IUAメッセージヘッダー… 20 3.3 メッセージの記述… 22 4. 手順… 45 セクション1.4.1における支援活動への4.1の手順… 45 セクション1.4.2における支援活動への4.2の手順… 46 セクション1.4.3における支援活動への4.3の手順… 47 5. 例… 56 5.1 SGとMGCの例との協会の設立。 56 5.2 ASPトラフィックフェイルオーバーの例… 58 5.3Q.921/Q.931基関数逆送Examples… 59 5.4 マネジメント・コミュニケーションの例を層にしてください… 61 6. セキュリティ… 61 6.1の脅威… 61 6.2 秘密性を保護します… 62 7. IANA問題… 62 7.1 SCTP有効搭載量プロトコル識別子… 62 7.2 IUAは拡大について議定書の中で述べます… 62 8. 承認… 64 9. 参照… 64 10. 作者のアドレス… 65 11. 完全な著作権宣言文… 66
1. Introduction
1. 序論
In this document, the term Q.921-User refers to an upper layer which uses the services of Q.921, not the user side of ISDN interface [1]. Examples of the upper layer would be Q.931 and QSIG.
本書では、用語Q.921-ユーザはISDNインタフェース[1]のユーザ側ではなく、Q.921のサービスを利用する上側の層について言及します。 上側の層に関する例は、Q.931とQSIGでしょう。
This section describes the need for ISDN Q.921-User Adaptation (IUA) layer protocol as well as how this protocol shall be implemented.
このセクションはこのプロトコルがどう実装されるものとするかと同様にISDN Q.921-ユーザAdaptation(IUA)層のプロトコルの必要性について説明します。
1.1 Scope
1.1 範囲
There is a need for Switched Circuit Network (SCN) signaling protocol delivery from an ISDN Signaling Gateway (SG) to a Media Gateway Controller (MGC) as described in the Framework Architecture for
ISDN Signalingゲートウェイ(SG)からメディアゲートウェイController(MGC)までのSwitched Circuit Network(SCN)シグナリングプロトコル配送の必要がFramework Architectureで説明されるようにあります。
Morneault, et al. Standards Track [Page 2] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[2ページ]。
Signaling Transport [4]. The delivery mechanism SHOULD meet the following criteria:
シグナリングは[4]を輸送します。 排紙機構SHOULDは以下の評価基準を満たします:
* Support for transport of the Q.921 / Q.931 boundary primitives
* Support for communication between Layer Management modules on SG
and MGC
* Support for management of active associations between SG and MGC
* Q.921 / Q.931の輸送には、SGとMGCとの活動的な協会の経営のSGとMGC*サポートのときに境界基関数*がLayer Managementモジュールのコミュニケーションのサポートであるとサポートしてください。
This document supports both ISDN Primary Rate Access (PRA) as well as Basic Rate Access (BRA) including the support for both point-to-point and point-to-multipoint modes of communication. This support includes Facility Associated Signaling (FAS), Non-Facility Associated Signaling (NFAS) and NFAS with backup D channel. QSIG adaptation layer requirements do not differ from Q.931 adaptation layer, hence; the procedures described in this document are also applicable for a QSIG adaptation layer. For simplicity, only Q.931 will be mentioned in the rest of this document.
ポイントツーポイントとコミュニケーションのポイントツーマルチポイントモードの両方のサポートを含んでいて、このドキュメントはISDN Primary Rate Access(PRA)とBasic Rate Access(BRA)の両方をサポートします。 このサポートはバックアップDチャネルがあるFacility Associated Signaling(FAS)、Non-施設Associated Signaling(NFAS)、およびNFASを含んでいます。 したがって、QSIG適合層の要件はQ.931適合層と異なっていません。 また、QSIG適合層に、本書では説明された手順も適切です。 簡単さにおいて、このドキュメントの残りでQ.931だけについて言及するでしょう。
1.2 Terminology
1.2 用語
Interface - For the purposes of this document an interface supports the relevant ISDN signaling channel. This signaling channel MAY be a 16 kbps D channel for an ISDN BRA as well as 64 kbps primary or backup D channel for an ISDN PRA. For QSIG, the signaling channel is a Qc channel.
インタフェース--このドキュメントの目的のために、インタフェースは関連ISDNシグナリングチャンネルを支えます。 このシグナリングチャンネルは、64キロビット毎秒予備選挙と同様にISDN BRAのための16キロビット毎秒DチャネルであるかISDN PRAのためにDチャネルのバックアップをとるかもしれません。 QSIGに関しては、シグナリングチャンネルはQcチャンネルです。
Q.921-User - Any protocol normally using the services of the ISDN Q.921 (e.g., Q.931, QSIG, etc.).
Q.921-ユーザ--通常、ISDN Q.921(例えば、Q.931、QSIGなど)のサービスを利用するどんなプロトコル。
Backhaul - A SG terminates the lower layers of an SCN protocol and backhauls the upper layer(s) to MGC for call processing. For the purposes of this document the SG terminates Q.921 and backhauls Q.931 to MGC.
逆送--SGはSCNプロトコルの下層を終えて、逆送は呼び出し処理のためのMGCへの上側の層を終えます。 このドキュメントの目的のために、SGはMGCへのQ.921と逆送Q.931を終えます。
Association - An association refers to a SCTP association. The association will provide the transport for the delivery of Q.921-User protocol data units and IUA adaptation layer peer messages.
協会--協会はSCTP協会について言及します。 協会はQ.921-ユーザプロトコルデータ単位とIUA適合層の同輩メッセージの配送のための輸送を提供するでしょう。
Stream - A stream refers to an SCTP stream; a uni-directional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the un-ordered delivery service.
ストリーム--ストリームはSCTPストリームについて言及します。 1つのSCTP終点から別の終点まで確立されたuni方向の論理チャネルはSCTP終点を関連づけました。そこでは、連続して順不同のデリバリ・サービスに提出されたものを除いて、すべてのユーザメッセージが提供されます。
Interface Identifier - The Interface Identifier identifies the physical interface at the SG for which the signaling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to
インタフェースIdentifier--Interface Identifierはシグナリングメッセージが送るか、または受信されているSGで物理インターフェースを特定します。 Interface Identifierパラメタの形式は、テキストか整数であるかもしれません。それの値は割り当てられます。
Morneault, et al. Standards Track [Page 3] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[3ページ]。
network operator policy. The values used are of local significance only, coordinated between the SG and ASP. Significance is not implied across SGs served by an AS.
オペレータ方針をネットワークでつないでください。 使用される値はSGとASPの間で唯一の、そして、連携しているローカルの意味のものです。 意味はASによって役立たれたSGsの向こう側に含意されません。
Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the Q.931 and call processing for D channels terminated by the Signaling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary).
アプリケーションServer(AS)--特定のアプリケーションインスタンスに役立つ論理的な実体。 Application Serverに関する例はDチャネルのためのQ.931と呼び出し処理がSignaling Gatewaysで終えたMGC取り扱いです。 実際に話すなら、1以上の規則正しいリストがApplication Server Processes(例えば、プライマリの、そして、セカンダリの第三)を関係づけたので、ASはSGでモデル化されます。
Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances.
アプリケーションServer Process(ASP)--Application Server Application Server Processesに関する例のプロセスインスタンスは、プライマリである、またはMGCインスタンスのバックアップをとります。
Fail-over - The capability to re-route signaling traffic as required between related ASPs in the event of failure or unavailability of the currently used ASP (e.g., from primary MGC to back-up MGC). Fail- over also applies upon the return to service of a previously unavailable process.
フェイルオーバー--現在中古のASP(例えば、プライマリMGCからバックアップMGCまでの)の失敗か使用不能の場合、必要に応じて関連するASPの間でシグナリングトラフィックを別ルートで送る能力。 失敗する、また、リターンのときに、以前に入手できないプロセスのサービスに適用します。
Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the IUA layer and a local management entity.
層のManagement--層のManagementはIUA層と現地管理職者実体の間の入力と出力を扱うこぶのような機能です。
Network Byte Order - Most significant byte first, a.k.a Big Endian.
Byte Orderをネットワークでつないでください--大部分の重要なバイト最初に、a.k.a Big Endian。
Host - The computing platform that the ASP process is running on.
ホスト--ASPプロセスが走っているコンピューティングプラットホーム。
1.3 IUA Overview
1.3 IUA概要
The architecture that has been defined [4] for SCN signaling transport over IP uses multiple components, including an IP transport protocol, a signaling common transport protocol and an adaptation module to support the services expected by a particular SCN signaling protocol from its underlying protocol layer.
定義されて、IPの上のSCNシグナリング輸送のための[4]は複数のコンポーネントを使用します、IPトランスポート・プロトコルを含んでいてことであるアーキテクチャ、特定のSCNシグナリングによって予想されたサービスをサポートする合図している一般的なトランスポート・プロトコルと適合モジュールは基本的なプロトコル層より議定書を作ります。
This document defines an adaptation module that is suitable for the transport of ISDN Q.921-User (e.g., Q.931) messages.
このドキュメントはISDN Q.921-ユーザ(例えば、Q.931)メッセージの輸送に適した適合モジュールを定義します。
1.3.1 Example - SG to MGC
1.3.1 例--MGCへのSG
In a Signaling Gateway, it is expected that the ISDN signaling is received over a standard ISDN network termination. The SG then provides interworking of transport functions with IP Signaling Transport, in order to transport the Q.931 signaling messages to the MGC where the peer Q.931 protocol layer exists, as shown below:
Signalingゲートウェイでは、ISDNシグナリングが標準のISDNネットワーク終了の上に受け取られると予想されます。 次に、SGは輸送機能を織り込むのにIP Signaling Transportを提供します、同輩Q.931プロトコル層が存在するMGCにQ.931シグナリングメッセージを輸送するために、以下に示すように:
Morneault, et al. Standards Track [Page 4] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[4ページ]。
****** ISDN ****** IP *******
* EP *---------------* SG *--------------* MGC *
****** ****** *******
****** ISDN******IP********EP*---------------* SG*--------------* MGC********************
+-----+ +-----+
|Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+ |Q.931| (NIF) |Q.931| +-----+ +----------+ +-----+ | | | | IUA| | IUA| | | | +----+ +-----+ |Q.921| |Q.921|SCTP| |SCTP| | | | +----+ +-----+ | | | | IP| | IP| +-----+ +-----+----+ +-----+
NIF - Nodal Interworking Function
EP - ISDN End Point
SCTP - Stream Control Transmission Protocol (Refer to [3])
IUA - ISDN User Adaptation Layer Protocol
NIF--こぶのような織り込んでいる機能EP--ISDNエンドポイントSCTP--制御伝動プロトコルを流してください。([3]) IUAを参照してください--、ISDNユーザ適合層のプロトコル
It is recommended that the IUA use the services of the Stream Control Transmission Protocol (SCTP) as the underlying reliable common signaling transport protocol. The use of SCTP provides the following features:
基本的な信頼できる一般的なシグナリング輸送が議定書を作るときIUAがStream Control Transmissionプロトコル(SCTP)のサービスを利用するのは、お勧めです。 SCTPの使用は以下の特徴を提供します:
- explicit packet-oriented delivery (not stream-oriented)
- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
- optional multiplexing of user messages into SCTP datagrams,
- network-level fault tolerance through support of multi-homing
at either or both ends of an association,
- resistance to flooding and masquerade attacks, and
- data segmentation to conform to discovered path MTU size
- そして、明白なパケット指向の配送(ストリーム指向でない)--どちらかのマルチホーミングのサポートか協会の両端を通る個々のユーザメッセージ--SCTPデータグラムへのユーザメッセージの任意のマルチプレクシング--ネットワークレベル耐障害性の到着の注文配送のためのオプションによる複数のストリームの中のユーザメッセージの配列された配送--氾濫と仮面舞踏会への抵抗が攻撃される、--従うデータ分割が経路MTUサイズを発見した
There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol.
シナリオが冗長がトランスポート層の下でサポートされる冗長要件とシナリオなしであります。 これらのケース、上の機能がそうしないSCTPでは要件になってください、そして、基本的な一般的なトランスポート・プロトコルとしてTCPは使用できます。
1.3.2 Support for the management of SCTP associations between the SG
and ASPs
1.3.2 SGとASPとのSCTP協会の経営のサポート
The IUA layer at the SG maintains the availability state of all dynamically registered remote ASPs, in order to manage the SCTP Associations and the traffic between the SG and ASPs. As well, the active/inactive state of remote ASP(s) are also maintained. Active ASPs are those currently receiving traffic from the SG.
SGのIUA層はすべてのダイナミックに登録されたリモートASPの有用性状態を維持します、SGとASPの間のSCTP Associationsとトラフィックを管理するために。 また、井戸、リモートASPのアクティブであるか不活発な状態が維持されるように。 活動的なASPは現在SGからトラフィックを受けるものです。
Morneault, et al. Standards Track [Page 5] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[5ページ]。
The IUA layer MAY be instructed by local management to establish an SCTP association to a peer IUA node. This can be achieved using the M-SCTP ESTABLISH primitive to request, indicate and confirm the establishment of an SCTP association with a peer IUA node.
IUA層が同輩IUAノードにSCTP協会を設立するよう現地管理職者によって命令されるかもしれません。 要求するためには原始のM-SCTP ESTABLISHを使用することでこれを達成できます、と同輩IUAノードとのSCTP協会の設立は示して、確認します。
The IUA layer MAY also need to inform local management of the status of the underlying SCTP associations using the M-SCTP STATUS request and indication primitive. For example, the IUA MAY inform local management of the reason for the release of an SCTP association, determined either locally within the IUA layer or by a primitive from the SCTP.
また、M-SCTP STATUS要求と指示プリミティブを使用して、IUA層は、基本的なSCTP協会の状態について現地管理職者に知らせる必要があるかもしれません。 例えば、IUA MAYはIUA層以内かSCTPからの基関数で局所的に決定するSCTP協会のリリースの理由について現地管理職者に知らせます。
1.3.3 Signaling Network Architecture
1.3.3 シグナル伝達ネットワークアーキテクチャ
A Signaling Gateway is used to support the transport of Q.921-User signaling traffic to one or more distributed ASPs (e.g., MGCs). Clearly, the IUA protocol is not designed to meet the performance and reliability requirements for such transport by itself. However, the conjunction of distributed architecture and redundant networks does allow for a sufficiently reliable transport of signaling traffic over IP. The IUA protocol is flexible enough to allow its operation and management in a variety of physical configurations, enabling Network Operators to meet their performance and reliability requirements.
Signalingゲートウェイは、1つ以上の分配されたASP(例えば、MGCs)にQ.921-ユーザシグナリングトラフィックの輸送をサポートするのに使用されます。 明確に、IUAプロトコルは、それ自体でそのような輸送のための性能と信頼度要求事項を満たすように設計されていません。 しかしながら、分配されたアーキテクチャと余分なネットワークの接続詞はIPの上でシグナリングトラフィックの十分信頼できる輸送を考慮します。 IUAプロトコルはさまざまな物理的な構成でその操作と管理を許すほどフレキシブルです、Network Operatorsが彼らの性能と信頼度要求事項を満たすのを可能にして。
To meet the ISDN signaling reliability and performance requirements for carrier grade networks, Network Operators SHOULD ensure that there is no single point of failure provisioned in the end-to-end network architecture between an ISDN node and an IP ASP.
信頼性とキャリヤーグレードネットワークのための性能要件、Network Operators SHOULDが確実にするあるISDNシグナリングを満たすために、失敗のどんな単一のポイントもISDNノードとIP ASPの間の終わらせる終わりのネットワークアーキテクチャに食糧を供給しませんでした。
Depending of course on the reliability of the SG and ASP functional elements, this can typically be met by the provision of redundant QOS-bounded IP network paths for SCTP Associations between SCTP End Points, and redundant Hosts, and redundant SGs. The distribution of ASPs within the available Hosts is also important. For a particular Application Server, the related ASPs SHOULD be distributed over at least two Hosts.
もちろんSGとASP機能要素の信頼性によって、余分なQOSが境界があるIPネットワーク経路の支給でSCTP End Pointsと、余分なHostsと、余分なSGsの間のSCTP Associationsのためにこれに通常会うことができます。 また、利用可能なHostsの中のASPの分配も重要です。 特定のApplication Serverのために関係づける、分配されていて、少なくとも2Hostsの上にASP SHOULDを関係づけました。
An example logical network architecture relevant to carrier-grade operation in the IP network domain is shown in Figure 1 below:
IPネットワークドメインでのキャリヤーグレード操作に関連している例の論理的なネットワークアーキテクチャは以下の図1に示されます:
Morneault, et al. Standards Track [Page 6] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[6ページ]。
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Host1************************_________________________________________* ******** * * * _________* * ASP1***SG1*SCTP協会| * ******** * * *_______________________ | * * ******** | | ************** | | ******** | | * *_______________________________| * * | * SG2*SCTP協会| * *____________ | * * | | Host2********| | ************** | |_________________* ******** * |____________________________* * ASP1****************************…
Figure 2 - Logical Model Example
図2--論理的なモデルの例
For carrier grade networks, the failure or isolation of a particular ASP SHOULD NOT cause stable calls to be dropped. This implies that ASPs need, in some cases, to share the call state or be able to pass the call state between each other. However, this sharing or communication of call state information is outside the scope of this document.
特定のASP SHOULD NOTのキャリヤーグレードネットワーク、失敗または分離には、下げられるという安定した要求を引き起こしてください。 これは、いくつかの場合、ASPが、呼び出し状態を共有するか、または互いの間の呼び出し状態を通り過ぎることができる必要であるのを含意します。 しかしながら、このドキュメントの範囲の外に呼び出し状態情報に関するこの共有かコミュニケーションがあります。
1.3.4 ASP Fail-over Model and Terminology
1.3.4 ASPフェイルオーバーモデルと用語
The IUA layer supports ASP fail-over functions in order to support a high availability of call processing capability. All Q.921-User messages incoming to an SG are assigned to a unique Application Server, based on the Interface Identifier of the message.
IUA層は、呼び出し処理能力の高可用性をサポートするためにASPフェイルオーバーが機能であるとサポートします。 SGへのすべてのQ.921-ユーザメッセージ入来がユニークなApplication Serverに割り当てられます、メッセージのInterface Identifierに基づいて。
The Application Server is, in practical terms, a list of all ASPs configured to process Q.921-User messages from certain Interface Identifiers. One or more ASPs in the list are normally active (i.e., handling traffic) while any others MAY be unavailable or inactive, to be possibly used in the event of failure or unavailability of the active ASP(s).
Application Serverは実際的な言い方をするならあるInterface IdentifiersからQ.921-ユーザメッセージを処理するために構成されたすべてのASPのリストです。 どんな他のものも、活動的なASPの失敗か使用不能の場合、ことによると使用されるために入手できないか、または不活発であるかもしれませんが、通常、リストの1つ以上のASPが活動的です(すなわち、取り扱いトラフィック)。
Morneault, et al. Standards Track [Page 7] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[7ページ]。
The fail-over model supports an n+k redundancy model, where n ASP(s) are the minimum number of redundant ASPs required to handle traffic and k ASPs are available to take over for a failed or unavailable ASP. Note that 1+1 active/standby redundancy is a subset of this model. A simplex 1+0 model is also supported as a subset, with no ASP redundancy.
フェイルオーバーモデルはn+k冗長モデルをサポートします。そこでは、n ASPがトラフィックを扱わなければならなかった余分なASPの最小の数であり、k ASPは、失敗したか入手できないASPのために持って行くために利用可能です。 1つの+1アクティブな/予備冗長がこのモデルの部分集合であることに注意してください。 また、シンプレクス1+0モデルは部分集合としてASP冗長なしでサポートされます。
To avoid a single point of failure, it is recommended that a minimum of two ASPs be in the list, resident in separate hosts and therefore available over different SCTP Associations. For example, in the network shown in Figure 2, all messages from a particular D Channel (Interface Identifier) could be sent to ASP1 in Host1 or ASP1 in Host2. The AS list at SG1 might look like the following:
1ポイントの失敗を避けるために、最低2つのASPが別々のホストで居住していてしたがって、異なったSCTP Associationsの上で利用可能なリストでそうであることはお勧めです。 例えば、図2のネットワークでは、Host2のHost1かASP1で特定のD Channel(インタフェースIdentifier)からのすべてのメッセージをASP1に送ることができました。 SG1のASリストは以下に似るかもしれません:
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Inactive
インタフェース識別子(アプリケーションサーバ#1ASP1/Host1)は、= アクティブなASP1/Host2--上がって、上がって、不活発な状態で=を述べるように述べます。
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming message for the Interface Identifiers registered. ASP1 in Host2 would normally be brought to the active state upon failure of, or loss of connectivity to, ASP1/Host1. In this example, both ASPs are Up, meaning that the related SCTP association and far-end IUA peer is ready.
この1+1冗長場合では、登録されたInterface Identifiersのためのどんな入力メッセージもHost1のASP1に送るでしょう。 通常、Host2のASP1が接続性の失敗、または損失のときに活動的な状態に持って来られるだろう、ASP1/Host1。 この例では、関連するSCTP協会と遠端IUA同輩が準備ができていることを意味して、両方のASPはUpです。
The AS List at SG1 might also be set up in load-share mode as shown below:
また、SG1のAS Listは以下に示されるように負荷シェアモードでセットアップされるかもしれません:
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Active
インタフェース識別子--アプリケーションサーバ#1ASP1/Host1--状態は上、アクティブなASP1/Host2と等しいです--状態は上、能動態と等しいです。
In this case, both the ASPs would be sent a portion of the traffic.
この場合、トラフィックの部分を両方のASPに送るでしょう。
In the process of fail-over, it is recommended that in the case of ASPs supporting call processing, stable calls do not get released. It is possible that calls in transition MAY fail, although measures of communication between the ASPs involved can be used to mitigate this problem. For example, the two ASPs MAY share call state via shared memory, or MAY use an ASP to ASP protocol to pass call state information. The ASP to ASP protocol is outside the scope of this document.
フェイルオーバーの途中に、呼び出し処理をサポートするASPの場合では、安定した電話がリリースされないのは、お勧めです。 変遷における呼び出しが失敗するのは、可能です、この問題を緩和するのにかかわったASPのコミュニケーションの測定を使用できますが。 例えば、2つのASPが、共有メモリを通して呼び出し状態を共有するか、または呼び出し状態情報を通過するのにASPプロトコルにASPを使用するかもしれません。 このドキュメントの範囲の外にASPプロトコルへのASPがあります。
1.3.5 Client/Server Model
1.3.5 クライアント/サーバモデル
It is recommended that the SG and ASP be able to support both client and server operation. The peer endpoints using IUA SHOULD be configured so that one always takes on the role of client and the
SGとASPがクライアントとサーバ操作の両方をサポートすることができるのは、お勧めです。 そして人がいつもクライアントの役割を引き受けるように構成されていて、IUA SHOULDを使用する同輩終点。
Morneault, et al. Standards Track [Page 8] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[8ページ]。
other the role of server for initiating SCTP associations. The default orientation would be for the SG to take on the role of server while the ASP is the client. In this case, ASPs SHOULD initiate the SCTP association to the SG.
他、SCTP協会を開始するためのサーバの役割。 ASPはクライアントですが、デフォルトオリエンテーションはSGがサーバの役割を引き受けるだろうことです。 この場合、ASP SHOULDはSCTP協会をSGに開始します。
The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA is 9900.
IUAのためのSCTP(そして、UDP/TCP)の登録されたUser Port Number Assignmentは9900です。
1.4 Services Provided by the IUA Layer
IUAによって提供された1.4のサービスが層にされます。
1.4.1 Support for transport of Q.921/Q.931 boundary primitives
1.4.1 Q.921/Q.931境界基関数の輸送のサポート
In the backhaul scenario, the Q.921/Q.931 boundary primitives are exposed. IUA layer needs to support all of the primitives of this boundary to successfully backhaul Q.931.
逆送シナリオでは、Q.921/Q.931境界基関数は暴露されます。 IUAは首尾よくこの境界に関する基関数のすべてをサポートする必要性を層にします。逆送Q.931。
This includes the following primitives [1]:
これは以下の基関数[1]を含んでいます:
DL-ESTABLISH
dl設立します。
The DL-ESTABLISH primitives are used to request, indicate and confirm the outcome of the procedures for establishing multiple frame operation.
DL-ESTABLISH基関数は、複数のフレーム操作を確立するための手順の結果を要求して、示して、確認するのに使用されます。
DL-RELEASE
dlリリース
DL-RELEASE primitives are used to request, indicate, and confirm the outcome of the procedures for terminating a previously established multiple frame operation, or for reporting an unsuccessful establishment attempt.
DL-RELEASE基関数は、以前に確立した倍数フレーム操作を終えるか、または失敗の設立試みを報告するための手順の結果を要求して、示して、確認するのに使用されます。
DL-DATA
dlデータ
The DL-DATA primitives are used to request and indicate layer 3 (Q.931) messages which are to be transmitted, or have been received, by the Q.921 layer using the acknowledged information transfer service.
DL-DATA基関数は伝えられるか、または受け取られることである層3(Q.931)のメッセージを要求して、示すのに使用されます、承認された情報転送サービスを利用するQ.921層のそばで。
DL-UNIT DATA
dl単位データ
The DL-UNIT DATA primitives are used to request and indicate layer 3 (Q.931) messages which are to be transmitted, by the Q.921 layer using the unacknowledged information transfer service.
DL-UNIT DATA基関数は伝えられることである層3(Q.931)のメッセージを要求して、示すのに使用されます、不承認の情報転送サービスを利用するQ.921層のそばで。
Morneault, et al. Standards Track [Page 9] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[9ページ]。
1.4.2 Support for communication between Layer Management modules on SG
and MGC
1.4.2 SGとMGCの上のLayer Managementモジュールのコミュニケーションのサポート
It is envisioned that the IUA layer needs to provide some services that will facilitate communication between Layer Management modules on the SG and MGC. These primitives are pointed out in [2], which are shown below:
それは思い描かれます。IUA層が、いくつかのサービスにそれを提供する必要があるのがSGとMGCでLayer Managementモジュールのコミュニケーションを容易にするでしょう。 これらの基関数は[2]で指摘されます(以下に示されます):
M-TEI STATUS
M-TEI状態
The M-TEI STATUS primitives are used to request, confirm and indicate the status (assigned/unassigned) of a TEI.
M-TEI STATUS基関数は、TEIの状態(割り当てられるか、または割り当てられない)を要求して、確認して、示すのに使用されます。
M-ERROR
M誤り
The M-ERROR primitive is used to indicate an error with a received IUA message (e.g., interface identifier value is not known to the SG).
基関数が使用されているM-ERRORは受信されたIUAメッセージで誤りを示します(例えばインタフェース識別子価値はSGにおいて知られていません)。
1.4.3 Support for management of active associations between SG and MGC
1.4.3 SGとMGCとの活動的な協会の経営のサポート
A set of primitives between the IUA layer and the Layer Management are defined below to help the Layer Management manage the SCTP association(s) between the SG and MGC. The IUA layer can be instructed by the Layer Management to establish an SCTP association to a peer IUA node. This procedure can be achieved using the M-SCTP ESTABLISH primitive.
IUA層とLayer Managementの間の1セットの基関数は、Layer ManagementがSGとMGCとのSCTP協会を経営するのを助けるために以下で定義されます。 Layer Managementは、IUA層が同輩IUAノードにSCTP協会を設立するよう命令できます。 原始的にM-SCTP ESTABLISHを使用することでこの手順を達成できます。
M-SCTP ESTABLISH
M-SCTPは設立します。
The M-SCTP ESTABLISH primitives are used to request, indicate, and confirm the establishment of an SCTP association to a peer IUA node.
M-SCTP ESTABLISH基関数は、同輩IUAノードにSCTP協会の設立を要求して、示して、確認するのに使用されます。
M-SCTP RELEASE
M-SCTPリリース
The M-SCTP RELEASE primitives are used to request, indicate, and confirm the release of an SCTP association to a peer IUA node.
M-SCTP RELEASE基関数は、同輩IUAノードにSCTP協会のリリースを要求して、示して、確認するのに使用されます。
The IUA layer MAY also need to inform the status of the SCTP associations to the Layer Management. This can be achieved using the M-SCTP STATUS primitive.
また、IUA層は、SCTP協会の状態をLayer Managementに知らせる必要があるかもしれません。 原始的にM-SCTP STATUSを使用することでこれを達成できます。
M-SCTP STATUS
M-SCTP状態
The M-SCTP STATUS primitives are used to request and indicate the status of the underlying SCTP association(s).
M-SCTP STATUS基関数は、基本的なSCTP協会の状態を要求して、示すのに使用されます。
Morneault, et al. Standards Track [Page 10] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[10ページ]。
The Layer Management MAY need to inform the IUA layer of an AS/ASP status (i.e., failure, active, etc.), so that messages can be exchanged between IUA layer peers to stop traffic to the local IUA user. This can be achieved using the M-ASP STATUS primitive.
Layer Managementは、AS/ASP状態(すなわち、失敗、能動態など)のIUA層を知らせる必要があるかもしれません、地元のIUAユーザに通行を止めるためにIUA層の同輩の間でメッセージを交換できるように。 原始的にM-ASP STATUSを使用することでこれを達成できます。
M-ASP STATUS
M ASP状態
The ASP status is stored inside IUA layer on both the SG and MGC sides. The M-ASP STATUS primitive can be used by Layer Management to request the status of the Application Server Process from the IUA layer. This primitive can also be used to indicate the status of the Application Server Process.
ASP状態はSGとMGC側の両方にIUA層の中に保存されます。 Layer Managementは、IUA層からApplication Server Processの状態を要求するのにM-ASP STATUS基関数を使用できます。 また、Application Server Processの状態を示すのにこの基関数を使用できます。
M-ASP-UP
M ASP上
The M-ASP-UP primitive can be used by Layer Management to send a ASP Up message for the Application Server Process. It can also be used to generate an ASP Up Acknowledgement.
Layer Managementは、Application Server ProcessへのASP Upメッセージを送るのにM ASP UP基関数を使用できます。 また、ASP Up Acknowledgementを生成するのにそれを使用できます。
M-ASP-DOWN
ASPが倒すM
The M-ASP-DOWN primitive can be used by Layer Management to send a ASP Down message for the Application Server Process. It can also be used to generate an ASP Down Acknowledgement.
Layer Managementは、Application Server ProcessへのASP Downメッセージを送るのにM ASP DOWN基関数を使用できます。 また、ASP Down Acknowledgementを生成するのにそれを使用できます。
M-ASP-ACTIVE
M ASP能動態
The M-ASP-UP primitive can be used by Layer Management to send a ASP Active message for the Application Server Process. It can also be used to generate an ASP Active Acknowledgement.
Layer Managementは、Application Server ProcessへのASP Activeメッセージを送るのにM ASP UP基関数を使用できます。 また、ASP Active Acknowledgementを生成するのにそれを使用できます。
M-ASP-INACTIVE
M ASP不活発
The M-ASP-UP primitive can be used by Layer Management to send a ASP Inactive message for the Application Server Process. It can also be used to generate an ASP Inactive Acknowledgement.
Layer Managementは、Application Server ProcessへのASP Inactiveメッセージを送るのにM ASP UP基関数を使用できます。 また、ASP Inactive Acknowledgementを生成するのにそれを使用できます。
M-AS STATUS
M、-、状態
The M-AS STATUS primitive can be used by Layer Management to request the status of the Application Server. This primitive can also be used to indicate the status of the Application Server.
Layer Managementは、Application Serverの状態を要求するのにM-AS STATUS基関数を使用できます。また、Application Serverの状態を示すのにこの基関数を使用できます。
Morneault, et al. Standards Track [Page 11] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[11ページ]。
1.5 Functions Implemented by the IUA Layer
IUAによって実装された1.5の機能が層にされます。
1.5.1 Mapping
1.5.1 マッピング
The IUA layer MUST maintain a map of the Interface Identifier to a physical interface on the Signaling Gateway. A physical interface would be a T1 line, E1 line, etc., and could include the TDM timeslot. In addition, for a given interface the SG MUST be able to identify the associated signaling channel. IUA layers on both SG and MGC MAY maintain the status of TEIs and SAPIs.
IUA層はSignalingゲートウェイでInterface Identifierの地図を物理インターフェースに維持しなければなりません。 物理インターフェースは、T1系列、1Eの系列であるだろうなど、TDM timeslotを含むかもしれません。 当然のことに関して、さらに、SG MUSTを連結してください。関連シグナリングチャンネルを特定できてください。 SGとMGC MAYの両方のIUA層はTEIsとSAPIsの状態を維持します。
The SG maps an Interface Identifier to an SCTP association/stream only when an ASP sends an ASP Active message for a particular Interface Identifier. It MUST be noted, however, that this mapping is dynamic and could change at any time due to a change of ASP state. This mapping could even temporarily be invalid, for example during failover of one ASP to another. Therefore, the SG MUST maintain the states of AS/ASP and reference them during the routing of an messages to an AS/ASP.
ASPが特定のInterface IdentifierへのASP Activeメッセージを送るときだけ、SGはSCTP協会/ストリームにInterface Identifierを写像します。 しかしながら、このマッピングがダイナミックであり、いつでもASP状態の変化のため変化できたことに注意しなければなりません。 このマッピングは例えば、別のものの1つのASPのフェイルオーバーの間、一時無効でさえあるかもしれません。 したがって、SG MUSTはAS/ASPの州を維持して、AS/ASPへのメッセージのルーティングの間、彼らに参照をつけます。
One example of the logical view of relationship between D channel, Interface Identifier, AS and ASP in the SG is shown below:
Dチャネルと、Interface Identifierと、ASとASPとのSGでの関係の論理的な視点に関する1つの例が以下に示されます:
/---------------------------------------------------+
/ /------------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+-|+--+-
D chan1-------->|IID |-+ +-->| ASP |--->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
/ +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+
D chan2-------->|IID |-+ | ASP |
+----+ +-----+
/---------------------------------------------------+ / /------------------------------------------------|--+ //v| / / +----+ 行為+-----+ +-------+ -+--+-|+--+D chan1-------->|IID|-+ +-->| ASP|、-、--、>| Assoc| v/+----+ | +----+ | +-----+ +-------+ -+--+--+--+- / +->| as|--+ ストリーム/+----+ | +----+ stb+-----+ D chan2-------->|IID|-+ | ASP| +----+ +-----+
where IID = Interface Identifier
IIDがインタフェースIdentifierと等しいところ
Note that an ASP can be in more than one AS.
ASPが1ASにあることができることに注意してください。
1.5.2 Status of ASPs
1.5.2 ASPの状態
The IUA layer on the SG MUST maintain the state of the ASPs it is supporting. The state of an ASP changes because of reception of peer-to-peer messages (ASPM messages as described in Section 3.3.2) or reception of indications from the local SCTP association. ASP state transition procedures are described in Section 4.3.1.
SG MUSTの上のIUA層はそれがサポートしているASPの状態を維持します。 ASPの状態はピアツーピアメッセージ(セクション3.3.2で説明されるASPMメッセージ)のレセプションか指摘のレセプションのために地方のSCTP協会から変化します。 ASP状態遷移手順はセクション4.3.1で説明されます。
Morneault, et al. Standards Track [Page 12] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[12ページ]。
At a SG, an Application Server list MAY contain active and inactive ASPs to support ASP load-sharing and fail-over procedures. When, for example, both a primary and a back-up ASP are available, IUA peer protocol is required to control which ASP is currently active. The ordered list of ASPs within a logical Application Server is kept updated in the SG to reflect the active Application Server Process(es).
SGでは、Application ServerリストはサポートASP負荷分割法とフェイルオーバー手順にアクティブで不活発なASPを含むかもしれません。 例えば、予備選挙とバックアップASPの両方が利用可能であるときに、IUA同輩プロトコルが、どのASPが現在活動的であるかを制御するのに必要です。 論理的なApplication Serverの中のASPの規則正しいリストはSGでアップデートして、アクティブなApplication Server Process(es)を反映してください続けられます。
Also the IUA layer MAY need to inform the local management of the change in status of an ASP or AS. This can be achieved using the M- ASP STATUS or M-AS STATUS primitives.
また、IUA層は、ASPかASの状態の変化について現地管理職者に知らせる必要があるかもしれません。 M ASP STATUSかM-AS STATUS基関数を使用することでこれを達成できます。
1.5.3 SCTP Stream Management
1.5.3 SCTPストリーム管理
SCTP allows a user specified number of streams to be opened during the initialization. It is the responsibility of the IUA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, an IUA layer is not aware of the stream number to Interface Identifier mapping of its peer IUA layer. Instead, the Interface Identifier is in the IUA message header.
SCTPは初期化の間、ユーザの指定された番号のストリームを開かせます。 これらのストリームの適切な管理を確実にするのは、IUA層の責任です。ストリームの単方向の本質のために、IUA層は同輩IUA層に関するInterface Identifierマッピングにストリーム番号を意識していません。 代わりに、Interface IdentifierがIUAメッセージヘッダーにあります。
The use of SCTP streams within IUA is recommended in order to minimize transmission and buffering delay, therefore improving the overall performance and reliability of the signaling elements. It is recommended that a separate SCTP stream is used for each D channel.
IUAの中のSCTPストリームの使用は、トランスミッションを最小にするために推薦されて、遅れをバッファリングしています、したがって、シグナリング要素の総合的な性能と信頼性を向上させます。 別々のSCTPストリームが各Dチャネルに使用されるのは、お勧めです。
1.5.4 Seamless Network Management Interworking
1.5.4 シームレスのネットワークマネージメントの織り込むこと
The IUA layer on the SG SHOULD pass an indication of unavailability of the IUA-User (Q.931) to the local Layer Management, if the currently active ASP moves from the ACTIVE state. The Layer Management could instruct Q.921 to take some action, if it deems appropriate.
IUAはSG SHOULDパスの上にIUA-ユーザ(Q.931)の使用不能のしるしを地方のLayer Managementに層にします、現在活動的なASPがACTIVE状態から移行するなら。 Layer Managementは、それであるなら何らかの動作で取るようQ.921に命令するかもしれません。適切であると考えます。
Likewise, if an SCTP association fails, the IUA layer on both the SG and ASP sides MAY generate Release primitives to take the data links out-of-service.
同様に、SCTP協会が行き詰まるなら、SGとASP側の両方のIUA層は、使われなくなっていた状態でデータ・リンクを取るためにReleaseに基関数を生成するかもしれません。
1.5.5 Congestion Management
1.5.5 ふくそう管理
If the IUA layer becomes congested (implementation dependent), it MAY stop reading from the SCTP association to flow control from the peer IUA.
IUA層が混雑するように(実装に依存する)なるなら、それは、同輩IUAからSCTP協会からフロー制御まで読むのを止めるかもしれません。
Morneault, et al. Standards Track [Page 13] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[13ページ]。
1.6 Definition of IUA Boundaries
1.6 IUA境界の定義
1.6.1 Definition of IUA/Q.921 boundary
1.6.1 IUA/Q.921境界の定義
DL-ESTABLISH DL-RELEASE DL-DATA DL-UNIT DATA
dlリリースdlデータdl単位データをdl確立してください。
1.6.2 Definition of IUA/Q.931 boundary
1.6.2 IUA/Q.931境界の定義
DL-ESTABLISH DL-RELEASE DL-DATA DL-UNIT DATA
dlリリースdlデータdl単位データをdl確立してください。
1.6.3 Definition of SCTP/IUA Boundary
1.6.3 SCTP/IUA境界の定義
An example of the upper layer primitives provided by SCTP are available in Reference [3] section 10.
SCTPによって提供された上側の層の基関数の例はReference[3]セクション10で利用可能です。
1.6.4 Definition of IUA/Layer-Management Boundary
1.6.4 層IUA/管理限界の定義
M-SCTP ESTABLISH request Direction: LM -> IUA Purpose: LM requests ASP to establish an SCTP association with an SG.
M-SCTP ESTABLISHはDirectionを要求します: LM->IUA目的: LMは、SGとのSCTP協会を設立するようASPに要求します。
M-STCP ESTABLISH confirm
Direction: IUA -> LM
Purpose: ASP confirms to LM that it has established an SCTP
association with an SG.
M-STCP ESTABLISHはDirectionを確認します: IUA->LM目的: ASPは、SGとのSCTP協会を設立したとLMに確認します。
M-SCTP ESTABLISH indication
Direction: IUA -> LM
Purpose: SG informs LM that an ASP has established an SCTP
association.
M-SCTP ESTABLISH指示Direction: IUA->LM目的: SGは、ASPがSCTP協会を設立したことをLMに知らせます。
M-SCTP RELEASE request Direction: LM -> IUA Purpose: LM requests ASP to release an SCTP association with SG.
M-SCTP RELEASEはDirectionを要求します: LM->IUA目的: LMは、SGとのSCTP協会をリリースするようASPに要求します。
M-SCTP RELEASE confirm
Direction: IUA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with SG.
M-SCTP RELEASEはDirectionを確認します: IUA->LM目的: ASPは、SGとのSCTP協会をリリースしたとLMに確認します。
Morneault, et al. Standards Track [Page 14] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[14ページ]。
M-SCTP RELEASE indication Direction: IUA -> LM Purpose: SG informs LM that ASP has released an SCTP association.
M-SCTP RELEASE指示Direction: IUA->LM目的: SGは、ASPがSCTP協会をリリースしたことをLMに知らせます。
M-SCTP STATUS request Direction: LM -> IUA Purpose: LM requests IUA to report status of SCTP association.
M-SCTP STATUSはDirectionを要求します: LM->IUA目的: LMは、SCTP協会の状態を報告するようIUAに要求します。
M-SCTP STATUS indication Direction: IUA -> LM Purpose: IUA reports status of SCTP association.
M-SCTP STATUS指示Direction: IUA->LM目的: IUAはSCTP協会の状態を報告します。
M-ASP STATUS request Direction: LM -> IUA Purpose: LM requests SG to report status of remote ASP.
M-ASP STATUSはDirectionを要求します: LM->IUA目的: LMは、リモートASPの状態を報告するようSGに要求します。
M-ASP STATUS indication Direction: IUA -> LM Purpose: SG reports status of remote ASP.
M-ASP STATUS指示Direction: IUA->LM目的: SGはリモートASPの状態を報告します。
M-AS-STATUS request Direction: LM -> IUA Purpose: LM requests SG to report status of AS.
M-AS-STATUSはDirectionを要求します: LM->IUA目的: LMは、ASの状態を報告するようSGに要求します。
M-AS-STATUS indication Direction: IUA -> LM Purpose: SG reports status of AS.
M-AS-STATUS指示Direction: IUA->LM目的: SGはASの状態を報告します。
M-NOTIFY indication
Direction: IUA -> LM
Purpose: ASP reports that it has received a NOTIFY message
from its peer.
M-NOTIFY指示Direction: IUA->LM目的: ASPは、同輩からNOTIFYメッセージを受け取ったと報告します。
M-ERROR indication
Direction: IUA -> LM
Purpose: ASP or SG reports that it has received an ERROR
message from its peer.
M-ERROR指示Direction: IUA->LM目的: ASPかSGが、同輩からERRORメッセージを受け取ったと報告します。
M-ASP-UP request
Direction: LM -> IUA
Purpose: LM requests ASP to start its operation and send an ASP UP
message to the SG.
M ASP UPはDirectionを要求します: LM->IUA目的: LMはSGに操業を開始して、ASP UPメッセージを送るようASPに要求します。
M-ASP-UP confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP UP Acknowledgement
message from the SG.
M ASP UPはDirectionを確認します: IUA->LM目的: ASPレポートはSGからASP UP Acknowledgementメッセージを受け取りました。
Morneault, et al. Standards Track [Page 15] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[15ページ]。
M-ASP-DOWN request
Direction: LM -> IUA
Purpose: LM requests ASP to stop its operation and send an ASP DOWN
message to the SG.
M ASP DOWNはDirectionを要求します: LM->IUA目的: LMはSGに操作を止めて、ASP DOWNメッセージを送るようASPに要求します。
M-ASP-DOWN confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP DOWN
Acknowledgement message from the SG.
M ASP DOWNはDirectionを確認します: IUA->LM目的: ASPレポートはSGからASP DOWN Acknowledgementメッセージを受け取りました。
M-ASP-ACTIVE request Direction: LM -> IUA Purpose: LM requests ASP to send an ASP ACTIVE message to the SG.
M ASP ACTIVEはDirectionを要求します: LM->IUA目的: LMは、ASP ACTIVEメッセージをSGに送るようASPに要求します。
M-ASP-ACTIVE confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE
Acknowledgement message from the SG.
M ASP ACTIVEはDirectionを確認します: IUA->LM目的: ASPレポートはSGからASP ACTIVE Acknowledgementメッセージを受け取りました。
M-ASP-INACTIVE request Direction: LM -> IUA Purpose: LM requests ASP to send an ASP INACTIVE message to the SG.
M ASP INACTIVEはDirectionを要求します: LM->IUA目的: LMは、ASP INACTIVEメッセージをSGに送るようASPに要求します。
M-ASP-INACTIVE confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP INACTIVE
Acknowledgement message from the SG.
M ASP INACTIVEはDirectionを確認します: IUA->LM目的: ASPレポートはSGからASP INACTIVE Acknowledgementメッセージを受け取りました。
M-TEI STATUS request Direction: LM -> IUA Purpose: LM requests ASP to send a TEI status request to the SG.
M-TEI STATUSはDirectionを要求します: LM->IUA目的: LMは、TEI状態要求をSGに送るようASPに要求します。
M-TEI STATUS indication
Direction: IUA -> LM
Purpose: ASP reports that is has received a TEI status indication
from the SG.
M-TEI STATUS指示Direction: IUA->LM目的: ASPレポートはSGからTEI状態指示を受けました。
M-TEI STATUS confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received a TEI status confirm from the
SG.
M-TEI STATUSはDirectionを確認します: IUA->LM目的: そうするASPレポートはTEI状態を取りました。SGから、確認します。
2.0 Conventions
2.0 コンベンション
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードが解釈しなければならない、本書では現れるとき、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Morneault, et al. Standards Track [Page 16] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[16ページ]。
3.0 Protocol Elements
3.0 Protocol Elements
This section describes the format of various messages used in this protocol.
このセクションはこのプロトコルに使用される様々なメッセージの形式について説明します。
3.1 Common Message Header
3.1 一般的なメッセージヘッダー
The protocol messages for Q.921-User Adaptation require a message header which contains the adaptation layer version, the message type, and message length.
Q.921-ユーザAdaptationへのプロトコルメッセージは適合層のバージョン、メッセージタイプ、およびメッセージ長を含むメッセージヘッダーを必要とします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 予約されます。| メッセージのクラス| メッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Common Header Format
図3 一般的なヘッダー形式
All fields in an IUA message MUST be transmitted in the network byte order, unless otherwise stated.
別の方法で述べられない場合、ネットワークバイトオーダーでIUAメッセージのすべての野原を伝えなければなりません。
3.1.1 Version
3.1.1 バージョン
The version field contains the version of the IUA adaptation layer. The supported versions are the following:
バージョン分野はIUA適合層のバージョンを含んでいます。 サポートしているバージョンは以下です:
Value Version
----- -------
1 Release 1.0
値のバージョン----- ------- 1 リリース1.0
3.1.2 Message Classes and Types
3.1.2 メッセージのクラスとタイプ
The following List contains the valid Message Classes:
以下のListは有効なMessage Classesを含んでいます:
Message Class: 8 bits (unsigned integer)
メッセージのクラス: 8ビット(符号のない整数)
0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
1 Transfer Messages [M3UA]
2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
5 Q.921/Q.931 Boundary Primitives Transport (QPTM)
Messages [IUA]
6 MTP2 User Adaptation (MAUP) Messages [M2UA]
7 Connectionless Messages [SUA]
0 [M3UA]2SS7が(QPTM)メッセージ[IUA]6MTP2ユーザ適合(MAUP)メッセージ[M2UA]7コネクションレスなメッセージを輸送するとネットワークマネージメント(SSNM)メッセージ[M3UA/SUA]3ASP州のメインテナンス(ASPSM)メッセージ[IUA/M2UA/M3UA/SUA]4ASPトラフィックメインテナンス(ASPTM)メッセージ[IUA/M2UA/M3UA/SUA]5Q.921/Q.931境界基関数に合図する管理(管理)メッセージ[IUA/M2UA/M3UA/SUA]1転送メッセージ[SUA]
Morneault, et al. Standards Track [Page 17] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[17ページ]。
8 Connection-Oriented Messages [SUA]
9 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions
8 IETFによって定義されたMessage Class拡張子のためのIETF128〜255Reservedによる接続が指向のMessages[SUA]9〜127Reserved
The following list contains the message names for the defined messages.
以下のリストは定義されたメッセージのためのメッセージ名を含んでいます。
Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
Q.921/Q.931境界基関数輸送(QPTM)メッセージ
0 Reserved
1 Data Request Message
2 Data Indication Message
3 Unit Data Request Message
4 Unit Data Indication Message
5 Establish Request
6 Establish Confirm
7 Establish Indication
8 Release Request
9 Release Confirm
10 Release Indication
11 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined QPTM extensions
0 IETFによって定義されたQPTM拡張子のためのIETF128〜255Reservedによる予約された1Data Request Message2のData Indication Message3Unit Data Request Message4Unit Data Indication Message5Establish Request6Establish Confirm7Establish Indication8Release Request9Release Confirm10Release Indication11〜127Reserved
Application Server Process State Maintenance (ASPSM) messages
アプリケーションServer Process州Maintenance(ASPSM)メッセージ
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heatbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
0 IETFによって定義されたASPSM拡張子のためのIETF128〜255Reservedによる予約された1つのASP Up(UP)2ASP Down(DOWN)3Heartbeat(BEAT)4ASP Up Ack(UP ACK)5ASP Down Ack(DOWN ACK)6Heatbeat Ack(BEAT ACK)7〜127Reserved
Application Server Process Traffic Maintenance (ASPTM) messages
アプリケーションServer Process Traffic Maintenance(ASPTM)メッセージ
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
0 IETFによって定義されたASPTM拡張子のためのIETF128〜255Reservedによる1つのASPの予約されたActive(ACTIVE)2ASP Inactive(INACTIVE)3ASP Active Ack(ACTIVE ACK)4ASP Inactive Ack(INACTIVE ACK)5〜127Reserved
Morneault, et al. Standards Track [Page 18] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[18ページ]。
Management (MGMT) Messages
管理(管理)メッセージ
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions
0 IETFによって定義されたMGMT拡張子のためのIETF128〜255Reservedによる誤り(ERR)1Notify(NTFY)2TEI Status Request3TEI Status Confirm4TEI Status Indication5〜127Reserved
3.1.3 Reserved
3.1.3 予約されています。
The Reserved field is 8-bits. It SHOULD be set to all '0's and ignored by the receiver.
Reserved分野は8ビットです。 それ、SHOULDがすべての'に0設定されて、受信機を無視した、'
3.1.4 Message Length
3.1.4 メッセージ長
The Message length defines the length of the message in octets, including the Common header.
Messageの長さはCommonヘッダーを含む八重奏における、メッセージの長さを定義します。
3.1.5 Variable-Length Parameter Format
3.1.5 可変長のパラメタ形式
IUA messages consist of a Common Header followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameters contained in a message are defined in a Tag-Length-Value format as shown below.
IUAメッセージはメッセージタイプによって定義されるようにゼロか、より可変長のパラメタがあとに続いたCommon Headerから成ります。 メッセージに含まれた可変長のパラメタはTag長さの価値の形式で以下に示すように定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメタタグ| パラメタの長さ| パラメタ..値
Mandatory parameters MUST be placed before optional parameters in a message.
メッセージの任意のパラメタの前に義務的なパラメタを置かなければなりません。
Parameter Tag: 16 bits (unsigned integer)
パラメタタグ: 16ビット(符号のない整数)
The Tag field is a 16 bit identifier of the type of parameter. It takes a value of 0 to 65534.
Tag分野はパラメタのタイプに関する16ビットの識別子です。 それは0〜65534の値を取ります。
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific parameter description are reserved for use by the IETF.
65535の値はIETFによって定義された拡大のために予約されます。 特定のパラメータ記述で定義されたもの以外の値は使用のためにIETFによって予約されます。
Morneault, et al. Standards Track [Page 19] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[19ページ]。
Parameter Length: 16 bits (unsigned integer)
パラメタの長さ: 16ビット(符号のない整数)
The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. The Parameter Length does not include any padding bytes.
Parameter Length分野はバイトで表現されるパラメタのサイズを含んでいます、Parameter Tag、Parameter Length、およびParameter Value分野を含んでいて。 Parameter Lengthはどんな詰め物バイトも含んでいません。
Parameter Value: variable-length
パラメタ値: 可変長
The Parameter Value field contains the actual information to be transferred in the parameter.
Parameter Value分野はパラメタで移されるべき実際の情報を含んでいます。
The total length of a parameter (including Tag, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is NOT included in the parameter length field. A sender SHOULD NEVER pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
パラメタ(Tag、Parameter Length、およびValue分野を含んでいる)の全長は4バイトの倍数であるに違いありません。 パラメタの長さが4バイトの倍数でないなら、送付者は終わり(すなわち、Parameter Value分野の後の)にすべてのバイトでどんなParameterを水増ししません。 詰め物の長さはパラメタ長さの分野に含まれていません。 3バイト以上がある送付者SHOULD NEVERパッド。 受信機は詰め物バイトを無視しなければなりません。
3.2 IUA Message Header
3.2 IUAメッセージヘッダー
In addition to the common message header, there will be a specific message header for QPTM and the TEI Status MGMT messages. The IUA message header will immediately follow the Common header in these messages.
一般的なメッセージヘッダーに加えて、QPTMのための特定のメッセージヘッダーとTEI Status MGMTメッセージがあるでしょう。 IUAメッセージヘッダーはすぐに、これらのメッセージでCommonヘッダーについて来るでしょう。
This message header will contain the Interface Identifier and Data Link Connection Identifier (DLCI). The Interface Identifier identifies the physical interface terminating the signaling channel at the SG for which the signaling messages are sent/received. The format of the Interface Identifier parameter can be text or integer. The Interface Identifiers are assigned according to network operator policy. The integer values used are of local significance only, coordinated between the SG and ASP.
このメッセージヘッダーはInterface IdentifierとData Link Connection Identifier(DLCI)を含むでしょう。 Interface Identifierはシグナリングがシグナリングメッセージが送られるSGでチャネルを開設したか、または受けた物理インターフェースの終わりを特定します。 Interface Identifierパラメタの形式は、テキストか整数であるかもしれません。 ネットワーク・オペレータ方針によると、Interface Identifiersは割り当てられます。 使用される整数値はSGとASPの間で唯一の、そして、連携しているローカルの意味のものです。
The integer formatted Interface Identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported.
整数のフォーマットされたInterface Identifierをサポートしなければなりません。 テキストのフォーマットされたInterface Identifierは任意にサポートされるかもしれません。
Morneault, et al. Standards Track [Page 20] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[20ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×1)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子(整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×5)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI| 予備| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 IUA Message Header (Integer-based Interface Identifier)
図4 IUAメッセージヘッダー(整数ベースのインタフェース識別子)
The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8.
IntegerベースのInterface IdentifierのためのTag値は0×1です。 長さはいつも8の値に設定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×3)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (text) |
| インタフェース識別子(テキスト)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x5) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI | Spare | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×5)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI| 予備| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IUA Message Header (Text-based Interface Identifier)
図5 IUAメッセージヘッダー(テキストベースのインタフェース識別子)
The Tag value for the Text-based Interface Identifier is 0x3. The length is variable.
TextベースのInterface IdentifierのためのTag値は0×3です。 長さは可変です。
The DLCI format is shown below in Figure 6.
DLCI書式は図6に以下に示されます。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | SPR | SAPI |
+-----------------------------------------------+
| 1 | TEI |
+-----------------------------------------------+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | SPR| SAPI| +-----------------------------------------------+ | 1 | TEI| +-----------------------------------------------+
Figure 6 DLCI Format
図6 DLCI形式
SPR: Spare 2nd bit in octet 1, (1 bit)
SPR: 八重奏1で2番目のビットを割いてください。(1ビット)
Morneault, et al. Standards Track [Page 21] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[21ページ]。
SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
1 (6 bits)
SAPI: サービスAccess Point Identifier、八重奏1における3番目〜8番目のビット(6ビット)
TEI: Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
(7 bits)
TEI: 端末のEndpoint Identifier、八重奏2における2番目〜8番目のビット(7ビット)
The DLCI field (including the SAPI and TEI) is coded in accordance with Q.921.
Q.921によると、DLCI分野(SAPIとTEIを含んでいる)はコード化されます。
3.3 IUA Messages
3.3 IUAメッセージ
The following section defines the messages and parameter contents. The IUA messages will use the common message header (Figure 3) and the IUA message header (Figure 4 and Figure 5).
以下のセクションはメッセージとパラメタコンテンツを定義します。 IUAメッセージは一般的なメッセージヘッダー(図3)とIUAメッセージヘッダー(図4と図5)を使用するでしょう。
3.3.1 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
3.3.1 Q.921/Q.931境界基関数輸送(QPTM)メッセージ
3.3.1.1 Establish Messages (Request, Confirm, Indication)
3.3.1.1 メッセージを確立してください。(要求、確認、指示)
The Establish Messages are used to establish a data link on the signaling channel or to confirm that a data link on the signaling channel has been established. The MGC controls the state of the D channel. When the MGC desires the D channel to be in-service, it will send the Establish Request message.
Establish Messagesは、シグナリングチャンネルの上にデータ・リンクを証明するか、またはシグナリングチャンネルの上のデータ・リンクが設立されたと確認するのに使用されます。 MGCはDチャネルの状態を制御します。 MGCが、Dチャネルが稼働中であることで、Establish Requestメッセージを送るということであることを望んでいるとき。
When the MGC sends an IUA Establish Request message, the MGC MAY start a timer. This timer would be stopped upon receipt of an IUA Establish Confirm or Establish Indication. If the timer expires, the MGC would re-send the IUA Establish Request message and restart the timer. In other words, the MGC MAY continue to request the establishment of the data link on periodic basis until the desired state is achieved or take some other action (notify the Management Layer).
MGCがIUA Establish Requestメッセージを送るとき、MGC MAYはタイマを始動します。 このタイマはIUA Establish ConfirmかEstablish Indicationを受け取り次第止められるでしょう。 タイマが期限が切れるなら、MGCはIUA Establish Requestメッセージを再送して、タイマを再開するでしょう。 言い換えれば、MGC MAYは必要な状態が獲得されるまで周期的ベースにおけるデータ・リンクの設立を要求し続けているか、またはある他の行動を取ります(Management Layerに通知してください)。
When the SG receives an IUA Establish Request from the MGC, the SG shall send the Q.921 Establish Request primitive to the its Q.921 entity. In addition, the SG shall map any response received from the Q.921 entity to the appropriate message to the MGC. For example, if the Q.921 entity responds with a Q.921 Establish Confirm primitive, the IUA layer shall map this to an IUA Establish Confirm message. As another example, if the IUA Layer receives a Q.921 Release Confirm or Release Indication as an apparent response to the Q.921 Establish Request primitive, the IUA Layer shall map these to the corresponding IUA Release Confirm or Release Indication messages.
いつにSGがMGCからIUA Establish Requestを受けて、SGがQ.921 Establish Requestを原始的に送るものとするか、そのQ.921実体 さらに、SGはQ.921実体から適切なメッセージまでMGCに受けられたどんな応答も写像するものとします。 例えば、Q.921 Establish Confirmが原始的にQ.921実体が応じるなら、IUA層はIUA Establish Confirmメッセージにこれを写像するものとします。 別の例として、IUA LayerがQ.921 Establish Requestへの見かけの応答として原始的にQ.921 Release ConfirmかRelease Indicationを受けるなら、IUA Layerは対応するIUA Release ConfirmかRelease Indicationメッセージにこれらを写像するものとします。
The Establish messages contain the common message header followed by IUA message header. It does not contain any additional parameters.
EstablishメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 それはどんな追加パラメタも含んでいません。
Morneault, et al. Standards Track [Page 22] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[22ページ]。
3.3.1.2 Release Messages (Request, Indication, Confirmation)
3.3.1.2 リリースメッセージ(要求、指示、確認)
The Release Request message is used to release the data link on the signaling channel. The Release Confirm and Indication messages are used to indicate that the data link on the signaling channel has been released.
Release Requestメッセージは、シグナリングチャンネルでデータ・リンクをリリースするのに使用されます。 Release ConfirmとIndicationメッセージは、シグナリングチャンネルの上のデータ・リンクがリリースされたのを示すのに使用されます。
If a response to the Release Request message is not received, the MGC MAY resend the Release Request message. If no response is received, the MGC can consider the data link as being released. In this case, signaling traffic on that D channel is not expected from the SG and signaling traffic will not be sent to the SG for that D channel.
Release Requestメッセージへの応答が受け取られていないなら、MGC MAYはRelease Requestメッセージを再送します。 どんな応答も受け取られていないなら、MGCは、データ・リンクがリリースすることにされるのであるとみなすことができます。 この場合、そのDチャネルに関するシグナリングトラフィックはSGから予想されません、そして、シグナリングトラフィックはそのDチャネルのためにSGに送られないでしょう。
The Release messages contain the common message header followed by IUA message header. The Release confirm message is in response to a Release Request message and it does not contain any additional parameters. The Release Request and Indication messages contain the following parameter:
ReleaseメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 Releaseは、メッセージがRelease Requestメッセージに対応していると確認します、そして、それはどんな追加パラメタも含んでいません。 Release RequestとIndicationメッセージは以下のパラメタを含んでいます:
REASON
理由
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xf) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xf)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 理由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Reason are shown in the following table.
Reasonのための有効値は以下のテーブルに示されます。
Define Value Description
RELEASE_MGMT 0x0 Management layer generated release.
RELEASE_PHYS 0x1 Physical layer alarm generated release.
RELEASE_DM 0x2 Specific to a request. Indicates Layer 2
SHOULD release and deny all requests from
far end to establish a data link on the
signaling channel (i.e., if SABME is
received send a DM)
RELEASE_OTHER 0x3 Other reasons
リリースであると生成されたValue記述RELEASE_MGMT0x0Management層を定義してください。 RELEASE_PHYS0x1Physical層のアラームはリリースを作りました。 要求へのRELEASE_DM0x2Specific。 Layer2SHOULDがシグナリングチャンネル(すなわち、SABMEが受け取られているなら、DMを送る)RELEASE_OTHER0x3Other理由でデータ・リンクを証明するために遠端からすべての要求を発表して、否定するのを示します。
Note: Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid reason codes for a Release Request message.
以下に注意してください。 RELEASE_MGMT、RELEASE_DM、および唯一のRELEASE_OTHERはRelease Requestメッセージのための正当な理由コードです。
3.3.1.3 Data Messages (Request, Indication)
3.3.1.3 データメッセージ(要求、指示)
The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to acknowledged information transfer service.
Dataメッセージは承認された情報転送サービスに対応するISDN Q.921-ユーザプロトコルData Unit(PDU)を含んでいます。
Morneault, et al. Standards Track [Page 23] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[23ページ]。
The Data messages contain the common message header followed by IUA message header. The Data message contains the following parameters:
DataメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 Dataメッセージは以下のパラメタを含んでいます:
PROTOCOL DATA
プロトコルデータ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xe)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data |
| プロトコルデータ|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The protocol data contains upper layer signaling message e.g. Q.931, QSIG.
プロトコルデータは例えば、上側の層のシグナリングメッセージQ.931、QSIGを含んでいます。
3.3.1.4 Unit Data Messages (Request, Indication)
3.3.1.4 ユニットデータメッセージ(要求、指示)
The Unit Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to unacknowledged information transfer service.
Unit Dataメッセージは不承認の情報転送サービスに対応するISDN Q.921-ユーザプロトコルData Unit(PDU)を含んでいます。
The Unit Data messages contain the common message header followed by IUA message header. The Unit Data message contains the following parameters
Unit DataメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 Unit Dataメッセージは以下のパラメタを含んでいます。
PROTOCOL DATA
プロトコルデータ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xe)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data |
| プロトコルデータ|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.2 Application Server Process Maintenance (ASPM) Messages
3.3.2 アプリケーション・サーバープロセスメインテナンス(ASPM)メッセージ
The ASPM messages will only use the common message header.
ASPMメッセージは一般的なメッセージヘッダーを使用するだけでしょう。
3.3.2.1 ASP Up (ASPUP)
3.3.2.1 ASP上(ASPUP)
The ASP Up (ASPUP) message is sent by an ASP to indicate to an SG that it is ready to receive traffic or maintenance messages.
ASP Up(ASPUP)メッセージは、それがトラフィックかメインテナンスメッセージを受け取る準備ができているのをSGに示すためにASPによって送られます。
Morneault, et al. Standards Track [Page 24] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[24ページ]。
The ASPUP message contains the following parameters:
ASPUPメッセージは以下のパラメタを含んでいます:
Info String (optional)
インフォメーションストリング(任意)です。
The format for ASPUP Message parameters is as follows:
ASPUP Messageパラメタのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional INFO String parameter can carry any meaningful 8-bit ASCII character string along with the message. Length of the INFO String parameter is from 0 to 255 characters. No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes.
任意のINFO Stringパラメタはメッセージに伴うどんな重要な8ビットのASCII文字列も運ぶことができます。 INFO Stringパラメタの長さは0〜255のキャラクタです。 手順は全く現在、使用のために特定されませんが、INFO Stringはデバッグ目的に使用されるかもしれません。
3.3.2.2 ASP Up Ack
3.3.2.2 AckへのASP
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote IUA peer.
ASP Up Ackメッセージは、リモートIUA同輩から受け取られたASP Upメッセージを承認するのに使用されます。
The ASPUP Ack message contains the following parameters:
ASPUP Ackメッセージは以下のパラメタを含んでいます:
INFO String (optional)
インフォメーションストリング(任意)です。
The format for ASPUP Ack Message parameters is as follows:
ASPUP Ack Messageパラメタのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.3.1).
セクション3.3を見てください。任意のInfo Stringパラメタの形式と記述がASP Upメッセージのように同じである、(.3 .1)。
Morneault, et al. Standards Track [Page 25] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[25ページ]。
3.3.2.3 ASP Down (ASPDN)
3.3.2.3 ASP下(ASPDN)
The ASP Down (ASPDN) message is sent by an ASP to indicate to an SG that it is NOT ready to receive traffic or maintenance messages.
ASP Down(ASPDN)メッセージは、それがトラフィックかメインテナンスメッセージを受け取る準備ができていないのをSGに示すためにASPによって送られます。
The ASPDN message contains the following parameters:
ASPDNメッセージは以下のパラメタを含んでいます:
Reason
INFO String (Optional)
理由インフォメーションストリング(任意)です。
The format for the ASPDN message parameters is as follows:
ASPDNメッセージパラメタのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xa)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 理由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.3.1.).
任意のInfo Stringパラメタの形式と記述はASP Upメッセージのように同じです(.1にセクション3.3.3を見てください)。
The Reason parameter indicates the reason that the remote IUA adaptation layer is unavailable. The valid values for Reason are shown in the following table.
Reasonパラメタは遠く離れたIUA適合層が入手できない理由を示します。 Reasonのための有効値は以下のテーブルに示されます。
Value Description
0x1 Management Inhibit
経営者側が抑制する値の記述0x1
If a ASP is removed from Management Inhibit, the ASP will send an ASP Up message.
Management InhibitからASPを免職すると、ASPはASP Upメッセージを送るでしょう。
3.3.2.4 ASP Down Ack
3.3.2.4 ASP下のAck
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer.
ASP Down Ackメッセージは、リモートIUA同輩から受け取られたASP Downメッセージを承認するのに使用されます。
The ASP Down Ack message contains the following parameters:
ASP Down Ackメッセージは以下のパラメタを含んでいます:
Reason
INFO String (Optional)
理由インフォメーションストリング(任意)です。
Morneault, et al. Standards Track [Page 26] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[26ページ]。
The format for the ASP Down Ack message parameters is as follows:
ASP Down Ackメッセージパラメタのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xa)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 理由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1.).
任意のInfo Stringパラメタの形式と記述はASP Upメッセージのように同じです(.1にセクション3.3.2を見てください)。
The format of the Reason parameter is the same as for the ASP Down message (See Section 3.3.2.3).
セクション3.3を見てください。Reasonパラメタの形式がASP Downメッセージのように同じである、(.2 .3)。
3.3.2.5 ASP Active (ASPAC)
3.3.2.5 ASPアクティブです。(ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is Active and ready to be used.
ASPACメッセージは、それがActiveであることをSGに示すためにASPによって送られて、使用される準備ができています。
The ASPAC message contains the following parameters
ASPACメッセージは以下のパラメタを含んでいます。
Traffic Mode Type (Mandatory)
Interface Identifier (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
トラフィックMode Type(義務的な)インタフェースIdentifier(任意の)--整数の組み合わせと整数範囲、OR--ストリング(フォーマットされたテキスト)INFO String(任意)です。
Morneault, et al. Standards Track [Page 27] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[27ページ]。
The format for the ASPAC message using integer formatted Interface Identifiers is as follows:
整数を使用するASPACメッセージがInterface Identifiersをフォーマットしたので、形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 |
| 追加インタフェース識別子| | タグタイプ0×1か0x8について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 28] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[28ページ]。
The format for the ASPAC message using text formatted (string) Interface Identifiers is as follows:
テキストを使用するASPACメッセージが(ストリング)インタフェースIdentifiersをフォーマットしたので、形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
| 追加インタフェース識別子| | タグタイプ0x3について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table:
Traffic Mode TypeパラメタはASの中でASPのトラフィック運転モードを特定します。 Typeのための有効値は以下のテーブルに示されます:
Value Description
0x1 Over-ride
0x2 Load-share
値の記述0x1オーバーライド0x2負荷シェア
Within a particular Interface Identifier, only one Traffic Mode Type can be used. The Over-ride value indicates that the ASP is operating in Over-ride mode, where the ASP takes over all traffic in an Application Server (i.e., primary/back-up operation), over-riding any currently active ASPs in the AS. In Load-share mode, the ASP will share in the traffic distribution with any other currently active ASPs.
特定のInterface Identifierの中では、1Traffic Mode Typeしか使用できません。 Over-乗りの値は、ASPがASPがApplication Server(すなわち、予備選挙/バックアップ操作)のすべてのトラフィックを引き継ぐOver-乗りのモードで作動しているのを示します、ASのどんな現在活動的なASPもくつがえして。 Load-シェアモードで、ASPはいかなる他の現在活動的なASPとのトラヒック分配も分担するでしょう。
The optional Interface Identifiers parameter contains a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) indexing the Application Server traffic that the sending ASP is configured/registered to receive. If integer formatted
任意のInterface Identifiersパラメタは、送付ASPが受けるために構成されるか、または登録されるApplication Serverトラフィックに索引をつけながら、Interface Identifier整数(0×1かType0x8をタイプする)かテキスト文字列(0×3をタイプする)のリストを含んでいます。 整数はフォーマットしました。
Morneault, et al. Standards Track [Page 29] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[29ページ]。
Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers (Type 0x8). Interface Identifier types Integer (0x1) and Integer Range (0x8) are allowed in the same message. Text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types.
インタフェースIdentifiersは使用されています、また、ASPがInterface Identifiersの範囲を送ることができます(0×8をタイプしてください)。 インタフェースIdentifierはInteger(0×1)をタイプします、そして、Integer Range(0×8)は同じメッセージに許容されています。 Integer(0×1)かInteger Range(0×8)タイプのどちらかでテキストのフォーマットされたInterface Identifiers(0×3)を使用できません。
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. If only a subset of Interface Identifiers are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
どんなInterface Identifiersも含まれていないなら、ASPが食糧を供給されるAS(s)の中にメッセージはすべての食糧を供給されたInterface Identifiersのためにあります。 Interface Identifiersの部分集合だけが含まれているなら、ASPはそのASのために食糧を供給されたすべてのInterface IdentifiersでActiveとして有名です。
Note: If the optional Interface Identifier parameter is present, the integer formatted Interface Identifier MUST be supported, while the text formatted Interface Identifier MAY be supported.
以下に注意してください。 任意のInterface Identifierパラメタが存在しているなら、整数のフォーマットされたInterface Identifierをサポートしなければなりません、テキストのフォーマットされたInterface Identifierはサポートされるかもしれませんが。
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1.).
任意のInfo Stringパラメタの形式と記述はASP Upメッセージのように同じです(.1にセクション3.3.2を見てください)。
An SG that receives an ASPAC with an incorrect Traffic Mode Type for a particular Interface Identifier will respond with an Error Message (Cause: Unsupported Traffic Handling Mode).
特定のInterface Identifierのために不正確なTraffic Mode Typeと共にASPACを受けるSGはError Message(原因: サポートされないTraffic Handling Mode)と共に応じるでしょう。
3.3.2.6 ASP Active Ack
3.3.2.6 ASPのアクティブなAck
The ASPAC Ack message is used to acknowledge an ASP-Active message received from a remote IUA peer.
ASPAC Ackメッセージは、リモートIUA同輩から受け取られたASPアクティブなメッセージを承認するのに使用されます。
The ASPAC Ack message contains the following parameters:
ASPAC Ackメッセージは以下のパラメタを含んでいます:
Traffic Mode Type (Mandatory)
Interface Identifier (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
トラフィックMode Type(義務的な)インタフェースIdentifier(任意の)--整数の組み合わせと整数範囲、OR--ストリング(フォーマットされたテキスト)INFO String(任意)です。
Morneault, et al. Standards Track [Page 30] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[30ページ]。
The format for the ASPAC Ack message with Integer-formatted Interface Identifiers is as follows:
IntegerによってフォーマットされたInterface IdentifiersがあるASPAC Ackメッセージのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 |
| 追加インタフェース識別子| | タグタイプ0×1か0x8について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 31] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[31ページ]。
The format for the ASP Active Ack message using text formatted (string) Interface Identifiers is as follows:
テキストを使用するASP Active Ackメッセージが(ストリング)インタフェースIdentifiersをフォーマットしたので、形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
| 追加インタフェース識別子| | タグタイプ0x3について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Traffic Mode Type and Interface Identifier parameters is the same as for the ASP Active message (See Section 3.3.2.5).
セクション3.3を見てください。Traffic Mode TypeとInterface Identifierパラメタの形式がASP Activeメッセージのように同じである、(.2 .5)。
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1.).
任意のInfo Stringパラメタの形式と記述はASP Upメッセージのように同じです(.1にセクション3.3.2を見てください)。
3.3.2.7 ASP Inactive (ASPIA)
3.3.2.7 ASP不活発です。(ASPIA)
The ASPIA message is sent by an ASP to indicate to an SG that it is no longer an active ASP to be used from within a list of ASPs. The SG will respond with an ASPIA Ack message and either discard incoming messages or buffer for a timed period and then discard.
ASPIAメッセージは、ASPのリストから使用されるのが、もう活動的なASPでないことをSGに示すためにASPによって送られます。 SGはASPIA Ackメッセージで応じて、調節された期間、入力メッセージかバッファを捨てて、次に、捨てるでしょう。
The ASPIA message contains the following parameters
ASPIAメッセージは以下のパラメタを含んでいます。
Traffic Mode Type (Mandatory)
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
Mode Typeの(義務的)のインタフェースIdentifiers(任意の)(整数の組み合わせと整数範囲、OR)が結ぶトラフィック(フォーマットされたテキスト)
Morneault, et al. Standards Track [Page 32] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[32ページ]。
INFO String (Optional)
インフォメーションストリング(任意)です。
The format for the ASP Inactive message parameters using Integer formatted Interface Identifiers is as follows:
Integerを使用するASP InactiveメッセージパラメタがInterface Identifiersをフォーマットしたので、形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 |
| 追加インタフェース識別子| | タグタイプ0×1か0x8について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 33] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[33ページ]。
The format for the ASP Inactive message using text formatted (string) Interface Identifiers is as follows:
テキストを使用するASP Inactiveメッセージが(ストリング)インタフェースIdentifiersをフォーマットしたので、形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
| 追加インタフェース識別子| | タグタイプ0x3について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Traffic Mode Type are shown in the following table:
Traffic Mode TypeパラメタはASの中でASPのトラフィック運転モードを特定します。 Traffic Mode Typeのための有効値は以下のテーブルに示されます:
Value Description
0x1 Over-ride
0x2 Load-share
値の記述0x1オーバーライド0x2負荷シェア
The format and description of the optional Interface Identifiers and Info String parameters is the same as for the ASP Active message (See Section 3.3.2.3.).
任意のInterface IdentifiersとInfo Stringパラメタの形式と記述はASP Activeメッセージのように同じです(.3にセクション3.3.2を見てください)。
The optional Interface Identifiers parameter contains a list of Interface Identifier integers or text strings indexing the Application Server traffic that the sending ASP is configured/registered to receive, but does not want to receive at this time.
任意のInterface Identifiersパラメタは、送付ASPが受けるために構成されるか、または登録されるApplication Serverトラフィックに索引をつけるInterface Identifier整数かテキスト文字列のリストを含んでいますが、このとき、受信したがっていません。
Morneault, et al. Standards Track [Page 34] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[34ページ]。
3.3.2.8 ASP Inactive Ack
3.3.2.8 ASPの不活発なAck
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote IUA peer.
ASP Inactive(ASPIA)Ackメッセージは、リモートIUA同輩から受け取られたASP Inactiveメッセージを承認するのに使用されます。
The ASPIA Ack message contains the following parameters:
ASPIA Ackメッセージは以下のパラメタを含んでいます:
Traffic Mode Type (Mandatory)
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
トラフィックMode Type(義務的な)インタフェースIdentifiers(任意の)--整数の組み合わせと整数範囲、OR--ストリング(フォーマットされたテキスト)INFO String(任意)です。
Morneault, et al. Standards Track [Page 35] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[35ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 |
| 追加インタフェース識別子| | タグタイプ0×1か0x8について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 36] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[36ページ]。
The format for the ASP Inactive Ack message using text formatted (string) Interface Identifiers is as follows:
テキストを使用するASP Inactive Ackメッセージが(ストリング)インタフェースIdentifiersをフォーマットしたので、形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xb)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トラフィックモードタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
| 追加インタフェース識別子| | タグタイプ0x3について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Traffic Mode Type and Interface Identifier parameters is the same as for the ASP Inactive message (See Section 3.3.2.7).
セクション3.3を見てください。Traffic Mode TypeとInterface Identifierパラメタの形式がASP Inactiveメッセージのように同じである、(.2 .7)。
The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
セクション3.3を見てください。任意のInfo Stringパラメタの形式と記述がASP Upメッセージのように同じである、(.2 .1)。
3.3.2.9 Heartbeat (BEAT)
3.3.2.9 鼓動(ビート)
The Heartbeat message is optionally used to ensure that the IUA peers are still available to each other. It is recommended for use when the IUA runs over a transport layer other than the SCTP, which has its own heartbeat.
Heartbeatメッセージは、互いにおいて、IUA同輩がまだ手があいているのを保証するのに任意に使用されます。 IUAがトランスポート層をひくとき、使用のために、SCTPを除いて、どれにそれ自身の鼓動があるかが勧められます。
The BEAT message contains the following parameters:
BEATメッセージは以下のパラメタを含んでいます:
Heartbeat Data Optional
鼓動データ任意です。
Morneault, et al. Standards Track [Page 37] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[37ページ]。
The format for the BEAT message is as follows:
BEATメッセージのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
| Heartbeat Data * |
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=9| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ | 鼓動データ*| \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node. The Heartbeat Data could include, for example, a Heartbeat Sequence Number and, or Timestamp. The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver MUST respond with a Heartbeat Ack message.
Heartbeat Dataパラメタ内容は送付ノードによって定義されます。 そして、Heartbeat Dataが例えばHeartbeat Sequence Numberを含むことができた、または、Timestamp。 それが送付者への意味だけのものであって、Heartbeatメッセージの受信機はこの分野を処理しません。 受信機はHeartbeat Ackメッセージで応じなければなりません。
3.3.2.10 Heartbeat Ack (BEAT-Ack)
3.3.2.10 鼓動Ack(ビート-Ack)
The Heartbeat Ack message is sent in response to a received Heartbeat message. It includes all the parameters of the received Heartbeat message, without any change.
受信されたHeartbeatメッセージに対応してHeartbeat Ackメッセージを送ります。 それは少しも変化なしで受信されたHeartbeatメッセージのすべてのパラメタを含んでいます。
3.3.3 Layer Management (MGMT) Messages
3.3.3 層の管理(管理)メッセージ
3.3.3.1 Error (ERR)
3.3.3.1 誤り(間違えます)
The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid.
Errorメッセージは、入力メッセージに関連している誤りイベントについて同輩に通知するのに使用されます。 例えば、現状を考えて、メッセージタイプが予期していないかもしれませんか、またはパラメタ値は無効であるかもしれません。
The Error message will only have the common message header. The Error message contains the following parameters:
Errorメッセージには、一般的なメッセージヘッダーがあるだけでしょう。 Errorメッセージは以下のパラメタを含んでいます:
Error Code
Diagnostic Information (optional)
エラーコード診断情報(任意)です。
Morneault, et al. Standards Track [Page 38] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[38ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xc) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x7) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xc)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×7)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diagnostic Information* |
| 診断情報*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error Message. The Error parameter value can be one of the following values:
Error CodeパラメタはError Messageの理由を示します。 Errorパラメタ価値は以下の値の1つであるかもしれません:
Invalid Version 0x01
Invalid Interface Identifier 0x02
Unsupported Message Class 0x03
Unsupported Message Type 0x04
Unsupported Traffic Handling Mode 0x05
Unexpected Message 0x06
Protocol Error 0x07
Unsupported Interface Identifier Type 0x08
Invalid Stream Identifier 0x09
Unassigned TEI 0x0a
Unrecognized SAPI 0x0b
Invalid TEI, SAPI combination 0x0c
無効のバージョン0x01Invalid Interface Identifier0x02Unsupported Message Class0x03Unsupported Message Type0x04Unsupported Traffic Handling Mode0x05Unexpected Message0x06プロトコルError0x07Unsupported Interface Identifier Type0x08Invalid Stream Identifier0×09Unassigned TEI 0x0a Unrecognized SAPI 0x0b Invalid TEI、SAPI組み合わせ0x0c
The "Invalid Version" error would be sent if a message was received with an invalid or unsupported version. The Error message would contain the supported version in the Common header. The Error message could optionally provide the supported version in the Diagnostic Information area.
無効の、または、サポートされないバージョンでメッセージを受け取るなら、「無効のバージョン」誤りを送るでしょうに。 ErrorメッセージはCommonヘッダーにサポートしているバージョンを含んでいるでしょう。 Errorメッセージは任意にDiagnostic情報領域にサポートしているバージョンを提供するかもしれません。
The "Invalid Interface Identifier" error would be sent by a SG if an ASP sends a message with an invalid (unconfigured) Interface Identifier value.
ASPが無効(非構成される)のインタフェースIdentifier価値があるメッセージを送るなら、「無効のインタフェース識別子」誤りはSGによって送られるでしょう。
The "Unsupported Traffic Handling Mode" error would be sent by a SG if an ASP sends an ASP Active with an unsupported Traffic Handling Mode. An example would be a case in which the SG did not support load-sharing.
ASPがサポートされないTraffic Handling ModeのASP Activeを送るなら、「サポートされないトラフィック取り扱いモード」誤りはSGによって送られるでしょう。 例はSGが負荷分割法をサポートしなかった場合でしょう。
The "Unexpected Message" error would be sent by an ASP if it received a QPTM message from an SG while it was in the Inactive state (the ASP could optionally drop the message and not send an Error). It would
それがInactive状態にあった間(ASPは、任意にメッセージを下げて、Errorを送ることができませんでした)、SGからQPTMメッセージを受け取るなら、「予期していなかったメッセージ」誤りはASPによって送られるでしょうに。 それはそうするでしょう。
Morneault, et al. Standards Track [Page 39] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[39ページ]。
also be sent by an ASP if it received a defined and recognized message that the SG is not expected to send (e.g., if the MGC receives an IUA Establish Request message).
また、それがSGが発信しないと予想されるという(例えば、MGCがIUA Establish Requestメッセージを受け取るなら)定義されて認識されたメッセージを受け取ったなら、ASPによって送られてください。
The "Protocol Error" error would be sent for any protocol anomaly (i.e., a bogus message).
どんなプロトコル例外(すなわち、にせのメッセージ)によっても「プロトコル誤り」誤りを送るでしょう。
The "Invalid Stream Identifier" error would be sent if a message was received on an unexpected SCTP stream (i.e., a MGMT message was received on a stream other than "0").
予期していなかったSCTPストリームにメッセージを受け取るなら「無効のストリーム識別子」誤りを送る、(ストリームにすなわち、MGMTメッセージを受け取った、「0インチ)」
The "Unsupported Interface Identifier Type" error would be sent by a SG if an ASP sends a Text formatted Interface Identifier and the SG only supports Integer formatted Interface Identifiers. When the ASP receives this error, it will need to resend its message with an Integer formatted Interface Identifier.
ASPがフォーマットされたInterface IdentifierをTextに送って、サポートだけをSGに送るなら誤りがSGによって送られる「サポートされないインタフェース識別子タイプ」IntegerはInterface Identifiersをフォーマットしました。 ASPがこの誤りを受けるとき、それは、IntegerがフォーマットされているメッセージにInterface Identifierを再送する必要があるでしょう。
The "Unsupported Message Type" error would be sent if a message with an unexpected or unsupported Message Type is received.
予期していなかったかサポートされないMessage Typeがあるメッセージが受信されているなら、「サポートされないメッセージタイプ」誤りを送るでしょう。
The "Unsupported Message Class" error would be sent if a message with an unexpected or unsupported Message Class is received.
予期していなかったかサポートされないMessage Classがあるメッセージが受信されているなら、「サポートされないメッセージのクラス」誤りを送るでしょう。
The "Unassigned TEI" error may be used when the SG receives an IUA message that includes a TEI which has not been assigned or recognized for use on the indicated ISDN D-channel.
「割り当てられなかったTEI」誤りは、SGが割り当てられていないTEIを含んでいるIUAメッセージを受け取るとき、使用されるか、または示されたISDN D-チャンネルにおける使用として認識されるかもしれません。
The "Unrecognized SAPI" error would handle the case of using a SAPI that is not recognized by the SG. The "Invalid TEI, SAPI combination" error identify errors where the TEI is assigned and the the SAPI is recognized, but the combination is not valid for the interface (e.g., on a BRI the MGC tries to send Q.921 Management messages via IUA when Layer Management at the SG SHOULD be performing this function).
「認識されていないSAPI」誤りはSGによって認識されないSAPIを使用するケースを扱うでしょう。 「無効のTEI、SAPI組み合わせ、」 TEIが割り当てられて、SAPIが認識されるところで誤りは誤りを特定しますが、インタフェースには、組み合わせは有効ではありません(この機能を実行することであるSG SHOULDのLayer Managementであるときに、例えば、a BRIでは、MGCはIUAを通してメッセージをQ.921 Managementに送ろうとします)。
The optional Diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. To enhance debugging, the Diagnostic information could contain the first 40 bytes of the offending message.
任意のDiagnostic情報は、エラー条件の識別を助けるためにはエラー条件に適切などんな情報であるかもしれません。 デバッグを機能アップするために、Diagnostic情報は腹立たしいメッセージの最初の40バイトを含むかもしれません。
3.3.3.2 Notify (NTFY)
3.3.3.2 通知してください。(NTFY)
The Notify message used to provide an autonomous indication of IUA events to an IUA peer.
Notifyメッセージは以前はよくIUAイベントの自動しるしをIUA同輩に供給していました。
Morneault, et al. Standards Track [Page 40] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[40ページ]。
The Notify message will only use the common message header. The Notify message contains the following parameters:
Notifyメッセージは一般的なメッセージヘッダーを使用するだけでしょう。 Notifyメッセージは以下のパラメタを含んでいます:
Status Type
Status Identification
Interface Identifiers (Optional)
INFO String (Optional)
状態タイプ状態識別インタフェース識別子(任意の)インフォメーションストリング(任意)です。
Morneault, et al. Standards Track [Page 41] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[41ページ]。
The format for the Notify message with Integer-formatted Interface Identifiers is as follows:
IntegerによってフォーマットされたInterface IdentifiersがあるNotifyメッセージのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xd)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態タイプ| 状態識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x1 or 0x8 |
| 追加インタフェース識別子| | タグタイプ0×1か0x8について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 42] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[42ページ]。
The format for the Notify message with Text-formatted Interface Identifiers is as follows:
TextによってフォーマットされたInterface IdentifiersがあるNotifyメッセージのための形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xd)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態タイプ| 状態識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* |
| インタフェース識別子*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | of Tag Type 0x3 |
| 追加インタフェース識別子| | タグタイプ0x3について|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×4)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
| インフォメーションストリング*|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status Type parameter identifies the type of the Notify message. The following are the valid Status Type values:
Status TypeパラメタはNotifyメッセージのタイプを特定します。 ↓これは有効なStatus Type値です:
Value Description
0x1 Application Server state change (AS_State_Change)
0x2 Other
値の記述0x1Application Server州の変化(_AS_州Change)0×2Other
The Status Identification parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS_State_Change the following Status Identification values are used:
Status IdentificationパラメタはStatus Typeの値に基づいて通知のための、より詳細な情報を含んでいます。 Status TypeがAS_州_Changeであるなら、以下のStatus Identification値は使用されています:
Value Description
1 Application Server Down (AS_Down)
2 Application Server Inactive (AS_Inactive)
3 Application Server Active (AS_Active)
4 Application Server Pending (AS_Pending)
未定の(_下にとしての)2アプリケーション・サーバー不活発な(_不活発であるとしての)3アプリケーション・サーバーアクティブな(_アクティブであるとしての)4アプリケーション・サーバーの下側に記述1つのアプリケーション・サーバーを評価してください。(未定の_としての)
Morneault, et al. Standards Track [Page 43] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[43ページ]。
These notifications are sent from an SG to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server.
特定のApplication Serverの状態の変化でこれらの通知をSGからASPに送ります。値はApplication Serverの新しい州を反映します。
If the Status Type is Other, then the following Status Information values are defined:
Status TypeがOtherであるなら、以下のStatus情報値は定義されます:
Value Description
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
AS2Alternate ASP Activeでアクティブな値の記述1Insufficient ASPリソース
These notifications are not based on the SG reporting the state change of an ASP or AS. In the Insufficient ASP Resources case, the SG is indicating to an "Inactive" ASP(s) in the AS that another ASP is required in order to handle the load of the AS (Load-sharing mode). For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-Active state in Over-ride mode.
これらの通知はASPの州の変化を報告するSGかASに基づいていません。 Insufficient ASP Resources場合では、SGは、ASで別のASPがAS(負荷分割法モード)の荷重を扱うのに必要であることを「不活発な」ASPに示しています。 Alternate ASP Activeケースにおいて、ASPは代替のASPがいつOver-乗りのモードでASP活動的な状態に移行するかを知らされます。
The format and description of the optional Interface Identifiers and Info String parameters is the same as for the ASP Active message (See Section 3.3.2.3.).
任意のInterface IdentifiersとInfo Stringパラメタの形式と記述はASP Activeメッセージのように同じです(.3にセクション3.3.2を見てください)。
3.3.3.3 TEI Status Messages (Request, Confirm and Indication)
3.3.3.3 TEIステータスメッセージそして、(要求、確認、指示)
The TEI Status messages are exchanged between IUA layer peers to request, confirm and indicate the status of a particular TEI.
特定のTEIの状態を要求して、確認して、示すためにIUA層の同輩の間でTEI Statusメッセージを交換します。
The TEI Status messages contain the common message header followed by IUA message header. The TEI Status Request message does not contain any additional parameters.
TEI StatusメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 TEI Status Requestメッセージはどんな追加パラメタも含んでいません。
In the integrated ISDN Layer 2/3 model (e.g., in traditional ISDN switches), it is assumed that the Layer Management for the Q.921 Layer and the Q.931 layer are co-located. When backhauling ISDN, this assumption is not necessarily valid. The TEI status messages allow the two Layer Management entities to communicate the status of the TEI. In addition, knowing that a TEI is in service allows the ASP to request the SG to establish the datalink to the terminal (via the IUA Establish message) for signaling if the ASP wants to be in control of data link establishment. Another use of the TEI status procedure is where the Layer Management at the ASP can prepare for send/receive signaling to/from a given TEI and confirm/verify the establishment of a datalink to that TEI. For example, if a datalink is established for a TEI that the ASP did not know was assigned, the ASP can check to see whether it was assigned or whether there was an error in the signaling message. Also, knowing that a TEI is out of service, the ASP need not request the SG to establish a datalink to that TEI.
統合ISDN Layer2/3モデル(例えば、伝統的なISDNスイッチの)では、Q.921 LayerのためのLayer ManagementとQ.931層が共同見つけられていると思われます。 ISDNをbackhaulingするとき、この仮定は必ず有効であるというわけではありません。 TEIステータスメッセージで、2つのLayer Management実体がTEIの状態を伝えることができます。 さらに、TEIが使用中であることを知っているのに、ASPは、データ・リンク設立のコントロールにASPがありたいなら合図するために端末(IUA Establishメッセージを通した)にデータリンクを確立するようSGに要求できます。 TEI状態手順の使用がASPのLayer Managementが準備できるところにある別のものは、そのTEIにデータリンクの確立を与えられたTEIからの/にシグナリングを送るか、または受けて、確認するか、または確かめます。 例えば、データリンクがTEIのために確立されるなら、ASPが知らなかったのは割り当てられました、とASPがそれが割り当てられたかどうか、またはシグナリングメッセージには誤りがあったかを確認するためにチェックできます。 また、TEIが使われなくなっているのを知っていて、ASPは、そのTEIにデータリンクを確立するようSGに要求する必要はありません。
Morneault, et al. Standards Track [Page 44] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[44ページ]。
The TEI Status Indication, and Confirm messages contain the following parameter:
TEI Status Indication、Confirmメッセージが以下のパラメタを含んでいる、:
STATUS
状態
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x10) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×10)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Status are shown in the following table.
Statusのための有効値は以下のテーブルに示されます。
Define Value Description
ASSIGNED 0x0 TEI is considered assigned by Q.921
UNASSIGNED 0x1 TEI is considered unassigned by Q.921
定義、Value記述ASSIGNED0x0TEIによる割り当てられると考えられて、Q.921によって割り当てられないで、Q.921 UNASSIGNED0x1によって、TEIが考えられるということです。
4.0 Procedures
4.0の手順
The IUA layer needs to respond to various primitives it receives from other layers as well as messages it receives from the peer IUA layer. This section describes various procedures involved in response to these events.
IUA層は、それがそれが同輩IUA層から受け取るメッセージと同様に他の層から受け取る様々な基関数に応じる必要があります。 このセクションはこれらのイベントに対応してかかわる様々な手順について説明します。
4.1 Procedures to support service in section 1.4.1
セクション1.4.1における支援活動への4.1の手順
These procedures achieve the IUA layer's "Transport of Q.921/Q.931 boundary" service.
これらの手順はIUA層の「Q.921/Q.931境界の輸送」サービスを実現します。
4.1.1 Q.921 or Q.931 primitives procedures
4.1.1 Q.921かQ.931基関数手順
On receiving these primitives from the local layer, the IUA layer will send the corresponding QPTM message (Data, Unit Data, Establish, Release) to its peer. While doing so, the IUA layer needs to fill various fields of the common and specific headers correctly. In addition the message needs to be sent on the SCTP stream that corresponds to the D channel (Interface Identifier).
地方の層からこれらの基関数を受け取ると、IUA層は対応するQPTMメッセージ(データ、Unit Data、Establish、Release)を同輩に送るでしょう。 そうしている間、IUA層は、正しく一般的で特定のヘッダーの多岐をいっぱいにする必要があります。 さらに、メッセージは、Dチャネル(インタフェースIdentifier)に対応するSCTPストリームで送られる必要があります。
4.1.2 QPTM message procedures
4.1.2 QPTMメッセージ手順
On receiving QPTM messages from a peer IUA layer, the IUA layer on an SG or MGC needs to invoke the corresponding layer primitives (DL- ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) to the local Q.921 or Q.931 layer.
同輩IUA層からQPTMメッセージを受け取ると、SGかMGCの上のIUA層は、対応する層の基関数(DL- ESTABLISH、DL-DATA、DL-UNIT DATA、DL-RELEASE)を地方のQ.921かQ.931層へ呼び出す必要があります。
Morneault, et al. Standards Track [Page 45] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[45ページ]。
4.2 Procedures to support service in section 1.4.2
セクション1.4.2における支援活動への4.2の手順
These procedures achieve the IUA layer's "Support for Communication between Layer Managements" service.
これらの手順はIUA層の「層の監理のコミュニケーションのサポート」サービスを実現します。
4.2.1 Layer Management primitives procedures
4.2.1 層のManagement基関数手順
On receiving these primitives from the local Layer Management, the IUA layer will provide the appropriate response primitive across the internal local Layer Management interface.
地方のLayer Managementからこれらの基関数を受け取ると、IUA層は内部の地方のLayer Managementインタフェースの向こう側に適切な応答プリミティブを提供するでしょう。
An M-SCTP ESTABLISH request from Layer Management will initiate the establishment of an SCTP association. An M-SCTP ESTABLISH confirm will be sent to Layer Management when the initiated association set- up is complete. An M-SCTP ESTABLISH indication is sent to Layer Management upon successful completion of an incoming SCTP association set-up from a peer IUA node
Layer ManagementからのM-SCTP ESTABLISH要求はSCTP協会の設立を開始するでしょう。 セットされた開始している協会が完全であるときに、Layer Managementに送られるでしょうM-SCTP ESTABLISHが、確認する。 入って来るSCTP協会セットアップの無事終了のときにM-SCTP ESTABLISH指示を同輩IUAノードからLayer Managementに送ります。
An M-SCTP RELEASE request from Layer Management will initiate the tear-down of an SCTP association. An M-SCTP RELEASE confirm will be sent by Layer Management when the association teardown is complete. An M-SCTP RELEASE indication is sent to Layer Management upon successful tear-down of an SCTP association initiated by a peer IUA.
Layer ManagementからのM-SCTP RELEASE要求はSCTP協会の分解を起こすでしょう。 協会分解が完全であるときに、Layer Managementによって送られるでしょうM-SCTP RELEASEが、確認する。 同輩IUAによって開始されたSCTP協会のうまくいっている分解でM-SCTP RELEASE指示をLayer Managementに送ります。
M-SCTP STATUS request and indication support a Layer Management query of the local status of a particular SCTP association.
M-SCTP STATUS要求と指示は特定のSCTP協会のローカルの状態のLayer Management質問をサポートします。
M-NOTIFY indication and M-ERROR indication indicate to Layer Management the notification or error information contained in a received IUA Notify or Error message respectively. These indications can also be generated based on local IUA events.
M-NOTIFY指示とM-ERROR指示は容認されたIUA NotifyかErrorメッセージにそれぞれ含まれた通知かエラー情報をLayer Managementに示します。 また、地方のIUAイベントに基づいてこれらの指摘を生成することができます。
M-ASP STATUS request/indication and M-AS-STATUS request/indication support a Layer Management query of the local status of a particular ASP or AS. No IUA peer protocol is invoked.
M-ASP STATUS要求/指示とM-AS-STATUS要求/指示は特定のASPかASのローカルの状態のLayer Management質問をサポートします。 IUA同輩プロトコルは全く呼び出されません。
M-ASP-UP request, M-ASP-DOWN request, M-ASP-INACTIVE request and M- ASP-ACTIVE request allow Layer Management at an ASP to initiate state changes. These requests result in outgoing IUA ASP UP, ASP DOWN, ASP INACTIVE and ASP ACTIVE messages.
M ASP UP要求、M ASP DOWN要求、M ASP INACTIVE要求、およびM ASP-ACTIVEは、ASPのLayer Managementに州の変化を起こさせるよう要求します。 これらの要求は出発しているIUA ASP UP、ASP DOWN、ASP INACTIVE、およびASP ACTIVEメッセージをもたらします。
M-ASP-UP confirmation, M-ASP-DOWN confirmation, M-ASP-INACTIVE confirmation and M-ASP-ACTIVE confirmation indicate to Layer Management that the previous request has been confirmed.
M ASP UP確認、M ASP DOWN確認、M ASP INACTIVE確認、およびM ASP ACTIVE確認は、前の要求が確認されたのをLayer Managementに示します。
Morneault, et al. Standards Track [Page 46] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[46ページ]。
Upon receipt of a M-TEI Status primitive from Layer Management, the IUA will send the corresponding MGMT message (TEI Status) to its peer. While doing so, the IUA layer needs to fill various fields of the common and specific headers correctly.
Layer Managementからの原始のM-TEI Statusを受け取り次第、IUAは対応するMGMTメッセージ(TEI Status)を同輩に送るでしょう。 そうしている間、IUA層は、正しく一般的で特定のヘッダーの多岐をいっぱいにする必要があります。
All MGMT messages are sent on a sequenced stream to ensure ordering. SCTP stream '0' SHOULD be used.
注文するのを保証するために配列されたストリームですべてのMGMTメッセージを送ります。 SCTPは'0'SHOULDを流します。使用されます。
4.2.2 Receipt of IUA Peer Management messages
4.2.2 IUA Peer Managementメッセージの領収書
Upon receipt of IUA Management messages, the IUA layer MUST invoke the corresponding Layer Management primitive indications (e.g., M-AS Status ind., M-ASP Status ind., M-ERROR ind., M-TEI STATUS...) to the local layer management.
IUA Managementを受け取り次第、メッセージ、IUA層は対応するLayer Management原始の指摘を呼び出さなければなりません。(例えば、M-AS Status ind、M ASP Status ind、M-ERROR ind、M-TEI STATUS) ローカルの層の管理に。
M-NOTIFY indication and M-ERROR indication indicate to Layer Management the notification or error information contained in a received IUA Notify or Error message. These indications can also be generated based on local IUA events.
M-NOTIFY指示とM-ERROR指示は容認されたIUA NotifyかErrorメッセージに含まれた通知かエラー情報をLayer Managementに示します。 また、地方のIUAイベントに基づいてこれらの指摘を生成することができます。
All MGMT messages are sent on a sequenced stream to ensure ordering. SCTP stream '0' SHOULD be used.
注文するのを保証するために配列されたストリームですべてのMGMTメッセージを送ります。 SCTPは'0'SHOULDを流します。使用されます。
4.3 Procedures to support service in section 1.4.3
セクション1.4.3における支援活動への4.3の手順
These procedures achieve the IUA layer's "Support for management of active associations between SG and MGC" service.
これらの手順はIUA層の「SGとMGCとの活動的な協会の経営のサポート」サービスを実現します。
4.3.1 AS and ASP State Maintenance
4.3.1、同じくらいそして、ASPはメインテナンスを述べます。
The IUA layer on the SG needs to maintain the states of each ASP as well as the state of the AS.
SGの上のIUA層は、ASの州と同様にそれぞれのASPの州を維持する必要があります。
4.3.1.1 ASP States
4.3.1.1 ASP州
The state of the each ASP, in each AS that it is configured, is maintained in the IUA layer on the SG. The state of an ASP changes due to the following type of events:
状態、各ASP、各ASでは、構成されていて、IUAがSGで層にする維持されたコネはそうです。 ASPの状態は以下のタイプのイベントのため変化します:
* Reception of messages from peer IUA layer at that ASP
* Reception of some messages from the peer IUA layer at other
ASPs in the AS
* Reception of indications from SCTP layer
* SCTP層からの指摘のAS*レセプションにおける他のASPにおける同輩IUA層からのいくつかのメッセージのそのASP*レセプションにおける同輩IUA層からのメッセージのレセプション
The ASP state transition diagram is shown in Figure 7. The possible states of an ASP are the following:
ASP状態遷移ダイヤグラムは図7で見せられます。 ASPの可能な州は以下です:
Morneault, et al. Standards Track [Page 47] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[47ページ]。
ASP-DOWN: Application Server Process is unavailable and/or the related SCTP association is down. Initially, all ASPs will be in this state. An ASP in this state SHOULD NOT be sent any IUA messages.
ASP下である: アプリケーションServer Processは入手できません、そして、関連するSCTP協会は下がっています。 初めは、すべてのASPがこの状態にあるでしょう。 これのASPは、どんなIUAメッセージもSHOULD NOTに送られると述べます。
ASP-INACTIVE: The remote IUA peer at the ASP is available (and the related SCTP association is up) but application traffic is stopped. In this state the ASP can be sent any non-QPTM IUA messages (except for TEI Status messages).
ASP不活発: ASPのリモートIUA同輩は手があいていますが(関連するSCTP協会は上がっています)、アプリケーション通行は止められます。 この状態では、どんな非QPTM IUAメッセージ(TEI Statusメッセージを除いた)もASPに送ることができます。
ASP-ACTIVE: The remote IUA peer at the ASP is available and application traffic is active.
ASPアクティブ: ASPのリモートIUA同輩は手があいています、そして、アプリケーション交通は活発です。
Figure 7 ASP State Transition Diagram
図7 ASP状態遷移ダイヤグラム
+-------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +-------------+
| Takeover | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +-------------+
| | | |
| +------>| ASP-INACT |
| +-------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI
| | v
| +-------------+
+--------------------->| |
| ASP-DOWN |
+-------------+
+-------------+ +----------------------| | | 補欠+-------| ASPアクティブです。| | ASP| +-------------+ | 接収| ^ | | | ASP| | ASP| | アクティブ| | 不活発| | | v| | +-------------+ | | | | | +------>| ASP-INACT| | +-------------+ | ^ | /へのASP| ASP| | ASP下に/SCTP CDI| 上がる| | SCTP CDI| | v| +-------------+ +--------------------->|、|、| 下にASP| +-------------+
SCTP CDI: The local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG. The local SCTP will send this indication when it detects the loss of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP.
SCTP CDI: SGの上のUpper Layerプロトコル(IUA)への地方のSCTP層のCommunication Down Indication。 それがASPの同輩SCTP層に接続性の損失を検出するとき、地方のSCTPはこの指示を送るでしょう。 SCTP CDIはSCTPからのSHUTDOWN COMPLETE通知とCOMMUNICATION LOST通知として理解されています。
4.3.1.2 AS States
4.3.1.2 州として
The state of the AS is maintained in the IUA layer on the SG.
ASの州はSGでIUA層の中で維持されます。
The state of an AS changes due to events. These events include the following:
ASの州は出来事のため変化します。 これらの出来事は以下を含んでいます:
Morneault, et al. Standards Track [Page 48] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[48ページ]。
* ASP state transitions
* Recovery timer triggers
* ASP状態遷移*回復タイマ引き金
The possible states of an AS are the following:
ASの可能な州は以下です:
AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state.
下にとして: Application Serverは入手できません。 この州は、すべての関連するASPがこのASのためのASP-DOWN状態にあるのを含意します。 初めは、ASがこの状態にあるでしょう。
AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP- INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired.
-、不活発である、: Application Serverは利用可能ですが、どんなアプリケーション交通も活発ではありません(すなわち、1つ以上の関連するASPがしかし、ASP INACTIVE状態、ASP-ACTIVE状態のなにもにあります)。 回復タイマT(r)は走っていないか、または期限が切れました。
AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state.
能動態として: Application Serverは利用可能です、そして、アプリケーション交通は活発です。 この州は、少なくとも1つのASPがASP-ACTIVE状態にあるのを含意します。
AS-PENDING: An active ASP has transitioned from active to inactive or down and it was the last remaining active ASP in the AS. A recovery timer T(r) will be started and all incoming SCN messages will be queued by the SG. If an ASP becomes active before T(r) expires, the AS will move to AS-ACTIVE state and all the queued messages will be sent to the active ASP.
-、未定である、: 活動的なASPはアクティブであるのから不活発であるか下がっているのに移行しました、そして、それはASの最後の残っている活動的なASPでした。 T(r)が始められて入って来るSCNがメッセージであったならそうする回復タイマはSGによって列に並ばせられるでしょう。 T(r)が期限が切れる前にASPがアクティブになると、ASはAS-ACTIVE状態に動くでしょう、そして、すべての列に並ばせられたメッセージを活動的なASPに送るでしょう。
If T(r) expires before an ASP becomes active, the SG stops queuing messages and discards all previously queued messages. The AS will move to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state.
ASPがアクティブになる前にT(r)が期限が切れるなら、SGはメッセージを列に並ばせるのを止めて、すべての以前に列に並ばせられたメッセージを捨てます。 少なくとも1つのASPがASP-INACTIVE状態にあるなら、ASはAS-INACTIVEに動くでしょう。さもなければ、それはAS-DOWN状態に動くでしょう。
Morneault, et al. Standards Track [Page 49] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[49ページ]。
Figure 8 AS State Transition Diagram
状態遷移ダイヤグラムとしてのエイト環
+----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| |
| AS-INACT | | AS-ACTIVE |
| | | |
| |< | |
+----------+ \ +-------------+
^ | \ Tr Trigger ^ |
| | \ at least one | |
| | \ ASP in UP | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | \ one ASP | | Last ACTIVE ASP
trans | | all ASP \------\ trans to | | trans to INACT
to | | trans to \ ACTIVE | | or DOWN
INACT | | DOWN \ | | (start Tr timer)
| | \ | |
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | -| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<------------------------| |
+----------+ Tr Expiry and no +-------------+
ASP in INACTIVE state
+----------+ 1つのASP移-ACTIVE+-------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| INACT| | 能動態| | | | | | | <|、| +----------+ \ +-------------+ ^ | \Tr引き金の^| | | \、少なくとも1| | | | 上の\ASP| | | | \ | | | | \ | | | | \ | | 1つのASP| | \はあるASPです。| | 最後のACTIVE ASP、移-| | すべてのASP、\------\、移-| | 移-、INACT| | 移-、\ACTIVE| | または、INACTの下側に| | \の下側に| | (スタートTrタイマ) | | \ | | | | \ | | | | \ | | | \に対して| +に対して----------+ \ +-------------+ | | -| | | 下に| | -、未定| | | | (待ち行列) | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +----------+ Tr Expiryにもかかわらず、+がありません。-------------+ INACTIVE州のASP
Tr = Recovery Timer
Trは回復タイマと等しいです。
4.3.2 ASPM procedures for primitives
4.3.2 基関数のためのASPM手順
Before the establishment of an SCTP association the ASP state at both the SG and ASP is assumed to be "Down".
SCTP協会の設立の前に、SGとASPの両方のASP状態は“Down"であると思われます。
As the ASP is responsible for initiating the setup of an SCTP association to an SG, the IUA layer at an ASP receives an M-SCTP ESTABLISH request primitive from the Layer Management, the IUA layer will try to establish an SCTP association with the remote IUA peer at an SG. Upon reception of an eventual SCTP-Communication Up confirm primitive from the SCTP, the IUA layer will invoke the primitive M- SCTP ESTABLISH confirm to the Layer Management.
ASPはSCTP協会のセットアップにSGに着手するのに責任があるとき、ASPにおけるIUA層がLayer Managementからの原始のM-SCTP ESTABLISH要求を受け取って、IUA層はSGのリモートIUA同輩とのSCTP仲間を設立しようとするでしょう。 SCTPからの最後のSCTP-コミュニケーションUp確認プリミティブのレセプションでは、IUA層はSCTP ESTABLISHがLayer Managementに確認する原始のMを呼び出すでしょう。
At the SG, the IUA layer will receive an SCTP Communication Up indication primitive from the SCTP. The IUA layer will then invoke the primitive M-SCTP ESTABLISH indication to the Layer Management.
SGでは、IUA層はSCTPからSCTP Communication Up指示プリミティブを受け取るでしょう。 そして、IUA層は原始のM-SCTP ESTABLISH指示をLayer Managementへ呼び出すでしょう。
Morneault, et al. Standards Track [Page 50] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[50ページ]。
Once the SCTP association is established and assuming that the local IUA-User is ready, the local ASP IUA Application Server Process Maintenance (ASPM) function will initiate the ASPM procedures, using the ASP Up/-Down/-Active/-Inactive messages to convey the ASP state to the SG - see Section 4.3.3.
SCTP協会が、地元のIUA-ユーザが準備ができていると一度確証されて、仮定していると、地方のASP IUA Application Server Process Maintenance(ASPM)機能はASPM手順に着手するでしょう、ASP状態をSGまで運ぶ下がるかアクティブであるかASP Up/不活発なメッセージを使用して--セクション4.3.3を見てください。
The Layer Management and the IUA layer on SG can communicate the status of the application server using the M-AS STATUS primitives. The Layer Management and the IUA layer on both the SG and ASP can communicate the status of an SCTP association using the M-SCTP STATUS primitives.
SGの上のLayer ManagementとIUA層は、M-AS STATUS基関数を使用することでアプリケーション・サーバーの状態を伝えることができます。 SGとASPの両方のLayer ManagementとIUA層は、M-SCTP STATUS基関数を使用することでSCTP協会の状態を伝えることができます。
If the Layer Management on SG or ASP wants to bring down an SCTP association for management reasons, they would send M-SCTP RELEASE request primitive to the local IUA layer. The IUA layer would release the SCTP association and upon receiving the SCTP Communication Down indication from the underlying SCTP layer, it would inform the local Layer Management using M-SCTP RELEASE confirm primitive.
SGかASPのLayer Managementが管理理由でSCTP協会を破滅させたいなら、それらはM-SCTP RELEASE要求プリミティブを地方のIUA層に送るでしょう。 IUA層はSCTP協会をリリースするでしょう、そして、基本的なSCTP層からSCTP Communication Down指示を受けるとき、それはM-SCTP RELEASE確認プリミティブを使用することで地方のLayer Managementに知らせるでしょう。
If the IUA layer receives an SCTP-Communication Down indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP RELEASE indication primitive. The state of the ASP will be moved to "Down" at both the SG and ASP.
IUA層が基本的なSCTP層からSCTP-コミュニケーションDown指示を受けると、それは、M-SCTP RELEASE指示プリミティブを呼び出すことによって、Layer Managementに知らせるでしょう。 ASPの状態はSGとASPの両方の“Down"に動かされるでしょう。
At an ASP, the Layer Management MAY try to reestablish the SCTP association using M-SCTP ESTABLISH request primitive.
ASPでは、Layer Managementは、M-SCTP ESTABLISH要求プリミティブを使用することでSCTP協会を復職させようとするかもしれません。
4.3.3 ASPM procedures for peer-to-peer messages
4.3.3 ピアツーピアメッセージのためのASPM手順
All ASPM messages are sent on a sequenced stream to ensure ordering. SCTP stream '0' SHOULD be used.
注文するのを保証するためにすべてのASPMメッセージを配列された流れに送ります。 SCTPは'0'SHOULDを流します。使用されます。
4.3.3.1 ASP Up
4.3.3.1 ASP上
After an ASP has successfully established an SCTP association to an SG, the SG waits for the ASP to send an ASP Up message, indicating that the ASP IUA peer is available. The ASP is always the initiator of the ASP Up exchange.
ASPが首尾よくSCTP協会をSGに設立した後に、SGは、ASPがASP Upメッセージを送るのを待っています、ASP IUA同輩が手があいているのを示して。 いつもASPはASP Up交換の創始者です。
When an ASP Up message is received at an SG and internally the remote ASP is not considered locked-out for local management reasons, the SG marks the remote ASP as "Inactive". The SG responds with an ASP Up Ack message in acknowledgement. The SG sends an ASP-Up Ack message in response to a received ASP Up message even if the ASP is already marked as "Inactive" at the SG.
SGにASP Upメッセージを受け取って、現地管理職者のために締め出している理由であると内面的にリモートASPを考えないとき、SGは「不活発である」としてリモートASPをマークします。 SGは承認におけるASP Up Ackメッセージで応じます。 ASPがSGで「不活発である」として既にマークされても、SGは受信されたASP Upメッセージに対応してASP上がっているAckメッセージを送ります。
Morneault, et al. Standards Track [Page 51] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[51ページ]。
If for any local reason the SG cannot respond with an ASP Up, the SG responds to a ASP Up with a with an ASP-Down Ack message with Reason "Management Blocking".
SGがどんなローカルの理由でもASP Upと共に応じることができないなら、SGはReason「管理ブロッキング」がある下にASP AckメッセージがあるaでASP Upに応じます。
At the ASP, the ASP Up Ack message received from the SG is not acknowledged by the ASP. If the ASP does not receive a response from the SG, or an ASP Down Ack is received, the ASP MAY resend ASP Up messages every 2 seconds until it receives a ASP Up Ack message from the SG. The ASP MAY decide to reduce the frequency (say to every 5 seconds) if an ASP Up Ack is not received after a few tries.
ASPでは、SGから受け取られたASP Up AckメッセージはASPによって承認されません。 ASPがSGから応答を受けないか、またはASP Down Ackが受け取られているなら、それがSGからASP Up Ackメッセージを受け取るまで、ASPは2秒毎にASP Upにメッセージを再送するかもしれません。 ASP Up Ackがいくつかのトライの後に受け取られないなら、ASPは、頻度(5秒毎まで言う)を減少させると決めるかもしれません。
The ASP MUST wait for the ASP Up Ack message from the SG before sending any ASP traffic control messages (ASPAC or ASPIA) or Data messages or it will risk message loss. If the SG receives QPTM, ASP Active or ASP Inactive messages before an ASP Up is received, the SG SHOULD discard these messages.
メッセージの損失の危険を冒す前にASPはSGからのASP Up Ackメッセージを待たなければなりません。 ASP Upが受け取られている前にSGがQPTM、ASP ActiveまたはASP Inactiveメッセージを受け取るなら、SG SHOULDはこれらのメッセージを捨てます。
4.3.3.2 ASP Down
4.3.3.2 ASP下
The ASP will send an ASP Down to an SG when the ASP is to be removed from the list of ASPs in all Application Servers that it is a member and no longer receive any IUA traffic or management messages.
ASPは、ASPがすべてのApplication ServersでASPのリストから免職されることになっているSGのASP Downにメンバーを送って、もうどんなIUA交通や管理メッセージも受け取らないでしょう。
Whether the ASP is permanently removed from an AS is a function of configuration management.
永久にASからASPを免職するかどうかが、構成管理の機能です。
The SG marks the ASP as "Down" and returns an ASP Down Ack message to the ASP if one of the following events occur:
以下の出来事の1つが起こるなら、SGは“Down"としてASPをマークして、ASP Down AckメッセージをASPに返します:
- to acknowledge an ASP Down message from an ASP,
- to reply to ASPM messages from an ASP which is locked out for
management reasons.
- ASPからの回答へのASP DownメッセージをASPからのASPMメッセージに承認するために、どれが管理のために締め出されるかは推論します。
The SG sends an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as "Down" at the SG.
ASPが“Down"として既にSGにマークされても、SGはASPからの受信されたASP Downメッセージに対応してASP Down Ackメッセージを送ります。
If the ASP does not receive a response from the SG, the ASP MAY send ASP Down messages every 2 seconds until it receives an ASP Down Ack message from the SG or the SCTP association goes down. The ASP MAY decide to reduce the frequency (say to every 5 seconds) if an ASP Down Ack is not received after a few tries.
ASPがSGから応答を受けないなら、それがSGからASP Down Ackメッセージを受け取るまで、ASPが2秒毎にASP Downにメッセージを送るかもしれませんか、またはSCTP協会は落ちます。 ASP Down Ackがいくつかのトライの後に受け取られないなら、ASPは、頻度(5秒毎まで言う)を減少させると決めるかもしれません。
4.3.3.3 IUA Version Control
4.3.3.3 IUAバージョンコントロール
If a ASP Up message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports and notifies Layer Management.
サポートされないバージョンがあるASP Upメッセージが受信されているなら、犠牲者は、受信ノードが支えるバージョンを示して、Errorメッセージで応じて、Layer Managementに通知します。
Morneault, et al. Standards Track [Page 52] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[52ページ]。
This is useful when protocol version upgrades are being performed in a network. A node upgraded to a newer version SHOULD support the older versions used on other nodes it is communicating with. Because ASPs initiate the ASP Up procedure it is assumed that the Error message would normally come from the SG.
プロトコルバージョンアップグレードがネットワークで実行されているとき、これは役に立ちます。 ノードはそれがコミュニケートしている他のノードの上で使用される旧式のバージョンをより新しいバージョンSHOULDサポートにアップグレードさせました。 ASPがASP Up手順に着手するので、通常、ErrorメッセージがSGから来ると思われます。
4.3.3.4 ASP Active
4.3.3.4 ASPアクティブです。
Any time after the ASP has received a ASP Up Ack from the SG, the ASP sends an ASP-Active (ASPAC) to the SG indicating that the ASP is ready to start processing traffic. In the case where an ASP is configured/registered to process the traffic for more than one Application Server across an SCTP association, the ASPAC contains one or more Interface Identifiers to indicate for which Application Servers the ASPAC applies.
ASPがSGからASP Up Ackを受けた後にいつでも、ASPはASP ASPが始める準備ができているのを示すSGに活発な(ASPAC)処理交通を送ります。 ASPが1Application ServerのためにSCTP協会の向こう側に交通を処理するために構成されるか、または登録される場合では、ASPACは、ASPACがどのApplication Serversに関して適用するかを示すために1Interface Identifiersを含んでいます。
When an ASP Active (ASPAC) message is received, the SG responds to the ASP with a ASPAC Ack message acknowledging that the ASPAC was received and starts sending traffic for the associated Application Server(s) to that ASP.
ASP Active(ASPAC)メッセージが受信されているとき、SGはASPACが受け取られたと認めながらASPAC AckメッセージでASPにこたえて、関連Application Server(s)のためにそのASPに交通を送り始めます。
The ASP MUST wait for the ASP-Active Ack message from the SG before sending any Data messages or it will risk message loss. If the SG receives QPTM messages before an ASP Active is received, the SG SHOULD discard these messages.
どんなDataメッセージかそれも送るとメッセージの損失が危険を冒される前にASPはSGからのASPアクティブなAckメッセージを待たなければなりません。 ASP Activeが受け取られている前にSGがQPTMメッセージを受け取るなら、SG SHOULDはこれらのメッセージを捨てます。
There are two modes of Application Server traffic handling in the SG IUA - Over-ride and Load-sharing. The Type parameter in the ASPAC message indicates the mode used in a particular Application Server. If the SG determines that the mode indicates in an ASPAC is incompatible with the traffic handling mode currently used in the AS, the SG responds with an Error message indicating Unsupported Traffic Handling Mode.
Application Server交通取り扱いの2つの方法がSG IUAにあります--オーバーライドとLoad-共有。 ASPACメッセージのTypeパラメタは特定のApplication Serverで使用されるモードを示します。SGが、モードが、中にASPACが現在ASで使用される交通取り扱いモードと非互換であることを示すことを決定するなら、ErrorメッセージがUnsupported Traffic Handling Modeを示していて、SGは応じます。
In the case of an Over-ride mode AS, reception of an ASPAC message at an SG causes the redirection of all traffic for the AS to the ASP that sent the ASPAC. The SG responds to the ASPAC with an ASP-Active Ack message to the ASP. Any previously active ASP in the AS is now considered Inactive and will no longer receive traffic from the SG within the AS. The SG sends a Notify (Alternate ASP-Active) to the previously active ASP in the AS, after stopping all traffic to that ASP.
Over-乗りのモードASの場合では、SGのASPACメッセージのレセプションはASのためにASPACを送ったASPにすべての交通のリダイレクションを引き起こします。 SGはASPへのASPアクティブなAckメッセージでASPACに応じます。 ASのどんな以前に活動的なASPも、現在、Inactiveであると考えられて、もうASの中のSGからの交通を受けないでしょう。 SGはNotify(ASPアクティブな状態で、交替する)をASの以前に活動的なASPに送ります、そのASPへのすべての通行を止めた後に。
In the case of a load-share mode AS, reception of an ASPAC message at an SG causes the direction of traffic to the ASP sending the ASPAC, in addition to all the other ASPs that are currently active in the AS. The algorithm at the SG for load-sharing traffic within an AS to all the active ASPs is implementation dependent. The algorithm
負荷シェアモードASの場合では、SGのASPACメッセージのレセプションはASPACを送るASPに交通の指示を引き起こします、他のすべての現在ASで活動的なASPに加えて。 すべての活動的なASPへのASの中の負荷分割法交通へのSGのアルゴリズムは実現に依存しています。 アルゴリズム
Morneault, et al. Standards Track [Page 53] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[53ページ]。
could, for example be round-robin or based on information in the Data message, such as Interface Identifier, depending on the requirements of the application and the call state handling assumptions of the collection of ASPs in the AS. The SG responds to the ASPAC with a ASP-Active Ack message to the ASP.
例えば、丸いコマドリである、またはDataメッセージのInterface Identifierなどの情報に基づいて、ASのアプリケーションの要件とASPの収集の呼び出し状態取り扱い前提によって、そうすることができました。 SGはASPへのASPアクティブなAckメッセージでASPACに応じます。
4.3.3.5 ASP Inactive
4.3.3.5 ASP不活発です。
When an ASP wishes to withdraw from receiving traffic within an AS, the ASP sends an ASP Inactive (ASPIA) to the SG. In the case where an ASP is configured/registered to process the traffic for more than one Application Server across an SCTP association, the ASPIA contains one or more Interface Identifiers to indicate for which Application Servers the ASPIA applies.
ASPがASの中で交通を受けるのから引き下がりたがっているとき、ASPはASP Inactive(ASPIA)をSGに送ります。 ASPが1Application ServerのためにSCTP協会の向こう側に交通を処理するために構成されるか、または登録される場合では、ASPIAは、ASPIAがどのApplication Serversに関して適用するかを示すために1Interface Identifiersを含んでいます。
There are two modes of Application Server traffic handling in the SG IUA when withdrawing an ASP from service - Over-ride and Load- sharing. The Type parameter in the ASPIA message indicates the mode used in a particular Application Server. If the SG determines that the mode indicates in an ASPAC is incompatible with the traffic handling mode currently used in the AS, the SG responds with an Error message indicating Unsupported Traffic Handling Mode.
サービスからASPを撤退するとき、Application Server交通取り扱いの2つの方法がSG IUAにあります--オーバーライドとLoad共有。 ASPIAメッセージのTypeパラメタは特定のApplication Serverで使用されるモードを示します。SGが、モードが、中にASPACが現在ASで使用される交通取り扱いモードと非互換であることを示すことを決定するなら、ErrorメッセージがUnsupported Traffic Handling Modeを示していて、SGは応じます。
In the case of an Over-ride mode AS, where normally another ASP has already taken over the traffic within the AS with an Over-ride ASPAC, the ASP which sends the ASPIA is already considered by the SG to be "Inactive". An ASPIA Ack message is sent to the ASP, after ensuring that all traffic is stopped to the ASP.
Over-乗りのモードASの場合では、SGによって既にASPIAを送るASPが「不活発である」と考えられます。(通常、そこでは、別のASPがOver-乗りのASPACと共にASの中で交通を既に引き継ぎました)。 すべての通行がASPに止められるのを確実にした後に、ASPIA AckメッセージをASPに送ります。
In the case of a Load-share mode AS, the SG moves the ASP to the "Inactive" state and the AS traffic is re-allocated across the remaining "active" ASPs per the load-sharing algorithm currently used within the AS. An ASPIA Ack message is sent to the ASP after all traffic is halted to the ASP. A NTFY (Insufficient ASPs) MAY be sent to all inactive ASPs, if required.
Load-シェアモードASの場合では、SGはASPを「不活発な」状態に動かします、そして、AS交通は現在ASの中で使用されている負荷分割法アルゴリズムあたりの残っている「アクティブな」ASPの向こう側に再割当てされます。 すべての交通をASPに止めた後にASPIA AckメッセージをASPに送ります。 必要なら、NTFY(不十分なASP)をすべての不活発なASPに送るかもしれません。
If no other ASPs are Active in the Application Server, the SG sends a NTFY (AS-Pending) to all inactive ASPs of the AS and either discards all incoming messages for the AS or starts buffering the incoming messages for T(r)seconds, after which messages will be discarded. T(r) is configurable by the network operator. If the SG receives an ASPAC from an ASP in the AS before expiry of T(r), the buffered traffic is directed to the ASP and the timer is cancelled. If T(r) expires, the AS is moved to the "Inactive" state.
他のどんなASPもApplication ServerのActiveでないなら、SGはT(r)秒の間、NTFY(未定のAS)をASのすべての不活発なASPに送って、ASのためのすべての入力メッセージを捨て始めるか、または入力メッセージをバッファリングし始めます。(その時、メッセージは捨てられたでしょう後)。 T(r)はネットワーク・オペレータが構成可能です。 SGがT(r)の満期の前にASのASPからASPACを受けるなら、バッファリングされた交通はASPに向けられます、そして、タイマは取り消されます。 T(r)が期限が切れるなら、ASは「不活発な」状態に動かされます。
Morneault, et al. Standards Track [Page 54] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[54ページ]。
4.3.3.6 Notify
4.3.3.6 通知してください。
A Notify message reflecting a change in the AS state is sent to all ASPs in the AS, except those in the "Down" state, with appropriate Status Identification.
AS状態の変化を反映するNotifyメッセージをASのすべてのASPに送ります、“Down"状態のそれらを除いて、適切なStatus Identificationと共に。
In the case where a Notify (AS-Pending) message is sent by an SG that now has no ASPs active to service the traffic, or a NTFY (Insufficient ASPs) is sent in the Load-share mode, the Notify does not explicitly force the ASP(s) receiving the message to become active. The ASPs remain in control of what (and when) action is taken.
Notify(未定のAS)メッセージが現在ASPを全く交通を修理するためにアクティブにしないSGによって送られるか、またはNTFY(不十分なASP)がLoad-シェアモードで送られる場合では、Notifyは、アクティブになるメッセージを受け取りながら、明らかにASPを強制しません。 ASPはどんな(そして、いつ)行動を取るかに関するコントロールに残っています。
4.3.3.7 Heartbeat
4.3.3.7 鼓動
The optional Heartbeat procedures MAY be used when operating over transport layers that do not have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than the SCTP).
輸送協会(すなわち、SCTPを除いた)の損失を検出するためのそれら自身の鼓動メカニズムを持っていないトランスポート層の上で作動するとき、任意のHeartbeat手順は用いられるかもしれません。
After receiving an ASP Up Ack message from the SG in response to an ASP Up message, the ASP MAY optionally send Beat messages periodically, subject to a provisionable timer T(beat). The SG IUA, upon receiving a BEAT message from the ASP, responds with a BEAT ACK message. If no BEAT message (or any other IUA message) is received from the SG within the timer 2*T(beat), the SG will consider the remote IUA as "Down". The SG will also send an ASP Down Ack message to the ASP.
ASP Upメッセージに対応してSGからASP Up Ackメッセージを受け取った後に、ASPは定期的に任意に支給可能タイマTを条件としてメッセージをBeatに送るかもしれません(打ってください)。 ASPからBEATメッセージを受け取るとき、SG IUAはBEAT ACKメッセージで応じます。 タイマ2*Tの中のSGからBEATメッセージ(または、いかなる他のIUAメッセージも)を全く受け取らないと(打ってください)、SGは、リモートIUAが“Down"であるとみなすでしょう。 また、SGはASP Down AckメッセージをASPに送るでしょう。
At the ASP, if no BEAT ACK message (or any other IUA message) is received from the SG within 2*T(beat), the SG is considered unavailable. Transmission of BEAT messages is stopped and ASP Up procedures are used to re-establish communication with the SG IUA peer.
ASPでは、2*Tの中のSGからBEAT ACKメッセージ(または、いかなる他のIUAメッセージも)を全く受け取らないなら(打ってください)、入手できないとSGを考えます。 BEATメッセージの伝達は止められます、そして、ASP Up手順は、SG IUA同輩とのコミュニケーションを復職させるのに用いられます。
The BEAT message MAY optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Beat Ack message. The ASP upon examining the contents of the returned BEAT Ack message MAY choose to consider the remote ASP as unavailable. The contents/format of the Heartbeat Data parameter is implementation-dependent and only of local interest to the original sender. The contents MAY be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays).
BEATメッセージは任意に関連するBeat Ackメッセージで変わりがない状態でecho backでなければならない不明瞭なHeartbeat Dataパラメタを含むかもしれません。 中身を調べるときの返されたBEAT AckメッセージのASPは、リモートASPが入手できないとみなすのを選ぶかもしれません。 実現依存していて、元の送り主への地方の関心だけについてHeartbeat Dataパラメタのコンテンツ/形式。 例えば、コンテンツは、Heartbeat系列アルゴリズム(なくなったHeartbeatsを検出する)、そして/または、タイムスタンプメカニズム(遅れを評価する)をサポートするのに使用されるかもしれません。
Note: Heartbeat related events are not shown in Figure 4 "ASP state transition diagram".
以下に注意してください。 鼓動関連する出来事は「ASP状態遷移ダイヤグラム」という図4に示されません。
Morneault, et al. Standards Track [Page 55] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[55ページ]。
5.0 Examples
5.0 例
5.1 Establishment of Association and Traffic between SGs and ASPs
5.1 SGsとASPの間の協会と交通の確立
5.1.1 Single ASP in an Application Server (1+0 sparing)
5.1.1 アプリケーション・サーバーのただ一つのASP(1+0割くこと)
This scenario shows the example IUA message flows for the establishment of traffic between an SG and an ASP, where only one ASP is configured within an AS (no backup). It is assumed that the SCTP association is already set-up.
このシナリオは、例のIUAメッセージが1つのASPだけがAS(バックアップがない)の中で構成されるSGとASPの間の交通の確立のために流れるのを示します。 SCTP協会が既にセットアップであると思われます。
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
SG ASP1| | <、-、-、-、-、-、-、-、--ASPは上昇します。----------| |--------AckへのASP------->|、|、| | <、-、-、-、-、-、--ASPアクティブです。--------| |------ASPのアクティブなAck----->|、|、|
5.1.2 Two ASPs in Application Server (1+1 sparing)
5.1.2 アプリケーション・サーバーの2つのASP(1+1割くこと)
This scenario shows the example IUA message flows for the establishment of traffic between an SG and two ASPs in the same Application Server, where ASP1 is configured to be Active and ASP2 a standby in the event of communication failure or the withdrawal from service of ASP1. ASP2 MAY act as a hot, warm, or cold standby depending on the extent to which ASP1 and ASP2 share call state or can communicate call state under failure/withdrawal events. The example message flow is the same whether the ASP-Active messages are Over-ride or Load-share mode although typically this example would use an Over-ride mode.
このシナリオは、通信障害か退出の場合、ASP1のサービスからASP1がActiveになるように構成される同じApplication ServerのSGと2つのASPの間の交通の確立のためのIUAメッセージ流れを例に示して、予備をASP2に示しています。 ASP2 MAYはaとして熱く機能します、暖かいか、またはASP1とASP2シェアが呼ぶ範囲に依存するコールドスタンバイは、失敗/退出出来事の下の呼び出し状態を述べるか、伝えることができます。 例のメッセージ流動はこの例がOver-乗りのモードを通常使用するでしょうが、ASPアクティブなメッセージがOver-乗りかLoad-シェアモードであるか否かに関係なく、同じです。
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
SG ASP1 ASP2| | | | <、-、-、-、-、-、-、--ASPは上昇します。----------| | |-------AckへのASP------->|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPは上昇します。----------------| |----------------------------AckへのASP------------->|、|、|、|、|、|、| | <、-、-、-、-、-、--ASPアクティブです。-------| | |-----ASPのアクティブなAck----->|、|、|、|、|
Morneault, et al. Standards Track [Page 56] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[56ページ]。
5.1.3 Two ASPs in an Application Server (1+1 sparing, load-sharing case)
5.1.3 アプリケーション・サーバーの2つのASP(1+1割く負荷分割法ケース)
This scenario shows a similar case to Section 5.1.2 but where the two ASPs are brought to active and load-share the traffic load. In this case, one ASP is sufficient to handle the total traffic load.
このシナリオは、2つのASPがどこで.2にもかかわらず、アクティブにもたらされていて、トラヒック負荷を負荷で共有するかをセクション5.1への類例に示します。 この場合、1つのASPが、総トラヒック負荷を扱うために十分です。
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
SG ASP1 ASP2| | | | <、-、-、-、-、-、-、-、--ASPは上昇します。---------| | |--------AckへのASP------>|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPは上昇します。---------------| |-----------------------------AckへのASP------------>|、|、|、|、|、|、| | <--ASPのアクティブな(Ldshr)----| | |----ASPのアクティブなAck------>|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPのアクティブな(Ldshr)-----| |-----------------------------ASPのアクティブなAck-------->|、|、|、|
5.1.4 Three ASPs in an Application Server (n+k sparing, load-sharing
case)
5.1.4 アプリケーション・サーバーの3つのASP(n+kの割く負荷分割法ケース)
This scenario shows the example IUA message flows for the establishment of traffic between an SG and three ASPs in the same Application Server, where two of the ASPs are brought to active and share the load. In this case, a minimum of two ASPs are required to handle the total traffic load (2+1 sparing).
このシナリオは、例のIUAメッセージが2つのASPがアクティブにもたらされていて、負荷を共有する同じApplication ServerのSGと3つのASPの間の交通の確立のために流れるのを示します。 この場合、最低2つのASPが、総トラヒック負荷(2+1割く)を扱うのに必要です。
Morneault, et al. Standards Track [Page 57] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[57ページ]。
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASPUp Ack)----->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
SG ASP1 ASP2 ASP3| | | | | <、-、-、-、-、--ASPは上昇します。-------| | | |-----AckへのASP---->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPは上昇します。-------| | |------------------------ASPUp Ack)----->|、|、|、|、|、| |<---------------------------------------------ASPは上昇します。--------| |--------------------------------------------AckへのASP----->|、|、|、|、|、|、|、|、| | <、-ASP条例(Ldshr)---| | | |----ASP条例Ack---->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASP条例(Ldshr)---| | |----------------------ASP条例Ack------>|、|、|、|、|、|
5.2 ASP Traffic Fail-over Examples
5.2 ASPトラフィックフェイルオーバーの例
5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
5.2.1 (1+1割くASPの撤退、Back上がっているOver-乗り)
The following example shows a case in which an ASP withdraws from service:
以下の例はASPがサービスから引き下がる場合を示しています:
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|-------------------NTFY(AS-Pending) --------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |
SG ASP1 ASP2| | | | <、-、-、-、--ASP不活発です。-------| | |----ASPの不活発なAck---->|、| |-------------------NTFY、(-、未定である、)--------------->|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ASPアクティブです。----------| |-----------------------------ASPのアクティブなAck)------->|、|、|
In this case, the SG notifies ASP2 that the AS has moved to the Down state. The SG could have also (optionally) sent a Notify message when the AS moved to the Pending state.
この場合、SGは、ASがDown状態に移行したことをASP2に通知します。 また、ASがPending状態に移行したとき、SGは(任意に)Notifyメッセージを送ったかもしれません。
Note: If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange would not occur.
以下に注意してください。 SGがIUA同輩(SCTPの故障のIUA鼓動の損失か検出)の損失を検出するなら、初期のSG-ASP1 ASP Inactive交換処理は起こらないでしょう。
5.2.2 (1+1 Sparing, Back-up Over-ride)
5.2.2 (1+1割くバックアップオーバーライド)
The following example shows a case in which ASP2 wishes to over-ride ASP1 and take over the traffic:
以下の例はASP2がASP1をくつがえして、トラフィックを引き継ぎたがっている場合を示しています:
Morneault, et al. Standards Track [Page 58] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[58ページ]。
SG ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY( Alt ASP-Act)-->|
| | |
SG ASP1 ASP2| | | |<-------------------------------ASPアクティブです。----------| |-----------------------------ASPのアクティブなAck-------->| |----NTFY(Alt ASP条例)-->|、|、|、|
In this case, the SG notifies ASP1 that an alternative ASP has overridden it.
この場合、SGは、代替のASPがそれをくつがえしたことをASP1に通知します。
5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)
5.2.3 (ケース、ASPの撤退をLoad共有することでのn+k Sparing
Following on from the example in Section 5.1.4, and ASP1 withdraws from service
セクション5.1の.4、およびASP1の例からの以下では、サービスから、引き下がります。
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
SG ASP1 ASP2 ASP3| | | | | <、-、-、--ASP Inact------| | | |---ASP Inact Ack--->|、|、|、|、|、|、| |---------------------------------NTFY(インチ ASP)----------->|、|、|、|、| |<-----------------------------------------ASP条例(Ldshr)---| |-------------------------------------------ASP条例(Ack)--->|、|、|、|、|
In this case, the SG has knowledge of the minimum ASP resources required (implementation dependent) for example if the SG knows that n+k = 2+1 for a load-share AS and n currently equals 1.
この場合、SGにはn+kが等しい例えば、SGが知っているならリソースが必要とした(実装に依存する)最小のASPに関する知識がある、2、+1、負荷シェアASとnは現在、1と等しいです。
Note: If the SG detects loss of the ASP1 IUA peer (IUA heartbeat loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive message exchange would not occur.
以下に注意してください。 SGがASP1 IUA同輩(SCTPの故障のIUA鼓動の損失か検出)の損失を検出するなら、最初のSG-ASP1 ASP Inactive交換処理は起こらないでしょう。
5.3 Q.921/Q.931 primitives backhaul Examples
5.3 Q.921/Q.931基関数逆送Examples
When the IUA layer on the ASP has a QPTM message to send to the SG, it will do the following:
ASPのIUA層にSGに発信するQPTMメッセージがあるとき、以下をするでしょう:
- Determine the correct SG
- 正しいSGを決定してください。
- Find the SCTP association to the chosen SG
- 選ばれたSGにおいてSCTP協会を見つけてください。
- Determine the correct stream in the SCTP association based on
the D channel
- Dチャネルに基づくSCTP協会で正しいストリームを決定してください。
- Fill in the QPTM message, fill in IUA Message Header, fill in
Common Header
- QPTMメッセージに記入してください、そして、IUA Message Headerに記入してください、そして、Common Headerに記入してください。
Morneault, et al. Standards Track [Page 59] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[59ページ]。
- Send the QPTM message to the remote IUA peer in the SG, over
the SCTP association
- SCTP協会の上でSGのリモートIUA同輩にQPTMメッセージを送ってください。
When the IUA layer on the SG has a QPTM message to send to the ASP, it will do the following:
SGの上のIUA層にASPに発信するQPTMメッセージがあるとき、以下をするでしょう:
- Determine the AS for the Interface Identifier
- 決定、インタフェース識別子
- Determine the Active ASP (SCTP association) within the AS
- ASの中でActive ASP(SCTP協会)を決定してください。
- Determine the correct stream in the SCTP association based on
the D channel
- Dチャネルに基づくSCTP協会で正しいストリームを決定してください。
- Fill in the QPTM message, fill in IUA Message Header, fill in
Common Header
- QPTMメッセージに記入してください、そして、IUA Message Headerに記入してください、そして、Common Headerに記入してください。
- Send the QPTM message to the remote IUA peer in the ASP, over
the SCTP association
- SCTP協会の上でASPにおけるリモートIUA同輩にQPTMメッセージを送ってください。
An example of the message flows for establishing a data link on a signaling channel, passing PDUs and releasing a data link on a signaling channel is shown below. An active association between MGC and SG is established (Section 5.1) prior to the following message flows.
シグナリングチャンネルでPDUsを渡して、データ・リンクをリリースするのは以下にメッセージに関する例がシグナリングチャンネルの上にデータ・リンクを設立するために流れるのが示されます。 MGCとSGとの活動的な協会は以下のメッセージ流れの前に設立されます(セクション5.1)。
SG ASP
SG ASP
<----------- Establish Request
Establish Confirm ---------->
<。----------- 設立、要求が設立する、確認---------->。
<----------- Data Request
Data Indication ----------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
<----------- Data Request
Data Indication ----------->
<。----------- データはデータ指示を要求します。-----------><。----------- データはデータ指示を要求します。-----------><。----------- データは<を要求します。----------- データはデータ指示を要求します。----------->。
<----------- Release Request (RELEASE_MGMT)
Release Confirm ---------->
<。----------- リリースが確認するリリース要求(リリース_管理)---------->。
An example of the message flows for a failed attempt to establish a data link on the signaling channel is shown below. In this case, the gateway has a problem with its physical connection (e.g., Red Alarm), so it cannot establish a data link on the signaling channel.
シグナリングチャンネルの上にデータ・リンクを設立する未遂のためのメッセージ流れに関する例は以下に示されます。 この場合、ゲートウェイには物理接続(例えば、Red Alarm)に関する問題があるので、それはシグナリングチャンネルの上にデータ・リンクを設立できません。
Morneault, et al. Standards Track [Page 60] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[60ページ]。
SG ASP
SG ASP
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)
<。----------- 要求(_始めを確立する)リリース指示を確立してください。---------->。(リリース_PHYS)
5.4 Layer Management Communication Examples
5.4 層のマネジメント・コミュニケーションの例
An example of the message flows for communication between Layer Management modules between SG and ASP is shown below. An active association between ASP and SG is established (Section 5.1) prior to the following message flows.
SGとASPの間のLayer Managementモジュールのコミュニケーションのためのメッセージ流れに関する例は以下に示されます。 ASPとSGとの活動的な協会は以下のメッセージ流れの前に設立されます(セクション5.1)。
SG ASP
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<。----------- データは誤り表示を要求します。---------->。(病人_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)
<。----------- TEI状態が確認するTEI状態要求---------->。(割り当てられません)
6.0 Security
6.0 セキュリティ
IUA is designed to carry signaling messages for telephony services. As such, IUA MUST involve the security needs of several parties the end users of the services; the network providers and the applications involved. Additional requirements MAY come from local regulation. While having some overlapping security needs, any security solution SHOULD fulfill all of the different parties' needs.
IUAは、電話サービスへのシグナリングメッセージを伝えるように設計されています。 そういうものとして、IUA MUSTがかかわる、セキュリティは数人のパーティーにサービスのエンドユーザを必要とします。 プロバイダーとアプリケーションがかかわったネットワーク。 追加要件は地方条例から来るかもしれません。 セキュリティが必要とするいくつかの重なることを持っている間、どんなセキュリティソリューションSHOULDも異なったパーティーの必要性のすべてを実現させます。
6.1 Threats
6.1 脅威
There is no quick fix, one-size-fits-all solution for security. As a transport protocol, IUA has the following security objectives:
即効薬がない、セキュリティのためのフリーサイズのソリューションがあります。 トランスポート・プロトコルとして、IUAには、以下のセキュリティ目的があります:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
* 信頼できてタイムリーなユーザデータ伝送の有用性。 * ユーザデータ伝送の保全。 * 利用者データの秘密性。
IUA runs on top of SCTP. SCTP [3] provides certain transport related security features, such as
IUAはSCTPの上で稼働しています。 SCTP[3]は関連するセキュリティ機能をある輸送に提供します。
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
* サービスの*仮面舞踏会*不適当な独占をあふれさせる盲目のサービス不能攻撃*
Morneault, et al. Standards Track [Page 61] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[61ページ]。
When IUA is running in professionally managed corporate or service provider network, it is reasonable to expect that this network includes an appropriate security policy framework. The "Site Security Handbook" [5] SHOULD be consulted for guidance.
IUAが専門的に管理された法人かサービスプロバイダーのネットワークに遺伝しているとき、このネットワークが適切な安全保障政策フレームワークを含んでいると予想するのは妥当です。 」 [5] セキュリティハンドブックSHOULDを位置させてください。「指導のために、相談されます。
When the network in which IUA runs in involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [6] for more information on configuring IPSEC services.
IUAが駆け込むネットワークが1回以上のパーティーにかかわるとき、すべてのパーティーが十分な方法におけるセキュリティを実装したと予想するのは妥当でないかもしれません。 このような場合には、IPSECがユーザペイロードの秘密性を確実にするのに使用されるのは、お勧めです。 IPSECサービスを構成する詳しい情報のための[6]に相談してください。
6.2 Protecting Confidentiality
6.2 秘密性を保護すること。
Particularly for mobile users, the requirement for confidentiality MAY include the masking of IP addresses and ports. In this case application level encryption is not sufficient; IPSEC ESP SHOULD be used instead. Regardless of which level performs the encryption, the IPSEC ISAKMP service SHOULD be used for key management.
特にモバイルユーザに関しては、秘密性のための要件はIPアドレスとポートのマスキングを含むかもしれません。 この場合、アプリケーションレベル暗号化は十分ではありません。 IPSEC ESP SHOULD、代わりに使用されてください。 どのレベルが働くかにかかわらず暗号化、IPSEC ISAKMPはSHOULDを調整します。かぎ管理には、使用されてください。
7.0 IANA Considerations
7.0 IANA問題
7.1 SCTP Payload Protocol Identifier
7.1 SCTP有効搭載量プロトコル識別子
A request will be made to IANA to assign an IUA value for the Payload Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier will be registered:
有効搭載量プロトコルIdentifierのためにSCTP有効搭載量Data塊でIUA値を割り当てるのを要求をIANAにするでしょう。 以下のSCTP有効搭載量プロトコルIdentifierは登録されるでしょう:
IUA "1"
IUA、「1インチ」
The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, to indicate which protocol the SCTP is carrying. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a Data chunk.
SCTP有効搭載量プロトコルIdentifierは、SCTPがどのプロトコルを運ぶかを示すためにそれぞれのSCTP Data塊に含まれています。 この有効搭載量プロトコルIdentifierはSCTPによって直接使用されませんが、あるネットワーク実体によって使用されて、Data塊で運ばれる情報の種類を特定するかもしれません。
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of determining additional information about the data being presented to it by SCTP.
User Adaptation同輩はSCTPによってそれに提示されるデータに関する追加情報を決定する方法として有効搭載量プロトコルIdentifierを使用するかもしれません。
7.2 IUA Protocol Extensions
7.2 IUAプロトコル拡張子
This protocol may also be extended through IANA in three ways:
また、このプロトコルはIANAを通して3つの方法で広げられるかもしれません:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
-- そして、追加メッセージタイプの定義による追加メッセージのクラスの定義で--追加メッセージパラメタの定義で。
Morneault, et al. Standards Track [Page 62] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[62ページ]。
The definition and use of new message classes, types and parameters is an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in [RFC2434].
新しいメッセージのクラス、タイプ、およびパラメタの定義と使用はSIGTRAN適合層の不可欠の一部です。 したがって、これらの拡大は[RFC2434]で定義されるようにIETF Consensus動作でIANAによって割り当てられます。
The proposed extension must in no way adversely affect the general working of the protocol.
提案された拡大はプロトコルの一般的な運用に決して悪影響を与えてはいけません。
7.2.1 IETF Defined Message Classes
7.2.1 IETFはメッセージのクラスを定義しました。
The documentation for a new message class MUST include the following information:
新しいメッセージのクラスのためのドキュメンテーションは以下の情報を含まなければなりません:
(a) A long and short name for the message class. (b) A detailed description of the purpose of the message class.
(a) 長くてメッセージのクラスに、短い名前。 (b) メッセージのクラスの目的の詳述。
7.2.2 IETF Defined Message Types
7.2.2 IETFはメッセージタイプを定義しました。
Documentation of the message type MUST contain the following information:
メッセージタイプのドキュメンテーションは以下の情報を含まなければなりません:
(a) A long and short name for the new message type.
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.
ti3 (d) A detailed procedural description of the use of the new
message type within the operation of the protocol.
(e) A detailed description of error conditions when receiving this
message type.
(a) 長くて新しいメッセージタイプに、短い名前。 (b) メッセージの構造の詳述。 (c) それぞれの意図している使用の詳細な定義と記述はプロトコルの操作の中で. メッセージti3(d)の中で新しいメッセージタイプの使用の詳細な手続き上の記述をさばきます。 (e) このメッセージタイプを受けるときのエラー条件の詳述。
When an implementation receives a message type which it does not support, it MUST respond with an Error (ERR) message with an Error Code of Unsupported Message Type.
実装がそれがサポートしないメッセージタイプを受けるとき、それはUnsupported Message TypeのError Codeと共にError(ERR)メッセージで応じなければなりません。
7.2.3 IETF-defined TLV Parameter Extension
7.2.3 IETFによって定義されたTLVパラメタ拡張子
Documentation of the message parameter MUST contain the following information:
メッセージパラメタのドキュメンテーションは以下の情報を含まなければなりません:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.1.5.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within the
same message type.
(a) パラメータの型の名前。 (b) パラメタ分野の構造の詳述。 この構造はセクション3.1.5で説明された一般的なタイプ長さの価値の形式に一致しなければなりません。 (c) パラメタ価値のそれぞれのコンポーネントの詳細な定義。 (d) このパラメータの型の意図している使用の記述、および指示を詳しく述べる、そして、どんな状況で、このパラメータの型の複数のインスタンスが同じメッセージタイプの中で見つけられるかもしれませんか?
Morneault, et al. Standards Track [Page 63] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[63ページ]。
8.0 Acknowledgements
8.0 承認
The authors would like to thank Alex Audu, Maria Sonia Vazquez Arevalillo, Ming-te Chao, Keith Drage, Norm Glaude, Nikhil Jain, Bernard Kuc, Ming Lin, Stephen Lorusso, John Loughney, Barry Nagelberg, Neil Olson, Lyndon Ong, Heinz Prantner, Jose Luis Jimenez Ramirez, Ian Rytina, Michael Tuexen and Hank Wang for their valuable comments and suggestions.
作者は彼らの貴重なコメントと提案についてジャイナ教のバーナードKuc、Nikhil明リンのアレックスAudu、マリアソニアバスケスArevalillo、明-Teチャオ、キースDrage、Norm Glaude、スティーブンLorusso、ジョンLoughney、バリーNagelberg、ニール・オルソン、リンドン・オング、ハインツPrantner、ホセ・ルイス・ヒメネス・ラミレス、イアンRytina、マイケルTuexen、およびハンクワングに感謝したがっています。
9.0 References
9.0の参照箇所
[1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System
No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer -
General Aspects'
[1] 'デジタルSubscriberがSystem No.1(DSS1)--ISDN User-ネットワークInterface Data Link Layer--Aspects司令官に合図することでのITU-T Recommendation Q.920
[2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a
Voice over Packet Network'
[2] T1S1.7/99-220貢献、'引っ張りを支持しているDSS1はPacket Networkの上のVoiceで議定書を作ります'。
[3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H.,
Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural
Framework for Signaling Transport", RFC 2719, October 1999.
[4] オング、L.、Rytina、I.、ガルシア、M.、Schwarzbauer、H.、Coene、L.、リン、H.、Juhasz、I.、Holdrege、M.、および鋭く、「シグナリングのための建築フレームワークは輸送する」C.、RFC2719(1999年10月)。
[5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September
1997.
[5] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[6] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[7] Bradner, s., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、s.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Morneault, et al. Standards Track [Page 64] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[64ページ]。
10.0 Authors' Addresses
10.0 作者のアドレス
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA
ケンMorneaultシスコシステムズInc.13615ダレスTechnology Driveハーンドン(ヴァージニア)。 20171 米国
Phone: +1-703-484-3323 EMail: kmorneau@cisco.com
以下に電話をしてください。 +1-703-484-3323 メールしてください: kmorneau@cisco.com
Malleswar Kalla Telcordia Technologies PYA 2J-341 3 Corporate Place Piscataway, NJ 08854 USA
MalleswarカッラTelcordia Technologiesピア2J-341 3の法人のPlaceピスキャタウェイ(ニュージャージー)08854米国
Phone: +1-732-699-3728 EMail: mkalla@telcordia.com
以下に電話をしてください。 +1-732-699-3728 メールしてください: mkalla@telcordia.com
Selvam Rengasami Telcordia Technologies NVC-2Z439 331 Newman Springs Road Red Bank, NJ 07701 USA
NVC-2Z439 331ニューマン春の道路赤が盛り土するSelvam Rengasami Telcordia技術、ニュージャージー07701米国
Phone: +1-732-758-5260 EMail: srengasa@telcordia.com
以下に電話をしてください。 +1-732-758-5260 メールしてください: srengasa@telcordia.com
Greg Sidebottom Nortel Networks 3685 Richmond Road Nepean, Ontario Canada K2H5B7
オンタリオカナダK2H5B7、グレッグSidebottomノーテルは3685リッチモンド道路ネピアンをネットワークでつなぎます。
Phone: +1-613-763-7305 EMail: gregside@nortelnetworks.com
以下に電話をしてください。 +1-613-763-7305 メールしてください: gregside@nortelnetworks.com
Morneault, et al. Standards Track [Page 65] RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Morneault、他 規格はISDN Q.921-ユーザ適合層の2001年2月にRFC3057を追跡します[65ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Morneault, et al. Standards Track [Page 66]
Morneault、他 標準化過程[66ページ]
一覧
スポンサーリンク
