Internet DRAFT - draft-ietf-pppext-aal5-funi

draft-ietf-pppext-aal5-funi



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 06:36:14 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 26 Mar 1997 14:42:00 GMT
ETag: "304d23-38d9-333935b8"
Accept-Ranges: bytes
Content-Length: 14553
Connection: close
Content-Type: text/plain




PPP Extension Group                                Manu Kaycee, Paradyne
INTERNET DRAFT                         George Gross, Lucent Technologies
Expires September 25, 1997                     Arthur Lin, Cisco Systems
                                    Andrew Malis, Cascade Communications
                                           John Stephens, Cayman Systems
                                                          March 25, 1997



                         PPP over AAL5 and FUNI
                  <draft-ietf-pppext-aal5-funi-00.txt>



Status of this Memo

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``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),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   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 ATM Adaptation Layer 5 (AAL5) and
   Frame User Network Interface (FUNI) 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
   Protocol, Network-layer Control Protocols, authentication, and


Kaycee, et. al.        Expires September 25, 1997               [Page 1]

Internet Draft           PPP over AAL5 and FUNI           March 13, 1997


   compression.  These capabilities require a point-to-point
   relationship between peers, and are not designed for multi-point
   relationships which are available in ATM and other multi-access
   environments.


1.   Introduction

   AAL5 and FUNI are relative newcomers to the serial link community.
   Like Frame Relay, these protocols  were designed to provide virtual
   circuits for connections between stations attached to the same ATM
   network.  These mechanisms are restricted to delivery of packets, and
   dispense with sequencing and flow control, simplifying the service
   immensely.

   Most implementations of PPP use ISO 3309 HDLC as a basis for their
   framing [3].

   When an ATM network is configured with point-to-point connections,
   PPP can use AAL5 or FUNI as a framing mechanism, ignoring its other
   features.  This is equivalent to the technique used to carry SNAP
   headers over AAL5 [4].


2.   Physical Layer Requirements

   PPP treats the ATM network as a bit-synchronous point-to-point link.
   The link, more appropriately the virtual connections,  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.

   Control Signals

     Implementation of ATM 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 [1].


3.   The Data Link Layer

   This specification uses the principles, terminology, and frame
   structure described in "Multiprotocol Interconnect over AAL5" [4].


Kaycee, et. al.        Expires September 25, 1997               [Page 2]

Internet Draft           PPP over AAL5 and FUNI           March 13, 1997


   The purpose of this specification is not to document what is already
   standardized in [4].  Instead, this document specifies how mechanisms
   described in [4] are to be used in order to map PPP onto an AAL5
   and/or FUNI-based ATM network.


3.1. PPP over AAL5

   The AAL5 format is as follows:

                     AAL5 CPCS-PDU Format
               +-------------------------------+
               |             .                 |
               |             .                 |
               |        CPCS-PDU Payload       |
               |     up to 2^16 - 1 octets)    |
               |             .                 |
               |             .                 |
               +-------------------------------+
               |      PAD ( 0 - 47 octets)     |
               +-------------------------------+ -------
               |       CPCS-UU (1 octet )      |
               +-------------------------------+
               |         CPI (1 octet )        |
               +-------------------------------+CPCS-PDU Trailer
               |        Length (2 octets)      |
               +-------------------------------|
               |         CRC (4 octets)        |
               +-------------------------------+ -------

   The Payload field contains user information up to 2^16 - 1 octets.

   The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
   such that the last 48 octet cell payload created by the SAR sublayer
   will have the CPCS-PDU Trailer right justified in the cell.

   The CPCS-UU (User-to-User indication) field is used to transparently
   transfer CPCS user to user information.  The field has no function
   under the multiprotocol ATM encapsulation described in this memo and
   can be set to any value.

   The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
   64 bits.  Possible additional functions are for further study in
   ITU-T.  When only the 64 bit alignment function is used, this field
   shall be coded as 0x00.

   The Length field indicates the length, in octets, of the Payload
   field.  The maximum value for the Length field is 65535 octets.  A
   Length field coded as 0x00 is used for the abort function.

   The CRC field protects the entire CPCS-PDU except the CRC field
   itself.

Kaycee, et. al.        Expires September 25, 1997               [Page 3]

Internet Draft           PPP over AAL5 and FUNI           March 13, 1997


   PPP over AAL5 SHALL use the VC-multiplexing mechanism described in
   [4].  A PPP frame SHALL constitute the CPCS-PDU payload and is
   defined as:

                  +----------+-------------+---------+
                  | Protocol | Information | Padding |
                  | 8/16 bits|      *      |    *    |
                  +----------+-------------+---------+

   Each of these fields are specifically defined in [1].


3.2. PPP over FUNI

   The FUNI frame format [2] is as follows:

                   +-------------------------------+
                   |              Flag             |
                   +-------------------------------+---------
                   |           FUNI Header         |    ^
                   +-------------------------------+    |
                   |                               |    |
                   |                               |    |
                   |            User SDU           | FUNI PDU
                   |                               |    |
                   |                               |    |
                   +-------------------------------+    |
                   |      FUNI FCS (4 octets)      |    v
                   +-------------------------------+---------
                   |              Flag             |
                   +-------------------------------+

   The FUNI Header includes a 10-bit Frame Address (a.k.a. VPI/VCI
   bits), a Congestion Notification bit, a Congestion Loss Priority bit,
   and four Reserved bits.

   The User SDU field contains user information up to 4096 (optionally
   up to 64K) octets.

   The FCS field protects the entire FUNI PDU except for the FCS field
   itself.

   PPP over FUNI SHALL use NULL-multiplexing. As such, a PPP frame SHALL
   constitute the User SDU field and is defined as:

                  +----------+-------------+---------+
                  | Protocol | Information | Padding |
                  | 8/16 bits|      *      |    *    |
                  +----------+-------------+---------+

   Each of these fields are specifically defined in [1].


Kaycee, et. al.        Expires September 25, 1997               [Page 4]

Internet Draft           PPP over AAL5 and FUNI           March 13, 1997


   Though v2 of the FUNI specification is out for straw ballot in the
   ATM Forum, this document is based on the currently approved FUNI v1
   specification.  This document will be updated as when the FUNI V2
   specification is approved.


3.3. Modification of the Basic Frame

   The Link Control Protocol can negotiate modifications to the basic
   frame structure.  However, any such modified frames MUST always be
   clearly distinguishable from standard frames.


4.   In-Band Protocol Demultiplexing

   Initial LCP packets contain the sequence cf-c0-21.  In the case of
   AAL5, this sequence constitute the first three octets of an AAL5
   frame. In the case of FUNI, they follow the FUNI Header.  When a LCP
   Configure-Request packet is received and recognized, the PPP link
   enters Link Establishment phase.

   Configuration requests received over multi-point connections SHOULD
   result in (a) misconfiguration indication(s).  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.

   Once PPP has entered the Network-layer Protocol phase, and
   successfully negotiated a particular NCP for a PPP Protocol, if a
   frame arrives using an alternate but 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.


5.   Out-of-Band signaling

   Conforming implementations MUST use VC multiplexing, as specified in
   RFC 1483, Section 5.  A VC multiplexed PPP virtual connection is
   setup through control plane  procedures, and by definition, the first
   bytes of the frame's payload field will always contain a PPP header
   followed by a packet.

   For switched virtual circuits, at call set up time, the ITU Q.2931
   B-LLI element user information layer 3 protocol field is required to
   select ISO/IEC TR 9577 [5] in octet 7, and explicitly specify PPP
   (IPI value 0xCF) in the extension octets.

Kaycee, et. al.        Expires September 25, 1997               [Page 5]

Internet Draft           PPP over AAL5 and FUNI           March 13, 1997

6.  Configuration Details


   The following Configuration Options are recommended:

      Magic Number
      Protocol Field Compression


Security Considerations

   Generally, ATM networks are virtual circuit based, and security is
   implicit in the public data networking service provider's
   administration of Permanent Virtual Circuits (PVCs) between the
   network boundaries.  The probability of a security breach caused by
   mis-routed ATM cells is considered to be negligible.
   
   When a public ATM network supports Switched Virtual Circuits, the
   protocol model becomes analogous to traditional voice band modem dial
   up over the Public Telephone Switched Network (PTSN).  The same
   PAP/CHAP authentication protocols that are already widely in use for
   Internet dial up access are leveraged.  As a consequence, PPP over
   AAL5 (and/or FUNI) security is at parity with those practices already
   established by the existing Internet infrastructure.
   
   Those applications that require stronger security are encouraged to
   use authentication headers or encrypted payloads.

References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, July 1994.

   [2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
         Specification v1", September 1995

   [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
         RFC 1662, July 1994.

   [4]   Hienanan, J., "Multiprotocol Interconnect over AAL5 ",
         RFC 1483, 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 is based on work performed in ADSL Forum's Packet Mode
   Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973,
   by William Simpson, which we have used gratuitously.


Kaycee, et. al.        Expires September 25, 1997               [Page 6]

Internet Draft           PPP over AAL5 and FUNI           March 13, 1997


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:

     Manu Kaycee
     Paradyne Corporation
     100 Shultz Drive
     Red Bank, NJ 07701
     Tel:   +1.908.345.7664
     Email: mjk@nj.paradyne.com

     George Gross
     Lucent Technologies, Inc
     184 Liberty Corner Road
     Warren, NJ 07059
     Tel:   +1.908.580.4589
     Email: gmg@garage.lucent.com

     Arthur Lin
     Cisco Systems, Inc.
     170 West Tasman Drive
     San Jose, CA 95134
     Tel:   +1.408.526.8260
     Email: alin@cisco.com

     Andrew Malis
     Cascade Communications Corporation
     5 Carlisle Road
     Westford, MA 01886
     Tel:  +1.508.952.7414
     Email: malis@casc.com

     John Stephens
     Cayman Systems, Inc.
     100 Maple Street
     Stoneham, MA 02180
     Tel:   +1.617.279.1101
     Email: john@cayman.com



Kaycee, et. al.        Expires September 25, 1997               [Page 7]