Re: [802.21] SAP semantics
Hi!
>> IMHO, Vivek seems to be saying that unless there are new functions
>> specifically to be supported by the MIH_NET_SAP, there's no need to
>> describe a new SAP (Correct me if I'm wrong Vivek).
> By this argument we should remove MIH_LINK_SAP.
Hmm... The MIH_LINK_SAP is used for the media specific interfaces to
map/create functionalities corresponding to 802.21
functionality/requirements.
> Define means of interface that invoke layer 2 or layer 3 transport
> mechanism for remote MIHF peers
Communication with remote MIHF peers should/may be transparently
achieved using the MIH_SAP and/or the MIH_LINK_SAP.
Is it your intention then to separate some of the functionalities from
MIH_SAP and MIH_LINK_SAP and group them under MIH_NET_SAP instead? Or
are you proposing the creation of new "invoke layer 2 or layer 3
transport mechanism for remote MIHF peers" to be located in the MIH_NET_SAP?
Regards,
Ben
So is it your intention to
Peretz Feder wrote:
> Benjamin: see in-line
>
> Peretz Feder
>
> On 9/6/2006 10:59 PM, Benjamin Koh Tien-Ming wrote:
>> Hi all!
>>
>> IMHO, Vivek seems to be saying that unless there are new functions
>> specifically to be supported by the MIH_NET_SAP, there's no need to
>> describe a new SAP (Correct me if I'm wrong Vivek).
> By this argument we should remove MIH_LINK_SAP.
>>
>> I basically agree with that viewpoint, having a SAP that basically maps
>> existing functionality does not seem that critical at this point in
>> time. Is there any new service unique to the MIH_NET_SAP? It may help
>> clarify the discussion.
> Define means of interface that invoke layer 2 or layer 3 transport
> mechanism for remote MIHF peers
>>
>> Regards,
>> Ben
>>
>>
>>
>> Peretz Feder wrote:
>>
>>> Vivek, pls see in line (red):
>>>
>>> */ /*
>>>
>>> */"The L2 transport functions are provided by media specific SAPs. The
>>> L3 transport functions may be provided by other higher layer services. /*
>>>
>>> */I don’t see the need to introduce another SAP for these transport
>>> functions."
>>> /*
>>>
>>> */
>>> Pls. look at the attached, it is exactly what you are indicating here.
>>> The proposed MIH-NET-SAP is an explanation and illustration of what you
>>> have just described:/*
>>>
>>> */
>>> The L2 transport functions are provided by media specific SAPs.
>>> /*
>>>
>>> */
>>> In the attached pls note the media specific text
>>> /*
>>>
>>> */
>>> /*
>>>
>>> */
>>> The L3 transport functions may be provided by other higher layer
>>>
>>> That too is described in the mapping exercise. We are not proposing a
>>> new SAP, just map it properly to L2 and L3.
>>> /*
>>>
>>> */Peretz Feder
>>> /*
>>>
>>> *//*
>>>
>>> */
>>> /*
>>>
>>>
>>>
>>> On 9/6/2006 5:00 PM, Gupta, Vivek G wrote:
>>>
>>>> Some comments below.
>>>>
>>>> Best Regards
>>>>
>>>> -Vivek
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> * *Ajay Rajkumar wrote:
>>>>
>>>> Hong-Yon,
>>>>
>>>> I agree that SAP is defined to provide an abstraction between a
>>>> service provider entity and a user entity.
>>>> Also, MIH protocol would be used to provide communication between the
>>>> two MIHF entities.
>>>> The problem arises from the current text in the draft in Section 5.6
>>>>
>>>> "Upper layers may directly send commands to MIHF. Similarly MIHF
>>>> entity may also
>>>> send commands to another remote (peer) MIHF entity. Primitives
>>>> corresponding to all these services
>>>> described above are within the scope of MIH_SAP."
>>>>
>>>> */[Vivek G Gupta] /*
>>>>
>>>> */This text can be updated. Below is a suggestion for the second part
>>>> of this paragraph in section 5.6 (pg 29 of draft D01.09)/*
>>>>
>>>> */ /*
>>>>
>>>> */“The MIH_SAP and associated primitives provide the interface from
>>>> MIHF to the upper layers of the mobility-management stack. Upper
>>>> layers need to register with MIHF as users to receive MIHF generated
>>>> events and also for link layer events that originate at layers below
>>>> the MIHF but may be passed on to upper layers through MIHF. Upper
>>>> layers may directly send commands to MIHF. Similarly MIHF entity may
>>>> also send transport these commands and events to another remote (peer)
>>>> MIHF entity./* */Primitives corresponding to all these services
>>>> described above are within the scope of MIH_SAP/**. **/The L2
>>>> transport functions are provided by media specific SAPs. The L3
>>>> transport functions may be provided by other higher layer services.”/*
>>>>
>>>> */ /*
>>>>
>>>> */I don’t see the need to introduce another SAP for these transport
>>>> functions./*
>>>>
>>>> This implies that MIH_SAP is being used both by the MIH User as well
>>>> as MIHF to communicate with the remote entity, which is my view is
>>>> incorrect.
>>>>
>>>> */[Vivek G Gupta] /*
>>>>
>>>> */MIHF does not use MIH_SAP. That notion is indeed incorrect./*
>>>>
>>>> */The first sentence in paragraph above (copied below) illustrates
>>>> that clearly as well./*
>>>>
>>>> */“The MIH_SAP and associated primitives provide the interface from
>>>> MIHF to the upper layers of the mobility-management stack”/*
>>>>
>>>>
>>>> Regards,
>>>> -ajay
>>>>
>>>> */ /*
>>>>
>>>>
>>>> Hong-Yon Lach wrote:
>>>>
>>>> Salut all,
>>>>
>>>> A SAP is defined to provide an abstraction of service between a
>>>> service provider entity and its user entities in the local system. A
>>>> protocol provides a specification of interactions and operations
>>>> between “peer” entities in different (sometimes virtual) systems with
>>>> well-defined PDUs exchanges over a communications transport.
>>>>
>>>> If a local MIH-user needs a remote services by a remote MIHF, it makes
>>>> its request to the local MIHF through the MIH SAP. The local MIHF
>>>> determines that it needs the support of a remote MIHF, it thus
>>>> performs the necessary operations with the remote MIHF using the MIH
>>>> protocol. Upon the end of the MIH protocol operation, the local MIHF
>>>> provides a response to the MIH-user via the MIH SAP.
>>>>
>>>> An entity can initiate the execution of its function and/or protocol
>>>> by many different triggers: timeout of a timer, request by its users,
>>>> detection of certain system conditions, reception of a PDU from its
>>>> peer, etc. The entity can initiate its function and/or protocol
>>>> without going through its SAP. A SAP is not the only means to have its
>>>> serving entity to initiate a function and/or protocol.
>>>>
>>>> I hopes this addresses your concerns.
>>>>
>>>> Cheers,
>>>> Hong-Yon
>>>>
>>>>
>>
>>
>>
>
--
/<<<<<<<<<<<<<<<<<<<<++>>>>>>>>>>>>>>>>>>>>\
| Benjamin Koh Tien-Ming |
| R & D Engineer |
| Panasonic Singapore Laboratories Pte Ltd |
| Tel: (65)6550 5481 Fax: (65)6550 5459 |
| E-mail: benjamin.kohtm@sg.panasonic.com |
\>>>>>>>>>>>>>>>>>>>>--<<<<<<<<<<<<<<<<<<<</