One document matched: draft-cui-mipshop-map-reliability-00.txt
Mipshop Working Group X. Cui
Internet-Draft huawei
Intended status: Experimental June 8 2009
Expires: December 8 2009
Mobility Anchor Point (MAP) Reliability Extension
draft-cui-mipshop-map-reliability-00.txt
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 December 8 2009.
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 allow an adapted multiple
binding in hierarchical mobile network. Mobile node registers its
RCoA and LCoA in the home agent at same time to get two separate
Cui Expires December 8, 2009 [Page 1]
Internet-Draft MAP Reliability Extension June 2009
connections between the mobile node and the home agent, or between
the mobile node and the correspondent node in Route Optimization
scenario. These connections provide a robust communication between
the mobile node and correspondent nodes and mobile node can overcome
the failure on MAP.
Requirements Language
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 [RFC-2119].
Cui Expires December 8, 2009 [Page 2]
Internet-Draft MAP Reliability Extension June 2009
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement and analysis . . . . . . . . . . . . . . . . 5
4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Proposed solution overview . . . . . . . . . . . . . . . . 5
4.2. Adapted multiple binding registration flow . . . . . . . . 5
4.3. MAP failure solution in HA manner . . . . . . . . . . . . 7
4.4. MAP failure solution in Route Optimization . . . . . . . . 8
4.5. Mobile Node operation . . . . . . . . . . . . . . . . . . 8
4.6. Home Agent operation . . . . . . . . . . . . . . . . . . . 9
4.7. Correspondent Node operation . . . . . . . . . . . . . . . 9
4.8. MAP operation . . . . . . . . . . . . . . . . . . . . . . 9
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Cui Expires December 8, 2009 [Page 3]
Internet-Draft MAP Reliability Extension June 2009
1. Introduction
IETF community defined MIP6 protocol to provide Mobility Support in
IPv6 and later HMIP was defined to support Hierarchical Mobile IPv6
Mobility Management.
In MIP6 protocol [RFC-3775], Mobile Node (MN) may move within the
network. When the MN moves it sends binding update (BU) message to
its home agent (HA) or correspondent node (CN) to maintain
reachability and ongoing connections between MN and CNs. MIP6
provides the global mobility solution.
In HMIP protocol [RFC-5380], MN sends binding update message to its
Mobility Anchor Point (MAP) when the MN moves and MAP sends binding
updates to MN's HA on behalf of the mobile node. HMIP provides the
localized and hierarchical mobility solution.
HMIP mechanism allows MN to hide the location and can reduce packet
loss when MN is moving by reducing the binding update delay. The
advantages of HMIP solution can help improving the security and
performance in mobile network.
[RFC-5380] also permits that a mobile node may send a BU containing
its LCoA (instead of its RCoA) to correspondent nodes. The purpose
of this operation is for route optimization. If these nodes are
connected to the same link, packets will then be routed directly,
without going through the MAP.
In fact the multiple binding mechanism may provide an additional
path if the mobile node send a BU containing its LCoA as the CoA
to the home agent. The operation MAY be used for MAP reliability.
If the MAP gets out of service, packets destined to the MN will
be routed by HA directly to MN (destination address is set to LCoA),
without involving the failed MAP.
This document specifies the adapted multiple binding mechanism to
support co-operation on both MIP and HMIP, as a MAP reliability
solution.
2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC-3775]
and Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
specification [RFC-5380].
Cui Expires December 8, 2009 [Page 4]
Internet-Draft MAP Reliability Extension June 2009
3. Problem statement and analysis
We may notice that in HMIP network MAP is a mandatory hop in the
connections between MN and HA or between MN and CNs. If MAP gets
out of service the MN would lose connections with HA and CNs, so
the reliability of MAP must be considered seriously.
Some solutions on Home Agent Reliability have been mentioned in
[I-D.ietf-mip6-hareliability]. But we must notice the difference
between HA and MAP. HA is a high-level router, acting as the core
node for the global mobility, while MAP is in low level, acting as
an anchor just for a local scope. The number of MAP may be very large
so we have to think over the cost of MAP equipment. The protocol
stack and software in MAP should be simple. The operation and
maintenance should be easy to handle. In these views the solutions
for HA are not really fit for MAP. Reliability solution for MAP
should be economical and simple.
4. Proposed Solutions
4.1 Proposed solution overview
In order to provide a solution for MAP reliability, an adapted
multiple binding mechanism is introduced in the document. Since the
global mobility (MIP6) and localized mobility (PMIP6) can work
together, there is also some way for MIP and HMIP to co-operate.
This document specifies how to implement a simple MAP reliability
solution by multiple binding mechanism. This document only specifies
MAP reliability. HA reliability is out of scope.
4.2 Adapted multiple binding registration flow
In the proposed solution a new registration step is added in the
procedure described in [RFC-5380], and in the new step MN sends one
more Binding Update to HA. Additionally, some original steps are
modified to achieve the solution.
The proposed registration is illustrated in Figure 1.
Cui Expires December 8, 2009 [Page 5]
Internet-Draft MAP Reliability Extension June 2009
MN MAP HA
| Binding Update | |
(a) |<------------------->| |
| Binding Update (RCoA, high priority) |
(b) |<----------------------------------------->|
| | |
| | |
| Binding Upadate (LCoA, low priority) |
(c) |------------------------------------------>|
| | |
| Binding Ack (LCoA, low priority) |
(d) |<----------------------------------------- |
| | |
Figure 1. Adapted multiple binding registration flow
for MAP reliability
The detailed descriptions are as follows:
(a) MN sends binding update message (binding RCoA and LCoA) to MAP as
described in section 6.1 of [RFC-5380]. MAP sends
binding acknowledgement message to MN, indicating the successful
registration.
(b) MN sends binding update message (binding HoA and RCoA) to HA as
described in section 6.1 of [RFC-5380]. MN includes a BID-PRI
parameter in the BU message as described in section 5.2.1 of
[I-D.ietf-mext-flow-binding] and sets the value of BID-PRI
parameter to high priority. HA responds binding acknowledgement
message indicating the successful registration.
(c) MN sends one more binding update message (binding HoA and LCoA)
to HA with a low binding priority indication in the BU message,
as described in section 5.2.1 of [I-D.ietf-mext-flow-binding].
The mobile node's home address is used in the Home Address option
and the LCoA is used as the care-of address in the source address
field. The binding lifetime in the BU message SHOULD be equal to
or less than the mobile node's binding lifetime with the MAP,
which is received in the binding acknowledgement in step (a).
(d) HA sends binding acknowledgement message to MN indicating the
successful registration, which means HA has recorded the binding
on <HoA, LCoA> pair. A bi-directional tunnel between the mobile
node and the home agent is established.
It should be noted that when MN detects the failure of the MAP, MN
MAY send a binding update message to HA and set the lifetime equal to
zero in the BU message.
Cui Expires December 8, 2009 [Page 6]
Internet-Draft MAP Reliability Extension June 2009
When MN detects MAP's recovery after a failure, MN should redo the
registration operation as if the mobile node is entering a new MAP
domain.
After the adapted multiple binding registration, HA gets a whole
Binding Cache Entry for the mobile node. One example is illustrated
in Figure 2.
BIDs BID-PRI HoA CoA Lifetime A/I
---- ------- ----- ---------- -------- -------
1 10 HoA RCoA x seconds Active
2 20 HoA LCoA x seconds Active
N/A N/A NULL NULL NULL Inactive
Figure 2. Example of Biding Cache Entry with
adapted multiple binding
4.3 MAP failure solution in HA manner
In [RFC-5380] all the packets destined to MN are forwarded by MAP.
This document provides a supplementary solution to overcome the
failure on MAP.
The proposed reliability solution in HA manner is illustrated in
Figure 3.
CN HA MAP AR MN
| | | | |
(a) |------->| | | |
(b) | |------->| | |
(c) | | |------->| |
(d) | | | |------->|
| | | | |
| |failure | | |
| |detected| | |
(e) | |<------>| | |
| | | | |
(f) |------->| | | |
(g) | |---------------->| |
(h) | | | |------->|
| | | | |
Figure 3. Proposed reliability solution in HA manner
The detailed descriptions are as follows:
(a) CN sends packet to MN. The destination address of the packet is
set to HoA and the packet is routed to HA.
Cui Expires December 8, 2009 [Page 7]
Internet-Draft MAP Reliability Extension June 2009
(b) HA searches the BCE and finds the active binding to RCoA, which
is BID 1 in Figure 2. So HA forwards the packet to MAP.
(c) MAP also searches the BCE and finds the binding to LCoA. So MAP
forwards the packet with the destination set to LCoA. The packet
is routed to AR which is the MN's default router.
(d) AR routes the packet to MN without any modification.
(e) MAP gets out of service for some reason and HA detects the
failure of MAP. The method to detect the failure is out of the
scope of this document. HA updates the binding cache and BID 1
in BCE of HA is set to Inactive status. BID 2 (HoA, LCoA) becomes
the only active item in binding cache.
(f) Another packet destined to MN is sent by CN to HA.
(g) HA searches the BCE and finds the only active binding to LCoA. So
HA sets the destination address of the packet to LCoA and
forwards the packet to MN directly. The packet is routed to AR
which is the MN's default router.
(h) AR routes the packet to MN without any modification.
It should be noted that when MN detects the failure of the MAP, MN
would set the source address of the packets, which are destined to
CN, to LCoA and sends the packets to HA. HA forwards the packets from
MN to CN.
4.4 MAP failure solution in Route Optimization
In Route Optimization manner, packets between MN and CNs are not
routed through HA. The multiple binding in HA is unavailable for
route optimization. The binding cache in CN replaces the role of the
one in HA. So MN in route optimization may make adapted multiple
binding in CNs to implement the MAP reliability instead in HA.
MN sends BU message containing its LCoA and low priority indication
to correspondent nodes to bind its HoA and its LCoA. Other operation
and procedure are similar to the solution in HA manner.
4.5 Mobile Node operation
In order to implement the MAP reliability solution MN should send one
more binding message with low priority indication to bind its home
address and its LCoA. The binding update message is sent to either HA
in HA manner or CN in RO manner.
Cui Expires December 8, 2009 [Page 8]
Internet-Draft MAP Reliability Extension June 2009
The detailed method to implement adapted multiple binding is
described in [I-D.ietf-monami6-multiplecoa] and
[I-D.ietf-mext-flow-binding].
4.6 Home Agent operation
Home Agent normally maintains the binding cache with only one item in
the list. The home address is usually associated to RCoA in HMIP.
This document extends the binding cache in HA to multiple bindings,
which permit the home address to be associated to multiple CoAs in
sequence.
The detailed method to extend the binding cache is described in
[I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding].
4.7 Correspondent Node operation
The mechanism defined in this document is completely transparent to
correspondent nodes in HA manner. In Route Optimization manner the CN
maintains the binding cache with multiple binding as HA does in HA
manner.
4.8 MAP operation
The mechanism defined in this document is completely irrelative to
MAP's operation.
5. Conclusion
This document specifies a reliability solution for MAP. In the
solution an additional binding, which associates HoA and LCoA, is
registered in home agent. By this means, the mobile node exposes its
location to home agent and gets a redundant connection between mobile
node and home agent. Since the location information is not crucial
while the reliability is considerable, this solution may be
implemented in the mobile network.
6. Security Considerations
This document specifies a solution for MAP reliability by an adapted
multiple binding mechanism. The solution incorporates the operations
specified in [RFC-5380] (registration in MAP),
[I-D.ietf-monami6-multiplecoa] (multiple binding operation) and
[I-D.ietf-mext-flow-binding] (BID priority registration). This
document uses the same security as described in [RFC-5380],
[I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding].
Cui Expires December 8, 2009 [Page 9]
Internet-Draft MAP Reliability Extension June 2009
7. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
TBD.
9. References
9.1 Normative References
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-13 (work in progress),
April 2009.
[I-D.ietf-mext-flow-binding]
Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
Kuladinithi, K., Flow Bindings in Mobile IPv6 and Nemo
Basic Support, draft-ietf-mext-flow-binding-02.txt (work
in progress), April 2009
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC-5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
9.2 Informative References
[I-D.ietf-mip6-hareliability]
Wakikawa, R., "Home Agent Reliability Protocol",
draft-ietf-mip6-hareliability-04.txt, July 2008
Author's Address
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Cui Expires December 8, 2009 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 08:26:16 |