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

Description: Request For Comments

You can download source copies of the file as follows:

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

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




Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation

Expires in six months                                    January 2, 2003

                    Registration Extensions (REGEXT)
                                  for
                   Signalling User Adaptation Layers
                 <draft-bidulock-sigtran-regext-01.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 (REGEXT) that provides
  the ability for an Application Server Process (ASP) to modify existing
  Routing (Link) Keys with a Signalling Gateway (SG).

     Current procedures in the SS7 Signalling User Adaptation Layers
  (UAs) [M2UA..TUA] do not provide for the modification of Routing
  (Link) Keys 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
  Adaptation Layer [M2UA], modification of Circuit Identification Code

B. Bidulock                    Version 0.1                        Page 1

Internet Draft                  UA REGEXT                January 2, 2003

  (CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA],
  modification of Circuit Identification Code (CIC) rnages for the SS7
  ISUP-User Adaptation Layer [ISUA], 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..TUA], for the purpose of supporting changed to
  Routing (Link) 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.  Change History

  Changes from Version 0.0 to Version 1.0:

   - added this section,
   - updated references,
   - addition of Source Reference Number, Destination Reference Number
     and Reference Number Range to SUA [SUA] Routing Key.
   - update author's address.

1.3.  Terminology

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

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

  Signalling Peer Process (SPP) - 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..TUA] supporting Registration.

1.4.  Overview

     Existing registration mangement procedures do not provide for the
  alteration of Routing (Link) 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.4.1.  Limitations of Existing Registration Management

     Each of the SS7 UAs [M2UA..TUA] provides procedures for
  registration and deregistration of Routing (Link) Keys.  None of these

B. Bidulock                    Version 0.1                        Page 2

Internet Draft                  UA REGEXT                January 2, 2003

  procedures currently provides for alteration of Routing (Link) Keys
  for a Application Server (AS) in the active state.

1.4.1.1.  Limitations of Registration for M2UA

     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 together into Application Servers
  (AS), nor does it provide a mechanism for altering the membership of
  signalling links associated with an Application Server.

1.4.1.2.  Limitations of Registration for M3UA

     The SS7 MTP3-User Adaptation Layer [M3UA] registration of a Routing
  Key associates a range of tranfic 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.[1]

1.4.1.3.  Limitations of Regsitration for ISUA

     The SS7 ISUP-User Adapatation Layer [ISUA] registration of a
  Routing Key associates a range of traffic 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 where
  normal circuit management expects to add and remove specific circuits
  or ranges of circuits (circuit groups) to and from Application
  Servers.[2]

1.4.1.4.  Limitations of Registration for SUA

     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.[2]

1.4.1.5.  Limitations of Registration for TUA

     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

B. Bidulock                    Version 0.1                        Page 3

Internet Draft                  UA REGEXT                January 2, 2003

  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 operation class 1, 2
  and 3 (dialogues) and the ASP wishes to dynamically assign dialogues
  to Application Servers.

1.4.2.  Registration Extension

     This memo provides extensions for the UA registration and
  dregistration procedures which addresses these limitations in the
  existing prcoedures.  REGEXT provides support for altering an existing
  Routing (Link) Key for an active Application Server.

