Internet DRAFT - draft-sarikaya-netext-fb-support-extensions
draft-sarikaya-netext-fb-support-extensions
Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: December 9, 2012 Huawei
June 7, 2012
PMIPv6 Multihoming Support for Flow Mobility
draft-sarikaya-netext-fb-support-extensions-02
Abstract
This document specifies extensions to Proxy Mobile IPv6 (PMIPv6) for
flow mobility support. Binding cache, binding update list and home
network prefix option are slighlty extended to allow indicating the
home interface and other interfaces.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 9, 2012.
Copyright Notice
Copyright (c) 2012 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
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 Simplified BSD License.
Sarikaya & Xia Expires December 9, 2012 [Page 1]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Multihoming Case . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . 7
7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
11.2. Informative references . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Sarikaya & Xia Expires December 9, 2012 [Page 2]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
1. Introduction
In Mobile IPv6 [RFC6275] 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.ietf-netext-logical-interface-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], [RFC6089] 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.ietf-netext-logical-interface-support].
Sarikaya & Xia Expires December 9, 2012 [Page 3]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
3. Problem Statement
In base Proxy Mobile IPv6 when MN connects simultaneously with
multiple interfaces each interface is treated independently and MN
uses different source addresses when sending packet over these
interfaces [RFC5213]. 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.
In based Proxy Mobile IPv6 LMA treats each interface independently of
the other interface(s) MN may have and tries to provide mobility
support for each interface. LMA does not manage bindings from
different interfaces of the mobile node in an integrated fashion. So
LMA can not be in control of moving the flows in between interfaces.
The solution to this is to modify the way the binding cache is
managed. Instead of creating an independent mobility session for
each interface, the bindings from each interface are kept together so
that the flows can be moved among interfaces. The extensions to the
base protocol needed for this should be minimal.
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 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.
Sarikaya & Xia Expires December 9, 2012 [Page 4]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
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" defined in Section 5.1 to all home
network prefixes assigned to this interface. Also the corresponding
value is set to the (H) flag of the home network interface option
defined in Section 7 in the binding 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
active 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. LMA refreshes the binding
cache entry for the interface with only "S" flag.
5. LMA Operation
When LMA receives a Binding Update message 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. In
the binding cache entry these HNPs MUST be flagged with a value of 0
representing "S". This binding cache entry becomes part of the
binding cache entry that contains home network prefixes with "H"
flag. "H" and "S" flags are as defined in Section 5.1.
LMA sends home network prefixes assigned to the new interface in the
Binding Acknowledgement message. LMA MUST also set the (H) Flag in
HNP option to 0. In the same BA message, LMA MAY also send home
network prefixes whose (H) flag is set to 1 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
One flag associated with the following binding cache entry: list of
IPv6 home network prefixes assigned to the mobile node's connected
interface and prefix length. The flag is set to 1 representing "H"
Sarikaya & Xia Expires December 9, 2012 [Page 5]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
if the connected interface is the home interface and flag is set to 0
representing "S" if the connected interface is not the home interface
but it is one of the secondary interfaces.
The prefixes assigned after the very first PBU is received for this
MN are assigned the "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
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, i.e. MN always sends non-local
packets with source address assigned from HNPs of its home interface.
LMA decides to which interface to route this packet by consulting the
flow mobility cache [I-D.ietf-netext-pmipv6-flowmob], similar to the
case in Mobile IPv6 [RFC6089]. The packet will be matched against
the flow descriptions [RFC6088] in the flow mobility cache 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
corresponding binding update list entry. There will be a maximum of
two sets of HNPs for each MN if the MAG is not connected to the home
interface.
MAG receives packets from LMA, decapsulates them and searches the
binding update list to find the corresponding enrty (with the "H"
flag) and sends them to the MN with the corresponding "S" flag.
Sarikaya & Xia Expires December 9, 2012 [Page 6]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
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 corresponding prefix length. The flag is set to 0
representing "H" if the connected interface is the home interface and
is set to 1 representing "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". MAG determines these flag values from the home
network prefix option's (H) flag.
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.
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 to 1 when this prefix is assigned to a secondary
interface of the mobile node, i.e. when the binding cache entry
for this HNP has "S" flag set. This flag is set to 0 when this
prefix is assigned to the firstly connecting or the only connected
interface of the mobile node, i.e. when the binding cache entry
Sarikaya & Xia Expires December 9, 2012 [Page 7]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
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
IANA is requested to add the H Flag into the reserved field in Home
Network Prefix Option defined in Section 8.3 in [RFC5213] as the
first bit, i.e. Bit number 16 and change the Reserved (R) field as
follows:
This 7-bit field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
10. Acknowledgements
The authors thank Hidetoshi Yokota who provided valuable comments.
11. References
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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
January 2011.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
Sarikaya & Xia Expires December 9, 2012 [Page 8]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
11.2. Informative references
[I-D.ietf-netext-pmipv6-flowmob]
Cano, C., "Proxy Mobile IPv6 Extensions to Support Flow
Mobility", draft-ietf-netext-pmipv6-flowmob-03 (work in
progress), March 2012.
[I-D.ietf-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
draft-ietf-netext-logical-interface-support-05 (work in
progress), April 2012.
Sarikaya & Xia Expires December 9, 2012 [Page 9]
Internet-Draft PMIPv6 Support for Flow Mobility June 2012
Authors' Addresses
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75074
Email: sarikaya@ieee.org
Frank Xia
Huawei
Nanjing, China
Phone:
Email: xiayangsong@huawei.com
Sarikaya & Xia Expires December 9, 2012 [Page 10]
