Payload scramble on DS3 and SONET/SDH interfaces is used to
ensure that payload bit pattern can't be translated by transmission
equipment as
part of framing, LOS,LOF, AIS, any other alarm signals, or to prevent an
injection of hostile patterns directed at SONET/SDH equipment to produce
such a pattern (LOS etc.) (if scramble is not enabled there is a chance
to emulate a such pattern, therefore taking transmission equipment out of
service - DoS).
Scrambling is Also used to ensure adequate number of 1's/0's for line rate
clock recovery at the receiver.
RFC 1619 - original POS rfc- specified no need for scrambling of the payload
;-(
RFC 2615 specifies that "self-synchronous scrambler of polynomial X**43 +
1" is to be used on all SPE payload and
provides an option for scramble on/off for backwards compatibility with RFC
1619.
( See rfc 2615 section "Security Considerations" for more " ..)
Also, in ATM, with direct mapping (HEC is used for cell delineation) of the
cells into a DS3 or SONET/SDH payload,
scrambling helps to ensure that payload bit pattern will not match HEC.
Scrambling is hardware activated feature, so there is no performance impact.
There is good white paper on PMC Sierra discussing POS and scrambling
methods :
http://www.pmc-sierra.com/pdf/whitePaper-packetOverSonet.pdf
Also, PMC Sierra has lot's of other white papers on related topics, since
they are one of the leading manufactures of the
ATM, POS and SONET/SDH chip sets used in our beloved Cisco gear ;-() and a
contributor to IETF working groups.
So, scramble! ;-)
Regards,
Mike Axelrod
Digital Island
----- Original Message -----
From: "Charles Sprickman" <spork@inch.com>
To: "George Robbins" <grr@shandakor.tharsis.com>
Cc: <cisco-nsp@puck.nether.net>; <kashani@enteract.com>
Sent: Monday, July 17, 2000 11:44 PM
Subject: Re: Scramble or not to scramble
> I remember seeing something about scramble being preferred when Covad said
> "no don't do that" on a DS3 to them.
>
> I found something over at the 3Com site that states: "It is a
> technique used to avoid certain transmission equipment behaviors (for
> example, erroneous alarm conditions) that are caused by sensitivity to
> certain bit patterns in the ATM payload. You must match this setting at
> the two ends of the DS3 trunk."
>
> Haven't found anything more detailed than that though. I wonder why this
> specifically applies to ATM? I wish I could find the earlier reference,
> as it went into more detail regarding the "why"...
>
> Charles
>
> | Charles Sprickman | Internet Channel
> | INCH System Administration Team | (212)243-5200
> | spork@inch.com | access@inch.com
>
> On Tue, 18 Jul 2000, George Robbins wrote:
>
> > Well, the b3zs linecoding should keep you out of erroneous error
territory.
> >
> > There are some older t3 CSU's that don't even support payload
scrambling,
> > beyond that it seems some providers default to doing it one way and some
> > the other...
> >
> > The DOS thing has to do with scrambler prediction on services over SONET
> > links that don't use a zero-handling linecoding at the line level. (or
> > something like that 8-)
> >
> > George
> >
> >
> > > Date: Mon, 17 Jul 2000 16:37:38 -0700
> > > To: <cisco-nsp@puck.nether.net>
> > > From: Ramin K <kashani@enteract.com>
> > > Subject: Scramble or not to scramble
> > >
> > > I've got a provider who said they usually don't do scramble on DS3's.
> > > I was under the impression that turning on scramble was a good thing
> > > in most cases.
> > >
> > > Now of course I can't remember why I came to this conclusion. The only
> > > reference I found was it keeps your DSU from reporting erroneous
errors.
> > >
> > > For some reason I thought it made some DoS attack against the
interfaces
> > > harder. Am I just on crack?
> > >
> >
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:14 EDT