Subject: new version of data encodings I-D

From: John Wroclawski <[email-masked]>
Date: Tue, 12 Dec 1995 14:51:27 -0500

Hi,
Enclosed is a new version of the "data encodings" I-D, which gives
some rules for stuffing int-serv data objects into packets.

The only changes between this and the previous version are bugfixes
and editorial corrections. The previous version was circulated to the
mailing list, but apparently did not make it onto the I-D ftp
sites. This version should be available from those sites shortly.

		-john

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                             J. Wroclawski
draft-ietf-intserv-data-encoding-01.txt                          MIT LCS
                                                          November, 1995
                                                           Expires: 6/96

         Standard Data Encoding for Integrated Services Objects

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 draft 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 int-
   [email-masked] and/or the author(s).

Abstract

      A number of data objects must be transmitted between end-nodes and
      network elements to support resource reservation in an integrated
      services internet. This document provides some background
      requirements and specifies preferred transmission encodings for
      these objects, which include RSpecs, TSpecs, characterization
      paramters, and composition function intermediate parameters.

J. Wroclawski                 Expires 6/96                      [Page 1]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

Introduction

   Support for end-to-end resource reservation and controlled qualities
   of service requires that several types of information be communicated
   between end-nodes and intermediate network elements. This information
   may include characterizations of the traffic to be sent over that
   path, requests for a specific level of service, characterizations of
   the chosen data path, and other related data.

   The specifics of this communication depend heavily on the mechanisms
   being used to set up and reserve resources for QoS-controlled paths.
   The same integrated services building blocks may be used to support a
   range of different setup protocols, reservation styles, and
   management functions. Data and message formats designed for use with
   these building blocks must be able to support this varied use.

   This note provides some background information about the requirements
   of the integrated services data transport formats. It then describes
   a general set of encoding rules which, together with the information
   contained in a particular service specification document, specify the
   preferred wire encoding format for the data associated with that
   service. Finally, it gives some usage examples for these rules.

Background and Requirements

   Current IETF integrated services documents discuss four types of data
   objects:

     - Traffic Specifications, or TSpecs, describe a flow of data
     traffic. This may be the traffic generated by a data source, the
     traffic expected by a data receiver, or the traffic subject to a
     resource reservation at an intermediate network element.

     - Request Specifications, or RSpecs, describe a request for a
     specific QoS control service. This may be request being placed by
     an application or end-node, or it may be a request delivered to a
     particular intermediate network element.

     - Characterization Parameters are specific parameters made
     available by the service module at an end-node or intermediate
     network element for the purpose of characterizing the end-to-end
     QoS delivered over a data path. The parameters made available by a
     service module are a function of the service that module
     implements.

J. Wroclawski                 Expires 6/96                      [Page 2]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

     - Composition variables are the intermediate variables and end
     results of composition functions; the functions which process per-
     hop characterization parameters to compute end-to-end path
     characterizations.

        NOTE: Traffic Specifications, Request Specifications and
        Characterization Parameters are defined further in [the template
        document]. The phrase "Composition Variables", or equivalent, is
        not currently defined in current version of that document, but
        will be included inthe next version.

        NOTE: Additional types of data objects may be defined in the
        future.

     These objects may be used in a variety of different ways, depending
     on the situation. Some examples are listed below:

       - A routing protocol might query network elements for certain
       characterization parameters, such as link bandwidth or delay.
       This protocol would make no use of RSpecs or TSpecs, and may or
       may not use composition variables.

       - A management station setting up a quasi-permanant flow might
       transmit RSpecs (specifying the requested service) and TSpecs
       (specifying the level of traffic for which the service is
       requested) directly from a central point to each of a number of
       network elements.

       - A one-pass receiver based resource reservation protocol such as
       RSVP might do the following:

         o Transmit TSpecs describing each sender's traffic from the
         sender to intermediate network elements.

         o Compute end-to-end characterizations in the sender-to-
         receiver direction, by collecting characterization parameters
         at the sending end-node and intermediate elements, executing
         composition functions at the intermediate nodes, and
         transmitting composition variables from senders towards
         receivers.

         o Transmit an RSpec (describing each receiver's desired
         reservation request) and a TSpec (describing the traffic
         parameters for which each receiver desires this level of

J. Wroclawski                 Expires 6/96                      [Page 3]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

         service) from each receiver to intermediate network elements.

         o Compute an appropriate RSpec and TSpec for each network
         element, based on the protocol's rules, and attempt to reserve
         resources based on that RSpec and TSpec.

       - A two-pass sender-based setup protocol such as ST-II might do
       the following:

         o On pass one, transmit each sender's RSpec (describing the
         sender's service request) and TSpec (describing the sender's
         traffic generation pattern) into the network.

         o On pass one, compute end-to-end characterizations in the
         sender-to-receiver direction, by collecting characterization
         parameters at the sending end-node and intermediate elements,
         executing composition functions at the intermediate nodes, and
         transmitting composition variables from senders towards
         receivers.

         o Between passes, compute a final RSpec and TSpec for the
         resource reservation request, based on information collected in
         pass one.

         o On pass two, carry the final RSpec and TSpec from the
         receiver towards the sender, placing reservations using these
         parameters.

     These differing examples show that a single protocol message may
     contain one, some, or all of these data objects. For this reason,
     the format described below is self-parsing at the object level.

     The examples also show that a single protocol message may be
     required to carry objects relating to several services at the same
     time. For example, a one-pass reservation protocol such as RSVP may
     transport composition variables for several services from sender to
     receiver to more fully characterize the path. For this reason, the
     format described below has a two-level structure which can carry
     objects from multiple services simultaneously.

Message Format

   This section describes the preferred wire format for protocol
   messages used to transmit integrated services data objects. It

J. Wroclawski                 Expires 6/96                      [Page 4]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

   provides rules constructing the overall data format for carrying
   integrated messages. The data contained *within a specific object* is
   unique to the service defining the object, and is described in the
   service definition. To fully interpret a message, the recipient must
   understand both the overall format presented here and the data
   objects defined by the specific service. However, the format is
   self-parsing at the service level, so that objects belonging to an
   unknown service may be ignored entirely.

   All fields described below are drawn and transmitted in big-endian
   "network byte order".

   The overall representation consists of a 32-bit header specifying the
   version number and total length of the message, followed by any
   number of service-specific data blocks. The overall message must be
   aligned to a 32-bit boundary within the protocol's data packet.  The
   message length is measured in 32-bit words *not including the word
   containing the header*.

   Each service-specific data block begins with a 16-bit header
   containing the service number and length field, followed by the
   service-specific parameters. The length field specifies the number of
   32-bit words used to hold data specific to this service as a count of
   32-bit words *not including the word containing the header*. Note
   that the alignment rules described below ensure that the 16-bit
   service header will always be aligned to a 32-bit boundary.

   Each parameter within a service-specific data block is identified by
   a 16-bit parameter-id header containing the parameter identifier
   (parameter number) and a flag field. The data field(s) of the
   parameter follow.  The parameter's ID number, as well as the meaning,
   data format, and location of each data field within the parameter,
   are given by the specification which defines the parameter.  The
   placement and alignment of a parameter's data fields within the
   message is specified by the alignment rules below.

   Within a service-specific data block, parameter headers and parameter
   data fields are aligned to their natural boundaries (16 bit fields
   aligned to a 16 bit boundary, etc.) by pre-padding with zero bytes if
   required. Note that this implies that parameter headers are aligned
   only to the nearest 16-bit boundary. Within a service-specific data
   block, all parameter headers after the first may appear in either the
   high-order or low-order 16 bits of a 32-bit word, depending on where
   the data field(s) of the previous parameter end.

   If the last field of the last parameter in a service-specific data
   block does not end on a 32 bit boundary the data block is padded to
   the next 32-bit boundary with zero bytes.

J. Wroclawski                 Expires 6/96                      [Page 5]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

   Message Header Field

       31    28 27                   16 15                            0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | V     |    Unused             |     OVERALL LENGTH            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   V               - Flowspec version; currently 0
   OVERALL LENGTH  - Overall length in 32-bit words not including header

   Service-Specific Data Header Field

       15             8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  SVC_NUMBER   |  LENGTH       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SVC_NUMBER      - Service ID number (defined in service specification)
   LENGTH          - Service-specific data length in 32-bit words,
                     not including header.

   Parameter-ID Header

       15             8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PARAM_NUM    |   PARAM_FLAGS |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        I
                        n
                        v

   PARAM_NUM       - Parameter ID number (defined in service specification)
   PARAM_FLAGS     - Flags. Currently:
                     INV (Invalid) (bit 7) - This parameter may be invalid.

Examples

   Shown below is an example message carrying both a TSpec (parameter 1)
   and RSpec (parameter 2) for service number 2. This message might be
   contained within a FLOWSPEC object in the RSVP protocol.

J. Wroclawski                 Expires 6/96                      [Page 6]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 0 (a) |    Unused             |            5 (b)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     2 (c)     |    4 (d)      |    1 (e)      |     0 (f)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 16-bit TSpec field            |      zero padding             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    32-bit TSpec field                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 16-bit TSPec field            | 16-bit TSpec field            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     2 (g)     |    0 (h)      |   16-bit RSpec field          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Version number (0)
     (b) - Overall length (6 words not including header)
     (c) - Service header, service number 2
     (d) - Length of per-service data, 5 words not including header
     (e) - Parameter ID, parameter 1 (TSpec)
     (f) - Parameter 1 flags (none set)
     (g) - Parameter ID, parameter 2
     (h) - Parameter 2 flags (none set)

   Shown below is an example message carrying characterization
   information for two different services simultaneously.  This message
   might be contained within an ADSPEC object in the RSVP protocol.

        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 0 (a) |    Unused             |            7 (b)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     10 (c)    |    3 (d)      |    17 (e)     |     0 (f)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        32-bit characterization parameter value                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     18 (g)    |1(h)           |       zero padding            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        32-bit characterization parameter value                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     11 (i)    |    2 (j)      |    17 (k)     |     0 (l)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   16-bit parameter 17 value   |    18 (m)     |     0 (n)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   16-bit parameter 18 value   |         zero padding          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

J. Wroclawski                 Expires 6/96                      [Page 7]
INTERNET-DRAFT  draft-ietf-intserv-data-encoding-01.txt   December, 1995

     (a) - Version number (0)
     (b) - Overall length, 7 words not including header
     (c) - Service header, indicates service number 10
     (d) - Length of per-service data, 3 words not including header
     (e) - Parameter ID, indicates characterization parameter 17
     (f) - Parameter 17 flags (none set)
     (g) - Parameter ID, indicates characterization parameter 18
     (h) - Parameter 18 flags. INVALID flag set.
     (i) - Service header, indicates service number 11
     (j) - Length of per-service data, 2 words not including header
     (k) - Parameter ID, indicates characterization parameter 17
     (l) - Parameter 17 flags (none set)
     (m) - Parameter ID, indicates characterization parameter 18
     (n) - Parameter 18 flags (none set)

Security Considerations

   Security considerations are not discussed in this memo.

Authors' Address:

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

J. Wroclawski                 Expires 6/96                      [Page 8]

---

From: [email-masked]
Date: Wed, 13 Dec 1995 16:54:39 -0800

John,

I oppose adding redundant information and gratuitous code because your
flowspec might be used with some other protocol that has no object
encapsulation.  Others in the int-serv working group are encouraged
to comment on this.

  *> 
  *> Then there are situations such as the one shown in the picture below
  *> 
  *>       o    Class = 9, C-Type = 254:  Unmerged Flowspec List
  *> 
  *>            +-------------+-------------+-------------+-------------+
  *>            //                 FLOWSPEC object  1                  //
  *>            +-------------+-------------+-------------+-------------+
  *>            //                 FLOWSPEC object  2                  //
  *>            +-------------+-------------+-------------+-------------+
  *>            //                                                     //
  *>            +-------------+-------------+-------------+-------------+
  *>            //                 FLOWSPEC object  k                  //
  *>            +-------------+-------------+-------------+-------------+
  *> 
  *> where you are packing several intserv data objects into the same
  *> message. The message header gives you a way to do that without any
  *> additional framing mechanism from the higher-level protocol.
  *> 

First, I expect this RSVP object type to be dropped from the spec, in
favor of internal structure within a flowspec.  Your comment presumably
assumes this, and suggests that you need your internal header to allow
such structure.  But, as I pointed out, your internal header adds no
new information over that already provided by the RSVP object header,
so that cannot be the reason.

Bob