Net2WG/Notes/20100625
Contents
Meeting Notes
Agenda
* Source routing packet format * Context of source routing in TinyOS community
Participants
* Om, USC * Mike, JHU * Doug, JHU * Eric, UCSC
Source routing packet format
Finding the next hop
* Mike: 'currentHop' field in header: do we increment or decrement it?
* Eric: Decrement currentHop, order entries in reverse. when it's 0, you're the destination. Can still use this to directly index into the header to find the next hop.
Keeping route in Header vs. Footer, encapsulation.
* Eric: Should put all SR info into header (not footer).
* Eric: For the case of link estimator: this is done at the MAC level, where HW tells you the size of the packet. Only works at the first layer.
* Eric: keep things simple: SR header, SR, payload. More like the standard way of encapsulating protocols.
* All: OK, sounds good.
Send command, dependency between setting route and setting payload.
* Om: so do we need to set the SR, then the payload? does this need to change in an interface?
* Eric: this seems like it should be hidden.
* Mike: Actually, it's all wrapped into a single call (to Send). so there's no dependency between calls.
More packet format discussion
* Eric: last night, put out there: if you don't use a route-length field, I suggested a format for doing it efficiently.
* Eric: the main difference between this and the tep is that sr_len and hop_offset are in terms of bytes. Simpler to compute, low byte count.
* Eric: as it propagates, subtract 2 from the hop count each time. when it hits 0, it's yours.
* Om: sounds good to me.
* Eric: The payload_id is used for encapsulation. same as srouting_id. "this is the type of payload that the SR packet is carrying."
* Eric: has done some of this engineering work already for proper variable encapsulators. not done yet.
Greater Context of SR
* Eric: treat this as a research/exploration vehicle: is source-routing a reasonable propagation mechanism in general? Needs research, and could be very beneficial.
* Eric: if this seems useful, then we can start talking about putting this into the standard network stack. Then we can talk about the more interesting research issues that this opens up (route discovery, route healing).
Mixing SR nodes with non-SR nodes.
* Mike: Do we mix SR nodes with non-SR nodes?
* Eric: some apps don't care about the routes, some do. If these apps live together, then we deal with it. Until then, no worries.
* Om/Eric: Should shelve this, deal with it only later. Let's not fret about this until we've decided that yes, we do want to use source routing.
Documenting these discussions.
* Om: might be good to record the open questions in the TEP. "Future considerations," if you will.
* Eric: State in the introduction that this is a "Source Route application protocol". it's not intended to be "how you do SR in TOS networks". It's more of a tool for exploring the use of SR in networks.
* Om: yeah, they're all drafts for now.
* Eric: Right, this is roughly the equivalent of an IETF I-D (internet-draft)
To-do's
* Mike: I'll update the TEP again and redistribute/put into repo before monday.
* Mike/Om: one or two more revisions, then out to the community
* Eric: somebody should try to hack out the code for this right quick and get a feel for how it will work out.
* Om: yep, won't be final until there's some hands-on time with it.
* Om: Protocol testing postponed until next week at least, Thanh's not around.
