Network Working Group                                         R. Stewart
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Experimental                                     Q. Xie
Expires: January 10, 2008                                 Motorola, Inc.
                                                             M. Stillman
                                                                   Nokia
                                                               M. Tuexen
                                      Muenster Univ. of Applied Sciences
                                                            July 9, 2007


    Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace
                 Redundancy Protocol (ENRP) Parameters
                draft-ietf-rserpool-common-param-12.txt

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 January 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).








Stewart, et al.         Expires January 10, 2008                [Page 1]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


Abstract

   This document details the parameters of the Aggregate Server Access
   Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP)
   protocols defined within the Reliable Server Pooling (RSERPOOL)
   architecture.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Parameters in General  . . . . . . . . . . . . . . . . . . . .  4
   3.  ENRP-ASAP Common Parameters  . . . . . . . . . . . . . . . . .  5
     3.1.  IPv4 Address Parameter . . . . . . . . . . . . . . . . . .  7
     3.2.  IPv6 Address Parameter . . . . . . . . . . . . . . . . . .  7
     3.3.  SCTP Transport Parameter . . . . . . . . . . . . . . . . .  7
     3.4.  TCP Transport Parameter  . . . . . . . . . . . . . . . . .  9
     3.5.  UDP Transport Parameter  . . . . . . . . . . . . . . . . .  9
     3.6.  Pool Member Selection Policy Parameter . . . . . . . . . . 10
     3.7.  Pool Handle Parameter  . . . . . . . . . . . . . . . . . . 11
     3.8.  Pool Element Parameter . . . . . . . . . . . . . . . . . . 12
     3.9.  Server Information Parameter . . . . . . . . . . . . . . . 13
     3.10. Operation Error Parameter  . . . . . . . . . . . . . . . . 14
       3.10.1.  Unspecified Error . . . . . . . . . . . . . . . . . . 16
       3.10.2.  Unrecognized Parameter Error  . . . . . . . . . . . . 16
       3.10.3.  Unrecognized Message Error  . . . . . . . . . . . . . 16
       3.10.4.  Invalid Values Error  . . . . . . . . . . . . . . . . 16
       3.10.5.  Non-unique PE Identifier Error  . . . . . . . . . . . 16
       3.10.6.  Inconsistent Pool Policy Error  . . . . . . . . . . . 16
       3.10.7.  Lack of Resources Error . . . . . . . . . . . . . . . 16
       3.10.8.  Inconsistent Transport Type Error . . . . . . . . . . 16
       3.10.9.  Inconsistent Data/Control Configuration Error . . . . 17
       3.10.10. Rejected due to security considerations . . . . . . . 17
       3.10.11. Unknown Poor Handle Error . . . . . . . . . . . . . . 17
     3.11. Cookie Parameter . . . . . . . . . . . . . . . . . . . . . 17
     3.12. PE Identifier Parameter  . . . . . . . . . . . . . . . . . 17
     3.13. PE Checksum Parameter  . . . . . . . . . . . . . . . . . . 18
   4.  Common Message Formats . . . . . . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
     5.1.  A New Table for RSerPool Parameter Types . . . . . . . . . 21
     5.2.  A New Table for RSerPool Error Causes  . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26





Stewart, et al.         Expires January 10, 2008                [Page 2]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


1.  Introduction

   Aggregate Server Access Protocol (ASAP) [4] in conjunction with the
   Endpoint Handlespace Redundancy Protocol (ENRP) [5] provides a high
   availability data transfer mechanism over IP networks.

   Both protocols work together and so share many common parameters used
   in message formats.  This document details the common message
   parameters shared between the two protocols.  This document provides
   parameter formats only, for procedures and message composition please
   refer to the respective ASAP [4] and ENRP [5] documents.

1.1.  Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   RFC2119 [2].

































Stewart, et al.         Expires January 10, 2008                [Page 3]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


2.  Parameters in General

   All parameters described below MUST be in Network Byte Order (a.k.a.
   Big Endian, i.e., the most significant byte first) during
   transmission.

   Please note that messages in both ENRP and ASAP are often composed of
   multiple parameters.  These parameters may also be nested.  In such a
   case a nested parameter will include the length of the padding
   between the nested parameters but not the last padding.









































Stewart, et al.         Expires January 10, 2008                [Page 4]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


