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