Re: [802.21] Question today about upper layers
I would agree accept that 3GPP/3GPP2 thought me otherwise, see embedded.
On 3/22/2005 6:43 AM, Hong-Yon Lach wrote:
> Let's change a bit the aspect of the discussion...
>
> About standardization:
> - An element (information, protocol, function, etc) needs to be standardized
> ONLY IF its behaviour and/or format needs to conform to an agreement (for
> interoperability).
PF: You mean interoperable test to verify interoperability.
> There are conformance testing of protocol
> implementations, but there are no conformance testing for SAP
> implementations (although well-know APIs can be specified and implemented).
PF: fine, yet 3GPP and 3GPP2 defines every internal SAP and every internal bit
very precisely. An apparent overkill that proved to be fast accepted by
3GPP/3GPP2 vendors than traditional IEEE vendors who take many years to adopt
and require Wi-Fi or WiAmx alliances to help them sort out the extremely vague
options listed in typical IEEE standards.
> - The SAP is a means in standards to describe the abstract relationship
> between a service user and the service provider in the adjacent layers in a
> reference model of a protocol stack. It is NOT used to describe (protocol)
> exchanges between systems. It does NOT dictate any implementation of the
> layers and APIs. The SAP describes the essential abstract primitives
> (request, response, indication, response) with their associated parameters
> (formats and semantics) between the service user and service provider. How a
> SAP is implemented could be specified in an API, which decides how to
> express the SAP primitives in function calls and methods (synchronous,
> asynchronous, callback, listening, etc), and may include other elements
> associated with specific software design, OS, and programming language.
PF: Yet, 3GPP and 3GPP2 see it differently and painstakingly provided extensive
description of internal interfaces and in the process created many additional
layers below IETF layer 3 (IP).
>
> Now about the mobility management policy:
> - Is there a need to standardize the logic of processing a mobility
> management policy? I don't think so. There is no interoperability issue
> associated with such logic.
> - Is there a need to standardize the expression of a mobility management
> policy? It is ONLY necessary if a protocol is to be defined to exchange such
> policy between systems. I do see such need. However, I don't think such
> exchange as part of the 802.21 (MIH) function; thus such policy expression
> does not needed to be exchange at the MIH SAP between layers; thus the
> policy expression does not need to be standardized in 802.21 (although it
> may need to be standardized else where).
> - I do not see any argument from the standardization perspective justifying
> the need of standardizing policy and policy logic in 802.21. As pointed out
> already, this does not prevent any such policy and policy logic to be
> implemented.
>
> Cheers,
> Hong-Yon
>
>
>
> [Gupta, Vivek G]
> It just cannot be standardized that way. If it is not standardized that
> way no possibility is precluded and you are free to do your own custom
> implementation any way you want.
>
> PF: Are you saying it can't be standardized because it can't be tested? and
> therefore nothing is precluded?
>
> [Gupta, Vivek G]
> With only the base primitives of triggers and information service
>
> PF: and these are testable/conformable and therefore can be standardized
> more
> precisely?
>
>
> On 21/03/05 20:24, "Johnston, Dj" <dj.johnston@INTEL.COM> wrote:
>
>
>>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
>>>
>
>
> Message Classification:
> [ ] General Business Use Only
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary
>
> Hong-Yon Lach
> Lab Manager, Edge Mobile Networking Lab (EMNL)
> Office: +33 (0)169352536; Mobile: +33 (0)607590268
>
>
> Parc les Algorithmes - Saint Aubin
> 91193 Gif-sur-Yvette Cedex
> France
>
>