WO2014090083A1 - Service bearing method and apparatus during distributed resilient network interconnect - Google Patents

Abstract

Disclosed is a Service bearing method and apparatus during distributed resilient network interconnect (DRNI). The method comprises: within-end systems within DRNI endpoints synchronizing states of the within-end systems and/or states of the ports within the endpoints; the within-end systems detecting occurrence of an event, the event being used to trigger update of the within-end systems and/or ports for bearing services; and the within-end systems updating, according to a sequence of the within-end systems and/or a sequence of the ports for bearing services, and states of the within-end systems and/or states of the ports within the endpoints, the within-end systems and/or ports that currently bear the services. The present invention solves the traffic interruption problem in the prior art that is caused when the aggregated link or the within-end systems fail, reduces the effect of the fault on the services, and improves the user experience.

Description

 TECHNICAL FIELD The present invention relates to the field of communications, and in particular, to a service bearer and a device for distributing a Resilient Network Interconnect (DRNI). BACKGROUND With the rapid development of broadband services, interconnections between networks and networks are used more and more, and more services are carried. Within the network, depending on the technology used, there are multiple ways to protect the link and nodes. As the demand for protection of traffic becomes stronger and stronger, the requirements are getting higher and higher, and operators have also raised the need for protection of network interconnection areas. This type of protection can be implemented by port aggregation. The common method can be port aggregation or loop protection. The ring network protection technology is limited by the network topology, and the method of using the whole network connection for the network interconnection part is not applicable. The IEEE standard 802.1AX-link aggregation can protect multiple links, but only supports single-node link aggregation, which cannot meet the requirements of node protection. In order to be more suitable for network and network interconnection area networking, and to achieve link and edge node protection, IEEE standards organizations propose to extend 802.1AX-link aggregation to implement distributed elastic network interconnection (Distributed Resilient Network) Interconnect (DRNI for short) to support multi-system link aggregation.

DRNI extends 802.1AX so that both ends of a link aggregation group can be aggregated by one or more end-end systems to form a logical endpoint. That is, multiple links in these end systems form a distributed link aggregation group. (Link Aggregation Group, LAG for short), to ensure double protection of links and nodes in the network interconnection area. At present, the DRNI adopts the service packet distribution mode, and the in-end system receives the packet, and forwards the service packet according to the mapping value of the outermost label of the service packet, such as the session ID. The end system receives the packet to be sent to the internal network, or sends the packet to the network node interface (NI) side through the aggregation link of the system in the local end. Whether the label mapping value session ID is in the aggregation port service table or the aggregator service table, if the session ID is in the service table, it is forwarded, otherwise it is discarded. When the aggregation link or the end system fails, the service needs to be switched to other ports or other end systems to send. However, the service is not included in the aggregation service table of other port service tables and other end systems, and services are discarded, causing traffic interruption. In view of the problem that the aggregated link or the end system fails in the related art, the traffic is interrupted, and an effective solution has not been proposed yet. SUMMARY OF THE INVENTION The present invention provides a method and apparatus for service bearer of a distributed elastic network interconnection to solve at least the above problems, in view of the problem that traffic is interrupted when an aggregated link or an in-end system fails in the related art. According to an aspect of the embodiments of the present invention, a DRNI service bearer method is provided, including: synchronizing a state of an in-end system of the endpoint and/or a state of a port between end systems in a DRNI endpoint; The internal system detects that an event has occurred, wherein the event is used to trigger an in-end system and/or port that updates the bearer service; the end-end system is based on an in-end system sequence and/or port sequence carrying the service, and The state of the in-end system and/or the state of the port within the endpoint, updating the in-end system and/or port currently carrying the service. Preferably, the state of the in-end system of the endpoint and the state of the port between the in-end systems in the DRNI endpoint are: the period between the in-terminal systems in the DRNI endpoint mutually advertises its own port state through DRCP And / or the port status of other end systems, to achieve state synchronization between the systems within the end. Preferably, the period between the intra-end systems advertises each other's port status through DRCP and/or the port status of other end systems: the end system performs its own port status information and/or the port status of other end systems The information is carried in the DRCP message in a value TLV manner and sent to other end systems of the DRNI endpoint. Preferably, the port status information includes at least one of the following: distribution enable status information of the aggregation port, LACP status information of the aggregation port, and distribution enable status information of the aggregator. Preferably, the state of the in-end system and/or port of the end point is synchronized between the in-end systems in the DRNI endpoint, and further includes: the port in which the state changes when the port state of the in-end system changes. The associated in-end system advertises the state of the changed state of the port to the other end systems of the DRNI endpoint through the DRCP. Preferably, the event comprises: a change in state of an in-end system and/or port of the endpoint. Preferably, the state of the in-end system and/or port of the endpoint changes, including one of the following: an in-end system failure or failure recovery of the end point of the end point; an inline link failure or failure recovery of the in-end system of the end point The end-end system of the endpoint is removed or added to the aggregation group; the port of the end-end system of the endpoint fails or recovers; and the port of the end-system of the endpoint is removed or added to the aggregation group. Preferably, the determining, by the in-end system, the service currently carried by the in-end system and/or the port whose status is changed to be affected by the event includes: determining, by the in-end system, a service affected by the event; Preferably, the determining, by the in-end system, the service affected by the event comprises: determining, by the in-end system, the service currently carried by the in-end system and/or the port whose status is changed is a service affected by the event. Preferably, the in-end system determines that the service currently carried by the in-end system and/or the port whose status is changed is the service affected by the event, and the end-end system in the DRNI endpoint detects the local end. The port of the system is not available; the system of the port to which the unavailable port belongs is updated to be unavailable, and the port service table of the unavailable port is obtained; and the service included in the port service table is determined as Business affected by the event. Preferably, after the end system detects that the port of the system in the local end is unavailable, the method further includes: the end system to which the unavailable port belongs, notifying the other end systems in the end point that the port is unavailable; The other end system updates the state of the locally saved port to be unavailable, and obtains the port service table of the unavailable port; and determines the service included in the port service table as the service affected by the event. Preferably, the in-end system determines that the service currently carried by the in-end system and/or port whose status is changed is determined to be affected by the event, and includes: the end-end system in the DRNI endpoint detects the current endpoint The connection information of the system in the adjacent end is lost, and the end system that detects the loss of the connection information remains in the aggregation group; the end system that detects the loss of the connection information updates the locally saved end The port status of the internal system is unavailable, and the port service table of the unavailable port is obtained; the service included in the port service table is determined as the service affected by the event. Preferably, the in-end system determines that the service currently carried by the in-end system and/or the port whose status is changed is the service affected by the event, and the end-end system in the DRNI endpoint detects the local end. The port of the system is restored to be available by being unavailable; the recovery is that the state of the port in which the available port belongs is updated, and the current bearer port in the DRNI endpoint is not the first priority port; Recovering to the in-end system to which the available port belongs compares the positional relationship between the reverted available port and the current bearer port of the service in the in-end system sequence and/or port sequence carrying the service; If the port is in a priority position than the current bearer port of the service, the service is determined to be a service affected by the event. Preferably, after the intra-end system detects that the port of the local end system is restored to be available, the method further includes: resuming that the end-end system to which the available port belongs to the other end-end system in the DRNI endpoint The port is available; the other in-end system updates the locally saved state of the port to be available, and obtains the service that the current bearer port in the DRNI endpoint is not the first priority port; the other end systems compare the recovery a positional relationship between an available port and the service in an in-end system sequence and/or port sequence carrying the service; In the case that the available port is in a priority position than the current bearer port of the service, the service is determined to be a service affected by the event. Preferably, the end-end system updates the current end of the service according to the intra-end system sequence and/or port sequence carrying the service, and the status of the intra-end system and/or the status of the port in the end point. The internal system and/or the port includes: a service port table for obtaining the service, where the service port table includes an in-end system sequence and/or a port sequence that carries the service; and according to the bearer in the service port table The sequence of the intra-system sequence and/or the port sequence of the service, the selected state is available and the sequential in-end system and/or port is used as the current bearer system and/or port of the service; The port service table of the current bearer port of the service. According to another aspect of the present invention, a DRNI service bearer is provided, which is located in an in-end system within a DRNI endpoint, and includes: a synchronization module configured to synchronize the state of the in-end system within the DRNI endpoint and/or a status of the port; the detecting module is configured to detect that an event has occurred, wherein the event is used to trigger an in-end system and/or port that updates the bearer service; and the update module is configured to be based on the in-end system sequence of the bearer service and/or Or a port sequence, and the status of the in-end system and/or port within the endpoint, updating the in-end system and/or port currently carrying the service. Preferably, the synchronization module comprises: a first advertising unit, configured to mutually notify the port state of the port and/or the port state of other end systems by DRCP during the period between the end systems. Preferably, the synchronization module includes: a second notification unit, configured to notify, by the DRCP, a port status of a changed state to the other end systems of the DRNI endpoint by using a DRCP in a change in a port state of the system in the end . Preferably, the update module includes: a determining module, configured to determine a service affected by the event; an obtaining unit, configured to obtain a service port table of the service, where the service port table includes carrying the service In-end system sequence and/or port sequence; a selection unit, configured to select a state as available according to an order of end systems and/or ports carrying the service in the service port table, and the order is prior The in-end system and/or port serves as the current bearer system and/or port of the service; the first update unit is configured to update the port service table of the current bearer port of the service. Preferably, the determining module includes: a second updating unit, configured to: after detecting that the port of the system in the local end is unavailable, update the status of the unavailable port to be unavailable, and obtain the port of the unavailable port a first determining unit, configured to determine a service included in the port service table as a service affected by the event. Preferably, the determining module further includes: a first receiving unit, configured to receive an advertisement of another end-end system in the DRNI endpoint, where the notification is used to indicate that a port of the other end-end system is unavailable; The second update unit is further configured to: update the saved state of the port of the other in-end system to be unavailable, and obtain a port service table of the unavailable port; The service included in the port service table is determined to be a service affected by the event. Preferably, the determining module includes: a third updating unit, configured to: after detecting that the connection information with the neighboring end system in the DRNI endpoint is lost, and the in-end system that detects the loss of the connection information remains If the aggregation group is added, the port status of the system in the neighboring end is not available, and the port service table of the unavailable port is obtained. The second determining unit is configured to be in the port service table. The business included is determined to be the business affected by the event. Preferably, the determining module further includes: a fourth updating unit, configured to: after detecting that the port of the system in the local end is restored as unavailable, the status of the port is updated; the priority detecting unit is set to Detecting that the current bearer port in the DRNI endpoint is not the first priority port; the comparing unit is configured to compare the end-to-end system sequence that carries the service to the available port and the current bearer port of the service, and/or a location relationship in the port sequence, and in the case where the recovery to the available port is prioritized than the current bearer port of the service, the service is determined to be a service affected by the event. Preferably, the determining module further includes: a second receiving unit, configured to receive an advertisement of another end-end system in the DRNI endpoint, where the notification is used to indicate that a port of the other end-end system is available; The fourth updating unit is further configured to update the saved state of the port of the other in-end system to be available; the priority detecting unit is further configured to detect that the current bearer port in the DRNI endpoint is not the first priority port. The comparing unit is further configured to compare the positional relationship between the available port and the current bearer port of the service in the intra-system sequence and/or port sequence carrying the service, and restore the If the available port is in a preferred position than the current bearer port of the service, the service is determined to be a service affected by the event. With the embodiment of the present invention, the state of the in-end system of the endpoint and the state of the port are synchronized between the in-end systems in the DRNI endpoint; the in-end system detects that an event has occurred, wherein the event is used to trigger the update bearer. The in-end system and/or port of the service; the in-end system determines the service affected by the event; the in-end system is based on the in-end system sequence and/or port sequence carrying the service, and the state of the in-end system within the endpoint and The status of the port is used to update the current in-band system and/or port that carries the service. This solves the problem that traffic is interrupted when the aggregated link or the end system fails in the related technology, and the fault is reduced. Impact, improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 is a flowchart of a service bearer method for a distributed elastic network interconnection according to an embodiment of the present invention; FIG. 2 is a structural block diagram of a service bearer for a distributed elastic network interconnection according to an embodiment of the present invention; 3 is a block diagram showing a preferred structure of a synchronization module according to an embodiment of the present invention; FIG. 4 is a block diagram showing a preferred structure of an update module according to an embodiment of the present invention; and FIG. 5 is a block diagram showing a preferred structure of a determination module according to an embodiment of the present invention. 6 is a block diagram of a preferred structure of a determining module according to an embodiment of the present invention. FIG. 7 is a block diagram of a preferred structure of a determining module according to an embodiment of the present invention. FIG. 8 is a flowchart of a process of an in-end system in which an aggregate link is faulty according to the first embodiment of the present invention. Figure 9 is a flow chart showing the processing of the system in the other end of the aggregation link failure according to the first embodiment of the present invention; Figure 10 is a flowchart of the processing of the in-end system failure according to the first embodiment of the present invention; The processing flowchart of the system in the end of the aggregation link failure recovery of the first example; FIG. 12 is the processing of the system in the other end of the aggregation link failure recovery according to the first embodiment of the present invention; 13 is a structural block diagram of an apparatus for negotiating a service bearer in a DRNI according to the first embodiment of the present invention; FIG. 14 is a schematic diagram of a networking diagram according to Embodiment 2 of the present invention; FIG. 15 is a schematic diagram of an aggregation chain according to Embodiment 2 of the present invention; FIG. 16 is a schematic diagram of an in-end system failure according to a third embodiment of the present invention; FIG. 17 is a schematic diagram of networking in accordance with Embodiment 4 of the present invention; FIG. 18 is a schematic diagram of a logical port not available according to Embodiment 5 of the present invention; , BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. In this embodiment, a service bearer method for a distributed elastic network interconnection is provided. FIG. 1 is a flowchart of a service bearer method for a distributed elastic network interconnection according to an embodiment of the present invention, as shown in FIG. The method includes the following steps: Step S102: Synchronize the state of the in-end system of the endpoint and/or the state of the port between the in-end systems in the DR endpoint; Step S104, the in-end system detects that an event has occurred, wherein the event An in-end system and/or a port for triggering the update of the bearer service; Step S106, the in-end system determines the service affected by the event; Step S108, the in-end system according to the in-end system sequence and/or port sequence carrying the service, And the status of the in-end system and/or the status of the port within the endpoint, updating the in-end system and/or port currently carrying the service. In this embodiment, through the foregoing steps, the in-end system in the endpoint of the DRNI aggregation group synchronizes the state of the in-end system of the endpoint (for example, the distribution enabled state) and/or the state of the port (for example, the distribution enabled state); After detecting an event that occurs to trigger an in-end system and/or port that updates the bearer service, the in-end system determines the service affected by the event and updates the in-end system and/or port currently carrying the service, thereby The situation that the other end systems and/or ports in the end of the aggregation group discard the service occurs when the aggregation link or the end system of the bearer service fails, and the related system generates the aggregate link or the end system. When the fault occurs, the traffic will be interrupted, the impact of the fault on the service is reduced, and the user experience is improved. As a preferred implementation manner, the synchronization manner of the states of the intra-end systems and/or the ports of the intra-end systems in the aggregation group endpoint may be a periodic relay control protocol between the intra-systems within the aggregation group endpoints ( The Distributed Relay Control Protocol (DRCP) advertises the status information of the ports to each other to achieve state synchronization between the systems in the end. The port status information sent by the system in the end can include the port status information of the system in the local end, and can also include the port status information of the system in other end systems. Preferably, the in-end system may carry the port state information of the in-end system itself and/or the port state information of the other in-end system in the manner of type, length, and value (Type, Length and Value, or simply TLV) in the DRCP. In the packet, it is sent to other end systems of the DRNI aggregation group endpoint. The state information of the port is carried in this synchronous packet format, which is simple and clear. Preferably, the status information of the port may be the distribution enable information of the aggregation port, or the Link Aggregation Control Protocol (LACP) status information of the aggregation port, or may be the aggregation enable of the aggregator. status information. In this way, when any of the above changes occurs in the state of the port, the bearer update of the service can be triggered, and the continuity of the service is further ensured. Preferably, the port state of the in-end system (for example, the distribution enable state of the aggregation port, the aggregation port

In the case where a change occurs in the LACP state, the aggregator's distribution enable state, etc., the in-terminal system to which the port whose state is changed is notified by DRCP to the other end systems of the aggregation group endpoint of the state of the port whose state has changed. In the case of synchronizing the status information of the port, all the status information may be synchronized, or only the changed status information may be synchronized. As a preferred implementation manner, the foregoing event for triggering an in-end system and/or port for updating a bearer service may be a change in state of an in-end system and/or port within the DRNI endpoint. For example, the in-end system of the endpoint (that is, the DRNI aggregation group endpoint) fails or recovers; the inline link of the end-end system of the endpoint fails or recovers; the end-end system of the endpoint is removed or joined. Aggregation group, the port of the end-end system of this endpoint fails or recovers; and the port of the end-end system of the endpoint is removed or added to the aggregation group. Preferably, the manner in which the in-end system determines the service affected by the event in step S106 may be that the system currently in the end system determines the service currently carried by the in-end system and/or port whose status is changed to be the service affected by the event. As an example, a method for determining that the port status of the system needs to be updated may be as follows: When the system in the end system detects that the port of the local system is unavailable, In the case of the in-band system to which the port is not available, the state of the port can be updated to be unavailable, and the port service table in the system of the port is obtained, and the service included in the port service table is determined to be affected by the event. Business to carry updates. Preferably, after the end system detects that the port of the system in the local end is unavailable, the in-end system to which the unavailable port belongs may also notify the other end systems in the end of the aggregation group that the port is unavailable; in this case, The other end systems can update the status of the locally saved port to be unavailable, and obtain the port service table of the unavailable port, and determine the service included in the port service table as the service affected by the event. Host an update. In this way, the correctness of the port service table of the port itself and the ports of other end systems can be guaranteed in all end systems in the aggregation group endpoint. As a preferred embodiment, the intra-end system in the end point of the aggregation group detects that the connection information of the system in the adjacent end point of the aggregation group endpoint is lost, and the end-end system that detects the loss of the connection information remains joined. In the case of an aggregation group, the in-end system that detects the loss of connection information can update the locally stored adjacent end system. The port status is unavailable, and the port service table of the unavailable port is obtained, and the service included in the port service table is determined as the service affected by the event to perform bearer update. As an example, when the in-end system detects that the port status of the system in the system is unavailable, the system detects that the port in the system is unavailable. The in-end system to which the available port belongs can update the status of the port to be available, and obtain the services of all the current bearer ports in the DRNI aggregation group endpoint that are not the first priority port; the in-end system compares the restored port with the current bearer. The port is not the location relationship of the current bearer port of the service of the first priority port in the intra-system sequence and/or port sequence carrying the service; if the restored port is in the priority position than the current bearer port of the service, The service is determined to be a business affected by the event for bearer updates. For example, taking the higher priority of the in-end system and/or port in the in-end system sequence and/or port sequence of the service, if the system sequence and/or port sequence is recovered in the end of the service, The location of the port is prior to the location of the current bearer port of the service, and the service can be determined as the service affected by the event. Preferably, after the end system detects that the port of the in-end system is restored from being unavailable to available, the in-end system to which the available port belongs may also notify the other end systems within the DRNI aggregation group that the port is restored to be available. In this case, the other in-end system can simultaneously update the state of the locally saved port to be available, and obtain the services of all the current bearer ports in the DRNI aggregation group endpoint that are not the first priority port; The location relationship between the recovered port and the current bearer port that is not the first priority port in the intra-system sequence and/or port sequence that carries the service; if the restored port is in the priority position than the current bearer port of the service, The service is determined to be the service affected by the event for bearer update. For example, taking the higher priority of the in-end system and/or port in the in-end system sequence and/or port sequence of the service, if the system sequence and/or port sequence is recovered in the end of the service, The location of the port is prior to the location of the current bearer port of the service, and the service can be determined as the service affected by the event. In this way, the correctness of the port service table of the port itself and the ports of other end systems can be guaranteed in all end systems in the aggregation group endpoint. In the above manner, when the state of the port in the endpoint of the aggregation group is detected to be changed, the affected service can be quickly and accurately determined, thereby ensuring traffic continuity of all services. As a preferred embodiment, the method for updating the in-end system and/or port that carries the affected service in step S108 may be as follows: Obtain a service port table of the service, and select according to the bearer priority order in the service port table. The port with the highest priority of the distribution enabled state and the port with the highest priority is used as the bearer port of the service. Then, the port service table of the bearer port is updated. The service port table is a port sequence table that can carry the service, and the port sequence in the table can be ranked according to the priority order of the bearer service. The port service table is a service that can be carried by the port. The port service table can also be used to obtain services affected by the fault when the port is faulty. Corresponding to the foregoing method, in this embodiment, a service bearer device for a distributed elastic network interconnection is further provided, which is located in any end-end system in the DRNI endpoint, and the device is used to implement the foregoing embodiment and the preferred embodiment. , already explained, no longer repeat them. As used hereinafter, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and conceivable. 2 is a structural block diagram of a service bearer of a distributed elastic network interconnection according to an embodiment of the present invention. As shown in FIG. 2, the device includes: a synchronization module 22, a detection module 24, and an update module 26, and the following modules Detailed instructions are given. The synchronization module 22 is configured to synchronize the state of the in-end system and/or the state of the port in the DR endpoint; the detecting module 24 is connected to the synchronization module 22, and is configured to detect that an event has occurred, wherein the event is used to trigger the update bearer The in-end system and/or port of the service; the update module 26, connected to the synchronization module 22 and the detection module 24, configured to be based on the in-end system sequence and/or port sequence of the bearer service, and the in-end system and/or within the endpoint Or the status of the port, updating the in-end system and/or port currently carrying the service. In this embodiment, through the above module, the in-end system in the endpoint of the DRNI aggregation group synchronizes the state of the in-end system of the endpoint and/or the state of the port through the synchronization module 22; the detection module 24 detects that an update is triggered to occur. After the event of the in-end system and/or port of the service is carried out, and the in-end system and/or port of the current bearer service is updated by the update module 26, thereby avoiding when the aggregated link or the end-end system of the bearer service fails. The other system and/or port in the end of the aggregation group discards the service. This solves the problem that traffic is interrupted when the aggregation link or the intra-system fails in the related technology, which reduces the impact of the fault on the service. Improved user experience. 3 is a block diagram of a preferred structure of the synchronization module 22 according to an embodiment of the present invention. As shown in FIG. 3, the synchronization module 22 may include: a first notification unit 222, configured to notify itself to other end systems of the aggregation group endpoint by using DRCP. The port state and/or the port state of the other in-end system; or the synchronization module 22 may further include: a second advertising unit 224 configured to aggregate by DRCP in a case where the state of the port of the system in the local end is changed The status of the port in the other end of the group endpoint where the system advertises a change in state. FIG. 4 is a block diagram of a preferred structure of the update module 26 according to an embodiment of the present invention. As shown in FIG. 4, the update module 26 may include: a determining module 262, configured to acquire a service affected by the fault, and an obtaining unit 264 configured to acquire a service. a service port table, where the service port table includes an in-end system sequence and/or a port sequence that carries the service; the selecting unit 266 is connected to the obtaining unit 264, and is configured to carry the service according to the service port table. The order of the in-system and/or port of the service, select the distribution enable state as the available and sequential in-end system and

The port is the current bearer system and/or port of the service; the first update unit 268 is connected to the selecting unit 266 and configured to update the port service table of the current bearer port of the service. FIG. 5 is a block diagram of a preferred structure of the determining module 262. As shown in FIG. 5, the determining module 262 may include: a second updating unit 26202, configured to detect that the port of the system in the local end is unavailable The status of the port that is not available is updated, and the port service table of the port that is not available is obtained. The first determining unit 26204 is connected to the second updating unit 26202, and is configured to determine the service included in the port service table as being subjected to The business affected by the incident. Preferably, the determining module 262 may further include: a first receiving unit 26206, connected to the second updating unit 26202, configured to receive an advertisement of other end systems in the aggregation group endpoint, where the notification is used to indicate other end systems The port is not available; in this case, the second update unit 26202 may also be configured to update the status of the port of the other end system to be unavailable, and obtain the port service table of the unavailable port; the first determining unit 26204 further Can be set to identify the services contained in the port business table as the business affected by the event. FIG. 6 is a block diagram of a preferred structure of the determining module 262 according to an embodiment of the present invention. As shown in FIG. 6, the determining module 262 may include: a third updating unit 26212, configured to detect adjacent ends in the endpoint of the aggregation group. After the connection information of the internal system is lost, and the system that detects the loss of the connection information remains in the aggregation group, the status of the port in the system in the adjacent terminal is updated, and the unavailable port is obtained. The second service unit 26214 is connected to the third update unit 26212, and is configured to determine the service included in the port service table as the service affected by the event. FIG. 7 is a block diagram 3 of a preferred structure of the determining module 262 according to an embodiment of the present invention. As shown in FIG. 7, the determining module 262 may further include: a fourth updating unit 26222, configured to detect that the port of the system in the local end is unavailable. After the recovery is available, the status of the port is updated. The priority detecting unit 26224 is connected to the fourth updating unit 26222, and is configured to detect that the current bearer port in the DRNI aggregation group endpoint is not the first priority port; the comparing unit 26226 And being connected to the priority detecting unit 26224, and configured to compare the positional relationship between the restored port and the current bearer port of the service whose current bearer port is not the first priority port in the intra-system sequence and/or port sequence that carries the service, and In case the recovered port is in a priority position than the current bearer port of the service, the service is determined to be a service affected by the event. Preferably, the determining module 262 may further include: a second receiving unit 26228, connected to the fourth updating unit 26222, configured to receive an advertisement of other end systems in the aggregation group endpoint, where the notification is used to indicate other end systems The port is available; in this case, the fourth updating unit 26222 may also be configured to update the state of the port of the other in-end system saved locally as available; the priority detecting unit 26224 may also be configured to detect the aggregation The current bearer port in the group endpoint is not the service of the first priority port; the comparing unit 26226 may also be configured to compare the recovered port with the current bearer port of the service whose current bearer port is not the first priority port in the end system system carrying the service And/or the location relationship in the port sequence, and in the case where the restored port is in a priority position than the current bearer port of the service, the service is determined to be a service affected by the event. The following description is made in conjunction with the preferred embodiments, which are combined with the above-described embodiments and preferred embodiments thereof. In the following preferred embodiments, in order to ensure that a fault occurs in the aggregation link or the end system, the intra-terminal system can negotiate a new aggregation link to implement fast service switching, thereby reducing the impact of the fault on the service. A protection scheme for interconnecting interfaces between networks in a communication system, in particular, a method and apparatus for negotiating service bearers in a DRNI. With this solution, when an aggregate link or an end system fails, traffic can be transmitted from other aggregated links. The newly selected aggregate link can be on the same end system as the faulty link, or it can be in the endpoint. The different end of the system. The scheme for negotiating the aggregated link in the DRNI includes: mutually informing the synchronization port state information between the intra-end systems in the endpoint of the aggregation group, updating the port service table and/or the current bearer port of the service according to the port state information and the service port table, and according to The service currently carries the port and/or port service table to send and receive services. The implementation scheme of the negotiated service bearer in the DRNI in the preferred embodiment includes the following steps: Step 1: The intra-end system uses the Distributed Relay Control Protocol (DRCP) to the other end systems of the endpoint. Notifies the status of the sync port. The port status information is carried in the DRCP protocol packet in the TLV mode, and the intra-terminal system synchronizes the port status. In addition, when the port status changes, it triggers the notification of the change of the port status to the other end systems, so that the port status between the end systems is synchronized. The port state TLV may carry information such as an aggregate port state, an aggregator state, and the like. The notification of the change of the status of the aggregation port can be: When the distribution enable status of the aggregation port changes, the advertisement is triggered. The LACP status of the aggregation port may be changed, and the advertisement is triggered. The change of the aggregator status triggers the advertisement: When the aggregation enable status of the aggregator changes, the advertisement is triggered. Step 2: The in-end system obtains the port service table of each port and/or the current bearer port table of the service according to the service port table and the synchronized port state information. The service port table is a port sequence table of the bearer service, and the port sequence is sorted according to the priority order of the bearer service. The port service table is a service that can be carried by the port, and can be used to obtain a service affected by the fault when the port is faulty; The current bearer port of the service is the currently available high-priority port obtained from the service port table, including the port number and the priority of the bearer service. The priority of the bearer service is used to determine whether the current bearer port of the service needs to be updated by comparing the current bearer port of the service with the bearer priority of the service port. Step 3: When a port on the system is unavailable, you need to update the port service table saved by the system and/or the current bearer port of the service according to the port status information. 8 is a processing flowchart of a system in an end where an aggregation link is faulty according to the first embodiment of the present invention. As shown in FIG. 8, when a port on the system in the end system is unavailable, the processing procedure of step 3 is as follows: Step S802 When a port on the system is unavailable, the port status is updated, and the unavailable status information of the port is advertised to other end systems in the endpoint. Step S804: Acquire an affected service from the saved port service table of the unavailable port. Step S806: Retrieve the service port table of the affected service, and obtain the next available high-priority port as the bearer port of the service, and update the port service table and/or the current bearer port of the service stored in the system. 9 is a flowchart of processing of an in-band system in which an aggregate link is faulty according to the first embodiment of the present invention. As shown in FIG. 9, when the in-end system receives port unavailability information advertised by other end systems, step 3 The process is as follows: Step S902: After receiving the status notification information that the port status becomes unavailable, the system in the end system updates the status of the port saved on the system in the local end to be unavailable. Step S904: Acquire an affected service from the saved port service table of the unavailable port. If there is a service affected by the failure, it proceeds to step S906. Step S906: Retrieve the service port table of the affected service, obtain the next available high-priority port as the bearer port of the service, and update the port service table and/or the current bearer port of the service saved in the system. Step 4 is a flow chart of the fault processing of the in-end system according to the first embodiment of the present invention. When the system in the end detects the loss of system connection information in the adjacent end, such as a system fault in the adjacent end and an inline link failure. If the system in the adjacent end system is removed from the aggregation group and the system in the local end remains in the aggregation group, the processing of the system in the local end is as shown in Figure 10. In step S1002, updating the status of the port on the system stored in the local end and the system in the unavailable end is unavailable. In step S1004, the service affected by the fault is obtained from the saved port service table of the unavailable port. If there is a service affected by the failure, it proceeds to step S1006. Step S1006: Retrieve the service port table of the affected service, obtain the next available high-priority port as the bearer port of the service, and update the port service table and/or the current bearer port of the service saved in the system. Step 5: When a port on the system in the terminal is restored to the available state and is in the return mode, the port service table saved by the system in the terminal and/or the current bearer port of the service need to be updated according to the port state information. 11 is a flowchart of processing of an intra-end system in which an aggregate link fault recovery is performed according to the first embodiment of the present invention. As shown in FIG. 11, the process is as follows: Step S1102: When a port on the system in the end system is restored to be available, The available status information for the port is advertised to other end systems within the endpoint. Step S1104: Retrieve the current bearer port of the service of all services, and obtain the service that the current bearer port is not the first priority port. In step S1106, the bearer priority of the service is compared between the recovery port and the current bearer port of the service. If the bearer priority of the recovery port is high, the process proceeds to step S1108. Otherwise, the process proceeds to step S1110. Step S1108: The update recovery port is a service bearer port, and the port service table and/or the current bearer port of the service saved on the system in the update end. In step S1110, no processing is required, and the current bearer port is kept unchanged. FIG. 12 is a flowchart of processing of an aggregation link failure recovery other end system according to the first embodiment of the present invention. As shown in FIG. 12, when the end system receives the port notified by the other end system, the process becomes available. The process is as follows: Step S1202: After receiving the status notification information that the port status becomes available, the in-end system updates the status of the port saved on the system in the local end to be available. Step S1204: Retrieve the current bearer port of the service of all services, and obtain the service that the current bearer port is not the first priority port. Step S1206 compares the bearer priority between the recovery port and the current bearer port of the service to the service. If the bearer priority of the recovery port is high, the process proceeds to step S1208. Otherwise, the process proceeds to step S1210. In step S1208, the update recovery port is a service bearer port, and the port service table and/or the current service port of the service saved on the system in the update terminal are updated. In step S1210, no processing is required, and the current bearer port is kept unchanged. In the preferred embodiment, a device for implementing a negotiated service bearer in the DRNI is provided. FIG. 13 is a structural block diagram of an apparatus for negotiating a service bearer in the DRNI according to the first embodiment of the present invention. As shown in FIG. The control message transceiving unit 1302, the detecting unit 1304, the updating unit 1306, and the service message transceiving unit 1308 are included to complete the above functions. The control packet transceiver unit 1302 (implementing the function of the synchronization module 22) is configured to receive and transmit a status notification message and a status synchronization message with other end systems, and encapsulate and decapsulate the message. The detecting unit 1304 (implementing the function of the determining module 24 described above) is configured to detect the port state and the system state in the adjacent end. The updating unit 1306 (implementing the function of the updating module 26) is configured to update the current bearer port and the port service table of the service according to the port state information and the saved service port table information. The method is configured to update the saved port state information according to the state information received by the transceiver unit and the state information detected by the detecting unit. The service packet sending and receiving unit 1308 is configured to send and receive service packets according to the port service table and/or the current bearer port of the service. The port may be a physical port or a logical port. The above service refers to a taggable data stream or session, which can be marked with an Ethernet VLAN ID virtual local area network identifier, an I-SID (Backbone Service Instance Identifier) or a session ID, and the like. According to the method for negotiating service bearers in the DRNI provided in the preferred embodiment, when the aggregated link or the end system fails, the aggregated port service table and/or the aggregate is dynamically updated according to the synchronized port state information between the intra-end systems. The service table enables the service affected by the fault to be transmitted from other aggregated links of the system in the end of the faulty link or from the aggregated link of the other end systems to reduce the impact of the fault on the service. The method for negotiating service bearers in the DRNI in the preferred embodiment will be described in more detail below with reference to other embodiments and the accompanying drawings. Embodiment 2 In the preferred embodiment, the port that is negotiated and updated between the end systems of the DRNI-end is taken as an example. 14 is a schematic diagram of networking in accordance with Embodiment 2 of the present invention. As shown in FIG. 14, two ends of an aggregation group are respectively composed of one endpoint, and each endpoint is composed of two end systems, wherein the endpoint 1 is terminated. The internal systems A and B are composed, and the end point 2 is composed of the in-end systems C and D. Link 1, link 2, link 3, and link 4 between endpoint 1 and endpoint 2 are aggregated into a distributed LAG. The following describes the information interaction and service forwarding of the system in each end of the endpoint 1. The system in each end of the endpoint 2 is processed in the same manner as the endpoint 1. In the first step, the intra-systems A and B in the endpoint 1 are configured to obtain a global service port table. Table 1 is a service port table of the endpoint 1 according to the second embodiment of the present invention. As shown in Table 1, the service port table indicates The port priority of the bearer service. Table 1

