Internet Draft R. Cohen Expires: September 2000 A. Zavalkovsky draft-ronc-domain-phb-set-specification-00.txt N. Elfassy Cisco Systems March 2000 Domain Per Hop Behavior Set Specification Abstract This memo introduces the concept of Domain PHB sets. A Domain PHB set allow the network administrator to control and tune PHB parameters within its DS domain in an abstract form. Derivation of specific configuration parameters from the Domain PHB set is included as well. 1. 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. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Introduction IETF Differential Service WG has standardized the EF PHB and AF PHB Group. Within a DS Domain, the network administrator needs to choose the set of standard and private PHBs he/she intends to use, and tune their parameters. As all PHBs provisioned on the domain need to share bandwidth and buffer resources in each hop, tuning should be Expiration: September 2000 [Page 1]
Draft Domain PHB Set Specification March 2000 made on the PHB set selected for the domain, and not individually per each PHB. This memo describes an abstract representation of the set of PHBs and a minimal set of parameters for their tuning. The intention is to provide tuning parameters that do not depend on particular mechanisms of individual queues implemented on each device. A standard definition of a PHB set is a mean for interoperability between different devices and vendors. 3. PHB set specification 3.1 Specification Terminology used in this memo is taken from [DSARCH] and [NEWTERMS]. The PHB Set specification is organized as a table of entries. Each entry contains parameters for a single PHB. Following parameters are defined per PHB: - Name: An identifying name for the PHB. Examples include EF, Mission Critical, AF12, etc. - DSCP: A PHB selector. Each PHB must have a distinct DSCP value. - Scheduling Class: A number identifying all PHBs that belong to the same scheduling class. Order of packets must be preserved for all PHB with the same scheduling class. - Default Class: A Boolean flag that must be set on one and only one of the PHB entries. This specifies the default PHB provided to flows with an unspecified PHB selector. The flag is set by default for Best Effort PHB. - Immediate Forwarding: A Boolean flag that specifies whether immediate forwarding of packets belonging to this PHB is required. This flag is set in EF PHB. - Reserved Bandwidth: Bandwidth in Kb/sec reserved for the behavior aggregate. For PHBs that do not require immediate forwarding, the reserved bandwidth value determines the minimal bandwidth reserved for this service. In immediate forwarding PHBs, the reserved bandwidth indicates the Maximal bandwidth allowed for this behavior aggregate. This limiting bandwidth is required in order not to starve other behavior aggregates. All PHBs with the same scheduling class share the same reserved bandwidth value. - Forwarding Factor: A percentage of the scheduling resources consumed by the behavior aggregate. This is an alternative representation of the reserved bandwidth field. It allows the network administrator to manage its scheduling resources without knowledge of the particular link speeds. Within a domain PHB set, a mixed assignment of forwarding factors to some scheduling classes and reserved bandwidth Expiration: September 2000 [Page 2]
Draft Domain PHB Set Specification March 2000 to others classes is allowed. - Reserved Packets: Number of packets reserved in queue prior to discard. Large values allows sustain of bursts. Within a scheduling class, this parameter specifies the relative drop precedence of PHBs. For example, within the AF PHB group, the total number of packets reserved for A1x is assigned to A11, while smaller numbers of packets are reserved for the A12 and A13 PHBs respectively. - Buffer Factor: A percentage of the buffer resources kept for this behavior aggregate. This is an alternative representation of the Reserved Packets field. It allows the network administrator to manage its buffer resources without knowledge of the particular queue lengths. In order to translate the buffer factor field into Actual Reserved Packet field, a global parameter specifying the total buffer space should be used. The sum of buffer factors assigned to the scheduling classes is 100%. Within each scheduling class, the buffer factor specifies the relative drop precedence of the PHBs. - Traffic type: A flag that specifies whether the traffic of this behavior aggregate is elastic or not. Most TCP traffic is elastic, as it can adapt to the available network resources. RED discard mechanism is useful for elastic PHBs. An example for non-elastic traffic is UDP traffic carrying Voice. For this type of traffic, RED does not provide any benefit. - Packet Size: A parameter that describes the typical packet size in bytes of traffic of this behavior aggregate. This parameter is used when there is a need to arrive at a byte count representation of reserved packets field. For some schedulers a drain-size parameter is required per queue. Drain size determines the number of bytes a scheduler fetches from each queue in each cycle. The ratio between drain-sizes is determined by either the ratio between the reserved bandwidth field or the ratio between the forwarding factors. Drain-size absolute values per queue should approximate a multiple of a typical packet size and not be smaller than one packet size of the PHB the queue serves. - Max Per Hop Delay: A parameter that describes the maximal delay in msecs before a packet of this behavior aggregate is forwarded. This parameter is relevant mostly to immediate forwarding PHBs. On slow speed interfaces, this parameter allows to calculate whether fragmentation and interleave of packets is required. Examples of such mechanisms include MPPP or Frame-Relay FRF-12 LFI. The fragment size (fs) is determined according to the following formula: fs = max-phop-delay/link-speed. If fs is larger than link MTU, fragmentation and interleave is not required. Expiration: September 2000 [Page 3]
Draft Domain PHB Set Specification March 2000 3.2 Example: PHB set with AF and EF PHBs In this example the network administrator wishes to provide QoS for different applications. The primary applications he/she considers are Voice-over-IP and Mission Critical applications. The user decides to use the EF PHB to answer the tight delay and jitter requirements of VOIP traffic, and provide 'better than best effort' PHB to the mission critical applications. For the latter purpose, the network administrator chooses an AF-like PHB. As not all PHBs of the AF PHB groups were required, only a single AF class, AF1x is used, using only AF11 and AF12. +----------------+--------+--------+--------+--------+ | Name | BE | AF11 | AF12 | EF | +----------------+--------+--------+--------+--------+ | DSCP | 0 | 10 | 12 | 46 | +----------------+--------+--------+--------+--------+ | Scheduling | 0 | 1 | 1 | 2 | | Class | | | | | +----------------+--------+--------+--------+--------+ | Default |default | | | | +----------------+--------+--------+--------+--------+ | Immediate | | | |Immediat| +----------------+--------+--------+--------+--------+ | Reserved | 64Kb/s |512Kb/s | ----- |512Kb/s | | Bandwidth | | | | | +----------------+--------+--------+--------+--------+ | Forwarding | | | | | | Factor | | | | | +----------------+--------+--------+--------+--------+ | Reserved | | | | | | Packets | | | | | +----------------+--------+--------+--------+--------+ | Buffer | 30% | 60% | 30% | 10% | | Factor | | | | | +----------------+--------+--------+--------+--------+ | Packet Size | 1500 | 1500 | 1500 | 200 | +----------------+--------+--------+--------+--------+ | Traffic Type |elastic |elastic |elastic |non-elas| +----------------+--------+--------+--------+--------+ | Per Hop Delay | -- | -- | -- | 20msec | +----------------+--------+--------+--------+--------+ The network administrator in this example chose to specify the reserved bandwidth. On specific interfaces within the system the forwarding factor can be calculated. The AF12 PHB reserved bandwidth is equal to the AF11 specification. He/she chose to partition the buffer space using the buffer factor parameter. Translation to reserved packet in queue can be done on specific interface according to the total buffer space on this interface. The buffer factor of AF12 is smaller than the buffer factor of AF12, reflecting the higher drop precedence. Expiration: September 2000 [Page 4]
Draft Domain PHB Set Specification March 2000 4. Mapping a PHB Set to device configuration The PHB set specification allows automatic construction of set of specific device configuration parameters. Current work within the Differential Service WG offers several alternatives to model PHB configuration on devices [DMIB, PIB]. In each model, the required configuration of queues and actions can be derived from the PHB set specification. One can construct queue configurations in each of the models that can not be derived from a PHB set. We believe that the PHB set specification should model only viable PHBs, in a relatively simple way. For example, some queue models allow for multiple scheduling priority levels. As the need of more than two levels of priority is yet to be proven to lead to meaningful PHBs, we chose to provide only one priority level denoted by the intermediate forwarding flag. Here we provide an example of how queue and actions define in [DMIB] can be configured. We refer to [DMIB] for detailed explanations of each of the fields. Queues are modeled as a set of independent FIFO queues, each with the following parameters: DiffServQueueEntry ::= SEQUENCE { diffServQueueNumber INTEGER, diffServQueueMinimumRate Unsigned32, diffServQueueMaximumRate Unsigned32, diffServQueuePriority Unsigned32, diffServQueueNextTCB RowPointer, diffServQueueStatus RowStatus } The example PHB set defined above can be mapped to: +-----------------------+-------+------+-------+ | Name | BE | AF | EF | +-----------------------+-------+------+-------+ | DServQueueNumber | 1 | 2 | 3 | +-----------------------+-------+------+-------+ | DServQueueMinimumRate | 64 | 512 | -- | +-----------------------+-------+------+-------+ | DservQueueMaximumRate | -- | -- | 512 | +-----------------------+-------+------+-------+ | DServQueuePriority | 0 | 0 | 1 | +-----------------------+-------+------+-------+ | DServQueueNextTCB | NULL | NULL | NULL | +-----------------------+-------+------+-------+ In order to get full PHB configuration within the model introduced in [DMIB], the action entry configuration should be specified as well. The actions are modeled using: Expiration: September 2000 [Page 5]
Draft Domain PHB Set Specification March 2000 DiffServActionEntry ::= SEQUENCE { diffServActionNumber INTEGER, diffServActionNext RowPointer, diffServActionDSCP Dscp, diffServActionMinThreshold Unsigned32, diffServActionMaxThreshold Unsigned32, diffServActionDropPolicy INTEGER, diffServActionStatus RowStatus } We have omitted the statistic counters. The example PHB set provided above is mapped to the following: +-----------------------+-------+------+------+------+ | DservActionNumber | 1 | 2 | 3 | 4 | +-----------------------+-------+------+------+------+ | DservActionNext |queue1 |queue2|queue2|queue3| +-----------------------+-------+------+------+------+ | DServActionDSCP | BE | AF11 | AF12 | EF | +-----------------------+-------+------+------+------+ | DservActionMinThreshold 2pckts|4pckts|2pckts|2pckts| +-----------------------+-------+------+------+------+ | DservActionMaxThreshold 6pckts|12pckt|6pckts|2pckts| +-----------------------+-------+------+------+------+ | DservActionDropPolicy |random |random|random| tail | +-----------------------+-------+------+------+------+ We assume here that the total-packet-in-queue parameter is set to 20 packets. The buffer factor percentages determine the max thresholds. The minimum thresholds are not determined by the PHB set specification. We believe that RED minimal thresholds can be determined automatically either according to best practice by automatically adjusting to network behavior. For RED thresholds, we have set the min threshold to be 1/3 of the max threshold. Fragmentation and interleave are not modeled within [DMIB]. Some links may not be able to admit the reserved bandwidth required for eachof the scheduling classes. The provisioning system used should detect these links and report back an admission error. Some devices may not be able to implement this PHB set, either because not enough queues are available, or because the scheduler can not provide preemptive scheduling. The provisioning system used should detect those deficient devices and report back an error. In order to provide best approximate PHB configuration that can be implemented on a deficient device, additional information should be specified in the PHB set. For example, if only 2 queues are available on the device, the PHB set should specify whether AF and BE should be mapped to the same queue, or whether EF and AF should. Heuristics and additional information required for mapping PHB sets to deficient devices are outside of the scope of this document. Expiration: September 2000 [Page 6]
Draft Domain PHB Set Specification March 2000 5. Acknowledgments 6. Security Considerations Management of PHBs within a DS Domain requires adequate security measures. These measures are outside the scope of this memo and should be covered in the appropriate protocols used for provisioning the network. 7. Intellectual Property Considerations Cisco may have IPR on material contained in this draft. Upon approval by the IESG of the relevant Internet standards track specification and if any patents issue to Cisco or its subsidiaries with claims that are necessary for practicing this standard, any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non- discriminatory terms. 8. Reference [EF] V. Jacobson, K. Nichols, K. Poduri, " An Expedited Forwarding PHB", RFC2598, September 1999 [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC2597, September 1999 [DSARCH] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC2475, December 1998 [NEWTERMS] D. Grossman, "New Terminology for Diffserv", draft-ietf-diffserv-new-terms-00.txt, October 1999 [DMIB] F. Baker, "Management Information Base for the Differentiated Services Architecture", draft-ietf-diffserv-mib-00.txt, July 1999. [PIB] M. Fine, K. McCloghrie, j. Seligson, K. Chan, S. Hahn, A. Smith, "Quality of Service Policy Information Base", draft-mfine-cops-pib-01.txt, 25 September 1999 Expiration: September 2000 [Page 6]
Draft Domain PHB Set Specification March 2000 9. Authors' Address Ron Cohen Cisco Systems, Inc. Phone: +972-9-9700064 4 Maskit St. Email: ronc@cisco.com Herzeliya Pituach, Israel 46766 Arthur Zavalkovsky Cisco Systems, Inc. Phone: +972-9-9700088 4 Maskit St. Email: arthurz@cisco.com Herzeliya Pituach, Israel 46766 Nitsan Elfassy Cisco Systems, Inc. Phone: +972-9-9700066 4 Maskit St. Email: nitsan@cisco.com Herzeliya Pituach, Israel 46766 Expiration: September 2000 [Page 7]