Subject: RE: [mobile-ip] HMIPv6-next steps

From: "Alan O'Neill" <[email-masked]>
Date: Fri, 20 Sep 2002 00:29:49 -0400

James,

I also have some likely requirements here on controlled allocation of MAPs.
At the moment the MAP is selected by the MN based on routing metrics /
precendence.

Hesham seems happy for that kind of work to continue outside the main spec
so maybe we can combine these two aspects (adertisement and
selection/allocation) together in a single piece of work down the line..

Alan.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: 18 September 2002 03:27
To: Behcet Sarikaya; Hesham Soliman (EAB)
Cc: [email-masked]
Subject: Re: [mobile-ip] HMIPv6-next steps

This is an issue that has come up in our discussions as well.

We are particularly interested in some way of doing MAP discovery that does
not
involve detecting modified RAs. This could involve a custom built
administratively scoped multicast discovery protocol, or possibly the use of
SLP
or some other discovery protocol.

The reason for this is because we would like to maintain the option of
deploying
MIPv6 with standard IPv6 routers, and then deploy MAPs for location privacy
without requiring any modifications on the routers or configuration of
router
advertisements.

This option does not have to be in the base specification, unless there is
wider
agreement that this would be a better design.
If it is not in the base specification, then RA-based MAP advertisement
should
be properly qualified as the advertisement technique so that other
techniques
are allowed. We are prepared to work together on designing a MAP discovery
technique if there is broader interest in this possibility, either in a
separate
draft or as a contribution to the base draft.

            jak

----- Original Message -----
From: "Behcet Sarikaya" <[email-masked]>
To: "Hesham Soliman (EAB)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 17, 2002 10:07 AM
Subject: Re: [mobile-ip] HMIPv6-next steps

> Hesham,
>   I agree with the decision to remove the extended mode.
> As for the comments, I suggest that you look into the open issues I
> tried to point out in my draft on LMM architectures, the most important
> one being how to detect domain changes, etc. The pointer to version 1 is
> in one of my previous messages.
>
> Regards,
>
> Hesham Soliman (EAB) wrote:
>
> >Hi all,
> >
> >After some discussion with the chairs we agreed
> >that we will send an update on HMIPv6 to the
> >list FYI and comments.
> >
> >A couple of people have indicated that it might
> >be good to put extended mode in a separate draft,
> >partly because it is helpful for nemo and partly
> >because it will need some more work to accomodate
> >the latest changes in the MIPv6 base.
> >
> >Extended mode might be useful for nemo, but it's too
> >early to tell right now, for this reason it is hard
> >to keep it in a MIP WG document. On the other hand,
> >it is also useful for removing the extra tunnel
> >when CNs do not use/implement RO.
> >
> >What we're trying to do is to finish the draft ASAP.
> >For this reason, and given comments on the list, the
> >chairs suggested that we remove extended mode for
> >now and proceed with Basic mode only. If we later
> >agree on a nice solution for using extended mode
> >with MNs implementing RR with CNs, then we can proceed
> >with a separate draft.
> >
> >We are now working on a new revision that will reflect
> >these changes, your feedback is welcome as usual.
> >
> >Hesham
> >
> >
> >
>
> --
> Behcet
>
>
>
>

---

From: Greg Daley <[email-masked]>
Date: Fri, 20 Sep 2002 15:40:04 +1000

Hi Alan and James,

For an equivalency, we could allocate a site-scope local
multicast to which which the MAP sends advertisements.

This could be send with a finite multicast hop limit,
and maybe the MAP could indicate the original hoplimit
in the advertised option.

Therefore, each MAP may only send the multicast packets a
certain number of hops, and therefore their influence could be
controlled. Also, since the original number of hops is
available, MN's can determine the distance to the MAP
based on current hop limit (for map selection heuristics).

MAP options will not arrive together, so MN's may initially
select a non-optimal MAP, but a mechanism may be described
which allows later selection of a better MAP, if desired.

As a bonus, Access networks where no nodes are using HMIP
multicast discovery receive no advertisements ;)

Selection of HMIPv6 MAP could be performed based on the union
of HMIPv6 advertising techniques (Mcast/RA).  If the group
doesn't exist and no RA advertisements are received, then
fallback is MIPv6.

