RFC2823 日本語訳
2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-likeframing. J. Carlson, P. Langner, E. Hernandez-Valencia, J.Manchester. May 2000. (Format: TXT=60049 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
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
PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
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.
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
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.
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
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.
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].
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.
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
Carlson, et al. Experimental [Page 2] RFC 2823 PPP SDL on SONET/SDH May 2000
Table of Contents
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
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
Carlson, et al. Experimental [Page 3] RFC 2823 PPP SDL on SONET/SDH May 2000
1. Introduction
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.
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.
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).
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
2. Compliance
In this document, the words that are used to define the significance of each particular requirement are capitalized.
In this document, the words that are used to define the significance of each particular requirement are capitalized.
These words are:
These words are:
* "MUST"
* "MUST"
This word means that the item is an absolute requirement of the
specification.
This word means that the item is an absolute requirement of the specification.
* "MUST NOT"
* "MUST NOT"
This phrase means that the item is an absolute prohibition of the
specification.
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
Carlson, et al. Experimental [Page 4] RFC 2823 PPP SDL on SONET/SDH May 2000
* "SHOULD"
* "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.
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"
* "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.
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"
* "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.
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".
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
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.
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
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.
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.
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
Carlson, et al. Experimental [Page 5] RFC 2823 PPP SDL on SONET/SDH May 2000
3.2. Control Signals
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.
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.
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.
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 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.
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
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.
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.
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
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.
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
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 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.
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.
Carlson, et al. Experimental [Page 7] RFC 2823 PPP SDL on SONET/SDH May 2000
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Type
29
29
Length
Length
2
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.
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.
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.)
(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
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.
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
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
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.
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.
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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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
Carlson, et al. Experimental [Page 10] RFC 2823 PPP SDL on SONET/SDH May 2000
3.6. Framing Example
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:
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
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.
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
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:
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
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.
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
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.
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.
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.
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
Carlson, et al. Experimental [Page 11] RFC 2823 PPP SDL on SONET/SDH May 2000
3.8. Scrambler Operation
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.
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
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)
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.
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.
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
3.9. CRC Generation
The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T polynomials [11]. These are:
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^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
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 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
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
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.
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.
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.
C code to generate these CRCs is found in section 8.1.
3.10. Error Correction
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.
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.)
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: 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.
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.
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
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):
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
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.
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.
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.
Corresponding C code to generate this table is found in section 8.2.
4. Performance Analysis
4. Performance Analysis
There are five general statistics that are important for framing algorithms. These are:
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
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].
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)
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.
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] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 14] RFC 2823 PPP SDL on SONET/SDH May 2000
In order to calculate MTTF, we must first determine how often the frame detection state machine is "unavailable" because it failed to detect the next incoming SDL frame in the data stream.
In order to calculate MTTF, we must first determine how often the frame detection state machine is "unavailable" because it failed to detect the next incoming SDL frame in the data stream.
Since the probability of a false header detection using CRC-16 in random data is 2^-16 and this rate is large compared to the allowable packet size, it is worthwhile to run multiple parallel frame- detection state machines. Each machine starts with a different candidate framing point in order to reduce the probability of falsely detecting user data as a valid frame header.
Since the probability of a false header detection using CRC-16 in random data is 2^-16 and this rate is large compared to the allowable packet size, it is worthwhile to run multiple parallel frame- detection state machines. Each machine starts with a different candidate framing point in order to reduce the probability of falsely detecting user data as a valid frame header.
The results for this calculation, given maximal 64KB packets and slightly larger than Internet average 354 byte packets, are:
The results for this calculation, given maximal 64KB packets and slightly larger than Internet average 354 byte packets, are:
Number of Unavailability Unavailability
Framers 64KB packets 354 byte pkts
1 3.679E-1 5.373E-3
2 3.083E-2 1.710E-6
3 2.965E-3 9.712E-10
4 2.532E-4 4.653E-13
Number of Unavailability Unavailability Framers 64KB packets 354 byte pkts 1 3.679E-1 5.373E-3 2 3.083E-2 1.710E-6 3 2.965E-3 9.712E-10 4 2.532E-4 4.653E-13
Using these values, MTTF can be calculated as a function of the Bit Error Rate (BER). These plots show a characteristically flat region for all BERs up to a knee, beyond which the begins to rise sharply. In all cases, this knee point has been found to occur at a BER of approximately 1E-4, which is several orders of magnitude above that observed on existing SONET/SDH links. The flat rate values are summarized as:
Using these values, MTTF can be calculated as a function of the Bit Error Rate (BER). These plots show a characteristically flat region for all BERs up to a knee, beyond which the begins to rise sharply. In all cases, this knee point has been found to occur at a BER of approximately 1E-4, which is several orders of magnitude above that observed on existing SONET/SDH links. The flat rate values are summarized as:
Number of Flat region Flat region
Framers 64KB packets 354 bytes
1 3.58 1.52
2 1.595 1.5
3 1.52 1.5
4 1.5 1.5
Number of Flat region Flat region Framers 64KB packets 354 bytes 1 3.58 1.52 2 1.595 1.5 3 1.52 1.5 4 1.5 1.5
Thus, for common packet sizes in an implementation with two parallel framers using links with a BER of 1E-4 or better, the MTTF is approximately 1.5 packets. This is also the optimal time, since it represents initiating framing at an average point half-way into one packet, and achieving good framing after seeing exactly one correctly framed packet.
Thus, for common packet sizes in an implementation with two parallel framers using links with a BER of 1E-4 or better, the MTTF is approximately 1.5 packets. This is also the optimal time, since it represents initiating framing at an average point half-way into one packet, and achieving good framing after seeing exactly one correctly framed packet.
4.2. Mean Time To Synchronization (MTTS)
4.2. Mean Time To Synchronization (MTTS)
The MTTS for SDL with a self-synchronous scrambler is the same as the MTTF, or 1.5 packets.
The MTTS for SDL with a self-synchronous scrambler is the same as the MTTF, or 1.5 packets.
Carlson, et al. Experimental [Page 15] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 15] RFC 2823 PPP SDL on SONET/SDH May 2000
The MTTS for SDL using the optional set-reset scrambler is one half of the scrambling state transmission interval (in packets) plus the MTTF. For insertion at the default rate of one per eight packets, the MTTS is 5.5 packets.
The MTTS for SDL using the optional set-reset scrambler is one half of the scrambling state transmission interval (in packets) plus the MTTF. For insertion at the default rate of one per eight packets, the MTTS is 5.5 packets.
(The probability of receiving a bad scrambling state transmission should also be included in this calculation. The probability of random corruption of this short message is shown in the SDL document [6] to be small enough that it can be neglected for this calculation.)
(The probability of receiving a bad scrambling state transmission should also be included in this calculation. The probability of random corruption of this short message is shown in the SDL document [6] to be small enough that it can be neglected for this calculation.)
4.3. Probability of False Frame (PFF)
4.3. Probability of False Frame (PFF)
The PFF is 2.328E-10 (2^-32), since false framing requires two consecutive headers with falsely correct CRC-16.
The PFF is 2.328E-10 (2^-32), since false framing requires two consecutive headers with falsely correct CRC-16.
4.4. Probability of False Synchronization (PFS)
4.4. Probability of False Synchronization (PFS)
The PFS for SDL with the self-synchronous scrambler is the same as the PFF, or 2.328E-10 (2^-32).
The PFS for SDL with the self-synchronous scrambler is the same as the PFF, or 2.328E-10 (2^-32).
The PFS for SDL with the set-reset scrambler is 5.421E-20 (2^-64), and is calculated as the PFF above multiplied by the probability of a falsely detected scrambler state message, which itself contains two independent CRC-16 calculations.
The PFS for SDL with the set-reset scrambler is 5.421E-20 (2^-64), and is calculated as the PFF above multiplied by the probability of a falsely detected scrambler state message, which itself contains two independent CRC-16 calculations.
4.5. Probability of Loss of Frame (PLF)
4.5. Probability of Loss of Frame (PLF)
The PLF is a function of the BER, and for SDL is approximately the square of the BER multiplied by 500, which is the probability of two or more bit errors occurring within the 32 bit SDL header. Thus, at a BER of 1E-5, the PLF is 5E-8.
The PLF is a function of the BER, and for SDL is approximately the square of the BER multiplied by 500, which is the probability of two or more bit errors occurring within the 32 bit SDL header. Thus, at a BER of 1E-5, the PLF is 5E-8.
5. The Special Messages
5. The Special Messages
When the SDL Packet Length field has any value between 0000 and 0003, the message following the header has a special, pre-defined length. The 0 value is a time-fill on an idle link, and no other data follows. The next octet on the link is the first octet of the next SDL header.
When the SDL Packet Length field has any value between 0000 and 0003, the message following the header has a special, pre-defined length. The 0 value is a time-fill on an idle link, and no other data follows. The next octet on the link is the first octet of the next SDL header.
The values 1 through 3 are defined in the following subsections. These special messages each consist of a six octet data portion followed by another CRC-16 over that data portion, as with the SDL header, and this CRC is used for single bit error correction.
The values 1 through 3 are defined in the following subsections. These special messages each consist of a six octet data portion followed by another CRC-16 over that data portion, as with the SDL header, and this CRC is used for single bit error correction.
Carlson, et al. Experimental [Page 16] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 16] RFC 2823 PPP SDL on SONET/SDH May 2000
5.1. Scrambler State
5.1. Scrambler State
The special value of 1 for Packet Length is reserved to transfer the scrambler state from the transmitter to the receiver for the optional set-reset scrambler. In this case, the SDL header is followed by six octets (48 bits) of scrambler state. Neither the scrambler state nor the CRC are scrambled.
The special value of 1 for Packet Length is reserved to transfer the scrambler state from the transmitter to the receiver for the optional set-reset scrambler. In this case, the SDL header is followed by six octets (48 bits) of scrambler state. Neither the scrambler state nor the CRC are scrambled.
5.2. A/B Message
5.2. A/B Message
The special values of 2 and 3 for Packet Length are reserved for "A" and "B" messages, which are also six octets in length followed by two octets of CRC-16. Each of these eight octets are scrambled. No use for these messages with PPP SDL is defined. These messages are reserved for use by link maintenance protocols, in a manner analogous to ATM's OAM cells.
The special values of 2 and 3 for Packet Length are reserved for "A" and "B" messages, which are also six octets in length followed by two octets of CRC-16. Each of these eight octets are scrambled. No use for these messages with PPP SDL is defined. These messages are reserved for use by link maintenance protocols, in a manner analogous to ATM's OAM cells.
6. The Set-Reset Scrambler Option
6. The Set-Reset Scrambler Option
PPP over SDL uses a self-synchronous scrambler. SDL implementations MAY also employ a set-reset scrambler to avoid some of the possible inherent problems with self-synchronous scramblers.
PPP over SDL uses a self-synchronous scrambler. SDL implementations MAY also employ a set-reset scrambler to avoid some of the possible inherent problems with self-synchronous scramblers.
6.1. The Killer Packet Problem
6.1. The Killer Packet Problem
Scrambling in general solves two problems. First, SONET and SDH interfaces require a minimum density of bit transitions in order to maintain hardware clock recovery. Since data streams frequently contain long runs of all zeros or all ones, scrambling the bits using a pseudo-random number sequence breaks up these patters. Second, all link-layer synchronization mechanisms rely on detecting long-range patterns in the received data to detect framing.
Scrambling in general solves two problems. First, SONET and SDH interfaces require a minimum density of bit transitions in order to maintain hardware clock recovery. Since data streams frequently contain long runs of all zeros or all ones, scrambling the bits using a pseudo-random number sequence breaks up these patters. Second, all link-layer synchronization mechanisms rely on detecting long-range patterns in the received data to detect framing.
Self-synchronous scramblers are an easy way to partially avoid these problems. One problem that is inherent with self-synchronous, however, is that long user packets from malicious sites can make use of the known properties of these scramblers to inject either long strings of zeros or other synchronization-destroying patterns into the link. For public networks, where the data presented to the network is usually multiplexed (interleaved) with multiple unrelated streams, the clocking problem does not pose a significant threat to the public network. It does, however, pose a threat to the PPP- speaking device, and it poses a threat to long lines that are unchannelized.
Self-synchronous scramblers are an easy way to partially avoid these problems. One problem that is inherent with self-synchronous, however, is that long user packets from malicious sites can make use of the known properties of these scramblers to inject either long strings of zeros or other synchronization-destroying patterns into the link. For public networks, where the data presented to the network is usually multiplexed (interleaved) with multiple unrelated streams, the clocking problem does not pose a significant threat to the public network. It does, however, pose a threat to the PPP- speaking device, and it poses a threat to long lines that are unchannelized.
Such carefully constructed packets are called "killer packets".
Such carefully constructed packets are called "killer packets".
Carlson, et al. Experimental [Page 17] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 17] RFC 2823 PPP SDL on SONET/SDH May 2000
6.2. SDL Set-Reset Scrambler
6.2. SDL Set-Reset Scrambler
An alternative to the self-synchronous scrambler is the externally synchronized or "set-reset" scrambler. This is a free-running scrambler that is not affected by the patterns in the user data, and therefore minimizes the possibility that a malicious user could present data to the network that mimics an undesirable data pattern.
An alternative to the self-synchronous scrambler is the externally synchronized or "set-reset" scrambler. This is a free-running scrambler that is not affected by the patterns in the user data, and therefore minimizes the possibility that a malicious user could present data to the network that mimics an undesirable data pattern.
The option set-reset scrambler defined for SDL is an x^48+x^28+x^27+x+1 independent scrambler initialized to all ones when the link enters PRESYNCH state and reinitialized if the value ever becomes all zero bits. As with the self-synchronous scrambler, all octets in the PPP packet data following the SDL header through the final packet CRC are scrambled.
The option set-reset scrambler defined for SDL is an x^48+x^28+x^27+x+1 independent scrambler initialized to all ones when the link enters PRESYNCH state and reinitialized if the value ever becomes all zero bits. As with the self-synchronous scrambler, all octets in the PPP packet data following the SDL header through the final packet CRC are scrambled.
This mode MAY be detected automatically. If a scrambler state message is received (as described in the following section), an SDL implementation that includes the set-reset scrambler option may switch from self-synchronous into set-reset mode automatically. An SDL implementation that does not include the set-reset scrambler MUST NOT send scrambler state messages.
This mode MAY be detected automatically. If a scrambler state message is received (as described in the following section), an SDL implementation that includes the set-reset scrambler option may switch from self-synchronous into set-reset mode automatically. An SDL implementation that does not include the set-reset scrambler MUST NOT send scrambler state messages.
6.3. SDL Scrambler Synchronization
6.3. SDL Scrambler Synchronization
As described in the previous section, the special value of 1 for Packet Length is reserved to transfer the scrambler state from the transmitter to the receiver. In this case, the SDL header is followed by six octets (48 bits) of scrambler state plus two octets of CRC-16 over the scrambler state. None of these eight octets are scrambled.
As described in the previous section, the special value of 1 for Packet Length is reserved to transfer the scrambler state from the transmitter to the receiver. In this case, the SDL header is followed by six octets (48 bits) of scrambler state plus two octets of CRC-16 over the scrambler state. None of these eight octets are scrambled.
SDL synchronization consists of two components, link and scrambler synchronization. Both must be completed before PPP data flows on the link.
SDL synchronization consists of two components, link and scrambler synchronization. Both must be completed before PPP data flows on the link.
If a valid SDL header is seen in PRESYNCH state, then the link enters SYNCH state, and the scrambler synchronization sequence is started. If an invalid SDL header is detected, then the link is returned to HUNT state, and PPP transmission is suspended.
If a valid SDL header is seen in PRESYNCH state, then the link enters SYNCH state, and the scrambler synchronization sequence is started. If an invalid SDL header is detected, then the link is returned to HUNT state, and PPP transmission is suspended.
When scrambler synchronization is started, a scrambler state message is sent (Packet Length set to 1 and six octets of scrambler state in network byte order follow the SDL header). When a scrambler synchronization message is received from the peer, PPP transmission is enabled.
When scrambler synchronization is started, a scrambler state message is sent (Packet Length set to 1 and six octets of scrambler state in network byte order follow the SDL header). When a scrambler synchronization message is received from the peer, PPP transmission is enabled.
Carlson, et al. Experimental [Page 18] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 18] RFC 2823 PPP SDL on SONET/SDH May 2000
Scrambler state messages are periodically transmitted to keep the peers in synchronization. A period of once per eight transmitted packets is suggested, and it SHOULD be configurable. Excessive packet CRC errors detected indicates an extended loss of synchronization and should trigger link resynchronization.
Scrambler state messages are periodically transmitted to keep the peers in synchronization. A period of once per eight transmitted packets is suggested, and it SHOULD be configurable. Excessive packet CRC errors detected indicates an extended loss of synchronization and should trigger link resynchronization.
On reception of a scrambler state message, an SDL implementation MUST compare the received 48 bits of state with the receiver's scrambler state. If any of these bits differ, then a synchronization slip error is declared. After such an error, the next valid scrambler state message received MUST be loaded into the receiver's scrambler, and the error condition is then cleared.
On reception of a scrambler state message, an SDL implementation MUST compare the received 48 bits of state with the receiver's scrambler state. If any of these bits differ, then a synchronization slip error is declared. After such an error, the next valid scrambler state message received MUST be loaded into the receiver's scrambler, and the error condition is then cleared.
6.4. SDL Scrambler Operation
6.4. SDL Scrambler Operation
The transmit and receive scramblers are shift registers with 48 stages that are initialized to all-ones when the link is initialized. Each is refilled with all one bits if the value in the shift register ever becomes all zeros. This scrambler is not reset at the beginning of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it modified by the transmitted data, as is the ATM self-synchronous scrambler. Instead it is kept in synchronization using special SDL messages.
The transmit and receive scramblers are shift registers with 48 stages that are initialized to all-ones when the link is initialized. Each is refilled with all one bits if the value in the shift register ever becomes all zeros. This scrambler is not reset at the beginning of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it modified by the transmitted data, as is the ATM self-synchronous scrambler. Instead it is kept in synchronization using special SDL messages.
+----XOR<--------------XOR<---XOR<----------------+ | ^ ^ ^ | | | | | | +->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+ | v OUT
+----XOR<--------------XOR<---XOR<----------------+ | ^ ^ ^ | | | | | | +->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+ | v OUT
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.
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 of each bit of SDL data, whether or not the transmitted bit is scrambled. When scrambling is enabled for a given octet, the OUT bit is exclusive- ored with the raw data bit to produce the transmitted bit. Bits within an octet are transmitted MSB-first.
The scrambler is clocked once after transmission of each bit of SDL data, whether or not the transmitted bit is scrambled. When scrambling is enabled for a given octet, the OUT bit is exclusive- ored with the raw data bit to produce the transmitted bit. Bits within an octet are transmitted MSB-first.
Reception of scrambled data is identical to transmission. Each received bit is exclusive-ored with the output of the separate receive data scrambler.
Reception of scrambled data is identical to transmission. Each received bit is exclusive-ored with the output of the separate receive data scrambler.
Carlson, et al. Experimental [Page 19] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 19] RFC 2823 PPP SDL on SONET/SDH May 2000
To generate a scrambler state message, the contents of D47 through D0 are snapshot at the point where the first scrambler state bit is sent. D47 is transmitted as the first bit of the output. The first octet transmitted contains D47 through D40, the second octet D39 through D32, and the sixth octet D7 through D0.
To generate a scrambler state message, the contents of D47 through D0 are snapshot at the point where the first scrambler state bit is sent. D47 is transmitted as the first bit of the output. The first octet transmitted contains D47 through D40, the second octet D39 through D32, and the sixth octet D7 through D0.
The receiver of a scrambler state message MUST first run the CRC-16 check and correct algorithm over this message. If the CRC-16 message check detects multiple bit errors, then the message is dropped and is not processed further.
The receiver of a scrambler state message MUST first run the CRC-16 check and correct algorithm over this message. If the CRC-16 message check detects multiple bit errors, then the message is dropped and is not processed further.
Otherwise, it then should compare the contents of the entire receive scrambler state D47:D0 with the corrected message. (By pipelining the receiver with multiple clock stages between SDL Header error- correction block and the descrambling block, the receive descrambler will be on the correct clock boundary when the message arrives at the descrambler. This means that the decoded scrambler state can be treated as immediately available at the beginning of the D47 clock cycle into the receive scrambler.)
Otherwise, it then should compare the contents of the entire receive scrambler state D47:D0 with the corrected message. (By pipelining the receiver with multiple clock stages between SDL Header error- correction block and the descrambling block, the receive descrambler will be on the correct clock boundary when the message arrives at the descrambler. This means that the decoded scrambler state can be treated as immediately available at the beginning of the D47 clock cycle into the receive scrambler.)
If any of the received scrambler state bits is different from the corresponding shift register bit, then a soft error flag is set. If the flag was already set when this occurs, then a synchronization slip error is declared. This error SHOULD be counted and reported through implementation-defined network management procedures. When the receiver has this soft error flag set, any scrambler state message that passes the CRC-16 message check without multiple bit errors is clocked directly into the receiver's state register after the comparison is done, and the soft error flag is then cleared. Otherwise, while uncorrectable scrambler state messages are received, the soft error flag state is maintained.
If any of the received scrambler state bits is different from the corresponding shift register bit, then a soft error flag is set. If the flag was already set when this occurs, then a synchronization slip error is declared. This error SHOULD be counted and reported through implementation-defined network management procedures. When the receiver has this soft error flag set, any scrambler state message that passes the CRC-16 message check without multiple bit errors is clocked directly into the receiver's state register after the comparison is done, and the soft error flag is then cleared. Otherwise, while uncorrectable scrambler state messages are received, the soft error flag state is maintained.
(The intent of this mechanism is to reduce the likelihood that a falsely corrected scrambler state message with multiple bit errors can corrupt the running scrambler state.)
(The intent of this mechanism is to reduce the likelihood that a falsely corrected scrambler state message with multiple bit errors can corrupt the running scrambler state.)
7. Configuration Details
7. Configuration Details
7.1. Default LCP Configuration
7.1. Default LCP Configuration
The LCP synchronous configuration defaults apply to SONET/SDH links.
The LCP synchronous configuration defaults apply to SONET/SDH links.
The following Configuration Options are recommended:
The following Configuration Options are recommended:
Magic Number
No Address and Control Field Compression
No Protocol Field Compression
No FCS alternatives (32-bit FCS default)
Magic Number No Address and Control Field Compression No Protocol Field Compression No FCS alternatives (32-bit FCS default)
Carlson, et al. Experimental [Page 20] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 20] RFC 2823 PPP SDL on SONET/SDH May 2000
This configuration means that PPP over SDL generally presents a 32- bit aligned datagram to the network layer. With the address, control, and protocol field intact, the PPP overhead on each packet is four octets. If the SDL framer presents the SDL packet header to the PPP input handling in order to communicate the packet length (the Lucent implementation does not do this, but other hardware implementations may), this header is also four octets, and alignment is preserved.
This configuration means that PPP over SDL generally presents a 32- bit aligned datagram to the network layer. With the address, control, and protocol field intact, the PPP overhead on each packet is four octets. If the SDL framer presents the SDL packet header to the PPP input handling in order to communicate the packet length (the Lucent implementation does not do this, but other hardware implementations may), this header is also four octets, and alignment is preserved.
7.2. Modification of the Standard Frame Format
7.2. Modification of the Standard Frame Format
Since SDL does take the place of HDLC as a transport for PPP, it is at least tempting to remove the HDLC-derived overhead. This is not done for PPP over SDL in order to preserve the message alignment and to allow for the future possibility interworking with other services (e.g., Frame Relay).
Since SDL does take the place of HDLC as a transport for PPP, it is at least tempting to remove the HDLC-derived overhead. This is not done for PPP over SDL in order to preserve the message alignment and to allow for the future possibility interworking with other services (e.g., Frame Relay).
By prior external arrangement or via LCP negotiation, any two SDL implementations MAY agree to omit the address and control fields or implement protocol field compression on a link. Such use is not described by this document and MUST NOT be the default on any SDL implementation.
By prior external arrangement or via LCP negotiation, any two SDL implementations MAY agree to omit the address and control fields or implement protocol field compression on a link. Such use is not described by this document and MUST NOT be the default on any SDL implementation.
8. Implementation Details
8. Implementation Details
8.1. CRC Generation
8.1. CRC Generation
The following unoptimized code generates proper CRC-16 and CRC-32 values for SDL messages. Note that the polynomial bits are numbered in big-endian order for SDL CRCs; bit 0 is the MSB.
The following unoptimized code generates proper CRC-16 and CRC-32 values for SDL messages. Note that the polynomial bits are numbered in big-endian order for SDL CRCs; bit 0 is the MSB.
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned long u32;
typedef unsigned char u8; typedef unsigned short u16; typedef unsigned long u32;
#define POLY16 0x1021
#define POLY32 0x04C11DB7
#define POLY16 0x1021 #define POLY32 0x04C11DB7
u16
crc16(u16 crcval, u8 cval)
{
int i;
u16 crc16(u16 crcval, u8 cval) { int i;
crcval ^= cval << 8;
for (i = 8; i--; )
crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 :
crcval << 1;
return crcval;
crcval ^= cval << 8; for (i = 8; i--; ) crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 : crcval << 1; return crcval;
Carlson, et al. Experimental [Page 21] RFC 2823 PPP SDL on SONET/SDH May 2000
Carlson, et al. Experimental [Page 21] RFC 2823 PPP SDL on SONET/SDH May 2000
}
}
u32
crc32(u32 crcval, u8 cval)
{
int i;
u32 crc32(u32 crcval, u8 cval) { int i;
crcval ^= cval << 24;
for (i = 8; i--; )
crcval = crcval & 0x80000000 ? (crcval << 1) ^ POLY32 :
crcval << 1;
return crcval;
}
crcval ^= cval << 24; for (i = 8; i--; ) crcval = crcval & 0x80000000 ? (crcval << 1) ^ POLY32 : crcval << 1; return crcval; }
u16
crc16_special(u8 *buffer, int len)
{
u16 crc;
u16 crc16_special(u8 *buffer, int len) { u16 crc;
crc = 0;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc;
}
crc = 0; while (--len >= 0) crc = crc16(crc,*buffer++); return crc; }
u16
crc16_payload(u8 *buffer, int len)
{
u16 crc;
u16 crc16_payload(u8 *buffer, int len) { u16 crc;
crc = 0xFFFF;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc ^ 0xFFFF;
}
crcは0xFFFFと等しいです。 (--len>が0と等しい)crcはcrc16(crc、*バッファ++)と等しいのですが。 crc^0xFFFFを返してください。 }
u32
crc32_payload(u8 *buffer, int len)
{
u32 crc;
u32 crc32_ペイロード(u8*バッファ、int len)、u32 crc。
crc = 0xFFFFFFFFul;
while (--len >= 0)
crc = crc32(crc,*buffer++);
return crc ^ 0xFFFFFFFFul;
}
crcは0xFFFFFFFFulと等しいです。 (--len>が0と等しい)crcはcrc32(crc、*バッファ++)と等しいのですが。 crc^0xFFFFFFFFulを返してください。 }
Carlson, et al. Experimental [Page 22] RFC 2823 PPP SDL on SONET/SDH May 2000
カールソン、他 Sonet/SDH2000年5月の実験的な[22ページ]RFC2823ppp SDL
void
make_sdl_header(int packet_length, u8 *buffer)
{
u16 crc;
空の造_sdl_ヘッダー(intパケット_の長さ、u8*バッファ)、u16 crc。
buffer[0] = (packet_length >> 8) & 0xFF;
buffer[1] = packet_length & 0xFF;
crc = crc16_special(buffer,2);
buffer[0] ^= 0xB6;
buffer[1] ^= 0xAB;
buffer[2] = ((crc >> 8) & 0xFF) ^ 0x31;
buffer[3] = (crc & 0xFF) ^ 0xE0;
}
[0]=(パケット_長さ>>8)と0xFFをバッファリングしてください。 バッファ[1]はパケット_の長さと0xFFと等しいです。 crcはcrc16_特別番組(バッファ、2)と等しいです。 バッファ[0]^は0xB6と等しいです。 バッファ[1]^は0xABと等しいです。 バッファ[2]は0xFF) (crc>>8)と^0x31と等しいです。 バッファ[3]は^0xE0と等しいです(crcと0xFF)。 }
8.2. Error Correction Tables
8.2. エラー修正テーブル
To generate the error correction table, the following implementation may be used. It creates a table called sdl_error_position, which is indexed on CRC residue value. The tables can be used to determine if no error exists (table entry is equal to FE hex), one correctable error exists (table entry is zero-based index to errored bit with MSB of first octet being 0), or more than one error exists, and error is uncorrectable (table entry is FF hex). To use for eight octet messages, the bit index from this table is used directly. To use for four octet messages, the index is treated as an unrecoverable error if it is below 32, and as bit index plus 32 if it is above 32.
エラー修正テーブルを発生させるように、以下の実現は使用されるかもしれません。 それはCRC残り価値で索引をつけられるsdl_誤り_位置と呼ばれるテーブルを作成します。 1つ以上の誤りが存在しています、そして、誤りが全く存在しないかどうか(テーブル項目はFE十六進法と等しいです)決定するのにテーブルを使用できますか、1つのコレクタブルエラーが存在しているか(テーブル項目は0歳である最初の八重奏のMSBでのerroredビットへの無ベースのインデックスです)、または誤りは非修正可能です(テーブル項目はFF十六進法です)。 8八重奏にメッセージを使用するために、このテーブルからの噛み付いているインデックスは直接使用されます。 4つの八重奏メッセージ、インデックスの使用には、それがあるなら、それが32未満であるなら回復不能エラーとして扱われる、および噛み付いているインデックスプラス32として上の32があります。
The program also prints out the error syndrome table shown in section 3.10. This may be used as part of a "switch" statement in a hardware implementation.
また、プログラムはセクション3.10で見せられた誤りシンドロームテーブルを印刷します。 これは「スイッチ」声明の一部としてハードウェア実装に使用されるかもしれません。
u8 sdl_error_position[65536];
u8 sdl_誤り_位置[65536]。
/* Calculate new CRC from old^(byte<<8) */
u16
crc16_t8(u16 crcval)
{
u16 f1,f2,f3;
/*が古い^(バイト<<8)*/u16 crc16_t8(u16 crcval)から新しいCRCについて計算する、u16 f1、f2、f3。
f1 = (crcval>>8) | (crcval<<8);
f2 = (crcval>>12) | (crcval&0xF000) | ((crcval>>7)&0x01E0);
f3 = ((crcval>>3) & 0x1FE0) ^ ((crcval<<4) & 0xF000);
return f1^f2^f3;
}
f1は(crcval>>8)と等しいです。| (crcval<<8)。 f2は(crcval>>12)と等しいです。| (crcvalと0xF000) | (crcval>>7)と0x01E0)。 f3は0x1FE0) (crcval>>3)と^(crcval<<4)と0xF000)と等しいです。 f1^f2^f3を返してください。 }
Carlson, et al. Experimental [Page 23] RFC 2823 PPP SDL on SONET/SDH May 2000
カールソン、他 Sonet/SDH2000年5月の実験的な[23ページ]RFC2823ppp SDL
void
generate_error_table(u8 *bptab, int nbytes)
{
u16 crc;
int i, j, k;
空間が_誤り_テーブル(u8*bptab、int nbytes)を発生させる、u16 crc(int i、j、k)
/* Marker for no error */
bptab[0] = 0xFE;
誤りがない*/bptab[0]のための/*マーカーは0xFEと等しいです。
/* Marker for >1 error */
for (i = 1; i < 65536; i++ )
bptab[i] = 0xFF;
(i=1; i<65536; i++)bptab[i]のための>1つの誤り*/のための/*マーカーは0xFFと等しいです。
/* Mark all single bit error cases. */
printf("Error syndrome table:\n");
for (i = 0; i < nbytes; i++) {
putchar(' ');
/*は、すべての単一のビットが誤り事件であるとマークします。 */printf(「誤りシンドロームテーブル: \n」)。 (i=0; i<nbytes; i++)、putchar、('、'、)、;、'
for (j = 0; j < 8; j++) {
crc = 0;
for (k = 0; k < i; k++)
crc = crc16_t8(crc);
crc = crc16_t8(crc ^ (0x8000>>j));
for (k++; k < nbytes; k++)
crc = crc16_t8(crc);
bptab[crc] = (i * 8) + j;
printf(" %04X",crc);
}
putchar('\n');
}
}
等しい..0×8000..等しい } }
int
main(int argc, char **argv)
{
u8 buffer[8] = {
0x01,0x55,0x02,0xaa,
0x99,0x72,0x18,0x56
};
u16 crc;
int i;
intメイン(int argc、炭の**argv)、u8バッファ[8]が等しい、0×01 0×55 0×02 0xaa、0×99、0×72、0×18、0×56、; u16 crc;int i。
generate_error_table(sdl_error_position,8);
_誤り_テーブル(sdl_誤り_位置、8)を発生させてください。
/* Run sample message through check routine. */
crc = 0;
for (i = 0; i < 8; i++)
crc = crc16_t8(crc ^ (buffer[i]<<8));
チェック・ルーチンによる/*走行サンプルメッセージ。 */crc=0。 (i=0; i<8; i++)に関しては、crcはcrc16_t8(crc^(バッファ[i]<<8))と等しいです。
Carlson, et al. Experimental [Page 24] RFC 2823 PPP SDL on SONET/SDH May 2000
カールソン、他 Sonet/SDH2000年5月の実験的な[24ページ]RFC2823ppp SDL
/* Output is 0000 64 -- no error encountered. */
printf("\nError test: CRC %04X, bit position %d\n",
crc,sdl_error_position[crc]);
}
/*出力は0000 64です--誤りは遭遇しません。 */printf(「\nErrorは: CRC%04Xをテストして、ビット位置%dは\nです」crcにsdlな_誤り_位置の[crc])。 }
9. Security Considerations
9. セキュリティ問題
The reliability of public SONET/SDH networks depends on well-behaved traffic that does not disrupt the synchronous data recovery mechanisms. This document describes framing and scrambling options that are used to ensure the distribution of transmitted data such that SONET/SDH design assumptions are not likely to be violated.
公共のSonet/SDHネットワークの信頼性は同期データ回収機構を混乱させない品行方正の交通に依存します。このドキュメントが伝えられたデータの分配を確実にするのに使用されるオプションを縁どっていて、急いで移動させると説明するので、Sonet/SDHデザイン仮定は違反されそうにはありません。
10. References
10. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[2] シンプソン、W.、エディタ、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June
1999.
[3]MalisとA.とW.シンプソン、「Sonet/SDHの上のppp」、RFC2615、1999年6月。
[4] "American National Standard for Telecommunications -
Synchronous Optical Network (SONET) Payload Mappings," ANSI
T1.105.02-1995.
[4] 「アメリカの国家のテレコミュニケーション--同期式光通信網における標準(Sonet)の有効搭載量マッピング」、ANSI T1.105.02-1995。
[5] ITU-T Recommendation G.707, "Network Node Interface for the
Synchronous Digital Hierarchy (SDH)," March 1996.
[5] ITU-T推薦G.707、「同期デジタルハイアラーキ(SDH)のためのネットワーク・ノードインタフェース」、1996年3月。
[6] Doshi, B., Dravida, S., Hernandez-Valencia, E., Matragi, W.,
Qureshi, M., Anderson, J., Manchester, J.,"A Simple Data Link
Protocol for High Speed Packet Networks", Bell Labs Technical
Journal, pp. 85-104, Vol.4 No.1, January-March 1999.
[6] ドーシ、B.、ドラヴィダ人、S.、ヘルナンデス・バレンシア、E.、Matragi、W.、クレーシー、M.、アンダーソン、J.、マンチェスター、J.、「High Speed Packet NetworksのためのSimple Data Linkプロトコル」、ベル研究所Technical Journal、ページ 85-104 1999年1月-3月のVol.4No.1。
[7] Demers, A., S. Keshav, and S. Shenker, "Analysis and simulation
of a fair queueing algorithm," ACM SIGCOMM volume 19 number 4,
pp. 1-12, September 1989.
[7] Demers、A.、S.Keshav、およびS.Shenker、第19ACM SIGCOMM巻が「公正な待ち行列アルゴリズムの分析とシミュレーション」に付番する、4、ページ 1-12と、1989年9月。
[8] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for
Congestion Avoidance," IEEE/ACM Transactions on Networking,
August 1993.
[8] フロイド、S.、および「輻輳回避のための無作為の早期発見ゲートウェイ」、ネットワークのIEEE/ACM取引、1993年8月対ジェーコブソン
[9] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
1994.
[9] シンプソン、W.、エディタ、「ppp LCP拡張子」、RFC1570、1994年1月。
Carlson, et al. Experimental [Page 25] RFC 2823 PPP SDL on SONET/SDH May 2000
カールソン、他 Sonet/SDH2000年5月の実験的な[25ページ]RFC2823ppp SDL
[10] ITU-T Recommendation I.432.1, "B-ISDN User-Network Interface -
Physical Layer Specification: General Characteristics,"
February 1999.
[10] ITU-T推薦I.432.1、「B-ISDNユーザネットワーク・インターフェース--物理的な層の仕様:、」 1999年2月の「一般的特色。」
[11] ITU-T Recommendation V.41, "Code-independent error-control
system," November 1989.
[11]ITU-T Recommendation V.41、「コードから独立している誤り制御システム」、1989年11月。
[12] ITU-T Recommendation G.783, "Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks," April
1997.
[12]ITU-T Recommendation G.783、「同期デジタル階層構造(SDH)設備機能ブロックの特性」、1997年4月。
11. Acknowledgments
11. 承認
PPP over SONET was first proposed by Craig Partridge (BBN) and is documented by Andrew Malis and William Simpson as RFC 2615.
Sonetの上のPPPは最初に、クレイグPartridge(BBN)によって提案されて、RFC2615としてアンドリューMalisとウィリアム・シンプソンによって記録されます。
Much of the material in this document was supplied by Lucent.
材料の多くがLucentによって本書では供給されました。
Other length-prefixed forms of framing for PPP have gone before SDL, such as William Simpson's "PPP in Ether-like Framing" expired draft.
ウィリアム・シンプソンの「エーテルのような縁どりにおけるppp」などのSDLが草稿を吐き出す前にPPPのための縁どりの他の長さで前に置かれたフォームは続きました。
12. Working Group and Chair Address
12. 作業部会と議長Address
The working group can be contacted via the mailing list (ietf- ppp@merit.edu; send mail to ietf-ppp-request@merit.edu to subscribe), or via the current chair:
メーリングリスト(ietf ppp@merit.edu; は申し込むためにメールを ietf-ppp-request@merit.edu に送る)の近く、または、現在のいすを通してワーキンググループに連絡できます:
Karl Fox Extant, Inc. 3496 Snouffer Road, Suite 100 Columbus, Ohio 43235
Suite100コロンブス、オハイオ カールフォックスの実在のInc.3496Snouffer Road、43235
EMail: karl@extant.net
メール: karl@extant.net
13. Intellectual Property Notices
13. 知的所有権通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 公表に利用可能にされた権利のクレームと利用可能に作られるべきライセンスのどんな保証か、された試みの結果もコピーされます。
Carlson, et al. Experimental [Page 26] RFC 2823 PPP SDL on SONET/SDH May 2000
カールソン、他 Sonet/SDH2000年5月の実験的な[26ページ]RFC2823ppp SDL
obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
作成者によるそのような所有権の使用に一般的なライセンスか許可を得てください。さもないと、IETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
14. Authors' Addresses
14. 作者のアドレス
James Carlson Sun Microsystems, Inc. 1 Network Drive MS UBUR02-212 Burlington MA 01803-2757
ジェームスカールソンサン・マイクロシステムズ・インク1ネットワークDriveさんのUBUR02-212Burlington MA01803-2757
Phone: +1 781 442 2084 Fax: +1 781 442 1677 EMail: james.d.carlson@sun.com
以下に電話をしてください。 +1 781 442、2084Fax: +1 1677年の781 442メール: james.d.carlson@sun.com
Paul Langner Lucent Technologies Microelectronics Group 555 Union Boulevard Allentown PA 18103-1286
ポールラングナールーセントテクノロジーズマイクロエレクトロニクスグループ555組合並木街アレンタウンPA18103-1286
EMail: plangner@lucent.com
メール: plangner@lucent.com
Enrique J. Hernandez-Valencia Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
エンリケJ.ヘルナンデス・バレンシアルーセントテクノロジーズ101クロフォードは通りを追い詰めます。 Holmdelニュージャージー07733-3030
EMail: enrique@lucent.com
メール: enrique@lucent.com
James Manchester Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
ジェームスマンチェスタールーセントテクノロジーズ101クロフォードは通りを追い詰めます。 Holmdelニュージャージー07733-3030
EMail: sterling@hotair.hobl.lucent.com
メール: sterling@hotair.hobl.lucent.com
Carlson, et al. Experimental [Page 27] RFC 2823 PPP SDL on SONET/SDH May 2000
カールソン、他 Sonet/SDH2000年5月の実験的な[27ページ]RFC2823ppp SDL
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Carlson, et al. Experimental [Page 28]
カールソン、他 実験的[28ページ]
一覧
スポンサーリンク
