Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4129

Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol

Pages: 15
Proposed Standard

Top   ToC   RFC4129 - Page 1
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.

Copyright Notice

   Copyright (C) The Internet Society (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.
Top   ToC   RFC4129 - Page 2

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

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.

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]
Top   ToC   RFC4129 - Page 3
   Unless specifically mentioned, the details in this document are
   applicable to both DPNSS and DASS 2.

1.2. Terminology

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. 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 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 an 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. 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].
Top   ToC   RFC4129 - Page 4

1.3. DPNSS Overview

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. ---------- ---------- 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".
Top   ToC   RFC4129 - Page 5

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. 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 necessary to use a different message class parameter for DUA messages. 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
Top   ToC   RFC4129 - Page 6

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 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: 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.
Top   ToC   RFC4129 - Page 7
      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 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.
Top   ToC   RFC4129 - Page 8
   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).
Top   ToC   RFC4129 - Page 9
   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 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.

   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
Top   ToC   RFC4129 - Page 10
   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. IANA Considerations

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: SCTP Payload Protocol 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. 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.
Top   ToC   RFC4129 - Page 11

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

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 an
Top   ToC   RFC4129 - Page 12
   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)

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)
Top   ToC   RFC4129 - Page 13

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

[1] Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, 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, J., Tuexen, M., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8. Acknowledgements

The authors would like to thank Shashi Kumar and Venkatesh Seshasayee of Wipro Technologies for their useful suggestions and comments.
Top   ToC   RFC4129 - Page 14

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 Phone: +91-80-51195893 EMail: ranjith.mukundan@wipro.com Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA Phone: +1-703-484-3323 EMail: kmorneau@cisco.com Narsimuloo Mangalpally Nortel Networks 250 Sidney Street Belleville, Ontario K8P 3Z3 Canada Phone: +1-613-967-5034 EMail: narsim@nortelnetworks.com
Top   ToC   RFC4129 - Page 15
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.

   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.

   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.

   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.

Acknowledgement

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