[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: timing bounds for service restoration



I think the SONET APS timing is specified for a network of a specific
diameter. I would hope that this 10+50 ms time is the time for the "pop" to
NOT get noticed. ANSI T1X1 and Bellcore is probably the place to look for
the rationale for SONET if any.

I guess it might make sense to specify a sample network for the times the
design team has specified in section 5.4 of the draft. But then again it is
specified that these times are exclusive of signal propogation delay so
maybe a sample network might not be all that relevant.

Vik

-----Original Message-----
From: Jim Boyle [mailto:jimpb@nc.rr.com]
Sent: Monday, August 13, 2001 7:18 PM
To: Anantha, Vic
Cc: 'te-wg@ops.ietf.org'
Subject: re: timing bounds for service restoration



Does that hold for 4f-BLSR, and does switch in 4f-BLSR act as a
function of # nodes and diameter?  How does 10+50 ms apply to
practice?

And just where does that 10+50 ms come from, is that the time it takes for
"pop" to be noticed, the time it takes grandma to get mad and hangup?

I vote to make the requirement 40 ms, why shouldn't an intelligent
network with Gigs of Memory, Mips galore and baked silicon outperform
10 year old SONET technology?  But practically... what is the
difference between 140ms and 40 ms (correct answer is not 100 ms :)

regards,

Jim



On Mon, 13 Aug 2001, Anantha, Vic wrote:

> 1> In section 5.4 of draft-team-tewg-restore-hierarchy-00.txt certain
timing
> bounds are proposed for service restoration. I was wondering if the design
> team could give us a little more insight into how they arrived at these
> numbers. I am assuming that the restoration mechanisms were broken up into
> smaller chunks and an educated guesses were made about their timings.
>
> 2> Section 5.3 mentions the application requirements for restoration. I
was
> wondering if somebody could point me out to documents that specify a 140
ms
> to 2 sec call cutoff time. This seems to be a longer time than mandated by
> the 10+50 ms APS time in SONET, which seems to be a de-facto standard in
the
> industry.
>
> Vik
>