Re: [mpls] doubt on RSVP-TE over non RSVP cloud
Santanu Ganguly <sgangoly07@gmail.com> Tue, 03 March 2009 21:50 UTC
Return-Path: <sgangoly07@gmail.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A205F28C10B for <mpls@core3.amsl.com>; Tue, 3 Mar 2009 13:50:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSccZcxRZEK8 for <mpls@core3.amsl.com>; Tue, 3 Mar 2009 13:50:00 -0800 (PST)
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by core3.amsl.com (Postfix) with ESMTP id CC4C23A69A0 for <mpls@ietf.org>; Tue, 3 Mar 2009 13:49:59 -0800 (PST)
Received: by mu-out-0910.google.com with SMTP id w9so1233813mue.9 for <mpls@ietf.org>; Tue, 03 Mar 2009 13:50:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=22RvUSMre0AA+nBbVbrzUw6Iqf6OqtYuRh1PXch5nl0=; b=R2pzqXY1VnqBQSCCYb+V+8umsKtu7Up15gJuav71ep+o0e+Go88FD7Y5C+ooaTTlUk JDMs30mjPderGW7lztmmrETPOeoMAtuLOO9YgBdyrop6Za855BVT4jNgu4GU5dEfjZb4 rDpXFtO6kjsvRkq9ocNLXnjxYYHVw19vqySR0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K4Cyw17FAdU5ColZEtUzn/bxb/1FS3Dp8W907ZWGLCu5KwhtCd1D4PfG4KZxSL+A0l /kL1ykuOv7PuBSUMqFhhmBhccsGe+UczWTDwJ3MG+cejfDd2jFXcTQGFOgFpG5Akqqqh 0NgQz3Co9nc3cdWFxaIqDimKlIWSrVfx1piOo=
MIME-Version: 1.0
Received: by 10.103.217.5 with SMTP id u5mr3775818muq.118.1236117026452; Tue, 03 Mar 2009 13:50:26 -0800 (PST)
In-Reply-To: <a0d41f8e0903030149m784463c0y5a6865082bc06eda@mail.gmail.com>
References: <a0d41f8e0903030149m784463c0y5a6865082bc06eda@mail.gmail.com>
Date: Tue, 03 Mar 2009 21:50:26 +0000
Message-ID: <d67f43ae0903031350g6907fd3ahc88f1c32ad16e458@mail.gmail.com>
From: Santanu Ganguly <sgangoly07@gmail.com>
To: Santosh P K <sanpk316@gmail.com>
Content-Type: multipart/alternative; boundary="001636765b864336c304643dec8d"
Cc: mpls@ietf.org, santanu.ganguly@riverbed.com
Subject: Re: [mpls] doubt on RSVP-TE over non RSVP cloud
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 21:50:01 -0000
On Tue, Mar 3, 2009 at 9:49 AM, Santosh P K <sanpk316@gmail.com> wrote: > > Hi All, > > As per RFC 3209 it mentions that RSVP-TE LSP can’t be established over non RSVP-TE could. Is it because there is no use case scenario of TE-LSP over non RSVP-TE?. Can you please provide me some use case scenario if any. > > > > Thanks and regards > > Santosh P K > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls Hi Santosh, An RSVP-signaled LSP has the property that its path does not necessarily follow the path that would be dictated by the IGP. RSVP, in its extended form, has explicit routing properties in that the ingress router can specify the entire end-to-end path that the LSP must follow, or can specify that the LSP must pass through particular transit nodes. A single LSP requires only one RSVP session, yet can carry all the traffic between a particular ingress and egress router pair, containing many end-to-end flows. The intermediate LSRs on the LSP need to know what the incoming and outgoing labels are for the particular LSP for that TE tunnel. The intermediate LSRs can only learn the labels if the head end router and intermediate LSRs signal the labels by a signaling protocol. In the past, two signaling protocols were proposed: RSVP with extensions for TE (RSVP-TE) and constraintbased LDP (CR-LDP). For e.g., Cisco IOS has RSVP with extensions for signaling MPLS TE tunnels and not so strong on CR-LDP. At the Internet Engineering Task Force (IETF), consensus was reached to carry on with developing RSVP as the signaling protocol for MPLS TE and to stop further development on CR-LDP ( I think...I maybe wrong..). This was documented in RFC 3468, “The Multiprotocol Label Switching (MPLS) Working Group Decision on MPLS Signaling Protocols.” The following is a quotation from the abstract of that RFC: This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on “Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels” (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to “Constraint-Based LSP Setup using Label Distribution Protocol (LDP)” (RFC 3212). The nature of RSVP TE LSP depends also on vendor interpretation and implementation. For e.g., Inside Cisco IOS, a TE database is built from the TE information that the link state protocol sends. This dataset contains all the links that are enabled for MPLS TE and their characteristics or attributes. From this MPLS TE database, path calculation (PCALC) or constrained SPF (CSPF) calculates the shortest route that still adheres to all the constraints (most importantly the bandwidth) from the head end LSR to the tail end LSR. PCALC or CSPF is a shortest path first (SPF) algorithm modified for MPLS TE, so that constraints can be taken into account. The bandwidth available to TE and the attributes are configurable on all links of the networks. You configure the bandwidth requirement and attributes of the TE tunnel on the tunnel configuration of the head end LSR. PCALC matches the bandwidth requirement and attributes of the TE tunnel with the ones on the links, and from all possible paths, it takes the shortest one. The calculation is done on the head end LSR. RSVP came into being before MPLS and was originally invented to create bandwidth reservations for various individual traffic flows in networks (e.g. a video telephony session between a particular pair of hosts) as part of the ‘int-serv’ model. RSVP includes mechanisms for reserving bandwidth along each hop of a network for an end-to-end session. However, the original int-serv application of RSVP has fallen out of favor because of concerns about its scalability. *References*: 1) "MPLS-Enabled Applications" by Ina Minei and Julian Lucek. John Wiley & Sons, 2005 2) "MPLS Fundamentals" by Luc De Ghein. Cisco Press, 2006 cheers santanu
- [mpls] doubt on RSVP-TE over non RSVP cloud Santosh P K
- Re: [mpls] doubt on RSVP-TE over non RSVP cloud Santanu Ganguly