1.4.2.1.  Registration Extensions for M2UA

     The purpose of REGEXT for M2UA [M2UA] is to support the Dynamic
  Allocation of Signalling Data Links and Signalling Terminals [Q.704],
  and, in particular, the ability to associate a new Signalling Link as
  specified by the combination of Signalling Data Link Identifier (SDLI)
  and Signalling Data Terminal Identifier (SDTI), with an existing
  Application Server.  This permits MTP Level 3 to perform the Level 1
  Connect and Level 1 Disconnect primitives, as well as associating a
  new Signalling Terminal with an existing Signalling Data Link for the
  Dynamic Allocation of Signalling Terminals.

                        SG                             ASP
                _________________                  ___________
               |         ______  |                |  _______  |
         SDL0  |        |      | |       IID0     | |       | |
        _______|_ _ _ __| SDT0 |_|________________|_|  AS0  | |
               |   ( /  |______| |                | |_______| |
               |    /    ______  |                |  _______  |
         SDL1  |   /    |      | |       IID1     | |       | |
        _______|__/     | SDT1 | |       _________|_|  AS1  | |
               |        |______| |      /         | |_______| |
               |         ______  |     /          |___________|
         SDL2  |        |      | |    /
        _______|________| SDT2 |_|___/
               |        |______| |
               |         ______  |
         SDL3  |        |      | |
        _______|        | SDT3 | |
               |        |______| |
               |_________________|

              Figure 1.  Example (A) - M2UA Configuration

     For example, an ASP is ASP-ACTIVE for a given Application Server
  and signalling data link and terminal wishes to replace the Signalling
  Data Link associated with a Signalling Link (under MTP Level 3 [Q.704]
  control).  The ASP wishes to replace the Signalling Data Link (SDL1)
  with the Signalling Data Link (SDL0) for the Signalling Link

B. Bidulock                    Version 0.1                        Page 4

Internet Draft                  UA REGEXT                January 2, 2003

  represented by AS0/IID0 as illustrated in Figure 1.

     REGEXT permits the ASP to perform this switch using the REG REQ
  message with the Interface Identifier IID0 placed in the message along
  with the Link Key SDT0/SDL0.  Examples are provided in Section 6.

1.4.2.2.  Registration Extensions for M3UA

     The purpose of REGEXT for M3UA [M3UA] is to support the
  modification of traffic to and from an active Application Server for
  operations, maintenance, administration and provisioning.  In
  particular this allows an MTP-User Part (SI value), Signalling Point
  Code or perhaps a Circuit Identification Code (CIC) range to be added
  or removed from an existing Routing Key associated with an active
  Application Server.

                                       STP             MGC
             ___                       ____           _____
            /   \     signalling      |   /|  assoc. |     |
           | SP1 |-------/-----/---/--| SG |---------| ASP |
            \___/\\     /     /   /   |/___|         |_____|
             ___  \\===/=====/===/=====================//
            /   \_____/     /   /     circuits        //
           | SP2 |         /   /                     //
            \___/\\       /   /                     //
             ___  \\=====/===/=====================//
            /   \_______/   /      circuits       //
           | SP3 |         /                     //
            \___/\\       /                     //
             ___  \\=====/=====================//
            /   \_______/       circuits      //
           | SP4 |                           //
            \___/\\                         //
                  \\+++++++++++++++++++++++//
                             circuits

              Figure 2.  Example (B) - M3UA Configuration

     For example, an ISUP Application Server wishes to add new trunk
  group(s) to a new Signalling Point Code (i.e. MGC).  The AS is
  currently registered against a Routing Key which includes several
  remote point codes, but does not include the remote point code of the
  switch to which the trunk group(s) are to be added (as illustrated in
  Figure 2).

     REGEXT permits the Application Server to provision the new trunk
  group(s) by adding the new remote point code to the Routing Key with
  the REG REQ message.

B. Bidulock                    Version 0.1                        Page 5

Internet Draft                  UA REGEXT                January 2, 2003

1.4.2.3.  Registration Extensions for ISUA

     The purpose of REGEXT for ISUA [ISUA] is to support the
  modification of traffic to and from an active Application Server for
  operations, maintenance, administration and provisioning.  In
  particular this allows perhaps a Circuit Identification Code (CIC)
  range to be added or removed from an existing Routing Key associated
  with an active Application Server.

                                       STP             MGC
             ___                       ____           _____
            /   \     signalling      |   /|  assoc. |     |
           | SP1 |-------/-----/---/--| SG |---------| ASP |
            \___/\\     /     /   /   |/___|         |_____|
             ___  \\===/=====/===/=====================//
            /   \_____/     /   /     circuits        //
           | SP2 |         /   /                     //
            \___/\\       /   /                     //
             ___  \\=====/===/=====================//
            /   \_______/   /      circuits       //
           | SP3 |         /                     //
            \___/\\       /                     //
             ___  \\=====/=====================//
            /   \_______/       circuits      //
           | SP4 |                           //
            \___/\\                         //
                  \\+++++++++++++++++++++++//
                             circuits

              Figure 3.  Example (C) - ISUA Configuration

     For example, an ISUP Application Server wishes to add new trunk
  group(s) to a new Signalling Point Code (i.e. MGC).  The AS is
  currently registered against a Routing Key which includes several
  remote point codes, but does not include the remote point code of the
  switch to which the trunk group(s) are to be added (as illustrated in
  Figure 3).

     REGEXT permits the Application Server to provision the new trunk
  group(s) by adding the new remote point code to the Routing Key with
  the REG REQ message.

1.4.2.4.  Registration Extensions for SUA

     The purpose of REGEXT for SUA [SUA] is to associate a newly formed
  connection with an Application Server that is responsible for the
  connection.  Almost all connection-oriented interface models (STREAMS,
  Sockets) rely on the concept of a listening stream or socket and an
  independent accepting stream or socket.  REGEXT permits an accepted
  connection to be established on an Application Server which is
  independent from the Application Server upon which the connection

B. Bidulock                    Version 0.1                        Page 6

Internet Draft                  UA REGEXT                January 2, 2003

  request was received.

                              SG                ASP
                           _________         _________
                          |         |       |         |
                 _________|___      |       |  _____  |
                 _________|___| RK2 |  RC2  | |     | |
                 _________|___|_____|_______|_| AS2 | |
                 _________|___|     |       | |     | |
                 _________|___|     |       | |_____| |
                 _________|___      |       |  _____  |
                 _________|___| RK1 |  RC1  | |     | |
                 _________|___|_____|_______|_| AS1 | |
                 _________|___|     |       | |     | |
                 _________|___|     |       | |_____| |
                          |         |       |  _____  |
                  connections   RK0 |  RC0  | |     | |
                 _________|_________|_______|_| AS0 | |
                          |         |       | |     | |
                          |         |       | |_____| |
                          |         |       |         |
                          |_________|       |_________|

               Figure 4.  Example (D) - SUA Configuration

     For example, as illustrated in Figure 4, one Application Server
  (AS0) is configured with a Routing Key which does not contain
  Destination Reference Number for SSN=5.  Another Application Server
  (AS1) processes some connections for SSN=5 and AS2 processes other
  connections.  When a CORE is received by AS0, and before sending a
  COAK, the ASP would like to assign the connection to one of AS1 or AS2
  for further communication associated with the newly arrived
  connection.

     REGEXT permits AS0 to modify Routing Key RK1 by sending a REG REQ
  message that includes Routing Context RC1 and the additional
  Destination Reference Number that is assigned to the connection,
  permitting the SCCP implementation to follow the Network Provider
  Interface [NPI].

     REGEXT also permits AS0 to modify the Routing Key on another
  Signalling Gateway with the complete fail-over support of the
  Application Server, avoiding many of the problems associated with DRN
  Label approach.

1.4.2.5.  Registration Extensions for TUA

     The purpose of REGEXT for TUA [TUA] is to associate a newly formed
  dialogue or transaction with an Application Server that is responsible
  for the dialogue or transaction.  Almost all connection-oriented
  interface models (STREAMS, Sockets) rely on the concept of a listening
  stream or socket and an independent accepting stream or socket.

B. Bidulock                    Version 0.1                        Page 7

Internet Draft                  UA REGEXT                January 2, 2003

  REGEXT permits an accepted dialogue or transaction to be established
  on an Application Server which is independent from the Application
  Server upon which the dialogue or transaction initiation was received.

                              SG                ASP
                           _________         _________
                          |         |       |         |
                 _________|___      |       |  _____  |
                 _________|___| RK2 |  RC2  | |     | |
                 _________|___|_____|_______|_| AS2 | |
                 _________|___|     |       | |     | |
                 _________|___|     |       | |_____| |
                 _________|___      |       |  _____  |
                 _________|___| RK1 |  RC1  | |     | |
                 _________|___|_____|_______|_| AS1 | |
                 _________|___|     |       | |     | |
                 _________|___|     |       | |_____| |
                          |         |       |  _____  |
                  dialogues     RK0 |  RC0  | |     | |
                 _________|_________|_______|_| AS0 | |
                          |         |       | |     | |
                          |         |       | |_____| |
                          |         |       |         |
                          |_________|       |_________|

               Figure 5.  Example (E) - TUA Configuration

     For example, as illustrated in Figure 5, one Application Server
  (AS0) is configured with a Routing Key which does not contain
  Terminating Transaction Id for a given Application Context.  Another
  Application Server (AS1) processes some dialogues and transactions for
  the Application Context, and AS2 processes other dialogues and
  transactions.  When a TBEG is received by AS0, and before sending a
  TCON, the ASP would list to assign the transaction to one of AS1 or
  AS2 for further communication associated with the newly arrived
  transaction.

     REGEXT permits AS0 to modify the Routing Key RK1 by sending a REG
  REQ message that includes Routing Context RC1 and the additional
  Terminating Transaction Id that is assigned to the transaction,
  permitting the TCAP implemetnation to follow the Transport Provider
  Interface [TPI, XNS].

     REGEXT also permits AS0 to modify the Routing Key on another
  Signalling Gateway with the complete fail-over support of the
  Application Server, permitting SGs to be configured as STP pairs in
  the SS7 network.

1.5.  Limitations

     Although the methods for dynamic modification of Routing Keys and
  Load Selections presented in this document is consistent with that

B. Bidulock                    Version 0.1                        Page 8

Internet Draft                  UA REGEXT                January 2, 2003

  previously discussed on the SIGTRAN WG, it has a number of
  limitations.  To change a Routing Key or Load Selections requires that
  the entire new key or selection be included in the REG REQ message.
  This may be especially inconvinent if the resulting Routing Key or
  Load Selection contains thousands of elements (as it might for CIC
  Ranges on large MGC).

     A method more ammeniable to this situation would be to use the REG
  REQ message to "add" elements to the Routing Key or Load Selection and
  use the DEREG REQ to "delete" elements from the Routing Key or Load
  Selection.

     A third approach would be to define two new messages, such as:
  Registration Add (REG ADD) and Registration Delete (REG DEL), but
  share the REG RSP message.  This last approach would probably be more
  convenient.

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

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

     This memo permits the use of the Routing Context (Interface
  Identifier) parameter within a Routing (Link) Key parameter.  It also
  allows the use of the Routing (Link) Key parameter within a DEREG REQ
  message.  This memo also defines a new Reference Number Range
  parameter for use in the SUA [SUA] Routing Key.  In addition, this
  memo permits the use of the Source Reference Number, Destination
  Reference Number and Reference Number Range parameters in the SUA
  [SUA] Routing Key.

3.1.1.  Routing Key Parameters

3.1.1.1.  SUA Reference Number Range

     REGEXT defines a new SUA [SUA] Reference Number Range parameter for
  use in the Routing Key in the REG REQ message.  This parameter is used
  to associate a range of source or destination reference numbers with
  an Application Server.

  The Reference Number Range parameter is formatted as follows: [3]

B. Bidulock                    Version 0.1                        Page 9

Internet Draft                  UA REGEXT                January 2, 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 = 0x0119          |            Length             |
   +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
   \                                                               \
   /                  Reference Number Parameter(s)                /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Reference Number Range parameter can contain the following fields:

  Reference Number field: variable (TLV parameters)

    The Reference Numbe field can contain the following parameters:

       Parameters
       ------------------------------------------------
       Source Reference Number        Conditional   *1
       Destination Reference Number   Conditional   *1

    Note 1: The Reference Number field must contain pairs of Source
            Reference Numbers or Destination Reference Numbers and MUST
            contain one and only one pair of addresses; but, MUST NOT
            mix Srouce Reference Numbers with Destination Reference
            Numbers in the same Reference Number field.

3.1.2.  Routing (Link) Key

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

3.1.2.1.  M2UA Link Key

  The M2UA [M2UA] Link Key parameter is formatted as follows:

    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 = 0x0309         |            Length             |
   +-------------------------------+-------------------------------+
   |                      Local-LK-Identifier                      |
   +---------------------------------------------------------------+
   \                                                               \
   /                        Key parameter(s)                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the M2UA Link Key parameter by adding the following
  parameters to the Link Key:

B. Bidulock                    Version 0.1                       Page 10

Internet Draft                  UA REGEXT                January 2, 2003

     Extension Sub-Parameters
     ------------------------------------------
     Interface Identifier        Optional   *1

  Note 1: The Interface Identifier parameter is optional in the Link
          Key.  This parameter identifies an existing Application Server
          for which the Link Key is to be altered.  The format of the
          Interface Identifier consists of a single integer Interface
          Identifier or a single text Interface Identifier.

3.1.2.2.  M3UA Routing Key

  The M3UA [M3UA] Routing Key parameter is formatted as follows:

    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                     |
   +---------------------------------------------------------------+
   \                                                               \
   /                        Key parameter(s)                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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.

     REGEXT extends the M3UA [M3UA] Routing Key parameter by allowing
  the following parameters to be used as optional sub-parameters within
  the Routing Key:

     Extension Sub-Parameters
     ------------------------------------------
     Routing Conext              Optional   *1

  Note 1: The Routing Context parameter is optional in the Routing Key.
          This parameter identifies an existing Application Server for
          which the Routing Key is to be altered.  The format of the
          Routing Context consists of a single Routing Context value.

3.1.2.3.  ISUA Routing Key

  The ISUA [ISUA] Routing Key parameter is formatted as follows:

B. Bidulock                    Version 0.1                       Page 11

Internet Draft                  UA REGEXT                January 2, 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 = 0x0522          |            Length             |
   +-------------------------------+-------------------------------+
   |                  Local Routing Key Identifier                 |
   +---------------------------------------------------------------+
   \                                                               \
   /                        Key parameter(s)                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the ISUA Routing Key [ISUA] by adding the following
  optional Key parameters to the Routing Key.

     Extension Sub-Parameters
     ------------------------------------------
     Routing Context             Optional   *1

  Note 1: The Routing Context parameter is included in the Routing Key
          when the ASP wishes to alter an existing Routing Key which
          corresponds to the indicated Routing Context.  The Routing
          Context parameter MUST only occur once in the Key parameters.

3.1.2.4.  SUA Routing Key

  The SUA [SUA] Routing Key parameter is formatted as follows:

    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 = 0x010E          |            Length             |
   +-------------------------------+-------------------------------+
   |                  Local Routing Key Identifier                 |
   +---------------------------------------------------------------+
   \                                                               \
   /                         Key parameter(s)                      /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the SUA Routing Key [SUA] by adding the following
  optional Key parameters to the Routing Key.

     Extension Sub-Parameters
     ------------------------------------------
     Routing Context             Optional   *1
     Reference Number Range      Optional   *2

B. Bidulock                    Version 0.1                       Page 12

Internet Draft                  UA REGEXT                January 2, 2003

  Note 1: The Routing Context parameter is included in the Routing Key
          when the ASP wishes to alter an existing Routing Key which
          corresponds to the indicated Routing Context.  The Routing
          Context parameter MUST only occur once in the Key parameters.

  Note 2: The Reference Number Range parameter is included in the
          Routing Key when the ASP wishes to accept or restrict
          connection oriented traffic within a Destination Local
          Reference (DLR) range for the Application Server being
          registered.  The Reference Number Range parameter SHOULD only
          occur once in the Key parameters.

3.1.2.5.  TUA Routing Key

  The TUA [TUA] Routing Key parameter is formatted as follows:

    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 = 0x041E          |            Length             |
   +-------------------------------+-------------------------------+
   |                  Local Routing Key Identifier                 |
   +---------------------------------------------------------------+
   \                                                               \
   /                        Key parameter(s)                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the TUA Routing Key [TUA] by adding the following
  optional Key parameters to the Routing Key.

     Extension Sub-Parameters
     ------------------------------------------
     Routing Context             Optional   *1

  Note 1: The Routing Context parameter is included in the Routing Key
          when the ASP wishes to alter an existing Routing Key which
          corresponds to the indicated Routing Context.  The Routing
          Context parameter MUST only occur once in the Key parameters.

3.1.3.  Load Selection

3.1.3.1.  M2UA Load Selection

  The M2UA [M2UA] Load Selection parameter [LOADSEL] is formatted as
  follows:

B. Bidulock                    Version 0.1                       Page 13

Internet Draft                  UA REGEXT                January 2, 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 = 0x0019          |            Length             |
   +-------------------------------+-------------------------------+
   \                                                               \
   /                      Load Key parameter(s)                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the M2UA Load Selection [LOADSEL] parameter by
  adding the following optional Load Key paramters to the Load
  Selection.

     Extension Sub-Parameters
     ------------------------------------------
     Load Selector               Optional   *1

  Note 1: The Load Selector parameter is included in the Load Selection
          when the ASP wishes to alter an existing Load Selection which
          corresponds to the indicated Load Selector.  The Load Selector
          parameter MUST only occur once in the Load Selection
          parameter.

3.1.3.2.  M3UA Load Selection

  The M3UA [M3UA] Load Selection parameter [LOADSEL] is formatted as
  follows:

    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 = 0x0019          |            Length             |
   +-------------------------------+-------------------------------+
   \                                                               \
   /                      Load Key parameter(s)                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the M3UA Load Selection [LOADSEL] parameter by
  adding the following optional Load Key paramters to the Load
  Selection.

     Extension Sub-Parameters
     ------------------------------------------
     Load Selector               Optional   *1

  Note 1: The Load Selector parameter is included in the Load Selection
          when the ASP wishes to alter an existing Load Selection which

B. Bidulock                    Version 0.1                       Page 14

Internet Draft                  UA REGEXT                January 2, 2003

          corresponds to the indicated Load Selector.  The Load Selector
          parameter MUST only occur once in the Load Selection
          parameter.

3.1.3.3.  ISUA Load Selection

  The ISUA [ISUA] Load Selection parameter [LOADSEL] is formatted as
  follows:

    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 = 0x0019          |            Length             |
   +-------------------------------+-------------------------------+
   \                                                               \
   /                      Load Key parameter(s)                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the ISUA Load Selection [LOADSEL] parameter by
  adding the following optional Load Key paramters to the Load
  Selection.

     Extension Sub-Parameters
     ------------------------------------------
     Load Selector               Optional   *1

  Note 1: The Load Selector parameter is included in the Load Selection
          when the ASP wishes to alter an existing Load Selection which
          corresponds to the indicated Load Selector.  The Load Selector
          parameter MUST only occur once in the Load Selection
          parameter.

3.1.3.4.  SUA Load Selection

  The SUA [SUA] Load Selection parameter [LOADSEL] is formatted as
  follows:

    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 = 0x0019          |            Length             |
   +-------------------------------+-------------------------------+
   \                                                               \
   /                      Load Key parameter(s)                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the SUA Load Selection [LOADSEL] parameter by adding
  the following optional Load Key paramters to the Load Selection.

B. Bidulock                    Version 0.1                       Page 15

Internet Draft                  UA REGEXT                January 2, 2003

     Extension Sub-Parameters
     ------------------------------------------
     Load Selector               Optional   *1

  Note 1: The Load Selector parameter is included in the Load Selection
          when the ASP wishes to alter an existing Load Selection which
          corresponds to the indicated Load Selector.  The Load Selector
          parameter MUST only occur once in the Load Selection
          parameter.

3.1.3.5.  TUA Load Selection

  The TUA [TUA] Load Selection parameter [LOADSEL] is formatted as
  follows:

    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 = 0x0019          |            Length             |
   +-------------------------------+-------------------------------+
   \                                                               \
   /                      Load Key parameter(s)                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the TUA Load Selection [LOADSEL] parameter by adding
  the following optional Load Key paramters to the Load Selection.

     Extension Sub-Parameters
     ------------------------------------------
     Load Selector               Optional   *1

  Note 1: The Load Selector parameter is included in the Load Selection
          when the ASP wishes to alter an existing Load Selection which
          corresponds to the indicated Load Selector.  The Load Selector
          parameter MUST only occur once in the Load Selection
          parameter.

3.1.4.  Error Codes

3.1.4.1.  SUA Error Codes

     REGEXT extends the Common mandatory Error Code parameter by
  removing the following Error Code values:

     Value   Description
     -----------------------------------
     0x17    Routing Key Change Refused

B. Bidulock                    Version 0.1                       Page 16

Internet Draft                  UA REGEXT                January 2, 2003

     In addition, REGEXT removes the following text associated with the
  "Routing Key Change Refused" error code:

      The "Routing Key Change Refused" error is sent when the SG
      refuses a change in the Routing Key parameters.  [SUA]

3.1.5.  Registration Status

     REGEXT extends the Registration Status parameter by adding the
  following values to the Common and UA-specific mandatory Registration
  Status parameter[4] in the REG RSP message:

     Value   Description
     ----------------------------------------------
      11     Error - Routing Key Change Refused
      17     Error - Load Selection Change Refused

3.1.5.1.  Common Registration Status

  The Common [ISUA..TUA] Registration Status parameter is formatted as
  follows:

     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 = 0x0016          |            Length             |
    + - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
    |                       Registration Status                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the Common Registration Status parameter for ISUA
  [ISUA], SUA [SUA] and TUA [TUA] by adding the following values to the
  status field:

     Value   Description
     ----------------------------------------------
      11     Error - Routing Key Change Refused
      17     Error - Load Selection Change Refused

     The "Error - Routing Key Change Refused" status is returned when
  the ASP has included an Routing Context in the Routing Key and the SGP
  is either unequipped to perform dynamic modification of the Routing
  Key, or dynamic modification of the Routing Key is not currently
  permitted.

     The "Error - Load Selection Change Refused" status is returned when
  the ASP has included a Load Selector in the Load Selection and the SGP
  is either unequipped to perform dynamic modification of the Load
  Selection, or dynamic modification of the Load Seletion is not

B. Bidulock                    Version 0.1                       Page 17

Internet Draft                  UA REGEXT                January 2, 2003

  currently permitted.

3.1.5.2.  M2UA Registration Status

  The M2UA [M2UA] Registration Status parameter is formatted as follows:
  [5]

     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 = 0x030E          |            Length             |
    + - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
    |                       Registration Status                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the M2UA [M2UA] Registration Status parameter by
  adding the following values to the status field: [6]

     Value   Description
     ----------------------------------------------
      11     Error - Link Key Change Refused
      17     Error - Load Selection Change Refused

     The "Error - Link Key Change Refused" status is returned by and SGP
  when the ASP has included an Interface Identifier in the Link Key and
  the SGP is either unequipped to perfor dynamic modification of the
  Link Key, or dynamic modification of the Link Key is not currently
  permitted.

     The "Error - Load Selection Change Refused" status is returned when
  the ASP has included a Load Selector in the Load Selection and the SGP
  is either unequipped to perform dynamic modification of the Load
  Selection, or dynamic modification of the Load Seletion is not
  currently permitted.

3.1.5.3.  M3UA Registration Status

  The M3UA [M3UA] Registration Status parameter is formatted as follows:
  [7]

     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 = 0x0212          |            Length             |
    + - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - +
    |                       Registration Status                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     REGEXT extends the M3UA [M3UA] Registration Status parameter by
  adding the following values to the status field:

B. Bidulock                    Version 0.1                       Page 18

Internet Draft                  UA REGEXT                January 2, 2003

     Value   Description
     ----------------------------------------------
      11     Error - Routing Key Change Refused
      17     Error - Load Selection Change Refused

     The "Error - Routing Key Change Refused" status is returned when
  the ASP has included an Routing Context in the Routing Key and the SGP
  is either unequipped to perform dynamic modification of the Routing
  Key, or dynamic modification of the Routing Key is not currently
  permitted.

     The "Error - Load Selection Change Refused" status is returned when
  the ASP has included a Load Selector in the Load Selection and the SGP
  is either unequipped to perform dynamic modification of the Load
  Selection, or dynamic modification of the Load Seletion is not
  currently permitted.

3.2.  Messages

     REGEXT extends the REG REQ and REG RSP messages.

3.2.1.  Registration Request (REG REQ)

     REGEXT extends the Registration Request (REG REQ) message by
  extending the Routing Key (Link Key) parameter and permitting the
  Routing Context (Interface Identifier) to be included in the REG REQ
  message.

     REGEXT also extens the REG REQ message by extending the Load
  Selection parameter [LOADSEL] and permitting the Load Selector to be
  included in the REG REQ message.

3.2.2.  Registration Response (REG RSP)

     REGEXT extends the Registration Response (REG RSP) message by
  adding the following values to the mandatory Registration Status
  parameter in the mandatory Registration Result parameter in the REG
  RSP message: [8]

     Value   Description
     --------------------------------------------------
      11     Error - Routing (Link) Key Change Refused
      17     Error - Load Selection Change Refused

  The new Registration Status values are interpreted as follows:

  "Error - Routing (Link) Key Change Refused"   This Registration Status
     is returned in a REG RSP message by the SGP when it is either
     unequipped to perform Routing (Link) Key modifications described in
     this memo, or is otherwise unable to modify the the Routing (Link)
     Key as requested by the ASP.

B. Bidulock                    Version 0.1                       Page 19

Internet Draft                  UA REGEXT                January 2, 2003

  "Error - Load Selection Change Refused"   This Registration Status is
     returned in a REG RSP message by the SGP when it is either
     unequipped to perform Load Selection modifications described in
     this memo, or is otherwise unable to modify the the Load Selection
     as requested by the ASP.

4.  Procedures

4.1.  Registration

     In extension to the registration procedures of M2UA [M2UA], REGEXT
  provides the following registration procedures:

4.1.1.  Common Registration Procedures

     In extension to the registration procedures of Common [M3UA..TUA],
  REGEXT provides the following registration procedures:

     An ASP MAY modify an existing Routing Key by including the Routing
  Context in the REG REQ.  If the SGP determines that the Routing
  Context applies to an existing Routing Key, the SG MAY adjust the
  existing Routing Key to match the new information provided in the
  Routing Key parameter.  A REG RSP with Registration Status "Error -
  Routing Key Change Refused" is returned if the SGP does not accept the
  modification of the Routing Key. [9]

     An ASP MAY modify an existing Load Selection by including the Load
  Selector in the REG REQ.  If the SGP supports load selection
  extensions [LOADSEL] and determines that the Load Selector applies to
  an existing Load Selection, the SGP MAY adjust the existing Load
  Selection to match the new information provided in the Load Selection
  parameter.  A REG RSP  with Registration Status "Error - Load
  Selection Change Refused" is returned if the SGP does not accept the
  modification of the Load Selection.

4.1.2.  M2UA Registration Procedures

     In extension to the registration procedures of M2UA [M2UA], REGEXT
  provides the following registration procedures:

     An ASP MAY modify an existing Link Key by including the Interface
  Identifier in the REG REQ.  If the SGP determines that the Interface
  Identifier applies to an existing Link Key, the SG MAY adjust the
  existing Link Key to match the new information provided in the Link
  Key parameter.  A REG RSP with Registration Status "Error - Link Key
  Change Refused" is returned if the SGP does not accept the
  modification of the Link Key.

     An ASP MAY modify an existing Load Selection by including the Load
  Selector in the REG REQ.  If the SGP supports load selection
  extensions [LOADSEL] and determines that the Load Selector applies to
  an existing Load Selection, the SGP MAY adjust the existing Load
  Selection to match the new information provided in the Load Selection
  parameter.  A REG RSP  with Registration Status "Error - Load

B. Bidulock                    Version 0.1                       Page 20

Internet Draft                  UA REGEXT                January 2, 2003

  Selection Change Refused" is returned if the SGP does not accept the
  modification of the Load Selection.

5.  Interworking

     REGEXT also provides procedures for an SGP or ASP not supporting
  REGEXT to interwork with an ASP or SGP supporting REGEXT.

5.1.  Registration Interworking

     An ASP that determines than an SG is unequipped to perform REGEXT
  SHOULD NOT send any subsequent REG REQ messages containing a Routing
  Context (or Interface Identifier) to that SG.

     An SG or ASP supporting ASPEXT [ASPEXT] will identify its ability
  or inability to support REGEXT using the ASP Extensions procedure
  [ASPEXT].

     If an SG does not support dynamic registration, it also does not
  support REGEXT.

     If an SG not supporting REGEXT receives a Routing Context
  (Interface Identifier in the REG REQ message, it could respond with an
  existing non-zero Registration Status or an ERR message.  If the ASP
  receives a REG RSP message containing a non-zero Registration Status,
  or receives an ERR message with an appropriate Error Code correlating
  to the REG REQ message and an indication that the Routing Context
  (Interface Identifier) parameter was considered invalid, from an SG
  not supporting ASP Extensions [ASPEXT], then the ASP SHOULD mark the
  SG as unequipped to perform REGEXT and not place any Routing Context
  (Interface Identifier) in any further messages to that SG, or attempt
  any of the extension procedures defined in this memo.

5.1.1.  Registration Status REGEXT Unsupported

     Examples of possible Registration Status errors returned in a REG
  RSP message when the peer does not support REGEXT are as follows:

     Value   Description
     ------------------------------------------------------
         4   Error - Invalid Routing Key
     ------------------------------------------------------
         6   Error - Cannot Support Unique Routing
             Error - Overlapping (Non-unique) Link Key
     ------------------------------------------------------
         7   Error - Routing Key not Currently Provisioned
             Error - Link Key not Provisioned
     ------------------------------------------------------
         9   Error - Unsupported RK parameter field
     ------------------------------------------------------
        11   Error - Routing Key Change Refused

B. Bidulock                    Version 0.1                       Page 21

Internet Draft                  UA REGEXT                January 2, 2003

             Error - Link Key Change Refused
     ------------------------------------------------------

5.1.2.  Error Codes REGEXT Unsupported

     Examples of possible Error Codes returned in a ERR message when the
  peer does not support REGEXT are as follows:

     Value   Description
     -----------------------------------------------
      0x02   Invalid Interface Identifier
      0x03   Unsupported Message Class
      0x04   Unsupported Message Type
      0x10   ASP Active for Interface Identifier(s)
      0x11   Invalid Paramater Value
      0x12   Parameter Field Error
      0x13   Unexpected Parameter
      0x19   Invalid Routing Context
     -----------------------------------------------

6.  Examples

7.  Security

     REGEXT provides adds some secuirty risks to M2UA [M2UA], M3UA
  [M3UA], ISUA [ISUA], SUA [SUA] and TUA [TUA].

     If the Signalling Gateway (SG) does cannot properly authenticate
  the peer, the peer might gain priviledges to alter a Routing (Link)
  Key to which the peer should not have permission, or alter a Load
  Selection to which the peer should not have permission.

     However, if the peer can imitate an ASP and gain access with the
  priviledges of an ASP, use of the Routing Context (Interface
  Identifier) parameter in the ASPTM message can always be used to
  perform denial of service on traffic destined for legitimate
  Application Servers.  As the REGEXT extensions require the use of the
  Routing Context (Interface Identifier) parameter in the REG REQ
  message, the same levels of protection afforded the Routing Context
  (Interface Identifier) parameter in the REG REQ message as is
  experienced in the ASPAC (ACK) message.

8.  IANA Considerations

     REGEXT adds the following parameter tag value (described in Section
  3) to the SUA-Specific Parameter numbering range for SUA [SUA]:

     Tag Value   Parameter Name
     -----------------------------------

B. Bidulock                    Version 0.1                       Page 22

Internet Draft                  UA REGEXT                January 2, 2003

      0x0119     Reference Number Range

      IANA NOTE:-  The Reference Number Range tag values shown
      through this document as 0x0119 will be assigned by IANA
      within the SUA-specfic parameter range of the SUA [SUA] and
      may change its value in further versions of this document.

Notes

  [1]  EDITOR'S NOTE:- Text was included in the M3UA specification
       [M3UA] to permit this operation, however, detailed procedures and
       the addition of the Routing Context parameter to the Routing Key,
       and addition of the corresponding error code was missed.

  [2]  EDITOR'S NOTE:- Text was include in the SUA specification [SUA]
       to permit this operation, however, detailed procedures and the
       addition of the Routing Context parameter to the Routing Key was
       missed.

       In addition, this mechanism can provide superior support for
       multiple SGs acting as STPs, and can replace the DRN Label and
       associated mechanism.  The TID Label and associated mechanism is
       inadequate and should be removed from the SUA specification
       [SUA].

  [3]  IANA NOTE:-  The parameter tag values shown as 0x0119 will be
       assigned by IANA within the specific parameter range of SUA [SUA]
       and may change its value in further versions of this document.

  [4]  IANA Note:-  Note that the Registration Status parameter has tag
       value 0x030e for M2UA [M2UA], tag value 0x0212 for M3UA [M3UA]
       and (perhaps not suprisingly) tag value 0x0016 for ISUA [ISUA],
       SUA [SUA] and TUA [TUA].

  [5]  IANA NOTE:-  The Registration Status value shown as 11 and 17
       will be assigned by IANA as a value of the Common Registration
       Status parameter for the SIGTRAN UAs and may change its value in
       further versions of this document.

  [5]  EDITOR'S NOTE:-  The M2UA [M2UA] Registration Result,
       Registration Status, Deregistration Result and Deregistration
       Status parameter should be altered from the M2UA-specific tag
       values to the Common tag values to be consistent with the other
       UAs.

B. Bidulock                    Version 0.1                       Page 23

Internet Draft                  UA REGEXT                January 2, 2003

  [6]  IANA NOTE:-  The Registration Status value shown as 11 and 17
       will be assigned by IANA as a value of the M2UA-specific
       Registration Status parameter for M2UA [M2UA] and may change its
       value in further versions of this document.

  [7]  EDITOR'S NOTE:-  The M3UA [M3UA] Registration Result,
       Registration Status, Deregistration Result and Deregistration
       Status parameter should be altered from the M3UA-specific tag
       values to the Common tag values to be consistent with the other
       UAs.

  [8]  IANA NOTE:-  The Registration Status value shown as 11 and 17
       will be assigned by IANA as a value of the M3UA-specific
       Registration Status parameter for M3UA [M3UA] and may change its
       value in further versions of this document.

  [8]  IANA NOTE:-  The Registration Status values shown as 11 and 17
       will be assigned by IANA as a value of the Common Registration
       Status parameter for SIGTRAN UAs and may change its value in
       further versions of this document.

  [9]  EDITOR'S NOTE:- ISUA [ISUA], SUA [SUA] and TUA [TUA] already
       contains the procedures described in this paragraph.  The only
       difference provided by REGEXT is that the Registration Status
       "Error - Routing Key Change Refused" is actually defined.

References

  M2UA.
       K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock and J. Heitz,
       "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User
       Adaptation Layer," RFC 3331, Internet Engineering Task Force -
       Signalling Transport Working Group (September, 2002).
       [Normative]

  M3UA.
       G. Sidebottom, K. Morneault and J. Pastor-Balbas, (eds),
       "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User
       Adaptation Layer (M3UA)," RFC 3332, Internet Engineering Task
       Force - Signalling Transport Working Group (September, 2002).
       [Normative]

  ISUA.
       B. Bidulock, "SS7 ISUP-User Adaptation Layer (ISUA)," <draft-
       bidulock-sigtran-isua-00.txt>, Internet Engineering Task Force -
       Signalling Transport Working Group (January 5, 2003).  Work In
       Progress. [Informative]

  SUA.
       J. Loughney, G. Sidebottom, L. Coene, G. Verwimp, J. Keller and

B. Bidulock                    Version 0.1                       Page 24

Internet Draft                  UA REGEXT                January 2, 2003

       B. Bidulock, "SS7 SCCP-User Adaptation Layer (SUA)," <draft-ietf-
       sigtran-sua-14.txt>, Internet Engineering Task Force - Signalling
       Transport Working Group (June 30, 2002).  Work In Progress.
       [Normative]

  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. [Informative]

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

  Q.704.
       ITU, "Message Transfer Part - Signalling Network Functions and
       Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication
       Standardization Sector of ITU, Geneva (March 1993).
       [Informative]

  NPI.
       UNIX. International, "Network Provider Interface Specification,"
       NPI Revision 2.0.0, UNIX International Publication, Parsippany,
       New Jersey (August 17, 1992).  [Informative]

  TPI.
       Open Group, "Transport Provider Interface Specification," TPI
       Version 2, Draft 2, Open Group Publication (1999).  [Informative]

  XNS.
       Open Group, "Technical Standard: Network Services (XNS)," XNS
       Issue 5.2 Draft 2.0 (ISBN: 1-85912-241-8), Open Group Publication
       (1999).  [Informative]

  RFC 2119.
       S. Bradner, "Key words for use in RFCs to Indicate Requirement
       Levels," RFC 2119 - BCP 14 (ISBN: 1-85912-241-8), Internet
       Engineering Task Force (March 1997).  [Normative]

  LOADSEL.
       B. Bidulock, "Load Selection Extension for Signalling User
       Adaptation Layers (LOADSEL)," <draft-bidulock-sigtran-
       loadsel-01.txt> (ISBN: 1-85912-241-8), Internet Engineering Task
       Force - Signalling Transport Working Group (January 2, 2003).
       Work In Progress.

  ASPEXT.
       B. Bidulock, "Application Server Process (ASP) Extension
       Framework," <draft-bidulock-sigtran-aspext-01.txt> (ISBN:
       1-85912-241-8), Internet Engineering Task Force - Signalling
       Transport Working Group (January 2, 2003).  Work In Progress.

B. Bidulock                    Version 0.1                       Page 25

Internet Draft                  UA REGEXT                January 2, 2003

       [Informative]

Author's Addresses

  Brian Bidulock                                  Phone: +1-780-490-1141
  OpenSS7 Corporation                        Email: bidulock@openss7.org
  1469 Jeffreys Crescent                     URL: http//www.openss7.org/
  Edmonton, AB  T6L 6T1
  Canada

  This Internet draft expires July, 2003.

B. Bidulock                    Version 0.1                       Page 26

Internet Draft                  UA REGEXT                January 2, 2003

                       List of Illustrations

  Figure 1 Example (A) - M2UA Configuration .....................    4
  Figure 2 Example (B) - M3UA Configuration .....................    5
  Figure 3 Example (C) - ISUA Configuration .....................    6
  Figure 4 Example (D) - SUA Configuration ......................    7
  Figure 5 Example (E) - TUA Configuration ......................    8

                         Table of Contents

  Status of this Memo ...........................................    1
  Abstract ......................................................    1
  1 Introduction ................................................    2
  1.1 Scope .....................................................    2
  1.2 Change History ............................................    2
  1.3 Terminology ...............................................    2
  1.4 Overview ..................................................    2
  1.4.1 Limitations of Existing Registration Management .........    2
  1.4.2 Registration Extension ..................................    4
  1.5 Limitations ...............................................    8
  2 Conventions .................................................    9
  3 Protocol Elements ...........................................    9
  3.1 Parameters ................................................    9
  3.1.1 Routing Key Parameters ..................................    9
  3.1.2 Routing (Link) Key ......................................   10
  3.1.3 Load Selection ..........................................   13
  3.1.4 Error Codes .............................................   16
  3.1.5 Registration Status .....................................   17
  3.2 Messages ..................................................   19
  3.2.1 Registration Request (REG REQ) ..........................   19
  3.2.2 Registration Response (REG RSP) .........................   19
  4 Procedures ..................................................   20
  4.1 Registration ..............................................   20
  4.1.1 Common Registration Procedures ..........................   20
  4.1.2 M2UA Registration Procedures ............................   20
  5 Interworking ................................................   21
  5.1 Registration Interworking .................................   21
  5.1.1 Registration Status REGEXT Unsupported ..................   21
  5.1.2 Error Codes REGEXT Unsupported ..........................   22
  6 Examples ....................................................   22
  7 Security ....................................................   22
  8 IANA Considerations .........................................   22
  Notes .........................................................   23
  References ....................................................   24
  Author's Addresses ............................................   26
  List of Illustrations .........................................   27

B. Bidulock                    Version 0.1                       Page 27

Internet Draft                  UA REGEXT                January 2, 2003

Copyright Statement

  Copyright (C) The Internet Society (2003).  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.1                       Page 28


Last modified: Wed, 12 Nov 2014 07:42:58 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.