Subject: Flowspec format document

From: John Wroclawski <[email-masked]>
Date: Thu, 20 Jul 1995 16:58:10 -0400

At the WG meeting this afternoon we discussed a format for flow
specifications. Here's a little document describing that format. There
are two small changes from the version discussed at the meeting: the
LENGTH field is larger (allowing 16K rather than 1K flowspecs) and the
header fields were reordered to acomodate the larger length field.

This document needs to hit the standards track at the same time as
RSVP and the service specifications - please send any comments to the
list. Thanks, -john

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                             J. Wroclawski
draft-ietf-intserv-flowspec-fmt-00.txt                           MIT LCS
                                                              July, 1995
                                                           Expires: 1/96

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
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

This document is a product of the Integrated Services working group of
the Internet Engineering Task Force.  Comments are solicited and
should be addressed to the working group's mailing list at
[email-masked] and/or the author(s).

Abstract

This note gives a format for "flow specifications"; the information
used to describe traffic and resource reservation characteristics in
the Integrated Services architecture. The note describes the
service-independent portion of the flow specification, and explains
how service-specific information is incorporated into the complete
flowspec.

Introduction

This note describes a format for flow specifications. A flow
specification holds information about a traffic flow and the packet
forwarding service it requires. Most commonly, this information
originates at the hosts running an application and is carried to
network elements inside the network by a setup protocol such as RSVP
[RSVP] or ST-II [STII]. However, other patterns of use are possible.

A flow specification ("flowspec") may in general carry two kinds of
information. The first kind is a specification of the traffic pattern
which a flow expects to exhibit. The second type is a specification of
the packet forwarding service a flow desires from a network element.
These two classes of information are referred to as TSpecs and RSpecs,
respectively, in [service template doc].

The TSpec(s) and Rspec(s) associated with a given traffic flow may or
may not originate at the same host. For example, in a receiver-based
resource reservation model such as that of RSVP, senders of data also
emit a TSpec for the data they send, while receivers of data emit an
RSpec describing the service they wish to receive.

The specific parameters carried by a flow specifier are determined by
the service being requested from the network. The definition of data
representation formats for a service's TSpecs and RSpecs is a function
of the service's specification document, as is the definition of how
the spec are utilized by the service, and whether both TSpecs and
RSpecs are required to invoke the service. The function of this note
is to describe an overall syntax for flow specifiers which can be used
to represent the TSpecs and RSpecs of any service for transmission
within a network.

Following the model of [service template doc], the syntax of flowspecs
is described here both in abstract terms and with a suggested concrete
format. The intention is to lay out a common packet format for those
protocols which desire to use it, but not mandate that this format be
used when another representation, such as one generated by an ASN.1 or
XDR description of the flowspec, would be more appropriate for a
specific protocol.

Abstract Requirements

Flow specifiers are not likely to be interpreted as part of in-band
per-packet processing. Thus, processing speed is not of paramount
concern.

Any flowspec representation must do three things:

1) Indicate the service associated with the flowspec (using the
service numbering scheme described in [service template doc]). This
service determines the definition of the specific parameters within
the flowspec.

2) Carry any flags needed to parse the flowspec into the specific
parameters defined by the service. One use of these flags is to
indicate whether the flowspec is carrying a TSpec, an RSpec, or both.
(Note that not all services will define the concept of TSpecs and
RSpecs as separate entities).

3) Carry the actual parameters defined by the service.

It is reasonable to assume that the number of defined services will be
limited to less than 255 with high probability, and less than 65535
with certainty. Services are specified using the service_name numbers
described in [template doc yet again].

At least 6 binary flags should be available. Four of these are
currently allocated to specific purposes. These are:

TSpec_present		- This flowspec contains a TSpec

RSpec_present		- This flowspec contains an RSpec

Service_specifc_1	- The meaning of this flag is determined by
			  the flowspec's associated service and defined
			  in the service specification.

Service_specifc_2	- The meaning of this flag is determined by
			  the flowspec's associated service and defined
			  in the service specification.

Two additional flags are reserved for future definition.

Concrete Format

This section defines a concrete bit-level format for flow specifiers.
This format may be incorporated by reference in any protocol document
desiring to do so.

The representation is self-parsing. Readers can skip over flowspecs
for services they do not support or understand. This allows a number
of flowspecs to be placed in a datastructure without additional
framing, and supports the incremental deployment of new services. For
example, RSVP could put a list of flowspecs (say, a list of service
options for a resource request) inside a single RSVP "Flowspec"
object.

In the description below, all fields described below are drawn and
transmitted in big-endian "network byte order".

The representation consists of version and length fields, 8 flag bits,
and a service specifier, followed by the service-specific parameters.
All service- specific parameters of size 32 bits or less are aligned
to their natural boundaries by padding with zero bytes if required.
Parameters of size greater than 32 bits are aligned to 32-bit
boundaries. If the last service-specific parameter does not end on a
32 bit boundary the flowspec is padded to this boundary with zero
bytes.

Ordering for the service-specific parameters within a flowspec is
given in each service specification document. Service specification
document authors should specify a transmission order for parameters
which minimizes the amount of zero-padding needed due to the alignment
requirements of this format.

When a flowspec may optionally contain either a TSpec, an RSpec, or
both, the TSpec is carried first if both are present.

                                     S S T R
                                     S S S S
    31                               1 2 P P                       0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | V |         LENGTH            |    FLAGS      |   SERVICE     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 16-bit svc_specific param 1   |	   zero padding             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               32-bit svc_specific param 2                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 16-bit svc_specific param 3   | 16-bit svc_specific param 4   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 16-bit svc_specific param N   |	   zero padding             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V		Flowspec version; currently 0

SVC		Service ID.

FLAGS		Currently:
	  	SS1 (bit 15) - service_specific flag #1.
	  	SS1 (bit 14) - service_specific flag #2.
	 	TSP (bit 13) - TSpec present.
	  	RSP (bit 12) - RSpec present.
	  	All others 0

LENGTH		Flowspec length. The length is specified as the number of
		32-bit words in the flowspec, not including the header word.
		The field is interpreted as an unsigned number, giving
                a maximum flowspec size of 16384 bytes.

Security Considerations

   Security considerations are not discussed in this memo.

AuthorUs Address:

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139
   [email-masked]
   617-253-7885
   617-253-2673 (FAX)