CN108650126B - Method for automatically discovering and configuring in-band DCN in PTN network - Google Patents
Method for automatically discovering and configuring in-band DCN in PTN network Download PDFInfo
- Publication number
- CN108650126B CN108650126B CN201810438017.3A CN201810438017A CN108650126B CN 108650126 B CN108650126 B CN 108650126B CN 201810438017 A CN201810438017 A CN 201810438017A CN 108650126 B CN108650126 B CN 108650126B
- Authority
- CN
- China
- Prior art keywords
- ibm
- network element
- managed
- network
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0876—Aspects of the degree of configuration automation
- H04L41/0886—Fully automatic configuration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/026—Details of "hello" or keep-alive messages
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a method for automatically discovering and configuring an in-band DCN in a PTN network, which comprises the processes of discovering a network element to be managed based on an IBM extension message, establishing an IBM channel between the network element to be managed and a network element to be managed, and managing a new access network element by a network management system. The invention can automatically discover a new network element and the connection which can reach the network element in the PTN network, and remotely establish an in-band management channel to the new network element, thereby accommodating the new network element into the management range of a network management system; in the whole process, only GNE is needed to be connected, personnel do not need to go to the site of each device, and the construction of the DCN can be automatically completed. The invention can improve the working efficiency, shorten the construction period, save the labor cost and have better practicability.
Description
Technical Field
The invention belongs to the technical field of data communication, and particularly relates to a method for automatically discovering and configuring an in-band DCN in a PTN network.
Background
In PTN network deployment, a Network Management System (NMS) typically manages each device (network element, NE) not directly through a management port of the device, but only a Gateway Network Element (GNE) is accessed through the management port thereof, and the rest of the network elements form an in-band Data Communication Network (DCN) by logically isolating an in-band management channel (IBM) in a service communication link, and are connected to the NMS via the gateway network element, thereby incorporating network management. The in-band management path of the PTN is a logical path, and network management data is separated from traffic data based on a specific MPLS label (label). If there is a physical connection between two adjacent network elements (e.g., an optical fiber, where two ends of the optical fiber are respectively a network port (NNI) of two network elements), an IBM channel can be established, and usually, a network management system or a maintenance terminal configures corresponding NNI ports of each network element according to a network plan.
However, in the initial stage of network construction, before the DCN based on the IBM channel is established, the network management system located in the network management center cannot remotely manage the devices. The establishment of IBM channels typically requires an operator to configure the network elements on a device site by network element basis. And once the configuration is wrong, the network element cannot be managed from the network management center, and people need to be sent to the site for reconfiguration. High cost and long time consumption. Improvements are needed.
Disclosure of Invention
The invention aims to provide a method for automatically discovering and configuring an in-band DCN in a PTN network, which can automatically discover a new network element and a connection which can reach the network element in the PTN network, and remotely establish an in-band management channel to the new network element, thereby accommodating the new network element into the management range of a network management system; because the construction of the DCN can be automatically completed, the invention can improve the working efficiency, shorten the construction period, save the labor cost, avoid the mismatching possibly generated by the personnel operation and have better practicability.
The invention is mainly realized by the following technical scheme: a method for automatically discovering and configuring in-band DCN in PTN network, dividing the network element into managed network element and network element to be managed according to the management state of the network element, the managed network element is managed by the network management system; the method comprises the steps of discovering a network element to be managed based on IBM extended information, establishing an IBM channel between the network element to be managed and a managed network element, and managing a new access network element by a network management system; the IBM extension message is extended based on an 802.1ab LLDP protocol message and comprises three message types including IBM _ HELLO, IBM _ SETUP _ REQ and IBM _ SETUP _ ACK.
In order to implement the present invention, further, in the process of discovering the network element to be managed based on the IBM extension message, the managed network element and the network element to be managed interact through an IBM _ HELLO message; the pipe waiting network element in the initial state must respond to the IBM _ HELLO message; if NE STATUS is NE _ STATUS _ INIT and Port STATUS is PORT _ STATUS _ IBM _ NO in IBM _ HELLO TLV content in IBM _ HELLO message received by the managed network element, the managed network element can confirm that the opposite end is a to-be-managed network element in the initial state, and report information to the network management system; the reported information comprises candidate IBM ports of the managed network element, the network element to be managed and corresponding ports thereof.
In order to realize the invention, further, in the process of establishing the IBM channel between the network element to be managed and the managed network element, the network management system sends an IBM channel configuration command to the managed network element, wherein the command comprises an MPLS label of the IBM channel appointed by the network management system and an IP address of the network element to be managed; the managed network element sends an IBM _ SETUP _ REQ message to the network element to be managed on an IBM port to be established and requires the network element to be managed to carry out IBM configuration; the network element to be managed configures IBM on a receiving port, configures an IP address and a default route passing through the IBM channel, and sends an IBM _ SETUP _ ACK confirmation message to the managed network element; after the configuration of the management network element IBM is completed, the updated IBM _ HELLO message is sent to the managed network element; the managed network element reports completion of IBM channel configuration to the network management system, so that the network management system can be connected with the network element to be managed to manage the network element. The content of the IBM _ SETUP _ REQ message includes Label, which is an MPLS Label specified by the network management system, IP Address, which is an IP Address allocated by the network management system for the peer network element to be managed, and GW Address, which is an IP Address of the managed network element in the in-band DCN; the IBM _ SETUP _ ACK acknowledgement message includes an IBM _ SETUP _ ACK TLV content, where Return Code is IBM _ SET _ OK and SN is SN in the received IBM _ SETUP _ REQ; and after the configuration of the network element to be managed IBM is completed, sending IBM _ HELLO TLV of the IBM _ HELLO message again, wherein the Port STATUS of the IBM _ HELLO TLV is PORT _ STATUS _ IBM _ SET.
The invention divides the network element into a managed network element and a network element to be managed according to the management state of the network element. The managed network element refers to a network element which is already managed by a network management system, and the managed network element and the network management system may be in direct communication through a management port of the network element or in communication through an in-band management channel (IBM); and the network element to be managed does not have a management channel to the network management system. They assume different roles in the IBM channel establishment process. In the process of establishing an IBM channel between a managed network element and a network element to be managed adjacent to the managed network element (adjacent means that there is a physical connection between the managed network element and the network element to be managed), the managed network element assumes a proxy role (proxy), and the network element to be managed is a target to be managed (target).
The status and role of the network elements may change with the construction process of the in-band DCN. Under the initial condition, only GNE is a managed network element (directly passing through a management port of the GNE network element); with the establishment of the IBM channel, more network elements are managed by the network management system through the IBM channel.
The construction of the DCN according to the invention involves: the method comprises the steps of discovering a network element to be managed based on IBM extended information, establishing an IBM channel between the network element to be managed and a managed network element, and managing a new access network element by a network management system. The above process is completed by the cooperation of the network management system, the managed network element and the adjacent network element to be managed. And the adjacent network elements exchange messages designed by the method.
The method is focused on the initial construction of the DCN, and the network elements which are mutually communicated in the whole network are brought into the management of the network management system of the DCN in the process. The subsequent redundancy configuration, DCN optimization and other further work can be normally configured through the network manager, which is not in the design range of the method, and thus, the detailed description is omitted.
The procedures and messages involved in the method are described below, respectively.
1. IBM extension messages:
the message of the invention is expanded based on 802.1ab LLDP protocol message, and is encapsulated by adopting Ethernet II format. The NNI communication port of the PTN network element is an ethernet port and these IBM extension messages can be passed over a physical connection on the NNI side of the adjacent network element.
The present invention designs several IBM messages:
-IBM _ HELLO: an announcement message announcing the status of the network element and the NNI port;
-IBM _ SETUP _ REQ: IBM sets up the solicited message;
-IBM _ SETUP _ ACK: IBM sets up the confirmation message.
The general format of the extended message is shown in fig. 1, where:
-DA: the destination address is here fixed as the ethernet multicast address 01-80-C2-00-00-0E.
-SA: and the source address is the MAC address of the NNI port for sending the message.
-EtherType: frame type, 0x88 CC.
-LLDP PDU: the message content consists of a series of TLVs including the partial content and end flag specified by LLDP, and IBM extensions designed here. IBM extension TLVs are described in detail below. And the TLVs specified by the LLDP protocol here include:
■ chatsis ID TLV, where the network element MAC address is passed as the chatsis ID;
■ Port ID TLV, where this send Port MAC address is conveyed as a Port ID;
■ TTL TLV, which indicates the effective time of the message and the unit is second;
■ END TLV, marking LLDP PDU END.
-FCS: the frame check sequence.
The IBM extended TLV format here is shown in fig. 2, where:
-Type: TLV type, IBM extended TLV type 127.
-Length: the length of the TLV information.
-OUI: organization ID, globally unique, OUI by Walssem corporation in the product of Walssem.
-Sub-type: since OUI distinguishes the subtype, the subtype is actually a local enumeration type and is autonomously defined by an organization, and the subtype is only required to be unique in the organization. The method designs the following IBM extended TLV subtypes:
■IBM_HELLO
■IBM_SETUP
-Value; the message content, Length must match the Length value of this TLV (i.e., the Length field).
IBM _ HELLO extended TLV, whose information Length (Length field) is 6 bytes, TLV subtype (Sub-type) is IBM _ HELLO, and message content (Value field) is as shown in fig. 3, where:
-Version: version, for later extension, the current version is 0x 01.
-NE status: the management state of the network element is an enumeration type, and the current version has the following states:
■ NE _ STATUS _ INIT: initial state, 0x 00;
■ NE _ STATUS _ MANAGED: the network element is managed;
■ NE _ STATUS _ LOM: network element offline (Loss of management).
-Port status: the port status, which indicates the status of the port sending this IBM _ HELLO message participating in the in-band DCN, is an enumeration type, and the current version has the following statuses:
■ PORT _ STATUS _ IBM _ NA: irrelevant state, this port does not participate in-band DCN;
■ PORT _ STATUS _ IBM _ NO: there is no IBM configuration on this port;
■ PORT _ STATUS _ IBM _ PENDING: the port is doing IBM configuration, which is a transitional state;
■ PORT _ STATUS _ IBM _ SET: this port has been configured with IBM.
-Label: the MPLS label, the IBM channel MPLS label configured for the port, occupies 20 bits per se, and the remaining 4 bits are reserved.
The IBM _ HELLO message includes the IBM _ HELLO TLV, as well as several of the mandatory standard LLDP TLVs mentioned above, and may also include some other TLVs (not to be so limited, but may be sent periodically in the same message as the IBM _ HELLO announcement, as will be described later, for consistency check by periodically sending LLDP messages in the maintenance phase). Where the END TLV must be placed at the END of all TLVs, i.e. after including the chatsis ID TLV, the Port ID TLV, the TTL TLV, the IBM _ HELLO TLV, and possibly others.
IBM _ SETUP _ REQ extension TLV whose TLV subtype (Sub-type) is IBM _ SETUP, and whose Value field includes contents as shown in fig. 4, where:
-Version: version, for later extension, the current version is 0x 01.
-Request Flag: flag bit, IBM _ SETUP _ REQ message with 1 in it.
-SN: sequence number for matching with IBM _ SETUP _ ACK.
-Label: MPLS Label, syntax is the Label field in IBM _ HELLO.
IP Address: an IP address.
-GW Address: and the gateway address is the gateway address corresponding to the IBM interface to be established, and the gateway address is used if the IP message is forwarded through the interface after the IBM channel is established.
The IBM _ SETUP _ REQ message includes the IBM _ SETUP _ REQ TLV, as well as several of the mandatory standard LLDP TLVs mentioned earlier. Where the END TLV must be placed after all other TLVs, including the chatsis ID TLV, the Port ID TLV, the TTL TLV, and the IBM _ SETUP _ REQ TLV.
IBM _ SETUP _ ACK extended TLV whose TLV subtype (Sub-type) is IBM _ SETUP, whose Value field includes contents as shown in fig. 5, where:
-Version: version, for later extension, the current version is 0x 01.
-Request Flag: the flag bit, IBM _ SETUP _ ACK message is 0.
-SN: sequence number, matching the sequence number in the IBM _ SETUP _ REQ message.
Return Code: a return code indicating the result of processing of the IBM setting request. The current version specification supports the following code:
■ IBM _ SET _ OK: 0x00, indicating no problem;
■ IBM _ SET _ ERR _ LABEL: 0x11, parameter error, MPLS label collision;
■ IBM _ SET _ ERR _ INVALID: 0x20, invalid request (this port current state does not support IBM set request);
■ IBM _ SET _ ERR _ GEN: 0x10, other errors.
The IBM _ SETUP _ ACK message includes the IBM _ SETUP _ ACKTLV, as well as several of the aforementioned mandatory standard LLDP TLVs. Where the END TLV must be placed after all other TLVs, including the chatsis ID TLV, the Port ID TLV, the TTLTLV, and the IBM _ SETUP _ ACKTLV.
2. The discovery process of the network element to be managed comprises the following steps:
through the interaction of IBM _ HELLO messages between adjacent network elements, the managed network element finds the network element to be managed and the physical connection which may establish an IBM channel, and reports the physical connection to the network management system.
The discovery process can be initiated actively by the network management system (discovery on demand), and also can be periodically and mutually sent IBM _ HELLO messages between network elements (periodic discovery); it can be configured whether a network element is periodically sending IBM _ HELLO messages on its NNI port. In the case where no settings are made on the device, as a network element to be managed, its default configuration may be that periodic IBM _ HELLO message transmission is not enabled, but IBM _ HELLO messages must be received. Unlike LLDP, the network element to be managed must process upon receiving the IBM _ HELLO message, and send its own IBM _ HELLO message in response on the port on which the IBM _ HELLO message was received.
The content of IBM _ HELLO TLV in IBM _ HELLO message sent by the managed network element is as follows:
NE STATUS (network element management state) NE _ STATUS _ MANAGED;
port STATUS ═ Port _ STATUS _ IBM _ NO (NO IBM configuration).
The content of the IBM _ HELLO TLV in the IBM _ HELLO message sent by the pipe network element to be managed in the initial state is as follows:
NE STATUS INIT (initial state);
port STATUS ═ Port _ STATUS _ IBM _ NO (NO IBM configuration).
After receiving the message, the managed network element can identify the network element connected to the receiving port as a network element to be managed. The managed network element reports the discovery to the network management system, and the reported information includes the discovered network element to be managed, the corresponding Port (obtained by the chatss ID TLV and the Port ID TLV in the received message), and the candidate IBM Port corresponding to the managed network element (namely the NNI Port receiving the IBM _ HELLO message).
If the discovery process is an on-demand discovery initiated by the network management system actively, the managed network element needs to start a timer, and if no message of NE STATUS (NE _ STATUS _ INIT) or NE STATUS (NE _ STATUS _ LOM) in IBM _ HELLO TLV is received before a specified time, the message should be reported to the network management system.
Note that the above is a method for determining the pipe waiting network element in the initial state. Yet another case is a managed network element, which can also be found in the IBM _ HELLO message interaction. The difference is that the NE STATUS of the offline network element announced in the IBM _ HELLO TLV is NE _ STATUS _ LOM, which is different from the initial state (i.e. the case of NE STATUS of NE _ STATUS _ INIT). This case of an out-of-service network element belongs to the maintenance phase mentioned later, which network element has been managed before, but is out-of-service due to a network failure. The network element determines whether the network element is out of control by a mature method, which is not in the new design scope of the invention. Many systems have their own implementation, for example, simply by heartbeat detection between a network management system and a network element. In short, the judgment of the state of the network element offline is a mature method and is not considered in the invention.
To support auto discovery, after the network element device is powered on, all network side ports should be opened by default to be able to receive and transmit ethernet messages and process the above defined IBM extension messages. To save device power consumption, this can be optimized as: after the equipment is powered on, all network side ports are opened with the direction detection function, and the sending direction is only periodically opened to send signals; if a line signal is detected in the receive direction, the port is then held fully open.
This is only for network side ports (NNIs), while user ports (UNI) are all off by default after power up, since in normal applications, PTN devices are also networked via interconnections between NNIs. The UNI is used to access client signals and it makes no sense to turn on the UNI before the device is not configured to provide service to the client. Some devices have partial ports which can be flexibly configured, namely one port can be configured as the NNI and can be configured as the UNI, and the ports of the type are factory default to be the NNI. Since the in-band managed communication channels of the PTN exist only between NNIs, as noted, not specifically, the ports described in this description refer to network-side ports (NNIs).
3. The establishing process of the IBM channel comprises the following steps:
after the network element to be managed is found, the network management system can send an instruction to the network element to be managed which reports the finding, and requests to carry out IBM channel configuration; besides the target network element and the port, the network management system also designates the MPLS label of the IBM channel and the IP address of the network element to be managed.
After receiving the instruction of the network management system, the managed network element sends an IBM _ SETUP _ REQ message to the adjacent target managed network element on the appointed candidate IBM port, and requires the opposite end to configure IBM. This IBM _ SETUP _ REQ message contains the following:
-Label (MPLS Label) specified by the network management system;
IP Address (IP Address) is an IP Address allocated by the network management system to the network element at the opposite end (to be managed);
GW Address (gateway Address) is the IP Address of the local (managed) network element in the in-band DCN.
After the target network element to be managed of the opposite end receives the IBM _ SETUP _ REQ request message, if no problem exists, the network element to be managed configures IBM, an IP address and a default gateway address passing through the IBM channel on a receiving port according to the parameters specified in the message, and sends an IBM _ SETUP _ ACK confirmation message to the network element to be managed which sends the IBM _ SETUP _ REQ request message; after configuration is complete, an IBM _ HELLO message is sent to the peer (managed network element) on that port.
Here, the IBM _ SETUP _ ACK acknowledgment message has its IBM _ SETUP _ ACKTLV:
-Return Code ═ IBM _ SET _ OK (no problem);
-SN (sequence number) SN in the received IBM _ SETUP _ REQ.
After an initial network element has been configured this time, the content in the IBM _ HELLO message sent here should be changed as follows:
-Port STATUS ═ Port _ STATUS _ IBM _ SET;
label, Label in the received IBM _ SETUP _ REQ.
After receiving the IBM _ SETUP _ ACK message, the managed network element configures an IBM channel on a corresponding port of the managed network element; this IBM configuration should use the same MPLS label that was sent to the opposite end in the aforementioned IBM _ SETUP _ REQ request message. In addition, the managed network element configures a route to the correspondent IP address.
After completing the above configuration and receiving IBM _ HELLO message from the peer target Port STATUS, Port _ STATUS _ IBM _ SET, the managed network element reports completion of IBM channel configuration to the network management system.
Note that if the network element is unable to complete the configuration required by the received IBM _ SETUP _ REQ request message, the requesting party is responded with a message containing a corresponding error code in IBM _ SETUP _ ack tlv. Error codes as described in the previous message section, the explicit errors are as follows:
-if the network element does not support IBM configuration for this port, or the network element status is managed, Return Code, IBM _ SET _ ERR _ INVALID;
-if the network element port is already IBM configured, returning a Return Code, IBM _ SET _ ERR _ INVALID;
-if the MPLS LABEL has a collision, Return Code is IBM _ SET _ ERR _ LABEL returned.
After receiving the IBM _ SETUP _ ack lv, the network element sending out the IBM _ SETUP _ REQ request message should report an error to the network management system. The errors described above are only the sophistication of message design so that the network element has some error handling mechanism. Such errors do not normally occur. If the network element does not support IBM configuration for this port, or if the network element status is managed, then there is an explicit status indication in the previous IBM _ HELLO announcement message, which is clear during the discovery phase. And the network management system should have all the network element information managed and should not send the instructions with conflict. The network management system and the neighboring managed elements should not make such IBM _ SETUP _ REQ requirements.
In the initial construction stage, the network management system can be set to an automatic mode. After receiving the report that the managed network element finds the new network element to be managed, the network management system automatically sends a management instruction to the reported managed network element, and starts the above-mentioned IBM channel establishment process, which only needs to determine the instruction parameters according to certain rules. MPLS for IBM should have a range preset and the IP addresses of network elements should also be planned to have a certain range. The simple rule is: the MPLS label is sequentially determined in an increasing mode in the range of the managed network element which receives the instruction, namely starting from the minimum value of the range of the IBM MPLS label, and skipping sequential increasing determination of the value of the label if the label is used on the managed network element so as to ensure uniqueness on the network element; the IP addresses allocated to the network elements to be managed can be sequentially increased in the IP address field according to the discovery sequence.
In this automatic mode, after newly managing a previous network element, the network management system automatically instructs the network element to send IBM _ HELLO advertisement messages on all connected network ports for discovery.
In addition, generally speaking, a network element to be managed may be discovered by a plurality of managed network elements, and the network management system should only instruct one managed network element to establish an IBM channel between the network element to be managed and the managed network element, so as to bring the network element to be managed into the management scope. The simple and feasible rule is the sequence, if a certain managed network element is received first and reported to find a network element to be managed, the managed network element is instructed to establish an IBM channel between the managed network element and the network element to be managed.
Thus, in the automatic mode, the initial construction process of the whole DCN can be automatically completed under the instruction coordination of the network management system, and all the network elements which are connected with each other are accessed into the network management range.
The above-mentioned mode is applicable to the initial construction process, and is started on the network management system by the operator. Once it is confirmed that the initial build of the DCN is complete, the operator may end the initial build process, ending the automatic mode. Subsequent optimization or maintenance work is performed manually. Of course, it is also possible to choose not to start the automatic mode, and the operator will gradually find and configure through the network management system, because of the remote operation, there is still a great cost and efficiency advantage compared with the traditional configuration on the field of the device.
4. The maintenance phase has the following functions:
although the method is focused on solving the initial building problem of DCN. However, the IBM extension message and partial procedure approach designed here can also help in the maintenance phase after DCN construction.
First, during a maintenance phase, a network element periodically sends IBM _ HELLO messages on its NNI, which can cause the other to detect an inconsistent place. This often represents a mismatch or misconnection. By reporting the network management system, the network management system can be helped to find the mismatching or misconnection condition, thereby taking measures. This is the normal usage of LLDP, however the LLDP protocol does not specify IBM, in this method IBM extensions are designed.
Secondly, in the maintenance phase, if a part of IBM channels are disconnected due to network faults, such as disconnection of individual lines, and individual network elements are offline, the network management center can send IBM _ SETUP _ REQ messages to the offline network elements from other adjacent unmanaged network elements according to the network topology, and carry out IBM setting, so as to establish new IBM channels and obtain new paths to manage the network elements. In the process, an operator can request the adjacent unmanaged network element to establish an IBM channel through the network management center without directly going to the site for processing. After the network element is managed, operation and maintenance personnel can remotely operate the equipment from a network management center to perform necessary diagnosis, so that the assistance can better position and eliminate network faults. Therefore, the operation and maintenance cost can be better reduced.
The invention has the beneficial effects that:
(1) the invention includes the processes of discovering the network element to be managed based on the IBM extended message, establishing an IBM channel between the network element to be managed and the managed network element, and managing the newly accessed network element by the network management system; the IBM extension message is extended based on an 802.1ab LLDP protocol message and comprises three message types including IBM _ HELLO, IBM _ SETUP _ REQ and IBM _ SETUP _ ACK. The invention can automatically discover a new network element and the connection which can reach the network element in the PTN network, and remotely establish an in-band management channel to the new network element, thereby accommodating the new network element into the management range of a network management system; in the whole process, only GNE is needed to be connected, and personnel do not need to go to the site of each device, so that the construction of DCN can be automatically completed; compared with the traditional method, the method improves the efficiency, shortens the construction period, reduces the cost and has better practicability.
(2) In the process of discovering the network element to be managed based on the IBM extended message, the managed network element and the network element to be managed interact through an IBM _ HELLO message; the pipe waiting network element in the initial state must respond to the IBM _ HELLO message; if NE STATUS is NE _ STATUS _ INIT and Port STATUS is PORT _ STATUS _ IBM _ NO in IBM _ HELLO TLV content in IBM _ HELLO message received by the managed network element, the managed network element can confirm that the opposite end is a to-be-managed network element in the initial state, and report information to the network management system; the reported information comprises candidate IBM ports of the managed network element, the network element to be managed and corresponding ports thereof. Because the automatic discovery is adopted, the mismatching possibly generated by the operation of personnel is avoided; compared with the traditional method, the method improves the efficiency, reduces the cost and has better practicability.
(3) In the process of establishing an IBM channel between a network element to be managed and a network element to be managed, a network management system sends an IBM channel configuration command to the network element to be managed, wherein the command comprises an MPLS label of the IBM channel appointed by the network management system and an IP address of the network element to be managed; the managed network element sends an IBM _ SETUP _ REQ message to the network element to be managed on an IBM port to be established and requires the network element to be managed to carry out IBM configuration; the network element to be managed configures IBM on a receiving port, configures an IP address and a default route passing through the IBM channel, and simultaneously sends an IBM _ SETUP _ ACK confirmation message to the managed network element; after the configuration of the management network element IBM is completed, the updated IBM _ HELLO message is sent to the managed network element; the managed network element reports completion of IBM channel configuration to the network management system, so that the network management system can be connected with the network element to be managed to manage the network element. By the method, an in-band management channel to the new network element is remotely established without personnel going to the site of each device, and the new network element is accommodated in the management range of the network management system; compared with the traditional method, the method improves the efficiency, reduces the cost and has better practicability.
(4) The IBM extended message and partial process approach of the present invention can also help in the maintenance phase: firstly, the inconsistency caused by mismatching and misconnection can be found; secondly, under the specific condition that the network failure causes the individual network element to be offline, the DCN can be repaired from other non-offline network elements remotely to re-manage the offline network elements, thereby helping to reduce the operation and maintenance cost.
Drawings
FIG. 1 is a diagram of a general format of a message;
FIG. 2 is a schematic diagram of an IBM extended TLV;
FIG. 3 is a schematic diagram of IBM _ HELLO extended content;
FIG. 4 is a schematic diagram of IBM _ SETUP _ REQ extended content;
FIG. 5 is a schematic diagram of IBM _ SETUP _ ACK extension;
FIG. 6 is a diagram relating to entities;
FIG. 7 is a diagram illustrating interaction between entities.
Detailed Description
Example 1:
in this embodiment, a new network element and a connection that can reach the new network element are discovered, and an in-band management channel to the new network element is remotely established, so that the new network element is accommodated in a management range of a network management system. The IBM extension message is extended based on an 802.1ab LLDP protocol message and comprises three message types including IBM _ HELLO, IBM _ SETUP _ REQ and IBM _ SETUP _ ACK.
As shown in fig. 6, the NE2 has been managed by a Network Management System (NMS), and IBM channels have been established between it (through its p1 port) and NE1, and between NE1 and GNE. And NE3 is in an initial state and is not managed. There is an optical fiber connection between the p2 port of NE2 and the p1 port of NE 3. The p1, p2 ports of NE2 and the p1, p2 ports of NE3 can both be NNI ports.
Fig. 7 shows the process by which the managed NE2 discovers the standby NE3 and establishes an IBM tunnel between them, thereby bringing NE3 into the scope of network management.
The discovery process in the example is initiated actively by the network management system. The Network Management System (NMS) issues an instruction to the NE2 to start the discovery process.
Upon receiving this instruction, NE2 sends an IBM _ HELLO advertisement message on its p2 port.
NE3 receives the IBM _ HELLO message from NE2 from its p1 port and in response, sends its IBM _ HELLO advertisement message on this p1 port. Since the NE3 is in the initial state after power-on at this time, in the IBM _ HELLO notification message sent by it, NE STATUS is NE _ STATUS _ INIT and Port STATUS is Port _ STATUS _ IBM _ NO, which indicates that the network element is in the initial state and the Port is not configured with IBM.
NE2 receives IBM _ HELLO advertisement message from NE3 from its p2 port, and finds NE3 to be the network element. NE2 reports this discovered information to the Network Management System (NMS).
The Network Management System (NMS) issues a command to NE2 requesting it to establish an IBM tunnel with NE3, where the Network Management System (NMS) specifies the MPLS label of the IBM tunnel and the IP address assigned to NE 3.
NE2 sends an IBM _ SETUP _ REQ message from its p2 port to NE 3. The MPLS label and the IP Address specified by the network management system instruction are filled in (the IP Address field is filled in), and the IP Address of NE2 itself is filled in as the GW Address field.
NE3 receives the IBM _ SETUP _ REQ request message sent by NE3 from its p1 port. At this point NE3 is in the initial state and the MPLS label is also collision free, it can make IBM settings as required. While doing IBM configuration, NE3 first sends an IBM _ SETUP _ ACK acknowledgement message to NE2 on its p1 port with the Return Code field IBM _ SET _ OK.
NE3 makes an IBM configuration for its p1 port, which uses the MPLS label received this time. NE3 configures its in-band IP Address according to the parameters received this time, and configures a default route, which is specified by gateway Address for GW Address received this time, i.e. the in-band IP Address of NE2, and the interface of the route is the IBM tunnel interface just configured here. After configuration, NE3 sends an IBM _ HELLO advertisement message from its p1 Port, at which time its element management STATUS NE STATUS is unchanged, but the Port STATUS of the p1 Port becomes Port _ STATUS _ IBM _ SET.
NE2 receives IBM _ SETUP _ ACK from NE3 from its p2 port, and also configures its p2 port according to the MPLS label required by this IBM configuration.
NE2 completes configuration and reports IBM channel configuration completion to the network management system after its p2 Port receives the IBM _ HELLO announcement message sent by NE3 (from which it can be found that its Port STATUS becomes Port _ STATUS _ IBM _ SET). A static route is configured to NE3IP address (i.e. via the IBM tunnel this time established, up to the in-band IP address assigned to NE 3).
If no routing protocol exists, the network management system needs to configure the static routes on the GNE and the NE1, add a route to the in-band IP address of the NE3, the gateway address of the route on the GNE is the in-band IP address of the NE1, the gateway address of the route on the NE1 is the in-band IP address of the NE2, and the forwarding interface is the same as the forwarding interface to the NE 2.
More generally, in the automatic mode, when a certain managed network element (proxy) establishes an IBM channel with its discovered neighboring network element (target) to be managed under the instruction of the network management system, the network management system can automatically configure a static route to the target network element to be managed of the target on all the intermediate network elements reaching the proxy managed network element, the destination IP address of the route entry is the IP address assigned to the network element to be managed by the network management system, the gateway address of the route entry on the neighboring network element on the proxy managed network element is the in-band IP address of the proxy managed network element, the gateway address of the route entry on other network elements is consistent with the route entry to the proxy managed network element IP, and the forwarding interface is also consistent with the route entry to the proxy managed network element IP.
At this time, a path has been established between NE3 and the network management system via an IBM path with NE 2. The network management system may manage NE 3. After managing NE3, NE3 may be further configured, for example, by network management instructions, to configure a dynamic routing protocol.
The above procedure expands the in-band DCN, which has brought NE3 into its scope, NE3 also changes from a standby network element to a managed network element. Next, via the same procedure, an IBM tunnel between NE3 and NE4 can be established, and the DCN further expands the incorporation of NE4 into its scope, so that the network management system incorporates NE4 into management.
The process starts from GNE, IBM channels are gradually built between managed network elements and network elements to be managed, DCN is expanded until DCN covering the whole network is built, and the whole network is brought into a management range.
Example 2:
further, in the example network shown in fig. 6, the network topology is a ring, the DCN construction process is advanced from GNE to both left and right directions, and the schedules on both sides may be found from both left and right sides in a certain network element. For example, if NE3 and NE5 are both managed, they may both discover the network element NE4 to be managed. At this time, since the reported network element discovery information includes the MAC address of the network element, the network management system should be able to determine that the NE3 and the NE5 discover that they are the same network element to be managed. After the network management system instructs one side (say NE3) to establish IBM tunnels and manage NE4, the other side (NE5) does not need to establish IBM via IBM _ SETUP _ REQ message.
Generally, a network element may be discovered by multiple managed network elements, and the network management system should only instruct one managed network element to establish an IBM channel between it and the managed network element, bringing this network element into management. The simple rule is the sequence, that is, the network element to be managed is instructed by the network element to be managed to establish an IBM channel with the network element to be managed when the network element to be managed is found after the network element to be managed is received and reported first.
Of course (not in the scope of the new design of the method), it is also possible to open up an IBM tunnel between NE4 and NE5 as a redundant tunnel to enhance the robustness of DCN (note that routing configuration should avoid looping), but this is only established by directly configuring NE4 and NE5 respectively through the network management system. In fact, after NE4 is managed, it will not accept any more IBM _ SET _ REQ requests as a managed network element, but will instead Return an IBM _ SET _ ACK message with a Return Code field of IBM _ SET _ ERR _ INVALID, rejecting such a setup request. Moreover, after NE4 is managed, our initial construction of DCNs has been completed; the latter operation can be completed by normal network management command, which is not in the new design range of the method, including further improvement of DCN, such as establishing redundant channel, further routing protocol and routing configuration.
Other parts of this embodiment are the same as embodiment 1, and thus are not described again.
Example 3:
further, in embodiment 1, after the IBM tunnel is established between NE2 and NE3, the network management system automatically configures a static routing table entry for reaching the IP address of NE3 on GNE and NE1, so that NE3 is reachable. If a dynamic routing protocol is run, the dynamic routing protocol may also maintain the route, and there is no need to configure such a static route. Only the routing protocol needs to be configured according to the same rule. For example, OSPF, only needs to ensure that all the IBM channel interfaces of the related network elements are configured in the same OSPF Area (Area).
The invention can automatically discover a new network element and the connection which can reach the network element in the PTN network, and remotely establish an in-band management channel to the new network element, thereby bringing the new network element into the management range of a network management system. In the whole process, only GNE is needed to be connected, personnel do not need to go to the site of each device, and the construction of the DCN can be automatically completed. The invention can improve the working efficiency, shorten the construction period, save the labor cost, avoid the mismatching possibly generated by the operation of personnel and have better practicability.
Other parts of this embodiment are the same as embodiment 1, and thus are not described again.
The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention in any way, and all simple modifications and equivalent variations of the above embodiments according to the technical spirit of the present invention are included in the scope of the present invention.
Claims (3)
1. A method for automatically discovering and configuring in-band DCN in PTN network is characterized in that the method comprises the processes of discovering a network element to be managed based on IBM extension information, establishing an IBM channel between the network element to be managed and a network element to be managed, and managing a new access network element by a network management system;
through the interaction of IBM _ HELLO messages between adjacent network elements, the managed network element finds the network element to be managed and the physical connection which can establish an IBM channel, and reports the physical connection to a network management system;
after discovering the network element to be managed, the network management system sends an instruction to the managed network element reporting the discovery, and requests to make IBM channel configuration; except the target network element and the port, the network management system appoints the MPLS label of the IBM channel and the IP address of the network element to be managed; the managed network element sends an IBM _ SETUP _ REQ message to the network element to be managed on an IBM port to be established and requires the network element to be managed to carry out IBM configuration; the network element to be managed configures IBM on a receiving port, configures an IP address and a default route passing through the IBM channel, and sends an IBM _ SETUP _ ACK confirmation message to the managed network element; after the configuration of the management network element IBM is completed, the updated IBM _ HELLO message is sent to the managed network element; the managed network element reports the completion of IBM channel configuration to the network management system, so that the network management system can be connected with the network element to be managed to manage the network element;
the IBM extension message is extended based on an 802.1ab LLDP protocol message and comprises three message types including IBM _ HELLO, IBM _ SETUP _ REQ and IBM _ SETUP _ ACK;
IBM _ HELLO: an announcement message announcing the status of the network element and the NNI port;
IBM _ SETUP _ REQ: IBM sets up the solicited message;
IBM _ SETUP _ ACK: IBM sets up the confirmation message.
2. The method of claim 1, wherein in the process of discovering the network element to be managed based on IBM extension message, the managed network element and the network element to be managed interact via IBM _ HELLO message; the pipe waiting network element in the initial state must respond to the IBM _ HELLO message; if NE STATUS = NE _ STATUS _ INIT and Port STATUS = PORT _ STATUS _ IBM _ NO in IBM _ HELLO TLV content in IBM _ HELLO message received by managed network element, then the managed network element can be confirmed to be a to-be-managed network element with an initial state at the opposite end, and the managed network element reports information to the network management system; the reported information comprises candidate IBM ports of the managed network element, the network element to be managed and corresponding ports thereof.
3. The method according to claim 1, wherein the content of the IBM _ SETUP _ REQ message includes Label = MPLS Label specified by the network management system, IP Address = IP Address allocated by the network management system for the peer standby network element, GW Address = IP Address of the managed network element in the in-band DCN; the IBM _ SETUP _ ACK acknowledgement message has a Return Code = IBM _ SET _ OK in its IBM _ SETUP _ ACK TLV content, and SN = SN in the received IBM _ SETUP _ REQ; and the Port STATUS = Port _ STATUS _ IBM _ SET of the IBM _ HELLO TLV for sending the IBM _ HELLO message after the configuration of the network element to be managed is completed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810438017.3A CN108650126B (en) | 2018-05-09 | 2018-05-09 | Method for automatically discovering and configuring in-band DCN in PTN network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810438017.3A CN108650126B (en) | 2018-05-09 | 2018-05-09 | Method for automatically discovering and configuring in-band DCN in PTN network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108650126A CN108650126A (en) | 2018-10-12 |
| CN108650126B true CN108650126B (en) | 2021-04-23 |
Family
ID=63753984
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810438017.3A Active CN108650126B (en) | 2018-05-09 | 2018-05-09 | Method for automatically discovering and configuring in-band DCN in PTN network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108650126B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111917621B (en) * | 2019-05-10 | 2021-09-07 | 烽火通信科技股份有限公司 | Communication method and system for network management server and network element of communication equipment |
| CN110351141B (en) * | 2019-07-12 | 2022-05-17 | Ut斯达康通讯有限公司 | Flexe interface management method, device and network element |
| CN111786888B (en) * | 2020-03-24 | 2022-08-09 | 北京京东尚科信息技术有限公司 | Interface isolation method and device |
| CN111565149B (en) * | 2020-04-03 | 2022-04-08 | 烽火通信科技股份有限公司 | Method and device for keeping remote session alive under LDP RLFA FRR scene |
| CN115334042A (en) * | 2021-04-25 | 2022-11-11 | 中国移动通信有限公司研究院 | Data transmission method, device and system and communication equipment |
| CN115296987B (en) * | 2022-07-25 | 2023-11-10 | 烽火通信科技股份有限公司 | Automatic network element management method and system for SDH equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102223278A (en) * | 2011-05-17 | 2011-10-19 | 中兴通讯股份有限公司 | Realization method and system for enabling LLDP function on non-Ethernet link |
| CN103259728A (en) * | 2013-05-24 | 2013-08-21 | 华为技术有限公司 | OFS in-band communication method and OFS |
| CN105591798A (en) * | 2015-07-24 | 2016-05-18 | 杭州华三通信技术有限公司 | Method and device for transmitting OAM information in DCN |
| CN105791014A (en) * | 2016-03-09 | 2016-07-20 | 浪潮通信信息系统有限公司 | Method for performing network relationship discovery and automatically realizing layered TOPO display by means of LLDP |
| WO2017000858A1 (en) * | 2015-06-30 | 2017-01-05 | 中兴通讯股份有限公司 | Network element device and method for opening data communication network |
| CN107995041A (en) * | 2017-12-12 | 2018-05-04 | 江西山水光电科技股份有限公司 | A kind of DCN management methods of PTN network |
-
2018
- 2018-05-09 CN CN201810438017.3A patent/CN108650126B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102223278A (en) * | 2011-05-17 | 2011-10-19 | 中兴通讯股份有限公司 | Realization method and system for enabling LLDP function on non-Ethernet link |
| CN103259728A (en) * | 2013-05-24 | 2013-08-21 | 华为技术有限公司 | OFS in-band communication method and OFS |
| WO2017000858A1 (en) * | 2015-06-30 | 2017-01-05 | 中兴通讯股份有限公司 | Network element device and method for opening data communication network |
| CN106330511A (en) * | 2015-06-30 | 2017-01-11 | 中兴通讯股份有限公司 | Network element device and method for opening data communication network |
| CN105591798A (en) * | 2015-07-24 | 2016-05-18 | 杭州华三通信技术有限公司 | Method and device for transmitting OAM information in DCN |
| CN105791014A (en) * | 2016-03-09 | 2016-07-20 | 浪潮通信信息系统有限公司 | Method for performing network relationship discovery and automatically realizing layered TOPO display by means of LLDP |
| CN107995041A (en) * | 2017-12-12 | 2018-05-04 | 江西山水光电科技股份有限公司 | A kind of DCN management methods of PTN network |
Non-Patent Citations (1)
| Title |
|---|
| LLDP Based Link Latency Monitoring in Software Defined Networks;Lingxia Liao;《 2016 12th International Conference on Network and Service Management (CNSM)》;20170119;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108650126A (en) | 2018-10-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108650126B (en) | Method for automatically discovering and configuring in-band DCN in PTN network | |
| CN100512292C (en) | Apparatus and method of real-time recovering service | |
| JP5350461B2 (en) | Enhanced traffic indication in connection failure management | |
| CN100389571C (en) | Method for detecting chain circuit fault between end-to-end notes in mixed network | |
| US7173934B2 (en) | System, device, and method for improving communication network reliability using trunk splitting | |
| US8203932B2 (en) | Method and system for protection switching in ethernet ring | |
| CN101652963B (en) | Method for reconfiguring a communications network | |
| CN102638389A (en) | Redundancy backup method and system of TRILL (Transparent Interconnection over Lots of Links) network | |
| US6973049B2 (en) | Auto-configuration of network interfaces in a bidirectional ring network | |
| AU2010282625B2 (en) | System and method for graceful restart | |
| JP5609995B2 (en) | COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION DEVICE | |
| EP2553870B1 (en) | An operations, administrations and management proxy and a method for handling operations, administrations and management messages | |
| CN107294816B (en) | Information transmission apparatus, communication network and method thereof | |
| CN101895437A (en) | Method and equipment of distributed bidirectional forwarding detection (BFD) | |
| CN110351141B (en) | Flexe interface management method, device and network element | |
| CN103490951A (en) | Bidirectional forwarding detection method in multi-hop link on basis of BFD | |
| JP2003258822A (en) | Packet ring network and inter-packet ring network connection method used in the same | |
| CN108234305B (en) | Control method and equipment for cross-machine frame link redundancy protection | |
| KR100701105B1 (en) | Method for configuration and protection of control channel in IP-based network and method of status transition therefor | |
| WO2011097893A1 (en) | Method, device and system for transmitting e1 bidirectional looped network data | |
| JP5974911B2 (en) | Communication system and network relay device | |
| US20050089029A1 (en) | Method for operating a transmission system and transmission system in an energy supply network | |
| CN113037883B (en) | Method and device for updating MAC address table entries | |
| CN109600290A (en) | A kind of more main methods coexisted in loop network | |
| US20160057010A1 (en) | Method and system for mapping different layouts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |