Attachment - CIF Specification
Cells In Frames Version 1.0:
Specification, Analysis, and Discussion

July 31, 1996


yellow rule

Introduction
CIF Formats
CIF Layer Procedures
Signalling
Management
Acknowledgments
References
Appendix A: CIF Format Identifiers
Appendix B: Pseudocode for CRC Generation
Appendix C: Pseudocode for RM cell management
Appendix D: CIF MIB
Appendix E. Token Ring Implementation
Annex I: Discussion

yellow rule

Introduction

This document specifies the mechanisms by which ATM traffic is carried across a media segment and a network interface card conforming to the Ethernet Version 2 specification, IEEE 802.5 Token Ring, or IEEE 802.3. The mechanisms are collectively known as "Cells In Frames," or "CIF." ATM cells can be carried over many different physical media, from optical fiber to spread spectrum radio. ATM is not coupled to any particular physical layer. CIF defines a new pseudo-physical layer over which ATM traffic can be carried. It is not simply a mechanism for translation between frames and cells; neither is it simple encapsulation.

The concept of carrying cells in legacy LAN frames is not new [Armitage90, Armitage93, and Armitage94]. The methods proposed for CIF have some unique features that enhance performance and adaptability. The definition of a protocol between CIF end system software and a CIF attachment device ("CIF-AD") makes it possible to support ATM service, including multiple classes of service, over an existing LAN NIC, just as if an ATM NIC were in use. This document specifies how the ATM layer protocols can be made to work over the existing LAN framing protocols in such a way that operation is transparent to an application written to an ATM compliant API. Unless specifically stated otherwise, all aspects of this specification apply equally to any LAN type.

The addition of the CIF functionality to an existing LAN-attached workstation extends the functionality of the LAN to include the ATM capabilities for priority scheduling, leaky bucket traffic shaping, and end-to-end protocol independent flow control when using the Available Bit Rate (ABR) services.

An ATM end system possesses an ATM Signalling module, an ILMI module, and the ability to process multiple AAL types. Together these are the "ATM processing layer." In order to provide a generic solution that works with the existing LAN driver on the CIF end systems, a "shim" bridges between the ATM processing layer and the existing LAN drivers. Legacy applications have access to the AAL layers via a LAN Emulation module [LANE], MPOA [MPOA], or classical IP over ATM [RFC1483, RFC1577, RFC1755], just as with other end system ATM implementations.

The CIF-AD receives groups of cells from the end system and forwards them to an ATM backbone switching fabric. The CIF-AD might be implemented as a multiplexor or, more likely, an ATM switch. To be compliant with CIF functionality, the CIF-AD may but is not required to implement LANE, MPOA, or Classic IP. Figure 1 shows a single end system attached to point-to-point 10BASE-T or other LAN wiring. This is expected to be a common configuration.

Note: Not all possible shared LAN configurations involving multiple CIF-ADs have been considered in this specification and some may not function correctly. The case of multiple CIF-ADs on a single shared LAN segment has been considered and is supported by this specification.

Note: A CIF-AD implementation may optionally support both CIF and non-CIF frames from a CIF end system. Alternatively, this traffic may be handled with existing LAN equipment on the same shared segment if desired.

Figure 1: An ATM network with CIF at the edge

One of the goals of the mechanisms described in this specification is to ensure that the CIF end system is not unduly burdened by ATM processing requirements. Thus CIF offers options to move some of the ATM processing from the CIF end system to the attachment device. There are three ATM functions that may impair performance if implemented in software in a CIF end system: ABR traffic management (especially RM cell management), AAL5 CRC calculation, and the actual generation of cells by the ATM layer.

CIF functionality includes: specification of the framing for carrying cell payloads on the LAN; the generation and interpretation of the frames and action to be taken based on the contents of the frames; control; and management. The following sections of this document are purely specification, and are intended as a guide to implementation. Additional useful information, considered informative (i.e., not a mandatory part of the specification), is included as appendices. Informative discussion and analysis then follows in Annex I.

CIF Formats

General

On an Ethernet, CIF frames shall have a standard Ethernet Version 2 header and trailer. CIF devices may be configured to support 802.3 as well, but there is no mechanism defined in CIF for negotiating framing. If the CIF-AD and CIF end systems support it, it may be configured manually.

Ethernet CIF Frame Format

IEEE 802.3 CIF Frame Format

IEEE 802.5 CIF Frame Format

SNAP Header

CIF Ethernet frame headers shall use an Ethernet type value of hexadecimal 8821 (decimal 34829).

CIF frames shall be encapsulated in 802.5 Token Ring and 802.3 (LLC class-1) by the use of a SNAP header. This is identified in the 802.2 protocol by the prefix of X'AAAA03' followed by a five byte SNAP header. The value of the SNAP header shall be X'0000008821' . See Appendix E for other requirements specific to Token Ring.

The first 8 octets of the frame payload shall contain the CIF header. The CIF header carries the information that is passed as parameters from the AAL layer to the ATM layer as well as CIF-specific information. The first bit of each of the first three octets (bits 0, 8, and 16, labeled "p") are even parity bits for the octets of which they are a part. For example, for CIF format type 0, octet 0 is binary "00000000". For CIF format type 1, octet 0 is binary "10000001". For CIF format type 2, octet 0 is binary "10000010".

CIF Header Format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|p| CIF fmt |p|f f|fmt flags|p| fmt flags | GFC | VPI |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| VPI | VCI | VCI | VCI | VCI | PT |C| HEC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

p: Even parity bit for octet
CIF fmt: CIF format identifier
ff: CIF format independent flags
fmt flags: CIF format-dependent flags (2 fields)

GFC: Generic Flow Control
VPI: Virtual Path Identifier
VCI: Virtual Channel Identifier
PT: Payload Type
C: Cell Loss Priority
HEC: Header Error Check

CIF Format Identifier

In the CIF header, bits 1-7 of octet 0 are used as the CIF frame format identifier. The defined CIF frame formats are discussed in the following sections.

The CIF Format Identifier Authority assigns CIF format identifiers. See Appendix A.

Only three format types are defined. Formats 0 and 1 are used for CIF Signalling. Format 2 is the default format for carrying user traffic.

Formats 112-127 are designated for use in experimentation and for pre-standard CIF implementations. Every CIF implementation must support format types 0, 1 and 2.

CIF Format Independent Flags

Bits 9-10 (ff) in octet 2 contain flags that are independent of any CIF format type. The uses of bits 11-15 in octet 1, and bits 17-23 in octet 2, depend on the CIF format type (octet 0).

The CIF format-independent flags are reserved. They shall be set to 0 when sent and shall be ignored when received

Cell Header Template

The structure and semantics of octets 3-7 in the CIF header are the same as those of an ATM UNI cell header. These octets are collectively known as the "CIF cell header template."

The sender of a LAN frame shall always calculate and fill in the HEC field. The receiver may either rely on the LAN CRC to detect errors in the frame, and not validate the received HECs, or it may check the correctness of the HEC. The procedure to be followed on detecting an incorrect HEC is outside the scope of this specification.

CIF Format Dependent FlagsCIF

The format-dependent flags differ depending on the CIF format type, and are described under each format.

The content of the rest of a CIF LAN frame, after the CIF header, depends on the CIF format type, and is discussed under the individual format types.

Format Types 0 and 1

Formats 0 (binary 00000000) and 1 (binary 10000001) are used by CIF end systems and access devices for CIF-layer to peer CIF-layer communications. Format 0 is used for messages from the CIF end system to the CIF-AD. Format 1 is used for messages from the CIF-AD to the CIF end system. Formats 0 and 1 are the same except for the format type field, which is different to allow for flexibility and easier protocol analysis.

For format 0 the CIF header is as follows:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|p| CIF Fmt |p| reserved |p| reserved | |reserved |

|0|0 0 0 0 0 0 0|0|0 0 0 0 0 0 0|0|0 0 0 0 0 0|A|0 0 0 0|0 0 0 0|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| reserved |

|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0|0|0 0 0 0 0 0 0 0|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

:1 1 1 ... format types supported :

: (128 bits) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | | reserved | |

|C|M|0 0 0 0 0 0 0 0 0 0 0 0 0 0| TLV Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... TLV elements ... |

| |

p: even octet parity

A: link activated flag (0=inactive, 1=active)

Formats types supported : bitmask, see below

C: proxy AAL5 CRC services option flag

M: multiple CIF headers in frame flag

TLV length total length of the TLV elements following

TLV elements: see below

Format 1 differs from format 0 only in the first octet, which shall be binary "10000001".

In formats 0 and 1, bit 23 is a format-dependent flag, the "link activated" flag, which is used to declare whether the sender of the format 0 or 1 frame believes the link to be active or not (see CIF Activation Procedures for details). The CIF cell header template fields are unused and reserved.

Following the CIF header, a format 0 or 1 frame shall carry a 128-bit mask indicating the CIF format types the sender is willing to send and wishes to receive, with format type 0 represented by the most significant bit and format type 127 represented by the least significant. Every CIF implementation shall support at least format types 0, 1, and 2, and the corresponding bits of the mask shall always be 1. The receiver of this format 0 or 1 frame shall use only the intersection of the format types listed in this message and the format types that its peer has indicated its willingness to support.

Following the format types bitmask, 16 bits are used for options that can be represented as bit flags. The following flags are defined in this version of CIF. All other bits are reserved and shall be sent as 0 and ignored upon receipt.

C: Proxy AAL5 CRC generation and validation
In a CIF format 0 frame (the sender is a CIF end system), a value of 0 signifies that the CIF end system is not requesting proxy AAL5 CRC generation and validation, that it takes responsibility for AAL5 CRCs. If the value is 1, the CIF end system is requesting that the CIF-AD take responsibility for AAL5 CRCs. In a CIF format 1 frame (the sender is a CIF-AD), a value of 0 signifies that the CIF-AD is not willing to take responsibility for AAL5 CRCs, while a value of 1 indicates that it is willing to take such responsibility. Proxy AAL5 CRC services are described under each format type that optionally uses them. If either the CIF end system or CIF-AD sets this bit to zero, then the CIF end system will be responsible for CRC generation and validation.
M: Multiple CIF headers in CIF frame
In a CIF format 0 or format 1 frame, a value of 0 signifies that the sender of the frame does not support multiple CIF headers in a single CIF frame. A value of 1 signifies that the sender is able to support this capability. Multiple CIF headers in a single frame shall not be used unless supported by both the CIF end system and the CIF-AD.

Following the bit flags are one or more variable-length elements in {type, length, value} triplets. First is the total length of all of the variable-length elements, and then the elements themselves. If there are no TLV elements the total TLV length shall be 0.

The format for each element shall be:

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|C|0| Type | Length | [Value...]

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C (bit 0)

"Compulsory." If 0, the extension may safely be ignored when the receiver does not recognize the type code. If 1, and the receiver does not recognize the type code, communications cannot be established between the CIF-AD and the CIF end system. In this version of the CIF specification there are no CIF-level error messages, and the receiver of the format 0 or 1 frame refuses to establish communications simply by not responding.

0 (bit 1)

Reserved, shall be set to 0 when sent and ignored when received.

Type

