draft-ietf-diffserv-rfc2598bis-01.txt   draft-ietf-diffserv-rfc2598bis-02.txt 
Network Working Group Bruce Davie, Editor Network Working Group Bruce Davie, Editor
Internet Draft Anna Charny Internet Draft Anna Charny
Expiration Date: October 2001 Fred Baker Expiration Date: March 2002 Fred Baker
Cisco Systems, Inc. Cisco Systems, Inc.
Jon Bennet Jon Bennet
Riverdelta Networks Riverdelta Networks
Kent Benson Jean-Yves Le Boudec Kent Benson Jean-Yves Le Boudec
Tellabs EPFL Tellabs EPFL
Angela Chiu William Courtney Angela Chiu William Courtney
AT&T Labs TRW AT&T Labs TRW
Shahram Davari Victor Firoiu Shahram Davari Victor Firoiu
PMC-Sierra Nortel Networks PMC-Sierra Nortel Networks
Charles Kalmanek K.K. Ramakrishnam Charles Kalmanek K.K. Ramakrishnam
AT&T Research TeraOptic Networks AT&T Research TeraOptic Networks
Dimitrios Stiliadis Dimitrios Stiliadis
Lucent Technologies Lucent Technologies
September 2001
An Expedited Forwarding PHB An Expedited Forwarding PHB
draft-ietf-diffserv-rfc2598bis-01.txt draft-ietf-diffserv-rfc2598bis-02.txt
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. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the Diffserv working group of the This document is a product of the Diffserv working group of the
Internet Engineering Task Force. Please address comments to the Internet Engineering Task Force. Please address comments to the
group's mailing list at diffserv@ietf.org, with a copy to the group's mailing list at diffserv@ietf.org, with a copy to the
authors. authors.
skipping to change at page 2, line 29 skipping to change at page 2, line 29
The PHB (per-hop behavior) is a basic building block in the The PHB (per-hop behavior) is a basic building block in the
Differentiated Services architecture. This document defines a PHB Differentiated Services architecture. This document defines a PHB
called Expedited Forwarding (EF). EF is intended to provide a called Expedited Forwarding (EF). EF is intended to provide a
building block for low delay, low jitter and low loss services by building block for low delay, low jitter and low loss services by
ensuring that the EF aggregate is served at a certain configured ensuring that the EF aggregate is served at a certain configured
rate. rate.
Contents Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 Relationship to RFC 2598 ............................... 4
2 Definition of EF PHB ................................... 4 2 Definition of EF PHB ................................... 4
2.1 Intuitive Description of EF ............................ 4 2.1 Intuitive Description of EF ............................ 4
2.2 Formal Definition of the EF PHB ........................ 5 2.2 Formal Definition of the EF PHB ........................ 6
2.3 Figures of merit ....................................... 8 2.3 Figures of merit ....................................... 9
2.4 Delay and jitter ....................................... 9 2.4 Delay and jitter ....................................... 9
2.5 Loss ................................................... 10 2.5 Loss ................................................... 10
2.6 Microflow misordering .................................. 10 2.6 Microflow misordering .................................. 10
2.7 Recommended codepoint for this PHB ..................... 10 2.7 Recommended codepoint for this PHB ..................... 11
2.8 Mutability ............................................. 11 2.8 Mutability ............................................. 11
2.9 Tunneling .............................................. 11 2.9 Tunneling .............................................. 11
2.10 Interaction with other PHBs ............................ 11 2.10 Interaction with other PHBs ............................ 11
3 Security Considerations ................................ 11 3 Security Considerations ................................ 11
4 IANA Considerations .................................... 12 4 IANA Considerations .................................... 12
5 Acknowledgments ........................................ 12 5 Acknowledgments ........................................ 12
6 References ............................................. 12 6 References ............................................. 12
7 Full Copyright ......................................... 16 7 Full Copyright ......................................... 16
Specification of Requirements Specification of Requirements
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 [3]. document are to be interpreted as described in RFC 2119 [3].
1. Introduction 1. Introduction
Network nodes that implement the differentiated services enhancements Network nodes that implement the differentiated services enhancements
to IP use a codepoint in the IP header to select a per-hop behavior to IP use a codepoint in the IP header to select a per-hop behavior
(PHB) as the specific forwarding treatment for that packet [RFC2474, (PHB) as the specific forwarding treatment for that packet [3, 4].
RFC2475]. This memo describes a particular PHB called expedited This memo describes a particular PHB called expedited forwarding
forwarding (EF). (EF).
The intent of the EF PHB is to provide a building block for low loss, The intent of the EF PHB is to provide a building block for low loss,
low delay, and low jitter services. The details of exactly how to low delay, and low jitter services. The details of exactly how to
build such services are outside the scope of this specification. build such services are outside the scope of this specification.
The dominant causes of delay in packet networks are fixed propagation The dominant causes of delay in packet networks are fixed propagation
delays (e.g. those arising from speed-of-light delays) on wide area delays (e.g. those arising from speed-of-light delays) on wide area
links and queuing delays in switches and routers. Since propagation links and queuing delays in switches and routers. Since propagation
delays are a fixed property of the topology, delay and jitter are delays are a fixed property of the topology, delay and jitter are
minimized when queueing delays are minimized. In this context, jitter minimized when queueing delays are minimized. In this context, jitter
skipping to change at page 4, line 11 skipping to change at page 4, line 11
specification of behavior of a collection of nodes is outside the specification of behavior of a collection of nodes is outside the
scope of this document. A Per-Domain Behavior (PDB) specification [7] scope of this document. A Per-Domain Behavior (PDB) specification [7]
may provide such information. may provide such information.
When a DS-compliant node claims to implement the EF PHB, the When a DS-compliant node claims to implement the EF PHB, the
implementation MUST conform to the specification given in this implementation MUST conform to the specification given in this
document. However, the EF PHB is not a mandatory part of the document. However, the EF PHB is not a mandatory part of the
Differentiated Services architecture - a node is NOT REQUIRED to Differentiated Services architecture - a node is NOT REQUIRED to
implement the EF PHB in order to be considered DS-compliant. implement the EF PHB in order to be considered DS-compliant.
1.1. Relationship to RFC 2598
This document replaces RFC 2598 [1]. The main difference is that it
adds mathematical formalism to give a more rigorous definition of the
behavior described. The full rationale for this is given in [6].
2. Definition of EF PHB 2. Definition of EF PHB
2.1. Intuitive Description of EF 2.1. Intuitive Description of EF
Intuitively, the definition of EF is simple: the rate at which EF Intuitively, the definition of EF is simple: the rate at which EF
traffic is served at a given output interface should be at least the traffic is served at a given output interface should be at least the
configured rate R, over a suitably defined interval, independent of configured rate R, over a suitably defined interval, independent of
the offered load of non-EF traffic to that interface. Two the offered load of non-EF traffic to that interface. Two
difficulties arise when we try to formalize this intuition: difficulties arise when we try to formalize this intuition:
skipping to change at page 4, line 41 skipping to change at page 4, line 47
delay within the router. delay within the router.
The formal definition below takes account of these issues. It assumes The formal definition below takes account of these issues. It assumes
that EF packets should ideally be served at rate R or faster, and that EF packets should ideally be served at rate R or faster, and
bounds the deviation of the actual departure time of each packet from bounds the deviation of the actual departure time of each packet from
the "ideal" departure time of that packet. We define the departure the "ideal" departure time of that packet. We define the departure
time of a packet as the time when the last bit of that packet leaves time of a packet as the time when the last bit of that packet leaves
the node. The "ideal" departure time of each EF packet is computed the node. The "ideal" departure time of each EF packet is computed
iteratively. iteratively.
In the case when an EF packet arrives to a device when all the In the case when an EF packet arrives at a device when all the
previous EF packets have already departed, the computation of the previous EF packets have already departed, the computation of the
ideal departure time is simple. Service of the packet should ideal departure time is simple. Service of the packet should
(ideally) start as soon as it arrives, so the ideal departure time is (ideally) start as soon as it arrives, so the ideal departure time is
simply the arrival time plus the ideal time to transmit the packet at simply the arrival time plus the ideal time to transmit the packet at
rate R. For a packet of length L_j, that transmission time at the rate R. For a packet of length L_j, that transmission time at the
configured rate R is L_j/R. (Of course, a real packet will typically configured rate R is L_j/R. (Of course, a real packet will typically
get transmitted at line rate once its transmission actually starts, get transmitted at line rate once its transmission actually starts,
but we are calculating the ideal target behavior here; the ideal but we are calculating the ideal target behavior here; the ideal
service takes place at rate R.) service takes place at rate R.)
In the case when an EF packet arrives to a device that still contains In the case when an EF packet arrives at a device that still contains
EF packets awaiting service, the computation of the ideal departure EF packets awaiting service, the computation of the ideal departure
time is more complicated. There are two cases to be considered. If time is more complicated. There are two cases to be considered. If
the previous (j-1-th) departure occurred after its own ideal the previous (j-1-th) departure occurred after its own ideal
departure time, then the scheduler is running "late". In this case, departure time, then the scheduler is running "late". In this case,
the ideal time to start service of the new packet is the ideal the ideal time to start service of the new packet is the ideal
departure time of the previous (j-1-th) packet, or the arrival time departure time of the previous (j-1-th) packet, or the arrival time
of the new packet, whichever is later, because we can't expect a of the new packet, whichever is later, because we can't expect a
packet to begin service before it arrives. If the previous (j-1-th) packet to begin service before it arrives. If the previous (j-1-th)
departure occurred before its own ideal departure time, then the departure occurred before its own ideal departure time, then the
scheduler is running "early". In this case, service of the new packet scheduler is running "early". In this case, service of the new packet
skipping to change at page 11, line 44 skipping to change at page 11, line 48
To protect itself against denial of service attacks, the edge of a DS To protect itself against denial of service attacks, the edge of a DS
domain SHOULD strictly police all EF marked packets to a rate domain SHOULD strictly police all EF marked packets to a rate
negotiated with the adjacent upstream domain. Packets in excess of negotiated with the adjacent upstream domain. Packets in excess of
the negotiated rate SHOULD be dropped. If two adjacent domains have the negotiated rate SHOULD be dropped. If two adjacent domains have
not negotiated an EF rate, the downstream domain SHOULD use 0 as the not negotiated an EF rate, the downstream domain SHOULD use 0 as the
rate (i.e., drop all EF marked packets). rate (i.e., drop all EF marked packets).
In addition, traffic conditioning at the ingress to a DS-domain MUST In addition, traffic conditioning at the ingress to a DS-domain MUST
ensure that only packets having DSCPs that correspond to an EF PHB ensure that only packets having DSCPs that correspond to an EF PHB
when they enter the DS-domain are marked with a DSCP that corresponds when they enter the DS-domain are marked with a DSCP that corresponds
to EF inside the DS-domain. Such behavior is as required by RFC to EF inside the DS-domain. Such behavior is as required by the
2475. It protects against denial-of-service and theft-of-service Differentiated Services architecture [4]. It protects against
attacks which exploit DSCPs that are not identified in any TCS denial-of-service and theft-of-service attacks which exploit DSCPs
provisioned at an ingress interface, but which map to EF inside the that are not identified in any TCS provisioned at an ingress
DS-domain. interface, but which map to EF inside the DS-domain.
4. IANA Considerations 4. IANA Considerations
This document allocates one codepoint, 101110, in Pool 1 of the code This document allocates one codepoint, 101110, in Pool 1 of the code
space defined by [RFC2474]. space defined by [3].
5. Acknowledgments 5. Acknowledgments
This document draws heavily on the original EF PHB definition of This document draws heavily on the original EF PHB definition of
Jacobson, Nichols and Poduri. It was also greatly influenced by the Jacobson, Nichols and Poduri. It was also greatly influenced by the
work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern, work of the EFRESOLVE team of Armitage, Casati, Crowcroft, Halpern,
Kumar, and Schnizlein. Kumar, and Schnizlein.
6. References 6. References
skipping to change at page 12, line 32 skipping to change at page 12, line 36
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
[4] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An [4] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
Architecture for Differentiated Services", RFC 2475, December 1998. Architecture for Differentiated Services", RFC 2475, December 1998.
[5] D. Black, "Differentiated Services and Tunnels", RFC 2983, [5] D. Black, "Differentiated Services and Tunnels", RFC 2983,
October 2000. October 2000.
[6] A. Charny et al., "Supplemental Information for the New [6] A. Charny et al., "Supplemental Information for the New
Definition of the EF PHB", Work in Progress, February 2001. Definition of the EF PHB", Work in Progress, June 2001.
[7] K. Nichols and B. Carpenter, "Definition of Differentiated [7] K. Nichols and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their Specification", Services Per Domain Behaviors and Rules for their Specification",
Work in Progress, January 2001. RFC 3086, April 2001.
Appendix: Implementation Examples Appendix: Implementation Examples
This appendix is not part of the normative specification of EF. This appendix is not part of the normative specification of EF.
However, it is included here as a possible source of useful However, it is included here as a possible source of useful
information for implementors. information for implementors.
A variety of factors in the implementation of a node supporting EF A variety of factors in the implementation of a node supporting EF
will influence the values of E_a and E_p. These factors are discussed will influence the values of E_a and E_p. These factors are discussed
in more detail in [6], and include both output schedulers and the in more detail in [6], and include both output schedulers and the
 End of changes. 15 change blocks. 
24 lines changed or deleted 28 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/