Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)Department of Computer ScienceUniversity of AucklandPB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comHuawei Technologies Co., LtdQ14, Huawei Campus, No.156 Beiqing RoadHai-Dian District, Beijing, 100095P.R. Chinajiangsheng@huawei.comHuawei Technologies Co., LtdQ14, Huawei CampusNo.156 Beiqing RoadHai-Dian District, Beijing100095P.R. Chinaleo.liubing@huawei.comThis document describes how bulk data may be transferred between Autonomic Service Agents
via the GeneRic Autonomic Signaling Protocol (GRASP).
The document discusses how information may be distributed
within the secure Autonomic Networking Infrastructure (ANI) .
Specifically, it describes using the Synchronization and Flood Synchronization mechanisms of the GeneRic
Autonomic Signaling Protocol (GRASP) for this purpose. However,
those mechanisms are limited to distributing GRASP Objective Options contained in messages that cannot
exceed the GRASP maximum message size of 2048 bytes.
There are scenarios in autonomic networks where this restriction is a problem.
One example is the distribution of network
policy in lengthy formats such as YANG or JSON.
Another case might be an
Autonomic Service Agent (ASA) uploading a log file to the Network Operations Center (NOC). A third case might
be a supervisory system downloading a software upgrade to an autonomic node.Naturally, an existing solution such as a secure file transfer protocol or secure HTTP might be used for
this. Other management protocols such as syslog or NETCONF
might also be used for related purposes, or might be mapped directly over GRASP.
The present document, however, applies to any scenario where it is preferable to re-use the
autonomic networking infrastructure itself rather than an additional mechanism, but there
is a need to transfer a large amount of data. The basic model is to
use the GRASP Negotiation process to transfer and acknowledge multiple
blocks of data in successive negotiation steps.NOTE: This is an early draft of a solution. As the specification becomes more mature,
the authors expect it to become precise enough to be placed on the standards track.As for any GRASP operation, the two participants are considered to be Autonomic Service Agents (ASAs)
and they communicate using a specific GRASP Objective Option, containing its own name, some flag bits,
a loop count, and a value. In bulk transfer, we can model the ASA acting as the source of the transfer as
a download server, and the destination as a download client. Compared to a normal GRASP negotiation, the communication
pattern is slightly asymmetric:
The client first discovers the server by the GRASP discovery mechanism (M_DISCOVERY and M_RESPONSE messages).The client then sends a GRASP negotiation request (M_REQ_NEG message).
The value of the objective expresses the requested item (e.g., a file name - see the next
section for a detailed example).The server replies with a negotiation step (M_NEGOTIATE message). The value of the objective is the first section of
the requested item (e.g., the first block of the requested file as a raw byte string).The client replies with a negotiation step (M_NEGOTIATE message). The value of the objective is a simple
acknowledgement (e.g., the text string 'ACK').The last two steps repeat until the transfer is complete. The server signals the end by
transferring an empty byte string as the final value. In this case the client responds with
a normal end to the negotiation (M_END message with an O_ACCEPT option).Errors of any kind are handled with the normal GRASP mechanisms, in particular by an M_END message
with an O_DECLINE option in either direction.The block size must be chosen such that each step does not exceed the GRASP message size limit of 2048
bits.This approach is safe since each block must be positively acknowledged, and data transfer errors
will be detected by TCP. If a future variant of GRASP runs over UDP, the mandatory UDP checksum for IPv6
will detect such errors. The method does not currently specify retransmission for failed blocks, so a
failed transfer will need to be restarted. In an enterprise network with low bit error rates, this
is not considered a serious issue.An observant reader will notice that the GRASP loop count mechanism, intended to terminate
endless negotiations, will cause a problem for large transfers. For this reason, both the client
and server must artificially increment the loop count by 1 before each negotiation step.If network load is a concern, the data rate can be limited by inserting a delay before each
negotiation step, with the GRASP timeout set accordingly. Either the server or the client,
or both, could insert such a delay. Also, either side could use the GRASP Confirm Waiting (M_WAIT)
message to slow the other side down.The description above concerns bulk download from a server (responding ASA) to a client (requesting ASA).
The data transfer could also be in the opposite (upload) direction with minor modifications to
the procedure: the client would send the data blocks and the server would send acknowledgements.This example describes a client ASA requesting a file download from a server ASA.Firstly we define a GRASP objective informally:
["411:mvFile", 3, 6, value]
The formal CDDL definition is:
The objective-flags field is set to indicate negotiation.Dry run mode must not be used.The loop-count is set to a suitable value to limit the scope of discovery. A suggested default value is 6.The value takes the following forms:
In the initial request from the client, a UTF-8 string containing the requested file name (with file path if appropriate).In negotiation steps from the server, a byte string containing at most 1024 bytes. However:
If the file does not exist, the first negotiation step will return an M_END, O_DECLINE response.After sending the last block, the next and final negotiation step will send an empty byte string as the value.In negotiation steps from the client, the value is the UTF-8 string 'ACK'.Note that the block size of 1024 is chosen to guarantee not only that each GRASP message is below the size
limit, but also that only one TCP data packet will be needed, even on an IPv6 network with a minimum link MTU.We now present outline pseudocode for the client and the server ASA. The API documented in
is used in a simplified way, and
error handling is not shown in detail.The above description and example assume that GRASP is implemented over a
reliable transport layer such as TCP, such that lost or corrupted messages need not be
considered. In the event that GRASP is implemented over an unreliable transport layer
such as UDP, it would be necessary to add a block number to both the data block and
acknowledgement objectives, so that missing blocks can be retransmitted, or duplicate
blocks can be ignored.
For example, the objective in would become:It would also be necessary for the transport layer to detect data errors, for example
by enabling UDP checksums.In an IPv6 environment, a minimal MTU of 1280 bytes can be assumed, and assuming that
high throughput is not a requirement, bulk transfers can be designed to match that MTU. However,
there are environments where the underlying physical MTU is much smaller. For example,
on an IEEE 802.15.4 network it may be less than 100 bytes . In such
a case, a bulk transfer solution has several choices:
Accept the overhead of an adaptation layer, and therefore assume a network-layer MTU of 1280 bytes.Attempt to determine the actual MTU available without lower-layer fragmentation.Attempt to determine a message size that provides optimum performance.TBD: further discussion?TBD - discussion of specific use cases?TBD - discussion of user space API for bulk transfer?All GRASP transactions are secured by the mandatory security substrate required by
. No additional security issues are created by
the application of GRASP described in this document.This document makes no request of the IANA.TBD.draft-carpenter-anima-grasp-bulk-00, 2017-09-12:
Initial version.