WO2018214731A1 - Netconf会话状态检测 - Google Patents

Netconf会话状态检测 Download PDF

Info

Publication number
WO2018214731A1
WO2018214731A1 PCT/CN2018/086162 CN2018086162W WO2018214731A1 WO 2018214731 A1 WO2018214731 A1 WO 2018214731A1 CN 2018086162 W CN2018086162 W CN 2018086162W WO 2018214731 A1 WO2018214731 A1 WO 2018214731A1
Authority
WO
WIPO (PCT)
Prior art keywords
netconf
controller
session
switching device
state
Prior art date
Application number
PCT/CN2018/086162
Other languages
English (en)
French (fr)
Inventor
王汉
Original Assignee
新华三技术有限公司
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 新华三技术有限公司 filed Critical 新华三技术有限公司
Priority to JP2020514315A priority Critical patent/JP6931781B2/ja
Priority to EP18805699.8A priority patent/EP3605954B1/en
Priority to US16/609,384 priority patent/US11843534B2/en
Publication of WO2018214731A1 publication Critical patent/WO2018214731A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/344—Out-of-band transfers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV

Definitions

  • This application relates to state detection of a Network Configuration (NETCONF) session.
  • NETCONF Network Configuration
  • NETCONF is a configuration protocol based on eXtensible Markup Language (XML).
  • XML eXtensible Markup Language
  • FIG. 1 is a schematic flowchart of a NETCONF session state detection method provided by the present application.
  • FIG. 1A is a schematic flowchart of an OpenFlow connection state between a detection controller and a switching device in the method shown in FIG. 1.
  • FIG. 1B is a schematic flowchart of sending a message to a switching device to obtain NETCONF session information based on the SOAP over HTTPS mode in the method shown in FIG.
  • FIG. 2 is a schematic diagram of an application networking of the method shown in FIG. 1.
  • FIG. 3 is a schematic diagram of a first process provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a second process provided by an embodiment of the present application.
  • FIG. 5 is a structural diagram of a device provided by the present application.
  • FIG. 6 is a structural diagram of hardware of a device provided by the present application.
  • NETCONF is a configuration protocol based on eXtensible Markup Language (XML).
  • XML eXtensible Markup Language
  • the controller can send a NETCONF message to the switching device based on the NETCONF session to perform network configuration on the switching device, which simplifies the configuration operation of the network administrator and implements more flexible and Convenient network configuration.
  • the NETCONF session between the controller and the switching device may be abnormal, and the controller cannot deliver the network configuration to the switching device.
  • NETCONF In the NETCONF protocol, a short connection method based on the Secure Socket Layer (SSL) Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) may be selected.
  • SSL Secure Socket Layer
  • HTTPS Hypertext Transfer Protocol over Secure Socket Layer
  • NETCONF can use the Simple Object Access Protocol (SOAP) over HTTPS, a short HTTPS-based connection.
  • SOAP Simple Object Access Protocol
  • the NETCONF connection in the SOAP over HTTPS mode can complete the keep-alive mechanism by means of timed heartbeat detection. The following may be referred to as timing heartbeat detection.
  • the timing heartbeat detection may be specifically: the controller uses the authentication token (obtained when establishing the NETCONF session) to obtain the NETCONF session information on the switching device in a fixed time period, and if the NETCONF session information is successfully obtained, the controller and the controller are considered.
  • the NETCONF session between the switching devices is normal, and the switching device is in the active state. If the NETCONF session information is not successfully obtained, and the NETCONF session information is not successfully obtained N times (N value is 3), It is considered that there is a problem with the NETCONF session between the controller and the switching device, and it is determined that the switching device is in an inactive state.
  • the controller may send a network configuration to the switching device; and after determining that the switching device is in an inactive state, the network configuration may be prohibited from being delivered to the switching device.
  • the manner in which the controller periodically obtains NETCONF session information from the switching device can work well when the controller manages a small number of switching devices, and can provide reliable device connectivity information.
  • the NETCONF session information is periodically executed on the switching device according to the SOAP over HTTPS mode.
  • an HTTPS connection needs to be established between the controller and the switching device, and the HTTPS connection is frequently established. It may cause the controller's operating system port number to be quickly occupied and the allocation cannot continue.
  • Openflow is a communication interface standard between the controller and the forwarding layer defined in the Software Defined Network (SDN) architecture. OpenFlow allows the controller to directly access and operate the forwarding plane of the switching device. These switching devices may be physical or virtual.
  • SDN Software Defined Network
  • OpenFlow allows the controller to directly access and operate the forwarding plane of the switching device. These switching devices may be physical or virtual.
  • the idea of OpenFlow is to separate the control plane and the data plane. The data plane is forwarded in a stream-based manner, and the standard protocol communication is used between the data plane and the control plane.
  • FIG. 1 is a schematic flowchart of a NETCONF session state detection method provided by the present application.
  • the process is applied to the controller.
  • the NETCONF session is established between the controller and the switching device.
  • the NETCONF session between the controller and the switching device may be established according to the connection manner defined by the NETCONF protocol, and the establishing process may generally include: the controller (as the NETCONF client) sends the switching device (as the NETCONF server)
  • the hello packet in the NETCONF protocol the hello packet carries the username and password.
  • the switching device authenticates the username and password carried in the hello packet.
  • the NETCONF session between the controller and the switching device is successfully established, and the switching device returns an authentication token to the controller. Subsequently, any message in the NETCONF protocol sent by the controller to the switching device carries the authentication token to indicate its identity. On the other hand, when the authentication fails, the controller periodically resends the hello message in the NETCONF protocol to request to establish a NETCONF session.
  • the NETCONF session state detection method may include the following steps:
  • step 101 the controller detects an OpenFlow connection between the controller and the switching device.
  • the Openflow connection in step 101 can be established based on the following manner: the controller sends a NETCONF message to the switching device, the NETCONF message carrying an Openflow configuration, so that the switching device can initiate an Openflow connection to the controller by using the Openflow configuration.
  • the controller receives an OpenFlow connection request initiated by the switching device, and establishes an OpenFlow connection between the controller and the switching device based on the Openflow connection request.
  • the Openflow configuration may include an IP address of the controller, and the like.
  • multiple NETCONF sessions can be established between the controller and the switching device, but session state detection can be performed only for one NETCONF session.
  • the NETCONF session described in steps 102 through 103 refers to a NETCONF session that detects session state. When it is confirmed that the NETCONF session is abnormal, it may be considered that an abnormality occurs in multiple NETCONF sessions established between the controller and the switching device.
  • the NETCONF session is hosted on the same physical link as the Openflow connection.
  • the controller may detect an OpenFlow connection between the controller and the switching device based on a TCP-based heartbeat keep-alive mechanism provided by the Openflow protocol itself.
  • the TCP-based heartbeat keep-alive mechanism can be considered as a heartbeat keep-alive mechanism based on long-connection.
  • the process of establishing an HTTPS connection can be omitted, and the interaction can be directly performed. Data, which can effectively save performance overhead.
  • the TCP-based heartbeat keep-alive mechanism detects an OpenFlow connection between the controller and the switching device, which may include:
  • step 101a1 an OpenFlow connection detection message is sent through an OpenFlow connection.
  • the OpenFlow connection detection message may be an echo request (Request) message in the Openflow protocol.
  • Request echo request
  • Step 101a2 If the response packet of the OpenFlow connection detection packet is received within a set time after the sending of the OpenFlow connection detection packet, the OpenFlow connection is determined to be normal. Otherwise, the OpenFlow connection is determined to be abnormal.
  • the OpenFlow connection detection packet is an echo request packet in the OpenFlow protocol
  • the corresponding response packet is an echo reply packet.
  • step 101a2 determines that the Openflow connection is normal, if the previously recorded Openflow connection is abnormal, it means that the state of the Openflow connection changes from abnormal to normal.
  • the Openflow connection changes from abnormal to normal and can be recorded as an Openflow connection activation (DATAPATH_CONNECT) event.
  • step 101a2 determines that the Openflow connection is abnormal, if the previously recorded Openflow connection is normal, it means that the state of the Openflow connection changes from normal to abnormal.
  • the Openflow connection changes from normal to abnormal and can be recorded as an Openflow Connection Disconnect (DATAPATH_DISCONNECT) event.
  • Step 102 When it is detected that the state of the OpenFlow connection changes, the controller sends a message for acquiring session information of the NETCONF session to the switching device.
  • the sending, by the controller, the message for acquiring the session information of the NETCONF session to the switching device may include: the controller sending, to the switching device, the acquiring the NETCONF session according to the SOAP over HTTPS mode.
  • the message that the foregoing controller sends the session information for acquiring the NETCONF session to the switching device based on the SOAP over HTTPS mode may include the following steps.
  • step 102b1 the authentication token obtained when the NETCONF session is established is carried in the NETCONF packet.
  • the NETCONF message here may be a get-sessions message in the NETCONF protocol.
  • the get-sessions message can be used to determine if the NETCONF session is normal. The reason why the get-sessions message is selected is that the get-sessions message has less content than other messages in the NETCONF protocol. Those skilled in the art can also select other messages in the NETCONF protocol as needed.
  • step 102b2 the NETCONF packet is carried in the SOAP packet.
  • step 102b3 an HTTPS connection is established between the controller and the switching device, and the SOAP packet is sent to the switching device through the HTTPS connection, so as to trigger the switching device to return the session information of the NETCONF session according to the authentication token.
  • the controller is configured to establish a HTTPS connection between the controller and the switching device, and the SOAP packet is sent to the switching device through the HTTPS connection, so as to trigger the switching device to return the session information of the NETCONF session according to the authentication token.
  • the sending of the NETCONF message to the switching device by the SOAP over HTTPS method can be implemented in the foregoing steps 102b1 to 102b3.
  • the message for obtaining the session information of the NETCONF session to the switching device based on the SOAP over HTTPS mode is triggered by the state change of the Openflow connection.
  • This is equivalent to the detection of the NETCONF session state caused by changes in the Openflow connection.
  • the Openflow connection is a long connection, and the heartbeat keep-alive mechanism based on the change of the OpenFlow connection state is compared with the synchronous heartbeat detection method based on the short connection-based SOAP over HTTPS, which eliminates the process of establishing a connection and can directly interact. Data, which can effectively save performance overhead.
  • Step 103 If the session information is not obtained within the preset duration, the controller determines that the NETCONF session is abnormal. If the session information is obtained within a preset duration, the controller determines that the NETCONF session is normal.
  • the switching device when it is determined that the NETCONF session is abnormal, it may be further determined that the switching device is in an inactive state.
  • the Openflow connection changes from abnormal to normal, and it is determined that the NETCONF session is normal, it may be determined that the switching device is in an active state.
  • the Openflow connection changes from normal to abnormal, and it is determined that the NETCONF session is normal, it may be determined that the switching device is in an inactive state. Since the status of the Openflow connection and the NETCONF session between the switching device and the controller should be the same under normal circumstances, there will be no inconsistency. To prevent misconfiguration, the status of the Openflow connection and the NETCONF session are inconsistent. By default, the switching device is inactive. Based on this, although the NETCONF session is determined to be normal in this example, because the Openflow connection is abnormal, that is, the state of the Openflow connection and the NETCONF session between the switching device and the controller are inconsistent, it is determined that the switching device is inactive. status.
  • the state of the Openflow connection and the NETCONF session between the switching device and the controller should be the same. Based on this, when the status of the Openflow connection and the NETCONF session are inconsistent, for example, the Openflow connection changes from abnormal to normal, and the NETCONF session is abnormal, or the Openflow connection changes from normal to abnormal, and the NETCONF session is determined to be normal.
  • the NETCONF session can be closed to facilitate the re-establishment of the NETCONF session so that the state of the Openflow connection and the NETCONF session can be agreed as much as possible.
  • the abnormality of the OpenFlow connection may be an abnormality of the physical link or an abnormality of the end device of the OpenFlow connection.
  • the present application is not specifically limited.
  • the physical link here can carry an Openflow connection and a NETCONF session for performing NETCONF session state detection.
  • the configuration when it is determined that the switching device is in an inactive state, the configuration may be prohibited from being delivered to the switching device.
  • the configuration may be delivered to the switching device.
  • FIG. 2 is a schematic diagram of an application networking of the method shown in FIG. 1 provided by the present application.
  • the networking shown in FIG. 2 can include controller 210 and switch 220. Both controller 210 and switch 220 support Openflow. Controller 210 is used to control and manage switch 220. FIG. 2 shows only one switch 220 as an example.
  • the controller 210 sends a hello packet in the NETCONF protocol to the switch 220 (as the NETCONF server) as a NETCONF client.
  • the hello packet carries the username and password.
  • the switch 220 After receiving the hello packet, the switch 220 authenticates the username and password carried in the hello packet. If the authentication is successful, it means that the NETCONF session between the controller 210 and the switch 220 is successfully established, and the switch 220 returns the authentication token to the controller 210.
  • the controller 210 receives and saves the authentication token returned by the switch 220, and carries the Openflow configuration in the NETCONF message and sends it to the switch 220.
  • the switch 220 creates an OpenFlow instance locally based on the Openflow configuration in the received NETCONF message, and sends a hello message in the Openflow protocol to the controller 210 based on the IP address of the controller 210 carried in the Openflow configuration.
  • the hello packet sent by the switch 220 carries the version of the Openflow protocol supported by the switch 220.
  • the controller 210 When the controller 210 receives the hello packet sent by the switch 220, it may mean that the version of the Openflow protocol supported by the controller 210 matches (the same or is compatible with) the version of the Openflow protocol supported by the switch 220 carried by the hello packet. The controller 210 negotiates successfully with the version of the Openflow protocol supported by the switch 220. In this case, the Openflow connection between the controller 210 and the switch 220 is successfully established and can operate normally.
  • the controller 210 can consider that the Openflow connection between the controller 210 and the switch 220 has never changed from use to start normal use.
  • the OpenFlow connection can be detected between the controller 210 and the switch 220 based on the TCP heartbeat protection mechanism, which can be described as follows:
  • the controller 210 can send an echo request message in the Openflow protocol to the switch 220 through an OpenFlow connection with the switch 220.
  • the switch 220 can return an echo reply message to the controller 210 through an OpenFlow connection with the controller 210. If the controller 210 receives the echo reply message returned by the switch 220 within the set time, it is determined that the OpenFlow connection between the controller 210 and the switch 220 is normal. In this case, since the previous establishment of the Openflow connection is equivalent to the Openflow connection being normal, it can be determined that the Openflow connection between the controller 210 and the switch 220 remains normal, that is, no state change occurs.
  • the controller 210 determines that the OpenFlow connection between the controller 210 and the switch 220 is abnormal. In this case, because the OpenFlow connection is established before the OpenFlow connection is normal, if it is determined that the OpenFlow connection between the controller 210 and the switch 220 is abnormal, the controller 210 determines that the controller 210 and the switch 220 are The OpenFlow connection between the two changes from normal to abnormal, which can perform the flow shown in Figure 4 below.
  • the controller 210 can send an echo request message in the Openflow protocol to the switch 220 through an OpenFlow connection with the switch 220. After receiving the echo request message, the switch 220 can return an echo reply message to the controller 210 through an OpenFlow connection with the controller 210. If the controller 210 receives the echo reply message returned by the switch 220 within the set time, it is determined that the OpenFlow connection between the controller 210 and the switch 220 is normal. In this case, if the last Openflow connection detection period detects that the Openflow connection between the controller 210 and the switch 220 is normal, it can be determined that the Openflow connection between the controller 210 and the switch 220 remains normal, that is, no state occurs. Variety. However, if the last Openflow connection detection period detects an OpenFlow connection abnormality between the controller 210 and the switch 220, it can be determined at this time that the OpenFlow connection between the controller 210 and the switch 220 changes from abnormal to normal.
  • the controller 210 determines that the OpenFlow connection between the controller 210 and the switch 220 is abnormal. In this case, if the last Openflow connection detection period detects an OpenFlow connection abnormality between the controller 210 and the switch 220, it can be determined that the Openflow connection between the controller 210 and the switch 220 remains abnormal, that is, no state occurs. Variety. However, if the last Openflow connection detection period detects that the OpenFlow connection between the controller 210 and the switch 220 is normal, then it can be determined that the Openflow connection between the controller 210 and the switch 220 changes from normal to abnormal.
  • the controller 210 determines that the OpenFlow connection between the present controller 210 and the switch 220 changes from abnormal to normal, the flow shown in FIG. 3 below can be performed.
  • the controller 210 determines that the OpenFlow connection between the present controller 210 and the switch 220 has changed from normal to abnormal, the flow shown in FIG. 4 below can be performed.
  • the flow shown in FIG. 3 is executed by the controller 210 when it is determined that the OpenFlow connection between the controller 210 and the switch 220 changes from abnormal to normal.
  • step 301 an HTTPS connection is established between the controller 210 and the switch 220.
  • step 302 the controller 210 carries the stored authentication token acquired in the NETCONF session to the get-sessions message in the NETCONF protocol, and sends the get-sessions message as the BODY element of the SOAP message over the HTTPS connection.
  • step 303 after receiving the SOAP message, the switch 220 verifies the authentication token carried in the get-sessions message in the SOAP message. If the verification succeeds, the switch 220 returns the current related switch 220 and the controller 210 through the HTTPS connection.
  • the NETCONF session is normally associated with the NETCONF session information to the controller 210.
  • the current NETCONF session information about the NETCONF session between the switch 220 and the controller 210 is returned to the controller 210 through the HTTPS connection.
  • the switch 220 may carry the NETCONF session information in the NETCONF.
  • the rpc-reply message is sent to the controller 210 as an BODY element of the SOAP message over the HTTPS connection.
  • the specificity of the NETCONF session information returned to the controller 210 is not limited in this application, and can be set by a person skilled in the art according to actual needs.
  • step 304 if the controller 210 receives the NETCONF session information returned by the switch 220 for a predetermined period of time, it determines that the NETCONF session between the controller 210 and the switch 220 is normal. In this case, it can be determined that the switch 220 is in an active state.
  • step 305 if the controller 210 does not receive the NETCONF session information returned by the switch 220 for a predetermined period of time, it determines that the NETCONF session between the controller 210 and the switch 220 is abnormal. In this case, it can be determined that the switch 220 is in an inactive state.
  • the flow shown in FIG. 3 is executed when the Openflow connection changes from abnormal to normal, and thus, in step 305, when the controller 210 determines that the NETCONF session between the present controller 210 and the switch 220 is abnormal, it means The state of the Openflow connection between the controller 210 and the switch 220 and the NETCONF session are inconsistent. For this inconsistency, as described above, the NETCONF session can be closed to cause the NETCONF session to be re-established.
  • the process shown in FIG. 4 is performed by the controller 210 when it is determined that the OpenFlow connection between the controller 210 and the switch 220 changes from normal to abnormal.
  • step 401 an HTTPS connection is established between the controller 210 and the switch 220.
  • step 402 the controller 210 carries the stored authentication token acquired during the establishment of the NETCONF session in the get-sessions message in the NETCONF protocol, and sends the get-sessions message as the BODY element of the SOAP message over the HTTPS connection.
  • step 403 the switch 220 verifies the authentication token carried in the get-sessions message in the SOAP message after receiving the SOAP message, and if the verification succeeds, returns the current relationship between the local switch 220 and the controller 210 through the HTTPS connection.
  • the NETCONF session is normally associated with the NETCONF session information to the controller 210.
  • the current NETCONF session information about the NETCONF session between the switch 220 and the controller 210 is returned to the controller 210 through the HTTPS connection.
  • the switch 220 may carry the NETCONF session information in the NETCONF.
  • the Rpc-reply message in the protocol the Rpc-reply message is sent to the controller 210 as an BODY element of the SOAP message over the HTTPS connection.
  • step 404 if the controller 210 receives the NETCONF session information returned by the switch 220 within the set duration, it determines that the NETCONF session between the controller 210 and the switch 220 is normal. In this case, it can be determined that the switch 220 is in an inactive state.
  • Step 405 If the controller 210 does not receive the NETCONF session information returned by the switch 220 within the set duration, the controller 210 determines that the NETCONF session between the controller 210 and the switch 220 is abnormal. In this case, it can be determined that the switch 220 is in an inactive state.
  • step 404 when the controller 210 determines that the NETCONF session between the present controller 210 and the switch 220 is normal, it means control.
  • the state of the Openflow connection between the device 210 and the switch 220 and the NETCONF session are inconsistent. Therefore, for this inconsistency, the NETCONF session can be closed to perform the operation of reestablishing the NETCONF session.
  • step 405 when the controller 210 determines that the NETCONF session between the present controller 210 and the switch 220 is abnormal, it means The state of the Openflow connection and the NETCONF session between the controller 210 and the switch 220 is the same. For this consistent situation, the Openflow connection can continue to be detected, and when it is detected that the Openflow connection transitions from abnormal to normal, the flow shown in FIG. 3 above is executed.
  • FIG. 5 is a structural diagram of a device provided by the present application.
  • the device can be applied to controllers that support Openflow.
  • a NETCONF session can be established between the controller and the switching device.
  • the apparatus can include an Openflow module 501 and a NETCONF module 502.
  • the Openflow module 501 is configured to detect an OpenFlow Openflow connection between the controller and the switching device, and send a notification to the NETCONF module 502 when detecting that the status of the Openflow connection changes.
  • the NETCONF module 502 can be configured to send a message for acquiring session information of the NETCONF session to the switching device in response to receiving a notification from the Openflow module 501. Moreover, if the session information is not obtained within a preset duration, the NETCONF module 502 may determine that the NETCONF session is abnormal. If the session information is obtained within a preset duration, the NETCONF module 502 may determine the NETCONF. The session is normal.
  • the NETCONF module 502 may determine that the switching device is in an inactive state when determining that the NETCONF session is abnormal.
  • the NETCONF module 502 may determine that the switching device is in an active state when the Openflow connection changes from abnormal to normal, and determines that the NETCONF session is normal; and, when the Openflow connection changes from normal When it is abnormal, and it is determined that the NETCONF session is normal, it is determined that the switching device is in an inactive state.
  • the NETCONF module 502 when the Openflow connection changes from abnormal to normal and determines that the NETCONF session is abnormal, or when the Openflow connection changes from normal to abnormal and determines that the NETCONF session is normal, The NETCONF session can be closed to facilitate the re-establishment of the NETCONF session.
  • the sending, by the NETCONF module 502, the message for acquiring the session information of the NETCONF session to the switching device may include: the NETCONF module 502 carrying the authentication token acquired when establishing the NETCONF session in the NETCONF Transmitting the NETCONF message in the Simple Object Access Protocol (SOAP) packet; establishing an HTTPS connection between the controller and the switching device, and sending the SOAP packet to the switching device by using an HTTPS connection. And to trigger the switching device to return session information of the NETCONF session according to the authentication token to the controller.
  • SOAP Simple Object Access Protocol
  • the present application also provides a hardware structure diagram of the apparatus shown in FIG. 5.
  • the hardware structure can include a processor 601, a machine readable storage medium 602 that stores machine executable instructions.
  • Processor 601 and machine readable storage medium 602 can communicate via system bus 603. And, by reading and executing the machine executable instructions in the machine readable storage medium 602 corresponding to the NETCONF session state detection logic, the processor 601 can perform the NETCONF session state detection method described above.
  • the machine-readable storage medium 602 referred to herein can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like.
  • the machine-readable storage medium may be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as a hard disk drive), solid state drive, any type of storage disk. (such as a disc, DVD, etc.), or a similar storage medium, or a combination thereof.
  • machine readable storage medium comprising machine executable instructions, such as machine readable storage medium 602 of FIG. 6, the processor executable instructions being operative by a processor in a NETCONF session state detecting device 601 is executed to implement the NETCONF session state detection method described above.
  • the processor 601 can perform the operations in the above NETCONF session state detecting method by calling and executing machine executable instructions corresponding to the NETCONF session state detecting logic in the machine readable storage medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请提供了用于检测NETCONF会话状态的方法和装置。根据所述方法的一个示例，NETCONF连接的检测是由Openflow连接的变化引起的。在控制器与交换设备之间建立有NETCONF会话的情况下，如果控制器检测到所述控制器与所述交换设备之间的开放流Openflow连接的状态发生变化，则所述控制器向所述交换设备发送用于获取所述NETCONF会话的会话信息的报文。并且，若在预设时长内未获取到所述会话信息，则确定所述NETCONF会话异常；若在预设时长内获取到所述会话信息，则确定所述NETCONF会话正常。

