2.3.18 Network Mobility (nemo)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional NEMO Web Page

Last Modified: 2005-06-28

Chair(s):

TJ Kniveton <tj@kniveton.com>
Thierry Ernst <ernst@sfc.wide.ad.jp>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Technical Advisor(s):

Steven Bellovin <smb@cs.columbia.edu>

Mailing Lists:

General Discussion: nemo@ietf.org
To Subscribe: nemo-request@ietf.org
Archive: http://www.ietf.org/mail-archive/web/nemo/index.html

Description of Working Group:

The NEMO Working Group is concerned with managing the mobility of an
entire network, which changes, as a unit, its point of attachment to
the Internet and thus its reachability in the topology. The mobile
network includes one or more mobile routers (MRs) which connect it to
the global Internet.

A mobile network is assumed to be a leaf network, i.e. it will not
carry transit traffic. However,it could be multihomed, either with a
single MR that has multiple attachments to the internet, or by using
multiple MRs that attach the mobile network to the Internet.

Initially,the WG will assume that none of the nodes behind the MR will
be aware of the network's mobility, thus the network's movement needs
to be completely transparent to the nodes inside the mobile
network. This assumption will be made to accomodate nodes inside the
network that are not generally aware of mobility.

A basic approach for network mobility support is for each Mobile
Router to have a Home Agent, and use bidirectional tunneling between
the MR and HA to preserve session continuity while the MR moves. The
MR will acquire a Care-of-address from its attachment point much like
what is done for Mobile Nodes using Mobile IP. This approach allows
nesting of mobile networks, since each MR will appear to its
attachment point as a single node.

The WG will take a stepwise approach by standardizing some basic
support mechanisms based on the bidirectional tunneling approach, and
at the same time study the possible approaches and issues with
providing more optimal routing than can be had with (potentially
nested) tunneling. However, the WG is not chartered to actually
standardize a solution to such route optimization for mobile networks
at this point in time.

The WG will work on:

- A threat analysis and security solution for the basic problem
(tunneling between HA and MR)

- A solution to the basic problem for both IPv4 and IPv6. The solution
will allow all nodes in the mobile network to be reachable via
permanent IP addresses, as well as maintain ongoing sessions as the MR
changes its point of attachment within the topology. This will be done
by maintaining a bidirectional tunnel between the MR and its Home
Agent. The WG will investigate reusing the existing Mobile IPv6
mechanisms for the tunnel management, or extend it if deemed
necessary.

- An informational document which specifies a detailed problem
statement for route optimization and looks at various approaches to
solving this problem. This document will look into the issues and
tradeoffs involved in making the network's movement visible to some
nodes, by optionally making them "NEMO aware". The interaction between
route optimization and IP routing will also be described in this
document. Furthermore, security considerations for the various
approaches will also be considered.

The WG will:

- Ensure that solutions will scale and function for the different
mobile network configurations, without requiring changes to
Correspondent Nodes in the Internet. All solutions will aim at
preserving route aggregation within the Internet and will satisfy an
acceptable level of security (a thorough survey of new threats and an
analysis of their severity will be conducted)

- Ensure that various mechanisms defined within other IETF WGs will be
useful for mobile networks. To achieve this, the NEMO WG will interact
with other WGs when needed, and may place requirements on the
protocols developed by those WGs.

The WG will not:

- consider routing issues inside the mobile network. Existing routing
protocols (including MANET protocols) can be used to solve these
problems.

Goals and Milestones:

Done  Submit terminology and requirements documents (for Basic support).
Done  Submit NEMO Basic Support to IESG
Done  Submit WG draft -00 on Threat Analysis and Security Requirements for NEMO.
Done  Submit WG draft -00 on Multihoming Problem Statement
Done  Submit WG draft -00 on NEMO Basic Support Usages
Apr 04  Submit Terminology as Informational to IESG
Apr 04  Submit Goals and Requirements as Informational to IESG
Apr 04  Submit WG draft -00 on Prefix Delegation for NEMO
May 04  Submit WG draft -00 on MIB for NEMO Basic Support
Jun 04  Submit WG draft -00 on Analysis of the Solution Space for Route Optimization
Aug 04  Shut down or recharter the WG to solve route optimization

Internet-Drafts:

  • draft-ietf-nemo-requirements-04.txt
  • draft-ietf-nemo-terminology-03.txt
  • draft-ietf-nemo-home-network-models-04.txt
  • draft-ietf-nemo-multihoming-issues-03.txt
  • draft-ietf-nemo-mib-01.txt
  • draft-ietf-nemo-ro-problem-statement-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3963 Standard Network Mobility (NEMO) Basic Support Protocol

    Current Meeting Report
    NEMO Working Group, IETF63 Minutes

    NEMO Working Group Minutes
    IETF63 - August 3, 2005 - Paris


    Compiled by TJ Kniveton

    Note: The jabber logs for this working group session are available at http://www.mobilenetworks.org/nemo/ietf63/nemo-ietf63-jabber-log.txt

    1. Agenda, welcoming, and WG doc status

      2. Agenda

      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

    2. NEMO Basic Support Status and Deployment

      1. Management Information Base - Sri Gundavelli

        2. Slides

        • 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.

      2. NEMO Implementation status on BSD (SHISA) and Linux (NEPL) - Romain KUNTZ

        3. Slides
        • 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

      3. TAHI NEMO BS Test Suite and Next Interoperability Test Event - Hiroshi MIYATA

        4. Slides
        • 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.

      4. ISO Activities on NEMO BS - Keisuke Uehara

        5. Slides
        • 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

      5. Status of the Mip6trans DT (presentation in the MIP6 WG) - Vijay Devarapalli

        6. Slides
        (This is a high level overview; more detailed slides presented in MIP6 working group)
        • 3 scenarios considered:
          1. 1. MN in IPv4-only network and wants to reach IPv6 services
          2. 2. HA is behind an IPv4 NAT without public v4 address
          3. 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)

    3. NEMO Multihoming

      1. Analysis of Multihoming in Network Mobility Support - ChanWah Ng


        2. (See slides for issues presented) Slides
        • 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.

      2. Token based Duplicate Network Detection for split NEMO - Masayuki Kumazawa

        3. Slides
        • 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 shown?
        • 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

    4. Route Optimization

      5. Slides

      1. 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?
          --About 6.
        • Is the content what the WG expected?
          --About 15.
        • 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?
          --None.
        • 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 you.

      2. 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 basis?
          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 requirements both.
        • 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 it
          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.

    5. NEMO Home Network Models - Pascal Thubert

      6. Slides
      • Some people had trouble understanding Mobile Home case, so I have a presentation to clarify it
      • (Slides and diagrams shown)

    6. Rechartering - TJ Kniveton

      7. Slides
      • (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 there.
      • 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 pieces
      • 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 specific?
      • Vijay: It can address reliability, and distribution of home agents.
      • 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

    Slides

    Agenda
    NEMO-MIB
    NEMO Basic Support Implementation Status
    TAHI NEMO Tester
    CALM --Continuous Air Interface for Long and Medium range
    V4 traversal for IPv6 mobility protocols - Scenarios
    NEMO Multihoming Issues
    Token based Duplicate Network Detection for split mobile network
    Network Mobility Route Optimization Problem Statement
    Home Network Models
    NEMO Charter Update