01 CN66561EN92GLA0 System Overview

System Overview

System Overview

Contents 1 1.1 1.2 1.3 1.4 2 2.1 3 3.1 3.2 3.3 3.4 3.5

General Tips for Troubleshooting Preface Logical approach Problem Solving Technique Data Collection Saving Sequence for Error Report Scope One-NDS Components Basic Knowledge Directory Concept Interfaces and Protocols Network Connectivity Ports Operating System Users and Rights

CN66561EN92GLA0 © 2014 Nokia Solutions and Networks

3 4 5 7 9 13 14 17 18 20 31 34 37

1

System Overview

2


System Overview

1

General Tips for Troubleshooting

Fig. 1 General Tips for Troubleshooting


3

System Overview

1.1

Preface

Troubleshooting, by its nature, is a tough subject to teach. You start with any of a world of symptoms and try to work your way back to the cause. We can't cover the whole gamut of problems you may encounter, but we will certainly do our best to show how to diagnose the most common of them. And along the way, we hope to teach you troubleshooting techniques that will be valuable in tracking down more obscure problems that we don't document. This course covers a selected subset of troubleshooting situations and tools for the One-NDS 9.0 system. Use of these tools should be at the direction of Nokia Solutions and Networks Service personnel as some processes may affect the performance of the Network Elements under test. Troubleshooting and collection of Error Symptoms for the One-NDS 8.0 system are contained in the Customer Documentation. Please refer to it for additional information. WARNING Information is not intended to replace the One-NDS 9.0 Service Manual for Maintenance, Diagnostics and Emergency and does not cover any Operator specific tools.

4


System Overview

1.2

Logical approach

A logical approach is helpful when troubleshooting any problem. Some common questions to ask during troubleshooting include the following: 

What works?



What does not work?



How are the things that do and do not work related?



Have the things that do not work ever worked?



If so, what has changed since it last worked?

The answers to these questions can indicate where to begin troubleshooting, possibly allowing you to isolate the component, layer, or configuration issue that is causing the problem.


5

System Overview

Common questions to ask when troubleshooting

• A logical approach is helpful when troubleshooting any problem. • Some common questions to ask during troubleshooting include the following:

-

What works? What does not work? How are the things that do and do not work related? Have the things that do not work ever worked? If so, what has changed since it last worked?

• The answers to these questions can indicate where to begin troubleshooting, possibly allowing you to isolate the component, layer, or configuration issue that is causing the problem.

1

©2014 Nokia Solutions and Networks. All rights reserved.

Fig. 2 Common questions to ask when troubleshooting

. . . . . . . . . . . . . . . . . . . . .

6

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .


System Overview

1.3 1.3.1

Problem Solving Technique Appreciation

Appreciation is a very simple but powerful technique for extracting the maximum amount of information from a simple fact. How to Use: Starting with a fact, ask the question 'So what?' i.e. what are the implications of that fact? Keep on asking that question until you have drawn all possible inferences. Example: Fact: It rained heavily last night. So What? The ground will be wet So What? 

It will turn into mud quickly So What? 

If many vehicles pass over the same ground, movement will be progressively slower and more difficult as the ground gets muddier and more difficult. So What? 



Where possible, stick to paved roads. Otherwise expect movement to be much slower than normal.

While it would be possible to reach this conclusion without the use of a formal technique, Appreciation provides a framework within which you can extract information quickly, effectively and reliably. Key points: Asking 'so what?' repeatedly helps you to extract all important information implied by a fact.


7

System Overview

1.3.2

5 Whys

Quickly Getting to the Root of a Problem: Why use the tool? The 5 Whys is a simple problem-solving technique that helps you to get to the root of the problem quickly. Made popular in the 1970s by the Toyota Production System, the 5 Whys strategy involves looking at any problem and asking: "Why?" and "What caused this problem?" Very often, the answer to the first "why" will prompt another " why" and the answer to the second "why" will prompt another and so on; hence the name the 5 Whys. 

It helps to quickly determine the root cause of a problem



It is easy to learn and apply

How to use: When looking to solve a problem, start at the end result and work backward (toward the root cause), continually asking: "Why?" This will need to be repeated over and over until the root cause of the problem becomes apparent.

TIP The 5 Whys technique is a simple technique that can help you quickly get to the root of a problem. But that is all it is, and the more complex things get, the more likely it i s to lead you down a false trail. If it doesn't quickly give you an answer that's obviously right, then you may need more sophisticated technique problem solving techniques.

8


System Overview

1.4

Data Collection Saving Sequence for Error Report

When an error occurs, the basic error symptoms and the error symptoms according to the error class should be saved as soon as possible. The reason for quick action is that data, which is essential for error diagnosis and stored in cyclic error symptom files or in the memory, could be overwritten and lost.

General Troubleshooting Instructions

Collect information

Analyze cause

Design solution

Implement solution

Test solution

1


Fig. 3 General troubleshooting instructions

The following slide sums up the procedure that needs to be handled in order to report effectively an error.


9

System Overview

Basic Error Reporting

• Save the basic error symptoms immediately - List the alarms indicated in the @vantage commander - Describe the error situation and all system relations, including all (operator) actions taken before and after the error. - Save the specific error symptoms which “may” require the following.

• Network Trace • HealthChecks • Subscriber Specific Trace at direction of NSN Service - Determine the Error Priority - Open Fault report in RESOLVE. Fill out the error report, and attach the error description as well as the error symptoms !

1


Fig. 4 Basic Error Reporting

Collecting Symptoms for the One-NDS is realized as a generic shell script available on all the network elements provided by the installation. The script is installed with the One-NDS “cntdb_common” package and stored under: /o p t/c n td b /b in /c o l lec t_s y m p to m s .

. . . . . . . . . . . . . . .

10

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .


System Overview

1.4.1

The collect_symptoms utility

This utility stores multiple types of information gathered in 3 different categories: 

Global system information



Global One-NDS information



Node specific application information

The global system information are gathered by the subscript s u p p o r t c o n f i g . This script is available on all different node types. The s u p p o r t c o n f i g script is part of supportutils-1.01-xx.x.noarch.rpm package provided from NOVELL (not part of SLES10 distribution). For more detailed information please visit: http://www.novell.com/communities/node/2332 In order to retrieve the global One-NDS information, the c o n f i g . s h subscript is executed. Also, this script is available on all different node types and stores e.g. the installed medium information (/opt/cntdb/etc/Media). Finally, the Node specific application information are retrieved executing applicationrelated own symptom collection script which in turn get executed by the master script in order to support application specific symptom collection. c o l l e c t _ s y m p t o m s -p will print the available application script for t his specific node type (server role). The slide on the right hand side shows you an example of the running of the script on a BE-DS. The script has to be executed with r o o t user.


11

System Overview

.

cdb2be2:/ # collect_symptoms collect_symptoms - version 8.6.3 run script /opt/cntdb/etc/symptoms.d/apertioDS.sh /tmp/cdb2be2_120918_0825/apertioDS.sh ... DS is running Writing status message to AQ17 Writing measurements message to AQ17 The Attribute (bgReconKeyFieldCnt) was not found done ! run script /opt/cntdb/etc/symptoms.d/config.sh /tmp/cdb2be2_120918_0825/config.sh ... done ! run script supportconfig /tmp/cdb2be2_120918_0825/supportconfig ... done ! Creating tarball --[ DONE ]------------------------------------------Log file tar ball: /tmp/cdb2be2_120918_0825.tar.bz2 Log file size: 4.7M ----------------------------------------------------cdb2be2:~ # Fig. 5 Executing the collect_symptoms utility on a BE-DS

Here, we can see that the script is divided into multiple subparts that are executed one after the other, collecting each time a different type of information. The following picture is the execution of the script on a PGW: .

cdb2pgw1:~ # collect_symptoms collect_symptoms - version 8.6.3 run script /opt/cntdb/etc/symptoms.d/ pgw.sh /tmp/cdb2pgw1_120918_0850/pgw.sh ... info: Dumping list of processes and top. info: Searching for instances. info: Found 2 instances: instance_li instance1 […]

run script /opt/cntdb/etc/symptoms.d/config.sh /tmp/cdb2pgw1_120918_0850/config.sh ... done ! run script supportconfig /tmp/cdb2pgw1_120918_0850/supportconfig ... done ! Creating tarball --[ DONE ]------------------------------------------Log file tar ball: /tmp/cdb2pgw1_120918_0850.tar.bz2 Log file size: 23M ----------------------------------------------------cdb2pgw1:~ #

Fig. 6 Executing the collect_symptoms utility on a PGW

The main difference here as we can see is the execution of an additional script called p g w . s h that stores the information related to the Provisioning Gateway functionality.

12


System Overview

2

Scope

Fig. 7 Scope


13

System Overview

2.1

One-NDS Components

The troubleshooting of the One-NDS system must start by identifying its components. In this case, it is better to distinguish them by their function rather than by their hardware. Indeed, all of them are running on the same HW platform. The OS running on all is SuSe Linux Enterprise Edition v10. We can distinguish the following functions: NDS The Network Directory Servers (later simply called DS) are the core elements of the One-NDS, forming together DSAs on which the DBs are stored. The data base where subscribers at stored consists of routing DSA cluster and the BE-DSA clusters. The BE-DSA clusters are the part of the directory that does contain the actual data content. The routing DSA stores access keys and references to the database entries (subscriber data) The PGW-DSA (Config DSA) is used to store the configuration data of the PGW. The configuration data provides information about the typology of the One-NDS Directory: number of DSs of routing DSA and PGW DSA, distribution of these DSAs over geographical sites, number and IDs of BE DSAs, IP addresses, presence of separate application LAN, presence of PGWs, their IP addresses, distribution of PGW geographical sites, and so on 

Provisioning Gateway (PGW) Transactions from the Customer Care Center (CCC) systems ar e forwarded to the provisioning gateway, processed there (selecting the DSA, where the subscriber will be stored), and then forwarded to the Data Base. The lightweight directory access protocol (LDAP) interface is used to transfer these transactions to the database. LDAP is based on the X.500 standard, but unlike X.500, LDAP supports TCP/IP access. 

Notification Manager (NTF) Either as a standalone or part of the PGW-DSA, the NTF is a central component for distributing all notifications from One-NDS components to both PGW and application servers. The NTF stores the subscription information from different applications in the One-NDS Directory. 

System Monitor (SM2) The NetAct System Monitor is introduced as an integral part of the One-NDS that provides standard interfaces that can be integrated to a third party Network Management System (NMS) for fault and performance management. One-NDS is integrated to NetAct via the System Monitor. Fault and Performance management data are collected from One-NDS components by the SM, aggregated and filtered, then reported to NetAct. 

14


System Overview

One-NDS Administrator (ADM) The One-NDS Administrator (ADM) is an independent management system used for the administration of One-NDS Directory, PGW configuration, and Notification Manager (NTF). Over the ADM, authenticated clients and authorized users can perform tasks, for example, in the One-NDS Directory. The tasks include relocating subscribers from one BE DSA to another, monitoring subscriber data storage, schema management, checking data consistency and administrating new DSAs. 

Here is an illustration of the main functional components of One-NDS that will be seen throughout the course:

components

NDS

PGW

NTF

ADM

SM2

INS

SLES 11 platform

e.g. Oracle Netra / HP Blade

NDS = Network Directory Server PGW = Provisioning Gateway NTF = Notification Manager ADM = One-NDS Administrator INS = Installation Server SM2 = System Monitor 1


Fig. 8 One-NDS main functional components


15

System Overview

16


System Overview

3

Basic Knowledge

Fig. 9 Basic Knowledge


17

System Overview

3.1 3.1.1

Directory Concept General

Directories provide a versatile way of organizing information and are highly appropriate for modeling the typical hierarchical relationships between data objects in the real world. For One-NDS, a standard X.500 directory has been selected in accordance with the International Telecommunication Union’s X.500 series of recommendations as the preferred structure for arranging information within t he directory. Storage capacity is virtually unlimited and directory performance is not affected by increases in data volume. In simple terms, a Directory is a database that follows the structure and features defined in the X.500 standards. The data is stored in a directory structure, hence the term ‘Directory’. Telecoms applications require fast access to potentially millions of subscriber entries. The Directory provides this because of two key features: 

Data is held in memory (as opposed to on disk) making access very fast.



The directory structure allows for efficient retrieval of data

3.1.2

Directory model definitions

The following terms which we will use during this course are defined in ITU-T Rec. X.501:

18



Access control



Alias



Attribute



Attribute type



Attribute value



Directory Information Tree (DIT)



Directory System Agent (DSA)



Directory User Agent (DUA)



Distinguished name (DN)



Entry



Hierarchical group



Object (of interest)



Relative distinguished name (RDN)



Root


System Overview

The directory data will then be available for a specific application part to access via LDAP, as shown on the following figure:

MSC/VLR

SGSN

MMSC

SMSC

Network Layer IP network

Service Layer (dataless)

SS7 network

HSS

HLR

EIR

AAA

Data Layer

PCS

One-NDS

1


Fig. 10 Elements involved in the access to One-NDS

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

19

System Overview

3.2

Interfaces and Protocols

In this part, we will describe the interfaces of each One-NDS component type and the associated protocols used in the communication.

3.2.1

R-DSA/BE DSA Interfaces

The main One-NDS Directory (routing/BE DSA) interface between the routing/BE DSAs and application servers is the LDAP interface. It is used for read-only and update requests.

3.2.1.1

Interface to NTF

The routing/BE DSAs send trigger notifications to t he Notification Manager (NTF). Protocol: SOAP

3.2.1.2

Interface to ADM

One-NDS Directory management functions can be performed from an ADM client (GUI) over this interface. These functions include the management of the One-NDS Directory scheme and LDAP users, DSA administration, subscriber relocation, and ADM configuration. Protocol: LDAP

3.2.1.3

Interface to PGW

The PGW server sends all provisioning requests to the routing DSA. The provisioning requests are handled differently in the PGW server. The corresponding provisioning results are sent from the routing DSA to the PGW server in the opposite transmission direction. Protocol: LDAP

3.2.1.4

Interface to B&R

In addition to the backup files and logs saved daily on the DS local hard disks, a daily backup of the same DS backup files and logs is performed at the B&R server. Protocol: SFTP

3.2.1.5

Interface to INS

The INS is first used to load the DS software and then used to perform software updates. Protocol: SFTP, BOOTP, TFTP

3.2.1.6

Interface to SM

Network element management (NEM), like fault management, is performed over this interface, which connects the DSAs to the @vantage Commander server and clients. Protocol: SSH and SNMP

20


System Overview

3.2.1.7

Interface to APP-FE

Read-only and update requests are received by the routing DSA directly from the application server (APPL).The routing DSA forwards such requests to specific BE DSAs. In the case of read-only requests, responses containing the required information are sent by the BE DSAs over the routing DSAs to the relevant applications. After updates have been successfully performed in the BE DSAs at all sites, corresponding responses are sent over this interface to the applications. Protocol: LDAP This information is summed up on the following figure:

NTF

SOAP

ADM

PGW

B&R

INS

SM2

LDAP

LDAP

sFTP

sFTP

RMTP

APPL

LDAP

R-DSA

BE-DSAs


Fig. 11 Routing/BE DSA Interfaces


21

System Overview

3.2.2

PGW DSA Interfaces

The main PGW DSA/Config DSA interfaces are LDAP-based interfaces between the PGW server and PGW DSA/Config DSA. They are used for storing the PGW configuration and act as an intermediary server between the PGW and the One-NDS Directory (routing DSAs and BE DSAs) Configuration data is received from the PGW server (or ADM) over these PGW DSA/Config DSA interfaces and then forwarded as configuration data information to the routing DSAs.

3.2.2.1

Interface to PGW Server

The PGW stores configuration data on the PGW DSA/Config DSA. The PGW DSA/Config DSA acts as an intermediate server between the PGW and the OneNDS Directory (routing/BE DSA). Protocol: LDAP

3.2.2.2

Interface to ADM

PGW DSA/Config DSA management functions can be performed from an ADM GUI client over this interface. These functions include managing the PGW application administration, PGW configuration data, and PGW user management. Protocol: LDIF and SSH

22


System Overview

This information is summed up on the following figure:

ADM

PGW

B&R

INS

SM2

SSH

LDAP

sFTP

sFTP

RMTP

LDAP

PGW-DSA

Fig. 12 PGW DSA interfaces

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

23

System Overview

3.2.3

Notification Manager (NTF) Interfaces

The Notification Manager (NTF) interfaces are SOAP-based interfaces between the NTF and application servers, Routing/BE DSAs, and PGW. They are used for example for transferring trigger messages from the subscriber data directories to applications. Subscription requests are received from the applications over the NTF interfaces and forwarded as application server subscription information to the Routing DSAs. Furthermore, the NTF can send trigger subscription messages to the Routing DSA/BE DSAs. In the opposite direction, the NTF receives trigger messages from the Routing DSA/BE DSAs that are sent as notifications to the applications and to the PGW.

3.2.3.1

Interface to ADM

NTF management functions can be performed from an ADM client (GUI) over this interface. These functions include the configuration management of the NTF configuration data and NTF subscription data, as well as fault management, performance management, etc. The SOAP protocol is used for update of configuration data, the LDAP is used for configuration change, and the SSH protocol is used f or start/stop/status. Protocol: SOAP, LDAP, SSH

3.2.3.2

Interface to APPL

The application servers are subscribed with detailed subscription data in the NTF over this interface. The NTF receives triggers from the One-NDS Directory and forwards it to the subscribed applications and to the PGW. Protocol: SOAP

3.2.3.3

Interface to R-DSA /BE-DSA

As mentioned earlier, the NTF receives the triggers from the primary servers running on R-DSA and BE-DSAs. Once the Trigger condition is fulfilled and detected on the DS, the trigger is directly sent to the NTF along with the su bscription information, so that the NTF knows how to handle such trigger. Indeed, the notifications sent from the NTF to the applications depend on the type of data modified (Broadcast, Round Robin…). Protocol: SOAP

24


System Overview


ADM

PGW

B&R

SSH

SOAP

sFTP

INS

SM2

sFTP

RMTP

R-DSA/BE-DSA APPL

SOAP

SOAP

LDAP

PGW-DSA or stand-alone

NTF

Fig. 13 NTF interface

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

25

System Overview

3.2.4

Provisioning Gateway Interfaces

The main PGW interface is the SPML provisioning interface between the PGW and CRM/CCC, which is used for subscriber data management. Subscriber data is administered using this SOAP-based SPML provisioning interface over HTTP. Bulk files (for example, for SIM card management) or a selected set of subscriber data is entered over this interface. For this purpose, this SPML provisioning interface is based on sFTP. As an alternative to the provisioning GUIs provided in the CRM/CCC, an SPML provisioning GUI for administering subscriber data can also be integrated at screen-level into @Com on customer request (currently available for HLR or HSS applications).

3.2.4.1

Interface to ADM

PGW management functions can be performed from an ADM client (GUI) over this interface. Regarding the PGW, the only protocol used in that is the SSH protocol for start/stop/status display. Protocol: SSH

3.2.4.2

Interface to CCC

The administration of subscriber, authentication and service data is performed over this SPML interface based on SOAP over HTTP. A provisioning GUI client is also available for administration. Furthermore, the CRM/CCC (Customer Care center) sends bulk files containing the multiple SPML request over the other SPML interface using secure FTP (sFTP). Protocol: SPML

3.2.4.3

Interface to NTF

The PGW receives notifications from the NTF. Protocol: SOAP

3.2.4.4

Interface to R-DSA

The PGW communicates with the R-DSA for transactions and read-only requests. This is basically the continuation of the messages received from the CCC after translation to LDAP protocol by the plug-ins running on the PGW. Protocol: LDAP

26


System Overview


PGW-DSA ADM

LDAP

SSH

NTF

B&R

SOAP

sFTP

INS

SM

CCC

sFTP

RMTP

SPML

R-DSA

LDAP

PGW

Fig. 14 PGW interfaces

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

27

System Overview

3.2.5

One-NDS Administrator (ADM) Interfaces

Administration tasks are performed over the ADM. All functions can be conveniently carried out over the ADM GUI, which can be launched from the @Com client. Furthermore, data directory management is integrated in the @Com fault management, and secure shell (SSH) access from @Com to the ADM is supported.

3.2.5.1

Interface to NEM

Network element management, such as configuration and fault management, is performed over this interface, which connects the ADM t o the @vantage Commander server and clients. LDIF files can also be received by the ADM from the schema designer over the @Com and the sFTP interface. The ADM then uses these LDIF files to update the One-NDS Directory schema on all DSAs within the in-memory LDAP of the One-NDS Directory. Protocol: SNMP, sFTP, SSH

3.2.5.2

Interface to R-DSA/BE DSA

One-NDS Directory management functions can be performed from an ADM GUI client (DB management part) over this interface. These functions include the configuration management of the One-NDS Directory schema and LDAP users, DSA administration, subscriber relocation, and ADM configuration, as well as f ault management, performance management, etc. Protocol: LDAP

3.2.5.3

Interface to PGW-DSA

Over this interface, PGW configuration, secure administration of PGW passwords, and browsing and downloading command logs can be performed using @Com. For this purpose, the ADM GUI is integrated at screen-level in the @Com clients. Protocol: LDIF and SSH

3.2.5.4

Interface to NTF

NTF management functions can be performed from an ADM client (GUI) over this interface. These functions include the configuration management of the NTF configuration data and NTF subscription data, as well as fault management, performance management, etc. Protocol: LDIF and SSH

28


System Overview


R-DSA/BE-DSA

B&R

INS

SM2

PGW-DSA

NTF

PGW

LDAP

sFTP

sFTP

RMTP

SSH

SSH

SSH

SSH

LDAP

ADM

Fig. 15 ADM interfaces

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

29

System Overview

3.2.6

Interfaces and Protocols wrap-up

Here is a wrap up on all interfaces and protocols used either when accessing or inside the One-NDS:

PGW-DSA incl. NTF

LDAP Notify SOAP

Notify SOAP

Trigger SOAP

SPML SOAP

CRM

PGW LDAP ssh LDAP

ADM

application FEs

HLR

HSS

AAA

LDAP

R-DSA

BE-DSAs

Fig. 16 Interfaces and Protocols wrap-up

30


System Overview

3.3

Network Connectivity

In order to separate the traffic taking place between specific elements inside the OneNDS and for security reasons, multiple networks are used. According to the type of communication taking place, we also need two types of communication infrastructure: 

Local-site Network



Inter-site Network

3.3.1

Local-site network

This network is implemented as an IP local area network (LAN). The local site network interconnects servers located at the same physical locations. Typically, the LAN is deployed as a switched Ethernet network. The LAN provides full path redundancy, that is, at least two independent paths must be available between any two servers that have direct connections. This includes cabling as well as switches used in the network. The local-site network is used for the following purposes:

3.3.1.1

OAM LAN and B&R LAN

The OAM network carries the remote management traffic used to perform the various management tasks for: 

Alarm forwarding



Availability management.



Remote management.



Software update management.



Backup and restore.



Administration.

3.3.1.2

Application LAN

The application network carries the client-side traffic to the One-NDS entities: 

Basically all LDAP requests issued from clients to the routing DSA.



SPML requests submitted to the provisioning gateway.


31

System Overview

3.3.1.3

Data Base LAN

The Database network carries out the requests between the Routing-DSA and the BE-DSAs. The connections between all database servers shall be gigabit Ethernet for performance reasons. The latency of the network impacts directly the response times of the database for update requests (since the data on the BE-DS of a triplet are always kept in synch.).

3.3.1.4

HLR/AuC LAN

A good example of a strictly local-site network is the HSM LANs (HLR/AuC LAN), implemented on dedicated hardware. The HSM LANs will only connect HLR -FEs and HSM modules; the LANs will not be visible from any other part of the network. Therefore, this LAN will not be discussed during the course.

3.3.2

Inter-site network

This network is implemented as an IP wide area network (WAN). The inter-site network connects the different sites with each other for One-NDS Directory inter-site traffic. This is deployed as a wide area network (WAN) because the sites are typically deployed approximately one hundred kilometers apart f rom one another. A dedicated network between the sites is highly recommended for exclusive use by One-NDS and application servers. The inter-site network is used for the following purposes:

3.3.2.1

OAM LAN and B&R WAN

The OAM WAN is used by the One-NDS Directory for inter-DS re-synchronization after routing/BE DSA server failure (makes copy of backup and log files).

3.3.2.2

Application WAN

The application WAN can be used in various cases: 

To allow an application server to access the One-NDS Directory if an application server is not deployed locally.



To access the PGW from customer care and operations systems.



To access to a remote One-NDS Directory site if a local one is unavailable.

3.3.2.3

Data Base WAN

The Database WAN is used in case of One-NDS Directory updates synchronization for servers belonging to the same Routing/BE DSA and also to read traffic if a local routing/BE DSA fails.

32


System Overview

These different networks and the elements using them are summed up in the following figure:

One-NDS components

non One-NDS components

IS

B&R

BE-DSA

R-DSA

ADM

SM

CRM

OAM B&R APP DSA

PGW

HLR

PGW-DSA

HSS

AAA

Fig. 17 Summary of Network Connectivity inside One-NDS

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

33

System Overview

3.4

Ports

For each type of communication towards or inside the One-NDS, we distinguish, along with the protocols used, specific ports. The list is long, but here are the most important ones to remember, again, classified by functional components.

34

Protocol

Ports

Purpose

LPDAP

16601

Low priority DAP; Currently not used by NSN

DSA_INTER

16602

Inter-DSA communications; for example, search / update chaining

SCF_PROV

16603

“Provisioning”; a form of DAP with bespoke TCP/IP wrappers

SDF_STATUS

16606

Bespoke protocol for enquiring the status of a DS server

nms_alarm

16608

Bespoke protocol for DS alarm events

nms_stats

16609

Bespoke protocol for triggering statistics file (af03) rotation

SDF_INTER

16610

Inter-DS replication

LDAP

16611

LDAP service interface

MODE_LDAP

16612

Mode sensitive LDAP - responds only on Primary or Secondary Synchronized servers

DS_RECON

16613

Inter DS Reconciliation monitoring

DS_NONDIR

16614

Non-Directory Data. In particular, used in the processing of Variant Objects

LDR_CLIENT

16616

Inter DSA router client port

DS_NDDR

16617

Local nddr connections

DS_ALIAS

16618

Alias verification utility port

DS_SNMP

16650

DS SNMP Port

SOAPC

16700

DS SOAP Client port

SYCOLINK

16701

Sync Controller port


System Overview

Protocol

Ports

Purpose

SOAP

1008110090

SOAP port for trigger reception

ICMP

Internet Control Message Protocol

SSH

22

Secure shell service for remote maintenance

SSH

22

Used for software update mechanism via installationserver

SFTP

22

Secure FTP service for bulk data transfer

TFTP

69

Used for first installation of the network element

RPC

111

RPC bind for NFS

NFS

2049

For transfer of software from the installation server

NTP

123

NTP client to keep the system time synchronized among the servers

SNMP

161

SNMP service to receive management requests

SNMP

162

SNMP service to receive management traps

SNMP

43821

Simple Network Management Protocol

SOAP / SPML

80818090

SOAP embedded SPML service

HTTPS

443

Web GUI, SOAP over HTTPS

HTTPS

8443


HTTPS

11000


Proprietary

55504

Used for first installation

Proprietary

55555

Control port for software upgrade

Proprietary

79379936

Communication for backup & restore (NEBR)

Proprietary

1000130000

Communication for backup & restore (NEBR)


35

System Overview

These different protocols and the elements using them to communicate are summed up in the following figure: PGW HTTPS 30600

HLR

HSS

CRM

SPML-file/SFTP

LDAP 16612

application FEs

SPML-SOAP-HTTP 8081-8090

LDAP 16612

PGW-DS incl. NTF

AAA

SOAP 30300

LDAP 16611

SOAP 1018010181

NTF

SOAP 1018010181

R-DSA INS

BOOTP TFTP

ADM

SSH LDAP

B&R

SSH SFTP

DAP, DOP, DSP

Networks

APP OAM DB/DSA

BE-DSA

1


Fig. 18 Summary of Protocols used by One-NDS

F

36


01 CN66561EN92GLA0 System Overview

Recommend Documents