rfc2823.txt

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

Network Working Group                                         J. Carlson
Request for Comments: 2823                        Sun Microsystems, Inc.
Category: Experimental                                        P. Langner
                              Lucent Technologies Microelectronics Group
                                                   E. Hernandez-Valencia
                                                           J. Manchester
                                                     Lucent Technologies
                                                                May 2000


                    PPP over Simple Data Link (SDL)
                 using SONET/SDH with ATM-like framing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links, and
   RFCs 1662 [2] and 2615 [3] provide a means to carry PPP over
   Synchronous Optical Network (SONET) [4] and Synchronous Digital
   Hierarchy (SDH) [5] circuits.  This document extends these standards
   to include a new encapsulation for PPP called Simple Data Link (SDL)
   [6].  SDL provides a very low overhead alternative to HDLC-like
   encapsulation, and can also be used on SONET/SDH links.

Applicability

   This specification is intended for those implementations that use PPP
   over high speed point-to-point circuits, both with so-called "dark
   fiber" and over public telecommunications networks.  Because this
   enhanced PPP encapsulation has very low overhead and good hardware
   scaling characteristics, it is anticipated that significantly higher
   throughput can be attained when compared to other possible SONET/SDH
   payload mappings, and at a significantly lower cost for line
   termination equipment.






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


   SDL is defined over other media types and for other data link
   protocols, but this specification covers only the use of PPP over SDL
   on SONET/SDH.

   The use of SDL requires the presentation of packet length information
   in the SDL header.  Thus, hardware implementing SDL must have access
   to the packet length when generating the header, and where a router's
   input link does not have this information (that is, for non-SDL input
   links), the router may be required to buffer the entire packet before
   transmission.  "Worm-hole" routing is thus at least problematic with
   SDL, unless the input links are also SDL.  This, however, does not
   appear to be a great disadvantage on modern routers due to the
   general requirement of length information in other parts of the
   system, notably in queuing and congestion control strategies such as
   Weighted Fair Queuing [7] and Random Early Detect [8].

   This document is not a replacement for the existing HDLC-like framing
   mandated by RFC 2615 [3].  Instead, the authors intend to gain
   implementation experience with this technique for operational and
   performance evaluation purposes, and would like to hear from others
   either considering or using the protocol as described in this
   document.  Please see Section 14 of this document for contact
   information.




























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


Table of Contents

   1.  Introduction ...............................................    4
   2.  Compliance .................................................    4
   3.  Physical Layer Requirements ................................    5
   3.1.  Payload Types ............................................    5
   3.2.  Control Signals ..........................................    6
   3.3.  Synchronization Modes ....................................    7
   3.4.  Simple-Data-Link LCP Option ..............................    7
   3.5.  Framing ..................................................    8
   3.6.  Framing Example ..........................................   11
   3.7.  Synchronization Procedure ................................   11
   3.8.  Scrambler Operation ......................................   12
   3.9.  CRC Generation ...........................................   12
   3.10.  Error Correction ........................................   13
   4.  Performance Analysis .......................................   14
   4.1.  Mean Time To Frame (MTTF) ................................   14
   4.2.  Mean Time To Synchronization (MTTS) ......................   15
   4.3.  Probability of False Frame (PFF) .........................   16
   4.4.  Probability of False Synchronization (PFS) ...............   16
   4.5.  Probability of Loss of Frame (PLF) .......................   16
   5.  The Special Messages .......................................   16
   5.1.  Scrambler State ..........................................   17
   5.2.  A/B Message ..............................................   17
   6.  The Set-Reset Scrambler Option .............................   17
   6.1.  The Killer Packet Problem ................................   17
   6.2.  SDL Set-Reset Scrambler ..................................   18
   6.3.  SDL Scrambler Synchronization ............................   18
   6.4.  SDL Scrambler Operation ..................................   19
   7.  Configuration Details ......................................   20
   7.1.  Default LCP Configuration ................................   20
   7.2.  Modification of the Standard Frame Format ................   21
   8.  Implementation Details .....................................   21
   8.1.  CRC Generation ...........................................   21
   8.2.  Error Correction Tables ..................................   23
   9.  Security Considerations ....................................   25
   10.  References ................................................   25
   11.  Acknowledgments ...........................................   26
   12.  Working Group and Chair Address ...........................   26
   13.  Intellectual Property Notices .............................   26
   14.  Authors' Addresses ........................................   27
   15.  Full Copyright Statement ..................................   28









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


