Luca Martini Draft: RSVP vice LDP

[dnewell24]

I’ve recently started looking into MPLS, L2VPNs, and pseudowires. I understand that the martini draft calls for LDP as it’s signaling and label distribution protocol but would it be theoretically possible to use RSVP instead? We have a requirement to setup an ATM pseudowire across an MPLS cloud. Using RSVP-TE we must also configure traffic engineering for the circuit. I believe RSVP-TE has the ability to signal a LSP as well as distribute a labels (?? so I’ve read). To simplify configuration could we use RSVP-TE for bandwidth reservation, signaling, and label distribution? Or am I comparing apples and oranges?

TIA,

Ryan

[pkhatri]

Ryan,

Using RSVP-TE, it is certainly possible to distribute the labels for the pseudowire end-points using RSVP. I'm not sure if the Cisco implementation supports that but I do know of at least one other implementation that does.

At end of the day, it's simply about label distribution so any label distribution protocol (appropriately extended) can do the job.

Pls do remember to rate posts.

Paresh

[dnewell24]

Paresh,

What vendor implementation are you refering to? I couldn't get it to work on Juniper M320s. But I must admit I'm new to the Juniper as well.

Ryan

[pkhatri]

Ryan,

The implementation I was referring to was one by Alcatel. However, I went back and had a closer look at what we are doing and it seems that we do not support RSVP in place of targeted LDP (yet). So my apologies for that... I just remembered reading something about potential support that and that's what led me to my comment in my earlier post.

Paresh.

[adityakaul]

Paresh,

I believe Alcatel's Dimitri P is co-author of the below mentioned draft which is being marketed at MPLS-WG for using RSVP-TE as PSN signalling proto.

Cutting aside the politics behind the draft...

Can anyone highlight the advantages using Rsvp..

apart from Qos for PSN's.

Regards,

Aditya

http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-03.txt

P.S-Interesting to note,none of the vendors on the draft seem to have implemented it yet.

(Initial draft published in June-2004)

[dnewell24]

Look at that!! I'm glad you posted this. Know I won't look like a complete lunatic at work for even suggesting that RSVP could work for PW setup thus removing the need for LDP.

Presently, to establish QoS for a PW one must "tunnel" or "stack" a RSVP label over an LDP PW label. I believe this draft eliminates the added configuration of LDP.

Interesting threaded discussion involving Luca Martini and his opposition (I think) to RSVP-TE.

http://www1.ietf.org/mail-archive/web/pwe3/current/msg07910.html

[Harold Ritter]

Paresh,

The cisco implementation does support the signaling of the tunnel LSP using RSVP. That should address the needs stated in the original posting.

The only two ways currently to exchange VC labels are LDP and BGP. I'm not aware of any work being done for VC label exchange using RSVP.

Hope this helps,

[dnewell24]

The current operation tunnels LDP sessions across RSVP established LSPs. RSVP is providing bandwidth reservation and LDP is signaling the pseudowire.

Didn’t know RSVP couldn’t distribute labels. The ‘Networkers 2005 MPLS Overview’ slides state LDP, TDP, RSVP, and BGP are all label distribution protocols. Maybe I’m confusing label allocation process of RSVP with label distribution.

So this brings up two part questions…

1. Can a MPLS network run only RSVP without any label distribution? If so why does a pseudowire require LDP?

[mheusinger]

Hello,

it is correct, that LDP, TDP, RSVP and BGP can distribute labels. But this does not mean they are interchangeable for every MPLS application like L2VPN, L3VPN or MPLS TE.

Regarding pseudowires - like EoMPLS - there is only the LDP option in Cisco routers (and in others as well following Martini draft) for the VC label. Be aware that you need two labels for transportation:

an LSP between PEs - TDP, LDP or RSVP (MPLS TE)

a VC label (identifies port/vc/interface...) - LDP

If it comes to VPLS then there is a scientific debate (Davie vs. Kompella ?) as to whether it is better to use LDP or BGP. Cisco implemented LDP.

RSVP is used with MPLS TE and can not be replaced there.

MP-BGP is used for distributing VPN labels in an MPLS VPN environment (RFC2547).

So if you have a plain IP network and want to turn on MPLS, you can use TDP, LDP and RSVP for label distribution. The latter requires MPLS TE implementation between all MPLS enabled devices. LSPs are then setup through MPLS TE tunnels.

Hope this helps! Please rate all posts.

Regards, Martin

[dnewell24]

Martin,

Thanks for the clarification.

I understand that the martini draft states use LDP for pseudowires and vendors implement LDP for pseudowire establishment. My question is, theoretically speaking is it possible to use RSVP to signal and distribute labels for pseudowires (ATM)? Why did martini decide to use LDP instead of RSVP? Are there extensions that were added to LDP not included in RSVP?

If both protocols, in their own ways, accomplish the same thing why not use RSVP? Instead of tunneling LDP through RSVP why not use RSVP?

I believe I missing a fundamental piece...

[Harold Ritter]

To my knowledge, RSVP was never considered for pseudowire label exchange. The nature of RSVP makes it a good choice for resource reservation and label assignement along a given path, which makes it a good fit for MPLS TE but not so much for pseudowire label exchange.

On the other hand, LDP was considered originally for MPLS TE but was quickly abandonned due to fewer vendors supporting it in IETF. It was referred to as Contraint based routing LDP (or CR-LDP).

Hope this helps,

[mheusinger]

Hello,

for a pseudowire you need exactly two PE routers exchanging VC labels. LDP allows the setup of a targeted session (TCP 646 between the two PEs) involving only those two PE routers.

RSVP would impose some constraints, because it relies on hop-by-hop processing and end-to-end implementation. I would assume it is not preferable to involve intermediate routers with information exchange, which only the two PE routers terminating the pseudowire will need.

And by the way: LDP is not tunneled through RSVP. Both are control plane protocols operating completely independant of each other. LDP uses a single TCP session between two routers. Intermediate routers will just see labeled unicast traffic. RSVP is not needed at all in an MPLS network unless you want to implement MPLS traffic engineering.

Hope this helps! Please rate all posts.

Regards, Martin

[dnewell24]

Makes sense. Again thank you for the clarification.

LDP tunneling is a term used by Juniper. It permits LDP session to be established across a RSVP network. In my environment we have a requirement to reserve bandwidth for the pseudowires. We're "tunneling" LDP sessions through RSVP established LSPs. In others we're stacking an RSVP label on an LDP label.

Again this is new to me so if I misspeak please correct.

http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-mpls-apps/html/ldp-overview8.html#1013988

http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-mpls-apps/html/ldp-overview7.html#1021145

[mheusinger]

Hello,

I wasn´t aware of this term. Cisco doesn´t make a big fuzz about LDP sessions across a RSVP enabled network.

In fact this LDP traffic is just seen as labeled unicast traffic and intermediate LSRs will not even be aware of what they are transporting. Off course you can call it "LDP tunneling" (and marketing guys seem to love those terms sounding great and unique). But then - you could also call it BGP tunneling, ICMP tunneling and it is still good old label switching.

Additionally label stacking is one of the core ideas in MPLS, so what´s the big deal there?

You see, I´m more a techie than a marketing guy ;-)

And as a techie one more remark: be careful with the meaning of the term "reserve bandwidth". MPLS TE with RSVP is a pure control plane feature, i.e. there is no statement regarding the "interface fate" (drop or forward) of a single packet. QoS is the feature to look into there - or combining both: DiffServ aware MPLS TE.

Hope this helps! Please rate all posts.

Regards, Martin