rfc2823.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Carlson, et al.               Experimental                      [Page 7]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      29

   Length

      2

   This option is used only as a hint to the peer that SDL over
   SONET/SDH operation is preferred by the sender.  If the current
   encapsulation mode is not SDL, then the only appropriate response to
   reception of this option by an SDL speaker is to then switch the
   encapsulation mode to SDL (as detailed in the section above) and
   restart LCP.  Non SDL-speakers SHOULD instead send LCP Configure-
   Reject for the option.

   If either LCP Configure-Nak or LCP Configure-Reject is received for
   this option, then the next transmitted LCP Configure-Request MUST NOT
   include this option.  If LCP Configure-Ack with this option is
   received, it MUST NOT be treated as a request to switch into SDL
   mode.  If the received LCP Configure-Request message does not contain
   an SDL LCP option, an implementation MUST NOT send an unsolicited
   Configure-Nak for the option.

   (An implementation of SDL that is already in SDL framing mode and
   receives this option in an LCP Configure-Request message MAY, both
   for clarity and for convergence reasons, elect to send LCP
   Configure-Ack.  It MUST NOT restart LCP nor change framing modes in
   this case.)

3.5.  Framing

   The PPP frames are located by row within the SPE payload.  Because
   frames are variable in length, the frames are allowed to cross SPE
   boundaries.  Bytes marked as "overhead" or "fixed stuff" in SONET/SDH
   documentation for concatenated streams are not used as payload bytes.

   With reference to the Lucent SDL specification [6] when SDL framing
   for PPP is employed, the SDL "Datagram Offset" feature is set to the
   value 4.  This corresponds to the fixed overhead value 4 in the





Carlson, et al.               Experimental                      [Page 8]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


   description below.  The "A" and "B" messages are never used.  These
   optional features of SDL are not described in this document, but are
   rather described in Lucent's SDL specification.

   Fixing the Datagram Offset value described in the Lucent
   documentation to 4 allows a PPP MRU/MTU up to 65536 using SDL.

   SDL framing is in general accomplished by the use of a four octet
   header on the packet.  This fixed-length header allows the use of a
   simple framer to detect synchronization as described in section 3.7.
   For use with PPP, this fixed-length header precedes each PPP/HDLC
   packet as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Packet Length         |          Header CRC           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     PPP packet (beginning with address and control fields)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .....                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SDL CRC                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The four octet length header is DC balanced by exclusive-OR (also
   known as "modulo 2 addition") with the hex value B6AB31E0.  This is
   the maximum transition, minimum sidelobe, Barker-like sequence of
   length 32.  No other scrambling is done on the header itself.

   Packet Length is an unsigned 16 bit number in network byte order.
   Unlike the PPP FCS, the Header CRC is a CRC-16 generated with initial
   value zero and transmitted in network byte order.  The PPP packet is
   scrambled, begins with the address and control fields, and may be any
   integral octet length (i.e., it is not padded unless the Self
   Describing Padding option is used).  The Packet CRC is also
   scrambled, and has a mode-dependent length (described below), and is
   located only on an octet boundary; no alignment of this field may be
   assumed.

   When the Packet Length value is 4 or greater, the distance in octets
   between one message header and the next in SDL is the sum of 8 plus
   the Packet Length field.  The value 8 represents a fixed overhead of
   4 octets plus the fixed length of the Packet CRC field.  When the
   Packet Length is 0, the distance to the next header is 4 octets.
   This is the idle fill header.  When the Packet Length is 1 to 3, the





Carlson, et al.               Experimental                      [Page 9]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


   distance to the next header is 12 octets.  These headers are used for
   special SDL messages used only with optional scrambling and
   management modes.  See section 5 for details of the messages.

   General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or
   ITU-T CRC-32 for the packet data.  However, because the Packet Length
   field does not include the CRC length, synchronization cannot be
   maintained if the CRC type is changed per RFC 1570 [9], because
   frame-to-frame distance is, as described above, calculated including
   the CRC length.  Thus, this PPP over SDL specification fixes the CRC
   type to CRC-32 (four octets), and all SDL implementations MUST reject
   any LCP FCS Alternatives Option [9] requested by the peer when in SDL
   mode.

   PPP over SDL implementations MAY allow a configuration option to set
   different CRC types for use by prior arrangement.  Any such
   configurable option MUST default to CRC-32, and MUST NOT include LCP
   negotiation of FCS Alternatives.

   Setting the SDL Datagram Offset value to 4 accounts for the 4 octet
   SDL header overhead.  With the SDL Datagram Offset set to 4, the
   value placed in the Packet Length field is exactly the length in
   octets of the PPP frame itself, including the address and control
   fields but not including the CRC field (the RFC 1662 PPP FCS field is
   not used with SDL).  Note again that the Datagram Offset is just an
   arithmetic value; it does not occupy bits in the message itself.

   Because Packet Lengths below 4 are reserved, the Packet Length MUST
   be 4 or greater for any legal PPP packet.  PPP packets with fewer
   octets, which are not possible without address/control or protocol
   field compression, MUST be padded to length 4 for SDL.

   Inter-packet time fill is accomplished by sending the four octet
   length header with the Packet Length set to zero.  No provision is
   made for intra-packet time fill.

   By default, an independent, self-synchronous x^43+1 scrambler is used
   on the data portion of the message including the 32 bit CRC.  This is
   done in exactly the same manner as with the ATM x^43+1 scrambler on
   an ATM channel.  The scrambler is not clocked when SDL header bits
   are transmitted.  Thus, the data scrambling MAY be implemented in an
   entirely independent manner from the SDL framing, and the data stream
   may be prescrambled before insertion of SDL framing marks.

   Optionally, by prior arrangement, SDL links MAY use a set-reset
   scrambler as described in section 6.  If this option is provided, it
   MUST be configurable by the administrator, and the option MUST
   default to the self-synchronous scrambler.



Carlson, et al.               Experimental                     [Page 10]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


3.6.  Framing Example

   To help clarify this structure, the following example may be helpful.
   First we have an LCP Configure-Request message that we wish to
   transmit over SDL:

       FF 03 C0 21 01 01 00 04

   Next, we create an SDL header for the length of this packet (8
   octets), a header CRC, and an SDL CRC.

       00 08 81 08 FF 03 C0 21 01 01 00 04 D1 F5 21 5E

   Finally, we DC-balance the header with the barker-like sequence:

       B6 A3 B0 E8 FF 03 C0 21 01 01 00 04 D1 F5 21 5E

   Note that the final length of the message is 8 (original message
   length) plus 4 (fixed datagram offset value) plus 4 (fixed CRC
   length), or 16 octets.

3.7.  Synchronization Procedure

   The link synchronization procedure is similar to the I.432 section
   4.5.1.1 ATM HEC delineation procedure [10], except that the SDL
   messages are variable length.  The machine starts in HUNT state until
   a four octet sequence in the data stream with a valid CRC-16 is
   found.  (Note that the CRC-16 single-bit error correction technique
   described in section 3.10 is not employed until the machine is in in
   SYNCH state.  The header must have no bit errors in order to leave
   HUNT state.)  Such a valid sequence is a candidate SDL header.  On
   finding the valid sequence, the machine enters PRESYNCH state.  Any
   one invalid SDL header in PRESYNCH state returns the link to HUNT
   state.

   If a second valid SDL header is seen after entering PRESYNCH state,
   then the link enters SYNCH state and PPP transmission is enabled.  If
   an invalid SDL header is detected, then the link is returned to HUNT
   state without enabling PPP transmission.

   Once the link enters SYNCH state, the SDL header single bit error
   correction logic is enabled (see section 3.10).  Any unrecoverable
   header CRC error returns the link to HUNT state, disables PPP
   transmission, and disables the error correction logic.







Carlson, et al.               Experimental                     [Page 11]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


3.8.  Scrambler Operation

   The transmit and receive scramblers are shift registers with 43
   stages that MAY be initialized to all-ones when the link is
   initialized.  Synchronization is maintained by the data itself.

               Transmit                            Receive

    DATA-STREAM (FROM PPP)             IN (FROM SDL FRAMER)
    |                                  |
    v                                  |
    XOR<-------------------------+     +->D0-+->D1-> ... ->D41->D42-+
    |                            |     |                            |
    +->D0-+->D1-> ... ->D41->D42-+     XOR<-------------------------+
    |                                  |
    v                                  v
    OUT (TO SDL FRAMER)                DATA-STREAM (TO PPP)

   Each XOR is an exclusive-or gate; also known as a modulo-2 adder.
   Each Dn block is a D-type flip-flop clocked on the appropriate data
   clock.

   The scrambler is clocked once after transmission or reception of each
   bit of payload and before the next bit is applied as input.  Bits
   within an octet are, per SONET/SDH practice, transmitted and received
   MSB-first.

