One document matched: draft-tsirtsis-logically-separate-lmaha-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='../rfc2629xslt/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "../rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc5026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5026.xml'>
<!ENTITY pmip PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netlmm-proxymip6-11.xml'>
<!ENTITY pmipcmip PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.giaretta-netlmm-mip-interactions.xml'>
<!ENTITY integrated PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mip6-bootstrapping-integrated-dhc-05.xml'>
<!ENTITY mcoa PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-monami6-multiplecoa-06.xml'>
<!ENTITY flow PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.soliman-monami6-flow-binding.xml'>
]>
<rfc category="std" ipr="full3978"
docName="draft-tsirtsis-logically-separate-lmaha-00.txt">
<front>
<title>Behavior of Collocated HA/LMA</title>
<author initials="G." surname="Tsirtsis" fullname="George Tsirtsis">
<organization>Qualcomm</organization>
<address>
<email>tsirtsis@googlemail.com</email>
</address>
</author>
<author initials="S" surname="Krishnan" fullname="Suresh Krishnan">
<organization>Ericsson</organization>
<address>
<email>suresh.krishnan@ericsson.com</email>
</address>
</author>
<date month="March" year="2008"/>
<abstract>
<t>In discussions about PMIPv6-MIPv6 interactions in NETLMM WG,
scenario C describes the case of collocation of LMA and HA
function. In this case a PMIP network emulates the "home link"
for MNs using MIPv6. This document argues that even when LMA and
HA functions are Collocated they MUST be treated as logically
separate entities. In particular this draft argues that PMIP
BCEs MUST NOT overwrite MIPv6 BCEs and vice versa.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Acknowledgments">
<t>We would like to thank the authors of PMIPv6-MIPv6 interactions
draft <xref target="I-D.giaretta-netlmm-mip-interactions"/> for
providing the basis for this discussion. </t>
</section>
<section title="Introduction">
<t>In PMIPv6-MIPv6 interactions draft <xref
target="I-D.giaretta-netlmm-mip-interactions"/>, scenario C
describes the case of collocation of LMA and HA function. In
this case a PMIP network emulates the "home link" for MNs using
MIPv6. This document argues that even when LMA and HA functions
are Collocated they MUST be treated as logically separate
entities. In particular this draft argues that PMIP BCEs MUST
NOT overwrite MIPv6 BCEs and vice versa.</t>
</section>
<section title="The Case for Logically Separate LMA and HA">
<t>When a PMIPv6 <xref target="I-D.ietf-netlmm-proxymip6"/> local
mobility agent is collocated with a MIPv6 <xref target="RFC3775"
/> home agent, the PMIPv6 network can be configured to emulate
the MIPv6 "home link" for a mobile node using MIPv6. This
configuration and its implications are discussed below.</t>
<section title="Logical Relationship Between Colocated LMA/HA">
<t> A PMIPv6 network comprising an LMA and multiple MAGs
emulates a single link. When a PMIPv6 LMA and a MIPv6 HA are
Collocated, PMIPv6 is used to handle mobility between MAGs
in the same PMIPv6 network emulating the link, and MIPv6 is
used to handle mobility between different links (emulated or
physical).</t>
<t>In that sense, logically, the PMIPv6 LMA operates at a lower
layer than the MIPv6 HA. This means that when a packet is
received by the LMA/HA, the destination address of the
packet is first matched against Binding Cache Entries (BCE)
created by MIPv6 BUs. If there are no MIPv6 BCEs for this
destination address (i.e., the MN is deregistered at MIPv6
level) then LMA BCEs are searched.</t>
<t>This simple way of thinking about logically separating the
two functions, ensures that MNs can move between PMIPv6
emulated links and other links the same way the do between
physical links and without require any specific
implementation of the combined LMA/HA. </t>
<t>Indeed, the two logical functions can be implemented as two
different but communicating processes or as a single
integrated process. The BCE tables of the LMA and the HA can
also be combined in a single table or they can be maintained
as separate tables. This draft does not impose, propose, or
in any other way imply any specific implementation. Instead,
this draft describes the required external behavior of such
a combined LMA/HA implementation and argues against PMIPv6
BCEs overwriting MIPv6 BCEs.</t>
<section title="BCE Overwritting is Wrong">
<t>There is currently a school of thought in the NETLMM WG
that wants PMIPv6 PBUs to overwrite state created by
PMIPv6 BUs and vice versa. This school of thought comes
from a fundamental assumptions that as MNs move from one
link to another, they only maintain ONE link at a time.
In other words the assumption is that during a handoff
an MN will disconnect from one link and connect to
another. In that sense, when a combined HA/LMA receives
a MIPv6 BU over a foreign link, it can overwrite any
state created in the LMA for the same mobile (since
presumably the MN is no longer connected to the MAG).
Based on the same logic when an combined HA/LMA receives
a PMIPv6 BU over a MAG on the home link, it can
overwrite any state created in the HA for the same
mobile (since presumably the MN is no longer connected
to a foreign link).</t>
<t>This logic breaks down if one considers MNs that are
capable of maintaining more than one link at the same
time. Such capability is common and can be utilised in
many different way, while specifically MIPv6 allows for
the following behavior: </t>
<t>
<list>
<t>Directing traffic between foreign links: If an MN
can maintain two links at the same time, it can
direct traffic to one or the other link by
simply sending a BU to its HA, registering the
CoA corresponding to one or the other link.</t>
<t>Directing traffic between home and foreign link:
If one of the links maintained is the home link,
the MN can direct traffic to it by sending a
deregistration MIPv6 BU to the HA over the home
link, while it can also direct traffic to the
foreign link by sending a MIPv6 BU to the HA
directing traffic to the CoA of the foreign
link.</t>
<t>Directing traffic between Multiple links: MEXT WG
is also working on <xref
target="I-D.ietf-monami6-multiplecoa"/> and
<xref
target="I-D.soliman-monami6-flow-binding"/>
specifications allowing an MN to register
multiple links (multiple CoAs and the home link)
to its HA at the same time and even direct
different flows to different links.</t>
</list>
</t>
<t>It should be clear that none of this can be possible if
every time the MN connects to its home link, the
corresponding PMIPv6 BCE overwrites the HA BCEs for the
same mobile or every time the MN sends a BU to its HA
over a foreign link, the MIPv6 BCE overwrites the LMA
BCE entry for the same MN.</t>
</section>
<section title="Shared State between LMA and HA">
<t>If the HA is configured as a virtual home link HA (i.e.,
there is no direct link between MN and HA), there are no
need to share any parameters between HA and LMA
functions. The LMA and HA function, however, need to
share certain parameters in a Collocated implementation
if the PMIPv6 network is used as a home link, i.e., if
the PMIPv6 network emulates a direct connection between
the MN and the HA. The parameters that need to be shared
in this case have to do with the addresses assigned to
the MN by the two entities. Specifically:</t>
<t>
<list>
<t>When an LMA receives a PBU for a new MN, it MUST
first check if the MN is associated with the
Collocated HA e.g. based on the MN-ID. If the HA
already has a home address associated with this
MN, then the LMA MUST allocate the same address
over the PMIPv6 home link.</t>
<t>When an HA receives an IKEv2 bootstrapping
request for a new MN, it MUST first check if the
MN is associated with the Collocated LMA e.g.
based on the MN-ID. If the LMA already has a
prefix associated with this MN, then the HA
provide the MN with the same HNP over the IKEv2
session.</t>
</list>
</t>
</section>
</section>
</section>
<section title="Detailed Bootstrapping and Handoff Considerations">
<section title="Bootstrapping on Emulated Home Link">
<t>When an MN connects to a MAG in a PMIPv6 network, it receives
an RA indicating a prefix that is topologically correct at
the LMA and unique to the MN. This prefix can be used by the
MN to autoconfigure one (or more) IPv6 address. This address
continues to be valid as the MN moves between MAGs in the
same PMIPv6 network. This is so since every time the MN
moves to a new MAG, the MAG sends a PBU to the LMA creating
a PMIPv6 Binding Cache Entry (BCE), binding the MN's prefix
with a MAG's address. Any packet with a destination address
matching the MN's prefix, is directed to the LMA, which
based on the BCE table it tunnels the packet to the
appropriate MAG which then delivers it to the MN.</t>
<t>Assume now that the MN, equipped with an IPv6 address derived
from a prefix provided to it over the link emulated by the
PMIPv6 network, wants to bootstrap MIPv6. Also assume that
the HA used by the MN is the one Collocated with the LMA of
the PMIPv6 network the MN is connected to. This address is
maybe discovered by Dynamic HA Address Detection (DHAAD) as
defined in <xref target="RFC3775"/> or by any of the
bootstrapping mechanisms <xref target="RFC5026"/>
<xref target="I-D.ietf-mip6-bootstrapping-integrated-dhc"/>. </t>
<t>The MN proceeds to establish a security association with it
using IKEv2. According to <xref target="RFC5026"/>, as part
of this procedure the HA can provide the home network prefix
(HNP) to the MN. The MN immediately understands that it is
attached to its MIPv6 home link since the prefix advertised
to it directly over the link (in an RA) matches the HNP
provided to it by the HA. In this case the MN does not need
to send a MIPv6 BU to the HA and the logical HA function
does not get initiated.</t>
<t> In other words, any packet sent to the MN's prefix is still
intercepted by the LMA and redirected to the appropriate MAG
(according to PMIPv6 BCE table) for delivery to the MN over
the emulated home link.</t>
</section>
<section title="Connecting to Foreign Link">
<t>If the MN connects to an access router that is not part of
the same PMIPv6 network as before i.e., on a foreign link,
it will receive an RA with a different prefix (say a foreign
prefix) and generates an IP address on the foreign link.</t>
<t>Note that up to now nothing has changed at the Collocated
LMA/HA. All traffic is still redirected by the LMA to the
registered MAG according to the state in the PMIPv6 BCE
table. For this to change the MN needs to send a MIPv6 BU to
the HA. The BU introduces an entry to the MIPv6 BCE, binding
the MN's prefix to the CoA. Any packets now reaching the
LMA/HA will now match the MIPv6 BCE and be redirected to the
CoA.</t>
<t>Note that the MIPv6 BCE created by the BU sent over the
foreign link MUST NOT overwrite the PMIPv6 BCE for the same
MN. The PMIPv6 BCE for this MN is removed only if and when
the MN disconnects from the MAG in the PMIPv6 domain and has
nothing to do with the HA state. Indeed, according to when a
MAG an MN disconnects from a MAG, the MAG is supposed to
send a deregistration BU to the LMA removing the
corresponding BCE for that MN.</t>
</section>
<section title="Connecting Back to Emulated Home Link">
<t>Now say that after the MN has disconnected to from the PMIPv6
MAG and registered to the HA via a foreign link, the MN
connects again to its emulated home link via one of the MAGs
in the PMIPv6 network.</t>
<t>The MAG the MN connects to, is supposed to send a PBU to the
LMA. Since the MN maintains a relationship with the HA, the
LMA should provide the same prefix as before i.e., the HNP.
This means that when the MN receives the RA from the MAG,
which includes the a prefix matching its HNP, it will detect
that this emulated link is its home link.</t>
<t>Note that the PBU sent by the MAG MUST NOT overwrite the
MIPv6 BCE pointing to the foreign link for this MN. This is
because the MAG can not possibly know whether the MN still
maintains the foreign link or not. Indeed, if the MN wants
to receive its traffic over the home link it will sent a
deregistration MIPv6 BU to the HA and remove the MIPv6 BCE.
When that happens packets will again reach the LMA and be
redirected according to the PMIPv6 BCE to the appropriate
MAG.</t>
</section>
</section>
<section title="Security Considerations">
<t>This document does not introduce security issues</t>
</section>
<section title="IANA Considerations">
<t>This document requires no action from IANA.</t>
</section>
</middle>
<back>
<references title="Informative References"
>&rfc2119;&rfc3775;&rfc5026;&pmip;&pmipcmip;&integrated;&mcoa;&flow;</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:00 |