INTERNET DRAFT Ki-II Kim Expires: April 2003 ChungNam National University Myung-Ki Shin ETRI Dong-Kyun Kim KISTI Sang-Ha Kim ChungNam National University October 2002 Xcast+ Extension for Few-to-Few Mulitcast Communication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 obsolete by other documents at anytime. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Xcast+[2] is newly proposed multicast scheme to support IGMPv2/MLDv3 in Explicit Multicast(Xcast)[1]. Xcast+ is suitable for one-to-few multicast applications. In order to support few-to- few communication naturally, the control plane of existing Xcast+ should be extended. In this document, a new control plane for few- to-few communication for Xcast+ is specified. In order to acheive this, the concept of logical core (LC) is newly introduced. Table of Contents: 1. Introduction 2. Terminology 3. Overview 4. Control Plane Kim et al. Expires April 2003 [Page 1] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 4.1 Group Join 4.2 Group Leave 4.3 Role of Logical Core 5. Data Transmission 6. New Messages for Few-to-Few Communication 7. Requirements 7.1 Sender Requirement 7.2 Receiver Requirement 7.3 Router Requirement 8.Mobility Support 9.Security Consideration 10. Simulation Notes Reference 1. Introduction Xcast is a new form of IP multicast, designed to provide scalable support for very large number of multicast groups, where these groups typically have a small number of participants. Xcast uses explicit encoding of destination list in the data packets, instead of multicast address. The source encodes the list of destinations in the Xcast header, and then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast header to each of the next hops. However, current Xcast specification seems to mention its data plane only, and does not specify a control plane. Xcast+ provides an enhanced scheme for the support of receiver initiated join in Xcast. This is achieved by adding IGMPv3/MLDv2 queries at receivers' side and new registration/de-registration messages between designated routers (at sender's side and receivers' side), and then by explicitly encoding the list of address of the designated routers at receivers' side instead of receiver address Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast. Xcast+ is suitable for one-to-few multicast applications. In order to support few-to-few communication (e.g., audio/video conferencing applications) naturally, it is required to extend the control plane of existing Xcast+. This document describes a new control plane for few-to-few communication in Xcast+. In order to achieve this, the concept of LC is newly introduced. The role of LC is to manage group dynamically and provide encryption key for secure communication. The LC is not involved in data transmission at all. The encoding of the destination list in IPv4 and IPv6 are the same as Xcast+. Kim et al. Expires April 2003 [Page 2] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. In addition, this document frequently uses the following terms: Xcast Explicit Multicast Xcast+ Explicit Multicast Extension Deginated router (DR) An Xcast+ capable multicast querier router. Logical Core (LC) The role of LC is to manage group dynamically and provide encryption key for secure communication. It can be implemented on router or hosts. Group Cache Table A table used to maintain the group membership information. This table should be implemented on LC as well as all DRs. Registration Request (RReq) A message sent from a DR at receiver's side to a DR at sender's side in order to request the reception of Xcast+ data. Registration Reply (RRep) A message sent a DR at sender's side to a DR at receiver's side in order to acknowledge the safe delivery of a Registration Request message. De-registration Request (DReq) A message sent from a DR at receiver's side to a DR at sender's side in order to cease the reception of Xcast+ data. De-registration Reply (DRep) A message sent a DR at sender's side to a DR at receiver's side in order to acknowledge the safe delivery of a De-registration Request message. Member Join Request (JReq) A message sent from a LC to DRs which are already joined in mulitcast group in order to inform them that the new DR just joins in the mulitcast group Member Join Reply (JRep) A message sent from DR to a LC in order to acknowledge the receipt of member join request and the completion the process that message. Member Leave Request (LReq) A message sent from a LC to DRs in order to inform that one of members wish to leave the multicast group Member Leave Reply (LRep) A message sent from a DR to a LC in order to acknowledge Kim et al. Expires April 2003 [Page 3] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 the safe delivery of member leave request and the completion of the process that message. 3. Overview In proposed scheme, a receiver initiates IGMP/MLD membership reports (*, G), where G is a standard multicast address. When a designated router (DR) at receivers' side receives the report, it sends new Registration Request messages (G, DR) to a LC. Thus, when the LC receives the message, it can keep track of the addresses of all DRs at the receivers' side involved in the multicast session (*, G) in its cache table. If other DRs that are involved in the multicast session (*, G) exist in cache table, the LC sends new member join request to the other DRs in order to inform them that the new DR just joins in the multicast group. In case of group leave, the same procedures are applied. These new messages format are specified in section 6. These procedures imply the new control plane for few-to-few communication in Xcast+. The role of LC is to manage group dynamically. The LC is not involved in data transmission. The encoding of the destination list in IPv4 and IPv6 are the same as Xcast+. For example, suppose that A, B, C, D, E and F are trying to send and receive packets each others in Figure 1 below: Detail operation examples for con trol plane will be described in section 4. B LC / | DR2 -- C | / D | / / A --- DR1 --- R2 --- R3 DR3 -- E \ / \ / R5 --- R6 --- R7 \ \ DR4 -- F LC : Logical Core Figure 1. Example of configuarion 4. Control Plane This section describes a new control plane for few-to-few communication in Xcast+ focusing on group join and leave. Kim et al. Expires April 2003 [Page 4] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 4.1 Group Join In the Figure 1, we assume that host A first tries to join multicast group G. In this example, host A initiates (*,G) join to DR1 using IGMPv3/MLDv2. In this procedure, the difference exits between proposed mechanism and exiting Xcast+. In the proposed scheme, receivers should join with (*,G) because all receivers also could be senders, while receivers join with (S,G) using IGMPv3 in existing xcast+. DR1 sends a registration request message to LC to join a group G. In order to send the message, every DR needs to acquire the address of LC which has responsibility of management for group memership. This can be done by using bootstrap mechanism in PIM-SM or manual configuration of LC on every DR. Proposed scheme supposes the address of LC is already known to all DRs. Then, LC which received a registration request message queries requested group information in its group cache table. In the example, there are no DR entries in LC's group cache table as DR1 initiated the first join. Therefore, LC just acknowledges group- join of DR1 by sending an registration reply message to DR1. If host B wants to join a group G later, DR2 will send a registration request message to LC. Then, LC should perform the following two works after receiving registration request because the other member already is being joined the multicast group. 1) LC sends DR2 a registration reply message including the address of DR1 stored in LC's group cache table. In this way, DR2 can get information of every other DR that already joined the group G. 2) DR1 also should know that DR2 is newly joined to a group G, consequently LC is required to notify newly-joined DR information(DR2 in this example) to all other DRs in group cache. In order to achieve this, LC uses a member join request message. Above two tasks are performed on LC. Every DR that received registration reply and member join request messages maintains addresses of other DRs for specific group G in their group cache table. These addresses of receivers will be inserted into xcast+ header of sender for few-to-few communication 4.2 Group Leave In order to explain group leave procedures, suppose host A, B, D, E, and F are joined a group G. In other words, the addresses of each host's DR1, DR2, DR3, and DR4 are supposed to be maintaining for a group G in LC. Kim et al. Expires April 2003 [Page 5] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 If host A is the last one that leaves a group G in its subnet, DR1 requests LC to leave the group by sending a de-registration request message. In this case, LC deletes DR1 from its group cache at first and then sends DR1 a de-registration request message to inform DR1 that it completely leaves the group. Along with this procedure, DR2, DR3 and DR4 delete the address of DR1 from their group cache table as soon as they receive a member leave request message from LC, and send LC a member leave reply message for acknowledgement. In case that acknowledgement messages does not arrive from DR2, DR3 and DR4, within specific time limit, LC sends member leave request messages once again to DRs that did not send acknowledgement. Even if the host D wishes to leave group, there is another receiver within same subnet, host E. So, any action is not taken into in this such case. 4.3 The Role of Logical Core As mentioned above, the LC plays very important roles for xcast+ extension for few-to-few communication. This section describes the role of LC. The role of logical core summarized as two parts : multicast group management and encrption key management for secure communication between group members. 4.3.1 Group Management LC has the very similar functionality with core router in core based multicast protocol, e.g., CBT[3], in that the LC has the responsibility for dynamic multicast group management. However, the major difference between them is able to be identified as the logical core is not involved in data transmission at all. So, the LC surely does not have to be a router. It means that the LC can be implemented as application server on general host. In the view point of group management, the group cache table is required to store the pair of group address and DR address information on LC. The group cache table data structure has the following fields: group address, designated router, and lifetime. The group address field indicates the multicast group address and designated router field store DR address, which has the hosts that wish to join mulitcast group within subnet. Finally, the lifetime field represent the number of seconds it would like its registration to last before it expires. Table 1 shows the example configuration of group cache table. Table 1 : The example of cache table for group management +-----------------------------------------------+ | Group address | Designated Router| Lifetime | +-----------------------------------------------+ | 224.223.232.234 | 211.123.123.1 | 10 | Kim et al. Expires April 2003 [Page 6] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 +-----------------------------------------------+ | 224.223.232.234 | 123.122.132.1 | 12 | +-----------------------------------------------+ | 224.223.232.234 | 63.23.32.1 | 10 | +-----------------------------------------------+ The above group cache table is controlled by newly defined control messages which are designed to insert or delete the specific table entry. In addition to insertion or deletion on on table entries, the control messages must notify change of group member status of all group members so that the each DR can maintain the other members information consistently. The control messages are as follows. - Registration request - Registration reply - De-registration request - De-registration reply - Member join request - Member join reply - Member leave request - Member leave reply 4.3.2 Encryption Key Management Sometimes, it might be very important to ensures that information in the packet are accessible only for reading by authorized group members in few-to-few multicast application. For this purpose, it is recommended to introduce encryption algorithms for confidentiality. The first requirement to introduce encryption algorithm into this scheme is to prevent encryption key from being distributed to unauthorized users. So, the LC should maintain the authorized and legitimate member list and distribute encryption key only when the authorized members request. The above procedure is able to be implemented by commercial network key management protocols. 5. Data Transmission Even though the extension of control plane is required to provide efficient few-to-few communication, there is no requirement for the data transmission. So, the routing algorithm for Xcast packet is specified as same as Xcast. As you can see in Figure 1, when the host B has packet to send toward multicast group, it simply transmits multicast packets to the DR1. Once the DR2 receives the multicast packet from host within subnet, it searches the group cache table with multicast address to get the other members address, for example, DR2 and DR Kim et al. Expires April 2003 [Page 7] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 3. This address (DR2 and DR3) is encoded into Xcast+ header, which is defined in [2]. The routing scheme on intermediate router is exactly as same as Xcast+[2]. [2] can give a fuller explanation for Xcast routing algorithm on intermediate router along the path. 6. New Messages for few-to-few communication There are two kinds of messages : One is for the messages for request registration, de-registration, member join, and member leave and another is for the return reply message for each request message. The use of each message is already described in section 3. The newly defined message format is depicted as follows. 6.1 Message Format for IPv4 All these messages are carried within the data portion of a UDP, which is in turn placed within the payload portion of an IP packet. The Xcast+ module in Xcast+ routers (at least DRs) MUST identify these messages by checking Destination Port field, which must be assigned by IANA in the future. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Type |A|S| Reserved | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (G) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router Address (DR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver 2 Few-to-few communication Type 0 Registration Request 2 De-registration Request 4 Member join Request 6 Member leave Request A 1 Acknowledgement SHOULD be sent S 1 Reply packet SHOULD be returned with payload encrytion Sequence number The number assigned by the node sending request packet and used to identify the packet Lifetime The number of seconds remaining before the entry must be considered expired Kim et al. Expires April 2003 [Page 8] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 Designated Router The router address generating this request message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Type | Number of DRs | Staus | Rsv.| Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (G) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | Designated Router Addresses (DRs) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver 2 Few-to-few communication Type 1 Registration Reply 3 De-registration Reply 5 Member join Reply 7 Member leave Reply Number of DRs The number of contained designated routers Status 8-bit unsigned integer indicating status 0 Registration Reply accepted 1 De-registration Reply accepted ... 128 NOT accepted Sequence number The originated number at source node. This value incrementally increses whenever source generate one request message Lifetime Set the lifetime for entry Multicast address Address for mulitcast session Designated Router The list of already joined designated routers 6.2 New Router Alert Option for IPv6 All of these messages for IPv6 are designed by the Router Alert option within the Hop-by-Hop option header. The Xcast6+ module in Xcast6+ routers (at least DRs) SHOULD identify these messages by Kim et al. Expires April 2003 [Page 9] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 checking the value of Router Alert Option, which must be assigned by IANA in the future. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Type |A|S| Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Length | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Address (S) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Address (G) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Designated Router Address (DR) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Type | Status |Rsv| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Length | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Address (S) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Address (G) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ ~ | Designated Router Addresses (DRs) | Kim et al. Expires April 2003 [Page 10] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Requirement This section shows several requirements that should be added to support few-to-few communication based on LC. Those requirements are described for sender, receiver, and DR router. 7.1 Sender requirement In the proposed Xcast+ extension, sender just sends packets to DR after encoding target IP addresses to group addresses in the same way of existing xcast+. The difference exists in data confidentiality. To achieve data confidentiality, sender should encrypt data using the key delivered when logical core authenticates the group member. 7.2 Receiver requirement No difference exists in receiver requirement compared to existing Xcast+. If sender transmits encrypted data, decryption function should be added on the receiver's side using the key that logical core sends during join procedure. 7.3 Designated Router requirement In case of existing Xcast+, sender's DR just maintains the list of other DRs to have receivers, but in proposed mechanism each DR should maintain the list of all other DRs for specific multicast group in the same way as logical core. Each DR has group cache table with defined data structure in 4.3.1. These DR addresses are encoded into receiver list field of Xcast+ header, if hosts transmit data to Xcast+ group. Therefore, every DR should have data structure to maintain the list of DRs for specific multicast group in few-to-few communication. Each DR should transmit original multicast datagram to its subnet after removing Xcast+ header of delivered Xcast+ packets. Implementation of this procedure should be defined. 8. Mobility Support The proposed scheme can provide the multicast in mobile environment without any difficulty or modification. The existing schemes for multicast in mobile environment fall into two categories: one is to Kim et al. Expires April 2003 [Page 11] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 rely on the tunneling between Home Agent (HA) and Foreign Agent (FA) and other is to rely on tree reconstruction from source of multicast group to current FA. First is called HA based mechanism and second is called as FA based mechanism. Now that the Xcast+ is not dependent on multicast state on intermediate router for transmitting multicast packet at all, there is no extra overhead for tree construction and management. So, the proposed scheme is designed as same way with latter scheme. The how to apply in mobile environment is described as shown in Figure 2. BS4 LC | | | | R1------------R2-----------R3----------R4 / | / | / BS3 R5 / \ / \ / \ / \ MH C MH D BS1 R6 | | | | MH A BS2 | | MH B Figure 2. The example configuration in mobile network As you can see in Figure 2, there is four Base Stations (BS), one LC, six Xcast-capable routers (R1, R2, R3, R4, R5, and R6) , and four mobile host (MH A, MH B, MH C, and MH D). We assume that each BS has the same functionality of DR and MH A, MH B, MH C, and MH D are being joined multicast group G. When the MH A moves and connects to BS4, MH A listens to agent advertisement message and determines whether it is connected to HA or FA. Whether MH A is connected to HA or FA, the MH A notifies BS4 through IGMP/MLD protocol that the MH A wishes to join multicast group G. Since there is no group information on BS4, BS4 requests registration by sending registration request message to LC. It is the same procedure as the any host within administrative scope of BS4 wishes to join multicast group. On the other hand, it happens that BS1 does not need to provide service for multicast group G any more since there is no host that wish to receive multicast data for group G. So, BS1 requests de- registration according to the procedures described in above section 4.2. Once LC receives the registration request or de-registration message, the LC modifies the corresponding cache table entry. And Kim et al. Expires April 2003 [Page 12] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 this modification result is distributed to each DRs so that it updates the cache table entry of each DRs. On the other hand, when MH C handoffs from BS3 to BS2, the MH C requests the group join through IGMP/MLD. However, since BS2 already has the other group member within its subnet, MH B, it is not required to send registration request message to LC. In the same manner, the BS3 does not send de-registration request message due to having another group member. Even if there might be drop of packets during the control messages exchange between LC and group members are completed, it is considered as short duration. Furthermore, it can support mobility of sender and always select the optimized path to transmit the multicast packet. 9. Security considerations In terms of confidentiality, the packet encryption might be easily obtained encryption key allocated in advance encryption key per group. This key must be kept secure in LC. Other considerations for Xcast security, that is, receiver authentication, integrity, access control, and nonrepudiation, mostly rely on [5]. 10. Simulation Notes We develop the simulation codes for Xcast+ extension based on LC with Network Simulator (NS). The simulation source code is avaiable at http://lionking.cnu.ac.kr/~multicast. References [1] R. Boivie et al., Explicit Multicast (Xcast) Basic Specification, , June, 2002. [2] M.K. Shin et al., Explicit Multicast Extension (Xcast+) Supporting Receiver Initiated Join, , October, 2002. [3] A. Ballardie, Core Based Trees (CBT version 2) Multicast Routing Protocol Specification, September 1997. [4] H. Holbrook and B. Cain, Source-Specific Multicast for IP, , November 2001. [5] O. Paridaens et al., Security Framework for Explicit Multicast, , June 2002. [6] C.E. Perkins, IP Mobility Support, IETF RFC 2002, October 1996. Kim et al. Expires April 2003 [Page 13] INTERNET-DRAFT Xcast+ For Few-to-Few Communication October 2002 Authors' Addresses Ki-Il Kim ChungNam National University 220 Gung-dong, Yuseong-gu, Daejon , Korea Tel : +82 42 821 7451 Fax : +82 42 822 9959 E-mail : kikim@cclab.cnu.ac.kr Myung-Ki Shin ETRI PEC 161 Gajeong-dong, Yuseong-gu, Daejon , Korea Tel : +82 42 860 6564 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Dong-Kyun Kim KISTI P.O. Box 122, Yuseong-gu, Daejon, Korea Tel : +82 42 869 0516 E-mail : mirr@kreonet2.net Sang-Ha Kim ChungNam National University 220 Gung-dong, Yuseong-gu, Taejon , Korea Tel : +82 42 821 6271 Fax : +82 42 822 9959 E-mail : shkim@cclab.cnu.ac.kr Kim et al. Expires April 2003 [Page 14]