Network Working Group R. Mukundan
Wipro Technologies
Ken Morneault
Cisco Systems
N. Mangalpally
A Vydyam
Nortel Networks
Expires in 6 months Jan 2003
DPNSS/DASS 2 extensions to the IUA protocol<draft-ietf-sigtran-dua-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 BTNR 188, is used to interconnect Private Branch
Exchanges (PBX) in a private network and 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.
Table of Contents
1.0 Introduction ......................................... 21.1 Scope ............................................. 21.2 Terminology ....................................... 21.3 DPNSS Overview .................................... 31.4 Proposed DPNSS Backhaul Architecture .............. 3Mukundan, et. al. [Page 1]

Internet Draft draft-ietf-sigtran-dua-05.txt Jan 2003
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)
In DUA, the DLCI field has a different format in accordance with
the 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 whether the message is for
a particular DLC or it is applicable for all the DLCs in the
carrier. The possible values of the V-bit are listed below:
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.
2.3 Unit Data Message
DPNSS layer 2 does not have a unit data primitive and hence the
Mukundan, et. al. [Page 5]

Internet Draft draft-ietf-sigtran-dua-05.txt Jan 2003
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
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 IUA 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.1.
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).
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).
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
For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2
DLC does not have this state. In addition, the Idle state is a
transient state local to the DLC so a value is not allocated for it.
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.
Mukundan, et. al. [Page 6]

Internet Draft draft-ietf-sigtran-dua-05.txt Jan 20032.5 Management (MGMT) Messages
Only the Notify and Error messages are valid for DUA. The TEI Status
messages are not used.
2.5.1 Error Message
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
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.
The "Channel Number not configured" error is sent if a message is
received with a channel number that is not configured.
3.0 IANA Considerations
A request will be made to IANA to assign a DUA value for the SCTP
Payload Protocol Identifier field used in SCTP Payload Data chunks.
The following value for the SCTP Payload Protocol Identifier field
SHOULD be used for DUA:
SCTP Payload Protocol ID = 10
However, the IUA SCTP Payload Protocol ID can also be used.
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.
The User Adaptation peer may use the Payload Protocol Identifier as
a way of determining whether the message is for IUA or DUA.
4.0 Message Sequence in DUA
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.
Mukundan, et. al. [Page 7]