Internet Engineering Task Force Authors:
INTERNET DRAFT R. Rajan/S. Kamat/J. C. Martin
AT&T/IBM/Sun Microsystems
M. See/ R. Chaudhury
IBM/Xylan/ Telstra
D. Verma/ G. Powers/ R. Yavatkar
IBM/ Packeteer/ Intel
5/ April/1999
Policy Action Classes for Differentiated Services and Integrated
Services
draft-rajan-policy-qosschema-01.txt
Status of Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026
except for the right to produce derivative works.
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.
This draft is in accordance with the policy information
model presented in draft-ietf-policy-core-schema-02.txt,
and elaborates on the action class for specifying quality
of service (QoS) related policies. This draft replaces
draft-rajan-policy-qosschema-00.txt by modeling networking
QoS policy actions as subclass of policyAction.
Discussion of this draft will be carried on the policy
mailing list (policy@raleigh.ibm.com). Suggestions for
improvement may also be sent to rajan@research.att.com.
rajan, kamat, martin, see Expires 5/ October/1999 [Page i]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights
Reserved.
Abstract
This document describes the structure of a directory
schema to enable and support administration of QoS
policies in networks through regulation or configuration
of nodes that support Differentiated Services and/or
Integrated Services with RSVP signaling. This draft
is consistent with the core schema described in
draft-ietf-policy-core-schema-02.txt and must be used in
conjunction with draft-ietf-rajan-policy-conditions-00.txt
for definition of complete QoS policies.
1. Purpose and Overview
As protocol aspects of providing quality of service in IP networks
begin to get standardized, there is a need for corresponding
standards towards enabling policy based administration of these
protocols. Supporting QoS in a network consumes network resources
and policy based administration seeks to regulate such resource usage
to ensure that it is consistent with the network service provider's
objectives or Service Level Agreements. The contents or nature
of the high level objectives or SLAs are clearly not within IETF
scope. However, there is a need to standardize lower level schema
definitions that facilitate the administration of QoS protocols to
ensure interoperability among network devices from multiple vendors.
Currently, there are two sets of standards for providing QoS in IP
networks. Integrated services with RSVP [8] signaling approach
allows providing per-flow QoS assurances with dynamic resource
reservation. A flow is defined by the 5-tuple (source address,
destination address, protocol, source port, destination port).
In this context, there is a need to provide policy control of
individual flows, and to regulate their ability to reserve network
resources. (See [9] for a discussion of policy based admission
control framework and sample policies). Differentiated services
[4], on the other hand, are aimed at traffic aggregates that are
identified by the DS code point (part of TOS field) in IP headers of
packets. This approach primarily relies on administrative control of
bandwidth, delay or dropping preferences through simple policies and
configuration rather than per-flow signaling protocols to communicate
rajan, kamat, martin, see Expires 5/ October/1999 [Page ii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
the service level information to network elements [3]. For such
services we wish to enable flexible definition of class-based packet
handling behaviors and class-based policy control. (See [7] for
a discussion of DiffServ framework and sample behavior/service
descriptions).
In either of these environments, network administrators need the
ability to specify different classes of packets and appropriate
bounds on the usage of network resources by packets from these
classes. For example, with the signaled QoS approach of IntServ with
RSVP, a policy may specify an upper limit on the total number of
active controlled load reservations from receivers in a particular
subnet or the size of individual controlled load or guaranteed
service reservations in terms of the request parameters such as token
buket rates, delay, etc. In the DiffServ scenario, a policy may
specify that an ingress router classify packets from a specific set
of applications as requiring DiffServ Expedited Forwarding (EF) [6]
treatment, and specify the token bucket parameters for conditioning
(policing and shaping) the traffic. In order to provide the desired
level of service through consistent per hop behaviours at all nodes
for this traffic, the DiffServ policy may also specify the resource
allocation information at all network nodes to ensure that the
aggregate EF traffic has the well defined minimum departure rate
at Similarly, for the Assured Forwarding (AF) [5] class, policies
for ingress routers may specify that packets from a certain set of
sources be classified into a particular AF class, and further, assign
different drop precedence values to packets based on additional
criteria. Furthermore, for ensuring the desired level of service,
the DiffServ policy may specify traffic conditioning actions at the
ingress to ensure that the aggregate traffic belonging to the two
lowest drop precedence values in each AF class is within specified
limits and appropriate levels of bandwidth and buffer resoures are
allocated for the class at all nodes.
1.1. Objectives and Scope
[1] defines five very general classes for defining policies:
policyGroup, policyRule, policyCondition, policyTimePeriodCondition,
and policyAction. Policy solutions for specific areas, such as QoS
and security are expected to use some of these classes directly
while creating their own subclasses derived from policyCondition and
policyAction in order to represent their own application-specific
needs. A subclass of policyCondition to facilitate definition of
packet classifiers applicable for both QoS and security policies is
proposed in [2]. This draft defines subclasses of policyAction for
QoS related policies and is consistent with the above proposals.
rajan, kamat, martin, see Expires 5/ October/1999 [Page iii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
This document aims to support QoS policies for differentiated and
integrated services networks that fall within the following three
broad scenarios:
- Integrated services secured through the use of RSVP signaling,
within or across domains. The use of policy in such an
environment allows enterprises to be able to police QoS requests
on a per-flow, per-user or per-application basis. Directory
schema are meant to be used in conjunction with the use of the
policy elements in RSVP signaling messages, to enable routers to
identify users and applications to which policy must be applied.
- Differentiated services secured through provisioning within a
domain, and, in an inter-domain scenario, bilateral agreements
across peer network boundaries. In such cases, policies are used
to map across the two domain specific semantics, and enforce
access control restrictions, such as ensuring that the amount of
in-profile traffic is within the specified contractual limits.
More specifically, policies for DiffServ facilitate specification
of the following:
1. packet classification filters to be installed into
DS-compliant nodes allowing wide granularity for edge nodes
and simple DSCP based aggregate traffic filters for DS
interior nodes;
2. appropriate traffic conditioning actions to be performed at
different nodes, specifically allowing for marking, metering,
policing, shaping and dropping;
3. bandwidth and buffer resources to be allocated at
DS-compliant nodes for different traffic aggregates
identified by DS code points.
- Integrated services secured within a domain, being mapped onto
differentiated services across domains. In such cases, policies
are needed at the domain boundary to translate between integrated
and differentiated service semantics, to enforce traffic
monitoring and to provide access control to network resources.
Two important scenarios, not explicitly supported by the schema in
this draft, but which may be covered by extensions to it are:
- RSVP aggregation, i.e., the mapping of several RSVP flows into
pre-configured RSVP tunnels,
- Support of differentiated services using RSVP tunnels.
rajan, kamat, martin, see Expires 5/ October/1999 [Page iv]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
We have the following objectives in defining this schema.
1. We want to cover a broad range of PEP clients that enforce
QoS policies. These include: 1) an edge device that
marks/drops/buffers/schedules certain packets to enforce a
service differentiation policy, 2) an RSVP capable router that
accepts/denies resource reservation requests based on allowed
policies, and 3) hosts capable of packet marking and traffic
conditioning. We would like the schema definition to be generic
enough to support a wide range of resource control environments
including the clients mentioned above.
2. We want to describe QoS actions in terms of observable or
measurable behaviors rather than implementation specific
configuration parameters. We believe that adminstrators
specifying QoS policies in a heterogeneous multi-vendor network
would prefer such descriptive semantics instead of detailed
prescription of configuration parameters for specific scheduling
or buffer management mechanisms used in network nodes. We assume
that translation of QoS action directives to implementation
specific actions will be carried out in the policy clients
(within PDP/PEP/proxies).
1.2. Class Hierarchy
The new classes and subclasses added to support QoS policy actions
are depicted in the class hierarchy below:
Top
|
|
|------- policyCondition
| |
| networkingPolicyCondition
|
|------- policyAction
| |
| |--- RSVPAction
| |--- diffServAction
|
|------- diffServResourceGroup
|
|------- RSVPResourceGroup
rajan, kamat, martin, see Expires 5/ October/1999 [Page v]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
2. The Subclass diffServAction
The class policyRule specifies a sequence of actions to be employed
on a sub-stream of packets identified through a simple or complex set
of conditions. Assuming that a packet substream has been identified
(for details, see drafts [1] and [2]), the diffServAction class
describes a component per-hop behaviour (PHB) in force at a network
device. The diffServAction class does not seek to describe in
detail resource reservations, packet treatment and configuration of
every possible network device. Instead, it provides a high-level
description of QoS services through a simple model that uses the
following three descriptors -- traffic profile descriptors, packet
marking descriptors and resource group descriptors. Of these,
traffic profile descriptors and packet marking descriptors constitute
attributes of diffServAction itself, while resource group descriptors
are used through reference to another class diffServResourceGroup.
The traffic profile descriptor is used to describe precisely, the
portion of the packets of the identified sub-stream that are to be
regarded as in-profile, with the understanding that the remaining
packets are to be regarded as out-of-profile (or excess traffic). To
this end we employ a leaky bucket model with three attributes -- a
mean rate, a peak rate and a bucket size. Of course, the sorting of
packets into in-profile and out-of-profile packets is possible only
under the assumption that a policing device is present at the policy
enforcement point; otherwise the attributes may be omitted or will be
ignored (i.e., all packets will be regarded as in-profile).
The packet marking descriptor provides an edge device with the
ability to mark the DS byte for enabling simpler QoS classification
at downstream network devices. We allow for differential marking
of in and out of profile traffic (which makes sense if policing is
present); as well as for the enforcement point to mark or remark
the DS code point portion of the DS byte in the packet header. The
latter is facilitated by allowing masking certain bits of the DS byte
while modifying others.
The resource group descriptor describes the treatment expected by
packets within a common service group (identified by the forwarding
class). The descriptor does NOT aim to describe how the service
is to be provided, i.e., scheduling, buffer management, and other
resource control details cannot be dictated by policy. The resource
group descriptor instead encapsulates the (qualitative/quantitative)
nature of the service to be accorded to identified packets. There
are two aspects of such a description:
(a) The treatment of in-profile traffic: The principal service
descriptors are rate, delay and loss. These may be defined
deterministically, stochastically or qualitiatively. For instance,
rajan, kamat, martin, see Expires 5/ October/1999 [Page vi]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
a rate may be defined deterministically through the transmission of
a certain number of bits over time period, stochastically through an
on-off Markov process, or qualititatively as Class 1 traffic. We
allow for deterministic and qualitative descriptions; stochastic
descriptors may be introduced as future extension.
(b) Treatment of out-of-profile traffic: Excess traffic may be
tolerated, reshaped, provided a different class of service or
dropped.
It is important to note that trafficProfileDescriptor and
resourceGroupDescriptor objects refer to states created in the
network device. To understand this better, consider two policy
rules, as follows.
Rule1: If PolicyCondition1 then PolicyDSAction1
Rule2: If PolicyCondition2 then PolicyDSAction1
PolicyDSAction1: TrafficProfileDescriptor1
PacketMarkingDescriptor1
ResourceGroupDescriptor1
Now, all packets described either by PolicyCondition1 or by
PolicyCondition2 will be policed together, and share the same rate
resource reservations. This is different from the case where we have
Rule1: If PolicyCondition1 then PolicyDSAction1
Rule2: If PolicyCondition2 then PolicyDSAction2
PolicyDSAction1: TrafficProfileDescriptor1
PacketMarkingDescriptor1
ResourceGroupDescriptor1
PolicyDSAction2: TrafficProfileDescriptor2
PacketMarkingDescriptor2
ResourceGroupDescriptor2
Even if the two traffic profile descriptors were numerically
identical, the two streams will not be policed together by the same
policer -- they will be policed by identical policers. Similarly,
they will not share the same buffer or bandwidth resources. In fact,
the resource requirements for the second example will be twice those
of the first (ignoring multiplexing gains).
The class description of diffServAction is as follows:
NAME diffServAction
rajan, kamat, martin, see Expires 5/ October/1999 [Page vii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
TYPE Structural
DERIVED FROM policyAction
AUXILIARY CLASSES NONE
MUST
CommonName
diffServPermission
MAY
diffServInProfileRate,
diffServInProfilePeakRate,
diffServInProfileTokenBucket,
diffServInProfileTransmittedTOSByte,
diffServOutProfileTransmittedTOSByte,
diffServResourceGroupRef,
diffServActionName
The first three MAY attributes describe the traffic profile, the next
two specify the marking, and next is a reference to the resource
group.
The following set of attributes are currently defined for the
DiffServ policy clients, namely hosts, edge devices, and routers that
do traffic conditioning (packet marking, dropping, shaping, etc).
NAME diffServPermission
DESC Allow/drop data packets
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT The currently defined values for this attribute are:
Accept
Deny
With the permission attribute set to ``Accept'', and no other
attribute present, the packets matching the PolicyCondition are given
the ``default'' service.
NAME diffServActionName
DESC The user friendly name of this entry.
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
DEFAULT No name
NAME diffServInProfileRate
DESC Specifies the token rate for the in-profile traffic descriptor in kbps
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
rajan, kamat, martin, see Expires 5/ October/1999 [Page viii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
SEMANTICS All packets in the behavior aggregate are measured against
a leaky bucket with this token rate. Traffic that passes the leaky
bucket check is considered in-profile.
DEFAULT All packets considered in-profile, i.e., infinity
NAME diffServInProfilePeakRate
DESC Specifies the peak rate for the in-profile traffic descriptor in kbps
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
SEMANTICS All packets in the behaviour aggregate are measured
against a leaky bucket with this peak rate.
DEFAULT Same value as diffServInProfileRate
NAME diffServInProfileTokenBucket
DESC Specifies the token bucket size for in-profile traffic
descriptor in kilobits
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
SEMANTICS All packets in the behaviour aggregate are measured
against a leaky bucket with this token bucket size.
DEFAULT Defaults to the maximum IP packet size.
NAME diffServInProfileTransmittedTOSByte
DESC Specifies the outgoing TOS byte for in profile packet
marking descriptor
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT String(s) of the form xxxxxxxx:xxxxxxxx, where each of the `x's
is either 0 or 1.
SINGLE-VALUED
SEMANTICS Each of the two substrings is treated as specifying an 8-bit
field. The left substring is termed Mask and the right
substring Modify. 0's in the Mask specify the bit locations
in the TOS byte that must not be changed and 1's specify
those that must be changed to match the corresponding ones
in the Modify field. The operation involved is: newTOSByte
= (Mask' & oldTOSbyte) | (Mask & Modify), where Mask' is the
bitwise complement of Mask and '&' and '|' denote the
bit-wise AND and OR operations respectively.
EXAMPLE Consider a policy rule that specifies 11100000:11001010 as
the value for this attribute. The Mask of 11100000 means
that when this rule is applied, the 5 least significant bits
in the TOS byte must be left unchanged but the 3 most
significant bits must be changed to make them identical to
rajan, kamat, martin, see Expires 5/ October/1999 [Page ix]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
the corresponding ones in the Modify field. Thus, if this
rule were to be applicable to a packet whose TOS byte is
10101010, then the TOS byte will be changed to 11001010
before transmission.
DEFAULT Don't modify any bit, i.e.,
Mask 00000000
Modify 00000000
NAME diffServOutProfileTransmittedTOSByte
DESC Specifies the outgoing TOS byte for out-of-profile packet
marking descriptor
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT same as `DiffServInProfileTransmittedTOSByte' attribute
SINGLE-VALUED
SEMANTICS same as `diffServInProfileTransmittedTOSByte' attribute
DEFAULT same as `diffServInProfileTransmittedTOSByte' attribute
NAME diffServResourceGroupRef
DESC Absolute distinguished name of LDAP entry, from the objectclass
diffServResourceGroup, that identifies the service category and
resource group descriptors that apply to the traffic.
SYNTAX DN
EQUALITY distinguishedNameMatch
SINGLE-VALUED
DEFAULT Best Effort Service
2.0.1. The class diffServResourceGroup
Objects of this class fully specify the treatment accorded to
in-profile and out-of-profile traffic, in terms of their access to
QoS resources. The class description of diffServResourceGroup is as
follows:
NAME diffServResourceGroup
TYPE Structural
DERIVED FROM Top
AUXILIARY CLASSES NONE
MUST CommonName
MAY
diffServLossParameter,
diffServDelayParameter,
diffServBandwidthShare,
diffServExcessTrafficTreatment
diffServAutoStart
rajan, kamat, martin, see Expires 5/ October/1999 [Page x]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
diffServResourceGroupName
The attributes are described below.
NAME diffServResourceGroupName
DESC The user friendly name of this entry.
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
DEFAULT No name
NAME diffServLossParameter
DESC Packet loss paremeters for in-profile traffic for this
class of service
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT Colon seperate numeric strings, A:B, where at most A packets
may be dropped for every B packets received.
SINGLE-VALUED
EXAMPLE 2:1000 implies a maximum loss rate of .002.
DEFAULT Best Effort
NAME diffServDelayParameters
DESC Packet delay paremeters for out-of-profile traffic for this
class of service
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT Colon seperated integer:string pair. Currently defined
1:<absolute delay> where the absolute delay is expressed in msec
2:<relative delay > where the relative delay is expressed as
a priority (1 means best effort)
SINGLE-VALUED
DEFAULT Best Effort
NAME diffServBandwidthShare
DESC Bandwidth share for this class of service
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT Colon seperated integer:string pair. Currently defined
1:<absolute bandwidth> where the absolute bw is expressed
in kilobits/sec
2:<bandwidth percent> where the bandwidth percent is a number
between 0 and 100 expressing the share of the bandwidth
allowed to this class
SINGLE-VALUED
SEMANTICS The intervals over which bandwidths are delivered are PEP-specific.
Percentages are provided for instances where the policy rule is unaware
of the link capacity at the enforcement entity. Percentages for all
rajan, kamat, martin, see Expires 5/ October/1999 [Page xi]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
classes must add to less than 100.
EXAMPLES 1:200 -- This class is allocated a 200kbps
2:40 -- This class is allocated 40% of the link bandwidth
DEFAULT 0, i.e., No reserved share
NAME diffServExcessTrafficTreatment
DESC Describes how excess traffic is to be treated.
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT The following values are defined
`Drop' -- Allow no excess traffic
`Best Effort' -- Treat excess traffic as best effort
`Reshape'--Reshape excess traffic
SINGLE-VALUED
SEMANTICS This field specifes the actions that must be taken if an
incoming packet cannot be placed within the reserved buffer
allocation of the stream.
DEFAULT Best Effort
NAME diffServAutoStart
DESC Indicates if the resource allocation for this service should be
done at time of enforcement entity startup, or should be packet
driven. This attribute is for guidance only, and its
interpretation is implementation specific.
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT The following strings are defined
`AutoStart' --- Allocate resources at device startup
`NoAutoStart' --- Allocate resources when packets for
flow are seen.
SINGLE-VALUED
DEFAULT Autostart
2.1. The Class RSVPAction
The class RSVPAction contains policies to be applied to RSVP
signalling packets, i.e., PATH messages and RESV messages, satisfying
the conditions specified in the policy conditions. In this draft of
the schema we allow for simple forms of policy based control, where
administrative restrictions may be placed on the amount of resources
that a single RSVP flow, or group of flows, may consume. We also
allow for an RSVP reservation to be supported through a mapping into
a DiffServ service category. Support for additional rules based on
richer classes of policy information such as user ids for signalled
QoS will be supported in future extensions to this schema.
rajan, kamat, martin, see Expires 5/ October/1999 [Page xii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
Currently, there are two kinds of restrictions that we may place on
resource usage by RSVP flows -- individual restrictions and group
restrictions.
The class description of RSVPAction is as follows:
NAME RSVPAction
TYPE Structural
DERIVED FROM policyAction
AUXILIARY CLASSES NONE
MUST CommonName
RSVPFlowServiceType,
RSVPPermission
MAY RSVPActionName
RSVPMaxRatePerFlow,
RSVPMaxTokenBucketPerFlow,
RSVPMinDelay,
RSVPMaxFlowDuration,
RSVPResourceGroupRef,
diffServActionRef
The syntax and semantics of the attributes of an `RSVPAction' entry
are described below.
NAME RSVPFlowServiceType
DESC IntServ service type that a flow can request
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT: String with allowed values
ControlledLoad
GuaranteedService
MULTI-VALUED
Name RSVPPermission
DESC Allow/Dissallow RSVP flows
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT: String with allowed values
Accept
Deny
SEMANTICS Accept or deny RSVP sessions of the specified Service Type(s).
The remaining attributes make sense only in the case of `Accept'
SINGLE-VALUED
NAME RSVPActionName
DESC The user friendly name of this entry.
rajan, kamat, martin, see Expires 5/ October/1999 [Page xiii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
DEFAULT No Name
NAME RSVPMaxRatePerFlow
DESC The maximum token rate for any individual flow in kilobits per second
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
SEMANTICS Reservation requests for higher per-flow bandwidth are denied.
DEFAULT No limit
NAME RSVPMaxPeakRatePerFlow
DESC The maximum peak rate for any individual flow in kilobits per second
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
SEMANTICS Reservation requests for higher per-flow peak rate are denied.
DEFAULT Assigned the same value as RSVPMaxRatePerFlow.
NAME RSVPMaxTokenBucketPerFlow
DESC The maximum token bucket size for any individual flow in kilobits
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
SEMANTICS: Reservation requests for higher per-flow token bucket size
are denied.
DEFAULT Implementation Specific.
NAME RSVPMinDelay
DESC The minimum delay value an individual flow may request in millisec
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
DEFAULT No limit
NAME RSVPMaxFlowDuration
DESC Maximum time (in seconds) an RSVP flow matching the profile may last
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
DEFAULT No limit
NAME RSVPUserAuthPolicy
DESC Manner of authentication to be performed to authenticate user
SYNTAX IA5String
rajan, kamat, martin, see Expires 5/ October/1999 [Page xiv]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT: String, currently defined values are
Plain (Plain text password)
Kerberos (Kerberos ticket authentication)
Public-Key (Public Key authentication)
None (for no authentication)
DEFAULT None
All the policy attributes hitherto described for RSVPAction refer
to an individual flow for which a reservation is sought to be made.
Often an adminstrator might wish to place group restrictions on
flows described as an aggregation of multiple policy condition
objects. For instance, the administrator might wish to restrict the
total number of active RSVP reservations. To facilitate such group
restrictions, we allow the reference attribute RSVPResourceGroupRef.
The reason for making this a reference is not difficult to see.
The group that the adminstrator wishes to control may not be
describable through a single profile, or a single profile might
belong to different groups in terms of resource control. In such
cases, multiple policy rules ``point'' to the same group. Note that
policies described through group rules require that the enforcement
entity maintain some state; in the example suggested above, the
enforcement entity would have to track the number of active flows in
order to enforce the policy.
NAME RSVPResourceGroupRef
DESC Absolute distinguished name(s) of LDAP entry, from the objectclass
RSVPResourceGroup, which specifies constraints on a group of
RSVP flows.
SYNTAX DN
EQUALITY distinguishedNameMatch
MULTI-VALUED
DEFAULT No Resource Group
The next attribute allows the enforcement entity to map RSVP flows
onto DiffServ resource groups.
NAME DiffServActionRef
DESC Absolute distinguished name of an LDAP entry, from the objectclass
DiffServAction, which specifies the class of service that the
RSVP flow must be mapped into.
EQUALITY distinguishedNameMatch
SINGLE-VALUED
SYNTAX DN
DEFAULT No RSVP to DiffServ Translation
rajan, kamat, martin, see Expires 5/ October/1999 [Page xv]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
2.2. The Class RSVPResourceGroup
The class description of RSVPResourceGroup is as follows:
NAME RSVPResourceGroup
TYPE Structural
DERIVED FROM Top
AUXILIARY CLASSES NONE
MUST
CommonName
MAY
RSVPMaxFlows
RSVPMaxAggregateRate
RSVPMaxAggregateTokenBucket
RSVPResourceGroupName
The syntax and semantics of individual attributes are described
below.
NAME RSVPResourceGroupName
DESC The user friendly name of this entry.
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
DEFAULT No Name
NAME RSVPMaxFlows
DESC The maximum allowed number of reserved flows belonging to the
group
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
DEFAULT No limit
NAME RSVPMaxAggregateRate
DESC The aggregate maximum token rate for all flows in the group
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
SEMANTICS Reservation requests that result in a higher aggregate
bandwidth reservation are denied.
Default No limit
NAME RSVPMaxAggregateTokenBucket
DESC The maximum token bucket size for the aggregate traffic matching
the profile in kilobits
SYNTAX INTEGER
EQUALITY integerMatch
rajan, kamat, martin, see Expires 5/ October/1999 [Page xvi]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
SINGLE-VALUED
DEFAULT No limit
3. QoS Schema Usage Examples
In this section we describe some usage scenarios for defining QoS
policies for different contexts. We use LDIF notation. These
examples broadly adhere to the core Policy schema as defined in
[1], and to the policyCondition class as defined in [2]. However,
for clarity of exposition we simplify certain attribute syntaxes
(policyRuleConditionList, for instance).
3.1. DiffServ PHB
The requirements are:
- All web traffic originating from two server clusters S1
(1.1.1.0 mask 255.255.255.0) and S2 (2.2.2.0 mask 255.255.255.0)
traversing a router must be assigned a low delay, low loss
service with a shared reservation of 40Mbps.
- This traffic must be marked with the TOS bits set to 10100000.
The following rules achieve the above objective:
dn: cn=S1-Web-Rule, o=XYZ, c=US
Objectclass: policyRule
policyRuleConditionList: cn=S1-Web-Condition,o=XYZ, c=US,
policyRuleActionList: cn=DSGoldService, o=XYZ, c=US
dn: cn=S2-Web-Rule, o=XYZ, c=US
Objectclass: policyRule
PolicyRuleConditionList: cn=S2-Web-Condition,o=XYZ, c=US,
PolicyRuleActionList: cn=DSGoldService, o=XYZ, c=US
The conditions and actions referred to in the above rules are:
dn: cn=S1-Web-Condition, o=XYZ, c=US
Objectclass: networkingPolicyCondition
Objectclass: hostConditionAuxClass
Objectclass: applicationConditionAuxClass
sourceIPAddressRange: 1:1.1.0:24
SourcePortRange: 8000:8080
protocolNumber: 4 (TCP)
rajan, kamat, martin, see Expires 5/ October/1999 [Page xvii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
dn: cn=S2-Web-Condition, o=XYZ, c=US
objectclass: networkingPolicyCondition
objectclass: hostConditionAuxClass
objectclass: applicationConditionAuxClass
sourceIPAddressRange: 1:2.2.2.0:24
sourcePortRange: 8000:8080
protocolNumber: 4 (TCP)
dn: cn=DSGoldService, o=XYZ, c=US
Objectclass: DiffServAction
DiffServPermission: Permit
DiffServInProfileTransmittedTOSByte: 11111111:1010000
DiffServResourceGroupRef: cn=S1-S2-WebDSResourceGroup, o=XYZ, c=US
dn: cn=S1-S2-WebDSResourceGroup, o=XYZ, c=US
ObjectClass: DiffServResourceGroup
DiffServQueuePriority: 1 (implementation specific)
DiffServLossParameter: 1:1000000
DiffServDelayParameter: 1:1
DiffServBandwidthShare: 40000 (kbps)
DiffServAutoStart: AutoStart
3.2. DiffServ Policing
Now, consider a policy rule that allows for no more than an aggregate
of 5000 kilobits/second of best effort traffic from sources in subnet
S3 (range 139.24.2.12 to 139.24.2.255).
dn: cn=S3-Policing-Rule, o=XYZ, c=US
objectclass: policyRule
policyRuleConditionList: cn=S3-Condition,o=XYZ, c=US,
policyRuleActionList: cn=S3-DS-Action, o=XYZ, c=US
dn: cn=S3-Condition,o=XYZ, c=US,
objectclass: networkingPolicyCondition
objectclass: hostConditionAuxClass
sourceIPAddressRange: 2:139.24.2.12:139.24.2.255
dn: cn=S3-DS-Action, o=XYZ, c=US
Objectclass: PolicyAction
DiffServInProfileRate: 5000
DiffServInProfileTokenBucket: 1024
DiffServResourceGroupRef: cn=BestEffortPolicing, o=XYZ, c=US
dn: cn=BestEffortPolicing, o=XYZ, c=US
DiffServQueuePriority: 1
rajan, kamat, martin, see Expires 5/ October/1999 [Page xviii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
DiffServExcessTrafficTreatment: drop
DiffServAutoStart: NoAutoStart
Here, we have allocated a nominal token bucket to take care of the
maximum packet size.
3.3. Forbidding RSVP Sessions
Suppose that RSVP traffic from a subnet S1 is to be denied access
to the network during the working day (9 am to 5 pm). We have the
following entry to express this policy.
dn: cn=S1-RSVP-Rule, o=XYZ, c=US
objectclass: Policy
policyRuleConditionList: cn=S1-RSVP-Condition,o=XYZ, c=US,
policyRuleActionList: cn=S1-RSVP-Action, o=XYZ, c=US
policyRuleValidityPeriodList: cn=workinghrs, o=XYZ, c=US
dn: cn=S1-RSVP-Condition,o=XYZ, c=US
objectclass: networkingPolicyCondition
objectclass: hostConditionAuxClass
sourceIPAddressRange: 1:1.1.0:4
dn: cn=workinghrs, o=XYZ, c=US
Objectclass: PolicyValidityPeriod
PolicyValidityTimeOfDayRange: 090000:170000
dn: cn=S1-RSVP-Action, o=XYZ, c=US
Objectclass: RSVPAction
RSVPFlowServiceType: ControlledLoad
RSVPFlowServiceType: GuaranteedService (multi-valued)
RSVPPermission: Deny
3.4. Controlling RSVP Reservations
Consider a policy that specifies that during after hours (5 pm to
9am) each RSVP controlled load reservation for outgoing traffic from
subnet S1 have a token rate of no more than 1 Mbps, that there be
no more than 100 such reservations active at any time, and that the
aggregate reservable amount from that subnet total to no more than 10
Mbps.
dn: cn=S1-CL-nw-Rule, o=XYZ, c=US
objectclass: policyRule
policyRuleConditionList: cn=S1-CL-nw-Condition,o=XYZ, c=US,
policyRuleActionList: cn=S1-CL-nw-Action, o=XYZ, c=US
rajan, kamat, martin, see Expires 5/ October/1999 [Page xix]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
PolicyValidityPeriodList: cn=non-workinghrs, o=XYZ, c=US
dn: cn=S1-CL-Condition,o=XYZ, c=US
objectclass: networkingPolicyCondition
objectclass: hostConditionAuxClass
sourceIPAddressRange: 1:1.1.0:4
dn: cn=non-workinghrs, o=XYZ, c=US
Objectclass: PolicyValidityPeriod
PolicyValidityTimeOfDayRange: 170000: 090000
dn: cn=S1-RSVP-Action, o=XYZ, c=US
Objectclass: RSVPAction
RSVPFlowServiceType: ControlledLoad
RSVPPermission: Permit
RSVPMaxRatePerFlow: 1000
RSVPResourceGroupReference: cn=S1-RSVPGroup, o=XYZ, c=US
dn: cn=S1-RSVPGroup, o=XYZ, c=US
RSVPMaxFlows: 100
RSVPMaxAggregateRate: 10000
4. Security Considerations
There are two potential security considerations, both of which may
be addressed through standards compliant mechanisms. The first is
the unauthorized access to read or change policy rules and related
objects in the directory repository. The schema in this document
SHOULD be used in conjunction with an LDAP access control mechanisms,
see for instance [15]. The second exposure for violation of security
lies in the communication between policy decision point and the
directory repository. Such communication SHOULD be secured, with
both ends mutually authenticated using SSL/TLS or IPSec.
Acknowledgments
Thanks to Partha Bhattacharya, Tim Moore, Roch Guerin, Dimitrios
Pendarakis and Ellen Stokes for useful discussion and suggestions in
this problem space. In addition, we also thank numerous others who
have read and commented on this draft in various forms.
rajan, kamat, martin, see Expires 5/ October/1999 [Page xx]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
References
[1] J. Strassner, E. Ellesson, and B. Moore (editor),
Policy Framework Core Information Model, Internet Draft,
draft-ietf-policy-core-schema-02.txt, Feb. 1999.
[2] R. Rajan, S. Kamat, and P. Bhattacharya, Networking
Policy Condition Information Model, Internet Draft,
draft-ietf-policy-conditions-01.txt, Apr. 1999.
[3] K. Nichols, S. Blake, F. Baker and D. Black, Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers, RFC2474, Dec. 1998.
[4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W.
Weiss, An Architecture for Differentiated Services, RFC2475,
Dec. 1998.
[5] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, Assured
Forwarding PHB Group Internet Draft, draft-ietf-diffserv-af-06.txt,
Feb. 1999.
[6] V. Jacobson, K. Nichols, and K. Poduri, An Expedited Forwarding
PHB, Internet Draft, draft-ietf-diffserv-phb-ef-02.txt, Feb.
1999.
[7] Y. Bernet, et al, A Framework for Differentiated Services,
Internet Draft, draft-ietf-diffserv-framework-02.txt, Feb. 1999.
[8] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,
Resource ReSerVation Protocol (RSVP) Version 1 Functional
Specification. RFC2205, Sept. 1997.
[9] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework
for Policy-based Admission Control Internet Draft,
draft-ietf-rap-framework-01.txt, Nov. 1998.
[10] S. Herzog, A. Sastry, R. Rajan, R. Cohen, J. Boyle, and
D. Durham, The COPS (Common Open Policy Service) Protocol
Internet-Draft, draft-ietf-rap-cops-06.txt, Feb. 1999.
[11] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access
Protocol, RFC1777, Mar. 1995.
[12] M. Wahl, A. Coulbeck, T. Howes and S. Kille, Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions
Internet Draft draft-ietf-asid-ldapv3-attributes-07.txt, August
1997.
rajan, kamat, martin, see Expires 5/ October/1999 [Page xxi]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
[13] S. Judd and J. Strassner, Directory Enabled Networks -
Information Model and Base Schema - Draft v3.0c5 DEN
Specifications, Sep. 1998.
[14] Desktop Management Task Force, Common Information Model (CIM)
Specification, Version 2.0, Mar. 1998.
[15] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control
Requirements for LDAP, Internet Draft, Sep. 1998.
[16] R. Droms, Dynamic Host Configuration Protocol, RFC1541, Oct.
1993.
AUTHORS' ADDRESS
Raju Rajan
AT&T Labs - Research
180 Park Avenue, P.O. Box 971
Florham Park, NJ 07932-0971
email: rajan@research.att.com
Sanjay Kamat
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532
email: sanjay@watson.ibm.com
Jean-Christophe Martin
Solaris and Network Software Group
Sun Microsystems
France
email:jean-christophe.martin@sun.com
Michael See
email: Michael.See@xylan.com
Rajiv Chaudhury
email: rchaudhu@telstra.com.au
rajan, kamat, martin, see Expires 5/ October/1999 [Page xxii]
Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999
Dinesh Verma
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532
email: dverma@watson.ibm.com
George Powers
email: george@packeteer.com
Raj Yavatkar
Intel Corporation, JF3-206
2111 NE 25th Avenue,
Hillsboro, OR 97124
email: raj.yavatkar@intel.com
Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
rajan, kamat, martin, see Expires 5/ October/1999 [Page xxiii]