LLDP TLV Client Disconnect for VLAN Change Reliability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Non-supplicant clients, both wired and wireless, experience network access issues due to the lack of a method to re-initiate DHCP requests after a VLAN change, especially when indirectly connected to a Network Access Server (NAS) through intermediate L2 bridges or switches.
Innovation Solution
A method utilizing a new LLDP TLV (Type 127) for 'Client Disconnect' messages is implemented, allowing the NAS to request port bounce or disassociation from intermediate L2 bridges and Access Points, ensuring clients can re-initiate DHCP requests in the new VLAN by toggling their Network Interface Controller (NIC) upon VLAN changes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the NAS performs port bounce on directly connected non-supplicant clients after VLAN change, then the client can re-initiate DHCP request in the new VLAN, but this solution does not work for indirectly connected clients through intermediate L2 bridges/switches
Solution Approach 1:
The patent introduces an intermediary mechanism (LLDP TLV message) that enables communication between the NAS and intermediate L2 bridges/switches. This intermediary carries client MAC address information and facilitates coordinated action among all devices in the path, allowing the solution to work for both directly and indirectly connected clients.
Solution Approach 2:
The patent segments the problem by identifying each device in the communication path (NAS, intermediate L2 bridges/switches, AP) as a separate entity that needs to be individually controlled. By sending targeted LLDP TLV messages to each intermediate device, the system can precisely control port bounce/disassociation actions at the correct location without affecting other clients or devices.
2Ease of operation
If the client continues to use the old VLAN assignment after VLAN change, then no additional control messages are needed, but the client experiences network access issues
Solution Approach 1:
The patent performs preliminary actions by having the NAS proactively send LLDP TLV messages to intermediate devices immediately upon detecting a VLAN change. This preemptive approach ensures that the client's network path is updated before the client attempts to use the old VLAN, preventing network access issues before they occur.
Solution Approach 2:
The patent implements a feedback mechanism where intermediate L2 bridges/switches and APs send acknowledgments back to the NAS after receiving LLDP TLV messages. This feedback loop ensures that the VLAN change propagation is confirmed and allows the NAS to track whether the reconfiguration was successful.
3Ease of manufacture
If a new LLDP TLV message type is introduced for Client Disconnect requests, then precise control over port bounce and disassociation can be achieved, but the protocol complexity increases
Solution Approach 1:
The patent makes the LLDP protocol universal by extending it with a new TLV type that can serve multiple functions (Client Disconnect requests, port bounce commands, disassociation notifications) across different device types (NAS, L2 bridges, switches, APs). This single extension provides multi-functional capability without requiring separate protocols for each device type.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method and system are devised of moving at a NAS (1) a client (12, 13) with a MAC address, from a first VLAN to a second VLAN. A leaf is comprised of at least one intermediate L2 bridge/switch (5, 9) being connected to the NAS (1). The client (12, 13) is being connected to one (9) of the at least one intermediate L2 bridge/switches (5, 9) in the leaf. The method and system involve sending at the NAS (1) a first message downlink (31, 36) to intermediate L2 bridge/switches (5) in the leaf directly connected to the NAS. They further involve at each intermediate L2 bridge/switch (5, 9) in the leaf: upon receiving the first message from uplink from the NAS (1) or an intermediate L2 bridge/switch (5, 9) in the leaf, determining whether the client (12, 13) is directly or indirectly connected to one of its ports; and if it is directly connected, bouncing the port to which the client (12, 13) is connected, and sending a second message uplink to the NAS (1) or an intermediate L2 bridge/switch (5, 9) in the leaf; if it is indirectly connected, sending the first message downlink on the port to which the client (12, 13) is indirectly connected to an intermediate L2 bridge/switches (5, 9) in the leaf; and if it is not connected, sending a third message uplink to the NAS (1) or an intermediate L2 bridge/switch (5, 9) in the leaf. They further involve at each intermediate L2 bridge/switch (5, 9) in the leaf: upon receiving the second or third message from downlink from an intermediate L2 bridge/switch (5, 9) in the leaf, forwarding it uplink to the NAS (1) or an intermediate L2 bridge/switch (5, 9) in the leaf. Finally the client (12, 13) may initiate a DHCP request in the second VLAN.