Internet DRAFT - draft-asveren-sigtran-m3uasgsg

draft-asveren-sigtran-m3uasgsg







Network Working Group                                         T. Asveren
Internet-Draft                                              Ulticom Inc.
Expires: June 3, 2006                                        B. Bidulock
                                                     OpenSS7 Corporation
                                                        J. Pastor-Balbas
                                                    Ericsson Espana S.A.
                                                       November 30, 2005


                        M3UA SG-SG Communication
                 draft-asveren-sigtran-m3uasgsg-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on June 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a protocol to support the communication
   between M3UA SGs in IP domain.  The functionality needed by SGs to
   act as relay points between SS7 nodes is also addressed.





Asveren, et al.           Expires June 3, 2006                  [Page 1]

Internet-Draft          M3UA SG-SG Communication           November 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Functional Areas . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Signaling Point Code Representation  . . . . . . . . . . .  4
     2.2.  Routing Keys and Routing Context . . . . . . . . . . . . .  4
     2.3.  Network Appearence . . . . . . . . . . . . . . . . . . . .  4
     2.4.  SCTP Associations  . . . . . . . . . . . . . . . . . . . .  5
     2.5.  Communication Initiation . . . . . . . . . . . . . . . . .  5
     2.6.  Message Distribution . . . . . . . . . . . . . . . . . . .  5
     2.7.  Congestion Handling  . . . . . . . . . . . . . . . . . . .  6
     2.8.  Restricted Destinations  . . . . . . . . . . . . . . . . .  6
   3.  Message Types and Parameters . . . . . . . . . . . . . . . . .  6
   4.  Protocol Messages  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Destiantion User Part Available(DUPU)  . . . . . . . . . .  7
     4.2.  Signaling Congestion (SCON)  . . . . . . . . . . . . . . .  7
     4.3.  Congestion Test Message (CGT)  . . . . . . . . . . . . . .  8
     4.4.  Changeover Mechanism Related Messages  . . . . . . . . . . 10
       4.4.1.  Changeover Request Message (COR) . . . . . . . . . . . 10
       4.4.2.  Changeover Request Acknowledgement Message (CORA)  . . 11
   5.  SG and SGP State Machines  . . . . . . . . . . . . . . . . . . 12
     5.1.  SGP State Machine  . . . . . . . . . . . . . . . . . . . . 12
     5.2.  SG State Machine . . . . . . . . . . . . . . . . . . . . . 13
   6.  Management Procedures  . . . . . . . . . . . . . . . . . . . . 14
     6.1.  ASPUP Procedures . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  ASP Down Procedures  . . . . . . . . . . . . . . . . . . . 15
     6.3.  ASP Active Procedures  . . . . . . . . . . . . . . . . . . 15
   7.  Examples of SG-SG Communication Procedures . . . . . . . . . . 15
     7.1.  M3UA Availability Declaration  . . . . . . . . . . . . . . 15
     7.2.  PC Status Announcement . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20












Asveren, et al.           Expires June 3, 2006                  [Page 2]

Internet-Draft          M3UA SG-SG Communication           November 2005


1.  Introduction

   This document describes a protocol to support the communication
   between M3UA[1] SGs in IP domain.

1.1.  Terminology

   This document uses the terminology in RFC3332 [1] with the following
   additions:

   COA Changeover Acknowledgement MTP3 message
   COO Changeover Order MTP3 message
   ECA Emergency Changeover Acknowledgement MTP3 message
   ECM Emergency Changeover MTP3 message
   Relaying Relaying is used throughout this document with the meaning
   of providing transfering functionality for messages, which are not
   destined for the own PC, like a STP does in SS7 network.
   TFC Transfer Controlled MTP3 message

1.2.  Scope

   This document defines a communication mechanism between M3UA SGs.
   The main motivation for such a mechanism is allowing message relaying
   on SGs.  This relaying could happen between two nodes in TDM based
   domain, between two nodes in IP based domain or between a node in TDM
   based domain and a node in IP based domain.
   M3UA SG-SG communication could be utilized for different reasons:
   o To offload SS7 traffic over IP network
   o To replace TDM based C-links between two SGs
   o To build a hierarchical network topology for easier provisioning
   o To provode security gateway functionality between different
   administrative domains


       (   )                              (   )
     (  SS7  )    +-----+    +-----+    ( SS7   )
    ( segment )---+ SG1 +----+ SG2 +---( segment )
     (   1   )    +-----+    +-----+    (   2   )
       (   )                              (   )

        Figure 1.   Connecting two SS7 segments with SG-SG communication

1.3.  Architecture

   The goal of SG-SG communication is to define a peer-to-peer
   relationship between two M3UA IP doamin entities, which can be used
   both for direct communication and for message relaying.  For that
   reason SG-SG communication model mimics the relationship between two



Asveren, et al.           Expires June 3, 2006                  [Page 3]

Internet-Draft          M3UA SG-SG Communication           November 2005


   MTP3[3] signaling points.  This allows inheritance of necessary MTP3
   procedures without any modeling problems.

   In the context of SG-SG communication, a SG MAY be controlling one or
   more SPMCs.  It should be noted that user parts for a specific SPMC
   MAY reside on the same node with SG itself, or MAY be distributed
   across remote nodes, where relationship between those nodes and the
   controling SG MAY be based on the ASP/SGP realtionship as defined by
   M3UA or MAY be implementation dependent.

   SG-SG communication management is based mainly on SSNM as defined in
   M3UA.  Communication of peers is in PC granularity.

   Each SG MAY consist of multiple SGPs.  It should be noted that all
   MTP3 related logic for own PC, for SPMCs directly connected and for
   remote PCs function as a signle entity in the whole SG.

                   SG
    ************************************
    * +------------------------------+ *
    * |        MTP3 Logic            | *
    * +----+---+----+---+----+--+----+ *
    * |SGP1|   |SGP2|   |SGP3|  |SGP4| *
    * +----+   +----+   +----+  +----+ *
    ************************************
        |        |        |      |

        Figure 2. SG consisting of multiple SGPs


2.  Functional Areas

2.1.  Signaling Point Code Representation

   If a SG controls a SPMC, it SHOULD control it as a whole.  When a
   SPMC becomes available, SG will broadcast DAVA to all adjacent SGs.
   Similarly when a SPMC becomes unavailable DUNA and when SPMC becomes
   restricted DRST SHOULD be sent.

2.2.  Routing Keys and Routing Context

   There is no Routing Context/Routing Key concept present in SG-SG
   communication.

2.3.  Network Appearence

   Network Appearence is used in the messages as described in M3UA.




Asveren, et al.           Expires June 3, 2006                  [Page 4]

Internet-Draft          M3UA SG-SG Communication           November 2005


2.4.  SCTP Associations

   SCTP[2] with multihoming feature MUST be used as transport protocol
   for SG-SG communication.

   There is no client/server relationship between SGPs.  SCTP
   associations MAY be initiated by any SG.  A collision, which might
   happen if both sides try to establish SCTP association concurrently
   is handled by SCTP protocol itself.

   Although SGPs are allowed to have more than one SCTP association
   between them, such a configuration is NOT RECOMMENDEDr, as SCTP
   multihoming provides an excellent way to achieve redundnacy in a
   trnsparent way to upper layers with no message loss/duplication/
   missequencing.  For that reason, equivalent of MTP3 changeover and
   changeback procedures are not defined for SG-SG communication.

2.5.  Communication Initiation

   After a SCTP association is established, peers MUST declare the
   availability of their M3UA layer with ASPUP message.  A received
   ASPUP is replied with ASPUP-ACK.  If one peer receives ASPUP message
   before sending ASPUP, it MAY send ASPUP message.  A received ASPUP or
   ASPUP-ACK message declares availability of the peer.  A SGP can
   declare its unavailability with ASPDN message.  ASPDN is acknowledged
   with ASPDN-ACK message.

   After the availability of M3UA layers is confirmed, SGs will exchange
   SSNM to update to update the remore peer about the status of PCs,
   which are configured as reachable on them.  Unless a corresponding
   message is received, all configured PCs are assumed as accessible via
   the remote peer.  Each SG will send DUAN for unavailable PCs and DRST
   for restricted PCs.  The end of this of this unavailable/restricted
   PC announcement is marked with an ASPAC message.  A received ASPAC is
   replied wit an ASPAC-ACK message.  SSNM and ASPAC/ASPAC-ACK are sent
   per SG.  A SG SHOULD NOT start sending DATA messages to a peer,
   unless ASPAC and ASPAC-ACK are received.

   SSNM, which are sent for point code status information exchange
   procedure and ASPAC/ASPAC-ACK SHOULD be sent via stream 0, to prevent
   problems which may arise due to missequencing.

2.6.  Message Distribution

   DATA messages SHOULD be sent to SGs, via which the destination
   pointcode of the message to be sent is in available status.  If there
   is no such peer SG, DATA messages SHOULD be sent to SGs, which
   declared the destination as restricted.  If no such SG exists, the



Asveren, et al.           Expires June 3, 2006                  [Page 5]

Internet-Draft          M3UA SG-SG Communication           November 2005


   message SHOULD be dropped.

   Message distribution among remote SGs is implementation dependent.

   Message distribution among SGPs belonging to the same SG is
   determined by the sender of the message.  A SG SHOULD be preprared to
   receive messages by any of its SGPs in UP state.

   Messages, for which sequencing has to be preserved SHOULD be sent via
   the same SCTP association using the same stream.

   In case, the destination to which a certain group of messages changes
   ,e.g due to a new SGP becoming UP, procedures similiar to time-
   controlled diversion and time-controlled changeover as decribed by
   MTP3 SHOULD be followed to reduce the possibility of message
   missequencing.

2.7.  Congestion Handling

   Congestion handling procedures as defined in relevant MTP3 standards
   SHOULD be followed.  It is responsibility of a SG to follow those
   procedures on behalf of the SPMCs it controls.  While following those
   procedures, SCON instead of TFC and CGT instead of RCT MUST be used,
   when the message needs to be sent to or via an adjacent SG.

2.8.  Restricted Destinations

   When destinations in IP domain should be declared as restricted is
   implementation dependent.


3.  Message Types and Parameters

   The following new message types are defined as new SSNM in addition
   to existing ones in M3UA:

   128 Congestion Test Message (CGT)
   129 Changeover Request Message (COR)
   130 Changeover Request Acknowledgement Message (CORA)

   The following parameters are added in addition to the ones defined in
   M3UA:

   Forward Sequence Number 0x0214 Signaling Link Code 0x0215


4.  Protocol Messages




Asveren, et al.           Expires June 3, 2006                  [Page 6]

Internet-Draft          M3UA SG-SG Communication           November 2005


   DATA, SSNM messages, ERROR, ASPUP/ASPUP-ACK, ASPAC/ASPAC-ACK messages
   are used for SG-SG communication.  RC field in the messages is not
   used, i.e. it MUST not be filled.

4.1.  Destiantion User Part Available(DUPU)

   A new field is introduced to DUPU.
   Concerned PC: Destination PC, which has caused DUPU to be generated.
   This parameter is mandatory.

   The format for DUPU message parameters is 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 = 0x0200          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Network Appearance                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0012          |          Length = 8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Mask = 0    |                  Affected PC                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0206          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    reserved   |                 Concerned DPC                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0204          |          Length = 8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Cause             |            User               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.2.  Signaling Congestion (SCON)

   For SG-SG communication, Concerned DPC parameter is mandatory.  It
   contains the point code for the signaling point, which originated the
   message causing SCON to be generated.

   There will be two Affected PC fields present.  The first one contains
   the point code of the originator of the SCON -or the corresponding



Asveren, et al.           Expires June 3, 2006                  [Page 7]

Internet-Draft          M3UA SG-SG Communication           November 2005


   TFC- message and the second one contains the point code for the
   congested destination.  Those two Affected PC fields MUST be sent in
   this order.

   The format for SCON message parameters is 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 = 0x0200          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Network Appearance                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0012          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   reserved    |                 Affected PC1                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   reserved    |                 Affected PC2                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0206          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    reserved   |                 Concerned DPC                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0205          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Reserved                    |  Cong. Level  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                         INFO String                           /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.3.  Congestion Test Message (CGT)

   CGT is used to support Signaling Route Set Congestion Test(National
   Option) procedures as defined by MTP3.  It is used instead of RCT
   MTP3 message.

   The CGT message contains the following parameters:

   Affected PC Mandatory
   Concerned DPC Mandatory
   Congestion Level Mandatory
   Info String Optional



Asveren, et al.           Expires June 3, 2006                  [Page 8]

Internet-Draft          M3UA SG-SG Communication           November 2005


   The format for the CGT message parameters is 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 = 0x0200          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Network Appearance                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0012          |             Length = 8        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Mask     |                 Affected PC                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0206          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    reserved   |                 Concerned DPC                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0205          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Reserved                    |  Cong. Level  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                         INFO String                           /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Network Appearence: 32 bits (semi-mandatory)
   See M3UA Section 3.1.1

   Affected Point Code: 32 bits (mandatory)
   Affected Point Code parameter contains the 14-, 16-, 24-bit binary
   formatted point code value, for which CGT message is generated.

   Congestion Levels: 8 bits (unsigned integer) (mandatory)
   The Congestion Level parameter contains one of the following values:
   0 No Congestion or Undefined
   1 Congestion Level 1
   2 Congestion Level 2
   3 Congestion Level 3

   When sending CGT message, procedures defined for Signaling Route Set
   Congestion Test in Q.704 Clause 13.9 SHOULD be followed.






Asveren, et al.           Expires June 3, 2006                  [Page 9]

Internet-Draft          M3UA SG-SG Communication           November 2005


4.4.  Changeover Mechanism Related Messages

   SG-SG communication does not rely on a mechanism similar to M3UA
   changeover mechanism for redundancy purposes , but a SG may relay
   MTP3 changeover mechanism related messages.

          +-------+                +-------+
          | SS7   |                |  SG2  |
          | node1 +--------X-------+       |
    COO(1)+---+---+ ^              +----+--+   CORA(3)
     |   ^    |     |                   |   ^   |
     |   |    |     |                   |   |   |
     |   |    |     |                   |   |   |
     |   |    |     |                   |   |   |
     |   |    |     |                   |   |   |
     |   |    |     |                   |   |   |
     V   |    |     | +-------+         |   |   V
        COA(4)|     | |  SG1  |         |  COR(2)
              +-----+-+       +---------+
                 ^  | +-------+     ^
                 |  |               |
                 |  |               |
                 |  |               |
                 |  |               |
                  TDM              IP

         Figure 3. SG1 relaying changeover messages to and from SG2

4.4.1.  Changeover Request Message (COR)

   COR is used to relay changeover order/emergency changeover order
   information to/from a peer in TDM domain.  There are two cases, where
   it can be used: either it is received from a SG peer, where a
   corresponding COO/ECM is sent to a conventional SS7 peer or it can be
   sent to a SG, after COO/ECM has been received from a conventional SS7
   node.

   COR message contains the following parameters:

   Network Appearence: 32 bits (semi-mandatory)
   See M3UA Section 3.1.1

   SLC: 5 bits (mandatory)
   The signaling link code of the failed link.

   FSN: 24-bits (semi-mandatory)
   Forward sequence number of the last message signal unit accepted from
   the unavailable signalink link by the sender of the message.  If COR



Asveren, et al.           Expires June 3, 2006                 [Page 10]

Internet-Draft          M3UA SG-SG Communication           November 2005


   is received from a SG and if FSN is present, a corresponding COO MUST
   be generated.  If no FSN is present an ECM MUST be generated.  When
   COO is received from a conventional SS7 peer, FSN MUST be filled in
   COR.  When ECM is received from a conventioanal SS7 peer, FSN MUST
   NOT be filled.

   Affected Point Code: 32 bits (mandatory)
   Affected Point Code parameter contains the 14-, 16-, 24-bit binary
   formatted point code value, which has send COO/ECM message.

   Concerned Point Code: 32 bits (mandatory)
   Concerned Point Code parameter contains he 14-, 16-, 24-bit binary
   formatted point code value, to which COO/ECM message is sent.

   The format for COR message parameters is 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 = 0x0200          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Network Appearance                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0214          |           Length =8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Reserve      |               FSN                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0215          |           Length =8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Reserved                             |   SLC   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Tag = 0x0012          |   Length =8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Reserved     |                 Affected PC                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Tag = 0x0206          |   Length =8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Reserved     |                 Concerned PC                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.4.2.  Changeover Request Acknowledgement Message (CORA)

   CORA is used to relay the FSN inforamtion for the last accepted MSU
   on a failed link between a peer SG and a conventional SS7 node as an
   answer to COR.

   COR message contains the following parameters:



Asveren, et al.           Expires June 3, 2006                 [Page 11]

Internet-Draft          M3UA SG-SG Communication           November 2005


   Network Appearence: 32-bit (semi-mandatory)
   See M3UA Section 3.1.1

   SLC: 5 bits (mandatory)
   The signaling link code of the failed link.

   FSN: 24 bits (semi-mandatory)
   Forward sequence number of the last message signal unit accepted from
   the unavailable signalink link by the sender of CORA.  If CORA is
   received from a SG and if FSN is present, a corresponding COA MUST be
   generated.  If no FSN is present an ECA MUST be generated.  When COA
   is received from a conventional SS7 node, FSN MUST be filled in CORA.
   When ECA is received from a conventional SS7 node, FSN MUST NOT be
   filled.

   Affected Point Code: 32 bits (mandatory)
   Affected Point Code parameter contains the 14-, 16-, 24-bit binary
   formatted point code value, to which COA/ECA generated based on the
   received CORA, should be sent.

   Concerned Point Code: 32 bits (mandatory)
   Concerned Point Code parameter contains the 14-, 16-, 24-bit binary
   formatted point code value, to which COO/ECM message is sent.


5.  SG and SGP State Machines

5.1.  SGP State Machine

   The state of each remote SGP is maintened in the M3UA layer in the
   SGP.  The state of a particular SGP changes due to events.  The
   events include:
   * Reception of messages from the peer SGP M3UA layer.
   * Reception of indications from the SCTP layer.
   * Local management intervention.

   The SGP state transition diagram is shown below.  The possible states
   of a SGP are:

   SGP-DOWN: The remote M3UA peer at the SGP is unavailable and/or the
   related SCTP association is down.  Initially all SGPs will be in this
   state.  An SGP in this state SHOULD NOT be sent any messages, with
   the exception of HEARTBEAT ASPDN-ACK and ERROR messages.

   SGP-UP: The remote M3UA peer at the SGP is available and the related
   SCTP association is up.  M3UA messages, which can be sent in this
   state are restricted only by SG state.




Asveren, et al.           Expires June 3, 2006                 [Page 12]

Internet-Draft          M3UA SG-SG Communication           November 2005


              +--------+
              |SGP UP  |
              +-+----+-+
       ASPUP or ^    | ASPDOWN/ASPDOWN-ACK
      ASPUP-ACK |    | SCTP CDI/SCTP RI
                |    |
                |    v
              +-+----+-+
              |SGP DOWN|
              +--------+

        Figure 4. SGP State Machine


5.2.  SG State Machine

   The state machine of each remote SG is maintained in the SGP.  SGPs
   belonging to the same SG MUST have a uniqie view of a remote SG.  The
   state of a particular SG changes due to the events.  The events
   include:
   * Reception of messages from the peer SG/SGP.
   * State changes of local SGPs.
   * Local management intervention.

   The SG state transition diagram is shown below.  Possible states of a
   SG are:

   SG DOWN: There is no SGP belonging to this SG in SGP UP state.
   Messages , which are not allowed in SGP DOWN state SHOULD NOT be sent
   to the SG.

   SG UP: There is at least one SGP belonging to this SG in SGP UP
   state, but PC status announcement phase is not completed yet.  In
   this state, DATA messages SHOULD NOT be sent to the remote SG.

   SG ACTIVE: There is at least one SGP belonging to this SG in SGP UP
   state and SG has finished PC announcement phase.














