Network Working Group C. Kersey Internet-Draft Cisco Systems, Inc. Expires: February 26, 2006 August 25, 2005 Dynamic Feedback Protocol draft-eck-dfp-00 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 February 26, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 February 26, 2006 [Page 1] Internet-Draft Dynamic Feedback Protocol August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 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 3.2. System Flow . . . . . . . . . . . . . . . . . . . . . . . 6 4. Message Structure . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 7 5. Defined TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. MD5 Security Authentication . . . . . . . . . . . . . 10 5.2. Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Weight Value . . . . . . . . . . . . . . . . . . . . . 12 5.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. BindID Table . . . . . . . . . . . . . . . . . . . . . . . 13 6. Defined Messages . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Preference Information Message . . . . . . . . . . . . . . 15 6.2. Server State Message . . . . . . . . . . . . . . . . . . . 16 6.3. DFP Parmaters Message . . . . . . . . . . . . . . . . . . 16 6.4. BindID Request Message . . . . . . . . . . . . . . . . . . 16 6.5. BindID Report Message . . . . . . . . . . . . . . . . . . 17 6.6. BindID Change Notify Message . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Kersey Expires February 26, 2006 [Page 2] Internet-Draft Dynamic Feedback Protocol August 2005 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 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 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. 1.2. Overview Editor's note: Need to add 1.3. 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: software running on the real server that collects Kersey Expires February 26, 2006 [Page 3] Internet-Draft Dynamic Feedback Protocol August 2005 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. This will also be referred to as a DFP agent. DFP manager: the network entity that the 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 entity. Kersey Expires February 26, 2006 [Page 4] Internet-Draft Dynamic Feedback Protocol August 2005 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 seperation 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. 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 TLV values. 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. The security rules are easy. 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 a receiving unit is not configured for any security type, the security TLV does not have to be present. If the security TLV is present in this case, it is ignored while the rest of the message is processed normally. Kersey Expires February 26, 2006 [Page 5] Internet-Draft Dynamic Feedback Protocol August 2005 3. Architecture 3.1. Functional Structure DFP is a protocol between DFP agents running on the real servers in a server farm and an outside entity. That outside entity could be 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 DFP. The agent software can gather whatever information it wants to about the health of the real server. The only part that is important to DFP is how the information is sent from the real server. DFP is the protocol that defines how the data is sent. 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. [Editors note: here is where we need to plug in RSERPOOL to provide the dynamic discovery :-D] 3.2. System Flow Editor's note: Need to add Kersey Expires February 26, 2006 [Page 6] Internet-Draft Dynamic Feedback Protocol August 2005 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 signal header is used to specify the DFP version number and message type. 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 February 26, 2006 [Page 7] Internet-Draft Dynamic Feedback Protocol August 2005 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 February 26, 2006 [Page 8] Internet-Draft Dynamic Feedback Protocol August 2005 5. Defined TLV The following TLVs are defined. TLVs are used to relay necessary data based on the message type. Defined messages are listed later. +-------------------------------------+ | 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 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. If the TLV is not present, then security is disabled. If this TLV is present, then it must be immediately after the Signal Header. The definition: 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. Kersey Expires February 26, 2006 [Page 9] Internet-Draft Dynamic Feedback Protocol August 2005 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. 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 are set to NULL (i.e. zeros) when calculating this hash value. 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 Kersey Expires February 26, 2006 [Page 10] Internet-Draft Dynamic Feedback Protocol August 2005 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. 5.2. Load 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Preference Field - one per Host | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Preference Field - one per Host (con't) | Kersey Expires February 26, 2006 [Page 11] Internet-Draft Dynamic Feedback Protocol August 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 zero. Number of Hosts, 2-bytes: total number of host servers included in this reporting of weights. Reserved, 2-bytes: set to zero. 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 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 server is not available for any more flows. 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. Kersey Expires February 26, 2006 [Page 12] Internet-Draft Dynamic Feedback Protocol August 2005 5.3. Keep-alive The Keep-alive TLV is part of the configuration for the connection maintained between the SLB device and the DFP agent running on the server. This TLV has the configuration to allow the SLB device 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 minimimum 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 control connection will not be terminated due to no response from the DFP agent. 5.4. BindID Table The BindID Table TLV is a mapping of BindID values to client network addresses for a particular server. This TLV is a method by which these mappings can be provided by the DFP agent. 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. Kersey Expires February 26, 2006 [Page 13] Internet-Draft Dynamic Feedback Protocol August 2005 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. Number of Entries, 2-bytes: number of BindID fields being reported in this message. BindID Field, 12-bytes: must include one for each Number of Entries specified. The format is: Host BindID, 2-bytes; Zeros, 2-bytes; IP address of Client network, 4-bytes; Netmask of Client network, 4-bytes. Kersey Expires February 26, 2006 [Page 14] Internet-Draft Dynamic Feedback Protocol August 2005 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 SLB device. It is used to report the status (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. +--------------------------+ | Signal Header | +--------------------------+ | Optional Security | +--------------------------+ | Load | +--------------------------+ Kersey Expires February 26, 2006 [Page 15] Internet-Draft Dynamic Feedback Protocol August 2005 6.2. Server State Message The Server State message is sent from the SLB device to the DFP agent. It is used to allow the SLB device to inform a DFP agent what it has decided independently from any status being reported 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 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 status, weight value, of 0 to 128 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 SLB device 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. +--------------------------+ | Signal Header | +--------------------------+ | Optional Security | +--------------------------+ | Keep-alive | +--------------------------+ 6.4. BindID Request Message The BindID Request message is used by the SLB device to request an updated version of the BindID database. Upon receiving this message, the DFP agent should respond with BindID Report messages in which the BindID database is reported. This message contains no data and therefore it contains no additional TLVs. +--------------------------+ | Signal Header | +--------------------------+ | Optional Security | Kersey Expires February 26, 2006 [Page 16] Internet-Draft Dynamic Feedback Protocol August 2005 +--------------------------+ 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 to report this information to the SLB device. A seperate should be sent for each server's 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 sued by a DFP agent to report that a change has been made to its BindID database. This notification allows the DFP manager the option of requesting a new copy of the entire table. This message contains no additional data and therefore does not contain any additional TLVs. +--------------------------+ | Signal Header | +--------------------------+ | Optional Security | +--------------------------+ 7. Normative References [1] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995. Kersey Expires February 26, 2006 [Page 17] Internet-Draft Dynamic Feedback Protocol August 2005 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 February 26, 2006 [Page 18] Internet-Draft Dynamic Feedback Protocol August 2005 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 (2005). 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 February 26, 2006 [Page 19]