Subject: [Sigtran] Queries on M2PA

From: [email-masked]
Date: Wed, 3 Sep 2003 13:12:20 +0530

Hi ALL:

I have few queries related to M2PA. Please provide the responses to these.

>>>In case the link is In Service prior to LPO occuring, then shouldn' we
send Link Status Ready which replaces the FISU of MTP2? In Fig 8 of Q.703
(Fig 8, sheet 13 of 14), if LPO is only PO in the system; then Local
processor recovering results in FISU transmission. Another possibility is
to send both Local Processor Recovered followed by Link Status Ready as
link status messages to the peer. If not, then is the use of Link Status
ready restricted to mark the end of the proving period.

>>>Tom, you have indicated in your posting (dated Aug 29) that in case of
LPO keep sending the messages received from MTP3. But isn't receiving any
messages from MTP3 indicative of end of Processor Outage or are we talking
of peer node here?

>>>In case peer is experiencing PO, should we block sending any data to
peer or rely on peer node to buffer the data and acknowledge it when
Processor recovers? 'If LPO exists then we must buffer the user data
received.' Is this valid for the data that peer might have sent before PO
was received at peer node i.e. should peer stop sending Data after it
received PO from peer?

>>>If busy is received from peer during proving, should the link be moved
to OOS state? Fig 8 of Q.703 does not contain any such State-Event
combination. Do we rule out any such event in proving state for M2PA as
well.
Also, in MTP2 if Proving fails due to Error (say checksum), max 5 proving
attempts are made (Q.703, Fig 9, sheet 6 of 6). Do we have similar
mechanism for M2PA or we move the link to OOS on failure of proving after
the first attempt itself?

>>>If Node A is in receive congestion, shouldn't it stop ACKing the
messages received from peer? If not, do we assume that User Layer will take
care of controlling the 'receive congestion' at the peer node?

Thanks

Best Regards
Rohit Raghav
Hughes Software Systems
Plot 31, Electronic City
Sector 18
Gurgaon 122015
Haryana, India

Tel: +91-124-2346666/2455555 Extn:3254
Fax: +91-124-2455100/2455101
web : www.hssworld.com
e-mail : [email-masked]

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Sep 2003 02:48:13 -0600

Rohit,

[email-masked] wrote:                          (Wed, 03 Sep 2003 13:12:20)
> ready restricted to mark the end of the proving period.

Link Status Processor Recovered replaces the FISU.

> messages from MTP3 indicative of end of Processor Outage or are we talking

The messages already received from MTP3 that have not been transmitted yet.
Q.703 stops transmitting because it must send continuous SIPO.  M2PA continues
to send after sending Local Processor Outage until the TB/RTB drains.

> was received at peer node i.e. should peer stop sending Data after it

Q.703 experiencing PO will discard received messages and not acknowledge them.
When PO recovers, retransmission at the peer will deliver any discarded
messages.  M2PA does not retransmit.  Therefore, during PO received messages
should be buffered, and not acknowledged.  The peer should stop sending, just
as it stops sending in the Q.703 case, however, there is a delay between the
PO event and when the peer receives LS Processor Outage.  During this time,
the peer might send some messages.

> combination. Do we rule out any such event in proving state for M2PA as

Busy is a condition that applies to Data messages (MSUs) only and is not
applicable to Link Status Proving messages (or SIN SIE for that matter).
Busy indicates to use longer delay timers for acknowledgement.  During proving
no Data messages have been sent and T7 cannot be running.

Busy and Busy Ended should be ignored in the Proving state.  This is evidenced
by Q.781/Test 2.3 (see draft-bidulock-sigtran-m2pa-test-04.txt 3.2.3).

> the first attempt itself?

Use the same procedures.  Note that how many times one end reattempts proving
is of no moment to the peer.  If the peer sends Link Status Ready after
successful proving, if the end reattempting does not sent Link Status Ready
also within T1 then the link will be placed out of service.  You will find in
Q.703 that T1 is normally set to a little larger than 5 times T4 to allow the
peer 5 full proving intervals before abandonning the alignment attempt.  See
test case 3.1.4 in draft-bidulock-sigtran-m2pa-test-04.txt.  Although this
test case does not indicate that one side is reattempting proving, it is
allowed to within the T1 interval.

> care of controlling the 'receive congestion' at the peer node?

In Q.703 there are two levels of receive congestion: CongestionAccept and
CongestionDiscard.   When in CongestionAccept the receiver continues to
acknowledge received messages and continues to buffer them for delivery to the
MTP3.  Although the mechanism is implementation dependent, the queue depth (RB
occupancy) is typically used as the mechanism.  In general, an MTP2
implementation should not acknowledge an MSU to the peer unless it has a high
degree of confidence that the MSU can be delivered to MTP3.  This reduces the
number of messages that may be lost due to a failure in the deliver mechanism
between MTP2 and MTP3.  Typically only several messages are queued.

During CongestionAccept, SIB is sent, but message are acknowledged.  If
congesiton increases to the point of CongestionDiscard, SIB is continued, and
new received messages are discarded (and not acknowledged).

M2PA should send Link Status Busy when it encounters the first type of
congestion (CongestionAccept) and should continue to acknowledge messages.
When M2PA reaches CongestionDiscard, it should stop acknowledging messages.
If M2PA does not have sufficient room to buffer new received messages
internally, it should stop servicing the receive side of the SCTP association.
This will result in the eventual closing of arwnd and the SCTP at the peer
will stop sending messages.  If the link fails, the peer M2PA has a copy of
all unacknolwedged messages and they can be retransmitted on another link
after the normal buffer updating procedures of MTP3.  If the busy condition
falls back to CongestionAccept, then the M2PA can start servicing SCTP
received and acknowledging messages.  When the busy condition goes back to
normal, the M2PA sends Link Status Busy Ended.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/