[go: up one dir, main page]

WO2014090083A1 - 分布式弹性网络互连的业务承载方法及装置 - Google Patents

分布式弹性网络互连的业务承载方法及装置 Download PDF

Info

Publication number
WO2014090083A1
WO2014090083A1 PCT/CN2013/087863 CN2013087863W WO2014090083A1 WO 2014090083 A1 WO2014090083 A1 WO 2014090083A1 CN 2013087863 W CN2013087863 W CN 2013087863W WO 2014090083 A1 WO2014090083 A1 WO 2014090083A1
Authority
WO
WIPO (PCT)
Prior art keywords
port
service
end system
endpoint
state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2013/087863
Other languages
English (en)
French (fr)
Inventor
许雪琼
喻敬海
敖婷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of WO2014090083A1 publication Critical patent/WO2014090083A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/41—Flow control; Congestion control by acting on aggregated flows or links
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Definitions

  • 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).
  • DRNI Resilient Network Interconnect
  • 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.
  • 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 distributed Resilient Network
  • the 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.
  • LAG Link Aggregation Group
  • 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.
  • NI network node interface
  • 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.
  • the service needs to be switched to other ports or other end systems to send.
  • 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.
  • the traffic is interrupted, and an effective solution has not been proposed yet.
  • 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.
  • a DRNI service bearer method 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the event comprises: a change in state of an in-end system and/or port of the endpoint.
  • 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.
  • 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a DRNI service bearer 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 bear
  • 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.
  • 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.
  • FIG. 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
  • 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.
  • FIG. 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • LACP Link Aggregation Control Protocol
  • the bearer update of the service can be triggered, and the continuity of the service is further ensured.
  • the port state of the in-end system for example, the distribution enable state of the aggregation port, the aggregation port
  • 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.
  • all the status information may be synchronized, or only the changed status information may be synchronized.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 service is determined to be the service affected by the event for bearer update.
  • the system sequence and/or port sequence is recovered in the end 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.
  • 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.
  • 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.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • 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.
  • 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 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.
  • FIG. 3 is a block diagram of a preferred structure of the synchronization module 22 according to an embodiment of the present invention.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a second receiving unit 26228, connected to the fourth updating unit 26222 configured to receive an advertisement of other end systems in
  • the intra-terminal system in order to ensure that a fault occurs in the aggregation link or the end 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.
  • 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.
  • DRCP Distributed Relay Control Protocol
  • the port status information is carried in the DRCP protocol packet in the TLV mode, and the intra-terminal system synchronizes the port status.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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:
  • the aggregator identifier is an optional field
  • 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.
  • 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
  • the system B 004 is in the fourth step.
  • the aggregator 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
  • 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 5 is a current bearer port table of the service according to the second embodiment of the present invention.
  • Table 6 is a service table of ports according to an embodiment of the present invention.
  • 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.
  • 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.
  • the end system B 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.
  • FIG. 16 is a schematic diagram of an in-end system failure according to Embodiment 3 of the present invention. As shown in FIG.
  • 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.
  • Table 10 is an aggregator business table according to Embodiment 3 of the present invention. Table 10
  • 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.
  • FIG. 17 is a schematic diagram of networking in accordance with Embodiment 4 of the present invention.
  • 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.
  • 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.
  • 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.
  • 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.
  • the aggregator state sub-TLV is carried in the port state TLV, and the aggregation port state sub-TLV may be optionally carried.
  • 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.
  • 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 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
  • the in-end system After receiving the service, the in-end system forwards the service according to the current bearer port of the service.
  • 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.
  • 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.
  • the in-end system on the endpoint forwards the service according to the updated information.
  • 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.
  • software is also provided for performing the technical solutions described in the above embodiments and preferred embodiments.
  • 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.
  • the computing device 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明公开了一种分布式弹性网络互连的业务承载方法及装置，其中，该方法包括：DRNI端点内的端内系统之间同步该端点的端内系统的状态和/或端口的状态；端内系统检测到发生了事件，其中，该事件用于触发更新承载业务的端内系统和/或端口；端内系统根据承载业务的端内系统序列和/或端口序列，以及该端点内的端内系统的状态和/或端口的状态，更新当前承载业务的端内系统和/或端口。通过本发明，解决了相关技术中聚合链路或端内系统发生故障时会导致流量中断的问题，降低了故障对业务的影响，提升了用户体验。

Description

