RE: [Mipshop] new charter
Colleagues,
Regarding L2 addressing/identity info, how it is useful and how it
is/will be used in L3 control/routing messages (mentioned below), that
is an important topic. I would encourage additional discussion and
proposals on that topic. RFC 2461 is referred to below and is a good
context to use in the discussion.
Regarding the format of the MIIS payload, 802.21 is discussing it hotly.
XML/RDF has been proposed as one of the choices.
Best Regards,
Michael Williams IEEEE 802.21 WG VC
-----Original Message-----
From: mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org] On
Behalf Of ext Alexandru Petrescu
Sent: Monday, October 10, 2005 2:51 PM
To: Faccin Stefano (Nokia-NRC/Dallas)
Cc: mipshop@ietf.org; Kempf@docomolabs-usa.com;
gabriel_montenegro_2000@yahoo.com; rajeev@iprg.nokia.com; Alexandru
Petrescu
Subject: Re: [Mipshop] new charter
stefano.faccin@nokia.com 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.
>> 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.
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
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop