The MPLS-OPS Archive

[Eric Osborne <eosborne@cisco.com>]

> >1. Is it possible to bind a label to an MPLS experimental bit across a 
> >network ? The idea is to have only 1 LSP per application (i.e. voice, exp. 
> >bits = 5), regardless the number of customers for MPLS VPN service? If 
> >this is feasible, will that raise a security issue (because no traffic 
> >separation).
> 
> 
> It is my understanding that labels are assigned on a per-flow per-customer 
> basis. This means that if Customer A has two streams of traffic with the 
> same priority and the same next-hop destination, those two streams become a 
> single flow and will share a single label for that hop. The same type of 
> traffic from Customer B will have a different label over the same next-hop. 
> In this way the two customers' traffic flows will be kept separate even 
> though they have the same priority.
> 

This is certainly possible, but not the way TE was intended to be
used, nor how at least one implementation out there behaves.  Think of
a TE LSP as a unidirectional traffic trunk between two nodes in the
provider's network.  Customer A and Customer B traffic between the
same two nodes takes the same trunk.  Seperation is done by DiffServ
and EXP bits.

> 
> >2. What's the behavior of RSVP, when it's configured to constrain & 
> >reserved a 20 MB? Will it maintain 20MB LSP permanently regardless the 
> >traffic usage (no tear down)?
> 

Yes.  But in at least our implementation, the reservation is
control-plane only.  The idea is to build a reservation for something
like 95th percentile of your traffic between two points.

> I believe there is something of a history in how well the constraints are 
> imposed and how well by a given platform, but those internal to Cisco (as 
> one source) could comment on that. In any case, there are variants. RSVP 
> can reserve bandwidth with a priority. If later a tunnel is built with a 
> higher priority,the tunnel with lower priority will be torn down so the 
> bandwidth can be allocated to the higher priority tunnel. There are two 
> figures here for any tunnel (I will call the tunnel "Tunnel A"). One figure 
> establishes the priority level that a new tunnel must have to bump Tunnel 
> A, and the other is the priority of Tunnel A to bump other tunnels. (I hope 
> I have that right, I am a bit vague here). I don't remember whether tunnels 
> unused will time out but I don't believe they do. However, non-tunnel 
> traffic of a lower priority can flow on that bandwidth when Tunnel A is not 
> being used. I am vague on whether lower priority tunnels can come up again 
> when Tunnel A is unused but still in place. I think not, but maybe others 
> can comment. Obviously we don't want the bandwidth to be unavailable to 
> others in the way empty time slots in a T1 or E1 line are.

All this stuff about priority is true, but seems to not actually be
the answer to the question. :)  If a tunnel makes a reservation,
it holds that reservation regardless of actual use of the LSP (modulo
stuff like cisco's auto-bandwidth, but there's no magic there).

> 
> 
> 
> >3. If it's not maintained permanently, who's controlling the actual bw 
> >available for the provisioning ? I meant, assuming a total 30MB bw, the 
> >first LSP has been configured with 25MB. Could I create another LSP with 
> >10MB bw ? It's sort of overbooking ;-)
> 
> There is one way to overbook that I know of. You can create what amount to 
> fallback tunnels for Tunnel A. If Tunnel A fails, Tunnel B comes into play 
> already set up with reserved bandwidth. However, that bandwidth is not 
> claimed until Tunnel B comes up, so it is available for other tunnels or 
> other traffic in general.

You can overbook two different ways:
    - reserve less bandwidth than you know an LSP needs
    or
    - advertise more capacity than you know a link has

there are tradeoffs either way.

> 
> One thing you have to keep in mind also is the difference between a tunnel 
> with its reserved bandwidth and the bandwidth of the entire pipe. An LSP 
> could go through the pipe using the tunnel bandwidth or not, depending on 
> other circumstances. If tunnels claim the entire bandwidth of the pipe at a 
> higher priority than regular non-tunnel traffic over the same link, it is 
> my understanding that the regular traffic will only flow when tunnel 
> traffic is not flowing.

Not at least in our implementation; traffic seperation is only done
with EXP/DSCP/IPPrec bits.

> 
> 
> 
> >3. For dynamic LSP, what's the behaviour of RSVP when it fails to find the 
> >required bw for its LSP ?

the LSP won't come up.  there are vendor-specific knobs to mitigate this.

> 
> If, after trying every possible path to the destination, RSVP fails to find 
> enough available bandwidth, the tunnel will not come up in the first
> place. 

RSVP does not try every path to the destination.  If a path is
determined dynamically, it's CSPF.  There are no explorer frames in
MPLS...:)


> No change happens to existing tunnels or other non-tunnel traffic, except 
> the traffic that was meant for the tunnel now travels via a non-tunnel LSP.
> 

or a regular IP routed path, depending on what happens at the headend.



eric

> 
> 
> 
> 
> 
> >TIA
> >
> >Aries C.
> >
> >
> >
> >
> >
> >_________________________________________________________________
> >MSN Instant Messenger now available on Australian mobile phones. Go to
> >http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp
> >
> >-------
> >The MPLS-OPS Mailing List
> >Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml