Protocol Action: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to Proposed Standard

The IESG <iesg-secretary@ietf.org> Wed, 11 November 1998 13:15 UTC

Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id IAA27442 for ietf-123-outbound.10@ietf.org; Wed, 11 Nov 1998 08:15:02 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA27376; Wed, 11 Nov 1998 08:08:45 -0500 (EST)
Message-Id: <199811111308.IAA27376@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: diff-serv@baynetworks.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to Proposed Standard
Date: Wed, 11 Nov 1998 08:08:45 -0500
Sender: scoya@ns.cnri.reston.va.us


The IESG has approved the Internet-Draft Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
<draft-ietf-diffserv-header-04.txt> as a Proposed Standard, obsoleting both
RFC1349 and RFC1455.

The IESG also approved publication of An Architecture for
Differentiated Services <draft-ietf-diffserv-arch-02.txt> as an
Informational RFC.

These documents are the product of the Differentiated Services Working
Group.  The IESG contact persons are Scott Bradner and Vern Paxson.


Technical Summary
 
  These documents define an architecture for implementing scalable service
  differentiation in the Internet.  This architecture achieves scalability
  by aggregating traffic classification state which is conveyed by means of
  IP-layer packet marking at network boundaries or in hosts.  Packets are
  classified and marked to receive a particular per-hop forwarding behavior
  on nodes along their path.  Sophisticated classification, marking,
  policing, and shaping operations need only be implemented at network
  boundaries or in hosts.  Network resources are allocated to traffic
  streams by service provisioning policies which govern how traffic is marked and
  conditioned upon entry to a differentiated services-capable network, and
  how that traffic is forwarded within that network.  A wide variety of
  services can be implemented on top of these building blocks.  The services
  may be either end-to-end or intra-domain; they include both those that can
  satisfy quantitative performance requirements (e.g., peak bandwidth) and
  those based on relative performance (e.g., "class"  differentiation).
  Services can be constructed by a combination of:

  - setting bits in an IP header field at network boundaries
    (autonomous system boundaries, internal administrative
    boundaries,  or hosts),
  - using those bits to determine how packets are forwarded by the
    nodes inside the network, and
  - conditioning the marked packets at network boundaries in
    accordance  with the requirements or rules of each service.

  The requirements or rules of each service are set through administrative
  policy mechanisms which are outside the scope of these documents.


  The document, "Definition of the Differentiated Services Field (DS Field)
  in the IPv4 and IPv6 Headers," defines the IP header field, called the DS
  (for differentiated services) field.  In IPv4, it defines the layout of the
  TOS octet; in IPv6, the Traffic Class octet.  In addition, a base set of
  packet forwarding treatments, or per-hop behaviors, is defined.  Since
  this document redefines the use of the IPv4 TOS field it will obsolete RFC
  1349 which will be reclassified as Historic.  The document also updates
  RFC 791.

  The document, "An Architecture for Differentiated Services," provides an
  overview of the architectural principals of a differentiated service
  network.

Working Group Summary

 The working group discussion indicated strong support for these documents
 and no significant issues were raised during IETF Last-Call.

Protocol Quality

 These documents have been reviewed for the IESG by Scott Bradner.

Note to RFC Editor:

in draft-ietf-diffserv-header-04.txt section 3 please change
the word "random" to "arbitrary" in the following

   those precedence designations."  Validating the value of the DS field
   at DS boundaries is sensible in any case since an upstream node can
   easily set it to any random value.  DS domains that are not isolated
   by suitably configured boundary nodes may deliver unpredictable
   service.