Subject: RE: [Sigtran] M2PA Draft 7 comment

From: [email-masked]
Date: Wed, 29 Jan 2003 12:43:25 -0000

Ok - thanks Brian.

Regards,

Karen

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 29 January 2003 10:07
To: King,KD,Karen,DEN8 KINGKD R
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] M2PA Draft 7 comment

Karen,

[email-masked] wrote:
(Wed, 29 Jan 2003 09:51:13)
> 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?

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

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

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran