WO2014139276A1 - 基于开放流协议的控制面设备的发现处理方法及装置 - Google Patents

基于开放流协议的控制面设备的发现处理方法及装置 Download PDF

Info

Publication number
WO2014139276A1
WO2014139276A1 PCT/CN2013/083803 CN2013083803W WO2014139276A1 WO 2014139276 A1 WO2014139276 A1 WO 2014139276A1 CN 2013083803 W CN2013083803 W CN 2013083803W WO 2014139276 A1 WO2014139276 A1 WO 2014139276A1
Authority
WO
WIPO (PCT)
Prior art keywords
plane device
information
openflow
dhcp
control plane
Prior art date
Application number
PCT/CN2013/083803
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 EP13877653.9A priority Critical patent/EP2975807B1/en
Publication of WO2014139276A1 publication Critical patent/WO2014139276A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • 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
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • 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/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow 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
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • 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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0886—Fully automatic configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the present invention relates to the field of communications, and in particular to a method and device for discovering and processing a control plane device based on an OpenFlow (OF) protocol.
  • OF OpenFlow
  • SDN Software Defined Network
  • the design concept is to separate the control plane of the network from the data forwarding plane and implement programmable control.
  • the SDN network architecture abstraction is usually defined as three layers: the first layer is the forwarding plane entity, including various hardware and software components that implement this forwarding function; the second layer is the entity that manages and controls the first layer forwarding entity, The third layer is based on the applications and services of the first two layers of the underlying network.
  • the interface between the first two layers is called the southbound interface of SDN.
  • the OpenFlow protocol is the mainstream protocol of the southbound interface. It is based on the flow table and controls the fine-grained forwarding table and its behavior. It has a strong expression. Ability, adaptability.
  • the OpenFlow protocol is an exchange technology originally proposed by Stanford University. It is based on the existing Transmission Control Protocol (TCP) / Internet Protocol (IP) technical conditions, with innovative The concept of network interconnection solves the shortcomings of the current network.
  • the core idea of the OpenFlow protocol is to transform the packet forwarding process controlled by the switch/router into an OpenFlow forwarding plane device (such as OF Switch, and other protocols that support OpenFlow/OF-Config and
  • the forwarding plane device of the flow table mechanism such as an access point (Access Point (abbreviated as AP), a router) and a control server (for example, OF Controller) respectively perform independent processes, thereby separating data forwarding and routing control.
  • AP Access Point
  • OF Controller OF Controller
  • switches and routers have control rights, but there is no concept of data flow, only packet-level exchange can be performed.
  • the control server will replace the router, and the control server (OF Controller) can control the data transmission path by determining the transmission path of all the data packets in the network through the pre-defined interface operation.
  • the OpenFlow protocol runs on the Transport Layer Security Protocol (TLS) and the unprotected TCP connection. If the OpenFlow forwarding device forwards a packet and encounters a packet with no forwarding path specified, the OpenFlow protocol is used. The device sends an inquiry message to the OpenFlow controller with which the link is established, and the controller determines the forwarding path of the data packet. This requires the OpenFlow forwarding plane device and the Openflow controller to establish a link before the OpenFlow forwarding plane device forwards the packet.
  • the OpenFlow protocol VI.3 version begins to separate the Of-Config protocol, which separates the functions of the SDN forwarding device configuration management and forms a separate channel.
  • the Of-Config protocol can run on the TCP and Secure Socket Layer (Secure Socket Layer).
  • the OpenFlow forwarding device can configure the address of the OpenFlow controller.
  • the OpenFlow forwarding device can dynamically discover the Of-Config management configuration point.
  • the OpenFlow protocol family does not define a corresponding discovery mechanism.
  • the OpenFlow forwarding plane device can only discover OpenFlow control plane devices (including OpenFlow Controller and OpenFlow Configuration Point devices) through static configuration. This method discovers the OpenFlow control plane device mechanism for OpenFlow forwarding plane devices. It is still not perfect enough to operate and maintain a large-scale OpenFlow network.
  • the administrator needs to plan the correspondence between the control plane device and the management control of the forwarding plane device, and forward it in a large amount.
  • the address information of the corresponding control plane device is configured on the device.
  • the forwarding plane device cannot be adaptively adjusted to access the new control plane device.
  • the configuration is more complicated.
  • the embodiment of the present invention provides a method and a device for discovering and processing a control plane device based on the OpenFlow protocol, to solve at least the foregoing. problem.
  • a discovery processing method of a control plane device based on the OpenFlow protocol including: receiving identifier information of a forwarding plane device based on an OpenFlow protocol, where the identifier information is an identifier of a forwarding plane device Information, the identifier information corresponding to the control plane device information in the Management Information Base (MIB); matching the control plane device information in the management information database according to the identifier information; sending the foregoing control to the forwarding device Device information.
  • MIB Management Information Base
  • the method before receiving the foregoing identification information, includes: acquiring, by the SDN, the control plane device information in the specified domain after the domain is pre-domain-divided; and storing the information of each control plane device in the specified domain to the management information database.
  • the foregoing identifier information includes: domain name information of a specified domain to which the forwarding plane device belongs.
  • the above method is applied to a Dynamic Host Configure Protocol (DHCP) device in the SDN.
  • the sending the control plane device information to the forwarding plane device comprises: sending the control plane device information to the forwarding plane device by using a specified field in the DHCP packet.
  • the above specified field includes: an Option field.
  • the method when receiving the identifier information of the forwarding plane device based on the OpenFlow protocol, the method further includes: receiving a request message of the forwarding plane device, where the request message is used to request the DHCP device to allocate an address for the forwarding plane device.
  • the method further includes: receiving a query request message of a network management system (NMS); and transmitting, by the NMS, control device information in the management information database to the SDN by triggering the query request message Other DHCP devices except DHCP devices.
  • NMS network management system
  • a discovery processing apparatus for a control plane device based on an OpenFlow protocol including: a receiving module, configured to receive identification information from a forwarding plane device based on an OpenFlow protocol, where the identification information For the identification information of the forwarding plane device, the identifier information corresponds to the control plane device information in the management information database; the matching module is configured to match the control plane device information in the management information database according to the identifier information; Set to send control plane device information to the forwarding plane device.
  • the foregoing apparatus includes: an obtaining module, configured to acquire information of each control plane device in a specified domain in a software-defined network (SDN), and a storage module, configured to store information of each control plane device in the specified domain to Management information database.
  • SDN software-defined network
  • the technical means for obtaining the control plane device information according to the identification information of the forwarding plane device and transmitting the control plane device information to the forwarding plane device is solved, and in the related art, the forwarding plane is not effectively enabled.
  • the device automatically discovers the technical problem of the control plane device, thereby realizing the automatic discovery of the control plane device by the forwarding plane device, and further enabling the forwarding plane device to adaptively adjust the control plane device.
  • FIG. 1 is a flowchart of a discovery processing method of a control plane device based on an OpenFlow protocol according to Embodiment 1 of the present invention
  • FIG. 2 is a structural block diagram of a discovery processing device of a control plane device based on an OpenFlow protocol according to Embodiment 1 of the present invention
  • 3 is a block diagram of another structure of a discovery processing device for a control plane device based on the OpenFlow protocol according to Embodiment 1 of the present invention
  • FIG. 4 is a schematic flowchart of an automatic discovery of an OpenFlow control plane device for an SDN network according to Embodiment 2 of the present invention
  • 5 is a schematic flowchart of an automatic discovery of an OpenFlow control plane device according to the SDN network according to Embodiment 3 of the present invention
  • FIG. 6 is a schematic flowchart of an SDN network automatically discovering an OpenFlow control plane device according to Embodiment 4 of the present invention
  • FIG. 8 is a schematic diagram of an option of an OpenFlow control plane device for automatically reporting an OpenFlow control plane device according to an embodiment of the present invention
  • FIG. 8 is a schematic diagram of an option Option A for an OpenFlow device to report device information according to an embodiment of the present invention
  • FIG. 9 is a schematic diagram of an OpenFlow control plane sent by a DHCPv4 according to an embodiment of the present invention.
  • FIG. 10 is a diagram of the present invention OpenFlow control plane information sent to device forwarding plane extended options OptionB2 schematic apparatus in DHCPv6 embodiment.
  • FIG. 1 is a flowchart of a discovery processing method of a control plane device based on the OpenFlow protocol according to Embodiment 1 of the present invention.
  • the method includes: Step S102, receiving the identification information of the forwarding plane device based on the OpenFlow protocol, where the identifier information is the identifier information of the forwarding plane device, where the identifier information corresponds to the control plane device information in the MIB.
  • Step S104 according to the identifier information.
  • the control plane device information is obtained by matching in the MIB; and in step S106, the control plane device information is sent to the forwarding plane device.
  • the above-mentioned various processing steps are used to automatically match the control plane device information according to the information of the forwarding plane device corresponding to the control plane device information and send the information to the forwarding plane device.
  • the way of the device therefore, the automatic discovery of the control plane device by the forwarding plane device can be realized.
  • the control plane device information may be separately managed. Specifically, before receiving the identifier information, each control plane in the specified domain in the SDN is pre-domain-divided. The device information stores the information of each control plane device in the specified domain to the management information database.
  • the foregoing identification information may include, but is not limited to, domain name information of the specified domain that belongs to the forwarding plane device.
  • the foregoing method may be, but is not limited to, being applied to a network device in an SDN.
  • the control plane device information can be sent to the forwarding plane device through the specified field in the DHCP packet.
  • the specified fields include but are not limited to: Option field.
  • the request message of the forwarding plane device may be received, where the request message is used to request the DHCP (including the DHCPv4 and DHCPv6) devices as the forwarding plane device. Assign an address.
  • the query request message of the network management system NMS may also be received; and the management information database is used by the NMS under the trigger of the query request message.
  • the control plane device information is sent to other DHCP devices in the SDN other than the above DHCP device.
  • a discovery processing device for the control plane device based on the OpenFlow protocol is also provided, which is used to implement the foregoing embodiments and preferred embodiments, and has not been described again.
  • the module is explained.
  • the term "module" may implement a combination of software and/or hardware of a predetermined function.
  • FIG. 2 is a structural block diagram of a discovery processing apparatus of a control plane device based on an OpenFlow protocol according to Embodiment 1 of the present invention.
  • the device includes: The receiving module 20 is connected to the matching module 22, and configured to receive the identification information of the forwarding plane device based on the OpenFlow protocol, where the identifier information is the identification information of the forwarding plane device, and the control information in the identifier information and the management information database
  • the matching module 22 is connected to the sending module 24, and is configured to match the control plane device information in the management information database according to the foregoing identification information; and the sending module 24 is configured to send the control plane device information to the forwarding plane device. .
  • the automatic discovery of the control plane device by the forwarding plane device can also be realized. In this embodiment, as shown in FIG.
  • the foregoing apparatus may further include the following modules: an obtaining module 26, connected to the storage module 28, configured to acquire information of each control plane device in a specified domain after pre-domain division in the SDN; Module 28 is configured to store information of each control plane device in the specified domain to a management information database.
  • an obtaining module 26 connected to the storage module 28, configured to acquire information of each control plane device in a specified domain after pre-domain division in the SDN
  • Module 28 is configured to store information of each control plane device in the specified domain to a management information database.
  • Embodiment 2 The purpose of this embodiment is to provide a method for automatically discovering an OpenFlow control plane device by using an SDN network, which can simplify the network configuration of the OpenFlow, improve the mechanism of the device for discovering the control plane of the OpenFlow network forwarding device, and make the OpenFlow network more intelligent. Improve the maintainability of OpenFlow networks.
  • the main design idea of this embodiment is to automatically learn the Openflow control plane device in the DHCP management domain by using the DHCP interaction process on the DHCP device (DHCP Server ⁇ DHCP Proxy DHCP Relay Agent, etc.) on the control plane of the SDN network, and automatically learn the As a result, it is stored in a management information database (MIB) maintained locally, and these OpenFlow control plane devices are managed in a domain.
  • MIB management information database
  • the DHCP device When the OpenFlow forwarding plane device requests an IP address from the DHCP server, the DHCP device matches the storage entry in the local MIB according to the domain name information in the OpenFlow forwarding device reporting option, and the matching result (the OpenFlow control available in the same management domain of the SDN network)
  • the device information list is advertised to the OpenFlow forwarding device through the Option option in the DHCP packet, so that it can select the appropriate OpenFlow control plane device to establish the link according to its own needs, and implement the OpenFlow control plane device to automatically discover the OpenFlow control plane device.
  • the DHCP device provides, manages, and maintains a MIB data table.
  • the data table of the management information base mainly manages device information such as OpenFlow forwarding plane devices, OpenFlow Controller, and OpenFlow Configuration Point in the OpenFlow network, and the MIB data.
  • the table can be modified locally by command.
  • the automatic learning modification can also be triggered by the NMS remote modification or the DHCP protocol module.
  • the entry of the entry field includes the device role, device address, domain name, device unique identifier, device management load, and information source.
  • the meanings of the fields in the MIB data table are as follows: Device Role (Role): Describe whether the device is an OpenFlow forwarding plane device (0), OpenFlow Controller (1) or OpenFlow Configuration Point (2).
  • IP address The southbound interface of the OpenFlow device establishes an IP address, which can be an IPv4 or IPv6 address.
  • Domain Name Indicates the administrative domain to which the OpenFlow device belongs. When the domain name string is empty, it is processed by the default domain name.
  • the administrator of the SDN network can plan the management domain of the network according to the device manufacturer classification, service type, or virtual operator classification, and manage the different devices in the network.
  • the domain name can be statically configured when the device is shipped from the factory, or configured by the local management interface. After being connected to the management network, the device can be dynamically configured and modified by the OpenFlow control plane.
  • Device unique identifier A globally unique identifier that characterizes a device.
  • a recommended string is a specific encoding format.
  • Device management load It is valid only for OpenFlow control plane devices. It indicates the metric data for managing device load. It can be the percentage of OpenFlow links and the number of full-load links, and can also integrate other indicators. These metric data can be dynamically updated by these OpenFlow control plane devices.
  • the OpenFlow forwarding plane device preferentially selects a lightly loaded control plane device to build a chain without prioritization.
  • Source of Information Indicates the reason for the generation of a data table record, such as NMS remote configuration, local configuration, and automatic learning. These generation reasons can be set with a certain priority. For example, the local configuration takes precedence over the NMS remote configuration, and the NMS remote configuration takes precedence over the automatic learning. Of course, this priority relationship can be configured.
  • a data table record that generates a cause can generally only be deleted by a delete action of the same information source, unless the data table record is replaced by a data table record of the same device with a higher priority.
  • the MIB data table can be queried by the NMS. After the NMS learns the record automatically learned by the MIB data table of the DHCP device, the NMS can send the records to other DHCP devices in the SDN to implement a discovery mechanism for managing the network across the DHCP device. It can be seen that the DHCP device in this solution is no longer simply performing or proxying the address allocation, and also implements unified management of the SDN network devices in its management category, so this can process DHCP messages and execute network nodes.
  • the information management device may also be some gateway devices, including a Broadband Network Gateway (BNG).
  • BNG Broadband Network Gateway
  • Step S402 After the OpenFlow control plane device 1 is started, the DHCP Discover message in the DHCP protocol carries the extended option Option A, and the information such as the role and the domain name Domain1 is reported. If it does not need to obtain an address through DHCP, it may carry the information itself. The address is applied for. In essence, it only reports its own device information to the DHCP device through the DHCP message to form an MIB data table entry. After the DHCP device responds to the DHCP request, it adds a device information record to the MIB data table.
  • BNG Broadband Network Gateway
  • the subsequent load change of the OpenFlow control plane device 1 can be dynamically updated to the DHCP device MIB data by the option of renewing the lease or the specific DHCP type packet carrying OptionA. table.
  • the OpenFlow control plane device 1 releases the address
  • the DHCP Release message carries the extended option OptionA
  • the DHCP device deletes the corresponding device record in the local MIB information table.
  • Step S404 After the OpenFlow control plane device 2 is started, the DHCP Discover message in the DHCP protocol carries the extended option Option A to report the role of the device and the domain name Domai n 2 and the like.
  • the DHCP device adds a new device information record to the MIB data table in the same manner as in step 1.
  • Step S406 After the OpenFlow forwarding plane device 1 starts normal, the DHCP in the DHCP protocol is adopted.
  • the Option A in the Discover domain is reported to the domain name Domain1 and obtains the IP address.
  • the DHCP device informs the OpenFlow forwarding device 1 of the address assigned by the DHCP device, and carries the special option OptionB to match the MIB data table record to the OpenFlow control plane device of Domain1.
  • the information list is sent to the OpenFlow forwarding plane device 1 so that it discovers the OpenFlow control plane device 1.
  • the OpenFlow forwarding plane device 1 starts to try to establish a chain with the OpenFlow control plane device 1.
  • the DHCP Release message carries the extended option OptionA, and the DHCP device deletes the corresponding device record in the local MIB information table.
  • Step S408 After the OpenFlow forwarding plane device 2 starts normal, the domain name Domai n 2 is reported by the option in the DHCP Discover in the DHCP protocol, and the IP address is obtained. Then, the OpenFlow control plane device 2 is found in the same manner as in step 3, and the attempt to establish a chain with the OpenFlow control plane device 2 is started. When the OpenFlow forwarding device 2 releases the address, the DHCP Release message carries the extended option OptionA, and the DHCP device deletes the corresponding device record in the local MIB information table.
  • Step S410 The NMS device queries the DHCP device MIB data table, learns the OpenFlow device information that it learns, and selectively sends the learned OpenFlow control device information to other DHCP devices according to the NMS configuration policy.
  • the DHCP device is also allowed to actively report or replace the MIB data table record learned by itself through a specific interface.
  • the above five steps have no strict timing relationship. Any step may occur first.
  • the OpenFlow forwarding device may not discover any OpenFlow control plane device from the DHCP device when applying for the address for the first time. It can select other discovery methods (for example, Multicast detection, local static configuration) To discover OpenFlow control plane devices in a broadcast domain, you can also delay re-attempting to discover OpenFlow control plane devices from DHCP devices.
  • the DHCP device delivers the OpenFlow forwarding device to the same management domain through Option B.
  • the order of the OpenFlow control plane devices in the list can be used to indicate its priority recommendation. If there are multiple OpenFlow control plane devices, the OpenFlow forwarding plane device will initiate a link establishment request to these devices until it is successfully chained to a suitable OpenFlow control plane device.
  • the management port of the OpenFlow forwarding device (used to initiate the DHCP interaction process and establish the chain after the OpenFlow control plane device is discovered) and the forwarding port should be clearly distinguished.
  • the management port supports protocols such as DHCP/TCP/SSL/OpenFlow. Processing, no flow table or default flow table, and the forwarding port does not need to support these protocols before the configuration of the OpenFlow control plane device.
  • This distinction can be software or firmware difference, or device deployment and local configuration. s Choice.
  • the foregoing solution in this embodiment provides a possibility for the OpenFlow forwarding plane device to automatically discover the OpenFlow control plane device, and makes the deployment of the OpenFlow forwarding plane device and the control plane device in the SDN network more intelligent.
  • the SDN network provided in the following embodiment 3-5 automatically discovers the OpenFlow control plane device.
  • the OpenFlow forwarding device automatically discovers the OpenFlow control plane device by interacting with the DHCP packet of the DHCP device.
  • the device is relatively stable on the OpenFlow control plane. In the network, it can provide good service.
  • the following embodiments 3-5 can be implemented based on the following design ideas: In the SDN, the OpenFlow forwarding plane device can dynamically discover the OpenFlow control plane device through the DHCPv4/DHCPv6 device.
  • the OpenFlow control plane device can report the management information of the device to the DHCPv6 device in the DHCPv6 Solicit message.
  • the DHCPv6 device can deliver the message through the DHCPv6 Advertise or DHCPv6 Reply message. Matching the OpenFlow control plane device information of the OpenFlow forwarding plane device management domain to the OpenFlow forwarding plane device.
  • the SDN network devices learned by the DHCP process on the DHCP device can be triggered and deleted by the DHCP Release messages of these devices.
  • Example 3 This embodiment mainly describes the process in which the OpenFlow forwarding plane device discovers the OpenFlow control plane device through the DHCP server and establishes the link normally in the scenario where the OpenFlow control plane device controller and the configuration point are not separated.
  • the DHCP device is a DHCP server
  • the OpenFlow control plane device is an OpenFlow Controller
  • the OpenFlow forwarding device is an OpenFlow Switch.
  • a separate OpenFlow Configuration Point device is not provided.
  • the OpenFlow Controller performs configuration work and specifically describes the DHCP device-aware SDN. The processing when the network OpenFlow device releases the address or goes offline.
  • the detailed flowchart of the service is shown in Figure 5.
  • Step S502 After the OpenFlow Controller is started, the DHCP Discovery (Discover) packet is sent to the DHCP server (it can carry the existing address request).
  • the Option A In the DHCP Discover message sent by the OF Controller, the Option A carries the field information such as the device role and domain name to the DHCP server.
  • the extended option OptionA format proposal is shown in Figure 8. The packet may also not carry the extended option OptionA, so that the DHCP Request carries the option.
  • Step S504 The DHCP server creates a DHCP user session, and parses the extended option OptionA carried by the OpenFlow control plane device Controller to temporarily store the information on the DHCP server.
  • the DHCP server sends a DHCP feed (Offer) packet carrying the assigned IP address and other configuration information to the OpenFlow Controller.
  • Step S506 The OpenFlow Controller selects an appropriate address, and sends a DHCP request (Request) to the DHCP server for confirmation. If the DHCP Discover message does not carry the Option A, the DHCP Request message must carry the Option A message to report its own information. You are advised to carry the OptionA only in the DHCP Request message.
  • Step S508 After receiving the DHCP Request, the DHCP server parses the information in the Option A, and obtains whether the DHCP server address in the Option 54 field is the same as the self. If the DHCP Request message timeout is abnormal, the step S504 or this step is deleted.
  • Step S510 The NMS queries the MIB data table of the DHCP server, and learns the OpenFlow Controller information learned by the DHCP server.
  • the described actions and the preceding and following steps in this step have no strict timing relationship.
  • the DHCP server is also allowed to actively report the information about the OpenFlow Controller that it has learned through a specific interface.
  • Step S512 The OpenFlow Switch sends a DHCP Discovery packet to the DHCP server to apply for an IP address, and can also carry the Option A message to the DHCP server, but it is not recommended to carry it in the packet.
  • Step S514 The DHCP server sends a DHCP Offer message containing the IP address and other configuration information to the OpenFlow Switch device.
  • Step S516 The OpenFlow Switch sends a DHCP request (Request) message to each DHCP server in a broadcast manner to confirm the information.
  • the DHCP Request message carries the Option A message to report its own information.
  • Step S518 After receiving the DHCP Request message of the OpenFlow Switch, the DHCP server determines whether the IP address of the DHCP server in the Option 54 field is the same as its own. If they are the same, the DHCP server sends a DHCP ACK acknowledgment message containing the IP address and other option information it provides to the OpenFlow Switch. At the same time, the DHCP server parses the OptionA of the DHCP Request message to obtain the OpenFlow Switch device information, and saves it as a record to the MIB data table of the DHCP server. (Adding the record of the OpenFlow Switch device information to the MIB data table is optional.
  • Step S520 After receiving the DHCP Ack packet of the DHCP server, the OpenFlow Switch parses the extended option Option B, and learns the OpenFlow Controller device address of the administrative domain to which it belongs from the option information. The OpenFlow Switch actively attempts to establish a chain with the OpenFlow Controller. Step S522: OpenFlow Controller and OpenFlow Switch After the OpenFlow Switch is successfully established, OpenFlow
  • the OpenFlow Controller renews the lease through the DHCP Request message and carries the option OptionA to update the local MIB data table record of the DHCP server.
  • DHCP Inform packets can also be used to carry the option OptionA to achieve the same effect.
  • Step S524 The OpenFlow Switch releases the address or does not renew the lease in time, the DHCP server reclaims the address, and deletes the record corresponding to the OpenFlow Switch in the local MIB data table.
  • Step S526 The OpenFlow Controller release address is not renewed in time, and the DHCP server reclaims the address and deletes the record corresponding to the OpenFlow Controller in the local MIB data table.
  • Step S528 The NMS queries the MIB data table of the DHCP server, learns the OpenFlow Controller information learned by the DHCP server, and learns the SDN of the OpenFlow Controller learned by the DHCP server. After the device is disabled, the corresponding record on the NMS is deleted, and the configuration that it sends to other DHCP devices is updated. The described actions and the preceding and following steps in this step have no strict timing relationship. As in step S510, the DHCP server is allowed to actively report the OpenFlow Controller information changes learned by the DHCP server through a specific interface.
  • the OpenFlow Controller discovers the OpenFlow Controllers that can be connected to the DHCP server based on the list of OpenFlow Controllers that are sent by the DHCP server.
  • the OpenFlow Controllers can be learned locally by the DHCP server or by the NMS from the DHCP servers of other network management domains. It can also be that the DHCP server is statically configured locally into the MIB data table.
  • Embodiment 4 This embodiment mainly describes a process in which an OpenFlow forwarding plane device discovers an OpenFlow control plane device through a DHCP proxy device and constructs a link normally in a scenario where the OpenFlow control plane device controller and the configuration point are not separated. For ease of description, and only as an example, the dynamic discovery process is described in the embodiment using the DHCPv4 protocol.
  • the DHCP device described in this embodiment is a DHCP proxy, and the back end has a DHCP server.
  • the OpenFlow control plane device is an OpenFlow Controller, and the OpenFlow forwarding plane device is an OpenFlow Switch. In this embodiment, a separate OpenFlow Configuration Point device is not provided.
  • the Controller performs configuration work. This embodiment does not describe the processing flow of the DHCP device when the OpenFlow device releases the address or is offline. For related processes, refer to the related description of Embodiment 3. The service detailed process in this embodiment is shown in Figure 6. Step S602: After the OpenFlow Controller is started, the DHCP Discover message is sent to the DHCP proxy (it can carry the existing address request).
  • Step S604 After receiving the DHCP Discover message, the DHCP proxy that supports learning and managing the SDN network device information creates a DHCP user session, intercepts the extended option OptionA, and reassembles a DHCP Discover unicast message to the DHCP server of the proxy.
  • Step S606 The DHCP server creates a DHCP user session, and sends a DHCP Offer message carrying the assigned IP address and other configuration information to the DHCP proxy (Proxy), which is sent to the OpenFlow Controller by the DHCP proxy.
  • Step S608 The DHCP Proxy forwards the received DHCP Offer message to the OpenFlow Controlle.
  • Step S610 The OpenFlow Controller selects an appropriate address and sends a DHCP Request to the DHCP proxy to confirm. If the DHCP Discover message does not carry the Option A, the DHCP Request message carries the Option A message. You are advised to carry the OptionA only in the DHCP Request message.
  • Step S612 After receiving the DHCP Request message, the DHCP proxy receives and parses the information in the Option A, and obtains whether the DHCP server address in the Option 54 field is consistent with the DHCP server address of the proxy. If the DHCP Request message expires, the DHCP Request message expires. If the fault is abnormal, the information record of the device role, domain name, and the like of the OpenFlow Controller cached in step S604 or in this step is deleted. If they are the same, the DHCP proxy reassembles the DHCP Request unicast packet that does not carry Option Option A to the DHCP server.
  • Step S614 After receiving the DHCP Request, the DHCP server obtains the judgment in the Option 54 field.
  • the DHCP server address is the same as the one. If the DHCP proxy sends a DHCP ACK message to the DHCP server, the DHCP proxy sends the DHCP ACK message to the OpenFlow Controller. Step S616: After receiving the DHCP ACK message, the DHCP proxy sends the OpenFlow Controller information as a record. Enter the local MIB data table of the DHCP proxy and send the packet to the OpenFlow Controller. Step S618: The NMS queries the MIB data table of the DHCP proxy to learn the OpenFlow Controller information learned by the DHCP proxy. The described actions and the preceding and following steps in this step have no strict timing relationship. The DHCP proxy can also actively report the information about the OpenFlow Controller that it learns through a specific interface.
  • Step S620 The OpenFlow Switch sends a DHCP Discover message to the DHCP proxy. It is required to apply for an IP address to the DHCP server.
  • the device can carry the Option A message in the packet, but it is not recommended to carry Option A in the DHCP Discover message.
  • Step S622 After receiving the DHCP Discover message, the DHCP proxy intercepts the Option A, creates a DHCP session, and reassembles a DHCP Discover unicast message to send its proxy DHCP server.
  • Step S624 DHCP server sends a DHCP Offer message to the DHCP Proxy contains IP address and other configuration information, sent on behalf of the DHCP Proxy to OpenFlow Switch 0
  • Step S626 DHCP Proxy receives the DHCP Offer packet forwarding OpenFlow Switch.
  • Step S628 The OpenFlow Switch sends a DHCP Request message to the DHCP proxy to confirm the DHCP Request message.
  • the DHCP Request message carries the Option A message to report its own information.
  • Step S630 After receiving the DHCP Request message of the OpenFlow Switch, the DHCP Proxy determines whether the IP address of the DHCP Server in the Option 54 field is the same as the DHCP server address of the proxy.
  • the DHCP proxy resolves the OptionA of the DHCP Request message to obtain and save the OpenFlow Switch device information.
  • the DHCP proxy reassembles a DHCP Request unicast packet that does not carry Option Option A to the DHCP server.
  • Step S632 After receiving the DHCP Request message forwarded by the DHCP proxy, the DHCP server determines whether the IP address of the DHCP server in the Option 54 field is the same as its own. If they are the same, the DHCP server sends a DHCP Ack acknowledgment message containing the IP address and other options provided by the DHCP proxy to the DHCP proxy. The DHCP proxy sends the DHCP Ack acknowledgment message to the OpenFlow Switch.
  • Step S634 After receiving the DHCP Ack packet, the DHCP Proxy will save the OpenFlow locally before.
  • the Switch device information is saved as a record to the local MIB data table of the DHCP Proxy (the record of adding OpenFlow Switch device information in the MIB data table is optional), and the OpenFlow Switch device domain name is matched in its MIB data table, which will match
  • the information of the OpenFlow Controller is sorted by priority.
  • the information of the OpenFlow Controller device is populated with the extended option OptionB.
  • the DHCP proxy reassembles a DHCP Ack packet carrying the extended option OptionB and sends it to the OpenFlow Switch.
  • Step S636 After receiving the DHCP Ack packet of the DHCP server, the OpenFlow Switch parses the extended option OptionB, and learns the OpenFlow Controller device address of the management domain to which it belongs from the option information.
  • the OpenFlow Switch actively attempts to build a link with the OpenFlow Controller.
  • Step S638 OpenFlow Controller and OpenFlow Switch After the OpenFlow Switch is successfully established, OpenFlow
  • Embodiment 5 This embodiment mainly describes a process in which an OpenFlow control plane device discovers an OpenFlow control plane device through a DHCP server and constructs a link normally in an OpenFlow control plane device controller and a configuration point separation scenario. For convenience of description, and only as an example, the dynamic discovery process is described in the embodiment using the DHCPv4 protocol.
  • the DHCP device is the DHCP server.
  • the OpenFlow control device is the OpenFlow Controller device and the OpenFlow Configuration Point device.
  • the OpenFlow Configuration Point device has the OpenFlow Controller device information.
  • the OpenFlow forwarding device is the OpenFlow Switch.
  • the implementation For example, the process flow of the DHCP device when the OpenFlow device releases the address or offline is not described. For related procedures, refer to the related description of Embodiment 3.
  • the service detailed process is shown in Figure 7.
  • Step S702 After the OpenFlow Configuration Point is started, the DHCP Discover message is sent to the DHCP server (it can carry the existing address request).
  • the Option B carries the field information such as the device role and domain name to the DHCP server.
  • the extended option OptionA format proposal is shown in Figure 8.
  • the DHCP Discover message can also carry the extended option OptionA. This option is carried by the DHCP Request.
  • Step S704 The DHCP server creates a DHCP user session, parses the extended option OptionA carried by the OpenFlow Configuration Point, and temporarily stores the information on the DHCP server.
  • DHCP server sends a DHCP Offer packet carries an assigned IP address and other configuration information to OpenFlow Configuration Point 0
  • Step S706 OpenFlow Configuration Point selects a proper address, and transmits the DHCP Request to the DHCP server to confirm if the DHCP Discover packets do not carry over Option Option A, DHCP Request message must carry Option A to report its own device information. You are advised to carry the OptionA only in the DHCP Request message.
  • Step S708 After receiving the DHCP Request, the DHCP server parses the information in the Option A and obtains the same as the DHCP server address in the Option 54 field. If the DHCP Request message is abnormal or the DHCP Request message times out abnormally, the step S704 or this step is deleted. The information of the device role, domain name, etc. of the OpenFlow Configuration Point cached by the DHCP server. If they are the same, the DHCP server sends a DHCP Ack message to the OpenFlow Configuration Point, and writes the device information of the OpenFlow Configuration Point as a record to the local MIB data table of the DHCP server.
  • Step S710 The NMS queries the MIB data table of the DHCP server, and learns the OpenFlow Configuration Point information learned by the DHCP server. The described actions and the preceding and following steps in this step have no strict timing relationship. The DHCP server is also allowed to actively report the information of the OpenFlow Configuration Point that it learns through a specific interface.
  • Step S712 The OpenFlow Switch sends a DHCP Discover message to the DHCP server to apply for an IP address, and can also carry the Option A message to the DHCP server, but it is not recommended to carry it in this message.
  • Step S714 The DHCP server sends a DHCP Offer message containing the IP address and other configuration information to the OpenFlow Switch device.
  • Step S716 The OpenFlow Switch sends a DHCP Request message to each DHCP server in a broadcast manner to confirm, and the DHCP Request message can carry the Option A message to report its own information.
  • Step S718 After receiving the DHCP Request message of the OpenFlow Switch, the DHCP server determines
  • the IP address of the DHCP server in the Option 54 field is the same as its own. If they are the same, the DHCP server sends a DHCP ACK acknowledgment message containing the IP address and other option information it provides to the OpenFlow Switch. At the same time, the DHCP server parses the OptionA of the DHCP Request message to obtain the OpenFlow Switch device information, and saves one record to the MIB data table of the DHCP server.
  • Step S720 After receiving the DHCP ACK message of the DHCP server, the OpenFlow Switch parses the extended option Option B, and learns the OpenFlow Configuration Point device address of the management domain to which it belongs from the option information. The OpenFlow Switch actively attempts to establish a chain with the OpenFlow Configuration Point.
  • Step S722 OpenFlow Configuration Point and OpenFlow Switch
  • the OpenFlow Configuration Point renews the lease through the DHCP Request message and carries the option OptionA to update the local MIB data table record of the DHCP server.
  • DHCP Inform packets can also be used to carry Option OptionA to achieve the same effect.
  • Step S724 After the OpenFlow Controller knows the address of the OpenFlow Controller, try to establish a link with the OpenFlow Controller. This step and step S722 do not have a strict timing relationship.
  • Step S726 After the OpenFlow Controller and the OpenFlow Switch are chained, the OpenFlow Configuration Point can be advertised to the OpenFlow Configuration Point according to the specific interface. When the OpenFlow Configuration Point manages multiple OpenFlow Controllers, the OpenFlow Switch can be adjusted according to a certain policy.
  • the OpenFlow Controller is built to implement load balancing of the SDN infrastructure network control flow. This step is optional and is not mandatory.
  • the DHCP device responds to the OpenFlow control plane device information list in the DHCP Ack packet of the OpenFlow forwarding device, and the Option B1 format proposal is shown in FIG. 9.
  • the present invention It is recommended that the extended option OptionB2 of the OpenFlow control plane device information list be sent in the DHCPv6 Reply message.
  • the format of the Option B2 format is shown in Figure 10.
  • the above embodiments of the present invention can be used in an SDN forwarding plane device (including all forwarding plane devices supporting an SDN southbound interface protocol such as OpenFlow, such as an AP, a switch, and a router) to discover an application scenario of a scenario of the SDN controller.
  • software is also provided for performing the technical solutions described in the above embodiments and preferred embodiments.
  • a storage medium is 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 above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module.
  • the technical means solves the technical problem that the forwarding plane device automatically discovers the control plane device in the related technology, thereby realizing the automatic discovery of the control plane device by the forwarding plane device, and thus the forwarding plane device can be controlled. Adaptive adjustment of the surface device.

Landscapes

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

Abstract

本发明提供了一种基于OpenFlow协议的控制面设备的发现处理方法及装置，其中，上述方法包括：接收来自基于OpenFlow协议的转发面设备的标识信息，其中，该标识信息为转发面设备的标识信息，上述标识信息与管理信息数据库中的控制面设备信息相对应；根据上述标识信息在管理信息数据库中匹配得到控制面设备信息；向转发面设备发送上述控制面设备信息。采用本发明提供的上述技术方案，解决了相关技术中，尚无有效地让转发面设备自动发现控制面设备的技术问题，从而实现了转发面设备对控制面设备的自动发现，进而可以实现转发面设备可以对控制面设备的自适应调整。

Description

基于开放流协议的控制面设备的发现处理方法及装置 技术领域 本发明涉及通信领域， 具体而言， 涉及一种基于开放流 （OpenFlow, 简称为 OF) 协议的控制面设备的发现处理方法及装置。 背景技术 软件定义网络（Software Defined Network, 简称为 SDN)是一种新型的网络架构， 它的设计理念是将网络的控制平面与数据转发平面进行分离， 并实现可编程化控制。 通常将 SDN网络架构抽象定义成三层： 第一层是转发面实体，包括实现这种转发功能 的各种软硬件组件； 第二层是针对第一层转发实体进行管理和控制的实体， 第三层是 基于前两层基础网络的应用和服务。前两层之间的接口称之为 SDN的南向接口， 目前 OpenFlow协议是南向接口的主流协议， 它以流表为基础， 控制细颗粒度的转发表及其 行为， 具有很强的表达能力， 适应能力强。
OpenFlow协议是一种交换技术， 该技术最早由斯坦福大学提出， 旨在基于现有传 输控制协议 （Transfer Control Protocol, 简称为 TCP) /互联网协议 （Internet Protocol, 简称为 IP) 技术条件， 以创新的网络互联理念解决当前网络的种种弊病， OpenFlow 协议的核心思想是将由交换机 /路由器控制的数据包转发过程， 演化为由 OpenFlow转 发面设备 （例如 OF Switch, 也包括其他支持 OpenFlow/OF-Config协议和流表机制的 转发面设备， 例如访问接入点（Access Point, 简称为 AP)、路由器）和控制服务器（例 如 OF Controller) 分别完成的独立过程， 进而实现数据转发和路由控制的分离。 在传 统网络中数据包的流向是人为指定的， 虽然交换机、 路由器拥有控制权， 却没有数据 流的概念， 所以只能进行数据包级别的交换。 然而在 OpenFlow网络中， 控制服务器 将取代路由器， 由控制服务器 (OF Controller)通过预先规定好的接口操作来决策所有数 据包在网络中传输路径， 从而达到控制数据转发的目的。
OpenFlow协议运行在安全传输层协议 （Transport Layer Security Protocol, 简称为 TLS) 和无保护 TCP连接之上， 如果 OpenFlow转发面设备在转发数据包时， 遇到未 指定转发路径的数据包， 则由该设备发送查询消息至与其建链的 OpenFlow控制器， 由该控制器决策该数据包的转发路径。 这样就要求 OpenFlow转发面设备和 Openflow 控制器必须在 OpenFlow转发面设备转发报文前建立链接。 OpenFlow协议 VI.3版本开始分离出 Of-Config协议， 将对 SDN转发面设备配置 管理方面的功能剥离出来， 形成单独的通道， Of-Config协议可以运行在 TCP、安全套 接层 （Secure Socket Layer, 简称为 SSL) 协议、 用户数据协议 （User Date Protocol, 简称为 UDP)或数据报文安全传输层（Datagram Transport Layer Security,简称为 DTLS) 协议等协议上。 OF配置点 （OF Configuration Point) 设备配置 OpenFlow转发面设备 时， 可以为其配置 OpenFlow控制器的地址， 但这又要求 OpenFlow转发面设备能有效 的动态发现 Of-Config管理配置点。 目前 OpenFlow协议族没有定义相应的发现机制， OpenFlow转发面设备只能通过 静态配置发现 OpenFlow 控制面设备 （包括 OpenFlow Controller 禾 B OpenFlow Configuration Point设备）， 该方法对于 OpenFlow转发面设备发现 OpenFlow控制面设 备机制来说还是不够完善， 不便于运行维护较大规模的 OpenFlow网络， 例如， 在较 大规模的 OpenFlow网络中， 管理员需要规划控制面设备对转发面设备进行管理控制 的对应关系， 并在大量转发面设备上配置其对应的控制面设备的地址信息。 一旦控制 面设备发生故障， 转发面设备还不能自适应调整， 接入新的控制面设备。 而且在根据 不同物理设备部署不同业务或分域管理不同设备厂商设备的应用场景下，配置更繁琐。 针对相关技术中的上述问题， 目前尚未提出有效的解决方案。 发明内容 针对相关技术中， 尚无有效的解决方案可以让转发面设备自动发现控制面设备， 本发明实施例提供了一种基于 OpenFlow协议的控制面设备的发现处理方法及装置， 以至少解决上述问题。 根据本发明的一个实施例， 提供了一种基于 OpenFlow协议的控制面设备的发现 处理方法， 包括： 接收来自基于 OpenFlow协议的转发面设备的标识信息， 其中， 该 标识信息为转发面设备的标识信息， 上述标识信息与管理信息数据库 （Management Information Base, 简称为 MIB) 中的控制面设备信息相对应； 根据上述标识信息在管 理信息数据库中匹配得到控制面设备信息； 向转发面设备发送上述控制面设备信息。 优选地， 在接收上述标识信息之前， 包括： 获取 SDN中预先分域后指定域中的各 个控制面设备信息； 将指定域中各个控制面设备信息存储至管理信息数据库。 优选地， 上述标识信息包括： 转发面设备所属指定域的域名信息。 优选地， 上述方法应用于 SDN中的动态主机配置协议 （Dynamic Host Configure Protocol, 简称为 DHCP) 设备。 优选地， 向转发面设备发送控制面设备信息包括： 通过 DHCP报文中的指定字段 向转发面设备发送控制面设备信息。 优选地， 上述指定字段包括： 选项 （Option) 字段。 优选地， 接收来自基于 OpenFlow协议的转发面设备的标识信息时， 还包括： 接 收转发面设备的请求消息， 其中， 该请求消息用于请求 DHCP设备为转发面设备分配 地址。 优选地， 上述方法还包括： 接收网络管理系统 （Network Management System, 简 称为 NMS) 的查询请求消息； 在查询请求消息的触发下， 通过 NMS将管理信息数据 库中的控制面设备信息发送至 SDN中除 DHCP设备之外的其它 DHCP设备。 根据本发明的另一个实施例， 提供了一种基于 OpenFlow协议的控制面设备的发 现处理装置， 包括： 接收模块， 设置为接收来自基于 OpenFlow协议的转发面设备的 标识信息， 其中， 该标识信息为所述转发面设备的标识信息， 上述标识信息与管理信 息数据库中的控制面设备信息相对应； 匹配模块， 设置为根据上述标识信息在管理信 息数据库中匹配得到控制面设备信息； 发送模块， 设置为向转发面设备发送控制面设 备信息。 优选地， 上述装置包括： 获取模块， 设置为获取软件定义网络 （SDN) 中预先分 域后指定域中的各个控制面设备信息； 存储模块， 设置为将指定域中各个控制面设备 信息存储至管理信息数据库。 通过本发明实施例， 采用根据转发面设备的标识信息匹配得到控制面设备信息， 并将该控制面设备信息发送至转发面设备的技术手段， 解决了相关技术中， 尚无有效 地让转发面设备自动发现控制面设备的技术问题， 从而实现了转发面设备对控制面设 备的自动发现， 进而可以实现转发面设备可以对控制面设备的自适应调整。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中- 图 1为根据本发明实施例 1的基于 OpenFlow协议的控制面设备的发现处理方法 的流程图； 图 2为根据本发明实施例 1的基于 OpenFlow协议的控制面设备的发现处理装置 的结构框图； 图 3为根据本发明实施例 1的基于 OpenFlow协议的控制面设备的发现处理装置 的另一结构框图； 图 4为根据本发明实施例 2的 SDN网络自动发现 OpenFlow控制面设备的流程示 意图； 图 5为根据本发明实施例 3的 SDN网络自动发现 OpenFlow控制面设备的流程示 意图； 图 6为根据本发明实施例 4的 SDN网络自动发现 OpenFlow控制面设备的流程示 意图； 图 7为根据本发明实施例 5的 SDN网络自动发现 OpenFlow控制面设备的流程示 意图； 图 8为根据本发明实施例的 OpenFlow设备上报设备信息的扩展选项 OptionA示 意图； 图 9为根据本发明实施例的 DHCPv4下发 OpenFlow控制面设备信息给转发面设 备的扩展选项 OptionBl示意图； 图 10为根据本发明实施例的 DHCPv6下发 OpenFlow控制面设备信息给转发面设 备的扩展选项 OptionB2示意图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在不冲突的 情况下， 本申请中的实施例及实施例中的特征可以相互组合。 实施例 1 图 1为根据本发明实施例 1的基于 OpenFlow协议的控制面设备的发现处理方法 的流程图。 如图 1所示， 该方法包括： 步骤 S102， 接收来自基于 OpenFlow协议的转发面设备的标识信息， 其中， 该标 识信息为转发面设备的标识信息， 上述标识信息与 MIB中的控制面设备信息相对应； 步骤 S104， 根据上述标识信息在 MIB中匹配得到上述控制面设备信息； 步骤 S106， 向转发面设备发送控制面设备信息。 通过上述各个处理步骤， 由于采用根据与控制面设备信息对应的转发面设备的标 识信息来自动匹配得到上述控制面设备信息并发送给转发面设备的技术手段， 代替了 采用静态配置发现 OpenFlow控制面设备的方式， 因此， 可以实现转发面设备对控制 面设备的自动发现。 在本实施例中， 为了便于对控制面设备的管理， 可以对上述控制面设备信息进行 分域管理， 具体地， 在接收标识信息之前， 获取 SDN中预先分域后指定域中的各个控 制面设备信息， 将指定域中各个控制面设备信息存储至管理信息数据库。 在对上述控制面设备信息进行分域管理时， 上述标识信息可以包括但不限于： 上 述转发面设备所属上述指定域的域名信息。 在本实施例中， 上述方法可以但不限于应用于 SDN中的网络设备。此时， 可以通 过 DHCP报文中的指定字段向转发面设备发送控制面设备信息。 该指定字段包括但不 限于： 选项 （Option) 字段。 在本实施例中， 可以在接收来自基于 OpenFlow协议的转发面设备的标识信息时， 接收转发面设备的请求消息， 其中， 该请求消息用于请求 DHCP (包括 DHCPv4 和 DHCPv6) 设备为转发面设备分配地址。 在本实施例中， 为了实现跨 DHCP设备管理网络的发现机制， 在本实施例中， 还 可以接收网络管理系统 NMS的查询请求消息； 在查询请求消息的触发下， 通过 NMS 将管理信息数据库中的控制面设备信息发送至 SDN中除上述 DHCP设备之外的其它 DHCP设备。 在本实施例中还提供了一种基于 OpenFlow协议的控制面设备的发现处理装置， 用于实现上述实施例及优选实施方式， 已经进行过说明的不再赘述， 下面对该装置中 涉及到的模块进行说明。 如以下所使用的， 术语"模块"可以实现预定功能的软件和 /或 硬件的组合。 尽管以下实施例所描述的装置较佳地以软件来实现， 但是硬件， 或者软 件和硬件的组合的实现也是可能并被构想的。 图 2 为根据本发明实施例 1 的基于 OpenFlow协议的控制面设备的发现处理装置的结构框图。 如图 2所示， 该装置包括： 接收模块 20， 连接至匹配模块 22， 设置为接收来自基于 OpenFlow协议的转发面 设备的标识信息， 其中， 该标识信息为上述转发面设备的标识信息， 上述标识信息与 管理信息数据库中的控制面设备信息相对应； 匹配模块 22，连接至发送模块 24， 设置为根据上述标识信息在管理信息数据库中 匹配得到上述控制面设备信息； 发送模块 24， 设置为向上述转发面设备发送控制面设备信息。 通过上述各个模块实现的功能， 同样可以实现转发面设备对控制面设备的自动发 现。 在本实施例中， 如图 3所示， 上述装置还可以包括以下模块： 获取模块 26， 连接 至存储模块 28， 设置为获取 SDN中预先分域后指定域中的各个控制面设备信息； 存 储模块 28， 设置为将指定域中各个控制面设备信息存储至管理信息数据库。 为了更好地理解上述实施例， 以下结合实施例 2-5 详细说明， 其中 DHCP 以 DHCPv4为例， 但不限于 DHCPv4， 例如还可以为 DHCPv6。 实施例 2 本实施例的目的在于提供一种 SDN网络自动发现 OpenFlow控制面设备的方法， 其可以简化 OpenFlow的网络配置， 完善 Openflow网络转发面设备发现控制面设备的 机制， 使 OpenFlow的网络更加智能化， 提高 OpenFlow网络的可维护性。 本实施例的主要设计思想在于，在 SDN网络控制面的 DHCP设备（DHCP Server^ DHCP Proxy DHCP Relay Agent等） 上借助 DHCP交互流程自动学习该 DHCP管理 域内的 Openflow控制面设备， 并把自动学习的结果，保存在本地维护的一个管理信息 数据库 (MIB)中， 实现分域管理这些 Openflow控制面设备。 在 OpenFlow转发面设备 向 DHCP服务器申请 IP地址时，由 DHCP设备根据 OpenFlow转发面设备上报选项中 的域名信息匹配本地 MIB中的存储条目， 将匹配的结果 （SDN网络的相同管理域内 可用的 OpenFlow控制面设备信息列表） 通过 DHCP 报文中的 Option选项通告给 OpenFlow转发面设备， 以便让其可以根据自身需要选择合适的 OpenFlow控制面设备 进行建链， 实现 OpenFlow转发面设备自动发现 OpenFlow控制面设备的功能。 如图 4所示， DHCP设备提供、 管理、 维护着一个 MIB数据表， 该管理信息库的 数据表主要管理 OpenFlow网络中的 OpenFlow转发面设备、 OpenFlow Controller和 OpenFlow Configuration Point等设备信息， 该 MIB数据表可以在本地通过命令修改， 也可以通过 NMS远程修改或 DHCP协议模块触发自动学习修改， 其表项字段建议包 括设备角色、 设备地址、 域名、 设备唯一标识、 设备管理负荷和信息来源等。 该 MIB数据表各个字段意义说明如下： 设备角色（Role): 描述该设备是 OpenFlow转发面设备（0)、 OpenFlow Controller ( 1 ) 还是 OpenFlow Configuration Point (2)。 设备地址（IP地址）： OpenFlow设备的南向接口建链 IP地址，可以是 IPv4或 IPv6 地址。 域名： 表示 OpenFlow设备归属的管理域， 域名字符串为空时， 按默认域名处理。 SDN网络的管理人员可以根据设备厂商分类、业务类型或虚拟运营商分类来规划网络 的管理域， 分域管理网络中的不同设备。 域名可以在设备出厂时静态配置， 或本地管 理口命令配置， 也可以在接入管理网络后， 由 OpenFlow控制面设备动态配置修改。 设备唯一标识： 表征设备的全局唯一标识， 建议是一个特定编码格式的字符串。 设备管理负荷： 仅对 OpenFlow控制面设备有效， 表示管理设备负荷的指标数据， 可以是 OpenFlow链接数和满载链接数的百分比， 也可以综合其他指标。 这些指标数 据可以由这些 OpenFlow控制面设备动态更新， OpenFlow转发面设备在没有优先级建 议的情况下， 优先选择负荷较轻的控制面设备建链。 信息来源： 表示一条数据表记录的生成原因， 例如 NMS远程配置， 本地配置和 自动学习。 这几种生成原因可以设定有一定的优先级， 例如本地配置优先于 NMS远 程配置， NMS远程配置优先于自动学习。 当然这种优先级关系可以配置设定。 一种生 成原因的数据表记录一般只能以相同信息来源的删除动作来删除， 除非该数据表记录 被高优先级的相同设备的数据表记录所替换。 同时该 MIB数据表可以被 NMS查询， NMS获悉该 DHCP设备的 MIB数据表自 动学习到的记录后， 可以向 SDN中的其他 DHCP设备下发这些记录， 实现跨 DHCP 设备管理网络的发现机制。 由此可见本方案中 DHCP设备不再是单纯地执行或代理执 行地址分配的动作，还实现了对其管理范畴内的 SDN网络设备进行统一管理，所以这 种能够处理 DHCP报文并执行网络节点信息管理的设备也可以为某些网关设备， 包括 宽带网络网关控制设备 （Broadband Network Gateway, 简称为 BNG) 等。 以下对本实施例即图 4中所涉及的步骤描述： 步骤 S402: OpenFlow控制面设备 1启动后，通过 DHCP协议中的 DHCP Discover 报文携带扩展的选项 OptionA上报该设备的角色和域名 Domainl等信息， 如果它不需 要通过 DHCP获取地址， 可以携带自身已有地址来申请， 本质上它只是通过 DHCP报 文上报自身的设备信息给 DHCP 设备来形成 MIB 数据表条目。 DHCP 设备在应答 DHCP请求后， 添加一个设备信息记录到 MIB数据表中， OpenFlow控制面设备 1后 续的负荷变化可以通过提前续租或特定的 DHCP类型报文携带选项 OptionA动态更新 给 DHCP设备 MIB数据表。 OpenFlow控制面设备 1释放地址时， 在 DHCP Release 报文中携带扩展的选项 OptionA, DHCP设备删除本地 MIB信息表中的对应的设备记 录。 步骤 S404: OpenFlow控制面设备 2启动后，通过 DHCP协议中的 DHCP Discover 报文携带扩展的选项 OptionA上报该设备的角色和域名 Domain2等信息。 DHCP设 备采用步骤 1相同的方式添加一个新的设备信息记录到 MIB数据表中。 OpenFlow控 制面设备 2释放地址时， 在 DHCP Release报文中携带扩展的选项 OptionA, DHCP设 备删除本地 MIB信息表中的对应的设备记录。 步骤 S406: OpenFlow转发面设备 1 启动正常后， 通过 DHCP协议中的 DHCP
Discover中的选项 OptionA上报域名 Domainl来并获取 IP地址， DHCP设备将分配到 的地址告知 OpenFlow转发面设备 1的同时， 携带特殊的选项 OptionB将其 MIB数据 表记录中匹配到 Domainl的 OpenFlow控制面设备信息列表下发给 OpenFlow转发面 设备 1， 从而让其发现 OpenFlow控制面设备 1。 OpenFlow转发面设备 1开始尝试和 OpenFlow控制面设备 1建链。 OpenFlow转发面设备 1释放地址时， 在 DHCP Release 报文中携带扩展的选项 OptionA, DHCP设备删除本地 MIB信息表中的对应的设备记 录。 步骤 S408: OpenFlow转发面设备 2启动正常后， 通过 DHCP协议中的 DHCP Discover中的选项上报域名 Domain2来并获取 IP地址。然后采用步骤 3相同的方式发 现 OpenFlow控制面设备 2， 并开始尝试和 OpenFlow控制面设备 2建链。 OpenFlow 转发面设备 2释放地址时， 在 DHCP Release报文中携带扩展的选项 OptionA, DHCP 设备删除本地 MIB信息表中的对应的设备记录。 步骤 S410: NMS设备查询 DHCP设备 MIB数据表， 获悉其学习到的 OpenFlow 设备信息，根据 NMS配置的策略，有选择地向其他 DHCP设备下发其获悉的 OpenFlow 控制设备信息。 当然， 也允许 DHCP设备通过特定接口主动上报或和更换自己学习到 的 MIB数据表记录。 以上 5个步骤没有严格的时序关系， 任何一个步骤都可能先发生， OpenFlow转发 面设备可能在第一次申请地址时没能从 DHCP设备发现任何 OpenFlow控制面设备， 它可以选择其他发现方式 （例如多播探测、 本地的静态配置） 来发现一个广播域内的 OpenFlow控制面设备，也可以延时重新尝试从 DHCP设备发现 OpenFlow控制面设备。 DHCP 设备通过选项 OptionB 给 OpenFlow转发面设备下发同一个管理域内的
OpenFlow控制面设备信息列表时， 列表中的 OpenFlow控制面设备的顺序可以用来表 示其优先级建议。 如果有多个 OpenFlow控制面设备， OpenFlow转发面设备会依次向 这些设备发起建链请求， 直到和某个合适的 OpenFlow控制面设备成功建链。
OpenFlow转发面设备的管理口 （用于发起 DHCP交互流程， 并在发现 OpenFlow 控制面设备后和其建链） 和转发 口应有明确的区分， 管理口支持 DHCP/TCP/SSL/OpenFlow等协议的处理，不需流表或有默认的流表，而转发口在没有 OpenFlow控制面设备配置前无需支持这些协议， 这种区分可以是软件或固件上的差 异， 也可以是设备部署和本地配置上的选择。 采用本实施例中的上述方案，为 OpenFlow转发面设备自动发现 OpenFlow控制面 设备提供了可行性， 使 SDN网络中 OpenFlow转发面设备和控制面设备的部署更加智 能化。 为了更好地理解上述实施例 1-2， 以下结合实施例 3-5详细说明。 以下实施例 3-5 提供的 SDN 网络自动发现 OpenFlow控制面设备的方案， 由 OpenFlow转发面设备借助于和 DHCP设备的 DHCP报文交互自动发现 OpenFlow控制 面设备， 在 OpenFlow控制面设备部署相对稳定的网络中， 能提供良好的服务。 以下实施例 3-5可以基于以下设计思想实现： 在 SDN中， OpenFlow转发面设备 可以通过 DHCPv4/DHCPv6设备动态发现 OpenFlow控制面设备。 禾 B DHCPv4类似， OpenFlow控制面设备可以在 DHCPv6 Solicit报文中上报本设备管理信息给 DHCPv6 设备， OpenFlow转发面设备在申请地址的过程中， DHCPv6 设备可以通过 DHCPv6 Advertise 或者是 DHCPv6 Reply 报文下发匹配该 OpenFlow 转发面设备管理域的 OpenFlow控制面设备信息给该 OpenFlow转发面设备。 另外对于 DHCP设备上通过 DHCP流程学习到的 SDN网络设备都可以被这些设备的 DHCP Release报文触发删除。 实施例 3 该实施例主要描述 OpenFlow 控制面设备控制器和配置点不分离场景下， OpenFlow转发面设备通过 DHCP服务器发现 OpenFlow控制面设备并正常建链的过 程。 为了便于描述， 并仅作为一种示例， 本实施例中采用 DHCPv4协议描述该动态发 现流程。 DHCP设备为 DHCP Server, OpenFlow控制面设备为 OpenFlow Controller, OpenFlow 转发面设备为 OpenFlow Switch, 该实施例下没有提供单独的 OpenFlow Configuration Point设备， 由 OpenFlow Controller执行配置工作， 并具体描述了 DHCP 设备感知 SDN网络 OpenFlow设备释放地址或离线时的处理。 业务详细流程图参见图 5所示： 步骤 S502: OpenFlow Controller启动后，发送 DHCP发现（Discover)报文给 DHCP 服务器 （可以携带已有地址申请）。 在 OF Controller设备发送的 DHCP Discover报文 中， 通过扩展选项 OptionA携带设备角色、 域名等字段信息给 DHCP服务器。 扩展的 选项 OptionA格式建议详见图 8， 该报文也可以不携带扩展的选项 OptionA, 让 DHCP Request携带该选项。 步骤 S504: DHCP 服务器创建 DHCP 用户会话， 解析 OpenFlow控制面设备 Controller携带上来的扩展选项 OptionA, 将信息暂存在 DHCP服务器上。 DHCP服务 器发送 DHCP供给 （Offer) 报文携带分配的 IP 地址和其他配置信息给 OpenFlow Controller。 步骤 S506: OpenFlow Controller选择合适的地址， 并发送 DHCP请求 （Request) 至 DHCP服务器进行确认，如果 DHCP Discover报文没有携带过选项 OptionA, DHCP Request报文就必须携带选项 OptionA上报自身信息。 建议只在 DHCP Request报文中 携带选项 OptionA。 步骤 S508: DHCP服务器收到 DHCP Request后， 解析选项 OptionA中的信息， 同时获取判断 Option54字段中的 DHCP服务器地址是否和自己相同， 如果不同或者 DHCP Request报文超时异常， 则删除步骤 S504 或本步骤中 DHCP 服务器缓存的 OpenFlow Controller的设备角色、域名等信息记录。如果相同， DHCP服务器发送 DHCP 响应（Ack)报文给 OpenFlow Controller, 同时将 OpenFlow Controller的信息作为一条 记录写入 DHCP服务器本地的 MIB数据表。 步骤 S510: NMS查询 DHCP服务器的 MIB数据表， 获悉 DHCP服务器学习到的 OpenFlow Controller信息。 该步骤前面的描述动作和前后步骤没有严格时序关系。 也 允许 DHCP服务器通过特定的接口主动上报自己学习到的 OpenFlow Controller的信 息。 步骤 S512: OpenFlow Switch发送 DHCP发现 （Discover) 报文至 DHCP服务器 申请 IP地址，也可以携带选项 OptionA上报自身设备信息给 DHCP服务器，但是不建 议在此报文中携带。 步骤 S514: DHCP服务器发送含有 IP地址和其他配置信息的 DHCP Offer报文给 OpenFlow Switch设备。 步骤 S516: OpenFlow Switch 以广播方式向各 DHCP 服务器回应 DHCP请求 ( Request )报文进行确认， DHCP Request报文中可以携带选项 OptionA上报自身信息。 步骤 S518: DHCP服务器收到 OpenFlow Switch的 DHCP Request报文后， 判断 Option54字段中的 DHCP Server的 IP地址是否与自己的相同。如果相同， DHCP服务 器会向 OpenFlow Switch发送包含它所提供的 IP地址和其它选项信息的 DHCP ACK 确认报文。 同时 DHCP 服务器解析 DHCP Request报文携带的选项 OptionA, 获取 OpenFlow Switch设备信息， 将其作为一条记录保存到该 DHCP服务器本地的 MIB数 据表 （在 MIB 数据表添加 OpenFlow Switch 设备信息的记录为可选动作）， 并用 OpenFlow Switch设备域名在其 MIB数据表中匹配， 将匹配到的 OpenFlow Controller 设备信息按优先级排序作优选建议， 将排序后的 OpenFlow Controller设备信息列表填 充扩展选项 OptionB由 DHCP ACK报文携带给 OpenFlow Switch。 步骤 S520: OpenFlow Switch收到 DHCP服务器的 DHCP Ack报文后， 解析其中 的扩展选项 OptionB, 从该选项信息获悉自己所属管理域的 OpenFlow Controller设备 地址。 OpenFlow Switch主动尝试和 OpenFlow Controller建链。 步骤 S522: OpenFlow Controller禾 B OpenFlow Switch 成功建链后， OpenFlow
Controller管理的 OpenFlow Switch数量变化， OpenFlow Controller通过 DHCP Request 报文提前续租，并携带选项 OptionA更新 DHCP服务器本地的 MIB数据表记录。当然 也允许使用 DHCP Inform报文来携带选项 OptionA, 以达到同样的效果。 步骤 S524: OpenFlow Switch释放地址或没有及时续租， DHCP服务器回收地址， 并删除本地 MIB数据表中对应该 OpenFlow Switch的记录。 步骤 S526: OpenFlow Controller释放地址没有及时续租， DHCP服务器回收地址 并删除本地 MIB数据表中对应该 OpenFlow Controller的记录。 步骤 S528: NMS查询 DHCP服务器的 MIB数据表， 获悉 DHCP服务器学习到的 OpenFlow Controller信息，得知 DHCP服务器之前学习到的 OpenFlow Controller等 SDN 设备失效后， NMS上对应的记录也删除，并同步更新它对其他 DHCP设备下发的配置。 该步骤前面的描述动作和前后步骤没有严格时序关系。和步骤 S510—样， 允许 DHCP 服务器通过特定的接口主动上报自己学习到的 OpenFlow Controller信息变更。
OpenFlow Switch根据 DHCP服务器下发的 OpenFlow Controller设备列表， 发现 可以与之建链的 OpenFlow Controller, 这些 OpenFlow Controller可以是 DHCP服务器 本地学习的， 也可以是 NMS从其他网络管理域的 DHCP服务器上获悉的， 也可以是 DHCP服务器本地静态配置到 MIB数据表中的。 实施例 4 该实施例主要描述 OpenFlow 控制面设备控制器和配置点不分离场景下， OpenFlow转发面设备通过 DHCP代理设备发现 OpenFlow控制面设备并正常建链的过 程。 为了便于描述， 并仅作为一种示例， 本实施例中采用 DHCPv4协议描述该动态发 现流程。 本实施例中描述的 DHCP设备为 DHCP Proxy, 后端还有 DHCP服务器， OpenFlow 控制面设备为 OpenFlow Controller, OpenFlow转发面设备为 OpenFlow Switch, 该实施例下没有提供单独的 OpenFlow Configuration Point设备， 由 OpenFlow Controller执行配置工作。 该实施例不再描述 OpenFlow设备释放地址或离线时 DHCP 设备的处理流程， 相关流程可参考实施例 3的相关描述。 本实施例的业务详细流程参见图 6所示： 步骤 S602: OpenFlow Controller启动后，发送 DHCP Discover报文给 DHCP Proxy (可以携带已有地址申请）。 在 OF Controller设备发送的 DHCP Discover报文中， 通 过扩展选项 OptionA 携带设备角色、 域名等字段信息给 DHCP Pr0xy。 扩展的选项 OptionA 格式建议详见图 8， 该报文也可以不携带扩展的选项 OptionA, 让 DHCP Request携带该选项。 步骤 S604:支持学习管理 SDN网络设备信息的 DHCP Proxy收到 DHCP Discover 报文后，创建 DHCP用户会话，截获其中扩展选项 OptionA,并重组一个 DHCP Discover 单播报文发往其代理的 DHCP服务器。 步骤 S606: DHCP服务器创建 DHCP用户会话， 发送 DHCP Offer报文携带分配 的 IP地址和其他配置信息给 DHCP代理（Proxy),由 DHCP Proxy代为发送给 OpenFlow Controller。 步骤 S608： DHCP Proxy将收到的 DHCP Offer报文转发 OpenFlow Controlle 步骤 S610: OpenFlow Controller选择合适的地址，并发送 DHCP Request至 DHCP Proxy进行确认， 如果 DHCP Discover报文没有携带过选项 OptionA, DHCP Request 报文就必须携带选项 OptionA上报自身信息。 建议只在 DHCP Request报文中携带选 项 OptionA。 步骤 S612: DHCP Proxy收到 DHCP Request报文后， 截获并解析选项 OptionA中 的信息，同时获取判断 Option54字段中的 DHCP服务器地址是否和自己代理的 DHCP 服务器地址一致， 如果不同或者 DHCP Request报文超时异常， 则删除步骤 S604或本 步骤中缓存的 OpenFlow Controller的设备角色、 域名等信息记录。 如果相同， DHCP Proxy重组不携带选项 OptionA的 DHCP Request单播报文发送 DHCP服务器。 步骤 S614: DHCP服务器收到 DHCP Request后， 获取判断 Option54字段中的
DHCP服务器地址是否和自己相同，如果相同就发送 DHCP ACK报文给 DHCP Proxy, 由 DHCP Proxy代为发送给 OpenFlow Controller 步骤 S616: DHCP Proxy收到 DHCP ACK报文后， 将 OpenFlow Controller的信息 作为一条记录写入 DHCP Proxy本地的 MIB 数据表， 同时将报文发送给 OpenFlow Controller。 步骤 S618: NMS查询 DHCP Proxy的 MIB数据表， 获悉 DHCP Proxy学习到的 OpenFlow Controller信息。 该步骤前面的描述动作和前后步骤没有严格时序关系。 也 允许 DHCP Proxy通过特定的接口主动上报自己学习到的 OpenFlow Controller的信息。 步骤 S620: OpenFlow Switch发送 DHCP Discover报文至 DHCP Proxy, 希望向 DHCP服务器申请 IP地址， 可以在该报文中携带选项 OptionA上报自身设备信息， 但 是不建议在 DHCP Discover报文中携带 OptionA。 步骤 S622: DHCP Proxy收到 DHCP Discover报文后截获选项 OptionA, 创建 DHCP会话， 重组一个 DHCP Discover单播报文发送其代理的 DHCP服务器。 步骤 S624: DHCP服务器发送含有 IP地址和其他配置信息的 DHCP Offer报文给 DHCP Proxy, 由 DHCP Proxy代为发送给 OpenFlow Switch 0 步骤 S626: DHCP Proxy将收到的 DHCP Offer报文转发 OpenFlow Switch。 步骤 S628: OpenFlow Switch以广播方式向 DHCP Proxy回应 DHCP Request报文 进行确认， DHCP Request报文中可以携带选项 OptionA上报自身信息。 步骤 S630: DHCP Proxy收到 OpenFlow Switch的 DHCP Request报文后， 判断 Option54字段中的 DHCP Server的 IP地址是否与自己代理的 DHCP服务器地址相同。 如果相同， DHCP Proxy解析 DHCP Request报文携带的选项 OptionA, 获取并保存 OpenFlow Switch设备信息。 DHCP Proxy重组一个不携带选项 OptionA 的 DHCP Request单播报文发送 DHCP服务器。 步骤 S632: DHCP服务器收到 DHCP Proxy转发的 DHCP Request报文后， 判断 Option54字段中的 DHCP Server的 IP地址是否与自己的相同。如果相同， DHCP Server 会向 DHCP Proxy发送包含它所提供的 IP地址和其它选项信息的 DHCP Ack确认报文， 由 DHCP Proxy代为发送给 OpenFlow Switch。 步骤 S634: DHCP Proxy收到 DHCP Ack报文后， 将之前本地保存的 OpenFlow
Switch设备信息作为一条记录保存到该 DHCP Proxy本地的 MIB数据表（在 MIB数据 表添加 OpenFlow Switch设备信息的记录为可选动作）， 并用 OpenFlow Switch设备域 名在其 MIB数据表中匹配，将匹配到的 OpenFlow Controller设备信息按优先级排序作 优选建议， 将排序后的 OpenFlow Controller设备信息列表填充扩展选项 OptionB, 然 后 DHCP Proxy重组一个携带扩展选项 OptionB的 DHCP Ack报文， 发送给 OpenFlow Switch。 步骤 S636: OpenFlow Switch收到 DHCP服务器的 DHCP Ack报文后， 解析其中 的扩展选项 OptionB, 从该选项信息获悉自己所属管理域的 OpenFlow Controller设备 地址。 OpenFlow Switch主动尝试和 OpenFlow Controller建链。 步骤 S638 : OpenFlow Controller禾 B OpenFlow Switch 成功建链后， OpenFlow
Controller管理的 OpenFlow Switch数量变化， OpenFlow Controller通过 DHCP Request 报文提前续租，并携带选项 OptionA更新 DHCP服务器本地的 MIB数据表记录。当然 也允许使用 DHCP Inform报文来携带选项 OptionA, 以达到同样的效果。 实施例 5 该实施例主要描述 OpenFlow控制面设备控制器和配置点分离场景下， OpenFlow 转发面设备通过 DHCP服务器发现 OpenFlow控制面设备并正常建链的过程。 为了便 于描述，并仅作为一种示例，本实施例中采用 DHCPv4协议描述该动态发现流程。 DHCP 设备为 DHCP Server, OpenFlow控制面设备为 OpenFlow Controller控制器设备、 OpenFlow Configuration Point酉己置设备， OpenFlow Configuration Point设备上酉己置有 OpenFlow Controller设备的信息， OpenFlow转发面设备为 OpenFlow Switch。 该实施 例不再描述 OpenFlow设备释放地址或离线时 DHCP设备的处理流程， 相关流程可参 考实施例 3的相关描述。 业务详细流程参见图 7所示： 步骤 S702: OpenFlow Configuration Point启动后， 发送 DHCP Discover报文给 DHCP服务器（可以携带已有地址申请）。在 OpenFlow Configuration Point设备发送的 DHCP Discover报文中， 通过扩展选项 OptionA 携带设备角色、 域名等字段信息给 DHCP服务器。扩展的选项 OptionA格式建议详见图 8， DHCP Discover报文也可以不 携带扩展的选项 OptionA, 由 DHCP Request携带该选项。 步骤 S704: DHCP服务器创建 DHCP用户会话，解析 OpenFlow Configuration Point 携带上来的扩展选项 OptionA, 将信息暂存在 DHCP 服务器上。 DHCP 服务器发送 DHCP Offer报文携带分配的 IP地址和其他配置信息给 OpenFlow Configuration Point 0 步骤 S706: OpenFlow Configuration Point选择合适的地址， 并发送 DHCP Request 至 DHCP服务器进行确认，如果 DHCP Discover报文没有携带过选项 OptionA, DHCP Request报文就必须携带选项 OptionA上报自身设备信息。 建议只在 DHCP Request报 文中携带选项 OptionA。 步骤 S708: DHCP服务器收到 DHCP Request后， 解析选项 OptionA中的信息， 同时获取判断 Option54字段中的 DHCP服务器地址是否和自己相同， 如果不同或者 DHCP Request报文超时异常， 则删除步骤 S704 或本步骤中 DHCP 服务器缓存的 OpenFlow Configuration Point的设备角色、 域名等信息记录。 如果相同， DHCP服务 器发送 DHCP Ack报文给 OpenFlow Configuration Point,同时将 OpenFlow Configuration Point的设备信息作为一条记录写入 DHCP服务器本地的 MIB数据表。 步骤 S710: NMS查询 DHCP服务器的 MIB数据表， 获悉 DHCP服务器学习到的 OpenFlow Configuration Point信息。 该步骤前面的描述动作和前后步骤没有严格时序 关系。 也允许 DHCP 服务器通过特定的接口主动上报自己学习到的 OpenFlow Configuration Point的信息。 步骤 S712: OpenFlow Switch发送 DHCP Discover报文至 DHCP服务器申请 IP 地址， 也可以携带选项 OptionA上报自身设备信息给 DHCP服务器， 但是不建议在此 报文中携带。 步骤 S714: DHCP服务器发送含有 IP地址和其他配置信息的 DHCP Offer报文给 OpenFlow Switch设备。 步骤 S716: OpenFlow Switch以广播方式向各 DHCP服务器回应 DHCP Request 报文进行确认， DHCP Request报文中可以携带选项 OptionA上报自身信息。 步骤 S718: DHCP服务器收到 OpenFlow Switch的 DHCP Request报文后， 判断
Option54字段中的 DHCP Server的 IP地址是否与自己的相同。如果相同， DHCP服务 器会向 OpenFlow Switch发送包含它所提供的 IP地址和其它选项信息的 DHCP ACK 确认报文。 同时 DHCP 服务器解析 DHCP Request报文携带的选项 OptionA, 获取 OpenFlow Switch设备信息， 将其一条记录保存到该 DHCP服务器本地的 MIB数据表 (在 MIB数据表添加 OpenFlow Switch设备信息的记录为可选动作）， 并用 OpenFlow Switch设备域名在其 MIB数据表中匹配， 将匹配到的 OpenFlow Configuration Point 设备信息按优先级排序作优选建议， 将排序后的 OpenFlow Configuration Point设备信 息列表填充扩展选项 OptionB, 由 DHCP Ack报文携带给 OpenFlow Switch。 步骤 S720: OpenFlow Switch收到 DHCP服务器的 DHCP ACK报文后， 解析其中 的扩展选项 OptionB, 从该选项信息获悉自己所属管理域的 OpenFlow Configuration Point设备地址。 OpenFlow Switch主动尝试和 OpenFlow Configuration Point建链， 建 链后 OpenFlow Configuration Point酉己置 OpenFlow Switch, 告知其 OpenFlow Controller 的地址。 步骤 S722: OpenFlow Configuration Point 禾 B OpenFlow Switch 成功建链后， OpenFlow Configuration Point 管理的 OpenFlow Switch 数量变化， OpenFlow Configuration Point通过 DHCP Request报文提前续租，并携带选项 OptionA更新 DHCP 服务器本地的 MIB 数据表记录。 当然也允许使用 DHCP Inform 报文来携带选项 OptionA, 以达到同样的效果。 步骤 S724: OpenFlow Switch 获知 OpenFlow Controller 的地址后， 尝试和该 OpenFlow Controller建链。 该步骤和步骤 S722没有严格的时序关系。 步骤 S726: OpenFlow Controller和 OpenFlow Switch建链后， 根据需要， 可以根 据特定的接口向 OpenFlow Configuration Point通告自身的负荷信息， 供 OpenFlow Configuration Point管理多个 OpenFlow Controller时，能够根据某种策略调整 OpenFlow Switch选择建链的 OpenFlow Controller, 实现 SDN基础网络控制流的负载均衡。 该步 骤可选操作， 不做强制要求。 本实施例提供了 DHCP设备回应 OpenFlow转发面设备的 DHCP Ack报文中携带 的扩展选项 OptionBl来告知其 OpenFlow控制面设备信息列表， 选项 OptionBl格式 建议详见图 9， 如果是 DHCPV6协议， 那么本发明建议在 DHCPv6 Reply报文中下发 OpenFlow控制面设备信息列表的扩展选项 OptionB2， 选项 OptionB2格式建议详见图 10。 本发明的上述实施例， 可以通用于 SDN转发面设备（包括支持 OpenFlow等 SDN 南向接口协议的所有转发面设备， 例如 AP、 交换器、 路由器） 发现 SDN控制器的场 景的应用场景。 在另外一个实施例中， 还提供了一种软件， 该软件用于执行上述实施例及优选实 施方式中描述的技术方案。 在另外一个实施例中， 还提供了一种存储介质， 该存储介质中存储有上述软件， 该存储介质包括但不限于： 光盘、 软盘、 硬盘、 可擦写存储器等。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而， 可以 将它们存储在存储装置中由计算装置来执行， 并且在某些情况下， 可以以不同于此处 的顺序执行所示出或描述的步骤， 或者将它们分别制作成各个集成电路模块， 或者将 它们中的多个模块或步骤制作成单个集成电路模块来实现。 这样， 本发明不限制于任 何特定的硬件和软件结合。 以上仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技术人 员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的任何 修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。 工业实用性 本发明提供的上述技术方案， 可以应用于控制面设备的发现处理过程中， 采用根 据转发面设备的标识信息匹配得到控制面设备信息， 并将该控制面设备信息发送至转 发面设备的技术手段， 解决了相关技术中， 尚无有效地让转发面设备自动发现控制面 设备的技术问题， 从而实现了转发面设备对控制面设备的自动发现， 进而可以实现转 发面设备可以对控制面设备的自适应调整。

Claims

权 利 要 求 书
1. 一种基于开放流 OpenFlow协议的控制面设备的发现处理方法， 包括：
接收来自基于 OpenFlow协议的转发面设备的标识信息， 其中， 所述标识 信息为所述转发面设备的标识信息， 所述标识信息与管理信息数据库中的控制 面设备信息相对应；
根据所述标识信息在所述管理信息数据库中匹配得到所述控制面设备信 息；
向所述转发面设备发送所述控制面设备信息。
2. 根据权利要求 1所述的方法， 其中， 在接收所述标识信息之前， 包括：
获取软件定义网络 SDN 中预先分域后指定域中的各个所述控制面设备信 息；
将所述指定域中各个所述控制面设备信息存储至所述管理信息数据库。
3. 根据权利要求 2所述的方法， 其中， 所述标识信息包括： 所述转发面设备所属 所述指定域的域名信息。
4. 根据权利要求 1至 3任一项所述的方法，其中，所述方法应用于 SDN中的动态 主机配置协议 DHCP设备。
5. 根据权利要求 4所述的方法， 其中， 向所述转发面设备发送所述控制面设备信 息包括：
通过 DHCP 报文中的指定字段向所述转发面设备发送所述控制面设备信 息。
6. 根据权利要求 5所述的方法， 其中， 所述指定字段包括： 选项 Option字段。
7. 根据权利要求 3所述的方法， 其中， 接收来自基于 OpenFlow协议的转发面设 备的标识信息时， 还包括：
接收所述转发面设备的请求消息， 其中， 该请求消息用于请求所述 DHCP 设备为所述转发面设备分配地址。
8. 根据权利要求 4所述的方法， 其中， 还包括: 接收网络管理系统 NMS的查询请求消息；
在所述查询请求消息的触发下， 通过所述 NMS将所述管理信息数据库中 的所述控制面设备信息发送至所述 SDN中除所述 DHCP设备之外的其它 DHCP 设备。 一种基于开放流 OpenFlow协议的控制面设备的发现处理装置， 包括：
接收模块， 设置为接收来自基于 OpenFlow协议的转发面设备的标识信息， 其中， 所述标识信息为所述转发面设备的标识信息， 所述标识信息与管理信息 数据库中的控制面设备信息相对应；
匹配模块， 设置为根据所述标识信息在所述管理信息数据库中匹配得到所 述控制面设备信息；
发送模块， 设置为向所述转发面设备发送所述控制面设备信息。 根据权利要求 9所述的装置， 其中， 包括：
获取模块，设置为获取软件定义网络 SDN中预先分域后指定域中的各个所 述控制面设备信息；
存储模块， 设置为将所述指定域中各个所述控制面设备信息存储至所述管 理信息数据库。
PCT/CN2013/083803 2013-03-15 2013-09-18 基于开放流协议的控制面设备的发现处理方法及装置 WO2014139276A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP13877653.9A EP2975807B1 (en) 2013-03-15 2013-09-18 Method and apparatus for discovering openflow protocol-based control plane device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310082998.X 2013-03-15
CN201310082998.XA CN103209121B (zh) 2013-03-15 2013-03-15 基于开放流协议的控制面设备的发现处理方法及装置

Publications (1)

Publication Number Publication Date
WO2014139276A1 true WO2014139276A1 (zh) 2014-09-18

Family

ID=48756210

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/083803 WO2014139276A1 (zh) 2013-03-15 2013-09-18 基于开放流协议的控制面设备的发现处理方法及装置

Country Status (3)

Country Link
EP (1) EP2975807B1 (zh)
CN (1) CN103209121B (zh)
WO (1) WO2014139276A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10931521B2 (en) 2017-09-01 2021-02-23 Industrial Technology Research Institute Software defined network system with auto-deployed switch and method for deploying switch
CN116743570A (zh) * 2023-08-16 2023-09-12 新华三技术有限公司 设备的自动化上线方法、装置、电子设备及介质

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8817625B1 (en) * 2013-09-13 2014-08-26 Telefonaktiebolaget L M Ericsson (Publ) Service placement for inline services chaining with multiple instances
CN103209121B (zh) * 2013-03-15 2019-02-01 中兴通讯股份有限公司 基于开放流协议的控制面设备的发现处理方法及装置
CN104782087B (zh) * 2013-07-19 2018-03-13 华为技术有限公司 交换设备、控制器、交换设备配置、报文处理方法及系统
CN104348757B (zh) * 2013-07-31 2018-03-16 华为技术有限公司 一种流表交互方法、交换机及系统
CN103688510B (zh) * 2013-09-13 2016-05-25 华为技术有限公司 跨网通信方法及装置
CN104468415A (zh) * 2013-09-16 2015-03-25 中兴通讯股份有限公司 上报交换机类型的方法及装置
CN104468168B (zh) * 2013-09-18 2018-01-23 华为技术有限公司 网络故障恢复方法、控制服务器及交换机
CN105960789A (zh) * 2013-09-20 2016-09-21 诺基亚通信管理国际两合公司 对软件定义的架构中的数据平面上的信令消息的处理
CN104580021B (zh) * 2013-10-17 2018-07-13 华为技术有限公司 一种配置点连接信息的获取方法及装置
CN103618621B (zh) * 2013-11-21 2017-08-11 华为技术有限公司 一种软件定义网络sdn的自动配置方法、设备及系统
CN103647658B (zh) * 2013-11-27 2016-12-07 华为技术有限公司 一种软件定义网络系统中网络设备的管理方法和控制器
WO2015081526A1 (zh) * 2013-12-05 2015-06-11 华为技术有限公司 软件定义网络中的控制方法，控制设备和处理器
WO2015090363A1 (en) * 2013-12-17 2015-06-25 Nokia Solutions And Networks Management International Gmbh Handover in software defined networking
CN104734988B (zh) * 2013-12-23 2018-10-30 杭州华为数字技术有限公司 软件定义网络中路由控制的方法和开放流控制器
CN104754762B (zh) * 2013-12-30 2019-12-03 中兴通讯股份有限公司 软件自定义网络中自动发现控制器的方法、控制器及系统
CN104753791B (zh) * 2013-12-31 2019-01-01 中国移动通信集团公司 一种数据包处理方法、装置和系统
CN104767720A (zh) * 2014-01-08 2015-07-08 中兴通讯股份有限公司 一种软件定义网络中OpenFlow消息跟踪和过滤的方法
CN104796344B (zh) * 2014-01-16 2020-01-14 中兴通讯股份有限公司 基于SDN实现报文转发的方法、系统、Openflow交换机及服务器
CN103780517A (zh) * 2014-01-20 2014-05-07 江苏省未来网络创新研究院 一种用于不同版本OpenFlow控制器与交换机协同工作的驱动系统及驱动方法
CN104811403B (zh) * 2014-01-27 2019-02-26 中兴通讯股份有限公司 基于开放流的组表处理方法、装置及组表配置单元
CN103763207B (zh) * 2014-01-29 2017-03-15 杭州华三通信技术有限公司 软件定义网络中的带内控制连接建立方法及设备
US9749214B2 (en) * 2014-02-26 2017-08-29 Futurewei Technologies, Inc. Software defined networking (SDN) specific topology information discovery
CN104901825B (zh) * 2014-03-05 2019-02-19 新华三技术有限公司 一种实现零配置启动的方法和装置
CN104954271B (zh) 2014-03-26 2018-11-30 国际商业机器公司 Sdn网络中的数据包处理方法和装置
CN104205745B (zh) * 2014-04-04 2017-02-15 华为技术有限公司 报文处理的方法与设备
CN105264839B (zh) * 2014-04-16 2019-01-18 华为技术有限公司 基于软件定义网络的组网方法及设备
CN105450525B (zh) * 2014-05-28 2018-05-01 国际商业机器公司 用于路由交换设备使用的方法和设备
WO2015180177A1 (zh) * 2014-05-30 2015-12-03 华为技术有限公司 一种网络配置方法、装置及系统
EP2966830B1 (en) * 2014-06-06 2017-08-16 Huawei Technologies Co., Ltd. Method, apparatus and system for interacting information in access network
CN104168202B (zh) * 2014-08-26 2017-10-24 华为技术有限公司 开放流报文转发方法及装置
CN105792284A (zh) * 2014-12-22 2016-07-20 中国移动通信集团公司 一种网络控制方法、装置及系统
US10432510B2 (en) 2015-01-30 2019-10-01 Hewlett Packard Enterprise Development Lp Forwarding table of hybrid software defined networking switch
CN107409088B (zh) * 2015-05-15 2020-02-14 华为技术有限公司 一种数据包转发方法和网络设备
CN106331206B (zh) * 2015-06-30 2019-08-23 新华三技术有限公司 域名管理方法及装置
JP6573717B2 (ja) * 2015-09-30 2019-09-11 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． サービスフロー処理ポリシーのための処理方法、装置、およびシステム
CN105207908B (zh) * 2015-09-30 2018-09-18 浪潮(北京)电子信息产业有限公司 一种报文处理方法及系统
CN107104811B (zh) * 2016-02-22 2021-08-17 中兴通讯股份有限公司 一种网络功能实现方法及控制装置
US11349922B2 (en) 2016-04-06 2022-05-31 Marvell Asia Pte Ltd. System and method for a database proxy
US10237350B2 (en) * 2016-04-06 2019-03-19 Reniac, Inc. System and method for a database proxy
CN107566278B (zh) * 2016-07-01 2021-12-21 中兴通讯股份有限公司 传输方法、装置及系统
CN106231003B (zh) * 2016-07-28 2019-09-17 新华三技术有限公司 一种地址分配方法及装置
CN106790656B (zh) * 2017-01-19 2019-12-31 南京贝伦思网络科技股份有限公司 一种基于sdn的负载均衡装置及其方法
WO2019000332A1 (zh) * 2017-06-29 2019-01-03 华为技术有限公司 转发器和控制器建立连接的方法和装置
CN107896182B (zh) * 2017-11-30 2020-09-08 新华三技术有限公司 报文转发方法及装置
CN111464454B (zh) * 2020-03-02 2022-03-18 烽火通信科技股份有限公司 一种数据中心内虚拟bras设备负载分担方法及系统
US11429595B2 (en) 2020-04-01 2022-08-30 Marvell Asia Pte Ltd. Persistence of write requests in a database proxy

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102594697A (zh) * 2012-02-21 2012-07-18 华为技术有限公司 负载均衡方法及负载均衡装置
WO2012137646A1 (ja) * 2011-04-04 2012-10-11 日本電気株式会社 ネットワークシステム、スイッチ、及び接続端末検知方法
CN102938794A (zh) * 2012-11-14 2013-02-20 华为技术有限公司 地址解析协议arp消息转发方法、交换机和控制器
CN103209121A (zh) * 2013-03-15 2013-07-17 中兴通讯股份有限公司 基于开放流协议的控制面设备的发现处理方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012137646A1 (ja) * 2011-04-04 2012-10-11 日本電気株式会社 ネットワークシステム、スイッチ、及び接続端末検知方法
CN102594697A (zh) * 2012-02-21 2012-07-18 华为技术有限公司 负载均衡方法及负载均衡装置
CN102938794A (zh) * 2012-11-14 2013-02-20 华为技术有限公司 地址解析协议arp消息转发方法、交换机和控制器
CN103209121A (zh) * 2013-03-15 2013-07-17 中兴通讯股份有限公司 基于开放流协议的控制面设备的发现处理方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2975807A4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10931521B2 (en) 2017-09-01 2021-02-23 Industrial Technology Research Institute Software defined network system with auto-deployed switch and method for deploying switch
CN116743570A (zh) * 2023-08-16 2023-09-12 新华三技术有限公司 设备的自动化上线方法、装置、电子设备及介质
CN116743570B (zh) * 2023-08-16 2023-10-24 新华三技术有限公司 设备的自动化上线方法、装置、电子设备及介质

Also Published As

Publication number Publication date
CN103209121B (zh) 2019-02-01
EP2975807B1 (en) 2019-03-27
EP2975807A4 (en) 2016-04-20
CN103209121A (zh) 2013-07-17
EP2975807A1 (en) 2016-01-20

Similar Documents

Publication Publication Date Title
WO2014139276A1 (zh) 基于开放流协议的控制面设备的发现处理方法及装置
US9935781B2 (en) Managing a large network using a single point of configuration
US10050824B2 (en) Managing a cluster of switches using multiple controllers
CN113364610B (zh) 网络设备的管理方法、装置及系统
JP3850391B2 (ja) ＶＲＲＰ（ＶｉｒｔｕａｌＲｏｕｔｅｒＲｅｄｕｎｄａｎｃｙＰｒｏｔｏｃｏｌ）によるルータ・インターフェース・バックアップ実行方法
US8121136B2 (en) Dynamic discovery mechanisms via inter-domain routing protocol
US8451839B2 (en) Method and apparatus for managing route information and forwarding data in access devices
US9276898B2 (en) Method and device for link fault detecting and recovering based on ARP interaction
WO2015131560A1 (zh) 一种分配分段路由标记的方法和分段路由节点
US9876712B2 (en) Method and device for processing address resolution protocol in software-defined networking environment
TW201344576A (zh) 韌體更新方法與系統以及使用該方法之終端裝置
US10021030B2 (en) Method and system for forwarding information in distributed network
JP2006135970A (ja) ＳｏｆｔＲｏｕｔｅｒ動的バインディング・プロトコル
WO2006058206A2 (en) A method of subnet roaming within a network
WO2014116148A1 (en) Methods and arrangements for checking connectivity and detecting connectivity failure
JP2003298635A (ja) ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法
US10404544B2 (en) Network topology determining method and apparatus, and centralized network status information storage device
WO2014075216A1 (zh) 一种虚拟集群建立的方法及网络设备
JP2022052741A (ja) 境界ゲートウェイプロトコルのためのターゲットネイバー探索
JP3996922B2 (ja) 異なる通信プロトコルが併存するネットワークにおけるネットワーク接続手段の一元管理システム及び方法
KR101755829B1 (ko) Ｓｄｎ 환경에서 ａｒｐ 처리 방법 및 장치
Cisco Configuring Novell IPX
JP3613207B2 (ja) Ａｒｐテーブル形成方法及びこれを用いた経路制御方法
US20240205135A1 (en) Managing connection timers for border gateway protocol in a computing environment
WO2015106506A1 (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: 13877653

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2013877653

Country of ref document: EP