Internet DRAFT - draft-snalluri-dhcp-status-monitoring
draft-snalluri-dhcp-status-monitoring
Network Working Group Srinivasa Rao Nalluri
Internet Draft Lakshmisha G
Intended status: Standards Track Amit Gupta
Expires: April 30, 2016 Ericsson
October 10, 2015
Status monitoring extensions to DHCP
draft-snalluri-dhcp-status-monitoring-00
Abstract
This draft introduces bidirectional framework and protocol to
monitor reachability and status of IP clients in subnet. This draft
is based on Dynamic Host Configuration Protocol and MAY be
considered as an extension of RFC 2131.
Status of This Memo
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2016.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please review
these documents carefully, as they describe your rights and
restrictions with respect to this document.
Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Table of Contents
1. Terminology
2. Introduction and motivations
3. Reference Network topology
4. Protocol summary
4.1. Capability negotiation
4.1.2. DHCP client's monitor capability option
4.1.3. DHCP server's monitor capability option
4.2. DHCP client's monitor function
4.3. DHCP server's or relay agent's monitor function
5. Administrative objects and default values
5.1. Client monitor request interval
5.2. Client monitor threshold
5.3. Server monitor threshold
6. Message definitions
6.1. DHCP client monitor request
6.2. DHCP client monitor response
7. Constructing and sending DHCP client monitor request
8. Constructing and sending DHCP client monitor response
9. Processing DHCP client monitor request
10. Processing DHCP client monitor response
11. IPv6 considerations
12. Backward compatibility
13. Acknowledgements
14. References
14.1. Informative References
14.2. Normative References
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
- DHCP client's monitor function
A function that is active on DHCP client device to monitor
reachability of DHCP server or DHCP relay agent that is active
on intermediate Layer3 node. In specific scenarios considered
in this draft, intermediate node MAY be Access device or Edge
router.
- DHCP server's monitor function -
A function that is active on DHCP server to monitor reachability
of all its DHCP clients. DHCP server's monitor function is
active only for clients which are in DHCP server's broadcast
domain.
- DHCP relay agent's monitor function
A function that is active on DHCP relay agent to monitor DHCP
clients which are in different broadcast domain from DHCP
server. In specific scenarios discussed in this draft, DHCP
relay agent's monitor function MAY be active on Layer3 access
device or on edge router.
2. Introduction and motivations
In IP networks, DHCP is the protocol used to assign IP address
dynamically. Though DHCP assigns network layer address on need basis,
it cannot dynamically track the client's status and reachability.
Once the address is assigned, it is assumed that client is reachable
and active. Resources assigned to client are not released until
service lease time expires or until client initiate DHCP RELEASE
message. The resources might include IP address, FIB entries,
bandwidth, and allocated internal buffers. In congested networks it
is possible that DHCP release MAY not reach DHCP server. DHCP
client MAY leave network without sending DHCP RELEASE message.
In service provider IP networks it is important to optimize resource
utilization based on actual status of DHCP client. To achieve
resource overbooking and reduce capital investments it is required
to release network resources dynamically even when IP clients leaves
network silently.
Accounting is another area where dynamic client status monitoring is
required. There are services where time based accounting is required
rather than volume based. In such scenarios it is important to have
client status tracking close to accuracy.
The problem becomes severe as industry is moving towards Internet of
Things and new generation of mobile technologies which are boosting
growth of number of IP devices and their dynamic nature.
There are several ways by which service providers are trying to
solve this issue.
- Periodic Layer2 address resolution to determine client status.
- Periodic Layer3 reachability test.
- Subscriber resources clean up based on subscriber idle time.
None of these approaches are clean and standardized. These
approaches are unidirectional and do not provide ability to client
to initiate negotiation upon detecting an IP connectivity failure.
Client's renegotiation capability is particularly important in
broadband scenarios to increase service availability.
3. Reference Network topology
IP client Monitoring function SHOULD be combined with
- DHCP server function if DHCP client exists in same broadcast
domain as DHCP server.
- DHCP relay agent If client and server are in different
broadcast domain.
Following network topologies are specific to broadband access
scenarios but SHOULD be used as reference network topologies.
+----------+
|IP client |-------------|
+----------+ |
| +------+ +------+
+----------+ | | | | |
|IP client |-------------| | | | |
+----------+ | | | | BRAS/|
: | | L2 | | EDGE |
: | |ACCESS| |ROUTER|
: |------------| NODE |------------| + |
: | | | | DHCP |
: | | | |SERVER|
+----------+ | | | | |
|IP client |-------------| +------+ +------+
+----------+ |
|
+----------+ |
|IP client |-------------|
+----------+
<-------------------- Monitor function ------------------->
Figure 1. Broadband network design with DHCP server and client in same
broadcast domain.
+----------+
|IP client |-------------|
+----------+ |
| +------+ +------+
+----------+ | | | | |
|IP client |-------------| | L3 | | |
+----------+ | |ACCESS| | BRAS/|
: | | NODE | | EDGE |
: | | + | |ROUTER|
: |------------| DHCP |------------| + |
: | | RELAY| | DHCP |
: | | AGENT| |SERVER|
+----------+ | | | | |
|IP client |-------------| +------+ +------+
+----------+ |
|
+----------+ |
|IP client |-------------|
+----------+
<--------- Monitor function --------->
Figure 2. Broadband network design with DHCP server and client in
different broadcast domain
+----------+
|IP client |--------|
+----------+ |
| +------+ +------+
+----------+ | | | | |
|IP client |--------| | | | | +------+
+----------+ | | | | BRAS/| | |
: | | L2 | | EDGE | | DHCP |
: | |ACCESS| |ROUTER| |SERVER|
: |---------| NODE |---------| + |----| |
: | | | | DHCP | | |
: | | | |RELAY | +------+
+----------+ | | | |AGENT |
|IP client |--------| +------+ +------+
+----------+ |
|
+----------+ |
|IP client |--------|
+----------+
<-------------- Monitor function -------------->
Figure 3. Broadband network design with L2 access device, where DHCP
server and client are in different broadcast domain
4.Protocol summary
Note that defaults for timer values are described later in this
document. Timer and counter names appear in square brackets.
4.1. Capability negotiation
DHCP server's monitor function and DHCP client's monitor function
detects monitoring capability of peer through DHCP options
exchanged during DHCP discovery phase. DHCP client sends DISCOVER
and REQUEST messages with new option to indicate client is capable
of responding to monitor request received from server.
DHCP server or relay agent responds to monitor capable clients with
DHCP OFFER that carries an option indicating server's capability to
broadcast periodic monitoring messages in broadcast domain.
4.1.2. DHCP client's monitor capability option
A zero length option with code 214 in DHCP DISCOVER and REQUEST
messages indicates DHCP client's capability to responds to periodic
monitoring messages received from DHCP Server or DHCP relay agent.
Code Len
+-----+-----+
| 214 | 0 |
+-----+-----+
4.1.3. DHCP server's monitor capability option
A new option with code 215 and length 2 in DHCP OFFER and DHCP ACK
messages indicates router's monitoring function's capability to
generate periodic broadcast monitor messages in subnet.
code Len Interval
+-----+-----+-----+-----+
| 215 | 2 | |
+-----+-----+-----+-----+
Interval is the time taken in seconds by DHCP server's or relay
agent's monitor function between generating two periodic broadcast
client monitor messages
4.2. DHCP client's monitor function
Once DHCP discovery phase completed between DHCP client and server,
DHCP client expects periodic [DHCP client monitor request] messages
from server at intervals advertised by server in Option 215. DHCP
client responds with [DHCP client monitor response] message only if
DHCP server from which the [DHCP client monitor request] is received
is same as the DHCP server from which its own IP address is
assigned.
DHCP client uses DHCP client monitor request to monitor reachability
of DHCP server or DHCP relay agent. DHCP client considers DHCP server
or DHCP relay agent is unreachable if [DHCP client monitor request]
message is not received for given number of intervals. If DHCP
server or relay agent is considered as unreachable, DHCP client MAY
clean existing configuration and initiate new DHCP DISCOVER to
obtain configuration from any other reachable DHCP server.
4.3. DHCP server's or relay agent's monitor function
Existence of DHCP Server's or DHCP relay agent's function in network
depends on topology. Once DHCP DISCOVER phase is completed and at
least one DHCP client is assigned with IP address, DHCP server's or
relay agent's monitor function starts broadcasting [DHCP client
monitor request] in subnet. DHCP server's or relay agent's monitor
function expects response for each [DHCP client monitor request]
message from each of its clients.
DHCP server's or relay agent's monitor function considers client is
not reachable if DHCP client monitor response is not received for a
sequence of DHCP client monitor request.
If DHCP server's monitor function detects an unreachable client, it
releases all resources allocated for unreachable client.
If DHCP relay agent's monitor function detects an un-reachable
client, it releases all local resources and informs DHCP server to
release resources by sending DHCP RELEASE message.
5. Administrative objects and default values
5.1. Client monitor request interval
The [client monitor request interval] is the interval between [DHCP
client monitor request] messages sent by DHCP server's or relay
agent's monitor function. This is administratively configurable on
DHCP server's or relay agent's monitor function.
Default: 120 seconds.
Value of [client monitor request interval] is advertised by DHCP
server or relay agent during session discovery phase through DHCP
server's monitor capability option. DHCP client's monitor function
uses [client monitor request interval] value advertised by server or
relay agent to monitor server or relay agent reachability.
By varying the value of [client monitor request interval], an
administrator may tune the number of DHCP messages on the subnet.
Larger values cause [client monitor request] to be sent less often.
An administrator may also tune the burstiness of [DHCP client
monitor response] messages on the subnet; larger values make the
[DHCP client monitor response] messages less bursty, as DHCP
client's monitor functions can send responses spread out over a
larger interval.
5.2. Client monitor threshold
[Client monitor threshold] is the number of [client monitor
requests] sent by DHCP server's or relay agent's monitor function
without receiving response from a DHCP client, before deciding DHCP
client as unreachable
Administratively configurable on DHCP server's or relay agent's
monitor function, Default: 3
By varying the Client monitor threshold, an administrator may
adjust monitor functions to network conditions. Larger value allows
DHCP client and server to avoid resource release due to bad network
conditions.
5.3. Server monitor threshold
[Server monitor threshold] is the number of [Client monitor request
intervals] that client monitor function wait without receiving [DHCP
client monitor request]. Once [Server monitor threshold] is reached
client monitor function decides server or relay agent as
unreachable.
Administratively configurable on DHCP client's monitor function,
Default: 3
To avoid frequent session re-negotiations from DHCP client, Server
monitor threshold of client's monitor function MUST be in line with
Server monitor threshold of server's or relay agent's monitor
function.
6. Message definitions
6.1. DHCP client monitor request
A client monitor request is a bootp broadcast message sent from a
DHCP server/relay agent to a DHCP client, to detect the client's
reachability
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | Reserved(3) |
+---------------+---------------+---------------+---------------+
| Server or Relay agent Ip Addres (4) |
+-------------------------------+-------------------------------+
FIELD OCTETS DESCRIPTION
----- ------ -----------
Op 1 Message op code / message type.
3 = MONITORREQUEST
Reserved 3 Reserved and MUST be filled with
zero.
Server or
Relay agent 4 DHCP server/relay agent's IP address
IP address
6.2. DHCP client monitor response
[DHCP client monitor response] message is a BOOTP unicast message
sent from a DHCP client to dhcp server/relay agent in response to
the client monitor request to indicate its reachability to server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1)| hlen (1) | Reserved (1) |
+---------------+---------------+---------------+---------------+
| Ciaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
FIELD OCTETS DESCRIPTION
----- ------ -----------
Op 1 Message op code / message type.
4 = MONITORRESPONSE
htype 1 Hardware address type, see ARP section
in "Assigned Numbers" RFC; e.g.,
'1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for
10mb ethernet).
Reserved 1 Reserved and MUST be filled with zero.
Ciaddr 4 Client Ip Address
chaddr 16 Client hardware address
The 'htype', 'hlen', and 'chaddr' fields supply the link-layer
hardware type, hardware address length, and hardware address of the
client as defined in the ARP protocol [2] and the Assigned Numbers
document [3].
7. Constructing and sending DHCP client monitor request
[DHCP client monitor request] is always sent by DHCP server's or
relay agent's monitor function at [Client monitor request interval]
on 'DHCP client' udp port(68). DHCP client monitor request is a
broadcast message that will be reached all layer2 devices in
broadcast domain.
Server or relay agent broadcasts DHCP client monitor request to IP
header destination address 0xffffffff and must have the source
address field in the IP header set to
- DHCP server IP address if message is generated by DHCP server.
- DHCP relay agent IP address if message is generated by DHCP
relay agent.
Server's or relay agent's monitor function MUST set
- 'op' as MONITORREQUEST(3)
- 'reserved' as zero
- 'Server or relay agent IP address' as local IP address of
server or relay agent.
8. Constructing and sending DHCP client monitor response
[DHCP client monitor response] is always sent by DHCP client's
monitor function as response to [DHCP client monitor request] on
'DHCP server' udp port(67). [DHCP client monitor response] is
unicast message that will be reached to DHCP server or relay agent
from which DHCP client received IP address
DHCP client sends [DHCP client monitor response] to IP header
destination address that is same as DHCP server IP address received
in 'server identifier' option during DHCP discovery phase. Source IP
address field in the IP header MUST be set to client's IP address
DHCP client SHOULD respond to [DHCP client monitor request] messages
only if received 'Server or Relay agent Ip Address' is same as
Server IP address mentioned in server identifier option that was
received during DHCP discovery phase. DHCP client should silently
ignore all other [DHCP client monitor request] messages
Client's monitor function MUST set
- 'op' as MONITORRESPONSE(4)
- 'reserved' as zero
- 'htype' as defined in assigned numbers RFC
- 'hlen' as defined in assigned numbers RFC
- 'ciaddr' as IP address of client's monitor function.
- 'chaddr' as client's hardware address.
To reduce the burstiness of[DHCP client monitor response] messages
DHCP client SHOULD delay response to [DHCP client monitor request].
Delay time SHOULD be set to a random value selected from the range
0 and half of [Client monitor request interval]
9. Processing DHCP client monitor request
Reception of [DHCP client monitor request] indicate that DHCP server
or relay agent is still active. In deployment scenario this indicate
the active status of default gateway.
Source IP address of IP header in received [DHCP client monitor
request] SHOULD NOT be trusted as a sole key in identifying DHCP
server or relay agent. 'Server or relay agent Ip address' received
in [DHCP client monitor request] SHOULD be considered in validating
[DHCP client monitor request]. DHCP client responds with [DHCP
client monitor response] If the 'Server or relay agent Ip address'
in received [DHCP client monitor request] is same as server IP
address received in server identifier option during DHCP DISCOVERY
phase.
DHCP client waits for [Server monitor threshold] iterations without
receiving [DHCP client monitor request] before deciding
unreachability of DHCP server or relay agent.
10. Processing DHCP client monitor response
Reception of [DHCP client monitor response] indicate that DHCP
server or relay agent is still reachable from DHCP client and also
indicates active status of DHCP client.
'ciaddr' field in received [DHCP client monitor response] SHOULD
NOT be trusted as a sole key in identifying a client; the contents
of the 'ciaddr', 'chaddr', 'htype', and 'hlen' fields SHOULD all be
considered together in validating [DHCP client monitor response]
DHCP server or relay agent waits for [Client monitor threshold]
iterations without receiving [DHCP client monitor response] before
deciding unreachability of DHCP client.
11. IPv6 considerations
12. Backward compatibility
- DHCP client compatibility with legacy DHCP server or relay agent:
DHCP client should fallback to legacy behavior If DHCP client is
monitor capable but not the server or relay agent. DHCP server
that is not capable of monitoring ignores option 214 in received
DHCPDISCOVER messages and responds with DHCPOFFER without adding
option 215.
If monitor capable DHCP client receives DHCPOFFER without option
215, client MAY accept the DHCPOFFER and send DHCPREQUEST
without option 214 or, client can ignore DHCPOFFER and wait for
DHCPOFFER with option 215 from another monitor capable DHCP
server.
[DHCP client monitor response] received by legacy DHCP server
SHOULD be silently ignored.
- DHCP server or relay agent compatibility with legacy DHCP client:
Monitor capable DHCP server responds with option 215 included
DHCPOFFER only for those DHCPDISCOVER messages which include
option 214. For all other DHCPDISCOVER messages, server responds
with DHCPOFFER without option 215.
DHCP server's monitor function should monitor only those clients
for which monitor capability is exchanged during DHCP discovery
phase.
Legacy DHCP clients ignores all [DHCP client monitor request]
messages from known or unknown servers.
13. Acknowledgements
This document is based on concepts and broadband service provider
network deployment modes described in several forums, including IETF
and Broadband forum.
14. References
14.1. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Normative References
[2] Plummer, D., "An Ethernet Address Resolution Protocol",
STD 37, RFC 826, MIT, November 1982.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1340, USC/Information Sciences Institute, July, 1992.
This RFC is periodically reissued with a new number.
Please be sure to consult the latest version.
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997
[6] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993
Author's Addresses
Srinivasa Rao Nalluri
Ericsson
Level-5
Ferns Icon, Outer Ring Road,
Doddanakundi
Marathahalli, Bangalore
India-560037
Email: srinivasa.rao.nalluri@ericsson.com
Lakshmisha G
Ericsson
Level-5
Ferns Icon, Outer Ring Road,
Doddanakundi
Marathahalli, Bangalore
India-560037
Email: lakshmisha.g@ericsson.com
Amit Gupta
Ericsson
Level-5
Ferns Icon, Outer Ring Road,
Doddanakundi
Marathahalli, Bangalore
India-560037
Email: amit.x.gupta@ericsson.com
