doc: Add RFC documents

1 files changed, 2523 insertions, 0 deletions

diff --git a/doc/rfc/rfc3423.txt b/doc/rfc/rfc3423.txt
new file mode 100644
index 0000000..21ca11b
--- /dev/null
+++ b/doc/rfc/rfc3423.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Network Working Group                                           K. Zhang
+Request for Comments: 3423                                      E. Elkin
+Category: Informational                               XACCT Technologies
+                                                           November 2002
+
+
+     XACCT's Common Reliable Accounting for Network Element (CRANE)
+                   Protocol Specification Version 1.0
+
+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 (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines the Common Reliable Accounting for Network
+   Element (CRANE) protocol that enables efficient and reliable delivery
+   of any data, mainly accounting data from Network Elements to any
+   systems, such as mediation systems and Business Support Systems
+   (BSS)/ Operations Support Systems (OSS).  The protocol is developed
+   to address the critical needs for exporting high volume of accounting
+   data from NE's with efficient use of network, storage, and processing
+   resources.
+
+   This document specifies the architecture of the protocol and the
+   message format, which MUST be supported by all CRANE protocol
+   implementations.
+
+Table of Contents
+
+   1  Introduction...................................................2
+      1.1  Specification of Requirements.............................3
+      1.2  Terminology...............................................3
+   2  Protocol Overview..............................................5
+      2.1  CRANE Architecture........................................6
+      2.2  CRANE over TCP............................................7
+      2.3  Alternate servers.........................................7
+      2.4  Templates.................................................9
+      2.5  Template Transmission and Negotiation....................10
+      2.6  Changing Templates.......................................11
+      2.7  Flow Control.............................................12
+      2.8  The CRANE Client Query Messages..........................13
+
+
+
+Zhang & Elkin                Informational                      [Page 1]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+      2.9  CRANE Sessions...........................................13
+   3  CRANE Message Format..........................................14
+   4  CRANE Messages................................................16
+      4.1  Flow Start (START).......................................16
+      4.2  Flow Start Acknowledge (START ACK).......................16
+      4.3  Flow Stop (STOP).........................................17
+      4.4  Flow Stop Acknowledge (STOP ACK).........................17
+      4.5  Connect (CONNECT)........................................18
+      4.6  Template Data (TMPL DATA)................................18
+      4.7  Template Data Acknowledge (TMPL DATA ACK)................23
+      4.8  Final Template Data (FINAL TMPL DATA)....................25
+      4.9  Final Template Data Acknowledge (FINAL TMPL DATA ACK)....26
+      4.10  Get Sessions (GET SESS).................................26
+      4.11  Get Sessions Response (GET SESS RSP)....................27
+      4.12  Get Templates (GET TMPL)................................30
+      4.13  Get Templates Response(GET TMPL RSP)....................30
+      4.14  Start Negotiation (START NEGOTIATE).....................33
+      4.15  Start Negotiation Acknowledge (START NEGOTIATE ACK).....34
+      4.16  Data (DATA).............................................34
+      4.17  Data Acknowledge (DATA ACK).............................36
+      4.18  Error (ERROR)...........................................37
+      4.19  Status Request (STATUS REQ).............................38
+      4.20  Status Response (STATUS RSP)............................38
+   5  Protocol Version Negotiation..................................39
+   6  Security Considerations.......................................42
+   7  References....................................................43
+   8  Acknowledgments...............................................43
+   9  Authors' Addresses............................................44
+   10 Full Copyright Statement......................................45
+
+1  Introduction
+
+   Network Elements are often required to export usage information to
+   mediation and business support systems (BSS) to facilitate
+   accounting.  Though there are several existing mechanisms for usage
+   information export, they are becoming inadequate to support the
+   evolving business requirements from service providers.
+
+   For example, some of the export mechanisms are legacies of the Telco
+   world.  Typically usage information is stored in Network Elements as
+   Log files (e.g., CDR files), and exported to external systems in
+   batches.  These are reliable methods, however, they do not meet the
+   real-time and high-performance requirements of today's rapidly
+   evolving data networks.
+
+   RADIUS [1] is a widely deployed protocol that may be used for
+   exporting usage information.  However, it can only handle a few
+   outstanding requests and is not extensible due to its limited command
+
+
+
+Zhang & Elkin                Informational                      [Page 2]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   and attribute address space.  RADIUS also does not support
+   unsolicited messages from a server to a client.  A detailed analysis
+   of limitations of RADIUS can be found in [3].
+
+   DIAMETER [2] is a new AAA protocol that retains the basic RADIUS
+   model, and eliminates several drawbacks in RADIUS.  The current
+   DIAMETER protocol and its extensions focus on Internet and wireless
+   network access, and their support to accounting is closely associated
+   with authentication/authorization events.  DIAMETER is intended to
+   solve many problems in the AAA area; by doing so, it does not
+   adequately address some critical issues such as efficiency and
+   performance in an accounting protocol.
+
+   There are also SNMP based mechanisms that generally require a large
+   amount of processing and bandwidth resources.
+
+   Based on the above analysis, a critical need for a reliable, fast,
+   efficient and flexible accounting protocol exists.  The XACCT's CRANE
+   protocol is designed to address these critical requirements.
+
+   This document defines the CRANE protocol that enables efficient and
+   reliable delivery of any data, mainly accounting data from Network
+   Elements to any systems, such as mediation systems and BSS/OSS.  The
+   protocol is developed to address the critical needs for exporting
+   high volume of accounting data from NE's with efficient use of
+   network, storage, and processing resources.
+
+   This document specifies the architecture of the protocol and the
+   message format, which MUST be supported by all CRANE protocol
+   implementations.
+
+1.1 Specification of Requirements
+
+   In this document, the keywords "MUST", "MUST NOT", "SHOULD", "SHOULD
+   NOT", and "MAY" are to be interpreted as described in BCP 14 [5].
+   These keywords are not case sensitive in this document.
+
+1.2 Terminology
+
+   CRANE Protocol
+
+      CRANE stands for Common Reliable Accounting for Network Element.
+      The CRANE Protocol maybe referred as CRANE, or the Protocol in
+      this document.  The CRANE Protocol is used at the interface(s)
+      between a CRANE client and one or multiple CRANE servers for the
+      purpose of delivering accounting data.
+
+
+
+
+
+Zhang & Elkin                Informational                      [Page 3]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Client or CRANE Client
+
+      A CRANE Client is an implementation on the data producing side of
+      the CRANE protocol.  It is typically integrated with the network
+      element's software, enabling it to collect and send out accounting
+      data to a mediation/billing system using the protocol defined
+      herein.
+
+   Server or CRANE Server
+
+      A CRANE Server is an implementation on the data receiving side of
+      the CRANE protocol.  It is typically part of a Business Support
+      System (BSS) (e.g., Billing, Market Analysis, Fraud detection,
+      etc.), or a mediation system.  There could be more than one CRANE
+      server connected to one CRANE client to improve robustness of the
+      usage information export system.
+
+   CRANE Session
+
+      A CRANE Session is a logical connection between a CRANE client and
+      one or multiple CRANE servers for the purpose of delivering
+      accounting data.  Multiple sessions MAY be maintained concurrently
+      in a CRANE client or a CRANE server; they are distinguished by
+      Session IDs.
+
+   Server Priority
+
+      A CRANE server is assigned with a Priority value.  Accounting data
+      is always delivered to the perceived operating CRANE server (from
+      the CRANE client point of view) with the highest Priority value
+      (the primary server) within a CRANE Session.
+
+   Message
+
+      A Message is encoded according to rules specified by the CRANE
+      protocol and transmitted across the interface between a CRANE
+      client and a CRANE server.  It contains a common CRANE header and
+      optionally control or user data payload.
+
+   Data Record
+
+      A Data Record is a collection of information gathered by the
+      Network Element for various purposes, e.g., accounting.  The
+      structure of a Data Record is defined by a Template.
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                      [Page 4]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Template
+
+      A Template defines the structure of any types of Data Record, and
+      specifies the data type, meaning, and location of the fields in
+      the record.
+
+   Data Sequence Number (DSN)
+
+      An accounting Data Record level sequence number, which is attached
+      to all data messages to facilitate reliable and in-sequence
+      delivery.
+
+2  Protocol Overview
+
+   The CRANE protocol is designed to deliver accounting data reliably,
+   efficiently, and quickly.  Due to the nature of accounting data,
+   large records often need to be transmitted; thus supporting
+   fragmentation of large records is required.  Furthermore, the value
+   associated with accounting data is high; to prevent data loss, quick
+   detection of unresponsive CRANE servers is also required for added
+   robustness.
+
+   The CRANE protocol can be viewed as an application that uses the data
+   transport service provided by lower layer protocols.  It relies on a
+   transport layer protocol to deliver reliable, in-sequence data
+   packets.
+
+   UDP is a simple connectionless transport layer protocol that has
+   advantages of being fast and agile, but it provides no reliability
+   and lacks flow control mechanisms.  Hence, The CRANE protocol must
+   not use UDP as the transport layer protocol to avoid the risk of
+   adversely impacting the networks it is being run over.
+
+   TCP and SCTP [4] are two transport layer protocols that fulfill the
+   reliability requirement of CRANE.  Either one of them MAY be used to
+   transport CRANE messages.  TCP meets some of the requirements, but
+   not all (e.g., quick detection of server failure, the fact that TCP
+   is stream oriented and not record oriented).  Therefore, SCTP [4] is
+   the preferred way to transmit CRANE messages.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                      [Page 5]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+2.1 CRANE Architecture
+
+   The CRANE protocol is an application running over a reliable
+   transport layer protocol.  The transport layer protocol is
+   responsible for delivering CRANE messages between CRANE clients and
+   CRANE servers.  It MUST support the following capabilities:
+
+   1. Reliable, in-sequence message delivery.
+   2. Connection oriented.
+   3. Delivery of messages with a length of up to 2^32 octets (i.e., the
+      transport layer has to support fragmentation of messages when
+      running over IP).
+
+   The transport layer MAY support:
+
+   1. Authentication.
+   2. Bundling of multiple messages into a single datagram.
+
+   Possible transport layer protocols MAY be TCP or SCTP [4].  TCP
+   supports the minimal requirements for CRANE, but lacks some desirable
+   capabilities that are available in SCTP, these include:
+
+   1. Session level authentication.
+   2. Message based data delivery (as opposed to stream based).
+   3. Fast connection failure detection.
+
+   Reliable delivery of accounting data is achieved through both the
+   transport layer level and the CRANE protocol level.  The transport
+   layer acknowledgments are used to ensure quick detection of lost data
+   packets and unresponsive servers, while the CRANE protocol
+   acknowledges CRANE messages after they have been processed and the
+   accounting information has been placed in persistent storage.
+
+   Being a reliable protocol for delivering accounting data, traffic
+   flowing from a CRANE client to a CRANE server is mostly accounting
+   data.  There are also bi-directional control message exchanges,
+   though they only comprise of small portion of the traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                      [Page 6]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   The following diagram illustrates the CRANE protocol architecture:
+
+       +----------------+             +----------------+
+       |    CRANE       |             |     CRANE      |+
+       |    User        |             |     User       ||+
+       +----------------+             +----------------+||
+       |    CRANE       | ==========> |     CRANE      |+|
+       |    Client      | <---------- |     Server     ||+
+       +----------------+             +----------------+||
+       |  Transport     |             |   Transport    |+|
+       |    Layer       | <---------> |     Layer      ||+
+       +----------------+             +----------------+||
+       |    Lower       |             |     Lower      |+|
+       |    Layers      | <---------> |     Layers     ||+
+       +----------------+             +----------------+||
+                                       +----------------+|
+                                        +----------------+
+
+2.2 CRANE over TCP
+
+   TCP can be used as a transport layer for the CRANE protocol.  CRANE
+   running over TCP MUST conform to the following rules:
+
+   1. The CRANE client MUST accept TCP connections over a specific TCP
+      port.
+   2. The CRANE server MUST connect to the CRANE client, and SHOULD be
+      responsible for reestablishing a connection in case of a failure.
+   3. CRANE messages are written as a stream of bytes into a TCP
+      connection, the size of a CRANE message is specified by the
+      Message Length field in the CRANE message header.
+
+2.3 Alternate servers
+
+   For purposes of improved reliability and robustness, redundant CRANE
+   server configuration MAY be employed.  The CRANE protocol supports
+   delivering accounting data to alternate CRANE servers, which may be
+   part of a mediation system or a BSS.
+
+   A CRANE session may comprise of one or more CRANE servers.  The CRANE
+   client is responsible for configuring network addresses of all CRANE
+   servers belonging to the session.  A Server Priority is assigned to
+   each CRANE server.  The Server Priority reflects the CRANE client's
+   preference regarding which CRANE server should receive accounting
+   data.  The assignment of the Server Priority should consider factors
+   such as geographical distance, communication cost, and CRANE server
+   loading, etc.  It is also possible for several CRANE servers to have
+   the same priority.  In this case, the CRANE client could randomly
+   choose one of them as the primary server to deliver accounting data.
+
+
+
+Zhang & Elkin                Informational                      [Page 7]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Additional features such as load balancing may be implemented in a
+   multi-server environment.  The process of configuring CRANE client is
+   carried out using the NE's configuration system and is outside the
+   scope of this document.
+
+   A CRANE client MUST deliver accounting data to its perceived
+   operating CRANE server with the highest priority; if this CRANE
+   server is deemed unreachable, the CRANE client MUST deliver the
+   accounting data to the next highest priority CRANE server that is
+   perceived to be operating.  If no perceived operating CRANE servers
+   are available, accounting data MUST be queued in the CRANE client
+   until any CRANE server is available or the client's queue space runs
+   out.  An alarm should be generated to inform the CRANE user of the
+   queue overflow condition.
+
+   Accounting data delivery SHOULD revert to the higher priority server
+   when it is perceived to be operating again.
+
+   The CRANE protocol does not specify how a CRANE client should
+   redirect accounting data to other CRANE servers, which is considered
+   an implementation issue.  But all the supporting mechanisms are
+   provided by the protocol to work in a multiple-server environment
+   (e.g., the template negotiation process, and configuration
+   procedures, etc.).  The transport layer (together with some other
+   means) is responsible for monitoring server's responsiveness and
+   notifying CRANE protocol for any failures.  The client may choose to
+   transition to an alternate server.
+
+   Implementation Note:
+
+      The transition to an alternate CRANE server is an implementation
+      issue and should occur under the following conditions:
+
+      A) Transport layer notifies the CRANE client that the
+      corresponding port of the CRANE server is unresponsive.
+
+      B) Total size of unacknowledged accounting records has exceeded a
+      threshold (configurable) for certain duration (configurable).
+
+      C) A STOP message is received from the active server.
+
+      D) A lower priority server is the active one and a higher priority
+      server has recovered.
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                      [Page 8]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+2.4 Templates
+
+   The CRANE protocol enables efficient delivery of accounting data.
+   This is achieved by negotiating a set of Data Templates for a CRANE
+   session before actual accounting data is delivered.   A data template
+   defines the structure of a DATA message payload by describing the
+   data type, meaning, and location of the fields in the payload.  By
+   agreeing on session templates, CRANE servers understand how to
+   process DATA messages received from a CRANE client.  As a result, a
+   CRANE client only needs to deliver actual accounting data without
+   attaching any descriptors of the data; this reduces the amount of
+   bytes sent over communication links.
+
+   A template is an ordered list of keys.  A key is the specification of
+   a field in the template.  It specifies an accounting item that a
+   network element MAY collect and export.  The specification MUST
+   consist of the description and the data type of the accounting item.
+   (e.g., 'Number of Sent Bytes'  can be a key that is an unsigned
+   integer of 32 bit long).  A CRANE client typically defines keys.
+
+   The CRANE protocol supports usage of several templates concurrently
+   (for different accounting records).  Keys contained in a template
+   could be enabled or disabled.  An enabled key implies that the
+   outgoing data record will contain the data item specified by the key.
+   A disabled key implies that the outgoing record will omit the
+   specified data item.  The enabling/disabling mechanism further
+   reduces bandwidth requirement; it could also reduce processing in
+   network elements, as only needed data items are produced.
+
+   In a CRANE session, all the CRANE servers and the CRANE client MUST
+   use the same set of templates and associated enable/disable status.
+   The templates' configuration and connectivity to an end application
+   MUST be the same in all servers.  The CRANE client MUST publish the
+   relevant templates to all CRANE servers in a session through user
+   configuration, before it starts to send data according to the
+   templates.
+
+   The complete set of templates residing in a CRANE client MUST bear a
+   configuration ID that identifies the template set.  Each data record
+   is delivered with the Template ID and the Configuration ID, so that
+   the correct template can be referenced.  A server, when receiving a
+   record with an older Configuration ID, MAY handle the record
+   gracefully by keeping some template history.  The transport layer
+   should ensure that a server would not get messages with future
+   configuration IDs.
+
+
+
+
+
+
+Zhang & Elkin                Informational                      [Page 9]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+2.5 Template Transmission and Negotiation
+
+   As stated before, all CRANE servers MUST use the same set of
+   templates in a CRANE session.  In case that servers do not share the
+   same set of templates (the templates are considered different if
+   different keys are enabled or disabled), a negotiation process
+   between the client and the server would ultimately determine one set
+   of templates that is accepted and used by all the CRANE servers in a
+   session.
+
+   After a CRANE session is established and the server sent a START
+   message indicating that it is ready to take part in the session, the
+   client MUST deliver the set of templates that it intends to use by
+   sending a TMPL DATA message to the server.  The CRANE server MUST
+   acknowledge the reception of the set of templates.
+
+   Templates are negotiable between a CRANE client and CRANE servers.  A
+   CRANE server may propose changes to the templates received from a
+   CRANE client (e.g., enabling some keys and disabling others), or it
+   can acknowledge the templates as is.  In the case that a template or
+   a key is not recognized by the server (e.g., they might be added to
+   the client after the server configuration has completed), the server
+   MAY choose to disable each unknown key or unknown templates in order
+   to avoid unnecessary traffic.  A template is disabled when all the
+   keys are disabled.  If changes were received from the CRANE servers,
+   the client will send the changed template set to all connected
+   servers (using FINAL_TMPL_DATA message).  It is the client's
+   responsibility to decide what would be the final set of templates
+   used by a session.  At this time, each CRANE server MUST accept and
+   acknowledge the templates without changing anything (to avoid
+   deadlock and loop conditions).  Each CRANE server is given a single
+   chance to propose any changes during the negotiation process.
+
+   The template negotiation process is outlined as follows:
+
+   A) CRANE client sends a TMPL DATA message with a set of templates.
+
+   B) CRANE server either responds with the TMPL DATA ACK message with
+   changes in the template set (process continues in step C) or responds
+   with FINAL TMPL DATA ACK message if no changes are needed (process
+   continues in step E).
+
+   C) CRANE client receives proposed changes, incorporates them if
+   possible and then sends a FINAL TMPL DATA message containing the new
+   set of templates to all servers (in order to deploy the change).
+
+   D) CRANE server receives the FINAL TMPL DATA message containing the
+   new set of templates and MUST send a FINAL TMPL DATA ACK message to
+
+
+
+Zhang & Elkin                Informational                     [Page 10]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   acknowledge the reception of the templates.  No changes are allowed
+   at this stage and the templates, which the client sent, are going to
+   be used.
+
+   E) CRANE client receives a FINAL TMPL DATA ACK message from the
+   server and can assume that the server knows which templates to use.
+
+   All these stages take place only when there are multiple CRANE
+   servers with differences in the template set (e.g., not all key
+   states are identical).  If all CRANE servers within a session share
+   the same configuration exactly, all servers will respond with FINAL
+   TMPL DATA ACK and the ping-pong between the client and the servers
+   will end immediately.  This is the common case, but in case some
+   other CRANE servers have a different configuration, the protocol
+   offers the way to maintain consistency among CRANE servers.
+
+   Implementation Note:
+
+      TMPL DATA messages SHOULD be sent only after all DATA messages
+      with the previous configuration have been acknowledged.  This
+      ensures the server to transition properly to the new
+      configuration.
+
+2.6 Changing Templates
+
+   Though TMPL DATA messages allow for deploying and publicizing
+   template, a need to configure the template set still exists.  Each of
+   the CRANE servers in a CRANE session may change the template set,
+   which is typically requested by an end-user through User Interface.
+   If the end-users need to know what templates are available and the
+   current template set status, they may issue the GET TMPL message.
+
+   The following steps are performed in order to change the templates:
+
+   A) The server MUST retrieve from CRANE client the template set that
+   requires change by issuing GET TMPL message.  The server can issue a
+   GET TMPL even if it has not yet issued a START message.
+
+   B) After received a GET TMPL message, the client sends back a GET
+   TMPL RSP message with the requested data.
+
+   C) The server makes the necessary changes to the templates and sends
+   back a START NEGOTIATION message.  This message triggers the CRANE
+   client to inquire about changes made by the CRANE server.
+
+   D) After received a START NEGOTIATE message, the client MUST respond
+   with START NEGOTIATE ACK message followed by a TMPL DATA message.
+   From this point on, the template negotiation process starts.
+
+
+
+Zhang & Elkin                Informational                     [Page 11]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+2.7 Flow Control
+
+   After templates have been deployed, DATA messages start to arrive at
+   the primary CRANE server (the operational one with the highest
+   priority within the CRANE session).  Each DATA message contains a
+   Data Sequence Number (DSN).  The primary CRANE server MUST accept the
+   data as long as it is in-sequence.  Out-of-sequence DATA messages
+   should be discarded.
+
+   The CRANE server detects the start of accounting data when it
+   receives the first DATA message either after startup or after a
+   server transition.  The first DATA message MUST have the 'S' bit
+   ('DSN Synchronize' bit) set by the CRANE client.  Upon reception of
+   the message with initial DSN, the server MUST accept all in-sequence
+   DATA messages.  The DSN MUST be incremented by 1 for each new DATA
+   message originated from the client.
+
+   A CRANE server MUST acknowledge the reception and correct processing
+   of DATA messages by sending DATA ACK messages.  The DATA ACK MUST
+   contain the DSN of the last processed in-sequence DATA message.  If
+   the CRANE server receives an Out Of Sequence DATA message, it MUST
+   also send a DATA ACK message.  It will trigger an immediate
+   retransmission of unacknowledged records.
+
+   The CRANE client is responsible for delivering all the records.  In
+   the case of a redundant server configuration, there could be a
+   scenario when one server does not receive all the records but another
+   redundant CRANE server for the same mediation system receives the
+   rest of the records.  For example, server #1 could receive records
+   3042-3095 and then 3123-..., with server #2 receiving records 3096-
+   3122.  It is the sender's responsibility to deliver all the records,
+   in-sequence, but not necessarily to the same server.
+
+   The billing/mediation system eventually receives all the records,
+   possibly through more than one CRANE server.  The CRANE client MUST
+   convey all the records it received to the billing/mediation system.
+    This MAY result in duplicate records in the billing/mediation
+   system.  In this case, the DSN MUST be used to remove duplicates.  To
+   aid the process of duplicate removal, whenever a record is re-sent to
+   another server, its 'Duplicate' bit MUST be set to suggest that this
+   record might be a duplicate.
+
+   Implementation Note:
+
+      When the amount of unacknowledged records reaches a threshold, a
+      timer should be started.  When the timer expires, all the
+      unacknowledged records should be transmitted to an alternate
+
+
+
+
+Zhang & Elkin                Informational                     [Page 12]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+      server with 'D' bit set in the DATA message; if alternate servers
+      are not available, the records should be retransmitted.
+
+      The CRANE flow control also supports redundant server
+      configuration.  A server MUST send a START message in order to
+      move to the 'ready' state.  In the 'ready' state, the server can
+      receive and process CRANE messages.  To leave the 'ready' state
+      and stop the message flows from the client, the server should send
+      a STOP message to the client.
+
+2.8 The CRANE Client Query Messages
+
+   A CRANE server may query a CRANE client's status by sending query
+   messages after it has established a session with the client.  A CRANE
+   client that is connected to the server MUST respond with response
+   messages.  All the Query Messages MUST be initiated by a CRANE
+   server.  The CRANE protocol defines three such Query Message pairs,
+   they are:
+
+   Get Session (GET SESS)
+   Get Session Response (GET SESS RSP)
+
+   Get Template (GET TMPL)
+   Get Template Response (GET TMPL RSP)
+
+   Status Request (STATUS REQ)
+   Status Response (STATUS RSP)
+
+   All the query messages incorporate a Request ID field for tagging
+   purposes and matching requests and responses.  This field contains a
+   16 bit counter incremented with every request and is set by the
+   initiator of the request.  Along with the CRANE server's IP address
+   and port number, this constitutes a unique identifier for a request.
+   This value MUST be copied to Request ID field in the response message
+   in order to associate a specific response with a request.
+
+   The CRANE client SHOULD collect and send out meta-data about the data
+   collected (counters, statistics, etc.).  This is done by creating
+   status templates, which are treated like any other template, with the
+   exception that these templates are marked with a /'Status' bit.
+   Status templates are used with the set of STATUS REQ and STATUS RSP
+   messages.  A server MAY issue a STATUS REQ to a CRANE client and
+   receive a STATUS RSP message with the requested data.
+
+2.9 CRANE Sessions
+
+   A CRANE client MAY deliver accounting data to different
+   mediation/billing systems by establishing different CRANE sessions.
+
+
+
+Zhang & Elkin                Informational                     [Page 13]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Each session MAY consist of several CRANE servers in a redundant
+   configuration.  The session ID imbedded in all the CRANE messages
+   enables the correct association of CRANE sessions with CRANE users.
+   All the CRANE processes (e.g., template negotiation, configuration,
+   flow control, etc.) should be carried out in the same way in a multi
+   session scenario.
+
+   Each session has its set of templates (these may be the same
+   templates, but the keys could be enabled or disabled differently).
+    The sessions are configured in the NE, each with a different session
+   name with associated Session IDs.  The session ID is carried in each
+   message to associate the message with a specific session.
+
+   A CRANE server MAY take part in different sessions.  When configuring
+   a server, it needs to know the sessions in which it participates.
+   The server can issue a GET SESS message to receive a list of relevant
+   sessions.
+
+3  CRANE Message Format
+
+   A summary of the CRANE protocol message format is shown below.  A
+   CRANE message consists of an 8 octet message header; it is followed
+   by a variable length message payload that is aligned to 32 bit
+   boundary.  Some of the messages do not have the CRANE Message Payload
+   part.  The fields are in network byte order and transmitted from left
+   to right.
+
+       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      |Message ID(MID)|  Session ID   | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                    CRANE Message Payload                      ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Version: 8 bit unsigned integer
+
+      The Version field indicates the supported CRANE protocol
+      implementation.  This field MUST be set to 1 to indicate the CRANE
+      protocol Version 1.0.  CRANE protocol Version 1.0 only supports
+      Ipv4 addressing; however, it can be used to transfer information
+      related to Ipv6 flows.
+
+
+
+
+Zhang & Elkin                Informational                     [Page 14]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message ID (MID): 8 bit unsigned integer
+
+      The Message ID field identifies the type of the message.  The
+      message IDs defined by CRANE Version 1 are:
+
+      Message Name               Short Name         Message ID
+      ---------------------      ---------------    ------------
+      Reserved                                         0x00
+
+      Flow Start                  START                0x01
+      Flow Start Acknowledge      START ACK            0x02
+      Flow Stop                   STOP                 0x03
+      Flow Stop Acknowledge       STOP ACK             0x04
+      Connect                     CONNECT              0x05
+
+      Template Data               TMPL DATA            0x10
+      Template Data Acknowledge   TMPL DATA ACK        0x11
+      Final Template Data         FINAL TMPL DATA      0x12
+      Final Template Data Ack.    FINAL TMPL DATA ACK  0x13
+      Get Sessions                GET SESS             0x14
+      Get Sessions Response       GET SESS RSP         0x15
+      Get Template                GET TMPL             0x16
+      Get Template Response       GET TMPL RSP         0x17
+      Start Negotiation           START NEGOTIATE      0x18
+      Start Negotiation Ack.      START NEGOTIATE ACK  0x19
+
+      Data                        DATA                 0x20
+      Data Acknowledge            DATA ACK             0x21
+      Error                       ERROR                0x23
+
+      Status Request              STATUS REQ           0x30
+      Status Response             STATUS RSP           0x31
+
+   Session ID: 8 bit unsigned char
+
+      The Session ID field identifies the session with which the message
+      is associated.  The session ID is ignored in the case of GET SESS
+      and GET SESS RSP messages.  More details about session can be
+      found in Section 2.9.
+
+   Message Flags: 8 bit unsigned char
+
+      The Message Flags field can be used to identify options associated
+      with the message.  For CRANE Version 1.0, all the flags are
+      reserved; unless otherwise specified, the flags are set to zero on
+      transmit and are ignored on receipt.
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 15]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message Length: 32 bit unsigned integer
+
+      The Message Length field is the total length of the CRANE message
+      in octet including the header.
+
+4  CRANE Messages
+
+   This section defines CRANE mandatory messages.  They MUST be
+   supported by any CRANE protocol implementation.
+
+4.1 Flow Start (START)
+
+   Description
+
+      The Flow Start message is sent from a CRANE server to a CRANE
+      client to indicate that the CRANE server is ready to receive CRANE
+      messages.
+
+     Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x01     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.2 Flow Start Acknowledge (START ACK)
+
+   Description
+
+      The Flow Start Acknowledge message is sent by a CRANE client to
+      acknowledge the reception of a START message from a specific CRANE
+      server.  It is sent only to that server to indicate that the
+      client considers it ready to receive CRANE messages.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x02     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Client Boot Time                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Zhang & Elkin                Informational                     [Page 16]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Client Boot Time: 32 bit unsigned integer
+
+      The Client Boot Time field is the timestamp of the last client
+      startup in seconds from 1970.  This field can be combined with the
+      DSN and the client's IP address to serve as a system wide unique
+      record identifier.
+
+4.3 Flow Stop (STOP)
+
+   Description
+
+      The Flow Stop message is sent from a CRANE server to a CRANE
+      client to instruct it to stop sending data (to that server).  The
+      STOP message does not disconnect the server; it only stops the
+      CRANE client from sending "DATA" messages.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x03     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.4 Flow Stop Acknowledge (STOP ACK)
+
+   Description
+
+      The Flow Stop Acknowledgement message acknowledges the STOP
+      message issued by a CRANE server.
+
+   Message 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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Version      |  MID=0x04     | Session ID    | Message Flags |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                         Message Length                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 17]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+4.5 Connect (CONNECT)
+
+   Description
+
+      The CONNECT message is sent from a CRANE server to a CRANE client
+      to identify itself.  The message MUST be the first message sent
+      over a transport layer connection between the server and the
+      client.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x05     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Server Address                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Server Port          |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Server Address: 32 bit unsigned integer
+
+      The Server Address field is the server's IP address (IPV4).
+
+   Server Port: 16 bit unsigned integer
+
+      The Server Port field is the server's port number for the
+      transport layer (the port number specified here doesn't
+      necessarily have to match the port number used by the transport
+      layer)
+
+4.6 Template Data (TMPL DATA)
+
+   Description
+
+      A CRANE client sends the Template Data message to a CRANE server
+      after a START or a START NEGOTIATE message was received from the
+      server.  The message MUST contain all the templates that are going
+      to be used for the session.  It SHOULD also include the template
+      for the status records (See section 2.8)
+
+      The receiving CRANE server MUST acknowledge the message by sending
+      either a TMPL DATA ACK (if template changes are needed) or a FINAL
+      TMPL DATA ACK message.  For more information, see section 2.5.
+
+
+
+
+Zhang & Elkin                Informational                     [Page 18]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x10     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Config ID   |  Flags      |E|       Number of Templates     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       Template Block                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       ...       ...                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       Template Block                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Configuration ID (Config. ID): 8 bit unsigned char
+
+      The Configuration ID field identifies the version number
+      associated with a template set.  Changes to any of the templates
+      would result in a new template version, and the version number
+      would be incremented by one.  An implementation SHOULD handle
+      rollovers of the version number.
+
+   Flags: 8 bit unsigned char
+
+      The Flags field identifies any options associated to the message.
+
+      The flag defined by the CRANE Version 1 is:
+
+      The 'E' bit indicates the transmission order of the "DATA"
+      messages.  If the field is set to 1, data is in big endian format;
+      otherwise, little endian format is used.
+
+   Number of Templates: 16 bit unsigned integer
+
+      The Number of Templates field is the number of Templates (a
+      template is described by a Template Block) specified by the
+      message.
+
+
+
+
+Zhang & Elkin                Informational                     [Page 19]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Template Block
+
+      The Template Block field is of variable length and aligned to 32
+      bit boundary.  It is the specification of a template.
+
+   Template Block 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Template ID            |         Number of Keys        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Template Flags         |T|      Description Length       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Template Block Length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         Description                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Key Block                            ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       ...       ...                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Key Block                            ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Template ID: 16 bit unsigned integer
+
+      The Template ID field identifies a specific template.
+
+   Number of Keys: 16 bit unsigned integer
+
+      The Number of Keys field is the number of keys included in the
+      template.
+
+   Template Flags: 16 bit unsigned integer
+
+      The Template Flags field is composed of flags that indicate
+      different attributes of the template.  In CRANE Version 1.0, only
+      the 'T' bit is defined, other bits in the field SHOULD be set to
+      zero by the sender and ignored by the receiver.
+
+
+
+Zhang & Elkin                Informational                     [Page 20]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+      The 'T' bit ('Status' bit) indicates that the template is a status
+      template that is used by the STATUS RSP message only.  See section
+      2.8 for more details.
+
+   Description Length: 16 bit unsigned integer
+
+      The Description Length field is the length of the Description
+      field.  If no description is supplied, the length MUST be 0.
+
+   Template Block Length: 32 bit unsigned integer
+
+      The Template Block Length is the length of the template block in
+      octets.
+
+   Description: Variable length unsigned char
+
+      The Description field contains the text description of the
+      template (e.g., "Aggregated by interface and ToS bits").  It is a
+      variable length field of up to 64Kb long, and padded with 0 to the
+      next 32 bit boundary.
+
+   Key Block
+
+      A key Block contains the specification of a key within a template.
+
+   Key Block 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            Key ID                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Key Type ID          |            Reserved           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Key Attribute Vector                   |K|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Key ID: 32 bit unsigned integer
+
+      The Key ID field identifies the key within a template.  See
+      section 2.4 for more details.
+
+   Key Type ID: 16 bit unsigned integer
+
+      The Key Type ID field specifies the data type of the key.
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 21]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+           The fixed length data types are defined as following:
+
+               Data Type             Data Type ID
+           ---------------------    --------------
+            Boolean (1)                 0x0001
+            Unsigned Integer8           0x0002
+            Signed Integer8             0x0003
+            Unsigned Integer16          0x0004
+            Signed Integer16            0x0005
+            Unsigned Integer32          0x0006
+            Signed Integer32            0x0007
+            Unsigned Integer64          0x0008
+            Signed Integer64            0x0009
+
+            Float (2)                   0x000a
+            Double (2)                  0x000b
+
+            IP address (Ipv4)           0x0010
+            IP address (Ipv6)           0x0011
+            Time_SEC  (3)               0x0012
+            Time_MSEC_64(4)             0x0013
+            Time_USEC_64 (5)            0x0014
+            Time_MSEC_32 (6)            0x0015
+            Time_USEC_32 (7)            0x0016
+
+           The variable length data types are defined as following:
+
+            String (8)                  0x400c
+            Null Terminated String      0x400d
+            UTF-8 String                0x400e
+            UTF-16 String               0x400f
+            Arbitrary Data (BLOB) (9)   0x4015
+
+           (1) Boolean is represented as a single octet holding 0 for a
+           value of FALSE and 1 for a value of TRUE.
+
+           (2) Float and Double are single and double precision floating
+           point numbers that comply with the IEEE-754 standard.
+
+           (3) Time_SEC is a 32 bit value, most significant octet first
+           - seconds since 00:00:00 GMT, January 1, 1970.
+
+           (4) Time_MSEC_64 is a 64 bit value, most significant octet
+           first - milliseconds since 00:00:00 GMT, January 1, 1970.
+
+           (5) Time_USEC_64 is a 64 bit value, most significant octet
+           first - microseconds since 00:00:00 GMT, January 1, 1970.
+
+
+
+
+Zhang & Elkin                Informational                     [Page 22]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+           (6) Time_MSEC_32 is a 32 bit value, most significant octet
+           first - milliseconds since 00:00:00 GMT, January 1, 1970.
+
+           (7) Time_USEC_32 is a 32 bit value, most significant octet
+           first - microseconds since 00:00:00 GMT, January 1, 1970.
+
+           (8) String is prefixed by a 32 bit length field that
+           indicates the length of the string, and followed by ASCII
+           codes of the string characters.  This representation MUST
+           only be used for encoding data records in a "DATA" message.
+
+           (9) The arbitrary data is prefixed by a 32 bit length field
+           and followed by the data in binary format.
+
+   Key Attribute Vector: 32 bit unsigned integer
+
+      The Key Attribute Vector field indicates different attributes of
+      the key.  In CRANE Version 1, only the 'K' bit is defined, other
+      bits in the field SHOULD be set to zero by the sender and ignored
+      by the receiver.
+
+      The 'K' bit ('Disabled bit') is set to 1 when the key is disabled
+      in this template.
+
+4.7 Template Data Acknowledge (TMPL DATA ACK)
+
+   Description
+
+      The Template Data Acknowledge message is sent from a CRANE server
+      to a CRANE client after a TMPL DATA message has been received.  It
+      proposes changes of the templates and/or key status changes
+      (enable/disable) for the templates.
+
+      If a CRANE server wishes to acknowledge reception of TMPL DATA
+      without changes, it MUST respond with the FINAL TMPL DATA ACK
+      message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 23]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x11     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Config. ID |    Reserved   |   Number of Template Changes  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                    Template Change Block                      ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       ...       ...                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                    Template Change Block                      ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Configuration ID (Config. ID): 8 bit unsigned char
+
+      See Section 4.6.  The value MUST be identical to the Config.  ID
+      field of the acknowledged TMPL DATA message.
+
+   Number of Template Changes: 16 bit unsigned integer
+
+      The Number of Template Changes field is the number of changed
+      Templates (a changed template is described by a Template Change
+      Block) specified by the message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 24]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Template Change Block
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Template ID            |        Number of Keys         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Key Block                            ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       ...       ...                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Key Block                            ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Template ID: 16 bit unsigned integer
+
+      See Section 4.6.
+
+   Number of Keys: 16 bit unsigned integer
+
+      See Section 4.6.
+
+   Key Block
+
+      See Section 4.6, only relevant keys are described.
+
+4.8 Final Template Data (FINAL TMPL DATA)
+
+      Description
+
+      The Final Template Data message is sent by a CRANE client to all
+      the CRANE servers in a session, to convey the finalize templates.
+      It is similar to the TMPL DATA message, with the only difference
+      that a server must accept the templates in this message.
+
+   Message Format
+
+      Identical to the TMPL DATA (see section 4.6)
+
+   Message ID (MID)
+
+      0x12      Final Template Data
+
+
+
+Zhang & Elkin                Informational                     [Page 25]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+4.9 Final Template Data Acknowledge (FINAL TMPL DATA ACK)
+
+   Description
+
+      The CRANE server acknowledges reception of the TMPL DATA or FINAL
+      TMPL DATA by sending a Final Template Data Acknowledge message.
+      It does not carry any changes to the templates.  Unlike TMPL DATA
+      ACK messages, a FINAL TMPL DATA ACK message indicates the
+      acceptance of the templates for the session.  A server MAY respond
+      with this message to a TMPL DATA (if it does not want any changes
+      in the templates).  A server MUST respond with this message to a
+      FINAL TMPL DATA.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x13     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Config. ID  |                     Reserved                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Configuration ID: 8 bit unsigned char
+
+      See Section 4.6.  This field MUST copy the configuration ID from
+      the acknowledged message.
+
+4.10    Get Sessions (GET SESS)
+
+   Description
+
+      The Get Sessions message is sent by a CRANE server to a CRANE
+      client to query what are the sessions it should participate.  This
+      is typically done just before a UI configuration of the CRANE
+      client's templates.  As each session has its own set of templates,
+      there is a need to know the server's participation of all the
+      sessions.
+
+      The Session ID field in the CRANE message header MUST be ignored
+      by the receiver.
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 26]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x14     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Request ID          |        Reserved               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Request ID: 16 bit unsigned integer
+
+      The Request ID field identifies the specific request issued by the
+      server.  The same Request ID MUST be placed in the responding
+      message in order to associate it with the request.
+
+4.11    Get Sessions Response (GET SESS RSP)
+
+   Description
+
+      The Get Sessions Response message is sent by a CRANE client to a
+      CRANE server as a reply to a GET SESS request.  The message MUST
+      contain all the information related to any session with which the
+      requesting server is associated.
+
+      The Session ID field in the common message header MUST be ignored
+      by the receiver.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 27]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x15     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Request ID          |       Number of Sessions      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Vendor String Length       |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+      |                                                               |
+      ~                       Vendor String                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         Session Block                         ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       ...       ...                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         Session Block                         ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Request ID: 16 bit unsigned integer
+
+      See Section 4.10.
+
+   Number of Sessions: 16 bit unsigned integer
+
+      The Number of Sessions field is the number of session blocks in
+      the message.
+
+   Vendor String Length: 16 bit unsigned integer
+
+      The Vendor String Length field is the length of Vendor String
+      field in octet.  The field limits vendor strings to 64Kb long.  If
+      no such string is supplied, the length MUST be set to 0.
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 28]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Vendor String: Variable length unsigned char
+
+      The Vendor String field is a variable length field.  It identifies
+      the vendor that created the session.  It MUST be padded with 0 to
+      the next 32 bit boundary.  The information differentiates similar
+      templates from different vendors.  The actual format of the
+      information is application specific and outside the scope of this
+      document.
+
+   Session Block
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Session ID    |   Reserved    |      Session Name Length      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Session Description Length   |             Reserved          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Session Name                         ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       Session Description                     ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Session ID: 8 bit unsigned char
+
+      See Section 3.
+
+   Session Name Length: 16 bit unsigned integer
+
+      The Session Name Length field is the length of the Session Name
+      field.  The field limits the session name strings to 64 Kb long.
+      As a name is mandatory to differentiate between sessions, this
+      field MUST NOT be 0.
+
+   Session Description Length: 16 bit unsigned integer
+
+      The Session Description Length field is the length of a session
+      description.  The field limits the session description to 64Kb
+      long.  If no such Description is supplied, the length MUST be set
+      to 0.
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 29]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Session Name: Variable length unsigned char
+
+      The Session Name field is the name for a session, which MAY be
+      displayed to end-users.  It MUST be padded with 0 to the next 32
+      bit boundary.  Session Name MUST be unique within a CRANE client.
+      This field is mandatory and MUST be a part of any Session Block.
+
+   Session Description: Variable length unsigned char
+
+      The Session Description field is the text description of a
+      session; it could be displayed to end-users.  It MUST be padded
+      with 0 to the next 32 bit boundary.
+
+4.12    Get Templates (GET TMPL)
+
+   Description
+
+      The Get Templates message is sent by a CRANE server to a CRANE
+      client to query templates in a session.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x16     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Request ID          |            Reserved           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Request ID: 16 bit unsigned integer
+
+      See Section 4.10.
+
+4.13    Get Templates Response (GET TMPL RSP)
+
+   Description
+
+      The Get Templates Response message is sent by a CRANE client to a
+      CRANE server as a response to a GET TMPL message.  The message
+      SHOULD contain all templates available for the specific session.
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 30]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x17     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Request ID          |       Number of Templates     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       Template Block                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       ...       ...                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       Template Block                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Request ID: 16 bit unsigned integer
+
+      See Section 4.10.
+
+   Number of Templates: 16 bit unsigned integer
+
+      See Section 4.6.
+
+   Template Block
+
+      Same as the template block defined in the TMPL DATA message (see
+      Section 4.6).  However, Extended Key Blocks MUST be used instead
+      of Key Blocks.  Extended key Block field provides extensive
+      informational data that MAY be displayed to end-users.
+
+   Extended Key Block
+
+      The Extended Key Block field provides comprehensive information
+      about a key.
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 31]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Extended Key Block 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            Key ID                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Key Type ID          |        Key Name Length        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Key Label Length     |        Key Help Length        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                            Key Name                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                            Key Label                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                            Key Help                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Key Attribute Vector                   |K|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Key ID: 32 bit unsigned integer
+
+      Same as section 4.6.
+
+   Key Type ID: 16 bit unsigned integer
+
+      Same as section 4.6.
+
+   Key Name Length: 16 bit unsigned integer
+
+      The Key Name Length field is the length of the Key Name field.
+      The field limits Key Name strings to 64 Kb long.  As a name is
+      mandatory to a key, this field MUST NOT be 0.
+
+   Key Label Length: 16 bit unsigned integer
+
+      The Key Label Length field is the length of the Key Label field.
+      The field limits Key Label strings to 64 Kb long.  Length of 0
+      means that the Label field is to be skipped.
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 32]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Key Help Length: 16 bit unsigned integer
+
+      The Key Help Length field is the length of the Key Help field.
+      The field limits Key Help strings to 64 Kb long.  Length of 0
+      means that the Help field is to be skipped.
+
+   Key Name: Variable length unsigned char
+
+      The Key Name field is the name for the key, which could be
+      displayed to end users.  It MUST be padded with 0 to the next 32
+      bit boundary.  Key Name MUST be unique (within the template) and
+      case sensitive.  This field is mandatory and MUST be a part of any
+      Extended Key Block.
+
+   Key Label: Variable length unsigned char
+
+      The Key Label field is a descriptive label, which could be
+      displayed to end users concerning this key.  It MUST be padded
+      with 0 to the next 32 bit boundary.  This field SHOULD be a part
+      of any Extended Key Block.
+
+   Key Help: Variable length unsigned char
+
+      The Key Help field is any Help string that could be displayed to
+      end users concerning this key.  It MUST be padded with 0 to the
+      next 32 bit boundary.  This field MAY be a part of any Extended
+      Key Block.
+
+   Key Attribute Vector: 32 bit unsigned integer
+
+      Same as section 4.6.
+
+4.14    Start Negotiation (START NEGOTIATE)
+
+   Description
+
+      The Start Negotiation message is sent by a CRANE server after the
+      configuration process has completed.  The message should initiate
+      template negotiation by the client with all CRANE servers in a
+      session.  The CRANE server MAY re-send this message up to 3 times
+      with repeat interval of 5 seconds unless it is acknowledged by the
+      CRANE client.  Otherwise, the CRANE user will be informed.  The
+      client should send TMPL DATA message to the servers after
+      acknowledged the message.
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 33]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x18     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.15    Start Negotiation Acknowledge (START NEGOTIATE ACK)
+
+   Description
+
+      The Start Negotiation Acknowledge message MUST be sent by a CRANE
+      client to the server to acknowledge the reception of the START
+      NEGOTIATE message.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x19     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.16    Data (DATA)
+
+   Description
+
+      The DATA message carries actual data records from a CRANE client
+      to a CRANE server.  A data record is a structured collection of
+      fields that matches a specific template.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 34]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x20     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Template ID            |    Config. ID |  Flags    |D|S|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Data Sequence Number (DSN)                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Record Data                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Template ID: 16 bit unsigned integer
+
+      See Section 4.6.
+
+     Configuration ID: 8 bit unsigned char
+
+      See Section 4.6.  The Config. ID field can prevent out-of-the-blue
+      messages with outdated templates arriving and erroneously
+      processed.  A server MAY keep a short history of templates in
+      order to cope with this scenario.
+
+   Flags: 8 bit unsigned char
+
+      The Flags field is composed of flag bits that indicate processing
+      requirements of the data records.  The CRANE Version 1 defined two
+      flags for these purposes.  Unless otherwise specified, the other
+      flags are set to zero on transmit and are ignored on receipt.
+
+   The following flags are defined in CRANE Version 1:
+
+      The 'D' bit ('Duplicate' bit): It is set for records that are
+      re-sent to an alternate server after a server transition occurs.
+      When the same records are sent to different servers, there is a
+      possibility that duplicated data exists.  The Status of the 'D'
+      bit will help the billing/mediation system to perform
+      de-duplication if desired.
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 35]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+      The 'S' bit ('DSN Synchronize' bit): When set, it indicates that
+      the record is the first one received by the server after starting
+      (or restarting) of data transmission to this server.  The server
+      MUST set the initial DSN to the DSN specified in the record.  The
+      flag is set to zero by default.
+
+   Data Sequence Number: 32 bit unsigned integer
+
+      The Data Sequence Number field is the record sequence number used
+      for preserving data orders and detecting data losses.  The DSN
+      MUST be incremented by one for each new record transmitted.  The
+      selection of the initial DSN number is implementation specific.
+
+   Record Data: Variable Length unsigned octets
+
+      The Record Data field carries the actual accounting/billing data
+      that is structured according to the template identified by the
+      Template ID field.
+
+4.17    Data Acknowledge (DATA ACK)
+
+   Description
+
+      The Data Acknowledgement message is sent from a CRANE server to
+      acknowledge receipt of records.  It acknowledges the maximal in-
+      sequence DSN received.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x21     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Data Sequence Number                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Config. ID  |                  Reserved                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Data Sequence Number: 32 bit unsigned integer
+
+      See Section 4.16.  It MUST be DSN of the last in-sequence record
+      that was received by the server.
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 36]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Configuration ID: 8 bit unsigned char
+
+      See Section 4.16.
+
+4.18    Error (ERROR)
+
+   Description
+
+      The Error message MAY be issued by either a CRANE server or
+      client.  It indicates an error condition that was detected by the
+      sender.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x23     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Error Code            |      Description Length       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                          Description                          ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Timestamp: 32 bit unsigned integer
+
+      The Timestamp field is a timestamp in seconds since 00:00:00 GMT,
+      January 1, 1970.
+
+   Error Code: 16 bit unsigned integer
+
+      The Error Code field is a code assigned to an error condition.
+
+   The following error codes are defined in CRANE Version 1:
+
+          Error Condition                   Error Code
+         -----------                    --------------
+          Unknown                           0
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 37]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Description Length: 16 bit unsigned integer
+
+      The Description Length field is the length of the Description
+      field.  The field limits Description strings to 64 Kb long.
+      Length of 0 means that the Description field is to be skipped.
+
+   Description: Variable Length unsigned char
+
+      The Description field is a text description that allows the sender
+      to provide more detailed information about the error condition.
+      It MUST be padded with 0 to the next 32 bit boundary.
+
+4.19    Status Request (STATUS REQ)
+
+   Description
+
+      CRANE servers MAY inquire general operation status of a client by
+      sending the Status Request message.  The status information SHOULD
+      include a collection of states, counters, accumulators of the data
+      collection functions that reside with the client.  The status MAY
+      include more information about the CRANE client itself.
+
+      The status reporting mechanism relies on the status template of a
+      session.  It is determined similarly as other templates.  Without
+      a determined status template, no status information can be
+      delivered.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x30     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.20    Status Response (STATUS RSP)
+
+   Description
+
+      The Status Response message contains a status report that MUST be
+      compatible with the status template of the session.  It is
+      client's response to a STATUS REQ message from a server.
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 38]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Version      |  MID=0x31     | Session ID    | Message Flags |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Message Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Template ID            |  Reserved     |Config. ID     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Record Length                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         Record Data                           ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Template ID: 16 bit unsigned integer
+
+      See Section 4.6.
+
+   Configuration ID: 8 bit unsigned integer
+
+      See Section 4.6.  The version is needed here to prevent
+      out-of-the-blue messages with outdated templates arriving and
+      erroneously processed.  A server MAY keep a short history of
+      templates in order to cope with this scenario.
+
+   Record Length: 32 bit unsigned integer
+
+      The Record Length field is the length of the Record Data field in
+      octets.
+
+   Record Data: Variable Length unsigned octets
+
+      The Record Data field contains the status data that complies with
+      the status template.  For more details see section 2.4
+
+5  Protocol Version Negotiation
+
+   Since the CRANE protocol may evolve in the future and it may run over
+   different transport layers, a transport neutral version negotiation
+   mechanism running over UDP is defined.  A CRANE server MAY inquire a
+   CRANE client about the CRANE protocol version and transport layer
+   support by sending a UDP packet on an agreed UDP port.  The client
+   MUST respond to this request with a UDP packet carrying the protocol
+
+
+
+
+Zhang & Elkin                Informational                     [Page 39]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   version, the transport type and the port number used for the specific
+   transport.  The Protocol Version Negotiation is optional for CRANE
+   Version 1.
+
+   The CRANE server sends the following message to query the client's
+   protocol support.
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Server Address                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Server Boot Time                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     'C'       |    'R'        |    'A'        |    'N'        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Server Address:
+
+      The Server Address field is the IP address (Ipv4) of the CRANE
+      server.
+
+   Server Boot Time
+
+      The Server Boot Time field is the timestamp of the last server
+      startup in seconds from 1970.
+
+   'C', 'R', 'A', 'N':
+
+      The 'C', 'R', 'A', 'N' fields are ASCII encoded characters to
+      identify the CRANE server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 40]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   The client's reply to a version negotiation request MUST comply with
+   the following structure:
+
+   Message 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Default Protocol Info                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    Additional Protocols Count                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    Additional Protocols Info                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              ...   Additional Protocols Info  ...             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    Additional Protocols Info                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Default Protocol Info:
+
+      The Default Protocol Info field contains information of the
+      default protocol supported by the client.  The field is structured
+      as a Protocol Info Block described below.
+
+   Additional Protocols Count: 32 bit unsigned integer
+
+      The Additional Protocols Count field specifies the number of
+      additional protocols supported by the client.  In the case that
+      only the default protocol is supported, the field MUST be set to
+      0.
+
+   Additional Protocols Info:
+
+      The Additional Protocol Info field is an array of Protocol Info
+      Blocks (described below) contain information about additional
+      protocols supported by the client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 41]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   Protocol Info Block
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Transport Type                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Protocol Version                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Port Number           |            Reserved           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Transport Type: 32 bit unsigned integer
+
+      1 - TCP, 2 - SCTP
+
+   Protocol Version: 32 bit unsigned integer
+
+      Version number of the CRANE protocol supported over the specific
+      transport layer, the current version is 1.
+
+   Port Number: 16 bit unsigned integer
+
+      Port number (either SCTP or TCP port) used for the protocol
+
+6  Security Considerations
+
+   The CRANE protocol can be viewed as an application running over a
+   reliable transport layer, such as TCP and SCTP.  The CRANE protocol
+   is end-to-end in the sense that the CRANE messages are communicated
+   between clients and servers identified by the host address and the
+   transport protocol port number.  Before any CRANE sessions can be
+   initiated, a set of CRANE servers' addresses should be provisioned on
+   a CRANE client.  Similarly, a CRANE server maintains a list of CRANE
+   clients' address with which it communicates.  The provisioning is
+   typically carried out securely using a network management system; in
+   this way, the CRANE end-points can be authenticated and authorized.
+   As this scheme is static, without additional security protections the
+   CRANE protocol is vulnerable to attacks such as address spoofing.
+
+   The CRANE protocol itself does not offer strong security facilities;
+   therefore, it cannot ensure confidentiality and integrity of CRANE
+   messages.  It is strongly recommended that users of the CRANE
+   protocol evaluate their deployment configurations and implement
+   appropriate security policies.  For example, if the CRANE protocol is
+   deployed over a local area network or a dedicated connection that
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 42]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+   ensure security, no additional security services or procedures may be
+   required; however, if CRANE clients and servers are connected through
+   the Internet, lower layer security services should be invoked.
+
+   To achieve a strong security protection of communications between
+   CRANE clients and servers, lower layer security services are strongly
+   recommended.  The lower layer security services are transparent to
+   the CRANE protocols.  Security mechanisms may be provided at the IP
+   layer using IPSEC [6], or it may be implemented for transport layer
+   using TLS [7].  The provisioning of the lower layer security services
+   is out of the scope of this document.
+
+7  References
+
+   [1]   Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
+         Authentication Dial In User Service (RADIUS)", RFC 2865, June
+         2000.
+
+   [2]   Calhoun, P., "DIAMETER Base Protocol", Work in Progress.
+
+   [3]   Calhoun, P., et. al., "DIAMETER Framework Document", Work in
+         Progress.
+
+   [4]   Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
+         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
+         "Simple Control Transmission Protocol", RFC 2960, October 2000.
+
+   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]   Kent, S. and R. Atkinson,  "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [7]   Dierks,  T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
+         2246, January 1999.
+
+8  Acknowledgments
+
+   Special thanks are due to Tal Givoly, Limor Schweitzer for conceiving
+   the work, and Nir Pedhatzur, Batya Ferder, and Peter Ludemann from
+   XACCT Technologies for accomplishing the first CRANE protocol
+   implementation.
+
+   Thanks are also due to Nevil Brownlee for his valuable comments on
+   the work, as well as the IETF IPFIX WG.
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 43]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+9  Authors' Addresses
+
+   Kevin Zhang
+   10124 Treble Court
+   Rockville, MD 20850
+   U.S.A.
+
+   Phone +1 301 315 0033
+   EMail: kevinzhang@ieee.org
+
+
+   Eitan Elkin
+   XACCT Technologies, Ltd.
+   www.xacct.com
+   12 Hachilazon St.
+   Ramat-Gan, Israel 52522
+
+   Phone +1 972 3 576 4111
+   EMail: eitan@xacct.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 44]
+
+RFC 3423          XACCT's CRANE Protocol Specification     November 2002
+
+
+10  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang & Elkin                Informational                     [Page 45]
+