draft-ietf-diffserv-new-terms-03.txt   draft-ietf-diffserv-new-terms-04.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
Expires: September 2001
August, 2000 draft-ietf-diffserv-new-terms-04.txt
March, 2001
New Terminology for Diffserv New Terminology for Diffserv
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC2026. Internet-Drafts are working all provisions of section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
1. Introduction 1. Introduction
As the Diffserv work has evolved, there have been several cases where As the Diffserv work has evolved, there have been several cases where
terminology has needed to be created or the definitions in Diffserv terminology has needed to be created or the definitions in Diffserv
standards track RFCs have needed to be refined. This memo was standards track RFCs have needed to be refined. This memo was
created to capture and test group agreements on terminology, rather created to capture and test group agreements on terminology, rather
than attempting to revise the base RFCs and recycle them at proposed than attempting to revise the base RFCs and recycle them at proposed
standard. Diffserv authors are encouraged to use the new terminology standard. Diffserv authors are encouraged to use the new terminology
whereever appropriate. whereever appropriate.
2. Terminology related to Service Level Agreements (SLAs) 2. Terminology Related to Service Level Agreements (SLAs)
The Diffserv Architecture [2] uses the term "Service Level Agreement" The Diffserv Architecture [2] uses the term "Service Level Agreement"
(SLA) to describe the "service contract... that specifies the (SLA) to describe the "service contract... that specifies the
forwarding service a customer should receive". The SLA may include forwarding service a customer should receive". The SLA may include
traffic conditioning rules which (at least in part) constitute a traffic conditioning rules which (at least in part) constitute a
Traffic Conditioning Agreement (TCA). A TCA is "an agreement Traffic Conditioning Agreement (TCA). A TCA is "an agreement
specifying classifier rules and any corresponding traffic profiles specifying classifier rules and any corresponding traffic profiles
and metering, marking, discarding and/or shaping rules which are to and metering, marking, discarding and/or shaping rules which are to
apply...." apply...."
skipping to change at page 2, line 32 skipping to change at page 2, line 32
notion of an "agreement" implied considerations that were of a notion of an "agreement" implied considerations that were of a
pricing, contractual or other business nature, as well as those that pricing, contractual or other business nature, as well as those that
were strictly technical. There also could be other technical were strictly technical. There also could be other technical
considerations in such an agreement (e.g., service availability) considerations in such an agreement (e.g., service availability)
which are not addressed by Diffserv. It was therefore agreed that which are not addressed by Diffserv. It was therefore agreed that
the notions of SLAs and TCAs would be taken to represent the broader the notions of SLAs and TCAs would be taken to represent the broader
context, and that new terminology would be used to describe those context, and that new terminology would be used to describe those
elements of service and traffic conditioning that are addressed by elements of service and traffic conditioning that are addressed by
Diffserv. Diffserv.
- A Service Level Specfication (SLS) is a set of parameters and - A Service Level Specification (SLS) is a set of parameters and
their values which together define the service offered to a traffic their values which together define the service offered to a traffic
stream by a DS domain. stream by a DS domain.
- A Traffic Conditioning Specification (TCS) is a set of parameters - A Traffic Conditioning Specification (TCS) is a set of parameters
and their values which together specify a set of classfier rules and their values which together specify a set of classfier rules
and a traffic profile. A TCS is an integral element of an SLS. and a traffic profile. A TCS is an integral element of an SLS.
Note that the definition of "Traffic stream" is unchanged from RFC Note that the definition of "Traffic stream" is unchanged from RFC
2475. A traffic stream can be an individual microflow or a group of 2475. A traffic stream can be an individual microflow or a group of
microflows (i.e., in a source or destination DS domain) or it can microflows (i.e., in a source or destination DS domain) or it can
be a BA. Thus, an SLS may apply in the source or destination DS be a BA. Thus, an SLS may apply in the source or destination DS
domain to a single microflow or group of microflows, as well as to a domain to a single microflow or group of microflows, as well as to a
BA in any DS domain. BA in any DS domain.
3. Usage of PHB Group 3. Usage of PHB Group
RFC 2475 defines a PHB group to be: RFC 2475 defines a Per-hop behavior (PHB) group to be:
"a set of one or more PHBs that can only be meaningfully specified "a set of one or more PHBs that can only be meaningfully specified
and implemented simultaneously, due to a common constraint applying and implemented simultaneously, due to a common constraint applying
to all PHBs in the set such as a queue servicing or queue to all PHBs in the set such as a queue servicing or queue
management policy. A PHB group provides a service building block management policy. A PHB group provides a service building block
that allows a set of related forwarding behaviors to be specified that allows a set of related forwarding behaviors to be specified
together (e.g., four dropping priorities). A single PHB is a together (e.g., four dropping priorities). A single PHB is a
special case of a PHB group." special case of a PHB group."
One standards track PHB Group is defined in RFC 2497 [3], "Assured One standards track PHB Group is defined in RFC 2597 [3], "Assured
Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding
behavior with some assigned level of queuing resources and three drop behavior with some assigned level of queuing resources and three drop
precedences. An AF PHB Group consists of three PHBs, and uses three precedences. An AF PHB Group consists of three PHBs, and uses three
DSCPs. Diffserv Codepoints (DSCPs).
RFC 2497 defines twelve DSCPs, corresponding to four independent AF RFC 2597 defines twelve DSCPs, corresponding to four independent AF
classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x
(where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class
is one instance of an AF PHB Group. is one instance of an AF PHB Group.
There has been confusion expressed that RFC 2497 refers to all four AF There has been confusion expressed that RFC 2597 refers to all four AF
classes with their three drop precedences as being part of a single PHB classes with their three drop precedences as being part of a single PHB
Group. However, since each AF class operates entirely independently of Group. However, since each AF class operates entirely independently of
the others, (and thus there is no common constraint among AF classes as the others, (and thus there is no common constraint among AF classes as
there is among drop precedences within an AF class) this usage is there is among drop precedences within an AF class) this usage is
inconsistent with RFC 2475. The inconsistency exists for historical inconsistent with RFC 2475. The inconsistency exists for historical
reasons and will be removed in future revisions of the AF specification. reasons and will be removed in future revisions of the AF specification.
It should now be understood that AF is a _type_ of PHB group, and each It should now be understood that AF is a _type_ of PHB group, and each
AF class is an _instance_ of the AF type. AF class is an _instance_ of the AF type.
Authors of new PHB specifications should be careful to adhere to the RFC Authors of new PHB specifications should be careful to adhere to the RFC
skipping to change at page 3, line 47 skipping to change at page 3, line 47
4. Definition of the DS Field 4. Definition of the DS Field
Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv
Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the
TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 TOS octet of the IPV4 header, and Traffic Class octet of the IPV6
header, respectively, to the DS field. The DS Field has a six bit header, respectively, to the DS field. The DS Field has a six bit
Diffserv Codepoint and two "currently unused bits". Diffserv Codepoint and two "currently unused bits".
It has been pointed out that this leads to inconsistencies and It has been pointed out that this leads to inconsistencies and
ambiguities. In particular, the CU bits of the DS Field have not been ambiguities. In particular, the "Currently Unused" (CU) bits of the DS
assigned to Diffserv, and have been assigned an experimental use for an Field have not been assigned to Diffserv, and have been assigned an
explicit congestion notification scheme [4]. In the current text, a experimental use for an explicit congestion notification scheme [4].
DSCP is, depending on context, either an encoding which selects a PHB or In the current text, a DSCP is, depending on context, either an encoding
a sub-field in the DS field which contains that encoding. which selects a PHB or a sub-field in the DS field which contains that
encoding.
The present text is also inconsistent with the IANA allocation The present text is also inconsistent with the IANA allocation
guidelines draft [5]. In that draft, the IPV4 TOS field and the IPV6 guidelines [5]. The IPV4 Type-of-Service (TOS) field and the IPV6
traffic class field are superceded by the 6 bit DS field and a 2 bit CU traffic class field are superceded by the 6 bit DS field and a 2 bit CU
field. The IANA allocates values in the DS field following the IANA field. The IANA allocates values in the DS field following the IANA
considerations section in RFC 2474. Experimental uses of the CU field considerations section in RFC 2474. Experimental uses of the CU field
are assigned after IESG approval processes. Permanent values in the CU are assigned after IESG approval processes. Permanent values in the CU
field are allocated following a Standards Action process. field are allocated following a Standards Action process.
The consensus of the DiffServ working group is that [5] correctly The consensus of the DiffServ working group is that [5] correctly
restates the structure of the former TOS and traffic class fields. restates the structure of the former TOS and traffic class fields.
Therefore, for use in future drafts, including the next update to RFC Therefore, for use in future drafts, including the next update to RFC
skipping to change at page 4, line 32 skipping to change at page 4, line 34
- the Differentiated Services Codepoint (DSCP) is a value which is - the Differentiated Services Codepoint (DSCP) is a value which is
encoded in the DS field, and which each DS Node MUST use to select encoded in the DS field, and which each DS Node MUST use to select
the PHB which is to be experienced by each packet it forwards. the PHB which is to be experienced by each packet it forwards.
The two least significant bits of the IPV4 TOS octet and the IPV6 The two least significant bits of the IPV4 TOS octet and the IPV6
Traffic Class octet are not presently used by Diffserv. Traffic Class octet are not presently used by Diffserv.
The update should also reference the IANA Allocation Guidelines, The update should also reference the IANA Allocation Guidelines,
assuming that they are published as an RFC. assuming that they are published as an RFC.
5. Ordered aggregates and PHB scheduling classes 5. Ordered Aggregates and PHB Scheduling Classes
Work on Diffserv support by MPLS LSRs led to the realization that a Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to
concept was needed in Diffserv to capture the notion of a set of BAs the realization that a concept was needed in Diffserv to capture the
with a common ordering constraint. This presently applies to AF notion of a set of BAs with a common ordering constraint. This
behavior aggregates, since a DS node may not reorder packets of the presently applies to AF behavior aggregates, since a DS node may not
same microflow if they belong to the same AF class. This would, for reorder packets of the same microflow if they belong to the same AF
example, prevent an MPLS LSR which was also a DS node from class. This would, for example, prevent an MPLS LSR which was also a
discriminating between packets of an AF BA based on drop precedence DS node from discriminating between packets of an AF Behavior
and forwarding packets of the same AF class but different drop Agrregeate (BA) based on drop precedence and forwarding packets of
precedence over different LSPs. The following new terms are defined. the same AF class but different drop precedence over different LSPs.
The following new terms are defined.
PHB Scheduling Class: A PHB group for which a common constraint is PHB Scheduling Class: A PHB group for which a common constraint is
that ordering of at least those packets belonging to the same that ordering of at least those packets belonging to the same
microflow must be preserved. microflow must be preserved.
Ordered Aggregate (OA): A set of Behavior Aggregates that share an Ordered Aggregate (OA): A set of Behavior Aggregates that share an
ordering constraint. The set of PHBs that are applied to this set ordering constraint. The set of PHBs that are applied to this set
of Behavior Aggregates constitutes a PHB scheduling class. of Behavior Aggregates constitutes a PHB scheduling class.
6. Unknown/improperly mapped DSCPs Several implementors have pointed out 6. Unknown/Improperly Mapped DSCPs
ambiguities or conflicts in the Diffserv RFCs concerning behavior
when a DS-node recieves a packet with a DSCP which it does not Several implementors have pointed out ambiguities or conflicts in the
understand. Diffserv RFCs concerning behavior when a DS-node recieves a packet
with a DSCP which it does not understand.
RFC 2475 states: RFC 2475 states:
"Ingress nodes must condition all other inbound traffic to ensure "Ingress nodes must condition all other inbound traffic to ensure
that the DS codepoints are acceptable; packets found to have that the DS codepoints are acceptable; packets found to have
unacceptable codepoints must either be discarded or must have their unacceptable codepoints must either be discarded or must have their
DS codepoints modified to acceptable values before being forwarded. DS codepoints modified to acceptable values before being forwarded.
For example, an ingress node receiving traffic from a domain with For example, an ingress node receiving traffic from a domain with
which no enhanced service agreement exists may reset the DS which no enhanced service agreement exists may reset the DS
codepoint to the Default PHB codepoint [DSFIELD]." codepoint to the Default PHB codepoint [DSFIELD]."
On the other hand, RFC 2474 states: On the other hand, RFC 2474 states:
"Packets received with an unrecognized codepoint SHOULD be "Packets received with an unrecognized codepoint SHOULD be
forwarded as if they were marked for the Default behavior (see Sec. forwarded as if they were marked for the Default behavior (see Sec.
4), and their codepoints should not be changed." 4), and their codepoints should not be changed."
The intent in RFC 2474 principally concerned DS-interior nodes. The intent in RFC 2474 principally concerned DS-interior nodes.
However, this behavior could also be performed in DS-ingress nodes However, this behavior could also be performed in DS-ingress nodes
AFTER the traffic conditioning required by RFC 2475 (in which case, AFTER the traffic conditioning required by RFC 2475 (in which case,
an unrecognized DSCP would occur only in the case of an unrecognized DSCP would occur only in the case of
misconfiguration). If a packet showed up with a DSCP that hadn't misconfiguration). If a packet arrives with a DSCP that hadn't been
been explicitly mapped to any particular PHB, it should get treated explicitly mapped to a particular PHB, it should be treated the same
the same way as a packet marked for Default. The alternatives were to way as a packet marked for Default. The alternatives were to assign
assign it another PHB, which could result in misallocation of it another PHB, which could result in misallocation of provisioned
provisioned resources, or to drop it. Those are the only resources, or to drop it. Those are the only alternatives within the
alternatives within the framework of 2474. Neither alternative was framework of 2474. Neither alternative was considered desirable.
considered desirable. There has been discussion of a PHB which There has been discussion of a PHB which receives worse service than
receives worse service than the default; this might be a better the default; this might be a better alternative. Hence the
alternative. Hence the imperitive was"SHOULD" rather than "SHALL". imperitive was"SHOULD" rather than "SHALL".
The intent in RFC 2475 is clearly concerns DS-ingress nodes, or to be The intent in RFC 2475 clearly concerns DS-ingress nodes, or to be
more precise, the ingress traffic conditioning function. This is more precise, the ingress traffic conditioning function. This is
another context where the "SHOULD" in RFC 2474 gives the flexibility another context where the "SHOULD" in RFC 2474 gives the flexibility
to do what the group intended. Such tortured readings are not to do what the group intended. Such tortured readings are not
desirable. desirable.
Therefore, the statement in RFC 2474 will be clarified to indicate Therefore, the statement in RFC 2474 will be clarified to indicate
that it is not intended to apply at the ingress traffic conditioning that it is not intended to apply at the ingress traffic conditioning
function at a DS-ingress node, and cross reference RFC 2475 for that function at a DS-ingress node, and cross reference RFC 2475 for that
case. case.
There is a similar issue, which manifests itself with EF. RFC 2598 There is a similar issue, which manifests itself with Expedited
states: Forwarding (EF). RFC 2598 states:
To protect itself against denial of service attacks, the edge of a To protect itself against denial of service attacks, the edge of a
DS domain MUST strictly police all EF marked packets to a rate DS domain MUST strictly police all EF marked packets to a rate
negotiated with the adjacent upstream domain. (This rate must be negotiated with the adjacent upstream domain. (This rate must be
<= the EF PHB configured rate.) Packets in excess of the <= the EF PHB configured rate.) Packets in excess of the
negotiated rate MUST be dropped. If two adjacent domains have not negotiated rate MUST be dropped. If two adjacent domains have not
negotiated an EF rate, the downstream domain MUST use 0 as the rate negotiated an EF rate, the downstream domain MUST use 0 as the rate
(i.e., drop all EF marked packets). (i.e., drop all EF marked packets).
The problem arises in the case of misconfiguration or routing The problem arises in the case of misconfiguration or routing
problems. An egress DS-node at the edge of one DS-domain forwards problems. An egress DS-node at the edge of one DS-domain forwards
packets an ingress DS-node at the edge of another DS domain. These packets an ingress DS-node at the edge of another DS domain. These
packets are marked with a DSCP that the egress node understands to packets are marked with a DSCP that the egress node understands to
map to EF, but which the ingress node does not recognize. The map to EF, but which the ingress node does not recognize. The
statement in RFC 2475 would appear to apply to this case. When RFC statement in RFC 2475 would appear to apply to this case. This is
2598 is updated, a reference to RFC 2475 to cover the case of being covered in the (draft) update to RFC2598.
unrecognized DSCPs will be added.
6. Summary of pending changes 7. No Backward Compatibility With RFC 1349
It has been pointed out that that RFC 2474 should have stated a bit
more explicitly that the TOS bit usage described in RFC 1349 is
obsoleted. This useage was intended to interact with OSPF extensions
in RFC 1247, which were never widely deployed. The processing of the
TOS bits is described as a requirement in RFC 1812. Although this is
a direct implication of the following sentence in RFC 2474:
"No attempt is made to maintain backwards compatibility with
the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791]."
Further clarification is needed. The previous sentence should be
augmented as follows when RFC 2474 is updated:
"No attempt is made to maintain backwards compatibility with the
"DTR/MBZ"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and
[RFC1349]. This implies that TOS bit processing as described in
sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this
memo. Also see [RFC2780]."
8. Summary of Pending Changes
The following standards track RFCs are expected to be updated to The following standards track RFCs are expected to be updated to
reflect the agreements captured in this memo. It is intended that reflect the agreements captured in this memo. It is intended that
these updates occur when each specification progresses to Draft (or these updates occur when each specification progresses to Draft (or
if some issue arises that forces recycling at Proposed). if some issue arises that forces recycling at Proposed).
RFC 2474: revise definition of DS field. Clarify that the RFC 2474: revise definition of DS field. Clarify that the
suggested default forwarding in the event of an unrecognized DSCP suggested default forwarding in the event of an unrecognized DSCP
is not intended to apply to ingress conditioning in DS-ingress is not intended to apply to ingress conditioning in DS-ingress
nodes. nodes. Clarify effects on RFC1349 and RFC1812.
RFC 2475: revise definition of DS field. Add SLS and TCS RFC 2475: revise definition of DS field. Add SLS and TCS
definitions. Update body of document to use SLS and TCS definitions. Update body of document to use SLS and TCS
appropriately. Add definitions of PHB scheduling class and ordered appropriately. Add definitions of PHB scheduling class and ordered
aggregate. aggregate.
RFC 2497: revise to reflect understanding that AF classes are RFC 2497: revise to reflect understanding that AF classes are
instances of the AF PHB group, and are not collectively a PHB instances of the AF PHB group, and are not collectively a PHB
group. group.
RFC 2598: put reference to RFC 2475 in security considerations to RFC 2598: put reference to RFC 2475 in security considerations to
cover the case of a DS egress node receiving an unrecognized DSCP cover the case of a DS egress node receiving an unrecognized DSCP
which maps to EF in the DS ingress node. which maps to EF in the DS ingress node. (done)
7. Security Considerations Security considerations are addressed in RFC 7. Security Considerations
2475.
Security considerations are addressed in RFC 2475.
Acknowledgements Acknowledgements
References References
[1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated [1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC
2474, December 1998. 2474, December 1998.
[2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture
for Differentiated Services", RFC 2475, December 1998. for Differentiated Services", RFC 2475, December 1998.
[3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB
Group", RFC 2597 Group", RFC 2597
skipping to change at page 7, line 17 skipping to change at page 7, line 41
[2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture
for Differentiated Services", RFC 2475, December 1998. for Differentiated Services", RFC 2475, December 1998.
[3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB
Group", RFC 2597 Group", RFC 2597
[4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion
Notification (ECN)" to IP, RFC 2481, January 1999 Notification (ECN)" to IP, RFC 2481, January 1999
[5] Bradner and Paxon, IANA Allocation Guidelines for Values in the [5] Bradner and Paxon, "IANA Allocation Guidelines for Values in the
Internet Protocol and Related Headers, draft-bradner-iana-
allocation-02.txt, October 1999, work in progress
Author's Address Author's Address
Dan Grossman Dan Grossman
Motorola, Inc. Motorola, Inc.
20 Cabot Blvd. 20 Cabot Blvd.
Mansfield, MA 02048 Mansfield, MA 02048
Email: dan@dma.isg.mot.com Email: dan@dma.isg.mot.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
itor assist in its implementation may be prepared, copied, published itor assist in its implementation may be prepared, copied, published
 End of changes. 25 change blocks. 
51 lines changed or deleted 78 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/