One document matched: draft-jeong-nemo-ro-ndproxy-01.txt
Differences from draft-jeong-nemo-ro-ndproxy-00.txt
Individual Submission
Internet Draft Jaehoon Paul Jeong
Kyeong-Jin Lee
Jung-Soo Park
Hyoung-Jun Kim
<draft-jeong-nemo-ro-ndproxy-01.txt> ETRI
Expires: April 2004 2 October 2003
ND-Proxy based Route and DNS Optimizations for
Mobile Nodes in Mobile Network
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted [1].
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".
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
This document specifies a mechanism for enabling mobile nodes in IPv6
mobile network to perform route optimization. The route optimization
is possible because mobile router relays the prefix of its Care-of
address to its mobile nodes by playing the role of ND-proxy.
Through binding updates associated with the network prefix of an
access network, the mobile nodes can perform route optimization. In
addition, this document explains how mobile nodes can optimize its
DNS name resolution through RA-based DNS discovery. By announcing
the address of local recursive DNS server, mobile router allows
mobile nodes to optimize their DNS name resolution.
Conventions used in this document
Jeong, et al. Expires - April 2004 [Page 1]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
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 [2].
Table of Contents
1. Terminology...................................................2
2. Introduction..................................................3
3. Overview......................................................3
4. Neighbor Discovery extension..................................4
4.1 RO Prefix Information option format.......................4
4.2 Neighbor Solicitation (NS) message format.................5
4.3 DNS Server option format..................................6
5. Mobile Router.................................................8
5.1 Process of RO Prefix Information option...................8
5.2 Process of DNS Server option..............................8
5.3 Delivery of Data Packets..................................8
6. Mobile Node...................................................9
6.1 Procedure of Route Optimization...........................9
6.1.1 Generation of a new CoA.............................9
6.1.2 DAD for the new CoA.................................9
6.1.3 Return Routability and Binding Update..............10
6.2 Procedure of DNS Optimization............................10
6.2.1 RDNSS Configuration................................10
6.2.2 RDNSS Selection....................................10
7. Security Considerations......................................11
8. Copyright....................................................11
9. Normative References.........................................12
10. Informative References......................................12
11. Acknowledgements............................................13
12. Authors' Addresses..........................................13
1. Terminology
This document uses the terminology described in [3]-[7]. Especially
four important terms are as follows [5][7]:
Multilink Subnet (MS)
A collection of independent links, connected by routers, but
sharing a common subnet prefix.
ND-Proxy
A router proxying and relaying for all nodes on its router-mode
interfaces except proxy-mode interfaces among its network
interfaces.
Multilink-Subnet Router (MSR)
Jeong, et al. Expires - April 2004 [Page 2]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
A router which has interfaces attached to different links in a
MS, and which plays the role of ND-Proxy.
Recursive DNS Server (RDNSS)
A Recursive DNS Server is a name server that offers the
recursive service of DNS name resolution.
2. Introduction
The basic support of mobile network (NEMO) enables mobile network
nodes and correspondent nodes to communicate through bi-directional
tunnels. The deeper multi-level network this NEMO gets, the longer
the delay becomes by dog-legged routing. This document specifies how
to optimize the routes between mobile nodes and correspondent nodes.
Also, this document provides a way to optimize DNS name resolution of
mobile nodes, through the autoconfiguration of recursive DNS server.
3. Overview
+---+ ******************* +---+
|CN1+---* Internet *---+CN2|
+---+ ******************* +---+
|
|
+-+-+
|AR1|
RA(AR1_P)| +-+-+
V |
----------+---------------+---------------+----------- Link1
|Proxy-mode |Proxy-mode
+-+-+ +------+ +-+-+ +------+
|MR1+--+RDNSS1| |MR2+--+RDNSS2|
RA(AR1_P)| +-+-+ +------+ RA(AR1_P)| +-+-+ +------+
V |Router-mode V |Router-mode
---+-----+-----+--- Link2 ---+------+-----+--- Link3
| | | Proxy-mode|
+-+-+ +-+-+ +-+-+ +-+-+
|MN1| |MN2| |MN3| |MR3|
+---+ +---+ +---+ +-+-+ | RA(AR1_P)
Router-mode| V
---+-----+-----+--- Link4
| |
+-+-+ +-+-+
|MN4| |MN5|
+---+ +---+
Figure 1. Multilink Subnet for Route Optimization
Jeong, et al. Expires - April 2004 [Page 3]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
The route optimization is possible by mobile router's performing ND-
Proxy, which makes a Care-of Address (CoA) with the prefix advertised
by access router and delivers the prefix of access network into the
NEMO. Each mobile node can make its new CoA with router
advertisement message including access network prefix and perform the
return routability and binding update procedure. As ND-Proxy, the
mobile router performs neighbor discovery instead of the mobile nodes
within its NEMO. Like this, through mobile router that performs ND-
Proxy, access network and NEMO are configured into a multilink subnet.
Figure 1 shows an example of a multilink subnet comprised of four
links from Link1 to Link4. Three mobile routers from MR1 to MR3
relay the prefix information of access network (AR1_P) that was sent
by an access router, AR1. Let's assume that the mobile nodes MN1 and
MN2 move into the mobile network managed by mobile router MR1 like
Figure 1. Also, let's assume that these visiting mobile nodes
communicate with the correspondent nodes, CN1 and CN2, respectively.
If these visiting mobiles can get the prefix of access network and
make their new CoA, through the binding update with their
correspondent node, they can communicate each other via optimized
path. This dissemination of access network's prefix is performed by
mobile router which becomes attached to a foreign access network, not
its home network. Likewise, MN3 can optimize the route through MR2.
MN4 and MN5 can perform route optimization through MR2 and MR3, too.
The optimization of DNS name resolution is possible by mobile
router's announcing the address of local recursive DNS server as well
as the prefix information of access network. In Figure 1, by DNS
Server option included in RA message, MR1 announces the address of
Recursive DNS Server, RDNSS1, within its mobile network to its
router-mode link, Link2. Therefore, mobile nodes within Link2, MN1
and MN2, can optimize their DNS name resolution by using local DNS
server, RDNSS1.
4. Neighbor Discovery extension
4.1 RO Prefix Information option format
The mechanism of this document needs the addition of a new flag
within prefix information option for route optimization [3]. When
this flag is set, it indicates that the prefix included in the option
can be used by mobile nodes within a NEMO for the route optimization.
Figure 2 shows the format of the modified prefix information option,
RO Prefix Information option, which is included in RA message.
Jeong, et al. Expires - April 2004 [Page 4]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|O|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Prefix Information Option Format for Route Optimization
Field:
O 1-bit route-optimization flag. When set indicates
that this prefix can be used for the route
optimization of mobile nodes within NEMO.
The RO Prefix Information option provides a mobile node with the
network prefix of access network and allows it to autoconfigure its
new CoA through stateless address autoconfiguration and to perform
binding update. The Prefix Information option appears in RA message
and MUST be silently ignored for other messages. L (On-link) flag
MAY be either 0 or 1. Namely, this route optimization can be either
on-link or off-link model [5]. A (Autonomous address-configuration)
flag MUST be 1, indicating IPv6 stateless address autoconfiguration.
4.2 Neighbor Solicitation (NS) message format
NS message MUST be extended for Duplicate Address Detection (DAD) for
the address based on RO prefix of access network. Therefore, there
is a need to discriminate between the normal NS message and extended
NS message for route optimization [3]. Figure 3 shows the format of
the modified NS message.
Jeong, et al. Expires - April 2004 [Page 5]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3. Extended Neighbor Solicitation Message Format
Fields:
M 1-bit multi-hop flag. When set indicates
that this NS message SHOULD be relayed to the other
links of multilink subnet.
Target IPv6 Address
The IPv6 address of the target of the solicitation
that will be used as CoA. It MUST NOT be a
multicast address.
4.3 DNS Server option format
DNS Server option contains the IPv6 address of the recursive DNS
server. When more than one DNS Server option are advertised, as many
DNS Server options as DNS servers are included in an RA message.
Figure 4 shows the format of DNS Server option [7].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pref | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeong, et al. Expires - April 2004 [Page 6]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
| |
+ +
| |
+ IPv6 Address of DNS Server +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. DNS Server Option Format
Fields:
Type 8-bit identifier of the option type (TBD: IANA)
Option Name Type
DNS Server (TBD)
Length 8-bit unsigned integer. The length of the
option (including the type and length fields)
in units of 8 octets. The value 0 is invalid.
Mobile nodes MUST silently discard a Neighbor
Discovery (ND) packet that contains an option
with length zero.
Pref The preference of a DNS server. A 4-bit unsigned
integer. A decimal value of 15 indicates the
highest preference. A decimal value of 0
indicates that the DNS server can not be used.
The field can be used for selecting an RDNSS
among multiple RDNSSes.
Valid Lifetime 32-bit unsigned integer. The maximum time, in
seconds, over which this DNS server is used for
name resolution. Mobile nodes should contact the
source of this information, mobile router, before
expiry of this time interval. A value of all one
bits (0xffffffff) represents infinity.
IPv6 Address of DNS Server
Recursive DNS Server's address for DNS name
resolution.
"Pref"=0 SHOULD require a "Valid Lifetime"=0 because the
corresponding DNS server SHOULD not be used any more.
Jeong, et al. Expires - April 2004 [Page 7]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
5. Mobile Router
Mobile router MUST process Prefix Information option for Route
Optimization (RO) and DNS Server option for DNS Optimization, which
are included in RA message.
5.1 Process of RO Prefix Information option
Only if the prefix announced by an access router is different from
the prefix of a mobile router's Home Address (HoA), the mobile router
MUST perform the role of ND-Proxy and relay the prefix information.
Before mobile router advertises the prefix information through Router
Advertisement (RA) message, it MUST set route-optimization flag
indicating that this prefix can be used for route optimization of
mobile nodes, which are either local mobile nodes or visiting mobile
nodes within the mobile network.
If a mobile node within a mobile network receives the new prefix
information option through RA message and can recognize this option,
it MAY prefer this new prefix information option to the normal prefix
information option that contains the mobile network prefix assigned
by the mobile router's home network. By performing binding update
with the prefix of the access network, the mobile node can optimize
the routes between its correspondent nodes and itself.
ND-Proxy MUST join the solicited-node multicast address(es) that
correspond to the IP address(es) assigned to the mobile node for
which it is proxying [3].
5.2 Process of DNS Server option
If mobile router has its own local RDNSS like MR1 and MR2 in Figure 1,
it SHOULD announce the address of RDNSS to its router-mode link(s).
If mobile router receives DNS Server option from its proxy-mode
link(s), it SHOULD relay the option to its router-mode link(s)
through its RA message. In case that mobile router has its own local
RDNSS, it announces the DNS Server option of its RDNSS with higher
precedence than those of other RDNSSes.
5.3 Delivery of Data Packets
After a mobile node gets a new CoA within a mobile network and
performs binding update associated with the address, the data packets
of correspondent node toward the mobile node are delivered to the
access network to which the NEMO containing the mobile node is
attached, via optimal path between the mobile and correspondent nodes.
Jeong, et al. Expires - April 2004 [Page 8]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
When the access router of the access network receives the data
packets, it multicasts normal Neighbor Solicitation (NS) message to
the solicited-node multicast address of the destination IPv6 address
in order to find out the link-layer address of the destination mobile
node. The mobile router, knowing the link-layer address of the
target, responds to the NS message by returning its own link-layer
address in a unicast Neighbor Advertisement (NA) message as ND-Proxy,
which knows the IPv6 addresses and link-layer addresses of mobile
nodes within its mobile network during the DAD of each CoA of each
mobile node.
When the access router knows the link-layer address to the
destination, it forwards the IPv6 data packets to the mobile router
corresponding to the link-layer address. The mobile router relays
the packets to the destination mobile node. In case that the NEMO
where the destination node is placed is multi-level, the packets are
relayed to the destination node by more than one mobile router.
6. Mobile Node
Mobile node MUST process Prefix Information option for Route
Optimization (RO) and DNS Server option for DNS Optimization, which
are included in RA message.
6.1 Procedure of Route Optimization
For route optimization, mobile node generates a new CoA based on the
access network prefix and performs binding update for the CoA.
6.1.1 Generation of a new CoA
Whenever a mobile node receives RA message containing RO prefix
information option that includes a new network prefix of access
network, it makes a new CoA.
6.1.2 DAD for the new CoA
The mobile node performs DAD for the new CoA through the extended NS
message. The NS message of DAD for the new address is relayed to the
other links by a mobile router, acting as ND-Proxy, on the link where
the mobile node is placed [5]. The mobile router memorizes the DAD
for returning NA message to the sender of the extended NS message.
If there is no NA returned and the DAD is successful, the mobile node
configures the verified address as its new CoA in its network
interface.
Jeong, et al. Expires - April 2004 [Page 9]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
Notice that the DAD for the link-local addresses and global addresses
based on mobile network prefix assigned by home network is performed
through normal NS message only within a link and the DAD for the
global addresses based on access network prefix is performed through
extended NS message within a multilink subnet, which is relayed by
ND-Proxies.
6.1.3 Return Routability and Binding Update
After configuring the new CoA, the mobile node performs the return
routability and binding update procedure of Mobile IPv6 [8]. If the
mobile node is visiting mobile node (VMN) for the mobile network
where it is present, or as local mobile node (LMN), moves into
another link of the mobile network to which its home link belongs to,
it SHOULD perform binding updates with both its home agent and
correspondent nodes. In case that as LMN, the mobile node is present
at home link and receives RO prefix information option, namely when
the mobile node's HoA and CoA belong to the same link, it SHOULD
perform not deregistration with its home agent which is its mobile
router simultaneously, but binding updates with both its home agent
and correspondent nodes.
6.2 Procedure of DNS Optimization
The optimization of DNS name resolution is possible by mobile
router's announcing the address of local recursive DNS server as well
as RO prefix information through RA message [7]. The DNS server can
exist either within mobile network or within access network. The
address of recursive DNS server is delivered to mobile nodes through
DNS Server option, one of RA options. Especially, visiting mobile
nodes will optimize their DNS name resolution effectively by using
local recursive DNS server.
6.2.1 RDNSS Configuration
The addresses of DNS servers are announced by DNS Server options in
RA message. These addresses can be used for recursive DNS service
providing DNS name resolution. If mobile node receives DNS Server
option, it SHOULD store RDNSS's address in the configuration file for
its DNS resolver; i.e., /etc/resolv.conf in UNIX.
6.2.2 RDNSS Selection
When mobile node perceives multiple RDNSSes through RA message, it
stores the RDNSS addresses in order into the configuration file which
its DNS resolver uses for DNS name resolution on the basis of the
value of "Pref" field in the DNS Server option. The following
algorithm is simply based on the rule of selecting an RDNSS in the
Jeong, et al. Expires - April 2004 [Page 10]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
order from the most preferred RDNSS, provided that its preference
value is not zero. The processing of the DNS Server option received
in RA message by a mobile node is as follows:
For each DNS Server option:
Step (a) : Receive and parse all DNS Server options.
Step (b) : Arrange the addresses of RDNSSes in a descending order, in
the respect of preference value, namely starting with the
biggest value of "Pref" field of the DNS Server option and
store them in the configuration file used by resolver for
DNS name Resolution (DNS configuration).
Step (c) : For each DNS Server option, check the following: If the
Value of "Pref" or "Valid Lifetime" field is set to zero,
exclude the corresponding RDNSS entry from the list of
RDNSSes of DNS configuration in order to let the RDNSS not
used any more.
Whenever the DNS resolver on the mobile node performs the name
resolution, it refers to the address of RDNSS in order from the first
RDNSS stored in its DNS configuration. Like this, in case that there
are several mobile routers advertising RDNSS in a multilink subnet,
"Pref" field is used to select RDNSS.
7. Security Considerations
The route optimization and DNS optimization in this document does not
add any other security problems to the NEMO, Mobile IPv6, or Neighbor
Discovery (ND) protocols. Security issues regarding the ND protocol
are being discussed in IETF SEND (Securing Neighbor Discovery)
working group [9].
8. Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society July 12, 2001. All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
Jeong, et al. Expires - April 2004 [Page 11]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
IP version 6", RFC 2461, December 1998.
[4] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[5] Dave Thaler and Chistian Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, June 2002.
[6] Thierry Ernst, "Network Mobility Support Terminology", draft-
ietf-nemo-terminology-00.txt, May 2003.
[7] Jaehoon Jeong, Soohong D. Park, Luc Beloeil and Syam Madanapalli,
"IPv6 DNS Discovery based on Router Advertisement", draft-jeong-
dnsop-ipv6-dns-discovery-00.txt, July 2003.
10. Informative References
[8] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-22.txt, May 2003.
Jeong, et al. Expires - April 2004 [Page 12]
Internet-Draft ND-Proxy based Route Optimization for MN October 2003
[9] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt,
June 2003.
11. Acknowledgements
The authors would like to acknowledge the previous contribution of
Dave Thaler and Christian Huitema.
12. Authors' Addresses
Jaehoon Paul Jeong
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 1664
EMail: paul@etri.re.kr
Kyeong-Jin Lee
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6484
EMail: leekj@etri.re.kr
Jung-Soo Park
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Hyoung-Jun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6576
EMail: khj@etri.re.kr
Jeong, et al. Expires - April 2004 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 03:49:59 |