RSVP-TE: Extensions to RSVP for LSP Tunnels

By Daniel O. Awduche, L. Berger, Der-hwa Gan, Tony Li, V. Srinivasan, G. Swallow. Request for Comments, 2001

1,420 citations recorded by the source corpus.

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

Walking the tightrope: responsive yet stable traffic engineering (2005, methodology): “Th e ISP configures each agent with a set of paths it can use to deliv er its IE traffic, and pins the paths using a standard protocol like R SVPTE [7].”
Achieving high utilization with software-driven WAN (2013, methodology): “We use OpenFlow switches, though any switch that permits direct programming of forwarding state (e.g., MPLS Explicit Route Objects [3]) may be used.”
Generalized multiprotocol label switching: an overview of routing and management enhancements (2001, methodology): “For example, either RSVP-TE [11] or CR-LDP [12] is used to establish the label forwarding state along the routes computed by a CSPF-based algorithm; this creates the LSP.”
Traffic Engineering (2000, neutral): “This specification only defines the use of the ATM_SERVICECLASS Object in PATH messages used to establish LSP (Label Switched Path) Tunnels in accordance with [RSVP-TE].”
MATE: MPLS adaptive traffic engineering (2001, methodology): “[3] D. O. Awduche et. al., ”RSVP-TE: extensions to RSVP for LSP tunnels”, Internet draft<draft-ietf-mpls-rsvp-lsp-tunnel-05.txt>, Feb. 2000.”