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.