Subject: [Mipshop] Difference between MAP and HA

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 28 Nov 2006 16:00:44 +0100

Hi all,

I guess this question has been brought up several times in the HMIP
history, so maybe someone can provide a quick answer: I'm wondering why
HMIP doesn't reuse an RFC3775 HA as MAP. 

It seems that the "M" bit in the BU is the only difference between a MAP
and a HA that prevents real re-use (the MAP option for dynamic MAP
discovery is optional). But why is this bit needed? RFC4140bis says that
the purpose is to distinguish a BU sent to a MAP from a BU sent to HA or
to a CN. But what exactly is the problem? If the problem is on the
MN-side: The MN could as well remember (e.g., in the BUL) which BU
destination address is a HA and which is a MAP. If the problem is on the
HA-side: there should be no problem if MAP and HA functionality are
identical.

Thanks,

Kilian

------------------------------------------------------------
Dr.-Ing. Kilian Weniger
Panasonic R&D Center Germany GmbH,
Monzastr. 4c, 63225 Langen, Germany
phone:  +49 (0)6103 766 137
fax:    +49 (0)6103 766 166
e-mail: [email-masked]
------------------------------------------------------------

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 11:46:17 +1100

> history, 

=> Yes.

  so maybe someone can provide a quick answer: I'm wondering why
 > HMIP doesn't reuse an RFC3775 HA as MAP.

=> The forwarding aspects of the HA, the data strcuture, packet protection
...etc are all used. The differences were in how that "HA" would be
discovered, the scope of that "HoA", and how mobility is done across LMM
domains. So it's a small extension in terms of protocol and somewhat larger
extension in terms of behviour. The other obvious reason is the security
aspects related to address authorisation, but I won't repeat that in this
email.

 > discovery is optional). 

=> No the M flag is not the real difference, see above.

   But why is this bit needed? RFC4140bis says that
 > to a CN. But what exactly is the problem? 

=> I got this question a few times so I'll add an explanation in the text.
The M bit distinguishes a home reg from a MAP reg. This was done to allow a
MAP that also acts as an HA for some MNs to decide (based on its loading)
whether it should accept more MAP registrations. I.e. it might prioritise HA
reg over the MAP ones.

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 29 Nov 2006 11:35:23 +0100

Hi Hesham,

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Mittwoch, 29. November 2006 01:46
> To: 'Kilian Weniger'; [email-masked]
> Subject: RE: [Mipshop] Difference between MAP and HA
> 

ok, then thanks for replying again. But maybe the question is a bit
different now in the context of the recently developed MIPv6
bootstrapping mechanisms (assuming most of them can be applied to HMIP).

>  > HMIP doesn't reuse an RFC3775 HA as MAP.

I should rephrase the question: Wouldn't it be valuable and possible
(maybe with minor modification to RFC4140) to provide *the option* to
reuse an RFC3775 HA implementation as MAP?

> discovered, 

The spec says manual configuration of ARs with the MAP option
information is the default and dynamic MAP discovery is optional. So I
assumed that the MAP does not need to implement anything specifically
for MAP discovery (e.g., if an operator only wants to use manual or any
other discovery mechanism such as the ones specified for MIPv6). Do you
agree?

> the scope of that "HoA", 

What do you mean by "scope of an address"? What is the difference
between a RCoA and a HoA from a local HA in this context?

> and how mobility is done across LMM domains.

Which additional functionality is required in the MAP for this, compared
to bootstrapping with a local HA and changing from one local HA to
another? Isn't all the intelligence for changing MAPs/HAs in the MN?

> So it's a small extension in terms of protocol and 
> somewhat larger

