2.7.2 Context and Micro-mobility Routing (seamoby)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 20-Nov-00


Pat Calhoun <pcalhoun@eng.sun.com>
Phillip Neumiller <phil_neumiller@3com.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Technical Advisor(s):

David Oran <oran@cisco.com>

Mailing Lists:

General Discussion:seamoby@cdma-2000.org
To Subscribe: majordomo@cdma-2000.org
In Body: (un)subscribe seamoby your_e-mail_address
Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/

Description of Working Group:


During the recent fast handoff discussions within the Mobile IP WG, a need for a new protocol was identified that would allow state information to be transferred between edge devices (e.g. Foreign Agents). Examples of state information that needs to be transferred is AAA information, security context, QOS properties assigned to the user, Robust Header Compression information, etc.

The proposed SeaMoby WG will take over the routing protocols that are no longer within the Mobile IP WG's charter, and it will develop the new protocol used to transfer state information between edge devices. It will be in the Transport Area even though it includes routing protocols, because these routing protocols for micro-mobility have close association with end-to-end performance.

Some of the 3G SDOs are hoping that the IETF will be able to provide a set of protocols that will enable them to provide real-time services over an IP infrastructure, and, along with Mobile IP, SeaMoby is expected to provide such protocols. It is expected that the 3G organizations will provide their input into the WG during the requirements gathering and protocol design phase.


There are a large number of IP access networks that support mobility of hosts. For example, wireless Personal Area Networks (PANs) and LANs, satellite and cellular WANs. The nature of this roaming is such that the communication path to the host changes frequently, and rapidly. In many situations, the change of communications path includes a change in communications media between the host and access networking, including changes from a wireless to a wired connection.

To support these changes, there is a need for support in the access network to actively re-direct the IP packet flows, while preserving the context of all active IP flows. The IP flow context includes, but is not limited to security context, policy, QOS, congestion indication/management, header compression and accounting.

The SeaMoby Working Group will develop a protocol to provide fast mobility within an access network, and thereby reduce the latency of the data/traffic flow to/from the mobile node. By improving the performance of intra-domain handoffs, the protocol will also help the overall latency of traffic using multiple, heterogeneous network access infrastructures. The protocol will provide "micro-mobility", where specialized signalling is used in an Administrative Domain to support the movement of IP nodes across IP subnets.

The SeaMoby Working group will also analyze the requirements and tradeoffs for the goal of transferring context information from a mobile's old access to the new access point (versus accessing needed context over a distance).

Depending on the results of the requirements analysis, the SeaMoby Working Group will develop a protocol to transfer the context information for a session. The context information to be transferred includes QOS, header compression state, policy, security context, congestion management state, AAA information, etc. Transferring context state is expected to provide a more robust handoff to the user, and applications. Quality of service (QOS) state may include both diffserv and intserv information, as needed.

Lastly, the Working Group will investigate the use of paging at the IP layer in networks, and if it is deemed necessary, a protocol will be developed to tackle this problem. IP paging is typically used in micro-mobility protocols to quickly track a mobile that has moved from its previously known point of attachment, while in dormant mode. IP paging is not the application (e.g. it is not simply a robust form of instant messaging, but rather it is the protocol for fast setup of a routing path to a mobile that may be triggered by an application message for that mobile.

All work produced by the Working Group will support both IPv4 and IPv6, will be congestion friendly, and will undergo a security review prior to WG last call.

The Working Group will coordinate closely with the aaa, cnrp, impp, mobileip, pilc, and rohc working groups.

Goals and Milestones:

Nov 00


Submit I-D on Layer 3 Paging Requirements & Needs assesment

Jan 01


Submit Micro-Mobility Requirements I-D to IESG for consideration as Informational

Jan 01


Submit requirements analysis for Inter Access Point Context Transfer Protocol to IESG for consideration as Informational

Feb 01


Candidate Micro-Mobility Protocols are submitted, with accompanying comparison against requirements

Mar 01


Submit revised charter to IESG with any changes needed especially with respect to the micro-mobility evaluation

Mar 01


Submit Inter Access Point Context Transfer Protocol MIB to IESG for consideration as a Proposed Standard

Mar 01


Submit Inter Access Point Context Transfer Protocol MIB to IESG for consideration as Proposed Standard

Apr 01


IP Paging Protocol as Proposed Standard (if needed)

May 01


Selection of one (or convergence of many) Micro-Mobility Protocol

Jun 01


IP Paging Protocol MIB as Proposed Standard (if needed)

Aug 01


Micro-Mobility Protocol as Proposed Standard

Oct 01


Micro-Mobility Protocol MIB as Proposed Standard

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

49th IETF in San Diego
Seamoby Working Group

Chairs: Pat Calhoun (pcalhoun@eng.sun.com)

Minutes by: La Monte Henry Piggy Yarroll (piggy@em.cig.mot.com)

Meeting Summary:

As a result of the meeting, three design groups were formed. James Kempf
(james.kempf@eng.sun.com) will lead the paging team, Dana Blair
(dblair@cisco.com) will lead the micro-mobility team, while Gary Kenward
(gkenward@nortelnetworks.com) will lead the context transfer team).

The design teams are responsible for coming up with a problem statement for their respective area.


1. Agenda

Agenda Bashing
Ground Rules


2. Seamoby Reference Model

Phil Neumiller presented a reference model with a picture of some kinds of MIP peer within IP and "Hints" going down to layer 2. There was also another diagram provided by Phil that shows a network doing a vertical handoff. There was much controversy on what the pictures meant, and where some functions resided, but the main focus was to show that multi-technology handoffs should be possible. How it is done is something that can only be answered once a problem statement has been written.

There were more discussions on how QoS is affected in a seamoby environment, and another diagram showing an actual handoff taking place. There was a comment that Mobile IP already solves this problem, but Mobile IP doesn't handle mobile routers or subnets.

3. Seamoby Concerns (John Loughney)

John Loughney presented some concerns, and in his presentations he showed a long list of handover types, followed by a list of definitions of the various handover types, such as seamless, fast, smooth, etc. There was a slide that discussed context transfer, which may include compression state, policy, security, etc. There was a question as to what kind of state we really want to send, what makes sense? There was a comment that end-to-end QoS is obviously out of scope, given that the edge has no control over the network (and the endpoint), so there are no QoS guarantees.

John then presented some of his requirements, which are:

His drafts will be announced on the mailing list.

4. SeaMoby Header Compression (Rajeev Koodli)

Rejeev is presenting his two Internet Drafts:

The problem is how to move the compression state from an old router to a new router. The proposed solution is HCRP, where the MN asks the new router to fetch the context from the old router.

There are many compression profile types, so what kind of compression info is needed? A possible work item is to define a bunch of compression profiles, but a question was raised as to what the savings were. The response was that packet loss over the air could cause problems for state handoff.

5. Cellular IP

Andrew Campbell presented Cellular IP, and stated that more information on Cellular IP can be found on the web site (both the code and the docs). The discussion was not Mobile IP does not scale as well as IP, and that something new is required. Many comments were made in regards to this presentation, but the fact of the matter is that we need to understand the problem before we look into the solutions.

More questioned how a stateful protocol can be more scalable than a stateless protocol, and questions on how L3 paging can be used, etc. However, these were all solutions, and not requirements.

There was a comment on why this presentation was made here, given that we aren't at the solutions stage yes, which drew some applause some the audience. The response from the chair was fairness.

6. State transfer between Access Routers during Handoff

Context Transfer++ (draft-oneill-handoff-state-00.txt) was presented, and briefly summarized some of the states that need to be transferred to expose some of the gory bits. The transferred state might have some attachment to surrounding universe of the edge router.

Some approaches were discussed, such as allowing the mobile to rebuild the state on the new router using the appropriate protocols (e.g. RSVP, Mobile IP, etc). It was noted that it make take several seconds to rebuild the state. Another approach is to assume that the Mobile Node can securely upload all of the state to the new router, but the speaker stated that there are some trust issues in this model. Another model is to allow the routers to exchange the states directly.

An example of state that could be transferred was multicast information.
We could not do anything, and let the mobile rejoin, have the mobile send IGMP information to the router, or have the old router send the IGMP information to the new router.

The recommended approach was to document the state, design a solution and document it per protocol. First, we should document the requirements for generalized context transfer.

There were questions whether this could be handled at layer 2, and the feeling was no.

A question was raised why is there a need for seamless handoff in the first place, where Charlie Perkins answered "S a m e s H nd v r".

7. Buffer Mgmt (Charlie Perkins, the Tallest MIP Designer)

Rate of beacons in MIP is too slow to do voice buffering, but if you increase the beacon rate you can make it work.
Hand over 2-3 buffers and you get pretty-good results.
Holy Grail: Do smooth voice hand-over.
Problem statement (paraphrase): "Mobile node has some context and needs to retrieve it later..."

8. Realtime Mobile IPv6

Dana Blair presented draft-blair-rt-mobileipv6-seamoby-00.txt. The goals of the draft are:

Dana presented some Micro-Mobility objectives, which should become requirements:

There were a few proposed solutions:

There was a question whether minimizing packets meant round trips, and the speaker answered that packets matter too. Another questioned why multicasting was missing (as a state to transfer), and the answer was that it hadn't come up, and it did complicate the problem. Another questioned whether a single packet solution (to transfer state) generalized lots of other stuff, but someone stated that some state information may not fit in a single packet. Lastly, someone questioned the reliability of a single packet handoff.

9. Next steps
Chair: Who wants to participate in the problem statement? (Many hands)
Who wants to do the administrative overhead?
Context Transfer: Gary Kenward
MM: Dana Blair
Paging: James Kempf

A comment was made that all micro-mobility people should simply post their comments to the main list. A follow-on stated that everybody has their own terminology, and a team would help tp to unify the terminology.

Another comment was made that the dates in the milestone are too aggressive.
The chair responded that this was caused by the latency in fixing the charter to address IESG comments, and its approval. This can be changed at the next charter review.


None received.