[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Internet Draft                                 Hugh Mahon
Expiration: May 2001                            Hewlett-Packard
File: draft-ietf-policy-req-02.txt             Yoram Bernet
                                                Microsoft
                                               Shai Herzog
                                                IP Highway
                                               John Schnizlein
                                                Cisco Systems
                                               November 9, 2000






           Requirements for a Policy Management System









Status of this Memo

This  document  is  an  Internet-Draft and is in full conformance
with all provisions of Section 10  of  RFC2026.   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 made obsolete 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.''

The  list  of  current  Internet-Drafts  can   be   accessed   at
http://www.ietf.org/ietf/1id-abstracts.txt

The  list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2000).  All Rights  Reserved.

Abstract

This  document describes why policy based management is interest-
ing to people managing IT environments and what is needed to make










Internet Draft         Policy Requirements          November 2000


policy  management  address  those  interests.   Work  to date is
described, as well as usage cases demonstrating how  policy-based
management would actually work.

The  goal  for  this document is to provide a set of requirements
for further development of standards for policy  management  sys-
tems.   There has already been work in the area of policy manage-
ment and the work to date is  described  as  well  as  additional
areas to be defined.

This  document  is  the  result of discussions, e-mail, and other
communications within the  Policy  Framework  Working  Group  and
among individuals.

Table of Contents

   1. Introduction .........................................    2
   2. QoS Policy usage .....................................    5
   2.1 Voice ...............................................    5
   2.2 Protected classes of traffic ........................    6
   2.3 Guaranteed Transfer Time ............................    7
   2.4 Policy and Services .................................    7
   3. Usage Cases ..........................................    8
   3.1 Simple Usage Case ...................................    8
   3.1.1 Simple Usage Case in an ISP Environment ...........    8
   3.1.2 Simple Usage Case in an Enterprise Environment ....    9
   3.1.3 Simple Usage Case - Steps to Implement ............   10
   3.1.3 Simple Usage Case Requirements ....................   11
   3.1 Complex Usage Case ..................................   12
   3.1 Complex Usage Case - Requirements ...................   13
   4. Security Considerations ..............................   13
   5. Summary ..............................................   14
   6. Intellectual Property ................................   15
   7. References ...........................................   16
   8 Acknowledgements ......................................   17
   9. Author Information ...................................   17
   10. Full Copyright Statement ............................   18








1.  Introduction

   Policy  based  management  has  generated a lot of buzz in the
   industry lately.  Unfortunately hype  can  create  unrealistic
   expectations.   While  Policy Based Management won't solve all
   problems, or make IT administration a trivial task, there is a
   real  need  for  Policy  Based  Management.  So why are people
   interested in Policy Based Management?


Mahon, et al             Expires May 2001                [Page 2]


Internet Draft         Policy Requirements          November 2000


   Policy is essentially a  matter  of  allocating  resources  in
   terms  of  business  decisions.  It is the translation between
   business terms and the configuration details necessary to pro-
   duce those resource allocations that distinguishes policy man-
   agement from configuration management.

   Internet technology based networks are  being  used  for  more
   functions  and  by more businesses.  Their ability to do busi-
   ness is affected by the health and  abilities  of  their  net-
   works.

   As  networks grow the amount of things that need to be managed
   grows.  Not only are there more devices  to  be  managed,  but
   also  the  number of kinds of things (e.g., capabilities, ser-
   vices, types of interfaces, etc.) is growing.  As  more  kinds
   of  things  are  introduced, so are more management interfaces
   the IT administrators must learn and use to manage  the  envi-
   ronment.   In  addition,  many  of those management tools work
   with individual devices, so that an administrator must  dupli-
   cate  the  actions  used  to manage (configure) one device for
   each other device, even if they are the same  type  of  device
   from  the  same  vendor.   The  problem  is exacerbated if the
   devices are from different vendors, since  they  must  perform
   different  tasks  to  manage  similar  capabilities.  The same
   problem exists not just for networking,  but  for  just  about
   anything an IT administrator may need to manage.

   In  response  to this situation, customers (IT administrators)
   have for many years been asking vendors for tools which better
   address  their  needs in managing such large and dynamic envi-
   ronments.  Their list of desired features includes:


       - centralized management
       - abstracted (or simplified) management data
       - commonality across devices
       - automation of management tasks
       - fewer interfaces
       - consistency across interfaces



   Centralized management requires the ability to perform manage-
   ment  tasks  via  the  network.   Scalability factors into the
   requirements since a centralized system is not practical if it
   doesn't scale well to fit the management needs in the environ-
   ment.

   Abstracted (or simplified) management data fits with the fewer
   interfaces objective by abstracting the functions and decision
   criteria across multiple devices, lending itself to  the  next
   desired feature, commonality across devices.



Mahon, et al             Expires May 2001                [Page 3]


Internet Draft         Policy Requirements          November 2000


   There are two aspects to commonality: the ability to learn how
   to do something once and apply that across multiple things  of
   the  same kind, and the ability to use the same data, not just
   similar data, across multiple things.  By using the same  con-
   figuration  across  multiple  devices,  the  administrator can
   achieve consistent behavior in  the  managed  environment  and
   reduce,  or  better yet eliminate, duplication of efforts.  It
   is this desire to use the same data  across  multiple  devices
   that is behind the desire to have fewer interfaces.

   Automation  of  management  tasks is the feature that causes a
   change from most  implementations  of  management  tools  with
   existing  technologies (e.g., SNMP).  One aspect of automation
   is the desire of customers to be  able  to  re-use  management
   data  where that re-use makes sense, and for the tools to sup-
   port such re-use.  In  other  words,  wherever  possible,  the
   tools  support  management  information  re-use,  and  do  not
   require the administrator to duplicate information already  in
   the  management system, and can automatically get the informa-
   tion where it needs to go and when it is  needed  rather  than
   require  additional  intervention  by the human administrator.
   Automation is also key in allowing the network to operate with
   a minimum of human intervention (once the human administrators
   have specified, through management data, how  the  environment
   is to behave under given circumstances).

   The  key to providing a solution for these requirements is the
   data used to manage the environment;  what  that  data  repre-
   sents,  how  it  gets  from the administrator to what the data
   affects, and the functionality that supports reuse and automa-
   tion.

   That  data  has been called 'policy'.  Policy Based Management
   is the term used to describe the technologies that address the
   customer requirements described above.

   In  support  of  the  above features, the efforts for defining
   Policy Based Management have focused on the  data  representa-
   tion and properties of a repository for that information.

   The use of a repository is important to support reusability of
   data across managed things, as well as allowing an administra-
   tor  to  edit  existing  management  data  (both  are forms of
   reuse).  In addition to being stored in a repository, the data
   must  get to where it will be used (this supports the require-
   ments of centralized management and automation).  (Information
   distributed from a centralized repository also aids in consis-
   tency of information throughout the managed environment.)

   With common policy information the administrator can  use  the
   same information to configure devices which are supposed to do
   the same thing (addressing centralized management, commonality
   across devices, and reducing the number of interfaces required


Mahon, et al             Expires May 2001                [Page 4]


Internet Draft         Policy Requirements          November 2000


   for multiple devices from  different  vendors).   This  policy
   information can also be abstracted to a higher level, since it
   will need to be device independent.

   Common information does not require  a  common  format  (i.e.,
   schema).  In other words, it is possible to have common infor-
   mation for QoS management, and common information for security
   uses,  but have completely different formats for the different
   uses of data.  This would cause a duplication  of  information
   that  could  be  common (e.g., user information use for access
   control), and so would be a bad thing because it would lead to
   greater   differences   between  disciplines  than  necessary.
   Therefore, a common format is another requirement  to  support
   the desire for automation and fewer interfaces.

   To  summarize  the  above: centralized management leads to the
   need for a repository; scalability requires a means to  commu-
   nicate  the data beyond the repository; abstraction requires a
   common information model; automation requires the  abstraction
   and components to perform actions based on management data and
   real-time inputs.

   The rest of this document describes what is necessary to  make
   a policy-based management system work.


2.  QoS Policy usage

   The focus of this draft is on the requirements of policy, with
   an emphasis on network Quality of Service.

   Policy control of data (packet) networks  coincides  with  the
   convergence of voice (and video) calling and business-critical
   communications with interconnected local area networks (LANs).
   A  strong  motivation  for  users is to protect these forms of
   communication that are less tolerant of potential  delays  and
   congestion than applications usually using in packet networks.
   Because the application of policy implies  unequal  treatment,
   adequate authorization for allocations is essential.


   2.1.  Voice

      Voice  over  IP  requires  special  network  allocations to
      ensure reasonable  quality.  Whether  using  int-serv  [RFC
      1633] or diff-serv [RFC 2475], priority queuing and traffic
      shaping are required for real-time traffic.  Policy  speci-
      fies how much of the network is allocated to this real-time
      traffic and which calls are authorized to use this  alloca-
      tion.   This  policy, in conjunction with traffic engineer-
      ing, determines the configuration of queue  schedulers  and
      traffic policers across a variety of network devices.



Mahon, et al             Expires May 2001                [Page 5]


Internet Draft         Policy Requirements          November 2000


      Because  calling  parties might connect at different places
      in the network (unlike plain-old telephone  service  (POTS)
      but  not  roam  like  cellular  mobility), binding personal
      authorization to which devices to be configured depends  on
      the process resolving personal locations within the network
      topology.  This binding between user identity and  location
      is outside the policy system, but might depend on policy to
      determine  what  locations  are  authorized.  Configuration
      depends  on  the interaction between calling authorization,
      location, and the details of network capacity at that loca-
      tion.   Since this interaction is more dynamic than policy,
      separate processes in  the  configuration  environment  are
      suggested.

      If the capacity for real-time calls is less than the poten-
      tial level authorized, some scheduling  process,  at  least
      call  admission  control (CAC), is also required. Since CAC
      is likely to be even more dynamic than station mobility,  a
      process  separate  from  the configuration process above is
      suggested.  RSVP [RFC 2205]  anticipates  that  policy,  in
      addition  to local network capacity, will determine CAC for
      int-serv.   Capacity  allocation  for  CAC  must  be  local
      because  availability  or congestion is only meaningful for
      individual links (or queues).

      To summarize: Configuration  for  real-time  (voice)  calls
      requires  the  interaction  of policy, traffic engineering,
      user  identity,  and  location.  Call   admission   control
      requires  all  of  this plus accounting for local resources
      along the path of the call.


   2.2.  Protected classes of traffic

      Fear that traffic for critical applications might  be  dis-
      placed  by  less important traffic when both share the same
      network motivates interest in policy networking. As a  mat-
      ter of implementation, the only way to protect one class of
      traffic from the load applied  from  another  class  is  to
      queue  them separately. Each class must then be allocated a
      share of the output link capacity. This also has the advan-
      tage that each class is protected from the others, which is
      impossible with priority or precedence approaches;  even  a
      class allocated a small share will not be affected by loads
      in other classes.  Priority  appears  to  reflect  business
      interests,  "But  priority  is an implementation mechanism,
      not a service model." [RFC 1633] Resolving ordering effects
      among  multiple  levels  of  priority  also  complicates an
      already difficult problem of resolving potential  conflicts
      within a set of policy constraints.

      Because  queues can be scarce resources in network devices,
      policy should control their allocation  and  which  traffic


Mahon, et al             Expires May 2001                [Page 6]


Internet Draft         Policy Requirements          November 2000


      sources  use  which queues.  Traffic engineering influences
      the allocation of traffic classes to queues because  queues
      are necessary only where bottlenecks cause congestion. This
      interaction  between  traffic  engineering  and  policy  is
      slightly  different  than  their  interaction for real-time
      traffic; policy creation should be constrained by the abil-
      ity  of  the  network to protect different traffic classes.
      Where call admission is analogous to program-language  run-
      time,  and  configuration is analogous to compile-time, the
      availability of class separation is analogous  to  semanti-
      cally-constrained editing of policy entry.

      In  many  cases, traffic rates from server to client are so
      much larger than from client to server that  classification
      of  protected  traffic  can  be made on the basis of server
      addresses, which are authenticated and authorized over long
      time  periods.  Sometimes,  it  may be necessary to include
      client authorization beyond what the application  performs.
      Client  authorization  could  interact with policy to imply
      configuration changes on a time-scale (comparable  to  user
      mobility  above),  or  individual  sessions on a multi-user
      (host) client (comparable to admission control above).


   2.3.  Guaranteed Transfer Time

      The business-level specification of  quality  is  often  in
      terms  much  larger  than  suitable for configuration, even
      through consistency resolution and translation from policy.
      An  application  that demands transfer of a known (approxi-
      mately) volume of data within a specified time  is  attrac-
      tive  for  archival  storage  and content distribution. The
      value of this application justifies scheduling  classes  of
      traffic with capacity configurations across the path of the
      transfer. This application requires (time of day)  schedul-
      ing  along  with  the  same  requirements  as for protected
      classes.

   2.4.  Policy and Services

      Policy management is often discussed in terms of  the  ser-
      vices  that  are supported via policy.  There are different
      kinds and levels of information required  when  managing  a
      networked  environment.  Service management is a relatively
      high level view  of  a  system.   Many  drafts  discuss  an
      "Olympic"  service,  in  which there are multiple levels of
      service, for example: Bronze, Silver, and  Gold.   In  such
      discussions  Gold is better than Silver, and Silver is bet-
      ter than Bronze.  When actually describing the  meaning  of
      the service, though, things become more complex.

      Policy  is  used  to  implement services in an environment.
      But policy information may not be the  only  representation


Mahon, et al             Expires May 2001                [Page 7]


