A method and apparatus for a server-based local address allocation protocol

Abstract

A method of a server-based local address allocation protocol in which a client generates a host identifier (HID) from a random number and uses the HID to generate an initial message requesting a local address. The initial message is then sent and response messages sent from the server in response to the initial message are received, a first response message is selected from among the response messages, and a media access control (MAC) address is extracted from the first response message.

Description

[0001] Related applications cross-application

[0002] This invention claims priority to U.S. Provisional Application No. 62 / 129,251, entitled “Server-Based Local Address Assignment Protocol,” filed March 6, 2015, by Donald E. Eastlake III et al., the contents of which are incorporated herein by reference.

[0003] Statement regarding research or development sponsored by the federal government

[0004] not applicable

[0005] Reference Microfilm Appendix

[0006] not applicable Technical Field

[0007] none Background Technology

[0008] Manufacturers of traditional hardware network components such as servers, proxies, and clients request media access control (MAC) addresses and receive these MAC addresses from a registration authority (RA), such as the Institute of Electrical and Electronics Engineers (IEEE) standards association registration authority. MAC addresses are also known as physical addresses. While MAC addresses are typically intended to provide a unique address for each node in a local area network (LAN), they are also globally unique identifiers (IDs). The original IEEE MAC address standard provided over 281 trillion unique MAC addresses.

[0009] A virtual machine (VM) is a software implementation of a hardware machine that executes programs just like the hardware machine. VMs do not have physical MAC addresses because they are virtual, but MAC addresses may need to be assigned to them. The Internet of Things (IoT) is a network of physical devices with embedded sensors and network connectivity that enables those devices to exchange data. MAC addresses may also need to be assigned to IoT devices. However, with the rapid proliferation of IoT components, there will not be a sufficient number of unique MAC addresses to accommodate the expected number of IoT devices. Therefore, it remains necessary to provide MAC addresses for VMs and IoT devices in a sustainable manner. Summary of the Invention

[0010] In one embodiment, the present invention includes an apparatus comprising: a memory; and a processor coupled to the memory and configured to: perform random number generation; generate a host identifier (HID) based on the random number generation, wherein the HID is substantially unique within a local network; and generate an initial message requesting a local address using the HID. In some embodiments, the apparatus is an endpoint client in a local network; the HID includes a plurality of bits, wherein the number of bits is guaranteed to be within a probability that the HID is unique within the local network; the HID is at least 48 bits; the initial message includes a destination media access control (DMAC) field, a source media access control (SMAC) field, an EtherType field, and a server local address assignment (SMAC) field. The processor further comprises a protocol (S-LAAP) type field and an HID field; wherein the DMAC field includes a multicast address, the SMAC field includes a first value indicating that the local address is unknown, the EtherType field includes two octets indicating the S-LAAP protocol, the S-LAAP type field includes a second value indicating that the initial message is of type Initial Message, and the HID field includes the HID; wherein the processor is further configured to select from a plurality of response messages in response to an Initial Message originating from a server a first response message including a local address portion and a Media Access Control (MAC) address based on the local address portion; wherein the processor is further configured to generate an acknowledgment message in response to the first response message, and wherein the acknowledgment message includes the destination address; The device comprises a Direct Media Access Control (DMAC) field, a Source Media Access Control (SMAC) field, an EtherType field, a Server Local Address Allocation Protocol (S-LAAP) type field, and an HID field; wherein the DMAC field includes a multicast address, the SMAC field includes a MAC address, the EtherType field includes two octets indicating the S-LAAP protocol, the S-LAAP type field includes a value indicating that the acknowledgment message is of acknowledgment message type, and the HID field includes the HID; the device further comprises a transmitter coupled to the processor for transmitting initial messages and acknowledgment messages to a proxy; the device further comprises a transmitter coupled to the processor for transmitting initial messages and acknowledgment messages to intermediate nodes.

[0011] In another embodiment, the invention includes a proxy comprising: a first port for receiving an initial message from a client, wherein the initial message includes a host identifier (HID) that substantially uniquely identifies a client within a local network; a processor coupled to the first port for modifying the initial message to generate a modified initial message including a port value corresponding to the first port; and a transmitter coupled to the processor for transmitting the modified initial message to a server located outside the local network. In some embodiments, the modified initial message includes a Target Media Access Control (DMAC) field, a Source Media Access Control (SMAC) field, an EtherType field, a Server Local Address Allocation Protocol (S-LAAP) type field, an HID field, and a port field; the DMAC field includes a multicast address, the SMAC field includes a proxy Media Access Control (MAC) address, the EtherType field includes two octets indicating the S-LAAP protocol, the S-LAAP type field includes a value indicating that the initial message is of type initial message, the HID field includes the HID, and the port field includes the port value; the proxy further includes a second port coupled to the processor and used to receive a response message from the server, wherein the response message includes the client's Media Access Control (MAC) address and the port value; the proxy is used to transmit a response message to the client via the first port in response to receiving a response message from the first server.

[0012] In another embodiment, the present invention includes a method comprising: performing random number generation; generating a host identifier (HID) based on the random number generation, wherein the HID is substantially unique within a local network; generating an initial message requesting a local address using the HID; and transmitting the initial message. In some embodiments, generating the initial message includes: generating a Target Media Access Control (DMAC) field including a multicast address; generating a Source Media Access Control (SMAC) field including a first value indicating that the local address is unknown; generating an EtherType field including two octets indicating a Server Local Address Allocation Protocol (S-LAAP) protocol; generating an S-LAAP type field including a second value indicating that the initial message is an initial message type; and generating an HID field including the HID; the method further includes: receiving a response message in response to the originating end of the initial message; selecting a first response message from the response messages based on at least one criterion; and extracting a Media Access Control (MAC) address from the first response message; the method further includes: generating an acknowledgment message in response to the first response message by: generating a Target Media Access Control (DMAC) field including a multicast address; generating a Source Media Access Control (SMAC) field including a MAC address; generating an EtherType field including two octets indicating a S-LAAP protocol; generating a Server Local Address Allocation Protocol (S-LAAP) type field including a value indicating that the acknowledgment message is an acknowledgment message type; and generating an HID field including the HID.

[0013] These and other features will become clearer from the following detailed description taken in conjunction with the accompanying drawings and claims. Attached Figure Description

[0014] To gain a more thorough understanding of the invention, reference is now made to the following brief description taken in conjunction with the accompanying drawings and specific embodiments, wherein like reference numerals denote like parts.

[0015] Figure 1 This is a schematic diagram of a network system according to an embodiment of the present invention.

[0016] Figure 2 This is a message sequence diagram illustrating address allocation negotiation using a proxy according to an embodiment of the present invention.

[0017] Figure 3 yes Figure 2 A diagram illustrating the initial message in the program.

[0018] Figure 4 To explain in more detail Figure 2 The flowchart for step 230.

[0019] Figure 5 To explain in more detail Figure 2 The flowcharts for steps 240 and 250.

[0020] Figure 6 yes Figure 2 A diagram illustrating the response message.

[0021] Figure 7 To explain in more detail Figure 2 The flowchart for step 260.

[0022] Figure 8 yes Figure 2 A diagram illustrating the confirmation message.

[0023] Figure 9 To explain in more detail Figure 2 The flowchart for step 280.

[0024] Figure 10 To explain in more detail Figure 2 The flowchart for step 290.

[0025] Figure 11 This is a message sequence diagram illustrating address allocation negotiation using intermediate nodes according to an embodiment of the present invention.

[0026] Figure 12 This is a flowchart illustrating a method for generating a host identifier (HID) and transmitting an initial message according to an embodiment of the present invention.

[0027] Figure 13 This is a schematic diagram of a network device according to an embodiment of the present invention. Detailed Implementation

[0028] First, it should be understood that although illustrative embodiments of one or more examples are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or existing. The invention should not in any way be limited to the illustrative embodiments, figures, and techniques described below, but includes the exemplary designs and embodiments illustrated and described herein, and can be modified within the full scope of the appended claims and their equivalents.

[0029] The IEEE Std 802-2014, “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture,” June 12, 2014, and IEEE P802c / D0.2, “Standard for Local and Metropolitan Area Networks: Overview and Architecture - Draft Amendment: Local Medium Access Control Address Usage,” February 2016, both incorporated by reference (collectively, “IEEE 802”), describe approaches to resolving the MAC addressing issues for VMs and IoT devices. Specifically, IEEE 802 describes MAC addresses with two parts: a globally assigned address portion and a local address portion. The RA still assigns the globally assigned address portion to the server, but the server can assign the local address portion. For example, a server in a LAN can use and reuse the local address according to its own protocol. Therefore, such protocols allow VMs and IoT components to obtain local addresses without having to request those addresses and receive them from a centralized RA.

[0030] One such protocol is described in "Dynamic Host Configuration Protocol," Internet Engineering Task Force (IETF), March 1997, and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," IETF, July 2003 (collectively, "DHCP"), which is incorporated herein by reference. DHCP is a mature protocol that uses multicast messages, supports redundant servers, and supports proxying between clients and servers. However, VMs and IoT devices may not initially have MAC addresses. Therefore, when they request a local address or local ID from a server, the server cannot know which devices initiated the request, and the server cannot individually address and respond to the requesting devices by including the requested local address or local ID in the message.

[0031] This document discloses an embodiment of a server-based local address allocation protocol. The protocol may be referred to as Server Local Address Allocation Protocol (S-LAAP, pronounced "ess-lap"). In S-LAAP, the client generates its own HID. The client can be a VM or IoT device. The HID has a very high probability of being a locally unique ID. The server and other nodes do not generate HIDs. Using the HID, the client requests a local address from the server. Therefore, the client does not need a MAC address to request a local address from the server. The proxy or server records port information indicating which ports receive the request and then responds to the request using the same ports. The proxy may optionally not record the port information but actually add the port information to the request it forwards to the server. The server then adds the port information to its response back to the proxy. The response includes the MAC address and may include the duration for which the requesting device can use the MAC address during this period. The local address is locally unique. The response includes, or the server may transmit, a Layer 2 MAC address and may also include a Layer 3 Internet Protocol (IP) address. S-LAAP may be a new, standalone standard or an extension of existing standards such as IEEE 802 or DHCP.

[0032] Figure 1 This is a schematic diagram of a network system 100 according to an embodiment of the present invention. System 100 typically includes a wider network 140 coupled to local networks 105, 106, and 145. Although system 100 is shown as including only local networks 105, 106, and 145 coupled to the wider network 140, any suitable number of local networks may exist.

[0033] Local networks 105 and 106 are S-LAAP networks, meaning they employ S-LAAP. Local networks 105 and 106 can each be referred to as LANs. Local networks 105 and 106 are connected via a Layer 3 switch 127. Local network 105 includes clients 110 and 115 and a portion of switch 127. Local network 106 includes clients 120 and 121, intermediate node 130, a portion of switch 127, and server 135. Agent 125 may be located within local network 105 as shown or may be incorporated into and part of switch 127. Although local networks 105 and 106 are shown as including only those components or nodes, any suitable number of such nodes may exist. In this context, the term "local" refers to a local network, in contrast to a wider network such as wider network 140. A local network can refer to a group of nodes communicating at Layer 2 or below the Open Systems Interconnection (OSI) model, in contrast to a group of nodes communicating at Layer 3 or above the OSI model. Alternatively, a local network can refer to a group of nodes that are geographically close to each other, such as a group of nodes in the same building. In this context, a local network can mean that broadcast messages reach all end sites within the local network and multicast messages reach all end sites of interest.

[0034] Clients 110, 115, 120, and 122 are S-LAAP clients and are hardware network components, VMs, or IoT devices. Clients 110, 115, 120, and 122 are typically endpoints in system 100 and specifically endpoints in local networks 105 and 106. When clients 110, 115, 120, and 122 are VMs, they can be software themselves but may be implemented in larger hardware devices such as agent 125. When clients 110, 115, 120, and 122 are IoT devices, they can communicate within local networks 105 and 106 using hardware network components such as agent 125. Clients 110 and 115 communicate with server 135 via agent 125. Clients 120 and 122 communicate with server 135 via intermediate node 130.

[0035] Agent 125 is a hardware network component or a software implementation within a hardware network component. If clients 110 and 115 are VMs, then agent 125 may include clients 110 and 115. Regardless of whether clients 110 and 115 are VMs or IoT devices, agent 125 provides components for clients 110 and 115 to communicate within local network 105. Specifically, agent 125 acts as a forwarding node for clients 110 and 115.

[0036] Intermediate node 130 may resemble client 110 and may represent a series of such nodes. Both proxy 125 and intermediate node 130 act as intermediaries between clients 110, 115, 120, and 122, and between clients 110, 115, 120, and 122, and between clients 110, 115, 120, and 122, and between clients 110, 115, and 122, and between clients 110, 115, and 122, and between clients 110, 115, and 122, and between clients 110, 115, and 122, and between clients 110, 120, and 122, respectively. If the S-LAAP server and all clients are on the same local network, such as local network 106, then no proxy is required.

[0037] Server 135 is an S-LAAP server and is either a hardware network component or a software implementation of a hardware network component. Server 135 enables access to the wider network 140 for other components in local networks 105 and 106 that initially do not have MAC addresses. In contrast to agent 125, server 135 maintains a database of resources, including MAC addresses, for allocation. Because server 135 is a hardware network component or hosted within a hardware network component, it can have MAC addresses allocated via RA. The functions of clients 110, 115, 120, and 122; agent 125; intermediate node 130; and server 135 are further described below.

[0038] Wider network 140 acts as an intermediary between local networks 105 and 106 and local network 145. For example, wider network 140 could be the Internet. In this context, the term "wider" refers to a wider network, in contrast to local networks such as local networks 105, 106, and 145. A wider network can also refer to a group of nodes communicating at layer 3 or above the OSI model, in contrast to a group of nodes communicating at layer 2 or below the OSI model. Alternatively, a wider network can refer to a group of nodes that are geographically distant from each other, such as a group of nodes spanning one or more countries.

[0039] Local network 145 is similar to local networks 105 and 106. Local network 145 may or may not be an S-LAAP network. Client 150 is similar to clients 110, 115, 120, and 122. Client 150 may or may not be an S-LAAP client.

[0040] exist Figure 1 The system 100 has been simplified. Therefore, system 100 may include other components, such as bridges, routers, and additional agents and servers. Furthermore, the components of system 100 can be arranged in any suitable manner. For example, server 135 may be located in conjunction with a router.

[0041] Figure 2Figure 200 illustrates a message sequence diagram of address allocation negotiation using a proxy according to an embodiment of the present invention. Proxy 125 and server 135 perform the negotiation. Specifically, Figure 200 shows the negotiation between client 110, proxy 125, and server 135. Of course, the same principle applies between any suitable components.

[0042] Before step 210, client 110 wishes to communicate with client 150. To do this, client 110 must have a MAC address. If client 110 is a VM or IoT device, then client 110 may not initially have a MAC address. In this case, client 110 must obtain a MAC address from server 135. However, as mentioned above, server 135 may not have a way to identify messages from client 110 or address messages to client 110.

