The Multi Protocol Over ATM (MPOA) deals with the efficient transfer of inter-subnet unicast data in a LANE environment. MPOA integrates LANE and NHRP to preserve the benefits of LAN Emulation, while allowing inter-subnet, internetwork layer protocol communication over ATM VCCs without requiring routers in the data path. MPOA provides a framework for effectively synthesizing bridging and routing with ATM in an environment of diverse protocols, network technologies, and IEEE 802.1 virtual LANs. MPOA is capable of using both routing and bridging information to locate the optimal exit from the ATM cloud; it allows the physical separation of internetwork layer route calculation and forwarding, a technique known as virtual routing.
Based on ATM UNI signaling, LAN Emulation, and Next Hop Resolution Protocol (NHRP), MPOA defines two components: MPOA Clients (MPCs) and MPOA Servers (MPSs), and the protocols that are required to communicate and receive services.
The MPS is a component of a router, and is only useful in a router that has an Next Hop Server (NHS) and interfaces to one or more LECs. The data and control path from the router through the LEC(s) to LANE is unaltered by MPOA. The MPS does, however, interact with the router, its LEC(s), the NHS, and other MPOA components. A LEC is associated with a single MPS.
MPOA uses a protocol based on the Next Hop Resolution Protocol [NHRP] to manage caches and establish shortcuts. It performs the following operations:
- Configuration- Obtaining the appropriate configuration information.
- Discovery- MPCs and MPSs learning of each others' existence.
- Target Resolution - Determining the mapping of a Target to an egress ATM address, an optional Tag, and a set of parameters used to set up a Shortcut VCC to forward packets across subnet boundaries.
- Connection Management - VCCs Creating, maintaining, and terminating for the purpose of transferring control information and data.
- Data Transfer - Forwarding internetwork layer data across a Shortcut.
- MPOA components must support the use of LLC/SNAP encapsulation for all PDUs. By default VCCs must be signaled to use LLC encapsulation. An MPOA component must be capable of establishing, receiving and maintaining a VCC to any entity that conforms to the connection management procedures, whether or not that entity is an MPOA component
Protocol Structure
MPOA tagged encapsulation format:
| 0 | LLC- X"AA" | LLC-X"AA" | LLC X"03" | OUI-X"00" | ||
| 4 | OUI-X"00" | OUI-X"00" | Frame-Type = 0x884C | |||
| 8 | MPOA Tag | |||||
| 12-n | Internetwork Layer PDU (up to 2^16 - 13 octets) | |||||
By default, MPOA uses LLC encapsulation for all control flows as defined in [NHRP], with the same fixed header as an NHRP packet described below:
| 0 | ar$afn | ar$pro.type | ||
| 4 | ar$pro.snap | |||
| 8 | ar$pro.snap | ar$hopcnt | ar$pkstz | |
| 12 | ar$chksum | ar$extoff | ||
| 16 | ar$op.version | ar$op.type | ar$shtl | ar$sstl |
- ar$afn - Defines the type of "link layer" address being carried.
- ar$pro.type C Protocol Type, this field is a 16 bit unsigned integer.
- ar$pro.snap - When ar$pro.type field equals to 0x0080, a snap encoded extension, which is placed in the ar$pro.snap field. is being used to encode the protocol type. Default this field should be set to 0.
- ar$hopcnt - Hop count- the maximum number of NHSs that an MPOA packet is allowed to traverse.
- h="10%"> 8 -n
MPOA PDU - (up to 2^16 - 9 octets)
By default, MPOA uses LLC encapsulation for all control flows as defined in [NHRP], with the same fixed header as an NHRP packet described below:
| 0 | ar$afn | ar$pro.type | ||
| 4 | ar$pro.snap | |||
| 8 | ar$pro.snap | ar$hopcnt | ar$pkstz | |
| 12 | ar$chksum | ar$extoff | ||
| 16 | ar$op.version | ar$op.type | ar$shtl | ar$sstl |
- ar$afn - Defines the type of "link layer" address being carried.
- ar$pro.type C Protocol Type, this field is a 16 bit unsigned integer.
- ar$pro.snap - When ar$pro.type field equals to 0x0080, a snap encoded extension, which is placed in the ar$pro.snap field. is being used to encode the protocol type. Default this field should be set to 0.
- ar$hopcnt - Hop count- the maximum number of NHSs that an MPOA packet is allowed to traverse.
- ar$pktsz - The total length of the MPOA packet in octets.
- ar$chksum - The standard IP 16-bit checksum over the entire MPOA packet.
- ar$extoff - This field identifies the existence and location of MPOA extensions.
- ar$op.version - Version of generic address mapping and management protocol, set to X01 NHRP
- ar$op.type - The MPOA packet type. Some values for packet types are:
| 128 | MPOA Cache Imposition Request. | 129 | MPOA Cache Imposition Reply. |
| 130 | MPOA Egress Cache Purge Request. | 131 | MPOA Egress Cache Purge Reply. |
| 132 | MPOA Keep-Alive. | 133 | MPOA Trigger. |
| 134 | MPOA Resolution Request. | 135 | MPOA Resolution Reply. |
| 136 | MPOA Error Indicator |
- ar$shtl - The type and length of the source NBMA address interpreted.
- ar$sstl - The type and length of the source NBMA subaddress interpreted
Related protocols: SONET, ATM, LAN Emulation, CES, PNNI, Q.2931
Sponsor Source:
The ATM protocols are based on standards developed by the ITU.
ftp://ftp.atmforum.com/pub/approved-specs/af-mpoa-0114.000.pdf "Multiprotocol over ATM Version 1.1", ATM Forum af-mpoa-0114.000, May 1999
Reference:
ftp://ftp.atmforum.com/pub/approved-specs/af-mpoa-0129.000.pdf "MPOA Addendum on VPN support", ATM Forum af-mpoa-0129.000, October 1999.
"Next Hop Resolution Protocol", IETF RFC 2332, April 1998
http://www.atmforum.com/standards/approved.html#uni: ATM User-Network Interface Specification
http://www.atmforum.com/standards/approved.html: ATM Forum approved specifications
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/atm.htm: ATM Overview
