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]
