mirror of
https://gitlab.com/d3tn/ud3tn.git
synced 2026-08-13 12:33:27 +02:00
doc: Update AAP docs and the dissector with new name
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This commit is contained in:
Felix Walter
parent
8d53addb5e
commit
a971d98f9a
2 changed files with 32 additions and 32 deletions
|
|
@ -1,6 +1,6 @@
|
|||
# µPCN Application Agent Protocol (AAP)
|
||||
# µD3TN Application Agent Protocol (AAP)
|
||||
|
||||
The µPCN Application Agent Protocol (AAP) allows applications to register a custom (sub-)EID with µPCN and send and receive bundles via this EID.
|
||||
The µD3TN Application Agent Protocol (AAP) allows applications to register a custom (sub-)EID with µD3TN and send and receive bundles via this EID.
|
||||
Communication takes place over a plain TCP connection. The default port is 4242. This document describes version 1 (v1) of the protocol.
|
||||
|
||||
## Message Format
|
||||
|
|
@ -54,7 +54,7 @@ The *ACK* and *NACK* messages do not contain additional data. They acknowledge o
|
|||
|
||||
### EID registration request (REGISTER)
|
||||
|
||||
The *REGISTER* message can only be sent by the client and requests that µPCN associates the current connection with a specific EID.
|
||||
The *REGISTER* message can only be sent by the client and requests that µD3TN associates the current connection with a specific EID.
|
||||
The message is encoded as follows:
|
||||
|
||||
```
|
||||
|
|
@ -63,7 +63,7 @@ The message is encoded as follows:
|
|||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
```
|
||||
|
||||
The EID contained within this message is *not* the complete EID that the application will be associated to, but the agent identifier, i.e. only the last part of the EID. The first part of the EID (as communicated in the *WELCOME* message) is configured in µPCN and cannot be altered.
|
||||
The EID contained within this message is *not* the complete EID that the application will be associated to, but the agent identifier, i.e. only the last part of the EID. The first part of the EID (as communicated in the *WELCOME* message) is configured in µD3TN and cannot be altered.
|
||||
|
||||
### Bundle transmission request (SENDBUNDLE)
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ The *SENDBUNDLE* message can only be sent by the client (the application). It co
|
|||
|
||||
### Bundle reception message (RECVBUNDLE)
|
||||
|
||||
The *RECVBUNDLE* message can only be sent by the server (µPCN). It is encoded in the same manner as the *SENDBUNDLE* message but instead contains the bundle's source EID:
|
||||
The *RECVBUNDLE* message can only be sent by the server (µD3TN). It is encoded in the same manner as the *SENDBUNDLE* message but instead contains the bundle's source EID:
|
||||
|
||||
```
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|
|
@ -95,7 +95,7 @@ The *RECVBUNDLE* message can only be sent by the server (µPCN). It is encoded i
|
|||
|
||||
### Bundle transmission confirmation (SENDCONFIRM)
|
||||
|
||||
The *SENDCONFIRM* message communicates that a bundle was accepted and queued for transmission. It can only be sent by the server (µPCN) and contains a numeric 64-bit bundle identifier uniquely identifying the queued bundle. This can be used in a *CANCELBUNDLE* message to cancel the transmission request.
|
||||
The *SENDCONFIRM* message communicates that a bundle was accepted and queued for transmission. It can only be sent by the server (µD3TN) and contains a numeric 64-bit bundle identifier uniquely identifying the queued bundle. This can be used in a *CANCELBUNDLE* message to cancel the transmission request.
|
||||
|
||||
```
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|
|
@ -115,17 +115,17 @@ This message requests cancellation of a queued bundle. It can only be sent by th
|
|||
|
||||
### Connection establishment notice (WELCOME)
|
||||
|
||||
This message is only sent by the server (µPCN), once at the start of every connection. It communicates µPCN's EID prefix, i.e. the first part of every EID that can be registered.
|
||||
This message is only sent by the server (µD3TN), once at the start of every connection. It communicates µD3TN's EID prefix, i.e. the first part of every EID that can be registered.
|
||||
|
||||
```
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|00010111| EID length (16) | µPCN EID prefix (variable-length) ... |
|
||||
|00010111| EID length (16) | µD3TN EID prefix (variable-length) ... |
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
```
|
||||
|
||||
### Connection liveliness check (PING)
|
||||
|
||||
This message can be sent by either the client (the application) or µPCN and is always answered with an *ACK* message. In which intervals the message should be sent is defined by the originating instance.
|
||||
This message can be sent by either the client (the application) or µD3TN and is always answered with an *ACK* message. In which intervals the message should be sent is defined by the originating instance.
|
||||
|
||||
*PING*:
|
||||
|
||||
|
|
@ -139,28 +139,28 @@ This message can be sent by either the client (the application) or µPCN and is
|
|||
|
||||
### Connection establishment
|
||||
|
||||
For establishing a connection to µPCN (the server), the application (the client) opens a new TCP connection to the AAP port configured in µPCN. µPCN responds to the newly opened connection with a *WELCOME* message.
|
||||
For establishing a connection to µD3TN (the server), the application (the client) opens a new TCP connection to the AAP port configured in µD3TN. µD3TN responds to the newly opened connection with a *WELCOME* message.
|
||||
|
||||
### EID registration
|
||||
|
||||
The application can only send and receive bundles if it registers itself under an endpoint identifier (EID). The full EID is composed of two parts: the µPCN EID prefix and the application-defined second part of the EID.
|
||||
The first part is communicated by µPCN in the *WELCOME* message at the start of the connection. The second part needs to be registered by the application. Only one EID can be registered per TCP connection. For registering an EID, a *REGISTER* message is sent by the application to µPCN. µPCN responds with either a positive (*ACK*) or a negative (*NACK*) acknowledgment. If the EID has not been registered by another client currently connected and µPCN can allocate the necessary resources, registration will succeed.
|
||||
The application can only send and receive bundles if it registers itself under an endpoint identifier (EID). The full EID is composed of two parts: the µD3TN EID prefix and the application-defined second part of the EID.
|
||||
The first part is communicated by µD3TN in the *WELCOME* message at the start of the connection. The second part needs to be registered by the application. Only one EID can be registered per TCP connection. For registering an EID, a *REGISTER* message is sent by the application to µD3TN. µD3TN responds with either a positive (*ACK*) or a negative (*NACK*) acknowledgment. If the EID has not been registered by another client currently connected and µD3TN can allocate the necessary resources, registration will succeed.
|
||||
|
||||
Re-registration and termination of registrations is possible. If a second *REGISTER* message is sent during an ongoing connection, the existing registration is replaced by the new one, if successful. A registration is deleted by either terminating the TCP connection or by sending a *REGISTER* message with an empty (zero-length) EID. Then, no bundles can be sent or received.
|
||||
|
||||
### Bundle transmission
|
||||
|
||||
If EID registration has been performed successfully, bundles can be transmitted via the connection. µPCN handles bundle creation, thus, the client only needs to transmit the destination EID as well as the payload data via a *SENDBUNDLE* message.
|
||||
If µPCN could create and queue the bundle for transmission, it sends a *SENDCONFIRM* message back to the client, containing the bundle identifier. If the bundle creation failed or no EID registration was performed beforehand, a *NACK* message is sent back to the client.
|
||||
If EID registration has been performed successfully, bundles can be transmitted via the connection. µD3TN handles bundle creation, thus, the client only needs to transmit the destination EID as well as the payload data via a *SENDBUNDLE* message.
|
||||
If µD3TN could create and queue the bundle for transmission, it sends a *SENDCONFIRM* message back to the client, containing the bundle identifier. If the bundle creation failed or no EID registration was performed beforehand, a *NACK* message is sent back to the client.
|
||||
|
||||
### Bundle reception
|
||||
|
||||
If EID registration has been performed successfully and a bundle destined to the client application is received by µPCN, it will issue a *RECVBUNDLE* message to the client. This message contains the source EID and the payload data of the received bundle.
|
||||
If EID registration has been performed successfully and a bundle destined to the client application is received by µD3TN, it will issue a *RECVBUNDLE* message to the client. This message contains the source EID and the payload data of the received bundle.
|
||||
|
||||
### Bundle cancellation
|
||||
|
||||
While a bundle is queued for transmission inside µPCN, the planned transmission(s) can be cancelled by the client. For that purpose, a *CANCELBUNDLE* message can be sent to µPCN. µPCN will respond with either an *ACK* or a *NACK* message, depending on whether the bundle could be cancelled successfully. Upon cancellation, the bundle is dropped completely by µPCN.
|
||||
While a bundle is queued for transmission inside µD3TN, the planned transmission(s) can be cancelled by the client. For that purpose, a *CANCELBUNDLE* message can be sent to µD3TN. µD3TN will respond with either an *ACK* or a *NACK* message, depending on whether the bundle could be cancelled successfully. Upon cancellation, the bundle is dropped completely by µD3TN.
|
||||
|
||||
### Connection check
|
||||
|
||||
For long-lasting connections, it has to be ensured that the operating system does not assume the connection to be dead and closes it automatically. For that purpose, the client or µPCN can (e.g. periodically) send a *PING* message which is answered by the receiving side with an *ACK* message.
|
||||
For long-lasting connections, it has to be ensured that the operating system does not assume the connection to be dead and closes it automatically. For that purpose, the client or µD3TN can (e.g. periodically) send a *PING* message which is answered by the receiving side with an *ACK* message.
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
-- Wireshark dissector for uPCN AAP
|
||||
-- Wireshark dissector for uD3TN AAP
|
||||
-- This script may be used to view the on-wire AAP communication in Wireshark.
|
||||
-- Use as follows: wireshark -Xlua_script:/path/to/tools/aap.lua
|
||||
|
||||
upcn_aap = Proto("upcn_aap", "uPCN Application Agent Protocol")
|
||||
ud3tn_aap = Proto("ud3tn_aap", "uD3TN Application Agent Protocol")
|
||||
|
||||
local f_version = ProtoField.uint8(
|
||||
"upcn_aap.version", "Version", base.HEX,
|
||||
"ud3tn_aap.version", "Version", base.HEX,
|
||||
nil,
|
||||
0xf0
|
||||
)
|
||||
|
|
@ -23,28 +23,28 @@ local f_type_names = {
|
|||
}
|
||||
|
||||
local f_type = ProtoField.uint8(
|
||||
"upcn_aap.type", "Type", base.HEX,
|
||||
"ud3tn_aap.type", "Type", base.HEX,
|
||||
f_type_names,
|
||||
0x0f
|
||||
)
|
||||
|
||||
local f_eid_length = ProtoField.uint16(
|
||||
"upcn_aap.eid_length",
|
||||
"ud3tn_aap.eid_length",
|
||||
"EID Length",
|
||||
base.DEC)
|
||||
|
||||
local f_eid = ProtoField.string("upcn_aap.eid", "EID", base.ASCII)
|
||||
local f_eid = ProtoField.string("ud3tn_aap.eid", "EID", base.ASCII)
|
||||
|
||||
|
||||
local f_bundle_length = ProtoField.uint64(
|
||||
"upcn_aap.bundle_length",
|
||||
"ud3tn_aap.bundle_length",
|
||||
"Bundle Payload Length",
|
||||
base.DEC)
|
||||
|
||||
local f_bundle_data = ProtoField.bytes("upcn_aap.bundle", "Bundle Payload")
|
||||
local f_bundle_data = ProtoField.bytes("ud3tn_aap.bundle", "Bundle Payload")
|
||||
|
||||
local f_bundle_id_sent = ProtoField.uint64(
|
||||
"upcn_aap.bundle_id_sent",
|
||||
"ud3tn_aap.bundle_id_sent",
|
||||
"Sent Bundle ID",
|
||||
base.HEX
|
||||
-- base.NONE,
|
||||
|
|
@ -52,14 +52,14 @@ local f_bundle_id_sent = ProtoField.uint64(
|
|||
)
|
||||
|
||||
local f_bundle_id_cancel = ProtoField.uint64(
|
||||
"upcn_aap.bundle_id_cancel",
|
||||
"ud3tn_aap.bundle_id_cancel",
|
||||
"Cancel Bundle ID",
|
||||
base.HEX
|
||||
-- base.NONE,
|
||||
-- frametype.RESPONSE
|
||||
)
|
||||
|
||||
upcn_aap.fields = {
|
||||
ud3tn_aap.fields = {
|
||||
f_version,
|
||||
f_type,
|
||||
f_eid_length,
|
||||
|
|
@ -134,9 +134,9 @@ end
|
|||
|
||||
|
||||
local function dissect_aap(tvb, pinfo, tree)
|
||||
pinfo.cols.protocol = "UPCN AAP";
|
||||
pinfo.cols.protocol = "UD3TN AAP";
|
||||
|
||||
local subtree = tree:add(upcn_aap, tvb(0))
|
||||
local subtree = tree:add(ud3tn_aap, tvb(0))
|
||||
subtree:add(f_version, tvb(0, 1))
|
||||
subtree:add(f_type, tvb(0, 1))
|
||||
|
||||
|
|
@ -165,11 +165,11 @@ local function dissect_aap(tvb, pinfo, tree)
|
|||
end
|
||||
|
||||
|
||||
function upcn_aap.dissector(tvb, pkt, root)
|
||||
function ud3tn_aap.dissector(tvb, pkt, root)
|
||||
dissect_tcp_pdus(
|
||||
tvb, root, 1, get_aap_length, dissect_aap
|
||||
)
|
||||
end
|
||||
|
||||
local dissector_table = DissectorTable.get("tcp.port")
|
||||
dissector_table:add(4242, upcn_aap)
|
||||
dissector_table:add(4242, ud3tn_aap)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue