As per Relevance of the word definition, we have this rfc below:
Network Working Group G.
Request for Comments: 3248 Swinburne University of
Category: Informational B.
A.
Lucent
J.
University of
J.
B.
Corona Networks Inc
J.
Cisco
March 2002
A Delay Bound alternative revision of RFC 2598
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
For historical interest, this document captures the EF Design Team'
proposed solution, preferred by the original authors of RFC 2598
not adopted by the working group in December 2000. The
definition of EF was based on comparison of forwarding on an
network. This experimental Delay Bound (DB) PHB requires a bound
the delay of packets due to other traffic in the network. At
Pittsburgh IETF meeting in August 2000, the Differentiated
working group faced serious questions regarding RFC 2598 -
group's standards track definition of the Expedited Forwarding (EF
Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop
re-expression of RFC 2598, bearing in mind the issues raised in
DiffServ group. At the San Diego IETF meeting in December 2000
DiffServ working group decided to pursue an alternative re-
of the EF PHB
Armitage, et al. Informational [Page 1]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
Specification of
This document is for Informational purposes only. If
choose to experiment with the DB PHB, key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described
RFC 2119 [3].
1
RFC 2598 was the Differentiated Services (DiffServ) working group'
first standards track definition of the Expedited Forwarding (EF)
Hop Behavior (PHB) [1]. As part of the DiffServ working group'
ongoing refinement of the EF PHB, various issues were raised with
text in RFC 2598 [2].
After the Pittsburgh IETF meeting in August 2000, a volunteer '
design team' was formed (the authors of this document) to propose
new expression of the EF PHB. The remainder of this
document captures our feedback to the DiffServ working group at
San Diego IETF in December 2000. Our solution focussed on a
Bound (DB) based re-expression of RFC 2598 which met the goals of
2598's original authors. The DiffServ working group ultimately
an alternative re-expression of the EF PHB text, developed by
authors of [2] and revised to additionally encompass our
described here
Our proposed Delay Bound solution is archived for
interest. Section 2 covers the minimum, necessary and
description of what we believed qualifies as 'DB' behavior from
single node. Section 3 then discusses a number of issues
assumptions made to support the definition in section 2.
2. Definition of Delay Bound
For a traffic stream not exceeding a particular configured rate,
goal of the DB PHB is a strict bound on the delay variation
packets through a hop
This section will begin with the goals and necessary
conditions for DB behavior, then provide a descriptive definition
DB behavior itself, discuss what it means to conform to the
definition, and assign the experimental DB PHB code point
Armitage, et al. Informational [Page 2]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
2.1 Goal and Scope of
For a traffic stream not exceeding a configured rate the goal of
DB PHB is a strict bound on the delay variation of packets through
hop
Traffic MUST be policed and/or shaped at the source edge (
example, on ingress to the DS-domain as discussed in RFC 2475 [5])
order to get such a bound. However, specific policing and/or
rules are outside the scope of the DB PHB definition. Such
MUST be defined in any per-domain behaviors (PDBs) composed from
DB PHB
A device (hop) delivers DB behavior to appropriately marked
received on one or more interfaces (marking is specified in
2.4). A device SHALL deliver the DB behavior on an interface to
marked traffic meeting (i.e. less than or equal) a certain
rate limit R
If more DB traffic arrives than is acceptable, the device is
REQUIRED to deliver the DB behavior. However, although the
source of DB traffic will be shaped, aggregation and upstream
ensure that the traffic arriving at any given hop cannot be
to be so shaped. Thus a DB implementation SHOULD have some
for burstiness - the ability to provide EF behavior even when
arrival rate exceeds the rate limit R
Different DB implementations are free to exhibit different
to burstiness. (Burstiness MAY be characterized in terms of
number of back-to-back wire-rate packets to which the hop can
DB behavior. However, since the goal of characterizing burstiness
to allow useful comparison of DB implementations, vendors and
of DB implementations MAY choose to utilize other
metrics.)
The DB PHB definition does NOT mandate or recommend any
method for achieving DB behavior. Rather, the DB PHB
identifies parameters that bound the operating range(s) over which
implementation can deliver DB behavior. Implementors
their implementations using these parameters, while network
and testers use these parameters to assess the utility of
DB implementations
2.2 Description of DB
For simplicity the definition will be explained using an
where traffic arrives on only one interface and is destined
another (single) interface
Armitage, et al. Informational [Page 3]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
The crux of this definition is that the difference in time
when a packet might have been delivered, and when it is delivered
will never exceed a specifiable bound
Given an acceptable (not exceeding arrival rate limit R) stream of
packets arriving on an interface
There is a time sequence E(i) when these packets would
delivered at the output interface in the absence of
traffic. That is, E(i) are the earliest times that the
could be delivered by the device
In the presence of competing traffic, the packets will be
to some later time D(i).
Competing traffic includes all DB traffic arriving at the device
other ports, and all non-DB traffic arriving at the device on
port
DB is defined as the behavior which ensures, for all i, that
D(i) - E(i) <= S * MTU/R
MTU is the maximum transmission unit (packet size) of the output.
is the arrival rate that the DB device is prepared to accept on
interface
Note that D(i) and E(i) simply refer to the times of what can
thought of as "the same packet" under the two treatments (with
without competing traffic).
The score, S, is a characteristic of the device at the rate, R,
order to meet this defined bound. This score, preferably a
constant, depends on the scheduling mechanism and configuration
the device
2.3 Conformance to DB
An implementation need not conform to the DB specification over
arbitrary range of parameter values. Instead, implementations
specify the rates, R, and scores S, for which they claim
with the DB definition in section 2.2, and the implementation
specific configuration parameters needed to deliver
behavior. An implementation SHOULD document the traffic
it can tolerate while still providing DB behavior
Armitage, et al. Informational [Page 4]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
The score, S, and configuration parameters depend on
implementation error from an ideal scheduler. Discussion of
ability of any particular scheduler to provide DB behavior, and
conditions under which it might do so, is outside the scope of
document
The implementor MAY define additional constraints on the range
configurations in which DB behavior is delivered. These
MAY include limits on the total DB traffic across the device,
total DB traffic targeted at a given interface from all inputs
This document does not specify any requirements on
implementation's values for R, S, or tolerable burstiness.
parameters will be bounded by real-world considerations such as
actual network being designed and the desired PDB
2.4 Marking for DB
One or more DiffServ codepoint (DSCP) value may be used to indicate
requirement for DB behavior [4].
By default we suggest an 'experimental' DSCP of 101111 be used
indicate that DB PHB is required
3.
This section discusses some issues that might not be
obvious from the definition in section 2.
3.1
Packets marked for DB PHB MAY be remarked at a DS domain
only to other codepoints that satisfy the DB PHB. Packets marked
DB PHBs SHOULD NOT be demoted or promoted to another PHB by a
domain
3.2
When DB packets are tunneled, the tunneling packets must be marked
DB
3.3 Interaction with other
Other PHBs and PHB groups may be deployed in the same DS node
domain with the DB PHB as long as the requirement of section 2
met
Armitage, et al. Informational [Page 5]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
3.4 Output Rate not
The definition of DB behavior given in section 2 is quite
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,
(by design) it will be whatever is needed to achieve the target
variation bounds
3.5
Jitter is not the bounded parameter in DB behavior. Jitter can
understood in a number of ways, for example the variability
inter-packet times from one inter-packet interval to the next
However, DB behavior aims to bound a related but different
- the variation in delay between the time packets would depart in
absence of competing traffic, E(i), and when they would depart in
presence of competing traffic, D(i).
3.6 Multiple Inputs and/or Multiple
The definition of 'competing traffic' in section 2.2 covers both
single input/single output case and the more general case where
traffic is converging on a single output port from multiple
ports. When evaluating the ability of an DB device to offer
behavior to traffic arriving on one port, DB traffic arriving
other ports is factored in as competing traffic
When considering DB traffic from a single input that is leaving
multiple ports, it is clear that the behavior is no worse than if
of the traffic could be leaving through each one of those
individually (subject to limits on how much is permitted).
3.7 Fragmentation and
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
Diffserv hop. However, the unpredictability of fragmentation
significantly counter to the goal of providing controllable QoS
Therefore we assume that fragmentation of DB packets is being
(either through some form of Path MTU discovery, or configuration),
and does not need to be specifically considered in the DB
definition
Armitage, et al. Informational [Page 6]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
3.8 Interference with other
If the DB PHB is implemented by a mechanism that allows
preemption of other traffic (e.g., a priority queue),
implementation MUST include some means to limit the damage DB
could inflict on other traffic. This will be reflected in the
device's burst tolerance described in section 2.1.
3.9 Micro flow
Some DB implementations may choose to provide queuing and
at a finer granularity, (for example, per micro flow), than
indicated solely by the packet's DSCP. Such behavior is
precluded by the DB PHB definition. However, such behavior is
NOT part of the DB PHB definition. Implementors are free
characterize and publicize the additional per micro flow
of their DB implementations as they see fit
3.10 Arrival rate 'R
In the absence of additional information, R is assumed to be
by the slowest interface on the device
In addition, an DB device may be characterized by different values
R for different traffic flow scenarios (for example, for
aimed at different ports, total incoming R, and possibly total
output port incoming R across all incoming interfaces).
4. IANA
This document suggests one experimental codepoint, 101111.
the DSCP is taken from the experimental code space, it may be re-
by other experimental or informational DiffServ proposals
5. Conclusion
This document defines DB behavior in terms of a bound on
variation for traffic streams that are rate shaped on ingress to a
domain. Two parameters - capped arrival rate (R) and a 'score' (S),
are defined and related to the target delay variation bound.
claims of DB 'conformance' for specific implementations of
behavior are made with respect to particular values for R, S, and
implementation's ability to tolerate small amounts of burstiness
the arriving DB traffic stream
Armitage, et al. Informational [Page 7]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
Security
To protect itself against denial of service attacks, the edge of a
domain MUST strictly police all DB marked packets to a
negotiated with the adjacent upstream domain (for example, some
less than or equal to the capped arrival rate R). Packets in
of the negotiated rate MUST be dropped. If two adjacent domains
not negotiated an DB rate, the downstream domain MUST use 0 as
rate (i.e., drop all DB marked packets).
Since PDBs constructed from the DB PHB will require that the
domain police and shape DB marked traffic to meet the rate
with the downstream domain, the downstream domain's policer
never have to drop packets. Thus these drops (or a summary of
drops) SHOULD be noted (e.g., via rate-limited SNMP traps)
possible security violations or serious misconfiguration
Overflow events on an DB queue MAY also be logged as
possible denial of service attacks or serious
misconfiguration
This document is the product of the volunteer 'EF Resolve'
team, building on the work of V. Jacobson, K. Nichols, K. Poduri [1]
and clarified through discussions with members of the
working group (particularly the authors of [2]). Non-
text (such as the use of DB with tunnels, the
considerations, etc.) were drawn directly from equivalent text in
2598.
Intellectual Properties
To establish whether any considerations apply to the idea
in this document, readers are encouraged to review notices filed
the IETF and stored at
http://www.ietf.org/ipr.
Armitage, et al. Informational [Page 8]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
[1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
PHB", RFC 2598, June 1999.
[2] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K.,
Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
Kalmanek, C., Ramakrishnan, K. and D. Stiliadis, "An
Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[4] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
the Differentiated Services Field (DS Field) in the IPv4 and IPv
Headers", RFC 2474, December 1998.
[5] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
Armitage, et al. Informational [Page 9]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
Authors (volunteer EF Design Team members
Grenville
Center for Advanced Internet
Swinburne University of Technology
Melbourne,
EMail: garmitage@swin.edu.
Brian E. Carpenter (team observer, WG co-chair
IBM Zurich Research
Saeumerstrasse 4
8803
EMail: brian@hursley.ibm.
Alessio
Lucent
Swindon, WI SN5 7DJ United
EMail: acasati@lucent.
Jon
Marconi Professor of Communications
University of
Computer
William Gates
J J Thomson
CB3 0
Phone: +44 (0)1223 763633
EMail: Jon.Crowcroft@cl.cam.ac.
Joel M.
P. O. Box 6049
Leesburg, VA 20178
Phone: 1-703-371-3043
EMail: jmh@joelhalpern.
Brijesh
Corona Networks Inc.,
630 Alder Drive
Milpitas, CA 95035
EMail: brijesh@coronanetworks.
John
Cisco
9123 Loughran
Fort Washington, MD 20744
EMail: john.schnizlein@cisco.
Armitage, et al. Informational [Page 10]
RFC 3248 Delay Bound alternative revision of RFC 2598 March 2002
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Armitage, et al. Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