Asveren, et al.           Expires June 3, 2006                 [Page 13]

Internet-Draft          M3UA SG-SG Communication           November 2005


               +--------+
               |  SG    |
               |ACTIVE  +---+
               +---+----+   |
                   ^        |
          ASPAC and|        |Last SGP in SGP UP state
            ASPAC-ACK |        |transitions to SGP DOWN state
     received from |        |
       peer SG +---+----+   |
               |  SG    |   |
               |  UP    |   |
               +-+-----++   |
         one SGP ^     |    |
      transitions|     |Last SGP in SGP UP state
      to SGP UP  |     |transitions to SGP DOWN state
       state     |     |    |
                 |     v    |
               +-+-----++   |
               |  SG    +<--+
               | DOWN   |
               +--------+

        Figure 5. SG State Machine



6.  Management Procedures

6.1.  ASPUP Procedures

   After a SGP successfully establishes a SCTP association with a peer
   SGP, it needs to declare availability of its M3UA layer to its peer.
   This is done either by sending ASPUP or by acknowledging a received
   ASPUP with ASPUP-ACK or with both of them.

   Because there is no client/server relationship between peers, each of
   them can send ASPUP.

   If for any local reason, e.g. management blocking, the SGP cannot
   respond with an ASPUP-ACK message, the SGP responds with an Error
   message with reason "Refused - Management Blocking".  Otherwise, a
   received ASPUP message SHOULD be acknowledged with ASPUP-ACK.

   When ASPUP message is received while the SGP is in SGP-UP state, SGP
   stays in SGP-UP state and an ASPUP-ACK message is sent.  In such a
   situation, if the SGP sending ASPUP message was the only SGP in
   SGP-UP state and if the SG is in SG-ACTIVE state, SG state is chnaged
   to SG-UP state.



Asveren, et al.           Expires June 3, 2006                 [Page 14]

Internet-Draft          M3UA SG-SG Communication           November 2005


   When ASPUP-ACK message is received without sending an ASPUP message,
   remote SGP is put to SGP-DOWN state and an Error message with reason
   "Unexpected Message" is sent.


6.2.  ASP Down Procedures

   When a SGP does not want to send/receive DATA messages to/from a SGP,
   for which it was already in SGP-UP state, it sends ASPDN message.

   When ASPDN message is received while the peer SGP is already in SGP-
   DOWN state, an Error message with reason "Unexpected message" is
   sent.

   When the SGP sends an ASPDN message, it starts timer T(ack).  If the
   SGP does not receive a response to ASPDN message within T(ack), the
   SGP MAY restart T(ack) and resend ASPDN.

6.3.  ASP Active Procedures

   ASPAC message MUST be sent to mark the end of SSNM, intiially sent to
   report PCs, which are configured as reachable via the SGP, but
   currently are not accessible or restricted.

   A received ASPAC message SHOULD be acknowledged with ASPAC-ACK
   message.

   When the SGP sends an ASPAC message, it starts timer T(ack).  If the
   SGP does not receive a response to ASPAC message within T(ack), the
   SGP MAY restart T(ack) and resend ASPAC.

   A SGP SHOULD NOT start sending DATA to a peer SGP before receiving
   both ASPAC and ASPAC-ACK from the peer SGP.


7.  Examples of SG-SG Communication Procedures

7.1.  M3UA Availability Declaration

   In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists
   of SGP3/SGP4.  After establishmnet of SCTP association between SGPs,
   each SGP should make its peers aware that its own M3UA layer is
   ready.








Asveren, et al.           Expires June 3, 2006                 [Page 15]

Internet-Draft          M3UA SG-SG Communication           November 2005


    SGP1      SGP2          SGP3      SGP4
      |        |              |        |
      +------ASPUP----------->|        |
      |        |              |        |
      +------ASPUP------------+------->|
      |        |              |        |
      |<-----ASPUP-ACK--------|        |
      |        |              |        |
      |<-----ASPUP------------+--------|
      |        |              |        |
      |<-----ASPUP-ACK--------+--------|
      |        |              |        |
      |------ASPUP-ACK--------+------->|
      |        |              |        |
      |        |<---ASPUP-----|        |
      |        |              |        |
      |        |--ASPUP-ACK-->|        |
      |        |              |        |
      |        |-----ASPUP----+------->|
      |        |              |        |
      |        |<------ASPUP-ACK-------|
      |        |              |        |
      |        |              |        |


7.2.  PC Status Announcement

   In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists
   of SGP3/SGP4.  The scenario shows message exchange after M3UA
   availability declaration is performed.  Pc1/PC2/PC3 are configured as
   reachable via SG2 in SG1 and PC4/PC5 are configured as reachable via
   SG1 in SG2.  During PC Status Announcement procedure, PC1 is
   unavailable in SG1 and PC2 is restricted.  PC4 is unavailable in SG2.


















Asveren, et al.           Expires June 3, 2006                 [Page 16]

Internet-Draft          M3UA SG-SG Communication           November 2005


      SGP1      SGP2             SGP3      SGP4
       |         |                |         |
       |-------DUNA(PC1)--------->|         |
       |         |                |         |
       |-------DRST(PC2)--------->|         |
       |         |                |         |
       |------ASPAC-------------->|         |
       |         |                |         |
       |<-----ASPAC-ACK-----------|         |
       |         |                |         |
       |<--------+----DUNA(PC4)---+---------|
       |         |                |         |
       |<--------+----ASPAC-------+---------|
       |         |                |         |
       |---------+----ASPAC-ACK---+-------->|
       |         |                |         |
       |<------DATA(PC3)----------|         |
       |         |                |         |
       |         |----DATA(PC5)-->|         |
       |         |                |         |



8.  IANA Considerations


9.  Security Considerations

   SG-SG communication inherits security risks and considerations that
   are present in M3UA.  Please see "Security" section of M3UA for those
   security considerations and recommendations.

   Because SG-SG communication introduces relaying capability and can be
   places at network boundaries of networks belonging to different
   operators, additional security might be desirable.  Since SS7 related
   outages are very costly and increased interconnections between TDM
   and IP domain make SS7 networks more vulnerable to intentioanl and/or
   accidental disturbances, it is advisable for SGs to have capability
   to screen and act on SS7 messages going through it.  For example,
   screening of messages can be made based on configurable lists of OPC,
   DPC, SIO values or any combination of them.  Possible actions that
   are taken upon detection of disturbances could be informing network
   management entities, generation of alarms, discarding messages,
   modification of messages or a combination of them.  Other more
   sophisticated message syntax, message type and content based
   screening could also be implemented to improve security.





Asveren, et al.           Expires June 3, 2006                 [Page 17]

Internet-Draft          M3UA SG-SG Communication           November 2005


10.  Acknowledgments

   The authors would like to thank Manfred Angermayr, Vaibhav Madan, Ken
   Morneault and Kutluk Uslu for their valuable comments and
   suggestions.

11.  Normative References

   [1]  Sidebottom, G., Morneault, K., and J. Pastor-Balbas, "Signaling
        System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation
        Layer (M3UA)", RFC 3332, September 2002.

   [2]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [3]  ITU, "Q.704 (07/96) Specifications of Signalling System No. 7 -
        Message transfer part".

































Asveren, et al.           Expires June 3, 2006                 [Page 18]

Internet-Draft          M3UA SG-SG Communication           November 2005


Authors' Addresses

   Tolga Asveren
   Ulticom Inc.
   1020 Briggs Road
   Mount Laurel, NJ, 08054
   USA

   Email: asveren@ulticom.com


   Brian Bidulock
   OpenSS7 Corporation
   1469 Jeffreys Crescent
   Edmonton, AB   T6L 6T1
   Canada

   Email: bidulock@openss7.org


   Javier Pastor-Balbas
   Ericsson Espana S.A.
   C/ Retama1
   28045 Madrid
   Spain

   Email: j.javier.pastor@ericsson.com
























Asveren, et al.           Expires June 3, 2006                 [Page 19]

Internet-Draft          M3UA SG-SG Communication           November 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Asveren, et al.           Expires June 3, 2006                 [Page 20]