Subject: RE: [Sigtran] M2PA Draft 7 comment

From: [email-masked]
Date: Tue, 28 Jan 2003 11:06:16 -0000

Brian,

Good you're happy with the first comment.

OK - I understand your point that no one should think this behaviour would
be appropriate and, at the end of the day, we can't spec out everything a
poor/incorrect implementation 'might' do. I do seem to remember some emails
a while ago that mentioned processor outage and congestion in the same
sentence. I therefore get concerned that some do not understand its correct
use.

Regards,

Karen

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

karen.d.king,

[email-masked] wrote:
(Tue, 28 Jan 2003 08:53:34)
> Brian,
> 
> I feel that my first comment is a minor editorial change that clarifies
the
> behaviour needed.

I don't have a problem with the first comment.

> 
> As for the last point, yes, you'd hope this was obvious, but for those
with
> less experience of SS7 functionality, it's an important clarification of
> behaviour that can easily be overlooked. I feel the addition of a note on
> this would make clear the intended use of processor outage, without
> detracting from the 'correct' specification of the behaviour.

How would anyone think to use a Level 2 procedure to perform a Level 3
function is beyond me.  If the reader is both that bold and ignorant
there will be no stopping them.  There are some 20 or so other Level 3
procedures for which processor outage cannot be used: are we to list
all of those too?

--brian

> 
> Regards,
> 
> Karen
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 24 January 2003 21:28
> To: King,KD,Karen,DEN8 KINGKD R
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA Draft 7 comment
> 
> 
> karen.d.king,
> 
> [email-masked] wrote:
> (Fri, 24 Jan 2003 14:10:33)
> > Hi,
> > 
> > I still have the comments, from draft 5, on the use of processor outage
> > (section 4.1.4).
> > 
> > When processor outage ceases, the buffers need to be flushed. Therefore
> > please can you move the paragraph "MTP3 may send Flush Buffers or
> > Continue......."  to after the paragraph starting, "When processor
outage
> > ceases....".
> > 
> > Please could you also add a statement that processor outage should not
be
> > used to cover the situations when MTP3 or user parts are encountering
> > congestion, or where the user part is unavailable.
> 
> Doesn't this last point go without saying?
> 
> --brian
> 
> > 
> > Regards,
> > 
> > Karen
> > 
> > Karen King
> > BTexact Technologies
> > Orion Building MLB1/PP9
> > Adastral Park
> > Martlesham Heath
> > IPSWICH
> > Suffolk   IP5 3RE
> > 
> > Tel: (01473) 605389
> > [email-masked]
> > 
> > BTexact Technologies is a trademark of British Telecommunications plc
> > Registered office: 81 Newgate Street London EC1A 7AJ
> > Registered in England no. 1800000
> > 
> > This electronic message contains information from British
> Telecommunications
> > plc which may be privileged or confidential. The information is intended
> to
> > be for the use of the individual(s) or entity named above. If you are
not
> > the intended recipient be aware that any disclosure, copying,
distribution
> > or use of the contents of this information is prohibited. If you have
> > received this electronic message in error, please notify us by telephone
> or
> > email (to the numbers or address above) immediately.
> > Activity and use of British Telecommunications plc E-mail system is
> > monitored to secure its effective operation and for other lawful
business
> > purposes. Communications using this system will also be monitored and
may
> be
> > recorded to secure effective operation and for other lawful business
> > purposes.
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

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

---

From: Tom George <[email-masked]>
Date: Tue, 28 Jan 2003 18:22:14 -0600

Karen,

If it is the discussion I am thinking about, we were discussing what
would happen if a processor outage (a real one) happened while there
were congestion problems. I don't think anyone suggested that proc
outage be used improperly.

tomG.

> sentence. I therefore get concerned that some do not understand its correct
  [...]

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

---

From: Tom George <[email-masked]>
Date: Tue, 28 Jan 2003 18:34:06 -0600

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