RE: [NSIS] Proposed NSIS charter

["Georgios Karagiannis (ELN)" <[e-mail]>]

Hi Hemant

Before discussing possible modifications on 
RSVP, I think we should first discuss and 
agree on the charter.
In my opinion this charter is very much Mobile IP centric.
There are some other wireless QoS requirements that 
in my opinion should also be included in these discussions.
Such requirements are specified in:
http://search.ietf.org/internet-drafts/draft-westberg-rmd-cellular-issues-00.txt

Best regards,
Georgios

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:[e-mail]]
Sent: dinsdag 30 oktober 2001 16:19
To: [e-mail]
Cc: Loughney John (NRC/Helsinki); [e-mail]
Subject: RE: [NSIS] Proposed NSIS charter


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

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