Description

NETCONF会话状态检测
相关申请的交叉引用
本专利申请要求于2017年5月26日提交的、申请号为201710383893.6、发明名称为“NETCONF会话状态检测方法和装置”的中国专利申请的优先权，该申请的全文以引用的方式并入本文中。
背景技术
本申请涉及网络配置(Network Configuration，NETCONF)会话的状态检测。
NETCONF是一种基于可扩展标记语言(eXtensible Markup Language，XML)的配置协议。在控制器和交换设备之间建立NETCONF会话后，控制器可基于NETCONF会话向交换设备下发NETCONF消息以对交换设备进行网络配置，这简化了网络管理员的配置操作，实现了更为灵活和方便的网络配置。
附图说明
图1为本申请提供的NETCONF会话状态检测方法的示意性流程图。
图1A为图1所示方法中检测控制器与交换设备之间的Openflow连接状态的示意性流程图。
图1B为图1所示方法中基于SOAP over HTTPS方式向交换设备发送报文以获取NETCONF会话信息的示意性流程图。
图2为图1所示方法的应用组网示意图。
图3为本申请实施例提供的第一流程示意图。
图4为本申请实施例提供的第二流程示意图。
图5为本申请提供的装置结构图。
图6为本申请提供的装置硬件结构图。
具体实施方式
NETCONF是一种基于可扩展标记语言(eXtensible Markup Language，XML)的配 置协议。在控制器和交换设备之间建立NETCONF会话后，控制器可基于NETCONF会话向交换设备下发NETCONF消息以对交换设备进行网络配置，这简化了网络管理员的配置操作，实现了更为灵活和方便的网络配置。但是，因为链路故障、交换设备故障等原因，控制器和交换设备之间的NETCONF会话可能会出现异常，则控制器不能向交换设备下发网络配置。
NETCONF协议中，可选用基于安全套接层(Secure Socket Layer，SSL)的超文本传输协议(Hyper Text Transfer Protocol over Secure Socket Layer，HTTPS)的短连接方式。例如，NETCONF可选用简单对象访问协议(Simple Object Access Protocol，SOAP)over HTTPS这一种基于HTTPS的短连接方式。并且，SOAP over HTTPS方式的NETCONF连接可通过定时心跳检测的方式完成保活机制，以下可简称为定时心跳检测。
其中，定时心跳检测可具体为：控制器以一个固定的时间周期使用认证令牌(建立NETCONF会话时获取的)到交换设备上获取NETCONF会话信息，如果成功获取NETCONF会话信息，则认为控制器和交换设备之间的NETCONF会话正常，并确定交换设备处于激活状态；如果未成功获取NETCONF会话信息，且截至当前已经是连续N次(N取值比如为3)都未能成功获取NETCONF会话信息，则认为控制器和交换设备之间的NETCONF会话出现问题，并确定交换设备处于非激活状态。控制器在确定交换设备处于激活状态之后，可向所述交换设备下发网络配置；而在确定交换设备处于非激活状态之后，则可禁止向所述交换设备下发网络配置。
上述控制器定时到交换设备上获取NETCONF会话信息的方式，在控制器管理少量交换设备的时候能够工作良好，可提供可靠的设备连通性信息。
然而，随着控制器管理交换设备的数量越来越多，定时到交换设备上获取NETCONF会话信息的方式带来的开销和性能压力会越来越大，甚至可能影响正常的业务运行。原因是：定时到交换设备上获取NETCONF会话信息是按照SOAP over HTTPS方式执行的，每次到交换设备上获取NETCONF会话信息之前需要在控制器和交换设备之间建立HTTPS连接，而频繁建立HTTPS连接可能会引发控制器的操作系统端口号很快被占用完，进而无法继续分配。
为了解决上述问题，本申请提供了一种NETCONF会话状态的检测方法，其基于Openflow的辅助实现NETCONF会话检测。Openflow是软件定义网络(Software Defined Network，SDN)架构中定义的控制器与转发层之间的通信接口标准。OpenFlow允许控制器直接访问和操作交换设备的转发平面。这些交换设备可能是物理的，也可能是虚拟 的。OpenFlow的思想是分离控制平面和数据平面，数据平面采用基于流的方式进行转发，数据平面和控制平面之间使用标准的协议通信。
下面对本申请提供的使用Openflow辅助NETCONF会话状态检测的方法进行描述：
参见图1，图1为本申请提供的NETCONF会话状态检测方法的示意性流程图。如图1所示，该流程应用于控制器。其中，控制器与交换设备之间建立有NETCONF会话。作为一个实施例，控制器与交换设备之间的NETCONF会话可按照NETCONF协议定义的连接方式建立，并且建立过程可大致包括：控制器(作为NETCONF客户端)向交换设备(作为NETCONF服务端)发送NETCONF协议中的hello报文，hello报文携带用户名、密码；该交换设备收到该hello报文后，对该hello报文携带的用户名、密码进行认证；若成功认证，则意味着该控制器与该交换设备之间的NETCONF会话建立成功，该交换设备返回认证令牌给该控制器。后续，该控制器向该交换设备发送的NETCONF协议中的任何报文都携带该认证令牌以表明自身身份。反之，当认证失败时，该控制器会定时重新发送NETCONF协议中的hello报文请求建立NETCONF会话。
如图1所示，根据本申请实施例提供的NETCONF会话状态检测方法可包括以下步骤：
步骤101，控制器检测本控制器与交换设备之间的Openflow连接。
作为一个实施例，步骤101中的Openflow连接可基于以下方式建立：控制器向交换设备发送NETCONF消息，该NETCONF消息携带Openflow配置，以使得该交换设备可利用该Openflow配置向该控制器发起Openflow连接请求；该控制器接收该交换设备发起的Openflow连接请求，基于该Openflow连接请求在本控制器与该交换设备之间建立Openflow连接。作为一个实施例，Openflow配置可包括控制器的IP地址等。
在本实施例中，控制器与交换设备之间可建立有多个NETCONF会话，但可只针对一个NETCONF会话进行会话状态检测。步骤102至步骤103描述的NETCONF会话是指检测会话状态的NETCONF会话。当确认该NETCONF会话异常时，可认为控制器与交换设备之间建立有的多个NETCONF会话均发生异常。其中，该NETCONF会话与Openflow连接承载在同一物理链路上。
作为一个实施例，控制器可基于Openflow协议自身提供的基于TCP的心跳保活机制，来检测本控制器与交换设备之间的Openflow连接。基于TCP的心跳保活机制可认为是基于长连接的一种心跳保活机制，其相比于基于短连接的SOAP over HTTPS的定 时心跳检测方式，省去了建立HTTPS连接的过程，可以直接交互数据，从而可以有效节省性能开销。
具体地，如图1A所示，基于TCP的心跳保活机制检测上述控制器与交换设备之间的Openflow连接可包括：
步骤101a1，通过Openflow连接发送Openflow连接检测报文。
作为一个实施例，Openflow连接检测报文可为Openflow协议中的echo请求(Request)报文。
步骤101a2，若在发送所述Openflow连接检测报文之后的设定时间内接收到所述Openflow连接检测报文的响应报文，则确定所述Openflow连接正常，否则，确定所述Openflow连接异常。
作为一个实施例，若Openflow连接检测报文为Openflow协议中的echo Request报文，则对应的响应报文为echo Reply报文。
当步骤101a2确定Openflow连接正常时，如果之前记录的Openflow连接异常，则意味着Openflow连接的状态从异常变化为正常。Openflow连接从异常变化为正常可记为Openflow连接激活(DATAPATH_CONNECT)事件。
当步骤101a2确定Openflow连接异常时，如果之前记录的Openflow连接正常，则意味着Openflow连接的状态从正常变化为异常。Openflow连接从正常变化为异常可记为Openflow连接断开(DATAPATH_DISCONNECT)事件。
步骤102，当检测到Openflow连接的状态发生变化时，控制器向交换设备发送用于获取所述NETCONF会话的会话信息的报文。
作为一个实施例，步骤102中，控制器向交换设备发送用于获取所述NETCONF会话的会话信息的报文可包括：控制器基于SOAP over HTTPS方式向交换设备发送用于获取所述NETCONF会话的会话信息的报文，以获取NETCONF会话的会话信息。
作为一个实施例，如图1B所示，上述控制器基于SOAP over HTTPS方式向交换设备发送用于获取所述NETCONF会话的会话信息的报文可包括如下步骤。
步骤102b1，将建立NETCONF会话时获取的认证令牌携带在NETCONF报文。
作为一个实施例，这里的NETCONF报文可为NETCONF协议中的获取会话信息(get-sessions)消息。get-sessions消息可用于确定NETCONF会话是否正常。之所以选 取get-sessions消息，其原因是get-sessions消息相比NETCONF协议中的其他消息，内容比较少。本领域技术人员也可以根据需求选择NETCONF协议中的其他消息。
步骤102b2，将NETCONF报文携带在SOAP报文中。
步骤102b3，在本控制器与所述交换设备之间建立HTTPS连接，通过HTTPS连接将SOAP报文发送给交换设备，以触发所述交换设备根据所述认证令牌返回所述NETCONF会话的会话信息给控制器。
通过步骤102b1至步骤102b3，能够实现上述通过SOAP over HTTPS方式向交换设备发送NETCONF报文。
通过上面步骤101和步骤102描述可以看出，基于SOAP over HTTPS方式向交换设备发送用于获取NETCONF会话的会话信息的报文，是由Openflow连接的状态变化触发的。这相当于，NETCONF会话状态的检测是由Openflow连接的变化引起的。并且，如上描述，Openflow连接是一种长连接，基于Openflow连接状态变化的心跳保活机制相比于基于短连接的SOAP over HTTPS的定时心跳检测方式，省去了建立连接的过程，可以直接交互数据，从而可以有效节省性能开销。
步骤103，若在预设时长内未获取到所述会话信息，则控制器确定所述NETCONF会话异常，若在预设时长内获取到所述会话信息，则控制器确定所述NETCONF会话正常。
至此，完成图1所示流程。
作为一个实施例，当确定NETCONF会话异常时，可进一步确定交换设备处于非激活状态。
作为一个实施例，若所述Openflow连接从异常变化为正常，且确定所述NETCONF会话正常，则可确定交换设备处于激活状态。
作为一个实施例，若所述Openflow连接从正常变化为异常，且确定所述NETCONF会话正常，则可确定所述交换设备处于非激活状态。由于正常情况下，交换设备与控制器之间的Openflow连接、NETCONF会话的状态应该是一致的，不会出现不一致的情况。为防止错误配置，针对Openflow连接、NETCONF会话的状态不一致的情况，可默认交换设备处于非激活状态。基于此，在本例中虽然确定所述NETCONF会话正常，但因为Openflow连接异常，即交换设备与控制器之间的Openflow连接、NETCONF会话的状态是不一致的，所以确定所述交换设备处于非激活状态。
如上描述，正常情况下，交换设备与控制器之间的Openflow连接、NETCONF会话的状态应该是一致的。基于此，当Openflow连接、NETCONF会话的状态不一致时，例如Openflow连接从异常变化为正常、并确定所述NETCONF会话异常时，或者所述Openflow连接从正常变化为异常、并确定所述NETCONF会话正常时，可关闭所述NETCONF会话，以促使NETCONF会话的重建，从而可以尽可能使Openflow连接、NETCONF会话的状态达成一致。
其中，Openflow连接异常可为物理链路异常，或者Openflow连接的端设备异常等，本申请并不具体限定。这里的物理链路可承载Openflow连接和用于执行NETCONF会话状态检测的NETCONF会话。
作为一个实施例，当确定交换设备处于非激活状态时，可禁止向所述交换设备下发配置。
作为一个实施例，当确定所述交换设备处于激活状态时，可向所述交换设备下发配置。
下面通过一个具体实施例对图1所示流程进行描述：
参见图2，图2为本申请提供的图1所示方法的应用组网示意图。图2所示的组网可包含控制器210和交换机220。控制器210和交换机220均支持Openflow。控制器210用于控制和管理交换机220。图2仅示出一个交换机220为例。
如图2所示，控制器210作为NETCONF客户端向交换机220(作为NETCONF服务端)发送NETCONF协议中的hello报文，hello报文携带用户名、密码。
交换机220收到hello报文后，对hello报文携带的用户名、密码进行认证。若成功认证，则意味着控制器210与交换机220之间的NETCONF会话建立成功，则交换机220返回认证令牌给控制器210。
控制器210接收并保存交换机220返回的认证令牌，并将Openflow配置携带在NETCONF消息中发送给交换机220。
交换机220基于接收的NETCONF消息中的Openflow配置在本地创建Openflow实例，并基于Openflow配置携带的控制器210的IP地址向控制器210发送Openflow协议中的hello报文。交换机220发送的hello报文中携带交换机220支持的Openflow协议版本。
当控制器210接收交换机220发送的hello报文时，若发现本控制器210支持的Openflow协议版本与该hello报文携带的交换机220所支持的Openflow协议版本匹配(相同或者兼容)，则可意味着控制器210与交换机220所支持的Openflow协议版本协商成功，在这种情况下，控制器210与交换机220之间的Openflow连接成功建立，可以正常运行。
当控制器210与交换机220之间的Openflow连接成功建立，可以正常运行时，则控制器210可认为本控制器210与交换机220之间的Openflow连接从未使用变化至开始正常使用。
当控制器210与交换机220之间成功建立Openflow连接后，控制器210与交换机220之间可基于TCP的心跳保护机制检测Openflow连接，具体可描述为如下：
在首个Openflow连接检测周期，控制器210可通过与交换机220之间的Openflow连接向交换机220发送Openflow协议中的echo Request报文。当交换机220接收到该echo Request报文后，可通过与控制器210之间的Openflow连接向控制器210返回echo Reply报文。若控制器210在设定时间内接收到交换机220返回的echo Reply报文，则确定本控制器210与交换机220之间的Openflow连接正常。在这种情况下，因为之前建立Openflow连接相当于Openflow连接正常，可确定控制器210与交换机220之间的Openflow连接维持正常，即没有发生状态变化。
反之，在首个Openflow连接检测周期，若控制器210在设定时间内未接收到交换机220返回的echo Reply报文，则确定本控制器210与交换机220之间的Openflow连接异常。在这种情况下，因为之前建立Openflow连接相当于Openflow连接正常，此时若确定本控制器210与交换机220之间的Openflow连接异常，则相当于控制器210确定本控制器210与交换机220之间的Openflow连接从正常变为异常，其可执行下文的图4所示流程。
在非首个Openflow连接检测周期，控制器210可通过与交换机220之间的Openflow连接向交换机220发送Openflow协议中的echo Request报文。当交换机220接收到该echo Request报文后，可通过与控制器210之间的Openflow连接向控制器210返回echo Reply报文。若控制器210在设定时间内接收到交换机220返回的echo Reply报文，则确定本控制器210与交换机220之间的Openflow连接正常。在这种情况下，如果上个Openflow连接检测周期检测到本控制器210与交换机220之间的Openflow连接正常，则可确定控制器210与交换机220之间的Openflow连接维持正常，即没有发生状态变 化。然而，如果上个Openflow连接检测周期检测到本控制器210与交换机220之间的Openflow连接异常，则此时可确定本控制器210与交换机220之间的Openflow连接从异常变为正常。
反之，在非首个Openflow连接检测周期，若控制器210在设定时间内未接收到交换机220返回的echo Reply报文，则确定本控制器210与交换机220之间的Openflow连接异常。在这种情况下，如果上个Openflow连接检测周期检测到本控制器210与交换机220之间的Openflow连接异常，则可确定控制器210与交换机220之间的Openflow连接维持异常，即没有发生状态变化。然而，如果上个Openflow连接检测周期检测到本控制器210与交换机220之间的Openflow连接正常，则此时可确定本控制器210与交换机220之间的Openflow连接从正常变为异常。
当控制器210在确定本控制器210与交换机220之间的Openflow连接从异常变为正常时，可执行下文的图3所示流程。另一方面，当控制器210在确定本控制器210与交换机220之间的Openflow连接从正常变为异常时，可执行下文的图4所示流程。
图3所示流程是控制器210在确定本控制器210与交换机220之间的Openflow连接从异常变化为正常时执行的，其具体为：
在步骤301中，控制器210与交换机220之间建立HTTPS连接。
在步骤302中，控制器210将已存储的建立NETCONF会话时获取的认证令牌携带在NETCONF协议中的get-sessions消息，将get-sessions消息作为SOAP报文的BODY元素通过HTTPS连接发送。
在步骤303中，交换机220收到SOAP报文后会验证SOAP报文中get-sessions消息携带的认证令牌，若验证通过，则交换机220通过上述HTTPS连接返回当前有关本交换机220与控制器210之间NETCONF会话正常的相关NETCONF会话信息给控制器210。
作为一个实施例，上述步骤303中，通过HTTPS连接返回当前有关本交换机220与控制器210之间NETCONF会话正常的相关NETCONF会话信息给控制器210具体可为：交换机220将NETCONF会话信息携带在NETCONF协议中的响应(rpc-reply)消息中，将rpc-reply消息作为SOAP报文的BODY元素通过HTTPS连接发送给控制器210。
至于返回给控制器210的NETCONF会话信息具体是什么，在本申请并不限定，本 领域技术人员可以根据实际需求设置。
在步骤304中，控制器210若在预定时长收到交换机220返回的NETCONF会话信息，则确定本控制器210与交换机220之间的NETCONF会话正常。在这种情况下，可确定交换机220处于激活状态。
在步骤305中，控制器210若在预定时长未收到交换机220返回的NETCONF会话信息，则确定本控制器210与交换机220之间的NETCONF会话异常。在这种情况下，可确定交换机220处于非激活状态。
如上描述，图3所示流程是在Openflow连接从异常变为正常时执行的，如此，在步骤305中，当控制器210确定本控制器210与交换机220之间的NETCONF会话异常时，则意味着控制器210与交换机220之间的Openflow连接、NETCONF会话的状态是不一致的。针对该不一致的情况，如上描述，可关闭NETCONF会话，以促使重建NETCONF会话。
至此，完成图3所示流程。
图4所示流程是控制器210在确定本控制器210与交换机220之间的Openflow连接从正常变为异常时执行的，其可具体包括：
在步骤401中，控制器210与交换机220之间建立HTTPS连接。
在步骤402中，控制器210将已存储的建立NETCONF会话时获取的认证令牌携带在NETCONF协议中的get-sessions消息，将get-sessions消息作为SOAP报文的BODY元素通过HTTPS连接发送。
在步骤403中，交换机220在收到SOAP报文后验证SOAP报文中get-sessions消息携带的认证令牌，若验证通过，则通过上述HTTPS连接返回当前有关本交换机220与控制器210之间NETCONF会话正常的相关NETCONF会话信息给控制器210。
作为一个实施例，上述步骤403中，通过HTTPS连接返回当前有关本交换机220与控制器210之间NETCONF会话正常的相关NETCONF会话信息给控制器210具体可为：交换机220将NETCONF会话信息携带在NETCONF协议中的Rpc-reply消息中，将Rpc-reply消息作为SOAP报文的BODY元素通过HTTPS连接发送给控制器210。
在本申请中，至于返回给控制器的NETCONF会话信息具体是什么，在本申请并不限定，本领域技术人员可以根据实际需求设置。
在步骤404中，控制器210若在设定时长内收到交换机220返回的NETCONF会话信息，则确定本控制器210与交换机220之间的NETCONF会话正常。在这种情况下，可确定交换机220处于非激活状态。
步骤405，控制器210若在设定时长内未收到交换机220返回的NETCONF会话信息，则确定本控制器210与交换机220之间的NETCONF会话异常。在这种情况下，可确定交换机220处于非激活状态。
因为图4所示流程是在Openflow连接从正常变为异常时执行的，如此，在步骤404中，当控制器210确定本控制器210与交换机220之间的NETCONF会话正常时，则意味着控制器210与交换机220之间的Openflow连接、NETCONF会话的状态是不一致的。因此，针对该不一致的情况，则可关闭NETCONF会话，以执行重建NETCONF会话的操作。
如上描述，图4所示流程是在Openflow连接从正常变为异常时执行的，如此，在步骤405中，当控制器210确定本控制器210与交换机220之间的NETCONF会话异常时，则意味着控制器210与交换机220之间的Openflow连接、NETCONF会话的状态是一致的。针对该一致的情况，可继续检测Openflow连接，并当检测到所述Openflow连接从异常转换为正常时，返回执行上述图3所示流程。
至此，完成图4所示流程。
参见图5，图5为本申请提供的装置结构图。该装置可应用于支持Openflow的控制器。该装置应用于控制器时，所述控制器与交换设备之间可建立有NETCONF会话。如图5所示，该装置可包括Openflow模块501和NETCONF模块502。
Openflow模块501，可用于检测所述控制器与所述交换设备之间的开放流Openflow连接，当检测到所述Openflow连接的状态发生变化时，发送通知给NETCONF模块502。
NETCONF模块502，可用于响应于接收到来自Openflow模块501的通知，向所述交换设备发送用于获取所述NETCONF会话的会话信息的报文。并且，若在预设时长内未获取到所述会话信息，则NETCONF模块502可确定所述NETCONF会话异常，若在预设时长内获取到所述会话信息，则NETCONF模块502可确定所述NETCONF会话正常。
作为一个实施例，所述NETCONF模块502在确定所述NETCONF会话异常时，可确定所述交换设备处于非激活状态。
作为一个实施例，所述NETCONF模块502在所述Openflow连接从异常变化为正常，且确定所述NETCONF会话正常时，可确定所述交换设备处于激活状态；以及，在所述Openflow连接从正常变化为异常，且确定所述NETCONF会话正常时，确定所述交换设备处于非激活状态。
作为一个实施例，所述NETCONF模块502在所述Openflow连接从异常变化为正常且确定所述NETCONF会话异常时，或者，在所述Openflow连接从正常变化为异常且确定所述NETCONF会话正常时，可关闭所述NETCONF会话，以促使NETCONF会话的重建。
作为一个实施例，所述NETCONF模块502向交换设备发送用于获取所述NETCONF会话的会话信息的报文可包括：所述NETCONF模块502将建立所述NETCONF会话时获取的认证令牌携带在NETCONF报文，将所述NETCONF报文携带在简单对象访问协议SOAP报文中；在本控制器与所述交换设备之间建立HTTPS连接，通过HTTPS连接将所述SOAP报文发送给所述交换设备，以触发所述交换设备根据所述认证令牌返回所述NETCONF会话的会话信息给所述控制器。
至此，完成图5所示装置的描述。
对应地，本申请还提供了图5所示装置的硬件结构图。如图6所示，该硬件结构可包括处理器601、存储有机器可执行指令的机器可读存储介质602。处理器601与机器可读存储介质602可经由系统总线603通信。并且，通过读取并执行机器可读存储介质602中与NETCONF会话状态检测逻辑对应的机器可执行指令，处理器601可执行上文描述的NETCONF会话状态检测方法。
本文中提到的机器可读存储介质602可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、DVD等)，或者类似的存储介质，或者它们的组合。
至此，完成图6所示的硬件结构描述。
在本申请中，还提供了一种包括机器可执行指令的机器可读存储介质，例如图6中的机器可读存储介质602，所述机器可执行指令可由NETCONF会话状态检测装置中的处理器601执行以实现以上描述的NETCONF会话状态检测方法。
具体地，通过调用并执行机器可读存储介质中与NETCONF会话状态检测逻辑对应的机器可执行指令，处理器601可执行以上NETCONF会话状态检测方法中的操作。
以上所述仅为本申请的实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (15)

  1. 一种检测网络配置NETCONF会话状态的方法，包括：
    控制器检测所述控制器与交换设备之间的开放流Openflow连接，其中，所述控制器与所述交换设备之间建立有NETCONF会话；
    当检测到所述Openflow连接的状态发生变化时，所述控制器向所述交换设备发送用于获取所述NETCONF会话的会话信息的报文；
    若在预设时长内未获取到所述会话信息，则所述控制器确定所述NETCONF会话异常；
    若在预设时长内获取到所述会话信息，则所述控制器确定所述NETCONF会话正常。
  2. 根据权利要求1所述的方法，还包括：
    若确定所述NETCONF会话异常，则所述控制器确定所述交换设备处于非激活状态。
  3. 根据权利要求1所述的方法，还包括：
    若检测到所述Openflow连接从异常状态变化为正常状态，且确定所述NETCONF会话正常，则所述控制器确定所述交换设备处于激活状态。
  4. 根据权利要求1所述的方法，还包括：
    若检测到所述Openflow连接从正常状态变化为异常状态，且确定所述NETCONF会话正常，则所述控制器确定所述交换设备处于非激活状态。
  5. 根据权利要求1所述的方法，还包括：
    若检测到所述Openflow连接从异常状态变化为正常状态，且确定所述NETCONF会话异常，则所述控制器关闭所述NETCONF会话。
  6. 根据权利要求1所述的方法，还包括：
    若检测到所述Openflow连接从正常状态变化为异常状态，且确定所述NETCONF会话正常，则所述控制器关闭所述NETCONF会话。
  7. 根据权利要求1所述的方法，其特征在于，向所述交换设备发送用于获取所述NETCONF会话的会话信息的报文包括：
    所述控制器将建立所述NETCONF会话时获取的认证令牌携带在NETCONF报文，
    所述控制器将所述NETCONF报文携带在简单对象访问协议SOAP报文中；
    所述控制器在本控制器与所述交换设备之间建立HTTPS连接，
    所述控制器通过所述HTTPS连接将所述SOAP报文发送给所述交换设备。
  8. 一种检测网络配置NETCONF会话状态的装置，该装置应用于控制器，该装置包括：
    处理器；和
    存储有机器可执行指令的机器可读存储介质，
    通过执行所述机器可执行指令，所述处理器被促使：
    检测所述控制器与交换设备之间的开放流Openflow连接，其中所述控制器与所述交换设备之间建立有NETCONF会话；
    当检测到所述Openflow连接的状态发生变化时，向所述交换设备发送用于获取所述NETCONF会话的会话信息的报文，
    若在预设时长内未获取到所述会话信息，则确定所述NETCONF会话异常，
    若在预设时长内获取到所述会话信息，则确定所述NETCONF会话正常。
  9. 根据权利要求8所述的装置，其特征在于，所述机器可执行指令还促使所述处理器：
    在确定所述NETCONF会话异常时，进一步确定所述交换设备处于非激活状态。
  10. 根据权利要求8所述的装置，其特征在于，所述机器可执行指令还促使所述处理器：
    在检测到所述Openflow连接从异常状态变化为正常状态，且确定所述NETCONF会话正常时，确定所述交换设备处于激活状态。
  11. 根据权利要求8所述的装置，其特征在于，所述机器可执行指令还促使所述处理器：
    在检测到所述Openflow连接从正常状态变化为异常状态，且确定所述NETCONF会话正常时，确定所述交换设备处于非激活状态。
  12. 根据权利要求8所述的装置，其特征在于，所述机器可执行指令还促使所述处理器：
    在检测到所述Openflow连接从异常状态变化为正常状态，且确定所述NETCONF会话异常时，关闭所述NETCONF会话。
  13. 根据权利要求8所述的装置，其特征在于，所述机器可执行指令还促使所述处理器：
    在检测到所述Openflow连接从正常状态变化为异常状态，且确定所述NETCONF会话正常时，关闭所述NETCONF会话。
  14. 根据权利要求8所述的装置，其特征在于，在向所述交换设备发送用于获取所 述NETCONF会话的会话信息的报文，所述机器可执行指令促使所述处理器：
    将建立所述NETCONF会话时获取的认证令牌携带在NETCONF报文，
    将所述NETCONF报文携带在简单对象访问协议SOAP报文中；
    在所述控制器与所述交换设备之间建立HTTPS连接，
    通过所述HTTPS连接将所述SOAP报文发送给所述交换设备。
  15. 一种机器可读存储介质，存储有机器可执行指令，控制器通过执行所述机器可执行指令被促使：
    检测所述控制器与交换设备之间的开放流Openflow连接，其中所述控制器与所述交换设备之间建立有NETCONF会话；
    当检测到所述Openflow连接的状态发生变化时，向所述交换设备发送用于获取所述NETCONF会话的会话信息的报文，
    若在预设时长内未获取到所述会话信息，则确定所述NETCONF会话异常，
    若在预设时长内获取到所述会话信息，则确定所述NETCONF会话正常。
PCT/CN2018/086162 2017-05-26 2018-05-09 Netconf会话状态检测 WO2018214731A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2020514315A JP6931781B2 (ja) 2017-05-26 2018-05-09 Ｎｅｔｃｏｎｆセッション状態の検出方法、装置及びコンピュータ読取可能な記録媒体
EP18805699.8A EP3605954B1 (en) 2017-05-26 2018-05-09 State detection of netconf session
US16/609,384 US11843534B2 (en) 2017-05-26 2018-05-09 State detection of NETCONF session

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710383893.6 2017-05-26
CN201710383893.6A CN108259213B (zh) 2017-05-26 2017-05-26 Netconf会话状态检测方法和装置

Publications (1)

Publication Number Publication Date
WO2018214731A1 true WO2018214731A1 (zh) 2018-11-29

Family

ID=62721798

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/086162 WO2018214731A1 (zh) 2017-05-26 2018-05-09 Netconf会话状态检测

Country Status (5)

Country Link
US (1) US11843534B2 (zh)
EP (1) EP3605954B1 (zh)
JP (1) JP6931781B2 (zh)
CN (1) CN108259213B (zh)
WO (1) WO2018214731A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113542359A (zh) * 2021-06-17 2021-10-22 聚好看科技股份有限公司 一种线上会议中的终端状态更新方法、装置及电子设备

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109525516B (zh) * 2018-11-16 2021-05-11 盛科网络（苏州）有限公司 通过DHCP通告OpenFlow控制器信息的方法和系统
US10880210B2 (en) * 2018-12-26 2020-12-29 Juniper Networks, Inc. Cloud network having multiple protocols using virtualization overlays across physical and virtualized workloads
CN114221884B (zh) * 2021-11-18 2023-12-26 新华三技术有限公司合肥分公司 心跳报文的订阅方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103841022A (zh) * 2014-03-12 2014-06-04 华为技术有限公司 用于建立隧道的方法及装置
US20140298052A1 (en) * 2013-03-29 2014-10-02 Telefonaktiebolaget L M Ericsson (pubI) Energy efficiency in software defined networks

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008148017A (ja) 2006-12-11 2008-06-26 Hitachi Software Eng Co Ltd ノード検出装置及びプログラム
JP4840236B2 (ja) 2007-04-12 2011-12-21 株式会社日立製作所 ネットワークシステム及びノード装置
CN103001887B (zh) * 2012-11-22 2018-01-05 中兴通讯股份有限公司 一种链路保活方法、控制器及交换机
US9253117B1 (en) * 2012-12-18 2016-02-02 Google Inc. Systems and methods for reducing network hardware of a centrally-controlled network using in-band network connections
CN104113443B (zh) * 2013-04-19 2018-10-02 南京中兴新软件有限责任公司 一种网络设备检测方法、装置及云检测系统
KR101586151B1 (ko) * 2013-08-28 2016-01-18 주식회사 케이티 컨트롤러와 네트워크 장치 간 재연결 방법
CN104580293B (zh) * 2013-10-17 2018-05-25 中国电信股份有限公司 用于远程控制管控策略的方法、装置和系统
CN104639470B (zh) 2013-11-14 2019-05-31 中兴通讯股份有限公司 流标识封装方法及系统
KR20150088559A (ko) * 2014-01-24 2015-08-03 한국전자통신연구원 네트워크의 장애를 복구하는 방법 및 장치
CN104883266B (zh) * 2014-02-28 2018-10-12 新华三技术有限公司 网络配置访问方法及装置
US9419874B2 (en) * 2014-03-27 2016-08-16 Nicira, Inc. Packet tracing in a software-defined networking environment
US9509527B2 (en) 2014-06-30 2016-11-29 Arista Networks, Inc. Method and system for VXLAN encapsulation offload
CN105591804B (zh) * 2015-09-22 2019-02-19 新华三技术有限公司 一种配置改变处理方法及装置
US10666639B2 (en) * 2016-05-20 2020-05-26 Avaya, Inc. Customer-centric workflow for initial on-boarding of an OpenFlow enabled switch

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140298052A1 (en) * 2013-03-29 2014-10-02 Telefonaktiebolaget L M Ericsson (pubI) Energy efficiency in software defined networks
CN103841022A (zh) * 2014-03-12 2014-06-04 华为技术有限公司 用于建立隧道的方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
OPENFLOW MANAGEMENT AND CONFIGURATION PROTOCOL (OF-CONFIG 1.1.1, 23 March 2013 (2013-03-23), XP055550385 *
See also references of EP3605954A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113542359A (zh) * 2021-06-17 2021-10-22 聚好看科技股份有限公司 一种线上会议中的终端状态更新方法、装置及电子设备
CN113542359B (zh) * 2021-06-17 2023-09-05 聚好看科技股份有限公司 一种线上会议中的终端状态更新方法、装置及电子设备

Also Published As

Publication number Publication date
JP2020521409A (ja) 2020-07-16
CN108259213A (zh) 2018-07-06
JP6931781B2 (ja) 2021-09-08
US20200067810A1 (en) 2020-02-27
EP3605954A1 (en) 2020-02-05
US11843534B2 (en) 2023-12-12
CN108259213B (zh) 2020-05-12
EP3605954B1 (en) 2021-07-07
EP3605954A4 (en) 2020-03-25

Similar Documents

Publication Publication Date Title
WO2018214731A1 (zh) Netconf会话状态检测
US7533178B2 (en) Resuming a computing session when rebooting a computing device
EP1914939B1 (en) A method for the triggering failure detection of bidirectional forwarding detection
US20080172582A1 (en) Method and system for providing peer liveness for high speed environments
JP5068495B2 (ja) 分散型認証機能
US10530644B2 (en) Techniques for establishing a communication connection between two network entities via different network flows
WO2019057007A1 (zh) 一种通信连接检测方法及装置
US11128663B2 (en) Synchronizing link and event detection mechanisms with a secure session associated with the link
WO2018121284A1 (zh) 一种处理路由的方法及网络设备
CN107277058B (zh) 一种基于bfd协议的接口认证方法及系统
CN107547368B (zh) Bfd会话切换方法、装置及存储介质
CN107566213B (zh) 一种保活检测方法和装置
US20180227332A1 (en) A method and computer program products for probing the status of an ip-based communication connection in order to receive an incoming communication
US9300642B2 (en) Restarting network reachability protocol sessions based on transport layer authentication
US20110225230A1 (en) Method and apparatus for detecting active and orphan session-based connections
US6915431B1 (en) System and method for providing security mechanisms for securing network communication
US9769140B1 (en) Authentication support for autonomous requests
CN112929417B (zh) 报文处理方法及装置
EP2432167B1 (en) Method and apparatus for implementing point to point remote loopback of ethernet
US11509502B2 (en) Edge device, control method, and program
CN104811426B (zh) 用户代理客户端发送注册请求的方法及用户代理客户端
WO2016082343A1 (zh) 故障检测方法及装置
JP6126062B2 (ja) ネットワーク装置及びネットワーク装置のｍａｃアドレス認証方法
WO2016201973A1 (zh) 一种容灾方法、装置及通信系统
US20240107303A1 (en) Network Nodes and Methods Therein for Facilitating Registration of Terminal Device

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: 18805699

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018805699

Country of ref document: EP

Effective date: 20191023

ENP Entry into the national phase

Ref document number: 2020514315

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE