Network Working Group Dimitris Zisiadis
Internet-Draft Spyros Kopsidas
Intended status: Experimental Track Matina Tsavli
Expires: March 27, 2010 Leandros Tassiulas
CERTH
Chrysostomos Tziouvaras
GRNET
Guillaume Cessieux
Xavier Jeannin
CNRS
September 23, 2009
The Network Trouble Ticket Data Model
draft-dzis-nwg-nttdm-01.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 27, 2010.
Zisiadis, et al. Expires March 27, 2010 [Page 1]
Internet-Draft NTTDM September 2009
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
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 for presentation and storing at the
central NOC is mandatory. 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 ............................................. 4
1.1. Terminology ........................................... 5
1.2. Notations ............................................. 5
1.3. About the Network Trouble Ticket Data Model ........... 6
1.4. About the Network Trouble Ticket Implementation ....... 6
2. NTTDM Types and Definitions .............................. 7
Zisiadis, et al. Expires March 27, 2010 [Page 2]
Internet-Draft NTTDM September 2009
2.1 Types and Definitions for the TYPE Attributes .......... 7
2.1.1 Defined ............................................ 7
2.1.2 Free ............................................... 7
2.1.3 Multiple ........................................... 7
2.1.4 List ............................................... 7
2.2 Types and Definitions for the VALID FORMAT Attributes .. 8
2.2.1 Predefined String .................................. 8
2.2.1.1 Definitions of the Predefined Values ........... 9
2.2.2 String ............................................ 12
2.2.3 Datetime .......................................... 12
3. NTTDM ................................................... 12
3.1 NTTDM components ...................................... 12
3.1.1 NTTDM Attributes .................................. 12
3.2 NTTDM Aggregate classes .............................. 13
3.2.1 NTTDM-Document class .............................. 13
3.2.2 Ticket class ...................................... 13
3.2.3 Ticket origin information ......................... 15
3.2.3.1 PARTNER_ID .................................... 15
3.2.3.2 ORIGINAL_ID ................................... 15
3.2.4 Ticket information ................................ 16
3.2.4.1 TT_ID ......................................... 16
3.2.4.2 TT_TITLE ...................................... 16
3.2.4.3 TT_TYPE ....................................... 17
3.2.4.4 TT_PRIORITY ................................... 17
3.2.4.5 TT_STATUS ..................................... 18
3.2.4.6 TT_SOURCE ..................................... 18
3.2.4.7 TT_OPEN_DATETIME .............................. 19
3.2.4.8 TT_CLOSE_DATETIME ............................. 19
3.2.5 Trouble details ................................... 20
3.2.5.1 TT_SHORT_DESCRIPTION .......................... 20
3.2.5.2 TT_LONG_DESCRIPTION ........................... 20
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 ............................... 23
3.2.5.8 END_DATETIME .................................. 23
3.2.5.9 TT_LAST_UPDATE_TIME ........................... 24
3.2.5.10 TIME_WINDOW_START ............................ 24
3.2.5.11 TIME_WINDOW_END .............................. 25
3.2.5.12 WORK_PLAN_START_DATETIME ..................... 25
3.2.5.13 WORK_PLAN_END_DATETIME ....................... 26
3.2.6 Related data ...................................... 26
3.2.6.1 RELATED_EXTERNAL_TICKETS ...................... 26
3.2.6.2 ADDITIONAL_DATA ............................... 27
3.2.6.3 RELATED_ACTIVITY .............................. 26
3.2.6.4 HISTORY ....................................... 28
Zisiadis, et al. Expires March 27, 2010 [Page 3]
Internet-Draft NTTDM September 2009
3.2.7 Localization and impact ........................... 28
3.2.7.1 AFFECTED_COMMUNITY ............................ 28
3.2.7.2 AFFECTED_SERVICE .............................. 29
3.2.7.3 LOCATION ...................................... 29
3.2.7.4 NETWORK_NODE .................................. 30
3.2.7.5 NETWORK_LINK_CIRCUIT .......................... 30
3.2.7.6 END_LINE_LOCATION_A ........................... 31
3.2.7.7 END_LINE_LOCATION_B ........................... 31
3.2.8 Contact information ............................... 32
3.2.8.1 OPEN_ENGINEER ................................. 32
3.2.8.2 CONTACT_ENGINEERS ............................. 32
3.2.8.3 CLOSE_ENGINEER ................................ 33
3.2.9 Security .......................................... 33
3.2.9.1 HASH .......................................... 33
3.3 NTTDM Representation .................................. 33
4. Internationalization Issues ............................. 35
5. Examples ................................................ 35
5.1 Link Failure .......................................... 35
6. Sample Implementaion: XML Schema ........................ 36
7. Security Considerations ................................. 58
8. Acknowledgements ........................................ 58
9. IANA Considerations ...................................... 58
10. List of Acronyms ....................................... 59
11. References ............................................. 60
12. Authors' Addresses ..................................... 61
Zisiadis, et al. Expires March 27, 2010 [Page 4]
Internet-Draft NTTDM September 2009
1. Introduction
Modern telecommunications networks are aimed to provide a
plethora of differentiated services to theirs customers.
Networks are becoming more sophisticated by the day, while
their offering spans a wide variety of customer types and
services. Quality of Service (QoS) [2] and Service Level
Agreement (SLA) [3] provisioning are fundamental ingredients.
Multiple interconnected institutions spread over different
countries, targeting a common approach to service offering,
along with a unified network operation scheme to support these
services, form Grid networks. Network Management is crucial for
the success of the Grid. 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 the Grid.
The current work evolved within the specific Service Activity 2
(SA2 - network support) of the European funded EGEE [1] project.
A central NOC, called the ENOC (EGEE Network Operating Centre) [4]
is responsible for collecting and handling multiple network TTs
received by the participating network providers' TT systems.
Different TT systems are used by each of them, delivering TTs
in alternate formats, while TT load is growing proportionally
with the network size and the serviced users. TT normalization,
i.e. transformation to a common format that is "reasonable" for
all parties and copes with service demands in a dynamic and
effective way, is of crucial importance for successful
management of the Grid.
In the present work we define a data model for TT normalization
initially targeted for networking providers serving EGEE. The
model is designed in accordance with RFC 1297 [11] and the
specific needs of the participants, 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 as it allows other 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.
Zisiadis, et al. Expires March 27, 2010 [Page 5]
Internet-Draft NTTDM September 2009
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 cognisance by modelling 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.
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) [5] 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 [6, 7, 8, 9].
A specific namespace [10] 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.
Zisiadis, et al. Expires March 27, 2010 [Page 6]
Internet-Draft NTTDM September 2009
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.
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:
Zisiadis, et al. Expires March 27, 2010 [Page 7]
Internet-Draft NTTDM September 2009
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.)
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 attributes
These types are used to describe the TYPE attributes.
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 27, 2010 [Page 8]
Internet-Draft NTTDM September 2009
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 |
+------------------------+-----------------------------------+
| TT_SOURCE | Users, Monitoring, Other NOC |
+------------------------+-----------------------------------+
Figure 1: The allowed Predefined String values
The Predefined String data type is implemented as an
"xs:string" in the schema with a sequence of enumerations for
the allowed values.
Zisiadis, et al. Expires March 27, 2010 [Page 9]
Internet-Draft NTTDM September 2009
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.
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.
Zisiadis, et al. Expires March 27, 2010 [Page 10]
Internet-Draft NTTDM September 2009
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.
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.
Zisiadis, et al. Expires March 27, 2010 [Page 11]
Internet-Draft NTTDM September 2009
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).
+------------------+
| 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
Zisiadis, et al. Expires March 27, 2010 [Page 12]
Internet-Draft NTTDM September 2009
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.
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 27, 2010 [Page 13]
Internet-Draft NTTDM September 2009
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 constitute 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 27, 2010 [Page 14]
Internet-Draft NTTDM September 2009
+---------+
| Ticket |
+---------+
| lang |<>----------[ Partner_ID ]
| |<>----------[ Original_ID ]
| |<>----------[ TT_ID ]
| |<>----------[ TT_Open_Datetime ]
| |<>----------[ TT_Close_Datetime ]
| |<>----------[ 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 ]
| |<>----------[ TT_Title ]
| |<>----------[ TT_Short_Description ]
| |<>--{0..1}--[ TT_Long_Description ]
| |<>----------[ Type ]
| |<>----------[ TT_Type ]
| |<>----------[ TT_Impact_Assessment ]
| |<>--{0..1}--[ Related_External_Tickets ]
| |<>----------[ 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}--[ TT_Priority ]
| |<>----------[ TT_Status ]
| |<>--{0..1}--[ Additional_Data ]
| |<>--{0..1}--[ Related_Activity ]
| |<>----------[ History ]
| |<>--{0..1}--[ Hash ]
| |<>--{0..1}--[ TT_Source ]
| |<>--{0..1}--[ Affected_Community ]
| |<>--{0..1}--[ Affected_Service ]
+---------+
Figure 4: the Ticket class
lang
Required.
Zisiadis, et al. Expires March 27, 2010 [Page 15]
Internet-Draft NTTDM September 2009
The Field Names are the Aggregate Classes that constitute the
NTTDM and each of them is an element that is characterized by a
quadrupel (DESCRIPTION, TYPE, VALID FORMAT, MANDATORY).
3.2.3 Ticket origin information
3.2.3.1 PARTNER_ID
+--------------+
| PARTNER_ID |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 5: Partner_ID Class
DESCRIPTION: This field contains the unique ID of the TT source
partner.
TYPE: This attribute contains a MULTIPLE value.
VALID FORMAT: This attribute contains a STRING value.
MANDATORY: YES. This information is required.
3.2.3.2 ORIGINAL_ID
+--------------+
| ORIGINAL_ID |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 6: Original_ID Class
DESCRIPTION: This field contains the TT ID that was assigned by the party.
TYPE: This attribute contains a Free value.
VALID FORMAT: This attribute contains a String value.
Zisiadis, et al. Expires March 27, 2010 [Page 16]
Internet-Draft NTTDM September 2009
MANDATORY: YES. This information is required.
3.2.4 Ticket information
3.2.4.1 TT_ID
+--------------+
| TT_ID |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 7: TT_ID Class
DESCRIPTION: This field contains contains the unique ID of the
TT.
TYPE: It is built the following way "PARTNER_ID"_"ORIGINAL_ID".
PARTNER_ID and ORIGINAL_ID MUST therefore not
contain an underscore character.
VALID FORMAT: This attribute contains a String value.
MANDATORY: YES. This information is required.
3.2.4.2 TT_TITLE
+---------------+
| TT_TITLE |
+---------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------+
Figure 8: TT_Title Class
DESCRIPTION: The title of the TT.
TYPE: This attribute contains a Defined value.
VALID FORMAT: This attribute contains a String value.
Zisiadis, et al. Expires March 27, 2010 [Page 17]
Internet-Draft NTTDM September 2009
MANDATORY: YES. This information is required.
3.2.4.3 TT_TYPE
+---------------+
| TT_TYPE |
+---------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------+
Figure 9: Type Class
DESCRIPTION: The type of the TT.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: YES. This information is required.
3.2.4.4 TT_PRIORITY
+--------------+
| TT_PRIORITY |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 10: TT_Priority Class
DESCRIPTION: The TT priority.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 18]
Internet-Draft NTTDM September 2009
3.2.4.5 TT_STATUS
+--------------+
| TT_STATUS |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 11: TT_Status Class
DESCRIPTION: The TT status.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: Yes. This information is required.
3.2.4.6 TT_SOURCE
+--------------+
| TT_SOURCE |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 12: TT_Source Class
DESCRIPTION: The source of the ticket.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 19]
Internet-Draft NTTDM September 2009
3.2.4.7 TT_OPEN_DATETIME
+------------------+
| TT_OPEN_DATETIME |
+------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+------------------+
Figure 13: TT_Open_Datetime Class
DESCRIPTION: The datetime that the TT was opened.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: YES. This information is required.
3.2.4.8 TT_CLOSE_DATETIME
+-------------------+
| TT_CLOSE_DATETIME |
+-------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-------------------+
Figure 14: TT_Close_Datetime Class
DESCRIPTION: The datetime that the TT was closed.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: YES. This information is required.
Zisiadis, et al. Expires March 27, 2010 [Page 20]
Internet-Draft NTTDM September 2009
3.2.5 Trouble details
3.2.5.1 TT_SHORT_DESCRIPTION
+----------------------+
| TT_SHORT_DESCRIPTION |
+----------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+----------------------+
Figure 15: TT_Short_Description Class
DESCRIPTION: The short description of the TT.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: YES. This information is required.
3.2.5.2 TT_LONG_DESCRIPTION
+---------------------+
| TT_LONG_DESCRIPTION |
+---------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------------+
Figure 16: TT_Long_Description Class
DESCRIPTION: The detailed description of the
incident/maintenance reported in the TT.
TYPE: This attribute contains a Free value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: YES. This information is required.
Zisiadis, et al. Expires March 27, 2010 [Page 21]
Internet-Draft NTTDM September 2009
3.2.5.3 TYPE
+--------------+
| TYPE |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 17: Type Class
DESCRIPTION: The type of the trouble.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: YES. This information is required.
3.2.5.4 TT_IMPACT_ASSESSMENT
+----------------------+
| TT_IMPACT_ASSESSMENT |
+----------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+----------------------+
Figure 18: TT_Impact_Assessement Class
DESCRIPTION: The impact of the incident/maintenance.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Predefined String
value.
MANDATORY: YES. This information is required.
Zisiadis, et al. Expires March 27, 2010 [Page 22]
Internet-Draft NTTDM September 2009
3.2.5.5 START_DATETIME
+----------------+
| START_DATETIME |
+----------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+----------------+
Figure 19: Start_Datetime Class
DESCRIPTION: The datetime that the incident/maintenance
started.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: YES. This information is required.
3.2.5.6 DETECT_DATETIME
+-------------------+
| DETECT_DATETIME |
+-------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-------------------+
Figure 20: Detect_Datetime Class
DESCRIPTION: The datetime that the incident was detected.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 23]
Internet-Draft NTTDM September 2009
3.2.5.7 REPORT_DATETIME
+-----------------+
| REPORT_DATETIME |
+-----------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-----------------+
Figure 21: Report_Datetime Class
DESCRIPTION: The datetime that the incident was reported.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: No. This information is optional.
3.2.5.8 END_DATETIME
+--------------+
| END_DATETIME |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 22: End_Datetime Class
DESCRIPTION: The datetime that the incident/maintenance ended.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: YES. This information is required.
Zisiadis, et al. Expires March 27, 2010 [Page 24]
Internet-Draft NTTDM September 2009
3.2.5.9 TT_LAST_UPDATE_TIME
+---------------------+
| TT_LAST_UPDATE_TIME |
+---------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------------+
Figure 23: TT_Last_Update_Time Class
DESCRIPTION: The last datetime that the TT was updated.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: YES. This information is required.
3.2.5.10 TIME_WINDOW_START
+-------------------+
| TIME_WINDOW_START |
+-------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-------------------+
Figure 24: Time_Window_Start Class
DESCRIPTION: The window start time in which planned maintenance
may occur.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: No. This information is optional. However, it is
mandatory if the TYPE element contains the string
"Scheduled".
Zisiadis, et al. Expires March 27, 2010 [Page 25]
Internet-Draft NTTDM September 2009
3.2.5.11 TIME_WINDOW_END
+-----------------+
| TIME_WINDOW_END |
+-----------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-----------------+
Figure 25: Time_Window_End Class
DESCRIPTION: The window end time in which planned maintenance
may occur.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: No. This information is optional. However, it is
mandatory if the TYPE element contains the string
"Scheduled".
3.2.5.12 WORK_PLAN_START_DATETIME
+--------------------------+
| WORK_PLAN_START_DATETIME |
+--------------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------------------+
Figure 26: Work_Plan_Start_Datetime Class
DESCRIPTION: Work planned (expected) start time in case of
maintenance.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 26]
Internet-Draft NTTDM September 2009
3.2.5.13 WORK_PLAN_END_DATETIME
+------------------------+
| WORK_PLAN_END_DATETIME |
+------------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+------------------------+
Figure 27: Work_Plan_End_Datetime Class
DESCRIPTION: Work planned (expected) end time in case of
maintenance.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a Datetime value.
MANDATORY: No. This information is optional.
The period delimited by WORK_PLAN_START_DATETIME and
WORK_PLAN_END_DATETIME must be included in the period delimited
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 |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------------------+
Figure 28: Related_External_Tickets Class
DESCRIPTION: The NOC entity related to the incident.
TYPE: This attribute contains a List value.
VALID FORMAT: This attribute contains a String value.
Zisiadis, et al. Expires March 27, 2010 [Page 27]
Internet-Draft NTTDM September 2009
MANDATORY: No. This information is optional.
3.2.6.2 ADDITIONAL_DATA
+-----------------+
| ADDITIONAL_DATA |
+-----------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-----------------+
Figure 29: Additional_Data Class
DESCRIPTION: Additional information.
TYPE: This attribute contains a Free value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.2.6.3 RELATED_ACTIVITY
+------------------+
| RELATED_ACTIVITY |
+------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+------------------+
Figure 30: Related_Activity Class
DESCRIPTION: The trouble TT IDs of the related incidents.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 28]
Internet-Draft NTTDM September 2009
3.2.6.4 HISTORY
+--------------+
| HISTORY |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 31: History Class
DESCRIPTION: The necessary Actions/events log.
TYPE: This attribute contains a Free value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: Yes. This information is required.
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 |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------------+
Figure 32: Affected_Community Class
DESCRIPTION: Information about the community that was affected
by the trouble incident.
TYPE: This attribute contains a Free value.
VALID FORMAT: This attribute contains a String value.
Zisiadis, et al. Expires March 27, 2010 [Page 29]
Internet-Draft NTTDM September 2009
MANDATORY: No. This information is optional.
3.2.7.2 AFFECTED_SERVICE
+------------------+
| AFFECTED_SERVICE |
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+------------------+
Figure 33: Affected_Service Class
DESCRIPTION: The service that was affected by the trouble
incident.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.2.7.3 LOCATION
+--------------+
| LOCATION |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 34: Location Class
DESCRIPTION: Location (Pop site, city, etc) of the incident/
maintenance.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: YES. This information is required.
Zisiadis, et al. Expires March 27, 2010 [Page 30]
Internet-Draft NTTDM September 2009
3.2.7.4 NETWORK_NODE
+--------------+
| NETWORK_NODE |
+--------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+--------------+
Figure 35: Network_Node Class
DESCRIPTION: The NOC network node related to the incident.
TYPE: This attribute contains a List value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.2.7.5 NETWORK_LINK_CIRCUIT
+----------------------+
| NETWORK_LINK_CIRCUIT |
+----------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+----------------------+
Figure 36: Network_Link_Circuit Class
DESCRIPTION: Name of the network line related to the incident.
TYPE: This attribute contains a List value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 31]
Internet-Draft NTTDM September 2009
3.2.7.6 END_LINE_LOCATION_A
+---------------------+
| END_LINE_LOCATION_A |
+---------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------------+
Figure 37: End_Line_Location_A Class
DESCRIPTION: A-end of the link.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.2.7.7 END_LINE_LOCATION_B
+---------------------+
| END_LINE_LOCATION_B |
+---------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------------+
Figure 38: End_Line_Location_B Class
DESCRIPTION: B-end of the link.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 32]
Internet-Draft NTTDM September 2009
3.2.8 Contact information
3.2.8.1 OPEN_ENGINEER
+---------------+
| OPEN_ENGINEER |
+---------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+---------------+
Figure 39: Open_Engineer Class
DESCRIPTION: The engineer that opened the ticket.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.2.8.2 CONTACT_ENGINEERS
+-------------------+
| CONTACT_ENGINEERS |
+-------------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+-------------------+
Figure 40: Contact_Engineers Class
DESCRIPTION: The engineers responsible for the incident
settlement.
TYPE: This attribute contains a List value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
Zisiadis, et al. Expires March 27, 2010 [Page 33]
Internet-Draft NTTDM September 2009
3.2.8.3 CLOSE_ENGINEER
+----------------+
| CLOSE_ENGINEER |
+----------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT |
| MANDATORY |
+----------------+
Figure 41: Close_Engineer Class
DESCRIPTION: The engineer that closed the ticket.
TYPE: This attribute contains a Multiple value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.2.9 Security
3.2.9.1 HASH
+-------------+
| HASH |
+-------------+
| DESCRIPTION |
| TYPE |
| VALID FORMAT|
| MANDATORY |
+-------------+
Figure 42: Hash Class
DESCRIPTION: Encrypted message hash.
TYPE: This attribute contains a Defined value.
VALID FORMAT: This attribute contains a String value.
MANDATORY: No. This information is optional.
3.3 NTTDM Representation
The collected and processed TTs received from multiple
Zisiadis, et al. Expires March 27, 2010 [Page 34]
Internet-Draft NTTDM September 2009
telecommunications networks are adjusted in a normalized NTTDM.
Below, there is the representation of this normalized Data
Model. The "DESCRIPTION" attribute is implied.
+------------------------+--------+------------------+---------+
| FIELD NAME | TYPE |VALID FORMAT |MANDATORY|
+------------------------+--------+------------------+---------+
|PARTNER_ID |MULTIPLE|STRING |YES |
|ORIGINAL_ID |FREE |STRING |YES |
|TT_ID |DEFINED |STRING |YES |
|TT_OPEN_DATETIME |MULTIPLE|DATETIME |YES |
|TT_CLOSE_DATETIME |MULTIPLE|DATETIME |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 |
|TT_TITLE |DEFINED |STRING |YES |
|TT_SHORT_DESCRIPTION |MULTIPLE|PREDEFINED STRING |YES |
|TT_LONG_DESCRIPTION |FREE |STRING |NO |
|TYPE |MULTIPLE|PREDEFINED STRING |YES |
|TT_TYPE |MULTIPLE|PREDEFINED STRING |YES |
|TT_IMPACT_ASSESSMENT |MULTIPLE|PREDEFINED STRING |YES |
|RELATED_EXTERNAL_TICKETS|LIST |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 |
|TT_PRIORITY |MULTIPLE|PREDEFINED STRING |NO |
|TT_STATUS |MULTIPLE|PREDEFINED STRING |YES |
|ADDITIONAL_DATA |FREE |STRING |NO |
|RELATED_ACTIVITY |MULTIPLE|STRING |NO |
|HISTORY |FREE |STRING |YES |
|HASH |DEFINED |STRING |NO |
|TT_SOURCE |MULTIPLE|STRING |NO |
|AFFECTED_COMMUNITY |FREE |STRING |NO |
|AFFECTED_SERVICE |MULTIPLE|STRING |NO |
+------------------------+--------+------------------+---------+
Figure 43: the Field Name class
Zisiadis, et al. Expires March 27, 2010 [Page 35]
Internet-Draft NTTDM September 2009
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. Examples
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.
Zisiadis, et al. Expires March 27, 2010 [Page 37]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 38]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 39]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 40]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 41]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 42]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 44]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 45]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 46]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 49]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 50]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 51]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 52]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 53]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 54]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 55]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 56]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 57]
Internet-Draft NTTDM September 2009
Zisiadis, et al. Expires March 27, 2010 [Page 58]
Internet-Draft NTTDM September 2009
7. Security Considerations
Some security issues should be kept in mind as network TTs
could carry sensitive information (IP addresses, contact
details, authentication details, commercial providers involved
etc.) about flagship institutions (military, health centre...).
o Integrity: The HASH field is intended to ensure integrity of
received tickets.
o Confidentiality: could be ensured by encrypting whole tickets
or only some parts. This could allow having meaningful
tickets to be disclosed while only sensitive information
protected.
o Peer entity authentication: message sender authentication must
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.
8. IANA Considerations
Nothing is yet appplied.
The following registrations will have to be accomodated at a
latter stage:
o NTTDM namespace: "urn:ietf:params:xml:ns:NTTDM-1.0"
o NTTDM XML Schema: "urn:ietf:params:xml:ns:NTTDM-1.0"
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 27, 2010 [Page 59]
Internet-Draft NTTDM September 2009
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
SLA: Service level Agreement
UML: Unified Modeling Language
XML: Extensible Markup Language
Zisiadis, et al. Expires March 27, 2010 [Page 60]
Internet-Draft NTTDM September 2009
11. References
[1] http://www.eu-egee.org/
[2] http://en.wikipedia.org/wiki/Quality of service
[3] http://en.wikipedia.org/wiki/Service Level Agreement
[4] http://egee-sa2.web.cern.ch/egee-sa2/ENOC.html
[5] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified
Modeling Language Reference Model," ISBN 020130998X,
Addison-Wesley, 1998.
[6] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0 (Second Edition)", W3C Recommendation,
October 2000,
.
[7] XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001.
http://www.w3.org/TR/xmlschema-0/
[8] World Wide Web Consortium, "XML XML Schema Part 1:
Structures Second Edition", W3C Recommendation,
October 2004,
.
[9] World Wide Web Consortium, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation, October 2004,
.
[10] World Wide Web Consortium, "Namespaces in XML", W3C
Recommendation, January 1999,
.
[11] http://www.ietf.org/rfc/rfc1297.txt
Zisiadis, et al. Expires March 27, 2010 [Page 61]
Internet-Draft NTTDM September 2009
12. Authors' Addresses
Dimitris Zisiadis
Centre for Research and Technology
6th km Thermi-Thessaloniki, 57001
Hellas
Email: dimitris@uth.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 27, 2010 [Page 62]
Internet-Draft NTTDM September 2009
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