RSVP-TE: Difference between revisions
Content deleted Content added
m Standard headings &/or gen fixes. using AWB |
Citation bot (talk | contribs) Alter: isbn. Upgrade ISBN10 to 13. | Use this bot. Report bugs. | Suggested by VulcanSphere | Category:Internet architecture | #UCB_Category 102/127 |
||
| (34 intermediate revisions by 16 users not shown) | |||
| Line 1: | Line 1: | ||
{{short description|Extension of the Resource Reservation Protocol}} |
|||
'''Resource Reservation Protocol - Traffic Engineering''' |
|||
{{Update|reason=was this ever deployed at scale?|date=January 2023}} |
|||
| ⚫ | '''Resource Reservation Protocol - Traffic Engineering''' ('''RSVP-TE''') is an extension of the [[Resource Reservation Protocol]] (RSVP) for [[teletraffic engineering|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 (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 generally allows the establishment of [[Multiprotocol Label Switching]] (MPLS) [[label-switched path]]s (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit [[hop (networking)|hops]].<ref name=rfc3209>{{cite IETF|rfc=3209|title=RSVP-TE: Extensions to RSVP for LSP Tunnels|author1=D. Awduche|author2=L. Berger|author3=D. Gan|author4=T. Li|author5=V. Srinivasan|author6=G. Swallow|date=December 2001|publisher=Network Working Group}} Updated by {{IETF RFC|3936|link=no}}, {{IETF RFC|4420|link=no}}, {{IETF RFC|4874|link=no}}, {{IETF RFC|5151|link=no}}, {{IETF RFC|5420|link=no}}, {{IETF RFC|5711|link=no}}, {{IETF RFC|6780|link=no}}, {{IETF RFC|6790|link=no}}, and {{IETF RFC|7274|link=no}}.</ref> |
|||
| ⚫ | Protocol |
||
==History== |
|||
Traffic engineering extension to RSVP or RSVP-TE is detailed in IETF RFC 3209. RSVP-TE generally allows the establishment of [[label switched path]]s (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops. Operation overhead of RSVP-TE compared to the more widely deployed [[Label Distribution Protocol|LDP]] based network will generally be higher. This is a classic trade-off between complexity and optimality in the use of technologies in telecommunications networks. |
|||
{{As of|February 2003}}, the [[Internet Engineering Task Force]] (IETF) MPLS working group deprecated [[Constraint-based Routing Label Distribution Protocol]] (CR-LDP) and decided to focus purely on RSVP-TE.<ref name=rfc3468>{{cite IETF|rfc=3468|title=The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols|author1=L. Andersson|author2=G. Swallow|date=February 2003|publisher=Network Working Group}}</ref> Operational overhead of RSVP-TE compared to the more widely deployed [[Label Distribution Protocol]] (LDP) will generally be higher. This is a classic [[trade-off]] between complexity and optimality in the use of technologies in [[telecommunications network]]s. |
|||
== |
==Standards== |
||
* {{IETF RFC|3209}} - RSVP-TE: Extensions to RSVP for LSP Tunnels |
|||
| ⚫ | |||
* {{IETF RFC|3468|link=no}} - The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols |
|||
* {{IETF RFC|4090|link=no}} - Fast Reroute Extensions to RSVP-TE for LSP Tunnels |
|||
* {{IETF RFC|4874|link=no}} - Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
|||
* {{IETF RFC|4920|link=no}} - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE |
|||
* {{IETF RFC|5151|link=no}} - Inter-Domain MPLS and GMPLS Traffic Engineering—Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions |
|||
* {{IETF RFC|5420|link=no}} - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
|||
* {{IETF RFC|5711|link=no}} - Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages |
|||
* {{IETF RFC|6001|link=no}} - Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) |
|||
== |
==References== |
||
{{reflist}} |
|||
[[Resource Reservation Protocol]] (RSVP) |
|||
==Further reading== |
|||
| ⚫ | |||
[[Category:Internet architecture]] |
|||
{{compu-stub}} |
|||
Latest revision as of 23:37, 20 November 2023
 | This article needs to be updated. The reason given is: was this ever deployed at scale?. (January 2023) |
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) is an extension of the Resource Reservation Protocol (RSVP) 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 generally allows the establishment of Multiprotocol Label Switching (MPLS) label-switched paths (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops.[1]
History
[edit]As of February 2003[update], the Internet Engineering Task Force (IETF) MPLS working group deprecated Constraint-based Routing Label Distribution Protocol (CR-LDP) and decided to focus purely on RSVP-TE.[2] Operational overhead of RSVP-TE compared to the more widely deployed Label Distribution Protocol (LDP) will generally be higher. This is a classic trade-off between complexity and optimality in the use of technologies in telecommunications networks.
Standards
[edit]- 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 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
- RFC 5420 - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
- RFC 5711 - Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
- RFC 6001 - Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
References
[edit]- ^ D. Awduche; L. Berger; D. Gan; T. Li; V. Srinivasan; G. Swallow (December 2001). RSVP-TE: Extensions to RSVP for LSP Tunnels. Network Working Group. doi:10.17487/RFC3209. RFC 3209. Updated by RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, and RFC 7274.
- ^ L. Andersson; G. Swallow (February 2003). The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols. Network Working Group. doi:10.17487/RFC3468. RFC 3468.
Further reading
[edit]- John Evans; Clarence Filsfils (2007). Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Morgan Kaufmann. ISBN 978-0-12-370549-5.