Subject: [Mobopts] RG last call

From: Rajeev Koodli <[email-masked]>
Date: Tue, 03 Oct 2006 09:26:13 -0700

Folks,

This is the last call for comments on

draft-irtf-mobopts-l2-abstractions-01.txt

The last call expires on October 20, 06.

Please provide your input by then.

Thanks,

-Rajeev

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

---

From: Christian Vogt <[email-masked]>
Date: Mon, 09 Oct 2006 08:49:33 +0200

Hi authors,

cross-layer interaction between L2 and L3 is an important topic given
the increasing use of mobility and multi-homing across heterogeneous
networks.  I think it is good that you are working on this.

OTOH, I do concur with the observation recently raised on the ML that
there is an obvious overlap between your work and the ongoing work of
the IEEE 802.21 working group.  (IEEE 802.21 is working on the topic in
a broader context.  E.g., it also considers over-the-network events,
commands, and information retrieval.)  I won't further comment an any
potential conflicts between your work and the work of IEEE 802.21, but
do state my personal opinion that the two proposals should be harmonized
and possibly merged.

Architectural differences compared to IEEE 802.21

- Your proposal does not strictly differentiate between events,
commands, and information retrieval services, as the IEEE 802.21 work
does.  (I recognize that you are using different "types" of primitives,
but nonetheless.)  It may be of benefit if you stated at some place in
the beginning of the draft that you don't make/need this
differentiation.  It's one of the main architectural differences between
your work and the IEEE 802.21 work.

- You may also want to mention in the very beginning that your approach
does not use an intermediate shim layer through which primitives are
exchanged.  This is another architectural difference between your work
and the IEEE 802.21 work, which defines an MIH function between L2 and L3.

Section 2, Terminology.

- You should do without the definition of "peer" IMO; use "point of
attachment" or "attachment point" instead.  "Peer" has a widely accepted
end-to-end meaning, where a peer of node X is another node Y with which
X communicates at application layer.  Defining the peer to be an access
point may be confusing.

Section 3, Primitives for L2 Abstractions

- The draft defines a Confirm primitive to be the reply for a Request
primitive, and the Response primitive to be the reply for an Indication
primitive.  Intuitively, I would have matched Request with Response, and
Indication with Confirm, in which case figure 1 would look like this:

        ------------------------------------------------------
                  Request                    Confirm
                    ||      /\          /\      ||
        Layer N     ||      ||          ||      ||
        ------------||------||----------||------||------------
                    ||      ||          ||      ||
                    \/      ||          ||      \/
        Layer N-m        Response   Indication
        ------------------------------------------------------

- You define Protocol Layer ID and Protocol ID fields to be included in
all primitives.  Are these fields really necessary?  After all, the
primitives are delivered directly from a protocol instance at one layer
to a protocol instance at another layer, so what is the purpose of
having the destination field?  The primitives are not relayed or
distributed anywhere where the destination fields might have to be
consulted, as they would by an intermediate shim like like the MIH
function in IEEE 802.21.

Section 4.7, L2-LinkGoingDown (Type 2)

- The text in this section describes the registration process for the
Link Going Down event:

>                                    In the registration processing, the
>    L2-LinkGoingDown.request primitive carries the "Network Interface ID"
>    parameter and the "Enable/Disable" parameter.

According to section 3, /all/ type 2 primitives use registration, but
the registration process is explained only here.  I'd therefore
recommend to move the above text to the beginning of the section, and
generalize it so that it becomes applicable to all type 2 primitives.

- It is not clear whether a protocol interested in a type 2 primitive
must re-register for the primitive after it has received the primitive
once.  E.g., if a movement detection daemon on a mobile node registers
for the Link Going Down primitive and eventually receives one such
primitive, does it have to register again in order to receive a Link
Going Down primitive for the next handoff?

Section 6.2, Condition

- You may want to state that the conditions provided should be limited
to those which do not change rapidly for other reasons than the behavior
of the node implementing L2 abstractions.  E.g., another interesting
link condition might be the access latency for the medium.  But the
access latency may be a function of the number of other nodes competing
for bandwidth, and hence is a very dynamic condition even if the node
implementing L2 abstractions does not move and does not change
communications patterns.  It may hence be difficult to implement another
"access latency" link condition.

