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

Hello and thanks for this message,

I think generally Route Optimization in the absence of a Home Agent is a
useful matter to address.

With colleagues I have worked on a solution whereby two Mobile Routers
can communicate directly via their egress interface, bypassing the need
to contact the Home Agent:
http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00
(the draft is being updated with transportation scenarios and expanded
  authorship, and I would be interested to discuss it further).

In a certain sense this MR-to-MR can be considered as Route Optimization
without using Home Agent, although it is at a certain extreme where no
Home Addresses/CoAs are used either.

A related draft MNPP does a similar behaviour, but it has an additional
scenario with a fixed Access Point:
http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00

I insert below some comments on the preliminary text you provided:

Le 20/01/2011 21:07, Hampel, K Georg (K Georg) a écrit :
> 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 is a good point - it is very advantageous to perform direct
MN-to-MN communication some times when HA is little or not available at all.

> This proposal requires “enhanced route optimization for Mobile IPv6”
> (RFC 4866) as pre-requisite.

I must say I do not understand why this RFC is required.  Is your
proposal intended to become an extension of RFC4866?

> 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).

YEs, the first step (1) is the fact establishing the initial BC entries
(the ones permitting direct non-tunnelled communication CoA to CoA on
behalf of the HoAs) is impossible if HA does not reply.  Once the BC
entries are established the HA is no longer needed.

> 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.

I agree, this is an excellent point.  Lack of HA forbidding
network-layer communication upon handover is an unfortunate consequence
of cross-layer otherwise abberant tunnel assumptions.  Tunnels have a
magic in them (go up next level( but they also expose their weaknesses
when least expected.

> ·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.

Is this the HoA in the Routing Header being a packet size problem?

> ·Signaling handshakes have to be conducted between mobile and HA at
> every mobility event.

This is a cost? yes and no.  BU/BAck and RR messages happen relatively
fast compared to RS/RA address autoconfig, and the link-layer messages
used during handovers for configuration and security.  The Mobile IPv6
signalling represents less than 10% from the handover time, even in the
unfortunate cases when HA is very far away in the Internet.  In another
sense, it is good to optimize out even these 10%.

Also, if you start saying MIPv6 signalling is a "cost" (a negative) then
make sure you don't design something new which actually has a higher
cost.  You risk struggling against a cost which is already very low
(Mobile IPv6 BU/BAck RR message exchange cost is very low).

> 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).

YEs, I agree, one wouldn't need the MH to use its HoA when talking some
web browsing to a local server.

> ·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).

I need to better understand this.  What is the "direct path"?  I
understand "fallback path" being to HA.  I would need further
explanation of this item.

> ·The mobile may know about the correspondent’s Mobile-IPv6 support
> from prior sessions or through means external to the standard.

A-ha, so there are scenarios where the MHs may know each other's
CoA/HoAs pre-configured somehow.

> ·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.

Do we need to limit an HA-less RO mechanism to using CGA?  Would this
work without CGA?

> 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.

So you want to design an RFC4866bis?

> 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.

This is a technique, yes.

Is RFC4866 more implemented than MIPv6 RR?

> OPEN ISSUES
>
> These extensions have to be made compliant with RFC 5648 (multiple
> CoA registration), RFC 3963 (NEMO) and others. More discussions are
> necessary.

I agree.

Alex

>
>
>
> _______________________________________________ MEXT mailing list
> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext