TOC 
Signaling Transport Working GroupB. Nagelberg
Internet-DraftAdax
Intended status: InformationalNovember 02, 2007
Expires: May 5, 2008 


M2UA Implementor's Guide
<draft-nagelberg-m2ua-implementors-guide-00>

Status of this Memo

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

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

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

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

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

This Internet-Draft will expire on May 5, 2008.

Abstract

This document contains a compilation of all defects found since the publication date for M2UA [RFC3331]. 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 M2UA to clarify errors in the original M2UA document. This document updates RFC3331 and text within this document supersedes the text found in RFC3331.



Table of Contents

1.  Introduction
    1.1.  Terminology
    1.2.  Requirements Language
2.  Corrections to RFC3331
    2.1.  n+k redundancy
    2.2.  Messages and Streams
    2.3.  Parameter Containing Subparameters with Padding Bytes
    2.4.  Multiple Parameters of the Same Type in a Message
    2.5.  How to indicate that Dynamic Registration is not supported
    2.6.  Explanatory text for "Unsupported Message Type" error code is missing
    2.7.  Need additional error code
    2.8.  Notify(ASP-Failure) usage clarification
    2.9.  Alignment of ASP Active message with ASP Inactive message
    2.10.  Response to an ASPIA message
    2.11.  NOTIFY messages are missing in Examples section
    2.12.  Error handling in the Retrieval Confirm message for ACTION_RTRV_BSN
    2.13.  Error handling in the Retrieval Confirm message for ACTION_RTRV_MSGS
3.  Acknowledgements
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

This document contains a compilation of all defects found since the publication date for M2UA [RFC3331] (Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. Heitz, “Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer,” September 2002.). 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 M2UA to clarify errors in the original M2UA document. This document updates RFC3331 and text within this document supersedes the text found in RFC3331. Each error will be detailed within this document in the form of:



 TOC 

1.1.  Terminology

The terms are commonly identified in related work M2UA [RFC3331] (Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. Heitz, “Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer,” September 2002.).



 TOC 

1.2.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



 TOC 

2.  Corrections to RFC3331



 TOC 

2.1.  n+k redundancy



 TOC 

2.1.1.  Description of the problem

The n+k redundancy model is explained as a general model but there is no reference to it in the current AS state diagram, and sometimes it is not clear when it should be used. Also the term "n+k" is subject to multiple interpretations.



 TOC 

2.1.2.  Text changes to the document

---------
Old text: (Section 1.3.2)
---------

The M2UA layer supports a n+k redundancy model (active-standby, load sharing, broadcast) where n is the minimum number of redundant ASPs required to handle traffic and k ASPs are available to take over for a failed or unavailable ASP. Note that 1+1 active/standby redundancy is a subset of this model. A simplex 1+0 model is also supported as a subset, with no ASP redundancy.

---------
New text: (Section 1.3.2)
---------

The M2UA layer supports an "n+k" redundancy model, where "n" ASPs is the number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be either active at the same time as "n" or kept inactive until needed due to a failed or unavailable ASP.

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

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

AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. An Application Server MUST be in the AS-DOWN state before it can be 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, the SGP 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 the ASP-INACTIVE state, otherwise it will move to the AS-DOWN state.

Figure 6 shows an example AS state machine for the case where the AS/ASP data is pre-configured. For other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at the 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 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.


                Figure 6: 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  |
     |          |                             |  (queuing)  |
     |          |<----------------------------|             |
     +----------+    Tr Expiry and no ASP     +-------------+
                     in ASP-INACTIVE state

  Tr = Recovery Timer

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

AS-DOWN: The Application Server is unavailable. This state implies that all the ASPs are in the ASP-DOWN state. 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. One or more ASPs are in ASP-INACTIVE state and/or the number of ASPs in ASP-ACTIVE state has not reached n. The recovery timer T(r) is not running or has expired.

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

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

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

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


            Figure 6: 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 from ASP-DOWN to ASP-INACTIVE state.

IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN.

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

AC2PN: The last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP- DOWN states.

PN2AC: One ASP moves to ASP-ACTIVE.

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

PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state.

An AS becomes AS-ACTIVE when n ASPs reach the ASP-ACTIVE state during the start-up phase (except for smooth start). Once the traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP switches to a state other than ASP-ACTIVE. This avoids unnecessary traffic disturbances as long as there are ASPs available, in the assumption that the system will not always be exposed to the maximum load.

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

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

An SGP, upon reception of an ASP Active message for the first ASP in a Load share 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).

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

At start-up or re-start phases, an SGP, 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 SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.



 TOC 

2.1.3.  Solution description

The AS state machine reflects the state changes as a function of the "n" number from the n+k redundancy model. 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.



 TOC 

2.2.  Messages and Streams



 TOC 

2.2.1.  Description of the problem

The instructions for stream usage are distributed across different sections.



 TOC 

2.2.2.  Text changes to the document

---------
Old text: (Section 1.5.4.1)
---------

SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) messages (see Section 3) since stream '0' SHOULD only be used for ASP Management (ASPM) messages (see Section 4.3.3).

---------
New text: (Section 1.5.4.1)
---------

---------
Old text: (Section 4.2.1)
---------

All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. All MGMT messages, with the exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP stream '0'. All ASPTM messages SHOULD be sent on the stream which normally carries the data traffic to which the message applies. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery, and MAY be sent on any stream.

---------
New text: (Section 4.2.1)
---------

All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery



 TOC 

2.2.3.  Solution description

The instructions for stream usage are combined into a single section.



 TOC 

2.3.  Parameter Containing Subparameters with Padding Bytes



 TOC 

2.3.1.  Description of the problem

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



 TOC 

2.3.2.  Text changes to the document

---------
Old text: (Section 3.1.6)
---------

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

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



 TOC 

2.3.3.  Solution description

Clarified that when calculating the length of a parameter that contains subparameters, the padding bytes of the subparameters should be included.



 TOC 

2.4.  Multiple Parameters of the Same Type in a Message



 TOC 

2.4.1.  Description of the problem

It is not clear whether or not multiple parameters of same type are allowed in a message.



 TOC 

2.4.2.  Text changes to the document

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

None.

---------
New text: (Section 3.1.6)
---------

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.



 TOC 

2.4.3.  Solution description

Clarified that multiple parameters of the same type are forbidden in messages unless explicitly allowed.



 TOC 

2.5.  How to indicate that Dynamic Registration is not supported



 TOC 

2.5.1.  Description of the problem

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



 TOC 

2.5.2.  Text changes to the document

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

None.

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

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

---------
Old text: (Section 3.3.3.1)
---------

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

---------
New text: (Section 3.3.3.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.

---------
Old text: (Section 3.3.3.1)
---------

The ERR message contains the following parameters:

Error Code (mandatory)

Interface Identifier (optional)

Diagnostic Information (optional)

---------
New text: (Section 3.3.3.1)
---------

Error Code (mandatory)

Interface Identifier (optional)

Diagnostic Information (conditional)



 TOC 

2.5.3.  Solution description

An SGP that does not support dynamic registration must return an Error message (Unsupported Message Class), including the first 40 bytes of the offending message (i.e. any Link Key Management message sent by the ASP) so that the ASP can correlate this error to the Registration Request message. Note that the change to the "Unsupported Message Class" text make this a general solution that allows the ASP or SG side to correlate these error responses with the offending message.



 TOC 

2.6.  Explanatory text for "Unsupported Message Type" error code is missing



 TOC 

2.6.1.  Description of the problem

There is no explanatory text for the "Unsupported Message Type" error code.



 TOC 

2.6.2.  Text changes to the document

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

None

---------
New text: (Section 3.3.3.1)
---------

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.



 TOC 

2.6.3.  Solution description

Add explanatory text for the "Unsupported Message Type" error code.



 TOC 

2.7.  Need additional error code



 TOC 

2.7.1.  Description of the problem

There is a need to add an error code to cover the case in which an ASP Active or an ASP Inactive message is received from the ASP without a Interface Identifier parameter, and it is not known by configuration data which Application Servers are referenced.



 TOC 

2.7.2.  Text changes to the document

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

Missing Parameter                      0x16

---------
New text: (Section 3.3.3.1)
---------

Missing Parameter                      0x16
Not Used in M2UA                       0x17
Not Used in M2UA                       0x18
Not Used in M2UA                       0x19
No Configured AS for ASP               0x1a

The "No Configured AS for ASP" error is sent if an ASP Active or an ASP Inactive message is received from the ASP without a Interface Identifier parameter, and it is not known by configuration data which Application Servers are referenced.



 TOC 

2.7.3.  Solution description

Add error code.



 TOC 

2.8.  Notify(ASP-Failure) usage clarification



 TOC 

2.8.1.  Description of the problem

It is not clear when Notify (ASP Failure) must be sent. Is it upon failure (SCTP association fails) or any transition to ASP-DOWN state?



 TOC 

2.8.2.  Text changes to the document

---------
Old text: (Section 3.3.3.2)
---------

In the Insufficient ASP Resources case, the SGP is indicating to an ASP-INACTIVE ASP(s) in the AS that another ASP is required in order to handle the load of the AS (Load-sharing mode). For the Alternate ASP Active case, the formerly Active ASP is informed when an alternate ASP transitions to the ASP Active state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.

---------
New text: (Section 3.3.3.2)
---------

These notifications are not based on the SGP reporting the state change of an ASP or AS.



 TOC 

2.8.3.  Solution description

The term "transitioned to ASP-DOWN" has been changed to "ASP has failed" to clarigy that the ASP failure is the reason of this notification.



 TOC 

2.9.  Alignment of ASP Active message with ASP Inactive message



 TOC 

2.9.1.  Description of the problem

The description of the procedures for ASP Active and ASP Inactive messages are different, and the responses to these messages are not specified for all cases.



 TOC 

2.9.2.  Text changes to the document

---------
Old text: (Section 4.3.4.3)
---------

In the case where an ASP Active message does not contain a Interface Identifier parameter, the receiver must know, via configuration data, of which Application Server(s) the ASP is a member.

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

In the case where an ASP Active message does not contain a Interface Identifier parameter, the receiver must know, via configuration data, of which Application Server(s) the ASP is a member and move the ASP to the ASP-ACTIVE state in all Application Servers.

---------
Old text: (Section 4.3.4.3)
---------

Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Interface Identifiers, allowing the SGP to independently acknowledge the ASP Active message for different (sets of) Interface Identifiers. The SGP MUST send an Error message ("Invalid Interface Identifier") for each Interface Identifier value that cannot be successfully activated.

In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently discarded.

The SGP MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SGP.

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

Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Interface Identifiers, allowing the SGP to independently acknowledge the ASP Active message for different (sets of) Interface Identifiers.

The ASP Active message will be responded in the following way as a function of the presence/need of the Interface Identifier parameter:



 TOC 

2.9.3.  Solution description

Align the wording in these two sections.



 TOC 

2.10.  Response to an ASPIA message



 TOC 

2.10.1.  Description of the problem

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


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

What should SG do?



 TOC 

2.10.2.  Text changes to the document

---------
Old text: (Section 4.3.4.4)
---------

When an ASP wishes to withdraw from receiving traffic within an AS, the ASP sends an ASP Inactive message to the SGP. 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 M2UA 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 Interface Identifiers to indicate for which Application Servers the ASP Inactive message applies.

---------
New text: (Section 4.3.4.4)
---------

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

The SGP MUST always respond to an ASP Inactive message, in the following way:

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 M2UA 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 Interface Identifiers to indicate for which Application Servers the ASP Inactive message applies.



 TOC 

2.10.3.  Solution description

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



 TOC 

2.11.  NOTIFY messages are missing in Examples section



 TOC 

2.11.1.  Description of the problem

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



 TOC 

2.11.2.  Text changes to the document

---------
Old text: (Section 5.1.1)
---------

             SGP                             ASP1
              |                               |
              |<-------------ASP Up-----------|
              |-----------ASP Up Ack--------->|
              |                               |
              |<------- ASP Active------------|
              |-----ASP Active Ack----------->|
              |                               |
              |-----NTFY(AS-ACTIVE)---------->|
              |                               |


---------
New text: (Section 5.1.1)
---------


             SGP                             ASP1
              |                               |
              |<-------------ASP Up-----------|
              |-----------ASP Up Ack--------->|
              |                               |
              |-----NTFY(AS-INACTIVE)-------->|
              |                               |
              |<------- ASP Active(LKn)-------|
              |-----ASP Active Ack (LKn)----->|
              |                               |
              |-----NTFY(AS-ACTIVE)(LKn)----->|
              |                               |


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

            SGP                             ASP1
             |                               |
             |<------------ASP Up------------|
             |----------ASP Up Ack---------->|
             |                               |
             |<----REG REQ-------------------|
             |----REG REQ RESP-------------->|
             |                               |
             |<------- ASP Active------------|
             |-----ASP Active Ack----------->|
             |                               |
             |-----NTFY(AS-ACTIVE)---------->|
             |                               |


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

            SGP                             ASP1
             |                               |
             |<------------ASP Up------------|
             |----------ASP Up Ack---------->|
             |                               |
             |<----REG REQ-------------------|
             |----REG REQ RESP-------------->|
             |                               |
             |----NTFY(AS-INACTIVE)--------->|
             |                               |
             |<------- ASP Active------------|
             |-----ASP Active Ack----------->|
             |                               |
             |-----NTFY(AS-ACTIVE)---------->|
             |                               |


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

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

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


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



 TOC 

2.11.3.  Solution description

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



 TOC 

2.12.  Error handling in the Retrieval Confirm message for ACTION_RTRV_BSN



 TOC 

2.12.1.  Description of the problem

There is a contradiction in the RFC regarding error handling in the Retrieval Confirm message for ACTION_RTRV_BSN, for the case in which the SGP cannot retrieve the Backward Sequence Number. Section 3.3.1.10 (Retrieval Confirm) states that "If the BSN could not be retrieved, the Sequence Number field will not be included and the Result field will indicate failure." However Section 5.3.6 (SS7 Link Changeover) shows examples of this error case in which the Sequence Number field is included, and is set to -1.



 TOC 

2.12.2.  Text changes to the document

---------
Old text: (Section 5.3.6)
---------

An example of a message flow with an error retrieving the BSN is shown below.


MTP2          M2UA                            M2UA             MTP3
SGP           SGP                             ASP              ASP

<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

-BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv-->
                           (seq_num = -1)

---------
New text: (Section 5.3.6)
---------

An example of a message flow with an error retrieving the BSN is shown below.


MTP2          M2UA                            M2UA             MTP3
SGP           SGP                             ASP              ASP

<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

-BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv-->
                 (seq_num field not included)



 TOC 

2.12.3.  Solution description

The example has been corrected to not conflict with the message description.



 TOC 

2.13.  Error handling in the Retrieval Confirm message for ACTION_RTRV_MSGS



 TOC 

2.13.1.  Description of the problem

There is a contradiction in the RFC regarding the use of the Sequence Number field in Retrieval Confirm message for the ACTION_RTRV_MSGS case. Section 3.3.1.10 (Retrieval Confirm) states that "For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of the Result field will indicate success or failure. A failure means that the buffers could not be retrieved. The Sequence Number field is not used with ACTION_RTRV_MSGS." However Section 5.3.6 (SS7 Link Changeover) shows examples of the retrieval confirm message for ACTION_RTRV_MSGS in which the Sequence Number field is included.



 TOC 

2.13.2.  Text changes to the document

---------
Old text: (Section 5.3.6)
---------


MTP2          M2UA                            M2UA             MTP3
SGP           SGP                             ASP              ASP

<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
                           (seq_num = 0)

-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
                           (seq_num = BSN)

<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
                           (seq_num = FSN)

-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
                           (seq_num = 0)

---------
New text: (Section 5.3.6)
---------


MTP2          M2UA                            M2UA             MTP3
SGP           SGP                             ASP              ASP

<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
                           (seq_num = 0)

-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
                           (seq_num = BSN)

<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
                           (seq_num = FSN)

-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
                      (seq_num field not included)

---------
Old text: (Section 5.3.6)
---------

An example of a message flow with an error retrieving the messages is shown below.


<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
                           (seq_num = BSN)

<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
                           (seq_num = FSN)

-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
                           (seq_num = -1)

---------
New text: (Section 5.3.6)
---------

An example of a message flow with an error retrieving the messages is shown below.


<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
                           (seq_num = BSN)

<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
                           (seq_num = FSN)

-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
                       (seq_num field not included)



 TOC 

2.13.3.  Solution description

The example has been corrected to not conflict with the message description.



 TOC 

3.  Acknowledgements

The author would like to thank Javier Pastor-Balbas, Ken Morneault, Lyndon Ong, Tolga Asveren, Brian Bidulock, Umesh Vats, Samuel Dur D. Jeyaseelan, Antonio Canete, Kamesh Kaul, Vivek Toky, Daniel Cohn and many others for their valuable comments and suggestions.



 TOC 

4.  IANA Considerations

This memo includes no request to IANA.



 TOC 

5.  Security Considerations

No new threats have been identified besides the already known in [RFC3331] (Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. Heitz, “Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer,” September 2002.).



 TOC 

6.  References



 TOC 

6.1. Normative References

[RFC3331] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. Heitz, “Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer,” RFC 3331, September 2002 (TXT).


 TOC 

6.2. Informative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4666] Morneault, K. and J. Pastor-Balbas, “Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA),” RFC 4666, September 2006 (TXT).


 TOC 

Author's Address

  Barry Nagelberg
  Adax, Inc.
  520 Fellowship Rd. Suite C-304
  Mount Laurel, NJ 08054
  US
Phone:  +1 856 642 7757
Email:  barryn@adax.com


 TOC 

Full Copyright Statement

Intellectual Property