Section 7, Architectural Considerations

>    [4]   Upper layers should utilize a timely recovery step so as to
>          limit the potential damage from link indications determined to
>          be invalid after they have been acted on.
> 
>          The proposed L3-driven handover described in Appendix D uses
>          the L2-LinkGoingDown indication as the trigger for starting
>          handover.  L2-LinkGoingDown is indicated when the link quality
>          goes down below the specific threshold.  This indication is not
>          canceled even if the link quality goes up soon.  As described
>          above, L2-LinkStatus can be used to detect the most suitable
>          AP.  The IP layer can cancel a handover if it finds that the
>          current AP is the most suitable one by using L2-LinkStatus when
>          L2-LingGoingDown is notified.

You could avoid possible issues with anticipatory indications if you
replaced the Link Going Down indication (which is the only anticipatory
indication in your draft) by periodic or on-demand link status reports
which notify an interested upper-layer protocol of link status changes.
 The upper-layer protocol can then make its own projections about when
the current link attachment will go down due to decreasing signal quality.

(Note that an additional use case for the similar Link Going Down
indication in IEEE 802.21 is for the network to warn a mobile node about
a forthcoming shutdown of a base station.  You don't define
over-the-network indications in your draft, so you may not actually
depend on the Link Going Down indication.)

>    [8]   Proposals should avoid race conditions, which can occur where
>          link indications are utilized directly by multiple layers of
>          the stack.
> 
>          Since our proposal defines the link indications to only the IP
>          layer, race conditions between multiple layers never happen.

But there may be race conditions between protocols on the same layer.
Take, e.g., Mobile IPv6 and Stateless Address Autoconfiguration.  If
Mobile IPv6 tries to register a new care-of address once it receives
a Link Up indication, Stateless Address Autoconfiguration may not yet
have such a new care-of address configured.  The configuration of a new
care-of address further depends on router and prefix discovery, which
may also be triggered by the same Link Up indication.  So there are
plenty of race conditions, and all of them are within the IP layer.

So far, so good.

Best regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 09 Oct 2006 08:36:59 -0700

Hi Christian,

Thanks for your input. I am sure the authors will find them worthwhile.

I wanted to mention that we as an RG here should focus on the technical
content rather than worrying about the "overlap" with 802.21.
As I have mentioned previously, we should view this as a comprehensive
investigation of L2 and L3 interactions in handovers and not necessarily as
a study of 802.21. As was pointed out earlier in the ML, the authors could
look into the gap between the primitives here and what 802.21 has defined.

So, let's keep the focus on what this ID talks about in perspective. And,
thank you for your other detailed comments.

-Rajeev

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 20 Oct 2006 11:17:38 +0300 (EEST)

Hi all,

I promised Rajeev to give a review of the draft, so here goes.

In overall, I liked the document. Yet, I would remove all the sections 
(Appendix B.3 and D) that discuss the experiments, since those are 
difficult to verify, and do not really provide any important information, 
just that the scheme seems to work in some use case.

Some more detailed comments:

- Section 3 does not really discuss the Response primitive. In general, 
  what is the use of the Response? Why would L3 really need to acknowledge
  an asynchronous Indication from L2?

- Section 4: 

  * is the proposal only for so-called Managed Mode (AP mode) 
    link layers? How would this be applicable to ad-hoc or mesh radios? 
    E.g., would L2-PeerList provide info about only L2 APs, but also other 
    terminals? Would L2-LinkUp/Down tell which links to other ad-hoc nodes 
    are up/down?

  * How do channels come into play? Does the L2-PeerList allow getting 
    peers on different channels? Can L3 somehow control the use of 
    channels?

  * After reading the whole spec, you actually later talk about quality of 
    the signal in relation to the L2-PeerFound, i.e., only certain peers 
    are told about to L3. That is not mentioned in Section 4.

  * Related to the above, and other requests, would there be a need to 
    define some filters about which notifications are of interest? E.g. 
    the above, a peer is announced only if the quality of the link to the 
    peer is of some relative quality.

  * L2-PeerLost: provide info about which peers disappeared, but since 
    when? Does L2 e.g. send a notification every second, and tell which 
    peers disappeared within the past second? Or everytime there is even a
    one peer change in the list?

  * Is there any need to add some kind of security awareness to the 
    primitives, i.e., is the link secure or not (how secure?)? E.g., to 
    the link status primitive, or to a filter associated to the PeerFound?

- Section 6.2 Condition: should the SNR be also provided? What is this 
  "available bandwidth? If we talk about 802.11, if the link layer says I 
   have full 54 Mbps connectivity, everybody knows that is about half the 
   actual bandwidth I get for my IP packets.

- Section 7:
  * [2]: As above, why is the Response needed in the first place?
  * [5]: You don't need congestion control in the transport, but you 
         surely need rate limitation for how often indications are sent 
         from L2 to L3.

- Appendix A, p.20, 2nd sentence: I think the L2 and L3 are mixed: "L2 
  handover begins after the L2 sends L2-LinkConnect.confirm to the L3."

- C.4: "is got lost"

- C.6: "...frame to the AP, or the" > "...frame to the AP, and the" ?

- C.7: "...and becomes under" > "...and falls unders"?

Hope these comments help.

Regards,
Jukka

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Oct 2006 11:07:10 -0700

Thanks Jukka.

A brief comment about the experiments: being an RG, we need exposure to
them. So, we should include them appropriately, such as in an Appendix. But,
I also agree that the system description has to be adequately provided so
that folks know what to expect.

Regards,

-Rajeev

---

From: Koshiro MITSUYA <[email-masked]>
Date: Mon, 23 Oct 2006 14:59:02 +0900

Hi Christian,

Thank you very much for your detailed comments.
I am sorry for my delayed reply.

Please find my comments inline:

> networks.  I think it is good that you are working on this.

Thanks.

> do state my personal opinion that the two proposals should be  

I agree that two proposals should be harmonized.
We are looking forward how we can process that.

> your work and the IEEE 802.21 work.

Right.
Our approach works fine for simple handover scenarios (e.g. same  
domain, same network access), but we may need more information for a  
complex handover scenarios (e.g. inter domain, mixed network  
access).  I am not sure now.  So we need to discuss how much impact  
the difference has.

> and the IEEE 802.21 work, which defines an MIH function between L2  

Right.
We would like to have something works with the current deployed  
wireless networks.
We do not want to add new entities in the network.

> X communicates at application layer.  Defining the peer to be an  

OK, I agree to use another world.

> Indication with Confirm, in which case figure 1 would look like this:

Agree.  less confusing.

> consulted, as they would by an intermediate shim like like the MIH

We are thinking that the messages are exchanged between layers by  
using e.g. routing socket.   It is an information method in which lll  
entities can hear all message.  The protocol layer ID is used to  
filter unnecessary message, for example.

> generalize it so that it becomes applicable to all type 2 primitives.

I agree.

> Going Down primitive for the next handoff?

Such re-registration is not necessary.  I will make it clear in the  
draft.

> "access latency" link condition.

Right.  Do you think the state is needed to be more clear?

> depend on the Link Going Down indication.)

Sorry, I do not see your point.

> plenty of race conditions, and all of them are within the IP layer.

Hum..  You are right.  I will change the text.

Thank you very much again,
Koshiro

---

From: Christian Vogt <[email-masked]>
Date: Tue, 24 Oct 2006 01:11:19 +0200

Hi Koshiro.

Two follow-ups below.

<snip>

> Right.  Do you think the state is needed to be more clear?

Yes, you could state this more clearly.  There is a similar statement in 
the IEEE 802.21 specification which is that the information provided by 
Media Independent Information Services is relatively stable and does not 
change often.  See section 6.3.3, Information Service Elements, of 
version 1.09 of the IEEE 802.21 specification.

> Sorry, I do not see your point.

The Link Going Down indication in IEEE 802.21 is not only used in local 
cross-layer signaling within a mobile node, but also between the mobile 
node and the network.  This is why IEEE 802.21 requires the Link Going 
Down indication.

