RSVP-TE

Resource Reservation Protocol - Traffic Engineering is an extension of the RSVP protocol for traffic engineering. It supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature (bandwidth, jitter, maximum burst, and so forth) of the packet streams they want to receive. RSVP runs on both IPv4 and IPv6.

RSVP-TE is detailed in IETF RFC 3209. RSVP-TE generally allows the establishment of MPLS label switched paths (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops.

As of February 2003, as documented in RFC 3468^[1], the IETF MPLS working group deprecated LDP and decided to focus purely on RSVP-TE. Operational overhead of RSVP-TE compared to the more widely deployed LDP will generally be higher. This is a classic trade-off between complexity and optimality in the use of technologies in telecommunications networks.

References

1. ^ The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols,RFC3468,L. Andersson and G. Swallow, February 2003

• "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)

See also

• Resource Reservation Protocol (RSVP)
• MPLS

RFCs

• RFC 3209 - RSVP-TE: Extensions to RSVP for LSP Tunnels
• RFC 3468 - The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols
• RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels
• RFC 4420 - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
• RFC 4874 - Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
• RFC 4920 - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE

This computer-related article is a stub. You can help Wikipedia by expanding it.