ATM is a connection-oriented, packet-based protocol that allows multiple logical data streams (for example, different videos) to be transmitted simultaneously over a single physical connection. The ATM driver passes data from multiple applications to the ATM hardware where the data streams are stored as separate queues. The data is segmented into ATM cells and multiplexed into a single physical stream (see Figure 1-2). Each ATM cell is 53 bytes long, of which 5 bytes are ATM overhead and 48 bytes are upper-layer data (also known as payload).

Each logical data stream is called a virtual channel (VC). All of the VCs from a transmitting endpoint can share one physical link to the ATM switch. However, at the switch, the VCs might be routed onto different outgoing physical links, depending on their final destinations. In this way, they can follow their virtual channel connection (VCC) to the destination endpoint. ATM requires that the endpoint-to-endpoint physical connection be established before transmission occurs for a VC's first bit of data.

Figure 1-2. Segmenting and Multiplexing Data from Multiple VCs

When each VC is set up, the user specifies a transmission rate, an upper layer conversion protocol (referred to as the ATM adaptation layer (AAL)), and, for some implementations (for example, switched virtual circuits), performance objectives that are referred to as the traffic contract.

The manner in which the ATM cells are multiplexed guarantees correct ordering of the upper-layer data and supports simultaneous transmission of multiple VCs in a single stream, as shown in Figure 1-3. (The single stream is passed to the SONET hardware as a single path and is explained in the following SONET section.) When the stream of cells arrives at its destination ATM layer, each conversation must be demultiplexed and reassembled before passing the data to the receiving application.

Figure 1-3. Multiplexed ATM Cells for Multiple VCs

Each VC within the single stream can be transmitted at a different rate. This is accomplished by taking cells from each VC's queue at a different rate. As the ATM hardware creates the single stream, it selects cells from the different VC streams in a manner that supports each channel's user-selected rate. For example, if the transmission rate for VC1 is twice the rate of VC2, the cells are selected and interleaved as shown in Figure 1-4, (instead of equally as shown in Figure 1-2, and Figure 1-3). In the example shown in Figure 1-4, when two cells have been transmitted for VC2, four cells have been transmitted for VC1.

Figure 1-4. Multiplexing Cells to Support Different Transmission Rates

The ATM Adaptation Layers (AAL) provide mapping between upper-layer formats and the ATM cell format. In addition, the AAL module handles the ATM cells in a manner that supports the selected class of service.^[3]All AAL functionality occurs at the endpoints (not in the switches). Upper-layer applications select a class of service (one of the AALs) from those summarized in Figure 1-5. AAL 5 is defined for high-speed data transfer and ATM signaling. AAL0 is an unofficial adaptation layer.

Figure 1-5. AAL Service Classes: Types of Protocol Mappings for ATM

SONET defines the fiber-optic physical layer. It covers issues such as the specifications for the multimode fiber optic cable, loss characteristics on the connectors, clock recovery, the available formats for organizing data payloads, and the frame boundary delimitation. SONET provides a variety of data rates and supports numerous payload formats.

When discussing SONET rates, it is important to distinguish between the line or signal rate (that is, the rate on the fiber) and the rates of the various communication streams (referred to as embedded transport rates) being carried within the SONET stream. SONET supports signal rates that are multiples of the basic 51.84 Mbit/s synchronous transport signal (STS) rate, as summarized in Table 1-2. The embedded transport rates are always slower than (or equal to) the signal rate and include some of the more commonly used rates in the communications industry today: for example, 1.544 (DS1 and T1), 2.048 (CEPT), and 6.912 (DS2) Mbit/s.

At the SONET level, the data stream logically consists of n separate paths (STS-1 streams), each carrying data of one type, encapsulated in STS-1 frames. The number of paths within a SONET stream is specified by the number in the SONET protocol's name. For example, SONET OC3 has three different paths (that is, three STS-1 streams) multiplexed within a signal rate of 155.52 Mbit/s. There is an exception to this. The concatenated formats of SONET (for example, OC3c and OC12c), have only one path and use an abbreviated form of the SONET frame. Within any SONET OCn stream, the multiple paths coexist through byte multiplexing; one byte from each path (each STS-1 frame) is transmitted, then another byte from each path is transmitted, as shown in Figure 1-6.

Figure 1-6. Byte Multiplexing within a SONET Stream

---

Note: The overhead associated with the SONET stream is not shown in Figure 1-6.

---

As explained in the preceding paragraphs, the basic physical building blocks for a SONET stream are bytes. Logically, however, the basic building blocks for a SONET data stream are SONET frames (also called STS-1 frames), as shown in Figure 1-7. Each STS-1 frame contains header and data for one path. The header contains protocol overhead data; the upper-layer data is carried in the synchronous payload envelope (SPE) portion of the frame. A SONET OCn stream uses larger frames constructed from n basic frames. For example, for SONET OC3 and OC3c, each frame carries three STS-1 SONET frames, as shown in Figure 1-8.

Figure 1-7. Basic SONET (STS-1) Frame

Figure 1-8. SONET OC3 Versus OC3c Frame Format

All of the data within any single SONET path must be of the same format. This is referred to as the mapping for the SPE. ATM is one of the available SPE mappings.^[5]Since each path within the SONET stream is a separate logical entity, each path can be mapped differently from the other paths carried in that SONET stream.

Each path is capable of carrying a number of embedded streams at lower transport rates. One STS-1 SONET stream (for example, Path 1 shown in the OC3 frame of Figure 1-8) could carry twenty-eight 1.728 Mbit/s channels. When the SPE mapping is ATM, the separate paths are collapsed into a single concatenated path; for example, for the 155.52 Mbit/s rate, the SONET protocol is OC3c. In OC3c, both the line rate and the path rate are 155.52 Mbit/s. Figure 1-8, shows the difference between the triple-path format of OC3 and the collapsed, single-path format of OC3c.

The VPI/VCI address is a 3-octet value contained in the header of the ATM cell (as shown in Figure 1-9). This value identifies a virtual channel. The value is locally assigned by each transmitting station and is unique (and valid) for only one physical link of the virtual channel (for example, from the host to its switch or between two switches). The VPI/VCI value is replaced at each switch along the virtual channel's span. This type of address is used for both PVCs and SVCs. For PVCs, it is the only ATM-level address required.

Figure 1-9. ATM Cell

The ATM network address comes in two formats: a 20-octet value called ATM network service access point (NSAP) (shown in Figure 1-10) or an up-to-15-octet value called native E.164 (shown in Figure 1-11). The ATM network address is globally unique, meaning that it identifies one (and only one) endpoint within the entire world. This address, or a portion of it, is usually assigned to a port by its ATM switch. The NSAP format allows a system to support multiple endpoints using a single port by assigning local values to one portion of the address (as explained in more detail in the following paragraphs). The ATM network address is required for SVCs, but not for PVCs.

The ATM NSAP format (shown in Figure 1-10,) can carry any one of following three types of addresses:

The contents of the IDI field are represented in binary code decimal (BCD) notation. For example, the country code for the United States of America is 840 (decimal); this is represented in the IDI field by the binary sequence 1000 0100 0000. Each type of IDI value requires padding and all IDI field padding is done with four 1s. For example, the DCC code requires only 12 of the 16 bits in the IDI field and DCCs are padded on the right, resulting in a binary sequence of 1000 0100 0000 1111 for the United States of America.

Table 1-3, indicates the organization that assigns and defines the values for the three different IDI fields of ATM NSAP addresses.

The ATM NSAP address can be logically divided into two sections: that portion assigned by the switch and the portion assigned at the endpoint. The part assigned by the switch is referred to as the network prefix. It includes all fields of the address except the end system identifier (ESI) and end system selector (SEL) fields, as shown in Figure 1-10. The endpoint's interim local management interface (ILMI) module communicates with the adjacent switch to retrieve its assigned network prefix and to register its values for the ESI field.^[7]Switches ignore the SEL field; however endpoint software can assign values to this field to differentiate among multiple upper-layer endpoints.^[8]

Figure 1-10. ATM Address: The NSAP Format

Figure 1-11. ATM Address: The E.164 Format

Each VC has a traffic contract associated with it. The traffic contract determines the performance characteristics of the data transmission. The two parameters that are always included in a traffic contract are the transmission rate (expressed in ATM cells per second) and the quality of service (QoS). Other performance parameters can be included, for example, cell delay variation (CDV), cell transfer delay, and cell loss ratio.

Since transmission rates are expressed in ATM cells per second, it is useful to know that one ATM cell carries 48 bytes of upper-layer data. For example, in order for an upper-layer to transmit (or receive) 3.5 megabits of data per second, the traffic contract must specify about 9115 cells per second (9115 cells * 48 bytes in each cell * 8 bits in each byte = 3,500,160 bits). If the upper-layer data includes an encapsulated protocol, some of the 48 bytes may contain non-ATM overhead, like TCP/IP headers.

The QoS classes are as follows:

The manner in which the traffic contract is negotiated depends on whether the endpoints are using a permanent virtual circuit (PVC) or a switched virtual circuit (SVC), as explained in “Permanent Virtual Circuits” and “Switched Virtual Circuits”.

A permanent virtual circuit (PVC) is a long-term (permanent) communication channel between two ATM endpoints. The channel can directly connect two ATM endpoints or can involve any number of intermediate switches between the two endpoints. PVCs are created during a relatively difficult installation and setup procedure. The traffic contract is negotiated, person-to-person or as-advertised, but in all cases, before the installation and setup takes place. The traffic contract's performance parameters are either built into the equipment or are configured, manually, by a network administrator. Each node in the network must be configured to conform to the negotiated traffic contract and the contract cannot easily be changed. The sequence of physical links for each PVC must be planned and manually configured. First, the existence of a complete physical connection must be verified. Then, at each port along the route, an address must be created to identify the resources being reserved for this PVC; this address usually consists of a VPI/VCI value and a port identification. Before a VPI/VCI value is selected for a link, the administrator must verify that the value is available at both ends of the link. For the example PVC shown in Figure 1-12, four address mapping tables (one at each node) must be configured manually with the following bidirectional mappings:

PVCs require significantly less software complexity and overhead than SVCs; however, they require significantly more administrative time for planning and configuring. PVCs are appropriate for environments in which the traffic contract and the point-to-point connections (PVCs) are well-defined and will remain stable for a reasonably long period of time. PVCs are required if any switch or host along the path does not support SVCs.

Figure 1-12. General Overview of PVC Configuration Tasks

As an example of the manual configuration entries required for every PVC, Figure 1-13, shows sample address mapping tables for the single PVC shown in Figure 1-12.

Figure 1-13. Example of Address Mapping Tables for One PVC

A switched virtual circuit (SVC) is created and torn down dynamically (more or less in real time), as requested by an upper-layer application. The switches, the ATM signaling software, and, for IP traffic, the ATMARP software, automatically handle most of the negotiable parameters and operation management, including the following operations:

Due to this automation, an SVC environment requires much less administrative time than a PVC configuration.

The two endpoints for an SVC are known as the calling party and the called party. The calling party is the endpoint that originates the setup request for the SVC. Each SVC is bidirectional and is, in fact, two virtual channels (VCs)--a forward VC and backward (or return) VC. The forward VC carries data from the calling endpoint to the called endpoint; the calling endpoint transmits on this channel, the called endpoint receives on this channel. The backward VC carries data in the opposite direction, so the calling endpoint receives on this channel while the called endpoint transmits on it. Three topics related to SVC operation are discussed in more detail in the sections that follow:

ATM Signaling

ATM signaling is the protocol that sets up and tears down an SVC. This protocol's full name is ATM user-to-network interface (UNI) signaling. A calling endpoint uses ATM signaling to request a channel and to specify the traffic contract for the SVC. The setup request is sent to an adjacent node, which can be either an adjacent ATM switch (either public or private) or the called endpoint.^[9]If the recipient of the setup request is an ATM switch (the network side of the UNI interface), it uses one of the following switch-to-switch protocols to discover a route to the called party and to forward the message through the network to the destination: (1) the network node interface (NNI) protocol with dynamically maintained route information, or (2) the interim interswitch signaling protocol (IISP) with manually configured route lookup tables. (Usage of UNI and NNI protocols between different types of nodes is shown in Figure 1-14.) For some parameters of the traffic contract, the called endpoint can modify the contract by selecting among a list of possible values before the connection is completely set up. The traffic contract can be different for the forward and back channels of an SVC.

Figure 1-14. Use of UNI and NNI Protocols for ATM Signaling

The basic signaling messages used for managing SVCs are described in Table 1-4.

Table 1-4. Mandatory ATM UNI Signaling Messages

ATM signaling message	Who originates message	Who receives and processes message
SETUP: Requests that a bidirectional SVC be created and specifies the traffic contract. Some contract parameters allow the called party to select among a list.	Any node implementing a UNI. Sent on forward channel.	The adjacent node (switch or called endpoint). When the recipient is a switch, the request is forwarded to the next hop on the route to the called party, and can be converted into the NNI format. The final switch gives the SETUP message to the called party. Each recipient of this message allocates resources and sets up the SVC, if it can.
CALL PROCEEDING: Indicates that the SETUP message was received. This message is optional.	Each node that receives a SETUP message. Sent on back channel.	The adjacent node (switch or endpoint).
CONNECT: Indicates that the SVC has been set up completely between the two endpoints. This message contains any traffic parameters that were negotiated.	The called party after receiving a SETUP message and after setting up the SVC. Sent on back channel.	The adjacent node (switch or calling endpoint). When the recipient is a switch, the message is forwarded to the next hop along the route going back to the calling party and can be converted into the NNI format. The final switch gives the CONNECT message to the calling party.
CONNECT ACKNOWLEDGE: Indicates that the SVC is set up and functional in both directions.	The calling party after receiving the CONNECT message. Sent on forward channel.	The adjacent node (switch or called endpoint). When the recipient is a switch, the message is forwarded to the next hop on the route to the called party, and may be converted into the NNI format. The final switch gives the message to the called party.
RELEASE: Requests that the SVC be torn down.	Either endpoint of an SVC. For a calling party, sent on forward channel. For a called party, sent on back channel.	The adjacent node (switch or endpoint). When the recipient is a switch, the message is forwarded to the next hop on the route to the other endpoint, and can be converted into the NNI format. Upon receipt of this message, each node tears down its local resources for this SVC.
RELEASE COMPLETE: Indicates that the SVC has been torn down. As soon as this message is transmitted, all references to the SVC are erased.	Each node that received a RELEASE message. Sent on the opposite channel from the RELEASE message.	The adjacent node (switch or endpoint).
STATUS ENQUIRY: Requests status information about the SVC.	An endpoint or its adjacent switch. Sent on either channel.	The adjacent node (switch or endpoint).
STATUS: Indicates the status of the SVC at this node.	An endpoint or switch that received a STATUS ENQUIRY message. Sent on the opposite channel from the STATUS ENQUIRY message.	The node that generated the STATUS ENQUIRY message.

Four messages are involved in creating an SVC: SETUP, CALL PROCEEDING, CONNECT, and CONNECT ACKNOWLEDGEMENT. Figure 1-15, shows the order in which these messages are processed by the different nodes.

SETUP is the first message in the creation of an SVC. This message can be originated by either the source or the destination endpoint of a data transaction. As each switch along the path between the two endpoints receives the SETUP request, it may respond with a CALL PROCEEDING acknowledgment message, as shown in Figure 1-15. Each switch sets up its links for the SVC connection by allocating resources for a bidirectional connection at the specified traffic contracts. Once the resources are allocated, the switch forwards the SETUP request to the next node enroute to the other endpoint. When the SETUP request has been received and successfully processed by the called endpoint, the endpoint sends a CONNECT message, which is propagated along the return (backward) VC to the endpoint that originated the SETUP request. If a switch cannot set up the requested SVC, it does not forward the SETUP message and instead follows its CALL PROCEEDING message with a RELEASE message that causes all the links for that SVC to be torn down. If the called endpoint cannot match the requested traffic contract or does not want to accept the connection, it sends a RELEASE instead of a CONNECT message. Figure 1-16, shows the bidirectional SVC (two VCs) that is the result of a successful SETUP request.

---

Note: The term forward is always used to describe the channel that carries data from the calling party to the called party. The term backward always refers to the channel that carries data from the called party to the calling party.

---

Figure 1-15. ATM Signaling Messages for Creating an SVC

Figure 1-16. Result of a Successful SETUP Request for an SVC

When either endpoint wishes to terminate the connection, it generates a RELEASE message that causes each node along the connection to tear down the two VCs and pass the message on to the next node. As each node completes its tear down and frees its resources, it sends a RELEASE COMPLETE message to the adjacent node from which the RELEASE message came. Figure 1-17, shows the use of these messages for two cases: (A) the case in which the calling endpoint initiates the release, and (B) the case in which the called endpoint initiates the release.

Figure 1-17. ATM Signaling Messages for Tearing down an SVC

ATM UNI

For IRIS ATM, the ATM user-network interface (UNI) refers to the complete set of functionality that controls how an ATM endpoint (the user) interfaces with a switch (the network). Each ATM port requires one ATM UNI. The IRIS ATM signaling software (atmsigd) consists of a number of modules that run as an IRIX daemon and handle the various functions and protocols related to the UNIs on a system.

For every physical ATM port, the ATM standard requires one instance of an ATM UNI. For IRIS ATM, atmsigd performs this function. For each UNI, atmsigd creates a software stack made of the four following modules (shown in Figure 1-18). Each UNI has its own set of the lower three modules; all the UNIs within a system share a single instance of the overall control module.

• Overall control

• Signaling (Q.2931)

• Service specific convergence protocol (SSCOP, also known as QSAAL)

• ATM adaptation layer 5 (AAL5)

For each UNI, atmsigd creates a PVC to the switch using the following default address: VPI=0 and VCI=5. The signaling module, as shown in Figure 1-18, uses this PVC for its own communications with the switch (for example, setup and teardown requests for SVCs). The VPI/VCI address of this PVC is configurable. Overall, the traffic on this PVC is sporadic and takes up only a small portion of any port's bandwidth; however, the higher the PVC's configured rate, the larger the percentage of the port's total bandwidth that can be occupied by this overhead at a specific point in time (that is, when there is UNI signaling occurring).

ATM network administration and management is based on the existence of an ATM management information base (MIB) that is managed by ILMI software via a PVC to the switch. For each UNI, there is one MIB and one ILMI PVC.

Figure 1-18. The IRIS ATM Signaling and ILMI Daemons

ATM ILMI