The element type code. An unsigned integer between 0 and 63. Specific element types are described below.

Length

The length in octets of the value field (not including the C flag, reserved flag, or type and length fields). An unsigned integer between 0 and 255. A value of 0 signifies that the Value field is zero length.

Value

The value of the element. The value is variable length, between 0 and 255 octets.

Variable length elements may be included in any order. Any particular element (except for the vendor-private element) may occur only once in a frame. The vendor-private element may occur multiple times in a frame in order to allow for vendor-private elements that do not share the same vendor ID to be present.

If the total length of the CIF payload, including the CIF header and the format 0 or 1 payload, is less than 56 octets, it shall be padded with 0s to a minimum total length of 56 octets (CIF header plus 48 octets, or 74 octets including the Ethernet header and trailer).

The variable length elements are as follows:

Element 0: List termination. Compulsory.
Element type 0, if present, terminates the list of elements. The length shall be 0.

Element 1: Desired Nrm value for Available Bit Rate Service. Non-compulsory.

Element type 1, if present, identifies a value for Nrm to be used for Available Bit Rate traffic when connections are established through the CIF-AD to the CIF end system. The CIF end system sends a format 0 message to request a value which it wishes the CIF-AD to use in its ATM Signalling to the CIF end system for ABR services. If the CIF-AD supports Virtual Source/Virtual Destination (VS/VD), it may use this value within its communication with the CIF end system, and it shall respond to the CIF end system's format 0 message with a format 1 message to indicate the value that it will actually use on the CIF segment.


Element 63: Vendor-private. Non-compulsory.

The vendor-private element is intended to convey vendor-private information. The format of the value of a vendor-private element is a 3-octet (24-bit) vendor ID (as assigned to the vendor by IEEE) followed by vendor-dependent data. While the use of a vendor-private element is specific to that vendor, in general if the recipient of a vendor-private element does not understand it or does not wish to support it, the recipient shall not include that element in any response.

Format Type 2

In CIF format 2 (binary 10000010), the LAN frame payload shall consist of one or more groups, comprising a CIF header followed by one or more 48-octet cell payloads (SAR-PDUs, ATM-SDUs), placed contiguously in the frame, without cell headers. Multiple groups are allowed only if both ends of a CIF link indicate willingness to support multiple groups by setting the M flag in the format 0 or 1 header.

ATM cell payloads are packed in CIF frames along with CIF headers which contain parameters that describe the cell payloads' ATM headers. In CIF frames sent from the CIF end system to the CIF-AD, the CIF header is used to specify parameters for cell headers that shall be constructed for those cell payloads by the CIF-AD. In frames sent from the CIF-AD to the CIF end system, the parameters describe the contents of the cell headers that were received from the ATM network with the payloads. In addition, CIF format type 2 offers options that permit functions to be provided by the CIF-AD to assist the CIF end system.

Within each of these groups of CIF header plus cell payloads, all of the cell payloads shall be destined to the same VC. Cell payloads shall be complete (e.g. the AAL1 SAR-PDU header octet shall be calculated and inserted). A frame shall contain no partial cell payloads.

The minimum CIF Format 2 LAN frame, carrying one cell payload, shall consist of 14 octets of Ethernet header, 8 octets of a single CIF header, 48 octets of cell payload, and 4 octets of Ethernet trailer, for a total of 74 octets. The maximum single header CIF format 2 frame carries 31 cell payloads or 1488 octets. CIF frames with multiple headers shall not exceed 1496 octets. If each cell had an associated header the frame would consist of 26 cells and headers with a total length of 1456.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1|0 0 0 0 0 1 0|p|r r| CCCCC |p|T|V|r| SSSS | GFC | VPI |

|p| Format type | | | count | | | | | seq# | Cell hdr tmplt|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| VPI | VCI | VCI | VCI | VCI | PTI |X| HEC |

| cell header template (continued) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cell Payloads |

| . . . . . |

| . . . . . |

| . . . . . |

r: Reserved, must be 0

p: octet parity bits (even parity)

CCCCC: Cell payload count for this CIF header (0 indicates that the header applies to the remainder of the CIF frame.)

T: Payload type toggle indication

V: AAL5 CRC validity indication

SSSS: PDU Sequence Number

GFC: Generalized Flow Control

VPI: Virtual Path Identifier

VCI: Virtual Channel Identifier

PTI: Payload Type Indicator

C: Cell Loss Priority

HEC: Header Error Check

CCCCC (count field)

The cell payload count field is a 5-bit unsigned integer indicating the number of cell payloads which follow this CIF header and to which it applies. After the cell payloads associated with this CIF header, one or more additional groups of CIF header plus cell payloads may occur. A 0 in the count field indicates that this CIF header is the last in the LAN frame and applies to all remaining cell payloads.

T (payload type toggle flag)

The format 2 T flag signifies that AAL dependent processing should be applied to the last cell of the payload. In the case of AAL5 the third bit of the PTI field shall be inverted on the last cell to indicate the end of a CPCS-PDU. The use of the format 2 Payload type toggle indication flag is described in Section 3.3, "Frame Generation and Processing."

V (AAL5 CRC flag)

The use of the format 2 V flag is described in Section 3.3.1, "AAL5."

SSSS (PDU sequence number)

The PDU sequence number shall only be used in CIF headers applying to user data cells (i.e., those with a PTI field value of binary 000, 001, 010, or 011), and only for AALs where an AAL CPCS PDU can be span more than one CIF LAN frame. That is, for example, the PDU sequence number field is not used for AAL1, and it is not used for OAM and RM cells in AAL5 VCs. Using a valid PDU sequence number on these frames increases the probability of detecting errors in PDUs. The use of the PDU sequence number is described in more detail in Section 3.3.1.4

Format Types 112-127

Format types 112 through 127 inclusive are reserved for pre-standard implementations of ATM over LANs.

CIF Layer Procedures

CIF Activation Procedures

When either the CIF end system or the CIF-AD is starting up, it does not require knowledge of the other system's MAC address. Until it gains this knowledge, the CIF link to the other system is considered down.

The CIF end system shall initialize the CIF link by sending a CIF format 0 frame (described above) with the Link Activated flag set to zero. It shall send this frame to a MAC-layer multicast address that is assigned specifically for this purpose. Its value is xxxxxxxxxx (to be assigned).

A CIF-AD shall not send any CIF format 1 frames if it considers the link to be down. The CIF-AD only sends CIF format 1 frames when it considers the CIF link to be in the up state. A CIF-AD waits to receive a CIF format 0 frame, either multicast or unicast, from a CIF end system. When it receives one, it learns that CIF end system's individual MAC address, as well as the CIF options the CIF end system requests and is willing to support. The CIF-AD declares the CIF link to that end station to be in an up state, and sends CIF format 1 frames to this CIF end system, using the CIF end system individual MAC address as the destination address.

CIF end systems receive only unicast frames. CIF-ADs receive either multicast or unicast frames, but send only unicast frames to CIF end systems from which they have received frames.

Upon receipt of a CIF format 1 frame, the CIF end system learns the MAC address of the CIF-AD, as well as what CIF options the CIF-AD requests and is willing to support. From that time on it sends only point-to-point unicast frames destined to the CIF-AD's individual MAC address. It also places the CIF link into the up state and sets the Link Activated flag to 1 in its next Format 0 frame.

Bringing a link up is thus a three step process. First the end system searches for a CIF-AD to communicate with. Then the CIF-AD responds that it is willing to do so. Finally, the end system confirms that it will be accepting the CIF-AD's services, and in the process the link is declared up by both parties.

When there are multiple CIF-ADs on the same LAN segment, an end system may receive CIF format 1 frames from more than one CIF-AD. The CIF end system shall choose a CIF-AD from among the those that respond to its multicasts. After the choice is made, following the above rule, the CIF end system shall send CIF frames, of any type, only to that CIF-AD. Messages from that CIF-AD shall be accepted, but messages from any other MAC address shall be ignored. Subsequently, if the CIF end system declares the link to the CIF-AD down again, it again sends CIF format 0 frames to the multicast address, accepts messages from any CIF-AD, and chooses one to which to send further CIF frames.

When there are multiple CIF end systems on the same LAN segment, a CIF-AD may receive messages from more than one CIF end system. If the CIF-AD supports multiple CIF end systems on a segment (optional), it shall respond to each as it if had a point-to-point connection to it, i.e. with unicast point-to-point frames. If it does not support multiple CIF end systems it is an implementation option as to how it should respond.

A CIF end system may receive a CIF frame from the CIF-AD when it has declared a CIF connection down but before it can send a multicast frame, or a CIF-AD may receive a unicast frame whose contents are not appropriate for the state of the connection. In that case it may assume connectivity is established, place the CIF link in the up state and save the message's source MAC address.

CIF Link Maintenance Procedures

CIF provides pseudo-physical connectivity detection and maintenance between the CIF end system and the CIF-AD, using CIF format 0 and 1 frames. A CIF end system or CIF-AD shall send a format 0 or format 1 frame every 5 seconds in the up state. When in the down state, a CIF end system shall send a format 0 frame every 1second.

If either the CIF end system or the CIF-AD does not receive a CIF frame from a peer in 15 seconds then it shall place the link into the down state.

CIF LINK Finite State Machine for CIF End System

Event

DOWN

UP

Initialization Multicast CIF format 0 frame; start 1 second timer
Reinitialization (by upper layer) -> DOWN, Initialization -> DOWN, Initialization
Timer (1 second) Multicast CIF format 0 frame;start 1 second timer No action
Timer (5 second) Impossible count=count+1;
if count= 3 then do;
DOWN; count = 0; end;
else do;
Unicast CIF format 0 frame; start 5 second timer end;
Receive format 1 frame Set Link Activated flag; unicast CIF format 0 frame; start 5 second timer; count = 0; UP count=0
Receive any frame not format 1 Set Link Activated flag; unicast CIF format 0 frame; start 5 second timer; count=0; UP count=0

CIF LINK Finite State Machine for CIF-AD

Event
DOWN
UP
Receive Format 0 Set Link Activated flag; unicast CIF format 1 frame; start 5 second timer; count = 0; UP count=0
Re-initialization (by upper layer) -> DOWN -> DOWN
Timer (5 second) Impossible count=count+1; if count= 3 then do;
DOWN; count = 0; end;
else do;
Unicast CIF format 0
frame; start 5 second timer;
end;
Receive any frame not format 0 Set Link Activated flag;send CIF format 1 frame;count=0 UP count=0

Format 2 Frame Generation and Processing

In CIF format 2 frames, the cell header template portion of the CIF header is used to generate or infer cell headers for the cell payloads associated with that CIF header. All fields in the ATM cell header portion of the CIF header are used as defined in the ITU specification for the ATM cell header [ATM] with the following exceptions.

