PPP in X.25
RFC 1598

Network Working Group                                         W. Simpson
Request for Comments: 1598                                    Daydreamer
Category: Standards Track                                     March 1994

                              PPP in X.25

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 X.25 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@merit.edu mailing list.

Applicability

   This specification is intended for those implementations which desire
   to use facilities which are defined for PPP, such as the Link Control
   Protocol, Network-layer Control Protocols, authentication, and
   compression.  These capabilities require a point-to-point
   relationship between peers, and are not designed for multi-point or
   multi-access environments.

Simpson                                                         [Page i]

RFC 1598                      PPP in X.25                     March 1994

                           Table of Contents

     1.     Introduction ..........................................    1

     2.     Physical Layer Requirements ...........................    2

     3.     The Data Link Layer ...................................    2
        3.1       Frame Format ....................................    3
        3.2       Modification of the Basic Frame .................    3

     4.     Call Setup ............................................    4

     5.     Configuration Details .................................    5

     SECURITY CONSIDERATIONS ......................................    6

     REFERENCES ...................................................    6

     ACKNOWLEDGEMENTS .............................................    6

     CHAIR'S ADDRESS ..............................................    7

     AUTHOR'S ADDRESS .............................................    7

1.  Introduction

   CCITT recommendation X.25 [2] describes a network layer protocol
   providing error-free, sequenced, flow controlled, virtual circuits.
   X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
   and 6256.

   PPP also uses ISO 3309 HDLC as a basis for its framing [3].

   When X.25 is configured as a point-to-point circuit, PPP can use X.25
   as a framing mechanism, ignoring its other features.  This is
   equivalent to the technique used to carry SNAP headers over X.25 [4].

   At one time, it had been hoped that PPP HDLC frames and X.25 frames
   would co-exist on the same links.  Equipment could gradually be
   converted to PPP.  Subsequently, it has been learned that some
   switches actually remove the X.25 header, transport packets to
   another switch using a different protocol such as Frame Relay, and
   reconstruct the X.25 header at the final hop.  Co-existance and
   gradual migration are precluded.

Simpson                                                         [Page 1]

RFC 1598                      PPP in X.25                     March 1994

2.  Physical Layer Requirements

   PPP treats X.25 framing as a bit synchronous link.  The link MUST be
   full-duplex, but MAY be either dedicated (permanent) or switched.

   Interface Format

      PPP presents an octet interface to the physical layer.  There is
      no provision for sub-octets to be supplied or accepted.

   Transmission Rate

      PPP does not impose any restrictions regarding transmission rate,
      other than that of the particular X.25 interface.

   Control Signals

      Implementation of X.25 requires the provision of control signals,
      which indicate when the link has become connected or disconnected.
      These in turn provide the Up and Down events to the LCP state
      machine.

      Because PPP does not normally require the use of control signals,
      the failure of such signals MUST NOT affect correct operation of
      PPP.  Implications are discussed in [2].

   Encoding

      The definition of various encodings is the responsibility of the
      DTE/DCE equipment in use, and is outside the scope of this
      specification.

      While PPP will operate without regard to the underlying
      representation of the bit stream, X.25 requires NRZ encoding.

3.  The Data Link Layer