Internet Engineering Task Force Kalevi Kilkki INTERNET DRAFT Jussi Ruutu Expires April 2000 Nokia Research Center October, 1999 Interoperability PHB Group Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines Differentiated Services Per-Hob-Behavior (PHB) Group called Interoperability PHB Group (PHB-i). PHB-i Group provides delivery of IP packets in two PHB forwarding classes. These two classes provides differentiation based on delay properties. Each class includes at least 6, or preferably 8 importance (or drop precedence) levels. This document shows how this PHB-i model can be used to facilitate interoperability between service providers. 1. Introduction Differentiated Services framework provides network operators the possibility to select different PHB groups [RFC2475]. Moreover, it is also possible to utilize PHB groups in many different ways. While this provides great opportunity to experiment and differentiate network services, there is an evident demand for a model that can be used for interoperation between service providers. This PHB Group for Kilkki Interoperability PHB Group [Page 1] INTERNET DRAFT April, 2000 interoperability (PHB-i Group) can be used to create an unambiguous DiffServ interoperation between network domains while allowing network operators freedom to implement such individual technical and business solutions as they wish without assuming anything about DiffServ models adopted by other service providers. 2. Problem Statement and Motivation While the general idea of DiffServ is to offer as much freedom for service creation as possible, this proposal emphasizes, in addition to the freedom, feasible interoperability between service providers. The approach of this draft is to identify the basics needs of effective traffic control in IP network and based on those needs to build a framework that supports both interoperability between domains and consistent and viable services within a network domain. The proposal is based on the following fundamental assumptions (1) IP is a packet network. (2) Possible problems encountered by a packet inside a network are bit errors, excessive delay and loss of the packet. (3) DS codepoints are used to define the expedient treatment of packets in core network. (4) In IP core network, bit errors are typically not an important issue. Consequently, we may infer that Per Hob Behaviors (PHB) should primarily be used to manage packet discarding and delays. This seemingly is one of the main objectives of current PHB models although it is not necessarily explicitly declared in the specifications [RFC2597], [RFC2598]. Particularly, the core of AF PHB Group [RFC2597] is that there are a number of PHB forwarding classes, and each of the classes has a weight that defines the (relative) amount of network resources available for the class. However, there are some practical difficulties with the application of that kind of PHB model in heterogeneous environment. In particular, the need to settle the weight for each PHB forwarding class throughout inter-operating network domains is a laborious task due to the intense traffic fluctuations on all time scales from milliseconds to weeks. A brief evaluation of the use of weights is provided in Appendix 1. For more thorough discussion see [KK99]. In addition to weights, there are problems related to management of interoperation. Operators may have quite different ideas about how to use different DiffServ PHB classes. For example, one operator may have IP packets allocated to different classes based on price of the service while the other is making the allocation based on applications. A third operator may use a combination of these two principles. In the worst case, there is a need for mapping of DSCP almost case by case at the boundary between networks. Thus, it is obvious that some common metrics is needed to build workable end-to-end services. Kilkki Interoperability PHB Group [Page 2] INTERNET DRAFT April, 2000 3. Principles of PHB-i model The main difference between PHB-i model and the conventional DiffServ model is that in the latter one it assumed that each specific problem can be solved by specifying an appropriate PHB group. The fundamental risk of this approach is that in reality there are a large number of problems that are not independent of each other. As a result, independent specification, implementation and management of PHB groups might be very difficult task in real networks. For instance, if the specification of a PHB group requires that other PHB groups shall be implemented and management in a way that they do not interfere the treatment of the packets belonging to that PHB group, is evidently useful approach from the PHB group viewpoint, but might lead difficult situations if other PHB groups make similar requirements. PHB-i model, on the contrary, provides a framework for different service models with a comprehensible interoperability scheme. The fundamental principle of the PHB-i model is the use of unambiguous scales for importance and urgency. All needs are mapped to these two scales, whereas the marking schemes by itself are left open. It shall also be noted that these scales are defined for packets, not for flows or connections. The overall quality of service related to flows depends on the use of these scales as well as on network planning and provisioning. The principle of PHB-i system is depicted in Figure 1. from customer | or other | domain | -> [Mark1] -> (I=a,U=b) --- | | / \ | ->(I=a,U=b)---->O--> [Mark2] -> (I=x,U=b) ----O->|->(I,U) or (DSCP=x) | \ / | | -> [Mark3] -> (I=y,U=z) --- | Figure 1. Basic principle of PHB-i model. Incoming packets, with an original packet marking that can either be based on importance and urgency (I=a,U=b) or other PHB models (DSCP=z), are sorted based on any appropriate principle in a way that they will receive a suitable marking (Mark). This sorting defines the marking principle applied to the packet as shown in Figure 1. For example, packet marking can be based on application, price paid by the customer and original packet marking made by the customer. The outcome of each marking mechanism is importance level (I) and urgency class (U) for every packet. After the marking, information about the actual marking schemes, as well as the original marking made by the customer, is hidden behind the importance and urgency levels of each packet. As a result, whatsoever treatment the packet later attains, it is based on the importance and urgency of the packet. Kilkki Interoperability PHB Group [Page 3] INTERNET DRAFT April, 2000 Appendix 2 shows additional information about possible marking mechanisms. Note, however, that this document does not take any position about the merits of different schemes. 4. Applications of the PHB-i Group This section outlines some possible applications of the PHB-i model. The applications can be divided into three categories: 1. PHB-i Group is used only for interoperability purposes 2. PHB-i Group is used mainly for interoperability purposes but also to some extent within a domain 3. PHB-i Group is used as the only PHB group within a domain 4.1 PHB-i Group for interoperability purposes This scheme provides a minimum changes to a network using other PHB models. The main characteristics of the model are: - Packet marking inside a network domain is entirely based on other PHB specifications. - Core node implementation is purely based on the requirements of other PHB proposals including the use of weights for each PHB forwarding class. - PHB-i model is used only between service providers for traffic contract and interoperability purposes. We can discern several sub-categories depending on whether the real marking of packets is changed in any part of the network. In the first sub-category illustrated in Figure 2 PHB-i model does not effect into the real marking of packets in any way. Instead, the DS codepoint (DSCP) of the packet is mapped into a pair of importance and urgency, and these are merely used to implement the contract between the operators. | -> [Map1] -> (I=u,U=v) -> [$] / | (DSCP=a) -X--> [Map2] ----> (DSCP=x) ------> | Domain 1 | Domain 2 Figure 2. PHB-i model used for service contract purposes (Mapping 1 is here virtual in the sense that it does not effect on the real DSCP value of packets). Note that Mapping refers in this document to a relation between input and output in which the output is always the same independent of any other parameter than the input, e.g., DSCP in Figure 2. In contrast, if the relation depends on other issues like momentary load, the box is Kilkki Interoperability PHB Group [Page 4] INTERNET DRAFT April, 2000 called Marking. Abbreviations Map and Mark are used for Mapping and Marking, respectively, in the figures. The next possible step is to utilize the PHB-i model to facilitate the DSCP mappings between two network domains as shown in Figure 3. The main difference between this and the previous approach is that now each operator can define the mappings between ordinary DSCPs and PHB-i model independent of other service providers. | ->[$] / | (DSCP=a) -> [Map1] -> (I=u,U=v)--X------> [Map2] -> (DSCP=y) | Domain 1 | Domain 2 Figure 3. PHB-i model used to facilitate the management of DSCP conversions. 4.2 PHB-i Group combined with other PHB groups The main properties of this approach are - Edge node sets the DS field of each IP packet coming from local customers as defined in any PHB specification. - Part of the packets with non-PHB-i marking can use PHB-i mechanisms inside network nodes by means of a temporary mapping to PHB-i model. - Packets coming from other domains primarily use the PHB-i group. - Core node implementation includes both conventional methods with appropriate mechanisms, like weights, and traffic handling mechanisms for packets with PHB-i marking. The main benefit of this model is that while a service provider may have a good idea how to use the ordinary PHB groups within his own domain, it is difficult for him or her to locate incoming traffic coming from other domains to any specific PHB group without knowing how every other operator uses each PHB group. However, it might be easier to implement a designated PHB-i group for that purpose rather than making ambiguous markings between PHBs groups. Figure 4 illustrates how the traffic from other domains is handled with PHB-i group while the local traffic is still treated using the local DSCPs. Kilkki Interoperability PHB Group [Page 5] INTERNET DRAFT April, 2000 | | from | ->[Mark1]->(DSCP)------------------------> W1(DP) local | / | customers ->O-->[Mark2]->(DSCP)---O--------------------> W2(DP) | | \ | | ->[Map4]->(I,U)-O--> W3(I,U) from other| | / domains -----> [Mark3]->(I,U) -------------------- | | Wi() = Weight for PHB Group i DP = Drop Preference inside a PHB Group Figure 4. PHB-i used for handling traffic coming from other domains (Mapping 4 can be virtual in the sense that the real DSCP of the packet is not changed). 4.3 PHB-i Group as the only PHB group within a domain The third main alternative is to use PHB-i as the main PHB model within a network domain. In this case: - All packets sent by local customers and coming from other domains are marked according to the PHB-i model. - Core node implementation only needs to support the PHB-i model The fundamental principle of the PHB-i model is the use of unambiguous scales for importance and urgency. All needs are mapped to these scales, whereas markings schemes by itself are left open. The basic principles of PHB-i system are depicted in Figure 5. Although the actual implementation is out of the scope of this draft except that it should provide consistent importance and urgency differentiation as described in Appendix 3. | -> [Mark1] -> (I=a,U=b) --- | local | / \ | customer->(I=a,U=b)-->O--> [Mark2] -> (I=x,U=b) ----O->|->(I,U) | \ / | | -> [Mark3] -> (I=y,U=z) --/ | from other | / | domain ->(I=c,U=d)---> [Mark4] -> (I=v,U=d) ---/ | | / | ->(DSCP=a)----> [Mark5] -> (I=w,U=z) -- | | | Figure 5. PHB-i used as the only PHB model inside a domain Kilkki Interoperability PHB Group [Page 6] INTERNET DRAFT April, 2000 Incoming packets are classified based on any appropriate principle. Classification selects the marking procedure for the packet as shown in Figure 5. The outcome of each marking mechanism is importance level (I) and urgency level (U) for every packet. Both importance and urgency can be either the same as the original marking or something else (see also Appendix 2). Note, however, that this document does not take any position about the merits of different marking schemes. A specific case of mapping is that between other PHBs and PHB-i group. This mapping is essential when the operator does not want to implement other PHB groups in core network, but still wants to use them, for instance, in access network. Moreover, similar mapping is needed for interoperability purposes when another operator does not apply the PHB-i model at all. More information is provided in Appendix 4. After the marking procedure all packets are multiplexed in the same stream in a way that marking schemes are hidden behind the importance and urgency levels. Consequently, core network does not know anything about the reasons why a packet has a specific marking. Moreover, in this case there is no need to have and manage weights for different PHB groups (see also Appendix 3). 5. Codepoints This section provides a recommendation for the codepoints used by the PHB-i Group. The minimum number of levels is 2 for urgency and 6 for importance. However, in order to achieve as general applicability as possible more levels could be useful, but probably not more than 3 urgency levels and 10 importance levels. Table 1 shows a codepoint proposal for a PHB-i system with 8 importance levels and 2 urgency classes. Table 1. Recommended codepoints for PHB-i +------------+----------------+ | | Urgency | | Importance | 0 1 | +------------+----------------+ | 7 | 111011 111111 | + - - - - - - - - - - - - - - + | 6 | 110011 110111 | | 5 | 101011 101111 | | 4 | 100011 100111 | | 3 | 011011 011111 | | 2 | 010011 010111 | | 1 | 001011 001111 | + - - - - - - - - - - - - - - + | 0 | 000011 000111 | +------------+----------------+ Kilkki Interoperability PHB Group [Page 7] INTERNET DRAFT April, 2000 Principally, PHB-i model provides at least 6 levels of importance for each urgency class. Although one may assume that the number implies that that the packet belonging to one flow could be marked with at least 6 levels of importance, that is not the real reason for specifying as many importance levels as 6. In contrast, the actual reason for having that many, or even more, importance levels is to build a framework that is applicable to various situations (see also Appendix 4). 5. Security Implications In order to protect against denial of service attacks, a service provider should limit the traffic entering the domain on each importance level (including both urgency classes) to an extent that is needed to realize the service objectives. This requirement is particularly critical on the highest importance levels whereas on the lowest importance levels the traffic adjustment during congestion situations can rely more on the traffic control protocols in customer equipment. 6. IANA considerations This document allocates 16 codepoints, listed in section 5, in the codepoint pool reserved for local and experimental use defined in [RFC2474]. Kilkki Interoperability PHB Group [Page 8] INTERNET DRAFT April, 2000 Appendix 1. Weight management Appropriate regulation of the weights is necessary in order to attain a meaningful quality relationship between the PHB classes. Basically, there are three main possibilities to achieve this: (1) Weights are regulated based on the requirements of each individual flow. (2) Weights are regulated based on the instantaneous load of each class. (3) Weights are permanent but the input traffic of each class is controlled (that is, limited) in a way that the quality relationships remain appropriate. Although the first approach is definitely possible, it does not belong to the area of Differentiated Services, because it effectively requires signaling of flow requirements through the network. Nonetheless, some proposals presented in the context of DiffServ effectively belong to this category. The second approach, in contrast, might offer a decent solution although the actual algorithm used to control the weights seems relatively hard to design. Moreover, different algorithms may entail considerably differing results which makes it more difficult to obtain consistent interoperability between network domains. The third approach yields similar problem as the first approach because some information about the load situation on each link should be transmitted continuously to all edge nodes. In addition, this approach appears to limit the accepted traffic in vain because packets are discarded at the edge due to unfit weights rather than a real lack of resources inside the network. Yet it might be a feasible solution to some specific problems, like Virtual Private Networks (VPNs), in which the business model may necessitate a strict separation of network resources. Consequently, a PHB structure in which the outcome is based on the use of weights makes the interoperability between operators difficult. Appendix 2. Examples of packet marking This appendix outlines some possible marking approaches that appear applicable with PHB-i model. Let us use the following abbreviations: Kilkki Interoperability PHB Group [Page 9] INTERNET DRAFT April, 2000 A = application P = price paid by the customer T = instantaneous traffic sent by the customer I = importance marking of the packet (made by the network) U = urgency marking of the packet (made by the network) IO = original importance marking made by the customer UO = original importance marking made by the customer F() = a function First, the starting point could be that importance and urgency levels while the price of the service is defined as a function of them: (1a) P = F1(IO,UO,T) In this case the customer defines the packet marking, and the service provider calculates the price of the service based on the importance and urgency of packets and the total amount of traffic. More specifically, it is possible that a price is attached to each packet i, (1b) P(i) = F1(IO(i),UO(i),T(i)). In addition, price function may depend on the destination of the packet, time of date and similar issues. Second, the starting point can be application while importance and urgency are based on them: (2) I(i) = F2(A) U(i) = F3(A) In this case network identifies the application and defines the importance and urgency of the packet according to the requirements of the application. No explicit price is used in this scheme. Third, it is possible to combine the first two approaches: (3) I(i) = F2(A) U(i) = F3(A) P = F4(I,U,T) Packet marking is based on the application while the price is based on the ensuing marking and amount of traffic. Forth, the starting point can be the price paid by the customer while the importance of the packets is a function of the price and the traffic sent by the customer: (4) I(i) = F5(P,T) U(i) = UO(i) (or U(i) = F6(A)) Kilkki Interoperability PHB Group [Page 10] INTERNET DRAFT April, 2000 In addition, urgency marking may have an effect on this function. Urgency marking can be the original one made by the customer, or it can be based on the application. Appendix 3. Implementation recommendations This appendix provides some recommendations for the implementation of core nodes that supports the PHB-i model. The two main recommended features for the PHB-i implementation are - No reordering is allowed for two packets belonging to the same urgency class - Packet discarding on certain point of time should primarily be based on importance scale and load situation. As far as load situation is constant the following relations should be valid: Pr(discard,I(i)) ( Pr(discard,I(j)) if I(i) > I(j) Pr(discard,I(i)) ( Pr(discard,I(j)) if I(i) = I(j) E(delay,U(i)) ( E(delay,U(j)) if U(i) > U(j) E(delay,U(i)} ( E{delay,U(j)) if U(i) = U(j) where Pr() is probability and E() is expected value, I(i) is the importance level of packet i, and U(i) is the urgency level of packet i. Note that E(delay) is defined only for successfully delivered packets. Appendix 4. Interoperability with other PHB groups Currently the main PHB groups are Expedited Forwarding (EF) and Assured Forwarding (AF) [RFC2598], [RFC2597]. In addition, a mapping between current best effort (BE) service and PHB-i is necessary in any DiffServ network. Expedited Forwarding In principle, EF PHB can be mapped permanently to one PHB-i codepoint. Because of the high quality requirements of EF it is evident that EF needs as high urgency and importance as possible. If we suppose that the highest importance level is used exclusively by packets related to networks operation like routing, the obvious mapping is: I(EF) = N-1, where N is the highest importance level U(EF) = M , where M is the highest urgency level It should be stressed that this mapping does not itself guarantee high Kilkki Interoperability PHB Group [Page 11] INTERNET DRAFT April, 2000 quality related to packet loss ratio for a flow, but rigorous network planning with possibly some additional traffic control functions are needed for end-to-end service provision. Assured Forwarding AF consists of four PHB forwarding classes each with 3 drop precedence levels. The fundamental difficulty of any AF mapping scheme is that the real nature of and relationship between AF classes are not accurately defined. Therefore, we have to temporarily fix the objective for the AF PHB Group in order to specify an appropriate mapping between it and PHB- i Group. In this case, it is supposed that four AF forwarding classes are used to provide - two overall service levels, e.g., one for "more important" and another one for "less important" customers - two delay classes, one for real time applications and another for non-real time applications Combining these two into one system we get totally 4 forwarding classes, each with 3 levels of drop preference. Best Effort Service Basically it is possible to map the Best Effort PHB into one fixed point on the importance-urgency scale. It appears that best effort traffic is not particularly urgent because applications using best effort service should, by and large, be adaptable to large delay variations. Further, it seems likely that best effort traffic, which is intrinsically uncontrolled by the network operator, should be placed below those AF codepoints which carry traffic that is efficiently limited by edge routers. Thus, the importance level shall be at most 1. The main problem of this approach is that it might cause temporary deprivation of resources for Best Effort traffic. Table 2. A tentative mapping between ordinary PHB groups and PHB-i group. +------------+----------------------+ | PHB-i | Urgency | | Importance | 0 1 | +------------+----------------------+ | 7 | (network control) | | 6 | EF | | 5 | AF11 AF31 | | 4 | AF21 AF41 | | 3 | AF12 AF32 | | 2 | AF22 AF42 | | 1 | BE | | 0 | AF13&AF23 AF33&AF43 | +------------+----------------------+ Kilkki Interoperability PHB Group [Page 12] INTERNET DRAFT April, 2000 It should be stressed that Table 2 represents only one possible mapping scheme while it does not provide a general approach that is valid independent of the services built by the PHB groups. In fact, there cannot be any generally applicable mapping, and therefore, each operator has to design the mappings based on the end-to-end service model. References [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black: "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss: "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski: "Assured Forwarding PHB Group, RFC 2597, June 1999. [RFC2598] V. Jacobson, K. Nichols, K. Poduri: "An Expedited Forwarding PHB, RFC 2598, June 1999. [KK99] K. Kilkki: "Differentiated Services for the Internet", Macmillan Technical Publishing, USA, June 1999. Authors' Addresses Kalevi Kilkki Nokia Research Center 3 Burlington Woods Drive, Suite 250 Burlington, MA 01803 email: kalevi.kilkki@nokia.com Jussi Ruutu Nokia Research Center It„merenkatu 11-13 FIN-00180, Helsinki, Finland email: jussi.ruutu@nokia.com Please send comments to Kalevi Kilkki, kalevi.kilkki@nokia.com Expires April, 2000 Kilkki Interoperability PHB Group [Page 13]