[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                           W A Simpson [DayDreamer]
Internet Draft
expires in six months                                      November 1997


                              PPP in X.25
                    draft-ietf-pppext-x25-ds-00.txt


Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) [RFC-1661] 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.

Applicability

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



Simpson                   expires in six months                 [Page i]


DRAFT                          PPP in X.25                 November 1997


   environments.

   Use of X.25 as a secondary framing mechanism (for example, with asyn-
   chronous HDLC-like frames tunnelled through X.3) is outside the scope
   of this specification.














































Simpson                   expires in six months                [Page ii]


DRAFT                          PPP in X.25                 November 1997


1.  Introduction

   CCITT recommendation X.25 [X.25] 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.

   At one time, it had been hoped that "PPP in HDLC-like Framing"
   [RFC-1662] would co-exist with other X.25 transmissions 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 proto-
   col such as Frame Relay, and reconstruct the X.25 header at the final
   hop.  Co-existance and gradual migration are precluded.

   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 equiva-
   lent to the technique used to carry SNAP headers over X.25
   [RFC-1356].


1.1.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC-2119].

   To remain consistent with standard Internet practice, and avoid con-
   fusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least Signifi-
   cant Bit order, from Most Significant Byte to Least Significant Byte,
   reading from left to right, unless otherwise indicated.  Note that
   this is contrary to ISO and ITU practice, which orders bits as trans-
   mitted (network bit order).  Keep this in mind when comparing this
   document with the other documents.


2.  Physical Layer Requirements

   PPP is capable of operating across most X.25 interfaces.  The only
   absolute requirement imposed by PPP is the provision of a bi-
   directional full-duplex circuit, either dedicated (permanent) or cir-
   cuit-switched, that can operate in a bit-synchronous mode, transpar-
   ent to PPP Data Link Layer frames.







Simpson                   expires in six months                 [Page 1]


DRAFT                          PPP in X.25                 November 1997


   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,
      that indicate when the link has become connected or disconnected.
      These in turn provide the Up and Down events to the PPP 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 [RFC-1662].


2.1.  Transmission Considerations

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

   While PPP will operate without regard to the underlying representa-
   tion of the bit stream, bit-synchronous X.25 requires NRZ encoding.


3.  The Data Link Layer

   This specification uses the principles, terminology, and frame struc-
   ture described in [RFC-1356].

   The purpose of this specification is not to document what is already
   standardized in [RFC-1356].  Instead, this document attempts to give
   a concise summary and point out specific options and features used by
   PPP.










Simpson                   expires in six months                 [Page 2]


DRAFT                          PPP in X.25                 November 1997


3.1.  Frame Header

   Since both "PPP in HDLC-like Framing" [RFC-1662] and X.25 use ISO
   3309 as a basis for framing, the X.25 header is easily substituted
   for the smaller HDLC header.  These fields are transmitted from left
   to right.

    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
   +-+-+-+-+-+-+-+-+
   |  Flag (0x7e)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+?+?+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Address    |    Control    |0|0| SVC# (hi) |   SVC# (lo)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |p(r) |M|p(s) |0|         PPP Protocol          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PPP Protocol field and the following Information and Padding
   fields are described in the Point-to-Point Protocol Encapsulation
   [RFC-1661].


3.2.  Modification of the Basic Frame

   The Link Control Protocol can negotiate modifications to the basic
   frame structure.  This is not compatible with X.25.

   Address-and-Control-Field-Compression

      Since the X.25 Address and Control field values are not constant,
      and are modified as the frame is transported by the network
      switching fabric, Address-and-Control-Field-Compression cannot
      affect the frame format.

   FCS-Alternatives

      Since X.25 requires a 16-bit FCS, which is modified as the frame
      is transported by the network switching fabric, FCS-Alternatives
      cannot affect the frame format.

   In general, framing-related LCP Configuration Options are not recog-
   nizable, and are not acceptable for negotiation.  The implementation
   MUST NOT send ineffectual options in a Configure-Request, and SHOULD
   respond to such requested options with a Configure-Reject.  See [RFC-
   ffff] for details.






Simpson                   expires in six months                 [Page 3]


DRAFT                          PPP in X.25                 November 1997


3.3.  Modification of the Basic Packet

   The Link Control Protocol can negotiate modifications to the basic
   packet structure.  These are transparent to X.25.

   Protocol-Field-Compression

      The X.25 framing does not align the PPP Information field on a
      32-bit boundary.  Alignment to a 16-bit boundary occurs when the
      Protocol field is compressed to a single octet.  When this
      improves throughput, Protocol-Field-Compression SHOULD be negoti-
      ated.







































Simpson                   expires in six months                 [Page 4]


DRAFT                          PPP in X.25                 November 1997


