As per Relevance of the word clarification, we have this rfc below:
Network Working Group D.
Request for Comments: 3260 Motorola, Inc
Updates: 2474, 2475, 2597 April 2002
Category:
New Terminology and Clarifications for
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This memo captures Diffserv working group agreements concerning
and improved terminology, and provides minor
clarifications. It is intended to update RFC 2474, RFC 2475 and
2597. When RFCs 2474 and 2597 advance on the standards track,
RFC 2475 is updated, it is intended that the revisions in this
will be incorporated, and that this memo will be obsoleted by the
RFCs
1.
As the Diffserv work has evolved, there have been several cases
terminology has needed to be created or the definitions in
standards track RFCs have needed to be refined. Some minor
clarifications were also found to be needed. This memo was
to capture group agreements, rather than attempting to revise
base RFCs and recycle them at proposed standard. It updates in
RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been obsoleted by
3246, and clarifications agreed by the group were incorporated
that revision
2. Terminology Related to Service Level Agreements (SLAs
The Diffserv Architecture [2] uses the term "Service Level Agreement
(SLA) to describe the "service contract... that specifies
forwarding service a customer should receive". The SLA may
traffic conditioning rules which (at least in part) constitute
Traffic Conditioning Agreement (TCA). A TCA is "an
Grossman Informational [Page 1]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
specifying classifier rules and any corresponding traffic
and metering, marking, discarding and/or shaping rules which are
apply...."
As work progressed in Diffserv (as well as in the Policy WG [6]),
came to be believed that the notion of an "agreement"
considerations that were of a pricing, contractual or other
nature, as well as those that were strictly technical. There
could be other technical considerations in such an agreement (e.g.,
service availability) which are not addressed by Diffserv. It
therefore agreed that the notions of SLAs and TCAs would be taken
represent the broader context, and that new terminology would be
to describe those elements of service and traffic conditioning
are addressed by Diffserv
- A Service Level Specification (SLS) is a set of parameters
their values which together define the service offered to
traffic stream by a DS domain
- A Traffic Conditioning Specification (TCS) is a set
parameters and their values which together specify a set
classifier rules and a traffic profile. A TCS is an
element of an SLS
Note that the definition of "Traffic stream" is unchanged from
2475. A traffic stream can be an individual microflow or a group
microflows (i.e., in a source or destination DS domain) or it can
a BA. Thus, an SLS may apply in the source or destination DS
to a single microflow or group of microflows, as well as to a BA
any DS domain
Also note that the definition of a "Service Provisioning Policy"
unchanged from RFC 2475. RFC 2475 defines a "Service
Policy as "a policy which defines how traffic conditioners
configured on DS boundary nodes and how traffic streams are mapped
DS behavior aggregates to achieve a range of services." According
one definition given in RFC 3198 [6], a policy is "...a set of
to administer, manage, and control access to network resources".
Therefore, the relationship between an SLS and a service
policy is that the latter is, in part, the set of rules that
the parameters and range of values that may be in the former
Further note that this definition is more restrictive than that
RFC 3198.
Grossman Informational [Page 2]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
3. Usage of PHB
RFC 2475 defines a Per-hop behavior (PHB) group to be
"a set of one or more PHBs that can only be meaningfully
and implemented simultaneously, due to a common
applying to all PHBs in the set such as a queue servicing or
management policy. A PHB group provides a service building
that allows a set of related forwarding behaviors to be
together (e.g., four dropping priorities). A single PHB is
special case of a PHB group."
One standards track PHB Group is defined in RFC 2597 [3], "
Forwarding PHB Group". Assured Forwarding (AF) is a type
forwarding behavior with some assigned level of queuing resources
three drop precedences. An AF PHB Group consists of three PHBs,
uses three Diffserv Codepoints (DSCPs).
RFC 2597 defines twelve DSCPs, corresponding to four independent
classes. The AF classes are referred to as AF1x, AF2x, AF3x,
AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each
class is one instance of an AF PHB Group
There has been confusion expressed that RFC 2597 refers to all
AF classes with their three drop precedences as being part of
single PHB Group. However, since each AF class operates
independently of the others, (and thus there is no common
among AF classes as there is among drop precedences within an
class) this usage is inconsistent with RFC 2475. The
exists for historical reasons and will be removed in future
of the AF specification. It should now be understood that AF is
_type_ of PHB group, and each AF class is an _instance_ of the
type
Authors of new PHB specifications should be careful to adhere to
RFC 2475 definition of PHB Group. RFC 2475 does not prohibit new
specifications from assigning enough DSCPs to represent
independent instances of their PHB Group. However, such a set
DSCPs must not be referred to as a single PHB Group
4. Definition of the DS
Diffserv uses six bits of the IPV4 or IPV6 header to convey
Diffserv Codepoint (DSCP), which selects a PHB. RFC 2474 attempts
rename the TOS octet of the IPV4 header, and Traffic Class octet
the IPV6 header, respectively, to the DS field. The DS Field has
six bit Diffserv Codepoint and two "currently unused" bits
Grossman Informational [Page 3]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
It has been pointed out that this leads to inconsistencies
ambiguities. In particular, the "Currently Unused" (CU) bits of
DS Field have not been assigned to Diffserv, and subsequent to
publication of RFC 2474, they were assigned for explicit
notification, as defined in RFC 3168 [4]. In the current text,
DSCP is, depending on context, either an encoding which selects a
or a sub-field in the DS field which contains that encoding
The present text is also inconsistent with BCP 37, IANA
Guidelines for Values in the Internet Protocol and Related
[5]. The IPV4 Type-of-Service (TOS) field and the IPV6 traffic
field are superseded by the 6 bit DS field and a 2 bit CU field.
IANA allocates values in the DS field following the
considerations section in RFC 2474, as clarified in section 8 of
memo
The consensus of the DiffServ working group is that BCP 37
restates the structure of the former TOS and traffic class fields
Therefore, for use in future documents, including the next update
RFC 2474, the following definitions should apply
- the Differentiated Services Field (DSField) is the six
significant bits of the (former) IPV4 TOS octet or the (former
IPV6 Traffic Class octet
- the Differentiated Services Codepoint (DSCP) is a value
is encoded in the DS field, and which each DS Node MUST use
select the PHB which is to be experienced by each packet
forwards
The two least significant bits of the IPV4 TOS octet and the IPV
Traffic Class octet are not used by Diffserv
When RFC 2474 is updated, consideration should be given to
the designation "currently unused (CU)" to "explicit
notification (ECN)" and referencing RFC 3168 (or its successor).
The update should also reference BCP 37.
5. Ordered Aggregates and PHB Scheduling
Work on Diffserv support by MPLS Label Switched Routers (LSRs) led
the realization that a concept was needed in Diffserv to capture
notion of a set of BAs with a common ordering constraint.
presently applies to AF behavior aggregates, since a DS node may
reorder packets of the same microflow if they belong to the same
class. This would, for example, prevent an MPLS LSR, which was
Grossman Informational [Page 4]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
a DS node, from discriminating between packets of an AF
Aggregate (BA) based on drop precedence and forwarding packets of
same AF class but different drop precedence over different LSPs.
following new terms are defined
PHB Scheduling Class: A PHB group for which a common constraint
that, ordering of at least those packets belonging to the
microflow must be preserved
Ordered Aggregate (OA): A set of Behavior Aggregates that share
ordering constraint. The set of PHBs that are applied to this
of Behavior Aggregates constitutes a PHB scheduling class
6. Unknown/Improperly Mapped
Several implementors have pointed out ambiguities or conflicts in
Diffserv RFCs concerning behavior when a DS-node receives a
with a DSCP which it does not understand
RFC 2475 states
"Ingress nodes must condition all other inbound traffic to
that the DS codepoints are acceptable; packets found to
unacceptable codepoints must either be discarded or must
their DS codepoints modified to acceptable values before
forwarded. For example, an ingress node receiving traffic from
domain with which no enhanced service agreement exists may
the DS codepoint to the Default PHB codepoint [DSFIELD]."
On the other hand, RFC 2474 states
"Packets received with an unrecognized codepoint SHOULD
forwarded as if they were marked for the Default behavior (
Sec. 4), and their codepoints should not be changed."
RFC 2474 is principally concerned with DS-interior nodes. However
this behavior could also be performed in DS-ingress nodes AFTER
traffic conditioning required by RFC 2475 (in which case,
unrecognized DSCP would occur only in the case of misconfiguration).
If a packet arrives with a DSCP that hadn't been explicitly mapped
a particular PHB, it should be treated the same way as a
marked for Default. The alternatives were to assign it another PHB
which could result in misallocation of provisioned resources, or
drop it. Those are the only alternatives within the framework of
2474. Neither alternative was considered desirable. There has
discussion of a PHB which receives worse service than the default
this might be a better alternative. Hence the imperative
"SHOULD" rather than "SHALL".
Grossman Informational [Page 5]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
The intent of RFC 2475 clearly concerns DS-ingress nodes, or
precisely, the ingress traffic conditioning function. This
another context where the "SHOULD" in RFC 2474 provides
flexibility to do what the group intended. Such tortured
are not desirable
Therefore, the statement in RFC 2474 will be clarified to
that it is not intended to apply at the ingress traffic
function at a DS-ingress node, and cross reference RFC 2475 for
case
There was a similar issue, which manifested itself with the
incarnation of Expedited Forwarding (EF). RFC 2598 states
To protect itself against denial of service attacks, the edge of
DS domain MUST strictly police all EF marked packets to a
negotiated with the adjacent upstream domain. (This rate must
<= the EF PHB configured rate.) Packets in excess of
negotiated rate MUST be dropped. If two adjacent domains have
negotiated an EF rate, the downstream domain MUST use 0 as
rate (i.e., drop all EF marked packets).
The problem arose in the case of misconfiguration or
problems. An egress DS-node at the edge of one DS-domain
packets to an ingress DS-node at the edge of another DS domain
These packets are marked with a DSCP that the egress node
to map to EF, but which the ingress node does not recognize.
statement in RFC 2475 would appear to apply to this case. RFC 3246
[7] clarifies this point
7. No Backward Compatibility With RFC 1349
At least one implementor has expressed confusion about
relationship of the DSField, as defined in RFC 2474, to the use
the TOS bits, as described in RFC 1349. The RFC 1349 usage
intended to interact with OSPF extensions in RFC 1247. These
never widely deployed and thus removed by standards action when
54, RFC 2328, was published. The processing of the TOS bits
described as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123
[10]. RFC 2474 states
"No attempt is made to maintain backwards compatibility with
"DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].",
Grossman Informational [Page 6]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
In addition, RFC 2474 obsoletes RFC 1349 by IESG action.
completeness, when RFC 2474 is updated, the sentence should read
"No attempt is made to maintain backwards compatibility with
"DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined
[RFC791] and [RFC1349]. This implies that TOS bit processing
described in [RFC1812], [RFC1122] and [RFC1123] is also
by this memo. Also see [RFC2780]."
8. IANA
IANA has requested clarification of a point in RFC 2474,
registration of experimental/local use DSCPs. When RFC 2474
revised, the following should be added to Section 6:
IANA is requested to maintain a registry of RECOMMENDED
values assigned by standards action. EXP/LU values are not to
registered
9. Summary of Pending
The following standards track and informational RFCs are expected
be updated to reflect the agreements captured in this memo. It
intended that these updates occur when each standards track
progresses to Draft Standard (or if some issue arises that
recycling at Proposed). RFC 2475 is expected to be updated at
the same time as RFC 2474. Those updates will also obsolete
memo
RFC 2474: revise definition of DS field. Clarify that
suggested default forwarding in the event of an unrecognized
is not intended to apply to ingress conditioning in DS-
nodes. Clarify effects on RFC 1349 and RFC 1812. Clarify
only RECOMMENDED DSCPs assigned by standards action are to
registered by IANA
RFC 2475: revise definition of DS field. Add SLS and
definitions. Update body of document to use SLS and
appropriately. Add definitions of PHB scheduling class
ordered aggregate
RFC 2497: revise to reflect understanding that, AF classes
instances of the AF PHB group, and are not collectively a
group
Grossman Informational [Page 7]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
In addition, RFC 3246 [7] has added a reference to RFC 2475 in
security considerations section to cover the case of a DS egress
receiving an unrecognized DSCP which maps to EF in the DS
node
10. Security
Security considerations are addressed in RFC 2475.
This memo captures agreements of the Diffserv working group.
individuals contributed to the discussions on the Diffserv list
in the meetings. The Diffserv chairs were Brian Carpenter and
Nichols. Among many who participated actively in these
were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim
Sharam Davari, David Black, Gerard Gastaud, Joel Halpern,
Schnizlein, Francois Le Faucheur, and Fred Baker. Mike Ayers,
Heard and Andrea Westerinen provided valuable editorial comments
Normative
[1] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
the Differentiated Services Field (DS Field) in the IPv4
IPv6 Headers", RFC 2474, December 1998.
[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, "
Forwarding PHB Group", RFC 2597, June 1999.
[4] Ramakrishnan, K., Floyd, S. and D. Black "The Addition
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[5] Bradner, S. and V. Paxon, "IANA Allocation Guidelines for
in the Internet Protocol and Related Headers", BCP 37, RFC2780,
March 2000.
[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S
Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
November 2001.
Grossman Informational [Page 8]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
[7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K.,
Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V.,
Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An
Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[9] Braden, R., "Requirements for Internet Hosts --
Layers", STD 3, RFC 1122, October 1989.
[10] Braden, R., "Requirements for Internet Hosts -- Application
Support", STD 3, RFC 1123, October 1989.
Author's
Dan
Motorola, Inc
20 Cabot Blvd
Mansfield, MA 02048
EMail: dan@dma.isg.mot.
Grossman Informational [Page 9]
RFC 3260 New Terminology and Clarifications for Diffserv April 2002
Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Grossman Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
