RFC4233 日本語訳
4233 Integrated Services Digital Network (ISDN) Q.921-User AdaptationLayer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. January 2006. (Format: TXT=157857 bytes) (Obsoletes RFC3057) (Updated by RFC5133) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Morneault
Request for Comments: 4233 Cisco Systems
Obsoletes: 3057 S. Rengasami
Category: Standards Track Tridea Works
M. Kalla
Telcordia Technologies
G. Sidebottom
Signatus Technologies
January 2006
Morneaultがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4233 シスコシステムズは以下を時代遅れにします。 3057秒間Rengasamiカテゴリ: 標準化過程TrideaはM.カッラTelcordia技術G.Sidebottom Signatus技術2006年1月に働いています。
Integrated Services Digital Network (ISDN)
Q.921-User Adaptation Layer
サービス統合ディジタル網(ISDN)Q.921-ユーザ適合層
Status of This 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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines a protocol for backhauling of Integrated Services Digital Network (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の上でIntegrated Services Digital Network(ISDN)Q.921 UserメッセージをbackhaulingするようにStream Control Transmissionプロトコル(SCTP)を使用することでプロトコルを定義します。 このプロトコルはSignalingゲートウェイ(SG)とメディアゲートウェイController(MGC)の間で使用されるでしょう。 SGが標準のISDNインタフェースの上にISDNシグナリングを受けると思われます。
This document obsoletes RFC 3057.
このドキュメントはRFC3057を時代遅れにします。
Morneault, et al. Standards Track [Page 1] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. IUA Overview ...............................................5
1.4. Services Provided by the IUA Layer .........................7
1.5. Functions Implemented by the IUA Layer ....................10
1.6. Definition of IUA Boundaries ..............................12
2. Conventions ....................................................15
3. Protocol Elements ..............................................15
3.1. Common Message Header .....................................15
3.2. IUA Message Header ........................................19
3.3. IUA Messages ..............................................21
4. Procedures .....................................................46
4.1. Procedures to Support Service in Section 1.4.1 ............46
4.2. Procedures to Support Service in Section 1.4.2 ............46
4.3. Procedures to Support Service in Section 1.4.3 ............48
5. Examples .......................................................58
5.1. Establishment of Association and Traffic between
SGs and ASPs ..............................................58
5.2. ASP Traffic Fail-over Examples ............................62
5.3. Q.921/Q.931 Primitives Backhaul Examples ..................63
5.4. Layer Management Communication Examples ...................64
6. Security .......................................................65
7. IANA Considerations ............................................65
7.1. SCTP Payload Protocol Identifier ..........................65
7.2. IUA Protocol Extensions ...................................65
8. Timer Values ...................................................67
9. Acknowledgements ...............................................67
10. References ....................................................67
10.1. Normative References .....................................67
10.2. Informative References ...................................67
11. Change Log ....................................................68
Appendix A ........................................................69
A.1. Signaling Network Architecture ............................69
A.2. Application Server Process Redundancy .....................70
1. 序論…3 1.1. 範囲…3 1.2. 用語…3 1.3. IUA概要…5 1.4. IUAによって提供されたサービスは層にされます…7 1.5. IUAによって実装された機能は層にされます…10 1.6. IUA境界の定義…12 2. コンベンション…15 3. Elementsについて議定書の中で述べてください…15 3.1. 一般的なメッセージヘッダー…15 3.2. IUAメッセージヘッダー…19 3.3. IUAメッセージ…21 4. 手順…46 4.1. セクション1.4.1における支援活動への手順…46 4.2. セクション1.4.2における支援活動への手順…46 4.3. セクション1.4.3における支援活動への手順…48 5. 例…58 5.1. SGsとASPの間の協会とトラフィックの設立…58 5.2. ASPトラフィックフェイルオーバーの例…62 5.3. Q.921/Q.931基関数逆送の例…63 5.4. マネジメント・コミュニケーションの例を層にしてください…64 6. セキュリティ…65 7. IANA問題…65 7.1. SCTP有効搭載量プロトコル識別子…65 7.2. IUAは拡大について議定書の中で述べます…65 8. タイマ値…67 9. 承認…67 10. 参照…67 10.1. 標準の参照…67 10.2. 有益な参照…67 11. ログを変えてください…68 付録A…69 A.1。 シグナリングはアーキテクチャをネットワークでつなぎます…69 A.2。 アプリケーション・サーバープロセス冗長…70
Morneault, et al. Standards Track [Page 2] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[2ページ]。
1. Introduction
1. 序論
In this document, the term Q.921-User refers to an upper layer that 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で説明されるようにあります。
Signaling Transport [5]. The delivery mechanism SHOULD meet the following criteria:
シグナリングは[5]を輸送します。 排紙機構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 SCTP active associations between SG
and MGC
* Q.921/Q.931の輸送には、SGとMGCとのSCTPの活動的な協会の経営の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)の両方をサポートします。 このサポートはFacility Associated Signaling(FAS)、Non-施設Associated Signaling(NFAS)、およびバックアップDチャネルがあるNFASを含んでいます。 QSIG適合層の要件はQ.931適合層と異なっていません。 したがって、また、QSIG適合層に、本書では説明された手順も適切です。 簡単さにおいて、このドキュメントの残りでQ.931だけについて言及するでしょう。
1.2. Terminology
1.2. 用語
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インスタンスのバックアップをとります。
Morneault, et al. Standards Track [Page 3] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[3ページ]。
Association - An association refers to an 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適合層の同輩メッセージの配送のための輸送を提供するでしょう。
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を終えます。
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 backup MGC). Fail-over also applies upon the return to service of a previously unavailable process.
フェイルオーバー--現在中古のASP(例えば、プライマリMGCからバックアップMGCまでの)の失敗か使用不能の場合、必要に応じて関連するASPの間でシグナリングトラフィックを別ルートで送る能力。 また、フェイルオーバーはリターンのときに以前に入手できないプロセスのサービスに適用されます。
Host - The computing platform that the ASP process is running on.
ホスト--ASPプロセスが走っているコンピューティングプラットホーム。
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チャンネルです。
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 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.
インタフェースIdentifier--Interface Identifierはシグナリングメッセージが送るか、または受信されているSGで物理インターフェースを特定します。 Interface Identifierパラメタの形式は、テキストか整数であるかもしれません。ネットワーク・オペレータ方針によると、それの値は割り当てられます。 使用される値はSGとASPの間で唯一の、そして、連携しているローカルの意味のものです。 意味はASによって役立たれたSGsの向こう側に含意されません。
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. 最初に、ビッグエンディアン。
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終点を関連づけました。そこでは、連続して順不同のデリバリ・サービスに提出されたものを除いて、すべてのユーザメッセージが提供されます。
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など)のサービスを利用するどんなプロトコル。
Morneault, et al. Standards Track [Page 4] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[4ページ]。
1.3. IUA Overview
1.3. IUA概要
The architecture that has been defined [5] 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シグナリング輸送のための[5]は複数のコンポーネントを使用します、特定のSCNシグナリングプロトコルによって基本的なプロトコル層から予想されたサービスをサポートするためにIPトランスポート・プロトコル、合図している一般的なトランスポート・プロトコル、および適合モジュールを含んでいてことであるアーキテクチャ。
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 (SG), 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ゲートウェイ(SG)では、ISDNシグナリングが標準のISDNネットワーク終了の上に受け取られると予想されます。 次に、SGは輸送機能を織り込むのにIP Signaling Transportを提供します、同輩Q.931プロトコル層が存在するMGCにQ.931シグナリングメッセージを輸送するために、以下に示すように:
****** 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 [4,8])
IUA - ISDN User Adaptation Layer Protocol
NIF--こぶのような織り込む機能EP--ISDNエンドポイントSCTP--ストリーム制御伝動プロトコル(言及します[4、8])IUA--ISDNユーザ適合層のプロトコル
Figure 1. IUA in the SG to MGC Application
図1。 MGCアプリケーションへのSGのIUA
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)
- 明白なパケット指向の配送(ストリーム指向でない)です。
Morneault, et al. Standards Track [Page 5] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[5ページ]。
- 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 be determined to not be required and TCP MAY be used as the underlying common transport protocol.
シナリオが冗長がトランスポート層の下でサポートされる冗長要件とシナリオなしであります。 これらのケース、上の機能が決定しているかもしれないSCTPでは、必要にしないでください、TCP MAY、基本的な一般的なトランスポート・プロトコルとして、使用されてください。
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 states of remote ASP(s) are maintained. Active ASPs are those currently receiving traffic from the SG.
SGのIUA層はすべてのダイナミックに登録されたリモートASPの有用性状態を維持します、SGとASPの間のSCTP協会とトラフィックを経営するために。 また、リモートASPのアクティブであるか不活発な州は維持されます。 活動的なASPは現在SGからトラフィックを受けるものです。
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. ASP Fail-over Model and Terminology
1.3.3. 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 6] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[6ページ]。
The IUA layer supports an n+k redundancy model (active-standby, load sharing, broadcast) where n is 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.
IUA層はnがトラフィックを扱わなければならなかった余分なASPの最小の数であり、k ASPが失敗したか入手できないASPのために持って行くために入手できるところでn+k冗長モデルをサポートします(活発な予備(負荷分割法)は放送されました)。 1つの+1アクティブな/予備冗長がこのモデルの部分集合であることに注意してください。 また、シンプレクス1+0モデルは部分集合としてASP冗長なしでサポートされます。
1.3.4. Client/Server Model
1.3.4. クライアント/サーバモデル
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 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.
SGとASPがクライアントとサーバ操作の両方をサポートすることができるのは、お勧めです。 ものがクライアントともう片方の役割でいつもSCTP協会を開始するのにサーバの役割を果たすように構成されていて、IUA SHOULDを使用する同輩終点。 ASPはクライアントですが、デフォルトオリエンテーションはSGがサーバの役割を引き受けるだろうことです。 この場合、ASP SHOULDはSCTP協会をSGに開始します。
The SCTP and TCP Registered User Port Number Assignment for IUA is 9900.
IUAのためのSCTPとTCP Registered User Port Number Assignmentは9900です。
1.4. Services Provided by the IUA Layer
1.4. IUA層で提供されたサービス
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基関数は、以前に確立した倍数フレーム操作を終えるか、または失敗の設立試みを報告するための手順の結果を要求して、示して、確認するのに使用されます。
Morneault, et al. Standards Track [Page 7] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[7ページ]。
DL-DATA
dlデータ
The DL-DATA primitives are used to request and indicate layer 3 (Q.931) messages that 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 that are to be transmitted, by the Q.921 layer using the unacknowledged information transfer service.
DL-UNIT DATA基関数は送られることになっている層3(Q.931)のメッセージを要求して、示すのに使用されます、不承認の情報転送サービスを利用するQ.921層のそばで。
1.4.2. Support for Communication between Layer Management Modules on SG
and MGC
1.4.2. SGとMGCの上の層の管理モジュールのコミュニケーションのサポート
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 shown below:
それは思い描かれます。IUA層が、いくつかのサービスにそれを提供する必要があるのがSGとMGCでLayer Managementモジュールのコミュニケーションを容易にするでしょう。 これらの基関数は以下に示されます:
M-TEI STATUS
M-TEI状態
The M-TEI STATUS primitives are used to request, confirm, and indicate the status (assigned/unassigned) of an ISDN Terminal Endpoint Identifier (TEI).
M-TEI STATUS基関数は、ISDN Terminal Endpoint Identifier(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 is 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協会の設立を要求して、示して、確認するのに使用されます。
Morneault, et al. Standards Track [Page 8] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[8ページ]。
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協会の状態を要求して、示すのに使用されます。
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を生成するのにそれを使用できます。
Morneault, et al. Standards Track [Page 9] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[9ページ]。
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の状態を示すのにこの基関数を使用できます。
1.5. Functions Implemented by the IUA Layer
1.5. IUA層によって実装された機能
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 Time- Division Multiplexing (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 ISDN Terminal Endpoint Identifiers (TEIs) and Service Access Point Identifiers (SAPIs).
IUA層はSignalingゲートウェイでInterface Identifierの地図を物理インターフェースに維持しなければなりません。 物理インターフェースは、T1系列、1Eの系列であるだろうなど、Time事業部Multiplexing(TDM)timeslotを含むかもしれません。 当然のことに関して、さらに、SG MUSTを連結してください。関連シグナリングチャンネルを特定できてください。 SGとMGC MAYの両方のIUA層はISDN Terminal Endpoint Identifiers(TEIs)とService Access Point Identifiers(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 fail-over 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| +----+ +-----+
Morneault, et al. Standards Track [Page 10] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[10ページ]。
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で説明されます。
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 backup 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に命令するかもしれません。適切であると考えます。
Morneault, et al. Standards Track [Page 11] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[11ページ]。
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協会からフロー制御まで読むのを止めるかもしれません。
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 Section 10 of RFC 2960 [4].
SCTPによって提供された上側の層の基関数の例はRFC2960[4]のセクション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に知らせます。
Morneault, et al. Standards Track [Page 12] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[12ページ]。
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に確認します。
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メッセージを受け取ったと報告します。
Morneault, et al. Standards Track [Page 13] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[13ページ]。
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メッセージを受け取りました。
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状態指示を受けました。
Morneault, et al. Standards Track [Page 14] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[14ページ]。
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. Conventions
2. コンベンション
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 [6].
キーワードが解釈しなければならない、本書では現れるとき、[6]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. Protocol Elements
3. プロトコル要素
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 that 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 2. Common Header Format
図2。 一般的なヘッダー形式
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
Morneault, et al. Standards Track [Page 15] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[15ページ]。
3.1.2. Message Classes and Types
3.1.2. メッセージのクラスとタイプ
The following list contains the valid Message Classes:
以下のリストは有効なMessage Classesを入れてあます:
Message Class: 8 bits (unsigned integer)
メッセージのクラス: 8ビット(符号のない整数)
0 Management (MGMT) Message
1 Reserved for Other SIGTRAN Adaptation Layer
2 Reserved for Other SIGTRAN Adaptation Layers
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
6 Reserved for Other SIGTRAN Adaptation Layer
7 Reserved for Other SIGTRAN Adaptation Layer
8 Reserved for Other SIGTRAN Adaptation Layer
9 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions
0 Other SIGTRAN Adaptation Layer9〜127ReservedごとのOther SIGTRAN Adaptation Layer8ReservedのためのOther SIGTRAN Adaptation Layer7ReservedのためのOther SIGTRAN Adaptation Layers3ASP州Maintenance(ASPSM)メッセージ4ASP Traffic Maintenance(ASPTM)メッセージ5Q.921/Q.931 Boundary Primitives Transport(QPTM)メッセージ6ReservedのためのOther SIGTRAN Adaptation Layer2Reservedのためのメッセージ1管理(MGMT)Reserved
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
Morneault, et al. Standards Track [Page 16] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[16ページ]。
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
Management (MGMT) Messages
管理(管理)メッセージ
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 TEI Query Request
6 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 Indication5TEI Query Request6〜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. The Message Length MUST include parameter padding bytes, if any.
Message LengthはCommon Headerを含む八重奏における、メッセージの長さを定義します。 Message Lengthはもしあればパラメタ詰め物バイトを含まなければなりません。
Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length.
以下に注意してください。 最終的なパラメタ詰め物がメッセージ長に含まれているか否かに関係なく、受信機SHOULDはメッセージを受け入れます。
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 Type-Length-Value (TLV) format as shown below.
IUAメッセージはメッセージタイプによって定義されるようにゼロか、より可変長のパラメタがあとに続いたCommon Headerから成ります。 メッセージに含まれた可変長のパラメタはType長さの価値(TLV)の形式で以下に示すように定義されます。
Morneault, et al. Standards Track [Page 17] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[17ページ]。
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. Common parameters used by adaptation layers are in the range of 0x00 to 0x3f. The parameter Tags defined are as follows:
Tag分野はパラメタのタイプの16ビットの識別子です。 それは0〜65534の値を取ります。 0x3fには適合層によって使用される一般的なパラメタが0×00の範囲にあります。 定義されたパラメタTagsは以下の通りです:
Common Parameters. These TLV parameters are common across the different adaptation layers:
一般的なパラメタ。 これらのTLVパラメタは異なった適合層の向こう側に一般的です:
Parameter Name Parameter ID ============== ============ Reserved 0x0000 Interface Identifier (integer) 0x0001 Not Used in IUA 0x0002 Interface Identifier (text) 0x0003 INFO String 0x0004 DLCI 0x0005 Not Used in IUA 0x0006 Diagnostic Information 0x0007 Interface Identifier Range 0x0008 Heartbeat Data 0x0009 Not Used in IUA 0x000a Traffic Mode Type 0x000b Error Code 0x000c Status 0x000d Protocol Data 0x000e Release Reason 0x000f TEI Status 0x0010 ASP Identifier 0x0011 Not Used in IUA 0x0012 - 0x003f
パラメタ名前パラメタID============== ============ (整数)0x0001がIUA0x0012で使用されないIUA 0x000aトラフィックモードタイプ0x000bエラーコード0x000c状態0x000dプロトコルデータ0x000eリリース理由0x000f TEI状態0x0010ASP識別子0x0011で使用されない0×0008のIUA0x0006診断情報0x0007インタフェース識別子範囲鼓動データ0x0009で使用されないIUA0x0002インタフェース識別子(テキスト)0×0003インフォメーションストリング0x0004DLCI0x0005で使用しなかった予約された0×0000インタフェース識別子--0x003f
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 18] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[18ページ]。
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を水増ししません。 詰め物の長さはParameter Length分野に含まれていません。 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 19] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[19ページ]。
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 3. IUA Message Header (Integer-based Interface Identifier)
図3。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Interface Identifier (text) \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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×3)| 長さ| インタフェース..識別子..テキスト| タグ(0×5)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI| 予備| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. IUA Message Header (Text-based Interface Identifier)
図4。 IUAメッセージヘッダー(テキストベースのインタフェース識別子)
The Tag value for the Text-based [2] Interface Identifier is 0x3. The length is variable.
Textベースの[2]インタフェースIdentifierのためのTag値は0×3です。 長さは可変です。
The DLCI format is shown below in Figure 5.
DLCI書式は図5に以下に示されます。
most least
significant significant
bit bit
+-----+-----+-----+-----+-----+-----+-----+-----+
| SAPI | SPR | 0 |
+-----------------------------------------------+
| TEI | 1 |
+-----------------------------------------------+
ほとんどの最も重要でない重要な噛み付いているビット+-----+-----+-----+-----+-----+-----+-----+-----+ | SAPI| SPR| 0 | +-----------------------------------------------+ | TEI| 1 | +-----------------------------------------------+
Figure 5. DLCI Format
図5。 DLCI形式
Morneault, et al. Standards Track [Page 20] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[20ページ]。
SPR: Spare 2nd bit in octet 1 (1 bit)
SPR: 八重奏1で2番目のビットを割いてください。(1ビット)
SAPI: Service Access Point Identifier (6 bits)
SAPI: サービスアクセスポイント識別子(6ビット)
TEI: Terminal Endpoint Identifier (7 bits)
TEI: 端末の終点識別子(7ビット)
As an example, SAPI = 0, TEI = 64, SPR = 0 would be encoded as follows:
例として、SAPIは0、TEI=64と等しく、SPR=0は以下の通りコード化されるでしょう:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x5) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | 0x81 | 0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0×5)| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×0| 0×81| 0×0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 2) and the IUA message header (Figure 3 and Figure 4).
以下のセクションはメッセージとパラメタコンテンツを定義します。 IUAメッセージは一般的なメッセージヘッダー(図2)とIUAメッセージヘッダー(図3と図4)を使用するでしょう。
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 resend 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 a 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 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
SGがMGCからIUA Establish Requestを受けるとき、SGはQ.921実体への原始のQ.921 Establish Requestを送るものとします。 さらに、SGはQ.921実体から適切なメッセージまでMGCに受けられたどんな応答も写像するものとします。 Q.921 Establish Confirmが原始的にQ.921実体が例えば応じるなら
Morneault, et al. Standards Track [Page 21] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[21ページ]。
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.
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メッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 それはどんな追加パラメタも含んでいません。
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 ConfirmメッセージはRelease Requestメッセージに対応しています、そして、それはどんな追加パラメタも含んでいません。 Release RequestとIndicationメッセージは以下のパラメタを含んでいます:
Reason
理由
The format for Release Message parameters is as follows:
Release 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 (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)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 理由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 22] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[22ページ]。
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)を含んでいます。
The Data messages contain the common message header followed by IUA message header. The Data message contains the following parameter:
DataメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 Dataメッセージは以下のパラメタを含んでいます:
Protocol Data
プロトコルデータ
The format for Data Message parameters is as follows:
Data 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 (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xe)| 長さ| プロトコル..データ
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 parameter:
Unit DataメッセージはIUAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 Unit Dataメッセージは以下のパラメタを含んでいます:
Morneault, et al. Standards Track [Page 23] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[23ページ]。
Protocol Data
プロトコルデータ
The format for Unit Data Message parameters is as follows:
Unit Data 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 (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ(0xe)| 長さ| プロトコル..データ
3.3.2. Application Server Process Maintenance (ASPM) Messages
3.3.2. アプリケーション・サーバープロセスメインテナンス(ASPM)メッセージ
The ASPM messages will use only 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によって送られます。
The ASPUP message contains the following parameters:
ASPUPメッセージは以下のパラメタを含んでいます:
ASP Identifier (Optional)
INFO String (Optional)
ASPの識別子の(任意)のインフォメーションストリング(任意)です。
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 = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0011| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0004| 長さ| インフォメーション..ストリング
ASP Identifier: 32-bit unsigned integer
ASP Identifier: 32-bit unsigned integer
Morneault, et al. Standards Track [Page 24] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 24] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SG should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.3.3.2).
The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SG should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.3.3.2).
The optional INFO String parameter can carry any meaningful 8-bit ASCII [2] 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.
The optional INFO String parameter can carry any meaningful 8-bit ASCII [2] 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.
3.3.2.2. ASP Up Ack
3.3.2.2. ASP Up Ack
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote IUA peer.
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote IUA peer.
The ASPUP Ack message contains the following parameters:
The ASPUP Ack message contains the following parameters:
INFO String (optional)
INFO String (optional)
The format for ASPUP Ack Message parameters is as follows:
The format for ASPUP Ack Message parameters is as follows:
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
3.3.2.3. ASP Down (ASPDN)
3.3.2.3. ASP Down (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.
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.
The ASPDN message contains the following parameters:
The ASPDN message contains the following parameters:
INFO String (Optional)
INFO String (Optional)
Morneault, et al. Standards Track [Page 25] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 25] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASPDN message parameters is as follows:
The format for the ASPDN message parameters is as follows:
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
3.3.2.4. ASP Down Ack
3.3.2.4. ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer.
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer.
The ASP Down Ack message contains the following parameters:
The ASP Down Ack message contains the following parameters:
INFO String (Optional)
INFO String (Optional)
The format for the ASP Down Ack message parameters is as follows:
The format for the ASP Down Ack message parameters is as follows:
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
3.3.2.5. ASP Active (ASPAC)
3.3.2.5. ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is Active and ready to be used.
The ASPAC message is sent by an ASP to indicate to an SG that it is Active and ready to be used.
Morneault, et al. Standards Track [Page 26] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 26] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The ASPAC message contains the following parameters:
The ASPAC message contains the following parameters:
Traffic Mode Type (Mandatory)
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text-formatted)
INFO String (Optional)
Traffic Mode Type (Mandatory) Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text-formatted) INFO String (Optional)
Morneault, et al. Standards Track [Page 27] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 27] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASPAC message using integer-formatted Interface Identifiers is as follows:
The format for the ASPAC message using integer-formatted Interface Identifiers is as follows:
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 = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x000b | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / 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* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Interface Identifier Parameters / \ of Tag Type 0x1 or 0x8 \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 28] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 28] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASPAC message using text-formatted (string) Interface Identifiers is as follows:
The format for the ASPAC message using text-formatted (string) Interface Identifiers is as follows:
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 = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x000b | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Interface Identifiers / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Interface Identifier Parameters / \ of Tag Type 0x3 \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / 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:
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:
Value Description
0x1 Over-ride
0x2 Load-share
Value Description 0x1 Over-ride 0x2 Load-share
Within a particular AS, 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/backup 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.
Within a particular AS, 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/backup 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.
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
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
Morneault, et al. Standards Track [Page 29] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 29] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
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.
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.
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS or ASes in which the ASP is provisioned. If only a subset of Interface Identifiers is included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS or ASes in which the ASP is provisioned. If only a subset of Interface Identifiers is included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
Note: If the optional Interface Identifier parameter is present, the integer-formatted Interface Identifier MUST be supported, whereas the text-formatted Interface Identifier MAY be supported.
Note: If the optional Interface Identifier parameter is present, the integer-formatted Interface Identifier MUST be supported, whereas the text-formatted Interface Identifier MAY be supported.
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1.).
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1.).
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).
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).
3.3.2.6. ASP Active Ack
3.3.2.6. ASP Active Ack
The ASPAC Ack message is used to acknowledge an ASP Active message received from a remote IUA peer.
The ASPAC Ack message is used to acknowledge an ASP Active message received from a remote IUA peer.
The ASPAC Ack message contains the following parameters:
The ASPAC Ack message contains the following parameters:
Traffic Mode Type (Mandatory)
Interface Identifier (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
Traffic Mode Type (Mandatory) Interface Identifier (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (Optional)
Morneault, et al. Standards Track [Page 30] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 30] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASPAC Ack message with integer-formatted Interface Identifiers is as follows:
The format for the ASPAC Ack message with integer-formatted Interface Identifiers is as follows:
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 = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x000b | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / 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* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Interface Identifier Parameters / \ of Tag Type 0x1 or 0x8 \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 31] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 31] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASP Active Ack message using text-formatted (string) Interface Identifiers is as follows:
The format for the ASP Active Ack message using text-formatted (string) Interface Identifiers is as follows:
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 = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 0x000b | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Interface Identifiers / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Interface Identifier Parameters / \ of Tag Type 0x3 \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / 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).
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).
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
3.3.2.7. ASP Inactive (ASPIA)
3.3.2.7. ASP Inactive (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.
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.
Morneault, et al. Standards Track [Page 32] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 32] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The ASPIA message contains the following parameters:
The ASPIA message contains the following parameters:
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text formatted)
INFO String (Optional)
INFO String (Optional)
The format for the ASP Inactive message parameters using integer- formatted Interface Identifiers is as follows:
The format for the ASP Inactive message parameters using integer- formatted Interface Identifiers is as follows:
Morneault, et al. Standards Track [Page 33] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 33] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
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=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=integer) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / 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* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Interface Identifier Parameters / \ of Tag Type 0x1 or 0x8 \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 34] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 34] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASP Inactive message using text-formatted (string) Interface Identifiers is as follows:
The format for the ASP Inactive message using text-formatted (string) Interface Identifiers is as follows:
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=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=string) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Interface Identifiers / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Interface Identifier Parameters / \ of Tag Type 0x3 \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
3.3.2.8. ASP Inactive Ack
3.3.2.8. ASP Inactive Ack
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote IUA peer.
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote IUA peer.
The ASPIA Ack message contains the following parameters:
The ASPIA Ack message contains the following parameters:
Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
INFO String (Optional)
Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (Optional)
Morneault, et al. Standards Track [Page 35] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault, et al. Standards Track [Page 35] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
The format for the ASP Inactive Ack message parameters using integer-formatted Interface Identifiers is as follows:
The format for the ASP Inactive Ack message parameters using integer-formatted Interface Identifiers is as follows:
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=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| 追加..インタフェース..識別子..パラメタ..タグ..タイプ..0×1..0×8| タグ(0×4)| 長さ| インフォメーション..ストリング
Morneault, et al. Standards Track [Page 36] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[36ページ]。
The format for the ASP Inactive Ack message using text-formatted (string) Interface Identifiers is as follows:
テキストでフォーマットされた(ストリング)インタフェースIdentifiersを使用するASP Inactive 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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=ストリング)にタグ付けをしてください。| 長さ| インタフェース..識別子..追加..インタフェース..識別子..パラメタ..タグ..タイプ..0×3| タグ(0×4)| 長さ| インフォメーション..ストリング
The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
セクション3.3を見てください。任意のInterface IdentifiersとINFO Stringパラメタの形式と記述がASP Activeメッセージのように同じである、(.2 .5)。
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 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[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 = 0x0009 | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0009| 長さ| 鼓動..データ
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 have only 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 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[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 = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Diagnostic Information \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x000c| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0007| 長さ| 診断情報
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メッセージの理由を示します。 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
Refused - Management Blocking 0x0d
ASP Identifier Required 0x0e
Invalid ASP Identifier 0x0f
無効のバージョン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 Refused--管理Blocking 0x0d ASP Identifier Required 0x0e Invalid ASP Identifier 0x0f
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 an SG if an ASP sends a message with an invalid (unconfigured) Interface Identifier value. For this error, the Diagnostic Information MUST contain enough of the offending message to identify the invalid Interface Identifier. For example, in the case of QPTM and TEI Status management messages, the Common and IUA message headers of the offending message would be placed in the Diagnostic Information at a minimum.
ASPが無効(非構成される)のインタフェースIdentifier価値があるメッセージを送るなら、「無効のインタフェース識別子」誤りはSGによって送られるでしょう。 この誤りによって、Diagnostic情報は腹立たしいメッセージが無効のInterface Identifierを特定する十分を含まなければなりません。 例えば、QPTMとTEI Status管理メッセージの場合では、腹立たしいメッセージのCommonとIUAメッセージヘッダーは最小限でDiagnostic情報に置かれるでしょう。
Morneault, et al. Standards Track [Page 39] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[39ページ]。
The "Unsupported Traffic Handling Mode" error would be sent by an 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 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).
それがInactive状態にあった間(ASPは、任意にメッセージを下げて、誤りを送ることができませんでした)、SGからQPTMメッセージを受け取るなら、「予期していなかったメッセージ」誤りはASPによって送られるでしょうに。 また、それが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 (e.g., a MGMT message was received on a stream other than "0").
予期していなかったSCTPストリームにメッセージを受け取るなら「無効のストリーム識別子」誤りを送る、(ストリームに例えばMGMTメッセージを受け取った、「0インチ)」
The "Unsupported Interface Identifier Type" error would be sent by an 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を送るなら、「サポートされないインタフェース識別子タイプ」誤りはSGによって送られるでしょう、そして、SGは整数でフォーマットされたInterface Identifiersをサポートするだけです。 ASPがこの誤りを受けるとき、それは、整数でフォーマットされた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 that 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 an SAPI that is not recognized by the SG. The "Invalid TEI, SAPI combination" error identifies errors where the TEI is assigned and the SAPI is recognized, but the combination is not valid for the interface (e.g., on a Basic Rate Interface (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であるときに、例えば、Basic Rate Interface(BRI)では、MGCはIUAを通してメッセージをQ.921 Managementに送ろうとします)。
The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lockout).
ASP UpかASP Activeメッセージが受信されているとき、「拒否されました--管理ブロッキング」という誤りを送ります、そして、管理理由(例えば、管理ロックアウト)で要求を拒否します。
Morneault, et al. Standards Track [Page 40] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[40ページ]。
The "ASP Identifier Required" is sent by an SG in response to an ASP Up message that does not contain an ASP Identifier parameter when the SG requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier.
「必要であるASP識別子」はSGが1を必要とするときASP Identifierパラメタを含まないASP Upメッセージに対応してSGによって送られます。 ASP SHOULDはASP IdentifierがあるASP Upメッセージを再送します。
The "Invalid ASP Identifier" is sent by a SG in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
すなわち、「無効のASP識別子」が病人がいるASP Upメッセージに対応してSGによって送られる、(非、ユニークである、)、ASP Identifier。
Diagnostic Information: variable length
診断情報: 可変長
When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in
identification of the error condition. The Diagnostic information
SHOULD contain the offending message.
含まれていると、任意のDiagnostic情報は、エラー条件の識別を助けるためにはエラー条件に適切などんな情報であるかもしれません。 Diagnostic情報SHOULDは腹立たしいメッセージを含んでいます。
Error messages MUST NOT be generated in response to other Error messages.
他のErrorメッセージに対応してエラーメッセージを生成してはいけません。
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同輩に供給していました。
The Notify message will use only the common message header. The Notify message contains the following parameters:
Notifyメッセージは一般的なメッセージヘッダーだけを使用するでしょう。 Notifyメッセージは以下のパラメタを含んでいます:
Status (Mandatory)
ASP Identifier (Optional)
Interface Identifiers (Optional)
INFO String (Optional)
状態の(義務的)のASP識別子(任意)のインタフェース識別子(任意の)インフォメーションストリング(任意)です。
The format for the Notify message with integer-formatted Interface Identifiers is as follows:
整数でフォーマットされたInterface IdentifiersがあるNotifyメッセージのための形式は以下の通りです:
Morneault, et al. Standards Track [Page 41] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[41ページ]。
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 = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x000d| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態タイプ| 状態識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0011| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×1=整数)にタグ付けをしてください。| 長さ| インタフェース..識別子| (0×8=整数範囲)にタグ付けをしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop1*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Start2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子Stop2*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StartN*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース識別子StopN*| 追加..インタフェース..識別子..パラメタ..タグ..タイプ..0×1..0×8| タグ=0x0004| 長さ| インフォメーション..ストリング
Morneault, et al. Standards Track [Page 42] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[42ページ]。
The format for the Notify message with text-formatted Interface Identifiers is as follows:
テキストでフォーマットされた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 = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x000d| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態タイプ| 状態識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0011| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×3=ストリング)にタグ付けをしてください。| 長さ| インタフェース..識別子..追加..インタフェース..識別子..パラメタ..タグ..タイプ..0×3| タグ=0x0004| 長さ| インフォメーション..ストリング
Status Type: 16 bits (unsigned integer)
状態タイプ: 16ビット(符号のない整数)
The Status Type parameter identifies the type of the Notify
message. The following are the valid Status Type values:
Status TypeパラメタはNotifyメッセージのタイプを特定します。 ↓これは有効なStatus Type値です:
1 Application Server State Change (AS-State_Change)
2 Other
1 アプリケーション・サーバー州の変化(状態_変化としての)2もう一方
Status Information: 16 bits (unsigned integer)
状態情報: 16ビット(符号のない整数)
The Status Information 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
Information values are used:
Status情報パラメタはStatus Typeの値に基づいて通知のための、より詳細な情報を含んでいます。 Status TypeがAS状態_Changeであるなら、以下のStatus情報値は使用されています:
Morneault, et al. Standards Track [Page 43] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[43ページ]。
1 reserved
2 Application Server Inactive (AS-INACTIVE)
3 Application Server Active (AS-ACTIVE)
4 Application Server Pending (AS-PENDING)
1 予約された2Application Server Inactive(AS-INACTIVE)3Application Server Active(AS-ACTIVE)4Application Server Pending(-、未定である、)
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
3 ASP Failure
AS2Alternate ASP Active3ASP Failureでアクティブな値の記述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 ASP-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. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SG is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.
これらの通知はASPの州の変化を報告するSGかASに基づいていません。 Insufficient ASP Resources場合では、SGは、ASで別のASPがAS(負荷分割法モード)の荷重を扱うのに必要であることをASP-INACTIVE ASPに示しています。 Alternate ASP Activeケースにおいて、ASPは代替のASPがいつOver-乗りのモードでASP-ACTIVE状態に移行するかを知らされます。 Alternate ASPのASP Identifier(利用可能であるなら)をメッセージに置かなければなりません。 ASP Failureケースのために、SGは、ASでASPの1つがASP-DOWNに移行したのをASPに示しています。 失敗したASPのASP Identifier(利用可能であるなら)をメッセージに置かなければなりません。
The format and description of the optional ASP Identifier are the same as for the ASP Up message (see Section 3.3.2.1). The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5).
セクション3.3を見てください。任意のASP Identifierの形式と記述がASP Upメッセージのように同じである、(.2 .1)。 セクション3.3を見てください。任意のInterface IdentifiersとINFO Stringパラメタの形式と記述がASP Activeメッセージのように同じである、(.2 .5)。
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
統合ISDN Layer2/3モデル(例えば、伝統的なISDNスイッチの)では、Q.921 LayerのためのLayer ManagementとQ.931層が共同見つけられていると思われます。 ISDNをbackhaulingするとき、この仮定は必ず有効であるというわけではありません。 TEI Statusメッセージ
Morneault, et al. Standards Track [Page 44] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[44ページ]。
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.
2つのLayer Management実体にTEIの状態を伝えさせてください。 さらに、TEIが使用中であることを知っているのに、ASPは、データ・リンク設立のコントロールにASPがありたいなら合図するために端末(IUA Establishメッセージを通した)にデータリンクを確立するようSGに要求できます。 手順がASPのLayer Managementが準備できるところにあるTEI Statusの別の使用は、そのTEIにデータリンクの確立を与えられたTEIからの/にシグナリングを送るか、または受けて、確認するか、または確かめます。 例えば、データリンクがTEIのために確立されるなら、ASPが知らなかったのは割り当てられました、とASPがそれが割り当てられたかどうか、またはシグナリングメッセージには誤りがあったかを確認するためにチェックできます。 また、TEIが使われなくなっているのを知っていて、ASPは、そのTEIにデータリンクを確立するようSGに要求する必要はありません。
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 = 0x0010 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ=0x0010| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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が考えられるということです。
3.3.3.4. TEI Query Message (Request)
3.3.3.4. TEI質問メッセージ(要求)
The TEI Query message is sent by the ASP to query the TEI(s). This message consists of the common header and IUA header. The DLCI in the IUA header MUST be ignored by the SG. The SG will respond to this message with TEI Status Indication(s).
TEI Queryメッセージは、TEI(s)について質問するためにASPによって送られます。 このメッセージは一般的なヘッダーとIUAヘッダーから成ります。 SGはIUAヘッダーのDLCIを無視しなければなりません。 SGはTEI Status Indication(s)と共にこのメッセージに応じるでしょう。
Morneault, et al. Standards Track [Page 45] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[45ページ]。
4. Procedures
4. 手順
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
4.1. セクション1.4.1における支援活動への手順
These procedures achieve the IUA layer's "Transport of Q.921/Q.931 boundary primitives" 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層へ呼び出す必要があります。
4.2. Procedures to Support Service in Section 1.4.2
4.2. セクション1.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. 層の管理基関数手順
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 setup is complete. An M-SCTP ESTABLISH indication is sent to Layer Management upon successful completion of an incoming SCTP association setup from a peer IUA node.
Layer ManagementからのM-SCTP ESTABLISH要求はSCTP協会の設立を開始するでしょう。 開始している協会セットアップが完全であるときに、Layer Managementに送られるでしょうM-SCTP ESTABLISHが、確認する。 入って来るSCTP協会セットアップの無事終了のときにM-SCTP ESTABLISH指示を同輩IUAノードからLayer Managementに送ります。
Morneault, et al. Standards Track [Page 46] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[46ページ]。
An M-SCTP RELEASE request from Layer Management will initiate the teardown 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 teardown 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 INACTIVEが要求するよう要求します、そして、M ASP DOWNが、要求する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に示します。
Upon receipt of an 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同輩管理メッセージの領収書
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出来事に基づいて発生できます。
Morneault, et al. Standards Track [Page 47] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[47ページ]。
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
4.3. セクション1.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
* Local Management intervention
* SCTP層の*地方のManagement介入からの指摘のAS*レセプションにおける他のASPにおける同輩IUA層からのいくつかのメッセージのそのASP*レセプションにおける同輩IUA層からのメッセージのレセプション
The ASP state transition diagram is shown in Figure 6. The possible states of an ASP are the following:
ASP状態遷移ダイヤグラムは図6で見せられます。 ASPの可能な州は以下です:
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同輩は手があいています、そして、アプリケーション交通は活発です。
Morneault, et al. Standards Track [Page 48] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[48ページ]。
+--------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +--------------+
| Takeover | ^ |
| | ASP | | ASP Inactive /
| | Active | | ASP Up
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI /
SCTP RI | | v SCTP RI
| +--------------+
+--------------------->| |
| ASP-DOWN |
+--------------+
+--------------+ +----------------------| | | 補欠+-------| ASPアクティブです。| | ASP| +--------------+ | 接収| ^ | | | ASP| | ASP不活発な/| | アクティブ| | ASPは上昇します。| | | v| | +--------------+ | | | | | +------>| ASP不活発です。| | +--------------+ | ^ | /へのASP| ASP| | / SCTP CDI/の下側へのASP| 上がる| | SCTP CDI / SCTPロードアイランド| | SCTP RIに対して| +--------------+ +--------------------->|、|、| 下にASP| +--------------+
Figure 6. ASP State Transition Diagram
図6。 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通知として理解されています。
SCTP RI: The local SCTP layer's Restart indication to the upper layer protocol (IUA) on an SG. The local SCTP will send this indication when it detects a restart from the ASP's peer SCTP layer.
SCTPロードアイランド: SGの上のプロトコル(IUA)上側の層への地方のSCTP層のRestart指示。 それがASPの同輩SCTP層から再開を検出するとき、地方のSCTPはこの指示を送るでしょう。
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の州は出来事のため変化します。 これらの出来事は以下を含んでいます:
* ASP state transitions
* Recovery timer triggers
* ASP状態遷移*回復タイマ引き金
Morneault, et al. Standards Track [Page 49] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[49ページ]。
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 50] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[50ページ]。
+----------+ one ASP trans to ASP-ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state
+----------+ 1つのASP、移-、ASP-ACTIVE+-------------+ | -|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| -| | 不活発| | アクティブ| | | <、-、--、|、| +----------+ \ +-------------+ ^ | \Tr満期、^| | | \、少なくとも1| | | | ASP不活発の\ASP| | | | \ | | | | \ | | | | \ | | 1つのASP| | すべてのASP\1つ、ASP| | 最後のACTIVE、移-| | 移-、\、移-| | ASP、移-| | 下にASP-------\ASP| | ASP不活発なASP| | \アクティブです。| | または、不活発な状態でASPでダウンしてください。| | \ | | (スタートTr) | | \ | | | | \ | | | \に対して| +に対して----------+ \ +-------------+ | | --| | | 下に| | -、未定| | | | (待ち行列) | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +----------+ Tr Expiryにもかかわらず、ASPがありません+。-------------+ ASP-INACTIVE状態で
Tr = Recovery Timer
Trは回復タイマと等しいです。
Figure 7: AS State Transition Diagram
図7: 状態遷移ダイヤグラムとして
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 in the state ASP-DOWN.
SCTP協会の設立の前に、SGとASPの両方の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、層がそうするIUAからの最後のSCTP-コミュニケーションUp確認プリミティブのレセプションでは、原始のM-SCTP ESTABLISHを呼び出してください。Layer Managementに確認します。
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 51] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[51ページ]。
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を使用することでSCTP協会の状態を伝えることができます。_STATUS基関数。
If the Layer Management on SG or ASP wants to bring down an SCTP association for management reasons, it 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-COMMUNICATION_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協会使用を復職させようとするかもしれません。
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered by its IUA peer to be in the ASP-DOWN state. The ASP, if it is to recover, must begin any recovery with the ASP Up procedure.
ASPのSCTP-RESTART指示の場合では、現在、ASPがASP-DOWN状態にあるとIUA同輩によって考えられます。 回復するつもりであるなら、ASPはASP Up手順に従ったどんな回復も始めなければなりません。
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 Procedures
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 message. This action MAY be initiated at the ASP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an IUA management function.
ASPが首尾よくSCTP協会をSGに設立した後に、SGは、ASPがASP Upメッセージを送るのを待っています、ASP IUA同輩が手があいているのを示して。 いつもASPはASP Upメッセージの創始者です。 この動作は、Layer ManagementからのM ASP_UPによる要求原始のASPで開始されるか、またはIUA管理機能によって自動的に開始されるかもしれません。
Morneault, et al. Standards Track [Page 52] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[52ページ]。
When an ASP Up message is received at an SG and internally the remote ASP is in the ASP-DOWN state and not considered locked out for local management reasons, the SG marks the remote ASP in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive. If the SG is aware, via current configuration data, which Application Servers the ASP is configured to operate in, the SG updates the ASP state to ASP-INACTIVE in each AS that it is a member.
SGにASP Upメッセージを受け取って、リモートASPが内面的にASP-DOWN状態にあって、現地管理職者理由でロックされているのは考えられないとき、SGが州のASP-INACTIVEでリモートASPをマークして、M ASP_Upが指示原始的にLayer Managementに知らせます。 SGが意識しているなら、現在のコンフィギュレーション・データ、Application Servers ASPが作動するために構成されるもの、SGアップデートを通したASPは、各ASにそれがメンバーであるとASP-INACTIVEに述べます。
Alternatively, the SG may move the ASP into a pool of Inactive ASPs available for future configuration within Application Server(s), determined in a subsequent ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SG should save the ASP Identifier for that ASP. The SG MUST send an ASP Up Ack message in response to a received ASP Up message even if the ASP is already marked as ASP-INACTIVE at the SG.
あるいはまた、SGはApplication Server(s)の中の将来の構成に利用可能なInactive ASPのプールの中にASPを引っ越すかもしれません、その後のASP Active手順で、断固としています。 ASP UpメッセージがASP Identifierを含んでいるなら、SGはそのASPのためにASP Identifierを取っておくはずです。 ASPがASP-INACTIVEとして既にSGにマークされても、SG MUSTは受信されたASP Upメッセージに対応してASP Up Ackメッセージを送ります。
If for any local reason (e.g., management lockout) the SG cannot respond with an ASP Up Ack message, the SG responds to an ASP Up message with an Error message with reason "Refused - Management Blocking".
SGがどんなローカルの理由(例えば、管理ロックアウト)でもASP Up Ackメッセージで応じることができないなら、SGは「管理が立ち塞がって、拒否された」理由があるErrorメッセージでASP Upメッセージに応じます。
At the ASP, the ASP Up Ack message received is not acknowledged. Layer Management is informed with an M-ASP_UP confirm primitive.
ASPでは、Up Ackメッセージが受けたASPは承認されません。 知らされる層のManagementはM ASP_UPと共に基関数を確認します。
When the ASP sends an ASP Up message, it starts timer T(ack). If the ASP does not receive a response to an ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication.
ASPがASP Upメッセージを送るとき、それはタイマT(ack)を始動します。 ASPがT(ack)の中のASP Upメッセージへの応答を受けないなら、それがASP Up Ackメッセージを受け取るまで、ASPは、T(ack)を再開して、ASP Upにメッセージを再送するかもしれません。 T(ack)は2秒のデフォルトで支給可能です。 あるいはまた、ASP Upメッセージの「再-トランスミッション」はLayer Managementのコントロールの下で置かれるかもしれません。 この方法で、T(ack)の満期は、負の符号表示を運びながら、原始的に_UPが確認するM ASPをもたらします。
The ASP must wait for the ASP Up Ack message before sending any other IUA messages (e.g., ASP Active). If the SG receives any other IUA messages before an ASP Up message is received (other than ASP Down; see Section 4.3.3.2), the SG MAY discard them.
いかなる他のIUAメッセージ(例えば、ASP Active)も送る前に、ASPはASP Up Ackメッセージを待たなければなりません。 ASP Downを除いて; セクション4.3を見てください。ASP Upメッセージが受信されている前にSGが他のIUAメッセージを受け取る、(.3 .2、)SG MAYはそれらを捨てます。
If an ASP Up message is received and internally the remote ASP is in
the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as
an Error message ("Unexpected Message"), and the remote ASP state is
changed to ASP-INACTIVE in all relevant Application Servers.
ASP Upメッセージが受信されていて、リモートASPがASP-ACTIVE状態に本質的にあるなら、Errorメッセージ(「予期していなかったメッセージ」)と同様にASP Up Ackメッセージを返します、そして、遠く離れたASP状態はすべての関連Application ServersでASP-INACTIVEに変わります。
If an ASP Up message is received and internally the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and no further action is taken.
ASP Upメッセージが受信されていて、リモートASPがASP-INACTIVE状態に本質的に既にあるなら、ASP Up Ackメッセージを返します、そして、さらなる行動を全く取りません。
Morneault, et al. Standards Track [Page 53] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[53ページ]。
4.3.3.2. ASP Down Procedures
4.3.3.2. ASP下に手順
The ASP will send an ASP Down message to an SG when the ASP wishes to be removed from the list of ASPs in all Application Servers that it is a member and no longer receive any IUA QPTM or ASPTM messages. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management or MAY be initiated automatically by an IUA management function.
ASPはASPをすべてのApplication ServersでASPのリストから取り除かれたいSGにASP Downメッセージを送るでしょう。それは、メンバーであり、もういずれもIUA QPTMかASPTMメッセージを受け取りません。 この動作は、Layer ManagementからのM ASP_DOWNによる要求原始のASPで開始されるか、またはIUA管理機能によって自動的に開始されるかもしれません。
Whether the ASP is permanently removed from an AS is a function of configuration management.
永久にASからASPを免職するかどうかが、構成管理の機能です。
The SG marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP.
SGはASP-DOWNとしてASPをマークして、M ASP_Downが指示原始的にLayer Managementに知らせて、ASP Down AckメッセージをASPに返します。
The SG MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as ASP-DOWN at the SG.
ASPがASP-DOWNとして既にSGにマークされても、SG MUSTはASPからの受信されたASP Downメッセージに対応してASP Down Ackメッセージを送ります。
At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself as in the ASP-DOWN state. If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
ASPでは、Down Ackメッセージが受けたASPは承認されません。 知らされる層のManagementはM ASP_DOWNと共に基関数を確認します。 ASPがASP Downメッセージを送らないでASP Down Ackを受けるなら、ASPは現在、ASP-DOWN状態のようにそれ自体を考えるべきです。 ASPが以前にASP-ACTIVEかASP-INACTIVE状態にあるなら、ASPは、それ自体を先に返すために手順に着手するでしょうに。
When the ASP sends an ASP Down message, it starts timer T(ack). If the ASP does not receive a response to an ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication.
ASPがASP Downメッセージを送るとき、それはタイマT(ack)を始動します。 ASPがT(ack)の中のASP Downメッセージへの応答を受けないなら、それがASP Down Ackメッセージを受け取るまで、ASPは、T(ack)を再開して、ASP Downにメッセージを再送するかもしれません。 T(ack)は2秒のデフォルトで支給可能です。 あるいはまた、ASP Downメッセージの「再-トランスミッション」はLayer Managementのコントロールの下で置かれるかもしれません。 この方法で、T(ack)の満期は、負の符号表示を運びながら、原始的に_DOWNが確認するM ASPをもたらします。
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に通知します。
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から来ると思われます。
Morneault, et al. Standards Track [Page 54] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[54ページ]。
4.3.3.4. ASP Active Procedures
4.3.3.4. ASPのアクティブな手順
Any time after the ASP has received an ASP Up Ack from the SG, the ASP sends an ASP Active message to the SG indicating that the ASP is ready to start processing traffic. This action MAY be initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer Management or MAY be initiated automatically by an IUA management function. 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が交通を処理する準備ができ始めるのを示すSGにASP Activeメッセージを送ります。 この動作は、Layer ManagementからのM ASP_ACTIVEによる要求原始のASPで開始されるか、またはIUA管理機能によって自動的に開始されるかもしれません。 ASPが1Application ServerのためにSCTP協会の向こう側に交通を処理するために構成されるか、または登録される場合では、ASPACは、ASPACがどのApplication Serversに関して適用するかを示すために1Interface Identifiersを含んでいます。
If the Application Server can be successfully activated, the SG responds to the ASP with an ASPAC Ack message acknowledging that the ASPAC message was received and starts sending traffic for the Application Server to that ASP.
Application Serverが首尾よく動くことができるなら、SGはASPACメッセージが受け取られたと認めながらASPAC AckメッセージでASPにこたえて、Application ServerのためにそのASPに交通を送り始めます。
In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently discarded.
「青の外」というASP Activeメッセージが受信されている(すなわち、ASPがSGとともに記名していないか、またはSGにはASPのためのどんな静的なコンフィギュレーション・データもありません)場合では、メッセージは静かに捨てられるかもしれません。
The SG MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SG.
SG MUSTはASPからの受信されたASP Activeメッセージに対応してASP Active Ackメッセージを送ります、ASPがASP-ACTIVE状態で既にSGにマークされるなら。
At the ASP, the ASP Active Ack message received is not acknowledged. Layer Management is informed with an M-ASP_ACTIVE confirm primitive. It is possible for the ASP to receive Data message(s) before the ASP Active Ack message as the ASP Active Ack and Data messages from an SG may be sent on different SCTP streams. Message loss is possible as the ASP does not consider itself in the ASP-ACTIVE state until reception of the ASP Active Ack message.
ASPでは、Active Ackメッセージが受けたASPは承認されません。 知らされる層のManagementはM ASP_ACTIVEと共に基関数を確認します。 SGからのASP Active AckとDataメッセージとしてのASP Active Ackメッセージを異なったSCTPの流れに送るかもしれない前にASPがDataメッセージを受け取るのは、可能です。ASPがASP-ACTIVE状態でASP Active Ackメッセージのレセプションまでそれ自体を考えないとき、メッセージの損失は可能です。
When the ASP sends an ASP Active message, it starts timer T(ack). If the ASP does not receive a response to an ASP Active message within T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M- ASP_ACTIVE confirm primitive carrying a negative indication.
ASPがASP Activeメッセージを送るとき、それはタイマT(ack)を始動します。 ASPがT(ack)の中のASP Activeメッセージへの応答を受けないなら、それがASP Active Ackメッセージを受け取るまで、ASPは、T(ack)を再開して、ASP Activeにメッセージを再送するかもしれません。 T(ack)は2秒のデフォルトで支給可能です。 あるいはまた、ASP Activeメッセージの「再-トランスミッション」はLayer Managementのコントロールの下で置かれるかもしれません。 この方法で、T(ack)の満期は負の符号表示を運ぶM ASP_ACTIVE確認プリミティブをもたらします。
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 Active Ackメッセージを待たなければなりません。 ASP Activeが受け取られている前にSGがQPTMメッセージを受け取るなら、SG SHOULDはこれらのメッセージを捨てます。
Morneault, et al. Standards Track [Page 55] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[55ページ]。
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にあります: オーバーライドと負荷分割法。 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 Active AckメッセージでASPACに応じます。 ASのどんな以前に活動的なASPも、現在、Inactiveであると考えられて、もうASの中のSGからの交通を受けないでしょう。 SGはNotify(ASP Activeを交替する)を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 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 an ASP Active Ack message to the ASP.
負荷シェアモードASの場合では、SGのASPACメッセージのレセプションはASPACを送るASPに交通の指示を引き起こします、他のすべての現在ASで活動的なASPに加えて。 すべての活動的なASPへのASの中の負荷分割法交通へのSGのアルゴリズムは実現に依存しています。 Interface Identifierなどのように、アルゴリズムは、例えば、丸いコマドリであることができた、またはDataメッセージの情報に基づいてASのアプリケーションの要件とASPの収集の呼び出し状態取り扱い前提によっています。 SGはASPへのASP Active AckメッセージでASPACに応じます。
4.3.3.5. ASP Inactive Procedures
4.3.3.5. ASPの不活発な手順
When an ASP wishes to withdraw from receiving traffic within an AS, the ASP sends an ASP Inactive message to the SG. This action MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an IUA management function. 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 ASP Inactive message applies.
ASPがASの中で交通を受けるのから引き下がりたがっているとき、ASPはASP InactiveメッセージをSGに送ります。 この動作は、Layer ManagementからのM ASP_INACTIVEによる要求原始のASPで開始されるか、またはIUA管理機能によって自動的に開始されるかもしれません。 ASPが1Application ServerのためにSCTP協会の向こう側に交通を処理するために構成されるか、または登録される場合では、ASPIAは、ASP Inactiveメッセージがどの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. 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 message, the ASP that sends the ASPIA message is already considered by the SG to be ASP-INACTIVE. An ASPIA Ack message is sent to the ASP, after ensuring that all traffic is stopped to the ASP.
サービスからASPを撤退するとき、Application Server交通取り扱いの2つの方法がSG IUAにあります: オーバーライドと負荷分割法。 Over-乗りのモードASの場合では、ASPIAメッセージを送るASPはSGによって既にASP-INACTIVEであると考えられます。(通常、そこでは、別のASPがASの中でOver-乗りのASPACメッセージで既に交通を引き継ぎました)。 すべての通行がASPに止められるのを確実にした後に、ASPIA AckメッセージをASPに送ります。
Morneault, et al. Standards Track [Page 56] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[56ページ]。
In the case of a Load-share mode AS, the SG moves the ASP to the ASP-INACTIVE state and the AS traffic is re-allocated across the remaining ASP-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 Notify (Insufficient ASPs) message MAY be sent to all inactive ASPs, if required.
Load-シェアモードASの場合では、SGはASPをASP-INACTIVE状態に動かします、そして、AS交通は現在ASの中で使用されている負荷分割法アルゴリズムあたりの残っているASP-ACTIVE ASPの向こう側に再割当てされます。 すべての交通をASPに止めた後にASPIA AckメッセージをASPに送ります。 必要なら、Notify(不十分なASP)メッセージをすべての不活発なASPに送るかもしれません。
When the ASP sends an ASP Inactive message it starts timer T(ack). If the ASP does not receive a response to an ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in a M- ASP_Inactive confirm primitive carrying a negative indication.
ASPがASP Inactiveメッセージを送るとき、それはタイマT(ack)を始動します。 ASPがT(ack)の中のASP Inactiveメッセージへの応答を受けないなら、それがASP Inactive Ackメッセージを受け取るまで、ASPは、T(ack)を再開して、ASP Inactiveにメッセージを再送するかもしれません。 T(ack)は2秒のデフォルトで支給可能です。 あるいはまた、ASP Inactiveメッセージの「再-トランスミッション」はLayer Managementのコントロールの下で置かれるかもしれません。 この方法で、T(ack)の満期は負の符号表示を運ぶM ASP_Inactive確認プリミティブをもたらします。
If no other ASPs in the Application Server are in the state
ASP-ACTIVE, the SG MUST send a Notify ("AS-Pending") message to all
of the ASPs in the AS that are in the state ASP-INACTIVE. The SG
SHOULD start buffering the incoming messages for T(r) seconds, after
which messages MAY be discarded. T(r) is configurable by the network
operator. If the SG receives an ASP Active message from an ASP in
the AS before expiry of T(r), the buffered traffic is directed to
that ASP and the timer is cancelled. If T(r) expires, the AS is
moved to the AS-INACTIVE state.
Application Serverの他のASPが全く州のASP-ACTIVEにないなら、SG MUSTがNotifyを送る、(「-、未定である、」、)、州のASP-INACTIVEにあるASのASPのすべてへのメッセージ。 SG SHOULDはT(r)秒の間、入力メッセージをバッファリングし始めます。(その時、メッセージは捨てられたかもしれません後)。 T(r)はネットワーク・オペレータが構成可能です。 SGがT(r)の満期の前にASのASPからASP Activeメッセージを受け取るなら、バッファリングされた交通はそのASPに向けられます、そして、タイマは取り消されます。 T(r)が期限が切れるなら、ASはAS-INACTIVE状態に動かされます。
At the ASP, the ASP Inactive Ack message received is not acknowledged. Layer Management is informed with an M-ASP_INACTIVE confirm primitive. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP should now consider itself as in the ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
ASPでは、Inactive Ackメッセージが受けたASPは承認されません。 知らされる層のManagementはM ASP_INACTIVEと共に基関数を確認します。 ASPがASP Inactiveメッセージを送らないでASP Inactive Ackを受けるなら、ASPは現在、ASP-INACTIVE状態のようにそれ自体を考えるべきです。 ASPが以前にASP-ACTIVE状態にあるなら、ASPは、それ自体を先に返すために手順に着手するでしょうに。
4.3.3.6. Notify Procedures
4.3.3.6. 手順に通知してください。
A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack).
AS状態の変化を反映するNotifyメッセージをASのすべてのASPに送らなければなりません、ASP-DOWN状態のそれらを除いて、失敗したASPの適切なStatus情報とどんなASP Identifierと共にも。 ASPでは、Layer ManagementはM-NOTIFY指示プリミティブで知識があります。 AS州の変化がASP州Management(ASPSM)/ASP Traffic Management(ASPTM)メッセージのASP失敗かレセプションの結果であったか否かに関係なく、Notifyメッセージを送らなければなりません。 2番目の場合では、いずれも確認メッセージ(例えば、ASP Up Ack、ASP Down Ack(ASP Active Ack)またはASP Inactive Ack)について話した後にNotifyメッセージを送らなければなりません。
Morneault, et al. Standards Track [Page 57] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[57ページ]。
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 compel the ASP(s) receiving the message to become
active. The ASPs remain in control of what (and when) action is
taken.
中、ケースどこa Notify、(「-、未定である、」、)、メッセージが現在ASPを全く交通を修理するためにアクティブにしないSGによって送られるか、Load-シェアモードでNTFY(「不十分なASP」)を送って、または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手順は用いられるかもしれません。
Either IUA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat). Upon receiving a Heartbeat message, the IUA peer MUST respond with a Heartbeat Ack message.
どちらのIUA同輩も定期的に任意に支給可能タイマTを条件としてメッセージをHeartbeatに送るかもしれません(打ってください)。 Heartbeatメッセージを受け取ると、IUA同輩はHeartbeat Ackメッセージで応じなければなりません。
If no Heartbeat Ack message (or any other IUA message) is received from the IUA peer within 2*T(beat), the remote IUA peer is considered unavailable. Transmission of Heartbeat messages is stopped and the signaling process SHOULD attempt to re-establish communication if it is configured as the client for the disconnected IUA peer.
2*Tの中のIUA同輩からHeartbeat Ackメッセージ(または、いかなる他のIUAメッセージも)を全く受け取らないなら(打ってください)、入手できないとリモートIUA同輩を考えます。 Heartbeatメッセージの伝達は止められます、そして、それが外されたIUA同輩のためのクライアントとして構成されるなら、シグナリングの過程SHOULDはコミュニケーションを復職させるのを試みます。
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 6, "ASP State Transition Diagram".
以下に注意してください。 鼓動関連の出来事は図6に示されて、「ASPは変遷ダイヤグラムを述べる」ということではありません。
5. Examples
5. 例
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 setup.
このシナリオは、例のIUAメッセージが1つのASPだけがAS(バックアップがない)の中で構成されるSGとASPの間の交通の確立のために流れるのを示します。 SCTP協会が既にセットアップであると思われます。
Morneault, et al. Standards Track [Page 58] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[58ページ]。
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|-----NTFY(AS-INACTIVE)--->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|
| |
SG ASP1| | <、-、-、-、-、-、-、-、--ASPは上昇します。----------| |--------AckへのASP------->|、|、| |-----NTFY、(-、不活発である、)--->|、|、| | <、-、-、-、-、-、--ASPアクティブです。--------| |------ASPのアクティブなAck----->|、|、| |------NTFY(能動態としての)---->|、|、|
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 ActiveメッセージがOver-乗りかLoad-シェアモードであるか否かに関係なく、同じです。
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
SG ASP1 ASP2| | | | <、-、-、-、-、-、-、--ASPは上昇します。----------| | |-------AckへのASP------->|、|、|、|、| |----NTFY、(-、不活発である、)--->|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPは上昇します。----------------| |----------------------------AckへのASP------------->|、|、|、|、|、|、| | <、-、-、-、-、-、--ASPアクティブです。-------| | |-----ASPのアクティブなAck----->|、|、|、|、| |-----NTFY(能動態としての)---->|、| |----------------------NTFY(能動態としての)-------------->|
Morneault, et al. Standards Track [Page 59] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[59ページ]。
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------>| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
SG ASP1 ASP2| | | | <、-、-、-、-、-、-、-、--ASPは上昇します。---------| | |--------AckへのASP------>|、|、|、|、| |----NTFY、(-、不活発である、)--->|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPは上昇します。---------------| |-----------------------------AckへのASP------------>|、|、|、|、|、|、| | <--ASPのアクティブな(Ldshr)----| | |----ASPのアクティブなAck------>|、|、|、|、| |-----NTFY(能動態としての)---->|、| |----------------------NTFY(能動態としての)-------------->|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--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 60] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[60ページ]。
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|-NTFY(AS-INACTIVE)->| | |
| | | |
|<--------------------------ASP Up-------| |
|-----------------------ASP Up Ack------>| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
|--NTFY(AS-ACTIVE)-->| | |
|---------------NTFY(AS-ACTIVE)--------->| |
|------------------------NTFY(AS-ACTIVE)-------------------->|
SG ASP1 ASP2 ASP3| | | | | <、-、-、-、-、--ASPは上昇します。-------| | | |-----AckへのASP---->|、|、|、|、|、|、| |-NTFY、(-、不活発である、)、->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASPは上昇します。-------| | |-----------------------AckへのASP------>|、|、|、|、|、| |<---------------------------------------------ASPは上昇します。--------| |--------------------------------------------AckへのASP----->|、|、|、|、|、|、|、|、| | <、-ASP条例(Ldshr)---| | | |----ASP条例Ack---->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--ASP条例(Ldshr)---| | |----------------------ASP条例Ack------>|、|、|、|、|、| |--NTFY(能動態としての)-->|、|、| |---------------NTFY(能動態としての)--------->|、| |------------------------NTFY(能動態としての)-------------------->|
5.1.5. Interface Identifier Configuration Mismatch Example
5.1.5. インタフェース識別子構成ミスマッチの例
This scenario shows the example IUA message flows for the establishment of traffic between an SG and an ASP in which some of the Interface Identifiers have been misconfigured on the ASP side. The SG in this case has Interface Identifiers 1-5 configured for ASP1.
このシナリオは、例のIUAメッセージがいくつかのInterface IdentifiersがASP側でmisconfiguredされたSGとASPの間の交通の確立のために流れるのを示します。 SGはこの場合ASP1のためにInterface Identifiers1-5を構成させます。
SG ASP1
| |
| |
|<----ASP Active (IIDs 1-10)-----|
|---ASP Active Ack (IIDs 1-5)--->|
|-------Error (IIDs 6)---------->|
|-------Error (IIDs 7)---------->|
|-------Error (IIDs 8)---------->|
|-------Error (IIDs 9)---------->|
|-------Error (IIDs 10)--------->|
| |
SG ASP1| | | | | <、-、-、--ASPアクティブです(IIDs1-10)。-----| |---ASPのアクティブなAck(IIDs1-5)--->| |-------誤り(IIDs6)---------->| |-------誤り(IIDs7)---------->| |-------誤り(IIDs8)---------->| |-------誤り(IIDs9)---------->| |-------誤り(IIDs10)--------->|、|、|
Morneault, et al. Standards Track [Page 61] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[61ページ]。
5.2. ASP Traffic Fail-over Examples
5.2. ASP交通フェイルオーバーの例
5.2.1. (1+1 Sparing, withdrawal of ASP, Backup Over-ride)
5.2.1. (1+1割くASPの撤退、Backup 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)---->| |
|-------------------NTFY(AS-Pending)---------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| | |
|----NTFY(AS-ACTIVE)----->| |
|-------------------NTFY(AS-ACTIVE)----------------->|
SG ASP1 ASP2| | | | <、-、-、-、--ASP不活発です。-------| | |----ASPの不活発なAck---->|、|、|、|、| |----NTFY、(-、未定である、)---->|、| |-------------------NTFY、(-、未定である、)---------------->|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ASPアクティブです。----------| |-----------------------------ASPのアクティブなAck)------->|、|、|、| |----NTFY(能動態としての)----->|、| |-------------------NTFY(能動態としての)----------------->|
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, Backup Over-ride)
5.2.2. (1+1割くバックアップオーバーライド)
The following example shows a case in which ASP2 wishes to override ASP1 and take over the traffic:
以下の例はASP2がASP1をくつがえして、交通を引き継ぎたがっている場合を示しています:
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に通知します。
Morneault, et al. Standards Track [Page 62] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[62ページ]。
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基関数逆送の例
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に記入してください。
- 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協会)を決定してください。
Morneault, et al. Standards Track [Page 63] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[63ページ]。
- 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)に関する問題があるので、それはシグナリングチャンネルの上にデータ・リンクを設立できません。
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)。
Morneault, et al. Standards Track [Page 64] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[64ページ]。
SG ASP
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<。----------- データは誤り表示を要求します。---------->。(病人_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)
<。----------- TEI状態が確認するTEI状態要求---------->。(割り当てられません)
6. Security
6. セキュリティ
The security considerations discussed in "Security Considerations for SIGTRAN Protocols", RFC 3788 [3], apply to this document.
「SIGTRANプロトコルのためのセキュリティ問題」で議論したセキュリティ問題(RFC3788[3])はこのドキュメントに適用されます。
7. IANA Considerations
7. IANA問題
7.1. SCTP Payload Protocol Identifier
7.1. SCTP有効搭載量プロトコル識別子
The IANA has assigned an IUA value for the Payload Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier has been registered:
IANAは有効搭載量プロトコルIdentifierのためにSCTP有効搭載量Data塊でIUA値を割り当てました。 以下の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.
-- そして、追加メッセージタイプの定義による追加メッセージのクラスの定義で--追加メッセージパラメタの定義で。
The definition and use of new message classes, types, and parameters are an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in [7].
新しいメッセージのクラス、タイプ、およびパラメタの定義と使用はSIGTRAN適合層の不可欠の一部です。 したがって、これらの拡大は[7]で定義されるようにIETF Consensus動作でIANAによって割り当てられます。
Morneault, et al. Standards Track [Page 65] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[65ページ]。
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.
(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) メッセージの中の各分野の意図している使用の詳細な定義と記述。 (d) プロトコルの操作の中の新しいメッセージタイプの使用の詳細な手続き上の記述。 (e) このメッセージタイプを受けるときのエラー条件の詳述。
When an implementation receives a message type that 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 66] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[66ページ]。
8. Timer Values
8. タイマ値
The following are suggestions for default timer values.
↓これはデフォルトタイマ値のための提案です。
T(r) 3-5 seconds T(ack) 2-5 seconds T(beat) Heartbeat Timer 30 seconds
3-5秒T(ack)2-5秒T(打ちます)鼓動Timer30秒のT(r)
9. Acknowledgements
9. 承認
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、およびハンクワングに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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] Coded Character Set--7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[2]コード化文字集合--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[3] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
3788, June 2004.
[3]Loughney、J.、Tuexen、M.、およびJ.牧師-Balbas、「シグナリング輸送(SIGTRAN)プロトコルのためのセキュリティ問題」、RFC3788、2004年6月。
10.2. Informative References
10.2. 有益な参照
[4] 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.
[4] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999.
[5] オング、L.、Rytina、I.、ガルシア、M.、Schwarzbauer、H.、Coene、L.、リン、H.、Juhasz、I.、Holdrege、M.、および鋭く、「シグナリングのためのフレームワークアーキテクチャは輸送する」C.、RFC2719(1999年10月)。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Morneault, et al. Standards Track [Page 67] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[67ページ]。
[8] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[8] ストーン、J.、スチュワート、R.、およびD.オーティス、「ストリーム制御伝動プロトコル(SCTP)チェックサム変化」、RFC3309、2002年9月。
11. Change Log
11. チェンジログ
Below is a list of the major changes between this document and RFC 3057.
以下に、このドキュメントとRFC3057の間には、大きな変化のリストがあります。
1. The TEI Query message was added.
1. TEI Queryメッセージは加えられました。
2. An explanation of the DLCI format (shown in Figure 6) is
provided.
2. DLCI形式(図6では、目立つ)に関する説明を提供します。
3. Aligned the ASP and AS procedures in Section 4 with RFC3331 and
RFC3332.
3. セクション4のASPとAS手順をRFC3331とRFC3332に並べました。
4. Alinged the format of the ASPSM and ASPTM messages with RFC3331
and RFC3332. These changes include removing the Reason field
from the ASP Down and ASP Down Ack messages and the Traffic Mode
Type field from the ASP Inactive and ASP Inactive Ack messages.
4. RFC3331とRFC3332と共にASPSMとASPTMメッセージの形式をAlingedしました。 これらの変化は、ASP InactiveとASP Inactive AckメッセージからASP DownとASP Down AckメッセージからのReason野原とTraffic Mode Type野原を取り除くのを含んでいます。
5. Sections 1.3.3 and 1.3.4 were moved to Appendix A. A new section
was added in place of Section 1.3.3.
5. セクション1.3.3、1.3に、.4はAppendixに動かされて、A.のA新しいセクションが.3にセクション1.3に代わって加えられたということです。
6. The references have been split between Normative and Informative.
6. 参照はNormativeとInformativeの間で分けられました。
7. The new Sigtran security document is referenced and Section 6 has
been updated appropriately.
7. 新しいSigtranセキュリティドキュメントは参照をつけます、そして、適切にセクション6をアップデートしました。
Morneault, et al. Standards Track [Page 68] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[68ページ]。
Appendix A
付録A
A.1. Signaling Network Architecture
A.1。 シグナル伝達ネットワークアーキテクチャ
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 Quality of Service (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機能要素の信頼性によって、Service(QoS)の境界があるIPネットワーク経路の余分なQualityの設備で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 8 below:
IPネットワークドメインでのキャリヤーグレード操作に関連している例の論理的なネットワークアーキテクチャは以下の図8に示されます:
Morneault, et al. Standards Track [Page 69] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[69ページ]。
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Host1************************_________________________________________* ******** * * * _________* * ASP1***SG1*SCTP協会| * ******** * * *_______________________ | * * ******** | | ************** | | ******** | | * *_______________________________| * * | * SG2*SCTP協会| * *____________ | * * | | Host2********| | ************** | |_________________* ******** * |____________________________* * ASP1****************************…
Figure 8. Logical Model Example
エイト環。 論理的なモデルの例
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が、呼び出し状態を共有するか、または互いの間の呼び出し状態を通り過ぎることができる必要であるのを含意します。 しかしながら、このドキュメントの範囲の外に呼び出し状態情報に関するこの共有かコミュニケーションがあります。
A.2. Application Server Process Redundancy
A.2。 アプリケーション・サーバープロセス冗長
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 8, 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の上で利用可能なリストでそうであることはお勧めです。 例えば、図8のネットワークでは、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--上がって、上がって、不活発な状態で=を述べるように述べます。
Morneault, et al. Standards Track [Page 70] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[70ページ]。
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 are 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へのプロトコルがあります。
Morneault, et al. Standards Track [Page 71] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[71ページ]。
Authors' Addresses
作者のアドレス
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 Tridea Works
Selvam Rengasami Trideaは働いています。
Phone: +1-732-512-0969 EMail: selvam@trideaworks.com
以下に電話をしてください。 +1-732-512-0969 メールしてください: selvam@trideaworks.com
Greg Sidebottom Signatus Technologies Kanata, Ontario, Canada
グレッグSidebottom Signatus技術Kanata、オンタリオ(カナダ)
EMail: greg@signatustechnologies.com
メール: greg@signatustechnologies.com
Morneault, et al. Standards Track [Page 72] RFC 4233 ISDN Q.921-User Adaptation Layer January 2006
Morneault、他 規格はISDN Q.921-ユーザ適合層の2006年1月にRFC4233を追跡します[72ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Morneault, et al. Standards Track [Page 73]
Morneault、他 標準化過程[73ページ]
一覧
スポンサーリンク
