The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Fwd: RSVP and LSP Questions
Aries, I will take a shot at some of your questions, and maybe get some answers correct. I hope others will correct me where I am wrong and add their own pieces, as your questions are very good ones. Look for the answers in line. I will pick away at some of the questions in your other notes over the weekend; a neighbor's floor is calling me. Roger Williams >Resent-Date: Fri, 21 Feb 2003 13:24:41 -0500 >X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to >mpls-ops-request@mplsrc.com using -f >X-Originating-IP: [202.166.126.231] >From: "Aries C" <cariesc@hotmail.com> >To: mpls-ops@mplsrc.com >Date: Fri, 21 Feb 2003 18:07:00 +0000 >X-OriginalArrivalTime: 21 Feb 2003 18:07:00.0851 (UTC) >FILETIME=[07E49430:01C2D9D4] >Subject: [MPLS-OPS]: RSVP and LSP Questions >Resent-From: mpls-ops@mplsrc.com >X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/5360 >X-Loop: mpls-ops@mplsrc.com >Resent-Sender: mpls-ops-request@mplsrc.com > >Hi All, > >I have 2 questions : > >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. >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)? 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. >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. 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. >3. For dynamic LSP, what's the behaviour of RSVP when it fails to find the >required bw for its LSP ? 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. 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. >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
|
|