Greg,
Who's happy if he can use radvd to send map options.
(BSD-like License, source code available ;-)

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Sep 2002 09:40:18 -0700

> doesn't exist and no RA advertisements are received, then

As a general rule, it is not a good idea to do service discovery by having the
service advertise (routers being the exception because the advertisements only
happen on a single link). The Novell discovery protocol often consumed 10% of
the local network bandwidth because it had the services multicasting periodic
advertisements.

A better idea is to have the host multicast to an administratively scoped (RFC
2365, BCP23) multicast address when it wants to find the MAP. The network
operator controls the scopes, so different MAPs can appear in different pieces
of the network topology.

Alternatively, we could use an anycast address, as is done with the Home Agent.

One issue is whether there are particular attributes characterizing a MAP other
than its location in the topology that might be of interest to a MN. The
location in the topology is controlled by the administratively scoped multicast.
If so, then we may want to look at a more general service discovery protocol,
like SLP. Otherwise, we may need to define a protocol to allow the MN to sort
through the attributes. If not, then we can just use a multicast or anycast
address.

The other issue is how a host knows when it has moved outside the scope of a
MAP. Perhaps the returned MAP adverisement contains information (like subnets
covered) which the host can use to determine when it has to look for a new MAP.
This avoids the problem of the host having to constantly probe, or the MAP to
constantly multicast.

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 23 Sep 2002 11:24:48 +1000

Hi James,

There is some difference between advertising a routing
routing service with IPv6 multicast, and having broacast
storms with IPX networks which used broadcast
advertisements to propagate all manner of information
until it hit a filter.

Your suggestion about using a limited scoped system
where advertisements are controlled at the boundary of their
usefulness is well taken, but the RFC you pointed to
2365 is an IPv4 backport of the site-scoping available in
IPv6!

Maybe limiting the multicasting based on hop-count isn't
optimal, but site-local or the admin scope from
IPv6 Scoped Address Architecture draft may be appropriate for
either periodic advertisement or probing based solutions.

I get shy of probing solutions which aren't based on multicast
because they tie the LMM scheme to a node which understands
the request on the unicast path of the packet travelling through
the network (something which it seems you want to avoid,
by using unmodified routers).  Using SLP or another mutlicast
based probing mechanism would have to be used with caution,
since in most locations, there will be thousands of probing
mobile nodes per MAP.

The idea of indicating coverage which you have is good if it
can be done efficiently.  Maybe a coverage field which
indicates the prefix over which the MAP may be used.
I wouldn't use a probing system without this sort of
information available, because of the load probing could have
on the network.

This doesn't necessarily get us to a point where we can choose
the best MAP though, if we rely on probes only when we enter
a domain not covered by the previous MAP, we won't be able to
adjust to a better MAP when we're in an access network where
MAP coverage overlaps.

Periodic advertisements can be used with some effect in these
situations, but it needn't be IPXv6...

As it stands, I'm happy using MAP advertisements in the
Router Advert.  It stops a second link acquisition to send the 
information (useful in 802.11b), and may be sent unicast, in
response to a link-local only probe.  I'd like
HMIPv6 to be useful and attractive to deploy though, too,
so I can understand the points yourself and Alan are making.

We can look at definition of an SLP Service Type,
but I'd suggest it can be done as an adjunct to the
Basic function in another document.  It would be used
in situations where a MN supports HMIPv6 and isn't
receiving MAP advertisements from the router (which is known
when site/global addresses are formed).

Greg

James Kempf wrote:
[greg's last message cut]

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Sep 2002 14:42:58 -0700

> either periodic advertisement or probing based solutions.

Agree.

> information available, because of the load probing could have

There would need to be some indication of coverage area in the advertisement,
else the probes would be too frequent.

> adjust to a better MAP when we're in an access network where

What is the requirement for overlaps?

> so I can understand the points yourself and Alan are making.

If someone wants to use a Cisco 3600 as their access router, they should be able
to, even though it doesn't support HMIP advertisement. And they can do it today.

> when site/global addresses are formed).

