< draft-ietf-pppext-aal5-04.txt   draft-ietf-pppext-aal5-05.txt >
PPP Extensions Working Group George Gross, Lucent Technologies PPP Extensions Working Group George Gross, Lucent Technologies
INTERNET DRAFT Manu Kaycee, Paradyne INTERNET DRAFT Manu Kaycee, Paradyne
Expires May 23, 1998 Arthur Lin, Benchmark Capital Expires October 5, 1998 Arthur Lin, Shasta Networks
Andrew Malis, Ascend Communications Andrew Malis, Ascend Communications
John Stephens, Cayman Systems John Stephens, Cayman Systems
December 23, 1997 April 5th, 1998
PPP Over AAL5 PPP Over AAL5
<draft-ietf-pppext-aal5-04.txt> <draft-ietf-pppext-aal5-05.txt>
Status Of This Memo Status Of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
ftp.isi.edu (US West Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method The Point-to-Point Protocol (PPP) [1] provides a standard method
for transporting multi-protocol datagrams over point-to-point for transporting multi-protocol datagrams over point-to-point
links. links.
This document describes the use of ATM Adaptation Layer 5 (AAL5) This document describes the use of ATM Adaptation Layer 5 (AAL5)
skipping to change at page 2, line 30 skipping to change at page 2, line 30
their framing [3]. their framing [3].
When an ATM network is configured with point-to-point connections, PPP When an ATM network is configured with point-to-point connections, PPP
can use AAL5 as a framing mechanism. can use AAL5 as a framing mechanism.
2. Specification of Requirements 2. Specification of Requirements
In this document, several words are used to signify the requirements of In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. the specification. These words are often capitalized.
MUST - This word, or the adjective "required", means that the 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
definition is an absolute requirement of the specification. the definition is an absolute requirement of the specification.
MUST NOT - This phrase means that the definition is an absolute 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
prohibition of the specification. definition is an absolute prohibition of the specification.
SHOULD - This word, or the adjective "recommended", means that 3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to ignore there may exist valid reasons in particular circumstances to ignore
this item, but the full implications MUST be understood and a particular item, but the full implications must be understood and
carefully weighed before choosing a different course. carefully weighed before choosing a different course.
MAY - This word, or the adjective "optional", means that this item 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
is one of an allowed set of alternatives. An implementation which that there may exist valid reasons in particular circumstances when
does not include this option MUST be prepared to interoperate with the particular behavior is acceptable or even useful, but the full
another implementation which does include the option. implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item
is truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because the vendor
feels that it enhances the product while another vendor may omit
the same item. An implementation which does not include a
particular option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with
reduced functionality. In the same vein an implementation which
does include a particular option MUST be prepared to interoperate
with another implementation which does not include the option
(except, of course, for the feature the option provides.)
3. AAL5 Layer Service Interface 3. AAL5 Layer Service Interface
The PPP layer treats the underlying ATM AAL5 layer service as a bit- The PPP layer treats the underlying ATM AAL5 layer service as a bit-
synchronous point-to-point link. In this context, the PPP link synchronous point-to-point link. In this context, the PPP link
corresponds to an ATM AAL5 virtual connection. The virtual connection corresponds to an ATM AAL5 virtual connection. The virtual connection
MUST be full-duplex, point to point, and it MAY be either dedicated 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). (i.e. permanent, set up by provisioning) or switched (set up on demand).
In addition, the PPP/AAL5 service interface boundary MUST meet the In addition, the PPP/AAL5 service interface boundary MUST meet the
following requirements: following requirements:
skipping to change at page 3, line 43 skipping to change at page 4, line 8
multiplexing, and Logical Link Control (LLC) encapsulation. In the multiplexing, and Logical Link Control (LLC) encapsulation. In the
former technique, the payload's protocol type is implicitly agreed to by former technique, the payload's protocol type is implicitly agreed to by
the end points for each virtual circuit using provisioning or control the end points for each virtual circuit using provisioning or control
plane procedures. When using the LLC encapsulation technique, the plane procedures. When using the LLC encapsulation technique, the
payload's protocol type is explicitly identified on a per PDU basis by payload's protocol type is explicitly identified on a per PDU basis by
an in-band LLC header, followed by the payload data. an in-band LLC header, followed by the payload data.
When transporting a PPP payload over AAL5, an implementation: When transporting a PPP payload over AAL5, an implementation:
1. MUST support virtual circuit multiplexed PPP payloads as 1. MUST support virtual circuit multiplexed PPP payloads as
described in section 5. This technique is referred to as "VC- described in section 5 below by mutual configuration or negotiation
of both end points. This technique is referred to as "VC-
multiplexed PPP". multiplexed PPP".
2. MAY use LLC encapsulated PPP payloads on PVCs as described in 2. MUST support LLC encapsulated PPP payloads on PVCs as described
section 6 below by mutual configuration or negotiation of both end in section 6 below by mutual configuration or negotiation of both
points. This technique is referred to as "LLC encapsulated PPP". end points. This technique is referred to as "LLC encapsulated
PPP".
3. For SVC set up, an implementation MUST negotiate using the 3. For SVC set up, an implementation MUST negotiate using the
Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
Interface (B-LLI) information element to signal either VC- Interface (B-LLI) information element to signal either VC-
multiplexed PPP or LLC encapsulated PPP. The details of this multiplexed PPP or LLC encapsulated PPP. The details of this
control plane procedure are described in section 7. control plane procedure are described in section 7.
If an implementation is connecting through a Frame Relay/ATM FRF.8 [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 service inter-working unit to an RFC 1973 [6] end point, then it MUST
use LLC encapsulated PPP payloads. Implementations that wish to inter- use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8 inter-working
operate with all potential end points MUST implement LLC-encapsulated units are exempted from the requirement to support VC-multiplexed PPP.
payloads. This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when
the PPP over AAL5 end point is inter-operating with an RFC1973 end
point.
5. Virtual Circuit Multiplexed PPP Over AAL5 5. Virtual Circuit Multiplexed PPP Over AAL5
The AAL5 PDU format is shown in figure 1: The AAL5 PDU format is shown in figure 1:
AAL5 CPCS-PDU Format AAL5 CPCS-PDU Format
+-------------------------------+ +-------------------------------+
| . | | . |
| . | | . |
| CPCS-PDU Payload | | CPCS-PDU Payload |
| up to 2^16 - 1 octets) | | up to 2^16 - 1 octets) |
| . | | . |
| . |
+-------------------------------+ +-------------------------------+
| PAD ( 0 - 47 octets) | | PAD ( 0 - 47 octets) |
+-------------------------------+ ------- +-------------------------------+ -------
| CPCS-UU (1 octet ) | | CPCS-UU (1 octet ) | ^
+-------------------------------+ +-------------------------------+ |
| CPI (1 octet ) | | CPI (1 octet ) | |
+-------------------------------+CPCS-PDU Trailer +-------------------------------+CPCS-PDU Trailer
| Length (2 octets) | | Length (2 octets) | |
+-------------------------------| +-------------------------------| |
| CRC (4 octets) | | CRC (4 octets) | V
+-------------------------------+ ------- +-------------------------------+ -------
Figure 1 Figure 1
The Common Part Convergence Sub-layer (CPCS)-PDU Payload field contains The Common Part Convergence Sub-layer (CPCS)-PDU Payload field contains
user information up to 2^16 - 1 octets. user information up to 2^16 - 1 octets.
The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such 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 that the last 48 octet cell payload created by the SAR sublayer will
have the CPCS-PDU Trailer right justified in the cell. have the CPCS-PDU Trailer right justified in the cell.
skipping to change at page 5, line 30 skipping to change at page 5, line 44
| Protocol ID | Information | Padding | | Protocol ID | Information | Padding |
| 8/16 bits | | | | 8/16 bits | | |
+-------------+-------------+---------+ +-------------+-------------+---------+
Figure 2 Figure 2
Each of these fields are specifically defined in [1]. Each of these fields are specifically defined in [1].
6. LLC Encapsulated PPP Over AAL5 6. LLC Encapsulated PPP Over AAL5
LLC encapsulated PPP over AAL5 is the alternative technique to VC- LLC encapsulated PPP over AAL5 is the alternative technique to VC-
multiplexed PPP over AAL5. LLC encapsulated PPP minimizes the ATM/Frame multiplexed PPP over AAL5.
Relay inter-working translation complexity that occurs when a VCC is
connected to an RFC 1973 compliant end point.
The AAL5 CPCS-PDU payload field is encoded as shown in figure 3. The The AAL5 CPCS-PDU payload field is encoded as shown in figure 3. The
pertinent fields in that diagram are: pertinent fields in that diagram are:
1. LLC header: 2 bytes encoded to specify a source SAP and 1. LLC header: 2 bytes encoded to specify a source SAP and
destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by
an Un-numbered Information (UI) frame type (value 0x03). an Un-numbered Information (UI) frame type (value 0x03).
2. Network Layer Protocol IDentifier (NLPID) representing PPP, 2. Network Layer Protocol IDentifier (NLPID) representing PPP,
(value 0xCF). (value 0xCF).
3. the PPP protocol identifier field, which can be either 1 or 2 3. the PPP protocol identifier field, which can be either 1 or 2
octets long. See reference [1]. octets long. See reference [1].
4. followed by the PPP information field. 4. followed by the PPP information field as per Figure 2.
+-------------------------+ -------- +-------------------------+ --------
| Destination SAP (0xFE) | ^ | Destination SAP (0xFE) | ^
+-------------------------+ | +-------------------------+ |
| Source SAP (0xFE) | LLC header | Source SAP (0xFE) | LLC header
+-------------------------+ | +-------------------------+ |
| Frame Type = UI (0x03) | V | Frame Type = UI (0x03) | V
+-------------------------+ -------- +-------------------------+ --------
| NLPID = PPP (0xCF) | | NLPID = PPP (0xCF) |
+-------------------------+ -------- +-------------------------+ --------
| Protocol Identifier | ^ | Protocol Identifier | ^
| (8 or 16 bits) | | | (8 or 16 bits) | |
+-------------------------+ PPP payload +-------------------------+ PPP payload
| . | | | . | |
| . | | | . | |
| PPP information field | | | PPP information field | |
| . | | | . | |
| . | V | . | |
+-------------------------+ |
| padding | V
+-------------------------+ -------- +-------------------------+ --------
| PAD ( 0 - 47 octets) | | PAD ( 0 - 47 octets) |
+-------------------------+ -------- +-------------------------+ --------
| CPCS-UU (1 octet ) | ^ | CPCS-UU (1 octet ) | ^
+-------------------------+ | +-------------------------+ |
| CPI (1 octet ) | | | CPI (1 octet ) | |
+-------------------------+CPCS-PDU Trailer +-------------------------+CPCS-PDU Trailer
| Length (2 octets) | | | Length (2 octets) | |
+-------------------------| | +-------------------------| |
| CRC (4 octets) | V | CRC (4 octets) | V
+-------------------------+ -------- +-------------------------+ --------
skipping to change at page 6, line 51 skipping to change at page 7, line 13
scheduling that minimizes the performance impact on the quality of scheduling that minimizes the performance impact on the quality of
service commitments associated with both the LLC-encapsulated PPP and service commitments associated with both the LLC-encapsulated PPP and
non-PPP protocol flows. non-PPP protocol flows.
7. Out-Of-Band Control Plane Signaling 7. Out-Of-Band Control Plane Signaling
When originating a switched virtual circuit AAL5 connection, the caller When originating a switched virtual circuit AAL5 connection, the caller
MUST request in the SETUP message either VC-multiplexed PPP, LLC- MUST request in the SETUP message either VC-multiplexed PPP, LLC-
encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP. 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 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 preferance. within a Broadband Repeat Indicator IE in the order of their preference.
The called implementation MUST be able to accept an incoming call that The called implementation MUST be able to accept an incoming call that
offers VC-multiplexed PPP in the caller's request. The called offers LLC-encapsulated PPP in the caller's request. The called
implementation MUST reject a call set up request that only offers an implementation MUST reject a call set up request that only offers an
encapsulation that it does not support. Implementations originating a encapsulation that it does not support. Implementations originating a
call offering both protocol encapsulation techniques MUST be able to call offering both protocol encapsulation techniques MUST be able to
negotiate the use of VC-multiplexed PPP. negotiate the use of LLC-encapsulated PPP.
When originating a virtual circuit multiplexed call that is to carry a 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 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 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 extension octets specify an IPI value of PPP (0xCF). By definition, the
first bytes of the AAL5 frame's payload field will always contain a PPP first bytes of the AAL5 frame's payload field will always contain a PPP
header followed by a packet. header followed by a packet.
When originating an LLC encapsulated call that is to carry a PPP 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 payload, the ITU Q.2931 B-LLI element user information layer 2 protocol
skipping to change at page 8, line 35 skipping to change at page 8, line 44
Asynchronous-Control-Character-Map (ACCM) Asynchronous-Control-Character-Map (ACCM)
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger
size than the maximum CPCS-SDU size specified in the associated size than the maximum CPCS-SDU size specified in the associated
direction for the virtual connection's traffic contract. direction for the virtual connection's traffic contract.
When viewed peer to peer, a PPP link may be bridged over multiple When viewed peer to peer, a PPP link may be bridged over multiple
physical layer sections. For each such AAL5 section, the LCP framing physical layer sections. For each such AAL5 section, the LCP framing
options MUST be actively negotiated by the bridging convertors options MUST be actively negotiated by the bridging convertors
independently of the LCP framing options in use by other physical layer independently of the LCP framing options in use by other physical layer
sections sections.
Implementation Note:
When an ATM AAL5 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 10. Security Considerations
Generally, ATM networks are virtual circuit based, and security is Generally, ATM networks are virtual circuit based, and security is
implicit in the public data networking service provider's administration implicit in the public data networking service provider's administration
of Permanent Virtual Circuits (PVCs) between the network boundaries. of Permanent Virtual Circuits (PVCs) between the network boundaries.
The probability of a security breach caused by mis-routed ATM cells is The probability of a security breach caused by mis-routed ATM cells is
considered to be negligible. considered to be negligible.
When a public ATM network supports Switched Virtual Circuits, the When a public ATM network supports Switched Virtual Circuits, the
skipping to change at page 10, line 34 skipping to change at page 11, line 4
Email: gmgross@lucent.com Email: gmgross@lucent.com
Manu Kaycee Manu Kaycee
Paradyne Corporation Paradyne Corporation
21 Bear Meadow Road 21 Bear Meadow Road
Londonderry, NH 03053-2168 Londonderry, NH 03053-2168
Tel: +1.603.434.6088 Tel: +1.603.434.6088
Email: mjk@nj.paradyne.com Email: mjk@nj.paradyne.com
Arthur Lin Arthur Lin
Benchmark Capital Shasta Networks Inc.
2480 Sand Hill Road 249 Humboldt Court
Suite 200 Sunnyvale, CA 94089-1300
Menlo Park, CA 94025 Tel: +1.408.747.5051
Tel: +1.650.854.8180 Email: alin@shastanets.com
Email: artlin@pacbell.net
Andrew Malis Andrew Malis
Ascend Communications, Inc. Ascend Communications, Inc.
1 Robbins Road 1 Robbins Road
Westford, MA 01886 Westford, MA 01886
Tel: +1.978.952.7414 Tel: +1.978.952.7414
Email: malis@ascend.com Email: malis@ascend.com
John Stephens John Stephens
Cayman Systems, Inc. Cayman Systems, Inc.
 End of changes. 24 change blocks. 
49 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/