RFC 4804
Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels
RFC 4804 🎀 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels
Network Working Group 🌸 Written by F. Le Faucheur, Ed. from Cisco Systems, Inc. 💅
Category: Standards Track 👑
Date: February 2007 📅
Obsoletes / Updates: The title block doesn't list anything this RFC obsoletes or updates. 🫶
Status of This Memo 📜
okay bestie, so this document is a standards track protocol for the whole Internet community ✨ It's open for discussion and suggestions for improvements, so send your ideas in 💖 Distribution is unlimited, so share it with everyone 🦋
To find the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔥
Copyright Notice ⭐
Copyright (C) The IETF Trust (2007). 💜
Abstract 🦋
okay so RFC 3175 is the one that specifies aggregating RSVP end-to-end reservations over aggregate RSVP reservations 💅 This doc takes that idea and extends it to MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels ✨ It's based on RFC 3175 and just tweaks the procedures so they work over MPLS TE tunnels instead of aggregate RSVP reservations 🌈
Why is this so iconic? 😭 You can do admission control for a very large number of flows, and it stays scalable because the routers in the core are unaware of the end-to-end RSVP reservations. They only know about the MPLS TE tunnels 🧚 The core stays chill and the edges do the heavy lifting 👑
Table of Contents 🌈
1. Introduction ....................................................3
2. Specification of Requirements ...................................7
3. Definitions .....................................................7
4. Operations of RSVP Aggregation over TE with
Pre-established Tunnels .........................................8
4.1. Reference Model ............................................9
4.2. Receipt of E2E Path Message by the Aggregator ..............9
4.3. Handling of E2E Path Message by Transit LSRs ..............11
4.4. Receipt of E2E Path Message by the Deaggregator ...........11
4.5. Handling of E2E Resv Message by the Deaggregator ..........12
4.6. Handling of E2E Resv Message by the Aggregator ............12
4.7. Forwarding of E2E Traffic by the Aggregator ...............14
4.8. Removal of E2E Reservations ...............................14
4.9. Removal of the TE Tunnel ..................................14
4.10. Example Signaling Flow ...................................15
5. IPv4 and IPv6 Applicability ....................................16
6. E2E Reservations Applicability .................................16
7. Example Deployment Scenarios ...................................16
7.1. Voice and Video Reservations Scenario .....................16
7.2. PSTN/3G Voice Trunking Scenario ...........................17
8. Security Considerations ........................................18
9. Acknowledgments ................................................20
10. Normative References ..........................................20
11. Informative References ........................................21
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator ........23
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels
for VoIP Call Admission Control (CAC) ................251. Introduction ✨
okay so bestie, the Integrated Services (Intserv) [INT-SERV] architecture is all about delivering end-to-end Quality of Service (QoS) to applications, even when they cross heterogeneous networks 🦋 it's giving main character energy for apps that need real guarantees 💅
[RSVP] defines the Resource reSerVation Protocol 🎀 apps can use it to request resources from the network, and the network responds by explicitly admitting or rejecting those RSVP requests. Certain apps with quantifiable resource requirements express them using Intserv parameters from the appropriate Intserv service specifications ([GUARANTEED], [CONTROLLED]) 🫶
Then the Differentiated Services (DiffServ) architecture ([DIFFSERV]) showed up to support differentiated treatment of packets in very large scale environments 🌈 Unlike the per-flow vibe of Intserv and RSVP, Diffserv networks sort packets into a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet IP header ✨ At each Diffserv router, packets get a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit is scalability 😭 Diffserv gets rid of per-flow state and per-flow processing, so it scales well to large networks 💜
However, DiffServ has no mechanism for communication between applications and the network 💀 As detailed in [INT-DIFF], significant benefits can be achieved by running Intserv over Diffserv, including resource-based admission control, policy-based admission control, assistance in traffic identification/classification, and traffic conditioning 🔥 As discussed in [INT-DIFF], Intserv can operate over Diffserv in multiple ways. For example, the Diffserv region may be statically provisioned or RSVP aware. When it is RSVP aware, several mechanisms may be used to support dynamic provisioning and topology-aware admission control, including aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. The advantage of aggregate RSVP reservations is that they offer dynamic, topology-aware admission control over the Diffserv region without per-flow reservations and the associated level of RSVP signaling in the Diffserv core 🧚 That means dynamic, topology-aware admission control of flows requiring QoS reservations over the Diffserv core, even when the total number of such flows is extremely large 🍓
[RSVP-AGG] and [RSVP-GEN-AGG] describe in detail how to aggregate end-to-end RSVP reservations over aggregate RSVP reservations in a Diffserv cloud 🦋 They set up an architecture where multiple end-to-end RSVP reservations sharing the same ingress router (Aggregator) and egress router (Deaggregator) at the edges of an "aggregation region" can be mapped onto a single aggregate reservation within that region. This considerably reduces the amount of reservation state that routers inside the aggregation region need to maintain 🌸 Furthermore, traffic belonging to aggregate reservations is classified in the data path purely using Diffserv marking ✨
[MPLS-TE] describes how MPLS Traffic Engineering (TE) tunnels can carry arbitrary aggregates of traffic for traffic engineering purposes 🎀 [RSVP-TE] specifies how such MPLS TE tunnels can be established using RSVP-TE signaling. MPLS TE uses Constraint-Based Routing to compute the path for a TE tunnel. Then, Admission Control is performed during the establishment of TE tunnels to make sure they get their requested resources 💅
[DSTE-REQ] presents the Service Providers' requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE) 👑 With DS-TE, separate DS-TE tunnels can carry different Diffserv classes of traffic, and different resource constraints can be enforced for those different classes. [DSTE-PROTO] specifies RSVP-TE signaling extensions, as well as OSPF and Intermediate System to Intermediate System (IS-IS) extensions, for support of DS-TE 🫶
In the rest of this document we will refer to both TE tunnels and DS-TE tunnels simply as "TE tunnels" 🌈
TE tunnels have a lot in common with the aggregate RSVP reservations used in [RSVP-AGG] and [RSVP-GEN-AGG] 👯
- A TE tunnel is subject to Admission Control and is therefore effectively an aggregate bandwidth reservation.
- In the data plane, packet scheduling relies exclusively on Diffserv classification and PHBs.
- Both TE tunnels and aggregate RSVP reservations are controlled by "intelligent" devices on the edge of the "aggregation core" (Head-end and Tail-end in the case of TE tunnels; Aggregator and Deaggregator in the case of aggregate RSVP reservations.
- Both TE tunnels and aggregate RSVP reservations are signaled using the RSVP protocol (with some extensions defined in [RSVP-TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE tunnels).
This document provides a detailed specification for aggregating end-to-end RSVP reservations over MPLS TE tunnels (which act as aggregate reservations in the core) 🦋 It builds on the RSVP Aggregation procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG], and only changes them where necessary to operate over TE tunnels. With [RSVP-AGG] and [RSVP-GEN-AGG], a lot of responsibilities (such as mapping end-to-end reservations to Aggregate reservations and resizing the Aggregate reservations) are assigned to the Deaggregator (which is the equivalent of the tunnel Tail-end), while with TE, the tunnels are controlled by the tunnel Head-end. So the main change over the RSVP Aggregations procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG] is to reassign responsibilities from the Deaggregator to the Aggregator (i.e., the tunnel Head-end) 🔄
[LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths (LSPs) by creating a hierarchy of such LSPs 🪆 This involves nesting end-to-end LSPs into an aggregate LSP in the core (by using the label stack construct). Since end-to-end TE LSPs are themselves signaled with RSVP-TE and reserve resources at every hop, this can be seen as a form of aggregation of RSVP(-TE) reservations over MPLS TE tunnels 🌸 This document capitalizes on the similarities between nesting TE LSPs over TE tunnels and RSVP aggregation over TE tunnels, and reuses the procedures of [LSP-HIER] wherever possible 💖
This document also builds on the "RSVP over Tunnels" concepts of RFC 2746 [RSVP-TUN] 🧁 It differs from that specification in the following ways:
- This document describes operation over MPLS tunnels, whereas RFC 2746 describes operation with IP tunnels. One consequence of this difference is the need to deal with penultimate hop popping (PHP).
- MPLS-TE tunnels inherently reserve resources, whereas the tunnels in RFC 2746 do not have resource reservations by default. This leads to some simplifications in the current document.
- This document builds on the fact that there is exactly one aggregate reservation per MPLS-TE tunnel, whereas RFC 2746 permits a model where one reservation is established on the tunnel path for each end-to-end flow.
- We have assumed in the current document that a given MPLS-TE tunnel will carry reserved traffic and nothing but reserved traffic, which negates the requirement of RFC 2746 to distinguish reserved and non-reserved traffic traversing the same tunnel by using distinct encapsulations.
- There may be several MPLS-TE tunnels that share common Head-end and Tail-end routers, with the Head-end policy determining which tunnel is appropriate for a particular flow. This scenario does not appear to be addressed in RFC 2746.
At the same time, this document has a lot in common with RFC 2746 👭 MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 2746:
"The (logical) link may be able to promise that some overall level of resources is available to carry traffic, but not to allocate resources specifically to individual data flows".
Aggregating end-to-end RSVP reservations over TE tunnels combines the benefits of [RSVP-AGG] and [RSVP-GEN-AGG] with the benefits of MPLS, including the following 🤩
- Applications can benefit from dynamic, topology-aware, resource-based admission control over any segment of the end-to-end path, including the core.
- As per regular RSVP behavior, RSVP does not impose any burden on routers where such admission control is not needed (for example, if the links upstream and downstream of the MPLS TE core are vastly over-engineered compared to the core capacity, admission control is not required on these over-engineered links and RSVP need not be processed on the corresponding router hops).
- The core scalability is not affected (relative to the traditional MPLS TE deployment model), since the core remains unaware of end-to-end RSVP reservations and only has to maintain aggregate TE tunnels, because the datapath classification and scheduling in the core relies purely on the Diffserv mechanism (or more precisely the MPLS Diffserv mechanisms, as specified in [DIFF-MPLS]) 💪
- The aggregate reservation (and thus the traffic from the corresponding end-to-end reservations) can be network engineered via the use of Constraint-Based Routing (e.g., affinity, optimization on different metrics) and, when needed, can take advantage of resources on other paths than the shortest path 🗺️
- The aggregate reservations (and thus the traffic from the corresponding end-to-end reservations) can be protected against failure through the use of MPLS Fast Reroute 🛡️
This document, like [RSVP-AGG] and [RSVP-GEN-AGG], covers aggregation of unicast sessions. Aggregation of multicast sessions is for further study 🔮
2. Specification of Requirements ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 📜🫶
3. Definitions ✨
okay so before we get into the good stuff, here's a little glossary so we're all on the same page 💅 some of these come from [RSVP-AGG], and the rest are the usual MPLS TE terms 🎀
- Aggregator: the process in (or associated with) the router at the ingress edge of the aggregation region (with respect to the end-to-end RSVP reservation) that behaves in accordance with [RSVP-AGG]. In this document, it is also the TE tunnel Head-end 🫶
- Deaggregator: the process in (or associated with) the router at the egress edge of the aggregation region (with respect to the end-to-end RSVP reservation) that behaves in accordance with [RSVP-AGG]. In this document, it is also the TE tunnel Tail-end ✨
- E2E: End to end 🌈
- E2E Reservation: an RSVP reservation such that:
- (i) corresponding Path messages are initiated upstream of the Aggregator and terminated downstream of the Deaggregator, and
- (ii) corresponding Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and
- (iii) this RSVP reservation is aggregated over an MPLS TE tunnel between the Aggregator and Deaggregator.
An E2E RSVP reservation may be a per-flow reservation. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g., Aggregate IP reservation, Aggregate IPsec reservation). See Section 5 and 6 for more details on the types of E2E RSVP reservations. As per regular RSVP operations, E2E RSVP reservations are unidirectional. 🦋
- Head-end: the Label Switch Router responsible for establishing, maintaining, and tearing down a given TE tunnel. 👑
- Tail-end: the Label Switch Router responsible for terminating a given TE tunnel. 💜
- Transit LSR: a Label Switch Router that is on the path of a given TE tunnel and is neither the Head-end nor the Tail-end. 🧚
4. Operations of RSVP Aggregation over TE with Pre-established Tunnels 🎀
okay this section is where it gets juicy 🔥 [RSVP-AGG] and [RSVP-GEN-AGG] both support operations where the aggregate RSVP reservations are pre-established, and also the case where Aggregators and Deaggregators have to dynamically discover each other and dynamically set up the necessary aggregate RSVP reservations. no cap, that's a lot of flexibility 💅
RSVP Aggregation over TE tunnels can work the same way. it could operate when the TE tunnels are pre-established, and also when the tunnels need to be dynamically established ✨
in this document, we walk through the detailed procedures for when the TE tunnels are already established 💖 these procedures are based on the ones defined in [LSP-HIER]. the routing aspects discussed in Section 3 of [LSP-HIER] don't apply here, because those are about letting constraint based routing of end-to-end TE LSPs take the (aggregate) TE tunnels into account. in this document, the end-to-end RSVP reservations that get aggregated over the TE tunnels rely on regular SPF routing. 🍓 however, as already mentioned in [LSP-HIER], a TE tunnel may be advertised into IS-IS or OSPF, so that nodes upstream of the Aggregator can use it in normal SPF. this would affect SPF routing and therefore the routing of end-to-end RSVP reservations 👀 the control of aggregation boundaries discussed in Section 6 of [LSP-HIER] is also not relevant here. that one uses information exchanged in GMPLS protocols to dynamically discover the aggregation boundary. in this document, the TE tunnels are pre-established, so the aggregation boundary can be easily inferred 🧠
the signaling aspects discussed in Section 6.2 of [LSP-HIER] apply to establishing and terminating the aggregate TE tunnels when that's triggered by GMPLS mechanisms (for example, as a result of an end-to-end TE LSP establishment request received at the aggregation boundary). since this document assumes pre-established tunnels, those aspects aren't relevant here 🙈 the signaling aspects discussed in Section 6.1 of [LSP-HIER] are about establishing and maintaining the end-to-end TE LSPs over the aggregate TE tunnel. this document describes how to use the same procedures as those in Section 6.1 of [LSP-HIER], but for establishing end-to-end RSVP reservations (instead of end-to-end TE LSPs) over the TE tunnels. this is covered further in Section 4 of the present document 🫶
pre-establishment of the TE tunnels may be triggered by any mechanism, for example manual configuration, or automatic establishment of a TE tunnel mesh through dynamic discovery of TE Mesh membership as allowed in [AUTOMESH] 🌸
procedures for dynamically established TE tunnels are for further studies 🔮
4.1. Reference Model
|----| |----|
H--| R |\ |-----| |------| /| R |--H
H--| |\\| | |---| | |//| |--H
|----| \| He/ | | T | | Te/ |/ |----|
| Agg |=======================| Deag |
/| | | | | |\
H--------//| | |---| | |\\--------H
H--------/ |-----| |------| \--------H
H = Host requesting end-to-end RSVP reservations
R = RSVP router
He/Agg = TE tunnel Head-end/Aggregator
Te/Deag = TE tunnel Tail-end/Deaggregator
T = Transit LSR
-- = E2E RSVP reservation
== = TE tunnel4.2. Receipt of E2E Path Message by the Aggregator 💌
first up, the E2E Path message shows up at the Aggregator 📬 the Aggregator MUST follow traditional RSVP procedures for processing this E2E Path message, plus the extensions documented in this section 🎀
the Aggregator MUST first try to map the E2E reservation onto a TE tunnel 🗺️ this decision is made according to routing information, and also any local policy information that may be available at the Aggregator. examples of such policies show up in the following paragraphs. just for illustration, and among many other criteria, such mapping policies might take into account the Intserv service type, the Application Identity [RSVP-APPID], and/or the signaled preemption [RSVP-PREEMP] of the E2E reservation (for example, the Aggregator may take into account the E2E reservation's RSVP preemption priority and the MPLS TE tunnel setup and/or hold priorities when mapping the E2E reservation onto an MPLS TE tunnel) 💅
sometimes the Aggregator can make a final mapping decision 🎯 that would be the case, for example, if there's a single TE tunnel toward the destination and the policy is to map any E2E RSVP reservation onto TE tunnels 🙌
other times the Aggregator can't make a final call 🤷♀️ that would be the case, for example, if routing identifies two DS-TE tunnels toward the destination, one belonging to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel and Intserv Controlled Load reservations to a Class-Type 0 tunnel, and if the E2E RSVP Path message advertises both Guaranteed Service and Controlled Load 😭
whether it's final or tentative, the Aggregator makes a mapping decision and selects a TE tunnel ✨ before forwarding the E2E Path message toward the receiver, the Aggregator SHOULD update the ADSPEC inside the E2E Path message to reflect the impact of the MPLS TE cloud on the QoS the E2E flow can achieve 📊 this update is a local matter. it may be based on configured information, on the information in the MPLS TE topology database, on the current TE tunnel path, on information collected via RSVP-TE signaling, or a combination of those 🧩 updating the ADSPEC lets receivers that take into account the info collected in the ADSPEC within the network (such as delay and bandwidth estimates) make more informed reservation decisions 🧠💖
the Aggregator MUST then forward the E2E Path message to the Deaggregator (which is the Tail-end of the selected TE tunnel) 🚀 in accordance with [LSP-HIER], the Aggregator MUST send the E2E Path message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. the data interface identification MUST identify the TE tunnel 🫶
to send the E2E Path message, the Aggregator MUST address it directly to the Deaggregator by setting the destination address in the IP Header of the E2E Path message to the Deaggregator address. the Router Alert is not set in the E2E Path message 🙈
optionally, the Aggregator MAY also encapsulate the E2E Path message in an IP tunnel or in the TE tunnel itself 🎁
regardless of the encapsulation method, the Router Alert is not set. so the E2E Path message won't be visible to routers along the path from the Aggregator to the Deaggregator 👻 therefore, unlike the procedures of [RSVP-AGG] and [RSVP-GEN-AGG], the IP Protocol number does not need to be changed to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating "RSVP") by the Aggregator 🌈
in some environments, the Aggregator and Deaggregator MAY also act as IPsec Security Gateways to give IPsec protection to E2E traffic when it transits between the Aggregator and the Deaggregator 🔐 in that case, to transmit the E2E Path message to the Deaggregator, the Aggregator MUST send the E2E Path message into the relevant IPsec tunnel terminating on the Deaggregator 🛡️
E2E PathTear and ResvConf messages MUST be forwarded by the Aggregator to the Deaggregator exactly like Path messages 💌✨
4.3. Handling of E2E Path Message by Transit LSRs 🌙
since the E2E Path message is addressed directly to the Deaggregator and doesn't have Router Alert set, it's hidden from all transit LSRs 🥷💜
4.4. Receipt of E2E Path Message by the Deaggregator 🎀
okay so when the E2E Path message gets addressed to the Deaggregator, it checks the IP Protocol number. If it says "RSVP", the Deaggregator knows to do full RSVP processing on that E2E Path message 💅
bestie, pay attention here 👀 The IP TTL vs. RSVP TTL check MUST NOT be made, same as in [LSP-HIER]. The IF_ID RSVP HOP object is what tells the Deaggregator to skip that check. it's giving efficient design 😭
The Deaggregator MAY support the option to perform the following checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID RSVP_HOP object:
- Make sure that the data interface identified in the IF_ID RSVP_HOP object actually terminates on Y.
- Find the "other end" of the above data interface, i.e., X. Make sure that the PHOP in the IF_ID RSVP_HOP object is a control channel address that belongs to the same node as X.
ngl the info needed for these checks isn't always available to the Deaggregator 🥺 So the Deaggregator MUST support operations in those environments where the checks cannot be made. no crashing, just vibing 🫶
The Deaggregator MUST forward the E2E Path downstream toward the receiver. While doing that, it sets the destination address in the IP header of the E2E Path message to the IP address in the destination address field of the Session object. It also sets the Router Alert ✨
An E2E PathErr that the Deaggregator sends back in response to the E2E Path message (the one with an IF_ID RSVP_HOP object) SHOULD contain an IF_ID RSVP_HOP object. main character energy 👑
4.5. Handling of E2E Resv Message by the Deaggregator 🦋
so, as per regular RSVP operations, once the receiver gets the E2E Path, it generates an E2E Resv message. That message travels upstream hop-by-hop toward the sender 🌸
When the Deaggregator gets the E2E Resv, it MUST follow traditional RSVP procedures for receiving an E2E Resv message. That includes doing admission control for the segment downstream of the Deaggregator, and forwarding the E2E Resv to the PHOP that was signaled earlier in the E2E Path message. That PHOP is the one that identifies the Aggregator 💖
here's the cute part ✨ The E2E Resv is directly addressed to the Aggregator and does not carry the Router Alert option (as per traditional RSVP Resv procedures). So the routers between the Deaggregator and the Aggregator are kept out of it and handle the E2E Resv as a regular IP packet. hidden in plain sight 🙈
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Deaggregator MUST send the E2E Resv message into the relevant IPsec tunnel terminating on the Aggregator 🔥
4.6. Handling of E2E Resv Message by the Aggregator 💅
the Aggregator is responsible for making sure there's enough bandwidth available and reserved over the right TE tunnel to the Deaggregator for the E2E reservation. no cap, this is a big job 😭
When the E2E Resv message arrives, the Aggregator MUST first do the final mapping onto the final TE tunnel, but only if the previous mapping was just tentative 🧚
If the tunnel did not change during the final mapping, the Aggregator carries on with processing the E2E Resv in the way the next four paragraphs describe ✨
the aggregator works out the size of the resource request using traditional RSVP procedures. In other words, it follows the procedures in [RSVP] to figure out the resource requirements from the Sender Tspec and the Flowspec in the Resv. Then it compares that resource request with the available resources of the selected TE tunnel 🍓
If there's enough bandwidth on the final TE tunnel, the Aggregator MUST update its internal understanding of how much of the TE tunnel is in use, and MUST forward the E2E Resv messages to the corresponding PHOP 🌈
As noted in [RSVP-AGG], a range of policies MAY be applied to re-sizing the aggregate reservation (in this case, the TE tunnel). For example, the policy could be that the reserved bandwidth of the tunnel can only be changed by configuration. More dynamic policies are also possible, where the aggregator tries to increase the reserved bandwidth of the tunnel based on how much of the allocated bandwidth E2E reservations are actually using. Furthermore, to avoid the delay that comes with growing the tunnel, the Aggregator may try to anticipate demand increases and resize the TE tunnel before E2E reservations actually need it. To keep disruptions low, the Aggregator SHOULD use "make-before-break" procedures as described in [RSVP-TE] when changing the TE tunnel bandwidth 🫧
If there isn't enough bandwidth on the final TE tunnel, the Aggregator MUST follow the normal RSVP procedure for a reservation placed with insufficient bandwidth to support it. So the reservation is not installed and a ResvError is sent back toward the receiver 🥀
If the tunnel did change during the final mapping, the Aggregator MUST first resend to the Deaggregator an E2E Path message with the IF_ID RSVP_HOP data interface identification that identifies the final TE tunnel. If needed, the ADSPEC information in this E2E Path message SHOULD be updated. Then the Aggregator MUST do one of these:
- either drop the E2E Resv message
- or proceed with processing the E2E Resv in the same way as when the tunnel did not change (described above)
in the first case, admission control over the final TE tunnel (and forwarding the E2E Resv upstream toward the sender) only happens when the Aggregator gets the next E2E Resv message, the one the Deaggregator sends in response to the resent E2E Path. in the second case, admission control over the final tunnel happens right away from the Aggregator, and if it works out, the E2E Resv is generated upstream toward the sender 🎀
When the Aggregator sends an E2E ResvConf, the Deaggregator MUST forward that E2E ResvConf downstream toward the receiver. While doing that, it sets the destination address in the IP header of the E2E ResvConf message to the IP address found in the RESV_CONFIRM object of the matching Resv. It also sets the Router Alert 💜
4.7. Forwarding of E2E Traffic by the Aggregator 🌸
when the Aggregator gets a data packet that belongs to an E2E reservation currently mapped over a given TE tunnel, it MUST encapsulate that packet into that TE tunnel 🚀
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Aggregator MUST also encapsulate the data packet into the relevant IPsec tunnel terminating on the Deaggregator before it's sent into the MPLS TE tunnel. double encapsulation, iconic 💅✨
4.8. Removal of E2E Reservations 🧚
E2E reservations get removed the usual way, through PathTear, ResvTear, timeout, or as the result of an error condition. When a reservation is removed, the Aggregator MUST update its local view of the resources available on the matching TE tunnel 🫶
4.9. Removal of the TE Tunnel 🌧️
okay, so if a TE tunnel goes away (presumably because of a configuration change, route change, or policy event), the Aggregator acts a lot like a regular RSVP router when a link fails. It might try to forward the Path messages onto another tunnel, if routing and policy allow it. Or it might send Path_Error messages to the sender if there's no suitable tunnel 😬
If the Path messages get forwarded onto another tunnel that ends at a different Deaggregator, or if the reservation gets torn down with Path Error messages, then the reservation state that the router acting as the Deaggregator set up before the TE tunnel went away will time out. why? because nobody's refreshing it anymore 🥲
4.10. Example Signaling Flow 🎬
here's the whole flow in one picture, bestie 🦋
Aggregator Deaggregator
(*)
RSVP-TE Path
=========================>
RSVP-TE Resv
<=========================
(**)
E2E Path
-------------->
(1)
E2E Path
------------------------------->
(2)
E2E Path
----------->
E2E Resv
<-----------
(3)
E2E Resv
<-----------------------------
(4)
E2E Resv
<-------------here's what each marker means:
- (*) Aggregator is triggered to pre-establish the TE tunnel(s)
- (**) TE tunnel(s) are pre-established
- (1) Aggregator tentatively selects the TE tunnel and forwards E2E Path to Deaggregator
- (2) Deaggregator forwards the E2E Path toward the receiver
- (3) Deaggregator forwards the E2E Resv to the Aggregator
- (4) Aggregator selects final TE tunnel, checks that there is sufficient bandwidth on TE tunnel, and forwards E2E Resv to PHOP. If final tunnel is different from tunnel tentatively selected, the Aggregator re-sends an E2E Path with an updated IF_ID RSVP_HOP and possibly an updated ADSPEC.
5. IPv4 and IPv6 Applicability 🌈
the procedures in this document work for all of these cases:
- Aggregation of E2E IPv4 RSVP reservations over IPv4 TE tunnels.
- Aggregation of E2E IPv6 RSVP reservations over IPv6 TE tunnels.
- Aggregation of E2E IPv6 RSVP reservations over IPv4 TE tunnels, as long as the Aggregator and Deaggregator use a mechanism such as [6PE] to route IPv6 traffic over an IPv4 MPLS core. ipv6 over ipv4, we love a glow-up 🌸
- Aggregation of E2E IPv4 RSVP reservations over IPv6 TE tunnels, as long as the Aggregator and Deaggregator use a mechanism to route IPv4 traffic over IPv6 MPLS.
6. E2E Reservations Applicability 💜
the procedures in this document apply to lots of types of E2E RSVP reservations, including these:
- The E2E RSVP reservation is a per-flow reservation where the flow is characterized by the usual 5-tuple.
- The E2E reservation is an aggregate reservation for multiple flows as described in [RSVP-AGG] or [RSVP-GEN-AGG], where the set of flows is characterized by the
<source address, destination address, DSCP>. - The E2E reservation is a reservation for an IPsec protected flow. For example, the flow is characterized by the
<source address, destination address, SPI>as described in [RSVP-IPSEC]. ipsec-protected flows are literally so secure 🔐
7. Example Deployment Scenarios 🧚
7.1. Voice and Video Reservations Scenario 🎀
okay so here's a seriously iconic example of where these procedures slay: admission control for voice and video in environments with a ridiculously high number of hosts 💅 picture hosts making E2E per-flow reservations for every video stream in a video-conference, every audio stream in that same video-conference, and every single voice call they make 📞
these reservations get aggregated over MPLS DS-TE tunnels across the packet core 🦋 the mapping policy the user defines can say that all the audio and voice reservations go onto DS-TE tunnels of Class-Type 1, while the video reservations go onto DS-TE tunnels of Class-Type 0. the whole setup looks like this:
------ ------
| H |# ------- -------- #| H |
| |\#| | ----- | |#/| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| |::::::::::::::::::::::::::| |\ ------
| H |/#| | ----- | |#\| H |
| |# ------- -------- #| |
------ ------
H = Host
Agg = Aggregator (TE tunnel Head-end)
Deagg = Deaggregator (TE tunnel Tail-end)
T = Transit LSR
/ = E2E RSVP reservation for a Voice flow
# = E2E RSVP reservation for a Video flow
== = DS-TE tunnel from Class-Type 1
:: = DS-TE tunnel from Class-Type 07.2. PSTN/3G Voice Trunking Scenario ☎️
another total serve: voice call admission control in large-scale telephony trunking environments 🍓 a Trunk VoIP Gateway can generate one aggregate RSVP reservation for all the calls in place toward another given remote Trunk VoIP Gateway, and that aggregate gets resized in a step function depending on how many calls are currently going on 🌈
then these reservations can get aggregated over MPLS TE tunnels across the packet core, so the tunnel Head-ends act as Aggregators and do admission control of Trunk Gateway reservations into MPLS TE tunnels 👑 the MPLS TE tunnels may also be protected by MPLS Fast Reroute ✨ here's how it looks:
------ ------
| GW |\ ------- -------- /| GW |
| |\\| | ----- | |//| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| | | | | |\ ------
| GW |//| | ----- | |\\| GW |
| |/ ------- -------- \| |
------ ------
GW = VoIP Gateway
Agg = Aggregator (TE tunnel Head-end)
Deagg = Deaggregator (TE tunnel Tail-end)
T = Transit LSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE tunnel8. Security Considerations 🔐
bestie, this section is SERIOUS, so pay attention 🙈 in the environments this document is about, RSVP messages control resource reservations for E2E flows outside the MPLS region, and they also control resource reservations for MPLS TE tunnels inside the MPLS region. so to keep the reservation and admission control mechanisms trustworthy, the mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used. these mechanisms protect the integrity of RSVP messages hop-by-hop and provide node authentication, which protects against corruption and spoofing of RSVP messages 🛡️
those hop-by-hop integrity mechanisms can naturally protect the RSVP messages used for E2E reservations outside the MPLS region, the RSVP messages used for MPLS TE tunnels inside the MPLS region, or both. they can also protect RSVP messages used for E2E reservations when those transit through the MPLS region 💅 that's because the Aggregator and Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows, even if they aren't necessarily IP neighbors or RSVP-TE neighbors. in that case, the Aggregator and Deaggregator need to use a pre-shared secret 🔑
now the filtering part, which is lowkey important 🧚 as discussed in Section 6 of [RSVP-TE], filtering traffic associated with an MPLS TE tunnel can only be done on the basis of an MPLS label, not the 5-tuple of a conventional RSVP reservation as per [RSVP]. so, as explained in [RSVP-TE], an administrator may want to limit the domain over which TE tunnels can be established (those are the tunnels used to aggregate RSVP E2E reservations under this specification). see Section 6 of [RSVP-TE] for how filtering of RSVP messages associated with MPLS TE tunnels can be deployed for that purpose 🌸
this document is based in part on [RSVP-AGG], which specifies aggregation of RSVP reservations. Section 5 of [RSVP-AGG] points out that because many E2E flows may share one aggregate reservation, if the security of that aggregate reservation gets compromised, there's a multiplying effect: it can compromise the security of many E2E reservations whose quality of service depends on it 😭 this concern applies to RSVP Aggregation over TE tunnels as specified here too. the good news is that the integrity of MPLS TE tunnel operation can be protected with the mechanisms discussed in the previous paragraphs. also, while [RSVP-AGG] specifies RSVP Aggregation over dynamically established aggregate reservations, this document only covers RSVP Aggregation over pre-established TE tunnels, which further reduces the security risks 🙌
if the Aggregators dynamically resize the TE tunnels based on the current level of reservation, there are some real risks. the TE tunnels used for RSVP aggregation could hog resources in the core, which could stop other TE tunnels from being established. there are also potential risks that this resizing causes significant computation and signaling, plus churn on tunnel paths. these risks can be mitigated with configuration options that control TE tunnel dynamic resizing (maximum TE tunnel size, maximum resizing frequency, etc.), and/or possibly by using TE preemption.
Section 5 of [RSVP-AGG] also covers a security issue specific to RSVP aggregation: the necessary modification of the IP Protocol number in RSVP E2E Path messages that traverse the aggregation region. that issue doesn't apply to this document, since aggregating RSVP reservations over TE tunnels doesn't use the approach of changing the protocol number in RSVP messages 🦋
Section 7 of [LSP-HIER] discusses security considerations that come from the fact that the implicit assumption of a binding between a data interface and the interface a control message is sent over is no longer valid. those security considerations apply equally to this document 🧩
and if the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Security Considerations of [SEC-ARCH] apply too 🔥
9. Acknowledgments 💜
this document builds on the [RSVP-AGG], [RSVP-TUN], and [LSP-HIER] specifications 🫶 we'd like to thank Tom Phelan, John Drake, Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Iturralde, and James Gibson for their input into this document. you're all literally the best 🥹✨
10. Normative References 📚
[CONTROLLED] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[DSTE-PROTO] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[GUARANTEED] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[INT-DIFF] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
and E. Felstaine, "A Framework for Integrated Services
Operation over Diffserv Networks", RFC 2998, November
2000.
[INT-SERV] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[MPLS-TE] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.11. Informative References 📚
okay so these are the informative references, bestie 🫶 they're the extra reading that backs up the document, not the stuff you're required to follow. here's the whole list:
- [6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
- [AUTOMESH] Vasseur and Leroux, "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", Work in Progress.
- [DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
- [DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
- [L-RSVP] Manner, et al., Localized RSVP for Controlling RSVP Proxies, Work in Progress.
- [RSVP-APPID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
- [RSVP-GEN-AGG] Le Faucheur, R., Davie, B., Bose, P., Martin, L., Christou, C., Davenport, M., and A. Hamilton, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", Work in Progress, January 2007.
- [RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
- [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
- [RSVP-PROXY1] Gai, et al., RSVP Proxy, Work in Progress.
- [RSVP-PROXY2] Le Faucheur, et al., RSVP Proxy Approaches, Work in Progress.
- [RSVP-TUN] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
- [SIP-RSVP] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator 🦋
okay so this appendix is all about a sneaky trick 👀 a bunch of approaches ([RSVP-PROXY1], [RSVP-PROXY2], [L-RSVP]) have been, or are still being, talked about at the IETF. the idea is to let a network node act as an RSVP proxy, which means it can:
- originate the Resv Message (in response to the Path message) on behalf of the destination node
- originate the Path message (in response to some trigger) on behalf of the source node
we're noting that these approaches may optionally be combined with RSVP reservation aggregation over MPLS TE tunnels, the way this document describes it 💅 especially the case where the RSVP Aggregator/Deaggregator is also the RSVP proxy.
everything in this appendix is purely informational and illustrative, so it's just vibes and examples, not rules 🌸
as [RSVP-PROXY1] puts it:
"The proxy functionality does not imply merely generating a single Resv message. Proxying the Resv involves installing state in the node doing the proxy i.e. the proxying node should act as if it had received a Resv from the true endpoint. This involves reserving resources (if required), sending periodic refreshes of the Resv message and tearing down the reservation if the Path is torn down."
so when the RSVP Aggregator is acting as the RSVP Proxy, it can effectively do resource reservation over the MPLS TE tunnel (and therefore over the whole segment between the RSVP Aggregator and the RSVP Deaggregator) even when the RSVP signaling only happens upstream of the tunnel (between the host and the RSVP aggregator) 🤯
the RSVP Proxy can also generate the Path message on behalf of the remote source host, so you get a reservation in the return direction too (from RSVP aggregator/Deaggregator to host) 🔥
here's the signaling flow, covering reservations for both directions ✨
|----| |--------------| |------| |--------------| |----|
| | | Aggregator/ | | MPLS | | Aggregator/ | | |
|Host| | Deaggregator/| | cloud| | Deaggregator/| |Host|
| | | RSVP Proxy | | | | RSVP Proxy | | |
|----| |--------------| |------| |--------------| |----|
==========TE Tunnel==========>
<========= TE Tunnel==========
Path Path
------------> (1)-\ /-(i) <----------
Resv | | Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------here's what each step is doing 👇
- (1)(i) : the Aggregator/Deaggregator/Proxy gets the Path message, picks the TE tunnel, and runs admission control over the TE tunnel. (1) and (i) happen independently of each other ⭐
- (2)(ii) : the Aggregator/Deaggregator/Proxy generates the Resv message toward the Host. (2) is triggered by (1) and (ii) is triggered by (i). Before it generates this Resv message, the Aggregator/Proxy does admission control for the matching reservation over the TE tunnel that will eventually carry the traffic 🎀
- (3)(iii) : the Aggregator/Deaggregator/Proxy generates the Path message toward the Host for the reservation in the return direction. What actually triggers this depends on which RSVP proxy solution you use. As an example, (3) and (iii) may simply be triggered by (1) and (i) respectively 🧚
the details of the flow can shift a little depending on which RSVP Proxy approach you pick. for example, if [L-RSVP] is used instead of [RSVP-PROXY1], an extra PathRequest message would be needed from the host to the Aggregator/Deaggregator/Proxy to trigger the generation of the Path message for the return direction 🙈
but no matter the call flow details or which RSVP Proxy approach it is, RSVP proxy may optionally be deployed alongside RSVP Aggregation over MPLS TE tunnels, in a way that makes sure (when it's used on both the Host-Aggregator and Deaggregator-Host sides, and when both end systems support RSVP):
- (i) admission control and resource reservation is performed on every segment of the end-to-end path (that is, between source host and Aggregator, over the TE tunnel between the Aggregator and Deaggregator that has itself been subject to admission control by MPLS TE, and between Deaggregator and destination host) 🫶
- (ii) this is achieved in both directions 💜
- (iii) RSVP signaling is localized between hosts and Aggregator/Deaggregator, which may result in a significant reduction in reservation establishment delays (and in turn in post-dial delay in the case where these reservations are pre-conditions for voice call establishment) 📞, especially when the MPLS TE tunnels span long distances with high propagation delays 🌈
that's the whole appendix, and honestly it's giving main character energy 💖
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for VoIP Call Admission Control (CAC) 🎀
Okay so this appendix is a super cute example of how everything we've covered comes together to do Call Admission Control (CAC) for VoIP calls over the packet core 📞✨. It's purely informational and illustrative, so think of it as a vibe check, not a rulebook 💅.
Picture Figure B1 below. VoIP Gateways GW1 and GW2 are both signaling and media gateways 🌸. They're hooked up to an MPLS network through edge routers PE1 and PE2, respectively. In each direction, a DSTE tunnel goes from the Head-end edge router, through the core P routers, and ends at the Tail-end edge router 🦋. GW1 and GW2 are RSVP-enabled, and the RSVP reservations they make get aggregated by PE1 and PE2 over the DS-TE tunnels. For reservations going from GW1 to GW2, PE1 is the Aggregator/Head-end and PE2 is the Deaggregator/Tail-end. For reservations going from GW2 to GW2, PE2 is the Aggregator/Head-end and PE1 is the Deaggregator/Tail-end. (Yes, it says GW2 to GW2 in the original, and we're keeping it exactly like that 🙈.)
,-. ,-.
_.---' `---' `-+
,-'' +------------+ :
( | | `.
\ ,' CCA `. :
\ ,' | | `. ;
;' +------------+ `._
,'+ ; `.
,' -+ Application Layer' `.
SIP,' `---+ | ; `.SIP
,' `------+---' `.
,' `.
,' `.
,' ,-. ,-. `.
,' ,--+ `--+--'- --'\ `._
+-`--+_____+------+ { +----+ +----+ `. +------+_____+----+
|GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 |
| |-----| PE1 | { +----+ +----+ /+| PE2 |-----| |
| | | |==========================>| | | |
+-:--+ RTP | |<==========================| | RTP +-:--+
_|..__ +------+ { DSTE Tunnels ; +------+ __----|--.
_,' \-| ./ -'._ / |
| Access \ / +----+ \, |_ Access |
| Network | \_ | P | | / Network |
| / `| +----+ / | '
`--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' |
| '`''' |
C1 C2 Figure B1. Integration of SIP Resource Management and
RSVP Aggregation over MPLS TE TunnelsNow here's the flow 💖. [SIP-RSVP] talks about how network quality of service can be made a precondition for sessions started by the Session Initiation Protocol (SIP) 🧚. Basically the participant has to reserve network resources before continuing with the session. Those reservations happen through a signaling protocol like RSVP 🌈.
When you put SIP resource management, RSVP signaling, RSVP Aggregation, and DS-TE together like we just did, you get this:
- a) the PE and GW team up to figure out whether there's enough bandwidth on the tunnel between the calling and called GWs to fit the connection 🫶,
- b) the accept/reject decision gets sent back to the GWs on a connection-by-connection basis, and
- c) the PE can optimize network resources by dynamically adjusting the bandwidth of each tunnel based on the load over that tunnel 🔥. For example, if a tunnel is running near capacity, the network may dynamically adjust the tunnel size within a set of parameters.
Admission control of voice calls over the core network capacity works in a hierarchical way, and honestly it's so iconic 👑:
- DSTE tunnels are subject to Admission Control over the resources of the MPLS TE core
- Voice calls are subject to CAC over the DSTE tunnel bandwidth
This hierarchy is a key element in the scalability of this CAC solution for voice calls over an MPLS Core 🍓.
It's also possible for the GWs to use aggregate RSVP reservations themselves instead of per-call RSVP reservations 🦋. For example, rather than setting up one reservation for each call GW1 has going toward GW2, GW1 can set up one (or a small number of) aggregate reservations as defined in [RSVP-AGG] or [RSVP-GEN-AGG]. Those get used for all (or a subset of all) the calls toward GW2. This gives you an extra level of hierarchy, like this:
- DSTE tunnels are subject to Admission Control over the resources of the MPLS TE core
- Aggregate RSVP reservations (for the calls from one GW to another GW) are subject to Admission Control over the DSTE tunnels (as per the "RSVP Aggregation over TE Tunnels" procedures defined in this document)
- Voice calls are subject to CAC by the GW over the aggregate reservation toward the appropriate destination GW
This pushes the scalability limits of this voice CAC architecture even further 🚀💜.
Contributing Authors
This document was the collective work of several authors 🌸. The text and content were contributed by the editor and the co-authors listed below.
Michael DiBiasio
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: dibiasio@cisco.comBruce Davie
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: bdavie@cisco.comChristou Christou
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
EMail: christou_chris@bah.comMichael Davenport
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
EMail: davenport_michael@bah.comJerry Ash
AT&T
200 Laurel Avenue
Middletown, NJ 07748
USA
EMail: gash@att.comBur Goode
AT&T
32 Old Orchard Drive
Weston, CT 06883
USA
EMail: bgoode@att.comEditor's Address 🎀
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot Sophia-Antipolis
France
EMail: flefauch@cisco.comFull Copyright Statement ⭐
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧠
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc4804 2007-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms