There will be no Cisco configuration commands this month, since MPOA is not yet visible in the Cisco documentation.
LANE is just basic virtual LAN's, VLAN's, for ATM. LANE provides logical bridging over an ATM backbone (or in an ATM workgroup). Ethernet or Fast Ethernet switches with ATM uplink generally can be configured to do LANE, connecting the VLAN's on one switch to those on another across the ATM backbone.
Just as with VLAN's, you need a router to get from one emulated LAN or ELAN to another. Up until recently, folks sometimes did this with a single ATM-attached router, sometimes called "router on a stick". In the picture below, the router routes between the red and green VLAN's (which might be different IP subnets, or different IPX networks, etc.). They probably extend to more than one edge device (Ethernet and ATM switch), but the router is necessary even to go between red and green VLAN's on the same edge device.
I'm simplifying a bit here, so we can focus on MPOA. The real world can be a bit messier. If you have a RSM in a Cat5000, your edge device is a router. If you have the announced NetFlow blade in a Cat5000, then the router on a stick can download flow information to the blade and (after the first packet) the switch blade acts like it is routing between the local VLAN's. But those are just variants of the hardware, and the idea remains the same.
Back to MPOA. Recall that every ATM edge device, including the router on a stick, has to do segmentation and re-assembly, SAR. LANE allows bridged traffic from Edge Device A to go directly to Edge Device B. But in large networks, broadcast overhead and other factors limit the scale of the bridged network. So generally people would like to use routers to break up large bridging domains, at least for routable protocols like IP. But if IP is routed, then packets from A to B have to be reassembled at the router, causing extra latency and possibly reduced throughput. That seems like a rather steep price to have to pay. It perhaps creates an incentive to push scaling limits, which is never a good thing.
MPOA is the answer to this. It allows "cut-through" routing, whereby routed packets can be sent (as cells) across an ATM SVC directly from A to B, just as the bridged packets are sent. And it does this while being compatible with the bridging behavior of LANE.
Some vendors describe this in terms of the router being a "route server". You can think of the "cut-through" routing as making the ATM cloud the backplane of a distributed router, with route cache in the route server (router on a stick), and edge devices providing the interfaces for this distributed router.
For the switches to be able to do cut-through routing, they have to be able to send packets as cells directly across an ATM SVC. As we saw last month, NHRP is focussed on tasks such as letting MPC-A in the picture find the ATM address of MPC-D, so they can establish a direct SVC. MPOA lifts us from bridging/switching at Layer 2 of the OSI model, to routing at Layer 3. What else does that router on a stick do? Or if we route via two routers, MPS-B and MPS-C in the picture, what do they do for us?
The answer is re-encapsulation. At every hop, a router removes the old DLL (Layer 2) encapsulation and adds a new one. If MPC switches are going to "pretend" to be routers, they have to someone do this. So the MPS is going to have to get new DLL headers to the MPC's involved, so they can cache it and put it in packets as necessary. The egress MPC has the responsibility of doing this chore. The egress MPC is the MPC the packet's cells exit the ATM cloud through.
The next question: when does this happen?
The ATM Forum document states:
"In its ingress role, an MPC detects flows of packets that are being forwarded over an ELAN to a router that contains an MPS. When it recognizes a flow that could benefit from a shortcut that bypasses the routed path, it uses an NHRP-based query-response protocol to request the information required to establish a shortcut to the destination."That is behavior similar to NHRP: it may not be worth the bother of doing cut-through for one packet. But when enough packets are detected flowing between two hosts (or subnets), it is then worth trying to do cut-through routing.
A packet is transmitted by an end host and arrives at MPC-A, the ingress MPC. Maybe this is a new flow or we haven't done cut-through (established a shortcut) with this data flow yet. We therefore forward the packet to the router, just as a bridge would. As the packet is being sent, the LANE client software on MPC-A's ATM interface does the work. As LANE sends the packet to MPS-B across the green ELAN, it counts flow information at the internetwork layer based on destination address. When a threshold is reached (packets per unit time), MPC-A will send an MPOA request to MPS-B.
MPS-B is the ingress MPS. It either responds, if the destination is local, or it re-originates the MPOA request via the local NHRP NHS, along the normal path routing would take. Let's say this request goes to MPS-C in the picture, across the blue ELAN.
MPS-C is the NHRP authoritative responder for MPC-D, so it sends an MPOA Cache Imposition Request to MPC-D across the red ELAN. In effect, it asks it "how'd you like to do a shortcut?" This particular request contains the encapsulation information MPC-D will need. MPC-D replies to MPS-C with status, ATM address, and inbound tagging information needed for the NHRP reply. Or it replies that it does not have sufficient resources left.
The shortcut is then established. (There are more details to this, but without having gone into detail on LANE, there's not much point to going through this here).
For the next packet in this flow, MPC-A would strip the DLL encapsulation before sending the packet via the shortcut. (This reduces overhead). See the picture.
If a packet arrives via a shortcut SVC, the egress (receiving) MPC examines its cache. If there is a DLL header, it is added and the packet forwarded (acting as a bridge again, unless there is a higher layer to hand off to). If no cache entry is found, the packet is discarded (since there's no way it can be forwarded).
And that's it!
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .