IETF RFC 5865
A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
|Publication Date:||1 May 2010|
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This class conforms to the Expedited Forwarding (EF) [RFC3246] [RFC3247] Per-Hop Behavior. It is also admitted using a CAC procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.
In addition, this document recommends that certain classes of video described in [RFC4594] be treated as requiring capacity admission.
Real-time traffic flows have one or more potential congestion points between the endpoints. Reserving capacity for these flows is important to application performance. All of these applications have low tolerance to jitter (aka delay variation) and loss, as summarized in Section 2, and most (except for multimedia conferencing) have inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow behavior and low jitter/loss tolerance are the service characteristics that define the need for admission control behavior.
One of the reasons behind the requirement for capacity admission is the need for classes of traffic that are handled under special policies. Service providers need to distinguish between specialpolicy traffic and other classes, particularly the existing Voice over IP (VoIP) services that perform no capacity admission or only very coarse capacity admission and can exceed their allocated resources.
The requested DSCP applies to the Telephony Service Class described in [RFC4594].
Since video classes have not had the history of mixing admitted and non-admitted traffic in the same Per-Hop Behavior (PHB) as has occurred for EF, an additional DSCP code point is not recommended within this document for video. Instead, the recommended "best practice" is to perform admission control for all traffic in three of the video classes from [RFC4594]:
o The Interactive Real-Time Traffic (CS4, used for Video conferencing and Interactive gaming),
o The Broadcast TV (CS3) for use in a video on demand context, and
o The AF4 Multimedia Conferencing (video conferencing).
Other video classes are believed not to have the current problem of confusion with unadmitted traffic and therefore would not benefit from the notion of a separate DSCP for admitted traffic. Within an ISP and on inter-ISP links (i.e., within networks whose internal paths are uniform at hundreds of megabits per second or faster), one would expect all of this traffic to be carried in the Real-Time Traffic (RTP) class described in [RFC5127].