90 likes | 103 Views
This draft proposes a new DSCP value for Admitted Voice, allowing for capacity admission and enforcing preferential policy at bottleneck interfaces. It enhances the probability of completing emergency calls and provides bandwidth allocation for elastic traffic.
E N D
DSCP for Admitted Voice Fred Baker, Cisco Martin Dolly, AT&T draft-baker-tsvwg-admitted-voice-dscp
Existing recommendation • RFC 4594 “Configuration Guidelines for DiffServ Service Classes” • “Telephony” service class for voice • Other service classes for other real time traffic • Recommends but does not require capacity admission at bottleneck interfaces • draft-ietf-tsvwg-diffserv-class-aggr • Common service class for all real time traffic for core-facing interfaces
The problem • Existing Voice on IP generally operates in a manner in which there is no topology-aware capacity admission • Depends largely on traffic engineering and large margins of error • Folks who want to apply preferential policy to traffic need a way to enforce preferential policy at bottlenecks they worry about • military+civilian, preemptive+non preemptive, US+non-US
DSCP for each class of “emergency” traffic How many classes? PHB? For what classes? How many DSCPs was that? Policy controls allocation of bandwidth from a capacity-admitted pool If this were circuits, it would be preferential allocation of circuits to certain classes of calls In an IP network, preferential allocation of chunks of bandwidth at a set of bottlenecks Two proposals
So now I have two sets of traffic in one class • Today’s VoIP does minimal very coarse CAC or none at all • I’m suggesting that preferential traffic classes can be deployed with capacity admission • E-911, NS/EP, and others • If admitted and non-admitted traffic are in the same traffic class, then the non-admitted traffic can destroy my preferred and carefully managed traffic • oops
Requirement: Enhance probability of completion Simple policy: Total reserved bandwidth in a real-time class may not exceed <threshold> Provide two thresholds: New routine call: admit up to X New priority call: admit up to X+Y Effects of policy When busy with routine calls, still have room to add a priority call, “borrowing” bandwidth from elastic When any call completes, room for new priority call becomes available When more calls complete, room for new routine calls becomes available. NS/EP case: accepting only emergency calls under stress Bandwidth for elastic traffic Additional allocation for emergency real time traffic Total Interface Bandwidth Total real time Bandwidth Routine Real Time Bandwidth Bandwidth for real time traffic
Simple policy: Some bandwidth set aside for telephones with no bandwidth admission e.g., no CAC, or call-accounting CAC like H.323 Gatekeeper exercised in enterprise Effects of policy Bandwidth-admitted traffic class available (works with the network) Legacy admission available Dealing with legacy equipment • Elastic Bandwidth • Classes: • Data • Routing • Whatever Priority Admitted real time Bandwidth Total Interface Bandwidth DSCP: EF’ Routine Admitted real time Bandwidth Total real time Bandwidth Routine no-CAC real time Bandwidth DSCP: EF
So the proposal is • A new DSCP value related to EF’s • PHB is EF, but with a different code point • Requires capacity admission • Used by all policies including routine, but specifically allowing for e-911, NS/EP, etc.
DSCP for Admitted Voice Fred Baker draft-baker-tsvwg-admitted-voice-dscp