Subject: [NSIS] RE: What's in the charter of NSIS

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 15 May 2002 11:35:49 +0200

Hi John

> RFC 2998 discusses "Integrated Services Over Diffserv Networks."
> Some folks (meaning area directors & IESG folks) have thought
> that a more general solution is needed, meaning that 2998 is
> a specific implementation of the general solution.  

And the fog started to lift...

> Furthermore, maybe someone does not want IntServ exactly,
> but perhaps a certain characteristic of IntServ, say 
> bandwidth.

What happens to the remainder of IntServ in that case? 
Would one have to signal empty parameters? No answer 
required if this will be discussed in Helsinki!   

>     Then you could have
> 
> 	Bandwidth Assurance over IntServ Networks
> 	Bandwidth Assurance over MPLS Networks
> 	Bandwidth Assurance over Over Provisioned Networks
> 	Bandwidth Assurance over a Bandwidth Broker Network

That BB definition issue must be settled. The "friends 
of BB" could provide an architecture outline by now, 
if they are not charged of entering the solution discussion. 
It would be helpful to have such a document (and I see
by your other message that you aggree). Your above 
example in my words would be:

BW Assurancee over MPLS using a BB
BW Assurance over Over Provisoned Networks using a BB
or in general: BW Assurance over a network using a BB

BB's of separated domains may 
signal with each other without bothering which 
layers/technologies are supported by the domain
in which each operates. This solves the problem 
you've mentioned below (with regard to signaling):  

> Finally, what do you do when one party of a call/session has
> one 'kind' of network and the other party has a different 
> 'kind'?  You could do a hop-by-hop approach, at each
> hop modifying or translating the necessary parameters,
> but this gets ugly fast and may not work.  Perhaps it is
> better to have a general solution, then work later on
> how the general solution can be mapped down to a specific
> network or resource reservation mechanism.

Regards, Rüdiger

PS: My basic BB perception may be found in
http://qbone.internet2.edu/bb/bboutline2.html
That's work without progress. It's more than 10 pages. 
If anybody has got time and doesn't mind an 80% perfect 
document, he/she may like it.

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

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 15 May 2002 16:12:35 +0200

Hi Rüdiger and John,

"Geib, Ruediger" wrote:
> 
> That BB definition issue must be settled. 

[email-masked] wrote:
> There is no 'bandwidth broker' term in the IETF lexicon, a quick
> RFC search turned up no references.  I think this is part of the
> problem.  Generally, the IETF has been allergic to centralized
> approaches, as this introduces single points of failures, etc.

Chapter 4 of rfc2905 refers an explicit definition of bandwidth
broker (which discussed by Internet2) and derives authorization 
aspects for the BB. Maybe it's helpful for NSIS to regard the BB
as an item as well. As many folks here stated, BB is not usually
a centralized approach in a larger scale than a single domain.

There are a number of other rfcs (e.g., 2475, 2903, 2638) talk
about the BB.

Regards,
--
Xiaoming Fu 
[email-masked]
http://www-tkn.ee.tu-berlin.de/