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]