Analyzing and reducing the protocol overheads of the
MPOA in the intra-Communication
1Wei Kuang Lai2 and J. -M. Chung High Speed Networks Laboratory
Department of Computer Science and Engineering National Sun Yat-Sen University, Kaohsiung, Taiwan, ROC
Wklai@cse.nsysu.edu.tw
1
This research is supported in part by National Science Council of Taiwan, ROC, under contract NSC87-2213-E-110-021.
2 wklai@cse.nsysu.edu.tw
Abstract
The MPOA protocol adopts the LANE protocol for intra-Communication. In this paper, we discuss the advantages and the disadvantages of the MPOA and explain why the LANE is a performance bottleneck in the
intra-Communication and the
inter-Communication. To verify our ideas, we first benchmark the performance of the LANE and the IPOA. Then we analyze the encapsulation overheads. The results show the IPOA is more scalable than the LANE when the bandwidths increase. This is due to the differences in the number of interrupts. The results also suggest the implementation of the IPOA protocol is necessary when we increase the bandwidth of the edge devices. Hence, we propose the IPOA+ protocol to extend the functions of the IPOA to edge devices and discuss the necessary changes for incorporating the IPOA+ protocol into the MPOA protocol. The modified MPOA protocol is called the MPOA+ protocol. The MPOA+ protocol is shown to need fewer pre-established connections than the MPOA protocol. We also simulate the MPOA+ protocol and the MPOA protocol for the number of ARP requests, the BUS/MCS loads, the connection delays, the number of SVC connections for establishing shortcuts, and the buffer requirements for those two protocols. The simulation results show the MPOA+ has significant improvement over the
MPOA protocol for intra-Communication on all those aspects.
Keywords: LANE, MPOA, communication. .
1. Introduction
The introduction of multimedia
applications and the increase in the number of hosts connected to Internets [1-3] have made high-speed networks necessary. On one hand, Fast Ethernet and Gigabit Ethernet are introduced to improve the performance of Ethernet networks while they maintain the characteristics of the Ethernet networks. On the
other hand, new technology such as
Asynchronous Transfer Mode (ATM) is adopted by the ITU-T as the transfer technology for Broadband ISDN (B-ISDN) [4-6]. ATM is a connection-oriented network and is a protocol designed for both LANs and WANs. ATM has the advantages of low delays, high speed, guaranteed Quality of Services (QoSs), and bandwidth on demand. On the top of the Ethernet (with or without Logical Link Control (LLC) in the middle) or the ATM, the IP is the most popular protocol [7-10].
Two issues, the address resolution and the support of broadcast/multicast, need to be addressed in the two approaches. To solve those problems and let the traditional networks communicate with the ATM networks, the ATM Forum adopts the LAN Emulation (LANE) [1] and the Multi-Protocol over ATM (MPOA) [2].
On the other hand, the IETF designs the classical IP over ATM (IPOA) [3]. They are briefly introduced as follows:
LANE: The hosts on the ATM networks emulate the MAC layer protocols of the traditional networks. Hence, the software developed in the traditional networks can run on the ATM networks without knowing that the protocols have been changed from the traditional
networks to the ATM networks. This
characteristic is called transparency. LANE server (LES) is responsible for the address resolution between the ATM layer and the MAC layer and Broadcast and Unknown Server (BUS) is responsible for broadcasting and multicasting. When a LANE Client (LEC) wants to transmit data to another client, the LEC broadcasts its IP ARP request through the BUS. The destination or the proxy server of the destination returns an IP ARP reply to the source LEC via the BUS. The destination or the proxy server of the destination also sends an ARP request to the LES for acquiring the ATM address of the source LEC and then establishing a VCC with the source VCC. After receiving an IP ARP reply, the LEC can query the LES by an ARP request to obtain the destination ATM address and then make a connection for transmitting data. Eventually, the source LEC will find that a connection from the destination or the proxy server of the destination to the source has also been established and will combine the two VCCs into a VCC. Before the connection is established, the data can be forwarded to the destination via the BUS.
Classical IP over ATM (IPOA): To implement the IPOA, there are some standards proposed by the IETF and the ATM Forum we must follow. Related documents include RFC 2225 Classical IP and ARP over ATM [11], RFC 1483 Multiprotocol Encapsulation over ATM for packet encapsulation [10], RFC 1191 Path MTU Discovery [12], RFC 826 Address Resolution Protocol [2], RFC 1293 Inverse Address Resolution Protocol [3], RFC 1755 ATM Signaling Support for IP over ATM [13], ATM Forum MPOA [14] and ATM Forum UNI 4.0 specification for User Network Interface [6], etc. TCP/IP is the most popular protocol. The IPOA allows the software developed on the TCP/IP to run on the ATM networks. The address resolution needed is between the IP layer and the ATM layer. There is no address resolution between the IP layer and the MAC layer. An ATM Address Resolution Protocol (ARP) Server is responsible for the address resolution. When a
host wants to communicate with another host, the local host first issues an ATM ARP request to the ARP Server (ARS). After receiving an ARP reply from the ARS and obtaining the ATM address of the destination host, a connection is established between the local host and the destination host. Then the data can be transmitted via the connection. Before the connection is established, the data is queued in the buffers of the local host.
Multiprotocol over ATM (MPOA) is developed by the joint effort of the ATM Forum and the IETF [14-15]. The main purpose of the MPOA is to integrate different protocols running on ATM networks (ex. IPv4 and IPX). The communication of the MPOA consists of two kinds. The communication among hosts within the same IASG (Internet Address Sub Groups) is called Intra-IASG. The IASGs are similar to the concept of the subnets in traditional networks. Different groups are given different routing addresses. The communication among hosts of different IASGs is called Inter-IASG. For the Intra-IASG, the MPOA adopts LANE (LAN Emulation) protocol and architecture as a basis [16-17]. For the Inter-IASG, the MPOA also
adopts the LANE protocol for the
communication within the same IASG and adopts the concept of a virtual router for the communication across multiple IASGs. The virtual router consists of two functions, routing and forwarding. Those two functions need not be implemented in the same host. The routing function is responsible for making address resolution and establishing a shortcut. Then the
forwarding function is responsible for
transmitting frames from sources to destinations. The division of the virtual router into two function groups has the advantages of simplifying the design and reducing the cost. The routing speed can also be increased so the virtual routers will not become the bottlenecks of networks. Frames are sent from source to destination by a pre-defined path in the beginning. The MPOA also supports the establishment of a shortcut between two MPOA clients (MPCs) in the same IASG or different IASGs. By the help of a shortcut, we can achieve the goal of cut-through or zero-hop. That is, frames do no need to be forwarded hop by hop from source to destination.
The connections needed in the MPOA architecture is shown in Figure 1. There are two IASGs in this Figure. Every IASG has its own LES. The upper half is the connections needed
point-to-multipoint (pt-to-mpt) connections needed in the LES for the LANE ARP and the pt-to-mpt connections needed in the BUS for the broadcast are omitted. The lower half is the connections needed between the MPCs and the MPS. In the third Section, we will use the Figure 1 again to compare the number of pre-established connections needed for the
MPOA and the modified protocol, MPOA+.
There are several major advantages for the MPOA protocol. They are as follows:
1) The shortcut is an efficient way of communication,
2) The number of stations with the routing function is decreased. Only the MPOA routers have the routing function. Hence, the scalability is increased and the complexity of management is decreased, and
3) The design of the MPOA router and the MPOA edge devices/hosts are simplified. The MPOA routers do not support the forwarding
function. Similarly, the MPOA edge
devices/hosts do not support the routing function. The MPOA edge devices/hosts only support the forwarding function of the router.
There are several disadvantages in the MPOA protocol. They are also listed as follows: 1) Fragmentation of IP datagrams is highly
undesirable [11][18]. The performance benchmarks obtained by several researchers [19] show that the IPOA is more scalable than the LANE when the bandwidth increases.
2) The MTU of the AAL5 is more than 65535 bytes so the actual MTU of the AAL5 is limited by the MTU of the LANE and the IPOA. The LANE can not adjust the size of the Maximum Transport Unit (MTU). This will affect the performance of the MPOA protocol in the intra-Communication and the inter-Communication. The first reason is the default Maximum Transfer Unit (MTU) of the IPOA layer is 9180 bytes [11-12] and the MTU of the Ethernet MAC layer is 1500 bytes. The default MTU for the IPOA can be set by running path MTU discovery [12] on IPOA hosts or by a pre-agreed value in the beginning. Because the MPOA adopts the LANE, the MTU of the MPOA is limited to 1500 bytes. When we implement the LANE, the MAC layer has to interrupt with the LANE layer every 1500 bytes or less. If we implement the IPOA, the IPOA layer only has to interrupt with the IP layer every 9180 bytes.
2) It is hard to provide Quality of Service (QoS)
in the LANE because the LANE is in the MAC layer protocol (layer 2). New protocols such as IPv6 and RSVP provide some degree of QoSs (Quality of Services). The IPOA allows us to extend QoSs of those protocols to LANs, and
3) The architecture of the MPOA protocol is not easy to implement. The MPOA protocol includes the LANE, the MPS with the NHRP, the routing function, and the forwarding function.
To improve the performance of the MPOA, we extend the functions of the IPOA protocol to edge devices and modify the MPOA protocol,
which is called the MPOA+ protocol. The IPOA
protocol allows us to negotiate the size of MTU between hosts. In the next Section, we will further discuss the motivation of adopting the IPOA protocol and the motivation of designing a modified protocol. As to the second point, the
MPOA+ protocol can benefit from researches for
providing Quality of Services (QoSs) in TCP/IP
networks [8][20]. In addition, the MPOA+
protocol does not need to implement the LANE
protocol. The operations of the MPOA+ protocol
for establishing connections are greatly
simplified. This is explained in Section 3 and Section 4 of the paper. The paper is organized as follows. Section 2 is the motivation of the paper. In this Section, we benchmark the performance of the IPOA and the LANE and compare their encapsulation overheads. The results suggest we extend the functions of the IPOA protocol to edge devices and design a modified MPOA
protocol, the MPOA+ protocol. In Section 3, the
MPOA+ protocol is proposed. We first discuss
the necessary changes to extend the IPOA
protocol to the edge device, the IPOA+ protocol.
Then we discuss the message flows and the necessary changes in the MPOA protocol. Section 4 is the Conclusions.
2. Motivation
In this Section, we perform benchmarks for those two protocols and discuss the encapsulation overheads of the LANE and the IPOA [11][21-22]. We also explain why the IPOA is better than the LANE.
2.1 The benchmarks of the LANE and the IPOA
In this subsection, we benchmark the performance of the LANE and IPOA by using the TCP_STREAM communication mode of the Netperf [19]. The environments for performing the benchmarks are shown in Table 1. Two SUN workstations with the FORE ATM interface
cards communicate with each other. The FORE interface card can support 155 Mbps of transmission rate. One host sends packets to the other host. In this test, the MTU of the IPOA is set to be 9180 bytes and the MTU of the LANE is set to be 1500 bytes. Figure 2 shows the bandwidths for different socket buffer sizes. From the Figure, we find that the performance of the IPOA is about 50% more than the LANE for buffer sizes over 33000 bytes. The performance differences can be explained by the Figure 3. Because we can have a larger MTU size in the IPOA, the number of interrupts needed for the IPOA is far less than the number of interrupts for the LANE. The hosts need to be fast enough in processing interrupts when they send or receive frames by the LANE. In today, machines can handle interrupts from several hundreds interrupts/sec for workstations to about 10000 interrupts/sec for workstation servers. For example, a sparc 10 workstation can handle 911 interrupts/sec but the number of interrupts needed for a channel of 155 Mbps is 1839 interrupts/s for the IPOA and 11037 interrupts/sec for the LANE. Hence, both the IPOA and the LANE can not achieve the expected bandwidths. However, the MPOA is 50% better than the LANE when the buffer sizes are over 33000 bytes.
2.2 Comparisons of the encapsulation overheads between the LANE and the
IPOA
We know there are overheads in the physical layer, the ATM AAL layer, and the LLC layer. In here, we want to compare the encapsulation overheads in the LLC layer. If the physical layer selects the SONET protocol and according to the standard, both the LANE and the IPOA adopts the AAL type 5 in the ATM AAL layer, the only difference is in the LLC/SNAP layer. The data formats for the LANE and the IPOA are shown in Figure 4 and Figure 5, respectively. If we adopt the LLC/SNAP protocol, then we select the multiplexed data frame format for IEEE 802.3 in the LANE and the RFC1483 LLC/SNAP encapsulation for routed IP PDUs in the IPOA. The data formats of them can be shown as Figure 6. In this Figure, l is the size of the LLC/SNAP header (8 bytes) or the size of the LANE Header (28 bytes which includes the LLC/SNAP field), m is the size of the IP PDU, p is the size of padding (p1 for the IPOA, p2 for
the LANEv2), and t is the size of trailer. Then the
IPOA encapsulation must satisfy the following equation.
(8 + m + p1 + 8) mod 48 = 0, where m 0, p1 0, and p2 0. (1)
Similarly, the LANE must satisfy the following equation.
(28 + m + p2 + 8) mod 48 = 0, where m 0, p1 0, and p2 0. (2)
Form equation (1) and equation (2), we knows that equation (2) minus equation (1) leaves the following equation.
[20 + (p2 - p1)] mod 48 = 0 [20 + (p2 - p1)] = 48k, (k 0, k Z). (3)
The proportions of overheads for the IPOA (U1) and the proportions of overheads for the LANE (U2) are calculated as follows.
U1 = m/(m + 16 + p1) U2 = m/(m + 36 + p2).
If we let d = U1 – U2, we have the following equation, d = U1 – U2 d = m/(m + 16 + p1) – m/(m + 36 + p2) d = [m(m + 36 + p2) – m(m + 16 + p1)] / (m + 16+ p1)(m + 36 + p2) d = m[20+(p2 - p1)] / (m + 16 + p1)(m + 36 + p2). (4)
From (3) and (4), we have d > 0. Hence,
the encapsulation efficiency of the IPOA+ is
always better than the encapsulation efficiency of the LANE. Table 2 is the transmission rates
for different layers in the IPOA+ protocol and
the LANE with different MTUs. In general, the MTU size of the LANE is limited by the MTU of the Ethernet layer which is 1500 bytes. On
the other hand, the IPOA+ is more flexible in the
MTU size because we can renegotiate the MTU
size in the IPOA+ protocol. For example, if we
adopt 9200 bytes for the MTU of the IPOA+ and
1500 bytes for the MTU of the LANE protocol, the maximum transmission rates are 135.397 Mbps for the IPOA and 132.453 Mbps for the LANE. The difference between them is 2.944 Mbps.
3 The MPOA
+protocol architecture
Under the current IPOA standard, the edge device can not implement the IPOA protocol. However, the traditional networks are connected to the ATM networks by edge devices. In this paper, we propose the necessary changes for the IPOA protocol and the MPOA protocol. The idea of the proxy server for implementing the IPOA in the edge device is also adopted here [23]. The modified IPOA protocol is used to
replace the LANE function for the
Intra-Communication in the MPOA. The
protocol. The modified MPOA protocol with the necessary changes in the IPOA protocol is called
the MPOA+ protocol. The MPOA+ protocol is
shown in Figure 7 which does not implement the function of the LANE. The upper half of the Figure is the pre-established connections among the IPCs, the IPOASs, and the IPCS for the
IPOA+ protocol. For simplicity, the pt-to-mpt
connections from the MCSs to LECs are omitted. The lower half of the Figure is the connections between the MPCs and the MPSs, which are
needed in the MPOA+ protocol.
3.1 The IPOA+ protocol
The IPOA+ protocol consists of several
parts. They are explained as follows.
IPOA Configuration Server (IPCS): The IPCS provides information to the IPOA clients or the MPS. The information includes the Type Length Value (TLV), the ATM address of the IPOA server, the ATM address of the MPS, etc. The functions of the IPCS are to replace the functions of the LANE Configuration Server (LECS) in the original MPOA protocol.
IPOA Server (IPOAS): The IPOAS provides the function of address resolution. There is only one IPOAS in an IASG. Unlike the LANE Server (LES) which provides the address resolution function between the MAC address and the ATM address, the IPOAS provides the address resolution function between the IP address and the ATM address.
IPOA Client (IPC): The IPC is implemented in both the MPCs and the MPS. The IPCs within an IASG need to register at their IPOAS. Each IPC registers its related information, which includes the IP address and the ATM address. The IPC needs to know the address of its IPCS so the IPC can find its IPOAS.
Multicast Server (MCS): The MCS provides the functions of multicast and broadcast. Any multicast message is sent to the MCS first, and the MCS forwards the multicast message to destinations.
The message flows of the MPOA+ protocol
are shown in Figure 8. The upper half is the
operation of the IPOA+ and the lower half is the
operation of the MPOA+. For the pt-to-pt
connection in the IPOA operation, the IPC first communicates with the IPCS to get the address of the IPOAS. Then the IPC registers itself to the IPOAS and a control direct VCC from the IPC to the IPOAS and a control distribute VCC form the IPOAS to all IPCs are established. The connections between the IPC and the MCS and the registration from the MPC to the MPS are optional and are needed only if multicast
communication is supported. The IPC then makes an ARP query to the IPOAS to get the ATM address of the destination IPC. After obtaining the destination ATM address, the IPC makes a direct connection with the destination IPC. For the MPOA operation, the local MPS makes a query to the IPCS to get the ATM address of the remote MPS. Then the local MPS establishes an MPS-MPS control VCC with the remote MPS. The MPC can now query the IPCS about the ATM address of the MPS. The MPC registers itself to the MPS and an MPC-MPS control VCC is established between the MPC and the MPS. The MPC now makes a query to the MPS for the ATM address of the remote MPC. By the help of the MPSs and the NHS, the MPC can establish a shortcut to the remote MPC.
3.2 The service blocks of the MPOA+ protocol
The service blocks of the MPOA+ protocol
for the AH/ED are shown in Figure 9. The MPOA protocol consists of the MPC service
block and the LANE service block. The MPOA+
protocol consists of the MPC+ service block, the
IPC service block, and the IPOARP service block. The MPC service block is replaced by the
MPC+ service block and the LANE service
block is replaced by the IPC service block and the IPOARP service block. Note that the IPOARP can be viewed as part of the IPC service block. There are three kinds of ARPs. The IP ARP requests are issued by the IP layer,
the IPOA ARP requests are issued by the IPOA+
protocol for the intra-Communication, and the
MPOA ARP requests are issued by the MPOA+
layer for the inter-Communication. The flow
diagram of the MPC+ service block is shown in
Figure 10. When the ingress MPC+ receives an
IP_ARP_REQ or an IP_ARP_REP, it is forwarded to the inbound IPOARP service
interface. When the ingress MPC+ receives an
IP_PDU or an IPX_PDU, it first decides whether the destination address is a local address. If the address is a local address, the IP_PDU or the IPX_PDU is forwarded to the inbound IPC service interface. If the destination address is a remote address, we look up an entry in the ingress cache for the destination address or create an entry for the destination address when we can not find one. If there is an entry in the ingress cache for the destination address and the connection to the destination address is a shortcut, we forward the IP_PDU or the IPX_PDU to the ingress MPOA_VCC service interface. If there is an entry in the ingress cache for the address and the connection to the address
is not a shortcut or if there is no entry for the address so we create one, we count the total number of frames and compare the number with a certain threshold. If the number exceeds the threshold, we send the IP_PDU or the IPX_PDU to the inbound IPC interface. If there is no outstanding request, MPOA_ARP_REQ, we also send an MPOA_ARP_REQ to the ingress MPOA_VCC service interface for establishing a shortcut. If the number does not exceed the threshold, we only forward the IP_PDU or the IPX_PDU to the inbound IPC interface. When the outbound IPC or the outbound IPOARP receives a frame, it forwards the frame to the
egress MPC+ interface. When the egress
MPOA_VCC service interface receives a frame through a shortcut, it sends the frame to the
egress MPC+ interface if there is an egress cache
hit or performs an error recovery function (purges the VCC connection) if there is an egress cache miss.
The flow diagram of the IPC service block is shown in Figure 11. When a frame arrives at the inbound IPC service interface and the destination IP address is a broadcast address, the frame is forwarded to the MCS through the inbound IPOA_VCC service interface. If the destination address is not a broadcast address, we look up an entry in the inbound cache for the destination address or create an inbound cache entry when we can not find one. If there is an entry in the inbound cache for the destination address and the connection to the destination address is a shortcut, we forward the frame to the inbound IPOA_VCC service interface. If there is an entry in the inbound cache for the destination address and the connection to the destination address is not a shortcut or if there is no entry for the destination address so we create one inbound cache entry, we count the total number of frames and compare the number with a certain threshold. If the number exceeds the threshold, we send the frame to the MCS through the inbound IPOA_VCC service interface. If there is no outstanding request,
IPOA_ARP_REQ, we also send an
IPOA_ARP_REQ to the IPOAS through the inbound IPOA_VCC service interface for establishing a shortcut. If the number does not exceed the threshold, we only forward the frame to the MCS through the inbound IPOA_VCC interface. When the frame arrives at the outbound IPOA_VCC service interface through
a VCCDirect/MCS and there is an outbound cache
hit, the frame is forwarded to the outbound IPC service. When the frame arrives at the outbound
IPOA_VCC service interface through a
VCCDirect/MCS and there is not an outbound cache
hit, the destination address is a broadcast address) and the frame is put into the queue waiting for transmission.
The flow diagram of the IPOARP service block is shown in Figure 12. When an IP ARP request, IP_ARP_REQ, arrives at the inbound IPOARP service interface from the IP layer and there is an inbound ARP cache hit, an IP ARP reply, IP_ARP_REP, is sent to the outbound IPOARP service interface. When an IP ARP request, IP_ARP_REQ, arrives at the inbound IPOARP service interface from the IP layer and there is not an inbound ARP cache hit, a request, IPOA_ARP_REQ, is sent to the IPOAS through the inbound IPOA_VCC service interface and an inbound cache entry is created. When the arrival frame in the inbound IPOARP service interface is an IP ARP reply, IP_ARP_REP, from the IP layer, a reply, IPOA_ARP_REP, is sent to the IPOAS through the inbound IPOA_VCC service interface. When the arrival frame is neither a request nor a reply, the frame is discarded. When an IPOA ARP reply, IPOA_ARP_REP, arrives at the outbound IPOA_VCC service interface, we send an IP reply, IP_ARR_REP, to the outbound IPOARP service interface. When an IPOA ARP request, IPOA_ARP_REQ, arrives at the outbound IPOA_VCC service interface and there is not an outbound ARP cache hit, an IP ARP request, IP_ARP_REQ, is sent to the outbound IPOARP service interface. When an IPOA ARP request, IPOA_ARP_REQ, arrives at the outbound IPOA_VCC service interface and there is an outbound ARP cache hit, an IPOA ARP reply, IPOA_ARP_REP, is sent to the IPOAS through the inbound IPOA_VCC service interface. When the arrival frame is neither a request nor a reply, the frame is discarded.
3.3 Comparisons between the MPOA+ and the MPOA for the number of pre-established
connections
The connections needed in the MPOA+
protocol are shown in Figure 7. There are two IASGs in the Figure. From Figure 1 and Figure 7, we can compare the total number of connections. The variables are assumed as follows:
Number of Configuration Servers = a (1) Number of MPOA Routers = b (1) Number of MPOA AHs/EDs = c (1) Number of kind of ELANs = d (1).
MPOA protocol.
The total number of hosts = the number of the LECSs + the number of MRs + the number of AHs/Eds + the number of BUSs/LESs = a + b +
c + 2d.
The total number of connections = the connections between the AHs/EDs and the LECSs + the connections between the AHs/EDs and the LESs/BUSs + the pt-to-mpt connections in the LESs/BUSs + the connections between the AHs/EDs and the MR router = (c + d+ b) + 2(c + b) + 2d (pt-to-mpt connections) + c = [(c +
d+ b) + 2(c+b) + c] pt-to-pt connections + 2d
pt-to-mpt connections.
We also have the following equations for
the MPOA+ protocol.
The total number of hosts = the number of the IPCSs + the number of MRs + the number of AHs/Eds + the number of MCSs/IPOAs = a + b + c + 2.
The total number of connections = the connections between the AHs/EDs and the IPCSs + the connections between the AHs/EDs
and the IPOAs/MCSs + the pt-to-mpt
connections in the IPOAs/MCSs + the connections between the AHs/EDs and the MR router = (c + 1 + b) + 2(c + b) +2 (pt-to-mpt connections) + c = [(c + 1 + b) + 2(c + b) + c] pt-to-pt connections + 2 pt-to-mpt connections.
If we compare the two protocols, we find the number of BUSs/LESs, the connections between the AHs/EDs and the LECSs, and the pt-to-mpt connections in the LESs/BUSs are increased linearly with the number of emulated LANs (ELANs). In the IPOA, they are constant.
Hence, the MPOA+ protocol reduces the number
of pre-established connections. In addition, the more kinds of the ELANs, the more complex we implement the LANE protocol in the MPOA.
4. Conclusions
In the MPOA protocol, the LANE is adopted for intra-Communication. However, the efficiency of the LANE will influence the performance of
the intra-Communication and the
inter-Communication. The increase in the speed of traditional networks has made it necessary to extend the functions of the IPOA to edge devices and use the IPOA protocol for the
intra-Communication. In this paper, we
benchmark the performance of the LANE and the IPOA and analyze the results to support our
arguments. A modified protocol, MPOA+, is
proposed to improve the performance. Then we explain the few changes needed in the MPOA
protocol. Simulation results show the MPOA+
can significant reduce the loads of the ARP server and the MCS/BUS server, decrease the time delay for making a connection, and lessen the total number of SVC connections.
References
[1] Jon Postel, “Internet Protocol DARPA Internet Program Protocol Specification,” IETF Network Working Group, RFC 791﹐September 1981
[2] David C. Plummer, “An Ethernet Address Resolution Protocol,” IETF Network Working Group, RFC 826﹐November 1982.
[3] T. Bradley ﹐C. Brown ﹐“ Inverse Address Resolution Protocol,” IETF Network Working Group, RFC 1293, Wellfleet Communications, Inc.﹐January 1992.
[4] David E. McDysan and Darren L. Spohn, ATM theory and Application, McGraw-Hill﹐1995.
[5] David Ginsburg ﹐ATM solution for enterprise internetworking﹐Addison-Wesley﹐1996.
[6] ATM Forum, ATM User-Network Interface (UNI) Specification – version 4.0, ATM Forum Specification, 1996.
[7] W. Richard Stevens﹐TCP/IP Illustrated Volume I – The Protocols﹐Addison-Wesley, 1994.
[8] J. Wroclawski, “The Use of RSVP with IETF Integrated Services,” IETF Network Working Group, RFC 2210﹐September 1997.
[9] Steven Berson﹐“Classical RSVP and IP over ATM,” USC Information Science Institute, Apr. 10﹐ 1996.
[10] Juha Heinanen﹐“Multiprotocol Encapsulation for ATM Adaptation Layer 5,” IETF Network Working Group, RFC 1483﹐Telecom Finland﹐July 1993.
[11] M. Laubach and J. Halpern, Classical IP and ARP over ATM, IETF Network Working Group, RFC
2225, April 1998.
[12] J. Mogul and S. Deering, Path MTU Discovery,
IETF Network Working Group, RFC 1191, Nov 1990.
[13] R. G. Cole and D. H. Shur, ATM Signaling Support for IP over ATM, IETF Network Working Group, RFC 1755, February 1995.
[14] ATM Forum ﹐“ Multi-Protocol Over ATM Version 1.0,” Multiprotocol Sub-Working Group ﹐ ATM Forum Specification, May 29 1997.
[15] Anthony Alles ﹐“ ATM Internetworking, ” Engineering InterOp﹐Las Vegas﹐May 1995.
[16] Debanjan Saha﹐Dipak Ghosal, and H. Jonathan, “ A design for Implementation of the Internet Protocol in a Local ATM Network,”IEEE Magazine ﹐1994.
[17] ATM Forum, “ LANE version 2, ” LAN Emulation Sub-Working Group ﹐ATM Forum Specification, July 1997.
[18] C. Kent and J. Mogul, Fragmentation Considered Harmful, Proceedings of the ACM
SIGCOMM '87 Workshop on Frontiers in Computer Communication Technology, August 1987.
[19] Rick Jones﹐http://www.netperf.org//.
[20] Gung-Chou Lai and Ruay-Shiung Chang ﹐ “Support QoS in IP over ATM,” Proceedings of National Computer Symposium, Volume 3, F-21 - F.25, Taiwan, 1997.
[21] M. Perez﹐F. Liaw﹐A. Mankin﹐E. Hoffman﹐D. Grossman and A. Malis, “ATM Signaling Support for IP Over ATM,” IETF Network Working Group, RFC
1755﹐February 1995.
[22] R. Cole﹐D. Shur and C. Villamizar, “IP over ATM: A Framework Document, IETF Network Working Group, RFC 1932﹐April 1996.
[23] Wei Kuang Lai and Tzann-yuan Su﹐“The design and implementation of IP over ATM on Edge Device, ” Proceedings of National Computer Symposium, Volume 3﹐F-15 – F-20, Taiwan, 1997.
Table 1. The environment for performing benchmarks.
Host name Magic Sonic
Machine Sparc-10 Sparc-10
CPU number 1 1
Operating system SUNOS 4.1.3 SUNOS 4.1.3
ATM interface card
Fore SBA-200 Fore SBA-200
Supporting rate 155 (Mbps) 155 (Mbps)
Table 2. The transmission rates for the IPOA+ protocol and the LANE.
OC-3c 155.520 149.760 135.632 IPOA+ LANEv2 MTU=150 0 MTU=9,200 MTU=65,52 7 MTU=150 0 MTU=9,200 MTU=65,52 7 133.160 135.514 135.563 134.926 135.105 135.605 Line rate To ATM To AAL To LLC To IP 132.453 135.397 135.547 132.453 134.695 135.547 Ethernet Ethernet Ethernet LECS MPC LEC MPC LEC MPC LEC MPC LEC MPC LEC MPC LEC LES BUS BUS LES Ethernet Ethernet Ethernet LECS MPC LEC MPC LEC MPC LEC MPC LEC MPC LEC MPC LEC LES BUS BUS LES MPS LEC Routing function Plane-1 Plane-2 MPS LEC Routing function
IPOA 與 LANE的 效 能 比 較
0 50 100
0 10000 20000 30000 40000 50000 60000 70000
Socket Buffer Size(Byte)
B an d w id th ( Mb ps )
IPOA ( MTU=9180Bytes) LANE ( MTU=1500Bytes)
Figure 2. The performance benchmarks for the IPOA and the LANE.
0.00E+00 5.00E+04 1.00E+05 1.50E+05 2.00E+05 0 500 1,000 1,500 2,000 2,500 3,000 Bandwidth (Mbps) N u m b er o f in te rr u p ts (times/sec)
LAN Emulation (MTU=1500Bytes) IPOA (MTU=9200Bytes)
Figure 3. The total number of interrupts for the LANE and the IPOA in high-speed transmission.
LE HEADER DESTINATION ADDR
DESTINATION ADDRESS
PAYLOAD
LANEv2 Non-multiplexed Data Frame Format for IEEE 802.3/Ethernet Frames
0xAA 0xAA 0x03 0x00
0xAA 0xAA FRAME-TYPE
SOURCE ADDRESS
SOURCE ADDR TYPE/LENGTH
ELANE-ID
LE HEADER DESTINATION ADDR
DESTINATION ADDRESS
PAYLOAD SOURCE ADDRESS
SOURCE ADDR TYPE/LENGTH
LANEv2 Multiplexed Data Frame Format for IEEE 802.3/Ethernet Frames
0xAA 0xAA 0x03 0x00
0xAA 0xAA 0x08 0x00
Internetwork Layer PDU ( up to 2^16 - 9 octets) RFC 1483 LLC/SNAP Encapsulation for Routed IP PDUs
Internetwork Layer PDU ( up to 2^16 - 1 octets) RFC 1483 "Null" Encapsulation for Routed IP PDUs
0xAA 0xAA 0x03 0x00
0xAA 0xAA 0x884c
MPOA Tag
MPOA Tagged Encapsulation for IP Internetwork Layer PDU ( up to 2^16 - 9 octets)
Figure 5. The data packet of the IPOA+.
L M P T
l is size of LLC/SNAP and LANE Header. (LLC/SNAP = 8 octets) m is size of IP PDU
p is size of padding (p1 for IPOA+, p2 for LANEv2)
t is size of trailer (trailer = 8 octets)
Figure 6. The LLC/SNAP encapsulation.
Token Ring Ethernet Ethernet MPC IPC MPC IPC MPC IPC MPC IPC MPS IPC Routing function Ethernet Ethernet IPCS MPC IPC MPC IPC MPC IPC MPC IPC MPC IPC MPC IPC MPS IPC Routing function Plane-1 Plane-2 Token Ring IPOAS IPOAS IPOAS IPCS MPC IPC MPC IPC IPOAS MCS IPOAS
Connect Query and respond Rigister
Establish MPS-MPS control VCC
Establish MPC-MPS control VCC
Establish Shortcut VCC MPOA ARP Query and Response
Query and respond
Register Establish Data Direct VCC Establish Multicast Send VCC and
join the multicast tree Establish Control Direct, and Control
Distribute VCCs Rigister Time M PC IPCS M PS M PC Configuration Joining IASG Data transfer M PO A+ operation Configuration
Time IPC IPCS IPO AS M CS IPC
Joining IASG
Connection to MCS (optional)
Data transfer
Query and respond
IPOA ARP Query and Response
IPO A+ operation Time M PS IPCS M PS Configuration MPS-MPS control flows NHS
Figure 8. The MPOA+ message flow.
MPC Service Block
LANE Service Block
MPC+ Service Block IPC Service Block IPOARP Service Block
Figure 9. The relative function blocks for the MPOA protocol (left) and the MPOA+ protocol
(right). Ingress MPC+ Service Interface Egress MPC+ Service Interface Inbound IPC Service Interface Outbound IPC/IPOARP Service Interface IP.dst IS Remote ? Ingress Cache Hit ? Valid Shortcut ? Create Ingress Cache Entry
Count Frame Threshold Exceeded ? Ingress MPOA_VCC Service Interface Egress MPOA_VCC Service Interface Egress Cache Hit ? Perform Error Recovery Function (Purge) IP/IPX_PDU Out
Send Packet on IPC Packet Arrives on IPC VCCsc Yes No Yes Yes Yes No No No No VCCM P S Request Outstanding ? Send MPOA_ARP_REQ to MPS Yes Yes No IP/IPX_PDU or IP_ARP In Inbound IPOARP Service Interface IP_PDU/IPX_PDU IP_ARP VCCsc VCCsc
Put Into the Queue and Waiting to Send Inbound IPC Service Interface Outbound IPC Service Interface IP.dst Is Broadcast Address ? Inbound Cache Hit ? Valid Direct VCC ? Count Frame Inbound IPOA_VCC Service Interface Outbound IPOA_VCC Service Interface
Frame In Frame Out
VCCDirect Yes No Yes No No Yes Forward Packet to MCS VCCMCS VCCDirect/MCS Threshold Exceeded ? No VCCIPOAS Request Outstanding ? Send IPOA_ARP_REQ to IPOAS Yes Yes No Create Inbound Cache Entry Outbound Cache Hit ? Yes No VCCDirect/MCS
Figure 11. The flow chart of the IPC service block.
Frame Out Inbound IPOARP Service Interface Frame In Is IP_ARP_REQ ? Is IP_ARP_REP ? Discard the Packet Send IPOA_ARP_REP to IPOAS Inbound IPOA_VCC Service Interface Outbound IPOA_VCC Service Interface VCCIPOAS Inbound ARP Cache Hit ? Create Inbound Cache Entry Send IPOA_ARP_REQ to IPOAS No Yes Yes Yes No No Outbound IPOARP Service Interface VCCIPOAS Is IPOA_ARP_REQ ? Yes No Is IPOA_ARP_REP ? Discard the Packet No Oubound ARP Cache Hit ? No Yes Send IP_ARP_REQ to LANs Send IP_ARP_REP to LANs Send IP_ARP_REP to LANs Yes VCCIPOAS VCCIPOAS