Erik, here's my take on this although others may have
additional or different ideas. See inline...
>Hi,
>I saw your discussion below and I came to think of
>a couple of questions I have regarding MPLS-TE. Maybe you
>can help me with an answer.
>
>1) Can you set up RSVP-TE tunnels based on delay-requirements?
> I only see discussions and configurations regarding
> reserving a particular bandwidth.
Although regular RSVP has provisions for requesting certain
bounds in delay, I don't believe cisco can do this via
RSVP-TE. Admission control will probably only look at
reservable bandwidth, priority, and link attributes.
In my opinion, you could attack this problem several ways:
1-If you're able to, set the metrics throughout your domain
to reflect actual latencies from propogation delay from
either direct delay measurement or inferring it from the
fiber miles/kilometers. This only makes sense if your core
links have the same bandwidth (OC48 everywhere or whatever).
2-If you cannot change the regular IGP metric, advertise delay
via the IGP Traffic Engineering Metric.
http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt
http://search.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st18/delaysen.htm
With 1 and 2 above, the caveat is that your circuit/channel/
wavelength provider might change the route on you and make
the delay metrics inaccurate.
3-Use link attributes to force EF-type traffic over paths
you expect to have lowest latency (or let that be decided
via CSPF using 1 or 2 above) and/or where the outgoing
interfaces can do an appropriate queing (Strict PQ, LLQ) to
satisfy your PHB while introducing minimal delay.
4-Use global- and sub-pools to make sure your EF traffic
doesn't starve other classes of traffic during the
reservation phase (and configure your queuing similarly).
> Then of course how would you treat voip if the tunnel can not
> guarantee maximum delay.
> I have seen talks about using strict-priority for voip (LLQ, priority-queueing)
>
> Would the solution then be mapping voip to a RSVP-TE (guaranteeing bandwidth)
> and setting EXP to high value and use LLQ/priority-q-ing.
>
> Will this really give me what the customer wants in a
> heavily loaded network?
It's hard to say. It'd be great if one of the testgear
vendors came out with a Diffserv and DS TE package to
test whether the routers/switches can satisfy EF PHB per
the requirements set in RFC2598. I'm not aware of anyone
doing this (someone chime in if any vendor does this).
Or you can set your own requirements... does the gear
forward my voice traffic with no loss up to a certain
amount of bandwidth? Does the gear do so without starving
bulk traffic or interactive traffic? Is delay, jitter,
and out-of-order traffic at an acceptable minimum? Do
calls sounds good enough in a reasonable test mockup?
>2) EF-Expedited Forwarding what does it give us?
> As I understand it EF means setting the DSCP to a
> specific value instructing equipment to
> deal with the traffic as fast they can.
> But can you compare Expedited Forwarding in one
> vendors equipment with another vendors equipment?
> Is EF really saying anything?
Technically yes, if they can deliver the traffic in
accordance with RFC2598. Determining that is the issue.
> Will DSCP=EF be prioritized a head of DSCP=AF (Assured Forwarding of any sort)?
If the box is configured to do so, one would hope the
answer is "yes".
Sean
>Regards,
>Erik Johansson
>Email: erik.e.johansson@skanova.com
>
>
>-----Ursprungligt meddelande-----
>Från: eosborne@cisco.com [mailto:eosborne@cisco.com]
>Skickat: den 23 maj 2002 19:04
>Till: vravi@research.telcordia.com
>Kopia: crockers@mail.trinicom.com; cisco-nsp@puck.nether.net
>Ämne: Re: [nsp] Mapping traffic into MPLS tunnels
>
>
>On Thu, May 23, 2002 at 11:28:07AM -0400, Ravichander Vaidyanathan wrote:
>>
>> Sean,
>>
>> >
>> > I didn't realize VRFs were part of this scenario... are you
>> > putting L3 VPNs into TE LSPs? My question is, why would you
>> > want to apply PBR to VPNs? Do you want to shunt certain
>> > classes of traffic into LSPs that get different CoS treatment
>> > by LSRs? You might be able to just mark EXP bits using
>> > MQC- provided the hardware can do it- and let it go across
>> > an LSP to the other PE via normal routing.
>> >
>>
>> The guaranteed bw feature of TE LSPs could be useful for supporting
>> customers who are willing pay for it. Shunting VPNs into TE LSPs with
>> guaranteed bw helps ensure that this bw constraint can be met for the VPN
>> customer.
>
>True, but you need to be careful here. Just putting traffic into TE
>LSPs isn't enough; if you also have non-TE traffic on the network,
>there's no special queueing done to ensure that TE LSPs get any sort
>of bandwidth assurance. You need to do this with IP Prec/EXP bits.
>
>>
>> The other philosophy that you brought up is to use COS with the EXP
>> bits. Is there IOS support for classifying traffic into different queues
>> (say WFQ) based on the MPLS EXP bits?
>
>I don't view this as another choice vs. TE, but a complementary
>approach. Use TE to spread out all your traffic, and diffserv to
>handle temporary bursts/congestion at every hop.
>
>Like Sean said, yes, generally you can do MPLS EXP queueing. Some
>configurations let you specify the EXP seperately, some only allow you
>to configure queueing for IP Prec, but MPLS EXP is generally treated
>the same way as IP Prec.
>
>
>
>eric
>
>>
>> thanks,
>> Ravi
>
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:45 EDT