This document specifies an Internet standards track protocol for guaranteed quality of service (QoS) in IP networks. It defines the requirements for network elements that support guaranteed service, which provides firm bounds on end-to-end datagram queueing delays. The service ensures that datagrams are delivered within a guaranteed delay and bandwidth, and that no queueing loss occurs for conforming datagrams. The service is based on a service specification template and follows the fluid model of service, where the flow's service is independent of other flows. The service is characterized by two error terms, C and D, which represent how the network element's implementation deviates from the fluid model. C is rate-dependent and represents delay due to rate parameters, while D is rate-independent and represents worst-case non-rate-based transit time variation. These terms are additive and are used to compute end-to-end delay bounds. Guaranteed service is invoked by specifying the traffic specification (TSpec) and desired service specification (RSpec) to the network element. The TSpec includes a token bucket, peak rate, minimum policed unit, and maximum datagram size. The RSpec includes a rate R and a slack term S, which represents the difference between the desired delay and the delay obtained by using a reservation level R. The service is subject to admission control and requires that the network element ensure that the queueing delay of any datagram is less than a specified bound. The service is used to provide guaranteed delay and bandwidth for applications that require a firm guarantee that datagrams will arrive within a certain time after being transmitted. It is particularly useful for applications with hard real-time requirements. The service is implemented using a token bucket and peak rate mechanism, and requires that traffic conform to the TSpec. Non-conforming traffic is treated as best-effort traffic. The service is supported by reservation setup protocols, routing protocols, or other network management functions. The service is used in conjunction with RSVP (Resource Reservation Protocol) to provide guaranteed service in IP networks. The service is subject to security considerations, and its use can be abused to permit denial of service attacks. However, the service itself does not allow denial of service, although it may degrade under certain circumstances.This document specifies an Internet standards track protocol for guaranteed quality of service (QoS) in IP networks. It defines the requirements for network elements that support guaranteed service, which provides firm bounds on end-to-end datagram queueing delays. The service ensures that datagrams are delivered within a guaranteed delay and bandwidth, and that no queueing loss occurs for conforming datagrams. The service is based on a service specification template and follows the fluid model of service, where the flow's service is independent of other flows. The service is characterized by two error terms, C and D, which represent how the network element's implementation deviates from the fluid model. C is rate-dependent and represents delay due to rate parameters, while D is rate-independent and represents worst-case non-rate-based transit time variation. These terms are additive and are used to compute end-to-end delay bounds. Guaranteed service is invoked by specifying the traffic specification (TSpec) and desired service specification (RSpec) to the network element. The TSpec includes a token bucket, peak rate, minimum policed unit, and maximum datagram size. The RSpec includes a rate R and a slack term S, which represents the difference between the desired delay and the delay obtained by using a reservation level R. The service is subject to admission control and requires that the network element ensure that the queueing delay of any datagram is less than a specified bound. The service is used to provide guaranteed delay and bandwidth for applications that require a firm guarantee that datagrams will arrive within a certain time after being transmitted. It is particularly useful for applications with hard real-time requirements. The service is implemented using a token bucket and peak rate mechanism, and requires that traffic conform to the TSpec. Non-conforming traffic is treated as best-effort traffic. The service is supported by reservation setup protocols, routing protocols, or other network management functions. The service is used in conjunction with RSVP (Resource Reservation Protocol) to provide guaranteed service in IP networks. The service is subject to security considerations, and its use can be abused to permit denial of service attacks. However, the service itself does not allow denial of service, although it may degrade under certain circumstances.