The ATM standard specifies an interim local management interface (ILMI) to handle address registration and assignment, and status reporting (shown in Figure 1-18, and Figure 1-19). To exchange status information, ILMI implementations use the simple network management protocol (SNMP, RFC 1157). ILMI implementations store some of the information they collect in management information databases (MIBs) that users can view. There is one MIB for each UNI (that is, each physical connection). The ATM MIBs contain objects and tables that are specified by the ATM User-Network Interface Specification standard. The module in IRIS ATM that performs these duties is atmilmid. Like snmpd, atmilmid is an administrative process (IRIX daemon) that acts as an SNMP agent, managing MIBs and exchanging information with other ILMI agents. The atmilmid also functions as a subagent to the main SNMP agent (snmpd) so that the ATM MIBs can be viewed with standard SNMP MIB browsers.

The atmilmid daemon responds to requests from other ILMI modules (for example, those that reside on adjacent switches) as well as requests from the local main SNMP agent, as shown in Figure 1-19. To communicate with the local SNMP agent, atmilmid listens on a user datagram protocol (UDP) socket. To communicate with each adjacent ILMI agent, the atmilmid uses a permanent virtual circuit (PVC) on each port with the following default address: VPI=0 and VCI=16. (The VPI/VCI address for the PVC and the socket address are both configurable.) Overall, the traffic on this PVC is sporadic and takes up only a small portion of any port's bandwidth; however, the higher the PVC's configured rate, the larger the percentage of the port's total bandwidth that can be occupied by this overhead at a specific point in time (that is, when there is ILMI overhead communication occurring).

During startup, atmilmid opens a PVC to each adjacent switch and contacts each ILMI agent, as shown in Figure 1-19. From each ILMI agent, atmilmid obtains the switch-assigned portion for its ATM address and it registers its locally assigned portion (MAC address). If the ILMI agent on the switch is not available, atmilmid completes this task as soon as that agent comes online. If the request times out, atmilmid looks for a locally configured ATM address. If no ATM address is available, atmilmid uses a null address.

Figure 1-19. Relationship of ILMI Module to UNIs

After this initialization procedure, the atmilmid daemon uses its PVC during normal operation to exchange status information with adjacent ILMI agents. The atmilmid daemon maintains (in memory) one MIB for each UNI. Each UNI MIB contains the adjacent switch's table of supported network prefixes and UNI status objects, as specified by the ATM Forum standards. You can view the ATM MIBs by using any application developed for viewing SNMP MIBs (for example, the IRIXpro Browser\xb9).

In IP networks, it is common to think of each host (that is, each system on a network) as identified by two unique addresses: a logical IP address and a hardware MAC (or Ethernet) address. This view is, however, inaccurate. It is more accurate to think of the MAC hardware address as identifying only the physical connection to the network and the IP address as identifying one upper-layer software endpoint (for example, a logical IP network interface, such as et0 or atm0). When described this way, it is conceivable to have multiple upper-layer endpoints in a system, all sharing the same physical connection. And this is exactly what ATM makes possible: numerous IP interfaces all sharing one ATM port. The following paragraphs describe exactly how this is done.

In ATM switched virtual circuit environments, each upper-layer endpoint is identified by an ATM address, as described in “ATM Addresses”. In concept, an ATM address is a network layer address, not a hardware address. However, in many ATM implementations (including IRIS ATM), an ATM address is partially a hardware address because it includes the hardware address (MAC address) of the ATM port. All of the fields of the ATM NSAP except the end system selector (SEL) field constitute the ATM port's address; the entire ATM NSAP, including the SEL field, is the endpoint's address. The SEL field is used to distinguish between the upper-layer endpoints that share that port.

To do IP-over-SVCs, it is necessary to map between IP and ATM addresses. RFC 1577 specifies a method for doing this. The method uses the ATM address in place of the standard Ethernet or MAC hardware address, and describes a protocol, ATMARP, for registering and discovering the mappings, and for maintaining the IP-to-ATM address resolution table. The RFC 1577 design is shown in Figure 1-20. The ATMARP protocol uses standard IP address resolution protocol (ARP) (RFC 826) to discover ATM addresses when only the IP address is known, and inverse IP ARP (RFC 1293) to discover IP addresses when only the ATM address is known.

Figure 1-20. ATM Address Resolution Events

In the RFC 1577 design, all IP hosts that use the same network address and subnet mask (that is, the same subnet address) are considered members of a single logical IP subnetwork (LIS). Each LIS can be thought of as logically similar to an Ethernet local area network, even though the members of the LIS do not have any special physical relationship to each other and can even be separated by multiple ATM switches. Each LIS member must be known to other members of that LIS by a single ATM address. For IRIS ATM, this rule means that all traffic between an IRIS ATM endpoint and other members of a specific LIS must travel over the same physical port, as shown in Figure 1-21. To contact an IP host that is not a member of the same LIS, a router must be used, even when it is physically possible for the IP host to be contacted directly through the ATM switch, as illustrated by network 255.100.8, which is shown in Figure 1-21.

