One document matched: draft-jeyatharan-netext-pmip-dormant-binding-00.txt
NetExt Working Group M. Jeyatharan
Internet-Draft C. Ng
Intended status: Standards Track Panasonic
Expires: April 19, 2010 October 16, 2009
Fast Handoff using Dormant Bindings in PMIPv6
draft-jeyatharan-netext-pmip-dormant-binding-00
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 19, 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
A multiple interfaced mobile node (MN) may be connected to Proxy
Mobile Internet Protocol version 6 (PMIPv6) domain via a stable
access connection (e.g. cellular) and an unstable access connection
Jeyatharan & Ng Expires April 19, 2010 [Page 1]
Internet-Draft Dormant Binding October 2009
(e.g. IEEE 802.11). To eliminate packet loss and handoff delay due
to disconnection of the unstable access, a dormant binding method is
proposed access such that a binding is maintained in dormant mode in
the network until the mobile node is disconnected from the unstable
access. Once activated, the binding allows the network to route data
packets intended for the unstable access via the stable access
connection.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem and Motivation . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Dormant Binding . . . . . . . . . . . . . . . . . 5
3.1. Dormant Binding Operation when Disconnection via
Unstable Access . . . . . . . . . . . . . . . . . . . . . 5
3.2. Dormant Binding Operation when there is change in MAG . . 6
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Dormant Binding Update (DBU) Message . . . . . . . . . . . 7
4.2. Dormant Binding Acknowledgement (DBA) Message . . . . . . 8
4.3. Unsolicited PBA Message (UnSol-PBA) . . . . . . . . . . . 9
4.4. Unsolicited DBA Message (UnSol-DBA) . . . . . . . . . . . 10
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Signaling and Data Related MAG Operations . . . . . . . . 11
5.2. Signaling and Data Related LMA Operations . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13
8.2. Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Jeyatharan & Ng Expires April 19, 2010 [Page 2]
Internet-Draft Dormant Binding October 2009
1. Introduction
Proxy Mobile IPv6 protocol (RFC-5213 [1]) allows a mobile node to be
connected to the PMIPv6 domain via multiple interfaces and see
different prefixes via different interfaces. For example, one of the
interface may be attached to a third generation cellular (3G) access
which provides stable connectivity of moderate bandwidth. Another
interface may be attached to a wireless local area network (WLAN)
such as IEEE 802.11 where the WLAN cells are sporadically dispersed
and hence providing unstable connectivity of higher bandwidth.
Ideally, the mobile node will want to reduce the handoff delay and
packet loss due to the disconnection in the unstable access.
Existing fast handoff mechanisms that address handoff delay related
issues are highlighted in RFC 5268 [2] and ID-PFMIPv6 [3].
These methods usually requires prediction of handover to achieve true
seamless mobility, which is difficult to achieve for the unstable
access, and is also unsuitable for the scenario where two connections
are available, as described above. This draft proposes a fast
handoff mechanism, which we refer to as "dormant binding mechanism".
In essence, it allows the mobile node to set up a binding between two
accesses such that flows can be immediately re-directed from one
access to another when the first access is disconnected suddenly.
In this draft, we will first highlight the handoff issues in the
environment where the mobile node has a stable access and looses
connectivity via the unstable access in Section 2. Following that,
Section 3 gives an overview of the dormant binding operation. In
Section 4, the message format for messages are given and finally
Section 5 highlights the operation of the architectural entities.
2. Problem and Motivation
To illustrate the problem, we consider the scenario where a mobile
node MN has a cellular 3G access and a WLAN access connected to the
PMIPv6 domain. Normally, the MN would want flows to pass through its
WLAN access for cost and bandwidth consideration. Hence, the
cellular interface is left in an idle mode whenever WLAN access is
available. When WLAN access is lost, session continuity is
maintained by transferring the prefix given to the WLAN interface to
the 3G interface. The message sequence diagram in Figure 1
illustrates this handoff using existing PMIPv6 mechanism.
Jeyatharan & Ng Expires April 19, 2010 [Page 3]
Internet-Draft Dormant Binding October 2009
+-----+ +----------+ +------------+ +-----+
| MN | | MAG1(3G) | | MAG2(WLAN) | | LMA |
+-----+ +----------+ +------------+ +-----+
| | | |
|<----- RA(P1) -----| | |
| | | |
|<----- RA(P2) -----------------------| |
| | | |
t0: Disconnection in WLAN | |
| | |------ Dereg PBU ---->|:t1
|----- Handoff ---->| | |
| trigger |-------------- PBU(P2,HI=2) ----------->|:t2
| | | |
| |<------------- PBA(P2,HI=2) ------------|
t3:|<--- RA(P1,P2) ----| | |
Figure 1: Handoff delay when flow transfer via Stable Access
Initially, the mobile MN receives prefix P1 on its 3G interface via
MAG1 and prefix P2 on its WLAN interface via MAG2. At time t0, the
WLAN access is lost, triggering MAG2 to send a de-registration PBU to
LMA. The mobile node MN will also send an access specific handoff
trigger to MAG1 via its 3G access to indicate vertical handoff of
prefix P2 to its 3G connection. This will trigger MAG1 to send a PBU
to LMA, which is received at time t2. After checking the validity of
this PBU, LMA accepts the proxy binding, and response with a PBA
indicating the successful transfer of P2. The mobile node can then
start transmitting packets for session with P2 once it sees the
prefix P2 advertised on its cellular interface at time t3.
We can see that from time t0 ~ t3, the mobile node MN cannot transmit
any packets for session with prefix P2. This is called the outgoing
handoff delay. Also, any incoming packets arriving from time t0 ~ t1
at LMA will be delivered to MAG2 and thus be discarded. If the LMA
does not perform packet buffering, the packet loss vulnerable period
will be extended to time t2. If MAG2 does not detect the loss of
access or does not send the optional de-registration PBU, the packet
loss vulnerable period will also be extended to time t2.
We note that the outgoing handoff delay t0 ~ t3 and the incoming
packet loss period t0 ~ t1/t2 is too excessive considering that the
mobile node has an alternate route to the LMA -- that is via the
stable 3G connection. The motivation for the dormant binding
mechanism is to reduce these time periods as much as possible. To
achieve this, the dormant binding mechanism has some important design
features. Firstly, a binding is set-up well before disconnection so
that the network entities (MAG and LMA) knows where to transfer the
flows should a disconnection event take place. Secondly, the
Jeyatharan & Ng Expires April 19, 2010 [Page 4]
Internet-Draft Dormant Binding October 2009
triggering rules for fast handoff mechanism is very clearly defined
such that when the disconnection happens, both MAG2 and LMA will
immediately starts forwarding the data packets received to MAG1. The
overview of how this can be achieved is described next.
3. Overview of Dormant Binding
3.1. Dormant Binding Operation when Disconnection via Unstable Access
Here, we use the same scenario as described in Section 2 to
illustrate the operation of the dormant binding mechanism. Figure 2
shows the message sequence diagram.
+-----+ +----------+ +------------+ +-----+
| MN | | MAG1(3G) | | MAG2(WLAN) | | LMA |
+-----+ +----------+ +------------+ +-----+
|<----- RA(P1) ----| | |
| | | |
|<----- RA(P2) ---------------------| |
| | | |
|--- Dormant Binding Indication --->| |
| (P2 to P1) |------- DBU ------->|
| | | |
| | |<---- DBA(MAG1) ----|
| | | |
. . . .
| | | /---|<-Data1
Disconnection in WLAN |-- Dereg PBU --/--->|
| | |<--- Data1 ---/ |
|<---- Data1 ------|<---- Data1 ----| |
| | | |
|<--- RA(P1,P2) ---|<------------ PBA(P1,P2) ------------|
| | | |
Figure 2: Dormant Binding Operation during Disconnection
When the mobile node MN decides to set up a dormant binding, it will
send an access-specific indication to MAG2 for the dormant binding of
P2 to P1. Since MAG2 does not know which mobile access gateway is
proxying for the prefix P1, it will need to ask the LMA. Hence, a
new PMIPv6 message called the Dormant Binding Update (DBU) is sent
from MAG2 to LMA. This DBU serves two purposes. Firstly, it allows
MAG2 to query the LMA which node is proxying for prefix P1.
Secondly, it is also used to set up a dormant binding of P2 to P1 at
the LMA. Hence, whenever the mobile node sets up a dormant binding
at its MAG, the dormant binding is actually registered in two nodes:
the MAG and the LMA.
Jeyatharan & Ng Expires April 19, 2010 [Page 5]
Internet-Draft Dormant Binding October 2009
Once the LMA accepts the dormant binding, it replies with a Dormant
Binding Acknowledgement (DBA). This will carries the address of the
MAG that is currently proxying for prefix P1 (i.e. MAG1). From this
DBA, MAG2 will know which node to forward packets to should the
dormant binding be triggered.
Consider that some time later, the WLAN access gets disconnected.
Once MAG2 detects the disconnection, in addition to sending a de-
registration PBU to LMA, MAG2 will also activates the dormant
binding. Hence when an incoming packet (say, Data1) arrives at MAG2
after the dormant binding is activated, MAG2 will forward the packet
Data1 to MAG1 for delivery.
The de-registration PBU will also act as a trigger to activate the
dormant binding registered at LMA. Hence, without having to wait for
the PBU with HI=2 to be sent by MAG1 (not shown in Figure 2), the LMA
can immediately send an Unsolicited Proxy Binding Acknowledgement
(PBA) to transfer prefix P2 to MAG1.
3.2. Dormant Binding Operation when there is change in MAG
Although unlikely in the usual scenario, it is possible for the
mobile node to experience a handover of mobile access gateways for
its stable interface. In this case, the dormant binding registered
at the MAG of the unstable access needs to be updated. Figure 3
illustrates how this is done.
+-----+ +----------+ +----------+ +------------+ +-----+
| MN | | MAG1(3G) | | MAG3(3G) | | MAG2(WLAN) | | LMA |
+-----+ +----------+ +----------+ +------------+ +-----+
| | | | |
|<--- RA(P1) ----| | | |
| | | | |
|<--- RA(P2) -------------------------------| |
| | | | |
|------ Dormant Binding Indication -------->|----- DBU ----->|
| (P2 to P1) | | |
| | | |<-- DBA(MAG1) --|
| | | | |
Handover occurs in 3G Access (MAG1->MAG3) | |
| | |-------- PBU(P1,HI=3) ------->|
| | | | |
|<--- RA(P1) -----------------|<------- PBA(P1,H1=3) --------|
| | | | |
| | | |<-- DBA(MAG3) --|
| | | | |
Jeyatharan & Ng Expires April 19, 2010 [Page 6]
Internet-Draft Dormant Binding October 2009
Figure 3: Dormant Binding Operation during MAG Change
When a handover of MAG occurs, MAG3 will send a PBU with HI=3 to LMA
to complete the horizontal handoff. The LMA will perform two actions
upon receiving this PBU. Firstly, it will respond with a PBA as
specified in PMIPv6. Secondly, since there is a dormant binding
registered for P2 to P1, it will notify the MAG that is currently
proxying for P2 that the dormant binding target has changed. Hence,
an Unsolicited DBA will be sent to MAG2 to inform MAG2 that the
dormant binding target is now MAG3.
4. Message Formats
This section highlights the message formats for the new messages that
were mentioned in Section 3. The new messages are the DBU, DBA,
Unsolicited PBA and Unsolicited DBA messages described in Section 3.
The dormant binding indication originating from the mobile node is
considered access specific and is not defined in this draft.
4.1. Dormant Binding Update (DBU) Message
The DBU message is sent from the MAG to the LMA. It is a normal PBU
message as defined in RFC-5213 [1] with a new mobility option called
the Dormant Binding mobility option attached. As mentioned
previously, this message is used to establish dormant binding at LMA
and also used to create fast handoff tunnel between the MAGs
connected to the interfaces of the mobile node. This new dormant
binding mobility option carries the mobile node's stable 3G interface
IP address. The Dormant Binding mobility option is shown in
Figure 4. The DBU message contains the mandatory mobility options
such as mobile node identifier option (MN-ID), home network prefix
option (HNP), access technology type option (ATT) and handoff
indicator (HI) option in addition to the new DBU mobility option.
Description of these mandatory mobility options are given in RFC-5213
[1].
Jeyatharan & Ng Expires April 19, 2010 [Page 7]
Internet-Draft Dormant Binding October 2009
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Stable Interface IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Dormant Binding Mobility Option
Type
To be assigned by IANA. Identifies the Dormant Binding mobility
option.
Length
This field carries a 8-bit unsigned integer indicating the length
of the option in octets, excluding the type and length fields.
Reserved
The value MUST be initialized to 0 by the sender and MUST be
ignored by the receiver.
Stable Interface IP Address
IP address of the stable interface (example 3G interface of mobile
node). This IP address can be an IPv6 address or an IPv4 address.
4.2. Dormant Binding Acknowledgement (DBA) Message
The purpose of the DBA message is to provide information about the
stable MAG address. This DBA message will be a normal PBA message as
defined in RFC-5213 [1] with a new mobility option called the Dormant
Target Address mobility option attached to it. The Dormant Target
Address mobility option is shown in Figure 5. The DBA message, in
addition to the Dormant Target Address mobility option will contain
all the mobility options that were included in the Forward DBU
message.
Jeyatharan & Ng Expires April 19, 2010 [Page 8]
Internet-Draft Dormant Binding October 2009
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target MAG IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Dormant Target Address Mobility Option
Type
To be assigned by IANA. Identifies the Dormant Target Address
mobility option.
Length
This field carries a 8-bit unsigned integer indicating the length
of the option in octets, excluding the type and length fields.
Reserved
The value MUST be initialized to 0 by the sender and MUST be
ignored by the receiver.
Target MAG IP Address
IP address of the MAG that is connected to the stable interface of
the mobile node.
4.3. Unsolicited PBA Message (UnSol-PBA)
The Unsolicited PBA message is sent by the LMA to the MAG connected
to the stable interface of the mobile node. This message is used to
inform the MAG that an additional prefix (specified in a Home Network
Prefix option in the Unsolicited PBA message) is being transferred to
the connection proxied by the MAG. The Unsolicited PBA message is
represented as a normal PBA message with a new 'U' bit in the
reserved field of the PBA message to indicate that this is an
Unsolicited acknowledgement from LMA. The Unsolicited PBA message
also contains a HNP option and this option is used to carry the
prefix tied to the unstable interface of the mobile node. Figure 6
Jeyatharan & Ng Expires April 19, 2010 [Page 9]
Internet-Draft Dormant Binding October 2009
shows the Unsolicited PBA message format.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Status |K|R|P|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mobility Options |
. .
. .
Figure 6: Unsolicited PBA Message
Status
An 8-bit unsigned integer indicating the disposition of the Proxy
Binding Update. A value of less than 128 will be used.
Unsolicited Flag
The "U" bit when set to value "1" indicates that the PBA is an
Unsolicited PBA and sequence number matching need not be done by
the MAG.
Mobility Options
The mobility options attached to the Unsolicited PBA message are
the HNP mobility option and the MN-ID mobility option.
4.4. Unsolicited DBA Message (UnSol-DBA)
The Unsolicited DBA message is sent by the LMA to the MAG connected
to the unstable interface. This message is used to notify recipient
that the MAG connected to the stable interface has changed. The
Unsolicited DBA message is represented as a normal PBA message with a
new 'U' bit in the reserved field of the PBA message to indicate that
this is an Unsolicited acknowledgement from LMA. The Unsolicited DBA
message also contains the Dormant Target Address mobility option that
was shown in Figure 5. Figure 7 shows the Unsolicited DBA message
format.
Jeyatharan & Ng Expires April 19, 2010 [Page 10]
Internet-Draft Dormant Binding October 2009
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Status |K|R|P|U| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mobility Options |
. .
. .
Figure 7: Unsolicited DBA Message
Status
An 8-bit unsigned integer indicating the disposition of the Proxy
Binding Update. A value of less than 128 will be used.
Unsolicited Flag
The "U" bit when set to value "1" indicates that the PBA is an
Unsolicited PBA and sequence number matching need not be done by
the MAG.
Mobility Options
The mobility options attached to the Unsolicited DBA message are
the Dormant Target Address mobility option and the MN-ID mobility
option.
5. Operation
In this section, signaling and data related operations of MAG and LMA
are described.
5.1. Signaling and Data Related MAG Operations
o When the MAG attached to the unstable interface of the mobile node
receives the dormant binding trigger illustrated in Section 3, it
extracts the IP address embedded in the dormant binding trigger.
Following which it sends a DBU message to LMA with the extracted
IP address attached.
o The MAG attached to the unstable interface of mobile node will
first process the received DBA message using the standard PMIPv6
protocol mechanism. Following which it will establish a tunnel
Jeyatharan & Ng Expires April 19, 2010 [Page 11]
Internet-Draft Dormant Binding October 2009
with the MAG whose IP address was obtained from DBA message.
o When disconnection of the mobile node is detected by MAG attached
to the unstable interface of mobile node, it will trigger the
dormant binding state and start the tunneling procedure for
received data packets towards the stable access.
o When MAG connected to stable interface of the mobile node receives
the Unsolicited PBA message, it will create a forwarding state for
the prefix/address received in the Unsolicited PBA message.
o When MAG connected to unstable interface of the mobile node
receives the Unsolicited DBA message carrying the new MAG address
associated with the stable interface of the mobile node, it will
create a new tunnel to the new MAG informed by means of the
Unsolicited DBA message.
5.2. Signaling and Data Related LMA Operations
o When LMA receives the DBU message, in addition to the standard
PMIPv6 protocol related PBU validity check, it will further check
whether prefix tied to the address embedded in the DBU message is
a valid prefix tied to the mobile node.
o Once the prefix validity is confirmed and the address of the MAG
that is proxying the prefix is identified, LMA will create a
dormant binding cache entry.
o After creating the dormant binding cache entry, LMA will send the
DBA message to the MAG. The DBA message sent by LMA will have the
address of MAG attached to the stable interface of the mobile
node.
o If the disconnection trigger or dormant binding triggering event
(example: de-registration PBU from MAG that is connected to
unstable interface) is received by the LMA, LMA will activate the
dormant binding cache to active state and send an Unsolicited PBA
message to the MAG attached to the stable interface of the mobile
node.
o If dormant binding cache is in active state, the LMA will tunnel
data packets only via the MAG attached to the stable interface of
the mobile node.
o If the MAG attached to the stable interface of the mobile node is
changed due to handoff and the dormant binding cache is present at
the LMA, LMA will send the Unsolicited DBA message to the MAG
attached to the unstable interface of the mobile node and notify
Jeyatharan & Ng Expires April 19, 2010 [Page 12]
Internet-Draft Dormant Binding October 2009
the changed MAG address.
6. IANA Considerations
This draft introduces two new mobility options -- Dormant Binding
Mobility Option and Dormant Target Address Mobility Option -- whose
type values need to be assigned by IANA.
7. Security Considerations
The DBU message, DBA message, Unsolicited PBA and Unsolicited DBA
messages are tied to PBU and PBA signaling and thus the security
considerations tied to PMIPv6 protocol as given in RFC-5213 [1]
applies here as well. Hence, there are no additional security
mechanisms that are required to carry out the methods described in
this draft. However, the dormant binding indication is sent from
mobile node to the MAG using L2 methods tied to the specific access
type and it is considered that L2 specific mechanism will be used to
ensure the integrity and authenticity of the dormant binding
indication.
8. References
8.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[2] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
8.2. Informative Reference
[3] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia,
"Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-05 (work in progress), June 2009.
Jeyatharan & Ng Expires April 19, 2010 [Page 13]
Internet-Draft Dormant Binding October 2009
Authors' Addresses
Mohana Dahamayanthi Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Jeyatharan & Ng Expires April 19, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 15:51:36 |