Internet Engineering Task Force Authors
INTERNET DRAFT R. Rajan/J. C. Martin
IBM/Sun Microsystems
S. Kamat/M. See/ R. Chaudhury
IBM/Xylan/ Telstra
D. Verma/ G. Powers/ R. Yavatkar
IBM/ Packeteer/ Intel
23/ October/1998
Schema for Differentiated Services and Integrated Services in Networks
draft-rajan-policy-qosschema-00.txt
Status of Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please
check the
``1id-abstracts.txt'' listing contained in the
Internet-Drafts Shadow Directories on ftp.ietf.org (US
East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West
Coast), or munnari.oz.au (Pacific Rim).
Abstract
This document describes the structure of a directory schema
to enable and support administration of differentiated
services and/or integrated services within and among
Internet domains, intranets, and extranets. This draft
replaces draft-ellesson-sla-schema-00.txt.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page i]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
1. Overview
Integrated services with RSVP [2] signaling approach seeks to
provide 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
regulate their ability to reserve network resources. (See [8]
for a discussion of policy based admission control framework and
sample policies). Differentiated services[6], on the other hand,
are aimed at traffic aggregates that may not correspond to fine
grained flows. This approach may rely more on administrative control
of bandwidth, delay or dropping preferences, rather than per-flow
signaling protocols to communicate the service level information
to network elements. For such services we wish to enable flexible
definition of class-based packet handling behaviors and class-based
policy control. (See [6] for a discussion of DiffServ framework and
sample behavior/service descriptions).
In either of these environments, network administrators need the
ability to define and administer different types of services for
customers. Administrative policies tend to change infrequently, and
can be conveniently stored in a directory based repository which may
be distributed across multiple physical servers, but is administered
as a single entity by the network administrator. Furthermore,
this information must be propagated to network elements such as
hosts, proxies and routers, that actually implement the policies and
preferences by classifying traffic to identify its level of service,
and apportioning resources according to defined resource regulation
policies.
This document describes a common language for describing
administrative policies for integrated services and differentiated
services in terms of an LDAP schema. Currently, LDAP [4] is a widely
deployed industry standard for accessing directory information, and
hence LDAP based administration of these customer service level
preferences and the associated resource regulation policies seems a
natural approach. We envision that policies embodied as LDAP schema
will be stored on directories and downloaded to devices such as
hosts, routers, policy servers, proxies, etc., that implement the
policies. The use of LDAP assures a standard, widely deployed and
simple protocol for directory access.
The details of the architecture within which this schema will be
deployed, is presented in a seperate draft (citation TBDs). This
architecture for network resource control involves a management tool,
a policy repository, a policy decision point and a policy enforcement
entity. The network administrator uses the management tool to
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page ii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
populate the policy repository with a number of policy rules that
regulate access/use of network resources. These rules could specify
for instance, the service category to be employed for a particular
application, how much bandwidth is allocated to a particular flow or
TOS category, the maximum number of flows to be supported between
two subnets, etc. In any case, the administrator-specified rules
are stored in the policy repository in a well understood format
or schema. The decision entity downloads the policy rules. The
enforcement entity is the host or router which encounters (data
or signaling) packet flowing across the network. It queries the
decision entity for specific actions that are to be applied in
conditioning the packet stream. The next section describes the scope
of the schema, following which we discuss policy rule matching and
present the detailed schema. The draft concludes with a section on
examples. For an explanation of terminology employed to describe
network policy and services in this document, please refer to [13].
1.1. Objectives and Scope
This document aims to support QoS policies for differentiated and
integrated services networks that fall within the following three
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.
- 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:
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page iii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
- RSVP aggregation, i.e., the mapping of several RSVP flows into
pre-configured RSVP tunnels,
- Support of differentiated services using RSVP tunnels.
We have the following objectives in defining this schema.
1. The directory provides a convenient repository of the resource
regulation policies, which may be used by a wide variety
of clients that actually enforce the resource regulation
rules. As illustrated before, there are at least three such
potential clients for the near term: 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. When viewed in the context of resource control policies, the
associated schema can be considered to provide a ``language''
for defining these policies. From this perspective, we desire
that the schema should facilitate definition of a wide range
of policies varying in their complexity. Simple policies (the
common case) should be easy to specify, and there should be
sufficient hooks to define sophisticated policies within the
schema. Using the language analogy, an administrator's ability
to define sophisticated resource regulation policies should not
be limited by the structure of the schema, although it may be
limited by the available implementation of the policy enforcement
environment.
3. The schema should facilitate simple addition and deletion
of new rules, automated checks for rule ambiguities, and
allow for diverse methods (varying in efficiency and ease of
implementation) to be employed in the policy decision entity to
search through rules.
2. Class Hierarchy
In this section, we describe the inheritance hierarchy and the
relationship between various classes. We define a structural
LDAP object class called Policy as the container for policy
rules. An object of this class will ``piece together'' several
policy components relating to differentiated services, RSVP and
IPSec based VPNs [10]. In this section we largely focus on the
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page iv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
PolicyRules object class itself and not on where it is placed in the
organization's existing directory tree. However, the Policy class
described here is best understaod within the Common Information
Model [11] of the Directory Management Task Force or the directory
structure proposed by the Directory Enabled Networks specification
[9].
The class hierarchy in the schema is given below.
Top
|----Policy
|
|----PolicyCondition
| |
| |--IPPolicyCondition
|
|-----UserIDCondition
|
|----PolicyValidityPeriod
|
|----PolicyAction
| |----RSVPAction
| |----DiffServAction
| |----TCPAction
| |----ISAKMPAction
| |----IPSecSecurityAction
|
|----DiffServResourceGroup
|----RSVPResourceGroup
|----IPSecProposal
|----ISAKMPProposal
|----IPSecTransform
|----IPSecPrivateDiffieHellmanGroup
|
|----PolicyContainmentAuxClass
The schema described above closely follows the policy class hierarchy
described in the document ``Information Model and Base Schema''
version 3.0r5 released by the Directory Enabled Network AdHoc
Group. The schema described in this document expands on the DEN
specification but differs in a few significant details.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page v]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
3. Policy Rules
The Policy object class is instantiated by LDAP entries, where each
entry encodes a policy rule that specifies the resources and services
that are allowed (or denied) to a stream of packets. An entry is
composed of several attributes. Each attribute is of a certain type,
and has one or more values. The two principal components of a policy
rule are objects of the type PolicyCondition and and PolicyAction.
These two objects describe a rule through the relation
if <PolicyCondition> then <PolicyAction>.
A PolicyCondition object is defined by the values of a collection
of certain attributes that are typically used to determine when a
policy rule applies. A typical condition is, for instance, a range
of source addresses (or a source address and mask) to which the
policy applies. An action is defined by a collection of attributes
that detail permissions or additional behaviours that the policy
enforcement entity should perform for the given condition. For
instance, the value of attribute PolicyConditionRef could be the
distinguished name of an object that places restrictions on the
source address range of IP packets, while PolicyActionRef could
be the distinguished name of a DiffServAction object that fully
describes the treatment of a flow with respect to TOS marking and QoS
requirements.
Conditions and actions may each be of different types. For instance,
a PolicyCondition object may place restrictions on, or otherwise
refer to information contained in IP header fields such as source
addresses, or to information contained inside signalling packets
as with RSVP PATH or RESV messages, or may refer to information
regarding the layer 2 protocol such as restrictions on MAC addresses.
In this draft we take a simple, first cut approach to such issues,
covering the most common policy cases, but allowing for future
extensions to this draft or to policy standards. We allow the
class PolicyCondition to be expanded through an auxillary class
IPPolicyAuxCondition which allows for conditions based on IP
header fields, or through the class UserIDPolicyAuxCondition which
allows for conditions based on user IDs. Similarly, the class
PolicyAction is subclassed into a number of protocol or service
specific actions -- DiffServAction, RSVPAction, IPSecSecurityAction
and IPSecISAKMPAction. Both the PolicyCondition class and the
PolicyAction class may be easily extended in future.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page vi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
4. Ascertaining Applicability of Policy Rules
Typically, the policy decision entity needs to ascertain which
actions to apply to a particular (data or signalling) packet based on
the rules that it has downloaded from the repository. In doing so,
it must combine logical information that has been organized through
the schema structure where policy rules are made up of condition
and action attributes, and these attributes may assume one or more
values. We now explain the process of ascertaining whether a packet
meets a condition.
Consider a PolicyCondition object composed of several attributes
attribute1, attribute2, ..., each potentially assuming one or
more values (value1-1, value1-2,...), (value2-1,value2-2,...),...,
respectively. The packet header has several fields (field1,
field2,...). We say that the packet meets the condition if field1
belongs to any of the sets value1-1, value1-2 AND if field2 belongs
to any of the sets value 2-1, value2-2, AND so on. Thus, the check
of if packet matches condition can be written as
if (((field1 belongs to value1-1) OR (field1 belongs to value1-2) OR ...)
AND
((field2 belongs to value2-1) OR (field2 belongs to value2-2) OR ...)
AND
...
)
Most attributes are NOT multi-valued, and exceptions such as
Interface (denoting the incoming and outgoing interfaces on which the
rule is applicable) or TimeOfDay (denoting the time of day when the
rule is applicable) have been introduced only where unavoidable. As
an example, consider a packet with source address 8.2.3.1, source
port 50, destination address 7.2.3.1, destination port 51, protocol
22 arriving at a router on the interface 3, departing on interface 5
being matched against the following condition.
Attribute Values
SourceAddressRange 8.0.0.0 : 8.255.255.255
SourcePortRange 50 : 51
DestinationAddressRange 7.2.0.0 : 7.2.255.255
DestinationPortRange 50 : 51
Protocol 0 : 100000 (May be omitted)
Interface 1 : 5 (format - incoming:outgoing)
2 : 5
3 : 5
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page vii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
It is easy to check that the packet meets the condition, but another
packet destined to the address 9.2.19.250 would not.
Now, the policy decision point successively evaluates multiple rules
and in order to choose the one that matches. Thus, it checks
RULE 1: if (packet meets condition1) then perform (action1-1, action1-2, ...)
RULE 2: if (packet meets condition2) then perform (action2-1, action2-1, ...)
etc.
Here the logical operator that is used to combine the rules is an
AND, i.e.,
RULE 1 AND RULE 2
If the rules are mutually exclusive, i.e., no packet can ever
meet both conditions, then the actions corresponding to the one
that applies are performed. What does the decision entity do if
both conditions are applicable? In some cases, action 1 could be
compatible with action 2, i.e., it may be possible to perform both
actions. As an example, if action1 is a directive to encapsulate the
packet, and action2 indicates the QoS stream the packet belongs to,
then the packet is encapsulated and then given the right QoS. On the
other hand, if the actions are incompatible, then the operation of
the decision entity could be undefined.
Rule consistency is desirable whenever possible. However, for
purposes of administrative convenience, it is often useful to
introduce temporary rules that override others, without having to
remove the overriden rule -- for example, special rules for New
Year's day. We allow for this by optionally attaching priorities
to rules. Potential ambiguities are thus resolved by assigning a
higher priority to the overriding rule. In the earlier example, for
instance, if rule 2 has higher priority, then the decision point
performs all the actions specified in rule 2, and all the compatible
actions specified in rule 1. Hence, the right interpretation of the
rule set is:
if (packet meets condition2) then perform (action2-1, ...)
AND
if (packet meets condition1) then
if (action1-1) is compatible then perform it
if (action1-2) is compatible then perform it
...
It is very simple to check for compatibility. Actions correspond a
few basic scopes -- RSVP, DiffServ, IPSec, and so on. We need to
collect no more than one action of a particular scope.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page viii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
5. The class Policy
The Policy object class is the container class for the policy rules.
It contains a number of entries, each entry encodes a policy rule
that specifies the resources and services that are allowed (or
denied) to a stream of packets. An overview of the class Policy is
presented below, followed by the detailed sytax and semantics of
various attributes.
NAME Policy
TYPE Structural
DERIVED FROM Top
MUST
CommonName,
PolicyScope,
PolicyConditionRef,
PolicyActionRef,
PolicyVersion
MAY
PolicyRulePriority,
PolicyKeyword,
PolicyType,
PolicyName,
PolicyEnabled
The syntax and semantics of the attributes of the class Policy are as
follows:
NAME CommonName
DESC The common name for objects of this class. Used as relative
distinguished name to identify object within a branch of
directory tree.
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
NAME PolicyScope
DESC Lists the services that are controlled through this policy
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT The currently defined values for this attribute are:
DiffServ
RSVP
IPSec
ISAKMP
SEMANTICS This attribute is used by the appropriate directory clients
to fetch only those policy rules that are relevant for their
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page ix]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
functionality. The value DiffServ' means the policy rule
specifies DiffServ packet classification and traffic treatment.
The value `RSVP' means specifes an RSVP policy
decision point. The value `IPSec' means the policy refers
to an IPSec action rule. The value `ISAKMP' means the policy
refers to an ISAKMP action rule. Note that this is a multi-
valued attribute, and the same rule may regulate multiple
services for a packet stream.
NAME PolicyConditionRef
DESC Absolute Distinguished name of LDAP entry of the objectclass
PolicyCondition, that identify the packets that the policy rule
applies to.
SYNTAX DN
EQUALITY distinguishedNameMatch
SINGLE-VALUED
The following reference attributes specify the treatment of packets
that match the condition specified in the policy rule. The value
of a reference attribute is the distinguished name of an LDAP entry
which is an object corresponding to a prespecified class. For
instance, if the value of the attribute PolicyActionRef is the
distinguished name of an entry in the class RSVPAction, then the
policy rule specifies the policy relating to the handling of RSVP
signalling messages.
NAME PolicyActionRef
DESC Absolute Distinguished name(s) of LDAP entry, of the objectclass
PolicyAction, that specifies permissions and restrictions
that apply to the packets identified by the policy condition
SYNTAX DN
EQUALITY distinguishedNameMatch
MULTI-VALUED
SEMANTICS Multiple values are understood as logical AND; that is, all
the actions must be performed
NAME PolicyVersion
DESC The version of the policy schema embodied by this policy.
SYNTAX IA5String
EQUALITY caseExactIA5Match
FORMAT The current draft specifies version ``1.0''
SINGLE-VALUED
NAME PolicyKeyword
DESC List of keywords that assist in locating this policy
SYNTAX IA5String
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page x]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
EQUALITY caseExactIA5Match
MULTI-VALUED
DEFAULT No Keywords
NAME PolicyType
DESC Describes the types of a policy
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT The following values are allowed:
ISAKMPPhase1
ISAKMPPhase2
IPSecDataLocal
IPSecDataRemote
RSVPSignalling
RSVP-DiffServ
DiffServ
SEMANTICS ISAKMPPhase1 denotes an ISAKMP Phase 1 policy
ISAKMPPhase2 denotes an ISAKMP Phase 2 or Quick Mode policy
IPSecDataLocal denotes a policy for securing locally
originating data by IPSec. Local means either originating
from the same host or from an host for which this host
acts as a proxy
IPSecDataRemote denotes a policy for securing remotely
originating data by IPSec. Remote is the opposite of Local
as defined before.
RSVPSignalling denotes an RSVP signalling policy
RSVP-DiffServ denotes a policy for mapping an RSVP traffic
into a DiffServ pipe
DiffServ denotes a DiffServ policy
DEFAULT Unnamed Type
NAME PolicyName
DESC A user friendly name of this policy class
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
DEFAULT No Name
The following attribute defines relationships among multiple related
rules within the policy repository.
NAME PolicyRulePriority
DESC Priority level for this rule. Used to resolve ambiguity in
condition matching when the ranges specified in the Policy
conditions overlap. Higher values of this attribute imply
higher priority of the rule.
SYNTAX INTEGER
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
EQUALITY integerMatch
SINGLE-VALUED
DEFAULT The default value is 0 (lowest priority)
SEMANTICS Whenever a packet matches two rules of different priority,
the rule with the higher value of PolicyRulePriority is
applied.
NAME PolicyEnabled
DESC A flag describing whether the policy is currently enabled or
disabled
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT The currently defined values for this attribute are:
Enabled
Disabled
DEFAULT Enabled
5.1. PolicyContainmentAuxClass
Policy rules may need to be grouped together for a number
of different purposes -- organizational, security, ease of
administration, or ease of retrieval by a policy decision point. We
reproduce the PolicyContainmentAuxClass from the DEN specification
[9] that serves the useful purpose of grouping policies together.
This auxillary class definition is as follows:
NAME PolicyContainmentAuxClass
TYPE Auxillary
DERIVED FROM Top
AUXILIARY CLASS None
POSSIBLE SUPERIORS Organization, OrganizationalUnit, Group,
GroupOfDevices
MUST PoliciesContainedRef
MAY
The syntax and semantics of its sole attribute are as follows:
NAME PoliciesContainedRef
DESC Absolute distinguished names of policies grouped together
for some (context-dependent) purpose.
SYNTAX DN
EQUALITY distinguishedNameMatch
MULTI-VALUED
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
6. Policy Conditions
In this section we define the abstract class PolicyCondition, its
subclass IPPolicyCondition, and the class UserIDCondition. These
classes list the conditions that must be statisfied by a stream of
packets in order for the referring rule to apply to that packet
stream.
The reason for subclassing PolicyCondition is to allow extensibility
to other networking protocols through sub-classes such as
ATMPolicyCondition (for instance).
NAME PolicyCondition
TYPE Abstract
DERIVED FROM Top
AUXILIARY CLASS None
MUST CommonName
MAY PolicyConditionName
PolicyValidityPeriodRef
The detailed syntax and semantics of the attributes is as below:
NAME CommonName
DESC The common name of the policy condition object. Unique within a
limited scope and used to identify the object within the
directory tree.
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
NAME PolicyConditionName
DESC The user friendly name of this entry.The Name related attributes
are only for ease of user administration.
EQUALITY caseExactIA5Match
SYNTAX IA5String
SINGLE-VALUED
The next attribute is a reference to PolicyValdityPeriod object that
identifies the entry that limits the temporal scope of the policy to
specified periods of time.
NAME PolicyValidityPeriodRef
DESC Absolute distinguished name(s) of an PolicyValidityPeriod
object that specifies the times that the policy is active.
SYNTAX DN
EQUALITY distinguishedNameMatch
MULTI-VALUED
DEFAULT Policy applies at all times
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xiii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
6.1. The class IPPolicyCondition
The class PolicyCondition is now specialized to deal with IPv4 packet
headers in the class IPPolicyCondition.
NAME IPPolicyCondition
TYPE Structural
DERIVED FROM PolicyCondition
AUXILIARY CLASSES none
MAY Interface,
SourceIPAddressRange,
DestinationIPAddressRange,
SourcePortRange,
DestinationPortRange,
IPProtocolNumberRange,
ReceivedTOSByteCheck
HostUserIDRef
The first attribute limits the spatial scope of the policy rule by
identifying specific router interfaces where the policy is to be
applied.
NAME Interface
DESC An attribute that limits the scope of the policy to packets on
specified interface(s) and the direction(s) of traffic on these.
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT Three colon seperated strings. The left-most string is a numeral
denoting the type of the specification, followed by the incoming
and outgoing interface identifiers. Currently defined type/value
formats are
1:<IPv4Address>:<IPv4Address>
2:<InterfaceID>:<InterfaceID>
The IP addresses are in dotted decimal notation. The interface
IDs are integers unique to the host device.
The first address string specifies a restriction of the rule
to traffic inbound on the interface, and the rightmost string
specifies a corresponding restriction of the rule to traffic
outbound from that interface. An unspecified interface(s)
defaults to all interfaces on the device that this rule
applies to.
DEFAULTS Defaults to traffic inbound on all interfaces, outbound on
all interfaces.
EXAMPLE 1:9.3.1.52:9.2.1.54 (Applies to traffic inbound on 9.3.1.52
and outbound on 9.3.1.54)
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xiv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
1:9.3.1.32: (Applies to traffic inbound on 9.3.1.52
outgoing from any interface)
2::3 (Applies to traffic outbound on interface 3
arriving on any interface)
NAME SourceIPAddressRange
DESC Source IP addresses to which the policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT SourceIPAddressRange is of the following form: three colon (':')
separated strings denoting a range of IP addresses. The formats
currently defined are:
1:<IPv4Address>:<CIDRPrefixLength>
The IP v4 address is in dotted decimal format. The
CIDRPrefixLength is the number of unmasked leading bits.
A packet matches the condition if the unmasked
bits on the packet are identical to the unmasked bits on the
condition.
2:<IPv4Address>:<IPv4Address>
IP addresses in dotted decimal format. The second
address must be no smaller than the first. The first
denotes the start of the range, and the second denotes
the end of the range. A packet matches the condition
if its source address is no smaller than the first
IP address in the condition, and no larger than the
second.
3
Indicates policy applies to locally generated packets.
DEFAULT Defaults to the entire address range, i.e., every packet
matches the source address range condition.
EXAMPLE 1:83.23.23.1:24
A packet with source address 83.23.23.5 matches.
A packet with source address 83.23.24.1 does not.
2:83.23.23.0:83.28.28.0
A packet with source address 83.23.23.5 matches.
A packet with source address 83.29.24.1 does not.
NAME DestinationIPAddressRange
DESC Destination IP addresses to which policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT Identical to that of SourceIPAddressRange above.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
The value of ``3''indicates a locally destined packet.
DEFAULT Defaults to the entire address range, i.e., every packet
matches the destination address range condition.
NAME SourcePortRange
DESC Source Ports to which policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT String consisting of two colon separated positive
integers, the second no smaller than the first, or one
positive integer.
DEFAULT Defaults to the entire port range 0 to 65535, i.e., every
packet matches the destination address range condition.
EXAMPLE 8000:8080 (ports 8000 to 8080),
8000 (only port 8000)
NAME DestinationPortRange
DESC Destination Ports to which policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT String consisting of two colon separated positive
integers, the second no smaller than the first, or one
positive integer.
DEFAULT Defaults to the entire port range 0 to 65535, i.e., every
packet matches the source address range condition.
NAME IPProtocolNumberRange
DESC Protocol numbers to which policy applies
SYNTAX INTEGER
EQUALITY integerMatch
SINGLE-VALUED
FORMAT String consisting of two colon separated positive
integers, the second no smaller than the first, or one
positive integer.
DEFAULT Defaults to the entire protocol range 0 to 255, i.e., every
packet matches the ip protocol range condition.
EXAMPLE 50:51 (protocol 50 to 51),
50 (only protocol 50)
NAME ReceivedTOSByteCheck
DESC A condition attribute used to select traffic based on the
contents of the TOS byte of the received packet's IP header
SYNTAX IA5String
EQUALITY caseExactIA5Match
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xvi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
SINGLE-VALUED
FORMAT String of the form xxxxxxxx:xxxxxxxx, where each of the
x's is either 0 or 1.
SEMANTICS Each of the substrings is treated as specifying an 8-bit
field. The left substring is termed Mask and the right
substring Match. The TOS byte of the received packet's IP
header is ANDed with Mask and the result is compared against
Match. The combination of Mask and Match allows definition of
TOS byte based conditions where certain bits in the TOS byte
may be ignored for the purpose of comparison.
EXAMPLE An incoming packet with TOS byte 11001010 matches the
condition specified by a value of 00111100:00001000 for
ReceivedTOSByte.
NAME UserIDConditionRef
DESC Absolute Distinguished name(s) of LDAP entry or entries, of
an UserIDCondition object that identify the user or
host whose packets that the policy rule applies to.
SYNTAX DN
EQUALITY distinguishedNameMatch
MULTI-VALUED
6.2. The Class UserIDCondition
In many scenarios, for instance an end host IPSec, policy needs to
be specified for a user or a host ID instead of an IP address. A
standard example is a corporate worker connecting from home via an
ISP. The policy would be specified by Host FQDN, UserFQDN, X500 DN
etc. To accomodate this source and destination ids are required.
NAME HostUserID
TYPE Structural
DERIVED FROM Top
AUXILIARY CLASS None
MUST CommonName
MAY SourceID,
DestinationID,
NAME SourceID
DESC Source Host Identifier
SYNTAX IA5String
EQUALITY caseExact1A5Match
MULTI-VALUED
FORMAT Two strings , colon (`:') seperated, the first describing the
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xvii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
ID type and the second the ID value. The valid IdTypes and
their corresponding values are defined in [Piper98]. These
include:
Host-FQDN:<ID>
User-FQDN:<ID>
X500-DN:<ID>
X500-GN:<ID>
Key-Id:<ID>
DEFAULT Any ID is considered valid.
NAME DestinationID
DESC Destination Host Identifier
SYNTAX IA5String
EQUALITY caseExact1A5Match
MULTI-VALUED
DEFAULT Any ID is considered valid.
FORMAT Same as Source ID.
7. The class PolicyValidityPeriod
Objects of this class describe conditions that restrict the validity
period of the policy rule. The class definition is as follows:
NAME PolicyValidityPeriod
TYPE Structural
DERIVED FROM Top
AUXILIARY CLASSES NONE
MUST CommonName
MAY PolicyValidityPeriodName,
PolicyValidityTime,
PolicyValidityMonthMask,
PolicyValidityDayOfWeekMask,
PolicyValidityTimeOfDayRange
The syntax and semantics of various attributes are as given below
NAME PolicyValidityPeriodName
DESC The user friendly name of this entry.
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
NAME PolicyValidityTime
DESC When this policy is valid
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xviii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
FORMAT String(s) of the form yyyymmddhhmmss:yyyymmddhhmmss:<TZ>
SEMANTICS The first two substrings must be valid times,
(year-month-date-hour-minute- second) the second larger
than the first. The last substring is optional and
describes the time zone.
DEFAULT If the time zone is omitted then the time is local time at
the policy decision point. If the attribute itself is absent
then the policy is always valid.
EXAMPLE 19980121060000:19991231133000:GMT
(meaning Policy in effect from 6:00 AM on January 21, 1998
to 1:30 PM on December 31, 1999, Greenwich Mean Time).
NAME PolicyValidityMonthMask
DESC Months during which policy is valid
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT String denoting a mask of 12 0s and 1s.
SEMANTICS 1's corresponding to months in the January to December
range when the policy is valid.
EXAMPLE 000111111100 (Valid from April until October)
DEFAULT 111111111111, i.e., valid always
NAME PolicyValidityDayOfWeekMask
DESC days during which policy is valid
SYNTAX IA5String
EQUALITY caseExactIA5Match
SINGLE-VALUED
FORMAT String representing a mask of 7 0s and 1s.
SEMANTICS 1's correspond to days in the Monday to Sunday range
when the policy is valid.
EXAMPLE 1111100 (Valid weekdays)
DEFAULT 1111111, i.e., valid always
NAME PolicyValidityTimeOfDayRange
DESC Time(s) of day during which policy is valid
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT String(s) of the form hhmmss:hhmmss
SEMANTICS Substrings on either side of the colon must be be valid
time of day values. If the second string is not larger
than the first, then a wrap around midnight is assumed.
DEFAULT 000000:235959
EXAMPLE 090000:170000 (Policy valid from 9 AM to 5 PM)
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xix]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
7.1. The class DiffServAction
Each object of type DiffServAction 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 descriptors, packet marking descriptors and resource group
descriptors.
The traffic descriptor assumes a leaky bucket model with three
attributes -- a mean rate, a peak rate and a bucket size -- to
specify the characteristics of what is to be considered in-profile
traffic, with the understanding that the rest is out-of-profile
or excess traffic. The traffic descriptor makes sense only with
the assumption that a policing device is present at the policy
enforcement point; if not the attributes may be omitted or will be
ignored.
The packet marking descriptor provides an edge device with the
ability to mark the DS byte for simple 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 mask certain bits
while modifying others.
The resource group descriptor describes the treatment expected by
packets within a common service group. It is not a description of
how the service is to be provided, but simply a high-level view of
the service to be accorded to the in-profile traffic, its delay and
loss requirements, for instance, as well as the treatment of excess
traffic, whether this is to be tolerated, reshaped or dropped.
It is important to note that TrafficDescriptor 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: TrafficDescriptor1
PacketMarkingDescriptor1
ResourceGroupDescriptor1
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xx]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
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: TrafficDescriptor1
PacketMarkingDescriptor1
ResourceGroupDescriptor1
PolicyDSAction2: TrafficDescriptor2
PacketMarkingDescriptor2
ResourceGroupDescriptor2
Even if the two traffic descriptors are 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
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, 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 Directory Clients, namely hosts, edge devices, and
routers that do traffic conditioning (packet marking, dropping,
shaping, etc).
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
NAME DiffServPermission
DESC Allow/drop data packets matching the profile
EQUALITY caseExactIA5Match
SYNTAX IA5String
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 ``Best Effort'' service.
NAME DiffServActionName
DESC The user friendly name of this entry.
EQUALITY caseExactIA5Match
SYNTAX IA5String
SINGLE-VALUED
DEFAULT No name
NAME DiffServInProfileRate
DESC Specifies the token rate for the in-profile traffic descriptor
in kbps
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
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
EQUALITY integerMatch
SYNTAX INTEGER
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 kilobits
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
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
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
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 Dont modify any bit, i.e.,
Mask 00000000
Modify 00000000
NAME DiffServOutProfileTransmittedTOSByte
DESC Specifies the outgoing TOS byte for out-of-profile packet
marking descriptor
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxiii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
resource group descriptors that apply to the traffic.
EQUALITY distinguishedNameMatch
SINGLE-VALUED
SYNTAX DN
DEFAULT Best Effort Service
7.1.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.
NAME DiffServResourceGroup
TYPE Structural
DERIVED FROM Top
AUXILIARY CLASSES NONE
MUST CommonName
MAY
DiffServLossParameter,
DiffServDelayParameter,
DiffServBandwidthShare,
DiffServExcessTrafficTreatment
DiffServAutoStart
DiffServResourceGroupName
NAME DiffServResourceGroupName
DESC The user friendly name of this entry.
EQUALITY caseExactIA5Match
SYNTAX IA5String
SINGLE-VALUED
DEFAULT No name
NAME DiffServLossParameter
DESC Packet loss paremeters for in-profile traffic for this
class of service
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxiv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
EQUALITY caseExactIA5Match
SYNTAX IA5String
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 bandwidth weight is converted into a bandwidth share at
the enforcement entity by adding the weights of all
DiffServ classes and then taking the appropriate
ratios. The second case is provided for instances where
the policy rule is unaware of the link capacity at the
enforcement entity.
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.
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
interpretation is implementation specific.
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
7.2. 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. As RSVP policy evolves to support the
signalling of richer classes of policy information such as user
ids, we may extend schema to provide for restrictions based on this
information as well.
Currently, there are two kinds of restrictions that we may place on
resource usage by RSVP flows -- individual restrictions and group
restrictions.
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.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxvi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
NAME RSVPFlowServiceType
DESC IntServ service type that a flow can request
EQUALITY caseExactIA5Match
SYNTAX IA5String
FORMAT: String with allowed values
ControlledLoad
GuaranteedService
MULTI-VALUED
Name RSVPPermission
DESC Allow/Dissallow RSVP flows
EQUALITY caseExactIA5Match
SYNTAX IA5String
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.
EQUALITY caseExactIA5Match
SYNTAX IA5String
SINGLE-VALUED
DEFAULT No Name
NAME RSVPMaxRatePerFlow
DESC The maximum token rate for any individual flow in kilobits per second
EQUALITY integerMatch
SYNTAX INTEGER
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
EQUALITY integerMatch
SYNTAX INTEGER
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
EQUALITY integerMatch
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxvii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
SYNTAX INTEGER
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
EQUALITY integerMatch
SYNTAX INTEGER
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
EQUALITY caseExactIA5Match
SYNTAX IA5String
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
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxviii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
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.
EQUALITY distinguishedNameMatch
MULTI-VALUED
SYNTAX DN
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
7.2.1. The Class RSVPResourceGroup
NAME RSVPResourceGroup
TYPE Structural
DERIVED FROM Top
AUXILIARY CLASSES NONE
MUST CommonName
MAY RSVPMaxFlows
RSVPMaxAggregateRate
RSVPMaxAggregateTokenBucket
RSVPResourceGroupName
NAME RSVPResourceGroupName
DESC The user friendly name of this entry.
EQUALITY caseExactIA5Match
SYNTAX IA5String
SINGLE-VALUED
DEFAULT No Name
NAME RSVPMaxFlows
DESC The maximum allowed number of reserved flows belonging to the
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxix]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
group
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
DEFAULT No limit
NAME RSVPMaxAggregateRate
DESC The aggregate maximum token rate for all flows in the group
EQUALITY integerMatch
SYNTAX INTEGER
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
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUED
DEFAULT No limit
7.3. The class TCPAction
End hosts and firewalls often control the number and nature of active
TCP connections. Each object of type TCPaction describes policies
used to control TCP behaviour.
The class description of TCPAction is as follows:
NAME TCPAction
TYPE Structural
DERIVED FROM PolicyAction
AUXILIARY CLASSES NONE
MUST
CommonName,
TCPPermission
MAY
TCPFlag,
MaxTCPSessions,
MaxRatePerTCPSession
NAME TCPPermission
DESC Allow/drop data packets matching the profile
EQUALITY caseExactIA5Match
SYNTAX IA5String
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxx]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
SINGLE-VALUED
FORMAT The currently defined values for this attribute are:
Accept
Deny
NAME TCPFlag
DESC The types of TCP packets to which the policy action applies.
EQUALITY caseExactIA5Match
SYNTAX IA5String
MULTI-VALUED
FORMAT The following strings are recognized:
``SYN''
``ACK''
``FIN''
``All''
DEFAULT ``All''
NAME TCPActionName
DESC The user friendly name of this entry.
EQUALITY caseExactIA5Match
SYNTAX IA5String
SINGLE-VALUED
DEFAULT No name
NAME MaxTCPSessions
DESC The maximum number of simultaneously open TCP sessions.
EQUALITY integerMatch
SYNTAX integer
SINGLE-VALUED
DEFAULT No limit
NAME MaxRatePerTCPSession
DESC The maximum rate in kilobits/sec that is allowed.
EQUALITY integerMatch
SYNTAX integer
SINGLE-VALUED
DEFAULT No limit
8. QoS Schema Usage Examples
In this section we describe some usage scenarios for QoS using LDIF
notation.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
8.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 achieves the above objective
dn: cn=S1-Web-Rule, o=XYZ, c=US
Objectclass: Policy
PolicyScope: DiffServ
PolicyType: DiffServ
PolicyConditionRef: cn=S1-Web-Condition,o=XYZ, c=US,
PolicyActionRef: cn=DSGoldService, o=XYZ, c=US
dn: cn=S2-Web-Rule, o=XYZ, c=US
Objectclass: Policy
PolicyScope: DiffServ
PolicyType: DiffServ
PolicyConditionRef: cn=S2-Web-Condition,o=XYZ, c=US,
PolicyActionRef: 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: IPPolicyCondition
SourceAddressRange: 1:1.1.0:24
SourcePortRange: 8000:8080
IPProtocolRange: 4 (TCP)
dn: cn=S2-Web-Condition, o=XYZ, c=US
Objectclass: IPPolicyCondition
SourceAddressRange: 1:2.2.2.0:24
SourcePortRange: 8000:8080
IPProtocolRange: 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
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
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
8.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: Policy
PolicyScope: DiffServ
PolicyType: DiffServ
PolicyConditionRef: cn=S3-Condition,o=XYZ, c=US,
PolicyActionRef: cn=S3-DS-Action, o=XYZ, c=US
dn: cn=S3-Condition,o=XYZ, c=US,
Objectclass: PolicyCondition
SourceAddressRange: 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
DiffServExcessTrafficTreatment: drop
DiffServAutoStart: NoAutoStart
Here, we have allocated a nominal token bucket to take care of the
maximum packet size.
8.3. Forbidding RSVP Sessions
Suppose that non-RSVP datatraffic 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.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxiii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
dn: cn=S1-RSVP-Rule, o=XYZ, c=US
Objectclass: Policy
PolicyScope: RSVP
PolicyType: RSVP
PolicyConditionRef: cn=S1-RSVP-Condition,o=XYZ, c=US,
PolicyActionRef: cn=S1-RSVP-Action, o=XYZ, c=US
dn: cn=S1-RSVP-Condition,o=XYZ, c=US
Objectclass: IPPolicyCondition
SourceAddressRange: 1:1.1.0:4
PolicyValidityPeriodRef: cn=workinghrs, o=XYZ, c=US
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
8.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: Policy
PolicyScope: RSVP
PolicyType: RSVP
PolicyConditionRef: cn=S1-CL-nw-Condition,o=XYZ, c=US,
PolicyActionRef: cn=S1-CL-nw-Action, o=XYZ, c=US
dn: cn=S1-CL-Condition,o=XYZ, c=US
Objectclass: IPPolicyCondition
SourceAddressRange: 1:1.1.0:4
PolicyValidityPeriodRef: cn=non-workinghrs, o=XYZ, c=US
dn: cn=non-workinghrs, o=XYZ, c=US
Objectclass: PolicyValidityPeriod
PolicyValidityTimeOfDayRange: 170000: 090000
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxiv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
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
9. 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 [12]. 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, Ed Ellesson, 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.
References
[1] L. Wells and R. Bartky, Data Link Switching, Switch to Switch
Protocol: AIW DLSW RIG, AIW Closed Pages, DLSW Standard 1.0,
RFC1795, April 1995.
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,
Resource ReSerVation Protocol (RSVP) Version 1 Functional
Specification. RFC2205, Sept. 1997.
[3] 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-00.txt, Jan. 1998.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998
[4] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access
Protocol, RFC1777, Mar. 1995.
[5] R. Droms, Dynamic Host Configuration Protocol, RFC1541, Oct.
1993.
[6] K. Nichols and S. Blake, Differentiated Services
Operational Model and Definitions, Internet-Draft,
draft-nichols-dsopdef-00.txt, Feb. 1998.
[7] 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.
[8] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework
for Policy-based Admission Control Internet Draft,
draft-ietf-rap-framework-00.txt, Nov. 1997.
[9] S. Judd and J. Strassner, Directory Enabled Networks -
Information Model and Base Schema - Draft v3.0c5 DEN
Specifications, Sep. 1998.
[10] P. Bhattacharya et. al., An LDAP Schema for Configuration and
Administration of IPSec-based Virtual Private Networks, Internet
Draft, draft-ietf-ipsec-policy-ldapschema-00.txt, Oct. 1998.
[11] Desktop Management Task Force, Common Information Model (CIM)
Specification, Version 2.0, Mar. 1998.
[12] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control
Requirements for LDAP, Internet Draft, Sep. 1998.
[13] J. Strassner and E. Ellesson, Terminology for describing network
policy and services Internet draft, draft-strassner-policy-terms-00.txt,
Aug. 1998.
rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxvi]
