Network Working Group Dimitris Zisiadis Internet-Draft Spyros Kopsidas Intended status: Experimental Track Matina Tsavli Expires: March 20, 2011 Leandros Tassiulas CERTH Chrysostomos Tziouvaras GRNET Guillaume Cessieux Xavier Jeannin CNRS December 08, 2010 The Network Trouble Ticket Data Model draft-dzis-nwg-nttdm-08.txt Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 obsoleted 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. This Internet-Draft will expire on March 20, 2011. Zisiadis, et al. Expires March 20, 2011 [Page 1] Internet-Draft NTTDM December 2010 Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing and handling of the TTs. In the present document we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). Table of Contents 1. Introduction .................................................. 5 1.1. Terminology ................................................ 6 1.2. Notations .................................................. 6 1.3. About the Network Trouble Ticket Data Model ................ 6 1.4. About the Network Trouble Ticket Implementation ............ 7 1.5. Future plans ............................................... 7 Zisiadis, et al. Expires March 20, 2011 [Page 2] Internet-Draft NTTDM December 2010 2. NTTDM Types and Definitions ................................... 8 2.1 Types and Definitions for the TYPE Attributes ............... 8 2.1.1 Defined ................................................. 8 2.1.2 Free .................................................... 8 2.1.3 Multiple ................................................ 8 2.1.4 List .................................................... 8 2.2 Types and Definitions for the VALID FORMAT Attributes ....... 9 2.2.1 Predefined String ....................................... 9 2.2.1.1 Definitions of the Predefined Values ................10 2.2.2 String ................................................. 13 2.2.3 Datetime ............................................... 14 3. NTTDM ........................................................ 14 3.1 NTTDM components ........................................... 14 3.1.1 NTTDM Attributes ....................................... 14 3.2 NTTDM Aggregate classes ................................... 15 3.2.1 NTTDM-Document class ................................... 15 3.2.2 Ticket class ........................................... 15 3.2.3 Ticket origin information .............................. 17 3.2.3.1 PARTNER_ID ......................................... 17 3.2.3.2 ORIGINAL_ID ........................................ 17 3.2.4 Ticket information ..................................... 17 3.2.4.1 TT_ID .............................................. 18 3.2.4.2 TT_TITLE ........................................... 18 3.2.4.3 TT_TYPE ............................................ 18 3.2.4.4 TT_PRIORITY ........................................ 19 3.2.4.5 TT_STATUS .......................................... 19 3.2.4.6 TT_SOURCE .......................................... 19 3.2.4.7 TT_OPEN_DATETIME ................................... 20 3.2.4.8 TT_CLOSE_DATETIME .................................. 20 3.2.5 Trouble details ........................................ 20 3.2.5.1 TT_SHORT_DESCRIPTION ............................... 20 3.2.5.2 TT_LONG_DESCRIPTION ................................ 21 3.2.5.3 TYPE ............................................... 21 3.2.5.4 TT_IMPACT_ASSESSMENT ............................... 21 3.2.5.5 START_DATETIME ..................................... 22 3.2.5.6 DETECT_DATETIME .................................... 22 3.2.5.7 REPORT_DATETIME .................................... 22 3.2.5.8 END_DATETIME ....................................... 23 3.2.5.9 TT_LAST_UPDATE_TIME ................................ 23 3.2.5.10 TIME_WINDOW_START ................................. 23 3.2.5.11 TIME_WINDOW_END ................................... 24 3.2.5.12 WORK_PLAN_START_DATETIME .......................... 24 3.2.5.13 WORK_PLAN_END_DATETIME ............................ 24 3.2.6 Related data ........................................... 25 3.2.6.1 RELATED_EXTERNAL_TICKETS ........................... 25 Zisiadis, et al. Expires March 20, 2011 [Page 3] Internet-Draft NTTDM December 2010 3.2.6.2 ADDITIONAL_DATA .................................... 25 3.2.6.3 RELATED_ACTIVITY ................................... 25 3.2.6.4 HISTORY ............................................ 26 3.2.7 Localization and impact ................................ 26 3.2.7.1 AFFECTED_COMMUNITY ................................. 26 3.2.7.2 AFFECTED_SERVICE ................................... 26 3.2.7.3 LOCATION ........................................... 27 3.2.7.4 NETWORK_NODE ....................................... 27 3.2.7.5 NETWORK_LINK_CIRCUIT ............................... 27 3.2.7.6 END_LINE_LOCATION_A ................................ 28 3.2.7.7 END_LINE_LOCATION_B ................................ 28 3.2.8 Contact information .................................... 28 3.2.8.1 OPEN_ENGINEER ...................................... 28 3.2.8.2 CONTACT_ENGINEERS .................................. 29 3.2.8.3 CLOSE_ENGINEER ..................................... 29 3.2.9 Security ............................................... 29 3.2.9.1 HASH ............................................... 29 3.3 NTTDM Representation ....................................... 30 4. Internationalization Issues .................................. 32 5. Example ...................................................... 32 5.1 Link Failure ............................................... 32 6. Sample Implementation: XML Schema ............................ 33 7. Security Considerations ...................................... 45 8. IANA Considerations ........................................... 46 9. Acknowledgements ............................................. 47 10. List of Acronyms ............................................ 48 11. References .................................................. 49 11.1 Normative References ...................................... 49 11.2 Informative References .................................... 49 12. Authors' Addresses .......................................... 50 Zisiadis, et al. Expires March 20, 2011 [Page 4] Internet-Draft NTTDM December 2010 1. Introduction Problem impact assessment, reporting identification and handling as well as trouble information dissemination and delegation of authority are some of the main tasks that have to be implemented by the members of a Grid, for succession in managing the network and maintaining operational efficiency of the services offered to its users. Different TT systems are used by each network domain, delivering TTs in alternate formats, while TT load is growing proportionally with the network size and the serviced users. Hereby we define a data model for TT normalization initially targeted for networking providers serving EGEE [7]. The model is designed in accordance with RFC 1297 [10], meeting requirements of the multiple TT systems used. It is both effective and comprehensive, as it compensates for the core activities of the NOCs. It is also dynamic, allowing additional options to be included in the future, according to demand. It provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency. The data model encodes information about hosts, networks, and the services running on these systems; attack methodology and associated forensic evidence; impact of the activity; and limited approaches for documenting workflow. The Network Trouble Ticket Data Model (NTTDM) aims to simplify TT exchange within the boundaries of a Grid and to enhance the functional cooperation of every Network operation Centre (NOC) and the Grid Operation Centre (GOC). Community adoption of the NTTDM enhances trouble resolution within the grid framework and imparts network status cognizance by modeling collaboration and information exchange among the operators. The NTTDM definition provides: o A common format that allows GOC as well as all participating NOCs to store, exchange, manage and analyze TTs (assessment of TT impact). o Increased automation in handling a TT since the network operators have a common view to the trouble. The model was designed and used as part of the networking support activity of the EGEE project, as part of the ENOC (EGEE Network Operating Centre) [8] procedures for managing the Grid. Zisiadis, et al. Expires March 20, 2011 [Page 5] Internet-Draft NTTDM December 2010 1.1. Terminology NTTDM uses specific keywords to describe the various data components. These keywords are: Defined, Free, Multiple, List, Predefined String, String, Datetime, Solved, Cancelled, Inactive, Superseded, Opened/Closed, Operational, Informational, Administrative, Test. Those in this document are to be interpreted as described in Section 2. 1.2. Notations The NTTDM is specified in two ways, as an abstract data model and as an XML Schema. Section 3 provides a Unified Modeling Language (UML) [9] model describing the individual classes and their relationship with each other. The semantics of each class are discussed and their attributes explained. In Section 6, this UML model is converted in an XML Schema [1, 2, 3, 4]. A specific namespace [5] is also defined. The term "XML document" refers to any instance of an XML Document. The term "NTTDM document" refers to specific elements and attributes of the NTTDM schema. Finally, the terms "class", and "element" will be used interchangeably to reference either a given UML class in the data model or its corresponding schema implementation. 1.3. About the Network Trouble Ticket Data Model The NTTDM is a data representation that provides a framework for normalizing and sharing information among network operators and the GOC regarding troubles within the Grid boundaries. There has been a lot of thought processing during the design of the data model: o The data model serves as a common storage and exchange format. o Every NOC still uses its home TT system for network management within its area of control. o As there is no universally adopted definition for a trouble, in the NTTDM definition the term is used with a comprehensive meaning to cover all NOCs. Zisiadis, et al. Expires March 20, 2011 [Page 6] Internet-Draft NTTDM December 2010 o Handling every possible definition of a trouble incident would call for an extremely expanded and complex data model. Therefore, the NTTDM purpose is to serve as the basis to normalize and exchange TTs. It is flexible and expressive in order to ensure that specific NOC requirements are met. Specific NOC information is kept outside the NTTDM and external databases can be used to feed it. o The domain of managing the information is not fully standardized and must rely on free-form textual descriptions. The NTTDM attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident information. The NTTDM is only one of feasible TT data representations. The goal of this design was to be as effective and comprehensive to cover for the management of a general grid environment. The already used TT formats influenced the design of the NTTDM. 1.4. About the Network Trouble Ticket Implementation Here we describe an example of typical use case. The Grid project EGEE manages its infrastructure as network overlay over the European NRENs and want to be able to warn EGEE sites of the unavailability of the network. Thanks to collaboration with its network provider the EGEE NOC receive TTs (800 tickets/month, 2500 emails/month) from 20 NRENs and should be able to cope with the heavy TT process. Thanks to the NTTDM the EGEE NOC can automate the TT workflow: o TT is filtered, sorted and stored in local DB. o TT impact on the Grid is assessed. o TT is pushed to dashboard and other tools (EGEE TT system, statistics, etc.) 1.5. Future plans Since this is an Experimental document, operational experience will be used to expand the sections under 'Ticket Origin Information?. The current specification is already used within EGEE. Other Grids are free to use it and report comments to the authors. After enough experimentation it will be placed on the Standards Track. Zisiadis, et al. Expires March 20, 2011 [Page 7] Internet-Draft NTTDM December 2010 2. NTTDM Types and Definitions The various data elements of the TT data model are typed. This section discusses these data types. When possible, native Schema data types were adopted, but for more complicated formats, regular expressions or external standards were used. 2.1 Types and Definitions for the TYPE attribute. These types are used to describe the TYPE attribute. 2.1.1 Defined The Defined data type means that the data model provides a mean to compute this value from the rest of the fields. The Defined data type is implemented as a "Defined" in the schema. 2.1.2 Free The Free data type means that the value can be freely chosen. All Free string should have as an attribute the language used. The Free data type is implemented as a "Free" in the schema. 2.1.3 Multiple The Multiple data type consists of one value among multiple fixed values. The Multiple data type is implemented as an "Multiple" in the schema. 2.1.4 List List means many values among multiple fixed values. The List data type is implemented as a "List" in the schema. Zisiadis, et al. Expires March 20, 2011 [Page 8] Internet-Draft NTTDM December 2010 2.2 Types and Definitions for the VALID FORMAT attributes 2.2.1 Predefined String A Predefined String means the different values are predefined in the data model. Each field that requires a Predefined String contains a specific value. Here is the table that shows the allowed values for such fields. +------------------------+-----------------------------------+ | FIELD NAME | VALUES | +------------------------+-----------------------------------+ | TT_TYPE | Operational, Informational, | | | Administrative, Test | +------------------------+-----------------------------------+ | TYPE | Scheduled, Unscheduled | +------------------------+-----------------------------------+ | TT_PRIORITY | Low, Medium, High | +------------------------+-----------------------------------+ | TT_SHORT_DESCRIPTION | Core Line Fault, Access Line | | | Fault, Degraded Service, Router | | | Hardware Fault, Router Software | | | Fault, Routing Problem, Undefined | | | Problem, Network congestion, | | | Client Upgrade, IPv6, QoS, VoIP, | | | Other | +------------------------+-----------------------------------+ | TT_IMPACT_ASSESSMENT | No impact, Reduced redundancy, | | | Minor performance impact, Severe | | | performance impact, | | | No connectivity, On backup, | | | At risk, Unknown | +------------------------+-----------------------------------+ | TT_STATUS | Opened, Updated, Closed, Solved, | | | Inactive, Cancelled, Reopened, | | | Superseded, Opened/Closed | +------------------------+-----------------------------------+ | TT_SOURCE | Users, Monitoring, Other NOC | +------------------------+-----------------------------------+ Figure 1: The allowed Predefined String values Zisiadis, et al. Expires March 20, 2011 [Page 9] Internet-Draft NTTDM December 2010 The Predefined String data type is implemented as an "xs:string" in the schema with a sequence of enumerations for the allowed values. 2.2.1.1 Definitions of the Predefined Values TT_TYPE o Operational: for network incident & maintenance only. o Informational: Information about the TT system or the exchange interface (maintenance, upgrade). o Administrative: Information about the access to the TTS (credentials) or the exchange interface. o Test: to test the TT system or the exchange interface, etc. TYPE o Scheduled: the incident was scheduled to happen. o Unscheduled: the incident was unscheduled. TT_PRIORITY o Low: the TT priority is low. o Medium: the TT priority is medium. o High: the TT priority is high. TT_SHORT_DESCRIPTION o Core Line Fault: malfunction of a high bandwidth Core line. o Access Line Fault: malfunction of a medium bandwidth Access line. o Degraded Service. o Router Hardware Fault: malfunction of the router hardware. Zisiadis, et al. Expires March 20, 2011 [Page 10] Internet-Draft NTTDM December 2010 o Router Software Fault: malfunction of the router software. o Routing Problem: incident regarding the routing service. o Undefined Problem: the nature of the problem is not identified. o Network congestion: problem due to traffic at the network (blocked). o Client Upgrade: incidents regarding clients/services upgrade. o IPv6: incident regarding the IPv6 network. o QoS: incident regarding the QoS of the network. o VoIP: incident regarding VoIP. o Other: non listed incident. TT_IMPACT_ASSESSMENT o No impact: the incident does not cause any impacts. o Reduced redundancy: the incident produces reduction at the redundancy. o Minor performance impact: the incident causes a minor performance impact. o Severe performance impact: the incident causes a severe performance impact. o No connectivity: the incident causes failure of connectivity. o On backup: the incident produces malfunction on backup services. o At risk: the incident should not have any impact but possibly it may cause some trouble. o Unknown: the nature of the impact is not identified. Zisiadis, et al. Expires March 20, 2011 [Page 11] Internet-Draft NTTDM December 2010 TT_STATUS o Opened: the ticket is opened. o Closed: the ticket is closed. o Updated: the ticket's contents have been updated. o Cancelled: the ticket has been opened twice, one of the both tickets is cancelled and a relation is done between them via RELATED_ACTIVITY. o Solved: the incident is solved but the team prefers to monitor for check. o Opened/closed: stands for tickets that are opened only to report an incident that is already solved. o Inactive: the ticket is under the responsibility of an external domain and is no more under the domain control. o Reopened: the ticket was closed by error, or the problem was faulty declared solved. Historical data are very important at this case. o Superseded: the ticket has been superseded by another one (case of a bigger problem having raised many tickets and being merged in one single incident). The RELATED_ACTIVITY field should include the master ticket reference. Allowed transitions for TT_STATUS are only those following. Possible final states are indicated with (X). Zisiadis, et al. Expires March 20, 2011 [Page 12] Internet-Draft NTTDM December 2010 +------------------+ | Opened/Closed (X)| +------------------+ | | V +--------------+ /-----------------------| Reopened |<-------------------\ | | |----------\ | | +--------------+ | | | ^ | | | | | | | V | | | +-------------------+ | | | | Superseded (X) | | | | | or Inactive (X) | | | | /----------------->| or Cancelled (X) |<---\ | | | | +-------------------+ | | | | | ^ | | | | | | | V | | | +--------+ | +--------+ | | | /---------| Opened |----/ | Solved |-----\ | | | | | |---------------->| | | | | | | +--------+ +--------+ | | | | | | ^ | | V | V | | | | +---------+ | | | | | |----------(|)-------------------------/ V V | Updated | | +------------+ | |----------(|)---------------------------->| | +---------+ | | Closed (X) | \----------------------------->| | +------------+ Figure 2: TT_STATUS transition diagram 2.2.2 String The String value is defined by the user of the model. The String data type is implemented as an "xs:string" in the schema. Zisiadis, et al. Expires March 20, 2011 [Page 13] Internet-Draft NTTDM December 2010 2.2.3 Datetime Date-time strings are represented by the Datetime data type. Each date-time string identifies a particular instant in time; ranges are not supported. Date-time strings are formatted according to a subset of ISO 8601: 2000 documented in RFC 3339. The Datetime data type is implemented as an "xs:dateTime" in the schema. 3. NTTDM In this section, the individual components of NTTDM will be discussed in detail. This class provides a standardized representation for commonly exchanged Field Name data. 3.1 NTTDM Components 3.1.1 NTTDM Attributes The Field Name class has four attributes. Each attribute provides information about a Field Name instance. The attributes that characterize one instance constitute all the information required to form the data model. DESCRIPTION This field contains a short description of the field name. TYPE The TYPE attribute contains information about the type of the field name it depends on. The values that it may contain are: Defined, Free, Multiple, List. VALID FORMAT This attribute contains information about the format of each field. The values that it may contain are: Predefined String, String, Datetime. Zisiadis, et al. Expires March 20, 2011 [Page 14] Internet-Draft NTTDM December 2010 MANDATORY This attribute indicates if the information of each field is required or is optional. In case the information is required the field MANDATORY contains the word: "YES". On the contrary, when filling the information is optional, the field MANDATORY contains the word "NO". 3.2 NTTDM Aggregate Classes 3.2.1 NTTDM-Document class The NTTDM-Document class is the top-level class in NTTDM. All NTTDM documents are an instance of this class. +---------------+ | NTTDM-Document| +---------------+ | version |<>--{1..*}--[ Ticket ] | lang | +---------------+ Figure 3: NTTDM-Document class The aggregate class that constitutes NTTDM-Document is: Ticket One or more. The information related to a single ticket. The NTTDM-Document class has two attributes: version STRING. The value of this attribute MUST be "1.00" lang Required. 3.2.2 Ticket class Every ticket is represented by an instance of the Ticket class. This class provides a standardized representation for commonly exchanged TT data. Zisiadis, et al. Expires March 20, 2011 [Page 15] Internet-Draft NTTDM December 2010 +---------+ | Ticket | +---------+ | lang |<>----------[ Partner_ID ] | |<>----------[ Original_ID ] | |<>----------[ TT_ID ] | |<>----------[ TT_Title ] | |<>----------[ TT_Type ] | |<>--{0..1}--[ TT_Priority ] | |<>----------[ TT_Status ] | |<>--{0..1}--[ TT_Source ] | |<>----------[ TT_Open_Datetime ] | |<>----------[ TT_Close_Datetime ] | |<>----------[ TT_Short_Description ] | |<>----------[ TT_Long_Description ] | |<>----------[ Type ] | |<>----------[ TT_Impact_Assessment ] | |<>----------[ Start_Datetime ] | |<>--{0..1}--[ Detect_Datetime ] | |<>--{0..1}--[ Report_Datetime ] | |<>----------[ End_Datetime ] | |<>----------[ TT_Last_Update_Time ] | |<>--{0..1}--[ Time_Window_Start ] | |<>--{0..1}--[ Time_Window_End ] | |<>--{0..1}--[ Work_Plan_Start_Datetime ] | |<>--{0..1}--[ Work_Plan_End_Datetime ] | |<>--{0..1}--[ Related_External_Tickets ] | |<>--{0..1}--[ Additional_Data ] | |<>--{0..1}--[ Related_Activity ] | |<>----------[ History ] | |<>--{0..1}--[ Affected_Community ] | |<>--{0..1}--[ Affected_Service ] | |<>----------[ Location ] | |<>--{0..1}--[ Network_Node ] | |<>--{0..1}--[ Network_Link_Circuit ] | |<>--{0..1}--[ End_Line_Location_A ] | |<>--{0..1}--[ End_Line_Location_B ] | |<>--{0..1}--[ Open_Engineer ] | |<>--{0..1}--[ Contact_Engineers ] | |<>--{0..1}--[ Close_Engineer ] | |<>--{0..1}--[ Hash ] +---------+ Figure 4: the Ticket class Zisiadis, et al. Expires March 20, 2011 [Page 16] Internet-Draft NTTDM December 2010 lang Required. The Field Names are the Aggregate Classes that constitute the NTTDM and each of them is an element that is characterized by a quadruple (DESCRIPTION, TYPE, VALID FORMAT, MANDATORY). 3.2.3 Ticket origin information 3.2.3.1 PARTNER_ID +--------------+ | PARTNER_ID | +--------------+ | DESCRIPTION | The unique ID of the TT source partner. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | Yes. +--------------+ Figure 5: Partner_ID Class 3.2.3.2 ORIGINAL_ID +--------------+ | ORIGINAL_ID | +--------------+ | DESCRIPTION | TT ID that was assigned by the party. | TYPE | Free. | VALID FORMAT | String. | MANDATORY | Yes. +--------------+ Figure 6: Original_ID Class 3.2.4 Ticket information Zisiadis, et al. Expires March 20, 2011 [Page 17] Internet-Draft NTTDM December 2010 3.2.4.1 TT_ID +--------------+ | TT_ID | +--------------+ | DESCRIPTION | The unique ID of the TT. | TYPE | As defined below. | VALID FORMAT | String. | MANDATORY | Yes. +--------------+ Figure 7: TT_ID Class TYPE is constructed as "PARTNER_ID"_"ORIGINAL_ID". PARTNER_ID and ORIGINAL_ID MUST therefore not contain an underscore character. 3.2.4.2 TT_TITLE +---------------+ | TT_TITLE | +---------------+ | DESCRIPTION | The title of the TT. | TYPE | DEFINED. | VALID FORMAT | String. | MANDATORY | Yes. +---------------+ Figure 8: TT_Title Class 3.2.4.3 TT_TYPE +---------------+ | TT_TYPE | +---------------+ | DESCRIPTION | The type of the TT. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | Yes +---------------+ Figure 9: Type Class Zisiadis, et al. Expires March 20, 2011 [Page 18] Internet-Draft NTTDM December 2010 3.2.4.4 TT_PRIORITY +--------------+ | TT_PRIORITY | +--------------+ | DESCRIPTION | The TT priority. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | No. +--------------+ Figure 10: TT_Priority Class 3.2.4.5 TT_STATUS +--------------+ | TT_STATUS | +--------------+ | DESCRIPTION | The TT status. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | Yes. +--------------+ Figure 11: TT_Status Class 3.2.4.6 TT_SOURCE +--------------+ | TT_SOURCE | +--------------+ | DESCRIPTION | The source of the ticket. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | No. +--------------+ Figure 12: TT_Source Class Zisiadis, et al. Expires March 20, 2011 [Page 19] Internet-Draft NTTDM December 2010 3.2.4.7 TT_OPEN_DATETIME +------------------+ | TT_OPEN_DATETIME | +------------------+ | DESCRIPTION | The datetime when the TT was opened. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | Yes. +------------------+ Figure 13: TT_Open_Datetime Class 3.2.4.8 TT_CLOSE_DATETIME +-------------------+ | TT_CLOSE_DATETIME | +-------------------+ | DESCRIPTION | The datetime when the TT was closed. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | Yes. +-------------------+ Figure 14: TT_Close_Datetime Class 3.2.5 Trouble details 3.2.5.1 TT_SHORT_DESCRIPTION +----------------------+ | TT_SHORT_DESCRIPTION | +----------------------+ | DESCRIPTION | The short description of the trouble. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | Yes. +----------------------+ Figure 15: TT_Short_Description Class Zisiadis, et al. Expires March 20, 2011 [Page 20] Internet-Draft NTTDM December 2010 3.2.5.2 TT_LONG_DESCRIPTION +---------------------+ | TT_LONG_DESCRIPTION | +---------------------+ | DESCRIPTION | The detailed description of the | | incident/maintenance reported in the TT. | TYPE | Free. | VALID FORMAT | String. | MANDATORY | Yes. +---------------------+ Figure 16: TT_Long_Description Class 3.2.5.3 TYPE +--------------+ | TYPE | +--------------+ | DESCRIPTION | The type of the trouble. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | Yes. +--------------+ Figure 17: Type Class 3.2.5.4 TT_IMPACT_ASSESSMENT +----------------------+ | TT_IMPACT_ASSESSMENT | +----------------------+ | DESCRIPTION | The impact of the incident/maintenance. | TYPE | Multiple. | VALID FORMAT | Predefined String. | MANDATORY | Yes. +----------------------+ Figure 18: TT_Impact_Assessement Class Zisiadis, et al. Expires March 20, 2011 [Page 21] Internet-Draft NTTDM December 2010 3.2.5.5 START_DATETIME +----------------+ | START_DATETIME | +----------------+ | DESCRIPTION | The datetime that the | | incident/maintenance started. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | Yes. +----------------+ Figure 19: Start_Datetime Class 3.2.5.6 DETECT_DATETIME +-------------------+ | DETECT_DATETIME | +-------------------+ | DESCRIPTION | The datetime when the incident was detected. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | No. +-------------------+ Figure 20: Detect_Datetime Class 3.2.5.7 REPORT_DATETIME +-----------------+ | REPORT_DATETIME | +-----------------+ | DESCRIPTION | The datetime when the incident was reported. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | No. +-----------------+ Figure 21: Report_Datetime Class Zisiadis, et al. Expires March 20, 2011 [Page 22] Internet-Draft NTTDM December 2010 3.2.5.8 END_DATETIME +--------------+ | END_DATETIME | +--------------+ | DESCRIPTION | The datetime when the incident/maintenance ended. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | Yes. +--------------+ Figure 22: End_Datetime Class 3.2.5.9 TT_LAST_UPDATE_TIME +---------------------+ | TT_LAST_UPDATE_TIME | +---------------------+ | DESCRIPTION | The last datetime when the TT was updated. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | Yes. +---------------------+ Figure 23: TT_Last_Update_Time Class 3.2.5.10 TIME_WINDOW_START +-------------------+ | TIME_WINDOW_START | +-------------------+ | DESCRIPTION | The window start time in which planned | | maintenance may occur. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | No, unless TYPE is "Scheduled". +-------------------+ Figure 24: Time_Window_Start Class Zisiadis, et al. Expires March 20, 2011 [Page 23] Internet-Draft NTTDM December 2010 3.2.5.11 TIME_WINDOW_END +-----------------+ | TIME_WINDOW_END | +-----------------+ | DESCRIPTION | The window end time in which planned | | maintenance may occur. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | No, unless TYPE is "Scheduled". +-----------------+ Figure 25: Time_Window_End Class 3.2.5.12 WORK_PLAN_START_DATETIME +--------------------------+ | WORK_PLAN_START_DATETIME | +--------------------------+ | DESCRIPTION | Work planned (expected) start time | | in case of maintenance. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | No. +--------------------------+ Figure 26: Work_Plan_Start_Datetime Class 3.2.5.13 WORK_PLAN_END_DATETIME +------------------------+ | WORK_PLAN_END_DATETIME | +------------------------+ | DESCRIPTION | Work planned (expected) end time in case | | of maintenance. | TYPE | Multiple. | VALID FORMAT | Datetime. | MANDATORY | No. +------------------------+ Figure 27: Work_Plan_End_Datetime Class The period delimited by WORK_PLAN_START_DATETIME and WORK_PLAN_END_DATETIME must be included in the period delimited Zisiadis, et al. Expires March 20, 2011 [Page 24] Internet-Draft NTTDM December 2010 by TIME_WINDOW_START and TIME_WINDOW_END, duplicated with {START, END}_DATETIME, even in case of maintenance. 3.2.6 Related data 3.2.6.1 RELATED_EXTERNAL_TICKETS +--------------------------+ | RELATED_EXTERNAL_TICKETS | +--------------------------+ | DESCRIPTION | The NOC entity related to the incident. | TYPE | List. | VALID FORMAT | String. | MANDATORY | No. +--------------------------+ Figure 28: Related_External_Tickets Class 3.2.6.2 ADDITIONAL_DATA +-----------------+ | ADDITIONAL_DATA | +-----------------+ | DESCRIPTION | Additional information. | TYPE | Free. | VALID FORMAT | String. | MANDATORY | No. +-----------------+ Figure 29: Additional_Data Class 3.2.6.3 RELATED_ACTIVITY +------------------+ | RELATED_ACTIVITY | +------------------+ | DESCRIPTION | The trouble TT IDs of the related incidents. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | No. +------------------+ Figure 30: Related_Activity Class Zisiadis, et al. Expires March 20, 2011 [Page 25] Internet-Draft NTTDM December 2010 3.2.6.4 HISTORY +--------------+ | HISTORY | +--------------+ | DESCRIPTION | The necessary Actions/events log. | TYPE | Free. | VALID FORMAT | String. | MANDATORY | Yes. +--------------+ Figure 31: History Class Note: This field must NOT be empty when the VALID FORMAT attribute of the TT_STATUS field is different from "OPENED" or "OPENED/CLOSED". 3.2.7 Localization and Impact 3.2.7.1 AFFECTED_COMMUNITY +--------------------+ | AFFECTED_COMMUNITY | +--------------------+ | DESCRIPTION | Information about the community that was | | affected by the incident. | TYPE | Free. | VALID FORMAT | String. | MANDATORY | No. +--------------------+ Figure 32: Affected_Community Class 3.2.7.2 AFFECTED_SERVICE +------------------+ | AFFECTED_SERVICE | +------------------+ | DESCRIPTION | The service that was affected by the incident. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | No. +------------------+ Figure 33: Affected_Service Class Zisiadis, et al. Expires March 20, 2011 [Page 26] Internet-Draft NTTDM December 2010 3.2.7.3 LOCATION +--------------+ | LOCATION | +--------------+ | DESCRIPTION | Location (Pop site, city, etc) of the | | incident/maintenance. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | Yes. +--------------+ Figure 34: Location Class 3.2.7.4 NETWORK_NODE +--------------+ | NETWORK_NODE | +--------------+ | DESCRIPTION | The NOC network node related to the incident. | TYPE | List. | VALID FORMAT | String. | MANDATORY | No. +--------------+ Figure 35: Network_Node Class 3.2.7.5 NETWORK_LINK_CIRCUIT +----------------------+ | NETWORK_LINK_CIRCUIT | +----------------------+ | DESCRIPTION | Name of the network line related to the | | incident. | TYPE | List. | VALID FORMAT | String. | MANDATORY | No. +----------------------+ Figure 36: Network_Link_Circuit Class Zisiadis, et al. Expires March 20, 2011 [Page 27] Internet-Draft NTTDM December 2010 3.2.7.6 END_LINE_LOCATION_A +---------------------+ | END_LINE_LOCATION_A | +---------------------+ | DESCRIPTION | A-end of the link. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | No. +---------------------+ Figure 37: End_Line_Location_A Class 3.2.7.7 END_LINE_LOCATION_B +---------------------+ | END_LINE_LOCATION_B | +---------------------+ | DESCRIPTION | B-end of the link. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | No. +---------------------+ Figure 38: End_Line_Location_B Class 3.2.8 Contact information 3.2.8.1 OPEN_ENGINEER +---------------+ | OPEN_ENGINEER | +---------------+ | DESCRIPTION | The engineer that opened the ticket. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | No. +---------------+ Figure 39: Open_Engineer Class Zisiadis, et al. Expires March 20, 2011 [Page 28] Internet-Draft NTTDM December 2010 3.2.8.2 CONTACT_ENGINEERS +-------------------+ | CONTACT_ENGINEERS | +-------------------+ | DESCRIPTION | The engineers responsible for the incident | | settlement. | TYPE | List. | VALID FORMAT | String. | MANDATORY | No. +-------------------+ Figure 40: Contact_Engineers Class 3.2.8.3 CLOSE_ENGINEER +----------------+ | CLOSE_ENGINEER | +----------------+ | DESCRIPTION | The engineer that closed the ticket. | TYPE | Multiple. | VALID FORMAT | String. | MANDATORY | No. +----------------+ Figure 41: Close_Engineer Class 3.2.9 Security 3.2.9.1 HASH +-------------+ | HASH | +-------------+ | DESCRIPTION | Encrypted message hash. | TYPE | DEFINED. | VALID FORMAT| String. | MANDATORY | No. +-------------+ Figure 42: Hash Class Zisiadis, et al. Expires March 20, 2011 [Page 29] Internet-Draft NTTDM December 2010 3.3 NTTDM Representation The collected and processed TTs received from multiple telecommunications networks are adjusted in a normalized NTTDM. Below, there is the representation of this normalized Data Model. The "DESCRIPTION" attribute is implied. Zisiadis, et al. Expires March 20, 2011 [Page 30] Internet-Draft NTTDM December 2010 +------------------------+--------+------------------+---------+ | FIELD NAME | TYPE |VALID FORMAT |MANDATORY| +------------------------+--------+------------------+---------+ |PARTNER_ID |MULTIPLE|STRING |YES | |ORIGINAL_ID |FREE |STRING |YES | |TT_ID |DEFINED |STRING |YES | |TT_TITLE |DEFINED |STRING |YES | |TT_TYPE |MULTIPLE|PREDEFINED STRING |YES | |TT_PRIORITY |MULTIPLE|PREDEFINED STRING |NO | |TT_STATUS |MULTIPLE|PREDEFINED STRING |YES | |TT_SOURCE |MULTIPLE|STRING |NO | |TT_OPEN_DATETIME |MULTIPLE|DATETIME |YES | |TT_CLOSE_DATETIME |MULTIPLE|DATETIME |YES | |TT_SHORT_DESCRIPTION |MULTIPLE|PREDEFINED STRING |YES | |TT_LONG_DESCRIPTION |FREE |STRING |NO | |TYPE |MULTIPLE|PREDEFINED STRING |YES | |TT_IMPACT_ASSESSMENT |MULTIPLE|PREDEFINED STRING |YES | |START_DATETIME |MULTIPLE|DATETIME |YES | |DETECT_DATETIME |MULTIPLE|DATETIME |NO | |REPORT_DATETIME |MULTIPLE|DATETIME |NO | |END_DATETIME |MULTIPLE|DATETIME |YES | |TT_LAST_UPDATE_TIME |MULTIPLE|DATETIME |YES | |TIME_WINDOW_START |MULTIPLE|DATETIME |NO | |TIME_WINDOW_END |MULTIPLE|DATETIME |NO | |WORK_PLAN_START_DATETIME|MULTIPLE|DATETIME |NO | |WORK_PLAN_END_DATETIME |MULTIPLE|DATETIME |NO | |RELATED_EXTERNAL_TICKETS|LIST |STRING |NO | |ADDITIONAL_DATA |FREE |STRING |NO | |RELATED_ACTIVITY |MULTIPLE|STRING |NO | |HISTORY |FREE |STRING |YES | |AFFECTED_COMMUNITY |FREE |STRING |NO | |AFFECTED_SERVICE |MULTIPLE|STRING |NO | |LOCATION |MULTIPLE|STRING |YES | |NETWORK_NODE |LIST |STRING |NO | |NETWORK_LINK_CIRCUIT |LIST |STRING |NO | |END_LINE_LOCATION_A |MULTIPLE|STRING |NO | |END_LINE_LOCATION_B |MULTIPLE|STRING |NO | |OPEN_ENGINEER |MULTIPLE|STRING |NO | |CONTACT_ENGINEERS |LIST |STRING |NO | |CLOSE_ENGINEER |MULTIPLE|STRING |NO | |HASH |DEFINED |STRING |NO | +------------------------+--------+------------------+---------+ Figure 43: the Field Name class Zisiadis, et al. Expires March 20, 2011 [Page 31] Internet-Draft NTTDM December 2010 4. Internationalization Issues Internationalization and localization is of specific concern to the NTTDM, since it is only through collaboration, often across language barriers, that certain incidents be resolved. The NTTDM supports this goal by depending on XML constructs, and through explicit design choices in the data model. The main advantage of the model is that it provides a normalized data type that is implemented fully in the English language and can be used conveniently. It also supports Free formed text that can be written in any language. In the future it will provide translation services for all the free-formed text. 5. Example 5.1 Link Failure In this section an example is provided of network TTs exchanged using the proposed format. This is an actual GRNet ticket normalized according to TTDM. Fields that were not included in the ticket are left blank. 5985 01 01_5985 Forth Link Failure Operational Closed 2008-12-16T10:01:15+02:00 Core Line Fault Forth Link Failure Unscheduled No connectivity 2008-12-16T09:55:00+02:00 2008-12-16T15:00:34+02:00 HERAKLION Optical transmitter was changed 2008-12-16T15:05:00+02:00 Zisiadis, et al. Expires March 20, 2011 [Page 32] Internet-Draft NTTDM December 2010 2008-12-16T15:01:21+02:00 FORTH FORTH-2 Dimitris Zisiadis Guillaume Cessieux Spyros Kopsidas Chrysostomos Tziouvaras High 6. Sample implementation: XML schema This section provides a sample XML Schema of the NTTDM. Trouble Ticket Data Model v-1.0 Zisiadis, et al. Expires March 20, 2011 [Page 33] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 34] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 35] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 36] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 37] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 38] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 39] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 40] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 41] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 42] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 43] Internet-Draft NTTDM December 2010 Zisiadis, et al. Expires March 20, 2011 [Page 44] Internet-Draft NTTDM December 2010 7. Security Considerations The NTTDM data model defines a data model and the relevant XML schema for trouble ticket normalization; as such, NTTDM itself does not raise any security concerns. However, some security issues SHOULD be considered as network TTs could carry sensitive information (IP addresses, contact details, authentication details, commercial providers involved etc.) about flagship institutions (military, health centre...). The security considerations MAY involve measures during the exchange as well as during processing of the information. The HASH field is intended to provide an integrity insurance attribute within the exchanged tickets, however it does not ensure integrity alone. Confidentiality MAY be ensured by encrypting whole tickets or only some parts. This could allow having meaningful tickets to be disclosed while only sensitive information protected. Peer entity authentication SHOULD be provided in order to establish session with data origin authentication regardless of the form in which the TTs are exchanged, being either delivered through email, web forms or through a SOAP service. The latter is considered the better choice, the model itself though does not specify the communications requirements. The underlying communications service MUST provide guarantees to properly address integrity, confidentiality and peer entity authentication. The selection of the enforcing mechanisms is not in the scope of this document and the choice is up to the implementers. For data processing security each participating organization MAY use its own privacy policy, as part of its own data processing system. This approach avoids any interoperability issues and does not pose any extra burden for the adoption of the current scheme into the operational procedures of the NOCs. Unauthorized and inappropriate usage MUST be avoided. Zisiadis, et al. Expires March 20, 2011 [Page 45] Internet-Draft NTTDM December 2010 8. IANA Considerations This document uses URNs to describe an XML namespace and schema conforming to a registry mechanism described in [6]. Registration for the NTTDM namespace: o URI: urn:ietf:params:xml:ns:nttdm-1.0 o Registrant Contact: See the first author of the "Author's Address" section of this document. o XML: None. Namespace URIs do not represent an XML specification. Registration for the NTTDM XML schema: o URI: urn:ietf:params:xml:schema:nttdm-1.0 o Registrant Contact: See the first author of the "Author's Address" section of this document. o XML: See the XML Schema in Section 6 of this document. Zisiadis, et al. Expires March 20, 2011 [Page 46] Internet-Draft NTTDM December 2010 9. Acknowledgements The following groups and individuals contributed substantially to this document and are gratefully acknowledged: - Rodwell Toby, Apted Emma, DANTE - Allocchio Claudio, Vuagnin Gloria, Battista Claudia, GARR - Schauerhammer Karin, Stoy Robert, DFN Zisiadis, et al. Expires March 20, 2011 [Page 47] Internet-Draft NTTDM December 2010 10. List of acronyms TT: Trouble Ticket NTTDM: Network Trouble Ticket Data Model DB: Data Base EGEE: Enabling Grid for E-sciencE ENOC: EGEE NOC NOC: Network Operation Centre GOC: Grid Operation Centre NREN: National Research and Educational Networks QoS: Quality of service UML: Unified Modeling Language XML: Extensible Markup Language Zisiadis, et al. Expires March 20, 2011 [Page 48] Internet-Draft NTTDM December 2010 11. References 11.1 Normative References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, 26 November 2008, . [2] World Wide Web Consortium, XML Schema Part 0: Primer Second Edition, W3C Recommendation, 28 October 2004. [3] World Wide Web Consortium, "XML XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004, . [4] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, . [5] World Wide Web Consortium, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation, 8 December 2009, . [6] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 11.2 Informative References [7] http://www.eu-egee.org/ [8] http://egee-sa2.web.cern.ch/egee-sa2/ENOC.html [9] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling Language Reference Model," ISBN 020130998X, Addison-Wesley, 1998. [10] Johnson, D., "NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT Requirements")", RFC 1297, January 1992. Zisiadis, et al. Expires March 20, 2011 [Page 49] Internet-Draft NTTDM December 2010 12. Authors' Addresses Dimitris Zisiadis Centre for Research and Technology 6th km Thermi-Thessaloniki, 57001 Hellas Email: dzisiadis@iti.gr Spyros Kopsidas Centre for Research and Technology 6th km Thermi-Thessaloniki, 57001 Hellas Email: spyros@uth.gr Matina Tsavli Centre for Research and Technology 6th km Thermi-Thessaloniki, 57001 Hellas Email: sttsavli@uth.gr Leandros Tassiulas Centre for Research and Technology 6th km Thermi-Thessaloniki, 57001 Hellas Email: leandros@uth.gr Chrysostomos Tziouvaras Greek Research and Technology Network 56, Mesogion Av. 11527, Athens Hellas Email: tziou@grnet.gr Zisiadis, et al. Expires March 20, 2011 [Page 50] Internet-Draft NTTDM December 2010 Guillaume Cessieux Computer Centre of National Institute for Nuclear Physics and Particle Physics (IN2P3-CC) - France Email: Guillaume.Cessieux@cc.in2p3.fr Xavier Jeannin National Centre for Scientific Research Network Unit - UREC - France Email: Xavier.Jeannin@urec.cnrs.fr Zisiadis, et al. Expires March 20, 2011 [Page 51]