Internet Draft 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",. [Arch] Black, et. al, "An Architecture for Differentiated Services," . [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]