Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Tue, 8 Oct 2002 15:52:35 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2002 3:19 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> M2PA needs to support more than just MTP3 function 
> transparently: it must
> also support the SS7 MIB and provide some basis for 
> administration of its
> protocol parameters.  The SS7 MIB contains T7.  Network engineers are
> familiar with its effect.  No matter how you want to implement it, it
> should be viewed externally as a timer with a settable value 
> T7.  We all
> agreed that there should be timer alignment between M2PA and 
> MTP2.  You see,
> M2PA's purpose is to "transport" MTP2, not to reinvent it.
[TOLGA]If to be as much similar to MTP2 is so important, then it could be
also better to stick with T7 as it is in MTP2, afterall it causes also
problems there, based on your previous messages. And one is free also for
MTP2 case, to implement some mechanism to deal with that possible problem
-for example like you described in one of your previous messages-, if one
wants to do so, there is nothing preventive in the protocol to do this.
I also would say M2PA's purpose is to transport MTP3 traffic, not MTP2
itself.
Having said all of that, I still think the sentence you suggested is not
restrictive.
> 
> --brian
> 
> Tolga Asveren wrote:                                         
> (Tue, 08 Oct 2002 09:02:47)
> > [TOLGA] For that paragraph I both agree and disagree. I 
> disagree that M2PA
> > precludes per-message approach. To handle this case, why 
> should there be a
> > protocol timer? Meeting MTP3 performance requirements is 
> responsibility of
> > each node itself, for example I can have an implementation 
> dependent timer
> > to do this, should it be called T7? Or I can say, my 
> implementation does not
> > care about that problem and relies on the quality of IP 
> network. So, for
> > example why not just say that M2PA SHOULD meet MTP3 performance
> > requirements? How one achieves this is belongs more to 
> implementation in my
> > view. But I agree that the sentence as you suggest is also 
> not restrictive. 
> >  
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 14:04:20 -0600

Tolga,

Tolga Asveren wrote:                              (Tue, 08 Oct 2002 15:52:35)
> problems there, based on your previous messages.

You missed the point.  T7 does not cause problems for standard MTP2: only
if some fool introduces an artificial, a non-compliant, delay into a link.

On the other hand, M2PA's variable delay is expected and must be properly
accomodated.  To do that, using MTP2's T7 reset procedures will not work well
for M2PA.  A per-message approach is neccessary to accomplish that (where it
is not necessary for MTP2).

> And one is free also for MTP2 case, to implement some mechanism to deal with
> that possible problem -for example like you described in one of your
> previous messages-, if one wants to do so, there is nothing preventive in
> the protocol to do this.

Huh?  You shouldn't try to read an ITU-T document like an IETF document.
It is certainly not the place of Q.703 to attempt to accomodate variable
or excessive link delays artificially introduced into terrestrial
transmission facilities.

--brian