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

Versions: 00

Internet Engineering Task Force                                  Authors
INTERNET DRAFT                                               Ed Ellesson
                                                            Sanjay Kamat
                                                              Raju Rajan
                                                            Dinesh Verma
                                                                     IBM
                                                        19 February 1998


 Schema for Service Level Administration of Differentiated Services and
                    Integrated Services in Networks
                    draft-ellesson-sla-schema-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 ds.internic.net (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.














ellesson, kamat, rajan, verma     Expires 19 September 1998     [Page i]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


1. Overview

   Internet Service Providers (ISPs) and corporate administrators
   need simple and comprehensive mechanisms to deliver Service Level
   Agreements (SLAs) that define contracts between the user and the
   network.  The introduction of such agreements means, that contrary
   to the current best-effort networks which treat all packets equally,
   the network now needs to discriminate between different packets
   to provide multiple service levels.  The Internet community has
   taken two main approaches to such service discrimination -- the
   integrated services with RSVP signaling (IntServ/RSVP) approach [2],
   and the differentiated services (DiffSrv) approach [6].  Support
   for such discrimination requires that the network control the
   amount of resources that each flow or set of flows is allowed to
   consume.  Irrespective of the actual mechanism employed for providing
   different service levels, there is a need to regulate who can get
   such services, at what times and specifically using which network
   resources.  This document addresses the issue of administering such
   QoS regulation policies.

   Integrated services with RSVP signaling approach seeks to provide
   per-flow QoS assurances with dynamic resource reservation.  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, on the other hand,
   are aimed at traffic aggregates that may not correspond to fine
   grained flows such as individual TCP sessions.  This approach
   may rely more on administrative control of bandwidth, delay or
   dropping preferences, rather than per-session 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, the 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.




ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page ii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   To ensure inter-operability in a heterogeneous environment where
   network devices and administrative tools are developed by multiple
   vendors, we need a common `language' to describe how administrative
   policies may be stored in the directory server function, as well as
   a standard mechanism for distributing the directory information to
   devices which act as directory clients.  This document describes a
   common language for describing administrative policies for integrated
   services and differentiated services in terms of an X.500 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.


2. Policy based QoS Control and SLA Administration

   There are many situations where proper resource control and
   administrative policy control need to be supported in the network.
   The following examples illustrate some of these.

   (1) An ISP operator provides VPN services to different corporations.
   In addition to VPN services, the operator supports two different
   types of individual internet accesses, premium access and normal
   access.  The service to Corporation A and Corporation B belongs to
   service level 1, service to Corporation C belongs to service level 2,
   individual subscribers to the premium service belong to service level
   3, and individual subscribers to the normal service belong to service
   level 4.  The operator needs to define and enforce specialized
   service definitions and access restrictions for these four service
   classes.

   (2) A network operator needs to support both voice-over-IP and
   data-over-IP in the network.  The number of simultaneously supported
   voice calls is needs to be limited, while providing voice some
   priority over data traffic.

   (3) A network administrator of an RSVP capable intranet wishes to
   restrict individual Controlled Load reservations from certain sources
   during the day (9am to 5pm) to a certain token rate and also limit
   the total bandwidth of such reserved flows.

   (4) A network operator interfaces with another network operator to
   support communication within their network.  Network operator A
   supports 4 service levels within network A, while network operator B



ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page iii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   only supports two service levels.  Network operator B maps the first
   two service levels of A to one type of its own service levels, and
   the remaining two into its second type of service level.

   (5) The operator of a companyintra-net supports different
   applications running over the company intra-net.  The company
   provides support for SNA-based transactional applications by using
   the DataLink Switching Protocol [1].  Other IP traffic is mainly used
   for web-access and non-transactional services over the intra-net.
   The operator wishes to provide a different level of service for DLSW
   traffic than other IP traffic.  He therefore states that TCP traffic
   using port numbers of 2065 or 2067 (DLSW read and write ports) be
   provided a different level of service than normal traffic.

   We now describe a generic architecture for directory driven control
   of network QoS. We follow this by specializing this architecture to
   the particular cases of QoS control for differentiated services and
   integrated services.


2.1. Architectural Overview

   A typical picture of network resource control involves a management
   tool, a policy repository, and a policy enforcement entity.  The
   network administrator uses the management tool to 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.  The management tool may or may not be co-located with the
   policy repository.  In any case, the administrator-specified rules
   are stored in the policy repository in a well understood format or
   schema.  The directory client downloads the policy rules from the
   repository, and uses these rules to classify the packet stream and
   apply specific actions to thus identified packets.  This architecture
   is illustrated in Figure 1.














ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page iv]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998



                  +------------------+
                  | Management Tool  |
                  +------------------+
                  | Directory Client |
                  +--------+---------+
                           |
                           |
                  +-------------------+
                  | Policy Repository |
                  | (Directory Server)|
                  +--------+----------+
                           |
                           |
                  +--------+------------+
                  |   Directory Client  |
                  +---------------------+
                  |  Policy Enforcement |
                  |        Entity       |
                  +---------------------+

                  Figure 1: Architectual Schematic




   The management tool would be vendor-specific and developed by
   different vendors with value-adds that they see fit.  However,
   there needs to be some common language to represent policy rules
   and a standard mechanism whereby the directory client may access
   them.  LDAP schemas are versatile and allow considerable flexibility
   in choice of back-end directory management.  Further, the LDAP
   client-server protocol is widely implemented and used for supporting
   a wide range of directory enabled applications.  Assuming LDAP as the
   directory access protocol, we will focus on describing an LDAP schema
   to represent the policy rules.

   From a directory-oriented perspective, the network consists of the
   directory server function (which could be a distributed network
   of directory servers), and one or more directory clients which
   query/update the directory.  Some of the directory clients are
   management tools which populate and maintain the policy repository in
   the directory.  Others are enforcement entities, that apply policy
   rules by dropping, marking, reshaping or otherwise conditioning
   the packet stream and in case of RSVP/IntServ perform policy based
   admission control.  Examples of such clients include routers,
   firewalls, proxy servers, or some other agents acting on behalf of
   the above such as RSVP policy servers.  We assume that policy rules



ellesson, kamat, rajan, verma     Expires 19 September 1998     [Page v]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   are relatively static.  The enforcement entity may either download
   the entire policy repository all at once, or may query the directory
   when needed, for instance, triggered by events such as an RSVP
   message, an IP packet bearing a TCP connect request, etc.


2.2. Differentiated Services Environment

   Figure 2 illustrates the use of the resource control policy
   architecture in a typical differentiated services environment.  In
   this scenario, an edge device is assumed to play the role of the
   directory client.  The name refers to the location of the device,
   which would most likely be placed at the access point between a local
   subnet and the backbone network or at the peering point between
   backbone networks of two service providers.  In either context,
   the edge device achieves service discrimination by classifying
   packets based on information such as protocol specific header
   fields (source/destination addresses, port numbers, Type of Service
   indication, etc.), time of day, the interface on which the packet is
   received or will be forwarded, etc.  There is no requirement for an
   explicit signaling protocol.  Consequently, the policy rules that
   are meaningful in this context are defined in terms of filters used
   to classify packets and the associated actions such as changing TOS
   encoding, buffering, dropping, shaping the traffic according to
   certain rate, etc.

   In addition to the scenario described above, the directory clients
   in this environment could also be the hosts themselves (when such
   hosts are required to mark packets or condition traffic entering the
   network).  When IP packets are encrypted end-to-end using a protocol
   such as IP-sec, an intermediate network device cannot access fields
   such as port numbers from the TCP/UDP header that are needed to
   classify packets to mark their TOS bits in the IP header.  In such a
   situation, it is important that the hosts themselves are capable of
   packet marking and thus act as directory clients to obtain the packet
   classification rules.















ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page vi]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


             Administrative Domain 1     Admin Domain 2
            _______________/\___________     __/\___
           {                            }   {       }
           Network
           Access     Backbone
    Local  Point      Router
    Host   +------+   +------+   +------+   +------+
   +----+  |      |   |      |   |      |   |      |
   |    |--| ED-1 |---|      |---|ED-2  |---|      |
   +----+  +------+   +------+   +------+   +------+
            |    \                /
    Local   |     \              /
    Host   /       \ LDAP       /LDAP
   +----+ /         \          /
   |    |/           \        /
   +----+             \      /
                       \    /
   +----------+        +-----------+
   |Management|________| Directory |
   |  Tool    |  LDAP  |           |
   +----------+        +-----------+

            Figure 2: Differntiated Services Scenario




2.3. Integrated Services Environment

   Typically, in an integrated services environment with RSVP, end hosts
   signal resource requirements for specific sessions to the network.
   RSVP sessions may also be established between aggregation points,
   such as routers.  At policy capable RSVP routers, PATH and RESV
   messages are processed to approve or deny the reservation requests
   based on the administrative policy.  It is possible that policy
   processing is outsourced to a policy server in which case the policy
   server would be the directory client communicating with the directory
   server using LDAP and a policy protocol such as one described in
   [3] is used for communication between the policy server and router.
   Figure 3 depicts the architecture in the Int-Serv context.  In this
   figure, there are two RSVP policy capable routers one of which is
   also policy capable and acts as the policy enforcement entity while
   the other one outsources policy enforcement function to a policy
   server.  In either case, the policy enforcement entity (policy
   capable router or the policy server) access the directory to obtain
   the relevant policy rules that have been administratively configured.





ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page vii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


                      Policy
                      Incapable
           Local      Router      RSVP Policy
           Subnet     +------+    Outsourcing  +------+
          +----+      |      |    Protocol     |Policy|
          |    |      |      |-----------------|Server|
 Session 1|<---|------|------|->               |      |
 Session 2|<---|------|------|->               |      |
    +-----|->  |      +------+                 +------+
    |     +----+                                  /
    |                                            /
 Session 3  Policy                              /
    |       Capable                            /
    |       Router                            /LDAP
    |     +----+             LDAP            /
    +-----|----|-->                         /
          |    |-------------+             /
          +----+              \           /
                               \         /
          +----------+        +-----------+
          |Management|________| Directory |
          |  Tool    |  LDAP  |           |
          +----------+        +-----------+

            Figure 3: Integrated Services Scenario





3. LDAP schema

3.1. Objectives

   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.



ellesson, kamat, rajan, verma   Expires 19 September 1998    [Page viii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


    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 first 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.2. Schema

   We define a single LDAP object class called ServicePolicyRules
   as the container for policy rules.  The syntax and semantics
   of different attributes of this object class will be defined
   with the above goals in mind.  In this document we focus on the
   ServicePolicyRules object class itself and not on where it is
   placed in the organization's existing directory tree.  However,
   we make certain minimal assumptions regarding a portion of the
   subtree that is above the ServicePolicyRules object class.  This
   will allow us to avoid replication of certain attributes in each
   entry of an ServicePolicyRules instance and rather assume them to
   be inherited from the parent objectclass.  For example, we assume
   that policies are grouped by organizations or administrative domains
   and certain defaults that apply to all policies for the domain are
   stored as values of certain attributes in the parent objectclass of
   ServicePolicyRules.  Examples of such attributes are:

    -  policyCheckEnabled:  Policy rules enforced or not.

    -  messageLoggingEnabled:  Indicates whether logging of signaling
       (RSVP) messages is on/off.

   The ServicePolicyRules object class consists of a number of entries;
   each entry is composed of several attributes.  Each attribute is of
   a certain type, and has one or more values.  In the schema discussed
   in this draft, the two principal components of a policy entry are a
   `profile' and a `behavior.'  The entry itself defines a policy rule
   which can be thought of as specifying:

                     If <profile> then <behavior>.

   A profile is defined by the values of a collection of certain
   attributes that are typically used to determine when a policy rule



ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page ix]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   applies.  A typical profile is, for instance, a range of source
   addresses (or a source address and mask) to which the policy applies.
   Behavior is defined by a collection of attributes that detail
   permissions or additional actions that the policy enforcement entity
   should perform for the given profile.  A simple example of a behavior
   attribute is Permission with values accept and deny which indicates
   whether packets meeting a certain profile should be granted access to
   the network or dropped.

   Although this differentiation may suggest creating separate object
   classes to define profiles and behaviors, we argue for keeping these
   together.  Often, the distinction between profiles and behaviors
   is not absolute and which attributes play what role is very much
   dependent on the context of policy enforcement environment.  For
   example, consider the attribute MaxRate which specifies an upper
   limit on the total bandwidth that all packets matching the profile
   may consume.  In a DiffServ environment, the edge device which
   acts as a directory client may use this as a behavior attribute to
   determine the pacing rate for packets matching the profile.  On the
   other hand, in an IntServ environment with RSVP, a policy server (or
   policy capable router) which acts as the directory client may use
   this attribute as a profile attribute to check if the reservation
   request parameters match the profile and then make an appropriate
   admission control decision.

   In addition to the two principal components, there are other
   attributes whose role is to facilitate grouping of policy attributes
   in a manner most convenient for specific administrative domains,
   as well as for simplifying the representation of policy rules.  It
   is conceivable that policy administrators may find it useful to be
   able to group and label certain recurring profiles/behaviors so that
   they can be conveniently referred to, potentially in defining new
   policies.  It is, however, difficult to predict all such grouping
   needs in advance and design an LDAP schema hierarchy to reflect this
   grouping of attributes.  This is another reason we prefer to keep all
   the attributes that define a policy rule in a single object class,
   and provide means whereby administrators may group policies as they
   see fit.

   Before we present an exhaustive list of attributes, we explain the
   overall design of the schema and its functionality.


