Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies

From: Bernard Aboba <[email-masked]>
Date: Sun, 31 Oct 2004 21:45:14 -0800 (PST)

> There may be some problems related to link layer addresses, etc,
> but someone should really point us to the right documents, or better,
> write a problem statement draft of the situation, trying to clarify
> the current plans of running IPv6 over make-before-break CDMA (and
> other such radio links).  I don't see much use to argue about this
> until we properly understand the details, and at least I can't
> possibly claim understanding them.  I don't even know what documents
> I should read; sorry about my ignorance.

I must admit that I am also finding this conversation hard to follow.

As noted in Multi-Net (see
http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm)
it is quite possible for a single radio and single MAC address to be used
to construct multiple virtual interfaces, each connected to a distinct
network. In this case, DNA would be run on each virtual interface, with no
interactions between them.

It is also possible for a single radio to be used to construct multiple
virtual interfaces, each connected to the same network, as long as
distinct MAC addresses are used on each virtual interface.  Again, in this
case, DNA would be run on each virtual interface with no interactions
between them.

DNA is fundamentally about optimizing the problem of address assignment.
This is quite distinct from the problem of determining the outgoing or
incoming interface for packets, which is a routing problem.

Where the host is multi-homed, routing behavior is determined by whether
the host implements the strong or weak end-system model, the state of the
routing table, the state of Mobile IP (if present) and the dictates of
the application.  The link layer influences this behavior primarily
through its influence on the routing table.

Through constructs such as dial-on-demand or idle timeout, and link-aware
routing, it is possible for the state of one interface to influence
whether packets are routed out another interface.  And of course, link
indications such as "Link Down" can result in removal of routes, and "Link
Up" can result in insertion of routes.  Yet none of these phenomena
introduce the need for link layers to interace with respect to DNA.

Or is there something I'm missing?

---

From: Greg Daley <[email-masked]>
Date: Mon, 01 Nov 2004 16:56:04 +1100

Hi Pekka,

Pekka Nikander wrote:
>>> Purely DNA point of view, it would be better if CDMA doesn't support 
>>> 'make-before-break' at all. It would make DNA much simpler.
>>
>>
>> I know this was a throw-away line, but it's hard to throw away.
>>
>> I think that MBB will have to be supported, in DNA.  This is especially
>> the case where Unreachability is to be determined from certain tests.
>>
>> We mainly need to be clear about which tests are applicable and
>> what inference is taken from received messages.  I think this
>> is still in coverage for the BCP and Goals though.
> 
> 
> I have to admit that I am totally confused now.  Maybe I just
> don't know the facts.  So, let me ask some stupid questions:
> 
> 1. Are people planning to use make-before-break with CDMA
>    with PPP or not?  Or both?  (If PPP is used, I see no
>    problem wrt. DNA as PPP is then the link layer to IPv6,
>    and the situation has to be handled below the IPv6 layer.)

Indeed, PPP simplifies things.

Most cases we'll be looking at situations with PPP in CDMA.

> 2. Assuming no PPP is used, are there any actual plans of
>    supporting make-before-break between networks that actually
>    have different IPv6 configuration at different base stations?
>    (If not, again, I don't see what we have to worry about.)

 From my understanding, Flarion's wireless technology supports
Make-before break and has a multicast capable MAC.

I believe that these (and other?) technologies are contributing to
802.20.  The Flarion white-papers though, describe a combined 
base-station/router.

This simplifies DNA configuration change testing.

I'm not sure about 802.20, it looks like this is a MAC/PHY group,
so it's conceivable that networks may be bridged to 802.20
in the future.

> 3. Assuming no PPP is used and make-before-break is supported
>    between base stations that potentially have different
>    network configuration, is there any reason why the link
>    layer cannot model the situation as two different interfaces?

At the moment, I can't see why not.

It significantly simplifies neighbour resolution, for the case where
the wired network is bridged behind pairs of base-stations.

> That is, even in the case that the CDMA link layer does not use
> PPP but is directly visible to IPv6, if we can model the radio
> layer connections to different base stations as different interfaces,
> as seen by IPv6, I don't see any problem.  The worst that can there
> happen is that the two interfaces, corresponding to the two radio
> layer connections, are connected to the same IPv6 network.  But that
> is a case that we have to handle otherwise, too.
 >

I don't believe there's any ignorance in the matter, but there
are MBB technologies which are multi-access and have different L3
configurations under trial.

The only issue when using different interfaces is that DNA is likely
to be done per-interface, and it may not be possible to get reliable
link-down indications on the 'about to break' interface, even if it's
possible to get link-ups on the 'just made' interface.

Sorry to cause consternation by not thinking through and clarifying
statements.

The problem statement draft is a good idea.

Greg

---

From: Brett Pentland <[email-masked]>
Date: Mon, 01 Nov 2004 18:03:13 +1100

Bernard Aboba wrote:
<snip>
> incoming interface for packets, which is a routing problem.
</snip>

I agree, assuming I'm understanding the point correctly.  DNA is about
detecting, for a given link, which link that is and obtaining an address
that can be used on that link.  It's another process to decide whether
or not to use that link for, say, a default router.

Say a host is connected both a fixed Etherenet (eth0) and a wireless LAN
(wlan0).  DNA might tell the host that wlan0 has just connected to a new
network, and that it can use address X on that network, but it's active
connection on eth0, which is where it's default router currently is, is
unaffected and so it shouldn't change anything.

I think that the decision to not change default router (or to change to
one on wlan0 if DNA on eth0 indicates that it has just gone down), is
not really part of DNA.  Perhaps it should be?  I'm not sure. Any
thoughts?

Brett.

PS.  I realise that I've diverted from the discussion of
make-before-break interfaces, but if the virtual interface abstraction
can be made then I think this all still applies.  This would be a very
useful abstraction too, because if an interface can be connected to two
links simultaneously, then it difficult to say what DNA for that
interface should pass to the routing decision making component.

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 01 Nov 2004 16:48:47 +0900

Dear Pekka

>     and the situation has to be handled below the IPv6 layer.)

I don't know about the plan but your point looks reasonable.  
 
>     (If not, again, I don't see what we have to worry about.)

As Greg wrote, Flarion wireless technology, Flash OFDM, can support 
make-before-break. Right now they are contemplating only v4 but, 
I'd like DNA schemes be future proof.  
 
>     layer cannot model the situation as two different interfaces?

It seems that the link-layer can do that but we need to check it out. 
 
> is a case that we have to handle otherwise, too.

I guess that 'two interface approach' will handle the situation. 

However, I think we need to sort out a few the operational details. 

For example, if we model two link-layer connection as two (virtual) interfaces, 
shall we assign the same link-layer address to two interfaces? That may 
bring forth trouble if it happens that two link-layer connections belong to 
the same link. Though, right now, no problem seems insurmountable but 
we'd better think it over.   

> other such radio links). 

It would be nice. 

Best Regards

JinHyeock

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 01 Nov 2004 10:13:01 +0200

> shall we assign the same link-layer address to two interfaces?

That is a good question, but strictly speaking it is outside
the scope of the DNA WG.  I'm not saying we can't discuss it here,
but if the discussion diverted too much from DNA, it would be
better to move the discussion elsewhere.

--Pekka

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 01 Nov 2004 17:14:39 +0900

Dear Brett

> that can be used on that link.  

I need to point that obtaining an address is outside of DNA scope. 
It's DNA job to determine that a host need a new address. 
However, it's not DNA job to actually obtain a new address.  
We ruled out DAD optimization while DNA chartering. 

> It's another process to decide whether

Agree. 
 
> unaffected and so it shouldn't change anything.

ok except that DNA presenting a new valid address. However, DNA 
may present a valid prefix to form a new address. 

> not really part of DNA.  Perhaps it should be?  I'm not sure. Any

Agree. 

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 01 Nov 2004 17:29:14 +0900

> better to move the discussion elsewhere.
 
Strictly speaking No. This may be under RFC 2461 revision, 'how to 
run IPv6 over make-before-break technologies'. Also I don't want 
too much diversion here but, at least, we need to contemplate how this 
would affect DNA schemes. 

Best Regards

JinHyeock

---

From: Brett Pentland <[email-masked]>
Date: Tue, 02 Nov 2004 10:35:22 +1100

JinHyeock Choi wrote:
<snip>
<snip>
<snip>

Yes, you are correct.  I should have said the DNA could tell the host a 
prefix X on that network from which an address can be formed (and yes, 
testing for uniqueness is outside of DNA).

Cheers,
Brett.