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).




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
1. Introduction
1. はじめに

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の上に構築します。

1.1. Scope
1.1. 範囲

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 (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の両方に適用されています。

1.2. Terminology
1.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]。

1.3. DPNSS Overview
1.3. DPNSS概要

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


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."


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リンク」と呼ばれています。

1.4. Proposed DPNSS Backhaul Architecture
1.4. 提案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ユーザ適合層プロトコル

2. Changes from IUA

This section outlines the differences between DUA and IUA.


2.1. New Message Class for DUA
2.1. DUAのための新しいメッセージクラス

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

Similar to IUA, other valid message classes for DUA are:


          0       Management (MGMT) Message
          3       ASP State Maintenance (ASPSM) Messages
          4       ASP Traffic Maintenance (ASPTM) Messages
2.2. Message Header
2.2. メッセージのヘッダー

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


Should be set to all '0's and ignored by the receiver.


V-bit: 1 bit


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.


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です。

2.3. Unit Data Message
2.3. ユニットデータメッセージ

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.


2.4. DLC Status Message
2.4. DLCステータスメッセージ

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:


        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:


    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:


    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の長さを有するであろう。

2.5. Management (MGMT) Messages
2.5. 管理(MGMT)メッセージ

Only the Notify and Error messages are valid for DUA. The TEI Status messages are not used.

のみ通知とエラーメッセージがDUAのために有効です。 TEIのステータスメッセージが使用されていません。

2.5.1. Error Message
2.5.1. エラーメッセージ

The ERR message is sent when an invalid value or unrecognized message is found in an incoming message.


The Error Code parameter indicates the reason for the Error Message. These are the supported values in 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.


The following additional error codes are supported in 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.


3. IANA Considerations
3. IANAの考慮事項

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"

4. Use of SCTP Payload Protocol ID

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).


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.


5. Message Sequence in DUA
DUA 5.メッセージシーケンス

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との間のアクティブ・アソシエーションは、次のメッセージが流れる前に確立されています。

5.1. Resetting of single DLC
5.1. 単一DLCのリセット

i) Successful


       PBX                     SG                        MGC
           <----------- SABMR          <----------- Est Req(Ind=1)
       UA   ----------->       Est Cfm -----------> (DLC in RC State)

ii) Unsuccessful(Link Failure)


         PBX                     SG                        MGC
           <----------- SABMR         <----------- Est Req(Ind=1)
           Retransmissions over
           NT1 and NT2 expired
                               Rel Ind -----------> (DLC in RA state)
5.2. Resetting all DLCs in a Link
5.2. リンク内のすべてのDLCをリセット
         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を再試行します。

5.3. Information Transfer on a DLC
5.3. DLCの情報伝達
            PBX                     SG                        MGC
                 <----------- UI(C)            <----------- Data Req
            UI(R)----------->         Data Ind ----------->
5.4. Link Takedown (Single DLC)
5.4. リンクテイクダウン(シングルDLC)
            PBX                     SG                        MGC
                (For DPNSS, mark DLC as OOS)   <----------- Rel Req
                (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                      Rel Cfm  ---------->
5.5. Link Takedown (All DLCs)
5.5. リンクテイクダウン(すべてのDLC)
            PBX                     SG                        MGC
                (For DPNSS, mark all DLCs as OOS) <-------- Rel Req
                (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                        Rel Cfm  ---------->
5.6. Getting Link Status
5.6. リンクステータスの取得
            PBX                     SG                        MGC
                                           <-----------  Stat Req
                                  Stat Cfm -----------> (Mark DLC status
                                                         based on
                                                         status bits)
5.7. Error Conditions
5.7. エラー条件
            PBX                     SG                        MGC
                              Invalid Message <-----------Est/Rel/Data/-
                                                           Stat Req
                                 Error Ind    ----------->
                                (Error Code)
6. Security Considerations

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.


7. References
7.1. Normative References
7.1. 引用規格

[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における使用のためのレベルを示すために"。

8. Acknowledgements

The authors would like to thank Shashi Kumar and Venkatesh Seshasayee of Wipro Technologies for their useful suggestions and comments.


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:

電話:+ 91-80-51195893 Eメール

Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA

ケンMorneaultシスコシステムズ13615ダレステクノロジードライブハーンドン。 20171 USA

Phone: +1-703-484-3323 EMail:

電話:+ 1-703-484-3323 Eメール

Narsimuloo Mangalpally Nortel Networks 250 Sidney Street Belleville, Ontario K8P 3Z3 Canada

Narsimuloo Mangalpallyノーテルネットワーク250シドニー・ストリートベルヴィル、オンタリオ州K8P 3Z3カナダ

Phone: +1-613-967-5034 EMail:

電話:+ 1-613-967-5034 Eメール

Full Copyright Statement


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎と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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。