Subject: [DNA] Revised dna-link-info I-D

From: Alper Yegin <[email-masked]>
Date: Mon, 18 Jul 2005 12:03:17 -0700

Folks,

I've had submitted the revised version of the dna-link-info I-D 10 days
ago, but it hasn't showed up on the IETF repository yet. For that,
please see a copy of the I-D at the following location:

http://yegin.org/IETF/draft-ietf-dna-link-information-02.txt

The major changes in this revision include:

- New text for IEEE 802.3.
- Handling multiple 3GPP PDP Contexts.

I'd like to take your attention to the changes we needed to make in
order to accommodate nondeterministic L2 events on Ethernet (e.g., link
is up but the host the network may block data transmission). Please read
Section 2 and the entire 2.4 to see the details.

Please review and comment before the Paris meeting.

Alper

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 19 Jul 2005 10:14:54 +0900

Dear DNA WG

We have updated FRD (Fast Router Discovery) I-D and submitted it. 

This draft presents a quick RA acquisition scheme with the support 
of a link-layer entity, PoA (Point of Attachment). PoA is either 
802.11 AP or 802.16 BS. 

Upon a new network attachment, a PoA can either trigger a router 
to immediately send an unicast RA ("RA Triggering") or deliver 
such an RA for itself ("RA Proxying").   

We may put 'RA Triggering' or 'RA Proxying' functionality on 
a PoA to get the optimized result. 

Main changes from the previous versions are 
 - We expanded the result to other wireless-link technologies. 
   We added IEEE 802.16. part.   
 - We added RA Triggering part so the scheme doesn't depend 
   solely on "RA Caching" any longer. 
 - We incorporated the IEEE 802.21 (Media Independent Handover) 
   results to realize "RA Triggering" and "RA Proxying" 

The draft doesn't show up on the repository yet but is available at 

http://www.diffeo.com/drafts/draft-jinchoi-dna-frd-01.txt

Your feedback will be appreciated. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock Choi

p.s. 
We implemented a scheme in 802.11 AP and measured DNA delay. 
Roughly it takes 1-2 ms for a host to get an RA after L2 association 
is made. More detailed report later.

---

From: Brett Pentland <[email-masked]>
Date: Tue, 19 Jul 2005 16:14:36 +1000

Hi JinHyeock,

I just read over your update and have a few observations.

I see you now have triggering as well as caching.  Triggering seems
to make good sense when the AR and Point of Attachment (PoA) are
co-located, but when they are not it seems that you are just
reinventing RS/RA.  Compared to the host initiating the RS, you
save one store-and-forward time in the PoA, but that doesn't seem
like much of a saving for a new protocol.

For RA Proxying you have a new option for getting the cached RA,
but what do you do if there's more than one router on the link?
Should the PoA cache and forward multiple RAs?  If not, then the
host may have incomplete information.  It may not have all of the
prefixes available on the link, and it won't have a complete list
of potential default routers. To get this additional information
it will need to send an RS in order to receive the RAs from all
of the routers on the link.  You end up adding an RA to the overall
process though admittedly you get that first RA very quickly.

Cheers,
Brett.

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 20 Jul 2005 11:14:55 +0900

Dear Brett

Thanks for your comments. 

> like much of a saving for a new protocol.

Triggering is mostly aimed for the case of AR & PoA in one box.
In that case, I see few reason for PoA to proxy an RA. But I think 
that "Triggering" can be even of help in the other case. Right now, 
we're contemplating a scheme which I will present when completed.

> process though admittedly you get that first RA very quickly.

I don't understand your point. DNA solution is supposed to do 
its job with a single RA message. Allow me to quote from DNA
 design team document, 

                                   It was felt that by crafting the
   information in the solicitation and advertisement, a single RS/RA
   exchange should be sufficient for DNA.

So in DNA point of view, I see no problem sending just one RA 
(optimized for DNA).

Best Regards

JinHyeock

---

From: Alper Yegin <[email-masked]>
Date: Tue, 19 Jul 2005 21:43:17 -0700

Hi JinHyeock,

Here are couple of comments and questions on the FRD scheme...

- "Triggered RA" has dependency on an additional protocol between the AP
and AR. I see now that there are some discussions around that, stemming
from the IEEE 802.21 work. I had a draft on such a protocol a while back
(http://www.watersprings.org/pub/id/draft-yegin-l2-triggers-01.txt)
FYI...

- Have you analyzed what happens when you bypass the "random delay"
mechanisms? They are there for congestion avoidance. 

Thanks,

Alper

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of JinHyeock Choi
> Sent: Monday, July 18, 2005 6:15 PM
> To: Greg Daley
> Cc: [email-masked]
> Subject: [DNA] Revised FRD (Fast Router Discovery) I-D
> 
> Dear DNA WG
>

---

From: Brett Pentland <[email-masked]>
Date: Wed, 20 Jul 2005 17:22:58 +1000

Hi JinHyeock,

> So in DNA point of view, I see no problem sending just one RA 

You've answered my question in your email to Tero - only the most
recent RA is cached (and it will change frequently if there are
multiple routers on the link).

You are right that DNA only needs a single RA, and a decision about
configuration can be made immediately after that RA, but router
discovery may require more than that.  Section 6.3.7 of RFC 2461
notes that unsolicited RAs may be incomplete and that upon reception
of one before having sent an RS, that the host SHOULD send an RS.
Thus we end up with an RS and its associated RAs, plus the additional
original unsolicited RA.

This doesn't affect the speed of DNA but does add to the total packet
exchange.

Brett.

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 21 Jul 2005 17:19:36 +0900

Dear Alper

> (http://www.watersprings.org/pub/id/draft-yegin-l2-triggers-01.txt)

Thanks for pointing our useful doc. I'll look it over. 

> mechanisms? They are there for congestion avoidance.

For router side, FRD doesn't say anything about the random delay 
for routers. It's ok for FRD if routers perform random delay as before.  

For PoA side, it will not cause a problem, if we bypass random delay
for PoA. As of my understanding, random delay is to avoid conflict 
which may occur when two routers happen to send an RA at the 
same time. 

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 21 Jul 2005 18:19:24 +0900

Dear Brett

> multiple routers on the link).

Yes, but we may modify this in the next version. PoA may cache 
multiple RAs and send them all. 

> discovery may require more than that.  

I assume that an RA optimized for DNA would include all the information 
that is necessary for a new IP configuration.  

> Section 6.3.7 of RFC 2461

I didn't recognize this yet. Thanks for your pointing this out. 
We may need to relax the condition a little. 

> This doesn't affect the speed of DNA but does add to the total packet

ok. There will be one more RA. 

Thanks for your kind consideration. 

Best Regards

JinHyeock

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 28 Jul 2005 17:59:03 +0530

Hi Brett,

I am replying little late :)

> like much of a saving for a new protocol.

We have implemented the sending RS from AP while an MN is associating
with it and found that the RA comes at MN faster than the cached RA
sent from AP.  We have surprised with these results. It took ~700 micro 
seconds  (0.7 ms) for an RA to reach MN from the completion of association.
And it is very easy to implement.

We were sending RA from the Router kernel to MN MAC. We are sending RA
from the router without random delay as AP sends unicast RS with TSLLAO 
option.

A host can also send an RS but it may need to employ a some logic to avoid
random delay.

-Syam

---

From: Brett Pentland <[email-masked]>
Date: Fri, 29 Jul 2005 09:11:21 +1000

Hi Syam,

> And it is very easy to implement.

I don't quite understand this.  How can sending an RS to the AR, getting
back an RA and then forwarding that RA to the MN be faster than just
forwarding a cached RA?  How much faster is it than the MN soliciting
itself?

> A host can also send an RS but it may need to employ a some logic to avoid

Surely the same logic is needed for the AP or there would be collisions
if there are multiple routers on the link.

Cheers,
Brett.

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 29 Jul 2005 09:39:40 +0900

Dear Brett

> forwarding a cached RA? 

We also have difficulty understanding this. But our guess is that 
the processing inside a box takes more time than we anticipated. 

> How much faster is it than the MN soliciting
> itself?

Main difference between MN soliciting and AP soliciting is that, 
with the latter, we can realize a scheme (similar to Hash based 
FastRA) in a simpler way. 

We can assume that an AP knows all the ARs in a link. 
So AP can send UNICAST RS (to remove random delay) 
and solicit ARs in turns (for load balancing). 

When a new host is attached to the AP, 
AP can sends an unicast RS to a chosen AR 
1) with unspecified source address 
2) with the host's MAC address in TSLLAO. 

Upon receiving the unicast RS,  
the AR can send an RA immediately 
(because it is solicited in unicast).
in unicast (using TSLLAO)  

Also AP take turns to solicit ARs, 
such as this time AR1 next time AR2 
to achieve load balancing. 

Hence no load balancing mechanism is needed 
in ARs. 

> if there are multiple routers on the link.

Yes, AP needs some logic (but simpler one, in my opinion) and 
for hosts and routers, only TSLLAO is needed. 
Other than that there is nothing to change in them.  

How do you think of it? 

Best Regards

JinHyeock