NEMO Working Group, IETF63 Minutes
Compiled by TJ Kniveton
Note: The jabber logs for this working group session are available at
- Agenda, welcoming, and WG doc status
Prefix document drafts are currently individual drafts, but will be updated on the web page as -ietf- docs soon.
Home Network models draft submitted to IESG and will be going to RFC soon
Second RO solution space document due for end of August
- NEMO Basic Support Status and Deployment
- Management Information Base - Sri Gundavelli
- Added configuration objects to support scenarios where MR has multiple MNPs, based on implementation usefulness
- Before last call, there will be one more version. Will be an extension of the MIP6 MIB. Semantics aren`t there at the moment.
- Cisco has one implementation. WIDE and others also discussed.
- -02 by end of August; also, looking for MIB doctor. TJ offered to assist in finding a MIB doctor.
- NEMO Implementation status on BSD (SHISA) and Linux (NEPL) - Romain KUNTZ
- Explains implementations on *BSD operating systems
- NetBSD, FreeBSD, OpenBSD implementation developed between KAME and Nautilus6 projects
- Based on KAME`s SHISA implementation
- "NEPL=NEMO Platform for Linux"
- Next steps - Multiple CoA registration and Prefix Delegation 3 implementations were tested in January 2005 at TAHI test event Interop test results between Nautilus6, KAME and Cisco
- TAHI NEMO BS Test Suite and Next Interoperability Test Event - Hiroshi MIYATA
- Tahi has extended the MIPv6 tests. Almost all except RR are reused
- new specialized tests for NEMO
- Interop test scenario -- The scenarios are under discussion.
- If you have requirements on what to test, please contact TAHI.
- Two opportunities to try new TAHI tests: ETSI Plugtest in October, and TAHI in January `06
- Question from Thierry: Are you planning to support multihoming?
A: This year, we are just planning on basic support. But if there are resources, it is possible to expand it next year.
- ISO Activities on NEMO BS - Keisuke Uehara
- CALM - Continuous Air Interface for Long and Medium Range
- Goal: to create the standard for ITS wide area communication
- ITS is an area of automobiles using communication, i.e. car navigation, electronic toll collection..
- CALM supports continuous communication with handovers
- Adopting MIPv6 and NEMO.
- Low-latency applications and ITS applications
- Question from TJ: What does traffic information shower under a gate mean?
A: when the car is running, you can pass under a gate and receive a quick update on traffic situations.
- Focusing mainly on model 2 (in "Three Physical cconfiguration in Scenario 3" slide): Single router model
- in Model 1, they use MIPv6
- Motivation for interface selection from the MNN:
- MR and MNN will be delivered by different companies
- Architecture of Single MR and Multiple MR shown
- need CME-CME protocol
- Schedule: A committee draft is due later this year. Will take about 2 years to complete the international standard.
- Pascal Thubert: Devices on Mobile Network should know about characteristics of the egress interface/uplink network
A: Yes, we need a protocol to get that information
- Status of the Mip6trans DT (presentation in the MIP6 WG) - Vijay Devarapalli
(This is a high level overview; more detailed slides presented in MIP6 working group)
- 3 scenarios considered:
- 1. MN in IPv4-only network and wants to reach IPv6 services
- 2. HA is behind an IPv4 NAT without public v4 address
- 3. Support for IPv4 sessions initiated by MR.
- One other thing considered - MNN want IPv4 and IPv6 sessions at the same time (v4 subnet as well as MNP in v6)
- This has more to do with how the HA sets up routing
- It would be nice if it were possible to set up an IPv4 MNP as well as the IPv6 MNP. There is already a draft out, submitted after deadline. This is draft-shima-...
- Alex: Question on MNN.. There is a need for IPv4 MNNs. What will it mean?
A: MNN says a node on the network, not necessarily IPv6
- Alex: need for IPv4 MNNs and MRs?
A: This is simple, you just add an IPv4 address for MNNs. We are not addressing this scenario explicitly in the design team. If the WG is interested, we can do this in the WG. There is a draft that addresses this too.
- (Further questions and discussion in the Jabber log, starting at 07:44:15)
- NEMO Multihoming
- Analysis of Multihoming in Network Mobility Support - ChanWah Ng
(See slides for issues presented)
- Question what to do with Appendix B -- this is an informational draft so it may not belong here. The options are to further develop this, or remove it?
- Marcelo B: I raised this issue because the solution in App B has merit and it may be good to define it more precisely. TJ proposed an intermediate solution, to let it as is in the draft, and if more detail is required, we could also do that.
- Thierry: So the conclusion would be to leave it as-is?
- Marcelo: And as we understand more what the problem is, we can bring it into a separate document if needed.
- Mailing list issues presented.
- Thierry: Any comment on issues and classification?
- Alex: Since this talks mostly about multihoming, it should go to a separate WG
- Thierry: from an issue point of view, do people think the issues in the document are important?
- Vidya: The issue is real and needs to be solved. There is a subset of these issues that is important. But we may complicate the solution because we are looking at things that are not needed.
- Terry Davis: It becomes important in the aviation industry to deal with more than one network at a time. Not all networks will be capable of carrying air traffic control traffic.
- Vijay: There are some scenarios which are more important than others. We haven`t identified which we need to solve first.
- Vidya: That`s my point, and there is a dependence on how MIP6 solves multihoming and how we do it here. So we need to coordinate how simultaneous bindings are handled by MIP6.
- Thierry: So let`s consider this discussion on the mailing list. Some have expressed need to support these scenarios, but there are different usages.
- Token based Duplicate Network Detection for split NEMO - Masayuki Kumazawa
- TBDND tries to re-delegate the MNP consistently
- Prefix delegation without TBDND has a problem
- Can we discuss TBDND as an issue under PD?
- Sri G: Any other use cases for this, besides the one
- Christian Vogt: I assume you encrypt the token when
you send it to MR1?
A: Previous authentication is not necessary
- Christian: You could leverage the SAs between MRs and
the HA to share the information, but if you don`t encrypt the token it
could be eavesdropped.
- Chan-Wah: The reason for token is to check that MR1
and MR2 are on the same link. I don`t think the draft mentioned
anything about how to generate the token. But you are right, you could
use the SA.
- Thierry: Regarding question he asked to the WG: what
kind of configuration do we want to address in the WG, and what do we
want to solve? It`s too early to decide if we want to work on tha
particular topic, but we should have some feedback by the next IETF.
- Chan-Wah: I would like the PD draft authors to respond
to this on the mailing list
- Route Optimization
- NEMO Routing Optimization - Masafumi Watari
- Conclusion at IETF62 was to split the document into 2 drafts - RO problem statement, and solution space analysis. We have published the problem statement, but are still working on solution space analysis.
- Change log and identified problems shown. (See slides)
- Questions to working group (show of hands, count below):
- How many people have read the draft?
- Is the content what the WG expected?
- Comment from TJ: More people think the content is
what`s expected than read the draft.
- How many think it`s not what the WG expected?
- Alex: There is only one scenario that`s critical to
the protocol. The others could be categorized as efficiency.
2.7 is important to the protocol, which was
acknowledged long ago. I don`t know if RO is going to solve that.
A: I think RO is for efficiency, 2.7 was addressed by
- Network Mobility Route Optimization Solution Space
Analysis - Masafumi Watari
- Current status: Is supposed to be released by end of August, but may
take a little longer - we`ll do our best
- Analysis of Solution Space: A lot of discussion of how we should analyze the known solutions to provide RO
- There is some consensus, but no text yet from the authors
- Alex: Prefix ownership and prefix delegation were in
the multihoming presentation, but I don`t see it here. on the "Issues
of Route Optimization", the security considerations section - most
important is prefix ownership.
- Vidya: Is the goal to take a wholistic approach and
have a common solution, or to solve the scenarios on a case-by-case
A: I think it`s better to have one solution to provide
RO for all, but this document is just an input to provide some
knowledge for an RO solution
- Vidya: If we have a requirement that says we need a
solution that fits the whole space, it might be overly complicated and
nobody will use NEMO. so it`s better if we dont` have one complicated
solution. On 3rd bullet "Issues", we should have a modular approach to
RO for handoff
- Thierry: on last point for increasing delay,
draft-ietf-nemo-requirements shows the guidelines for evaluating what
we have to do. There is no mention for having one single solution or
many for RO.
- Chan-wah: I wanted to ask WG about "Goals and
Requirements" slide - on section 5, should we have a matrix to
evaluate RO solutions, or phrase it as requirements?
- Thierry: I think we should have a matrix and
- Ryuji: Is it possible to see a list of the solutions
you analyzed before coming up with the draft? Because some of the
solutions don`t say they`re a solution for RO, but they still address
A: We will give a list of the documents before
publishing the draft
- Chan-Wah: It`s better to publish a -00 first, and if
you feel the approaches are not addressed..
A: He just wants a list of what`s considered first, so
we can do that.
- NEMO Home Network Models - Pascal Thubert
- Some people had trouble understanding Mobile Home
case, so I have a presentation to clarify it
- (Slides and diagrams shown)
- Rechartering - TJ Kniveton
- (Slides shown)
- The working group has finished many of the original goals, and is wrapping up others. The question is what else (if anything) the WG should address, and how to update the charter.
- We can discuss this on the mailing list, and the target is to have a proposed charter update by IETF64.
- Vijay: I think Global HAHA could be important.
- Sri: We believe that it`s an important problem to
solve, and I think it should be solved here because it`s related
- Vijay: When the protocol was designed, it was intended
to solve geographical distribution of HAs, not Route Optimization
- TJ: It doesn`t fit neatly into the work packages, I
say that it`s like multihoming, that allows route optimization Pascal:
If you use the proxy, you do get route optimization.
- Alex: I think we
should have something on deployment. If we only do route optimization,
we don`t do improvement and support on protocol. Something relating to
IP version numbers would be fine, since there are many packets out
- Pascal: Since we don`t have NEMOOPS, we need to discuss things
like network management
- M Watari: Since we just discussed RO, some problems
that we addressed in the problem statement, can be split into several
- Vidya Narayanan: We haven`t really solved case of
LMNs, VMNs, moving in and out of mobile networks at all.
- Chan-Wah: Followup question on HAHA: isn`t it not NEMO
- Vijay: It can address reliability, and distribution of
- TJ: It was split apart, because geographical
distribution of home agents is more important in NEMO, where all the
MNN traffic has to go through HA without RO