I'm not tied to an SLP solution, but I would like a solution that doesn't
consume much bandwidth. The issue with SLP is whether there are other attributes
besides the location in the network that would make a MAP attractive for a MN.
If there are, then using something like SLP with attributes in the queries would
be useful. Off the top of my head, I can't think of any other attribute that
would be necessary, except what edge subnets the MAP supports.

Part of the problem with multicasting is that, as I mentioned, unlike router
adverts, a MAP advert need not be on a single link. One could argue that there
will not be enough MAPs to really impact performance, but if everyone in the
IETF who does a new service argues that way, pretty soon the advertisements add
up to real bandwidth.

I agree that having a separate document is the best solution. The only thing I
think we need in the base document is a statement saying that router adverts
SHOULD be used, but other discovery solutions MAY be, or something like that.

            jak

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Sep 2002 14:03:42 +1000

Hi James,

Some inline responses follow.
Mostly it's a brain dump, so some of
the ideas aren't necessarily thought through yet.

[first portion of response clipped]
> to, even though it doesn't support HMIP advertisement. And they can do it today.

They may be able to use a dhcpv6 server with a "HMIPv6 MAP"
information option similar to supplying a DNS server.
(draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt)

I'm not sure how mature DHCPv6 is, but DHCP has tradisitonally
been used in a similar role.
The option could even indicate coverage in a similar fashion to
the SLP idea. less DHCP probing would then be required.

The config could be stored on a server and access routers
act as relays, as today.

> would be necessary, except what edge subnets the MAP supports.

MAP Preference would be used to choose between multiple
redundant MAPs (as per Hesham's post).

> IETF who does a new service argues that way, pretty soon the advertisements add

Indeed, This is an important issue, but we're talking about
a routing proxy, so it is very interesting to the MN which
wants the signalling limitation which it supplies when handing
over.

Some node in the network either has to respond to a solicitation
in the probing case (even for SLP), so this either has to be
on the unicast path, the access router (a special case of the same)
or a multicast mechanism.

Unsolicited Advertising has many of the same issues.  The reason
is the separation of the MAP from the access network infrastructure
(which is one of the goals, IMHO).

I see the non-access network ideas to be:

unicast probing (like draft-vriz-mobileip-hbhlmap-00.txt)

multicast probing of a generic service (SLP Service Type or similar)

DHCPv6-proxies (with MAP info stored on a remote server)

specific multicast probing mechanism (to a discrete multicast address)

specific periodic multicast advertisement mechanism (Admin Scoped?)

Router Renumbering MAP Propagation (draft-ietf-mobileip-hmipv6-06.txt)

Can anyone think of another?

> SHOULD be used, but other discovery solutions MAY be, or something like that.

Absolutely.  We need to have at least one method defined (RA),
even if it is not available on all routers (it may be a simple
change for some).

That needn't inhibit using an advertisement or discovery protocol
which is independent of the access network hardware.

Greg.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Sep 2002 08:57:26 -0700

Greg,

Good list of options. DHCP is an interesting one, though I think something for
stateless autoconfig might be needed too. I wonder if DNS could work, for
example SRV record or NAPTR.

            jak

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Alan O'Neill" <[email-masked]>; "Hesham Soliman (EAB)"
<[email-masked]>; <[email-masked]>
Sent: Monday, September 23, 2002 9:03 PM
Subject: Re: [mobile-ip] HMIPv6-next steps

---

From: Greg Daley <[email-masked]>
Date: Wed, 25 Sep 2002 12:58:43 +1000

> example SRV record or NAPTR.

I think that DNS is OK once you know where to
query...

Actually, I liked the SRV method, but was not sure
what information would be used in the query (esp for NAPTR)
for example, how would you determine your domain,
except using dhcp/stateful systems?

a default 'local' domain perhaps, which would supply
information about the access networks you participate in?
or would you find out your domain before querying for the MAP?

some suggestion has been made about having a default
site-local IP address for DNS. If this were used,
the MN wouldn't necessarily know the domain.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Sep 2002 21:48:46 -0700

> except using dhcp/stateful systems?

The IPv6 WG is working on an anycast protocol for IPv6 DNS server discovery, but
I don't know if that requires knowing the local domain or not. Of course, with
DHCP you could configure it.

        jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 25 Sep 2002 16:57:41 +1000

we seem to be coming back to dhcp. :)

Greg