Subject: RE: [Sigtran] M2PA Draft 7 comment

From: [email-masked]
Date: Wed, 29 Jan 2003 09:51:13 -0000

Hi Tom,

Thanks, this looks better. One further thought -  data retrieval is only
appropriate for a very short time (or else you end up with 'stale'
information). Do we need a note to cover this, or is this sufficiently
covered else where?

On my other comment - if the correct use of processor outage is well
understood (and the spec leaves no room for misunderstanding) then I'm
happy.

Regards,

Karen

-----Original Message-----
From: Tom George [mailto:[email-masked]]
Sent: 29 January 2003 00:34
Cc: [email-masked]
Subject: Re: [Sigtran] M2PA Draft 7 comment

Here is the new section after moving the paragraphs around (Karen's 1st
comment). I also moved the paragraph after, since they go together.

==========================================================
4.1.4 Processor Outage

A processor outage occurs when M2PA cannot transfer messages because
of a condition at a higher layer than M2PA.

When M2PA detects a local processor outage, it sends a Link Status
message to its peer with status Processor Outage. M2PA SHALL also
cease sending User Data messages to SCTP for transmission. M2PA SHALL
stop acknowledging received User Data messages.

M2PA MAY send additional Link Status Processor Outage messages as long
as there is a local processor outage and the link is in service. If
the link is out of service, M2PA SHOULD locally mark that it is in
local processor outage.

The peer M2PA, upon receiving the Link Status Processor Outage
message, SHALL report Remote Processor Outage to its MTP3. The peer
M2PA ceases sending User Data messages. M2PA stops the Remote
Congestion timer T6 (see section 4.1.5 Level 2 Flow Control) if it is
running, and timer T7, if it is running.

When the processor outage ceases, MTP3 sends a Local Processor
Recovered indication to M2PA. The local M2PA notifies its peer by
sending a Link Status message with status Processor Outage Ended. The
local M2PA SHALL resume receiving and transmitting messages.

[moved]
MTP3 may send a Flush Buffers or Continue command to M2PA as part of
its processor outage procedure (See section 4.2.4 Flush Buffers and
Continue). The use of Flush Buffers and Continue is specified in Q.703
[Q.703] and T1.111.3 [T1.111].

[moved]
Alternatively, MTP3 may perform data retrieval as part of a changeover
procedure.

If the peer is in the IN SERVICE state, it uses the Remote Processor
Recovered Indication to notify its MTP3 that the remote processor
outage condition has ceased.
==========================================================

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB7-SWPRO; Plano TX 75075-5813  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Jan 2003 03:07:06 -0700

Karen,

[email-masked] wrote:                                                    (Wed, 29 Jan 2003 09:51:13)
> information). Do we need a note to cover this, or is this sufficiently

Handling of stale information in retrieval buffers is handled by normal MTP
Level 3 procedures (buffer flushing).  Level 2 keeps data for retrieval until
it is either retrieved by Level 3 or it is told to flush such information by
Level 3.  Addressing Level 3 procedures is out of scope for M2PA.  It is
sufficient that M2PA provides the same upper boundary to MTP Level 3 as is
provided by a normal signalling link.  This includes retrieval_requiest_and-
_fsnc and flush_buffers, resume, clear_rtb signals.

--brian

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

---

From: Tom George <[email-masked]>
Date: Wed, 29 Jan 2003 14:27:57 -0600

I agree that it would be out of scope to specify how MTP3 must use flush
or retrieve data. 

The proc outage reminded me of an old question. In ATM links (Q.2140),
there is no processor outage procedure as in Q.703. The link is just
failed when there is a "proc outage". Does anyone know why there is no
Q.703-like proc outage procedure in Q.2140?

tomG.

> > understood (and the spec leaves no room for misunderstanding) then I'm
  [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Jan 2003 14:16:20 -0700

Tom,

Becauwe for SSCOP the "processor" is normally the ATM cell processor
as well.  Also, MTP3b does not necessarily incur a cost for realigning
a link (because proving can be skipped, and unlike M2PA, there is no
slow-start to surmount).  So, for Q.2140 there is little difference
between a processor outage and out-of-service state.  It does mean
that asserting processor outage while performing network management
(which is provided in Q.704) cannot be properly used for MTP3b links.

--brian

Tom George wrote:                                                                      (Wed, 29 Jan 2003 14:27:57)