Re: [802.21] Question today about upper layers
Dear Peretz,
On 23/03/05 05:31, "Peretz Feder" <pfeder@LUCENT.COM> wrote:
> 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.
HYL: Please see below...
>> - 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).
HYL: There is no contradiction here. SAP is a means to clearly describe an
abstract interface between adjacent layers in a protocol stack reference
model. It does not matter what and how many layers you create. It is a tool
for clarity. As you know well, 3GPP/3GPP2 specifies very complicated
complete systems, it is normal and necessary to structure rigorously the
3GPP/3GPP2 stacks (with well-defined layers and SAPs). The definition of a
SAP is very important because it specifies what services the upper layer
expects from the lower layer, and allows the functions and protocols to be
developed independently in each layer.
Cheers,
Hong-Yon
>>
>> 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
>>
>>
>
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