MPOA Components and Model
Various components comprise an MPOA system. The following sections describe each of the significant components. Figure 10-2 illustrates the components and their positional relationship. Note that there are ingress and egress devices, inbound and outbound flows, and configuration, control, and data flows.
Figure 10-2. MPOA Model
Note also the presence of LANE components. MPOA depends upon LANE for intra-ELAN communications. Communication between a Multiprotocol Client (MPC) and a Multiprotocol Server (MPS) occurs over an ELAN. Communication between adjacent Next Hop Servers (NHSs), another MPOA component discussed later in the section on Next Hop Resolution Protocol (NHRP), also occurs over ELANs. Finally, MPSs also communicate over ELANs. Additionally, if frames are sent between MPCs before a shortcut is established, the frames transit ELANs. The objective of MPOA is to ultimately circumvent this situation by transmitting frames over a shortcut between MPCs. However, the shortcut is not immediately established. It is the responsibility of the ingress MPC to generate a shortcut request with the egress MPC as the target. The ingress MPC request asks for the egress MPC's ATM address from the ingress MPS. The ingress MPS receives the shortcut request from the ingress MPC and resolves the request into a Next Hop Resolution Protocol (NHRP) request. NHSs forward the request to the final NHS, which resides in the egress MPS. The egress MPS resolves the request, informs the egress MPC to expect traffic from the ingress MPC, and returns the resolution reply to the ingress MPC.
In this process, three kinds of information flows exist: configuration, inbound/outbound, and control.
MPOA components acquire configuration information from the LECS. LANE version 2 defines this configuration flow. Both the MPC and the MPS can obtain configuration parameters from the LECS. Alternatively, they can get configurations from internal statements.
Inbound and outbound flows occur between the MPCs and the MPSs. The inbound flow occurs between the ingress MPC and MPS, whereas the outbound flow occurs between the egress MPC and MPS. Inbound and outbound are defined from the perspective of the MPOA cloud.
MPOA defines a set of control flows used to establish and maintain shortcut information. Control flows occur over ELANs between adjacent devices. Control flows as defined by MPOA include:
MPOA Resolution Request Sent from the ingress MPC to the ingress MPS.
MPOA Resolution Reply Sent from the ingress MPS to the ingress MPC.
MPOA Cache Imposition Request Sent from the egress MPS to the egress MPC.
MPOA Cache Imposition Reply Sent from the egress MPC to the egress MPS.
MPOA Egress Cache Purge Request Sent from the egress MPC to the egress MPS.
MPOA Egress Cache Purge Reply Sent from the egress MPS to the egress MPC.
MPOA Keep-Alive Sent from an MPS to an MPC.
MPOA Trigger Sent from an MPS to an MPC. If an MPS detects a flow from an MPC, the MPS issues a request to the MPC to issue an MPOA resolution request.
NHRP Purge Request Sent from the egress MPC to the ingress MPC.
NHRP Purge Reply Sent from the ingress MPC to the egress MPC.
Another approach to describe the control flows categorizes the flows by the components that exercise the flow. Flows between an MPC and an MPS manage the MPC cache. These include the MPOA resolution request/reply and the MPOA cache imposition request/reply. The MPC/MPS control flows communicate over the common ELAN.
Control flows between MPCs include the MPOA egress cache purge request and reply. This control flow occurs over the shortcut, which normally carries only user data. It is used to eliminate cache errors in the ingress MPC. When the egress MPC detects errors, it sends the purge request to the ingress MPC, forcing the ingress MPC to reestablish its cache information.
Control flows also exist between MPSs. However, these are defined by the internetwork layer routing protocols and NHRP. MPOA does not define any new control flows between MPSs.
The control flow list does not define the actual sequence of the messages. Figure 10-3 shows two MPCs and MPSs interconnected in an ATM network.
Figure 10-3. Control Flow Sequence in an MPOA System
The message sequence occurs as follows:
The ingress MPC sends an MPOA resolution request to the ingress MPS.
The ingress MPS translates the request into an NHRP request that gets forwarded toward the egress MPS.
The egress MPS issues an MPOA cache imposition request to the egress MPC.
The egress MPC responds back to the egress MPS with an MPOA cache imposition reply.
The egress MPS returns an NHRP resolution to the ingress MPS.
The ingress MPS sends an MPOA resolution reply to the ingress MPC.
MPS
The Multiprotocol Server (MPS) interacts with NHRP on behalf of the Multiprotocol Client (MPC). An MPS always resides in a router and includes a full NHS. The MPS works with the local NHS and consults the local routing tables to resolve shortcut requests from an MPC. Figure 10-4 illustrates the components of an MPS.
Figure 10-4. MPS Anatomy
The MPS has a set of interfaces attached to the ATM cloud and at least one interface for internal services. The external connections pointing to the ATM cloud consist of LANE client(s) and an MPS interface. The LANE clients support the MPOA device discovery protocol described later, and the actual flow of data before the shortcuts are established. The MPS also uses the LEC to forward resolution requests to the next NHS in the system. The service interface interacts with internal processes such as the router processes and the NHS to facilitate MPOA resolution requests and replies.
When an MPC detects an inter-ELAN flow, the ingress MPC issues a shortcut request to the MPS asking if there is a better way to the target MPC. The ingress MPS translates the MPC's request into an NHRP request, which is forwarded to the egress MPS. The egress MPS resolves the request and performs a couple of other activities. These activities include cache imposition to the egress MPC and resolution reply back toward the ingress MPC.
MPC
In most cases, an MPC detects an inter-ELAN flow and subsequently initiates an MPOA resolution request. The MPC detects inter-ELAN flows by watching the internetwork layer destination address. When the destination and source network addresses differ, the MPC identifies a candidate flow. The MPC continues to transmit using hop-by-hop Layer 3 routing. But, it counts the number of frames transmitted to the target. If the frame count exceeds a threshold configured by the network administrator (or default values), the MPC triggers an MPOA resolution request to an appropriate MPS. The threshold is defined by two parameters: the number of frames sent and the time interval.
When the ingress MPC receives a resolution reply from the ingress MPS, the MPC can then establish a shortcut to the target MPC. Additional frames between the ingress and egress MPCs flow through the shortcut bypassing the routers in the default path.
MPOA identifies two types of MPC devices: a host device and an edge device. They differ in how they originate data in the MPOA system. The sections that follow discuss these two types of MPOA devices in greater detail.
MPOA Host Devices
Host devices originate traffic to traverse the MPOA network. A typical example of an MPC host device includes a workstation with an ATM network interface card (NIC), and MPOA drivers. An MPOA Host, then, includes at least one MPC, at least one LEC, and an internetworking layer protocol stack. An MPOA host generates traffic on its own behalf. Figure 10-5 shows an MPOA Host logical representation.
Figure 10-5. MPOA Host Device Anatomy
Like the MPS, the MPC host device has internal and external interfaces. The external interfaces include the LEC and the MPC. The MPC communicates to the LES through the LEC to detect MPOA neighbors. Also, traffic transmissions that are initiated before a shortcut is established will pass through the LEC.
The MPC interface, on the other hand, is used for shortcuts. When the MPC detects a flow, it issues a resolution request through its MPC interface. The MPC receives the resolution reply through the MPC interface too. After the MPC establishes a shortcut, the MPC interface becomes the origination point of the data circuit to the other MPC.
When you enable MPOA, all outbound traffic is forced through the MPC, whether or not a shortcut exists. The MPC internal service interface accepts the host's outbound traffic and passes it through the MPC. This enables the MPC to watch for flows so that shortcuts can be established as needed.
MPOA Edge Devices
Edge devices inject traffic into an MPOA system on behalf of non ATM-capable devices. As such, edge devices integrate at least one MPC, at least one LEC, and a bridge port. Bridges, LAN switches, and routers represent typical edge devices. Figure 10-6 illustrates an MPOA edge device logical representation.
Figure 10-6. MPOA Edge Device Anatomy
The MPC edge device is nearly identical to the MPC host device, except that its service interface connects to bridging processes. This happens because the edge device is facilitating connectivity of non-ATM capable devices onto the ATM network. These non-ATM capable devices are connected into the MPOA environment through bridged interfaces in the MPC edge device.
MPOA Operational Summary
Refer to Figure 10-7 for the following summary of data flows in MPOA.
Figure 10-7. MPOA Data Flow Summary
(1)Before the ingress MPC requests a shortcut, the MPC forwards frames through the LEC interface to the ATM cloud to the MPS. The MPS receives the flow on its LEC interface, performs routing and (2) forwards the frame to the next MPS. This continues until the frame reaches the egress MPS where the frame is forwarded (3) over the ELAN to the egress MPC. Until the ingress MPC establishes a shortcut, all frames pass through LECs at each device. When the ingress MPC detects a flow that exceeds the configured threshold levels (# of frames/time), the MPC issues an MPOA resolution request (4) through the MPC control interface to the ingress MPS. The ingress MPS forwards the request (5) to the next NHS which may or may not reside in an MPS. The resolution request continues to be forwarded until it reaches the device that serves as the egress MPS. Note that the resolution request propagates through LANE clients. Resolution replies propagate back to the ingress MPS (6) through LANE clients. The ingress MPS forwards the reply (7) to the ingress MPC through the MPOA control circuit. Then the ingress MPC establishes a shortcut (8) to the egress MPC. The shortcut is established to the MPC interface, not the LEC interface. Subsequent data frames stop transiting the LEC interfaces and pass through the MPC interface directly to the egress LEC.
In summary, intra-ELAN sessions flow through LANE clients, whereas inter-ELAN flows pass through the MPC interfaces.
LANE V2
In July of 1997, the ATM Forum released LANE version 2, which introduces enhancements over version 1. MPOA depends upon some of the enhancements to support MPOA operations. For example, one of the enhancements was the addition of the elan-id. MPOA uses the elan-id to identify what broadcast domains (ELANs) MPOA devices belong to. This is expected behavior in MPOA. In a non-MPOA environment, LECs use the elan-id value to filter traffic from other ELANs. If a LEC in one ELAN somehow obtains the NSAP of a LEC in another ELAN, the LEC can issue a connection request. However, because they are in different ELANs, the receiving ELAN can (and should) reject the connection request. Why? Because they are in different ELANs, they also belong to different subnetworks. A direct connection between them, then, is illegal outside of the scope of MPOA. Another LANEv2 enhancement supports neighbor discovery. When a LEC registers with the LES, it reports the MPOA device type associated with it. For example, if the LEC is associated with an MPC, the LEC informs the LES that the LEC serves an MPC. LECs associated with MPSs also report to the LES. The MPOA devices can then interrogate the LES to discover any other MPOA devices on the ELAN.
NHRP
Frequently, networks are described as having logically independent IP subnets (LISs). In legacy LANs, devices on each segment normally belong to a different IP subnet and interconnect with devices in other subnets through routers. The physical construction of the networks force traffic through the routers. In an ATM environment, a hard physical delineation doesn't exist. Connections exist whenever one ATM device requests the ATM network to create a logical circuit between the two devices. In a LAN environment, devices in the same subnet usually are located within a close proximity of each other. But in the ATM network, the devices can be located on opposite sides of the globe and still belong to the same LIS. In Figure 10-8, several LISs exist in an ATM network. But the illustration provides no hint as to the geographical proximity of devices in the system.
Figure 10-8. LISs in a Nonbroadcast Multi-Access (NBMA) Environment
NHRP describes the attributes of each LIS in an NBMA network. Quoting RFC 2332 (NHRP):
All members of an LIS have the same IP network/subnet number and address mask.
All members of an LIS are directly connected to the same NBMA subnetwork.
All hosts and routers outside of the LIS are accessed via a router.
All members of an LIS access each other directly (without routers).
Whenever an IP station in a LIS desires to talk to another IP station in the same LIS, the source station issues an ARP request to the destination station. If the source desires to communicate with a destination in another LIS, the source must ARP for a router that is a member of at least two LISs. A router must belong to the LIS of the source device and the next hop LIS. In other words, traffic in a LIS flows hop by hop just as it does for legacy networks interconnected with Layer 3 routers. Routers must, therefore, interconnect multiple LISs to provide a Layer 3 path between networks.
NHRP identifies another method of modeling stations in an NBMA network. Logical Address Groups (LAGs) differ from LISs in that LISs forward traffic in a hop-by-hop manner. Traffic must always be forwarded to another device in the same LIS. LAGs, on the other hand, associate devices based on Quality of Service (QoS) or traffic characteristics. LAGs do not group stations according to their logical addresses. Therefore, in a LAG model, two devices in the same NBMA network can talk directly with each other, even if they belong to different LISs. MPOA shortcuts interconnect devices belonging to different LISs, creating a LAG.
NHRP works directly with routing protocols to resolve a shortcut between workstations in different LISs. The primary NHRP component to do this is the Next Hop Server (NHS) which interacts with the router to determine next hop information. Each MPS has an NHS collocated with it. The MPS translates a resolution request to an NHS request. The NHS interrogates the router for next hop information. If the destination is local, the NHS finishes its job and reports the egress information to the ingress MPS. If the destination is not local, the NHS forwards the request to the next NHS toward the destination. The NHS determines the next NHS based upon the local routing tables. It answers the question, "What is the next hop towards the destination?" The request is forwarded from NHS to NHS until it reaches the final NHS, whereupon the egress information is returned to the ingress MPS.
EAN: N/A
Pages: 223