One document matched: draft-bernardos-mif-pmip-00.txt
NETEXT Working Group C. Bernardos
Internet-Draft UC3M
Intended status: Experimental T. Melia
Expires: January 4, 2010 Alcatel-Lucent Bell Labs
P. Seite
France Telecom
July 3, 2009
Multihoming extensions for Proxy Mobile IPv6
draft-bernardos-mif-pmip-00
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 January 4, 2010.
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.
Bernardos, et al. Expires January 4, 2010 [Page 1]
Internet-Draft PMIPv6 multihoming July 2009
Abstract
Netlmm WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables
mobile devices to connect to a PMIPv6 domain and roam across gateways
without changing the IP address. PMIPv6 also provides limited multi-
homing support to multi-mode mobile devices. Recently Netext WG is
being chartered to work on optimizations for PMIPv6. While multi-
homing item has been proposed to be part of the approved charter,
discussions showed there are still many controversial issues to be
addressed (i.e. the no-host modification theorem). This document,
leveraging parallel activities in the MIF WG, explores solutions for
the multi-homing use case aiming at helping Netext community where
possible.
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].
Bernardos, et al. Expires January 4, 2010 [Page 2]
Internet-Draft PMIPv6 multihoming July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. MIF scope and PMIPv6 . . . . . . . . . . . . . . . . . . . . . 5
3. A use case . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Considerations on feasibility. Approach overview . . . . . . . 7
4.1. MN considerations . . . . . . . . . . . . . . . . . . . . 8
4.2. LMA considerations . . . . . . . . . . . . . . . . . . . . 8
4.3. MAG considerations . . . . . . . . . . . . . . . . . . . . 9
4.4. Downlink (DL) and Uplink (UL) considerations . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Bernardos, et al. Expires January 4, 2010 [Page 3]
Internet-Draft PMIPv6 multihoming July 2009
1. Introduction
Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [RFC5213], provides
network based mobility management to hosts connecting to a PMIPv6
domain. PMIPv6 introduces two new functional entities, the Local
Mobility Anchor (LMA) and the Mobility Access Gateway (MAG). The MAG
is the first layer three hop detecting Mobile Node (MN) attachment
and providing IP connectivity. The LMA is the entity assigning one
or more Home Network Prefixes (HNPs) to the MN and is the topological
anchor for all traffic from/to the MN.
PMIPv6 allows an MN to connect to the same PMIPv6 domain through
different interfaces. ID
[I-D.devarapalli-netext-multi-interface-support] identifies at least
three possible scenarios, namely i) unique prefix per interface, ii)
same prefix but different global addresses per interface, iii) shared
address across multiple interfaces. The ID further describes issues
associated with each scenario. The first two scenarios are similar,
and bring similar issues, whereas the third one is more complex to
tackle, since it requires to deal with the sharing of the same IP
address across different interfaces. This document focuses on the
two first scenarios, as depicted in Figure 1.
LMA Binding Cache
+----+ -----------------
|LMA | MN:if1 [prefix1 or addr1] --> MAG1
+----+ MN:if2 [prefix2 or addr1] --> MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| if1 if2 |
+------[MN]------+
Figure 1: Unique prefix and Unique address per Interface scenarios
In parallel to this, the Multiple Interfaces (MIF) WG has been
chartered to describe host issues upon attachment to multiple
networks and document existing practice. This work has been
triggered based on the fact that many hosts currently have the
Bernardos, et al. Expires January 4, 2010 [Page 4]
Internet-Draft PMIPv6 multihoming July 2009
ability to attach to multiple networks simultaneously, and that
implies benefits (e.g., enables load balancing, improved
connectivity, higher throughput and better reliability, etc.), but
also brings some operation issues (e.g., default router selection,
address selection, DNS server selection, choice of interface for
packet transmission, the treatment of configuration information
received from the various networks, etc.). Configuration decisions
about how to deal with the different information from each of the
interface might have a very strong impact on the connectivity
experienced by a MIF node.
In the context of PMIPv6, current specification [RFC5213] does not
address the case of a MIF node attaching to a PMIPv6 domain. We
argue it is important to enable PMIPv6 to bring MIF nodes the
advantages related to the simultaneous use of multiple interfaces.
Moreover a MIF node could be seen as a not-modified host implementing
the right technology for multi-interface handling.
2. MIF scope and PMIPv6
Current scope of MIF WG only covers the issues of host attaching to
multiple networks. The WG is focused on documenting the system level
effects to host IP stacks and identification of gaps between the
existing IETF recommendations and existing practice, both for IPv4
and IPv6.
While the MIF WG is not addressing any (neither flow nor host nor
network) mobility, a MIF node might find itself connected to a PMIPv6
domain. PMIPv6 should be extended to efficiently support MIF nodes
attaching to a PMIPv6 domain, enabling features such as the ones
identified in [I-D.jeyatharan-netext-multihoming-ps], e.g., dynamic
mobility sessions between different interfaces, allowing traffic to
be forwarded to any of the interfaces of a MIF node, not only to the
one configured with the destination prefix/address of that traffic).
3. A use case
This section describes a simple use case of a MIF node in a PMIPv6
domain, as an example of a situation where PMIPv6 needs to be
extended.
Bernardos, et al. Expires January 4, 2010 [Page 5]
Internet-Draft PMIPv6 multihoming July 2009
+-----+
| CN1 |
+-----+
| LMA Binding Cache
| =====================
| MN:if1, pref1, MAG1
+-----+ +-----+ :if2, pref2, MAG2
| CN2 |--------| LMA |
+-----+ +-----+
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| if1 if2 |
+-------[MN]------+
(WLAN) (3G)
Figure 2: Use case
Figure 2 shows a potential use case of interest involving an MIF
mobile node attached to a PMIPv6 domain. The MN is attached to MAG1
through its WLAN interface (if1), and to MAG2 through its 3G
interface (if2). Lets consider the case in which each interface has
been assigned a different prefix by the LMA. Two different mobility
bindings are created in the LMA referring to the MN. In this
scenario, if the MN decides to move if1 from MAG1 to a different MAG
of the same domain, the PMIPv6 support would take care of ensuring
that the same prefix (pref1) is assigned at the new MAG (we assume
that there is an L2 identifier for if1 that the new MAG can include
in the PBU).
Lets assume for the sake of this example that the MN starts a
communication with CN1, using as source IPv6 address (pref1::if1) the
one assigned to its WLAN interface (if1), and that it also starts a
different communication with CN2, using as source IPv6 address
(pref2::if2) the one assigned to its 3G interface (if2). In this
scenario, it would be useful to enable the MN be able to receive
traffic addressed to pref1::if1 via if2 and vice versa. However,
current PMIPv6 specification does not support this. Analogously, it
would be also useful to allow the MN send traffic with source address
Bernardos, et al. Expires January 4, 2010 [Page 6]
Internet-Draft PMIPv6 multihoming July 2009
pref1::if2 through if2 and vice versa.
We argue in the next section that PMIPv6 could benefit from MIF
outcomes to support the previous scenario while limiting impact on
the LMA and MAG operation.
4. Considerations on feasibility. Approach overview
We analyse in the next sections the feasibility of the scenario
presented in Section 3, by identifying the requirements and changes
that would be needed in PMIPv6 to support it. In this version of the
document we do not specify with all the required details the
solution, but rather concentrate on the concept, with the goal of
triggering the discussion within MIF and NETEXT WGs.
Figure 3 shows in a glimpse the extensions to PMIPv6 required to
support the MIF example scenario shown in Section 3.
+-----+
| CN1 |
+-----+
| LMA Binding Cache LMA policy/routing table
| ===================== ============================
| MN:if1, pref1, MAG1 flow1(CN1,MN[pref1])->MAG1
+-----+ +-----+ :if2, pref2, MAG2 flow2(CN1,MN[pref2])->MAG1
| CN2 |-----| LMA | ...
+-----+ +-----+ flowN(CN2,MN[pref2])->MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG2 routing table
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref2::/64 directly connected
| | pref1::if1 pref2::if2
| |
| if1 if2 |
+-------[MN]------+ MN implements the weak host model
(WLAN) (3G)
Figure 3: Solution overview
Bernardos, et al. Expires January 4, 2010 [Page 7]
Internet-Draft PMIPv6 multihoming July 2009
4.1. MN considerations
In order to support the reception of traffic addressed to pref1::if1
at the interface if2, the MN MUST follow the Weak host model
[RFC1122], [I-D.thaler-ip-model-evolution]. This model does not
limit traffic reception at a host only to IP packets whose
destination address matches the IP address assigned to the interface
receiving the packets, but allows to receive and process packets
whose IP destination address corresponds to that of any of the local
interfaces of the host.
By implementing the Weak host model, the MN in Figure 3 would be able
to process traffic addressed to any of its IP addresses (i.e.,
pref1::if1 and pref2::if2), no matter to which interface that traffic
arrives to.
We have performed some tests with different operating systems, and
the results show that both Linux (tested with Linux-2.6.26) and Mac
OS X (tested with Leopard) implements the Weak host model for both
IPv4 and IPv6 traffic. We have not performed tests with Windows, but
some results have been reported in [I-D.mrw-mif-current-practices].
It should be noted that Windows XP and Windows Server 2003 use the
weak host model for sends and receives for all IPv4 interfaces and
the strong host model for sends and receives for all IPv6 interfaces.
This behavior cannot be modified. The Next Generation TCP/IP stack
in Windows Vista and Windows Server 2008 supports strong host sends
and receives for both IPv4 and IPv6 by default on all interfaces.
The stack can be configured to use weak host model.
Generally it should be possible to enable automatic configuration of
the weak model during network attachment/entry according to policies
configured in the operator's network. Signaling exchanged between
the MAG and the LMA (PUB, PBA) needs to be extended to configure the
MN (via RS/RA or DHCP) to use the weak host model on a specific
interface. As an example according to RFC 5175 [RFC5175] a bit can
be assigned in the RA message indicating such option. Alternatively,
the access provider may decide to configure the MAGs to advertise the
MN for weak model configuration.
4.2. LMA considerations
The LMA MUST be able to identify all the mobility bindings at its BC
that refer to the same MN, using the MN-identifier. The LMA SHOULD
have an additional policy/routing table. This table is used by the
LMA to store and look up information about how to route packets to a
certain MN. With current PMIPv6 specification, the LMA decides on
the next hop towards a particular MN based only on the destination
prefix (that would result on an outgoing tunnel interface to reach
Bernardos, et al. Expires January 4, 2010 [Page 8]
Internet-Draft PMIPv6 multihoming July 2009
the MAG where that prefix is currently reachable). In order to allow
the LMA to dynamically decide which is the best path for a certain
traffic to reach the MN, a policy/routing table SHOULD be used. By
using this table, the LMA would be able to send different flows
addressed to the same destination IP address (e.g. pref1::if1) via
different MAGs.
4.3. MAG considerations
The MAG MUST support routing packets addressed to MNs locally
attached to the MAG, but using a destination address that is not on-
link. In order to do that, the MAG SHOULD be informed by the LMA
about the set of IP addresses that the MN has acquired from the
PMIPv6 domain, so the MAG can add the required entries on its routing
table. The PBA MAY be extended to include such information.
4.4. Downlink (DL) and Uplink (UL) considerations
The extensions outlined in this document would allow an MN to
simultaneously receive traffic through all of its interfaces that are
attached to the same PMIPv6 domain. Enabling such a feature in the
Downlink (DL) makes sense when several access networks are available
at the same time, as for example in heterogeneous PMIPv6 domains
where several access technologies exhibiting different DL capacities
are found (e.g., WLAN and 3G).
Enabling the feature on the Uplink (UL) is also possible. Enabling
the network (i.e., the LMA) to have the control on which MN's
outgoing interface it used for a certain flow requires changes on the
MN side, as well as signalling on the MN-AR interface. Nevertheless,
if the decision is on the MN side, this might be easily supported by
the solution outlined in this document, by properly configuring the
routing and ingress filtering at the MAGs.
The mapping of a flow to an interface may be driven by the terminal,
the LMA or both:
1. driven by the terminal: the terminal establishes the policy and
selects the interface to send packets. The LMA must be aware of
the flow/interface mapping policy to keep consistency in routing
(the terminal would expect receiving traffic on a specific
interface). So the terminal may provide its policy to the LMA.
2. driven by the LMA: the LMA have the control on which MN's
outgoing interface is used for a certain flow. In such a case
the MN's routing table is updated according to the policy which
must be provided to the MN by the LMA.
Bernardos, et al. Expires January 4, 2010 [Page 9]
Internet-Draft PMIPv6 multihoming July 2009
3. MN driven but assisted by the LMA: the terminal controls the
mapping of the flows to the possible interfaces. However the LMA
provides some default policies which can be updated by the MN.
The policies must be exchanged in both directions (from LMA to MN
and vice versa).
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
None.
7. Acknowledgements
The research of Carlos J. Bernardos leading to these results has
received funding from the European Community's Seventh Framework
Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN
project).
8. References
8.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement
Flags Option", RFC 5175, March 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[I-D.devarapalli-netext-multi-interface-support]
Devarapalli, V., Kant, N., Lim, H., and C. Vogt, "Multiple
Interface Support with Proxy Mobile IPv6",
draft-devarapalli-netext-multi-interface-support-00 (work
in progress), March 2009.
Bernardos, et al. Expires January 4, 2010 [Page 10]
Internet-Draft PMIPv6 multihoming July 2009
[I-D.jeyatharan-netext-multihoming-ps]
Jeyatharan, M. and C. Ng, "Multihoming Problem Statement
in NetLMM", draft-jeyatharan-netext-multihoming-ps-01
(work in progress), March 2009.
[I-D.mrw-mif-current-practices]
Wasserman, M., "Current Practices for Multiple Interface
Hosts", draft-mrw-mif-current-practices-02 (work in
progress), March 2009.
[I-D.thaler-ip-model-evolution]
Thaler, D., "Evolution of the IP Model",
draft-thaler-ip-model-evolution-01 (work in progress),
July 2008.
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Telemaco Melia
Alcatel-Lucent Bell Labs
Email: Telemaco.Melia@alcatel-lucent.com
Pierrick Seite
France Telecom
Email: pierrick.seite@orange-ftgroup.com
Bernardos, et al. Expires January 4, 2010 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:34:59 |