But in your case, you do not specify any signaling between a mobile node 
and the network.  So you could replace the Link Going Down indication by 
periodic or on-demand link status reports which notify an interested 
upper-layer protocol of link status changes.  The advantage of this 
would be that you eliminate the single anticipatory indication in your 
proposal.

In contrast to Link Going Down indications, simple link status reports 
don't suggest anything to the mobile node about when to do the next 
handoff.  So they are not anticipatory.  It is then the responsibility 
of the upper-layer protocol do decide when to switch to a different link.

<snip>

Hope this helps.

- Christian

---

From: Koshiro MITSUYA <[email-masked]>
Date: Tue, 31 Oct 2006 16:01:15 +0900

Hi Jukka,

I am sorry for the delayed reply.
Please find my comment inline:

> I promised Rajeev to give a review of the draft, so here goes.

Thank you!

> just that the scheme seems to work in some use case.

We thought these appendixes will help reader to understand our proposal.
However, I agree with you.  I will remove.

>   an asynchronous Indication from L2?

I do not see any strong reason now, but I would keep the Response for  
future usage.

One of our architectural feature is that all message (command and  
indication) go
through the same inter-layer communication method.  It is possible to  
e.g.
accept the handover command after receiving the response of ToBeDown  
indication.

>     terminals? Would L2-LinkUp/Down tell which links to other ad- 

Some primitives may work on ad-hoc mode.  However, ad-hoc mode or
mesh is out of scope so far.  If WG requests, we can work on the study.

>     peers on different channels? Can L3 somehow control the use of

Yes, L2-PeerList allow to get peers on different channels.
However, L3-* do not need to play with channels.
L3 specify a Peer, and L2 understand which channel the Peer is using.

>     are told about to L3. That is not mentioned in Section 4.

Sorry, I don't see your point.

>     peer is of some relative quality.

Same here.  Could you explain explain more?

>     one peer change in the list?

We assume that L2 creates and maintains a list of APs when it  
performs scanning.
When It performs scanning again, the comparing is performed and a  
notification
is sent if needed.  The timing of scanning is  implementation issues.

>     the link status primitive, or to a filter associated to the  

I would hear the WG voice :)

>    actual bandwidth I get for my IP packets.

It is out of scope in our spec.
Such information is very useful for transport or application,
but not so useful for L3.

>   * [2]: As above, why is the Response needed in the first place?

see above.

>          surely need rate limitation for how often indications are  

Good point.   I will add a text to mention this.

> - C.7: "...and becomes under" > "...and falls unders"?

Thank you.   I will fix them!

regards,
Koshiro

---

From: Koshiro MITSUYA <[email-masked]>
Date: Tue, 31 Oct 2006 16:15:51 +0900

Hi Christian,

Thank you for you reply.

[snip]

> Yes, you could state this more clearly.  There is a similar  
> statement in the IEEE 802.21 specification which is that the  
> information provided by Media Independent Information Services is  
> relatively stable and does not change often.  See section 6.3.3,  
> Information Service Elements, of version 1.09 of the IEEE 802.21  
> specification.

OK.  Thank you for the information.

> The Link Going Down indication in IEEE 802.21 is not only used in  
> local cross-layer signaling within a mobile node, but also between  
> the mobile node and the network.  This is why IEEE 802.21 requires  
> the Link Going Down indication.
>
> But in your case, you do not specify any signaling between a mobile  
> node and the network.  So you could replace the Link Going Down  
> indication by periodic or on-demand link status reports which  
> notify an interested upper-layer protocol of link status changes.   
> The advantage of this would be that you eliminate the single  
> anticipatory indication in your proposal.
>
> In contrast to Link Going Down indications, simple link status  
> reports don't suggest anything to the mobile node about when to do  
> the next handoff.  So they are not anticipatory.  It is then the  
> responsibility of the upper-layer protocol do decide when to switch  
> to a different link.
>

OK, I see you point.
We have such on-demand link status report by L2-LinkStatus.
And the LinkGoingDown is also needed to let several entities behave  
in the same way.

regards,
Koshiro