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

                                                             October, 2002

                                                                           February, 2003

                                          M3UA Implementor's Guide
            <draft-ietf-sigtran-m3ua-implementors-guide-02.txt>
                            <draft-ietf-sigtran-m3ua-implementors-guide-03.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
                    October 2002 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 RFC3332 and text
                    within this document supersedes the text found in RFC3332.

                 TABLE OF CONTENTS

 1.Introduction........................................................3
 2.Conventions.........................................................3
 3.Corrections

                 1.  Introduction.......................................................3
                 1.1  Abbreviations.....................................................3
                 2.  Conventions........................................................3
                 3.  Corrections to RFC-M3UA.............................................3 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 NIF Not Available on SGP...........................................7
                 3.5 Scope of Network Appearance........................................8
                 3.6 Semi-optional Conditional RC parameter.........................................9 parameter...........................................9
                 3.7 Receiving REG for a RK already registered.........................12
                 3.8 OPC list in the Dynamic Registration Request Message......................13 Support for Alias Point Code.................15
                 3.9 Auditing procedure and congestion state...........................14 state...........................16
                 3.10 Response to an ASPIA message.....................................16 message.....................................18
                 3.11 INFO and DIAG parameter length...................................18 length...................................20
                 3.12 IPSP stuff.......................................................19 stuff.......................................................21
                 3.13 Messages and Streams.............................................24 Streams.............................................28
                 3.14 ASP Id for IPSP communication....................................25 communication....................................28
                 3.15 n+k redundancy...................................................26
 4.Acknowledgements...................................................31
 5.Authors' Addresses.................................................31
 6.References.........................................................31
 7.Changes Control....................................................33 redundancy...................................................30
                 3.16 Multiple Parameters of the Same Type in a Message................34
                 3.17 Registered Routing Key State After Unexpected ASP Up Message.....34
                 3.18 Location of Network Appearance...................................35
                 3.19 Determination of Congestion Abatement When ASP Sends SCON........37
                 3.20 Removing CIC and SSN from RK.....................................37
                 3.21 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45
                 4.  Acknowledgements..................................................47
                 5.  Authors' Addresses................................................47
                 6.  References........................................................47
                 7.  Changes Control...................................................47
                 7.1 Changes from v00 to v01...........................................47
                 7.2 Changes from v01 to v02...........................................48
                 7.3 Changes from v02 to v03...........................................48
                 1. Introduction

                    This document contains a compilation of all defects found up until
                    March 2002 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 RFC-M3UA 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
                    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)
                    ---------

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

                    The Error message contains the following parameters:
                    Error Code                 Mandatory
                    Routing Context            Mandatory*
                    Network Appearance         Mandatory*
                    Affected Point Code        Mandatory*
                    Diagnostic Information     Semi-Optional     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)

                         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]. [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 to was required for the different SS7 message label types was
    required.
                    types.

                 3.4 NIF Not Available on SGP

                 3.4.1 Description of the problem

                    The text is not clear about how the SGP/SG should handle the case of
                    the NIF becoming unavailable on a SGP or all SGPs (SG).

                 3.4.2 Text changes to the document

                    ---------
                    Old text: (None)
                    ---------

                    None.

                    ---------
                    New text: (Section 4.7)
                    ---------

                    If the SG (all the SGPs) is isolated from the NIF, then all the users
                    are isolated from the SS7 network.  A DUNA(*) message MUST be sent
                    from the SGPs to all the ASPs.

                    If only one SGP in the SG is isolated entirely from the NIF, the SGP
                    SHOULD abort its associations. An alternative would be for the SGP to
                    send ASP Down Ack.

                    If one or more SGP suffer a partial failure (where aborting the
                    association(s) would cause all active AS(es) to fail), then the SGP
                    MUST send DUNA messages for the affected SPC(es).  This is the case
                    where an SGP can continue to service one or more active AS(es), but
                    due to a partial failure it is unable to service other(s) active
                    AS(es).

                 3.4.3 Solution description

                    The addition of this text specifies the SGP/SG behavoir behavior for the
                    different scenarios of the NIF becoming unavailable on the SGP/SG.

                 3.5 Scope of Network Appearance

                 3.5.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.5.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
                    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.

                 3.5.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.6 Semi-optional Conditional RC parameter

                 3.6.1 Description of the problem

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

                 3.6.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          Semi-Optional          Conditional
                         Protocol Data            Mandatory
                         Correlation Id           Optional

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

                         Routing Context          Optional

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

                         Routing Context          Semi-Optional          Conditional

                    ---------
                    Old text: (Section 3.4.2)
                    ---------
                         Routing Context          Optional

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

                         Routing Context          Semi-Optional          Conditional

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

                         Routing Context          Optional

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

                         Routing Context          Semi-Optional          Conditional

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

                         Routing Context          Optional

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

                         Routing Context          Semi-Optional          Conditional

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

                         Routing Context          Optional

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

                         Routing Context          Semi-Optional          Conditional

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

                         Routing Context          Optional

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

                         Routing Context          Semi-Optional          Conditional

                 3.6.3 Solution description

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

                 3.7 Receiving REG for a RK already registered

                 3.7.1 Description of the problem

                    The RFC does not clearly specify what to do in this case.

 3.7.2 Text changes to the document

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

    None.

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

    If the SG determines that the received RK was already registered, the
    SGP returns should do when it
                    receives a Registration Response message Request for a Routing Key that has already
                    been registered. There are two scenarios to consider: the ASP, containing
                    registration request is a
    Registration Result "Error - Cannot Support Unique Routing".

 3.7.3 Solution description

    By specifying the error code, duplicate or the general problem of re-registering registration request
                    indicates a
    RK is solved. This error response applies whether desire to modify the Routing Key is
    Active or Inactive.

 3.8 OPC list in the Registration Request Message

 3.8.1 Description of the problem

    It is not clear the reason of having an OPC list in the Registration
    Request message. What is it valid for?

 3.8.2

                 3.7.2 Text changes to the document

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

    OPC List:

                    The Originating Point Code List parameter contains one or more SS7
    OPC entries, and its format is the same as the Destination Point Code
    parameter.  The absence of the OPC List parameter in the Routing Key
    indicates the use of any OPC value, 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
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |          Tag = 0x020e         |             Length                       Local-RK-Identifier                     |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Mask = 0                  Traffic Mode Type (optional)                 |          Origination
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                     Destination Point Code #1                    |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Mask = 0                  Network Appearance (optional)                |          Origination
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                  Service Indicators (optional)                |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |              Originating Point Code #2 List (optional)           |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                   Circuit Range List (optional)               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      \                                                               \
                      /                              ...                              /
                      \                                                               \
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Mask = 0                     Destination Point Code                    |          Origination
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                  Service Indicators (optional)                |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |              Originating Point Code #n List (optional)           |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                   Circuit Range List (optional)               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

    DPC List:

                    The Destination Point Code List parameter contains one or more SS7
    DPC entries, and its format is the same as the Destination Point Code
    parameter. Multiple DPC values will only be valid in the case of
    Alias Point Code configuration. The absence of the DPC List parameter
    in the Routing Key indicates the use of the DPC value parameter is as the only
    posible DPC for the 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 = 0x020e                       Local-RK-Identifier                     |             Length
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                   Routing Context (optional)                  |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Mask = 0                  Traffic Mode Type (optional)                 |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                     Destination Point Code #1                    |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Mask = 0                  Network Appearance (optional)                |          Destination
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                  Service Indicators (optional)                |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |              Originating Point Code #2 List (optional)           |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                   Circuit Range List (optional)               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      \                                                               \
                      /                              ...                              /
                      \                                                               \
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Mask = 0   |                     Destination Point Code #n                    |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 3.8.3 Solution description

    Including the scenario where this parameter is used (Alias point code
    configurations), the problem is solved.
                      |                  Service Indicators (optional)                |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |              Originating Point Code List (optional)           |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                   Circuit Range List (optional)               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                    Registration Status: 32-bit integer

                      The parameter name has also
    be changed to "Destination" since it is the way that Registration Result Status field indicates the SG sees it.

 3.9 Auditing procedure and congestion state

 3.9.1 Description of success or the problem

    The current description
                      reason for failure of the AUDIT procedure in regards to
    congestion state is not clear enough. When to send SCON is 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
    completely specified.

 3.9.2 Text changes to the document Currently Provisioned
                         8           Error - Insufficient Resources
                         9           Error - Unsupported RK parameter Field
                         10          Error - Unsupported/Invalid Traffic Handling Mode

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

    [...]. Where

                    Registration Status: 32-bit integer

                      The Registration Result Status field indicates the SGP maintains success or the congestion status
                      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
                         11          Error - Routing Key Change Refused

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

                    None.

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

                    If the SS7
    destination, and SGP determines that the SS7 destination is congested, received RK was already registered,
                    the SGP MUST
    additionally respond with an SCON returns a Registration Response message before to the DAVA or DRST
    message.  If ASP,
                    containing a Registration Result "Error - Cannot Support Unique
                    Routing". This error applies whether the SS7 destination Routing Key is available and congested, the SGP
    MUST respond with Active or
                    Inactive.

                    An ASP MAY modify an SCON message and then existing Routing Key by including a DAVA message.  If Routing
                    Context parameter in the
    SS7 destination is restricted and congested, REG REQ.  If the SGP MUST respond
    with an SCON message immediately followed by a DRST message.  If determines that the
    SGP has no information on
                    Routing Context applies to an existing Routing Key, the availability status of SG MAY adjust
                    the SS7
    destination, existing Routing Key to match the SGP responds with a DUNA message, as it has no
    routing new information to allow it to route traffic to this destination.

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

    [...]. Where provided in the
                    Routing Key parameter.  A Registration Response "ERR - Routing Key
                    Change Refused" is returned if the SGP maintains does not accept the congestion status
                    modification of the SS7
    destination, the SGP MUST additionally respond with an SCON message
    before Routing Key due to either it does not support the DAVA
                    re-registration procedure or DRST message. the specific RC does not exist.

                    If the SS7 destination change is
    available, the SGP MUST respond with an SCON message (indicating the
    appropriate congestion level) and then accepted, a DAVA message.  If the SS7
    destination Registration Response "Successfully
                    Registered" is restricted, returned.

                 3.7.3 Solution description

                    By specifying the SGP MUST respond with an SCON message
    (with error code and this new text, the appropriate congestion level) immediately followed by cases of
                    receiving a
    DRST message.  If duplicate registration request or modification to a
                    Routing Key are resolved.

                 3.8 Dynamic Registration Support for Alias Point Code

                 3.8.1 Description of the SGP has problem

                    There is no information on text regarding the availability
    status support of an Alias Point Code
                    configuration in the SS7 destination, the SGP responds with a DUNA message,
    as it has no routing information to allow it to route traffic dynamic registration of Routing Keys.

                 3.8.2 Text changes to this
    destination.

    Where the SGP does not maintain document

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

                       Destination Point Code:

                          The Destination Point Code parameter is mandatory, and
                          Identifies the congestion status Destination Point Code of the incoming SS7
    destination, traffic
                          for which the ASP is registering.  The format is the same as
                          described for the Affected Destination parameter in 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 (See Section 3.4.1).  Its format is:

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

    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

                       Destination Point Code:

                          The Destination Point Code parameter is mandatory, and
                          Identifies the Destination Point Code of incoming SS7 traffic
                          for which the ASP                          SGP
           ---                          ---
            |  -------- DAUD --------->  |
            |  <------- 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 ----------  |

    5.5 M3UA/MTP3-User Boundary Examples

 3.9.3 message (See Section
                          3.4.1).  Its format is:

                 3.8.3 Solution description

    Whenever a DAUD is received, it has

                    The solution was to add some text to describe how an alias point code
                    configuration could be responded supported with
    DAVA/DUNA/DRST message depending on dynamic registration.

                 3.9 Auditing procedure and congestion state

                 3.9.1 Description of the peer node's state. If problem

                    The current description of the SGP
    has AUDIT procedure in regards to
                    congestion control (i.e. no ITU international networks) an SCON
    message with the appropiate congestion level should precede to the
    DAVA/DRST messages upon a DAUD arrival.

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

 3.10 Response to an ASPIA message

 3.10.1 Description of the problem

    It was state is not clear how enough. When 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.10.2 send SCON is not
                    completely specified.

                 3.9.2 Text changes to the document

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

    When an ASP wishes to withdraw from receiving traffic within an AS,
    the ASP sends an ASP Inactive message to

                    [...]. Where 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 maintains the case where an ASP is processing congestion status of the traffic for more than one Application Server across a common SCTP
    association, SS7
                    destination, and the ASP Inactive message contains one or more Routing
    Contexts to indicate for which Application Servers SS7 destination is congested, the ASP Inactive
    message applies.

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

    When an ASP wishes to withdraw from receiving traffic within SGP MUST
                    additionally respond with an AS,or SCON message before the ASP wants to initiate DAVA or DRST
                    message.  If the process of activation, SS7 destination is available and congested, the ASP sends SGP
                    MUST respond with an
    ASP Inactive SCON message to and then a DAVA message.  If the SGP or IPSP.

    An ASP Inactive message MUST be always responded by the peer
    (although other messages may be sent in the middle):
       - If the corresponding RK
                    SS7 destination is registered (statically or
          dynamically), restricted and congested, the peer should SGP MUST respond
                    with an ASP Inactive Ack SCON message immediately followed by a DRST message.
       -  If the RK is not registered, or
                    SGP has no information on the RC availability status of the SS7
                    destination, the SGP responds with a DUNA message, as it has no
                    routing information is not valid, to allow it to route traffic to this destination.

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

                    [...]. Where the peer must SGP maintains the congestion status of the SS7
                    destination, the SGP MUST additionally respond with an ERROR SCON message with Error Code =
          "Invalid Routing Context".
       -
                    before the DAVA or DRST message.  If the RC is missing and its specification SS7 destination is needed according
          to the used configuration,
                    available, the peer must SGP MUST respond with an ERROR SCON message with Error Code = "No Configured AS for ASP".

    The action of sending (indicating the ASP Inactive message MAY be initiated at
                    appropriate congestion level) and then a DAVA message.  If the ASP by an M-ASP_INACTIVE request primitive from Layer Management
    or MAY be initiated automatically by an M3UA management function.  In SS7
                    destination is restricted, the case where SGP MUST respond with an ASP is processing SCON message
                    (with the traffic for more than one
    Application Server across appropriate congestion level) immediately followed by a common SCTP association,
                    DRST message.  If the ASP Inactive
    message contains one or more Routing Contexts to indicate for which
    Application Servers SGP has no information on the ASP Inactive message applies.

 3.10.3 Solution description
    A more detailed specification availability
                    status of the messages to be sent upon SS7 destination, the
    reception of an ASPIA SGP responds with a DUNA message,
                    as it has been added no routing information to the Inactive Procedures
    Section.

 3.11 INFO and DIAG parameter length

 3.11.1 Description of the problem

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

 3.11.2 Text changes allow it 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 route traffic to 255 octets. No procedures are presently
    identified for its use but this
                    destination.

                    Where the INFO String MAY be used for debugging
    purposes.

    ---------
    New 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 SGP does not maintain the message. Length congestion status of the INFO
    String parameter is from 0 to 255 octets. This means that No
    procedures are presently identified for its use but SS7
                    destination, the INFO String
    MAY response to a DAUD message should always be used for debugging purposes. An INFO String with only a zero length
    parameter is not considered
                    DAVA, DRST or DUNA message as an error (this means that the Length
    field in the TLV will be set to 4). appropriate.

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

    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.

                    5.4 M3UA/MTP3-User Boundary Examples

                    ---------
                    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. A Diagnostic Information 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.11.3 Solution description

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

 3.12 IPSP stuff

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

 3.12.2 Text changes to the document

    ---------
    Old text: (Section 4.3.1) 5.4, 5.5)
                    ---------

    Figure 4:

                    5.4 Auditing examples

                    5.4.1 SG State: Uncongested / Unavailable

                           ASP State Transition Diagram, per AS

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

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

                           ASP in AS  |       +--------------+
                |   Overrides                          SGP
                           ---                          ---
                            |           ^  -------- DAUD --------->  |
                            |  <------ SCON(2) --------  |    ASP
                            |  <------- DAVA ----------  |

                    5.4.3 SG state: Unknown / Available

                           ASP                          SGP
                           ---                          ---
                            |              |    Active |     | Inactive
                |              |           |     v
                |              |       +--------------+  -------- DAUD --------->  |
                            |  <------- DAVA ----------  |

                    5.4.4 SG state: Uncongested / Unavailable

                           ASP                          SGP
                           ---                          ---
                            |  -------- DAUD --------->  |              +------>| ASP-INACTIVE |
                |                      +--------------+
                |                          ^     |
      ASP Down/ |                     ASP
                            |  <------- DUNA ----------  |

                    5.5 M3UA/MTP3-User Boundary Examples

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

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

                 3.10 Response to an ASPIA message

                 3.10.1 Description of the problem

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

                           ASP Down /
      SCTP CDI/ |                     Up   |                          SGP
                           ---                          ---
                            | SCTP CDI/
      SCTP RI  ------ ASPIA (RC1)----->  |
                            |     v SCTP RI  <----  ASPIA Ack -------  |                      +--------------+
                            |  -----DEREG REQ (RC1)--->  |
                            |
                +--------------------->|   ASP-DOWN  <----DEREG RSP (RC1)----  |
                            |  -------ASPIA (RC1)----->  |
                                       +--------------+

                    What should SG do?

                 3.10.2 Text changes to the document

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

    The figure below shows

                    When an ASP wishes to withdraw from receiving traffic within an AS,
                    the transitions 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 and IPSP cases.

            Figure 5: IPSP State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |        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 communication
    while the rest are valid Inactive message contains one or more Routing
                    Contexts to indicate 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 which Application Servers the ASP state transition diagram. It
    would need four messages for completion. Inactive
                    message applies.

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

    None.

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

    Alternatively,

                    When an interchange of ASP Active messages wishes to withdraw from each end
    can be performed. This option follows receiving traffic within an AS,or
                    the ASP state transition
    diagram and gives wants to initiate the additional advantage process 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)
    ---------

    None.

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

    Alternatively, activation, the ASP sends an interchange of
                    ASP Inactive messages from each end
    can be performed. This option follows message to the SGP or IPSP.

                    An ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to Inactive message MUST be deactivated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four always responded by the peer
                    (although other messages for
    completion.

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

    None.

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

    The Registration/Deregistration procedures work may be sent in the IPSP cases in middle):
                       - If the same way as in AS-SG cases.  An IPSP may register an corresponding RK in the
    remote IPSP.  An IPSP is responsible for deregistering registered (statically or
                          dynamically), the RKs that
    it has registered.

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

    The Registration/Deregistration procedures work in peer should respond with an ASP Inactive Ack
                          message.
                       -
                          If the IPSP cases in RK is not registered, or the same way as in AS-SG cases.  An IPSP may register RC information is not valid,
                          the peer must respond with an RK in ERROR message with Error Code =
                          "Invalid Routing Context".
                       - If the
    remote IPSP.  An IPSP RC is responsible for deregistering missing and its specification is needed according
                          to the RKs that
    it has registered.

    It MAY be used one common RK for both IPSP participating in the
    communication using configuration, the Signaling Point peer must respond with an ERROR
                          message with Error Code granularity. It would
    basically consist = "No Configured AS for ASP".

                    The action of <OPC,DPC>.

    In sending the case of RC use, RCs SHOULD ASP Inactive message MAY be previously agreed between both
    peers.

    ---------
    Old text: (Section 5.5)
    ---------

    These scenarios show a basic example for IPSP communication for the
    three phases of initiated at
                    the connection (establishment, data exchange,
    disconnection). It is assumed that ASP by an M-ASP_INACTIVE request primitive from Layer Management
                    or MAY be initiated automatically by an M3UA management function.  In
                    the SCTP association case where an ASP is already
    set up. Both single exchange and double exchange behavior are
    included processing the traffic for illustrative purposes.

    5.5.1 Single exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- more than one
                    Application Server across a common SCTP association, the ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|        (optional)
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |
                    message contains one or more Routing Context are previously agreed Contexts to be indicate for which
                    Application Servers the same in both
    directions.

    5.5.2 Double exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |<-------------ASP Up------------|
                  |-----------ASP Up Ack---------->|
                  |                                |
                  |-------------ASP Up------------>|  (optional)
                  |<----------ASP Up Ack-----------|  (optional)
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |------- ASP Active(RCa)-------->|  RC: Routing Context
                  |<-----ASP Active Ack (RCa)------|      (optional)
                  |                                |
                  |<=========  DATA (RCa) =========|
                  |==========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|
                  |                                |
                  |------ASP Inactive (RCa)------->|  RC: Routing Context
                  |<----ASP Inactive Ack (RCa)-----|
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |
                  |------------ASP Down----------->|  (optional)
                  |<--------ASP Down Ack-----------|  (optional)
                  |                                |

    In this approach, only one single exchange of ASP Up message can be
    considered as enough since the response by applies.

                 3.10.3 Solution description

                    A more detailed specification of the other peer can messages to be
    considered as a notice that it is in ASP_UP state.

    For sent upon the same reason, only one ASP Down message is needed since once
    that
                    reception of an IPSP receives ASP_Down ack message it is itself considered as
    being in the ASP_Down state and not allowed ASPIA has been added to receive ASPSM
    messages.

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

    This scenarios show a basic example for IPSP communication for the
    three phases of the connection (establishment, data exchange,
    disconnection). It is assumed that the SCTP association is already
    set up.

                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|        (optional)
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |

    Routing Context are previously agreed to be the same in both
    directions.

 3.12.3 Solution description

    All the references to the "double exchange" (a.k.a. symmetric IPSP
    method) has been removed. Modifications in the ASP state machine has
    been done to include the IPSP model.

 3.13 Messages Procedures
                    Section.

                 3.11 INFO and Streams

 3.13.1 DIAG parameter length

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

                    At the document.

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

                 3.11.2 Text changes to the document

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

    None.

                    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 1.4.7) 3.4.1)
                    ---------

                    INFO String: variable length

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

    1. DATA is never sent on stream 0.
    2. ASPSM, MGMT, RKM should be sent on stream 0 (Other than BEAT and
       BEAT ACK)
    3. SSNM , ASPTM , BEAT and BEAT ACK optional INFO String parameter can be sent on carry any stream.

 3.13.3 Solution description

    A clear specification meaningful UTF-8
                    [10] character string along with the message. Length of how messages should be sent is included in the corresponding section.

 3.14 ASP Id INFO
                    String parameter is from 0 to 255 octets. This means that No
                    procedures are presently identified for IPSP communication

 3.14.1 Description of the problem

    When using its use but the IPSP communication it INFO String
                    MAY be used for debugging purposes. An INFO String with a zero length
                    parameter is no way of dynamically
    exchange not considered as an error (this means that the ASP Identifier Length
                    field in both directions.

 3.14.2 Text changes to the document TLV will be set to 4).

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

    The ASP Up Ack message contains

                    Diagnostic Information: variable length
                    When included, the following parameters:
         INFO String (optional) optional Diagnostic information can be any
                    information germane to the error condition, to assist in
                    identification of the error condition. 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                          /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Diagnostic information
                    SHOULD contain the offending message.

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

    The ASP Up Ack message contains

                    Diagnostic Information: variable length

                    When included, the following parameters:
         ASP Identifier                Optional
         INFO String                   Optional optional Diagnostic information can be any
                    information germane to the error condition, to assist in
                    identification of the error condition. The format for ASP Up Ack message parameters Diagnostic information
                    SHOULD contain the offending message. TheDiagnostic Information
                    parameter with a zero length parameter is not considered 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            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                          INFO String                          /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The optional ASP Identifier parameter is specially useful for IPSP
    communication. In an error
                    (this means that case the IPSP answering Length field in the ASP Up message MAY
    include its own ASP Identifier value. For AS-SG communication this
    parameter MUST NOT TLV will be used.

 3.14.3 set to 4).

                 3.11.3 Solution Description

    By including the optional ASP Identifier in ASP Up message this can
    be achieved. In description

                    It has been explicitly included the AS-SG communication this optional fact that a parameter with length
                    zero is
    not needed

 3.15 n+k redundancy

 3.15.1 allowed.

                 3.12 IPSP stuff

                 3.12.1 Description of the problem

    The n+k redundancy is explained as a general model to use but there
    is no reference in

                    At the AS state and sometimes it is not clear when to
    use it.

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

                 3.12.2 Text changes to the document

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

    AS-DOWN:

                    4.3 AS and ASP State Maintenance

                    The Application Server is unavailable.  This state implies
    that all related ASPs are in M3UA layer on the ASP-DOWN state for this AS.
    Initially SGP maintains the AS will be state of each remote ASP, in this state. An
                    each Application Server is in that the AS-DOWN state when it is removed from a configuration.

    AS-INACTIVE: The Application Server is available but no application
    traffic ASP is active (i.e., one or more related ASPs are in configured to receive
                    traffic, as input to the ASP-
    INACTIVE state, but none M3UA message distribution function.
                    Similarly, where IPSPs use M3UA in a point-to-point fashion, 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 M3UA
                    layer in an IPSP maintains 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 state of remote IPSPs. For the AS.  A recovery
    timer T(r) SHOULD be started and all incoming signalling messages
    SHOULD be queued by
                    purposes of the SGP. If an ASP becomes ASP-ACTIVE before T(r)
    expires, following procedures, only the AS SGP/ASP case is moved to
                    described but the AS-ACTIVE state and all SGP side of the queued
    messages will be sent procedures also apply to the ASP.

    If T(r) expires before an ASP becomes ASP-ACTIVE, 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 has no
    alternative, the SGP may stops queuing messages and discards all
    previously queued messages. The AS will move to maintains the AS-INACTIVE state
    if at least one of each remote ASP, in
                    each Application Server that the ASP is in ASP-INACTIVE state, otherwise it will move configured to receive
                    traffic, as input to AS-DOWN state.

    Figure 5 shows an example AS state machine for the case M3UA message distribution function.
                    Similarly, where IPSPs use M3UA in a point-to-point fashion, the
    AS/ASP data is preconfigured. 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.

                    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 cases where 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).

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

                    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
                    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.12.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.13 Messages and Streams

                 3.13.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.13.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.13.3 Solution description

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

                 3.14 ASP Id for IPSP communication

                 3.14.1 Description of the problem

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

                 3.14.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            |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       \                                                               \
                       /                          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.14.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.15 n+k redundancy

                 3.15.1 Description of the problem

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

                 3.15.2 Text changes to the document

                    ---------
                    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-     |
                         | 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-DOWN 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
                    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.  This state implies that at least n ASPs are in
                    the ASP-ACTIVE state.

                    AS-PENDING: An active ASP has transitioned from ASP-ACTIVE to ASP-
                    INACTIVE or ASP-DOWN and it was the number n 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 the number of ASPs in either ASP-INACTIVE or ASP-ACTIVE
                    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 a 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.

                    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.

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

                    PN2AC: One ASP moves to ASP-ACTIVE causing the number of ASPs in the
                    ASP-ACTIVE state to be n.

                    PN2IA: T(r) Expiry, n or more ASPs are in either ASP-INACTIVE or ASP-
                    ACTIVE state and number of ASPs in ASP-ACTIVE state is less than n.

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

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

                    ---------
                    New 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, 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.15.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.

                 3.16 Multiple Parameters of the Same Type in a Message

                 3.16.1 Description of the problem

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

                 3.16.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)
                    ---------

                    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.16.3  Solution Description

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

                 3.17 Registered Routing Key State After Unexpected ASP Up Message
                          Received
                 3.17.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.17.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.17.3 Solution Description

                    Added a statement to clarify that registered Routing Keys will be
                    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.18 Location of Network Appearance

                 3.18.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.18.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)
                    ---------

                    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.18.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.19 Determination of Congestion Abatement When ASP Sends SCON

                 3.19.1 Description of the problem

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

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

                 3.19.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.20 Removing CIC and SSN from RK

                 3.20.1 Description of the problem

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

                 3.20.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
                    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)
                    ---------

                    In this example, the SGP contains an instance of the SS7 SCCP
                    protocol layer that may, for example, perform the SCCP Global Title
                    Translation (GTT) function for messages logically addressed to the SG
                    SCCP.  If the result of a GTT for an SCCP message yields an SS7 DPC
                    or DPC/SSN address of an SCCP peer located in the IP domain, the
                    resulting MTP-TRANSFER request primitive is sent to the local M3UA-
                    resident network address translation and mapping function for ongoing
                    routing to the final IP destination.

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

                    In this example, the SGP contains an instance of the SS7 SCCP
                    protocol layer that may, for example, perform the SCCP Global Title
                    Translation (GTT) function for messages logically addressed to the SG
                    SCCP.  If the result of a GTT for an SCCP message yields an SS7 DPC
                    or DPC/SI address of an SCCP peer located in the AS/ASP
    configuration data IP domain, the
                    resulting MTP-TRANSFER request primitive is created dynamically, there would sent to the local M3UA-
                    resident network address translation and mapping function for ongoing
                    routing to the final IP destination.

                    ---------
                    Old text: (Section 1.5.3)
                    ---------
                    For internal SGP modeling purposes, this may be differences
    in accomplished with the state machine, especially at creation
                    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 AS.

                     Figure 5: AS State Transition Diagram

         +----------+   one
                    ASP trans to ACTIVE   +-------------+
         |    AS-   |---------------------------->|     AS- or SEP.

                    ---------
                    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
                             Protocol Data                         0x0210
                             Reserved                              0x0211
                             Registration Status                   0x0212
                             Deregistration Status                 0x0213

                    ---------
                    Old text: (Section 3.6.1)
                    ---------
                       |                  Traffic Mode Type (optional)                 | INACTIVE
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                     Destination Point Code                    |   ACTIVE
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  Network Appearance (optional)                |          |<---
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  Service Indicators (optional)                |
         +----------+    \                        +-------------+
            ^
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |         \ Tr Expiry,                ^              Originating Point Code List (optional)           |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                   Circuit Range List (optional)               |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       \ at least one             |    |
            |   |                                                               \ ASP in ASP-INACTIVE     |    |
            |   |
                       /                              ...                              /
                       \                        |    |
            |   |                                                               \
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                     Destination Point Code                    |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  Service Indicators (optional)                |              \                      |    |
    one ASP
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |              Originating Point Code List (optional)           | all ASP       \            one ASP
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                   Circuit Range List (optional)               | Last ACTIVE
    trans
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       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)                 | trans to       \           trans to
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                     Destination Point Code                    | ASP trans to
    to
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  Network Appearance (optional)                | ASP-DOWN        -------\   ASP-
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  Service Indicators (optional)                | ASP-INACTIVE
    ASP-
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |              Originating Point Code List (optional)           |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       \  ACTIVE   |    | or ASP-DOWN
    INACTIVE|   |                                                               \
                       /                              ...                              /
                       \                                                               \
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                     Destination Point Code                    |  (start Tr)
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  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
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |           Tag = 0x020f        |                            \              Length           |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |    Mask = 0   |   v                             \          Origination Point Code #1            |    v
         +----------+                          \  +-------------+
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |       Lower CIC Value #1      |                           --|      Upper CIC Value #1       |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       | AS-DOWN    Mask = 0   |          Origination Point Code #2            | AS-PENDING
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |       Lower CIC Value #2      |      Upper CIC Value #2       |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       /                              ...                              /
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  (queueing)    Mask = 0   |          Origination Point Code #n            |          |<----------------------------|
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |
         +----------+    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-DOWN 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
    ASP-ACTIVE state has not reach n.  The recovery timer T(r) is not
    running or has expired.

    AS-ACTIVE: The       Lower CIC Value #n      |      Upper CIC Value #n       |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                    (none)

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

                       An Application Server is available and application 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 is active.  This state implies that at least n ASPs are in the ASP-ACTIVE state.

    AS-PENDING: An active ASP has transitioned from ASP-ACTIVE is currently configured to ASP-
    INACTIVE or ASP-DOWN and it was receive
                       from the number n active SGP.  For example, an ASP in the AS.  A
    recovery timer T(r) SHOULD could be started configured to support
                       call processing for multiple ranges of PSTN trunks and all incoming therefore
                       receive related signalling
    messages SHOULD be queued 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 SGP. If
                       perspective of an ASP becomes ASP-ACTIVE
    before T(r) expires, ASP, a Routing Context defines a range of
                       signalling traffic that the AS ASP is moved currently configured to receive
                       from the AS-ACTIVE state and all
    the queued messages will SGP.  For example, an ASP could be sent configured to the ASP. support
                       call processing for multiple ranges of PSTN trunks and therefore
                       receive related signalling traffic, identified by separate SS7
                       DPC/OPC/SI ranges.

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

                    If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
    alternative, determines that one or more of the Routing Key parameters
                    are not supported for the purpose of creating new Routing Key
                    entries, the SGP may stops queuing messages and discards all
    previously queued messages. The AS will move returns a Registration Response message to the AS-INACTIVE state
    if at least ASP,
                    containing a Registration Result "Error - Unsupported RK parameter
                    field".  This result MAY be used if, for example, the number of ASPs SGP does not
                    support RK Circuit Range Lists in either ASP-INACTIVE a Routing Key because the SGP does
                    not support ISUP traffic, or ASP-ACTIVE
    sum n, otherwise it will move to AS-DOWN state.

    Figure 5 shows does not provide CIC range granularity.

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

                    If an example AS state machine SGP determines that one or more of the Routing Key parameters
                    are not supported for the case where purpose of creating new Routing Key
                    entries, the
    AS/ASP data is preconfigured and SGP returns a 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 Registration Response message to ASP-INACTIVE causing that n ASPs the ASP,
                    containing a Registration Result "Error - Unsupported RK parameter
                    field".

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

                    For example, where Application Servers are in
    either ASP-ACTIVE or ASP-INACTIVE states.

    IA2DN: One ASP moves to ASP-DOWN causing that defined using ranges of
                    ISUP CIC values, the number Operator is implicitly splitting up control of ASPs
                    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.20.3 Solution Description

                    The removal of reference to SSN and CIC used in
    either ASP-ACTIVE or ASP-INACTIVE drops below n.

    IA2AC: one Routing Keys as well
                    as removal of Circuit Range from the Routing Key parameter removes
                    the unclear text from the specification.

                 3.21 ASP moves comes to ASP-ACTIVE, causing number of ASPs in the ASP-ACTIVE state to be n.

    AC2PN: one without full SS7 connectivity

                 3.21.1 Description of the problem

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

                 3.21.2 Text changes to ASP-INACTIVE or ASP-DOWN
    states, causing the number document

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

                    The SGP M3UA layer determines the set of concerned ASPs in ASP-ACTIVE drop below n.

    PN2AC: One ASP moves to ASP-ACTIVE causing be
                    informed based on the number of ASPs in specific SS7 network for which the
    ASP-ACTIVE state primitive
                    indication is relevant. In this way, all ASPs configured to be n.

    PN2IA: T(r) Expiry, n or more
                    send/receive traffic within a particular network appearance are
                    informed.  If the SGP operates within a single SS7 network
                    appearance, then all ASPs are in either ASP-INACTIVE or ASP-
    ACTIVE state informed.

                    DUNA, DAVA, SCON, and number of ASPs in ASP-ACTIVE state is less than n.

    PN2DN: T(r) Expiry, DRST messages may be sent sequentially and
                    processed at the number of ASPs receiver in either ASP-INACTIVE or ASP-
    ACTIVE state is less than n.

    For other cases where the AS/ASP configuration data is created
    dynamically, there would be differences in order sent.

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

                    The SGP M3UA layer determines the state machine,
    especially at creation set of concerned ASPs to be
                    informed based on the AS. For example, where specific SS7 network for which the AS/ASP
    configuration data primitive
                    indication is not created until Registration of the first
    ASP, relevant. In this way, all ASPs configured to
                    send/receive traffic within a particular network appearance are
                    informed.  If the AS-INACTIVE state is entered directly upon SGP operates within a single SS7 network
                    appearance, then all ASPs are informed.

                    For the nth
    successful REG REQ from particular case that an ASP belonging becomes active for an AS and
                    destinations normally accessible to that AS.  Another example
    is where the AS/ASP configuration data is not created until AS are inaccessible,
                    restricted or congested, the SG MAY send DUNA, DRST or SCON messages
                    for the inaccessible, restricted or congested destinations to the nth ASP successfully enters
                    newly active for the ASP-ACTIVE state.  In this latter case AS to prevent the AS-ACTIVE state is entered directly. ASP from sending traffic for
                    destinations that it might otherwise not know that are inaccessible,
                    restricted or congested.

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

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

    An SGP or IPSP, upon reception of an ASP Active message for the first

                    The ASP in a Loadshare AS, MAY choose not to direct traffic to a newly 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 until it determines that there are sufficient resources to
    handle the expected load (e.g., until there are "n" ASPs in state
    ASP-ACTIVE and does not have current
                    destination statuses.  If MTP restart is in progress at the AS).  In this case, 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 SHOULD withhold case, MTP restart could be considered if the Notify (AS-ACTIVE) until there are sufficient resources. IPSP also
                    has connection to an SS7 network. [...]

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

                    The ASP MAY choose to audit the availability of unavailable
                    destinations by sending DAUD messages.  This would be for both loadsharing example the
                    case when an AS becomes active at an ASP and broadcast)
    ---------

    An 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 IPSP, upon reception of restricted.

                    When an ASP Active message becomes active for an AS and the SG is experiencing SS7
                    network isolation or is performing the MTP Restart procedure for the first
    ASP in a Loadshare
                    AS, the SG SHOULD NOT direct traffic to send a DUNA(*) to the 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 prevent
                    the AS). ASP from sending traffic.

                    In this case, the SGP or IPSP SHOULD withhold the Notify
    (AS-ACTIVE) until there are sufficient resources.

 3.15.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 case, MTP restart could be considered if the previous one: 1+0 model. The change from MAY to
    SHOULD NOT makes it recommendable IPSP also
                    has connection to an SS7 network. [...]

                 3.21.3 Solution Description
                    By specifying how send traffic only when the
    require ASPs number are SSNM messages in ASP-ACTIVE state. that scenario the problem is
                    solved.

                 4. Acknowledgements

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

                 5. Authors' Addresses

                    Javier Pastor-Balbas
                    Ericsson Espana S.A.
                    Ombu 3
                    28045 Madrid
                    Spain

                    Phone: +34-91-339-3819
                    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
                          - 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 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

                 Full Copyright Statement

                    Copyright (C) The Internet Society (2002). (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.