One document matched: draft-premec-netlmm-intertech-handover-00.txt
NETLMM Working Group D.Premec
Internet Draft Nokia Siemens Networks
Intended status: Informational T.Savolainen
Expires: October 2008 Nokia
April 26, 2008
Inter-technology handover in netlmm domain
draft-premec-netlmm-intertech-handover-00.txt
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.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
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 October 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Premec Expires October 26, 2008 [Page 1]
Internet-Draft PMIP6 inter-tech handover April 2008
Abstract
Proxy Mobile IPv6 specification [Gun2008] describes a network based
mobility management protocol which provides IP mobility service to a
host in a way which is transparent to the host itself. This document
analyses the scenario in which the MN equipped with multiple network
interfaces roams in a netlmm domain consisting of several access
networks. If the MN wants to preserve IP session continuity across
different network interfaces as it moves from one access network to
another it needs to be enhanced with a new, netlmm-specific
functionality.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Problem statement..............................................4
4. Possible solutions.............................................9
4.1. netlmm service availability...............................9
4.2. MN's enhancements for netlmmm ............................9
4.3. Movement of IP sessions across interfaces................11
5. Router Solicitation message extension.........................12
6. Mobile Node Operation.........................................13
7. Mobile Access Gateway Operation...............................14
8. LMA operation.................................................14
9. Other Considerations..........................................15
9.1. Support for IPv4.........................................15
9.1.1. Overlapping private address spaces..................15
9.1.2. IPv4 address configuration and indication of PMIP
support....................................................15
9.2. MTU size.................................................16
9.3. Zero physical interfaces available.......................16
10. Security Considerations......................................17
11. IANA Considerations..........................................17
12. Acknowledgments..............................................17
13. References...................................................17
Premec Expires October 26, 2008 [Page 2]
Internet-Draft PMIP6 inter-tech handover April 2008
13.1. Normative References....................................17
13.2. Informative References..................................18
Author's Addresses...............................................18
Intellectual Property Statement..................................19
Disclaimer of Validity...........................................19
1. Introduction
NETLMM working group develops a network based mobility management
protocol called Proxy Mobile IPv6 [Gun2008]. The goal of the Proxy
Mobile IPv6 protocol is to provide IP mobility service to hosts which
are not Mobile IP capable. One of the key objectives of the netlmm
protocol is that network based IP mobility service is provided in a
manner that is transparent to the hosts. According to base PMIP6
specification, an unmodified host can roam within a netlmm domain and
retain its IP address and IP session continuity as it moves within
the PMIP6 domain.
This document presents a scenario where the host with multiple
network interfaces attaches to the netlmm domain consisting of
multiple access networks. If the host wants to retain IP session
continuity as it handoffs from one access network to another, we show
that the host has to be enhanced with netlmm specific capabilities.
Section 3 presents a detailed discussion of the scenario and the
related issues. Section 4 analyses possible solutions. Section 5
shows changes for Router Solicitation message. Section 6, 7 and 8
describe operational changes to Mobile Node, Mobile Access Gateway,
and Local Mobility Anchor. Section 9 lists other considerations and
future research needs identified this far.
2. Terminology
General mobility related terminology is defined in [RFC3775].
Additional PMIP6 specific terminology can be found in [Gun2008].
netlmm domain
Network providing the network based IP mobility service as
defined in [Gun2008].
PMIP6
Proxy Mobile IPv6 protocol specified in [Gun2008].
Premec Expires October 26, 2008 [Page 3]
Internet-Draft PMIP6 inter-tech handover April 2008
3. Problem statement
According to the base PMIP6 specification [Gun2008], a netlmm domain
is defined as a network which provides network based IP mobility
service by deploying the PMIP6 protocol and where the security
association between MAGs and LMAs can be set up. Such broad
definition allows a netlmm domain to consist of several access
networks of different types. A host attaching to such netlmm domain
may have multiple network interface cards (WiFi, 3G, WiMAX, etc.),
one for each different radio access technology.
The basic premise of the netlmm protocol is that the host roaming in
a netlmm domain is provided with IP session continuity in a manner
transparent to the host. However, this is not true any more if the
host is equipped with multiple network interface cards and if the
netlmm domain comprises several access networks of different
technology types. This network configuration is illustrated by the
following figure:
+--------+
| HA/LMA |
+--------+
/ \
/ \
/ \
/ \
/ \
--------------/-----+ +-\--------------
/ ) ( \
RAN1 +------+ ) ( +------+ RAN2
| MAG1 | ) ( | MAG2 |
+------+ ) ( +------+
\ ) ( /
---------------\----+ +----/-----------
\ /
\ /
\ /
\ /
| |
+-|---|-+
|IF1 IF2|
| MN |
+-------+
Figure 1 netlmm domain with multiple access networks
Premec Expires October 26, 2008 [Page 4]
Internet-Draft PMIP6 inter-tech handover April 2008
In such scenario the host can handoff between the adjacent MAGs
located at the boundaries of different access networks. The scenario
analyzed here assumes that the host does not want to use both
interfaces simultaneously for independent IP sessions. Instead the
host wants to move its existing IP sessions from one interface to
another at time of its choosing.
We assume that the host first attaches to the netlmm domain via the
MAG1 located in the access network RAN1. As the host moves, it may
come into an area covered by the access network RAN2 and may decide
to attach to it. However, the attach decision does not necessarily
imply immediate interest of moving existing IP sessions from RAN1 to
RAN2. The attachment may be done only as an initial preparation for
faster future movement of IP sessions. The decision to switch IP
sessions to RAN2 is an implementation dependent and may be based on
the number of different reasons like for example deteriorating radio
signal quality from RAN1 or various policy reasons like price,
quality of service, available bandwidth, etc.
The following figure shows in more detail how the attachment
procedure to RAN2 will happen. Unmodified host is assumed and the
goal is to preserve host's IP session continuity.
Premec Expires October 26, 2008 [Page 5]
Internet-Draft PMIP6 inter-tech handover April 2008
MN MAG1 MAG2 LMA
IF1 IF2
| | | | |
1) |<-----L2 link------>|<==========PMIP tunnel===========>|
| | | | |
| | | | |
2) | |<---------L2 link---------------->| |
| | | | PBU |
3) | | | |--------------->|
| | | | |
| | | | PBAck |
4) | | | |<---------------|
| | | | |
5) | | | |<==PMIP tunnel=>|
| | | | |
| | RS | | |
6) | |--------------------------------->| |
| | | | |
| | MLD(JOIN) | | |
7) | |--------------------------------->| |
| | | | |
| | DAD(LLA) | | |
8) | |--------------------------------->| |
| | | | |
| | RA(HNP) | | |
9) | |<---------------------------------| |
| | | | |
| | DAD(HNP) | | |
10) | |--------------------------------->| |
| | | | |
| | | | |
| | | | |
Figure 2 Multihomed MN moving between different RANs
1. This step shows the MN is connected to MAG1 and there is a PMIP6
tunnel between MAG1 and the LMA
2. MN attaches to MAG2 through its second interface. Depending on the
access technology used in RAN2, it is possible that MN configures
different Interface Identifier for the second interface than what
is used in the first interface.
Premec Expires October 26, 2008 [Page 6]
Internet-Draft PMIP6 inter-tech handover April 2008
3. Triggered by the link establishment event the MAG2 sends the PBU
to the LMA. MAG2 indicates the access technology type in the PBU
and sets handoff indicator to the "handoff state unknown". The
legacy MN attaching to MAG2 will not be able to provide any hint
as to how the handoff indicator should be set.
4. LMA detects an existing binding of the MN. The binding contains an
access technology type that is different from the one received in
the PBU message. If the LMA wants to give MN a chance to move its
existing IP sessions to a new interface, it must send to the MAG2
the existing HNP from the MN's binding cache entry. If LMA returns
a different HNP, the MN will have to configure an address that is
different from the address configured on its interface to MAG1,
and will thus not be able to move its IP sessions from one
interface to another. For detailed description of rules how the
LMA selects a prefix consult [Gun2008] section 5.4.
5. This step shows the MAG2 to LMA tunnel is established. The LMA no
longer retains the tunnel to MAG1.
6. Triggered by the step 2, the MN sends a Router Solicitation
message.
7. Triggered by the step 2, the MN sends the MLD report message to
join the solicited node multicast group.
8. Triggered by the step 2, the MN autoconfigures a link-local
address and starts a DAD process.
9. Triggered by the step 4, MAG2 advertises the HNP to the MN.
10.MN autoconfigures the address based on the HNP received in the RA
message and the Interface Identifier selected for the interface.
Although the advertised prefix is the same on both interfaces, the
address autoconfigured by host on the interface facing the MAG2 is
either truly different, or considered logically different by the
host software, from the address configured on its interface
connected to MAG1. This is to comply with the basic rules of IP
networking: an IP address can not be assigned to more then one
interface. Some existing host implementations are less strict and
actually allow configuration of the same IP address to multiple
interfaces, but in that case consider IP addresses being
overlapping and logically different from each other, and thus do
not allow movement of sessions from one interface to another. The
host starts a DAD procedure for its newly configured address.
Premec Expires October 26, 2008 [Page 7]
Internet-Draft PMIP6 inter-tech handover April 2008
The precondition for the host to move IP sessions from one interface
to another is that it is able to configure the same IP address for
both interfaces and it considers the same IP address in multiple
interfaces actually being logically the same address (host supports
multihoming on different access technologies with single IP address).
The above steps show that unmodified legacy host will not be able to
move its IP sessions even if the same prefix is available in both
access networks.
In fact, there is a serious flaw resulting from the above message
sequence. The host still has connectivity to MAG1 and may still send
packets via the interface connected to MAG1. MAG1 will tunnel the
packets to the LMA, but the LMA will drop them as in its binding
cache entry the authorized tunnel source is now MAG2. Any packets the
MN transmits over MAG1 will be dropped by the network and no
indication will be sent to the MN. Because of this the baseline
document does not allow the LMA to return the same HNP to a new MAG
in a different access network unless the LMA is sure that the MN
intends to perform handover across interfaces.
LMA relies on the handoff indication to know that the MN is capable
of moving its IP session across interfaces. In case that the access
technology type in the PBU message is different from the one saved in
the binding cache entry, LMA will know that the MN attached to MAG2
over a different interface. In this case the LMA may return the same
HNP in the PBAck message only if the handoff indicator in the PBU
message indicates handoff between two different interfaces. It is the
responsibility of the MAG to provide the correct handoff indication,
but how does the MAG know? This document recommends that the MAG must
get this indication from the MN itself. Consequently, the MN that
wants to retain its IP address as it moves from one access network to
another in a netlmm domain must be enhanced with netlmm specific
functionality, and in particular it must be able to do the following:
o detect that it is located in a netlmm domain
o indicate to the MAG its support for moving of IP sessions across
interfaces
o support moving of IP session across interfaces
Premec Expires October 26, 2008 [Page 8]
Internet-Draft PMIP6 inter-tech handover April 2008
4. Possible solutions
This subsection introduces several different mechanisms that, when
put to work together, address the issue of moving the IP sessions
across interfaces.
4.1. netlmm service availability
The network can indicate to the MN that it is providing the netlmm
service in any of the following ways:
o Extension of Router Advertisement message
Router Advertisement message can be extended to carry the information
about the availability of the netlmm service. This is described in
more detail in [Dam2008]. Advantage of such IP-layer based mechanism
is that it is available irrespective of link-layer technology and
requires no support or modification of the underlying link-layer(s).
o Extensions of the link-layer
A link-layer technology used in a netlmm domain could be extended to
carry the indication of the availability of the netlmm service. This
approach enables the MN to learn the network's netlmm capability
during the link setup phase. On the other side, it requires changes
to the underlying link-layer technologies and is based on a tight
coupling between the IP and the link layer.
o Advertising the same prefix in different access networks
If the MN receives Router Advertisement messages over different
interfaces carrying the same prefix, it may take this as an
indication of the netlmm service availability in the network. This is
an implicit indication and is error prone because such solution can
not differentiate between the netlmm domain and multi-link subnets
[RFC4903]. Advantage is that it does not require any changes to the
messages.
This document recommends the mechanism based on the extension of
Router Advertisement message. This mechanism provides an explicit
indication, it is backwards compatible with legacy hosts and it is
independent of the link-layer technology.
4.2. MN's enhancements for netlmmm
When the MN roaming in a netlmm domain decides to move its IP
sessions from one access network to another, it needs a mechanism by
Premec Expires October 26, 2008 [Page 9]
Internet-Draft PMIP6 inter-tech handover April 2008
which it can inform the network about its intention to move its IP
sessions across interfaces. The MAG uses this indication from the MN
to fill in the Handoff Indicator option in the PBU message.
o Extension of Router Solicitation message
A Router Solicitation message can be extended with a new flag
indicating that the MN wants to move its IP session across
interfaces. Usage of Router Solicitation message requires that MAG
waits for a Router Solicitation message from the MN before it can
send a PBU message to the LMA with the correct handoff indicator.
This is different from the baseline spec [Gun2008] where it is
assumed that the sending of PBU message is triggered by the link
establishment event.
o Extensions of the link-layer
The underlying link-layer can be extended to carry the indication of
the MN's netlmm capability to the MAG. This solution introduces tight
coupling between the IP layer and the link-layer and requires changes
to link layer technologies used with the PMIP6 protocol.
o Same interface identifier across access networks
This approach is suggested in the [Lag2008]. The idea is that the MN
will use the same interface identifier in both access networks if it
wants to move its IP session across interfaces. A MAG in a new access
network is assumed to acquire the MN's interface identifier during
the link establishment phase through link specific mechanisms. A MAG
is also assumed to obtain an interface identifier that the MN was
using at a previous MAG and the access technology type through
context transfer between MAGs or some other unspecified mechanisms.
If access technology type is different and the interface identifier
is the same in both access networks than the new MAG should take that
as an indication of the MN's capability and intention to move its IP
sessions across interfaces. In this case the MAG would always set the
handoff indicator in the PBU message to the value "2: Handoff between
two different interfaces of the mobile node". This solution is partly
based on a link-layer as the MAG learns the MN's interface identifier
during the link layer establishment. Note that there are link layers
which do not allow for MAC address negotiation and where the MAC
address assigned to the device is authenticated by the certificate
and thus can not be changed. One example of such link layer is IEEE
802.16 defined in [IEEE802.16] and [IEEE802.16e].
This document recommends the mechanism based on the extension of
Router Solicitation message. This mechanism provides an explicit
Premec Expires October 26, 2008 [Page 10]
Internet-Draft PMIP6 inter-tech handover April 2008
indication, it is backwards compatible with legacy hosts, it is
independent of the link-layer technology, it allows arbitrarily long
temporal separation of access network attachment and session
movement, and does not require any changes to the already deployed
equipment.
4.3. Movement of IP sessions across interfaces
Some aspects of the procedure described here are internal to the MN
and as such they are implementation dependent and may be implemented
differently than shown here.
The MN initiates the PMIP6 handover across interfaces by sending a
Router Solicitation message with a flag indicating that it wants to
move its IP sessions across interfaces. The target access network to
which the IP sessions will be moved is the access network where the
Router Solicitation message was sent. The MAG SHOULD respond with the
Router Advertisement message containing netlmm specific extensions as
described in [Dam2008]. The MN SHOULD detect that it is in a netlmm
domain by looking for a N flag in a Flags Expansion option in a
Router Advertisement message. If during the initial network
attachment the MN detects that it is attaching to a netlmm domain, it
SHOULD instantiate a virtual interface and associate it with a
physical interface used to attach to the network. The address
configured using the HNP from the Router Advertisement message SHOULD
NOT be assigned to the physical interface used to attach to the
netlmm domain. Instead, it SHOULD be assigned to the virtual
interface. Any packets that the MN sends over this virtual interface
SHOULD be delivered to the network over the associated physical
interface. Any packets the MN receives over the physical interface
SHOULD be delivered to the IP layer over the associated virtual
interface.
When the MN attaches to the netlmm domain over its second interface,
it SHOULD send a Router Solicitation message over this interface. The
Router Solicitation message SHOULD include the indication that the MN
wants to move its IP sessions across interfaces, but if MN wants to
postpone movement of its IP sessions, it MAY leave this indication
out from initial Router Solicitation. If the Router Advertisement
message indicates that the network supports netlmm service and the
HNP advertised in the Router Advertisement message is the same as the
MN is using on its virtual interface, the MN SHOULD associate its
virtual interface with the newly configured physical interface. The
switch of the virtual interface's association to the newly configured
physical interface accomplishes the movement of IP sessions from one
access network to another, preserving the IP sessions.
Premec Expires October 26, 2008 [Page 11]
Internet-Draft PMIP6 inter-tech handover April 2008
After associating the virtual interface with the newly configured
physical interface, the MN MAY bring down the physical interface
previously associated with the virtual interface.
The MN may decide to remain attached at a link layer to both access
networks. In such case the MN can move its IP sessions back and forth
between the access networks without first performing a network entry
in the target access network. In order to initiate the switch of its
IP sessions to another access network, the MN SHALL send a Router
Solicitation message in the target access network and the flag
requesting the movement of IP sessions in the Router Solicitation
message SHALL be set.
5. Router Solicitation message extension
A new 'P' flag is added to the Router Solicitation message specified
in [RFC4861] indicating that the host supports netlmm specific
enhancement specified in this document.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3. P flag in the Router Solicitation
ICMP Fields:
Type 133
Code 0
Checksum The ICMP checksum. See [RFC4443]
C flag C bit is introduced in [Dam2008]. If it is set, it
indicates that the MN is capable of performing its own
mobility management.
Premec Expires October 26, 2008 [Page 12]
Internet-Draft PMIP6 inter-tech handover April 2008
P flag If this bit is set, it indicates that the MN supports
the netlmm specific enhancements specified in this
document. In particular, by setting this bit the
sending node indicates that it is both capable and
willing of moving its IP session across interfaces.
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
The MN implementing the P flag SHOULD support the N flag in a Router
Advertisement message as defined in [Dam2008].
Access routers and MAGs not supporting the P bit will ignore it as
specified in [RFC4861]. Hence there are no backward compatibility
issues.
6. Mobile Node Operation
When the mobile node wants to move its IP sessions from one interface
to another one, the mobile node SHALL send the Router Solicitation
message in the target access network with the P flag set. If the
Router Advertisement message received in response does not contain
the same HNP that the MN is already using for its IP sessions in the
current access network, then the target access network does not
support handovers across interfaces and the MN SHALL not move its IP
sessions to a target interface.
The P flag in a Router Advertisement message triggers the mobile node
to move its IP sessions from the previous access network to interface
attached to the target access network. Unless the MN wants to
initiate the PMIP6 handover it SHALL NOT set the P flag in a Router
Solicitation message.
If the MN already initiated the PMIP6 handover and the MN receives a
Router Advertisement message in a previous access network revoking
the HNP (prefix lifetime set to 0), the MN SHOULD NOT immediately
invalidate the addresses configured with the HNP. Instead, the MN
SHALL wait for a Router Advertisement from a target access network.
This situation is similar to what is described in chapter 9.3. If the
Router Advertisement from a target network contains the HNP with a
non-zero lifetime, the MN SHALL continue to use the addresses based
on HNP in the target access network.
Premec Expires October 26, 2008 [Page 13]
Internet-Draft PMIP6 inter-tech handover April 2008
7. Mobile Access Gateway Operation
When the mobile node attaches to a MAG, the MAG SHALL delay the
sending of an initial PBU message until it receives a Router
Solicitation message from the mobile node. If the P flag in the
received Router Solicitation message is not set, the MAG SHALL send
the PBU message as per [Gun2008].
When MAG receives a Router Solicitation message with a P flag set,
the MAG SHALL send a PBU message to the LMA setting the Handoff
indicator option to the value "2: Handoff between two different
interfaces of the mobile node".
In all other cases the MAG SHALL set the Handoff Indicator option as
described in the [Gun2008].
8. LMA operation
When the LMA receives a PBU message with a handoff option indicating
handover across interface, the LMA SHALL send a Binding Revocation
message to the previous MAG.
9. Other Considerations
9.1. Support for IPv4
The current version of this document is focused on IPv6 only and the
considerations for IPv4-enabled hosts are not in the scope. Future
versions of the document should be enhanced to include support for
IPv4.
9.1.1. Overlapping private address spaces
IPv4 hosts with multiple simultaneously used network interfaces have
had to be able to function even in situations where host has same
private IP address allocated for two or more network interfaces. This
has been implemented, for example, by binding applications to
interface, rather than to IPv4 address. Hosts of this kind are not
able to move IP sessions from one interface to another, even if they
are able to configure same IPv4 address to multiple interfaces.
Premec Expires October 26, 2008 [Page 14]
Internet-Draft PMIP6 inter-tech handover April 2008
Furthermore, due to overlapping address spaces, private IPv4 address
cannot be used to determine whether network is providing network
based mobility.
Network based mobility should utilize public IPv4 addresses, or there
should be indication that informs host of possibility to move IP
sessions even when private IP address spaces are used. Nevertheless,
hosts have to be modified to allow IP session movement from one
network interface to another.
9.1.2. IPv4 address configuration and indication of PMIP support
IPv6 addresses are always configured after link establishment, which
enables rather dynamic features as described in this document.
However, especially in cellular networks IPv4 addresses are often
configured during the link layer establishment procedures only, e.g.
with IPCP. In these kinds of networks host cannot utilize IP-layer
technologies to indicate support for network based mobility, before
IPv4 address allocation takes place in the network. Thus in these
kinds of networks host effectively cannot open second network
interface before it is actually willing to move, as just opening of a
RAN2 network interface can trigger MAG2 to update bindings in LMA,
and as not all of the current unmodified host implementations are
able to be able to move IP sessions from one interface to another,
ongoing IP sessions in RAN1 would be immediately disconnected.
In those network access technologies where IPv4 address is assigned
after link establishment, e.g. with DHCP, similar solutions as with
IPv6 may be possible (IPv4 Router Solicitation/Advertisement, or
DHCP-based). In technologies where IPv4 address is allocated right at
the link setup, link layer extensions seem to be inevitable.
Question: if a host asks during RAN2 link layer setup to be given the
same address it has in the RAN1, would that help MAG2 to determine
host is interested to move its sessions?
9.2. MTU size
Different physical interfaces can have different MTU size. Changes in
the MTU size MAY affect the existing IP sessions. When the MN moves
its IP sessions to another access network, it SHOULD expect that the
link MTU size has changed. Likewise, the MN SHOULD assume that the
path MTU changes whenever the access network is changed.
If the MN assigns the addresses based on the HNP to a virtual
interface, it SHOULD set the MTU size of the virtual interface to the
Premec Expires October 26, 2008 [Page 15]
Internet-Draft PMIP6 inter-tech handover April 2008
link MTU of the physical interface associated with the virtual
interface. When a physical interface associated with a virtual
interface is changed, the MTU of the virtual interface must also be
updated to the MTU of the new physical interface.
9.3. Zero physical interfaces available
It may happen that the multi-interface MN looses its connection with
the current access network before it is able to establish a
connection with a target access network. We call this situation "zero
physical interfaces". Such situation is transient in nature.
When the MN roaming in a netlmm domain looses its connection with the
current access network (link-down event), it SHOULD NOT immediately
invalidate the addresses based on the HNP and tear down the virtual
interface. Instead, the MN SHOULD perform a network scan over all
physical interfaces looking for a suitable network to attach to. If
it finds alternative access network, it should attach to it and use
the mechanism described in this document to handoff its IP sessions
from previous access network. If the MN is not able to configure the
same HNP in a new access network, then the MN SHALL release all
addresses based on HNP and all related IP sessions.
10. Security Considerations
tbd
11. IANA Considerations
The following Extension Types MUST be assigned by IANA:
'P' flag in the Router Solicitation message.
12. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Premec Expires October 26, 2008 [Page 16]
Internet-Draft PMIP6 inter-tech handover April 2008
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.
[RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[Gun2008] Gundavelli, S., Ed., "Proxy Mobile IPv6", April 2008,
draft-ietf-netlmm-proxymip6-12.txt
[Dam2008] Damic, D., et al., "Proxy Mobile IPv6 indication and
discovery", February 2008, draft-damic-netlmm-pmip6-ind-
discover
13.2. Informative References
[RFC4443] Conta, A., Deering, S., Gupta, M., "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version
6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
2007.
[Lag2008] Laganier, J., Narayanan, S., McCann, P., "Interface between
a Proxy MIPv6 Mobility Access Gateway and a Mobile Node",
February 2008, draft-ietf-netlmm-mn-ar-if-03
[IEEE802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", October 2004.
[IEEE802.16e] IEEE802.16e-2005, "IEEE Standard for Local and
metropolitan area networks, Amendment for Physical and
Medium Access Control Layers for Combined Fixed and Mobile
Operation in Licensed Bands", 2005.
Premec Expires October 26, 2008 [Page 17]
Internet-Draft PMIP6 inter-tech handover April 2008
Author's Addresses
Domagoj Premec
Nokia Siemens Networks
Heinzelova 70a
10000 Zagreb
Croatia
Email: domagoj.premec.ext@nsn.com
Teemu Savolainen
Nokia
Sinitaival 5
FI-33720 Tampere
Finland
Email: teemu.savolainen@nokia.com
Intellectual Property Statement
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.
Premec Expires October 26, 2008 [Page 18]
Internet-Draft PMIP6 inter-tech handover April 2008
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Premec Expires October 26, 2008 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 07:32:35 |