Subject: [nemo] new nemo charter approved

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Apr 2007 10:56:44 +0300

Hi all,

After a discussion and some edits, the IESG has approved the
new charter for NEMO. Here are the changes:

1) Added the types of document (PS, Inf) for each deliverable.

2) Formulated the technical requirements of the different
cases using the speed and range of movements rather
than through the industry that uses them.

3) Changed the deliverables for the PMR and Automotive
case so that there's a rechartering step between the
approval of the requirements document and the solution
work. This does not apply to the Airliner solutions work,
however. It can proceed immediately.

4) A few editorial changes.

The reason for these changes were comments from the rest
of the IESG, in general attempting to make the charter more
precise and involve more checkpoints where the IESG or the
rest of the community can verify that we're going to the right
direction. Item 3 above is a change from what the WG initially
wanted, but was a necessary compromise to get the charter
approved.

Here's the new charter:

Network Mobility (nemo)
========================

Current Status: Active Working Group

Chair(s):
TJ Kniveton <[email-masked]>
Thierry Ernst <[email-masked]>

Internet Area Director(s):
Jari Arkko <[email-masked]>
Mark Townsley <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Technical Advisor(s):
Steven Bellovin <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
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 its point of attachment to the Internet
and thus its reachability in the network topology. The mobile network
includes one or more mobile routers (MRs) which connect the rest of
the mobile network to the global Internet.

For the purposes of this working group, a mobile network is a leaf
network; it does not carry transit traffic. Nonetheless, 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.

For the basic NEMO support case, none of the nodes behind the MR need
be aware of the network's mobility; thus, the network's movement is
completely transparent to the nodes inside the mobile network. This
design consideration was made to accommodate nodes inside the network
that are not generally aware of mobility.

Basic network mobility support is described in RFC 3963. This RFC
contains NEMO Basic Support, which is a protocol based on Mobile IPv6
(RFC 3775, 3776) that enables network mobility in an IPv6 network.

The working group is tasked with continuing to evolve RFC 3963 to
correct errors and maintain the specification. In addition, the group
works in co-operation with the MIP6 WG to design a mechanism to allow
mixed IPv4/IPv6 networks to be used.

At this point, the working group is concerned with solving deployment
issues of NEMO, primarily relating to the identified needs of the
automotive and aviation communities. The group will gather
requirements from those builders and users, and then solve the route
optimization issues necessary for optimized deployments.

Among the deployments that have issues which may be solved by NEMO
Route Optimization feature(s), we have identified three cases that
have a likelihood of requirements gathering and an Optimization
solution. These are called the Aviation case, the Automotive case, and
the Personal Mobile Router (consumer electronics) case, though the
actual technical problems are characterized by the type of movements
and environments more than by the specific industry using the
technology. The group will explore these cases to gather requirements
and, if those requirements match the capability of a NEMO RO solution
space, proceed with solving the open issues.

The WG will:

- Finish working group documents that are currently in process, and
submit for RFC. This includes prefix delegation protocol mechanisms, a
multihoming problem statement, and a MIB for NEMO Basic Support.

- Gather requirements for NEMO Route Optimization in deployment
scenarios:

(1) Airline and spacecraft community, who are deploying NEMO for
control systems, as well as Internet connectivity and entertainment
systems. This use case is characterized by fast (~ 1000 km/h) moving
objects over large distances (across continents). The main technical
problem is that tunneling-based solutions imply a roundtrip to another
continent and that BGP based solutions imply significant churn in the
global Internet routing table.

(2) Automotive industry who are deploying NEMO for in-car
communication, entertainment, and data gathering, possible control
systems use, and communication to roadside devices.  This use case is
characterized by moderately fast (~ 100-300 km/h) moving objects that
employ local or cellular networks for connectivity.

(3) Personal Mobile Routers, which are consumer devices that allow the
user to bring a NEMO network with the user while mobile, and
communicate with peer NEMO networks/MNNs.

After gathering the requirements for these types of deployments, the
working group will evaluate what type of route optimization needs to
be performed (if any), and formulate a solution to those problems.

If no requirements for those scenarios can be collected by the
deadline, it will be assumed that the work is premature, and that type
of deployment will be dropped from the list of use cases currently
addressed by NEMO.

The group will only consider airline and spacecraft solutions that
combine tunneling solutions for small movements with either federated
tunnel servers or slowly changing end host prefixes.

The group will only consider personal mobile router requirements about
optimized routes to another mobile router belonging to the same
operator.

The group will only consider automotive industry requirements to allow
MR-attached hosts to directly access the network where MR has attached
to.

Work on automotive and personal mobile router solutions requires
rechartering.

The WG will not:

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

- consider general route optimization, multihoming, or other problems
that are not related to the deployment and maintenance of NEMO
networks.

- consider or rely on the results of general routing architecture,
Internet architecture, or identifier-locator split issues that are
discussed in separate, long term efforts elsewhere in the IETF

- consider solutions that require changes from correspondent nodes in
the general Internet

The working group will endeavor to separate research issues, and refer
them to the IRTF as appropriate.

Goals and Milestones:

Apr 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG,
for Proposed Standard
Apr 2007 Submit the final doc Multihoming Problem Statement to the IESG,
for Informational
May 2007 Submit the final doc on MIB for NEMO Basic Support to the IESG,
for Proposed Standard

May 2007 Submit -00 draft on Route Optimization Needs for Aircraft and
Spacecraft Deployments
May 2007 Submit -00 draft on Route Optimization Needs for Automobile and
Highway Deployments
May 2007 Submit -00 draft on Route Optimization needs for Personal
Mobile Router

Aug 2007 Submit -00 draft for solution to aircraft/spacecraft problem

Sep 2007 Submit final doc on Route Optimization Needs for Aircraft and
Spacecraft Deployments, for Informational
Sep 2007 Submit final doc on Route Optimization Needs for Automobile and
Highway Deployments, for Informational
Sep 2007 Submit final doc on Route Optimization needs for Personal
Mobile Router, for Informational

Oct 2007 Determine how to proceed with remaining automotive/Personal
Mobile Router solutions
Oct 2007 Recharter to work on the remaining automotive/Personal Mobile
Router solutions
Jan 2008 Submit final doc for solution to aircraft/spacecraft problem to
the IESG, for Proposed Standard
May 2008 Shut down or recharter the WG to solve further identified topics

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 10 Apr 2007 13:21:31 +0200

Dear Jari, all,

Thanks for the assistance in this and the feedback.

I do have a comment about the "speed of movement". I don't get at all
why the speed would be a selective criteria, the frequency of movement
would, on the other hand. The others criterias are of course the size
of the network on the move, and the use case itself. I do think that
the major difference is in the use and not the speed.

The May 2007 milestones are too optimistic since we are already well
engaged into April.

Thierry.

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Apr 2007 15:00:13 +0300

Thierry,

> the major difference is in the use and not the speed.

Speed is one of the criteria, among others. Speed and distance of the
movement
does matter. For instance, a fast/far moving object gets easier into a
situation
where it has to tunnel to a geographically far away destination. Frequency
does matter, too, but in a different way. High movement frequency implies
a lot of updates to home agents and correspondent nodes.

> The May 2007 milestones are too optimistic since we are already well
I will take another look before sending the final charter to the
secretariat. Is there a suggestion? I don't think we should move
milestones too much, however.

Jari

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 10 Apr 2007 14:25:51 +0200

Hi,

>a lot of updates to home agents and correspondent nodes.

I do agree with that, but I think just mentioning "speed" is too
implicit and doesn't help. A better wording would mention "type of
media" and topologically distant subsequent points of attachment. To
me, the aircraft use case is very similar to the (international)
high-speed train use case (unfortunately no one from this industry
never showed up in our discussion), but still, even the French TGV
which beat the world record on track last week (at 576 km/h) is still
falling short from approaching the speed of airliners. So, "speed" is
not exactly the right criteria though I understand what you mean.

>milestones too much, however.

The current drafts are not focusing enough on RO, they deal with
requirements in a broader sense. We need more contribution, from
different sources. So, I don't see any agreement on a WG draft before
next IETF meeting, at the earliest, but waiting longer wouldn't serve
us.

Thierry.

---

From: "Davis, Terry L" <[email-masked]>
Date: Tue, 10 Apr 2007 08:54:12 -0700

Jari/Thierry

A couple relevant examples:

- Within the last couple weeks the FCC (not the FAA!) continued the ban
on cell phone usage in the US on aircraft.  The reason remains the same;
the number of cell tower hops per minute that an on aircraft user
generates while on a call creates excessive route changes in the
cellular network.

- When using most geo-satellites, the beams have a relatively small
overlap and an aircraft has only perhaps 10 minutes from acquiring a new
satellite signal until the previous one is lost.  When this beam switch
is initiated, the aircraft's ground station usually moves thousands of
miles and that often involves instantaneous jumps between continents.

- On some routes, an aircraft travels more or less down the dividing
line between two geo-satellite beam areas, this often results in the
aircraft bouncing back and forth between these beams every few minutes.

Take care
Terry

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, April 10, 2007 5:00 AM
> To: Thierry Ernst
> Cc: [email-masked]
> Subject: Re: [nemo] new nemo charter approved
> 
> Thierry,
>

---

From: Teco Boot <[email-masked]>
Date: Fri, 20 Apr 2007 11:35:09 +0200

Jari,

Sorry for a late response. I have some comments on where the NEMO WG should
not work on.

> protocols (including MANET protocols) can be used to solve these
I think the existing IETF MANET routing protocols are currently not able to
solve all problems. I agree NEMO WG should not work on this, other WGs are
chartered for it. And we have the MANEMO discussions.

> optimized routes to another mobile router belonging to the same
Why this restriction? I understand there could be policies. But I can think
of use cases requiring RO for multi-operator environments.

Regards, Teco

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Apr 2007 14:19:43 +0300

> of use cases requiring RO for multi-operator environments.

First, the reason we have a set of restrictions in the charter
is to ensure that the group stays focused on a solvable problem
and does not go into research mode trying to solve the general
mobile router RO problem (which I believe is very hard).

But the purpose of this particular restriction was really to
only state that the PMR work shall be based on the help
of the operator to set up the necessary associations, security,
etc. I.e., that there is some trusted party which can help
in the process, and that we are not talking about random
router attempting to talk to another random router in
the Internet.

But I wouldn't preclude the possibility that the resulting
protocol works in a roaming case, too. The important part is
that you have that third party available. If two mobile
routers can set up RO with the help of the local access
operator, I think its fine.

Jari