Analysing and reducing the protocol overheads of MPOA in the Intra-IASG Communication Wei Kuang Lai and J. -M.

Chung High Speed Networks Laboratory Department of Computer Science and Engineering No. 70, Lien Hai Road, National Sun Yat-Sen University, Kaohsiung, Taiwan, ROC wklai@cse.nsysu.edu.tw Abstract The MPOA protocol adopts LANE for the Intra-IASG Communication. In this paper, we discuss the advantages and the disadvantages of MPOA and explain why LANE is a performance bottleneck in the Intra-IASG Communication and the Inter-IASG Communication. To verify our ideas, we first benchmark the performance of LANE and IPOA. The results show IPOA is more scalable than LANE when 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 edge devices. Hence, we propose the IPOA+ protocol to extend the functions of 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 functionality provided by MPOA+ is the same as MPOA so upper layers need not to have any changes. The MPOA+ protocol reduces signal traffic and needs fewer pre-established connections than the MPOA protocol. 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. 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]. On the top of Ethernet (with or without Logical Link Control (LLC) in the middle) or ATM, Internet Protocol (IP) is the most popular protocol [7-10].

To allow traditional networks communicate with ATM networks, two issues, the address resolution mechanism and the support of broadcast/multicast, need to be addressed. The ATM Forum adopts LAN Emulation (LANE) [1] and Multi-Protocol over ATM (MPOA) [2]. On the other hand, the IETF designs classical IP over ATM (IPOA) [3]. Before introducing them, we first explain four kinds of Address Resolution Protocols (ARPs). In traditional networks, the address resolution is between the IP layer and the MAC layer (IP_ARP). In LANE, the address resolution is between the ATM layer and the MAC layer (LE_ARP). In IPOA and MPOA, the
1

address resolution is between the ATM layer and the MAC layer (IPOA_ARP and MPOA_ARP).
LANE: The hosts on ATM networks emulate the MAC layer protocols of traditional networks. Hence, the software developed in traditional networks can run on ATM networks without knowing that protocols have been changed from traditional networks such as Ethernet networks or FDDI networks to ATM networks. This characteristic is called transparency. A LANE server (LES) is responsible for the address resolution. A Broadcast and Unknown Server (BUS) is responsible for broadcasting and multicasting. The host connected to LANE is called a LANE Client (LEC). Classical IP over ATM (IPOA): To implement IPOA, there are some standards proposed by the IETF and the ATM Forum we must follow [2-3][6][10][11-14]. IPOA also allows the software developed on the TCP/IP protocols to run on ATM networks without knowing the protocols have been changed from traditional networks to ATM networks. An ATM Address Resolution Protocol (ARP) Server is responsible for the address resolution. Multiprotocol over ATM (MPOA): MPOA is developed by the joint effort of the ATM Forum and the IETF [14-15]. The main purpose of MPOA is to integrate different protocols running on ATM networks (ex. IPv4 and IPX). The communication of MPOA consists of two kinds. The communication among hosts within the same IASG (Internet Address Sub Groups) is called the Intra-IASG Communication. Different groups are given different routing addresses. The communication among hosts of different IASGs is called the Inter-IASG Communication. For the Intra-IASG Communication, the MPOA protocol adopts the LANE (LAN Emulation) protocol and architecture as a basis [16-17]. For the Inter-IASG Communication, a router is required for classical IP. The MPOA protocol 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 hardware of MPOA include Edge Devices (EDs) which connect traditional networks and ATM networks, MPOA Hosts (MHs) which are connected to ATM networks directly, and MPOA Routers (MRs). The function blocks of the ED/MH consist of the MPC, the forwarding function, and the LAN emulation client (LEC). The MPC decides whether the communication is the Inter-IASG Communication or not. The function blocks of the MR consist of the MPOA server (MPS), the routing function, and the LEC. The MPS contains a Next Hop Server (NHS). The NHS supports the Next Hop Routing Protocol (NHRP) which is responsible for address resolution and is needed in establishing shortcuts across multiple MPSs [15]. There are six kinds of control flows in MPOA. They are between MPSs/MPCs and LECS, between MPSs/MPCs and LESs/BUSs, the pt-to-mpt connections in the

LESs/BUSs, between MPCs and MPSs for the MPOA resolution request/reply, between MPSs for internetwork layer routing and NHRP, and between MPCs for purging cache information. The last three kinds of control flows are not changed for MPOA and MPOA+ and will not be discussed in this paper. The connections needed in the LANE implementation of MPOA (the first three kinds of control flows) are shown in Figure 1 (a). There are two IASGs in this Figure. Every IASG has its own LES. For simplicity, the 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 broadcasting are not included. In the third Section, we will use Figure 1 again to compare the number of pre-established connections needed for MPOA and the modified protocol, MPOA+. There are several 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 MRs have the routing function. Hence, the scalability is increased and the complexity of management is decreased, and 3) The design of MRs and EDs/MHs are simplified. The MRs do not support the forwarding function. The routing speed of the MRs can be increased. The MPOA edge devices/hosts only support the forwarding function of the router. However, 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 Maximum Transfer Unit (MTU) size of AAL5 is more than 65535 bytes so actual MTU size of AAL5 is limited by the MTU size of LANE and IPOA. The default MTU size of the IPOA layer is 9180 bytes [11-12]. The default MTU size for the IPOA protocol can be set by running path MTU discovery [12] on IPOA hosts or by a pre-agreed value in the beginning. As to the MPOA protocol, because it adopts LANE which emulates the MAC layer and communicates with the MAC layer of the traditional networks directly via edge devices, the MTU size of MPOA is limited to 1500 bytes and can not be adjusted. In addition, although we increase the MTU size, the Protocol Data Unit (PDU) error rate increased is negligible because the error rate of ATM networks is very small and the help from TCP/IP layers for error corrections and retransmissions, 2) Many researchers have benchmarks on different ATM switches which show the speed of IPOA is more scalable than LANE when the link bandwidth increases and the speed of IPOA is about 2 4 times better than LANE in general [11][12][19]. This is because IPOA has less fragmentation of IP frames and thus less interrupts. Here, we will further explain the results. For LANE, its protocol stacks are shown in Figure 2 (a). Assume host A in the ATM network wants to communicate with host B in the LAN via an ATM switch and an edge device. There may be many ATM switches between host A and the edge device. Here

we use an ATM switch to represent them for simplicity. For IPOA, its protocol stacks are shown in Figure 2 (b). Also assume host A in the ATM network wants to communicate with host B in the LAN. We compare their protocol stacks and find they are different in some places. We show them by lines with arrows on both ends and mark them with Arabic numbers. For host A, the layer between the IP layer and the ATM layer is the LANE layer when we implement LANE and is the IPOA layer when we implement IPOA. Because the MTU size of the MAC layer is 1500 bytes and the MTU size of the IP layer is 9180 bytes, there are 6-7 times more interrupts between the IP layer and the LANE layer ((1) in Figure 2 (a)) when we implement LANE than the IP layer and the IPOA layer ((1) in Figure 2 (b)) when we implement IPOA. In our benchmarks in Section 2.1, we also find there are a lot more retransmissions in the implementation of LANE when the CPU speed is not fast enough. The number of interrupts between the LANE layer and the ATM AAL5 layer for LANE ((2) in Figure 2(a)) is also 6-7 times more than the number of interrupts between the IPOA layer and the ATM AAL5 layer for IPOA ((2) in Figure 2 (b)). Note that the interfaces between the ATM layer and physical layer are in general implemented by hardware in which speed is less critical. As to the bridge in the LANE implementation and the router in the IPOA implementation, we can also count their interrupts in a similar manner although we know a router has to do more work per packet than a bridge. For the bridge, there are interrupts between the LANE layer and the AAL5 layer ((3) in Figure 2 (a)) and between the LANE layer and the MAC layer ((4) in the Figure 2 (a)). For the router, there are interrupts between the IP layer and the IPOA layer ((3) in Figure 2 (b)), the IPOA layer and the AAL5 layer ((4) in Figure 2 (b)), and the IP layer and the MAC layer ((5) in the Figure 2 (b)). From the above discussion, the number of interrupt in the bridge is also about 1.5 times more than the number of interrupts in the router, 3) LANE has the higher encapsulation overhead than IPOA given the greater LANE header size compared to IPOA, 4) The architecture of the MPOA protocol is complex and not easy to implement. Many pre-established connections are needed. LANE has to map between IP and the ATM layer and IP and the MAC layer while IPOA only has to map between IP and ATM layer, and 5) It is hard to provide Quality of Service (QoS) because LANE is the MAC layer protocol (layer 2). New protocols such as IPv6 and RSVP provide some degree of QoSs (Quality of Services). IPOA allows us to extend QoSs of those protocols to LANs, To improve the performance of MPOA, we extend the functions IPOA to edge devices, IPOA+, and modify the MPOA protocol. The modified MPOA protocol is called the MPOA+ protocol. Note that for the MPOA+ protocol, the functionality provided is identical to the MPOA protocol. The software developed on top of TCP/IP layers can run on ATM networks without knowing that networks have been changed from traditional networks to ATM networks which is just as LANE, IPOA, and MPOA. There are several major advantages of

MPOA+. First, we have the ability to send larger frames and thus reduce interrupts. Second, we have the lower encapsulation overhead. Third, we reduce signalling traffic in creating shortcuts and the number of pre-established connections. The MPOA+ protocol does not need to implement the LANE protocol and thus the implementation of the MPOA+ protocol is simplified. As a result, the operations of the MPOA+ protocol for creating shortcuts and the number of pre-established connections are also greatly simplified. In addition, the MPOA+ protocol can benefit from researches for providing Quality of Services (QoSs) in TCP/IP networks [8][20]. The paper is organized as follows. Section 2 is the motivation of the paper. In this Section, we benchmark the performance of IPOA and LANE and compare the differences in establishing shortcuts between MPOA and MPOA+. The results suggest we extend the functions of the IPOA protocol to edge devices and design a modified 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, which is called the IPOA+ protocol. Then we discuss the message flows and the necessary changes in the MPOA protocol. We also compare the number of pre-established connections needed in the MPOA protocol and the MPOA+ protocol. Section 4 is the Conclusions. 2. Motivation In this Section, we perform benchmarks for the LANE protocol and the IPOA protocol [11][21-22]. We also explain why IPOA has better performance than LANE. We then compare the differences in pre-established connections between MPOA and MPOA+. 2.1 The benchmarks of LANE and IPOA In this subsection, we benchmark the performance of LANE and IPOA by using Netperf [19] which is a performance software. We simulate the TCP traffic. Two SUN Sparc 10 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 size of IPOA is set to be 9180 bytes and the MTU size of LANE is set to be 1500 bytes. Figure 3 shows the bandwidths for different buffer sizes of sockets. From the Figure, we find that the performance of IPOA is about 50% more than LANE for buffer sizes over 33000 bytes. The performance differences can be explained by Figure 4. Because we can have a larger MTU size in IPOA, the number of interrupts needed for IPOA is far less than the number of interrupts for LANE. The hosts need to be fast enough in processing interrupts when they send or receive frames by 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 IPOA and 11037 interrupts/sec for LANE. Hence, both IPOA and LANE can not achieve the expected bandwidths. However, MPOA is 50% better than LANE when the