分布式弹性网络互连的业务承载方法及装置 技术领域 本发明涉及通信领域， 具体而言， 涉及一种分布式弹性网络互连 （Distributed Resilient Network Interconnect, 简称为 DRNI) 的业务承载方法及装置。 背景技术 随着宽带业务的飞速发展， 网络与网络之间的互连使用得越来越多， 承载了更多 的业务。 网络内部根据其所采用的技术， 均可有多种方法对链路， 及节点实现保护。 随着对流量的保护需求越来越强烈， 要求越来越高， 有运营商也提出了需要对网络互 连区域的保护需求。 可以采用端口聚合的方式来实现该保护， 常用的方式可以是端口 聚合， 也可以是环路保护。 环网保护技术受到网络拓扑的限制， 对于网络互连部分采 用全网连接的方式不适用。 在 IEEE现有标准 802.1AX-链路聚合能够实现多条链路的 保护， 但仅限于支持的是单节点的链路聚合， 不能满足节点保护的需求。 为了适用于网络与网络互连区域组网方式更加多样化， 并能实现链路和边缘节点 的保护， IEEE 标准组织提出扩展 802.1AX-链路聚合来实现分布式弹性网络互连 (Distributed Resilient Network Interconnect,简称为 DRNI)，以支持多系统的链路聚合。
DRNI对 802.1AX进行扩展， 使链路聚合组的两端可以由一个或多个端内系统组成一 个逻辑端点进行聚合，即由这些端内系统的多条链路组成一个分布式链路聚合组（Link Aggregation Group, 简称为 LAG)， 从而保证网络互连区域的链路和节点双重保护。 目前， DRNI 采用按业务报文分发方式， 端内系统接收到报文， 根据业务报文的 最外层标签的映射值， 如会话 ID， 对业务报文进行转发。 端内系统接收到要发往本网 络内部的报文， 或要通过本端内系统的聚合链路发往网络节点接口 （Network Node Interface, 简称为 NI) 侧的报文， 需要判断该报文标签映射值会话 ID是否在聚合端 口业务表或聚合器业务表中， 如果该会话 ID在业务表中， 则转发， 否则丢弃。 当聚合链路或端内系统发生故障时， 需要将业务切换到其他端口或其他端内系统 发送。 但其他端口业务表、 其他端内系统的聚合器业务表中都不包含该业务， 业务将 被丢弃， 导致流量中断。 针对相关技术中聚合链路或端内系统发生故障时会导致流量中断的问题， 目前尚 未提出有效的解决方案。 发明内容 针对相关技术中聚合链路或端内系统发生故障时会导致流量中断的问题， 本发明 提供了一种分布式弹性网络互连的业务承载方法及装置， 以至少解决上述问题。 根据本发明实施例的一个方面， 提供了一种 DRNI的业务承载方法， 包括： DRNI 端点内的端内系统之间同步所述端点的端内系统的状态和 /或端口的状态； 所述端内系 统检测到发生了事件， 其中， 所述事件用于触发更新承载业务的端内系统和 /或端口； 所述端内系统根据承载所述业务的端内系统序列和 /或端口序列， 以及所述端点内的端 内系统的状态和 /或端口的状态， 更新当前承载所述业务的端内系统和 /或端口。 优选地， DRNI端点内的端内系统之间同步所述端点的端内系统的状态和 /或端口 的状态包括： 所述 DRNI端点内的端内系统之间周期通过 DRCP相互通告自身的端口 状态和 /或其他端内系统的端口状态， 实现端内系统之间的状态同步。 优选地，端内系统之间周期通过 DRCP相互通告自身的端口状态和 /或其他端内系 统的端口状态包括： 所述端内系统将自身的端口状态信息和 /或其他端内系统的端口状 态信息以值 TLV方式携带在所述 DRCP报文中，向所述 DRNI端点的其他端内系统发 送。 优选地， 所述端口状态信息包括以下至少之一： 聚合端口的分发使能状态信息， 聚合端口的 LACP状态信息， 聚合器的分发使能状态信息。 优选地， DRNI端点内的端内系统之间同步所述端点的端内系统和 /或端口的状态， 还包括： 在端内系统的端口状态发生改变的情况下， 所述状态发生改变的端口所属的 端内系统通过 DRCP向所述 DRNI端点的其他端内系统通告状态发生改变的端口状态。 优选地， 所述事件包括： 本端点的端内系统和 /或端口的状态发生改变。 优选地， 本端点的端内系统和 /或端口的状态发生改变包括以下之一： 本端点的端 内系统发生故障或故障恢复； 本端点的端内系统的内连链路发生故障或故障恢复； 本 端点的端内系统被移除或加入聚合组；本端点的端内系统的端口发生故障或故障恢复; 以及本端点的端内系统的端口被移除或加入聚合组。 优选地， 所述端内系统将状态发生改变的端内系统和 /或端口当前所承载的业务确 定为受所述事件影响的业务包括： 所述端内系统确定受所述事件影响的业务； 优选地， 所述端内系统确定受所述事件影响的业务包括： 所述端内系统将状态发 生改变的端内系统和 /或端口当前所承载的业务确定为受所述事件影响的业务。 优选地， 所述端内系统将状态发生改变的端内系统和 /或端口当前所承载的业务确 定为受所述事件影响的业务包括： 所述 DRNI端点内的端内系统检测到本端内系统的 端口不可用； 所述不可用端口所属的端内系统更新所述端口的状态为不可用， 并获取 所述不可用端口的端口业务表； 将所述端口业务表中包含的业务确定为受所述事件影 响的业务。 优选地， 在端内系统检测到本端内系统的端口不可用之后， 还包括： 所述不可用 端口所属的端内系统向本端点内的其他端内系统通告所述端口不可用； 所述其他端内 系统更新本地保存的所述端口的状态为不可用，并获取所述不可用端口的端口业务表; 将所述端口业务表中包含的业务确定为受所述事件影响的业务。 优选地， 所述端内系统将状态发生改变的端内系统和 /或端口当前所承载的业务确 定为受所述事件影响的业务包括： 所述 DRNI端点内的端内系统检测到与本端点内的 相邻端内系统的连接信息丢失， 且所述检测到连接信息丢失的端内系统仍保持加入聚 合组； 所述检测到连接信息丢失的端内系统更新本地保存的所述相邻端内系统的端口 状态为不可用， 并获取所述不可用端口的端口业务表； 将所述端口业务表中包括的业 务确定为受所述事件影响的业务。 优选地， 所述端内系统将状态发生改变的端内系统和 /或端口当前所承载的业务确 定为受所述事件影响的业务包括： 所述 DRNI端点内的端内系统检测到本端内系统的 端口由不可用恢复为可用； 所述恢复为可用端口所属的端内系统更新所述端口的状态 为可用， 并获取所述 DRNI端点内当前承载端口不是第一优先端口的业务； 所述恢复 为可用端口所属的端内系统比较所述恢复为可用端口与所述业务的当前承载端口在承 载所述业务的端内系统序列和 /或端口序列中的位置关系； 在所述恢复为可用端口比所 述业务的当前承载端口处于优先位置的情况下， 将所述业务确定为受所述事件影响的 业务。 优选地，在端内系统检测到本端内系统的端口由不可用恢复为可用之后，还包括: 所述恢复为可用端口所属的端内系统向所述 DRNI端点内的其他端内系统通告所述端 口可用；所述其他端内系统更新本地保存的所述端口的状态为可用，并获取所述 DRNI 端点内当前承载端口不是第一优先端口的业务； 所述其他端内系统比较所述恢复为可 用端口与所述业务在承载所述业务的端内系统序列和 /或端口序列中的位置关系； 在所 述恢复为可用端口比所述业务的当前承载端口处于优先位置的情况下， 将所述业务确 定为受所述事件影响的业务。 优选地， 所述端内系统根据承载所述业务的端内系统序列和 /或端口序列， 以及所 述端点内的端内系统的状态和 /或端口的状态， 更新当前承载所述业务的端内系统和 / 或端口包括： 获取所述业务的业务端口表， 其中， 所述业务端口表中包括承载所述业 务的端内系统序列和 /或端口序列； 根据所述业务端口表中的承载所述业务的端内系统 序列和 /或端口序列的顺序，选择状态为可用且所述顺序在先的端内系统和 /或端口作为 所述业务的当前承载端内系统和 /或端口； 更新所述业务的当前承载端口的端口业务 表。 根据本发明实施例的另一方面， 提供了一种 DRNI的业务承载装置， 位于 DRNI 端点内的端内系统中， 包括： 同步模块， 设置为同步 DRNI端点内的端内系统的状态 和 /或端口的状态； 检测模块， 设置为检测到发生了事件， 其中， 所述事件用于触发更 新承载业务的端内系统和 /或端口； 更新模块， 设置为根据承载业务的端内系统序列和 /或端口序列， 以及所述端点内的端内系统和 /或端口的状态，更新当前承载所述业务的 端内系统和 /或端口。 优选地，所述同步模块包括：第一通告单元，设置为端内系统之间周期通过 DRCP 相互通告所述自身的端口状态和 /或其他端内系统的端口状态。 优选地， 所述同步模块包括： 第二通告单元， 设置为在所述端内系统的端口状态 发生改变的情况下， 通过 DRCP向所述 DRNI端点的其他端内系统通告状态发生变化 的端口状态。 优选地， 所述更新模块包括： 确定模块， 设置为确定受所述事件影响的业务； 获 取单元， 设置为获取所述业务的业务端口表， 其中， 所述业务端口表中包括承载所述 业务的端内系统序列和 /或端口序列； 选择单元， 设置为根据所述业务端口表中的承载 所述业务的端内系统和 /或端口的顺序， 选择状态为可用的且所述顺序在先的端内系统 和 /或端口作为所述业务的当前承载端内系统和 /或端口；第一更新单元，设置为更新所 述业务的当前承载端口的端口业务表。 优选地， 所述确定模块包括： 第二更新单元， 设置为在检测到本端内系统的端口 不可用后， 更新所述不可用端口的状态为不可用， 并获取所述不可用端口的端口业务 表； 第一确定单元， 设置为将所述端口业务表中包含的业务确定为受所述事件影响的 业务。 优选地， 所述确定模块还包括： 第一接收单元， 设置为接收所述 DRNI端点内的 其他端内系统的通告， 其中， 所述通告用于指示所述其他端内系统的端口不可用； 所 述第二更新单元， 还用于更新保存的所述其他端内系统的所述端口的状态为不可用， 并获取所述不可用端口的端口业务表； 所述第一确定单元， 还用于将所述端口业务表 中包含的业务确定为受所述事件影响的业务。 优选地， 所述确定模块包括： 第三更新单元， 设置为在检测到与所述 DRNI端点 内的相邻端内系统的连接信息丢失后， 且所述检测到连接信息丢失的端内系统保持加 入聚合组的情况下， 更新保存的所述相邻端内系统的端口状态为不可用， 并获取所述 不可用端口的端口业务表； 第二确定单元， 设置为将所述端口业务表中包括的业务确 定为受所述事件影响的业务。 优选地， 所述确定模块还包括： 第四更新单元， 设置为在检测到本端内系统的端 口由不可用恢复为可用后， 更新所述端口的状态为可用； 优先级检测单元， 设置为检 测所述 DRNI端点内当前承载端口不是第一优先端口的业务； 比较单元， 设置为比较 所述恢复为可用端口与所述业务的当前承载端口在承载所述业务的端内系统序列和 / 或端口序列中的位置关系， 并在所述恢复为可用端口比所述业务的当前承载端口处于 优先位置的情况下， 将所述业务确定为受所述事件影响的业务。 优选地， 所述确定模块还包括： 第二接收单元， 设置为接收所述 DRNI端点内的 其他端内系统的通告， 其中， 所述通告用于指示所述其他端内系统的端口可用； 所述 第四更新单元还设置为更新保存的所述其他端内系统的所述端口的状态为可用； 所述 优先级检测单元还设置为检测所述 DRNI端点内当前承载端口不是第一优先端口的业 务； 所述比较单元还设置为比较所述恢复为可用端口与所述业务的当前承载端口在承 载所述业务的端内系统序列和 /或端口序列中的位置关系， 并在所述恢复为可用端口比 所述业务的当前承载端口处于优先位置的情况下， 将所述业务确定为受所述事件影响 的业务。 通过本发明实施例， 采用 DRNI端点内的端内系统之间同步该端点的端内系统的 状态和 /或端口的状态； 端内系统检测到发生了事件， 其中， 该事件用于触发更新承载 业务的端内系统和 /或端口； 端内系统确定受该事件影响的业务； 端内系统根据承载该 业务的端内系统序列和 /或端口序列， 以及该端点内的端内系统的状态和 /或端口的状 态， 更新当前承载该业务的端内系统和 /或端口的方式， 解决了相关技术中聚合链路或 端内系统发生故障时会导致流量中断的问题， 降低了故障对业务的影响， 提升了用户 体验。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中- 图 1是根据本发明实施例的分布式弹性网络互连的业务承载方法的流程图； 图 2是根据本发明实施例的分布式弹性网络互连的业务承载装置的结构框图; 图 3是根据本发明实施例的同步模块的优选结构框图; 图 4是根据本发明实施例的更新模块的优选结构框图; 图 5是根据本发明实施例的确定模块的优选结构框图- 图 6是根据本发明实施例的确定模块的优选结构框图 图 7是根据本发明实施例的确定模块的优选结构框图 图 8是根据本发明实施例一的聚合链路故障所在端内系统的处理流程图; 图 9是根据本发明实施例一的聚合链路故障其他端内系统的处理流程图; 图 10是根据本发明实施例一的端内系统故障处理流程图; 图 11是根据本发明实施例一的聚合链路故障恢复所在端内系统的处理流程图; 图 12是根据本发明实施例一的聚合链路故障恢复其他端内系统的处理流程图; 图 13是根据本发明实施例一的 DRNI中协商业务承载的装置的结构框图； 图 14是根据本发明实施例二的组网示意图; 图 15是根据本发明实施例二的聚合链路故障示意图; 图 16是根据本发明实施例三的端内系统故障示意图; 图 17是根据本发明实施例四的组网示意图; 图 18是根据本发明实施例五的逻辑端口不可用的示意图, 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在不冲突的 情况下， 本申请中的实施例及实施例中的特征可以相互组合。 在本实施例中， 提供了一种分布式弹性网络互连的业务承载方法， 图 1是根据本 发明实施例的分布式弹性网络互连的业务承载方法的流程图， 如图 1所示， 该方法包 括如下步骤： 步骤 S102， DR 端点内的端内系统之间同步该端点的端内系统的状态和 /或端口 的状态； 步骤 S104， 端内系统检测到发生了事件， 其中， 该事件用于触发更新承载业务的 端内系统和 /或端口； 步骤 S106， 端内系统确定受该事件影响的业务； 步骤 S108，端内系统根据承载该业务的端内系统序列和 /或端口序列， 以及该端点 内的端内系统的状态和 /或端口的状态， 更新当前承载该业务的端内系统和 /或端口。 本实施例通过上述步骤， DRNI 聚合组端点内的端内系统之间同步该端点的端内 系统的状态 （例如， 分发使能状态） 和 /或端口的状态 （例如， 分发使能状态）； 在检 测到发生了用于触发更新承载业务的端内系统和 /或端口的事件后， 端内系统确定受该 事件影响的业务， 并更新当前承载该业务的端内系统和 /或端口， 从而避免了当承载业 务的聚合链路或端内系统发生故障时， 聚合组端点内的其他端内系统和 /或端口丢弃该 业务的情况出现， 解决了相关技术中聚合链路或端内系统发生故障时会导致流量中断 的问题， 降低了故障对业务的影响， 提升了用户体验。 作为一种优选实施方式， 聚合组端点内的端内系统和 /或端内系统的端口的状态的 同步方式可以是由聚合组端点内的端内系统之间周期通过分布式中继控制协议 (Distributed Relay Control Protocol, 简称为 DRCP) 相互通告端口的状态信息， 以达 到端内系统之间的状态同步。 端内系统发送的端口状态信息中既可以包含本端内系统 的端口状态信息， 还可以包含其他端内系统的端口状态信息。 优选地， 端内系统可以将该端内系统自身的端口状态信息和 /或其他端内系统的端 口状态信息以类型、 长度和赋值 （Type、 Length and Value, 简称为 TLV) 的方式携带 在 DRCP报文中， 向 DRNI聚合组端点的其他端内系统发送。 通过这种同步报文格式 携带端口的状态信息， 简洁清楚。 优选地， 上述端口的状态信息可以是聚合端口的分发使能状态信息， 或者聚合端 口的链路聚合控制协议（LinkAggregation Control Protocol, 简称为 LACP)状态信息， 或者也可以是聚合器的分发使能状态信息。 通过这种方式， 在端口的状态发生上述任 一种变化时， 均可以触发业务的承载更新， 进一步保证了业务的连续性。 优选地， 在端内系统的端口状态 （例如， 聚合端口的分发使能状态、 聚合端口的
LACP 状态、 聚合器的分发使能状态等） 发生改变的情况下， 状态发生改变的端口所 属的端内系统通过 DRCP向聚合组端点的其他端内系统通告该状态发生改变的端口的 状态。 其中， 在同步端口的状态信息时， 可以将所有状态信息均进行同步， 或者， 也 可以仅将发生改变的状态信息进行同步。 作为一种优选实施方式， 上述用于触发更新承载业务的端内系统和 /或端口的事件 可以是该 DRNI 端点内的端内系统和 /或端口的状态发生改变。 例如， 本端点 （即该 DRNI 聚合组端点） 的端内系统发生故障或故障恢复； 本端点的端内系统的内连链路 发生故障或故障恢复； 本端点的端内系统被移除或加入聚合组， 本端点的端内系统的 端口发生故障或故障恢复； 以及本端点的端内系统的端口被移除或加入聚合组。 优选地，步骤 S106中端内系统确定受事件影响的业务的方式可以是该端内系统将 状态发生改变的端内系统和 /或端口当前所承载的业务确定为受上述事件影响的业务。 以端内系统发现该系统内的端口状态变成不可用为例， 作为一种优选实施方式， 确定需要更新承载的业务的方式可以如下： 当端内系统检测到本端内系统的端口不可 用的情况下， 不可用端口所属的端内系统可以更新该端口的状态为不可用， 并获取该 端口在该端内系统中的端口业务表， 将端口业务表中包含的业务确定为受事件影响的 业务， 以进行承载更新。 优选地， 在端内系统检测到本端内系统的端口不可用之后， 不可用端口所属的端 内系统还可以向聚合组端点内的其他端内系统通告该端口不可用； 在这种情况下， 其 他端内系统可以同时更新本地保存的该端口的状态为不可用， 并获取该不可用的端口 的端口业务表， 将该端口业务表中包含的业务确定为受事件影响的业务， 以进行承载 更新。 通过这种方式， 聚合组端点内的所有端内系统中均可以保证其保存的自身以及 其他端内系统的端口的端口业务表的正确性。 作为一种优选实施方式， 在聚合组端点内的端内系统检测到其与该聚合组端点内 的相邻端内系统的连接信息丢失、 且该检测到连接信息丢失的端内系统仍保持加入聚 合组的情况下， 该检测到连接信息丢失的端内系统可以更新本地保存的相邻端内系统 的端口状态为不可用， 并获取不可用的端口的端口业务表， 将该端口业务表中包括的 业务确定为受事件影响的业务， 以进行承载更新。 以端内系统发现该系统内的端口状态由不可用恢复为可用为例， 作为一种优选实 施方式， 当该端内系统检测到本端内系统的端口由不可用恢复为可用的情况下， 该恢 复为可用端口所属的端内系统可以更新该端口的状态为可用， 并获取该 DRNI聚合组 端点内所有当前承载端口不是第一优先端口的业务； 该端内系统比较恢复的端口与当 前承载端口不是第一优先端口的业务的当前承载端口在承载该业务的端内系统序列和 /或端口序列中的位置关系； 如果恢复的端口比业务的当前承载端口处于优先位置的情 况下， 则将业务确定为受事件影响的业务， 以进行承载更新。 例如， 以业务的端内系 统序列和 /或端口序列中在先的端内系统和 /或端口的优先级较高为例，则如果在业务的 端内系统序列和 /或端口序列中， 恢复的端口所处的位置先于业务的当前承载端口所处 的位置， 则可以将该业务确定为受事件影响的业务。 优选地， 在端内系统检测到端内系统的端口由不可用恢复为可用之后， 恢复为可 用端口所属的端内系统还可以向 DRNI聚合组端点内的其他端内系统通告该端口恢复 为可用； 在这种情况下，其他端内系统可以同时更新本地保存的该端口的状态为可用， 并获取该 DRNI聚合组端点内所有当前承载端口不是第一优先端口的业务； 该其他端 内系统比较恢复的端口与当前承载端口不是第一优先端口的业务在承载该业务的端内 系统序列和 /或端口序列中的位置关系； 如果恢复的端口比业务的当前承载端口处于优 先位置的情况下， 则将业务确定为受事件影响的业务， 以进行承载更新。 例如， 以业 务的端内系统序列和 /或端口序列中在先的端内系统和 /或端口的优先级较高为例，则如 果在业务的端内系统序列和 /或端口序列中， 恢复的端口所处的位置先于业务的当前承 载端口所处的位置， 则可以将该业务确定为受事件影响的业务。 通过这种方式， 聚合 组端点内的所有端内系统中均可以保证其保存的自身以及其他端内系统的端口的端口 业务表的正确性。 通过上述方式， 能够在检测到聚合组端点内的端口状态发生改变的情况下， 迅速 准确地确定受到影响的业务， 从而保证了所有业务的流量连续性。 作为一种优选实施方式， 步骤 S108中更新承载受影响业务的端内系统和 /或端口 的方式可以如下： 获取该业务的业务端口表， 并根据该业务端口表中的承载优先级顺 序， 选择当前聚合组端点内所有端口中分发使能状态为可用的且承载优先级最高的端 口作为业务的承载端口； 然后更新该承载端口的端口业务表。 其中， 上述业务端口表 为可以承载该业务的端口序列表， 表中的端口序列可以是按承载业务的优先级顺序排 序的； 上述端口业务表为可以通过该端口承载的业务， 该端口业务表也可以用于在端 口故障时获取受故障影响的业务。 对应于上述方法， 在本实施例中还提供了一种分布式弹性网络互连的业务承载装 置， 位于 DRNI端点内的任意一个端内系统中， 该装置用于实现上述实施例及优选实 施方式， 已经进行过说明的不再赘述。 如以下所使用的， 术语"模块"可以实现预定功 能的软件和 /或硬件的组合。 尽管以下实施例所描述的装置较佳地以软件来实现， 但是 硬件， 或者软件和硬件的组合的实现也是可能并被构想的。 图 2是根据本发明实施例的分布式弹性网络互连的业务承载装置的结构框图， 如 图 2所示， 该装置包括： 同步模块 22、 检测模块 24和更新模块 26， 下面对各个模块 进行详细说明。 同步模块 22， 设置为同步 DR 端点内的端内系统的状态和 /或端口的状态； 检测 模块 24， 与同步模块 22相连， 设置为检测到发生了事件， 其中， 该事件用于触发更 新承载业务的端内系统和 /或端口； 更新模块 26， 与同步模块 22和检测模块 24相连， 设置为根据承载业务的端内系统序列和 /或端口序列，以及该端点内的端内系统和 /或端 口的状态， 更新当前承载该业务的端内系统和 /或端口。 本实施例通过上述模块， DRNI聚合组端点内的端内系统之间通过同步模块 22同 步该端点的端内系统的状态和 /或端口的状态； 在检测模块 24检测到发生了用于触发 更新承载业务的端内系统和 /或端口的事件后， 并通过更新模块 26更新当前承载业务 的端内系统和 /或端口， 从而避免了当承载业务的聚合链路或端内系统发生故障时， 聚 合组端点内的其他端内系统和 /或端口丢弃该业务的情况出现， 解决了相关技术中聚合 链路或端内系统发生故障时会导致流量中断的问题， 降低了故障对业务的影响， 提升 了用户体验。 图 3是根据本发明实施例的同步模块 22的优选结构框图， 如图 3所示， 同步模块 22可以包括： 第一通告单元 222， 设置为通过 DRCP向聚合组端点的其他端内系统通 告自身的端口状态和 /或其他端内系统的端口状态； 或者， 同步模块 22也可以包括： 第二通告单元 224，设置为在本端内系统的端口的状态发生改变的情况下，通过 DRCP 向聚合组端点的其他端内系统通告状态发生变化的端口状态。 图 4是根据本发明实施例的更新模块 26的优选结构框图， 如图 4所示， 更新模块 26可以包括： 确定模块 262， 用于获取受故障影响的业务， 获取单元 264， 设置为获 取业务的业务端口表， 其中， 该业务端口表中包括承载该业务的端内系统序列和 /或端 口序列； 选择单元 266， 与获取单元 264相连， 设置为根据业务端口表中的承载该业 务的端内系统和 /或端口的顺序， 选择分发使能状态为可用的且顺序在先的端内系统和
/或端口作为该业务的当前承载端内系统和 /或端口；第一更新单元 268，与选择单元 266 相连， 设置为更新该业务的当前承载端口的端口业务表。 图 5是根据本发明实施例的确定模块 262的优选结构框图一， 如图 5所示， 确定 模块 262可以包括： 第二更新单元 26202， 设置为在检测到本端内系统的端口不可用 后， 更新不可用的端口的状态为不可用， 并获取不可用的端口的端口业务表； 第一确 定单元 26204， 与第二更新单元 26202相连， 设置为将端口业务表中包含的业务确定 为受事件影响的业务。 优选地， 确定模块 262还可以包括： 第一接收单元 26206， 与第二更新单元 26202 相连， 设置为接收聚合组端点内的其他端内系统的通告， 其中， 该通告用于指示其他 端内系统的端口不可用； 在这种情况下， 第二更新单元 26202还可以设置为更新其他 端内系统的端口的状态为不可用， 并获取不可用的端口的端口业务表； 第一确定单元 26204还可以设置为将端口业务表中包含的业务确定为受事件影响的业务。 图 6是根据本发明实施例的确定模块 262的优选结构框图二， 如图 6所示， 确定 模块 262可以包括： 第三更新单元 26212， 设置为在检测到与聚合组端点内的相邻端 内系统的连接信息丢失后， 且该检测到连接信息丢失的端内系统保持加入聚合组的情 况下， 更新保存的相邻端内系统内的端口的状态为不可用， 并获取不可用的端口的端 口业务表； 第二确定单元 26214， 与第三更新单元 26212相连， 设置为将端口业务表 中包括的业务确定为受事件影响的业务。 图 7是根据本发明实施例的确定模块 262的优选结构框图三， 如图 7所示， 确定 模块 262还可以包括： 第四更新单元 26222， 设置为在检测到本端内系统的端口由不 可用恢复为可用后， 更新该端口的状态为可用； 优先级检测单元 26224， 与第四更新 单元 26222相连， 设置为检测 DRNI聚合组端点内当前承载端口不是第一优先端口的 业务； 比较单元 26226， 与优先级检测单元 26224相连， 设置为比较恢复的端口与当 前承载端口不是第一优先端口的业务的当前承载端口在承载该业务的端内系统序列和 /或端口序列中的位置关系， 并在恢复的该端口比该业务的当前承载端口处于优先位置 的情况下， 将该业务确定为受事件影响的业务。 优选地， 确定模块 262还可以包括： 第二接收单元 26228， 与第四更新单元 26222 相连， 设置为接收聚合组端点内的其他端内系统的通告， 其中， 该通告用于指示其他 端内系统的端口可用； 在这种情况下， 第四更新单元 26222还可以设置为更新本地保 存的其他端内系统的端口的状态为可用； 优先级检测单元 26224还可以设置为检测聚 合组端点内当前承载端口不是第一优先端口的业务； 比较单元 26226还可以设置为比 较恢复的端口与当前承载端口不是第一优先端口的业务的当前承载端口在承载该业务 的端内系统序列和 /或端口序列中的位置关系， 并在恢复的端口比该业务的当前承载端 口处于优先位置的情况下， 将业务确定为受事件影响的业务。 下面结合优选实施例进行说明，以下实施例结合了上述实施例及其优选实施方式。 在以下优选实施例中， 为了保证在聚合链路或端内系统发生故障时， 端内系统之 间能够通过协商选择新的聚合链路来实现业务快速切换，从而降低故障对业务的影响， 提供了一种一种在通信系统中网络之间互联接口的保护方案， 尤其提供了一种 DRNI 中协商业务承载的方法和装置。 通过该方案， 在聚合链路或端内系统发生故障时， 流 量能够从其他聚合链路传输， 新选择的聚合链路可以和故障链路可以在同一个端内系 统上， 也可以在本端点的不同端内系统上。 该 DRNI中协商聚合链路的方案包括： 聚合组端点内的端内系统之间相互通告同 步端口状态信息， 根据端口状态信息和业务端口表更新端口业务表和 /或业务当前承载 端口， 并根据业务当前承载端口和 /或端口业务表发送和接收业务。 实施例一 本优选实施例中的 DRNI中协商业务承载的实现方案包括： 步骤一， 端内系统通过分布式中继控制协议 （Distributed Relay Control Protocol, 简称为 DRCP) 向本端点的其他端内系统通告同步端口的状态。 其中， 端口状态信息以 TLV方式携带在 DRCP协议报文中，端内系统之间周期同 步端口状态。 另外， 在端口状态发生改变时， 触发向其他端内系统通告端口状态的变 化情况， 使端内系统之间的端口状态达到同步。 上述端口状态 TLV可以携带聚合端口状态、 聚合器状态等信息。 其中， 聚合端口 状态发生变化触发通告可以为： 聚合端口的分发使能状态发生改变时， 触发通告。 也 可以为聚合端口的 LACP状态发生改变，触发通告；聚合器状态发生变化触发通告为： 聚合器的分发使能状态发生改变时， 触发通告。 步骤二， 端内系统根据业务端口表和同步的端口状态信息， 获取各端口的端口业 务表和 /或业务当前承载端口表。 其中， 上述业务端口表为承载业务的端口序列表， 端口序列按承载业务的优先级 顺序排序； 上述端口业务表为可以通过该端口承载的业务， 可用于端口故障时获取受 故障影响的业务； 上述业务当前承载端口为从业务端口表中获取的当前可用的高优先 级端口， 包含端口号和承载业务的优先级等。其中， 承载业务优先级用于故障恢复时， 通过比较业务的当前承载端口和恢复端口对业务的承载优先级， 来判断是否需要更新 上述业务的当前承载端口。 步骤三， 当端内系统上某个端口不可用时， 需要根据端口状态信息更新端内系统 保存的端口业务表和 /或业务当前承载端口。 其中， 图 8是根据本发明实施例一的聚合链路故障所在端内系统的处理流程图， 如图 8所示， 当端内系统上某端口不可用时， 步骤三的处理过程如下： 步骤 S802， 端内系统上某端口不可用时， 更新该端口状态， 并将该端口的不可用 状态信息通告给端点内的其他端内系统。 步骤 S804， 从保存的该不可用端口的端口业务表中， 获取受影响的业务。 步骤 S806， 检索受影响业务的业务端口表， 获取下一个可用的高优先级端口作为 该业务的承载端口， 更新端内系统上保存的端口业务表和 /或业务当前承载端口。 图 9是根据本发明实施例一的聚合链路故障其他端内系统的处理流程图， 如图 9 所示， 当端内系统接收到其他端内系统通告的端口不可用信息时， 步骤三的处理过程 如下： 步骤 S902， 端内系统在接收到端口状态变为不可用的状态通告信息后， 更新本端 内系统上保存的该端口的状态为不可用。 步骤 S904， 从保存的该不可用端口的端口业务表中， 获取受影响的业务。 如果存 在受故障影响的业务， 则进入步骤 S906。 步骤 S906， 检索受影响业务的业务端口表， 获取下一个可用的高优先级端口作为 该业务的承载端口， 更新端内系统上保存的端口业务表和 /或业务当前承载端口。 步骤四， 图 10是根据本发明实施例一的端内系统故障处理流程图， 当端内系统检 测到相邻端内系统连接信息丢失， 如相邻端内系统故障、 内连链路故障导致相邻端内 系统从聚合组移除， 而本端内系统仍保持加入聚合组， 则本端内系统的处理过程如图 10所示： 步骤 S1002，更新本端内系统上保存的与不可用端内系统上的端口状态为不可用。 步骤 S1004, 从保存的该不可用端口的端口业务表中， 获取受故障影响的业务。 如果存在受故障影响的业务， 则进入步骤 S1006。 步骤 S1006, 检索受影响业务的业务端口表， 获取下一个可用的高优先级端口作 为该业务的承载端口， 更新端内系统上保存的端口业务表和 /或业务当前承载端口。 步骤五， 当端内系统上的某端口由不可用恢复为可用状态， 且为返回模式， 需要 根据端口状态信息更新端内系统保存的端口业务表和 /或业务当前承载端口。 图 11 是 根据本发明实施例一的聚合链路故障恢复所在端内系统的处理流程图， 如图 11所示， 该处理过程如下： 步骤 S1102, 端内系统上某端口恢复为可用时， 将端口的可用状态信息通告给端 点内的其他端内系统。 步骤 S1104, 检索所有业务的业务当前承载端口， 获取当前承载端口不是第一优 先端口的业务。 步骤 S1106, 比较恢复端口与业务当前承载端口对上述业务的承载优先级， 如果 恢复端口的承载优先级高， 则进入步骤 S1108， 否则， 进入步骤 S1110。 步骤 S1108 , 更新恢复端口为业务承载端口， 更新端内系统上保存的端口业务表 和 /或业务当前承载端口。 步骤 S1110, 无需处理， 保持当前承载端口不变。 图 12是根据本发明实施例一的聚合链路故障恢复其他端内系统的处理流程图，如 图 12所示， 当端内系统接收到其他端内系统通告的端口变为可用信息时， 处理过程如 下： 步骤 S1202, 端内系统在接收到端口状态变为可用的状态通告信息后， 更新本端 内系统上保存的该端口的状态为可用。 步骤 S1204, 检索所有业务的业务当前承载端口， 获取当前承载端口不是第一优 先端口的业务。 步骤 S1206比较恢复端口与业务当前承载端口对上述业务的承载优先级， 如果恢 复端口的承载优先级高， 则进入步骤 S1208, 否则， 进入步骤 S1210。 步骤 S1208， 更新恢复端口为业务承载端口， 更新端内系统上保存的端口业务表 和 /或业务当前承载端口。 步骤 S1210, 无需处理， 保持当前承载端口不变。 在本优选实施例中， 还提供了一种实现 DRNI中协商业务承载的装置， 图 13是根 据本发明实施例一的 DRNI中协商业务承载的装置的结构框图， 如图 13所示， 该装置 包括控制报文收发单元 1302、检测单元 1304、更新单元 1306、业务报文收发单元 1308， 来完成上述功能。 上述控制报文收发单元 1302 (实现了上述同步模块 22的功能）， 设置为与其他端 内系统之间接收和发送状态通知报文、 状态同步报文， 对报文进行封装和解封装。 上述检测单元 1304 (实现了上述确定模块 24的功能）， 设置为对端口状态、 相邻 端内系统状态进行检测。 上述更新单元 1306 (实现了上述更新模块 26的功能）， 设置为根据端口状态信息 和保存的业务端口表信息， 更新业务当前承载端口和端口业务表。 设置为根据收发单 元接收的状态信息、 检测单元检测到的状态信息， 更新保存的端口状态信息。 上述业务报文收发单元 1308，设置为根据端口业务表和 /或业务当前承载端口收发 业务报文。 其中， 上述端口既可以是物理端口， 也可以是逻辑端口。 上述业务是指可标记的数据流或会话， 其可以用以太网 VLANID虚拟局域网标 识)、 I-SID (骨干业务实例标识符） 或会话 ID等来标记。 根据本优选实施例中提供的 DRNI中协商业务承载的方法， 在聚合链路或端内系 统发生故障时， 根据端内系统之间同步的端口状态信息， 动态更新聚合端口业务表和 / 或聚合器业务表， 使受故障影响的业务能够从故障链路所在端内系统的其他聚合链路 传送， 或从其他端内系统的聚合链路重新传送， 降低故障对业务的影响。 下面结合其他实施例和附图对本优选实施例中的 DRNI中协商业务承载的方法进 行更加详细的说明。 实施例二 在本优选实施例中， 以 DRNI—端的端内系统之间协商更新的端口为物理端口为 例进行说明。 图 14是根据本发明实施例二的组网示意图， 如图 14所示， 聚合组的两 端分别由 1个端点组成， 每个端点分别由 2个端内系统组成， 其中， 端点 1由端内系 统 A、 B组成， 端点 2由端内系统 C、 D组成。端点 1和端点 2之间的链路 1、链路 2、 链路 3、 链路 4聚合成分布式 LAG。 以下以端点 1内各端内系统的信息交互和业务转 发进行说明， 端点 2内各端内系统的处理方式同端点 1。 步骤一， 端点 1内的端内系统 A、 B经配置协商得到全局业务端口表， 表 1是根 据本发明实施例二的端点 1的业务端口表， 如表 1所示， 该业务端口表指明承载业务 的端口优先顺序。 表 1
Figure imgf000018_0001
步骤二， 端内系统 、 B通过 DRCP协议周期同步端口状态信息， 端口状态信息 以 TLV方式携带在 DRCP协议中。 一种可行的端口状态 TLV格式如下：
状态消息类型 lByte
状态消息长度 2Byte
端口状态信息 可变长 在本示例中端口状态信息字段中可携带聚合器状态 sub-TLV、 聚合端口状态 sub-TLV等信息。 一种可行的聚合器状态 sub-TLV如下:
Figure imgf000018_0002
这里的聚合器标识为可选字段， 聚合器状态为端内系统标识指定的端内系统上的 聚合器状态， 有可用和不可用两种状态。 -种可行的聚合端口状态 sub-TLV如下:
Figure imgf000019_0001
聚合端口状态为聚合端口的 LACP状态， 当 LACP状态为分发使能， 则该聚合端 口可用， 否则不可用。 另外， 除周期同步外， 在端口状态发生改变时， 触发通告端口状态的变化情况， 在向其他端内系统通告的端口状态 TLV中携带发生变化的端口状态。 如， 聚合端口 1 状态发生变化， 聚合端口 2状态没有变化， 则在触发状态通告时， 仅在聚合端口状态 TLV中携带聚合端口 1的状态信息， 不携带聚合端口 2的状态信息， 来通知其他端内 系统聚合端口 1的状态发生变化。 步骤三， 端内系统 、 B的聚合状态同步后， 根据聚合端口状态， 从业务端口表 (表 1 )获取可用的高优先级端口， 形成端口业务表、业务当前承载端口。如： 端口 1， 端口 2， 端口 3， 端口 4， 都已加入聚合组， 且端口可用。 则根据表 1， 生成业务当前 承载端口， 表 2是根据本发明实施例二的业务当前承载端口表， 如表 2所示， 业务当 前承载端口如下： 表 2
Figure imgf000019_0002
表 3是根据本发明实施例二的端口业务表， 即通过本端口发送和接收的业务， 如 表 3所示， 端口对应的业务序列如下： 表 3
端口号 端口所在端内系统 端口业务序列 端口 1 端内系统 A 001、 005
端口 2 端内系统 A 002、 006
端口 3 端内系统 B 003
端口 4 端内系统 B 004 步骤四， 根据端点的聚合端口业务表， 可以形成各端内系统的聚合器业务表， 即 可通过本端内系统的聚合器发送和接收的业务信息， 表 4是根据本发明实施例二的聚 合器业务表， 如表 4所示， 聚合器业务如下： 表 4
Figure imgf000020_0001
形成各端内系统的聚合器业务表的过程， 是可选的。 如果需要通过各端内系统的 聚合器业务表来形成转发表， 则通过该过程来获取各端内系统的聚合器业务表。例如， 对于三个端内系统及以上组成的聚合组， 可根据各端内系统聚合器业务表转发业务， 或过滤泛洪的业务， 防止环路。 步骤五， 图 15是根据本发明实施例二的聚合链路故障示意图， 如图 15所示， 当 链路 1故障时， 端内系统 A的端口 1状态指示该端口不可用， 触发端口状态通告， 在 DRCP协议通告的端口状态 TLV中携带端口 1状态， 通告该端口不可用。 端内系统 B接收到端内系统 A通告的聚合端口 1的状态变为不可用，更新本端内 系统上保存的聚合端口 1的状态为不可用。 端内系统 A、B查找端口 1的业务表 (表 3 )，获取受端口 1故障影响的业务为" 001， 005"。 然后， 查找" 001， 005"的业务端口表 （表 1 )， 获取当前可用的高优先端口分别 为端口 2、 3， 更新业务当前承载端口 （表 5 )， 并更新端口 2、 3的端口业务表 （表 6) 和各端内系统的聚合器业务表 （表 7)。 在下文各表中， 加粗部分以及带删除线部分为 修改部分。 其中， 表 5是根据本发明实施例二的业务当前承载端口表； 表
Figure imgf000020_0002
004 端口 4 1 端内系统 B
005 端口 3 2 端内系统 B
006 端口 2 1 端内系统 A 表 6是根据本发明实施例的端口的业务表; 表 6
Figure imgf000021_0001
表 7是根据本发明实施例二的聚合器业务表。 表 7
Figure imgf000021_0002
步骤六， 端口当前承载端口、 端口业务表， 各端内系统的聚合器业务表更新后， 端内系统 A从网络侧接收到业务 001， 从表 5确定业务 001当前承载端口在本系统上 的端口 2， 从本系统的端口 2发送。 端内系统 A从网络侧接收到业务 005， 从表 5确 定该业务的当前承载端口为端内系统 B上的端口 3， 故业务 005通过内连接口， 从内 连链路转发给端内系统 B， 由端内系统 B的端口 3发送。 在保证业务双向一致时， 从聚合端口接收到的业务， 判断该业务是否在该接收端 口的业务表中， 或判断该业务的当前承载端口是否为该接收接口。 若是， 则接收并转 发该业务。 否则， 丢弃。 步骤七， 端内系统 A上的端口 1连接的链路 1恢复， 触发端口状态更新和通告， 在 DRCP协议通告的状态 TLV报文中携带聚合端口 1状态， 向端内系统 B通告该聚 合端口可用。 过程同上。 端内系统 B接收到端内系统 A通告的聚合端口 1的状态可用后，更新本端内系统 保存的该聚合端口状态为可用。 端内系统 、 B进行返回处理， 对业务当前承载端口优先级不为第一优先级端口 的业务（如表 5的业务 "001， 005"), 判断该业务当前端口优先级是否比恢复链路承载 业务优先级高， 由于端口 1承载业务" 001， 005"的优先级比端口 2、 3高， 故更新业务
"001， 005"的当前承载端口为端口 1 (更新后同表 2)， 触发更新端口 1、 2、 3的端口 业务表 （更新后同表 3 )， 同时更新保存的各端内系统的聚合器业务表信息 （更新后同 表 4)。 实施例三 在本优选实施例中， 以 DRNI—端的端内系统之间协商更新的端口为物理端口为 例进行说明。 图 16是根据本发明实施例三的端内系统故障示意图， 如图 16所示， 在 实施例二基础上， 当端内系统发生故障， 处理过程如下： 当端内系统 A发生故障， 端内系统 B检测到端内系统 A的连接信息丢失， 且端 内系统 B仍保持加入聚合组。端内系统 B从保存的端内系统 A的端口业务表（如表 3 ) 或聚合器业务表 （如表 4 ) 中， 获取受故障影响的业务为" 001， 002， 005， 006"。 同 时， 更新端内系统 A的聚合器和端口状态信息， 置端内系统 A的聚合器和端口状态为 不可用。 检索受故障影响的业务" 001， 002， 005， 006"的业务端口表 （如表 1 )， 分别获取 业务" 001， 002， 005， 006"的当前可用的高优先级端口为业务的当前承载端口， 更新 业务" 001， 002， 005， 006"的当前承载端口 （如表 8)， 触发更新端口 3、 4的业务表 (如表 9)， 并更新各端内系统的聚合器业务表 （如表 10)。 表 8是根据本发明实施例三的业务当前承载端口表； 表 8
Figure imgf000022_0001
表 9是根据本发明实施例三的端口业务表; 表 9
Figure imgf000022_0002
表 10是根据本发明实施例三的聚合器业务表。 表 10
Figure imgf000023_0001
在业务当前承载端口、 各端口业务表更新后， 端内系统 B从网络侧接收到业务， 判断该业务在本端内系统的聚合器业务表中， 从端口当前承载端口发送。 从聚合端口 接收到的业务， 判断该业务在本端口的业务表中， 或该业务的当前承载端口为接收到 报文的端口， 则接收并转发该业务。 若端内系统 A、 B间的内连链路故障， 导致端内系统 A从聚合组移除， 端内系统 A停止转发该聚合组的业务。 实施例四 在本优选实施例中， 以 DRNI—端的端内系统之间协商更新的端口为逻辑端口为 例进行说明。 图 17是根据本发明实施例四的组网示意图， 如图 17所示， 聚合组两端 的端点分别由 2个端内系统组成， 其中， 端点 1由端内系统 A、 B组成， 端点 2由端 内系统 C、 D组成。 端点 1和端点 2之间的链路 1、 链路 2、 链路 3、 链路 4聚合成分 布式 LAG。 端口 1、 2加入到端内系统 A的聚合器 Aggl中， 聚合器客户层看到的端 口为逻辑端口 Aggl (如图 17所示）， 端口 3、 4加入到端内系统 B的聚合器 Agg2中， 聚合器客户层看到的端口为逻辑端口 Agg2 (如图 17所示）。 以下以端点 1内各端内系 统的信息交互和业务转发进行说明， 端点 2内各端内系统的处理方式同端点 1。 步骤一， 端点 1内的端内系统 A、 B经配置协商得到全局业务端口表， 表 11是根 据本发明实施例四的端点 1的业务端口表 （端口为聚合器）， 如表 11所示， 该业务端 口表指明承载业务的端口优先顺序， 表中的端口为各端内系统上的聚合器。 表 11
Figure imgf000023_0002
步骤二， 端内系统 、 B通过 DRCP协议周期同步端口状态信息， 报文格式同实 施例一。 进行周期同步时， 在端口状态 TLV中携带聚合器状态 sub-TLV， 可选择携带 聚合端口状态 sub-TLV。 另外， 除周期同步外， 在聚合器状态发生改变时， 触发通告聚合器状态的变化情 况， 在向其他端内系统通告的端口状态 TLV中携带发生变化的聚合器状态。 如， 聚合 器 Aggl状态发生变化， 则在端口状态 TLV中携带聚合器 Aggl的状态信息， 来通知 其他端内系统聚合器 Aggl的状态发生变化。 步骤三， 端内系统 、 B的聚合状态同步后， 根据聚合器状态， 从业务端口表获 取可用的高优先级端口， 形成端口业务表、业务当前承载端口， 这里的端口为聚合器。 如： 端口 1， 端口 2， 端口 3， 端口 4， 都已加入聚合组， 且端口可用， 相应的聚合器 Agg Agg2可用。 表 12是根据表 11的业务聚合器端口表和聚合器状态所生成的端点 1的业务当前 承载端口表， 这里的承载端口为聚合器， 端内系统 、 B都可以保存有这张表。 表 12
Figure imgf000024_0001
表 13是根据本发明实施例四的端点 1的端口业务表，即通过本端口发送和接收的 业务， 这里的端口为逻辑端口， 即聚合器， 端点 1的端内系统都保存有这张表， 如下
表 13
Figure imgf000024_0002
端内系统在接收到业务后， 根据业务当前承载端口对业务进行转发。 例如， 端内 系统 B接收到业务" 004， 005， 006"，检索业务当前承载端口表（表 12)确定业务" 004， 005, 006"的承载端口为本系统上的聚合器 Agg2， 进一步地由聚合器 Agg2负责将业 务" 004， 005， 006"分发到本端内系统的聚合链路上。 实施例五 图 18是根据本发明实施例五的逻辑端口不可用的示意图， 如图 18所示， 在实施 例四基础上， 当端口 3、 4都不可用时， 端内系统 B的聚合器中不存在可用聚合端口， 故端内系统 B的聚合器状态也变为不可用， 触发端口状态通告， 在 DRCP协议通告的 端口状态 TLV中携带聚合器 Agg2状态， 通告该端口变为不可用。 在通告的端口状态 TLV中可选择携带聚合端口 3、 4的端口状态变为不可用的信息。 端内系统 A接收到端内系统 B通告的聚合器 Agg2的状态变为不可用， 更新本端 内系统上保存的聚合器 Agg2的状态为不可用。 端内系统 、 B查找本系统上保存的端口业务表（表 13 )， 获取受聚合器 Agg2故 障影响的业务为" 004， 005， 006"。 然后， 查找" 004， 005， 006"的业务聚合器端口表 (表 11 )，获取当前可用的高优先端口为聚合器 Aggl，更新业务当前承载端口（表 14)， 并更新聚合器 Aggl、 Agg2的端口业务表 （表 15 )。 在下文各表中， 加粗部分以及带 删除线部分为修改部分。 表 14是根据本发明实施例五的业务当前承载端口表 （端口为聚合器）; 表 14
Figure imgf000025_0001
表 15是根据本发明实施例五的端口业务表 （端口为聚合器）; 表 15
Figure imgf000025_0002
承载业务的端口更新后， 端点上的端内系统根据更新后的信息对业务进行转发。 例如， 端内系统 B接收到业务" 004， 005， 006"， 检索业务当前承载端口 （表 14) 确 定业务 "004， 005， 006"的承载端口为端内系统 A上的聚合器 Aggl， 故将业务发送给 端内系统 。 端内系统 A接收到业务" 004， 005， 006"， 确定业务" 004， 005， 006"的 承载端口为本系统上的聚合器 Aggl， 进一步由本端内系统的聚合器 Aggl负责将业务 分发到聚合链路上。 聚合器恢复可用的处理过程与前面实施例中聚合端口恢复可用类似， 这里不再累 赘。 在另外一个实施例中， 还提供了一种软件， 该软件用于执行上述实施例及优选实 施例中描述的技术方案。 在另外一个实施例中， 还提供了一种存储介质， 该存储介质中存储有上述软件， 该存储介质包括但不限于光盘、 软盘、 硬盘、 可擦写存储器等。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而， 可以 将它们存储在存储装置中由计算装置来执行， 并且在某些情况下， 可以以不同于此处 的顺序执行所示出或描述的步骤， 或者将它们分别制作成各个集成电路模块， 或者将 它们中的多个模块或步骤制作成单个集成电路模块来实现。 这样， 本发明不限制于任 何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的 任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。 工业实用性： 本发明涉及通信领域， 提供了一种分布式弹性网络互连的业务承载方法及装置， 解决了相关技术中聚合链路或端内系统发生故障时会导致流量中断的问题， 降低了故 障对业务的影响， 提升了用户体验。

Claims

权 利 要 求 书
1. 一种分布式弹性网络互连 DRNI的业务承载方法， 包括：
DRNI端点内的端内系统之间同步所述端点的端内系统的状态和 /或端口的 状态；
所述端内系统检测到发生了事件， 其中， 所述事件用于触发更新承载业务 的端内系统和 /或端口；
所述端内系统根据承载业务的端内系统序列和 /或端口序列， 以及所述端点 内的端内系统的状态和 /或端口的状态， 更新当前承载业务的端内系统和 /或端
Π。 2. 根据权利要求 1所述的方法， 其中， DRNI端点内的端内系统之间同步所述端 点的端内系统的状态和 /或端口的状态包括：
所述 DRNI端点内的端内系统之间周期通过分布式中继控制协议 DRCP相 互通告自身的端口状态和 /或其他端内系统的端口状态，实现端内系统之间的状 态同步。 3. 根据权利要求 2所述的方法， 其中， 端内系统之间周期通过 DRCP相互通告自 身的端口状态和 /或其他端内系统的端口状态包括：
所述端内系统将自身的端口状态信息和 /或其他端内系统的端口状态信息 以类型、长度和赋值 TLV方式携带在所述 DRCP报文中， 向所述 DRNI端点的 其他端内系统发送。 4. 根据权利要求 3所述的方法， 其中， 所述端口状态信息包括以下至少之一： 聚 合端口的分发使能状态信息， 聚合端口的 LACP状态信息， 聚合器的分发使能 状态信息。
5. 根据权利要求 1所述的方法， 其中， DRNI端点内的端内系统之间同步所述端 点的端内系统和 /或端口的状态， 还包括：
在端内系统的端口状态发生改变的情况下， 所述状态发生改变的端口所属 的端内系统通过 DRCP向所述 DRNI端点的其他端内系统通告状态发生改变的 端口状态。 根据权利要求 1所述的方法， 其中， 所述事件包括： 本端点的端内系统和 /或端 口的状态发生改变。 根据权利要求 6所述的方法， 其中， 本端点的端内系统和 /或端口的状态发生改 变包括以下之一：
本端点的端内系统发生故障或故障恢复；
本端点的端内系统的内连链路发生故障或故障恢复；
本端点的端内系统被移除或加入聚合组；
本端点的端内系统的端口发生故障或故障恢复； 以及
本端点的端内系统的端口被移除或加入聚合组。 根据权利要求 1所述的方法， 其中， 所述端内系统根据承载业务的端内系统序 列和 /或端口序列， 以及所述端点内的端内系统的状态和 /或端口的状态， 更新 当前承载业务的端内系统和 /或端口包括：
所述端内系统确定受所述事件影响的业务。 根据权利要求 1所述的方法， 其中， 所述端内系统确定受所述事件影响的业务 包括：
所述端内系统将状态发生改变的端内系统和 /或端口当前所承载的业务确 定为受所述事件影响的业务。 10.根据权利要求 9所述的方法，其中，所述端内 系统将状态发生改变的端内系统和 /或端口当前所承载的业务确定为受所述事 件影响的业务包括：
所述 DRNI端点内的端内系统检测到本端内系统的端口不可用； 所述不可用端口所属的端内系统更新所述端口的状态为不可用， 并获取所 述不可用端口的端口业务表；
将所述端口业务表中包含的业务确定为受所述事件影响的业务。 根据权利要求 10所述的方法，其中，在端内系统检测到本端内系统的端口不可 用之后， 还包括：
所述不可用端口所属的端内系统向本端点内的其他端内系统通告所述端口 不可用； 所述其他端内系统更新本地保存的所述端口的状态为不可用， 并获取所述 不可用端口的端口业务表；
将所述端口业务表中包含的业务确定为受所述事件影响的业务。
12. 根据权利要求 9所述的方法， 其中， 所述端内系统将状态发生改变的端内系统 和 /或端口当前所承载的业务确定为受所述事件影响的业务包括：
所述 DRNI端点内的端内系统检测到与本端点内的相邻端内系统的连接信 息丢失， 且所述检测到连接信息丢失的端内系统仍保持加入聚合组；
所述检测到连接信息丢失的端内系统更新本地保存的所述相邻端内系统的 端口状态为不可用， 并获取所述不可用端口的端口业务表；
将所述端口业务表中包括的业务确定为受所述事件影响的业务。
13. 根据权利要求 9所述的方法， 其中， 所述端内系统将状态发生改变的端内系统 和 /或端口当前所承载的业务确定为受所述事件影响的业务包括：
所述 DRNI端点内的端内系统检测到本端内系统的端口由不可用恢复为可 用；
所述恢复为可用端口所属的端内系统更新所述端口的状态为可用， 并获取 所述 DRNI端点内当前承载端口不是第一优先端口的业务；
所述恢复为可用端口所属的端内系统比较所述恢复为可用端口与所述业务 的当前承载端口在承载所述业务的端内系统序列和 /或端口序列中的位置关系； 在所述恢复为可用端口比所述业务的当前承载端口处于优先位置的情况 下， 将所述业务确定为受所述事件影响的业务。
14. 根据权利要求 13所述的方法，其中，在端内系统检测到本端内系统的端口由不 可用恢复为可用之后， 还包括：
所述恢复为可用端口所属的端内系统向所述 DRNI端点内的其他端内系统 通告所述端口可用；
所述其他端内系统更新本地保存的所述端口的状态为可用， 并获取所述 DRNI端点内当前承载端口不是第一优先端口的业务；
所述其他端内系统比较所述恢复为可用端口与所述业务在承载所述业务的 端内系统序列和 /或端口序列中的位置关系； 在所述恢复为可用端口比所述业务的当前承载端口处于优先位置的情况 下， 将所述业务确定为受所述事件影响的业务。
15. 根据权利要求 1至 14中任一项所述的方法，其中，所述端内系统根据承载业务 的端内系统序列和 /或端口序列， 以及所述端点内的端内系统的状态和 /或端口 的状态， 更新当前承载业务的端内系统和 /或端口包括：
获取所述业务的业务端口表， 其中， 所述业务端口表中包括承载所述业务 的端内系统序列和 /或端口序列；
根据所述业务端口表中的承载所述业务的端内系统序列和 /或端口序列的 顺序，选择状态为可用且所述顺序在先的端内系统和 /或端口作为所述业务的当 前承载端内系统和 /或端口；
更新所述业务的当前承载端口的端口业务表。
16. 一种分布式弹性网络互连 DRNI的业务承载装置， 位于 DRNI端点内的端内系 统中， 包括：
同步模块， 设置为同步 DRNI端点内的端内系统的状态和 /或端口的状态； 检测模块， 设置为检测到发生了事件， 其中， 所述事件用于触发更新承载 业务的端内系统和 /或端口；
更新模块， 设置为根据承载业务的端内系统序列和 /或端口序列， 以及所述 端点内的端内系统和 /或端口的状态， 更新当前承载业务的端内系统和 /或端口。
17. 根据权利要求 16所述的装置， 其中， 所述同步模块包括：
第一通告单元， 设置为端内系统之间周期通过分布式中继控制协议 DRCP 相互通告所述自身的端口状态和 /或其他端内系统的端口状态。
18. 根据权利要求 16所述的装置， 其中， 所述同步模块包括：
第二通告单元， 设置为在所述端内系统的端口状态发生改变的情况下， 通 过 DRCP向所述 DRNI端点的其他端内系统通告状态发生变化的端口状态。
19. 根据权利要求 15至 18中任一项所述的装置， 其中， 所述更新模块包括： 确定模块， 设置为确定受所述事件影响的业务；
获取单元， 设置为获取所述业务的业务端口表， 其中， 所述业务端口表中 包括承载所述业务的端内系统序列和 /或端口序列； 选择单元， 设置为根据所述业务端口表中的承载所述业务的端内系统和 / 或端口的顺序，选择状态为可用的且所述顺序在先的端内系统和 /或端口作为所 述业务的当前承载端内系统和 /或端口；
第一更新单元， 设置为更新所述业务的当前承载端口的端口业务表。
20. 根据权利要求 16至 19中任一项所述的装置， 其中， 所述确定模块包括：
第二更新单元， 设置为在检测到本端内系统的端口不可用后， 更新所述不 可用端口的状态为不可用， 并获取所述不可用端口的端口业务表；
第一确定单元， 设置为将所述端口业务表中包含的业务确定为受所述事件 影响的业务。
21. 根据权利要求 20所述的装置， 其特征在于其中， 所述确定模块还包括：
第一接收单元，用于设置为接收所述 DRNI端点内的其他端内系统的通告， 其中， 所述通告用于指示所述其他端内系统的端口不可用；
所述第二更新单元， 还用于更新保存的所述其他端内系统的所述端口的状 态为不可用， 并获取所述不可用端口的端口业务表；
所述第一确定单元， 还用于将所述端口业务表中包含的业务确定为受所述 事件影响的业务。
22. 根据权利要求 16至 19中任一项所述的装置，其特征在于，所述确定模块包括： 第三更新单元， 用于在检测到与所述 DRNI端点内的相邻端内系统的连接 信息丢失后，且所述检测到连接信息丢失的端内系统保持加入聚合组的情况下， 更新保存的所述相邻端内系统的端口状态为不可用， 并获取所述不可用端口的 端口业务表；
第二确定单元， 用于将所述端口业务表中包括的业务确定为受所述事件影 响的业务。
23. 根据权利要求 16至 19中任一项所述的装置， 其特征在于， 所述确定模块还包 括- 第四更新单元， 用于在检测到本端内系统的端口由不可用恢复为可用后， 更新所述端口的状态为可用；
优先级检测单元， 用于检测所述 DRNI端点内当前承载端口不是第一优先 端口的业务； 比较单元， 用于比较所述恢复为可用端口与所述业务的当前承载端口在承 载所述业务的端内系统序列和 /或端口序列中的位置关系，并在所述恢复为可用 端口比所述业务的当前承载端口处于优先位置的情况下， 将所述业务确定为受 所述事件影响的业务。 根据权利要求 21所述的装置， 其特征在于， 所述确定模块还包括：
第二接收单元，用于接收所述 DRNI端点内的其他端内系统的通告，其中， 所述通告用于指示所述其他端内系统的端口可用；
所述第四更新单元还用于更新保存的所述其他端内系统的所述端口的状态 为可用；
所述优先级检测单元还用于检测所述 DRNI端点内当前承载端口不是第一 优先端口的业务；
所述比较单元还用于比较所述恢复为可用端口与所述业务的当前承载端口 在承载所述业务的端内系统序列和 /或端口序列中的位置关系，并在所述恢复为 可用端口比所述业务的当前承载端口处于优先位置的情况下， 将所述业务确定 为受所述事件影响的业务。
PCT/CN2013/087863 2012-12-14 2013-11-26 分布式弹性网络互连的业务承载方法及装置 Ceased WO2014090083A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210543785.8 2012-12-14
CN201210543785.8A CN103873336B (zh) 2012-12-14 2012-12-14 分布式弹性网络互连的业务承载方法及装置

Publications (1)

Publication Number Publication Date
WO2014090083A1 true WO2014090083A1 (zh) 2014-06-19

Family

ID=50911479

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/087863 Ceased WO2014090083A1 (zh) 2012-12-14 2013-11-26 分布式弹性网络互连的业务承载方法及装置

Country Status (2)

Country Link
CN (1) CN103873336B (zh)
WO (1) WO2014090083A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109088752A (zh) * 2018-07-25 2018-12-25 新华三技术有限公司 内部控制链路端口动态配置方法及相关装置

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9813290B2 (en) * 2014-08-29 2017-11-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for supporting distributed relay control protocol (DRCP) operations upon misconfiguration
CN105991344A (zh) * 2015-04-17 2016-10-05 杭州迪普科技有限公司 一种数据同步方法及装置
CN108173757B (zh) * 2017-12-26 2020-08-11 新华三技术有限公司 端口状态设置方法及装置
CN108337159B (zh) * 2018-01-31 2021-05-28 新华三技术有限公司 端口操作控制方法及装置
CN110708275B (zh) 2018-12-18 2020-11-06 新华三技术有限公司 一种协议报文的处理方法和装置
CN110086657B (zh) * 2019-04-10 2020-04-03 北京华三通信技术有限公司 一种配置同步方法及装置
CN110351127B (zh) * 2019-06-28 2022-06-28 迈普通信技术股份有限公司 一种优雅重启的方法、设备及系统
CN110380910B (zh) * 2019-08-07 2022-02-25 河北远东通信系统工程有限公司 一种实现调度终端双网口自动检测和切换的方法
CN111835560B (zh) * 2020-06-29 2024-02-09 新华三信息安全技术有限公司 一种分布式弹性网络互连系统及其部署方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101277219A (zh) * 2007-03-28 2008-10-01 日本电气株式会社 通信装置、通信系统及其使用的lag管理表管理方法
CN101595691A (zh) * 2007-01-31 2009-12-02 阿尔卡特朗讯公司 使用机架间备份连接的涉及冗余远端情境的伪线连通性
CN102006222A (zh) * 2010-11-16 2011-04-06 中兴通讯股份有限公司 一种业务链路切换方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100438498C (zh) * 2005-01-17 2008-11-26 华为技术有限公司 以太网设备堆叠方法及其系统
CN100481773C (zh) * 2005-04-12 2009-04-22 富士通株式会社 用于链路聚合组管理的分配调整方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101595691A (zh) * 2007-01-31 2009-12-02 阿尔卡特朗讯公司 使用机架间备份连接的涉及冗余远端情境的伪线连通性
CN101277219A (zh) * 2007-03-28 2008-10-01 日本电气株式会社 通信装置、通信系统及其使用的lag管理表管理方法
CN102006222A (zh) * 2010-11-16 2011-04-06 中兴通讯股份有限公司 一种业务链路切换方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109088752A (zh) * 2018-07-25 2018-12-25 新华三技术有限公司 内部控制链路端口动态配置方法及相关装置
CN109088752B (zh) * 2018-07-25 2022-02-11 新华三技术有限公司 内部控制链路端口动态配置方法及相关装置

Also Published As

Publication number Publication date
CN103873336B (zh) 2019-04-23
CN103873336A (zh) 2014-06-18

Similar Documents

Publication Publication Date Title
WO2014090083A1 (zh) 分布式弹性网络互连的业务承载方法及装置
CN103780407B (zh) 分布式弹性网络互连(drni)中网关动态切换方法和装置
CN101710877B (zh) 基于伪线的业务流量处理方法、设备和系统
US8750096B2 (en) Method and apparatus for improving data integrity during a router recovery process
CN100527716C (zh) 主备网关设备状态切换后业务恢复的方法及网关设备
CN109672619A (zh) 一种处理报文的方法、设备及系统
CN100512292C (zh) 一种实时恢复业务的装置及方法
WO2012000234A1 (zh) 链路间快速切换的方法、装置和系统
CN102780635B (zh) 基于trill网络实现保护倒换的方法、tor交换机及系统
EP2424186B1 (en) Dual-computer hot-standby method, device and system
WO2012159489A1 (zh) 一种伪线双归网络的切换方法、系统和双归属运营商设备
EP3217608B1 (en) Switchback delay methods and devices
WO2011157130A2 (zh) 路径建立方法和装置
KR20150007623A (ko) 패킷 전달 시스템에서의 보호 절체 방법 및 장치
WO2012171378A1 (zh) 解决vpls接入l3故障切换导致断流的方法及路由器
CN102984014A (zh) 数据发送方法及网络系统
CN103457817B (zh) 一种pw+l3vpn的保护方法和系统
EP2658177B1 (en) Method for detecting tunnel faults and traffic engineering node
CN105490937A (zh) 以太虚拟网络网关切换方法和服务商边缘节点设备
CN102857316A (zh) 一种实现源环网保护的方法及系统
WO2011120360A1 (zh) 集中式网络节点中实现热备份的方法及系统
CN103138957A (zh) 一种业务路径回切的方法、设备及系统
CN102045239B (zh) 点到多点伪线保护网络的实现方法及装置
CN104202184A (zh) 一种快速回切业务的方法和装置
CN103414591A (zh) 一种端口故障恢复时的快速收敛方法和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13862495

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13862495

Country of ref document: EP

Kind code of ref document: A1