Subject: RE: [NSIS] About GIMPS!

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 09:16:42 +0200

hi cheng, 

> Hi Hannes,
> 
> 
> <Snip>
> > if you decouple the authorization aspects from the signaling 
> > aspects then
> > the concepts of sender- vs. receiver-initiated "something" 
> > are less obvious
> > in a path-coupled signaling protocol. i personally think that the
> 
> I think if we further decouple the messaging association establishing
> procedure (GIMPS) from the actual signaling (NSLP signaling), the
> sender-init vs. receiver-init would be less important. With 
> the current text
> in GIMPS, there is still a subtle difference, e.g. in D-mode, 
> sender-init
> could send NSLP message with the "GIMPS-query" message. 

i still cannot get used to the d-mode vs. c-mode terminology. 
anyway, the d-mode vs. c-mode issues are also orthogonal to this discussion.

> 
> As for the messaging association establishment, it is a GIMPS level
> signaling. According to the text in section 4.3, it has to be 
> initiated from
> upstream. What is lacking is how this process is triggered 
> (maybe out of
> scope). What I am not so sure is that if it is triggered by a 
> message sent
> by the receiver, e.g. a BU from a MN, could we call it 
> receiver initiated?

this is part of our mobility discussions. i don't know whether we should
call something receiver-initiated only if the data receiver triggers some
actions (after an initial exchange already took place). in the mobility case
we even have scenarios where nodes in the middle could trigger something. 

> 
> 
> > definitions of these two terms is rather fuzzy (even in the 
> > framework). with
> > path-coupled signaling only the sender is able to start signaling.
> 
> Do you mean the GIMPS signaling described above? I feel it 
> depends on what
> we took as "signaling": NSLP or NSLP+NTLP. But, overall (for 
> NTLP and NSLP),
> it is quite true.

the data sender has to send the first message in nearly all cases. 

for the receiver-behind a nat things are a bit different but this might not
fit into the sender- vs. receiver-initiated "something" terminology either. 

i suggest to deprecate the sender- and receiver-initiated terminology. what
matters at the end is
- who has to provide information for authorizion 
- what is he authorized for
- to which entity is authorization required
- who triggers reauthorization
- what credentials are used for authorization
- how long is authorization valid
- and finally the different levels of authorization (for qos resource, for
triggering certain actions, ... )

since some of these issues have a relationship to mobility i would encourage
everyone to take a look at the mobility draft (and the nslps) and to post
their opinion. 

ciao
hannes

> 
> 
> cheers
> 
> Cheng Hong 
> 
> 
> > 'maintaining the treatment for a flow' is also difficult to 
> > understand in
> > the light of our mobility discussions or the recently 
> > discussed preemption
> > issues. 
> > 
> > ciao
> > hannes
> > 
> > 
> > > 
> > > Thanks for your replies,
> > > Elena
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > > 
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 7 Apr 2004 16:23:31 +0800

Hi Hannes,

Please see a few more comments inline:

> > sender-init vs. receiver-init would be less important. With the 
> > current text in GIMPS, there is still a subtle difference, e.g. in 
> > D-mode, sender-init

True. This has nothing to do with D-mode vs C-mode. It is rather sender-init
vs. receiver-init. For a sender-init case, it could send NSLP message
directly using a GIMPS-query message without a messaging association to be
setup beforehand. For receiver-init signaling, it is not possible to do so.

> > initiated from upstream. What is lacking is how this process is 
> > triggered (maybe out of
> this is part of our mobility discussions. i don't know 
> whether we should call something receiver-initiated only if 
> the data receiver triggers some actions (after an initial 
> exchange already took place). in the mobility case we even 
> have scenarios where nodes in the middle could trigger something. 

With mobility scenarios, this would be more intersting. There could be
different triggers flying around. The issue would be "do we treat these
mobility signaling part of NSIS signaling"? If not, the signaling would be
almost always sender-init, since the first GIMPS message is always sent out
from the sender. If yes, then, the signaling could be initiated anyway
(sender/receiver/middle node)

> the data sender has to send the first message in nearly all cases. 

Please see above.

> for the receiver-behind a nat things are a bit different but 
> this might not fit into the sender- vs. receiver-initiated 
> "something" terminology either. 

Agree. Add in the NAT makes it more confusing for now.

> i suggest to deprecate the sender- and receiver-initiated 
> terminology. what matters at the end is
> - and finally the different levels of authorization (for qos 
> resource, for triggering certain actions, ... )

This is a good list. But I feel some of the issues could be separated for
NTLP(GIMPS) and NSLP. Most of the authorization issues would be related to
NSLP, e.g. authorization for qos, etc. As for the GIMPS, the issue is more
focused on the "routing state maintenance" and "messaging association".
Therefore, the things to be sort out are: 
-who and when setup the messaging association (including nodes auth. issues)

-what triggers the setup of messaging association (interactions with NSLP or
routing stack)
-What is the interaction for "routing state" and "messaging association
(related to mobility)

> since some of these issues have a relationship to mobility i 
> would encourage everyone to take a look at the mobility draft 
> (and the nslps) and to post their opinion. 

Is the new version of the mobility draft available now?

cheers

Cheng Hong