4.  Call Setup

   When the link is configured as a Permanent Virtual Circuit (PVC),
   support for Switched Virtual Circuit (SVC) call setup and clearing is
   not required.  Calls are Established and Terminated using PPP LCP
   packets.

   When the link is configured as a Switched Virtual Circuit (SVC), the
   first octet in the Call User Data (CUD) Field (the first data octet
   in the Call Request packet) is used for protocol demultiplexing, in
   accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC
   TR 9577 [TR 9577].  This field contains a one octet Network Layer
   Protocol Identifier (NLPID), which identifies the encapsulation in
   use over the X.25 virtual circuit.  The CUD field MAY contain more
   than one octet of information.

   The PPP encapsulation MUST be indicated by the PPP NLPID value (CF
   hex).  Any subsequent octet in this CUD is extraneous and MUST be
   ignored.

   Multipoint networks (or multicast groups) MUST refuse calls which
   indicate the PPP NLPID in the CUD.

   The accidental connection of a link to feed a multipoint network (or
   multicast group) SHOULD result in a misconfiguration indication.
   This can be detected by multiple responses to the LCP Configure-
   Request with the same Identifier, coming from different framing
   addresses.  Some implementations might be physically unable to either
   log or report such information.

   Conformance with this specification requires that the PPP NLPID (CF)
   be supported.  In addition, conformance with [RFC-1356] requires that
   the IP NLPID (CC) be supported, and does not require that other NLPID
   values be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS
   (82).

   When IP address negotiation and/or VJ header compression are desired,
   the PPP call setup SHOULD be attempted first.  If the PPP call setup
   fails, the normal IP call setup MUST be used.

   The PPP NLPID value SHOULD NOT be used to demultiplex circuits that
   use the Zero NLPID in call setup, as described in [RFC-1356].  When
   such a circuit exists concurrently with PPP encapsulated circuits,
   only network layer traffic which has not been negotiated by the asso-
   ciated NCP is sent over the Zero NLPID circuit.






Simpson                   expires in six months                 [Page 5]


DRAFT                          PPP in X.25                 November 1997


   Rationale:

      Using call setup to determine if PPP is supported should be inex-
      pensive, when users aren't charged for failed calls.

      Using the Zero NLPID call together with PPP could be expensive,
      when users are charged per packet or for connect time, due to the
      probing of PPP configuration packets at each call.

      PPP configuration provides a direct indication of the availability
      of service, and on that basis is preferred over the Zero NLPID
      technique, which can result in "black-holes".


5.  Configuration Details

   The following Configuration Options are recommended:

      Magic Number
      Protocol Field Compression

   The standard LCP configuration defaults apply to X.25 links, except
   Maximum-Receive-Unit (MRU).

   To ensure interoperability with existing X.25 implementations, the
   initial MRU is 1600 octets [RFC-1356].  This only affects the minimum
   required buffer space available for receiving packets, not the size
   of packets sent.

   The typical network feeding the link is likely to have a MRU of
   either 1500, or 2048 or greater.  To avoid fragmentation, the Maxi-
   mum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed
   1500, unless a peer MRU of 2048 or greater is specifically negoti-
   ated.

   The X.25 packet size is not directly related to the MRU.  Instead,
   Protocol Data Units (PDUs) are sent as X.25 "complete packet
   sequences".  That is, PDUs begin on X.25 data packet boundaries and
   the M bit ("more data") is used to fragment PDUs that are larger than
   one X.25 data packet in length.











Simpson                   expires in six months                 [Page 6]


DRAFT                          PPP in X.25                 November 1997


Security Considerations

   Implementations MUST NOT consider PPP authentication on call setup
   for one circuit between two systems to apply to concurrent call setup
   for other circuits between those same two systems.  This results in
   possible security lapses due to over-reliance on the integrity and
   security of switching systems and administrations.  An insertion
   attack might be undetected.  An attacker which is able to spoof the
   same calling identity might be able to avoid link authentication.


Acknowledgements

   This design was inspired by the paper "Parameter Negotiation for the
   Multiprotocol Interconnect", Keith Sklower and Clifford Frost, Uni-
   versity of California, Berkeley, 1992, unpublished.


References

   [RFC-1356]  Malis, A., Robinson, D., Ullman R., "Multiprotocol Inter-
               connect on X.25 and ISDN in the Packet Mode", August
               1992.

   [RFC-1661]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
               STD-51, DayDreamer, July 1994.

   [RFC-1662]  Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51,
               DayDreamer, July 1994.

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, Harvard University, March
               1997.

   [RFC-ffff]  Simpson, W., "PPP with Framing Conversion", work in
               progress.

   [TR 9577]   ISO/IEC TR 9577:1990(E), "Information technology -
               Telecommunications and Information exchange between sys-
               tems - Protocol Identification in the network layer",
               1990-10-15.

   [X.25]      CCITT Recommendation X.25, "Interface Between Data Termi-
               nal Equipment (DTE) and Data Circuit Terminating Equip-
               ment (DCE) for Terminals Operating in the Packet Mode on
               Public Data Networks", International Telecommunication
               Union, CCITT Red Book, Volume VIII, Fascicle VIII.2, Rec.
               X.25, October 1984.



Simpson                   expires in six months                 [Page 7]


DRAFT                          PPP in X.25                 November 1997


Contacts

   Comments about this document should be discussed on the ietf-
   ppp@merit.edu mailing list.

   This document was reviewed by the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  The working
   group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      655 Metro Place South,  Suite 370
      Dublin, Ohio  43017

          karl@Ascend.com

   Questions about this document can also be directed to:

      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)

























Simpson                   expires in six months                 [Page 8]