Network Working Group R. Mukundan
Request for Comments: 4129 Wipro Technologies
Category: Standards Track K. Morneault
Cisco Systems
N. Mangalpally
Nortel Networks
August 2005
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).
版权所有（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.
本文件通过扩展RFC 3057中定义的ISDN用户适配（IUA）层协议，定义了通过IP回传数字专用网信令系统1（DPNSS 1）和数字接入信令系统2（DASS 2）消息的机制。ND1301:2001/03（原BTNR 188）中规定的DPNSS 1用于互连专用网络中的专用分支交换机（PBX）。BTNR 190中规定的DASS 2用于将PBX连接到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
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.
本文档描述了使用改进版的ISDN用户适配协议（IUAP）[1]通过IP实现数字专用网信令系统1（DPNSS 1）[2]（以下简称为DPNSS）和数字接入信令系统2（DASS 2）[3]回程消息传递的方法。DPNSS/DASS2用户自适应（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:
需要将交换电路网络（SCN）信令协议从DPNSS信令网关（SG）传送到媒体网关控制器（MGC）。交付机制应支持以下协议：
- 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通道）-一个64 kbit/s的时隙，在2048 kbit/s接口或1544 kbit/s接口上用作公共信令通道，用于传输DPNSS信令。
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.
数据链路连接（DLC）-DLC是代表一个DPNSS通道控制3级消息传输的2级进程。数据链路连接器唯一标识一个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链路—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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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是一种行业标准接口（参考ND1301:2001/03）[2]，定义在PBX和接入网络（an）之间。DPNSS将通常仅在单个PBX上的扩展之间可用的设施扩展到专用网络中连接的PBX上的所有扩展。DPNSS最初源自英国电信的数字接入信令系统I（DASSI），并在必要时进行了增强，以满足专用网络的要求。其中一些增强功能已并入DASS 2中[3]。DPNSS使用2048 kbits/s或1544 kbits/s数字传输系统接口，如下图1所示。
---------- ---------- o--o
| | 2048 kbits/s | |------- /\
| |--------------| | --
| PBX | 1544 kbits/s | AN |
| |--------------| | o--o
| | | |------- /\
---------- ---------- --
---------- ---------- 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 ****** IP *******
*PBX *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|DPNSS| (NIF) |DPNSS|
| L3 | | L3 |
+-----+ +----------+ +-----+
| | | | DUA| | DUA |
|DPNSS| |DPNSS+----+ +-----+
| L2 | | L2 |SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+
|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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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中，根据ND1301:2001/03（原BTNR 188）[2]，DLCI字段具有不同的格式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |V|0|Channel No.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位用于确定消息是针对特定数据链路连接器还是适用于载波中的所有数据链路连接器。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.
值说明0将在所有数据链路连接器上执行操作；忽略通道号参数。1在通道号指定的单个数据链路连接器上执行操作。
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位值仅由建立和释放消息使用。数据消息应忽略此值。提供此指示器是为了发出一个命令来建立或释放一个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，DAS 2的有效值为0至31。这是因为DASS 2不支持虚拟数据链路，因此只有32个数据链路。
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，需要一条新消息来携带数据链路连接器的状态。此消息将是一条管理消息（即，对于管理，其消息类的值为0）。以下消息类型将用于这些消息：
5 DLC Status Request 6 DLC Status Confirm 7 DLC Status Indication
5数据链路连接器状态请求6数据链路连接器状态确认7数据链路连接器状态指示
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.
数据链路状态消息在DUA层对等方之间交换，以请求、确认和指示数据链路的状态。如第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:
此外，数据链路连接器状态确认和指示消息将包含新参数，称为数据链路连接器状态参数。对于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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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接口，因为时隙0用于E1帧和同步位，而时隙16用于信令。对于DPNSS，总共最多有60个DLC（30个实数据+30个虚拟数据），对于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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
D23不适用于T1接口，因为时隙23用于信令。对于DPNSS，最多将有46个DLC（23个实数+23个虚拟数），对于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:
该参数为每个数据链路使用两位来表示数据链路的状态。两位的可能值如下所示：
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，值00（停止服务）无效，因为DASS 2 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，没有虚拟数据链路，因此只需携带32个数据链路的信息。因此，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.
当在传入消息中发现无效值或无法识别的消息时，将发送错误消息。
The Error Code parameter indicates the reason for the Error Message. These are the supported values in IUA.
Error Code参数指示错误消息的原因。这些是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
无效版本0x01无效接口标识符0x02不支持的消息类0x03不支持的消息类型0x04不支持的流量处理模式0x05意外消息0x06协议错误0x07不支持的接口标识符类型0x08无效流标识符0x09未分配的TEI 0x0a未识别的SAPI 0x0b无效TEI，SAPI组合0x0c被拒绝-管理阻止0x0d需要ASP标识符0x0e无效ASP标识符0x0f
In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are specific to ISDN.
在DUA中，错误代码0x0a、0x0b和0x0c无效，因为它们特定于ISDN。
The following additional error codes are supported in DUA:
DUA中支持以下附加错误代码：
Channel Number out of range 0x1c Channel Number not configured 0x1d
通道号超出范围0x1c通道号未配置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或DAS 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有效负载协议标识符字段分配了DUA值，该字段用于SCTP有效负载数据块。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值也可用于DUA，例如，如果希望通过同一SCTP关联回程ISDN和DPNSS。但是，建议使用单独的SCTP有效负载协议ID（10用于DUA，1用于IUA）作为主要选项，即使在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通过SCTP关联进行回程传输（即，在不需要通过同一关联同时回程ISDN和DPNSS的情况下），则应将SCTP有效负载协议ID“10”用于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)
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 <----------- 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
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)
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
如果在此过程后一个或多个数据链路仍不可用（例如，由于第2层管理），则MGC可以使用指示特定数据链路的Est Req（Ind=1）重试此数据链路，或者使用
Est Req(Ind=0) and the SG will retry the appropriate DLC that is out-of-service.
Est Req（Ind=0）和SG将重试相应的停用数据链路连接器。
PBX SG MGC
<----------- UI(C) <----------- Data Req
UI(R)-----------> Data Ind ----------->
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 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
(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
<----------- 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)
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-用户适配层”，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.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
印度班加罗尔电子城Hosur大道72号Ranjith Mukundan Wipro Technologies 560100
Phone: +91-80-51195893
EMail: ranjith.mukundan@wipro.com
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号，邮编：20171
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Narsimuloo Mangalpally Nortel Networks 250 Sidney Street Belleville, Ontario K8P 3Z3 Canada
加拿大安大略省贝勒维尔西德尼街250号Narsuloo Mangalpally Nortel Networks K8P 3Z3
Phone: +1-613-967-5034
EMail: narsim@nortelnetworks.com
Phone: +1-613-967-5034
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。