3.9.  CRC Generation

   The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T
   polynomials [11].  These are:

     x^16+x^12+x^5+1

     x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1

   The SDL Header CRC and the CRC-16 used for each of the three special
   messages (scrambler state, message A, and message B; see section 5)
   are all generated using an initial remainder value of 0000 hex.

   The optional CRC-16 on the payload data (this mode is not used with
   PPP over SDL except by prior arrangement) uses the initial remainder
   value of FFFF hex for calculation and the bits are complemented
   before transmission.  The final CRC remainder, however, is
   transmitted in network byte order, unlike the regular PPP FCS.  If
   the CRC-16 algorithm is run over all of the octets including the
   appended CRC itself, then the remainder value on intact packets will




Carlson, et al.               Experimental                     [Page 12]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


   always be E2F0 hex.  Alternatively, an implementation may stop CRC
   calculation before processing the appended CRC itself, and do a
   direct comparison.

   The CRC-32 on the payload data (used for PPP over SDL) uses the
   initial remainder value of FFFFFFFF hex for calculation and the bits
   are complemented before transmission.  The CRC, however, is
   transmitted in network byte order, most significant bit first, unlike
   the optional PPP 32 bit FCS, which is transmitted in reverse order.
   The remainder value on intact packets when the appended CRC value is
   included in the calculation is 38FB2284.

   C code to generate these CRCs is found in section 8.1.

3.10.  Error Correction

   The error correction technique is based on the use of a Galois number
   field, as with the ATM HEC correction.  In a Galois number field,
   f(a+b) = f(a) + f(b).  Since the CRC-16 used for SDL forms such a
   field, we can state that CRC(message+error) = CRC(message) +
   CRC(error).  Since the CRC-16 remainder of a properly formed message
   is always zero, this means that, for the N distinct "error" strings
   corresponding to a single bit error, there are N distinct CRC(error)
   values, where N is the number of bits in the message.

   A table look-up is thus applied to the CRC-16 residue after
   calculation over the four octet SDL header to correct bit errors in
   the header and to detect multiple bit errors.  For the optional set-
   reset scrambler, a table look-up is similarly applied to the CRC-16
   residue after calculation over the eight octet scrambler state
   message to correct bit errors and to detect multiple bit errors.
   (This second correction is also used for the special SDL A and B
   messages, which are not used for PPP over SDL.)

   Note:  No error correction is performed for the payload.

   Note:  This error correction technique is used only when the link has
   entered SYNCH state.  While in HUNT or PRESYNCH state, error
   correction should not be performed, and only messages with syndrome
   0000 are accepted.  If the calculated syndrome does not appear in
   this table, then an unrecoverable error has occurred.  Any such error
   in the SDL header will return the link to HUNT state.

   Since the CRC calculation is started with zero, the two tables can be
   merged.  The four octet table is merely the last 32 entries of the
   eight octet table.





Carlson, et al.               Experimental                     [Page 13]

RFC 2823                  PPP SDL on SONET/SDH                  May 2000


   Eight octet (64 bit) single bit error syndrome table (in
   hexadecimal):

     FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D3
     ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861
     D420 6A10 3508 1A84 0D42 06A1 8B40 45A0
     22D0 1168 08B4 045A 022D 8906 4483 AA51
     DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B4
     3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730
     1B98 0DCC 06E6 0373 89A9 CCC4 6662 3331
     9188 48C4 2462 1231 8108 4084 2042 1021

   Thus, if the syndrome 6EF6 is seen on an eight octet message, then
   the third bit (hex 20) of the second octet is in error.  Similarly,
   if 48C4 is seen on an eight octet message, then the second bit (hex
   40) in the eighth octet is in error.  For a four octet message, the
   same two syndromes would indicate a multiple bit error for 6EF6, and
   a single bit error in the second bit of the fourth octet for 48C4.

   Note that eight octet messages are used only for the optional set-
   reset scrambling mode, described in section 6.

   Corresponding C code to generate this table is found in section 8.2.

4.  Performance Analysis

   There are five general statistics that are important for framing
   algorithms.  These are:

     MTTF   Mean time to frame
     MTTS   Mean time to synchronization
     PFF    Probability of false frame
     PFS    Probability of false synchronization
     PLF    Probability of loss of frame

   The following sections summarize each of these statistics for SDL.
   Details and mathematic development can be found in the Lucent SDL
   documentation [6].

4.1.  Mean Time To Frame (MTTF)

   This metric measures the amount of time required to establish correct
   framing in the input data.  This may be measured in any convenient
   units, such as seconds or bytes.  For SDL, the relevant measurement
   is in packets, since fragments of packets are not useful.






Carlson, et al.               Experimental                     [Page 14]