tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3670

Proposed STD
Pages: 97
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: POLICY

Information Model for Describing Network Device QoS Datapath Mechanisms

Part 1 of 4, p. 1 to 9
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                           B. Moore
Request for Comments: 3670                               IBM Corporation
Category: Standards Track                                      D. Durham
                                                                   Intel
                                                            J. Strassner
                                                        INTELLIDEN, Inc.
                                                           A. Westerinen
                                                           Cisco Systems
                                                                W. Weiss
                                                                Ellacoya
                                                            January 2004


                   Information Model for Describing
                Network Device QoS Datapath Mechanisms

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   The purpose of this document is to define an information model to
   describe the quality of service (QoS) mechanisms inherent in
   different network devices, including hosts.  Broadly speaking, these
   mechanisms describe the properties common to selecting and
   conditioning traffic through the forwarding path (datapath) of a
   network device.  This selection and conditioning of traffic in the
   datapath spans both major QoS architectures: Differentiated Services
   and Integrated Services.

   This document should be used with the QoS Policy Information Model
   (QPIM) to model how policies can be defined to manage and configure
   the QoS mechanisms (i.e., the classification, marking, metering,
   dropping, queuing, and scheduling functionality) of devices.
   Together, these two documents describe how to write QoS policy rules
   to configure and manage the QoS mechanisms present in the datapaths
   of devices.

Page 2 
   This document, as well as QPIM, are information models.  That is,
   they represent information independent of a binding to a specific
   type of repository.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Policy Management Conceptual Model . . . . . . . . . . .  6
       1.2.  Purpose and Relation to Other Policy Work. . . . . . . .  7
       1.3.  Typical Examples of Policy Usage . . . . . . . . . . . .  7
   2.  Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.1.  Common Needs Of DiffServ and IntServ . . . . . . . . . .  8
       2.2.  Specific Needs Of DiffServ . . . . . . . . . . . . . . .  9
       2.3.  Specific Needs Of IntServ. . . . . . . . . . . . . . . .  9
   3.  Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.  Level of Abstraction for Expressing QoS Policies . . . . 10
       3.2.  Specifying Policy Parameters . . . . . . . . . . . . . . 11
       3.3.  Specifying Policy Services . . . . . . . . . . . . . . . 12
       3.4.  Level of Abstraction for Defining QoS Attributes and
             Classes. . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.5.  Characterization of QoS Properties . . . . . . . . . . . 14
       3.6.  QoS Information Model Derivation . . . . . . . . . . . . 15
       3.7.  Attribute Representation . . . . . . . . . . . . . . . . 16
       3.8.  Mental Model . . . . . . . . . . . . . . . . . . . . . . 17
             3.8.1.  The QoSService Class . . . . . . . . . . . . . . 17
             3.8.2.  The ConditioningService Class. . . . . . . . . . 18
             3.8.3.  Preserving QoS Information from Ingress to
                     Egress . . . . . . . . . . . . . . . . . . . . . 19
       3.9.  Classifiers, FilterLists, and Filter Entries . . . . . . 21
       3.10. Modeling of Droppers . . . . . . . . . . . . . . . . . . 23
             3.10.1. Configuring Head and Tail Droppers . . . . . . . 23
             3.10.2. Configuring RED Droppers . . . . . . . . . . . . 24
       3.11. Modeling of Queues and Schedulers. . . . . . . . . . . . 25
             3.11.1. Simple Hierarchical Scheduler. . . . . . . . . . 25
             3.11.2. Complex Hierarchical Scheduler . . . . . . . . . 27
             3.11.3. Excess Capacity Scheduler. . . . . . . . . . . . 29
             3.11.4. Hierarchical CBQ Scheduler . . . . . . . . . . . 31
   4.  The Class Hierarchy. . . . . . . . . . . . . . . . . . . . . . 33
       4.1.  Associations and Aggregations. . . . . . . . . . . . . . 33
       4.2.  The Structure of the Class Hierarchies . . . . . . . . . 34
       4.3.  Class Definitions. . . . . . . . . . . . . . . . . . . . 38
             4.3.1.  The Abstract Class ManagedElement. . . . . . . . 38
             4.3.2.  The Abstract Class ManagedSystemElement. . . . . 39
             4.3.3.  The Abstract Class LogicalElement. . . . . . . . 39
             4.3.4.  The Abstract Class Service . . . . . . . . . . . 39
             4.3.5.  The Class ConditioningService. . . . . . . . . . 39
             4.3.6.  The Class ClassifierService. . . . . . . . . . . 40
             4.3.7.  The Class ClassifierElement. . . . . . . . . . . 41

