WO2021057517A1

WO2021057517A1 - Method for monitoring multicast service and board

Info

Publication number: WO2021057517A1
Application number: PCT/CN2020/114858
Authority: WO
Inventors: 路永斌
Original assignee: 中兴通讯股份有限公司
Priority date: 2019-09-24
Filing date: 2020-09-11
Publication date: 2021-04-01
Also published as: CN112637708A

Abstract

Disclosed in embodiments of the present invention are a method for monitoring a multicast service and a board. The method is applied to an optical line terminal (OLT) and comprises: the board in the OLT regularly scans its own upper-layer service data and lower-layer hardware data; compare whether the upper-layer service data is consistent with the lower-layer hardware data; and perform multicast service monitoring according to the comparison result. In this way, a multicast service can be monitored in real time on an OLT device.

Description

Method and board for monitoring multicast service

Technical field

The embodiment of the present invention relates to but is not limited to a multicast service, and more specifically relates to a method and board for monitoring a multicast service.

Background technique

At present, large-scale commercial applications are mainly EPON (Ethernet Passive Optical Network, Ethernet passive optical network) and GPON (Gigabit-capable Passive Optical Network, Gigabit Passive Optical Network) technologies, which are compatible with traditional access network technologies and Ethernet technologies. Compared with switch technology, the physical layer of PON (Passive Optical Network) is a point-to-multipoint topology. The downlink data adopts the physical layer broadcast mode, that is, the downlink data will be transmitted to all the links on the link. Terminal equipment (ONU, Optical Network Unit, Optical Network Unit).

On the basis of the physical layer, the PON link layer establishes a logical point-to-point channel, so its forwarding methods for unicast and multicast services are as follows:

a) The unicast service is sent to the ONU through the logical unicast channel.

b) The multicast service takes advantage of the downstream broadcast characteristics of the physical layer and sends it directly to the ONU through the broadcast channel.

The reason why unicast and multicast services use different forwarding channels is because for multicast services, if the unicast channel is also used, it means that a large number of multicast data packets need to be made on the OLT (Optical Line Terminal) side Replication increases the complexity of device implementation, and large-traffic replication multicast packets will cause a lot of waste of link bandwidth.

As shown in Figure 1, for the central office OLT equipment, the mainstream adopts the architecture of PON board, switch board (control board/main control board), and uplink board on the forwarding plane. The PON board stores the user joining information of the board, and the switch board (control board/main control board) stores the user joining information of the entire OLT. Therefore, the replication of multicast services usually needs to be performed at multiple points in the equipment. For example, multicast service packets need to be replicated and forwarded to multiple PON boards on the switch board (control board/main control board), and replicated and forwarded on the PON board. Give multiple PON ports. After the multicast service packet is copied to the PON port, it will not be further copied and forwarded to multiple ONUs. Instead, the downstream multicast or broadcast channel will be forwarded to the ONU in a single copy mode (SCB, Single Copy Broadcast). During the multicast forwarding process, the OLT device receives the multicast service traffic from the source port. The source port is used as the first-level replication point of the multicast, which is generally located on the switch board (control board/main control board); on the PON board, the traffic is transferred again The replication is distributed to the PON port, and the distribution port is the secondary replication point of the multicast. For example, the downstream data forwarding method is specifically shown in Figure 2. The 1 on the switch board is the first-level replication point; the 2 on the PON board is the second-level replication point, and the black box is the PON port.

With the popularization of PON networks on existing networks, operators have higher and higher requirements for the business stability of OLT equipment. As a very important and widely used service, multicast will also have various problems in the operation of the existing network. Generally, when a fault occurs, the maintenance personnel can only passively wait for the user to report the fault, and then go to the scene to deal with it, which is inefficient and easily leads to user complaints. At the same time, the OLT device cannot perform self-diagnosis and self-recovery after a failure, which also leads to problems that cannot be solved quickly.

For this reason, there is an urgent need for real-time monitoring of high-value services such as multicast. Once a problem occurs, it can perform self-diagnosis and self-recovery in a timely manner. If it does not recover automatically, it can report an alarm in time so that maintenance personnel can immediately intervene and deal with it. However, the OLT equipment on the current network does not support this function at all.

Summary of the invention

In view of this, an embodiment of the present invention provides a method for monitoring multicast services, which is applied to an optical line terminal OLT, and includes:

The board in the OLT regularly scans its own upper-layer service data and lower-layer hardware data;

Compare whether the upper-layer business data and the underlying hardware data are consistent;

Monitor the multicast service according to the comparison result.

The embodiment of the present invention also provides a board, which is applied to an optical line terminal OLT, and includes:

