One document matched: draft-jeyatharan-netlmm-multi-interface-ps-00.txt
NetLMM Working Group M. Jeyatharan
Internet-Draft C. Ng
Expires: March 4, 2008 J. Hirano
Panasonic
September 2007
Multiple Interfaced Mobile Nodes in NetLMM
draft-jeyatharan-netlmm-multi-interface-ps-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 March 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Currently, Proxy Mobile IPv6 (PMIPv6) only supports mobile node (MN)
with single interface roaming in the PMIPv6 domain. This memo
explores possible issues that may surface when considering MN with
multiple interfaces.
Jeyatharan, et al. Expires March 4, 2008 [Page 1]
Internet-Draft Multiple Interfaces in NetLMM September 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multiple Interfaces Support Model in PMIP . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 6
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 7
Appendix A. Multihoming Issues in different PMIP Single LMA
Scenarios . . . . . . . . . . . . . . . . . . . . . . 7
Appendix B. Multihoming Issues in Multiple LMA Scenario . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Jeyatharan, et al. Expires March 4, 2008 [Page 2]
Internet-Draft Multiple Interfaces in NetLMM September 2007
1. Introduction
Proxy Mobile IPv6 (PMIPv6) is a network based local mobility
management protocol that provides local mobility support to IPv6
hosts and MIPv6 hosts. Details of protocol operation and related
terminologies are given in [1]. Nevertheless, the PMIPv6 protocol as
outlined in [1] was designed with single-interface mobile node in
mind and thus lacks multihoming support functionality.
In this memo we specifically look at host multihoming and defer
roaming mobile router multihoming support in PMIPv6 for future
analysis. Currently, in PMIPv6 domain as disclosed in [1], there is
only a single PMIPv6 prefix (or more correctly per-MN unique prefix)
that is advertised for each MN and thus the problem analysis in this
memo will be mostly confined to host multihoming from the perspective
of explicit multiple interfaces. If the PMIPv6 domain has multiple
local mobility anchors (LMAs), and the MAGs are connected to multiple
LMAs, then, multiple local home prefixes may be received by the MN
and it may configure multiple addresses for the same interface. This
memo briefly looks at multihoming issue where multiple prefixes are
processed by a single interface of MN in Appendix B.
2. Multiple Interfaces Support Model in PMIP
When a node with multiple interfaces is roaming in a PMIP domain,
there are various benefits it can enjoy if the PMIP domain allows
more than one interfaces to be used simultaneously. Such benefits
have been described elsewhere, such as in [2], and are thus omitted
in this document. It should be noted that some benefits could be
enjoyed by the PMIP domain as well. For instance, when the LMA
receives a packet destined for a multiple interfaced MN, the LMA may
be able to choose among multiple routes to better utilize the network
resources of the PMIP domain or to avoid congested region of the PMIP
domain.
There are two main ways multiple interfaces support can be provided
by the PMIP domain. The first way is to offer the MN different home
network prefixes for each of MN's interfaces. The second way is to
offer the MN the same home network prefix.
o Different Home Network Prefix for Each Interface
In this case, each interface of the MN is allocated a unique Home
Network Prefix. If the MN is a IPv6 host using SHIM6 (Site
Multihoming by IPv6 Intermediation) [3] or SCTP (Stream Control
Transport Protocol) [4] or MONAMI6 capable mobile node [5], then
the MN can continue to enjoy multihoming benefits. However, the
Jeyatharan, et al. Expires March 4, 2008 [Page 3]
Internet-Draft Multiple Interfaces in NetLMM September 2007
LMA will not be able to route packets destined to one of the MN's
address configured from one Home Network Prefix assigned to one
interface to another of MN's interfaces, since the addresses
configured on these interfaces are from different prefixes.
To use this model, the MN may have to generate different NAI for
different interfaces or MAGs may need to generate interface
identifier based on some hint from the MN about attachment via a
certain interface. This is necessary since different home network
prefixes must be allocated to different interfaces. Thus, for
practical purposes, this model can be treated as multiple MNs
having one interface each. As such, we do not forsee any other
issues supporting this model of operation. In addition, this
model requires MN to have additional functionalities to enjoy the
benefits of multihoming, and the LMA cannot choose among different
paths to deliver a packet to a multi-interfaced MN. On top of
that, this model also unnecessarily consume network resources (a
MN having multiple unqiue prefixes). Hence the rest of this
document will concentrate on the second model unless explicitly
stated otherwise.
o Same Home Network Prefix for All Interfaces
In this case, each interface will receive the same Home Network
Prefix. In this scenario, MN should accept packets received by
any interface as long as the destination address matches the Home
Network Prefix regardless of the actual address configured (or
assigned) for that interface. This will allow the LMA to choose
from all available routes when forwarding packets to the MN.
There is no need for the MN to run separate multihoming enabling
protocols (such as SHIM6, SCTP, MONAMI6 extension) to enjoy the
benefits of multihoming.
3. Problem Statement
We next explore into whether the current PMIP protocol is capable of
supporting multiple interfaced MN. Figure 1 shows a multiple
interfaced MN, which is simultaneously attached to a PMIPv6 network
via both its interfaces.
Jeyatharan, et al. Expires March 4, 2008 [Page 4]
Internet-Draft Multiple Interfaces in NetLMM September 2007
+-------------+-----------+--------+
| Home Prefix | CoA | NAI |
+-----+ +-------------+-----------+--------+
| LMA | | MN.Prefix | MAG1.Addr | MN.NAI | -> old
+--+--+ | MN.Prefix | MAG2.Addr | MN.NAI | -> new
| +-------------+-----------+--------+
|
+--------------------------+
| |
| Proxy Mobile IP Domain |
| |
+--------------------------+
| |
MAG2 Address | | MAG1 Address
(MN.If2 proxy CoA) | | (MN.If1 proxy CoA)
+------+ +------+
| MAG2 | | MAG1 |
+------+ +------+
\ /
If2 \ / If1
+------+
| MN |
+------+
Figure 1: Attaching multiple interfaces in legacy PMIP domain
In Figure 1 it is assumed that the interface MN.If1 roams into the
PMIP domain first and gets attached to MAG1. The binding cache entry
(BCE) thus created is marked "old". When MN powers up the second
interface MN.If2, MAG2 will send a new PBU to the LMA, requesting to
bind the Home Network Prefix of MN to the proxy CoA of MAG2.Addr(see
2nd BCE marked "new"). As of the current operation of LMA as
specified in [1], LMA will overwrite the "old" BCE with the "new"
BCE. Now, let us look at the problem from the perspective of MN
operation. When a MN in the above figure sees a prefix via interface
1, it will either use statefull or stateless address
autoconfiguration methods to configure a global routable address for
interface 1. When MN.If2 attaches to MAG2 and receives the same
prefix as received via MN.If1, MN.If2 might end up configuring a
"tentative address" that is the same as the fully configured address
for MN.If1. Now, when MN does duplicate address detection (DAD) on
the above said "tentative address", DAD may fail due to same address
being configured in interface 1 and the MN may not configure a global
routable address for MN.If2 until it finds other ways of obtaining a
unique address for that interface 2. In such a circumstance, there
will not be any reachability at all to MN because the LMA has route
to MN.If2 while MN has no global reachability for MN.If2 and is only
attached via MN.If1. However such total IP disconnectivity will
Jeyatharan, et al. Expires March 4, 2008 [Page 5]
Internet-Draft Multiple Interfaces in NetLMM September 2007
sustain only for a short while until MAG1 sends a binding re-
registration message. Even after the binding re-registration, MN
will only use one interface and multi-homing benefits cannot be
enjoyed by MN. There could be an event where the MN configures
different addresses for each of its interfaces. This can happen when
stateless address autoconfiguartion yields different addresses to the
interfaces. Thus, in this differentr address scenario, MN will have
two home addresses in PMIP domain. In such a case, MN can attach to
PMIP via both its interfaces.
When MN does such simultaneous attachment via valid global routable
address assigned to all its interfaces, there is only one BCE entry
for MN at any one time, even though the MN has attached multiple
interfaces to the PMIP domain. The problem is not simply the
reduction of MN's multiple attachments into effectively a single
attachment. Packets may be lost as a result. For instance, when MN
sends a packet through the interface MN.If1, MAG1 will tunnel the
packet to LMA. Since the LMA can no longer locate a valid entry
where MAG1.Addr is the proxy CoA of MN's prefix, the LMA will discard
the packet. More elaborate multihoming problem description in
various scenarios of MN attachments will be discussed in Appendix A
and Appendix B.
4. IANA Considerations
This is an informational document and does not require any IANA
action.
5. Security Considerations
This document explores the problem of supporting mobile nodes with
multiple interfaces connecting to a single PMIPv6 domain. No
additional security threat is identified as of the writing of this
memo that is specific to multiple interfaces support.
6. References
6.1. Normative Reference
[1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-05
(work in progress), September 2007.
Jeyatharan, et al. Expires March 4, 2008 [Page 6]
Internet-Draft Multiple Interfaces in NetLMM September 2007
6.2. Informative Reference
[2] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
progress), July 2007.
[3] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-08 (work in
progress), April 2007.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-03 (work in progress), July 2007.
Appendix A. Multihoming Issues in different PMIP Single LMA Scenarios
In this section a brief description of multihoming problem in
different scenarios is discussed. Only scenarios which were not
highlighted previously is discussed here. Furthermore, in this
section it is assumed the MN an HA are Monami6 capable.
+-----+ BCE at LMA/HA
| HA/ | +---------+-------+-----+-----+
| LMA | |MN prefix| MN.CoA| NAI | BID |
+-----+ +---------+-------+-----+-----+
| | prefix |MAG1add| NAI | - |->deleted
+-----------+ | prefix |MAG2add| NAI | - |->deleted
| Home | | HoA |HomeCoA| NAI | BID1|->valid
| PMIPv6 | +---------+-------+-----+-----+
| domain |\
+-----------+ \
| \
+----+ +----+
MAG1 Address |MAG1| |MAG2| MAG2 Address
(MN.If1 proxy CoA) +----+ +----+ (MN.If2 proxy CoA)
\ /
HoA \If1 If2/ Home CoA
+--------+
| MN |
+--------+
Figure 2: Using multiple interfaces in home PMIPv6 domain
Jeyatharan, et al. Expires March 4, 2008 [Page 7]
Internet-Draft Multiple Interfaces in NetLMM September 2007
When the MN boots up in its home PMIPv6 network with both its
interfaces, it may either configure two home addresses (one for each
interface), or a single home address associated with one interface
(If1) and a care-of address for the other interface (If2). This
care-of address can be configured from the local home prefix obtained
from the PMIPv6 home domain. Such a configuration scenario is shown
in Figure 2.
It is assumed that the MN attaches to MAG1 with If1 before attaching
If2 to MAG2. The first entry in LMA's binding cache as shown in
Figure 2 created from the PBU sent by MAG1 would be overwritten by
the second entry created from the PBU sent by MAG1. Since MN
configures a care-of address from its home prefix (i.e. a Home CoA),
it then proceeds to send CMIP binding update to HA. As before, the
LMA/HA would wipe out the second entry, and create a third entry from
the CMIP binding. Thus, multihoming benefits cannot be obtained.
Further, LMA/HA may not have a route to Home CoA, since the bindings
of MN's prefix are removed. Thus, the MN may be rendered unreachable
by the use of multiple interfaces.
+-----+ BCE at LMA/HA
| HA/ | +---------+---------+-----+-----+
| LMA | |MN prefix| MN.CoA | NAI | BID |
+-----+ +---------+---------+-----+-----+
| | prefix | MAGaddr | NAI | - |->deleted
+----------------+ | HoA | CoA | NAI | BID1|->valid
| Home PMIP | +---------+---------+-----+-----+
| domain |
+----------------+
|
+-----+
| MAG | MAG Address
+-----+ (MN.If1 proxy CoA)
|
| +-----------+
| | foreign |
| | domain |
| +-----------+
| |
HoA | If1 |
+------+ If2 +-----+
| MN |-------------| AR |
+------+ CoA +-----+
Figure 3: Simultaneously at home and at foreign
Figure 3 shows another scenario where MN connects interface If2 to a
foreign domain while interface If1 is at home. MAG will send PBU to
Jeyatharan, et al. Expires March 4, 2008 [Page 8]
Internet-Draft Multiple Interfaces in NetLMM September 2007
the LMA/HA, resulting in the first entry in LMA/HA's binding cache as
shown in Figure 3. After the MN has configured a care-of address for
If2, it will send a CMIP binding to LMA/HA. Since there is no way
for the LMA/HA to know that this CMIP binding is coming from another
interface, it will replace the first entry in its binding cache with
the second entry. Thus, multihoming benefits are not available to
MN.
+------+ +----------------+
| HA |----| Internet |
+------+ +----------------+
|
BCE at HA | BCE at LMA
+-----+-----+-----+ | +----------+---------+-----+
| HoA | CoA | BID | +-------+ | MNprefix | MN.CoA | NAI |
+-----+-----+-----+ | LMA | +----------+---------+-----+
| HoA | CoA1| BID1| +-------+ | prefix | MAGAddr | NAI |
| HoA | CoA2| BID2| | +----------+---------+-----+
+-----+-----+-----+ |
+--------------+
| Foreign |
| PMIP |
| domain 1 |
+--------------+
|
+-----------+ +-----+
| Foreign | | MAG | MAG Address
| domain 2 | +-----+ (MN.If1 Proxy CoA)
+-----------+ |
| If1 | CoA1 (from PMIP prefix)
+----+ If2 +--------+
| AR |------------| MN |
+----+ CoA2 +--------+
Figure 4: Attaching to two different foreign domains
In Figure 4 MN is attached to a foreign PMIPv6 domain 1 via If1 and
attached to a foreign domain 2 via If2. The binding cache at LMA of
the foreign PMIPv6 domain is shown in Figure 4. After configuring
addresses on both If1 and If2, the MN will send binding updates to
its home agent HA. Being Monami6 capable, the MN will add BID
options for each of its bindings. Thus the binding cache at HA will
contains two entries, as shown in Figure 4. In this case, MN can
enjoy multioming benefits.
Jeyatharan, et al. Expires March 4, 2008 [Page 9]
Internet-Draft Multiple Interfaces in NetLMM September 2007
Appendix B. Multihoming Issues in Multiple LMA Scenario
If there are multiple LMAs in the same PMIPv6 network, then there is
a possibility that a MN sees multiple prefixes being received at the
same interface. In this section this scenario is briefly analyzed to
see whether multihoming issue is present. Again, it is assumed that
MN and HA have Monami6 functionality.
+-----+------------+------+
+----+ | HoA | CoA | BID |
| HA | +-----+------------+------+
+----+ | HoA |LMA1pref.CoA| BID1 |
| | HoA |LMA2pref.coA| BID2 |
+----------+--------+-----+ +------------+ +-----+------------+------+
| prefix | MN.CoA | NAI | | Internet |
+----------+--------+-----+ +------------+
| LMA1pref | MAGAddr| NAI | / \
+----------+--------+-----+ / \
+------+ +------+
| LMA1 | | LMA2 |
+------+ +------+
| | +----------+--------+-----+
+-----------------+ | prefix | MN.CoA | NAI |
| foreign | +----------+--------+-----+
| PMIPv6 | | LMA1pref | MAGAddr| NAI |
| domain | +----------+--------+-----+
+-----------------+
|
+-----+
| MAG |
+-----+
LMA1pref | LMA2pref
+-----+
| MN |
+-----+
Figure 5: PMIPv6 domain with multiple LMAs
Figure 5 shows a scenario where MN is attached to a foreign PMIPv6
domain with multiple LMAs. Here, MN may receive two per-MN unique
prefixes (LMA1pref and LMA2pref) and configure two care-of addresses
using these prefixes. As MN is Monami6 capable, it will assign
different BID for each of the care-of addresses when binding them to
its home address at its home agent HA. The binding caches of the
LMAs and the HA are shown in Figure 5. In this case, MN can enjoy
multioming benefits.
Jeyatharan, et al. Expires March 4, 2008 [Page 10]
Internet-Draft Multiple Interfaces in NetLMM September 2007
Authors' Addresses
Mohana Dahamayanthi Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Jun Hirano
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
Email: hirano.jun@jp.panasonic.com
Jeyatharan, et al. Expires March 4, 2008 [Page 11]
Internet-Draft Multiple Interfaces in NetLMM September 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jeyatharan, et al. Expires March 4, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:47 |