[要約] 要約：RFC 4129は、IUAプロトコルに対するDPNSS/DASS 2の拡張に関する仕様を提供しています。 目的：このRFCの目的は、IUAプロトコルを使用してDPNSS/DASS 2をサポートするためのガイドラインを提供することです。
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
デジタルプライベートネットワークシグナリングシステム（DPNSS）/デジタルアクセス信号システム2（DASS 2）IUAプロトコルへの拡張
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).
Copyright（c）The Internet Society（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.
このドキュメントは、RFC 3057で定義されたISDNユーザー適応（IUA）レイヤープロトコルを拡張することにより、IPを拡張することにより、IPを介したデジタルプライベートネットワークシグナリングシステム1（DPNSS 1）およびデジタルアクセス信号システム2（DASS 2）メッセージをバックホールするためのメカニズムを定義しています。ND1301：2001/03（以前のBTNR 188）では、プライベートネットワークでプライベートブランチ交換（PBX）を相互接続するために使用されます。BTNR 190で指定されたDass 2は、PBXSをPSTNに接続するために使用されます。このドキュメントは、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.
このドキュメントでは、デジタルプライベートネットワークシグナリングシステム1（DPNSS 1）[2]（以降、DPNSSと呼ばれる）およびデジタルアクセスシグナリングシステム2（DASS 2）[3]の修正バージョンを使用してIPを使用してバックホールメッセージングを実装する方法について説明します。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:
DPNSSシグナリングゲートウェイ（SG）からメディアゲートウェイコントローラー（MGC）へのスイッチング回路ネットワーク（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.
Data Channel（D -Channel）-2048 KBITS/Sインターフェイスで共通のシグナル伝達チャネルまたはDPNSS信号を運ぶようにプロビジョニングされる1544 KBITS/Sインターフェイスとして機能する64 KBIT/Sタイムスロット。
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チャネル-2048 KBITS/Sインターフェイスでタイムスロット1〜15および17〜31は、1544 KBITS/sインターフェイスのタイムスロット1〜23がDPNSSチャネルと呼ばれます。これらは、音声またはデータトラフィックを運ぶトラフィックチャネルです。
- DPNSS supports 60 Channels (30 Real and 30 Virtual) - DASS2 supports 30 Channels (All Real)
- DPNSSは60チャンネル（30リアルおよび30の仮想）をサポートします-Dass2は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.
Data Link Connection（DLC）-DLCは、1つの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 REALおよび30 VARTUAL）をサポートしています-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リンク - 2048 KBITS/Sインターフェイスまたは1544 KBITS/SインターフェイスのDチャンネルと関連するDPNSSチャネルの論理コレクションは、「DPNSSリンク」と呼ばれます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
DPNSSは、業界標準インターフェイス（Ref。ND1301：2001/03）[2]であり、PBXとAccess Network（AN）の間で定義されています。DPNSSは、通常、単一のPBX上のエクステンション間でのみ利用可能な施設を、プライベートネットワークで接続されているPBXのすべての拡張機能に拡張します。DPNSSはもともとBTのデジタルアクセス信号システムI（DASS I）に由来し、必要に応じてプライベートネットワークの要件を満たすために強化されました。これらの機能強化のいくつかは、Dass 2に組み込まれました[3]。DPNSSは、以下の図1に示すように、2048 KBITS/Sまたは1544 KBITS/Sデジタル伝送システムインターフェイスを使用しています。
---------- ---------- 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 KBITS/S（E1）インターフェイスにあり、チャンネル24は1544 KBITS/S（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 -NODALインターワーキング関数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.
DPNSS/DASS2レイヤー2レイヤー3プリミティブ[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)
13 dpnss/dass2境界プリミティブ輸送メッセージ（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
0管理（MGMT）メッセージ3 ASP状態メンテナンス（ASPSM）メッセージ4 ASPトラフィックメンテナンス（ASPTM）メッセージ
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.
チャネル番号（チャネル番号）の場合、有効な値はDPNSSの場合は0〜63、DASS 2では0〜31です。これは、Dass 2が仮想DLCをサポートせず、したがって32のDLCしかないためです。
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の場合、DLCSのステータスを運ぶために新しいメッセージが必要です。このメッセージは、管理メッセージになります（つまり、そのメッセージクラスは管理の場合は0の値です）。これらのメッセージには、次のメッセージタイプが使用されます。
5 DLC Status Request 6 DLC Status Confirm 7 DLC Status Indication
5 DLCステータスリクエスト6 DLCステータス7 DLCステータス表示を確認する
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レイヤーのピア間で交換され、DLCSのステータスを要求、確認、示します。DLCステータスメッセージには、セクション2.2で説明されているように、共通のメッセージヘッダーが含まれています。
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は該当しないことを表しています。D0とD16はE1インターフェイスには適用できません。なぜなら、Timeslot 0はE1フレーミングに使用され、同期ビットとTimeslot 16がシグナリングに使用されるためです。DPNSSの場合、合計60 DLC（30 Real 30 Virtual）があり、DASS2の場合、合計30のDLC（仮想なし）があります。
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).
Timeslot 23はシグナリングに使用されるため、D23はT1インターフェイスには適用されません。DPNSSの場合、合計46 DLC（23 Real 23 Virtual）があり、DASS2の場合、合計23のDLC（仮想なし）があります。
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
値の説明00サービスオースサービス01リセット試行10リセット11情報転送を完了する
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の場合、DASS 2 DLCにはこの状態がないため、値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に対して有効なNotifyおよびエラーメッセージのみが有効です。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
In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are specific to ISDN.
DUAでは、ISDNに固有のエラーコード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で63を超えるチャネル番号、DASS 2で31を超えるチャネル番号でメッセージが受信された場合、「範囲外のチャネル番号」エラーが送信されます。
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.
オプションとして、SCTPペイロードプロトコルIDのIUA値は、たとえば、同じSCTPアソシエーションでISDNおよびDPNSSをバックホールしたい場合、DUAにも使用できます。ただし、ISDNとDPNSが同じSCTPアソシエーションでバックホールされているシナリオであっても、個別のSCTPペイロードプロトコルID（DUAで10、IUAの場合は10）の使用が主要なオプションとして推奨されます。
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).
SCTP Association（つまり、同じ協会のISDNとDPNSの同時バックホールが不要なシナリオでDPNSSのみがバックホールされている場合は、DUAに「10」のSCTPペイロードプロトコルIDを使用する必要があります。
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)
ii）失敗（リンク障害）
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 Est Req(Ind=0) and the SG will retry the appropriate DLC that is out-of-service.
この手順の後（レイヤー2管理のため）、より多くのDLCの1つがサービス外のままである場合、MGCは、特定のDLCを示すEST REQ（IND = 1）またはEST REQ（EST REQ）でこのDLCを再試行できます。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.、Kalla、M。、およびG. Sidebottom、「ISDN Q.921-USER適応層」、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]、デジタルプライベートシグナル伝達システムNO 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. Pastor-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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
The authors would like to thank Shashi Kumar and Venkatesh Seshasayee of Wipro Technologies for their useful suggestions and comments.
著者は、Wipro TechnologiesのShashi KumarとVenkatesh 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
Ranjith Mukundan Wipro Technologies 72、Electronics City Hosur Main Road Bangalore 560100 India
Phone: +91-80-51195893
EMail: ranjith.mukundan@wipro.com
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon、VA。20171 USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Narsimuloo Mangalpally Nortel Networks 250 Sidney Street Belleville, Ontario K8P 3Z3 Canada
ナルシムルーマンガルパリーノルテルネットワーク250シドニーストリートベルビル、オンタリオK8P 3Z3カナダ
Phone: +1-613-967-5034
EMail: narsim@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。