Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2684

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                       D. Grossman
Request for Comments: 2684                               Motorola, Inc.
Obsoletes: 1483                                             J. Heinanen
Category: Standards Track                                         Telia
                                                         September 1999

        Multiprotocol Encapsulation over ATM Adaptation Layer 5

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 (1999).  All Rights Reserved.

Abstract

   This memo replaces RFC 1483.  It describes two encapsulations methods
   for carrying network interconnect traffic over AAL type 5 over  ATM.
   The first method allows multiplexing of multiple protocols over a
   single ATM virtual connection whereas the second method assumes that
   each protocol is carried over a separate ATM virtual connection.

Applicability

   This specification is intended to be used in implementations which
   use ATM networks to carry multiprotocol traffic among hosts, routers
   and bridges which are ATM end systems.

1.  Introduction

   Asynchronous Transfer Mode (ATM) wide area, campus and local area
   networks are used to transport IP datagrams and other connectionless
   traffic between hosts, routers, bridges and other networking devices.
   This memo describes two methods for carrying connectionless routed
   and bridged Protocol Data Units (PDUs) over an ATM network.  The "LLC
   Encapsulation" method allows multiplexing of multiple protocols over
   a single ATM virtual connection (VC).  The protocol type of each PDU
   is identified by a prefixed IEEE 802.2 Logical Link Control (LLC)
   header. In the "VC Multiplexing" method, each ATM VC carries PDUs of
   exactly one protocol type.  When multiple protocols need to be
   transported, there is a separate VC for each.

Grossman & Heinanen         Standards Track                     [Page 1]
RFC 2684                Multiprotocol Over AALS           September 1999

   The unit of transport in ATM is a 53 octet fixed length PDU called a
   cell.  A cell consists of a 5 octet header and a 48 byte payload.
   Variable length PDUs, including those addressed in this memo, must be
   segmented by the transmitter to fit into the 48 octet ATM cell
   payload, and reassembled by the receiver.  This memo specifies the
   use of the ATM Adaptation Layer type 5 (AAL5), as defined in ITU-T
   Recommendation I.363.5 [2] for this purpose. Variable length PDUs are
   carried in the Payload field of the AAL5 Common Part Convergence
   Sublayer (CPCS) PDU.

   This memo only describes how routed and bridged PDUs are carried
   directly over the AAL5  CPCS, i.e., when the Service Specific
   Convergence Sublayer (SSCS) of AAL5 is absent.  If Frame Relay
   Service Specific Convergence Sublayer (FR-SSCS), as defined in ITU-T
   Recommendation I.365.1 [3], is used over the CPCS, then routed and
   bridged PDUs are carried using the NLPID multiplexing method
   described in RFC 2427 [4]. The RFC 2427 encapsulation MUST be used in
   the special case that Frame Relay Network Interworking or transparent
   mode Service Interworking [9] are used, but is NOT RECOMMENDED for
   other applications.  Appendix A (which is for information only) shows
   the format of the FR-SSCS-PDU as well as how IP and CLNP PDUs are
   encapsulated over FR-SSCS according to RFC 2427.

   This memo also includes an optional encapsulation for use with
   Virtual Private Networks that operate over an ATM subnet.

   If it is desired to use the facilities which are designed for the
   Point-to-Point Protocol (PPP), and there exists a point-to-point
   relationship between peer systems, then RFC 2364, rather than this
   memo, applies.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   RFC 2119 [10].

3.  Selection of the Multiplexing Method

   The decision as to whether to use LLC encapsulation or VC-
   multiplexing depends on implementation and system requirements.  In
   general, LLC encapsulation tends to require fewer VCs in a
   multiprotocol environment.  VC multiplexing tends to reduce
   fragmentation overhead (e.g., an IPV4 datagram containing a TCP
   control packet with neither IP nor TCP options exactly fits into a
   single cell).

Grossman & Heinanen         Standards Track                     [Page 2]
RFC 2684                Multiprotocol Over AALS           September 1999

   When two ATM end systems wish to exchange connectionless PDUs across