• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
IP Network Management System

IP Network Management System






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    IP Network Management System IP Network Management System Document Transcript

    • UDC 621.395.3:621.397.2.681.32 IP Network Management System VKohei Iseda VJunichi Sakuma VHiroaki Abe (Manuscript received March 5, 2001) Internet traffic is growing exponentially, and different kinds of traffic are being inte- grated into the Internet Protocol. To keep up with these changes, the Operation Sup- port System (IP-OSS) will be changed to adapt a diversification of IP services. In this paper, after describing the framework of a future IP-OSS, we discuss “negotiation,” which will become a key function in future IP management. We describe a policy/ negotiation-based IP management service for an enterprise network. This service re- alizes end-to-end policy-based enterprise networking. Lastly, we introduce some Fujitsu IP-OSS products for supporting these features. 1. Introduction new services such as bandwidth trading are ap- The Internet traffic volume is growing expo- pearing. IP management systems should support nentially, and different kinds of traffic are being these new services by including a negotiation func- integrated into the Internet Protocol. This growth tion for their customers. has given birth to many new Internet businesses, In this paper, after describing the framework and the integration of traffic has made the IP net- of the future IP-OSS, we will discuss negotiation, work into a widespread infrastructure for business which will become a key function for future IP activities. Various kinds of IP services, consisting management services. We describe a policy/ of IP management services and IP communica- negotiation-based IP management service for an tion services, for Application Service Providers enterprise network. This service realizes an end- (ASPs) and Content Service Providers (CSPs) have to-end policy-based enterprise networking support been launched, and the public network has shift- of business activities. Lastly, we introduce several ed from legacy telephony and data networks to IP Fujitsu IP-OSS products that support the above packet transmission networks with value-added features. services. The increasing competition based on liberalization, new services, and new business 2. IP service management models have made the IP network an important framework commodity. Existing IP management systems focus on To keep up with these drastic changes, re- the management of Network Elements (NEs), quirements for an IP-OSS which adapts to which include routers, edge switches, and diversification in IP services have strengthened. Customer Premised Environment (CPE) equip- Increased utilization by providing various kinds ment. These systems are designed to monitor, of IP services is crucial to secure investment re- supervise, and control the behavior and perfor- turns and win the competition. To achieve this, mance of NEs, thus offering basic and essential 72 FUJITSU Sci. Tech. J.,37,1,pp.72-80(June 2001)
    • K. Iseda et al.: IP Network Management System IP management functions for network devices. public network management must also be consid- These systems are based on the on-site manage- ered to achieve public IP network service ment concept for small LAN environments. customization with flow-through network opera- However, from on-site locations to remote loca- tions. tions, the evolution of the Internet is making it necessary to change existing IP management con- 3. Negotiation2) cepts in order to improve customer satisfaction, In this section, we discuss the negotiations services, scalability, and compatibility with e-busi- made between an IP service provider (e.g., public ness management systems. The key requirements IP network provider) and an end-user (e.g., an for the new IP management system are as follows: enterprise). 1) Faster order handling. 2) End-to-end communication service quality 3.1 Negotiation model management. Negotiation is one of the key functions of IP 3) Support of network performance monitoring service customer care. An end-user will be able and planning. to interact with the provider’s negotiation func- 4) New management services. tion by downloading negotiation agent software 5) Support of e-business models. from a server in the provider domain to the end- Figure 1 shows a management framework user terminal, to finalize the SLA. The software for a public IP network. Using this framework, agent is a very useful paradigm for the brokering autonomous IP network management and of 1:n or n:n negotiations among participating multi-domain management are realized. To ac- users and providers. Table 1 shows the features commodate topologically huge and technologically that should be included in negotiations and their heterogeneous public IP networks and to provide timings. Of course, the timings of actual negotia- IP services based on Service Level Agreements tions can be adjusted depending on the customers’ (SLAs) with customers and other network provid- needs and support mechanisms. ers, the public network must be managed based Through negotiation, end-users can select on the Telecommunications Management Network their preferred service features and price. At the (TMN) five-layer framework (Business Manage- same time, service providers can offer the request- ment Layer (BML), Service Management Layer ed service features while minimizing resource (SML), Network Management Layer (NML), requirements and maximizing resource utiliza- Element Management Layer (EML), and Network tion. Figure 2 shows the functional architecture Element Layer (NEL).1) These characteristics of for realizing negotiation. The figure shows that in total IP management, in contrast to legacy Network design Evaluation/design PSTN services, Web-enabled IT-capable terminals Network/service /provisioning planning IP service Service fulfillment Service assurance Table 1 provision (Service configuration ) (Service measurement, etc.) Negotiation items. Network config. Policy Timing Features IP resource information repository operation Control Monitoring • Static (long term) • Price (Consistency check) (Performance, fault, etc.) • Pre-assigned • QoS/CoS • On demand • Bandwidth Carrier IP network (autonomous, multi-domain) • Delivery time Figure 1 • Security Management framework for public IP network. etc. FUJITSU Sci. Tech. J.,37, 1,(June 2001) 73
    • K. Iseda et al.: IP Network Management System make easy, customer self-operation and negotia- viding the Policy-Based Management (PBM) sys- tion a reality. To fully support these user functions, tem into a policy decision, policy enforcement, and the provider must establish dynamic resource policy repository.3) Figure 3 illustrates the poli- management databases (DBs), for example, a traf- cy-based negotiation architecture based on the fic DB, pricing DB, and CoS DB, to make more loose-coupling concept. effective use of network resources. The policy executor in the figure consists of a policy repository and policy decision function. 3.2 Policy-based negotiation architecture The policies are included in the policy repository Negotiations and the resultant SLAs drive as policy rules. The rules are well-defined until a the execution of policies in the user and provider management system and/or a network element domains. In return, the policies in these domains can handle them directly. A state change event of can drive the content of a negotiation. Negotia- network resources triggers the policy decision tion is done in consideration of factors such as function to search through the policy repository resource utilization, the providing of services, and to make a policy decision. Since the policies, the competition with other providers. These factors mechanism which makes decisions according to quickly change, and network management poli- the policies, and the management functions (i.e., cies which realize negotiation results are also the policy enforcement functions) which control affected by these changes. Although policy-based resources according to the policy decisions are management has been used in traditional telecom clearly separated in this architecture, the impact management systems, its policies are not sepa- of policy changes on the rest of the management rated from the rest of the system as independent system is minimized. Hence, a change in the man- components. Instead, its policies are tightly cod- agement policies to gain a competitive advantage ed within the management systems, making it can be easily realized. The policy descriptor pro- extremely difficult to adjust the policies to respond vides a representation mechanism for policies, and to dynamic user needs and provide new services the policy editor includes a tool for policy consis- according to the resource status and the competition. tency and integrity checking. The tool is of The only solution to this problem is to sepa- particular importance in minimizing policy-to- rate policies from the management system so that policy interference when policies are modified. the policies are realized as a set of loosely cou- The coherency of the policy is of critical im- pled, parameterizable parts of the management portance if the PBM is to provide reliable system. Policy management supports this by di- management operations. One systematic ap- Customers Operators (3) Agreed services Interactive Customer Resources negotiation OSF Policy descriptor (4) Service report (1) Negotiation (2) Service provision Policy editor Resource Policy Service negotiation function management Policy executor management Status report Policy Policy decision repository function Policy Pricing Resource Class of Traffic enforcement DB DB service DB DB OSS OSS Figure 2 Figure 3 Negotiation architecture. Policy management and negotiation. 74 FUJITSU Sci. Tech. J.,37, 1,(June 2001)
    • K. Iseda et al.: IP Network Management System proach to maintaining coherency is to sort out the monly consists of private networks and public resources by management layers and represent networks. In the private network portion (i.e., a them as managed objects using a proper abstrac- Local Area Network [LAN]), a policy-based man- tion scheme. agement framework can be a solution for policy The policy-based negotiation architecture enforcement if the policies can be translated into and the loosely coupled PBM allow the policies to refined policies (called policy rules) that the PBM define and represent the relationships between policy mechanism is able to handle. In the public service managed objects (MOs), enabling flexible network portion of an enterprise network (i.e., a and customizable negotiation and more timely IP Wide Area Network [WAN]), enterprise users will service management. For example, a customer expect public IP network service providers to be (end-user) negotiates with a service provider in- able to enforce the enterprises’ policies. teractively, resulting in a policy modification To meet these requirements, we enhanced the request in the respective management domains. concept of SLA and created a policy-based SLA. Changes in policy descriptions lead to changes in The policy-based SLA is defined as a set of man- IP service management by the provider in areas agement policies (policy rules) that are derived ranging from customer service provisioning to bill- by refining enterprise business policies according ing. Maintaining the policy coherency before and to the assets of the information network. The con- after the negotiation and policy modification is cept of end-to-end network management based on mandatory. Although a theoretically complete policy based-SLA is shown in Figure 4. checking of policy coherency is in general a hard issue, a policy consistency and integrity tool in 4.2 Hierarchical policy enforcement the policy editor would enable much of the unde- architecture sirable side effects to be eliminated. Underlying Dynamic controls of IP services are specified OSSs make the resources at and below the net- as the policy rules. Since the controls are based work management layer available as manageable on individual events involving the network re- resources for the policy executor. sources (e.g., a state change notification) or the network/service management function (e.g., net- 4. Policy-based SLA2) work/service fault alarm), to execute the dynamic 4.1 End-to-end network management control, different types of policy rules reside in based on customers’ policies each management layer. To handle the policy rules In this section, we describe a new policy- based IP management service for enterprise Policy networks that incorporates a part of the above Management administrator Policy administrator’s view policies for mentioned negotiation concept. Since enterprise enterprise network users will be the main customers in the early stag- Enterprise network Policy dissemination es of a public IP network, end-to-end service Policy- based SLA management is needed if these business custom- Private network manager Public network service provider Private network manager Management ers are to trust and use the public network services operations Public IP network to establish their individual enterprise networks. Optical MPLS/ATM/SDH Optical Enterprise users will require management access network network access network WDM network of the quality and cost of their enterprise network Private network Private network assets to make them suitable for their business Public IP network goals, which determines the enterprise network Figure 4 management policies. An enterprise network com- End-to-end management based on customers’ policies. FUJITSU Sci. Tech. J.,37, 1,(June 2001) 75
    • K. Iseda et al.: IP Network Management System efficiently, we propose a hierarchical policy en- get is the managed object. Hence, the relation- forcement architecture. Figure 5 shows the ship can be paraphrased as follows: “If the architecture and three reference points: RP #1 to Condition becomes true, the Subject performs the #3. RP #1 is for policy-based SLA negotiation, RP Action on the Target.” #2 is for event notification, and RP #3 is for issu- Management policies can be categorized into ing management operations. two groups: 1) the policies that require the action The policy rules in an SLA are specified based of SM functions and do not require the action of on the management information model according NM functions and 2) the policies that require the to the customer’s point of view, and the model is action of NM functions and only optionally require presented to the customer by a service provider. the action of SM functions. It is necessary to trans- The policies are translated into a set of policies late a policy included in the SLA at SLA based on the TMN management information mod- negotiation in order to do the following: el (i.e., MOs) in the service provider. Regarding – To guarantee policy enforcement. When the the enforcement of policies within a TMN envi- policy requests a modification of the network ronment, the policies can be placed into two configuration, the executability of the action groups: QoS policies and management policies. to be taken by the NM functions should be Since a QoS policy is a rule guaranteeing the qual- checked based-on the network information ity of service for specified data flows, the QoS (MOs) before the acknowledgement of SLA policy must be refined so that the QoS is guaran- negotiation. teed within the network resources (elements) in – To check whether the policy causes a conflict which the target data flows can be identified. A with the management policy of the service management policy is a rule for invoking man- provider. Because the management policies agement operations in certain situations. In the of the service provider cover both SM and remainder of this section, we describe how the SM/ NM, the customers’ management policies are NM policy-translation block enforces the manage- translated into NML policies before the ac- ment policies. knowledgement of SLA negotiation. A management policy rule is represented by To maintain data consistency with the net- a combination of items: the Condition, Subject, work management information in NM functions, Action, and Target. The Condition is the trigger further refinement, including translation into pol- event. The Subject is the manager, and the Tar- icies enforced by EM functions, is not allowed. Within the SN/NM policy-translation func- tion block, the refined management policies are Enterprise network management function classified as policies enforced by the Network Customer side RP #1 RP #2 RP #3 Public network Management Systems (NMSs) and those enforced side SLA negotiation Operation handling NW service notification by the Service Management Systems (SMSs). SM policy SM functions Some policies must be adapted to prevent lookup SM/NM policy executor Function #1 Function #2 ... translation in the SM databases by NMSs. This enables in- NM policy NM functions dependent enforcement of all SM policies from the executor Function #1 Function #2 ... NM layer and the layers under NM if sufficient EM functions information is received in event notifications from SM: Service management NM: Network management the NMSs. In addition, all NM policies can be Network elements EM: Element management enforced independently from the SML. This de- ployment improves the performance of the policy Figure 5 Hierarchical policy enforcement architecture. enforcement. 76 FUJITSU Sci. Tech. J.,37, 1,(June 2001)
    • K. Iseda et al.: IP Network Management System 5. Fujitsu product architecture agement activities are controlled. SystemWalker In this section, we introduce Fujitsu’s focuses its enhancements on the management of IP-OSS products for supporting the features de- e-business. One of the management activities in scribed above. The Fujitsu IP-OSS architecture SystemWalker/CentricMGR is a centralized oper- (Figure 6) is based on a TMN functional archi- ation monitoring function based on a “business tecture (BML, SML, NML, EML, NEL). Common viewpoint.” Policy-based negotiation will be a core data sharing, load balancing, and distributed func- function in the concept. For the IP network, Sys- tions are realized by using CORBA. Each SML temWalker/IP NetMGR provides IP management product is related by a workflow engine, and fine- functions based on a “service viewpoint” and has grained services for users are promptly provided. the management scalability and reliability re- In the next section, we describe the main prod- quired by ISPs and carriers. ucts in Fujitsu’s product map. SystemWalker/IP NetMGR can have its mon- itoring servers in parallel, depending on the size 5.1 SystemWalker/CentricMGR and IP of the target network and the amount of informa- NetMGR tion (Figure 7). It also gives users great flexibility, SystemWalker is a total management prod- for example, it enables step-by-step addition of the uct family that manages all the elements monitoring menu and dynamic reconfiguration/ (resources) of an IT system, for example, the net- maintenance operations. For high-availability, it work, servers, storage, and applications. This has stand-by backup and dynamic switch mecha- family supports the IP resources operating in nisms for the monitoring servers. All the Figure 1. Its basic concept is Policy-based information collected by the monitoring servers Systems Management (PSM), with which all man- is automatically assembled into reports. These Customer Service order Billing management management Web access Trouble ticket Help desk Rating management OSS common base: CORBA, XML, EAI SML InterBond Service management Service order, Service test, Service fault, SLM Work-flow management Network ProactNes/SN ProactNes/PN planning Network management Policy-based network Configuration, Faults, management Oracle8 Network Performance, Testing Database (QoS, Security, etc.) SystemWalker design management Policy-based system Multi-vendor wrapper management NML INTERSTAGE Resource EML EMS GeoStream EMS for EMS for Directory management for CA element manager ATM access management NEL CA GeoStream ATM Servers MG (IP-GW) ER Figure 6 Fujitsu IP-OSS architecture. FUJITSU Sci. Tech. J.,37, 1,(June 2001) 77
    • K. Iseda et al.: IP Network Management System SystemWalker/IP NetMGR Management console Management servers Access points Monitoring servers SLA evaluation for each customer Trend analysis, capacity planning Figure 7 Example application of SystemWalker/IP NetMGR. reports can serve as Service Level Agreement (SLA) reports for the customers. • Network QoS policy • Network security policy etc. ProactNes/PN 5.2 GeoStream Element Manager Policy definition, check, distribution, etc. GeoStream Element Manager manages networks based on GeoSrtream, which is a next- < Dynamic policy management > > < Dynamic policy management Internet generation, large-scale, high-performance, IP Access Access switching node. It also supports the IP resources network IP core network network operating in Figure 1. Enterprise network Enterprise network For a large-scale, IP network management Carrier IP network system, high reliability through, for example, re- Figure 8 dundancy, congestion control, access permission ProactNes/PN: policy network manager. control, and scalability, is required. To satisfy these requirements, GeoStream Element Manag- er uses CORBA, Java, Clustering and other vendor connection is a key element function for object-oriented approaches as base technologies. supporting end-to-end service quality manage- ment, the system supports a mutual connection 5.3 ProactNes/PN and SN network between multi-vendor network elements. ProactNes/PN provides a policy-based man- This system will be used as a platform for future agement function to manage the quality of management services provided by a policy-based communication services. This system supports the SLA. Each IP network consists of several types provision of IP communication services and the of network elements that have different QoS IP resources operating in Figure 1. To maintain policy control mechanisms. ProactNes/PN is im- the IP network quality and security, ProactNes/ plemented with a modular structure to handle the PN dynamically controls the Quality of Service various QoS policy mechanisms, and it can be (QoS) parameter of related network elements us- applied to each grade of network and NE ing unified rules (policies) according to the state (Figure 8). of the IP network. Because managing a multi- ProactNes/SN provides the network topolo- 78 FUJITSU Sci. Tech. J.,37, 1,(June 2001)
    • K. Iseda et al.: IP Network Management System End-user A • VPN view for End-user B DSU/ONU each end-user End-user C DSU/ONU End-user A • SLA monitoring End-user B Core Core ATM/STM private line router ATM/STM private line Edge router Edge router router DSU/ONU DSU/ONU End-user C End-user A G-Ether G-Ether Core O/E network E/O O/E E/O 10/100 10/100 End-user C BASE-T BASE-T End-user B E/O E/O IP access line IP access line O/E O/E End-user A End-user A Figure 9 ProactNes/SN: service network manager. gy view of a Virtual Private Network (VPN) ser- attractive IP network field. We proposed a vice and an operator view for each end user policy/negotiation-based management service to (Figure 9). This system supports IP communica- provide dynamic, fine-grained, IP network service tion service provision. The term “end-user” here customization based on SLAs, including custom- means not only individual users but also contract er management policies. Then, we described our parties who use the carrier IP backbone networks, IP management products for supporting these for example, ISPs and ASPs. Also, ProactNes/SN management services. provides an SLA management function and ser- vice quality control function by inter-working with References ProactNes/PN. 1) ITU-T Recommendation: Principle for the Telecommunications Management Network, 6. Conclusion M.3100. ITU, Geneva, 1996. In this paper, we studied some of the require- 2) M. Ejiri, K. Iseda, and T. Hamada: IP Man- ments for IP management. We presented a new agement for e-business based on Negotiation. IP management framework which is based on the Telecom Asia 2000, December 2000. results of our study. This framework keeps up 3) IETF: draft-ietf-policy-terminology-00.txt. with diversification among IP services and cre- Jul. 2000. ates added value. We believe that negotiation is 4) K. Fukuda, M. Minoura, H. Ueno, K. Iseda, the key to IP management and that the negotia- and J. Yoshio: Policy-based Management Ar- tion mechanism proposed in this paper will help chitecture for Service Customization of realize high price-performance IP services, there- Heterogeneous Public IP Network. Telecom by winning the competition in the commercially Asia 2000, December 2000. FUJITSU Sci. Tech. J.,37, 1,(June 2001) 79
    • K. Iseda et al.: IP Network Management System Kohei Iseda received the B.E. and M.E. Hiroaki Abe received the B.S. and M.S. degrees in Telecommunication Engi- degrees in Communications Engineer- neering from Tohoku University, Sendai, ing from Tohoku University, Sendai, Japan in 1983 and 1985, respectively. Japan in 1984 and 1986, respectively. He joined Fujitsu Laboratories Ltd., He joined Fujitsu Ltd., Kawasaki, Kawasaki, Japan in 1985. He initially Japan in 1986, where he has been worked on research and development engaged in research and development of speech and audio coding. Since then, of network management systems for he has been engaged in research of telecommunications carriers. He is a network management systems. His re- member of the Institute of Electronics, search interests include distributed ob- Information, and Communication Engi- ject oriented technology and policy-based management. He is neers (IEICE) of Japan. a member of the Institute of Electronics, Information, and Com- munication Engineers (IEICE) of Japan. E-mail: abe@osd.ts.fujitsu.co.jp E-mail: iseda@flab.fujitsu.co.jp Junichi Sakuma received the B.E. and M.E. degrees in Electronic Engineering from Hokkaido University, Sapporo, Japan in 1975 and 1977, respectively. He joined Fujitsu Ltd., Kawasaki, Japan in 1977, where he has been engaged in development of network manage- ment software for mainframe computer networks, enterprise LAN systems, and IP-based networks. He is a member of the Information Pro- cessing Society of Japan. E-mail: sakuma.junichi@jp.fujitsu.com 80 FUJITSU Sci. Tech. J.,37, 1,(June 2001)