TSV working group Internet Draft Naotaka MORITA Document: draft-morita-tsvwg-mfphb-00.txt NTT Corporation Expires: April 2004 October 2003 Measurable Forwarding: A New per-Hop Behavior (PHB) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for a series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. The indicator of bandwidth available for media packets in the PPS is the number of lower-priority packets dropped by the routers. The scheme is based on a new per-hop forwarding behavior, called measurable forwarding (MF-PHB), which will use the DiffServ Morita Expires - April 2004 [Page 1] MF-PHB October 2003 architecture. The similarities with and differences from the queuing methods of existing routers, and the utility of the latter, are described. MF-PHB has two modes, static and elastic. The feasibility of realizing the MF-PHB on existing DiffServ architecture is examined to derive guidance on ways to quickly configure MF-PHB. Architectures that derive the full advantages of MF-PHB are also described. Conventions used in this document 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 RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 2. Requirements for Routers.......................................3 2.1 Four Mandatory Functions...................................3 2.2 Additional or Optional Functions...........................5 3. Definition of MF-PHB...........................................7 3.1 Static Mode................................................7 3.2 Elastic Mode...............................................9 4. Realization for MF-PHB........................................11 4.1 Policer Enhancement to Realize Static Mode through EF-Class Extension (Two-Threshold Token Bucket)........................12 4.2 Policer Enhancement to Realize Elastic Mode through EF-Class Extension (Two-Rate Token Bucket).............................15 4.3 Shaper Enhancement to Realize Static Mode through AF-Class Extension.....................................................17 Security Considerations..........................................18 References.......................................................18 Author's Addresses...............................................19 1.Introduction The Priority Promotion Scheme (PPS) [3] is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for series of packets on a packet-based network. The main target is interactive multimedia services such as VoIP, video chatting, and video conferencing, which are usually controlled using SIP. In this context, "priority" means priority or precedence in the IP layer as represented by the DiffServ Code Point (DSCP). The scheme is based on end-to-end measurement of network resources through coordination of the end systems. Before a session is established and even during sessions under certain conditions, the source end system senses, measures, or probes the availability of network resources by sending Morita Expires - April 2004 [Page 2] MF-PHB October 2003 packets with priority one level lower than that of the non-probe packets, i.e. those for established streams. The result is an adjustment of the DiffServ Code Point (DSCP) value for the succeeding IP packets: the priority is raised or promoted to firmly establish the session, lowered to leave resources with existing sessions, or otherwise adjusted to control the amount of packets so that the traffic fits the available capacity. The network, i.e. output links of the routers or L2 switches, is only required to support per-class priority control. The prioritization allows the end systems to measure remaining resources without affecting exiting streams. Having all end systems behave in the way described above ensures that the end-to-end QoS is achieved without maintaining per-flow states in individual items of network equipment. This new per-hop forwarding behavior (transport function of the network), called "measurable forwarding" or MF-PHB, is the key point of the PPS. In this document, we introduce this behavior and show methods for its implementation. In section 2, we examine the router behavior required for network implementation of the PPS. In section 3, we propose the MF-PHB as a description of behavior that realizes the PPS and define the static and elastic modes of the MF-PHB. The former covers functions essential to the PPS (mandatory functions) while the latter provides greater flexibility (additional functions). In section 4, we describe ways to achieve MF-PHB on existing DiffServ-based architectures as well as architectures that derive the full advantages of this new PHB. Verification scenarios for MF-PHB are specified in [4]. 2.Requirements for Routers In this section, we discuss the requirements for routers to make PPS work effectively and appropriately. We categorize the required functions into two groups; mandatory, and additional or optional functions. 2.1Four Mandatory Functions 2.1.1 Guaranteeing a Minimum Bandwidth PPS is essentially a scheme for per-flow control of admission to the DiffServ network on a per-class basis. When we do admission control in a DiffServ network, we usually presume that the bandwidth for the class is reserved and dedicated at every link. When a session or a flow is established, the terminal judges whether or not there is enough unused bandwidth to provide the required level of quality between the source and destination terminals. If there is, the session will be established with the required bandwidth, and the Morita Expires - April 2004 [Page 3] MF-PHB October 2003 quality of the session is guaranteed till the session ends. If there isn't, the session request is refused. Obviously, the purpose of admission control is to guarantee the QoS once the session has been admitted. Consequently, this is not achieved when the quality of an admitted session becomes worse and some of its packets start to be dropped. That is to say, the bandwidth dedicated to a class under admission control must not be decreased. In other words, the routers must guarantee bandwidth for the classes. This is the generic requirement for classes under admission control in DiffServ architecture, and also applies to the PPS. Note that non-PPS classes may use the unused resources when there is no traffic in the PPS class. It is important that a given threshold bandwidth be available for PPS traffic at all times. The requirement is obviously satisfied when all traffic on the link is PPS. The requirement must be explicitly satisfied when PPS-class traffic coexists with traffic in other classes, i.e., EF (expedited forwarding), AF (assured- forwarding), and BE (best-effort). 2.1.2 Maximum Bandwidth Limitation PPS is a measurement-based admission control scheme applied by the end terminals. The terminals send probe packets to find out the remaining bandwidth. Fixed bandwidth limitations are essential for the routers if we are to get information on the remaining bandwidth that is reliable and is valid over relatively long periods. If the upper limits fluctuate, so does the remaining bandwidth. Let's assume that the limits increase. More flows will be admitted, which seems like a good result. However, the guaranteed quality levels of the admitted flows may be lost when the bandwidth, once having increased, subsequently falls. This is why the routers must keep fixed bandwidth available for PPS-class traffic. The requirement is obviously satisfied when only one class is using the link. As with the above requirement, it must also be satisfied when the PPS class coexists with other classes, i.e., EF, AF, and BE. So, bandwidth for the PPS class must be reserved, available at any time, and have a strict upper limit which applies regardless of usage by non-PPS classes. For a router to be able to handle PPS traffic it must be configurable with a minimum-bandwidth guarantee and maximum- bandwidth limitation; these values are in practice the same. 2.1.3 Priority Control The use of probe packets is a key feature of the PPS. Having the priority of the probe packets the same as that of the actual packets that follow may lead to the loss of existing media packets. This issue becomes serious when a large number of terminals attempt to establish new sessions, and produce huge amounts of probe packets. Morita Expires - April 2004 [Page 4] MF-PHB October 2003 Media packets, therefore, must take priority over the preceding probe packets so that the QoS levels for existing flows are maintained. The lower priority makes probe packets more sensitive, since deterioration of QoS is concentrated on the probe packets so that they don't affect the actual media packets. Media and probe packets are the two basic sub-classes of the PPS class. Measurement-based admission control can be achieved if the routers satisfy the above three requirements. 2.1.4 Real time nature The targets of PPS are interactive multimedia, that is, the real-time traffic for VoIP and video-chat services. PPS-class packets thus need to be handled as such. Delay and jitter at routers must be minimized. In summary, four functions are mandatory: guarantee of the minimum bandwidth, limitation of the maximum bandwidth, priority control with two classes, high and middle, and real-time operation. 2.2 Additional or Optional Functions In this sub-section, we move on to the extended requirements, which enhance the capabilities of PPS. 2.2.1 Sequence integrity In the PPS the destination terminals measure the availability of the network to judge whether or not to admit new sessions. The effects of packet-order inversion differ according to whether probe packets or media packets are affected; in the former case, the results of measurement become less reliable and in the latter case, playback quality may be lost. Furthermore, the media packets themselves will act as probe packets in some implementations of the PPS. This will be so when probing is expected to take more than a couple of seconds and the user is unwilling to tolerate such a post-dial delay. Sending the initial content packets as probe packets eliminates the delay. In such a case, the priority of the actual media flow will change during the session. Integrity should be maintained for the packet sequence regardless of priority. 2.2.2 Consideration of link failure In general, breakdown of a link in an IP network, the routers gather new topological information from which they derive new routes. Flows that were being transmitted along the damaged link pass through new links. In PPS, the media packets are assumed to pass through the Morita Expires - April 2004 [Page 5] MF-PHB October 2003 same links as the preceding probe packets. If the link in use changes during a session, QoS cannot be guaranteed because admission control wasn't for the new link. The negative impact is not limited to the flow forced to travel along a new link. The unexpected load caused by such failure leads to deterioration for the other flows on the link, because there is no way to distinguish them from the flows that have been switched from the damaged link. We must, therefore, be careful about the behavior of dynamic routing in cases of link failure. To simplify this issue, we assume that the links are equipped with a form of redundancy (one-to-one protection), which minimizes the effects of dynamic routing. If a failure occurs on one link, the router switches all traffic from that link to the other link of the redundant pair. Each is paired with another link on the same hop and neither devotes more than 50% (or less) of its capacity to PPS traffic except if one fails. Thus, even though probing isn't applied when the traffic is switched-over, there will be no problems with quality. For example, if the maximum bandwidth for the PPS class at each link is 40%, the total traffic will never take up more than 80% of one link. If the queuing mechanism allows such exceptionally treated but upper-limited traffic, the switch-over can be realized while QoS for the flows is maintained. 2.2.3 Consideration of hand-over for mobile terminals Mobility is an important service feature. Even when a user moves from one place to another, i.e., changes access points during a session, the QoS of the session should be maintained. In PPS, it is straightforward to have the terminals perform admission control again to confirm the suitability of the new route. Doing so takes time, and there is a chance of unsuitability when sufficient resources are not available. Once again however, if the queuing mechanism treats hand-over flows as an exceptional case, guaranteed QoS becomes achievable for the mobile user. 2.2.4 Support for VBR traffic Any measurement-based form of admission control is more suitable with constant bandwidth (CBR) sources than with variable bandwidth (VBR) sources. CBR sources to which silence suppression is not applied are generally used in voice communications in Japan. For interactive multimedia, on the other hand, it is important that we take VBR into account. We would briefly like to refer to another approach based on declared traffic parameters. The admission control system gets the declared parameters, estimates the equivalent bandwidth, and then judges Morita Expires - April 2004 [Page 6] MF-PHB October 2003 whether or not admission is possible. The issues are how to derive truly representative parameters for each of the many popular codecs, and how to estimate the total required bandwidth if a new flow were offered. VBR has quite different implications for a measurement-based approach such as PPS. PPS requires no parameters, no estimation, and no calculation. In addition, utilization of bandwidth is ideal because measurement is of actual traffic. There is, however, a trade off. The PPS depends on the usage of resources at the time of measurement. Measurement for a particular session may occur when the flows already present are at relatively low rates. The new session may then suffer loss of QoS when the existing flows grow again. The solution to these issues is to absorb statistical variation, which can be done by probing over a longer time or using probing packets that are more than the media packets. If the queuing mechanism allows transmission of such extra packets, traffic for which we expect fluctuation of the above kinds may be more easily accommodated. 3.Definition of MF-PHB Superficially, a queuing mechanism for PPS appears easy to achieve on the basis of the existing DiffServ architecture. However, the requirement that the router handle two sub-classes (for probing and media packets) and place a common bandwidth limitation on both is not covered by the current DiffServ per-hop behaviors or PHBs. We therefore propose the new Measurable Forwarding Per-Hop Behavior (MF- PHB). MF-PHB has two sub-classes; MF-High (media) and MF-Middle (probing). We further define two modes for MF-PHB, static and elastic. The static mode includes a minimum bandwidth guarantee, maximum bandwidth limitation, priority control, and real-time service. This mode is the same as the form of operation proposed by Karlsson. The elastic mode caters to more flexible behavior by taking additional requirements into account and omitting unnecessary conditions. 3.1Static Mode 3.1.1 Definition ò Minimum bandwidth guarantee: Regardless of the conditions of non- PPS classes, the router should pass MF packets up to some threshold, if they are offered. BWmf is defined as the threshold. Morita Expires - April 2004 [Page 7] MF-PHB October 2003 ò Maximum bandwidth limitation: The router should discard packets that take usage beyond this limit; this applies, regardless of the states of traffic in non-PPS classes, to both MF-H and MF-M packets. In the Static mode, the limit is the same as the guarantee. ò Priority control: the router must give priority to MF-H packets. Regardless of the states of traffic in non-PPS classes, the router discards any M packets that would take the overall rate of MF-class traffic over the threshold BWmf and passes all H packets within BWmf. ò Real-time operation: Regardless of the conditions of non-PPS classes, the router should pass H packets with low latency and low jitter. ò Sequence integrity: the router should transport packets without changing their order. This is satisfied within all flows across the two priority levels, i.e., H and M. 3.1.2 Behavior In static mode, one threshold is common to both M- and H-subclass traffic. Figure 1 illustrates typical MF-PHB dynamics in static mode. The horizontal line is time, and the vertical line is usage of the output interface of a router. BWmf is both the minimum guaranteed bandwidth and the maximum bandwidth limitation. As long as the aggregate of flows takes up less than BWmf, no MF-M packets are discarded; the succeeding MF-H packets are then sent (1). When the aggregate would take up more than BWmf, the router discards the offending MF-M packets and the source terminal doesn't transmit the succeeding MF-H packets. There is still no discarding of MF-H packets (2). When the source attempts to open a new session after previous sessions have been closed (3), it transmits MF-M packets for the new flow, after which transmission of the MF-H packets starts up. Morita Expires - April 2004 [Page 8] MF-PHB October 2003 ===================================================================== !!LOSS!! !!LOSS!! +-----+ +-----+ BWmf- - - - - - - (2)|- m- |- |- m- |- - - - - - - - - - - - - - - - +--------------------------+ | M | H | +------------------------------------+ +-----+-----+ (1)| M | H | (3)| M | H | +-----------------------------------------------------------+ | M | H | +-----------------------------------------------------------------+ | M | H | ===================================================================== ---> time M: a series of middle-subclass packets successfully transported H: a series of high-subclass packets successfully transported m: a series of middle-subclass packets discarded BWmf: available bandwidth for MF-PHB in static mode Figure 1. Dynamics of MF-PHB in static mode at a link 3.2Elastic Mode 3.2.1 Definition ò Extended minimum bandwidth guarantee: Regardless of the conditions of non-PPS classes, the router should pass MF packets up to this threshold. There are separate thresholds, BWm and BWh, for M- and H- class traffic, respectively. ò Extended maximum bandwidth limitation: Regardless of the conditions of non-PPS classes, the router has to discard extra MF-M packets if there is more MF traffic than the threshold BWm. The router has to discard MF-H packets when the amount of MF traffic exceeds the threshold BWh. ò Priority control: the router must give MF-H packets priority over MF-M packets. Regardless of the conditions of non-PPS classes, the router should discard M packets that exceed the threshold BWm while passing H packets up to BWh. ò Real time nature: Regardless of the conditions of non-PPS classes, the router should pass H packets with low latency and low jitter. Morita Expires - April 2004 [Page 9] MF-PHB October 2003 ò Sequence integrity: the router should transport packets without changing the order of packets in the series. This is satisfied within all flows at each of the priority levels, i.e., H and M. 3.2.2 Behavior In elastic mode, there are two thresholds, BWm for M- and BWh for H- class traffic. Figure 2 illustrates typical MF-PHB dynamics in elastic mode. The behavior is the same as Static Mode at points (1) and (2). In Static mode, flows start to be discarded when the number of MF-H packets would go beyond the threshold. In Elastic mode, however, MF-H packets for flows that would only exceed BWm, the first threshold, are not discarded (3). This is because BWm is only the limit for probing traffic. When the MF-M packets for a new flow go beyond BWm, they are discarded (4). This prohibits transmission of the succeeding MF-H packets. After some sessions have closed so that the aggregate traffic takes up less than BWm, an attempt can be made to open a new session; after successful transmission of the MF-M packets, transmission of the MF-H packets starts up. Morita Expires - April 2004 [Page 10] MF-PHB October 2003 ===================================================================== !!LOSS!! +-----+ BWh - - - - - - - - - - - - - - - - - (4)|- m- |- - - - - - - - - - +----------------+ | H | +------------------+ | H | (3)+---------------------+ !!LOSS!! | H | +-----+ +-----------------------+ BWm - - - - (2)|- m- |- - - - - - - |- - - - - H - - - - - -| - - - +----------------------+ +-------------------------+ | M | H | | H | +-----------------------------------------------------------+ (1)| M | H | +-----------------------------------------------------------------+ | M | H | ===================================================================== ---> time M: a series of middle-subclass packets successfully transported H: a series of high-subclass packets successfully transported m: a series of middle-subclass packets discarded BWh: available bandwidth for H-subclass of MF-PHB in elastic mode BWm: available bandwidth for M-subclass of MF-PHB in elastic mode Figure 2. Elastic Mode of MF-PHB Elastic mode fulfills the additional or optional requirements (2), (3), and (4) of section 2.2. In the case of link failure, the switched-over traffic can be handled without admission control. This is also the case in hand-over for mobility. In the case of VBR, even if all established flows reach their maximum rates, the packets can be transported without any loss. In elastic mode, the traffic can be transported as long as it's certain that the amount of extra MF-H traffic will be below the BWh threshold. 4.Realization for MF-PHB We describe possible ways to realize MF-PHB. In general, EF (expedited forwarding), AF (assured-forwarding), and BE (best-effort) classes are assumed to be present in a Diffserv architecture. Packets for these classes are read out from the queue by a weighted scheduler. The scheduler ensures that EF packets are read out Morita Expires - April 2004 [Page 11] MF-PHB October 2003 regardless of the weight and offered loads of traffic in other classes. This is equivalent to giving EF packets the highest priority. According to the Diffserv architecture, there are two implementation alternatives of MF-PHB; one is enhancement of EF and the other is enhancement of AF. The former is the enhancement of priority process and the latter is the enhancement of weighted scheduler process. 4.1 Policer Enhancement to Realize Static Mode through EF-Class Extension (Two-Threshold Token Bucket) One way to realize the static mode of MF-PHB is to enhance the EF class and relevant priority processing. Firstly, we would like to examine the existing EF class. Since this class has the highest priority, we might think that it provides the best basis for a bandwidth guarantee. However, a maximum bandwidth limitation is not explicitly included in the current EF specification, and we cannot in general assume that the preferential handling of the EF class allows this capability. Furthermore, EF-PHB is a single class and doesn't in itself provide a method of priority transmission. EF packets are simply handled with the top priority, the expectation being that this will automatically achieve real-time transmission. Furthermore, integrity of the packet sequence is hard to evaluate, since the priority transmission is open. Next, let's consider how to realize MF-PHB by enhancing the priority- processing mechanism for the EF class. We want to expand the processing so that it also gives MF-class packets special treatment and, in particular, provides differentiated treatment of the MF-H and MF-M subclasses. Figure 3 shows two approaches to realize MF-PHB by enhancing EF class. One is by two additional queues with priority and the other is by a queue with discard threshold. Since EF and MF are assumed to be the top priority classes, we need an on-the-fly decision model based on the bandwidth being used at the time of packet arrival, rather than a model based on queues and a weighted scheduler. A policer controlled by a token-bucket algorithm will achieve this. The token bucket we consider here is simply a counter- driven checking process and not a queuing process. We note that the policing function here is located at the output interfaces of all routers and its operation is based on the classes of the packets, whereas the conventional policing function is located at the input interfaces of ingress routers and operates on a per-flow basis. Morita Expires - April 2004 [Page 12] MF-PHB October 2003 |> ------------------+ | > EF |------------------------>| > ------------------+ | > ==================+ | > MF-high |------------------------>| > ==================+ | > ==================+ | > MF-middle |------------------------>|Priority> ==================+ | >-----> ------------------+ |> | Queue > AF1 |---------->| > | > ------------------+ | > | > ------------------+ |WS >-------->| > AF2 |---------->| > | > ------------------+ | > | > ------------------+ |> | > BE |------------------------>| > ------------------+ |> WS: Weighted Scheduler |> ------------------+ | > EF |------------------------>| > ------------------+ | > =====V============+ | > MF-H | MF-H and M |------------------------>| > ==================+ | > ------------------+ |> | > AF1 |-----------| > |Priority> ------------------+ | > | >-----> ------------------+ | > | Queue > AF2 |---------->|WS >------->| > ------------------+ | > | > ------------------+ | > | > AF3 |---------->| > | > ------------------+ |> | > ------------------+ | > BE |------------------------>| > ------------------+ |> WS: Weighted Scheduler Figure 3. Two approaches to realize MF-PHB by enhancing EF class The token bucket for static mode operation should pass both the M and H sub-classes when the bandwidth in use is below BWmf; when it is above BWmf, the extra class-M packets should be discarded but the Morita Expires - April 2004 [Page 13] MF-PHB October 2003 class-H packets for existing flows should not. We propose a two- threshold token bucket to meet this requirement. Figure 4 illustrates the behavior of the two-threshold token bucket. One conventional threshold is zero and the new one is A. The initial value of the counter is B and the refresh rate of the counter is R. The token counter is decremented whenever a packet that satisfies the threshold conditions is sent. Probing (M-subclass) packets that arrive after the counter has reached the threshold are discarded. The router continues to pass media (H-subclass) packets until the counter reaches zero. By supplementing the conventional zero threshold with a further threshold, we get the router to pass media packets while ignoring probing packets when this is necessary for the MF scheme. After the arrival of each packet, the counter is incremented at the refresh rate, which corresponds to the BWmf. Packet arrival Tc' = Tc+R * (ta - LCT) | | No The packet is M? ----------------------+ Yes| | | No | No Tc' < N+A ? --------+ Tc' < N ? ---------+ Yes| | Yes| | | | | | V V V V Non-conforming Conforming Non-conforming Conforming M packet M packet H packet H packet | | | | | | | | V V V V No counter Tc=min(Tc',B)-N No counter Tc= min(Tc',B)-N updated updated TOKEN COUNTER Constants Token bucket rate: R byte/second Token bucket size: B bytes Offset value (intermediate threshold): A bytes Variables Token counter: Tc bytes Last conforming time: LCT seconds Variables per packet arrival Packet arrival time: ta seconds Packet size: N byte Tentative variable Tc' Initial values Morita Expires - April 2004 [Page 14] MF-PHB October 2003 Tc = B LCT = The arrival time of the first packet Figure 4. Two-threshold token bucket 4.2 Policer Enhancement to Realize Elastic Mode through EF-Class Extension (Two-Rate Token Bucket) For the elastic mode operation, we propose the use of two token counters, each running at a different rate. The lower-rate counter has two thresholds, i.e. zero and A. The initial value of the counter is Bm and its refresh rate is Rm. The higher-rate counter has one threshold, i.e. zero. The initial value of this counter is Bh and its refresh rate is Rh. Rh is higher than Rm. Figure 5 depicts the behavior. We decrement the lower-rate counter whenever a packet of either subclass is passed. When the lower-rate counter reaches threshold A, the router starts to discard M-subclass packets, updating neither counter when it does so. Even after the lower-rate counter has reached threshold A or zero, it may continue to pass packets of the H-subclass. Here, the router's decision is dependent on the other counter, i.e. the high-rate counter. As long as the value of this counter is more than zero, the router passes the packet and decrements the counter. While the higher-rate counter's value is at or below zero, H packets are discarded and the router doesn't decrement the counters. This behavior produces the following outcomes. While the rate of H- subclass packets is less than Rm which corresponds to BWm, and the total rate of both H and M packets is more than Rm, the extra M packets are discarded. We can often see this outcome in ordinary PPS operation. If the offered rate of H packets is greater than Rm and the total rate of both subclasses is above this threshold, the M packets should be discarded but the H packets are passed. If we use the two-rate token buckets, the H-subclass packets are not discarded as long as the offered rate is less than Rh. The elastic mode of MF- PHB handling is thus achieved. The bottom line of the elastic mode is the lower rate counter, Tc2 in Figure 5. In case that only Tc2 is used, when the arrived packet is H, the counter is always updated as Tc2=max(min(Tc2',Bm)-N,0). The advantage of using a policer-based approach is that it is easy to implement the elastic mode; all that's required is a slight enhancement to the token-bucket algorithm. Morita Expires - April 2004 [Page 15] MF-PHB October 2003 Packet arrival Tc1' = Tc1 + Rh * (ta - LCT1) Tc2' = Tc2 + Rm * (ta - LCT2) | | | No The packet is M ? -------------------+ Yes| | | | V No | No Tc2' < N+A ? -----+ Tc1' < N ? ---------+ Yes| | Yes| | | | | | | | | | V V V V Non-conforming Conforming Non-conforming Conforming M packet M packet H packet H packet | | | | | | | | V V V V No counter Tc1=min(Tc1',Bh)-N No counter Tc1=min(Tc1',Bh)-N updated Tc2=min(Tc2',Bm)-N updated Tc2=max(min(Tc2',Bm)-N,0) TOKEN COUNTER #1 Constants Token bucket rate: Rh byte/second Token bucket size: Bh bytes Variables Token counter: Tc1 bytes Last conforming time: LCT1 seconds Variables per packet arrival Packet arrival time: ta seconds Packet size: N byte Tentative variable Tc1' Initial values Tc1 = Bh LCT1 = The arrival time of the first packet TOKEN COUNTER #2 Constants Token bucket rate: Rm byte/second Token bucket size: Bm bytes Offset value (intermediate threshold): A bytes Variables Token counter: Tc2 bytes Last conforming time: LCT2 seconds Variables per packet arrival Morita Expires - April 2004 [Page 16] MF-PHB October 2003 Packet arrival time: ta seconds Packet size: N byte Tentative variable Tc2' Initial values Tc2 = Bm LCT2 = The arrival time of the first packet Figure 5. The two-token-bucket mechanism for elastic mode operation 4.3 Shaper Enhancement to Realize Static Mode through AF-Class Extension AF actually consists of four classes, each of which has three subclasses defined by three levels of drop precedence. There are thus two ways to realize MF-PHB based on the AF classes. One is to use a single AF class and two of the levels of drop precedence. The other is to use two of the AF classes with different weights. We will start by examining the single-AF-class case. The minimum bandwidth guarantee and maximum bandwidth limitation are the issues to consider. In particular, the maximum bandwidth limitation is hard to realize if a weighted scheduler is used to output packets, since the scheduler will take the non-PPS AF classes into account in scheduling the bandwidth allocated to all AF classes. We will require a traffic shaper to limit the rate of the AF class selected for PPS implementation, i.e. to provide a fixed bandwidth to the MF- PHB. The second possibility is to use two of the AF classes. It is harder to realize MF-PHB with this model, because the router must apply a common maximum bandwidth limitation to two AF queues. A traffic shaper is again able to provide the required limitations. This is completely beyond the scope of existing queuing mechanisms. Figure 6 shows two examples of implementation on the basis of AF classes, that is, shaper-based approaches. The shaper is at the output side of the queue. The shaper is preceded by a single AF queue for packets that have two levels of drop precedence or two AF queues when two classes with different priority levels are used. Matters of concern for this shaper-based realization of MF-PHB are delay characteristics and the difficulties with extension to provide elastic mode. When two AF queues are used, sequence integrity becomes a further concern. Morita Expires - April 2004 [Page 17] MF-PHB October 2003 |> ------------------+ | > EF |------------------------>| > ------------------+ | > ==================+ | > MF-high |---------->|> | > ==================+ | > | > ==================+ | > | > MF-middle |---------->| > |Priority> ==================+ | > | >-----> ------------------+ | WS >------>| Queue > AF1 |---------->| > | > ------------------+ | > | > ------------------+ | > | > AF2 |---------->| > | > ------------------+ |> | > ------------------+ | > BE |------------------------>| > ------------------+ |> WS: Weighted Scheduler |> ------------------+ | > EF |------------------------>| > ------------------+ | > =====V============+ | > MF-H | MF-H and M |---------->|> | > ==================+ | > | > ------------------+ | > | > AF1 |---------->| > |Priority> ------------------+ | > | >-----> ------------------+ | WS >------>| Queue > AF2 |---------->| > | > ------------------+ | > | > ------------------+ | > | > AF3 |---------->| > | > ------------------+ |> | > ------------------+ | > BE |------------------------>| > ------------------+ |> WS: Weighted Scheduler Figure 6. Two approaches to realize MF-PHB by enhancing AF class Security Considerations To be described. References Morita Expires - April 2004 [Page 18] MF-PHB October 2003 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 N. Morita and G. Karlsson, "Framework of Priority Promotion Scheme," Internet draft, October 2003. 4 N. Morita, "Verification scenarios for Measurable Forwarding PHB (Per-Hop Behavior)," Internet draft, October 2003. Author's Addresses Naotaka MORITA Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan EMail: morita.naotaka@lab.ntt.co.jp Morita Expires - April 2004 [Page 19]