As per Relevance of the word encapsulated, we have this rfc below:
Network Working Group G.
Request for Comments: 2364 Lucent
Category: Standards Track M.
A.
Shasta
A.
Ascend
J.
Cayman
July 1998
PPP Over AAL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links
This document describes the use of ATM Adaptation Layer 5 (AAL5)
framing PPP encapsulated packets
This specification is intended for those implementations which
to use the facilities which are defined for PPP, such as the
Control Protocol, Network-layer Control Protocols, authentication
and compression. These capabilities require a point-to-
relationship between the peers, and are not designed for the multi
point relationships which are available in ATM and other multi-
environments
Gross, et. al. Standards Track [Page 1]
RFC 2364 PPP Over AAL5 July 1998
1.
ATM AAL5 protocol is designed to provide virtual connections
end stations attached to the same network. These connections offer
packet delivery service that includes error detection, but does
do error correction
Most existing implementations of PPP use ISO 3309 HDLC as a basis
their framing [3].
When an ATM network is configured with point-to-point connections
PPP can use AAL5 as a framing mechanism
2.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [10].
3. AAL5 Layer Service
The PPP layer treats the underlying ATM AAL5 layer service as a bit
synchronous point-to-point link. In this context, the PPP
corresponds to an ATM AAL5 virtual connection. The
connection MUST be full-duplex, point to point, and it MAY be
dedicated (i.e. permanent, set up by provisioning) or switched (
up on demand). In addition, the PPP/AAL5 service interface
MUST meet the following requirements
Interface Format - The PPP/AAL5 layer boundary presents an
service interface to the AAL5 layer. There is no provision
sub-octets to be supplied or accepted
Transmission Rate - The PPP layer does not impose
restrictions regarding transmission rate or the underlying
layer traffic descriptor parameters
Control Signals - The AAL5 layer MUST provide control signals
the PPP layer which indicate when the virtual connection
has become connected or disconnected. These provide the "Up
"Down" events to the LCP state machine [1] within the PPP layer
Gross, et. al. Standards Track [Page 2]
RFC 2364 PPP Over AAL5 July 1998
4. Multi-Protocol
This specification uses the principles, terminology, and
structure described in "Multiprotocol Encapsulation over
Adaptation Layer 5" [4].
The purpose of this specification is not to document what is
standardized in [4], but to specify how the mechanisms described
[4] are to be used to map PPP onto an AAL5-based ATM network
Section 1 within [4] defines the two mechanisms for identifying
Protocol Data Unit (PDU) payload field's protocol type:
circuit based multiplexing, and Logical Link Control (LLC
encapsulation. In the former technique, the payload's protocol
is implicitly agreed to by the end points for each virtual
using provisioning or control plane procedures. When using the
encapsulation technique, the payload's protocol type is
identified on a per PDU basis by an in-band LLC header, followed
the payload data
When transporting a PPP payload over AAL5, an implementation
1. MUST support virtual circuit multiplexed PPP payloads
described in section 5 below by mutual configuration
negotiation of both end points. This technique is referred
as "VC-multiplexed PPP".
2. MUST support LLC encapsulated PPP payloads on PVCs
described in section 6 below by mutual configuration
negotiation of both end points. This technique is referred
as "LLC encapsulated PPP".
3. For SVC set up, an implementation MUST negotiate using
Q.2931 [9] Annex C procedure, encoding the Broadband Lower
Interface (B-LLI) information element to signal either VC
multiplexed PPP or LLC encapsulated PPP. The details of
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
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
compliant with FRF.8 when the PPP over AAL5 end point is inter
operating with an RFC 1973 end point
Gross, et. al. Standards Track [Page 3]
RFC 2364 PPP Over AAL5 July 1998
5. Virtual Circuit Multiplexed PPP Over AAL
The AAL5 PDU format is shown in figure 1:
AAL5 CPCS-PDU
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) | ^
+-------------------------------+ |
| CPI (1 octet ) | |
+-------------------------------+CPCS-PDU
| Length (2 octets) | |
+-------------------------------| |
| CRC (4 octets) |
+-------------------------------+ -------
Figure 1
The Common Part Convergence Sub-layer (CPCS)-PDU Payload
contains user information up to 2^16 - 1 octets
The PAD field pads the CPCS-PDU to fit exactly into the ATM
such that the last 48 octet cell payload created by the SAR
will have the CPCS-PDU Trailer right justified in the cell
The CPCS-UU (User-to-User indication) field is used to
transfer CPCS user to user information. The field has no
under the multi-protocol ATM encapsulation described in this memo
can be set to any value
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer
64 bits. Possible additional functions are for further study
ITU-T. When only the 64 bit alignment function is used, this
shall be coded as 0x00.
The Length field indicates the length, in octets, of the
field. The maximum value for the Length field is 65535 octets.
Length field coded as 0x00 is used for the abort function
The CRC field protects the entire CPCS-PDU except the CRC
itself
Gross, et. al. Standards Track [Page 4]
RFC 2364 PPP Over AAL5 July 1998
A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload
is defined as
+-------------+-------------+---------+
| Protocol ID | Information | Padding |
| 8/16 bits | | |
+-------------+-------------+---------+
Figure 2
Each of these fields are specifically defined in [1].
6. LLC Encapsulated PPP Over AAL
LLC encapsulated PPP over AAL5 is the alternative technique to VC
multiplexed PPP over AAL5.
The AAL5 CPCS-PDU 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
destination SAP of routed OSI PDU (values 0xFE 0xFE),
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.
Gross, et. al. Standards Track [Page 5]
RFC 2364 PPP Over AAL5 July 1998
+-------------------------+ --------
| Destination SAP (0xFE) | ^
+-------------------------+ |
| Source SAP (0xFE) | LLC
+-------------------------+ |
| Frame Type = UI (0x03) |
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP
| . | |
| . | |
| PPP information field | |
| . | |
| . | |
+-------------------------+ |
| padding |
+-------------------------+ --------
| PAD ( 0 - 47 octets) |
+-------------------------+ --------
| CPCS-UU (1 octet ) | ^
+-------------------------+ |
| CPI (1 octet ) | |
+-------------------------+CPCS-PDU
| Length (2 octets) | |
+-------------------------| |
| CRC (4 octets) |
+-------------------------+ --------
Figure 3
The end points MAY be bi-laterally provisioned to send other LLC
encapsulated protocols besides PPP across the same
connection. However, they MUST NOT send packets belonging to
protocol that has an active NCP within the PPP session
Implementations SHOULD do packet scheduling that minimizes
performance impact on the quality of service commitments
with both the LLC-encapsulated PPP and non-PPP protocol flows
7. Out-Of-Band Control Plane
When originating a switched virtual circuit AAL5 connection,
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
Gross, et. al. Standards Track [Page 6]
RFC 2364 PPP Over AAL5 July 1998
B-LLI IEs are encoded within a Broadband Repeat Indicator IE in
order of their preference. The called implementation MUST be able
accept an incoming call that offers LLC-encapsulated PPP in
caller's request. The called implementation MUST reject a call
up request that only offers an encapsulation that it does
support. Implementations originating a call offering both
encapsulation techniques MUST be able to negotiate the use of LLC
encapsulated PPP
When originating a virtual circuit multiplexed call that is to
a PPP payload, the ITU Q.2931 [9] B-LLI element user
layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5]
octet 7. The extension octets specify an IPI value of PPP (0xCF).
By definition, the first bytes of the AAL5 frame's payload field
always contain a PPP header followed by a packet
When originating an LLC encapsulated call that is to carry a
payload, the ITU Q.2931 B-LLI element user information layer 2
protocol field is encoded to select LAN Logical Link
(ISO/IEC8802-2) in octet 6. See RFC 1755 [8] appendix A for
example. By definition, the first bytes of the AAL5 frame's
field will contain an LLC header, followed by a NLPID and the
payload
8. Detection And Recovery From Unsolicited PPP Encapsulation
When the virtual connection loses state, the PPP
technique may uni-laterally and unexpectedly change across
transitions. Detection and recovery procedures are defined for
following state transitions
VC-multiplexed PPP changing to LLC encapsulated
LLC encapsulated PPP changing to VC-multiplexed
When LLC-encapsulated PPP is being used, the inital 6 octets of
LCP packets contain the sequence: fe-fe-03-cf-c0-21. This
constitutes the first 6 octets of the AAL5 frame. In the case
VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
This sequence constitutes the first 2 octets of an AAL5 frame.
a LCP Configure-Request packet is received and recognized, the
link enters Link Establishment phase
Once PPP has entered the Network-layer Protocol phase,
successfully negotiated a particular NCP for a PPP Protocol, if
frame arrives using an alternate but equivalent data encapsulation
defined in [4], then the PPP Link MUST
Gross, et. al. Standards Track [Page 7]
RFC 2364 PPP Over AAL5 July 1998
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
message, enter the Termination state, and silently drop
received packets
These policies prevent "black-holes" that occur when the peer
state. An implementation which requires PPP link configuration,
other PPP negotiated features (such as authentication), MAY
Termination state when configuration fails
9. LCP Configuration
The Magic Number LCP configuration option is RECOMMENDED, and
Protocol Field Compression (PFC) option is NOT RECOMMENDED.
implementation MUST NOT request any of the following options,
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
larger size than the maximum CPCS-SDU size specified in
associated direction for the virtual connection's traffic contract
When viewed peer to peer, a PPP link may be bridged over
physical layer sections. For each such AAL5 section, the LCP
options MUST be actively negotiated by the bridging
independently of the LCP framing options in use by other
layer sections
Implementation Note
When an ATM AAL5 PVC is in the "Stopped" state, it
RECOMMENDED that the implementation wait for Configure-Requests
See the implementation option in reference [1] section 4.2,
"Stopped State" sub-section
10. Security
Generally, ATM networks are virtual circuit based, and security
implicit in the public data networking service provider'
administration of Permanent Virtual Circuits (PVCs) between
network boundaries. The probability of a security breach caused
mis-routed ATM cells is considered to be negligible
Gross, et. al. Standards Track [Page 8]
RFC 2364 PPP Over AAL5 July 1998
When a public ATM network supports Switched Virtual Circuits,
protocol model becomes analogous to traditional voice band modem
up over the Public Telephone Switched Network (PTSN). The
PAP/CHAP authentication protocols that are already widely in use
Internet dial up access are leveraged. As a consequence, PPP
AAL5 security is at parity with those practices already
by the existing Internet infrastructure
Those applications that require stronger security are encouraged
use authentication headers, or encrypted payloads, and/or ATM-
security services
When using LLC-encapsulated PPP over a virtual connection, an
point can not assume that the PPP session authentication and
security mechanisms also secure the other LLC encapsulated flows
that same virtual connection
11.
This design is based on work performed in ADSL Forum's Packet
Working Group. It is inspired by "PPP in Frame Relay", RFC 1973,
William Simpson. Special thanks to Phil Rakity of Flowpoint,
Kwok of Microsoft, and David Allan of Nortel for their
review and commentary
12.
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
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,
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.
Gross, et. al. Standards Track [Page 9]
RFC 2364 PPP Over AAL5 July 1998
[8] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D.,
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
February 1995.
[9] International Telecommunication Union, "Broadband
Service Digital Network (B-ISDN) Digital Subscriber
System No.2 (DSS2) User Network Interface Layer 3
for Basic Call/Connection Control", ITU-T
Q.2931, (International Telecommunication Union: Geneva, 2/95)
[10] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Chair's
The working group can be contacted via the current chair
Karl
Ascend
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.
Authors'
Questions about this memo can also be directed to
George
Lucent Technologies,
184 Liberty Corner
Warren, NJ 07059
Phone: +1.908.580.4589
EMail: gmgross@lucent.
Manu
Paradyne
21 Bear Meadow
Londonderry, NH 03053-2168
Phone: +1.603.434.6088
EMail: mjk@nj.paradyne.
Gross, et. al. Standards Track [Page 10]
RFC 2364 PPP Over AAL5 July 1998
Arthur
Shasta Networks Inc
249 Humboldt
Sunnyvale, CA 94089-1300
Phone: +1.408.747.5051
EMail: alin@shastanets.
Andrew
Ascend Communications, Inc
1 Robbins
Westford, MA 01886
Phone: +1.978.952.7414
EMail: malis@ascend.
John
Cayman Systems, Inc
100 Maple
Stoneham, MA 02180
Phone: +1.617.279.1101
EMail: john@cayman.
Gross, et. al. Standards Track [Page 11]
RFC 2364 PPP Over AAL5 July 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Gross, et. al. Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
