summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3336.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3336.txt')
-rw-r--r--doc/rfc/rfc3336.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3336.txt b/doc/rfc/rfc3336.txt
new file mode 100644
index 0000000..2547aba
--- /dev/null
+++ b/doc/rfc/rfc3336.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group B. Thompson
+Request for Comments: 3336 T. Koren
+Category: Standards Track Cisco Systems
+ B. Buffam
+ Seaway Networks
+ December 2002
+
+
+ PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)
+
+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 (2002). All Rights Reserved.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links.
+
+ This document describes the use of ATM Adaptation Layer 2 (AAL2) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 1]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+1. Introduction
+
+ PPP over AAL5 [2] describes the encapsulation format and operation of
+ PPP when used with the ATM AAL5 adaptation layer. While this
+ encapsulation format is well suited to PPP transport of IP, it is
+ bandwidth inefficient when used for transporting small payloads such
+ as voice. PPP over AAL5 is especially bandwidth inefficient when
+ used with RTP header compression [3].
+
+ PPP over AAL2 addresses the bandwidth efficiency issues of PPP over
+ AAL5 for small packet transport by making use of the AAL2 Common Part
+ Sublayer (CPS) [4] to allow multiple PPP payloads to be multiplexed
+ into a set of ATM cells.
+
+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 [6].
+
+3. AAL2 Layer Service Interface
+
+ The PPP layer treats the underlying ATM AAL2 layer service as a bit-
+ synchronous point-to-point link. In this context, the PPP link
+ corresponds to an ATM AAL2 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/AAL2 service interface boundary
+ MUST meet the following requirements.
+
+ Interface Format - The PPP/AAL2 layer boundary presents an octet
+ service interface to the AAL2 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 on the underlying ATM
+ layer traffic descriptor parameters.
+
+ Control Signals - The AAL2 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.
+
+ In the case of PPP over AAL2, the state of the link can be derived
+ from the type 3 fault management packets carried in-band within a
+ given AAL2 CID flow.
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 2]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+4. PPP Operation with AAL2
+
+ PPP over AAL2 defines an encapsulation that uses the Service Specific
+ Segmentation and Reassembly Sublayer (SSSAR) [5] for AAL type 2. The
+ SSSAR sub-layer is used to segment PPP packets into frames that can
+ be transported using the AAL2 CPS. The SSSAR sub-layer uses
+ different AAL2 UUI code-points to indicate whether a segment is the
+ last segment of a packet or not.
+
+ The encapsulation of PPP over AAL2 provides a 16-bit CRC for PPP
+ payloads. There are 2 UUI code points assigned from SSSAR to
+ indicate intermediate fragments of a packet and the last fragment of
+ a packet. Code point 27 indicates intermediate frames of a
+ fragmented packet and code point 26 indicates the last frame of a
+ packet. The encapsulation format is more fully described in section
+ 6.2.1.
+
+ An implementation of PPP over AAL2 MAY use one or more AAL2 Channel
+ Identifiers (CIDs) for transport of PPP packets associated with each
+ PPP session. Multiple CIDs could be used to implement a multiple
+ class real time transport service for PPP using the AAL2 layer for
+ link fragmentation and interleaving. A companion document [10]
+ describes class extensions for PPP over AAL2 using multiple AAL2
+ CIDs.
+
+5. Comparison of PPP Over AAL2 with Existing Encapsulations
+
+ This document proposes the substitution of AAL2 transport for PPP in
+ scenarios where small packets are being transported over an ATM
+ network. This is most critical in applications such as voice
+ transport using RTP [9] where RTP Header compression [3] is used. In
+ applications such as voice transport, both bandwidth efficiency and
+ low delay are very important.
+
+ This section provides justification for the PPP over AAL2 service for
+ ATM transport by comparing it to existing PPP encapsulation formats
+ used for transport over ATM. Two encapsulation formats will be
+ examined here: PPP over AAL5 [2], and PPP with PPPMUX [8] over AAL5.
+
+5.1 Comparison With PPP Over AAL5
+
+ This proposal uses ATM AAL2 [4] rather than AAL5 as the transport for
+ PPP. SSSAR along with the AAL2 CPS generates less ATM encapsulation
+ overhead per PPP payload. The payload encapsulation consists of a 2
+ byte CRC. The AAL2 CPS header consists of 3 bytes, and the AAL2
+ Start Field (STF) is 1 byte. This is a total encapsulation overhead
+ of 6 bytes. This compares to 8 bytes of overhead for the AAL5
+ trailer used for PPP over AAL5.
+
+
+
+Thompson, et. al. Standards Track [Page 3]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+ The multiplexing function of the AAL2 CPS layer allows more bandwidth
+ efficient transport of PPP frames by multiplexing multiple PPP frames
+ into one or more ATM cells using the AAL2 CPS function. This removes
+ the pad overhead of AAL5 when used to transport short frames.
+
+5.2 Comparison with PPPMUX over AAL5
+
+ PPP Multiplexing (PPPMUX) [8] is a new method for doing multiplexing
+ in the PPP layer. PPPMUX provides functionality similar to the CPS
+ based multiplexing function of AAL2. Using PPP multiplexing, a PPP
+ stack would look like PPP/PPPMUX/AAL5.
+
+ Both PPP/PPPMUX/AAL5 and PPP/AAL2 use multiplexing to reduce the
+ overhead of cell padding when frames are sent over an ATM virtual
+ circuit. However, the bandwidth utilization of PPP/AAL2 will
+ typically be better than the bandwidth used by PPP/PPPMUX/AAL5. This
+ is because multiplexed frames in PPP/PPPMUX/AAL5 must always be
+ encapsulated within an AAL5 frame before being sent. This
+ encapsulation causes an additional 8 bytes of AAL5 trailer to be
+ added to the PPPMUX encapsulation. In addition to the 8 bytes of
+ AAL5 trailer, PPPMUX will incur an average of 24 additional bytes of
+ AAL5 PAD. These 2 factors will end up reducing the effective
+ efficiency of PPPMUX when it is used over AAL5.
+
+ With PPP/AAL2, the AAL2 CPS layer treats individual PPP frames as a
+ series of CPS payloads that can be multiplexed. As long as PPP
+ frames arrive at the CPS layer before the CPS TIMER_CU expires, all
+ ATM cells coming from the CPS layer will be filled. Under these
+ conditions, PPP/AAL2 will have no PAD associated with it. When the
+ AAL2 CPS function causes no PAD to be generated, PPP/AAL2 will be
+ more bandwidth efficient than PPP/PPPMUX/AAL5.
+
+ In PPP/PPPMUX/AAL5, the AAL5 SAR and the PPP MUX/DEMUX are performed
+ in two different layers. Thus, the PPPMUX/AAL5 receiver must
+ reassemble a full AAL5 frame from the ATM layer before the PPPMUX
+ layer can extract the PPP payloads. To derive maximum PPP
+ Multiplexing efficiency, many PPP payloads may be multiplexed
+ together. This increases the size of the multiplexed frame to many
+ ATM cells. If one of these ATM cells is lost, the whole PPPMUX
+ packet will be discarded. Also, there may be a significant delay
+ incurred while the AAL5 layer waits for many ATM cell arrival times
+ until a full frame has been assembled before the full frame is passed
+ up to the PPP Multiplexing layer where the inverse PPP demux then
+ occurs. This same issue also applies to PPPMUX/AAL5 frames
+ progressing down the stack.
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 4]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+ With AAL2, both the segmentation and reassembly and multiplexing
+ functions are performed in the AAL2 CPS layer. Because of the
+ definition of the AAL2 CPS function, a multiplexed payload will be
+ extracted as soon as it is received. The CPS receiver does not wait
+ until the many payloads of an AAL2 multiplexed frame are received
+ before removing payloads from the multiplexed stream. The same
+ benefit also applies to AAL2 CPS sender implementations. Also, the
+ loss of an ATM cell causes the loss of the packets that are included
+ in that cell only.
+
+ The AAL2 CPS function provides multiplexing in AAL2. This function
+ often needs to be implemented in hardware for performance reasons.
+ Because of this, a PPP/AAL2 implementation that takes advantage of an
+ AAL2 SAR implemented in hardware will have significant performance
+ benefits over a PPP/PPPMUX/AAL5 implementation where PPPMUX is
+ implemented in software. Also, the AAL2 specification has been
+ available significantly longer than the PPP Multiplexing
+ specification and because of this, optimized software and hardware
+ implementations of the AAL2 CPS function are further in development
+ than PPP Multiplexing implementations.
+
+6. Detailed Protocol Operation Description
+
+6.1 Background
+
+6.1.1 AAL2 Multiplexing
+
+ ITU-T I.363.2 specifies ATM Adaptation Layer Type 2. This AAL type
+ provides for bandwidth efficient transmission of low-rate, short and
+ variable length packets in delay sensitive applications. More than
+ one AAL type 2 user information stream can be supported on a single
+ ATM connection. There is only one definition for the sub-layer
+ because it implements the interface to the ATM layer and is shared by
+ more than one SSCS layer.
+
+6.1.2 AAL2 Service Specific Convergence Sub-layers
+
+ ITU-T I.366.1 and I.366.2 define Service Specific Convergence Sub-
+ layers (SSCS) that operate above the Common Part Sub-layer defined in
+ I.363.2. This layer specifies packet formats and procedures to
+ encode the different information streams in bandwidth efficient
+ transport. As the name implies, this sub-layer implements those
+ elements of service specific transport. While there is only one
+ definition of the Common Part Sublayer for AAL2, there can be
+ multiple SSCS functions defined to run over this CPS layer.
+ Different CIDs within an AAL2 virtual circuit may run different
+ SSCSs.
+
+
+
+
+Thompson, et. al. Standards Track [Page 5]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+6.1.3 AAL2 CPS Packet (CPS-PKT) Format
+
+ The CPS-PKT format over AAL2 as defined in I.363.2:
+
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| + + + + |
+| CID + LI + UUI + HEC + CPS-INFO |
+| + + + + |
+| + + + + |
+| (8) + (6) + (5) + (5) + (45/64 * 8) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Note: The size of the fields denote bit-width
+
+ The Channel ID (CID) identifies the sub-stream within the AAL2
+ connection. The Length indication (LI) indicates the length of the
+ CPS-INFO payload. The User-to-User Indication (UUI) carries
+ information between the SSCS/Application running above the CPS. The
+ SSSAR sub-layer as defined in I.366.1 uses the following code points:
+
+ UUI Code-point Packet Content
+ ++++++++++++++ ++++++++++++++
+
+ 0-26 Framed mode data, final packet.
+
+ 27 Framed mode data, more to come.
+
+ This proposal uses two UUI code-points as follows:
+
+ UUI Code-point Packet Content
+ ++++++++++++++ ++++++++++++++
+
+ 27 non-final packet.
+
+ 26 final packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 6]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+6.1.4 AAL2 CPS-PDU Format
+
+ The CPS-PDU format over AAL2 as defined in I.363.2:
+
+ +-+-+-+~+~+-+-+
+ |CPS| CPS-INFO|
+ |PKT| |
+ |HDR| |
+ +-+-+-+~+~+-+-+
+ | CPS-PKT |
+
+ | +-+-+-+~+~+-+-+
+ |CPS| CPS-INFO|
+ | |PKT| |
+ |HDR| |
+ | +-+-+-+~+~+-+-+
+ CPS-PKT
+ | | +-+-+-+~+~+-+-+
+ |CPS| CPS-INFO|
+ | | |PKT| |
+ |HDR| |
+ | | +-+-+-+~+~+-+-+
+ CPS-PKT
+ V V V V
++-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Cell | | | |
+ Header | STF | CPS-PDU Payload | PAD |
+ | | | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
+
+ Note: The size of the fields denote bitwidth
+
+ The CPS-PDU format is used to carry one or more CPS-PKT's multiplexed
+ on a single CPS-PDU. The CPS header contains enough information to
+ identify the CPS packets within a CPS-PDU. In the event of cell loss,
+ the STF field is used to find the first CPS-PKT in the current cell.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 7]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+6.2 PPP Over AAL2 Encapsulation
+
+ PPP encapsulation over AAL2 uses the AAL2 CPS with no change.
+
+ Some PPP encapsulated protocols such as RTP header compression
+ require that the link layer provide packet error detection. Because
+ of this, PPP over AAL2 defines a 16-bit CRC that is used along with
+ the SSSAR sub-layer of I.366.1 to provide packet error detection.
+ The encapsulation format is described below.
+
+6.2.1 PPP Payload Encapsulation Over AAL2 with 16-bit CRC (CRC-16).
+
+ The payload encapsulation of PPP appends a two byte CRC to each PPP
+ frame before using the SSSAR layer to send the PPP packet as a series
+ of AAL2 frames.
+
+ The format of a PPP over AAL2 packet is shown in the diagram below.
+ Note that the diagram below shows the payload encapsulation when the
+ packet is not segmented (UUI=26). When the PPP packet is segmented,
+ the PPP Protocol ID, Information field, and CRC-16 fields will be
+ split across multiple SSSAR frames. In this case, the UUI field will
+ be set to 27 for all frames except the last frame. In the last frame,
+ the UUI field will be set to 26.
+
+Payload Encapsulation
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| + + + + + + |
+| CID + LI + UUI + HEC + Protocol + + |
+| + + + + ID + Information + CRC-16 |
+| + + + + + + |
+| (8) + (6) + (5) + (5) + (8/16) + + (16) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Note: The size of the fields denote bit-width
+
+ The algorithms used for computing and verifying the CRC-16 field are
+ identical to the algorithms specified for the Frame Check Sequence
+ (FCS) field in Q.921 [13]. The algorithms from Q.921 are included in
+ this section for ease of access.
+
+ The CRC-16 field is filled with the value of a CRC calculation which
+ is performed over the contents of the PPP packet, including the PPP
+ Protocol ID and the information field. The CRC field shall contain
+ the ones complement of the sum (modulo 2) of:
+
+ 1) the remainder of x^k (x^15 + x^14 + ... + x + 1) divided (modulo
+ 2) by the generator polynomial, where k is the number of bits of
+ the information over which the CRC is calculated; and
+
+
+
+Thompson, et. al. Standards Track [Page 8]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+ 2) the remainder of the division (modulo 2) by the generator
+ polynomial of the product of x^16 by the information over which
+ the CRC is calculated.
+
+ The CRC-16 generator polynomial is:
+
+ G(x) = x^16 + x^12 + x^5 + 1
+
+ The result of the CRC calculation is placed with the least
+ significant bit right justified in the CRC field.
+
+ As a typical implementation at the transmitter, the initial content
+ of the register of the device computing the remainder of the division
+ is preset to all "1"s and is then modified by division by the
+ generator polynomial (as described above) on the information over
+ which the CRC is to be calculated; the ones complement of the
+ resulting remainder is put into the CRC field.
+
+ As a typical implementation at the receiver, the initial content of
+ the register of the device computing the remainder of the division is
+ preset to all "1"s. The final remainder, after multiplication by
+ x^16 and then division (modulo 2) by the generator polynomial of the
+ serial incoming PPP packet (including the Protocol ID, the
+ information and the CRC fields), will be 0001110100001111 (x^15
+ through x^0, respectively) in the absence of transmission errors.
+
+6.3 Use of AAL2 CPS-PKT CIDs
+
+ An implementation of PPP over AAL2 MAY use a single AAL2 Channel
+ Identifier (CID) or multiple CIDs for transport of all PPP packets.
+ In order for the endpoints of a PPP session to work with AAL2, they
+ MUST both agree on the number, SSCS mapping, and values of AAL2 CIDs
+ that will be used for a PPP session. The values of AAL2 CIDs to be
+ used for a PPP session MAY be obtained from either static
+ provisioning in the case of a dedicated AAL2 connection (PVC) or from
+ Q.2630.2 [7] signaling in the case of an AAL2 switched virtual
+ circuit (SPVC or SVC).
+
+ Using this proposal it is possible to support the use of conventional
+ AAL2 in CIDs that are not used to support PPP over AAL2. This
+ proposal allows the co-existence of multiple types of SSCS function
+ within the same AAL2 VCC.
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 9]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+6.4 PPP over AAL2 Operation
+
+ PPP operation with AAL2 will perform basic PPP encapsulation with the
+ PPP protocol ID. A 16-bit CRC is calculated as described above and
+ appended to the payload. The SSSAR sub-layer of AAL2 is used for
+ transport.
+
+ Applications implementing PPP over AAL2 MUST meet all the
+ requirements of PPP [1].
+
+7. Example implementation of PPP/AAL2
+
+ This section describes an example implementation of how PPP can be
+ encapsulated over AAL2. The example shows two application stacks
+ generating IP packets that are sent to the same interface running
+ PPP/AAL2. One Application stack is generating RTP packets and
+ another application is generating IP Datagrams. The PPP/AAL2
+ interface shown in this example is running an RFC 2508 compliant
+ version of RTP header compression.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 10]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+ Here are the paths an Application packet can take in this
+ implementation:
+
+ +---+---+---+---+--+ +
+ | Application A | |
+ +---+---+---+---+--+ |
+ | RTP | |
+ +---+---+---+---+--+ +---+---+---+---+---+ Application
+ | UDP | | Application B | |
+ +---+---+---+---+--+ +---+---+---+---+---+ |
+ | IP | | IP | |
+ +---+---+---+---+--+ +---+---+---+---+---+ +
+ | |
+ +---------------+------------+
+ |
+ |
+ +---+---+---+---+---+--+ +
+ | Compression Filter | |
+ +---+---+---+---+---+--+ |
+ | |
+ | |
+ +---------+-----------+ |
+ | | |
+ RTP | | Non-RTP |
+ Packets V | Packets |
+ +---+---+---+---+---+---+ | |
+ | CRTP | | |
+ +---+---+---+---+---+---+---+---+---+---+---+---+ Transport
+ | PPP | |
+ +---+---+---+---+---+---+---+---+---+---+---+---+ |
+ | |
+ +---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |
+ | Segmentation (SSSAR) | |
+ +---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |
+ +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |
+ | AAL2 CPS | |
+ +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |
+ | ATM Layer | |
+ +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ +
+
+ In the picture above, application A is an RTP application generating
+ RTP packets. Application B is an IP application generating IP
+ datagrams. Application A gathers the RTP data and formats an RTP
+ packet. Lower level layers of application A add UDP and IP headers
+ to form a complete IP packet. Application B is generating datagrams
+ to the IP layer. These datagrams may not have UDP or RTP headers.
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 11]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+ In the above picture, a protocol stack is configured to apply
+ CRTP/PPP/AAL2 compression on an interface to a destination host. All
+ packets that are sent to this interface will be tested to see if they
+ can be compressed using RTP header compression. As packets appear at
+ the interface, they will be tested by a compression filter to
+ determine if they are candidates for header compression. If the
+ compression filter determines that the packet is a candidate for
+ compression, the packet will be sent to the CRTP compressor. If the
+ packet is not a candidate for compression, it will be sent directly
+ to the PPP layer for encapsulation as an IP packet encapsulated in
+ PPP.
+
+ The destination UDP port number and packet length are examples of
+ criteria that may be used by the compression filter to select the
+ interface.
+
+ In this example, packets from application A will be passed to the
+ CRTP compressor which then hands the compressed packet to the PPP
+ layer for encapsulation as one of the compressed header types of
+ CRTP. The PPP layer will add the appropriate CRTP payload type for
+ the compressed packet.
+
+ Packets from application B will be sent directly to the PPP layer for
+ encapsulation as an IP/PPP packet. The PPP layer will add the PPP
+ payload type for an IP packet encapsulated in PPP.
+
+ PPP packets are then segmented using I.366.1 segmentation with SSSAR.
+
+ The resulting AAL2 frame mode PDU is passed down as a CPS SDU to the
+ CPS Layer for multiplexing accompanied by the CPS-UUI and the CPS-
+ CID. The CPS Layer multiplexes the CPS-PKT onto a CPS-PDU. CPS-PDUs
+ are passed to the ATM layer as ATM SDUs to be carried end-to-end
+ across the ATM network.
+
+ At the receiving end, the ATM SDU's arrive and are passed up to the
+ AAL2 CPS. As the AAL2 CPS PDU is accumulated, complete CPS-PKT's are
+ reassembled by the SSSAR SSCS. Reassembled packets are checked for
+ errors using the CRC algorithm.
+
+ At this point, the PPP layer on the receiving side uses the PPP
+ payload type to deliver the packet to either the CRTP decompressor or
+ the IP layer depending on the value of the PPP payload type.
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 12]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+8. LCP Configuration Options
+
+ By default, PPP over AAL2 will use the 16 bit CRC encapsulation for
+ all packets.
+
+ The default Maximum-Receive-Unit (MRU) is 1500 bytes.
+
+9. Security Considerations
+
+ This memo defines mechanisms for PPP encapsulation over ATM. There
+ is an element of trust in any encapsulation protocol: a receiver
+ should be able to trust that the sender has correctly identified the
+ protocol being encapsulated and that the sender has not been spoofed
+ or compromised. A receiver should also be able to trust that the
+ transport network between sender and receiver has not been
+ compromised.
+
+ A PPP session that runs over an ATM Virtual Circuit must follow the
+ PPP link operation state machine described in RFC 1661 [1]. This
+ state machine includes the ability to enforce the use of an
+ authentication phase using the PAP/CHAP authentication protocols
+ before any network layer packets are exchanged. Using PPP level
+ authentication, a PPP receiver can authenticate a PPP sender.
+
+ System security may also be compromised by the attacks of the ATM
+ transport network itself. The ATM Forum has published a security
+ framework [11] and a security specification [12] that define
+ procedures to guard against common threats to an ATM transport
+ network.
+
+ PPP level authentication does not guard against man in the middle
+ attacks. These attacks could occur if an attacker was able to
+ compromise the security infrastructure of an ATM switching network.
+ Applications that require protection against threats to an ATM
+ switching network are encouraged to use authentication headers, or
+ encrypted payloads, and/or the ATM-layer security services described
+ in [12].
+
+ When PPP over AAL2 is used on a set of CIDs in a virtual connection,
+ there may be other non PPP encapsulated AAL2 CIDs running on the same
+ virtual connection. Because of this, an end point cannot assume that
+ the PPP session authentication and related security mechanisms also
+ secure the non PPP encapsulated CIDs on that same virtual connection.
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 13]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+10. Acknowledgements
+
+ The authors would like to thank Rajesh Kumar, Mike Mclaughlin, Pietro
+ Schicker, James Carlson and John O'Neil for their contributions to
+ this proposal.
+
+11. References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [2] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP
+ over AAL5", STD 51, RFC 2364, July 1998.
+
+ [3] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
+ Low-Speed Serial Links", RFC 2508, February 1999.
+
+ [4] International Telecommunications Union, "BISDN ATM Adaptation
+ layer specification: Type 2 AAL(AAL2)", ITU-T Recommendation
+ I.363.2, September 1997.
+
+ [5] International Telecommunications Union, "Segmentation and
+ Reassembly Service Specific Convergence Sublayer for the AAL
+ type 2", ITU-T Recommendation I.366.1, June 1998.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [7] ITU-T, "ITU-T RECOMMENDATION Q.2630.2", December 2000.
+
+ [8] Pazhyannur, R, Ali, I. and C. Fox, "PPP Multiplexing", RFC 3153,
+ August 2001.
+
+ [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", RFC
+ 1889, January 1996.
+
+ [10] Thompson, B., Koren, T. and B. Buffam, "Class Extensions for PPP
+ over Asynchronous Transfer Mode Adaptation Layer 2", RFC 3337,
+ December 2002.
+
+ [11] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-
+ 0096.000, February 1998.
+
+ [12] The ATM Forum, "ATM Security Specification v1.1", af-sec-
+ 0100.002, March 2001.
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 14]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+ [13] International Telecommunications Union, ISDN User-Network
+ Interface-Data Link Layer Specification, ITU-T Recommendation
+ Q.921, March 1993.
+
+12. Authors' Addresses
+
+ Bruce Thompson
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ Phone: +1 408 527-0446
+ EMail: brucet@cisco.com
+
+
+ Tmima Koren
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ Phone: +1 408 527-6169
+ EMail: tmima@cisco.com
+
+
+ Bruce Buffam
+ Seaway Networks
+ One Chrysalis Way,
+ Suite 300,
+ Ottawa, Canada
+ K2G-6P9
+
+ Phone: +1 613 723-9161
+ EMail: bruce@seawaynetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 15]
+
+RFC 3336 PPP Over AAL2 December 2002
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson, et. al. Standards Track [Page 16]
+