draft-ietf-diffserv-efresolve-00.txt   draft-ietf-diffserv-efresolve-01.txt 
Internet-Draft EF RESOLVE DESIGN TEAM
(Grenville Armitage)
(Alessio Casati)
(Jon Crowcroft)
(Joel Halpern)
(Brijesh Kumar)
(John Schnizlein)
November 12th, 2000 Internet-Draft (Informational) Grenville Armitage
Alessio Casati
Jon Crowcroft
Joel Halpern
Brijesh Kumar
John Schnizlein
A revised expression of the Expedited Forwarding PHB April 20th, 2001
<draft-ietf-diffserv-efresolve-00.txt>
A Delay Bound alternative revision of RFC2598
<draft-ietf-diffserv-efresolve-01.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 To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/ietf/1id-abstracts.txt
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 was submitted to the IETF Differentiated Services This document was submitted to the IETF Differentiated Services
(DiffServ) WG. Publication of this document does not imply (DiffServ) WG. Publication of this document does not imply
acceptance by the DiffServ WG of any ideas expressed within. acceptance by the DiffServ WG of any ideas expressed within.
Comments should be submitted to the diffserv@ietf.org mailing list. Comments should be submitted to the diffserv@ietf.org mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
RFC 2598 is the DiffServ working group's current standards track At the Pittsburgh IETF meeting in August 2000, the Differentiated
definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB) Services working group faced serious questions regarding RFC2598 -
[1]. As part of the DiffServ working group's ongoing refinement of the group's standards track definition of the Expedited Forwarding
the EF PHB, additional issues were raised with the text in RFC 2598 (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to
[2]. An 'EF design team' was formed after the Pittsburgh IETF meeting develop a re-expression of RFC2598, bearing in mind the issues raised
to synthesize a new expression of the EF PHB. This Internet Draft in the DiffServ group. At the San Diego IETF meeting in December
captures our feedback to the DiffServ WG on a proposed revision to 2000 the DiffServ working group decided to pursue an alternative re-
the EF PHB definition. A formal revision to RFC 2598 will be derived expression of the EF PHB. For historical interest this document
from this document. captures the EF Design Team's proposed solution, preferred by the
original authors of RFC2598 but not adopted by the working group in
December 2000. The original definition of EF was based on comparison
of forwarding on an unloaded network. This experimental Delay Bound
(DB) PHB requires a bound on the delay of packets due to other
traffic in the network.
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is for Informational purposes only. If implementors
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this choose to experiment with the DB PHB, key words "MUST", "MUST NOT",
document are to be interpreted as described in RFC 2119 [3]. "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in
RFC 2119 [3].
1 Introduction 1 Introduction
RFC 2598 is the Differentiated Services (DiffServ) working group's RFC 2598 was the Differentiated Services (DiffServ) working group's
current standards track definition of the Expedited Forwarding (EF) first standards track definition of the Expedited Forwarding (EF) Per
Per Hop Behavior (PHB) [1]. As part of the DiffServ working group's Hop Behavior (PHB) [1]. As part of the DiffServ working group's
ongoing refinement of the EF PHB, additional issues were raised with ongoing refinement of the EF PHB, various issues were raised with the
the text in RFC 2598 [2]. An 'EF design team' was formed after the text in RFC 2598 [2].
Pittsburgh IETF meeting to synthesize a new expression of the EF PHB.
This Internet Draft captures our feedback to the DiffServ WG on a
proposed revision to the EF PHB definition.
A formal revision to RFC 2598 will be derived from this document.
Section 2 covers the minimum, necessary and sufficient description of After the Pittsburgh IETF meeting in August 2000, a volunteer 'EF
what qualifies as 'EF' behavior from a single node. Section 3 then design team' was formed (the authors of this document) to propose a
discusses a number of issues and assumptions made to support the new expression of the EF PHB. The remainder of this Informational
definition in section 2. document captures our feedback to the DiffServ working group at the
San Diego IETF in December 2000. Our solution focussed on a Delay
Bound (DB) based re-expression of RFC 2598 which met the goals of
RFC2598's original authors. The DiffServ working group ultimately
chose an alternative re-expression of the EF PHB text, developed by
the authors of [2] and revised to additionally encompass our model
described here.
2. Definition of Expedited Forwarding Our proposed Delay Bound solution is archived for historical
interest. Section 2 covers the minimum, necessary and sufficient
description of what we believed qualifies as 'DB' behavior from a
single node. Section 3 then discusses a number of issues and
assumptions made to support the definition in section 2.
For a traffic stream not exceeding a configured rate the goal of the 2. Definition of Delay Bound forwarding
EF PHB is a strict bound on the delay variation of packets through a
hop.
When a DS-compliant node claims to implement the EF PHB, the For a traffic stream not exceeding a particular configured rate the
implementation MUST conform to the specification given in this goal of the DB PHB is a strict bound on the delay variation of
document. However, the EF PHB is not a mandatory part of the packets through a hop.
Differentiated Services architecture - a node is NOT REQUIRED to
implement the EF PHB in order to be considered DS-compliant.
This section will begin with the goals and necessary boundary This section will begin with the goals and necessary boundary
conditions for EF behavior, then provide a descriptive definition of conditions for DB behavior, then provide a descriptive definition of
EF behavior itself, discuss what it means to conform to the EF DB behavior itself, discuss what it means to conform to the DB
definition, and assign the default EF code point. definition, and assign the experimental DB PHB code point.
2.1 Goal and Scope of DB
2.1 Goal and Scope of EF
For a traffic stream not exceeding a configured rate the goal of the For a traffic stream not exceeding a configured rate the goal of the
EF PHB is a strict bound on the delay variation of packets through a DB PHB is a strict bound on the delay variation of packets through a
hop. hop.
Traffic MUST be policed and/or shaped at the source edge (for Traffic MUST be policed and/or shaped at the source edge (for
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
order to get such a bound. However, specific policing and/or shaping order to get such a bound. However, specific policing and/or shaping
rules are outside the scope of the EF PHB definition. Such rules rules are outside the scope of the DB PHB definition. Such rules
MUST be defined in any per-domain behaviors (PDBs) composed from the MUST be defined in any per-domain behaviors (PDBs) composed from the
EF PHB. DB PHB.
A device (hop) delivers EF behavior to appropriately marked traffic A device (hop) delivers DB behavior to appropriately marked traffic
received on one or more interfaces (marking is specified in section received on one or more interfaces (marking is specified in section
2.4). A device SHALL deliver the EF behavior on an interface to EF 2.4). A device SHALL deliver the DB behavior on an interface to DB
marked traffic meeting (i.e. less than or equal) a certain arrival marked traffic meeting (i.e. less than or equal) a certain arrival
rate limit R. rate limit R.
If more EF traffic arrives than is acceptable, the device is NOT If more DB traffic arrives than is acceptable, the device is NOT
REQUIRED to deliver the EF behavior. However, although the original REQUIRED to deliver the DB behavior. However, although the original
source of EF traffic will be shaped, aggregation and upstream jitter source of DB traffic will be shaped, aggregation and upstream jitter
ensure that the traffic arriving at any given hop cannot be assumed ensure that the traffic arriving at any given hop cannot be assumed
to be so shaped. Thus an EF implementation SHOULD have some to be so shaped. Thus an DB implementation SHOULD have some
tolerance for burstiness - the ability to provide EF behavior even tolerance for burstiness - the ability to provide EF behavior even
when the arrival rate exceeds the rate limit R. when the arrival rate exceeds the rate limit R.
Different EF implementations are free to exhibit different tolerance Different DB implementations are free to exhibit different tolerance
to burstiness. (Burstiness MAY be characterized in terms of the to burstiness. (Burstiness MAY be characterized in terms of the
number of back-to-back wire-rate packets to which the hop can deliver number of back-to-back wire-rate packets to which the hop can deliver
EF behavior. However, since the goal of characterizing burstiness is DB behavior. However, since the goal of characterizing burstiness is
to allow useful comparison of EF implementations, vendors and users to allow useful comparison of DB implementations, vendors and users
of EF implementations MAY choose to utilize other burstiness of DB implementations MAY choose to utilize other burstiness
metrics.) metrics.)
The EF PHB definition does NOT mandate or recommend any particular The DB PHB definition does NOT mandate or recommend any particular
method for achieving EF behavior. Rather, the EF PHB definition method for achieving DB behavior. Rather, the DB PHB definition
identifies parameters that bound the operating range(s) over which an identifies parameters that bound the operating range(s) over which an
implementation can deliver EF behavior. Implementors characterize implementation can deliver DB behavior. Implementors characterize
their implementations using these parameters, while network designers their implementations using these parameters, while network designers
and testers use these parameters to assess the utility of different and testers use these parameters to assess the utility of different
EF implementations. DB implementations.
2.2 Description of EF behavior 2.2 Description of DB behavior
For simplicity the definition will be explained using an example For simplicity the definition will be explained using an example
where traffic arrives on only one interface and is destined for where traffic arrives on only one interface and is destined for
another (single) interface. another (single) interface.
The crux of this definition is that the difference in time between The crux of this definition is that the difference in time between
when a packet might have been delivered, and when it is delivered, when a packet might have been delivered, and when it is delivered,
will never exceed a specifiable bound. will never exceed a specifiable bound.
Given an acceptable (not exceeding arrival rate limit R) stream of EF Given an acceptable (not exceeding arrival rate limit R) stream of DB
packets arriving on an interface: packets arriving on an interface:
There is a time sequence E(i) when these packets would be There is a time sequence E(i) when these packets would be
delivered at the output interface in the absence of competing delivered at the output interface in the absence of competing
traffic. That is, E(i) are the earliest times that the packets traffic. That is, E(i) are the earliest times that the packets
could be delivered by the device. could be delivered by the device.
In the presence of competing traffic, the packets will be delayed In the presence of competing traffic, the packets will be delayed
to some later time D(i). to some later time D(i).
Competing traffic includes all EF traffic arriving at the device on Competing traffic includes all DB traffic arriving at the device on
other ports, and all non-EF traffic arriving at the device on any other ports, and all non-DB traffic arriving at the device on any
port. port.
EF is defined as the behavior which ensures, for all i, that: DB is defined as the behavior which ensures, for all i, that:
D(i) - E(i) <= S * MTU/R. D(i) - E(i) <= S * MTU/R.
MTU is the maximum transmission unit (packet size) of the output. MTU is the maximum transmission unit (packet size) of the output.
R is the arrival rate that the EF device is prepared to accept on R is the arrival rate that the DB device is prepared to accept on
this interface. this interface.
Note that D(i) and E(i) simply refer to the times of what can be Note that D(i) and E(i) simply refer to the times of what can be
thought of as "the same packet" under the two treatments (with and thought of as "the same packet" under the two treatments (with and
without competing traffic). without competing traffic).
The score, S, is a characteristic of the device at the rate, R, in The score, S, is a characteristic of the device at the rate, R, in
order to meet this defined bound. This score, preferably a small order to meet this defined bound. This score, preferably a small
constant, depends on the scheduling mechanism and configuration of constant, depends on the scheduling mechanism and configuration of
the device. the device.
2.3 Conformance to EF behavior 2.3 Conformance to DB behavior
An implementation need not conform to the EF specification over an An implementation need not conform to the DB specification over an
arbitrary range of parameter values. Instead, implementations MUST arbitrary range of parameter values. Instead, implementations MUST
specify the rates, R, and scores S, for which they claim conformance specify the rates, R, and scores S, for which they claim conformance
with the EF definition in section 2.2, and the implementation- with the DB definition in section 2.2, and the implementation-
specific configuration parameters needed to deliver conformant specific configuration parameters needed to deliver conformant
behavior. An implementation SHOULD document the traffic burstiness it behavior. An implementation SHOULD document the traffic burstiness it
can tolerate while still providing EF behavior. can tolerate while still providing DB behavior.
The score, S, and configuration parameters depend on the The score, S, and configuration parameters depend on the
implementation error from an ideal scheduler. Discussion of the implementation error from an ideal scheduler. Discussion of the
ability of any particular scheduler to provide EF behavior, and the ability of any particular scheduler to provide DB behavior, and the
conditions under which it might do so, is outside the scope of this conditions under which it might do so, is outside the scope of this
document. document.
The implementor MAY define additional constraints on the range of The implementor MAY define additional constraints on the range of
configurations in which EF behavior is delivered. These constraints configurations in which DB behavior is delivered. These constraints
MAY include limits on the total EF traffic across the device, or MAY include limits on the total DB traffic across the device, or
total EF traffic targetted at a given interface from all inputs. total DB traffic targetted at a given interface from all inputs.
This document does not specify any requirements on an EF This document does not specify any requirements on an DB
implementation's values for R, S, or tolerable burstiness. These implementation's values for R, S, or tolerable burstiness. These
parameters will be bounded by real-world considerations such as the parameters will be bounded by real-world considerations such as the
actual network being designed and the desired PDB. actual network being designed and the desired PDB.
2.4 Marking for EF behavior 2.4 Marking for DB behavior
One or more DiffServ codepoint (DSCP) values may be used to indicate One or more DiffServ codepoint (DSCP) values may be used to indicate
a requirement for EF behavior [4]. a requirement for DB behavior [4].
By default a DSCP of 101110 indicates that EF PHB is required. By default we suggest an 'experimental' DSCP of 101111 be used to
indicate that DB PHB is required.
3. Discussion 3. Discussion
This section discusses some issues that might not be immediately This section discusses some issues that might not be immediately
obvious from the definition in section 2. obvious from the definition in section 2.
3.1 Mutability 3.1 Mutability
Packets marked for EF PHB MAY be remarked at a DS domain boundary Packets marked for DB PHB MAY be remarked at a DS domain boundary
only to other codepoints that satisfy the EF PHB. Packets marked for only to other codepoints that satisfy the DB PHB. Packets marked for
EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS DB PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
domain. domain.
3.2 Tunneling 3.2 Tunneling
When EF packets are tunneled, the tunneling packets must be marked as When DB packets are tunneled, the tunneling packets must be marked as
EF. DB.
3.3 Interaction with other PHBs 3.3 Interaction with other PHBs
Other PHBs and PHB groups may be deployed in the same DS node or Other PHBs and PHB groups may be deployed in the same DS node or
domain with the EF PHB as long as the requirement of section 2 is domain with the DB PHB as long as the requirement of section 2 is
met. met.
3.4 Output Rate not specified 3.4 Output Rate not specified
The definition of EF behavior given in section 2 is quite explicitly The definition of DB behavior given in section 2 is quite explicitly
given in terms of input rate R and output delay variation D(i) - given in terms of input rate R and output delay variation D(i) -
E(i). A scheduler's output rate does not need to be specified, since E(i). A scheduler's output rate does not need to be specified, since
it will be whatever is needed to achieve the target delay variation (by design) it will be whatever is needed to achieve the target delay
bounds. variation bounds.
3.5 Jitter 3.5 Jitter
Jitter is not the bounded parameter in EF behavior. Jitter can be Jitter is not the bounded parameter in DB behavior. Jitter can be
understood in a number of ways, for example the variability in inter- understood in a number of ways, for example the variability in inter-
packet times from one inter-packet interval to the next. However, EF packet times from one inter-packet interval to the next. However, DB
behavior aims to bound a related but different parameter - the behavior aims to bound a related but different parameter - the
variation in delay between the time packets would ideally depart, variation in delay between the time packets would depart in the
E(i), and when they would depart in the presence of competing absence of competing traffic, E(i), and when they would depart in the
traffic, D(i). presence of competing traffic, D(i).
3.6 Multiple Inputs and/or Multiple Outputs 3.6 Multiple Inputs and/or Multiple Outputs
The definition of 'competing traffic' in section 2.2 covers both the The definition of 'competing traffic' in section 2.2 covers both the
single input/single output case and the more general case where EF single input/single output case and the more general case where DB
traffic is converging on a single output port from multiple input traffic is converging on a single output port from multiple input
ports. When evaluating the ability of an EF device to offer EF ports. When evaluating the ability of an DB device to offer DB
behavior to traffic arriving on one port, EF traffic arriving on behavior to traffic arriving on one port, DB traffic arriving on
other ports is factored in as competing traffic. other ports is factored in as competing traffic.
When considering EF traffic from a single input that is leaving via When considering DB traffic from a single input that is leaving via
multiple ports, it is clear that the behavior is no worse than if all multiple ports, it is clear that the behavior is no worse than if all
of the traffic could be leaving through each one of those ports of the traffic could be leaving through each one of those ports
individually (subject to limits on how much is permitted). individually (subject to limits on how much is permitted).
3.7 Fragmentation and Rate 3.7 Fragmentation and Rate
Where an ingress link has an MTU higher than that of an egress link, Where an ingress link has an MTU higher than that of an egress link,
it is conceivable packets may be fragmented as they pass through a it is conceivable packets may be fragmented as they pass through a
Diffserv hop. However, the unpredictability of fragmentation is Diffserv hop. However, the unpredictability of fragmentation is
significantly counter to the goal of providing controllable QoS. significantly counter to the goal of providing controllable QoS.
Therefore we assume that fragmentation of EF packets is being avoided Therefore we assume that fragmentation of DB packets is being avoided
(either through some form of Path MTU discovery, or configuration), (either through some form of Path MTU discovery, or configuration),
and does not need to be specifically considered in the EF behavior and does not need to be specifically considered in the DB behavior
definition. definition.
3.8 Interference with other traffic 3.8 Interference with other traffic
If the DB PHB is implemented by a mechanism that allows unlimited
If the EF PHB is implemented by a mechanism that allows unlimited
preemption of other traffic (e.g., a priority queue), the preemption of other traffic (e.g., a priority queue), the
implementation MUST include some means to limit the damage EF traffic implementation MUST include some means to limit the damage DB traffic
could inflict on other traffic. This will be reflected in the EF could inflict on other traffic. This will be reflected in the DB
device's burst tolerance described in section 2.1. device's burst tolerance described in section 2.1.
3.9 Micro flow awareness 3.9 Micro flow awareness
Some EF implementations may choose to provide queuing and scheduling
Some DB implementations may choose to provide queuing and scheduling
at a finer granularity (for example, per micro flow) than is at a finer granularity (for example, per micro flow) than is
indicated solely by the packet's DSCP. Such behavior is NOT precluded indicated solely by the packet's DSCP. Such behavior is NOT precluded
by the EF PHB definition. However, such behavior is also NOT part of by the DB PHB definition. However, such behavior is also NOT part of
the EF PHB definition. Vendors are free to characterize and publicize the DB PHB definition. Implementors are free to characterize and
the additional per micro flow capabilities of their EF publicize the additional per micro flow capabilities of their DB
implementations as they see fit. implementations as they see fit.
3.10 Arrival rate 'R' 3.10 Arrival rate 'R'
In the absence of additional information, R is assumed to be limited In the absence of additional information, R is assumed to be limited
by the slowest interface on the device. by the slowest interface on the device.
In addition, an EF device may be characterized by different values of In addition, an DB device may be characterized by different values of
R for different traffic flow scenarios (for example, for traffic R for different traffic flow scenarios (for example, for traffic
aimed at different ports, total incoming R, and possibly total per aimed at different ports, total incoming R, and possibly total per
output port incoming R across all incoming interfaces). output port incoming R across all incoming interfaces).
4. IANA Considerations 4. IANA Considerations
This document allocates one codepoint, 101110, in Pool 1 of the code This document suggests one experimental codepoint, 101111. Because
space defined by [4]. the DSCP is taken from the experimental code space, it may be re-used
by other experimental or informational DiffServ proposals.
5. Conclusion. 5. Conclusion.
This document defines EF behavior in terms of a bound on delay This document defines DB behavior in terms of a bound on delay
variation for traffic streams that are rate shaped on ingress to a DS variation for traffic streams that are rate shaped on ingress to a DS
domain. Two parameters - capped arrival rate (R) and a 'score' (S) domain. Two parameters - capped arrival rate (R) and a 'score' (S)
are defined and related to the target delay variation bound. All are defined and related to the target delay variation bound. All
claims of EF 'conformance' for specific implementations of EF claims of DB 'conformance' for specific implementations of DB
behavior are made with respect to particular values for R, S, and the behavior are made with respect to particular values for R, S, and the
implementation's ability to tolerate small amounts of burstiness in implementation's ability to tolerate small amounts of burstiness in
the arriving EF traffic stream. the arriving DB traffic stream.
Security Considerations Security Considerations
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 MUST strictly police all EF marked packets to a rate domain MUST strictly police all DB marked packets to a rate
negotiated with the adjacent upstream domain (for example, some value negotiated with the adjacent upstream domain (for example, some value
less than or equal to the capped arrival rate R). Packets in excess less than or equal to the capped arrival rate R). Packets in excess
of the negotiated rate MUST be dropped. If two adjacent domains have 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 not negotiated an DB rate, the downstream domain MUST use 0 as the
rate (i.e., drop all EF marked packets). rate (i.e., drop all DB marked packets).
Since PDBs constructed from the EF PHB will require that the upstream Since PDBs constructed from the DB PHB will require that the upstream
domain police and shape EF marked traffic to meet the rate negotiated domain police and shape DB marked traffic to meet the rate negotiated
with the downstream domain, the downstream domain's policer should with the downstream domain, the downstream domain's policer should
never have to drop packets. Thus these drops SHOULD be noted (e.g., never have to drop packets. Thus these drops (or a summary of these
via SNMP traps) as possible security violations or serious drops) SHOULD be noted (e.g., via rate-limited SNMP traps) as
misconfiguration. possible security violations or serious misconfiguration.
Overflow events on an EF queue MAY also be logged as indicating Overflow events on an DB queue MAY also be logged as indicating
possible denial of service attacks or serious network possible denial of service attacks or serious network
misconfiguration. misconfiguration.
Acknowledgments Acknowledgments
This draft is the product of the EF Resolve design team, and builds This document is the product of the volunteer 'EF Resolve' design
almost entirely on the works of V. Jacobson, K. Nichols, K. Poduri team, building on the work of V. Jacobson, K. Nichols, K. Poduri [1]
[1] and A. Charny, F. Baker, J. Bennett, K. Benson, J.-Y. Le Boudec, and clarified through discussions with members of the DiffServ
A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. Kalmanek, working group (particularly the authors of [2]). Non-contentious
K.K. Ramakrishnan, and D. Stiliadis [2]. Non-contentious text (such text (such as the use of DB with tunnels, the security
as the use of EF with tunnels, the security considerations, etc) were considerations, etc) were drawn directly from equivalent text in RFC
drawn directly from RFC 2598. 2598.
EF Design Team Members Authors (volunteer EF Design Team members)
Grenville Armitage Grenville Armitage
Rm A234, 3180 Porter Drive email: gja@ureach.com
Palo Alto, CA 94061
email: gja@lucent.com
Brian E. Carpenter (team observer, WG co-chair) Brian E. Carpenter (team observer, WG co-chair)
IBM IBM
iCAIR, Suite 150 iCAIR, Suite 150
1890 Maple Avenue 1890 Maple Avenue
Evanston IL 60201, USA Evanston IL 60201, USA
email: brian@icair.org email: brian@icair.org
Alessio Casati Alessio Casati
Lucent Technologies Lucent Technologies
skipping to change at page 9, line 8 skipping to change at page 9, line 13
London WC1E 6BT, UK London WC1E 6BT, UK
email: J.Crowcroft@cs.ucl.ac.uk email: J.Crowcroft@cs.ucl.ac.uk
Joel M. Halpern Joel M. Halpern
Longitude Systems, Inc. Longitude Systems, Inc.
15000 Conference Center Drive 15000 Conference Center Drive
Chantilly, VA 20151 Chantilly, VA 20151
email: joel@longsys.com email: joel@longsys.com
Brijesh Kumar Brijesh Kumar
Ennovate Networks Corona Networks Inc.,
email: bkumar@ennovatenetworks.com 630 Alder DRive,
Milpitas, CA 95035
email: brijesh@coronanetworks.com
John Schnizlein John Schnizlein
Cisco Systems Cisco Systems
9123 Loughran Road 9123 Loughran Road
Fort Washington, MD 20744 Fort Washington, MD 20744
email: john.schnizlein@cisco.com email: john.schnizlein@cisco.com
Intellectual Properties Considerations Intellectual Properties Considerations
<TBD> To establish whether any considerations apply to the idea expressed
in this document, readers are encouraged to review notices filed with
the IETF and stored at:
http://www.ietf.org/ipr.html
References References
[1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding [1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding
[2] A Charny, ed. "EF PHB Redefined", INTERNET DRAFT <draft-charny- [2] A Charny, ed. "EF PHB Redefined", INTERNET DRAFT <draft-charny-
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
[4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the [4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
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.
 End of changes. 73 change blocks. 
146 lines changed or deleted 157 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/