Within each LIS, one (and only one) host acts as the address resolution server and maintains the IP-to-ATM address resolution table. Upon request, this server provides the ATM address for any other member of that LIS. Each LIS member (IP endpoint) registers its IP address and ATM address with the ATMARP server. When the ATM address is in the ATM NSAP format, a different ATM address can be registered for each of the local IP addresses.^[12]This is accomplished by using the SEL field (which is not interpreted by ATM switches) to distinguish among the IP upper-layer endpoints. For example, the ATM address for atm2 using port 0 might consist of the ATM address for port 0 (network prefix and MAC address) plus the 8-bit SEL field set to 00000010 binary (which is 2 in decimal format).

Figure 1-21. Multiple IP Interfaces Using Each ATM Physical Port with SVCs

Because the logical network interfaces are upper-layer, nonphysical entities and the ATM port can simultaneously handle multiple communication channels, a single physical ATM port can service more than one logical network interface, as shown in Figure 1-21. (Each logical network interface identifies one member of an LIS.) In this figure, port 1 (board unit 1) services both atm1 (a member of LIS 255.100.3) and atm2 (a member of LIS 255.100.4). IRIS ATM can simultaneously support up to 64 logical network interfaces. These can all share a single physical port, or they can be distributed among a number of ports. During the SVC configuration process, the network administrator assigns each logical network interface to one (and only one) port. Figure 1-21, illustrates a system with three logical network interfaces (each one is a member of a different LIS) and two ATM physical ports.

The IRIS ATM subsystem handles IP-over-SVC address resolution with the following mechanisms:

In environments requiring IP-over-PVCs in compliance with RFC 1577 (using or not using LLC/SNAP encapsulation and ATMARP), IRIS ATM can interoperate (that is, participate in each LIS) with or without ATM addresses and with or without ILMI.

IRIS ATM allows IP to operate over PVCs in configurations that do not comply with RFC 1577 guidelines. This type of configuration functions exactly like the conformant IP-over-PVC configurations; however, the address resolution and PVC management daemon, atmarp, cannot be used because it enforces RFC 1577 rules. The following scenarios (shown in Figure 1-23,) are examples of nonconformant configurations:

This section describes the manner in which the IRIX operating system assigns an IP network interface (for example, atm0 and IP address 223.9.1.2) to a particular ATM port.

% /sbin/hinv -d atm
ATM-OC3c: atm0, slot 5 adap 6, firmware version ####
ATM-OC3c: atm1, slot 3 adap 5, firmware version ####

On Origin and Onyx2 Platforms

