Subject: [Mip6] RE: [Mipshop] fast handover revisions

From: "NJEDJOU Eric FTRD/DMR/REN" <[email-masked]>
Date: Wed, 5 Nov 2003 15:21:27 +0100

Hello folks,

I get one remark on the the FMIPv6 specification update

the specification says what follows:

"The protocol begins when a MN sends RtSolPtr to its access router....
The trigger for sending RtSolPr can emanate from a link-specific event,
such as the promise of better signal strength from another access point
coupled with fading signal quality with the current access point.  Such
events, often broadly called as ``L2 triggers'', are outside the scope
of this document.  Nevertheless, they serve as important events that
invoke the protocol.  For instance, when a ``link up'' indication is
obtained on the new link, the protocol messages (e.g., FNA) can be
immediately transmitted.  Implementations SHOULD make use of such
triggers whenever available."

The big problem with saying that "L2 triggers are out of scope" is that
actually they are out of scope for all the documents that specify
handovers. [FMIP4] is an example. Which implies, it should be let to
implementors to decide how they build their triggers. This unfortunately
will results in implementations that will inter-work very badly, if not
at all. Even if this protocol is going experimental, i think is is still
time for mipshop to give guidances to implementors on what they should
consider as Fast Handoffs initiation/termination L2 triggers. 
Triggers are available in almost every access technlogy. It could
therefore be possible to identify them technology per technology and
then define an abstraction just as what it is being done in DNA Working
Group for instance that has initiated an effort to cataloguing link
hints that can suggest that a Node has just attached/detached from a
network and that can optimise the attachment process in terms of IP
configuration.      
While DNA is looking at Detecting network Attachment, Mipshop could be
focusing on identifying and get a consensus on link triggers that can
optimize the Fast Handoff operation in a couple of radio technologies,
rather than letting this critical issue to the fancy of every
implementator. Unless we really want that specification to rapidly go
experimental and then just forget about.

Comments are welcommed     

Eric Nejdjou
-----Message d'origine-----
De : Rajeev Koodli [mailto:[email-masked]]
Envoye : samedi 11 octobre 2003 04:37
A : [email-masked]; [email-masked]
Objet : [Mipshop] fast handover revisions

Hello folks,

I have made some changes.

- consolidated the network-initiated handover to a Section (3.3) .
    Thanks to Jim Kempf for the suggestion and the text.
- revised the security considerations section as a follow up on my
   previous message. This is mostly re-organizing the original text
   to more clearly outline the considerations and the suggested
   recommendations.

I hope the draft is now ready for the last call! Chairs :-)

I won't be able to participate in the discussions until IETF itself.
I will be away for few weeks.

Best Regards,

-Rajeev

ps: you can download the draft from

http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-08.txt

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

-----Message d'origine-----
De : Rajeev Koodli [mailto:[email-masked]]
Envoye : samedi 11 octobre 2003 04:37
A : [email-masked]; [email-masked]
Objet : [Mipshop] fast handover revisions

Hello folks,

I have made some changes.

- consolidated the network-initiated handover to a Section (3.3) .
    Thanks to Jim Kempf for the suggestion and the text.
- revised the security considerations section as a follow up on my
   previous message. This is mostly re-organizing the original text
   to more clearly outline the considerations and the suggested
   recommendations.

I hope the draft is now ready for the last call! Chairs :-)

I won't be able to participate in the discussions until IETF itself.
I will be away for few weeks.

Best Regards,

-Rajeev

ps: you can download the draft from

http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-08.txt

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

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

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 5 Nov 2003 13:40:52 -0800

FWIW, my understanding of L2 triggers:

1) category "network directed hop":
This is where the network sends some type of message to the MN, that
directs the MN to move and/or tells it that it has moved. I believe this
is how MIPv6 fast handovers typically defines "L2 triggers", although
I'm not so familiar with that material.

2) category "undirected hop":
This is when the MN detects on its own either that it should move to a
different link/channel, or it has already moved. This also includes the
simple "link up" indication, however that indication does not
necessarily indicate movement to a new link. If the link-layer
incorporates the subnet information (for example, there is a draft for
WiFi that recommends using the ESSID for this purpose; CDPD used the
areaGroup color code in the MAC-layer blocks sent to the M-ES/MN by the
cellular base station for this purpose, pre-MIPv6), then the MN at the
link-layer (i.e. in the device driver) will be able to detect link
movement that corresponds to subnet movement, and then can issue the
appropriate L2 trigger to itself, in this case notifying its MN state
machine of a subnet move ("L3 move"). I refer to these types of triggers
as "L2 move" and "L3 move", the "link up" indication corresponding to
"L2 move" because it may be movement back to the same link/subnet, and
"L3 move" indicating a move to a new subnet. I treat NUD indication that
the old default router is no longer reachable as a L3 move.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of NJEDJOU Eric FTRD/DMR/REN
> Sent: Wednesday, November 05, 2003 6:21 AM
> To: Rajeev Koodli; [email-masked]; [email-masked]
> Subject: [Mip6] RE: [Mipshop] fast handover revisions
> 
> 
> Hello folks,
> 
> "The protocol begins when a MN sends RtSolPtr to its access 
> router.... The trigger for sending RtSolPr can emanate from a 
> link-specific event, such as the promise of better signal 
> strength from another access point coupled with fading signal 
> quality with the current access point.  Such events, often 
> broadly called as ``L2 triggers'', are outside the scope of 
> this document.  Nevertheless, they serve as important events 
> that invoke the protocol.  For instance, when a ``link up'' 
> indication is obtained on the new link, the protocol messages 
> (e.g., FNA) can be immediately transmitted.  Implementations 
> SHOULD make use of such triggers whenever available."
> 
> The big problem with saying that "L2 triggers are out of 
> scope" is that actually they are out of scope for all the 
> documents that specify handovers. [FMIP4] is an example. 
> Which implies, it should be let to implementors to decide how 
> they build their triggers. This unfortunately will results in 
> implementations that will inter-work very badly, if not at 
> all. Even if this protocol is going experimental, i think is 
> is still time for mipshop to give guidances to implementors 
> on what they should consider as Fast Handoffs 
> initiation/termination L2 triggers. 
> Triggers are available in almost every access technlogy. It 
> could therefore be possible to identify them technology per 
> technology and then define an abstraction just as what it is 
> being done in DNA Working Group for instance that has 
> initiated an effort to cataloguing link hints that can 
> suggest that a Node has just attached/detached from a network 
> and that can optimise the attachment process in terms of IP
> configuration.      
> While DNA is looking at Detecting network Attachment, Mipshop 
> could be focusing on identifying and get a consensus on link 
> triggers that can optimize the Fast Handoff operation in a 
> couple of radio technologies, rather than letting this 
> critical issue to the fancy of every implementator. Unless we 
> really want that specification to rapidly go experimental and 
> then just forget about.
> 
> Comments are welcommed     
> 
> Eric Nejdjou
> I won't be able to participate in the discussions until IETF 
> itself. I will be away for few weeks.
> 
> Best Regards,
> 
> -Rajeev
> 
> I won't be able to participate in the discussions until IETF 
> itself. I will be away for few weeks.
> 
> Best Regards,
> 
> -Rajeev
> 

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 5 Nov 2003 13:57:14 -0800

BTW, RA beacons per Eager Cell Switching is another example of a L2
trigger, in this case the MN receiving a RA from a new router indicates
a "L3 move".

- Ed

---

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Nov 2003 11:35:41 -0800

Hi Eric,

the issue of link triggers has come up more than once
before, and we have arrived at a conclusion where the
protocol itself does not define these. The primary reason is
it is too link-specific that a generic abstraction would
only serve the purpose of an API (which belongs to a
separate space).

While I agree that some  guidelines could help, perhaps
one could put them together in a separate ID if there is interest.

Thank you for your comment.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Nov 2003 11:40:38 -0800

Hi Ed,

the fast handover draft allows both categories below.
Category 1) is network-initiated handover and 2) is
MN-initiated.

Regarding movement detection in 2) below, the fast
handovers allows a MN to build [AP-ID, AR-info] tuple
ahead of handover. So, when the link-up indicates a new
AP-ID, the MN can determine if there is a new AR behind
it.

-Rajeev