Mobile Ad hoc Networks (MANET) Agenda Meeting : IETF 71 Monday March 10th 2008 Time : 1740-1950 Location : Franklin 6/7 Chairs : Ian Chakeres ian.chakeres@gmail.com Joseph Macker joseph.macker@nrl.navy.mil Jabber : manet@jabber.ietf.org Audiocast: http://www.ietf.org/audio// URL : http://www.ietf.org/html.charters/manet-charter.html http://www.ianchak.com/manet http://tools.ietf.org/wg/manet/ https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=71 Minutes : Jerome Haerri ========================================================= Administriva - Mailing list: manet@ietf.org - Presentations have been updated very recently. Please log on to download the latest version. - Scribe: Jerome Haerri (haerri@tm.uka.de) - Blue Sheets: Please sign your name on the blue sheets - State your name at the microphone when asking questions - IPR - RFC3979 ========================================================= Agenda bashing Speaker: Ian Chakeres Content: WG Progress - draft-ietf-manet-jitter-04.txt => RFC 5148 - draft-ietf-manet-packetbb-11.txt (Revision Needed) - draft-ietf-manet-timetlv-04.txt (Revision Needed) o DYMO Discussion - draft-ietf-manet-dymo-12.txt o DYMO-MIB Discussion - draft-manet-cole-dymo-mib-01.txt (Published Today) o PacketBB, TimeTLV, NHDP, OLSRv2 Discussion - draft-ietf-manet-packetbb-12.txt (Published Today) - draft-ietf-manet-timetlv-04.txt (Revision Needed) - draft-ietf-manet-nhdp-06.txt (Published Today) - draft-ietf-manet-olsrv2-05.txt o NRL PacketBB Implementation o nOLSRv2 Implementation Update - http://www.net.ie.niigata-u.ac.jp/~yowada/v2/olsrv2/Welcome.html o SMF Discussion - draft-ietf-manet-smf-07.txt o SEAL Discussion - draft-templin-manet-seal-00.txt o Metrics - draft-dean-manet-metrictlv-01.txt (Expected revision) - Choosing relays in OLSR while considering link metrics - draft-dearlove-olsrv2-metrics-00.txt o Open Discussion, Related Work & Announcements - ROLL WG - Routing Over Low Power and Lossy Networks Thurs Morning in Franklin 13 agenda agreed. ========================================================= WG Progress Speaker: Ian Chakeres Content: * Manet WG status * IPR: attendees are kindly asked to speak up if they know/have IPR technologies - Brief update on all documents. See slides. * Jitter has been published as RFC5148 * IANA is in RFC editor queue * PacketBB and TimeTLV require a revision. Need to discuss today * a WGLC has been completed with NHDP. The draft has been improved according to comments. - Document relationship Comments: none. ========================================================= - draft-ietf-manet-dymo-12.txt Speaker: Ian Chakeres Content: See slides Comments: none. ========================================================= - draft-manet-cole-dymo-mib-01.txt Speaker: Joe Macker Content: See slides Comments: Charles Perkins: MIB-II and MIB-DYMO should be clearly differentiated. IT would be required to specify exactly what is in MIB-II and MIB-DYMO Joe Macker: The WG should decide if MIB-DYMO should be a WG document Ian Chakeres: Please read the document and provide your comments. ========================================================= - draft-ietf-manet-packetbb-12.txt (Published Today) - draft-ietf-manet-timetlv-04.txt (Revision Needed) - draft-ietf-manet-nhdp-06.txt (Published Today) - draft-ietf-manet-olsrv2-05.txt Speaker: Thomas Clausen Content: See slides Comments: packetBB: Ian Chakeres: It is in the IESG queue, and there remains several issues. Joe Macker: File a note on what has been done and what is missing Ross Callon: In order to be accepted, 10 votes need to be secured. Even with the current comments solved, we do not have enough votes. As we are waiting for responses from the other voting members, you should expect to have more comments in the near future. timetlv: no comments. nhdp: Teco Boot: The number of addresses exchanged with the interface IDs is problematic. It is inefficient. Is possible to simply use a single router ID to improve it ? Thomas Clausen: If you have only one interface with one address, then things might be simplify-able. However with multiple interfaces and multiple addresses, then the bi-directionality check of a link over a pair of interfaces requires information describing all addresses. Ian Chakeres: Let's put this on the "to do" list. Charles Perkins: I feel uncomfortable with the increasing size of a "Hello" message. This comes from the inefficiency of PacketBB. Some fields are not required to be transmitted every time. You should revise the list of mandatory fields from MUST to MAY. Moreover, reducing the packet size should be encouraged. Thomas Clausen: The standardization of the NHDP protocol is intended to go beyond OLSRv2, DYMO or SMF. Specifying components for a specific protocol is easy. Specifying a generic component for a generic protocol needs flexibility. Moreover, the size of a packet is less important than the cost of its transmission. Charles Perkins: OK, but some components has also been specified for L2 protocols Charles Perkins: I still think that for the validityTLV, for instance, MAY should replace SHOULD for its inclusion. Thomas Clausen: We should add this to the "to do" list. Ian Chakeres: Charles, could you please start a thread on this topic? Charles Perkins: I will do it. Has NHDP also been defined for L2 functionality? Thomas Clausen: No, it has not been done for that. Elwyn Davies: A motivation for why NHDP is the right answer is missing. It contains a large set of possible neighbor discovery procedures, but no reason of why this is good... Joe Macker: I think you got confused. But that is a good remark. We need to be more clear. There are many reasons for that, some are straightforward. Do you want an applicability statement? Elwyn Davies: No, just a motivation on how NHDP is compared to a Link_Neighbor or one-hop neighbor at layer 2. Justin Dean: Would it be difficult to change NHDP to use only 1-hop neighbors ? Thomas Clausen: Well, no. But, if one wants only 1-hop neighbors, then one can record only the 1-hop neighbor set. However since we'd still need to check link-bi-directionality (with link as defined in the I-D), then one still needs to exchange the addresses of the interfaces. And, as such, one does get the 2-hop neighbor set "for free". Furthermore, there is a (subtle) difference between detecting "neighbors" and "neighbor interfaces", which necessitates more information exchange (i.e. as in NHDP). olsrv2: no comment. ========================================================= nOLSRv2 Implementation Update - http://www.net.ie.niigata-u.ac.jp/~yowada/v2/olsrv2/Welcome.html Speaker: Yasumory Owada Content: See slides Comments: Ian Chakeres: If you are facing implementation issues, or protocol issues, please report them. We are interested. Brian Adamson: Implementing NRL PacketBB Thomas Clausen: We have an up-to-date and complete packetbb-implementation; that implementation has been "interoperability tested" by hex-dumping a packet, emailing the hex-dump to a person abroad who's also implemented packetbb, and who fed it to his parser and emailed the resulting parsed packet back. Thomas Clausen: In October, there will be an Interop/Workshop in Ottawa, Canada; more information announced shortly; We're working on (as-is, we've completed) Java applets that allow: - given a hex-dump of a packetbb packet, get a parsed version - point-and-click construction of packetbb packets, get a hex-dump Once testing is completed, we will announce these publicly; allow testing your packetbb implementation with ours. Yasumory Owada: The code is available. Please download, test it and provide feedback. ========================================================= - draft-ietf-manet-smf-07.txt - SMF: Speaker: Joe Macker Content: See slides Comments: none. ========================================================= - draft-templin-manet-seal-00.txt Speaker: Fred Templin Content: See slides Comments: Ian Chakeres: Fred published an update today. So, please read it and send your comments. ========================================================= - draft-dean-manet-metrictlv-01.txt (Expected revision) Speaker: Justin Dean Content: See slides Comments: Joe Macker: There might be other works on other metrics in different groups here in IETF. A summary of what has been done or is currently under investigation should be done. We would like to know how much has been done yet.. Justin: This draft proposes a solution on how to encapsulate link metrics, not what or how to use a metric. Thomas Clausen: Two other important aspect that I see: - IANA Allocation - related work in IETF Brian Adamson: On the IANA issue, the metric TLV is similar to the time TLV concept. The context for the TLV is only meaningful for the context of the message. It may then serve for different protocols, ie. multiple different metrics to transmit for different protocols or even version of a same protocol. Thomas Clausen: I am still concerned by IANA. Any TLV should use the same structure to cut down on the redundancy in message decoding. Thus, 1 parser for all functionalists of the TLV. We need a common structure. Somebody: How to tag specific values when we use the same basic structure for different TLV ? PacketBB might not need to know a particular metric that a protocol could need. Thomas Clausen: I do not want to have the same piece of code in many places, but rather have one piece of code for a functionality. Example: OLSRv2 and NHDP both use TimeTLVs. Then, I do not want to recode it several times. Teco Boot: Optimize the code is fine with me. But it would be better to first optimize the protocol. So, we should address the question of "why metrics help" ? Joe Macker: Justin, could you please organize a special meeting to discuss link metrics ? Justin Dean: I will do that. ========================================================= Choosing relays in OLSR while considering link metrics Speaker: Jerome Haerri Content: See slides Comments: Joe Macker: Do you have similar results for different metrics, such as number of hops ? Jerome Haerri: Yes, I could not show them here, but I can send them to you. They are available anyways on the journal publication indicated on the slides. Philippe Jacquet: Are you sure MPR is only based on Unit disk graph ? Jerome Haerri: right, MPR can also be applied to random graphs. Yet, my point is that these graph abstractions are too simplistic compared to real communication graphs. Philippe Jacquet: MPRs are not build upon the unit disk model. Charles Perkins: What is the idea behind the equation creating the "kinetic nodal degree" ? How do you obtain this equation ? Jerome Haerri: Basically, we model the node degree as a double sigmoid function. The first sigmoid goes to 1 when two nodes start being neighbors, and the inverse sigmoid goes to 0 when the link breaks. By multiplying them, we obtain a continuous function of the node degree as a function of time. Thomas Clausen: OLSR mandates selection of MPRs on one criteria (2-hop coverage) only, and is algorithm-agnostic otherwise; given that criteria and an algorithm that satisfies that, we can reason about the behavior and performance. Obviously, changing the fundamental criteria (item 1 above) means that the reasoning in the immediately previous item may or may not hold. Hence, for any changes to the criteria, one must be careful to verify that it doesn't "break" any of the reasoning, and I have not seen justification or discussion to this effect. Jerome Haerri: Yes, but I have seen that OLSR has trouble in mobile networks. Jerome Haerri: What I mean is that under mobility (such as vehicular networks), OLSR can shows poor performance. MPR selection may not converge, and therefore OLSR has problems also. Thomas Clausen: First, I believe talking about the convergence of MPRs is incorrect in this context. Second, this does not correspond with our own experiences of OLSR in vehicular networks. Rather, it may be indicative of an inappropriate choice of deployment parameters. Report from offline discussion: Thomas Clausen: As long as you propose a protocol replacing MPR that maintains the two-hops connectivity, I am fine with it. But if you do not, then we have a serious issue with OLSR. Jerome Haerri: Actually, I did not emphasized enough, but both solutions totally keep the two-hops connectivity. They just propose a better ways to chose the relays keeping this two hops connectivity. Thomas Clausen: Then, you are still using MPR. Jerome Haerri: Yes, but using link metrics. Thomas Clausen: It is not the MPR protocol that is not adapted to mobility, but the algorithm creating these MPR nodes. Jerome Haerri: Agreed. I used a wrong formulation. Meeting ended at 7:55pm.