Browse Prior Art Database

Partitioning Operator Access with a Node

IP.com Disclosure Number: IPCOM000118222D
Original Publication Date: 1996-Nov-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 91K

Publishing Venue

IBM

Related People

Sappa, B: AUTHOR [+2]

Abstract

In current networks, different operators have different degrees of responsibility for what they can change in the network. This responsibility can be: view but no change, changes concerning one specific node, changes concerning any node in the network. The finest granularity provided for partitioning operator access is on a whole node basis. This is adequate for networks owned and used by one organization.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Partitioning Operator Access with a Node

      In current networks, different operators have different degrees
of responsibility for what they can change in the network.  This
responsibility can be: view but no change, changes concerning one
specific node, changes concerning any node in the network.  The
finest granularity provided for partitioning operator access is on a
whole node basis.  This is adequate for networks owned and used by
one organization.

      However, as the usefulness of networks (and their cost) has
grown, it is often the case that one company owns a network and sells
the use of parts of it to other companies.  Then the operators of
each client company need to control their part, and only their part,
of the network.  When the network includes bandwidth manager nodes,
the operator restriction needs to be on a granularity finer than that
of a whole node.  For example, one client company may have the use of
half the ports on a bandwidth manager node, another client company
may have the use of the remaining ports, the owning company may
control the trunks.  Numerous customer requirements have been
received to provide a partitioning of operator access down to the
granularity of individual parts of a node, not just to a whole node.

      Operator identifications, Identification (ID) verifications
(e.g., a password), and profiles are defined and stored in each node,
and checked for each command received.  The functions available to an
operator are divided into access groups, for example, trunks, ports,
administrative.

      When a new operator ID is created by the network administrator,
the ID is accompanied by a profile that identifies what groups of
functions the operator is entitled to use and what node resources the
operator can access.

      The information is kept in a file or control block within each
node.  See example record in the Figure.  Each command carries with
it the ID of the operator that issued it.  When a command is
received, the operator ID associated with it is used to determine:
  1.  whether this operator is allowed to access this node;
  2.  if so, whether the operator is using a command within the
       access groups in his profile; and
  3.  whether he is using the command on a node resource that
       this operator is allowed to access.

      There are six operator function groups.  The first three would
be retained by the owning company, and it does not make sense to
partition them at granularity smaller than a whole node.
  1.  Administrative, such as identifying new operator ID's;
  2.  Service, such as starting traces or loading new code
       into a node;
  3.  Node Infrastructure, hardware and software supporting
       the node as a whole (e.g., an inter-adapter...