返回首页

RFC 4678 - Server/Application State Protocol v1

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup A.Bivens RequestforComments:4678IBMResearch Category:Informational September2006 Server/ApplicationStateProtocolv1 StatusofThisMemo ThismemoprovidesinformationfortheInternetcommunity.Itdoes notspecifyanInternetstandardofanykind.Di
  Network Working Group                                              A. Bivens
Request for Comments: 4678                                  IBM Research
Category: Informational                                        September 2006

                  Server/Application State Protocol v1

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

IESG Note

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and in particular notes that the decision to publish is not
   based on IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.  Readers of
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Abstract

   Entities responsible for distributing work across a group of systems
   traditionally do not know a great deal about the ability of the
   applications on those systems to complete the work in a satisfactory
   fashion.  Workload management systems traditionally know a great deal
   about the health of applications, but have little control over the
   rate in which these applications receive work.  The
   Server/Application State Protocol (SASP) provides a mechanism for
   load balancers and workload management systems to communicate better
   ways of distributing the existing workload to the group members.

Table of Contents

   1. Introduction ....................................................3
      1.1. Overview ...................................................3
      1.2. Identities .................................................4
   2. Requirements Notation ...........................................4
   3. Conventions Used in This Document ...............................4
   4. General Message Structure .......................................4
      4.1. TLV Structure ..............................................6
      4.2. Component Types ............................................6
      4.3. SASP Protocol Header .......................................7
      4.4. Version Negotiation ........................................8
   5. Singular Protocol Components ....................................9
      5.1. Member Data Component ......................................9
      5.2. Group Data Component ......................................11
      5.3. Weight Entry Data Component ...............................12
      5.4. Member State Instance Component ...........................14
   6. Group Protocol Components ......................................15
      6.1. Group of Member Data Component ............................15
      6.2. Group of Weight Data Component ............................16
      6.3. Group of Member State Data Components .....................17
   7. Protocol Messages ..............................................17
      7.1. Registration Request and Reply ............................18
           7.1.1. Registration Request ...............................18
           7.1.2. Registration Reply .................................19
      7.2. DeRegistration Request and Reply ..........................20
           7.2.1. DeRegistration Request .............................21
           7.2.2. DeRegistration Reply ...............................22
      7.3. Get Weights Request and Reply .............................23
           7.3.1. Get Weights Request ................................24
           7.3.2. Get Weights Reply ..................................25
      7.4. Send Weights ..............................................26
      7.5. Set Member State Request and Reply ........................27
           7.5.1. Set Member State Request ...........................28
           7.5.2. Set Member State Reply .............................29
      7.6. Set Load Balancer State Request and Reply .................30
           7.6.1. Set LB State Request ...............................30
           7.6.2. Set LB State Reply .................................32
   8. Example of SASP Message Encoding ...............................32
   9. Protocol Flow ..................................................37
      9.1. Normal Protocol Flow ......................................37
      9.2. Behavior in Error Cases ...................................39
      9.3. Example Flow 1: Load Balancer Registration,
           Getting Weights, and Application-Side Quiescing ...........41
      9.4. Example Flow 2:  Set Load Balancer State, Application
           Registration, and Load Balancer Group DeRegistration ......43
      9.5. Avoiding Single Points of Failure .........................44

   10. Security Considerations .......................................45
   11. Normative References ..........................................46
   Appendix A. Acknowledgements ......................................47

1.  Introduction

1.1.  Overview

   The Server/Application State Protocol is designed to enable load
   balancers or schedulers (1) to receive traffic weight recommendations
   from Workload Managers, (2) to register with Workload Managers
   members of load balancing/scheduling groups, and (3) to enable
   Workload Managers to suggest new load balancing group members to load
   balancers and schedulers

   The figure below shows where the SASP entities are in typical load
   balancing topology.

                                            ----------
                                            | Group  |
                                   -------->|Member 1|<--|
                                   |        ----------   |
                                   |                     |
     ---------        ----------   |        ----------   |
     |Request|<------>|  Load  |---|        | Group  |   |
     |Origins|<------>|Balancer|----------->|Member 2|<--|
     ---------        |        |---|        ----------   |
                      ----------   |                     |
                          ^        |        ----------   |
                          |        -------->| Group  |   |
                     SASP |                 |Member 3|<--|
                    -------                 ----------   |
                    |                                    |
                    |      --------------------          |
                    |      |     Group        |     SASP |
                    ------>| Workload Manager |<----------
                           --------------------

                                 Figure 1

   SASP is a binary protocol that facilitates communication from load
   balancers/schedulers to Workload Managers.  The connection between
   the Group Workload Manager (GWM) and the load balancer/scheduler is
   expected to be a long-running TCP connection.  In SASP interactions,
   the GWM acts as a SASP server waiting to receive connections from the
   other SASP components.  Server port 3860 has been registered with the
   IANA for SASP communications.  It is expected that all SASP
   components are configured with the DNS name of the GWM to develop

   this connection.  Security in SASP is handled by transporting binary
   messages over Secure Socket Layer/Transport Layer Security (SSL/TLS).
   This document only describes the message format and protocol behavior
   above the connection and security layers.  Connection and security
   aspects including SSL’s authentication and encryption will be
   implementation specific.

1.2.  Identities

   SASP identifies a load balancer by a UTF-8 string called a "LB UID".
   A group of "equivalent" servers providing a service is identified by
   a UTF-8 string called a "Group Name", which is interpreted in the
   context of the LB UID.  A server is identified by its IP address and
   (optional) port and protocol numbers.  A GWM is only identified
   implicitly as the entity on the other end of the TCP connection from
   a load balancer or group member.  All of these identifiers are local;
   there are no globally unique identifiers.  The LB UID and GroupName
   fields are unstructured so that components could assign values to
   these fields that are meaningful to an administrator.  For example,
   in many cases, a load balancer would use the name an administrator
   provided for the serverfarm group as the groupname in a SASP-
   specified group.  Since the naming options in industry load balancers
   do not carry explicit naming restrictions, SASP naming options also
   carry no naming restrictions.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Conventions Used in This Document

   o  Load Balancer - Entity responsible for distributing requests
      amongst the available members.

   o  Member - Machine, process, or application used to service
      requests.

   o  Group Workload Manager (GWM) - Entity responsible for reporting or
      managing a group of members on multiple machines.

4.  General Message Structure

   Any string interpreted by the group workload manager is assumed to
   use UTF8.  Components implementing SASP MUST support the printable
   ASCII subrepertoire of UTF8 (0x20-0x7E).  Components MAY also choose
   to provide support for additional UTF8 character encodings.  It is

   recommended that customers using SASP-enabled products configure the
   string-generating components (load balancers and group members) to
   use the same character repertoire.

   Many of the SASP structures involve the transfer of multi-byte
   integer values.  In all cases where multi-byte integer values are
   used, they are considered to be in network-byte order (big-endian).

   SASP is organized into several message components.  For extendibility
   and ease of processing, each message component is described in a TLV
   (Type, Length, Value) format.  An illustration of the SASP structure
   can be found in the example below.  The first section is the header
   followed by the message component type.  As mentioned, the header,
   message component, and all other components have a TLV format.  Each
   component value contains a variable number of fields, some of which
   refer to upcoming components (explained component descriptions are in
   upcoming sections).  After the first message component, any number of
   additional components may be included (as stipulated in the fields of
   the message type).

   -------------------------------------------------
   |            |T| Type (SASP Header Type)        |
   |    SASP    |----------------------------------|
   |   Header   |L| Length of SASP header TLV      |
   |            |----------------------------------|
   |            |V| Header fields                  |
   |-----------------------------------------------|
   |            |T| Type (Message Type)            |
   |  Message   |----------------------------------|
   |    Type    |L| Length of this Message Type TLV|
   | Component  |----------------------------------|
   |            |V| Component fields               |
   |-----------------------------------------------|
   |            |T| Type (Component Type)          |
   |            |----------------------------------|
   |Component-1 |L| Length of this TLV             |
   |            |----------------------------------|
   |            |V| Component fields               |
   |-----------------------------------------------|
   | ...                                           |
   |-----------------------------------------------|
   |            |T| Type (Component Type)          |
   |            |----------------------------------|
   |Component-n |L| Length of this TLV             |
   |            |----------------------------------|
   |            |V| Component fields               |
   -------------------------------------------------

                                 Figure 2

4.1.  TLV Structure

   An illustration of the TLV format is shown below.  The Type is a
   two-byte field containing a binary value for the component type.  The
   Length is a two-byte field containing the size of the TLV in bytes
   (including the Type and Length fields).  The Value field is a
   variable-length field that actually contains the data of the
   component.

   < xxxx xxxx xxxx xxxx, xxxx xxxx xxxx xxxx, xxxx...........xxxx >
     |-----------------|  |-----------------|  |-----------------|
        Type(2 bytes)       Length(2 bytes)      Value(variable)

                                 Figure 3

