Internet DRAFT - draft-eck-dfp
draft-eck-dfp
Network Working Group C. Kersey
Internet-Draft Cisco Systems, Inc.
Expires: September 7, 2006 March 6, 2006
Dynamic Feedback Protocol
draft-eck-dfp-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo presents a protocol for allowing servers in a load sharing
pool to provide feedback status to the entity making decisions on how
to distribute the work load to the pool.
Kersey Expires September 7, 2006 [Page 1]
Internet-Draft Dynamic Feedback Protocol March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
2.1. Environment Independence . . . . . . . . . . . . . . . . . 5
2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Functional Structure . . . . . . . . . . . . . . . . . . . 6
4. Message Structure . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 7
5. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Security TLV . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. MD5 Security Authentication . . . . . . . . . . . . . 10
5.2. Load TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Weight Value . . . . . . . . . . . . . . . . . . . . . 12
5.3. Keep-alive TLV . . . . . . . . . . . . . . . . . . . . . . 13
5.4. BindID Table TLV . . . . . . . . . . . . . . . . . . . . . 14
6. Defined Messages . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Preference Information Message . . . . . . . . . . . . . . 16
6.2. Server State Message . . . . . . . . . . . . . . . . . . . 17
6.3. DFP Parmaters Message . . . . . . . . . . . . . . . . . . 17
6.4. BindID Request Message . . . . . . . . . . . . . . . . . . 17
6.5. BindID Report Message . . . . . . . . . . . . . . . . . . 18
6.6. BindID Change Notify Message . . . . . . . . . . . . . . . 18
7. System Flow . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Control Connection . . . . . . . . . . . . . . . . . . . . 19
7.2. DFP Parameter Messages . . . . . . . . . . . . . . . . . . 19
7.3. Status Reporting of Real Servers . . . . . . . . . . . . . 19
7.4. Server Status Updates to DFP Agent . . . . . . . . . . . . 19
7.5. DFP Manager Update Request . . . . . . . . . . . . . . . . 20
7.6. Real Server Updates to DFP Manager . . . . . . . . . . . . 20
8. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Kersey Expires September 7, 2006 [Page 2]
Internet-Draft Dynamic Feedback Protocol March 2006
1. Introduction
1.1. Problem Description
The Dynamic Feedback Protocol, DFP, is designed to be used in Server
Load-Balancing (SLB) environments. In the SLB environment, it is
critical to know the availability or health of the servers in your
server farm. The problem today is that there is no effective way for
the real server to relay their overall health back to the SLB device.
There are several ways to monitor the health of real servers. You
can actively monitor the flows that are being served by the SLB
device. You can also activate probes on the SLB device. In this
context, a probe is a program that acts as a client to the server
farm. It will query for data, and it will compare the received data
to that of the probes configuration for acceptable data values coming
back. While these methods are somewhat effective in understanding if
the real servers are available or not, they do not offer a view into
the true health of the real servers.
The DFP protocol will allow the real servers to adjust their overall
health or availability to the SLB device. This will play a role into
which real server is picked by the SLB device to service a particular
flow. The most available and most healthy real server will be chosen
to handle the 'next' flow. The real server will calculate its own
health or availability to report to the SLB device.
1.2. Terminology
This document uses the following terms:
Virtual server: a virtual instance of a set of real servers that
clients use to connect to a site. The virtual server is represented
by an IP address, port, and protocol.
Server farm: a set of servers that are pre-defined to do the work for
a virtual server.
Real server: the physical server in a datacenter that is running the
application to fullfill the requests of incoming clients.
Server Load Balancer, SLB: Device in the network that distributes
load to a server farm via a virtual server.
Server agent/DFP Agent: software running on the real server that
collects statistics about the real server. These statistics are then
reported to a SLB device or a third-party box for determining the
overall health or availability of the real server.
Kersey Expires September 7, 2006 [Page 3]
Internet-Draft Dynamic Feedback Protocol March 2006
DFP Manager: the network entity that the DFP agent (or Server agent)
will report the availability of a real server to in a particular
operating environment. This could be the SLB device directly, or it
could be a third party.
1.3. Overview
In this system, DFP Agents will communicate with DFP Managers to set
the real server's health / availability to do work in a server farm.
The DFP Manager can be the actual SLB device that is making the
decisions on where the next flow goes, or it can be a third party
box. The third party box in this case could be a network management
system or something similar. In this case, the third party box will
gather the data from all the real servers and then apply its own
algorithms to the data. It will then send the data for all real
servers on to the DFP Manager, which could be running on a SLB
device. The idea is that the third party box can normalize the data
to ensure unique factors about each real server can be taken into
account before reporting the real server's availability to the DFP
Manager.
There are predefined messages that must be passed between the DFP
Agent and DFP Manager. Some messages are required to pass in only
one direction. The details on the message definitions and direction
are included in Section 6 and Section 7.
Kersey Expires September 7, 2006 [Page 4]
Internet-Draft Dynamic Feedback Protocol March 2006
2. Design Considerations
2.1. Environment Independence
This protocol is designed to be used within any network
infrastructure. It is the responsibility of the DFP Agent to gather
the statistical data from the actual server and to translate that
into meaningful data to report to the DFP Manager. Having this
separation allows the DFP Agent to interpret the information
differently depending on its actual operating environment.
2.2. Extensibility
The type of information being reported will grow as more features are
added to server farms or applications. Because of this, the protocol
must provide both flexibility and extensibility. New information can
be added and reported using DFP without 'breaking' the participants
that do not understand this new information. This is achieved
through the use of Type, Length, Value (TLV) parameters.
As new features are created, more TLVs can be added to messages
without disturbing the current participants. This allows for a form
of backwards compatibility in a particular operating environment
without adding a lot of complexity.
2.3. Security
This protocol allows real servers to provide feedback on their
availability in addition to allowing them to take themselves in and
out of service for a particular server farm. This implies that a
security risk exists if the network is 'hacked', which could take a
virtual server out of service.
An optional Security TLV is included in the protocol to allow for
message verification. This allows different levels of security to
the latest and greatest method that is being used without an overhaul
or modification to the protocol.
Kersey Expires September 7, 2006 [Page 5]
Internet-Draft Dynamic Feedback Protocol March 2006
3. Architecture
3.1. Functional Structure
DFP is a protocol between DFP Agents running on the real servers in a
server farm and a DFP Manager. That DFP Manager could be running on
a SLB device or a third-party host. If the data is collected by a
third-party host, the assumption is for that host to normalize the
data for all the servers in a server farm. The third-party host
would then report all the information to the SLB device. The DFP
Agent is responsible for collecting server status by whatever means
available. It then reports that information to the DFP Manager.
In the case of a third party unit gathering the information, DFP will
be the protocol used between all units in the network. DFP will be
running between the DFP Agents and DFP mananger. DFP will also be
running between the DFP manager and the SLB device. In this context,
it is assumed that any information being reported to a third party
unit will report the same information to the SLB device. The only
difference is that the third party unit can 'normalize' the data for
all real servers in a server farm. It should be noted that load-
balancing decisions will not be affected until the information is
received and processed by the SLB device.
The communication between the DFP Agent and the SLB/third-party unit
is a long-lived, reliable connection (e.g., TCP). The DFP Manager is
responsible for initiating and maintaining the connection. Based
upon the messages being received by the SLB device, the SLB device is
responsible for updating its internal status of the real servers.
The implemenation of the DFP Agent is outside the scope of the DFP
protocol. The agent software can gather whatever information it
wants to for determining the health of the real server (e.g.,
available memory, processor speed, process type, etc). The only part
that is important to the DFP protocol is how the information is sent
from the DFP Agent to the DFP Manager.
At this time, there is no dynamic discovery method implemented as a
part of the DFP protocol. The units must be configured with real and
virtual server information. Additionally, the SLB device must be
configured with DFP Agent information so it can initiate the
connection for retreiving information. Any dynamic discovery
protocol could be added to the DFP Agent and Manager to allow for
less configuration; however, that is outside the scope of this
document.
Kersey Expires September 7, 2006 [Page 6]
Internet-Draft Dynamic Feedback Protocol March 2006
4. Message Structure
DFP messages will contain a Signal Header describing the DFP protocol
version and the defined message type. In order to make the protocol
extensible, defined messages will be broken up into Type, Length,
Value, (TLV) format. Each message will contain the type of message
followed by the length of that component. Lastly the actual value
will be included. This will allow for new message types to be added
in the future without disturbing the current protocol definition. If
a message type is not understood by the receiver, the entire message
should be discarded.
All messages are assumed to be in Network Byte Order throughout the
protocol.
4.1. Message Format
The message format will be:
+-----------------------+
| Signal Header |
+-----------------------+
| First TLV |
+-----------------------+
| Second TLV |
+-----------------------+
| ..... |
+-----------------------+
| Last TLV |
+-----------------------+
The DFP version number is intended to be used for compatibility in
the network. The overall length of the entire DFP message is also
included.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version = 0x01 |0|0|0|0|0|0|0|0| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Length is the entire length of the message, including the
signal header.
Kersey Expires September 7, 2006 [Page 7]
Internet-Draft Dynamic Feedback Protocol March 2006
The TLV header is the first part of each component in the DFP
message. It describes the type and the overall length of the TLV.
This allows the receiver of the message to interpret the contents
correctly. It also allows the receiver the ability to skip over any
TLVs that are not understood.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length is the length of the TLV data plus the TLV header.
Kersey Expires September 7, 2006 [Page 8]
Internet-Draft Dynamic Feedback Protocol March 2006
5. Defined TLVs
The following TLVs are defined. TLVs are used to relay necessary
data based on the message type. The DFP message types are listed in
Section 6.
+-------------------------------------+
| TLV Name | Type Value |
+-------------------------------------+
| Security | 0x0001 |
+-------------------------------------+
| Load | 0x0002 |
+-------------------------------------+
| Keep-Alive | 0x0101 |
+-------------------------------------+
| Reserved | 0x0200-0x02ff |
+-------------------------------------+
| BindID Table | 0x0301 |
+-------------------------------------+
The "Reserved" TLVs are intended for future expansion or for user-
defined values. A user can define and use TLVs of their choosing.
5.1. Security TLV
The security TLV is used to describe the security algorithm being
used. Additionally, it provides the data necessary for that security
algorithm.
This TLV is optional in the protocol; however, if a receiving unit is
configured for a security type, then all DFP messages must contain
that Security TLV or they will be ignored. If the Security TLV is
present and not configured on the receiving unit, it will be ignored
while the rest of the message is processed normally. If this TLV is
present in a DFP message, then it must be immediately after the
Signal Header.
The definition:
Kersey Expires September 7, 2006 [Page 9]
Internet-Draft Dynamic Feedback Protocol March 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Data |
.............
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Algorithm: desribes the type of security algorithm being
implemented.
Security Data: contains the necessary data to implement the security
algorithm.
The defined Security values are:
+----------------------------+
| Security Type | Value |
+----------------------------+
| MD5_Security | 0x00000001 |
+----------------------------+
5.1.1. MD5 Security Authentication
The MD5 Security Authentication contains the following data:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Authentication Data (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Authentication Data (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Authentication Data (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MD5 Key ID, 4-bytes: used to determine which key (i.e., password) was
used in the MD5 calculation. This allows the changing of the keys on
the various boxes (i.e., DFP Agents, SLB devices, etc) without
messages being rejected.
Kersey Expires September 7, 2006 [Page 10]
Internet-Draft Dynamic Feedback Protocol March 2006
MD5 Authentication Data, 16-bytes: contains a 128-bit hash of the
message. This hash is based on the sum of the shared key plus the
entire message beginning with the Signal Header plus the shared key
again. This follows RFC1828 [1] MD5 to include the key in producing
the 128-bit message digest.
The MD5 hash is calculated per RFC1828 [1] over the entire DFP
portion of the message beginning with the signal header. The
Authentication Data and Key ID fields
MD5 keys will consist of up to 64 ASCII characters If the key is less
than 64 characters, it will be padded as per RFC1828 [1]. If
multiple keys are used, each key will have a "Key ID" assigned to it
upon configuration. This "Key ID" is provided with the message to
allow the receiving unit to be informed as to which key should be
used to verify this message. The "Key ID" for each key must be
unique and must be configured identically on all boxes. This value
is any 4-byte number. The default value for a single key should be
zero. When configuring MD5 keys, an optional time-out value can be
supplied.
The timeout value is used for two reasons:
1. When a new key is added, no system will send a message using this
new key for time-out number of seconds. All systems will accept
messages using this key immediately. If this is the first key, the
system should begin using it immediately as unit that are not yet
configured for security will ignore the security TLV. The system
should also accept messages that do not contain the security TLV for
this time-out period. This gives the system Administrator time-out
seconds to configure the key on all systems involved without having a
disruption in service.
2. When it becomes desirable to remove or replace a password, the
time-out value is used to tell each system to stop sending messages
with a key immediately. All systems should also stop accepting
messages using that key after time-out seconds. If the key is being
replaced, the old key must be accepted for time-out seconds. Again,
this will give the system Administrator time-out seconds to remove or
replace this key for each system.
Kersey Expires September 7, 2006 [Page 11]
Internet-Draft Dynamic Feedback Protocol March 2006
5.2. Load TLV
The Load TLV contains the actual load information being reported via
the DFP Agents on the servers. The real servers are first grouped by
their port number and protocol type requiring a seperate Load TLV for
each grouping. The individual servers are then listed with their
individual weights. The BindID is included in the definition of the
server to allow a single server to be bound to multiple virtual
servers. By having a distinct BindID, the server can report a
different weight for each virtual 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | Protocol | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Hosts |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Preference Field - one per Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Preference Field - one per Host (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port Number, 2-bytes: port number of host server. This can be
represented as a wildcard value, 0x0000.
Protocol, 1-byte: protocol of the host server. This can be
represented as a wildcard value, 0x00.
Flags, 1-byte: miscellaneous flags - currently set to zeros.
Number of Hosts, 2-bytes: total number of host servers included in
this reporting of weights.
Reserverd, 2-bytes: all zeros.
Preference Field, 8-bytes: One for each host being reported, which
includes: IP address (4-bytes), BindID (2-bytes), and Weight
(2-bytes).
5.2.1. Weight Value
The weight value in the Load TLV is used by the SLB device to
determine which server is most available or healthiest to service the
next flow. In the most simplistic terms, the higher the weight value
the more available the server. The weight of zero means that the
Kersey Expires September 7, 2006 [Page 12]
Internet-Draft Dynamic Feedback Protocol March 2006
server is not available for any more flows. This is equivalent to
taking the real server out-of-service.
The way the weight value is exactly used depends on the load
distribution algorithim that the SLB device is using. The most
common load distribution algorithims that use a weight value are
weighted least connections and weighted round robin.
The weighted least connections algorithm distributes the next flow to
the server that has the fewest number of flows. It will use the
weight value as a way to have the overall load distributed for a
particular virtual server. For example, if there are 3 servers with
weights of 1, 1, and 2, then the servers with a weight of 1 would
have 25% each of the total flows for the virtual server, and the
server with a weight of 2 would have 50% of the total flows for the
same virtual server.
The weighted round robin algorithm distributes the next flow based on
which server got the previous flow and the weights. The servers for
a virtual server will get 'weight value' number of flows in a row,
then the next server will get its 'weight value' number of flows in a
row. This will repeat until the last server gets its flows, then it
will go back to the top of the list.
5.3. Keep-alive TLV
The Keep-alive TLV is part of the DFP configuration for the control
connection maintained between the SLB device and the DFP Agent. This
allows the DFP Manager to inform the DFP Agent about the minimum time
interval in which the DFP Agent must send information over the DFP
control connection.
If the SLB device does not receive an update from the DFP Agent in
the amount of time configured, the SLB device will close the
connection. Once the connection is closed, the SLB device will
attempt to establish a new control connection to the DFP Agent.
During the time the DFP Manager is re-establishing the control
connection, it must use the pre-configured static weight for each
real server it was receiving updates on via DFP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keep-alive Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kersey Expires September 7, 2006 [Page 13]
Internet-Draft Dynamic Feedback Protocol March 2006
Keep-alive time: time in seconds for which activity over the DFP
control connection must be detected or the connection will be
terminated. A timeout value of zero means that the DFP control
connection will not be terminated due to no response from the DFP
Agent.
5.4. BindID Table TLV
The BindID Table TLV is a mapping of BindID values to client network
addresses for a particular real server. The SLB device may use the
client IP address as part of its server selection process. Allowing
the use of the client address in the server selection process for a
flow allows for a mechanism in which Quality of Service can be
implemented.
The inclusion of a BindID, and thus a client's network, in the
server's availability report allows a server to be more available for
some client networks while simultaneously being less available for
others. As each server may have a different "representation" of the
mapping between a client network and the BindID value, information
about the server is included in this TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Port Number | Protocol |0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Entries |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BindID Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BindID Field (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BindID Field (con't) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server IP Address, 4-bytes: IP address of Server to which BindID's
apply.
Server Port Number, 2-bytes: port number of Server to which BindID's
apply.
Protocol, 1-byte: protocol type of Server to which BindID's apply.
Kersey Expires September 7, 2006 [Page 14]
Internet-Draft Dynamic Feedback Protocol March 2006
Reserved, 1-byte: all zeros.
Number of Entries, 2-bytes: number of BindID fields being reported in
this message.
Reserved, 2-bytes: all zeros.
BindID Field, 12-bytes: must include one for each Number of Entries
specified.
The format of the BindID Field is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BindID | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Network IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask of Client Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kersey Expires September 7, 2006 [Page 15]
Internet-Draft Dynamic Feedback Protocol March 2006
6. Defined Messages
The following message types exist:
+----------------------------------------+
| Message Name | Type Value |
+----------------------------------------+
| Preference Information | 0x0101 |
+----------------------------------------+
| Server State | 0x0201 |
+----------------------------------------+
| DFP Parameters | 0x0301 |
+----------------------------------------+
| BindID Request | 0x0401 |
+----------------------------------------+
| BindID Report | 0x0402 |
+----------------------------------------+
| BindID Change Notify | 0x0402 |
+----------------------------------------+
| Customer Private Use | 0x0500-0x05FF |
+----------------------------------------+
6.1. Preference Information Message
The Preference Information message is sent from the DFP Agent to the
DFP Manger. It is used to report the availability or health (i.e.,
weight) for 0 to 128 Servers. If a DFP Agent does not have any
information to report, it must send this message with the Load TLV
not included. This is to act as an application level keep-alive as
descsribed in Section 5.3.
+--------------------------+
| Signal Header |
+--------------------------+
| Optional Security |
+--------------------------+
| Load |
+--------------------------+
Kersey Expires September 7, 2006 [Page 16]
Internet-Draft Dynamic Feedback Protocol March 2006
6.2. Server State Message
The Server State message is sent from the DFP Manager to the DFP
Agent. It is used to allow the DFP Manager to inform a DFP Agent
what it has decided independently from any status being reported by a
DFP Agent to take a server out-of-service or to place a server back
in-service. The DFP Agent may log this information, but it should
not change its internally stored availability / weight value for any
server reported in this message. Instead, the DFP Agent should
continue to report what it considers its availability of the server.
The availability / status of 0 to 128 real servers may be included in
this message.
+--------------------------+
| Signal Header |
+--------------------------+
| Optional Security |
+--------------------------+
| Load |
+--------------------------+
6.3. DFP Parmaters Message
The DFP Parameters message is used to send configuration information
about the DFP control connection from the DFP Manager to the DFP
Agent. This information allows the DFP Agent to know how to handle
the DFP control connection. Currently the only configuration
information passed is the keep-alive interval as described in
Section 5.3.
+--------------------------+
| Signal Header |
+--------------------------+
| Optional Security |
+--------------------------+
| Keep-alive |
+--------------------------+
6.4. BindID Request Message
The BindID Request message is used by the DFP Manager to request an
updated version of the BindID database from the DFP Agent. Upon
receiving this message, the DFP Agent should respond with BindID
Report messages in which the BindID database is reported, which is
described in Section 5.4. This message contains no data and
therefore it contains no additional TLVs.
Kersey Expires September 7, 2006 [Page 17]
Internet-Draft Dynamic Feedback Protocol March 2006
+--------------------------+
| Signal Header |
+--------------------------+
| Optional Security |
+--------------------------+
6.5. BindID Report Message
The BindID Report message is sent in response to a BindID Request
message. It is never sent autonomously. This message contains a
mapping of BindIDs to client networks, and it is used by the DFP
Agent to report this information to the DFP Manager. A seperate
BindID TLB message should be sent for each DFP Agent's real server
tables. The DFP Agent should send its entire table anytime the
BindID table is requested. When the entire table has been sent (or
there is no table to send), this message should be sent with the
BindID table TLV entries with a zero Server IP address, Server port,
protocol, and number of entries. This indicates there is no more
data to be sent.
+--------------------------+
| Signal Header |
+--------------------------+
| Optional Security |
+--------------------------+
| BindID Table |
+--------------------------+
6.6. BindID Change Notify Message
The BindID Change Notify message is used by a DFP Agent to report
that a change has been made to its BindID database. This
notification gives the DFP Manager the option of requesting a new
copy of the entire table from the DFP Agent. The request and report
messages are described in Section 6.4 and Section 6.5, respectively.
This message contains no additional data and therefore does not
contain any additional TLVs.
+--------------------------+
| Signal Header |
+--------------------------+
| Optional Security |
+--------------------------+
Kersey Expires September 7, 2006 [Page 18]
Internet-Draft Dynamic Feedback Protocol March 2006
7. System Flow
Messages are expected to flow in a certain order at a certain time.
That information is included here.
7.1. Control Connection
Before messages can be sent in either direction, the DFP control
connection must be established. It is the job of the DFP Manager to
establish the control connection to the DFP Agent. Currently the DFP
Agent port used in some SLB device implementations is port 8080. The
DFP Manager port is the next available TCP port that the TCP stack
assigns upon connecting. Of course the implementor can choose any
ports or make ports configurable on either side. If the control
connection is not able to be established, then DFP cannot be used to
report real server availability.
If the control connection is dropped or lost, it is up to the DFP
Manager to re-establish the connection. While the connection is not
available, the DFP Manager must use the default values for the real
servers as configured on the DFP Manager. Once the connection is re-
established, it can begin using the dynamic values sent to it by the
DFP Agent.
7.2. DFP Parameter Messages
The DFP Manager must report changes in configuration to the DFP
Agents. This information allows the DFP Agents to know how to handle
the DFP connection to the manager. Currently the only value that can
be changed is the keep-alive time interval. Note: a keep-alive time
interval of zero means to never time out the connection.
7.3. Status Reporting of Real Servers
The 'Preference Info' message is used to communicate the availability
(weight) of the real server to the DFP Manager. If a DFP Agent does
not have any information to report, it must send this message with
the Load TLV not included. This is intended to be an application
keep-alive message.
7.4. Server Status Updates to DFP Agent
This message is sent from the DFP Manager to the DFP Agent. The
purpose is for the DFP Manager to report any change in status that is
it able to determine from analysis of the flows going through the
device. The DFP Agent should not stop reporting for that real server
when it receives this message. The DFP Agent should only log the
information.
Kersey Expires September 7, 2006 [Page 19]
Internet-Draft Dynamic Feedback Protocol March 2006
7.5. DFP Manager Update Request
The DFP Manager can request for updates to the BindID table to be
sent to it. In order to do this, the DFP Manager would send the
BindID Request Message to the DFP Agent. The DFP Agent will then
provide the information via the BindID Report Message. Both message
types are defined in the 'Defined Messages' section.
7.6. Real Server Updates to DFP Manager
If the DFP Agent needs to update the DFP Manager with the current
status of its BindID table, then it can send the BindID CHange
Notification Message to the DFP Manger. It is then up to the DFP
Manager to request the full table update via the BindID Request
Message.
8. Normative References
[1] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5",
RFC 1828, August 1995.
Kersey Expires September 7, 2006 [Page 20]
Internet-Draft Dynamic Feedback Protocol March 2006
Author's Address
Curt Kersey
Cisco Systems, Inc.
500 Northridge Road
Suite 800
Atlanta, GA 30350
US
Phone: +1 678 352 2744
Email: eck@cisco.com
URI: http://www.cisco.com/
Kersey Expires September 7, 2006 [Page 21]
Internet-Draft Dynamic Feedback Protocol March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kersey Expires September 7, 2006 [Page 22]
