PPP Extensions Working Group Manu Kaycee, Paradyne
INTERNET DRAFT George Gross, Lucent Technologies
Expires February 25, 1998 Arthur Lin, Cisco Systems
Andrew Malis, Ascend Communications
John Stephens, Cayman Systems
July 25, 1997
PPP Over FUNI
<draft-ietf-pppext-funi-01.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 Frame User Network Interface
(FUNI) for framing PPP encapsulated packets.
Applicability
Gross, Kaycee, et al Expires February 25th 1997 [Page 1]
Internet Draft PPP Over ATM FUNI July 25th 1997
This specification is intended for those implementations which desire to
use the facilities which are defined for PPP, such as the Link Control
Protocol, Network-layer Control Protocols, authentication, and
compression. These capabilities require a point-to-point relationship
between the peers, and are not designed for the multi-point
relationships which are available in ATM and other multi-access
environments.
1. Introduction
ATM FUNI protocol is designed to provide virtual connections between end
stations attached to the same network. These connections offer a packet
delivery service that includes error detection, but does not do error
correction.
Most existing 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 FUNI as a framing mechanism, ignoring its other features.
2. FUNI Layer Service Interface
The PPP layer treats the underlying ATM FUNI layer service as a bit-
synchronous point-to-point link. In this context, the PPP link
corresponds to an ATM FUNI virtual connection. The virtual connection
MUST be full-duplex, point to point, and it MAY be either dedicated
(i.e. permanent, set up by provisioning) or switched (set up on demand).
In addition, the PPP/FUNI service interface boundary MUST meet the
following requirements:
Interface Format - The PPP/FUNI layer boundary presents an octet
service interface to the FUNI layer. There is no provision for
sub-octets to be supplied or accepted.
Transmission Rate - The PPP layer does not impose any restrictions
regarding transmission rate.
Control Signals - The FUNI layer must provide control signals to
the PPP layer which indicate when the virtual connection link has
become connected or disconnected. These provide the "Up" and
"Down" events to the LCP state machine [1] within the PPP layer.
3. Multi-Protocol Encapsulation
This specification uses the principles, terminology, and frame structure
described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
[4].
Gross, Kaycee, et al Expires February 25th 1997 [Page 2]
Internet Draft PPP Over ATM FUNI July 25th 1997
The purpose of this specification is not to document what is already
standardized in [4], but to specify how the mechanisms described in [4]
are to be used to map PPP onto a FUNI-based ATM network. Section 1
within [4] defines the two mechanisms for identifying the Protocol Data
Unit (PDU) payload field's protocol type: virtual circuit based
multiplexing, and Logical Link Control (LLC) encapsulation. In the
former technique, the payload's protocol type is implicitly agreed to by
the end points for each virtual circuit using provisioning or control
plane procedures. When using the LLC encapsulation technique, the
payload's protocol type is explicitly identified on a per PDU basis by
an in-band LLC header, followed by the payload data.
When transporting a PPP payload over FUNI, an implementation:
1. MUST support virtual circuit multiplexed PPP payloads as
described in section 4. This technique is referred to as "VC-
multiplexed PPP".
2. MAY use LLC encapsulated PPP payloads on PVCs as described in
section 5 below by mutual configuration or negotiation of both end
points. This technique is referred to as "LLC encapsulated PPP".
3. If an implementation is connecting though a Frame Relay/ATM
FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point,
then it MUST support LLC encapsulated PPP payloads.
4. For SVC set up, an implementation MUST negotiate using the
Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
Interface (B-LLI) information element to signal either VC-
multiplexed PPP or LLC encapsulated PPP. The details of this
control plane procedure are described in section 6.
Gross, Kaycee, et al Expires February 25th 1997 [Page 3]
Internet Draft PPP Over ATM FUNI July 25th 1997
4. Virtual Circuit Multiplexed PPP Over FUNI
The FUNI protocol data unit (PDU) format [2] is as follows:
+-------------------------------+
| Flag |
+-------------------------------+---------
| FUNI Header | ^
+-------------------------------+ |
| | |
| | |
| User SDU | FUNI PDU
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) | v
+-------------------------------+---------
| Flag |
+-------------------------------+
Figure 1
The FUNI Header includes a 10-bit or 24-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.
A VC-multiplexed PPP frame SHALL constitute the User Service Data Unit
(SDU) field and is defined as shown in figure 2:
+----------+-------------+---------+
| Protocol | Information | Padding |
| 8/16 bits| | |
+----------+-------------+---------+
Figure 2
Each of these fields are specifically defined in [1].
Modification of the Basic FUNI Frame
The Link Control Protocol can negotiate modifications to the basic frame
structure (e.g. AFC, etc). However, any such modified frames MUST
always be clearly distinguishable from standard frames.
Gross, Kaycee, et al Expires February 25th 1997 [Page 4]
Internet Draft PPP Over ATM FUNI July 25th 1997
5. LLC Encapsulated PPP Over FUNI
LLC encapsulated PPP over FUNI is the alternative technique to VC-
multiplexed PPP over FUNI. LLC encapsulated PPP minimizes the ATM/Frame
Relay inter-working translation complexity that occurs when a VCC is
connected to an RFC 1973 compliant end point.
The FUNI SDU payload field is encoded as shown in figure 3:
+-------------------------+ --------
| Source SAP (0xFE) | ^
+-------------------------+ |
| Destination SAP (0xFE) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP payload
| . | |
| . | |
| PPP information field | |
| . | |
| . | V
+-------------------------+ --------
Figure 3
The fields in the above diagram are:
1. LLC header: 2 bytes encoded to specify a source SAP and
destination SAP of non-OSI routed PDU (values 0xFE 0xFE), followed
by an Un-numbered Information (UI) frame type (value 0x03).
2. Network Layer Protocol IDentifier (NLPID) representing PPP,
(value 0xCF).
3. the PPP protocol identifier field, which can be either 1 or 2
octets long.
4. followed by the PPP information field.
6. Out-Of-Band Control Plane Signaling
Gross, Kaycee, et al Expires February 25th 1997 [Page 5]
Internet Draft PPP Over ATM FUNI July 25th 1997
When originating a switched virtual circuit FUNI connection, the caller
MUST request in the SETUP message either one or else both of the RFC1483
protocol encapsulation techniques for PPP payload transport. When a
caller is offering both techniques, the two BLLI IEs are encoded within
a Broadband Repeat Indicator IE in the order of their preferance. The
called implementation MUST be able to accept an incoming call that
offers VC-multiplexed PPP in the caller's request. The called
implementation MAY reject a call set up request that only offers LLC
encapsulated PPP. Implementations originating a call offering both
protocol encapsulation techniques MUST be able to negotiate to the fall
back position of VC-multiplexed PPP and still inter-operate.
When originating a virtual circuit multiplexed call that is to carry a
PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3
protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The
extension octets specify an IPI value of PPP (0xCF). By definition, the
first bytes of the FUNI frame's payload field will always contain a PPP
header followed by a packet.
When originating an LLC encapsulated call that is to carry a PPP
payload, the ITU Q.2931 B-LLI element user information layer 2 protocol
field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in
octet 6. See RFC 1755 [8] appendix A for an example. By definition,
the first bytes of the FUNI frame's payload field will contain an LLC
header, followed by a NLPID and the PPP payload.
7. PPP Link Control Protocol Phase Transitions
Initial LCP packets contain the sequence cf-c0-21.
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.
Gross, Kaycee, et al Expires February 25th 1997 [Page 6]
Internet Draft PPP Over ATM FUNI July 25th 1997
An implementation which requires PPP link configuration, and other PPP
negotiated features (such as authentication), MAY enter Termination
phase when configuration fails.
8. Configuration Options
The following Configuration Options are recommended:
Magic Number
Protocol Field Compression
9. 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 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, and/or ATM-layer security
services.
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 v2", af-saa-0088.000, May 1997.
[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.
Gross, Kaycee, et al Expires February 25th 1997 [Page 7]
Internet Draft PPP Over ATM FUNI July 25th 1997
[5] ISO/IEC DTR 9577.2, "Information technology -
Telecommunications and Information exchange between systems -
Protocol Identification in the network layer", 1995-08-16.
[6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working
Implementation Agreement", FRF.8, April 1995.
[8] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis,
"ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
[9] International Telecommunication Union, "Broadband Integrated Service
Digital Network (B-ISDN) Digital Subscriber Signaling System No.2
(DSS2) User Network Interface Layer 3 Specification for Basic
Call/Connection Control", ITU-T Recommendation Q.2931, (International
Telecommunication Union: Geneva, 2/95)
10. 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.
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.732.345.7664
Email: mjk@nj.paradyne.com
George Gross
Lucent Technologies, Inc
Gross, Kaycee, et al Expires February 25th 1997 [Page 8]
Internet Draft PPP Over ATM FUNI July 25th 1997
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
Ascend Communications, Inc.
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
Gross, Kaycee, et al Expires February 25th 1997 [Page 9]
