draft-ietf-diffserv-new-terms-07.txt   draft-ietf-diffserv-new-terms-08.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
Expires: June, 2002 Expires: July, 2002
draft-ietf-diffserv-new-terms-07.txt draft-ietf-diffserv-new-terms-08.txt
December, 2001 January, 2002
New Terminology and Clarifications for Diffserv New Terminology and Clarifications 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 line 42 skipping to change at page 1, line 43
This memo captures Diffserv working group agreements concerning new This memo captures Diffserv working group agreements concerning new
and improved terminology, and also provides minor technical and improved terminology, and also provides minor technical
clarifications. It is intended to update RFC 2474, RFC 2475 and RFC clarifications. It is intended to update RFC 2474, RFC 2475 and RFC
2597. When RFCs 2474 and 2597 advance on the standards track, and 2597. When RFCs 2474 and 2597 advance on the standards track, and
RFC 2475 is updated, it is intended that the revisions in this memo RFC 2475 is updated, it is intended that the revisions in this memo
will be incorporated, and that this memo will be obsoleted by the new will be incorporated, and that this memo will be obsoleted by the new
RFCs. RFCs.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999, 2001). All Rights Copyright (C) The Internet Society (1999, 2002). All Rights
Reserved. Reserved.
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. Some minor technical standards track RFCs have needed to be refined. Some minor technical
clarifications were also found to be needed. This memo was created clarifications were also found to be needed. This memo was created
to capture group agreements, rather than attempting to revise the to capture group agreements, rather than attempting to revise the
base RFCs and recycle them at proposed standard. It updates in part base RFCs and recycle them at proposed standard. It updates in part
RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been updated by RFC RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been updated by RFC
XXXX (draft-ietf-diffserv-rfc2598bis), and clarifications agreed by XXXX (draft-ietf-diffserv-rfc2598bis), and clarifications agreed by
the group were incorporated in that update. the group were incorporated in that update.
skipping to change at line 80 skipping to change at page 2, line 37
considerations that were of a pricing, contractual or other business considerations that were of a pricing, contractual or other business
nature, as well as those that were strictly technical. There also nature, as well as those that were strictly technical. There also
could be other technical considerations in such an agreement (e.g., could be other technical considerations in such an agreement (e.g.,
service availability) which are not addressed by Diffserv. It was service availability) which are not addressed by Diffserv. It was
therefore agreed that the notions of SLAs and TCAs would be taken to therefore agreed that the notions of SLAs and TCAs would be taken to
represent the broader context, and that new terminology would be used represent the broader context, and that new terminology would be used
to describe those elements of service and traffic conditioning that to describe those elements of service and traffic conditioning that
are addressed by Diffserv. are addressed by Diffserv.
- A Service Level Specification (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
stream by a DS domain. traffic stream by a DS domain.
- A Traffic Conditioning Specification (TCS) is a set of parameters - A Traffic Conditioning Specification (TCS) is a set of
and their values which together specify a set of classfier rules parameters and their values which together specify a set of
and a traffic profile. A TCS is an integral element of an SLS. classfier rules 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.
Also note that the definition of a "Service Provisioning Policy" is Also note that the definition of a "Service Provisioning Policy" is
unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning
skipping to change at line 113 skipping to change at page 3, line 24
the parameters and range of values that may be in the former. the parameters and range of values that may be in the former.
Further note that this definition is more restrictive than that in Further note that this definition is more restrictive than that in
RFC 3198. RFC 3198.
3. Usage of PHB Group 3. Usage of PHB Group
RFC 2475 defines a Per-hop behavior (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
to all PHBs in the set such as a queue servicing or queue applying 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 2597 [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
behavior with some assigned level of queuing resources and three drop forwarding behavior with some assigned level of queuing resources and
precedences. An AF PHB Group consists of three PHBs, and uses three three drop precedences. An AF PHB Group consists of three PHBs, and
Diffserv Codepoints (DSCPs). uses three Diffserv Codepoints (DSCPs).
RFC 2597 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
(where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF
is one instance of an AF PHB Group. class is one instance of an AF PHB Group.
There has been confusion expressed that RFC 2597 refers to all four AF There has been confusion expressed that RFC 2597 refers to all four
classes with their three drop precedences as being part of a single PHB AF classes with their three drop precedences as being part of a
Group. However, since each AF class operates entirely independently of single PHB Group. However, since each AF class operates entirely
the others, (and thus there is no common constraint among AF classes as independently of the others, (and thus there is no common constraint
there is among drop precedences within an AF class) this usage is among AF classes as there is among drop precedences within an AF
inconsistent with RFC 2475. The inconsistency exists for historical class) this usage is inconsistent with RFC 2475. The inconsistency
reasons and will be removed in future revisions of the AF specification. exists for historical reasons and will be removed in future
It should now be understood that AF is a _type_ of PHB group, and each revisions of the AF specification. It should now be understood that
AF class is an _instance_ of the AF type. AF is a _type_ of PHB group, and each 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
2475 definition of PHB Group. RFC 2475 does not prohibit new PHB RFC 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB
specifications from assigning enough DSCPs to represent multiple specifications from assigning enough DSCPs to represent multiple
independent instances of their PHB Group. However, such a set of DSCPs independent instances of their PHB Group. However, such a set of
must not be referred to as a single PHB Group. DSCPs must not be referred to as a single PHB Group.
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
Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the Diffserv Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to
TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 rename the TOS octet of the IPV4 header, and Traffic Class octet of
header, respectively, to the DS field. The DS Field has a six bit the IPV6 header, respectively, to the DS field. The DS Field has a
Diffserv Codepoint and two "currently unused bits". six bit 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 "Currently Unused" (CU) bits of the DS ambiguities. In particular, the "Currently Unused" (CU) bits of the
Field have not been assigned to Diffserv, and have been assigned an DS Field have not been assigned to Diffserv, and subsequent to the
experimental use for an explicit congestion notification scheme [4]. publication of RFC 2474, they were assigned for explicit congestion
In the current text, a DSCP is, depending on context, either an encoding notification, as defined in RFC 3168 [4]. In the current text, a
which selects a PHB or a sub-field in the DS field which contains that DSCP is, depending on context, either an encoding which selects a PHB
encoding. or a sub-field in the DS field which contains that encoding.
The present text is also inconsistent with BCP0037, IANA Allocation The present text is also inconsistent with BCP0037, IANA Allocation
Guidelines for Values in the Internet Protocol and Related Headers [5]. Guidelines for Values in the Internet Protocol and Related Headers
The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class field [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class
are superceded by the 6 bit DS field and a 2 bit CU field. The IANA field are superseded by the 6 bit DS field and a 2 bit CU field. The
allocates values in the DS field following the IANA considerations IANA allocates values in the DS field following the IANA
section in RFC 2474. Experimental uses of the CU field are assigned considerations section in RFC 2474, as clarified in section 8 of this
after IESG approval processes. Permanent values in the CU field are memo.
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 BCP0037 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
2474, the following definitions should apply: 2474, the following definitions should apply:
- the Differentiated Services Field (DSField) is the six most - the Differentiated Services Field (DSField) is the six most
significant bits of the (former) IPV4 TOS octet or the (former) significant bits of the (former) IPV4 TOS octet or the (former)
IPV6 Traffic Class octet. IPV6 Traffic Class octet.
- 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 used by Diffserv.
When RFC 2474 is updated, consideration should be given to changing
the designation "currently unused (CU)" to "explicit congestion
notification (ECN)" and referencing RFC 3168 (or its successor).
The update should also reference BCP0037. The update should also reference BCP0037.
5. Ordered Aggregates and PHB Scheduling Classes 5. Ordered Aggregates and PHB Scheduling Classes
Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to
the realization that a concept was needed in Diffserv to capture the the realization that a concept was needed in Diffserv to capture the
notion of a set of BAs with a common ordering constraint. This notion of a set of BAs with a common ordering constraint. This
presently applies to AF behavior aggregates, since a DS node may not presently applies to AF behavior aggregates, since a DS node may not
reorder packets of the same microflow if they belong to the same AF reorder packets of the same microflow if they belong to the same AF
class. This would, for example, prevent an MPLS LSR which was also a class. This would, for example, prevent an MPLS LSR which was also a
DS node from discriminating between packets of an AF Behavior DS node from discriminating between packets of an AF Behavior
Agrregeate (BA) based on drop precedence and forwarding packets of Agrregeate (BA) based on drop precedence and forwarding packets of
the same AF class but different drop precedence over different LSPs. the same AF class but different drop precedence over different LSPs.
The following new terms are defined. 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
ordering constraint. The set of PHBs that are applied to this set an ordering constraint. The set of PHBs that are applied to this
of Behavior Aggregates constitutes a PHB scheduling class. set of Behavior Aggregates constitutes a PHB scheduling class.
6. Unknown/Improperly Mapped DSCPs 6. Unknown/Improperly Mapped DSCPs
Several implementors have pointed out ambiguities or conflicts in the Several implementors have pointed out ambiguities or conflicts in the
Diffserv RFCs concerning behavior when a DS-node recieves a packet Diffserv RFCs concerning behavior when a DS-node recieves a packet
with a DSCP which it does not understand. 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
DS codepoints modified to acceptable values before being forwarded. their DS codepoints modified to acceptable values before being
For example, an ingress node receiving traffic from a domain with forwarded. For example, an ingress node receiving traffic from a
which no enhanced service agreement exists may reset the DS domain with which no enhanced service agreement exists may reset
codepoint to the Default PHB codepoint [DSFIELD]." the DS 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
4), and their codepoints should not be changed." Sec. 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 arrives with a DSCP that hadn't been misconfiguration). If a packet arrives with a DSCP that hadn't been
explicitly mapped to a particular PHB, it should be treated the same explicitly mapped to a particular PHB, it should be treated the same
way as a packet marked for Default. The alternatives were to assign way as a packet marked for Default. The alternatives were to assign
it another PHB, which could result in misallocation of provisioned it another PHB, which could result in misallocation of provisioned
resources, or to drop it. Those are the only alternatives within the resources, or to drop it. Those are the only alternatives within the
framework of 2474. Neither alternative was considered desirable. framework of 2474. Neither alternative was considered desirable.
There has been discussion of a PHB which receives worse service than There has been discussion of a PHB which receives worse service than
skipping to change at line 263 skipping to change at page 6, line 36
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 was a similar issue, which manifested itself with the first There was a similar issue, which manifested itself with the first
incarnation of Expedited Forwarding (EF). RFC 2598 states: incarnation of Expedited 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
(i.e., drop all EF marked packets). rate (i.e., drop all EF marked packets).
The problem arose in the case of misconfiguration or routing The problem arose 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 to an ingress DS-node at the edge of another 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 understands These packets are marked with a DSCP that the egress node understands
to map to EF, but which the ingress node does not recognize. The to map to EF, but which the ingress node does not recognize. The
statement in RFC 2475 would appear to apply to this case. RFC XXXX statement in RFC 2475 would appear to apply to this case. RFC XXXX
[7] (draft-ietf-diffserv-rfc2598bis) clarifies this point. [7] (draft-ietf-diffserv-rfc2598bis) clarifies this point.
7. No Backward Compatibility With RFC 1349 7. No Backward Compatibility With RFC 1349
At least one implementor has expressed confusion about the At least one implementor has expressed confusion about the
relationship of the DSField, as defined in RFC 2474, to the use of relationship of the DSField, as defined in RFC 2474, to the use of
the TOS bits, as described in RFC 1349. The RFC 1349 useage was the TOS bits, as described in RFC 1349. The RFC 1349 useage was
intended to interact with OSPF extensions in RFC 1247, which were intended to interact with OSPF extensions in RFC 1247. These were
never widely deployed. The processing of the TOS bits is described never widely deployed and thus removed by standards action when STD
as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10]. 0054 was published. The processing of the TOS bits is described as a
RFC 2474 states: requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10]. RFC
2474 states:
"No attempt is made to maintain backwards compatibility with "No attempt is made to maintain backwards compatibility with
the "DTR" the "DTR" or TOS bits of the IPv4 TOS octet, as defined in
or TOS bits of the IPv4 TOS octet, as defined in [RFC791].", [RFC791].",
In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For
completeness, when RFC 2474 is updated, the sentence should read: completeness, when RFC 2474 is updated, the sentence should read:
"No attempt is made to maintain backwards compatibility with the "No attempt is made to maintain backwards compatibility with the
"DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in
[RFC791] and [RFC1349]. This implies that TOS bit processing as [RFC791] and [RFC1349]. This implies that TOS bit processing as
described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted
by this memo. Also see [RFC2780]." by this memo. Also see [RFC2780]."
8. IANA Considerations 8. IANA Considerations
skipping to change at line 317 skipping to change at page 7, line 42
be updated to reflect the agreements captured in this memo. It is be updated to reflect the agreements captured in this memo. It is
intended that these updates occur when each standards track RFC intended that these updates occur when each standards track RFC
progresses to Draft (or if some issue arises that forces recycling at progresses to Draft (or if some issue arises that forces recycling at
Proposed). RFC 2475 is expected to be updated at about the same time Proposed). RFC 2475 is expected to be updated at about the same time
as RFC 2474. Those updates will also obsolete this memo. as RFC 2474. Those updates will also obsolete this memo.
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. Clarify effects on RFC1349 and RFC1812. Clarify that only nodes. Clarify effects on RFC1349 and RFC1812. Clarify that only
RECOMMENDED DSCPs assigned by standards action are to be registered RECOMMENDED DSCPs assigned by standards action are to be
by IANA. registered by IANA.
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
aggregate. ordered 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.
In addition, RFCXXXX [7] (draft-ietf-diffserv-rfc2598bis) put a In addition, RFCXXXX [7] (draft-ietf-diffserv-rfc2598bis) put a
reference to RFC 2475 in the security considerations section to cover reference to RFC 2475 in the security considerations section to cover
the case of a DS egress node receiving an unrecognized DSCP which maps the case of a DS egress node receiving an unrecognized DSCP which
to EF in the DS ingress node. maps to EF in the DS ingress node.
10. Security Considerations 10. Security Considerations
Security considerations are addressed in RFC 2475. Security considerations are addressed in RFC 2475.
Acknowledgements Acknowledgements
This memo captures agreements of the Diffserv working
This memo captures agreements of the Diffserv working group. Many group. Many individuals contributed to the discussions on the
individuals contributed to the discussions on the Diffserv list and in Diffserv list and in the meetings. The Diffserv chairs were Brian
the meetings. The Diffserv chairs were Brian Carpenter and Kathie Carpenter and Kathie Nichols. Among many who participated actively
Nichols. Among many who participated actively in these discussions in these discussions were Lloyd Wood, Juha Heinanen, Grenville
were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud,
Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Joel Halpern, John Schnizlein, Francois Le Faucheur, and Fred Baker.
Francois Le Faucheur, and Fred Baker. Mike Ayers, Mike Heard and Andrea Mike Ayers, Mike Heard and Andrea Westerinen provided valuable
Westerinen provided valuable editorial comments. editorial comments.
Normative References Normative 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
[4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion [4] Ramakrishnan, Floyd, Black "The Addition of Explicit Congestion
Notification (ECN)" to IP, RFC 2481, January 1999 Notification (ECN) to IP", RFC 3168, September 2001
[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", BCP0037/RFC2780, March Internet Protocol and Related Headers", BCP0037/RFC2780, March
2000 2000
[6] Westerinen et al, "Terminology for Policy Based Management", RFC [6] Westerinen et al, "Terminology for Policy Based Management", RFC
3198 3198
[7] Davie et al, "An Expedited Forwarding PHB", RFC XXXX (ex-draft- [7] Davie et al, "An Expedited Forwarding PHB", RFC XXXX (ex-draft-
ietf-rfc2598bis-02.txt) ietf-rfc2598bis-02.txt)
 End of changes. 29 change blocks. 
87 lines changed or deleted 93 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/