4.2.  Component Types

   The TLV structure requires a type value for each protocol component.
   All SASP types are listed in this section.

      Reserved 0x0000-0x1000

      Message Types

         Registration Request 0x1010

         Registration Reply 0x1015

         DeRegistration Request 0x1020

         DeRegistration Reply 0x1025

         Get Weights Request 0x1030

         Get Weights Reply 0x1035

         Send Weights 0x1040

         Set Load Balancer State Request 0x1050

         Set Load Balancer State Reply 0x1055

         Set Member State Request 0x1060

         Set Member State Reply 0x1065

      Utility Component Types

         SASP Header 0x2010

      Singular Component Types

         Member Data 0x3010

         Group Data 0x3011

         Weight Entry Data 0x3012

         Member State Instance 0x3013

      Group Component Types

         Group of Member Data 0x4010

         Group of Weight Entry Data 0x4011

         Group of Member State Data 0x4012

      Reserved 0xF000-0xFFFF

4.3.  SASP Protocol Header

   An illustration of the SASP Header is found in the table below.  It
   is expected that every message will start with the SASP Protocol
   Header component.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   SASP header type (0x2010)   |       Size of this TLV        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |                     Message Length
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                       Message ID
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |
      +-+-+-+-+-+-+-+-+

                                 Figure 4

   o  Version: The version of the protocol used in this message.

   o  Message Length: A 4-byte signed integer value representing the
      total length of the SASP message.  It is said to be a signed
      4-byte value to make any Java implementations easier (or any other
      implementations without unsigned values); however, no negative
      lengths are valid.

   o  Message ID: Each request message is given a 4-byte Message ID by
      the message originator, which is simply returned in the Message ID
      field of the reply.  This field is meant to assist the requester
      in correlating replies to the appropriate request when many
      requests have been sent.  In the Send Weights message (the only
      message transaction that has no reply), this field serves no
      purpose.

4.4.  Version Negotiation

   To negotiate the version of the protocol used by the entities
   involved in the connection, the GWM views the version included in the
   load balancer request as the load balancer’s proposed version.

   If the GWM supports the version proposed by the load balancer, it
   will respond to the connection with the appropriate response code and
   the load balancer’s proposed version in the response header.  This
   proposed version should be the version used for all messages in this
   connection.

   If the GWM does not support the version proposed by the load
   balancer, the GWM will respond with a "message not understood"
   response code and the GWM’s highest supported SASP version in the
   version field of the response header.  This is an indication for the
   load balancer to come down to GWM’s SASP version level.

5.  Singular Protocol Components

   The most basic of SASP components are singular components because
   they describe a single instance of a member, member resource, member
   weight, or group.  Some of the SASP components reuse other SASP
   components.  When this is the case, any component being reused by a
   base component will simply be given immediately following the base
   component.  Some examples of this technique are seen and explained in
   the Weight Entry and Member State Instance components.

5.1.  Member Data Component

   The member data component describes a particular member and is
   referred to by other components.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Member Data Type (0x3010)   |       Size of this TLV        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Protocol    |             Port              |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
      |                                                               |
      +                                                               +
      |                                                               |
      +                   IP Address of Member                        +
      |                                                               |
      +                                               +-+-+-+-+-+-+-+-+
      |                                               |  Label Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                          Label                                .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

   o  Protocol: The assigned number of the IP transport layer used in
      the Protocol Field of the IP header.  These are defined in
      [RFC1700]; however, a current list is maintained at
      http://www.iana.org.
      for example: TCP = 0x06, UDP = 0x11, etc.

   o  Port: The port number used for communication to the member.
      *** A value of 0 can be given for the Protocol and Port to signify
      a system level member.  However, 0 shouldn’t be perceived as a
      wildcard for either Port or Protocol fields (i.e., a
      deregistration request that includes a MemberData component with a
      0 for the port doesn’t mean deregister all applications listening
      on any port of that IP and protocol).

   o  IP Address: The current format is described by the following 16
      bytes, where IPv4 addresses are represented as "IPv4-compatible
      IPv6 addresses" [RFC4291].  In the following example, the x’s and
      zeros represent 4-bit hex values.  The x’s describe arbitrary hex
      values.

         IPv4 Address: 00 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx

         IPv6 Address: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

   o  Label length: The length, in bytes, of the label string to follow.

   o  Label: A UTF8 string that may be set while registering a member.
      This string is opaque to the GWM and is simply included with any
      correspondence containing the member data component.  Note that
      the size of this label is <= 255 bytes.  Because UTF8 character
      encodings may be up to 6 bytes, care must be exercised by the load
      balancer or member to make sure the UTF8 string it sends the GWM
      is in fact <= 255 bytes.

5.2.  Group Data Component

   The group data component simply describes a group with which to
   associate other singular components.

      0                   1                   2                   3
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容