3.  ENRP-ASAP Common Parameters

   Parameters are defined in the following Type-Length-Value (TLV)
   format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Parameter Type       |       Parameter Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                       Parameter Value                         :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type: 16 bits (unsigned integer)

   The Type field is a 16 bit identifier of the type of parameter.  It
   takes a value of 0 to 65534.

   The value of 65535 is reserved for IETF-defined extensions.  Values
   other than those defined in specific ENRP parameter description are
   reserved by IETF.  (Additional types, when needed, will be defined in
   the future through appropriate IETF/IANA procedures.)

   The Parameter Types are encoded such that the highest-order two bits
   specify the action that must be taken if the processing endpoint does
   not recognize the Parameter Type.

   00 Stop processing this ENRP or ASAP message and discard it, do not
      process any further parameters within it.

   01 Stop processing this ENRP or ASAP message and discard it, do not
      process any further parameters within it, and report the
      unrecognized parameter in an 'Unrecognized Parameter' error (see
      Section 3.10).

   10 Skip this parameter and continue processing.

   11 Skip this parameter and continue processing, but report the
      unrecognized parameter in an 'Unrecognized Parameter' error (see
      Section 3.10).

   The values of parameter types are defined as follows:







Stewart, et al.         Expires January 10, 2008                [Page 5]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


      Value     Parameter Type
      -----     ----------
      0x0       - (reserved by IETF)
      0x1       - IPv4 Address
      0x2       - IPv6 Address
      0x3       - SCTP Transport
      0x4       - TCP Transport
      0x5       - UDP Transport
      0x6       - Pool Member Selection Policy
      0x7       - Pool Handle
      0x8       - Pool Element
      0x9       - Server Information
      0xa       - Operation Error
      0xb       - Cookie
      0xc       - PE Identifier
      0xd       - PE Checksum

      others    - (reserved by IETF)

                                 Figure 2

   Parameter Length: 16 bits (unsigned integer)

   The Parameter Length field contains the size of the parameter in
   bytes, including the Parameter Type, Parameter Length, and Parameter
   Value fields.  Thus, a parameter with a zero-length Parameter Value
   field would have a Length field of 4.

   The total length of a parameter (including Type, Parameter Length and
   Value fields) MUST be a multiple of 4 bytes.  If the length of the
   parameter is not a multiple of 4 bytes, the sender MUST pad the
   parameter at the end (i.e., after the Parameter Value field) with all
   zero bytes.  The length of this padding is not included in the
   Parameter Length field.  A sender MUST NOT pad with more than 3
   bytes.  The receiver MUST ignore the padding bytes.

   (Editor's note: clarify further that any padding inside in the
   parameter, such as the padding in sub-param is included in the total
   length)

   Parameter Value: variable-length.

   The Parameter Value field contains the actual information to be
   transferred in the parameter.







Stewart, et al.         Expires January 10, 2008                [Page 6]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


3.1.  IPv4 Address Parameter

   This parameter defines a TLV that carries an IPv4 address.

    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 = 0x1             |      Length = 0x8             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv4 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address: 32 bits (unsigned integer)

   Contains an IPv4 address.  It is binary encoded.

3.2.  IPv6 Address Parameter

   This parameter defines a TLV that carries an IPv6 address.

    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 = 0x2         |          Length = 0x14        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         IPv6 Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address: 128 bit (unsigned integer)

   Contains an IPv6 address.  It is binary encoded.

3.3.  SCTP Transport Parameter

   This parameter defines a TLV that describes a user transport using
   SCTP protocol.












Stewart, et al.         Expires January 10, 2008                [Page 7]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


    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 = 0x3             |      Length = variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        SCTP port              |          Transport Use        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     IPv4 or IPv6 Address #1                   :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     IPv4 or IPv6 Address #n                   :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets,
   including the Type, Length, SCTP port, reserved fields, and all IP
   address parameters present.

   SCTP port: 16 bits (unsigned integer)

   The SCTP port number signed to this SCTP user transport.

   Transport use: 16 bits (unsigned integer)

   This field represents how the pool element intends this transport
   address to be used.  The field MUST be populated with one of the
   following values:


   Type              |    Value
   ------------------+----------------
   DATA ONLY         |   0x0000
   DATA plus CONTROL |   0x0001


   IPv4 or IPv6 Address #1 - #n:

   Each indicates an IPv4 or IPv6 address parameter (as defined above in
   Section 3.1 and Section 3.2) assigned to this SCTP user transport.
   An SCTP Transport parameter may have a mixed list of IPv4 and IPv6
   addresses and at least one IP address parameter MUST be present in an
   SCTP transport parameter.






Stewart, et al.         Expires January 10, 2008                [Page 8]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


3.4.  TCP Transport Parameter

   This parameter defines a TLV that describes a user transport using
   TCP protocol.

    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 = 0x4             |      Length = variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         TCP port              |          Transport Use        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     IPv4 or IPv6 Address                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets,
   including the Type, Length, TCP port, reserved fields, and IP address
   parameter.

   TCP port: 16 bits (unsigned integer)

   The TCP port number signed to this TCP user transport.

   Transport use: 16 bits (unsigned integer)

   This field represents how the pool element intends this transport
   address to be used.  The field MUST be populated with one of the
   following values:

   Type              |    Value
   ------------------+----------------
   DATA ONLY         |   0x0000
   DATA plus CONTROL |   0x0001


   IPv4 or IPv6 Address:

   Indicates an IPv4 or IPv6 address parameter (as defined above in
   Section 3.1 and Section 3.2) assigned to this TCP user transport.
   Unlike in an SCTP transport, only one IP address parameter can be
   present in a TCP transport parameter.

3.5.  UDP Transport Parameter

   This parameter defines a TLV that describes a user transport using
   UDP protocol.



Stewart, et al.         Expires January 10, 2008                [Page 9]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


    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 = 0x5             |      Length = variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         UDP port              |          (reserved)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     IPv4 or IPv6 Address                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets,
   including the Type, Length, UDP port, reserved fields, and IP address
   parameter.

   UDP port: 16 bits (unsigned integer)

   The UDP port number signed to this UDP user transport.

   IPv4 or IPv6 Address:

   Indicates an IPv4 or IPv6 address parameter (as defined above in
   Section 3.1 and Section 3.2) assigned to this UDP user transport.
   Unlike in an SCTP transport, only one IP address parameter can be
   present in a UDP transport parameter.

   Note: A UDP port MUST NOT be used for control information.  For this
   reason, no Transport Use field is provided.  UDP MUST always be
   treated as a "Data Only" type transport use.

3.6.  Pool Member Selection Policy Parameter

   This parameter defines a pool member selection policy.  RSERPOOL
   supports multiple pool member selection policies and also allows
   definition of new selection policies in the future.

   The enforcement rules and handling procedures of all the policies are
   defined in Section xxxxx in ASAP [4].

   All pool member selection policies, both present and future, MUST use
   the following general parameter format:









Stewart, et al.         Expires January 10, 2008               [Page 10]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


    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 = 0x6             |      Length = variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Policy Type                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Policy-specific Data                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets,
   including the Type, Length, Policy Type, and the Policy-specific Data
   fields.

   Note, the Length field value will NOT include any padding at the end
   of the parameter.

   Policy Type: 32 bits (unsigned integer)

   Specifies the type of selection policy.

   Policy-specific Data:

   The structure and fields for each presently defined policy types are
   described in detail in Policies [6].

3.7.  Pool Handle Parameter

   This parameter holds a pool handle.

    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 = 0x7            |       Length=variable         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                          Pool Handle                          :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets,
   including the Type, Length, and Pool Handle string.




Stewart, et al.         Expires January 10, 2008               [Page 11]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


   Note, the value in Length field will NOT cover any padding at the end
   of the parameter.

   Pool Handle:

   defined as a sequence of (Length - 4) bytes.

3.8.  Pool Element Parameter

   This parameter is used in multiple ENRP messages to represent an ASAP
   endpoint (i.e., a PE in a pool) and the associated information, such
   as its transport address, selection policy, and other operational or
   status information of the PE.

    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 = 0x8            |       Length=variable         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PE Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Home ENRP Server Identifier                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Registration Life                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      User Transport param                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                 Member Selection Policy param                 :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                      ASAP Transport param                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets,
   including the Type, Length, PE Identifier, Registration Life, User
   Transport, and Member Selection Policy parameters.

   Note, the value in Length field will NOT cover any padding at the end
   of this Pool Element parameter.

   PE Identifier: 32 bits (unsigned integer)

   Uniquely identifies the PE in the pool.  The PE picks its identifier
   when it starts up.  See Section ???? in [ASAP] for recommendations on
   PE identifier generation.

   Home ENRP Server Identifier: 32 bits (unsigned integer)



