| draft-ietf-sigtran-dua-01Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-dua-01.txt.
Internet Engineering Task Force A. Vydyam
R. Mukundan
N. Mangalpally
Nortel Networks
Ken Morneault
Cisco Systems
Expires in 6 months October 2001
DPNSS/DASS 2 extensions to the IUA protocol
<draft-ietf-sigtran-dua-01.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 of DPNSS/DASS2
messages over IP by extending the ISDN User Adaptation Layer
Protocol reference RFC3057. This document aims to become an Appendix
to IUA and to be the base for a DUA implementation.
Table of Contents
1.0 Introduction ......................................... 2
1.1 Scope ............................................. 2
1.2 Terminology ....................................... 2
1.3 DPNSS Overview .................................... 3
1.4 Proposed DPNSS Backhaul Architecture .............. 3
Vydyam/Mukundan/Mangalpally/Morneault 1
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
2.0 Changes from IUA...................................... 4
2.1 New Message Class for DUA.......................... 4
2.2 Message Header..................................... 4
2.3 Unit Data Message.................................. 5
2.4 Status Message..................................... 5
2.5 Error Message...................................... 6
3.0 IANA Considerations................................... 7
4.0 Message Sequence in DUA............................... 7
4.1 Resetting of single DLC............................ 7
4.2 Resetting all DLCs in a link....................... 8
4.3 Information Transfer on a DLC...................... 8
4.4 Link Takedown(Single DLC).......................... 8
4.5 Link Takedown(All DLCs)............................ 8
4.6 Getting link Status................................ 9
4.7 Error conditions................................... 9
5.0 References ........................................... 9
6.0 Author's Addresses.................................... 9
7.0 Author's Addresses.................................... 9
8.0 Author's Addresses.................................... 9
1.0 Introduction
This document describes a method of implementing DPNSS/DASS 2 back-
haul messaging over IP using a modified version of the ISDN
User Adaptation Protocol (IUAP). The DUA builds on top of IUA
defining the necessary extensions to IUA for a DPNSS/DASS2
implementation.
1.1 Scope
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)
- DASS 2 (Digital Access Signaling System No 2)
Unless specifically mentioned the details in this document are
applicable to both DPNSS and DASS2.
1.2 Terminology
Data channel (D-channel) - A 64 kbit/s time slot which functions
as a common signaling channel on a 2048 kbits/s interface or a
1544 kbits/s interface which is provisioned to carry DPNSS
signaling.
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 which carry voice or data traffic.
Vydyam/Mukundan/Mangalpally/Morneault 2
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
- DPNSS supports 60 Channels (30 Real and 30 Virtual)
- DASS2 supports 30 Channels (All Real)
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.
- DPNSS supports 60 DLCs (30 Real and 30 Virtual)
- DASSII supports 30 DLCs (All Real)
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".
1.3 DPNSS Overview
DPNSS is an industry standard interface (reference BTNR 188)
defined between a PBX and an Access Network (AN).
DPNSS extends facilities normally only available between
extensions on a single PBX to all extensions on PBXs that are
connected together in a private network. DPNSS was originally
derived from BT's Digital Access Signaling System I (DASS I)
enhanced where necessary to meet the private network
requirements. Some of these enhancements were incorporated in
DASS 2. DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital
Transmission System Interface as shown in figure 1 below.
---------- ---------- o--o
| | 2048 kbits/s | |------- /\
| |--------------| | --
| PBX | 1544 kbits/s | AN |
| |--------------| | o--o
| | | |------- /\
---------- ---------- --
Figure 1
Channel 16 on a 2048 kbits/s interface and channel 24 on a
1544 kbits/s interface 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 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".
1.4 Proposed DPNSS Backhaul Architecture
Vydyam/Mukundan/Mangalpally/Morneault 3
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
****** 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
2.0 Changes from IUA
The following section outlines the differences between DUA and IUA
2.1 New Message Class for DUA
The DPNSS/DASS2 Layer 2 to Layer 3 primitives need to be handled
in a different way from the IUA boundary primitive transport
messages and the boundary primitive transport messages of other
IUA extensions V5UA. Therefore it is neccessary to distinguish
between these from other IUA-based boundary primitive transport
message types by means of the Message Class parameter.
For all DPNSS/DASS2 interface boundary primitives, a new Message
Class is introduced:
10 DPNSS/DASS2 Boundary Primitives Transport Messages
(DPTM)
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
IUA Message header has the format as shown in Figure 2 below.
Vydyam/Mukundan/Mangalpally/Morneault 4
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 IUA Message Header
In DUA header DLCI field has a different format in accordance with
the BTNR 188.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indicator |0|Channel No.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The indicator field 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 indicator is mentioned 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 indicator 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 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
Vydyam/Mukundan/Mangalpally/Morneault 5
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
Unit Data Messages (Request, Indication) are invalid for a DUA
application.
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). A message type of 0x5 will be
used for this message.
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.
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 (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|D16|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .................... |Dxx|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
2.5 Error Message
Vydyam/Mukundan/Mangalpally/Morneault 6
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
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
In DUA the error codes 0x0a to 0x0c are invalid as they are specific
to ISDN.
The following additional error codes are supported in DUA.
Channel Number out of range 0x0d
Channel Not configured 0x0e
3.0 IANA Considerations
A request will be made to IANA to assign a DUA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Payload Protocol Identifier will be registered:
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.
4.1 Resetting of single DLC
Vydyam/Mukundan/Mangalpally/Morneault 7
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
i) Successful
PBX SG MGC
<----------- SABMR <----------- Est Req(Ind=1)
UA -----------> Est Cfm -----------> (DLC in RC State)
Ind=1)
ii) Unsuccessful(Link Failure)
PBX SG MGC
<----------- SABMR <----------- Est Req(Ind=1)
Retransmissions over
NT1 and NT2 expired
Rel Ind -----------> (DLC in RA state)
(RELEASE_PHYS,Ind=1)
4.2 Resetting all DLCs in a link
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)
4.3 Information Transfer on a DLC
PBX SG MGC
<----------- UI(C) <----------- Data Req
UI(C)-----------> Data Ind ----------->
4.4 Link Takedown(Single DLC)
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)
4.5 Link Takedown(All DLCs)
Vydyam/Mukundan/Mangalpally/Morneault 8
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
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)
4.6 Getting link Status
PBX SG MGC
<----------- Stat Req
Stat Res -----------> (Mark DLC status
based on
status bits)
4.7 Error conditions
PBX SG MGC
Invalid Message <-----------
Est/Rel/Data/Stat Req
Error Ind ----------->
(Error Code)
5.0 Glossary of terms
Real channel : The signalling channel with associated
traffic channel (TS).
Virtual channel: The signalling channel with no
associated traffic channel.
NT1 : Retransmission period of 500msec.
NT2 : Recommended value is 64.
6.0 References
[1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057,
February 2001.
[2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital
Private Network Signaling System 1.
[3] BTNR (British Telecom Network Requirements) 190 Issue 2
Digital Access Signaling System No 2
[4] ETS 300 167 (08/1993) : Transmission and Multiplexing;
Functional characteristic of 2048 kbits/s interfaces
(Standard is based on G.704, G.706).
Vydyam/Mukundan/Mangalpally/Morneault 9
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
7.0. Acknowledgments
The authors would like to thank Sudarsan Naganathan, Subhas
Mondal and Sivaram Subramanian of Nortel Networks for their useful
suggestions/comments.
8.0 Author's Addresses
Authors : Anil Vydyam, Ranjith Mukundan, Narsimuloo Mangalpally and
Ken Morneault
All correspondence regarding this draft should be sent to
the following addresses :
Mick Dragon Phone: +44 (0)1628434388
Nortel Networks plc EMail: [email protected]
Concorde Road
Maidenhead
Berkshire SL6 4AG
United Kingdom
Ken Morneault Phone: +1-703-484-3323
Cisco Systems Inc. EMail: [email protected]
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Vydyam/Mukundan/Mangalpally/Morneault 10
Internet Draft draft-ietf-sigtran-dua-01.txt October 2001
| ||||||||||||||||
| Last modified: Thu, 28 Nov 2024 03:12:47 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||