The Role of SNMP in A General TMN Framework For Convergent Networks

Size: px

Start display at page:

Download "The Role of SNMP in A General TMN Framework For Convergent Networks"

Lambert Allison
5 years ago
Views:

1 The Role of SNMP in A General TMN Framework For Convergent Networks Wolfgang Haidegger Telecommunications Research Center (FTW) Vienna Donau-City-Str. 1, TechGate A-1220 Wien Austria Phone: Fax: haidegger@ftw.at

2 The Role of SNMP in A General TMN Framework For Convergent Networks Wolfgang Haidegger Telecommunications Research Center (FTW) Vienna Donau-City-Str. 1, TechGate, A-1220 Wien haidegger@ftw.at Keywords: TMN, SNMP, Q 3, Quality-of-Service, Endto-End Management, convergent networks ABSTRACT This paper intends to show that SNMP will play an important role in a future end-end TMN of convergent networks. Taking the principal building blocks for a TMN as defined by ITU-T s recommendation M.3010 as a basis, a high-level framework for an end-end management in convergent networks is developed. In the course of the discussion it will be shown that SNMP can find its place within a TMN framework generically. 1. INTRODUCTION The notion Quality-of-Service (QoS) has gained importance in practically all kinds of networks for all kinds of services. This paper focuses on the requirements of mixed voice/data (also: convergent) networks with telephony applications put on top. The challenge concerning this scenario is the fact that QoS within circuit switching networks has acquired a very high level. As the customers have been used to this high standard for many years they will not easily accept a degradation of the quality of voice transmission. A similar standard has not yet been reached within voice over packet networks. In order to remedy this situation two totally different aspects have to be dealt with: On the one hand the networks themselves have to be made more reliable, using efficient routing (queuing) algorithms, traffic engineering and the latest high performance techniques. On the other hand the framework for an endend network management system has to be designed, which takes care of the needs of a network provider, a service provider and an enterprise. The remainder of this paper will focus on the last issue. Using SNMP (Simple Network Management Protocol) in a TMN context has received only minor attention in the related work so far, whereas it is common practice to use SNMP for traffic engineering within the IETF (see e.g. [4], [5] and references therein). [6] introduces the function sets of end-to-end performance management as a possible content of the TMN described in the following sections. The rest of the paper is structured as follows: Starting point will be a short discussion of the principal ideas of the M.3010 [1]. Resulting from this, a general framework encompassing both circuit switching and packet oriented networks will be proposed. Finally the role of SNMP within this framework will be discussed, before some conclusions and consequences for further work are described. 2. THE LAYERED, FUNCTIONAL MANAGEMENT STRUCTURE DEFINED BY ITU-T At the basis of the whole ITU TMN construct one finds the definition of a TMN function. It is seen as an interaction between applications of a managing and a managed system so as to manage some physical or logical telecommunication resources. For the formulation of specific management capabilities like network performance assessment [2] more than one management function will be necessary. Functions defined for the same capability can be grouped together and are then referred to as function groups. To fill the above definitions with contents, one has to formulate the management services needed and their benefits. As a consequence one will arrive at different management contexts, which mandate certain roles of the TMN and consequently also different functions to be executed. On the basis of the above the authors of [1] identified some generic logical units on the one hand and a layered structure according to the different management objectives on the other hand as sketched in figures 1 and 2.

3 BUSINESS MANAGEMENT LAYER B u s i n e s s M a n a g e m e n t L a y e r B u s i n e s s O S F B - O S F SERVICE MANAGEMENT LAYER NETWORK MANAGEMENT LAYER S e r v i c e M a n a g e m e n t L a y e r S e r v i c e O S F S - O S F x ELEMENT MANAGEMENT LAYER N e t w o r k M a n a g e m e n t L a y e r N e t w o r k O S F N - O S F x Figure 1: ITU-T network management layers The generic logical units, also called function blocks, pertain to the three principally different tasks attributed to the TMN. One is the operations system function block (OSF) dealing with the controlling, coordination and monitoring of telecommunication functions including the management functions. The second is the network element function block (NEF), which mirrors the activities actually carried out on the network element from the point of view of the element management. The third logical function block is the so called work station function block (WSF), which takes care of the translation of all acquired information into forms which can be interpreted by human personnel. In addition the authors of [1] defined two mediation function blocks, of which one is of special importance and that is the mediation function block (MF). It has as its main task to provide accessible data in the form a WSF or OSF can use it (by probably filtering, adapting, condensing or thresholding the data). The various function blocks need to exchange information. To this end the authors of [1] define reference points, which turn into interfaces as soon as actual protocols are used. The Q3 interface as depicted in figure 2 will be introduced in section 4. In addition one needs a protocol to transfer the information, for which they chose CMIP (Common Management Information Protocol, see also section 4). It shall be remarked here that the usage of CMIP is not a prerequisite for the definition of the function blocks to stay intact. Figure 2 gives an impression of the way the functional blocks and the layers fit together. l e m e n t a n a g e m e n t a y e r e t w o r k l e m e n t a y e r O T E S E l e m e n t O S F E - O S F N e t w o r k E l e m e n t F u n c t i o n N E F A d d i t i o n a l o r a l t e r n a t i v e l a y e r s a r e p e r m i t t e d. O t h e r i n t e r a c t i o n s m a y a l s o o c c u r b e t w e e n n o n - a d j a c e n t l a y e r s. Figure 2: ITU-T TMN function blocks and interfaces The management layers stem from a totally different focus. The first two layers are dedicated to the network operator and differ in granularity. The lowest layer is concerned with the management of a single network element (Element Management Layer EML). It can have three roles, coordinating a single network element, coordinating a group of them and maintaining statistical information about them. The next layer is tasked with the management of a whole network (NML), the types of the nodes being transparent to the network provider at this level. It can have four principal x

