A Proposed Flow Specification
RFC 1363
|
Document |
Type |
|
RFC - Informational
(September 1992; No errata)
|
|
Author |
|
Craig Partridge
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1363 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group C. Partridge
Request for Comments: 1363 BBN
September 1992
A Proposed Flow Specification
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
A flow specification (or "flow spec") is a data structure used by
internetwork hosts to request special services of the internetwork,
often guarantees about how the internetwork will handle some of the
hosts' traffic. In the future, hosts are expected to have to request
such services on behalf of distributed applications such as
multimedia conferencing.
The flow specification defined in this memo is intended for
information and possible experimentation (i.e., experimental use by
consenting routers and applications only). This RFC is a product of
the Internet Research Task Force (IRTF).
Introduction
The Internet research community is currently studying the problems of
supporting a new suite of distributed applications over
internetworks. These applications, which include multimedia
conferencing, data fusion, visualization, and virtual reality, have
the property that they require the distributed system (the collection
of hosts that support the applications along with the internetwork to
which they are attached) be able to provide guarantees about the
quality of communication between applications. For example, a video
conference may require a certain minimum bandwidth to be sure that
the video images are delivered in a timely way to all recipients.
One way for the distributed system to provide guarantees is for hosts
to negotiate with the internetwork for rights to use a certain part
of the internetwork's resources. (An alternative is to have the
internetwork infer the hosts' needs from information embedded in the
data traffic each host injects into the network. Currently, it is
not clear how to make this scheme work except for a rather limited
set of traffic classes.)
Partridge [Page 1]
RFC 1363 A Proposed Flow Specification September 1992
There are a number of ways to effect a negotiation. For example a
negotiation can be done in-band or out-of-band. It can also be done
in advance of sending data (possibly days in advance), as the first
part of a connection setup, or concurrently with sending (i.e., a
host starts sending data and starts a negotiation to try to ensure
that it will allowed to continue sending). Insofar as is possible,
this memo is agnostic with regard to the variety of negotiation that
is to be done.
The purpose of this memo is to define a data structure, called a flow
specification or flow spec, that can be used as part of the
negotiation to describe the type of service that the hosts need from
the internetwork. This memo defines the format of the fields of the
data structure and their interpretation. It also briefly describes
what purpose the different fields fill, and discusses why this set of
fields is thought to be both necessary and sufficient.
It is important to note that the goal of this flow spec is to able to
describe *any* flow requirement, both for guaranteed flows and for
applications that simply want to give hints to the internetwork about
their requirements.
Format of the Flow Spec
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Maximum Transmission Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate | Token Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Rate | Minimum Delay Noticed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Delay Variation | Loss Sensitivity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Loss Sensitivity | Loss Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discussion of the Flow Spec
The flow spec indicates service requirements for a single direction.
Multidirectional flows will need to request services in both
directions (using two flow specs).
To characterize a unidirectional flow, the flow spec needs to do four
things.
Partridge [Page 2]
Show full document text