[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 draft-ietf-sigtran-rfc3332bis

Network Working Group                               Javier Pastor-Balbas
INTERNET-DRAFT                                                  Ericsson
Expires: December 2003
                                                            Ken Morneault
                                                           Cisco Systems


                                                              June, 2003



                         M3UA Implementor's Guide
           <draft-ietf-sigtran-m3ua-implementors-guide-04.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.

Copyright Notice

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

Abstract

   This document contains a compilation of all defects found up until
   the publication date for M3UA [RFC3332]. These defects may be of an
   editorial or technical nature. This document may be thought of as a
   companion document to be used in the implementation of M3UA to
   clarify errors in the original M3UA document. This document updates




Pastor, Morneault                                               [Page 1]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   RFC3332 and text within this document supersedes the text found in
   RFC3332.







TABLE OF CONTENTS

1.  Introduction.......................................................3
1.1  Abbreviations.....................................................3
2.  Conventions........................................................3
3.  Corrections to RFC3332.............................................3
3.1 Parameter Containing Subparameters with Padding Bytes..............3
3.2 Dynamic Registration Not Supported.................................4
3.3 Contents of User Protocol Data.....................................6
3.4 Scope of Network Appearance........................................7
3.5 Conditional RC parameter...........................................9
3.6 Receiving REG for a RK already registered.........................11
3.7 Dynamic Registration Support for Alias Point Code.................15
3.8 Auditing procedure and congestion state...........................15
3.9 Response to an ASPIA message......................................18
3.10 INFO and DIAG parameter length...................................19
3.11 IPSP stuff.......................................................20
3.12 Messages and Streams.............................................27
3.13 ASP Id for IPSP communication....................................28
3.14 n+k redundancy...................................................29
3.15 Multiple Parameters of the Same Type in a Message................34
3.16 Registered Routing Key State After Unexpected ASP Up Message.....35
3.17 Location of Network Appearance...................................36
3.18 Determination of Congestion Abatement When ASP Sends SCON........37
3.19 Removing CIC and SSN from RK.....................................38
3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45
3.21 NOTIFY messages are missing in Examples section..................46
4.  Acknowledgements..................................................56
5.  Authors' Addresses................................................56
6.  References........................................................56
7.  Changes Control...................................................56
7.1 Changes from v00 to v01...........................................56
7.2 Changes from v01 to v02...........................................57
7.3 Changes from v02 to v03...........................................57











Pastor, Morneault                                               [Page 2]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003





1. Introduction

   This document contains a compilation of all defects found up until
   the publication date for the MTP3 User Adaptation Layer (M3UA)
   [RFC3332]. These defects may be of an editorial or technical nature.
   This document may be thought of as a companion document to be used in
   the implementation of M3UA to clarify errors in the original M3UA
   document. This document updates RFC3332 and text within this
   document, where noted, supersedes the text found in RFC3332. Each
   error will be detailed within this document in the form of:

      - The problem description,
      - The text quoted from RFC3332,
      - The replacement text,
      - A description of the solution.

1.1  Abbreviations

   SPC    Signalling Point Code

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


3. Corrections to RFC3332

3.1 Parameter Containing Subparameters with Padding Bytes

3.1.1  Description of the problem

   If a parameter contains subparameters with padding bytes, should the
   parameter length include the subparameter padding bytes or not.

3.1.2  Text changes to the document

   ---------
   Old text: (Section 3.2)
   ---------
   Parameter Length: 16 bits (unsigned integer)

   The Parameter Length field contains the size of the parameter in
   bytes, including the Parameter Tag, Parameter Length, and Parameter
   Value fields. Thus, a parameter with a zero-length Parameter Value




Pastor, Morneault                                               [Page 3]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   field would have a Length field of 4.  The Parameter Length does not
   include any padding bytes.




   ---------
   New text: (Section 3.2)
   ---------
   Parameter Length: 16 bits (unsigned integer)

   The Parameter Length field contains the size of the parameter in
   bytes, including the Parameter Tag, Parameter Length, and Parameter
   Value fields. Thus, a parameter with a zero-length Parameter Value
   field would have a Length field of 4.  The Parameter Length does not
   include any padding bytes. If the parameter contains subparameters,
   the Parameter Length field will include all the bytes of each
   subparameter including subparameter padding bytes (if any).



3.1.3 Solution description

   When calculating the length of a parameter that contains
   subparameters, include the padding bytes of the subparameters.


3.2  Dynamic Registration Not Supported

3.2.1 Description of the problem

   There is a need to be able to correlate a Dynamic Registration not
   supported error to a Registration Request.


3.2.2 Text changes to the document

   ---------
   Old text: (Section 4.4.1)
   ---------

   If the SGP does not support the registration procedure, the SGP
   returns an Error message to the ASP, with an error code of
   "Unsupported Message Type".

   ---------
   New text: (Section 4.4.1)
   ---------






Pastor, Morneault                                               [Page 4]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   If the SGP does not support the registration procedure, the SGP
   returns an Error message to the ASP, with an error code of
   "Unsupported Message Class".





   ---------
   Old text: (Section 3.8.1)
   ---------

   The "Unsupported Message Class" error is sent if a message with an
   unexpected or unsupported Message Class is received.

   The "Unsupported Message Type" error is sent if a message with an
   unexpected or unsupported Message Type is received.

   ---------
   New text: (Section 3.8.1)
   ---------

   The "Unsupported Message Class" error is sent if a message with an
   unexpected or unsupported Message Class is received.  For this error,
   the Diagnostic Information parameter MUST be included with the first
   40 bytes of the offending message.

   The "Unsupported Message Type" error is sent if a message with an
   unexpected or unsupported Message Type is received.  For this error,
   the Diagnostic Information parameter MUST be included with the first
   40 bytes of the offending message.


   ---------
   Old text:
   ---------

   The Error message contains the following parameters:
   Error Code                 Mandatory
   Routing Context            Mandatory*
   Network Appearance         Mandatory*
   Affected Point Code        Mandatory*
   Diagnostic Information     Optional

   (*) Only mandatory for specific Error Codes


   ---------
   New text:
   ---------




Pastor, Morneault                                               [Page 5]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   The Error message contains the following parameters:
   Error Code                 Mandatory
   Routing Context            Mandatory*
   Network Appearance         Mandatory*
   Affected Point Code        Mandatory*
   Diagnostic Information     Conditional

   (*) Only mandatory for specific Error Codes


3.2.3 Solution description

   A SGP that does not support registration must return an Error
   (Unsupported Message Class) message with the first 40 bytes of the
   offending message (i.e. any Routing Key Management message sent by
   the ASP) so that the ASP can correlate this error to the Registration
   Request message.

   Note that the changes to the "Unsupported Message Class" and
   "Unsupported Message Type" text make this a general solution that
   allows the ASP or SG side to correlate these error responses with the
   offending message.



3.3 Contents of User Protocol Data

3.3.1 Description of the problem

   There is a need to add a reference that contains the different SS7
   message label types to ensure implementations take into account the
   differences among these labels.

3.3.2 Text changes to the document

   ---------
   Old text: (Section 3.3.1)
   ---------

   Protocol Data: (variable)

        The Protocol Data field contains a byte string of MTP-User
        information from the original SS7 message starting with the
        first byte of the original SS7 message following the Routing
        Label.

   ---------
   New text: (Section 3.3.1)
   ---------

   Protocol Data: (variable)



Pastor, Morneault                                               [Page 6]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



        The Protocol Data field contains a byte string of MTP-User
        information from the original SS7 message starting with the
        first byte of the original SS7 message following the Routing
        Label [7][8][29].



   ---------
   Old text: (Section 9.1)
   ---------

   [7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
          (SS7) - Message Transfer Part (MTP

   ---------
   New text: (Section 9.1)
   ---------

   [7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7
          (SS7) - Message Transfer Part (MTP)"

3.3.3 Solution description

   A proper reference was required for the different SS7 message label
   types.




3.4 Scope of Network Appearance

3.4.1 Description of the problem

   A problem was found with the scope of the NA parameter. It was not
   clear whether it should be unique across SG-AS or unique across SCTP
   associations

3.4.2 Text changes to the document

   ---------
   Old text: (Section 3.3.1)
   ---------
   Network Appearance: 32-bits (unsigned integer)

   The Network Appearance parameter identifies the SS7 network context
   for the message and implicitly identifies the SS7 Point Code format
   used, the SS7 Network Indicator value, and the MTP3 and possibly the
   MTP3-User protocol type/variant/version used within the specific SS7
   network.  Where an SG operates in the context of a single SS7
   network, or individual SCTP associations are dedicated to each SS7



Pastor, Morneault                                               [Page 7]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   network context, the Network Appearance parameter is not required.
   In other cases the parameter may be configured to be present for the
   use of the receiver.

   The Network Appearance parameter value is of local significance only,
   coordinated between the SGP and ASP. Therefore, in the case where an
   ASP is connected to more than one SGP, the same SS7 network context
   may be identified by different Network Appearance values depending
   over which SGP a message is being transmitted/received.

   Where the optional Network Appearance parameter is present, it must
   be the first parameter in the message as it defines the format of the
   Protocol Data field.

   IMPLEMENTATION NOTE: For simplicity of configuration it may be
   desirable to use the same NA value across all nodes sharing a
   particular network context.




   ---------
   New text: (Section 3.3.1)
   ---------

   Network Appearance: 32-bits (unsigned integer)

   The Network Appearance parameter identifies the SS7 network context
   for the message and implicitly identifies the used SS7 Point Code
   format, the SS7 Network Indicator value, and the MTP3 and possibly
   the MTP3-User protocol type/variant/version used within the specific
   SS7 network.  Where a SG operates in the context of a single SS7
   network, or individual SCTP associations are dedicated to each SS7
   network context, the Network Appearance parameter is not required.
   In other cases the parameter may be configured to be present for the
   use of the receiver.

   The Network Appearance parameter value is of local significance only,
   coordinated between the SG and AS. Therefore, in the case where an AS
   is connected to more than one SG, the same SS7 network context may be
   identified by different Network Appearance values depending over
   which SG a message is being transmitted/received.

   Where the optional Network Appearance parameter is present, it must
   be the first parameter in the message as it defines the format of the
   Protocol Data field.

   IMPLEMENTATION NOTE: For simplicity of configuration it may be
   desirable to use the same NA value across all nodes sharing a
   particular network context.




Pastor, Morneault                                               [Page 8]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


3.4.3 Solution description

   The text is modified to show that NA has to be coordinated between AS
   to SG. This correction also aligns this text with the NA definition
   in section 1.2 of the RFC.


3.5 Conditional RC parameter

3.5.1 Description of the problem

   Some optional parameters are not always optional. The text should be
   clear when conditionally optional parameters are mandatory.








3.5.2 Text changes to the document

   ---------
   Old text: (Section 3.3.1)
   ---------

   3.3.1 Payload Data Message (DATA)

   The DATA message contains the SS7 MTP3-User protocol data, which is
   an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
   The DATA message contains the following variable length parameters:
        Network Appearance       Optional
        Routing Context          Optional
        Protocol Data            Mandatory
        Correlation Id           Optional

   ---------
   New text: (Section 3.3.1)
   ---------

   3.3.1 Payload Data Message (DATA)

   The DATA message contains the SS7 MTP3-User protocol data, which is
   an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
   The DATA message contains the following variable length parameters:
        Network Appearance       Optional
        Routing Context          Conditional
        Protocol Data            Mandatory
        Correlation Id           Optional




Pastor, Morneault                                               [Page 9]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



   ---------
   Old text: (Section 3.4.1)
   ---------

        Routing Context          Optional

   ---------
   New text: (Section 3.4.1)
   ---------

        Routing Context          Conditional


   ---------
   Old text: (Section 3.4.2)
   ---------

        Routing Context          Optional


   ---------
   New text: (Section 3.4.2)
   ---------

        Routing Context          Conditional


   ---------
   Old text: (Section 3.4.3)
   ---------

        Routing Context          Optional

   ---------
   New text: (Section 3.4.3)
   ---------

        Routing Context          Conditional


   ---------
   Old text: (Section 3.4.4)
   ---------

        Routing Context          Optional

   ---------
   New text: (Section 3.4.4)
   ---------




Pastor, Morneault                                              [Page 10]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


        Routing Context          Conditional


   ---------
   Old text: (Section 3.4.5)
   ---------

        Routing Context          Optional

   ---------
   New text: (Section 3.4.5)
   ---------

        Routing Context          Conditional


   ---------
   Old text: (Section 3.4.6)
   ---------

        Routing Context          Optional

   ---------
   New text: (Section 3.4.6)
   ---------

        Routing Context          Conditional



3.5.3 Solution description

   Stating that the parameter is conditional implies that it is not
   either optional or mandatory. In the parameter description, the text
   explains when Routing Context is mandatory and when optional.


3.6 Receiving REG for a RK already registered

3.6.1 Description of the problem

   The RFC does not clearly specify what the SG should do when it
   receives a Registration Request for a Routing Key that has already
   been registered. There are two scenarios to consider: the
   registration request is a duplicate or the registration request
   indicates a desire to modify the Routing Key

3.6.2 Text changes to the document

   ---------
   Old text: (Section 3.6.1)



Pastor, Morneault                                              [Page 11]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   ---------

   The format of the Routing Key parameter 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Local-RK-Identifier                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Traffic Mode Type (optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Point Code                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Network Appearance (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Indicators (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Originating Point Code List (optional)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Circuit Range List (optional)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                              ...                              /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Point Code                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Indicators (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Originating Point Code List (optional)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Circuit Range List (optional)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ---------
   New text: (Section 3.6.1)
   ---------

   The format of the Routing Key parameter 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Local-RK-Identifier                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Routing Context (optional)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Traffic Mode Type (optional)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Point Code                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Pastor, Morneault                                              [Page 12]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


     |                  Network Appearance (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Indicators (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Originating Point Code List (optional)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Circuit Range List (optional)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                              ...                              /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Point Code                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Indicators (optional)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Originating Point Code List (optional)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Circuit Range List (optional)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ---------
   Old text: (Section 4.4.1)
   ---------

   Registration Status: 32-bit integer

     The Registration Result Status field indicates the success or the
     reason for failure of a registration request.
     Its values may be:

        0           Successfully Registered
        1           Error - Unknown
        2           Error - Invalid DPC
        3           Error - Invalid Network Appearance
        4           Error - Invalid Routing Key
        5           Error - Permission Denied
        6           Error - Cannot Support Unique Routing
        7           Error - Routing Key not Currently Provisioned
        8           Error - Insufficient Resources
        9           Error - Unsupported RK parameter Field
        10          Error - Unsupported/Invalid Traffic Handling Mode

   ---------
   New text: (Section 4.4.1)
   ---------

   Registration Status: 32-bit integer

     The Registration Result Status field indicates the success or the
     reason for failure of a registration request.



Pastor, Morneault                                              [Page 13]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


     Its values may be:
        0           Successfully Registered
        1           Error - Unknown
        2           Error - Invalid DPC
        3           Error - Invalid Network Appearance
        4           Error - Invalid Routing Key
        5           Error - Permission Denied
        6           Error - Cannot Support Unique Routing
        7           Error - Routing Key not Currently Provisioned
        8           Error - Insufficient Resources
        9           Error - Unsupported RK parameter Field
        10          Error - Unsupported/Invalid Traffic Handling Mode
        11          Error - Routing Key Change Refused


   ---------
   Old text: (Section 4.4.1)
   ---------

   None.

   --------
   New text: (Section 4.4.1)
   ---------

   If the SGP determines that the received RK was already registered,
   the SGP returns a Registration Response message to the ASP,
   containing a Registration Result "Error - Cannot Support Unique
   Routing". This error applies whether the Routing Key is Active or
   Inactive.

   An ASP MAY modify an existing Routing Key by including a Routing
   Context parameter 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 Registration Response "ERR - Routing Key
   Change Refused" is returned if the SGP does not accept the
   modification of the Routing Key due to either it does not support the
   re-registration procedure or the specific RC does not exist.

   If the change is accepted, a Registration Response "Successfully
   Registered" is returned.

3.6.3 Solution description

   By specifying the error code and this new text, the cases of
   receiving a duplicate registration request or modification to a
   Routing Key are resolved.






Pastor, Morneault                                              [Page 14]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



3.7 Dynamic Registration Support for Alias Point Code

3.7.1 Description of the problem

   There is no text regarding the support of an Alias Point Code
   configuration in the dynamic registration of Routing Keys.

3.7.2 Text changes to the document

   ---------
   Old text: (Section 3.6.1)
   ---------

      Destination Point Code:

         The Destination Point Code parameter is mandatory, and
         Identifies the Destination Point Code of incoming SS7 traffic
         for which the ASP is registering.  The format is the same as
         described for the Affected Destination parameter in the DUNA
         message (See Section 3.4.1).  Its format is:

   ---------
   New text: (Section 3.6.1)
   ---------

      Destination Point Code:

         The Destination Point Code parameter is mandatory, and
         Identifies the Destination Point Code of incoming SS7 traffic
         for which the ASP is registering.  For an alias point code
         configuration, the DPC parameter would be repeated for each
         point code.  The format is the same as described for the
         Affected Destination parameter in the DUNA message (See Section
         3.4.1).  Its format is:

3.7.3 Solution description

   The solution was to add some text to describe how an alias point code
   configuration could be supported with dynamic registration.

3.8 Auditing procedure and congestion state

3.8.1 Description of the problem

   The current description of the AUDIT procedure in regards to
   congestion state is not clear enough. When to send SCON is not
   completely specified.






Pastor, Morneault                                              [Page 15]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003




3.8.2 Text changes to the document

   ---------
   Old text: (Section 3.3.1)
   ---------

   [...]. Where the SGP maintains the congestion status of the SS7
   destination, and the SS7 destination is congested, the SGP MUST
   additionally respond with an SCON message before the DAVA or DRST
   message.  If the SS7 destination is available and congested, the SGP
   MUST respond with an SCON message and then a DAVA message.  If the
   SS7 destination is restricted and congested, the SGP MUST respond
   with an SCON message immediately followed by a DRST message.  If the
   SGP has no information on the availability status of the SS7
   destination, the SGP responds with a DUNA message, as it has no
   routing information to allow it to route traffic to this destination.

   ---------
   New text: (Section 3.3.1)
   ---------

   [...]. Where the SGP maintains the congestion status of the SS7
   destination, the SGP MUST additionally respond with an SCON message
   before the DAVA or DRST message.  If the SS7 destination is
   available, the SGP MUST respond with an SCON message (indicating the
   appropriate congestion level) and then a DAVA message.  If the SS7
   destination is restricted, the SGP MUST respond with an SCON message
   (with the appropriate congestion level) immediately followed by a
   DRST message.  If the SGP has no information on the availability
   status of the SS7 destination, the SGP responds with a DUNA message,
   as it has no routing information to allow it to route traffic to this
   destination.

   Where the SGP does not maintain the congestion status of the SS7
   destination, the response to a DAUD message should always be only a
   DAVA, DRST or DUNA message as appropriate.


   ---------
   Old text: (Section 5.4)
   ---------

   5.4 M3UA/MTP3-User Boundary Examples


   ---------
   New text: (Section 5.4, 5.5)
   ---------




Pastor, Morneault                                              [Page 16]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   5.4 Auditing examples

   5.4.1 SG State: Uncongested / Unavailable

          ASP                          SGP
          ---                          ---
           |  -------- DAUD --------->  |
           |  <------ SCON(0) --------  |
           |  <------- DUNA ----------  |


   5.4.2 SG state: Congested (Congestion Level=2) / Available

          ASP                          SGP
          ---                          ---
           |  -------- DAUD --------->  |
           |  <------ SCON(2) --------  |
           |  <------- DAVA ----------  |



   5.4.3 SG state: Unknown / Available

          ASP                          SGP
          ---                          ---
           |  -------- DAUD --------->  |
           |  <------- DAVA ----------  |



   5.4.4 SG state: Uncongested / Unavailable

          ASP                          SGP
          ---                          ---
           |  -------- DAUD --------->  |
           |  <------- DUNA ----------  |



   5.5 M3UA/MTP3-User Boundary Examples



3.8.3 Solution description

   Whenever a DAUD is received, it has to be responded with
   DAVA/DUNA/DRST message depending on the peer node's state. If the SGP
   has congestion control (i.e. no ITU international networks) an SCON
   message with the appropriate congestion level should precede to the
   DAVA/DRST messages upon a DAUD arrival.



Pastor, Morneault                                              [Page 17]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



   A new examples section has been added to show this behavior.


3.9 Response to an ASPIA message

3.9.1 Description of the problem

   It was not clear how to act in the following scenario:


          ASP                          SGP
          ---                          ---
           |  ------ ASPIA (RC1)----->  |
           |  <----  ASPIA Ack -------  |
           |  -----DEREG REQ (RC1)--->  |
           |  <----DEREG RSP (RC1)----  |
           |  -------ASPIA (RC1)----->  |


   What should SG do?

3.9.2 Text changes to the document

   ---------
   Old text: (Section 4.5.3)
   ---------

   When an ASP wishes to withdraw from receiving traffic within an AS,
   the ASP sends an ASP Inactive message to the SGP or IPSP.  This
   action MAY be initiated at the ASP by an M-ASP_INACTIVE request
   primitive from Layer Management or MAY be initiated automatically by
   an M3UA management function.  In the case where an ASP is processing
   the traffic for more than one Application Server across a common SCTP
   association, the ASP Inactive message contains one or more Routing
   Contexts to indicate for which Application Servers the ASP Inactive
   message applies.

   ---------
   New text: (Section 4.5.3)
   ---------

   When an ASP wishes to withdraw from receiving traffic within an AS,or
   the ASP wants to initiate the process of activation, the ASP sends an
   ASP Inactive message to the SGP or IPSP.

   An ASP Inactive message MUST be always responded by the peer
   (although other messages may be sent in the middle):






Pastor, Morneault                                              [Page 18]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


      - If the corresponding RK is registered (statically or
         dynamically), the peer should respond with an ASP Inactive Ack
         message.
      -         If the RK is not registered, or the RC information is not valid,
         the peer must respond with an ERROR message with Error Code =
         "Invalid Routing Context".
      - If the RC is missing and its specification is needed according
         to the used configuration, the peer must respond with an ERROR
         message with Error Code = "No Configured AS for ASP".

   The action of sending the ASP Inactive message MAY be initiated at
   the ASP by an M-ASP_INACTIVE request primitive from Layer Management
   or MAY be initiated automatically by an M3UA management function.  In
   the case where an ASP is processing the traffic for more than one
   Application Server across a common SCTP association, the ASP Inactive
   message contains one or more Routing Contexts to indicate for which
   Application Servers the ASP Inactive message applies.

3.9.3 Solution description

   A more detailed specification of the messages to be sent upon the
   reception of an ASPIA has been added to the Inactive Procedures
   Section.


3.10 INFO and DIAG parameter length

3.10.1 Description of the problem

   At the second interop a question was raised about accepting a length
   of 4 bytes for DIAG and INFO parameters.


3.10.2 Text changes to the document

   ---------
   Old text: (Section 3.4.1)
   ---------

   INFO String: variable length

   The optional INFO String parameter can carry any meaningful UTF-8
   [10] character string along with the message. Length of the INFO
   String parameter is from 0 to 255 octets. No procedures are presently
   identified for its use but the INFO String MAY be used for debugging
   purposes.


   ---------
   New text: (Section 3.4.1)
   ---------



Pastor, Morneault                                              [Page 19]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



   INFO String: variable length

   The optional INFO String parameter can carry any meaningful UTF-8
   [10] character string along with the message. Length of the INFO
   String parameter is from 0 to 255 octets. This means that No
   procedures are presently identified for its use but the INFO String
   MAY be used for debugging purposes. An INFO String with a zero length
   parameter is not considered as an error (this means that the Length
   field in the TLV will be set to 4).


   ---------
   Old text: (Section 3.8.1)
   ---------

   Diagnostic Information: variable length

   When included, the optional Diagnostic information can be any
   information germane to the error condition, to assist in
   identification of the error condition. The Diagnostic information
   SHOULD contain the offending message.


   ---------
   New text: (Section 3.8.1)
   ---------

   Diagnostic Information: variable length

   When included, the optional Diagnostic information can be any
   information germane to the error condition, to assist in
   identification of the error condition. The Diagnostic information
   SHOULD contain the offending message. TheDiagnostic Information
   parameter with a zero length parameter is not considered as an error
   (this means that the Length field in the TLV will be set to 4).


3.10.3 Solution description

   It has been explicitly included the fact that a parameter with length
   zero is allowed.



3.11 IPSP stuff

3.11.1 Description of the problem

   At the 2nd M3UA Plugtest several concerns were raised about the non-
   interoperability of the two different IPSP exchanges defined in M3UA.



Pastor, Morneault                                              [Page 20]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003




3.11.2 Text changes to the document

   ---------
   Old text: (Section 4.3)
   ---------

   4.3 AS and ASP State Maintenance

   The M3UA layer on the SGP maintains the state of each remote ASP, in
   each Application Server that the ASP is configured to receive
   traffic, as input to the M3UA message distribution function.
   Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA
   layer in an IPSP maintains the state of remote IPSPs. For the
   purposes of the following procedures, only the SGP/ASP case is
   described but the SGP side of the procedures also apply to an IPSP
   sending traffic to an AS consisting of a set of remote IPSPs.

   ---------
   New text: (Section 4.3)
   ---------

   4.3 AS and ASP/IPSP State Maintenance

   The M3UA layer on the SGP maintains the state of each remote ASP, in
   each Application Server that the ASP is configured to receive
   traffic, as input to the M3UA message distribution function.
   Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA
   layer in an IPSP maintains the state of remote IPSPs.

   Two IPSP models are defined with regards to the number of messages
   that are needed to a IPSP state change. They are defined as follows:

   1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM
      or ASPSM messages is needed to change the IPSP state. This means
      that a set of request from one end and acknowledge from the other
      will be enough. This configuration requires static RK
      configuration.

   2- IPSP Double Exchange (DE) model. Both IPSPs have to send request
      messages and both IPSPs have to acknowledge the request messages
      from the other end. This results in a double exchange of ASPTM and
      ASPSM message, one from each end. This configuration supports
      dynamic routing key configuration by using RKM messages in the
      same way as ASP-SGP scenario.

   In order to ensure interoperability, an M3UA implementation
   supporting IPSP communication MUST support IPSP SE model and MAY
   implement IPSP DE model.




Pastor, Morneault                                              [Page 21]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



   In section 4.3.1: ASP/IPSP States, only the SGP-ASP and the IPSP SE
   scenarios are described. For the IPSP DE model, both IPSPs MUST
   follow the SGP side of the SGP-ASP procedures.

   In section 4.3.2, only the SGP-ASP scenario is described. All of the
   procedures referring to an AS served by ASPs are also applicable to
   ASes served by IPSPs.

   In section 4.3.3, only the Management procedures for the SGP-ASP
   scenario are described. The corresponding Management procedures for
   IPSPs are directly inferred.

   The remaining sections contain specific IPSP Considerations sub-
   sections.



   ---------
   Old text: (Section 4.3.1)
   ---------

   4.3.1 ASP States

   The state of each remote ASP, in each AS that it is configured to
   operate, is maintained in the M3UA layer in the SGP. The state of a
   particular ASP in a particular AS changes due to events. The events
   include:

   * Reception of messages from the peer M3UA layer at the ASP;
   * Reception of some messages from the peer M3UA layer at other ASPs
     in the AS (e.g., ASP Active message indicating "Override");
   * Reception of indications from the SCTP layer; or
   * Local Management intervention.

   The ASP state transition diagram is shown in Figure 3.  The possible
   states of an ASP are:

   ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the
   related SCTP association is down.  Initially all ASPs will be in this
   state.  An ASP in this state SHOULD NOT be sent any M3UA messages,
   with the exception of Heartbeat, ASP Down Ack and Error messages.

   ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the
   related SCTP association is up) but application traffic is stopped.
   In this state the ASP SHOULD NOT be sent any DATA or SSNM messages
   for the AS for which the ASP is inactive.

   ASP-ACTIVE: The remote M3UA peer at the ASP is available and
   application traffic is active (for a particular Routing Context or
   set of Routing Contexts).



Pastor, Morneault                                              [Page 22]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



   SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
   Down Indication to the Upper Layer Protocol (M3UA) on an SGP.  The
   local SCTP layer will send this indication when it detects the loss
   of connectivity to the ASP's peer SCTP layer.  SCTP CDI is understood
   as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
   notification from the SCTP layer.

   SCTP RI: The local SCTP layer's Restart indication to the upper layer
   protocol (M3UA) on an SG.  The local SCTP will send this indication
   when it detects a restart from the ASP's peer SCTP layer.


   ---------
   New text: (Section 4.3.1)
   ---------

   4.3.1 ASP States

   The state of each remote ASP/IPSP, in each AS that it is configured
   to operate, is maintained in the peer M3UA layer (i.e. in the SGP or
   peer IPSP, respectively). The state of a particular ASP/IPSP in a
   particular AS changes due to events. The events include:

   * Reception of messages from the peer M3UA layer at the ASP/IPSP;
   * Reception of some messages from the peer M3UA layer at other
     ASPs/IPSPs in the AS (e.g., ASP Active message indicating
     "Override");
   * Reception of indications from the SCTP layer; or
   * Local Management intervention.

   The ASP/IPSP state transition diagram is shown in Figure 3.  The
   possible states of an ASP/IPSP are:

   ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable and/or
   the related SCTP association is down.  Initially all ASPs/IPSPs will
   be in this state. An ASP/IPSP in this state SHOULD NOT be sent any
   M3UA messages, with the exception of Heartbeat, ASP Down Ack and
   Error messages.

   ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and
   the related SCTP association is up) but application traffic is
   stopped. In this state the ASP/IPSP SHOULD NOT be sent any DATA or
   SSNM messages for the AS for which the ASP/IPSP is inactive.

   ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and
   application traffic is active (for a particular Routing Context or
   set of Routing Contexts).

   SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
   Down Indication to the Upper Layer Protocol (M3UA) on an SGP.  The



Pastor, Morneault                                              [Page 23]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   local SCTP layer will send this indication when it detects the loss
   of connectivity to the ASP's peer SCTP layer.  SCTP CDI is understood
   as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
   notification from the SCTP layer.

   SCTP RI: The local SCTP layer's Restart indication to the upper layer
   protocol (M3UA) on an SG.  The local SCTP will send this indication
   when it detects a restart from the ASP's/IPSP's peer SCTP layer.



   ---------
   Old text: (Section 4.3.1)
   ---------

   Figure 4: ASP State Transition Diagram, per AS

                                      +--------------+
                                      |              |
               +----------------------|  ASP-ACTIVE  |
               |      Other   +-------|              |
               |   ASP in AS  |       +--------------+
               |   Overrides  |           ^     |
               |              |    ASP    |     | ASP
               |              |    Active |     | Inactive
               |              |           |     v
               |              |       +--------------+
               |              |       |              |
               |              +------>| ASP-INACTIVE |
               |                      +--------------+
               |                          ^     |
     ASP Down/ |                     ASP  |     | ASP Down /
     SCTP CDI/ |                     Up   |     | SCTP CDI/
     SCTP RI   |                          |     v SCTP RI
               |                      +--------------+
               |                      |              |
               +--------------------->|   ASP-DOWN   |
                                      |              |
                                      +--------------+

   ---------
   New text: (Section 4.3.1)
   ---------

   The figure below shows the transitions for the ASP and IPSP cases.

           Figure 5: ASP/IPSP State Transition Diagram, per AS

                                      +--------------+
                                      |              |
               +----------------------|  ASP-ACTIVE  |



Pastor, Morneault                                              [Page 24]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


               |        Other +-------|              |
               |   IPSP in AS |       +--------------+
               |    Overrides |           ^     |
               |              |    ASPAC/ |     | ASPIA/
               |              |[ASPAC-Ack]|     | [ASPIA-Ack]
               |              |           |     v
               |              |       +--------------+
               |              |       |              |
               |              +------>| ASP-INACTIVE |
               |                      |              |
               |                      +--------------+
               |                          ^     |
        ASPDN/ |                          |     | ASPDN /
   [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
     SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
     SCTP RI   |                          |     | SCTP RI
               |                          |     v
               |                      +--------------+
               |                      |              |
               +--------------------->|   ASP-DOWN   |
                                      |              |
                                      +--------------+



   The transitions in brackets are just valid for the IPSP SE model
   communication while the rest are valid for both ASPs and IPSPs.


   ---------
   Old text: (Section 4.3.4.1.2)
   ---------

   Alternatively, an interchange of ASP Up messages from each end can be
   performed. This option follows the ASP state transition diagram. It
   would need four messages for completion.

   ---------
   New text: (Section 4.3.4.1.2)
   ---------

   Alternatively, when using IPSP DE model, an interchange of ASP Up
   messages from each end MUST be performed. Four messages are needed
   for completion.


   ---------
   Old text: (Section 4.3.4.3.1)
   ---------





Pastor, Morneault                                              [Page 25]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   Alternatively, an interchange of ASP Active messages from each end
   can be performed. This option follows the ASP state transition
   diagram and gives the additional advantage of selecting a particular
   AS to be activated from each end. It is especially useful when an
   IPSP is serving more than one AS. It would need four messages for
   completion.

   ---------
   New text: (Section 4.3.4.3.1)
   ---------

   Alternatively, when using IPSP DE model, an interchange of ASP Active
   messages from each end MUST be performed. Four messages are needed
   for completion.


   ---------
   Old text: (Section 4.3.4.4.1)
   ---------

   Alternatively, an interchange of ASP Inactive messages from each end
   can be performed. This option follows the ASP state transition
   diagram and gives the additional advantage of selecting a particular
   AS to be deactivated from each end. It is especially useful when an
   IPSP is serving more than one AS. It would need four messages for
   completion.

   ---------
   New text: (Section 4.3.4.4.1)
   ---------

   Alternatively, when using IPSP DE model, an interchange of ASP
   Inactive messages from each end MUST be performed. Four messages are
   needed for completion.


   ---------
   Old text: (Section 4.4.3)
   ---------

   The Registration/Deregistration procedures work in the IPSP cases in
   the same way as in AS-SG cases.  An IPSP may register an RK in the
   remote IPSP.  An IPSP is responsible for deregistering the RKs that
   it has registered.

   ---------
   New text: (Section 4.4.3)
   ---------

   The Registration/Deregistration procedures work in the IPSP cases in
   the same way as in AS-SG cases.  An IPSP may register an RK in the



Pastor, Morneault                                              [Page 26]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   remote IPSP.  An IPSP is responsible for deregistering the RKs that
   it has registered.

   For the IPSP SE model, it MAY be used one common RK for both IPSP
   participating in the communication using the Signaling Point Code
   granularity. It would basically consist of <OPC,DPC>. In the case of
   RC use, RCs SHOULD be previously agreed between both peers.



3.11.3 Solution description

   Text regarding procedures has been modified to explicitely include
   IPSP communication. A clear definition of both IPSP models has been
   included. Modifications in the ASP state machine have been done to
   also include the IPSP model. For interoperability purposes, IPSP SE
   model is mandated while DE model is allowed.


3.12 Messages and Streams

3.12.1 Description of the problem

   The relation between messages and what stream to use in order to send
   them is diffuse and spread all along the document.

3.12.2 Text changes to the document

   ---------
   Old text: (Section 1.4.7)
   ---------

   None.

   ---------
   New text: (Section 1.4.7)
   ---------

   The following rules MUST to be followed (see section 3.1.2):

   1. DATA message is never sent on stream 0.
   2. ASPSM, MGMT, RKM  classes should be sent on stream 0 (Other than
   BEAT, BEAT ACK and NTFY messages)
   3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be
      sent on any stream.


3.12.3 Solution description

   A clear specification of how messages should be sent is included in
   the corresponding section.



Pastor, Morneault                                              [Page 27]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



3.13 ASP Id for IPSP communication

3.13.1 Description of the problem

   When using the IPSP communication there is no way to dynamically
   exchange the ASP Identifier in both directions.


3.13.2 Text changes to the document



   ---------
   Old text: (Section 3.5.2)
   ---------

   The ASP Up Ack message contains the following parameters:
        INFO String (optional)

   The format for ASP Up Ack 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 =0x0004             |             Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   ---------
   New text: (Section 3.5.2)
   ---------

   The ASP Up Ack message contains the following parameters:
        ASP Identifier                Optional
        INFO String                   Optional

   The format for ASP Up Ack 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 = 0x0011          |           Length = 8          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         ASP Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag =0x0004           |             Length            |



Pastor, Morneault                                              [Page 28]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The optional ASP Identifier parameter is specifically useful for IPSP
   communication. In that case the IPSP answering the ASP Up message MAY
   include its own ASP Identifier value. For AS-SG communication this
   parameter MUST NOT be used.


3.13.3 Solution Description

   By including the optional ASP Identifier in ASP Up message this can
   be achieved. In the AS-SG communication this optional parameter is
   not needed


3.14 n+k redundancy

3.14.1 Description of the problem

   The n+k redundancy is explained as a general model to use but there
   is no reference in the current AS state diagram and sometimes it is
   not clear when to use it. Also n+k as defined in the introduction is
   subject to multiple interpretations.


3.14.2 Text changes to the document


   ---------
   Old text: (Section 1.4.4.1)
   ---------

   The failover model supports an "n+k" redundancy model, where "n" ASPs
   is the minimum number of redundant ASPs required to handle traffic
   and "k" ASPs are available to take over for a failed or unavailable
   ASP.  A "1+1" active/backup redundancy is a subset of this model. A
   simplex "1+0" model is also supported as a subset, with no ASP
   redundancy.


   ---------
   New text: (Section 1.4.4.1)
   ---------

   The failover model supports an "n+k" redundancy model, where "n" ASPs
   is the number of redundant ASPs required to handle traffic and "k"



Pastor, Morneault                                              [Page 29]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   ASPs are available to take over for a failed or unavailable ASP.
   Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be
   either active at the same time as "n" or kept inactive until needed
   due to a failed or unavailable ASP.

   A "1+1" active/backup redundancy is a subset of this model.  A
   simplex "1+0" model is also supported as a subset, with no ASP
   redundancy.



   ---------
   Old text: (Section 4.3.2)
   ---------

   AS-DOWN: The Application Server is unavailable.  This state implies
   that all related ASPs are in the ASP-DOWN state for this AS.
   Initially the AS will be in this state. An Application Server is in
   the AS-DOWN state when it is removed from a configuration.

   AS-INACTIVE: The Application Server is available but no application
   traffic is active (i.e., one or more related ASPs are in the ASP-
   INACTIVE state, but none in the ASP-ACTIVE state).  The recovery
   timer T(r) is not running or has expired.

   AS-ACTIVE: The Application Server is available and application
   traffic is active.  This state implies that at least one ASP is in
   the ASP-ACTIVE state.

   AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-
   DOWN  and it was the last remaining active ASP in the AS.  A recovery
   timer T(r) SHOULD be started and all incoming signalling messages
   SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r)
   expires, the AS is moved to the AS-ACTIVE state and all the queued
   messages will be sent to the ASP.

   If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
   alternative, the SGP may stops queuing messages and discards all
   previously queued messages. The AS will move to the AS-INACTIVE state
   if at least one ASP is in ASP-INACTIVE state, otherwise it will move
   to AS-DOWN state.

   Figure 5 shows an example AS state machine for the case where the
   AS/ASP data is preconfigured.  For other cases where the AS/ASP
   configuration data is created dynamically, there would be differences
   in the state machine, especially at creation of the AS.

                    Figure 5: AS State Transition Diagram

        +----------+   one ASP trans to ACTIVE   +-------------+
        |    AS-   |---------------------------->|     AS-     |



Pastor, Morneault                                              [Page 30]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


        | INACTIVE |                             |   ACTIVE    |
        |          |<---                         |             |
        +----------+    \                        +-------------+
           ^   |         \ Tr Expiry,                ^    |
           |   |          \ at least one             |    |
           |   |           \ ASP in ASP-INACTIVE     |    |
           |   |            \                        |    |
           |   |             \                       |    |
           |   |              \                      |    |
   one ASP |   | all ASP       \            one ASP  |    | Last ACTIVE
   trans   |   | trans to       \           trans to |    | ASP trans to
   to      |   | ASP-DOWN        -------\   ASP-     |    | ASP-INACTIVE
   ASP-    |   |                         \  ACTIVE   |    | or ASP-DOWN
   INACTIVE|   |                          \          |    |  (start Tr)
           |   |                           \         |    |
           |   |                            \        |    |
           |   v                             \       |    v
        +----------+                          \  +-------------+
        |          |                           --|             |
        | AS-DOWN  |                             | AS-PENDING  |
        |          |                             |  (queueing) |
        |          |<----------------------------|             |
        +----------+    Tr Expiry and no ASP     +-------------+
                        in ASP-INACTIVE state)

    Tr = Recovery Timer



   For example, where the AS/ASP configuration data is not created until
   Registration of the first ASP, the AS-INACTIVE state is entered
   directly upon the first successful REG REQ from an ASP.  Another
   example is where the AS/ASP configuration data is not created until
   the first ASP successfully enters the ASP-ACTIVE state.  In this case
   the AS-ACTIVE state is entered directly.


   ---------
   New text: (Section 4.3.2)
   ---------

   AS-DOWN: The Application Server is unavailable.  This state implies
   that the number of ASPs being in ASP-INACTIVE or ASP-ACTIVE is less
   than "n". Initially the AS will be in this state. An Application
   Server is in the AS-DOWN state when it is removed from a
   configuration.

   AS-INACTIVE: The Application Server is available but no application
   traffic is active. This implies that there are at least n ASPs in
   either ASP-INACTIVE or ASP-ACTIVE but the total number of ASPs in




Pastor, Morneault                                              [Page 31]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   ASP-ACTIVE state has not reach n.  The recovery timer T(r) is not
   running or has expired.

   AS-ACTIVE: The Application Server is available and application
   traffic is active. The AS moves to this state after being in AS-
   INACTIVE and getting n ASPs in ASP-ACTIVE state or, after reaching
   AS-ACTIVE and keeping one or more ASPs in ASP-ACTIVE state.
   When it is considered that one ASP is enough to handle traffic
   (smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon
   as the first ASP moves to the ASP-ACTIVE state.

   AS-PENDING: The last active ASP has transitioned from ASP-ACTIVE to
   ASP-INACTIVE or ASP-DOWN.  A recovery timer T(r) SHOULD be started
   and all incoming signalling messages SHOULD be queued by the SGP. If
   an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the
   AS-ACTIVE state and all the queued messages will be sent to the ASP.

   If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP MAY stop
   queuing messages and discards all
   previously queued messages. The AS will move to the AS-INACTIVE state
   if at least the number of ASPs in ASP-INACTIVE sum n, otherwise it
   will move to AS-DOWN state.

   Figure 5 shows an example AS state machine for the case where the
   AS/ASP data is preconfigured and an n+k redundancy model.


                Figure 5: AS State Transition Diagram


        +----------+          IA2AC              +-------------+
        |    AS-   |---------------------------->|     AS-     |
        | INACTIVE |                             |   ACTIVE    |
        |          |<-----------                 |             |
        +----------+            \                +-------------+
           ^   |                 \                    ^   |
           |   | IA2DN            \ PN2IA             |   | AC2PN
           |   |                   \                  |   |
     DN2IA |   |                    \          PN2AC  |   |
           |   v                     \                |   v
        +----------+                  \          +-------------+
        |          |                   ----------|             |
        | AS-DOWN  |                             | AS-PENDING  |
        |          |                  PN2DN      |  (queueing) |
        |          |<----------------------------|             |
        +----------+                             +-------------+



   DN2IA: One ASP moves to ASP-INACTIVE causing that n ASPs are in
   either ASP-ACTIVE or ASP-INACTIVE states.



Pastor, Morneault                                              [Page 32]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003



   IA2DN: One ASP moves to ASP-DOWN causing that the number of ASPs in
   either ASP-ACTIVE or ASP-INACTIVE drops below n.

   IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the
   ASP-ACTIVE state to be n.
   In a special case of smooth start, this transition MAY be done when
   the first ASP moves to ASP-ACTIVE state.

   AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-
   DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1.

   PN2AC: One ASP moves to ASP-ACTIVE.

   PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE.

   PN2DN: T(r) Expiry, the number of ASPs in ASP-INACTIVE state is less
   than n.

   As "n" ASPs are needed to handle the maximum engineered load of the
   AS, an AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE
   state during the start-up phase (except for smooth start). Once the
   traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP
   turns to another state different to ASP-ACTIVE, avoiding unnecessary
   traffic disturbances as long as there are ASPs available, in the
   assumption that the system will not always be exposed to the maximum
   load.

   There are other cases where the AS/ASP configuration data is created
   dynamically. In those cases there would be differences in the state
   machine, especially at creation of the AS. For example, where the
   AS/ASP configuration data is not created until Registration of the
   first ASP, the AS-INACTIVE state is entered directly upon the nth
   successful REG REQ from an ASP belonging to that AS.  Another example
   is where the AS/ASP configuration data is not created until the nth
   ASP successfully enters the ASP-ACTIVE state.  In this latter case
   the AS-ACTIVE state is entered directly.



   ---------
   Old text: (Section 4.3.4.3, for both loadsharing and broadcast)
   ---------

   An SGP or IPSP, upon reception of an ASP Active message for the first
   ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
   active ASP until it determines that there are sufficient resources to
   handle the expected load (e.g., until there are "n" ASPs in state
   ASP-ACTIVE in the AS).  In this case, the SGP or IPSP SHOULD withhold
   the Notify (AS-ACTIVE) until there are sufficient resources.




Pastor, Morneault                                              [Page 33]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   ---------
   New text: (Section 4.3.4.3, for both loadsharing and broadcast)
   ---------

   At start-up or re-start phases, an SGP or IPSP, upon reception of an
   ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT
   direct traffic to a newly active ASP until it determines that there
   are sufficient resources to handle the expected load (e.g., until
   there are "n" ASPs in state ASP-ACTIVE in the AS).  In this case, the
   SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are
   sufficient resources.




3.14.3 Solution description

   The AS state machine reflects the state changes as a function of the
   "n" number from the n+k redundancy configuration. This solution is
   compliance with the previous one: 1+0 model. The change from MAY to
   SHOULD NOT makes it recommendable to send traffic only when the
   require ASPs number are in ASP-ACTIVE state.
   Also it is explicitely stated that "n" is seen as the "maximum
   engineered load".


3.15 Multiple Parameters of the Same Type in a Message

3.15.1 Description of the problem

   There was some confusion about whether or not multiple parameters
   of same type were allowed in a message.

3.15.2 Text changes to the document


   ---------
   Old text: (Section 3.2)
   ---------

   Where more than one parameter is included in a message, the
   parameters may be in any order, except where explicitly mandated.  A
   receiver SHOULD accept the parameters in any order.


   ---------
   New text: (Section 3.2)
   ---------






Pastor, Morneault                                              [Page 34]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   Where more than one parameter is included in a message, the
   parameters may be in any order, except where explicitly mandated.  A
   receiver SHOULD accept the parameters in any order.

   Unless explicitly stated or shown in a message format diagram, only
   one parameter of the same type is allowed in a message.


3.15.3  Solution Description

   Added a statement to clarify that multiple parameters of the same
   type are forbidden in messages unless explicitly allowed.


3.16 Registered Routing Key State After Unexpected ASP Up Message
         Received

3.16.1 Description of the problem

   If the ASP unexpectedly sends an ASP Up message while in the
   ASP-ACTIVE state, it is not clear what the peer should do
   with registered Routing Keys.  Should these Routing Keys be
   maintained as registered or should they be considered
   deregistered?

3.16.2 Text changes to the document


   ---------
   Old text: (Section 4.3.4.1)
   ---------

   If an ASP Up message is received and internally the remote ASP is in
   the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as
   an Error message ("Unexpected Message), and the remote ASP state is
   changed to ASP-INACTIVE in all relevant Application Servers.


   ---------
   New text: (Section 4.3.4.1)
   ---------

   If an ASP Up message is received and internally the remote ASP is in
   the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as,
   an Error message ("Unexpected Message).  In addition, the remote ASP
   state is changed to ASP-INACTIVE in all relevant Application Servers
   and all registered Routing Keys are considered deregistered.

3.16.3 Solution Description

   Added a statement to clarify that registered Routing Keys will be



Pastor, Morneault                                              [Page 35]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   considered deregistered if an unexpected ASP Up message is received
   while the ASP is in the ASP-ACTIVE state.  This clarification ensures
   the two peers remain synchronized.


3.17 Location of Network Appearance

3.17.1 Description of the problem

   For the Payload Data message, it is clear that the Network
   Appearance, if included, MUST be the first parameter in the message.
   For the other messages that may contain Network Appearance, it is not
   so clear.

3.17.2 Text changes to the document

   ---------
   Old text: (Section 3.4.1)
   ---------

   Network Appearance: 32-bit unsigned integer

      See Section 3.3.1


   ---------
   New text: (Section 3.4.1)
   ---------

   Network Appearance: 32-bit unsigned integer

      The description of Network Appearance in Section 3.3.1 applies
      with the exception that Network Appearance does not have to be
      the first parameter in this message.

   ---------
   Old text: (Section 3.6.1)
   ---------

   Network Appearance:

      The optional Network Appearance parameter field identifies the SS7
      network context for the Routing Key, and has the same format as in
      the DATA message (See Section 3.3.1).  The absence of the Network
      Appearance parameter in the Routing Key indicates the use of any
      Network Appearance value.  Its format is:

   ---------
   New text: (Section 3.6.1)
   ---------




Pastor, Morneault                                              [Page 36]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   Network Appearance:

      The optional Network Appearance parameter field identifies the SS7
      network context for the Routing Key, and has the same format as in
      the DATA message (See Section 3.3.1) with the exception that it
      does not have to be the first parameter in the message.  The
      absence of the Network Appearance parameter in the Routing Key
      indicates the use of any Network Appearance value.  Its format is:

3.17.3 Solution Description

   Add statements to clarify that Network Appearance, if present, does
   not have to be the first parameter in the message with the exception
   of the Payload Data message.


3.18 Determination of Congestion Abatement When ASP Sends SCON

3.18.1 Description of the problem

   Currently, there is no text in the RFC indicating that the ASP
   indicates when congestion has abated.

3.18.2 Text changes to the document

   ---------
   Old text: (Section 3.4.4)
   ---------

   The SCON message can be sent from an SGP to all concerned ASPs to
   indicate that an SG has determined that there is congestion in the
   SS7 network to one or more destinations, or to an ASP in response to
   a DATA or DAUD message as appropriate.  For some MTP protocol
   variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
   congestion level changes.  The SCON message MAY also be sent from the
   M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer
   or the ASP is congested.

   ---------
   New text: (Section 3.4.1)
   ---------

   The SCON message can be sent from an SGP to all concerned ASPs to
   indicate that an SG has determined that there is congestion in the
   SS7 network to one or more destinations, or to an ASP in response to
   a DATA or DAUD message as appropriate.  For some MTP protocol
   variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
   congestion level changes.  The SCON message MAY also be sent from the
   M3UA layer of an ASP to an M3UA peer indicating that the congestion
   level of the M3UA layer or the ASP has changed.




Pastor, Morneault                                              [Page 37]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


3.18.3 Solution Description

   Clarify that the ASP needs to indicate when the congestion level has
   changed (including abatement).  Further, the ASP peer can maintain
   a timer, if desired, in case the ASP fails to indicate congestion
   abatement.


3.19 Removing CIC and SSN from RK

3.19.1 Description of the problem

   Use of SSN and CIC Routing Keys is inadequately defined in RFC3332
   leading to non-interoperable solutions.


3.19.2 Text changes to the document

   ---------
   Old text: (Section 1.4.2.1)
   ---------

   Possible SS7 address/routing information that comprise a Routing Key
   entry includes, for example, the OPC, DPC, SIO found in the MTP3
   routing label, or MTP3-User specific fields (such as the ISUP CIC,
   SCCP subsystem number).  Some example Routing Keys are: the DPC
   alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
   DPC/SSN combination.  The particular information used to define an
   M3UA Routing Key is application and network dependent, and none of
   the above examples are mandated.

   ---------
   New text: (Section 1.4.2.1)
   ---------

   Possible SS7 address/routing information that comprise a Routing Key
   entry includes, for example, the OPC, DPC, SIO found in the MTP3
   routing label.  Some example Routing Keys are: the DPC alone, the
   DPC/OPC combination, or the DPC/OPC/SI combination.  The particular
   information used to define an M3UA Routing Key is application and
   network dependent, and none of the above examples are mandated.


   ---------
   Old text: (Section 1.4.2.2)
   ---------

   Routing Keys SHOULD be unique in the sense that each received SS7
   signalling message SHOULD have a full or partial match to a single
   routing result. It is not necessary for the parameter range values
   within a particular Routing Key to be contiguous.  For example, an AS



Pastor, Morneault                                              [Page 38]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   should be configured to support call processing for multiple ranges
   of PSTN trunks that are not represented by contiguous CIC values.

   ---------
   New text: (Section 1.4.2.2)
   ---------

   Routing Keys SHOULD be unique in the sense that each received SS7
   signalling message SHOULD have a full or partial match to a single
   routing result. It is not necessary for the parameter range values
   within a particular Routing Key to be contiguous.

   ---------
   Old text: (Section 1.4.7)
   ---------

   The M3UA layer at both the SGP and ASP also supports the assignment
   of signalling traffic into streams within an SCTP association.
   Traffic that requires sequencing SHOULD be assigned to the same
   stream.  To accomplish this, MTP3-User traffic may be assigned to
   individual streams based on, for example, the SLS value in the MTP3
   Routing Label or the ISUP CIC assignment, subject of course to the
   maximum number of streams supported by the underlying SCTP
   association.

   ---------
   New text: (Section 1.4.7)
   ---------

   The M3UA layer at both the SGP and ASP also supports the assignment
   of signalling traffic into streams within an SCTP association.
   Traffic that requires sequencing SHOULD be assigned to the same
   stream.  To accomplish this, MTP3-User traffic may be assigned to
   individual streams based on, for example, the SLS value in the MTP3
   Routing Label, subject of course to the maximum number of streams
   supported by the underlying SCTP association.



   ---------
   Old text: (Section 1.5.3)
   ---------

   For internal SGP modeling purposes, this may be accomplished with the
   use of an implementation-dependent nodal interworking function within
   the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
   request/indication messages to/from both the MTP3 and the M3UA layer,
   based on the SS7 DPC or DPC/SSN address information.  This nodal
   interworking function has no visible peer protocol with either the
   ASP or SEP.




Pastor, Morneault                                              [Page 39]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   ---------
   New text: (Section 1.5.3)
   ---------

   For internal SGP modeling purposes, this may be accomplished with the
   use of an implementation-dependent nodal interworking function within
   the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
   request/indication messages to/from both the MTP3 and the M3UA layer,
   based on the SS7 DPC or DPC/SI address information.  This nodal
   interworking function has no visible peer protocol with either the
   ASP or SEP.



   ---------
   Old text: (Section 3.2)
   ---------

            Congestion Indications                0x0205
            Concerned Destination                 0x0206
            Routing Key                           0x0207
            Registration Result                   0x0208
            Deregistration Result                 0x0209
            Local_Routing Key Identifier          0x020a
            Destination Point Code                0x020b
            Service Indicators                    0x020c
            Reserved                              0x020d
            Originating Point Code List           0x020e
            Circuit Range                         0x020f
            Protocol Data                         0x0210
            Reserved                              0x0211
            Registration Status                   0x0212
            Deregistration Status                 0x0213

   ---------
   New text: (Section 3.2)
   ---------

            Congestion Indications                0x0205
            Concerned Destination                 0x0206
            Routing Key                           0x0207
            Registration Result                   0x0208
            Deregistration Result                 0x0209
            Local_Routing Key Identifier          0x020a
            Destination Point Code                0x020b
            Service Indicators                    0x020c
            Reserved                              0x020d
            Originating Point Code List           0x020e
            Reserved                              0x020f        Protocol
   Data                         0x0210
            Reserved                              0x0211



Pastor, Morneault                                              [Page 40]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


            Registration Status                   0x0212
            Deregistration Status                 0x0213



   ---------
   Old text: (Section 3.6.1)
   ---------
      |                  Traffic Mode Type (optional)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Point Code                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Network Appearance (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Service Indicators (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Originating Point Code List (optional)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Circuit Range List (optional)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                              ...                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Point Code                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Service Indicators (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Originating Point Code List (optional)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Circuit Range List (optional)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Note: The Destination Point Code, Service Indicators, Originating
      Point Code List and Circuit Range List parameters MAY be repeated
      as a grouping within the Routing Key parameter, in the structure
      shown above.

   ---------
   New text: (Section 3.6.1)
   ---------

      |                  Traffic Mode Type (optional)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Point Code                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Network Appearance (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Service Indicators (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Originating Point Code List (optional)           |



Pastor, Morneault                                              [Page 41]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                              ...                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Point Code                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Service Indicators (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Originating Point Code List (optional)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Note: The Destination Point Code, Service Indicators, and
      Originating Point Code List parameters MAY be repeated as a
      grouping within the Routing Key parameter, in the structure shown
      above.

   ---------
   Old text: (Section 3.6.1)
   ---------

   Circuit Range:

      An ISUP controlled circuit is uniquely identified by the SS7 OPC,
      DPC and CIC value.  For the purposes of identifying Circuit Ranges
      in an M3UA Routing Key, the optional Circuit Range parameter
      includes one or more circuit ranges, each identified by an OPC and
      Upper/Lower CIC value.  The DPC is implicit as it is mandatory and
      already included in the DPC parameter of the Routing Key.  The
      absence of the Circuit Range parameter in the Routing Key
      indicates the use of any Circuit Range values, in the case of
      ISUP/TUP traffic.  The Origination Point Code is encoded the same
      as the Destination Point Code parameter, while the CIC values are
      16-bit integers.

   ---------
   New text: (Section 3.6.1)
   ---------

   (none)


   ---------
   Old text: (Section 3.6.1)
   ---------

   The Circuit Range format 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Pastor, Morneault                                              [Page 42]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


      |           Tag = 0x020f        |              Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mask = 0   |          Origination Point Code #1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Lower CIC Value #1      |      Upper CIC Value #1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mask = 0   |          Origination Point Code #2            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Lower CIC Value #2      |      Upper CIC Value #2       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                              ...                              /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mask = 0   |          Origination Point Code #n            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Lower CIC Value #n      |      Upper CIC Value #n       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ---------
   New text: (Section 3.6.1)
   ---------

   (none)



   ---------
   Old text: (Section 3.7.1)
   ---------


      An Application Server Process may be configured to process traffic
      for more than one logical Application Server.  From the
      perspective of an ASP, a Routing Context defines a range of
      signalling traffic that the ASP is currently configured to receive
      from the SGP.  For example, an ASP could be configured to support
      call processing for multiple ranges of PSTN trunks and therefore
      receive related signalling traffic, identified by separate SS7
      DPC/OPC/CIC ranges.

   ---------
   New text: (Section 3.7.1)
   ---------

      An Application Server Process may be configured to process traffic
      for more than one logical Application Server.  From the
      perspective of an ASP, a Routing Context defines a range of
      signalling traffic that the ASP is currently configured to receive
      from the SGP.  For example, an ASP could be configured to support
      call processing for multiple ranges of PSTN trunks and therefore
      receive related signalling traffic, identified by separate SS7
      DPC/OPC/SI ranges.



Pastor, Morneault                                              [Page 43]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003





   ---------
   Old text: (Section 4.4.1)
   ---------

   If an SGP determines that one or more of the Routing Key parameters
   are not supported for the purpose of creating new Routing Key
   entries, the SGP returns a Registration Response message to the ASP,
   containing a Registration Result "Error - Unsupported RK parameter
   field".  This result MAY be used if, for example, the SGP does not
   support RK Circuit Range Lists in a Routing Key because the SGP does
   not support ISUP traffic, or does not provide CIC range granularity.

   ---------
   New text: (Section 4.4.1)
   ---------

   If an SGP determines that one or more of the Routing Key parameters
   are not supported for the purpose of creating new Routing Key
   entries, the SGP returns a Registration Response message to the ASP,
   containing a Registration Result "Error - Unsupported RK parameter
   field".


   ---------
   Old text: (Section A.2.1)
   ---------

   For example, where Application Servers are defined using ranges of
   ISUP CIC values, the Operator is implicitly splitting up control of
   the related circuit groups.  Some CIC value range assignments may
   interfere with ISUP circuit group management procedures.

   ---------
   New text: (Section A.2.1)
   ---------

   (none)




3.19.3 Solution Description

   The removal of reference to SSN and CIC used in Routing Keys as well
   as removal of Circuit Range from the Routing Key parameter removes
   the unclear text from the specification.





Pastor, Morneault                                              [Page 44]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity

3.20.1 Description of the problem

   There is not explicit text explaining how the protocol should work
   for the case when an ASP comes to ASP-ACTIVE state and there exist
   some problems in the SS7 network that prevent it to have full
   connectivity.


3.20.2 Text changes to the document




   ---------
   Old text: (Section 4.5.1)
   ---------


   The SGP M3UA layer determines the set of concerned ASPs to be
   informed based on the specific SS7 network for which the primitive
   indication is relevant. In this way, all ASPs configured to
   send/receive traffic within a particular network appearance are
   informed.  If the SGP operates within a single SS7 network
   appearance, then all ASPs are informed.

   DUNA, DAVA, SCON, and DRST messages may be sent sequentially and
   processed at the receiver in the order sent.


   ---------
   New text: (Section 4.5.1)
   ---------


   The SGP M3UA layer determines the set of concerned ASPs to be
   informed based on the specific SS7 network for which the primitive
   indication is relevant. In this way, all ASPs configured to
   send/receive traffic within a particular network appearance are
   informed.  If the SGP operates within a single SS7 network
   appearance, then all ASPs are informed.

   For the particular case that an ASP becomes active for an AS and
   destinations normally accessible to the AS are inaccessible,
   restricted or congested, the SG MAY send DUNA, DRST or SCON messages
   for the inaccessible, restricted or congested destinations to the ASP
   newly active for the AS to prevent the ASP from sending traffic for
   destinations that it might otherwise not know that are inaccessible,
   restricted or congested.




Pastor, Morneault                                              [Page 45]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   DUNA, DAVA, SCON, and DRST messages may be sent sequentially and
   processed at the receiver in the order sent.





   ---------
   Old text: (Section 4.6)
   ---------

   The ASP MAY choose to audit the availability of unavailable
   destinations by sending DAUD messages.  This would be for example the
   case when an AS becomes active at an ASP and does not have current
   destination statuses.  If MTP restart is in progress at the SG, the
   SGP returns a DUNA message for that destination, even if it received
   an indication that the destination became available or restricted.

   In the IPSP case, MTP restart could be considered if the IPSP also
   has connection to an SS7 network. [...]



   ---------
   New text: (Section 4.6)
   ---------

   The ASP MAY choose to audit the availability of unavailable
   destinations by sending DAUD messages.  This would be for example the
   case when an AS becomes active at an ASP and does not have current
   destination statuses.  If MTP restart is in progress at the SG, the
   SGP returns a DUNA message for that destination, even if it received
   an indication that the destination became available or restricted.

   When an ASP becomes active for an AS and the SG is experiencing SS7
   network isolation or is performing the MTP Restart procedure for the
   AS, the SG SHOULD send a DUNA(*) to the newly active ASP to prevent
   the ASP from sending traffic.

   In the IPSP case, MTP restart could be considered if the IPSP also
   has connection to an SS7 network. [...]

3.20.3 Solution Description

   By specifying how send SSNM messages in that scenario the problem is
   solved.



3.21 NOTIFY messages are missing in Examples section




Pastor, Morneault                                              [Page 46]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


3.21.1 Description of the problem

   There are some mandatory NOTIFY messages missing in section 5 in the
   RFC.


3.21.2 Text changes to the document


   ---------
   Old text: (Section 5)
   ---------

   NOTE: Not all the Notify messages that are appropriate per the Notify
   procedures are shown in these examples.


   ---------
   New text: (Section 5)
   ---------

   -


   ---------
   Old text: (Section 5.1.1.1)
   ---------

                 SGP                             ASP1
                  |                               |
                  |<-------------ASP Up-----------|
                  |-----------ASP Up Ack--------->|
                  |                               |
                  |<------- ASP Active(RCn)-------|  RC: Routing Context
                  |-----ASP Active Ack (RCn)----->|      (optional)
                  |                               |
                  |-----NTFY(AS-ACTIVE)(RCn)----->|
                  |                               |


   ---------
   New text: (Section 5.1.1.1)
   ---------


                 SGP                             ASP1
                  |                               |
                  |<-------------ASP Up-----------|
                  |-----------ASP Up Ack--------->|
                  |                               |
                  |-----NTFY(AS-INACTIVE)(RCn)--->|



Pastor, Morneault                                              [Page 47]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


                  |                               |
                  |<------- ASP Active(RCn)-------|  RC: Routing Context
                  |-----ASP Active Ack (RCn)----->|      (optional)
                  |                               |
                  |-----NTFY(AS-ACTIVE)(RCn)----->|
                  |                               |


   ---------
   Old text: (Section 5.1.1.2)
   ---------


                SGP                             ASP1
                 |                               |
                 |<------------ASP Up------------|
                 |----------ASP Up Ack---------->|
                 |                               |
                 |<----REGISTER REQ(LRCn,RKn)----|  LRC: Local Routing
                 |                               |       Context
                 |----REGISTER RESP(LRCn,RCn)--->|   RK: Routing Key
                 |                               |   RC: Routing Context
                 |                               |
                 |<------- ASP Active(RCn)-------|
                 |-----ASP Active Ack (RCn)----->|
                 |                               |
                 |-----NTFY(AS-ACTIVE)(RCn)----->|
                 |                               |


   ---------
   New text: (Section 5.1.1.2)
   ---------

                SGP                             ASP1
                 |                               |
                 |<------------ASP Up------------|
                 |----------ASP Up Ack---------->|
                 |                               |
                 |                               |
                 |<----REGISTER REQ(LRCn,RKn)----|  LRC: Local Routing
                 |                               |       Key Id
                 |----REGISTER RESP(LRCn,RCn)--->|   RK: Routing Key
                 |                               |   RC: Routing Context
                 |----NTFY(AS-INACTIVE)(RCn)---->|
                 |                               |
                 |                               |
                 |<------- ASP Active(RCn)-------|
                 |-----ASP Active Ack (RCn)----->|
                 |                               |
                 |-----NTFY(AS-ACTIVE)(RCn)----->|



Pastor, Morneault                                              [Page 48]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


                 |                               |



   ---------
   Old text: (Section 5.1.1.3)
   ---------



                SGP                             ASP1
                 |                               |
                 |<------------ASP Up------------|
                 |----------ASP Up Ack---------->|
                 |                               |
                 |<----REGISTER REQ(LRC1,RK1)----|  LRC: Local Routing
                 |                               |       Context
                 |----REGISTER RESP(LRC1,RC1)--->|   RK: Routing Key
                 |                               |   RC: Routing Context
                 |                               |
                 |<------- ASP Active(RC1)-------|
                 |-----ASP Active Ack (RC1)----->|
                 |                               |
                 |                               |
                 |<----REGISTER REQ(LRCn,RKn)----|
                 |                               |
                 |----REGISTER RESP(LRCn,RCn)--->|
                 |                               |
                 |                               |
                 |<------- ASP Active(RCn)-------|
                 |-----ASP Active Ack (RCn)----->|
                 |                               |


   ---------
   New text: (Section 5.1.1.3)
   ---------



                SGP                             ASP1
                 |                               |
                 |<------------ASP Up------------|
                 |----------ASP Up Ack---------->|
                 |                               |
                 |<----REGISTER REQ(LRC1,RK1)----|  LRC: Local Routing
                 |                               |       Key Id
                 |----REGISTER RESP(LRC1,RC1)--->|   RK: Routing Key
                 |                               |   RC: Routing Context
                 |---NOTIFY(AS-INACTIVE)(RC1)--->|
                 |                               |



Pastor, Morneault                                              [Page 49]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


                 |                               |
                 |<------- ASP Active(RC1)-------|
                 |-----ASP Active Ack (RC1)----->|
                 |                               |
                 |----NOTIFY(AS-ACTIVE)(RC1)---->|
                 |                               |
                 ~                               ~
                 |                               |
                 |<----REGISTER REQ(LRCn,RKn)----|
                 |                               |
                 |----REGISTER RESP(LRCn,RCn)--->|
                 |                               |
                 |                               |
                 |<------- ASP Active(RCn)-------|
                 |-----ASP Active Ack (RCn)----->|
                 |                               |
                 |----NOTIFY(AS-ACTIVE)(RCn)---->|
                 |                               |


   ---------
   Old text: (Section 5.1.1.4)
   ---------



                  SGP                             ASP1
                   |                               |
                   |<------------ASP Up------------|
                   |----------ASP Up Ack---------->|
                   |                               |
                   |<---REGISTER REQ({LRC1,RK1},---|
                   |                   ...,        |
                   |                 {LRCn,RKn}),--|
                   |                               |
                   |---REGISTER RESP({LRC1,RC1},-->|
                   |                  ...,         |
                   |                 (LRCn,RCn})   |
                   |                               |
                   |<------- ASP Active(RC1)-------|
                   |-----ASP Active Ack (RC1)----->|
                   |                               |
                   :                               :
                   :                               :
                   |                               |
                   |<------- ASP Active(RCn)-------|
                   |-----ASP Active Ack (RCn)----->|
                   |                               |

   ---------
   New text: (Section 5.1.1.4)



Pastor, Morneault                                              [Page 50]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


   ---------


                  SGP                             ASP1
                   |                               |
                   |<------------ASP Up------------|
                   |----------ASP Up Ack---------->|
                   |                               |
                   |                               |
                   |<---REGISTER REQ({LRC1,RK1},   |
                   |                   ...,        |
                   |                 {LRCn,RKn}),--|
                   |                               |
                   |---REGISTER RESP({LRC1,RC1},-->|
                   |                  ...,         |
                   |                 (LRCn,RCn})   |
                   |                               |
                   |--NTFY(AS-INACTIVE)(RC1..RCn)->|
                   |                               |
                   |                               |
                   |<------- ASP Active(RC1)-------|
                   |-----ASP Active Ack (RC1)----->|
                   |                               |
                   |----NOTIFY(AS-ACTIVE)(RC1)---->|
                   |                               |
                   :                               :
                   :                               :
                   |                               |
                   |<------- ASP Active(RCn)-------|
                   |-----ASP Active Ack (RCn)----->|
                   |                               |
                   |----NOTIFY(AS-ACTIVE)(RCn)---->|
                   |                               |







   ---------
   Old text: (Section 5.1.2)
   ---------

         SGP                      ASP1                       ASP2
          |                        |                          |
          |<--------ASP Up---------|                          |
          |-------ASP Up Ack------>|                          |
          |                        |                          |
          |<----------------------------ASP Up----------------|
          |----------------------------ASP Up Ack------------>|



Pastor, Morneault                                              [Page 51]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


          |                        |                          |
          |                        |                          |
          |<-------ASP Active------|                          |
          |------ASP Active Ack--->|                          |
          |                        |                          |

   ---------
   New text: (Section 5.1.2)
   ---------


         SGP                      ASP1                       ASP2
          |                        |                          |
          |<--------ASP Up---------|                          |
          |-------ASP Up Ack------>|                          |
          |                        |                          |
          |--NOTIFY(AS-INACTIVE)-->|                          |
          |                        |                          |
          |<----------------------------ASP Up----------------|
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |                        |                          |
          |<-------ASP Active------|                          |
          |------ASP Active Ack--->|                          |
          |                        |                          |
          |---NOTIFY(AS-ACTIVE)--->|                          |
          |--------------------------NOTIFY(AS-ACTIVE)------->|
          |                        |                          |






   ---------
   Old text: (Section 5.1.3)
   ---------

        OLD:
         SGP                      ASP1                       ASP2
          |                        |                          |
          |<---------ASP Up--------|                          |
          |--------ASP Up Ack----->|                          |
          |                        |                          |
          |<-----------------------------ASP Up---------------|
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |                        |                          |
          |<--ASP Active (Ldshr)---|                          |
          |-----ASP-Active Ack---->|                          |
          |                        |                          |



Pastor, Morneault                                              [Page 52]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


          |---------------------------NOTIFY (AS-ACTIVE------>|
          |                        |                          |
          |<---------------------------ASP Active (Ldshr)-----|
          |------------------------------ASP Active Ack------>|
          |                        |                          |


   ---------
   New text: (Section 5.1.3)
   ---------



         SGP                      ASP1                       ASP2
          |                        |                          |
          |<---------ASP Up--------|                          |
          |--------ASP Up Ack----->|                          |
          |                        |                          |
          |--NOTIFY(AS-INACTIVE)-->|                          |
          |                        |                          |
          |<-----------------------------ASP Up---------------|
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |<--ASP Active (Ldshr)---|                          |
          |-----ASP-Active Ack---->|                          |
          |                        |                          |
          |---NOTIFY (AS-ACTIVE)-->|                          |
          |-----------------------------NOTIFY(AS-ACTIVE)---->|
          |                        |                          |
          |<---------------------------ASP Active (Ldshr)-----|
          |------------------------------ASP Active Ack------>|
          |                        |                          |


   ---------
   Old text: (Section 5.1.4)
   ---------


        SGP                 ASP1                ASP2                ASP3
          |                   |                   |                   |
          |<------ASP Up------|                   |                   |
          |-----ASP Up Ack--->|                   |                   |
          |                   |                   |                   |
          |<-------------------------ASP Up-------|                   |
          |------------------------ASP Up Ack---->|                   |
          |                   |                   |                   |
          |<--------------------------------------------ASP Up--------|
          |--------------------------------------------ASP Up Ack---->|
          |                   |                   |                   |
          |                   |                   |                   |



Pastor, Morneault                                              [Page 53]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


          |<--ASP Act (Ldshr)-|                   |                   |
          |----ASP Act Ack--->|                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |<-------------------ASP Act. (Ldshr)---|                   |
          |----------------------ASP Act Ack----->|                   |
          |                   |                   |                   |
          |---------Notify (AS-ACTIVE)----------->|                   |
          |----------------------Notify (AS-ACTIVE)------------------>|


   ---------
   New text: (Section 5.1.4)
   ---------



        SGP                 ASP1                ASP2                ASP3
          |                   |                   |                   |
          |<------ASP Up------|                   |                   |
          |-----ASP Up Ack--->|                   |                   |
          |                   |                   |                   |
          |<-------------------------ASP Up-------|                   |
          |------------------------ASP Up Ack---->|                   |
          |                   |                   |                   |
          |NTFY(AS-INACTIVE)->|                   |                   |
          |------------------NOTIFY(AS-INACTIVE)->|                   |
          |                   |                   |                   |
          |<--------------------------------------------ASP Up--------|
          |--------------------------------------------ASP Up Ack---->|
          |                   |                   |                   |
          |                   |                   |                   |
          |<--ASP Act (Ldshr)-|                   |                   |
          |----ASP Act Ack--->|                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |<-------------------ASP Act. (Ldshr)---|                   |
          |----------------------ASP Act Ack----->|                   |
          |                   |                   |                   |
          |--NTFY(AS-ACTIVE)->|                   |                   |
          |--------------------NOTIFY(AS-ACTIVE)->|                   |
          |----------------------------------------NOTIFY(AS-ACTIVE)->|
          |                   |                   |                   |
          |                   |                   |                   |

   ---------
   Old text: (Section 5.2.3)
   ---------


        SGP                 ASP1                ASP2                ASP3



Pastor, Morneault                                              [Page 54]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


          |                   |                   |                   |
          |<----ASP Inact.----|                   |                   |
          |---ASP Inact Ack-->|                   |                   |
          |                   |                   |                   |
          |--------------------------------NTFY(Ins. ASPs)----------->|
          |                   |                   |                   |
          |<----------------------------------------ASP Act (Ldshr)---|
          |------------------------------------------ASP Act (Ack)--->|
          |                   |                   |                   |


   ---------
   New text: (Section 5.2.3)
   ---------


        SGP                 ASP1                ASP2                ASP3
          |                   |                   |                   |
          |<----ASP Inact.----|                   |                   |
          |---ASP Inact Ack-->|                   |                   |
          |                   |                   |                   |
          |-NTFY(AS-PENDING)->|                   |                   |
          |-------------------NOTIFY(AS-PENDING)->|                   |
          |---------------------------------------NOTIFY(AS-PENDING)->|
          |---------------------------------------NOTIFY(Ins. ASPs)-->|
          |                   |                   |                   |
          |                   |                   |                   |
          |<----------------------------------------ASP Act (Ldshr)---|
          |------------------------------------------ASP Act (Ack)--->|
          |                   |                   |                   |
          |-NTFY(AS-ACTIVE)-->|                   |                   |
          |-------------------NOTIFY(AS-ACTIVE)-->|                   |
          |---------------------------------------NOTIFY(AS-ACTIVE)-->|
          |                   |                   |                   |
          |                   |                   |                   |







3.21.3 Solution Description

   By specifying all the mandatory NOTIFY messages in the drawing, we
   solve the problem.








Pastor, Morneault                                              [Page 55]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


4. Acknowledgements

   The authors would like to thank Lyndon Ong, Tolga Asveren, Brian
   Bidulock, Umesh Vats, Barry Nagelberg, Samuel Dur D. Jeyaseelan,
   Antonio Canete and many others for their valuable comments and
   suggestions.

5. Authors' Addresses

   Javier Pastor-Balbas
   Ericsson Espana S.A.
   Via de los Poblados 13
   28033 Madrid
   Spain

   Phone: +34-91-339-1397
   Email: j.javier.pastor@ericsson.com


   Ken Morneault
   Cisco Systems Inc.
   13615 Dulles Technology Drive
   Herndon, VA. 20171
   USA

   Phone: +1-703-484-3323
   EMail: kmorneau@cisco.com




6. References

   [RFC3332] "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
              User Adaptation Layer (M3UA)". G. Sidebotton, K.
              Morneault, J. Pastor-Balbas.


7. Changes Control

7.1 Changes from v00 to v01

      - Typos.

      - Update all the RC references to show it is a semi-optional
         parameter.

      - DUNA(*) substituted for ASPIA-ACK when NIF is not available.

      - New sections added:
         - IPSP stuff



Pastor, Morneault                                              [Page 56]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


         - Messages and Streams
         - ASP Id for IPSP communication
         - n+k redundancy

7.2 Changes from v01 to v02

      - ASPIA-ACK substituted for DUNA when NIF is not available since
         it also allows inter-ASP routing.
      - Changed REGREQ's parameter from "Origination Point Code" to
         "Destination Point Code".

7.3 Changes from v02 to v03

   - Changed from "semi-optional" to "conditional"- Section 3.7 reworded

   - Updated Section 3.8 to correctly explain how the alias point code
     configuration can be supported with dynamically registered Routing
     Keys

   - Changes in "messages and streams" section

   - IPSP DE model is allowed. But IPSP SE MUST be supported.

   - New sections added:
     - Multiple Parameters of the Same Type in a Message
     - Registration Routing Key State After Unexpected ASP Up Message
     - Location of Network Appearance
     - Determination of Congestion Abatement When ASP Sends SCON
     - Removing CIC and SSN from RK
     - ASP comes to ASP-ACTIVE state without full SS7 connectivity



7.4 Changes from v03 to v04

   - Removed NIF section and left it as implementation dependant. There
     is now plenty of discussion in the email archive to make an
     informed decision on how to handle NIF isolation.

   - Section 3.15 updated (now it is section 3.14)

   - Current section 3.19 about removing CIC and SSN from the RK:
     "Reserved 0x020f" Parameter Tag Code has been added (that was the
     CIC Code)

   - New Section to fix lack of NOTIFY messages in Examples section. It
     is section 3.21.







Pastor, Morneault                                              [Page 57]


INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE              June, 2003


Full 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 procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions 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
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Acknowledgment

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






















Pastor, Morneault                                              [Page 58]


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