RE: Last Call on RSVP Label Allocation for Backup Tunnels

["Mak, L (Leen)" <lmak@lucent.com>]

There are (used to be?) voice switches in the PSTN which
start dropping calls within 100 ms after loosing a trunk. 
This was at least one of the reasons for the 50 ms figure 
found in SDH specs. If the trunk is carried on an STM16, 
you could loose >32k calls because of a cable cut. Some 
operators do not like that.

Leen Mak

> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:mlazer@att.com]
> Sent: Friday, April 06, 2001 14:02
> To: 'neil.2.harrison@bt.com'; raszuk@cisco.com
> Cc: mpls@UU.NET; ccamp@ops.ietf.org
> Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
> 
> 
> Voice switches will drop the connections after 2.5 seconds. A 
> large number
> of dropped calls will cause FCC reportable events, which is 
> something that
> US carriers need to avoid. So restoration within this time 
> frame is needed
> for support of trunks carrying voice traffic.
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> mlazer@att.com
> 
> 
> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Monday, April 02, 2001 5:19 AM
> To: raszuk@cisco.com
> Cc: mpls@UU.NET; ccamp@ops.ietf.org
> Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels
> 
> Robert Raszuk [mailto:raszuk@cisco.com] wrote 01 April 2001 09:02
> > Giles,
> >
> > > > For the user-plane, the failure modes which must be
> > considered/defined are:
> > > > -       simple below MPLS fabric server layer 
> connectivity breaks;
> > > > -       simple within MPLS fabric connectivity breaks (at
> > or below the LSP
> > > > level considered);
> > >
> > > Both of these will be detected by the RSVP signalling, won't they?
> >
> > Sure but the question is when ?
> >
> > Do you think that RSVP Error/Tear msgs will travel
> > immediately - case of
> > link failure or are you proposing to run RSVP refresh in 
> the interval
> > less then 1 sec - to detect the case of node failure ? The
> > point is that
> > this draft is not about detection, but about backup LSP setup
> > and label
> > allocation under the __local__ protection scheme. So let's 
> talk on the
> > subject here.
> >
> > If one questions the use of local protection all together
> > please specify
> > how else you will achive the same results of even less then 1
> > sec end to
> > end traffic disruption with end to end protection under both
> > link & node
> > failures for the TE- LSP ?
> NH=> Fair point Robert.....but it still leaves me wondering:
> 1       Why do we need such fast action......voice surely 
> does not need few
> 10s ms restoration, 1-3s would be fine I feel sure (for the 
> relatively rare
> case of failure......unless, perhaps, one expects such 
> failures to occur on
> a very frequent basis)?
> BTW- I suspect the biggest source of 'disruptions' will be 
> planned-works by
> operators at L1, ie pre-meditiated re-routing of 
> traffic.....so some care
> should be taken that such actions don't invoke unecessary 
> actions in higher
> layers.
> 2       Where are the failures referenced specified?  Have 
> Cisco their own
> specifications for this?  We would really like to see these 
> specified in
> some standard manner.
> 
> thanks/regards, neil
>