1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 130412_webex

View History

Minutes Webex 12 April 2013, 6TSCH group

Note: timestamps in PDT.

Present (alphabetically)

  1. Thomas Watteyne
  2. Pascal Thubert
  3. Alfredo Grieco
  4. Adrian Farrel
  5. Herman Storey
  6. Maria Rita Palattella
  7. Ted Lemon
  8. Tina Tsou
  9. Tom Phinney
  10. Xavi Vilajosana
  11. Yoshihiro Obha
  12. Dominique Barthel
  13. Gennaro Boggia

Recording

Slides

  • 130412_slides_webex.pptx: slides shared during the call

Agenda

  • update work on PANA [Yoshihiro] [5min]
  • Conclude work on NSIS [Xavi] [5min]
  • Review / finalize archi 01 [Pascal] [5min]
  • discuss charter [Thomas, all] [45min]

Minutes

  • [08.02] meeting starts
  • [08.02] Context Pascal to Ted
    • Ted no opinion whether routing or internet area applies best for 6TSCH, but willing to help 6TSCH get IESG aware. Decision on whether Ted or Adrian can be taken later.
  • [08.05] Pascal presents agenda
  • [08.06] update work on PANA [Yoshihiro]
    • work on-going
    • 6 contributors
    • agreed on TOC
    • start analyzing gap
    • 3 phase for key management
    • discussion
      • [Pascal] From gap analysis, can we use existing standards?
      • [Yoshihiro] Depends on what requirements come up with. If need new, we need to discuss next steps. This document describes more the architecture.
      • [Pascal] If we end up needing a new standard work, should be done in 6TSCH or in security area?
      • [Yoshihiro] Will depend on the requirements.
      • [Pascal] Will need to be open in the charter.
  • [08.12] Conclude work on NSIS [Xavi]
    • has been doing lots of reading on NSIS.
    • NSIS clear fit for distributed scheduling in 6TSCH.
    • Yet, heavy implementation, and lots of signaling overhead.
    • Not clear whether can be used directly for transporting PCE signaling.
    • [Thomas] Could PCEP not be used for PCE-to-motes communication?
    • [Xavi] Probably.
    • [Pascal] NSIS is veyu heavy.
    • [Pascal] not a big deal is need PCEP and RSVP since very lean.
    • [Xavi] John is looking at PCEP.
  • [08.19] update on draft-thubert-6tsch-architecture [Pascal]
    • Discussion hasn't moved much in last weeks
    • Yet we might want to incorporate DTLS and COAP
    • We not have a much clearer picture of the protocols, so we will be able to submit a new version of the draft.
    • [Thomas] When could this submission be?
    • [Pascal] Possibly immediately.
  • [08.23] discusion on draft charter [Thomas]
    • Thomas presents latest version of the draft charter
    • available at https://bitbucket.org/6tisch/charter-ietf-6tsch/src
    • outline very conventional.
    • First part of presenting IEE802.15.4e:
      • focuses on the tsch mode of the 15.4e
      • 6tsch is adaptation layer
      • support both distribute and centralized scheduling approaches
      • focuses on the scheduling of such networks.
    • [Pascal] Are we limited to IEEE802.15.4e? Can we imagine other macs/phy in the future?
    • [Thomas] goal is to avoid discussions about other MAC layers that are not related at all.
    • [Thomas] however tsch is the most wide representation of the kind of networks we want to address
    • 3 scheduling approaches:
      • centralized PCE: entity out the network and pushes the schedule to the network
      • distributed resource reservation: signaling protocol used to establish pipes between source and destination
      • best effort: bootstrap case. best effort traffic class. smallest configuration to be able to inter-operate.
    • Multiple backbone routers:
      • transit links.
      • scale devices in the same subnet-> layout a high speed backbone(RPL root, or 6LowPAN lbr), that is able to route to transit nodes which moved to another subnet.
      • backbone router, was presented in orlando meeting.
    • [Tom] add "diversity" together with jitter,latency, loss. Diversity needs to continue on the backbone as part of the routing.
    • [Thomas] absolutely, will do. Filed at https://bitbucket.org/6tisch/charter-ietf-6tsch/issue/1
    • Include architecture recommendation on how to deal with multiple BBR, how we aim to deal with synchronization, etc..
    • Coordination with IPSO,IoT6, ISA, IEEE. (assemble pieces from other groups).
    • [Herman] how to stablish a performance criteria on that networks. Specially for backbone. ISA100 differentiates between backhaul and backbone. What are the exact performance criteria which trigger a switch between the two cases?
    • [Pascal] Currently, there is no item (and requirement) for backhaul, just BB. No particular plans on neighbor discovery, routing over the backhaul.
    • [Herman] Difference between BB and BH imporant in ISA100. BH can be used e.g. for inter-continental communication. 60% of automation is done remotely.
    • [Thomas] We can have several good technocal discussions about how to split the management entity between close to the network and far. From an administrative point of view, let's add this case to the backbone work
    • [Pascal] Placing constraints in terms on latency. Let's move that constraint on the architecture.
    • work items
    • Thomas will proxy comments from Michael Richardson, who could not be at the webex.
    • list of work items:
      • 6tus layer: adaptation layer. Michael suggests that bootstraping is too generic. This suggestion is captured in https://bitbucket.org/6tisch/charter-ietf-6tsch/issue/2
      • Centralized management. presence of a PCE. define how the pce communicates to the network and how it extracts information from it.
      • distributed management. looking at NSIS and RSVP.
      • best effort: 6tsch minimal operation. No PCE nor Dist.SCheduling. Minimum set of things that can be done to stablish a minimal traffic support. Local reservation. Very minimal set of requirements. Initial setup of basic links.
      • 6tsch architecture. Put together all of pieces. Describing implementation, highlight differences of data flows.
      • TSCH overview: highlights of 15.4e tsch mode, and what is missing that 6TSCH needs to do.
    • Non-milestone work items:
      • implementors guide. sharing best practices of implementation.
      • coexistence: how 6tsch network can operate in the presence of similar TSCH (ISA100.11a,Whart). make cohexistence simpler. interoperability testing.
      • applicability statement. How it answer the requirements.
    • [Thomas] do we put security as a work item or do we integrate it on each work item?
    • [Pascal] Could be part of the architecture
    • [Tom] if security is everywhere put it at every work item.
    • [Thomas] Every document we generate needs to have a security section. We can create a separate work item in charter. Captured in https://bitbucket.org/6tisch/charter-ietf-6tsch/issue/3
    • Milestone dates:
      • too early for that, let's wait
    • [Pascal] What should be doing now thinking on the BOF in Berlin?
    • [Ted] Having the charter ready for Berlin is good.
    • [Adrian]
      • Instead of milestones and dates, put work items in chronological order better.
      • Work out what is missing, and clean up the drafts.
      • Work out what you want to do in the BoF. Plan the agenda. Describe the environment,etc. Do a good planning is what would help on the BoF acceptance.
      • You will get questions about deployment use cases. Why would people want to run IP on that particular IEEE networks. Rather than what could be done, answer what the needs are.
      • Good starting points:
  • [09.15] meeting ends

Updated