[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 Frame Relay
                 draft-ietf-pppext-framerelay-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 Frame Relay 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 Frame Relay              November 1997


   environments.


















































Simpson                   expires in six months                [Page ii]


DRAFT                      PPP in Frame Relay              November 1997


1.  Introduction

   Frame Relay [Q.922] is a relative newcomer to the serial link commu-
   nity.  Like X.25, the protocol was designed to provide virtual cir-
   cuits for connections between stations attached to the same Frame
   Relay network.  The improvement over X.25 is that Q.922 is restricted
   to delivery of packets, and dispenses with sequencing and flow con-
   trol, simplifying the service immensely.

   At one time, it had been hoped that "PPP in HDLC-like Framing"
   [RFC-1662] would co-exist with other Frame Relay transmissions on the
   same links.  Unfortunately, the Q.922 method for expanding the
   address from 1 to 2 to 4 octets is not reliably distinguishable from
   the ISO 3309 HDLC method, due to the structure of its Data Link Con-
   nection Identifier (DLCI) subfields.  Co-existance is precluded.

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


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 Frame Relay interfaces.  The
   only absolute requirement imposed by PPP is the provision of a bi-
   directional full-duplex circuit, either dedicated (permanent) or
   frame-switched, that can operate in either a bit-synchronous, or
   octet-synchronous mode, transparent to PPP Data Link Layer frames.






Simpson                   expires in six months                 [Page 1]


DRAFT                      PPP in Frame Relay              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 Frame Relay interface.

   Control Signals

      Implementation of Frame Relay requires the provision of control
      signals, that indicate when the link has become connected or dis-
      connected.  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 speci-
      fication.

      While PPP will operate without regard to the underlying represen-
      tation of the octet stream, bit-synchronous Frame Relay requires
      NRZ encoding.

      In addition, this specification permits octet-synchronous Frame
      Relay, with the same stuffing conventions as HDLC [RFC-1662].


   3.  The Data Link Layer

      This specification uses the principles, terminology, and frame
      structure described in [RFC-1490].

      The purpose of this specification is not to document what is
      already standardized in [RFC-1490].  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 Frame Relay              November 1997


   3.1.  Frame Header

      As described in [RFC-1490], Q.922 header address and control
      fields are followed by a Network Layer Protocol Identifier (NLPID)
      to identify the encapsulated packet.  This specification describes
      the PPP Protocol encapsulation.  These fields are transmitted from
      left to right.

      +-+-+-+-+-+-+-+-+
      |  Flag (0x7e)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         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 Frame Relay.

      Address-and-Control-Field-Compression

         Since Frame Relay Address and Control field values are not con-
         stant, are variable size, 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 Frame Relay 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 rec-
      ognizable, and are not acceptable for negotiation.  The implemen-
      tation 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 Frame Relay              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 Frame Relay.

      Protocol-Field-Compression

         The default Frame Relay header does not align the PPP Informa-
         tion field on a 32-bit boundary.  Alignment to a 32-bit bound-
         ary occurs when the NLPID is removed and the PPP Protocol field
         is compressed to a single octet.  When this improves through-
         put, Protocol-Field-Compression SHOULD be negotiated.


   4.  In-Band Protocol Demultiplexing

      The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish
      the PPP encapsulation from the other NLPID encapsulations
      described in [RFC-1490].

      The joining of the PPP and NLPID number space has an added advan-
      tage, in that the LCP Protocol-Reject can be used to indicate
      NLPIDs that are not recognized.  This can eliminate "black-holes"
      that occur when traffic is not supported.

      For those network-layer protocols that have no PPP Protocol
      assignment, or have not yet been implemented under the PPP encap-
      sulation, or have not been successfully negotiated by a PPP NCP,
      another method of encapsulation defined under [RFC-1490] SHOULD be
      used.

      Currently, there are no conflicts between NLPID and PPP Protocol
      values.  If a future implementation is configured to send a NLPID
      value which is the same as a compressed Protocol field, that Pro-
      tocol field MUST NOT be sent compressed.

      On reception, the first octet following the Control field is exam-
      ined:

      -  If the octet is zero, it MUST be assumed that the packet is
         formatted according to [RFC-1490].

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

      -  If the octet is not the PPP NLPID value, and Protocol-Field-
         Compression is enabled, and the associated NCP has been



Simpson                   expires in six months                 [Page 4]


DRAFT                      PPP in Frame Relay              November 1997


         negotiated, then it is expected to be a compressed PPP Protocol
         value.

      -  Otherwise, it MUST be assumed that the packet is formatted
         according to [RFC-1490].

      Once PPP has entered the Link Establishment phase, packets with
      other NLPID values MUST NOT be sent, and on receipt such packets
      MUST be silently discarded, until the PPP link enters the Network-
      Layer Protocol phase.

      Once PPP has entered the Network-Layer Protocol phase, and suc-
      cessfully negotiated a particular NCP for a PPP Protocol, if a
      frame arrives using another equivalent data encapsulation defined
      in [RFC-1490], the PPP Link MUST re-enter Link Establishment phase
      and send a new LCP Configure-Request.  This prevents "black-holes"
      that occur when the peer loses state.

      An implementation that requires PPP link configuration, and other
      PPP negotiated features (such as authentication), MAY enter Termi-
      nation phase when configuration fails.  Otherwise, when the Con-
      figure-Request sender reaches the Max-Configure limit, it MUST
      fall back to send only frames encapsulated according to
      [RFC-1490].

      Implementation Notes

         The PPP Protocol field value 0x00cf is not allowed (reserved)
         to avoid ambiguity when Protocol-Field-Compression is enabled.
         For consistency, the NLPID value 0xcf MAY be treated as a com-
         pressed PPP Protocol which indicates that another PPP Protocol
         packet follows.

         The accidental connection of a link to feed a multipoint net-
         work (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.


   5.  Out-of-Band signaling

      There is no generally agreed method of out-of-band signalling.
      Until such a method is universally available, an implementation
      MUST use In-Band Protocol Demultiplexing for both Permanent and
      Switched Virtual Circuits.




Simpson                   expires in six months                 [Page 5]


DRAFT                      PPP in Frame Relay              November 1997


   6.  Configuration Details

      The following Configuration Options are recommended:

         Magic Number
         Protocol Field Compression

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

      To ensure interoperability with existing Frame Relay implementa-
      tions, the initial MRU is 1600 octets [RFC-1490].  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 Max-
      imum-Transmission-Unit (MTU) at the network layer SHOULD NOT
      exceed 1500, unless a peer MRU of 2048 or greater is specifically
      negotiated.

      Some Frame Relay switches are only capable of 262 octet frames.
      It is not recommended that anyone deploy or use a switch that is
      capable of less than 1600 octet frames.  However, PPP implementa-
      tions MUST be configurable to limit the size of LCP packets that
      are sent to 259 octets (leaving room for the NLPID and PPP Proto-
      col fields), until LCP negotiation is complete.

      XID negotiation is not required to be supported for links that are
      capable of PPP negotiation.

      Inverse ARP is not required to be supported for PPP links.  That
      function is provided by PPP NCP negotiation.


   Security Considerations

      This specification introduces no known security risks.













Simpson                   expires in six months                 [Page 6]


DRAFT                      PPP in Frame Relay              November 1997


   Acknowledgements

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

      Use of octet-synchronous interfaces, such as SONET/SDH, was first
      proposed by John Bartell (BellSouth).


   References

      [Q.922]  CCITT Recommendation Q.922, "ISDN Data Link Layer Speci-
               fication for Frame Mode Bearer Services", International
               Telegraph and Telephone Consultative Committee, 1992.

      [RFC-1490]
               Bradley, T., Brown, C., and Malis, A., "Multiprotocol
               Interconnect over Frame Relay", July 1993.

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















Simpson                   expires in six months                 [Page 7]


DRAFT                      PPP in Frame Relay              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]