RE: restoration time requirement (was Re: Last Call on RSVP Labe l Allocation for Backup Tunnels)

[andy.bd.reid@bt.com]

Curtis,

I not sure I understand what point your trying to make - other that make
implicit critcism of the body of engineers who put together SONET/SDH
technology.

Generally speaking, the specs and parameters that go to make up SONET/SDH
are there for good technical and economic reasons and, while some of these
may now be historical, it would seem to me more helpful to work from an
assumption that a set of good engineers were solving a real problem. I can
try and give you my understanding and memory of the problems that resulted
in some of the SONET/SDH features you "AFAIK" comment on. I'm sure Heiles,
Maarten, and others will comment where their memory differs.

50ms restoration
This figure has a very long history. My memory is that this started as time
the SONET/SDH payload should wait before assuming a failure in the payload.
The figure was chosen somewhat randomly as that were many implementation
specific factors which would affect the time including detection of LOS,
detection of LOF, any protection mechanism (MSP or internal equipment card
protection) and we made a conscious decision not to specify any details of
these - they are open to different vendor implementation for good economic
reasons. It general use now, it includes any failure detection time, any
protection signalling time, any protection switching time, and any time for
signals to reacquire and stablise. In practise some implementations with
simple 1+1 MSP protection over short distances will switch in a few
millisecs while implementations of more complex shared ring MSP protection
on geographically large rings struggle to meet the 50ms. This is simply the
transmission time required to pass the MSP signalling around the ring. As a
broad summary, SONET/SDH is generally designed to go as fast as possible -
unless you are goning to invent a new speed for the speed of light, you are
unlikely to usefully go faster than SONET/SDH protection schemes.

I draw three conclusions from this
- lambda optical systems can and should just use the current SONET/SDH specs
as this is now the "bottom of the network" - some small modifications are
probably needed to reflect the analogue nature of DWDM
- SONET/SDH systems deployed over lambda optical systems should understand
they are no longer at the bottom of the network and do something about the
potential interactions, eg don't use SONET/SDH MSP or use a holdoff timer -
all out equipment is specced to have a programmable delay of 0-100ms and the
spec was written 10 years ago.
- packet based layers must be designed to cope with either SONET/SDH or
lambda optical protection switching underneath.

Scramblers
This is a good example of IETFers not asking the experts in the field.
No-one bothered to ask anyone who knew about SONET/SDH before writing the
PoS spec and just got it wrong. The x43 + 1 scrambler was specced for
non-byte interleaved SONET/SDH payloads in around 1990. There was/is nothing
wrong with SONET/SDH only some IETFers not knowing what they don't know.

Bi-directional fibre working
It has been know for a long time that bi-directional fibre working can cause
a problem with detecting fibre breaks - a transmit signal reflects off the
break and is received and a perfectly framed signal. This is why the J0 byte
was recoded (it was orginally called C1) so that each transmitter can send a
different signal label and detect if it receives it own signal label. My
guess is the anacdote you refer to was a problem in setting the J0 signal
label.

Hope this answer some of the "issues" people raise with SONET/SDH. I'm
convinced good engineers can work together but it takes a level of mutual
respect.

Andy


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: 09 April 2001 18:46
> To: Heiles Juergen
> Cc: 'curtis@avici.com'; Lazer, Monica A, NNAD; 
> 'neil.2.harrison@bt.com';
> raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org
> Subject: Re: restoration time requirement (was Re: Last Call on RSVP
> Label Allocation for Backup Tunnels)
> 
> 
> 
> 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
> > 
>