rfc1297.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 675 行 · 第 1/3 页


RFC 1297                  NOC TT REQUIREMENTS               January 1992


      automatically without operator intervention.  This operator's
      opinion is that an operator acknowledgement should be required,
      but this point is debated enough that designers of a new system
      probably should support either option).

      The Alarm Clock feature of the trouble ticket system also
      generates alerts.  These alerts ought to feed gracefully into the
      Alert Monitor system, so that the operators will get all of their
      alerts from one place.

      3) DATABASE CONNECTIONS.  A good trouble ticketing system will
      query NOC databases to automatically fill out trouble ticket
      fields where possible.  This can be used for:

      - Filling out Network Operator information (e.g., phone number)
        based on the NetOp's signon id.
      - Filling in contact information based on machine name.
      - Filling in circuit numbers based on link description.
      - Filling in alarm clock or escalation time fields based on the
        machine or link name and on time of day.
      - Filling in machine serial numbers based on configuration database.

      4) MACHINE QUERYABLE INFORMATION.  It could also be possible for a
      trouble ticket system to make standard queries of the network
      itself when a trouble ticket is opened: e.g., the system could
      request and store current machine configurations whenever a ticket
      was opened for that machine.  On some systems, hardware serial
      numbers are obtainable by software query directly to the machine.

      5) ELECTRONIC MAIL.  Problem notification often comes via
      electronic mail; it must be possible to easily open a ticket and
      include the original mail message within the ticket as part of the
      initial problem description.  When extremely technical messages
      come in from network engineers, it is useful to allow those
      messages to be included verbatim, rather than forcing less
      technical network operators to rephrase the messages or to force
      them into predefined formats.  Later update messages should also
      be easily includable.  Possibly: tickets could be opened
      automatically for mail messages to certain mailboxes.  A response
      system saying "Your request has been received and assigned ticket
      number ####" might be desirable.

      Information within trouble tickets must also be easily available
      (possibly just via the windowing system) for inclusion in Email
      messages to engineers and others.

      Scheduled (e.g., daily) reports must also be easily generated into
      the Email system.



Johnson                                                         [Page 9]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


      6) DISPATCHING AND NOTIFICATION SYSTEMS.  An important real-time
      aspect of Network Operations is notifying users, technical
      contacts, and administrators of various classes of problems.  The
      rules for who gets notified of what can be very arbitrary and
      complex, and can involve electronic mail, notices in computer
      conferences, automatic beeper pages, and synthesized voice
      announcements.  It would be good for a trouble ticket system to
      provide for automatic (or operator initiated) notification of the
      appropriate channels for the current ticket (based on network,
      machine, severity of problem, duration of the problem, escalation
      guidelines, etc).

      Databases associated with the trouble ticket system may also have
      lists of specific people to contact about outages for particular
      machines.  These "who to inform" lists can facilitate customized
      notification messages directly from the trouble ticket system.

      It may also be possible to dispatch experts directly from the
      trouble tickets system.  IBM's ECCO system allows allows customers
      to directly dispatch Service Engineers from machine interactions.
      Many NOCs also use computer hooked to modems to automatically page
      engineers.  This kind of dispatching should be available from
      within the trouble ticket system (along with an automatic note
      into the trouble ticket that the engineer has been dispatched).

      7) OTHER TROUBLE TICKET SYSTEMS.  When the NOC generates a trouble
      ticket, it often immediately calls up a telco or another Internet
      NOC, who proceed to open their own ticket.  The Internet
      Engineering Task Force User Connectivity Working Group is also
      proposing a national trouble ticket tracking system, which would
      need updating from individual NOC trouble ticket systems.  A
      state-of-the-art trouble ticket system could have provisions for
      transferring tickets and ticket information in and out of other
      such systems.

      8) NETWORK ACCESS.  Some older trouble ticket systems assumed that
      anyone with a need to access the information would obtain a signon
      and learn to use that system.  The range of people with a need for
      trouble ticket information is now too great to allow this
      assumption.  A good system now needs to be able to support network
      query for tickets and summary reports, as well as Email delivery
      of scheduled reports.

      9) SUBROUTINE INTERFACE.  To allow for ad-hoc and currently
      unanticipated needs, the trouble ticket system needs to support a
      full-function set of subroutine calls.  These subroutines will
      allow construction of further trouble ticket functionality not yet
      specified.



Johnson                                                        [Page 10]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


      10) EXPERT SYSTEMS.  Network debugging is a very promising area
      for expert system and artificial intelligence applications.  But
      such an algorithm should require access to the alert monitoring
      system, configuration and change control systems, to the network
      itself, and also to the information in the trouble ticket system.
      A good future system then needs to make this information available
      (probably via the subroutine interface mentioned above), and to
      also allow the Network Operators to invoke the artificially
      intelligent debugging from within a trouble ticket (including its
      output as part of the ticket dialogue).

      11) GRAPHICS/REPORT Capability.  Statistical and graphical
      displays about trouble ticket data need to be compatible with
      tools used to generate reports, news letters, etc.

OTHER CONSIDERATIONS:

      1) INTERACTIVE SPEED.  The system must be fast enough to be used
      interactively.  NetOps need to answer questions over the phone in
      real time; good answers cannot be given if every query takes a
      couple of minutes.  More importantly, the NetOps need the trouble
      ticket system in order to get information necessary to fix the
      network.  If looking for old or currently-open tickets takes more
      than a few seconds, it won't be done.  If updates take very long
      to make, then updates won't be recorded, or they will be recorded
      long after the event (with corresponding loss of accuracy).  (Our
      Operators have asked for a single-line "update this ticket with
      this message" utility that would let them avoid even retrieving
      the ticket for simple updates!)  Any time spent waiting reduces
      NetOp productivity and Network reliability.

      2) BACKUPS AND RELIABILITY.  The trouble ticket system is
      absolutely crucial to both immediate and long-term operation of
      the NOC.  Good systems could back up all data several times an
      hour to an auxiliary processor.  That processor should be
      accessible for immediate use in case of failure of the primary
      system.

      3) HISTORY AND ARCHIVING.  A trouble ticket system is a
      constantly-growing database system.  Old tickets need to be
      removed from the system at some interval (a year?  several years?)
      and archived.  These archives should also be restorable for long-
      term history processing.

      4) PRIVACY AND SECURITY.  The ability to enter, append, and modify
      tickets should be controlled by id and password.  Permissions
      should be specifiable on a per-field basis.  General read access
      to tickets (or portions of tickets) also needs to be restricted,



Johnson                                                        [Page 11]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


      or else NetOps will be reluctant to be full and candid in their
      reporting.

UTILITY

   There are quite a few ideas in this "Wishlist".  Ultimately, what an
   Operations Center needs is a totally integrated set of tools which
   completely model all of its activities, and which integrates cleanly
   with all backup, peer, and vendor NOCs.  It is hard to imagine that
   this whole system could come out of a shrinkwrapped box, even without
   the local configuration.  But most of these facilities do exist, now,
   in some system.  Hopefully, this document will foster an ongoing
   discussion of ways in which NOC operator-level tools are used in real
   operations, and will encourage systems implementors and vendors to
   bring some of this functionality to the aid of real operations.  It
   might even inspire current Operations Centers to add useful features
   to their current operations.

Security Considerations

   This paper does not pose specific new security issues.  The systems
   described herein would be host database applications, however, or
   even distributed host database applications.  All of the normal
   security considerations for that kind of system would apply.
   Multiple classes of user access need to be specified for classes of
   ticket data.  Possible security threats include disclosure of network
   information, disclosure of confidential material (e.g., circuit
   numbers or home phone numbers), and denial of service to the Network
   Operations Center leading to degradation of network service.

Author's Address

   Dale S. Johnson
   Merit NOC
   1075 Beal Avenue
   Ann Arbor, MI 48109-2112

   Phone:  [phone]

   Email:  [e-mail]

   Discussion/comments may be sent to [e-mail].  The list
   is maintained by [e-mail].








Johnson                                                        [Page 12]