Step 2: The intra-end system and B periodically synchronize the port status information through the DRCP protocol, and the port status information is carried in the DRCP protocol in TLV mode. A feasible port state TLV format is as follows:

 Status message type lByte

 Status message length 2Byte

 Port status information Variable length In the example, the port status information field can carry information such as the aggregator status sub-TLV and aggregation port status sub-TLV. A feasible aggregator state sub-TLV is as follows:

Here, the aggregator identifier is an optional field, and the aggregator state is the aggregator state on the in-end system specified by the in-end system identifier, and there are two states of available and unavailable. - A feasible aggregation port state sub-TLV is as follows:

 The status of the aggregation port is the LACP status of the aggregation port. If the LACP status is distributed, the aggregation port is available. Otherwise, it is unavailable. In addition, in addition to the periodic synchronization, when the status of the port changes, the status of the advertised port is triggered, and the status of the changed port is carried in the port status TLV advertised to the other end system. For example, if the state of the aggregation port 1 changes and the state of the aggregation port 2 does not change, the state information of the aggregation port 1 is carried in the aggregation port state TLV only, and the state information of the aggregation port 2 is not carried. The state of the in-end system aggregation port 1 changes. Step 3: After the aggregation status of the system and the B are synchronized, obtain the available high-priority ports from the service port table (Table 1) according to the status of the aggregation port to form the port service table and the current bearer port of the service. For example, port 1, port 2, port 3, and port 4 are both added to the aggregation group and the ports are available. Then, according to Table 1, the current bearer port of the service is generated. Table 2 is the current bearer port table of the service according to Embodiment 2 of the present invention. As shown in Table 2, the current bearer port of the service is as follows: Table 2

 Table 3 is a port service table according to Embodiment 2 of the present invention, that is, a service that is sent and received through the port, as shown in Table 3, the service sequence corresponding to the port is as follows: Table 3

Port number of the system port in the end of the port number port Port 1 end system A 001, 005

 Port 2 end system A 002, 006

 Port 3 end system B 003

In the port 4 end, the system B 004 is in the fourth step. According to the aggregation port service table of the endpoint, the aggregator service table of each end system can be formed, and the service information sent and received by the aggregator of the local end system can be formed. Table 4 is According to the aggregator service table of the second embodiment of the present invention, as shown in Table 4, the aggregator service is as follows: Table 4

 The process of forming an aggregator business table for each end system is optional. If the forwarding table needs to be formed by the aggregator service table of each end system, the aggregator service table of each end system is obtained through the process. For example, for the three intra-end systems and the above-mentioned aggregation groups, the service can be forwarded according to the system aggregator service table in each end, or the flooded service can be filtered to prevent loops. Step 5 is a schematic diagram of the fault of the aggregated link according to the second embodiment of the present invention. As shown in FIG. 15, when the link 1 is faulty, the state of the port 1 of the system A in the terminal indicates that the port is unavailable, and the port state advertisement is triggered. The port state TLV advertised in the DRCP protocol carries the state of the port 1 and advertises that the port is unavailable. Inbound system B receives the status of aggregation port 1 advertised by system A in the end becomes unavailable, and updates the status of aggregation port 1 saved on the system in the local end to unavailable. The in-end system A and B look up the service table of port 1 (Table 3), and obtain the service affected by port 1 fault as "001, 005". Then, look up the service port table of "001, 005" (Table 1), obtain the currently available high-priority ports for ports 2, 3, update the current bearer port of the service (Table 5), and update the port services of ports 2 and 3. Table (Table 6) and aggregator business tables for each end system (Table 7). In the tables below, the bolded portion and the part with the strikethrough are modified. Table 5 is a current bearer port table of the service according to the second embodiment of the present invention;

004 端口 4 1 端内系统 B

004 port 4 1 end system B

005 port 3 2 end system B

 006 Port 2 1 In-end system A Table 6 is a service table of ports according to an embodiment of the present invention; Table 6

Table 7 is an aggregator service table according to Embodiment 2 of the present invention. Table 7

 Step 6: The current bearer port and port service table of the port, and the aggregator service table of the system in each end is updated, the system A receives the service 001 from the network side, and determines the current bearer port of the service 001 on the system from Table 5. Port 2, sent from port 2 of this system. The in-end system A receives the service 005 from the network side, and determines from Table 5 that the current bearer port of the service is the port 3 on the in-end system B, so the service 005 is forwarded from the intralink to the end system through the internal connection port. B, sent by port 3 of system B in the end. When the service is guaranteed to be in the same direction, the service received from the aggregation port determines whether the service is in the service table of the receiving port, or whether the current bearer port of the service is the receiving interface. If so, the service is received and forwarded. Otherwise, discard. Step 7: The link 1 connected to the port 1 on the system A in the terminal is restored, and the port status update and the advertisement are triggered. The status of the aggregation port 1 is carried in the status TLV message advertised by the DRCP protocol, and the aggregation port is advertised to the system B in the end. Available. The process is the same as above. After the end system B receives the status of the aggregation port 1 advertised by the system A, the status of the aggregation port saved by the system in the local end is available. The in-end system and B perform the return processing. The service whose current bearer port priority is not the first priority port (such as the service "001, 005" in Table 5) determines whether the current port priority of the service is greater than the recovery link. The priority of the bearer service is high. Because the priority of port 1 carrying service "001, 005" is higher than that of ports 2 and 3, the service is updated.

The current bearer port of "001, 005" is port 1 (same as Table 2 after update), triggering the port of updating port 1, 2, 3 The business table (same as Table 3 after the update), and the information of the aggregator service table of the saved system in each end is updated at the same time (the same as Table 4 after the update). Embodiment 3 In the preferred embodiment, a port that is negotiated and updated between the DRNI-end end systems is taken as an example. FIG. 16 is a schematic diagram of an in-end system failure according to Embodiment 3 of the present invention. As shown in FIG. 16, on the basis of Embodiment 2, when a fault occurs in the end system, the processing procedure is as follows: When the end system A fails, the end is within System B detects that the connection information of System A in the end is lost, and System B remains in the aggregation group. In-end system B obtains the service affected by the fault as "001, 002, 005, 006" from the port service table of system A in the saved end (such as Table 3) or the aggregator service table (such as Table 4). At the same time, the aggregator and port status information of system A in the terminal is updated, and the aggregator and port status of system A in the terminal are unavailable. The service port table of the service "001, 002, 005, 006" (such as Table 1) is retrieved, and the currently available high-priority port of the service "001, 002, 005, 006" is obtained as the current bearer of the service. Port, update the current bearer port of service "001, 002, 005, 006" (refer to Table 8), trigger the service table of update port 3, 4 (such as Table 9), and update the aggregator service table of the system in each end ( As shown in Table 10). Table 8 is a current bearer port table of a service according to Embodiment 3 of the present invention;

 Table 9 is a port service table according to Embodiment 3 of the present invention;

表 10是根据本发明实施例三的聚合器业务表。 表 10

Table 10 is an aggregator business table according to Embodiment 3 of the present invention. Table 10

 After the current bearer port and the service table of each port are updated, the system B receives the service from the network side, and determines that the service is sent in the aggregator service table of the local system. The service received from the aggregation port determines whether the service is in the service table of the local port, or the current bearer port of the service is the port that receives the packet, and then receives and forwards the service. If the internal link between the systems A and B in the end fails, the system A in the end removes from the aggregation group, and the system A in the end stops forwarding the services of the aggregation group. Embodiment 4 In the preferred embodiment, a port that is negotiated and updated between the end systems of the DRNI-end is taken as a logical port as an example. FIG. 17 is a schematic diagram of networking in accordance with Embodiment 4 of the present invention. As shown in FIG. 17, the endpoints at both ends of the aggregation group are respectively composed of two end systems, wherein the endpoint 1 is composed of end systems A and B, and the endpoint 2 is composed of End system C, D. The link between endpoint 1 and endpoint 2 1. Link 2, link 3, link 4 aggregate component LAG. Ports 1 and 2 are added to the aggregator Aggl of the system A in the end. The port seen by the aggregator client layer is the logical port Aggl (as shown in Figure 17), and the ports 3 and 4 are added to the aggregator Agg2 of the system B in the end. The port seen by the aggregator client layer is the logical port Agg2 (as shown in Figure 17). The following describes the information interaction and service forwarding of the system in each end of the endpoint 1, and the system in each end of the endpoint 2 is processed in the same manner as the endpoint 1. In the first step, the in-end system A and B in the endpoint 1 are configured to negotiate a global service port table. Table 11 is a service port table (port is an aggregator) of the endpoint 1 according to the fourth embodiment of the present invention, as shown in Table 11. The service port table indicates the port priority order of the bearer service, and the port in the table is an aggregator on the system in each end. Table 11

步骤二， 端内系统 、 B通过 DRCP协议周期同步端口状态信息， 报文格式同实 施例一。 进行周期同步时， 在端口状态 TLV中携带聚合器状态 sub-TLV， 可选择携带 聚合端口状态 sub-TLV。 另外， 除周期同步外， 在聚合器状态发生改变时， 触发通告聚合器状态的变化情 况， 在向其他端内系统通告的端口状态 TLV中携带发生变化的聚合器状态。 如， 聚合 器 Aggl状态发生变化， 则在端口状态 TLV中携带聚合器 Aggl的状态信息， 来通知 其他端内系统聚合器 Aggl的状态发生变化。 步骤三， 端内系统 、 B的聚合状态同步后， 根据聚合器状态， 从业务端口表获 取可用的高优先级端口， 形成端口业务表、业务当前承载端口， 这里的端口为聚合器。 如： 端口 1， 端口 2， 端口 3， 端口 4， 都已加入聚合组， 且端口可用， 相应的聚合器 Agg Agg2可用。 表 12是根据表 11的业务聚合器端口表和聚合器状态所生成的端点 1的业务当前 承载端口表， 这里的承载端口为聚合器， 端内系统 、 B都可以保存有这张表。 表 12

Step 2: The intra-end system and B synchronize the port status information by using the DRCP protocol periodically. The packet format is the same as that in the first embodiment. When the period synchronization is performed, the aggregator state sub-TLV is carried in the port state TLV, and the aggregation port state sub-TLV may be optionally carried. In addition, in addition to the periodic synchronization, when the state of the aggregator changes, the change of the state of the aggregator is triggered, and the state of the aggregator that changes is carried in the port state TLV advertised to the system in the other end. For example, if the Aggl state of the aggregator changes, the state information of the aggregator Aggl is carried in the port state TLV to notify the state of the system aggregator Aggl in the other end. Step 3: After the aggregation state of the system and the B are synchronized, the available high-priority port is obtained from the service port table according to the state of the aggregator, and the port service table and the current bearer port of the service are formed, where the port is an aggregator. For example, port 1, port 2, port 3, and port 4 are both added to the aggregation group, and the port is available. The corresponding aggregator Agg Agg2 is available. Table 12 is a service current bearer port table of the endpoint 1 generated according to the service aggregator port table and the aggregator state of Table 11, where the bearer port is an aggregator, and the end system and B can both store this table. Table 12

 Table 13 is a port service table of the endpoint 1 according to the fourth embodiment of the present invention, that is, a service sent and received through the port, where the port is a logical port, that is, an aggregator, and the end system of the endpoint 1 stores the table. , as follows

Table 13

After receiving the service, the in-end system forwards the service according to the current bearer port of the service. For example, the in-end system B receives the service "004, 005, 006", and retrieves the current bearer port table (Table 12) of the service to determine that the bearer port of the service "004, 005, 006" is the aggregator Agg2 on the system, and further The aggregator Agg2 is responsible for distributing the service "004, 005, 006" to the aggregation link of the local system. Embodiment 5 FIG. 18 is a schematic diagram showing that a logical port is unavailable according to Embodiment 5 of the present invention. As shown in FIG. 18, on the basis of Embodiment 4, when ports 3 and 4 are unavailable, the aggregator of the system B in the end is included. There is no available aggregation port, so the aggregator status of the system B becomes unavailable. The port status advertisement is triggered. The port status TLV advertised in the DRCP protocol carries the aggregator Agg2 status, and the port is notified that the port becomes unavailable. In the advertised port status TLV, information that the port status of the aggregation port 3, 4 is changed to be unavailable may be selected. The status of the aggregator Agg2, which is notified by the system B in the end, is not available, and the status of the aggregator Agg2 saved on the system in the local end is not available. The in-end system and B find the port service table (Table 13) saved on the system, and obtain the service affected by the aggregator Agg2 failure as "004, 005, 006". Then, find the service aggregator port table of "004, 005, 006" (Table 11), obtain the currently available high priority port as the aggregator Aggl, update the current bearer port of the service (Table 14), and update the Aggregator Aggl, Agg2. Port business table (Table 15). In the tables below, the bolded portion and the portion with the strikethrough are modified. Table 14 is a service current bearer port table (port is an aggregator) according to Embodiment 5 of the present invention;

 Table 15 is a port service table (port is an aggregator) according to Embodiment 5 of the present invention; Table 15

After the port carrying the service is updated, the in-end system on the endpoint forwards the service according to the updated information. For example, in-end system B receives the service "004, 005, 006", and retrieves the current bearer port of the service (Table 14). The bearer port of the service "004, 005, 006" is the aggregator Aggl on the system A in the end, so the service is sent to the end system. The in-end system A receives the service "004, 005, 006", and determines that the bearer port of the service "004, 005, 006" is the aggregator Aggl on the system, and the aggregator Aggl of the local system is responsible for distributing the service to On the aggregated link. The process available for aggregator recovery is similar to the aggregation port recovery available in the previous embodiment, and is no longer burdensome. In another embodiment, software is also provided for performing the technical solutions described in the above embodiments and preferred embodiments. In another embodiment, a storage medium is also provided, the software being stored, including but not limited to an optical disk, a floppy disk, a hard disk, a rewritable memory, and the like. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention. Industrial Applicability: The present invention relates to the field of communications, and provides a service bearer method and device for a distributed elastic network interconnection, which solves the problem that traffic interruption occurs when an aggregate link or an end system fails in the related art, and reduces The impact of the failure on the business has improved the user experience.

Claims

 Claims A distributed elastic network interconnection DRNI service bearer method, including:  Synchronizing the state of the in-end system of the endpoint and/or the state of the port between the in-end systems within the DRNI endpoint;  The in-end system detects that an event has occurred, wherein the event is used to trigger an in-end system and/or port that updates the bearer service;  The in-end system updates the in-end system and/or end of the current bearer service according to the in-end system sequence and/or port sequence of the bearer service, and the state of the in-end system and/or the state of the port in the endpoint. Hey. 2. The method according to claim 1, wherein the state of the in-end system and/or the state of the port that synchronizes the end point between the end systems within the DRNI endpoint includes:  The intra-end system in the DRNI endpoint periodically advertises its own port status and/or the port status of other end systems through the distributed relay control protocol DRCP to achieve state synchronization between the end systems. 3. The method according to claim 2, wherein the period between the end systems to advertise each other's port status through DRCP and/or the port status of other end systems includes:  The in-end system carries its own port state information and/or port state information of other in-end systems in the DRCP packet in the type, length, and assignment TLV mode, and sends the same to the other end systems of the DRNI endpoint. . The method according to claim 3, wherein the port status information comprises at least one of: distribution enable status information of the aggregation port, LACP status information of the aggregation port, and distribution enable status information of the aggregator. 5. The method of claim 1, wherein synchronizing the state of the in-end system and/or port of the end point between the in-end systems within the DRNI endpoint further comprises: In the case where the port state of the end system is changed, the in-end system to which the port whose state is changed belongs to the other in-end system of the DRNI endpoint by the DRCP to notify the state of the changed state of the port. The method of claim 1, wherein the event comprises: a change in state of an in-end system and/or port of the endpoint. The method of claim 6, wherein the change in state of the in-end system and/or port of the endpoint includes one of the following:  The end of the system of this endpoint fails or recovers from failure;  The internal link of the end-end system of the endpoint fails or recovers from the fault;  The in-end system of the endpoint is removed or added to the aggregation group;  The port of the end-end system of this endpoint fails or recovers; and  The port of the in-end system of this endpoint is removed or added to the aggregation group. The method according to claim 1, wherein the in-end system updates the current system according to an in-end system sequence and/or a port sequence of the bearer service, and a state of the in-end system and/or a state of the port in the endpoint. The in-end system and/or port carrying the service includes:  The in-end system determines the business affected by the event. The method according to claim 1, wherein the in-end system determines that the service affected by the event comprises:  The in-end system determines the traffic currently carried by the in-end system and/or port whose state has changed, as the service affected by the event. The method according to claim 9, wherein the in-end system determines that the service currently carried by the in-end system and/or the port whose state has changed is the service affected by the event, including:  The in-end system in the DRNI endpoint detects that the port of the in-end system is unavailable; the in-band system to which the unavailable port belongs updates the state of the port as unavailable, and obtains the port service of the unavailable port. Table  The service included in the port service table is determined to be a service affected by the event. The method according to claim 10, wherein after the end system detects that the port of the system in the local end is unavailable, the method further includes: The in-end system to which the unavailable port belongs notifies the other end systems in the endpoint that the port is unavailable; The other in-end system updates the state of the locally saved port to be unavailable, and acquires a port service table of the unavailable port;  The service included in the port service table is determined to be a service affected by the event. The method according to claim 9, wherein the determining, by the in-end system, the service currently carried by the in-end system and/or the port whose status is changed to be affected by the event includes:  The in-end system in the DRNI endpoint detects that the connection information with the neighboring intra-system in the endpoint is lost, and the in-end system that detects the loss of the connection information remains in the aggregation group;  And detecting, by the in-end system that the connection information is lost, the locally saved port state of the neighboring end system is unavailable, and acquiring the port service table of the unavailable port;  The service included in the port service table is determined to be a service affected by the event. The method according to claim 9, wherein the in-end system determines the service currently carried by the in-end system and/or the port whose status is changed to be affected by the event, including:  The in-end system in the DRNI endpoint detects that the port of the system in the local end is restored to be usable by being unavailable;  The recovery is that the status of the port in the in-end system to which the available port belongs is available, and the service in which the current bearer port is not the first priority port in the DRNI endpoint is obtained;  Recovering to the in-end system to which the available port belongs compares the positional relationship between the reverting the available port and the current bearer port of the service in the intra-system sequence and/or port sequence carrying the service; In the case where the available port is in a preferred position than the current bearer port of the service, the service is determined to be a service affected by the event. The method according to claim 13, wherein after the end system detects that the port of the local end system is restored from being unavailable to available, the method further includes:  The in-end system to which the recovery is an available port advertises that the port is available to other end systems within the DRNI endpoint;  The other end-end system updates the state of the locally saved port to be available, and obtains a service in which the current bearer port in the DRNI endpoint is not the first priority port; The other in-end system compares the positional relationship between the reverting to an available port and the service in the in-end system sequence and/or port sequence carrying the service; The service is determined to be a service affected by the event if the recovery is that the available port is in a preferred position than the current bearer port of the service. The method according to any one of claims 1 to 14, wherein the in-end system is based on an in-end system sequence and/or a port sequence carrying a service, and a status and state of an in-end system within the endpoint / or the status of the port, the system and/or port that updates the current bearer service includes:  Obtaining a service port table of the service, where the service port table includes an intra-end system sequence and/or a port sequence that carries the service;  Determining, according to the sequence of the intra-system sequence and/or the port sequence carrying the service in the service port table, the end-end system and/or port whose status is available as the current bearer of the service In-end system and/or port;  Update the port service table of the current bearer port of the service. A distributed elastic network interconnection DRNI service bearer, located in the end system of the DRNI endpoint, includes:  a synchronization module, configured to synchronize the state of the in-end system and/or the state of the port in the DRNI endpoint; the detecting module is configured to detect that an event has occurred, wherein the event is used to trigger an in-end system that updates the bearer service and/or Or port;  The update module is configured to update the in-end system and/or port of the currently carried service according to the in-end system sequence and/or port sequence of the bearer service and the status of the in-end system and/or port within the endpoint. The device according to claim 16, wherein the synchronization module comprises:  The first advertising unit is configured to notify each other of the port status and/or the port status of the other end systems through the distributed relay control protocol DRCP. 18. The device according to claim 16, wherein the synchronization module comprises:  The second advertising unit is configured to notify, by the DRCP, to the other end systems of the DRNI endpoint that the state of the port changes state, in the case that the port state of the system in the end is changed. The apparatus according to any one of claims 15 to 18, wherein the update module comprises: a determining module configured to determine a service affected by the event; An obtaining unit, configured to obtain a service port table of the service, where the service port table includes an in-end system sequence and/or a port sequence that carries the service; a selecting unit, configured to select, according to an order of the in-end system and/or port carrying the service in the service port table, the in-end system and/or port in the sequence as the The current bearer system and/or port of the service;  The first update unit is configured to update a port service table of a current bearer port of the service. The device according to any one of claims 16 to 19, wherein the determining module comprises:  a second update unit, configured to: after detecting that the port of the system in the local end is unavailable, update the status of the unavailable port to be unavailable, and obtain a port service table of the unavailable port;  The first determining unit is configured to determine the service included in the port service table as a service affected by the event. The device according to claim 20, wherein the determining module further comprises:  a first receiving unit, configured to receive an advertisement of another end-end system in the DRNI endpoint, where the notification is used to indicate that a port of the other end-end system is unavailable;  The second update unit is further configured to: update the saved state of the port of the other end-end system to be unavailable, and obtain a port service table of the unavailable port;  The first determining unit is further configured to determine, according to the service included in the port service table, a service that is affected by the event. The apparatus according to any one of claims 16 to 19, wherein the determining module comprises: a third updating unit, configured to detect a system with an adjacent end within the DRNI endpoint After the connection information is lost, and the in-end system that detects the loss of the connection information remains in the aggregation group, the port state of the system in the adjacent end system that is saved and saved is not available, and the unavailable port is obtained. Port business table;  And a second determining unit, configured to determine, by the service included in the port service table, a service that is affected by the event. The device according to any one of claims 16 to 19, wherein the determining module further comprises: a fourth updating unit, configured to: when detecting that the port of the system in the local end is restored from unavailable to available After that, the status of the updated port is available; a priority detecting unit, configured to detect a service in which the current bearer port in the DRNI endpoint is not the first priority port; a comparing unit, configured to compare a positional relationship between the available port and the current bearer port of the service in an in-end system sequence and/or a port sequence that carries the service, and restore the available port ratio to the available port ratio If the current bearer port of the service is in the priority position, the service is determined to be a service affected by the event. The device according to claim 21, wherein the determining module further comprises:  a second receiving unit, configured to receive an advertisement of another end-end system in the DRNI endpoint, where the notification is used to indicate that a port of the other end-end system is available;  The fourth update unit is further configured to update the saved state of the port of the other end-end system to be available;  The priority detecting unit is further configured to detect that the current bearer port in the DRNI endpoint is not the first priority port;  The comparing unit is further configured to compare the location relationship between the available port and the current bearer port of the service in an in-end system sequence and/or port sequence that carries the service, and restore the available port to the available port. In the case where the current bearer port of the service is in a priority position, the service is determined to be a service affected by the event.