FIELD OF INVENTION
[0001] The present subject matter relates to rebuilding Dynamic Host Configuration
Protocol (DHCP) session information and, particularly, but not exclusively, to rebuilding DHCP
session information at access nodes.
BACKGROUND 5
[0002] Client devices connected to communication networks have been increasing in
numbers. The communication networks generally include a collection of distributed client
devices, e.g., set top boxes, Voice over IP (VoIP) phones, Customer-Premises Equipments
(CPEs), personal computers, printers, routers, servers, etc., each having distinct and unique
addresses, such as an Internet Protocol (IP) address. 10
[0003] Commonly, such distinct and unique addresses, such as the IP addresses, are
assigned using different protocols within communication networks, such as a Dynamic Host
Configuration Protocol (DHCP). In communication networks that use the DHCP, client devices
request IP addresses from a DHCP server. The DHCP server allocates an IP address for use by
the requesting client device and sends the device a response message informing the client device 15
about the IP address to use. The IP address allocated by the DHCP server is generally "leased" to
the client device for a fixed period of time. Subsequently, the client device is responsible for
periodically renewing the lease of the IP address.
[0004] Typically, in the communication network implementing DHCP, connectivity to
the client devices is provided by access nodes. The access nodes include, Digital Subscriber Line 20
Access Multiplexer (DSLAM), Metro Ethernet Switch, Optical Line Terminal (OLT), Base-
Station, and the like. The access nodes act as an intermediary between the DHCP server and the
client devices.
SUMMARY
[0005] This summary is provided to introduce concepts related to systems and methods 25
for rebuilding Dynamic Host Configuration Protocol (DHCP) session information in an access
node. This summary is not intended to identify essential features of the claimed subject matter
nor is it intended for use in determining or limiting the scope of the claimed subject matter.

3

[0006] In an implementation, a method for rebuilding DHCP session information at an
access node is described. The method comprises receiving a Link Layer Discovery Protocol
(LLDP) message from a client device. The LLDP message comprises a DHCP client information
associated with the client device. The method further comprises authenticating a DHCP session
information associated with the client device, where the DHCP session information comprises 5
the DHCP client information. The method further comprises updating a mapping of DHCP
session information with the DHCP session information based on the authenticating.
[0007] In an implementation, a method for transmitting DHCP session information from
a client device is described. The method comprises generating a LLDP message, where the
LLDP message comprises a DHCP client information, where the DHCP client information is 10
associated with the client device, and a DHCP server information, where the DHCP server
information is associated with a DHCP server providing connectivity to the client device. The
method further comprises transmitting the LLDP message comprising the DHCP session
information, where the session information comprises the DHCP client information and the
DHCP server information. 15
[0008] In another implementation, a DHCP Information Rebuilding (DIR) system for
rebuilding DHCP session information at an access node is described. The DIR system comprises
a processor and a session information module coupled to the processor. The session information
module is configured to receive a LLDP message from a client device, wherein the LLDP
message comprises a DHCP client information associated with the client device. The DIR system 20
further comprises a revival module coupled to the processor. The revival module is adapted to
authenticate the DHCP session information associated with the client device. The DIR system
further comprises an information processing module coupled to the processor. The information
processing module is configured to update a mapping of DHCP session information with the
DHCP session information based on the authenticating. 25
[0009] In an implementation, a non-transitory computer readable medium having a set of
computer readable instructions that, when executed, cause a computing system to perform a
process is described. The process comprises receiving a Link Layer Discovery Protocol (LLDP)
message from a client device. The LLDP message comprises a DHCP client information
associated with the client device. The process further comprises authenticating a DHCP session 30

4

information comprising the DHCP client information, associated with the client device. The
process further comprises updating a mapping of DHCP session information with the DHCP
session information based on the authenticating.
[0010] In another implementation, a non-transitory computer readable medium having a
set of computer readable instructions that, when executed, cause a computing system to perform 5
a process is described. The process comprises generating a LLDP message, where the LLDP
message comprises a DHCP client information, where the DHCP client information is associated
with the client device, and a DHCP server information, where the DHCP server information is
associated with a DHCP server providing connectivity to the client device. The process further
comprises transmitting the LLDP message comprising the DHCP session information, where the 10
session information comprises the DHCP client information and the DHCP server information.
BRIEF DESCRIPTION OF THE FIGURES
[0011] The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the
reference number first appears. The same numbers are used throughout the figures to reference 15
like features and components. Some embodiments of system and/or methods in accordance with
embodiments of the present subject matter are now described, by way of example, and with
reference to the accompanying figures, in which:
[0012] Fig. 1 schematically illustrates a communication network environment
implementing a DHCP Information Rebuilding (DIR) system, in accordance with an 20
embodiment of the present subject matter;
[0013] Fig. 2 illustrates a call flow diagram to rebuild DHCP session information, in
accordance with an embodiment of the present subject matter; and
[0014] Fig. 3 illustrates a method to rebuild DHCP session information, in accordance
with an embodiment of the present subject matter. 25
[0015] It should be appreciated by those skilled in the art that any block diagrams herein
represent conceptual views of illustrative systems embodying the principles of the present
subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state
transition diagrams, pseudo code, and the like represent various processes which may be

5