I assumed that with IKEv2 the address authz of the RCoA is the same as
for the HoA in MIPv6 bootstrapping (That's also what I read from Vidya's
and Gerardo's last emails).

> => No the M flag is not the real difference, see above.

Sorry, I still don't get what this "real" difference is. Could you
please elaborate based on my comments above?

> whether it should accept more MAP registrations. I.e. it 

Hmm, I see. The idea is to prioritise the provision of "basic mobility
service" over "LMM optimization service". Makes sense. But since this is
very deployment-sepcific, wouldn't it make sense to make this optional
(e.g., flag in MAP option that tells whether MN should use the bit)?
E.g., some operators may deploy separate anchors for LMM and for global
MM, in which case this prioritisation is not needed. And even if they
are co-located, wouldn't the network get the type of requested service
(LMM or global MM) during service auth/authz?

Regards,

Kilian

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 21:57:23 +1100

> reuse an RFC3775 HA implementation as MAP?

=> Please define exactly what you mean by "implementing the HA as a MAP".
You can view the MAP as an extension to the HA, I'm not sure what exactly
you want to do. Functionally, it already does the same thing as I said
before. 

 > other discovery mechanism such as the ones specified for MIPv6). Do you

=> Of course, but you didn't get my point, my point was the discovery as far
as the MN is concerned not the MAP.

 > between a RCoA and a HoA from a local HA in this context?

=> See RFC 4140's definition of a MAP domain.

 > another? Isn't all the intelligence for changing MAPs/HAs in the MN?

=> Yes, I didn't say it's in the MAP! I did say it was in the spec though. 

 > and Gerardo's last emails).

=> It's very similar to a dynamic HoA allocation but not the static one.
Also, as I mentioned above this is one of the differences.

 > please elaborate based on my comments above?

=> I'm not sure I can elaborate any more, perhaps if you already read the
draft you can come up with a clear proposal of what you want. I already
listed all the differences as I see them. 

 > (e.g., flag in MAP option that tells whether MN should use the bit)?

=> So you want a flag to indicate whether a flag is needed? :) I don't see
the need, if the MAP chooses to ignore it there is nothing to do. So if you
implement a MAP and you decided to ignore the M flag and treat all BUs the
same then that's a choice we can't police.

 > MM, in which case this prioritisation is not needed. 

=> Ok but what's the problem? They won't use the flag? So what?

   And even if they
 > (LMM or global MM) during service auth/authz?

=> Depends on the network technology you have in mind. 

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 29 Nov 2006 14:24:52 +0100

> you want to do. Functionally, it already does the same thing as I said

I didn't say "...implementing HA as a MAP". I said "...to reuse HA
(implementation) as MAP". My question is about using an RFC3775 HA as
HMIP anchor (i.e., as LMM anchor for HMIP-aware MNs).

> as the MN is concerned not the MAP.

It seems the confusion is due to a misunderstanding: My question was
about reusing the HA as HMIP anchor. Changes to an RFC3775 MN to make it
HMIP-aware are irrelevant for this question.

> => See RFC 4140's definition of a MAP domain.

I know what the MAP domain is (spec says "A MAP domain's boundaries are
defined by the Access Routers (ARs) advertising the MAP information to
the attached Mobile Nodes."). But I guess this point is not relevant for
the question of reusing the HA as HMIP anchor...

> => Yes, I didn't say it's in the MAP! I did say it was in the 

ok, same misunderstanding. This is not relevant for my question.

> Also, as I mentioned above this is one of the differences.

let's assume dynamic RCoA allocation.

> same then that's a choice we can't police.

:) you are right, this works. I wronlgy assumed the HA would discard a
BU with M bit, but the M bit is in the reserved field of the BU as
defined in RFC3775 and RFC3775 says that the reserved field must be
ignored by the receiver...

So the answer to my question is that RFC4140 already allows the use of
an RFC3775 HA as HMIP anchor, right?

Thanks,

Kilian

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 30 Nov 2006 00:42:10 +1100

> HMIP anchor (i.e., as LMM anchor for HMIP-aware MNs).

=> It *is* acting like an HA with about 99% reuse of the code. What exactly
do you want to use, just the name? May be you should explain what you see is
wrong or what scenario is better served that way. I don't think it's useful
to talk about a term.

 > the question of reusing the HA as HMIP anchor...

=> Your question above was about the "scope" of the address, that's why I
referred you to the MAP domain in the spec, which implies a scope for the
RCoA, unlike the HoA. 

 > an RFC3775 HA as HMIP anchor, right?

=> Wrong. Please read my responses and read the HA specs in 3775. The HA in
3775 doesn't allow for the addressing model we have in HMIP...

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 29 Nov 2006 18:42:30 +0100

