Operating System

Specification of Incremental Functionality Supported by Third Party Policy Enforcement Points and Policy Decision PointsUpdated Thursday, December 02, 1999

White Paper

Abstract

This document specifies various levels of PEP and PDP functionality that may be implemented by network equipment vendors in support of signaled QoS. All specified functionality is based on open standards and published protocols.

© 1999 Microsoft Corporation. All rights reserved.The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.Microsoft, ActiveX, the BackOffice logo, DirectShow, Visual Basic, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.Other product or company names mentioned herein may be the trademarks of their respective owners.Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA0999

REVISION HISTORY

Overview:1. Added statement clarifying the purpose of the document.

Section 1.1:1. Added references to related white papers.

Section 1.3:1. Changed "one or more standard configuration protocols" to "one or more well-known configuration

protocols".2. Added text to the last two paragraphs to clarify the meaning of 'gleaning classification information'.

Section 2:1. Modified first statement regarding support for traffic handling mechanisms.

Section 2.1:1. Added section 2.1.2 on the applicability of the aforementioned traffic handling mechanisms.2. Added footnote #2.

Section 3.1:1. Changed first sentence to read "to optimize" instead of "for correct".2. Added sentence clarifying the intended meaning of 'shared media networks'.

Section 3.3:1. Added sentence clarifying admission of resource requests on a 'per-service level basis'.2. Added text clarifying distinction between resource-based admission control and policy based

admission control.

Section 3.3.1:1. Added reference to MSQOSMECH.

Section 3.3.2:1. Significant text changes to clarify interpretation of the table.

Section 3.3.4:1. Added second paragraph to expand on DCLASS/TCLASS support.

Section 3.3.5:1. Added text to clarify applicability of 'aggregate policing'.

Section 3.4:1. Added section 3.4.6 regarding the use of the Active Directory.

Section 3.4.2:1. Added text recommending the use of COPS.2. Removed footnote regarding COPS.3. Added text clarifying the distinction between 'run-time' vs. 'provisioning-time'.4. Added paragraph explaining how resource based and policy based resource limits are used in

combination.5. Added text clarifying the use of interface as an index to select different policies.6. Deleted text referring to the number of bits in DCLASS and TCLASS objects.

Section 3.4.3:1. Added text regarding the option for the policy system to apply quantitative parameters in response to

requests for null service.

Section 3.5:1. Deleted last sentence of first paragraph.

Section 3.5:1. Added text explaining the hierarchy of becoming a DSBM.

Section 3.5.2:2. Deleted sentence starting "Devices winning".3. Added sentence regarding the need for UI to configure the NON_RESV_SEND_LIMIT.

References:1. Added two references (MSQOSMECH and MSQOSCOMP).2. Changed reference for [CURRENT_APPIDS] to provide URL.3. Added reference (COPS-RSVP).

Footnote 1:1. Added reference to MSQOSMECH.

Overview 31.1 DOCUMENT ORGANIZATION..............................................................................................................31.2 CONCEPTUAL DIAGRAM OF PEP/PDP ELEMENTS............................................................................31.3 THE ROLE OF THE PEP/PDP IN END-TO-END SIGNALED QOS.........................................................3

2 TRAFFIC HANDLING MECHANISMS.............................................................................................4

2.1 MOTIVATION.....................................................................................................................................42.1.1 Incremental Functionality - Traffic Handling Mechanisms.....................................................4

3 RSVP SIGNALING AND ADMISSION CONTROL AGENT FUNCTIONALITY.......................5

3.1 SBM CLIENTS...................................................................................................................................53.1.1 Motivation.................................................................................................................................53.1.2 Incremental Functionality - SBM Client...................................................................................6

3.2 RSVP SNOOPING FUNCTIONALITY...................................................................................................63.2.1 Motivation.................................................................................................................................63.2.2 RSVP Message Parsing Functionality......................................................................................73.2.3 Incremental Functionality - Use of Policy Objects as Policy Locators...................................73.2.4 Incremental Functionality - Use of SPI Instead of Filterspec..................................................8

3.3 RESOURCE-BASED QUANTITATIVE ADMISSION CONTROL AGENTS.................................................83.3.1 Motivation.................................................................................................................................83.3.2 Incremental Functionality - Resource Based Admission Control............................................83.3.3 Incremental Functionality - Aggregate Traffic Handling........................................................93.3.4 Incremental Functionality - DCLASS or TCLASS Object Support..........................................93.3.5 Incremental Functionality - Aggregate Policing......................................................................9

3.4 POLICY BASED ADMISSION CONTROL AGENTS..............................................................................103.4.1 Motivation...............................................................................................................................103.4.2 Incremental Functionality – Policy-Based Admission Control..............................................103.4.3 Incremental Functionality - Null (Qualitative) Service Support............................................113.4.4 Incremental Functionality - Use of Existing Active Directory Schema..................................113.4.5 Incremental Functionality - Extending the Active Directory Schema....................................11

3.5 DSBM FUNCTIONALITY..................................................................................................................113.5.1 Motivation...............................................................................................................................113.5.2 Incremental Functionality - DSBM........................................................................................12

4 TABLE OF INCREMENTAL FUNCTIONALITY..........................................................................13

5 REFERENCES.....................................................................................................................................14

OverviewOptimal Quality of Service (QoS) functionality is realized when hosts and network equipment cooperate to enable management of network resources. Windows 2000-based hosts (and to some degree Windows 98-based hosts) support application-based, signaled QoS. This functionality enables significant value-add when compared with management systems that rely exclusively on top-down provisioned, network-centric mechanisms. To realize these incremental benefits, complementary functionality is required in network equipment, in the form of signaling-aware policy enforcement points (PEP) and policy decision points (PDP). The purpose of this document is to encourage network equipment vendors to implement the functionality necessary to realize the additional value that results when hosts and network equipment cooperate to support QoS. To this end, the document specifies various levels of PEP and PDP functionality that may be implemented by network equipment vendors in support of signaled (QoS). All specified functionality is based on open standards and published protocols.

1.1 Document OrganizationThis document includes an overview of PEP/PDP functionality in section 1. It is followed by specific descriptions of incremental functionality in sections 2 and 3. These sections also include a number of Motivation subsections explaining how this functionality benefits the administrator of a QoS-enabled network. Section 4 contains a table that identifies specific subsets of functionality derived from the set of functionality defined in the previous sections. Vendors of PEP/PDP network elements and related equipment should use this table as a checklist of functionality that they provide (or do not provide) in support of Windows 2000 QoS. Section 5 includes pointers to the various specifications and references that are referred to throughout the document.

It is strongly recommended that the reader review one or more of the suggested Microsoft white papers on QoS mechanisms and components, as background material for this document. [MSQOSMECH] is a short white paper that provides a review of basic QoS mechanisms. [MSQOSCOMP] is a short white paper that provides a review of Microsoft's QoS components. [MSQOSWP] is an in-depth tutorial covering the issues reviewed in the two shorter white papers.

1.2 Conceptual Diagram of PEP/PDP Elements The following diagram shows the relationship of the conceptual elements discussed throughout this document. Note that specific implementations may co-locate certain subsets of these elements (such as the PEP and the PDP).

This diagram illustrates only a single PEP and a single PDP. In general, multiple PEPs and PDPs will be located at strategic points in the network topology (such as at ingress points to constrained or expensive network regions). It is likely that a single PDP will support multiple PEPs. PDPs will use a distributed form of policy store, such as a directory.

1.3 The Role of the PEP/PDP in End-to-End Signaled QoSQoS-enabled networks employ a variety of mechanisms to provide different qualities of service guarantees. Any QoS-enabled network relies on fundamental traffic handling mechanisms in the network elements through which data is carried. These elements are predominantly switches and routers. The traffic handling mechanisms include mechanisms by which traffic can be classified as belonging to one flow or another, and queuing mechanisms by which traffic on a particular flow can be allotted more or fewer resources. Network elements that support traffic handling mechanisms are also referred to as policy enforcement points (PEPs) because they are able to apply QoS policies to the traffic passing through them.

In addition, network elements must support mechanisms by which their traffic handling functionality can be provisioned or configured. Provisioning and configuration mechanisms include both top-down mechanisms and signaled mechanisms (such as the IETF's Resource Reservation Protocol (RSVP) signaling protocol [RFC2205]). Typically, PEPs are associated with some form of policy server, also known as a PDP. In top-down provisioning, a PDP uses one or more well-known configuration protocols such as Simple Network Management Protocol (SNMP), Command Line Interface (CLI), or Common Open Protocol Services (COPS) to 'push' top-down configuration information to associated PEPs.

In signaled configuration, RSVP messages arrive at PEPs. These messages describe QoS traffic flows that are traversing the PEP and request QoS resources for these flows. The PEP extracts the relevant information from the RSVP messages and passes it to the associated PDP. At a minimum, the PDP will glean classification information from these messages. To further clarify this point, RSVP messages indicate the sending (or receiving) user, and the sending (or receiving) application, as well as the classification information (IP addresses and IP ports) by which to recognize the traffic associated with the specified user and application. This effectively provides a binding that can be used by the PDP to enhance the user interface presented to the network manager and in top-down provisioning of classification information.

In addition to gleaning classification information, the PDP may also decide whether or not a particular RSVP request is admissible. As such, a PEP and its associated PDP act as an admission control agent. Certain PEPs may include PDP functionality locally. Others may offload the PDP functionality to a separate policy server. PEP/PDPs work together to apply QoS policies. In doing so, they act on policy data that is typically stored in some form of database, commonly a distributed directory.

By supporting RSVP signaling, network elements are able to offer improved manageability and to support networks with a higher quality/efficiency (QE) product1. Much of this specification addresses varying levels of support for RSVP signaled QoS.

1 The QE product of a network is its ability to simultaneously offer high quality guarantees and efficient use of network resources (see [MSQOSMECH, MSQOSWP]).

2 Traffic Handling MechanismsSupport for basic traffic handling mechanisms is the most fundamental requirement of any network equipment purporting to provide QoS. Specific implementations of traffic handling mechanisms vary from vendor to vendor.

2.1 MotivationNetwork elements implement QoS by providing traffic handling mechanisms that recognize the different traffic flows passing through them and handle them preferentially. This basic functionality is necessary to build a QoS network.

2.1.1 Incremental Functionality - Traffic Handling MechanismsWell-known traffic handling mechanisms include the following:

Differentiated service per-hop behaviors (PHB), including the Expedited Forwarding (EF) PHB, the Assured Forwarding (AF) PHB group and support for legacy IP precedence. (See [RFC2474], [RFC2475], [RFC2597], [RFC2598]). 802.1p/q prioritization (802 network elements). (See [IEEE802]) The Guaranteed and Controlled Load integrated services2 (intserv). (See [RFC2211], [RFC2212])

Generally, layer-3 devices should offer differentiated service PHBs and/or the guaranteed and controlled load integrated services. Layer-2 devices should offer 802.1p prioritization. Microsoft intentionally does not specify the underlying queuing mechanisms by which these traffic-handling mechanisms should be supported.

2.1.2 Application of Traffic Handling MechanismsIt is expected that the EF PHB will be used to construct a diffserv service offering characteristics similar to a leased line. We expect that this PHB will be used to support the Intserv Guaranteed service across diffserv networks. (See related work that is proceeding in the ISSLL working group of the IETF).

It is expected that one or more AF PHBs will be used to support the Intserv Controlled Load service across diffserv networks. (See related work that is proceeding in the ISSLL working group of the IETF).

It is expected that one of the AF PHBs (or an alternate PHB) will be available to provide less than best-effort (LBE) service. Packets marked with the corresponding DSCP would be treated at a lower priority than all other packets. This PHB would be used for the initial roll-out of certain network-hostile applications.

2 Note that IETF drafts define the Null Service [NULLSERVICE] in addition to the more traditional Guaranteed and Controlled Load services. Support for this service does not dictate any particular traffic handling mechanisms. Nonetheless, it is expected that PEPs will provide varying levels of QoS for applications regarding the Null Service by applying one or more of the various traffic handling mechanisms enumerated.

3 RSVP Signaling and Admission Control Agent FunctionalityMicrosoft is interested in network elements that support varying degrees of RSVP and admission control agent functionality. These include:

1. Subnet Bandwidth Manager (SBM) client functionality2. RSVP snooping functionality3. Resource-based quantitative admission control agent functionality4. Policy based admission control agent functionality (including support for the Active Directory as

policy data store)5. Designated Subnet Bandwidth Manager (DSBM) functionality

These features are listed in roughly ascending order of sophistication (with the exception of DSBM functionality). They are specified in detail in this section and are tabulated in section 4.

3.1 SBM ClientsThe Integrated Services over Specific Link Layers (ISSLL) working group of the IETF has specified extensions to the RSVP protocol, which are necessary to optimize operation of the signaling protocol on shared media networks. Note that throughout this text, the term 'shared media networks' is used to refer to layer-2 networks composed of switches, bridges, hubs and physically shared segments. These extensions are specified in the form of the subnet bandwidth manager (SBM). (See [SBM], [802MAP], [802FRM]). Existing SBM implementations are available from several vendors of network equipment and may be used for interoperability testing.

3.1.1 MotivationLayer-3 devices that transmit onto shared media networks and are not SBM client compliant will bypass any PEP/PDP devices in the shared network that rely on RSVP signaling. As a consequence, these will defeat signaling-based QoS management mechanisms used by the network administrator. Even though shared media networks are often considered over-provisioned, network administrators may employ RSVP-capable PEP/PDPs in these networks for the purpose of enforcing enterprise QoS policies, usage tracking, or providing high quality guarantees to high bandwidth applications. Microsoft's DSBM-based Admission Control Service (ACS) is one such system. SBM client support requires only minimal incremental development work beyond basic RSVP protocol support.

3.1.2 Incremental Functionality - SBM ClientAll layer-3 devices transmitting onto a shared media network must adhere to the SBM client functionality ([SBM]). These primarily include hosts and routers but also any device that carries traffic between two or more different IP subnetworks with one or more of these subnetworks being a shared media subnetwork. SBM client functionality must be supported on each interface that transmits onto a shared media. SBM client functionality includes the ability to detect I_AM_DSBM announcements and to redirect RSVP signaling messages accordingly.

Note: SBM client functionality does not include the ability to act as a DSBM. DSBM functionality is required on layer-2 devices (switches or other devices that carry traffic between interfaces on the same IP subnetwork) in order to provide RSVP-based admission control functionality (items 2 through 4 from the list above). DSBM functionality will be discussed separately later in this document.

3.2 RSVP Snooping FunctionalityThis is the minimal level of RSVP signaling support that is of interest to Microsoft. Network elements supporting policy-based QoS functionality should at least be capable of RSVP snooping. This functionality refers to the ability of the network element to glean robust classification information from Windows 2000 RSVP-generated messages that pass through it and to use this information to enhance management applications.

3.2.1 MotivationTraditional traffic handling mechanisms in PEPs classify traffic based on common IP header fields including IP addresses and ports. Policy management systems typically present a management interface that enables the network administrator to manage QoS based on users and/or applications. The policy management system relies on a mapping from users and applications to IP ports and addresses. This mapping is typically generated based on some combination of the following mechanisms:

Statically configured mappings that are manually created by the network administrator Libraries included with the management system that identify well-known ports and the corresponding

applications Dynamic Host Configuration Protocol (DHCP) servers that are integral parts of the management

system Sophisticated classification hardware that peers deep into packets to 'guess' the associated application

based on well-known identifiers in arbitrarily deep packet fields

These mechanisms are often cumbersome or failure-prone. In addition, some may place a high burden on network classification hardware and may not scale well under heavy loads. Network elements can use RSVP snooping functionality to reduce the management burden associated with manually generated mappings and to improve the robustness and scalability of automated mechanisms.

In IP Security (IPSec) environments, it is typically not possible for network elements to extract IP port numbers from encrypted packets. In these environments, RSVP signaling messages carry the IPSec Security Parameter Index (SPI), which can be used by the PEP in place of IP ports to associate traffic with applications.

3.2.2 RSVP Message Parsing FunctionalitySnooping functionality begins with the ability to parse RSVP messages. In particular, network elements must be able to extract RSVP policy objects, RSVP filterspec and RSVP session objects ([RFC2205]) from each RSVP message. The policy objects identify the users and applications with which signaled traffic is associated. The filterspec and session objects specify the IP addresses and ports by which this traffic can be recognized. Thus, by extracting this information from an RSVP message, a policy management system can generate a reliable mapping between users and applications on the one hand, and IP header classification information on the other hand, for internal use.

The format of RSVP policy objects in general is defined in the [IDENTITY]. The format of application identifier policy objects specifically, is defined in [APPID]. Microsoft-generated user identity policy objects contain Kerberos authenticated user IDs (in the form of an X.500 Distinguished Name). Processing of these objects requires that the policy management system participate in the authentication infrastructure as a Service principle. Specific instructions for doing so are documented in [KERB].

3.2.3 Incremental Functionality - Use of Policy Objects as Policy LocatorsThe policy management system must extract one or more of three strings from the policy objects in parsed RSVP messages. These strings are:

1. Kerberos-authenticated X.500 distinguished name (user ID)2. Application ID (generated by QoS-aware application)3. Sub application ID (generated by QoS-aware application)

These strings should be offered to the network administrator as policy locators. This means that the network administrator should be able to use the policy management system to associate specific QoS policies or resources with combinations of these strings (just as they might otherwise associate specific policies or resources with specific IP addresses and ports).

Policy management systems that use the Active Directory or otherwise participate in the Microsoft user authentication infrastructure may have out-of-band access to an enterprise list of user IDs (in the form of X.500 distinguished names, typically retrieved via the LDAP protocol from the Active Directory). In this case, the policy management system may offer the network administrator a set of user names (or user groups) for which policy may be configured at provisioning time.

Application identifiers and sub identifiers are not at this time an integral part of the Microsoft Active Directory infrastructure (although they will be so at some future date). For a current list of well-known application identifiers and sub-identifiers, see [CURRENT_APPIDS]. These may be offered to the network administrator, by the policy management system, as a set of well-known application identifiers.

Arbitrary additional application identifiers and sub identifiers can be generated by any application using the GQoS API (unlike user identifiers, which are generated by the operating system). Therefore, the policy management system should provide a flexible mechanism by which the network administrator can extend the list of well-known identifiers by adding application identifier and sub identifier strings of specific applications that are of interest to the network administrator.

3.2.4 Incremental Functionality - Use of SPI Instead of FilterspecFor environments in which traffic is encrypted using IPSec, the filterspec object contained in RSVP messages carries an SPI rather than IP ports and addresses. The format of this object is defined in [RFC2207]. RSVP messages can still be used to learn mappings of applications and users to classification information. However, in this case, the classification information takes the form of an SPI, rather than IP ports. Network management systems offering QoS management of IPSec encrypted traffic must be able to use the SPI that is signaled in RSVP messages to classify traffic.

3.3 Resource-Based Quantitative Admission Control Agents This is the minimal level of RSVP-based admission control functionality that should be offered by RSVP-aware network elements. It refers to the ability of an RSVP-aware device to maintain an accounting of the quantity of admitted resources on a per service level basis and to admit or reject RSVP requests for resources at the corresponding service level. Specifically, the device is expected to interpret the requested service type from the RSVP message and to map it to a corresponding traffic handling mechanism appropriate for the medium. The admit/reject decision is then made based on the availability of resources to provide the mapped traffic handling.

In this case, the admit/reject decision is based solely on resource availability with no regard for the user or application associated with the request. This is the reason that the functionality is referred to as resource-based admission control, as opposed to policy-based admission control. To some degree, one could argue that the specification of any resource limits, other than those imposed by the physical constraints of the device, is in itself a policy specification. However, in this document resource admission control is distinguished from policy admission control as described. Policy-based admission control is addressed specifically in section 3.4

Incremental functionality is described which allows the network administrator to police to aggregate traffic limits and to configure a RSVP-aware network element to append a DCLASS [DCLASS] or TCLASS [SBM] object to RSVP RESV messages.

3.3.1 MotivationEnterprise networks administrators are expected to use RSVP signaling to control admission to traffic handling mechanisms that support high quality service guarantees. This usage of RSVP-based admission control is described in [INTDIFF], and [MSQOSMECH, MSQOSWP]. Application of admission control in this manner is useful for protecting precious network resources. Note that the admission control functionality described in this section is implemented in the network element's control plane only. It does not dictate any particular traffic handling mechanism. Its value may be significantly enhanced by simple aggregate traffic handling mechanisms and/or policing. The level of functionality described in this section may often be simple enough to implement in standalone network elements, without requiring an external policy server.

3.3.2 Incremental Functionality - Resource Based Admission ControlAdmission control may be applied to RSVP PATH messages, RESV messages or both. PEP/PDPs must offer the network administrator (via the policy management interface) a table containing the following information for each interface:

Intserv Service Type Total Send Resources Admissible Total Receive Resources Admissible

(Token Bucket Parameters) (Token Bucket Parameters)GuaranteedControlled Load

It is not necessary to provide a table literally in this form. The most important aspect of the sample table is that it enables a network administrator to specify admission control limits separately for each service level. It also enables the network administrator to specify these limits separately for PATH messages and for RESV messages (PATH messages would be admitted based on the resource limits specified in the Send resources column. RESV messages would be admitted based on the resource limits specified in the Receive resources column.) Traditionally speaking, resource admission control is not applied to RSVP PATH messages, but rather to RESV messages. However, the ability to apply resource admission control to PATH messages may be useful to network administrators.

Note that the table specifies the total amount of resources that may be admitted on the particular interface, at each service level, not per-request limits.

Certain devices may be able to shift resources between service levels. For example, it may be possible to accommodate higher resource limits for Guaranteed service traffic if fewer resources are made available to controlled load traffic (and vice versa). In this case, a total resource limit across all service levels might be a valuable additional configurable parameter.

PEPs providing this functionality must be able to parse the appropriate RSVP messages and to extract the quantitative information from the FLOWSPEC or the SENDER_TSPEC objects that describe a traffic flow. The PEP, in cooperation with the PDP, must then use the appropriate integrated services arithmetic [RFC2210] to determine whether sufficient resources remain to be allocated to the traffic flow. If they do, the PEP/PDP should approve the resource request by allowing the message to pass unhindered (per standard RSVP processing) and should reduce the amount of remaining resources accordingly. If remaining resources are insufficient to accommodate the resource request, the PEP/PDP should reject the resource request by sending a RESV_ERR to the requesting receiver.

3.3.3 Incremental Functionality - Aggregate Traffic HandlingPEP/PDPs offering the admission control functionality specified above could be enhanced by offering aggregate traffic handling functionality in the form of differentiated service PHBs or 802.1p prioritized classes of service. In a minimal implementation, no linkage is required between the control plane admission control functionality and the aggregate traffic handling mechanism. In this case, network administrators will apply a mapping from each intserv service level to one of the aggregate traffic handling codepoints supported by the PEP. Upstream senders will be configured to mark traffic on admitted flows with the corresponding diffserv code point (DSCP) and/or 802.1p codepoints used by the PEP. For optimal flexibility in the case of differentiated service PEPs, the network administrator should be able to define the mapping of DSCP to PHB within the PEP.

3.3.4 Incremental Functionality - DCLASS or TCLASS Object SupportIncremental functionality would extend the table in section 3.3.2 to include an additional column labeled DSCP (802.1p in layer-2 DSBM devices) [DCLASS] ([TCLASS]). This column would enable the network administrator to associate a specific DSCP (or 802.1p tag) with each intserv service level. The PEP would append the DCLASS (or TCLASS) object corresponding to the admitted service type to each RSVP RESV message.

Clearly, the association of a single DCLASS and/or TCLASS with a signaled request, based solely on requested service type is a simplistic model. More sophisticated mappings could be envisioned in which, for example, quantitative parameters included with the request are used to modify the mapping and select from a range of DCLASS or TCLASS objects which might be appropriate for a specific service type. However, in the near term, we expect that significant gains in manageability can be realized by providing the simple functionality described.

3.3.5 Incremental Functionality - Aggregate Policing Offering traffic policing per aggregate service level may further enhance PEPs. Such enhanced PEPs would actually enforce the limits specified in the table in section 3.3.2. Traffic submitted in excess of the configured rates would either be discarded or demoted to a best-effort or less than best-effort aggregate class. The simplest mechanism by which such aggregate policing can be implemented is by policing based on DSCP or the 802.1p tag. All traffic marked for a certain DSCP would collectively be policed to the limits configured in the row corresponding to the DSCP from the configuration table. Such policing is particularly useful to providers offering specific resources at each of a number of service levels (such as might be offered by a diffserv network in the form of a Service Level Agreement (SLA).). It assures that the cumulative resources used by upstream marking devices do not exceed the cumulative resources offered to these devices at each service level.

In one mode, this configuration would trust upstream devices to mark DSCPs based on the results of admission control. An alternative implementation would store classification information for each admitted traffic flow and would collectively police all flows admitted for an intserv service type to the limits specified on the corresponding row.

3.4 Policy Based Admission Control AgentsPEP/PDP combinations supporting this functionality enable the network administrator to admit or reject requests for resources based not only on total admissible resources but also on per user and/or per application admissible limits.

3.4.1 MotivationPure resource-based quantitative admission control (as described in the previous section) enables the network administrator to limit the total use of prioritized network resources in PEPs on a per-interface basis. However, this is a first-come-first-serve mechanism. While it can be applied effectively to protect network resources, it does not enable the network administrator to determine which users and applications are entitled to prioritized resources in the network. Since prioritized resources are generally costly and since there are generally insufficient prioritized resources for all requesting applications or users, network administrators require the ability to apply policies in determining which traffic is entitled to admission and which is not.

3.4.2 Incremental Functionality – Policy-Based Admission ControlThe functionality for policy-based admission control builds on the functionality required for resource-based admission control. In the case of pure resource-based admission control, the network administrator uses a simple per-interface table to specify per service level, quantifiable admissible resource limits. In the case of policy-based admission control, the network administrator must be presented additional configuration options that are based on the user and application associated with admitted traffic. Due to the added complexity of policy-based admission control, this functionality is usually implemented with the help of a separate PDP and a policy data store. Where PDP and PEP functionality is separated into distinct hardware systems, these should each converse using the COPS protocol. This is necessary to promote interoperability between PEPs and PDPs provided by different vendors. The use of COPS for applying policy to RSVP requests is standardized in [COPS-RSVP]. The PEP should extract user and application identity objects from RSVP messages, as described in section 3.2.2. These should be passed to the PDP, which should use them as policy locators (also described in section 3.2.2). These should then be used to locate resource limits (and optionally DCLASS and TCLASS

values) that the network administrator has previously associated with specific combinations of policy locators. The policy management system provides a provisioning UI that is used for this purpose.

It is worth noting the distinction between two separate activities. One activity is the population of the policy system with policy locator strings and associated QoS policies. This policy system may be populated a priori (at provisioning time) with both policy locator strings and the associated policies (for example, resource limits and/or DCLASS/TCLASS). In addition, the policy system may 'accumulate' or 'learn' policy locator strings as applications signal them to the network. In this case, no policies can actually be applied until the network administrator associates policies with the learned policy locators. The second activity is the application of policies, which is said to occur at run-time. As applications signal policy locators through the network, policy systems participate in the signaling process and apply the policies previously associated with the policy locators. Specifically, the PDP should locate associated resource limits and compare the requested resources from the RSVP messages (in the form of FLOWSPEC and SENDER_TSPEC) against the provisioned limits for the corresponding service level. If sufficient admissible resources remain, the RSVP request should be admitted and the PDP should return an 'admit' decision to the PEP. If there are insufficient resources, the PDP should return a 'reject' decision to the PEP. The PDP should maintain the appropriate resource accounting and the PEP should reflect the decision to the network using the appropriate error messages as described in section 3.3.2 and [RSVPEXT]. In addition to returning the admit/reject decision, the PDP may supply a DCLASS [DCLASS] or TCLASS [SBM] value to be appended by the PEP to admitted RSVP RESV messages.

Note that, in the case of policy-based admission control, resource limits and or DCLASS/TCLASS values are associated with specific users and/or applications. These limits do not supersede those limits associated with interfaces only (for resource-based admission control). Instead, the net result of any policy decision reflects the combination of the two sets of limits. Thus, the policy system would typically check first to verify that a request passes resource-based admission control (are there sufficient resources, regardless of who/what is requesting resources?), then would check to verify that the requesting user and/or application is actually entitled to use the available resources.

This document does not specify the exact combinations of policy locators that can be associated with resource limits and DCLASS and TCLASS parameters. Rather, it specifies the format of the policy locators and the associated resource limit parameters and DCLASS and TCLASS parameters. The format of the policy objects is specified in [IDENTITY] and [APPID]. Resource limits are specified per the token bucket parameters tabulated in section 3.3.2. The specific PEP interface at which an RSVP message arrives should be offered as an additional index to support interface-based policies. In other words, the policy UI should enable the network administrator to associate different policies with the same policy locators depending on the network interface from which they are presented to the policy system.

The specification of the combinations of policy locators that are used to locate associated resources, the rules describing precedence among various policy locators, their format, and the format of the associated resource parameters, are jointly referred to as the policy schemas of the policy management system. An example of a schema which uses Windows 2000 Kerberos authenticated user IDs (and the subnet of the parsed RSVP message) to locate associated per service level resource limits can be found in [ACS]. The example schema does not use application identifiers and sub application identifiers as policy locators. It also does not allow the network administrator to associate DCLASS or TCLASS values with combinations of policy locators. A fully featured policy management system would support both the use of application identifiers and sub identifiers as well as the ability to associate DCLASS or TCLASS values.

3.4.3 Incremental Functionality - Null (Qualitative) Service SupportIn the case of the null (qualitative) service [NULLSERVICE], RSVP messages do not quantify required resources. In this case, the policy management system may still apply an admit/reject decision, but it is not based on a simple arithmetic calculation of requested resources against available resources. Rather, the admit/reject decision is typically based on a maximum number of admissible flows (corresponding to a specific user, group of users, or application) that can be specified at provisioning time by the network administrator. Policy management systems that offer support for the null service must allow the network

administrator to specify a TCLASS and/or DCLASS to be returned in response to requests for qualitative services. The effect of policy in this case is to admit or to reject a flow and to determine the appropriate marking (DSCP or 802.1p tag) for admitted flows.

Policy systems may go further by applying policies that do incorporate quantitative parameters. However, in this case, these parameters will likely be based on parameters provisioned by the network administrator and, for the foreseeable future, will not be provided by the signaling application.

3.4.4 Incremental Functionality - Use of Existing Active Directory SchemaMicrosoft's Active Directory currently supports quantitative schemas, as described in the reference above. A dynamic link library is available from Microsoft that can be used to parse the Active Directory quantitative QoS schema.

3.4.5 Incremental Functionality - Extending the Active Directory SchemaThird party management system vendors are encouraged to enhance Microsoft's limited quantitative schema by adding support for application identifiers and sub identifiers as well as the ability to associate DCLASS and TCLASS objects. Documentation and examples for developing custom Active Directory schemas and provisioning UIs can be found in [SDK]. This includes information on the Active Directory Services Interface (ADSI) and the Microsoft Management Console (MMC).

3.4.6 Regarding Use of the Active DirectoryNote that policy-based admission control, in general, does not require the use of Active™ Directory (or any other directory for that matter). Policy-based admission control refers to the ability to make an admission control decision, at a PEP or PDP, subject to policy dictated by the network administrator. The Active Directory is, however, a well-suited repository for network policy information. In addition, it is expected that network administrators deploying Windows 2000-based hosts will make broad use of the Active Directory and will use it to manage users and applications. Thus, there are synergies to be realized by enabling PEPs and PDPs to use policy information from the Active Directory. Microsoft has just begun to realize the potential of the Active Directory with respect to QoS policy information. Vendors are encouraged to expand on this usage.

3.5 DSBM FunctionalityLayer-2 devices that offer any form of RSVP based functionality must be able to intercept and parse RSVP messages. As such, they generally are required to become DSBM on the subnetwork on which they reside. As an exception, if every device in the shared subnetwork is RSVP-aware then these may cooperatively provide RSVP functionality without any of the devices officially becoming DSBM.

Layer-3 devices may also provide DSBM functionality. However, it is sufficient for these to provide only SBM client functionality in order to participate in RSVP signaling. In the absence of DSBM-capable switches, DSBM capable routers will take on the role of DSBM. Similarly, in the absence of DSBM- capable switches or routers, DSBM-capable hosts will take on this functionality. DSBM functionality is best implemented in switches.

3.5.1 MotivationDSBM-aware layer-2 devices enable network administrators to operate their layer-2 networks at an improved quality/efficiency product. In addition, DSBM functionality is necessary if layer-2 devices are to offer PEP/PDP functionality linked to RSVP signaling.

3.5.2 Incremental Functionality - DSBM DSBM functionality includes the ability to run for election as DSBM. Switches and other layer-2 devices should run at the highest priority, with routers at second priority. Devices capable of becoming DSBM must provide a mechanism by which their DSBM functionality can be disabled. Incremental functionality that may be provided by DSBMs includes the ability to append the NON_RESV_SEND_LIMIT [SBM] to

I_AM_DSBM messages. This functionality enables network administrators to limit the amount of traffic sent by QoS-aware applications on shared segments. A UI must be provided to enable the network administrator to set the limits advertised for the NON_RESV_SEND_LIMIT.

4 Table of Incremental FunctionalityThe following table tabulates the varying levels of PEP/PDP functionality detailed in the preceding paragraphs.

Feature Description Reference CommentsTraffic handling mechanism EF PHB 2.1.1

AF PHB group 2.1.1Other PHBs802.1p 2.1.1Cntl Load 2.1.1Guaranteed 2.1.1

SBM Client Functionality 3.1.2Snooping SPI parsing 3.2.4

User ID (Kerberos)

3.2.2

Application ID 3.2.2Application sub ID

3.2.2

Resource based admission control agent functionality

Per service level, token bucket limits

3.3.2

Aggregate traffic handling

3.3.3

User defined DSCP to PHB mapping

3.3.3

DCLASS or TCLASS support

3.3.4

Aggregate policing

3.3.5

Policy based admission control agent functionality

SPI parsing 3.2.4User ID (Kerberos)

3.2.2

Application ID 3.2.2Application sub ID

3.2.2

COPS/RSVP conversant PEP

3.4.2

Null Service support

3.4.3

Uses Microsoft quantitative schema

3.4.4

Extends Active Directory schema

3.4.5

DSBM functionality 3.5.2

PEP/PDP vendors should also specify whether they use: A PDP separate from the PEP. The Active Directory as the policy data store. A custom directory as the policy data store.

Specify protocol used between PEP and PDP (if not co-located). Specify protocol used between PDP and policy data store (if not co-located).

5 ReferencesMany of the references below are IETF RFCs or drafts. RFCs or 'Requests for Comments' are typically Internet standards or are documents that have been accepted by the Internet Engineering Task Force (IETF) as informational documents. These are available from the IETF web site at http://www.ietf.org. Internet drafts, on the other hand, are works in progress and are not standards. These are updated every six months until they are published as RFCs. Drafts can be obtained from the IETF web site. These can be located by searching based on keywords in the title, author names or associated working groups. Note that the version numbers of Internet drafts may be updated periodically as new versions are posted to the web site.

[RFC2205] "Resource Reservation Protocol - Version 1 Functional Specification," R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin.

[MSQOSMECH] "A Short Overview of QoS Mechanisms and Their Operation," - technical white paper http://www.microsoft.com/windows/server/Technical/networking/QoSMech.asp

[MSQOSCOMP] "The Microsoft QoS Components," - technical white paper http://www.microsoft.com/windows/server/Technical/networking/QoSComp.asp

[MSQOSWP] "An Overview of QoS," - technical white paper http://www.microsoft.com/windows/server/Technical/networking/QoSOver.asp

[RFC2474] "Definition of the Differentiated Services Field (DS Field) in the Ipv4 and Ipv6 Headers," K. Nichols, S.Blake, F. Baker, D. Black, December 1998.

[RFC2475] "An Architecture for Differentiated Services," S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, December 1998.

[RFC2597] "Assured Forwarding PHB Group," J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, June 1999.

[RFC2598] "An Expedited Forwarding PHB," V. Jacobson, K. Nichols, K. Poduri, June 1999.

[IEEE802] "Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Common Specifications - Part 3: Media Access Control (MAC) Bridges: Revision (Incorporating IEEE 802.1p: Traffic Class Expediting and Dynamic Multicast Filtering)," ISO/IEC Final CD 15802-3 IEEE P802.1D/D16, March 1998.

[RFC2211] "Specification of the Controlled Load Network Element Service," J. Wroclawski, September 1997.

[RFC2212] "Specification of Guaranteed Quality of Service," S. Shenker, C. Partridge, R. Guerin, September 1997.

[SBM] “SBM (Subnet Bandwidth Manager): A Protocol for RSVP-Based Admission Control Over IEEE 802-Style Networks," R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, Internet Draft, draft-ietf-issll-is802-sbm-08, May, 1999.

[802MAP] "Integrated Service Mappings on IEEE 802 Networks," M. Seaman, A. Smith, E. Crawley, J. Wroclawski, Internet Draft, draft-ietf-issll-is802-svc-mapping-04.txt, June 1999

[802FRM] "A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies," M. Seaman, A. Smith, V. Srinivasan, W. Pace, A. Ghanwani, June 1999

[IDENTITY] "Identity Representation for RSVP," S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, Internet Draft, draft-ietf-rap-rsvp-identity-04.txt, July 1999.

[APPID] "Application and Sub-Application Identity Policy Element for Use with RSVP," Y. Bernet, Internet Draft, draft-bernet-appid-00.txt, February 1999.

[CURRENT_APPIDS] "Application and Sub-Application Ids for Windows 2000 Quality of Service," - technical white paperhttp://www.microsoft.com/windows/server/Technical/networking/appident.asp

[KERB] "Windows 2000 RSVP/Kerberos User Authentication Interoperability Note", (available on request, from Microsoft, by sending mail to msqos@microsoft.com).

[RFC2207] "RSVP Extensions for IPSEC Data Flows," L. Berger, T. O' Malley, September 1997.

[DCLASS] "Usage and Format of the DCLASS Object with RSVP Signaling," Y. Bernet, Internet Draft, draft-ietf-issll-dclass-00.txt, June 1999.

[INTDIFF] "Interoperation of RSVP/Intserv and Diffserv Networks," L. Zhang, R. Yavatkar, F. Baker, B. Davie, P. Ford, B. Braden, M. Speer, Y. Bernet, Internet Draft, draft-ietf-issll-diffserv-rsvp-03.txt, September 1999.

[RFC2210] "The Use of RSVP with IETF Integrated Services," J. Wroclawski, September 1997.

[RSVPEXT] "RSVP Extensions for Policy Control," S. Herzog, Internet Draft, draft-ietf-rap-rsvp-ext-06.txt, April 1999.

[ACS] "Admission Control Services: Resource and Policy", (available on request, from Microsoft, by sending mail to msqos@microsoft.com).

[NULLSERVICE] "Specification of the Null Service Type," Y. Bernet, A. Smith, B. Davie, Internet Draft, draft-ietf-issll-nullservice-00.txt, September, 1999.

[SDK] "The Microsoft Platform SDK", http://msdn.microsoft.com/developer/sdk/platform.asp

[COPS-RSVP] "COPS Usage for RSVP," J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, Internet Draft, draft-ietf-rap-cops-rsvp-05.txt.