Subject: [seamoby] Preliminary Meeting minutes - please review

From: Pat Calhoun <[email-masked]>
Date: Wed, 22 Aug 2001 08:30:42 -0700

All,

Below is the first draft of the minutes from the London meeting. I'd like
to thank Jim Kempf for taking the minutes.

I'd also like folks to read the minutes carefully. There were lots of 
intense discussions, which made minute taking very difficult. I've had
to make small changes to enhance readability, and want to make sure that
I haven't messed up.

Comments appreciated,

PatC
----

Seamoby Meeting - Monday August 6th

Agenda Bashing and document/milestone review

L2 Triggers - James Kempf

   The goal is to collect requirements from various WGs for L2 triggers 
   to optimize handoff.

   Requirements can then be used to design an API or protocol if desired
   Also available to L2 designers

   Draft discusses requirements from the following
	 Fmipv6 and low latency MIPv4
	 Seamoby context transfer

   Issue: Why are there two sets of requirements, one for MIP and
          one for seamoby

	  Because there are two application areas
	  Should they be merged into a single one?

   What about other areas, such as CAR, paging, QOS?

	  MIP handover and seamoby CT were immediate generator of 
	  requirements for L2 triggers, so we included them.

   Should we also include requirements from these other areas?
   If so, can we get volunteers familiar with the subjects to 
   write the requirements?

   Comment: CAR is relevant to the both MIP and CT, but why QOS? 
            This makes sense because QOS indications are immediate, 
	    so they could be used as an L2 trigger. However, someone 
	    else stated that an L2 trigger is normally viewed as an 
	    interrupt, but as a list of capabilities of the link layer.

   Next Steps:
	Add additional requirements, edit text following the outcome
	of this IETF meeting.

	Where should the work happen? MIP? Seamoby, or perhaps a joint WG?
	Or should a new WG be created under the Sub-IP area?

	Draft ready for IETF last call at IETF 53.

   Comment: This is handoff related, so maybe it belongs in Mobile IP.
   Comment: One of the first requirements in CT was to define the 
	    triggers, but this work is not ready yet for publishing 
	    in this draft, given this draft's intended deadlines.
   Comment: Worried about separating the requirements for Mobile IP 
	    and CT in the triggers, since this seems the wrong approach. 
   Comment: Encourage to do the trigger work, but keep it simple.

