Subject: PPP Bit ordering for PPP over SONET/SDH

From: "Joseph Pereira" <[email-masked]>
Date: Thu, 18 Dec 1997 09:59:28 -0500

I would appreciate any input on the following issues:

1. Bit ordering:

This is  has been a point of confusion for me.   Let me illustrate my
question with an example:

Say I have a PPP frame in HDLC-like framing with 16 bit CRC.  And I had one
data byte, 0x7D (the control escape character) in the info field.    The
bytes of the PPP in HDLC like frame should look like 0x7E 0XFF 0X03 0X7D
0X5D CRC CRC.    These bits are shown below with the ISO bit ordering for
HDLC:

	MSB						            LSB
Bit  	7	6	5	4	3	2	1	0
----------------------------------------------------------------------------
--------------------------------
0x7E	0	1	1	1	1	1	1	0
0XFF	1	1	1	1	1	1	1	1
0X03	0	0	0	0	0	0	1	1
0X7D	0	1	1	1	1	1	0	1
0X5D	0	1	0	1	1	1	0	1
CRC	X^8	...................................................................
X^15
CRC	X^0       
..................................................................    	X^7

In the ISO documents the bits are transmitted from RIGHT to LEFT.

However, what would the outgoing SONET/SDH data stream look like after
these bits are serialized?  The confusion results because it is my
understanding that the SONET/SDH bits are transmitted MSB first.    That is
I bit 7 above would correspond to the first bit transmitted n the SONET/SDH
stream and also corresponds to what is called bit 1 in the SONET/SDH specs.
  I have shown an example of what I think it would look like but I am not
sure that it is correct.  An A1 (0xF6)  and an A2 (0x28) SONET/SDH framing
byte are shown for reference:

1111 0110....0010 1000....0111 1110 1111 1111 0000 0011 0111 1101 0101 1101
X^8...X^15 X^0..X7 0111 1110 .......

The bits above are transmitted from left to right.    

X^15 .. X^0 are the CRC bits.  Let me explain what they mean.   Think of
the CRC generator as a shift register (serial implementation) with the
appropriate XOR feedbacks.    Let's number the bits of  the SR input ->
output 0 -> 15.  As an example, the  control escape character (0x7D) would
be shifted into the CRC generator as  1011 1110,  where the bits are
shifted in from left to right (i.e. LSB first).    It is clear that the 
coefficient of the highest term is the output end of the SR (bit15).
Therefore, the octet 8-15 will be transmitted first. Since this is a 16 bit
value (for crc16), and bits 8-15 are the least significant octet, the bit
we have numbered 15 is the LSBit of the CRC and the octet. Now, Sonet
always transmits MSbit of a byte first. So, the transmission order should
be bits 8,9,10,11,12,13,14,15,(LSByte -MSBit first) 0,1,2,3,4,5,6,7 (MSByte
-MSBit first).

2) The second question is regarding the 1+X^43 polynomial PPP scrambler.   

Do the bytes get inserted into the scrambler MSB first or LSB first with
respect to the bit ordering shown above?

If anyone can help me here, and possible show an example,  I would be truly
grateful.

kind regards,

Joseph M. Pereira

---

From: "William Allen Simpson" <[email-masked]>
Date: Thu, 18 Dec 97 16:54:47 GMT

I tried to answer your question at least once already, when you asked
privately.

> From: "Joseph Pereira" <[email-masked]>
No, on bit-synchronous and asynchronous over many low speed serial links
the bits are transmitted least significant to most significant within
bytes.  This has nothing to do with ISO, and in fact was adopted by IBM
for SDLC long ago, and independently by EIA for async.  It is media
specific.

Also, to avoid exactly this problem, as noted in RFC-1662, in the IETF
we do not number our bits in transmission order -- a terrible convention
that has caused confusion on ethernet as well.  Instead, we number them
in "canonical" order within bytes.

> understanding that the SONET/SDH bits are transmitted MSB first.

That is correct.  What is confusing?  The media is the same as FDDI.

Instead of wasting time reading ISO documents, stick to RFC-1662.  There
is no such thing as octet-synchronous in ISOese.

RFC-1662 is the standard.

> be bits 8,9,10,11,12,13,14,15,(LSByte -MSBit first) 0,1,2,3,4,5,6,7 (MSByte
We do not use the old CRC16, we use FCS-16, a different polynomial and
algorithm.

That bit order looks right, but only if you think of the FCS as a shift
register.  That is only one implementation.  A faster implementation is
done with bytes and words, as documented in RFC-1662.

> respect to the bit ordering shown above?
That is one of the technical issues that was not answered in DC.  Ask
Cisco what they did, and we'll document it.  That's all the DC BOF
decided to do -- whatever Cisco was already shipping (unannounced).

The IETF doesn't make decisions based on technical rationale anymore....

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: "Joseph Pereira" <[email-masked]>
Date: Thu, 18 Dec 1997 14:10:21 -0500

Mr. Simpson:

Thanks for response.   However what is confusing is what is meant by MSB in
RFC1662.   Is what you call an MSB in RFC1662 the same as MSB in the SONET
frame (i.e. the first bit transmitted).  

For example the control octet has a value of 0x03  (0000 0011) which I
understand that the leftmost bit is the MSB.  So in the outgoing sonet
stream the control field will be transmitted as 0000 0011 from left to
right.    However when calculating the FCS-16, the  control field  is
inserted into the CRC generator shift register  as 1100 0000 one bit at a
time from left to right (i.e. LSB first).
This is what I believe it is saying.

kind regards,

Joseph Pereira

----------
> From: William Allen Simpson <[email-masked]>
> To: [email-masked]
> Cc: Jati Vij <[email-masked]>; Bill Bartholomay <[email-masked]>
> Subject: Re: PPP Bit ordering for PPP over SONET/SDH
> Date: Thursday, December 18, 1997 11:54 AM
>

---

From: "William Allen Simpson" <[email-masked]>
Date: Sun, 21 Dec 97 13:59:23 GMT

> frame (i.e. the first bit transmitted).
I am sorry that the ITU has confused you.  A bit that is "most
significant" has nothing what-so-ever to do with transmission order.
Please re-read RFC-1662.  There is text that I have sent you at least
twice already:

   To remain consistent with standard Internet practice, and avoid
   confusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least
   Significant Bit order, reading from left to right, unless otherwise
   indicated.  Note that this is contrary to standard ISO and CCITT
   practice which orders bits as transmitted (network bit order).  Keep
   this in mind when comparing this document with the international
   standards documents.

SONET is octet-sync, and transmits most significant bit first.  Async
transmits least significant bit first.  They are different media:

4.5.  Transmission Considerations

4.5.1.  Octet-synchronous

   The definition of various encodings and scrambling is the
   responsibility of the DTE/DCE equipment in use, and is outside the
   scope of this specification.

4.5.2.  Asynchronous

   All octets are transmitted least significant bit first, with one
   start bit, eight bits of data, and one stop bit.  There is no
   provision for seven bit asynchronous links.

> right.

Correct!

> However when calculating the FCS-16, the  control field  is

Correct, if you use a shift register.  Also correct for the 32-bit FCS.

However, as I have advised you, it would not be good engineering
practice to use a bit shift register at high speeds, and we have clearly
defined a byte calculation technique.  But that is your cross to bear.

[email-masked]