draft-ietf-issll-ds-map-00.txt   draft-ietf-issll-ds-map-01.txt 
Internet Draft J. Wroclawski Internet Draft J. Wroclawski
Expires September, 2000 MIT LCS draft-ietf-issll-ds-map-01.txt MIT LCS
draft-ietf-issll-ds-map-00.txt A. Charny Expires August, 2001 A. Charny
Cisco Systems Cisco Systems
March, 2000 February, 2001
Integrated Service Mappings for Differentiated Services Networks Integrated Service Mappings for Differentiated Services Networks
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with all This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet Drafts are working provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
skipping to change at line 38 skipping to change at line 38
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
This document is a product of the ISSLL working group of the Internet This document is a product of the ISSLL working group of the Internet
Engineering Task Force. Please address comments to the group's mailing Engineering Task Force. Please address comments to the group's mailing
list at issll@mercury.lcs.mit.edu, with a copy to the authors. list at issll@mercury.lcs.mit.edu, with a copy to the authors.
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes mappings of IETF Integrated Services onto IETF This document describes mappings of IETF Integrated Services onto IETF
differentiated services networks. These mappings allow appropriately differentiated services networks. These mappings allow appropriately
engineered and configured differentiated service network clouds to play engineered and configured differentiated service network clouds to play
the role of "network elements" in the Integrated Services framework, and the role of "network elements" in the Integrated Services framework, and
thus to be used as components of an overall end-to-end Integrated thus to be used as components of an overall end-to-end Integrated
Services QoS solution. Services QoS solution.
1. Introduction 1. Introduction
The IETF Integrated Services framework [INTSERV] defines mechanisms and The IETF Integrated Services framework [INTSERV] defines mechanisms and
interfaces for providing network Quality of Service control useful for interfaces for providing network Quality of Service control useful for
applications that require more predictable network service than is applications that require more predictable network service than is
Wroclawski and Charny Expires: August, 2001 [page 1 ]
available with the traditional best-effort IP delivery model. Provision available with the traditional best-effort IP delivery model. Provision
of end-to-end QoS control in the Intserv model is based on the of end-to-end QoS control in the Intserv model is based on the
concatenation of "network elements" along the data transmission path. concatenation of "network elements" along the data transmission path.
When all of the concatenated network elements implement one of the When all of the concatenated network elements implement one of the
defined Intserv "services" [G,CL], the resulting data transmission path defined Intserv "services" [G,CL], the resulting data transmission path
will deliver a known, controlled QoS defined by the particular Intserv will deliver a known, controlled QoS defined by the particular Intserv
service in use. service in use.
The IETF Differentiated Services framework [DIFFSERV] defines a number The IETF Differentiated Services framework [DIFFSERV] defines a number
of mechanisms for differentiating different traffic streams within a of mechanisms for differentiating different traffic streams within a
skipping to change at line 103 skipping to change at line 105
discusses issues that are independent of the class of Intserv service discusses issues that are independent of the class of Intserv service
being implemented. Section 3 discusses implementation of the Controlled being implemented. Section 3 discusses implementation of the Controlled
Load service. Section 4 discusses implementation of a mathematically Load service. Section 4 discusses implementation of a mathematically
correct Guaranteed service, and presents information about the correct Guaranteed service, and presents information about the
performance and limitations of this implementation. Section 5 discusses performance and limitations of this implementation. Section 5 discusses
implementation of close approximations to the Guaranteed service that implementation of close approximations to the Guaranteed service that
may be acceptable in some circumstances and may allow more efficient use may be acceptable in some circumstances and may allow more efficient use
of network resources. Section 6 briefly describes the relationship of of network resources. Section 6 briefly describes the relationship of
the mechanisms described here to the Intserv Null Service [NULL]. the mechanisms described here to the Intserv Null Service [NULL].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Basics 2. Basics
2.1. Components 2.1. Components
Figure 1 shows the basic use of a Diffserv network cloud as an Intserv Figure 1 shows the basic use of a Diffserv network cloud as an Intserv
network element.
Figure 1 <ascii art TBA> Wroclawski and Charny Expires: August, 2001 [page 2 ]
network element. In this figure, Intserv functions within the
non-Diffserv regions take place at the level of individual
switches, routers, subnets, and similar ojects. In contrast, the
entire Diffserv region acts as a _single_ Intserv network element;
using components of the Diffserv architecture to implement the
behaviors expected of an object in the Intserv environment.
________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-|--O--O--|ER1|---|BR1| |BR2|---|ER2|--O--O--|-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/
Non-Diffserv region Diffserv region Non-Diffserv region
Figure 1: Sample Network Configuration Figure 1 <ascii art TBA>
The figure shows that required Intserv network element functions are The figure shows that required Intserv network element functions are
mapped to the Diffserv cloud as follows: mapped to the Diffserv cloud as follows:
- Traffic scheduling. The Intserv traffic scheduling function is - Traffic scheduling. The Intserv traffic scheduling function is
supported by appropriately selected, configured, and provisioned PHB's supported by appropriately selected, configured, and provisioned PHB's
within the Diffserv network. These PHB's, when concatenated along the within the Diffserv network. These PHB's, when concatenated along the
path of traffic flow, must provide a scheduling result that adequately path of traffic flow, must provide a scheduling result that adequately
approximates the result defined by the Intserv service. approximates the result defined by the Intserv service.
skipping to change at line 149 skipping to change at line 165
per-session end-to-end flows, but in fact any collection of packets per-session end-to-end flows, but in fact any collection of packets
that can be described by an appropriate classifier can be treated as that can be described by an appropriate classifier can be treated as
an Intserv traffic flow. an Intserv traffic flow.
When Intserv is mapped to Diffserv, packets must be classified into When Intserv is mapped to Diffserv, packets must be classified into
flows, policed, shaped, and marked with the appropriate DSCP before flows, policed, shaped, and marked with the appropriate DSCP before
they enter the interior of the diffserv cloud. Strictly speaking, the they enter the interior of the diffserv cloud. Strictly speaking, the
independence requirement stated above implies that the ingress independence requirement stated above implies that the ingress
boundary router of each diffserv cloud must implement a MF classifier boundary router of each diffserv cloud must implement a MF classifier
to perform the classification function. However, in keeping with the to perform the classification function. However, in keeping with the
Wroclawski and Charny Expires: August, 2001 [page 3 ]
diffserv model, it is permissible to push the flow classification diffserv model, it is permissible to push the flow classification
function further towards the edge of the network if appropriate function further towards the edge of the network if appropriate
agreements are in place. For example, flows may be classified and agreements are in place. For example, flows may be classified and
marked by the upstream edge router if the Diffserv network is prepared marked by the upstream edge router if the Diffserv network is prepared
to trust this router. to trust this router.
- Policing and shaping. In terms of location in the network, these - Policing and shaping. In terms of location in the network, these
functions are similar to traffic classification. A strict functions are similar to traffic classification. A strict
interpretation of the Intserv framework would require that the ingress interpretation of the Intserv framework would require that the ingress
boundary router of the diffserv cloud perform these functions. In boundary router of the diffserv cloud perform these functions. In
skipping to change at line 205 skipping to change at line 223
appropriate for each service are <not yet> discussed in the service appropriate for each service are <not yet> discussed in the service
specific sections below. specific sections below.
The admission control mechanism used within the diffserv cloud is also The admission control mechanism used within the diffserv cloud is also
independent of the mechanism used by the outside world to request independent of the mechanism used by the outside world to request
service from the cloud. As an example, end-to-end RSVP might be used service from the cloud. As an example, end-to-end RSVP might be used
together with any form of interior admission control mechanism - together with any form of interior admission control mechanism -
static provisioning, a central bandwidth broker, or aggregate RSVP static provisioning, a central bandwidth broker, or aggregate RSVP
internal signalling. internal signalling.
Wroclawski and Charny Expires: August, 2001 [page 4 ]
2.2. Per-Cloud versus Per-Path Control 2.2. Per-Cloud versus Per-Path Control
The key to providing absolute, quantitative QoS services within a The key to providing absolute, quantitative QoS services within a
diffserv network is to ensure that at each hop in the network the diffserv network is to ensure that at each hop in the network the
resources allocated to the PHB's used for these services are sufficient resources allocated to the PHB's used for these services are sufficient
to handle the arriving traffic. As described above, this can be done to handle the arriving traffic. As described above, this can be done
through a spectrum of mechanisms ranging from static provisioning to through a spectrum of mechanisms ranging from static provisioning to
dynamic per-hop signaling within the cloud. Two situations are dynamic per-hop signaling within the cloud. Two situations are
possible: possible:
skipping to change at line 259 skipping to change at line 279
- Controlled Load traffic is described by a token bucket Tspec. When - Controlled Load traffic is described by a token bucket Tspec. When
traffic is conformant to the Tspec, network elements will forward it traffic is conformant to the Tspec, network elements will forward it
with queuing delay not greater than that caused by the traffic's own with queuing delay not greater than that caused by the traffic's own
burstiness - that is, the result of the source emitting a burst of burstiness - that is, the result of the source emitting a burst of
size B into a logical network with capacity R. Further, in doing this size B into a logical network with capacity R. Further, in doing this
no packets will be discarded due to queue overflow. Statistically no packets will be discarded due to queue overflow. Statistically
rare deviations from this ideal behavior are permitted. A measure of rare deviations from this ideal behavior are permitted. A measure of
the "quality" of a CL service is how rare these deviations are. the "quality" of a CL service is how rare these deviations are.
Wroclawski and Charny Expires: August, 2001 [page 5 ]
NOTE: the actual behavior requirements stated in the CL spec are NOTE: the actual behavior requirements stated in the CL spec are
slightly more detailed than what is presented here. slightly more detailed than what is presented here.
- Network elements must not assume that that arrival of nonconformant - Network elements must not assume that that arrival of nonconformant
traffic for a specific controlled-load flow will be unusual, or traffic for a specific controlled-load flow will be unusual, or
indicative of error. In certain circumstances large numbers of indicative of error. In certain circumstances large numbers of
packets will fail the conformance test *as a matter of normal packets will fail the conformance test *as a matter of normal
operation*. Some aspects of the behavior of a CL network element in operation*. Some aspects of the behavior of a CL network element in
the presence of nonconformant traffic are specified. the presence of nonconformant traffic are specified.
skipping to change at line 313 skipping to change at line 334
nonconformant traffic, giving only the minimum requirements listed nonconformant traffic, giving only the minimum requirements listed
above. above.
NOTE: The phrase "best effort basis" in the portion of the CL spec NOTE: The phrase "best effort basis" in the portion of the CL spec
quoted above has sometimes been taken to mean "the traffic must be quoted above has sometimes been taken to mean "the traffic must be
placed in the best effort traffic class and treated identically to placed in the best effort traffic class and treated identically to
BE traffic". This interpretation is incorrect. It is easy to see BE traffic". This interpretation is incorrect. It is easy to see
this at one level, because if nonconformant CL traffic from this at one level, because if nonconformant CL traffic from
non-adaptive applications is simply lumped in with adaptive non-adaptive applications is simply lumped in with adaptive
best-effort traffic it will tend to unfairly impact that traffic, in best-effort traffic it will tend to unfairly impact that traffic, in
Wroclawski and Charny Expires: August, 2001 [page 6 ]
contravention of point 2). However, the intent of the specification contravention of point 2). However, the intent of the specification
is more general. An appropriate reading is "nonconformant CL is more general. An appropriate reading is "nonconformant CL
traffic should be transmitted, when possible, in the way that is traffic should be transmitted, when possible, in the way that is
most advantageous to users and applications, subject to the most advantageous to users and applications, subject to the
requirements on non-interference with other traffic". This allows requirements on non-interference with other traffic". This allows
the CL service to be used both to provide a specific QoS for the CL service to be used both to provide a specific QoS for
non-adaptive applications and as to provide a "floor" or minimum QoS non-adaptive applications and as to provide a "floor" or minimum QoS
for adaptive applications. for adaptive applications.
3.2. Implementation of CL using the AF Per-Hop Behavior 3.2. Implementation of CL using the AF Per-Hop Behavior
skipping to change at line 369 skipping to change at line 392
c) setting the service rate of the AF instance to a bandwidth c) setting the service rate of the AF instance to a bandwidth
sufficient to meet the delay and loss behavior requirements of the sufficient to meet the delay and loss behavior requirements of the
CL spec when only high-priority packets are present. CL spec when only high-priority packets are present.
- Implement an admission control algorithm that ensures that at each - Implement an admission control algorithm that ensures that at each
hop in the network the level of conformant traffic offered to each AF hop in the network the level of conformant traffic offered to each AF
instance is equal to or less than that provisioned for in step 4c instance is equal to or less than that provisioned for in step 4c
above (or alternatively dynamically allocates more bandwidth to the above (or alternatively dynamically allocates more bandwidth to the
relevant AF instance when required). relevant AF instance when required).
Wroclawski and Charny Expires: August, 2001 [page 7 ]
In addition to these basic actions, two subtleties with the use of AF In addition to these basic actions, two subtleties with the use of AF
must be observed. must be observed.
First the relationship between different AF instances, and between AF First the relationship between different AF instances, and between AF
and other PHBs, must be more tightly constrained than is required by the and other PHBs, must be more tightly constrained than is required by the
the base AF specification. the base AF specification.
- Bandwidth should be allocated between AF and BE (and any other - Bandwidth should be allocated between AF and BE (and any other
relevant PHB's) in such a way that AF cannot simply steal all relevant PHB's) in such a way that AF cannot simply steal all
best-effort bandwidth on demand. A simple WFQ or CBQ scheduler can best-effort bandwidth on demand. A simple WFQ or CBQ scheduler can
skipping to change at line 424 skipping to change at line 448
- Resources are used efficiently by aggregating traffic with similar - Resources are used efficiently by aggregating traffic with similar
requirements, but supporting multiple delay classes for traffic with requirements, but supporting multiple delay classes for traffic with
widely differing requirements. widely differing requirements.
- Non-CL traffic is carried whenever resources permit, and is not - Non-CL traffic is carried whenever resources permit, and is not
reordered with respect to the CL flow's conformant traffic. reordered with respect to the CL flow's conformant traffic.
- Nonconformant CL traffic is not able to disrupt traffic of other - Nonconformant CL traffic is not able to disrupt traffic of other
classes, particular BE. classes, particular BE.
Wroclawski and Charny Expires: August, 2001 [page 8 ]
3.2.1 CL/AF Admission Control Approaches 3.2.1 CL/AF Admission Control Approaches
<TBA?> <TBA?>
3.3. Implementation of CL using the EF Per-Hop Behavior 3.3. Implementation of CL using the EF Per-Hop Behavior
It is also possible to implement an approximation of the Controlled Load It is also possible to implement an approximation of the Controlled Load
service using the Diffserv Expedited Forwarding [EF] PHB as the traffic service using the Diffserv Expedited Forwarding [EF] PHB as the traffic
scheduling element. This approach is not preferred, because of two scheduling element. This approach is not preferred, because of two
significant limitations. Therefore, this approach SHOULD NOT be used significant limitations. Therefore, this approach SHOULD NOT be used
skipping to change at line 477 skipping to change at line 503
- At each hop within the network the EF PHB must receive a bandwidth - At each hop within the network the EF PHB must receive a bandwidth
allocation sufficient to meet the requirements given in the EF allocation sufficient to meet the requirements given in the EF
specification when the arriving CL traffic is at the Tspec level for specification when the arriving CL traffic is at the Tspec level for
that point within the network. that point within the network.
- The topology of the network must be designed so that the - The topology of the network must be designed so that the
instantaneous queuing delay caused by fan-in to a node will exceed the instantaneous queuing delay caused by fan-in to a node will exceed the
CL requirements rarely or never. In practice, this will be a concern CL requirements rarely or never. In practice, this will be a concern
only with very high fan-in topologies. only with very high fan-in topologies.
Wroclawski and Charny Expires: August, 2001 [page 9 ]
4. Implementation of the Guaranteed Service 4. Implementation of the Guaranteed Service
The Guaranteed service [G] offers a strict mathematical assurance of The Guaranteed service [G] offers a strict mathematical assurance of
both throughput and queuing delay, assuming only that the network is both throughput and queuing delay, assuming only that the network is
functioning correctly. A key concept of the Guaranteed service is that functioning correctly. A key concept of the Guaranteed service is that
"error terms", referred to as C and D in the specification, are provided "error terms", referred to as C and D in the specification, are provided
by the network element to the customer, allowing the customer to by the network element to the customer, allowing the customer to
calculate the bandwidth it must request from the network in order to calculate the bandwidth it must request from the network in order to
achieve a particular queuing delay target. Thus, the two important achieve a particular queuing delay target. Thus, the two important
tasks in implementing a Guaranteed service network element are providing tasks in implementing a Guaranteed service network element are providing
skipping to change at line 530 skipping to change at line 558
through the Diffserv cloud should be performed off-line, perhaps as part through the Diffserv cloud should be performed off-line, perhaps as part
of a traffic management algorithm, based on the knowledge of the of a traffic management algorithm, based on the knowledge of the
topology, traffic patterns, shaping policies, and other relevant topology, traffic patterns, shaping policies, and other relevant
parametersof the cloud. These parameters are discussed in the following parametersof the cloud. These parameters are discussed in the following
sections with respect of each delay component. sections with respect of each delay component.
Once the delay bounds and determined, the corresponding error terms C_dc Once the delay bounds and determined, the corresponding error terms C_dc
and D_dc are configured into the appropriate intserv-capable edge and D_dc are configured into the appropriate intserv-capable edge
routers, as discussed below. routers, as discussed below.
Wroclawski and Charny Expires: August, 2001 [page 10]
4.1 Propagation and Serialization Delay. 4.1 Propagation and Serialization Delay.
These delay components can be bounded by modeling the Diffserv cloud as These delay components can be bounded by modeling the Diffserv cloud as
a sequence of at most h links, each of which of at most length C. The a sequence of at most h links, each of which of at most length C. The
parameters (h, C) determine the so-called "diameter" of the cloud. The parameters (h, C) determine the so-called "diameter" of the cloud. The
knowledge of this diameter can then be used to obtain upper bounds on knowledge of this diameter can then be used to obtain upper bounds on
the propagation and serialization delay through the cloud. the propagation and serialization delay through the cloud.
4.2 Shaping delay. 4.2 Shaping delay.
skipping to change at line 583 skipping to change at line 613
Since the Diffserv cloud itself does not perform any shaping in this Since the Diffserv cloud itself does not perform any shaping in this
case, its C_dc should be set to zero. The determination of the value of case, its C_dc should be set to zero. The determination of the value of
D_dc and factors affecting it are discussed in section 4.4 below. D_dc and factors affecting it are discussed in section 4.4 below.
4.2.2 Shaping at the boundary routers 4.2.2 Shaping at the boundary routers
In the case where shaping is performed by the boundary routers, shaping In the case where shaping is performed by the boundary routers, shaping
and reshaping delay become part of the delay of the Diffserv cloud and and reshaping delay become part of the delay of the Diffserv cloud and
hence have to be accounted for in the C_dc and D_dc error terms. Note hence have to be accounted for in the C_dc and D_dc error terms. Note
Wroclawski and Charny Expires: August, 2001 [page 11]
that depending on the shaping implementation, the rate-dependent error that depending on the shaping implementation, the rate-dependent error
term may not necessarily be zero, and hence ingress shaping may add a term may not necessarily be zero, and hence ingress shaping may add a
non-zero component to the C_dc value of the Diffserv cloud. non-zero component to the C_dc value of the Diffserv cloud.
Since the ingress shaping delay depends on the shaping implementation Since the ingress shaping delay depends on the shaping implementation
and shaping granularity at the border router, and since different border and shaping granularity at the border router, and since different border
routers may implement different shaping algorithms, it seems natural to routers may implement different shaping algorithms, it seems natural to
dedicate the responsibility to export the error terms for ingress dedicate the responsibility to export the error terms for ingress
shaping delay to the ingress edge router(s) attached to the border shaping delay to the ingress edge router(s) attached to the border
router. router.
skipping to change at line 634 skipping to change at line 666
responsible for exporting the D_ds component of the delay inside the responsible for exporting the D_ds component of the delay inside the
diffserv cloud which is not due to the shaping or reshaping delays. diffserv cloud which is not due to the shaping or reshaping delays.
4.2.3. Shaping inside the Diffserv cloud 4.2.3. Shaping inside the Diffserv cloud
While the Diffserv model does not prevent shaping inside the cloud as While the Diffserv model does not prevent shaping inside the cloud as
well as at the boundaries, this draft will concentrate on the most well as at the boundaries, this draft will concentrate on the most
common case when all internal interfaces of any node in the diffserv common case when all internal interfaces of any node in the diffserv
cloud implement work-conserving aggregate class-based scheduling only. cloud implement work-conserving aggregate class-based scheduling only.
Wroclawski and Charny Expires: August, 2001 [page 12]
4.3 Queuing delay 4.3 Queuing delay
Queuing delay experienced by a given packet is caused by two reasons: Queuing delay experienced by a given packet is caused by two reasons:
contention with other packets in the scheduler and the interruption of contention with other packets in the scheduler and the interruption of
service experienced by the scheduler as a whole. A typical example of service experienced by the scheduler as a whole. A typical example of
the latter is the delay in a single processor system when the processor the latter is the delay in a single processor system when the processor
schedules some tasks other than packet scheduler. If a bound on this schedules some tasks other than packet scheduler. If a bound on this
latter portion of the delay is known for all routers inside the diffserv latter portion of the delay is known for all routers inside the diffserv
cloud, then the contribution of this delay component can be bounded by cloud, then the contribution of this delay component can be bounded by
multiplying this bound by the max hop count h. multiplying this bound by the max hop count h.
skipping to change at line 685 skipping to change at line 719
- minimum rate of the shaped aggregate (denoted r_min) - minimum rate of the shaped aggregate (denoted r_min)
- maximum token bucket depth of an edge-to-edge aggregate (denoted - maximum token bucket depth of an edge-to-edge aggregate (denoted
b_max) b_max)
- minimum service rate of the EF queue (denoted S) - minimum service rate of the EF queue (denoted S)
- maximum deviation of the amount of service of the EF queue from the - maximum deviation of the amount of service of the EF queue from the
ideal fluid service at rate S (denoted E) ideal fluid service at rate S (denoted E)
Wroclawski and Charny Expires: August, 2001 [page 13]
Currently, the only known delay bound that holds for an arbitrary Currently, the only known delay bound that holds for an arbitrary
topology and arbitrary route distribution is given in [LeBouldec] by topology and arbitrary route distribution is given in [LeBouldec] by
D = (E/S + ub_max/r_min)x h/(1-u(h-1)) D = (E/S + ub_max/r_min)x h/(1-u(h-1))
which holds for any utilization u<1/(h-1). This bound holds for the which holds for any utilization u<1/(h-1). This bound holds for the
case when the capacity of any single link is substantially smaller than case when the capacity of any single link is substantially smaller than
the total capacity of all interfaces of any router. (This bound may be the total capacity of all interfaces of any router. (This bound may be
slightly improved if the capacity of a single link is not negligible slightly improved if the capacity of a single link is not negligible
compared to the total router capacity [LeBouldec]). Unfortunately, this compared to the total router capacity [LeBouldec]). Unfortunately, this
skipping to change at line 739 skipping to change at line 774
As discussed in Section 4.4, in order to provide a strict delay bound As discussed in Section 4.4, in order to provide a strict delay bound
across the Diffserv cloud the ratio of the EF load to the service rate across the Diffserv cloud the ratio of the EF load to the service rate
of the EF queue has to be deterministically bounded on all links in the of the EF queue has to be deterministically bounded on all links in the
network. This can be either ensured by signaled admission control (such network. This can be either ensured by signaled admission control (such
as using RSVP aggregation techniques [RSVPAGGR] or by a static as using RSVP aggregation techniques [RSVPAGGR] or by a static
provisioning mechanism. It should be noted that if provisioning is provisioning mechanism. It should be noted that if provisioning is
used, then to ensure deterministic load/service rate ratio on all link used, then to ensure deterministic load/service rate ratio on all link
the network should be strongly overprovisioned to account for possible the network should be strongly overprovisioned to account for possible
inaccuracy of traffic matrix estimates. inaccuracy of traffic matrix estimates.
Wroclawski and Charny Expires: August, 2001 [page 14]
In either case deterministic availability of sufficient bandwidth on all In either case deterministic availability of sufficient bandwidth on all
links is a necessary condition for the ability to provide deterministic links is a necessary condition for the ability to provide deterministic
delay guarantees. delay guarantees.
4.5.2. Effect of Shaping Granularity on Delay Bounds 4.5.2. Effect of Shaping Granularity on Delay Bounds
A related, although different issue for the ability to provide delay A related, although different issue for the ability to provide delay
deterministic delay guarantees is the granularity of the ingress deterministic delay guarantees is the granularity of the ingress
shaping. The implications of different choices on the resulting delay shaping. The implications of different choices on the resulting delay
bounds are discussed in the following subsections. bounds are discussed in the following subsections.
skipping to change at line 793 skipping to change at line 829
through a single bottleneck link, the capacity of that link is through a single bottleneck link, the capacity of that link is
sufficient to ensure the appropriate load to service rate ratio for the sufficient to ensure the appropriate load to service rate ratio for the
EF traffic. EF traffic.
Depending on which of the two choices for provisioning is chosen, Depending on which of the two choices for provisioning is chosen,
shaping of the edge-to-everywhere aggregate has the opposite effect on shaping of the edge-to-everywhere aggregate has the opposite effect on
the delay bound. the delay bound.
In the case of "edge-to-edge provisioning", the bandwidth of any link In the case of "edge-to-edge provisioning", the bandwidth of any link
may be sufficient to accommodate the _actual_ load of EF traffic while may be sufficient to accommodate the _actual_ load of EF traffic while
Wroclawski and Charny Expires: August, 2001 [page 15]
remaining within the target utilization bound. Hence, it is the minimal remaining within the target utilization bound. Hence, it is the minimal
rate and the maximum burst size of the _actual_ edge-to-edge aggregates rate and the maximum burst size of the _actual_ edge-to-edge aggregates
sharing any link that effect the delay bound. However, aggregate sharing any link that effect the delay bound. However, aggregate
edge-to-all shaping may result in individual substreams of the shaped edge-to-all shaping may result in individual substreams of the shaped
aggregate being shaped to a much higher rate than the expected rate of aggregate being shaped to a much higher rate than the expected rate of
that substream. When the edge-to-everywhere aggregate splits inside the that substream. When the edge-to-everywhere aggregate splits inside the
network into different substreams going to different destinations, each network into different substreams going to different destinations, each
of those substreams may have in the worst case substantially larger of those substreams may have in the worst case substantially larger
burstiness than the token bucket depth of the aggregate burstiness than the token bucket depth of the aggregate
edge-to-everywhere stream. This results in substantial increase of the edge-to-everywhere stream. This results in substantial increase of the
skipping to change at line 846 skipping to change at line 884
<TBA> <TBA>
6. Relationship to the Null Service 6. Relationship to the Null Service
The Intserv "Null Service" [NULL] differs from other defined services by The Intserv "Null Service" [NULL] differs from other defined services by
not expressing any quantitative network performance requirements. Use not expressing any quantitative network performance requirements. Use
of the Null Service where an Intserv service class is required allows an of the Null Service where an Intserv service class is required allows an
application or host requesting QoS control service to express policy application or host requesting QoS control service to express policy
related information to the network without making a specific related information to the network without making a specific
Wroclawski and Charny Expires: August, 2001 [page 16]
quantitative QoS request. The assumption is that the network policy quantitative QoS request. The assumption is that the network policy
management and control elements will use this information to select an management and control elements will use this information to select an
appropriate QoS for the requesting entity, and take whatever action is appropriate QoS for the requesting entity, and take whatever action is
required to provide this QoS. required to provide this QoS.
One possibility is that the network policy mechanisms will determine One possibility is that the network policy mechanisms will determine
that a quantitative end-to-end QoS is appropriate for this entity, and that a quantitative end-to-end QoS is appropriate for this entity, and
that this QoS can be provided using Intserv mechanisms. In this case, that this QoS can be provided using Intserv mechanisms. In this case,
the Null service selector can be replaced, at the first hop router or the Null service selector can be replaced, at the first hop router or
elsewhere along the path, with a different Intserv service class and elsewhere along the path, with a different Intserv service class and
skipping to change at line 882 skipping to change at line 922
[AF] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured [AF] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured
Forwarding PHB Group", RFC 2597, June 1999. Forwarding PHB Group", RFC 2597, June 1999.
[CHARNY] Anna Charny, "Delay Bounds in a Network with Aggregate [CHARNY] Anna Charny, "Delay Bounds in a Network with Aggregate
Scehduling", work in progress, Scehduling", work in progress,
ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps ftpeng.cisco.com/ftp/acharny/aggregate_delay_v4.ps
[CL] Wroclawski, J., "Specification of the Controlled-Load Network [CL] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997 Element Service", RFC 2211, September 1997
[DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With RSVP [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
Signaling", Internet Draft draft-ietf-issll-dclass-00.txt November 2000
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang Z., [DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang Z.,
Weiss, W., "An Architecture for Differentiated Service", RFC 2475, Weiss, W., "An Architecture for Differentiated Service", RFC 2475,
December 1998. December 1998.
[EF] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding [EF] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding
PHB", RFC 2598, June 1999. PHB", RFC 2598, June 1999.
[G] Schenker, S., Partridge, C., Guerin, R., "Specification of [G] Schenker, S., Partridge, C., Guerin, R., "Specification of
Guaranteed Quality of Service", RFC 2212 September 1997 Guaranteed Quality of Service", RFC 2212 September 1997
[GENCHAR] Shenker, S., Wroclawski, J., "General Characterization [GENCHAR] Shenker, S., Wroclawski, J., "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215, September Parameters for Integrated Service Network Elements", RFC 2215, September
1997 1997
Wroclawski and Charny Expires: August, 2001 [page 17]
[INTSERV] Clark, D. et al. "Integrated Services in the Internet [INTSERV] Clark, D. et al. "Integrated Services in the Internet
[ISDSFRAME] Several hundred people, Internet Draft [ISDSFRAME] Bernet, Ford, Yavatkar, Baker, Zhang, Speer, Braden,
draft-ietf-issll-diffserv-rsvp-03.txt Davie, Wroclawski, Felstaine, "A Framework for Integrated
Services Operation over Diffserv Networks", RFC 2998, November 2000
[LEBOUDEC] Jean-Yves LeBoudec, "A Proven Delay Bound in a Network with [LEBOUDEC] Jean-Yves LeBoudec, "A Proven Delay Bound in a Network with
Aggregate Scheduling", work in progress, Aggregate Scheduling", work in progress,
http://ica1www.epfl.ch/PS_files/ds2.ps http://ica1www.epfl.ch/PS_files/ds2.ps
[NULL] Bernet, Y., Smith, A., Davie, B., "Specification of the Null [NULL] Bernet, Y., Smith, A., Davie, B., "Specification of the Null
Service Type", Internet Draft draft-ietf-issll-nullservice-00.txt Service Type", RFC 2297, November 2000
[RSVP] Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource [RSVP] Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC
2205, September 1997 2205, September 1997
[RSVPAGGR] Baker, F., Iturralde, C., Le Faucheur, F., Davie, B., [RSVPAGGR] Baker, F., Iturralde, C., Le Faucheur, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", Internet Draft "Aggregation of RSVP for IPv4 and IPv6 Reservations", Internet Draft
draft-ietf-issll-rsvp-aggr-02.txt draft-ietf-issll-rsvp-aggr-02.txt
[RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated [RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
9. Authors' addresses 9. Authors' addresses
John Wroclawski John Wroclawski
MIT Laboratory for Computer Science MIT Laboratory for Computer Science
545 Technology Sq., Cambridge, MA 02139, USA 545 Technology Sq., Cambridge, MA 02139, USA
Phone: +1 617 253 7885
EMail: jtw@lcs.mit.edu EMail: jtw@lcs.mit.edu
Anna Charny Anna Charny
Cisco Systems Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824, USA 300 Apollo Drive, Chelmsford, MA 01824, USA
Phone: +1 978 244 8000
Email: acharny@cisco.com Email: acharny@cisco.com
10. Full Copyright 10. Full Copyright
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society 2001. All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied, explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards procedures for copyrights defined in the Internet Standards
Wroclawski and Charny Expires: August, 2001 [page 18]
process must be followed, or as required to translate it into process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns. be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Wroclawski and Charny Expires: August, 2001 [page 19]
 End of changes. 30 change blocks. 
19 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/