< draft-ietf-intserv-svc-template-01.txt   draft-ietf-intserv-svc-template-02.txt >
Internet Engineering Task Force Integrated Services WG Internet Engineering Task Force Integrated Services WG
INTERNET-DRAFT S. Shenker/J. Wroclawski INTERNET-DRAFT S. Shenker/J. Wroclawski
draft-ietf-intserv-svc-template-01.txt Xerox PARC/MIT LCS draft-ietf-intserv-svc-template-02.txt Xerox PARC/MIT LCS
June, 1995 November, 1995
Expires: 12/25/95 Expires: 5/96
Network Element Service Specification Template Network Element Service Specification Template
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
This draft is a product of the Integrated Services Working Group of This draft is a product of the Integrated Services Working Group of
the Internet Engineering Task Force. Comments are solicited and the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at int- should be addressed to the working group's mailing list at int-
serv@isi.edu and/or the author(s). serv@isi.edu and/or the author(s).
Abstract Abstract
This document defines a format for specifying services provided by This document defines a framework for specifying services provided
network elements, and available to applications, in a network by network elements, and available to applications, in an
which offers multiple classes of service. The document provides internetwork which offers multiple qualities of service. The
necessary context, including definitions, data formats, and document first provides some necessary context -- including
interfaces; then specifies a "template" which service relevant definitions and suggested data formats -- and then
specification documents should follow. The specification template specifies a "template" which service specification documents
includes per-element requirements such as the service's packet should follow. The specification template includes per-element
handling behavior, parameters required and made available by the requirements such as the service's packet handling behavior,
service, traffic specification and policing requirements, and parameters required and made available by the service, traffic
traffic ordering relationships. It also includes evaluation specification and policing requirements, and traffic ordering
criteria for elements providing the service, and examples of how relationships. It also includes evaluation criteria for elements
the service might be implemented (by network elements) and used providing the service, and examples of how the service might be
(by applications). implemented (by network elements) and used (by applications).
Introduction Introduction
This document defines the format used to specify the functionality of This document defines the framework used to specify the functionality
internetwork system components related to "Integrated Services"; the of internetwork system components which support the the ability to
ability to provide multiple, dynamically selectable qualities of provide multiple, dynamically selectable qualities of service to
service to applications using the internetwork. The behavior of applications using an internetwork. The behavior of individual
individual routers and subnetworks is captured as a set of routers and subnetworks is captured as a set of "services", some or
"services", some or all of which may be offered by each element. The all of which may be offered by each element. The concatenation of
concatenation of these services along the end-to-end data paths used these services along the end-to-end data paths used by an application
by an application provides overall quality of service control. provides overall quality of service control.
The definition of a service, as specified by this document, states The definition of a service states what is required of a router (or,
what is required of a router (or, more generally, any network more generally, any network element; a router, switch, subnet, etc.)
element; a router, switch, subnet, etc.) which supports a particular which supports a particular service. The service definition also
service. The service definition also specifies parameters used to specifies parameters used to invoke the service, the relationship
invoke the service, the relationship between those parameters and the between those parameters and the service delivered, and the end-to-
service delivered, and the end-to-end behavior obtained by end behavior obtained by concatenating several instances of the
concatenating several instances of the service. service.
The service definition does not describe the protocols or mechanisms Each service definition also specifies the interface between that
used to establish state in the network elements for flows that use service and the environment. This includes the parameters needed to
the described service, but may specify information which must be invoke the service, informational parameters which the service must
carried between end-nodes and network elements by those mechanisms. make available for use by setup, routing, and management mechanisms,
and information which should be carried between end-nodes and network
elements by those mechanisms in order to achieve the desired end-to-
end behavior. However, a service definition does not describe the
specific protocols or mechanisms used to establish state in the
network elements for flows that use the described service.
Services defined following the guidelines of this document are Services defined following the guidelines of this document are
intended for use both within the global Internet and private IP intended for use both within the global Internet and private IP
networks. In certain cases a concatenation of network element networks. In certain cases a concatenation of network element
services may be used to provide a range of end-to-end behaviors; some services may be used to provide a range of end-to-end behaviors, some
more suited to a decentralized internet and some more appropriate for more suited to a decentralized internet and some more appropriate for
a tightly managed private network. This document points out places a tightly managed private network. This document points out places
where such distinction may be appropriate. where such distinction may be appropriate.
This document is comprised of three parts. The first defines some
terms used both in this document and in the various service
specification documents. The second discusses data formats and
representations. The third portion of the document describes the
various components of the service specification template.
Definitions Definitions
The following terms are used throughout this document. Service The following terms are used throughout this document. Service
specification documents should employ the same terms to express these specification documents should employ the same terms to express these
concepts. concepts.
o Quality of Service (QoS) o Quality of Service (QoS)
In the context of this document, quality of service refers to the In the context of this document, quality of service refers to the
suitability of a packet delivery service for the needs of a nature of the packet delivery service provided, as described by
particular application, as defined by parameters such as achieved parameters such as achieved bandwidth, packet delay, and packet loss
bandwidth, packet delay, and packet loss rates. Traditionally, the rates. Traditionally, the Internet has offered a single quality of
Internet has offered a single quality of service; best-effort service, best-effort delivery, with available bandwidth and delay
delivery with available bandwidth and delay characteristics dependent characteristics dependent on instantaneous load. Control over the
on instantaneous load. Control over the quality of service seen by quality of service seen by applications is exercised by adequate
applications is exercised by adequate provisioning of the network provisioning of the network infrastructure. In contrast, a network
infrastructure. In contrast, a network with dynamically controllable with dynamically controllable quality of service allows individual
quality of service allows individual application sessions to request application sessions to request network packet delivery
network packet delivery characteristics according to their perceived characteristics according to their perceived needs, and may provide
needs, and may provide different qualities of service to different different qualities of service to different applications. It should
applications. It should be understood that there is a range of useful be understood that there is a range of useful possibilities between
possibilities between the two endpoints of providing no dynamic QoS the two endpoints of providing no dynamic QoS control at all and
control at all and providing extremely precise and accurate control providing extremely precise and accurate control of QoS parameters.
of QoS parameters.
o Network Element o Network Element
A "Network Element" (or the equivalent shorter form "Element"), is A "Network Element" (or the equivalent shorter form "Element"), is
any component of an internetwork which directly handles data packets any component of an internetwork which directly handles data packets
and thus is potentially capable of exercising QOS control over data and thus is potentially capable of exercising QoS control over data
flowing through it. Network elements include routers, subnetworks, flowing through it. Network elements include routers, subnetworks,
and end-node operating systems. A "QOS-aware" network element is one and end-node operating systems. A QoS-capable network element is one
which offers one or more of the services defined according to the which offers one or more of the services defined according to the
format of this document. Note that this definition does not by itself rules given in this document. Note that this definition, by itself,
preclude QoS-aware network elements which meet performance goals preclude QoS-capable network elements that meet performance goals
purely through adequate provisioning, rather than active control purely through adequate provisioning rather than active admission and
mechanisms. traffic control mechanisms. A "QoS-aware" network element is one
which supports the interfaces (described below) required by the
service definitions. Thus, a QoS-aware network element need not
actually offer any of the services defined according to the format of
this document; it merely needs to know how to deny service requests.
o Flow o Flow
For the purposes of this document a flow is a set of packets For the purposes of this document a flow is a set of packets
traversing a network element all of which are covered by the same traversing a network element all of which are covered by the same
request for control of quality of service. At a given network element request for control of quality of service. At a given network element
a flow may consist of the packets from a single application session, a flow may consist of the packets from a single application session,
or it may be an aggregation comprising the combined data traffic from or it may be an aggregation comprising the combined data traffic from
a number of application sessions. a number of application sessions.
NOTE: this definition of a flow is different from that used in
IPv6, where a flow is defined as those packets with the same
source address and FlowID.
Mechanisms used to associate a request for quality of service control Mechanisms used to associate a request for quality of service control
with the packets covered by that request are beyond the scope of this with the packets covered by that request are beyond the scope of this
document. document.
o Service o Service
The word "service" describes a named, coordinated set of QoS control The word "service" describes a named, coordinated set of QoS control
capabilities provided by a single network element. The definition of capabilities provided by a single network element. The definition of
a service includes a specification of the functions to be performed a service includes a specification of the functions to be performed
by the network element, the information required by the element to by the network element, the information required by the element to
perform these functions, and the information made available by the perform these functions, and the information made available by the
element to other elements of the system. element to other elements of the system. A service is conceptually
implemented within the "service module" contained within the network
A service is conceptually implemented within a "service module" element.
contained within the network element. A network element may and
generally will contain more than one service module and hence offer
more than one service.
NOTE: The above defines a precise meaning for the word "service"; NOTE: The above defines a precise meaning for the word "service".
a word which has a variety of meanings throughout the networking Service is a word which has a variety of meanings throughout the
community. The definition of "service" given here refers networking community; the definition of "service" given here
specifically to the actions and responses of a single network refers specifically to the actions and responses of a single
element such as a router or subnet. This contrasts with the more network element such as a router or subnet. This contrasts with
end-to-end oriented definition of the same word seen in some other the more end-to-end oriented definition of the same word seen in
networking contexts. some other networking contexts.
o Behavior o Behavior
A "behavior" is the QoS-related end-to-end performance seen by an A "behavior" is the QoS-related end-to-end performance seen by an
application session. This behavior is the end result of composing the application session. This behavior is the end result of composing the
services offered by each network element along the path of the services offered by each network element along the path of the
application's data flow. application's data flow.
When each network element along a data flow path offers the same When each network element along a data flow path offers the same
service, it is frequently possible to explain the resulting end-to- service, it is frequently possible to explain the resulting end-to-
skipping to change at page 5, line 20 skipping to change at page 5, line 31
Characterizations are computed from a set of characterization Characterizations are computed from a set of characterization
parameters provided by each network element on the flow's path, and a parameters provided by each network element on the flow's path, and a
composition function which computes the end-to-end characterization composition function which computes the end-to-end characterization
from those parameters. The composition function may in practice be from those parameters. The composition function may in practice be
executed in a distributed fashion by the setup or routing protocol, executed in a distributed fashion by the setup or routing protocol,
or the characterization parameters may be gathered to a single point or the characterization parameters may be gathered to a single point
and the characterization computed at that point. and the characterization computed at that point.
Several characterizations may be computed for a single candidate data Several characterizations may be computed for a single candidate data
flow. Conversely, characterizations are not mandatory, and under some flow. Conversely, a service may provide no characterizations, and
conditions no characterizations may be available to the end-nodes under some conditions no characterizations may be available to the
requesting QoS services. end-nodes requesting QoS services.
o Composition Function o Composition Function
A composition function accepts characterization parameters as input A composition function accepts characterization parameters as input
and computes a characterization, as described above. and computes a characterization, as described above.
o Traffic Specification (TSpec) o Traffic Specification (TSpec)
A Traffic Specification, or TSpec, is a specification of the traffic A Traffic Specification, or TSpec, is a description of the traffic
pattern which a flow expects to exhibit. As examples, this pattern for which service is being requested. In general, the TSpec
specification might take the form of a token bucket filter (defined forms one side of a "contract" between the data flow and the service.
below) or an upper bound on the peak rate. Note that the traffic Once a service request is accepted, the service module has agreed to
specification specifies the flow's -expected- traffic pattern, not provide a specific QoS as long as the flow's data traffic continues
the flows -actual- traffic pattern. The behavior of a service when a to be accurately described by the TSpec.
flow's actual traffic does not conform to the traffic specification
must be defined by the service (see "Policing" below).
Traffic specifications are most frequently created by the originator As examples, this specification might take the form of a token bucket
of the data flow. filter (defined below) or an upper bound on the peak rate. Note that
the traffic specification specifies the flow's *allowed* traffic
pattern, not the flows *actual* traffic pattern. The behavior of a
service when a flow's actual traffic does not conform to the traffic
specification must be defined by the service (see "Policing" below).
o Service Request Specification (RSpec) o Service Request Specification (RSpec)
A Service Request Specification, or RSpec, is a specification of the A Service Request Specification, or RSpec, is a specification of the
quality of service a flow desires from a network element. The form of quality of service a flow wishes to request from a network element.
a service request specification is highly specific to a particular The contents of a service request specification is highly specific to
service. As examples, these specifications might contain information a particular service. As examples, these specifications might contain
about bandwidth allocated to the flow, maximum delays, or packet loss information about bandwidth allocated to the flow, maximum delays, or
rates. Service request specifications may originate from either the packet loss rates.
sender or receiver(s) of a data flow.
o Setup Protocol o Setup Protocol
A setup protocol is used to carry QoS-related information from the A setup protocol is used to carry QoS-related information from the
end-nodes requesting QoS control to network elements which must end-nodes requesting QoS control to network elements which must
exercise that control, and to install and maintain to required QoS exercise that control, and to install and maintain to required QoS
control state in those network elements. A setup protocol may also control state in those network elements. A setup protocol may also
be used to collect QoS-related information from interior network be used to collect QoS-related information from interior network
elements along an application's data flow path for ultimate delivery elements along an application's data flow path for ultimate delivery
to end nodes. Examples of protocols which perform setup functions are to end nodes. Examples of protocols which perform setup functions are
RSVP [xxx], ST-II [xxx] and Q.2931 [xxx]. RSVP (RFC to be determined), ST-II (RFC 1819), and Q.2931.
Note that other mechanisms, such as network management protocols, may
also perform this function. The phrase "setup protocol"
conventionally refers to a protocol with this function as its primary
purpose.
o Token Bucket o Token Bucket
A particular form of traffic specification consisting of a "token A Token Bucket is a particular form of traffic specification
rate" R and a "bucket size" B. Essentially, the R parameter specifies consisting of a "token rate" r and a "bucket size" b. Essentially,
the continually sustainable data rate, while the B parameter the r parameter specifies the continually sustainable data rate,
specifies the extent to which the data rate can exceed the while the b parameter specifies the extent to which the data rate can
sustainable level for short periods of time. exceed the sustainable level for short periods of time. More
specifically, the traffic must obey the rule that over all time
periods, the amount of data sent cannot exceed rT+b, where T is the
length of the time period.
Token buckets are further discussed in [xxx]. Token buckets are further discussed in [1].
o Token Bucket Filter o Token Bucket Filter
A filtering or policing function which differentiates those packets A Token Bucket Filter is a filtering or policing function which
in a traffic flow which conform to a particular token bucket differentiates those packets in a traffic flow which conform to a
specification from those packets which do not. The specific treatment particular token bucket specification from those packets which do
accorded nonconforming packets is not specified in this definition; not. The specific treatment accorded nonconforming packets is not
common actions are discarding of the packet or marking the packet in specified in this definition; common actions are relegating the
some fashion. packet to best effort service, discarding the packet, or marking the
packet in some fashion.
NOTE: The definition of token bucket in this document does not
allow for token bucket filters with a "backing buffer" which
queues packets that do not immediately pass through the filter.
The intent is to cleanly distinguish the bufferless case from the
buffer case through the use of different names; however this draft
does not yet provide a definition for the second case.
o Admission Control o Admission Control
Admission control is the process of deciding whether a newly arriving Admission control is the process of deciding whether a newly arriving
request for service from a network element can be granted, or must be request for service from a network element can be granted. This
refused due to scarcity of resources. This action must be performed action must be performed by any service which wishes to offer
by any service which wishes to offer absolute quantitative bounds on absolute quantitative bounds on overall performance. It is not
overall performance. It is not necessary for services which provide necessary for services which provide only relative statements about
only relative statements about performance, such as the Internet's performance, such as the Internet's current best-effort service. The
current best-effort service. The precise criteria for making the precise criteria for making the admission control decision are a
admission control decision are a specific to each particular service. specific to each particular service.
o Policing o Policing
Policing is the set of actions triggered when a flow's actual data Policing is the set of actions triggered when a flow's actual data
traffic characteristics exceed the expected values given in the traffic characteristics exceed the expected values given in the
flow's traffic specification. Services which require policing flow's traffic specification. Services which require policing
functions to operate correctly must specify the locations in the functions to operate correctly must specify both the action to be
network where discrepancies are to be detected and the action to be taken when such discrepancies occur and the locations in the network
taken when such discrepancies occur. Examples of such actions might where discrepancies are to be detected. Examples of such actions
include dropping packets, reshaping the traffic, or marking non- might include relegating the packet to best effort service, dropping
conforming traffic for later discard if necessary. packets, reshaping the traffic, or marking non-conforming traffic in
some fashion.
o Interfaces
The service module conceptually interacts with other portions of the
network element through a number of interfaces. The service
specification document should clearly define the specific data,
including formats, which moves across each conceptual interface, and
ensure that the mapping between conceptual interfaces and the
specific mechanisms of the service being defined are clear.
NOTE: The interfaces required by the service module are currently
documented only by this note.
Data Format and Representation Data Format and Representation
Each service module will import and export a variety of data A service module will import and export a variety of data according
according to its specific requirements. The service definition MUST to the specific requirements of the services the network element
specify the format of each such data item in an abstract manner. The supports. Each service definition MUST specify the format of each
information specified must be sufficient for the designer of a setup such data item in an abstract manner. The information specified must
protocol to correctly select an appropriate concrete (packet) format be sufficient for the designer of a setup protocol to correctly
for variables containing this data. At minimum, the following select an appropriate concrete (packet) format for variables
information must be given: containing this data. At minimum, the following information must be
given:
- Type: whether the quantity is an enumeration, a numerical value, - Type: whether the quantity is an enumeration, a numerical value,
etc. etc.
- Range: for numerical quantities, the minimum and maximum values - Range: for numerical quantities, the minimum and maximum values
the quantity must be able to represent. For enumerated quantities, the quantity must be able to represent. For enumerated quantities,
an estimate of the maximum number of items which may need be an estimate of the maximum number of items which may need be
enumerated in the future, even if many of the values are currently enumerated in the future, even if many of the values are currently
unused. unused.
skipping to change at page 8, line 28 skipping to change at page 9, line 11
sufficiently complete and detailed to allow the service definition to sufficiently complete and detailed to allow the service definition to
be incorporated by reference into the specifications for setup be incorporated by reference into the specifications for setup
protocols and other users of the specified data. protocols and other users of the specified data.
NOTE: The wording above is intended to encourage the use of common NOTE: The wording above is intended to encourage the use of common
data formats by all protocols carrying data related to a specific data formats by all protocols carrying data related to a specific
service, while not mandating this common format or infringing on service, while not mandating this common format or infringing on
the freedom of protocol specification designers to define data the freedom of protocol specification designers to define data
representations using alternative mechanisms such as ASN.1 or XDR. representations using alternative mechanisms such as ASN.1 or XDR.
Interfaces Service and Data Element Naming
The service module conceptually interacts with other portions of the End-nodes, network elements, setup protocols, and management entities
network element through a number of interfaces. These interfaces are within an integrated services internetwork frequently need to
documented in [xxx; the non-existent new IS - Overview RFC]. The exchange information about services, service invocation parameters,
service specification document should clearly define each the characterization parameters, and the intermediate variables and end
specific data, including formats, which moves across each conceptual results of composition functions. To support this requirement, a
interface, and ensure that the mapping between conceptual interfaces single uniform namespace is established for services and their
and the specific mechanisms of the service being defined are clear. parameters.
The namespace is a two-level hierarchy:
<service_name>.<parameter_name>.
Each of these elements is a integer numerical quantity.
<Service Name> is an integer in the range 1 to 254. The number space
is broken into two regions. The range from 1 to 127 is managed by the
IANA. Procedures for allocating service numbers in this region will
be established by the IETF INT-SERV WG and the IANA. Services
designed for public use should obtain a number from this space. The
minimum requirement for doing so is a published RFC following the
format described in this note.
Numbers in the region above 127 are reserved for experimental or
private services. Service designers may allocate numbers from this
space at random for local experimental use. A policy for global but
temporary allocation of these numbers may be established in the
future if necessary.
The value 0 is left unused to allow the direct mapping of parameter
names to MIB object names, as described below.
The value 255 is reserved to facilitate future expansion of the
service number space, if required.
<Parameter_name> is a number in the range 1 to 254, allocated on a
per-service basis. Within this range, the values 1 to 16 are
reserved for assignment as "well-known" numbers, representing
parameters common to most or all services. Numbers for parameters
specific to a service are assigned from the range 17-254 by the
author of the service specification document.
The value 0 is left unused to allow the direct mapping of parameter
names to MIB object names, as described below.
The value 255 is reserved to facilitate future expansion of the
parameter number space, if required.
In addition to their uses within the integrated services framework,
these <service_number>.<parameter_number> pairs should be used as
last two levels of the MIB name when the corresponding values are
made available to network management protocols.
Certain values of the namespace are allocated to well-known objects.
The well-known service Number 1 is reserved for the "general"
parameters described above. Parameter numbers within this space are
allocated by IANA.
The well-known parameter number 1 is reserved for the TSpec parameter
in all services, including service 1. The well-known parameter number
2 is reserved for the RSpec parameter in all services, including
service 1. No other well-known parameter numbers are assigned at this
time.
NOTE: Number assignments in the current service specification
documents do not match this description due to parallel
development. The wording here supercedes the assignments in the
current service specification documents.
Specification Document Format Specification Document Format
The following portion of this document describes the layout and The following portion of this document describes the layout and
contents of a service specification. Each service specification contents of a service specification. Each service specification
document MUST contain the sections marked [required] below, in the document MUST contain the sections marked [required] below, in the
order listed. Each document SHOULD contain each of the remaining order listed. Each document SHOULD contain each of the remaining
sections in the list below, unless there is a compelling argument sections in the list below, unless there is a compelling argument
that the presence of the section is not beneficial. Additional that the presence of the section is not beneficial. Additional
material, including references, should be included at the end of the material, including references, should be included at the end of the
document. document.
Some of these sections are normative, in that they describe specific
requirements to which conformant implementations must adhere. Other
sections are informational in nature, in that they describe necessary
context and technical considerations important to the implementor of
a service. The sections, and their nature (required or optional, and
informational or normative) are listed below:
o Components o Components
The body of a service specification document incorporates the The body of a service specification document incorporates the
following sections: following sections:
- Motivation [required] - End-to-End Behavior [required] [informational]
- Network Element Data Handling Requirements [required] - Motivation [required] [informational]
- Invocation Information [required] - Network Element Data Handling Requirements [required] [normative]
- Exported Information [required] - Invocation Information [required] [normative]
- Policing [required] - Exported Information [required] [normative]
- Ordering and Merging [required] - Policing [required] [normative]
- Resulting Service [required] - Ordering and Merging [required] [normative]
- Guidelines for Implementors - Guidelines for Implementors [optional] [informational]
- Evaluation Criteria [required] - Evaluation Criteria [required] [informational]
- Examples of Implementation - Examples of Implementation [optional] [informational]
- Examples of Use - Examples of Use [optional] [informational]
o End-to-end Behavior
This is a description of the behavior that results if all network
elements along the path offer the same service, invoked with a
defined set of parameters.
In private networks it will generally be the case that the required
end-to-end behavior is obtained by concatenation of network elements
utilizing the same service and making significant use of
characterizations.
In the global Internet, this will not always be true. End-to-end
behaviors will frequently be obtained through a concatenation of
network elements supporting different services, including in some
cases elements which exercise no QoS control at all. Mechanisms to
characterize end-to-end behavior in this circumstance are not fully
established at this time. Future versions of this document may impose
additional requirements on service specifications to facilitate
inter-service composition.
This section is for informational purposes only.
o Motivation o Motivation
This section discusses why this service is being defined. It This section discusses why this service is being defined. It
describes what kinds of applications might make use of this service, describes what kinds of applications might make use of this service,
and why this service might be more appropriate for those applications and why this service might be more appropriate for those applications
than other possible choices. This section is for informational than other possible choices. This section is for informational
purposes only. purposes only.
o Network Element Data Handling Requirements o Network Element Data Handling Requirements
skipping to change at page 10, line 20 skipping to change at page 12, line 43
rather than by discarding packets when overloaded". rather than by discarding packets when overloaded".
Requirements on packet handling SHOULD, when at all possible, be Requirements on packet handling SHOULD, when at all possible, be
expressed as performance requirements rather than by specifying a a expressed as performance requirements rather than by specifying a a
particular packet scheduling algorithm. The performance requirements particular packet scheduling algorithm. The performance requirements
might, for example, be a specification of the maximal packet delays might, for example, be a specification of the maximal packet delays
or the minimal bandwidth share given to a flow. or the minimal bandwidth share given to a flow.
This section also specifies actions which the packet handling path is This section also specifies actions which the packet handling path is
required to take to actively provide feedback to end-nodes about required to take to actively provide feedback to end-nodes about
conditions at the network element. Such actions might include the conditions at the network element. Such actions might include
explicitly generated congestion feedback, indicated either as bits explicitly generated congestion feedback, indicated either as bits
set in the header of data packets or separate control messages sent. set in the header of data packets or separate control messages sent.
When writing this section of the service specification document, the When writing this section of the service specification document, the
authors' goal should be to specify the required behavior as precisely authors' goal should be to specify the required behavior as precisely
as necessary while still leaving adequate room for the implementation as necessary while still leaving adequate room for the implementation
and architectural tradeoffs appropriate to different circumstances and architectural tradeoffs appropriate to different circumstances
and classes of network elements. Successfully achieving this balance and classes of network elements. Successfully achieving this balance
may require some care. may require some care.
skipping to change at page 10, line 43 skipping to change at page 13, line 22
This section describes the set of parameters required by a service This section describes the set of parameters required by a service
module to invoke the service, and a description of how the parameter module to invoke the service, and a description of how the parameter
values are used by the service module. For example, a hypothetical values are used by the service module. For example, a hypothetical
"bounded delay" service might be described as accepting a request "bounded delay" service might be described as accepting a request
indicating a delay target for the network element and the set of indicating a delay target for the network element and the set of
packets subject to that delay target, and processing packets in the packets subject to that delay target, and processing packets in the
given set with a delay of the target value or less. given set with a delay of the target value or less.
Necessary invocation information for most services can be broken into Necessary invocation information for most services can be broken into
two parts, the Traffic Specification (TSpec) and the Service Request two parts, the Traffic Specification (TSpec) and the Service Request
Specification (RSpec). The TSpec gives characteristics of the data to Specification (RSpec). The TSpec gives characteristics of the data
be handled, while the Rspec specifies the properties desired from the traffic to be handled, while the Rspec specifies the properties
service. For example, a service offering a mathematical bound on desired from the service. For example, a service offering a
delay might accept a TSpec giving the traffic flow's bandwidth and mathematical bound on delay might accept a TSpec giving the traffic
burstiness specified as a Token Bucket, and an RSpec giving the flow's bandwidth and burstiness specified as a Token Bucket, and an
maximum tolerable queueing delay. These two components of the RSpec giving the maximum tolerable queueing delay.
invocation information should be specified separately and
independently, as they will often be generated and transported by A service accepting an invocation request may be thought of as
different elements of the internetwork entering into a "contract" to provide the service described by the
RSpec as long as the flow's traffic continues to be described by the
TSpec. If the flow's traffic pattern falls outside the bounds of the
TSpec, the QoS provided to the flow may change. The precise nature of
this change is also described by the service specification (see
"Policing" below).
The RSPec and TSpec components of the invocation information should
be specified separately and independently, as they will often be
generated by different elements of the internetwork
All quantitative information specifications in this section should All quantitative information specifications in this section should
follow the guidelines given in the Data Formats section of this follow the guidelines given in the Data Formats section of this
document, above. document, above.
o Exported Information and Characterization Parameters o Exported Information and Characterization Parameters
This section describes information which must be collected and This section describes information which must be collected and
exported by the service module. Exported information is available to exported by the service module. Exported information is available to
other portions of the network element, and by extension to setup other modules of the network element, and by extension to setup
protocols, routing protocols, network management tools, and the like. protocols, routing protocols, network management tools, and the like.
Information exported by service modules may be used in several ways. Information exported by service modules may be used in several ways.
For example, quantities such as the amount of link bandwidth For example, quantities such as the amount of link bandwidth
dedicated to the service and the set of data flows currently dedicated to the service and the set of data flows currently
receiving the service are appropriate pieces of information to make receiving the service are appropriate pieces of information to make
available as network management variables. available as network management variables.
A service definition may identify a particular subset of the A service definition may identify a particular subset of the
information exported by a service module as characterization information exported by a service module as characterization
parameters. These characterization parameters may be used to compute parameters. These characterization parameters may be used to compute
or estimate the end-to-end behavior of a data flow traversing a or estimate the end-to-end behavior of a data flow traversing a
concatenation of network service elements. A service which defines concatenation of network service elements. They may also be used to
characterization parameters also specifies the characterizations they characterize portions of the path for use by network elements (e.g.,
are used to generate and the composition functions used to generate in computing the buffer necessary, an element may need to know
the characterizations. something about the service characteristics of the upstream portion
of the path). A service which defines characterization parameters
also specifies the characterizations they are used to generate and
the composition functions used to generate the characterizations.
NOTE: Characterization parameters are identified as such by virtue NOTE: Characterization parameters are identified as such by virtue
of being the inputs to a service's defined composition functions. of being the inputs to a service's defined composition functions.
Because characterization parameters are part of a service's Because characterization parameters are part of a service's
overall exported data set, they are also available to other overall exported data set, they are also available to other
functions, such as network management. The discussion below functions, such as network management. The discussion below
relates soley to their use as characterization parameters, and is relates solely to their use as characterization parameters, and is
not intended to limit other uses. not intended to limit other uses.
Characterization parameters may be relatively static quantities, such Characterization parameters may be relatively static quantities, such
as the bandwidth available on a specific link, or relatively dynamic as the bandwidth available on a specific link, or relatively dynamic
quantities, such as a running estimation of current packet delay. quantities, such as a running estimation of current packet delay.
Support for a service's defined characterization parameters is Support for a service's defined characterization parameters is
mandatory. Any network element offering this service must be able to mandatory. Any network element offering this service must be able to
measure, compute, or, if allowed by the specification, estimate the measure, compute, or, if allowed by the specification, estimate the
service's characterization parameters. Service designers are service's characterization parameters. Service designers are
skipping to change at page 12, line 18 skipping to change at page 15, line 9
Characterization parameters are used by composing the values exported Characterization parameters are used by composing the values exported
by each network element along a data flow's path according to a by each network element along a data flow's path according to a
composition rule. For each parameter or set of parameters used to composition rule. For each parameter or set of parameters used to
develop a characterization, the service specification must specify develop a characterization, the service specification must specify
the composition rule to be used. These composition rules should the composition rule to be used. These composition rules should
result in characterizations that are independent of the order in result in characterizations that are independent of the order in
which the element are composed; commutativity and associativity are which the element are composed; commutativity and associativity are
sufficient but not necessary conditions for this. sufficient but not necessary conditions for this.
Characterization parameters are available through a general Characterization parameters are available through a general
interface, and are provided in response to a request that would most interface, and are provided in response to a request from some other
likely come from either the setup protocol or the routing protocol. module, such as a setup protocol or the routing protocol. The
The issue of exactly how, or if, a specific protocol (e.g., RSVP) question of exactly how, or if, a specific protocol (e.g., RSVP) uses
uses characterization parameters to generate characterizations should characterization parameters to generate characterizations is
be described in the specification of that specific protocol. described in the specification of that specific protocol.
There is no requirement that setup and routing protocols use the The correct use of characterization parameters supplied by service
characterization parameters supplied by service modules, and there is modules is a function of the setup, routing, or management protocol
no guarantee that characterizations will be available to end-nodes controlling the module. There is no absolute guarantee that
desiring to use a QOS control service. Service designers targeting characterizations will be available to end-nodes desiring to use a
services for the global Internet may wish to ensure that a service is QoS control service. Service designers targeting services for the
useful even in the absence of characterizations, and to exhibit such global Internet may wish to ensure that a service is useful even in
uses in the "Examples" sections of the service description document. the absence of characterizations, and to exhibit such uses in the
"Examples" sections of the service description document.
Conversely, the availability of characterizations may be mandatory in Conversely, the availability of characterizations may be mandatory in
certain circumstances, particularly for private IP networks providing certain circumstances, particularly for private IP networks providing
tightly controlled qualities of service for specific applications. tightly controlled qualities of service for specific applications.
Service designers targeting this environment should particularly Service designers targeting this environment should particularly
ensure that the service provides adequate characterization parameters ensure that the service provides adequate characterization parameters
and composition functions to fully meet the needs of target and composition functions to meet the needs of target audiences. It
audiences. It may be appropriate to specify the same basic service may be appropriate to specify the same basic service with additional
with additional characterizations for meeting specific requirements characterizations for meeting specific requirements beyond those of
beyond those of the global Internet. the global Internet.
It may be useful to define "generic" characterization parameters not Some useful "general" characterization parameters and corresponding
associated with any specific service. These might include the composition rules are not associated with any specific service.
speed-of-light latency of communication links (additive composition These include the speed-of-light latency of communication links and
rule) and available link bandwidth (minimum composition rule). available link bandwidth. These general characterization parameters
Eventually, these generic parameters should be defined in the are defined in (RFC to be announced).
Integrated Services overview document, and incorporated by reference
in the Router Requirements document and the relevant service
specification documents.
Characterization parameters are named, so that protocols which Although every conformant implementation of a service is required to
transport and use these parameters can uniquely identify them. The provide that service's characterization parameters, it is still
namespace is a two-level hierarchy: <service_name>.<parameter_name>; possible that the desired characterization parameters will not be
each of these elements is a numerical quantity. This same namespace available for composition at all network elements in a path. This
is used to name the results of composition functions which are made situation may arise when different network element services are used
available to end-nodes. The service specification author may also at different points in the end-to-end path, as may be required in a
choose to name intermediate data which might be transported as part heterogeneous internetworking environment. For this reason,
of a distributed composition function computation. The reason for characterization parameters and composition function results
assigning names to these data objects is to support a variety of conceptually include a "validity flag". A network element which is
styles for calculating the composition function, and to ensure that unable to provide the characterization parameter must set this flag,
the end-nodes can clearly determine the meaning of data delivered to and otherwise leave parameter or composed value unchanged. Once set,
them as part of a characterization. the flag is preserved by the composition function, and serves as an
indicator of the validity of the data when the final composed result
is delivered to its destination.
- <Service Name> is a 16-bit number. The number space is broken Protocols which transport characterization parameters and composition
into two regions. The region below 32768 (high bit 0) is managed by data must define and support a concrete representation for this
the IANA. Procedures for allocating service numbers in this region validity flag, as well as for the characterization parameters
will be established by the IETF INT-SERV WG and the IANA. Services themselves.
designed for public use should obtain a number from this space; the
minimum requirement is a published RFC following the format
described in this note.
Numbers in the region above 32768 are reserved for experimental or NOTE: This service specification template does not allow a service
private services. Service designers may allocate numbers from this definition to *require* that a setup or invocation mechanism used
space at random for local experimental use. A policy for global but with the service perform any function other than transport of
temporary allocation of these numbers may be appropriate in the invocation parameters to the network elements and signalling of
future. errors generated by the network elements to the end nodes. A notable
example of this is that service specification documents may not
require or assume that characterizations defined in the specification
are actually computed or presented to the end nodes.
- <Parameter_name> is a 16-bit number assigned on a per-service Further, the current integrated services architecture does not
basis. Numbers are allocated by the author of the service provide a way for the invoking protocol to deliver any information to
specification document. the service module about the availability of capabilities such as the
support for characterizations.
[ Is 16 bits too big? Could be 8.8, or a non-byte split such as That point notwithstanding, the practical usefulness of a specific
6.10 ] service may be highly dependent on the presence of some additional
behavior in the networked system, such as the computation and
presentation of characterizations to end-nodes or the reliable
assurance that every network element in the path from sender to
receivers supports the given service. Service specification authors
are strongly encouraged to clearly explain the situation of their
service in this regard. Statements such as:
Service Number 0 (zero) is reserved for the "generic" parameters The characterizations defined by this service serve as useful
described above. Parameter numbers within this space are initially hints to the application. However, the service is specifically
allocated by the INT-SERV WG, and may in the future be allocated by intended to be useful even if characterizations are not available.
IANA.
These <service_number>.<parameter_number> pairs should be used as or
last two levels of the MIB name when the parameters are made
available to network management protocols. The usefulness of this service depends strongly on the delivery of
both characterizations and the knowledge that all network elements
on the path support the service. Requests for this service when
characterizations are not available are likely to lead to
incorrect or misleading results.
are appropriate. It may also be useful to consider this point in the
"Examples of Use" section described below.
NOTE: The possibility of modifying the overall architecture to
provide information about the invoking protocol in a service request,
and to allow a service to require that the invocation protocol
support specific additional functionality, is an area of active
study.
o Policing o Policing
This portion of the service description describes the nature of This portion of the service description describes the nature of
policing used to enforce adherence to a flow's Traffic Specification. policing used to enforce adherence to a flow's Traffic Specification.
The specification document must specify the following points The specification document must specify the following points
- Expected policing action. This is the action taken when packets - Expected policing action. This is the action taken when packets
not conforming to the TSpec are detected. Example actions include not conforming to the TSpec are detected. Example actions include
immediately dropping nonconforming packets, delaying these packets relegating nonconforming packets to best effort, immediately
until they once again "fit" into the TSpec, or "marking" dropping nonconforming packets, delaying these packets until they
nonconforming packets in some way, to enable dropping them once again "fit" into the TSpec, or "marking" nonconforming packets
preferentially if a later network element in the marked packet's in some way.
path should be overloaded.
- Legality of alternative policing actions. The section must - Legality of alternative policing actions. The section must
specify whether actions not specifically mentioned in specify whether actions not specifically mentioned in
specification's description of policing behavior are legal. For specification's description of policing behavior are legal. For
example, a service description which specifies that nonconforming example, a service description which specifies that nonconforming
packets are to be dropped should state whether an alternate action, packets are to be dropped should state whether an alternate action,
such as delaying these packets, is acceptable. such as delaying these packets, is acceptable.
- Location of policing actions in the internetwork. The description - Location of policing actions in the internetwork. The description
of policing must specify where that policing is done. Possibilities of policing must specify where that policing is done. Possibilities
include "at the edges of the network only", "at every hop", and include "at the edges of the network only", "at every hop",
"source merge points" (points where multiple data streams covered "heterogeneous branch points" (points where the branches of a
by a single resource reservation converge). The specification multicast tree converge and have different TSpecs reserved
should clearly state requirements about topology information (for downstream), and "source merge points" (points where multiple data
example "this is an edge node" or "this is a source merge point") streams covered by a single resource reservation converge). The
which must be available from the setup protocol or another source. specification should clearly state requirements about topology
information (for example "this is an edge node" or "this is a
source merge point") which must be available from the setup
protocol or another source.
In this section the specification should also specify the legality In this section the specification should also specify the legality
of policing at additional points in the network, beyond those of policing at additional points in the network, beyond those
listed above. This is important due to technical effects such as listed above. This is important due to technical effects such as
are described in the next paragraph. are described in the next paragraph.
- Applicable additional technical considerations. If policing of - Applicable additional technical considerations. If policing of
data flows is required or legal at points other than the flow's data flows is required or legal at points other than the flow's
first entry into the network, the service definition should first entry into the network, the service definition should
describe any additional technical considerations which affect the describe any additional technical considerations which affect the
skipping to change at page 15, line 15 skipping to change at page 18, line 25
allow a data flow to become more bursty as it progresses through allow a data flow to become more bursty as it progresses through
the network. If such a service allows policing at points other than the network. If such a service allows policing at points other than
the network edge, the traffic specification describing the flow the network edge, the traffic specification describing the flow
will have to be modified from that given by the application to the will have to be modified from that given by the application to the
network to account for this growing burstiness. Otherwise, it is network to account for this growing burstiness. Otherwise, it is
likely that the flow will be overpoliced, with packets being likely that the flow will be overpoliced, with packets being
penalized unnecessarily. penalized unnecessarily.
o Ordering and Merging o Ordering and Merging
Ordering and merging come into play when a service receives several Ordering and merging come into play when a network element receives
invocation requests covering the same data flow. As examples, this several invocation requests covering the same data flow. As examples,
could occur if several receivers of a multicast data flow requested this could occur if several receivers of a multicast data flow
QOS services for that flow using the RSVP setup protocol, or if a requested QoS services for that flow using the RSVP setup protocol,
flow was subject to both a statically installed permanent invocation or if a flow was subject to both a statically installed permanent
request and a dynamic request from a resource setup protocol. invocation request and a dynamic request from a resource setup
protocol.
In this situation the service module must be able to answer questions In this situation the service module must be able to answer questions
about the ordering between different invocation requests, and must be about the ordering between different invocation requests, and must be
able to generate a single new invocation request which meets the able to generate a single new invocation request which meets the
requirements of all the original requesters. This new request is a requirements of all the original requesters. This new request is a
"merged" request. It may be equal to one of the original requests, or "merged" request. It may be equal to one of the original requests, or
it may be a newly computed request. Operationally, this is achieved it may be a newly computed request. Operationally, this is achieved
by having the setup protocol ask the service module, given a set of by having the invoking protocol ask the service module, given a set
requests R1...Rn, to compute an merged request which which results in of invocation requests I1...In, to compute an merged request which
service to the merged flow at least equivalent to that which any of results in service to the merged flow at least equivalent to that
the original requests would obtain for its corresponding unmerged which any of the original requests would obtain for its corresponding
flow. Hence, the merged invocation request represents an "upper unmerged flow. Hence, the merged invocation request represents an
bound" on the set of original invocation requests. This upper bound "upper bound" on the set of original invocation requests. This upper
calculation must be performed by the service module because it is bound calculation must be performed by the service module because it
specific to a particular service. is specific to a particular service.
The calculated upper bound need not be a least upper bound, nor do The calculated upper bound need not be a least upper bound, nor do
the various network elements along the path need to all use the same the various network elements along the path need to all use the same
choice of upper bound. Any selection of invocation parameters Ru is choice of upper bound. Any selection of invocation parameters Iu is
compliant as long as it substitutable for each of the parameters compliant as long as it substitutable for each of the parameters
R1...Rn from which it is calculated. Intuitively, one set of I1...In from which it is calculated. Intuitively, one set of
parameters is substitutable for another if the resulting quality of parameters is substitutable for another if the resulting quality of
service is at least as desirable to all applications. A precise service is at least as desirable to all applications. A precise
definition of this "substitutable for" function; the ordering definition of this "substitutable for" function; the ordering
relation, MUST be specified in the service definition. (It may be relation, MUST be specified in the service definition. (It may be
specified as the empty set, in which case merging of dissimilar specified as the empty set, in which case merging of dissimilar
requests will not be allowed). A merging computation (upper bound requests will not be allowed). A merging computation (upper bound
calculation) MAY be given in the document as well. calculation) MAY be given in the document as well.
Typically the ordering relation will be described separately for the Typically the ordering relation will be described separately for the
service's TSpec and RSpec. An invocation request is ordered with service's TSpec and RSpec. An invocation request is ordered with
skipping to change at page 16, line 31 skipping to change at page 19, line 42
spelled out explicitly in the service description. spelled out explicitly in the service description.
This portion of the service description may also note any ordering This portion of the service description may also note any ordering
relationships with other services which are strictly ordered with relationships with other services which are strictly ordered with
respect to the service being defined. Two services A and B are respect to the service being defined. Two services A and B are
strictly ordered if it is always possible to substitute service B for strictly ordered if it is always possible to substitute service B for
the service A given a set of invocation parameters for service A. the service A given a set of invocation parameters for service A.
This ordering information may be used to allow network elements which This ordering information may be used to allow network elements which
provide service B to respond to requests for service A, even if the provide service B to respond to requests for service A, even if the
element does not provide service A directly. If the service element does not provide service A directly. If the service
specification describes such an inter-service ordering, it SHOULD specification describes such an inter-service ordering, it MUST also
also include a description of the invocation parameter mapping include a description of the invocation parameter mapping function
function for that ordering. for that ordering.
Substitution of of one service for another in cases where they are Substitution of of one service for another in cases where they are
not strictly ordered is currently not supported. A future version of not strictly ordered is currently not supported. A future version of
this document may augment the service specification format to support this document may augment the service specification format to support
this capability. this capability.
o End-to-end Behavior
This is a description of the behavior that results if all network
elements along the path offer the same service, invoked with a
defined set of parameters. This section should be as detailed as
possible. There are certain services where the end-to-end behavior
is a highly nontrivial result of the concatenation of per-hop
services; one purpose of this section is that such nontrivial results
are not left unrevealed to the reader of this document.
In private networks it will generally be the case that the required
end-to-end behavior is obtained by concatenation of network elements
utilizing the same service and making significant use of
characterizations.
In the global Internet, this will not always be true. End-to-end
behaviors will frequently be obtained through a concatenation of
network elements supporting different services, including in some
cases elements which exercise no QoS control at all. Mechanisms to
characterize end-to-end behavior in this circumstance are not fully
established at this time. Future versions of this document may impose
additional requirements on service specifications to facilitate
inter-service composition.
NOTE: This service specification template does not allow a service
definition to -require- that a setup or invocation mechanism used
with the service perform any function other than transport of
invocation parameters to the network elements and signalling of
errors generated by the network elements to the end nodes. A
notable example of this is that service specification documents
may not require or assume that characterizations defined in the
specification are actually computed or presented to the end nodes.
That point notwithstanding, the practical usefulness of a specific
service may be highly dependent on the presence of some additional
behavior in the networked system, such as the computation and
presentation of characterizations to end-nodes or the reliable
assurance that every network element in the path from sender to
receivers supports the given service. Service specification
authors are strongly encouraged to clearly explain the situation
of their service in this regard. Statements such as:
"The characterizations defined by this service serve as useful
hints to the application. However, the service is specifically
intended to be useful even if characterizations are not
available.
or
The usefulness of this service depends strongly on the delivery
of both characterizations and the knowledge that all network
elements on the path support the service. Requests for this
service when characterizations are not available are likely to
lead to incorrect or misleading results.
are appropriate. It may also be useful to consider this point in
the "Examples of Use" section described below. ]
NOTE: The possibility of adopting alternative wording for this
document which allows a service to require that the invocation
protocol support specific additional functionality or return an
error is a topic open to discussion.
o Guidelines for Implementors o Guidelines for Implementors
Many services may be defined in a manner which allows the range of Many services may be defined in a manner which allows the range of
behavior of a compliant network element to be rather broad. This behavior of a compliant network element to be rather broad. This
section should provide some guidance as to what range of behaviors section should provide some guidance as to what range of behaviors
the author of the service specification expects the community to the author of the service specification expects the community to
desire in their implementations. Because these guidelines depend on desire in their implementations. Because these guidelines depend on
such imprecise and undefinable notions at "typical loads", these such imprecise and undefinable notions at "typical loads", these
guidelines cannot be incorporated as part of a strict compliance guidelines cannot be incorporated as part of a strict compliance
test. Instead, they are for informational purposes only. test. Instead, they are for informational purposes only.
skipping to change at page 19, line 14 skipping to change at page 21, line 5
behavior obtained, which will depend not just on the particular behavior obtained, which will depend not just on the particular
network elements selected, but also on other factors such as the network elements selected, but also on other factors such as the
setup protocol and the bandwidth of the links. Some user-relevant setup protocol and the bandwidth of the links. Some user-relevant
performance factors are the rate of admission control rejections, the performance factors are the rate of admission control rejections, the
range of services offered, and the packet delay and drop rates in the range of services offered, and the packet delay and drop rates in the
various service classes. The form of any standardized end-to-end various service classes. The form of any standardized end-to-end
metrics and measurement tools for integrated service internetworks is metrics and measurement tools for integrated service internetworks is
not specified by this document or by service specification document not specified by this document or by service specification document
which follow the format given here. which follow the format given here.
This section is for informational purposes only.
o Examples of Implementation o Examples of Implementation
This section describes example instantiations of the service. Often This section describes example instantiations of the service. Often
these will just be references to the literature, or brief sketches of these will just be references to the literature, or brief sketches of
how the service could be implemented. The purposes of the section how the service could be implemented. The purposes of the section
are to to provide a more concrete sense of the service being are to to provide a more concrete sense of the service being
specified and to provide pointers and hints to aid the implementor. specified and to provide pointers and hints to aid the implementor.
However, the descriptions in this section are specifically not However, the descriptions in this section are specifically not
intended to exclude other implementation strategies. intended to exclude other implementation strategies.
This section is for informational purposes only.
o Examples of Use o Examples of Use
In order to provide more a more concrete sense of how this service In order to provide more a more concrete sense of how this service
might be used, this section describes some example uses of the might be used, this section describes some example uses of the
service, for informational purposes only. The examples here are not service, for informational purposes only. The examples here are not
meant to be exhaustive, and do not exclude in any way other uses of meant to be exhaustive, and do not exclude in any way other uses of
the service. the service.
This section is for informational purposes only.
Security Considerations Security Considerations
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
References
1. C. Partridge, Gigabit Networking, Addison Wesley Publishers
(1994).
Authors' Address: Authors' Address:
Scott Shenker Scott Shenker
Xerox PARC Xerox PARC
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304-1314 Palo Alto, CA 94304-1314
shenker@parc.xerox.com shenker@parc.xerox.com
415-812-4840 415-812-4840
415-812-4471 (FAX) 415-812-4471 (FAX)
 End of changes. 67 change blocks. 
316 lines changed or deleted 420 lines changed or added

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