OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Wed, 07 Jan 2009 08:59:22 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-ranjith-sigtran-gr303ua-00
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-ranjith-sigtran-gr303ua-00

Description: Request For Comments

You can download source copies of the file as follows:

draft-ranjith-sigtran-gr303ua-00.txt in text format.

Listed below is the contents of file draft-ranjith-sigtran-gr303ua-00.txt.


Internet Engineering Task Force                         Ranjith Mukundan
                                                      Wipro Technologies
                                                           Ken Morneault
                                                           Cisco Systems
Expires in six months                                       October 2002

                   GR-303 extensions to the IUA protocol
                    <draft-ranjith-sigtran-gr303ua-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 [1].

   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 GR-303 [2]
   messages over IP by extending the ISDN User Adaptation Layer
   Protocol [3] and to be the base for a GR-303 User Adaptation (GR-
   303UA) implementation.

Table of Contents

   1.0 Introduction ..................................................2
      1.1 Scope ......................................................2
      1.2 Terminology ................................................3
      1.3 GR-303 Overview ............................................3
      1.4 Proposed GR-303 Backhaul Architecture ......................5
   2.0 Changes from IUA ..............................................6
      2.1  New Message Classes for GR-303UA ..........................6
      2.2  Message Header ............................................6
   3.0 IANA Considerations ...........................................8
   4.0 Security Considerations .......................................8
   5.0  References ...................................................9

Ranjith Mukundan/Ken Morneault                                  [Page 1]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

      5.1 Normative References .......................................9
      5.2 Informative References .....................................9
   6.0 Acknowledgements .............................................10
   7.0 Author's Addresses ...........................................10

1.0 Introduction

   This document describes a method of implementing GR-303 [2] backhaul
   messaging over IP using a modified version of the ISDN User
   Adaptation Protocol (IUAP) [3].  The GR-303UA builds on top of IUA
   defining the necessary extensions to IUA for GR-303 implementation.

1.1 Scope

   There is a need for Switched Circuit Network (SCN) GR-303 signaling
   protocol delivery, to cater to two scenarios:

        Scenario 1:  Delivery from a GR-303 Signaling Gateway (SG) to 
        a Media Gateway Controller (MGC). In this scenario, the
        traditional "TDM-based" Remote Digital Terminal (RDT) will
        interconnect to a SG.

        Scenario 2:  Delivery from an "IP-based" distributed Remote
        Digital Terminal (RDT) to a Voice Gateway (VG). In this
        scenario, the VG will connect to a traditional "TDM-based"
        Local Digital Switch (LDS).

   The delivery mechanism should support the following GR-303 protocol
   entities:

        - Time-slot Management Channel (TMC) Protocol [2]
        - Common Signaling Channel (CSC) Protocol [2]
        - Embedded Operations Channel (EOC) Protocol [2 & 4]

   Unless specifically mentioned, the details in this document are
   applicable to all the three aforementioned GR-303 protocol entities.

   It is to be noted that, owing to the 'hybrid' nature of the GR-303
   signaling system, in the GR-303 TMC option, call processing and
   terminal supervision signaling also comprises of specific in-band
   Robbed Bit Signaling (RBS) signals (ABCD bit patterns) for different
   types of subscriber-loops (e.g., Ground Start, Loop Start, Loop
   Reverse Battery etc). To transport the in-band signals over the IP
   network, other protocols like MEGACO [6]/Media Gateway Control
   Protocol (MGCP) [7] (with concomitant new or existing MEGACO/MGCP
   packages) OR RTP [8 & 9] will have to be used in conjunction with
   GR-303UA. Typically, MEGACO/MGCP would be used in scenario 1 and RTP
   in Scenario 2.

Ranjith Mukundan/Ken Morneault                                  [Page 2]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

1.2 Terminology

   Remote Digital Terminal (RDT) - An access system located in the
   outside plant. RDT's main function is to multiplex traffic from a
   number of subscriber lines onto a high-speed transmission facility
   (SONET, DS3, or DS1s) for transport to/from the central office.  The
   maximum number of access lines per RDT is 2048 per interface group.
   These access lines can be made to share between 1 and 28 DS1s with
   the flexible concentration supported by GR-303. When the number of
   DS1 facilities are 2 or more, GR-303 signaling interface
   specification mandates a stand-by "protection" signaling channel to
   be supported on a DS1 facility different from the DS1 facility that
   hosts the primary signaling channels.

   Integrated Digital Terminal (IDT) - The switch resources used to
   manage and support a single interface group of the RDT. The IDT
   interface coordinates operations, administration, and management of
   the RDT, including facility terminations, control data links, and
   other functions.

   Local Digital Switch (LDS) - The switching system (Class-5) located
   in the central office that provides switched services such as POTS,
   ISDN, or Centrex to subscriber lines on RDTs. An IDT is a logical
   entity within the LDS.

1.3 GR-303 Overview

   GR-303 is a Bellcore specification [2] that defines a set of generic
   interface requirements that allow Class-5 digital switches from one
   vendor to interface with access systems from another.  Access
   systems include digital loop carriers (DLCs) or hybrid fiber/coax
   residential broadband systems that are typically used to provide
   service to remote concentration groups, as well as extending the
   service areas.

   The Figure 1 below shows the major building blocks of an Integrated
   Digital Loop Carrier (IDLC) using GR-303 interface. An IDLC system
   consists of an integrated digital terminal (IDT) located in the
   switch and a remote digital terminal (RDT) located in the outside
   plant or in some cases at the customer premise. GR-303 provides for
   flexible concentration of bandwidth into the LDS for analog
   services, and 4:1 Integrated Service Digital Network (ISDN) Basic
   Rate Access (BRA).  In addition, it provides extensive Operations,
   Administration, Management & Provisioning (OAM&P) capabilities for
   managing RDTs.

Ranjith Mukundan/Ken Morneault                                  [Page 3]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

        +-----------+  GR-303 interface
        |   LDS     | Group (1 - 28 DS1s)
        |           |                     +--------+        o--o
        |           |        DS1          |        |-------  /\
        |    +------|---------------------|        |         --
        |    | IDT  |        DS1          |  RDT   |
        |    +------|---------------------|        |        o--o
        |           |                     |        |-------  /\
        +-----------+                     +--------+         --

             |<---------- IDLC system ------------->|

                  Figure 1 GR-303 IDLC System

   The maximum number of DS0s supported is 672.  Four of these DS0s
   are reserved for signaling (EOC and TMC/CSC on primary DS1, EOC and
   TMC/CSC on protection DS1).

   The GR-303 interface is composed of 1 to 28 DS-1 facilities
   connecting the IDT at the central office and the RDT. Standby
   signaling channel protection is not available when there is only D1
   in the GR-303 interface. For GR-303 interface spanning 2 or more
   (upto 28) DS1s, two of these DS-1 facilities carry signaling
   channels. The first carries the primary signaling channels, while a
   separate DS-1 facility is used to carry the redundant signaling
   channels for protection.

   GR-303 defines three types of message-based signaling channels

   1.  Embedded Operations Channel (EOC) - Uses a DS0 (64kbps, clear
   channel) on the primary DS1 facility (time slot # 12). And another
   DS0 is used  for EOC protection on a separate DS1 facility.  The EOC
   channel is primarily used for carrying Path Protection Switching (PPS) 
   and OAM&P-related messaging.  The higher layer protocols used with 
   this channel include LAPD subset for layer 2, Convergence sub-layer &
   Common Management Information Service Element (CMISE)/Remote
   Operations Services Element (ROSE)/ASN.1 sub-layer for layer 3.

   2.  Timeslot Management Channel (TMC) - Uses a DS0 (64kbps, clear
   channel) on the primary DS1 facility (time slot # 24).  And another
   DS0 is used for TMC protection on a separate DS1 facility.  The TMC
   channel is primarily used to perform per-call time-slot allocation
   and call processing messages between the RDT and the LDS.  The
   higher layer protocols used with this channel are LAPD subset for
   layer 2, and a subset of Q.931 for layer 3.

Ranjith Mukundan/Ken Morneault                                  [Page 4]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

   As mentioned earlier in this document, when TMC is used, the bearer
   channels will still need to use RBS for transmitting call-processing
   and subscriber line supervision in-band messages between the RDT and
   the LDS.  In other words, signaling between the RDT and IDT is a
   hybrid of time slot management channel and robbed-bit (TMC/RBS)
   signaling.

   3.  Common Signaling Channel (CSC) - This signaling channel is an 
   option that is used instead of TMC for clean out-of-band signaling
   implementation. In this case, bearer channels are not required to
   carry RBS since CSC messages handle both call supervision and time
   slot assignment. The higher layer protocols used with this channel
   are LAPD subset for layer 2, and a subset of Q.931 for layer 3.

1.4 Proposed GR-303 Backhaul Architecture

   Figure 2 below, depicts the backhaul architecture for the two
   scenarios described earlier.

              Scenario 1

              ******    GR-303     ******      IP      *******
              *RDT *---------------* SG *--------------* MGC *
              ******               ******              *******

              Scenario 2

              ******    GR-303     ******      IP      ********
              *LDS *---------------* VG *--------------*IP-RDT*
              *    *               *(SG)*              *      *
              ******               ******              ********

              +-----+                                  +-------+
              |GR303|              (NIF)               | GR303 |
              | L3  |                                  |   L3  |
              +-----+         +-----+-------+          +-------+
              |     |         |     |GR303UA|          |GR303UA|
              |GR303|         |GR303+-------+          +-------+
              | L2  |         | L2  | SCTP  |          | SCTP  |
              |     |         |     +-------+          +-------+
              |     |         |     |  IP   |          |  IP   |
              +-----+         +-----+-------+          +-------+

                    Figure 2 GR-303 Backhaul Architecture

Ranjith Mukundan/Ken Morneault                                  [Page 5]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

         NIF      - Nodal Interworking function
         SCTP     - Stream Control Transmission Protocol
         GR303UA  - GR-303 User Adaptation Layer Protocol
         GR303 L2 - A subset of LAPD
         GR303 L3 - TMC/CSC (a Q.931 subset) OR
                    EOC Convergence & CMISE/ROSE/ASN.1 sub-layers

2.0 Changes from IUA

   This section outlines the differences between GR-303UA and IUA.

2.1  New Message Classes for GR-303UA

   The GR-303 TMC/CSC and EOC 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 (i.e. V5 or DPNSS).  Therefore, it is neccessary to
   distinguish between these from other IUA-based boundary primitive
   transport message types [3] by means of the Message Class parameter.

   In order to support GR-303 layer 2 <=> layer 3 interface boundary
   primitives, the following Message Classes are introduced (to be
   assigned by IANA):

     12   GR-303 EOC Boundary Primitives Transport Messages (GEPTM)
     13   GR-303 TMC/CSC Boundary Primitives Transport Messages (GXPTM)

   Similar to IUA, other valid message classes for GR-303UA are the 
   following:

              0       Management (MGMT) Message
              3       ASP State Maintenance (ASPSM) Messages
              4       ASP Traffic Maintenance (ASPTM) Messages

2.2  Message Header

   IUA Message header [3] has the format as shown in Figure 3 below.
   GR-303UA, being extension of IUA, will have the same format.

Ranjith Mukundan/Ken Morneault                                  [Page 6]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

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

   Where, the Tag value for the Integer-based Interface Identifier is
   0x1. The length is always set to a value of 8.

   And the DLCI format is shown below in Figure 4.

               0     1     2     3     4     5     6     7
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |  0  | SPR |           SAPI                    |
            +-----------------------------------------------+
            |  1  |                 TEI                     |
            +-----------------------------------------------+

                            Figure 4  DLCI Format

   SPR : Spare 2nd bit in octet 1, (1 bit)
   SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
         1 (6 bits)
   TEI : Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
         (7 bits)

   The DLCI field (including the SAPI and TEI) is coded in accordance
   with Q.921.

   The following SAPI/TEI combinations shall be supported for GR-303
   TMC/CSC and EOC

   TMC Data-link function
   ----------------------

                          SAPI          TEI
   ------------------------------------------
    Call Processing        0             0
    TMC Path Switch Ops    1             0

Ranjith Mukundan/Ken Morneault                                  [Page 7]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

   EOC Data-link function
   ----------------------

                                     SAPI          TEI
   ----------------------------------------------------
    TMC Path Switch Ops               1             0
    RDT - Provisioning/Mem Admin      1             1
    RDT - Maint/Surveillance OS       1             2
    RDT - Testing OS                  1             3
    RDT - IDT                         1             4
    RDT - Test System Controller 1    1             5
    RDT - Test System Controller 2    1             6
    RDT - Test System Controller 3    1             7
    user assignable                   1             8
    user assignable                   1             9
    user assignable                   1            10
    user assignable                   1            11

3.0 IANA Considerations

   A request will be made to IANA to assign a GR-303UA 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 GR-303UA:

           SCTP Payload Protocol ID xxx - tba by IANA

   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, V5UA, DUA or
   GR-303UA.

4.0 Security Considerations

   The security considerations discussed for the IUA [3] Section 6.0 
   apply to this document as well.

Ranjith Mukundan/Ken Morneault                                  [Page 8]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

5.0  References

5.1 Normative References
                    
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.

[2] GR-303-CORE Issue 4, "IDLC Generic Requirements, Objectives, and
Interface", December 2000 and the associated Issues List Report GR-
303-ILR Issue 4A, December 2000.

[3] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057,
February 2001.

[4] GR-303-IMD, "IDLC System Generic Operations Interface" (formerly
TR-TSY-000303 Supplement 3), Issue 1, December 1998

[5]  IUA (RFC3057) Implementors Guide, draft-ietf-sigtran-iua-imp-
guide-01.txt, Oct 2002

5.2 Informative References

[6] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J.
Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.

[7] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S.,
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October
1999.

[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP
A Transport Protocol for Real-Time Applications", RFC 1889, January
1996.

[9] Schulzrinne, H. and Petrack, S., "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.

[10] TR-NWT-000057, "Functional Criteria for Digital Loop Carrier
Systems", Issue 2, January 1993.                                                                  

[11] ANSI T1.403, "Network and Customer Installation Interfaces - DS1
Electrical Interface", May 1999.

[12] ANSI T1.403.02, "Network and Customer Installation Interfaces -
DS1 Robbed-Bit Signaling State Definition", May 1999.

Ranjith Mukundan/Ken Morneault                                  [Page 9]

Internet Draft     draft-ranjith-sigtran-gr303ua-00.txt     October 2002

6.0 Acknowledgments

   None

7.0 Author's 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

Ranjith Mukundan/Ken Morneault                                 [Page 10]



OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-ranjith-sigtran-gr303ua-00
Last modified: Wed, 07 Jan 2009 08:59:22 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.