datatracker.ietf.org
Sign in
Version 5.6.4, 2014-10-13
Report a bug

PPP in HDLC Framing
RFC 1549

Document type: RFC - Draft Standard (December 1993; No errata)
Obsoleted by RFC 1662
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 1549 (Draft Standard)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                 W. Simpson, Editor
Request for Comments: 1549                                    Daydreamer
Category: Standards Track                                  December 1993

                          PPP in HDLC Framing

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   This document describes the use of HDLC for framing PPP encapsulated
   packets. This document is the product of the Point-to-Point Protocol
   Working Group of the Internet Engineering Task Force (IETF).
   Comments should be submitted to the ietf-ppp@ucdavis.edu mailing
   list.

Table of Contents

   1.   Introduction ..................................................2
   1.1  Specification of Requirements .................................2
   1.2  Terminology ...................................................3
   2.   Physical Layer Requirements ...................................3
   3.   The Data Link Layer ...........................................4
   3.1  Frame Format ..................................................5
   3.2  Modification of the Basic Frame ...............................7
   4.   Asynchronous HDLC .............................................7
   5.   Bit-synchronous HDLC ..........................................5
   6.   Octet-synchronous HDLC ........................................12
   APPENDIX A. Fast Frame Check Sequence (FCS) Implementation .........13
   A.1  FCS Computation Method ........................................13
   A.2  Fast FCS table generator ......................................15
   SECURITY CONSIDERATIONS ............................................16
   REFERENCES .........................................................17
   ACKNOWLEDGEMENTS ...................................................17
   CHAIR'S ADDRESS ....................................................18
   EDITOR'S ADDRESS ...................................................18

Simpson                                                         [Page 1]
RFC 1549                      HDLC Framing                Decvember 1993

1.  Introduction

   This specification provides for framing over both bit-oriented and
   octet-oriented synchronous links, and asynchronous links with 8 bits
   of data and no parity.  These links MUST be full-duplex, but MAY be
   either dedicated or circuit-switched.  PPP uses HDLC as a basis for
   the framing.

   An escape mechanism is specified to allow control data such as
   XON/XOFF to be transmitted transparently over the link, and to remove
   spurious control data which may be injected into the link by
   intervening hardware and software.

   Some protocols expect error free transmission, and either provide
   error detection only on a conditional basis, or do not provide it at
   all.  PPP uses the HDLC Frame Check Sequence for error detection.
   This is commonly available in hardware implementations, and a
   software implementation is provided.

1.1 Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

    MUST

      This word, or the adjective "required", means that the definition
      is an absolute requirement of the specification.

    MUST NOT

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

    SHOULD

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

    MAY

      This word, or the adjective "optional", means that this item is
      one of an allowed set of alternatives.  An implementation which
      does not include this option MUST be prepared to interoperate with
      another implementation which does include the option.

Simpson                                                         [Page 2]
RFC 1549                      HDLC Framing                Decvember 1993

1.2 Terminology

   This document frequently uses the following terms:

    datagram

      The unit of transmission in the network layer (such as IP).  A

[include full document text]