Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

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-bidulock-sigtran-regext-00

Description: Request For Comments

You can download source copies of the file as follows:

draft-bidulock-sigtran-regext-00.txt in text format.
draft-bidulock-sigtran-regext-00.ps in ps format.
draft-bidulock-sigtran-regext-00.pdf in pdf format.

Listed below is the contents of file draft-bidulock-sigtran-regext-00.txt.




Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation

Expires in six months                                    January 7, 2003

              Session Identification Registration (SESSID)
                                  for
                   Signalling User Adaptation Layers
                 <draft-bidulock-sigtran-regext-00.txt>

Status of this Memo

      This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 or RFC 2026.  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

      To learn the current status of any Internet-Draft, please check
   the Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

      This memo describes Registration Extensions that provides the
   ability for an Application Server Process (ASP) to modify existing
   Routing Keys (RKs) with a Signalling Gateway (SG).

      Current procedures in the SS7 Signalling User Adaptation Layers
   (UAs) do not provide for the modification of Routing Keys (RKs)
   without deactivation of the Application Server (AS).  This causes
   problems in making changes to live systems.

      The extensions described in this memo permit modification of
   Signalling Link membership in Application Servers for SS7 MTP2-User

B. Bidulock                    Version 0.0                        Page 1

Internet Draft                   SESSID                  January 7, 2003

   Adaptation Layer [M2UA], modification of Circuit Identification Code
   (CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA],
   modificiation of Destination Local Reference (DLR) ranges for SS7
   SCCP-User Adaptation Layer [SUA], and modification of Transaction
   Identifier (TID) ranges for SS7 TCAP-User Adaptation Layer [TUA].

1.  Introduction

1.1.  Scope

      This Internet-Draft provides parameters and procedures in
   extension to the parameters and procedures of the SS7 Signalling User
   Adaptation Layers (UAs) [M2UA, M3UA, SUA, TUA], for the purpose of
   supporting changed to Routing Keys to be made in live systems.

      UA implementations with REGEXT are intended to be compatible with
   UA implementations not supporting this extension.

1.2.  Terminology

      REGEXT adds the following terms to the terminology presented in
   the UA documents:

   Registration Extension - The parameters and procedures described by
      this memo.

   Signalling Peer Process - refers to an ASP, SGP or IPSP.

   Signalling User Adaptation Layer (UA) - one or more of the Stream
      Control Transmission Protocol (SCTP) [RFC 2960] SS7 Signalling
      User Adaptation Layers [M2UA, M3UA, SUA, TUA] supporting
      Registration.

1.3.  Overview

      Existing registration mangement procedures do not provide for the
   alteration of Routing Keys on live systems.  This can lead to
   significant operational difficulties in large scale deployments.
   This memo provides extension procedures that permit this
   modification.

1.3.1.  Limitations of Existing Registration Management

      Each of the UAs [M2UA, M3UA, SUA, TUA] provides procedures for
   registration and deregistration of Routing (Link) Keys.  None of
   these procedures currently provides for alteration of Routing Keys
   for a Application Server (AS) in the active state.

      In SS7 MTP2-User Adaptation Layer [M2UA] registration of a Link
   Key associates a signalling link with an Interface Identifier (IID).
   However, registration does not provide a mechanism for associating
   groups of Interface Identifiers (IID) together into Application
   Servers (AS), nor does it provide a mechanism for altering the
   membership of signalling links associated with an Application Server.

B. Bidulock                    Version 0.0                        Page 2

Internet Draft                   SESSID                  January 7, 2003

      The SS7 MTP3-User Adaptation Layer [M3UA] registration of a
   Routing Key associates a range of tranffic with an Application Server
   through a Routing Context.  However, it does not provide procedures
   for changing the range of traffic associated with an Application
   Server and Routing Context without deactivating the Application
   Server and deregistering the Routing Key.  This can cause
   difficulties when M3UA is used in support of ISUP MTP3-Users where
   normal circuit management expects to add and remove specific circuits
   or ranges of circuits (circuit groups) to and from Application
   Servers.

      The SS7 SCCP-User Adaptation Layer [SUA] registration of a Routing
   Key associates a range of traffic with an Application Server through
   a Routing Context and the Address Mapping Fucntion.  However, it does
   not provide procedures for changing the range of traffic associated
   with an Application Server and Routing Context without deactivating
   the Application Server and deregistering the Routing Key.  This can
   cause difficulties when SUA is used in the connection-oriented
   environment and the ASP wishes to dynamically assign connections to
   Application Servers.

      The SS7 TCAP-User Adapatation Layer [TUA] registration of a
   Routing Key associates a range of traffic wtih an Application Server
   through a Routing Context and the Transaction Mapping Function.
   However, it does not provide procedures for changing the range of
   traffic associated with an Application Server and Routing Context
   without deactivating the Application Server and deregistering the
   Routing Key.  This can cause difficulties when TUA is used in
   operations class 1, 2 and 3 (dialogues) and the ASP wishes to
   dynamically assign dialogues to Application Servers.

1.3.2.  Registration Extension

      This memo provides extensions for the UA registration and
   dregistration procedures which addresses these limitations in the
   existing prcoedures.  REGEXT provide the following

1.3.2.1.  M2UA

1.3.2.2.  M3UA

1.3.2.3.  SUA

1.3.2.4.  TUA

2.  Conventions

      The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC 2119].

B. Bidulock                    Version 0.0                        Page 3

Internet Draft                   SESSID                  January 7, 2003

3.  Protocol Elements

      The following subsections describe the parameters which are added
   or whose use is modified by this extension, their format and the
   messages in which they are used.

3.1.  Parameters

      Registration Extensions does not add any new parameters, but
   permits the use of the Routing Context parameter within a Routing Key
   parameter.  It also allows the use of the Routing Key parameter
   within a DEREG REQ message.

3.1.1.  Routing Key

      REGEXT augments the Link Key parameter of M2UA [M2UA] and the
   Routing Key parameters of M3UA, SUA, and TUA [M3UA, SUA, TUA].

3.1.1.1.  M2UA Link Key

3.1.1.2.  M3UA Routing Key

      The Routing Key parameter is used in the REG REQ and DEREG REQ
   messages.  It is used to identify the portion of traffic for which an
   ASP is registering or deregistering.

      The Routing Key parameter is formatted as follows:

B. Bidulock                    Version 0.0                        Page 4

