end-to-end service models across a wide diversity of internet
platforms. It should be noted that such an effort may not
necessarily result in a single resultant architecture, and that it is
possible to see a number of end-to-end approaches based on different
combinations of the existing components.
One approach is to attempt to combine both architectures into an
end-to-end model, using IntServ as the architecture which allows
applications to interact with the network, and DiffServ as the
architecture to manage admission the network's resources [7]. In
this approach, the basic tension that needs to be resolved lies in
difference between the per-application view of the IntServ
architecture and the network boundary-centric view of the DiffServ
architecture.
One building block for such an end-to-end service architecture is a
service signaling protocol. The RSVP signaling protocol can address
the needs of applications that require a per-service end-to-end
service signaling environment. The abstracted model of RSVP is that
of a discovery signaling protocol that allows an application to use a
single transaction to communicate its service requirements to both
the network and the remote party, and through the response mechanism,
to allow these network elements to commit to the service
requirements. The barriers to deployment for this model lie in an
element-by element approach to service commitment, implying that each
network element must undertake some level of signaling and processing
as dictated by this imposed state. For high precision services this
implies per-flow signaling and per-flow processing to support this
service model. This fine-grained high precision approach to service
management is seen as imposing an unacceptable level of overhead on
the central core elements of large carrier networks.
The DiffServ approach uses a model of abstraction which attempts to
create an external view of a compound network as a single subnetwork.
From this external perspective the network can be perceived as two
boundary service points, ingress and egress. The advantage of this
approach is that there exists the potential to eliminate the
requirement for per-flow state and per-flow processing on the
interior elements of such a network, and instead provide aggregate
service responses.
One approach is for applications to use RSVP to request that their
flows be admitted into the network. If a request is accepted, it
would imply that there is a committed resource reservation within the
IntServ-capable components of the network, and that the service
requirements have been mapped into a compatible aggregate service
class within the DiffServ-capable network [7]. The DiffServ core
must be capable of carrying the RSVP messages across the DiffServ
network, so that further resource reservation is possible within the
IntServ network upon egress from the DiffServ environment. The
approach calls for the DiffServ network to use per-flow multi-field
(MF) classifier, where the MF classification is based on the RSVP-
signaled flow specification. The service specification of the RSVP-
signaled resource reservation is mapped into a compatible aggregate
DiffServ behavior aggregate and the MF classifier marks packets
according to the selected behavior. Alternatively the boundary of
the IntServ and DiffServ networks can use the IntServ egress to mark
the flow packets with the appropriate DSCP, allowing the DiffServ
ingress element to use the BA classifier, and dispense with the per-
flow MF classifier.
A high precision end-to-end QoS model requires that any admission
failure within the DiffServ network be communicated to the end
application, presumably via RSVP. This allows the application to
take some form of corrective action, either by modifying it's service
requirements or terminating the application. If the service
agreement between the DiffServ network is statically provisioned,
then this static information can be loaded into the IntServ boundary
systems, and IntServ can manage the allocation of available DiffServ
behavior aggregate resources. If the service agreement is
dynamically variable, some form of signaling is required between the
two networks to pass this resource availability information back into
the RSVP signaling environment.
6. Conclusions
None of these observations are intended to be any reason to condemn
the QoS architectures as completely impractical, nor are they
intended to provide any reason to believe that the efforts of
deploying QoS architectures will not come to fruition.
What this document is intended to illustrate is that there are still
a number of activities that are essential precursors to widespread
deployment and use of such QoS networks, and that there is a need to
fill in the missing sections with something substantial in terms of
adoption of additional refinements to the existing QoS model.
The architectural direction that appears to offer the most promising
outcome for QoS is not one of universal adoption of a single
architecture, but instead use a tailored approach where aggregated
service elements are used in the core of a network where scalability
is a major design objective and use per-flow service elements at the
edge of the network where accuracy of the service response is a
sustainable outcome.
Architecturally, this points to no single QoS architecture, but
rather to a set of QoS mechanisms and a number of ways these
mechanisms can be configured to interoperate in a stable and
consistent fashion.
7. Security Considerations
The Internet is not an architecture that includes a strict
implementation of fairness of access to the common transmission and
switching resource. The introduction of any form of fairness, and,
in the case of QoS, weighted fairness, implies a requirement for
transparency in the implementation of the fairness contract between
the network provider and the network's users. This requires some
form of resource accounting and auditing, which, in turn, requires
the use of authentication and access control. The balancing factor
is that a shared resource should not overtly expose the level of
resource usage of any one user to any other, so that some level of
secrecy is required in this environment
The QoS environment also exposes the potential of theft of resources
through the unauthorized admission of traffic with an associated
service profile. QoS signaling protocols which are intended to
undertake resource management and admission control require the use
of identity authentication and integrity protection in order to
mitigate this potential for theft of resources.
Both forms of QoS architecture require the internal elements of the
network to be able to undertake classification of traffic based on
some form of identification that is carried in the packet header in
the clear. Classifications systems that use multi-field specifiers,
or per-flow specifiers rely on the carriage of end-to-end packet
header fields being carried in the clear. This has conflicting
requirements for security architectures that attempt to mask such
end-to-end identifiers within an encrypted payload.
QoS architectures can be considered as a means of exerting control
over network resource allocation. In the event of a rapid change in
resource availability (e.g. disaster) it is an undesirable outcome if
the remaining resources are completely allocated to a single class of
service to the exclusion of all other classes. Such an outcome
constitutes a denial of service, where the traffic control system
(routing) selects paths that are incapable of carrying any traffic of
a particular service class.
8. References
[1] Bradner, S., "The Internet Standards Process- Revision 3", BCP
9, RFC2026, October 1996.
[2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A.,
Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP)
Version 1 Applicability Statement", RFC2208, September 1997.
[3] Braden. R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC1633, June 1994.
[4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC2475,
December 1998.
[5] Baker, F., Iturralde, C., Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", Work in
Progress.
[6] Bernet, Y., "Format of the RSVP DCLASS Object", RFC2996,
November 2000.
[7] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer,
M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A
Framework for Integrated Services Operation Over DiffServ
Networks", RFC2998, November 2000.
[8] "Quality of Service Technical Overview", Microsoft Technical
Library, Microsoft Corporation, September 1999.
[9] "Resource Reservation Protocol API (RAPI)", Open Group Technical
Standard, C809 ISBN 1-85912-226-4, The Open Group, December
1998.
[10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC2007, September 1997.
[11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting:
Background", RFC1272, November 1991.
9. Acknowledgments
Valuable contributions to this document came from Yoram Bernet, Brian
Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne.
10. Author's Address
Geoff Huston
Telstra
5/490 Northbourne Ave
Dickson ACT 2602
AUSTRALIA
EMail: gih@telstra.net
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.