[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-anil-sigtran-dua) 00 01 02 03 04 05 06 07 08 RFC 4129

Network Working Group                                       R. Mukundan
                                                     Wipro Technologies
                                                          Ken Morneault
                                                          Cisco Systems
                                                          N Mangalpally
                                                        Nortel Networks
Expires in 6 months                                            Oct 2003



                DPNSS/DASS 2 extensions to the IUA protocol
                      <draft-ietf-sigtran-dua-07.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 ......................................... 2
        1.1  Scope ............................................. 2
        1.2  Terminology ....................................... 2
        1.3  DPNSS Overview .................................... 3
        1.4  Proposed DPNSS Backhaul Architecture .............. 3

Mukundan, et. al.                                              [Page 1]

Internet Draft       draft-ietf-sigtran-dua-07.txt             Oct 2003


      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  Management (MGMT) Messages......................... 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 Security Considerations............................... 9
      6.0 References............................................ 9
      7.0 Acknowledgements...................................... 10
      8.0 Acknowledgements...................................... 10
      9.0 Editor's Addresses.................................... 10

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.

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.

Mukundan, et. al.                                              [Page 2]

Internet Draft        draft-ietf-sigtran-dua-07.txt            Oct 2003


       - 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 (reference BTNR 188) [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.

           ----------              ----------        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".






Mukundan, et. al.                                              [Page 3]

Internet Draft        draft-ietf-sigtran-dua-07.txt            Oct 2003


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.

   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.


Mukundan, et. al.                                              [Page 4]

Internet Draft        draft-ietf-sigtran-dua-07.txt            Oct 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-07.txt            Oct 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-07.txt            Oct 2003


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

   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 MAY be used, for instance,
   if one wanted to backhaul ISDN and DPNSS over the same SCTP association.

   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]

Internet Draft        draft-ietf-sigtran-dua-07.txt            Oct 2003


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

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)

   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.

4.3 Information Transfer on a DLC

           PBX                     SG                        MGC
                <----------- UI(C)            <----------- Data Req
           UI(R)----------->         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)

Mukundan, et. al.                                              [Page 8]

Internet Draft        draft-ietf-sigtran-dua-07.txt            Oct 2003


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

4.6 Getting link Status

           PBX                     SG                        MGC
                                          <-----------  Stat Req
                                 Stat Cfm -----------> (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 Security Considerations

   The security considerations discussed for the ISDN User Adaptation
   Protocol (IUAP) [1][4] Section 6.0 and the Security Considerations
   for SIGTRAN Protocols document [5] apply to this document as well.

6.0  References

6.1  Normative 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]  Morneault, et al., IUA (RFC3057) bis, draft-ietf-sigtran-
   rfc3057bis-00.txt, May 2003

   [5]  Loughnet, et al., Security Considerations for SIGTRAN Protocols,
   draft-ietf-sigtran-security-03.txt, June 29, 2003

6.2  Informative References

   [6]  ETS 300 167 (08/1993) : Transmission and Multiplexing;
   Functional characteristic of 2048 kbits/s interfaces
   (Standard is based on G.704, G.706).


Mukundan, et. al.                                              [Page 9]

Internet Draft        draft-ietf-sigtran-dua-07.txt            Oct 2003



7.0  Acknowledgments

   The authors would like to thank  Subhas Mondal and Sivaram
   Subramanian of Nortel Networks for their useful suggestions/
   comments.

8.0  Contributors

   In addition to the listed authors, the following person contributed
   significantly to this document:

   Anil Vydyam
   Nortel Networks
   Email:  anil.vydyam@wipro.com

9.0  Author's Addresses

   All correspondence regarding this draft should be sent to
   the following addresses:

   Ranjith Mukundan                 Phone +91-80-8520408
   Wipro Technologies               Email ranjith.mukundan@wipro.com
   72, Electronics City,
   Hosur Main Road,
   Bangalore 561229
   India

   Ken Morneault                    Phone: +1-703-484-3323
   Cisco Systems Inc.               EMail: kmorneau@cisco.com
   13615 Dulles Technology Drive
   Herndon, VA. 20171
   USA

   Narsimuloo Mangalpally           Phone +1 613 967 5034
   250 Sidney Street                EMail narsim@nortelnetworks.com
   Belleville, Ontario K8P 3Z3
   Canada


























Mukundan, et. al.                                             [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/