Subject: CR-LDP and RSVP implementation

From: [email-masked]
Date: Mon, 19 Feb 2001 12:10:03 -0500

Hi Everyone,

I have a question regarding CR-LDP and RSVP implementation.

I guess it is possible that both CR-LDP and RSVP implementations will be
supported on one LSR.  However, is there any chance that both the
implementations will be called for one LSP setup?  Say, at the incoming
interface, CR-LDP will take the PATH message and pass it to some other MPLS
processes.  At the out going interface, RSVP will get some message from
other MPLS processes and does something in the middle and sends out another
PATH message to its neighbor node.

Thanks.

Regards,
Jane D. Jiang
[email-masked]
(301) 809-4497

---

From: David Charlap <[email-masked]>
Date: Mon, 19 Feb 2001 12:31:59 -0500

[email-masked] wrote:
> I guess it is possible that both CR-LDP and RSVP implementations will
> be supported on one LSR.

Definitely possible.  And quite probable in the future.

> However, is there any chance that both the implementations will be
> called for one LSP setup?  Say, at the incoming interface, CR-LDP will
> take the PATH message and pass it to some other MPLS processes.  At
> the out going interface, RSVP will get some message from other MPLS
> processes and does something in the middle and sends out another PATH
> message to its neighbor node.

I don't think so.

The only way I can picture such a setup would require a transit router's
ability to terminate one LSP, then initiate setup of another, and
connect them internally.  Theoretically possible, but difficult to
automate and of questionable utility.

I think you may find MPLS networks where RSVP-TE, LDP and CR-LDP are all
used for LSP setup at once.  And this may well result in multiple
redundant LSPs between edge nodes.  But each individual LSP will almost
certainly be set up through exactly one protocol.

-- David

---

From: "Manohar Ellanti" <[email-masked]>
Date: Mon, 19 Feb 2001 21:50:55 -0800

I think one commercial MPLS stack vendor has support for one side of LSP setup using LDP(CR) and the other using RSVP. I am not sure
about the extent of support. For instance Explicit and crankback semantics and how they can be translated between the two sides.

However I can imagine, instead of horizontal participation of the two signaling protocols, a vertical participation where a tunnel
might be setup using RSVP-TE and inside the tunnel number of LSPs to be setup using CR-LDP for instance.

Again probably it is best avoided using multiple signaling protocols over a single provider network. 2547 does mention use of LDP to
setup PE-PE tunnles. I remember a discussion on removing explicit reference to one particular signaling protocol from 2547. If 2547
does require LDP then probably the underlying physical connectivity between PE routers can be setup using RSVP-TE and VPNs
provisioned or PE-PE (per VPN specific) inner LSPs setup using LDP. Some one can  comment whether this makes sense.

-Manohar

---

From: Eric Gray <[email-masked]>
Date: Tue, 20 Feb 2001 10:18:43 -0500

David,

    Hmmm.  There is the interworking scenario:

  --- R1 --- R2 --- R3 ---

in which R1 only "speaks" CR-LDP/LDP and R3 only
speaks RSVP-TE (and maybe LDP).  In this scenario,
it is quite reasonable for R2 to "translate" between the
two protocols for LSP set-up.

    Also, there is very little difference between setting
up a single LSP through (for example) R2 above and
terminating one LSP (from R1, for instance), making
a new LSP (toward R3) and connecting them internally
(at R2) - as long as the mapping (might be a FEC) is
one-to-one from one LSP to the other.

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Tue, 20 Feb 2001 10:36:51 -0500

Manohar,

    Please see embedded comments below...

You wrote:

> I think one commercial MPLS stack vendor has support
> for one side of LSP setup using LDP(CR) and the other
> using RSVP. I am not sure about the extent of support.
> For instance Explicit and crankback semantics and how
> they can be translated between the two sides.

Whenever there are a number of elements cooperating to
communicate (in series, as it were), the limitations of
the things they might be able to communicate is likely to
be the intersection of their communication capabilities.

What you say above would be just as true if the same
protocol were in use but some of these features were
not supported at every node.

>
> However I can imagine, instead of horizontal participation
> of the two signaling protocols, a vertical participation
> where a tunnel might be setup using RSVP-TE and inside
> the tunnel number of LSPs to be setup using CR-LDP for
> instance.

This makes sense.  I believe you might find the opposite
could make sense in some scenarios as well.  It is even
conceivable that you could have alternating layers.

>
> Again probably it is best avoided using multiple signaling
> protocols over a single provider network. 2547 does
> mention use of LDP to setup PE-PE tunnles. I remember
> a discussion on removing explicit reference to one
> particular signaling protocol from 2547. If 2547 does require
> LDP then probably the underlying physical connectivity
> between PE routers can be setup using RSVP-TE and
> VPNs provisioned or PE-PE (per VPN specific) inner
> LSPs setup using LDP. Some one can comment whether
> this makes sense.

Certainly. :-)

For BGP-MPLS, it is necessary to have some protocol in
use to establish LSPs between non-adjacent BGP speakers
since - otherwise - the labels exchanged between such
speakers are not meaningful.  It also makes sense that the
protocol used should be in-tune with the IGP used to route
packets between these non-adjacent BGP speakers.  Hence,
LDP makes sense - although another protocol could be used.

I believe this is something like what the current state of affairs
with BGP-MPLS says.

---

From: David Charlap <[email-masked]>
Date: Tue, 20 Feb 2001 12:54:25 -0500

Eric Gray wrote:
> in which R1 only "speaks" CR-LDP/LDP and R3 only speaks RSVP-TE (and
> maybe LDP).  In this scenario, it is quite reasonable for R2 to
> "translate" between the two protocols for LSP set-up.

Would you want to have R2 translate one signalling protocol to another? 
This seems unmanagable and needlessly complicated.

In this scenario, I think it would make more sense to use LDP to signal
an LSP that terminates on R2.  R2 can then signal a different LSP that
goes through R3 to the edge of the MPLS cloud.  R2 can then configure
itself to forward packets between the two LSPs.

While the effect is the same, the mechanism is different.  It avoids a
few nasty problems that would result from the differences in the
protocols:

- RSVP-TE uses a different QoS representation from CR-LDP

- RSVP-TE explicltly LSPs from a known ingress router to a known
  egress router.  LDP distributes labels without a firm concept of an
  LSP during the signalling.  CR-LDP appears to be like LDP in this
  respect, although the presence of an explicit route mitigates the
  difference somewhat.

- There is no LDP or CR-LDP way to signal multiple LSPs that share
  resources.  (RSVP's "SE" reservation style)

These problems can all be worked around, of course, but it they can be
avoided altogether if the routers create two LSPs, connected at R2
intead of trying to signal one LSP with two protocols.

> Also, there is very little difference between setting up a single LSP
> through (for example) R2 above and terminating one LSP (from R1, for
> instance), making a new LSP (toward R3) and connecting them
> internally (at R2) - as long as the mapping (might be a FEC) is

In the data plane, there is no difference.  But the setup procedures
will be different.  IMO, the two-connected-LSP method will be simpler.

-- David

---

From: Eric Gray <[email-masked]>
Date: Tue, 20 Feb 2001 17:04:29 -0500

David,

    Let me do a little constructive reasoning.

    IF it is not possible to create an LSP from R2 forward that
- even closely - matches LSP(s) we are going to consider
terminating at R2, then there will necessarily be some degree
of complexity associated with both the process of determining
what sets of LSPs to signal (to R2 and beyond R2) and the
process of mapping data arriving on an LSP to R2 onto an LSP
going forward from R2.

    There will definitely be zero or more traffic streams to which
this will apply in any case.

    Let's assume that for one or more traffic streams, however,
there is a simple mapping of data arriving on an LSP to R2 to
an LSP going forward from R2.  Let's call the arriving LSP,
LSP-A and the departing LSP LSP-A'.  If this is the case,
then it is very likely the case that requirements for forwarding
packets on LSP-A are a subset of requirements for packet
forwarding on LSP-A' since - if this is not the case - packet
forwarding resources associated with LSP-A will have been
needlessly expended since the same resource commitment
does not exist for LSP-A'.  Similarly, the reverse is true: if
resources are committed for LSP-A' and not for LSP-A.  As
near as I can tell, this applies generally to all kinds of resources
- including built in fault-tolerance, queuing behavior, etc.

    This being the case, then R2 should not commit resources
for LSP-A until it is known that it can create LSP-A' or can
otherwise ensure that packets will obtain similar consideration
and treatment going forward from R2.

    In my mind, that implies that R2 should signal to obtain LSP-A'
prior to "granting" LSP-A.  Not only does this compare closely
to "tranlation" of the signaling message, but it also preserves the
"ordered control" mode common to both RSVP-TE and CR-LDP.

    Moreover, the example given was deliberatly simplistic.  How
will either RSVP-TE or CR-LDP satisfy an explicit routing for
an LSP if the egress is not within the same signaling domain?  It
would be a lot simpler for the user if they can setup LSPs across
multiple signaling domains within their administrative domain -
as opposed to having to treat each signaling domain as if it is
also an administrative domain.

    Finally, in following the development of both RSVP-TE and
CR-LDP, one thing I can definitely say is that a lot of effort
has gone into making sure that there was very little you could
do (in terms of providing a service) with one protocol that you
could not also do with the other.  I think I would focus on the
types of services that you can provide with either or both - this
being a larger number than the kinds of services you cannot.

    Please see embedded comments below.

--
Eric Gray

> This seems unmanagable and needlessly complicated.

In most cases, there are some very simple and - in many cases -
fairly obvious mappings form the objects in one protocol to the
analog objects in the other.  These mappings require very little
in the way of configuration (defaults will work in most cases)
- especially in comparison with the management effort I would
think would be associated with seperate LSP setup.

> itself to forward packets between the two LSPs.

In some (zero or more) cases, this may be necessary. In theory, this
couldbe necessary for all LSPs.  For example, in the case where the
signaling domain coincides with an administrative domain or "trust"
boundary.  Where the mapping of forwarding requirements is 1:1,
however, the semantic difference between an approach that uses
translation of singaling and one that does not is nil.

> - RSVP-TE uses a different QoS representation from CR-LDP

Most of the objects associated with QoS in CR-LDP were lifted
bodily from RSVP-TE and the resemblence is striking.

>   respect, although the presence of an explicit route mitigates the

CR-LDP includes Explicit Routing using mechanisms and objects
that are very nearly identical to the objects included in RSVP-TE
(this time, both efforts "borrowed" from the same bank).

>   resources.  (RSVP's "SE" reservation style)

CR-LDP accomplishes this using LSP-ID.

> intead of trying to signal one LSP with two protocols.

As near as I can tell, the means to resolve the above "issues" are
available natively in both RSVP-TE and CR-LDP.  Work-arounds
are not needed.

--
Eric Gray