draft-ietf-diffserv-new-terms-02.txt   draft-ietf-diffserv-new-terms-03.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
November, 1999 August, 2000
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 4, line 45 skipping to change at page 4, line 45
concept was needed in Diffserv to capture the notion of a set of BAs concept was needed in Diffserv to capture the notion of a set of BAs
with a common ordering constraint. This presently applies to AF with a common ordering constraint. This presently applies to AF
behavior aggregates, since a DS node may not reorder packets of the behavior aggregates, since a DS node may not reorder packets of the
same microflow if they belong to the same AF class. This would, for same microflow if they belong to the same AF class. This would, for
example, prevent an MPLS LSR which was also a DS node from example, prevent an MPLS LSR which was also a DS node from
discriminating between packets of an AF BA based on drop precedence discriminating between packets of an AF BA based on drop precedence
and forwarding packets of the same AF class but different drop and forwarding packets of the same AF class but different drop
precedence over different LSPs. The following new terms are defined. 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 packets must be preserved that ordering of at least those packets belonging to the same
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
ambiguities or conflicts in the Diffserv RFCs concerning behavior
when a DS-node recieves a packet with a DSCP which it does not
understand.
RFC 2475 states:
"Ingress nodes must condition all other inbound traffic to ensure
that the DS codepoints are acceptable; packets found to have
unacceptable codepoints must either be discarded or must have their
DS codepoints modified to acceptable values before being forwarded.
For example, an ingress node receiving traffic from a domain with
which no enhanced service agreement exists may reset the DS
codepoint to the Default PHB codepoint [DSFIELD]."
On the other hand, RFC 2474 states:
"Packets received with an unrecognized codepoint SHOULD be
forwarded as if they were marked for the Default behavior (see Sec.
4), and their codepoints should not be changed."
The intent in RFC 2474 principally concerned DS-interior nodes.
However, this behavior could also be performed in DS-ingress nodes
AFTER the traffic conditioning required by RFC 2475 (in which case,
an unrecognized DSCP would occur only in the case of
misconfiguration). If a packet showed up with a DSCP that hadn't
been explicitly mapped to any particular PHB, it should get treated
the same way as a packet marked for Default. The alternatives were to
assign it another PHB, which could result in misallocation of
provisioned resources, or to drop it. Those are the only
alternatives within the framework of 2474. Neither alternative was
considered desirable. There has been discussion of a PHB which
receives worse service than the default; this might be a better
alternative. Hence the imperitive was"SHOULD" rather than "SHALL".
The intent in RFC 2475 is clearly concerns DS-ingress nodes, or to be
more precise, the ingress traffic conditioning function. This is
another context where the "SHOULD" in RFC 2474 gives the flexibility
to do what the group intended. Such tortured readings are not
desirable.
Therefore, the statement in RFC 2474 will be clarified to indicate
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
case.
There is a similar issue, which manifests itself with EF. RFC 2598
states:
To protect itself against denial of service attacks, the edge of a
DS domain MUST strictly police all EF marked packets to a rate
negotiated with the adjacent upstream domain. (This rate must be
<= the EF PHB configured rate.) Packets in excess of the
negotiated rate MUST be dropped. If two adjacent domains have not
negotiated an EF rate, the downstream domain MUST use 0 as the rate
(i.e., drop all EF marked packets).
The problem arises in the case of misconfiguration or routing
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 are marked with a DSCP that the egress node understands to
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
2598 is updated, a reference to RFC 2475 to cover the case of
unrecognized DSCPs will be added.
6. Summary of pending changes 6. 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 RFC 2474: revise definition of DS field. Clarify that the
suggested default forwarding in the event of an unrecognized DSCP
is not intended to apply to ingress conditioning in DS-ingress
nodes.
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
cover the case of a DS egress node receiving an unrecognized DSCP
which maps to EF in the DS ingress node.
7. Security Considerations Security considerations are addressed in RFC 7. Security Considerations Security considerations are addressed in RFC
2475. 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
 End of changes. 6 change blocks. 
4 lines changed or deleted 74 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/