Subject: [NSIS] About GIMPS!

From: "Elena Scialpi" <[email-masked]>
Date: Tue, 6 Apr 2004 15:54:14 +0200

Hi all, 

In the framework of NSIS there are 2 approaches:

-sender-initiated approach is when the sender of the data flow requests and maintains the 
treatment for that flow;
-receiver-initiated approach the receiver of the data flow requests and    maintains the treatment 
for that flow. 

I think that in  GIMPS (http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt ) 
there is  only the second approach ( the same approach used in RSVP).

What's "Routing State and Messaging Association Maintainance" in sender-initiated approach ?

Thanks for your replies,
Elena

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

---

From: Takako Sanda <[email-masked]>
Date: Wed, 07 Apr 2004 17:52:41 +0900

Hi all,

I have an additional questions about GIMPS state.

Section 4.1 of GIMPS draft says the GIMPS layer maintains message
routing state by using primary key consists of {flow routing info,
session id, signaling application id}.
However, when a signaling application data is QUERY, which used for
finding out available resources, it may not contain flow information or
session id. This case GIMPS cannot maintain routing state as above
though QUERY message requires RESPONSE which should be forwarded
peer-to-peer back to QUERY sender by using NSLP level routing
association (section 3.5.2 of QoS NSLP draft).
So, I think alternative state management method may be required.

If I have any misunderstandings, please point them out.

Best Regards,
Takako Sanda

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 7 Apr 2004 13:44:17 +0200

hi Takako,

In this case, D-mode (or C mode) can be used. I don't understand why the
message does not contain the flow information, nslp-id. The message needs
routing as the data packets so flow information and nslp-id are necessary.
For session-id, it can be created for each query message and the state is
not maintained on any intermediate nodes.

Nary Tra,
ENST, Paris.