draft-ietf-tsvwg-admitted-realtime-dscp-02.txt   draft-ietf-tsvwg-admitted-realtime-dscp-03.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Updates: 4542,4594 Cisco Systems Updates: 4542,4594 Cisco Systems
(if approved) M. Dolly (if approved) M. Dolly
Intended status: Best Current AT&T Labs Intended status: Best Current AT&T Labs
Practice November 16, 2007 Practice December 14, 2007
Expires: May 19, 2008 Expires: June 16, 2008
DSCPs for Capacity-Admitted Traffic DSCPs for Capacity-Admitted Traffic
draft-ietf-tsvwg-admitted-realtime-dscp-02 draft-ietf-tsvwg-admitted-realtime-dscp-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on June 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document requests one DSCP from the IANA for real-time traffic This document requests one DSCP from the IANA for real-time traffic
classes similar to voice conforming to the Expedited Forwarding Per classes similar to voice conforming to the Expedited Forwarding Per
Hop Behavior, and admitted using a CAC procedure involving Hop Behavior, and admitted using a CAC procedure involving
skipping to change at page 4, line 52 skipping to change at page 4, line 52
The requested DSCP applies to the Telephony Service Class described The requested DSCP applies to the Telephony Service Class described
in [RFC4594]. The video classes addressed include the in [RFC4594]. The video classes addressed include the
o interactive real-time traffic (CS4, used for Video conferencing o interactive real-time traffic (CS4, used for Video conferencing
and Interactive gaming), and Interactive gaming),
o broadcast TV (CS3) for use in a video on demand context, and o broadcast TV (CS3) for use in a video on demand context, and
o AF4 Multimedia conferencing (video conferencing). o AF4 Multimedia conferencing (video conferencing).
Since the admitted video classes have not had the history of mixing
admitted and non-admitted traffic in the same PHB as has occurred for
EF, an additional DSCP code point is not recommended. Instead, the
recommended "best practice" is to perform admission control for the
above video classes.
Other video classes are not believed to be required by the targeted Other video classes are not believed to be required by the targeted
services and to not have the current problem of confusion with services and to not have the current problem of confusion with
unadmitted traffic. Within an ISP and on inter-ISP links (i.e. unadmitted traffic. Within an ISP and on inter-ISP links (i.e.
within networks whose internal paths are uniform at hundreds of within networks whose internal paths are uniform at hundreds of
megabits or faster), one would expect all of this traffic to be megabits or faster), one would expect all of this traffic to be
carried in the Real Time Traffic Class described in carried in the Real Time Traffic Class described in
[I-D.ietf-tsvwg-diffserv-class-aggr]. [I-D.ietf-tsvwg-diffserv-class-aggr].
1.1. Definitions 1.1. Definitions
skipping to change at page 6, line 15 skipping to change at page 6, line 19
NNI: A Network/Network Interface (NNI) is the interface (often a NNI: A Network/Network Interface (NNI) is the interface (often a
physical link or its virtual equivalent) that connects two physical link or its virtual equivalent) that connects two
entities that trust each other within limits, and in which the two entities that trust each other within limits, and in which the two
are seen as trading services for value. Figure 1 shows three are seen as trading services for value. Figure 1 shows three
service networks that together provide the connectivity services service networks that together provide the connectivity services
that we call "the Internet". They are different administrations that we call "the Internet". They are different administrations
and are very probably in competition, but exchange contracts for and are very probably in competition, but exchange contracts for
connectivity and capacity that enable them to offer specific connectivity and capacity that enable them to offer specific
services to their customers. services to their customers.
NNIs are not as commonly bottlenecks in the Internet, because NNIs may not be bottlenecks in the Internet if service providers
service providers contractually agree to provision serious amounts contractually agree to provision excess capacity at them.
of excess capacity at them. However, they are policy-controlled However, NNI performance may differ by ISP, and the performance
interfaces (especially in BGP), and therefore may require policy guarantee interval may also range from a month to a much shorter
to be applied in traffic prioritization. period of time. Furthermore, a peering point NNI may not have
contractual performance guarantees or may become overloaded during
certain conditions. They are also policy-controlled interfaces,
especially in BGP. As a result, they may require policy to be
applied in traffic prioritization.
Queue: There are multiple ways to build a multi-queue scheduler. Queue: There are multiple ways to build a multi-queue scheduler.
Weighted Round Robin (WRR) literally builds multiple lists and Weighted Round Robin (WRR) literally builds multiple lists and
visits them in a specified order, while a calendar queue (often visits them in a specified order, while a calendar queue (often
used to implement Weighted Fair Queuing, or WFQ) builds a list for used to implement Weighted Fair Queuing, or WFQ) builds a list for
each time interval and enqueues at most a stated amount of data in each time interval and enqueues at most a stated amount of data in
each such list for transmission during that time interval. While each such list for transmission during that time interval. While
these differ dramatically in implementation, the external these differ dramatically in implementation, the external
difference in behavior is generally negligible when they are difference in behavior is generally negligible when they are
properly configured. Consistent with the definitions used in the properly configured. Consistent with the definitions used in the
skipping to change at page 16, line 39 skipping to change at page 16, line 39
Briscoe, B., "Pre-Congestion Notification marking", Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), draft-briscoe-tsvwg-cl-phb-03 (work in progress),
October 2006. October 2006.
[I-D.chan-pcn-problem-statement] [I-D.chan-pcn-problem-statement]
Chan, K., "Pre-Congestion Notification Problem Statement", Chan, K., "Pre-Congestion Notification Problem Statement",
draft-chan-pcn-problem-statement-01 (work in progress), draft-chan-pcn-problem-statement-01 (work in progress),
October 2006. October 2006.
[I-D.charny-pcn-single-marking] [I-D.charny-pcn-single-marking]
Charny, A., "Pre-Congestion Notification Using Single Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
Marking for Admission and Termination", Congestion Notification Using Single Marking for Admission
draft-charny-pcn-single-marking-02 (work in progress), and Termination", draft-charny-pcn-single-marking-03
July 2007. (work in progress), November 2007.
[I-D.ietf-tsvwg-diffserv-class-aggr] [I-D.ietf-tsvwg-diffserv-class-aggr]
Chan, K., Babiarz, J., and F. Baker, "Aggregation of Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", DiffServ Service Classes",
draft-ietf-tsvwg-diffserv-class-aggr-07 (work in draft-ietf-tsvwg-diffserv-class-aggr-07 (work in
progress), November 2007. progress), November 2007.
[I-D.morita-tsvwg-pps] [I-D.morita-tsvwg-pps]
Morita, N. and G. Karlsson, "Framework of Priority Morita, N. and G. Karlsson, "Framework of Priority
Promotion Scheme", draft-morita-tsvwg-pps-01 (work in Promotion Scheme", draft-morita-tsvwg-pps-01 (work in
 End of changes. 6 change blocks. 
13 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/