Re: [lp-wan] Architecture

["Pascal Thubert (pthubert)" <[e-mail]>]

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.
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.
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.
"

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 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.

"

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