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

Wiki

Clone wiki

meetings / 130503_webex

View History

Minutes Webex 03 May 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes

  1. Xavi Vilajosana
  2. Thomas Watteyne

Present (alphabetically)

  1. Alfredo Grieco
  2. Dominique Barthel
  3. Guillaume Gaillard
  4. Maria Rita Palattella
  5. Pascal Thubert
  6. Raghuram Sudhaakar
  7. Robert Assimiti
  8. Thomas Watteyne
  9. Tina Tsou
  10. Tom Phinney
  11. Xavi Vilajosana
  12. Yoshihiro Obha

Recording

Slides

Agenda

  • update charter: security paragraph [5min]
  • link / peering management [10min]
  • 6TUS building blocks [10min]
  • Centralized routing building blocks [10min]
  • distributed routing building blocks [10min]
  • Wireless ND [10min]

Minutes

  • [08.06] Security. [Yoshihiro]
    • updated paragraph. PANA was mentioned explicitly in the previous version of the charter. Rene Struik commented that until the requirements are clear, we should not be identifting specific solutions. The PANA was therefore removed from the charter.
    • working on the security draft, identifying requirements
    • [Pascal] new interesting discussion started on the mailing list about security between PCE and PCC. Needs to be taken into account in security document.
    • Action Item Yoshihiro to identify scope of this discussion and include in security draft.
  • [08.07] Building block in the architecture draft [Pascal]
    • Goal: have a discussion to better understand what is in the different building blocks, to better understand what the scope of the group's work is.
    • Pascal presents the slide which shows stack and highlights what we have identified.
    • Peering
      • how nodes discover peers and maintain links
      • Bidirectional reachability needed
      • metrics for evaluation
      • rpl does not address this particularly, but since we are doing lower layer with 6tus, we might want to do something
    • 6tus [Thomas]
      • scheduler: 6tus interfaces to TSCH.
      • GMPLS function: the cell you receive a packet on can be enough information to allow you to switch it to a different cell without having to invoke the routing protocol.
      • slot negocation protocol between neighbors
      • Discussion
        • [Thomas] Where does the mapping-of-to-track happen?
        • [Pascal] Part of the scheduler.
        • [Pascal] We might have to remove the term "scheduler", or at least the separate what puts data on a track, from what puts it on a cell.
    • Centralize Routing
      • Identifying sub-blocks [Pascal]:
        • the way the tracks are computed is not in the standard, do we want to describe anything?
        • Protocol to request a computation. PCEP. Maybe but some parts are missing.
        • Protocol (normally inherited from a link state protocol) to advertise the peerings and metrics to the PCE (PCC to PCE). Devices should already understand RFC6551 so we can reuse those metrics.
        • Protocol to validate a track (OAM frames).
        • Pascal presents slides to highlight different approaches for the PCE to installing a track:
          • V1: the PCE talks to each node on the track individually
          • V2: the PCE talks to the source, which uses a separate protocol to install the resources.
            • Thomas how does the PCE know that the track was installed correctly? easier on V1. Also easier to maintain.
          • OAM link: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview. Very used in MPLS environment.
          • [Thomas,Pascal,Yoshihiro] The PCC-PCE communication should be authenticated and maybe even encrypted.
          • [Pascal] Maybe have a PCEP at BBR so authentication would be between device and root. Between root and PCE can be over BB, without note intervention.
      • overview of PCEP [Thomas]
        • Thanks for Maria Rita who is leading this work
        • PCEP protocol: RFC5440 - 2009
        • Communication between client (PCC==node or mote) and PCE.
        • PCC ask for path computation to the PCE. PCReq. Indicates all requirements.
        • PCEP is open and easy to extend.
        • PCE answers with PCResp.
        • Out of scope:
          • how the PCE calculates the track. From discussion, looks like we agree with this.
          • how L2 resource are installed on the nodes along a track
          • how the PCE learns about the network (topology, traffic requirements)
          • Rather small subset of what we want to do.
        • TCP port 4189
        • nothing critical that prevents to use UDP/CoAP instead of TCP
        • multiple PCEs supported per mote
        • TCP sessions can be open/close at each requests, or stay open long term
        • PCEP comes with a PCEP-specific keepalive mechanism.
        • PCEP defines 7 different types of packets
        • Discussion:
          • [Pascal] Like DHCP, PCEP could use a router as a relay. That is, authentication and knowledge of the PCE is hidden from the node. One of the function of the BBR could d be to relay communication between node and PCE. Authentication and discovery would be handled by the BBR. For Yoshihiro to consider to save some burden.
          • [Yoshihiro] architecture clearer now. Does PCEP define a relay?
          • [Pascal] not to my knowledge. architecture clearer now. We could have CoAP to BRR, and have BBR handle TCP.
    • Distributed routing
      • RPL
        • no major changes required. Probably just some work on the OF.
      • reservation part
      • Pascal goes over overview of installing a /64 route
        • Single subnet (/64) model for the backbone and the LLNs
        • DAOs go from motes to BBR. Host routes (/128) are installed.
        • Reservation protocol (considering RSVP). We will install switching states. No optimization the paths. Even if we do RSVP and determinism, we don't have shortes path. We can not do distributed reservation across the LLNs.
        • discussion
          • [Thomas] we could have a single DODAG with virtual roots
          • [Pascal] sure, but RPL does not guarantee any for of optimization.
      • RSVP/NSIS [Xavi]
        • try to understand whether RSVP/NSIS are applicable
        • both are UDP. So easier to adapt. point-to-point reservation. Allow for maintenance.
        • NSIS define lots of QoS metrics, but are extensible
        • reservation can start from source or end node, or from a different node.
        • provides hop-by-hop state installation: with only one request, I can install all requirements on all nodes along a track
        • ideally, we use this protocol to install PCE information. Then we don't need to implement both or mix, or solve cross-protocol issues.
        • [Thomas] interesting point. If we use same protocol for PCE-to-node and node-to-node, will make things much simpler.
        • [Pascal] RSVP is usually always over raw IP rather than UDP.
    • wireless ND (WiND)
      • people used "WiND"
      • 6LoWPAN-ND is the first step
      • subblocks:
        • registration and DAD
        • resolution: Pascal presents 2 slides illustrating the 2-step registration process.
        • we need to assist 6MAN, who will probably be responsible for the bulk of the work
        • what is missing from 6LoWPAN=ND:
          • sequence number to distinguish mobility from duplication
          • second model: no NS/NA or proxy ND on the backbone, but directly run RPL on the BB. RPL is the only protocol which would support this, since it has TID.
    • Discussion
      • Next steps [Pascal]:
        • spin new version of the architecture
        • review the charter to make things more explicit about the building block. E.g. peering, maintenance (OAM).
      • Unclear the model of different protocols for reservation, PCEP vs NSIS [Thomas].
        • [Pascal] We need to explicitly say at the BoF what work is in front of us. Must be listed as work items in charter. We could for example cut the 6tus work in multiple documents.
  • [08.50]
    • meeting ends

Updated