If the format 2 Payload Type Toggle Indication flag is set in the CIF header:

  • When the CIF end system receives a CIF header from the CIF-AD in which the CIF format 2 T (Payload Type Toggle Indication) flag is 1, the CIF end system shall consider the cell payloads associated with that CIF header to all have an associated payload type that is the same as the payload type in the CIF header PTI field, except that the payload type for the last cell payload associated with the CIF header shall be considered to be the inverted value of the ATM-user-to-ATM-user indication bit.
  • When the CIF-AD receives a CIF header in which the format 2 T flag is 1, the CIF-AD shall set the payload type for all cells generated from the cell payloads associated with that CIF header to be the same as the payload type in the CIF header PT field, except the last one, where it shall be set to the opposite of the value of the ATM-user-to-ATM user indication in the CIF header PT field.
  • When the CIF-AD is generating a CIF frame from cells received on another interface, and adds a cell payload to it from a cell whose payload type indicated a different ATM-user-to-ATM user indication than that of the first cell payload, it shall set the CIF format 2 Payload type toggle indication flag in the frame's CIF header to be 1 and add no more cell payloads to the group associated with that CIF header.

hese rules are true for all AALs. Only the last cell payload in a group associated with a CIF header can be for a cell where the payload type differs from that of the first cell. The ATM payload type field PTI is defined for all AAL types in ITU Recommendation I.361 as follows:

000 User data cell, congestion not experienced, ATM-user-to-ATM user indication 0
001 User data cell, congestion not experienced, ATM-user-to-ATM user indication 1
010 User data cell, congestion experienced, ATM-user-to-ATM user indication 0
011 User data cell, congestion experienced, ATM-user-to-ATM user indication 1
100 OAM F4 segment associated cell
101 OAM F5 end-to-end associated cell
110 Virtual Circuit Resource Management Cell
111 Reserved

AAL5

General

In VCs using AAL5 the cell payloads associated with a particular CIF header shall all belong to the same CPCS-PDU, and the last cell payload of the CPCS-PDU may be included in the same group as cell payloads that are not the last by using the format 2 Payload Type Toggle Indication flag.

For traffic from the CIF end system to the network, processing of the AAL-SDU starts in the CIF end system and is completed at the CIF-AD where the ATM cells are created. On the send side the AAL-SDU is the basic unit. CPCS processing is performed, adding any header or trailer, and the resulting CPCS-PDU is broken up into 48 byte payloads at the SAR layer. A CIF header and then a LAN header are prepended to up to 31 of the 48 byte SAR-PDUs (the most that fit in a single Ethernet frame), and a LAN trailer is appended to the end of the set. (Multiple groups of CIF header and SAR-PDUs may be included in a LAN frame.) The resulting frame is then sent to the CIF-AD. This process is repeated as necessary until the entire CPCS-PDU has been transmitted. In the CIF-AD the LAN header and trailer for each LAN frame are discarded and the CIF header is used to construct an ATM Cell header for each of the ATM cell payloads within a group.

For traffic from the network to the CIF end system, the CIF-AD places one or more cell payloads in a frame with an appropriate CIF header. The CIF-AD stops filling a particular frame whenever:

the number of cell payloads placed in the frame reaches a maximum for that VC (31 or less). A CIF-AD may choose a value less than 31 to improve latency; however, this must be traded against increased processing load placed on the CIF end system through forwarding a larger number of smaller CIF frames.

the cell payload from a cell is placed in the frame where the new cell's payload type differs from the payload type of the first cell placed in the group of cell payloads and CIF header.

Traffic from CIF end system to CIF-AD

The CIF end system shall provide a complete CPCS-PDU to the CIF-AD in one or more CIF frames. The CIF end system shall add the appropriate amount of padding and an AAL5 trailer to create a complete CPCS-PDU. The trailer length field and UUI shall be filled in correctly.

The CIF end system shall segment an AAL5 CPCS-PDU into groups containing 1 to 31 cell payloads. Each group shall begin with a CIF header. The PDU sequence number field in the CIF header shall be filled in for frames that contain appropriate PDUs. In CIF format type 2, frames may contain cells from more than one CPCS-PDU if this capability has been agreed to at CIF activation. If the frame contains more than one cell from a PDU, and includes the last cell of the PDU, then the payload type in the CIF header shall be set to indicate ATM-user-to-ATM user indication 0 and the format 2 Payload type toggle indication flag in the CIF header shall be set to 1.

Figure 2: An example of an AAL5-SDU in multiple LAN frames

The format 0 and 1 Proxy AAL5 CRC generation and validation flag works with the format 2 AAL5 CRC validity indication flag to determine how AAL5 CPCS-PDU CRCs are managed. The exchange of the Proxy AAL5 flag with format 0 and 1 frames determines which system is responsible for AAL5 CRCs. If the CIF end system is responsible for AAL5 CRCs, the CIF-AD gives AAL5 CRCs no special treatment and the format 2 AAL5 CRC validity indication flag is never used. If the CIF-AD has assumed responsibility for AAL5 CRCs, then the following are true:

The format 2 AAL5 CRC validity indication flag may be set by the end system in a CIF header that is associated with the cell payload containing the end of an AAL5 CPCS-PDU and thus the CRC-32 field. The format 2 AAL5 CRC validity indication flag is used whenever the CIF end system does not provide a valid CRC-32 field and the CIF-AD is to calculate it on its behalf.

Upon receipt of the last cell payload of an AAL5 CPCS-PDU (the Payload type toggle indication being 1), the CIF-AD shall:

  • fill in the AAL5 CRC field before sending the last cell of the PDU into the network.
  • check the PDU sequence number and the AAL5 length field. If either of these tests fail, the CIF-AD shall modify the last cell of the PDU to indicate an abort by modifying the AAL5 length and CRC fields to be zero.

Traffic from CIF-AD to CIF end system

Similarly, if the CIF-AD has not taken responsibility for AAL5 CRC management, neither the CIF-AD nor the CIF end system give AAL5 cells special handling with regard to CRCs. However, if the CIF-AD has taken responsibility, the following shall be done:

