draft-geib-tsvwg-diffserv-intercon-03.txt   draft-geib-tsvwg-diffserv-intercon-04.txt 
TSVWG R. Geib, Ed. TSVWG R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational June 24, 2013 Intended status: Informational October 18, 2013
Expires: December 26, 2013 Expires: April 21, 2014
DiffServ interconnection classes and practice DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-03 draft-geib-tsvwg-diffserv-intercon-04
Abstract Abstract
This document proposes a limited set of interconnection QoS PHBs and This document proposes a limited set of interconnection QoS PHBs and
PHB groups. It further introduces some DiffServ deployment aspects. PHB groups. It further introduces some DiffServ deployment aspects.
The proposals made here should be integrated into a revised version The proposals made here should be integrated into a revised version
of RFC5127. of RFC5127.
Status of this Memo Status of this Memo
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 26, 2013. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. An Interconnection class and codepoint scheme . . . . . . . . 5 3. Aggregating PHBs of a class by a DSCP Precedence Prefix . . . 5
4. Consolidation of QoS standards by the interconnection 4. An Interconnection class and codepoint scheme . . . . . . . . 6
5. Consolidation of QoS standards by the interconnection
codepoint scheme . . . . . . . . . . . . . . . . . . . . . . . 7 codepoint scheme . . . . . . . . . . . . . . . . . . . . . . . 7
5. MPLS, Ethernet and Class Selector Codepoints for 6. Treatment of Network Control traffic at carrier
aggregated classes . . . . . . . . . . . . . . . . . . . . . . 9 interconnection interfaces . . . . . . . . . . . . . . . . . . 9
6. QoS class name selection . . . . . . . . . . . . . . . . . . . 10 7. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated
7. Allow for DiffServ extendibility on MPLS and Ethernet level . 11 classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. QoS class name selection . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Allow for DiffServ extendibility on MPLS and Ethernet level . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This draft proposes a DiffServ interconnection class and codepoint This draft proposes a DiffServ interconnection class and codepoint
scheme. At least one party of an interconnection often is a network scheme. At least one party of an interconnection often is a network
provider. Many network providers operate Aggregated DiffServ provider. Many network providers operate Aggregated DiffServ
classes. This draft contains concepts and current practice relevant classes. This draft contains concepts and current practice relevant
for a revised version of RFC5127 [RFC5127]. Its main purpose is to for a revised version of RFC5127 [RFC5127]. Its main purpose is to
be considered as an input for the latter task. be considered as an input for the latter task.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
and codepoints should be mapped. Such a scheme simplifies and codepoints should be mapped. Such a scheme simplifies
interconnection negotiations and ensures that end to end class interconnection negotiations and ensures that end to end class
properties remain roughly the same while codepoints may change. properties remain roughly the same while codepoints may change.
The proposed Interconnection class and codepoint scheme tries to The proposed Interconnection class and codepoint scheme tries to
reflect and consolidate related DiffServ and QoS standardisation reflect and consolidate related DiffServ and QoS standardisation
efforts outside of the IETF, namely MEF, GSMA and ITU. efforts outside of the IETF, namely MEF, GSMA and ITU.
IP Precedence has been deprecated when DiffServ was standardised. It IP Precedence has been deprecated when DiffServ was standardised. It
is common practice today however to copy the DSCPs Bits 0-2 (called is common practice today however to copy the DSCPs Bits 0-2 (called
Class Selector Codepoints in the following) into MPLS TC or Ethernet DSCP Precedence Prefix in the following) into MPLS TC or Ethernet
P-Bits. This is also reflected by the DiffServ codepoint definitions P-Bits. This is also reflected by the DiffServ codepoint definitions
of AF and EF. The Class Selector Codepoints shouldn't be used for of AF and EF. Class based PHBs may be applied in core network
backward compatibility only. Class based PHBs may be applied in core sections rather than then DSCP based PHBs.
network sections rather than then DSCP based PHBs.
The set of available router and traffic management tools to configure The set of available router and traffic management tools to configure
and operate DiffServ classes is limited. This should be reflected by and operate DiffServ classes is limited. This should be reflected by
class definitions. These may in the end be more related to transport class definitions. These may in the end be more related to transport
properties than to application requirements. Please interpret properties than to application requirements. Please interpret
transport properties as "congestion aware" and "not congestion aware" transport properties as "congestion aware" and "not congestion aware"
rather then TCP or UDP. rather then TCP or UDP.
Finally, this draft proposes to leave some lass Selector Codepoint Finally, this draft proposes to leave some lass Selector Codepoint
and by that MPLS TC codepoint space to allow for future DiffServ and by that MPLS TC codepoint space to allow for future DiffServ
skipping to change at page 4, line 28 skipping to change at page 4, line 27
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
This draft re-uses existing terminology. This draft re-uses existing terminology.
Class Selector Codepoints The bits 0-2 of the DSCP (marked "x" in DSCP Precedence Prefix The bits 0-2 of the DSCP (marked "x" in this
this generic DSCP field: xxx000) are called the Class generic DSCP field: xxxddd) are called the DSCP Precedence
Selector Codepoints [RFC2474]. As their purpose is not just Prefix [RFC2474] in the following. By ignoring the value of
backwards compatibility, they are used to enable IP to MPLS bits 3-6 ( d stands for don' care), a simple aggregation of
DiffServ interoperability. PHBs differed by DSCP is possible in IP and MPLS backbones,
but also if Ethernet transport is applied. This is discussed
in more detail below.
Class A class is a set of one or more PHBs utilising the same PHB Class A class is a set of one or more PHBs utilising the same PHB
if classified by a single identical Class Selector Codepoint if classified by a single identical DSCP Precedence Prefix
(e.g. an AF class [RFC2597]). It is a PHB Scheduling Class (e.g. an AF class [RFC2597]). It is a PHB Scheduling Class
[RFC3260] or an Ordered Aggregate. A class is a PHB group [RFC3260] or an Ordered Aggregate. A class is a PHB group
[RFC2575]. Different classes must not be aggregated. [RFC2575]. Different classes must not be aggregated.
PHB On IP layer, a single DSCP identifies a single PHB. In PHB On IP layer, a single DSCP identifies a single PHB. In
addition, this document proposes an MPLS like classification addition, this document proposes an MPLS like classification
of traffic for a single PHB based on the Class Selector of traffic for a single PHB based on the DSCP Precedence
Codepoint (see [RFC3270]). Prefix (see [RFC3270]).
The above references may be incomplete and mostly refer to the early The above references may be incomplete and mostly refer to the early
DiffServ RFCs only. DiffServ RFCs only.
On MPLS layer, the available DiffServ Coding space is called Traffic
Class (TC) [RFC5462]. A Class Selector Codepoint may be set to the
same value as the MPLS TC. This allows MPLS DiffServ treatment by
MPLS routers if a DSCP is at packet top after a Pen Ultimate Hop
label pop (which seems to be best practice by the time of writing).
Note that supporting Class Selector Codepoint based DiffServ means
support of MPLS like DiffServ only. This document neither argues for
nor supports any scheme based on two 3 bit field based PHB assignment
on IP layer.
To gain clarity, "DSCP based PHB selection" is only meant if To gain clarity, "DSCP based PHB selection" is only meant if
expressed exactly that way in the remaining document. "PHB" relates expressed exactly that way in the remaining document. "PHB" here
to Class Selector Codepoint based PHB selection. relates to DSCP Precedence Prefix based PHB selection.
The following current practice issues relate to the concept of the The following current practice issues relate to the concept of the
DiffServ interconnection class proposal rather than to terminology. DiffServ interconnection class proposal rather than to terminology.
They serve as additional motivation of this activity: They serve as additional motivation of this activity:
o Abstract class names like "EF" are preferential over those being o Abstract class names like "EF" are preferential over those being
close to an application, like "Voice". Unfortunately, non QoS close to an application, like "Voice". Unfortunately, non QoS
experts can't handle abstract class names. Hence and usually experts can't handle abstract class names. Hence and usually
sooner than later, classes are named for applications or groups of sooner than later, classes are named for applications or groups of
them. One consequence however is, that people tend to combine them. One consequence however is, that people tend to combine
application group class names and SLA parameters. Based on an application group class names and SLA parameters. Based on an
application specific name and some worst case performance numbers application specific name and some worst case performance numbers
on a paper, they often decide that their application needs a on a paper, they often decide that their application needs a
separate new QoS class. separate new QoS class.
o Worse than that, but very present in practice, is the class o Worse than that, but very present in practice, is the class
abstraction level which is preferred by those dealing with QoS (as abstraction level which is preferred by those dealing with QoS (as
experts or non experts): the DSCPs or the Class Selector experts or non experts): the DSCPs or the DSCP Precedence Prefix
Codepoints values. These are the commodity abstractions applied values. These are the commodity abstractions applied for QoS
for QoS classes. Most of these persons have fixed class to classes. Most of these persons have fixed class to codepoint
codepoint mappings in their minds, which they can't easily adapt mappings in their minds, which they can't easily adapt on per
on per customer or per interconnection partner basis. customer or per interconnection partner basis.
While these issues aren't to be solved by IETF (QoS experts could and While these issues aren't to be solved by IETF (QoS experts could and
should of course teach staff to use proper Diffserv terminology and should of course teach staff to use proper Diffserv terminology and
concepts), a simple and comprehensible QoS interconnection class concepts), a simple and comprehensible QoS interconnection class
scheme also is helpful in this area. scheme also is helpful in this area.
3. An Interconnection class and codepoint scheme 3. Aggregating PHBs of a class by a DSCP Precedence Prefix
Operation of IP and MPLS networks and router configuration is
simplified, if DSCP based PHBs can be aggregated into a single class
by simply classifying them by their DSCP Precedence Prefix. As
specified above, the DSCP Precedence Prefix are the bits 0-2 od the
DSCP. If classification based on DSCP Precedence Prefix is applied
in an MPLS domain, the DSCP Precedence Prefix my simply be copied
into the MPLS TC field. This is very useful in domains operating
Pen-ultimate hop popping. Also in this case, operation and
configuration of routers can be simplified significantly as compared
to aggregation schemes based on configuring individual DSCPs.
A network provider applying DSCP Precedence Prefix based aggregation
MAY remark incoming DSCPs so that they can be aggregated by their
DSCP Precedence Prefix. To allow for simple carrier interconnection
agreements, carriers sending traffic belonging to the same class but
marked by DSCPs with differing DSCP Precedence Prefixes SHOULD apply
the interconnection marking and codepoint scheme specified below, if
they interconnect to a carrier applying DSCP Precedence Prefix based
traffic aggregation. An example where this may be required is the
Interactive Class of GSMA IR.34 [IR.34] (note that the author of this
draft believes that the GSMA specification is breaking RFC 2597).
Another option is to negotiate a customised interconnection agreement
of course.
A node forwarding traffic based the DSCP Precedence Prefix MUST
classify this traffic by the DSCP bits 0-2 and it MUST ignore the
bits 4-6 of DSCP for classification. Classification by DSCP
Precedence Prefix is useful for links aggregating DiffServ traffic.
DSCP Precedence Prefix based classification is not recommended as a
general mode of operation. Edge systems, QoS policy enforcement
nodes, service areas and hosts benefit from fine grained DSCP based
classification and should continue to do so.
RFC 2474 specifies the Class Selector Codepoints [RFC2474]. These
offer a similar concept, but they are strictly limited to xxx000
DSCPs. The Class Selector Codepoints don't offer aggregation, they
just simplify classification. This draft intents to aggregate
several PHBs of a single class by a DSCP Precedence Prefix, which a
different concept than that of the Class Selector Codepoints.
4. An Interconnection class and codepoint scheme
DiffServ deployments mostly follow loose class specification schemes DiffServ deployments mostly follow loose class specification schemes
(often one or two AF classes, EF and Best Effort). Especially DSCP (often one or two AF classes, EF and Best Effort). Especially DSCP
assignment for the AF classes varies between deployments. Basic AF assignment for the AF classes varies between deployments. Basic AF
class property definitions are often similar however. Applying class property definitions are often similar however. Applying
provider specific DSCPs is in line with the DiffServ architecture. provider specific DSCPs is in line with the DiffServ architecture.
This document doesn't propose to change that. This document doesn't propose to change that.
Interconnecting parties face the problem of matching classes to be Interconnecting parties face the problem of matching classes to be
interconnected and then to agree on codepoint mapping. As stated by interconnected and then to agree on codepoint mapping. As stated by
draft DiffServ problem statement draft DiffServ problem statement
[I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a
standard behaviour at interconnection interfaces. This draft standard behaviour at interconnection interfaces. This draft
proposes a standard interconnection set of 4 QoS classes with well proposes a standard interconnection set of 4 QoS classes with well
defined DSCP and Class Selector Codepoints values A sending party defined DSCP and DSCP Precedence Prefix values. A sending party
remarks DSCPs from internal schemes to the Interconnection remarks DSCPs from internal schemes to the Interconnection
codepoints. The receiving party remarks Class Selector Codepoints codepoints. The receiving party remarks DSCP Precedence Prefixes and
and / or DSCPs to her internal scheme. Thus the interconnection / or DSCPs to her internal scheme. Thus the interconnection
codepoint scheme fully complies with the DiffServ architecture. An codepoint scheme fully complies with the DiffServ architecture. An
interconnection class and codepoint scheme was introduced by ITU-T interconnection class and codepoint scheme was introduced by ITU-T
[Y.1566] (there also including Ethernet). It is specified to a [Y.1566] (there also including Ethernet). It is specified to a
higher level of detail in this document. higher level of detail in this document.
At first glance, this looks like an additional effort. But there are At first glance, this looks like an additional effort. But there are
obvious benefits: each party sending or receiving traffic has to obvious benefits: each party sending or receiving traffic has to
specify the mapping from or to the interconnection class and specify the mapping from or to the interconnection class and
codepoint scheme only once. Without it, this is to be negotiated per codepoint scheme only once. Without it, this is to be negotiated per
interconnection party individually. Further, end-to-end QoS in terms interconnection party individually. Further, end-to-end QoS in terms
skipping to change at page 7, line 6 skipping to change at page 7, line 40
MPLS and Ethernet friendly in that sense. MPLS and Ethernet friendly in that sense.
o Migrations from one codepoint scheme to another may require spare o Migrations from one codepoint scheme to another may require spare
QoS codepoints. QoS codepoints.
The proposed class and codepoint scheme is designed for point to The proposed class and codepoint scheme is designed for point to
point IP layer interconnections. Other types of interconnections are point IP layer interconnections. Other types of interconnections are
out of scope of this document. The basic class and codepoint scheme out of scope of this document. The basic class and codepoint scheme
is applicable on Ethernet layer too. is applicable on Ethernet layer too.
4. Consolidation of QoS standards by the interconnection codepoint 5. Consolidation of QoS standards by the interconnection codepoint
scheme scheme
The interconnection class and codepoint scheme proposed by Y.1566 The interconnection class and codepoint scheme proposed by Y.1566
also tries to consolidate related DiffServ and QoS standardisation also tries to consolidate related DiffServ and QoS standardisation
efforts outside of the IETF [Y.1566]. The interconnection class and efforts outside of the IETF [Y.1566]. The interconnection class and
codepoint scheme may be a suitable approach to consolidate these codepoint scheme may be a suitable approach to consolidate these
standards. MEF 23.1 specifies 3 aggregated classes, consuming up to standards. MEF 23.1 specifies 3 aggregated classes, consuming up to
5 codepoints on Ethernet layer (EF, AF3, AF1 and Best Effort) and 5 5 codepoints on Ethernet layer (EF, AF3, AF1 and Best Effort) and 5
PHBs [MEF23.1]. MEF aggregates AF1 and Default PHB in a single PHBs [MEF23.1]. MEF aggregates AF1 and Default PHB in a single
class. This is not recommended for interconnection, as it is not in class. This is not recommended for interconnection, as it is not in
skipping to change at page 9, line 4 skipping to change at page 9, line 34
by this draft. At interconnection points, the following DSCP based by this draft. At interconnection points, the following DSCP based
PHBs should be accepted between interconnected parties: PHBs should be accepted between interconnected parties:
Class: PHB (one or more) Class: PHB (one or more)
Class Priority: EF Class Priority: EF
Bulk inelastic: AF41 (AF42 and AF43 are reserved for extension) Bulk inelastic: AF41 (AF42 and AF43 are reserved for extension)
Assured: AF31, AF32 and AF33 Assured: AF31, AF32 and AF33
Default: Default (i.e. Best Effort) Default: Default (i.e. Best Effort)
Class names (and property specification) have been picked from Y.1566 Class names (and property specification) have been picked from Y.1566
above. above.
A provider may prefer to operate an internal PHB for the routing and 6. Treatment of Network Control traffic at carrier interconnection
management traffic of own systems. The PHB may not be available for interfaces
traffic of peers or customers classified for the same HB within their
networks. By default, many routers mark this traffic by CS6.
Several scenarios are possible:
o CS6 marked traffic originating within a domain should be mapped to As specified by RFC4594, section 3.2, Network Control (NC) traffic
a suitable PHB at interconnection interfaces, if the receiving marked by CS6 is to be expected at interconnection interfaces. This
provider isn't offering transport with CS6. AF31 is recommended document does not change NC specifications of RFC4594. The latter
to that purpose. specification is detailed on domain internal NC traffic and on
traffic exchanged between peering points. Further, it recommends not
to forward CS6 marked traffic originating from user-controlled end
points by the NC class of a provider domain.
o BGP traffic terminating in the adjacent AS border router could As a minor clarification to RFC4594, "peering" shouldn't be
carry any codepoint whose traffic is not dropped by the receiving interpreted in a commercial sense. The NC PHB is applicable also in
AS border router. the case of a purchased network service based on a transit agreement
with an upstream provider. RFC4594 recommendations on NC traffic are
applicable for IP carrier interconnections in general.
o An AS border router may not be able to mark BGP traffic by any Some CS6 traffic exchanged accross carrier interconnections will
different DSCP than CS6 and this traffic might be destined to a terminate at the domain ingress node (e.g., if BGP is running between
distant BGP peer, like a routing arbiter. In that case, the the two routers on opposite ends of the interconnection link).
interconnecting parties should negotiate the treatment of this
traffic. Standard DiffServ remarking, picking e.g. AF31 or Best
Effort are possible options.
Operating a provider internal network management and routing class is An IP carrier MAY limit access to the NC PHB for traffic which is
an option only. Providers may of course bilaterally agree to recognised as network control traffic relevant to the own domain.
exchange CS6 marked traffic without changing the DSCP. Interconnecting carriers SHOULD specify treatment of CS6 marked
traffic received at a carrier interconnection which is to be
forwarded beyond the ingress node. An SLA covering the following
cases is recommended, if a carrier wishes to send CS6 marked traffic
accross an interconnection link which isn't terminating at the
interconnected ingress node:
Maintaining a separate PHB for network management, routing or o classification of traffic which is network control traffic for
signaling traffic also for traffic transiting through or terminating both domains. This traffic SHOULD be classified for the NC PHB.
in a remote AS may be desirable. AF31 is recommended to that
purpose. This is simple in the case of VPNs or point to point
services. If this traffic is multiplexed with arbitrary traffic
using this DSCP based PHB, distinction by the codepoint only isn't
possible any more. Hence a standard agreement would best solve the
issue. This document recommends picking an Assured class DSCP based
PHB, AF31.
5. MPLS, Ethernet and Class Selector Codepoints for aggregated classes o classification of traffic which is network control traffic for the
sending domain only. This traffic SHOULD be classified for a PHB
offering similar properties as the NC class (e.g. AF31 as
specified by this document).
o any other CS6 marked traffic SHOULD be remarked or dropped.
7. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes
Ethernet and MPLS support 3 bit codepoint fields to differentiate Ethernet and MPLS support 3 bit codepoint fields to differentiate
service quality. Mapping of the Class Selector Codepoints to these 3 service quality. Mapping of the DSCP Precedence Prefix to these 3
Bit fields has been a configuration restriction in the early days of Bit fields has been a configuration restriction in the early days of
DiffServ. The concept of classifying DiffServ traffic classes by the DiffServ. The concept of classifying DiffServ traffic classes by the
bits 0-2 of a DSCP has however been part of Diffserv from start on. bits 0-2 of a DSCP has however been part of Diffserv from start on.
EF's Class Selector Codepoints is 5, that of AF4 is 4 and so on. The EF's DSCP Precedence Prefix is 5, that of AF4 is 4 and so on. The
interconnection class and codepoint scheme respects properties and interconnection class and codepoint scheme respects properties and
limits of a 3 bit PHB coding space in different ways: limits of a 3 bit PHB coding space in different ways:
o it allows to classify four interconnection classes based on Class o it allows to classify four interconnection classes based on Class
Selector Codepoints. Selector Codepoints.
o it supports a single PHB group (AF3), whose DSCP based PHBs may be o it supports a single PHB group (AF3), whose DSCP based PHBs may be
mapped to up to three different MPLS TC's or Ethernet P-Bits. mapped to up to three different MPLS TC's or Ethernet P-Bits.
Note that this draft doesn's favour or recommend doing that, but Note that this draft doesn's favour or recommend doing that, but
it is possible. The author isn't aware of deployed service offers it is possible. The author isn't aware of deployed service offers
with 3 different drop levels in a single class. with 3 different drop levels in a single class.
The above statement is no requirement to depricate any DSCP to MPLS The above statement is no requirement to depricate any DSCP to MPLS
TC or Ethernet P-Bit mapping functionality. In the opposite, by TC or Ethernet P-Bit mapping functionality. In the opposite, by
limiting the interconnection scheme to 7 DSCP based PHBs, each PHB limiting the interconnection scheme to 7 DSCP based PHBs, each PHB
may be mapped to a 3 Bit based PHB scheme. may be mapped to a 3 Bit based PHB scheme.
6. QoS class name selection 8. QoS class name selection
This is more of an informational discussion, proposed best practice, This is more of an informational discussion, proposed best practice,
and mainly relates to human behaviour (including QoS experts) rather and mainly relates to human behaviour (including QoS experts) rather
than technical issues. Above the human preference for conceivable than technical issues. Above the human preference for conceivable
class names has been mentioned. Network engineers (including the class names has been mentioned. Network engineers (including the
former Diffserv WG authors) recommend avoiding application related former Diffserv WG authors) recommend avoiding application related
QoS class names. Focus should be put on class properties. These can QoS class names. Focus should be put on class properties. These can
be irritating again. Just looking at SLA parameters like Delay, be irritating again. Just looking at SLA parameters like Delay,
Jitter and packet loss doesn't tell the reader, which transport Jitter and packet loss doesn't tell the reader, which transport
properties guided the related scheduler engineering of a PHB. A properties guided the related scheduler engineering of a PHB. A
skipping to change at page 11, line 17 skipping to change at page 12, line 5
traffic, for which the EF engineering assumptions may not fit. So traffic, for which the EF engineering assumptions may not fit. So
support of a PHB like bulk inelastic is reasonable. support of a PHB like bulk inelastic is reasonable.
Active queue management may be deployed for QoS classes designed to Active queue management may be deployed for QoS classes designed to
transport traffic responding to congestion by traffic reduction. transport traffic responding to congestion by traffic reduction.
The class names of this document follow Y.1566. TCP_optimised and The class names of this document follow Y.1566. TCP_optimised and
especially UDP_optimised are inappropriate class names, as some UDP especially UDP_optimised are inappropriate class names, as some UDP
based applications are or may be expected to become TCP friendly. based applications are or may be expected to become TCP friendly.
7. Allow for DiffServ extendibility on MPLS and Ethernet level 9. Allow for DiffServ extendibility on MPLS and Ethernet level
Any aggregated Diffserv deployment faces codepoint depletion issues Any aggregated Diffserv deployment faces codepoint depletion issues
rather soon, if deployed on MPLS or Ethernet. Coding space should be rather soon, if deployed on MPLS or Ethernet. Coding space should be
left for new features, like ECN, PCN or Conex. In addition to left for new features, like ECN, PCN or Conex. In addition to
carrying customer traffic, internal routing and network management carrying customer traffic, internal routing and network management
traffic may be protected by using a separate class. Offering traffic may be protected by using a separate class. Offering
interconnection with up to four classes and 4 - 6 MPLS TC's (or interconnection with up to four classes and 4 - 6 MPLS TC's (or
Ethernet P-bits) to that respect is probably at least a fair Ethernet P-bits) to that respect is probably at least a fair
compromise. compromise.
8. Acknowledgements 10. Acknowledgements
David Black gave many helpful comments to this work. Al Morton and David Black gave many helpful comments to this work. Al Morton and
Sebastien Jobert provided feedback on many aspects during private Sebastien Jobert provided feedback on many aspects during private
discussions. Brian Carpenter, Mohamed Boucadair and Thomas Knoll discussions. Brian Carpenter, Mohamed Boucadair and Thomas Knoll
helped adding awareness of further potentially related work. helped adding awareness of further potentially related work.
9. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 12. Security Considerations
This document does not introduce new features, it describes how to This document does not introduce new features, it describes how to
use existing ones. The security section of RFC 4597 [RFC4597] use existing ones. The security section of RFC 4597 [RFC4597]
applies. applies.
11. References 13. References
11.1. Normative References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
skipping to change at page 12, line 40 skipping to change at page 13, line 27
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006. [min_ref] authSurName, authInitials., "Minimal Reference", 2006.
11.2. Informative References 13.2. Informative References
[I-D.knoll-idr-cos-interconnect] [I-D.knoll-idr-cos-interconnect]
Knoll, T., "BGP Class of Service Interconnection", Knoll, T., "BGP Class of Service Interconnection",
draft-knoll-idr-cos-interconnect-10 (work in progress), draft-knoll-idr-cos-interconnect-10 (work in progress),
May 2013. May 2013.
[I-D.polk-tsvwg-diffserv-stds-problem-statement] [I-D.polk-tsvwg-diffserv-stds-problem-statement]
Polk, J., "The Problem Statement for the Standard Polk, J., "The Problem Statement for the Standard
Configuration of DiffServ Service Classes", Configuration of DiffServ Service Classes",
draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work
skipping to change at page 14, line 8 skipping to change at page 14, line 38
00 to 01 Added terminology and references. Added details and 00 to 01 Added terminology and references. Added details and
information to interconnection class and codepoint scheme. information to interconnection class and codepoint scheme.
Editorial changes. Editorial changes.
01 to 02 Added some references regarding related work. Clarified 01 to 02 Added some references regarding related work. Clarified
class definitions. Further editorial improvements. class definitions. Further editorial improvements.
02 to 03 Consistent terminology. Discussion of Network Management 02 to 03 Consistent terminology. Discussion of Network Management
PHB at interconnection interfaces. Editorial review. PHB at interconnection interfaces. Editorial review.
03 to 04 Again improved terminology. Better wording of Network
Control PHB at interconnection interfaces.
Author's Address Author's Address
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt, 64295 Darmstadt, 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
 End of changes. 35 change blocks. 
92 lines changed or deleted 137 lines changed or added

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