The scanning unit is set to scan its own upper-layer business data and lower-layer hardware data regularly;

The comparing unit is set to compare whether the upper-layer business data and the lower-layer hardware data are consistent;

The monitoring unit is set to monitor the multicast service according to the comparison result.

The technical solution provided by the embodiment of the present invention can perform real-time monitoring of the multicast service on the OLT device.

Other features and advantages of the present invention will be described in the following description, and partly become obvious from the description, or understood by implementing the present invention. The purpose and other advantages of the present invention can be realized and obtained through the structures specifically pointed out in the specification, claims and drawings.

Description of the drawings

The accompanying drawings are used to provide a further understanding of the technical solution of the present invention, and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present invention, and do not constitute a limitation to the technical solution of the present invention.

Figure 1 is a schematic diagram of the architecture of an existing OLT device;

Figure 2 is a schematic diagram of downlink data forwarding of existing OLT equipment;

Figure 3 is a schematic diagram of a data forwarding port in an existing OLT device;

4 is a schematic flowchart of a method for monitoring multicast services according to an embodiment of the present invention;

5 is a schematic flowchart of a method for monitoring multicast services according to another embodiment of the present invention;

6 is a schematic flowchart of a method for monitoring multicast services according to another embodiment of the present invention;

FIG. 7 is a schematic diagram of a flow when the results of monitoring and comparison in the board are inconsistent in another embodiment of the present invention;

FIG. 8 is a schematic diagram of the flow when the comparison results of the internal monitoring of the boards are consistent in another embodiment of the present invention; FIG.

FIG. 9 is a schematic structural diagram of a board card provided by an embodiment of the present invention.

detailed description

In order to make the objectives, technical solutions and advantages of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. It should be noted that the embodiments in this application and the features in the embodiments can be combined with each other arbitrarily if there is no conflict.

The steps shown in the flowcharts of the drawings can be executed in a computer system such as a set of computer-executable instructions. And, although a logical sequence is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than here.

For the current OLT forwarding architecture, the key forwarding ports for multicast are shown in Figure 3. 1 is the PON port on the PON board; 2 is the port that connects the PON board to the switch board (control board/main control board); 3 is The port connecting the switch board (control board/main control board) side to the PON board; 4 is the port connecting the switch board (control board/main control board) side to the upper link board; 5 is the upper link board side and the switch board (control Board/main control board) link port; 6 is the multicast source port.

The technical solution provided by the embodiment of the present invention is based on the key forwarding node of the multicast, and the multicast service is monitored in real time on the OLT device.

FIG. 4 is a schematic flowchart of a method for monitoring multicast services according to an embodiment of the present invention. The method is applied to the optical line terminal OLT, as shown in Fig. 4, the method includes:

Step 401: The board in the OLT periodically scans its own upper-layer service data and lower-layer hardware data;

Step 402: Compare whether the upper-layer service data and the lower-layer hardware data are consistent;

Step 403: Perform multicast service monitoring according to the comparison result.

Wherein, the upper-layer service data includes the multicast group group of the upper-layer service and the export list corresponding to each group;

The bottom-level hardware data includes the Group of the bottom-level hardware, the export list corresponding to each group, and the ingress and egress traffic of each group.

Wherein, the comparing whether the upper-layer business data and the lower-layer hardware data are consistent includes:

Compare whether the multicast group group of the upper-layer service is consistent with the group of the underlying hardware;

Compare whether the export list corresponding to each Group of the upper-level business is consistent with the export list corresponding to each Group of the underlying hardware.

Wherein, the monitoring of the multicast service according to the comparison result includes:

When the upper-layer service and the first group of the lower-layer hardware are inconsistent, and/or the exit lists corresponding to the first group of the upper-layer service and the lower-layer hardware are inconsistent, performing fault recovery includes:

Send a specific query message of the first Group to all users;

If there is a user response, record the port information of all the responding users, and update the export list corresponding to the first Group of the upper-layer service and the underlying hardware according to the port information of all the responding users;

If there is no user response, the upper-layer service and the lower-layer hardware are notified to delete the entry corresponding to the first Group.

When the upper-layer service and the group of the lower-layer hardware are consistent, and the export list corresponding to the upper-layer service and the group of the lower-layer hardware is consistent, compare the ingress and egress traffic of each group;

When the difference between the ingress and egress traffic of any group exceeds the threshold, confirm the location of the packet loss and perform fault recovery.

Wherein, the board card is one of the following: a passive optical network PON board, a switch board, and an uplink board.

Wherein, when the board is a switch board, the method further includes:

The switch board regularly scans the underlying hardware data on different PON boards and uplink boards;

Compare whether its own upper-layer service data is consistent with the bottom-layer hardware data on the different PON boards and uplink boards;

When the upper-layer service of the switch board is inconsistent with the first Group of the underlying hardware on the different PON board and the uplink board, and/or, the upper-layer service of the switch board is different from the different PON board and the uplink board When the export list corresponding to the first Group of the underlying hardware is inconsistent, perform fault recovery, including:

Send a specific query message of the first Group to all users;

If a user responds, record the port information of all the responding users, and update the upper-layer services of the switch board and the first layer of the underlying hardware on the different PON boards and the upper-link board according to the port information of all the responding users. The export list corresponding to the Group;

If there is no response from the user, the upper-layer service of the switch board and the lower-layer hardware on the different PON board and the upper-link board are notified to delete the entry corresponding to the first Group.

Among them, the method also includes:

When the upper-layer service of the switch board is consistent with the Group of the lower-layer hardware on the different PON board and the uplink board, and the upper-layer service of the switch board is the Group of the lower-layer hardware on the different PON board and the uplink board When the corresponding export lists are consistent,

Comparing the egress traffic of the switch board of each group with the ingress traffic of the different PON boards;

Compare the inlet flow rate of the switch board and the outlet flow rate of the uplink board of each group;

Among them, after the failure recovery, the method also includes:

Scan the upper-level business data and the underlying hardware data again;

Compare whether the corresponding upper-layer business data and the underlying hardware data are consistent;

When they are consistent, the fault recovery is successful; when they are inconsistent, the fault recovery fails, and an alarm is reported.

FIG. 5 is a schematic flowchart of a method for monitoring a multicast service according to another embodiment of the present invention.

This embodiment is applied to the scene of monitoring in the board.

The method is applied to the optical line terminal OLT, as shown in Fig. 5, the method includes:

Step 501, the board scans regularly, and obtains the upper-layer business data and the lower-layer hardware data from the upper-layer business and the lower-layer hardware;

Among them, the current mainstream OLT equipment adopts a distributed processing method, that is, the PON board, the switch board (control board/main control board), and the uplink board will all process the multicast service and maintain the multicast forwarding entries. The PON board, switch board (control board/main control board), and uplink board all enable timers to scan the dynamic entries of the corresponding single board (board card) regularly, and obtain multicast forwarding data from the hardware, that is, the underlying hardware data .

Wherein, the board can be a PON board, a switch board (control board/main control board), or an uplink board.

Specifically, there are two data obtained from the underlying hardware:

1. Group information forwarded by the hardware, including the number of dynamic groups on the hardware, specific group information and source information, and the list of outgoing ports corresponding to each group;

Among them, the multicast forwarding data and upper-layer service data can be captured when scanning is triggered.

2. The total number of packets forwarded by each group, including the inbound port statistics and the outbound port statistics of each group.

Among them, the ingress port statistics refers to the cumulative number of ingress traffic from the last scan to this scan, and the egress port statistics refers to the cumulative number of egress traffic from the last scan to this scan.

Step 502: Compare whether the upper-layer service data and the lower-layer hardware data are consistent;

When the comparison results are inconsistent, it means that there is a fault in the service and fault recovery is required. Step 503 is executed. When the comparison results are consistent, step 506 is executed.

Wherein, the comparison result is inconsistent, including: any Group of the upper-layer service and the lower-layer hardware is inconsistent, and/or, the export list corresponding to any Group of the upper-layer service and the lower-layer hardware is inconsistent.

The comparison result is consistent, including: the upper-layer business and the group of the underlying hardware are consistent, and the export list corresponding to the upper-layer business and the group of the underlying hardware is consistent.

Step 503: Send a specific query message of the abnormal group to all users;

Among them, the in-board monitoring is used in the PON board or the uplink board. For the entire OLT system, the PON board or the uplink board is only responsible for the user of the board, and it does not care about the addition of users of other boards. So for it, all users are the receiving ports configured on the board (ie legal users). Inter-board monitoring is used in the switch board. For the entire OLT system, the switch board stores the user information of the entire system, and it cares about the joining of all boards. So for him, all users are the receiving ports (ie legal users) configured on the entire system.

Among them, the abnormal group refers to a group with inconsistent status in the upper-layer business and the underlying hardware, or a group with inconsistent export lists.

If there is a user answer, go to step 504, if there is no user answer, go to step 506;

Step 504: Record the port information of all responding users, and update the exit list corresponding to the abnormal group of the upper-layer service and the underlying hardware according to the port information of all the responding users;

Step 505: Notify the upper-layer service and the lower-layer hardware to delete the entry corresponding to the abnormal Group;

Because there is no user response, it indicates that the Group is currently unwatched, so the deleted entry here specifically refers to the entire Group entry, including Group group information, Group source information, and Group export list information.

Specifically, the inconsistent comparison results include two situations:

a, the existence status of a group is inconsistent;

Among them, the inconsistency of any Group between the upper-layer business and the underlying hardware specifically refers to the inconsistent status of Groop. For example, there is a Group entry in the upper-layer business, but there is no Group entry in the underlying hardware; or there is no Group entry in the upper-layer business, but there is a Group entry in the underlying hardware.

b. The export list in a certain group is inconsistent; when either situation occurs, a specific query message of the abnormal group will be sent to all users, and the message will be processed according to the response of the message. For example, after sending a specific query message, if no user's response is received, the upper-layer service and the underlying hardware are notified to delete the entry; if there is a user's response, the port information of all responding users will be recorded, and it will be compared with the current service. The hardware export list is compared, and the comparison result is recorded; then the export list of the upper-level business and the lower-level hardware for the group is updated according to the latest export list information. Among them, the specific query message here is a query message sent for an abnormal group, which is constructed and sent according to the definition of Group-Specific Query in standards such as rfc2236 and rfc3376.

Regardless of the situation a or the situation b, after the automatic recovery, the relevant information of the underlying hardware can be obtained again for the recovery group immediately, and compared with the upper-layer business to confirm the effect of the automatic recovery.

When the comparison results are inconsistent, through steps 503-505, the user's actual status is inquired (the inquiry method can be carried out by a specific inquiry message), the forced recovery is carried out according to the inquiry result, and whether to report an alarm is determined according to the recovery situation.

Step 506: Compare the ingress and egress traffic of each group, and when the difference between the ingress and egress traffic of any group exceeds the threshold, confirm the packet loss location and perform fault recovery;

For example, for IPTV multicast services, the threshold may be 5%. That is, if the flow rate difference between the inlet and the outlet exceeds 5%, it is considered an abnormality. Because according to experience, when the traffic difference exceeds 5%, users will obviously perceive IPTV picture abnormalities, such as mosaic or black screen.

Specifically, after it is found that the difference between the ingress flow and the egress flow exceeds 5%, because hardware forwarding may involve multiple links, it is necessary to confirm at which link the packet is forwarded abnormally. The hardware can be used for analysis and positioning, and the commands provided by the chip can be directly called for query; it can also be analyzed and positioned by software means. After confirming the location of the packet loss, use the embedded command to query the status of the location, confirm the specific cause of the packet loss, and perform forced recovery. If the recovery is successful, record the log; if the recovery fails, report an alarm. Among them, the current query method for calling the chip is to embed the query command of the chip in the system in advance. Once a problem occurs, the call is processed to confirm the location of the packet loss; taking the GPON line card as an example, the data forwarding of the chip involves Such as pon-tm, pon-mac and other internal modules, after a problem occurs, call the pre-embedded query commands of these modules to confirm whether the traffic is forwarded normally. Once the abnormal point inside the chip is confirmed, if a certain register bit is abnormal, it will be forcibly modified and set to ensure that it is restored to the correct state.

Step 507: Scan its own upper-layer business data and lower-layer hardware data again; compare whether the upper-layer business data and the lower-layer hardware data are consistent;

When they are consistent, perform step 508, and the fault recovery is successful; when they are inconsistent, perform step 509, and the fault recovery fails, and an alarm is reported.

In this embodiment, in each scan, you can also record the obtained Group information and its corresponding ingress and egress traffic, generate log logs, and obtain them by means of scheduled automatic uploads or manual triggers for easy maintenance Personnel can inquire about the historical traffic forwarding situation of a certain group at a certain time, which is conducive to a more detailed grasp of the operating status of the equipment.

In this embodiment, when the next scanning period arrives, the operations of steps 501-509 are repeated.

The technical solution provided in this embodiment is capable of real-time monitoring and self-recovery multicast services in the board.

In another embodiment of the present invention, the difference from the previous embodiment is that it is divided into real-time monitoring within the board and real-time monitoring between the boards. The real-time monitoring within the board is the main one, and the real-time monitoring between the boards is Auxiliary, coordinate to complete the real-time monitoring function of the entire system. For on-board detection, the board triggers a regular scan, and only compares the data of the bottom-layer hardware of the board with the upper-layer business data. In this embodiment, on the basis of in-board detection, inter-board detection is added, and the switch board (control board/main control board) triggers timing scanning to obtain the bottom hardware data of different PON boards and uplink boards. (Control board/Main control board) After summarizing the bottom hardware data of each board, compare it with the upper-layer business data of the switch board (control board/main control board) to determine whether they are consistent.

When the upper-layer service of the switch board is inconsistent with the first Group of the underlying hardware on the different PON board and the uplink board, and/or, the upper-layer service of the switch board is different from the different PON board and the uplink board When the export list corresponding to the first Group of the underlying hardware is inconsistent, send a specific query message of the first Group to all users; if there is a user response, record the port information of all the responding users, according to the port information of all the responding users Update the upper-layer service of the switch board and the export list corresponding to the first Group of the bottom hardware on the different PON board and the upper-link board; if there is no user response, notify the upper-layer service of the switch board and the The bottom layer hardware on different PON boards and uplink boards deletes the entry corresponding to the first Group.

When the upper-layer service of the switch board is consistent with the Group of the lower-layer hardware on the different PON board and the uplink board, and the upper-layer service of the switch board is the Group of the lower-layer hardware on the different PON board and the uplink board When the corresponding outlet lists are the same, compare the outlet traffic of the switch board of each group with the inlet traffic of the different PON boards; compare the inlet traffic of the switch board of each group and the outlet traffic of the uplink board ; When the difference between the ingress and egress traffic of any Group exceeds the threshold, confirm the packet loss location and perform fault recovery.

Among them, after fault recovery, you can also perform on-board monitoring and inter-board monitoring, that is, scan the upper-layer business data and the underlying hardware data again; compare whether the corresponding upper-layer business data and the underlying hardware data are consistent; when they are consistent, the fault recovery is successful , End the process; when it is inconsistent, it means that the fault recovery has failed, and an alarm is reported.

FIG. 6 is a schematic flowchart of a method for monitoring a multicast service according to another embodiment of the present invention.

This embodiment is applied to the scenario of simultaneous monitoring within and between boards.

This embodiment is applied to the system architecture shown in FIG. 3. As shown in Figure 3, the entrances of each data forwarding node are 2, 4, and 6; the exits are 1, 3, and 5 respectively.

As shown in Figure 6, the method includes:

Step 601, the OLT's PON board, switch board, and uplink board periodically scan, and obtain its own upper-layer service data and lower-layer hardware data from the upper-layer service and the underlying hardware; the switch board triggers the regular scan to obtain different PON boards and uplink boards. Low-level hardware data;

Specifically, for in-board detection, the board triggers the timing scan. For inter-board detection, the switch board (control board/main control board) triggers the timing scan.

Among them, timers can be enabled on the PON board, switch board (control board/main control board), and uplink board to scan the dynamic entries of the corresponding single board regularly, and obtain multicast forwarding data from the hardware.

Step 602: The PON board, the switch board, and the uplink board respectively compare whether their upper-layer service data is consistent with the underlying hardware data, and the switch board compares whether its own upper-layer service data is consistent with the bottom-layer hardware data on different PON boards and uplink boards;

The PON board, the switch board, and the uplink board respectively compare whether their upper-layer service data and the underlying hardware data are consistent, including:

Compare whether the multicast group group of its own upper-layer service is consistent with the group of the underlying hardware;

Compare whether the export list corresponding to each Group of its upper-level business is consistent with the export list corresponding to each Group of the underlying hardware.

The switch board compares whether its upper-layer service data is consistent with the bottom-layer hardware data on different PON boards and uplink boards, including:

Compare whether the multicast group group of its own upper-layer service is consistent with the group of the underlying hardware on different PON boards and uplink boards;

Compare whether the export list corresponding to each Group of its own upper-level business is consistent with the export list corresponding to each Group of the bottom-level hardware on different PON boards and uplink boards.

When the comparison results are inconsistent, it means that there is a business failure and fault recovery is required. Step 603 is executed. When the comparison results are consistent, step 606 is executed:

Among them, the inconsistent comparison results include inconsistent comparison within the board or inconsistency between the boards, and the consistency of the comparison result refers to the comparison within the board and the comparison between the boards.

Step 603: Send a specific query message of the abnormal group to all users;

If there is a user answer, go to step 604, if there is no user answer, go to step 605,

Step 604: Record the port information of all responding users, and update the exit list corresponding to the abnormal Group according to the port information of all responding users;

Step 605: Notify the corresponding upper-layer service and lower-layer hardware to delete the entry corresponding to the abnormal Group;

Specifically, when the comparison results are inconsistent, the user's actual status is inquired, the forced recovery is performed according to the query result, and the decision is made to report an alarm according to the recovery situation. Among them, the user's actual status query can be performed through a specific query message.

For example, when the upper-layer services of the board (ie, PON board, switch board, or uplink board) are inconsistent with the first group of the underlying hardware, and/or the upper-layer services of the board and the first group of the underlying hardware are inconsistent with the export list corresponding to the first group When, send a specific query message of the first Group to all users on the board;

If there is a user response, record the port information of all the responding users, and update the export list corresponding to the first Group of the upper-layer services of the board and the first group of the underlying hardware according to the port information of all the responding users;

If there is no response from the user, the upper-layer service and the lower-layer hardware of the board are notified to delete the entry corresponding to the first Group.

For another example, when the upper-layer service of the switch board is inconsistent with the first Group of the lower-layer hardware on the different PON board and the uplink board, and/or, the upper-layer service of the switch board is inconsistent with the different PON board and the upper layer. When the export list corresponding to the first group of the underlying hardware on the connection board is inconsistent, send a specific query message of the first group to all users;

Step 606, the PON board, the switch board, and the uplink board respectively compare the ingress and egress traffic of each group; the switch board compares the ingress and egress of each group, the ingress traffic data of different PON boards, and the egress of the uplink board. Traffic data; when the difference between the ingress and egress traffic of any Group exceeds the threshold, confirm the location of the packet loss and perform fault recovery;

Specifically in this embodiment, for in-board detection, the PON board compares the flow rates of the inlet 2 and the outlet 1, the switch board compares the flows of the inlet 4 and the outlet 3, and the upper link board compares the flow of the inlet 6 and the outlet 5. For inter-board detection, the exchange board compares the flow rates of the inlet 2 and the outlet 3 and the flow rates of the inlet 4 and the outlet 5.

Among them, when the difference between the ingress and egress traffic of all groups does not exceed the threshold, the business is normal and the process ends.

Step 607: Scan the upper-layer business data and the lower-layer hardware data again; compare whether the corresponding upper-layer business data and the lower-layer hardware data are consistent;

Specifically, step 607 repeats steps 601-602.

When they are consistent, perform step 608, and the fault recovery is successful; when they are inconsistent, perform step 609, and the fault recovery fails, and an alarm is reported.

When the next scan period arrives, repeat the above steps 601-609.

In this embodiment, during each scan, the obtained Group information and its corresponding ingress and egress traffic can also be recorded, log logs are generated, and they can be obtained by means of scheduled automatic uploading or manual triggering, so as to facilitate maintenance. Personnel can inquire about the historical traffic forwarding situation of a certain group at a certain time, which is conducive to a more detailed grasp of the operating status of the equipment.

The technical solution provided by the embodiment of the present invention adopts the whole process from the OLT entrance to the OLT exit, and performs forwarding entry inspection and flow monitoring for each link of the OLT. After a problem occurs, it automatically detects and locates the problem node and records the problem. Information, and automatic recovery of business at the same time.

Another embodiment of the present invention is applied to a scenario when the comparison result between the upper-layer service data and the lower-layer hardware data of the first board card itself is inconsistent. When the comparison result between the upper-layer service data and the lower-layer hardware data of the first board card itself is inconsistent, it indicates that fault recovery is required, and the process shown in FIG. 7 is subsequently executed.

As shown in Figure 7, it includes:

Step 701: The first board sends a specific query message of the abnormal group to all users;

Among them, the first board is a PON board, a switch board or an uplink board.

Follow-up processing is performed according to the response of the message, step 702 is executed when there is a user response, and step 705 is executed when there is no user response:

Step 702: Record the port information of all responding users, and generate the latest port list;

Step 703: Compare the latest port list with the existing port list, and record the comparison result;

Step 704: Notify the upper-layer services and the underlying hardware to update to the latest port list;

Step 706 is then executed.

Step 705, notify the upper-layer business and the lower-layer hardware to delete the entry corresponding to the abnormal group;

Step 706: Obtain the upper-layer business data and the lower-layer hardware data again, and compare whether the upper-layer business data and the lower-layer hardware data are consistent;

If they are consistent, execute step 707, if they are inconsistent, execute step 708:

Step 707, the recovery is successful, and the log is recorded;

In step 708, the recovery fails, and an alarm is reported.

Specifically, after the automatic recovery, the relevant information of the underlying hardware will be obtained again for the recovery group and compared with the upper-level business to confirm the effect of the automatic recovery.

In another embodiment of the present invention, when the switching board compares its own upper-layer service data and the lower-layer hardware data on different PON boards and uplink boards are inconsistent, the first board is the switching board, and steps 701-708 are also executed. Since the probability of problems between the boards is much smaller than that in the boards, real-time monitoring between boards can be used as an auxiliary means of monitoring within the boards. The two types of monitoring run at the same time. After a problem occurs, the monitoring results of the two types of monitoring are used. Cross-comparison can quickly recover problems or notify maintenance personnel to quickly intervene in analysis, save positioning time and improve problem solving efficiency.

Another embodiment of the present invention is applied to a scenario where the comparison result of the upper-layer service data and the lower-layer hardware data of the first board card is consistent. When the comparison result of the upper-layer service data and the lower-layer hardware data of the first board is consistent, the process shown in FIG. 8 is subsequently executed.

As shown in Figure 8, it includes:

Step 801: Compare whether the difference between the ingress and egress traffic of any Group in the first board exceeds a threshold;

When the threshold is exceeded, perform fault recovery and go to step 802. When the threshold is not exceeded, the business is normal and the process ends

Step 802, the first board confirms the packet loss position;

Among them, the first board is a PON board, a switch board or an uplink board.

Specifically, because hardware forwarding may involve multiple links, it is first necessary to confirm at which link the message is forwarded abnormally. The hardware can be used for analysis and positioning, and the commands provided by the chip can be directly called for query; it can also be analyzed and positioned by software means.

Step 803, confirm the specific cause of the packet loss and perform forced recovery;

Specifically, after confirming the location of the packet loss, you can use the embedded command to query the status of the location, confirm the specific cause of the packet loss, and perform forced recovery.

Step 804: Obtain the upper-layer business data and the lower-layer hardware data again, and compare whether the upper-layer business data and the lower-layer hardware data are consistent;

If they are consistent, execute step 805, if they are inconsistent, execute step 806:

Step 805, the recovery is successful, and the log is recorded;

In step 806, the recovery fails, and an alarm is reported.

In another embodiment of the present invention, when the switch board compares its own upper-layer service data with the bottom-layer hardware data on different PON boards and uplink boards that are consistent, and the difference between the ingress and egress traffic of the first group exceeds the threshold, the first group One board is a switch board, and steps 801-806 are also executed. Since the probability of problems between the boards is much smaller than that in the boards, real-time monitoring between boards can be used as an auxiliary means of monitoring within the boards. The two types of monitoring run at the same time. After a problem occurs, the monitoring results of the two types of monitoring are used. Cross-comparison can quickly recover problems or notify maintenance personnel to quickly intervene in analysis, save positioning time and improve problem solving efficiency.

FIG. 9 is a schematic structural diagram of a board card provided by an embodiment of the present invention. The board is applied to the optical line terminal OLT, as shown in Figure 9, including:

Among them, the comparison unit is specifically set as

Wherein, the monitoring unit is specifically set as

Send a specific query message of the first Group to all users;

Wherein, the monitoring unit is specifically set as

Wherein, when the board is a switch board,

The scanning unit is also configured to scan the bottom hardware data on different PON boards and uplink boards at regular intervals;

The comparison unit is further configured to compare whether its own upper-layer service data is consistent with the bottom-layer hardware data on the different PON boards and uplink boards;

The monitoring unit is further configured to: when the upper-layer service of the switch board is inconsistent with the first Group of the lower-layer hardware on the different PON board and the uplink board, and/or, the upper-layer service of the switch board is inconsistent with the first Group of the lower-layer hardware on the uplink board. When the export lists corresponding to the first Group of the bottom hardware on different PON boards and uplink boards are inconsistent, perform fault recovery, including:

Send a specific query message of the first Group to all users;

Wherein, when the upper-layer service of the switch board is consistent with the Group of the lower-layer hardware on the different PON board and the uplink board, and the upper-layer service of the switch board is the same as the lower-layer hardware on the different PON board and the uplink board When the export list corresponding to the Group is consistent,

The comparison unit is also set to

The monitoring unit is further configured to confirm the location of the packet loss and perform fault recovery when the difference between the ingress and egress traffic of any Group exceeds a threshold.

Among them, after the failure recovery,

The scanning unit is further configured to scan its own upper-layer business data and lower-layer hardware data again;

The comparing unit is further configured to compare whether the upper-layer service data and the lower-layer hardware data are consistent;

The monitoring unit is also set to succeed in failure recovery when they are consistent, and to report an alarm when failure recovery fails when they are inconsistent.

The embodiment of the present invention also provides a board card, including: a memory, a processor, and a computer program stored on the memory and running on the processor. When the computer program is executed by the processor, A method for realizing any one of the foregoing multicast service monitoring.

The embodiment of the present invention also provides a computer-readable storage medium, the computer-readable storage medium stores an information processing program, and when the information processing program is executed by a processor, the monitoring of any one of the foregoing multicast services is implemented. Steps of the method.

A person of ordinary skill in the art can understand that all or some of the steps, functional modules/units in the system, and apparatus in the methods disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. In the hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may consist of several physical components. The components are executed cooperatively. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer-readable medium, and the computer-readable medium may include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and non-volatile data implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Sexual, removable and non-removable media. Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or Any other medium used to store desired information and that can be accessed by a computer. In addition, as is well known to those of ordinary skill in the art, communication media usually contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as carrier waves or other transmission mechanisms, and may include any information delivery media. .

Claims

A method for monitoring multicast services, applied to an optical line terminal OLT, includes:

The board in the OLT regularly scans its own upper-layer service data and lower-layer hardware data;

Compare whether the upper-layer business data and the underlying hardware data are consistent;

Monitor the multicast service according to the comparison result.
The method of claim 1, wherein:

The upper-layer service data includes the multicast group group of the upper-layer service and the export list corresponding to each group;

The bottom-level hardware data includes the Group of the bottom-level hardware, the export list corresponding to each group, and the ingress and egress traffic of each group.
The method according to claim 2, wherein the comparing whether the upper-layer service data and the lower-layer hardware data are consistent, comprises:

Compare whether the multicast group group of the upper-layer service is consistent with the group of the underlying hardware;

Compare whether the export list corresponding to each Group of the upper-level business is consistent with the export list corresponding to each Group of the underlying hardware.
The method according to claim 3, wherein the monitoring of the multicast service according to the comparison result comprises:

When the upper-layer service and the first group of the lower-layer hardware are inconsistent, and/or the exit lists corresponding to the first group of the upper-layer service and the lower-layer hardware are inconsistent, performing fault recovery includes:

Send a specific query message of the first Group to all users;

If there is a user response, record the port information of all the responding users, and update the export list corresponding to the first Group of the upper-layer service and the underlying hardware according to the port information of all the responding users;

If there is no user response, the upper-layer service and the lower-layer hardware are notified to delete the entry corresponding to the first Group.
The method according to claim 3, wherein the monitoring of the multicast service according to the comparison result comprises:

When the upper-layer service and the group of the lower-layer hardware are consistent, and the export list corresponding to the upper-layer service and the group of the lower-layer hardware is consistent, compare the ingress and egress traffic of each group;

When the difference between the ingress and egress traffic of any group exceeds the threshold, confirm the location of the packet loss and perform fault recovery.
The method of claim 1, wherein:

The board card is one of the following: a passive optical network PON board, a switch board, and an uplink board.
The method according to claim 6, wherein when the board is a switch board, the method further comprises:

The switch board regularly scans the underlying hardware data on different PON boards and uplink boards;

Compare whether its own upper-layer service data is consistent with the bottom-layer hardware data on the different PON boards and uplink boards;

When the upper-layer service of the switch board is inconsistent with the first Group of the underlying hardware on the different PON board and the uplink board, and/or, the upper-layer service of the switch board is different from the different PON board and the uplink board When the export list corresponding to the first Group of the underlying hardware is inconsistent, perform fault recovery, including:

Send a specific query message of the first Group to all users;

If there is a user answer, record the port information of all the answering users, and update the upper-layer services of the switch board and the first layer of the underlying hardware on the different PON boards and the upper-link board according to the port information of all the answering users. The export list corresponding to the Group;

If there is no response from the user, the upper-layer service of the switch board and the lower-layer hardware on the different PON board and the upper-link board are notified to delete the entry corresponding to the first Group.
The method according to claim 7, wherein the method further comprises:

When the upper-layer service of the switch board is consistent with the Group of the lower-layer hardware on the different PON board and the uplink board, and the upper-layer service of the switch board is the same as the Group of the lower-layer hardware on the different PON board and the uplink board When the corresponding export lists are consistent,

Comparing the egress traffic of the switch board of each group with the ingress traffic of the different PON boards;

Compare the inlet flow rate of the switch board and the outlet flow rate of the uplink board of each group;

When the difference between the ingress and egress traffic of any group exceeds the threshold, confirm the location of the packet loss and perform fault recovery.
The method according to any one of claims 4, 5, 7, and 8, wherein, after performing failure recovery, the method further comprises:

Scan the upper-level business data and the underlying hardware data again;

Compare whether the corresponding upper-layer business data and the underlying hardware data are consistent;

When they are consistent, the fault recovery is successful; when they are inconsistent, the fault recovery fails, and an alarm is reported.
A board, applied to an optical line terminal OLT, including:

The scanning unit is set to scan its own upper-layer business data and lower-layer hardware data regularly;

The comparing unit is set to compare whether the upper-layer business data and the lower-layer hardware data are consistent;

The monitoring unit is set to monitor the multicast service according to the comparison result.