Subject: RE: [NSIS] Automatic Discovery of QCs

From: [email-masked]
Date: Mon, 4 Mar 2002 09:26:53 +0200

Hi Hemant,

> In the interest of simplicity, allow me to turn around the 
> blurred requirement. Can we actually say that
> 
> "NSIS SHOULD support a signaling mechanism that does not 
> require explicit discovery of QoS entities."
> 
> In other words, can't a host just shoot an NSIS signal 
> towards the network (destined to a well-known IP address for 
> example or identifiable by some field in the packet header) 
> and the routers can forward it to appropriate QCs in their 
> network domain.

You put it quite well, that was the reqirement that I was
trying for.

John

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

---

From: Kappler Cornelia <[email-masked]>
Date: Tue, 5 Mar 2002 10:49:01 +0100

Hi John, Hemant and Roland, 

	John wrote:
	>   5.3.8 Discovery of QoS Controllers
	> 
	> 	NSIS SHOULD support a simple mechanism for discoverying
	> 	QoS entities.

	Hemant wrote:
>"NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities."

I could live with either of the two, although the second alternative might be interpreted to actually exclude explicit discovery? However, I think both implicit and explicit discovery are important: 

On the one hand it is important to have a simple, implicit, default / fall back mechanism for sending NSIS signaling mesages when the address of the next QC is not known explicitly. The address of the next QC might not be available for example because a mobile host attaching to a foreign network doesnt know the local QC, nor should it be burdened with finding out. Or else there was a network failure and QC info got lost, or simply because each router on the data path is a QC (as in IntServ) and no explicit addressing is necessary. In this case the signaling packets should travel on the data path until it encounters a QC which knows the next QC and addresses the signaling explicitly. This QC on the data path would ideally be the access router or edge router as has been suggested - obviously for the fallback case it makes sense to have some routers on the data path which are NSIS aware (= QCs).

On the other hand, having each router on the data path look at the NSIS signaling message is not scalable. For optimizing both signaling path and processing load on routers, it is desireable to be able to explicitly address the next QC. Plus the next QC might not automatically be on the data path, either because some kind of QoS routing is being used, or because the next QC is a bandwidth broker.

So why not go the same way as RSVP: the default is on-path signaling, with the signaling destination as the destination address and Router Alert Option turned on. However, when the next QC controller is known (by some means e.g. such as have been discussed on the mailing list), the signaling is addressed explicitly, just as in aggregate RSVP the Deaggregator is addressed explicitly, for tunneling per-flow signaling messages accross the aggregation region. 

(This is also what we suggest in our framework draft http://www.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt.)

Cornelia