RE: [802.21] 3 way handshake
Hi Peretz,
I would like to take the opportunity to make a general point about service primitives
If we look at the 802.2 standard (pages 12 and 13), we can see this diagram, who shows 2 correspondent Service Users and their associated Service layer.
Service User Service Provider Service User
| |
Request -------->| |------> Indication
| |
| |
Confirm <---------| |<------ Response
| |
1)
REQUEST:
The request primitive is passed from the N-user to the N-layer (or sublayer) to request
that a service be initiated.
2)
INDICATION:
The indication primitive is passed from the N-layer (or sublayer) to the N-user to
indicate an internal N-layer (or sublayer) event that is significant to the N-user. This event may be
logically related to a remote service request, or may be caused by an event internal to the N-layer (or
sublayer).
3)
RESPONSE:
The response primitive is passed from the N-user to the N-layer (or sublayer) to complete
a procedure previously invoked by an indication primitive.
4)
CONFIRM:
The confirm primitive is passed from the N-layer (or sublayer) to the N-user to convey
the results of one or more associated previous service request(s).
If we want to reuse this for 802.21, then we have:
MIH User MIH MIH User
| |
Request -------->| |------> Indication
| |
| |
Confirm <---------| |<------ Response
| |
And
MIH Lower Layer MIH
| |
Request -------->| |------> Indication
| |
| |
Confirm <---------| |<------ Response
| |
Obviously we can have different cases, where we just have an Indication from the Provider to the User (our Events),
Or a request/confirm exchange (our Commands etc...).
I suggest we follow what 802.2 has defined, as we should be able to clearly identify the 4 different possible information flows
and I believe all 802s did follow this terminology as well (correct me if I am wrong).
Thus this would mean that in Figure 18 and 22, there cannot be a ".response" primitive from the Local MIHF to the MIHF User.
Both should be replaced by a ".confirm" primitive.
More, in figure 18, Link_Command.indication should be replaced by Link_Command.request and Link_Command.response should be replace by Link_Command.confirm.
I think some more cleanup has to be done in the draft if we choose to conform to "802.2-style" primitives...
As for your question Peretz, IMHO the first ".confirm" primitives in both diagrams are related to the transport
and should not be shown there. In these diagrams we don't mention how the transport is done, we just show local interactions between the MIH, the Lower Layers and their users.
I hope it helps.
Regards,
Mathieu
-----Message d'origine-----
De : Peretz Feder [mailto:pfeder@LUCENT.COM]
Envoyé : jeudi 27 avril 2006 07:08
À : STDS-802-21@listserv.ieee.org
Objet : [802.21] 3 way handshake
Esteemed 802.21 members:
Please explain me why do we need a 3 way handshake MIH command in Figure
18 and a 3 way handshake MIH info in Figure 22?
IMHO the confirmation message brings no added value when local MIHF tells its local MIHF user that the request is delivered further to the remote side. Same outcome can be achieved with a timer. A 3 way handshake is not a state machine friendly algorithm.
Who is objecting to removing confirm messages in the local stack and why?
Peretz