1.  Introduction

   The Path Signal Label (SONET/SDH overhead byte named C2; referred to
   as PSL in this document) is intended to indicate the type of data
   carried on the path.  This data, in turn, is referred to as the SONET
   Synchronous Payload Envelope (SPE) or SDH Administrative Unit Group
   (AUG).  The experimental PSL value of decimal 207 (CF hex) is
   currently [3] used to indicate that the SPE contains PPP framed using
   RFC 1662 Octet Synchronous (O-S) framing and transmission without
   scrambling, and the value 22 (16 hex) is used to indicated PPP framed
   using O-S framing and transmission with ATM-style X^43+1 scrambling.

   This document describes a method to enable the use of SDL framing for
   PPP over SONET/SDH, and describes the framing technique and
   requirements for PPP.  While O-S framing on SONET/SDH has a fixed
   seven octet overhead per frame plus a worst-case overhead of 100% of
   all data octets transmitted, SDL has a fixed eight octet per frame
   overhead with zero data overhead.  Unlike O-S framing, SDL also
   provides positive indication of link synchronization.

   Note:  This document describes two new SONET/SDH Path Signal Label
   (PSL) values; 23 (17 hex) for SDL with the proposed self synchronous
   scrambler and 25 (19 hex) for SDL with the proposed set-reset
   scrambler.  These values have been allocated by ANSI T1X1.5 and ITU-T
   SG-15 for use with SDL over SONET and SDH, and will appear in
   subsequent updates of T1.105 (Table 8) and Recommendation G.707
   (Table 7).

2.  Compliance

   In this document, the words that are used to define the significance
   of each particular requirement are capitalized.

   These words are:

   *  "MUST"

      This word means that the item is an absolute requirement of the
      specification.

   *  "MUST NOT"

      This phrase means that the item is an absolute prohibition of the
      specification.







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


   *  "SHOULD"

      This word means that there may exist valid reasons in particular
      circumstances to ignore this item, but the full implications
      should be understood and the case carefully weighed before
      choosing a different course.

   *  "SHOULD NOT"

      This phrase means that there may exist valid reasons in particular
      circumstances to apply this item, but the full implications should
      be understood and the case carefully weighed before choosing a
      different course.

   *  "MAY"

      This word means that this item is truly optional.  One vendor may
      choose to include the item because a particular marketplace
      requires it or because it enhances the product, for example;
      another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or MUST NOT requirements for this protocol.  An
   implementation that satisfies all of the MUST, MUST NOT, SHOULD, and
   SHOULD NOT requirements for this protocol is said to be
   "unconditionally compliant".  One that satisfies all the MUST and
   MUST NOT requirements but not all the SHOULD or SHOULD NOT
   requirements is said to be "conditionally compliant".

3.  Physical Layer Requirements

   PPP treats SONET/SDH transport as octet-oriented synchronous links.
   No provision is made to transmit partial octets.  Also, SONET/SDH
   links are full-duplex by definition.

3.1.  Payload Types

   Only synchronous payloads STS-1 and higher are considered in this
   document.  Lower speed synchronous, such as VT1.5-SPE/VC-11, and
   plesiochronous payload mappings, such as T1 and T3, are defined for
   SONET/SDH and for the SDL algorithm itself, but, since HDLC-like
   framing is defined for PPP on those media, PPP over SDL is not
   defined.

   SDL is separately defined as a PPP transport for use on raw fiber
   without SONET/SDH framing for use as an alternative to bit-
   synchronous HDLC.  Please see the separate work-in-progress for
   details.



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


3.2.  Control Signals

   The PPP over SONET/SDH mapping allows the use of the PSL as a control
   signal.  Not all equipment, however, is capable of setting or
   detecting this value, and any use must take this into account.
   Equipment employing only SDL MUST be capable of transmitting PSL with
   value 23, and MAY also be capable of transmitting PSL with value 25,
   but need not be capable of detecting the peer's value or capable of
   changing its own value.

   There are two methods to enable SDL, an LCP-negotiated method and a
   prior-arrangement method.  The former allows for easier configuration
   and compatibility with existing equipment, while the latter allows
   general use with separate SONET/SDH transmission equipment with PSL
   limitations.  Both types of implementations will freely interoperate
   given the procedures below.

   LCP-negotiated systems MUST be capable of changing their transmitted
   PSL value and detecting the peer's value.  Equipment without these
   features MUST NOT support LCP negotiation of SDL.

   When SDL is negotiated by LCP, LCP negotiation MUST be started with
   the PSL value initially set to 22 or 207 and the corresponding non-
   SDL O-S PPP encapsulation MUST be used.  The SDL LCP option is then
   placed in the LCP Configure-Request messages transmitted.  On
   reception of LCP Configure-Request with an SDL LCP option or when the
   peer's transmitted PSL value is received as 23 (or 25), the
   implementation MUST shut down LCP by sending a Down event to its
   state machine, then switch its transmitted PSL value to 23 (or 25),
   switch encapsulation mode to SDL, wait for SDL synchronization, and
   then restart LCP by sending an Up event into LCP.  Otherwise, if the
   peer does not transmit PSL value 23 (or 25) and it does not include
   the SDL LCP option in its LCP Configure-Request messages, then
   operation using non-SDL O-S PPP encapsulation continues.  If the
   received PSL value subsequently received reverts from 23 (or 25) to
   any other value, then this is treated as a Down event into the LCP
   state machine, and an Up event MUST be generated if the new value is
   recognized as a valid PPP framing mode.

   When SDL is enabled by prior arrangement, the PSL SHOULD be
   transmitted as 23 (or 25).  Any other value may also be used by prior
   external arrangement with the peer, although the values 22 and 207
   are discouraged.  (Such use is enforced by an administrator, and is
   outside the scope of this specification.)  When SDL is enabled by
   prior arrangement, the SDL LCP option SHOULD NOT be negotiated by the
   peers.





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


   An implementation-specific configuration option SHOULD exist to
   enable the use of prior-arrangement versus LCP-negotiated modes.
   This option SHOULD be presented to an administrator, and SHOULD
   default to LCP-negotiated if the hardware permits.  Otherwise, if the
   hardware implementation precludes non-SDL modes of operation, then it
   MUST default to prior-arrangement mode.

   The LCP-negotiated method of operation is compatible with the current
   version of G.783 [12].  This method may not be compatible, however,
   with some non-intrusive SDH path monitoring equipment based on
   obsolete versions of G.783.  The change in PSL value indicated by the
   LCP negotiation method will cause this equipment to declare an alarm
   condition on the path.  For this reason, the prior-arrangement method
   MUST be used on any SDH network that is using such monitoring
   equipment.

3.3.  Synchronization Modes

   Unlike O-S encapsulation, SDL provides a positive indication that it
   has achieved synchronization with the peer.  An SDL PPP
   implementation MUST provide a means to temporarily suspend PPP data
   transmission (both user data and negotiation traffic) if
   synchronization loss is detected.  An SDL PPP implementation SHOULD
   also provide a configurable timer that is started when SDL is
   initialized and restarted on the loss of synchronization, and is
   terminated when link synchronization is achieved.  If this timer
   expires, implementation-dependent action should be taken to report
   the hardware failure.

3.4.  Simple-Data-Link LCP Option

   A new LCP Configuration Option is used to request Simple Data Link
   (SDL) [6] operation for the PPP link.

   A summary of the Simple-Data-Link Configuration Option format for the
   Link Control Protocol (LCP) is shown below.  The fields are
   transmitted from left to right.