3.3. Self-Contained Entries

   In its simplest form, an entry completely describes a single policy
   rule.  Consider the following examples of such self-contained
   entries.



ellesson, kamat, rajan, verma     Expires 19 September 1998     [Page x]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   Suppose that users from a particular subnet 2.3.x.x are to be denied
   access to the network.  We have the following entry to express this
   policy.

        Name                  Entry1
        PolicyScope           DataTraffic
        SourceAddressRange    2.3.x.x
        Permission            Deny


   The PolicyScope with value DataTraffic means that this entry refers
   to policy applied to data traffic, rather than that applied to
   resource reservation messages such as RSVP control traffic.  The
   SourceAddressRange attribute is the profile, and the value of the
   behavior Permission is Deny.

   Now, consider a more sophisticated policy rule that allows for no
   more than an aggregate of 5000 kilobits/second of outgoing best
   effort traffic from sources in range 139.24.2.12 to 139.24.2.255
   during the day (9 am to 5 pm).

        Name                  Entry2
        PolicyScope           DataTraffic
        TimeOfDayRange        090000 to 170000
        SourceAddressRange    139.24.2.12 to 139.24.2.255
        Direction             Outgoing
        MaxeRate              5000


   We may regard the profile as consisting of the attributes
   TimeOfDayRange, SourceAddressRange and Direction, while the behavior
   is specified by the attribute MaxAggregateRate.

   Consider a policy that specifies that each RSVP controlled load
   reservation for outgoing traffic from subnet 140.24.x.x.  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.

        Name                  Entry3
        PolicyScope           RSVP
        FlowServiceType       GuaranteedRate
        SourceAddressRange    140.24.x.x
        MaxRatePerFlow        1000
        MaxFlows              100






ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page xi]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   It is possible, though often cumbersome, to completely specify
   any set of policies using a set of self-contained entries in
   ServicePolicyRules object class.  In this case, the policy
   enforcement entity applies all the rules embodied in self-contained
   entries to each (data or signaling) packet.  (Of course, by a clever
   ordering of the rules the enforcement entity may avoid searching
   through inapplicable entries).  It is very important to ensure that
   the entries are consistent, i.e., the order of search does not affect
   the outcome at the enforcement entity.  For instance, consider the
   following two rules.  The first specifies that all TCP packets
   (Protocol Number 6) should me marked with the TOS value 101.  The
   second specifies that all packets from the subnet 4.3.*.* should be
   marked with TOS value 111.

        Name                  Entry1
        PolicyScope           DataPackets
        ProtocolNumber        6
        OutgoingTOS           101


        Name                  Entry2
        PolicyScope           DataPackets
        SourceAddressRange    4.3.*.*
        OutgoingTos           111


   These rules leave ambiguous the fate of TCP packets from the
   specified subnet.  Of course, this example is simplistic, but
   care must be taken to ensure that if a packet could match multiple
   filters, then actions specified by all filters, applied in any order,
   yield the same result.


3.4. Exceptions and the Default Entry

   As mentioned above, it is often cumbersome to specify policy rules
   as a flat set of self-contained entries.  Suppose the only policy
   rule that needs to be administered at a firewall is to allow incoming
   packets destined to a web-server 23.2.9.2.  Then we would need the
   following entries :

        Name                  Entry1
        PolicyScope           DataPackets
        Direction             Outgoing
        Permission            Accept


        Name                  Entry2



ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page xii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


        PolicyScope           DataPackets
        SourceAddressRange    23.2.9.2
        Direction             Incoming
        Permission            Accept


        Name                  Entry3
        PolicyScope           DataPackets
        SourceAddressRange    0.0.0.0 to 23.2.9.1
        Direction             Incoming
        Permission            deny


        Name                  Entry4
        PolicyScope           DataPackets
        SourceAddressRange    23.2.9.3 to 255.255.255.255
        Direction             Incoming
        Permission            deny


   It is much easier to represent this with rules Entry1 and Entry3 as
   specified above and a Default policy rule defined as follows:

        Name                  Default
        PolicyScope           Both
        Permission            deny
        Exception             Entry1, Entry2


        Name                  Entry1
        PolicyScope           DataPackets
        Direction             Outgoing
        Permission            Accept


        Name                  Entry2
        PolicyScope           DataPackets
        SourceAddressRange    23.2.9.2
        Direction             Incoming
        Permission            Accept


   The Exception attribute of the Default entry specifies the unique
   names of the entries which form exceptions to the default rule.
   Hence, each packet is matched with the profile of the default entry
   which specifies that every packet be denied.  However, this rule is
   not applied to packets that match the either of filters specified by
   Entries 1 and 3.



ellesson, kamat, rajan, verma   Expires 19 September 1998    [Page xiii]


 Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


    It is easy to come up with examples where the use of the Exception
    attribute can be a valuable shortcut.  In using the Exception
    attribute correctly, the enforcement entity uses a ``most specific
    match'' based on the following 2 rules :

Rule 1: For each entry in the object class ServicePolicyRules,
        determine if the profile of the entry matches the packet to be
        classified/conditioned.

Rule 2: If the profile matches, apply the behavior specified by the
        entry, if and only if the profiles of no exception to the entry
        match the packet.


 3.5. References and Grouping

    Administrators may find it useful to define ``behavior categories'',
    or user groups that may then be conveniently referred to in other
    policies.  For instance, suppose an ISP has a service level agreement
    with two of its customers, Companies A and B, to support up to 30
    Mbps of Premium traffic, identified by PHB values 011, and 50 Mbps
    of Gold traffic, identified by TOS values 101.  Premium and Gold
    traffic have different drop priorities, but are otherwise treated
    similarly.  Excess Gold traffic is to be treated as best effort,
    while excess Premium traffic is to be treated as Gold.  The policy
    repository may then contain 3 object classes, say ServicePolicyRules,
    UserProfiles and ServiceCategories as defined below -- each based
    on the same schema.  Note that there is nothing sacred about this
    particular grouping; administrators may find it useful to have more
    than two external object classes with different names and schemas for
    conveniently referring to groups of attributes.  UserProfiles

         Name                  CompanyAProfile
         PolicyScope           DataTraffic
         SourceAddressRange    123.2.35.x


         Name                  CompanyBProfile
         PolicyScope           DataTraffic
         SourceAddressRange    221.5.x.x


 ServiceCategories

         Name                  PremiumService
         PolicyScope           DataTraffic
         MaxRate               30000
         Priority              1



 ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page xiv]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


        OutgoingTOS           011
        ExcessTreatment       GoldService


        Name                  GoldService
        PolicyScope           DataTraffic
        MaxRate               50000
        Priority              2
        OutgoingTOS           101
        ExcessTreatment       BestEffort


        Name                  BestEffort
        PolicyScope           DataTraffic
        Priority              3
        OutgoingTOS           000


ServicePolicyRules

        Name                  CompanyA-Premium
        IncomingTOS           011
        ExternalReference     UserProfiles.CompanyAProfile,
                              ServiceCategories.PremiumService


        Name                  CompanyB-Premium
        ExternalReference     UserProfiles.CompanyBProfile,
                              ServiceCategories.PremiumService
        IncomingTOS           011


        Name                  CompanyA-Gold
        ExternalReference     UserProfiles.CompanyAProfile,
                              ServiceCategories.GoldService
        IncomingTOS           101


        Name                  CompanyB-Gold
        ProfileReference      UserProfiles.CompanyAProfile
        IncomingTOS           011
        ServiceReference      ServiceCategories.GoldService


   The policy client can formulate an unambiguous set of rules to
   deal with incoming packets on the basis of the ServicePolicyRules
   object class, by referring to the other object classes.  There may




ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page xv]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


   be as many other object classes as is convenient for administrative
   purposes.


3.6. List of Attributes

   The syntax and semantics of the attributes of a ServicePolicyRules
   entry are described below.  The specification loosely follows
   the format recommended by [7].  First, we describe the mandatory
   attributes and then the optional ones in the following order:
   attributes common to IntServ and DiffServ environments, attributes
   specific to DiffServ environment, and attributes specific to IntServ
   (with RSVP-based admission control) environment.


3.6.1. Mandatory Attributes

   Only two mandatory attributes are currently defined.

(slaSchema.1.0
NAME 'Name'
DESC 'A unique distinguished name given to this policy entry'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE)

First, this attribute serves as the `rdn' of a policy entry, i.e., it
uniquely identifies a policy entry in the directory. This attribute is also
considered as a name for the `profile' part of the policy and as will be
explained later (in the context of the `ProfileReference' attribute), used
to define new policy rules using existing ones.

(slaSchema.1.1
NAME 'PolicyScope'
DESC 'States whether this rule applies to data traffic conditioning,
      RSVP admission control, or both'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE)

The currently defined values for this attribute are:
    DataTraffic
    RSVP
    Both

The value `DataTraffic' means the profile definition is for a DiffServ packet
classification and traffic conditioning device while the value `RSVP' means
it is for an RSVP policy server and `Both' implies either of the two. This



ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page xvi]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


attribute may be used by the appropriate directory clients to fetch only those
policy rules that are relevant for their functionality.



3.6.2. Attributes Common to IntServ and DiffServ

   We now list some attributes that are useful in defining common
   network resource and service level regulation policies applicable to
   both RSVP based IntServ model and the DiffServ model.

   The following attribute is provided to facilitate composition of new
   profiles/policies using existing ones.

(slaSchema.1.2
NAME 'ExternalReference'
DESC 'Distinguished name(s) of LDAP entries, possibly from other
      objectclasses, that allows arbitrary grouping and reuse of
      existing user profile and behavior definitions in the directory'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')



   This optional attribute allows reuse of pre-defined profiles or
   behaviors in two ways.  First, it allows reference to information
   present elsewhere in the enterprise/service provider directory tree
   where administrators may already have object classes with user
   (profile) and service categories (behaviors) definitions.  By simply
   referring to such entries in this attribute, service level policies
   for these users can be created without the need to redefine them.
   Secondly, it enables definition of `aggregate' profiles and their
   policies.  Note that this attribute can be multi-valued and thus,
   the profile to which this policy applies is obtained union of all
   profiles defined by this attribute.

   Attributes listed below are generic ones for defining common profiles
   and actions, applicable to both data traffic conditioning and RSVP
   admission control.

(slaSchema.1.3
NAME 'SourceAddressRange'
DESC 'Source addresses to which policy applies'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: string is of the form x1.x2.x3.x4 to y1.y2.y3.y4.
        x1 etc integers between 0 and 255



ellesson, kamat, rajan, verma   Expires 19 September 1998    [Page xvii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


Example: 9.3.1.32 to 9.3.1.64
Semantics: Second address larger than first
           Trailing '*' to denote all of range.
           eg. 233.122.*  for 233.122.0.0 to 233.122.255.255


(slaSchema.1.4
NAME 'DestinationAddressRange'
DESC 'Destination addresses to which policy applies'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: string x1.x2.x3.x4 to y1.y2.y3.y4
        x1 etc integers between 0 and 255
Example: 9.3.1.32 to 9.3.1.128
Restriction: Second address larger than first


(slaSchema.1.5
NAME 'SourcePortRange'
DESC 'Source Ports to which policy applies'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: string is of the form x1 to y1
        x1 etc. integers
Example:3 to 33
Restrictions: Second number larger than first

(slaSchema.1.6
NAME 'DestinationPortRange'
DESC 'Destination Ports to which policy applies'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: string is of the form x1 to y1
        x1 etc. integers
Example: 3 to 33
Restrictions: Second number larger than first


(slaSchema.1.7
NAME 'ProtocolNumber'
DESC 'Protocol numbers to which policy applies'
EQUALITY integerMatch
SYNTAX 'INTEGER')

Example: 12



ellesson, kamat, rajan, verma   Expires 19 September 1998   [Page xviii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998



(slaSchema.1.8
NAME 'Permission'
DESC 'Allow data packets or reservation requests matching the profile'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE )

(slaSchema.1.9
NAME 'MaxRate'
DESC 'The maximum token rate for any individual flow in kilobits per second'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE)

Example: 35
Semantics: In the Diff-Serv context, this rate determines the traffic
           conditioning actions for packets matching the profile. In the
           RSVP-IntServ context, this rate specifies a bound for admission
           control limiting total reservation of all flows matching the
           profile. Also note that, when the ProfileReference attribute is
           present, the profile is obtained by a union of all the referenced
           profiles.


(slaSchema.1.10
NAME 'MaxTokenBucket'
DESC 'The maximum token bucket size for any individual flow in kilobits '
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE)

Example: 60
Semantics: Applicability in the DiffServ and IntServ contexts is as in the case
           of MaxRate.

(slaSchema.1.11
NAME 'Priority'
DESC 'Priority level for traffic. (Locally defined semantics)'
EQUALITY integerMatch
SYNTAX 'INTEGER')

Semantics: 1. Different priorities could correspond to different
              dropping thresholds.
           2. Different priorities could correspond to different queuing
              priorities.

(slaSchema.1.12



ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page xix]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


NAME 'ValidityPeriod'
DESC 'When this policy is valid'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: String(s) of the form yyyymmddhhmmss to yyyymmddhhmmss
               year-month-date-hour-minute-second
Multivalued: YES
Example: 19980121000000 to 19991231000000
Restrictions: Must be valid dates, Second Larger than first

(slaSchema.1.13
NAME 'MonthMask'
DESC 'Months during which policy is valid'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE)

Format: String denoting a mask of 12 0s and 1s, 1's corresponding to valid
        months in the January to December range.
Example: 000111111100
         Valid from April to October



(slaSchema.1.14
NAME 'DayOfWeekMask'
DESC 'days during which policy is valid'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE)

Format: String representing a mask of 7 0s and 1s. Monday to Sunday
Example: 1111100
         Valid weekdays

(slaSchema.1.15
NAME 'TimeOfDayRange'
DESC 'Time(s) of day during which policy is valid'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: string of the form  hhmmss to hhmmss
Multivalued: YES
Example: 090000 to 170000
         9 am to 5 pm
Restrictions: Must be valid time of day values.




ellesson, kamat, rajan, verma    Expires 19 September 1998     [Page xx]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


(slaSchema.1.16
NAME 'Interface'
DESC 'IP address of the specific interface(s) for which this policy applies'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: string which has one of the following currently defined values
Incoming
Outgoing
Both

(slaSchema.1.17
NAME 'Direction'
DESC 'The direction of packet traffic on an interface for which this
      rule applies'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE)

Format: string which has one of the following currently defined values
Incoming
Outgoing
Both

(slaSchema.1.18
NAME 'Exception'
DESC 'Presence of this attribute signifies that this policy rule has
      certain exceptions and the value of this attribute is a list of
      (policy) Names referring to those exception rules'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: String, Distinguished Name of another entry
Example: ManagerProfilePolicy
Restrictions: Must be valid dn




3.6.3. Attributes Relevant to DiffServ Model

   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).


(slaSchema.1.19



ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page xxi]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


NAME 'ReceivedTOSMask'
DESC 'Ignore certain fields on the packet header'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: One Byte

(slaSchema.1.20
NAME 'ReceivedTOSMatch'
DESC 'TOS byte contents of the packet IP header'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: One Byte
Semantics: The IncomingTOSMask is applied (through an AND) to the
           packet TOS byte, and then the packet is matched with the
           IncomingTOSMatch.
Example : An incoming packet with TOS bits 11001010 matches the filter
          with IncomingTOSMask 01111100 and IncomingTOSMatch  00001000

(slaSchema.1.21
NAME 'TransmittedTOSMask'
DESC 'Transmit certain TOS bits without change'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: One Byte

(slaSchema.1.22
NAME 'TransmittedTOSMark'
DESC 'Mark Certain TOS bits before transmitting packet'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: One Byte
Semantics: `TransmittedTOSMark' indicates the new TOS value
           that the traffic conditioning device should mark on the
            packet header after masking the bits as specified by
            TransmittedTOSMark. The operation involved is
            (Mask' & TOSbyte) | (Mask & Mark), where Mask' is the
            bitwise complement of Mask.
Example: A packet with TOS bits 10101010 acted on by a policy rule
         with  attribute TransmittedTOSMask 11100000 and TransmittedTOSMark
         11001010 means, leave the last 5 bits of the TOS byte unchanged, and
         modify the first 3 to 110, i.e., the transmitted packet bears the TOS
         byte 11001010

(slaSchema.1.23



ellesson, kamat, rajan, verma   Expires 19 September 1998    [Page xxii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


NAME 'ExcessTreatment'
DESC 'Reference to an external entry defining how non-conformant
      traffic is to be treated'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')



3.6.4. Attributes Relevant to IntServ with RSVP Model

   The following set of attributes are meaningful in the IntServ-RSVP
   context.


(slaSchema.1.24
NAME 'FlowServiceType'
DESC 'IntServ service type that a flow can request'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String')

Format: String with allowed values
ControlledLoad
Guaranteed

(slaSchema.1.25
NAME 'MaxRatePerFlow'
DESC 'The maximum token rate for any individual flow in kilobits per second'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE)

Example: 35
Semantics: Reservation requests for higher per-flow bandwidth are denied.

(slaSchema.1.26
NAME 'MaxTokenBucketPerFlow'
DESC 'The maximum token bucket size for any individual flow in kilobits '
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE)

Example: 60
Semantics: Reservation requests for higher per-flow token bucket size are denied.

(slaSchema.1.27
NAME 'MinDelay'
DESC 'The minimum delay value an individual flow may request in millisec'
EQUALITY integerMatch



ellesson, kamat, rajan, verma   Expires 19 September 1998   [Page xxiii]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


SYNTAX 'INTEGER'
SINGLE-VALUE)

Example: 100

(slaSchema.1.28
NAME 'Authentication'
DESC 'Manner of authentication to be performed'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String'
SINGLE-VALUE)

Format: String, only currently defined value is
None      (for no authentication)



(slaSchema.1.29
NAME 'MaxFlows'
DESC 'The maximum allowed number of reserved flows matching the
      specified profile(s)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE)




4. Security Considerations

   Security Considerations are not discussed in this memo.


Acknowledgments

   Thanks to Partha Bhattacharya, John Chu, Roch Guerin, Arvind
   Krishna, Dimitrios Pendarakis, Ellen Stokes and John Tavs for useful
   discussion and suggestions in this problem space.


Authors' Address

   Ed Ellesson             Phone: (919) 254-4115
JDGA/501
IBM Corporation
4205 S. Miami Blvd.
Research Triangle Park, NC 27709
                       Email: ellesson@raleigh.ibm.com



ellesson, kamat, rajan, verma   Expires 19 September 1998    [Page xxiv]


Internet Draft     draft-ellesson-sla-schema-00.txt      19 February 1998


Sanjay Kamat             Phone: (914) 784-7402
                        Email: sanjay@watson.ibm.com
Raju Rajan               Phone: (914) 784-7260
                        Email: raju@watson.ibm.com
Dinesh Verma             Phone: (914) 784-7466
                        Email: dverma@watson.ibm.com
IBM T. J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598


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.

   [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.








ellesson, kamat, rajan, verma    Expires 19 September 1998    [Page xxv]


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