home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-aal5-funi-00.txt < prev    next >
Text File  |  1997-03-26  |  15KB  |  406 lines
  1.  
  2.  
  3.  
  4. PPP Extension Group                                Manu Kaycee, Paradyne
  5. INTERNET DRAFT                         George Gross, Lucent Technologies
  6. Expires September 25, 1997                     Arthur Lin, Cisco Systems
  7.                                     Andrew Malis, Cascade Communications
  8.                                            John Stephens, Cayman Systems
  9.                                                           March 25, 1997
  10.  
  11.  
  12.  
  13.                          PPP over AAL5 and FUNI
  14.                   <draft-ietf-pppext-aal5-funi-00.txt>
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference
  28.    material or to cite them other than as ``work in progress.''
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  32.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36.    Distribution of this memo is unlimited.
  37.  
  38.  
  39. Abstract
  40.  
  41.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  42.    transporting multi-protocol datagrams over point-to-point links.
  43.  
  44.    This document describes the use of ATM Adaptation Layer 5 (AAL5) and
  45.    Frame User Network Interface (FUNI) for framing PPP encapsulated
  46.    packets.
  47.  
  48.  
  49. Applicability
  50.  
  51.    This specification is intended for those implementations which desire
  52.    to use facilities which are defined for PPP, such as the Link Control
  53.    Protocol, Network-layer Control Protocols, authentication, and
  54.  
  55.  
  56. Kaycee, et. al.        Expires September 25, 1997               [Page 1]
  57.  
  58. Internet Draft           PPP over AAL5 and FUNI           March 13, 1997
  59.  
  60.  
  61.    compression.  These capabilities require a point-to-point
  62.    relationship between peers, and are not designed for multi-point
  63.    relationships which are available in ATM and other multi-access
  64.    environments.
  65.  
  66.  
  67. 1.   Introduction
  68.  
  69.    AAL5 and FUNI are relative newcomers to the serial link community.
  70.    Like Frame Relay, these protocols  were designed to provide virtual
  71.    circuits for connections between stations attached to the same ATM
  72.    network.  These mechanisms are restricted to delivery of packets, and
  73.    dispense with sequencing and flow control, simplifying the service
  74.    immensely.
  75.  
  76.    Most implementations of PPP use ISO 3309 HDLC as a basis for their
  77.    framing [3].
  78.  
  79.    When an ATM network is configured with point-to-point connections,
  80.    PPP can use AAL5 or FUNI as a framing mechanism, ignoring its other
  81.    features.  This is equivalent to the technique used to carry SNAP
  82.    headers over AAL5 [4].
  83.  
  84.  
  85. 2.   Physical Layer Requirements
  86.  
  87.    PPP treats the ATM network as a bit-synchronous point-to-point link.
  88.    The link, more appropriately the virtual connections,  MUST be
  89.    full-duplex, but MAY be either dedicated (permanent) or switched.
  90.  
  91.    Interface Format
  92.  
  93.      PPP presents an octet interface to the physical layer.  There is no
  94.      provision for sub-octets to be supplied or accepted.
  95.  
  96.    Transmission Rate
  97.  
  98.      PPP does not impose any restrictions regarding transmission rate.
  99.  
  100.    Control Signals
  101.  
  102.      Implementation of ATM requires the provision of control signals,
  103.      which indicate when the link has become connected or disconnected.
  104.      These in turn provide the Up and Down events to the LCP state
  105.      machine [1].
  106.  
  107.  
  108. 3.   The Data Link Layer
  109.  
  110.    This specification uses the principles, terminology, and frame
  111.    structure described in "Multiprotocol Interconnect over AAL5" [4].
  112.  
  113.  
  114. Kaycee, et. al.        Expires September 25, 1997               [Page 2]
  115.  
  116. Internet Draft           PPP over AAL5 and FUNI           March 13, 1997
  117.  
  118.  
  119.    The purpose of this specification is not to document what is already
  120.    standardized in [4].  Instead, this document specifies how mechanisms
  121.    described in [4] are to be used in order to map PPP onto an AAL5
  122.    and/or FUNI-based ATM network.
  123.  
  124.  
  125. 3.1. PPP over AAL5
  126.  
  127.    The AAL5 format is as follows:
  128.  
  129.                      AAL5 CPCS-PDU Format
  130.                +-------------------------------+
  131.                |             .                 |
  132.                |             .                 |
  133.                |        CPCS-PDU Payload       |
  134.                |     up to 2^16 - 1 octets)    |
  135.                |             .                 |
  136.                |             .                 |
  137.                +-------------------------------+
  138.                |      PAD ( 0 - 47 octets)     |
  139.                +-------------------------------+ -------
  140.                |       CPCS-UU (1 octet )      |
  141.                +-------------------------------+
  142.                |         CPI (1 octet )        |
  143.                +-------------------------------+CPCS-PDU Trailer
  144.                |        Length (2 octets)      |
  145.                +-------------------------------|
  146.                |         CRC (4 octets)        |
  147.                +-------------------------------+ -------
  148.  
  149.    The Payload field contains user information up to 2^16 - 1 octets.
  150.  
  151.    The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
  152.    such that the last 48 octet cell payload created by the SAR sublayer
  153.    will have the CPCS-PDU Trailer right justified in the cell.
  154.  
  155.    The CPCS-UU (User-to-User indication) field is used to transparently
  156.    transfer CPCS user to user information.  The field has no function
  157.    under the multiprotocol ATM encapsulation described in this memo and
  158.    can be set to any value.
  159.  
  160.    The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
  161.    64 bits.  Possible additional functions are for further study in
  162.    ITU-T.  When only the 64 bit alignment function is used, this field
  163.    shall be coded as 0x00.
  164.  
  165.    The Length field indicates the length, in octets, of the Payload
  166.    field.  The maximum value for the Length field is 65535 octets.  A
  167.    Length field coded as 0x00 is used for the abort function.
  168.  
  169.    The CRC field protects the entire CPCS-PDU except the CRC field
  170.    itself.
  171.  
  172. Kaycee, et. al.        Expires September 25, 1997               [Page 3]
  173.  
  174. Internet Draft           PPP over AAL5 and FUNI           March 13, 1997
  175.  
  176.  
  177.    PPP over AAL5 SHALL use the VC-multiplexing mechanism described in
  178.    [4].  A PPP frame SHALL constitute the CPCS-PDU payload and is
  179.    defined as:
  180.  
  181.                   +----------+-------------+---------+
  182.                   | Protocol | Information | Padding |
  183.                   | 8/16 bits|      *      |    *    |
  184.                   +----------+-------------+---------+
  185.  
  186.    Each of these fields are specifically defined in [1].
  187.  
  188.  
  189. 3.2. PPP over FUNI
  190.  
  191.    The FUNI frame format [2] is as follows:
  192.  
  193.                    +-------------------------------+
  194.                    |              Flag             |
  195.                    +-------------------------------+---------
  196.                    |           FUNI Header         |    ^
  197.                    +-------------------------------+    |
  198.                    |                               |    |
  199.                    |                               |    |
  200.                    |            User SDU           | FUNI PDU
  201.                    |                               |    |
  202.                    |                               |    |
  203.                    +-------------------------------+    |
  204.                    |      FUNI FCS (4 octets)      |    v
  205.                    +-------------------------------+---------
  206.                    |              Flag             |
  207.                    +-------------------------------+
  208.  
  209.    The FUNI Header includes a 10-bit Frame Address (a.k.a. VPI/VCI
  210.    bits), a Congestion Notification bit, a Congestion Loss Priority bit,
  211.    and four Reserved bits.
  212.  
  213.    The User SDU field contains user information up to 4096 (optionally
  214.    up to 64K) octets.
  215.  
  216.    The FCS field protects the entire FUNI PDU except for the FCS field
  217.    itself.
  218.  
  219.    PPP over FUNI SHALL use NULL-multiplexing. As such, a PPP frame SHALL
  220.    constitute the User SDU field and is defined as:
  221.  
  222.                   +----------+-------------+---------+
  223.                   | Protocol | Information | Padding |
  224.                   | 8/16 bits|      *      |    *    |
  225.                   +----------+-------------+---------+
  226.  
  227.    Each of these fields are specifically defined in [1].
  228.  
  229.  
  230. Kaycee, et. al.        Expires September 25, 1997               [Page 4]
  231.  
  232. Internet Draft           PPP over AAL5 and FUNI           March 13, 1997
  233.  
  234.  
  235.    Though v2 of the FUNI specification is out for straw ballot in the
  236.    ATM Forum, this document is based on the currently approved FUNI v1
  237.    specification.  This document will be updated as when the FUNI V2
  238.    specification is approved.
  239.  
  240.  
  241. 3.3. Modification of the Basic Frame
  242.  
  243.    The Link Control Protocol can negotiate modifications to the basic
  244.    frame structure.  However, any such modified frames MUST always be
  245.    clearly distinguishable from standard frames.
  246.  
  247.  
  248. 4.   In-Band Protocol Demultiplexing
  249.  
  250.    Initial LCP packets contain the sequence cf-c0-21.  In the case of
  251.    AAL5, this sequence constitute the first three octets of an AAL5
  252.    frame. In the case of FUNI, they follow the FUNI Header.  When a LCP
  253.    Configure-Request packet is received and recognized, the PPP link
  254.    enters Link Establishment phase.
  255.  
  256.    Configuration requests received over multi-point connections SHOULD
  257.    result in (a) misconfiguration indication(s).  This can be detected
  258.    by multiple responses to the LCP Configure-Request with the same
  259.    Identifier, coming from different framing addresses.  Some
  260.    implementations might be physically unable to either log or report
  261.    such information.
  262.  
  263.    Once PPP has entered the Network-layer Protocol phase, and
  264.    successfully negotiated a particular NCP for a PPP Protocol, if a
  265.    frame arrives using an alternate but equivalent data encapsulation
  266.    defined in [4], the PPP Link MUST re-enter Link Establishment phase
  267.    and send a new LCP Configure-Request.  This prevents "black-holes"
  268.    that occur when the peer loses state.
  269.  
  270.    An implementation which requires PPP link configuration, and other
  271.    PPP negotiated features (such as authentication), MAY enter
  272.    Termination phase when configuration fails.
  273.  
  274.  
  275. 5.   Out-of-Band signaling
  276.  
  277.    Conforming implementations MUST use VC multiplexing, as specified in
  278.    RFC 1483, Section 5.  A VC multiplexed PPP virtual connection is
  279.    setup through control plane  procedures, and by definition, the first
  280.    bytes of the frame's payload field will always contain a PPP header
  281.    followed by a packet.
  282.  
  283.    For switched virtual circuits, at call set up time, the ITU Q.2931
  284.    B-LLI element user information layer 3 protocol field is required to
  285.    select ISO/IEC TR 9577 [5] in octet 7, and explicitly specify PPP
  286.    (IPI value 0xCF) in the extension octets.
  287.  
  288. Kaycee, et. al.        Expires September 25, 1997               [Page 5]
  289.  
  290. Internet Draft           PPP over AAL5 and FUNI           March 13, 1997
  291.  
  292. 6.  Configuration Details
  293.  
  294.  
  295.    The following Configuration Options are recommended:
  296.  
  297.       Magic Number
  298.       Protocol Field Compression
  299.  
  300.  
  301. Security Considerations
  302.  
  303.    Generally, ATM networks are virtual circuit based, and security is
  304.    implicit in the public data networking service provider's
  305.    administration of Permanent Virtual Circuits (PVCs) between the
  306.    network boundaries.  The probability of a security breach caused by
  307.    mis-routed ATM cells is considered to be negligible.
  308.    
  309.    When a public ATM network supports Switched Virtual Circuits, the
  310.    protocol model becomes analogous to traditional voice band modem dial
  311.    up over the Public Telephone Switched Network (PTSN).  The same
  312.    PAP/CHAP authentication protocols that are already widely in use for
  313.    Internet dial up access are leveraged.  As a consequence, PPP over
  314.    AAL5 (and/or FUNI) security is at parity with those practices already
  315.    established by the existing Internet infrastructure.
  316.    
  317.    Those applications that require stronger security are encouraged to
  318.    use authentication headers or encrypted payloads.
  319.  
  320. References
  321.  
  322.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  323.          51, RFC 1661, July 1994.
  324.  
  325.    [2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
  326.          Specification v1", September 1995
  327.  
  328.    [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
  329.          RFC 1662, July 1994.
  330.  
  331.    [4]   Hienanan, J., "Multiprotocol Interconnect over AAL5 ",
  332.          RFC 1483, July 1993.
  333.  
  334.    [5]   ISO/IEC TR 9577:1990(E), "Information technology -
  335.          Telecommunications and Information exchange between systems -
  336.          Protocol Identification in the network layer", 1990-10-15.
  337.  
  338.  
  339. Acknowledgments
  340.  
  341.    This design is based on work performed in ADSL Forum's Packet Mode
  342.    Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973,
  343.    by William Simpson, which we have used gratuitously.
  344.  
  345.  
  346. Kaycee, et. al.        Expires September 25, 1997               [Page 6]
  347.  
  348. Internet Draft           PPP over AAL5 and FUNI           March 13, 1997
  349.  
  350.  
  351. Chair's Address
  352.  
  353.    The working group can be contacted via the current chair:
  354.  
  355.       Karl Fox
  356.       Ascend Communications
  357.       3518 Riverside Drive, Suite 101
  358.       Columbus, Ohio 43221
  359.  
  360.       EMail: karl@ascend.com
  361.  
  362.  
  363. Author's Address
  364.  
  365.    Questions about this memo can also be directed to:
  366.  
  367.      Manu Kaycee
  368.      Paradyne Corporation
  369.      100 Shultz Drive
  370.      Red Bank, NJ 07701
  371.      Tel:   +1.908.345.7664
  372.      Email: mjk@nj.paradyne.com
  373.  
  374.      George Gross
  375.      Lucent Technologies, Inc
  376.      184 Liberty Corner Road
  377.      Warren, NJ 07059
  378.      Tel:   +1.908.580.4589
  379.      Email: gmg@garage.lucent.com
  380.  
  381.      Arthur Lin
  382.      Cisco Systems, Inc.
  383.      170 West Tasman Drive
  384.      San Jose, CA 95134
  385.      Tel:   +1.408.526.8260
  386.      Email: alin@cisco.com
  387.  
  388.      Andrew Malis
  389.      Cascade Communications Corporation
  390.      5 Carlisle Road
  391.      Westford, MA 01886
  392.      Tel:  +1.508.952.7414
  393.      Email: malis@casc.com
  394.  
  395.      John Stephens
  396.      Cayman Systems, Inc.
  397.      100 Maple Street
  398.      Stoneham, MA 02180
  399.      Tel:   +1.617.279.1101
  400.      Email: john@cayman.com
  401.  
  402.  
  403.  
  404. Kaycee, et. al.        Expires September 25, 1997               [Page 7]
  405.  
  406.