Hello Pascal,
My apologies for late reply (I am taking some time off). Since I last
wrote, thread has progressed quite a bit. Anyways...·
What attracted my attention is the header structure in Figure 6. It is
often the case that field devices are smaller 8-bit or16-bit addresses
connected to a PLC. The general practice today is to encapsulate device
address and function code/command to an actuator over TCP. This is an
indirect communication to the actuator.
I thought it would be interesting if we could directly address the
device and send the command over. By having topological structure, one
benefit is that association to PLC or controller will always be there
due to parent/child relationship in this address structure. This gives
us savings of bits on wire, on both address and payload, because if the
actuator is directly addressed, the payload only contains the command.
When an OT operator sees this device in an HMI or SCADA systems, they
see direct actuator's address, without any mapping.
It is my personal opinion (I maybe wrong) that IPV6 as is will be an
overkill for factory floors. Moreover, I like the asymmetry in the
header that source and destination can be variable length - the server
above could be IPv6 in the IT world, and actuator could be NSA in OT
world. I find NSA type of mechanisms give better fine-tuning of limited
domain industrial networks.
With regards to SCHC, maybe it is a better approach but I do not know
enough. Two potential benefits over SCHC maybe that the operator need
not assign an IPV6 address to actuators/field devices; second, since we
know that the shop floor topology and actuator's location do not change,
no need to maintain the state... but I am just guessing.
Having said that, many forwarding related questions came up, which I
should be dealt separately and some are already raised.
- Kiran
On 8/16/2022 1:42 PM, Pascal Thubert (pthubert) wrote:
Hello Kiran
Note that the core of the work is an autoconfiguration model along a
fixed tree structure, and the desired “side effects” are implicit
routing and short addresses. For short addresses, we already have SCHC
and 6LoWPAN so that would not be a sufficient argument.
Now, I do not see how your point on IIoT matches this specification.
Since a main objection (though not the only one) is the lack of
applicability, this may help. Could you please elaborate?
In particular, which industrial protocol would benefit from this
automatic assignment of IP addresses (vs. Say, mapping the protocol
address into an IID or something)?
Many thanks in advance;
Pascal
*From:* 6lo <6lo-boun...@ietf.org> *On Behalf Of *Kiran Makhijani
*Sent:* mardi 16 août 2022 2:08
*To:* carle...@entel.upc.edu; 6lo@ietf.org
*Subject:* Re: [6lo] Call for WG adoption of
draft-li-6lo-native-short-address-03
Hello,
I have quickly skimmed through the document and would like to see this
work progress.
I see that the focus is mainly on wireless constrained devices,
however, in industrial networks with field devices it is useful to
have short and variable addressing schemes on a factory floor.
Variable addressing approach is more interesting here because, on one
side the controllers may use IPv6 addresses and field-devices on the
other end can very well be shorter addresses.
I support this document and wouldn't mind contributing to the
alignment with above mentioned scenario.
Cheers,
Kiran
------------------------------------------------------------------------
*From:*Carles Gomez Montenegro [mailto:carle...@entel.upc.edu
<mailto:carle...@entel.upc.edu>]
*Sent:*Monday, August 1, 2022, 7:58 AM
*To:*6lo@ietf.org
*Subject:*[6lo] Call for WG adoption of
draft-li-6lo-native-short-address-03
Dear 6lo WG,
This message starts a call for WG adoption for
draft-li-6lo-native-short-address-03.
(Link below:
https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03)
Considering that some folks may be on vacation currently or in the
next
few days, the call will end on the 22nd of August, EOB.
Please state whether you are in favor of adopting this document.
Also, any comments you may have, and/or expressions of interest to
review
the document, will be very much appreciated.
Thanks,
Shwetha and Carles
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