Internet Draft         Policy Requirements          November 2000


      of  the service characteristics.  Services may be described
      in a manner that is higher-level than policy  itself;  that
      is,  services  may  be  described  in a form that describes
      characteristics  from  which  policy  information  is  then
      derived.    Such  a  higher  level  representation  may  be
      required to perform some functions in  a  managed  environ-
      ment.   For example, different policies which describe dif-
      ferent behaviors may be deployed to two entities  traversed
      by a customer's traffic.  It may be impossible to tell if a
      conflict exists simply by looking  at  the  policies  them-
      selves,  but  it may be possible to determine if a conflict
      exists with the service(s) to which the customer  has  sub-
      scribed.

      Service  descriptions  are  beyond the scope of this draft,
      but the distinction between services  and  policies  is  an
      important one when discussing what information is used in a
      management system, and what the administrator needs to know
      in order to create and deploy policies.


3.  Usage Cases

   Building  on the discussion in section 2, two usage cases will
   be described.


   3.1.  Simple Usage Case

      A customer, Joe, has subscribed for Gold service.  For this
      example  Gold  service will simply mean that Joe has higher
      priority than customers who subscribed for Silver or Bronze
      service  levels.   What needs to happen in order for Joe to
      receive the service to which he is subscribed?

      This example will be shown in two contexts: an ISP environ-
      ment and an enterprise environment.

      3.1.1.  Simple Usage Case in an ISP Environment

         The ISP management personnel must configure the environ-
         ment to support the Gold, Silver, and  Bronze  services.
         Within  the core of the network this can be accomplished
         by putting in place policies which cause the devices  to
         examine  the  DiffServ mark on the packet and then treat
         the traffic appropriately.  These policies do not change
         frequently because they are not associated with specific
         customers.  The more difficult part is to have the traf-
         fic appropriately marked.

         Since  Joe  is  signed  up  for  the service, the RADIUS
         server could be configured to have the POP at which  Joe
         usually  logs in assign Joe a known address when he logs


Mahon, et al             Expires May 2001                [Page 8]


Internet Draft         Policy Requirements          November 2000


         in.  With a  known  IP  address  the  administrator  can
         author  a  policy  which references Joe's IP address and
         marks traffic coming from that address as  Gold  service
         traffic.   This  policy  would then be deployed to Joe's
         POP.

         In order for  any  traffic  going  to  Joe's  system  to
         receive Gold treatment, that traffic must also be marked
         appropriately.  This means that policy must be  deployed
         to the edge devices so that they will mark traffic going
         to Joe's system to receive Gold service.  This is accom-
         plished  by  deploying  policies to edge devices.  These
         edge policies cause packets going to Joe's address to be
         marked  so  that  they  receive  Gold service treatment.
         This would also be done on internal routers or  switches
         to  which the ISP's servers (e.g., mail or news servers)
         are attached so that traffic internal to the ISP is also
         appropriately marked.

         Customers  like  Joe  want to be able to see if they are
         getting the service they have paid the service  provider
         for.   Service  providers should provide the tools which
         allow their customers to  see  information  relevant  to
         each  customer's  service.   Such  tools  are beyond the
         scope of this document.

      3.1.2.  Simple Usage Case in an Enterprise Environment

         As in the ISP example above, the corporate  IT  adminis-
         trators  will  need  to configure the core to handle the
         different services offered to  users  of  the  corporate
         network.  The difference is in how the user's traffic is
         marked to receive the desired service.

         One way for the traffic to be marked is for Joe to  have
         a  fixed IP address.  The policies would then be written
         to recognize Joe's address and treat the traffic  coming
         to and from that address appropriately.

         A  second  way for the traffic to be marked correctly is
         that when Joe's computer is connected to the network the
         DHCP  system  recognizes  that  it is Joe's computer, or
         that it is a computer to which Gold  service  is  to  be
         provided, and thus notifies another management component
         of the event.  This causes a policy to be  deployed  (or
         more  likely  causes  an existing policy to be modified)
         that will mark the traffic to and from Joe's computer as
         receiving Gold service.

         A third way for the traffic to be marked correctly is to
         have a sequence of events be started when Joe logs  into
         the system.  This would notify a central authority which
         would cause the traffic to be  marked  to  receive  Gold


Mahon, et al             Expires May 2001                [Page 9]


Internet Draft         Policy Requirements          November 2000


         service.

         Yet a fourth way would be to have policy deployed to the
         end systems themselves.  When Joe  uses  an  application
         that generates traffic the networking stack on that sys-
         tem would mark Joe's traffic appropriately.

         For all of these approaches, the network  devices  would
         also need to be configured to appropriately mark traffic
         going to Joe's system so that it gets the desired treat-
         ment.   As  can  be  seen,  an  environment with totally
         dynamic address assignment would require dynamic config-
         uration  changes  in  order  to  support QoS.  Signaling
         addresses some of these  issues,  but  introduces  other
         issues as well.

         Each  of  these  approaches has advantages and disadvan-
         tages.  Approaches two and three are  the  most  complex
         and would require more elaborate management systems than
         approaches one and four.  The  fourth  approach  is  the
         only  method described which addresses policy associated
         with an individual user that would work  with  a  multi-
         user  system.   However,  the problem of solving marking
         traffic going to Joe on system X, and treating the traf-
         fic  going  to  other  users  on system X, is not solved
         here.

         As in the ISP example above, knowledgeable users of  the
         network  in the enterprise like to be able to review the
         services they are receiving.

      3.1.3.  Simple Usage Case - Steps to Implement

         In order to implement the policy  discussed  above,  the
         administrator  must  enter  new policy (or edit old pol-
         icy).  Some interface, whose specification is beyond the
         scope of this document, is used to accomplish this task.
         This interface then delivers the policy information to a
         repository.   At  this  step other functions may be per-
         formed,  such  as  validation,  verification,   conflict
         detection,  etc.   The Policy Consumers (see [POLFRAME])
         associated with  the  interfaces  to  which  the  policy
         applies will be notified that the policy has changed (or
         is newly available).  The Policy Consumers will  receive
         the  policy  information  and  transform  it into a form
         suitable for the device.  During this  step  the  Policy
         Consumer will use information about the Policy Target to
         perform the information transformation.  Note that noth-
         ing is being stated about the architecture of the Policy
         Consumer or Policy Target.  They may be  integral,  dis-
         tributed,  or in whatever form will accomplish receiving
         policy  information  and  implementing   the   behaviors
         described by the policy information.


Mahon, et al             Expires May 2001               [Page 10]


Internet Draft         Policy Requirements          November 2000


      3.1.4.  Simple Usage Case Requirements

         Now let's look at what happened in the above example and
         see what is necessary to support it.

         At least two policies would be  written  in  this  case.
         One is to configure the core devices.  In this example a
         single policy could be written which specifies  priority
         treatment  based on DSCP values.  The other policy would
         be to configure  the  RADIUS  server  to  assign  an  IP
         address for Joe.  A third policy may be required so that
         the devices at the POP recognize Joe's  IP  address  and
         give  his  traffic the appropriate DSCP mark.  The third
         policy (which could be an action on the  RADIUS  policy)
         would  require  dynamic  reconfiguration in real-time in
         order to provide appropriate service to the  user  in  a
         timely manner.

         In  order  to perform these tasks the administrator will
         need to enter or edit policy and have  it  stored  in  a
         central  repository.   The  policy would then be sent to
         the appropriate devices which must carry out the  opera-
         tions  specified  by  the  policies.   The administrator
         would need to be able to associate the policies with the
         devices  in  some  way.  The interface the administrator
         uses for policy administration is beyond  the  scope  of
         this  document,  but there must be a standardized inter-
         face for inserting into and retrieving  policy  informa-
         tion from the repository.

         The  next step is the repository.  The actual repository
         must be able to support the structured nature of  policy
         information,  and support insert, search, and retrieval.
         The key aspect of the repository is its network accessi-
         bility.   So  far  LDAP is the stand out example meeting
         this requirement.  However,  the  environment  described
         above  is  dynamic.  Policy can be, and should be, rela-
         tively static.  But when the administrator makes changes
         in  policy, especially to address an existing problem in
         the network or to correct  an  incorrect  policy,  those
         changes may need to be propagated quickly.  This is best
         done via notification rather than  polling.   LDAP  cur-
         rently  does  not provide a notification to LDAP clients
         of changes.

         There may be  other  functionality  which  is  logically
         associated  with the repository.  This functionality may
         address the notification requirements, and may also con-
         tribute  to the desire to have validation, verification,
         and conflict detection performed on new or modified pol-
         icy information.




Mahon, et al             Expires May 2001               [Page 11]


Internet Draft         Policy Requirements          November 2000


         The  next  requirement  is  the transformation of policy
         information into device  information,  followed  by  the
         features in the device to enforce policy.

         In  addition  is  the  need  to  address policy which is
         referring to a moving or changing set of needs,  primar-
         ily users moving around in the network.  This issue will
         only grow in importance.   The  issue  arises  not  just
         because  the  origin  of  the traffic is moving, but the
         destination, meaning that more  points  in  the  network
         must  be  made aware that traffic going to that destina-
         tion should receive a particular treatment.

   3.2.  Complex Usage Case

      A more complex usage case would involve managing a particu-
      lar  kind  of traffic across the network.  For example, say
      that a corporate IT group decides that no more than 40%  of
      all  network  traffic  can  be video.  This will further be
      defined that over any link the traffic can only take up  to
      40% of the bandwidth of that link.

      This  presents many different problems to be solved.  Traf-
      fic identification is a necessary  component  in  order  to
      enforce  policy  of  this  type, but such identification is
      beyond the scope of this draft.   The  ability  to  specify
      conditions which are used to identify traffic is a require-
      ment for policy itself.

      One way is to use signaling via RSVP to  identify  traffic.
      But  this  may  not  always be feasible, especially in this
      example where the intent is not to guarantee a QoS for  the
      video  traffic,  but to limit its use of the corporate net-
      work bandwidth.  Those who are generating video traffic may
      not  always want to have their traffic identified as video,
      and so using a signal may be avoided.

      The traffic must be identifiable and must  be  able  to  be
      specified in conditions used within the policy rule.

      Policies  would be deployed in the core and at the edges of
      the network to enforce the utilization limits.  The need in
      the core is that multiple flows from different sources with
      different destinations may end up traversing the same link.
      Per  the  definition above, their aggregate bandwidth usage
      can be no more than 40% on any link, so the  policing  must
      occur everywhere.

      For  this  example  consider  a simple policing action type
      which limits bandwidth usage.  This action may use  shaping
      or dropping to police the traffic to ensure it doesn't take
      more  than  the  permitted  bandwidth.   Because  of   this
      restriction,  traffic  would  end up with no more bandwidth


Mahon, et al             Expires May 2001               [Page 12]


Internet Draft         Policy Requirements          November 2000


      than 40% of the slowest link it traverses.  Issues of  jit-
      ter  and latency should be addressed in some form, possibly
      by other action types deployed to the same interfaces.

      This leads to another topic that must  be  resolved  for  a
      usable  policy  system:  the  interaction and relationships
      between multiple policy rules,  particularly  of  different
      types,  on  a  single  managed entity.  For example, how to
      express policy rules in a way that is obvious to the admin-
      istrator and device/policy translator that multiple actions
      are to be taken and are to work together?  Later  revisions
      of this draft will include examples in this area.

      Either  the  policy management system must have information
      about the bandwidth abilities of each link, or  the  Policy
      Consumers  (which  convert  policy into device information)
      must be able to translate percentage into  device  specific
      values.

   3.3.  Complex Usage Case - Requirements

      As with the simple usage case, there must be:

          - A standard interface to the policy repository.
          - Network access to the policy repository.
          - A way to notify components which use policy that
            there is new or modified policy.
          - A way to transform the policy information to a
            form usable by devices.
          - Mechanisms to enforce policy on network traffic.


      In  addition,  this  example  points  out the need for well
      defined semantic relationships  between  multiple  policies
      and/or rules within the same policy, especially if they are
      of different action types.


4.  Security Considerations

   For QoS related Policy, the security needs of a Policy Manage-
   ment System require authentication at a minimum.

   The  Policy  Management  System contains components which send
   messages and read and write data.

   The interactions which involve writing  of  data  MUST  ensure
   authentication of both parties.  In other words, when a Policy
   Consumer connects to a Policy Management Repository, in  which
   the  Policy  Consumer writes status and configuration informa-
   tion to the Policy Management Repository, the Policy  Consumer
   must  authenticate itself to the Policy Management Repository,
   and vice-versa.  The reason for this is that either end of the


Mahon, et al             Expires May 2001               [Page 13]


Internet Draft         Policy Requirements          November 2000


   communication could be false.  If a true Policy Consumer wrote
   data to a false Policy Management Repository, the  Administra-
   tor  will  not  see the true data.  If a false Policy Consumer
   wrote data to a true Policy Management Repository, the  Admin-
   istrator will see false data.  Either situation means that the
   Administrator does not know the true state of Policy  configu-
   ration  in  the  networked  environment.  Similar requirements
   exist for the connection of the Policy UI to the Policy Repos-
   itory and Policy Management Repository.

   Authentication also allows ensuring the party is authorized to
   perform the actions taken (reading and/or writing  policy  and
   status information).

   There  is  need to limit access (either read or write) to por-
   tions of the policy information (and status information).  The
   policy  management  system  (or data repository if it is to be
   accessed directly rather than through  the  policy  management
   system) must allow establishing multiple users (or identities)
   in order to allow authorization of which subsets of the infor-
   mation the user (or component) is allowed to access.

   Policy  information  should  also  be shipped with information
   verifying its integrity, that is, demonstrating  that  it  has
   not been tampered with during transit from a trusted server or
   client.

   When  Policy  is  used  for  security  purposes,  it  MUST  be
   encrypted when being transported over the network.

   Repositories  must  be as secure as reasonably possible.  If a
   Repository resides on a general purpose host,  access  to  the
   Repository  data  should  be controlled and monitored.  If the
   data cannot be so secured, other means, such as encryption  of
   data  in  the  repository, or other methods ensuring integrity
   should be employed.

5.  Summary

   Policy Based Management is not just a buzz word, or a solution
   looking  for  a problem.  There is a genuine need for allowing
   network Administrators to be more effective  by  managing  the
   network  as  a  collective,  not as a collection of individual
   devices each requiring a separate set of knowledge.

   Today's tools allow Administrators to  configure  the  devices
   which enable traffic, but the view they present to Administra-
   tors is limited, and the management of a device is  the  focus
   of the activities with those tools.

   Policy  information,  as  described in [INFOMODEL] allows that
   abstraction, but additional information is needed to make Pol-
   icy  useful.   Information  such  as  the  targets  of Policy,


Mahon, et al             Expires May 2001               [Page 14]


Internet Draft         Policy Requirements          November 2000


   attributes about those targets, and  the  association  between
   Policy and the targets must be further defined.

   Additionally,  the  actual architecture of a Policy Management
   System must be further defined in order to allow multiple ven-
   dors  to  have  interoperable implementations.  The details of
   such an architecture include  making  the  Policy  information
   available  in a timely manner, and providing the Administrator
   (and, in the future, tools) with information about the charac-
   teristics  of  Policy  Targets in order to allow validation of
   Policy and conflict detection.   Additionally,  Administrators
   need  to  know if Policy deployment was successful in order to
   know if the network will work as expected so they  don't  have
   to  wait for users of the network to tell them there's a prob-
   lem.

   New requirements not already  documented  elsewhere  are  also
   documented here, such as security, and timely delivery of Pol-
   icy Data.

   Another requirement which is probably best addressed through a
   combination  of  data  organization, techniques, and architec-
   ture, is that of  dealing  with  a  mobile  (dynamic)  set  of
   clients.

   To  finish  the  summation  of this document, below are bullet
   lists of the requirements of a Policy Management System.   The
   items marked with an asterisk are yet to be fully defined.

    Policy Data

       - A way to state actions to be taken by the policy managed
         entity
       - A way to specify under what conditions the above actions
         are to take place
       - A way to specify to what the policy (combination of action
         and prerequisite conditions) pertains or is to control *
       - Status information about the policy managed entity *
       - Properties of policy managed entity describing capabilities *
       -  Semantic relationship of policy actions, both of same
         action type and dissimilar action types. *
       - Security information (integrity, authentication, etc.) *
       - A way to limit access to policy contents based on security
         information.


   The  following are tentative derivations from the requirements
   to be considered further.







Mahon, et al             Expires May 2001               [Page 15]


Internet Draft         Policy Requirements          November 2000


       - Policy repository communication (e.g., LDAP)
       - Policy repository (may be settled by above
         question, e.g., if communication is LDAP)
       - Notification to Policy Consumer of new/changed
         policy *
       - Versioning of Policy Data *
       - Status reporting mechanism *




6.  Intellectual Property

   The IETF takes no position regarding the validity or scope  of
   any  intellectual  property  or  other  rights  that  might be
   claimed to pertain to the implementation or use of  the  tech-
   nology  described  in this document or the extent to which any
   license under such rights might or  might  not  be  available;
   neither does it represent that it has made any effort to iden-
   tify any such rights.  Information on  the  IETF's  procedures
   with  respect  to  rights  in  standards-track  and standards-
   related documentation can be found in BCP-11.

   Copies of claims of rights made available for publication  and
   any assurances of licenses to be made available, or the result
   of an attempt made to obtain a general license  or  permission
   for  the  use  of  such  proprietary rights by implementors or
   users of this specification can be obtained from the IETF Sec-
   retariat.

   The  IETF  invites any interested party to bring to its atten-
   tion any copyrights, patents or patent applications, or  other
   proprietary  rights  which  may  cover  technology that may be
   required to practice this standard.  Please address the infor-
   mation to the IETF Executive Director.


7.  References


   [TERMS]         S.  Bradner,  "Key  words  for  use in RFCs to
                   Indicate  Requirement  Levels",  Internet  RFC
                   2119, March 1997.


   [RFC 1633]      R.  Braden,  D. Clark, S. Shenker, "Integrated
                   Services  in  the  Internet  Architecture:  an
                   Overview", June 1994.


   [RFC 2205]      R.  Braden, L. Zhang, S. Berson, S. Herzog, S.
                   Jamin, "Resource ReSerVation  Protocol  (RSVP)
                   --   Version   1   Functional  Specification",


Mahon, et al             Expires May 2001               [Page 16]


Internet Draft         Policy Requirements          November 2000


                   September 1997.


   [RFC 2475]      S. Blake, D. Black, M. Carlson, E. Davies,  Z.
                   Wang, W. Weiss, "An Architecture for Differen-
                   tiated Services", December 1998.


   [TERMINOLOGY]   J. Strassner, E.  Ellesson,  "Terminology  for
                   describing   network   policy  and  services",
                   Internet     Draft     draft-strassner-policy-
                   terms-01.txt, February 1999.


   [IANA]          Internet     Assigned    Numbers    Authority,
                   http://www.isi.edu/in-notes/iana/assign-
                   ments/port-numbers .


   [INFOMODEL]     B.  Moore,  E. Ellesson, J. Strassner, "Policy
                   Framework Core  Information  Model",  Internet
                   Draft             draft-ietf-policy-core-info-
                   model-03.txt, January 2000.


   [POLFRAME]      M. Stevens, W. Weiss, H. Mahon, B.  Moore,  J.
                   Strassner,   G.   Waters,  A.  Westerinen,  J.
                   Wheeler, "Policy  Framework",  Internet  Draft
                   draft-ietf-policy-framework-00.txt,  September
                   1999.


   [COPS]          J. Boyle, R. Cohen, D. Durham, S.  Herzog,  R.
                   Rajan, A.  Sastry, "The COPS (Common Open Pol-
                   icy  Service)  Protocol",  RFC  2748,  January
                   2000.


8.  Acknowledgements

   Special  thanks to Mark Stevens, Bob Moore, Andrea Westerinen,
   Avri Doria, Cheh Goh, Ken  Owens,  Rick  Roeling,   and  Brian
   O'Keefe  for input and feedback during the development of this
   draft.  Thanks also go to Ed  Ellesson  and  Bert  Wijnan  for
   their guidance on what should be discussed in this document.

9.  Author Information








Mahon, et al             Expires May 2001               [Page 17]


Internet Draft         Policy Requirements          November 2000


       Hugh Mahon
       Hewlett-Packard Co.
       3404 East Harmony Road, MS A2
       Fort Collins, CO 80528-9599
       USA
       Phone: +1 970 898 2487
       EMail: hugh_mahon@hp.com

       Yoram Bernet
       Microsoft
       1 Microsoft Way
       Redmond, WA 98052
       USA
       Phone: +1 206 936 9568
       EMail: yoramb@microsoft.com

       Shai Herzog
       IPHighway
       Parker Plaza, 16th Floor
       400 Kelby St. Fort-Lee NJ 07024
       USA
       Phone: +1 201.585.0800
       EMail: herzog@iphighway.com

       John Schnizlein
       Cisco Systems
       9123 Loughran Road
       Fort Washington, MD 20744
       USA
       Phone: +1 301 567 7126
       EMail: john.schnizlein@cisco.com


10.  Full Copyright Statement

   Copyright   (C)   The  Internet  Society  (2000).  All  Rights
   Reserved.

   This document and translations of it may be  copied  and  fur-
   nished to others, and derivative works that comment on or oth-
   erwise explain it or assist in its implementation may be  pre-
   pared, copied, published and distributed, in whole or in part,
   without restriction of any kind, provided that the above copy-
   right  notice  and  this  paragraph  are  included on all such
   copies and derivative works.  However,  this  document  itself
   may  not be modified in any way, such as by removing the copy-
   right notice or references to the Internet  Society  or  other
   Internet  organizations,  except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights  defined  in the Internet Standards process must be
   followed, or as required to translate it into languages  other
   than English.



Mahon, et al             Expires May 2001               [Page 18]


Internet Draft         Policy Requirements          November 2000


   The  limited  permissions granted above are perpetual and will
   not be revoked by the Internet Society or  its  successors  or
   assigns.

   This document and the information contained herein is provided
   on an "AS IS" basis and THE INTERNET SOCIETY AND THE  INTERNET
   ENGINEERING  TASK  FORCE  DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY  WARRANTY  THAT  THE
   USE  OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY  OR  FITNESS  FOR  A
   PARTICULAR PURPOSE."












































Mahon, et al             Expires May 2001               [Page 19]


Internet Draft         Policy Requirements          November 2000


   1. Introduction .........................................    2
   2. QoS Policy usage .....................................    5
   2.1 Voice ...............................................    5
   2.2 Protected classes of traffic ........................    6
   2.3 Guaranteed Transfer Time ............................    7
   2.4 Policy and Services .................................    7
   3. Usage Cases ..........................................    8
   3.1 Simple Usage Case ...................................    8
   3.1.1 Simple Usage Case in an ISP Environment ...........    8
   3.1.2 Simple Usage Case in an Enterprise Environment ....    9
   3.1.3 Simple Usage Case - Steps to Implement ............   10
   3.1.3 Simple Usage Case Requirements ....................   11
   3.1 Complex Usage Case ..................................   12
   3.1 Complex Usage Case - Requirements ...................   13
   4. Security Considerations ..............................   13
   5. Summary ..............................................   14
   6. Intellectual Property ................................   16
   7. References ...........................................   16
   8 Acknowledgements ......................................   17
   9. Author Information ...................................   17
   10. Full Copyright Statement ............................   18


































Mahon, et al             Expires May 2001               [Page 20]