NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")
RFC 1297

Document Type RFC - Informational (January 1992; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1297 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         D. Johnson
Request for Comments: 1297                           Merit Network, Inc.
                                                            January 1992

             NOC Internal Integrated Trouble Ticket System
                   Functional Specification Wishlist
                        ("NOC TT REQUIREMENTS")

Status of the Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   Professional quality handling of network problems requires some kind
   of problem tracking system, herein referred to as a "trouble ticket"
   system.  A basic trouble ticket system acts like a hospital chart,
   coordinating the work of multiple people who may need to work on the
   problem.

   Once the basic trouble ticket system is in place, however, there are
   many extensions that can aid Network Operations efficiency.
   Information in the tickets can be used to produce statistical
   reports.  Operator efficiency and accuracy may be increased by
   automating trouble ticket entry with information from the network
   Alert system.  The Alert system may be used to monitor trouble ticket
   progress.  Trouble tickets may be also used to communicate network
   health information between NOCs, to telcom vendors, and to other
   internal sales and engineering audiences.

   This document explores competing uses, architectures, and desirable
   features of integrated internal trouble ticket systems for Network
   and other Operations Centers.

Introduction

   This RFC describes general functions of a Trouble Ticket system that
   could be designed for Network Operations Centers.  The document is
   being distributed to members of the Internet community in order to
   stimulate discussions of new production-oriented operator-level
   application tools for network operations.  Hopefully, this will
   result both in more ideas for improving NOC performance, and in more
   available tools that incorporate those ideas.

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

PURPOSES OF A NOC TROUBLE TICKET SYSTEM

   A good Network Operations Trouble Ticket System should serve many
   purposes:

      1) SHORT-TERM MEMORY AND COMMUNICATION ("Hospital Chart").  The
      primary purpose of the trouble ticket system is to act as short-
      term memory about specific problems for the NOC as a whole.  In a
      multi-operator or multi-shift NOC, calls and problem updates come
      in without regard to who worked last on a particular problem.
      Problems extend over shifts, and problems may be addressed by
      several different operators on the same shift.  The trouble ticket
      (like a hospital chart) provides a complete history of the
      problem, so that any operator can come up to speed on a problem
      and take the next appropriate step without having to consult with
      other operators who are working on something else, or have gone
      home, or are on vacation.  In single-room NOCs, an operator may
      ask out loud if someone else knows about or is working on a
      problem, but the system should allow for more formal communication
      as well.

      2) SCHEDULING and WORK ASSIGNMENT.  NOCs typically work with many
      simultaneous problems with different priorities.  An on-line
      trouble ticket system can provide real time (or even constantly
      displayed and updated) lists of open problems, sorted by priority.
      This would allow operators to sort their work at the beginning of
      a shift, and to pick their next task during the shift.  It also
      would allow supervisors and operators to keep track of the current
      NOC workload, and to call in and assign additional staff as
      appropriate.

      It may be useful to allow current priorities of tickets change
      according to time of day, or in response to timer alerts.

      3) REFERRALS AND DISPATCHING.  If the trouble ticket system is
      thoroughly enough integrated with a mail system, or if the system
      is used by Network Engineers as well as Network Operators, then
      some problems can be dispatched simply by placing the appropriate
      Engineer or Operator name in an "assigned to" field of the trouble
      ticket.

      4) ALARM CLOCK.  Typically, most of the time a trouble ticket is
      open, it is waiting for something to happen.  There should almost
      always be a timer associated with every wait.  If a ticket is
      referred to a phone company, there will be an escalation time
      before which the phone company is supposed to call back with an
      update on the problem.  For tickets referred to remote site
      personnel, there may be other more arbitrary timeouts such as

Johnson                                                         [Page 2]
Show full document text