M2UA Implementor's Guide

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

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.

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

1. Introduction

1.1. Terminology

1.2. Requirements Language

2. Corrections to RFC3331

2.1. n+k redundancy

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.

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

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.

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.

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.

2.2. Messages and Streams

2.2.1. Description of the problem

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

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

2.2.3. Solution description

2.3. Parameter Containing Subparameters with Padding Bytes

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.

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

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.

2.4. Multiple Parameters of the Same Type in a Message

2.4.1. Description of the problem

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

2.4.2. Text changes to the document

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

2.4.3. Solution description

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

2.5. How to indicate that Dynamic Registration is not supported

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.

2.5.2. Text changes to the document

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

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.

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

2.6.1. Description of the problem

2.6.2. Text changes to the document

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

2.6.3. Solution description

2.7. Need additional error code

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.

2.7.2. Text changes to the document

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.

2.7.3. Solution description

2.8. Notify(ASP-Failure) usage clarification

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?

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.

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.

2.9. Alignment of ASP Active message with ASP Inactive message

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.

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:

2.9.3. Solution description

2.10. Response to an ASPIA message

2.10.1. Description of the problem

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.

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.

2.11. NOTIFY messages are missing in Examples section

2.11.1. Description of the problem

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

2.11.3. Solution description

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

2.12. Error handling in the Retrieval Confirm message for ACTION_RTRV_BSN

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.

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.

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

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

2.12.3. Solution description

2.13. Error handling in the Retrieval Confirm message for ACTION_RTRV_MSGS

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.

2.13.2. Text changes to the document


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)


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)

2.13.3. Solution description

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.

4. IANA Considerations

5. Security Considerations

6. References

6.1. Normative References

6.2. Informative References

Author's Address

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

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

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

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

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

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

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

Status of this Memo