| draft-ietf-sigtran-dua-08Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-dua-08.txt.
INTERNET-DRAFT Ranjith Mukundan
Internet Engineering Task Force Wipro Technologies
Ken Morneault
Cisco Systems
N Mangalpally
Nortel Networks
Expires: March 2005 Issued: Sept 2004
DPNSS/DASS 2 extensions to the IUA protocol
<draft-ietf-sigtran-dua-08.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 ND1301:2001/03 (formerly 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.
Mukundan, et. al. [Page 1]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
Table of Contents
1.0 Introduction ......................................... 2
1.1 Scope ............................................. 2
1.2 Terminology ....................................... 3
1.3 DPNSS Overview .................................... 3
1.4 Proposed DPNSS Backhaul Architecture .............. 4
2.0 Changes from IUA...................................... 4
2.1 New Message Class for DUA.......................... 4
2.2 Message Header..................................... 5
2.3 Unit Data Message.................................. 6
2.4 DLS Status Message................................. 6
2.5 Management (MGMT) Messages......................... 7
3.0 IANA Considerations................................... 8
4.0 Use of SCTP Payload Protocol ID........................9
5.0 Message Sequence in DUA............................... 9
5.1 Resetting of single DLC............................ 9
5.2 Resetting all DLCs in a link....................... 10
5.3 Information Transfer on a DLC...................... 10
5.4 Link Takedown(Single DLC).......................... 10
5.5 Link Takedown(All DLCs)............................ 10
5.6 Getting link Status................................ 11
5.7 Error conditions................................... 11
6.0 Security Considerations............................... 11
7.0 References............................................ 11
8.0 Acknowledgements...................................... 11
9.0 Author's Addresses.................................... 12
10.0 Full Copyright Statement.............................. 12
1.0 Introduction
This document describes a method of implementing Digital Private
Network Signaling System 1 (DPNSS 1) [2] - henceforth just 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.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) [2]
- DASS 2 (Digital Access Signaling System Number 2) [3]
Unless specifically mentioned, the details in this document are
applicable to both DPNSS and DASS 2.
Mukundan, et. al. [Page 2]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
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.
- 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".
Real channel - A signalling channel with associated traffic
channel (TS).
Virtual channel - A signalling channel with no associated traffic
channel.
NT1 - The DPNSS minimum retransmission period.
NT2 - The DPNSS minimum post retransmission acknowledgement delay.
1.3 DPNSS Overview
DPNSS is an industry standard interface (ref. ND1301:2001/03) [2]
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 [3]. DPNSS uses a 2048 kbits/s or
1544 kbits/s Digital Transmission System Interface as shown in
Figure 1 below.
Mukundan, et. al. [Page 3]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
---------- ---------- o--o
| | 2048 kbits/s | |------- /\
| |--------------| | --
| PBX | 1544 kbits/s | AN |
| |--------------| | o--o
| | | |------- /\
---------- ---------- --
Figure 1
Channel 16 on a 2048 kbits/s (E1) interface and channel 24 on a
1544 kbits/s (T1) 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
****** 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
This section outlines the differences between DUA and IUA.
2.1 New Message Class for 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 neccessary to use a different
message class parameter for DUA messages.
Mukundan, et. al. [Page 4]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
For all DPNSS/DASS2 interface boundary primitives, a new Message
Class is introduced:
13 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
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.
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 ND1301:2001/03 (formerly 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
Mukundan, et. al. [Page 5]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
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
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:
Mukundan, et. al. [Page 6]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
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.
Mukundan, et. al. [Page 7]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
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 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
IANA has assigned a DUA value for the SCTP Payload Protocol
Identifier field used in SCTP Payload Data chunks. The following
Mukundan, et. al. [Page 8]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
value for the SCTP Payload Protocol Identifier field SHOULD be used
for DUA:
SCTP Payload Protocol ID = "10"
4.0 Use of SCTP Payload Protocol ID
As an option, 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 Payload Protocol ID of "10" SHOULD be used for DUA if only
DPNSS is backhauled over a 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.
The User Adaptation peer MAY use the Payload Protocol Identifier as
a way of determining whether the message is for IUA or DUA.
5.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.
5.1 Resetting of single DLC
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_OTHER,Ind=1)
Mukundan, et. al. [Page 9]
Internet Draft draft-ietf-sigtran-dus-08.txt Sept 2004
5.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)
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
a Est Req(Ind=0) and the SG will retry the appropriate DLC that
is out-of-service.
5.3 Information Transfer on a DLC
PBX SG MGC
<----------- UI(C) <----------- Data Req
UI(R)-----------> Data Ind ----------->
5.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)
5.5 Link Takedown(All DLCs)
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)
Mukundan, et. al. [Page 10]
Internet Draft draft-ietf-sigtran-dus-08.txt Sept 2004
5.6 Getting link Status
PBX SG MGC
<----------- Stat Req
Stat Cfm -----------> (Mark DLC status
based on
status bits)
5.7 Error conditions
PBX SG MGC
Invalid Message <-----------Est/Rel/Data/-
Stat Req
Error Ind ----------->
(Error Code)
6.0 Security Considerations
The security considerations discussed for the ISDN User Adaptation
Protocol (IUAP) [1] Section 6.0 and the Security Considerations
for SIGTRAN Protocols document [4] apply to this document as well.
7.0 References
7.1 Normative References
[1] Morneault, et al., ISDN Q.921-User Adaptation Layer RFC3057)
February 2001
[2] Ofcom/NICC ND1301:2001/03, DPNSS [188], Digital Private
Signalling System No 1 (DPNSS 1) (Formerly BTNR 188).
[3] BTNR (British Telecom Network Requirements) 190 Issue 2
Digital Access Signaling System No 2
[4] Loughney, et al., Security Considerations for Signaling
Transport (SIGTRAN) Protocols, RFC 3788, June 2004
7.2 Informative References
[5] ETS 300 167 (08/1993) : Transmission and Multiplexing;
Functional characteristic of 2048 kbits/s interfaces
(Standard is based on G.704, G.706).
8.0 Acknowledgments
The authors would like to thank Shashi Kumar and Venkatesh
Seshasayee of Wipro Technologies for their useful suggestions and
comments.
Mukundan, et. al. [Page 11]
Internet Draft draft-ietf-sigtran-dua-08.txt Sept 2004
9.0 Author's Addresses
All correspondence regarding this draft should be sent to
the following addresses:
Ranjith Mukundan Phone: +91-80-51195893
Wipro Technologies Email: [email protected]
72, Electronics City
Hosur Main Road
Bangalore 560100
India
Ken Morneault Phone: +1-703-484-3323
Cisco Systems Inc. EMail: [email protected]
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Narsimuloo Mangalpally Phone: +1-613-967-5034
Nortel Networks EMail: [email protected]
250 Sidney Street
Belleville, Ontario K8P 3Z3
Canada
10.0 Full Copyright Statement
"Copyright (C) The Internet Society (2004). 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."
"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."
Mukundan, et. al. [Page 12]
| ||||||||||||||||
| Last modified: Wed, 27 Nov 2024 03:43:47 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||