Internet Draft Hee Young Jung
Internet Engineering Task Force ETRI
Expires February 2004 Seok Joo Koh
August 2003 ETRI
Dae Young Kim
CNU
Address Pool based Stateful NCoA Configuration for FMIPv6
<draft-jung-mipshop-stateful-fmipv6-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are 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 a "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
The DAD procedure for NCoA validation is a burden for achieving the
fast MIPv6 handover. The existing stateless and DHCPv6-based stateful
NCoA configuration schemes are all concerned with the DAD process at
NAR. This document describes an NCoA address pool based stateful NCoA
configuration for MIPv6 fast handover (FMIPv6). To reduce the DAD
handling time during the handover, the NCoA pools are established at
NAR (in the reactive stateful scheme) or PAR (in the proactive
stateful scheme). An NCoA pool maintains a list of NCoAs already
confirmed by the corresponding NAR. In response to a handover request,
the NAR or PAR will allocate a confirmed NCoA to the MN. By the
address pool based stateful NCoA configuration, the handover latency
can be significantly reduced, and a tunneling for handover can be
extended to an NCoA address, instead of NAR.
Jung, Koh, Kim [Page 1]
INTERNET DRAFT Stateful FMIPv6 August 2003
1. Introduction and Motivations
One of the primary goals of fast handover for MIPv6 [1, 2] is to
minimize the handover latency required for handover. It is noted that
the handover latency could largely be impacted by the NCoA
configuration mechanism involved.
Generally, the NCoA configuration schemes can be classified into:
o Stateless NCoA configuration
o Stateful NCoA configuration
Stateless NCoA configuration scheme [3] basically requires the DAD
handling at the NAR. The use of DAD to verify the uniqueness of an
IPv6 address configured through stateless auto-configuration may add
significant delays to a MIPv6 handover, and hence a large handover
latency. Even if the duplication probability of an interface ID on
the same subnet is very low, it cannot be ignored.
It is noted that a couple of optimization schemes have recently been
proposed so as to deal with the DAD handling issues, as seen in
'optimistic DAD' [4] and 'advance DAD' [5]. However, it still needs
further enhancement works for effectively applying stateless address
configuration to fast handover for MIPv6.
FMIPv6 also considers a stateful NCoA configuration based on a
special server, typically DHCPv6 [6]. In response to a request from
PAR via the HI message, the NAR returns an NCoA via the HACK message
by referring to a DHCPv6 server attached.
The DHCPv6 based stateful NCoA configuration scheme still requires
the DAD handling or NCoA validation procedures at NAR. Furthermore,
the time for NAR to perform the DHCPv6 protocol may not be negligible
during the overall handover period.
In this document, we propose to use NCoA pools for stateful NCoA
configuration at ARs. For fast handover support, each AR is required
to manage the NCoA pools to ensure that each NCoA contained in the
pool is validated and confirmed by the corresponding NAR, so that it
could be immediately available in response to the NCoA request from
MN (or PAR).
The address pool based stateful NCoA configuration is free from the
DAD handling burden, compared to the existing stateless and DHCPv6
based stateful NCoA configuration schemes. Accordingly, it is
expected that the stateful NCoA configuration method could reduce the
handover latency concerned with the DAD handling.
Jung, Koh, Kim [Page 2]
INTERNET DRAFT Stateful FMIPv6 August 2003
In addition to the reduced handover latency, the address pool based
NCoA configuration scheme gives another benefit to FMIPv6. That is,
the PAR could establish a bi-directional tunnel to NAR with NCoA
address, instead of NAR address, since the NCoA was already proved to
be valid in the NAR region.
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.
This document uses the terms defined in MIPv6 [1] and FMIPv6 [2].
3. Framework of Address Pool based Stateful NCoA Configuration
3.1 NCoA Pools for Fast Handover Support
An 'NCoA pool' is an address pool that maintains a list of NCoAs to
be used for supporting MIPv6 handover. An AR keeps and manages an
NCoA address pool for each neighboring ARs (i.e., for each interface).
For handover support, each NCoA in the pool will have been validated
for use by the corresponding NAR.
Depending on where the NCoA pool is located at, the address pool
based configuration schemes are divided into the following two cases:
o Reactive stateful NCoA configuration (NAR-based)
The NCoA pool is located at NAR. On a request of NCoA from MN (or
PAR) via the HI message, the NAR assigns a confirmed NCoA to the
requesting MN from the NCoA pool via the HACK message.
o Proactive stateful NCoA configuration (PAR-based)
The NCoA pool is located at PAR, and updated by an out-of-band
signaling between PAR and NAR. In response to the handover
request from MN via RtSolPr, the PAR immediately assigns a
confirmed NCoA to the requesting MN from the NCoA pool via the
PrRtAdv message. In this scheme, the HI/HACK exchange is done
only for tunnel establishment, without NCoA allocation and
confirmation.
In any case, the NAR (reactive) or PAR (proactive) will respond with
a confirmed NCoA to the request from the MN.
Jung, Koh, Kim [Page 3]
INTERNET DRAFT Stateful FMIPv6 August 2003
3.2 Reactive Stateful NCoA Configuration
In the reactive stateful NCoA configuration scheme, each AR (NAR)
SHOULD keep and maintain a list of NCoAs in the NCoA pool all the
time. Each of the NCoAs in the pool SHOULD have been validated and
confirmed by NAR.
When one of its neighboring PARs asks for handover via an HI message,
it will immediately respond with an NCoA to the PAR via the
responding HACK message, as shown in Figure 1. Note that the NAR will
respond to the NCoA request from each of its neighboring PARs. In the
figure, one NAR and its two neighboring PARs are shown for an example.
+---------+
|NCoA Pool|
| for NAR |
+---------+
|
|
+------+ HI +-------+ HI +------+
| |-------------->| |<--------------| |
| PAR1 | | NAR | | PAR2 |
| |<--------------| |-------------->| |
+------+ HACK +-------+ HACK +------+
Figure 1. Network Model for Reactive NCoA Configuration
Figure 2 shows a timing diagram for fast handover using the reactive
stateful NCoA configuration. When an MN triggers the handover by
RtSolPr or an L2 trigger, the PAR requests an NCoA to NAR via the HI
message, and the NAR then delivers a confirmed NCoA to PAR. In turn,
the PAR allocates it to the MN via the PrRtAdv message.
MN PAR NAR
| | |
|------RtSolPr------->| |
| |--------HI--------->|
| |<------HACK---------|~~> w/o DAD,
|<-----PrRtAdv--------| | tunnel to NCoA
| | |
|------F-BU---------->| |
| <--F-BACK--|--F-BACK--> |
| | |
Figure 2. Reactive NCoA Configuration in FMIPv6
Jung, Koh, Kim [Page 4]
INTERNET DRAFT Stateful FMIPv6 August 2003
The term 'Reactive' is used in the viewpoint that an NCoA is
statefully allocated by NAR when the PAR requests it.
The reactive stateful scheme is different from the existing DHCPv6
based stateful scheme since the NAR is always maintaining a set of
NCoAs available and confirmed, so that a further DAD handling is not
necessary during the handover process.
3.3 Proactive Stateful NCoA Configuration
In the proactive stateful NCoA configuration scheme, each AR (PAR)
SHOULD keep 'NCoA Pools' for its respective neighboring ARs (i.e.,
prospective NARs), as shown in Figure 3. Note that the PAR SHOULD
manage an NCoA pool for each of the neighboring NARs. In the figure,
for example, only two NCoA Pools are shown for NAR1 and NAR2,
respectively.
+---------+ +---------+
|NCoA Pool| |NCoA Pool|
|for NAR1 |--+ +--|for NAR2 |
+---------+ | | +---------+
| |
+------+ +-------+ +------+
| | Signaling | | Signaling | |
| NAR1 |<=============>| PAR |<=============>| NAR2 |
| | | | | |
+------+ +-------+ +------+
Figure 3. Network Model for Proactive NCoA Configuration
The term 'Proactive' is employed in the viewpoint that an NCoA is
allocated by PAR without further requesting to NAR.
When receiving a PrSolPr from MN, the PAR obtains an NCoA (confirmed)
from the NCoA pool. The PAR then responds with a confirmed NCoA (via
PrRtAdv) to MN.
Note in the proactive configuration scheme that the HI/HACK exchange
is done only for tunnel establishment, not for the NCoA configuration
and confirmation at NAR. Accordingly, the time required for
processing the HI and HACK could be more reduced, compared to the
Reactive configuration scheme.
Figure 2 illustrates the handover timing diagram by Proactive scheme.
Jung, Koh, Kim [Page 5]
INTERNET DRAFT Stateful FMIPv6 August 2003
MN PAR NAR
| | Out-of-Band |
| | Signaling |
| |<==================>|
|------RtSolPr------->| |
|<-----PrRtAdv--------|--------HI--------->|
| |<------HACK---------|~~> w/o DAD,
|-------FBU---------->| | tunnel to NCoA
| <---FBACK--|--FBACK---> |
| | |
Figure 2. Proactive NCoA Configuration in FMIPv6
For supporting the proactive NCoA configuration, the PAR needs to
generate NCoAs and manage them to ensure that the respective NCoAs
are unique in the NAR. In particular, the NCoA generation MAY be
implemented by using one of the followings:
(1) Generation of NCoAs by PAR may be done by using network prefix of
the corresponding NAR as the network prefix portion of an NCoA.
The remaining interface ID portion may be filled with a random
number or by using a pre-specified rule exploiting the MN's link
layer identifier.
(2) Instead of PAR, the NAR may randomly generate a list of NCoAs
available and then gratuitously deliver them to PAR via an out-
of-band signaling, as described below.
(3) As an alternative to NCoA generation randomly, the PAR or NAR MAY
use a specific scheme for generating a globally unique NCoA for
an MN, without a need to confirmation by NAR. Such an NCoA
generation scheme will depend on the addressing scheme of the
underlying link layer, such as Ethernet-based or Cellular-based.
More detailed scheme is for further study.
Another key element for realizing the proactive stateful NCoA
configuration is 'signaling' for NCoA pool management between PAR and
NAR. Such signaling will intrinsically be done out-of-band because
the signaling mechanisms are performed independently of the FMIPv6
handover procedures, and thus the time required for the signaling is
excluded from the overall handover latency.
The main objective of the signaling is to ensure that the NCoA
address pool always maintains a list of NCoAs available and confirmed
by the corresponding NAR. To do this, the PAR should request the NCoA
confirmation to the NAR and also update the NCoA pool based on the
response from the NAR.
Jung, Koh, Kim [Page 6]
INTERNET DRAFT Stateful FMIPv6 August 2003
4. Impacts on FMIPv6
Basically, the address pool based stateful NCoA configuration schemes
conform to the FMIPv6 handover [2]. In this section, the FMIPv6
procedures are described when the reactive and proactive stateful
NCoA configuration apply.
4.1 FMIPv6 in the reactive NCoA Configuration
The handover procedures based on the reactive stateful NCoA
configuration is basically identical to those for the DHCPv6 based
stateful configuration scheme, as described in [2], except that the
NAR refers to its NCoA pool, not the DHCPv6 server.
In response to RtSolPr message (or by an L2 trigger in the network
initiated case), the PAR requests an NCoA to the corresponding NAR
via the HI message. In response, the NAR takes an NCoA out of its
NCoA pool and deliver it to the PAR via the HACK message.
Note that the allocated NCoA has already been confirmed by NAR, as
described so far in this document. Then the PAR sends the PrRtAdv
message that MUST include 'New CoA Option', as specified in 6.1.2 of
[2].
4.2 FMIPv6 in the proactive NCoA Configuration
In response to RtSolPr message (or by an L2 trigger in the network
initiated case), the PAR allocates an NCoA to the MN out of the
address pool for the corresponding NAR. Note that the allocated NCoA
has already been confirmed by NAR, as described so far in this
document. Then the PAR sends the PrRtAdv message that MUST include
'New CoA Option', as specified in 6.1.2 of [2].
As soon as the PAR transmits PrRtAdv to MN, it may also sends an HI
message to the NAR, as described in 5.2 of FMIPv6 [2]. Note in the
proactive scheme that the HI message is used 'only' for establishing
a bi-directional tunnel, since the NCoA was already confirmed. Note
in the HI message (see 6.2.1 of [2]) that:
o 'S' flag MUST NOT be set, although it is a stateful configuration
scheme, since the S flag set requests an NCoA to NAR. The S flag
is set only in the 'Reactive' stateful scheme.
o 'New CoA Option' SHOULD be present, although the S bit is zero,
so as to indicate that the MN wishes to use the NCoA in the NAR.
Jung, Koh, Kim [Page 7]
INTERNET DRAFT Stateful FMIPv6 August 2003
In response to the HI message, the NAR sets up a host route for the
MN's PCoA and responds with a Handover Acknowledge (HACK) message.
Note in the HACK message (see 6.2.2 of [2]) that:
o ICMP Code SHOULD be set to 0, if not an error case (128 ~ 131).
That is, the codes of 1 ~ 4 are not used.
o 'New CoA Option' SHOULD be present, although the S bit is zero,
so as to indicate that the MN should use the NCoA in the NAR.
After the HI/HACK exchange, the MN can send a Fast Binding Update
(FBU) to PAR so as to request that the packets arriving at the PAR
can be tunneled to the NAR.
In the stateful configuration scheme, the FBACK may not be used
because the MN already knows the availability of NCoA on NAR. In this
case, the 'A' flag of FBU will not be set. Even when the FBACK is
used, the PAR SHOULD promptly send the FBACK in response to FBU.
Accordingly, it is likely that the FBACK is sent only to PAR, not to
NAR.
Use of the FNA and NAACK options is identical to that of FMIPv6.
Similar to the use of FBACK message, the NAACK option may not be used.
5. Further Considerations
The following further issues may need to be considered in the future:
o Specific schemes to generate the candidate NCoAs at PAR or NAR.
o Signaling mechanisms for confirming and update the candidate NCoAs
in the proactive stateful scheme.
6. References
[1] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf-mobileip-
ipv6-24, June 2003.
[2] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf-
mobileip-fast-mipv6-06, March 2003.
[3] S. Thomson, et al., "IPv6 Stateless Address Autoconfigurationö, RFC
2462, December 1998.
[4] N. Moore, "Optimistic Duplicate Address Detection", draft-moore-ipv6-
optimistic-dad-02, February 2003.
Jung, Koh, Kim [Page 8]
INTERNET DRAFT Proactive FMIPv6 August 2003
[5] Y. Han, J. Choi, and S. Park, "Advance Duplicate Address Detection",
draft-han-mobileip-adad-01, July 2003.
[6] R. Droms (Ed.), "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
7. Author's Addresses
Hee Young Jung
hyjung@etri.re.kr
Protocol Engineering Center, ETRI
Seok Joo Koh
sjkoh@etri.re.kr
Protocol Engineering Center, ETRI
Dae Young Kim
dykim@cnu.ac.kr
Chungnam National University, KOREA
Jung, Koh [Page 9]