Subject: Re: draft-ietf-sigtran-m2ua-07.txt

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 1 Mar 2001 05:26:38 -0600

Ken,

I have discovered a problem in the M2UA draft with regards to proper
MTP Level 3 operation under changeover.  There are several problems as
follows:

-   The retrieval sections refer to the "retransmit queue" when the
    procedures apply to different buffers.  Retrieval applies to the
    updated RTB contents as well as "all messages not yet transmitted on
    the link".

    Flushing buffers with the State Request and STATUS_FLUSH_BUFFERS in
    section 3.3.1.5 must also flush SCTP transmit and receive queues of
    MSUs only.  Also, it must flush MTP2 RB as well as TB and RTB
    (similar to ANSI MTP2 behavior).

    During changeover when buffer updating is not performed
    (time-controlled or emergency), it is still necessary that the MTP3
    implementation divert all messages not previously transmitted on the
    link.  This would include any MSU in the TB plus any MSUs in MGC
    SCTP transmit queues, retransmit queues, the SG SCTP receive queues,
    and the MTP2 transmit buffer.  These must also be retrieved even
    though buffer updating and retrieval (of the RTB) is not performed.

    This could perhaps be accomplished by using a retrieval request with
    the value of ACTION_RTRV_MSGS but with no seq_num, or possibly
    preceded by a ACTION_DROP_MSGS.

-   While attempting normal changeover the case where a failure to
    retrieve buffers and the case of an unreasonable FSNC, are
    different.  In the case of an unreasonable FSNC, the implementation
    should still provide all of the messages indicated above, but not
    provide the contents of the RTB.  There is no mechanism for
    indicating this partial success.

-   Because time-controlled changeover can be initiated on a signalling
    link in response to processor outage or management inhibiting of the
    link (requiring the retrieval of TB) but then change to normal
    changeover upon receipt of a changeover-order, some MTP3
    implementations may require two separate retrieval actions: one for
    the TB and SCTP Tx queue contents, and another later for RTB
    updating and retrieval if necessary.

    This is not usually a problem in existing implementation because the
    MTP3 normally has direct access to MTP2 transmit and receive
    buffers.

    This would mean that a ACTION_DROP_MSGS followed by a
    ACTION_RTRV_MSGS to retrieve the TB contents will destroy the RTB
    contents for later conversion from time-controlled changeover to
    normal changeover with buffer updating.

    Again, you don't normally see a primitive for TB retrieval in SS7
    because the MTP3 has direct access to the TB (but not necessarily
    the RTB).  Also conversion from time-controlled changeover to buffer
    updating is left "implementation dependent" in Q.703 and not
    properly addressed in the SDLs.

-   For temporary loss of the association causing LPO (less than T1), it
    may be necessary to retrieve MSUs from SCTP queues on the failed
    association and place them on the new one at both ends of the
    association.

    However, for longer outages, it will be necessary to flush these in
    response to the STATUS_FLUSH_BUFFERS State Request.  Only MTP3 can
    tell when buffers should be cleared.  Therefore, it will be
    necessary for the SG implementation to place MSUs from the failed
    SCTP association received queues into its transmit buffer and place
    MSUs from the failed SCTP associated transmit queues into its
    receive buffer (all in order) and await instructions after the
    establishment of the new association before placing MSUs onto the
    newly formed association.  This will allow MTP3 to send a State
    Request STATUS_FLUSH_BUFFERS before issuing a State Request
    STATUS_LPO_CLEAR when the outage is of long term, or or simply the
    STATUS_LPO_CLEAR if the outage has been transitory.

    This has complications for any sections (such as 1.5.5) where it is
    expected that MTP2 gets some Local Processor Recovered indication
    from other than MTP3, because MTP3 needs to decide whether to do a
    STATUS_FLUSH_BUFFERS first.

    MTP2 must wait until it gets a STATUS_LPO_CLEAR before exiting the
    LPO state and cannot autonomously exit LPO.

    Furthermore, for the MTP3 time-controlled changeover procedure in
    response to local processor outage to meet its goals, MTP2 cannot
    autonomously enter LPO state (unless it can be guaranteed that MTP3
    enters LPO at the same time).  Otherwise, time-controlled changeover
    in response to LPO will not begin at MTP3 and several bad things
    will happen: 1) MTP3 will continue sending MSUs to an MTP2 that may
    never get them, increasing message loss; 2) the time-controlled
    procedure may never begin resulting in messages being sent into a
    black hole; 3) MTP3 will not know to send a STATUS_FLUSH_BUFFERS if
    the MTP2 recovers and aged messages will be delivered.

With these considerations, I suggest the following changes:

>     1.5.5  Flow Control / Congestion
>     
>     It is possible for the M2UA layer to be informed of IP network congestion
>     onset and abatement by means of an implementation-dependent function  
>     (i.e. an indication from the SCTP).  
>     
>     If the M2UA layer on the SG receives an IP network congestion onset
>     indication, the M2UA layer SHOULD inform the MTP2 layer of a Local
>     Processor Outage.  When the M2UA layer on the SG receives an IP network
>   ! congestion abate indication, the MTP2 MUST await a State Request
>   ! STATUS_LPO_CLEAR from the M2UA layer before considering the Local
>   ! Processor Outage condition cleared.
>     
>     If the M2UA layer on the ASP receives an IP network congestion onset
>     indication, the M2UA layer SHOULD inform the MTP3 layer of a Local
>   ! Processor Outage.  This indication MUST be coincident with the M2UA
>   ! layer on the SG informing the MTP2 of a Local Processor Outage.  When the
>   ! M2UA layer on the ASP receives an IP network congestion abate
>   ! indication, the M2UA layer SHOULD inform the MTP3 layer of a Local
>   ! Processor Outage condition has been cleared.
  
...
  
>     3.3.1.8  Retrieval (Request, Confirm)
>     
>     The MTP2 Retrieval Request message is used during the MTP Level 3
>     changeover procedure to request the BSN, to retrieve PDUs from the
>   ! transmit and retransmit queues or to flush PDUs from the retransmit
>   ! queue.
  
...

>     The valid values for Action are shown in the following table.
>     
>             Define         Value       Description
>        ACTION_RTRV_BSN      0x1     Retrieve the backward sequence number
>        ACTION_RTRV_MSGS     0x2     Retrieve the PDUs from the retransmit
>                                     queue
>        ACTION_DROP_MSGS     0x3     Drop the PDUs in the retransmit queue
>   +    ACTION_RTRV_TRANS    0x4     Retrieve the PDUS from the transmit
>   +                                 queue
>     
>     In the Retrieval Request message, the seq_num field SHOULD be ignored if 
>   ! the Action field is ACTION_RTRV_BSN, ACTION_DROP_MSGS or
>   ! ACTION_RTRV_TRANS.  The seq_num field contains the Forward Sequence
>   ! Number (FSN) of the far end if the Action is ACTION_RTRV_MSGS.
>     
>     When the Signaling Gateway sends a Retrieval Confirm to this request,
>     it echos the action and puts the Backward Sequence Number (BSN) in the 
>     seq_num field if the action was ACTION_RTRV_BSN.  If there is a failure 
>     in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff).  
>     For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of
>     of seq_num will be set to zero for success or -1 (0xffffffff) for failure.
>     A failure means that the buffers could not be retrieved.  For a Retrieval
>     Confirm with an Action of ACTION_DROP_MSGS, the value received in the 
>     seq_num field will be ignored.
>     
>     3.3.1.9  Retrieval Indication
>     
>     The Retrieval Indication message is sent by the Signaling Gateway
>   ! with a PDU from the transmit or the retransmit queue.  The Retrieval
>   ! Indication message does not contain the Action or seq_num fields, just a
>   ! MTP3 Protocol Data Unit (PDU) from the transmit or retransmit queue.
>     
>     The M2UA implementation MAY consider the use of the bundling feature
>     of SCTP for Retrieval Indication messages.
>     
>         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 (0x14)          |            Length             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     
>   !    |             PDU from transmit or retransmit queue             |
>     
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     
>     
>     3.3.1.10  Retrieval Complete Indication
>     
>     The MTP2 Retrieval Complete Indication message is exactly the same as
>     the MTP2 Retrieval Indication message except that it also indicates that
>   ! it contains the last PDU from the transmit or retransmit queue.
  
-- 
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 ¦

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 1 Mar 2001 05:30:27 -0600

Ken,

Oh, I suggest this minor change for STATUS_FLUSH_BUFFERS to make it
clear that receive queues are to be flushed as well:

>        STATUS_EMER_CLEAR       0x3      Request normal alignment (cancel
>                                         emergency) procedure
>   !    STATUS_FLUSH_BUFFERS    0x4      Flush receive, transmit and
>   !                                     retransmit queues
>        STATUS_CONTINUE         0x5      Continue
>        STATUS_CONG_ACCEPT      0x6      Congestion accept
>        STATUS_CONG_DISCARD     0x7      Congestion discard

...

>        STATUS_EMER_CLEAR       0x3      Request normal alignment (cancel
>                                         emergency) procedure
>   !    STATUS_FLUSH_BUFFERS    0x4      Flush receive, transmit and
>   !                                     retransmit queues
>        STATUS_CONTINUE         0x5      Continue
>        STATUS_CONG_ACCEPT      0x6      Congestion accept
>        STATUS_CONG_DISCARD     0x7      Congestion discard