4 roles, controlling and coordinating the network using information from all network elements, providing, withdrawing or modifying network services according to the requests of the service management layer, maintaining all network capabilities and maintaining statistical, log and other data for the usage of the service management layer. With the next layer the needs of a service provider are addressed (Service Management Layer SML). It is concerned with the contractual aspects of the services provided for a customer or available for a potential new customer. This layer can again take four roles, facing the customer or interfacing with other administrations, interacting with service providers, maintaining statistical data or interacting between services. The last layer defined within [1] is responsible for the management of a whole enterprise or business (Business Management Layer BML). Though its nature will obviously be very proprietary still some roles have also been identified for this layer, supporting the decision process for the optimal investment, supporting the budget decisions for the OA&M (Operation, Administration and Maintenance) related investments and maintaining the aggregated data about the whole enterprise. So, as a summary, according to [1] the following entities need to be allocated in the physical and functional TMN architecture: management function sets; management functions; applicable reference points (for example q, x, f); corresponding interfaces (Q, X, F, ) The next section will see a principal, very high level application of the just presented ideas onto a convergent network. 3. A MANAGEMENT FRAMEWORK FOR CONVER- GENT NETWORKS From the last section it is clear that the end-end layers starting with the network management layer should not see the difference between an element from a circuit switching network and from a packet oriented network. Regarding the basic definitions of the end-end layers as kind of templates, which have yet to be filled with contents this is effectively true. The reasons why, in spite of the level of abstraction, the end to end layers will have to be treated separately for the different types of networks will just be touched upon in the remainder of this paragraph. For one there will always be data, which will not be common to the two types of networks, if one thinks for example of label switched path information used for traffic engineering within packet oriented networks. The difference reaches actually even farther, as the congestion phenomena of the different network types obey different mathematical laws, so that one cannot take the NML as a plug and play entity without regard to whether the EML belongs to a circuit switched network or to a packet oriented network. Still the genericity of [1] remains. If one assumes the packet oriented network to be an IP-network one has, in addition to the purely functional aspects, organizational aspects as well. The smallest unit to be managed will again be one network element, but the next closed administrative unit that presents itself, is the Internet Domain. Regarding big enterprises as an example one might have to manage more than one domain, with the additional problem that these might be dispersed over the globe being connected via domains, which are not directly controllable. Altogether, this motivates the definition of a telecommunication network management framework for packet oriented networks, which can function in a stand-alone version as well as in unison with a POTS- TMN. According to the organizational hierarchy of the Internet discussed above the following layered approach is proposed (see fig. 3): Dedicated to one single network element or to a group of such elements will be the Element Monitoring and Management Entity (EMME). Its functionality can be located either on the network node itself or on a separate management computer. The EMME is assigned the same roles as the EML except that it has as an additional main role the monitoring (and thus polling) of the managed network elements. The next layer is concerned with the management of a whole domain, the so called Domain Management Entity (DME). From a concept point of view it can contain all end-end layers described within section 2. Note that end-end means in this case from domain border to domain border. This is the case if the network of one enterprise for example corresponds to one Internet domain. The DME does not necessarily need to contain all layers. If the enterprise should for example be a network provider the service management layer may well be empty. In case a network consisting of various, not necessarily directly connected, networks needs to be managed, it is proposed to use an entity, which can coordinate and manage the various DMEs, the so called All Domain Management Entities Supervisor Entity (ADMESE). This entity will also have to be able to slip into all the roles defined for the NML, SML and BML. There will be a shared responsibility between the DMEs and the ADMESE.

5 ADMESE Layer DME Layer EM ME Layer IP Layer Domai n 1 Domain 2 Domain 3 Figure 3: The organizational structure for an Internet TMN The connection between the TMN systems can be effected in two ways. One can either use the X- interface, which has been mentioned in section 2 and which has been foreseen by ITU-T as the interface between TMNs. To this end one might note that this construction is possible, because both TMN systems basically adhere to [1]. One can also enhance the hierarchical structure by adding a common management layer, CML, which is able to interpret the data delivered by both TMN systems. This might keep the amount of protocols needed within the TMN as a whole down, but decidedly adds to the topological complexity. 4. THE ROLE OF CMIP AND SNMP IN THE TMN SYSTEM OF A CONVERGENT NETWORK In section 2 the basic notion of a TMN function was introduced as interaction between applications of a managing and a managed system. This interaction has been modeled as an open system interconnection according to [3]. In addition it is using the manager-agent principle. This means that the element, which happens to be in the role of the slave, only talks to the element, which plays the role of the manager, when it is triggered. The only exceptions are, when instantaneous messages have to be sent in order to notify the master of some important event. The manager has a certain view on the resources of his agent and well defined operations via which he can read or modify (in some cases also create and delete) the same. All these properties are met by the protocols CMIP and SNMP treated within the next two paragraphs. CMIP, which will make the start, has been developed in a strongly circuit oriented surrounding, whereas SNMP has always been IETF s favorite. The information exchange protocol favored by ITU-T is defined as Common Management Information Protocol (CMIP) [7]. The corresponding reference point is the reference point, leading to the Q 3 -interface. The manageable resources are in this case modeled with the type and value modeling language ASN.1 [8] and the object modeling language GDMO [9]. The resulting objects can be manipulated by well defined and individually attached operations: CREATE, GET, SET, DELET. The orders for the realization of these commands are sent via CMIP from the master to the agent. Via an EVENT the agent can notify the master of important unusual happenings. CMIP represents a fairly powerful tool, which allows filtering and scoping for all types of operation (one would probably be careful at creation time using scoping). The drawback is that CMIP is fairly complex to implement and handle, as the requests can get very difficult, if one wants to filter on something like a partial key. In addition CMIP needs the protocols ACSE (Association Control Service Element) [10] for the association initiation and ROSE (Remote Operation Service Element) [11] for the possibility of remote operations as basis. Using the same principles enumerated in the first paragraphs of this section IETF developed the Simple Network Management Protocol (SNMP) for the management of agent entities (like for example a router). The interface which bears no special name is only modeled in ASN.1. The approach is still object oriented, as ASN.1 macros are used to define objects, which represent the resources to be manipulated by the manager. Unlike in Q 3 though only simple data types are allowed, which makes the processing of the data much easier and faster. Manipulation of the objects can be carried out via the following two operations: READ, WRITE, making the implementation of the protocol that much easier. The agent can make himself heard using TRAPs (instead of the EVENTs in Q 3 ). One of the main drawbacks is that SNMP comes in many flavors (v1, v2x, v3) [12] [13] [14]. Only SNMPv3 provides the necessary security standards necessary for the management of sensitive resources. 5. SUMMARY AND CONCLUSION This paper first summarizes the TMN concept of ITU-T [1]. In the course of this summary the genericity of the concept is highlighted. Then a possible overall TMN architecture for circuit switching and packet oriented networks is presented, proposing a specific organizational structure for the specific case of the Internet. It is shown that the generic structure of [1] also

6 holds for this new architecture. Then two management protocols are introduced, CMIP and SNMP, for both of whom it is shown that they fit into the TMN concept perfectly well. The next steps will be the detailed specification of the Internet TMN system and an in-depth analysis of the usage of an CML versus the definition of an X- interface and the corresponding protocol. Acknowledgements. This work has been partially funded within the framework of the Austrian Kplus Competence Centre Program. REFERENCES [1] ITU-T Recommendation M.3010: Principles for a Telecommunications Management Network, [2] ITU-T Recommendation M.3400: TMN Management Functions, [3] ITU-T Recommendation X.200: Open System Interconnection, [4] draft-ietf-tewg-mib-00.txt A Traffic Engineering MIB [5] Awduche et al.: Requirements for Traffic Engineering Over MPLS RFC 2702, , IETF [6] Reichl P., Haidegger W.: How to Combine Edge Pricing and End-To-End Performance Management Efficiently. Proc. of Applied Telecommunication Symposion 2002, San Diego (CA), April [7] ITU-T Recommendation X.711: Common Management Information Protocol [8] ITU-T Recommendation X.680 (X.208): Abstract Syntax Notation 1 [9] ITU-T Recommendation X.722: Guidline for the Definition of Managed Objects [10] ITU-T Recommendation X.217: Association Control Service Element [11] ITU-T Recommendation X.719: Remote Operation Service Element [12] Case et al.: Simple Network Management Protocol RFC 1157, , IETF [13] Case et al.: Introduction to Community-based SNMP-v2l RFC 1901, , IETF [14] Case et al.: SNMPv3 Management Protocol RFC 2262, , IETF

ETSI TR V1.1.1 ( )

ETSI TR V1.1.1 ( ) TR 101 303 V1.1.1 (2001-06) Technical Report Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Service and Network Management Framework; Overview and Introduction 2 TR 101