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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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
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)", RFC2865, 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", RFC2960, October 2000.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[6] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, 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.
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
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 RFCEditor function is currently provided by the
Internet Society.