substantially represented in computer readable medium and so executed by a computer or
processor, whether or not such computer or processor is explicitly shown.
DESCRIPTION OF EMBODIMENTS
[0016] Systems and methods for rebuilding Dynamic Host Configuration Protocol
(DHCP) session information in an access node are described. The systems and the methods can 5
be implemented in a variety of communication networks comprising client devices, where the IP
addresses to the client devices are assigned using the Dynamic Host Configuration Protocol
(DHCP). The client devices may include, but not limited to, set top boxes, Voice over IP (VoIP)
phones, Customer-Premises Equipments (CPEs), personal computers, printers, routers, servers,
and the like. Although the description herein is with reference to IP networks, the systems and 10
methods may be implemented in other communication networks, albeit with a few variations, as
will be understood by a person skilled in the art.
[0017] The DHCP is a communication network protocol that is used to configure devices
which are connected to a communication network so that they can communicate through the
internet protocol. The client devices request for DHCP session information, such as an IP 15
address, a default route and Domain Name System (DNS) server addresses, from a DHCP server
using the DHCP. Once the client device implements configuration from the DHCP session
information, the client device is able to communicate with other client devices through the
internet protocol. The DHCP server usually maintains a database of available IP addresses and
configuration information. When the DHCP server receives a request from the client device, the 20
DHCP server allocates an IP address or a prefix that is appropriate for the client device
depending on the communication network to which the client device is connected, and sends the
DHCP session information to the client device. An interval for which the DHCP session
information, such as the IP address is granted to the client devices by the DHCP servers is
referred herein as a DHCP session of the client device. Before the DHCP session of the client 25
device expires, the client device has to renew the DHCP session information from the DHCP
server. In case the session is not renewed, the client device has to stop the usage of the obtained
configuration from the DHCP session information.
[0018] Typically, a communication network implementing DHCP sessions includes
access nodes. The access nodes may include, but not limited to, Digital Subscriber Line Access 30

6

Multiplexer (DSLAM), Metro Ethernet Switch, Optical Line Terminal (OLT), Base-Station and
the like. The access node provides connectivity to the client devices and acts as an intermediary
between the DHCP server and the client device. In many situations, the access node itself is the
DHCP server providing connectivity to the client devices. The access node, implemented as an
intermediary, monitors DHCP transactions between the client device and the DHCP server, to 5
build a mapping of DHCP session information. The mapping of DHCP session information may
include an IP address to Media Access Control address (MAC address) mapping for the client
device connected to the access node. The IP address to MAC address mapping is usually used by
the access node to ensure secure forwarding of data to and from client device and prevention of
address spoofing, and other attacks on the client device. 10
[0019] Generally, the access node builds a mapping of the DHCP session information of
the client device, such as DHCP client information associated with the client device and DHCP
server information associated with the DHCP server for providing connectivity to the client
device.
[0020] While the access node is providing connectivity to the client devices, the access 15
node might undergo reboot or a power-on reset due to various reasons, such as fault in
equipment and fault in software. Typically, the DHCP session information is stored in a volatile
memory of the access node which is erased when the access node restarts. Hence when the
access node reboots, the DHCP session information is generally lost. When the DHCP session
information is unavailable at the access node, the connection between the client device and the 20
DHCP server is lost resulting in communication failure. Therefore, after the reboot the access
node has to wait till the DHCP transaction between the client device and the DHCP server are re-
established to rebuild the mapping of DHCP session information and ensure forwarding of data.
Generally the client devices are unaware of any reboot at the access node and initiate the DHCP
transactions with the DHCP server at the end of DHCP session time interval. Hence, in situations 25
where the access node has undergone a reboot while there is still considerable time left for
DHCP session expiry, neither the client device, nor the access node will be capable of resolving
the problem suo-motu by initiating renewal or re-establishment of the DHCP transactions
between the client device and the DHCP server.

7

[0021] Although, as a solution, the access nodes may be implemented with non-volatile
memory to save the DHCP session information which is retained even after a reboot, the
implementation of the non-volatile memory may result in higher costs of the access nodes and
their increased sizes. In today’s competitive market, it is highly undesirable to either increase
cost of an electronic hardware component, such as the access node, or increase its physical size. 5
[0022] According to an implementation of the present subject matter, systems, and
methods to rebuild the DHCP session information at access node are described. On one hand, the
described methods and implemented systems may allow efficient rebuilding of DHCP session
information at the access node; on the other hand, the methods may reduce downtime in
situations of access node reboot. 10
[0023] In operation, according to an implementation, the client device may send the
DHCP session information to the access node at predetermined time intervals. Link Layer
Discovery Protocol (LLDP) is a communication protocol in Internet Protocol Suite, used by
client devices for advertising their identity, capabilities, and neighbors on the communication
network. In said implementation, the client devices may be configured to send the DHCP session 15
information as a part of the LLDP message. In said implementation, the DHCP session
information may be included in the LLDP message. The DHCP session information may be
included as optional Type-Length-Values (TLVs) in the LLDP message. The LLDP message
may include a first TLV comprising DHCP client information associated with the client device.
The client information may be the IP address associated with the client device. The LLDP 20
message may further comprise a second TLV comprising DHCP server information associated
with the DHCP server providing connectivity to the client device. The DHCP server information
may include, amongst other information, details of the IP address associated with the DHCP
server. Further in said implementation the access node upon reboot may receive the LLDP
message. The access node may extract the DHCP client information from the first TLV and the 25
DHCP server information from the second TLV, of the LLDP message.
[0024] In an implementation of the present subject matter, the access node upon reboot
may receive DHCP session information from the client device through the LLDP message,
which is transmitted at predetermined time intervals. The access node may extract the DHCP
session information from the LLDP message, which may be in TLVs. The access node may 30

8

check for availability of the DHCP session information extracted from the LLDP message in the
mapping of DHCP session information at the access node. The access node may not trust the
DHCP session information in the LLDP message provided by the client device to prevent
unauthenticated clients from connecting to the access node. A malicious user may add a client
device to the mapping of DHCP session information at the access node by sending a LLDP 5
message with fake DHCP session information in the TLVs. Hence, to prevent such malicious
attacks, the access node may trust the DHCP server, and may authenticate the DHCP session
information received from the client device from the DHCP server. In case, if the DHCP session
information is not available in the mapping of DHCP session information at the access node, the
access node may initiate authentication of the DHCP session information by sending a dummy 10
revival request to the client device. In order to verify the authenticity, the access node may
confirm the DHCP client information from the DHCP server based on the transactions between
the client device and the DHCP server during a DHCP session renewal.
[0025] The access node may send a dummy revival request to the client device to initiate
force-revival of the DHCP session with the DHCP server. The dummy revival request may be 15
generated based on the DHCP server information received through the LLDP message, shared by
the client device. The dummy revival request generated based on the DHCP server information
allows for the dummy revival request to be seen as originating from the DHCP sever. The
dummy revival request may be based on IP factors which may depend on version of the IP suite,
the communication network supports. The dummy revival request may be a FORCERENEW 20
request or a RECONFIGURE request, determined based on the IP factors.
[0026] It would be appreciated by those skilled in the art that upon receiving a DHCP
revival request, such as FORCERENEW or RECONFIGURE request, the client devices initiate
renewal of the DHCP session with the DHCP server. In said implementation, upon receiving the
dummy revival request, the client device may initiate revival of the DHCP session with the 25
DHCP server.
[0027] In response to the revival request from the client device, the DHCP server may
send a revival response to the client device. In an implementation, depending on the validity of
the DHCP session, the DHCP server may either renew the DHCP session, or initiate a new
DHCP session with the client device, or reject the client’s request. In situations where the DHCP 30

9

server either renews the DHCP session of the client device, or initiates a new DHCP session, the
access node may monitor the communications between the DHCP server and the client device to
update the DHCP session information. The DHCP session information may be updated to the
mapping of DHCP session information at the access node.
[0028] Typically, the DHCP session interval ranges in time periods of hours, whereas 5
time interval for transmitting LLDP messages ranges in time periods of seconds or minutes.
According to the implementation of the present subject matter, the access node upon reboot may
initiate an update of the DHCP session information associated with the client device, based on
the LLDP message received from the client device. The initiation by the access node can
substantially reduce the time taken by the access point to rebuild the DHCP session information 10
into its mapping of DHCP session information and restoring service to the client device. In
another implementation, the time interval for sending the LLDP messages from the client device
may be modified as per requisite of service availability and availability of hardware resources
associated with the communication network.
[0029] It should be noted that the description merely illustrates the principles of the 15
present subject matter. It will thus be appreciated that those skilled in the art will be able to
devise various arrangements that, although not explicitly described herein, embody the principles
of the present subject matter and are included within its spirit and scope. Furthermore, all
examples recited herein are principally intended expressly to be for pedagogical purposes to aid
the reader in understanding the principles of the present subject matter and the concepts 20
contributed by the inventor(s) to furthering the art, and are to be construed as being without
limitation to such specifically recited examples and conditions. Moreover, all statements herein
reciting principles, aspects, and embodiments of the subject matter, as well as specific examples
thereof, are intended to encompass equivalents thereof.
[0030] The manner in which the systems and methods, to enable rebuilding of DHCP 25
session information, shall be explained in details with respect to the Fig. 1-3. While aspects of
described systems and methods for enabling rebuilding of DHCP session information can be
implemented in any number of different computing systems, transmission environments, and/or
configurations, the embodiments are described in the context of the following system(s).

10

[0031] It will also be appreciated by those skilled in the art that the words during, while,
and when as used herein are not exact terms that mean an action takes place instantly upon an
initiating action but that there may be some small but reasonable delay, such as a propagation
delay, between the initial action and the reaction that is initiated by the initial action.
Additionally, the word “connected” and “coupled” is used throughout for clarity of the 5
description and can include either a direct connection or an indirect connection.
[0032] Fig. 1 illustrates a communication network environment 100 implementing a
DHCP Information Rebuilding (DIR) system 102. The DIR system 102 is connected to client
devices 104-1, 104-2,..., 104-N. For the purpose of explanation and clarity, the client devices
104-1, 104-2,..., 104-N, are collectively referred to as the client devices 104 and individually as a 10
client device 104, hereinafter. Further, the DIR system 102 is connected via a communication
network 106 to a DHCP server 108. The DHCP server 108 may provide the client devices 104 a
connectivity to the communication network 106, through establishment of a DHCP session.
[0033] In accordance with an implementation described herein, a client device 104 may
request DHCP server 108, to establish a DHCP session. In response, the DHCP server 108 may 15
facilitate establishment of a DHCP session for the client device 104 by providing DHCP session
information. The DHCP session information may comprise DHCP client information, such as IP
address allocated to the client device 104. The DHCP session information may further comprise
a time interval for which the IP address is allocated to the client device 104. The DHCP session
information may further comprise DHCP server information, such as IP address of the DHCP 20
server 108. The client device 104 may use the received DHCP session information for
communicating with devices connected to the communication network 106.
[0034] In an implementation of the present subject matter, the DIR system 102 may
provide connection between the DHCP server 108 and the client devices 104. In said
implementation the DIR system 102 may monitor the transactions between the DHCP server 108 25
and the client device 104. The DIR system 102 may further build a cache based on DHCP
session information provided to the client device 104. The cache may include a mapping of IP
address allocated to the client device 104 to a Media Access Control address (MAC address) of
the client device 104. The cache may be used by the DIR system 102 for providing the client
device 104 the connectivity to the communication network 106. The cache may further be used 30
by the DIR system 102 for secure forwarding and receiving of data with the client device 104.

11

