Subject: RE: QoS and Labels: A question ??

From: "Vipul Sharma" <[email-masked]>
Date: Tue, 23 Jan 2001 17:53:53 -0500

OOps I meant 2 services in ur server (NOT PC). Also, a couple of points, to
have two LSPs you have to be able to recognize and classify traffic to each
service in the server seperately at the ingress LSR (which may involve L3 or
above).  Thanx.

Vip

-----Original Message-----
From: Vipul Sharma [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 5:44 PM
To: 'Arturo Nunez'; [email-masked]'
Subject: RE: QoS and Labels: A question ??

Arturo,
	This has to do with Forward Equivalency Class (FEC). Since the 2 services
in ur PC have different QoS req. you will like them to be handled diff. in
the Core network (perhaps to reflect their QoS). So you may have two LSP,
one for each service. Each LSP corresponds to a FEC.
	There is EXP bits in the MPLS Label that is there to convey the QoS info.
Hope this helps and experts in this subj. pls. feel free to correct me if I
am wrong. Thanx.

Vip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Arturo
Nunez
Sent: Tuesday, January 23, 2001 5:25 PM
To: [email-masked]
Subject: QoS and Labels: A question ??

Hi:
	I have a doubt about the relation between Labels and the QoS ??
	For example in  the follow network:

PC ==== Ingress LSR ---- Core Network[LSR] ------ Egress LSR === Server

	+ I have a 2 services that are running in the Server, with QoS
	different.
	+ Now if I connect from the PC,notice its one, to the Server for the 2
	services. Will I have 2 LSP ?? Hows is connected the QoS with the labels
	?

	Regards
	Arturo Nunez

---

From: "Zhao, Xingguo" <[email-masked]>
Date: Tue, 23 Jan 2001 16:54:50 -0600

-----Original Message-----
From: Vipul Sharma [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 4:44 PM
To: 'Arturo Nunez'; [email-masked]
Subject: RE: QoS and Labels: A question ??

First, I guess you probably won't run MPLS from your PC to Ingress LSP.
Maybe it is just access protocol such as PPPoA.
But you surely may have some SLA with the Ingress LSR, so he can
classify/police your packet based on the contract.

Second, For scalability, I guess the MPLS network will implement MPLS Diff
Serv which supports both E-LSP and L-LSP.

Your packet will either go through an E-LSP or L-LSP based on the CoS of
your packet.

The E-LSP or L-LSP will then satisfy the QoS requirement of your packet
without a hard guarantee due to the nature of DiffServ.

Xingguo

Arturo,
	This has to do with Forward Equivalency Class (FEC). Since the 2
services
in ur PC have different QoS req. you will like them to be handled diff. in
the Core network (perhaps to reflect their QoS). So you may have two LSP,
one for each service. Each LSP corresponds to a FEC.
	There is EXP bits in the MPLS Label that is there to convey the QoS
info.
Hope this helps and experts in this subj. pls. feel free to correct me if I
am wrong. Thanx.

Vip

-----Original Message-----

Hi:

	+ I have a 2 services that are running in the Server, with QoS
	different.
	+ Now if I connect from the PC,notice its one, to the Server for the
2
	services. Will I have 2 LSP ?? Hows is connected the QoS with the
labels
	?

	Regards
	Arturo Nunez

---

From: Jay Wang <[email-masked]>
Date: Tue, 23 Jan 2001 16:54:50 -0800

> 
> The EXP bits are for conveying DiffServ priority levels.  If 
> you simply
> want to prioritize best-effort traffic, and your switches can suport
> E-LSPs, then this is the way to do it.
> 
> If you need actual QoS guarantees, or if your switches only support
> L-LPSs, or if you want the two service levels to be routed
> independantly, then you need to create a separate LSP for each service
> level.  

No, I don't think this is the intention of draft-ietf-mpls-diff-ext(-07),
in which it was clearly stated that:

   "Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the
   pre-configured mapping are capable of transporting the same common
   set of 8, or fewer, BAs. Each of those E-LSPs may actually transport
   this full set of BAs or any arbitrary subset of it."

That is, each E-LSP allows up to 8 combinations of <PSC, drop-precedence>.
With other mechanisms (in a Diffserv TCB) this would allow you to tansport 
flows with different "QoS quarantees" using just one LSP (and fortunately
so).

- Jay

> CR-LDP or RSVP-TE can be used for signalling the QoS
> requirements for the two LSPs.
> 
> -- David
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 24 Jan 2001 09:30:55 -0800

Hi David,

To reiterate Jim's comments, I think you may be looking at Intserv concept. Diffserv can use both E-LSP and L-LSP to guarantee an aggregate QoS (not per microflow QoS). 

It is true that you could use Intserv with MPLS for a finer controlled QoS (per microflow QoS), and the result probably looks very similar to L-LSP, in which the QoS is derived from the Label context. But they are totally different solutions.

Yours,
-Shahram

P.S. you could also signal the meaning of EXP in E-LSP. This method is called Signaled E-LSP versus the Configured E-LSP.

> From: Jim Boyle [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 11:13 AM
> To: David Charlap
> Cc: [email-masked]
> Subject: Re: QoS and Labels: A question ??
> 
> 
> 
> 
> That is the difference between diffserv and intserv, I 
> believe.  Diffserv
> doesn't aim to give hard guarentees to individual flows.  
> Diffserv, and
> "E-LSPs", work.
> 
> Jim
> 
> 
> On Wed, 24 Jan 2001, David Charlap wrote:
> 
> > Bora Akyol wrote:
> > > 
> > > >>>>> "David" == David Charlap <[email-masked]> writes:
> > > 
> > >     David> If you need actual QoS guarantees, or if your
> > >     David> switches only support L-LPSs, or if you want the two
> > >     David> service levels to be routed independantly, then you
> > >     David> need to create a separate LSP for each service level.
> > >     David> CR-LDP or RSVP-TE can be used for signalling the QoS
> > >     David> requirements for the two LSPs.
> > > 
> > > David
> > > 
> > > You are making assumptions about a particular switch
> > > architecture when you assert that you can not do "actual" QoS
> > > guarantees with E-LSPs. If you have a policer and a
> > > shaper/scheduler that can process the EXP bits as well as the
> > > label, then doing "actual" QoS is quite possible with
> > > E-LSPs.
> > > 
> > > Not only that, but you can map traffic destined to the same
> > > prefix to different EXP levels based either on Diffserv bits or
> > > on packet content. This also applies to VLAN tags.
> > 
> > The meaning of the EXP bits is not signalled.  It must be 
> preconfigured
> > network-wide.  And in order to be useful, they must be 
> identical across
> > the entire network.  Which limits you to 8 different service levels,
> > network-wide.
> > 
> > If you use the EXP bits to define a priority level and two flows are
> > both assigned that level, they will be queued in best-effort fashion
> > relative to each other.  There is no way to guarantee the individual
> > flows any particular level of service.  You can only guarantee the
> > aggregate of one class relative to another class.
> > 
> > Using L-LSPs, you can request a separate label, and a 
> separate resource
> > reservation for every flow, if needed.  This is the only way to
> > guarantee this level of service.  (Unless you're willing to 
> limit each
> > DS code point to a single flow, which is a ridiculous concept.)
> > 
> > E-LSPs are useful, no doubt about that.  But they can not 
> provide the
> > level of QoS necessary to make sure that a single specific 
> flow can be
> > guaranteed the resources it requires.
> > 
> > -- David
> > 
>

---

From: Jay Wang <[email-masked]>
Date: Wed, 24 Jan 2001 11:28:20 -0800

Jim,

> Sent: Wednesday, January 24, 2001 8:13 AM
> To: David Charlap
> Cc: [email-masked]
> believe. Diffserv doesn't aim to give hard guarentees to individual flows.

> Diffserv, and "E-LSPs", work.
> 

I would not compare Intserv and Diffserv like that. I think the idea of
Diffserv 
is to provides the needed transport, on an aggregated basis (for better
scalability
of course), to achieve services that are specified by Intserv model (not
exclusively
of course). Even the Diffserv paradigm is built upon PHB and aggregation
concepts, 
it is still possible (and very feasible) to achieve per-flow QoS guarantee.

- Jay