Subject: RE: [NSIS] Proposed NSIS charter

From: "Chen, Weijing" <[email-masked]>
Date: Thu, 1 Nov 2001 14:05:32 -0600

To make it simple, scalable, deployable, you really have to separate UNI
(User-to-Network) from NNI (Network-to-Network). Otherwise, all the network
information weight is carried over to user end device.

From service provider perspective, we have two basic requirements:

1. UNI signaling must be independent of the network and NNI signaling.
Choice of the network and NNI signaling is transparent to user device.
Separation of UNI from NNI ensures a simple UNI signaling which helps
widespread adoption in PC, appliance, handset, set top, gateway, router,
switch, wireless, etc.
2. UNI signaling must be multiprotocol, i.e. support different transport
technology (wireless, DSL, Ethernet) with different session mechanism (IP
flow, ATM VC, Ethernet VLAN, MPLS label).

 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent:	Thursday, November 01, 2001 8:54 AM
To:	[email-masked]'; Georgios Karagiannis (ELN)
Cc:	[email-masked]'; [email-masked]'
Subject:	RE: [NSIS] Proposed NSIS charter

Hi Jussi

I agree! the basic QoS signaling component should be 
as lightweight as possible, simple, very fast, scalable, etc.,

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 1 november 2001 15:42
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] Proposed NSIS charter

Hello Georgios,

I think that flexible/extendable QoS signaling is perfectly OK as far as
there exists some kind of lightweight, basic signaling component that can be
used in all cases as a simple, common "QoS language". 

Best Regards,
Jussi

> -----Original Message-----
> From: ext Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 01 November, 2001 14:32
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Proposed NSIS charter
> 
> 
> Hi Jussi
> 
> Please see my comments below.
> 
> [JR} I think that we have here a very fundamental 
> [JR]  question related to NSIS,
> [JR]  namely:
> 
> [JR]	- Do we want to create general purpose QoS signaling?
> 
> It depends, what do you mean by general purpose signaling.
> I think that it would be very interesting if we somehow 
> specify a flexible QoS solution that will consist of  
> different QoS protocol components.
> Some of these QoS protocol components will then be used for 
> QoS lightweight (simple, fast and scalable) solutions, 
> and other QoS protocol components will be used for more 
> complex QoS solutions, e.g., QoS required by the wireless link.
> 
> What I mean, is that you might probably use the same 
> QoS end to end protocol, that would be transparent 
> for certain IP domains, while for other IP domains it would
> operate as a lightweight QoS protocol and in other domains 
> it would be used as a more complex QoS protocol. This usage
> is depending on the characteristics and requirements of 
> the IP domains.
> 
> This QoS solution might be an extended 
> existing QoS protocol.
> 
> 
> Best Regards,
> Georgios
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: donderdag 1 november 2001 11:51
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Proposed NSIS charter
> 
> 
> Hello,
> 
> I think that we have here a very fundamental question related to NSIS,
> namely:
> 
> 	- Do we want to create general purpose QoS signaling?
> 
> An alternative is to create specialized versions targeted for certain
> interfaces, tasks, etc.
> 
> Personally, I feel that we should aim for the general purpose 
> signaling,
> since the common language between QoS systems, elements, and 
> technologies is
> exactly what we need right now. It is possible to make later optimized
> versions if/when really needed. Naturally, the big challenge 
> is to create a
> general purpose QoS signaling without ending with something too big,
> cumbersome and heavy.
> 
> Best Regards,
> Jussi 
> 
> 
> > -----Original Message-----
> > From: ext Chen, Weijing [mailto:[email-masked]]
> > Sent: 31 October, 2001 18:54
> > To: ''; [email-masked];
> > [email-masked]
> > Subject: RE: [NSIS] Proposed NSIS charter
> > 
> > 
> > John, Georgios,
> 
> ...
> 
> > To simplifying the signaling protocol, we can focus on UNI 
> > function, which
> > could be independent of NNI function. For service provider 
> > point of view, we
> > see clearly need of separation of  UNI signaling and NNI 
> > signaling. Maybe
> > NSIS is the right platform for UNI only signaling?
> >  
> > --
> > Weijing Chen
> > SBC Technology Resources
> > 9505 Arboretum Blvd.
> > Austin, TX 78759
> > 512 372 5710
> > [email-masked]
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/nsis
> 

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

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

---

From: Brian Williams <[email-masked]>
Date: Fri, 02 Nov 2001 10:18:00 +1100

I would also agree with the requirements of the basic component to be
simple, fast, scalable, ...
Of course, there are also different requirements in different domains of
the network (eg within an operator domain, customer to network,
end-to-end). This leads to the requirements for flexible, extensible,
etc. Requirements like these tend to work against each other. You may
manage to create the holy grail and satisfy all requirements reasonably,
the result may end up as a poor compromise for one or another of the
requirements, or the prblem space could be broken up into different
parts and more specific solutions targeted to each problem space. 

Whether different solutions are developed or one solution with flexible
capabilities, there will be a strong need to ensure that the solution(s)
work together in a reasonable manner for connections crossing multiple
domains. That is to say, interactions/interworking between the domains
with different mechanisms (or different flexible components) must be
considered. But again, I would think the interworking/interaction must
also be simple, scalable, etc.
/brian