Subject: [Sigtran] M3UA-v02 Last Call Comment: ASP States and SE or DE IPSP

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 May 2004 23:07:06 -0600

Although it is stated that section 4.3.1 describes the SE IPSP model,
this is not the case.  The offending passages are:

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

and Section 4.3.1.

The IPSP SE and DE models (that were discussed on the list in great detail)
are as follows:

Single Ended (SE):

          IPSP A                           IPSP B     
        ___________                      ___________  
       |           |                    |           | 
       |  _______  |                    |  _______  | 
       | |       | |                    | |       | | 
       | | ASPF  | |                    | | ASPF  | | 
       | |_______| |                    | |_______| | 
       |     |     |    Association     |   |       | 
       |     |   __|____________________|__/        | 
       |     |  /  |                    |           | 
       |  ___|_|_  |                    |  _______  | 
       | |       | |                    | |       | | 
       | | SGPF  | |                    | | SGPF  | | 
       | |_______| |                    | |_______| | 
       |           |                    |           | 
       |___________|                    |___________| 

In the SE model, one IPSP provides an SGPF (SGP Function) and the other an
ASPF (ASP Function).  These two IPSP communicate just as does an ASP and SGP,
where one IPSP follows the SGP-side of the procedures and the other IPSP
follows the ASP-side of the procedures.  No half-traffic flows may result.
IPSP B, performing the ASPF, is able to dynamically register RKs with IPSP A
performing the SGPF.

This makes the new statements in Section 4.3 and 4.3.1 incorrect.  Offending
passages are:

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

SE model supports dynamic RK configuration.  The last line is incorrect.

|4.3.1 ASP States
|
|   The state of each remote ASP/IPSP, in each AS that it is configured
|   to operate, is maintained in the peer M3UA layer (i.e. in the SGP or
|   peer IPSP, respectively). The state of a particular ASP/IPSP in a
|   particular AS changes due to events. The events include:
|
|   * Reception of messages from the peer M3UA layer at the ASP/IPSP;
|   * Reception of some messages from the peer M3UA layer at other
|     ASPs/IPSPs in the AS (e.g., ASP Active message indicating
|     "Override");
|   * Reception of indications from the SCTP layer; or
|   * Local Management intervention.
|
|   The ASP/IPSP state transition diagram is shown in Figure 3.  The
|   possible states of an ASP/IPSP are:
|
|   ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable and/or
|   the related SCTP association is down.  Initially all ASPs/IPSPs will
|   be in this state. An ASP/IPSP in this state SHOULD NOT be sent any
|   M3UA messages, with the exception of Heartbeat, ASP Down Ack and
|   Error messages.
|
|   ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and
|   the related SCTP association is up) but application traffic is
|   stopped. In this state the ASP/IPSP SHOULD NOT be sent any DATA or
|   SSNM messages for the AS for which the ASP/IPSP is inactive.
|
|   ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and
|   application traffic is active (for a particular Routing Context or
|   set of Routing Contexts).

    ...

|   SCTP RI: The local SCTP layer's Restart indication to the upper layer
|   protocol (M3UA) on an SG.  The local SCTP will send this indication
|   when it detects a restart from the ASP's/IPSP's peer SCTP layer.
|
|              Figure 3: ASP State Transition Diagram, per AS
|
|                                      +--------------+
|                                      |              |
|               +----------------------|  ASP-ACTIVE  |
|               |        Other +-------|              |
|               |   IPSP in AS |       +--------------+
|               |    Overrides |           ^     |
|               |              |    ASPAC/ |     | ASPIA/
|               |              |[ASPAC-Ack]|     | [ASPIA-Ack]
|               |              |           |     v
|               |              |       +--------------+
|               |              |       |              |
|               |              +------>| ASP-INACTIVE |
|               |                      |              |
|               |                      +--------------+
|               |                          ^     |
|        ASPDN/ |                          |     | ASPDN /
|   [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
|     SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
|     SCTP RI   |                          |     | SCTP RI
|               |                          |     v
|               |                      +--------------+
|               |                      |              |
|               +--------------------->|   ASP-DOWN   |
|                                      |              |
|                                      +--------------+
|
|   The transitions in brackets are just valid for the IPSP SE model
|   communication while the rest are valid for both ASPs and IPSPs.

All of the above statements are only applicable for IPSP-A in the SE model.
There are *not* applicable to IPSP-B.  As such, they are incorrect, or at
best misleading.

All of the IPSP additions to section 4.3.1 should be struck and the situation,
instead, described properly in section 4.3.

Double Ended (DE):

          IPSP A                           IPSP B     
        ___________                      ___________  
       |           |                    |           | 
       |  _______  |                    |  _______  | 
       | |       | |                    | |       | | 
       | | ASPF  | |                    | | ASPF  | | 
       | |_______| |                    | |_______| | 
       |     | |   |    Association     |   | |     | 
       |     |  \__|_________ __________|__/  |     | 
       |     |   __|_________X__________|__   |     | 
       |     |  /  |                    |  \  |     | 
       |  ___|_|_  |                    |  _|_|___  | 
       | |       | |                    | |       | | 
       | | SGPF  | |                    | | SGPF  | | 
       | |_______| |                    | |_______| | 
       |           |                    |           | 
       |___________|                    |___________| 

In the DE model, both IPSPs provide both ASPF (ASP Function) and SGPF (SGP
Function).  Each IPSP implements *both* the ASP-side and SGP side of the
procedures.  Registration and activation is only for half a traffic flow,
therefore, half-traffic flows may result.  Twice the messaging and twice the
state information is required to acheive the same end as SE and this is why
DE is not recommended.

This makes the statements in Section 4.3 incorrect.  Offending passages are:

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

Incorrect.  Each IPSP must follow *both* sides of the ASP-SGP procedures.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran