One document matched: draft-sarikaya-netext-fb-support-extensions-00.txt
Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: August 5, 2010 Huawei USA
February 1, 2010
PMIPv6 Multihoming Support for Flow Mobility
draft-sarikaya-netext-fb-support-extensions-00
Abstract
This document specifies extensions to Proxy Mobile IPv6 (PMIPv6) for
flow mobility support. Binding cache and binding update list are
slighlty extended to allow indicating the home interface and other
interfaces.
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 August 5, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Sarikaya & Xia Expires August 5, 2010 [Page 1]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multihoming Case . . . . . . . . . . . . . . . . . . . . . . . 4
5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Extensions to Binding Cache Entry . . . . . . . . . . . . . 5
6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Extensions to Binding Update List Entry Data Structure . . 6
7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
11.2. Informative references . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Sarikaya & Xia Expires August 5, 2010 [Page 2]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
1. Introduction
In Mobile IPv6 [RFC3775] multi-homing is supported efficiently due to
the use of home address. Mobile node uses its home address as the
source address and all incoming traffic is directed to the home
address (HoA). When multiple interfaces are concurrently active the
home agent (HA) has to decide how to route incoming packets to
different active interfaces. HA does this based on the flow
bindings. MN has to register its active flows with the HA and HA
keeps flow binding entries for each HoA. HA then forwards packets to
one of the care-of addresses of an active interface after matching it
with an ordered list of flow bindings.
Proxy Mobile IPv6 [RFC5213] lacks a similar mechanism because each
active interface is treated separately and a different binding cache
entry is created. This document proposes changes necessary to the
local mobility anchor (LMA) behaviour so that flow mobility can
seamlessly be supported in PMIPv6. The changes to the mobile node
considered in [I-D.yokota-netlmm-pmipv6-mn-itho-support] are also
needed to complement our solution on the host side.
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 [RFC2119].
The terminology in this document is based on the definitions in
[RFC5213], [I-D.ietf-mext-flow-binding] in addition to the ones
specified in this section:
Single-Radio MN: Consider MN with two interfaces. These interfaces
are implemented in such a way that MN can keep one radio module
(interface) active at a given time.
Dual/multiple-Radio MN: Consider MN with two interfaces. These
interfaces are implemented in such a way that both radio modules
can receive and transmit simultaneously.
Inter-technology handover: Sometimes called vertical handover. A
multi-homed MN communicates with one interface at any time to
conserve power. Each interface can support different access
technology. Inter-technology handover occurs when MN moves out of
coverage of one technology and moves into the coverage area of
another technology which will result in switching of the
communicating interface on MN
[I-D.yokota-netlmm-pmipv6-mn-itho-support].
Sarikaya & Xia Expires August 5, 2010 [Page 3]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
3. Problem Statement
When MN connects simultaneously with multiple interfaces each
interface is treated independently and MN uses different source
addresses when sending packet over these interfaces. However in case
of flow mobility, MN itself or LMA might wish to move one flow from
one interface to the other. When a flow is moved from interface A to
interface B, MN has to stop sending packets on interface A, i.e. it
should set the source address to an address based on HNPs assigned to
interface B. Forcing an MN to do this after a flow is moved is
difficult currently and is one of the problems PMIPv6 flow mobility
is facing.
The solution for this is to let MN always use a source address from
HNPs assigned to its home interface. When multiple interfaces are
active, incoming packets can be directed to different active
interfaces based on flow state established at LMA.
When MN does an inter-technology handover, the new MAG sends a Proxy
Binding Update (PBU) message to the local mobility anchor (LMA) to
register the new proxy care-of address. In the PBU, MAG sets the
access technology type (ATT) and handoff indicator (HI) values. If
ATT is different from the one stored in the existing binding cache
entry for this MN and if HI is set to 2 (Handoff between two
different interfaces of the mobile node), LMA concludes that an
inter-technology handover happened and assigns the same home network
prefix(es) to MN which enables IP session continuity.
Setting the access technology type correctly might prove easier for
MAGs that are connected to a single technology. Currently this could
be the most popular case. However with the advent of fixed mobile
convergence this is likely to change. MAGs in the future are
expected to serve more than one access technologies.
Setting the handoff indicator correctly is also not so easy. Most
MAGs would tend to set HI to 1 (Attachment over a new interface)
which would result in LMA setting new prefix(es) to MN and creating a
new binding cache entry and allocating a new mobility session for
this new interface. This behaviour as described in Section 5.4 of
[RFC5213] needs to be changed.
4. Multihoming Case
When there is attachment over a new interface (HI value received in
the Binding Update from MAG is 1) LMA creates a new binding cache
entry and assigns the flag "S" to all home network prefixes assigned
to this interface. Also this flag is set in the binding
Sarikaya & Xia Expires August 5, 2010 [Page 4]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
acknowledgement sent to MAG. LMA MUST also include the home network
prefixes with "H" flag in the BA message. This should enable MN
continue to send packets with source addresses selected from HNPs
with "H" flag on.
The new binding cache entry does not create a new mobility session.
The entry is considered as a pointer to another binding the same MN
has with LMA. MN may have as many such binding entries as it has
interfaces. These secondary binding cache entries are refreshed
regularly by MAGs sending BUs. MAG MUST include HNPs both with "H"
and "S" flags in the BU message.
5. LMA Operation
When LMA receives a Binding Update meesage which contains Handoff
Indication set to a value of 1 LMA MUST create a new binding cache
entry and assign new home network prefixes for this interface. The
flag MUST be assigned to "S". This binding cache entry becomes part
of the binding cache entry that contains home network prefixes with
"H" flag.
LMA sends home network prefixes assigned to the new interface in the
Binding Acknowledgement message. LMA MUST also set the flag to "S".
In the same BA message, LMA also sends home network prefixes whose
associated flag is "H" in the same BA.
The modifications specified in this document allow a mobile node to
have a single interface connected at a given moment and that
interface has prefixes assigned an "S" flag, i.e. the binding with
the home interface may have expired. In this case LMA MUST also
store the home network prefixes with "H" flag in the binding cache
entry.
5.1. Extensions to Binding Cache Entry
A flag associated with the following binding cache entry: list of
IPv6 home network prefixes assigned to the mobile node's connected
interface. The flag is set to "H" if the connected interface is the
home interface and is set to "S" if the connected interface is not.
The prefixes assigned after the first PBU is received for MN are
assigned "H" flag. The handoff between two different interfaces does
not require the prefixes to be changed in order to allow session
continuity. Because of this the flag (of "H" or "S") associated with
the prefixes stays the same.
This specification also brings the change that binding cache entries
Sarikaya & Xia Expires August 5, 2010 [Page 5]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
for the same MN-Identifier are considered together. The number of
entries is equal to the number of active interfaces of MN. If there
is a single entry it is assumed that the flag value is "H", otherwise
the prefixes with "H" flag should also be stored in the binding cache
entry.
For an incoming packet, the destination address MUST be selected from
the set of prefixes with "H" flag. LMA decides to which interface to
route this packet by consulting the flow binding entries list,
similar to the case in Mobile IPv6 [I-D.ietf-mext-flow-binding]. The
packet will be matched against the flow descriptions in the flow
binding entries list and Proxy-CoA of the matching entry will be
determined. Next, binding cache entry for this MN will be searched
and the packet will be directed to the MAG to which the matching
interface is connected.
6. MAG Operation
When MAG detects an attachment over a new interface it sets Handoff
Indicator field to 1 as described in [RFC5213] in the Binding Update
message that it sends to LMA.
MAG MUST store home network prefixes it receives in Binding
Acknowledgement message from LMA together with the flag in the
binding update list entry. If the flag is "S" MAG MUST also store
all home network prefixes in the BA message whose flag is "H" in the
corrsponding binding update list entry.
6.1. Extensions to Binding Update List Entry Data Structure
A flag associated with the following binding update list entry: list
of IPv6 home network prefixes assigned to the mobile node's connected
interface. The flag is set to "H" if the connected interface is the
home interface and is set to "S" if the connected interface is not.
MAG MUST also store the home network prefixes with flag "H" in
addition to the prefixes associated with the connected interface if
the flag of the home network prefix assigned to the connected
interface is "S".
7. Message Formats
Home Network Prefix Option defined in [RFC5213] is modified to
include a flag to indicate if home network prefixes are assocaited
with "H" flag or "S" flag in the binding cache entries.
Sarikaya & Xia Expires August 5, 2010 [Page 6]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
This specification extends the Home Network Prefix Option with a new
flag. The flag is shown and described below. All other fields are
as described in [RFC5213].
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 |H| Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Home Network Prefix Option
H Flag
This flag is set when this prefix is assigned to a secondary
interface of the mobile node and when the binding cache entry for
this HNP has "S" flag set. This flag is not set when this prefix
is assigned to the firstly connecting or the only connected
interface of the mobile node and when the binding cache entry for
this HNP has "H" flag set.
8. Security Considerations
This document does not define any new security issues. PMIPv6
security procedures apply.
9. IANA considerations
TBD.
10. Acknowledgements
TBD.
11. References
Sarikaya & Xia Expires August 5, 2010 [Page 7]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[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.
[I-D.yokota-netlmm-pmipv6-mn-itho-support]
Yokota, H., Gundavelli, S., and K. Leung, "Inter-
Technology Handoff support in Mobile Node for Proxy Mobile
IPv6", draft-yokota-netlmm-pmipv6-mn-itho-support-02 (work
in progress), October 2009.
[I-D.ietf-mext-flow-binding]
Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
Basic Support", draft-ietf-mext-flow-binding-04 (work in
progress), November 2009.
11.2. Informative references
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
(work in progress), September 2009.
Sarikaya & Xia Expires August 5, 2010 [Page 8]
Internet-Draft PMIPv6 Support for Flow Mobility February 2010
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Sarikaya & Xia Expires August 5, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:28 |