One document matched: draft-jung-mobopts-fhmipv6-00.txt
Internet Draft HeeYoung Jung, ETRI
Internet Engineering Task Force Hesham Soliman, Flarion
draft-jung-mobopts-fhmipv6-00.txt Seok Joo Koh, KNU
Expires October 2005 Jae Yong Lee, CNU
April 2005
Fast Handover for Hierarchical MIPv6 (F-HMIPv6)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668 [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 proposes a scheme to support Fast Handover over HMIPv6
networks. The MIPv6 mobility could be more enhanced by combining
FMIPv6 with HMIPv6, in which MIPv6 is benefited from all the
advantages of the respective schemes. This document describes how to
use FMIPv6 for HMIPv6 (F-HMIPv6). The F-HMIPv6 is designed to be
friendly with the data transport feature of HMIPv6. In F-HMIPv6, the
tunnel for fast handover is established between MAP and NAR, rather
than between PAR and NAR. For this purpose, the MN exchanges the
FMIPv6 messages with MAP, not PAR. The F-HMIPv6 utilizes the FMIPv6
messages for handover support without further defining any new
messages. For the F-HMIPv6, it is proposed to define a new flag 'F' in
the HMIPv6 MAP option.
Jung, et al. Expires October 2005 [Page 1]
Internet Draft Fast Handover for HMIPv6 April 2005
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................3
3. A Simple FMIPv6-to-HMIPv6 Scheme..............................4
4. Overview of F-HMIPv6..........................................5
4.1 Reference Architecture....................................5
4.2 Optimized Data Flows in F-HMIPv6..........................6
5. F-HMIPv6 Operations...........................................7
5.1 Mobile-Initiated Handover.................................7
5.2 Network-Initiated Handover................................9
5.3 AR based RtSolPr/PrRtAdv.................................10
6. Messages for F-HMIPv6........................................10
6.1 A New Flag in the HMIPv6 MAP Option......................11
6.2 Use of FMIPv6 messages in F-HMIPv6.......................12
7. Security Considerations......................................12
8. Acknowledgement..............................................13
9. References...................................................13
Author's Addresses..............................................13
Full Copyright Statement........................................14
Intellectual Property...........................................14
Jung, et al. Expires October 2005 [Page 2]
Internet Draft Fast Handover for HMIPv6 April 2005
1. Introduction
The HMIPv6 [3] was developed to reduce the signaling overhead and
delay concerned with Binding Update (BU) in Mobile IPv6. In HMIPv6,
when a MN moves within a MAP region, the MN only sends a local BU to
the local MAP, rather than the Home Agent (HA) and Correspondent Node
(CN), as done in Mobile IPv6. If the distance from the MN to HA/CN is
long, this local BU will considerably reduce the time required for the
binding update.
However, the HMIPv6 still need a further enhancement for supporting
the real-time applications because HMIPv6 only concern with the
latency due to BU and does not touch the latency related to Movement
Detection and CoA configuration/Verification. Currently, the FMIPv6
[4] is the typical protocol that was designed to reduce the latency
due to these two remaining issues. Therefore, if we want to support
the fast handover scheme in HMIPv6 network, the simplest approach will
be to apply the FMIPv6 to the HMIPv6 in the straightforward way.
We describe in this document how to use FMIPv6 over HMIPv6 networks so
as to provide better handover performance during handover. At a glance,
it may be straightforward to simply integrate the FMIPv6 scheme with
HMIPv6. However, such simple integration may induce unnecessary
processing overhead for re-tunneling at the previous Access Routers
and also inefficient usage of network bandwidth. The main reason for
this is that the operation of HMIPv6 mainly depends on the
functionality of a MAP, while the major functionalities of FMIPv6 are
located in Access Routers (AR).
This document describes a Fast Handover scheme for HMIPv6, named F-
HMIPv6. In F-HMIPv6, the main operation for handover is accomplished
by using MAP, rather than Access Router (i.e. PAR and NAR) like in
FMIPv6. For this purpose, the MN exchanges the signaling messages for
handover such as RtSolPr, PrRtAdv, FBU, and FBACK with MAP, not PAR.
The F-HMIPv6 utilizes the FMIPv6 messages for handover support without
further defining any new messages. For the use of F-HMIPv6, it is
proposed to define a new flag 'F' in the HMIPv6 MAP option.
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 [2].
This document uses all the terminology described in the MIPv6, HMIPv6,
and FMIPv6 documents. In addition, this document uses the following
terms for the on-link Care of Address (LCoA):
Jung, et al. Expires October 2005 [Page 3]
Internet Draft Fast Handover for HMIPv6 April 2005
PLCoA: MN's LCoA valid on the Previous Access Router (PAR). It
corresponds to the PCoA of the FMIPv6.
NLCoA: MN's LCoA valid on the New Access Router (NAR). It corresponds
to the NCoA of the FMIPv6.
3. A Simple FMIPv6-to-HMIPv6 Scheme
A natural and straightforward choice to combine FMIPv6 with HMIPv6 is
to directly apply the FMIPv6 handover scheme in the HMIPv6 networks,
as per their own specifications. In this case, a bi-directional tunnel
will be established between PAR and NAR by the FMIPv6 procedures. In
this case, it may possibly induce inefficient signaling and data
forwarding path.
Figure 1 shows the data flow during handover by the simple integration
of FMIPv6 with HMIPv6.
CN PAR MAP MN(at NAR)
| | | |
| MIPv6 | |
|---------------------->| |
| | | |
| | HMIPv6 | |
| |<----------| |
| | | |
| | FMIPv6 |
| |---------------------->|
| | | |
Figure 1: Data flows in simple scheme
According to the HMIPv6 operations, the data packets sent by CN will
arrive at MAP and then be tunneled to MN over PLCoA. When the handover
is initiated, a bi-directional tunnel will be established between PAR
and NAR according to the FMIPv6 procedures. To forward the data
packets to the NAR by using the tunnel, the PAR must first intercept
those data packets flowing from the MAP, and then perform the re-
tunneling process. This may be done by adding a new outer IP header of
<Source = PAR, Destination = NAR> to the data packets sent by MAP
according to the HMIPv6 operations.
In the viewpoint of the HMIPv6 operations, the simple straightforward
approach has the following disadvantages:
Jung, et al. Expires October 2005 [Page 4]
Internet Draft Fast Handover for HMIPv6 April 2005
(1) The PAR must perform the tunneling operations for fast handover,
in addition to the HMIPv6 tunneling from MAP to MN. To do this,
the PAR must first intercept the data packets flowing from the MAP,
which will be an additional overhead for HMIPv6. It is noted that
the data delivery in HMIPv6 is performed based on MAP.
(2) In HMIPv6, the actual data path of the bi-directional tunnel
between PAR and NAR may include the MAP (i.e., PAR-MAP-NAR).
Accordingly, the data packets will flow twice along the path
between ARs and MAP. This induces inefficiency of network
bandwidth usage, especially when ARs are connected to the network
through bandwidth-limited links.
(3) During handover, the possibility that the tunneled packets from
PAR to NAR before F-BU arrive later at NAR than the packet sent
directly from MAP by F-BU is relatively high. It will be the cause
of the reversed sequence packets in NAR and the packets with
reversed sequence makes TCP performance worse.
(4) From such detouring feature, the overall handover latency and
tunneling overhead may increase during the handover period.
Moreover, it is likely to be difficult to exploit the advantages
of FMIPv6 and HMIPv6 as well.
(5) In hierarchical architecture like HMIPv6, the maintenance of
information for neighbor ARs in each AR may be overhead.
From the observations described above, it is clear that the fast
handover for HMIPv6 needs to be designed by considering the data
transport features of the HMIPv6 (i.e., in HMIPv6, all data packets
are intercepted by MAP and delivered over the tunnel between MAP and
MNs).
4. Overview of F-HMIPv6
4.1 Reference Architecture
Figure 2 illustrates a reference configuration of the F-HMIPv6 network
for fast handover support. In the figure, the MAP acts as an
aggregation router in the hierarchical domain.
When a mobile node (MN) enters a new HMIPv6 domain, firstly it
performs the HMIPv6 registrations procedures with HA and MAP, as per
MIPv6 and HMIPv6. Also, if the MN moves from a previous AR (PAR) to a
new AR (NAR) within the domain, it will follow the Local Binding
Update procedures of HMIPv6. At that time, if the fast handover is
Jung, et al. Expires October 2005 [Page 5]
Internet Draft Fast Handover for HMIPv6 April 2005
required for an on-going data session between MN and CN, then the F-
HMIPv6 scheme will apply to the MN, ARs and MAP.
+-------+
| HA |
+-------+
| +----+
| | CN |
| +----+
+-----+ |
| +---+
| |
+-------+
| MAP | RCoA
+-------+
| |
| +--------+
| |
+-----+ +-----+
PLCoA | PAR | | NAR | NLCoA
+-----+ +-----+
+----+
| MN | ------------->
+----+ Movement
Figure 2: Reference Architecture for F-HMIPv6
4.2 Optimized Data Flows in F-HMIPv6
By the F-HMIPv6 scheme, the data packets sent by CN will be tunneled
by the MAP toward the NAR during the handover.
Figure 3 illustrates the data flows that F-HMIPv6 is willing to
achieve.
CN PAR MAP MN(at NAR)
| | | |
| MIPv6 | | |
|---------------------->| |
| | | |
| | | F-HMIPv6 |
| | |---------->|
| | | |
Figure 3: Optimized data flows by F-HMIPv6
Jung, et al. Expires October 2005 [Page 6]
Internet Draft Fast Handover for HMIPv6 April 2005
Before handover, according to the HMIPv6 operations, the data packets
sent by CN are tunneled by MAP to MN with the following IP fields:
o Inner IP header: <Source = CN, Destination = RCoA of MN>
o Outer IP header: <Source = MAP, Destination = PLCoA of MN>
When the F-HMIPv6 handover is triggered (e.g., by receiving the FBU
message from the MN), the MAP will establish a bi-directional tunnel
with the NAR, and then begin to forward the data packets to the NAR
over the tunnel. By the tunnel, each data packet has an additional
outer IP header to the normal HMIPv6 headers with the following IP
fields:
o Additional outer IP header: <S = MAP, Destination = NAR>
When receiving the tunneled data packets from the MAP, the NAR will
de-capsulate them and then be caching the decapsulated data packets.
When the MN moves into the NAR region, the NAR will deliver the cached
data packets to the MN, as done in FMIPv6.
5. F-HMIPv6 Operations
In this section, we describe the generic F-HMIPv6 operations. It is
assumed that the handover anticipation is supported with appropriate
layer 2 triggers; and that the MNs as well as ARs are aware of the F-
HMIPv6 scheme described in this document.
The F-HMIPv6 procedures described in this section are based on the
assumption that the MAP already has the information necessary for
handover support about the ARs located in the HMIPv6 domain. This
information should include the link-layer address (or identifier) and
network prefix of each AR.
5.1 Mobile-Initiated Handover
Figure 4 illustrates the generic procedures for F-HMIPv6 operations.
Jung, et al. Expires October 2005 [Page 7]
Internet Draft Fast Handover for HMIPv6 April 2005
MN(at PAR) PAR MAP NAR MN(at NAR)
| | | | |
| HMIPv6 Data (before HO) | | |
|<===========================>| | |
| RtSolPr | | | |
|---------------------------->| | |
| PrRtAdv | | | |
|<----------------------------| | |
| FBU | | HI | |
|---------------------------->|------------->| |
| | | HACK | |
| | |<-------------| |
| | FBACK | FBACK | |
| <-------------------|-------------------> |
Disconnect | | | |
| | |Packet Forward| |
| | |=============>| |
Connect | | Packet Delivery by FNA
| | | |============>|
| | Stop | LBU |
| | Forwarding |<---------------------------|
| | to NAR | LBACK |
| | |--------------------------->|
| | | HMIPv6 Data (after HO) |
| | |<==========================>|
| | | | |
Figure 4: F-HMIPv6 for Mobile-Initiated Handover
Note that the control messages depicted in Figure 4 have identical
format to those in FMIPv6; only the contents (the IP source and
destination fields) are different. These values are described more in
details in Section 6.
The detailed description for the control flows are given below:
1) Based on L2 handover anticipation, the MN sends RtSolPr message
to MAP. The RtSolPr SHOULD include information about the link
layer address or identifier of the concerned NAR.
2) In response to the RtSolPr message, the MAP sends the PrRtAdv
message to the MN, which SHOULD contain information about NLCoA
for the MN to use in the NAR region; i. e, NARs network prefix
for stateless auto-configuration or NLCoA for stateful
configuration.
Note in F-HMIPv6 that the MAP SHOULD already know the network
prefix and link layer address of the associated NAR.
Jung, et al. Expires October 2005 [Page 8]
Internet Draft Fast Handover for HMIPv6 April 2005
3) The MN sends Fast Binding Update (FBU) message to MAP. The FBU
message contains PLCoA and IP address of the NAR.
4) After receiving the FBU message from MN, the MAP will send a
Handover Initiate (HI) message to the NAR so as to establish a
bi-directional tunnel.
In response to the HI message, the NAR will set up a host route
entry for the MN's PLCoA and then respond with a Handover
Acknowledge (HACK) message.
As a result, a bi-directional tunnel between MAP and NAR will be
established. Over the tunnel, the data packets sent by MAP have
the additional outer IP header with the following IP fields of
<Source = MAP, Destination = NAR>. The NAR may cache those data
packets flowing from the MAP, until it receives the RS (possibly
with FNA option) message from the newly incoming MN.
5) The MAP sends Fast Binding ACK (FBACK) messages toward the MN
over PLCoA and NLCoA. Then, the MAP will begin to forward the
data packets destined to MN to the NAR by using the established
tunnel.
6) The MN sends FNA messages to NAR, when it detects that it is
moved in the link layer. Then, the NAR delivers the buffered data
packets to the MN over PLCoA.
7) The MN then follows the normal HMIPv6 operations by sending a
Local Binding Update (LBU) to MAP, as per HMIPv6.
When the MAP receives the new Local Binding Update with NLCoA
from the MN, it will stop the packet forwarding to NAR and then
clear the tunnel established for fast handover.
8) In response to LBU, the MAP sends Local Binding ACK (LBACK) to MN,
and the remaining procedures will follow the HMIPv6.
5.2 Network-Initiated Handover
This section describes the F-HMIPv6 operations for the network-
initiated handover. In the network-initiated case, it is assumed that
the PAR or NAR detects the movement of the MN from the PAR toward the
NAR.
Figure 5 illustrates the F-HMIPv6 operations for the network-initiated
handover case.
Jung, et al. Expires October 2005 [Page 9]
Internet Draft Fast Handover for HMIPv6 April 2005
MN(at PAR) PAR MAP NAR MN(at NAR)
| | | | |
| | Trigger(ST) | Trigger(TT) | |
| |~~~~~~~~~~~~~>|<~~~~~~~~~~~~~| |
| | | | |
| PrRtAdv | | | |
|<----------------------------| | |
| | | | |
Figure 5: F-HMIPv6 for Network-Initiated Handover
When the PAR receives a source trigger or the NAR receives a target
trigger from the network, it sends a handover indication signal to the
MAP, possibly via an out-of-band signaling. Such the signal SHOULD
include information about the link layer address and PLCoA of the
concerned MN as well as the link layer address or identifier of the
associated NAR.
When a network-initiated handover is indicated, the MAP sends the
PrRtAdv message to the concerned MN. The PrRtAdv message SHOULD
contain information about NLCoA for the MN to use in the NAR region.
The remaining procedures are identical to those for the mobile-
initiated handover case, as shown in Figure 4.
5.3 AR based RtSolPr/PrRtAdv
F-HMIPv6 assumes that a MAP has necessary information about its
serving ARs such as IP address and link layer ID. It seems to be
natural if we refer convenient mobile networks that are hierarchically
configured.
If an access system provides the information sharing between ARs, the
direct exchange of RtSolPr/PrRtAdv between an MN and an AR may be more
effective. It is expected that the shorter signaling path can bring
the lower latency. This kind of approach was already touched in the
HMIPv6 (Appendix A). In this case, the procedure that described in the
draft could be used for remaining procedure as shown in Figure 4.
6. Messages for F-HMIPv6
In this document, it is assumed that the MNs and ARs (including MAP)
in the network are aware of the F-HMIPv6 described in this document as
well as HMIPv6 [4]. For realizing the F-HMIPv6, the messages and
functionality (e.g., triggers and tunnels) defined in FMIPv6 [5] will
be used with slightly different procedures.
Jung, et al. Expires October 2005 [Page 10]
Internet Draft Fast Handover for HMIPv6 April 2005
The F-HMIPv6 is basically designed to exploit all the messages defined
in FMIPv6 and HMIPv6 with the following exceptions:
- A new flag is defined in the HMIPv6 MAP option, so as to indicate
whether the MAP supports the F-HMIPv6 or not within the HMIPv6
domain.
- Some of the FMIPv6 messages have different IP source and destination
addresses in the respective IP fields. In particular, the MAP
address is used instead of the PAR address.
6.1 A New Flag in the HMIPv6 MAP Option
Figure 6 shows the MAP option used for HMIPv6. A new flag 'F' is added
for F-HMIPv6.
When a MN moves into a new MAP domain, it receives the Router
Advertisement with a MAP option from an access router. When the F bit
set in the MAP option indicates that the mobile node MAY use F-HMIPv6.
If the MN is not aware of F-HMIPv6, or the F bit is not set, it SHOULD
NOT use F-HMIPv6.
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 | Dist | Pref |R|I|P|V|F| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: A new flag in the MAP option
Fields:
F When set indicates that the MAP support
fast handover by F-HMIPv6.
Jung, et al. Expires October 2005 [Page 11]
Internet Draft Fast Handover for HMIPv6 April 2005
6.2 Use of FMIPv6 messages in F-HMIPv6
F-HMIPv6 uses the messages for fast handover defined in FMIPv6, with
different source and destination IP addresses. Table 1 summarizes the
use of these messages.
Table 1. Use of FMIPv6 Messages in F-HMIPv6
+--------------+-----------+-------------+---------------------+
| F-HMIPv6 | Source IP | Destination | Usage in FMIPv6 |
| Messages | address | IP address | |
+--------------+-----------+-------------+---------------------+
| RtSolPr | MN | MAP | Destination = PAR |
|(Mobile-Ini.) | | | Source = MN |
+--------------+-----------+-------------+---------------------+
| RtSolPr | PAR | MAP | Destination = PAR |
|(Network-Ini.)| | | Source = MN |
+--------------+-----------+-------------+---------------------+
| PrRtAdv | MAP | MN | Source = PAR |
+--------------+-----------+-------------+---------------------+
| FBU | MN | MAP | Destination = PAR |
+--------------+-----------+-------------+---------------------+
| FBACK | MAP | MN | Source = PAR |
| | |(via PAR/NAR)| |
+--------------+-----------+-------------+---------------------+
| HI | MAP | NAR | Source = PAR |
+--------------+-----------+-------------+---------------------+
| HACK | NAR | MAP | Destination = PAR |
+--------------+-----------+-------------+---------------------+
7. Security Considerations
The security issues of F-HMIPv6 are basically in line with those of
FMIPv6 and HMIPv6.
Note that the MN and MAP could have an IPsec security association in
HMIPv6, thus the RtSolPr and PrRtAdv messages can also be protected
with IPsec. This feature actually provides an advantage over FMIPv6
where ND messages cannot be secured in its present form.
In addition, the MAP MUST ensure that the RtSolPr and FBU packets
arrived from an MN that legitimately owns the RCoA. Otherwise, a bogus
node could attempt to disrupt packets meant for the MN and redirect
them to some access router.
Further security issues will be identified, as the F-HMIPv6 work is
progressing.
Jung, et al. Expires October 2005 [Page 12]
Internet Draft Fast Handover for HMIPv6 April 2005
8. Acknowledgement
The Authors would like to give special thanks to the following people
for their valuable comments and discussion for enhancing the F-HMIPv6.
Jun Seob Lee (ETRI)
Bryan Hartwell (Ashnet)
9. References
[1] S. Bradner, " Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP, RFC 2119, March 1997.
[3] D. Johnson, et al., "Mobility Support in IPv6", RFC 3775, June
2004.
[4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management
(HMIPv6)", draft-ietf-mipshop-hmipv6-04, December 2004.
[5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf-
mipshop-fast-mipv6-03, October 2004.
Author's Addresses
HeeYoung Jung
hyjung@etri.re.kr
Protocol Engineering Center, ETRI
Hesham Soliman
H.Soliman@flarion.com
Flarion
Seok J. Koh
sjkoh@knu.ac.kr
Kyungpook National University
Jae Yong Lee
jyl@cnu.ac.kr
Chungnam National University
Jung, et al. Expires October 2005 [Page 13]
Internet Draft Fast Handover for HMIPv6 April 2005
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Jung, et al. Expires October 2005 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 10:19:10 |