Apa Bedanya Cloud Server, VPS dan Web Hosting ?

Mungkin anda bingung dengan beberapa istilah tersebut. Atau anda sedang mencari suatu layanan yang tepat untuk kebutuhan bisnis online anda terutama di Indonesia, lalu anda menemukan di mesin pencari berbagai penawaran dengan istilah seperti Cloud Server, VPS dan Web Hosting. Apa bedanya dan bagaimana menyesuaikan dengan kebutuhan anda, bahkan sebaiknya anda berhati-hati jangan hanya karena murah namun akhirnya tidak sesuai dengan kebutuhan yang anda inginkan. Berikut ini adalah penjelasan yang semoga dapat membantu anda lebih memahami istilah dari produk tersebut.

Web Hosting

Web hosting adalah layanan yang menyewakan space untuk aplikasi berbasis web milik anda, dimana anda bisa menggunakan nama domain yang anda miliki untuk diarahkan ke aplikasi tersebut. Biasanya anda diberikan fasilitas manajemen untuk aplikasi anda seperti upload / download file untuk webnya maupun databasenya. Platform yang disediakan bervariasi, biasanya PHP dan database mySQL. Selain itu anda juga umumnya diberikan akun email dengan domain anda oleh penyedia layanan. Layanan ini memiliki harga paling mura. Namun memiliki keterbatasan hanya pada platform yang disediakan. Selain itu umumnya penyedia layanan hanya menyediakan 1 fisik server yang dishare bersama pelanggan lain untuk menekan harga jual. Jadi kualitas layanan juga terbatas dengan kondisi tersebut.

VPS (Virtual Private Server)

VPS adalah layanan yang menyewakan server virtual, bedanya dengan web hosting adalah anda memiliki kebebasan menentukan sistem operasi dan platform yang anda gunakan sehingga anda dapat mengoptimalkan layanan bisnis online anda. Layanan ini harganya umumnya sedikit di atas web hosting. Namun VPS tidak bisa mengakomodir kebutuhan koneksi privat antar server. Jadi ketika anda membutuhkan konfigurasi yang lebih optimal untuk security dan keandalan web online anda VPS tidak bisa lagi memenuhi. Harap anda berhati-hati juga dengan layanan VPS yang karena umumnya infrastrukturnya hanya terdiri dari 1 server fisik yang di share dengan software virtualisasi sehingga bisa menampung banyak guest OS. Artinya secara kualitas tidak berbeda dengan web hosting, kelebihannya hanya anda memiliki kebebasan menentukan OS dan platformnya saja.

Cloud Server
Teknologi cloud berbeda dengan 2 di atas. Teknologi cloud memungkinkan beberapa server dijadikan “satu” berfungsi sebagai storage (disk virtual), beberapa server lain (Host) di”satu”kan berfungsi sebagai computing node (CPU virtual). Diatas platform cloud tersebut bisa berjalan beberapa server virtual (Guest). Teknologi cloud juga memungkinkan sekumpulan server virtual (Guest) membentuk suatu network VLAN seperti layaknya server-server fisik yang terhubung dengan LAN. Dimana tiap pelanggan memiliki secure VLAN masing-masing yang tidak bisa saling memasuki. Sehingga aplikasi business online anda terutama di Indonesia, yang membutuhkan konfigurasi beberapa server dapat di akomodir oleh layanan cloud server. Selain itu layanan Cloud Server memberikan anda kemudahan menaikan atau menurunkan resource server anda seperti jumlah Core CPU, maupun jumlah RAM sesuai kebutuhan anda atau biasa disebut On Demand. Anda layak berhati-hati jika ada layanan mengaku Cloud Server terutama di Indonesia tapi tidak bisa memberikan fasilitas On Demand karena teknologi ini yang membedakan dengan VPS. Pada layanan Cloud, Anda juga masih bisa berlanganan 1 server, dengan konsekuensi harga sedikit mahal namun kualitas tentu saja lebih baik karena infrastrukturnya terdiri dari beberapa server yang saling membackup

Resource Management in Telecommunication : Telecommunication Management Network (TMN)

Mia Savira Karthin

110400254

http://savirakarthin.wordpress.com/

Telecommunication Management Network (TMN)

Telecomunication Management Network (TMN) adalah suatu standar arsitektur manajemen jaringan yang digunakan untuk mengumpulkan, mengirimkan dan mengolah informasi yang berkaitan dengan manajemen jaringan. Tujuan TMN sendiri adalah mendukung proses administrasi pada manajemen jaringan telekomunikasi. TMN dikembangkan olehInternational Telecomunication Union ( ITU) sebagai sebuah infrastruktur untuk mendukung pengaturan dan penyebaran layanan telekomunikasi yang dinamis.

Telecomunication Management Network (TMN) mengembangkan sebuah framework untuk jaringan yang fleksibel, terukur, reliabel,   murah  untuk dijalankan dan mudah meningkatkan kualitas jaringan. Untuk mencapai hal ini, TMN mendefinisikan saru set poin untuk elemen interface yang melakukan proses komunikasi yang akan diakses oleh elemen seperti workstation manajemen, digunakan untuk memantau dan mengendalikan jaringan. Standar interface  memungkinkan elemen-elemen dari berbagai produsen untuk dimasukkan ke dalam jaringan di bawah kontrol manajemen tunggal.  Untuk komunikasi antara Operasi Sistem dan SPN (Jaringan Unsur) menggunakan protokol manajemen informasi umum (CMIP) atau perangkat Mediasi ketika menggunakan antarmuka Q3. TMN dapat digunakan dalam pengelolaan ISDN, B-ISDN, ATM, dan jaringan GSM. Hal ini tidak umum digunakan untuk murni packet switched jaringan data. Sebuah TMN menyediakan sarana untuk informasi transportasi dan proses yang terkait dengan pengelolaan jaringan  telekomunikasi.

Pada umumnya konsep manajemen TMN memperkenalkan beberapa manajemen arsitektur pada tingkat abstraksi yang berbeda, yaitu:

• A functional architecture, yang menjelaskan jumlah dari manajemen fungsi.
• A physical architecture, yang mendefinisikan bagaimana fungsi-fungsi manajemen dapat diimplementasikan ke dalam peralatan fisik.
• An information architecture, yang menjelaskan konsep-konsep yang bersumber dari manajemen OSI.
• A logical layered architecture (LLA), yang termasuk salah satu gagasan terbaik dari TMN: sebuah model yang menunjukkan bagaimana manajemen dapat distrukturisasi menurut tanggung-jawab yang berbeda.

Arsitektur TMN fungsional didasarkan pada sejumlah blok fungsi TMN. Blok fungsi ini memberikan TMN dengan fungsi yang memungkinkan untuk melakukan fungsi manajemen TMN.  Fungsi blok TMN tersebut dibagi atas  5 bagian yaitu Operations Systems Function (OSF), Netwrok Elements Function (NEF), Workstation Function (WSF), Mediation Function (MF), Q Adaptor Function (QAF).

TMN memiliki sejumlah komponen fungsional yang telah teridentifikasi yaitu Management Application Function (MAF), Mediation Function-Management Application Function (MF- MAF), Operation System Function – MAF,  Network Element Function–MAF, Adaptor Function–MAF, Information Conversion Function (ICF), Workstation Support Function (WSSF), User Interface Support Function (UISF), Message Communication Function (MCF). Untuk menggambarkan blok fungsi manajemen, maka diperkenalkan konsep titik referensi. Titik acuan menentukan layanan batas antara dua blok fungsi manajemen. Untuk sepasang blok fungsi tertentu, informasi lewat antara mereka dapat dicirikan dengan daftar interaksi yang sesuai untuk pasangan blok fungsi.

Cakupan TMN dimulai dari hubungan sederhana antara sebuah OS dengan suatu perangkat telekomunikasi tertentu hingga hubungan yang sangat kompleks antara suatu OS dengan berbagai perangkat telekomunikasi. TMN menyediakan berbagai macam fungsi manajemen dan menawarkan komunikasi antar OS maupun antara OS dengan berbagai bagian jaringan telekomunikasi, yang dapat meliputi perangkat telekomunikasi yang disebut elemen jaringan dengan sistem digital maupun analog, sistem penyambungan (switching), berbagai multiplexer, terminal signaling dan seterusnya.

Telecommunication Management Network (TMN)

by International Engineering Consortium

1. Framework Telecommunication Management Network (TMN)

TMN menyediakan framework jaringan yang fleksibel, sesuai skala, handal, tidak mahal dan mudah dikembangkan agar dapat mengoptimumkan kinerja dan mencapai efisiensi komunikasi. Prinsip TMN adalah bekerjasama dalam jaringan telekomunikasi untuk mengirimkan dan menerima informasi dan mengelola sumber daya nya. TMN memungkinkan komunikasi antara operation support system (OSS) dan NE. Berikut gambar bagaimana TMN berkontribusi dalam jaringan telekomunikasi.

TMN menggunakan prinsip subject-oriented dan interface standar untuk mendefinisikan komunikasi antara entitas manajemen dalam jaringan. Interface standar ini dinamakan interface Q3.  Arsitektur dan interface TMN dibangun dari standar open system interconnection (OSI). Standar ini mencakup : CMIP (common management information protocol), GDMO (guideline for definition of managed objects), ASN.1 (abstract syntax notation one) dan open system interconnect reference model.

2. Functional Telecommunication Management Network (TMN)

Sebuah TMN menyediakan sarana untuk informasi transportasi dan proses yang terkait dengan pengelolaan jaringan telekomunikasi. Arsitektur TMN fungsional didasarkan pada sejumlah blok fungsi TMN. Blok fungsi memberikan TMN dengan fungsi yang memungkinkan untuk melakukan fungsi manajemen TMN. Sebuah Data Communication Function (DCF) digunakan untuk mentransfer informasi antara blok fungsi TMN. Pasangan TMN blok fungsional yang pertukaran informasi manajemen yang dipisahkan oleh titik referensi antara mereka. Biasanya blok fungsional yang berbeda mungkin memiliki derajat yang berbeda dari pembatasan dalam lingkup pelaksanaan titik acuan yang sama. Fungsi yang disediakan oleh blok fungsi TMN akan diuraikan dalam bentuk komponen fungsional yang terdiri dari mereka. Berikut merupakan building blocks TMN :

Keterangan :

OS              = Operations Systems

MD            = Mediation

WS            = Work Station

NE             = Network Element

QA             = Q Adaptor

….               = The TMN Function Boundary

Fungsi masing masing komponen  adalah sebagai berikut :

OS : informasi yang berhubungan dengan manajemen telekomunikasi untuk maksud monitoring / koordinasi dan atau pengendalian fungsi telekomunikasi termasuk fungsi manajemen itu sendiri.

NE : Function block yang berkomunikasi dengan TMN dan berlaku sebagai pihak yang dikendalikan/dimonitor. NE menyediakan fungsi telekomunikasi dan pendukung yang diperlukan oleh jaringan telekomunikasi yang di-manage. NE menyediakan fungsi telekomunikasi yang menjadi subjek dari manajemen. Fungsi ini bukan bagian dari TMN tetapi dirpresentasikan ke TMN oleh NE. Bagian NE yang merepresentasikan fungsi tersebutlah yang menjadi bagian dari TMN.

WS : Menyediakan sarana untuk menginterpretasikan informasi TMN ke pengguna dan sebaliknya. Tanggung jawab WS  adalah sebagai penterjemah atara titik referensi TMN dengan non-TMN.

MD : Blok MF berfungsi untuk memastikan bahwa informasi yang dipertukarkan antara OS dengan NE (atau QA) sesuai dengan keinginan dari function block yang terhubung dengan MF. MF blocks dapat menyimpan (store), menyesuaikan (adapt), menyaring (filter), threshold dan condense informasi.

QA : Digunakan untuk menghubungkan TMN dengan entitas non-TMN yang serupa dengan NEF atau OSF.

3. The Standard Interfaces

Dalam model, antarmuka spesifik antara dua komponen TMN saling berkomunikasi satu sama lain. Antarmuka TMN adalah :

Q à muncul antara dua fungsi TMN dalam domain yang sama.

F à MUNCUL antara WS dan OS dan antara WS dan MD

X à Muncul antara dua OS dalam dua domain terpisah, atau antara OS TMN dan OS non-TMN  lain dalam jaringan.

Ada dua kelas interface Q, yaitu Q3 dan Qx. Gambar 4 mengilustrasikan fungsional blok bisa berkomunikasi melalui interface Q. interface Q3 meruoaja jalur menuju sistem operasi, merupakan satu satunya antarmuka yang bisa digunakan Qas, MDs atau Nes untuk berkomunikasi langsung dengan OS. Antarmuka Qx beroperasi dengan MD. MD dapat menginterpretasikan antara informasi manajemen lokal yang disediakan antarmyka Qx dan informasi OS yang disediakan antarmuka Q3.

4. The Telecommunication Management Network Logical Model

• BML (Business-management layer), berkonsentrasi pada perencanaan tingkat tinggi, budgeting, penetapan tujuan, keputusan eksekutif, business level agreement (BLAs) dan sebagainya.
• SML (service-management layer), berkonsentrasi pada informasi yang ditampilkan oleh NML untuk mengelola jasa kontrak untuk pelanggan potensial dan pelanggan yang telah ada. SML juga merupakan poin kunci untuk berinteraksi dengan penyedia jasa dan dengan domain administratif lain.
• NML (network management layer), bertugas mengelola NE secara individual maupun secara grup. NML mengkoordinasikan semua aktivitas jaringan dan mendukung permintaan dari SML, OS dalam antarmuka NML dengan OS dalam SML melalui antarmuka Q3.
• EML (element management layer), mengelola masing-masing elemen jaringan. EML memiliki manajer elemen atau OS, masing-masingnya bertanggung jawab untuk informasi TMN yang telah dikelola dalam NE.
• NEL (network element layer), menampilkan informasi TMN yang telah dikelola dalam NE individual.

5. Telecommunication Management Network Solutions

Tantangan utama untuk penyedia jasa, original equipment of manufactures (OEMs), vendor software dan integrator adalah untuk mengembangkan TMN-conformant, memperkuat aplikasi yang bisa menampilkan variasi network management. Service provider dan vendor software dapat mengimplementasikan solusi :

• Memperkecil waktu untuk pasar
• Memperkecil biaya
• Mendukung peningkatan permintaan untuk kualitas yang lebih tinggi
• Menciptakan sistem nyang bisa bekerja sama
• Menyesuaikan diri ke standar industri untuk TMN.

Architectural and Framework Standards: the eTOM Model (TMF)

The TeleManagement Forum (TMF) is a nonprofit global consortium that works on telecommunications management and the development of management systems and standards. It was established in 1988 as the OSI/Network Management Forum under the sponsorship of the ITU. Later the name was changed to TeleManagement Forum. The strategic goal of the TMF is to create or identify standard interfaces that allow a network to be managed consistently across various network element suppliers.

A major deliverable of the TMF was the TOM (Telecom Operations Map, GB910) model, a framework for telecom and Information Services business processes.

It was developed to drive a consensus around the processes, inputs, outputs, and activities required for service provider operations management. Its focus and scope were operations and operations management. TOM was extended and superseded by the eTOM (enhanced Telecom Operations Map, GB921 v6) model.

eTOM is a reference framework that categorizes the business processes that a service provider will use. It broadens the TOM model to a complete enterprise framework and addresses the impact of e-business environments and business drivers. eTOM can be considered a blueprint for standardizing business processes as well as operations support systems (OSS) and business support systems (BSS). Another area of improvement is process-modeling methodology, which provides the linkage necessary for Next-Generation Operations Support Systems (NGOSS). NGOSS programs implement a common system infrastructure framework, in which components that adhere to the specifications can interoperate in a flexible application infrastructure.

The eTOM model serves as a reference framework for categorizing all the business activities of a service provider. It categorizes them into different levels of detail according to their significance and priority for the business. The eTOM structure establishes the business language and foundation for the development and integration of BSS and OSS, respectively. eTOM provides a reference point and common language for service providers' internal process (re)engineering needs, partnerships, alliances, and general working agreements with other providers. For suppliers, the eTOM framework outlines potential boundaries of software components, and the required functions, inputs, and outputs that need to be supported by products using the common language of the service providers.

The ITU-T TMN models define management layers and focuses on general network management functionality. The eTOM focuses on managing operations, services, and interactions between the various components and building blocks. eTOM defines three major building blocks:

• Operations (OPS)
• Strategy, Infrastructure, and Product (SIP)
• Enterprise Management (EM)

Related to this book's perspective, the OPS area is most relevant, because SIP and EM describe different functions such as marketing, supply chain, and financial management.

The core of the operations area is the Fulfillment, Assurance, and Billing (FAB) model. The Operations Support and Readiness (OSR) part was added to the original TOM FAB model (GB910). FAB operations are directly related to customer services, whereas OSR ensures that the operational environment is in place for FAB to be successful.

Therefore, the two definitions do not overlap, but complement each other. The TMN model lays the foundation for managing the infrastructure. eTOM adds service functions and processes, such as service definition and quality management, as well as customer management functionality, such as sales, order handling, and customer relationship management. eTOM can be used to analyze existing processes in organizations as well as for defining new processes. Note that the eTOM model introduces both vertical functions (OSR, fulfillment, assurance, billing) and functional process grouping in horizontal layers:

• Customer Relationship Management (CRM)
• Service Management and Operations (SM&O)
• Resource Management and Operations (RM&O)
• Supplier/Partner Relationship Management (S/PRM)

Figure 3-4 is an overview of the eTOM operations areas. In August 2004, the ITU completed the ratification of eTOM as an official ITU standard. eTOM is published in the ITU M.3050 recommendation; however, it is based on a previous version of eTOM, GB921 v4.0. This book references eTOM GB921 v6.0 and v6.1.

Figure 3-4. TMF eTOM: Operations Area

[View full size image]

Operations includes processes that support customers, network operations, and management. This also consists of sales management and supplier/partner relationships management.

Fulfillment is responsible for delivering products and services to the customer. This includes order handling, service configuration and activation, and resource provisioning.

Assurance consists of proactive and reactive maintenance activities, service monitoring (SLA or QoS), resource status and performance monitoring, and troubleshooting. This includes continuous resource status and performance monitoring to proactively detect possible failures, and the collection of performance data and analysis to identify and resolve potential or real problems.

Billing collects usage data records (accounting), various rating functions, and billing operations. This includes production of timely and accurate bills, providing pre-bill use information and billing to customers, processing their payments, and performing payment collections. A detailed description of each layer can be found in the TMF's eTOM document (GB921). The following is a brief summary of the two areas that are most relevant for accounting and performance management. Within these two, the emphasis is on assurance and billing, because neither fulfillment nor OSR is related to accounting and performance:

• Resource Management & Operations (RM&O) is responsible for application, computing, and network resources. It includes Resource Trouble Management, which performs fault monitoring and management functions, such as processing device notifications, root cause analysis, and fault reporting. Resource Performance Management is another function of RM&O. It monitors, analyzes, and reports performance data from the devices. A common RM&O function between assurance and billing is Resource Data Collection and Processing. It gathers and distributes management data between devices and service instances.
• Service Management & Operations (SM&O) consists of Service Problem Management and Service Quality Management in the assurance section. These are responsible for monitoring, analyzing, and controlling operational services, as well as detecting, analyzing, and localizing service problems.

In the billing area, Service and Specific Instance Rating correlates service events and converts them into a specific format. Reports for chargeable and noncacheable events can be generated—for example, to identify fraud.

From the perspective of this book, the eTOM operations processes are relevant—particularly fulfillment, assurance, and billing.

Understanding Standards and Standards Organizations

This chapter describes architectures, standards definitions, and protocols related to performance and accounting. Starting with the big picture, this chapter drills down into definitions and specifications for data collection, data representation, and service notions. This chapter is also an overview of the different standards bodies and architectures, along with the concepts and principles of each protocol. This chapter also includes references for further investigation.

Instead of following the "classic" book structure of defining all standards in an introductory chapter, we decided to start by defining the requirements, followed by the collection methodology. With the use cases in mind, this is the right moment to introduce standards. The question "Why are standards required?" leads toward two answers:

• If you operate a single-vendor equipment environment, you might not see a big need for standards, because products are expected to interoperate as long as you stay with the same vendor. Interoperability between different products or versions from one vendor (such as a Cisco IOS version) is still an important requirement.
• In a multivendor environment, you expect vendors to agree on at least a minimum common denominator for functionality, which is what standards provide.

Which approach is better? Probably both have their pros and cons; the answer mainly depends on your business requirements. If you change your perspective slightly, the need for standards becomes evident. For example, suppose you travel abroad and rent a car. You expect the traffic rules to be similar to those in your home country. Cars might drive on the "wrong" side of the road, but you expect a red traffic light to mean "stop" and a green one to mean "go." If you stay in a hotel on your trip, you expect warm water to be associated with a red symbol, while blue stands for cold water. What is the conclusion? Standards are helpful to provide a kind of "lingua franca" to ensure that participants talk about the same subject.

Data normalization is another benefit of a standard. Suppose you ask two people what the temperature is. One says 68, and the other says 20. Who is right? Both are correct if the first person means Fahrenheit and the second person means Celsius. The same applies to metering data from network elements. Unless all devices apply the same measurement and report the same information with the same unit, normalization is required to turn raw data into information. For example, in a networking scenario, an ISP offers SLAs to an enterprise customer, and both parties measure the service with different tools. In the worst case, the results are completely different, leading to finger-pointing and misapprehension. As another example, two service providers collect accounting data for a peering agreement but use accounting measurement techniques that collect records with different data units. At the end of the month, different collection results lead to misapprehension. Data normalization can help address these issues.

For this book, the authors applied the following definition of a standard: "Obtaining common information across multiple network elements by using common terminology, protocols, and measurement units rather than each network element using its own syntax and reporting scheme."

Bridging the gap to network management, one person might interpret "management" to mean device monitoring, and someone else might consider "management" to mean the active part of modifying device configuration. When selecting the required Network Management System (NMS) applications, operators are sometimes overwhelmed by the functionality offered by applications. When asked what they are looking for, the answer might be "Just something to manage my complete network." In these cases, a helpful approach is to step back and ask, "Which functionality is required?", "Which devices need to be managed?", "Which services are planned?", and more. Afterwards, the answers can be mapped to a standard model, such as Fault, Configuration, Accounting, Performance, and Security (FCAPS)—as introduced in Chapter 1, "Understanding the Need for Accounting and Performance Management"—to categorize and prioritize the required functionality. As a last step, potential NMS applications are also mapped against the selected model, such as the Telecommunications Management Network (TMN) FCAPS model or the TMF eTOM model, to identify which product addresses which requirements.

Two types of standards need to be clearly distinguished:

• A de facto industry standard
• A formally committed standard from an official standards organization

When the majority of users or vendors accept and implement the same technical specification defined outside a standards body, it becomes a de facto standard. An example is IBM's Systems Networking Architecture (SNA), which originally defined networking only for IBM devices but was also implemented by other vendors. Formal standards are defined by global, regional, or national standards bodies. The International Telecommunications Union (ITU) is an international organization within the United Nations System where governments and the private sector coordinate global telecom networks and services. The ITU Telecommunication Standardization Sector (ITU-T) was created on March 1, 1993, replacing the former International Telegraph and Telephone Consultative Committee (CCITT), which originated in 1865.

In addition to the formal standard definitions and vendor de facto standards, specifications are defined by consortia. If a consortium's proposal is widely accepted, it becomes a de facto standard. These consortia are groups where different vendors (and sometimes also large customers, service providers, system integrators, and others) agree on a common definition and implement it afterwards. Examples are the TeleManagement Forum (TMF), the World Wide Web Consortium (W3C), Internet Protocol Detail Record (IPDR), Distributed Management Task Force (DMTF), and others. In all these cases, interoperability is gained if different vendors implement the same specification.

If you investigate a little further into standards organizations, you will realize the variety of standards organizations, some of which have overlapping focus areas and competing standards definitions. Why are there so many standards? This is not a simple question to answer; multiple answers are possible. One reason for the existence of different standards organizations is history. After the CCITT defined interoperability standards for Post, Telephone, and Telegraph (PTT) organizations, a need for Internet standards evolved, and the Internet Engineering Task Force (IETF) was founded. To meet the need for enterprise management standards, the DMTF was founded. The emerging web technologies required common standards, so the W3C was set up. Another reason for diversity is political discussions and disagreements within groups. Sometimes it is easier to define a new standard than to come to an agreement across the industry. Introducing competition by founding a new standards group can also increase the pace of another group.

With several different standards groups and organizations in place and a multitude of standards, the next question is how to identify the "right" standard. This requires defining the perspective first: a customer's request, a system integrator's offering, or a vendor's implementation? From an end-user perspective, a simple approach is to select the standard that you like the most; however, there might be better selection criteria.

Best practice suggests starting with the requirements. Why are you looking for standards that provide interoperability in a multivendor environment? Do you want investment protection to replace one vendor's network element with another vendor's? In this case, your management software also needs to support multiple vendors' equipment. Are you looking for operational transparency, which means you want the same management and reporting functionalities across vendors? This requires device instrumentation to be standardized. How do you integrate different management applications? If they use standard application programming interfaces (API), integration takes less effort than different APIs for each application. In summary, selecting the "right" standard depends on various criteria:

• Business requirements
• Single-vendor or multivendor strategy
• Device instrumentation
• Application interoperability
• Technical feasibility—identifying if implementing a function is technically achievable
• Common sense—requesting a standard just for the heck of it is not a wise decision

Taking a top-down approach to accounting and performance management, mainly two specifications are relevant to the big picture: the ITU-T TMN/FCAPS model and the TMF eTOM definition.

Information modeling also has two groups: the DMTF and TMF with their information model definitions of the Common Information Model (CIM; DMTF) and Shared Information/Data (SID; TMF). From a protocol perspective the two relevant standards bodies are the IETF (SNMP, AAA, IPFIX, PSAMP, and others) and the ITU (CMIP/CMISE and GDMO). These protocols are discussed later.

A top-down approach to accounting and performance management includes three components, which are discussed in detail in subsequent chapters:

• Framework/architecture:

  - The ITU with the TMN/FCAPS model.

  - The TMF with the definition of eTOM. Note that ITU-T M.3050 recommends eTOM as well.

• Information modeling:

  - The DMTF with CIM.

  - The TMF with SID.

• Protocols:

  - The IETF with SNMP, AAA, IPFIX, PSAMP, and others.

  - The ITU with CMIP/CMISE and GDMO.

Architectural and Framework Standards: The TMN/FCAPS Model (ITU-T)

The ITU-T introduced the term Telecommunications Management Network (TMN) to describe a separate network that has interfaces to the telecommunication network (or production network). TMN defines interconnection points between the two networks and specifies management functionalities. The best description of how to operate a TMN is defined by the ITU-T recommendations M.3010, M.3400, and X.700.

The purpose of a framework is to describe the big picture, illustrate different functional areas, and identify how they interoperate. The focus of ITU-T M.3400 and X.700 is the specification and classification of management functionalities only. For example, it does not define whether syslog or trap messages are mandatory for event notifications. Neither does it define specific formats for storing accounting records. These details are defined in the lower-level specifications standards. In addition to the framework of M.3400, another recommendation (M.3010) defines the principles for a TMN. It includes details of a Data Communications Network (DCN) as a transport vehicle between the management applications and network elements. A DCN is also known as out-of-band-management, which separates user traffic from management traffic. Figure 3-1 illustrates the relationship between the telecommunications network, also called the service infrastructure, and the TMN.

Figure 3-1. TMN and Telecommunications Networks

[View full size image]

Another relevant aspect of M.3010 is the concept of layers. Network management tasks are grouped into functional areas such as FCAPS. In addition, a logical layered architecture (LLA) consists of five management layers:

• Network Element Layer (NEL) defines interfaces for the network elements, instantiating functions for device instrumentation, ideally covering all FCAPS areas.
• Element Management Layer (EML) provides management functions for network elements on an individual or group basis. It also supports an abstraction of the functions provided by the network element layer. Examples include determining equipment errors, measuring device temperatures, collecting statistical data for accounting purposes, and logging event notifications and performance statistics.
• Network Management Layer (NML) offers a holistic view of the network, between multiple pieces of equipment and independent of device types and vendors. It manages a network as supported by the element management layer. Examples include end-to-end network utilization reports, root cause analysis, and traffic engineering.
• Service Management Layer (SML) is concerned with, and responsible for, the contractual aspects of services that are being provided to customers. The main functions of this layer are service creation, order handling, service implementation, service monitoring, complaint handling, and invoicing. Examples include QoS management (delay, loss, jitter), accounting per service (VPN), and SLA monitoring and notification.
• Business Management Layer (BML) is responsible for the total enterprise. Business management can be considered a goal-setting approach: "What are the objectives, and how can the network (and network management specifically) help achieve them?"

Figure 3-2 shows the relationship between the different layers as well as the relationship with the FCAPS model. Each management layer is responsible for providing the appropriate FCAPS functionality according to the layer definition. Each layer communicates with the layers above and below it.

Figure 3-2. ITU-T M.3010: TMN Logical Layer Architecture

Now that the different layers of the TMN model have been identified, the functionality of each FCAPS area is described next. The TMN architecture has a strong relationship to Open Systems Interconnection (OSI) standards and frameworks. ISO 7498-4 defines the framework, concepts, and terminology of the OSI Management standards: "Information Processing Systems - OSI - Basic Reference Model - Part 4: Management Framework."

The ITU-T M.3400 recommendation is one document within the M series. It specifies five management functional areas (FCAPS):

• Fault management— Detect, isolate, notify, and correct faults encountered in the network.
• Configuration management— Configure aspects of network devices, such as configuration file management, inventory management, and software management.
• Accounting management— Collect usage information of network resources.
• Performance management— Monitor and measure various aspects of performance so that overall performance can be maintained at a defined level.
• Security management— Secure access to network devices, network resources, and services to authorized individuals.

The following section provides more details about each area. This chapter covers the FCAPS model extensively, because it sets the foundation for network management in general and provides a good understanding of accounting and performance management and their potential relationship to each other. Therefore, not only the accounting and performance parts of FCAPS are addressed, but the full model. Afterwards, other standards are discussed solely based on their specific relationship to accounting and performance management. Also, note that there is not an exact match between the brief FCAPS summary in Chapter 1 and the extended details for accounting and performance in this chapter. Chapter 1 provides the authors' definitions from a network element perspective, and this chapter covers FCAPS functionality from all layers of the TMN model.

Fault Management

Fault management is a set of functions that enable the detection, isolation, and correction of abnormal operation of the telecommunication network. The quality assurance measurements for fault management include component measurements for Reliability, Availability, and Survivability (RAS). Fault management consists of the following functions:

• RAS quality assurance establishes the reliability criteria that guide the design policy for redundant equipment (a responsibility of configuration management) and the policies of the other function groups in this area.
• Alarm surveillance describes the capability to monitor network element failures in near-real time.
• Fault localization describes where the initial failure information is insufficient for fault localization. It has to be augmented with information obtained by additional failure localization routines at the application level.
• Fault correction transfers data concerning the repair of a fault and the control of procedures that use redundant resources to replace equipment or facilities that have failed.
• Testing can be carried out in two ways. In one case, a network element analyzes equipment functions, where processing is executed entirely within the network element. Another method is active testing of external device components, such as circuits, links, and neighbor devices.
• Trouble administration transfers trouble reports originated by customers and trouble tickets originated by proactive failure-detection checks. It supports action to investigate and clear the problem and provides access to the status of services and the progress in clearing each problem.

Configuration Management

Configuration management provides functions to identify, collect configuration data from, exercise control over, and provide configuration data to network elements. Configuration management supports the following functions:

• Installing the physical equipment and logical configurations.
• Service planning and negotiation, which addresses planning for the introduction of new services, changing deployed service features, and disconnecting existing services.
• Provisioning, which consists of necessary procedures to bring equipment into service but does not include installation. As soon as the unit is ready for service, the supporting programs are initialized via the TMN. The state of the unit (in service, out of service, standby, or reserved) and selected parameters may also be controlled by provisioning functions.
• Status and control where the TMN provides the capability to monitor and control certain aspects of the network element (NE) on demand. Examples include checking or changing an NE's service state (in service, out of service, or standby) or the state of one of its subparts and initiating diagnostic tests within the NE. Normally, a status check is provided in conjunction with each control function to verify that the resulting action has taken place. When associated with failure conditions, these functions are corrective in nature (such as service restoration).
• Network planning and engineering deals with functions associated with determining the need for growth in capacity and the introduction of new technologies. Planning and engineering are examples of functions across multiple areas, because they relate to the performance section from a monitoring perspective and to the configuration section from an enforcement perspective.

Accounting Management

Accounting management lets you measure the use of network services and determine costs to the service provider and charges to the customer for such use. It also supports the determination of charges for services. Accounting management includes the following functions:

• Usage measurement— Consists of the following subfunctions:

  - Planning and management of the usage measurement process

  - Network and service usage aggregation, correlation, and validation

  - Usage distribution

  - Usage surveillance

  - Usage testing and error correction

  - Measurement rules identification

  - Usage short-term and long-term storage

  - Usage accumulation and validation

  - Administration of usage data collection

  - Usage generation

• Tariffing and pricing— A tariff is used to determine the amount of payment for services usage.
• Collections and finance— Functionality for administering customer accounts, informing customers of balances and payment dates, and receiving payments.
• Enterprise control— This group supports the enterprise's financial responsibilities, such as budgeting, auditing, and profitability analysis.

Performance Management

Performance management provides functions to evaluate and report on the behavior of telecommunication equipment and the effectiveness of the network or network element. Its role is to gather and analyze statistical data for the purpose of monitoring and correcting the behavior and effectiveness of the network, network elements, or other equipment, and to aid in planning, provisioning, maintenance, and quality measurement. Performance management includes the following functions:

• Performance quality assurance— Includes quality measurements, such as performance goals and assessment functions.
• Performance monitoring— This component involves the continuous collection of data concerning the performance of the network element. Acute fault conditions are detected by alarm surveillance methods. Very low rate or intermittent error conditions in multiple equipment units may interact, resulting in poor service quality, and may not be detected by alarm surveillance. Performance monitoring is designed to measure the overall quality, using monitored parameters to detect such degradation. It may also be designed to detect characteristic patterns of impairment before the quality has dropped below an acceptable level. Performance monitoring includes the following functions:

  - Performance monitoring policy

  - Network performance monitoring event correlation and filtering

  - Data aggregation and trending

  - Circuit-specific data collection

  - Traffic status

  - Threshold crossing alert processing

  - Trend analysis

  - Performance monitoring data accumulation

  - Detection, counting, storage, and reporting

• Performance management control— This group includes the setting of thresholds and data analysis algorithms and the collection of performance data. It has no direct effect on the managed network. For network traffic management and engineering, this includes functions that affect the routing and processing of traffic.
• Performance analysis— The collected performance records may require additional processing and analysis to evaluate the entity's performance level. Therefore, performance analysis includes the following functions:

  - Recommendations for performance improvement

  - Exception threshold policy

  - Traffic forecasting (trending)

  - Performance summaries (per network and service, and traffic-specific)

  - Exception analysis (per network and service, and traffic-specific)

  - Capacity analysis (per network and service, and traffic-specific)

  - Performance characterization

Security Management

Security is required for all functional areas. Security management consists of two main functions:

• Security services for communications provide authentication, access control, data confidentiality, data integrity, and nonrepudiation. These may be exercised in the course of any communications between systems and between users or customers and systems. In addition, a set of pervasive security mechanisms are defined that are applicable to any communication, such as event detection, security audit-trail management, and security recovery.
• Security event detection and reporting reports activities that may be construed as a security violation (unauthorized user, physical tampering with equipment) on higher layers of security applications.

Security management includes the following functions:

• Prevention
• Detection
• Containment and recovery
• Security administration

The TMN Framework

The framework shown in Figure 3-3 brings it all together. The different logical layers sit on top of each other; each layer is responsible for implementing the FCAPS functionality and passes the collected information to the next layer. From a customer's applicability perspective, after identifying and prioritizing the requirements, you can map various network management products to this matrix and identify what is required to meet your needs.

Figure 3-3. TMN Management Layers and FCAPS

[View full size image]

From the perspective of this book, relevant layers of the TMN architecture are the Network Element Layer (NEL); the Element Management Layer (EML), related to similar device types; the Network Management Layer (NML), related to mediation; and the Service Management Layer (SML), related to service monitoring and accounting. The Business Management Layer (BML) is outside the scope of this book. If you're interested, you're encouraged to study the ITU-T M series for more details.

Note that the FCAPS model describes the conceptual model of functional areas; it does not define accounting and performance standards for data collection. Therefore, a second level of standards is required for data collection. At the network element layer, it can be SNMP or IPFIX. IPDR is appropriate at the Element Management Layer.