RSVP-TE: Difference between revisions
Content deleted Content added
I think this change is more correct than I've made a minute ago. |
m Just add RFC 5151 in RFCs section. |
||
| Line 1: | Line 1: | ||
'''Resource Reservation Protocol - Traffic Engineering''' is an extension of the [[Resource Reservation Protocol|RSVP]] [[Protocol (computing)|protocol]] for [[Teletraffic engineering|traffic engineering]]. It supports the reservation of resources across an [[Internet Protocol|IP]] [[Computer network|network]]. Applications running on IP end systems can use RSVP to indicate to other nodes the nature ([[Bandwidth (computing)|bandwidth]], [[jitter]], maximum burst, and so forth) of the [[Packet (information technology)|packet]] streams they want to receive. RSVP runs on both [[IPv4]] and [[IPv6]]. |
'''Resource Reservation Protocol - Traffic Engineering''' is an extension of the [[Resource Reservation Protocol|RSVP]] [[Protocol (computing)|protocol]] for [[Teletraffic engineering|traffic engineering]]. It supports the reservation of resources across an [[Internet Protocol|IP]] [[Computer network|network]]. Applications running on IP end systems can use RSVP to indicate to other nodes the nature ([[Bandwidth (computing)|bandwidth]], [[jitter]], maximum burst, and so forth) of the [[Packet (information technology)|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 [[Multi-Protocol Label Switching|MPLS]] [[label switched path]]s (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops. |
RSVP-TE is detailed in [[IETF]] RFC 3209 (updated by RFC 5151). RSVP-TE generally allows the establishment of [[Multi-Protocol Label Switching|MPLS]] [[label switched path]]s (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops. |
||
As of February 2003, as documented in RFC 3468<ref>[http://www.ietf.org/rfc/rfc3468.txt The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols],RFC3468,L. Andersson and G. Swallow, February 2003</ref>, the IETF MPLS working group deprecated [[Constraint-based Routing Label Distribution Protocol|CR-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 network]]s. |
As of February 2003, as documented in RFC 3468<ref>[http://www.ietf.org/rfc/rfc3468.txt The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols],RFC3468,L. Andersson and G. Swallow, February 2003</ref>, the IETF MPLS working group deprecated [[Constraint-based Routing Label Distribution Protocol|CR-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 network]]s. |
||
| Line 20: | Line 20: | ||
* RFC 4874 - Exclude Routes - Extension to 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 |
* RFC 4920 - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE |
||
* RFC 5151 - Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions |
|||
[[Category:Internet architecture]] |
[[Category:Internet architecture]] |
||
Revision as of 13:36, 11 August 2008
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 (updated by RFC 5151). 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 CR-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
- ^ 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
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
- RFC 5151 - Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
 | This computing article is a stub. You can help Wikipedia by expanding it. |