Internet Draft Jun Ogawa Expires September 1997 (Fujitsu Laboratories LTD.) Yao-Min Chen (Fujitsu Laboratories of America INC.) March 1997 The Receiver-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 defines the Receiver Initiated Shortcut Path (RISP) protocol for NBMA networks. The protocol extends the NHRP message set by adding Callback Request and Reply messages to allow the destination host (or its corresponding egress router) to establish a shortcut path for a data flow, using the existing NBMA signaling protocols. Because of this receiver-initiated mechanism, a shortcut-capable network can use just the NBMA ARP servers, such as the ATMARP servers, instead of the more complex Next Hop Servers. This draft also describes how to extend NHRP with the new, receiver-initiated mechanism. 1. Introduction A main goal of the IP over NBMA Networks (ion) working group is to define efficient address resolution mechanisms for establishing NBMA paths suitable for IP flows. Towards this goal, Classical IP over ATM [1] and Next-Hop Address Resolution Protocol (NHRP) [2] Jun Ogawa, Yao-Min Chen [Page 1] INTERNET-DRAFT RISP Expires Sept. 1997 are outputs from the working group that have received significant attention. The strength of Classical IP over ATM is its simplicity but it cannot establish shortcut paths across multiple logical IP subnetworks. NHRP establishes the shortcuts but the complexity of Next Hop Servers may prevent its rapid adoption. In this memo, we describe a way to establish shortcut paths without the complexity of Next Hop Servers. RFC 1577 [1] defined the concept of Logical IP Subnetwork (LIS) which is a separate administrative entity where hosts and routers are configured within a closed IP subnetwork. In this memo, we describe a protocol to establish shortcut paths without the complexity of Next Hop Servers. The protocol is called Receiver-Initiated Shortcut Path (RISP). It works on an environment where an NBMA subnet is divided into multiple Logical IP Subnetworks (LISs, see reference [1]). This is the same environment considered by both Classical IP over ATM and NHRP. Below, we briefly review Classical IP over ATM and NHRP and then introduce RISP as a simple method to establish inter-LIS shortcut paths. 1.1 Classical IP over ATM First of all, a client must register its IP address and ATM address with an ATMARP Server using Inverse ATM Address Resolution Protocol (InATMARP). A client connects to the ATMARP server using a point-to-point VC. In the case of Intra-LIS path establishment, a sender client resolves the receiver's ATM address using the ATMARP server. Then the sender client establishes a path and sends IP packets along it. In the case of Inter-LIS, a sender client sends IP packets to a router. The router transmits these packets to the receiver using the ordinary routing table constructed by a routing protocol such as RIP or OSPF. Therefore, intermediate routers become bottleneck for the speedy transmission of data packets. 1.2 Next Hop Resolution Protocol First of all, a client host must register its Protocol and NBMA addresses with an Next Hop Server (NHS) using an NHRP Registration Request message. For example, if the internetwork-layer protocol is IP and the underlying subnet-layer NBMA network is ATM, the client registers its IP and ATM addresses with the NHS. Jun Ogawa, Yao-Min Chen [Page 2] INTERNET-DRAFT RISP Expires Sept. 1997 In both intra- and inter-LIS communications, a sender client sends an NHRP Resolution Request to the nearest NHS to resolve the destination NBMA address. If the NHS cannot resolve it, it forwards the request to the destination using the ordinary routing table because the NHS is also equipped with router function. Eventually, the NHS (router) nearest to the destination resolves the NBMA address. Once the destination NBMA address is resolved, the sender establishes a shortcut path to the receiver. Therefore, inter-LIS communication under NHRP does not suffer the router bottleneck problem in Classical IP over ATM. NHRP also allows an intermediate NHS to cache the NBMA address of a destination so that later the NHS can directly resolve a request instead of forwarding it. In addition, note that NHRP offers not only shortcut path establishment but also a rich set of functions beyond what is provided by Classical IP over ATM. Here we briefly mention a few. 1) An NHS can resolve the NBMA address for an equivalent class of internetwork layer addresses using the prefix length field in an NHRP message (See Section 5.2.0.1 of [2] for more details). This is useful when several Protocol addresses share an NBMA address. 2) An NHS can resolve an NBMA address from a Protocol address using the U bit (which indicates that the NBMA address is unique to the Protocol address). 3) To invalidate the cached information at a station(e.g. NHC or NHS), NHRP Purge Request is defined. This message facilitates the coherency of the information cached at multiple stations. However, the rich set of functions comes at the price of complexity at NHSs, which we summarize below and discuss in more depth in Appendix-A. a) Along with the conventional router function, an NHS must maintain a database for address resolution. In addition, all routers in the NBMA network must be equipped with this function when using NHRP in the network. b) When a LIS has multiple routers (NHSs), they need a mechanism to synchronize the cached information. SCSP [4] is such a mechanism being drafted by the ion working group. c) NHRP allows a transit NHS to cache the entries contained in the received NHRP Resolution Replys (i.e., the resolved Protocol/NBMA address mappings in the messages). Subsequently the NHS can resolve an NHRP Resolution Request using the cached entries. Jun Ogawa, Yao-Min Chen [Page 3] INTERNET-DRAFT RISP Expires Sept. 1997 However, the NHS also needs to keep track of the source address of the request (see Appendix-A.2 for a more thorough discussion on this aspect). In summary, the main reason for the complexity of NHS is that NHRP requires that the routers also perform address resolution for both intra- and inter-LIS communications. Consider a network that is based on Classical IP over ATM. When it migrates to NHRP, complexity incurred on all routers due to additional requirements in a)- c). In some cases a network operator may not want the complexity in spite of the benefits provided by NHRP. For example, the operator may be satisfied with just the provision of "inter-LIS shortcut paths" but rather uses Classical IP over ATM for intra-LIS paths. For this kind of networks, this document describes a simple way to establish shortcut paths without the need of inter-LIS address resolution. 1.3 Receiver-Initiated Shortcut Path Protocol The protocol adopts Classical IP over ATM for intra-LIS communication and defines a receiver-initiated setup mechanism for inter-LIS shortcut paths. Such a shortcut path is set up by the following four phases. In the Request phase, a sender sends a request along a routed (i.e., hop-by-hop) path. In the Respond phase, a responder, which can be either a destination host or an egress router, sets up a shortcut path back to the sender, and then sends a responding packet along the path. In the Transmit phase, data are transmitted between the sender and receiver through the shortcut path. In the Close phase, either the sender or the responder sends a release packet to its peer, which then tears down the path. A complete specification of the protocol will be given in Section 3, after we introduce terminology in Section 2. The protocol can stand alone (without NHRP) as an inter-LIS shortcut protocol, or its functionality can be integrated into NHRP. It can also be used as a transit step for the migration of ATMARP-based networks to NHRP networks, because it offers inter-LIS shortcut paths with just ATMARP servers. If later a network requires the richer set of functions provided by NHRP, it can migrate to NHRP. For this reason, we choose a packet format closely tied to the NHRP packet format. The packet format is described in Section 4, and the migration is discussed in Section 5. 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 Jun Ogawa, Yao-Min Chen [Page 4] INTERNET-DRAFT RISP Expires Sept. 1997 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. 3. Protocol Overview Currently, we only consider an IP-over-ATM environment. However, it is possible to generalize the draft for other NBMA networks. This is currently under study. The protocol does NOT use any servers for establishing a path across multiple LISs, but only uses ATMARP servers for intra-LIS address resolution. So, 1) for inter-LIS communication, a host does not need to know the NBMA address of its destination before initialing communication, 2) a router does not need to maintain a database for the purpose of address resolution, and 3) a destination host can refuse a shortcut path request. Below, we specify the protocol by specifying how inter- and intra-LIS communications are conducted. As we mentioned earlier, the messages used by the protocol will follow the NHRP basic packet format. Therefore, we add "NHRP" in front of these messages to indicate this fact. 3.1 Inter-LIS Communication By default, a source host sends IP packets to the destination through routers (hop by hop). We call a path taken this way a "routed" path. If the host decides that a shortcut path is more suitable for a flow than the routed path, it sends an NHRP Callback Request message to the destination along the routed path. We refer to this host as the requester for the NHRP Callback Request. An NHRP Callback Request message has the IP and ATM addresses of its requester. It also has a Request ID to uniquely identify the message. When the destination or its egress router (if the destination is not on the NBMA subnet) receives the NHRP Callback Request, it starts establishing a shortcut path back to the requester, using the NBMA signaling such as UNI*. This signaling is possible because the ATM address of the requester is contained in the NHRP Callback Request. We call the destination host or egress router the responder for the Callback Request. Jun Ogawa, Yao-Min Chen [Page 5] INTERNET-DRAFT RISP Expires Sept. 1997 If the NHRP Callback Request packet contains an error then the responder sends the NHRP Error Indication with appropriate Error Code as described in [2]. As soon as the shortcut path is established, the responder sends an NHRP Callback Reply along the path to the requester. The NHRP Callback Reply message contains the IP and ATM addresses of the responder. It also has a Request ID which is identical to the Request ID of the NHRP Callback Request. Upon receiving an NHRP Callback Reply, the requester verifies if the Request ID in the message is the same as in the NHRP Callback Request it issued. If they are the same, the shortcut path establishment has completed. Otherwise, the shortcut path must be terminated by the requester. After the establishment, the requester re-directs its data packets from the routed path to the shortcut path. On the other hand, if the path establishment fails, the responder sends an NHRP Callback Reply along the routed path. Such a failure may occur because of lack of resources at the responder or some layer-2 problem. In Section 4.2, we have a more thorough discussion. To terminate a shortcut path, either the requester or the responder sends an NHRP Release Request message to its peer. When the peer receives the message, it disconnects the shortcut path. If the requester sends an NHRP Callback Request but does not receive any NHRP Callback Reply or Error Indication messages with the Request ID, it sends an NHRP Callback Request again with the same Request ID. The interval between the NHRP Callback Requests and the number of times for the re-transmission are for further study. If the path establishment fails, the requester continues to send IP packets through the routed path. +-------+ +-------+ +-------+ +-------+ | src |-------|Router |------|Router |------| dst | | | +-------+ +-------+ | | +-------+ +-------+ (1) ------->------------->--------------> NHRP Callback Request (hop by hop) (2) <==================================== establish a shortcut path (3) <------------------------------------ NHRP Callback Reply : Jun Ogawa, Yao-Min Chen [Page 6] INTERNET-DRAFT RISP Expires Sept. 1997 (4) <------------------------------------ NHRP Release Request (5) The shortcut path terminates Fig.1 Typical usage of RISP. 3.2 Intra-LIS In the case of Intra-LIS address resolution, the protocol uses Classical IP over ATM. Therefore, when a host wants to join a LIS, it registers its IP and ATM addresses with an ATMARP server. 3.3 Authentication The protocol also provides an authentication mechanism, which is described in Appendix-B. The protocol has the option to work without the mechanism. 3.4 Summary The simplicity of the protocol lies in the fact that it does not require address resolution function to establish an inter-LIS shortcut path, because such a path is established by the receiver using NBMA signaling. 4. Messages The protocol requires that the NHRP to extend its message set and assign packet type values(ar$op.type) to the new messages NHRP Callback Request, NHRP Callback Reply, and NHRP Callback Release. If a network merely uses the RISP functions, it only needs to support these messages along with NHRP Error Indication. 4.1 NHRP Callback Request This message is used by a sender host to request a shortcut path. Unlike the NHRP Resolution Request, the nearest router or NHS of the destination simply forwards this message to the destination host. If the destination is outside of the NBMA subnet, then the egress router MUST become the responder to answer this request and it MUST not forward this request to the next NBMA subnet. NHRP Callback Request's mandatory part is coded as described in Section 5.2.0.1 of [2]. The message specific meanings of the fields are as follows, Jun Ogawa, Yao-Min Chen [Page 7] INTERNET-DRAFT RISP Expires Sept. 1997 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 the NHRP Resolution Request is a router; clear if it is a host. Zero or one CIE may be specified in an NHRP Callback Request. If a CIE is specified then that entry carries the pertinent information for the client sourcing the NHRP Callback Request. The usage of the CIE is described below: Maximum Transmission Unit This field gives the maximum transmission unit for the source station. A possible use of this field in the NHRP 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. All the Extension Parts of the NHRP can be used, but some of it may be meaningless to the NHRP Callback Request (e.g., the NHRP Reverse Transit NHS Record Extension). 4.2 NHRP Callback Reply This message is used by a responder to reply to an NHRP Callback Request. The message is sent along the shortcut path established for the NHRP Callback Request if the path establishment is successful, otherwise it is sent along the routed path. NHRP Callback Reply's mandatory part is coded as described in Section 5.2.0.1 of [2]. 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 NHRP Callback Request. Set if the requester is Jun Ogawa, Yao-Min Chen [Page 8] INTERNET-DRAFT RISP Expires Sept. 1997 a router; clear if it is a host. One CIE is specified in the NHRP Callback Reply. The CIE contains the responder's information. 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 NHRP Callback Reply. If this field contains any other value then this means NAK for the shortcut establishment. CIE Codes are defined temporary as follows: 0 - The shortcut path is established successfully. The NHRP Callback Request is accepted by its responder, and the shortcut path is established successfully. 32 - Not enough resource is available to establish the cut through path. The responder receives the NHRP Callback Request correctly, but it does not have enough resources to establish the shortcut path requested. 33 - The shortcut path establishment fails because of the sublayer. The responder receives the NHRP Callback Request correctly, but it fails to establish the shortcut path after using the NBMA 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]. All other fields in the CIE, such as Holding Time, Cli Addr T/L, Cli SAddr T/L, Cli Proto Len, Preference, Client NBMA Address, Client NBMA Subaddress, Client Protocol Address SHOULD be set to 0, because Jun Ogawa, Yao-Min Chen [Page 9] INTERNET-DRAFT RISP Expires Sept. 1997 the NHRP Callback Reply is not used for the address resolution. 4.3 NHRP Release Request The message is used by a host to ask its peer to disconnect the shortcut path between them, if the two hosts are located at different LISs. When a requester or responder wants to release a shortcut path, it sends this message to its peer along the shortcut path. When the peer receives the message and is ready to release the path, it uses NBMA signaling to disconnect the path. This message facilitates a host to detect whether a path termination is legal. Note that NHRP does not define any message for a host to notify its peer about path termination. This makes it difficult to distinguish whether the path is terminated by a peer or due to some intermediate switching entity failure. Hence, the NHRP Release Request message can be a useful addition to NHRP. Note that it is possible to release a shortcut path without using NHRP Release Request. If this message is not received through a shortcut path across multiple LISs, it must be discarded. Also a host can only send an NHRP Release Request message along a path where it has received or sent an NHRP Callback Reply, so that the NHRP Release Request Message is not sent along a path established by Classical IP over ATM. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ No CIE is specified in the NHRP Release Request. 5. Migration to the "full-set" NHRP We consider the "full-set" NHRP as the current NHRP proposal [2] plus the functions defined in RISP. Adding the functions to NHRP has following advantages. First, a receiver can refuse a shortcut path request. For example, an NHC may have a filter to determine which sender addresses are allowed shortcut paths, or it may decide to accept or deny a shortcut path request according to its load and resource level. This kind of Jun Ogawa, Yao-Min Chen [Page 10] INTERNET-DRAFT RISP Expires Sept. 1997 dynamic decision is difficult if done by an NHS. Second, some networks may allow services charged on receivers. In this case, it is desirable to let the receivers control the shortcut path establishment. When migrating to the full-set NHRP, an NHS must route/forward the NHRP Callback Request/Reply messages to its destination unless the NHS happens to be the egress router for the destination. If an NHS receives an NHRP Callback Request destined for a host in its LIS and does not have a cache for the host address, it MUST send NHRP Error Indication packet with the Error Code 6(Protocol Address Unreachable) to stop the requester from re-sending the NHRP Callback Request. 6. Security Considerations Security Considerations are not discussed in this memo. 7. 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. Appendix-A Complexity of the NHRP Servers. A-1: Necessity of the SCSP. When a LIS has more than one router(e.g.NHS), all the routers belonging to the LIS use SCSP to synchronize their cached information. <------- LIS -------> +-------+ +-------+ | NHS1 |------+-------+------| NHS2 | +-------+ | | +-------+ \ / \ / +-------+ | NHC1 | | | +-------+ (1) <------ NHRP Registration Request Jun Ogawa, Yao-Min Chen [Page 11] INTERNET-DRAFT RISP Expires Sept. 1997 (2) ------> NHRP Registration Reply (3) <=====================> Registration synchronization by SCSP Fig.A-1: NHRP requires SCSP for cache synchronization In the case of Fig.A-1, both NHS1 and NHS2 must be able to resolve the ATM address of NHC1, but NHC1 only registers with NHS1. So NHS1 tells NHS2 about NHC1's IP/ATM address using SCSP. A-2: Necessity of Memorizing NHRP Resolution Requests NHRP allows that a transit NHS receiving an NHRP Resolution Reply (e.g., NHS1 of Fig. A-2) caches its entries (the resolved IP/ATM address in NHRP Resolution Reply). The destination of an NHRP Resolution Reply (e.g., NHC1 of Fig. A-2) is allowed to cache too. Consider the example in Fig. A-2. In order to purge the cached Resolution Reply at NHS1 and NHC1 in Step (6), NHS2 has to remember having forwarded NHRP Resolution Request in Step (1). +-------+ +-------+ +-------+ +-------+ | NHC1 |-------| NHS1 |------| NHS2 |------| NHC2 | | (src) | +-------+ +-------+ | (dst) | +-------+ +-------+ (1) ------->-------------> NHRP Resolution Request NHRP Resolution Request has cached at NHS2. (2) <----------------<----- NHRP Resolution Reply The content of NHRP Resolution Reply is cached at NHS1 and NHC1. : (3) -------> NHRP Resolution Request (4) <------- NHRP Resolution Reply : (5) <----- NHRP Purge Request (6) <-------<------------- NHRP Purge Request Fig.A-2: NHRP Purge requires stations to memorize earlier NHRP Resolution Requests Appendix B The Authentication Mechanism for RISP In the case of the NHRP, an NHC resolves the ATM address of a destination using an NHRP Resolution Request message. Later, this requester can establish the shortcut path to the same destination Jun Ogawa, Yao-Min Chen [Page 12] INTERNET-DRAFT RISP Expires Sept. 1997 without another NHRP Resolution Request because it already knows the ATM address of the destination. Therefore, the intermediate routers cannot authenticate each shortcut path. If RISP stands alone as the inter-LIS shortcut protocol, authentication of each short-cut path is straightforward. A source may know the ATM address of a destination through a previous shortcut path establishment. However, later if the source sets up a shortcut path to the same destination (e.g., Step (6) in Fig. B-1), it does not have a Request ID from the destination and so it cannot send a proper NHRP Callback Reply along the path to the destination and so the destination will disconnect the path (e.g., Steps (7) and (8) in Fig. B-1). +-------+ +-------+ +-------+ +-------+ | src |-------|Router |------|Router |------| dst | | | +-------+ +-------+ | | +-------+ +-------+ (1) ------->------------->--------------> NHRP Callback Request (hop by hop) (2) <==================================== establish a shortcut path (3) <------------------------------------ NHRP Callback Reply : (4) <------------------------------------ NHRP Release Request (5) The shortcut path terminates : : (6) ====================================> establish a shortcut path (7) Can not send an NHRP Callback Reply (8) The shortcut path terminates by dst Fig.B-1 A shortcut path without an NHRP Callback Request cannot be authenticated. The following authentication rules are only optional and its adoption is a local decision matter; RISP can work without implementing these rules. However, if RISP is integrated with NHRP, these rules MUST NOT be adopted (see Chapter 5 for discussion about the migration to the full set NHRP). (1) A host that has a path without a corresponding NHRP Callback Jun Ogawa, Yao-Min Chen [Page 13] INTERNET-DRAFT RISP Expires Sept. 1997 Reply needs to check first whether the path is established by Classical IP over ATM (i.e., whether the other end of the path is within the same LIS). If it is, the host MUST accept IP packets from the path, for backward compatibility with Classical IP over ATM (because if the path is established by the Classical IP over ATM for intra-LIS communication, no NHRP Callback Reply is sent along the path). To verify whether the path is established via Classical IP over ATM, the host sends an InATMARP Request to the ATMARP server to acquire the IP address of the remote host. For this to work, ATMARP server MUST accept the InATMARP Request and reply it using information cached (although current RFC1577 does not require this on ATMARP servers). If the address resolved is in the same LIS as the host, it knows that the path is established by Classical IP over ATM and so accepts IP packets sent along the path. Otherwise, we recommend that the host terminate the path quietly. (2) For hosts belonging to different LISs, the normal Request ID authentication process MUST be followed. In other words, if a requester has a shortcut path along which it never receives an NHRP Callback Reply with the proper Request ID but receives some other IP packets, the requester MUST terminate the path. The details of this authentication mechanism is for further study. For example, in the case of (1), the handling of the packets that are received while the host communicates with its ATMARP server is yet to be determined. Also, RISP requires an NHRP Callback Request for each path establishment, while under NHRP, a host does not need to send an NHRP Resolution Request if it already has the destination NBMA address in its cache. Therefore, considering the number of request packets that are passed through the routers, the number of NHRP Callback Requests, under RISP, may be significantly larger than the number of NHRP Resolution Requests under NHRP. We are investigating whether this increase in packet count will be a disadvantage of the RISP authentication mechanism. 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, Jun Ogawa, Yao-Min Chen [Page 14] INTERNET-DRAFT RISP Expires Sept. 1997 Grenville Armitage, and Joel Halpern, draft-ietf-ion-scsp-00.txt. 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