Subject: [seamoby] Seamoby Minutes - Please Review

From: Patrice Calhoun <[email-masked]>
Date: Thu, 29 Mar 2001 16:06:01 -0800 (PST)

All,

Please review the following minutes, and provide comments by April 6th.

I'd like to thank La Monte again for the great minutes!

PatC
----

SEAMOBY Working Group Meeting at IETF50
Minneapolis, Minn.
March 21st, 2001

Minutes taken by La Monte H.P. Yarroll <[email-masked]>

AGENDA BASHING
1. Milestone review
2. Update on Paging Problem Statement
3. Update on Context Transfer Problem Statement
4. Update on Micro-Mobility Problem Statement
5. Update on any requirements work
6. Next Steps

No changes to Agenda.  Chair bashed the agenda physically

1. MILESTONE REVIEW
-- We're about 3 months behind original agenda
-- Paging completed WG last call and will go to IESG next week
-- Context transfer comments did come in--there will be another revision
   Significant comments were receive from WG Last Call, so need a new
   WG Last Call will be required. Design Team has started work on
   requirements.
-- MM-01 needs another revision
-- New goals and milestones will go to Secretariat next week.  Watch web site.

2. UPDATE ON PAGING, Jim Kempf

- Draft is complete, but some issues have been raised.
- Should the WG change its name to include paging?

Issue 1)
Some L2's have no paging support (no paging channel), and there doesn't seem
to be any benefit having a L3 paging protocol without any L2 support. The
conclusion is that paging is only needed when the network has a rough idea
of where the device is.

The group was asked whether the Design Team whether it is OK to assume
L2 paging for support of L3 paging?.  Consensus shows the group disagrees, and
L2 paging MUST NOT be assumed.

Issue 2)
There were some discussions on hypothetical L2s that do not support paging
mechanisms, and how they could be supported, but this is a difficult question
to answer, since we do not know what the future has in store for us.

Issue 3)
It was asked whether paging should only support Mobile IP, or some
other (yet undefined) micro-mobility protocol. The AD stated that it is too
early to answer this question at this time.

Jim detailed the process for the design team, which will be made
available on the mailing list. To subscribe to the list, see
www.diameter.org/seamoby.html.

Finally, Jim proposed a Design Team interim meeting in Menlo Park between
June 18th and the 20th, to discuss the requirements work. There is a process
involved in establishing an interim meeting, and the chair has the action item
to work this out with the Area Director. 

There were questions about whether a meeting was really necessary, and it
was noted that it helps get lots of work done in a short time frame. This is
important to Seamoby, given our aggressive deadlines.

3. UPDATE ON CONTEXT TRANSFER, Madjid Nakhjiri

The problem expressed is "In networks where hosts are mobile, the success
of real-time sensitive services like voice, video, etc. over IP networks
rests heavily the quality etc...

The things that Context Transfer operates on are properties (features)
and are measured as microflows. The state is held in what is called a
feature context. A feature context can be more general than just an
IP-layer feature (e.g. header compression).

The types of contexts mentioned in the problem statement Internet-Drafts
include Security, AAA, Header Compression state, Diffserv/Intserv, QOS
policy management, buffered data, sub network-layer state, and others. Note
that the list in the draft is not intended to be complete.

There were some comments on buffered data, which does not appear to be
a "feature", but this topic falls in the solution space, and was out of
scope for the meeting.

It was noted that the problem statements are just to establish the
assertion that there are problems that can be clearly described and
that it is worthwhile continuing the work.

There were comments from participants that context transfer should be done
for things other than mobility.

4. UPDATE ON MICRO MOBILITY, John Loughney

Prior to this discussion, the chair stated that there have been recent
developments on the charter, which will be discussed afterwards.

The problem statement expressed is "The general effort is to do as much
work locally to avoid having to cause effects deeper into the network." See
section 1.2 of the Micro-Mobility problem statement for more info.

The Design Team expressed the desire to create requirements, analyze solutions
and recommend a micro-mobility solution.

The goals of micro-mobility is to provide mobility w/o changing the mobile's
routable IP address. Reuse of Mobile IP WG protocols for mobility between
local mobility domains is also a goal. The work should be IP version neutral,
and scale well within the size of a local mobility domain.

There were some concerns in regards to how scalable a micro-mobility solution
could be, since it could be used across the Internet. This will be
addressed in the requirements phase.

The micro-mobility solution should be designed for inter-technology
heterogeneous networks, and use Mobile IP for signaling from the Mobile Node.
It should enable optionalized routing for mobile to mobile communication,
and not require triangular or trombone routing. The micro-mobility solution
should be optimized for bandwidth, provide user location confidentiality,
support connectivity to multiple AR's simultaneously and support simple
ad-hoc.

There was also a desire for this new solution to be "plug and play", but
this is out of the WG charter.

It was stated that it is very important for Mobile IP and the Seamoby MM
protocol to work together.
	  
The design team also listed the following drafts, which they
found informative for people interested in this space:
    - IPv6 MIP has many security requirements which are fulfilled by IPsec.
	-- draft-dupont-mipv6-aaa-00.txt
    - Mobile network support
	-- draft-ernst-mobileip-v6-network-01.txt
    - Mobility-aware IPsec ESP tunnels points out possible conflicts
      Mobility/Security.
	-- draft-dupont-movesptun-00.txt

It was stated that the Micro-Mobility and Context Transfer folks should
work together to make sure that their solution works together.

5. NEXT STEPS

The following points have been identified by the Micro-Mobility
design team:
	- There are MIP shortcomings for seamless hand-offs.
	- A possible new local edge mobility protocol.
	- Seamless hand-offs to access points that have the capabilities
	  required to support a given mobile.

After a meeting between the chair, ADs, and other interested parties, the
following actions will be taken:
	1) An I-D will be written that will describe the requirements
	   needed in the Mobile IP protocol to provide seamlessness. This
	   document will be sent to the Mobile IP WG.
	2) If the Design Team believes that a new routing protocol is
	   needed, the IRTF is very interested in taking over the work.
	3) The MM Design Team will write a requirements I-D for discovering
	   the best AP to hand-off a mobile to (e.g. CNP).

Item 1 is a short term work item that interested parties could work on, 
perhaps the design team itself, while item 3 would be the primary focus of
SEAMOBY.

There were some questions on whether context transfer and the new MM work
item are one and the same. These two items should be worked on separately.

There was some concern about seamoby writing a Mobile IP document, but
this document will only contain requirements, and will be given to the
Mobile IP WG to perform the necessary protocol enhancements.

The new work item (item 3) must work in conjunction with Mobile IP
fast hand-off, or any other future mobility protocol. There were also
some comments that selecting the right AP based on some properties, MAY
require that some non layer 3 criterias be used.

A question was raised on whether the paging work should take into
consideration the work that may be coming back from the IRTF, but
a well designed protocol should be designed to support a wide variety
of mobility protocols.

A context transfer question was raised about whether the context transfer
work should be applied to network failures [ed: read replication]. This
is outside the scope of the WG, but someone mentioned that one may end
up with a solution without trying.

There was also concern about the new discovery work in scenarios where 
L2 triggers are received after the hand-off occurs. This is an issue that
needs to be resolved by the WG.

Finally, a statement was made that someone didn't feel that consensus was
reached on whether there is a clean problem statement for paging.

The chair stated that the design teams are open to anyone, and the
mailing list information can be found at www.diameter.org/seamoby.html.