> wrong or what scenario is better served that way. I don't 

;) Let's keep the discussion on a technical level. As you know it's not
only about reusing the terms/names, it is about reusing the
functionality of an HA. And I don't see anything wrong with HMIP, I just
asked a technical question: "Can a HA be used as HMIP anchor or is there
an interoperability problem?". 

Maybe some background information helps: The main reason for the
question was to better understand the *essential* (have-to-implement)
functions of a MAP and compare them to a HA. This may help in the
discussion whether specific MIPv6 extensions (such as the boostrapping
mechanisms) can be applied to HMIP without changes or not, something
that was discussed in another thread on this list. 

Furthermore, there might be operators that already own HA products, want
to deploy HMIP, and therefore want to reuse HAs as anchors for HMIP LMM
(of course with sacrificing the optional features specified in RFC4140
such as dynamic MAP discovery). However, whether this would be valuable
for operators has to be decided by the operators themselves and is a
different question... 

> referred you to the MAP domain in the spec, which implies a 

ok. Do you mean with "scope for RCoA" that a BU from outside the MAP
domain can be rejected by the MAP, as described in the following
section?

"A MAP MAY be configured with the list of valid on-link prefixes that
   mobile nodes can use to derive LCoAs.  This is useful for network
   operators to stop mobile nodes from continuing to use the MAP after
   moving to a different administrative domain.  If a mobile node sent a
   binding update containing an LCoA that is not in the MAP's "valid
   on-link prefixes" list, the MAP could reject the binding update using
   existing error code 129 (administratively prohibited)."

However, this is optional to implement/configure on the MAP.

> 3775 doesn't allow for the addressing model we have in HMIP...

It's difficult to come to a conclusion with this type of discussion (I
read your responses and the specs, but they don't answer my question.
That's why I posted the questions on the mailing list). Unfortunately,
your response leads to a new question: What do you mean with "addressing
model" in this context? Neither the spec nor your previous responses
talk about an HMIP addressing model. I assume you mean the rejection of
Bus outside of the RCoA's MAP domain? If so, this is optional and hence
shouldn't prevent the use of an HA as HMIP anchor. 
Or do you mean that the MN auto-configures the RCoA in HMIP? But this
should be possible with the MIPv6 bootstrapping mechansisms if the HMIP
anchor is an HA. 

So is there any interoperability problem, if the HMIP anchor is an HA? I
can't see one.

Thanks,

Kilian

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 30 Nov 2006 19:49:42 +1100

> an interoperability problem?".

=> Which is exactly what my answer above says, there is probably 99% reuse
here. I think earlier answers explained exactly that depending on which HA
implementation you're referring to, you could use it (i.e. 3775 Vs others).

 > that was discussed in another thread on this list.

=> I think you might be looking at this in a sub-optimal view. HMIP *is* a
mechanism of allocating a *local* HA. What happened later with the
bootstrapping work is essentially replicating the idea and adding more ways
of bootstrapping the SA, e.g. AAA, as well as allowing things like DDNS to
be issued by the HA. The rest of HMIP is about what you can do with such
configuration.

=> Yes.

 > However, this is optional to implement/configure on the MAP.

=> I don't understand the "However" above, I didn't say it was mandatory.

 > Bus outside of the RCoA's MAP domain? 

=> No.

    If so, this is optional and hence
 > Or do you mean that the MN auto-configures the RCoA in HMIP? 

=> Yes.

   But this
 > should be possible with the MIPv6 bootstrapping mechansisms if the HMIP

=> I guess what makes it difficult to answer your question is that you keep
switching between 3775 and bootstrapping as if bootstrapping is part of
3775. Your question above was specifically about a 3775 HA... so the answer
is of course no. But if you have an HA that allocates addresses dynamically
and is discoverable in a suitable manner and can be located in the local
domain, then the answer is yes of course, that's what a MAP is. 

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 30 Nov 2006 10:41:43 +0100

ok, I think this answers my question. 

Thanks,

Kilian 

> Sent: Donnerstag, 30. November 2006 09:50
> To: 'Kilian Weniger'
> Cc: [email-masked]