Re: [MEXT] Support of route optimization in *absence* of HA

[Alexandru Petrescu <[e-mail]>]

Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a écrit :
> Julien,
>
> The intentions of Homeless MIPv6 are similar to those of our
> proposal.
>
> In contrast to Homeless MIPv6, our proposal requires only minimal
> upgrades to the present standard and implementation. (Homeless MIPv6
>  requires changes to the TCP/UDP and requires AH, for instance).
>
> Here’s the core idea of HA-free R/O:
>
> 1)When starting a session, the MN self-declares its current IP
> address as the “HoA” for this session. This automatically means that
> it resides in its “home network” and can conduct the home test
> directly with CN, i.e. no home registration required.
>
> 2)All further BU/BA signaling is done directly with CN according to
> RFC 4866.
>
> 3)All further signaling with HA is simply omitted.

Thanks for the description.  It makes sense and is compelling.

Would this method mean that when MN moves some packets from CN arriving
at "home" are lost until MN signals its new position to CN?

Would this fail when CN is mobile? (CN changes its address).

Would this require to modify all the CNs to which this MN may talk?

Would this imply that this solution is to be applied in a small system
(smaller than the size of the Internet), system within which other
link-layer mobility protocols do fine (GGSN-SGSN) where the IP address
is kept stable).

This helps deriving requirements for it.

> Our proposal builds on “enhanced route optimization” (RFC 4866),
> which provides a nice security solution for R/O and creates the
> ground for HA-free operation.

There are more grounds for HA-less operation than just RFC4866.  One can
realize HA-less mobility operation without using RFC4866.

> Little changes are required: e.g. MN must be able to deregister its
> HoA at CN, etc.

I agree, MN must be modified but I suppose CN too.

Alex

>
> Regards,
>
> Georg
>
> ------------------------------------------------------------------------
>
>  *From:*Laganier, Julien [mailto:[e-mail]] *Sent:*
> Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg);
> [e-mail] *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: Support
> of route optimization in *absence* of HA
>
> Georg,
>
> Is it correct that functionally your proposal is similar to Homeless
>  Mobile IPv6:
>
> http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01
>
> Best,
>
> --julien
>
> *From:*[e-mail] [mailto:[e-mail]] *On
> Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20,
> 2011 12:07 PM *To:* [e-mail] *Cc:* Hampel, K Georg (K Georg);
> Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route
> optimization in *absence* of HA
>
> All,
>
> We would like to add a proposal to MEXT that permits the mobile to
> engage into route-optimization in *absence* of a home agent.
>
> Such a feature adds robustness to route optimization in case the HA
> is temporarily unavailable. Under some circumstances, route
> optimization *without* HA may be beneficial for performance reasons.
> Our proposal requires “enhanced route optimization for Mobile IPv6”
> (RFC 4866) as pre-requisite.
>
> We would like to obtain some feedback from the MEXT community via
> this mailing list before we submit the proposal as a draft to the
> workgroup. For this purpose, we have enclosed a high-level outline
> below. Thanks.
>
> Regards,
>
> Georg Hampel
>
> Networking & Networks Domain
>
> BellLaboratories
>
> Alcatel-Lucent
>
> ============================================
>
> Proposal: Support of Route-Optimization in Absence of Home Agent
>
> ABSTRACT:
>
> The proposal allows the mobile to engage into route optimization
> (R/O) in *absence* of a HA. This feature increases robustness when
> the HA becomes temporarily unavailable. Under some circumstances, R/O
> *without* HA may be beneficial for performance reasons. This proposal
> requires “enhanced route optimization for Mobile IPv6” (RFC 4866) as
> pre-requisite.
>
> MOTIVATION:
>
> In route optimization (R/O), traffic packets are directly exchanged
> between hosts without passing the HA. The mobile, however, still has
> to interact with the HA. The HA provides (1) location service, (2) a
>  fallback path in case the direct path breaks, (3) a fallback in case
> the correspondent does not support the protocol and (4) security
> support for R/O-related signaling (i.e. home test). These functions
> come at the following cost:
>
> ·Handovers may fail when the link to the HA or the HA itself are down
> or congested. Mobility is not supported, when the mobile does not
> have a HA.
>
> ·When the mobile starts a session outside of its home network, it
> must use a HoA pertaining to its home network even if it engages into
> R/O. This requirement adds air-interface overhead due to mobility
> headers and processing overhead on the mobile. This upfront cost
> incurs even if the mobile does not move during the session.
>
> ·Signaling handshakes have to be conducted between mobile and HA at
> every mobility event.
>
> Currently, the Mobile IPv6 standard family forces the mobile to bear
>  these disadvantages in R/O even if the HA functions are not needed.
> This specifically applies to scenarios where:
>
> ·Traffic is based on mobile-initiated requests to public servers
> (majority of present mobile internet traffic). The HA’s location
> service is not needed for such traffic. Location service may also be
> provided by other means such as Dynamic DNS or on application layer
> (e.g. SIP registrar).
>
> ·The fallback path through the HA has little value when it shares the
>  weakest link with the direct path. Since the weakest link is
> typically the wireless link, this situation applies to all scenarios
> where only one air interface is available (this is the typical case
> rather than the exception).
>
> ·The mobile may know about the correspondent’s Mobile-IPv6 support
> from prior sessions or through means external to the standard.
>
> ·The mobile applies the CGA-based procedure of RFC 4866, which makes
> the HA’s security support for R/O unnecessary. This applies to all
> cases where stateless addressing is permitted.
>
> To increase the flexibility and robustness of route-optimized Mobile
>  IPv6, we propose to make the HA an *optional* rather than a
> *mandatory* feature, i.e. to permit operation without HA. This
> proposal requires some additional extensions to the present
> standard.
>
> HIGH-LEVEL OUTLINE
>
> The extensions build on Enhanced Route Optimization for Mobile IPv6
> (RFC 4866) to guarantee sufficient signaling security. With the
> absence of a HA, mobility support in R/O can be provided in the
> following manner:
>
> ·The mobile starts the traffic session from any of its currently
> supported IP addresses. The selected IP address automatically takes
> the function of the HoA for this session. This has the advantage that
>  conventional transport is used as long as the mobile does not move,
> i.e. mobility headers and CoA-vs-HoA mapping is not needed. The HoA
> must have been generated via CGA in compliance with RFC 4866.
>
> ·The mobile must conduct a “home-test” from this HoA in compliance
> with RFC 4866. It may conduct the home-test prior to session
> establishment, e.g. to find out if the correspondent supports the
> standard.
>
> ·All binding update handshakes are conducted on the direct path
> according to RFC 4866.
>
> ·Since sessions are always started from a currently supported IP
> address, temporally overlapping sessions may use different HoAs. A
> multi-homed mobile may also decide to start sessions from different
> simultaneously supported IP addresses. There is no principle problem
> here.
>
> ·Opposed to RFC 4866, the mobile need not perform the CoA
> registration with the HA.
>
> ·The mobile must be able to deregister the HoA at the correspondent
> in case the HoA is not supported anymore. This ensures that the
> correspondent does not send packets to the HoA. After deregistration
> of the HoA, the HoA is still used by higher protocol layers of
> ongoing sessions. It must still be included in the mobility headers
> for these sessions.
>
> ·When the mobile has HA support and the HA becomes temporarily
> unavailable, the mobile simply continues R/O without HA as outlined
> in the prior points.
>
> ·The mobile can publish its IP address in any location service. This
>  allows other hosts to initiate sessions with the mobile. These
> sessions enjoy route-optimized mobility support only if the published
> IP address was generated via CGA in compliance with RFC 4866.
>
> OPEN ISSUES
>
> These extensions have to be made compliant with RFC 5648 (multiple
> CoA registration), RFC 3963 (NEMO) and others. More discussions are
> necessary.
>
>
>
> _______________________________________________ MEXT mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mext