GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1973

Network Working Group W. Simpson Request for Comments: 1973 Daydreamer Category: Standards Track June 1996

                         PPP in Frame Relay

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 Frame Relay for framing PPP
 encapsulated packets.

Applicability

 This specification is intended for those implementations which desire
 to use facilities which are defined for PPP, such as the Link Control

Simpson Standards Track [Page i] RFC 1973 PPP in Frame Relay June 1996

 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.

Table of Contents

   1.     Introduction ..........................................    1
   2.     Physical Layer Requirements ...........................    1
   3.     The Data Link Layer ...................................    2
      3.1       Frame Format ....................................    2
      3.2       Modification of the Basic Frame .................    3
   4.     In-Band Protocol Demultiplexing .......................    4
   5.     Out-of-Band signaling .................................    5
   6.     Configuration Details .................................    5
   SECURITY CONSIDERATIONS ......................................    7
   REFERENCES ...................................................    7
   ACKNOWLEDGEMENTS .............................................    7
   CHAIR'S ADDRESS ..............................................    8
   AUTHOR'S ADDRESS .............................................    8

Simpson Standards Track [Page ii] RFC 1973 PPP in Frame Relay June 1996

1. Introduction

 Frame Relay [2] is a relative newcomer to the serial link community.
 Like X.25, the protocol was designed to provide virtual circuits 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 control,
 simplifying the service immensely.
 PPP uses ISO 3309 HDLC as a basis for its framing [3].
 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 [4].
 At one time, it had been hoped that PPP in HDLC-like frames and Frame
 Relay would co-exist on the same links.  Unfortunately, the Q.922
 method for expanding the address from 1 to 2 to 4 octets is not
 indistinguishable from the ISO 3309 method, due to the structure of
 its Data Link Connection Identifier (DLCI) subfields.  Co-existance
 is precluded.

2. Physical Layer Requirements

 PPP treats Frame Relay 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 Frame Relay interface.
 Control Signals
    Implementation of Frame Relay 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.

Simpson Standards Track [Page 1] RFC 1973 PPP in Frame Relay June 1996

    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, Frame Relay requires NRZ
    encoding.

3. The Data Link Layer

 This specification uses the principles, terminology, and frame
 structure described in "Multiprotocol Interconnect over Frame Relay"
 [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.

3.1. Frame Format

 As described in [4], Q.922 header address and control fields are
 combined with the Network Layer Protocol Identifier (NLPID), which
 identifies the encapsulation which follows.  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)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         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

Simpson Standards Track [Page 2] RFC 1973 PPP in Frame Relay June 1996

 [1].

3.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
 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
    Note that unlike PPP in HDLC-like framing, the Frame Relay framing
    does not align the Information field on a 32-bit boundary.
    Alignment to a 32-bit boundary occurs when the NLPID is removed
    and the Protocol field is compressed to a single octet.  When this
    improves throughput, Protocol-Field-Compression SHOULD be
    negotiated.

Simpson Standards Track [Page 3] RFC 1973 PPP in Frame Relay June 1996

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
 [4].
 The joining of the PPP and NLPID number space has an added advantage,
 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 which have no PPP Protocol
 assignment, or which have not yet been implemented under the PPP
 encapsulation, or which have not been successfully negotiated by a
 PPP NCP, another method of encapsulation defined under [4] 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 Protocol
 field MUST NOT be sent compressed.
 On reception, the first octet following the header is examined.  If
 the octet is zero, it MUST be assumed that the packet is formatted
 according to [4].
 PPP encapsulated packets always have a non-zero octet following the
 header.  If the octet is not the PPP NLPID value (CF hex), and
 Protocol-Field-Compression is enabled, and the associated NCP has
 been negotiated, then it is expected to be a compressed PPP Protocol
 value.  Otherwise, it MUST be assumed that the packet is formatted
 according to [4].
 The Protocol field value 0x00cf is not allowed (reserved) to avoid
 ambiguity when Protocol-Field-Compression is enabled.  The value MAY
 be treated as a PPP Protocol that indicates that another PPP Protocol
 packet follows.
 Initial LCP packets contain the sequence cf-c0-21 following the
 header.  When a LCP Configure-Request packet is received and
 recognized, the PPP link enters Link Establishment phase.
 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.

Simpson Standards Track [Page 4] RFC 1973 PPP in Frame Relay June 1996

 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
 successfully negotiated a particular NCP for a PPP Protocol, if a
 frame arrives using another equivalent data encapsulation defined in
 [4], 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 which requires PPP link configuration, and other
 PPP negotiated features (such as authentication), MAY enter
 Termination phase when configuration fails.  Otherwise, when the
 Configure-Request sender reaches the Max-Configure limit, it MUST
 fall back to send only frames encapsulated according to [4].

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.

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 implementations,
 the initial MRU is 1600 octets [4].  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
 Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
 exceed 1500, unless a peer MRU of 2048 or greater is specifically

Simpson Standards Track [Page 5] RFC 1973 PPP in Frame Relay June 1996

 negotiated.
 Some Frame Relay switches are only capable of 262 octet frames.  It
 is not recommended that anyone deploy or use a switch which is
 capable of less than 1600 octet frames.  However, PPP implementations
 MUST be configurable to limit the size of LCP packets which are sent
 to 259 octets (which leaves room for the NLPID and Protocol fields),
 until LCP negotiation is complete.
 XID negotiation is not required to be supported for links which are
 capable of PPP negotiation.
 Inverse ARP is not required to be supported for PPP links.  That
 function is provided by PPP NCP negotiation.

Simpson Standards Track [Page 6] RFC 1973 PPP in Frame Relay June 1996

Security Considerations

 Security issues are not discussed in this memo.

References

 [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
       51, RFC 1661, July 1994.
 [2]   CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
       for Frame Mode Bearer Services", International Telegraph and
       Telephone Consultative Committee, 1992.
 [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
       RFC 1662, July 1994.
 [4]   Bradley, T.,  Brown, C., and A. Malis, "Multiprotocol
       Interconnect over Frame Relay", RFC 1490, July 1993.
 [5]   ISO/IEC TR 9577:1990(E), "Information technology -
       Telecommunications and Information exchange between systems -
       Protocol Identification in the network layer", 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 Standards Track [Page 7] RFC 1973 PPP in Frame Relay June 1996

Chair's Address

 The working group can be contacted via the current chair:
    Karl Fox
    Ascend Communications
    3518 Riverside Drive, Suite 101
    Columbus, Ohio 43221
    EMail: karl@ascend.com

Author's Address

 Questions about this memo 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 Standards Track [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1973.txt · Last modified: 1996/06/17 22:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki