Internet Draft Jun Ogawa Expires February 1998 (Fujitsu Laboratories LTD.) Yao-Min Chen (Fujitsu Laboratories of America INC.) August 1997 Responder-Initiated Shortcut Path Protocol (RISP) Status of This Memo. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (WE West Coast). Abstract This memo describes a peer-to-peer protocol to set up shortcut paths in an environment where an internetworking (L3) protocol, such as IP, overlays a link-layer (L2) protocol such as ATM. In such a network, L3 routing is the default mechanism for data transfer but it is also possible to set up direct L2 paths such as ATM VCs, that bypass L3 routing, so as to expedite the transfer of data. The protocol described in this memo can be applied as an inter-LIS (Logical IP Subnetwork) shortcut protocol when an L2 subnetwork is configured into multiple LISs. It can also be used as an independent protocol to set up direct L2 paths. In this way, it operates without L2 address resolution servers and allows the use of conventional routers (those without address resolution function) in the network. Therefore, it is useful for networks that have no available L2 address resolution service. 1. Introduction The protocol described in this memo may be applicable to general Jun Ogawa, Yao-Min Chen [Page 1] INTERNET-DRAFT RISP Expires Feb. 1998 internetworking of Layer-2 (L2) and Layer-3 (L3) technologies. However, our current implementation is only for IP over ATM (IPOA) networks. Therefore, we describe the protocol specifically for IPOA, so that we can be truthful to what has already been implemented. Also, the protocol can be explained in familiar terms. IPOA provides an environment where two network technologies, IP and ATM, coexist in a physical network. Since both technologies provide mechanisms to route data across the network, many possibilities exist as how to efficiently integrate the benefits of IP and ATM routing mechanisms to achieve high-speed transfer of data. A popular paradigm is to configure a physical NBMA subnetwork (e.g., ATM subnetwork) into multiple logical IP subnetworks (LISs) and uses an address resolution protocol to provide IP-to-ATM address translation service. RFC1577 [1] describes the concept of LIS and the ATMARP protocol. The protocol is a client-server type of protocol where, within a LIS, each station registers its ATM address with an ATMARP server. When the station needs to talk to another station on the same LIS, it queries the server for the ATM address of the station, so as to set up a VC connection. To talk to stations outside its LIS, a station can only rely on the IP routers to forward the datagrams in a hop-by-hop fashion. NHRP[2] intends to eliminate the extra hops when datagrams are routed between stations located on different LISs. It is still a client-server type of protocol but a server can respond to clients located not only within the LIS but also outside the LIS of the server. In inter-LIS case, an address resolution query message travels hop-by-hop towards the IP address whose ATM address needs to be resolved. A router, that contains information to resolve the IP-to-ATM address mapping, intercepts the query message and responds to the sender of the message. The resolved ATM address is the one of the destination if it is located on the same ATM subnetwork. Otherwise, it is the ATM address of the egress router to the destination. Upon receiving the resolved ATM address, a station can use ATM signaling to set up a VC to the station having the ATM address. If such a VC is between stations on different LISs, intermediate router hops are eliminated. Therefore, such a VC is referred to as a shortcut path. A requirement of the NHRP protocol is that IP routers need to also be equipped with the address resolution function. In particular, a router needs to maintain a database for address resolution, which registers the IP-to-ATM address mappings of the stations within its LIS, as well as cached resolution results from previous queries. If there are multiple routers within the LIS, each of them needs to be configured with address resolution capability. In addition, a new protocol, Server Cache Synchronization Protocol (SCSP) [4] needs to be used to maintain the coherency of the entries stored at Jun Ogawa, Yao-Min Chen [Page 2] INTERNET-DRAFT RISP Expires Feb. 1998 the routers. The protocol described in this memo is a peer-to-peer protocol rather than a client-server type. Consider a station, called the "requester", that intends to set up a VC with a remote station. It sends a connect request message, called Callback Request, towards the station. The message is routed by way of transit IP routers. By routing this way, the message will reach the remote station if it is located on the same ATM subnetwork as the requester. Otherwise, the message will be intercepted by the egress router for the remote station. Let us call the destination station or egress router the "responder" of the message. Upon receiving the Callback Request message, the responder evaluates whether to accept the connection request based on its local policy and resources. If the decision is to accept, it uses ATM signaling to set up a VC back to the requester. It can do so because the protocol requires that the Callback Request message contains the ATM address of the requester. Since the shortcut path is set up from the responder, we call the protocol the Responder-Initiated Shortcut Path (RISP) protocol. Note that RISP combines IP and ATM routing mechanisms in an efficient way, in the following sense. When a shortcut path is needed, IP routing is used only once to send the Callback Request to the the responder. Then ATM routing takes over to set up the shortcut path. In contrast, NHRP requires using IP routing twice, once for sending the address resolution request and once for sending the reply. Whether this efficiency translates into shorter average setup latency is currently under investigation. However, one key feature of RISP is that conventional routers, without address resolution function, can still participate in the protocol. The only requirement is that they can forward RISP control messages (which are L3 packets in LLC/SNAP encapsulation the same as the encapsulation of NHRP packets described in [2]). Only the end stations and ingress and egress routers, that intend to use shortcut paths, need to be upgraded with the new protocol. Hence RISP provides a potentially less costly migration path to a fully shortcut-path capable network. As to the applicability of the protocol, it works well with existing address resolution protocol such as ATMARP or the intra-LIS part of NHRP. The existing protocol can be used for intra-LIS VC setup, while RISP can then be used as a shortcut path protocol that establishes VCs that cut across the LIS boundaries (i.e., inter-LIS VCs). It is also possible to use the RISP protocol by itself. We have an experimental network that runs without any address resolution server. This possibility distinguishes the protocol in its independence from L2 address resolution servers. Therefore, RISP can be used in networks that have no L2 address resolution services. The network uses a particular configuration of host interface at Jun Ogawa, Yao-Min Chen [Page 3] INTERNET-DRAFT RISP Expires Feb. 1998 the routers. It does not follow the traditional configuration of LISs. Instead, each host is attached to its router via a point-to-point interface, and recorded by the router as a host route entry in its routing table. Routers exchange their host routes simply via the routing protocol. In this way, this shortcut-capable network runs only routing protocol and RISP; the ARP mechanism is not necessary; and a station does not need to maintain any particular address resolution database other than the regular routing table. Therefore, it is not required to have other ARP-related mechanisms, such as SCSP. Further details on the configuration can be found in Section 3.2. 2. Terminology A "RISP host" refers to a host machine that can process RISP messages. Where there is no ambiguity, we will refer to a RISP host simply as a "host". A "RISP router" is a router performing conventional forwarding/routing functions as well as being capable of handling RISP messages including Callback Request, Callback Reply and Error Indication. The routers described in this memo, unless otherwise mentioned, refer to RISP routers. A "RISP station" is a RISP host or router. A "requester" is a RISP station that sends out a Callback Request message. A "target address" is the IP address in the destination address field of a Callback Request message. A "responder" is a RISP station that replies to a Callback Request. The responder is the station with the target address of the Callback Request, if the station is located in the same NBMA subnetwork (i.e., ATM subnetwork) as the requester. Otherwise, it is the egress router for the target address. A "routed path" is a datagram routing path that goes through one or more routers. A "shortcut path" is a switched virtual circuit between a pair of RISP stations that, in their default mode, would communicate with each other using a routed path. In the remainder of this memo, a shortcut path is set up by the RISP protocol. At a station, the data structure for maintaining information about a shortcut path is an L3 entity that is identified by the target address. Several shortcut paths can map to the same physical VC (when the responders corresponding to these shortcut paths are the same egress router), which is an L2 entity. 3. Protocol Overview Under normal condition, the operation of the protocol proceeds in the following four phases. (1) In the Request phase, the requester Jun Ogawa, Yao-Min Chen [Page 4] INTERNET-DRAFT RISP Expires Feb. 1998 sends a Callback Request message along a routed path towards the target address; the message is eventually received by the responder. (2) In the VC Setup phase, a VC directly connecting the responder to the requester is either found or established by the responder. (3) In the Callback phase, the responder sends a Callback Reply message along the VC to the requester. (4) In the Data Transmission phase, the data packets destined for the target address are transmitted by the requester over the shortcut path. Fig.1 illustrates the four phases. +-------+ +-------+ +-------+ +-------+ | src |-------|Router |------|Router |------| dst | | | +-------+ +-------+ | | +-------+ +-------+ (1) ------->------------->--------------> Callback Request (hop by hop) (2) <==================================== Establishing a direct VC (3) <------------------------------------ Callback Reply (4) ------------------------------------> Data transmitted over the VC Fig.1 Typical usage of RISP. Note that nowhere in the above four phases an address resolution server is needed. It is also apparent that: 1) a RISP station does not need to know the ATM address of its responder before initiating communication 2) a RISP router does not need to maintain a database for the purpose of address resolution, and 3) a responder can refuse a callback request. Below, we describe the protocol in more details. We specify the basic mechanism (called Core RISP Mechanism) in Section 3.1, which is the only part needed when using RISP as an inter-LIS shortcut protocol. As we allured to earlier, it is possible to apply the RISP without any address resolution server (particularly, ATMARP server). Section 3.2 gives such an example, which is a network implementing Core RISP mechanism as well as a specific configuration of host interface at the routers. 3.1 Core RISP Mechanism When a RISP station decides that a shortcut path is more suitable for a data flow than the routed path, it sends a Callback Request Jun Ogawa, Yao-Min Chen [Page 5] INTERNET-DRAFT RISP Expires Feb. 1998 message to the target address along the routed path. The message has the IP and ATM addresses of the requester station. It also has a Request ID to uniquely identify the message. The message format of Callback Request is described in Section 4.1. When the responder receives the Callback Request, It evaluates its policy and local resources to decide whether to accept the request. If it decides not to accept the request, it sends Callback Reply along the routed path back to the requester. The Callback Reply MUST have proper error code indicating the request is rejected. Otherwise, it checks if it has a VC between itself and the requester. It can choose to use an existing VC (if one exists) or it can set up a new one, using the ATM signaling. This signaling is possible because the ATM address of the requester is contained in the Callback Request. Example 1: The following example shows a VC setup and then the reuse of an existing VC. ATM(RISP) Ether ----------------------><--------------> DD.EE.FF.00/24 HostA ========== router --+-----+-- (Shortcut) | | HostB HostC At first, HostA has a data flow to HostB. It decides that a shortcut path is suitable for the flow and sends Callback Request with target address HostB. The router, which is an egress router and responder in this example, intercepts the Request and establishes the shortcut path between itself and HostA. Later, HostA has another flow, to HostC, that is suitable to use a shortcut path. HostA sends Callback Request towards HostC. However, when the Request was intercepted by the router, it knows that it already has a shortcut path to HostA and so sends back Callback Reply along the existing path. The detailed format information of Callback Reply is described in Section 4.2. If a Callback Request message contains an error, the responder sends an Error Indication message with appropriate Error Code defined in [2]. As soon as a VC between a requester and responder is established (in the case of a new VC) or is identified (in the case of re-using an existing VC), the responder sends an Callback Reply along the VC to the requester. The Callback Reply message contains the target Jun Ogawa, Yao-Min Chen [Page 6] INTERNET-DRAFT RISP Expires Feb. 1998 address, copied from the Callback Request message, as well as the IP and ATM addresses of the responder. The Callback Reply also has a Request ID which is identical to the Request ID of the Callback Request. Upon receiving a Callback Reply with a target address, the requester checks if the Request ID of the message is the same as the Request ID of the Callback Request it issued for the target address. If it is a match, the requester associates the shortcut path (a VC) with the target address. It can then start transmitting the data packets, destined for the target address, over the shortcut path. Whether and when the requester can start receiving data packets from the shortcut path depends on implementation and, most likely, security consideration. To be secure, a Callback Request and its corresponding Callback Reply SHOULD only authenticate a shortcut path in one direction. To use the shortcut path in the opposite direction, another run of Callback Request and Reply is needed. However, when RISP is used just for inter-LIS communication and ATMARP is used for intra-LIS communication, a station MUST accept packets from any shortcut path because ATMARP does not authenticate a VC using the request and reply messages and it is impractical to distinguish whether a VC is set up by RISP or ATMARP. Note that a race condition may lead to duplicated shortcut paths, which happens when two stations communicating with each other and become requesters at the same time. The station with the smaller ATM address SHOULD terminate the VC that it signaled. Also note that the Callback Request and Reply messages are L3 packets. Their purpose in this protocol is to associate an L2 link (an existing VC between the requester and responder, or the new VC established by the responder) to the shortcut path requested by the requester. As to the establishment and termination of a VC, they SHOULD follow the procedures specified in RFC1755[5]. In particular, VC termination depends on the idle timer described in [5]. Now consider the case when the path establishment fails, which may occur because of lack of resources at the responder or some other link-layer problem (see Section 4.2 for a more thorough discussion). If the path establishment fails, the responder sends an Callback Reply along the routed path to the requester. At the requester side, it MUST keep waiting for the Callback Reply or Error Indication with the proper Request ID until a timeout period expires. When the timer expires, the requester retransmits the Callback Request message. The interval between the successive Callback Requests and the number of times for the retransmission are under study. Note that the interval and number are important consideration in an environment where not all stations are equipped with RISP capability and so sometimes a Callback Request may not get Jun Ogawa, Yao-Min Chen [Page 7] INTERNET-DRAFT RISP Expires Feb. 1998 responded at all. If the requester cannot acquire the shortcut path it requested, it MUST continue to use the default, routed path to send IP data packets. 3.2 Example of Using RISP as an Independent Protocol RISP can work without any address resolution server. For example, it can accomplish this through the network configuration described in this section. We refer to this particular configuration as RISP+. 3.2.1. Router Configuration When a VC is connected between a host and its router, the router ties the VC to a point-to-point (PtoP) interface and registers the host to its host route information base. We illustrate this in the example below. Example 2: We show an example of how host route information is configured. AA.BB.CC.1--ATM Interface of a router. /dev/atm0:0 :1 :2 :3 ------------------------------------------- | | | | ATM Subnetwork |VC |VC |VC |VC | | | | HostA | | | (AA.BB.CC.10) | | | HostB | HostD (AA.BB.CC.11) | (AA.BB.CC.13) HostC (AA.BB.CC.12) The routing table of the router has the following entries. HostA /dev/atm0:0 HostB /dev/atm0:1 HostC /dev/atm0:2 HostD /dev/atm0:3 /* End of Example */ The router advertises host route information to every host connected to the router via a PtoP interface. Note that in this configuration. routing information is maintained with the full 32-bit subnetwork mask. However, when advertising to routers outside the subnetwork, the host route information MAY be aggregated Jun Ogawa, Yao-Min Chen [Page 8] INTERNET-DRAFT RISP Expires Feb. 1998 and appeared as a network route. An example of such aggregation is described below. Example 3: Here we show a logical subnetwork consisting of two routers A and B and seven hosts a, b, ..., g. The hosts share the same 24-bit IP address prefix AA.BB.CC. Their host route information is aggregated as AA.BB.CC.00/24 when advertised to the outside of the subnet. <---AA.BB.CC.00/24---> --- Router A ---------- Route B --- | | | | | | | Host a,b,c,d Host e,f,g ->->->------------>->-> Sends each host as the host route information <---- -----> Sends as AA.BB.CC.00/24 (aggregated) /* end of Example */ 3.2.2. Host Configuration A host either sets a default router or uses the advertised host route information from the router that the host is attached to. The host is responsible for keeping alive the VC to the router. It is for further study about the mechanism to automatically register a host at the routing table of its router. At least this registration can be done manually. A host can use Callback Request to ask for a shortcut path to a station, attached to the same or a different router. If the latter station accepts the request and establishes the shortcut path, both sides use a PtoP interface to maintain the shortcut path. 3.2.3. The Operation of RISP+ When a shortcut path is needed, a RISP station sends Callback Request and follows the procedure listed in Section 3.1, wherever the target address is. 4. Messages The set of RISP packets includes Callback Request, Callback Reply and Error Indication. They use the same NBMA encapsulation as NHRP packets. Also, the same as in NHRP, the RISP packets contain a Fixed Part, a Mandatory Part, and an Extensions Part. In the Fixed Part, RISP requires a different protocol version number ar$op.version than NHRP. The number is pending on IETF assignment. Jun Ogawa, Yao-Min Chen [Page 9] INTERNET-DRAFT RISP Expires Feb. 1998 Currently we use number 2. Under the protocol version number, the RISP packet type ar$op.type is coded as follows. The packet type codes for Callback Request, Callback Reply and Error Indication are 1, 2 and 7, respectively. The Mandatory Part for Callback Request (resp., Callback Reply, Error Indication) is the same as in NHRP Resolution Resolution Request (resp., NHRP Resolution Reply, NHRP Error Indication), except some fields have RISP-specific value and interpretation which we will specify later in this section. The rule for an NHRP packet (NHRP Resolution Request, NHRP Resolution reply, or NHRP Error Indication) to use the Extensions Part is applied to the corresponding RISP packet. 4.1 Callback Request This message is used by a sender host to request a shortcut path. Unlike the NHRP Resolution Request, if the target address is located within the ATM subnetwork, the nearest router of the target address simply forwards this message to the host with the target address. If the target address is outside of the ATM subnetwork, the egress router MUST become the responder to answer this request and it MUST NOT forward this request outside the ATM subnetwork. The mandatory part of Callback Request is coded as described in Section 5.2.0.1 of [2]. Src Proto Len, Source NBMA Address, Source NBMA Subaddress and Source Protocol Address in the common header have the information about the requester, and Dst Proto Len and Destination Protocol Address have the length and value of the target address. The message specific meanings of the fields are as follows, Flags - The flags field is coded as follows, 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Q| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Q Set if the station sending Callback Request is a router; clear if it is a host. Zero or one of the Client Information Entry (CIE) MAY be specified in an Callback Request. If a CIE is specified then that entry carries the pertinent information for the RISP station (i.e., the requester) issuing the Callback Request. The usage of the CIE is Jun Ogawa, Yao-Min Chen [Page 10] INTERNET-DRAFT RISP Expires Feb. 1998 described below: Maximum Transmission Unit This field gives the maximum transmission unit for the source station. A possible use of this field in the Callback Request packet is for the requester to ask for a target MTU. In lieu of that usage, the CIE MUST be omitted. All other fields in the CIE MUST be ignored and SHOULD be set to 0. Note that a shortcut path may be maintained by a RISP station as a PtoP interface, as we described in Section 3.2. If this is the case for a requester, it needs to know the IP address of its responder in order to initialize the PtoP interface to the responder. Therefore, if a requester uses PtoP interface to maintain a shortcut path, the Callback Request packet MUST have Responder Address Extension in order to get information about the responder. All other Extension Parts can be used, but some parts (e.g., the NHRP Reverse Transit NHS Record Extension) may be meaningless to the Callback Request. 4.2 Callback Reply This message is used by a responder to reply to a Callback Request. The message is sent along the shortcut path established for the Callback Request if the path establishment is successful or the responder already has a VC connecting to the requester. Otherwise it is sent along the routed path. Any extension present in the Callback Request packet MUST be present in the Callback Reply even if the extension is categorized as non-Compulsory in Section 5.2.1 of [2]. The mandatory part of Callback Reply is coded as described in Section 5.2.0.1 of [2]. Src Proto Len, Source NBMA Address, Source NBMA Subaddress and Source Protocol Address in the common header have the information about the requester, and Dst Proto Len and Destination Protocol Address have the length and value of the target address of the corresponding Callback Request packet. The message specific meanings of the fields are as follows, Flags - The flags field is coded as follows, 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Q| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Q Copied from the Callback Request. Set if the requester is a router; clear if it is a host. Jun Ogawa, Yao-Min Chen [Page 11] INTERNET-DRAFT RISP Expires Feb. 1998 One CIE is specified in the Callback Reply. The CIE contains information about the responder. If CIE Code is 0 then it MUST send this message along the shortcut path, otherwise this message MUST be sent along the routed path. Code If this field is set to 0 then this packet contains a positively acknowledged Callback Reply. If this field contains any other value, then this means NAK for the shortcut establishment. CIE Codes are defined temporarily as follows: 0 - The shortcut path is established successfully. The Callback Request is accepted by its responder, and the shortcut path is established successfully. 32 - There is not enough available resource. The responder receives the Callback Request correctly, but does not have enough resources to establish the shortcut path requested. 33 - The shortcut path establishment fails because of L2 problems. The responder receives the Callback Request correctly, but it fails to establish the shortcut path after using the ATM signaling such as UNI*. 34 - Establishment the shortcut path is prohibited by the administrator. An administrator of the responder prohibits the shortcut path to the responder. Prefix Length and Maximum Transmission Unit fields are used as described in Section 5.2.0.1 of [2]. Cli Proto Len and Client Protocol Address have the length and value of the target address of the Callback Request packet. Cli Addr T/L, Cli SAddr T/L, Client NBMA Address and Client NBMA Subaddress either have information about the responder or SHOULD be set to 0 otherwise. 4.3. Error Indication The packet format is the same as NHRP Error Indication described in Jun Ogawa, Yao-Min Chen [Page 12] INTERNET-DRAFT RISP Expires Feb. 1998 [2], except we do not need error code number 10 - Invalid NHRP Resolution Reply Received. 5. Security Considerations Shortcut routing and network security sometimes seem to serve different objectives. To be secure, we recommend using L3 firewalls to divide ATM subnetworks. Since Callback Request is an L3 packet, it can be filtered at a firewall so that attempts to setup shortcut paths crossing the firewall can be blocked. Section 3.1 briefly touched upon authenticating a VC for a shortcut path. Here we extend the idea a little further. Note that since RISP is a peer-to-peer protocol, authentication information can be carried in the Callback Request and Reply messages. The extension of packet format to carry authentication information is under investigation. In current implementation, we simply use the Request ID carried in the messages, which is discussed below. Note that a station A may know the ATM address of another station B through other means than receiving a Callback Request message (e.g., from previous shortcut path establishment). However, later if Station A sets up a VC to B (e.g., Step (5) in Fig. 2) it does not have a Request ID issued by B and so it cannot send a proper Callback Reply along the path to B (e.g., Step (6) in Fig. 2). +-------+ +-------+ +-------+ +-------+ |Station|-------|Router |------|Router |------|Station| | A | +-------+ +-------+ | B | +-------+ +-------+ (1) ------->------------->--------------> Callback Request (hop by hop) (2) <==================================== Establishing a shortcut path (3) <------------------------------------ Callback Reply : (4) The shortcut path terminates : : (5) ====================================> establish a shortcut path (6) Can not send a Callback Reply with proper Request ID Fig. 2 Callback Reply to authenticate a shortcut path. As we discussed in Section 3.1, when RISP inter-operates with ATMARP, the authentication mechanism needs to be aborted because the latter protocol does not authenticate the VCs that it establishes. Jun Ogawa, Yao-Min Chen [Page 13] INTERNET-DRAFT RISP Expires Feb. 1998 6. Intellectual Property Considerations. Fujitsu Laboratories Limited may seek patent or other intellectual property protection for some or all of the technologies described in this document. References [1] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [2] NBMA Next Hops Resolution Protocol (NHRP), James V. Luciani, draft-ietf-rolc-nhrp-11.txt [3] Classical IP to NHRP Transition, James V. Luciani, raft-ietf-ion-transition-00.txt [4] Server Cache Synchronization Protocol (SCSP), James V. Luciani, Grenville Armitage, and Joel Halpern, draft-ietf-ion-scsp-00.txt. [5] Perez Maher, M. et al, ""ATM Signaling Support for IP over ATM", RFC1755, February 1995 Acknowledgments We would like to thank David Richard and Steven A. Wright of Fujitsu Network Communications Inc. and Walter Sotelo of Hal Computer for insightful suggestions and comments. Authors' Addresses Jun Ogawa Fujitsu Laboratories LTD. 4-1-1 Kamikodanaka Nakahara-ku Kawasaki 211-88 Japan Phone: +81-44-754-2629 E-mail: ogawa@flab.fujitsu.co.jp Yao-Min Chen Fujitsu Laboratories of America, INC. 3350 Scott Blvd.,Bldg.#34, Santa Clara, CA 95054-3104 USA Phone: +1-408-567-4513 E-mail: ychen@fla.fujitsu.com