A customer-to-carrier interface for trouble administration

This paper describes a customer-to-carrier trouble administration service based on the Network Management Forum (NMF) service management concept. Implementing a trouble administration gateway for direct on-line submission and interaction of trouble
of 19
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  Journal of Network and Systems Management Vol. 4 No. 4 1996 A Customer to Carrier Interface for Trouble Administration Elizabeth D. Zeisler t Dan Bolton I Adrian Tang 2 Deokjai Choi 2 Taesang Choi 2 and Hai Feng Weng 2 This paper describes a customer-to-cartier rouble administration service based on the Network Management Forum (NMF) service management concept. Implement- ing a trouble administration gateway for direct on-line submission and interaction of trouble tickets is being realized through a standard interface known in industry as "Electronic Bonding." This interface supports connectivity between an ISO/ITU-T Common Management Information Protocol (CMIP) manager and multiple agents. A Defense Information Systems Agency (DISA) project, described herein, enables a customer, acting in a manager role, to track trouble reports across public carder networks. KEY WORDS: CMIP: service management: manager gateway: customer; service provider. 1. BACKGROUND AND PROBLEM STATEMENT A Defense Information Systems Agency (DISA) project enables a customer, acting in a manager role, to track trouble reports across public carrier networks. As network connectivity grows, there is a need to extend the trouble service management from a few nodes to a global environment, where many networks are interconnected. Until recently, DISA could only use the telephone to manually coordinate network troubles with carriers. This is changing, since in the last several years interfaces have been implemented to share "Electronic Bonding" (EB) trouble reports betweon local access providers and long distance service providers like Bell Atlantic Corp., GTE Corp., MCI Corp. and AT&T. In fact, our DISA ~The MITRE Corporation, 1820 Dolley Madison Blvd, MS W64/58, McLean, Virginia 22102- 3481. E-mail(s):, 2University of Missouri-Kansas City, 4747 Troost BIdg, Room 207H, 5100 Rockhitl Rd, Kansas City, Missouri 64110-2499. E-mail: 457 1064-757019611200-0457509.5010 9 1996 lenum Publishing Corporation  458 Zeisler Bolton Tang Choi Choi and Weng project represents the first U.S. noncarrier customer implementation of stan dard Trouble Administration using the EB interface. The creation of a standard profile for trouble administration was aided by AT T and MCI which pushed to create the electronic bonding profile by the end of 1995. In seeking a new format, they mandated the seven regional Bell companies and GTE implement both a standard application and connection solution or risk losing their business. The harmonized U.S. standards profile uses a subset of the ANSI T1M1 227 for the trouble administration model, ANSI T 1 M1 228 to define base services, objects and functional units, a superset of Open Systems Interconnection (OSI) standards for a common Telecommu- nications Management Network (TMN) for the transport and lower layer inter- face between two TMNs (ITU-T M3100 series) and a CMIP (CMIP-ITU-T X.711) over OSI component for the upper layer specifications. I.I. Requirement: Multiple Providers and Protocols Figure 1 highlights the interface between a customer's organization and a Service Provider (SP) who sells services to the customer [I]. The interface without a back-end system could be supported using CMIP or SNMP manage- ment platforms, as well as Remote Procedure Calls (RPCs). To this purpose, a mediation gateway is required (P gateway). In Fig. 1, the Protocol independent Implementation will connect customer organizations to an external entity like the various SP Operations Systems (OS), which reside outside the jurisdiction of the customer. The term SP in this paper refers to an entity providing services of the Service Layer in the TMN model, while the term network provider refers to an entity providing services of the Network Layer in the TMN model. Log- ically, an SP differs from a network provider; an SP may or may not own the network elements used to supply services. A traditional telephone carrier is a type of SP, as used herein. There can be one too many customer CMIP manager gateways at the cus- tomer location. The gateway (labeled as the P Gateway) is an intelligent pass through between the backend customer legacy trouble ticketing system on one side and the service provider agent and back-end system on the other side. 1.2. Context: A Customer Network Infrastructure Before explaining the architecture, we briefly identify the context for the customer operations center systems where troubles are raised. Overall, the interface provices the noncarrier customer a window into car- der trouble administration. Through this window, DISA will promulgate trou- ble reporting policy, create trouble reports, track the trouble report (state/status), authorize-or-prioritize requests, verify the repair, inform carriers of changes to  Customer to Carrier Interface for Trouble Administration 459 Customer s Organization m(~ Service Provider System 1 m), SelvIce Provider System n Protocol Independent (P) Implementation (No Backend System) I o.;.o. Customer Service Provider Customer Service Provider Fig l Uniform trouble management interface to multiple service providers customer contact personnel, and notify carriers of changes in operation center schedules minutes/hours/days) in universal time for international applications [2]. More specifically, there must be integration with Network and Systems Management Centers, that comprise a three-level hierarchical infrastructure for DISA/DOD Department of Defense), and are responsible for managing dis- tributed networks, systems, and databases. To this end, in support of the Defense Information Infrastructure DID, DISA has identified several essential distrib- uted, end-to-end services, which are key to management: messaging and trouble administration. Either of these services can be enabled through development of a uniform gateway for translation and communication to public carrier agent systems. Thus, the context for a trouble administration gateway is that it must sup- port different kinds of DII systems that use public carriers, like the Defense Messaging System DMS); DMS supports enterprise-wide directory manage- ment and electronic mail services. In DOD, at the top-most organizational level the DII Global Control Cen- ter GCC) will perform executive management oversight to include oversight of the DMS. Implicit in Fig. 2, managers at the GCC will be capable of mon- itoring DMS elements see Key).  460 Zeisler Bolton Tang Choi Choi and Weng L ..... i ....... i l Global ] Contro~ enter l I ........ t ....... r~- ... m I Control Center I ..... I I ~ISS-~ i~ [-PU~A-1 l Sub~4T~nate ;nteMllTlTate I ~A'-~ ............................ Key DSA Directory ystem Agent CAW CertiflcaUon uthority WorkaiaUon MFI MulUfunction nterpreter MLA Mail Ust Agent MS Meuage Store MTA Message Transfer Agent PUA Profiling User Agent UA User Agent Fig. 2. DMS within the DII management structure. At the second organizational level, the Regional Control Center RCC) fucntions will be executed at three control centers, one for each of the three major world regions: Continental U.S., Europe EUR), and Pacific PAC). An RCC will a) monitor multiple services, b) periodically receive network man- agement reports, c) monitor leased telecommunications resources, and d) maintain a view of operations for cartier-provided switched circuits, messaging and directory management. Moreover, when forces are deployed, a designated RCC assumes a role in providing trouble administration services to the Joint Task Force. Additionally, an RCC help desk would periodically receive Local Control Center LCC) mail service trouble reports that cannot be resolved at the local level. As shown in the shaded boxes of Fig. 2, managers at the RCCs will be capable of reporting troubles with the DMS backbone agents. Within the three respective RCC regions, the bottom organizational level LCC) is located at military installations and DOD agency facilities word-wide. The LCC is responsible for all of the local service, plus monitoring and control of intermediate and subordinate subnetworks and systems. DMS management at the LCC level involves monitoring and control using multiple management protocols: SNMP and CMIP more about this later).  Customer-to-Carrier Interface for Trouble Administration 461 Irnl0airecl Communicatiorm Co,.o, " Regional " 9 "2~:~ntTic l/ 9 L Center Control Center I ..g.,tAN I | t t o Report Problem 9 ~ 9 to Help Desk 9 9 ~_J Subroission o Gateway :mUll| , j User Notification 9 9 TRc~ . T ~.m. # DOD lnternal ystem | - 7/ , Diagnose and I Fix Problem a GTE Intra LATA I Support I Service rovider Fig 3 Trouble management scenario. 1.3. Context: Trouble Management Scenario Figure 3 shows an LCC administrator entering a trouble report (TR) to the local Remedy Action Request System (ARS) help desk, which is then submitted to the DISA regional gateway platform site and passed to the SP responsible for servicing the impaired communications, i.e., GTE Corporation. As shown in Fig. 3, management information must be exchanged among the control cen- ters, as well as with external entities like the GTE gateway and back-end sys- tems. In fact, while a trouble report related to service leased from the public carder can be created at he Local ontrol enter (possibly initiated at multiple local end offices), real fault integration between different systems operating at different layers is missing. In other words, the ticket administration is from a service layer perspective; analysis for symptoms caused by fault relations is usually provided at the network or network element layer [1]. Although the carder knowledge of faults would be outside the customer s window, DISA could use the HP OpenView network management product to analyze known local faults, which could lead to an X.25 trouble report creation request.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks