Subject: Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer identifiers

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 May 2002 11:04:50 -0500

Jeffrey,

Take a look at Q.704.  It defines additional timers on a per-link basis
such as T12 which would conflict with your implementation-depedent timer
labels.

Also, where is there an implementation-dependent timer which is not simply
a rate?  Rates are not timers (there are not started and stopped under
protocol control).

--brian

[email-masked] wrote:                    (Mon, 13 May 2002 08:42:40)
> 
> Hello Brian,
> 
> We're in general agreement, though there are a couple of details remaining.
> Your initial comment about Q.703 prompted me to go refresh my memory
> using the latest version of that recommendation.
> 
> When I refer to protocol "timers", what I really mean is protocol timeout
> values,
> and not necessarily a particular implementation in enforcing those
> timeouts.
> This jives with Q.703, which in 7.3 reads "Timers defined in this
> Recommendation
> are absolute time values".
> 
> The "timers" presented in Q.703 are:
> T1 -- Alignment Ready Timer (this appears to match the current M2PA T3 to
> some degree)
> T2 -- Not Aligned Timer (this appears to match the current M2PA T1 to some
> degree)
> T3 -- Aligned Timer (this does not appear to have an M2PA equivalent)
> T4N, T4E -- Proving Period Timer(s) (this appears to match the current M2PA
> T2)
> T5 -- Sending Status Indication Busy Timer (this would be my Busy Rate
> timer)
> T6 -- Remote Congestion Timer (matches M2PA T6)
> T7 -- Excessive Delay of ACK Timer (no M2PA equivalent...yet... could use
> one)
> 
> I propose that M2PA be updated to conform to these definitions where
> possible and
> reserve the T1-T10 block of timer identifiers. This would provide for T11+
> to be
> defined for implementation-dependent purposes (such as my Ready-Rate and
> Processor-Outage-Rate timeouts).
> 
> The underlying issue I am trying to address with all of this is to minimize
> the churn
> in timeout administration for my implementation as M2PA evolves.
> 
> Regards,
> 
> Jeff
> 
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 05/10/2002 06:32:39 PM
> 
> Please respond to [email-masked]
> 
> To:   [email-masked]
> cc:   [email-masked]
> Subject:  Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer
>       identifiers
> 
> 
> Jeffrey,
> 
> To avoid confusion with Q.704 timers, it might be advisable to
> name M2PA timers that do correspond to a Q.703/704 timer with
> "T1, etc," M2PA timers that do not correspond to a Q.703/704
> timer with a name such as "T-ack," and implementation timers
> with names such as "T-proving-rate".
> 
> Come to think of it, all the implementation timers in your
> list describe a "rate" and not a timer at all.  An interval
> timer is only one way of implementing a "rate".  Another
> approach, such as for proving, would be to send P proving
> messages to SCTP and wait an overall interval T-P for all
> proving messages to be acknowledged received by SCTP.  It
> would say that, given the implementation specifics of these
> rates, that naming implementation-dependent timers is of
> little use.
> 
> Then all that needs to be done is rename T2 Proving to T4 and
> describe these implementation-dependent things as
> implementation-depenent rates rather than timers.
> 
> If you look at the conformance test suite, you will see that
> there is value in describing Q.703 timers T2, T3 and T7 as
> they make the state machine more robust and more compatible
> with Q.703.
> 
> --brian
> 
> [email-masked] wrote:                    (Fri, 10 May 2002
> 16:57:54)
> >
> > Hello Brian,
> >
> > Having M2PA timers correspond to Q.703 is a good idea.
> >
> > That would mean that the current M2PA timer, T2 Proving, ought to be T4,
> as
> > per Q.703....
> > Or am I missing something?
> >
> > This would also suggest that M2PA should reserve timers T2, T5, and T7 in
> > addition to
> > the current requirements for T1, T3, and T6.
> >
> > Perhaps implementation-dependent timers should start at T11...
> >
> > Regards,
> >
> > Jeff
> >
> >
> >
> >
> >
> >
> >
> > "Brian F. G. Bidulock" <[email-masked]> on 05/10/2002 04:16:38 PM
> >
> > Please respond to [email-masked]
> >
> > To:   [email-masked]
> > cc:   [email-masked]
> > Subject:  Re: [Sigtran] (M2PA) Please standardize M2PA protocol timer
> >       identifiers
> >
> >
> > Jeffrey,
> >
> > Timer identifiers should correspond to Q.703 where possible.
> >
> > --brian
> >
> > [email-masked] wrote:                    (Fri, 10 May 2002
> > 15:13:22)
> > > Hello All,
> > >
> > > The M2PA v5 draft refers to four specific timer identifiers (T1, T2,
> T3,
> > > and T6) and assigns
> > > specific functional requirements on them. The draft also discusses at
> > least
> > > four more
> > > implementation-dependent timers, such as the 'status_interval' timer.
> > >
> > > I think it would be a good idea for the M2PA specification to reserve a
> > > block of timer
> > > identifiers (T1, T2,..., T10) for timers having required functionality
> > and
> > > assign a starting
> > > timer identifier (e.g. T11)  for implementation-dependent timers (such
> as
> > > Proving Rate).
> > >
> > > This would help reduce confusion as to the purpose of a given protocol
> > > timer between
> > > different M2PA implementations.
> > >
> > > Having said that,  I would like to see the described
> > > implementation-dependent timers identified in
> > > the draft as follows:
> > >      T4 - proving rate timer (interval between sending LSP messages
> > during
> > > PROVING)
> > >      T5 - ready rate timer (interval between sending LSR messages
> during
> > > READY-ALIGNED)
> > >      T7 - processor outage rate timer (interval between sending LSPO
> > > messages during INS)
> > >      T8 - busy rate timer (interval between sending LSB messages during
> > > INS)
> > >
> > > Regards,
> > >
> > > Jeff
> > >
> > >
> > > _______________________________________________
> > > 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/
> 
> 
> 
> 
> 

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

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

---

From: [email-masked]
Date: Mon, 13 May 2002 08:42:40 -0400

Hello Brian,

Regards,

Jeff

Jeffrey,

--brian

as
T3,
as
during

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