KR100542360B1 - The method for Network Element management indepenent on network layer - Google Patents

Abstract

The present invention relates to a method for providing a network management interface, and more particularly, to a network management method for managing a network by enabling data transmission and reception regardless of a communication network layer in remote device management using TL-1. The present invention does not depend on the lower transport layer that physically transmits management information, and efficiently processes the NE by allowing a proxy task of the destination NE to process a message for providing the management information of the corresponding NE to an external management device. It can be managed. This enables management interfaces to be applied to separate communication systems with minimal effort.

Description

The method for network element management indepenent on network layer}

1 is a view showing a network management interface system according to the prior art.

2 is a diagram illustrating an NE management system according to the present invention.

3 (a) is a diagram showing a data request packet

3 (b) is a diagram showing a data indication packet (data indication packet)

4 is a diagram illustrating a response process to a message request according to the present invention.

5 is a flowchart illustrating a system initialization process according to generation of a proxy task according to the present invention.

6 illustrates a proxy request database according to the present invention.

7 is a flowchart illustrating remote NE access according to indirect routing determination according to the present invention.

8 is a flowchart of processing a timeout when there is no response after a message request according to the present invention.

9 is a flowchart illustrating a case in which there is a response according to a message request according to the present invention.

The present invention relates to a method for providing a network device management interface using a communication network, and in particular, a network for remotely managing by an operator by enabling data transmission and reception irrespective of a communication network layer in remote device management using a TL-1. It relates to the equipment management method.

TL1 (Transaction Language 1) is a protocol for the maintenance of telecommunications equipment established by Bellcore, Telcoreia, USA in the early 80's. The Man-Machine Language of the ITU-T Z.3XX series It is a message delivery system between an operating system (OS) and a network element (hereinafter referred to as NE) written based on

In addition, TL1 defines the commands and response messages for maintaining and managing a communication network of communication devices and devices, and the rules for preparing these commands and response messages. Is an administrative command

1 is a view showing a network management interface system according to the prior art. As shown, the conventional network management interface system is characterized by consisting of a GNE (Gateway Network Element) (GNE) and a separate Sub-Network Element (SNE).

The GNE is a NE that acts as a waypoint between the external management equipment maintained by the operator and the individual NE. The GNE is connected to the external management equipment through a LAN, while the individual SNE is connected to the GNE and the IPC channel (Inter Processor Communication channel). Through IPC).

In the prior art, in order for an operator to access an NE individually to manage a remotely located NE, an OAM (Operations, Administration) of an individual SNE through an IPC channel using only a network address from an agent task of GNE. and Maintenance (hereinafter OAM) task to send a message.

The NE's response to the request message sent at the request of the operator is made by the OAM task of the individual SNE to the agent task of the GNE directly connected to the management equipment.

OAM refers to a group of network management functions that provide network fault indication, performance information, and data and diagnostics. In the present invention, alarm, performance, configuration, security, and the like are described. it means.

In the prior art, the agent task of the NE that handles the situation cannot manage the message, causing confusion to the real administrators. In addition, only the IPC protocol specialized for the equipment can be used to transmit and receive messages, and general protocols such as IP / OSI cannot be used.

For example, in the prior art, when an external management device tries to send a management message to SNE # 3, an agent task of GNE # 1 directly connected to the external management device receives a message and simply sends the message information to the OAM task of SNE # 3. SNE # 3 forwards the response to the agent task of GNE # 1.

At this time, the agent task of GNE # 1 adds its name (# 1) to the message and sends it to the external management equipment. Therefore, the administrator sent a message to SNE # 3, but received a message that seems to be processed and sent by GNE # 1.

Therefore, in the prior art, the agent task of the NE that is the destination of the external management equipment message, that is, the SNE does not receive the message, and the directly connected NE, that is, the agent task of the GNE, receives the message, so that the destination NE can manage the message. Problem occurs. Therefore, there is a problem that the external management equipment receives NE information which may cause confusion.

In addition, in the system according to the above structure, in the case of an auto-generated message, the generated NE information is not transmitted, but the information of the NE directly connected to the management equipment is transmitted.

In addition, in order to exchange management information between NEs, only through a specialized IPC channel, there is a problem that transmission and reception of messages are not possible in standard and popularized lower layer protocols such as IP and OSI.

On the other hand, the above-described problem of the prior art is equally applicable to a multiplex section shared protection ring (MSSPR) network structure in which a plurality of NEs are connected and operated in a ring structure.

Basically, the MSSP system has a dual management network structure. That is, a management interface with an external management device such as an external EMS may be an Internet Protocol (IP) or an OSI, and a management interface between NEs is a DCC (Data Communication Channel). I am using OSI. Therefore, for management in the whole N / W, it must be able to handle both IP and OSI protocols.

Therefore, when each NE has a structure of exchanging management information through DCC or IP in the MSSPR network, the external management equipment is directly connected to the Gateway NE (GNE), and several other NEs connected in a ring structure are GNEs. It must be managed through. As a result, in order to solve the same problem as described above, there is a problem in that the manager must be able to access and operate the remote NE through the GNE directly connected to the management equipment.

The present invention is to solve the above-mentioned problems, and does not depend on the lower transport layer for physically transmitting management information, and provides a message for providing the management information of the corresponding NE to the external management equipment by providing a proxy ( proxy) It aims to provide a way to manage NE efficiently by letting it be handled by tasks.

In order to achieve the above object, the present invention, in the network consisting of the external management equipment driven by the operator and the individual NE connected to the external management equipment for transmitting and receiving messages for management information, regardless of the communication layer external Characterized in that the transmission and reception between the management equipment and the individual NE is possible.

On the other hand, in the present invention, the individual NE is specifically equipped with a DCU board to perform the OSI tasks through the DCC, and also by embedding the MPU board with the assumption that the IP communication task is also configured to perform the same.

In describing the present invention, if it is determined that the detailed description of the related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. In addition, the terms to be described later are defined in consideration of functions in the present invention, which may vary according to a user's intention or custom, and the definitions should be made based on the contents throughout the present specification. Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

2 is a diagram illustrating a NE management system according to the present invention.

The present invention further includes proxy tasks, IP / IPC communication tasks in addition to agent tasks and OAM tasks performed according to the prior art in the MPU board, and further includes OSI tasks in the DCU board, thereby transmitting and receiving IP data through a general LAN or DCC. OSI data transmission and reception are enabled.

The MPU board has a built-in IP stack, while the DCU board has an OSI stack to identify and route each NE.

In the present invention, the digital communication channel (DCC) of the SDH (Synchronous Digital Hierarchy (Synchronous Digital Hierarchy)) physically flowing through an optical port between each NE is used to transmit management information between individual NEs, or a digital signal. In order to perform transmission and reception of a general LAN (LAN) can be used.

SDH is a standard technology for synchronous data transmission on optical media and is internationally equivalent to SONET, the US standard for synchronous data transmission on optical media. Both technologies are faster and less expensive to access networks than traditional PDH (Plesiochronous Digital Hierarchy) devices.

As described above, the individual NE according to the present invention is characterized in that the MPU board to enable communication using IP over a LAN and, in particular, the DCU board to enable optical communication through the DCC. In this case, OSI stack using DCC, TCP / IP stack using LAN, and internal interprocess communication (IPC) may be used as the lower layer that can communicate.

When using IP, a combination of IP address and port is used to designate the NE, and when using OSI, a network service access point (NSAP) and a transport service access point (NSAP) Transport service access point (TSAP). NSAP refers to the boundary point between a user and a service when using a network service, and is defined in the third layer (network layer) and the fourth layer (transport layer) of the OSI basic reference model.

The address for identifying this access point is specified in ISO 8343 and ITU-T Recommendation X.213 as the address of the Network Service Access Point (NSAP). The NSAP address format can correspond to a variety of networks that require a hierarchical addressing system, such as X.121 for X.25 packet switching and E.164 for Integrated Services Digital Network (ISDN). ATM addresses specified in the ATM Forum's User-Network Interface (UNI) specification are also based on NSAP addresses.

In addition, TSAP refers to a deadlock prevention technique that provides an optimal routing path with minimal information. In the present invention, the NSAP is configured through a system ID and a station ID assigned to the NE, and the TSAP uses a well known value in advance.

Basically, a task can be divided into a management task and a transfer task that transfers management information thereof. The management task in the present invention is a TL 1 task, and the management task will communicate using the same API using the IP / OSI / IPC task. The management task exchanges management information through a transfer protocol between the NE and the OS, and the transfer task transmits actual management information.

In order to realize the above, the present invention first creates a proxy task in the NE and then initializes a database for managing each message. At this time, it should be noted that the database is formed in the memory in the MPU board embedded in the individual NE and is not separately shown.

When the database initialization is completed, create each task for DCC, IPC, UDP / IP communication, and then register the proxy task to communicate with so that the proxy task can use the channel. At this time, the DCC enables optical communication as described above, and the IPC performs specialized communication.

On the other hand, UDP (User Datagram Protocol) is a communication protocol that provides only limited service when messages are exchanged between computers in a network using IP. UDP is sometimes referred to as UDP / IP when used with IP as an alternative to TCP.

The present invention is characterized in that the proxy task is generated and registered in an individual NE, so that the proxy task can receive and process data regardless of whether it is a lower layer such as DCC / OSI, DDP / IP, or IPC.

The generation of the proxy task means that the task itself is generated in order to operate the proxy task. In reality, the proxy task is generated by driving a source program described later. In addition, registration of a proxy task refers to registration in a database used by a lower layer task for communication independent of the lower layer. As described above, when the proxy task is driven, communication is possible with the help of lower layer tasks.

3 (a), (b) is a view showing a message packet sent and received in the task according to the present invention.

FIG. 3 (a) shows a data request packet, where the op code is DTRQ. The SRC TID refers to a source TID, and the DST SID refers to a destination SID. In this case, the transport identifier (TID) indicates a port number in the case of IP, and a TSAP (16 bytes) in the case of OSI, and is distinguished from a target identifier (TID) which means a transmission target.

NID (network identifier) means IP address, and OSI means NSAP (20byte). SID (SMASE identifier) is a combination of TID and NID, which can specify NE with SID, and is distinguished from source ID (SID) indicating whether a request message is remote as described below.

3 (b) is a diagram illustrating a data indication packet (SRC TID, DST SID is as described above, where the op code is DTID). According to the API for data transmission, the task is transmitted by using the predefined command pCLI_SendDTRQ (), and the received task recognizes that data has arrived when the DTID message is received.

When the message is entered into the NE from the management device, the proxy task checks the target identifier (TID) from the message to indicate the destination of the message, and then the remote NE separate from the local, which is the message case for the NE itself. It is determined whether or not the message is about remote.

Depending on whether the NE that originally received the message was processed locally or remotely, the proxy task in the NE that received the message performs the routing of the message and responds to the message. The message will be stored in memory. When the response to the message is received from the OAM task, the message information is read from memory and responded to the management device with the TID.

The following is an example of source program code that generates a proxy task.

void CliAgt_ProxyManager (void)

{

    UIPC_ENDPOINT_HANDLE_T hMainQueue;

    UIPC_RETURN_E rUipc;

    CLITR (CLITR_FLG_PRX, CLITR_LVL_FUNC, ("enter CliAgt_ProxyManager () \ n"));

    / *

    ** For using the UIPC component, call following API of UIPC

    * /

    rUipc = Uipc_InitTaskContext (CLI_AGT_PROXY_MGR_WAIT_TIME);

    if (rUipc! = UIPC_SUCCESS)

    {

        printf ("[CLI_AGT_PROXY_MGR]: ERROR [% d] in Uipc_InitTaskContext! \ n", rUipc);

        return;

    }

    / *

    ** Creating the queue on which the task is going to listen the messages

    * /

    rUipc = Uipc_CreateQueue (CLI_AGT_PROXY_MGR_QNAME, CLI_AGT_PROXY_MGR_QSIZE,

                             CLI_AGT_PROXY_MGR_APP_ID, &hMainQueue);

    if (rUipc! = UIPC_SUCCESS)

    {

        printf ("[CLI_AGT_PROXY_MGR]: ERROR [% d] in Uipc_CreateQueue! \ n", rUipc);

        return;

    }

    rUipc = Uipc_SetMainQueue (&hMainQueue);

    if (rUipc! = UIPC_SUCCESS)

    {

        printf ("[CLI_AGT_PROXY_MGR]: ERROR [% d] in Uipc_SetMainQueue! \ n", rUipc);

        return;

    }

    / *

    ** Register my message handler for all messages that nobody else has registered for.

    * /

    rUipc = Uipc_RegisterMsgHandler (AGENT_MSG_CLASS_CLI, CliAgt_ProxyHdr);

    if (rUipc! = UIPC_SUCCESS)

    {

        printf ("[CLI_AGT_PROXY_MGR]: ERROR [% d] in Uipc_RegisterMsgHandler! \ n", rUipc);

        return;

    }

    / *

    ** Register PCLI Library Hander for using PCLI.

    * /

    pCLI_InitTaskContext ((UIPC_MSG_CALLBACK_T *) NULL);

#ifdef __INDIRECT_ROUTING_SUPPORTED__

    / *

    ** Register Idle Hander for handling Time Out.

    * /

    rUipc = Uipc_RegisterIdleHandler (CliAgt_ProxyIdleHandler);

    if (rUipc! = UIPC_SUCCESS)

    {

        printf ("Uipc_RegisterIdleHandler (PRX) failed \ n");

        return;

    }

#endif / * __INDIRECT_ROUTING_SUPPORTED__ * /

    / *

    ** Loop forever receiving messages on the main queue

    * /

    while (1)

    {

        rUipc = Uipc_RcvLoop ();

        if (rUipc! = UIPC_SUCCESS)

        {

            CLITR (CLITR_FLG_PRX, CLITR_LVL_FAIL, ("Uipc_RcvLoop (% d) failed \ n", rUipc));

        }

    }

}

FIG. 4 is a diagram illustrating a response process to a message request according to the present invention and illustrates an operation flow excluding a management task. As described above, in the MSSP device, since the IP stack is on the MPU and the OSI stack is on the DCU, Rx tasks (Receive Tasks) for receiving packets of the corresponding stacks exist on each board.

First, when a message request for management information is received from an external management device such as EMS (10), the destination address is reported, and if it is local, the message is transmitted to the OAM task (11), and if it is remote, the DCU for transmission to the destination NE. It will transfer 12 to the board's OSI Tx Transfer Task.

The OSI Tx task sends a message to the destination NE. The OSI Rx task of the remote NE receives the message, sends it to the OSI Rx task of the MPU of the NE, and finally sends the message to the OAM task.

The OAM task processes the message and sends a response to it, looking at the information of the source that requested the message, sending it to the OSI Rx task in the remote case, and sending it to the UDP Tx task in the local case (13). -1 send the final response to the agent (14).

In the remote case, the OSI Rx task receives and transmits to the OSI Tx task of the DCU for transmission to the corresponding OSI address (15), and the OSI Rx task of the remote NE receives the transmitted message (16, 17) and receives a final response. In this case, the MPU transmits the OSI Rx task (18) to the TL-1 agent (19).

5 is a flowchart illustrating a system initialization process according to generation of a proxy task according to the present invention.

First, a proxy task is created (S1), and a queue for receiving a message is created (S2). The generation of the proxy task is performed by driving the source program as described above.

Once the queue has been created, register a message handler for handling messages from the management device and the NE (S3), and timeout the messages that do not receive a response for indirect routing. The timeout handler is registered (S4).

A handler is a module that has a function to handle when a task receives a message. Registering a handler allows you to receive the message later, or to perform the task automatically every second, so that you do not have to worry about handling the message. The method of processing indirect routing and timeout will be described later.

After registering the handler, you can register the generated proxy task in the OSI / IP task (S5) to make the corresponding channel available for communication regardless of the underlying layer, that is, whether it is an OSI task or an IP task (S5), and then individual NEs. The proxy request database, which is a database relating to each TID address, is initialized (S6).

The following is an example of a proxy request database for message processing. At this time, the database has a structure of a double linked list so that the interconnect relation between messages can be confirmed.

typedef struct CLI_AGT_proxy_REQ_EL_T

{

    struct CLI_AGT_proxy_REQ_EL_T * pNext; / * next pointer in the linked list * /

    struct CLI_AGT_proxy_REQ_EL_T * pPrev; / * previous pointer in linked list * /

    CSA_UINT_T Proxy JobId; / * request job id * /

    PCLI_SID srcSid; / * source id that requested the request (OSI / IP) * /

    CSA_INT_T index; / * Requested index * /

    CSA_UINT_T timeout; / * request timeout value * /

    AGT_MSG_CLI_INPUT_REQ_T req; / * actual message requested * /

} CLI_AGT_proxy_REQ_EL_T;

typedef struct CLI_AGT_proxy_REQ_LIST_T

{

    CLI_AGT_proxy_REQ_EL_T * pFirst; / * first of request element * /

    CLI_AGT_proxy_REQ_EL_T * pLast; / * last of request element * /

    CSA_INT_T listCnt; / * Number of current requests * /

} CLI_AGT_proxy_REQ_LIST_T;

6 is a diagram illustrating the structure of a proxy request database according to the present invention.

In the proxy request database, items represented in data fields are stored for each message, and the items can be read and used if necessary. The proxy request database creates one message in memory each time it receives a message from the management device and links it to a linked list. Next and pPrev represent the forward and backward connections of the stored messages.

The jobid in the data field is used to identify whose response to the request when the response comes. That is, when a large number of request messages occur and accumulate, a response ID for each request is assigned to each request message for a correct response later. It could be realized.

The source ID (srcSid) is an ID assigned to the request message to distinguish whether the requested message is from an external management device or a remote proxy. The timeout is a field to store for error handling when the proxy task does not receive a response to the request message within a set time.

A request is a message that an individual NE actually requested. As described above, the proxy request stored in the database can be retrieved from memory and used if necessary.

7 is a flowchart illustrating remote NE access according to indirect routing determination according to the present invention.

First, a TL-1 message is input from a management device (S11) and a TID is extracted from the message (S12). Meanwhile, the optical transmission equipment uses TL-1 as a management protocol, and the basic format of the TL-1 message is as follows.

VERB-MOD1-MOD2: [<TID>]: [<AID>]: [<CTAGS>] :: [<parameter block>];

Where <TID> is used for indirect routing to access the remote NE. An IP address may be used as the TID in the system, or the lower 8 bytes of the NSAP address for OSI may be used.

The TID rule of the 10G transmitter is SYS. <Ipaddress> for an IP address and SYS. <Sysid>-<stationid> for an NSAP address. At this time, <sysid> and <stationid> can be extracted from the lower 8 bytes of NSAP address. According to the TID rule, the TID of the corresponding NE is stored in a memory composed of NVRAM (S13).

For example, the NSAP address has the format 0x39410f8000000000000000XXXXXXXX0000000001. The XX part is used as <sysid> and <stationid> to make a TID to route between devices.

After extracting the TID, the received message is stored in the database on the proxy request memory. This database will be used later in response or during timeout processing. In addition, it is checked whether the received TID is equal to the TID of the local NE (S14).

During the test, the IP address or NSAP address stored in the real system memory, NVRAM, is read and compared with the input TID. If the comparison is the same, it transmits to the agent task of the local NE (S15). If not, the NSAP or IP address is extracted from the input TID (S16), and the message is retransmitted to the proxy task of the NE of the corresponding address (S17).

To extract the address, apply the above rule in reverse. At this time, regardless of the lower layer, if the data is simply transmitted using the channel registered at the time of initialization, it is transmitted to the corresponding NE. So you don't have to worry about what the lower layers are.

The proxy task of the retransmitted remote NE sends the message to its agent task and waits for a message or response. Therefore, the agent task of the destination NE receives the final message according to the management equipment's intention, so that the message can be managed.

8 is a flowchart illustrating a timeout when no response is received after a message request according to the present invention.

The proxy task is performed periodically at regular intervals to read the proxy request database from memory to determine whether the request has timed out. To this end, the individual request message requested by the external management equipment for the NE requires a response with each timeout value set in advance (S21).

In order to check whether or not the timeout is determined, the response messages of the request messages included in the proxy request database are sequentially checked, and then it is determined whether the corresponding message is the last of the proxy request database (S22). If the message is the last message in the proxy request database, the operation is terminated without checking for further timeout.

As a result of checking whether the request message has timed out (S23), if the timeout value is exceeded in advance, an error message is created and an error message is transmitted to the SID of the request message stored in the proxy request database (S24).

SID is one of the field items of the individual messages stored in the proxy request database. It means the source ID that requested the message. The SID receives the message from the external management device or the external management device that requested the message and delivers the message directly to the individual NE. Say an address.

Therefore, if the SID is not the address of the remote NE, it means that the address of the NE is local and the NE is directly connected to the external management equipment. Therefore, the generated error message directly transmits an error message to an external management device, that is, an operator, without having to pass a separate NE (GNE) (S26). In this case, an error message is generated by the proxy task, and if the response comes later, the response is discarded.

If the SID is the address of the remote NE (S25), an error message is transmitted to the proxy task of the GNE, which is a network device directly connected to the remote NE, that is, the external management device (S27). Upon receiving the error message, the proxy task of the remote NE again transmits the error message to the external management device that is the subject of the message request.

At this time, the message transmission between NEs uses a registered channel of a lower layer. That is, since the proxy task is registered in IP, OSI, and IPC channels, the proxy task determines the address type of the requested SID and transmits data to the corresponding subchannel.

9 is a flowchart illustrating a case in which there is a response according to a message request according to the present invention.

When the NE receives a message from the external management device, when the proxy task receives a response to the request message from the agent task in the NE, the NE can check the request message from the proxy request database.

 In this case, a key value for confirming the request message may use a job ID used at the time of requesting the message (S21).

After checking the request message, it is determined whether or not the stored source ID SID is a remote TID (S22). If the remote TID is a remote TID, it is transmitted to the proxy task of the remote NE of the corresponding address, that is, the network device directly connected to the external management device. (S23).

The proxy task of the remote NE, which has received the response message from the NE, sends the response message back to the external management device which is the party that originally requested the message. If the stored source ID is local, it does not need to pass through a separate NE, and thus directly transmits a response to the request message to the external management device (S24).

The technical spirit of the present invention has been described above with reference to the accompanying drawings, but this is by way of example only and not intended to limit the present invention. In addition, it is obvious that any person skilled in the art can make various modifications and imitations without departing from the scope of the technical idea of the present invention.

As described above, the present invention is effective in managing a plurality of remote NEs when the equipment using the TL-1 as a management protocol is in an MSSPR network environment, and furthermore, enables management regardless of the communication layer between the NEs. The management interface can also be applied to network systems with minimal changes.

Claims (11)

In the network device management method of NE using one or more tasks for lower layer communication in a network system including one or more NE (Network Element), Identifying a transmission target ID included in the request message received from an external management device and transmitting the request message to the transmission target through a task for lower layer communication between the transmission targets; Wow And when the response message for the request message is received, transmitting the response message to the external management device through a task for lower layer communication between the external management devices. delete delete The method of claim 1, The step of transmitting the request message to the transmission target, Checking whether a transmission target ID included in the request message matches its ID; Wow a) sending the request message to its management task if the transmission target ID matches its ID; b) transmitting the request message to a NE having a corresponding transmission target ID through a task for lower-layer communication between the corresponding NEs when the transmission target ID does not match its own ID. The method of claim 1, The step of transmitting the response message to the external management device, An error message is generated when a response message to the request message is not received for a set timeout value and is transmitted to an external management device through a task for lower layer communication between the external management devices. . delete delete delete delete delete delete

Images