Top      ToC       Page 3 
             4.3.8.  The Class MeterService . . . . . . . . . . . . . 42
             4.3.9.  The Class AverageRateMeterService. . . . . . . . 44
             4.3.10. The Class EWMAMeterService . . . . . . . . . . . 44
             4.3.11. The Class TokenBucketMeterService. . . . . . . . 46
             4.3.12. The Class MarkerService. . . . . . . . . . . . . 47
             4.3.13. The Class PreambleMarkerService. . . . . . . . . 47
             4.3.14. The Class ToSMarkerService . . . . . . . . . . . 48
             4.3.15. The Class DSCPMarkerService. . . . . . . . . . . 49
             4.3.16. The Class 8021QMarkerService . . . . . . . . . . 49
             4.3.17. The Class DropperService . . . . . . . . . . . . 50
             4.3.18. The Class HeadTailDropperService . . . . . . . . 52
             4.3.19. The Class REDDropperService. . . . . . . . . . . 52
             4.3.20. The Class QueuingService . . . . . . . . . . . . 54
             4.3.21. The Class PacketSchedulingService. . . . . . . . 55
             4.3.22. The Class NonWorkConservingSchedulingService . . 56
             4.3.23. The Class QoSService . . . . . . . . . . . . . . 57
             4.3.24. The Class DiffServService. . . . . . . . . . . . 58
             4.3.25. The Class AFService. . . . . . . . . . . . . . . 59
             4.3.26. The Class FlowService. . . . . . . . . . . . . . 60
             4.3.27. The Class DropThresholdCalculationService. . . . 60
             4.3.28. The Abstract Class FilterEntryBase . . . . . . . 61
             4.3.29. The Class IPHeaderFilter . . . . . . . . . . . . 62
             4.3.30. The Class 8021Filter . . . . . . . . . . . . . . 62
             4.3.31. The Class PreambleFilter . . . . . . . . . . . . 62
             4.3.32. The Class FilterList . . . . . . . . . . . . . . 63
             4.3.33. The Abstract Class ServiceAccessPoint. . . . . . 63
             4.3.34. The Class ProtocolEndpoint . . . . . . . . . . . 63
             4.3.35. The Abstract Class Collection. . . . . . . . . . 65
             4.3.36. The Abstract Class CollectionOfMSEs. . . . . . . 65
             4.3.37. The Class BufferPool . . . . . . . . . . . . . . 65
             4.3.38. The Abstract Class SchedulingElement . . . . . . 65
             4.3.39. The Class AllocationSchedulingElement. . . . . . 66
             4.3.40. The Class WRRSchedulingElement . . . . . . . . . 67
             4.3.41. The Class PrioritySchedulingElement. . . . . . . 69
             4.3.42. The Class BoundedPrioritySchedulingElement . . . 70
       4.4.  Association Definitions. . . . . . . . . . . . . . . . . 70
             4.4.1.  The Abstract Association Dependency. . . . . . . 71
             4.4.2.  The Association ServiceSAPDependency . . . . . . 71
             4.4.3.  The Association
                     IngressConditioningServiceOnEndpoint . . . . . . 71
             4.4.4.  The Association
                     EgressConditioningServiceOnEndpoint. . . . . . . 72
             4.4.5.  The Association HeadTailDropQueueBinding . . . . 72
             4.4.6.  The Association CalculationBasedOnQueue. . . . . 73
             4.4.7.  The Association ProvidesServiceToElement . . . . 74
             4.4.8.  The Association ServiceServiceDependency . . . . 74
             4.4.9.  The Association CalculationServiceForDropper . . 75
             4.4.10. The Association QueueAllocation. . . . . . . . . 75

Top      ToC       Page 4 
             4.4.11. The Association ClassifierElementUsesFilterList. 76
             4.4.12. The Association AFRelatedServices. . . . . . . . 77
             4.4.13. The Association NextService. . . . . . . . . . . 78
             4.4.14. The Association
                     NextServiceAfterClassifierElement. . . . . . . . 79
             4.4.15. The Association NextScheduler. . . . . . . . . . 80
             4.4.16. The Association FailNextScheduler. . . . . . . . 81
             4.4.17. The Association NextServiceAfterMeter. . . . . . 82
             4.4.18. The Association QueueToSchedule. . . . . . . . . 83
             4.4.19. The Association SchedulingServiceToSchedule. . . 84
             4.4.20. The Aggregation MemberOfCollection . . . . . . . 85
             4.4.21. The Aggregation CollectedBufferPool. . . . . . . 85
             4.4.22. The Abstract Aggregation Component . . . . . . . 86
             4.4.23. The Aggregation ServiceComponent . . . . . . . . 86
             4.4.24. The Aggregation QoSSubService. . . . . . . . . . 86
             4.4.25. The Aggregation QoSConditioningSubService. . . . 87
             4.4.26. The Aggregation
                     ClassifierElementInClassifierService . . . . . . 88
             4.4.27. The Aggregation EntriesInFilterList. . . . . . . 89
             4.4.28. The Aggregation ElementInSchedulingService . . . 90
   5.  Intellectual Property Statement. . . . . . . . . . . . . . . . 91
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 91
   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 91
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 92
       8.1. Normative References. . . . . . . . . . . . . . . . . . . 92
       8.2. Informative References  . . . . . . . . . . . . . . . . . 92
   9.  Appendix A:  Naming Instances in a Native CIM Implementation . 94
       9.1. Naming Instances of the Classes Derived from Service. . . 94
       9.2. Naming Instances of Subclasses of FilterEntryBase . . . . 94
       9.3. Naming Instances of ProtocolEndpoint. . . . . . . . . . . 94
       9.4. Naming Instances of BufferPool. . . . . . . . . . . . . . 95
             9.4.1.  The Property CollectionID. . . . . . . . . . . . 95
             9.4.2.  The Property CreationClassName . . . . . . . . . 95
       9.5. Naming Instances of SchedulingElement . . . . . . . . . . 95
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 96
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 97

1. Introduction

   The purpose of this document is to define an information model to
   describe the quality of service (QoS) mechanisms inherent in
   different network devices, including hosts.  Broadly speaking, these
   mechanisms describe the attributes common to selecting and
   conditioning traffic through the forwarding path (datapath) of a
   network device.  This selection and conditioning of traffic in the
   datapath spans both major QoS architectures: Differentiated Services
   (see [R2475]) and Integrated Services (see [R1633]).

Top      ToC       Page 5 
   This document is intended to be used with the QoS Policy Information
   Model [QPIM] to model how policies can be defined to manage and
   configure the QoS mechanisms (i.e., the classification, marking,
   metering, dropping, queuing, and scheduling functionality) of
   devices.  Together, these two documents describe how to write QoS
   policy rules to configure and manage the QoS mechanisms present in
   the datapaths of devices.

   This document, as well as [QPIM], are information models.  That is,
   they represent information independent of a binding to a specific
   type of repository.  A separate document could be written to provide
   a mapping of the data contained in this document to a form suitable
   for implementation in a directory that uses (L)DAP as its access
   protocol.  Similarly, a document could be written to provide a
   mapping of the data in [QPIM] to a directory. Together, these four
   documents (information models and directory schema mappings) would
   then describe how to write QoS policy rules that can be used to store
   information in directories to configure device QoS mechanisms.

   The approach taken in this document defines a common set of classes
   that can be used to model QoS in a device datapath. Vendors can then
   map these classes, either directly or using an intervening format
   like a COP-PR PIB, to their own device-specific implementations.
   Note that the admission control element of Integrated Services is not
   included in the scope of this model.

   The design of the class, association, and aggregation hierarchies
   described in this document is influenced by the Network QoS submodel
   defined by the Distributed Management Task Force (DMTF) - see [CIM].
   These hierarchies are not derived from the Policy Core Information
   Model [PCIM].  This is because the modeling of the QoS mechanisms of
   a device is separate and distinct from the modeling of policies that
   manage those mechanisms.  Hence, there is a need to separate QoS
   mechanisms (this document) from their control (specified using the
   generic policy document [PCIM] augmented by the QoS Policy document
   [QPIM]).

   While it is not a policy model per se, this document does have a
   dependency on the Policy Core Information Model Extensions document
   [PCIME].  The device-level packet filtering, through which a
   Classifier splits a traffic stream into multiple streams, is based on
   the FilterEntryBase and FilterList classes defined in [PCIME].

   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 BCP 14, RFC 2119
   [R2119].

Top      ToC       Page 6 
1.1.  Policy Management Conceptual Model

   The Policy Core Information Model [PCIM] describes a general
   methodology for constructing policy rules.  PCIM Extensions [PCIME]
   updates and extends the original PCIM.  A policy rule aggregates a
   set of policy conditions and an ordered set of policy actions.  The
   semantics of a policy rule are such that if the set of conditions
   evaluates to TRUE, then the set of actions are executed.

   Policy conditions and actions have two principal components: operands
   and operators.  Operands can be constants or variables. To specify a
   policy, it is necessary to specify:

   o  the operands to be examined (also known as state variables);

   o  the operands to be changed (also known as configuration
      variables);

   o  the relationships between these two sets of operands.

   Operands can be specified at a high-level, such as Joe (a user) or
   Gold (a service).  Operands can also be specified at a much finer
   level of detail, one that is much closer to the operation of the
   device.  Examples of the latter include an IP Address or a queue's
   bandwidth allocation.  Implicit in the use of operands is the binding
   of legal values or ranges of values to an operand.  For example, the
   value of an IP address cannot be an integer.  The concepts of
   operands and their ranges are defined in [PCIME].

   The second component of policy conditions and actions is a set of
   operators.  Operators can express both relationships (greater than,
   member of a set, Boolean OR, etc.) and assignments.  Together,
   operators and operands can express a variety of conditions and
   actions, such as:

      If Bob is an Engineer...
      If the source IP address is in the Marketing Subnet...
      Set Joe's IP address to 192.0.2.100
      Limit the bandwidth of application x to 10 Mb

   We recognize that the definition of operator semantics is critical to
   the definition of policies.  However, the definition of these
   operators is beyond the scope of this document.  Rather, this
   document (with [QPIM]) takes the first steps in identifying and
   standardizing a set of properties (operands) for use in defining
   policies for Differentiated and Integrated Services.

Top      ToC       Page 7 
1.2.  Purpose and Relation to Other Policy Work

   This model establishes a canonical model of the QoS mechanisms of a
   network device (e.g., a router, switch, or host) that is independent
   of any specific type of network device.  This enables traffic
   conditioning to be described using a common set of abstractions,
   modeled as a set of services and sub-services.

   When the concepts of this document are used in conjunction with the
   concepts of [QPIM], one is able to define policies that bind the
   services in a network to the needs of applications using that
   network.  In other words, the business requirements of an
   organization can be reflected in one set of policies, and those
   policies can be translated to a lower-level set of policies that
   control and manage the configuration and operation of network
   devices.

1.3.  Typical Examples of Policy Usage

   Policies could be implemented as low-level rules using the
   information model described in this specification.  For example, in a
   low-level policy, a condition could be represented as an evaluation
   of a specific attribute from this model.  Therefore, a condition such
   as "If filter = HTTP" would be interpreted as a test determining
   whether any HTTP filters have been defined for the device.  A high-
   level policy, such as "If protocol = HTTP, then mark with
   Differentiated Services Code Point (DSCP) 24," would be expressed as
   a series of actions in a low-level policy using the classes and
   attributes described below:

   1.  Create HTTP filter
   2.  Create DSCP marker with the value of 24
   3.  Bind the HTTP filter to the DSCP marker

   Note that unlike "mark with DSCP 24," these low-level actions are not
   performed on a packet as it passes through the device. Rather, they
   are configuration actions performed on the device itself, to make it
   ready to perform the correct action(s) on the correct packet(s).  The
   act of moving from a high-level policy rule to the correct set of
   low-level device configuration actions is an example of what
   [POLTERM] characterizes as "policy translation" or "policy
   conversion".

Top      ToC       Page 8 
2.  Approach

   QoS activities in the IETF have mainly focused in two areas,
   Integrated Services (IntServ) and Differentiated Services (DiffServ)
   (see [POLTERM], [R1633] and [R2475]).  This document focuses on the
   specification of QoS properties and classes for modeling the datapath
   where packet traffic is conditioned. However, the framework defined
   by the classes in this document has been designed with the needs of
   the admission control portion of IntServ in mind as well.

2.1.  Common Needs Of DiffServ and IntServ

   First, let us consider IntServ.  IntServ has two principal
   components.  One component is embedded in the datapath of the
   networking device.  Its functions include the classification and
   policing of individual flows, and scheduling admitted packets for the
   outbound link.  The other component of IntServ is admission control,
   which focuses on the management of the signaling protocol (e.g., the
   PATH and RESV messages of RSVP).  This component processes
   reservation requests, manages bandwidth, outsources decision making
   to policy servers, and interacts with the Routing Table manager.

   We will consider RSVP when defining the structure of this information
   model.  As this document focuses on the datapath, elements of RSVP
   applicable to the datapath will be considered in the structure of the
   classes.  The complete IntServ device model will, as we have
   indicated earlier, be addressed in a subsequent document.

   This document models a small subset of the QoS policy problem, in
   hopes of constructing a methodology that can be adapted for other
   aspects of QoS in particular, and of policy construction in general.
   The focus in this document is on QoS for devices that implement
   traffic conditioning in the datapath.

   DiffServ operates exclusively in the datapath.  It has all of the
   same components of the IntServ datapath, with two major differences.
   First, DiffServ classifies packets based solely on their DSCP field,
   whereas IntServ examines a subset of a standard flow's addressing 5-
   tuple.  The exception to this rule occurs in a router or host at the
   boundary of a DiffServ domain.  A device in this position may examine
   a packet's DSCP, its addressing 5-tuple, other fields in the packet,
   or even information wholly outside the packet, in determining the
   DSCP value with which to mark the packet prior to its transfer into
   the DiffServ domain.  However, routers in the interior of a DiffServ
   domain will only need to classify based on the DSCP field.

Top      ToC       Page 9 
   The second difference between IntServ and DiffServ is that the
   signaling protocol used in IntServ (e.g., RSVP) affects the
   configuration of the datapath in a more dynamic fashion.  This is
   because each newly admitted RSVP reservation requires a
   reconfiguration of the datapath.  In contrast, DiffServ requires far
   fewer changes to the datapath after the Per Hop Behaviors (PHBs) have
   been configured.

   The approach advocated in this document for the creation of policies
   that control the various QoS mechanisms of networking devices is to
   first identify the attributes with which policies are to be
   constructed.  These attributes are the parameters used in expressions
   that are necessary to construct policies.  There is also a parallel
   desire to define the operators, relations, and precedence constructs
   necessary to construct the conditions and actions that constitute
   these policies.  However, these efforts are beyond the scope of this
   document.

2.2.  Specific Needs Of DiffServ

   DiffServ-specific rules focus on two particular areas: the core and
   the edges of the network.  As explained in the DiffServ Architecture
   document [R2475], devices at the edge of the network classify traffic
   into different traffic streams.  The core of the network then
   forwards traffic from different streams by using a set of Per Hop
   Behaviors (PHBs).  A DSCP identifies each PHB. The DSCP is part of
   the IP header of each packet (as described in [R2474]).  This enables
   multiple traffic streams to be aggregated into a small number of
   aggregated traffic streams, where each aggregate traffic stream is
   identified by a particular DSCP, and forwarded using a particular
   PHB.

   The attributes used to manipulate QoS capabilities in the core of the
   network primarily address the behavioral characteristics of each
   supported PHB.  At the edges of the DiffServ network, the additional
   complexities of flow classification, policing, RSVP mappings,
   remarkings, and other factors have to be considered. Additional
   modeling will be required in this area.  However, first, the
   standards for edges of the DiffServ network need more detail - to
   allow the edges to be incorporated into the policy model.

2.3.  Specific Needs Of IntServ

   This document focuses exclusively on the forwarding aspects of
   network QoS.  Therefore, while the forwarding aspects of IntServ are
   considered, the management of IntServ is not considered. This topic
   will be addressed in a future document.


Next RFC Part