Re: [Mip6] Comments on draft-wakikawa-mobileip-multiplecoa-02.txt

[Ryuji Wakikawa<[e-mail]>]

Hi James

At Fri, 31 Oct 2003 18:42:22 -0800,
James Kempf wrote:
> 
> Thierry,
> 
> I looked at draft-wakikawa-mobileip-multiplecoa-02.txt and the fundamental
> architectural idea here seems to be to introduce a new namespace, the BID,
> to tie together multiple CoAs to one HA. I can see a couple issues with this
> approach.

Well, I am not sure whether BID is the new name space or not. The
identifier of MN is still HoA.  BID is nothing to do with session or
endpoint identifier. BID is identifier to distinguish bindings for the
same HoA. BID is used only for binding management (registration, de-,
refresh) and binding selection only. 

The name of BID might be wrong, we should name like nonce index
(i.e. just index each binding). If the name of "BID" is reason to
cause misunderstanding, I can change the name of BID to "binding
index, etc" in the next version.

> 1) On the one hand, the CoAs are not exposed to the transport layer on the
> two hosts, so the transport layer doesn't have the opportunity to assess
> such connection characteristics as congestion, reachability, bandwidth, etc.
> when determining which CoA to use, or whether to use multiple
> CoAs (draft-matsuoka-multilink-transport-requirement-00.txt). An
> example is the MPEG streaming video example I cited in previous email. If
> the transport layer has access to the multiple addresses and information on
> the connection, it can decide whether to send the extra layers to improve
> video quality over a high bandwidth v.s. low bandwidth connection.  Another
> example is SCTP which uses multiple addresses to good advantage, switching
> to a new address if unrecahability develops on the currently active one.

We use this BID only to register multiple CoAs bound to the same
HoA. Therefore, upper layers might not be aware of even multihoming
(multiple bindings). see more below.

> 2) On the other hand, although the BID is halfway to being an endpoint
> identifier, yet there's still the HoA to deal with. Proposals such as MAST
> (draft-crocker-mast-analysis-01.txt) and HIP
> (draft-moskowitz-hip-arch-05.txt) go all the way in this regard and
> introduce endpoint identifiers that are independent of IP addresses and are
> utilized for session identification. The endpoint identifier is visible to
> the transport layer and is used for transport session identification, rather
> than an IP address. They use different approaches - MAST identifiers are
> session specific and negotiated while HIP identifiers are global - but the
> basic architectural idea is the same.

The MN's identifier is still HoA in my draft. After session
establishment with HoA, MN and CN need to select the best BID or use
multiple BIDs for single communication depending on each flow type.

This decision shouldn't be taken only by MIP6, but also other
factors. I know there are several approaches proposed to MIP6WG to use
filter/policy for this decision (I basically agree with them), but
management of these policy/filters is _not_ MIP6 specific
issue. Carrying policy by MIP signaling is not only solution. There
are several ways to manage these policies at end-nodes.

We need to discuss combination of other transport protocols like you
listed, but what MIP6 lacks for multihoming now is multiple CoAs
registration for the same HoA. This draft try to solve the issue.
Even if other approach is taken for multihoming, multiple bindings
registration is still needed at MIP6 layer. 

regards,
ryuji

>             jak
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6