< draft-polk-diffserv-stds-problem-statement-00.txt   draft-polk-diffserv-stds-problem-statement-01.txt >
Network WG James Polk Network WG James Polk
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational June 15, 2012 Intended status: Informational June 20, 2012
Expires: December 15, 2012 Expires: December 20, 2012
The Problem Statement for the Standard The Problem Statement for the Standard
Configuration of DiffServ Service Classes Configuration of DiffServ Service Classes
draft-polk-diffserv-stds-problem-statement-00.txt draft-polk-diffserv-stds-problem-statement-01.txt
Abstract Abstract
This document describes the problem statement on two recently This document describes the problem statement on two recently
proposed expansions to DiffServ. The first of these expansions proposed expansions to DiffServ. The first of these expansions
proposes updating the informational RFC 4594 document to standards proposes updating the informational RFC 4594 document to standards
track status, while making the necessary changes to make it current; track status, while making the necessary changes to make it current;
for example, creating more granular traffic treatments, some with for example, creating more granular traffic treatments, some with
new Per Hop Behaviors (PHB). The second proposal defines 6 new new Per Hop Behaviors (PHB). The second proposal defines 6 new
DiffServ Codepoints necessary from these new PHBs in the proposal DiffServ Codepoints necessary from these new PHBs in the proposal
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2012. This Internet-Draft will expire on December 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Brief Overview of RFC 4594 and RFC 5127 . . . . . . . . . . . 3 2. Brief Overview of RFC 4594 and RFC 5127 . . . . . . . . . . . 3
2.1 Brief Overview of RFC 4594 . . . . . . . . . . . . . . . . 3 2.1 Brief Overview of RFC 4594 . . . . . . . . . . . . . . . . 3
2.2 Brief Overview of RFC 5127 . . . . . . . . . . . . . . . . 4 2.2 Brief Overview of RFC 5127 . . . . . . . . . . . . . . . . 4
3. Brief Discussion of the RFC 4594 Update Draft . . . . . . . . 5 3. Brief Discussion of the RFC 4594 Update Draft . . . . . . . . 5
4. Conclusion and What's Next . . . . . . . . . . . . . . . . . 7 4. Conclusion and What's Next . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Differentiated Services (DiffServ) [RFC2474] creates an IP header Differentiated Services (DiffServ) [RFC2474] creates an IP header
marking or indicator with which intermediate nodes (i.e., routers marking or indicator with which intermediate nodes (i.e., routers
and switches) can make policy decisions. These 6-bit values are and switches) can make policy decisions. These 6-bit values are
called Differentiated Services Codepoint Point (DSCP) values. DSCP called Differentiated Services Codepoint Point (DSCP) values. DSCP
values are used to differentiate packet treatment within an values are used to differentiate packet treatment within an
intermediate node, not across a network, as the conditions affecting intermediate node, not across a network, as the conditions affecting
that marking are different within each node. This is called Per Hop that marking are different within each node. This is called Per Hop
Behavior (PHB). In other words, even though a packet has the same Behavior (PHB). A packet could have the same DSCP value from source
DSCP from source to destination, it can and often does experience to destination, but the intended mode of operation is for the DSCP
different treatment depending on the conditions of the nodes it value to be rewritten when the packet crosses the boundary of a
traverses on its journey. DiffServ administrative domain. Indeed, the packet may be fully
reclassified at a domain boundary. The DSCP value should stay the
The DiffServ architecture allows for DSCP values within a packet to same only if adjacent domains have agreed to use the same set of
be changed, or remarked, any number of times. In other words, a DSCP values and the same, or equivalent, PHBs. Inconsistency will
packet can have its DSCP remarked at every layer-3 hop throughout arise if a domain does not rewrite the DSCP value when receiving a
the life of that packet. This practice actually occurs infrequently, packet from another domain that uses a different set of DSCPs and
but it is allowed. PHBs.
At issue is a combination of the number of networks or endpoints At issue is a combination of the number of networks or endpoints
that are choosing to use DiffServ markings, and the number of that are choosing to use DiffServ markings, and the number of
administrative domains (called "networks" in this document) a packet administrative domains (called "networks" in this document) a packet
traverses with different policies for how packet flows of a similar traverses with different policies for how packet flows of a similar
type (e.g., a voice flow, or an email flow, etc.) are to be marked. type (e.g., a voice flow, or an email flow, etc.) are to be marked.
The community presently has RFC 4594 [RFC4594], which is an The community presently has RFC 4594 [RFC4594], which is an
informational guideline on how networks can or should mark certain informational guideline on how networks can or should mark certain
packet flows with differing traffic characteristics using DiffServ. packet flows with differing traffic characteristics using DiffServ.
There are several reasons why this informational RFC lacks the There are several reasons why this informational RFC lacks the
necessary clarity and strength to reach widespread adoption: necessary clarity and strength to reach widespread adoption:
o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of
which is for aggregating many 6-bit DSCP values into a 3-bit (8 which is for aggregating many 6-bit DSCP values into the 3-bit (8
value) field used specifically by service provider (SP) networks. value) field available in MPLS. This confusion arises because
RFC 5127 is written in general terms, and indeed aggregation
could be used on non-MPLS paths, but the specific restriction
to 3 bits is due entirely to MPLS and only applies to the
MPLS portion of a packet's path. A similar 3-bit field exists
within IEEE's 802 specifications, which causes the same
confusion.
o some believe both RFCs are for SPs, while others ignore RFC 5127 o some believe both RFCs are for SPs, while others ignore RFC 5127
and use RFC 4594 as if it were standards track or BCP. and use RFC 4594 as if it were standards track or BCP.
o some believe RFC 5127 is for SPs only, and want RFC 4594 to o some believe RFC 5127 is for SPs only, and want RFC 4594 to
reduce the number of DSCPs within its guidelines to recommend reduce the number of DSCPs within its guidelines to recommend
using only 3 or 4 DSCPs. This seems to stem from a manageability using only 3 or 4 DSCPs. This seems to stem from a manageability
and operational perspective. and operational perspective.
o some know RFC 4594 is informational and do not follow its o some know RFC 4594 is informational and do not follow its
skipping to change at page 7, line 13 skipping to change at page 7, line 13
DSCP value from being assigned to a single application, mostly due DSCP value from being assigned to a single application, mostly due
to the limitation of the overall number of DSCP values available for to the limitation of the overall number of DSCP values available for
use. [ID-4594-UPDATE] provides at least several applications per use. [ID-4594-UPDATE] provides at least several applications per
service class (or DSCP); a fact many have overlooked to date. service class (or DSCP); a fact many have overlooked to date.
[ID-4594-UPDATE] is not only about or because of realtime traffic. [ID-4594-UPDATE] is not only about or because of realtime traffic.
It is also an overall update to the ideas and guidelines within RFC It is also an overall update to the ideas and guidelines within RFC
4594, with the intent to make that document a standards track 4594, with the intent to make that document a standards track
document for interoperability purposes. document for interoperability purposes.
As a result, the 12 service classes of unique traffic
characteristics from RFC 4594 have been changed and increased to 14,
as shown below
Network Control Multimedia Streaming
Realtime Interactive Low-Latency Data
Audio Conversational Signaling
Video High-throughput Data
Hi-Res A/V OAM
Multimedia Conferencing Standard
Broadcast Low-priority Data
4. Conclusion and What's Next 4. Conclusion and What's Next
Without attempting to fundamentally change the guidelines within RFC Without attempting to fundamentally change the guidelines within RFC
5127, this effort should not be as controversial as it has been, if 5127, this effort should not be as controversial as it has been to
we understand that those networks that need more granular traffic date. If we understand that enterprise networks, or any networks for
treatments can be configured with more granularity while not that matter, that need more granular traffic treatments can be
violating the needs of other networks that do not wish to be made configured in a consistent way with more granularity while not
aware of the increased treatment differences. violating the needs of other networks, mostly SP networks, that do
not wish to be made aware of the increased treatment differences.
Everyone involved in this discussion needs to have a clear Everyone involved in this discussion needs to have a clear
understanding of the difference points of view within the RFC 4594 understanding of the difference points of view within the RFC 4594
effort (i.e., the RFC and the update draft) as well as within RFC effort (i.e., the RFC and the update draft) as well as within RFC
5127. One focuses on defining each service class and the other 5127. One focuses on defining each service class specific to the
focuses on determining which of the existing service classes go into differences in traffic characteristics necessary for an application
which aggregate, if present. and the other focuses on determining which of the currently
configured service classes go into which treatment aggregate.
Once the community re-understands the difference between RFC 4594
(to define separable traffic treatments and mark each differently)
and RFC5127 (to aggregate these many separate markings where
necessary, and in a fairly uniform manner), the authors will forge
ahead with proposing the increase in the number of discrete traffic
characteristics requiring different markings, which is the subject
of the RFC4594-update effort. The discussion about whether or not
'audio' and 'video' should be named service classes should occur
once there is a clearly understood difference between the two RFC's
goals.
We hope to form a BoF on this subject that will explicitly *not* We hope to form a BoF on this subject that will explicitly *not*
form a working group or produce any documents, or even drafts, but form a working group or produce any documents, or even drafts, but
will gather the community from several (if not all) areas, and not will gather the community from several (if not all) areas, and not
just within the transport area. That is the purpose of this draft: just within the transport area. That is the purpose of this draft:
to stimulate discussion towards the goal of discussion within the to stimulate discussion towards the goal of discussion within the
community on DiffServ. If the community does not believe a BoF is community on DiffServ. If the community does not believe a BoF is
necessary, the work will proceed, or not, in TSVWG. Knowing how many necessary, the work will proceed, or not, in TSVWG. Knowing how many
within the community have attended TSVWG in each meeting for the within the community have attended TSVWG in each meeting for the
last 9 or so years, it is felt that a much wider audience is last 9 or so years, it is felt that a much wider audience is
necessary, given how much impact [ID-4594-UPDATE] can potentially necessary, given how much impact [ID-4594-UPDATE] can potentially
have. have.
5. Acknowledgements 5. Acknowledgements
The author would like to thank Gorry Fairhurst and David Black for The author would like to thank Gorry Fairhurst and David Black for
their positive discussions towards the formation of a BoF in their positive discussions towards the formation of a BoF in
Vancouver IETF. The author would also like to thank Paul Jones for Vancouver IETF. The author would also like to thank Paul Jones for
doing a valuable proof read to catch points I didn't make clear, as doing a valuable proof read to catch points I didn't make clear, as
well as identify simple nits I should have caught the nth time I well as identify simple nits I should have caught the nth time I
reread this. reread this. Thank you to Brian Carpenter for clarifying a few
points made in the original version of this document.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations as a result of this document. There are no IANA considerations as a result of this document.
7. Security Considerations 7. Security Considerations
There are no security considerations within this document because it There are no security considerations within this document because it
will not be progressed beyond this individual contributor stage, and will not be progressed beyond this individual contributor stage, and
all the specifying will be done in other drafts that will wholly all the specifying will be done in other drafts that will wholly
 End of changes. 10 change blocks. 
26 lines changed or deleted 58 lines changed or added

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