6TSCH Webex
description
Transcript of 6TSCH Webex
![Page 1: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/1.jpg)
6TSCH Webex
06/21/2013
![Page 2: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/2.jpg)
Agenda
• draft-thubert-6tsch-architecture-02 [5min]• draft-vilajosana-6tsch-basic-00 [10min]• Architecture with remote BBR [10min]• Soft cell assignment: random or not?[20min]• Track IDs [10min]• AOB [5min]
![Page 3: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/3.jpg)
draft-thubert-6tsch-architecture-02
Not published yet
![Page 4: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/4.jpg)
Centralized vs. Distributed Routing
6TSCH supports a mix model of centralized routes that are computed by
a Path Computation Entity and distributed routes that are computed by
RPL over a common physical LLN.
Both RPL and the PCE may inject routes in the Routing Tables of the
6TSCH routers. In either case, each route is associated with a
topology that is indexed by an instanceID, as defined in RPL
[RFC6550]. RPL and PCE rely on shared sources to define Global and
Local InstanceIDs.
It is possible for RPL and PCE to share a same topology, in which
case the PCE routes have precedence over RPL routes in case of a
conflict.
Inside the 6TSCH domain, the flow label is used to indicate the
topology that must be used for routing and the associated Routing
Tables as discussed in [I-D.thubert-roll-flow-label].
![Page 5: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/5.jpg)
Tunnel Mode In tunnel mode, the frames originate from an arbitrary protocol over
a compatible MAC that may or may not be perfectly synchronized with
the 6TSCH network. An example of this would be a router with a dual
radio that is capable to receive and send Wireless HART or ISA100.11a
frames with the second radio, by presenting itself as an Access Point
or a Backbone Router, respectively.
In that mode, the PCE may coordinate with a WiHART Network Manager or
an ISA100.11a System Manager in order to specify the flows that are
to be transported transparently over the Track.
![Page 6: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/6.jpg)
Tunnel Mode
+--------------+
| IPv6 |
+--------------+
| 6LoWPAN HC |
+--------------+ set restore
| 6TUS | +dmac+ +dmac+
+--------------+ | | | |
| TSCH MAC | | | | |
+--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ | ingress egress |
| |
+--------------+ | |
| LLN PHY | | |
+--------------+ | |
| TSCH MAC | | |
+--------------+ | |
|ISA100/WiHART | | v
+--------------+
![Page 7: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/7.jpg)
Tunnel Mode
In that case, the flow information that identifies the Track is
uniquely derived from the information at the receiving end, for
instance the incoming Timeslots, or an ISA100.11a ContractId. At the
ingress 6TSCH router, the packet destination is recognized as self
but the flow information indicates that the frame must be tunneled
over a particular 6TUS Track so the packet is not punted to upper
layer. Instead, it is passed to the 6TUS sublayer for switching.
The 6TUS sublayer in the ingress router overrides the destination MAC
to broadcast and forwards.
At the egress 6TUS router, the reverse operation occurs. Based on
metadata associated to the Track, the frame is passed to the
appropriate link layer with the destination MAC restored.
![Page 8: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/8.jpg)
Transport Mode
| ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | |
+--------------+ ingress egress
| 6TUS | sets +----+ +----+ restores
+--------------+ dmac to | | | | dmac to
| TSCH MAC | brdcst | | | | self
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
![Page 9: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/9.jpg)
draft-vilajosana-6tsch-basic-00
![Page 10: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/10.jpg)
Status
• Follow-up on webex discussion on 06/07/2013
• Published on 06/19/2013
• http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-00
• Same ideas as discussed over the phone
• Comments welcome!
![Page 11: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/11.jpg)
Architecture with remote BBR
![Page 12: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/12.jpg)
Current Architecture ---+------------------------ | External Network | +-----+ +-----+ | | Router | | PCE | | | | +-----+ +-----+ | | | Subnet Backbone | +--------------------+------------------+ | | | +-----+ +-----+ +-----+ | | Backbone | | Backbone | | Backbone o | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o LLN o o o o o o o o o o o o o o o o
?
Remote BBR
![Page 13: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/13.jpg)
Tunneling/VLAN ---+------------------------ | External Network | +-----+ +-----+ | | Router | | PCE | | | | +-----+ +-----+ | | | Subnet Backbone | ========== +--------------------+-------------- TUNNEL ----+ | | ========== | +-----+ +-----+ +-----+ (remote) | | Backbone | | Backbone | | Backbone o | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o LLN o o o o o o o o o o o o o o o
![Page 14: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/14.jpg)
PCE as forwarding engine --------------+------------------- | External Network | +-----+ | | PCE/Router | | +-----+ ^ ^ ^ | | | +---------------+ | +----------------+ | | | v v v +-----+ +-----+ +-----+ | | Backbone | | Backbone | | Backbone o | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o LLN o o o o o o o o o o o o o o o o
Protocol?
![Page 15: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/15.jpg)
Hybrid ---+----------------------- | External Network | +-----+ +-----+ | | Router | | PCE | | +--| | +-----+ | +-----+ | | ^ ^ ^ | | | | | ------------------------ | | | | | | | | | +---------------+ | +----------------+ | | | v v v +-----+ +-----+ +-----+ | | Backbone | | Backbone | | Backbone o | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o LLN o o o o o o o o o o o o o o o o
![Page 16: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/16.jpg)
Question
• PCE, ND must be maintained as separate elements
• 6TSCH does not need to define anything to create the connectivity between the BBRs
• Discovery?
![Page 17: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/17.jpg)
soft cell assignment: random or not?
![Page 18: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/18.jpg)
Problem
• Applies to distributed scheduling only• Two neighbor nodes negotiate the allocation of a
cell in the schedule• If this cell already used by other nodes in the
neighborhood collision• Options:
– random allocation. Collisions unlikely. Detect and fix collisions
– Informed allocation. Neighbors maintain state. Collisions less likely. Still detect and fix (less frequent) collisions.
![Page 19: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/19.jpg)
![Page 20: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/20.jpg)
Collision probability
• 10 node neighborhood• Each node sends 3 pk/s• 101 cells• 16 channels• Random cell allocation• Collision detection
Collision occurrence? Collapse?Overhead of re-negotiation?Overhead maintaining state?
![Page 21: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/21.jpg)
Informed allocation
• exchanging the changes in a node’s cell usages bitmap instead of reporting all cell usage bitmap periodically
• Approaches:– Active– Passive– Hybrid
![Page 22: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/22.jpg)
Using Trickle
• RFC6206, used in RPL• To use Trickle, we need to define
– What constitutes a "consistent" transmission.– What constitutes an "inconsistent" transmission.– What "events", if any -- besides inconsistent
transmissions -- reset the Trickle timer.– What information a node transmits in Trickle
messages.– What actions outside the algorithm the protocol takes,
if any, when it detects an inconsistency.
![Page 23: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/23.jpg)
Using track IDs
![Page 24: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/24.jpg)
Proposal
• Use a TrackID to associate incoming cells and outgoing cells
• TrackID is internal only, i.e. is does not appear in the packets
• Add TrackID to cell commands
• Track (switching) table using trackID
• Schedule is union of all track tables
![Page 25: 6TSCH Webex](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814e5e550346895dbbfd75/html5/thumbnails/25.jpg)
Any Other Business?