Stewart, et al.         Expires January 10, 2008               [Page 12]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


   Indicates the current home ENRP server of this PE.  Set to all 0's if
   the PE's home ENRP server is undetermined.

   Registration Life: 32 bits (signed integer)

   Indicates the life time of the registration in number of seconds.  A
   value of -1 indicates infinite life time.

   User Transport:

   This can be either an SCTP, TCP, or UDP type transport parameter (see
   Section 3.3, Section 3.4, Section 3.5).  A PE MUST have one and only
   one User Transport.

   Member Selection Policy:

   Contains one of the defined member selection policy parameters (see
   Section 3.6).

   ASAP Transport:

   This indicates the ASAP transport address of the PE and MUST be an
   SCTP type transport parameter (see Section 3.3).

3.9.  Server Information Parameter

   This parameter is used in ENRP to pass basic information of an ENRP
   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 = 0x9            |       Length=variable         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Server ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|                        (reserved)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       Server Transport                        :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets.

   Note, the value in Length field will NOT cover any padding at the end
   of the parameter.




Stewart, et al.         Expires January 10, 2008               [Page 13]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


   Server ID: 32 bit (unsigned integer)

   This is the ID of the ENRP server, as defined in Section xxxxxx in
   ENRP [5] .

   Multicast Flag (M): 1 bit

   If set to '1', indicates the ENRP server is allowed to use multicast
   for communications.  If set to '0', multicast is not used by the
   server.

   Reserved: 31 bits

   MUST be set to 0's by sender and ignored by the receiver.

   Server Transport:

   This is an SCTP Transport Parameter, as defined in Section 3.3 that
   contains the network access address(es), SCTP port number, etc. of
   the ENRP server.

3.10.  Operation Error Parameter

   This parameter is used in both ENPR and ASAP for a message sender to
   report an error(s) to a message receiver.

    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 = 0xa           |       Length=variable         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                    one or more Error Causes                   :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of octets.

   Note, the value in Length field will NOT cover any padding at the end
   of the parameter.

   Error causes are defined as variable-length parameters using the
   following format:






Stewart, et al.         Expires January 10, 2008               [Page 14]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Cause Code          |       Cause Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                    Cause-specific Information                 :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Cause Code: 16 bits (unsigned integer)

   Defines the type of error condition being reported.

         Cause Code
         Value           Cause Code
         ---------      ----------------
          0              Unspecified Error
          1              Unrecognized Parameter
          2              Unrecognized Message
          3              Invalid Values
          4              Non-unique PE Identifier
          5              Inconsistent Pooling Policy
          6              Lack of Resources
          7              Inconsistent Transport Type
          8              Inconsistent Data/Control Configuration
          9              Unknown Poor Handle
         10              Rejected due to security considerations.
         other values    reserved by IETF

                                 Figure 16

   Cause Length: 16 bits (unsigned integer)

   Set to the size of the parameter in bytes, including the Cause Code,
   Cause Length, and Cause-Specific Information fields, but not
   including any padding at the end of this error cause TLV.

   Cause-specific Information: variable length

   This field carries the details of the error condition.

   The following subsections (Section 3.10.1 - Section 3.10.9) define
   specific error causes.







Stewart, et al.         Expires January 10, 2008               [Page 15]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


3.10.1.  Unspecified Error

   This error cause is used to report an unspecified error by the
   sender.  There is no cause specific information.

3.10.2.  Unrecognized Parameter Error

   This error cause is used to report an unrecognized parameter.  The
   unrecognized parameter TLV is included as cause specific information.

3.10.3.  Unrecognized Message Error

   This error cause is used to report an unrecognized message.  The
   unrecognized message TLV is included as cause specific information.

3.10.4.  Invalid Values Error

   This error cause is used to report one or more invalid values found
   in a received parameter.  The offending TLV that contains the invalid
   value(s) is included as cause specific information.

3.10.5.  Non-unique PE Identifier Error

   This error cause is used by an ENRP server to indicate to a
   registering PE that the PE Identifier it chooses has already been
   used by another PE in the pool.  There is no cause specific
   information.

3.10.6.  Inconsistent Pool Policy Error

   This error cause is used by an ENRP server to indicate to a
   registering PE that the Pool Policy it chooses does not match the
   overall policy of the pool.  A Pool Member Selection Policy TLV (see
   Section 3.6) that indicates the overall pool policy is included as
   cause specific information.

3.10.7.  Lack of Resources Error

   This error cause is used to indicate that the sender does not have
   certain resources to perform a requested function.  There is no cause
   specific information.

3.10.8.  Inconsistent Transport Type Error

   This error cause is used by an ENRP server to indicate to a
   registering PE that the User Transport it chooses does not match the
   overall user transport of the pool.  A Transport TLV that indicates
   the overall pool user transport type is included as cause specific



Stewart, et al.         Expires January 10, 2008               [Page 16]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


   information.

3.10.9.  Inconsistent Data/Control Configuration Error

   This error cause is used by an ENRP server to indicate to a
   registering PE that the Transport Use field in the User Transport it
   sent in its registration is inconsistent to the pool's overall data/
   control channel configuration.  There is no cause specific
   information.

3.10.10.  Rejected due to security considerations

   This error cause is used by any endpoint to indicate a rejection of a
   request due to a failure in security credentials or authorizations.

3.10.11.  Unknown Poor Handle Error

   This error cause is used by an ENRP server to indicate to a PE or PU
   that the requested pool is unknown by the server.  There is no cause
   specific information.

3.11.  Cookie Parameter

   This parameter defines a TLV that carries a Cookie.

    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 = 0xb         |       Length=variable         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                             Cookie                            :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 16 bits (unsigned integer)

   Indicates the entire length of the parameter in number of bytes,
   including the Type, Length, and Cookie.

   Cookie: variable length

   The Cookie is an arbitrary byte string of (Length - 4) bytes.

3.12.  PE Identifier Parameter

   This parameter defines a TLV that carries a PE Identifier.




Stewart, et al.         Expires January 10, 2008               [Page 17]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


    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 = 0xc         |         Length=0x8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PE Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PE Identifier: 32 bits (unsigned integer)

   Uniquely identifies the PE in the pool.  The PE picks its identifier
   when it starts up.  See Section ???? in ASAP [4] for recommendations
   on PE identifier generation.

3.13.  PE Checksum Parameter

   This parameter defines a TLV that carries a PE Checksum.

   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 = 0xd         |         Length=0x6            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PE Checksum         |          Padding              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PE Checksum: 16 bits (unsigned integer)

   An overall checksum of all PEs in the current handlespace owned by an
   ENRP server (which is normally the sender of this TLV).  The
   definition and calculation of this checksum is defined in Section
   3.11.2 in ENRP [5].



















Stewart, et al.         Expires January 10, 2008               [Page 18]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


4.  Common Message Formats

   The figure below illustrates the common format for all ASAP and ENRP
   messages.  Each message is formatted with a Message Type field, a
   message-specific Flag field, a Message Length field, and a Value
   field.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Message Type  |   Msg Flags   |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                        Message Value                          :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type: 8 bits (unsigned integer)

   This field identifies the type of information contained in the
   Message Value field.  It takes a value from 0 to 254.  The value of
   255 is reserved for future use as an extension field.

   Message Types are encoded such that the highest-order two bits
   specify the action that must be taken if the message receiver does
   not recognize the Message Type.

   00 Stop processing this message and discard it.

   01 Stop processing this message and discard it, and report the
      unrecognized message in an 'Unrecognized Message' error (see
      Section 3.10.3).

   10 reserved.

   11 reserved.

   Message Flags: 8 bits

   The usage of these bits depends on the message type as given by the
   Message Type.  Unless otherwise specified, they are set to zero on
   transmit and are ignored on receipt.

   Message Length: 16 bits (unsigned integer)

   This value represents the size of the message in bytes including the
   Message Type, Message Flags, Message Length, and Message Value
   fields.  Therefore, if the Message Value field is zero-length, the



Stewart, et al.         Expires January 10, 2008               [Page 19]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


   Length field will be set to 4.

   Note, the value in Message Length field will NOT cover any padding at
   the end of this message.

   Message Value: variable length

   The Message Value field contains the actual information to be
   transferred in the message.  The usage and format of this field is
   dependent on the Message Type.

   The total length of a message (including Type, Length and Value
   fields) MUST be a multiple of 4 bytes.  If the length of the message
   is not a multiple of 4 bytes, the sender MUST pad the message with
   all zero bytes and this padding is not included in the message length
   field.  The sender should never pad with more than 3 bytes.  The
   receiver MUST ignore the padding bytes.


































Stewart, et al.         Expires January 10, 2008               [Page 20]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


5.  IANA Considerations

   [NOTE to RFC-Editor:

      "RFCXXXX" is to be replaced by the RFC number you assign this
      document.

   ]

   This document (RFCXXX) is the reference for all registrations
   described in this section.  All registrations need to be listed on an
   RSerPool specific page.

5.1.  A New Table for RSerPool Parameter Types

   RSerPool Parameter Types have to be maintained by IANA.  Thirteen
   initial values should be assigned by IANA as described in Figure 2.
   This requires a new table "RSerPool Parameter Types":

   Type       Message Name                     Reference
   -----      -------------------------        ---------
   0x0        (reserved by IETF)               RFCXXXX
   0x1        IPv4 Address                     RFCXXXX
   0x2        IPv6 Address                     RFCXXXX
   0x3        SCTP Transport                   RFCXXXX
   0x4        TCP Transport                    RFCXXXX
   0x5        UDP Transport                    RFCXXXX
   0x6        Pool Member Selection Policy     RFCXXXX
   0x7        Pool Handle                      RFCXXXX
   0x8        Pool Element                     RFCXXXX
   0x9        Server Information               RFCXXXX
   0xa        Operation Error                  RFCXXXX
   0xb        Cookie                           RFCXXXX
   0xc        PE Identifier                    RFCXXXX
   0xd        PE Checksum                      RFCXXXX
   others     (reserved by IETF)               RFCXXXX

   For registering at IANA an RSerPool Parameter Type in this table a
   request has to be made to assign such a number.  This number must be
   unique.  The "Specification Required" policy of RFC2434 [3] MUST be
   applied.

5.2.  A New Table for RSerPool Error Causes

   RSerPool Error Causes have to be maintained by IANA.  Eleven initial
   values should be assigned by IANA as described in Figure 16.  This
   requires a new table "RSerPool Error Causes":




Stewart, et al.         Expires January 10, 2008               [Page 21]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


   Cause       Cause Name                                  Reference
   -----       -------------------------                   ---------
    0          Unspecified Error                           RFCXXXX
    1          Unrecognized Parameter                      RFCXXXX
    2          Unrecognized Message                        RFCXXXX
    3          Invalid Values                              RFCXXXX
    4          Non-unique PE Identifier                    RFCXXXX
    5          Inconsistent Pooling Policy                 RFCXXXX
    6          Lack of Resources                           RFCXXXX
    7          Inconsistent Transport Type                 RFCXXXX
    8          Inconsistent Data/Control Configuration     RFCXXXX
    9          Unknown Poor Handle                         RFCXXXX
   10          Rejected due to security considerations     RFCXXXX
   others      (reserved by IETF)                          RFCXXXX

   For registering at IANA an RSerPool Error Cause in this table a
   request has to be made to assign such a number.  This number must be
   unique.  The "Specification Required" policy of RFC2434 [3] MUST be
   applied.
































Stewart, et al.         Expires January 10, 2008               [Page 22]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


6.  Security Considerations

   This document contains common parameter formats only.  As such it
   specifies no new security constraints on either ENRP or ASAP.
   Details on ENRP and ASAP security constraints are addressed in ENRP
   [5] and ASAP [4] .













































Stewart, et al.         Expires January 10, 2008               [Page 23]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


7.  Normative References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [4]  Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
        Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12
        (work in progress), July 2005.

   [5]  Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
        Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)",
        draft-ietf-rserpool-enrp-12 (work in progress), July 2005.

   [6]  Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies",
        draft-ietf-rserpool-policies-04 (work in progress), March 2007.






























Stewart, et al.         Expires January 10, 2008               [Page 24]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


Authors' Addresses

   Randall R. Stewart
   Cisco Systems, Inc.
   4875 Forest Drive
   Suite 200
   Columbia, SC  29206
   USA

   Phone:
   Email: rrs@cisco.com


   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, #2309
   Arlington Heights, IL  60004
   USA

   Phone:
   Email: qxie1@email.mot.com


   Maureen Stillman
   Nokia
   127 W. State Street
   Ithaca, NY  14850
   USA

   Phone:
   Email: maureen.stillman@nokia.com


   Michael Tuexen
   Muenster Univ. of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt
   Germany

   Email: tuexen@fh-muenster.de











Stewart, et al.         Expires January 10, 2008               [Page 25]


Internet-Draft        ASAP & ENRP Common Parameters            July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Stewart, et al.         Expires January 10, 2008               [Page 26]