Subject: [6tsch] minutes WebEx 3 May 2013

From: Thomas Watteyne <[email-masked]>
Date: Mon, 6 May 2013 20:20:47 -0700

All,

You will find the minutes of the last webex below, and the presented slides
attached. Thanks to Xavi for taking notes!). Please fix anything I might
have missed directly in the e-mail and reply.

These minutes and slides are archived at
https://bitbucket.org/6tsch/meetings/wiki/130503_webex (with bold face and
italics!).

Thomas

PS: for some reason, these minutes are becoming longer and longer. Will try
to put the verbose level lower next time.

---

# Minutes Webex 05 May 2013, 6TSCH group #

Note: timestamps in PDT.

Taking notes
------------

1. Xavi Vilajosana
2. Thomas Watteyne

Present (alphabetically)
------------------------

* Alfredo Grieco
* Dominique Barthel
* Guillaume Gaillard
* Maria Rita Palattella
* Pascal Thubert
* Raghuram Sudhaakar
* Robert Assimiti
* Thomas Watteyne
* Tina Tsou
* Tom Phinney
* Xavi Vilajosana
* Yoshihiro Obha

Recording
---------

* Webex recording (audio+slides,streaming)
*
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=67971312&rKey=0cbbd37855fabc7a
[47min]

Slides
------

* [slides_130503_webex.ppt](
https://bitbucket.org/6tsch/meetings/src/602148a945a44a81286fcc56de867a3103ccf72a/130503_webex/slides_130503_webex.ppt?at=master):
slides shared during the call

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