In each CIF frame being sent to the CIF end system for an AAL5 CPCS-PDU the CIF-AD shall set the PDU sequence number as described in section 3.3.1.4

The CIF-AD shall validate the CRC for an AAL5 CPCS-PDU arriving from the network. In the CIF header associated with the last cell payload of an AAL5 CPCS-PDU being sent from the CIF-AD to the CIF end system (the cell payload that contains the CRC), the CIF-AD shall set the format 2 AAL5 CRC validity indication flag to 1 to indicate that the AAL5 CRC field does not contain an actual CRC but rather an indication of validity.

If a valid CRC was received from the network, the CIF-AD shall set the AAL5 CRC field to all 1s. If the CRC validation failed, it shall set both the AAL5 length field and the AAL5 CRC field to all 0s to indicate an AAL5 abort.

After the CIF end system has received the entire AAL5 CPCS-PDU, it shall check: the PDU sequence number in the last received CIF header s described in section 3.3.1.4, the CRC validity, and the AAL5 length field. The length must be a value greater than or equal to the actual received length minus 40, and less than or equal to the received length minus 8 (because of variable AAL5 padding to fill out the final cell). If the PDU fails any of the 3 tests, it shall be delivered to the client layer as if it had been received in error.

The PDU Sequence Number

The PDU sequence number field in the CIF Format 2 header is an unsigned 4-bit integer that is used for error detection. Senders (both CIF end system and CIF-AD) shall insert a valid PDU sequence number specific to each virtual channel for which they are relevant. As discussed in Section 2.3, the PDU sequence number shall be used in CIF headers applying to user data cells and AALs where an AAL CPCS PDU can be span more than one CIF LAN frame.

When a virtual channel becomes active, the first CPCS-PDU sent on that VC by each source shall set the sequence number field in the CIF header of the PDU to 1, and shall hold the sequence number at 1 through the last CIF header associated with cell payloads for that PDU. The PDU sequence number is incremented by 1 for the first CIF header of the next PDU and (again) remains the same for all CIF headers associated with cell payloads containing that PDU. Sequence number 15 is followed directly by sequence number 0. PDU sequence numbers are independent for the two different directions of traffic flow between the CIF end system and the CIF-AD.

The receiver of frames for an AAL5 VC must at least check the PDU sequence number on the last CIF header of every AAL5 CPCS-PDU it receives. It should check the PDU sequence number on every frame, in order to avoid dropping some frames unnecessarily (discussed in Annex I.5).

The CIF end system shall check PDU sequence numbers in every appropriate CIF header. If the CIF end system receives a CIF header whose PDU sequence number does not directly follow that of the previous CIF header received for that VC, and if the previous CIF header was not associated with a cell payload containing the end of an AAL5 CPCS-PDU, the PDU previously being accumulated is treated as if it were aborted and the current CIF header and associated cell payload are considered the start of a new PDU. This procedure avoids unnecessary discarding of PDUs. See Annex I.5 for more discussion.

For traffic from the CIF end system to the CIF-AD, the CIF-AD behavior is the same with one exception. As above, if the CIF-AD receives a CIF header whose PDU-sequence number does not match that of the previous CIF header but the previous CIF header's cell payloads did not contain the end of a PDU, the PDU received so far shall be treated as aborted. However, since the CIF-AD is forwarding cells to the network, in this case it shall generate a new cell, on its own, containing the end of an AAL5 PDU, with length and CRC fields set appropriately for an AAL5 abort.

Other AALs in CIF Format 2

While AAL0, AAL1, and AAL5 are the only AALs that have been considered in this specification, there are no known restrictions in CIF that would cause other new AALs not to work.

AAL1 is only expected to be used in the "simplified" form for voice interworking [I.363.1].

Available Bit Rate Support

Based on the capabilities of the CIF-AD and the Nrm value exchanged in the format 0 and 1 frames, the CIF-AD may provide VS/VD support for ABR, i.e., the CIF-AD must include a non-zero Nrm TLV element in its format 1 frames.

For all VCs using ABR traffic management, the CIF-AD optionally may act as an ABR virtual source and virtual destination (VS/VD), sending and receiving RM cells on behalf of the CIF end system, in which case it shall communicate with the CIF end system as described here. If the CIF-AD does not support VS/VD behavior then it shall pass RM cells either transparently or, optionally, set the congestion indication, no increase bits, or explicit rate fields in the RM cells flowing through it.

If the CIF-AD supports VS/VD behavior, it shall maintain a value for its available cell rate (ACR) in conformance with the ABR specification, and shall indicate to the CIF end system the rate at which the CIF end system may generate cells by creating a response RM cell and encoding its current ACR rate into the explicit rate field of that RM cell. The CIF-AD may optionally set the congestion indication and no increase bits in this cell and may restrict the explicit rate further if it is currently congested.

An RM cell shall be generated by the CIF-AD to the CIF end system whenever either the ACR on an ABR VC changes significantly from the last time the ACR was sent, or periodically at a rate consistent with the Nrm value indicated in the CIF-AD format 1 frames.

The CIF end system shall act as a compliant source/destination as defined by the ATM Forum's TM 4.0 specification. The Pseudocode for this is included in Appendix C. It shall send forward RM cells at a rate consistent with the Nrm value indicated by the CIF-AD format 1 frames and shall turn around all forward RM cells received and send out backward RM cells.

Signalling

It is intended that ATM Signalling functionality be fully supported without change. The specific version(s) of Signalling supported, at the CIF end system or in the CIF-AD, is vendor-dependent.

The CIF link connecting the end system with the attachment device may be considered an ATM user-network interface (UNI). As with other UNI implementations, it is necessary to define one end of the UNI as the "user" side of the link and one end as the "network" side of the link. While CIF does not require any specific mapping to function, it is recommended that, by default, the end of the link at the attachment device be defined as network-side and the end of the link at the end system be defined as user-side.

In configurations where multiple CIF end systems share a single LAN segment to access an attachment device, each association between an end system and an attachment device may be considered a separate UNI.

Management

ILMI support

It is intended that all ATM ILMI functionality be fully supported without changes. The specific version(s) of ILMI supported, in the CIF end system or in the CIF-AD, is vendor-specific.

The CIF MIB is contained in Appendix D. All implementations shall this MIB.

OAM Support

It is intended that OAM be supported as per any other ATM interface. Specifically, this means that OAM cells (payload types 4 and 5) are supported across the LAN via the standard CIF framing, and may be sent to the network by the CIF end system and/or received by the CIF end system from the network. The actual level of OAM support, at the CIF end system or in the CIF-AD, is vendor-specific.

CRC-10 generation for both OAM and RM cells shall be performed by both CIF-AD and CIF end system. The CIF end system shall ignore CRC-10 fields on receipt. The CIF-AD shall validate the field on all RM and OAM cells and discard without forwarding any cells in error.

Acknowledgments

Editing was done by Scott Brim (Cornell University). Comments can be addressed to him at <swb1@cornell.edu> Major individual contributions to this specification were made by: Robert Amy, Andrew Chittenden, Richard Cogger, Roy Dixon, Kingston Duffie, Jim Grace, Greg Hill, Sanjay Kumar, Vernon Little, Drew Perkins, Larry Roberts, Raphael Rom, David Singer, Michael Sobieski, and John Yang.

In addition, the following organizations contributed to this specification's development: 3COM Corporation; 3M Corporation; AMD; Allied Telesyn; Apple Computer Inc.; ATM Inc.; Bell Atlantic; Bellcore; Cirrus; Com21 Inc.; Connectware ATM Systems Division; Digi International; First Virtual Corporation; Fore Systems; Fujitsu Microelectronics; Future Communications Software; IBM Corporation; Integrated Device Technology; Lynx; MMC; Madge; Microsoft; National Science Foundation; Northern Telecom; Novell; Olicom; PMC-Sierra; Siemens; Stratacom, Inc.; Sumitomo Electric USA; Sun Microsystems; Texas Instruments; University of California, Davis; Whitetree; Zeitnet.

References

[AAL5] ITU-T. "AAL Type 5, Draft Recommendation text for section 6 of I.363." TD-XVIII/10. 29 January 1993.

[AAL5-CP] T1S1. "Proposed Procedures, Detailed Service Interface, and Layer Management Interface Description for AAL-5 Common Part." 92-285. May 1992.

[Armitage90] Armitage, G.J., and K.M. Adams. "Architecture of a Multimedia Desktop Workstation." Proc. Australian Video Communications Workshop, Melbourne, pp. 76-85. July 1990.

[Armitage93] Armitage, G.J., and K.M. Adams. "Using the Common LAN to Introduce ATM Connectivity." Proc. IEEE Computer Society 18th Conference on Local Computer Networks, Minneapolis, MN. September 19-22, 1993. See also ftp://ftp.bell core.com/pub/gja/mu/gja.18th.LCN.slides.ps.Z.

[Armitage94] Armitage, G.J. "The Application of Asynchronous Transfer Mode to Multimedia and Local Area Networks." PhD Thesis, Department of Electrical and Electronic Engineering, University of Melbourne, Australia. January 1994.

ATM] ITU-T. ATM Layer Specification. I.361. 1993.

[Cogger94] Cogger, Richard. "IEEE802.1 Looking for Guidance - Cells in Frames." Rem-Conf Internet mailing list (rem-conf@isi.edu). 21 July 1994.

[Ethernet2] Digital Equipment Corporation, Intel Corporation, and Xerox Corporation. "The Ethernet - A Local Area Network: Data Link Layer and Physical Layer Specifications, Version 2.0." November 1982.

[I.361] ITU-T., SG13. "B-ISDN ATM layer specification." I.361.

[I.363.1] ITU-T., SG 13. "B-ISDN ATM Adaptation Layer (AAL) Specification, Types 1 and 2." I.363.1. 10-21 July 1995.

[ILMI4.0] The ATM Forum Technical Committee af-ilmi-0065.000. "ATM Forum Interim Local Management Interface (ILMI) Specification 4.0."

[LANE] The ATM Forum Technical Committee. "LAN Emulation over ATM, Version 1.0." January, 1995.

[MPOA] The ATM Forum Technical Committee. "Baseline Text for MPOA." 95-0824.

[RFC1483] Heinanen, Juha. "Multiprotocol Encapsulation over ATM Adaptation Layer 5." RFC 1483. July, 1993.

[RFC1577] Laubach, Mark. "Classical IP and ARP over ATM." RFC 1577. January, 1994.

[RFC1755] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., Malis, A. "ATM Signalling Support for IP over ATM." RFC1755. February 1995.

[Partridge95] Partridge, Craig, and Hughes, Jim. "Performance of Checksums and CRCs over Real Data", ACM CCR 25:4, pp. 68-76. October, 1995.

[SIG4.0] The ATM Forum Technical Committee af-sig-0061.000. "ATM Forum User-Network Interface (UNI) Signalling Specification Version 4.0."

[TM4.0] The ATM Forum Technical Committee af-tm-0056.000. "ATM Forum Traffic Management Specification Version 4.0."

[UNI3.1] The ATM Forum Technical Committee. "User-Network Interface (UNI) Specification, Version 3.1." September, 1994. Available by FTP from ftp.atmforum.com.

