Minutes RL2N BOF - IETF-70 - Vancouver Thanks to Geoff Mulligan and Dominik for having taken the notes. Agenda ###### 1. Administrativia (Chairs, 5 min) [5] - Notes takers - Agenda bashing 2. Scoping the BOF (Chairs/ADs, 10 min) [15] - Motivation and problem statement presentation 3. RL2N Routing Requirements summary (several & chairs, 15 mn) [30] - draft-brandt-rl2n-home-routing-reqs-02 (Anders) - draft-pister-rl2n-indus-routing-reqs-00 (Kris) - draft-dohler-rl2n-urban-routing-reqs-00 (Hassnaa) 4. Protocol survey (Phil - 5 mn) [35] - draft-levis-rl2n-overview-protocols-02 5. Consensus and Charter discussion (15 mn) [50] - Consensus - Work Items/Milestones - Interaction with other WG (6lowpan) 6. Conclusion and next steps (10mn, chairs and ADs) [60] Minutes ####### 1. Agenda: No comment 2. Scoping the BOF (Chairs) David is talking about the BoF scope, background and problem space of routing over low power and lossy networks L2Ns, and relations to the 6lowpan group. BoF is scoped to define routing requirements, which will later be used to formulate a routing framework. The approach of the BoF is to produce a set of routreq docs for selected use cases, conducting a survey of existing protocols and to provide an architectural framework for routing in L2Ns [see slides] Wireless embedded networks New to IETF Enabled by CMOS radios Several industrial forums Desire for IETF to get involved to get IP running over these networks 6LoWPAN is the start Domain: Routing over Low Power and Lossy Networks Links of unpredictable quality Technology and problem space Low Power and Low transmission noisy links Industry has been working Industrial routing solutions IETF is making IP practical over these types of devices Need routing and multi -hop Problem Statement: Define routing requirements for specific application areas Formulate a routing framework Pay attention to routing security and manageability Approach: Produce routing requirement IDs for representative use cases Survey applicability of existing protocols Provide framework for routing metrics used in path calculations, distributed v. centralized hierarchy 3. RL2N Routing Requirements summary (several & chairs, 15 mn) [30] - draft-brandt-rl2n-home-routing-reqs-02 (Anders) - draft-pister-rl2n-indus-routing-reqs-00 (Kris) - draft-dohler-rl2n-urban-routing-reqs-00 (Hassnaa) Home Automation Routing Requirements (Anders) Devices in the home Remote control (only awake when operating), movement/smoke sensors (battery operated) and lamp modules (most stable) Home scenario routing issues short distances but multi-hop support for multi paths routing stability in 250ms neighbor discovery on frequent basis self-configuration is a MUST Industrial Automation (Kris) 60 million installed process control 4 million shipping per year HART - most popular single wired sensor network Wireless HART uses 802.15.4, multi-hop mesh networking SP100 wireless - adopted 6LoWPAN, but defining own routing,transport Wireless HART and SP100 are a hybrid of circuit and packet switched Examples of Data flows Low frequency data collection routing requirements link attribute aware routing new constraints on node lifetime and traffic highly scalable Urban networks (Hassnaa) trial roll-outs in french cities Network elements: sensors, actuators, repeaters and access points Peculiarities of Urban nets: huge number of field nodes, highly constrained, need correlated data readings, hightly directed info flow Routing requirements: CRITICAL - scalability, parameter constrained routing, security and autonomous functioning less important - bandwidth and latency must support - highly directed information flow, field devices with different MAC, multi/group/geo cast 4. Protocol survey (Phil - 5 mn) [35] - draft-levis-rl2n-overview-protocols-02 Phil Levis gives an overview over existing protocols and presents the goal of the BoF in adapting or creating new routing protocol(s) suited for R2Ls. Also he shows the most important reqs derived from the application IDs. [see slides] Applying routing to protocols in l2ns large spectrum of existing protocol L2Ns have new and psecific contraints Can we use existing protocols? Can we draw from others to define something new if needed? Requirements placed by application IDs: small footprint, flooding control, multipath routing, resource awareness, small mtu and multi-topology routing draft looks at each of those requirements important to consider the rate of link churn 5. Consensus and Charter discussion (Chairs-15 mn) [50] - Consensus - Work Items/Milestones - Interaction with other WG (6lowpan) Charter Consensus reached so far: informal work started about a year ago with a lot of off-line discussion (please use the list!) - 400 subscribers started with generic requirement ID but now more focused with application driven routing BOF scoping Pre-WG meeting held in Boston on Nov 15 Number of different types of attendees: vendors, service providers, end-users,. showing a large community of interest, which is needed for L2Ns. Large community of interest Collaboration of Industry, end users, vendors, service providers and academia. When we talked to outside companies Why did they define their own protocols - answer because there wasn't IP. They now want to work here and we see more and more interest from these companies to move to IP. WG conflicts are avoided as best as possible. ex: 6lowpan. so far companies didn't have good routing solutions, now they are interested in this work instead of old proprietary systems. [see slides] Charter work items: Produce use cases for Industrial, Connected Home, Building and urban application These drafts are already well fleshed out (their authors have been working on such systems for many years) Survey of applicability of existing protocols If we find an existing protocol that meets L2N's routing requirements, we are done If existing protocol needs extensions we will work with appropriate Working Group Specification of routing metrics - different from past, battery, ram, ... Architectural framework for routing - routing framework for end-ends, distributed or centralized approach, hierarchical structure / large scale sleepy networks These wireless protocols and routing must be self forming security framework These wireless are prone to routing attacks, thus a particular attention must be paid to security. Goals and milestones: April 2008 ready to submit all use case as informational - very aggressive but doable: some of docs are already fleshed out august 2008 - routing metrics and attributes November 2008 submit protocol survey Jan 2009 submit security framework Feb 2009 - submit routing architecture Joe Maeker> the MANET WG has a lot in ID database that adress scalability Recommend dig a bit deeper into prior ids that might have been down scoped JP> Agree. Interaction with other working groups 6lowpan routing requirments would come from 6lowpan and RL2N will define routing solution Other forums: Zigbee, ITU, Bluetooth What is out of scope? Other use cases such as military, healthcare, wild life Ian Chakres> AUTOCONF WG is looking at configuration with similar styled networks - provide input to them JP> Will do. This is what I had in mind when mentioning self-configuring networks. Joe Maeker> Good you scoped back - industrial v. urban might not allow for a single solution JP> Indeed, and we do not know yet, this is part of the work that has to be done. Lars Eggert> What kind of network are you building? You push IP ip into sensor network and build app right on top of that. Where is transport layer? Each application has to define TCP for themselves? We're missing a layer here. David> Good question. Nothing here should suggest there is no transport. We can't solve ALL problems in this WG. Lars> It's ok if transportation is handles in other way. There are interactions here. Mark Townsley> some of this is more in 6lowpan scope. Mikko Saarnivala> - Sensinode supports effort - they are a software vendor/hardware vendor David Ward> Is this v4 v6 or what? charter should specify which? JP> Both, IPv6 much more likely than IPv4, but v6 isn't everywhere so we might need to do both. The idea is to not exclude IPv4 a priori. Mark Townsley> Which would mean a 4lowpan (does not exist today) David Ward> In use cases is it a v4 or v6 or both and should put in charter? Kevin Falk> All apps have realtime aspect, Phil didn't put realtime aspect in survey at least a timeliness aspect and some with extremely sensitive to jitter Kevin Falk> Where the security framework? JP> The aim is to look at routing attacks, especially because of the specifics of wireless L2Ns with specific traffic patterns. Kevin Falk> Maybe should study existing security for security framework. When see framework is sounds like to decision has been made David> many sec issues are different from routing security. family of sec issues may not happen here. Kevin Falk> need more precision. (?): you said 40 million devices shipped working now... make it v6 only! make all future work v6 only, Mark: he stole my thunder. 6lowpan would be v6 only. 4lowpan... What is that? Define from scratch. Not defined yet. Chandrashekhar Appanna> you need to clarify why industrial,home and such is in scope and why others are out of scope JP> We want to focus on a few specific use cases that are representative. Of course, if the routing solution is applicable to other domains, it could perfectly be documented in applicability IDs. Eric Nordmark> words looked like a threat analysis Quan ho chen> Will is still be low power? JP, David + Others> YES Quan Ho Chen> Why not layer-2? JP> This is IETF. We don't do layer 2 JP/David> Who thinks that we should work on these issues at the IETF ? Almost all JP/David> Who thinks that we should NOT work on these issues at the IETF ? Nobody JP/David> Is the charter reasonable approach? POS: >50% NEG: 3 JP> Do we have consensus to form a WG? POSITIVE: almost all. JP> Who is opposed ? NEGATIVE: 1 JP/David> Who is willing to contribute: [20~30]