Jaroslaw,
I think the list is discussing a particular case for SLS over
DiffServ networks (SLS_DS), hence (PHBID,DSCP) and their mapping.
If you want SLS_generic be defined for internal parameters [Brian],
then, for DiffServ you'll need to define (SLS_generic, SLS_DS) mapping.
Am I missing your point?
cheers
Michael
On Thu, 8 Feb 2001, Jaroslaw Sydir wrote:
> I think that the SLS should be specified in a way that is independent of
> the underlying technology used to implement the service. So I don't
> think
> that the SLS should contain PHBIDs or DSCPs. The network should map the
> service
> described in an SLS into a PDB, which in turn is mapped to a PHB at each
> hop.
> It seems contrary to the diffserv architecture to have end users specify
> the PHB
> that should be applied to their flow.
>
> Jerry Sydir
>
>
> Brian E Carpenter wrote:
> >
> > As I implied in another note, I think the SLS needs to describe both
> > the external parameters (the ones that the SLA will require to be met)
> > and the internal parameters (the ones the QOS management system will
> > use to configure diffserv, intserv, traffic engineering etc.)
> > An SLS is a technical device, not a contract. Of course, the internal
> > parameters don't all have to be exposed to the other party at a border.
> > But the PHBID and DSCP mapping may need to be, if the upstream traffic
> > source is doing its own shaping and marking.
> >
> > Brian
> >
> > Yves T'Joens wrote:
> > >
> > > Brian E Carpenter wrote:
> > > >
> > > > A detail - what should be in an SLS is not the DSCP value,
> > > > but the PHBID value (RFC 2836) and the PHBID to DSCP mapping.
> > > > (this mapping may be different on the two sides of the border).
> > > > DSCP values are not invariants.
> > >
> > > one can ask for a certain 'network' forwarding behaviour (aka a SLS) for
> > > a specific 'flow', and get a DSCP to apply to the stream back from the
> > > provider. As such, the DSCP has only value on the access link itself,
> > > and of course the provider is free to change this to another value at
> > > its border. I assume we have a different idea about the procedure of
> > > negotiation. Whether this DSCP is then used as indicator for PHB or not
> > > in the network is dependent on the QoS architecture used in the network,
> > > but should not be limited to diffserv.
> > >
> > > Yves
> > >
> > > >
> > > > Brian
> > > >
> > > > Yves T'Joens wrote:
> > > > >
> > > > > Brian E Carpenter wrote:
> > > > > >
> > > > > > Actually John, isn't that list rather focussed on one particular
> > > > > > approach to SLSs, wherease Demir's question is more general?
> > > > > >
> > > > > > I've been ruminating for some time whether, having figured out what
> > > > > > a PDB is, we could now figure out the parameters to be defined
> > > > > > in a generic SLS - and I don't think the tequila list is quite
> > > > > > in that space. Correct me if I'm wrong.
> > > > >
> > > > > imho, a PDB is a piece to the puzzle, when relying explicitly on per hop
> > > > > behaviour adherence in each hop along a 'known path' in the domain. one
> > > > > can define an SLS that exactly maps on the parameters of e.g., the
> > > > > virtual wire PDB. However, it doesn't stop there.
> > > > >
> > > > > The SLS discussed on the sls@ist-tequila.org list is somehow more
> > > > > generic applicable then to diffserv networks. One could assume the DSCP
> > > > > to be part of a flow descriptor on the access link to an IP domain (of
> > > > > which a diffserv domain is an example) if it is available.
> > > > >
> > > > > as to demir's questions :
> > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > John Schnizlein wrote:
> > > > > > >
> > > > > > > There is a mailing list for Service Level Specification.
> > > > > > > Please take these questions there.
> > > > > > >
> > > > > > > To subscribe send mail to <Majordomo@ist-tequila.org> with
> > > > > > > the following command in the body of your email message:
> > > > > > > subscribe sls
> > > > > > >
> > > > > > > At 11:32 AM 02/01/2001 -0800, demir wrote:
> > > > > > > >Is there any assumption(s)/constrain(s) on the relationship between SLA
> > > > > > > >and service class; such as an SLAs are only for per service class (mapped
> > > > > > > >into a DSCP)- meaning there can be only one SLA per service class between
> > > > > > > >two domains/there can be at most N SLAs where a DS domain is supporting N
> > > > > > > >service class?
> > > > >
> > > > > if packet flows at an ingress link are also characterized by e.g. a
> > > > > destination prefix, then the combination of DSCP and destination prefix
> > > > > may identify different streams, with as such different QoS. e.g., one
> > > > > has a maximum delay of 20 ms (because it is on the same ISP network),
> > > > > the other has service class (low delay, not quantified, since it is
> > > > > transfered to another ISP network.
> > > > >
> > > > > > > >if the answer is "NO", is it realistic to assume that applications
> > > > > > > >(/microflows) might ask for a "dynamic SLA"? If so, I assume a source
> > > > > > > >domain might have more than one SLA per service class (for the sake of
> > > > > > > >simplicity, I assume an application has an SLA interface).
> > > > > > > >
> > > > > > > >Any idea/insight/comment? Thank you very much.
> > > > >
> > > > > dynamic SLSses are theoretically feasible. in practice, much will depend
> > > > > on the implementation that is adhered for negotiation of the SLSs.
> > > > >
> > > > > see also http://www.ist-tequila.org
> > > > >
> > > > > > > >
> > > > > > > >Alper K. Demir
> > > > >
> > > > > cheers
> > > > > Yves
> > >
> > > --
> > > +------------------------------------------------------------------+
> > > | Yves T'Joens |
> > > | Project Manager Internet Access and Edge |
> > > | Alcatel Network Strategy Group |
> > > | Francis Wellesplein, 1 phone : +32 (0)3 240 7890 |
> > > | 2018 Antwerp fax : +32 (0)3 240 9932 |
> > > | Belgium email: yves.tjoens@alcatel.be |
> > > +------------------------------------------------------------------+
> >
> > --
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > Brian E Carpenter
> > Program Director, Internet Standards & Technology, IBM
> > On assignment for IBM at http://www.iCAIR.org
> > Board Chairman, Internet Society http://www.isoc.org
> > Non-IBM email: brian@icair.org
>
This archive was generated by hypermail 2b29 : Thu Feb 08 2001 - 19:34:28 CET