[8802-5] ISO/IEC 8802-5 ANSI/IEEE Std 802.5 Second Edition 1995-12-29 Information technology - Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements Part 5: Token ring access method and physical layer

Appendix A: CIF Format Identifiers

Requests for CIF format identifiers should be e-mailed to cif-format-request@cif.cornell.edu.

Appendix B: Pseudocode for CRC Generation

There are a number of references to the generation of CRCs available at the Cell Relay site.

All the code fragments and examples that appear in this appendix are provided with the kind permission of Charles Micheal Heard and Angie Tso.

B.1 HEC generation

As the ATM cell header does not change from one frame to the next for a given VC, the HEC only needs to be calculated and saved when a given VC is set up. This value is then inserted into the ATM Cell header on every frame sent for a given VC. On receipt of a CIF frame, the HEC requires checking only if the receiver does "cut-through" as, in this case, the receiver doesn't know whether the media CRC is correct at the time the HEC is received.

There is an excellent tutorial on the theory of the HEC checksum available on the Cell Relay site. The following code, that also appears on that page, can be used to generate the HEC efficiently.

Click here to get code.

B.2 AAL5 CRC generation

There are a number of things to be wary of with the generation of CRCs using the code in this Appendix:

The initial value of crc_accum which you pass to update_crc is 0xFFFFFFFFL, not zero. This is true whether the code is used for CRC generation or checking.In order to generate the AAL5 CRC you must first run update_crc over the whole CPCS-PDU, including PADS, CPCS-UU, and all other trailer fields except the CRC field itself. You must then append the ones complement of the output from update_crc as the CRC field of the CPCS-PDU.

In order to check the AAL5 CRC you must run update_crc over the whole CPCS-PDU including the CRC field and check that the remainder is 0xC704DD7BL, as specified in recommendation I.363.

Note that update_crc has been designed to allow for incremental calculation one cell at a time should you wish to do so. All that you need to do is to save the return value from one invocation of update_crc and pass it as the crc_accum argument to the next invocation of update_crc.

The following code can be used to generate the AAL5 CRC.

Click here to get CRC-32 Code.

B.2.2 Angie Tso's Test Cases

Here are the examples of valid AAL-5 CS-PDU in I.363: (There are three examples in I.363)

Click here to get Code and examples.

B.3 Code for CRC-10 Generation

The attached test cases and C program show how to implement a reasonably efficient software algorithm for generating and checking the CRC-10 in AAL 3/4 cells or OAM cells. It computes the CRC on such a cell one byte at a time using the generator polynomial x^10 + x^9 + x^5 + x^4 +x + 1

Unlike the AAL 5 CRC-32 code from which it was derived, the CRC update routine in the attached C program combines the input data with the CRC accumulator after the accumulator is shifted via the table lookup algorithm. This is done so that the CRC bit positions are included in the accumulation; if they were excluded then byte alignment problems would arise since the CRC length is not an integral number of bytes. The test cases below have zeroes in the last two bytes of the cell, but the code which inserts the payload CRC does not in fact depend on this; arbitrary values could be stored in the last two bytes and the resultant CRC would still be correct. In particular, an AAL 3/4 payload length field could be included in the 6 MSBs of the next-to-last byte. Of course, if any of the other bits—i.e., those in the CRC positions -- were non-zero then the final value of crc10_accum would no longer be equal to the cell's CRC, and the printf statements in the C program would be incorrect.

B.3.1 CRC-10 Test Cases

Click here to get Test Cases.

B.3.2 CRC10 code

Click here to get Code.

Appendix C: Pseudocode for RM cell management

The following Pseudocode, from the ATM Forum Traffic Management 4.0 document, provides an example of conforming behavior for the source end system (SES) and destination end system (DES). It represents a minimal but complete implementation of the specified end system behavior. This Pseudocode also applies to the virtual source and virtual destination behaviors, as when segmented rate control is used by an intermediate network. This Pseudocode example is provided for a single source connection. It assumes, but does not detail, a cell scheduler mechanism that controls the cell emissions from the SES. For simplicity of example, it also assumes that only out-of-rate forward RM-cells will be sent when ACR < TCR.

The behavior of the SES is controlled by the values assigned to a set of parameters. PCR, MCR, and ICR, are in units of cells per unit time, and RIF is dimensionless. RDF, CDF and Nrm are dimensionless. PCR and MCR are agreed upon at connection setup time. ICR, RIF, RDF, CDF and Nrm are established by the network(s) at connection setup time, with values that are determined to best optimize performance over various network trade-offs. Values for these parameters observe the following constraints:

MCR <= ICR <= PCR
MCR <= ACR <= PCR
0 <= CCR <= min(ACR, LCR)

where CCR is the current cell rate, reflecting the user's offered traffic. Generally, but not necessarily, CCR will equal either ACR or 0, as the source either has or doesn't have traffic to send. LCR is the cell rate due to the physical line limitation. In this pseudocode the parameter "MCR" may be utilized to represent:

  1. A NIC implementation limit, due to a lower bound on the integer precision, e.g., 1 cell/second,
  2. A (low) value gratuitously offered by the network to provide improved performance, or
  3. A means to support a contracted or guaranteed "MCR".

Each of the following parameters is assigned a value as a result of connection setup:

ICR, PCR, MCR, RIF, RDF, Nrm, Mrm, CRM, CDF, Trm, TCR, and ADTF.

In this section a "!" to the right of a pseudocode statement is the start of a comment. In the comments, "Sn" refers to source behavior #n, and "Dm" refers to destination behavior #m. Each connection has a few variables for its operation:

SES Variables (Per connection)



Click here to get Code.