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

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

 Network Working Group                               Javier Pastor-Balbas
 INTERNET-DRAFT                                                  Ericsson
 Expires: April 2003
                                                             Ken Morneault
                                                             Cisco Systems
 
 
                                                             October, 2002
 
 
 
                          M3UA Implementor's Guide
            <draft-ietf-sigtran-m3ua-implementors-guide-02.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.
 
 
 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.
 
 
 
 
 
 
 
 Pastor, Morneault                                               [Page 1]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
 
 
 TABLE OF CONTENTS
 
 1.Introduction........................................................3
 2.Conventions.........................................................3
 3.Corrections to RFC-M3UA.............................................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 RC parameter.........................................9
 3.7 Receiving REG for a RK already registered.........................12
 3.8 OPC list in the Registration Request Message......................13
 3.9 Auditing procedure and congestion state...........................14
 3.10 Response to an ASPIA message.....................................16
 3.11 INFO and DIAG parameter length...................................18
 3.12 IPSP stuff.......................................................19
 3.13 Messages and Streams.............................................24
 3.14 ASP Id for IPSP communication....................................25
 3.15 n+k redundancy...................................................26
 4.Acknowledgements...................................................31
 5.Authors' Addresses.................................................31
 6.References.........................................................31
 7.Changes Control....................................................33
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Pastor, Morneault                                               [Page 2]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 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
 
 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.
 
 
 
 
 
 
 Pastor, Morneault                                               [Page 3]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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".
 
 
 
 
 
 
 
 Pastor, Morneault                                               [Page 4]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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
 
 
 
 
 Pastor, Morneault                                               [Page 5]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
    (*) 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].
 
 
 
 
 
 Pastor, Morneault                                               [Page 6]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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 the different SS7 message label types was
    required.
 
 
 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
 
 
 
 
 Pastor, Morneault                                               [Page 7]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    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 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.
 
 
 
 
 
 
 Pastor, Morneault                                               [Page 8]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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 RC parameter
 
 3.6.1 Description of the problem
 
    Some optional parameters are not always optional. The text should be
    clear when optional parameters are not optional.
 
 
 
 
 
 
 
 
 
 
 Pastor, Morneault                                               [Page 9]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
 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
         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
 
 
    ---------
    Old text: (Section 3.4.2)
    ---------
 
         Routing Context          Optional
 
 
 
 
 Pastor, Morneault                                              [Page 10]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    New text: (Section 3.4.2)
    ---------
 
         Routing Context          Semi-Optional
 
 
    ---------
    Old text: (Section 3.4.3)
    ---------
 
         Routing Context          Optional
 
    ---------
    New text: (Section 3.4.3)
    ---------
 
         Routing Context          Semi-Optional
 
 
    ---------
    Old text: (Section 3.4.4)
    ---------
 
         Routing Context          Optional
 
    ---------
    New text: (Section 3.4.4)
    ---------
 
         Routing Context          Semi-Optional
 
 
    ---------
    Old text: (Section 3.4.5)
    ---------
 
         Routing Context          Optional
 
    ---------
    New text: (Section 3.4.5)
    ---------
 
         Routing Context          Semi-Optional
 
 
    ---------
    Old text: (Section 3.4.6)
    ---------
 
 
 
 
 Pastor, Morneault                                              [Page 11]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
         Routing Context          Optional
 
    ---------
    New text: (Section 3.4.6)
    ---------
 
         Routing Context          Semi-Optional
 
 
 
 3.6.3 Solution description
 
    Stating that the parameter is semi-optional, implies that it not
    either optional or mandatory. In the parameter description the text
    explains when it 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 a Registration Response message to the ASP, containing a
    Registration Result "Error - Cannot Support Unique Routing".
 
 
 
 3.7.3 Solution description
 
    By specifying the error code, the general problem of re-registering a
    RK is solved. This error response applies whether the Routing Key is
    Active or Inactive.
 
 
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 12]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
 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 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,
 
     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Mask = 0   |          Origination Point Code #1            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Mask = 0   |          Origination Point Code #2            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                              ...                              /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Mask = 0   |          Origination Point Code #n            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    ---------
    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 as the only
    posible DPC for the AS.
 
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 13]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Mask = 0   |          Destination Point Code #1            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Mask = 0   |          Destination Point Code #2            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                              ...                              /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    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. The parameter name has also
    be changed to "Destination" since it is the way that the SG sees it.
 
 
 3.9 Auditing procedure and congestion state
 
 3.9.1 Description of the problem
 
    The current description of the AUDIT procedure in regards to
    congestion state is not clear enough. When to send SCON is not
    completely specified.
 
 
 
 
 
 3.9.2 Text changes to the document
 
    ---------
    Old text: (Section 3.3.1)
    ---------
 
    [...]. Where the SGP maintains the congestion status of the SS7
    destination, and the SS7 destination is congested, the SGP MUST
    additionally respond with an SCON message before the DAVA or DRST
    message.  If the SS7 destination is available and congested, the SGP
    MUST respond with an SCON message and then a DAVA message.  If the
    SS7 destination is restricted and congested, the SGP MUST respond
    with an SCON message immediately followed by a DRST message.  If the
    SGP has no information on the availability status of the SS7
    destination, the SGP responds with a DUNA message, as it has no
    routing information to allow it to route traffic to this destination.
 
 
 
 
 
 Pastor, Morneault                                              [Page 14]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    ---------
    New text: (Section 3.3.1)
    ---------
 
    [...]. Where the SGP maintains the congestion status of the SS7
    destination, the SGP MUST additionally respond with an SCON message
    before the DAVA or DRST message.  If the SS7 destination is
    available, the SGP MUST respond with an SCON message (indicating the
    appropriate congestion level) and then a DAVA message.  If the SS7
    destination is restricted, the SGP MUST respond with an SCON message
    (with the appropriate congestion level) immediately followed by a
    DRST message.  If the SGP has no information on the availability
    status of the SS7 destination, the SGP responds with a DUNA message,
    as it has no routing information to allow it to route traffic to this
    destination.
 
    Where the SGP does not maintain the congestion status of the SS7
    destination, the response to a DAUD message should always be only a
    DAVA, DRST or DUNA message as appropriate.
 
 
    ---------
    Old text: (Section 5.4)
    ---------
 
    5.4 M3UA/MTP3-User Boundary Examples
 
 
    ---------
    New text: (Section 5.4, 5.5)
    ---------
 
    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 ----------  |
 
 
 
 
 Pastor, Morneault                                              [Page 15]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
 
    5.4.3 SG state: Unknown / Available
 
           ASP                          SGP
           ---                          ---
            |  -------- DAUD --------->  |
            |  <------- DAVA ----------  |
 
 
 
    5.4.4 SG state: Uncongested / Unavailable
 
           ASP                          SGP
           ---                          ---
            |  -------- DAUD --------->  |
            |  <------- DUNA ----------  |
 
 
 
    5.5 M3UA/MTP3-User Boundary Examples
 
 
 
 3.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 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 not clear how to act in the following scenario:
 
 
           ASP                          SGP
           ---                          ---
            |  ------ ASPIA (RC1)----->  |
 
            |  <----  ASPIA Ack -------  |
 
            |  -----DEREG REQ (RC1)--->  |
            |  <----DEREG RSP (RC1)----  |
            |  -------ASPIA (RC1)----->  |
 
 
 
 
 Pastor, Morneault                                              [Page 16]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    What should SG do?
 
 3.10.2 Text changes to the document
 
    ---------
    Old text: (Section 4.5.3)
    ---------
 
    When an ASP wishes to withdraw from receiving traffic within an AS,
    the ASP sends an ASP Inactive message to the SGP or IPSP.  This
    action MAY be initiated at the ASP by an M-ASP_INACTIVE request
    primitive from Layer Management or MAY be initiated automatically by
    an M3UA management function.  In the case where an ASP is processing
    the traffic for more than one Application Server across a common SCTP
    association, the ASP Inactive message contains one or more Routing
    Contexts to indicate for which Application Servers the ASP Inactive
    message applies.
 
    ---------
    New text: (Section 4.5.3)
    ---------
 
    When an ASP wishes to withdraw from receiving traffic within an AS,or
    the ASP wants to initiate the process of activation, the ASP sends an
    ASP Inactive message to the SGP or IPSP.
 
    An ASP Inactive message MUST be always responded by the peer
    (although other messages may be sent in the middle):
       - If the corresponding RK is registered (statically or
          dynamically), the peer should respond with an ASP Inactive Ack
          message.
       -           If the RK is not registered, or the RC information is not valid,
          the peer must respond with an ERROR message with Error Code =
          "Invalid Routing Context".
       - If the RC is missing and its specification is needed according
          to the used configuration, the peer must respond with an ERROR
          message with Error Code = "No Configured AS for ASP".
 
    The action of sending the ASP Inactive message MAY be initiated at
    the ASP by an M-ASP_INACTIVE request primitive from Layer Management
    or MAY be initiated automatically by an M3UA management function.  In
    the case where an ASP is processing the traffic for more than one
    Application Server across a common SCTP association, the ASP Inactive
    message contains one or more Routing Contexts to indicate for which
    Application Servers the ASP Inactive message applies.
 
 3.10.3 Solution description
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 17]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    A more detailed specification of the messages to be sent upon the
    reception of an ASPIA has been added to the Inactive Procedures
    Section.
 
 
 3.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 to the document
 
    ---------
    Old text: (Section 3.4.1)
    ---------
 
    INFO String: variable length
 
    The optional INFO String parameter can carry any meaningful UTF-8
    [10] character string along with the message. Length of the INFO
    String parameter is from 0 to 255 octets. No procedures are presently
    identified for its use but the INFO String MAY be used for debugging
    purposes.
 
 
    ---------
    New text: (Section 3.4.1)
    ---------
 
    INFO String: variable length
 
    The optional INFO String parameter can carry any meaningful UTF-8
    [10] character string along with the message. Length of the INFO
    String parameter is from 0 to 255 octets. This means that No
    procedures are presently identified for its use but the INFO String
    MAY be used for debugging purposes. An INFO String with a zero length
    parameter is not considered as an error (this means that the Length
    field in the TLV will be set to 4).
 
 
    ---------
    Old text: (Section 3.8.1)
    ---------
 
    Diagnostic Information: variable length
 
    When included, the optional Diagnostic information can be any
    information germane to the error condition, to assist in
 
 
 
 
 Pastor, Morneault                                              [Page 18]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    identification of the error condition. The Diagnostic information
    SHOULD contain the offending message.
 
 
    ---------
    New text: (Section 3.8.1)
    ---------
 
    Diagnostic Information: variable length
 
    When included, the optional Diagnostic information can be any
    information germane to the error condition, to assist in
    identification of the error condition. The Diagnostic information
    SHOULD contain the offending message. 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)
    ---------
 
    Figure 4: ASP State Transition Diagram, per AS
 
                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |      Other   +-------|              |
                |   ASP in AS  |       +--------------+
                |   Overrides  |           ^     |
                |              |    ASP    |     | ASP
                |              |    Active |     | Inactive
                |              |           |     v
                |              |       +--------------+
 
 
 
 
 Pastor, Morneault                                              [Page 19]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
                |              |       |              |
                |              +------>| 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: 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 for both ASPs and IPSPs.
 
 
 
 
 Pastor, Morneault                                              [Page 20]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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)
    ---------
 
    None.
 
 
    ---------
    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)
    ---------
 
    None.
 
 
    ---------
    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)
    ---------
 
    None.
 
 
 
 
 Pastor, Morneault                                              [Page 21]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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.
 
    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.
 
 
    ---------
    Old text: (Section 5.5)
    ---------
 
    These 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. Both single exchange and double exchange behavior are
    included for illustrative purposes.
 
    5.5.1 Single exchange:
 
                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
 
 
 
 
 Pastor, Morneault                                              [Page 22]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
                  |<-----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.
 
    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 the other peer can be
    considered as a notice that it is in ASP_UP state.
 
    For the same reason, only one ASP Down message is needed since once
    that an IPSP receives ASP_Down ack message it is itself considered as
    being in the ASP_Down state and not allowed to receive ASPSM
    messages.
 
 
 
 
 Pastor, Morneault                                              [Page 23]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
    ---------
    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 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)
 
 
 
 
 Pastor, Morneault                                              [Page 24]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    ---------
 
    None.
 
    ---------
    New text: (Section 1.4.7)
    ---------
 
    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 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 it is no way of 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                          /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 
 
 
 Pastor, Morneault                                              [Page 25]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
    ---------
    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 specially 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 and sometimes it is not clear when to
    use it.
 
 3.15.2 Text changes to the document
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 26]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    ---------
    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
 
 
 
 
 Pastor, Morneault                                              [Page 27]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    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
 
 
 
 
 
 Pastor, Morneault                                              [Page 28]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    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.
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 29]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
    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.
 
 
 
 
 Pastor, Morneault                                              [Page 30]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
 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:
 
 
 
 
 Pastor, Morneault                                              [Page 31]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
          - 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".
 
 
 
 Full Copyright Statement
 
    Copyright (C) The Internet Society (2002). All Rights Reserved.
 
    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works. However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.
 
    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.
 
    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
    Acknowledgment
 
    Funding for the RFC Editor function is currently provided by the
    Internet Society.
 
 
 
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 32]


 INTERNET-DRAFT          M3UA IMPLEMENTORÆS GUIDE      October 31st, 2002
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Pastor, Morneault                                              [Page 33]
 

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