J. Manchester
Internet Draft M. Krishnaswamy
Point-to-Point Protocol Extensions WG S. Dravida
J. Anderson
Expire in six months B. Doshi
E. Hernandez-Valencia
Lucent Technologies
W. L. Edwards
Sprint Corporation
B. Bharucha
K. Fendick
G. Wetzel
AT&T
PPP over SONET/SDH
<draft-ietf-pppext-pppsonet-scrambler-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
Abstract
This Internet Draft addresses the PPP/SONET interface defined
in the IETF RFC 1619 and its application in public Internet backbone
networks. By experimental analysis it is found that this SONET interface
specification is deficient in providing payload transparency. This
deficiency leads to deleterious effects in providing reliable network
operations. A simple SONET payload scrambler enhancement is proposed
Manchester, Krishnaswamy, et al. [Page 1]
PPP over SONET/SDH October 1997
to overcome this deficiency. This work has been brought to the
ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping
to T1.105 with a scrambler to be determined by T1X1.
We are submitting the same proposal to IETF now with the interest to
enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards.
To facilitate this alignment, we have recommended that T1X1 establish a
formal liaison with IETF in regard to IP/SONET interface standards
and associated IP transmission standards development.
1. Introduction
SONET provides a reliable high speed transmission path for today's
growing Internet backbone traffic. RFC 1619 addresses the issues
concerning mapping of the PPP packets on to SONET payload envelopes
[1], [2]. However no scrambling of the IP payload is specified in
RFC 1619. We have found by experimental analysis that this leads to
lack of payload transparency that could cause serious damage to the
reliable functioning of SONET networks.
We are proposing a scrambler for SONET payloads and use of SONET
Path Overheads for maintaining synchronization in the scrambler
operation. We have recommended to T1X1.5 that the scrambler enhanced
mapping use a different Path Signal Label code (byte C2) from the
original proposal in RFC 1619. This will allow network operators to
distinguish between scrambled and non-scrambled payloads.
2. Native SONET Scrambler design
One very serious problem with the RFC specification is the assertion
that "no scrambling is needed during insertion in the SPE". [2, page 2]
It is evident that the decision to not scramble the HDLC delimited PPP
packets is derived from errored assumptions about the SONET scrambler.
The SONET scrambler was designed for optical transmission of
digital signals. "SONET optical interfaces use binary line coding, and
therefore must be scrambled to assure an adequate number of transitions
(zeros to ones, and ones to zeros) for such purposes as line rate
recovery at the receiver,"[3, page 5-6] and the suppression of discrete
spectral components that could lower the receiver's signal-to-noise
ratio. Use of the SONET scrambler was deemed sufficient for providing
payload transparency for multiplexed payloads. However, in the case of
non-multiplexed payloads, such as IP or ATM, where the user data
occupies a significant portion of the SONET frame, use of the SONET
scrambler does not provide sufficient payload transparency.
Manchester, Krishnaswamy, et al. [Page 2]
PPP over SONET/SDH October 1997
____
| |
.--------------------------------------| <---.
| |____| |
| ^ |
__V___ ______ ______ | ___.__
|Stage | |Stage | |Stage | | |Stage |
| 1 |------> 2 |---> .... ---> 6 |-.--> 7 |----.
|______| |______| |______| |______| |
^ ^ ^ ^ ^ ^ ^ ^ |
| | | | | | | | |
| | | | | | | | |
----.-------------.--------------------.-----------.----- |
Clock | | | | |
| | | | |
------.-------------.--------------------.-----------.-- |
Frame Pulse |
_V__
Data In | |
----------> |
|_.__|
|
|
Scrambled |
Data Out V
Fig. 1 SONET Scrambler (1 + x**6 + x**7)
To understand the implications of not having sufficient payload
transparency, one must examine the SONET scrambler in more
detail. The SONET scrambler is a set-reset frame synchronous
scrambler with a generating polynomial of 1+x**6+x**7 as shown in
Figure 1. The scrambler resets at each SONET frame by setting
each of the registers to all ones on the most significant bit of the
byte following the STS-1 number N J0/Z0 byte. The framing bytes,
and the J0/Z0 bytes in STS-1 through STS-N are not scrambled.
A series of shift registers are used with feedback taps coming off
of the 6th and 7th registers. These taps are xored for input back
into the 1st shift register. This operation produces a pseudo
random sequence. As this is a 7th order scrambler, the pseudo
random sequence generated repeats itself every (2**7)-1, or 127, bit
periods. The pseudo random sequence coming out of the 7th
register is xored with the data to be transmitted. This sequence
from the 7th register is easily obtainable using a spread sheet
application. Thus, a malicious user, armed with knowledge of the
xor operation, can, by making a 1/127 assumption as to where
his data lands in the SPE, control the output of the SONET
scrambler.
Suppose for example that a malicious user was trying to introduce
a long string of zeros into the public network. They could transmit
Manchester, Krishnaswamy, et al. [Page 3]
PPP over SONET/SDH October 1997
an IP datagram that continuously repeats the 127 bit pattern from
the 7th register of the SONET scrambler. When the pattern from
the 7th register is aligned with the 127 bit pattern from the
malicious user, the scrambler will put out all zeros.
The malicious user has no idea where his datagram will land in the SPE.
The probability of the repetitive codes in the first row being aligned
with the 7th register of the SONET scrambler is 1/127. If the SONET
signal is an STS-3c, there will be an 80 bit offset for the
transmission of the SONET transport and path overhead. The
malicious user will have no control over these fields; however,
because 127 is prime and thus has no factors in common with 80,
the probability of the repetitive codes matching the output of the 7th
register is exactly 1/127 for each new row that the datagram is
mapped into [Note 1]. If the assumption is further made, that the
user is transmitting to the IP over SONET interfaces via an ethernet
interface (which has an MTU of 1500 bytes), then on average, the
malicious user only has to transmit 21 [Note 2] datagrams to be
reasonably sure that a long string of zeros has been introduced
into the network. This long string of zeros is, in the worst case,
2080 bits or 13 microsec for the STS-3c mapping. This is well within
the specification for SONET LOS (Loss Of Signal) and depending on the
type of clock and clock recovery circuit may also cause framing and
synchronization problems.
-----------------------------------------------------------------------------
[Note 1]
If there were common factors between 127 and 80, the per row probability
would be lower because there will be spots in one row whereby if
an user's datagram lands in them, it will be impossible for the
repetitive codes to be on in the next row. The 1/127 probability
actually increases if the Path Overhead starts to float. The path
overhead then acts as a second offset and the codes are twice as likely
to be on for each row; however, the number of zeroes that can be
introduced will be reduced.
[Note 2]
1500 bytes is roughly 6 rows for an STS-3c mapping. Each datagram thus
has a 6/127 chance of introducing a long string of zeros. The
transmission of 21 datagrams will thus lead to a probability of
(6/127)*21 ~= 1.
3. Experimental verification of RFC 1619 inadequacy
In the laboratory we tested out our technical hypotheses using
RFC 1619 compliant interfaces and several SONET transport network
test equipments. The following is a summary of our conclusions:
A. SONET interfaces that detect LOS in less than 13 microsec are open
to a malicious user causing LOS when interconnected to an RFC 1619
compliant interface [Note 3]. Note that the LOS specification is 2.3 to 100
microsec and it is our experience that most SONET interfaces are on the
Manchester, Krishnaswamy, et al. [Page 4]
PPP over SONET/SDH October 1997
low end of this detection time as this value is included in the SONET
restoration time for automatic protection switching.
B. All SONET interfaces regardless of LOS detection are open to a
malicious user causing synchronization, clock, and framing problems
when the interface is connected to an RFC 1619 compliant interface.
There are no requirements for how long a clock recovery circuit must
maintain synchronization, but our experience tells us that most SONET
clock recovery circuits are designed to stay in synchronization for
~80 bit periods when there are no bit transitions on the incoming line.
After that, the clock will go into holdover and the ability of the clock
to maintain synchronization will be dependent on the clock quality
(i.e., stratum level).
C. As a result of the above scenario, it is possible for a malicious
user to force an interface connected to an RFC 1619 compliant interface
to detect a hard failure based on the onset of LOS or LOF (Loss Of Frame).
Thus, RFC 1619 compliant interfaces should never be used to provide
enhanced services such as protection switching.
It is also important to realize that the issue of unraveling the
SONET scrambler came up during the standardization of ATM over SONET
interfaces. There a user could only gain 48 bytes of the SONET SPE
before there is an interruption from the ATM cell overhead. This was
still seen as a problem when analyzed theoretically. Laboratory tests
could not be performed at the time because SONET and ATM equipment did
not exist. It is therefore simply fair to point out, at the outset,
what this work owes to certain contemporary ATM and SONET
interface developers. We wish to provide citations to this early
outstanding technical work here: [4] [5] [6] [7] [8] [9].
As a result of these contributions, "cell payload scrambling is
used to provide security against payload information replicating
the frame synchronous scrambling sequence (or its inverse) used at the
SONET section layer." [3, page 3-61].
----------------------------------------------------------------------------
[Note 3]
The malicious datagrams can be transmitted from anywhere in the
Internet. The user need not be directly connected to the SONET
network.
4. Requirements for SONET Mappings
In November 1988, T1X1 agreed to the following set of mapping
guidelines [10]:
Standardized Payload
Significant Network Advantage OR Unique
Payload Transparency for Non-terminated Payloads
Timing Transparency
Minimal Implementation Complexity
Manchester, Krishnaswamy, et al. [Page 5]
PPP over SONET/SDH October 1997
Floating/Locked Translation Capability
Mid-Span Meet
A detailed explanation of each of the mapping guidelines from the
original T1X1.5 Mapping SWG contribution [10] follows:
Standardized Payload
The structure of any payload to be mapped must be specified in
detail and approved by a recognized standard setting
organization.
Unique or Significant Network Advantage
The payload must not already have a defined mapping (unique) or the new
mapping must have a significant network advantage over the original
mapping. Significant NETWORK advantage implies that the assessment of
'significant advantage' takes into consideration the fact that the STS
format was developed to allow direct interfaces on many types of transport
equipment which are interconnected. Therefore, a mapping which optimizes
a particular piece of equipment or application at the expense of the
network as a whole is precluded.
Payload Transparency For Non-Terminated Payloads
VT and STS Synchronous Payload Envelopes were developed to allow the
transport of payloads by equipment which has no 'knowledge' of the type
of payload, and to allow new payloads to be mapped and transported
without modification to deployed equipment. New mappings should not
compromise this capability.
Timing Transparency
VT and STS Payload Pointers were developed to allow the transport of
payloads between equipment which is not phase-aligned nor necessarily
exactly frequency synchronous. New mappings should not compromise this
capability.
Minimal Transport Delay
VT and STS Payload Pointers also allow the manipulation of Synchronous
Payload Envelopes without frame alignment buffers in order to minimize
transport delay. New mappings should not compromise this capability.
Minimal Implementation Complexity
The circuitry required to implement a particular mapping should
not be unduly complicated.
Performance
The mapping should be such that, after being transported by the
SONET network, the payload can meet all network performance
Manchester, Krishnaswamy, et al. [Page 6]
PPP over SONET/SDH October 1997
criteria, such as jitter, specific to that payload.
Floating/Locked Translation Capability
Locked VT Mode mappings must be such that it is possible to
translate an STS-1 between Locked and Floating VT Mode. This
translation function should meet all other applicable guidelines.
Mid-Span Meet
This mapping should not compromise the capability of providing mid-span
meet for that payload. Although a payload that is mapped using
Floating VTs is not compatible with the same payload mapped using Lock
VTs, this exception is covered by the Floating/Locked Translation
Capability.
5. Analysis of RFC 1619 with Respect to Mapping Guidelines
In examining the RFC 1619 PPP/SONET mapping with respect to the
T1X1 mapping guidelines, it is clear from the discussion in Section
2 and 3 that the mapping does not provide payload transparency for
non-terminated payloads. This is a very serious problem and
cannot be overlooked. To rectify this situation immediately, it
has been proposed in T1X1 to enhance the PPP over SONET mapping
with the use of a scrambler. (See Appendix A for the scrambler
proposed to T1X1)
6. Scrambler Requirements
In the previous sections we demonstrated the need for a scrambler.
Scramblers designed to transport high speed data services must meet
the following requirements:
A. Robust Performance: The scrambler design must be robust against
malicious user attacks. Even if the user gains control of one or more
SONET/SDH frames, the user should not be able to negate the scrambler
so that bit transparency is lost. This can be accomplished by
making the probability of guessing the scrambler state as small as
possible.
B. Quick Recovery: The scrambler design should be such that in the
event of abnormal situations such as the loss and regaining of physical
layer synchronization, the descrambler at the receiver and the scrambler
at the transmitter regain synchronization is as short a time as
possible.
C. No Error Multiplication: Error multiplication at the lower layer
can be damaging to the higher layer applications. If there is error
multiplication, certain error protection schemes such as parity checks
could be rendered useless. Arithmetic check sums are also generally
vulnerable to error multiplication and perform poorly. Even CRC checks
designed at the higher layers to provide a certain minimum Hamming
distance begin to lose their power and the effective minimum Hamming
distance provided in the presence of error multiplication is reduced.
Manchester, Krishnaswamy, et al. [Page 7]
PPP over SONET/SDH October 1997
D. Immunity to Transmission Errors: While quick recovery is desirable
PPP over SONET/SDH October 1997
after abnormal conditions such as loss of signal events, it is also
important that the scrambler have immunity to normal conditions such
as random background errors. The random errors should not cause the
descrambler and scrambler to go out of synchronization.
E. Work within existing Frame Structure: The scrambler should be made
to work within the existing SONET/SDH frame structure. There should be
no need to introduce new overheads in the SONET/SDH payload.
7. Proposed Scrambler Design
See Appendix A for the scrambler proposed to T1X1.
8. Proposal made to T1X1
This work addressed the PPP/SONET interface defined in the
IETF RFC 1619 and its application in public Internet backbone
networks. Based on the analysis presented herein, the following
proposals were made in T1X1:
A. Reaffirm the SONET mapping criteria and requirements for T1.105 [11]
outlined in [10].
B. Enhance the PPP/SONET mapping in [2] with use of a scrambler for
the SONET payload and use of Path Overheads for maintaining
synchronization in the scrambler operation.
C. Specify the scrambler and the Path Signal Label code. The Path
Signal Label code should be different from the original proposal in
RFC 1619 for allowing network operators to distinguish between
scrambled and non-scrambled payloads.
9. Proposal to IETF
Specifically we propose that future IETF specifications of PPP over
SONET/SDH be aligned with T1.105 when this work is completed in T1.
In the interim, we recommend that one of the following is done:
A. Retract RFC 1619 (or)
B. Reissue a new PPP over SONET/SDH RFC with a cautionary note
that the failure to scramble the PPP packets can lead to
deleterious effects in providing reliable network operations.
Manchester, Krishnaswamy, et al. [Page 8]
PPP over SONET/SDH October 1997
10. Security Consideration
This memo is informational, and specifies no protocol for deployment.
It highlights specific security vulnerabilities of RFC 1619.
11. Acknowledgments
We would like to thank Tom Bowmaster from Bellcore for his technical
and testing assistance.
Grenville Armitage assisted in presenting this information in the IETF
Internet Draft format.
12. References
[1] IETF RFC 1661, "The Point-to-Point Protocol (PPP)," W. Simpson -
Daydreamer (July 1994).
[2] IETF RFC 1619, "PPP over SONET/SDH," W. Simpson - Daydreamer (May 1994).
[3] Bellcore GR-253-CORE, Issue 2, (December 1995).
[4] T1S1.1/88-498, "Enhancements of SONET Scrambling Capabilities to
Carry ATM Cells," Kuo-Hui Liu and William L. Edwards - Pacific Bell
(October 1988).
[5] T1S1.1/88-453, "Bit Sequence Independence for ATM Cells,"
Ralph Ballart - Bellcore (October 1988).
[6] T1X1.5/89-007, "Further Analysis on Bit Transparency Issue,"
William L. Edwards and Kuo-Hui Liu - Pacific Bell (February 1989).
[7] T1S1.1/89-527, "Distributed Bit Scrambling Method for ATM Cells",
D. Fisher and S. Brueckheimer - STC Technology Limited (September 1989).
[8] T1S1.1/89-222, "Killer Cells Detector and Solution for Bit
Transparency Issue," William L. Edwards and Kuo-Hui Liu - Pacific Bell
(May 1989).
[9] T1S1.1/89-163, "Proposed Contribution to CCITT SG XVIII on
SDH Mapping for ATM," Jon Anderson - AT&T Bell Laboratories (May 1989).
[10] T1X1.5/88-123, "Payload Mapping Guidelines," Brent Allen - Nortel
(November 1988).
[11] ANSI T1.105, "Synchronous Optical Network (SONET) Basic
Description including Multiplex Structure, Rates and Formats" (1995).
[12] ITU-T Recommendation G.707, "Network node interface for the
synchronous digital hierarchy (SDH)" (3/96).
Manchester, Krishnaswamy, et al. [Page 9]
PPP over SONET/SDH October 1997
12. Authors' Address
James Manchester
E-mail: manchester@bell-labs.com
Telephone: +1-732-949-6284
Fax: +1-732-949-3210
Bell Laboratories
Room 2G-527
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Murali Krishnaswamy
E-mail: murali@bell-labs.com
Telephone: +1-732-949-3611
Fax: +1-732-949-3210
Bell Laboratories
Room 2G-527A
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Subrahmanyam Dravida
E-mail: dravida@bell-labs.com
Telephone: +1-732-949-1264
Fax: +1-732-834-5906
Bell Laboratories
Room 3M-337
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Jon Anderson
E-mail: jonanderson@bell-labs.com
Telephone: +1-732-949-0634
Fax: +1-732-949-3210
Bell Laboratories
Room 2G-538
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Bharat Tarachand Doshi
E-mail: bdoshi@bell-labs.com
Telephone: +1-732-949-0823
Fax: +1-732-834-5906
Bell Laboratories
Room 3L-337
Manchester, Krishnaswamy, et al. [Page 10]
PPP over SONET/SDH October 1997
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Enrique Hernandez-Valencia
E-mail: enrique@bell-labs.com
Telephone: +1-732-949-6153
Fax: +1-732-834-5906
Bell Laboratories
Room 3H-313
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
W. L. Edwards
E-mail: texas@sprintcorp.com
Telephone: +1-913-534-5334
Fax: +1-913-534-2526
Sprint Corporation
Mailstop KSOPKB0802
9300 Metcalf Avenue
Overland Park, KS 66212
Behram Bharucha
E-mail: bbharucha@att.com
Telephone: +1-732-949-7989
Fax: +1-732-949-8569
AT&T
Room 1J-301
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Kerry Fendick
E-mail: kfendick@att.com
Telephone: +1-732-949-1243
Fax: +1-732-949-1726
AT&T
Room 1L-425
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Greg Wetzel
E-mail: gfwetzel@att.com
Telephone: +1-732-949-6630
Fax: +1-732-949-1726
Manchester, Krishnaswamy, et al. [Page 11]
PPP over SONET/SDH October 1997
AT&T
Room 1L-426
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Appendix A
Note:
This is a proposal to T1X1 and should not be considered to be
in final form.
.--------<---------------<--------------<--------------<--------.
| ^ ^ ^ ^
| | | | |
| | | | |
_V_ ___ ___ | ___ ___ | ___ ___ | ___ ___ |
|x39|-->x38|...|x21|-->x20|-->x19|-->x18|...|x2 |-->x1 |-->x0 |--->
|___| |___| |___| |___| |___| |___| |___| |___| |___| |
|
|
Scrambler |
Output |
_V_
--------> |
Data |___|
|
|
To SONET/SDH |
Layer V
Fig. 2 Proposed Scrambler for PPP over SONET
Based on section 6 requirements, a scrambler polynomial has been
of degree 40 has been designed. This scrambler generates
a pseudo-random sequence of period (2**40)-1, that is it repeats
after (10**12) bits. This period is sufficiently long even for
rates up to OC-768. The probability of a malicious user locking
on to the phase of this scrambler is (2 ** -40) or (10 ** -12).
In conjunction with the SONET/SDH set-reset scrambler, the overall
probability of a malicious user causing loss of bit transparency is
(10 ** -14). The scrambler polynomial is
1 + x**2 + x**19 + x**21 + x**40 and its shift register implementation
is shown in Figure 2.
A. Transmitter and Receiver Synchronization.
The proposed scrambler is designed to scramble bits in the SONET/SDH
Payload envelope only. The section, line and path overheads are not
Manchester, Krishnaswamy, et al. [Page 12]
PPP over SONET/SDH October 1997
scrambled by this scrambler. Therefore the scrambler
state is transmitted using bytes available in the Path Overhead (POH).
Currently H4, Z3 and Z4 bytes are available. These bytes can be
used to transmit the scrambler state so that the descrambler
at the receiver can be synchronized with the scrambler at the
transmitter.
Since the scrambler state is 40 bits long, 5 bytes are needed to
transmit the scrambler state. This can be done by splitting the
scrambler state and carrying it in the H4, Z3 and Z4 bytes of
multiple frames. The state transmitted by the transmitter should
be such that upon its reception, the receiver could load that state
into its descrambler and immediately start descrambling. In order
to enable this, it is desirable for the transmitter to predict the
scrambler state needed at the receiver for immediate descrambling
and then place the predicted state in the H4, Z3 and Z4 bytes of the
Path Overhead (POH). Since the state is transmitted in multiple frames,
the scrambler state would have to be predicted across the number of
frames that it takes to transmit the scrambler state. For example,
if the scrambler state is transmitted in two successive frames then the
scrambler state needs to be predicted by at most two frames. However,
the prediction interval is pre-determined and all that is needed is
prediction of the current state by a fixed number of bytes.
Scrambler state prediction is very simple and can be accomplished in
many ways. A straightforward method is to run two scramblers, one at
the current state and the second one ahead by the number of bytes in
the prediction interval. Another elegant and fast method is to perform
prediction using table look-ups. This avoids the need for a serial bit
register implementation. Five tables each of 1.2 Kbytes can be used for
state prediction. Since the prediction interval is known, the tables are
precomputed and stored. The most significant byte (MSB) of the current
state indexes the first table and retrieves a 5 byte word, the second
most significant byte indexes the second table and retrieves another
5 byte word and so on. The retrieved 5 byte words are xored to provide
the predicted state.
.______________________________________________________.
|SN|Predicted State|SN|Predicted State|RSVD|SN|RSVD|CRC|
|__|_______________|__|_______________|____|__|____|___|
2 22 2 18 4 2 2 20 Bits
<---------------------- 9 Bytes ----------------------->
Fig. 3 Format of Predicted State
In order to provide immunity from random errors and to provide the
ability to quickly recover immediately after abnormal events such
as protection switching, are the predicted state be
covered by a CRC. Furthermore, to leave room for additional
functions that could be added in the future, the
Manchester, Krishnaswamy, et al. [Page 13]
PPP over SONET/SDH October 1997
H4, Z3 and Z4 bytes in some frames are reserved for future use.
This can be done by introducing a frame sequence number of two
bits. The H4, Z3 and Z4 bytes in three consecutive frames can be
used for transmitting the predicting scrambler state and the H4, Z3
and Z4 bytes in the fourth frame could be used for some other
purpose in the future. The proposed format of the predicted state
is shown in Figure 3. In this figure SN stands for sequence
number and RSVD is for reserved bits.
At initialization, the transmitter picks a random seed to load the
shift registers of the scrambler. The only requirement is that at
least one of the 40 bits be non-zero. The transmitter then picks
the corresponding predicted state and forms the predicted state
field as shown in Figure 3 and hands it down to the SONET/SDH
physical layer. The SONET/SDH physical layer transports the
predicted state in three consecutive frames. At the receiver, the
CRC is checked and if it passes the predicted state is loaded into
the descrambler and descrambling starts immediately.
Under normal conditions, the receiver checks to see if the CRC
passes. If the CRC does not pass then the receiver ignores the
predicted state. If the CRC passes and the predicted state does
not match the current state at the receiver, then the receiver loads
the predicted state into the descrambler and continues to
descrambler. The chance of loading an errored state is 1 in (10**6).
In the worst case, it will take six frame times (750 microsec) to regain
scrambler synchronization under abnormal conditions such as the
loss and recovery of physical layer synchronization.
Manchester, Krishnaswamy, et al. [Page 14]