Issues in CAR - Govind Krishnamurthi

   Seamless IP mobility protocols assume that the identity of the 
   target AR (TAR) for MN's handover is known to the current AR.
   TAR needs to be selected based on MN's requirements, AR 
   capabilities and local policies

   Problem Statement:
	To determine a set of CARs (i.e. the ARs that physically 
	adjacent (PAARs) to the current AR and have the capabilities 
	to support the MN's requirements)

   This information serves as input to the TAR selection process 
   at the time of handoff.

   Comment: What does physically adjacent mean? It means not 
	    necessarily topologically adjacent.

   Issues for discussion
	Pros and cons of anticipated vs. dynamic CAR discovery vs 
	hybrid CAR discovery
	       Radio traffic
	       East of PAAR identification
	       Control over TAR selection
	       Simultaneous connections to two ARs from MN
	       Power conservation issues
	       Others

   Comment: Should seamoby develop protocols separately for the 
	    anticipated and the dynamic case, and leave it to 
	    the network operator to choose one over the other?

	    Will these have hooks to build a Hybrid CAR discovery 
	    protocol

   Capabilities Exchange: What are the relevant capabilities? Should 
	    seamoby be involved in defining capabilities at all? 
	    If not, which WG will do this?

   Comment: How is this different from Mobile IP? Why can't router 
	    advertisements be used? Because it is more than just 
	    advertising itself, but also its capabilities.

   Comment: cdma2000 already has its own handoff discovery methods 
	    at L2. But we cannot expect them to use this protocol. 
	    It may be useful in heterogeneous environments.
	
   Comment: Should the mobile be allowed to discovery the candidates? 
	    It really depends upon the type of environment. It does, 
	    however, requirement that mobiles be simultaneously attached 
	    to several wireless networks. How does this protocol use 
	    to handle ping-pong effects? 

   Comment: Handoff candidate will requirement some security relationships,
	    and therefore could be unscalable, and therefore this work 
	    shouldn't happen. Having a GSM/802.11 roaming agreement is 
	    a hard thing to setup.

   Comment: If we expect to do fast handoff at L3, this work will be needed.

   Comment: Some items used in the discovery process are known, or 
	    handled, by different nodes in the network. Some by the 
	    mobile and others by the network elements.

   Comment: The mobile must be allowed to request this information.

   Hum: Is CAR useful work? Yes
   Hum: Should mobiles be involved? Yes

Moving Forward on Paging - Pat Calhoun

   Pat Calhoun discussed the proposed timelines for the paging work, which
   is listed below from an earlier e-mail to the mailing list:

   Here is a proposal on how to proceed:

   1. Folks submit protocols by no later than September 14th.
   2. Each protocol submission must also include an accompanying
      I-D that compares the protocol against the requirements. For
      each requirement, the author must state whether the protocol
      complies to the requirements, and if so, how. Note that we aren't
      looking for a dissertation, but also not looking for empty claims.
   3. Myself (or an appointed editor) will compile the list into a
      single Internet Draft, which will be used to ease comparison. This
      draft will be available on September 28th.
   4. The document will be submitted to the WG, and a Last Call will be
      made to make sure that the WG agrees with the comparison. WG Last
      Call ends Oct 12th.
   5. If there is a clear winner, then we begin protocol design based on
      leading protocol. Otherwise, discussions within the WG will commence
      to determine which protocol is best for our purposes. In either case,
      the WG will not rubber stamp the protocol. Input from the WG will 
      be taken to ensure that the spec can withstand a WG Last Call.

      Our milestones show that we have a potential interim meeting in September.
      We can use this meeting to discuss the paging proposals, should we need
      a face-to-face. However, if such a meeting occurs, it would most likely
      fall within the mid-October timeframe.

Some Considerations for Context Transfer - Gary Kenward

   The basic issue is that we don't know in which direction a
   mobile may be going. There are special cases where this is not
   true.

   CT can happen at anytime.

   If this does happen, then you may need to CT to many ARs. This is
   a one-to-many CT requirement, and this should be in the requirements
   Internet-Draft.

   CT shouldn't be tied to a CAR.

   Comment: Is the user of ANR intended? As opposed to AR and AG, which
	    are commonly used terms? Hierarchy complicates things.

   Comment: Because of Hierarchy, is CT done at the edges, or in the
	    core network?

Seamoby Meeting - Wednesday August 8th

[note: the first hour of the meeting was used by the MORE BOF]

Discussion on Pending CT Requirements Issues - Pat Calhoun

   There are four remaining issues that need to be resolved:
	 Issue 2
	 Issue 4
	 Issue 7
	 Issue 5

   Issue 2

	 4.2 Not much favor on list - CT must define common IP 
	     level (layer 3) triggers to initiate CT, support mobile
	     to initiate CT. Already there.
	 4.3 New requirement. CT must separate signaling to initiate 
	     CT from actual transfer.

	 Should the requirement be dropped? 4.3 is proposed text. 
	 Not currently in requirements. 

	 Comment: We must have this feature and the mobile must initiate.

	 Comment: This requirement isn't needed. It doesn't disallow any
		  feature.

	 Comment: 4.3 is not for mobile initiated. 4.2 is what triggers
		  cause a context transfer, but we won't define what they
		  are.

	 Comment: If there are L2 triggers, do I have to defined L3 
		  triggers? Triggers without signaling may be OK, but
		  4.3 is not necessary. 4.2 is a must.

	 Comment: We need both. CT is useful if no L2 triggers exist.

	 Hum: How many folks want to keep this text with some wordsmithing?
	      Consensus is yes.

   Issue 4 & 7

	 These two issues are bundled since they both address proactive
	 and reactive text. Issue 4 proposes new text, while 7 is a request
	 to remove it from the doc.

	 Comment: Why remove it? Two modes are too limited. There may
		  be more than two modes, and having this in the reqs
		  may limit future extensions.

	 Comment: Don't know yet, perhaps revisit this issue later and
		  move on to better understood requirements?

	 Comment: This talks about protocol modes, but they are 
		  examples rather than modes. They are useful to
		  discuss in terms of examples of how a protocol may
		  work, but not normative.

	 Comment: Perhaps this should be reconsidered during the
		  design phase. Don't put it in as a requirement.

	 Comment: This is a misunderstanding. The original timing
		  requirements were there. To define the timing
		  requirements we need to dig deeper and need to
		  define its relation to handover. This was not
		  supposed to be modes. A solution may cover both,
		  but don't have to cover modes. It should be 
		  removed if it is expected to be a mode.

	 Comment: Mode is the problem, not proactive or
		  reactive. The use of the term capability
		  is more descriptive, and should be used instead
		  of mode. There is no bit in the header, this
		  just describes how CT happens at different
		  time relative to a handoff.

	 Comment: Do we need to define temporal characteristics?
		  This depends upon when a trigger was sent.

	 Comment: Need to shift from mode to timing. Timing in
		  which you act. CT tends to resolve around time
		  restrictions. Dismiss timing, then revisit.

	 Comment: Mode->Capabilities will not solve the problem.
		  MN attaches to a new router, is context there
		  or not? Pro - it's there. Re - It isn't there.
		  Too much confusion. Put the text in an appendix.

	 Comment: Proposed text. If context there when MN attaches
		  to a new router, pro. If there after, re.

	 Comment: Are timing requirements in the spec? Will it
		  delay handover? May want to define pro and re.
		  Otherwise, triggers may be needed. Confusion is
		  based on starting and ending events.

	 Comment: Presentation, is a distinction.

	 Comment: Does there need to be a timing requirement?

	 Comment: Cedric's text makes me the least happy. The
		  way it is phrased it is difficult to understand.
		  I don't know whether the discussion states that
		  you implement two modes. Other than that, OK.

	 Comment: Timing requirements is in the current doc in
		  section 5. The current requirements for pro
		  ad re are wrong. They specify too tight 
		  timing, and need to be fixed. Not happy with
		  delegating to an appendix. It is an important
		  part of CT and for seamlessness.

	 Comment: It must be a requirement. Proactive is there 
		  when a packet arrives at a new AR. If we 
		  remove it, we'll be back in the same debate
		  later.

	 Comment: How would a router react if the first packet
		  had a code point, and the QoS context wasn't
		  there? Would it drop it? So there are timing
		  requirements.

	 Comment: Some environments exist where you don't have
		  handoff notifications, so you have to live with
		  what you have.

	 Comment: But some networks have it.

	 Comment: Always try to get context transferred prior
		  to handover. Don't remove the possibility
		  of moving context.

	 Comment: It is important to have the capability for
		  flexibility, as early and late. This shouldn't
		  be an appendix.

	 Comment: We can push or pull context. Pro or re depends
		  on timing.

	 Comment: This is purely a local API issue.

	 Comment: This makes a difference. Multi-phasic
		  means send state when handover is happening.
		  Later, state isn't there for packet to be
		  forwarded. Some other state may be transferred
		  in other phases. The value is the concept,
		  landscape for people to work on solutions.

	 Comment: Proactive mode, previous router initiates.
		  Reactive the new router initiates. 

	 Comment: Both routers should be able to initiate. You
		  may be proactive in either direction.

	 Hum: Here are the current options:
	      1) leave as is.
	      2) use word capabilities.
	      3) remove text from doc -5 
	      4) remove text to appendix -5 
	      5) state that CT before, during, or after
	         handover. - many.

	Consensus shows folks want option 5.

   Issue 5

	Multiphasic requirement. Transfer context in phases allowing
	time critical state first, and not critical later.
	This is a MAY. 

	Comment: Irrelevant as to actual payloads, time
		 critical is not the issue.

	Hum: How wants to adopt this text? Consensus shows yes.

Some CT Issues - Charlie Perkins

   CT-Handover interworking

      IP handover - process which enables an MN to acquire network
		    layer connectivity when it changes access 
		    routers, allowing it to send an receive IP 
		    packets. IP handover is a routing issue.

      CT - Process that facilitates continuing offering of IP 
	   features, typically during terminal mobility.

	   CT addresses performance of transport protocols assuming
	   IP connectivity is available.

      Is handover complete without CT?

	   NO - MIP work not complete w.o. Seamoby.

	   YES - Two concepts, preferred time relationship between
	         two. Need to preserve connection on link.

      Also time relationship, before, during, or after handover, 
      highlights distinction between handover and CT.

      Features have own characteristics, how to reinitialize
      if not transferred, etc.

   Transport Considerations

      Should it run over SCTP? Why? Some advantages in particular 
      cases. Time critical - can't get after retransmission, then 
      discard. 

      Can't use TCP/SCTP with this? 

      Comment: SCTP does have a mode to run this way. No fragmented 
	       packets is bad. Or do we use a well defined transport 
	       or define own transport?

      Comment: Does RFC allow? Separate draft allows.

      Comment: Nobody can state reliability, timing, and security 
	       requirements except in relation to individual features.

      Comment: Can't answer in general, depends on feature, need to 
	       do prototype and figure out. 

      Comment: Some precedent, punting on reliable vs. unreliable, 
	       have both profiles. Different kinds of situations,
	       stateless operation may do it.

      Here is Charlie's proposal

	   1) Start looking at particular features, standard
	      features, how to transfer, build from there.
	      Profile types.

	   2) Some standard features as sub-options of
	      handover signaling messages.

	   3) Facilitate CT for different CT,

      Comment: Interoperable contexts. Worry about negotiating
	       two access routers or end points, what does this
	       mean? 

   CT Framework.

      sending header compression, new AR can say no. If it can 
      handle but interoperability problems, then bad. Set out 
      data structures and fields. 

      Negotiation. One target, or do negotiation. Might not need 
      CAR discovery.

      Comment: Many ways to use profiles. Target AR selection. 
	       See if target supports profile. Also, do transfer, 
	       see if AR supports. Well defined profile.

      Comment: Both sides understand context. Run transfer. Should 
	       not include negotiations. CT profile type is a good 
	       idea. Different technologies, how would they understand?

      Comment: CT can be done independently of CAR selection.

      Comment: Negotiation is too slow. What would new AR do if failed? 
	       Can't relay useful info back. 

      Comment: Decouple CAR selection from CT. Could do it proactively. 

      Comment: What happens if CT fails? Security, reliability, link 
	       failure, no AR. Requirements should mention this case.

      Comment: Failure, then either renegotiate or?

      Comment: Too premature, depends on feature.

      Comment: Consider context negotiation failure. Third option, 
	       don't hand off. Target AR is same as source AR.

      Comment: Renegotiation should not be part. Should fail.

      Comment: Negotiation should be separate. Features should tell 
	       failover. Can tell mobile everything failed, OK.

      Comment: An optimization, just takes longer time if fails.

      Comment: Specific context could signal success or failure
	       if needed. No ACK or NACK needed, then no indication. 
	       If so, then can.

      Comment: Request/reply sequence, should be possible to ACK/NACK.

      Comment: Implies tie CT to handover signaling. Separate signaling,
	       how to indicate?

      Comment: Handover, CT not done, may have to renegotiate.

      Comment: CT only for handover or other things. If only handover,
	       think about CT and profile types, mobility framework.

      Comment: IRTF micromobility scheme, still should allow CT. 

      Comment: Mobility may be part of different messaging. 

      Comment: Notification. Assumption to notify mobile, assumptions 
	       are a can of worms. Complexity could be avoided by taking
	       a more piece by piece approach. AR section phase, 
	       different protocols transfer differently. Some way to get
	       from a -> b.

      Comment: Devil in details.

      Comment: Time to handover. MORE BOF. Session mobility. Could benefit
	       from CT. Reqs. for context movement for things that are not L3.

      Comment: Use CT for non time critical.

      Comment: Originator may need to know if context transferred.

      Comment: Assumed that CT is between ARs. MN is agent of CT, not 
	       necessarily the AR.

      Comment: 4.6 ARs as peers. 

      Comment: CT between any two points. Too complex. More immediate 
	       problem. Solve AR/AR issue. Handover can be done w.o. 
	       CT. but what about if service is special. Dropping VoIP 
	       to best effort not an option.

      Comment: App wants a particular of service, separable protocols. 

      Comment: Partial handover. Inter-technology. Might want to drop certain 
	       flows but not others. Can't get full blown. Conf call, hit
	       lower rate, drop some service.

      Comment: App cares about mandatory context, don't run and don't pay.

      Comment: Policy, negotiation is complex.

      Comment: MN carries own context. Can't prevent a router 
	       from determining whether a device is appropriate.
	       Proper protocol design should help. Is context delivery 
	       mechanism authenticated?

      Comment: Discussion during problem statement. Context not the 
	       same as on old router. Make CT during link handover. 
	       Can be expensive and error prone. Not just auth. CT are 
	       not mirror images.

      Comment: MN carry context, pay as you go. The router will affect. 
	       May have to rely on transmission over the air of context. 

      Comment: Another req. is mutual auth. Don't allow for MN to be 
	       agent of CT, could download from MN, then push to new AR.
	       Otherwise ARs may need mutual auth. Item 4.6.

      Comment: Mobile retrieve context and handoff to new, mobile 
	       moves to new AR, requests CT, mobile sends back up again.

      Comment: Route on old AR to new AR, push to new AR through old 
	       AR. Handoff after. Don't assume any access technology, or
	       even IP address discovery.

      Comment: Need to have context features push to new AR via old. 
	       MN may do, also cases where.

      Comment: CT between ARs is more important than via MN, but 
	       needs to be resolved later. Could be agents, etc.
	       Different kinds of context. Different kinds of transfer.

      Comment: Too detailed, req doc should not be a checklist. AR 
	       peers is logical notion, independent of path. Many 
	       scenarios. Separate puzzle, independent reqs.

      Comment: CT doesn't require that it is stored at AR when 
	       transferred, brought to current AR at time of transfer. 
	       No advantage to push to MN. 

      Comment: Not always bandwidth to push from MN to router. Looking 
	       at simplest case, AR to AR, sec assc., etc. Could establish
	       associate. BU in MIP, problem. Req doc should not prohibit.

      Comment: Examples of apps, ideas w.r.t architecture, might be a 
	       good idea to collect ideas. Focus discussion, too diffuse. 

      Comment: Framework doc does describe.

      Comment: Close off requirements, look at existing doc, any 
	       limiting what they need, they address, get finished. 

      Comment: Agree. Request, like to see context for a feature. 
	       Address issue of what is appropriate to send between
	       two. Add a doc to WG, requirements for particular feature 
	       transfer. WG can bash back and forth.

Action Items - Pat Calhoun

       Minutes to list. 
       Gary updates req doc, last call, issues during last call.

Next Steps - Pat Calhoun

     CT Reqs - done by Salt Lake City.

     CT protocol submission begins  end of September

     AD: Req. in some WGs with a lot of practice, forces into
	 interoperability, req to bring out issues, no implied
	 req. during solution phase, could be useful 
	 even if incomplete.

    Requirements doc by end of Sept. 

    DMHA wants to do conf calls after protocol comparisons, instead of
    a face to face meeting.

---

From: Pars MUTAF <[email-masked]>
Date: Fri, 31 Aug 2001 23:15:23 +0200

Hello all;

We have submitted an I-D called "DPAC: Dynamic Paging
Area Configuration" for DMHA (aka IP paging).

Interested people can find it at the following address until
it appears in IETF directories:

http://www.inrialpes.fr/planete/people/mutaf/draft-mutaf-dpac-00.txt

Millions of comments? No problem :-)
Thank you in advance.

Regards,
pars

PS: Below is the abstract:

Abstract

This document defines dynamic paging area configuration extensions
to IP paging. The motivation is three fold: First, paging areas
are auto-configured, hence human effort is minimized. Second,
paging area shapes adapt to host mobility characteristics, hence
more efficient. Third, paging area sizes are variable, allowing
future optimization.

Dynamic paging area configuration can be regarded as the major
advantage of having L3 paging areas.