On an Origin2000, OriginServer, or Onyx2 system, with each restart (for example, after a reboot, shutdown, halt, init command, or a power off), the startup routine probes for hardware on all the systems connected into the Craylink interconnection fabric. All the slots and links in all the modules within the fabric are probed. The routine then creates a hierarchical file system, called the hardware graph, that lists all the hardware that is located. The top of the hardware graph is visible at /hw. (For complete details, see the man page for hwgraph.) After the hardware graph is completed, the ioconfig program assigns a unit number to each located device that needs one. Other programs (for example, hinv and the device's driver) read the assigned number and use it. On an initial startup, ioconfig assigns numbers sequentially; for example, if two IRIS ATM XIO boards are found, they are numbered unit0 (with ports 0 to 3) and unit1 (with ports 4 to 7). The port numbers for each IRIS ATM XIO board are created from the board's assigned unit number: first_port#=brd_unit# * 4 and the other three are sequential from the first. On subsequent startups, ioconfig distinguishes between hardware that it has seen before and new items. To previously seen items, it assigns the same unit and port numbers that were assigned on the initial startup. To new hardware, it assigns new sequential numbers. It never reassigns a number, even if the device that had the number is removed and leaves a gap in the numbering.

---

Note: New items are differentiated from previously seen items based solely on the hardware graph listing (that is, the path within /hw). The database of previously seen devices is kept in the file /etc/ioconfig.conf. For example, a replacement board that is installed into the location of an old board will be assigned the old board's numbers, while a board that is moved from one location to another will be assigned a new unit number and new port numbers. For more information about the hardware graph and ioconfig, see the man pages for hwgraph and ioconfig.

---

The IRIS ATM boards that are located can be displayed with the /sbin/hinv or find commands, as shown in the following examples. In these examples, the startup routine located two IRIS ATM boards on two different modules (that is, inside two different chassis).

% find /hw/module -name atm /hw/module/1/slot/io3/quad_atm/pci/0/atm /hw/module/2/slot/io12/quad_atm/pci/0/atm<

% /sbin/hinv -d atm ATM XIO 4 port OC-3c: module 1, slot io3, unit 0 (ports: 0-3) ATM XIO 4 port OC-3c: module 2, slot io12, unit 1(ports: 4-7)

As the startup process continues, it calls the network hardware drivers so that they can create their network and programmatic interfaces. For ATM, this step works in the following manner:

• For each IRIS ATM port, the startup process creates short (/hw/atm/#) and long (/hw/module/#/slot/.../atm.) entries in the hardware graph. Then, the installation scripts create a symbolic link in /dev that points to the port's entry in the hardware graph. The /dev/atm# links are for use by the IRIS ATM application programming interface (API).

• If the IRIS ATM driver is configured to support the IP protocol stack, the driver creates the number of IP-over-ATM network interfaces specified in the/var/sysgen/master.d/if_atm file.

• The /etc/init.d/atm script uses the contents of the /var/atm/ifatm.conf file to associate each IP-over-ATM network interface with a port.

• The ifconfig command searches the netif.options file for IP-over-ATM interface names (for example, atm0, atm1, atm2) and configures and enables each interface that exists (that is, each interface that was created by the driver).

The following sections describe how transmission rates are created and managed by different IRIS ATM hardware products.

Rates on the ATM-OC3c HIO Board for CHALLENGE and Onyx Platforms

The IRIS ATM-OC3c HIO board for CHALLENGE and Onyx platforms manages transmission rates with rate queues and divisors. The board has 8 rate queues organized as 2 banks: a0-a3 and b0-b3. Each queue can support one peak rate and 63 different sustainable rates. The “a” bank consists of 4 high-priority queues that are designed for constant bit rate traffic (CBR and VBR channels). The other bank contains 4 low-priority queues and are only used for best-effort traffic.

High-priority queues are serviced before low-priority ones. As long as there is data awaiting transfer on any high-priority queue, low-priority data is not transmitted. This means that, for applications with a constant flow of data, only queues a0-a3 will ever operate.

During startup, the IRIS ATM HIO board driver configures each rate queue, as follows:

• Queues that are mentioned in the /var/atm/atmhw.conf file are configured to a fixed rate, as specified in the file. The IRIS ATM driver never changes the rates for these queues; this ensures that site-specified rates are always available, even when the queues are not actively being used. Appendix B, “Supported Transmission Rates for IRIS ATM Board on CHALLENGE and Onyx Platforms”, lists the supported rates, which range from 0 to 135,991,460 bits-per-second.

• Queues that are not mentioned (or are commented out) in the file are left unconfigured. The driver configures these during operation, as follows.

During operation, as VCs are created, the driver associates each newly created VC with the queue whose transmission rate best matches the peak rate requested for that VC. For each ATMIOC_CREATEPVC or ATMIOC_SETUP command, the driver looks for a queue whose transmission rate best matches the rate requested in the API call, following these guidelines:

• For VCs carrying best-effort traffic, the driver uses the low-priority queue whose rate is closest to, but slower than, the requested peak rate.

• For VCs carrying CBR and VBR traffic, the driver uses the high-priority queue whose configured rate exactly matches the requested peak rate. If the requested rate does not exist, the driver searches for a high-priority queue with the following characteristics and reconfigures it to the requested peak rate:

  • A queue that does not currently have a VC associated with it

  • A queue that was not configured from the atmhw.conf file during startup

  ---

  Note: There can be dozens of CBR and VBR virtual channels active on a board, but the peak rate for each one must be one of the four rates that are configured on the high-priority queues.

  ---

  
  

To set the sustainable transmission rate for a particular VC, one of the board's configured rates is divided by a divisor (ranging between 1 and 64). The IRIS ATM driver sets all divisors. Peak rates for CBR, VBR, or best-effort traffic use divisors of 1. Sustainable (average) rates for VBR traffic use divisors between 2 and 64 (inclusive).

---

Note: The IRIS ATM-OC3c board for CHALLENGE and Onyx platforms implements sustainable (average) rates by filling some cell slots with idle cells instead of data. This results in some loss of bandwidth which, under heavy load conditions, can be noticeable.

---

To summarize, the IRIS ATM-OC3c board simultaneously makes available for selection up to 8 different peak rates and up to 504 (8*63) sustainable rates. Not all of these available selections can be actively used simultaneously, since this would exceed the board's bandwidth.

Table 1-5, summarizes the default settings configured for the IRIS ATM-OC3c board's rates.

Table 1-5. Default Transmission Rates on ATM-OC3c Queues

Rate queue Number ID	String ID	Default cell rate (in ATM cells per second)	Default bit rate (in user payload bits per second)	Priority / Use
0	a0	unconfigured	0	High / CBR, VBR[a]
1	a1	unconfigured	0	High / CBR, VBR
2	a2	unconfigured	0	High / CBR, VBR
3	a3	unconfigured	0	High / CBR, VBR
4	b0	26,041	10,000,000	Low / BE
5	b1	78,125	30,000,000	Low / BE
6	b2	178,571	68,000,000	Low / BE
7	b3	357,142	135,991,460	Low / BE
[a] CBR = constant bit rate; VBR = variable bit rate; BE = best effort

A board is oversubscribed when the sum of all the open VCs multiplied by their average rates is greater than the board's total payload bandwidth.^[14]The IRIS ATM software contains a number of features that prevent performance degradation due to oversubscription.^[15]Whenever there is even one VC open for a CBR traffic contract, the IRIS ATM software refuses to create new VCs once the board's total bandwidth is allocated to open VCs (including the best-effort ones). If all the VCs on a board are best-effort (regardless of which queues they are using), the IRIS ATM software allows the board to become oversubscribed and handles the transmissions in the best manner possible.

---

Note: With this board, the default TCP/IP configuration uses the maximum bandwidth possible. Therefore, a single TCP/IP connection can oversubscribe the port it uses and prevent CBR traffic. To prevent this, there are two options: (1) reduce the default TCP/IP bandwidth (for example, by editing the /var/atm/ifatm.conf file) or (2) use ifconfig to disable the TCP/IP logical network interfaces.

---

Figure 1-24. Transmission Rate Control on ATM-OC3c Board for CHALLENGE and Onyx Platforms

Rates on the ATM-OC3c XIO Board for Origin2000 and Onyx2 Platforms

The IRIS ATM-OC3c 4Port XIO board for Origin2000 and Onyx2 platforms handles transmission rates with a table that is managed by firmware. Each table entry represents one ATM cell slot on the output stream, as shown in Figure 1-25. For each VC, the board's firmware calculates how many table entries are needed to generate the VC's rate, then associates that number of table entries with the VC's data stream, as shown in Figure 1-25. The cell feeder logic sequentially moves through the table, entry by entry. Each entry triggers a 48-byte read (384 bits) from one data stream. An ATM cell is created and placed on the stream of data that is on its way to the SONET logic. If there is no VC associated with a table entry, the cell feeder creates an idle cell to fill that cell slot in the stream. As shown in Figure 1-25, a VC is associated with multiple, evenly spaced table entries in order to transmit the VC's data steadily at its transmission rate. For this board, a VC's sustainable rate is exactly the same as its peak rate.

Theoretically, for a table with 353,207 entries, each entry would be processed once every second, while the entries in a table with half that number of entries would be processed twice every second. To understand why this is true, see the following calculation and facts:

• The OC3c SONET line rate is 155, 520,000 bits per second of which approximately 87.2% (135,631,698 bits) is upper-layer payload, and the rest is SONET and ATM overhead.

• The upper-level data in each ATM cell (and hence, each entry in the table) places 384 bits onto the transmission medium.

• When the total number of upper-layer bits transmitted every second is divided by the upper-layer bits in each cell, the result is the number of ATM cells per second. This is the number of table entries that are processed once every second: 135,631,698 bits transmitted per second / 384 bits per cell= 353,207 cells per second.

  Or expressed another way, the (number of table entries) multiplied by (number of times each table entry is processed every second) multiplied by (upper-layer bits in each cell) equals the total number of upper-layer bits transmitted in a second: (353,207 * 1) * 384 = 135,631,408 maximum bits per second of payload (176,603 * 2) * 384 = 135,631,108 maximum bits per second of payload.

A more realistic example for this product's hardware implementation (in which the maximum number of table entries is limited) is the following example:

(7,064 entries * 50 table passes) * 384 bits per cell = 135,628,808 payload bits per second

Figure 1-25. Transmission Rate Control on ATM-OC3c XIO Board for Origin2000 and Onyx2 Platforms

The driver for the IRIS ATM-OC3c 4Port XIO board does not allow oversubscription of any port. Whenever a requested rate cannot be provided, the request is denied. A denial can be due to either of these reasons:

• Not enough table entries are free to create the requested transmission rate. Said another way, the request is denied when filling it would oversubscribe the line rate.

• The spacing possible with the currently available table entries is not even enough to create a steady data flow for the VC. For example, if the table entries for a requested rate need to be spaced at intervals of 50 (table entries 8, 58, 108, 158, and so on, or table entries 3, 53, 103, 153, and so on), the request is denied when one or more of the needed table entries are already filled. This denial can occur even though the requested rate does not oversubscribe the connection's line rate.

IRIS ATM supports the following upper layer applications: