Re: [lp-wan] Architecture

[Carles Gomez Montenegro <[e-mail]>]

Hi Pascal,

Thanks for the proposed text!

Please find below my inline comments:

> OK, so let me propose some text here:
>
> 1) In the endpoints section, change to
>
> "
> Typically, an LPWAN network topology is star-oriented, which means that
> all
> packets between the same source-destination pair follow the same path
> from/to a
> central point. In that model, highly constrained Devices (Dev) exchange
> information with LPWAN Application Servers (App) through a central
> Network
> Gateway (NGW), which can be powered and is typically a lot less
> constrained than
> the Devices.
> Because Devices embed built-in applications, the traffic flows to be
> compressed
> are known in advance and the location of the C/D and F/R functions
> (e.g., at the Dev and NGW), and the associated rules, can be pre
> provisioned
>  in the system before use.
>
> The SCHC operation requires a shared sense of which SCHC Device is uplink
> and
> which is downlink.

I am a bit concerned about the use of "uplink" and "downlink" in this text.

RFC 8724 defines "Uplink" and "Downlink", and while they are related with
what I understand is meant in your proposed text (and while I agree with
the intent of the text), they are not exactly the same.

Why don't we just use "Dev" and "App", which are the terms defined already
in RFC 8376 and reused in RFC 8724?

> In a star deployment, the hub is always considered uplink and the spokes
> are
> downlink. The expectation is that the hub and spoke derive knowledge of
> their
> role from the network configuration and SCHC does not need to signal which
> is
> hub thus uplink vs. which is spoke thus downlink. In other words, the
> link
> direction is determined from extrinsic properties, and is not advertised
> in the
> protocol.
>
> Nevertheless, SCHC is very generic and its applicability is not limited
> to
> star-oriented deployments and/or to use cases where applications are very
> static
> and the state provisioned in advance.

Note, just for info: the current proposal/assumption for the updated SCHC
HC over 802.15.4 draft (to be submitted soon) is that applications and
state can be provisioned in advance.

> In particular, a peer-to-peer (P2P) SCHC Instance (see {{Instances}}) may
> be set
> up between peers of equivalent capabilities, and the link direction cannot
> be
> inferred, either from the network topology nor from the device
> capability.
> In that case, by convention, the device that initiates the SCHC Instance
> is considered downlink. This convention can be reversed, e.g., by
> configuration,
> but for proper SCHC operation, it is required that the method used ensures
> that
> both ends are aware of their role, and then again this determination is
> based
> on extrinsic properties.
> "

I like the idea of having a default behavior as expressed in the paragraph
above, e.g. for cases where there is no star topology and/or
applications/state cannot be provisioned in advance.

However, I was wondering: how is the SCHC Instance initiated? Is it
initiated by the device that transmits first? If yes, what happens if that
transmission (from, say, node A) is not received by the other endpoint
(node B), but then node B successfully transmits to node A?  Does node A
still believe that it was the initiator?

> And
> 2) add a new section on SCHC Instances like:
>
>
> "
> RFC8724 defines a protocol operation between a pair of peers. A session
> called a SCHC Instance is established and SCHC maintains a state and
> timers
> associated to that Instance.
>
> When the SCHC Device is a highly constrained unit, there is typically only
> one
> Instance for that Device, and all the traffic from and to the device is
> exchanged with the same Network Gateway. All the traffic can thus be
> implicitly
> associated with the single Instance that the device supports, and the
> Device
> does not need to manipulate the concept.
>
> For that reason, SCHC avoids to
> signal
> explicitly the Instance identification in its data packets.
>
> The Network Gateway, on the other hand, maintains multiple Instances, one
> per
> SCHC Device. The Instance is derived from the lower layer, typically the
> source
> of an incoming SCHC packet. The Instance is used in particular to select
> from
> the rule database the set of rules that apply to the SCHC Device, and the
> current state of their exchange, e.g., timers and previous fragments.
>
> This architecture

Perhaps s/architecture/architecture document

