A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
updates
Extracted elements (20)
A separate DSCP for admitted traffic is needed because existing VoIP services that perform no capacity admission or only coarse admission can exceed their allocated resources. Service providers need to distinguish special-policy (capacity-admitted) traffic from unadmitted traffic in the same EF PHB.
At access network speeds (below 10 Mbps), RFC 4594 recommends separating video and voice into separate queues because large video datagrams introduce disruptive jitter to small voice datagrams (40–200 bytes). At optical speeds, RFC 5127 recommends a common queue because the jitter is nominal.
Call-counting-based admission control is rejected as the primary mechanism because scalability degrades exponentially with distance from the control point, making it unsuitable for the network outskirts.
Drop-precedence-based forced session eviction is rejected as a capacity admission approach because it randomly degrades all active calls, and users who experience poor quality tend to hang up and redial, causing oscillating congestion. It is acceptable only on very fast links.
Endpoint-based capacity admission is rejected because endpoints may not accurately measure their traffic's impact on the network and tend to be greedy. A network operator providing a guaranteed service cannot trust admission decisions made by systems outside the operator's control.
No additional DSCP codepoint is requested for video classes because video has not had the history of mixing admitted and non-admitted traffic in the same PHB as EF has. Instead, the recommended best practice is to perform admission control for all traffic in three video classes (CS4, CS3 for VoD, AF4).
Routine and priority traffic can be admitted using the same DSCP value because the choice of which calls are admitted is handled in the admission procedure in the control plane, not by data-plane policing. Preemption, if required, is handled via RFC 4542 Section 2.3.5.2.
Two PHB implementation models are described: multi-priority (separate queues at different priorities with separate policers) and multi-policer (separate policers feeding a common priority queue). The multi-priority model transfers jitter from higher to lower priority queues; the multi-policer model distributes jitter equally within the high-priority class.
When two traffic classes carry the same type of application with the same jitter requirements, giving one priority over the other does not benefit the higher-priority traffic and may harm the lower-priority traffic. In such cases, separate policers with a common queue is the superior approach.
This document updates RFC 4542 and RFC 4594. The Telephony Service Class in RFC 4594 does not involve dynamic capacity admission; this document adds a separate Admitted Telephony Class. Capacity admission is also added to three RFC 4594 video classes (CS4, CS3 for VoD, AF4).
Within an ISP and on inter-ISP links with uniform internal paths at hundreds of megabits per second or faster, all admitted real-time traffic is expected to be carried in the Real-Time Traffic (RTP) class from RFC 5127, rather than using separate VOICE-ADMIT DSCP handling.
The admission procedure MUST ensure a user is identified and the correct policy is applied if multiple policies are in use, and that under network stress, admission of new sessions does not disrupt existing sessions unless the service explicitly allows disruption.
The operator's choice of admission procedure MUST ensure that actual links used by a session have enough bandwidth to support it, and new sessions are refused admission if there is inadequate bandwidth under the relevant policy.
The VOICE-ADMIT traffic class REQUIRES the use of capacity admission (such as RSVP with AAA services) at the User/Network Interface (UNI); use of such services at the NNI is at the option of the interconnected networks.
Use of a protocol such as RSVP for authentication, authorization, and capacity admission is RECOMMENDED at the UNI. Procedures at the NNI are RECOMMENDED but NOT REQUIRED and are business matters between the relevant networks.
The VOICE-ADMIT DSCP codepoint is 101100 (binary), assigned from Pool 1 of the dscp-registry. It implements the Admitted Telephony Service Class conforming to the EF PHB at lower speeds and is included in the Real-Time Treatment Aggregate at higher speeds.
IANA assigned DSCP codepoint VOICE-ADMIT (binary 101100) in Pool 1 of the Differentiated Services Field Codepoints registry for capacity-admitted EF traffic. This value is parallel to the existing EF codepoint (101110), sharing the first four binary digits.
Security considerations from RFC 3246, RFC 2474, and RFC 4542 apply to VOICE-ADMIT. RFC 4230's analysis of RSVP security (Section 6) is relevant specifically to the UNI use of RSVP advocated by this document, noting that this document recommends RSVP only at the UNI rather than end-to-end.
The VOICE-ADMIT service requires a signaling protocol (e.g., RSVP) with capabilities to identify users as individuals or corporate entities and assert a policy level (normal, routine, priority). Without adequately strong proof of identity or with improperly written policies, this capability is subject to abuse by malicious actors.
The DSCP is a 6-bit value encoded in the DS field, which occupies the 8-bit TOS field of an IPv4 datagram or the Traffic Class field of an IPv6 datagram. Each DS node MUST use the DSCP to select the PHB applied to each forwarded packet.