The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <AFC76835727DD211A7C20008C71EAF1E01146047@MCHH230E>, Heiles Juergen 
writes:
> Curtis
> 
> 	>Then again, this is second hand, so I could be completely wrong. This 
> is not a measurement I've made myself and the SONET equipment is not somethin
> g I'm familiar with .... 
> 
> you are completely wrong and I suggest you better make measurments and get fa
> miliar with SONET before making such statements.. SONET/SDH equipment will no
> t shut down/drop connections. Today SONET connections are permanent connectio
> ns setup via the management system. An automatic drop of a conneciton as it i
> s the case for switched connections will not occur. What you will see is the 
> insertion of AIS (alarm indication signal) after the detection of an defect. 
> But as soon as the defect is gone the AIS is removed and the connection is ru
> nning again. AIS is nothing harmful as due to the defect the connection is in
> terupted in any case. Furthermore the AIS avoids downstream alarms (alarm sto
> rms).

There was a similar problem encounterred when sending a packet over a
POS link with the old short scrambling pattern in the body of the
packet.  My understanding was that there was a small chance that
alignment with the scrambler could take a SONET link out of service,
then take the protect out of service and manual intervention was
required to bring them back into service.  That is second hand too but
someone from an ISP stood up at an IETF meeting and claimed to have
tried it with spectacular (though not desireable) results and the
statement wasn't challenged (and I know the person and he is a
reliable source).  This statement was made in response to the
assertion that there was no need to change the scrambler pattern
length.

It was definitely not Siemen SONET gear (but you knew that) and AFAIK
it is not called for in the SONET specs but I've been told that some
other gear does exhibit this behaviour.  US carriers in particular
have lots of it which creates a requirement for MPLS restoration that
must be met for some but not all networks and applications.

My understanding is that this behavior is observed in a particular
implementation, the same one that had the problem with DoS attack
based on the short scrambler pattern.  This SONET gear could not be
configured to bring the segment back into service without intervention
which was key to making the DoS attack effective.  Note: The DoS
problem was solved by lengthenning the POS scrambler pattern to be
much longer than the MTU, requiring no change to the SONET gear.

In pointing out that this is second hand I am noting that it is
possible that the problematic implementation might have been upgraded
since these two problems have been encountered and could allow a
configuration option to change this behaviour.  AFAIK this is not the
case but I'd be pleased to hear that it has been corrected.  We can
continue this discussion offline if you like.

> What could be of concern are the following points. I talk about a server laye
> r for a SONET/SDH network  (e.g. an Optical Network) providing protection/res
> toration:
> 
> Stacked protection/restoration:
> If you use protection/restoration at an optical network layer (server) and a 
> SONET/SDH network layer (client) the server layer switching times should be f
> aster than the client layer reaction times, so that the server layer does the
>  protection/restoration and the client layer doesn't react.

I'm aware of this and I mentioned it below.  See paragraph beginning
with OTOH below.

> Automatic power reduction/automatic laser shutdown APR/ALS
> APR is used for safety reasons in order to avoid harmful emission of laser li
> ght in case of a fiber cut. One implementation switches off the transmit lase
> r in case of loss of signal at the receiver. A restart action which is trigge
> red automatically in intervals of several seconds is required in order to tes
> t if the link is repaired. Normally the APR function can be switched off if n
> ot needed. The APR function needs some careful consideration in case of prote
> ction/restoration and automatic connection setup in all optical networks.

Thanks for the info.  I hadn't heard this.

> Regards
> 
> Juergen

Regards,

Curtis


> > -----Original Message-----
> > From:	Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org]
> > Sent:	Monday, April 09, 2001 4:37 AM
> > To:	Lazer, Monica A, NNAD
> > Cc:	'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf
> .org
> > Subject:	restoration time requirement (was Re: Last Call on RSVP Label A
> llocation for Backup Tunnels)
> > 
> > 
> > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>
> , "L
> > azer, Monica A, NNAD" writes:
> > > Voice switches will drop the connections after 2.5 seconds. A large numbe
> r
> > > of dropped calls will cause FCC reportable events, which is something tha
> t
> > > US carriers need to avoid. So restoration within this time frame is neede
> d
> > > for support of trunks carrying voice traffic.
> > > 
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > > 
> > > 908 234 8462
> > > mlazer@att.com
> > 
> > 
> > Monica,
> > 
> > We're off topic, so I changed the subject.
> > 
> > Thanks for providing the 2.5 second figure.
> > 
> > I've heard carrier transport people grumble about SONET equipment
> > they'd be please to get rid of that will shut down even when used as
> > linear SONET with no protect path and as a result would require
> > <100msec restoration.  Since there is enough of this SONET gear, the
> > carriers can't really get rid of it although it will probably
> > disappear over time and so they will make fast restoration a
> > requirement of people they buy from.  To be safe, the request for
> > <50msec has been made.
> > 
> > If you are not blessed with such equipment or you are able to work
> > around it when doing VoIP, then you are among the fortunate.
> > 
> > Then again, this is second hand, so I could be completely wrong.  This
> > is not a measurement I've made myself and the SONET equipment is not
> > something I'm familiar with such that I could say with confidence that
> > it could not be configured to hold on longer or to not shut down at> 
> > all if there was no protect.
> >  
> > OTOH there are those who (claim to) want to configure SONET on some
> > links but not on others and don't want a fast restoration.  They want
> > to be assured that restoration will occur only after it is safe to
> > assume that SONET restoration is not available.
> > 
> > Curtis
>