One document matched: draft-ietf-diffserv-phb-mgmt-00.txt
Internet Engineering Task Force Marty Borden,
Differentiated Services Working Group Bay Networks.
Internet Draft Christopher White,
Expires in six months Omnia Communications.
August, 1998
Management of PHBs
<draft-ietf-diffserv-phb-mgmt-00.txt>
Status of this Memo
This document is a submission to the IETF Differentiated Services
(DiffServ) Working Group. Comments are solicited and should be
addressed to the working group mailing list or to the editor.
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 draft documents are valid for a maximum of six
months and may be updated, replaced, or obsolete 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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited.
Abstract
The DiffServ Working Group will produce PHBs (Per Hop Behaviors)
used to provide differentiated services. Some of these are to be
standardized, others may have widespread use and still others may
remain experimental. The encoding of the PHB into a codepoint of
the DS Field will not be standardized, except for the legacy,
precedence PHBs. Therefore a method is needed to coordinate the
use of PHBs and codepoints, even if only for the purpose of
discussing them. This draft addresses this coordination issue.
[Page 1]
Internet Draft Diffserv PHB Management August, 1998
Table of Contents
1.Introduction 2
2.Terminology and Notations Used 3
3.Enumerated PHBs 3
3.1 Historical PHBs 4
3.2 Publication of PHB values 5
3.3 Local or Private PHBs 5
4.Exchange of PHB Information 5
5.Security Considerations 7
6.References 7
7.Authors' Addresses 7
1. Introduction
In the differentiated services architecture [ARCH], services are
built up from the building blocks of per hop behaviors (PHBs). Any
PHB is the externally observable forwarding behavior applied at a
DS capable node to a stream of packets that have a particular value
in the bits of the DS field (DS codepoint).
PHBs can also be grouped when it is necessary to describe the
several forwarding behaviors simultaneously with respect to some
common constraints.
Each PHB or PHB group thus corresponds to a subset of particular
bit patterns in the DS field. It is not desirable, however, to
rigidly map PHBs to codepoints. On the contrary, there is a desire
to have complete flexibility in this correspondence between
behaviors and codepoints. Such flexibility is useful in more than
one way. First, our understanding of good choices for PHBs is only
beginning and allocation of DS codepoints for PHBs is premature and
would possibly be limited in the future. Secondly, even after our
understanding of PHBs matures, it is quite possible that different
providers will deem it useful to use quite different sets of PHBs.
If these sets are moderately large then they could exhaust the
corresponding sets of potential codepoints and no fixed mapping
would suffice.
For these reasons, we propose that instead of enumerating the
codepoints and rigidly assigning PHBs to them, we enumerate the
PHBs, as they become defined, and allow the mapping of PHBs to
codepoints to be done within each DS domain.
As long as the enumeration space contains a large number of values,
there is no danger of running out of space to list the PHB values.
The PHB values can be made public for maximum interoperability.
Section 3 discusses the PHB enumeration.
[Page 2]
Internet Draft Diffserv PHB Management August, 1998
With the added freedom of flexibly mapping PHBs to codepoints comes
the additional work of reaching agreements between adjacent DS
domains as to the interpretation and translation of codepoints. As
long as the DS domains use the enumerated PHBs, they have a common
language for communicating per hop behaviors. What is needed is a
method for translating one set of codepoints to another. This is
discussed in section 4.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2. Terminology and Notations Used
We will use the following terminology:
Boundary Link: A network link between two DS domains. The link
connects the exit boundary node of one domain
with the entry boundary node of the other.
PHB value: The unique identifier used to enumerate PHBs.
PHB set: A set of PHBs identified by PHB values.
The following notation is used to represent the PHBs and codepoints
used:
PHBs(x) The set of PHBs supported by a domain x.
CP(x,phb) The value of the mapping from a PHB value to
codepoints for use within domain x: phb is an
element of PHBs(x); CP(x,phb) is a set of
codepoints.
3. Enumerated PHBs
Each PHB is assigned 32-bit unsigned integer, called the PHB value.
This numerical value is not of significance beyond its use in
enumeration.
We envision that a router will maintain the equivalent of a table
such as
[Page 3]
Internet Draft Diffserv PHB Management August, 1998
PHB value | DS Codepoint
______________________
... | ...
370 | 101000
371 | 101010
371 | 101011
... | ...
The same PHB value could be listed several times in the table:
different codepoints MAY represent the same PHB. This allows an
entire set of codepoints to be recognized as indicating the same
per hop behavior. This could be useful, for example, in some
implementations that use a portion of the bit pattern to recognize
a PHB and the remainder of the bit field to do any proprietary
items.
The same DS codepoint MAY be listed with different PHBs. At first
this might not seem correct, as different PHBs will receive the
same forwarding behavior based on them having the same codepoint.
However it really is necessary to allow this. For example, the
default, best-effort behavior and the lowest level precedence
behavior might be mapped to the same codepoint and receive the same
forwarding treatment.
The above considerations show that the table is not the
representation of a function between PHBs and Codepoints. What can
be said is that there is a function CP() that maps PHBs to *sets*
of codepoints. Such a mapping is domain specific, so that in
domain x (say) we might have CP(x,371) = {101010, 101011}, as
indicated in the table above.
It is important to note that the table is not used in the
forwarding path, but is used to configure the forwarding path and
its behavior.
3.1 Historical PHBs
The default PHB is the behavior corresponding to the best-effort
forwarding of today's routers [Header]. It is assigned the PHB
value 0.
We assume that the default PHB is in PHBs(x) for any domain x.
The 8 precedence PHBs [Header] are assigned the values 1 through 8.
The lowest precedence, corresponding to bit pattern 000, is
assigned the value 1; in general bit pattern b (interpreted in
network order) is assigned numerical value b+1.
[Page 4]
Internet Draft Diffserv PHB Management August, 1998
3.2 Publication of PHB values
To facilitate interoperability, in addition to the standardization
guidelines in [Header], PHBs MUST, as part of their proposal for
standardization, specify a PHB value, unique to the PHB.
A service to be offered by the Diffserv working group is to publish
the values of PHBs on its web page
http://www.ietf.org/html.charters/diffserv-charter.html. We
anticipate the assignment of PHB values to be done serially.
PHBs that are standard or proposed for standardization MUST be
published on the working group web page. PHBs that may be widely
used or for which interoperability is desirable SHOULD be published
at the working group web page. Other PHBs MAY be published on the
web page.
3.3 Local or Private PHBs
It is possible that a provider may wish to use some PHBs privately,
for its own purposes. The associated PHB values need not be
published but MUST NOT be the same value as any published PHB
values. In the future, we may find use of a protocol to exchange
PHB information, and conflicting interpretation of PHB values would
unnecessarily complicate any such protocol. Private PHBs SHOULD be
assigned values at least 2**30. There are an ample number of such
PHB values and they are well outside of the expected range of
enumerated, public PHB values.
4. Exchange of PHB Information
We consider the problem of interoperation between 2 DS domains, x
and y, say. To solve this problem, x and y need to reach an
agreement on the support of PHBs and the usage of codepoints. This
involves two agreements: how to handle flows from x into y and how
to handle flows from y into x. To describe what needs to be done,
it is sufficient to explain only one of these.
Consider the treatment of traffic from x into y. Each packet
that crosses the boundary link has some associated phb in PHBs(x),
although the traffic on this boundary link may correspond to a
strict subset of PHBs(x). When x enters agreement with y, it is
only necessary to deal with forwarding traffic that will actually
traverse the boundary link. There are three possible ways to
transform the behavior given to the packet as it enters domain y.
[Page 5]
Internet Draft Diffserv PHB Management August, 1998
(1) The phb in PHBs(x) is also in PHBs(y) and y agrees to support
this behavior on packets received from x. In this case a
mapping from CP(x, phb) to CP(y, phb) is required. This
mapping could be the trivial identity mapping if x and y use
the same codepoints for phb. It could, however, be quite
complicated to determine the mapping when the CP()'s are sets.
For example, if CP(x, phb) = {011101, 011010, 001011} and
CP(y, phb) = {011111, 101011}, some detailed discussions would
probably be necessary in order to decide the best mapping.
Once a mapping is determined for each phb, it must be decided
whether x or y is responsible to perform the manipulation of
the DS field.
(2) The phb in PHBs(x) is either in PHBs(y) but y will not support
this behavior in traffic from x, or phb is a behavior outside
of PHBs(y). Suppose further that x and y agree that a
substitute phb' in PHBs(y) is acceptable downstream behavior
for phb. Of course care must be taken to use a substitute
that provides a per hop behavior at least as good as phb or
very similar to phb since this decision may affect traffic
from upstream domains as well. Since this transformation of
phb to phb' is not invertible, there no recovery of phb
possible downstream and information is lost.
In this case we require a mapping between CP(x, phb) and CP(y,
phb'), and a decision as to whether x or y will do the mapping
of the DS field.
(3) If neither of the above 2 cases applies, then y has no option
other than to classify such incoming traffic from x as
discardable.
As mentioned above, we would need to make the mapping decisions for
traffic in each direction. These decisions may be done manually
via operator intervention, by a dynamic protocol between
neighboring domains, or by a combination of the two. Any
algorithmic approach for assigning codepoints is more complicated
when the CP() functions yield sets rather than individual
codepoints and it would be nearly impossible to guess the
operator's intent unless these sets have a clearly defined
structure. Work in this direction could be continued if there is
such structure and sufficient interest.
[Page 6]
Internet Draft Diffserv PHB Management August, 1998
5. Security Considerations
Security considerations for Diffserv in general are discussed in
[Header] and [Arch]. It is specifically of concern with respect to
this draft that the configuration of the translation of codepoints
be done in a secure manner by authorized entities in a manner
agreed to by adjacent domains.
6. References
[Header] Nichols, Blake, Baker and Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers", <draft-ietf-diffserv-header-
01.txt>.
[Arch] Black, et. al, "An Architecture for Differentiated
Services," <draft-ietf-diffserv-arch-00.txt>.
[RFC2119] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels."
7. Authors' Addresses
Marty Borden
Bay Networks, Inc.
mborden@baynetworks.com
+1 978-916-4578
Christopher White
Omnia Communications, Inc.
cwhite@omnia.com
+1 508-229-8444
[Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 10:51:16 |