Network Working Group R. Mukundan
Request for Comments: 4129 Wipro Technologies
Category: Standards Track K. Morneault
Cisco Systems
N. Mangalpally
Nortel Networks
August 2005
Digital Private Network Signaling System (DPNSS)/
Digital Access Signaling System 2 (DASS 2)
Extensions to the IUA Protocol
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network. DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.
この文書では、ISDNユーザ適応（IUA）が指定され、DPNSS 1 RFC 3057で定義されたプロトコルレイヤ拡張することで、IPを介してデジタルプライベートネットワークシグナリングシステム1（DPNSS 1）およびデジタルアクセス信号システム2（DASS 2）メッセージをバックホールのためのメカニズムを定義しますND1301に：2001/03（旧BTNR 188）、プライベートネットワーク内の構内交換機（PBX）を相互接続するために使用されます。 DASS 2は、BTNR 190で指定され、PSTNへのPBXを接続するために使用されます。この文書では、IUAの付録になることとDPNSS 1 / DASS 2ユーザ適応（DUA）の実装のためのベースであることを目的とします。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. Scope .................................................. 2
1.2. Terminology ............................................ 3
1.3. DPNSS Overview ......................................... 4
1.4. Proposed DPNSS Backhaul Architecture ................... 5
2. Changes from IUA ............................................. 5
2.1. New Message Class for DUA .............................. 5
2.2. Message Header ......................................... 6
2.3. Unit Data Message ...................................... 7
2.4. DLC Status Message ..................................... 7
2.5. Management (MGMT) Messages ............................. 9
3. IANA Considerations .......................................... 10
4. Use of SCTP Payload Protocol ID .............................. 10
5. Message Sequence in DUA ...................................... 11
5.1. Resetting of single DLC ................................ 11
5.2. Resetting all DLCs in a Link ........................... 11
5.3. Information Transfer on a DLC .......................... 12
5.4. Link Takedown (Single DLC) ............................. 12
5.5. Link Takedown (All DLCs) ............................... 12
5.6. Getting Link Status .................................... 12
5.7. Error Conditions ....................................... 12
6. Security Considerations ...................................... 13
7. References ................................................... 13
7.1. Normative References ................................... 13
8. Acknowledgements ............................................. 13
This document describes a method of implementing Digital Private Network Signaling System 1 (DPNSS 1) [2] (henceforth referred to as just DPNSS) and Digital Access Signaling System 2 (DASS 2)[3] backhaul messaging over IP using a modified version of the ISDN User Adaptation Protocol (IUAP) [1]. The DPNSS/DASS 2 User Adaptation (DUA) builds on top of IUA by defining the necessary extensions to IUA for a DPNSS/DASS2 implementation.
この文書では、との修正バージョンを使用して、IPオーバー[3]バックホールメッセージングデジタルアクセス信号システム2（ダス2）（以下のようなだけDPNSS呼ばれる）デジタルプライベートネットワークシグナリングシステム1（DPNSS 1）[2]を実現する方法を記載していますISDNユーザ適合プロトコル（IUAP）[1]。 DPNSS / DASS 2ユーザ適応（DUA）はDPNSS / DASS2実装にIUAに必要な拡張を定義することにより、IUAの上に構築します。
There is a need for Switched Circuit Network (SCN) signaling protocol delivery from a DPNSS Signaling Gateway (SG) to a Media Gateway Controller (MGC). The delivery mechanism should support the following protocols:
メディアゲートウェイコントローラ（MGC）にDPNSSシグナリングゲートウェイ（SG）から回線交換ネットワーク（SCN）シグナリングプロトコルの配信が必要です。配信メカニズムは、次のプロトコルをサポートする必要があります。
- DPNSS (Digital Private Network Signaling System) [2] - DASS 2 (Digital Access Signaling System Number 2) [3]
- DPNSS（デジタルプライベートネットワークシグナリングシステム）[2] - DASS 2（デジタルアクセス信号システムナンバー2）[3]
Unless specifically mentioned, the details in this document are applicable to both DPNSS and DASS 2.
特に言及しない限り、このドキュメントの詳細はDPNSSとDASS 2の両方に適用されています。
Data channel (D-channel) - A 64 kbit/s time slot that functions as a common signaling channel on a 2048 kbits/s interface or a 1544 kbits/s interface that is provisioned to carry DPNSS signaling.
データチャネル（Dチャネル） - 2048キロビット/秒インターフェースまたはDPNSSシグナリングを運ぶためにプロビジョニングされている1544キロビット/秒のインターフェイス上の共通のシグナリングチャネルとして機能する64キロビット/秒のタイムスロット。
DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s interface are termed as DPNSS channels. These are the traffic channels that carry voice or data traffic.
DPNSSチャネル - 1544キロビット/秒インターフェイスで23時間2048人のキロビット/秒のスロット1〜15および31から17へのインタフェースまたはタイムスロット1はDPNSSチャネルとして呼ばれます。これらは、音声またはデータトラフィックを運ぶトラフィックチャネルです。
- DPNSS supports 60 Channels (30 Real and 30 Virtual) - DASS2 supports 30 Channels (All Real)
- DASS2は、30チャンネル（すべての実）をサポート - DPNSSは、60チャンネル（実質30と30の仮想）をサポートしています
Data Link Connection(DLC) - A DLC is the level 2 process that controls the transfer of level 3 messages on behalf of one DPNSS channel. A DLC uniquely identifies one DPNSS channel.
データリンク接続（DLC） - DLC一DPNSSチャネルの代わりにレベル3メッセージの転送を制御するレベル2のプロセスです。 DLC一意1つのDPNSSチャネルを識別する。
- DPNSS supports 60 DLCs (30 Real and 30 Virtual) - DASSII supports 30 DLCs (All Real)
- DPNSSは、60台のDLC（30レアルと30仮想）をサポート - DASSIIは30台のDLC（すべての実）をサポートしています
DPNSS Link - A logical collection of the D-channel and the associated DPNSS channels in a 2048 kbits/s interface or a 1544 kbits/s interface is called a "DPNSS Link".
DPNSSリンク - Dチャネル2048人のキロビット/秒のインタフェースの関連するDPNSSチャネルまたは/ sのインターフェースが「DPNSSリンク」と呼ばれる1544人のキロビットの論理的な集合。
Real channel - A signalling channel with an associated traffic channel (TS).
実チャンネル - 関連するトラフィックチャネル（TS）とのシグナリングチャネル。
Virtual channel - A signalling channel with no associated traffic channel.
仮想チャネル - 無関連するトラフィックチャネルとシグナリングチャネル。
NT1 - The DPNSS minimum retransmission period.
NT1 - DPNSS最小再送期間。
NT2 - The DPNSS minimum post retransmission acknowledgement delay.
NT2 - DPNSS最小ポスト再送確認応答遅延。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[5]。
DPNSS is an industry standard interface (ref. ND1301:2001/03) [2], which is defined between a PBX and an Access Network (AN). DPNSS extends facilities that are normally only available between extensions on a single PBX to all extensions on PBXs that are connected in a private network. DPNSS was originally derived from BT's Digital Access Signaling System I (DASS I), and was enhanced where necessary to meet the private network requirements. Some of these enhancements were incorporated in DASS 2 [3]. DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital Transmission System Interface, as shown in Figure 1 below.
PBXとアクセスネットワーク（AN）との間に画定されている[2]：DPNSSは、業界標準インターフェイス（2001/03。REF ND1301）です。 DPNSSは、プライベートネットワークに接続されているPBX上のすべての拡張機能への単一のPBXの拡張の間、通常のみ利用可能な機能を拡張します。 DPNSSはもともとBTのデジタルアクセス信号システムI（DASS I）から派生した、プライベートネットワークの要件を満たすために、必要に応じて拡張されました。これらの拡張機能の一部はダス2に組み込まれた[3]。以下、図1に示すようにDPNSSは2048キロビット/秒または1544キロビット/秒のデジタル伝送システムインタフェースを使用します。
---------- ---------- o--o
| | 2048 kbits/s | |------- /\
| |--------------| | --
| PBX | 1544 kbits/s | AN |
| |--------------| | o--o
| | | |------- /\
---------- ---------- --
Figure 1
図1
Channel 16 is on a 2048 kbits/s (E1) interface and channel 24 is on a 1544 kbits/s (T1) interface and is reserved for data communication between LE and AN. The channels reserved for data are called "Data Channels" or "D-Channels."
チャネル16は、2048キロビット/秒（E1）インターフェイス上にあり、チャネル24は、1544キロビット/秒（T1）インターフェイス上にあり、LEとANとの間のデータ通信用に予約されています。データ用に予約チャネルは、「データチャネル」または呼ばれ、「Dチャネル」。
The D-Channels are the physical media used to exchange data between the DPNSS protocol peer entities. A logical collection of the D-channel and the associated DPNSS channels is called a "DPNSS Link".
DチャネルはDPNSSプロトコルピアエンティティ間でデータを交換するために使用される物理的な媒体です。 Dチャネル及び関連DPNSSチャネルの論理的な集まりを「DPNSSリンク」と呼ばれています。
****** DPNSS ****** IP *******
*PBX *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|DPNSS| (NIF) |DPNSS|
| L3 | | L3 |
+-----+ +----------+ +-----+
| | | | DUA| | DUA |
|DPNSS| |DPNSS+----+ +-----+
| L2 | | L2 |SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
NIF - Nodal Interworking function SCTP - Stream Control Transmission Protocol DUA - DPNSS User Adaptation Layer Protocol
NIF - 節点インターワーキング機能のSCTP - ストリーム制御伝送プロトコルDUA - DPNSSユーザ適合層プロトコル
This section outlines the differences between DUA and IUA.
このセクションでは、DUAとIUAの違いを概説します。
The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be identifiable from IUA boundary primitive transport messages and the boundary primitive transport messages of other IUA extensions (i.e., V5 or GR-303). Therefore, it is necessary to use a different message class parameter for DUA messages.
3つのプリミティブを層にDPNSS / DASS2レイヤ2 [2] [3] IUAから識別可能である必要がプリミティブ輸送メッセージ及び他のIUA拡張（すなわち、V5又はGR-303）の境界プリミティブ輸送メッセージを境界。したがって、DUAメッセージに異なるメッセージクラスパラメータを使用する必要があります。
For all DPNSS/DASS2 interface boundary primitives, a new Message Class is introduced:
すべてDPNSS / DASS2インターフェース境界プリミティブのために、新しいメッセージクラスが導入されています。
13 DPNSS/DASS2 Boundary Primitives Transport Messages
(DPTM)
Similar to IUA, other valid message classes for DUA are:
IUAと同様に、DUAのための他の有効なメッセージクラスは次のとおりです。
0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
The IUA Message Header [1] MUST be used with the DPTM messages, but the DLCI field in the DLCI parameter is formatted differently. Figure 2 below shows the IUA Message Header with integer-based Interface Identifier.
IUAメッセージヘッダ[1] DPTMメッセージと共に使用されなければならないが、DLCIパラメータのDLCIフィールドは異なるフォーマットされています。図2は、以下整数ベースのインタフェース識別子とIUAメッセージヘッダを示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 IUA Message Header (integer-based Interface Identifier)
図2 IUAメッセージヘッダ（整数ベースのインタフェース識別子）
In DUA, the DLCI field has a different format, in accordance with the ND1301:2001/03 (formerly BTNR 188) [2].
DUAにおいて、DLCIフィールドはND1301に応じて、異なるフォーマットを有する：2001/03（旧BTNR 188）[2]。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |V|0|Channel No.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 7 bits
予約：7ビット
Should be set to all '0's and ignored by the receiver.
すべての「0に設定され、受信機によって無視されるべきです。
V-bit: 1 bit
V-ビット：1ビット
The V-bit is used to determine if the message is for a particular DLC or if it is applicable for all the DLCs in the carrier. The possible values of the V-bit are listed below:
Vビットは、メッセージが特定のDLCまたは、それは担体内のすべてのDLCに適用可能である場合であるかどうかを決定するために使用されます。 Vビットの可能な値を以下に列挙する。
Value Description
0 Action is to be performed on all DLCs;
Channel number parameter is ignored.
1 Action is to be performed on a single
DLC specified by channel number.
This V-bit value is used only by the Establish and Release messages. Data messages should ignore this value. This indicator is provided so that a single command can be issued to establish or release all the DLCs in one DPNSS Link.
このVビットの値のみを確立し、リリースのメッセージで使用されています。データメッセージは、この値を無視する必要があります。単一コマンドは、1つDPNSSリンク内のすべてのDLCを確立または解放するために発行することができるように、この指標が提供されます。
For Channel Number (Channel No.), the valid values are 0 to 63 for DPNSS and 0 to 31 for DASS 2. This is because DASS 2 does not support virtual DLCs and, hence, has only 32 DLCs.
チャネル番号（チャネル番号）のために、有効な値は0これはDASS 2仮想のDLCをサポートしていないためであり、従って、唯一の32のDLCを有するダス2の31にDPNSS 63及び0です。
DPNSS layer 2 does not have a unit data primitive and, hence, the Unit Data Messages (Request, Indication) are invalid for a DUA application. The Data Request and Indication messages (message types 1 and 2, respectively) will be used with DUA.
DPNSS層2は、従って、ユニットデータメッセージ（要求、指示が）DUAアプリケーションの無効で、プリミティブ単位のデータを持っていません。データ要求および指示メッセージ（メッセージタイプそれぞれ1及び2は、）DUAと共に使用されるであろう。
For DUA, a new message is necessary to carry the status of the DLCs. This message will be a Management message (i.e., its message class will be a value of 0 for Management). The following message types will be used for these messages:
DUAのために、新しいメッセージはDLCの状況を運ぶために必要です。このメッセージは、管理メッセージ（すなわち、そのメッセージクラスは、管理のための0の値になる）であろう。次のメッセージの種類は、これらのメッセージのために使用されます。
5 DLC Status Request
6 DLC Status Confirm
7 DLC Status Indication
The DLC Status messages are exchanged between DUA layer peers to request, confirm, and indicate the status of the DLCs. The DLC Status messages contain the common message header, followed by IUA message header, as described in section 2.2.
DLCのステータスメッセージは、要求を確認するためにDUA層ピア間で交換、及びDLCの状況を示しています。 DLCステータスメッセージは、セクション2.2で説明したように、IUAメッセージヘッダに続く共通メッセージヘッダを含みます。
In addition, the DLC Status Confirm and Indication messages will contain the new parameter, called the DLC Status parameter. This parameter will have the following format for an E1 interface:
また、DLCステータスを確認し、指示メッセージは、新しいパラメータが含まれます、DLCステータスパラメータと呼ばれます。このパラメータは、E1インターフェイスには次の形式を持っています。
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 (0x12) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NA stands for Not Applicable. D0 and D16 are not applicable for an E1 interface because timeslot 0 is used for E1 framing and synchronization bits and timeslot 16 is used for signaling. For DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual) and in case of DASS2 there would be a total of 30 DLCs (no virtuals).
NAは該当なしを表します。タイムスロット0はE1フレーミングおよび同期ビットとタイムスロット16のために使用されているため、D0およびD16は、シグナリングのために使用されるE1インターフェイスに適用されません。 DPNSSのために、最大60台のDLC（30仮想+実30）の合計が存在するであろうとDASS2の場合には30台のDLC（NO virtualsを）の合計が存在することになります。
This parameter will have the following format for a T1 interface:
このパラメータは、T1インターフェイスには次の形式を持っています。
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 (0x12) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D23 is not applicable for a T1 interface because timeslot 23 is used for signaling. For DPNSS, there would be a total of max 46 DLCs (23 real + 23 virtual) and in case of DASS2 there would be a total of 23 DLCs (no virtuals).
タイムスロット23は、シグナリングのために使用されているため、D23は、T1インターフェースには適用できません。 DPNSSのために、最大46台のDLC（23仮想+実23）の合計が存在するであろうとDASS2の場合には23台のDLC（NO virtualsを）の合計が存在することになります。
The parameter carries the status of DLCs using two bits for each DLC. The possible values for the two bits are shown below:
パラメータは、各DLCのために2ビットを使用してのDLCの状態を運びます。 2ビットの可能な値を以下に示します。
Value Description
00 Out Of Service
01 Reset Attempted
10 Reset Completed
11 Information Transfer
For DASS 2, the value 00 (Out Of Service) is invalid because the DASS 2 DLC does not have this state. In addition, the Idle state is a transient state local to the DLC, therefore, a value is not allocated for it.
DASS 2 DLCがこの状態を持っていないので、DASS 2に関しては、（アウトオブサービス）値00は無効です。また、アイドル状態がDLCにローカル過渡状態であり、従って、値がそれのために割り当てられていません。
For DASS 2, there are no virtual DLCs and, hence, information about only 32 DLCs need to be carried. Therefore, the status message will have a length of 12 for a DASS 2 DLC Status message.
DASS 2ため、したがってない仮想のDLCとは、存在しない、唯一の32のDLCに関する情報を搭載する必要があります。したがって、ステータスメッセージはDASS 2 DLCステータスメッセージのための12の長さを有するであろう。
Only the Notify and Error messages are valid for DUA. The TEI Status messages are not used.
のみ通知とエラーメッセージがDUAのために有効です。 TEIのステータスメッセージが使用されていません。
The ERR message is sent when an invalid value or unrecognized message is found in an incoming message.
無効な値または認識されないメッセージは、着信メッセージで発見された場合ERRメッセージが送信されます。
The Error Code parameter indicates the reason for the Error Message. These are the supported values in IUA.
エラーコードのパラメータは、エラーメッセージの理由を示します。これらは、IUAでサポートされる値です。
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
無効なTEI、拒否0x0CのSAPIの組み合わせ0x0Bのモード0x05で予期しないメッセージ0x06のプロトコルエラー0x07のサポートされていないインターフェイス識別子タイプ0x08の無効なストリーム識別子0x09の未割り当てTEIの0x0Aを認識できないSAPIの取り扱い無効なバージョン0x01の無効なインタフェース識別子0x02のサポートされていないメッセージクラス0x03でサポートされていないメッセージの種類0x04がサポートされていないトラフィック - 管理0x0DのASP識別子必須0x0Eの無効なASP識別子0x0Fのをブロックします
In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are specific to ISDN.
彼らはISDNに固有のものとしてDUAでは、エラーコード0x0Aを、0x0Bの、と0x0Cのは、無効です。
The following additional error codes are supported in DUA:
次の追加のエラーコードはDUAでサポートされています。
Channel Number out of range 0x1c
Channel Number not configured 0x1d
The "Channel Number out of range" error is sent if a message is received with a channel number greater than 63 for DPNSS or 31 for DASS 2.
メッセージはDPNSSまたはDASS 2の31は63よりも大きいチャンネル番号で受信される場合、「範囲外のチャンネル番号」エラーが送信されます。
The "Channel Number not configured" error is sent if a message is received with a channel number that is not configured.
メッセージが構成されていないチャンネル番号で受信される場合、「チャネル番号が設定されていません」エラーが送信されます。
IANA has assigned a DUA value for the SCTP Payload Protocol Identifier field that is used in SCTP Payload Data chunks. The following value for the SCTP Payload Protocol Identifier field SHOULD be used for DUA:
IANAは、SCTPペイロードデータチャンクに使用されるSCTPペイロードプロトコル識別子フィールドのDUA値を割り当てました。 SCTPペイロードプロトコル識別子フィールドに次の値は、DUAのために使用する必要があります。
SCTP Payload Protocol ID = "10"
SCTPペイロードプロトコルID = "10"
As an option, the IUA value for SCTP Payload Protocol ID MAY also be used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS over the same SCTP association. However, use of separate SCTP Payload Protocol IDs (10 for DUA and 1 for IUA) is recommended as the primary option, even in scenarios where ISDN and DPNSS are backhauled over the same SCTP association.
1が同じSCTPアソシエーション上でISDNやDPNSSをバックホールしたい場合はオプションとして、SCTPペイロードプロトコルID用IUA値は、例えば、DUAのためにも使用することができます。しかし、別SCTPペイロードプロトコルのID（DUAとIUA 1 10）を使用することはあってもISDNおよびDPNSSが同じSCTPアソシエーション上にバックホールされているシナリオでは、一次オプションとして推奨されています。
SCTP Payload Protocol ID of "10" SHOULD be used for DUA if only DPNSS is backhauled over an SCTP association (i.e., in scenarios where simultaneous backhauling of ISDN and DPNSS over the same association is NOT required).
唯一DPNSS（すなわち、シナリオで同じアソシエーション上ISDNおよびDPNSSの同時バックホールを必要としない）SCTPアソシエーション上にバックホールされている場合、「10」のSCTPペイロードプロトコルIDは、DUAのために使用されるべきです。
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ペイロードプロトコル識別子はSCTPが搬送されるプロトコルを示すために、各SCTPデータチャンクに含まれています。このペイロードプロトコル識別子を直接SCTPによって使用されていないが、データのチャンクで運ばれる情報の種類を識別するために、特定のネットワークエンティティによって使用されてもよいです。
An example of the message flows for establishing a data link on a signaling channel, passing PDUs and releasing a data link on a DPNSS channel is shown below. An active association between MGC and SG is established prior to the following message flows.
メッセージの例を以下に示し、シグナリングチャンネル上でデータリンクを確立PDUを通過し、DPNSSチャネル上のデータ・リンクを解放するために流れます。 MGCとSGとの間のアクティブ・アソシエーションは、次のメッセージが流れる前に確立されています。
i) Successful
I）に成功
PBX SG MGC
<----------- SABMR <----------- Est Req(Ind=1)
UA -----------> Est Cfm -----------> (DLC in RC State)
Ind=1)
ii) Unsuccessful(Link Failure)
ⅱ）失敗した（リンク障害）
PBX SG MGC
<----------- SABMR <----------- Est Req(Ind=1)
Retransmissions over
NT1 and NT2 expired
Rel Ind -----------> (DLC in RA state)
(RELEASE_OTHER,Ind=1)
PBX SG MGC
<----------- SABMR(1) <----------- Est Req(Ind=0)
<----------- SABMR(2)
<----------- SABMR(3)
.............
<----------- SABMR(N)
In each DLC either
UA is received or
NT1/NT2 is expired
Est Cfm -----------> (Status of DLCs
(Ind=0) are not updated)
<----------- Status Req
Status cfm ----------> (Mark DLC status
based on
status bits)
If one of more DLCs remains out-of-service after this procedure (e.g., due to layer 2 management), the MGC can either retry this DLC with an Est Req(Ind=1) indicating the specific DLC or with an
複数のDLCの一つはアウト・オブ・サービスは、この手順の後に残っている場合、MGCはエスト必須（IND = 1）を有する特定のDLC又はを示すと、このDLCを再試行するか（例えば、原因は2管理層に）
Est Req(Ind=0) and the SG will retry the appropriate DLC that is out-of-service.
EST必須（IND = 0）とSGは、アウトオブサービスである適切なDLCを再試行します。
PBX SG MGC
<----------- UI(C) <----------- Data Req
UI(R)-----------> Data Ind ----------->
PBX SG MGC
(For DPNSS, mark DLC as OOS) <----------- Rel Req
(For DASSII, mark DLC as RA) (RELEASE_MGMT,
Ind=1)
Rel Cfm ---------->
(Ind=1)
PBX SG MGC
(For DPNSS, mark all DLCs as OOS) <-------- Rel Req
(For DASSII, mark DLC as RA) (RELEASE_MGMT,
Ind=0)
Rel Cfm ---------->
(Ind=0)
PBX SG MGC
<----------- Stat Req
Stat Cfm -----------> (Mark DLC status
based on
status bits)
PBX SG MGC
Invalid Message <-----------Est/Rel/Data/-
Stat Req
Error Ind ----------->
(Error Code)
The security considerations for the ISDN User Adaptation Protocol (IUAP) [1] (Section 6) and the security considerations for SIGTRAN Protocols document [4] apply to this document as well.
ISDNユーザ適合プロトコル（IUAP）[1]（第6節）とSIGTRANプロトコルドキュメントのセキュリティ問題のためのセキュリティ問題は、[4]同様に、この文書に適用されます。
[1] Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
[1] Morneault、K.、Rengasami、S.、カラ、M.、およびG. Sidebottom、 "ISDN Q.921ユーザー・アダプテーションレイヤ"、RFC 3057、2001年2月。
[2] Ofcom/NICC ND1301:2001/03, DPNSS [188], Digital Private Signalling System No 1 (DPNSS 1) (Formerly BTNR 188).
[2] Ofcomの/ NICC ND1301：2001/03、DPNSS [188]、デジタル専用シグナリングシステムいいえ1（DPNSS 1）（旧BTNR 188）。
[3] BTNR (British Telecom Network Requirements) 190 Issue 2 Digital Access Signaling System No 2.
[3] BTNR（ブリティッシュテレコムネットワークの要件）190号2デジタルアクセスシグナリングシステムはありません2。
[4] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004.
[4] Loughney、J.、Tuexen、M.、およびJ.牧師-Balbas、 "信号転送のためのセキュリティ上の考慮事項（SIGTRAN）プロトコル"、RFC 3788、2004年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
The authors would like to thank Shashi Kumar and Venkatesh Seshasayee of Wipro Technologies for their useful suggestions and comments.
著者は彼らの有益な提案やコメントをシャシクマールとウィプロ・テクノロジーズのベンカテッシュSeshasayeeに感謝したいと思います。
Authors' Addresses
著者のアドレス
All correspondence regarding this document should be sent to the following addresses:
本書に関するすべての対応は、次のアドレスに送信する必要があります。
Ranjith Mukundan Wipro Technologies 72, Electronics City Hosur Main Road Bangalore 560100 India
ランジットMukundan 72ウィプロ・テクノロジーズ、エレクトロニクスシティ、ホスールメインロードバンガロール560100インド
Phone: +91-80-51195893 EMail: ranjith.mukundan@wipro.com
電話：+ 91-80-51195893 Eメール：ranjith.mukundan@wipro.com
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA
ケンMorneaultシスコシステムズ13615ダレステクノロジードライブハーンドン。 20171 USA
Phone: +1-703-484-3323 EMail: kmorneau@cisco.com
電話：+ 1-703-484-3323 Eメール：kmorneau@cisco.com
Narsimuloo Mangalpally Nortel Networks 250 Sidney Street Belleville, Ontario K8P 3Z3 Canada
Narsimuloo Mangalpallyノーテルネットワーク250シドニー・ストリートベルヴィル、オンタリオ州K8P 3Z3カナダ
Phone: +1-613-967-5034 EMail: narsim@nortelnetworks.com
電話：+ 1-613-967-5034 Eメール：narsim@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。