Subject: [Sigtran] M3UAv02 Last Call Comment: AS State Transition Digaram

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 8 May 2004 00:12:15 -0600

By referencing state transitions of a performance metric 'n', the protocol
presumes to tell implementers how to meet performance requirements.  This is
against Section 6. of RFC 2119.  The protocol should not presume to tell
implementers how to meet performance requirements, but rather provide the
protocol elements necessary to do so.  The RFC acheived this goal, the new
draft does not.  The offending passage is:

|   Figure 5 shows an example AS state machine for the case where the
|   AS/ASP data is preconfigured and an 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 from ASP-DOWN to ASP-INACTIVE state.
|
|   IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN causing that
|   the all the ASPs are in ASP-DOWN state.
|
|   IA2AC: one ASP moves to ASP-ACTIVE, causing 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, causing the number of ASPs in ASP-ACTIVE drop below 1.
|
|   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 right after 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 turns
|   to another state different to ASP-ACTIVE, avoiding 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.  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.

The intent of the protocol was always to place ASPs in control of the
activity of the ASP and the AS.  If an implementation wants this behavior,
ASPs are welcome to send ASP Inactive upon receipt of NTFY("Insufficient
ASP Resources Active in AS").  If an SGP wishes to place an AS in the AS-DOWN
state autonomously, it may send unsolicited ASP Inactive Ack.

No changes were required to the RFC to implement this behavior; however, the
above offending passage makes it impossible to implement the former behavior.

There are no interoperability issues that have been addressed by the offending
passage.  The offending passage does not reduce "harm" to the IP network and,
as detailed, may indeed introduce harm to the SS7 network.

Please put the offending section back to the RFC text.

If you want to clarify how such an arrangement can be acheived with the RFC
procedures, I can provide several paragraphs.

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