[0035] The DIR system 102 may be implemented in Digital Subscriber Line Access
Multiplexer (DSLAM), Metro Ethernet Switch, Optical Line Terminal (OLT), Base-Station, a
wireless access node, etc. Further, the DHCP server 108 may be implemented on one or more
discrete servers, mainframe computers, broadband service routers, super-computers, and the like,
located across different geographic locations and coupled to each other. Further, the client 5
devices 104 may comprise one or more set top boxes, Voice over IP (VoIP) phones, Customer-
Premises Equipments (CPEs), personal computers, printers, routers, servers, and the like.
[0036] The communication network 106 may provide connection between the DHCP
server 108 and the client devices 104. The communication network 106 may be a combination of
wired and wireless networks. The communication network 106 may be implemented by the 10
DHCP servers through satellite communication, terrestrial communication, or may be
implemented through the use of routers and access nodes connected to various Digital Subscriber
Line Access Multiplexers (DSLAMs) of wired networks. The communication network 106 can
be implemented as one of the different types of networks, such as intranet, telecom network,
Local Area Network (LAN), Wide Area Network (WAN), Virtual Private Network (VPN), 15
internetwork, Global Area Network (GAN), the Internet, and such. The communication network
106 may either be a dedicated network or a shared network, which represents an association of
the different types of networks that use a variety of protocols, for example, Hypertext Transfer
Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless
Application Protocol (WAP), etc., to communicate with each other. 20
[0037] Fig. 1 further schematically illustrates components of the DIR system 102,
according to an embodiment of the present subject matter. In said implementation, the
components of the DIR system 102 implemented in a wireless access node have been described
for the sake of explanation. It would be understood by those skilled in the art that the DIR system
102, or equivalents thereof, may be implemented in a different manner, without digressing from 25
the scope and spirit of the present subject matter.
[0038] The DIR system 102 includes processor 110. The processor 110 can be a single
processing unit or a number of units, all of which could include multiple computing units. The
processor(s) may be implemented as one or more microprocessors, microcomputers,
microcontrollers, digital signal processors, central processing units, state machines, logic 30
circuitries, and/or any devices that manipulate signals based on operational instructions. Among

12

