[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-604) Specify requirements on the underlying network transport
[ https://issues.oasis-open.org/browse/MQTT-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davide Lenzarini updated MQTT-604:
----------------------------------
Proposal:
In Terminology Add:
Virtual Connection:
Carries the MQTT-SN data between a Client and a Gateway, or a broadcast to all Gateways and all clients.
Refer to section 3.2 Networks & Transport Layers for non-normative examples.
In 3.2 Networks & Transport Layers replace with:
The MQTT-SN V2.0 protocol requires an underlying transport to create a Virtual Connection,
this carries datagrams from a Client to a Gateway and a Gateway to a Client.
The underlying transport may also broadcast datagrams from a Client to all Gateways and from a Gateway to all Clients.
The datagrams carry the MQTT-SN V2.0 Packets which must be received unaltered and complete.
* The underlying transport does not need to be reliable,
it is expected that datagrams will be lost or delivered out of order.
* If the network might deliver a datagram more than once, then it is highly recommended that the PROTECTION
packet Monotonic Counter is used to eliminate the duplicates.
* The MQTT-SN V2.0 protocol will tolerate out of order Packets and it will retransmit lost Packets.
* The MQTT-SN V2.0 does not perform error correction. If a
corrupted or partial Packets is received it will cause a protocol error.
* The MQTT-SN V2.0 implementation may use either the origin network address or the sender identifier in the
PROTECTION Packet to determine the identity of the Virtual Connection.
* The underlying network does not need to provide low latency transmission.
* The networks may be connectionless, the virtual connections do not need to have an event that signals when they begin or end.
* The networks may be radio networks.
Non-normative comment
UDP as defined in [RFC0768] can be used for MQTT-SN v2.0 if the Maximum Transmission Unit
is configured to be more that the MQTT-SN Packet size used and no datagram fragmentation occurs.
Depending on the network configuration, UDP can duplicate datagrams.
If this can happen, the PROTECTION Packet monotonic counter should be used.
Examples of possible consequences of not removing duplicates datagrams are:
â DISCONNECT Packet applied to the wrong Virtual Connection
â SUBSCRIBE and UNSUBSCRIBE Packets applied to the wrong Session
â PUBLISH QOS=2 published more than once
The following transport protocols are also suitable:
DTLS v1.2 [RFC6347]
DTLS v1.3 [RFC9147]
QUIC [RFC9000]
Other non-IP protocols
TCP/IP [RFC0793], TLS [RFC5246], WebSocket [RFC6455] can be used for MQTT-SN v2.0 however, they do not provide
a broadcast capability so the optional ADVERTISE, SEARCHGW, GWINFO and PUBLISH MINUS -1 Packets cannot be implemented.
Non-normative comment
TCP ports 8883 and 1883 are registered with IANA for MQTT TLS and non-TLS communication respectively.
==> MQTT reserved both the UDP and TCP ports but prohibits the use of UDP,
we should approach the MQTT TC to get this redesignated as MQTT/MQTT-SN.
==> Is there a recommended way to test whether an MQTT CONNECT is being sent to an MQTT-SN Gateway
or an MQTT-SN CONNECT is being sent to an MQTT Server?
was:
In Terminology Add:
Virtual Connection:
Carries the MQTT-SN data between a Client and a Gateway, or a broadcast to all Gateways and all clients.
Refer to section 3.2 Networks & Transport Layers for non-normative examples.
In 3.2 Networks & Transport Layers replace with:
The MQTT-SN V2.0 protocol requires an underlying transport to create a Virtual Connection,
this carries datagrams from a Client to a Gateway and a Gateway to a Client.
The underlying transport may also broadcast datagrams from a Client to all Gateways and from a Gateway to all Clients.
The datagrams carry the MQTT-SN V2.0 Packets which must be received unaltered and complete.
* The underlying transport does not need to be reliable,
it is expected that datagrams will be lost or delivered out of order.
* If the network might deliver a datagram more than once, then it is highly recommended that the PROTECTION
packet Monotonic Counter is used to eliminate the duplicates.
* The MQTT-SN V2.0 protocol will tolerate out of order Packets and it will retransmit lost Packets.
* The MQTT-SN V2.0 does not perform error correction. If a
corrupted or partial Packets is received it will cause a protocol error.
* The MQTT-SN V2.0 implementation may use either the origin network address or the sender identifier in the
PROTECTION Packet to determine the identity of the Virtual Connection.
* The underlying network does not need to provide low latency transmission.
* The networks may be connectionless, the virtual connections do not need to have an event that signals when they begin or end.
* The networks may be radio networks.
Non-normative comment
UDP as defined in [RFC0768] can be used for MQTT-SN v2.0 if the Maximum Transmission Unit
is configured to be more that the MQTT-SN Packet size used and no datagram fragmentation occurs.
Depending on the network configuration, UDP can duplicate datagrams.
If this can happen, the PROTECTION Packet monotonic counter should be used.
Examples of possible consequences of not removing duplicates datagrams are:
â DISCONNECT Packet applied to the wrong Virtual Connection
â SUBSCRIBE and UNSUBSCRIBE Packets applied to the wrong Session
â PUBLISH QOS=2 published more than once
The following transport protocols are also suitable:
DTLS v1.2 [RFC6347]
DTLS v1.3 [RFC9147]
QUIC [RFC9000]
Other non-IP protocols
TCP/IP [RFC0793], TLS [RFC5246], WebSocket [RFC6455] can be used for for MQTT-SN v2.0 however, they do not provide
a broadcast capability so the optional ADVERTISE, SEARCHGW, GWINFO and PUBLISH MINUS -1 Packets cannot be implemented.
Non-normative comment
TCP ports 8883 and 1883 are registered with IANA for MQTT TLS and non-TLS communication respectively.
==> MQTT reserved both the UDP and TCP ports but prohibits the use of UDP,
we should approach the MQTT TC to get this redesignated as MQTT/MQTT-SN.
==> Is there a recommended way to test whether an MQTT CONNECT is being sent to an MQTT-SN Gateway
or an MQTT-SN CONNECT is being sent to an MQTT Server?
> Specify requirements on the underlying network transport
> --------------------------------------------------------
>
> Key: MQTT-604
> URL: https://issues.oasis-open.org/browse/MQTT-604
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Task
> Components: MQTT-SN
> Affects Versions: v2.0
> Reporter: Ian Craggs
> Assignee: Andrew Banks
> Priority: Major
>
> The section on "Networks and Transport Layers" needs to specify the requirements on the underlying transport, as MQTT 5.0 does in the normative statement:
> A Client or Server MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client [MQTT-4.2-1].
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]