[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/