Layer 3 Protocols over ATM

Background

Classical IP and Multiprotocol Encapsulation Over ATM

RFC 1577 Provisions

The ATMARP Mechanism

The InATMARP Mechanism

RFC 1483 Provisions

Static Map Lists

Common Implementations

SVCCs with ATMARP

PVCCs with InATMARP

PVCCs with Static Address Mapping

SVCCs with Static Address Mapping

Scenarios for Inband Management

Configuration Overviews

Layer 3 Protocols over ATM

One of the most common uses of ATM switches is in the backbone of a campus or enterprise network, or in the core of a WAN. In such applications, native mode network-layer traffic and LAN traffic must be carried across the ATM network. This chapter presents common scenarios and discusses two of the protocols that provide solutions for these problems.

This chapter contains the following sections:

Note The information in this chapter is applicable to the Catalyst 8540 MSR, Catalyst 8510 MSR, and LightStream 1010 ATM switch routers. For detailed configuration information, refer to the ATM Switch Router Software Configuration Guide and the ATM Switch Router Command Reference publication.

Background

As a campus backbone or core of a WAN, ATM provides reliable transport, efficiency of bandwidth utilization, and QoS. In a typical scenario, end stations connected to the ATM network via a router and sending network layer packets, such as IP, want to take advantage of ATM's benefits while communicating with end stations behind the other router across the ATM cloud (Figure 5-1).

Figure 5-1: Traffic Across the ATM Cloud

In a typical backbone implementation of ATM, the ATM network must carry traffic that is connectionless and in a network layer protocol format, such as IP. IP data, for example, is formatted in packets, not cells; IP is typically carried over a broadcast medium such as Ethernet or Token Ring and uses IP rather than ATM addresses. The requirements for transport of IP, or other Layer 3 protocols, are therefore fundamentally different from ATM.

Two main problems must be solved in carrying network layer protocol traffic across the ATM network (see Figure 5-2):

Packet encapsulation---how the network layer protocol packets are packaged into ATM cells
Address resolution---how an ATM network device finds the location of an IP address and connects to it

Figure 5-2: Native Mode versus LAN Emulation

Broadly speaking, there are three approaches available to solve the challenges that packet encapsulation and address resolution pose:

Native mode operation---approaches that are based on protocols that define IP connectivity over ATM using an address resolution mechanism, and encapsulation of Layer 3 protocols in ATM cells. The protocols and resultant approaches are described in the "Classical IP and Multiprotocol Encapsulation Over ATM" section.
LANE---a MAC-layer protocol used to provide transparent LAN services across the ATM network. An enhancement of LANE, Multiprotocol over ATM (MPOA) uses LANE technology with cut-through routing to improve performance in large networks. For descriptions of these protocols, see "LAN Emulation and MPOA."
Tag switching---a technology that combines the benefits of routing with the performance of switching to offer another solution to forwarding IP packets over an ATM network. See
"Tag Switching."

Classical IP and Multiprotocol Encapsulation Over ATM

Several protocols have been designed to provide complementary mechanisms and formats that address the issues of address resolution and encapsulation. Two protocols in particular provide the basis for native mode transport of IP and other network layer protocols over ATM:

"Classical IP and ARP over ATM" (RFC 1577)---defines an application of classical IP in an ATM network environment using switched virtual channel connections (SVCCs) and permanent virtual channel connections (PVCCs) and specifies mechanisms for address resolution and discovery.
"Multiprotocol Encapsulation over ATM Adaptation Layer 5" (RFC 1483)---defines how various types of PDUs are encapsulated for transport over ATM.

RFC 1577 Provisions

In the RFC 1577 model, ATM becomes a direct replacement for the interconnection of local LAN segments that contain IP end stations and routers operating in the classical LAN-based paradigm. Such LAN segments, called logical IP subnets (LISs), are identical in all "protocol" aspects to conventional LAN media subnets. ATM-attached systems in the same LIS have the same network numbers and subnet masks, just as on an Ethernet or other conventional media. Two ATM-attached systems not in the same LIS can communicate only through a router---hence the term "classical" IP---even though they are both attached to the same ATM physical network. RFC 1577 also specifies address resolution and discovery mechanisms. These are the ATM Address Resolution Protocol (ATMARP) and Inverse ATM Address Resolution Protocol (InATMARP).

The ATMARP Mechanism

In traditional LANs the function of finding a MAC layer address is performed by the ARP mechanism, which identifies the MAC address corresponding to an IP or other network layer address, and by the broadcast mechanism, which sends a single packet over the LAN that is seen by every device on the segment. This is not possible in ATM, since no such thing as a broadcast address exists. Additionally, ATM is point-to-point, so the only way to broadcast a single frame is to send copies of the same frame over every point-to-point link, addressed to the unique ATM address of that device.

RFC 1577 specifies that address resolution be accomplished by the ATMARP server, a centralized server that maintains a table of IP addresses to ATM addresses. The ARP server maintains this table for a single IP subnet, and any client that needs to communicate with another client can query the ARP server to get that device's ATM address and directly set up a connection to it.

How It Works

Figure 5-3 contains three ATMARP clients and one ATMARP server. When coming online, the ARP clients register their IP and ATM addresses with the ARP server.

Figure 5-3: Classical IP-Over-ATM Example

The following steps describe the process whereby a classical IP-over-ATM connection is set up between ATM switch router client A and client B:

Step 1 The initial IP packet sent by client A triggers a request to the ARP server to look up the IP address and the corresponding ATM address of client B in the ARP table.

For each packet with an unknown IP address, the client sends an ATMARP request to the ARP server. Until that address is resolved, any IP packet routed to the ATM interface causes the client to send another ATMARP request.

Step 2 The ARP server sends back a response to client A with the matching ATM address.

Step 3 Client A uses the ATM address it just obtained from the ARP server to set up an SVCC directly to client B.

Step 4 When client B replies with an IP packet to client A, it also triggers a query to the ARP server.

When client B receives the ATM address for client A, it usually discovers it already has a call set up to client A's ATM address and does not set up another call.

Step 5 Once the connection is known to both clients, they communicate directly over the SVCC.

In Cisco's implementation, the ATMARP client tries to maintain a connection to the ATMARP server. The ATMARP server can tear down the connection, but the client attempts once each minute to bring the connection back up. No error message is generated for a failed connection, but the client will not route packets until the ATMARP server is connected and translates IP network addresses.

The ATM switch router can be configured as an ATMARP client to work with any ATMARP server conforming to RFC 1577. Alternatively, one of the ATM switch routers in an LIS can be configured to act as the ATMARP server itself. In that case, it automatically acts as a client as well.

Note When possible, we recommend placing the ATMARP server on a router rather than a switch.

Note The ATM router module does not support RFC 1577.

The InATMARP Mechanism

With InATMARP there is no server function; rather, clients exchange information and discover one another's protocol address. To discover the protocol address of the remote end of a connection, a client sends an InATMARP request over a virtual connection for the address of the other end; this is how a client knows what addresses it can reach. This mechanism provides an alternative to statically mapping ATM and IP addressees in the configuration.

RFC 1483 Provisions

As its name implies, multiprotocol encapsulation over ATM, defined in RFC 1483, provides mechanisms for carrying traffic other than just IP. RFC 1483 specifies two ways to do this:

Logical Link Control (LLC)/Subnetwork Access Protocol (SNAP) encapsulation---in this method, multiple protocol types can be carried across a single connection with the type of encapsulated packet identified by a standard LLC/SNAP header.
Virtual connection multiplexing---in this method, only a single protocol is carried across an ATM connection, with the type of protocol implicitly identified at connection setup.

LLC encapsulation is provided to support routed and bridged protocols. In this encapsulation format, PDUs from multiple protocols can be carried over the same virtual connection. The type of protocol is indicated in the packet's SNAP header. By contrast, the virtual connection multiplexing method allows for transport of just one protocol per virtual connection.

Static Map Lists

Static map lists belong to neither RFC 1483 nor RFC 1577 specifications. Rather this is a Cisco IOS feature that offers an alternative to using the ATMARP or InATMARP mechanisms. With static maps lists, you can associate, among other things, a protocol address with an ATM address or with a VCI/VPI.

Figure 5-4 illustrates the use of static address mapping to set up a connection between switch A and switch B.

Figure 5-4: Multiprotocol Encapsulation over ATM Example

The following steps occur when a connection between switch A and switch B needs to be set up to forward an IP packet:

Step 1 An IP packet with destination 123.233.45.3 arrives at switch A.

Step 2 Switch A finds the destination IP address in its map list.

Step 3 Using a statically configured map list, switch A identifies the ATM address corresponding to the next-hop IP address (for SVCCs) or the VPI/VCI value corresponding to the next-hop IP address (for PVCCs).

Step 4 If SVCCs are used, signaling sets up a virtual connection to the destination ATM address. If PVCCs are used, the connection follows the statically configured path of the virtual connection.

Step 5 The encapsulated packet is forwarded over the ATM virtual connection.

Note Static map lists are not supported on the ATM router module.

Common Implementations

The solutions found in RFC 1483, RFC 1577, and Cisco's static map list feature, can be combined in various ways. Four of the most common of these, along with their advantages and limitations, are described in this section.

SVCCs with ATMARP

The essential ingredients of this implementation are encapsulation of native protocol IP datagrams over ATM (in RFC 1483 routed IP format) and use of the RFC 1577 ATMARP mechanism to map IP addresses to ATM addresses (see the "The ATMARP Mechanism" section).

Advantages

Potential advantages of SVCCs with ATMARP include the following:

Many vendors support the ATMARP function, making it is widely interoperable.
For interconnecting IP subnets, it is less complex than LANE.
Configuration in a small network is simple.
A Cisco proprietary mechanism allows configuration of multiple ATMARP servers on the ATMARP clients, eliminating the liability of a single ATMARP server failure.

Limitations

Potential limitations of SVCCs with ATMARP include the following:

No multicast capability is provided.
Only the IP network protocol is supported.
This implementation cannot take advantage of the router's traffic shaping capability; therefore, this implementation might not be a good choice for sending traffic through a public network.
Because address resolution is limited to a single hop and inter-LIS traffic must traverse a router, multiple hops are required for communication between different LISs. This can increase the load on the network resources, particularly as it results in repeated SARs.
The ATMARP server is a single point of failure in the network.
In a large network, configuring each host with its ATMARP server address can be tedious and can result in configuration errors.

PVCCs with InATMARP

In this implementation, static routes are configured between network devices (switches and routers) using PVCCs. The network protocol address of the remote end of a connection is not configured, but is discovered by the Inverse ATMARP (InATMARP) process. IP packets are encapsulated in SNAP, per RFC 1483.

Advantages

Potential advantages of PVCCs with InATMARP include the following:

Many vendors support the InATMARP functions, making it widely interoperable.
For interconnecting IP subnets, it is less complex than LANE.

Limitations

Potential limitations of PVCCs with InATMARP include the following:

No multicast capability is provided.
Only the IP network layer protocol is supported.
This implementation cannot take advantage of the router's traffic shaping capability; therefore, this implementation might not be a good choice for sending traffic through a public network.
Because address resolution is limited to a single hop and inter-LIS traffic must traverse a router, multiple hops are required for communication between different LISs. This can increase the load on the network resources, particularly as it results in repeated SARs.
Because PVCCs are manually configured, the complexity of configuration and the possibility of error increase with the number of devices you have to configure.

PVCCs with Static Address Mapping

In this implementation PVCCs are configured between switches (or between switches and routers in a routed subnet design). Using statically configured map lists, each PVCC is mapped to a destination protocol address; packets are routed based on the mappings in the map list.

Advantages

Potential advantages of PVCCs with static mapping include the following:

This implementation can support different Layer 3 protocols.
Configuration is simple for a few nodes.
Encapsulations is supported by many vendors.

Limitations

Potential limitations of this implementation include the following:

Scalability is a problem, because the number of PVCCs to configure grows exponentially with the addition of nodes.
It is strongly recommended not to use OSPF as routing protocol if the network is a meshed one that requires multicasting.
With PVCCs, there is no dynamic reaction to ATM failures; a possible workaround is to use soft PVCCs.
Bridged and routed 1483 cannot exist on the same PVCC, unless you enable Integrated Routing and Bridging (IRB) on the router.

SVCCs with Static Address Mapping

In this implementation SVCCs are set up as needed based on the information in the statically configured map list. That list contains mappings of protocol addresses to ATM addresses. To set up a connection to a destination protocol address, the ATM switch router locates the ATM address that corresponds to the protocol address in the map list, then sets up an SVCC to that ATM address.

Advantages

Potential advantages of SVCCs with static mapping include the following:

The implementation can support different Layer 3 protocols.
Encapsulation is supported by many vendors.
Multicasting and broadcasting are supported on static map subinterfaces that are of type multipoint. Multipoint routing in the form of PIM is also supported in this environment.

Limitations

Potential limitations of SVCCs with static mapping include the following:

It is strongly recommended not to use OSPF as a routing protocol if the network is a meshed one that requires multicasting.
The signaling complexity inherent in using SVCCs can be a troubleshooting liability.

In the WAN, this implementation might have the following additional limitations:

There can be problems with signaling of SVCCs when connecting to a service provider's address space. A possible alternative is to use SVCCs inside a VP tunnel.
There is no point-to-multipoint support.

Scenarios for Inband Management

The implementations described above provide one set of solutions to the need posed in Figure 5-1. In this scenario, in which routed subnets are interconnected over ATM, the role of the ATM switch router is essentially a passive one. Encapsulation and address resolution take place on the routers, and the switches function only to forward ATM cells through the network on SVCCs or PVCCs.

In a primarily Layer 2 ATM switch environment, however, these solutions can be used for inband management of the ATM switch router. When the ATM switch router is managed with out-of-band connections, a separate Ethernet connection is required for each device. For example, if you have multiple switches to manage through SNMP, you would have connections to the Ethernet port on the CPU of each of the switches. By using an implementation from RFC 1577 and RFC 1483, you can connect to just one of those ports and get management information from all the others using interswitch SVCCs or PVCCs (see Figure 5-5). In this scenario, you are accessing management information through an inband (ATM) connection rather than by out-of-band (Ethernet) connection.

Figure 5-5: Inband Network Management

Some risk occurs in using the ATM network itself to provide network management connectivity. However, this liability can be mitigated if you have redundant links and multiple paths. For this reason, implementations with SVCCs might be preferable.

Configuration Overviews

The configuration overviews in this section describe ways you can use solutions discussed in the "Common Implementations" section for inband management of the ATM switch router.

SVCCs with ATMARP

The following steps describe configuring the ATM switch router as an ARP client, such as switch client A in Figure 5-5:

Step 1 Enable IP host-based routing on the ATM switch router.

This enables the switch to perform basic routing functions.

Step 2 Configure an ATM address on the processor's ATM interface.

Step 3 Configure an IP address on the processor's ATM interface.

Step 4 Specify the ATM address of the ARP server.

Step 5 Configure a static route through the ATM switch router to the processor interface.

This step is required only when configuring the ARP client using an NSAP form address; ESI format addresses do not require this step.

The following steps describe configuring the ATM switch router as an ARP server, such as switch B in Figure 5-5:

Step 1 Enable IP host based routing on the ATM switch router.

This enables the switch to perform basic routing functions.

Step 2 Configure an ATM address on the processor's ATM interface.

Step 3 Configure an IP address on the processor's ATM interface.

Step 4 Enable the ARP server on this device.

Step 5 Configure a static route through the ATM switch router to the processor interface.

This step is required only when configuring the ARP server using an NSAP format address; ESI format addresses do not require this step.

It might be useful to keep the following additional points in mind when setting up SVCCs with ATMARP:

The size of the MTU must be the same for all nodes in the LIS. This parameter is negotiated, but there could be a mismatch when connecting with non-Cisco equipment, such as a UNIX workstation with an ATM NIC that supports the RFC 1577 protocol.
All members of an LIS must be in the same IP network/subnet and have the same address mask.
All members outside the LIS have to go through the router
There must be one ARP server per LIS.

PVCCs with InATMARP

The following steps are required to configure PVCCs with InATMARP for inband management such as that in Figure 5-5:

Step 1 Enable IP host-based routing on the ATM switch router.

This enables the switch to perform basic routing functions.

Step 2 Configure an IP address on the processor's ATM interface.

Step 3 Create a PVCC to the remote end.

Step 4 Enable InATMARP and SNAP encapsulation on the interface.

It might be useful to keep the following additional points in mind when setting up PVCCs with InATMARP:

The size of the MTU must be the same for all nodes in the LIS. Like the UNI version, this parameter is negotiated, but could fail when using non-Cisco equipment.
All members of an LIS must be in the same IP subnet and must have the same address mask.
All members outside the LIS have to go through a router.