NETEXT Working Group Y. Cui
Internet Draft H. Wang
Intended status: Standard Track T. Ma
Expires: April 2010 Tsinghua University
October 18, 2009
Simultaneous Multi-Access for PMIPv6 based on Single HNP Model
draft-cui-netext-sma-pmipv6-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 April 18, 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.
Cui, et al. Expires April 18, 2010 [Page 1]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
Abstract
Simultaneous Multi-Access (SMA), originally designed for MIPv6,
expects to be ported to PMIPv6 to achieve flow binding. However,
there are a lot of problems to adapt SMA to PMIPv6 due to
different mechanisms of two mobility management protocol. This
document analyzes issues of SMA and different multihoming
scenarios in PMIPv6. A PMIPv6 system which allows a MN to share
HNP across its interfaces is proposed and a SMA solution is
designed for the modified PMIPv6 system. The solution supports
flow-based routing and address-based routing simultaneously.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Overview.......................................................3
3.1. Issues of SMA Support in PMIPv6...........................3
3.2. Multihoming Scenarios of PMIPv6...........................5
3.2.1. Multiple HNP Model...................................5
3.2.2. Single HNP Model.....................................6
4. PMIPv6 based on Single HNP Model...............................6
4.1. HNP Allocation and Address Configuration..................6
4.2. Routing of LMA and MAG....................................7
5. SMA Operations.................................................8
5.1. Registration of Routing Rules.............................8
5.2. Data Transmission.........................................9
5.2.1. Sending Packet from MN..............................10
5.2.2. Sending Packet to MN................................10
5.3. Vertical Handoff.........................................11
6. Conclusion....................................................13
7. Security Considerations.......................................13
8. IANA Considerations...........................................13
9. References....................................................13
9.1. Normative References.....................................13
9.2. Informative References...................................13
10. Acknowledgments..............................................14
Cui, et al. Expires April 18, 2010 [Page 2]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [1] allows a multihoming mobile node to
connect to a PMIPv6 domain via multiple interfaces simultaneously.
With several paths available, flows could be bind to different
path to achieve load-balance, high aggregated bandwidth and flow
mobility. Simultaneous Multi-Access (SMA) [2], which is proposed
to takes these advantages of multihoming in MIPv6, could be
adapted to PMIPv6 to enable flow bindings. However, because of the
fact that MN uses different Home Network Prefixes (HNPs) on
different interfaces rather than a unique Home Address of MN in
MIPv6, additional mechanism such as Primary Prefix is introduced
into PMIPv6 to ensure packets can be routed to MN via a proper
path [3].
As for the PMIPv6 specification, assigning different HNPs for
different interfaces of one MN is regarded as lack of simultaneous
usage support and therefore is difficult to provide flow binding
support [4]. Besides this proposal, sharing the same HNPs across
multiple interfaces of one MN in PMIPv6 is proposed as a solution
for multihoming (different MNs are still assigned different HNPs).
This model is able to provide convenience for some multihoming
application, including flow-based routing [5].
This document describes a SMA solution for PMIPv6 based on Single
HNP Model. In the rest of the document, the issues of SMA support
in PMIPv6 and the advantages of sharing HNPs across interfaces are
analyzed. Based on the modified PMIPv6 system, a SMA solution is
proposed to support both address-based routing and flow-based
routing.
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 RFC-2119.
3. Overview
3.1. Issues of SMA Support in PMIPv6
SMA, originally designed for MIPv6, aims to take advantages of
multihoming. Its primary idea is to use policies to bind flow to a
specified path based on different characteristics of multiple
available paths (such as bandwidth, QoS, cost, etc.). In another
word, MIPv6 system equipped with SMA function performs flow-based
routing; both inbound packets and outbound packets are directed to
a specified interface by either HA or MN according to policies.
In MIPv6, each MN has a unique Home Address (HoA) which is always
used as the source address of outbound packet and the destination
Cui, et al. Expires April 18, 2010 [Page 3]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
address of inbound packet. Without regard to route optimization,
tunnels from HA to MN ensures that packets can be routed to either
MN or CN properly no matter which interface MN uses to transmit
packets. Therefore, there is little difficulty in performing SMA
in MIPv6.
However, the situation is quite different in PMIPv6. First of
all, unlike the unique HoA in MIPv6, MN is assigned different HNPs
for each interface in PMIPv6 and consequently addresses of
interfaces are different from each other. When communicating with
CN, MN use the address on the outgoing physical interface so it
could lead to troubles to bind an existing flow, which is usually
identified by the source and destination addresses, to another
interface. Flow-based routing might cause conflict with address-
based routing for the address of bound interface might not match
with the address of the flow.
Second, additional mechanism is necessary to guarantee the
validity of routing. Tunnels are built from LMA to MAGs rather
than MN in PMIPv6. Therefore, even if LMA is able to perform flow-
based routing to select a proper MAG to forward packets to,
additional mechanisms are necessary to introduced to MAGs to
ensure they are able to relay packets to MN. Take the scenario in
Figure 1 as an example. MAG2 should have the information about
HNP1 so as to forward Flow1 to MN via IF2. Otherwise, MAG2 cannot
find a route match the destination of the packet; even if MAG2 is
able to perform flow-based routing, it has to recognize which MN
the flow belongs to by matching the destination address of the
flow.
Third, MN has to be extended to support SMA in PMIPv6. PMIPv6 is
designed as a network-based mobility management protocol so that
MN needs no extension to get mobility support in a PMIPv6 domain.
However, to enable SMA function, MN has to be modified to support
the generation and transmission of routing rules as well as flow
binding operation. Moreover, owing to the above-mentioned two
issues, existing proposal involves MN in mobility management to
request Primary Prefix and to update Binding ID [3].
In short, flow-based routing of SMA relies on address-based
routing because only address information of a packet can be used
to identify the corresponding MN. With regard to PMIPv6, since
there is no direct tunnel from LMA to MN, HNP allocation and
conventional address-based routing of PMIPv6 should coordinate
with SMA mechanism to achieve flow binding. Moreover, extension to
MN is also necessary to make full use of multihoming.
Cui, et al. Expires April 18, 2010 [Page 4]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
+----+
| CN |
+----+
|
+-------+
| LMA | Flow1 -> IF2
+-------+
/ \ ----+ Flow1
/ \ | Src Addr: CN
/ \ | Dst Addr: HNP1
/ \ v
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
\ /
\ /
\ /
+-----------+
IF1: HNP1 | IF1 | IF2 | IF2: HNP2
+-----+-----+
| MN |
+-----------+
Figure 1 Routing Problem of SMA in PMIPv6
3.2. Multihoming Scenarios of PMIPv6
Different scenarios of multihoming in PMIPv6 can be divided into
two categories according to their HNP model. One is multiple HNP
model that assign unique HNP to each interface; the other is
single HNP model that assign the same HNP across interfaces of one
MN.
3.2.1. Multiple HNP Model
PMIPv6, defined in [1], use this model to assign HNP for MN. In
this model, each interface is assigned a unique HNP so a
multihoming MN always gets multiple HNPs; each binding tied to an
interface of MN is considered as a separate mobility session;
multiple interfaces are able to connect to PMIPv6 domain
simultaneously and transmit data independently. However, some
advanced multihoming application meets troubles in this model,
including HNP allocation in vertical handoff, lack of simultaneous
usage support [4], aforementioned SMA issues, etc.
Cui, et al. Expires April 18, 2010 [Page 5]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
3.2.2. Single HNP Model
In this model, a HNP is shared across different interfaces one MN.
There are several forms for this model. One is to assign unique
HNP to a MN and configure address for every interface of MN;
another one is to allow some HNPs to be shared across different
interfaces belonging to a MN; a third one is to configure the same
address on every interface of a MN to emulate HoA of MIPv6.
Despite varieties of this model, the primary feature of it is that
the address of an interface has prefix in common with others and
thus different MAGs are able to add general routing table entry
for different interface addresses of one MN.
However, this model causes problems for routing of LMA and MAG. As
for conventional PMIPv6, prefix-based routing of LMA and MAG works
well to forward packet for multihoming MN because prefixes of
multiple interfaces are different from each other but this no
longer work in Single HNP Model for prefix matching comes to
ambiguous result. On the other hand, address-based routing is an
alternative to prefix-based routing but it leads to troubles that
are similar to problems of Multiple HNP Model. Yet, with the
combination of prefix-based routing and address-based routing,
Single HNP Model is able to provide a valid platform for SMA
support, which will be described in the following sections.
4. PMIPv6 based on Single HNP Model
This section describes a modified PMIPv6 system based on Single
HNP Model. The PMIPv6 system SHOULD support multihoming and be
able to forward a packet to a proper interface of MN based on the
destination address. Moreover, it SHOULD support SMA function with
the aid of routing rules management and flow-based routing
extension.
4.1. HNP Allocation and Address Configuration
The system is based on Single HNP Model so the same HNP is
assigned to different interfaces of one MN. Yet, different HNPs
MAY be assigned to different interfaces as that of conventional
PMIPv6. However, for interfaces that are preparing for SMA usage,
shared HNP SHOULD be assigned to them.
Receiving HNP, MN SHOULD configure different addresses for
different interfaces even if they share the same HNP. Although
configuring the same address on different address emulates the HoA
of MIPv6 to some degree, duplicated IPv6 global addresses on
different physical interfaces might result in troubles such as
address collision and some systems does not allow such operation.
However, using the same prefix to configure different addresses is
well supported so this approach is feasible.
Cui, et al. Expires April 18, 2010 [Page 6]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
4.2. Routing of LMA and MAG
LMA SHOULD add address-based routing table entries for each access
interface that connects to the PMIPv6 domain. MAG SHOULD add both
address-based and prefix-based routing table entries for each
access interface that connects to the MAG itself.
Address-based routing table entries of LMA and MAG ensure that
packets can be routed to the interface with the destination
address. The longest prefix matching of address-based routing make
address-based entries selected to get the outgoing interface and
next hop for each packet. On the other hand, prefix-based entries
of MAG are used for simultaneous usage support and will come into
handy in SMA function.
To set up address-based entries, LMA and MAG SHOULD be aware of
the addresses of access interface, which is different from
original PMIPv6 for the prefix is enough to identify a routing
path in Multiple HNP Model. This can be achieved by using Neighbor
Discovery of IPv6. Since MN will send Neighbor Advertisement after
configuring address on an interface, MAG can get the address of
the access interface by receiving such messages. After that, MAG
SHOULD inform LMA of the address. Thus, additional signaling is
required to support address-based routing in Single HNP Model.
Figure 2 shows the extended signaling call flow of MN attachment,
in which extra PBU and PBA are added to transmit the address of
access interface.
Cui, et al. Expires April 18, 2010 [Page 7]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) |
| | |
|--- Rtr Sol --------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | (Allocate HNP, Setup BCE & Tunnel)
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| (Set Up Tunnel) |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | |
|----- Neigh Adv ----->| |
| Accept NA |
| (Set Up Routing) |
| | |
| |--- PBU ------------->|
| | (Carrying address) |
| | |
| | Accept PBU
| | (Set Up Routing)
| | |
| |<------------- PBA ---|
| | |
Figure 2 MN Attachment - Extended Signaling Call Flow
5. SMA Operations
5.1. Registration of Routing Rules
A Routing Rule is a rule which specifies that traffic with certain
characteristic is to be handled in a certain manner. Its main
application is to bind a flow to a certain path. A Path Identifier
Cui, et al. Expires April 18, 2010 [Page 8]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
(PID) is used to identify a path between a multihoming MN and its
peers [2]. For MIPv6, the PID is identical to the Binding
Identifier (BID) [6]. In PMIPv6, there is no BID for bindings but
a Link-layer Identifier (LL-ID) is generated for each access
interface and it can be used to identify a path.
Routing Rules can be generated by either MN or LMA and should be
transmitted to the other side by generator. The transmission of
Routing Rules can be achieved by extended ICMP messages and
mobility signaling defined in [3]. At LMA, Routing Rules are
stored in the Binding Cache Entry for the LL-ID.
5.2. Data Transmission
This section will explain how traffic is sent from and to a MN
based on SMA function. Figure 3 shows a PMIPv6 multihoming
scenario with the following assumptions:
o MN has two active interfaces; IF1 connects to MAG1 and IF2
connects to MAG2.
o IF1 and IF2 share the same HNP but they have respective
addresses (ADDR1 and ADDR2).
o Both MAG1 and MAG2 have set up address-based and prefix-based
routing table entries for corresponding access interface.
o LMA has set up address-based routing table entries for IF1 and
IF2.
o A set of Routing Rules with associated LL-IDs have been created
and transmitted. They are stored in both MN and LMA.
List of Routing Rules:
Flow A <--> LL-ID1
Flow B <--> LL-ID2
o MN is communicating with a CN.
Cui, et al. Expires April 18, 2010 [Page 9]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
+----+ Binding Cache:
| CN | ==============
+----+ MN-ID, HNP, LL-ID1,
| Flow A <--> LL-ID1;
| MN-ID, HNP, LL-ID2,
| Flow B <--> LL-ID2;
|
+-------+ LMA RT (Routing Table):
| LMA | ==================
+-------+ ADDR1 -> MAG1
/ \ ADDR2 -> MAG2
/ \
/ \
/ \
MAG1 RT: +------+ +------+ MAG2 RT:
======== | MAG1 | | MAG2 | ========
ADDR1 -> MN +------+ +------+ ADDR2 -> MN
HNP -> MN \ / HNP -> MN
\ /
\ /
+-----------+
IF1: HNP1, ADDR1 | IF1 | IF2 | IF2: HNP, ADDR2
+-----+-----+
| MN |
+-----------+ Routing Rules:
==============
Flow A <--> LL-ID1
Flow B <--> LL-ID2
Figure 3 Scenario of SMA in PMIPv6
5.2.1. Sending Packet from MN
When MN sends a packet to CN, it will match the packet with
Routing Rules. If the packet matches one of the Routing Rules, the
outgoing interface is selected according to the LL-ID in the
Routing Rule. Otherwise, MN just looks up into routing table to
get the outgoing interface by address-based routing. With the
outgoing interface, MN transmits the packet on that interface. The
MAG receiving the packet tunnels the packet to LMA. LMA
decapsulates the packet and routes it towards CN.
5.2.2. Sending Packet to MN
When LMA receives a packet from CN, it will search the Binding
Cache for entries with HNP matches the destination address of the
packet. Then it will check whether the packet matches one of the
Routing Rules belong to those Binding Cache entries.
Cui, et al. Expires April 18, 2010 [Page 10]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
If the packet matches one of the Routing Rules, the tunnel
interface identifier of the corresponding binding cache is
selected and LMA will use that tunnel to forward packet towards
MAG. When MAG receive the packet, it decapsulates the packet and
performs address-based routing to forward the packet to MN. If the
address of access interface connecting to the MAG is not the same
as the destination address of the packet, MAG can still route it
based on the prefix-based routing table entry for ADDR1 and ADDR2
share the same prefix; if the two addresses are the same, MAG will
route it based on the address-based entry: issues mentioned in
Section 3.1 no longer troubles.
Otherwise, if none of the Routing Rules is matched, LMA and MAG
will just perform address-based routing. The address-based routing
table entries set up in the registration procedure are enough to
help to route the packet to MN.
However, a problem arises when MN receives the packet. Although
network side manages to route the packet to one of the interfaces
of MN, MN has to be able to receive a packet aiming at one
interface from another interface. Otherwise, when the destination
address of the packet does not match the address of receiving
interface, the packet would be discarded. Yet, weak End System
Model, defined in [7] and supported by most of current systems,
allows MN to do so. Therefore, MN is able to receive the packet as
long as network side forwards the packet properly.
5.3. Vertical Handoff
In SMA, moving flows across running interfaces could be achieved
by changing routing rules but it cannot handle the condition where
an interface disconnect from the network. For example, MN in
Figure 3 starts a flow on IF1 with ADDR1. If IF1 disconnect from
the network, the address configured on it is also gone. Thus, MN
cannot receive the existing flow any longer even if network side
route the flow to IF2. To solve the problem, additional mechanism
is need to perform vertical handoff, i.e. the handoff between
different interfaces.
Both network side and MN are involved in vertical handoff. First,
network side SHOULD be aware of the handoff event so as to launch
a new proxy registration and modify routing entries. Second, MN
SHOULD be able to configure ADDR1 on IF2 to receive the existing
flow.
As for the network side, although Handoff Indicator Option is
defined in PMIPv6 [1] to implement such a handoff, no mechanism is
designed for MAG to detect handoff event so it cannot set the
value of the option properly. This document suggests that MN
notify MAG of handoff event since only MN itself is aware of
whether it would like to perform a handoff to move existing flow
Cui, et al. Expires April 18, 2010 [Page 11]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
to IF2 or it just want to terminate IF1 as well as the flow on it.
The notification could be done by sending an extended RS, just
like that defined in [8], via IF2. After receiving the request,
MAG2 will perform a new registration for ADDR1. Since IF1 and IF2
shares the same HNP, MAG and HNP just need to change their
address-based routing entries as well as update binding cache and
binding update list. When MN receives RA, it SHOULD be configure
ADDR1 on IF2 so address configuration mechanism of MN need to be
modified to meet such requirement. How to extend MN to support
extended RS and the modified address configuration mechanism is
out of scope of this document. Figure 4 shows the signaling call
flow of vertical handoff. Notice that since LMA has already got
ADDR1 and it could inform MAG2 of ADDR1 in PBA, it is not
necessary for MAG2 to get the address by listening for Neighbor
Advertisement.
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
Launch V. Handoff | |
| | |
| | |
|--Extended Rtr Sol -->| |
| (V. Handoff Req.) | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | |
| | |
| |<------------- PBA ---|
| | (Carrying Address) |
| | |
| Accept PBA |
| | |
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | |
Figure 4 Vertical Handoff - Signaling Call Flow
After the handoff operation, LMA and MAG are able to forward the
existing flow to IF2 and MN is also able to receive the flow via
IF2 for ADDR1 is configured on MN again.
Cui, et al. Expires April 18, 2010 [Page 12]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
6. Conclusion
This document describes a SMA solution for PMIPv6 based on Single
HNP Model. The protocol performs flow-based routing based on
Routing Rules to bind both inbound and outbound flow to a
specified path while it performs address-based routing for packets
that do not match any Routing Rules. Extra mobility signaling call
is added to set up address-based routing. Both LMA and MAG are
extended to be able to generate Routing Rules, transmit them and
route packets according to them; however, the extension on MN is
limited to SMA function and mobility management is still done by
network side, which follows the idea of PMIPv6.
7. Security Considerations
This document does not introduce any new security concerns on top
of what is described in Security Considerations section of [1].
8. IANA Considerations
This document does not request any assignments from IANA.
9. References
9.1. Normative References
[1] K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy
Mobile IPv6", RFC5213, August 2008.
9.2. Informative References
[2] C. Larsson, M. Eriksson, K. Mitsuya, K. Tasaka and R. Kuntz,
"Flow Distribution Rule Language for Multi-Access Nodes",
draft-larsson-mext-flow-distribution-rules-01, July 2008.
[3] C. Larsson, M. Eriksson and P. Arvidsson, "Simultaneous
Multi-Access and Flow Mobility Support for PMIPv6", draft-
larsson-netext-pmipv6-sma-flow-mobility-00, March 2009.
[4] M. Jeyatharan, C. Ng, V. Devarapalli and J. Hirano,
"Multiple Interfaced Mobile Nodes in NetLMM", draft-
jeyatharan-netlmm-multi-interface-ps-03, October 2008.
[5] M. Jeyatharan and C. Ng, "Multihoming Problem Statement in
NetLMM", draft-jeyatharan-netext-multihoming-ps-01, March
2009.
[6] M. Eriksson, C. Larsson and R. Kuntz, "Mobile IPv6 Flow
Routing over Multiple Care-of Addresses", draft-eriksson-
mext-mipv6-routing-rules-00, June 2008.
Cui, et al. Expires April 18, 2010 [Page 13]
Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009
[7] R. Braden, "Requirements for Internet Hosts -- Communication
Layers", RFC 1122, October 1989.
[8] T. Savolainen, D. Premec, "Inter-technology handover in
PMIPv6 domain", draft-savolainen-netext-intertech-handover-
00, July 2009.
10. Acknowledgments
The authors would like to thank Conny Larsson for his advice and
the discussion on the topic.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Yong Cui
Tsinghua University
Tsinghua University FIT Building 4-104
Beijing 100084
P.R.China
Email: cuiyong@tsinghua.edu.cn
Hongyi Wang
Tsinghua University
Tsinghua University FIT Building 4-103
Beijing 100084
P.R.China
Email: whynpc@gmail.com
Tianze Ma
Tsinghua University
Tsinghua University FIT Building 4-104
Beijing 100084
P.R.China
Email: frank0208@gmail.com
Cui, et al. Expires April 18, 2010 [Page 14]