buffer sizes are over 33000 bytes. 2.2 The differences in establishing shortcuts We explain in detail how MPOA and MPOA+ establish their shortcuts and transmit IP frames from local hosts to destinations via the edge devices. For LANE in MPOA, Figure 5 shows the four phases of the connection establishment. In the first phase, the local host (LH1) issues an IP_ARP_REQ to get the MAC address of the destination (Dst). The edge device forwards the request to the BUS and the BUS broadcasts the request to the destination. The destination can respond to the request by sending a reply to the edge device via the BUS before a direct VCC is established from the destination to the edge device. The destination can also query its LES by issuing a request, LE_ARP_REQ, to get the ATM address of the edge device and respond to the ARP request by establishing a DDVCC (Data Direct VCC) from the destination to the edge device. Here, we assume the ARP reply is sent to the edge device via the BUS for simplicity. When the loads on the BUS are not high, the total delay for establishing a shortcut by sending the ARP reply through the BUS is less than the total delay for establishing a shortcut by sending the ARP reply through the VCC. In the second phase, the LH-1 gets the MAC address of the destination and begins to send frames to the edge device. The edge device issues an LE_ARP_REQ to its LES to get the ATM address of the destination so the edge device can connect a DDVCC from the edge device to the destination. Eventually, the edge device will find a DDVCC has also been established from the destination to the edge device. Before the DDVCC is established, frames are sent to the destination via the BUS. After the DDVCC is established, we begin the third phase. The edge device sends a flush message to the destination via the BUS and the destination responds to the flush message by an ACK message via the LES. In the third phase, frames from the LH-1 are buffered in the edge device or discarded. In the final phase, the edge device forwards the frames from the LH-1 to the destination directly. Figure 6 shows the three phases of the MPOA+ operation. In the first phase, the LH-1 issues an IP_ARP_REQ to get the MAC address of the destination. The edge device then transmits an IPOA+_ARP_REQ to the IPOAS to get the ATM address of the destination. After the edge device receives a response, the edge device sends an IP_ARP reply which includes the MAC address of the edge device to the LH-1. In the same time, an IPOA+ VCC is established from the edge device to the destination. Before the IPOA+ is established, if there is a MCS, we send the frames from the LH-1 to the edge device and the edge device forwards the frames to the destination via the MCS. If we do not implement the MCS, we just buffer the frames in the edge device. Then in the third phase, the frames are sent from the LH-1 to the edge device and the edge device forwards the frames to the destination by the IPOA+ VCC. 3. The MPOA+ protocol architecture

Results from the last Section suggest the need to extend the functions of IPOA to edge devices. Under the current IPOA standard, the edge device does not implement the IPOA protocol. In this paper, we propose the necessary changes for the IPOA protocol and the MPOA protocol without influencing the functionality provided by the MPOA protocol. The idea of the proxy server for implementing IPOA in the edge device is also adopted here [23]. The modified IPOA protocol is used to replace the functionality of LANE for the Intra-IASG Communication in MPOA. 3.1 The IPOA+ protocol The IPOA+ protocol consists of several parts. They are explained as follows. MPOA Server (MPS): The logical component of a server which includes an NHS. IPOA Configuration Server (IPCS): The IPCS provides information to the IPOA clients or the MPS. The information includes the Type-Length-Value encoding (TLV), the ATM address of the IPOA server, the ATM address of the MPS, etc. The TLV will indicate whether an IPOA client is an MPC, an MPS, or both. 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. Unlike the LANE Server (LES) which could have many LESs within an IASGs and provides the address resolution function between the MAC address and the ATM address, there is only one IPOAS in an IASG and 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 in their IPOAS. Each IPC registers its related information, which includes the IP address and the ATM address. Each 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. 3.2 Message flows The message flows of the MPOA+ protocol are shown in Figure 7. The upper half is the operation of the IPOA+ and the lower half is the operation of 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 from the IPOAS to all IPCs are established. The connections between the IPC and the MCS and the registration from the MPC to the MCS are optional and needed only if the multicast communication is supported. The IPC then makes an IPOA+_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 an MPOA_ARP 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.3 The service blocks of the MPOA+ protocol The service blocks of the MPOA+ protocol for the MH/ED are shown in Figure 8. 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 service block can be viewed as part of the IPC service block. We only show the flow diagram of an MPC+ service block here (Figure 9). The flow diagram of an IPC service block and an IPOARP service block can be drawn similarly [24]. 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 of the PDU 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. An MPOA_VCC service interface is the interface we call for establishing an MPOA VCC connection and transmitting or receiving PDUs via a established connection. 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 pre-defined 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. 3.4 Comparisons between MPOA+ and MPOA for the number of pre-established connections

The IPOA implementation of the MPOA+ protocol is shown in Figure 1 (b) which does not implement the function of LANE. The Figure shows 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 IPCs are not included. There are two IASGs in the Figure. From Figure 1 (a) and Figure 1(b), we can count the total number of hosts involved and compare the total number of connections for LANE and IPOA+. The variables are assumed as follows: Number of Configuration Servers = a (1) Number of MPOA Routers = b (1) Number of MPOA MHs/EDs = c (1) Number of kind of ELANs = d (1). We have the following equations for the MPOA protocol. The total number of hosts = the number of LECSs + the number of MRs + the number of MHs/Eds + the number of BUSs/LESs = a + b + c + 2d. The total number of connections for LANE = the connections between MHs/EDs and LECSs + the connections between LECSs and LESs + the connections between MHs/EDs and LESs/BUSs + the pt-to-mpt connections in LESs/BUSs = (c + b) + ad + 2(c + b) + 2d (pt-to-mpt connections) = [(c + b) + ad + 2(c+b)] 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 IPCSs + the number of MRs + the number of MHs/Eds + the number of MCSs/IPOAS = a + b + c + 2. The total number of connections for IPOA+ = the connections between MHs/EDs and IPCSs + the connections between IPCSs and the IPOAS + the connections between MHs/EDs and the IPOAS/MCSs + the pt-to-mpt connections in the IPOAS/MCSs = (c + b) + a + 2(c + b) +2 (pt-to-mpt connections) = [(c + b) + a + 2(c + b)] 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 LECSs and LESs, and the pt-to-mpt connections in LESs/BUSs are increased linearly with the number of emulated LANs (ELANs). In IPOA, they are constant with the number of ELANs. 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 MPOA. 4. Conclusions In the MPOA protocol, LANE is adopted for the Intra-IASG Communication. However, the efficiency of LANE will influence the performance of the Intra-IASG Communication and the Inter-IASG Communication. The increase in the speed of traditional networks has made it necessary to extend the functionality of IPOA to edge devices and use the IPOA protocol for

the Intra-IASG Communication. To support our argument, we benchmark the performance of LANE and IPOA and analyse the results. We also compare the differences in signalling traffic for establishing shortcuts. Thus, a modified protocol, MPOA+, is proposed to improve the performance. Then we explain the few changes needed in the MPOA protocol and the reduction in pre-established connections. The functionality provided by MPOA+ is the same as MPOA so upper layers need not to have any changes. 5. Acknowledgements

The authors would like to thank the anonymous referees for their constructive comments. This research is supported in part by National Science Council of Taiwan, ROC, under contract NSC 87-2213-E-110-005.

10

23 Lai, Wei Kuang., and Su, Tzann-yuan.: The design and implementation of IP over ATM on Edge Device. Proceedings of National Computer Symposium, Volume 3 F-15 F-20, Taiwan, 1997. 24 Lai, Wei Kuang., and Chung, J. -M..: Analyzing and reducing the protocol overheads of the MPOA in the intra-Communication. TANET99, 1999, Taiwan.

11

6. References 1 Postel, Jon.: Internet Protocol DARPA Internet Program Protocol Specification. IETF Network Working Group, RFC 791 September 1981 2 Plummer, D.C.: An Ethernet Address Resolution Protocol. IETF Network Working Group, RFC 826 November 1982. 3 Bradley, T., and Brown C.: Inverse Address Resolution Protocol. IETF Network Working Group, RFC 1293, Wellfleet Communications, Inc. January 1992. 4 McDysan, David E., and Spohn, Darren L.: ATM theory and Application (McGraw-Hill 1995). 5 Ginsburg, David.: 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 Stevens W. Richard.: TCP/IP Illustrated Volume I The Protocols (Addison-Wesley, 1994). 8 Wroclawski, J.: The Use of RSVP with IETF Integrated Services. IETF Network Working Group, RFC 2210 September 1997. 9 Berson Steven.: Classical RSVP and IP over ATM. USC Information Science Institute, Apr. 10 1996. 10 Heinanen Juha.: Multiprotocol Encapsulation for ATM Adaptation Layer 5. IETF Network Working Group, RFC 1483 Telecom Finland July 1993. 11 Laubach M., and Halpern, J.: Classical IP and ARP over ATM. IETF Network Working Group, RFC 2225, April 1998. 12 Mogul, J., and Deering, S.: Path MTU Discovery. IETF Network Working Group, RFC 1191, Nov 1990. 13 Cole, R. G., and Shur, D. H.: 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 Alles Anthony.: ATM Internetworking. Engineering InterOp Las Vegas May 1995. 16 Saha Debanjan., Ghosal, Dipak., and Chao, H. J.: A design for Implementation of the Internet Protocol in a Local ATM Network. IEEE International Conference on Communications, Volume 3, 1326-1330, May 1994. 17 ATM Forum.: LANE version 2. LAN Emulation Sub-Working Group ATM Forum Specification, July 1997. 18 Kent, C., and Mogul, J.: Fragmentation Considered Harmful. Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in Computer Communication Technology, August 1987. 19 Jones Rick.: http://www.netperf.org//. 20 Lai, Gung-Chou., and Chang Ruay-Shiung.: Support QoS in IP over ATM. Proceedings of National Computer Symposium, Volume 3, F-21 - F.25, Taiwan, 1997. 21 Perez M., Liaw F., Mankin A., Hoffman E., Grossman., D., and Malis, A.: ATM Signaling Support for IP Over ATM. IETF Network Working Group, RFC 1755 February 1995. 22 Cole R., Shur, D., and Villamizar, C.: IP over ATM: A Framework Document, IETF Network Working Group. RFC 1932 April 1996.

Figure 1. The MPOA protocol (a) and the the MPOA+ protocol (b). Figure 2. The network architecture of LANE (a) and IP over ATM (b).
Figure 3. The performance benchmarks for IPOA and LANE. Figure 4. The total number of interrupts for LANE and IPOA in high-speed transmission. Figure 5. The four phases for establishing the shortcut in MPOA.

Figure 6. The three phases for establishing the shortcut in MPOA+.

Figure 7. The MPOA+ message flow. Figure 8. The relative function blocks for the MPOA protocol (left) and the MPOA+ protocol (right).

Figure 9. The flow chart of the MPC+ service block.

12

LES

LES

MPC IPC
SAOPI SAOPI

IPC

MPC

IPC

IPCS

Figure 1. The MPOA protocol (a) and the the MPOA+ protocol (b).
Host A Higher Layer Protocols (1) IP/IPX etc. LANE
UNI Signaling

Host B (4) Higher Layer Protocols IP/IPX etc. LANE (3)

UNI Signaling

(2)

AAL5 Layer ATM Layer Physical Layer

ATM Layer Phy Layer ATM Layer Phy Layer

AAL5 Layer ATM Layer Physical Layer

MAC Layer

MAC Layer

Physical Layer

Physical Layer

ATM Switch

(a)

Bridge

LAN Host
User Applications IP Layer

User Applications IP Layer

)3(

IP Layer
IP over ATM AAL 5 Layer
)5( )2(

IP over ATM AAL5 Layer ATM Layer Physical Layer

MAC Layer Physical Layer

MAC Layer

ATM Layer Physical Layer

ATM Layer Physical Layer

Physical Layer (Ethernet)

ATM-attached Host

ATM Switch
)b(

Router with IP over ATM

LAN Host

Figure 2. The network architecture of LANE (a) and IP over ATM (b).

Bandwidth

Figure 3. The performance benchmarks for IPOA and LANE.

00007

00006

SCM

)setyB0051=UTM ( ENAL

00005

SAOPI

)setyB( eziS reffuB tekcoS

00004

00003

)setyB0819=UTM ( AOPI

00002

)a(

CPM

CPM

CEL

CEL

)4(

00001

noitcnuf gnituoR

SCEL

SPM

CEL

)1(

05 ( M 001 b p s )

CEL CEL CEL CEL CPM CPM CPM

CPM

BUS

BUS
MPC IPC IPC MPC MPS IPC
Routing function

MPC

MPC IPC

(b)

13

Figure 4. The total number of interrupts for LANE and IPOA in high-speed transmission.

000,3

005,2

000,2

005,1

Bandwidth

14
)setyB0029=UTM( AOPI
)spbM(

)setyB0051=UTM( noitalumE NAL

000,1

005

Number of interrupts

00+E00.0 ( t i 50+E00.1 m e s / s e 50+E00.2 c )

LE_ARP_REQ IP_ARP_REP LES LH 1 Edge Device IP_ARP_REP IP_ARP_REQ IP_ARP_REP IPARP IP_ARP_REQ BUS IP_ARP_REQ Dst LE_ARP_REP

(a)

frames

LE_ARP_REP LE_ARP_REQ

LH 1

LES Edge Device

DDVCC Setup

frames

frames frames

frames
Dst

frames
BUS

(b)

flush LH 1 Edge Device frames LES

flush

Dst flush flush BUS

(c)

frames LES Edge Device frames frames Data Direct VCC Dst

LH 1

BUS
(d)

Figure 5. The four phases for establishing the shortcut in MPOA.

15

IP_ARP_REP

IPOA+ _ARP_REP

LH 1 IP_ARP_REQ

IPOAS IPOA +_ARP_REQ IPOA+ VCC Edge Device Setup

Dst

(a)
Before the direct VCC is established, frames can be buffered in the edge device , transmitted through the MCS, or discarded.

frames

LH 1 Edge Device frames

IPOA+ VCC Setup

frames frames

frames Dst frames

MCS

(b)
frames LH 1 Edge Device frames frames Dst IPOA+ VCC

(c)

Figure 6. The three phases for establishing the shortcut in MPOA+.

IPOA+ operation

Time

IPC Query and respond

IPCS

IPOAS

MCS

IPC

Configuration Rigister Joining IASG Establish Control Direct, and Control Distribute VCCs Connection to MCS (optional) Rigister Establish Multicast Send VCC and join the multicast tree IPOA+ ARP Query and Response Data transfer Establish Data Direct VCC

MPOA+ operation

Time

MPS Query and respond

IPCS

MPS

Configuration MPS-MPS control flows Connect Establish MPS-MPS control VCC

Time

MPC Query and respond

IPCS

MPS

NHS

MPC

Configuration Register Joining IASG Establish MPC-MPS control VCC MPOA+ ARP Query and Response

Data transfer

Establish Shortcut VCC

Figure 7. The MPOA+ message flow.

16

MPC Service Block

MPC+ Service Block IPC Service Block IPOARP Service Block

LANE Service Block

Figure 8. The relative function blocks for the MPOA protocol (left) and the MPOA+ protocol (right).
IP/IPX_PDU or IP_ARP In IP/IPX_PDU Out

Ingress MPC+ Service Interface

Egress MPC+ Service Interface

IP_ARP

IP_PDU/IPX_PDU

No

No

No

No

Inbound IPOARP Service Interface

Inbound IPC Service Interface

Outbound IPC/IPOARP Service Interface

Send Packet on IPC

Packet Arrives on IPC

Figure 9. The flow chart of the MPC+ service block.

csCCV

SPM ot QER_PRA_AOPM dneS

? gnidnatstuO tseuqeR

Yes

Yes

VCCMPS

? dedeecxE dlohserhT

No

VCCsc

Ingress MPOA_VCC Service Interface

Egress MPOA_VCC Service Interface

)egruP( noitcnuF yrevoceR rorrE mrofreP

No Yes

? tiH ehcaC ssergE

? tuctrohS dilaV emarF tnuoC

yrtnE ehcaC ssergnI etaerC

? tiH ehcaC ssergnI

Yes

Yes

Yes

? etomeR SI tsd.PI

VCCsc

17