Hi,
I think that it is very unlikely that we see customers asking their ISPs
for different voice service levels, probably they won't even know and/or
care of picking up one as long as they get a voice grade of service
similar to existing fixed telephony services. IMHO, I would say that one
way of describing services would be to say that a given application or
end-to-end service should receive a treatment that is
similar/equivalent to an end-to-end voice service. This assumes that ISP's
know what a voice grade service is and are then able to set the resources
for it. If we throw in too much service specifications onto the service
granularity, as it seems to be the case from the tequila and other
documents, I think that although the desired result seems desirable its
complexity may not reasonable. This is somehow similar to the DiffServ
approach, let's try to keep things simple. Why not standardise or specify
few (3 or 4) discrete service classes and fit the rest of the negotiation
within this simple framework?
Regards,
DJamel
On Wed, 25 Oct 2000, GARBISU Jean-Pierre FTRD/DMI/CAE wrote:
> Hi
> About the "Network Services", even if it doesn't (perhaps) fit exactly what
> S. Salsano have in mind, I would like to add the following :
> IMHO these network services are essential.
> I can't see how any kind of customers'e2e SLSs could be individually
> processed in the backbones supporting QoS services.
>
> To give an example, VoIP. One could imagine that all customers of an ISP
> don't ask for exactly the same SLS's metrics e.g some customers ask for 100
> ms OWD between their CPEs, others ask for 80 ms, other for 120 etc (based on
> different gateways needs, different access lines speeds etc.). The ISP could
> decide to implement only one VoIP network service wrt the OWD metric (e.g.
> 50 ms) between its PoPs instead of implementing (within all its backbone QoS
> toolbox : TC, TE, etc.) 3 VoIP OWD metrics. The "generic" network service in
> the core permits to handle varied specific e2e SLS.
>
> Another example could be ERP applications (e.g. transactional business
> critical applications). All customers don't share the same ERP apps but
> generally one could imagine that customers could ask for a prioritized e2e
> QoS service for them (e.g. somewhere between real time needs and best effort
> needs; OWD varying between a few hundred ms and a few secondes). The ISP
> could decide to implement one or two generic ERP network services which
> should cover the needs of a large variety of customers applications instead
> of trying to implement specific PoP to PoP service per ERP type.
>
> Finally it seems well established that the closer you get from the core
> networks, the fewer CoS (if ever) and dynamicity you should consider,
> compared to greater variety of CoS and dynamicity you can try to implement
> at the access.
> That's why mapping of (possibly numerous) e2e SLS on (few) PoP to PoP
> network services seems very attractive.
>
> Best regards.
>
> jeanpierre.garbisu@francetelecom.fr
>
>
> -----Message d'origine-----
> De : Michael Smirnov [mailto:smirnow@fokus.gmd.de]
> Envoyé : mercredi 25 octobre 2000 00:52
> À : sls@ist-tequila.org; brunner@ccrle.nec.de
> Cc : cak@cin.ufpe.br
> Objet : Re: [tequila/sls] predefined services / SLS ?
>
>
> Hi,
>
>
> On Tue Oct 17 17:42:18 2000 Stefano Salsano wrote:
>
> <...>
> > What is interesting is that we found the need to have pre-defined
> > SLSs (we called it "Network Services" but the name can be misleading):
> > for ease of negotiation and implementation only a subset
> > of parameters can be specified, while the others are given by default
> > with reference to a small set of "well known services".
> > This is in perfect agreement with your idea that a well-known service
> > identifer is just a compression of the SLS for ease of negotiation.
>
> can you provide examples of "Network Services"?
>
> Thanks in advance
>
> Michael
>
This archive was generated by hypermail 2b29 : Mon Oct 30 2000 - 12:08:13 CET