Subject: RE: [Mipshop] new charter

From: [email-masked]
Date: Mon, 10 Oct 2005 16:14:59 -0500

Alex,
in general I would like to avoid repeating on the MIPSHOP ml the whole 802.21 discussion, e.g. why 802.21 is needed. 

> -----Original Message-----
> From: ext Alexandru Petrescu [mailto:[email-masked]]
> Sent: Monday, October 10, 2005 15:40
> To: Faccin Stefano (Nokia-NRC/Dallas)
> Cc: Alexandru Petrescu; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Mipshop] new charter
> 
> 
> [email-masked] wrote:
> 
> > Alex, logically 802.21 is indeed "below" IP. However, for certain 
> > scenarios IEEE 802.21 has identified the need to transport 802.21 
> > specific information "above" IP (e.g. for deployment where the L2 
> > technology is not enhanced to support 802.21 either because the 
> > standard is not ready or because the operator has decided to adopt 
> > 802.21 "above" L3), and from that the work in MIPSHOP.
> 
> Stefano, thank you for the explanation.
> 
> The other example where link-layer data is present in IP messages is
> probably IPv6 RA/NAs containing 48bit MAC addresses.  I wonder whether
> there's any other example of including l2 information in IP messages,
> more than just l2 addresses.  I don't think there's any.
I think the example you provide is rather different. What we are proposing is to develop a solution for IS that can carry a set of information to the terminal. The information is just a payload for the IP protocol, and can contain L2, L3 and even above L3 information, based on how the IS is being defined in 802.21.

> It may also be possible that IPv6 RS/RA could probably solve 
> many issues
> that are considered as problems by 802.21.
During the studies performed when 802.21 was a study group, this was discussed and the conclusion was that we need 802.21. 

> For example the operator load balancing aspects mentioned in the other
> mail, where an operator tries to hand over a terminal from a 
> network to
> another.  That's a meaningful use case.  Maybe it's 
> sufficient for that
> operator to dynamically modify preferences in the RAs beaconed by the
> AP/ARs so that the terminal automatically switches from one 
> to another.
Modifying information dynamically (to the point you suggest) for the AP beacons works only if you make strong assumptions. also, I would leave such discussions on what we can do at L2 to IEEE. 

As for the dynamic info in RAs, what you say is true if you assume terminals that can operate with multiple radios active at the same time on a continuous basis. That assumption is and will not be realistic for a while, since in the future there will be still several terminals that can utilize only one radio technology at a time. Also, as indicated in some use cases used by 802.21 as examples, some terminals may switch off one of the radio interfaces and rely on 802.21 services over the active interface to discover information about other accesses and to decide when to handoff.

Finally, even by modifying the content of beacon and AR, there is still no certainty that the terminal would perform the handoff as needed by the network. Since network operators wants to be in tight control, they surely don't want to rely on the terminal for the decision. There is also the risk that many other terminals (all those hearing the same beacon/RA) may move all together to the new access, in which case load sharing fails. 

In conclusion, the scenarios behind network controlled handoff are such that you don't want to rely on the terminal to make the final decision if the operator wants to control the handoff.

> This would need a protocol between the Access Routers or the Access
> Points to synchronously trigger this change.  The protocol to do that
> could be SNMP.  The logic to decide when a network is too 
> loaded and the
> other too less loaded could be some new software that does not need
> standardization, nor message exchange, centralized, and whose 
> complexity
> is too high anyways.
> 
> Just some thoughts.
Sure, but you make architectural assumptions that are not necessarily realistic (e.g. SNMP between AR and AP). I'd leave the discussion on 802 architecture to 802.

> Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 10 Oct 2005 23:51:06 +0200

[email-masked] wrote:

> Alex, in general I would like to avoid repeating on the MIPSHOP ml 
> the whole 802.21 discussion, e.g. why 802.21 is needed.

Stefano, I am not questioning why the 802.21 is needed.  Just trying to
pinpoint what mipshop can do for 802.21 and vice-versa.  I am probably
steering waters in a settled zone, so I'll have to resume to standby
mode soon.

>> The other example where link-layer data is present in IP messages 
>> is probably IPv6 RA/NAs containing 48bit MAC addresses.  I wonder 
>> whether there's any other example of including l2 information in IP
>>  messages, more than just l2 addresses.  I don't think there's any.
>> 
>> 
>> 
> 
> I think the example you provide is rather different. What we are 
> proposing is to develop a solution for IS that can carry a set of 
> information to the terminal. The information is just a payload for 
> the IP protocol, and can contain L2, L3 and even above L3 
> information, based on how the IS is being defined in 802.21.

One should know what that information is exactly, before knowing how to
encode it.  It's useless to define generic encodings if one doesn't know
what's it.  If we need an encoding that's as generic as possible then
again, use XML; that's self-described.

Is the IS information IPv4 addresses?  IPv6 addresses?  ESSID's?
Arbitrary-length text strings?  Max length?  Power signals?  What's the
range of the power signals and measurement unit?

Once the information to be encoded is precisely known, the encoding can
be easily done, efficiently, extensibly.

>> It may also be possible that IPv6 RS/RA could probably solve many 
>> issues that are considered as problems by 802.21.
> 
> During the studies performed when 802.21 was a study group, this was 
> discussed and the conclusion was that we need 802.21.

Great.  I don't question the motivation of 802.21 itself.

>> For example the operator load balancing aspects mentioned in the 
>> other mail, where an operator tries to hand over a terminal from a 
>> network to another.  That's a meaningful use case.  Maybe it's 
>> sufficient for that operator to dynamically modify preferences in 
>> the RAs beaconed by the AP/ARs so that the terminal automatically 
>> switches from one to another.
> 
> Modifying information dynamically (to the point you suggest) for the 
> AP beacons works only if you make strong assumptions. also, I would 
> leave such discussions on what we can do at L2 to IEEE.

Yes, I do make the strong assumption that the AP sends IPv6 RAs.  Which
part of this assumption doesn't fit the 802.21 view?  I am not making
assumptions about the IEEE L2 AP "beacons", but about the IPv6 RA.

> As for the dynamic info in RAs, what you say is true if you assume 
> terminals that can operate with multiple radios active at the same 
> time on a continuous basis.

No no, I'm making the assumption that the terminal has a unique 802.21
interface that it uses to connect to a 3GPP network and to an 802.11b
AP.  Is this assumption false?

> That assumption is and will not be realistic for a while, since in 
> the future there will be still several terminals that can utilize 
> only one radio technology at a time. Also, as indicated in some use 
> cases used by 802.21 as examples, some terminals may switch off one 
> of the radio interfaces and rely on 802.21 services over the active 
> interface to discover information about other accesses and to decide
>  when to handoff.

Ok.

> Finally, even by modifying the content of beacon and AR, there is 
> still no certainty that the terminal would perform the handoff as 
> needed by the network.

Well, yes, there is.  RFC2461 suggests just that.  The terminal should
use the default route of a certain RA among the ones it receives based
on information on that RA.

Also, terminals are free to choose less-preferred RAs based on some
logic they're free to implement.  If all terminals are under same
operator's control then this should work.

> Since network operators wants to be in tight control, they surely 
> don't want to rely on the terminal for the decision. There is also 
> the risk that many other terminals (all those hearing the same 
> beacon/RA) may move all together to the new access, in which case 
> load sharing fails.

I agree, this is a weak point.

Then, instead of using RS/RA, one may use DHCPv6, where there's a
specific DHCP message sent from a server instructing it to re-request
subnet info, in which case the DHCP Server could re-direct the terminal
to another Server, probably.

> In conclusion, the scenarios behind network controlled handoff are 
> such that you don't want to rely on the terminal to make the final 
> decision if the operator wants to control the handoff.

Right, and it may be noticed that this is a significant departure from a
certain IP perspective in general, and from FMIPv6 in particular where
the terminal controls almost everything.

>>  Points to synchronously trigger this change.  The protocol to do 
>> that could be SNMP.  The logic to decide when a network is too 
>> loaded and the other too less loaded could be some new software 
>> that does not need standardization, nor message exchange, 
>> centralized, and whose complexity is too high anyways.
>> 
>> Just some thoughts.
> 
> Sure, but you make architectural assumptions that are not necessarily
>  realistic (e.g. SNMP between AR and AP). I'd leave the discussion on
>  802 architecture to 802.

I made the assumption of SNMP between a unique central control point and
all the APs and ARs under that operator's control.  This is not
unrealistic, but I won't struggle to sell it either :-)

Alex