RE: [NSIS] Proposed NSIS charter

["Chaskar Hemant (NRC/Boston)" <[e-mail]>]

Hi:


> Hi John,

> > >       1) I didn't quite understand, whether the WG would define a
new
> > > signalling protocol or not? Would, for example, an enhancement /
> > > modification to RSVP be considered in or out of scope?
> 
> > The intention is not to define a new protocol, but to enhance or
> > modify an existing one, such as RSVP.

> Could this "existing one" be interpreted as "approaches which have
been 
> already presented (perhaps under development)"? 

    [HC] I was thinking as to what modifications to RSVP can actually be
done. For that,    	it may be worthwhile to look at some core RSVP
characteristics. There are as 	follows:

     1. One pass with advertisement approach,
     2. A way to define packet filter based on source and dest IP
addresses and port 	numbers,
     3. A way to define flow's traffic characteristics via RSVP
Flowspecs.
     4. Use of explicit refresh messages.

	Now modifying RSVP might account to 

	1. Allowing for forward reservations.
	2. Expanding the scope of defining packet filters by inclusion
of additional 	parameters + some optimizations based on IPv6 flow
label. For example, IPv6 flow 	label can be used to identify the flow
in the router. This will get rid of problems 	with chaning CoA in
Mobile IP.
	3. In addition to using RSVP Flowspecs to describe nitty gritty
details of flow, 	provide an option for describing some simple QoS
requirement, for example, QoS 	class and average rate.
      4. Arrival of flow's data packet at the router can be used as an
indication of live 	connection. This will avoid reliance on explicit
refresh messages.

	Are there any other core modifications to RSVP that we can think
of.

      May be we can create a list of possible modifications, evaluate
their need and  	elaborate on those which will be agreed upon by
the WG. That way, we can get the 	task of RSVP modifications
completed quickly. 

> > >      2) If the goals include some sort of new QoS signalling,
would
> > > that include eg. bandwidth broker functionality, if needed, or
just a
> > > signalling mechanism? So, more entities concerned by the
> > > signalling than just routers and end hosts?
> >
> > One goal is to define the architecture.  This may include signaling
> > to a proxy or to a bandwidth broker.

> Do we have any "proxy" or "bandwidth broker" in existing protocols?
IMO the 
> answer depends on my previous question.

> > >     3) Would the signalling be limited to a separate QoS
signalling
> > > protocol, or could the QoS signalling be part data packets,
> > > so be in-band, as the DSCP in DiffServ or the INSIGNIA scheme. A
> > > new IPv6 extension header for QoS?
> >
> > I think those could be possibilities.  One could (though I won't)
> > make a point that one result would be to create a use for the IPv6
> > flow label.

> Fine with me. However I think taking advantage of IPv6 extension
header option,
> would be beneficial compared with only an IPv6 flow label since it can
carry 
> more information. In fact the ID 
>
www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-01.txt

> did present such an approach.

	[HC] I think Xiaoming meant 

	
http://ietf.org/internet-drafts/draft-chaskar-mobileip-qos-01.txt. 

	Thanks.

      Hemant



> Thanks

> Xiaoming

_______________________________________________
nsis mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/nsis