ISE write-up for: draft-schmitt-ipfix-tiny-03
Abstract:
'This document specifies the TinyIPFIX protocol that serves for
transmitting smart metering data in constrained networks such as
6LoWPAN [RFC4944]. TinyIPFIX is derived from IPFIX [RFC7011] and
adopted to the needs of constrained networks. This document
specifies how the TinyIPFIX Data and Template Records are transmitted
in constrained networks such as 6LoWPAN and how TinyIPFIX data can be
converted into unTinyIPFIX data in a proxy device.'
This draft has no IANA Considerations.
This draft presents the work of a fairly long-running research project as
THE, Zurich, see "TinyIPFIX", Schmitt, Kothmayr, Ertl, Wen and Braun and
Carle, Computer Communications, 2016.
It was reviewed for me by Tanja Zseby and Paul Aitken.
The authors have made the changes suggested by the reviewers, as well as those
requested by the ISE.
- - - - -
Tanja Zseby's review:
Comments on draft-schmitt-ipfix-tiny-00
General remarks
- I like the idea of using IPFIX for sensor data very much and think the draft
provides a very useful contribution. One challenge may be that there have been
many protocols proposed (and also standardized) for sensor data export. It
would be useful to include some references and point out the advantages of
using TinyIPFIX.
- The term “smart meter” is usually associated with meters in the power grid,
but the approach is suitable for sensors in general. In addition: Due to its
suitability for constrained environments TinyIPFIX might be also an excellent
protocol choice for “stupid” meters (e.g., meters with restricted
functionality). So I would suggest to reconsider the title (e.g., “TinyIPFIX
for sensor data export” or “TinyIPFIX for 6LoWPAN devices”).
- I would suggest to include a table or list to show/summarize the differences
between standard (full) IPFIX and TinyIPFIX. Also since several fields are
shortened, the consequences should be explicitly shown (e.g., maximum number of
packets with unique seq. no. compared to full IPFIX, etc.) and maybe some
references why in certain environments this would be OK.
- The use of UDP and unidirectional communication heavily restricts the
applicability of the protocol. That is ok, but it may be useful to provide more
application examples.
Specific sections
- Section 3.1: “IRIS mote from Crossbow”: I would mention at least one further
vendor/references. - Section 3.3: “protocol can also be used to transmit data
in other networks”: It should be clarified what is specific to 6LoWPAN
(addresses?) and would need to be changed if other networks are use. - Section
3.4: Should clarify what is the target environment and potential differences.
E.g., sensors located in one administrative network vs. data transmitted over
wide area. - Section 3.4: If TinyIPFIX is used over the Internet, UDP may be
problematic due to the lack of congestion control. - Section 3.4: TCP and SCTP
“NOT RECOMMENDED” seems quite strict for me. I would rather put a MAY and just
give advice to readers that performance may be reduced (depending on sensor
types, data and network). - Section 3.4: The use of UDP and unidirectional
communication heavily restricts the applicability of the protocol. Are all
configuration parameters, timing, templates etc. set manually in advance and
never changed? Or do you consider further interfaces to the sensor? Would the
examples (Duck Island, Golden Gate) work with the restrictions? - Section 3.4:
Occasional loss of some sensor data may be acceptable for some applications but
loss of template messages and the resulting loss of many subsequent sensor data
can be more severe because applications may not have enough data to
extrapolate. So I would explicitly separate these two restrictions (e.g.,
occasional random loss and bursty loss). - Section 3.4: “Smart Meters can be
queried”: not if they only support unidirectional communication - Section
5: “Smart Meter (S.M.) queries its internal sensors”: Does it mean a smart
meter is considered as a set of sensors? Should be clarified. - Section 5: “may
also aggregate the incoming data with its own measurement”: What is meant here?
It sounds like the collector is doing own measurements? - Section 6.1. Can
different header formats be mixed in subsequent IPFIX records? - Section 6.1:
Not getting exporting timestamps is a further restriction and may be added to
the list in section 4. If added on application layer this increases the
messages. - 6.2: should explain why Set ID 3 should not be used - Section 7.1.,
export time: How does the collector know whether the time was added by the
sensor or by the Mediator? - Section 7.1., sequence number: expanded here means
just putting the value in a larger field, correct?
Typos
- Section2, TinyIPFIX Smart Meter: tempering should be tampering
- Section 4, point 3. “several into” should be “several measurements into”
- Section 6.1. “thre” should be “three”
- Section 6.1. “WSN settings the also”: remove “the”
- Section 6.1. “Figure 10where” blank missing
- Section 6.1. containts should be contains
- Section 7: “counterparts in IPFIX” period missing- Several times: “an
TinyIPFIX Exporter” should be rather “a TinyIPFIX Exporter”?
- - - - -
Paul Aitken's review:
I've reviewed draft-schmitt-ipfix-tiny-01.
General comments:
* Some good ideas, but needs some work.
* Although Brian is listed as a co-author, I must wonder whether he's actually
read the draft? * Over-emphasis of 6LoWPAN, smart meters, and wireless. The
ideas would seem to apply equally to other low-powered networks and to wired
devices, so the draft should specify a generic protocol which can be used for
these, but isn't constrained by them. eg, non smart-meter devices should also
be able to use this protocol without having to re-write the document to s/smart
meter/other device/. * An obvious optimisation is to pre-share the IPFIX
templates, thus removing the need to export them at all (just export the usual
IPFIX data records). This solves several issues in the draft. I've written
draft-aitken-ipfix-pre-defined-templates because the idea was potentially
patentable (my employer won't be pursing this). The two drafts could be merged
or developed in parallel, but I've little time to devote to this.
Nits: multiple issues to be resolved.
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-schmitt-ipfix-tiny-01.txt
Spelling:
s/RFC7101/RFC7011/ throughout!
TinyIPFIX is derived from IPFIX [RFC7101] and adopted to the needs of
constrained networks. This documents specifies how the TinyIPFIX
wireless senor nodes, motes or any other kind of small constraint
12.1. Norminative References
where data is transmitted autonomically from the meters
A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header,
The first part has a fixed length of thre octets and consists of the
containts Data Record for Template 256. This places special
Lookup extended SetID field, shiftig enabled.
Multiple different capitalisations of "6lowpan" :
9 x 6LoWPAN
4 x 6LowPAN
1 x 6lowpan
Figure 14: TinyIPFIX Dta Field Specifier
Copyright:
* Is this the most appropriate copyright statement? Specifically, "Code
Components extracted from this document" - there are none.
Abstract:
This document specifies the TinyIPFIX protocol that serves for
transmitting smart metering data in6LoWPAN networks [RFC4944
<https://tools.ietf.org/html/rfc4944>]. TinyIPFIX is derived from IPFIX
[RFC7101 <https://tools.ietf.org/html/rfc7101>] and adopted to the needs of
constrained networks. This documents specifies how the TinyIPFIX Data and
Template Records are transmitted in6LoWPAN networks and how TinyIPFIX data
can be converted into unTinyIPFIX data in a proxy device.
* The protocol is more widely useful than just 6LoWPAN, so consider "in
constrained networks such as 6LoWPAN".
Section 1. Introduction
Smart meters that form a constrained wireless network need an
application layer protocol that allows the efficient transmission of
metering data from the devices tosome kind of central analysis
device.
* "to a central analysis device."
The devices are often battery powered and are expected to run for a
long time without having the possibilityto re-charge themselves.
* "of recharging"
Section 2. Terminology
* Should define "TinyIPFIX" (eg, "the protocol specified in this document") and
"unTinyIPFIX" (which is presumably IPFIX per RFC 7011). Consider "regular IPFIX
[RFC7011]" for clarity.
* Swap around the last two sentences of this paragraph, and remove the
struck-through "IPFIX":
Most of the terms used in this draft are defined in [RFC7101
<https://tools.ietf.org/html/rfc7101>]. All these terms are written with
their first letter being capitalized. Most of the terms that are defined for
IPFIX can be used to describe TinyIPFIX. The term "TinyIPFIX" is used in
front of the IPFIX term to distinguish between the IPFIX version and the
TinyIPFIX version. This draft uses the term IPFIX to refer to IPFIX as
perRFC 7101 <https://tools.ietf.org/html/rfc7101> and the term TinyIPFIX
for the IPFIX version defined in this draft.
* Move "The term smart meter is used" paragraph after the IPFIX paragraphs,
just before the "TinyIPFIX Exporting Process" definition.
TinyIPFIX Exporter
A TinyIPFIX Exporter is asmart metering device that contains at
least one TinyIPFIX Exporting Process.
* There's no need to say "smart metering" here, since the TI Exporter could be
hosted on any kind of device. Smart metering is just one example of a possible
application. Compare with the TI Device definition, which says "device" without
specifing "smart metering".
TinyIPFIX Device
A TinyIPFIX Device is a device that contains one or more TinyIPFIX
Collector or one or more TinyIPFIX Exporter.
* It's more usual to pluralise: "Collectors ... Exporters".
TinyIPFIX Smart Meter
A TinyIPFIX Smart Meter is a device that contains the
functionality of aTinyIPFIX device. It is usually equipped with
one or more sensors that meter a physical quantity, like power
consumption, temperature, or physical tempering with the device.
Every TinyIPFIX Smart Meter MUST at least contain a TinyIPFIX
Exporting Process. It MAY contain a TinyIPFIX Collecting Process
in order to work as aTinyIPFIX Proxy or Concentrator.
* Capitalise "TinyIPFIX device" since it's a defined term (and in fact the only
use of that term).
* Uses "TinyIPFIX Proxy" which hasn't been defined yet.
* Consider "TinyIPFIX Proxy or TinyIPFIX Concentrator".
* Per the introduction, "In order to save energy, smart meters often power off
their wireless networking device". Therefore a Smart Meter is not an
appropriate device to act as an Proxy or Concentrator.
TinyIPFIX Message
The TinyIPFIX Message is a message originated by a TinyIPFIX
Exporter. It is composed of a TinyIPFIX Message Header and one or
more TinyIPFIX Sets. The TinyIPFIX Message Format is defined in
Section 6.
* Uses "TinyIPFIX Sets" which hasn't been defined yet.
TinyIPFIX Data Record
A TinyIPFIX Data Record equals a Data Record in [RFC7101
<https://tools.ietf.org/html/rfc7101>]. The term is used to distinguish
between IPFIX and TinyIPFIX throughout the document.
* "this"
TinyIPFIX Template Record
A TinyIPFIX Template Record is similar to a Template Record. The
xxx Template Record Header is substituted with a TinyIPFIX Template
Record Headerand is otherwise equal to a Template Record. See
Section 6.3.
* Say "similar to an IPFIX Template Record" and/or xref RFC 7011. Also at xxx.
"... and is otherwise equal to a Template Record" seems to say that (IPFIX)
Template Record == (IPFIX) Template Record.
TinyIPFIX Intermediate Process
A TinyIPFIX Intermediate Process is anIPFIX Intermediate Process that
can handle TinyIPFIX Messages.
* Add "IPFIX" as indicated for consistency with the following "TinyIPFIX Proxy"
and "TinyIPFIX Concentrator" definitions.
TinyIPFIX Concentrator
A TinyIPFIX Concentrator is an IPFIX Concentrator that can handle
TinyIPFIX Messages.
* "IPFIX Concentrator" is not a defined term.
3.2. Energy constraints
transmitting application data under such circumstances. As the
communication is unidirectional, a meter can completely power down
its radio frequency transceivers as long as it does not have any data
tosent. If the metering device is able to keep a few measurements
in memory, and if real time metering is not a requirement, the
TinyIPFIX Data Records can be pushed less frequently. Therefore,
saving some more energy on the radio frequency transceivers.
* "send".
* Join the last sentence: "... can be pushed less frequently, therefore saving
..."
3.3. Packet size constraints
TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which
are based on IEEE 802.15.4 [RFC4944
<https://tools.ietf.org/html/rfc4944>].However, the protocol can also be
used to transmit data in other networks.
* No it can't, because the TinyIPFIX Transport Session requires 6LowPAN
addresses:
A TinyIPFIX Transport Session is defined by the communication between
a TinyIPFIX Exporter (*identified by an 6LowPAN-Address*, the Transport
Protocol, and the Transport Port) and a TinyIPFIX Collector
(identified by the same properties).
IEEE 802.15.4 defines a
maximum frame size of 127 octets,which usually leaves 102 octets for
user data.
* Why? Briefly explain the other 25 octets. eg, "A header size of 25 octets
leaves 102 octets ...".
TinyIPFIX enhances IPFIX by a header compression scheme,which allows to
reduce the overhead from header sizes significantly.
* "which allows the header size overhead to be significantly reduced."
3.4. Transport protocol constraints
This transport protocol recommendation is not suitable for TinyIPFIX.
A header compression scheme that allowsto compress an IPv6 header
from 40 octets down to 2 octets is defined in 6LoWPAN.
* "compression of ..."
* If TI isn't being used over 6LoWPAN, can that header compression scheme still
be used? (Per 3.3 / "the protocol can also be used to transmit data in other
networks.").
4. Application scenarios for TinyIPFIX
TinyIPFIX is derived from IPFIX [RFC7101
<https://tools.ietf.org/html/rfc7101>] and is therefore a unidirectional
push protocol.
* Underlying transport protocols (TCP, SCTP) may be bi-directional.
Hence, TinyIPFIX only fits for application
scenarios where meters transmit data to one or more Collectors.
* As opposed to scenarios where the Collector polls the meters.
If TinyIPFIX is used over UDP, as recommended, packet loss can occur.
Furthermore, if an initial Template Message gets lost, and is
therefore unknown to the Collector, all TinyIPFIX Data Sets that
reference this Template cannot be decoded. Hence, all these Messages
are lostif they are not cached by the Collector.
* It's dangerous for the Collector to cache Messages pending the receipt of a
re-transmitted Template, because it's impossible to know whether the newly
received Template is identical to the original (ie, re-sent) or is a new
template using the same ID as the original (ie, re-defined). Therefore, IPFIX
Collectors generally discard such Records.
* However, in the case of multiple monitoring devices, isn't it likely that
they all use the same Templates? In fact, the Templates can be well known and
defined in advance, so there's no need to transmit them at all. Templates are
only required when the fields in the data records may vary, eg if devices are
monitoring different parameters, or if certain measurements may sometimes be
unavailable and must therefore be omitted from the exported data. See
draft-aitken-ipfix-pre-defined-templates.
One
application for IPFIX can be long term monitoring of large physical
* s/can be/is/
Deploying TinyIPFIX in such scenarios seems to be a good fit.
* "TinyIPFIX is a good fit for such scenarios".
1. The application must require a push protocol. It is not possible
to request data from a smart meter. The TinyIPFIX Smart Meter
decides for itself when to send its metering data.
* Not true; it may be possible to request data from (another type of) smart
meter. "It is not possible to request data from a TinyIPFIX Smart Meter."
3. Ifreal-time is not required, the application might benefit from
accumulated several measurements into a single TinyIPFIX Message.
* "If real-time reporting is not required"?
* "accumulating".
TinyIPFIX easily allows the aggregationof several into a single
TinyIPFIX Message (or a single packet).
* Missing noun, eg "Of several measurements into" ?
* "accumulate" and "aggregate" seem to be used interchangeably here. Beware
that IPFIX aggregation means something quite different per RFC 7015. Therefore,
it'd be better to use "accumulate" when the sense is "addition of multiple
records", and review the use of "aggregation" throughout sections 4 and 5.
Figure 1
* s/TinyIPFIX S.M./TinyIPFIX Device/
* show multiple Exporters feeding into the Collector.
* draw the figure consistently downwards or rightwards, because that's the way
people read. Flowing upwards is confusing because it puts the last things first.
A TinyIPFIX Smart Meter (S.M.) queries its internal sensors to
retrieve the sensor data. It then encodes the results into a
TinyIPFIX Message and exports this TinyIPFIX Message to one or more
TinyIPFIX Collectors.
* Technically, the SM uses a TinyIPFIX Exporting Process to encode the
TinyIPFIX Message, and a TinyIPFIX Exporter to manage the export.
A second way to deploy TinyIPFIX Smart Meter can employ aggregation
on TinyIPFIX Messages during their journey through the constrained
network as shown in Figure 2. This aggregation can be performed by
special TinyIPFIX Smart Meter that act as TinyIPFIX Concentrators.
Such devices must have enough resources to perform the aggregation.
* This doesn't read well.
* Per earlier feedback, a constrained Smart Meter is not a good choice for a
Concentrator.
Figure 2
* s/TinyIPFIX S.M./TinyIPFIX Device/
* What's the significance of the (1) in "Collector(1)" ?
* s/Aggregation on/Aggregation of/
* I'd prefer the figure to flow vertically downwards, eg:
+-------------------------+ +-------------------------+
| Smart Meter | | Smart Meter |
+-------------------------+ ... +-------------------------+
| TinyIPFIX Device | | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+-------------------------+ +-------------------------+
| |
| | TinyIPFIX
| |
v v
+-------------------------+
| TinyIPFIX Concentrator |
| [Collecting Process] |
| [Exporting Process] |
+-------------------------+
|
| TinyIPFIX
|
v
+-------------------------+
| Collector |
| [Collecting Process(es)]|
+-------------------------+
Figure 2: Aggregation of TinyIPFIX
Under Figure 2:
TinyIPFIX Smart Meters send their data to TinyIPFIX Concentrator
which needs to have enough storage space to store the incoming data.
It may also aggregate the incoming data with its own measurement data. The
aggregated data can then be re-exported again to one or more Collectors.
* No, this mixes up the functions of a TinyIPFIX Concentrator and a Smart
Meter. If the Concentrator is hosted in a Smart Meter (which I've already said
is a bad idea), then the the Concentrator can be viewed as receiving data from
multiple Smart Meters - one locally, and some remotely.
* ie, it can be modelled as so (compare with the figure above) :
+-------------------------+ +-------------------------+
| Remote Smart Meter | | Local Smart Meter |
+-------------------------+ +-------------------------+
| TinyIPFIX Device | | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+-------------------------+ +-------------------------+
| |
| | TinyIPFIX
| |
v v
+-------------------------+
| TinyIPFIX Concentrator |
| [Collecting Process] |
+-------------------------+
The TinyIPFIX Smart Meters transmit their TinyIPFIX Messages to one
node, e.g. the base station, which translates the TinyIPFIX Messages
to IPFIX Messages. The IPFIX Messages can then be exported into an
existing IPFIX infrastructure. The Mediation process from TinyIPFIX
to IPFIX is described inSection 7
<https://tools.ietf.org/html/draft-schmitt-ipfix-tiny-01#section-7>.
* Say, "In this deployment, The TinyIPFIX Smart Meters transmit ..." to make it
clear that this isn't a general requirement. Again it'd be good to flow the
figure vertically.
* The figure 3 title is wrong. Perhaps it should say "TinyIPFIX Mediation".
6. TinyIPFIX Message Format
A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header,
followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be
any of the possible two types: TinyIPFIX Template Set and TinyIPFIX
Data Set. A TinyIPFIX Message MUST only contain one type of
TinyIPFIX Set. The format of the TinyIPFIX Message is shown in
Figure 4
* s/any/either/
* missing period in the last line.
Figure 5: This figure has been incorrectly copied from Figure F in RFC 7011.
The numbering is offset, and the figure is one bit short:
Figure 5:
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 Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Whereas Figure F in RFC7011:
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 Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below Figure 5:
TinyIPFIX introduces a TinyIPFIX Message Header that
has a smaller size. The TinyIPFIX header consists of a fixed part of
three octets and a variable length "Remaining Header" as shown in
Figure 6.
* The division into two parts is important, but unclear from Figure 6.
* s/Remaining/Variable/
* It would be better to say, "The TinyIPFIX header consists of a fixed part of
three octets as shown in Figure 6, followed by a variable part as shown in
Figures 7 through 10 below.
Figures 6 - 10:
* These are 16 bits wide and double-spaced, making them inconsistent with
Figure 5, 11, 13, 14, and all the IPFIX figures. To avoid confusion, it'd be
better to format these as 32 bits wide.
* The existing numbering is from 00 to 16, implying that the figures are 17
bits wide.
* Redraw these consistently with existing IPFIX figures, eg:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|E| SetID | Length | Sequence |
|1|2| Lookup| | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the Fixed Part of the TinyIPFIX Message header
Figure 6: note the change in title (above), since the existing figure only
describes the TinyIPFIX Message header Format in a specific circumstance (ie,
when E1 = E2 = 1, per Figure 10).
Thefirst part has a fixed length ofthre octets and consists of the
"E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field
(4 bit), the "Length" field (10 bit), and the "Sequence Number" field
(8 bit). Thesecond part (the "Remaining Header") has a variable
length. Its length is defined by the "E1" and "E2"field in the
fixed headerpart. The four variants are illustrated in the figures
below.
* s/bit/bits/
* "The fixed part has a length of three octets and consists of the "E1" field
(1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4 bits), the
"Length" field (10 bits), and the "Sequence Number" field (8 bits). The
variable part has a variable length defined by the "E1" and "E2" fields in the
fixed header. The four variants are illustrated in Figures 7, 8, 9, and 10
below."
Figure 10:
Since E1 controls the Ext. SetID field and E2 controls the Ext. Sequence Number
field, and since E1 comes ahead of E2, the fields in Figure 10 should logically
be Ext. Sequence Number followed by Ext. SetID.
E1 and E2
The bits marked "E1" and "E2" control the presence of thefile
"Ext. SetID" and the length of the field "Ext. Sequence Number"
respectively.
* s/file/field/
* It's not "the length of the field" that's being controlled, but its presence.
* Please break out the following four cases into separate paragraphs for easier
reading:
In case E1 = E2 = 0 the TinyIPFIX message header
has the formatas shown in Figure 7. No Ext. Sequence Number and
Ext. SetIDare required.
* "has the format shown" or, "is formatted as shown"
* Not only are the fields "not required", they MUST NOT be present.
In case E1 = 1, custom SetIDs can be
specified in the extended SetID field (cf. Figure 8.) When
evaluated, the value specified in the extended SetID field is
shifted left by 8 bits to prevent collisions with the reserved
SetIDs 0-255. To reference these, shifting can be disabled by
setting all SetID lookup bits to 1.
* "When E1 = 1, the extended SetID field MUST be present. Custom SetIDs can be
specified in this field"
* Append: "setting all SetID lookup bits to 1 (see "SetID Lookup" below)."
Depending on the application
sampling rates might be larger than in typicalWSNs and, thus,
they may have a large quantity of records per packet. In order to
make TinyIPFIX applicable for those cases E2 = 1 is set (cf.
Figure 9.) This means the Ext. Sequence Number field is available
offering 8-bit more sequence numbers as usual.
* WSN is not defined.
* s/is available/MUST be present/, or "In this case the Extended Sequence
Number field MUST be present ..."
* Don't write contractions such as "Ext." in the text. There's plenty of room
to spell things out. Many readers may not have English as a first language, so
make it as easy as possible for them to understand.
Depending on the
WSN settings the also the combination E1 = E2 = 1 is possible
resulting in the maximum TinyIPFIX Message header shown in
Figure10where Ext. Sequence Number field and Ext. SetID field are
required.
* s/are required/MUST both be present/
* Spell out Ext. in full.
SetID Lookup
This field acts as a lookup field for the SetIDs and provides
shortcuts to often used SetIDs.So far only four values are
defined: Value = 0 meansLookup extended SetID field,Shifting
enabled. Value = 1 means SetID = 2 and message contains a
Template definition. Value = 2 means SetID = 256 and message
containts Data Record for Template 256. This places special
importance on a single template ID, but since most sensor nodes
only define a single template directly after booting and continue
to stream data with this template ID during the whole session
lifetime, this shorthand is useful for this case. Value = 3-14
means SetIDs are reserved for future extensions. Value = 15 means
Lookup extended SetID field,shiftig enabled.
* If this becomes an RFC, in 25 years time "so far" won't make sense.
* This should be an IPFIX sub-registry (with the associated IANA action) so the
list can be extended in future.
* Please split out the values into separate paragraphs so they're easy to pick
out visually.
* De-capitalise "Lookup" and "Shifting".
Since TinyIPFIX packets are always transported via a network
protocol, which specifies the source of the packet, the "Observation
Domain" can be equated with the source of a TinyIPFIX packetand the field
can be dropped from the header.
* "can be" sounds like it's optional. "Therefore this IPFIX field has been
removed from the TinyIPFIX header".
Should applications require
several Observation Domains the information can be included in the
TinyIPFIX data message.
* How would that be done? I'd like to see an example.
The version field has been dropped since the
SetID lookup field provides room for future extensions.
* "The IPFIX version field has been removed ..."
The
specification of a 32 bit time stamp in seconds would require the
time synchronization across a wireless sensor network and produces
too much overhead. Thus, the "Export Time" field is dropped. If
applications should require the specification of time it can be sent
as part of the TinyIPFIX data message.
* s/is dropped/has been removed/
* Since records are transmitted unreliably, it would be a good idea to
recommend inclusion of an observationTime* field per record.
6.2. TinyIPFIX Set
A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data
Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set
can either be a TinyIPFIX Template Set or a TinyIPFIX Data Set.
Every TinyIPFIX Setis started with a TinyIPFIX Set Header and is
followed by one or more TinyIPFIX Records.
* s/is started/starts/
Figure 11: the numbering is offset and incorrectly indicates 17 bits. It should
be numbered from 00 to 15 like so:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tiny Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TinyIPFIX Set Header
* The meaning of "Comp." in "Comp. Set ID" is never stated. There's no need for
it, so remove it. * Or, call it the "Tiny Set ID".
The "TinyIPFIX Set ID" (Comp. Set ID) identifies the type of data
that is transported in the TinyIPFIX Set. A TinyIPFIX Template
Set is identified by TinyIPFIX Set ID 2.This corresponds to the Set IDs
that are used by Sets in IPFIX. TinyIPFIX Set ID number 3 MUST NOT be
used. All values from 4 to 127 are reserved for future use. Values
above 127 are used for TinyIPFIX Data Sets.
* "This corresponds to the Template Set ID that is used by IPFIX [RFC7011]."
* Say why Set ID 3 must not be used. To avoid an interoperability loophole, say
what a collector should do if it's received.
Figure 13: the numbering is offset and incorrectly indicates 17 bits. It should
be numbered from 00 to 15 like so:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* The meaning of "Comp." in "Comp. Temp ID" is never stated. There's no need
for it, so remove it.
8. Template Management
As with IPFIX, TinyIPFIX templates management depends on the
transport protocol used. If TCP or SCTP is used, it can be ensured
that TinyIPFIX Templates are delivered reliably. If UDP is used,
reliability cannot be guaranteed, and template loss can occur. If a
Template is lost on its way to the Collector,all following TinyIPFIX
Data Records that refer to this TinyIPFIX Template cannot be decoded.
* "all the following".
Template withdrawals are not supported in TinyIPFIX. This is
generally not a problem, because most sensor nodes only define a
single template directly after booting.
* Template withdrawal should be available within the same constraints as IPFIX,
ie not over UDP.
* If "most sensor nodes only define a single template directly after booting",
and that's a standard template (ie, invariant across devices) then there's a
huge opportunity for to reduce the protocol overhead and increase reliability
by eliminating transmission of standard templates. ie, allow the exporter and
collector to pre-share the template definitions. See
draft-aitken-ipfix-pre-defined-templates.
6.4. Field Specifier Format
The following text has been copied from
[RFC7101 <https://tools.ietf.org/html/rfc7101>] for completeness.
* No, the text has not been copied directly - an important modification has
been inserted which could easily be overlooked if the above statement was taken
at face value.
Field Length
The length of the corresponding encoded Information Element, in
octets. Refer to [RFC7012 <https://tools.ietf.org/html/rfc7012>].The
value 65535 is illegal as there are no variable size encoded elements as
they are defined in IPFIX.
* Say "The value 65535 is illegal in TinyIPFIX" and explain why.
7. TinyIPFIX Mediation
There are two types of TinyIPFIX Intermediate Processes. The first
one can occur on the transition between aconstraint 6LoWPAN and the
non-constrained network. This mediation changes the network and
transport protocol from 6LowPAN/UDP to IP/(SCTP|TCP|UDP) and is shown
in Figure 16.
* "constrained".
* It might not be a 6LowPAN network.
* It might not be using UDP.
Figures 16 and 17:
* Remove "S.M." because the Exporting Process could be in other kinds of
devices too. SM is just one example. * Remove "6LowPAN" because the TI protocol
is applicable to other kinds of network too. * Remove "UDP" because TCP and
SCTP are also possible. * Remove "(1)". * All that's left is generic protocol
translation?
Templates MUST be managed the same way as in theconstraint
environment
* "constrained"
This mediation can also be performed by an IPFIX Collector before
parsing the IPFIX message as shown in Figure 18. There is no need
for aTinyIPFIX IPFIX parser if such a mediation process can be
employed in front of analready existing IPFIX collector.
* What is a "TinyIPFIX IPFIX parser" ?
* remove "already".
Figure 18: Remove (1).
The TinyIPFIX Mediation Process has to translate the TinyIPFIX
Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template
Record Header into their counterparts inIPFIX Afterwards, the new
IPFIX Message Length needs to be calculated and inserted into the
IPFIX Message header.
* Missing period in "IPFIX Afterwards".
7.1. Expanding the Message header
The fields of the IPFIX Message Header that are shown in Figure 5can be
determined as follows:
* "can be determined from a TinyIPFIX Message Header as follows".
Export Time
If the "Export Time" in the TinyIPFIX Message Header has a length of 4 octets,
the value from the TinyIPFIX Message Header MUST be used for the IPFIX Message
Header. If it was omitted, the "Export Time" MUST be generated by the Mediator.
Per section 6.1, the "Export Time" field is dropped - so the Export Time MUST
be generated by the Mediator.
If the IPFIX Message is
exported again, the "Export Time" field MUST contain the time in
seconds since 0000 UTC Jan 1, 1970,at which the IPFIX Message leaves the
Exporter. If the Message is passed to an IPFIX Collector for decoding
directly, the "Export Time" field is the time in seconds since 0000 UTC
Jan 1 1970 at which the TinyIPFIX Message has been received by the
TinyIPFIX Exporter.
It would be more useful if the "Export Time" field was always the time ... at
which the TinyIPFIX Message has been received by the TinyIPFIX Exporter.
Updating to the current time loses some information.
Also, consider if both cases are true: the Mediator converts received TinyIPFIX
into IPFIX and provides the data to a local Collector - and also re-exports the
data to a remote backup collector. This would require updating the Export Time
field for the remote export, which could lead to inconsistencies between the
local and remote data (eg, if the collectors are aggregating hourly or daily
data, and the updated timestamp put the data into the next hour or next day).
7.2. Translating the Set Headers
Set ID
The field needs to be expanded from one octet to two octets. If
the Set ID is below 128, no recalculation needs to be performed.
This is because all IDs below 128 are reserved for special
messages and match the IDs used in IPFIX. The TinyIPFIX Set IDs
starting with 128 identify TinyIPFIX Data Sets. Therefore, every
TinyIPFIX Set IDabove 127 needs to be incremented by 128 because
IPFIX Data Set IDs arelocated above 255.
* This is the same case, so use consistent terminology to avoid confusion.
* s/located/numbered/
Set Length
The field needs to be expanded from one octet to two octets. It
needs to be recalculated by adding a value of 2octet to match the
additional size of the Set Header. For each TinyIPFIX Template
Record that is contained in the TinyIPFIX Set, 2 more octets need
to be added to the length.
* "octets"
8.1. TCP / SCTP
If TCP or SCTP is anoption and can be used for the transmission of
* Better not to say "option" because it could be confused with IPFIX options.
eg, "If TCP or SCTP is used ..."
TinyIPFIX, Template Management MUST be performed as defined in
[RFC7101] for IPFIX, with the exception of template withdrawals,
which are not supported in TinyIPFIX. Template withdrawals MUST NOT
be sent byTinyIPFIX exporters.
* If you must rule out template withdrawals, then explain why.
* Capitalise "Exporters" because its a defined term?
TinyIPFIX Templates are not expected to change over
time in TinyIPFIX. Hence, a TinyIPFIX Template that has been sent
once MAY NOT be withdrawn and MUST NOT expire.
* This begins to explain why template withdrawals are disallowed. Discuss this
earlier.
* Anyway, since templates are not expected to change, they should be pre-shared
- making template withdrawal impossible. See
draft-aitken-ipfix-pre-defined-templates.
As UDP is used, reliable transport of TinyIPFIX Templates cannot be
guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX Exporter
MUST expect TinyIPFIX Template loss. It MUST therefore re-send its
TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re-
send after a fixed number of N TinyIPFIX Messages that contained
TinyIPFIX Data Sets that referred to this TinyIPFIX Template.
* This whole issue would be avoided if the exporter and collector pre-shared
templates. See draft-aitken-ipfix-pre-defined-templates.
The
number N MUST be configured by the application developer.
* No, it should be configurable by the end user according to his tolerance for
data loss. One user may require 1:1 (ie, a template per message), where another
may want as few templates as possible to conserve bandwidth.
* Again, the issue can be avoided entirely if the exporter and collector
pre-shared templates.
- - - - -