Subject: RE: [NSIS] NSLP design draft: way forward

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 21 Jul 2003 12:16:46 +0200

Sven,

|QoS models (what makes up a QoS model, how is 
|this reflected in standards procedure and can 
|we map RSVP to it as an example).  

To me a minimum model seems to be to have
- a QoS service id which is the first QoS specific 
  object read by NSLP. An example of the meaning 
  in the case of RSVP may be "native IntServ" 
  or "native IntServ controlled load". It may 
  be useful to have IANA reserved and private coding 
  space in it.
  The service ID also determines the NSLP mode of 
  operation. "Native IntServ" is receiver oriented. A 
  hypothetical "Sender oriented IntServ" may allow 
  for sender based reservations re-using IntServ 
  parametrisation (i.e. QoS specific "RESV" objects 
  in a "PATH" message).
- a QoS service parametrisation. The service 
  parametrisation is determined by the service ID 
  (both are coupled non ambiguosly). IANA based service 
  IDs must or should have a standardised service 
  parametrisation. In the case of IntServ, here you'd 
  find the IntServ specific parameters. 
  Services sufficiently characterised by the service ID 
  (in terms of DiffServ e.g. qualitative services) don't 
  require a QoS service parametrisation. 

This service identification differs from the one used by 
IntServ. It's more generic, would support one pass 
reservations and allows for admission control based on 
sender provided parameters. 
Space for private services is left while at the same time 
standardised services may be supported. Interworking 
with IntServ is possible. Clearly, existing IntServ 
implementations can't be used to support the above.

A good question is whether we need a generic "QoS NSLP" 
and a "service ID" beyond. Maybe above syntax described 
how NSLPs are to be defined in general. 

Regards, Rüdiger  

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