RE: [802.21] Question today about upper layers
If we can agree that policy attribute signalling is complex and hard to
standardize, why not do as other groups do and leave in plenty of room
for vendor proprietary primitives and messages? Give it a year or two
and implementors will better know what works and be in a position to
propose specifics.
Obviously, since I'm suggesting a vendor proprietary message ID space on
the wire/air (as per the original proposals in the ECSG), I don't mean
upper layers only. These things may or may not need to traverse the
link.
I'm trying to understand the argument. Does someone want policy
attribute primitives defined and someone else not? Or is it one of these
arguments that is ultimately moot because it has no impact on the text?
DJ
-----Original Message-----
From: owner-stds-802-21@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Stefano M.
Faccin
Sent: Monday, March 21, 2005 6:15 AM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] Question today about upper layers
-----Original Message-----
From: owner-stds-802-21@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-21@LISTSERV.IEEE.ORG]On Behalf Of ext Peretz
Feder
Sent: Monday, March 21, 2005 12:17 AM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] Question today about upper layers
On 3/15/2005 9:57 AM, Iyer, Prakash wrote:
> We might want some flexibility here. Having a lower layer autonomously
> switch links w/o considerations for cost ($$), whether it makes sense
> to single-home or multi-home, account for user preferences etc. does
> not seem appropriate - and certainly not in all situations. Having MIH
> generate triggers that facilitate handovers is one thing; specifying
> how MIH can use policies to switch links at this layer is avoidable in
> 802.21.
Not sure what is issue. Why can't the MIH layer get as one of its inputs
the policy attributes? Why is it (policy attribute) only reserved for an
upper layer?
[Stefano Faccin] Peretz, I believe the point here is not that policies
and policy attributes must be only reserved for the upper layer, but
that realistically it would be rather complex to specify a SAP that
allows the UL to provide all the relevant attributes. Through
experimenting in Nokia implementations of mobility/connectivity
management for multiple access devices, we've witnessed that in order
for a terminal with multiple policies - end user, device owner (e.g.
enterprise), WISP, cellular operator, application policies/requirements
- to make decisions on connectivity and handoff, a rather complex set of
interactions between the information available about the links and the
policies is required. This led to the conclusion that the logic driving
such interaction must be at a layer above the MIH, since such logic can
be very complex. Also, it does not make much sense in specifying such
logic but allow differentiation between vendors. In particular, we
experienced how com!
plex the interactions between this logic and the policies are, and as a
direct result if we wanted to allow any logic in the MIH function and
the most flexible interaction between the MIH and the policies
repository in the terminal, a very complex SAP would result. In
conclusion, I see a lot of added complexity without seeing much
advantage.
That said, with the base primitives, none of the implementation
> scenarios that people are thinking about will be precluded.
Please elaborate, are you referring to upper layer implementation only
> -Prakash
>
> -----Original Message-----
> From: owner-stds-802-21@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of Peretz Feder
> Sent: Monday, March 14, 2005 2:48 PM
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: Re: [802.21] Question today about upper layers
>
> Greg:
>
> I am of the opinion thet MIH commands lower layers to switch a link
> and in conjunction inform upper layers to take care of the IP
> signaling over the new selected link.
>
> Example switch 3gpp2 to .11 interface and make the MIP signaling at
> layer 3 perform MIP re-registartion with the new COA and old MIP
> address. So I am with you.
>
> The counter argument will be what if moblity is done at the
> Application layer?
> i.e. SIP mobility?
>
>
>
> Peretz Feder
>
>
>
> On 3/14/2005 5:12 PM, Greg Daley wrote:
>
>>Hi,
>>
>>Here's my question from today about
>>upper layer protocols.
>>
>>Have you considered if specifying direct interfaces to upper-layers
>>will cause confusion?
>>Wouldn't it be better to delegate this upper-layer trigger function to
>>L3?
>>
>>Greg
>