Internet Draft                   SESSID                  January 7, 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 = 0x0207         |            Length             |
     +-------------------------------+-------------------------------+
     |                      Local-RK-Identifier                      |
     +---------------------------------------------------------------+
     |                 Traffic Mode Type (optional)                  |
     +---------------------------------------------------------------+
     |                  Routing Context (optional)                   |
     +---------------------------------------------------------------+
     |                 Network Appearance (optional)                 |
     +---------------------------------------------------------------+
     |                     Destination Point Code                    |
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                 Service Indicators (optional)                 |
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |               Originating Point Code (optional)               |
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                 Circuit Range List (optional)                 |
     +---------------------------------------------------------------+
     \                                                               \
     /                              ...                              /
     \                                                               \
     +---------------------------------------------------------------+
     |                     Destination Point Code                    |
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                 Service Indicators (optional)                 |
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |               Originating Point Code (optional)               |
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                 Circuit Range List (optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Routing Key parameter contains the following sub-parameters:

   Local-RK-Identifier parameter: TLV

     The mandatory Locak-RK-Identifier parameter is used to uniquely
     identify the registration request.  The Local-RK-Identifier value
     is assigned by the ASP, and is used to correlate the response in an
     REG RSP message with the original registration request.  THe Locak-
     RK-Identifier value must remain unique until the REG RSP message is
     received.

     The format of the Local-RK-Identifier is as follows:

B. Bidulock                    Version 0.0                        Page 5

Internet Draft                   SESSID                  January 7, 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 = 0x020a         |            Length = 8         |
       +-------------------------------+-------------------------------+
       |                      Local-RK-Identifier                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1.3.  SUA Routing Key

3.1.1.4.  TUA Routing Key

Routing Key

3.2.  Messages

4.  Procedures

4.1.  Regsitration

4.1.1.  Registration Procedures

4.1.2.  Deregistration Procedures

4.2.  AS and ASP State Maintenance

4.2.1.  ASP State

4.2.2.  AS State

4.2.3.  ASP Up Procedures

4.2.4.  ASP Down Procedures

4.2.5.  ASP Active Procedures

4.2.6.  ASP Inactive Procedures

4.2.7.  Notify Procedures

5.  Examples

6.  Security

7.  IANA Considerations

Acknowledgments

      The authors would like to thank for their valuable comments and
   suggestions.

B. Bidulock                    Version 0.0                        Page 6

Internet Draft                   SESSID                  January 7, 2003

Notes

References

   M2UA.
        K. Morneault, R. Dantu, G. Sidebottom, T. George, B. Bidulock
        and J. Heitz, "SS7 MTP2-User Adaptation Layer (M2UA)," <draft-
        ietf-sigtran-m2ua-12.txt>, Internet Engineering Task Force -
        Signalling Transport Working Group (December, 2001).  Work In
        Progress.

   M3UA.
        G. Sidebottom, J. Pastor-Balbas, I. Rytina, G. Mousseau, L. Ong,
        H. J. Schwarzbauer, K. Gradischnig, K. Morneault, M. Kalla, N.
        Glaude, B. Bidulock and J. Loughney, "SS7 MTP3-User Adaptation
        Layer (M3UA)," <draft-ietf-sigtran-m3ua-11.txt>, Internet
        Engineering Task Force - Signalling Transport Working Group
        (January, 2002).  Work In Progress.

   SUA.
        J. Loughney, G. Sidebottom, G. Mousseau, S. Lorusso, L. Coene,
        G. Verwimp, J. Keller, F. E. Gonzalez, W. Sully, S. Furniss and
        B. Bidulock, "SS7 SCCP-User Adaptation Layer (SUA)," <draft-
        ietf-sigtran-sua-10.txt>, Internet Engineering Task Force -
        Signalling Transport Working Group (December 27, 2001).  Work In
        Progress.

   TUA.
        B. Bidulock, "SS7 TCAP-User Adaptation Layer (TUA)," <draft-
        bidulock-sigtran-tua-01.txt>, Internet Engineering Task Force -
        Signalling Transport Working Group (January 2, 2003).  Work In
        Progress.

   RFC 2960.
        R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer,
        T. Taylor, I. Rytina, H. Kalla, L. Zhang and V. Paxson, "Stream
        Control Transmission Protocol (SCTP)," RFC 2960, The Internet
        Society (February 2000).

   RFC 2119.
        S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels," RFC 2119 - BCP 14, Internet Engineering Task Force
        (March 1997).

B. Bidulock                    Version 0.0                        Page 7

Internet Draft                   SESSID                  January 7, 2003

Author's Addresses

   Brian Bidulock                                 Phone: +1-972-839-4489
   OpenSS7 Corporation                       Email: bidulock@openss7.org
   4701 Preston Park Boulevard               URL: http//www.openss7.org/
   Suite 424
   Plano, TX  75093
   USA

   This Internet draft expires July, 2002.

B. Bidulock                    Version 0.0                        Page 8

Internet Draft                   SESSID                  January 7, 2003

                       List of Illustrations

                         Table of Contents

  1 Introduction ................................................    2
  1.1 Scope .....................................................    2
  1.2 Terminology ...............................................    2
  1.3 Overview ..................................................    2
  1.3.1 Limitations of Existing Registration Management .........    2
  1.3.2 Registration Extension ..................................    3
  2 Conventions .................................................    3
  3 Protocol Elements ...........................................    4
  3.1 Parameters ................................................    4
  3.1.1 Routing Key .............................................    4
  3.2 Messages ..................................................    6
  4 Procedures ..................................................    6
  4.1 Regsitration ..............................................    6
  4.1.1 Registration Procedures .................................    6
  4.1.2 Deregistration Procedures ...............................    6
  4.2 AS and ASP State Maintenance ..............................    6
  4.2.1 ASP State ...............................................    6
  4.2.2 AS State ................................................    6
  4.2.3 ASP Up Procedures .......................................    6
  4.2.4 ASP Down Procedures .....................................    6
  4.2.5 ASP Active Procedures ...................................    6
  4.2.6 ASP Inactive Procedures .................................    6
  4.2.7 Notify Procedures .......................................    6
  5 Examples ....................................................    6
  6 Security ....................................................    6
  7 IANA Considerations .........................................    6

B. Bidulock                    Version 0.0                        Page 9

Internet Draft                   SESSID                  January 7, 2003

Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

      This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise explain
   it or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedure for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate into languages other than
   English.

      The limited permission granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS 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 MECHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

B. Bidulock                    Version 0.0                       Page 10


Last modified: Wed, 12 Nov 2014 08:48:25 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.