[6lowpan] Draft minutes of Minneapolis 6lowpan meeting

Lowpanners,

attached please find the minutes I have written up from notes taken by 
Bob Moskowitz and me.
I must admit that I didn't catch all of the sometimes fast-paced 
discussion (as is my right as a non-native speaker :-), so my apologies 
in advance if I'm mis-representing your positions or am misspelling you 
name.  We still have a couple of days to correct these minutes before 
they are frozen in the proceedings.

Please send all minor corrections to me; but keep things that might be 
more contentious on the list please.
(These are minutes of a meeting that is already over, but I don't mind 
spawning some list discussion from the points raised here -- just make 
it clear that you are not suggesting a minutes correction.)

Gruesse, Carsten

IPv6 over Low power WPAN (6LOWPAN) Working Group Minutes
========================================================

Reported by Bob Moskowitz and Carsten Bormann

    The 6LOWPAN working group met once at the 62nd IETF meeting
    (Minneapolis, March 2005). The meeting was chaired by Geoff
    Mulligan.

WG Charter

    Geoff Mulligan went through the charter of the new working group and
    asked if there were any comments.  There were none.

Problem statement -- draft-kushalnagar-lowpan-goals-assumptions-00.txt

    Nandakishore (Nandu) Kushalnagar presented the problem statement
    draft (see slides).  This document is at the level of a personal
    contribution; there was no contention to use this draft as the basis
    for discussion in the working group.

    Regarding the issue of routing, Nandu pointed to a separate
    presentation later on the agenda.  While the intention was to use
    existing routing protocols, making them work at the subnetwork level
    requires some changes.  This brought up the question how to handle
    the plethora of routing protocol proposals that can be expected.
    Geoff stated that the the working group scope does not include
    routing, it is IP over foo.  There is an opportunity to look at
    other issues, maybe as an informational document; the charter
    nonetheless is limited to the two documents being discussed.

    A 15.4 contributor (Pradeep? The note takers apologize for not
    catching names very well.) mentioned that in 15.4, there are two
    mechanisms: CSMA/CA and slotted; IP discovery will be different for
    the two.  Gabriel Montenegro pointed to the subsequent agenda item,
    which goes into each of the modes we assume.  Geoff proposed to
    include in the problem statement the assumption of CSMA/CA, instead
    of the superframe structure ("slotted").

    Lixia Zhang noted that the WG will be constrained by its charter and
    asked whether there was a plan to address the inevitable issues of
    deployment: management and security.  Nandu proposed to make use of
    existing security working groups in the IETF, without making
    specific proposals which of these might be of interest.  Geoff
    proposed to complete the IPv6-over-15.4 document first.  Lixia
    insisted that deployable security must be part of the initial result
    or there will be a deployment surprise.  Gabriel said that while the
    charter has very specific goals; there is some language that allows
    future work -- the WG may be able to recharter when we have a better
    understanding; the issues might be the subject of individual
    submissions in the interim.

    Simone Ruffino asked whether, for the mesh network that is built
    below IP, the intention is to adapt existing mechanisms of stateless
    autoconf or invent a new one.  Nandu said the intention was to use
    the existing IPv6 mechanisms, but pointed out that for 15.4's 16-bit
    addresses we need a different method.  Simone asked whether the whole
    LoWPAN was to be considered one link in the IPv6 architecture sense.
    Nandu affirmed.  Bob Hinden asked for further clarification.  Bob
    Moskowitz said that the LoWPAN looks like an 802 LAN to higher
    layers. Bob Hinden mentioned that the IPv6 autocongifuration/address
    architecture defines how to create interface tokens and asked that
    these not be reinvented.  Nandu agreed.  Gabriel later attempted to
    clarify the answer to Bob Hinden's question by pointing out that
    15.4 has a PAN ID, which, in IPv6 architecture words, identifies a
    link -- multiple PAN IDs can overlap, but not interact.

    The discussion returned to the question how to use IETF security
    working groups for developing the LoWPAN solution.  Margaret
    Wasserman pointed out that there is a number of groups to look at.
    Geoff stated that none of them is actively looking at
    LoWPAN. Gabriel agreed that LoWPANs require security work but said
    we don't necessarily have to solve them in the 6LOWPAN WG, can do
    that in the security WGs.  Bob Moskowitz noted that 802.15.4 has a
    security format to encrypt the payloads, but does not have a key
    management scheme or exchange methodology -- defining that would be
    one valuable thing to do, reminding everyone that this is a
    hop-by-hop security model and that for end-to-end security, a higher
    layer security mechanism is required.

    Pekka Savola clarified that while there is an IETF security area; it
    would be too much to expect security area people to just come in and
    fix the WG's protocols; the WG has to do this and, if necessary, ask
    for help.  He pointed out that, if this WG does not do the necessary
    security work; the result will be held up in the IESG for security.
    Geoff countered that the WG is not currently chartered to do
    security

    Margaret asked why are there any specific security issues that
    aren't either a problem of IEEE or general IETF issues?  Nandu
    answered that a LoWPAN has different characteristics, including its
    packet size, and the wireless multi-hop, related to MANET type of
    network

    The WG chair closes the mike line and refers further security
    discussion to the final agenda item.

    One last comment was that it was not easy to see how stateless
    autoconfiguration fits into the LoWPAN model -- it was hard to
    imagine routers giving out the appropriate advertisements...

IPv6 over 15.4 -- draft-montenegro-lowpan-ipv6-over-802.15.4-01.txt

    Gabriel Montenegro presented the IPv6 over 15.4 draft (see slides),
    pointing out that, although this is already the -02 version (second
    revision) of the draft, this was going to be the first face to face
    discussion in this working group.

    During the presentation, a poll indicated that about ten of those
    present in the room had read the draft.  Gabriel pointed out that,
    for assigment of 16-bit addresses, 15.4 defines a prodecure with a
    central coordinator, which does all the necessary work, we can use
    that.  The mapping between PAN ID and IPv6 prefixes is not currently
    defined.

    During the presentation of the frame format and adaptation layer,
    Carsten Bormann asked how compatible this format was with
    transporting LLC packets as well.  This had not been examined.  Bob
    Hinden asked why RFC 2507 (IP Header Compression) wasn't being used
    as a header compression format.  Carsten answered that the
    requirements for 6LOWPAN's header compression scheme are very
    different from the ones that RFC 2507 addresses (which addresses
    flow-based compression).

    Carsten asked about the relationship of the reassembly scheme
    proposed and the reordering assumed from the link (e.g., the MSL
    issue).  Bob Moskowitz clarified that Meshes are being discussed in
    802.11, .15, .16, and none of them addresses reordering.

    Gabriel noted that there is a mistake in the current draft -- there
    is a need for multiple M bits.  Rajeev Koodli asked whether the IPv6
    routing header could not be used to solve the problem.  Gabriel
    clarified that routing headers carry IP addresses, while the "Final
    destination" field is about MAC addresses.  Bob Moskowitz added that
    all 802 meshes need special multi-MAC formats for meshes and pointed
    out the 4-address format used in .11.

    When Gabriel presented the header compression mechanism proposed,
    Alain asked about same-subnet vs. link-local source and destination
    addresses -- does this mean the assumption is that LoWPAN devices
    never listen to a router? Gabriel stated this as the most common
    case; however, global addresses are possible -- and even expected to
    be compressible.  Alain wondered whether this has a bearing on the
    address selection policy to be used by endpoints.  Gabriel asked
    whether, based on the current address selection policy, we have
    to modify anything.  Alain answered that, if only link-local
    addresses are used, the current address selection policy is fine.

    Greg Daly pointed out that, while link-local addressing is the most
    common case, at the moment, it is quite possible there will be
    off-link traffic.  Gabriel answered that this remaind possible, just
    will be less compressible. Gabriel then speculated about possible
    integration of the compression state and the routing information.

    Krishnan asked why there was no attempt compress out the hop limit
    as well.  Gabriel answered that this was worthwhile to examine.
    Rajeev pointed to a paper about stateless header compression he had
    at IEEE ICC 2005.  Gabriel also stated a need to expand the work to
    also examine TCP header compression.

Sub-IP Mesh for LoWPAN

    Nandu started the discussion pointing out that work on the Sub-IP
    Mesh is not currently part of charter.  Discussion ensued about
    other standards alliances working on standards in the same space.
    (See slides for Nandu's presentation.)  A draft for reactive routing
    at the Sub-IP level is in the works; replacing AODV hello by 15.4
    specific messages.  The suggestion is that this be separate from the
    basic IPv6 over 15.4 specification.  In the future, other protocols
    like OLSR, DYMO, DSR should be considered, but care must be taken
    that the work is actually applicable to LoWPANs.

    Charlie Perkins, in the context of work in MANET on DYMO and other
    protocols, asked for input to the discussion about the tradoff
    between using power for sending bits vs. using it for processing.
    Bob Moskowitz pointed to work in 802.11s about Mesh routing, an NRL
    proposal, and work on sub-second maintenance of the routing table
    information.

    Charlie Perkins indicated that this wasn't the complete answer he
    had hoped for and proposed to take the issue offline for further
    discussion.  Geoff added that he'd rather do less computing than
    send less bits.

Implementation considerations

    (The slides covered the issues of Embedded Systems, Code Size,
    Energy Use, Just enough security (what layer), What services
    (security, service discovery, ...), a Transport layer, and
    Compatibility.)

    Geoff noted overlap between the work of this working group and work
    done in ZigBee Alliance; ZigBee Alliance has announced to make
    their specification available for academic review but not for
    commercial use; anything about non-encumbrance has yet to be stated
    by the alliance.  This situation was a reason for not attempting to
    use the ZigBee format.  With respect to routing, Zigbee Alliance
    have what could be called "AODV junior", so we could try to
    interoperate, but we also could be ships in the night.  A ZigBee
    study group is just now looking at he feasibility of IPv6 over
    15.4, not doing the work yet.

    Gabriel: back to Charlie's question: typically, a LoWPAN is
    partitioned into Full Function Devices (FFD) with sufficient power
    and Reduced Function Devices (RFD) on battery power; RFD won't
    participate in the control messages (instead they'll send
    everything to a prefferred neighbor); in one scenario, FFD are
    always mains-powered; if FFD are battery powered, you want to
    compute, not transmit.

    Pekka Savola asked to focus some implementation considerations on
    AODV sub-ip; there is no security in AODV; there can't be a
    normative reference it as it is experimental.

    Geoff: One implementation consideration is that 15.4 defines radios
    for the whole range of 20-250 kbit/s, which is a big difference.
    We might have the opportunity to say we only do 2.4 GHz.  15.4b
    will have differences both in modulation and in security and is
    about to become an IEEE specification.  Gabriel noted that the
    current drafts don't have much text on 15.4 security -- using that
    might improve security.  Bob Moskowitz stated that doing the 15.4
    security cannot be avoided; the risk in a PAN to have
    non-authorized systems interfering is too great; L3 protection can
    do some of that, but is not as good a fit; so there is a need for
    an L2 keying solution.  Geoff pointed out that Sub-IP issues are
    generally not IETF work. Bob Moskowitz agreed and suggested to look
    where that work is done. IEEE 802 seems to be trying to get all
    future security work done in 802.1, whether that work fits here
    remains to be seen.

    Pekka stated that there needs to be at least some analysis, if not
    solutions for AODV security, Man in the Middle attacks.  Gabriel
    pointed out that every draft needs a security considerations
    section

    Nandu proposed writing an informational document that describes
    what kind of threats are relevant to 6LOWPAN.  The security of any
    adaptation layer needs to be addressed as well.

    It was pointed out that link-local addresses provide some form of
    isolation from link-external threads.  Gabriel pointed to work on
    group keys.

    Charlie Perkins asked about the scale of the network we are
    envisioning -- is this about PANs or larger?  Geoff said that his
    company was looking at home networks, with maybe 100s of nodes, as
    well as building networks with 1000s, but that additional input was
    required.  One solution might be a network of meshes (30-50 node
    LowPANs, IP routing between them).  It was pointed out that there
    are a lot more factors than just number of nodes; e.g., traffic
    characteristics.  There is a need to come up with some common use
    cases.

    Geoff asked about strict vs. loose source routing (carrying the MAC
    layer address for the next hop vs. the final destination), but then
    proposed to take this offline.

_______________________________________________
6lowpan mailing list
6lowpan@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan