tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3644

 
 
 

Policy Quality of Service (QoS) Information Model

Part 2 of 3, p. 23 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 23 
2.  Class Hierarchies

2.1.  Inheritance Hierarchy

   QPIM's class and association inheritance hierarchies are rooted in
   [PCIM] and [PCIMe].  Figures 2 and 3 depict these QPIM inheritance
   hierarchies, while noting their relationships to [PCIM] and
   [PCIMe]classes.  Note that many other classes used to form QPIM
   policies, such as SimplePolicyCondition, are defined in [PCIM] and
   [PCIMe].  Thus, the following figures do NOT represent ALL necessary
   classes and relationships for defining QPIM policies.  Rather, the
   designer using QPIM should use appropriate classes and relationships
   from [PCIM] and [PCIMe] in conjunction with those defined below.

Top      Up      ToC       Page 24 
 [ManagedElement] (abstract, PCIM)
   |
   +--Policy (abstract, PCIM)
   |  |
   |  +---PolicyAction (abstract, PCIM)
   |  |     |
   |  |     +---SimplePolicyAction (PCIMe)
   |  |     |   |
   |  |     |   +---QoSPolicyRSVPSimpleAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyDiscardAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyAdmissionAction (abstract, QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyPoliceAction (QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyShapeAction (QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyRSVPAdmissionAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyPHBAction (abstract, QPIM)
   |  |         |
   |  |         +---QoSPolicyBandwidthAction (QPIM)
   |  |         |
   |  |         +---QoSPolicyCongestionControlAction (QPIM)
   |  |
   |  +---QoSPolicyTrfcProf (abstract, QPIM)
   |  |   |
   |  |   +---QoSPolicyTokenBucketTrfcProf (QPIM)
   |  |   |
   |  |   +---QoSPolicyIntServTrfcProf (QPIM)
   |  |
   |  |
   |  +---PolicyVariable (abstract, PCIMe)
   |  |   |
   |  |   +---PolicyImplicitVariable (abstract, PCIMe)
   |  |       |
   |  |       +---QoSPolicyRSVPVariable (abstract, QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
   |  |           |

(continued on the next page)

Top      Up      ToC       Page 25 
(continued from the previous page)

[ManagedElement] (abstract, PCIM, repeated for convenience)
   |
   +--Policy (abstract, PCIM, repeated for convenience)
   |  |
   |  +---PolicyVariable (abstract, PCIMe)
   |  |   |
   |  |   +---PolicyImplicitVariable (abstract, PCIMe)
   |  |       |
   |  |       +---QoSPolicyRSVPVariable (abstract, QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPSourcePortVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDestinationPortVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPIPProtocolVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPIPVersionVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDCLASSVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPStyleVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDIntServVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPMessageTypeVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPUserVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPApplicationVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPAuthMethodVariable (QPIM)
   |  |
   |  +---PolicyValue (abstract, PCIMe)
   |  |     |
   |  |     +---QoSPolicyDNValue (QPIM)
   |  |     |
   |  |     +---QoSPolicyAttributeValue (QPIM)

            Figure 2.  The QPIM Class Inheritance Hierarchy

Top      Up      ToC       Page 26 
2.2.  Relationship Hierarchy

   Figure 3 shows the QPIM relationship hierarchy.

   [unrooted] (abstract, PCIM)
     |
     +---Dependency (abstract)
     |   |
     |   +--- QoSPolicyTrfcProfInAdmissionAction (QPIM)
     |   |
     |   +--- QoSPolicyConformAction (QPIM)
     |   |
     |   +--- QoSPolicyExceedAction (QPIM)
     |   |
     |   +--- QoSPolicyViolateAction (QPIM)
     |   |
     |   +--- PolicyVariableInSimplePolicyAction
     |   |       |
     |   |       + QoSPolicyRSVPVariableInRSVPSimplePolicyAction

        Figure 3.  The QPIM Association Class Inheritance Hierarchy

3.  QoS Actions

   This section describes the QoS actions that are modeled by QPIM.  QoS
   actions are policy enforced network behaviors that are specified for
   traffic selected by QoS conditions.  QoS actions are modeled using
   the classes PolicyAction (defined in [PCIM]), SimplePolicyAction
   (defined in [PCIMe]) and several QoS actions defined in this document
   that are derived from both of these classes, which are described
   below.

   Note that there is no discussion of PolicyRule, PolicyGroup, or
   different types of PolicyCondition classes in this document.  This is
   because these classes are fully specified in [PCIM] and [PCIMe].

3.1.  Overview

   QoS policy based systems allow the network administrator to specify a
   set of rules that control both the selection of the flows that need
   to be provided with a preferred forwarding treatment, as well as
   specifying the specific set of preferred forwarding behaviors.  QPIM
   provides an information model for specifying such a set of rules.

   QoS policy rules enable controlling environments in which RSVP
   signaling is used to request different forwarding treatment for
   different traffic types from the network, as well as environments
   where no signaling is used, but preferred treatment is desired for

Top      Up      ToC       Page 27 
   some (but not all) traffic types.  QoS policy rules also allow
   controlling environments where strict QoS guarantees are provided to
   individual flows, as well as environments where QoS is provided to
   flow aggregates.  QoS actions allow a PDP or a PEP to determine which
   RSVP requests should be admitted before network resources are
   allocated.  QoS actions allow control of the RSVP signaling content
   itself, as well as differentiation between priorities of RSVP
   requests.  QoS actions allow controlling the Differentiated Service
   edge enforcement including policing, shaping and marking, as well as
   the per-hop behaviors used in the network core.  Finally, QoS actions
   can be used to control mapping of RSVP requests at the edge of a
   differentiated service cloud into per hop behaviors.

   Four groups of actions are derived from action classes defined in
   [PCIM] and [PCIMe].  The first QoS action group contains a single
   action, QoSPolicyRSVPSimpleAction.  This action is used for both RSVP
   signal control and install actions.  The second QoS action group
   determines whether a flow or class of flows should be admitted.  This
   is done by specifying an appropriate traffic profile using the
   QoSPolicyTrfcProf class and its subclasses.  This set of actions also
   includes QoS admission control actions, which use the
   QoSPolicyAdmissionAction class and its subclasses.  The third group
   of actions control bandwidth allocation and congestion control
   differentiations, which together specify the per-hop behavior
   forwarding treatment.  This group of actions includes the
   QoSPolicyPHBAction class and its subclasses.  The fourth QoS action
   is an unconditional packet discard action, which uses the
   QoSPolicyDiscardAction class.  This action is used either by itself
   or as a building block of the QoSPolicyPoliceAction.

   Note that some QoS actions are not directly modeled.  Instead, they
   are modeled by using the class SimplePolicyAction with the
   appropriate associations.  For example, the three marking actions
   (DSCP, IPP and CoS) are modeled by using the SimplePolicyAction
   class, and associating that class with variables and values of the
   appropriate type defined in [PCIMe].

3.2.  RSVP Policy Actions

   There are three types of decisions a PDP (either remote or within a
   PEP) can make when it evaluates an RSVP request:

   1.  Admit or reject the request
   2.  Add or modify the request admission parameters
   3.  Modify the RSVP signaling content

Top      Up      ToC       Page 28 
   The COPS for RSVP [RFC2749] specification uses different Decision
   object types to model each of these decisions.  QPIM follows the COPS
   for RSVP specification and models each decision using a different
   action class.

   The QoSPolicyRSVPAdmissionAction controls the Decision Command and
   Decision Flags objects used within COPS for RSVP.  The
   QoSPolicyRSVPAdmissionAction class, with its associated
   QoSPolicyIntServTrfcProf class, is used to determine whether to
   accept or reject a given RSVP request by comparing the RSVP request's
   TSPEC or RSPEC parameters against the traffic profile specified by
   the QoSPolicyIntServTrfcProf.  For a full description of the
   comparison method, see section 4.  Following the COPS for RSVP
   specification, the admission decision has an option to both accept
   the request and send a warning to the requester.  The
   QoSPolicyRSVPAdmissionAction can be used to limit the number of
   admitted reservations as well.

   The class QoSPolicyRSVPSimpleAction, which is derived from the
   PolicySimpleAction class [PCIMe], can be used to control the two
   other COPS RSVP decision types.  The property qpRSVPActionType
   designates the instance of the class to be either of type 'REPLACE',
   'STATELESS', or both ('REPLACEANDSTATELESS').  For instances carrying
   a qpRSVPActionType property value of 'REPLACE', the action is
   interpreted as a COPS Replace Decision, controlling the contents of
   the RSVP message.  For instances carrying a qpRSVPActionType property
   value of 'STATELESS', the action is interpreted as a COPS Stateless
   Decision, controlling the admission parameters.  If both of these
   actions are required, this can be done by assigning the value
   REPLACEANDSTATELESS to the qpRSVPActionType property.

   This class is modeled to represent the COPS for RSVP Replace and
   Stateless decisions.  This similarity allows future use of these COPS
   decisions to be directly controlled by a QoSPolicySimpleAction.  The
   only required extension might be the definition of a new RSVP
   variable.

3.2.1.  Example: Controlling COPS Stateless Decision

   The QoSPolicyRSVPSimpleAction allows the specification of admission
   parameters.  It allows specification of the preemption priority
   [RFC3181] of a given RSVP Reservation request.  Using the preemption
   priority value, the PEP can determine the importance of a Reservation
   compared with already admitted reservations, and if necessary can
   preempt lower priority reservations to make room for the higher
   priority one.  This class can also be used to control mapping of RSVP
   requests to a differentiated services domain by setting the

Top      Up      ToC       Page 29 
   QoSPolicyRSVPDCLASSVariable to the required value.  This instructs
   the PEP to mark traffic matching the Session and Sender
   specifications carried in an RSVP request to a given DSCP value.

3.2.2.  Example: Controlling the COPS Replace Decision

   A Policy system should be able to control the information carried in
   the RSVP messages.  The QoSPolicyRSVPSimpleAction allows control of
   the content of RSVP signaling messages.  An RSVP message can carry a
   preemption policy object [RFC3181] specifying the priority of the
   reservation request in comparison to other requests.  An RSVP message
   can also carry a policy object for authentication purposes.  An RSVP
   message can carry a DCLASS [DCLASS] object that specifies to the
   receiver or sender the particular DSCP value that should be set on
   the data traffic.  A COPS for RSVP Replacement Data Decision controls
   the content of the RSVP message by specifying a set of RSVP objects
   replacing or removing the existing ones.

3.3.  Provisioning Policy Actions

   The differentiated Service Architecture [DIFFSERV] was designed to
   provide a scalable QoS differentiation without requiring any
   signaling protocols running between the hosts and the network.  The
   QoS actions modeled in QPIM can be used to control all of the
   building blocks of the Differentiated Service architecture, including
   per-hop behaviors, edge classification, and policing and shaping,
   without a need to specify the datapath mechanisms used by PEP
   implementations.  This provides an abstraction level hiding the
   unnecessary details and allowing the network administrator to write
   rules that express the network requirements in a more natural form.
   In this architecture, as no signaling between the end host and the
   network occurs before the sender starts sending information, the QoS
   mechanisms should be set up in advance.  This usually means that PEPs
   need to be provisioned with the set of policy rules in advance.

   Policing and Shaping actions are modeled as subclasses of the QoS
   admission action.  DSCP and CoS marking are modeled by using the
   SimplePolicyAction ([PCIMe]) class associated with the appropriate
   variables and values.  Bandwidth allocation and congestion control
   actions are modeled as subclasses of the QpQPolicyPHBAction, which is
   itself a subclass PolicyAction class ([PCIM])

3.3.1.  Admission Actions: Controlling Policers and Shapers

   Admission Actions (QoSPolicyAdmissionAction and its subclasses) are
   used to police and/or shape traffic.

Top      Up      ToC       Page 30 
   Each Admission Action is bound to a traffic profile
   (QoSPolicyTrfcProf) via the QoSPolicyTrfcProfInAdmissionAction
   association.  The traffic profile is used to meter traffic for
   purposes of policing or shaping.

   An Admission Action carries a scope property (qpAdmissionScope) that
   is used to determine whether the action controls individual traffic
   flows or aggregate traffic classes.  The concepts of "flow" and
   "traffic class" are explained in [DIFFSERV] using the terms
   'microflow' and 'traffic stream'.  Roughly speaking, a flow is a set
   of packets carrying an IP header that has the same values for source
   IP, destination IP, protocol and layer 4 source and destination
   ports.  A traffic class is a set of flows.  In QPIM, simple and
   compound conditions can identify flows and/or traffic classes by
   using Boolean terms over the values of IP header fields, including
   the value of the ToS byte.

   Thus, the interpretation of the scope property is as follows: If the
   value of the scope property is 0 (per-flow), each (micro) flow that
   can be positively matched with the rule's condition is metered and
   policed individually.  If the value of the scope property is 1 (per-
   class), all flows matched with the rule's condition are metered as a
   single aggregate and policed together.

   The following example illustrates the use of the scope property.
   Using two provisioned policing actions, the following policies can be
   enforced:

   -  Make sure that each HTTP flow will not exceed 64kb/s

   -  Make sure that the aggregate rate of all HTTP flows will not
      exceed 512Kb/s

   Both policies are modeled using the same class QoSPolicyPoliceAction
   (derived from QoSPolicyAdmissionAction).  The first policy has its
   scope property set to 'flow', while the second policy has its scope
   property set to 'class'.  The two policies are modeled using a rule
   with two police actions that, in a pseudo-formal definition, looks
   like the following:

      If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
                Action2=police, Traffic Profile2=512kb/s, Scope2=class

   The provisioned policing action QoSPolicyPoliceAction has three
   associations, QoSPolicyConformAction, QoSPolicyExceedAction and
   QoSPolicyViolateAction.

Top      Up      ToC       Page 31 
   To accomplish the desired result stated above, two possible modeling
   techniques may be used: The two actions can be part of a single
   policy rule using two PolicyActionInPolicyRule [PCIM] associations.
   In this case the ExecutionStrategy property of the PolicyRule class
   [PCIMe] SHOULD be set to "Do All" so that both individual flows and
   aggregate streams are policed.

   Alternatively, Action1 and Action2 could be aggregated in a
   CompundPolicyAction instance using the PolicyActionInPolicyAction
   aggregations [PCIMe].  In this case, in order for both individual
   flows and aggregate traffic classes to be policed, the
   ExecutionStrategy property of the CompoundPolicyAction class [PCIMe]
   SHOULD be set to "Do All".

   The policing action is associated with a three-level token bucket
   traffic profile carrying rate, burst and excess-burst parameters.
   Traffic measured by a meter can be classified as conforming traffic
   when the metered rate is below the rate defined by the traffic
   profile, as excess traffic when the metered traffic is above the
   normal burst and below the excess burst size, and violating traffic
   when rate is above the maximum excess burst.

   The [DIFF-MIB] defines a two-level meter, and provides a means to
   combine two-level meters into more complex meters.  In this document,
   a three-level traffic profile is defined.  This allows construction
   of both two-level meters as well as providing an easier definition
   for three-level meters needed for creating AF [AF] provisioning
   actions.

   A policing action that models three-level policing MUST associate
   three separate actions with a three-level traffic profile.  These
   actions are a conforming action, an exceeding action and a violating
   action.  A policing action that models two-level policing uses a
   two-level traffic profile and associates only conforming and
   exceeding actions.  A policing action with a three-level traffic
   profile that specifies an exceed action but does not specify a
   violate action implies that the action taken when the traffic is
   above the maximum excess burst is identical to the action taken when
   the traffic is above the normal burst.  A policer determines whether
   the profile is being met, while the actions to be performed are
   determined by the associations QoSPolicyXXXAction.

   Shapers are used to delay some or all of the packets in a traffic
   stream, in order to bring the stream into compliance with a traffic
   profile.  A shaper usually has a finite-sized buffer, and packets may
   be discarded if there is not sufficient buffer space to hold the
   delayed packets.  Shaping is controlled by the QoSPolicyShapeAction

Top      Up      ToC       Page 32 
   class.  The only required association is a traffic profile that
   specifies the rate and burst parameters that the outgoing flows
   should conform with.

3.3.2.  Controlling Markers

   Three types of marking control actions are modeled in QPIM:
   Differentiated Services Code Point (DSCP) assignment, IP Precedence
   (IPP) assignment and layer-2 Class of Service (CoS) assignment.
   These assignment actions themselves are modeled by using the
   SimplePolicyAction class associated with the appropriate variables
   and values.

   DSCP assignment sets ("marks" or "colors") the DS field of a packet
   header to a particular DS Code Point (DSCP), adding the marked packet
   to a particular DS behavior aggregate.

   When used in the basic form, "If <condition> then 'DCSP = ds1'", the
   assignment action assigns a DSCP value (ds1) to all packets that
   result in the condition being evaluated to true.

   When used in combination with a policing action, a different
   assignment action can be issued via each of the 'conform', 'exceed'
   and 'violate' action associations.  This way, one may select a PHB in
   a PHB group according to the state of a meter.

   The semantics of the DSCP assignment is encapsulated in the pairing
   of a DSCP variable and a DSCP value within a single
   SimplePolicyAction instance via the appropriate associations.

   IPP assignment sets the IPP field of a packet header to a particular
   IPP value (0 through 7).  The semantics of the IPP assignment is
   encapsulated in the pairing of a ToS variable (PolicyIPTosVariable)
   and a bit string value () (defined in [PCIMe]) within a single
   SimplePolicyAction instance via the appropriate associations.  The
   bit string value is used in its masked bit string format.  The mask
   indicates the relevant 3 bits of the IPP sub field within the ToS
   byte, while the bit string indicates the IPP value to be set.

   CoS assignments control the mapping of a per-hop behavior to a
   layer-2 Class of Service.  For example, mapping of a set of DSCP
   values into a 802.1p user priority value can be specified using a
   rule with a condition describing the set of DSCP values, and a CoS
   assignment action that specifies the required mapping to the given
   user priority value. The semantics of the CoS assignment is
   encapsulated in the pairing of a CoS variable and a CoS value
   (integer in the range of 0 through 7) within a single
   SimplePolicyAction instance via the appropriate associations.

Top      Up      ToC       Page 33 
3.3.3.  Controlling Edge Policies - Examples

   Assuming that the AF1 behavior aggregate is enforced within a DS
   domain, policy rules on the boundaries of the network should mark
   packets to one of the AF1x DSCPs, depending on the conformance of the
   traffic to a predetermined three-parameter traffic profile.  QPIM
   models such AF1 policing action as defined in Figure 4.

     +-----------------------+    +------------------------------+
     | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
     | scope = class         |    | rate = x, bc = y, be = z     |
     +-----------------------+    +------------------------------+
       *     @     #
       *     @     #
       *     @  +--------------------+   +--------------------------+
       *     @  | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
       *     @  +--------------------+   +--------------------------+
       *     @
       *  +--------------------+   +---------------------------+
       *  | SimplePolicyAction |---| PolicyIntegerValue - AF12 |
       *  +--------------------+   +---------------------------+
       *
     +--------------------+   +---------------------------+
     | SimplePolicyAction |---| PolicyIntegerValue - AF11 |
     +--------------------+   +---------------------------+

   Association and Aggregation Legend:

     ****  QoSPolicyConformAction
     @@@@  QoSPolicyExceedAction
     ####  QoSPolicyViolateAction
     ====  QoSTrfcProfInAdmissionAction
     ----  PolicyValueInSimplePolicyAction ([PCIMe])
     &&&&  PolicyVariableInSimplePolicyAction ([PCIMe], not shown)

                   Figure 4.    AF Policing and Marking

   The AF policing action is composed of a police action, a token bucket
   traffic profile and three instances of the SimplePolicyAction class.
   Each of the simple policy action instances models a different marking
   action.  Each SimplePolicyAction uses the aggregation
   PolicyVariableInSimplePolicyAction to specify that the associated
   PolicyDSCPVariable is set to the appropriate integer value.  This is
   done using the PolicyValueInSimplePolicyAction aggregation.  The
   three PolicyVariableInSimplePolicyAction aggregations which connect
   the appropriate SimplePolicyActions with the appropriate DSCP

Top      Up      ToC       Page 34 
   Variables, are not shown in this figure for simplicity.  AF11 is
   marked on detecting conforming traffic; AF12 is marked on detecting
   exceeding traffic, and AF13 on detecting violating traffic.

   The second example, shown in Figure 5, is the simplest policing
   action.  Traffic below a two-parameter traffic profile is unmodified,
   while traffic exceeding the traffic profile is discarded.

     +-----------------------+    +------------------------------+
     | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
     | scope = class         |    | rate = x, bc = y             |
     +-----------------------+    +------------------------------+
            @
            @
         +-------------------------+
         | QoSPolicyDiscardAction  |
         +-------------------------+

   Association and Aggregation Legend:
     ****  QoSPolicyConformAction (not used)
     @@@@  QoSPolicyExceedAction
     ####  QoSPolicyViolateAction (not used)
     ====  QoSTrfcProfInAdmissionAction

   Figure 5.    A Simple Policing Action

3.4.  Per-Hop Behavior Actions

   A Per-Hop Behavior (PHB) is a description of the externally
   observable forwarding behavior of a DS node applied to a particular
   DS behavior aggregate [DIFFSERV].  The approach taken here is that a
   PHB action specifies both observable forwarding behavior (e.g., loss,
   delay, jitter) as well as specifying the buffer and bandwidth
   resources that need to be allocated to each of the behavior
   aggregates in order to achieve this behavior.  That is, a rule with a
   set of PHB actions can specify that an EF packet must not be delayed
   more than 20 msec in each hop.  The same rule may also specify that
   EF packets need to be treated with preemptive forwarding (e.g., with
   priority queuing), and specify the maximum bandwidth for this class,
   as well as the maximum buffer resources.  PHB actions can therefore
   be used both to represent the final requirements from PHBs and to
   provide enough detail to be able to map the PHB actions into a set of
   configuration parameters to configure queues, schedulers, droppers
   and other mechanisms.

   The QoSPolicyPHBAction abstract class has two subclasses.  The
   QoSPolicyBandwidthAction class is used to control bandwidth, delay
   and forwarding behavior, while the QoSPolicyCongestionControlAction

Top      Up      ToC       Page 35 
   class is used to control queue size, thresholds and congestion
   algorithms.  The qpMaxPacketSize property of the QoSPolicyPHBAction
   class specifies the packet size in bytes, and is needed when
   translating the bandwidth and congestion control actions into actual
   implementation configurations. For example, an implementation
   measuring queue length in bytes will need to use this property to map
   the qpQueueSize property into the desired queue length in bytes.

3.4.1.  Controlling Bandwidth and Delay

   QoSPolicyBandwidthAction allows specifying the minimal bandwidth that
   should be reserved for a class of traffic.  The property
   qpMinBandwidth can be specified either in Kb/sec or as a percentage
   of the total available bandwidth.  The property qpBandwidthUnits is
   used to determine whether percentages or fixed values are used.

   The property qpForwardingPriority is used whenever preemptive
   forwarding is required.  A policy rule that defines the EF PHB should
   indicate a non-zero forwarding priority.  The qpForwardingPriority
   property holds an integer value to enable multiple levels of
   preemptive forwarding where higher values are used to specify higher
   priority.

   The property qpMaxBandwidth specifies the maximum bandwidth that
   should be allocated to a class of traffic.  This property may be
   specified in PHB actions with non-zero forwarding priority in order
   to guard against starvation of other PHBs.

   The properties qpMaxDelay and qpMaxJitter specify limits on the per-
   hop delay and jitter in milliseconds for any given packet within a
   traffic class.  Enforcement of the maximum delay and jitter may
   require use of preemptive forwarding as well as minimum and maximum
   bandwidth controls.  Enforcement of low max delay and jitter values
   may also require fragmentation and interleave mechanisms over low
   speed links.

   The Boolean property qpFairness indicates whether flows should have a
   fair chance to be forwarded without drop or delay.  A way to enforce
   a bandwidth action with qpFairness set to TRUE would be to build a
   queue per flow for the class of traffic specified in the rule's
   filter.  In this way, interactive flows like terminal access will not
   be queued behind a bursty flow (like FTP) and therefore have a
   reasonable response time.

3.4.2.  Congestion Control Actions

   The QoSPolicyCongestionControlAction class controls queue length,
   thresholds and congestion control algorithms.

Top      Up      ToC       Page 36 
   A PEP should be able to keep in its queues qpQueueSize packets
   matching the rule's condition.  In order to provide a link-speed
   independent queue size, the qpQueueSize property can also be measured
   in milliseconds.  The time interval specifies the time needed to
   transmit all packets within the queue if the link speed is dedicated
   entirely for transmission of packets within this queue.  The property
   qpQueueSizeUnit determines whether queue size is measured in number
   of packets or in milliseconds.  The property qpDropMethod selects
   either tail-drop, head-drop or random-drop algorithms.  The set of
   maximum and minimum threshold values can be specified as well, using
   qpDropMinThresholdValue and qpDropMaxThresholdValue properties,
   either in packets or in percentage of the total available queue size
   as specified by the qpDropThresholdUnits property.

3.4.3.  Using Hierarchical Policies: Examples for PHB Actions

   Hierarchical policy definition is a primary tool in the QoS Policy
   information model.  Rule nesting introduced in [PCIMe] allows
   specification of hierarchical policies controlling RSVP requests,
   hierarchical shaping, policing and marking actions, as well as
   hierarchical schedulers and definition of the differences in PHB
   groups.

   This example provides a set of rules that specify PHBs enforced
   within a Differentiated Service domain.  The network administrator
   chose to enforce the EF, AF11 and AF13 and Best Effort PHBs.  For
   simplicity, AF12 is not differentiated.  The set of rules takes the
   form:

      If (EF) then do EF actions
      If (AF1) then do AF1 actions
          If (AF11) then do AF11 actions
          If (AF12) then do AF12 actions
          If (AF13) then do AF13 actions
      If (default) then do Default actions.

   EF, AF1, AF11, AF12 and AF13 are conditions that filter traffic
   according to DSCP values.  The AF1 condition matches the entire AF1
   PHB group including the AF11, AF12 and AF13 DSCP values.  The default
   rule specifies the Best Effort rules.  The nesting of the AF1x rules
   within the AF1 rule specifies that there are further refinements on
   how AF1x traffic should be treated relative to the entire AF1 PHB
   group.  The set of rules reside in a PolicyGroup with a decision
   strategy property set to 'FirstMatching'.

   The class instances below specify the set of actions used to describe
   each of the PHBs.  Queue sizes are not specified, but can easily be
   added to the example.

Top      Up      ToC       Page 37 
   The actions used to describe the Best Effort PHB are simple.  No
   bandwidth is allocated to Best Effort traffic.  The first action
   specifies that Best Effort traffic class should have fairness.

   QoSPolicyBandwidthAction  BE-B:
     qpFairness: TRUE

   The second action specifies that the congestion algorithm for the
   Best Effort traffic class should be random, and specifies the
   thresholds in percentage of the default queue size.

   QoSPolicyCongestionControlAction  BE-C:
     qpDropMethod: random
     qpDropThresholdUnits %
     qpDropMinThreshold:  10%
     qpDropMaxThreshold:  70%

   EF requires preemptive forwarding.  The maximum bandwidth is also
   specified to make sure that the EF class does not starve the other
   classes.  EF PHB uses tail drop as the applications using EF are
   supposed to be UDP-based and therefore would not benefit from a
   random dropper.

   QoSPolicyBandwidthAction  EF-B:
     qpForwardingPriority: 1
     qpBandwidthUnits: %
     qpMaxBandwidth  50%
     qpFairness: FALSE

   QoSPolicyCongestionControlAction  EF-C:
     qpDropMethod: tail-drop
     qpDropThresholdUnits packet
     qpDropMaxThreshold:  3 packets

   The AF1 actions define the bandwidth allocations for the entire PHB
   group:

   QoSPolicyBandwidthAction  AF1-B:
     qpBandwidthUnits: %
     qpMinBandwidth: 30%

   The AF1i actions specifies the differentiating refinement for the
   AF1x PHBs within the AF1 PHB group.  The different threshold values
   provide the difference in discard probability of the AF1x PHBs within
   the AF1 PHB group.

Top      Up      ToC       Page 38 
   QoSPolicyCongestionControlAction  AF11-C:
     qpDropMethod: random
     qpDropThresholdUnits packet
     qpDropMinThreshold:  6 packets
     qpDropMaxThreshold:  16 packets

   QoSPolicyCongestionControlAction  AF12-C:
     qpDropMethod: random
     qpDropThresholdUnits packet
     qpDropMinThreshold:  4 packets
     qpDropMaxThreshold:  13 packets

   QoSPolicyCongestionControlAction  AF13-C:
     qpDropMethod: random
     qpDropThresholdUnits packet
     qpDropMinThreshold:  2 packets
     qpDropMaxThreshold:  10 packets

4.  Traffic Profiles

   Meters measure the temporal state of a flow or a set of flows against
   a traffic profile.  In this document, traffic profiles are modeled by
   the QoSPolicyTrfcProf class.  The association QoSPolicyTrfcProf
   InAdmissionAction binds the traffic profile to the admission action
   using it.  Two traffic profiles are derived from the abstract class
   QoSPolicyTrfcProf.  The first is a Token Bucket provisioning traffic
   profile carrying rate and burst parameters.  The second is an RSVP
   traffic profile, which enables flows to be compared with RSVP TSPEC
   and FLOWSPEC parameters.

4.1.  Provisioning Traffic Profiles

   Provisioned Admission Actions, including shaping and policing, are
   specified using a two- or three-parameter token bucket traffic
   profile.  The QoSPolicyTokenBucketTrfcProf class includes the
   following properties:

   1.  Rate measured in kbits/sec
   2.  Normal burst measured in bytes
   3.  Excess burst measured in bytes

   Rate determines the long-term average transmission rate.  Traffic
   that falls under this rate is conforming, as long as the normal burst
   is not exceeded at any time.  Traffic exceeding the normal burst but
   still below the excess burst is exceeding the traffic profile.
   Traffic beyond the excess burst is said to be violating the traffic
   profile.

Top      Up      ToC       Page 39 
   Excess burst size is measured in bytes in addition to the burst size.
   A zero excess burst size indicates that no excess burst is allowed.

4.2.  RSVP traffic profiles

   RSVP admission policy can condition the decision whether to accept or
   deny an RSVP request based on the traffic specification of the flow
   (TSPEC) or the amount of QoS resources requested (FLOWSPEC).  The
   admission decision can be based on matching individual RSVP requests
   against a traffic profile or by matching the aggregated sum of all
   FLOWSPECs (TSPECs) currently admitted, as determined by the
   qpAdmissionScope property in an associated
   QoSPolicyRSVPAdmissionAction.

   The QoSPolicyIntservTrfcProf class models both such traffic profiles.
   This class has the following properties:

      1.  Token Rate (r) measured in bits/sec
      2.  Peak Rate (p) measured in bits/sec
      3.  Bucket Size (b) measured in bytes
      4.  Min Policed unit (m) measured in bytes
      5.  Max packet size (M) measured in bytes
      6.  Resv Rate (R) measured in bits/sec
      7.  Slack term (s) measured in microseconds

   The first five parameters are the traffic specification parameters
   used in the Integrated Service architecture ([INTSERV]).  These
   parameters are used to define a sender TSPEC as well as a FLOWSPEC
   for the Controlled-Load service [CL].  For a definition and full
   explanation of their meanings, please refer to [RSVP-IS].

   Parameters 6 and 7 are the additional parameters used for
   specification of the Guaranteed Service FLOWSPEC [GS].

   A partial order is defined between TSPECs (and FLOWSPECs).  The TSPEC
   A is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB,
   mA<mB and MA>MB.  A TSPEC (FLOWSPEC) measured against a traffic
   profile uses the same ordering rule.  An RSVP message is accepted
   only if its TSPEC (FLOWSPEC) is either smaller or equal to the
   traffic profile.  Only parameters specified in the traffic profile
   are compared.

   The GS FLOWSPEC is compared against the rate R and the slack term s.
   The term R should not be larger than the traffic profile R parameter,
   while the FLOWSPEC slack term should not be smaller than that
   specified in the slack term.

Top      Up      ToC       Page 40 
   TSPECs as well as FLOWSPECs can be added.  The sum of two TSPECs is
   computed by summing the rate r, the peak rate p, the bucket size b,
   and by taking the minimum value of the minimum policed unit m and the
   maximum value of the maximum packet size M.  GS FLOWSPECs are summed
   by adding the Resv rate and minimizing the slack term s.  These rules
   are used to compute the temporal state of admitted RSVP states
   matching the traffic class defined by the rule condition.  This state
   is compared with the traffic profile to arrive at an admission
   decision when the scope of the QoSPolicyRSVPAdmissionAction is set to
   'class'.

5.  Pre-Defined QoS-Related Variables

   Pre-defined variables are necessary for ensuring interoperability
   among policy servers and policy management tools from different
   vendors.  The purpose of this section is to define frequently used
   variables in QoS policy domains.

   Notice that this section only adds to the variable classes as defined
   in [PCIMe] and reuses the mechanism defined there.

   The QoS policy information model specifies a set of pre-defined
   variable classes to support a set of fundamental QoS terms that are
   commonly used to form conditions and actions and are missing from the
   [PCIMe]. Examples of these include RSVP related variables.  All
   variable classes defined in this document extend the
   QoSPolicyRSVPVariable class (defined in this document), which itself
   extends the PolicyImplictVariable class, defined in [PCIMe].
   Subclasses specify the data type and semantics of the policy
   variables.

   This document defines the following RSVP variable classes; for
   details, see their class definitions:

   RSVP related Variables:

   1.   QoSPolicyRSVPSourceIPv4Variable - The source IPv4 address of the
        RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE
        and RSVP RESV FILTER_SPEC [RSVP] objects.

   2.   QoSPolicyRSVPDestinationIPv4Variable - The destination port of
        the RSVP signaled flow, as defined in the RSVP PATH and RESV
        SESSION [RSVP] objects (for IPv4 traffic).

   3.   QoSPolicyRSVPSourceIPv6Variable - The source IPv6 address of the
        RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE
        and RSVP RESV FILTER_SPEC [RSVP] objects.

Top      Up      ToC       Page 41 
   4.   QoSPolicyRSVPDestinationIPv6Variable - The destination port of
        the RSVP signaled flow, as defined in the RSVP PATH and RESV
        SESSION [RSVP] objects (for IPv6 traffic).

   5.   QoSPolicyRSVPSourcePortVariable - The source port of the RSVP
        signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
        RSVP RESV FILTER_SPEC [RSVP] objects.

   6.   QoSPolicyRSVPDestinationPortVariable - The destination port of
        the RSVP signaled flow, as defined in the RSVP PATH and RESV
        SESSION [RSVP] objects.

   7.   QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP
        signaled flow, as defined in the RSVP PATH and RESV SESSION
        [RSVP] objects.

   8.   QoSPolicyRSVPIPVersionVariable - The version of the IP addresses
        carrying the RSVP signaled flow, as defined in the RSVP PATH and
        RESV SESSION [RSVP] objects.

   9.   QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the
        RSVP DCLASS [DCLASS] object.

   10.  QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF)
        as defined in the RSVP RESV message [RSVP].

   11.  QoSPolicyRSVPIntServVariable - The type of Integrated Service
        (CL, GS, NULL) requested in the RSVP Reservation message, as
        defined in the FLOWSPEC RSVP Object [RSVP].

   12.  QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either
        PATH, PATHTEAR, RESV, RESVTEAR, RESVERR, CONF or PATHERR [RSVP].

   13.  QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation
        priority as defined in [RFC3181].

   14.  QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption
        reservation defending priority as defined in [RFC3181].

   15.  QoSPolicyRSVPUserVariable - The ID of the user that initiated
        the flow as defined in the User Locator string in the Identity
        Policy Object [RFC3182].

   16.  QoSPolicyRSVPApplicationVariable - The ID of the application
        that generated the flow as defined in the application locator
        string in the Application policy object [RFC2872].

Top      Up      ToC       Page 42 
   17.  QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type
        used in the Identity Policy Object [RFC3182].

   Each class restricts the possible value types associated with a
   specific variable.  For example, the QoSPolicyRSVPSourcePortVariable
   class is used to define the source port of the RSVP signaled flow.
   The value associated with this variable is of type
   PolicyIntegerValue.

6.  QoS Related Values

   Values are used in the information model as building blocks for the
   policy conditions and policy actions, as described in [PCIM] and
   [PCIMe].  This section defines a set of auxiliary values that are
   used for QoS policies as well as other policy domains.

   All value classes extend the PolicyValue class [PCIMe].  The
   subclasses specify specific data/value types that are not defined in
   [PCIMe].

   This document defines the following two subclasses of the PolicyValue
   class:

   QoSPolicyDNValue          This class is used to represent a single or
                             set of Distinguished Name [DNDEF] values,
                             including wildcards.  A Distinguished Name
                             is a name that can be used as a key to
                             retrieve an object from a directory
                             service.  This value can be used in
                             comparison to reference values carried in
                             RSVP policy objects, as specified in
                             [RFC3182].  This class is defined in
                             Section 8.31.

   QoSPolicyAttributeValue   A condition term uses the form "Variable
                             matches Value", and an action term uses the
                             form "set Variable to Value" ([PCIMe]).
                             This class is used to represent a single or
                             set of property values for the "Value" term
                             in either a condition or an action. This
                             value can be used in conjunction with
                             reference values carried in RSVP objects,
                             as specified in [RFC3182].  This class is
                             defined in section 8.12.

   The property name is used to specify which of the properties in the
   QoSPolicyAttributeValue class instance is being used in the condition
   or action term.  The value of this property or properties will then

Top      Up      ToC       Page 43 
   be retrieved.  In the case of a condition, a match (which is
   dependent on the property name) will be used to see if the condition
   is satisfied or not.  In the case of an action, the semantics are
   instead "set the variable to this value".

   For example, suppose the "user" objects in the organization include
   several properties, among them:

      - First Name
      - Last Name
      - Login Name
      - Department
      - Title

   A simple condition could be constructed to identify flows by their
   RSVP user carried policy object.  The simple condition: Last Name =
   "Smith" to identify a user named Bill would be constructed in the
   following way:

      A SimplePolicyCondition [PCIMe] would aggregate a
      QoSPolicyRSVPUserVariable [QPIM] object, via the
      PolicyVariableInSimplePolicyCondition [PCIMe] aggregation.

   The implicit value associated with this condition is created in the
   following way:

      A QoSPolicyAttributeValue object would be aggregated to the simple
      condition object via a PolicyValueInSimplePolicyCondition [PCIMe].
      The QoSPolicyAttributeValue attribute qpAttributeName would be set
      to "last name" and the qpAttributeValueList would be set to
      "Smith".

   Another example is a condition that has to do with the user's
   organizational department.  It can be constructed in the exact same
   way, by changing the QoSPolicyAttributeValue attribute
   qpAttributeName to "Department" and the qpAttributeValueList would be
   set to the particular value that is to be matched (e.g.,
   "engineering" or "customer support").  The logical condition would
   than be evaluated to true if the user belong to either the
   engineering department or the customer support.

   Notice that many multiple-attribute objects require the use of the
   QoSPolicyAttributeValue class to specify exactly which of its
   attributes should be used in the condition match operation.

Top      Up      ToC       Page 44 
7.  Class Definitions: Association Hierarchy

   The following sections define associations that are specified by
   QPIM.

7.1.  The Association "QoSPolicyTrfcProfInAdmissionAction"

   This association links a QoSPolicyTrfcProf object (defined in section
   8.9), modeling a specific traffic profile, to a
   QoSPolicyAdmissionAction object (defined in section 8.2).  The class
   definition for this association is as follows:

   NAME              QoSPolicyTrfcProfInAdmissionAction
   DESCRIPTION       A class representing the association between a
                     QoS admission action and its traffic profile.
   DERIVED FROM      Dependency (See [PCIM])
   ABSTRACT          FALSE
   PROPERTIES        Antecedent[ref QoSPolicyAdmissionAction [0..n]]
                     Dependent[ref QoSPolicyTrfcProf [1..1]]

7.1.1.  The Reference "Antecedent"

   This property is inherited from the Dependency association, defined
   in [PCIM].  Its type is overridden to become an object reference to a
   QoSPolicyAdmissionAction object.  This represents the "independent"
   part of the association.  The [0..n] cardinality indicates that any
   number of QoSPolicyAdmissionAction object(s) may use a given
   QoSPolicyTrfcProf.

7.1.2.  The Reference "Dependent"

   This property is inherited from the Dependency association, and is
   overridden to become an object reference to a QoSPolicyTrfcProf
   object.  This represents a specific traffic profile that is used by
   any number of QoSPolicyAdmissionAction objects.  The [1..1]
   cardinality means that exactly one object of the QoSPolicyTrfcProf
   can be used by a given QoSPolicyAddmissionAction.

7.2.  The Association "PolicyConformAction"

   This association links a policing action with an object defining an
   action to be applied to conforming traffic relative to the associated
   traffic profile.  The class definition for this association is as
   follows:

Top      Up      ToC       Page 45 
   NAME              PolicyConformAction
   DESCRIPTION       A class representing the association between a
                     policing action and the action that should be
                     applied to traffic conforming to an associated
                     traffic profile.
   DERIVED FROM      Dependency (see [PCIM])
   ABSTRACT          FALSE
   PROPERTIES        Antecedent[ref QoSPolicyPoliceAction[0..n]]
                     Dependent[ref PolicyAction [1..1]]

7.2.1.  The Reference "Antecedent"

   This property is inherited from the Dependency association.  Its type
   is overridden to become an object reference to a
   QoSPolicyPoliceAction object.  This represents the "independent" part
   of the association.  The [0..n] cardinality indicates that any number
   of QoSPolicyPoliceAction objects may be given the same action to be
   executed as the conforming action.

7.2.2.  The Reference "Dependent"

   This property is inherited from the Dependency association, and is
   overridden to become an object reference to a PolicyAction object.
   This represents a specific policy action that is used by a given
   QoSPolicyPoliceAction.  The [1..1] cardinality means that exactly one
   policy action  can be used as the "conform" action for a
   QoSPolicyPoliceAction.  To execute more than one conforming action,
   use the PolicyCompoundAction class to model the conforming action.

7.3.  The Association "QoSPolicyExceedAction"

   This association links a policing action with an object defining an
   action to be applied to traffic exceeding the associated traffic
   profile.  The class definition for this association is as follows:

   NAME              QoSPolicyExceedAction
   DESCRIPTION       A class representing the association between a
                     policing action and the action that should be
                     applied to traffic exceeding an associated traffic
                     profile.
   DERIVED FROM      Dependency (see [PCIM])
   ABSTRACT          FALSE
   PROPERTIES        Antecedent[ref QoSPolicePoliceAction[0..n]]
                     Dependent[ref PolicyAction [1..1]]

Top      Up      ToC       Page 46 
7.3.1.  The Reference "Antecedent"

   This property is inherited from the Dependency association.  Its type
   is overridden to become an object reference to a
   QoSPolicyPoliceAction object.  This represents the "independent" part
   of the association.  The [0..n] cardinality indicates that any number
   of QoSPolicyPoliceAction objects may be given the same action to be
   executed as the exceeding action.

7.3.2.  The Reference "Dependent"

   This property is inherited from the Dependency association, and is
   overridden to become an object reference to a PolicyAction object.
   This represents a specific policy action that is used by a given
   QoSPolicyPoliceAction.  The [1..1] cardinality means that a exactly
   one policy action can be used as the "exceed" action by a
   QoSPolicyPoliceAction.  To execute more than one conforming action,
   use the PolicyCompoundAction class to model the exceeding action.

7.4.  The Association "PolicyViolateAction"

   This association links a policing action with an object defining an
   action to be applied to traffic violating the associated traffic
   profile.  The class definition for this association is as follows:

   NAME              PolicyViolateAction
   DESCRIPTION       A class representing the association between
                     a policing action and the action that should be
                     applied to traffic violating an associated traffic
                     profile.
   DERIVED FROM      Dependency (see [PCIM])
   ABSTRACT          FALSE
   PROPERTIES        Antecedent[ref QoSPolicePoliceAction[0..n]]
                     Dependent[ref PolicyAction [1..1]]

7.4.1.  The Reference "Antecedent"

   This property is inherited from the Dependency association.  Its type
   is overridden to become an object reference to a
   QoSPolicyPoliceAction object.  This represents the "independent" part
   of the association.  The [0..n] cardinality indicates that any number
   of QoSPolicyPoliceAction objects may be given the same action to be
   executed as the violating action.

Top      Up      ToC       Page 47 
7.4.2.  The Reference "Dependent"

   This property is inherited from the Dependency association, and is
   overridden to become an object reference to a PolicyAction object.
   This represents a specific policy action that is used by a given
   QoSPolicyPoliceAction.  The [1..1] cardinality means that exactly one
   policy action can be used as the "violate" action by a
   QoSPolicyPoliceAction.  To execute more than one violating action,
   use the PolicyCompoundAction class to model the conforming action.

7.5.  The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction"

   A simple RSVP policy action is represented as a pair {variable,
   value}. This aggregation provides the linkage between a
   QoSPolicyRSVPSimpleAction instance and a single
   QoSPolicyRSVPVariable.  The aggregation
   PolicyValueInSimplePolicyAction links the QoSPolicyRSVPSimpleAction
   to a single PolicyValue.

   The class definition for this aggregation is as follows:

   NAME             QoSPolicyRSVPVariableInRSVPSimplePolicyAction
   DERIVED FROM     PolicyVariableInSimplePolicyAction
   ABSTRACT         FALSE
   PROPERTIES       GroupComponent[ref QoSPolicyRSVPSimpleAction
                      [0..n]]
                    PartComponent[ref QoSPolicyRSVPVariable [1..1] ]

7.5.1.  The Reference "GroupComponent"

   The reference property "GroupComponent" is inherited from
   PolicyComponent, and overridden to become an object reference to a
   QoSPolicyRSVPSimpleAction that contains exactly one
   QoSPolicyRSVPVariable.  Note that for any single instance of the
   aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this
   property is single-valued.  The [0..n] cardinality indicates that
   there may be 0, 1, or more QoSPolicyRSVPSimpleAction objects that
   contain any given RSVP variable object.

7.5.2.  The Reference "PartComponent"

   The reference property "PartComponent" is inherited from
   PolicyComponent, and overridden to become an object reference to a
   QoSPolicyRSVPVariable that is defined within the scope of a
   QoSPolicyRSVPSimpleAction.  Note that for any single instance of the
   association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this
   property (like all reference properties) is single-valued.  The

Top      Up      ToC       Page 48 
   [1..1] cardinality indicates that a
   QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one
   RSVP variable defined within its scope in order to be meaningful.



(page 48 continued on part 3)

Next RFC Part