idnits 2.17.1 draft-ietf-pppext-sdtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 296: '... is reserved and MUST be set to 0. (T...' RFC 2119 keyword, line 321: '...tate for more than T1 seconds, it MUST...' RFC 2119 keyword, line 374: '...ode operation both bits MUST be set to...' RFC 2119 keyword, line 482: '... SHOULD be silently discarded....' RFC 2119 keyword, line 502: '...sed. other Codes SHOULD be treated as...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 119 has weird spacing: '...atagram may b...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1994) is 10748 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4-10' on line 214 == Unused Reference: '4' is defined on line 842, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 845, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 848, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 851, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 854, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 857, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 860, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kevin Schneider 2 Internet Draft Stuart Venters 3 ADTRAN, Inc. 4 expires May 1995 November 1994 6 PPP Serial Data Transport Protocol (SDTP) 7 draft-ietf-pppext-sdtp-00.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 Please check the 1id-abstracts.txt listing contained in the 29 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 30 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 31 status of any Internet Draft. 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. PPP 37 defines an extensible Link Control Protocol, and proposes a family of 38 Network Control Protocols for establishing and configuring different 39 network-layer protocols. 41 This document describes a new Network level protocol (from the PPP 42 point of view), PPP Serial Data Transport Protocol, that provides 43 encapsulation and an associated control protocol for transporting 44 serial data streams over a PPP link. This protocol was developed for 45 the purpose of using PPP's many features to provide a standard method 46 for synchronous data compression. The encapsulation uses a header 47 structure based on that of the ITU-T Recommendation V.120 [2]. 49 1. Introduction 51 This document is a product of the TR30.1 ad hoc committee on 52 compression of synchronous data. It represents a component of a 53 proposal to use PPP to provide compression of synchronous data in 54 DSU/CSUs. 56 In addition to providing support for multi-protocol datagrams, the 57 Point-to-Point Protocol (PPP) [1] has defined an effective and robust 58 negotiating mechanism that can be used on point to point links. When 59 used in conjunction with the PPP Compression Control Protocol [3] and 60 one of the PPP Compression Protocols [4-10], PPP provides an 61 interoperable method of employing data compression on a point-to- 62 point link. 64 This document provides a PPP encapsulation for serial data, 65 specifying a transport protocol, PPP Serial Data Transport Protocol 66 (PPP-SDTP), and an associated control protocol, PPP Serial Data 67 Control Protocol (PPP-SDCP). When these protocols are added to above 68 mentioned PPP protocols, PPP can be used to provide compression of 69 serial data on a point-to-point link. 71 This first edition of PPP-SDTP/SDCP covers HDLC-like synchronous 72 serial data and asynchronous serial data. It does this by using a 73 terminal adaption header based on that of ITU-T Recommendation V.120 74 [2]. Support may be added in the future for other synchronous 75 protocols as the marketplace demands. 77 The V.120 terminal adaption header allows transported data frames to 78 be split over several packets, supports the transport of DTE port 79 idle and error information, and optionally supports the transport of 80 DTE control state information. 82 In addition to the V.120 Header, fields can be added to the packet 83 format through negotiation to provide support for features not 84 included in the V.120 header. The extra fields are: a Length Field, 85 which is used to distinguish packets in compound frames, and a Port 86 field, which is used to provide multi-port multiplexing capability. 87 The protocol also allows reserved bits in the V.120 header to be used 88 to transport non-octet aligned frames and to provide a flow control 89 mechanism. 91 To provide these features, PPP-SDTP permits a single frame format to 92 be selected from several possible formats by using PPP-SDCP 93 negotiation. The terminal adaption header can be either fixed length 94 or variable length, to allow either simplicity or flexibility. 96 The default frame format places the terminal adaption header at the 97 end of the packet. This permits optimal transmitter timelines when 98 user frames are segmented and compression is also used in conjunction 99 with this protocol. 101 2. SDTP Packets 103 Before any SDTP packets may be communicated, PPP must reach the 104 Network-Layer Protocol phase, and the SDTP Control Protocol must 105 reach the Opened state. 107 By default, exactly one SDTP packet is encapsulated in the PPP 108 Information field, where the PPP Protocol field indicates type hex 109 0049 (PPP-SDTP). If the Length-Field-Present Configuration Option 110 and the LCP Compound-Frames Configuration Option are successfully 111 negotiated, multiple SDTP packets may be placed in the PPP 112 Information field, and they are distinguished by the presence of 113 Length fields in each packet. 115 The maximum length of the SDTP datagram transmitted over a PPP link 116 is limited only by the negotiated Maximum-Frame-Size and the maximum 117 length of the Information field of a PPP encapsulated packet. Note 118 that if compression is used on the PPP link, this the maximum length 119 of the SDTP datagram may be larger or smaller than the maximum 120 length of the Information field of a PPP encapsulated packet, 121 depending on the particular compression algorithm and protocol used. 123 ITU-T Recommendation V.120 [2] defines an adaption header that is 124 used with its asynchronous and synchronous modes of operation. SDTP 125 packets include this header as a Header field to provide the protocol 126 adaption function. Using negotiation, additional fields can be added 127 to the packet to provide sequencing and multiplexing capability 128 within SDTP. SDTP also has an option of using the reserved bits of 129 the header to provide a flow control mechanism and support for 130 transporting non-octet aligned data frames. 132 The default SDTP packet format is designed to allow the efficient use 133 of the protocol's segmentation feature when combined with a PPP 134 Compression Protocol [4-10]. This format is a little different from 135 other PPP NCP's in that data is read from both ends of the packet. 136 The Header field is placed at the end of the SDTP packet, with the 137 order of the octets reversed. This somewhat unique format has been 138 selected to allow optimal transmitter timelines when compression is 139 used and transported data frames are split into multiple SDTP 140 packets. In such a situation, the Header field contains the 141 information about whether the data is split into multiple packets or 142 not, so if it is located at the end of a packet, the decision can be 143 made after observing the compressed size of the packet. The Header 144 field can then simply be run through the compressor after the 145 decision has been made. 147 When the Header field is placed before the data, as in the optional 148 packet format, the transmitter must make the decision about whether 149 to split a frame over multiple packets without knowing about the 150 compressibility of the frame. Therefore the optional format is 151 designed to be used when transported frames are not split into 152 multiple SDTP packets or where SDTP is not coupled with compression. 153 It is believed that this format may be useful for some hardware 154 implementations. 156 2.1. Padding 158 If padding is used, SDTP packets require the use of the Length Field 159 or the previous negotiation of the LCP Self-Describing-Padding 160 Configuration Option [11]. 162 2.2. Packet Formats 164 The default SDTP packet format is shown below. The fields are 165 transmitted from left to right. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | PPP Protocol ID | Transported Data ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Header - H | 173 +-+-+-+-+-+-+-+-+ 175 The two complete frame formats are shown below: Header-Last and 176 Header-First. Header-Last is the default packet format. The 177 additional fields provided support for: Control State Information 178 (CS), multiple packets and multi-port multiplexing. Again, the 179 fields are transmitted from left to right. Descriptions of the 180 fields follow the packet formats. 182 Header-Last 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | PPP Protocol ID | (Length) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | (Port) | Transported Data / (Odd-Pad) ... 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Header - (CS) : H | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Header-First 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | PPP Protocol ID | (Length) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | (Port) | Header - H : (CS) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Transported Data / (Odd-Pad) ... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 PPP Protocol ID 208 The PPP Protocol ID field is described in the Point-to-Point 209 Protocol Encapsulation [1]. 211 When the SDTP Protocol is successfully negotiated by the SDTP 212 Control Protocol (SDCP), the value is 0049 hex. This value may be 213 compressed to one octet when Protocol-Field-Compression is 214 negotiated, or if one of the PPP compression protocols [4-10] is 215 used. 217 Length 219 The optional Length field is present in every SDTP packet upon 220 successful negotiation of the Length-Field-Present Configuration 221 Option. 223 The value of the Length field is the combined lengths of the 224 Length, Port (if present), Header, Transmitted Data, and Odd-Pad 225 (if present) fields in octets. 227 The length of the Length field defaults to one octet. Valid 228 lengths are from 2 to 255 octets, since each packet must include 229 at least a one octet Header field. 231 If desired, the length field can be negotiated to be two octets in 232 length. In that case, valid lengths are from 2 to 65535 octets, 233 and the field is transmitted most significant octet first. 235 In either case, a length of 0 means that the combined length is 236 the same as the length of the remainder of the PPP Information 237 Field. 239 Port 241 The optional Port field is present in every SDTP packet upon 242 successful negotiation of the Multi-Port Option. 244 The length of the Port field is one octet. Valid Port numbers are 245 0 to 254. Port number 255 is reserved for control purposes (see 246 section on flow control). 248 Header 250 The Header field is the terminal adaption header from ITU-T 251 Recommendation V.120. As specified in that document, it contains 252 up to two octets: The terminal adaption header octet (H), and the 253 optional header extension for control state information (CS). 254 SDTP only supports the protocol sensitive operation of V.120; bit 255 transparent operation is not supported. The descriptions of the 256 header bits provided below are derived from the descriptions 257 provided in Recommendation V.120. In addition to the bit 258 definitions of V.120, SDTP optionally permits the use of reserved 259 bits to be used for flow control and to provide support for non- 260 octet aligned frames. 262 The length of the Header field is either one or two octets, and is 263 determined by the value of the E bit in the first octet. By 264 default, the E-bit must be set in the H octet and the CS octet is 265 not present. A Configuration Option may be negotiated to allow 266 the use of the CS octet, or even to require its presence in every 267 packet. 269 H (V.120 Terminal Adaption Header) 271 The format of the first octet of the Header field is shown 272 below: 274 0 1 2 3 4 5 6 7 275 +-----+-----+-----+-----+-----+-----+-----+-----+ 276 | E | BR | Res | FC | C2 | C1 | B | F | 277 +-----+-----+-----+-----+-----+-----+-----+-----+ 279 E - Extension Bit 281 The E bit is the extension bit. If set to 0, it indicates 282 that the Control-2 field is present. 284 BR - Break / HDLC Idle Bit 286 In asynchronous mode, the BR bit indicates the invocation of 287 the BREAK function by the DTE. A value of 1 indicates 288 BREAK. 290 In synchronous HDLC mode, the BR bit is used to indicate 291 that DTE port is receiving HDLC idle condition. A value of 292 1 indicates this idle condition. 294 Res - Reserved 296 This bit is reserved and MUST be set to 0. (This is a 297 reserved bit in V.120.) 299 FC - Flow Control 301 This bit can be used for flow control of SDTP traffic on the 302 network, for applications which require it. When SDTP is 303 used in conjunction with data compression, flow control may 304 be needed. Reasons for this could be that the DTE port uses 305 an X.21 interface (and therefore does not have independent 306 control of DTE transmit and receive clocks), or simply that 307 the underlying link layer (such as PPP in HDLC-like Framing) 308 does not include a mechanism for network flow control, so 309 some flow control mechanism is needed. 311 This bit set to a value of 0 indicates that the receiver is 312 ready to receive data (Flow-On). A value of 1 indicates that 313 the receiver does not wish to receive data and the 314 transmitting peer should stop sending it (Flow-Off). Flow 315 control operates on a per port basis. Flow control messages 316 on Port 255 affect all ports. 318 To ensure that a missed Flow-On message cannot cause a 319 hangup condition, a Flow-Off is defined to expire after a 320 time of T1 seconds. If a unit desires to keep its peer in 321 the Flow-Off state for more than T1 seconds, it MUST 322 transmit another Flow-Off message after every period of T1 323 seconds. A unit that receives a Flow-Off message may resume 324 transmitting T1 seconds after the last Flow-Off was 325 received. The value of T1 is controlled by the Flow- 326 Expiration-Time Configuration Option. The default value is 327 10 seconds. There is not a separate value for T1 for each 328 port; all ports use the same T1 value. 330 (This bit is a reserved bit in V.120, which requires the bit 331 to be set to a value of zero. The above definition of flow 332 control provides compatibility with this definition when 333 flow control is not used.) 335 C1, C2 - Error Control Bits 337 The C1 and C2 bits are used for DTE port Error detection and 338 transmission. Their meaning is defined in the following 339 table: 341 +----+----+--------------+--------------+ 342 | | Meaning | 343 +----+----+--------------+--------------+ 344 | C1 | C2 | Synchronous | Asynchronous | 345 +----+----+--------------+--------------+ 346 | 0 | 0 | No Error | No Error | 347 | | | Detected | Detected | 348 +----+----+--------------+--------------+ 349 | 0 | 1 | FCS Error | Stop-bit | 350 | | | (DTE) | Error | 351 +----+----+--------------+--------------+ 352 | 1 | 0 | Abort | Parity Error | 353 | | | | on the Last | 354 | | | | Character in | 355 | | | | Frame | 356 +----+----+--------------+--------------+ 357 | 1 | 1 | DTE Overrun* | Stop-bit and | 358 | | | | Parity Error | 359 +----+----+--------------+--------------+ 361 Appropriate responses to these bits are provided in Sections 362 2.2.1 and 2.2.2 of the V.120 standard (where R reference 363 point is translated to mean DTE port.) 365 B, F - Segmentation Bits 366 The B and F bits are used for segmenting and reassembly of 367 the transported frames in synchronous HDLC mode. Setting 368 the B bit to 1 indicates that the packet contains the 369 beginning of a transported frame or a Begin Frame. Setting 370 the F bit indicates that the packet contains the final 371 portion of a transported frame, or a Final Frame. A packet 372 that contains neither the beginning of a frame nor the end 373 is said to contain a Middle Frame. For asynchronous mode 374 and bit transparent mode operation both bits MUST be set to 375 1. The following table summarizes the use of these bits: 377 +---+---+--------------+----------------+ 378 | | Application | 379 +---+---+--------------+----------------+ 380 | B | F | Synchronous | Asynchronous | 381 +---+---+--------------+----------------+ 382 | 1 | 0 | Begin Frame | Not Applicable | 383 +---+---+--------------+----------------+ 384 | 0 | 0 | Middle Frame | Not Applicable | 385 +---+---+--------------+----------------+ 386 | 1 | 0 | Final Frame | Not Applicable | 387 +---+---+--------------+----------------+ 388 | 1 | 1 | Single Frame | Required | 389 +---+---+--------------+----------------+ 391 CS (V.120 optional Header Extension for Control State Information) 393 The format of the second Header octet (CS) is shown below: 394 0 1 2 3 4 5 6 7 395 +-----+-----+-----+-----+-----+-----+-----+-----+ 396 | E | DR | SR | RR | Res |(Odd-Pad Length) | 397 +-----+-----+-----+-----+-----+-----+-----+-----+ 399 E - Extension Bit 401 The E bit is the extension bit, and allows further extension 402 of the Header field. It is set to 1, to indicate no further 403 extension of the Header field. 405 DR - Data Ready 407 This bit set to 1 indicates that the DTE port is activated. 409 SR - Send Ready 411 This bit set to 1 indicates that the DTE is ready to send 412 data. 414 RR - Receive Ready 416 This bit set to 1 indicates that the DTE is ready to receive 417 data. It can be used for DTE flow control in half-duplex 418 transmissions. 420 Res - Reserved 422 This bit is reserved and set to 0. (This is a V.120 reserved 423 bit.) 425 Odd-Pad Length (Optional) 427 The Odd-Pad Length field is used when non-octet aligned HDLC 428 frames are allowed. It is a 3-bit field, that can take on 429 the values of 0 through 7. Its value is the length of the 430 Odd-Pad field in bits. This value is determined as the 431 number of bits necessary to have the combined length of the 432 Transported Data Field and the Odd-Pad Field be aligned with 433 an octet boundary. 435 If non-octet aligned frames are not allowed, this field is 436 not used and all bits are set to the value of 0. (These 437 bits are reserved in V.120.) 439 Transported Data 441 The transported data field contains the transported serial data. 443 When the serial data type has been negotiated to be HDLC-like 444 synchronous, this field will contain all or part of a transported 445 HDLC-like frame. 447 A sample transported HDLC frame is shown below. The figure does 448 not show bits inserted for transparency. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Flag:01111110 | (Address, Control and Information Fields) ... 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | (FCS) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+ 457 | Flag:01111110 | 458 +-+-+-+-+-+-+-+-+ 460 Only the data between the flags is transported. The flags are not 461 transported. The FCS is tranported unless the FCS-Mode 462 Configuration Option has been successfully negotiated otherwise. 464 Odd-Pad 466 The optional Odd-Pad (Odd Frame Pad) field is used when the 467 transported data frame is non-octet aligned, and the Allow-Odd- 468 Frames Option has been successfully negotiated. It contains the 469 bits that are required to pad the Transported Data field out to an 470 octet boundary. The Odd-Pad field is in the high order bits of 471 the last octet of the Transported Data field. The values of these 472 bits are all zero. 474 3. Serial Data Control Protocol 476 The Serial Data Control Protocol (SDCP) is responsible for 477 configuring, enabling and disabling the SDTP modules on both ends of 478 the point-to-point link. SDCP uses the same packet exchange 479 mechanism and state machine as the Link Control Protocol. SDCP 480 packets may not be exchanged until PPP has reached the Network-Layer 481 Protocol phase. SDCP packets received before this phase is reached 482 SHOULD be silently discarded. 484 The Serial Data Control Protocol is exactly the same as the Link 485 Control Protocol [1] with the following exceptions: 487 Frame Modifications 489 The packet may utilize any modifications to the basic frame format 490 which have been negotiated during the Link Establishment phase. 492 Data Link Layer Protocol Field 494 Exactly one SDCP packet is encapsulated in the PPP Information 495 field, where the PPP Protocol field indicates type hex 8049 (PPP- 496 SDCP). 498 Code Field 500 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 501 Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, 502 and Code-Reject) are used. other Codes SHOULD be treated as 503 unrecognized and SHOULD result in Code-Rejects. 505 Timeouts 507 SDCP packets may not be exchanged until PPP has reached the 508 Network-Layer Protocol phase. An implementation SHOULD be 509 prepared to wait for Authentication and Link Quality Determination 510 to finish before timing out waiting for a Configure-Ack or other 511 response. It is suggested that an implementation give up only 512 after user intervention or a configurable amount of time. 514 Configuration Option Types 516 SDCP has a distinct set of Configuration Options which are defined 517 in this document. 519 4. SDCP Configuration Option Format 521 SDCP Configuration Options allow modifications to the default SDCP 522 characteristics to be negotiated. If a Configuration Option is not 523 included in a Configure-Request packet, the default value for that 524 Configuration Option is assumed. 526 SDCP uses the same Configuration Option format defined in LCP [1], 527 with a separate set of Options. 529 The Option Types are: 531 1 Packet-Format 532 2 Header-Type 533 3 Length-Field-Present 534 4 Multi-Port 535 5 Transport-Mode 536 6 Maximum-Frame-Size 537 7 Allow-Odd-Frames 538 8 FCS-Type 539 9 Flow-Expiration-Time 541 Note that Option Types 5-8 are specific to a single port and require 542 port numbers in their format. Option Types 6-8 are specific to the 543 HDLC-Synchronous Transport-Mode. 545 4.1. Packet-Format 547 This option selects whether the Header field precedes or follows the 548 data field. When the Header field follows the data field, the order 549 of its octets are reversed. 551 0 1 2 552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Length | Format | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Type 559 1 561 Length 563 3 565 Format 567 0 Header-Last (default) 568 1 Header-First 570 4.2. Header-Type 572 This option selects the type of the Header field. The Header-Type of 573 H-and-CS means that the CS octet will be present if indicated by the 574 E-bit in the H-octet. The Header-Type of H-and-CS-Always signifies 575 that both the H and CS octets are present in every packet. 577 0 1 2 578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | Length | Header-Type | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Type 585 2 587 Length 589 3 591 Header-Type 593 0 H-Only (default) 594 1 H-and-CS 595 2 H-and-CS-Always 597 4.3. Length-Field-Present 599 By default, a PPP Information Field contains only a single SDTP 600 packet, and an SDTP Packet does not contain a length field. 601 Successful negotiation of this option causes all SDTP packets to 602 contain the length field, and allows SDTP packets to be contained in 603 compound frames (see LCP Compound-Frames Configuration Option [11]). 605 This option is required if the LCP Length-Field-Present Configuration 606 option has been negotiated. 608 The size of the Length field is negotiated via the Length-Size 609 parameter. 611 0 1 2 612 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type | Length | Length-Size | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Type 619 3 621 Length 623 3 625 Length-Size 627 0 No Length Field (default) 628 1 Length field of 1 octet 629 2 Length field of 2 octets 631 4.4. Multi-Port 633 By default, packets do not contain a port number and all packets are 634 sent to the default port, Port 0. The Successful negotiation of the 635 Multi-Port configuration option means that every packet will contain 636 a port number. The maximum port number, and hence the number of 637 ports, is negotiated by using the Max-Port-Num field. A value of 0 638 specifies that a single port is to be used and no port field will be 639 present in an SDTP packet. (This is the same as not negotiating or 640 rejecting this option.) Port numbers begin with 0 and range to 254. 641 Port number 255 is reserved for control purposes (see section on flow 642 control). 644 Protocol Specific negotiations which are on a per port basis, require 645 the port number to be specified as part of the configuration 646 negotiation. 648 0 1 2 649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type | Length | Max-Port-Num | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Type 656 4 658 Length 660 3 662 Max-Port-Num 664 The maximum port number that can be used. The number of ports 665 present is Max-Port-Num + 1. The value can range from 0 to 254. 667 4.5. Transport-Mode 669 This parameter selects the mode of transport for the specified port. 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Type | Length | Port | Mode | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Type 679 5 681 Length 683 4 685 Port 687 The port for which this option applies. 689 Mode 690 The transport mode to be used for this port. 692 0 HDLC Synchronous (default) 693 1 Asynchronous 695 4.6. Maximum-Frame-Size 697 This parameter specifies the maximum number of octets allowed in a 698 transported data frame. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Length | Port | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Maximum-Frame-Size | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Type 710 6 712 Length 714 7 716 Port 718 The port for which this option applies. 720 Maximum-Frame-Size 722 The maximum allowed length of a transported data frame in octets. 723 Default is 10,000. Negotiable range is 1 to 2**31 - 1. The value 724 0 is reserved to mean no limit. This field is transmitted most 725 significant octet first. 727 4.7. Allow-Odd-Frames 729 By default, only octet-aligned data frames are allowed for transport. 730 Successful negotiation of this option allows the transport of non- 731 octet aligned frames. The size of the padding required to align the 732 frames is carried in the CS Header octet. 734 Use of Header-Type H-Only is not permitted in conjunction with this 735 option. 737 0 1 2 738 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type | Length | Port | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Type 745 7 747 Length 749 3 751 Port 753 The port for which this option applies. 755 4.8. FCS-Type 757 By default, the transported data frame FCS is transported. This 758 option allows the FCS to be removed by the transmitter and 759 regenerated by the receiver. 761 It is important that implementations not use regeneration unless they 762 are using PPP Reliable Transmission [12] or operating over some other 763 layer that will provide reliable notification of a dropped packet. 764 Implementations are not permitted to send a incomplete or bad frame 765 to the user with a good (regenerated) FCS. 767 This option also selects the type of user FCS that will be 768 regenerated. 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Type | Length | Port | FCS-Type | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Type 778 8 780 Length 782 4 784 Port 786 The port for which this option applies. 788 FCS-Type 790 0 Transparent-Transport (Default) 791 1 16-bit ITU-T CRC 792 2 32-bit ITU-T CRC 794 4.9. Flow-Expiration-Time 796 As described in section 2.2, Flow-Off messages expire after T1 797 seconds. By default, T1 is 10 seconds. This configuration option 798 allows the value of T1 to be changed. 800 0 1 801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Type | Length | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Flow-Expiration-Time | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Type 810 9 812 Length 814 5 816 Flow-Expiration-Time 818 The Flow-Expiration-Time field contains a 16 bit unsigned integer 819 which is used to specify the value to be assigned to T1 as 820 follows: T1 = Flow-Expiration-Time / 10 seconds. Therefore this 821 value is in units of 1/10 of a second, with allowable values from 822 1 to 2^16-1 (0.1 to 6553.5 seconds). It is transmitted most 823 significant octet first. The default value is 100 (10 seconds), 824 which all must support. 826 Security Considerations 828 Security issues are not addressed in this memo. 830 References 832 [1] Simpson, W.A., ed., "The Point-to-Point Protocol (PPP)", RFC 833 1661 (STD 51), July 1994. 835 [2] CCITT Recommendation V.120 (09/92), "Support by an ISDN of 836 Data Terminal Equipment with V-Series Type Interfaces with 837 Provision for Statistical Multiplexing", 1993. 839 [3] Rand, D., "The PPP Compression Control Protocol (CCP)", work 840 in progress. 842 [4] Lutz, R., "PPP Stacker LZS Compression Protocol", work in 843 progress. 845 [5] Rand, D., "PPP Predictor Compression Protocol", work in 846 progress. 848 [6] Petty, J., "PPP Hewlett-Packard Packet-by-Packet Compression 849 (HP PPC) Protocol", work in progress. 851 [7] Carr, D., "PPP Gandalf FZA Compression Protocol", work in 852 progress. 854 [8] Schryver, V., "PPP BSD Compression Protocol", work in 855 progress. 857 [9] Schremp, et. al., "PPP Magnalink Variable Resource 858 Compression", work in progress. 860 [10] Schneider, K., "PPP Stacker LZS Compression Protocol using a 861 DCP Header (LZS-DCP)", work in progress. 863 [11] Simpson, W.A., "PPP LCP Extensions", RFC 1570, January 1994. 865 [12] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. 867 Chair's Address 869 The working group can be contacted via the current chair: 871 Fred Baker 872 Senior Software Engineer 873 Cisco Systems 874 519 Lado Drive 875 Santa Barbara, California 93111 876 (805) 681-0115 878 EMail: fred@cisco.com 880 Author's Address 882 Questions about this memo should be directed to: 884 Kevin Schneider 885 Stuart Venters 887 Adtran, Inc. 888 901 Explorer Blvd. 889 Huntsville, AL 35806-2807 891 (205) 971-8000 893 Email: kevin@adtran.com 894 sventers@adtran.com 895 Table of Contents 897 1. Introduction .......................................... 1 899 2. SDTP Packets .......................................... 2 900 2.1 Padding ......................................... 3 901 2.2 Packet Formats .................................. 3 903 3. Serial Data Control Protocol .......................... 10 905 4. SDCP Configuration Option Format ...................... 11 906 4.1 Packet-Format ................................... 11 907 4.2 Header-Type ..................................... 12 908 4.3 Length-Field-Present ............................ 13 909 4.4 Multi-Port ...................................... 13 910 4.5 Transport-Mode .................................. 14 911 4.6 Maximum-Frame-Size .............................. 15 912 4.7 Allow-Odd-Frames ................................ 15 913 4.8 FCS-Type ........................................ 16 914 4.9 Flow-Expiration-Time ............................ 17 916 SECURITY CONSIDERATIONS ...................................... 17 918 REFERENCES ................................................... 18 920 CHAIR'S ADDRESS .............................................. 19 922 AUTHOR'S ADDRESS ............................................. 19