Internet DRAFT - draft-sarikaya-netext-flowmob-ext
draft-sarikaya-netext-flowmob-ext
Network Working Group B. Sarikaya
Internet-Draft Huawei
Expires: March 28, 2013 September 24, 2012
PMIPv6 Multihoming Support Extensions for Flow Mobility
draft-sarikaya-netext-flowmob-ext-00
Abstract
Base Proxy Mobile IPv6 multihoming support treats each active
interface of the Mobile Node separately and creates a different
binding cache entry for each interface. This is similar to Mobile
IPv6 restricting only one care-of address to be registered with the
home agent and this restriction which did not allow flow mobility
between interfaces has been removed by allowing multiple care-of
address registration. In this document we specify a similar solution
for Proxy Mobile IPv6 (PMIPv6) to support flow mobility among
simultaneously connected interfaces. 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 March 28, 2013.
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
Sarikaya Expires March 28, 2013 [Page 1]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Extensions to Binding Cache Entry . . . . . . . . . . . . 6
6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Extensions to Binding Update List Entry Data Structure . . 7
6.2. MN Operation . . . . . . . . . . . . . . . . . . . . . . . 7
7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative references . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Sarikaya Expires March 28, 2013 [Page 2]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
1. Introduction
Mobile IPv6 (MIPv6) previously allowed registering only one care-of
address called primary care-of address with the home agent of a
Mobile Node (MN). The underlying assumption was that only one
interface would be activated at a given time. This restriction has
been removed by allowing multiple care-of addresses to be registered
as in [RFC5648].
RFC5648 makes the distinction among the interfaces of MN attached to
the home link and all other interfaces attached to the visited
link(s). Home link has the home address and the visited links have
care-of addresses. A short value (16 bits) called Binding ID or BID
is used to identify each care-of address. MN sends Binding Update
message with Binding Identifier Mobility Option to register these
care-of addresses each assigned a unique BID. HA creates separate
binding cache entries connected to the home address for each distict
BID representing an active interface of MN connected to a visited
link.
Mobile node uses its home address, i.e. the address of the interface
attached to the home link 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 in a BU its
active flows with the HA using Flow Identification Mobility Option
associating the flow with one or more registered BIDs 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 [RFC6089].
Proxy Mobile IPv6 [RFC5213] lacks a similar mechanism because each
active interface is treated separately and a different binding cache
entry is created. This restriction is similar to MIPv6 not allowing
to register more than one care-of addresses with the HA. Handoff
between two different interfaces is allowed in multihoming support of
PMIPv6 as long as two different interfaces do not remain active
simultaneously.
This document proposes changes necessary to the local mobility anchor
(LMA) and Mobility Access Gateway (MAG) behaviour so that flow
mobility can seamlessly be supported in PMIPv6. The changes to the
mobile node are also needed to complement our solution on the host
side [I-D.ietf-netext-logical-interface-support].
Sarikaya Expires March 28, 2013 [Page 3]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
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.
This specification applies to multi-radio MNs.
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 packets over these
interfaces [RFC5213].
In base Proxy Mobile IPv6 [RFC5213] LMA treats each interface
independently of the other interface(s) MN may have and tries to
provide mobility support for each interface. When LMA receives Proxy
Binding Update (PBU) from a MAG it creates a new binding cache entry
and allocates a new mobility session for this new interface. In case
of inter-technology handover, LMA does not create a new binding cache
entry but it assigns the same home network prefix(es) to the new
interface. This binding cache entry represents the new interface and
it replaces the previous interface. Assigning the same HNPs enables
IP session continuity between these two interfaces.
LMA does not manage bindings from different interfaces of the mobile
node in an integrated fashion because the assumption is that only one
interface is active at a given time. So LMA can not be in control of
moving the flows between different 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 simultaneously active
interface are kept together so that the flows can be moved among
interfaces. The extensions to the base protocol needed for this
Sarikaya Expires March 28, 2013 [Page 4]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
should be minimal.
As in Mobile IPv6 [RFC5648], the distinction should be made of the
interfaces connected to the home link or to the visited link(s). In
this specification we call them home and secondary links/ interfaces,
respectively. Binding Identifier or BID is not used. BID is mainly
defined for multiple-interfaced mobile nodes with Mobile IPv6
functionalities. The BID is an identification number used to
distinguish multiple bindings registered by the mobile node. Each
BID is generated and managed by a mobile node in Mobile IPv6. In
Proxy Mobile IPv6, mobility management of mobile nodes with multiple
interfaces is run in different independent MAGs, and BID loses its
meaning.
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.
4. Solution Overview
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.
Sarikaya Expires March 28, 2013 [Page 5]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
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"
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
Sarikaya Expires March 28, 2013 [Page 6]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
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 entry (with the "H"
flag) and sends them to the MN with the corresponding "S" flag.
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.
6.2. MN Operation
MN moves into PMIPv6 domain and gets connected to its home link. MN
roams in PMIPv6 domain as described in Section 7 of [RFC5213].
When MN connects to a secondary link simultaneously with the home
link MN MUST use a source address from HNPs assigned to its home link
in its communication with the correspondent nodes.
Sarikaya Expires March 28, 2013 [Page 7]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
7. Message Formats
Home Network Prefix Option defined in [RFC5213] is modified to
include a flag to indicate if home network prefixes are associated
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
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:
Sarikaya Expires March 28, 2013 [Page 8]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
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.,
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]
Bernardos, C., "Proxy Mobile IPv6 Extensions to Support
Flow Mobility", draft-ietf-netext-pmipv6-flowmob-04 (work
in progress), July 2012.
[I-D.ietf-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
Sarikaya Expires March 28, 2013 [Page 9]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
draft-ietf-netext-logical-interface-support-05 (work in
progress), April 2012.
Sarikaya Expires March 28, 2013 [Page 10]
Internet-Draft PMIPv6 Support for Flow Mobility September 2012
Author's Address
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75024
Email: sarikaya@ieee.org
Sarikaya Expires March 28, 2013 [Page 11]