[0043] At step 210, client 110 generates an HID. Client 110 does this using a random number generator to generate an HID of an appropriate size, such as a 48- or 64-bit HID. Some methods for generating such random numbers are provided in “Randomness Requirements for Security,” IETF RFC 4086, June 2005, which is incorporated herein by reference. Alternatively, the choice of bit length is guaranteed to be within an acceptable probability, i.e., the HID is locally unique based on the number of nodes in the local network that can simultaneously generate HIDs. In this case, the HID is substantially unique. The probability is any suitable probability, such as approximately 98 percent (%) or approximately 99% over 100 years of use. The HID only needs to be unique or substantially unique within a given time period, such as a second or a portion of several seconds, during which there are unresolved S-LAAP requests with pending responses.

[0044] At step 220, client 110 generates an initial message, packet, or frame and transmits it to agent 125. The initial message is a multicast or broadcast message, therefore the local network also delivers the initial message to other available nodes. In one embodiment, the initial message is shown as... Figure 3 middle.

[0045] Figure 3 yes Figure 2A schematic diagram of the initial message 300. The initial message 300 is a multicast or broadcast message and includes a Destination MAC (DMAC) field 310, a Source MAC (SMAC) field 320, an EtherType field 330, an S-LAAP type field 340, and an HID field 350. Multicast and broadcast messages can be collectively referred to as groupcast messages. The fields in the initial message 300 are in any suitable order and include any suitable number of digits. These fields may conform to existing standards such as DHCP to extend such standards.

[0046] DMAC field 310 includes the destination address (DA). However, client 110 may not know the address of proxy 125 or any other node. Therefore, DA is a special multicast or broadcast address, the latter of which can be all 1s.

[0047] SMAC field 320 includes the source address (SA). However, client 110 may not have or know its client MAC address. Therefore, SA is a special value indicating that the MAC address is unknown and includes, for example, all 0s or all 1s. This special value indicates that client 110 does not have or know its client MAC address.

[0048] The EtherType field 330 includes a new EtherType or a subtype of an existing EtherType. EtherType is a two-octet field used to indicate the protocol used for the initial message 300, the size of the initial message 300, or both. In this case, the EtherType field 330 may include an allocation value indicating S-LAAP. The S-LAAP type field 340 includes a value indicating the type of S-LAAP message. In this case, the value indicates that the initial message 300 is an initial message. The HID field 350 includes... Figure 2 The HID generated by client 110 in step 210.

[0049] The initial 300 message may also include additional fields. For example, the initial message may include additional client information such as verification, authorization, authentication, or other information. Verification information may be a date and time, a configuration string, security information, or billing information such as an account number. Security information may include one or more message verification codes or digital signatures.

[0050] Return to Figure 2At step 230, agent 125 receives initial message 300; corrects initial message 300 to generate corrected initial message 300'; and transmits corrected initial message 300' to server 135. Alternatively, agent 125 does not correct the initial message 300, but actually forwards the initial message 300 based on the DA in the DMAC field 310. In other words, agent 125 forwards the initial message 300 to multiple nodes because the DA is a special multicast or broadcast address. Agent 125 is used because the initial message 300, as a multicast or broadcast message, would have to otherwise flood into the local network containing the server. The use of the agent allows the influx of initial message 300 to be confined to local network 105 and not extended to local network 106, thus reducing network load while still providing service to clients in local network 105.

[0051] Figure 4 To explain in more detail Figure 2 The flowchart for step 230 is shown below. At step 410, agent 125 receives initial message 300. At decision diamond 420, agent 125 determines whether the SA from SMAC field 320 is a special value, such as all 0 or all 1. If not, agent 125 proceeds to step 460. If yes, agent 125 proceeds to step 430. At step 430, agent 125 corrects SMAC field 320 to include the agent MAC address belonging to agent 125. After step 430, agent 125 determines whether to proceed to step 440 or step 450 based on design choice. Alternatively, agent 125 may complete neither step 440 nor step 450, or both steps 440 and 450. The dashed line indicates this design choice.

[0052] At step 440, agent 125 records in the agent lookup table the HID from HID field 350, the port value indicating the port via which agent 125 receives initial message 300, and the HID-port association between the two. At step 450, agent 125 corrects or adds to the port field. Finally, at step 460, agent 125 transmits the corrected initial message 300' based on the DA in DMAC field 310. Specifically, agent 125 transmits the corrected initial message 300' to multiple nodes, including server 135, because the DA is a special multicast address. If agent 125 as Figure 1 As shown in the diagram, if the modified initial message 300' is in local network 105, then it will transmit the modified initial message 300' via unicast to one or more servers that are not in local network 105. If the agent 125 is a node connecting local network 105 and local network 106, and therefore has direct access to both, then it can enable the DMAC to be used as a special multicast or broadcast address and transmit the modified initial message 300' to local network 106.

[0053] As can be seen, the corrected initial message 300' is the same as the initial message 300, except for three possible differences. First, the SMAC field 320 may include the proxy MAC address. Second, the port field may include a port value. Third, the DMAC field 310 can be changed to a unicast address for server 135 and can be further changed for any additional server. Having a port value in the port field allows proxy 125 to forgo storing the port value, as proxy 125 can also receive the port value at step 250 as described below. This allows proxy 125 to minimize memory usage or proxy state. Storing the port value or subsequently receiving the port value allows proxy 125 to reduce the number of potential clients to which messages are sent. For example, if two clients generate the same HID, but proxy 125 uses different ports for the clients, proxy 125 can still distinguish between the two clients.

[0054] Return to Figure 2 In step 240, server 135 receives the corrected initial message 300' and generates the client MAC address of client 110. In step 250, server 135 generates a response message and transmits the response message to proxy 125.

[0055] Figure 5 To explain in more detail Figure 2 The flowcharts for steps 240 and 250 are shown below. At step 510, server 135 receives the corrected initial message 300'. At step 520, server 135 extracts the HID from the HID field 350. Server 135 may also extract additional client information if it is available in the corrected initial message 300'.

[0056] At decision diamond 530, server 135 scans the server lookup table to determine if the HID has already been assigned a MAC address. Alternatively, at decision diamond 530, server 135 scans the server lookup table to determine if the HID has already been assigned a MAC address. If yes, then server 135 proceeds to step 540. If not, then server 135 proceeds to step 550.

[0057] At step 540, server 135 retrieves the MAC address corresponding to the HID from the server lookup table. The MAC address is locally unique. At step 550, server 135 selects an unused MAC address from the server lookup table. The MAC address is locally unique. At step 560, server 135 records the HID, MAC address, the association between the two, and the status of the MAC address in the server lookup table. The status of the MAC address indicates that the MAC address is temporarily in use. Server 135 removes this status based on any suitable trigger, such as a timer used for renewal.

[0058] At step 570, server 135 generates a response message. Server 135 may include a Layer 2 MAC address or a Layer 3 IP address in the response message, or server 135 may transmit both Layer 2 MAC addresses and Layer 3 IP addresses simultaneously. Finally, at step 580, server 135 transmits the response message to agent 125 based on the DA in the DMAC field 310. If agent 125 is on a different local network than server 135, such as... Figure 1 As shown, DA is a unicast address and the response message is a unicast message. If agent 125 is in switch 127 and can be considered to be in the same local network 106 as server 125, then DA can be a multicast address and the response message is a multicast message. The disclosed embodiments attempt to use more unicast messages than multicast and broadcast messages, because these two types of messages are more of a burden on local networks 105 and 106.

[0059] The response message can be one of at least three types. A first type of response message indicates that server 135 does not have available MAC resources. In this case, step 530 can proceed directly to step 570. A second type of response message indicates that client 110 is not eligible to have a MAC address. In this case, step 520 can proceed directly to step 570. A third type of response message indicates the client's MAC address. The third type of response message is displayed in... Figure 6 middle.

[0060] Figure 6 yes Figure 2 A schematic diagram of response message 600. Response message 600 is a unicast message and includes a DMAC field 610, an SMAC field 620, an EtherType field 630, an S-LAAP type field 640, a HID field 650, an optional port field 660, and an assigned MAC field 670. The fields in response message 600 are in any suitable order and include any suitable number of bits. The fields may conform to existing standards such as DHCP to extend such standards. Response message 600 may also include additional fields.

[0061] DMAC field 610 includes the same DA or multicast DA as the proxy MAC address in SMAC field 320 of the revised initial message 300'. If SMAC field 320 in the revised initial message 300' does not include a proxy MAC address, then DA is one of two values. For the first value, DA is a unicast DA. Proxy 125 thus identifies the DA because the DA is not a special multicast address. For the second value, DA is a special multicast address or a broadcast address. SMAC field 620 includes SA, which is the server MAC address belonging to server 135.

[0062] The EtherType field 630 is typically the same as the EtherType field 330 in the initial message 300. The S-LAAP type field 640 includes a value indicating the type of S-LAAP message. In this case, the value indicates that the response message 600 is a response message. The HID field 650 is the same as the HID field 350 in the initial message 300. The port field 660, if present, is the same as the port field 360 in the modified initial message 300'. The MAC allocation field 670 includes... Figure 5 In step 560, the server 135 generates the client MAC address for the client 110.

[0063] Return to Figure 2 At step 260, agent 125 receives response message 600 and transmits it to client 110. Agent 125 may modify response message 600. For example, if agent 125 receives response message 600 as a unicast message, agent 125 may modify response message 600 to produce modified response message 600'. Modified response message 600' modifies the DMAC field 610 to include a special multicast or broadcast address, since the client still does not know its MAC address; modifies the SMAC field 620 to include the MAC address of the port through which agent 125 forwards response message 600; and optionally removes the port field 660, since client 110 does not need to know its contents. Figure 7 To explain in more detail Figure 2 The flowchart for step 260 is shown below. At step 710, agent 125 receives response message 600. At decision diamond 720, agent 125 determines whether the DA from the DMAC field 610 is the agent's MAC address. If yes, agent 125 proceeds to step 730. If not, agent 125 proceeds to decision diamond 750.

[0064] At step 730, agent 125 scans the agent lookup table and retrieves the port value corresponding to the HID. Alternatively, agent 125 determines the port value from port field 660 if port field 660 is available, instead of scanning the agent lookup table. The port value indicates the port through which agent 125 receives the initial message 300. At step 740, agent 125 transmits the response message 600 to client 110 via said port.

[0065] At decision diamond 750, agent 125 determines whether the DA from DMAC field 610 is a unicast address. Agent 125 does this by analyzing the multicast bit in DMAC field 610. If the multicast bit is 0, then the DA is unicast. If the multicast bit is 1, then the DA is multicast. If the multicast bit is 0, then agent 125 proceeds to step 760. If not, then the DA is a special multicast address and agent 125 proceeds to step 770. At step 760, agent 125 transmits response message 600 based on the DA. Specifically, if the DA is a client MAC address, then agent 125 transmits response message 600 to client 110. At step 770, agent 125 transmits response message 600 as a multicast message based on the DA. Specifically, agent 125 transmits response message 600 to client 110 and also to other available nodes.

[0066] Return to Figure 2 At step 270, client 110 receives response message 600, generates an acknowledgment message, and transmits the acknowledgment message to proxy 125. Since the initial message 300 is a multicast or broadcast message, client 110 may receive multiple response messages 600 from multiple servers. Client 110 therefore selects one of the response messages 600 and selects the corresponding server to which it transmits the acknowledgment message. Client 110 selects the response message 600 based on any suitable criteria or one or more. For example, client 110 selects either the first response message 600 it receives or the response message 600 associated with the server that previously provided the best service. In this case, the server selected by client 110 is server 135.

[0067] The acknowledgment message is either a multicast or broadcast message, therefore client 110 will also transmit the acknowledgment message to other available nodes. Because the acknowledgment message is multicast or broadcast, all servers including server 135 will know, either directly or through a proxy, the MAC address of the client belonging to the in-use client 110. Furthermore, all servers except server 135 will know that client 110 rejected its response message 600. The acknowledgment message is displayed in... Figure 8 middle.

[0068] Figure 8 yes Figure 2 A schematic diagram of acknowledgment message 800 is shown. Acknowledgment message 800 is a multicast or broadcast message and includes a DMAC field 810, an SMAC field 820, an EtherType field 830, an S-LAAP type field 840, and a HID field 850. The fields in acknowledgment message 800 are in any suitable order and include any suitable number of digits. The fields may conform to existing standards such as DHCP to extend such standards. Response message 800 may also include additional fields.

[0069] The DMAC field 810 is typically the same as the DMAC field 310 in the initial message 300. The SMAC field 820 is the same as the assigned MAC field 670 in the response message 600. The EtherType field 830 is typically the same as the EtherType field 330 in the initial message 300 and the EtherType field 630 in the response message 600. The S-LAAP type field 840 includes a value indicating the type of S-LAAP message. In this case, the value indicates that the acknowledgment message 800 is an acknowledgment message. The HID field 850 is the same as the HID field 350 in the initial message 300 and the HID field 650 in the response message 600. Alternatively, the acknowledgment message 800 includes another field from the response message 300 that is substantially unique within the local network.

[0070] Return to Figure 2 In step 280, agent 125 receives confirmation message 800, processes confirmation message 800, and transmits confirmation message 800 to server 135. Figure 9 To explain in more detail Figure 2 The flowchart for step 280 is as follows. At step 910, agent 125 receives acknowledgment message 800. At step 920, agent 125 removes the HID from the agent lookup table if the HID is still available in the agent lookup table. Finally, at step 930, agent 125 forwards acknowledgment message 800 based on the DA from the DMAC field 810. Specifically, agent 125 may forward acknowledgment message 800 to multiple nodes, including server 135, because the DA is a special multicast address or broadcast address.

[0071] Return to Figure 2 Finally, at step 290, server 135 receives and processes confirmation message 800. Figure 10 To explain in more detail Figure 2The flowchart for step 290 is as follows. At step 1010, server 135 receives confirmation message 800. At step 1020, server 135 extracts the HID from the HID field 850. At step 1030, server 135 records the valid association between the HID and the client MAC address in the server lookup table. Server 135 removes the valid state based on any suitable trigger, such as a timer for renewal. Finally, at step 1040, server 135 starts a timer for the association. If any other server provides the MAC address to client 110, then upon receiving confirmation from client 110 that it has selected the MAC address provided by server 135, the other server marks the MAC address provided by the server as available.

[0072] Figure 11 Figure 1100 illustrates a message sequence diagram of address allocation negotiation using an intermediate node according to an embodiment of the present invention. The local network 106 performs the negotiation. Specifically, Figure 1100 shows the negotiation between client 110, intermediate node 130, and server 135. Of course, the same principle applies between any suitable components.

[0073] Figure 1100 includes steps 1110 to 1190, which are respectively similar to Figure 2 Steps 210 to 290 differ from at least two others. First, intermediate node 130 replaces agent 125. Second, at step 1150, server 135 transmits response message 600 as a multicast message. Therefore, the DA in the DMAC field 610 is a special multicast address or broadcast address. Similarly, intermediate node 130 transmits response message 600 as a multicast message. The DAs of the two response messages 600 may be the same or different. Unlike the address allocation negotiation using an agent as shown in message sequence diagram 200, the intermediate node does not modify the message, which includes initial message 300, response message 600, and acknowledgment message 800.

[0074] Figure 12 This is a flowchart illustrating a method 1200 for generating an HID and transmitting an initial message according to an embodiment of the present invention. One of clients 110, 115, and 120 may implement method 1200 at any suitable time, for example, after desiring to communicate with another node such as client 150. The following text discusses... Figure 13 The described clients 110, 115, and 120 include processors implemented through any suitable combination of hardware, middleware, firmware, and software.

[0075] In step 1210, random number generation is performed. In step 1220, the HID is generated based on the generated random number. Steps 1210 and 1220 may correspond to... Figure 2Step 210. Specifically, at step 210, client 110 generates an HID. Client 110 does this using a random number generator to generate an HID of an appropriate size, such as a 48- or 64-bit HID. Some methods for generating such random numbers are provided in "Randomness Requirements for Security". Alternatively, the choice of bit length is guaranteed to be within an acceptable probability, i.e., the HID is locally unique based on the number of nodes in the local network that can simultaneously generate HIDs. In this case, the HID is substantially unique. The probability is any suitable probability, such as approximately 98% or approximately 99% over 100 years of use. The HID only needs to be unique or substantially unique within a given time period, such as a second or a portion of several seconds, during which there are unresolved S-LAAP requests for which responses are pending.

[0076] At step 1230, an initial message requesting a local address is generated using the HID. Finally, at step 1240, the initial message is transmitted. Steps 1230 and 1240 may correspond to... Figure 2 Step 220. Specifically, at step 220, client 110 generates an initial message, packet, or frame and transmits the initial message to proxy 125. The initial message is a multicast or broadcast message, so the local network also delivers the initial message to other available nodes. In one embodiment, the initial message is shown as... Figure 3 middle.

[0077] Figure 13 This is a schematic diagram of a network device 1300 according to an embodiment of the present invention. Device 1300 is suitable for implementing the disclosed embodiments described above. Device 1300 includes an input port 1310 and a receiver unit (Rx) 1320 for receiving data; a processor, logic unit, or central processing unit (CPU) 1330 for processing data; a transmitter unit (Tx) 1340 and an output port 1350 for transmitting data; and a memory 1360 for storing data. Device 1300 may further include an optical-to-electrical (OE) component and an electrical-to-optical (EO) component coupled to the input port 1310, the receiver unit 1320, the transmitter unit 1340, and the output port 1350 for input and output of optical or electrical signals.

[0078] Processor 1330 is implemented through any suitable combination of hardware, middleware, firmware, and software. Processor 1330 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and digital signal processors (DSPs). Processor 1330 communicates with ingress port 1310, receiver unit 1320, transmitter unit 1340, egress port 1350, and memory 1360. Processor 1330 includes an S-LAAP component 1370. S-LAAP component 1370 implements the disclosed embodiments described above. For example, S-LAAP component 1370 implements clients 110, 115, and 120; a proxy 125; an intermediate node 130; a server 135; and message sequence diagrams 200 and 1100 as described above. The inclusion of S-LAAP component 1370 thus provides a substantial improvement in the functionality of device 1300 and enables the device 1300 to transition to different states. Alternatively, S-LAAP component 1370 is implemented as instructions stored in memory 1360 and executed by processor 1330.

[0079] Memory 1360 includes one or more disks, tape drives, and solid-state drives, and can be used as an overflow data storage device to store such programs when a program is selected for execution and to store instructions and data read during program execution. Memory 1360 can be volatile or non-volatile, and can be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), or static random-access memory (SRAM).

[0080] Unless otherwise stated, the term "about" is used to mean a range including ±10% of the following number. While several embodiments have been provided in this invention, it should be understood that the disclosed systems and methods may also be embodied in many other specific forms without departing from the spirit or scope of the invention. Examples of the invention should be considered illustrative rather than restrictive, and the invention is not limited to the details given herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

[0081] Furthermore, the technologies, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, components, technologies, or methods without departing from the scope of the invention. Other items shown or discussed as coupled or directly coupled or communicating with each other may also be indirectly coupled or communicating via an interface, device, or intermediate component in an electrical, mechanical, or other manner. Examples of other changes, substitutions, and alterations will be apparent to those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims

1. A method for a server-based local address allocation protocol, applied to a network system, the network system including a client, a proxy device, and at least one server, wherein the client is located on a local network, and the server is a server outside the local network; The method is executed by the client, characterized in that, The method includes: Generate a host identifier (HID) based on a random number. The HID is used to generate an initial message requesting a local address. The initial message includes a Target Media Access Control (DMAC) field, a Source Media Access Control (SMAC) field, a Server Local Address Allocation Protocol (S-LAAP) type field, and an HID field. Send the initial message; Each receives a response message sent by the server in response to the initial message; Select a first response message from the response messages; and Extract the Media Access Control (MAC) address from the first response message.

2. The method according to claim 1, characterized in that, The client is an S-LAAP client, which is one of the following devices: hardware network components, VMs, or IoT devices.

3. The method according to claim 1, characterized in that, The HID comprises multiple bits, and the number of such bits is guaranteed to be within the probability that the HID is unique within the local network.

4. The method according to claim 3, characterized in that, The HID being unique within the local network specifically includes the HID being unique within the local network for a given period of time.

5. The method according to claim 3 or 4, characterized in that, The HID is at least 48 bits.

6. The method according to any one of claims 1-4, characterized in that, The DMAC field includes a multicast address, the SMAC field includes a first value indicating that the local address is unknown, the S-LAAP type field includes a second value indicating that the initial message is of the initial message type, and the HID field includes the HID.

7. The method according to claim 6, characterized in that, Further includes: A confirmation message is generated in response to the first response message, wherein the confirmation message includes a Target Media Access Control (DMAC) field, a Source Media Access Control (SMAC) field, a Server Local Address Allocation Protocol (S-LAAP) type field, and an HID field; wherein the DMAC field includes a multicast address, the SMAC field includes the MAC address, the S-LAAP type field includes a value indicating that the confirmation message is a confirmation message type, and the HID field includes the HID.

8. The method according to any one of claims 1-4 and 7, characterized in that, The step of selecting a first response message from the response messages includes: The response message is selected based on one or more criteria, including: selecting the response message associated with the server that previously provided the best service.

9. A method for a server-based local address allocation protocol, applied to a network system, the network system including a client, a proxy device, and at least one server, wherein the client is located on a local network, and the server is a server outside the local network; The method is executed by the agent device, characterized in that, The method includes: An initial message is received from the client through a first port, wherein the initial message includes a Target Media Access Control (DMAC) field, a Source Media Access Control (SMAC) field, a Server Local Address Allocation Protocol (S-LAAP) type field, and an HID field, wherein the HID field includes the client's Host Identifier (HID). The initial message is corrected to generate a corrected initial message; The corrected initial message is sent to the server.

10. The method according to claim 9, characterized in that, The method further includes: Record the association between the HID and the port value of the first port; or Add the port value of the first port to the initial message.

11. The method according to claim 10, characterized in that, The method further includes: Receive the response message returned by the server; Determine the destination MAC address carried in the response message; If the destination MAC address carried in the response message is the MAC address of the proxy device, the port that sent the response message is determined to be the first port; The response message is sent to the client through the first port.

12. The method according to claim 11, characterized in that, The response message carries the port value of the first port; The method further includes: The port used to send the response message is determined to be the first port based on the port value of the first port carried in the response message.

13. The method according to claim 11, characterized in that, The response message carries the HID; The method further includes: The port that sent the response message is determined to be the first port based on the correlation between the HID carried in the response message and the port value of the first port.

14. The method according to claim 10, characterized in that, The method further includes: Receive the response message returned by the server; If the destination MAC address carried in the response message is a unicast address, the response message is sent based on the unicast address; or... If the destination MAC address carried in the response message is a special multicast address, the response message is sent using a multicast message method based on the special multicast address.

15. The method according to any one of claims 11-14, characterized in that, The method further includes: Receive the confirmation message sent by the client; If the HID is still available in the agent lookup table of the agent device, remove the HID from the agent lookup table.

16. A method for a server-based local address allocation protocol, applied to a network system, the network system including a client, a proxy device, and at least one server, wherein the client is located on a local network, and the server is a server outside the local network; The method is performed by one or more of the at least one server, characterized in that, The method includes: The client receives a corrected initial message sent by the proxy device. The initial message is from the client and includes a Target Media Access Control (DMAC) field, a Source Media Access Control (SMAC) field, a Server Local Address Allocation Protocol (S-LAAP) type field, and an HID field. The HID field carries the client's Host Identifier (HID). Obtain the HID from the revised initial message; The type of response message is determined based on the HID, and the type of response message includes: the client is not qualified to have a MAC address, the server does not have a usable MAC address, or a MAC address is assigned to the client; Send the response message.

17. The method according to claim 16, characterized in that, The method further includes: If the HID has been assigned a MAC address, then obtain the MAC address corresponding to the HID; or if the HID has not been assigned a MAC address, then obtain the unused MAC address. Assign the obtained MAC address to the client; The response message carries the MAC address assigned to the client.

18. The method according to claim 16 or 17, characterized in that, The method further includes: Record the association between the HID and the MAC address.

19. The method according to claim 16 or 17, characterized in that, The method further includes: Receive a confirmation message from the client from the proxy device, the confirmation message carrying the HID; Extract the HID from the confirmation message; Recording the association between the HID and the MAC address is valid.

20. The method according to claim 19, characterized in that, The method further includes: The effective state of removing the association between the HID and the MAC address based on a triggering event, the triggering event including a renewable timer.

21. A computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1-8, 9-15, or 16-20.

Images