Network Working Group T. Melia
Internet-Draft B. Mongazon-Cazavet
Intended status: Standards Track Alcatel-Lucent Bell Labs
Expires: September 9, 2010 March 08, 2010
Proxy Mobile IPv6 extensions for flow mobility support
draft-melia-netext-flow-mob-solution-01
Abstract
The Netext WG has been recently rechartered to determine what Proxy
Mobile IPv6 extensions are required for flow mobility support of a MN
implementing the single IP interface hiding mechanism. This document
briefly introduces the single IP interface hiding mechanism and it
derives the associated protocol operations to enable seamless flow
mobility across multiple access networks. These extensions are
intended to allow such mobile nodes to send and receive IP packets on
multiple physical media in a simultaneous and possibly discriminated
manner when attached to a PMIPv6 domain. A typical usage of these
extensions is to perform downlink flow discrimination through
multiple interfaces based on filtering rules (i.e. dedicate one MN
physical media to VOIP traffic and another MN media to HTTP traffic).
The proposed extensions to PMIPv6 attempt to increment in a backward
compatible manner the current PMIPv6 specification. In addition
these extensions use, when possible, existing specifications related
to multihoming support at IETF and conform to the problem statement
of Netext Working Group.
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 [RFC2119].RFC
(e&"
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
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 1]
Internet-Draft Flow Mobility March 2010
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 September 9, 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
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.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 2]
Internet-Draft Flow Mobility March 2010
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. OvervieW . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conceptual Data Structure . . . . . . . . . . . . . . . . . . 8
5. Detailed flow charts . . . . . . . . . . . . . . . . . . . . . 10
5.1. Initial multi-interface setup . . . . . . . . . . . . . . 10
5.2. Multi-interface renewal . . . . . . . . . . . . . . . . . 11
5.3. Multi-interface filters modification MN initiated . . . . 12
5.4. Multi-interface filters modification network initiated . . 13
5.5. Multi-interface interface removal . . . . . . . . . . . . 14
5.6. Multi-interface interface addition . . . . . . . . . . . . 14
6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 15
6.1. Multi-interface Option . . . . . . . . . . . . . . . . . . 15
6.2. Flow Identifier Option . . . . . . . . . . . . . . . . . . 17
7. MAG behavior . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. LMA behavior . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. BCE modifications . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Options carried during attachment procedures . . . . . . . 20
12.2. Singalling to convey filters to the MAG . . . . . . . . . 20
12.3. Experimenting the bonding interface . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 3]
Internet-Draft Flow Mobility March 2010
1. Terminology
This document uses the following terminology:
MIGID Multi-interface Group ID: a set of physical interfaces (two or
more) belonging to the same MN. On the same MN multiple MIGID can
be configured.
NIC Network Interface Card: it provides physical access to a
networking medium and provides a low-level addressing system
through the use of MAC addresses.
Bonding Ethernet bonding: is a computer networking arrangement in
which two or more network interfaces on a host computer are
combined for redundancy or increased throughput, the resulting
logical IP interface is called bonding interface.
MASTER Master of the bonding device.
SLAVE Slave of the bonding device.
UL Up Link: flows sent from the MN to the network.
DL Down link: flows send from the network to the MN.
2. Introduction
Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network
based mobility management to hosts connecting to a PMIPv6 domain.
PMIPv6 introduces two functional entities, the Local Mobility Anchor
(LMA) and the Mobility Access Gateway (MAG). The MAG is the first
layer-three hop detecting MN attachment and providing IP
connectivity. The LMA is the entity assigning one or more Home
Network Prefix (HNP) to the MN and is the topological anchor for all
traffic from/to the MN.
PMIPv6 allows a MN to connect to the same PMIPv6 domain through
multiple interfaces. However in this case, PMIPv6 requires each
interface to be assigned a set of distinct IPv6 address(es) and thus
prevents from flow mobility capabilities. The revised Netext charter
imposes that the MN uses a single logical IP interface to hide the
use of multiple wireless/wired media to the IP stack. In this
context the MN is requested to:
o configure the logical IP interface (master) and bind to this
logical interface two or more wireless/wired physical media
(slaves)
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 4]
Internet-Draft Flow Mobility March 2010
o perform layer two network attachment and co-ordinate neighbor
discovery mechanisms
o configure one or more IPv4 and/or IPv6 HNP on the logical IP
interface
o configure local policies for physical media selection for UL
traffic
o send/receive triggers for flow mobility to/from the network and
local policy update
Configuration of a single logical IP interface strictly depends on
the OS running in the MN. In Linux/Unix systems virtual interfaces
can be configured with the bonding technology. Ethernet bonding (or
NIC teaming in Windows OS) allows a host equipped with two or more
Ethernet NICs to be connected to one or more layer two switch and to
exploit the different NICs for different purposes being reliability,
load balancing and bandwidth aggregation some of the possible use
cases. As an example, a host equipped with 4 NICs can configure its
bonding module for reliability. In case one of the NICs notifies a
link failure the following one in the slaves list can take the relay.
Alternatively a server, equipped with multiple NICs can be configured
to optimize bandwidth aggregation. For an exhaustive list of the
different bonding modes in Linux please refer to the Ethernet bonding
driver. Under the Window OS the NDIS driver type can be used to
create an NDIS Intermediate Driver. Intermediate drivers sit in-
between the MAC and IP layers and can control all traffic being
accepted by the NIC card.
Upon logical interface configuration the MN should perform network
attachment and IPv6 neighbor discovery. If we consider the Linux
bonding interface, the logical interface (master) and the physical
interfaces (slave) share the same MAC address. The PMIPv6 domain
where the MN is attaching to can only detect one interface and
additional intelligence is required to notify the PMIPv6 domain that
both physical interfaces need to be simultaneously connected to the
same LMA. In other words, if the MN attaches the physical interface
IF1 and configures HNPA, when it attaches physical interface IF2 it
should always configure HNPA and, accordingly, the LMA should record
both bindings in the BCE (i.e. this is not an intra-technology
handover). Additionally, depending on the configured bonding mode,
IPv6 neighbor discovery messages should be treated differently than
data plane (e.g; bonding configured in round robin mode sends packets
iterating across the interfaces).
For IP address configuration the MN can exchange DHCP or ND
signaling. In case of ND signaling the MN should send RS messages
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 5]
Internet-Draft Flow Mobility March 2010
and wait for unicast RA from the MAG. For DHCP the MN sends a DHCP
request to the MAG and waits for the DHCP reply carrying the HNP. In
both cases, as stated above, the bonding module (given the nature of
the Ethernet environments where it usually operates) selects any of
the physical interfaces to send out the packet. This has
shortcomings since each for the two links should be carrying DHCP/ND
messages. It seems intuitive that layer two interaction is required.
Upon configuration of one or more HNP on the logical IP interface the
MN needs to equally configure policies for media selection for UL
packets routing. Policies configuration can happen upon network
attachment ( and transferred to the MN by means of layer two
signaling) or dynamically via an external channel. This document
assumes that L2 signaling can carry such information and that PMIPv6
signaling can convey the routing policies from/to the LMA to/from the
MAG. Along the same lines policies update can occur during the
lifetime of a binding connection. Update of such policies may result
in moving ongoing flows from one access network to another access
network.
In principle a MN can have two or more NICs and one or more logical
interface can be configured. In this sense logical interface A can
group IF1 and IF2 and logical interface B can group IF3 and IF4. The
document introduces therefore the concept of Multi Interface Group
IDentifier (MIGID) (a logical set of physical interfaces of a MN) and
provides the support of elementary operations (addition,
modification, removal) on a group entity for a MN. This terminology
is expected to be more suited to the general multi-interface
paradigm. In case the terminal can signal to the network (e.g.
during authentication procedures) the desired MIGID, the MAG will
then transfer the MIGID to the LMA in the newly defined MIGID option.
If this is not possible a default value (MIGID=0) is defined to
represent all interfaces of a given MN (e.g. the user profile
indicates that he is eligible for multi-interface support in the
PMIPv6 domain and the MIGID is set to 0).
3. OvervieW
The functional usage of multi-interface MN capabilities in a PMIPv6
domain is defined by the present specification in a flexible and
multi-purpose manner. This allows for various traffic processing in
a PMIPv6 domain with multi-interface MN such as (but not limited to):
traffic blocking, traffic load-balancing or traffic dissemination.
To achieve this flexibility, this document uses the concept of
"filter" to denote a unitary criteria that can be managed between a
MAG and a LMA in relationship with a MN interface. Unitary filters
can be added, deleted and modified on a per multi-interface group
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 6]
Internet-Draft Flow Mobility March 2010
basis. Flexibility is achieved by allowing an arbitrary filter
syntax (or grammar) as proposed in [MEXT]. The filter syntax is a
matter of agreement between MAG and LMA entities. For the sake of
understanding, the "flow" and "filter" terminology shall be
considered equivalent.
The following Figure 1 depicts the general principles of PMIPv6
extensions for flow mobility support as proposed by the present
document.
LMA State
+----+ ---------
|LMA | (addr, pCoA1, flow1, migid)
+----+ (addr, pCoA2, flow2, migid)
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
pCoA1 // \\ pCoA2
+----+ +----+
if1 -> migid |MAG1| |MAG2| if2 -> migid
+----+ +----+
| |
| |
| if1 if2 |
+------[MN]------+
addr
Figure 1: Multi-interface MN with PMIPv6 extensions
When MN activates if1, MAG1selects the default multi-interface group.
The MAG can learn the MIGID during network authentication as part of
the authentication signaling or fetch the information from the user
profile. If the user is eligible for flow mobility service the MAG
performs proxy registration toward the LMA including the flow
mobility option and it can optionally provide filters (flow1) during
registration (e.g. default filters can be stored in the user
profile). The LMA accepts proxy registration from MAG1 and allocates
MN HNP according to the per MN prefix model. Since proxy
registration is requesting flow mobility support, LMA stores MAG1
filters that come along with delivery to pCoA1.
When MN activates if2, MAG2 selects the default multi-interface group
(similarly to the steps described for if1) and performs proxy
registration toward the LMA. MAG2 can provide filters (flow2) during
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 7]
Internet-Draft Flow Mobility March 2010
registration. LMA accepts proxy registration from MAG2 and allocates
MN HNP according to the per MN prefix model. LMA stores MAG2 filters
that come along with delivery to pCoA2. The LMA should update the
existing mobility session and append the parameters for if2. That
is, a single mobility session spans over two access networks as
opposed to RFC 5213 baseline.
Later on, when the LMA receives IP packets destinated to MN HNP, it
attempts to match each IP packet against filters (flow1, flow2)
stored for the MN HNP. When a filter match is found (flow1 or
flow2), the LMA performs the action for the IP packet in the context
of the matching flow. In particular if the IP packet is to be
delivered, the LMA performs delivery using the pCoA associated to the
filter (pCoA1 on flow1 or pCoA2 on flow2).
LMA behavior is extended to allow simultaneous transmission of
downlink (DL) flows to the mobile node across multiple physical
interfaces. For UL flows it is assumed that the MN can configure
local policies based on user preferences, operator policies,
applications requirements, etc... This document does not make any
assumption on the order in which rules should be considered neither
if some policies have higher priority with respect to others. This
document further assumes that the MN is capable of transmitting
policies to the MAG., either during network attachment or upon
reception of specific layer two triggers (e.g. Link going down). In
this case the MN is said to trigger the flow mobility procedure
(please refer to the appendix on how filters can be transmitted to
the MAG).
Both LMA and MAG behaviors are extended to provide enhanced Proxy
Binding management for multi-interface MN. LMA shall support Binding
Control Entries (BCE) of multi-interface type. This includes the
capability to refer to a MIGID and a set of filters in a BCE. LMA
shall support or delegate the downlink packet processing and delivery
according to flow specifications. Both MAG and LMA shall be able to
manage flows on a per multi-interface group basis. This document
also assumes that the network can equally start a flow mobility
procedure based, for instance, on network load conditions.
4. Conceptual Data Structure
This specification proposes to extend PMIPv6 to support multiple
proxy CoAs per mobility session possibly associated with downlink
transmission criteria using the flow concept.
Upon MN attachment the MAG determines if the MN should be provided
with multi-interface service and, if so, selects the flow
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 8]
Internet-Draft Flow Mobility March 2010
configuration that should be put in place for packet delivery. The
MAG can learn this information through a policy store or using
attachment-specific signaling. Any of the method used by the MAG is
however out of scope of this document. If the MAG determines that
the MN can use the multi-interface service it forms a PBU as per
[RFC5213] and adds a Multi-interface Option (newly defined by this
document) and possibly one or several Flow Identifier option(s) as
defined in [MEXT]. The Multi-interface option aims at identifying
(MIGID) and parameterizing the multi-interface group to be created/
updated/deleted by the LMA on MAG demand. The choice of
identification of the multi-interface group follows the following
rule:
All PBUs with the same HNP and MIGID values belong to the same
mobility session from the LMA perspective.
In the current revision of the document, only the default multi-
interface group is supported (id=0). In addition, multi-interface
group parameters are left for further study.
Mobility Session 1 Mobility Session 1
+----------------------+ +---------------------+
| HNP1 PCoA1 MIGID0 | ========> | HNP1 PCoA1 MIGID0 |
+----------------------+ | HNP1 PCoA2 MIGID0 |
+---------------------+
Figure 2: Mobility session extended for multi-interface
Figure 2 shows how the mobility session is extended to span the same
HNP across multiple interfaces. This updates the text in [RFC5213]
where each single interface is managed under a different mobility
session. The MIGID, selected by MAG1 (corresponding to PCoA1) upon
MN attachment, is stored at the LMA. When the MN attaches to MAG2
(corresponding to PCoA2) MAG2 selects the MIGID value either received
as part of the attachment signaling or via the policy profile. If
both MAG1 and MAG2 MIGID and HNP values match then the LMA adds PCoA2
-- migid0 to the already existing mobility session.
It should be noted that the MAG, as per RFC 5213, must be able to
obtain a mobile node's policy profile. The following fields are
mandatory: the mobile node's identifier (MN-Identifier) and the IPv6
address of the local mobility anchor. We further suggest to include
the MIGID which should be used for default multi interface setup. In
case the MN is capable to signal the MIGID to the MAG upon attachment
multiple MIGID can be stored at the LMA, each of them corresponding
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 9]
Internet-Draft Flow Mobility March 2010
to a mobility session. The policy profile can optionally contain
default filters.
The MAG treats the indication of multi-interface as an explicit
indication of adding flows to the PBU if any. Such flows can be
learned for instance during MN access to the network or via the user
profile.
Upon reception of a PBU containing indication for multi-interface the
LMA should perform a binding cache lookup and append the information
to the found BCE. Filters, if present, are extracted from the PBU
and processed by the LMA. The result of filters processing is
returned in the PBA by the LMA on an individual basis.
5. Detailed flow charts
This section introduces detailed flow charts for multi-interface
setup, renewal, filters modifications and interface removal/addition.
5.1. Initial multi-interface setup
Figure 3 shows the attachment of IF1 and subsequently the attachment
of IF2. IF1 and IF2 belong to the same MIGID (i.e. the default
multi-interface group id 0).
MAG1 upon MN attachment checks the MN's policy profile. If the MN is
eligible for multi-interface service it includes the MIGID value from
the policy profile. The multi interface option (defined in this
document) is included in the PBU. The LMA upon reception of the PBU
creates a new mobility session and it includes the received
parameters (e.g. MIGID, filters).
When MN attaches interface IF2 MAG2 retrieves the same MIGID from the
MN's policy profile and it appends filters (e.g. specific to that
access network). The LMA performing the lookup to check if a
mobility session already exists for the indicated MN_ID should update
its binding cache and append the parameters for the new connection.
The same HNP MUST be sent to the MAG via the PBA and advertised to
the MN. Please refer to the appendix for considerations on default
route configuration.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 10]
Internet-Draft Flow Mobility March 2010
+-----+ +------+ +------+ +-----+
| MN | | MAG1 | | MAG2 | | LMA |
+-----+ +--|---+ +------+ +-----+
| | | MN_ID, PCoA1, |
MN[IF1] Attached MAG1 | MIGID0, HI=1, |
| | | Filters_1 RQ |
| |------------ PBU ------------->|
| | | |MN_ID, HNP1, PCoA1,
| |<------------- PBA ------------|MIGID0, HI=1,
|---RtSol---->| | |Filters_1 RP
| |==== Bi-Dir Tunnel ============|
|<--Rtr Adv --| | |
| | | |
IP Address | |
Configuration |MN_ID, PCoA2, |
| |MGHID0, HI=1, |
|MN[IF2] Attached MAG2 |Filters_2 RQ |
| |------------ PBU ---->|
| | |MN_ID, HNP1, PCoA2,
| |<---- PBA ------------|MIGID0, HI=1,
|---RtSol------------->| |Filters_2 RP
| | |
|<-----------Rtr Adv --| |
IP Address | |
Configuration | |
| | |
Figure 3: Initial multi-interface setup
5.2. Multi-interface renewal
Figure 4 shows binding renewal upon lifetime expiration. MAG1 and
MAG2 should renew bindings at the LMA as per RFC 5213 and optionally
include new filters if necessary.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 11]
Internet-Draft Flow Mobility March 2010
+-----+ +------+ +------+ +-----+
| MN | | MAG1 | | MAG2 | | LMA |
+-----+ +--|---+ +------+ +-----+
| | | |
MN[IF1] Attached MAG1 | HNP1, PCoA1, |
Lifetime expires | | MGHID0, HI=5 |
| |------------ PBU ------------->|
| | | |HNP1, PCoA1,
| |<------------- PBA ------------|MGHID0, HI=5
| | |
| | |
MN[IF2] Attached MAG1 | |
Lifetime expires | |
| | |
| | |
| |HNP1, PCoA2, |
| |MGHID0, HI=5 |
| |------------ PBU ---->|
| | |HNP1, PCoA2,
| |<---- PBA ------------|MGHID0, HI=5
| | |
| | |
Figure 4: Multi-inerface renewal
5.3. Multi-interface filters modification MN initiated
Filters can also be modified upon reception of an external MAG
trigger Figure 5 (in this case MN initiated). From the PMIPv6 point
of view, filters modification is carried by binding renewal semantics
(HI=5). The target multi-interface group is set by the MAG in the
multi-interface option (MIGID field). This allows MAG to modify at
any time the downlink filters it is responsible for. For a
discussion on how MN can send modified triggers to the MAG please
refer to the Annex discussion. In this case the MN is also supposed
to update its UL filters accordingly.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 12]
Internet-Draft Flow Mobility March 2010
+-----+ +------+ +------+ +-----+
| MN | | MAG1 | | MAG2 | | LMA |
+-----+ +--|---+ +------+ +-----+
| | | HNP1, PCoA1, |
MN[IF1] Attached MAG1 | MIGID0, HI=5 |
MN triggers flow modif | Filters_1_modifs RQ
|------------>|------------ PBU ------------->|
| | | |HNP1, PCoA1,
| |<------------- PBA ------------|MGHID0, HI=5
|<--ACK-------| | Filters_1_modifs RP
| | | |
Figure 5: Multi-interface filters modification MN initiated
5.4. Multi-interface filters modification network initiated
The MAG might receive network triggers as a request to move flows due
for instance to changed QoS conditions. To this end the MAG should
send a PBU to the LMA including filters that can be potentially
modified. The LMA will respond with a PBA updating the cenessary
filters. While the procedure can be considered to add complexity, it
does not require semantic changes to the current signalling.
Additionally it should be noted that in the context of the 3GPP
Evolved Packet System the EPS bearer is terminated at the S-GW,
policy enforcement point and implementing the MAG funciotnality.
Further specification will be carried on in the next revision of this
document.
+-----+ +------+ +------+ +-----+
| MN | | MAG1 | | MAG2 | | LMA |
+--|--+ +--|---+ +--|---+ +--|--+
| | | |
MN[IF1] Attached MAG1 | |
MAG triggers flow modif | |
| | | HNP1, PCoA1, |
|<------------| | MIGID0, HI=5 |
| | | Filters_1_modifs RQ
|---ACK------>| | |
| |------------ PBU ------------->|
| | | |HNP1, PCoA1,
| |<------------- PBA ------------|MGHID0, HI=5
| | | Filters_1_modifs RP
| | | |
Figure 6: Multi-interface filters modification NW initiated
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 13]
Internet-Draft Flow Mobility March 2010
5.5. Multi-interface interface removal
Figure 7 shows how to remove an interface from a multi-interface
group managed by a MAG for a given MN. The target multi-interface
group is set by the MAG in the multi-interface option (MIGID field).
In this case it is supposed that all the existing flows are moved to
IF2.
+-----+ +------+ +------+ +-----+
| MN | | MAG1 | | MAG2 | | LMA |
+-----+ +--|---+ +------+ +-----+
| | | HNP1, PCoA1, |
MN[IF1] Attached MAG1 | MIGID0, HI=4 |
LINK going down | | LIFETIME = 0 |
| |------------ PBU ------------->|
| | | |HNP1, PCoA1,
| |<------------- PBA ------------|MIGID0, HI=4
| | |
Figure 7: Multi-interface interface removal
5.6. Multi-interface interface addition
Figure 8 addresses the case where the MN adds a third interface to
the same multi-interface group for a given MN. The target multi-
interface group is set by the MAG in the multi-interface option
(MIGID field). Filters modification can happen as described above.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 14]
Internet-Draft Flow Mobility March 2010
(------)
+-----+ ( MAG1 ) +------+ +-----+
| MN | ( MAG2 ) | MAG3 | | LMA |
+-----+ (------) +------+ +-----+
| | MN_ID, PCoA3, |
MN[IF1] and MN[IF2] | MIGID0, HI=1, |
attached to MAG1 and MAG2 | Filtrers_3 RQ |
| |--- PBU ------------->|
| | | HNP1, PCoA3,
| |<---- PBA ------------| MIGID0, HI=1,
| | | Filtrers_3 RP
| |== Bi-Dir Tunnel =====|
| | |
|---RtSol------------->| |
| | |
|<-------Rtr Adv-------| |
| | |
Figure 8: Multihoming interface addition
6. Protocol Extensions
We provide in the following extensions to the protocol options as
defined in [RFC5213].
6.1. Multi-interface Option
Figure 9 shows the Multi-interface option.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 15]
Internet-Draft Flow Mobility March 2010
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 | MIGID | ACT | RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field
MUST be set to 2.
MIGID
This 8 bit field identifies the multi-interface group the PBU/PBA refer to.
The value 0 is reserved to the default multi-interface group which includes
all interfaces of a MN. Only value 0 is currently supported.
ACT
This 3-bit field is used to provide optional action to be
performed by LMA upon removal of an interface from a multi-interface
group. The field shall only be set by the MAG when HI value in
PBU is set to 4, otherwise the field shall be set to 0.
The following bit values are currently defined:
000: Reserved
001: Remove filters
010: Keep filters
RFU (Reserved for Future Use)
This 5-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
Figure 9: Multi-interface option
The following considerations on the ACT field apply. If 001 (Remove
filters) is set on interface removal, the LMA shall remove all
filters currently configured. This might result in downlink traffic
disruption. If 010 (Keep filters) is set on interface removal, the
LMA shall arrange to re-instantiate filters configured on the removed
interface to existing filters (if any) of other interfaces of the
multi-interface group if any. This allows to avoid downlink traffic
disruption.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 16]
Internet-Draft Flow Mobility March 2010
However, a filter that has been re-instantiated on a interface should
be advertised by the LMA with a specific status of Flow identifier
option whenever a MAG performs a filter operation the interface.
6.2. Flow Identifier Option
The FID option defined in ID [MEXT] is used in the current
specification to manage downlink packet delivery across interfaces of
a multi interface MN. The option might be used by a MAG to create/
modify/delete filter(s) on the LMA for a particular multi-interface
group of a MN. Upon successful processing and installation of
filter(s) at LMA level an individual status (Status field) shall be
returned to the MAG by the LMA. The LMA should later evaluate
packets destinated to a MN through filters installed by MAG(s) that
are proxying the MN under the same mobility session. The LMA must
perform the action(s) associated to the matching filter(s).
In case, the LMA re-instantiates flows on a multi-interface group
toward a MAG for a given MN, the LMA shall perform the following
processing:
o Allocate a unique FID to the re-instantiated filter within the
context of existing filters for the multi-interface group of the
MN toward the target LMA
o Set the PRO field to a new reserved value (2: flow binding re-
instantiated by LMA) of [MEXT] as proposed by the current
specification
o Copy FID-PRI and Action fields from the original filter into the
re-instantiated filter
The binding revocation mechanism can be used to indicate to the MAG
that multi-interface service has changed. Alternatively re-
instantiated filter(s) will be returned by LMA only on MAG demand.
This might happen when MAG renews PBU or create/modify/delete its own
filters.
The format of the option is briefly recalled hereafter. The present
specification proposes to extend the PRO field value in order to add
the (2: flow binding re-instantiated by LMA) predefined value. The
full specification of the option can be found in [MEXT]
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 17]
Internet-Draft Flow Mobility March 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID-PRI | Action | Rsvd | PRO | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: FID Option Action values
7. MAG behavior
The MAG upon MN attachment performs all the steps as per [RFC5213].
In addition to this it MUST perform the following checks.
The MAG learns if the MN is requesting a HNP as part of a new
mobility session or if it is requesting to attach a new interface as
part of an already existing mobility session. The MAG retrieves the
MIGID from e.g. MN's profile as well as filters. The MAG can learn
filters in an access-specific manner or alternatively via other
infrastructure support. This is however out of scope of this
document. In any case the MAG MUST encode the PBU including at least
the Multi-interface option as specified before and possibly one or
more FID option(s).
The MAG can modify or delete filters attached to a multi-interface
group by sending a PBU carrying the filter operation(s) to be
performed. It shall analyze individual results according to what is
returned by the LMA. In addition, MAG should be prepared to handle
filters that have been re-instantiated by LMA when MN has
disconnected an interface belonging to the same multi-interface
group.
When MAG proxying a MN detects the MN has detached the related
interface, MAG stops proxying the MN by sending a PBU with lifetime
set to 0 and includes the multi-interface option that identifies the
target multi-interface group of the detached interface as well as
removal behavior regarding filters. MAG waits for successful PBA to
release the MN access.
8. LMA behavior
The LMA should be modified in the BCE and conceptual data structures.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 18]
Internet-Draft Flow Mobility March 2010
8.1. BCE modifications
The LMA binding cache lookup method should be extended to accommodate
multi-interface support. In case the LMA processes the Multi-
interface Option it SHOULD update existing mobility session as
defined in [RFC5213]. In addition to this it MUST perform the
following checks.
If the Multi-interface option is present in the PBU, the LMA must
allocate/update/delete the mobility session and the multi-interface
group ID it refers to. Flow filters received in the PBU shall be
created/modified/deleted for the target Multi-interface group ID and
a result shall be return on an individual filter basis.
In addition, the LMA shall handle removal of interfaces from multi-
interface group according to MAG instructions. In particular, if a
MAG instructs a LMA to remove an interface from a multi-interface
group but to keep filters, the LMA should re-instantiate filters on
existing interface(s) of the multi-interface group according to its
own mechanisms.
If a LMA does not support multi-interface extension (as a whole) or
specific multi-interface option, as proposed by the present document,
it shall return a status code in PBA as defined in [RFC5213]. The
later specification might be extended to include multi-homing
specific statuses, such as:
MI_NOT_SUPPORTED_BY_LMA
MI_FILTERS_REINSTANCIATION_NOT_SUPPORTED_BY_LMA
9. IANA Considerations
This document makes no request of IANA.
10. Security Considerations
This document only extends existing options, no security issues are
introduced.
11. Acknowledgements
The authors would like to thank Fabio Giust for carrying over the
implementation of this document.
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 19]
Internet-Draft Flow Mobility March 2010
12. Annex
The following Annex discusses few issues related to MN-to-MAG
signaling and MN configuration and it should open the floor for
discussion.
12.1. Options carried during attachment procedures
This document makes the assumption that the MN policy profile stores
the information on Multi-Interface Group ID. The MN could optionally
signal to the network the request to create a BCE at the LMA
supporting multiple interfaces, for instance as part of the EAP
exchange. Further revisions of this document will detail how this
can be achieved.
12.2. Singalling to convey filters to the MAG
IEEE 802.21 signaling can be used to carry filters from the MN to the
MAG. IETF standardized IP transport for MIH packets. One could
leverage the vendor specific options in the MIH packet to convey to
the MAG the required filters. It should be noted that the IEEE
802.21 framework suggests to deploy MIH Point of Service together
with the MAG functionality. Further revisions of this document will
detail how this can be achieved.
12.3. Experimenting the bonding interface
The following testbed has been setup:
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 20]
Internet-Draft Flow Mobility March 2010
+-----+
| C N |
+-----+
| LMA Binding Cache LMA policy/routing table
| ===================== ============================
| MN:if1, pref1, MAG1 flow1(6-tuple1)->MAG2
+-----+ :if2, pref1, MAG2 flow2(6-tuple2)->MAG2
| LMA | ...
+-----+ flowN(6-tupleN)->MAG1
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1/MAG2 routing table
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 directly connected
| |
| |
| pref1 pref1 |
| if1 if2 |
+-------[MN]------+ MN implements the bonding device
(WLAN) (3G)
Figure 11: Test network setup
The MN implements the bonding interface. Linux kernel provides a
module called "bonding" to group together several interfaces (or
"slaves", in the module's terminology) that will have the same L2 and
L3 address and figure out to be as just one interface. The module
offers the possibility to select the transmitting slave according to
per-configured policies. Unfortunately these policies don't cover
the scope of flow management so the module has to be extended to
allow an external input to select the transmitting slave.
Attachment of the bonding MN should be helped by layer two support to
avoid modifications to the ND protocol. L2 attachment procedures
should trigger the PBU in the MAG. Further when the LMA receives a
PBU from a MAG for a Proxy Registration, it may find that the BCE
already exists with a different CoA, as that CoA is the address of
the MAG to which another interface of the same MN is attached. This
may be interpreted as an unexpected handover if the handoff indicator
field isn't properly set. The Access Technology Type in conjunction
with a new value of the HI field in the PBU might be used to avoid
conflicts in the registration. The correct behavior for the LMA
would lead to a new tunnel creation in order to allow the MN to be
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 21]
Internet-Draft Flow Mobility March 2010
reached via all the MAGs to which the MN's interfaces are attached.
That's why the BCE format must be extended too to contain multiple
CoAs and tunnel identifiers.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
13.2. Informative References
[MEXT] IETF MEXT Working Group, "Flow Bindings in Mobile IPv6 and
Nemo Basic Support", April 2009.
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008.
Authors' Addresses
Telemaco Melia
Alcatel-Lucent Bell Labs
Email: telemaco.melia@gmail.com
Bruno Mongazon-Cazavet
Alcatel-Lucent Bell Labs
Email: Bruno.Mongazon-Cazavet@alcatel-lucent.com
Melia & Mongazon-Cazavet Expires September 9, 2010 [Page 22]