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 then . 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]