Subject: [NSIS] To BB or not to BB

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 8 May 2002 08:34:20 +0200

Hi Gary,

> I am confused by your comment about bandwidth broker 
> (perhaps because I missed the discussion). Ignoring
> the complexity of end-to-end inter-system negotiation
> for the moment, how is a bb different from a QC? 

You didn't miss anything. NSIS still is in the requirements phase. Georgios comment isn't part of the ongoing discussion. I'd suggest to return to requirements before we start to talk about solutions.

Regards, Rüdiger 

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

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 10 May 2002 09:30:13 -0400

John,

I think as long as we agreed that the NSIS signaling path is allowed to
diverge from the data forwarding path everybody who cares about BBs would be
satisfied.

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 10, 2002 4:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] To BB or not to BB

Hi all,

Just a general comment about Bandwidth Brokers and NSIS.  Bandwidth
Brokers (as the are commonly defined) are actually out of scope
of NSIS.  This means we are not defining a bandwidth broker
architecture.  There was quite a bit of discussion (at a highlevel)
about this before NSIS was allowed to be chartered, and it was
said to me that bandwidth brokers are not really thought of
as part of the Internet architecture.

However, I do know that there are many folks providing bandwidth
broker solutions.  My view is that a bandwidth broker comes
dangerously close to how resources are provisioned, therefore
are out of scope of NSIS. From the charter:

 It is noted that resource reservation and traffic engineering can be
 considered as part of network administration, and therefore beyond the
 scope of the IETF to mandate a particular mechanism.

Additionally, some folks may wish to check on the TEWG
(http://www.ietf.org/html.charters/tewg-charter.html) for work on
traffic engineering.

Finally, I do think it is perfectly acceptable to have a framework
and/or solution that is friendly to bandwidth brokers, but I do not
think that a bandwidth broker centric architecture or solution is
what we should do.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 10 May 2002 11:07:51 -0400

This is not just related to bandwidth brokers. It is a requirement
for any number of system architectures where the service control points
(not bandwidth brokers) are not located along the bearer path, and
for any system where there are performance advantages in having the
QoS signalling take a separate path from the bearer traffic.

Personally, I see a tremendous potential for confusion.
The charter, as John pointed out, precludes discussions of resource
reservation. And yet, the only reason, as far as I can tell, for requiring 
QoS signalling to traverse the bearer path is for the purposes of resource 
reservation. Perhaps I am missing something (as usual).

Gary

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: May 10, 2002 09:36
> To: 'Freytsis, Ilya'; [email-masked]';
> [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Hi Ilya
> This is one of the requirements that are mainly related 
> to bandwidth brokering scenarios and significantly 
> complicate the NSIS protocol.
> 
> 
> best regards,
> Georgios
> 
> 
> From: Freytsis, Ilya [mailto:[email-masked]]
> Sent: vrijdag 10 mei 2002 15:30
> To: [email-masked]'; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 13 May 2002 10:50:37 +0200

> After developed COPS multiple times in the past, 
> my experience has been that BB is to simply lift
> all the work from a distributed system (router
> network) to a centralized system (BB network).
> Instead making things simple, BB's will do the
> same amount of message processing, state management
> etc. as the routers, but BB's will now have to 
> somehow knowing the entire network AND to sync
> up states with the routers. At the end, BB's just
> make the whole thing more complex.

BB's will be optimized to process signaling messages which
of course have to be processed somewhere. I didn't argue 
for a centralized solution being simple. Coping with e.g.
route changes will introduce complexity in any signaling
architecture. I don't know by now which solution will be
more complex. And I won't argue against a router based 
signaling mechanism based on IntServ development 
experiences (I personally don't have it). I must also
admit that COPS isn't my favorite protocol.

> Hoe about this: mobile devices create a session 
> with some policy servers for billing. The packets may
> go through routers, and the routers don't have to do
> much about it. Only when the mobile devices want to 
> get network resource, it can ask the routers, and 
> routers can signal the rest of the network. In this
> case, routers don't have to care anything about BB or
> not BB, and mobile devices can talk to the servers 
> without worrying about if routers will do something
> crazy to the packets. :-)

But what if the wireless mobile changes base station 
and expects a seamless handoff? If all routers know where
to send and get signaling information to, a seamless 
handoff may be feasible while in your scenario some 
routers start to do things during handoff while some
servers may do other things. You must synchronize them.
Sounds complex too, doesn't it? Or do you expect all the 
related signaling to be done by the mobile. This wuoldn't 
quite be what mobile terminal developers dream of.

> What kind of inter-domain are you referring to?
> Please tell me how to run centralised XYZ 
> administration in the inter-domain enviornment in the
> Internet? :-)

Every domain may have its own centralized admin system
signaling to other centralized or non centralized systems.

This thread is only partially related to actual NSIS issues. 
I'm happy to continue private discussion. All I'm suggesting
with regard to NSIS is that people contribute requirements 
instead of talking solutions - especially if they talk about
solutions they don't like.

Rüdiger

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 14 May 2002 10:25:53 +0200

Hi

I think it will be very good if we will extensively discuss 
these issues in Helsinki (at interim meeting).

Best Regards,
Georgios

-----Original Message-----
From: Roland Bless [mailto:[email-masked]]
Sent: dinsdag 14 mei 2002 10:18
To: Georgios Karagiannis (ELN)
Cc: 'Freytsis, Ilya'; [email-masked]';
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [NSIS] To BB or not to BB 

Hi Georgios,

> complicate the NSIS protocol.

Sorry, but I disagree here. It gives you much more 
flexibility, but I don't see how it complicates things 
significantly. IMO an NSIS solution should allow at 
least both solutions, either router-based (RSVP-like) 
or BB-based, and, personally I don't think this will
complicate things that much.

Regards,
 Roland

---

From: [email-masked]
Date: Tue, 14 May 2002 10:36:16 +0200

Hi Georgios, Roland,

Leaving aside the application of the bandwidth broker, I think it is
essential that the nsis protocol be applicable for out-of-band signaling
(so directed to entities that are not necessarily on the data path). BB is
a potential application, so is proxy signaling. Anyway, I look forward to
the discussion on this in Helsinki.

CU,
Sven.

"Georgios Karagiannis (ELN)" <[email-masked]> on
14/05/2002 10:25:53

  To:          "'Roland Bless'" <[email-masked]>             
                                                              
  cc:          "'Freytsis, Ilya'" <[email-masked]>,   
               "[email-masked]'"                    
               <[email-masked]>,                     
               [email-masked],                   
               [email-masked],                   
               [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

  Subject      RE: [NSIS] To BB or not to BB                  
  :                                                           

Hi

Best Regards,
Georgios

-----Original Message-----
From: Roland Bless [mailto:[email-masked]]
Sent: dinsdag 14 mei 2002 10:18
To: Georgios Karagiannis (ELN)
Cc: 'Freytsis, Ilya'; [email-masked]';

Hi Georgios,

Regards,
 Roland

---

From: [email-masked]
Date: Wed, 15 May 2002 11:48:17 +0300

Hi Rüdiger,

> I don't know what your perception of a BB is. Mine is that
> there's one per QoS domain, controlled by the operator 
> running the domain. There's no difference in per router 
> security requirements and BB security requirements if you 
> look at the single element. The number of routers involved 
> into signaling is higher and each has to as robust against 
> an attack as the few centralised BBs have to be.

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.

Anyhow, I have yet to see a clear, crisp definition of bandwidth
broker, so I very hesitant in accepting it into NSIS.
 
> > Discovery mechanisms (how
> > do I discover the BB in my home network, my visited
> > network, do I need to discover your BB if I am calling
> > you ....  
> 
> As difficult to solve as AAA.

Not really, I think the current AAA architecture is not
so bad.

> > Scalability - to what extent does this scale?
> > Can we put a metric on it?  Is it per domain, sub-domain,
> > per link ..?
> 
> Or per router, maybe even integrated into a router? If you'd
> like to see more literatutre on the scalability of centralised
> admission control, could you provide a couple of references 
> examining the scalability IntDiff?

Noone is promoting Integrated Services over DiffServ networks as
a solution to NSIS, as this work as already been done.  Whether
or not anyone uses it, is not an issue for us.  I think we need
to work on a more general approach, because we cannot ensure
that all networks deploy DiffServ.

John

---

From: Kappler Cornelia <[email-masked]>
Date: Wed, 15 May 2002 11:51:39 +0200

Note that out-of-band signaling is also an issue when QoS Routing is employed. 

I.e. when the signaling packets are not identified the same way as the data packets they are signaling for (e.g. different DSCP, addresses etc) they might be routed differently and we have out-of-band signaling anyways.

Cornelia

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, May 14, 2002 10:36 AM
> Cc:	'Roland Bless'; 'Freytsis, Ilya'; [email-masked]'; [email-masked]; [email-masked]; [email-masked]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 15 May 2002 10:14:57 +0200

Hi John

> Complications are: security (we are developing for an 
> open Internet) - 3rd parties involvment in any signaling
> is a known security hole.  

I'm not sure whether the problem we discuss is of technical nature. 

Regards, Rüdiger

---

From: [email-masked]
Date: Wed, 15 May 2002 13:13:29 +0300

Marco,

Your proposed solution sounds much more like a proxy archicecture
than a bandwidth broker architecture.  I think we will be able
to work on the problem area you have suggested without too much
trouble.  We will have to sort out the details, of course.

John

> From: ext Schneider, Marco [mailto:[email-masked]]
> Sent: 13 May, 2002 19:04
> To: 'Ping Pan'; [email-masked]
> Cc: Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Ping,
> I am not sure how you define a Bandwidth Broker. As I and one of my
> colleagues at SBC have expressed to you on several occasions, 
> we at SBC want
> to enable our customers to signal for QOS flows across our 
> network. If we
> are successfull NSIS will become the common signaling 
> protocol to do that
> across all access methods. Because the timing does not fit 
> our immediate
> needs, we have proposed extensions to RSVP as a way to access 
> ATM and MPLS
> networks. In our architecture, customer initiated RSVP 
> signaling will be
> directed to an controller which proxy signals for a 
> connection across our
> network. It should come as no surprise that a number of other 
> carriers share
> an interest in this approach as a way to exploit their 
> already deployed ATM
> infrastructure.
> 
> My 3 Cents,
> 
> Marco
> 
> 
> 
> 
> > From: Ping Pan [mailto:[email-masked]]
> > Sent: Friday, May 10, 2002 1:03 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Marcus,
> > I think that IETF, especially NSIS, should not become a 
> > kitchen sink for 
> > all possible combinations of network architecture. We belong to an 
> > engineering community here, that is, we need to try our best 
> > to come up 
> > with some practical solutions for some practical problems.
> > 
> > Hence, could any *non-research* provider please please tell 
> me if and 
> > when they will deploy BB to their customers?  If there is a 
> > real demand 
> > for BB, we should look into it in IETF (not sure within the 
> scope of 
> > NSIS neither)? Otherwise, why not push the work to other 
> > places, such as 
> > IRTF?
> > 
> > 2 cents,
> > 
> > - Ping
> > 
> > 
> > 
> > Marcus Brunner wrote:
> > 
> > > I am sorry, but I could not refrain from asking what Internet 
> > > Architecture BB are not part of?
> > > 
> > > Otherwise I agree with John, the reqs and framework should 
> > allow for 
> > > various QoS architectures (including BB kind of 
> > architectures), defined 
> > > by the IETF.
> > > 
> > > Marcus
> > > 
> > > --On Friday, May 10, 2002 11:25 AM +0300 
> > [email-masked] wrote:
> > > 
> > >> Hi all,
> > >>
> > > --------------------------------------
> > > Dr. Marcus Brunner
> > > Network Laboratories
> > > NEC Europe Ltd.
> > > 
> > > E-Mail: [email-masked]
> > > WWW:    http://www.ccrle.nec.de/
> > > personal home page: http://www.brubers.org/marcus
> > > 
> > > 
> > >

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Wed, 15 May 2002 10:51:48 -0400

Hi, John.

As far as I understand when you are talking about centralized approach you
mean an approach to the resource provisioning. As we agreed resource
provisioning is out of NSIS scope anyway so there is no reason to get into
this discussion. That is exactly the reason why I like so much QoS Initiator
- QoS Controller terminology. It helps us not to deal with distributed and
centralized approaches at all (or deal with them in uniform fashion -
whatever you like more). Then the issue of having one or many QCs within
domain becomes the issue of local QoS technology/provisioning rather than
signaling. 

What I am looking for is very similar to Ruediger (I think) - the QoS
signaling that will make interoperability between domains using different
QoS technology easy (possible) and uniform. I do not what to deal with
Intserve over Diffserve, Intserve over MPLS etc. I would like to end up with
NSIS between all sorts of domains.

My 2 cents.

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 4:48 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] To BB or not to BB 

Hi Rüdiger,

John

---

From: [email-masked]
Date: Wed, 15 May 2002 20:56:37 +0300

Hi,

> I read the draft ¨Requirements for QoS Signaling Protocols¨and I found that
> the definition of the QoS signaling makes no difference between out-of-band
> signaling and in-band signaling. So, for the next version of the draft it
> should be necessary to define such things. Also, we must to speek o the
> level 3 (network level). For QoS there are many signalization methods using
> IP header so NSIS should not forget of them.

Feel free to document this.  I am aware of them, but documentation 
is always helpful.

Thanks,
John

---

From: "Schneider, Marco" <[email-masked]>
Date: Fri, 31 May 2002 12:24:51 -0500

Illya,

I like how you have phrased the problem here as "the QoS signaling that will
make interoperability between domains using different QoS technology
easy(possible) and uniform. I would only add that perhaps the most important
case of "different domains" is the user to the network.

Marco

> From: Freytsis, Ilya [mailto:[email-masked]]
> Sent: Wednesday, May 15, 2002 9:52 AM
> [email-masked]