[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-sigtran-dua

Internet Engineering Task Force                             Anil Vydyam
                                                       Ranjith Mukundan
                                                 Narsimuloo Mangalpally
                                                        Nortel Networks
Expires in 6 months                                       November 2000



              DPNSS/DASS 2 extensions to the IUA protocol
                    <draft-anil-sigtran-dua-00.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 Version 9 (<draft-ietf-sigtran-iua-09.txt>).
   The document aims to become an Appendix to IUA and to be the
   base for a DUA implementation.


Table of Contents

   1.0 Introduction ......................................... 3
     1.1  Scope ............................................. 3
     1.2  Terminology ....................................... 3
     1.3  DPNSS Overview .................................... 3
     1.4  Proposed DPNSS Backhaul Architecture .............. 4
   2.0 Changes from IUA...................................... 4
     2.1  Message Header..................................... 4

Vydyam/Mukundan/Mangalpally                                           1

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

     2.2  Adaptation Layer Identifier........................ 5
     2.3  Unit Data Message.................................. 5
     2.4  Status Message..................................... 5
     2.5  Error Message...................................... 6
   3.0 IANA Considerations................................... 6
   4.0 Message Sequence in DUA............................... 6
     4.1  Resetting of single DLC............................ 6
     4.2  Resetting all DLCs in a link....................... 7
     4.3  Information Transfer on a DLC...................... 7
     4.4  Link Takedown(Single DLC).......................... 7
     4.5  Link Takedown(All DLCs)............................ 7
     4.6  Getting link Status................................ 7
     4.7  Error conditions................................... 7
   5.0 References ........................................... 8
   6.0 Author's Addresses.................................... 8

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 document aims to
   become an Appendix to IUA and to be the base for the "appli-
   cation guide".

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

Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

   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

   Channels 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

        ******   DPNSS       ******      IP      *******
        *PBX *---------------* SG *--------------* MGC *
        ******               ******              *******

        +-----+                                  +-----+
        |DPNSS|              (NIF)               |DPNSS|
        | L3  |                                  | L3  |
        +-----+           +----------+           +-----+

Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

        |     |           |     | 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  Message Header

   IUA Message header has the format as shown in Figure 2 below.

       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.


Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

         1            Action is to be performed on a single
                      DLC specified by channel number.

   This indicator value is used only by the Est and Rel 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.2 Adaptation Layer Identifier

   Adaptation Layer Identifier string must be set to "DUA" for the DUA
   applications.

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.

2.4 Status Message

   IUA MIUA-TEI STATUS Message has the following format:
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Status                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In DUA this will be known as the Status message and will have the
   following format.

           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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   +-+-+
   DLC  1 |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
   | DLC 16
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   +-+-+
   DLC 17 |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
   | DLC 32
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   +-+-+
   DLC 33 |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
   | DLC 48


Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   +-+-+
   DLC 49 |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
   | DLC 64
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   +-+-+

   These 4 words carry the status of DLCs using two bits for each DLC.
   These are the possible values for these two bits.

       Value          Description
         00        Out Of Service
         01        Reset Attempted
         10        Reset Completed
         11        Information Transfer

   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 only 2 words instead of 4 for DPNSS.

   For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2
   DLC does not have this state.

2.5 Error Message

   The ERR message is sent when an invalid value 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                        0x1
        Invalid Interface Identifier           0x2
        Invalid Adaptation Layer Identifier    0x3
        Invalid Message Type                   0x4
        Invalid Stream Identifier              0x5
        Unassigned TEI                         0x6
        Unrecognized SAPI                      0x7
        Invalid TEI, SAPI combination          0x8
        Invalid AS Mode Type                   0x9

   In DUA the error codes 0x6 to 0x8 are invalid as they are specific
   to ISDN.

   The following additional error codes are supported in DUA.

        Channel Number out of range            0xA
        Channel Not configured                 0xB

3.0 IANA Considerations

   A request will be made to IANA to assign a DUA value for the Payload

Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

   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

   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

Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

                                   (Ind=0)               are not
   updated )
                                           <----------- Stat Req
                                  Stat Res -----------> (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)

        PBX                     SG                        MGC
               (For DPNSS, mark all DLCs as OOS) <----------- Rel Req
               (For DASSII, mark all DLCs 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



Vydyam/Mukundan/Mangalpally                                           9

Internet Draft        draft-anil-sigtran-dua-00.txt       November 2000

       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]  ISDN Q.921-User Adaptation Layer <draft-ietf-sigtran-
        iua-09.txt>

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



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 and Narsimuloo Mangalpally

   All correspondence regarding this draft should be sent to
   the following address :
   Mick Dragon                      Tel. +44 (0)1628434388
   Nortel Networks plc              Email. mdragon@nortelnetworks.com
   Concorde Road
   Maidenhead
   Berkshire SL6 4AG
   United Kingdom









Vydyam/Mukundan/Mangalpally                                           9


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