Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-ietf-pppext-x25-01.txt

Text File | 1993-07-08 | 11.6 KB | 443 lines

Network Working Group                                        W A Simpson
Internet Draft                                                Daydreamer
expires in six months                                          July 1993


                              PPP in X.25



Status of this Memo

   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 [e-mail] mailing list.

   Distribution of this memo is unlimited.

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

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

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

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
   datagrams.











Simpson                  expires in six months                  [Page i]
DRAFT                         PPP in X.25                      July 1993


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.  The capabilities that are provided by X.25 are considered
   unnecessary and overly complex.

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

   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.

   There are still ISO-lated pockets of existing X.25 links, and some
   interest in bringing the advantages of the PPP multiprotocol datagram
   service to this venue.

   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.


























Simpson                  expires in six months                  [Page 1]
DRAFT                         PPP in X.25                      July 1993


2.  The Data Link Layer

   This specification uses the principles, terminology, and frame
   structure of the "Multiprotocol Interconnect on X.25 and ISDN in the
   Packet Mode" [4].

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


2.1.  Frame Format

   Since both PPP and X.25 use ISO 3309 as a basis for framing, the full
   X.25 header is easily substituted for the smaller HDLC header.  The
   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    |D|Q| SVC# (hi) |   SVC# (lo)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |p(r) |M|p(s) |0|  NLPID(0xcf)  |         PPP Protocol          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   NLPID

      This field contains a one octet Network Layer Protocol Identifier
      (NLPID), which identifies the network layer protocol encapsulated
      over the X.25 virtual circuit, in accordance with the Subsequent
      Protocol Identifier (SPI) in ISO/IEC TR 9577 [5].  The value used
      for PPP is <TBD> CF hex.

   Protocol Field

      The Protocol field is two octets and its value identifies the
      protocol encapsulated in the Information field of the frame.  The
      field is transmitted and received most significant octet first.


2.2.  Modification of the Basic Frame

   The Link Control Protocol can negotiate modifications to the basic
   frame structure.  However, modified frames will always be clearly



Simpson                  expires in six months                  [Page 2]
DRAFT                         PPP in X.25                      July 1993


   distinguishable from standard frames.

   Address-and-Control-Field-Compression

      Because the 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 MUST NOT be
      negotiated.

   Protocol-Field-Compression

      When Protocol-Field-Compression is negotiated, both the NLPID and
      Protocol fields are compressed.

      On transmission, when the Protocol field is compressed to a single
      octet, the NLPID is omitted.

      On reception, the NLPID field is examined.  If it is not the PPP
      NLPID value, then it is expected to be a valid PPP Protocol value.

      The Protocol field value 0x00cf is not allowed (reserved) to avoid
      ambiguity when Protocol-Field-Compression is enabled.


3.  In-Band Frame Format Detection

   For Permanent Virtual Circuits (PVCs), the NLPID and PPP Protocol
   fields easily distinguish the PPP encapsulation.

   Initial LCP packets contain the sequence cf-c0-21 following the
   header.  When a PPP LCP Configure-Request packet is received, the
   link enters Link Establishment phase.

   Older implementations might contain the NLPID value CC hex, which is
   used for IP.  Other ISO conformant implementations might contain
   other NLPID values, such as 80 hex (SNAP), or 81 hex (CLNP).  Such
   values indicate that the link is not properly configured for PPP
   operation.


4.  Out-of-Band signaling

   Support for Switched Virtual Circuit (SVC) call setup and clearing is
   not required.

   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



Simpson                  expires in six months                  [Page 3]
DRAFT                         PPP in X.25                      July 1993


   (SPI) in ISO/IEC TR 9577 [5].  This field contains a one octet
   Network Layer Protocol Identifier (NLPID), which identifies the
   network layer protocol encapsulated over the X.25 virtual circuit.
   The CUD field MAY contain more than one octet of information, and
   receivers MUST ignore all extraneous octets in the field.

   The PPP encapsulation MUST be indicated by a value of CF hex.  Other
   values of the CUD are beyond the scope of this specification.


5.  Configuration Details

   The accidental connection of a link to feed an X.25 multipoint
   network SHOULD result in a misconfiguration indication.

   The following Configuration Options are recommended:

      Magic Number
      Link Quality Monitoring
      Protocol Field Compression

   The standard LCP configuration defaults apply to X.25 links, except
   MRU.

   To ensure interoperability with existing X.25 implementations, the
   default Maximum-Receive-Unit (MRU) is 1600 octets [4].  The basic
   HDLC header is significantly shorter than the full-sized X.25 header,
   which may give additional leeway in buffer management.

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

   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 4]
DRAFT                         PPP in X.25                      July 1993


Security Considerations

   Security issues are not discussed in this memo.


References

   [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
         progress.

   [2]   CCITT Recommendation X.25, "Interface Between Data Terminal
         Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
         for Terminals Operating in the Packet Mode on Public Data
         Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.

   [3]   Simpson, W. A., "PPP HDLC Framing", work in progress.

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

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


Acknowledgments

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





















Simpson                  expires in six months                  [Page 5]
DRAFT                         PPP in X.25                      July 1993


Chair's Address

   The working group can be contacted via the current chair:

      Fred Baker
      Advanced Computer Communications
      315 Bollay Drive
      Santa Barbara, California, 93111

      EMail: [e-mail]


Author's Address

   Questions about this memo can also be directed to:

      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      P O Box 6205
      East Lansing, MI  48826-6205

      EMail: [e-mail]




























Simpson                  expires in six months                  [Page 6]
DRAFT                         PPP in X.25                      July 1993


                           Table of Contents


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

     2.     The Data Link Layer ...................................    2
        2.1       Frame Format ....................................    2
        2.2       Modification of the Basic Frame .................    2

     3.     In-Band Frame Format Detection ........................    3

     4.     Out-of-Band signaling .................................    3

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

     SECURITY CONSIDERATIONS ......................................    5

     REFERENCES ...................................................    5

     ACKNOWLEDGEMENTS .............................................    5

     CHAIR'S ADDRESS ..............................................    6

     AUTHOR'S ADDRESS .............................................    6