One document matched: draft-wakikawa-netext-lma-reliability-01.txt
Differences from draft-wakikawa-netext-lma-reliability-00.txt
NETEXT Working Group R. Wakikawa
Internet-Draft Toyota ITC
Intended status: Standards Track J. Xia
Expires: April 26, 2010 Huawei
October 23, 2009
PMIP extension to Home Agent Reliability Protocol
draft-wakikawa-netext-lma-reliability-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on April 26, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document introduces an extension to the Home Agent Reliability
protocol standardized in MEXT Working Group for LMA reliability. In
Wakikawa & Xia Expires April 26, 2010 [Page 1]
Internet-Draft LMA Reliability October 2009
Proxy Mobile IPv6 [RFC5213], LMA is an anchor which is similar to
Home Agent of Mobile IPv6 [RFC3775]. Providing LMA reliability is
achieved with the extensions described in this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. LMA Failure Detection . . . . . . . . . . . . . . . . . . . . 4
4. LMA Virtual Switch Mode . . . . . . . . . . . . . . . . . . . 5
5. LMA Hard Switch Mode . . . . . . . . . . . . . . . . . . . . . 5
5.1. LMA Operation . . . . . . . . . . . . . . . . . . . . . . 6
5.2. MAG Operation . . . . . . . . . . . . . . . . . . . . . . 7
6. Mobility Options and Messages . . . . . . . . . . . . . . . . 8
6.1. Proxy Binding Cache Information Mobility Option . . . . . 8
6.2. LMA Failure Indication Mobility Option . . . . . . . . . . 10
6.3. LMA Inter Switch Message . . . . . . . . . . . . . . . . . 11
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Wakikawa & Xia Expires April 26, 2010 [Page 2]
Internet-Draft LMA Reliability October 2009
1. Introduction
This document specifies small extensions to the Home Agent
Reliability protocol [ID-HARELIABILITY]. Local Mobility Anchor (LMA)
acts as an anchor point in Proxy Mobile IPv6, while Home Agent (HA)
is used in Mobile IPv6 [RFC3775]. Therefore, this specification aims
to support LMA reliability for Proxy Mobile IPv6. Since mobility
managements are not handled by a mobile node, LMA failure and
recovery must be fully transparent to the mobile node. All the
operations defined in this specification are completed between LMA
and Mobile Access Gateways (MAGs).
Figure 1 shows the network configuration of LMAs in a Proxy Mobile
IPv6 domain. MN1 and MN2 anchor on LMA1 and LMA2 respectively, but
share one common MAG. LMA1' is a standby LMA for LMA1, they share
same address (i.e.LMAA1). Hence it is assume that the pair execute
as virtual-swith mode for MN1; While LMA2' is a standby LMA for LMA2,
they own individual address (i.e.LMAA2 and LMAA2'). The pair execute
as hard-switch mode for MN2.
+--Virtual--+ +---Hard---+
+----+ +-----+ +----+ +-----+
|LMA1| |LMA1'| |LMA2| |LMA2'|
+----+ +-----+ +----+ +-----+
LMAA1 -> | LMAA1 ->| LMAA2-> | LMAA2'-> |
| | | |
\\ || // //
\\ || // //
\\ || // //
+---\\--- ||---------//---- //-------+
( \\ || // // )
( \\ \\ // // )
+------\\--||-----//---//----------+
\\ || // //
\\|| // //
\\\\ ////
Proxy-CoA --> |
+-----+
| MAG |-----{MN2}
+-----+ |
| |
MN-HNP1 --> | MN-HNP2
{MN1}
Figure 1: LMA Network Configuration
Besides the failure detection mechanism specified in
[ID-HARELIABILITY], there exists other specific mechanism for LMA
Wakikawa & Xia Expires April 26, 2010 [Page 3]
Internet-Draft LMA Reliability October 2009
failure detection. A detailed description will be given in Section
3. The Home Agent Reliability protocol has a hard-switch and
virtual-switch operational modes, and this specification supports
both of them. All the assumptions are same as [ID-HARELIABILITY]
such as IPsec synchronization, same LMA Address configuration in
virtual-switch mode, etc. For example, if LMAA1 and LMAA1' are same
address, the operation can be virtual-switch mode. On the other
hand, if they are different, it should be hard-switch mode. Detailed
operations will be given in Section 4 and Section 5. While a
detailed description of new mobility option and message will be given
in Section 6.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All terms in this document are defined in[RFC5213], [ID-HEARTBEAT]
and [ID-HARELIABILITY]. In addition or in replacement of these, the
following terms are defined or redefined:
Current LMA
A LMA that is currently serving the MAGs. When the tunnel failure
is caused by path between the LMA and MAG fail, the LMA maybe
still keep active but not serving MAG.
3. LMA Failure Detection
LMA Failure events used in the Local Mobility Anchor Reliability
protocol are listed below.
Detection Mechanism in section 7.2 of [ID-HARELIABILITY]
Three mechanisms are defined in [ID-HARELIABILITY] such as Loss of
HA-HELLO, Monitored Server Failure by the Active HA, Routing Peer/
Link Failure. Each LMA should exchange HA-HELLO for failure
detection.
Heartbeat Mechanism for Proxy Mobile IPv6 in section 3.1 of
[ID-HEARTBEAT]
In Proxy Mobile IPv6, both LMA and MAG should involve in detecting
LMA failure. Heartbeat mechanism specified in section 3.1
[ID-HEARTBEAT] can be used as an indication of LMA failure. If a
Wakikawa & Xia Expires April 26, 2010 [Page 4]
Internet-Draft LMA Reliability October 2009
LMA detects the tunnel failure with one, some or all MAGs, it can
treats this events as a hint of LMA failure. However, the LMA
SHOULD NOT start the failover as soon as it detects the failure
events by using heartbeat detecting mechanism. It is because the
heartbeat detecting mechanism detects only the tunnel failure.
The tunnel failure might be caused by the path between MAG and LMA
failure or other reasons than LMA failure. In case of path
failure,it is likely that virtual-switch mode does not help. The
assumption is that in virtual-switch mode the LMA and LMA' share
the same LAN or the subnet, which would mean both get unreachable
when path dies. Therefore, heartbeat detecting mechanism only fit
for the hard-switch mode. If a MAG detects LMA failure, it can
solicit a standby LMA to recover the current LMA. MAG cannot
reach to the standby LMA until the standby LMA completes taking
over the current LMA.
4. LMA Virtual Switch Mode
In the virtual-switch mode, each LMA is configured with a same LMA
address (LMAA). A standby LMA MUST support the IPsec states and
Proxy Binding Cache information synchronization functionality for
this virtual switch mode. However, the scope of LMA Reliability
protocol is limited to the management of Proxy Mobile IPv6 related
states. Thus, only Proxy Binding Cache information synchronization
is token into account and given description in section 6.1. As soon
as LMA failure is detected, the standby LMA becomes active and takes
over the failed LMA as defined in[ID-HARELIABILITY].
5. LMA Hard Switch Mode
In the hard-switch mode, each LMA is configured with different LMA
address (LMAA). A standby LMA should creates security association
with MAGs beforehand, and it must launch Proxy Binding Cache
information synchronization as same as in virtual switch mode. It
can also establishes a tunnel with MAGs before LMA failure.
In this case that LMA-HELLO mechanism is employed in LMA failure
detection, the concrete procedure of LMA hard-switch is similar to
operation specified in [ID-HARELIABILITY]. As soon as LMA failure is
detected, the standby LMA should send HA switch message to each MAG
for which the current LMA served. Note that HA switch message is
sent for per MAG than per MN attched on the MAG. Even so, if there
are large amounts of MAGs served by the failed LMA, the overhead
caused by sending HA Switch messages is still non-negligible.
In this case that Heartbeat Mechanism defined in [ID-HEARTBEAT] is
Wakikawa & Xia Expires April 26, 2010 [Page 5]
Internet-Draft LMA Reliability October 2009
employed in LMA failure detection, MAG needs to actively involve in
detecting LMA failure. After a MAG establishes IPsec/IKE states with
all the LMAs in the redundant LMA set beforehand, MAG needs to
trigger heartbeat exchanges with each LMA respectively for checking
peers reachability. If the path between MAG and LMA fails rather
than LMA fails, it will result mobility session discontinuity for MAG
attached on LMA. However, the LMA is still active. In this case,
LMA-HELLO mechanism cannot detect the failure, and more further
considerations are needed.
The following subsections will only focus on the concrete solution to
solve this problem of the tunnel failure.
5.1. LMA Operation
If a MAG detects a path failure with the current LMA, the MAG SHOULD
solicit a standby LMA, with which MAG pre-establishes IPsec/IKE
state.
Usually the current LMA can also detect the path failure using the
heartbeat mechanism [ID-HEARTBEAT]. However the current LMA MUST NOT
solicit the standby LMA to takeover itself because the unreachability
may be caused by a MAG failure, and the current LMA should not know
whether the path between the MAG and the standby LMA is active or
not.
Upon receiving PBU message from the MAG with LMA failure indication,
the standby LMA MUST include Proxy-CoA of MAG in LMA Inter
SwitchRequest Message as specified in section 6.3 to notify the
current LMA that packets of the MAG will be routed to the standby LMA
instead of the current LMA. Whereas in this case, the current LMA
should not transit to standby state and still provide mobile service
for other reachable MAGs. At that time, two LMA are both available
for different MAGs respectively. More details are shown in Figure 2.
Wakikawa & Xia Expires April 26, 2010 [Page 6]
Internet-Draft LMA Reliability October 2009
MAGs LMA1(Current) LMA2(Standby)
| | |
| X |
|---------------------->| 1. Sending PBU message (with LMA
| X | failure indication)
| X |
| X<----------| 2. LMA2 sends LMA Inter Switch Request (with PCoA option)
| X---------->| 3. LMA1 sends LMA Inter Switch Reply
| X |
|<----------------------| 4. Binding PBA message
| X |
| X<----------| 5. LMA2 sends LMA Inter Switch Complete (optional)
| X |
| X | RECOVERY COMPLETE
Figure 2: LMA Opertation in LMA Hard Switch
In case that the tunnel failure is caused by broken LMA1, but not by
the path between the MAG and the current LMA, step2 & step3 would not
work at all and can be skipped.
5.2. MAG Operation
MAG needs to discover multiple LMA addresses, according to the
multiple LMAs discovery specified in section 2.2 of
[ID-LMADISCOVERY], MAG can discover more than one LMA in a PMIP
domain based on LMA FQDN if operator actually configures its DNS in
such way. Afterward, MAG authenticates itself to multiple LMAs and
creates IPsec SAs with them as defined in [ID-HARELIABILITY].
When MAG sends heartbeat request message to active LMA beyond
MISSING_HEARTBEATS_ALLOWED amount without response, MAG concludes
that the current LMA is unreachable. In this case, MAG indictates
current LMA failure to a reachable standby LMA and solicits the
standby LMA to takeover the current LMA. It is important to remark
that MAG sending PBU per MN will introduce high overhead. Therefore,
bulk registration mechanism specified in [ID-BULKREGISTER] is
recommended to mitigate the overhead. Even so, the overhead is still
unavoidable in the case that there are large amounts of MAGs served
by the current LMA.
MAG initiates proxy binding update message to the standby LMA with
LMA failure indication. Standby LMA MUST respond proxy binding
aknowledge message until standby LMA completes taking over the
current LMA. The overview of operation is shown in Figure 3.
Wakikawa & Xia Expires April 26, 2010 [Page 7]
Internet-Draft LMA Reliability October 2009
MAG LMA1(Current) LMA2(Standby)
| | |
|<--------------------->| 1. IKEv2 exchange
|---------->| | 2. Proxy Binding Update
| | | 3. LMA1 allocate MN-HNP, Setup BCE
|<----------| | 4. Proxy Binding Acknowledgment
| | |
|<--------------------->| 5. IKEv2 exchange
| | |
| |<--------->| 6. State exchange (proxy binding cache)
| | |
|<--------->X | 7. HeartBeat exchange overtime
| X |
|---------------------->| 8. Proxy Binding Update (with LMA failure
| X | indication)
| X |
|<----------------------| 9. Proxy Binding Acknowledgment
| X |
| X | RECOVERY COMPLETE
Figure 3: MAG Opertation in LMA Hard Switch
6. Mobility Options and Messages
6.1. Proxy Binding Cache Information Mobility Option
The LMA Reliability protocol extends Binding Cache Information Option
specified in section 5.2.2 of [ID-HARELIABILITY].
The proxy binding cache information option has an alignment
requirement of 4n+2. The Proxy Binding Cache Information option is
only valid in a State Synchronization message. Its format is as
follows:
Wakikawa & Xia Expires April 26, 2010 [Page 8]
Internet-Draft LMA Reliability October 2009
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 = TBD | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Proxy Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ ~
~ Mobile Node Mobility Options ~
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Cache Information Option
Besides of Tunnel Interface ID Option and Proxy Care-of Address
option, each LMA also MUST carry the Mobile Node Mobility Options in
Proxy Binding Cache Information Option in the State Synchronization
message. Mobile Node Mobility Options are very similar to Mobility
Options specified in [RFC5213].
1. Mobile Node Identifier Option (mandatory)
2. Home Network Prefix option (mandatory)
3. Access Technology Type option (mandatory)
4. Timestamp Option (optional)
5. Mobile Node Link-layer Identifier option (optional)
6. Link-local Address option (optional)
All the fields of Mobile Node Mobility Options in Proxy Binding Cache
information option are copied from the registered proxy binding of
one or more particular mobile nodes. The 8-bit Reserved field MUST
Wakikawa & Xia Expires April 26, 2010 [Page 9]
Internet-Draft LMA Reliability October 2009
be set to zero.
6.2. LMA Failure Indication Mobility Option
The LMA Reliability protocol includes this option in PBU message as
an indication to the standby LMA that the MAG detected the path
failure and solicit the standby LMA to takeover the current LMA's
role. The LMA Failure Indication mobility option in the PBU MUST
contain the IPv6 addresses of the current LMA. The LMA Failure
Indication mobility option in the PBU MAY contain the IPv4 addresses
of the current LMA.
The LMA Failure Indication mobility option has the alignment
requirement of 4n+2. There can zero or only one LMA Failure
Indication mobility option in the PBU. The format of the LMA Failure
Indication mobility option is shown below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 current LMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 current LMA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: LMA Failure Indication Mobility Option
Type
8-bit unsigned integer. TBD
Length
8-bit unsigned integer indicating the length in octets of the
option, excluding the type and length fields. If the IPv4 LMA
Addresses are included in the option, the Option Length MUST be
set to 20. Otherwise, the Option Length MUST be set to 16.
IPv6 current LMA Address
Wakikawa & Xia Expires April 26, 2010 [Page 10]
Internet-Draft LMA Reliability October 2009
the IPv6 address of the current LMA.
Optional IPv4 current LMA Address
the IPv4 address of the current LMA.
6.3. LMA Inter Switch Message
The LMA Reliability protocol creats this message for the LMA hard-
switch, which is similar with HA Control message defined in section
5.1.2 of[ID-HARELIABILITY]. When a standby LMA receives PBU message
from a MAG with LMA failure indication, it MUST include Proxy-CoA of
the MAG in MAG Address Option in LMA Inter Switch Request Message
(type field of LMA Inter Switch Message is 0) to notify the current
LMA that packets of the MAG will be routed to the standby LMA instead
of the current LMA from then on.
If the current LMA also detects the MAG unreachability using
heartbeat exchange, the current LMA should log the event and respond
LMA Inter Switch Reply Message (type field of LMA Inter Switch
Message is 1) to the standby LMA as soon as receiving LMA Inter
Switch Request Message from the standby LMA.
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 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 MAG Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 MAG Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: LMA Inter Switch Message
Type
8-bit unsigned integer. The type value is 0 to indicate as LMA
Inter Switch Request Message; The type value is 1 to indicate as
LMA Inter Switch Reply Message.
MAG Address
Wakikawa & Xia Expires April 26, 2010 [Page 11]
Internet-Draft LMA Reliability October 2009
The IPv6 or IPv4 address of the MAG need to switch LMA. The
standby LMA should take over all sessions of the MNs attached on
the MAG.
7. IANA considerations
This document defines three new mobility options to the Mobility
Options registry (in [RFC3775]) for using LMA reliability:
o Proxy Binding Cache Information Mobility Option:
A new mobility option is used to synchronizing Proxy Binding Cache
information of MAG in State Synchronization message between LMAs.
This option is specified in section 6.1.
o LMA Failure Indication Mobility Option:
A new mobility option is used to indicate current LMA failure to
standby LMA. This option is specified in section 6.2.
o LMA Inter Switch Message:
A new mobility message is used to switch LMA responsibility from a
current LMA to a standby LMA for MAG. This message is specified
in section 6.3.
8. Security Considerations
No security vulnerability is introduced in this specification. All
the signaling are protected as described in [ID-HARELIABILITY] and in
[RFC5213].
9. Acknowledgments
The authors would like to specially thank Jouni Kornohen for his
contributions to this document and detailed reviews.
The authors also thank the following individuals for their
contributions, comments and suggestions to this document: Sri
Gundavelli,etc.
10. References
Wakikawa & Xia Expires April 26, 2010 [Page 12]
Internet-Draft LMA Reliability October 2009
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
"Mobility Header Home Agent Switch Message", RFC 5142,
January 2008.
[ID-HARELIABILITY]
Wakikawa, R., "Home Agent Reliability Protocol",
draft-ietf-mip6-hareliability-04.txt (work in progress),
July 2008.
[ID-HEARTBEAT]
Devarapalli , V., "Heartbeat Mechanism for Proxy Mobile
IPv6", draft-ietf-netlmm-pmipv6-heartbeat-04 (work in
progress), February 2009.
10.2. Informative References
[ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), January 2009.
[ID-LMADISCOVERY]
Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy
Mobile IPv6", draft-korhonen-netlmm-lma-discovery-00 (work
in progress), October 2008.
[ID-BULKREGISTER]
Premec, D., Gundavelli, S., and K. Leung, "Bulk Re-
registration for Proxy Mobile IPv6",
draft-premec-netlmm-bulk-re-registration-03 (work in
progress), October 2009.
[ID-GENERICSIGNALING]
Haley, B. and S. Gundavelli, "Mobile IPv6 Generic
Signaling Message",
draft-ietf-mext-generic-signaling-message-00 (work in
progress), February 2009.
Wakikawa & Xia Expires April 26, 2010 [Page 13]
Internet-Draft LMA Reliability October 2009
Authors' Addresses
Ryuji Wakikawa
Toyota ITC
465 Bernardo Avenue
Mountain View, CA 94043
USA
Email: ryuji@us.toyota-itc.com
Jinwei Xia
Huawei
Hui Hong Mansion
Nanjing, Baixia District 210001
China
Phone: +86-025-84565890
Email: xiajinwei@huawei.com
Wakikawa & Xia Expires April 26, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 13:13:55 |