other capabilities, the processor(s) are to fetch and execute computer-readable instructions stored
in the memory. The memory may include any computer-readable medium known in the art
including, for example, volatile memory, such as SRAMs and DRAMs and/or non-volatile
memory such as EPROMs and flash memories.
[0039] The functions of the various elements shown in the figures, including any 5
functional blocks labeled as “processor(s)”, may be provided through the use of dedicated
hardware as well as hardware capable of executing software in association with appropriate
software. When provided by a processor, the functions may be provided by a single dedicated
processor, by a single shared processor, or by a plurality of individual processors, some of which
may be shared. Moreover, explicit use of the term “processor” should not be construed to refer 10
exclusively to hardware capable of executing software, and may implicitly include, without
limitation, Digital Signal Processor (DSP) hardware, network processor, application specific
integrated circuit (ASIC), Field Programmable Gate Array (FPGA), Read Only Memory (ROM)
for storing software, random access memory (RAM), and non volatile storage. Other hardware,
conventional and/or custom, may also be included. 15
[0040] Also, the DIR system 102 includes interface(s) 112. The interfaces 112 may
include a variety of software and hardware interfaces that allow the DIR system 102 to interact
with the communication network 106, or with each other. Further, the interfaces 112 may enable
the DIR system 102 to communicate with other communication and computing devices,
communication network 106 and client devices 104. The interfaces 112 may facilitate multiple 20
communications within a wide variety of networks and protocol types, including wire networks,
for example, LAN, cable, etc., and wireless networks, for example, WLAN, cellular, satellite-
based network, etc.
[0041] The DIR system 102 may also include memory 114. The memory 114 may be
coupled to the processor 110. The memory 114 may include any computer-readable medium 25
known in the art including, for example, volatile memory, such as static random access memory
(SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as
read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical
disks, and magnetic tapes.

13

[0042] The DIR system 102 includes modules 116 and data 118. The modules 116 may
be coupled to the processor(s) 110. The modules 116 include routines, programs, objects,
components, data structures, and the like, which perform particular tasks or implement particular
abstract data types. The modules 116 further include modules that supplement applications on
the DIR system 102, for example, modules of an operating system. The data 118 serves, amongst 5
other things, as a repository for storing data that may be fetched, processed, received, or
generated by one or more of the modules 116. Although the data 118 is shown internal to the
DIR system 102, it may be understood that the data 118 can reside in an external repository (not
shown in figure).
[0043] In an implementation of the present subject matter, the modules 116 of the DIR 10
system 102 include a session information module 120, a revival module 122, an information
processing module 124, and other module(s) 126. In said implementation, the data 118 of the
DIR system 102 includes session data 128, revive data 130, and other data 132. The other
module(s) 126 may include programs or coded instructions that supplement applications and
functions, for example, routing encapsulation support modules, programs in the operating system 15
of the DIR system 102, etc., and the other data 132 comprise data corresponding to one or more
other module(s) 126.
[0044] The client device 104 may have established a DHCP session, by obtaining DHCP
session information from the DHCP server 108, according an implementation of the present
subject matter. The access node implementing the DIR system 102 may have monitored the 20
transactions between the client device 104 and the DHCP server 108. Based on the monitoring
the access node may have built a cache which maps between a MAC address of the client device
104 and the DHCP client information allocated to the client device 104 from the DHCP server
108. The DHCP client information may include an IP address leased to the client device 104 for
a predetermined time. The predetermined time for the leased DHCP client information may vary 25
depending upon the implementation. The cache may be used to facilitate transfer of data with the
client device 104.
[0045] In said implementation, the access node implementing DIR system 102 may
undergo a reboot due to various reasons, such as fault in equipment and fault in software, and

14

lose the cache information. By implementation of the present subject matter the cache can be
rebuilt by the DIR system 102.
[0046] According to the present subject matter, the client device 104 may transmit DHCP
session information to the DIR system 102 at predetermined time intervals through LLDP
transmissions. The DHCP session information may comprise the DHCP client information and 5
the DHCP server information. The DHCP client information may be transmitted in a TLV of a
LLDP message. For the purpose of explanation and clarity, the TLV of LLDP message
comprising DHCP client information allocated to the client device is referred to as a first TLV
hereinafter. It would be understood by a person skilled in the art that the usage of term 'first' in
the first TLV is used for the purpose of explanation and not linked to position of the TLV in the 10
LLDP message. In an example, the LLDP message comprising the first TLV may be transmitted
to the DIR system 102 at predetermined time interval of 30 seconds.
[0047] In an implementation upon reboot of the access node implementing the DIR
system 102, the DIR system 102 may receive the LLDP message comprising the first TLV, from
the client device 104. The session information module 120 of the DIR system 102 may extract 15
the DHCP client information from the first TLV of the LLDP message. The extracted DHCP
client information may include the IP address allocated to the client device 104. The extracted
DHCP client information may be stored in the session data 128 of the DIR system 102.
[0048] In said implementation the DIR system 102 may be built with the DHCP server
information, such as DHCP server IP address. The DHCP server information may be stored in 20
the revive data 130 of the DIR system 102. In response to the DHCP client information received
by the DIR system 102 through the LLDP message from the client device 104, the revival
module 122 may authenticate the DHCP session information associated with the client device
104. In order to authenticate the revival module 122 may generate and send a dummy revival
request to the client device 104. The dummy revival request may be generated based on the 25
DHCP server information, such that the dummy revival request seems to the client device 104 to
have been originating from the DHCP server 108. The dummy revival request generated may
further be based on the DHCP server's MAC address. The revival module 122 may utilize
address resolution protocol (ARP) to find the MAC address corresponding to the DHCP server
information. The dummy revival request may be sent to the client device 104 to initiate force- 30

15

revival of the DHCP session of the client device 104. It would be understood by a person skilled
in the art that the revival module 122 may send the dummy revival request to the client device
104 at pre-determined time intervals, until the DIR system 102 identifies that the client device
104 has initiated the DHCP session force-revival. In an implementation, the dummy revival
request may be a DHCP FORCERENEW request. In another implementation the dummy revival 5
request may be a RECONFIGURE request.
[0049] The LLDP message from client device 104 may further comprise another TLV
comprising DHCP server information in an implementation of the present subject matter. For the
purpose of explanation and clarity, the TLV of LLDP message comprising DHCP server
information is referred to as a second TLV hereinafter. Similarly, it would be understood that the 10
term 'second' in the second TLV is used for the purpose of explanation and not linked to position
of the TLV in the LLDP message. The session information module 120 may extract the DHCP
server information from the second TLV of the LLDP message along with the DHCP client
information from the first TLV. The extracted DHCP server information may include the IP
address, such as IPv4 address and IPv6 address, corresponding to the DHCP server 108. The 15
extracted DHCP server information may be stored in the session data 128. As discussed, in
response to the LLDP message received by the DIR system 102, the revival module 122 of the
DIR system 102 may authenticate the DHCP session information associated with the client
device 104. In order to authenticate the revival module 122 may generate and send a dummy
revival request to the client device 104. In an embodiment of the present subject matter, the 20
revival module 122 may generate and send the dummy revival request to the client device 104 in
response to the LLDP message received, upon reboot of the access node implementing the DIR
system 102. Whereas in another embodiment of the present subject matter, there may be a pre-
determined time, after which the revival module 122 may generate and send the dummy revival
request to the client device 104 in response to the LLDP message received. The dummy revival 25
request may be generated based on the DHCP server information extracted from the second
TLV, such that dummy revival request seems to the client device 104 to have been originating
from the DHCP server 108. The dummy revival request may be sent to the client device 104 to
initiate force-revival of the DHCP session of the client device 104.
[0050] The client device 104, upon reboot of the access node, may receive the dummy 30
revival request from the DIR system 102. The client device 104 may initiate force-revival of the

16

DHCP session as per the dummy revival request, as if the dummy revival request originated from
the DHCP server 108. The client device 104 may send a revival request to the DHCP server 108,
requesting for revival of the DHCP session. In an implementation the revival request may be a
request for renewal of the DHCP session. In another implementation the revival request may be a
request for reconfiguring of the DHCP session. It would be understood by the person skilled in 5
the art that the client device 104 may send the revival request to the DHCP server 108 at pre-
determined time intervals, until the client device 104 receives a revival response from the DHCP
server 108.
[0051] The DHCP server 108 may receive the revival request from the client device 104,
according to an implementation of the present subject matter. The DHCP server 108 may provide 10
a revival response to the client device 104 in response to the revival request received. The revival
module 122 may monitor the transactions between the DHCP server 108 and the client device
104. To authenticate the DHCP session information associated with the client device 104 the
revival module 122 may monitor the revival response from the DHCP server 108 and verify the
authenticity of the DHCP session information. Based on the authentication the information 15
processing module 124 may rebuild the mapping of the DHCP session information with the
DHCP session information of the client device 104.
[0052] In an implementation of the present subject matter, the revival response provided
by the DHCP server 108 may be an acknowledgement response, where the DHCP server revives
the DHCP session information of the client device. The revival module 122 may monitor the 20
revival response and determine that the DHCP server 108 acknowledges the DHCP session
information of the client device 104. The revival module 122 may validate the DHCP session
information associated with the client device 104. In said implementation, the information
processing module 124 may rebuild the mapping of DHCP session information at the DIR
system 102 with the DHCP session information received through LLDP message from the client 25
device 104, based on the acknowledgement response detected by the revival module 122. As
mentioned earlier the DHCP session information may be stored in the session data 128. The
information processing module 124 may utilize the DHCP session information to rebuild the
mapping of DHCP session information at the DIR system 102. In an implementation the
information processing module 124 may further include the DHCP server information to the 30
mapping of DHCP session information of the DIR system 102.

17

[0053] In a scenario, the revival response provided by the DHCP server 108 may be an
acknowledgement response comprising the DHCP session information. The revival module 122
may monitor the revival response and determine that the DHCP server 108 acknowledges the
DHCP session information of the client device 104. In said implementation the revival module
122 may extract the DHCP session information from the revival response. The information 5
processing module 124 may rebuild the mapping of DHCP session information, with the DHCP
session information extracted by the revival module 122.
[0054] In another scenario, the revival response provided by the DHCP server 108 may
be a negative acknowledgement response. The revival module 122 may monitor the revival
response and determine that the DHCP server 108 rejects the DHCP session information of the 10
client device 104. In said implementation, the information processing module 124 may discard
the DHCP session information extracted by the information processing module 124 from the
LLDP message received. Further in said implementation, when the client device may receive the
negative acknowledgement response from the DHCP server, the client device may initiate
process for establishing a new DHCP session. In said implementation, the client device 15
establishes a new DHCP session by obtaining new DHCP session information from the DHCP
server 108. The revival module 122 may extract the DHCP session information from the
transaction of DHCP server 108 and the client device 104. Further, the information processing
module 124 rebuilds the mapping of DHCP session information, with the DHCP session
information of the client device 104. 20
[0055] In an example of the present subject matter, the client device 104-2 might have
established a DHCP session by receiving DHCP session information from the DHCP server 108.
The DIR system 102 may be implemented in a Wireless Access Point (WAP), which facilitates
transactions between the client device 104-2 and the DHCP server 108. The DHCP server's IP
address and MAC address may be 192.168.1.1 and 00:10:10:FF:44:33, respectively. The DHCP 25
server 108 may have allocated an IP address 192.168.1.50 to the client device 104-2 having a
MAC address 00:1F:D0:44:18:5D for a time period of 'T' time units. The DIR system 102 of
WAP may monitor the transactions between the client device 104-2 and the DHCP server 108
and may build a mapping of DHCP session information with the DHCP session information
associated with the client device 104-2. The mapping of DHCP session information may be built 30
by mapping the MAC address 00:1F:D0:44:18:5D of the client device 104-2 to the allocated IP

18

address 192.168.1.50 of the client device 104-2. In the described scenario, if after T/4 time units
from the start of the DHCP session, the WAP reboots due to hardware failure, the DIR system
102 of WAP would rebuild the mapping of DHCP session information upon reboot of the WAP.
[0056] In said example, the client device 104-2 may continuously transmit LLDP
messages after a time interval of 'x' time units. The LLDP messages may include two optional 5
TLVs, where one TLV, the ‘first TLV’ may include DHCP client information, such as the IP
address 192.168.1.50 allocated to the client device 104-2. The other TLV, ‘second TLV’ may
include DHCP server information, such as the IP address 192.168.1.1 of the DHCP server 108.
The session information module 120 of WAP may receive the LLDP message from client device
104-2 at time T/4 + x from the start of the DHCP session. The session information module 120 10
of WAP extracts the DHCP client information 192.168.1.50 and the DHCP server information
192.168.1.1, from the LLDP message. The revival module122 of WAP may utilize ARP for the
IP address 192.168.1.1 and find the corresponding MAC address 00:10:10:FF:44:33 of the
DHCP server 108.
[0057] Further in said example, the revival module 122 of WAP may generate a 15
FORCERENEW message with the source IP address 192.168.1.1 and MAC address
00:10:10:FF:44:33. The FORCERENEW message may be sent to the client device 104-2. The
client device 104-2 may initiate a DHCP session renewal procedure upon receiving the
FORCERENEW message. The revival module 122 of WAP monitors the response from the
DHCP server 108 and authenticates the DHCP session information associated with the client 20
device 104-2. The Information processing module 124 updates the mapping of DHCP session
information with the DHCP session information of the client device 104-2. In said example
implementation, the WAP may take a time period of x to rebuild the mapping of DHCP session
information with the DHCP session information. Since the time interval x for sending of LLDP
messages is less than the DHCP session time interval T, the WAP takes less time to rebuild the 25
mapping of DHCP session information. In a scenario where the LLDP packets do not include the
DHCP session information the WAP would have to wait till the half time, i.e., T/2 from start of
the DHCP session where the client device 104-2 would send the renewal request to DHCP server
108 and based on the response from the DHCP server 108 the WAP would have rebuilt the
mapping of DHCP session information and provided connectivity to the client device 104-2. 30
According to the present subject matter, since the time interval for transmitting LLDP messages

19

from the client device 104-2 is 'x' time units, the access node may receive LLDP messages from
the client device 104-2 on an average time interval of x/2 time units. The time interval 'x' may be
configured for a lesser duration, accordingly the time taken by the access node to rebuild the
DHCP session information after reboot can be reduced.
[0058] Fig. 2 illustrates a call-flow diagram 200 to rebuild DHCP session information, in 5
accordance with an implementation of the present subject matter. The various arrow indicators
used in the call-flow diagram depict the transfer of information between the client device 104,
the DIR system 102, and the DHCP server 108. In many cases, multiple network entities besides
those shown may lie between the entities, including transmitting devices, and switching devices,
although those have been omitted for clarity. Similarly, various acknowledgement and 10
confirmation network responses may also be omitted for clarity.
[0059] In an implementation, the call flow for rebuilding DHCP session information
procedure has been explained in reference to the client device 104, the DIR system 102, and the
DHCP server 108. In said implementation, the DIR system 102 may initiate rebuilding DHCP
session information procedure in response to receiving the LLDP message from the client device, 15
after reboot of the access node implementing the DIR system 102. At step 202, the client device
104 may send a LLDP message to the DIR system 102. As described before, the LLDP message
may include the first TLV, comprising DHCP client information corresponding to the client
device 104, where the DHCP client information may include the IP address allocated to the client
device 104 from the DHCP server 108. In an implementation, the LLDP message may further 20
include the second TLV comprising DHCP server information, where the DHCP server
information may include the IP address of the DHCP server 108. In another implementation the
DHCP server information may be built with the DIR system 102. The DIR system 102 may use
the DHCP server information and utilize ARP to determine the MAC address associated with the
DHCP server 108. 25
[0060] As described before, in an implementation of the present subject matter, the DIR
system 102 may generate a dummy revival request in order to authenticate the DHCP session
information associated with the client device. The dummy revival request may be generated
based on the DHCP server information. In an implementation the dummy revival request is
generated based on the IP address of the DHCP server 108 and the MAC address of the DHCP 30

20

server 108. In said implementation, the dummy revival request may be sent to the client device
104 at step 204. The dummy revival request may be generated based on the DHCP server
information, such that the dummy revival request seems to the client device 104 to have been
originating from the DHCP server 108.
[0061] At step 206, the client device 104 upon receiving of the dummy revival request 5
the client device initiates the DHCP session force-revival. The client device 104 may send a
revival request to the DHCP server 108 requesting for revival of the DHCP session. The DIR
system 102 may facilitate the transmission of the revival request to the DHCP server 108. During
this facilitation, the DIR system 102 may monitor the revival request from the client device 104.
[0062] In response to the revival request received from the client device 104, the DHCP 10
server 108 may send a revival response at step 208 to the client device 104. As described before,
the revival response may be an acknowledgement response, with or without the DHCP session
information, or a negative acknowledgement response resulting in formation of a new DHCP
session between the client device 104 and the DHCP server 108. The DIR system 102 may
monitor the revival response and based on the revival response it may verify the authenticity of 15
the DHCP session information. Based on the authentication, the DIR system 102 may rebuild the
DHCP session information. In situation where the revival response is negative acknowledgement
response, the client device 104 may establish a new DHCP session with the DHCP server 108.
During the establishment of the DHCP session the DIR system 102 may monitor the transactions
between the client device 104 and the DHCP server 108 and rebuild the DHCP session 20
information associated with the client device 104.
[0063] Fig. 3 illustrates method 300, for rebuilding DHCP session information in a
communication network by the DIR system 102, according to an embodiment of the present
subject matter. The order in which the methods are described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to 25
implement the method 300 or any alternative methods. Additionally, individual blocks may be
deleted from the methods without departing from the spirit and scope of the subject matter
described herein. Furthermore, the methods can be implemented in any suitable hardware,
software, firmware, or combination thereof.

21

[0064] The method may be described in the general context of computer executable
instructions. Generally, computer executable instructions can include routines, programs, objects,
components, data structures, procedures, modules, functions, etc., that perform particular
functions or implement particular abstract data types. The method may also be practiced in a
distributed computing environment where functions are performed by remote processing devices 5
that are linked through a communications network. In a distributed computing environment,
computer executable instructions may be located in both local and remote computer storage
media, including memory storage devices.
[0065] Referring to Fig. 3, the method 300 may be implemented by network entities,
such as Digital Subscriber Line Access Multiplexer (DSLAM), Metro Ethernet Switch, Optical 10
Line Terminal (OLT), Base-Station, a wireless access node. At block 302, the LLDP message
from a client device 104 may be received. The LLDP message may comprise a first TLV,
comprising DHCP client information associated with the client device 104, where the DHCP
client information may be the IP address allocated to the client device 104 from the DHCP server
108. In an implementation, the LLDP message may further include the second TLV comprising 15
DHCP server information, where the DHCP server information may be information associated
with the DHCP server 108 providing the client device connectivity to the communication
network 106. In an implementation the DHCP server information may be the IP address of the
DHCP server 108.
[0066] At block 304, the DHCP client information is extracted from the first TLV. 20
Further, in an implementation the DHCP server information is extracted from the second TLV.
In an implementation the DHCP server information may be built into the device implementing
the method 300.
[0067] At block 306, a dummy revival request is sent to the client device 104 in order to
authenticate the DHCP session information associated with the client device 104. The dummy 25
revival request may be generated based on the DHCP server information, such that the dummy
revival request seems to the client device 104 to have been originating from the DHCP server
108. The dummy revival request generated may further be based on the DHCP server's MAC
address. Upon receiving of the dummy revival request the client device 104 may initiate for
force-revival of the DHCP session, and may send request to the DHCP server 108 for revival of 30

22

the DHCP session. In an implementation the dummy revival request may be a DHCP
FORCERENEW request. In another implementation the dummy revival request may be a
RECONFIGURE request.
[0068] At block 308, the mapping of DHCP session information may be updated to
rebuild the DHCP session information based on response received in response to the dummy 5
revival request. The response received may be used to validate the authenticity of the DHCP
session information associated with the client device 104. Based on the authentication, the
mapping of DHCP session information may be updated with the DHCP session information
associated with the client device 104. The response received may originate from the DHCP
server 108, in response to a request for DHCP session revival from the client device. It would be 10
understood by the person skilled in the art that the response to the dummy revival request may
originate from the DHCP server after one or more transactions between the client device 104 and
the DHCP server, logically following the initiation for force-revival of the DHCP session by the
client device 104.
[0069] Although embodiments for methods and systems for rebuilding DHCP session 15
information have been described in a language specific to structural features and/or methods, it is
to be understood that the present subject matter is not necessarily limited to the specific features
or methods described. Rather, the specific features and methods are disclosed as embodiments
for rebuilding DHCP session information.
20

23

I/We claim:

1. A method for rebuilding Dynamic Host Configuration Protocol (DHCP) session
information at an access node, the method comprising:
receiving a Link Layer Discovery Protocol (LLDP) message from a client device 5
(104), wherein the LLDP message comprises a DHCP client information associated with
the client device (104);
authenticating a DHCP session information comprising the DHCP client
information, associated with the client device (104); and
updating a mapping of DHCP session information with the DHCP session 10
information based on the authenticating.
2. The method as claimed in claim 1, wherein the LLDP message comprises at least one
Type-Length-Value (TLV), and wherein the at least one TLV comprises a first TLV comprising
the DHCP client information.
3. The method as claimed in claim 2, wherein the at least one TLV further comprises a 15
second TLV comprising a DHCP server information associated with a DHCP server (108)
providing connectivity to the client device (104).
4. The method as claimed in claim 1, wherein the authenticating comprises:
providing a dummy revival request to the client device (104), wherein the dummy
revival request is to initiate force-revival of a DHCP session associated with the client 20
device (104); and
validating the DHCP session information based on a response received in
response to the dummy revival request.
5. The method as claimed in claim 4, wherein the dummy revival request is generated based
on the DHCP client information and a DHCP server information corresponding to a DHCP 25
server (108) providing connectivity to the client device (104).

24

6. The method as claimed in claim 4, wherein the dummy revival request is one of a DHCP
FORCERENEW request and a RECONFIGURE request.
7. The method as claimed in claim 4, wherein the response received in response to the
dummy revival request is from a DHCP server (108).
8. The method as claimed in claim 4, wherein the providing the dummy revival request to 5
the client device (104) comprises:
extracting the DHCP client information and a DHCP server information from the
LLDP message; and
generating a dummy revival request with the DHCP client information and the
DHCP server information. 10
9. A method for transmitting DHCP session information from a client device (104), the
method comprising:
generating a LLDP message, wherein the LLDP message comprises:
a DHCP client information, wherein the DHCP client information is
associated with the client device (104); and 15
a DHCP server information, wherein the DHCP server information is
associated with a DHCP server (108) providing connectivity to the client device
(104); and
transmitting the LLDP message comprising the DHCP session information,
wherein the DHCP session information comprises the DHCP client information and the 20
DHCP server information.
10. A DHCP Information Rebuilding (DIR) system (102) for rebuilding DHCP session
information at an access node, the DIR system (102) comprising:
a processor (110);

25

a session information module (120) coupled to the processor (110), to receive a
LLDP message from a client device (104), wherein the LLDP message comprises a
DHCP client information associated with the client device (104);
a revival module (122) coupled to the processor (110), to authenticate the DHCP
session information associated with the client device (104); and 5
an information processing module (124) coupled to the processor (110), to update
a mapping of DHCP session information with the DHCP session information based on
the authentication.
11. The DIR system (102) as claimed in claim 10, wherein the LLDP message comprises at
least one TLV, and wherein the at least one TLV comprises a first TLV comprising the DHCP 10
client information.
12. The DIR system (102) as claimed in claim 11, wherein the at least one TLV further
comprises a second TLV comprising a DHCP server information associated with a DHCP server
(108) providing connectivity to the client device (104).
13. The DIR system (102) as claimed in claim 10, wherein for authentication, the revival 15
module (122):
provides a dummy revival request to the client device (104), wherein the dummy
revival request is to initiate force-revival of a DHCP session associated with the client
device (104); and
validates the DHCP session information based on a response received in response 20
to the dummy revival request.
14. The DIR system (102) as claimed in claim 13, wherein the dummy revival request is
generated based on the DHCP client information and a DHCP server information, and wherein
the DHCP server information is corresponding to a DHCP server (108) providing connectivity to
the client device (104). 25

26

15. The DIR system (102) as claimed in claim 13, wherein the dummy revival request is one
of a DHCP FORCERENEW request and a RECONFIGURE request.
16. The DIR system (102) as claimed in claim 13, wherein the response received in response
to the dummy revival request is from a DHCP server (108).
17. The DIR system (102) as claimed in claim 13, wherein for providing the dummy revival 5
request to the client device (104), the revival module (122):
extracts the DHCP client information and a DHCP server information from the
LLDP message; and
generates a dummy revival request with the DHCP client information and the
DHCP server information. 10
18. A non-transitory computer readable medium having a set of computer readable
instructions that, when executed, cause a computing system to:
receive a LLDP message from a client device (104), wherein the LLDP message
comprises a DHCP client information associated with the client device (104);
authenticate a DHCP session information comprising the DHCP client 15
information, associated with the client device (104); and
update a mapping of DHCP session information with the DHCP session
information based on the authenticating.
19. A non-transitory computer readable medium having a set of computer readable
instructions that, when executed, cause a computing system to: 20
generate a LLDP message, wherein the LLDP message comprises:
a DHCP client information, wherein the DHCP client information is
associated with the client device (104); and

27

a DHCP server information, wherein the DHCP server information is
associated with a DHCP server (108) providing connectivity to the client device
(104); and
transmit the LLDP message comprising the DHCP session information, wherein
the session information comprises a DHCP client information and a DHCP server 5
information.