One document matched: draft-bernet-intdiff-00.txt
Internet Engineering Task Force Y. Bernet, Microsoft
Internet Draft R. Yavatkar, Intel
draft-bernet-intdiff-00.txt P. Ford, Microsoft
F. Baker, Cisco
L. Zhang, UCLA
March, 1998
A Framework for End-to-End QoS Combining RSVP/Intserv and
Differentiated Services
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This
document will expire before September, 1998. Distribution of this
draft is unlimited.
1. Abstract
In the past several years, work on QoS enabled networks led to the
development of the Integrated Services (Intserv) architecture [12]
and the RSVP signaling protocol [1]. RSVP addresses the needs of
applications that require QoS, promising per-flow service. As the
RSVP/Intserv (from here on abbreviated to intserv) work has
proceeded, we have recognized barriers to the deployment of intserv.
The reliance of intserv on per-flow state and per-flow processing is
an impediment to its deployment in the Internet at large, and in
particular in large carrier networks. Additionally, RSVP signaling
is supposed to originate from hosts, which as of yet are not RSVP
enabled in large numbers.
Recently, attention has shifted to Differentiated services (diff-
serv). Diff-serv promises to expedite the realization of QoS enabled
1
Framework for End-to-End QoS March, 1998
networks by offering a significantly simpler alternative to intserv,
which eliminates scalability concerns and which can be implemented
and managed in large networks, without requiring end-to-end
deployment. However, unlike intserv, diff-serv focuses on the needs
of the large network.
This draft proposes a framework for end-to-end QoS, in which intserv
and diff-serv are used together to meet the needs of large ISPs who
manage the transit networks of the Internet, and the users of QoS
applications and hosts, who are the ISPs' ultimate customers. This
focus is important, as we believe that in the coming years, there
will be a proliferation of applications that depend on QoS and of
hosts which are capable of QoS signaling. We envision the deployment
of diff-serv capable core networks and intserv capable stub networks
at the periphery. Our framework allows each to proceed at its own
pace, providing immediate incremental benefits in areas of the
network in which one or the other is deployed and additional
benefits where both are deployed. This framework builds upon current
work in the IETF including diff-serv [10] and RSVP aggregation [8].
Many of the ideas in this document have been previously discussed in
the original intserv architecture document [12].
2. Goals of This Draft
This draft is based on the assumption that end-to-end QoS is
required to support the needs of certain applications. Such
applications include IP-telephony, video-on-demand and various non-
multimedia mission-critical applications.
In our view, intserv and diff-serv are complementary tools in the
pursuit of end-to-end QoS. Each serves an important purpose in the
end-to-end QoS enabled network. The primary goal of this draft is to
encourage the continued development of each in a manner that does
not preclude realization of the proposed framework. To this end, we
will:
1. List the requirements of a network that provides end-to-end QoS.
2. Present a framework that uses intserv as a customer of diff-serv
to meet these requirements.
3. Identify dependencies of intserv on diff-serv.
3. Requirements for the End-to-End QoS Framework
An end-to-end QoS network must serve the requirements of network
managers as well as those of applications. We consider these
requirements in the context of the following general topology:
2
Framework for End-to-End QoS March, 1998
/ Stub \ / Transit \ / Stub \
/ Network \ / Network \ / Network \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\ / \ / \ /
Figure 1: Sample Network Configuration
This network consists of a diff-serv capable transit network and two
intserv capable stub networks. In the interest of simplicity, we
show a single QoS sender on one of the stub networks and a single
QoS receiver on the other. We show edge routers (ER1, ER2) at the
interfaces of the intserv networks to the diff-serv network. We show
boundary routers (BR1, BR2) at the interfaces of the diff-serv
network to the intserv networks.
The transit network contains a mesh of routers, at least some of
which are diff-serv capable. The stub networks contain a mesh of
routers, at least some of which are intserv capable.
We define the following requirements of the framework:
3.1 Definition of a Set of Services
There must be a set of useful end-to-end services that can be
requested by QoS needy applications. Routers internal to the diff-
serv network are assumed to provide a set of 'per-hop-behaviours'
(PHBs [10]). We expect that concatenation of certain well-defined
PHBs will yield certain well-understood services across the diff-
serv network. We also expect that the intserv regions of the network
will be able to extend these services such that they can be realized
in a true end-to-end manner.
3.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows
It must be possible to allot specific end-to-end service levels to
specific application traffic flows. Within the intserv regions of
the network this is achieved by allowing applications to use RSVP to
configure classifiers which operate on IP addresses and port
numbers. We will refer to such classifiers from here on as 'MF'
classifiers [10].
Within the diff-serv regions of the network, traffic is allotted
service based on the contents of the DS-byte in packet headers.
Therefore, it is necessary for QoS needy applications to effect the
3
Framework for End-to-End QoS March, 1998
correct marking of DS-bytes before their packets are submitted to
the diff-serv network. There are two general mechanisms for doing
so:
1. Hosts may directly mark DS-bytes in the transmitted packets of
QoS needy applications.
2. Routers external to the diff-serv network may mark DS-bytes on
behalf of QoS needy applications, based on MF classification.
In the first case, marking will be done based on host configuration
or local communication between QoS needy applications and the host
operating system. In the second case, marking will be done based on
manual configuration of the marking router's MF classifier/marker or
standard signaling between QoS needy applications and the marking
router's classifier/marker.
The following three requirements argue either for host based marking
or for dynamic configuration of a router's classifier/marker in
response to application requests.
3.2.1 Minimal Management Burden
The information required to express useful mappings of application
traffic flows to service levels is likely to be quite complex and to
change frequently. Thus, manual configuration is likely to impose a
significant management burden. If the configuration information is
very simple and does not change over time, the management burden may
be relatively minor. However, this means that the granularity of
allotting service levels to flows will be sub-optimal.
3.2.2 Granularity of Allotment
The term 'granularity' is used here to refer to the degree of
specificity that is available in allotting a specific service level
to a specific traffic flow. There are two measures of granularity;
one is the granularity with which an individual flow or a group of
flows is identified. The other is the frequency at which the service
allotted to a flow may change. A fine grain QoS system would allow
the following requirement to be expressed: telephony traffic from
user X should be allotted service level A, while telephony traffic
from user Y should be allotted service level B, and web traffic from
any user should be allotted service level C. A coarse grain system
would be limited to something of the form: all traffic from subnet
1.0.0.0 should receive service level A, while all traffic from
subnet 2.0.0.0 should receive service level B. A temporally fine
grain system would allow immediate changes in allotment of service
levels to traffic flows. A temporally coarse grain system may allow
infrequent changes only.
3.2.3 Allocation of Service Level to Application Flows
It must be possible to allot specific service levels to application
traffic flows. Routers may not be able to readily identify these
flows based on network and/or transport layer fields in a packet.
4
Framework for End-to-End QoS March, 1998
For example, consider the need to give preferential service to a
website's home page (over other, less important pages at the site)
or the case of encrypted traffic flows (IPSEC).
3.3 Admission Control
Applications use RSVP to request that their flows be admitted to
intserv regions of the network. When a request is rejected, the host
application may avoid sending traffic and/or intermediate RSVP
capable nodes will only give best-effort service to traffic on flows
that were not admitted. These mechanisms protect traffic on flows
that were admitted.
In diff-serv regions of the network, admission control is provided
implicitly, by policing at ingress points. The problem with implicit
admission control is that it breaks the end-to-end validity of
explicit admission control. Specifically, an application may gain
admission using RSVP signaling, even though there is no capacity for
that application's traffic within the diff-serv region of the
network. Neither the application, nor intermediate RSVP capable
nodes will be aware that the application's traffic is not
admissible. As a result, neither can take corrective action and all
traffic from that customer, at the corresponding service level, may
be compromised. This failure may be partially, but not completely
alleviated by policing based on MF classification at the diff-serv
ingress (rather than BA classification [10]).
End-to-end QoS requires that applications and RSVP capable intserv
nodes be explicitly informed of admission control failure in the
diff-serv network. This enables them to take corrective action and
to avoid overdriving the diff-serv network. If the service agreement
between the intserv and diff-serv regions of the network is
statically provisioned, then admission control functionality can be
provided by static configuration of admission control in intserv
edge routers. However, if the service agreement is dynamically
variable, then it will be necessary to dynamically propagate current
diff-serv resource availability to the intserv network for the
purpose of explicit admission control.
3.4 Policy Support
End-to-end QoS leads to preferential treatment of certain traffic
flows over others. Within diff-serv regions of the network, policy
applies on a per-customer basis. In general, the diff-serv network
makes multiple service levels available to a single customer's
intserv network. In this case the customer must apply policy within
its network to assure appropriate allocation of resources (customer
network resources as well as diff-serv network resources) to
individual hosts in the customer's network. This requires that end-
to-end admission control be based on policy as well as resource
availability.
4.0 Intserv as a Customer of Diff-serv
5
Framework for End-to-End QoS March, 1998
To meet the above requirements, we propose a network that consists
of relatively small intserv capable stub networks, connected by
larger, diff-serv capable transit networks. In this section, we will
describe the operation of one instantiation of such a network (see
figure 1). The following assumptions apply:
4.0.1 Host Capabilities
Both sending and receiving hosts use RSVP to communicate QoS
requirements of certain QoS aware applications running on the host.
A QoS process within the host operating system generates RSVP
signaling on behalf of the applications. This process also invokes
traffic control. Host traffic control includes marking the DS-byte
in transmitted packets and shaping transmitted traffic per token
bucket specifications. Note that host traffic control is assumed for
this specific example, but is not a requirement of the framework in
general. Leaf routers within the intserv network may provide the
traffic control functions.
4.0.2 Edge Routers
The edge routers are special routers that straddle the boundary
between the RSVP/Intserv region of the network and the diff-serv
region of the network. It is helpful to think of these routers as
consisting of two halves; the standard RSVP half, which interfaces
to the stub networks, and the diff-serv half, which interfaces to
the transit network.
The RSVP half is at least partially RSVP capable; it is able to
process PATH and RESV messages but it is not necessarily required to
store full RSVP state and it is not required to provide MF
classification.
The diff-serv half of the router provides the interface to the
admission control function for the diff-serv network. We shall refer
to this function from here on as the 'DACS' (diff-serv admission
control service). The DACS is a process that is likely to (but is
not required to) run at least partially, on the routers. If the
service agreement between the stub networks and the transit networks
is statically provisioned then the DACS can be as simple as a table
which specifies capacity at each service level. If the service
agreement is dynamic, the DACS may communicate with counterparts
within the diff-serv network (such as a bandwidth broker [4]) and
may be able to make admission control decisions based on provisioned
limits as well as the topology and the capacity of the diff-serv
network.
4.0.3 Boundary Routers
These are conventional boundary routers. In the example illustrated,
they are not required to run RSVP. They are expected to implement
the policing function of diff-serv ingress routers, based on the
results of a BA classifier. They may, but are not required, to
6
Framework for End-to-End QoS March, 1998
provide MF classification nor to mark the DS-byte (with the possible
exception of the in/out bit). [10, 8]
Note that this example places the boundary between the RSVP/Intserv
network and the diff-serv network, within the edge routers at the
stub networks. In general, this boundary could be shifted to the
left or to the right. It could for example, be placed within the
boundary routers in the transit network. In this case, the DACS is
implemented entirely within the diff-serv network (and is
essentially, the bandwidth broker proposed in [4]), but the diff-
serv boundary routers must be RSVP capable.
4.0.4 Stub Networks
The stub networks consist of RSVP capable hosts and some number of
leaf routers. Leaf routers within the stub networks may or may not
be RSVP capable. Since they are relatively small networks, it is
reasonable to assume that they are RSVP capable, but this is not
necessary. If they are not RSVP capable, we assume that they will
pass RSVP messages unhindered.
4.0.5 Transit Network
The transit network is not RSVP capable. It provides two or more
levels of service based on the DS-bytes in the headers of carried
packets (diff-serv capable). Furthermore, the transit network is
able to carry RSVP messages transparently, with minimal or no impact
on its performance (see [8]). The transit network may include
multiple carrier networks.
4.0.6 Carrier/Customer Agreement
The customer (owner(s) of the leaf networks) and the carrier owning
the transit network have negotiated a contract for the capacity to
be provided at each of a number of standard diff-serv service
levels. The capacity may be statically provisioned. In this case,
the DACSs are statically configured with the capacity available at
each service level and reside entirely within the edge routers.
Alternatively, the capacity may be dynamically variable with a pre-
negotiated usage fee and/or a pre-negotiated capacity limit. In this
case, the DACS would be required to communicate with counterparts
within the diff-serv transit network.
4.0.7 Mapping from Intserv Service Type to DS-Byte
The current Intserv service types (controlled load and guaranteed)
may or may not be practical in the diff-serv network. We assume that
a set of end-to-end services that is practical is defined based on
concatenation of PHBs (such as proposed in [10]) and that unique
code points are allocated for each service in the service type field
of the Intserv flowspec.
We assume further that there is some standard coding of PHBs in a
sub-field of the DS-byte.
7
Framework for End-to-End QoS March, 1998
It follows from the previous two assumptions, that there is a
mapping from intserv service type to a sub-field of the DS-byte.
Note that there is precedent for the notion of mapping intserv
service types to per-packet priority values, specifically in the
mapping of service types to 802.1p described in [5].
4.1 How End-to-End QoS is Obtained
The following sequence illustrates the process by which an
application obtains end-to-end QoS:
1. The sending host's QoS process generates an RSVP PATH message,
describing the traffic offered by the sending application.
2. The PATH message is carried toward the receiving host. In the
sending stub network, standard RSVP processing will be applied at
RSVP capable nodes (routers, SBMs, etc).
3. At ER1, the PATH message is subjected to standard RSVP processing
and PATH state is installed in the router. The PATH message is sent
onward, to the transit network.
4. The PATH message is carried transparently through the transit
network. It is processed in the receiving stub network according to
standard RSVP processing rules.
5. At the receiving host, the QoS process generates an RSVP RESV
message, indicating interest in the offered traffic, at a certain
intserv service level.
6. The RESV message is carried back towards the sending host.
Consistent with standard RSVP processing, it may be rejected at any
RSVP node in the receiving stub network if resources are deemed
insufficient to carry the traffic requested.
7. At ER2, the RESV message is subjected to standard RSVP
processing. It may be rejected if resources on the downstream
interface of ER2 are deemed insufficient to carry the resources
requested. If it is not rejected, it will be carried transparently
through the transit network, arriving at ER1.
8. At this point, the RESV message triggers DACS processing. The
DACS compares the resources requested to the resources available at
the corresponding diff-serv service level, in the diff-serv enabled
transit network. If the RESV message is admitted, the DACS updates
the available capacity for the service class, by subtracting the
approved resources from the available capacity.
9. Assuming the available capacity is sufficient, the RESV message
is admitted and is allowed to continue upstream towards the sending
host. If the available capacity is insufficient, the RESV message
will be rejected.
8
Framework for End-to-End QoS March, 1998
10. The RESV message proceeds through the sending stub network. RSVP
nodes in the sending stub network may reject it. If it is not
rejected, it will arrive at the sending host.
11. At the sending host, the QoS process receives the RESV message.
It interprets receipt of the message as an indication that the
specified traffic has been admitted for the specified intserv
service type (in the RSVP enabled regions of the network) and for
the corresponding diff-serv service level (in the diff-serv enabled
regions of the network). It begins to set the DS-byte in the headers
of transmitted packets, to the value which maps to the Intserv
service type specified in the admitted RESV message.
In this manner, we are able to obtain end to end QoS through a
combination of networks that support RSVP style reservations and
networks that support diff-serv style prioritization. The successful
arrival of RESV messages at the original sender indicates that
admission control has succeeded both in the RSVP regions of the
network and in the diff-serv regions of the network.
4.2 Variations of the Model
It is useful to consider a number of variations of the model
presented.
4.2.1 Admission Control
4.2.1.1 Statically Provisioned Service Agreements
In the simplest model, service agreements are negotiated statically
between the stub networks and the transit networks. A service
agreement consists of a table of capacities available to a
customer's stub network, at each diff-serv service level. In this
case, DACS functionality is provided at the edge routers in the stub
networks. The 'diff-serv half' of these routers appear to the 'RSVP
half' as a sending interface with resource limits defined by the
service agreement table. While there may be bandwidth brokers and
dynamic provisioning within the transit networks, these are not
coupled with the intserv stub networks and admission control in the
two regions of the network is completely independent.
4.2.1.2 Dynamic Service Agreements
In a more sophisticated model, service agreements between customer
stub networks and carrier transit networks are more dynamic.
Customers may be able to dynamically request changes to the service
agreement. In this case, a statically provisioned edge router cannot
provide the required DACS functionality. Instead, DACS functionality
must be provided by coupling the stub network's admission control
with the transit network's admission control.
The two admission control mechanisms meet at the boundary between
the diff-serv network and the intserv network. This boundary may be
9
Framework for End-to-End QoS March, 1998
implemented at the edge router (in the stub network) or at the
boundary router (in the transit network).
4.2.1.3 Limiting the Impact of Intserv Admission Control on the Diff-
serv Network
Note that coupling intserv and diff-serv admission control does not
imply that each intserv admission control request results in diff-
serv admission control work. Instead, intserv admission control
requests are aggregated at the boundary between the intserv and the
diff-serv network. For example, intserv admission control requests
may trigger diff-serv admission control requests to bandwidth
brokers only when some high-water or low-water resource threshold is
crossed. Separate high-water and low-water thresholds provide
hysteresis to prevent thrashing.
4.2.1.4 Roles of Policy and Resource Based Admission Control
It is necessary to provide both resource and policy based admission
control in the diff-serv network as well as the intserv network. In
the diff-serv network, resource and policy based admission control
are handled by entities such as bandwidth brokers and reflected to
the intserv network as DACS (or RSVP). Policy decisions made within
the diff-serv network are likely to be at the per-intserv network
(per-customer of the diff-serv network) granularity.
In the intserv network, resource based admission control is handled
by RSVP enabled routers (and SBMs). Policy based admission control
is handled by RSVP capable policy servers. These assure that intserv
resources are allotted to intserv customers according to policy
specific to the intserv network. In addition, policy servers within
the intserv network must also assure that appropriate policy is
applied when diff-serv resources are allotted to intserv customers.
4.2.2 Setting the DS-Byte at Intermediate Nodes
In the example described, hosts use RSVP signaling and mark the DS-
byte corresponding to the admitted service level. Note that these
functions can be separated. In the example, the function of RSVP
signaling is to invoke QoS in the intserv network and to provide
end-to-end admission control. The function of marking the DS-byte is
to eliminate the need for MF classification at routers.
It is possible to mark the DS-byte at intermediate routers rather
than at the host and still to realize many of the benefits of our
approach. In this case, intermediate routers may use the RSVP
signaling to configure an MF classifier and marker. Therefore, the
configuration of MF classifiers and markers is dynamic (minimizing
the management burden) and full resource and policy based admission
control can be applied.
The disadvantages of marking the DS-byte at intermediate routers
(instead of the host) are that full MF classifiers are required at
10
Framework for End-to-End QoS March, 1998
the intermediate nodes and that responsibility for traffic
separation is shifted away from the host.
Nonetheless, this approach is necessary to support those hosts which
may be capable of RSVP signaling, but which are not capable of
marking the DS-byte. In addition, there may be cases in which the
network administrators wish to shift the responsibility for traffic
separation away from the hosts.
4.2.3 Supporting Various Levels of Host Functionality
We identify four levels of host functionality, as follows:
1. Legacy hosts, incapable of any form of QoS signaling.
2. Hosts capable of RSVP signaling but not of marking DS-bytes.
3. Hosts capable of marking DS-bytes but not of RSVP signaling.
4. Hosts capable of both RSVP signaling and marking DS-bytes.
Hosts providing any of the above levels of functionality can co-
exist in our model. However, the advantages of the model may not be
fully realizable with certain combinations. In the following
paragraph, we consider as an example, the coexistence of legacy
hosts and of hosts that are capable both of RSVP signaling and of
marking DS-bytes.
When legacy hosts are required to coexist with hosts that are
capable both of RSVP signaling and of marking DS-bytes, stub network
administrators partition stub network resources between the two
types of hosts. Legacy hosts rely on a router to mark DS-bytes based
on the output of a statically configured MF classifier. This router
could reside within the stub network or alternatively, the edge or
boundary router could be configured to provide this functionality. A
policer is also required at this router. The policer is statically
configured to limit the consumption of diff-serv resources by the
legacy hosts. The network administrator statically allocates the
remaining diff-serv resources to the hosts that are capable of RSVP
signaling by configuring the appropriate limits in the intserv
enabled region of the stub network.
We see that support for legacy hosts requires both MF classification
and marking in intermediate routers as well as static allocation of
resources by the network administrator. Hosts that are capable of
marking the DS-byte eliminate the need for intermediate routers to
provide MF classification. Hosts that are capable of signaling RSVP
(and which use the result of this signaling to control transmission
to the network), alleviate the need for static configuration as a
form of admission control.
4.3 Issues
4.3.1 Setting the DS-Byte at Hosts
The thought of allowing hosts to set the DS-byte directly, may alarm
network administrators. The obvious concern is that hosts may
11
Framework for End-to-End QoS March, 1998
attempt to 'steal' resources. In fact, hosts may attempt to exceed
the negotiated capacity at a particular service level regardless of
whether they invoke this service level directly (by setting the DS-
byte) or indirectly (by submitting traffic that classifies in an
intermediate router to a particular diff-serv PHB).
In either case, it may be necessary to protect the network by
policing at various points, both within the stub network and/or at
the interface to the transit network. This assures that customers do
not use more resources than they are entitled to, at each service
level. If the sending host does not do the marking, intermeidate
and/or boundary routers must provide MF classification, mark and
police. If the sending host does do the marking, these routers need
only to provide BA classification and to police to ensure that the
customer is not exceeding the aggregate capacity negotiated for the
service level.
Requiring hosts to mark the DS-byte has the effect of moving
responsibility to the edge of the network, in more ways than one.
With this approach, boundary routers police in aggregate. As a
result, the customer cannot rely on boundary routers to provide
traffic isolation between the customer's flows, when policing or
shaping. Instead, it is the customer's responsibility to ensure
that the customer's flows are properly shaped within the customer's
sending network.
Ideally, hosts should provide per-flow shaping at their sending
interfaces. However, there is always a chance that the customer's
traffic will become distorted as it nears the boundary between the
customer and the carrier. In this case, the customer may chose to
provide per flow policing (or even re-shaping) at the egress point
from the customer's network.
In summary, the security concerns of marking the DS-byte at the edge
of the network can be dismissed since each carrier will have to
police at their boundary anyway. Furthermore, this approach reduces
the granularity at which boundary routers must police, thereby
pushing finer grain shaping and policing responsibility to the edges
of the network, where it scales better. The carriers are thus
focused on the task of protecting their transit networks, while the
customers are focused on the task of shaping and policing their own
traffic to be in compliance with their negotiated token bucket
parameters.
4.3.2 In/Out Bits
Diff-serv proposals call for the DS-byte to be used to indicate a
PHB, as well as whether a particular packet is 'in' or 'out' of
profile. In our proposal, we recommend that hosts set at least the
bits that indicate the PHB. This does not preclude hosts from
setting the in/out bit as well. For example, hosts with
sophisticated traffic shaping features may allow applications to
occasionally burst beyond the negotiated token bucket parameters and
may apply their own policing by marking excess packets as 'out'.
12
Framework for End-to-End QoS March, 1998
This does not compromise the transit network, since it will be
policing and may remark the in/out bit.
4.3.3 End-to-End Integrity of the DS-Byte
Our proposal assumes that hosts use a standard coding for specifying
a desired PHB in some sub-field of the DS-byte. It also assumes that
packets submitted to the network with a certain PHB specified, will
receive a standard service throughout the diff-serv network.
Strictly speaking, this does not dictate that the transit network
must leave the PHB field intact. However, we see little value in
allowing the PHB field to be altered within the network. This is
likely to perpetuate local and incompatible interpretations of the
field.
4.3.4 Carrying RSVP Messages across Transit Networks
Our proposal presumes end-to-end RSVP both as a means for
communication between sending host and receiving host and
optionally, for the support of true RSVP reservations in stub
networks (or in intermediate networks which are interested in the
fine grain RSVP information). Therefore, we require that RSVP
messages be carried across the transit networks. In [8] mechanisms
are proposed for doing so in a manner that does not adversely impact
the transit network.
5. Dependencies of Intserv on Diff-Serv
We have described a framework for end-to-end QoS in which intserv
networks are customers of diff-serv networks. We believe that the
benefits of this framework are sufficient to justify the
consideration of intserv dependencies as diff-serv work proceeds. In
particular, we wish to draw attention to the following dependencies:
1. We expect that we can invoke a standard end-to-end (within the
diff-serv network) service by specifying a standard code in a (PHB)
sub-field of the DS-byte of a packet launched into a diff-serv
network.
2. Diff-serv networks must provide admission control information to
the intserv network. At the very least, this is through static
service level agreements. Preferably, this is through a dynamic
protocol. If the intserv to diff-serv boundary is implemented in the
transit network boundary routers, then this protocol is RSVP.
3. We expect that diff-serv networks will carry RSVP messages such
that they can be recovered at the egress point from the diff-serv
network.
8. Security Considerations
We are proposing that RSVP signaling be used to obtain resources in
both the diff-serv and intserv regions of the network. Therefore,
all RSVP security considerations apply [11]. In addition, network
administrators are expected to protect network resources by
configuring secure policers at interfaces with untrusted customers.
13
Framework for End-to-End QoS March, 1998
9. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S.,
"Resource Reservation Protocol (RSVP) – Version 1 Functional
Specification", RFC 2205, Proposed Standard, September 1997
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M.,
"SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission
Control Over IEEE 802 Style Networks", Internet Draft, March 1998
[3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated
Services State", Internet Draft, December 1997.
[4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit
Differentiated Services Architecture for the Internet", Internet
Draft, December 1997.
[5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over
IEEE 802.1D/802.1p Networks", Internet Draft, June 1997
[6] Elleson, E. and Blake, S., "A Proposal for the Format and
Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6
Headers", Internet Draft, November 1997
[7] Ferguson, P., "Simple Differential Services: IP TOS and
Precedence, Delay Indication, and Drop Preference", Internet Draft,
November 1997
[8] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based
QoS Requests", Internet Draft, November 1997
[9] Clark, D. and Wroclawski, J., "An Approach to Service
Allocation in the Internet", Internet Draft, July 1997
[10] Blake, S. and Nichols, K., "Differentiated Services Operational
Model and Definitions", Internet Draft, February 1998
[11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft,
August 1997
[12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in
the Internet Architecture: an Overview", Internet RFC 1633, June
1994
10. Acknowledgments
11. Author's Addresses
Yoram Bernet
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 936-9568
14
Framework for End-to-End QoS March, 1998
Email: yoramb@microsoft.com
Raj Yavatkar
Intel Corporation, JF3-206
2111 NE 25th. Avenue,
Hillsboro, OR 97124
Phone: (503) 264-9077
Email: yavatkar@ibeam.intel.com
Peter Ford
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 703-2032
Email: peterf@microsoft.com
Fred Baker
Cisco Systems
519 Lado Drive,
Santa Barbara, CA 93111
Phone: (408) 526-4257
Email: fred@cisco.com
Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA 90095
Phone: (310_825-2695
Email: lixia@cs.ucla.edu
15
| PAFTECH AB 2003-2026 | 2026-04-22 04:56:32 |