home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1973.txt < prev    next >
Text File  |  1996-06-16  |  15KB  |  579 lines
  1.  
  2.  
  3. Network Working Group                                         W. Simpson
  4. Request for Comments: 1973                                    Daydreamer
  5. Category: Standards Track                                      June 1996
  6.  
  7.  
  8.                            PPP in Frame Relay
  9.  
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document specifies an Internet standards track protocol for
  15.    the Internet community, and requests discussion and suggestions for
  16.    improvements.  Please refer to the current edition of the "Internet
  17.    Official Protocol Standards" (STD 1) for the standardization state
  18.    and status of this protocol.  Distribution of this memo is unlimited.
  19.  
  20.  
  21. Abstract
  22.  
  23.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  24.    transporting multi-protocol datagrams over point-to-point links.
  25.  
  26.    This document describes the use of Frame Relay for framing PPP
  27.    encapsulated packets.
  28.  
  29.  
  30. Applicability
  31.  
  32.    This specification is intended for those implementations which desire
  33.    to use facilities which are defined for PPP, such as the Link Control
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Simpson                      Standards Track                    [Page i]
  57.  
  58. RFC 1973                     PPP in Frame Relay                June 1996
  59.  
  60.  
  61.    Protocol, Network-layer Control Protocols, authentication, and
  62.    compression.  These capabilities require a point-to-point
  63.    relationship between peers, and are not designed for multi-point or
  64.    multi-access environments.
  65.  
  66.  
  67. Table of Contents
  68.  
  69.  
  70.      1.     Introduction ..........................................    1
  71.  
  72.      2.     Physical Layer Requirements ...........................    1
  73.  
  74.      3.     The Data Link Layer ...................................    2
  75.         3.1       Frame Format ....................................    2
  76.         3.2       Modification of the Basic Frame .................    3
  77.  
  78.      4.     In-Band Protocol Demultiplexing .......................    4
  79.  
  80.      5.     Out-of-Band signaling .................................    5
  81.  
  82.      6.     Configuration Details .................................    5
  83.  
  84.      SECURITY CONSIDERATIONS ......................................    7
  85.  
  86.      REFERENCES ...................................................    7
  87.  
  88.      ACKNOWLEDGEMENTS .............................................    7
  89.  
  90.      CHAIR'S ADDRESS ..............................................    8
  91.  
  92.      AUTHOR'S ADDRESS .............................................    8
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Simpson                      Standards Track                   [Page ii]
  113.  
  114. RFC 1973                     PPP in Frame Relay                June 1996
  115.  
  116.  
  117.  
  118. 1.  Introduction
  119.  
  120.    Frame Relay [2] is a relative newcomer to the serial link community.
  121.    Like X.25, the protocol was designed to provide virtual circuits for
  122.    connections between stations attached to the same Frame Relay
  123.    network.  The improvement over X.25 is that Q.922 is restricted to
  124.    delivery of packets, and dispenses with sequencing and flow control,
  125.    simplifying the service immensely.
  126.  
  127.    PPP uses ISO 3309 HDLC as a basis for its framing [3].
  128.  
  129.    When Frame Relay is configured as a point-to-point circuit, PPP can
  130.    use Frame Relay as a framing mechanism, ignoring its other features.
  131.    This is equivalent to the technique used to carry SNAP headers over
  132.    Frame Relay [4].
  133.  
  134.    At one time, it had been hoped that PPP in HDLC-like frames and Frame
  135.    Relay would co-exist on the same links.  Unfortunately, the Q.922
  136.    method for expanding the address from 1 to 2 to 4 octets is not
  137.    indistinguishable from the ISO 3309 method, due to the structure of
  138.    its Data Link Connection Identifier (DLCI) subfields.  Co-existance
  139.    is precluded.
  140.  
  141.  
  142.  
  143. 2.  Physical Layer Requirements
  144.  
  145.    PPP treats Frame Relay framing as a bit-synchronous link.  The link
  146.    MUST be full-duplex, but MAY be either dedicated (permanent) or
  147.    switched.
  148.  
  149.    Interface Format
  150.  
  151.       PPP presents an octet interface to the physical layer.  There is
  152.       no provision for sub-octets to be supplied or accepted.
  153.  
  154.    Transmission Rate
  155.  
  156.       PPP does not impose any restrictions regarding transmission rate,
  157.       other than that of the particular Frame Relay interface.
  158.  
  159.    Control Signals
  160.  
  161.       Implementation of Frame Relay requires the provision of control
  162.       signals, which indicate when the link has become connected or
  163.       disconnected.  These in turn provide the Up and Down events to the
  164.       LCP state machine.
  165.  
  166.  
  167.  
  168. Simpson                      Standards Track                    [Page 1]
  169.  
  170. RFC 1973                     PPP in Frame Relay                June 1996
  171.  
  172.  
  173.       Because PPP does not normally require the use of control signals,
  174.       the failure of such signals MUST NOT affect correct operation of
  175.       PPP.  Implications are discussed in [2].
  176.  
  177.    Encoding
  178.  
  179.       The definition of various encodings is the responsibility of the
  180.       DTE/DCE equipment in use, and is outside the scope of this
  181.       specification.
  182.  
  183.       While PPP will operate without regard to the underlying
  184.       representation of the bit stream, Frame Relay requires NRZ
  185.       encoding.
  186.  
  187.  
  188.  
  189. 3.  The Data Link Layer
  190.  
  191.    This specification uses the principles, terminology, and frame
  192.    structure described in "Multiprotocol Interconnect over Frame Relay"
  193.    [4].
  194.  
  195.    The purpose of this specification is not to document what is already
  196.    standardized in [4].  Instead, this document attempts to give a
  197.    concise summary and point out specific options and features used by
  198.    PPP.
  199.  
  200.  
  201.  
  202. 3.1.  Frame Format
  203.  
  204.    As described in [4], Q.922 header address and control fields are
  205.    combined with the Network Layer Protocol Identifier (NLPID), which
  206.    identifies the encapsulation which follows.  The fields are
  207.    transmitted from left to right.
  208.  
  209.     0                   1                   2                   3
  210.     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
  211.    +-+-+-+-+-+-+-+-+
  212.    |  Flag (0x7e)  |
  213.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  214.    |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
  215.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  216.    |         PPP Protocol          |
  217.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  218.  
  219.    The PPP Protocol field and the following Information and Padding
  220.    fields are described in the Point-to-Point Protocol Encapsulation
  221.  
  222.  
  223.  
  224. Simpson                      Standards Track                    [Page 2]
  225.  
  226. RFC 1973                     PPP in Frame Relay                June 1996
  227.  
  228.  
  229.    [1].
  230.  
  231.  
  232.  
  233. 3.2.  Modification of the Basic Frame
  234.  
  235.    The Link Control Protocol can negotiate modifications to the basic
  236.    frame structure.  However, modified frames will always be clearly
  237.    distinguishable from standard frames.
  238.  
  239.    Address-and-Control-Field-Compression
  240.  
  241.       Because the Address and Control field values are not constant, and
  242.       are modified as the frame is transported by the network switching
  243.       fabric, Address-and-Control-Field-Compression MUST NOT be
  244.       negotiated.
  245.  
  246.    Protocol-Field-Compression
  247.  
  248.       Note that unlike PPP in HDLC-like framing, the Frame Relay framing
  249.       does not align the Information field on a 32-bit boundary.
  250.       Alignment to a 32-bit boundary occurs when the NLPID is removed
  251.       and the Protocol field is compressed to a single octet.  When this
  252.       improves throughput, Protocol-Field-Compression SHOULD be
  253.       negotiated.
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Simpson                      Standards Track                    [Page 3]
  281.  
  282. RFC 1973                     PPP in Frame Relay                June 1996
  283.  
  284.  
  285. 4.  In-Band Protocol Demultiplexing
  286.  
  287.    The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
  288.    PPP encapsulation from the other NLPID encapsulations described in
  289.    [4].
  290.  
  291.    The joining of the PPP and NLPID number space has an added advantage,
  292.    in that the LCP Protocol-Reject can be used to indicate NLPIDs that
  293.    are not recognized.  This can eliminate "black-holes" that occur when
  294.    traffic is not supported.
  295.  
  296.    For those network-layer protocols which have no PPP Protocol
  297.    assignment, or which have not yet been implemented under the PPP
  298.    encapsulation, or which have not been successfully negotiated by a
  299.    PPP NCP, another method of encapsulation defined under [4] SHOULD be
  300.    used.
  301.  
  302.    Currently, there are no conflicts between NLPID and PPP Protocol
  303.    values.  If a future implementation is configured to send a NLPID
  304.    value which is the same as a compressed Protocol field, that Protocol
  305.    field MUST NOT be sent compressed.
  306.  
  307.    On reception, the first octet following the header is examined.  If
  308.    the octet is zero, it MUST be assumed that the packet is formatted
  309.    according to [4].
  310.  
  311.    PPP encapsulated packets always have a non-zero octet following the
  312.    header.  If the octet is not the PPP NLPID value (CF hex), and
  313.    Protocol-Field-Compression is enabled, and the associated NCP has
  314.    been negotiated, then it is expected to be a compressed PPP Protocol
  315.    value.  Otherwise, it MUST be assumed that the packet is formatted
  316.    according to [4].
  317.  
  318.    The Protocol field value 0x00cf is not allowed (reserved) to avoid
  319.    ambiguity when Protocol-Field-Compression is enabled.  The value MAY
  320.    be treated as a PPP Protocol that indicates that another PPP Protocol
  321.    packet follows.
  322.  
  323.    Initial LCP packets contain the sequence cf-c0-21 following the
  324.    header.  When a LCP Configure-Request packet is received and
  325.    recognized, the PPP link enters Link Establishment phase.
  326.  
  327.    The accidental connection of a link to feed a multipoint network (or
  328.    multicast group) SHOULD result in a misconfiguration indication.
  329.    This can be detected by multiple responses to the LCP Configure-
  330.    Request with the same Identifier, coming from different framing
  331.    addresses.  Some implementations might be physically unable to either
  332.    log or report such information.
  333.  
  334.  
  335.  
  336. Simpson                      Standards Track                    [Page 4]
  337.  
  338. RFC 1973                     PPP in Frame Relay                June 1996
  339.  
  340.  
  341.    Once PPP has entered the Link Establishment phase, packets with other
  342.    NLPID values MUST NOT be sent, and on receipt such packets MUST be
  343.    silently discarded, until the PPP link enters the Network-Layer
  344.    Protocol phase.
  345.  
  346.    Once PPP has entered the Network-Layer Protocol phase, and
  347.    successfully negotiated a particular NCP for a PPP Protocol, if a
  348.    frame arrives using another equivalent data encapsulation defined in
  349.    [4], the PPP Link MUST re-enter Link Establishment phase and send a
  350.    new LCP Configure-Request.  This prevents "black-holes" that occur
  351.    when the peer loses state.
  352.  
  353.    An implementation which requires PPP link configuration, and other
  354.    PPP negotiated features (such as authentication), MAY enter
  355.    Termination phase when configuration fails.  Otherwise, when the
  356.    Configure-Request sender reaches the Max-Configure limit, it MUST
  357.    fall back to send only frames encapsulated according to [4].
  358.  
  359.  
  360.  
  361. 5.  Out-of-Band signaling
  362.  
  363.    There is no generally agreed method of out-of-band signalling.  Until
  364.    such a method is universally available, an implementation MUST use
  365.    In-Band Protocol Demultiplexing for both Permanent and Switched
  366.    Virtual Circuits.
  367.  
  368.  
  369.  
  370. 6.  Configuration Details
  371.  
  372.    The following Configuration Options are recommended:
  373.  
  374.       Magic Number
  375.       Protocol Field Compression
  376.  
  377.    The standard LCP configuration defaults apply to Frame Relay links,
  378.    except Maximum-Receive-Unit (MRU).
  379.  
  380.    To ensure interoperability with existing Frame Relay implementations,
  381.    the initial MRU is 1600 octets [4].  This only affects the minimum
  382.    required buffer space available for receiving packets, not the size
  383.    of packets sent.
  384.  
  385.    The typical network feeding the link is likely to have a MRU of
  386.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  387.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  388.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  389.  
  390.  
  391.  
  392. Simpson                      Standards Track                    [Page 5]
  393.  
  394. RFC 1973                     PPP in Frame Relay                June 1996
  395.  
  396.  
  397.    negotiated.
  398.  
  399.    Some Frame Relay switches are only capable of 262 octet frames.  It
  400.    is not recommended that anyone deploy or use a switch which is
  401.    capable of less than 1600 octet frames.  However, PPP implementations
  402.    MUST be configurable to limit the size of LCP packets which are sent
  403.    to 259 octets (which leaves room for the NLPID and Protocol fields),
  404.    until LCP negotiation is complete.
  405.  
  406.    XID negotiation is not required to be supported for links which are
  407.    capable of PPP negotiation.
  408.  
  409.    Inverse ARP is not required to be supported for PPP links.  That
  410.    function is provided by PPP NCP negotiation.
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448. Simpson                      Standards Track                    [Page 6]
  449.  
  450. RFC 1973                     PPP in Frame Relay                June 1996
  451.  
  452.  
  453. Security Considerations
  454.  
  455.    Security issues are not discussed in this memo.
  456.  
  457.  
  458.  
  459. References
  460.  
  461.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  462.          51, RFC 1661, July 1994.
  463.  
  464.    [2]   CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
  465.          for Frame Mode Bearer Services", International Telegraph and
  466.          Telephone Consultative Committee, 1992.
  467.  
  468.    [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
  469.          RFC 1662, July 1994.
  470.  
  471.    [4]   Bradley, T.,  Brown, C., and A. Malis, "Multiprotocol
  472.          Interconnect over Frame Relay", RFC 1490, July 1993.
  473.  
  474.    [5]   ISO/IEC TR 9577:1990(E), "Information technology -
  475.          Telecommunications and Information exchange between systems -
  476.          Protocol Identification in the network layer", 1990-10-15.
  477.  
  478.  
  479.  
  480. Acknowledgments
  481.  
  482.    This design was inspired by the paper "Parameter Negotiation for the
  483.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  484.    University of California, Berkeley, 1992, unpublished.
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504. Simpson                      Standards Track                    [Page 7]
  505.  
  506. RFC 1973                     PPP in Frame Relay                June 1996
  507.  
  508.  
  509. Chair's Address
  510.  
  511.    The working group can be contacted via the current chair:
  512.  
  513.       Karl Fox
  514.       Ascend Communications
  515.       3518 Riverside Drive, Suite 101
  516.       Columbus, Ohio 43221
  517.  
  518.       EMail: karl@ascend.com
  519.  
  520.  
  521.  
  522. Author's Address
  523.  
  524.    Questions about this memo can also be directed to:
  525.  
  526.       William Allen Simpson
  527.       Daydreamer
  528.       Computer Systems Consulting Services
  529.       1384 Fontaine
  530.       Madison Heights, Michigan  48071
  531.  
  532.           wsimpson@UMich.edu
  533.           wsimpson@GreenDragon.com (preferred)
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560. Simpson                      Standards Track                    [Page 8]
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.