================================================== | | | "RAW" MEETING MINUTES for Session 1 - MANEMO. | | | | (Minutes for Session 2 - AUTOCONF - see below) | | | ================================================== Thanks to Alexandru Petrescu for competent Jabber scribing Thanks to Charlie Perkins for the minutes, reproduced below - Devoted to MANEMO www.mobileip.jp/MANEMO - Agenda Bashing - Intro & Scope - Scenarios & Requirements - Architectural Considerations & relationship with IETF - Discussion & Next Steps - Intro & Scope = Bar-BOF at ietf68 = Goals: Scenarios, Use-cases, IETF relationship = NOT an [autoconf] rechartering = NOT for solution discussions = A Nemo Mobile Router * 2 phys. interfaces, roles, Egress and Ingress * Roles: impose behavior * Forwarding: tunnel, static forwarding * Important: session continuity = MANET interfaces * fuzzy neighborhood, semi-broadcast * non-prescriptive - no protocols are imposed --- existing protocols may require specification = Roles and Characteristics - Scenarios -- Teco Boot = First, a military environment very ad hoc, ships, helicopters, platoons, mobility events, topographies = Public Safety network: Federal Agencies, 911 stations IP core network, WiMax, Satcom, Cellular Doctors, Hospitals, Police, Command Control, Network Utility Information = Vehicle to Vehicle, Terrestrial Broadcast, Satellite, RSE == Roadside Equipment = Multiple uses: fixed Internet, a lot of mobile nodes = Communication between nearby nodes (but, NEMO requires use of remote home agent) = Path to home agent may be broken Question: what is the purpose of the meeting? what if there is no home agent? Discussion: Need to understand what the problem is, and why Mobile IP or Nemo or manet problem What is wrong with current protocols, and what work more is needed? What is meant by an optimal path? Would route optimization help? When micro and macro mobility is needed? When fixed and mobile infrastructure is needed? - Architectural considerations -- Ryuji Wakikawa MANEMO problems == too many home agents, bouncing through many domains before reaching correspondent == insertion of home agents in path between neighbors == What is the routing scope? (1-hop, 2-hop, or n-hop) == What should participation (MR, fixed router) (maybe node mobile host, ?access router?) == Which address is used? (link local, unique site-local, global [=which one??]) (for global, where is global topology information learned?) Question: WiFi, WiMax, 3G? Answer: depends on what devices the operator uses? [tautological??] Fred: need to have an idea of what medium is under consideration Fred: autoconf says prefix is obtained from upper access router, but it may be better to get prefix from the mobile router. Comment: only four important link types: ethernet, starlike/WiMax, WiFi, ...? [autoconf] applicability: What NEMO can get from [manet]/autoconf - NHDP, etc... NHDP vs. NDP - Mobile IP relies on NDP for movement detection, returning home, unreachability, addrconf/DAD - Assertion: conflicting routing information from NDP and NHDP (do not believe this, if data handled properly) [manet]/[autoconf] applicability: - Required functions: global topology correct - Route setup to AR - From Nemo MR: routes packets of other MRs - AR/IGW: must NOT leak routes to Internet - Is tunnel required: yes, since traffic goes through the home agent. Fred: but could get topologically incorrect prefix from mobile router, avoiding some of this problem Question to [manet]: how is route setup to access routers? [Ryuji] Joe: sometimes discovery mechanism is not the same as the routing/forwarding mechanism From [autoconf] global correct prefix/access router discovery AR/IGW involvement (is this a MANEMO problem?) Issue: divide a Nested NEMO - if fixed router is [manet] aware, full optimization - Otherwise, the fixed router divides the MANEMO into two nested NEMOs. Jari Arkko: Why not just upgrade the FR? Ryuji -- O.K. fine! That would be great! Jim Bound: _not_ just a military problem, but many other applications Dow Street: really just trying to solve the _general_ mobility problem Joe Macker: [manet] charter was pulled back to to solve a less complicated problem, and [manemo] is trying to get back to the more general problem Ryuji: Have been looking at gateway problem for a long time Andrew MacGregor: How do applications find each other? How about referrals? Jim Bound: [manet] is a misnomer since many scenarios for ad hoc networks aren't mobile Can't understand why people are questioning what the problem is. Thomas Narten: Does [manemo] need to boiling the ocean? Can it be done without changing addresses, or tunneling, or ??? Charles Perkins: It is not all black & white: more signaling can reduce tunneling, but sometimes more tunneling is OK. and more signaling is bad. Tim Shephard: What about multihoming? Is there another tactic besides the locator/identifier split? More slides/Ryuji: - Impact of MR movement - NEMO addressing: Movement Transparency - MR movement - Multihoming Capability: = MR may obtain multiple addresses in Nested NEMO * NEMO topologically incorrect address * Autoconf topologically correct address - Monami6 applicability?? = Then, MR can register both addresses as CoA - Overall Observations = Integration of [nemo], [autoconf], OLSR/DYMO, NHDP, NDP == MR obtains address (NDP or Autoconf) == MR updates routes (NEMO, DYMO, NDP, ...) == MR checks reachability by NDP and/or NHDP = Interoperability & backward compatibility == MR is not always participating in MANET, but attaches to the legacy v6 link. Jari Arkko: can't be relying on home agents at all -- Also, need to identify a solvable subset of the total problem Gabriel Montenegro: What is the fundamental problem? What about using solutions like Teredo or NAT? TJ: need to focus on actual cases, look at the tools we can used to solve Nested NEMO. Steve Pratt: We saw the scenarios, but what were the issues? Work with the emergency dispatch systems? Joe Macker: the two general problem areas are quite different, and has concern when they are mashed together... Comment: People in the field do not care about IP, they just want it to work. Dow Street: Charles Perkins: Why is this in the Internet Area instead of the Routing Area? Justin Dean: manet is just the routing, it is a "box" solution. The crux seems to be that problems work well enough separately, but not well enough together. ================================================== | | | "RAW" MEETING MINUTES for Session 2 - AUTOCONF.| | | ================================================== Autoconf WG Thursday 26th July 2007 13:00 MANET Architecture (Ian Chakeres) draft-ietf-autoconf-manetarch-04 Editorial and terminological changes made (from -01 to -04) -05 due in two weeks. To incorporate mailing list feedback. Hope to Last Call soon after that. Problem Statement (Emmanuel Baccelli) draft-ietf-manet-problem-statement-00 (updated from individual draft -03) Scenarios: Standalone MANET, Connected MANET (single gateway, multiple gateways) Thomas Clausen: Need to be careful of terminology, can have standalone MANET with attached network that doesn't use MANET routing. Attached is about to something with topologically correct addresses. Joe Macker: May transit between these states. Goals: Initial address assignment/prefix delegation, continued address/prefix uniqueness. Motivation: Current protocols don't allow for MANET characteristics (multi-hop, dynamic internal/gateway, partitioning). Issues: address/prefix configuration, uniqueness, border router management. Considerations: overgead, convergence time, trust, interaction with existing protocols. Thomas Clausen: Need more clarity on border router management. Single node or multiple BR interaction. Teco Boot: Commented that topologically correct ingress filtering should be mentioned in document. Thomas Clausen: What does topologically correct address mean? Only with respect to border router? Fred Templin: Suggest "a prefix which is aggregated" rather than "topologically correct". Joe Macker: Now looked at draft, not clear that the transit between cases must continue to work. Comments already received on -00, -01 due next week. (Terminology, ingress filtering, DHCP, enhanced considerations.) Fred Templin individual contribution Types of addresses/prefixes: link local, MANET local, unique local, centrally assigned unique local, global (options) Challenges: multi-link sites, multi-hop (link scoped functions do not work as expected) interfaces are neither ingress or egress (neutral). Options: Raw use of multilink site with changes to ND (in document, not here). Virtualise using IP-in-IP: VET (Virtual Ethernet) - not new. Autoconfiguration procedure: configure MANET local addresses, engage in MANET routing, configure VET interfaces, discover border routers, perform RS/RA exchange with border routers over VET, get DHCP prefix delegations, self-generate unique local addresses, auto-configure IPv6 addresses on VET interfaces (TBD). Can now select exit routers, send binding updates to home agents, tunnel and send packets. Operation with multiple border routers. Must use the border router where got visited network prefix from as default. DAD considerations: managed so should only need on-going, not pre-service. Some addresses don't need MANET-wide DAD. Three drafts, two need updates. Greg Daley: Question about where can use of DHCP addresses. Don't need for VET. Suresh Krisnan: Question about IAD part of addresses. VET is /128 (IPv6). Need consistent mechanism to keep VET consistent. Charles Perkins: Question about how MANET routing fits into the picture. It provides the routing that makes the virtual ethernet work. How does this fit to MANET work? Answer is architecture document bridges gap. Greg Daley: How are we going to track MAC addresses? This is the job of the MANET routing protocol. Joe Macker: Want to understand MANET interfaces. In some cases not all nodes are equal. Do we lose the heterogeneity handling by treating everything as one interface? The VET interface leaves these problems to MANET interface/routing. Gabriel Montenegro. Like this for 6lowpan. Is there anything in trill to use? Improving synergy. Layer 2 issues. Dave Thaler: Is this straight IP-in-IP encapsulation. What about multicast? Haven't considered multicast. Greg Daley Is this just IPv6? Possible IPv4 issues. Leaning to IPv6 in upper layer. Goals of autoconf are IPv6. More IPv4 thought needed. Common Framework for Stand-Alone Autoconfiguration (Kenichi Mase) Individual -03 updated from -02, -04 needed. Aim: Framework or guidelines for solutions. Background: Uniqueness issues are in Problem Statement. Phases model. Will be four phase model in -04. Duplicate address advertisement to avoid contamination. Framework includes pre-service and in-service DAD, DAA, and may use routing messages. Suresh Krisnan: Security issues over DAA, obvious DOS possibilities. Dave Thaler: This presentation says "address" while architecture discusses prefixes. Is this a change, or just a terminology issue. Considering MANET local address. That term isn't in architecture document. Thomas Clausen need to get addresses to interfaces. Dave Thaler, prefixes are what we assign. Emmanuel Baccelli just terminology. Emmanuel Baccelli: Why only standalone? What part doesn't apply to connected case? May be extensible, but not sure if four state model works. Charles Perkins: Why is pre-service DAD a MAY? Why not stronger? There's a performance cost of in-service DAD best avoided. SHOULD may be more appropriate (with proper understanding). There are different solutions. SHOULD does cover this (if you avoid by assignment mechanism you hit its "escape clause"). Charles Perkins: What if you just want an address? Christopher Dearlove: isn't this that you do just have one address, but it does both jobs. Address or prefix? Gateway Aggregation (Yasunori Owada) Individual -01 updated from -00 Motivation: to pick better gateway without changing assigned global address. Solution: IP-in-IP tunnels between border gateways. Routing control traffic goes through tunnels. All must support. Uses single anchor border gateway. Next step: route optimisation, extension for other scenarios/ uses cases. Anshul Kantawala: As gateways are connected to the Internet, why tunnel? If MANET changes, will tunnels be created and destroyed? Emmanuel Baccelli: this is for multihoming. Dave Thaler: Are the gateways owned by the same, or trusting, organisations? What is the need for the outbound tunnel? Take this offline. Emmanuel Baccelli anchor has default route. Survey of Autoconf Mechanisms (Carlos Bernados) Individual -00 was July 2005, now -01. Updated for WG documents, added solutions. Motivation: Survey, provide context, analyse and classify. Classification: Pure (standalone) and hybrid (connected) MANETs. Chairs: use standard WG terminology, and also consider transition and whether solutions support this. DAD-based or DAD-free. Chairs: may need name that doesn't clash with DAD protocol. This applies to all documents. Joe Macker: Can we suggest an alternative name. Christopher Dearlove: as we are using prefixes, not addresses... Emmanuel Baccelli: Problem statement uses prefix uniqueness. Routing Protocol Dependence: may be dependent, use information (possibly as optimisation) or be independent. Distributed/centralised Partitioning/merger support Prefix delegation support Protocol overhead (flooding, signalling, piggybacking on routing protocol, passive) Christopher Dearlove: you may get second/third to combine with packetbb if possible, otherwise not. Statistics: half standalone, half connected. Third each pre-service DAD, in-service DAD, DAD-free. Abour half independent/dependent. Mostly distributed. Two thirds with partitioning/merging support. Joe Macker: If you use routing, but don't directly interact with it? This is classified as independent. Charles Perkins: Suggest consider complexity analysis, how does it scale with numbers of nodes/links. Next steps: refining, evaluating, work on general solution spaced analysis. Joe Macker: Consider reliability. Prefix Distribution Framework (Kenich Mase) Individual ID to be submitted soon. Issues relating to prefix distribution, individual or common. Scenarios presented.