> generalizes the model to any kind of peers. In the case
> of
> more capable devices, a SCHC Device may maintain more than one Instance
> with the
> same peer, or a set of different peers.
> Since SCHC does not signal the Instance in its packets, the information
> must be
> derived from a lower layer point to point information.
> For instance, the SCHC session can be associated one-to-one with a tunnel,
> a TLS
> session, or a TCP or a PPP connection.
>
> For instance, <!-- existing text on SCHC o PPP here)
>
> In that case, the SCHC Instance is derived from the PPP connection. This
> means that there can be only one Instance per PPP connection, and that all
> the
> flow and only the flow of that Instance is exchanged within the PPP
> connection.

Thanks again for the proposed text, and let's hope we can converge soon!

Cheers,

Carles


> "
> I staged at the git, ready to publish...
>
> Works?
>
> Pascal
>
>
>> -----Original Message-----
>> From: Pascal Thubert (pthubert)
>> Sent: mercredi 29 juin 2022 16:53
>> To: 'Carles Gomez Montenegro' <[e-mail]>; Laurent Toutain
>> <[e-mail]>
>> Cc: lp-wan <[e-mail]>
>> Subject: RE: [lp-wan] Architecture
>>
>> Agreed 😊
>>
>> We need to republish a version of the architecture. Maybe I can add that
>> the
>> topologies are covered and that in Hub and Spoke the hub in uplink?
>> Then for a P2P, one end has to be declared uplink. Typically a session
>> is
>> formed by one node calling the other e.g., establishing a SCHC session
>> over
>> P2P.
>> Could we define that the caller is downlink and the called party is
>> uplink?
>> This was we'd abstain from impacting SCHC itself. The determination of
>> up and
>> down is needed but external to the protocol.
>>
>> What do you guys think?
>>
>> Pascal
>>
>> > -----Original Message-----
>> > From: lp-wan <[e-mail]> On Behalf Of Carles Gomez
>> > Montenegro
>> > Sent: mardi 28 juin 2022 18:35
>> > To: Laurent Toutain <[e-mail]>
>> > Cc: lp-wan <[e-mail]>
>> > Subject: Re: [lp-wan] Architecture
>> >
>> > Hi Laurent,
>> >
>> > Thanks a lot for bringing up this topic!
>> >
>> > Please find below some inline comments:
>> >
>> > <snip>
>> >
>> > > Carles raised the need to study a more generic approach for mesh
>> > > network where the notion of device and SCHC core do not exists
>> > > anymore and rules are more an association between a device and a
>> > > core. This may be solved by identifying the set of rules by a device
>> ID
>> and a core ID.
>> >
>> > I think your proposal is equivalent to determining which is the role
>> > (Dev or
>> > App) of each endpoint for a given Rule.
>> >
>> > In fact, we will soon submit a revised version of
>> > draft-gomez-6lo-schc- 15dot4-02. In -03, the idea to address the
>> > Dev/App problem (i.e., which is the Dev or App role of a node in a
>> > mesh or peer-to-peer network) is simply to stick to what we called
>> > Option 1 in IETF 113 (i.e., sticking to the RFC 8724
>> > terms) and define/configure beforehand who will be Dev and who will
>> be
>> > App when a Rule is written (since the Rule is written beforehand
>> anyway).
>> >
>> > So I understand that we are aligned!
>> >
>> > <snip>
>> >
>> > > In my opinion, we should specify on the architecture document, a
>> > > more generic model covering PPP, star and mesh and also more
>> > > precisely the interaction between them. From that, we will be able
>> > > to define an augmentation of the basic data model.
>> >
>> > I was thinking the same. The architecture document needs to cover all
>> > these topologies.
>> >
>> > > The way we include a mesh model with SCHC can be an interesting
>> > > thing to investigate during the hackathon.
>> >
>> > Cool! :)
>> >
>> > Cheers,
>> >
>> > Carles
>> >
>> >
>> > > See you,
>> > >
>> > > Laurent
>> > > _______________________________________________
>> > > lp-wan mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/lp-wan
>> > >
>> >
>> >
>> > _______________________________________________
>> > lp-wan mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/lp-wan
>