PPP Over FUNI
How to carry PPP frames over an ATM FUNI virtual connection, with two ways to tag the payload.
Gross, G., Kaycee, M., Li, A., Malis, A., and J. Stephens, "PPP Over FUNI", RFC 2363, DOI 10.17487/RFC2363, July 1998, <https://www.rfc-editor.org/info/rfc2363>.
@misc{rfc2363,
series = {Request for Comments},
number = 2363,
howpublished = {RFC 2363},
publisher = {RFC Editor},
doi = {10.17487/RFC2363},
url = {https://www.rfc-editor.org/info/rfc2363},
author = {G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens},
title = {{PPP Over FUNI}},
pagetotal = 12,
year = 1998,
month = jul,
} RFC text
Contents
Network Working Group G. Gross
Request for Comments: 2363 Lucent Technologies
Category: Standards Track M. Kaycee
Paradyne
A. Li
Shasta Networks
A. Malis
Ascend Communications
J. Stephens
Cayman Systems
July 1998
PPP Over FUNI
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
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
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.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [10].
3. 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 or the underlying ATM
layer traffic descriptor parameters.
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.
4. Multi-Protocol Encapsulation
This specification uses the principles, terminology, and frame
structure described in "Multiprotocol Encapsulation over ATM
Adaptation Layer 5" [4].
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 5 below by mutual configuration or
negotiation of both end points. This technique is referred to
as "VC-multiplexed PPP".
2. MUST support LLC encapsulated PPP payloads on PVCs as
described in section 6 below by mutual configuration or
negotiation of both end points. This technique is referred to
as "LLC encapsulated PPP".
3. 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 7.
If an implementation is connecting through a Frame Relay/ATM FRF.8 [7]
service inter-working unit to an RFC 1973 [6] end point, then it
MUST use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8
inter-working units are exempted from the requirement to support
VC-multiplexed PPP. This exemption allows the FR/ATM IWU to
remain compliant with FRF.8 when the PPP over FUNI end point is
inter-operating with an RFC 1973 end point.
5. 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 ID | Information | Padding |
| 8/16 bits | | |
+-------------+-------------+---------+
Figure 2
Each of these fields are specifically defined in [1].
6. LLC Encapsulated PPP Over FUNI
LLC encapsulated PPP over FUNI is the alternative technique to VC-
multiplexed PPP over FUNI.
The FUNI SDU payload field is encoded as shown in figure 3. The
pertinent fields in that diagram are:
1. LLC header: 2 bytes encoded to specify a source SAP and
destination SAP of routed OSI 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. See reference [1].
4. followed by the PPP information field as per Figure 2.
+-------------------------+ --------
| Destination SAP (0xFE) | ^
+-------------------------+ |
| Source SAP (0xFE) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP payload
| . | |
| . | |
| PPP information field | |
| . | |
| . | |
+-------------------------+ |
| padding | V
+-------------------------+ --------
| FUNI FCS (2 or 4 octets)| FUNI trailer
+-------------------------+---------
Figure 3
The end points MAY be bi-laterally provisioned to send other
LLC-encapsulated protocols besides PPP across the same virtual
connection. However, they MUST NOT send packets belonging to
any protocol that has an active NCP within the PPP session.
Implementations SHOULD do packet scheduling that minimizes the
performance impact on the quality of service commitments
associated with both the LLC-encapsulated PPP and non-PPP
protocol flows.
7. Out-Of-Band Control Plane Signaling
When originating a switched virtual circuit FUNI connection, the
caller MUST request in the SETUP message either VC-multiplexed
PPP, LLC-encapsulated PPP, or else both VC-multiplexed and LLC-
encapsulated PPP. When a caller is offering both techniques,
the two B-LLI IEs are encoded within a Broadband Repeat
Indicator IE in the order of their preference. The called
implementation MUST be able to accept an incoming call that
offers LLC-encapsulated PPP in the caller's request. The called
implementation MUST reject a call set up request that only
offers an encapsulation that it does not support.
Implementations originating a call offering both protocol
encapsulation techniques MUST be able to negotiate the use of
LLC-encapsulated PPP.
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.
8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions
When the virtual connection loses state, the PPP encapsulation
technique may uni-laterally and unexpectedly change across such
transitions. Detection and recovery procedures are defined for
the following state transitions:
VC-multiplexed PPP changing to LLC encapsulated PPP
LLC encapsulated PPP changing to VC-multiplexed PPP
When LLC-encapsulated PPP is being used, the inital 6 octets of the
LCP packets contain the sequence: fe-fe-03-cf-c0-21. This sequence
constitutes the first 6 octets of the FUNI frame. In the case of
VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
In the case of FUNI, this sequence follows the FUNI Header. When a
LCP Configure-Request packet is received and recognized, the PPP link
enters Link Establishment phase.
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 as
defined in [4], then the PPP Link MUST:
For a SVC, immediately clear the call with the cause value 111,
"protocol error, unspecified".
For a PVC: tear down the active NCPs, SHOULD generate an error
message, enter the Termination state, and silently drop all
received packets.
These policies prevent "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 state when configuration fails.
9. LCP Configuration Options
The Magic Number LCP configuration option is RECOMMENDED, and the
Protocol Field Compression (PFC) option is NOT RECOMMENDED. An
implementation MUST NOT request any of the following options, and
MUST reject a request for such an option:
Field Check Sequence (FCS) Alternatives,
Address-and-Control-Field-Compression (ACFC),
Asynchronous-Control-Character-Map (ACCM)
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
larger size than the maximum CPCS-SDU size specified in the
associated direction for the virtual connection's traffic contract.
When viewed peer to peer, a PPP link may be bridged over multiple
physical layer sections. For each such FUNI section, the LCP framing
options MUST be actively negotiated by the bridging convertors
independently of the LCP framing options in use by other physical
layer sections.
Implementation Note:
When an ATM FUNI PVC is in the "Stopped" state, it is
RECOMMENDED that the implementation wait for Configure-Requests.
See the implementation option in reference [1] section 4.2, the
"Stopped State" sub-section.
10. 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.
When using LLC-encapsulated PPP over a virtual connection, an end
point can not assume that the PPP session authentication and related
security mechanisms also secure the other LLC encapsulated flows on
that same virtual connection.
11. 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. Special thanks to Phil Rakity of Flowpoint, Tim
Kwok of Microsoft, and David Allan of Nortel for their constructive
review and commentary.
12. 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] Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483,
July 1993.
[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] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 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
Authors' Addresses
Questions about this memo can also be directed to:
George Gross
Lucent Technologies, Inc
184 Liberty Corner Road
Warren, NJ 07059
Phone: +1.908.580.4589
EMail: gmgross@lucent.com
Manu Kaycee
Paradyne Corporation
21 Bear Meadow Road
Londonderry, NH 03053-2168
Phone: +1.603.434.6088
EMail: mjk@nj.paradyne.com
Arthur Lin
Shasta Networks Inc.
249 Humboldt Court
Sunnyvale, CA 94089-1300
Phone: +1.408.747.5051
EMail: alin@shastanets.com
Andrew Malis
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: +1.978.952.7414
EMail: malis@ascend.com
John Stephens
Cayman Systems, Inc.
100 Maple Street
Stoneham, MA 02180
Phone: +1.617.279.1101
EMail: john@cayman.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
AI ELI5
On this page
§1PPP Meets FUNI
The ATM FUNI (Frame User Network Interface) protocol provides virtual connections between end stations on the same network. It offers a packet delivery service with error detection but no error correction. Most PPP implementations use ISO 3309 HDLC for framing; when an ATM network is configured with point-to-point connections, PPP can use FUNI as its framing mechanism instead.
PPP sees the FUNI layer as a bit-synchronous point-to-point link, and one PPP link corresponds to one FUNI virtual connection. That connection MUST be full-duplex and point to point, and it MAY be dedicated (permanent, set up by provisioning) or switched (set up on demand). The interface is an octet interface with no sub-octets, and PPP puts no limit on transmission rate. The FUNI layer MUST give PPP control signals saying when the connection is connected or disconnected, which become the "Up" and "Down" events of the LCP state machine.
The RFC is aimed at implementations that want PPP facilities such as the Link Control Protocol, Network-layer Control Protocols, authentication and compression. These need a point-to-point relationship between peers and are not designed for the multi-point relationships ATM can also offer.
Two computers share a private ATM line, and PPP is their way of talking. This RFC says how to treat that line like a simple wire between them, and tells PPP when the line is plugged in or unplugged.
§4Two Ways to Identify the Payload
The RFC builds on the principles and frame structure of RFC 1483 (Multiprotocol Interconnect over AAL5). That document defines two ways to say what protocol a payload carries. With virtual circuit multiplexing, the two ends agree on the protocol for each circuit, through provisioning or control-plane procedures. With LLC encapsulation, each PDU carries an in-band LLC header naming the protocol.
An implementation carrying PPP over FUNI MUST support both: VC-multiplexed PPP and LLC encapsulated PPP on PVCs, chosen by mutual configuration or negotiation. For switched circuits it MUST negotiate using the Q.2931 Annex C procedure, encoding a B-LLI information element to signal which one is wanted.
One exception: an implementation connecting through a Frame Relay/ATM FRF.8 interworking unit to an RFC 1973 end point MUST use LLC encapsulated PPP. Such interworking units are exempt from supporting VC-multiplexed PPP.
There are two ways to label a parcel: agree beforehand that everything on this road is PPP, or stick a label on every parcel. Both ends must know how to do both, and must agree on which one to use.
§5VC-Multiplexed PPP Frames
A FUNI PDU starts and ends with a flag. Inside are a FUNI Header, a User SDU and a FUNI FCS of 2 or 4 octets. The header holds a 10-bit or 24-bit Frame Address (also called the VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority bit and four Reserved bits. The User SDU carries up to 4096 octets, optionally up to 64K. The FCS protects the whole FUNI PDU except the FCS itself.
In VC-multiplexed mode a PPP frame is the User SDU: a Protocol ID of 8 or 16 bits, then the Information field, then padding. These fields are defined in RFC 1661. Nothing else is added, because both ends already know the circuit carries PPP.
The envelope has a stamp, an address and a check mark. Because everyone knows this road only carries PPP mail, the PPP letter goes straight inside with no extra label.
§6LLC Encapsulated PPP Frames
In LLC mode the User SDU begins with a short header. The LLC header has destination SAP 0xFE, source SAP 0xFE (a routed OSI PDU) and frame type UI 0x03. Next comes the NLPID for PPP, 0xCF. After that is the PPP protocol identifier (1 or 2 octets), the PPP information field and padding, then the FUNI FCS of 2 or 4 octets.
The two ends MAY be bilaterally provisioned to send other LLC-encapsulated protocols over the same virtual connection. However, they MUST NOT send packets of any protocol that has an active NCP within the PPP session. Implementations SHOULD schedule packets so the quality of service commitments of both the PPP and non-PPP flows are affected as little as possible.
Here every PPP letter gets a small label first that says "this is PPP". That way the same road could also carry other kinds of mail, as long as PPP is not already handling that kind.
- 0xFEDestination SAP — Routed OSI PDU.
- 0xFESource SAP — Routed OSI PDU.
- 0x03Frame type UI — Un-numbered Information frame.
- 0xCFNLPID — Marks the payload as PPP.
§7Signaling for Switched Circuits
When a caller sets up a switched virtual circuit, its SETUP message MUST request VC-multiplexed PPP, LLC-encapsulated PPP, or both. If it offers both, the two B-LLI information elements go inside a Broadband Repeat Indicator IE in order of preference. The called side MUST accept an incoming call that offers LLC-encapsulated PPP, and MUST reject a call that offers only an encapsulation it does not support. A caller offering both MUST be able to negotiate LLC-encapsulated PPP.
For a VC-multiplexed call, the Q.2931 B-LLI user information layer 3 protocol field selects ISO/IEC TR 9577 in octet 7, with an IPI value of PPP (0xCF). For an LLC call, the layer 2 protocol field selects LAN Logical Link Control (ISO/IEC8802-2) in octet 6; RFC 1755 appendix A has an example.
When you phone someone to set up a line, you say which labelling style you can use, in order of preference. The other side says no if it cannot use any of them.
§8Unexpected Encapsulation Changes
If a virtual connection loses state, one side may unilaterally switch between VC-multiplexed and LLC encapsulation. The RFC defines detection and recovery for both directions. With LLC encapsulation, the first six octets of an LCP packet, which are also the first six octets of the FUNI frame, are fe-fe-03-cf-c0-21. With VC-multiplexing the initial LCP packet starts with c0-21 right after the FUNI Header.
Once PPP is in the Network-layer Protocol phase and has negotiated an NCP, a frame in the other, equivalent encapsulation MUST trigger action. On an SVC the call is cleared at once with cause value 111, "protocol error, unspecified". On a PVC the link tears down the active NCPs, SHOULD generate an error message, enters the Termination state and silently drops all received packets. These rules prevent "black-holes" when a peer loses state.
If one side forgets which labelling style was agreed and starts using the other, the line is cut or reset so that nobody keeps sending letters into the void.
| Encapsulation | First octets of an LCP packet |
|---|---|
| LLC encapsulated PPP | fe-fe-03-cf-c0-21 |
| VC-multiplexed PPP | c0-21 (after the FUNI Header) |
§9LCP Option Rules
The Magic Number LCP option is RECOMMENDED and Protocol Field Compression is NOT RECOMMENDED. An implementation MUST NOT request, and MUST reject a request for, the Field Check Sequence (FCS) Alternatives, Address-and-Control-Field-Compression (ACFC) and Asynchronous-Control-Character-Map (ACCM) options.
The Maximum-Receive-Unit option MUST NOT be negotiated larger than the maximum CPCS-SDU size in the associated direction of the circuit's traffic contract. If a PPP link is bridged across several physical sections, the LCP framing options MUST be negotiated independently on each FUNI section. When a PVC is in the Stopped state, the implementation is RECOMMENDED to wait for Configure-Requests.
This RFC says not to ask for a few of PPP's usual settings here. It also says never to promise bigger packets than the line allows.
§10Security Considerations
ATM networks are virtual circuit based, so security is implicit in how the provider administers PVCs between network boundaries. The chance of a breach from mis-routed ATM cells is considered negligible.
With switched circuits the model resembles dial-up over the telephone network, and the same PAP and CHAP authentication used for Internet dial-up applies, giving security on par with existing practice. Applications needing more are encouraged to use authentication headers, encrypted payloads and/or ATM-layer security services. With LLC-encapsulated PPP, an end point cannot assume PPP authentication also secures the other LLC flows on the same virtual connection.
A private ATM line is hard to tap by accident, and PPP's usual password checks still work. Mail of other kinds sharing the line is not covered by those checks.