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 <firstname.lastname@example.org>
Phillip Neumiller <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
David Oran <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: (un)subscribe seamoby your_e-mail_address
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:
Submit I-D on Layer 3 Paging Requirements & Needs assesment
Submit Micro-Mobility Requirements I-D to IESG for consideration as Informational
Submit requirements analysis for Inter Access Point Context Transfer Protocol to IESG for consideration as Informational
Candidate Micro-Mobility Protocols are submitted, with accompanying comparison against requirements
Submit revised charter to IESG with any changes needed especially with respect to the micro-mobility evaluation
Submit Inter Access Point Context Transfer Protocol MIB to IESG for consideration as a Proposed Standard
Submit Inter Access Point Context Transfer Protocol MIB to IESG for consideration as Proposed Standard
IP Paging Protocol as Proposed Standard (if needed)
Selection of one (or convergence of many) Micro-Mobility Protocol
IP Paging Protocol MIB as Proposed Standard (if needed)
Micro-Mobility Protocol as Proposed Standard
Micro-Mobility Protocol MIB as Proposed Standard
No Current Internet-Drafts
No Request For Comments
49th IETF in San Diego
Seamoby Working Group
Chairs: Pat Calhoun (email@example.com)
Phil Neumiller (firstname.lastname@example.org)
Minutes by: La Monte Henry Piggy Yarroll (email@example.com)
As a result of the meeting, three design groups were formed. James Kempf
(firstname.lastname@example.org) will lead the paging team, Dana Blair
(email@example.com) will lead the micro-mobility team, while Gary Kenward
(firstname.lastname@example.org) will lead the context transfer team).
The design teams are responsible for coming up with a problem statement for their respective area.
- Chairs are very firm about charter.
- White gloves only
- Layer 3 paging
A point was made that the working group should first handle context transfer, given that this was the most complicated work item.
The chair stated that all work will progress in parallel.
Another point was made that paging should exist in the Mobile IP WG, but MIP has already agreed that paging is not within its charter.
A point was made that a succinct definition of WHAT Micro-mobility IS, is lacking from OUR COMMON VOCABULARY.
Sampling question: Do we need to reassess? Is MobileIP becoming sufficient (see 3 above)?
We need a clear problem statement.
A point was made that MIP may be sufficient, but there are scenarios that might need more than MIP. We need some scenarios. Is MM mobility within a subnet? Why doesn't MIP solve this? Why aren't the current radio protocols sufficient?
The MIP WG co-chair stated that we should explore the possible solutions which MIP is NOT exploring. There is an ID presented that has such a problem description., which will be presented in the meeting.
The chair stated that we need a set of requirements. We need a separate design team for a problem statement and a set of requirements.
Ideally, submit candidate protocols around about 22 February. REQUIRED is a document that compares the protocol to the requirements.
A comment was made that we should not over-narrow the scope of the WG. Another comment was made that some Mobile IP submissions might e relevant to some of our work items, and that we should take a closer look at what's going on in MIP.
An evaluation team will then select a protocol from the submitted candidates. A comment was made that evaluation teams are against the IETF mantra, and the working group should be the one that decides. There was some concern as to whether one single solution could be chosen, which the AD responded that one is sufficient, more would create confusion in the marketplace. There was many discussions on whether one or more problems are appropriate, and the problem description should address that issue.
There was another thread that questioned what kind of solutions are appropriate, whether it's routing, link or application. Some suggested routing.
- State Transfer
There are three options that the WG should evaluate:
1. Have the network nodes transfer state
2. Let the mobiles upload their state
3. Let the mobiles renegotiate with network
Comments were made that the first option seems most likely, and would probably best provide seamless mobility.
There was some discussion on what state transfer is, and isn't, but a problem statement is required, as per our charter, for the IESG to decide whether the work will be done.
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:
-- Split micro/macro (e.g. minimize reauthentication)
-- Layer 2 independent, but use what we can "Do what you can locally, but go global when necessary."
-- minimize air signaling
-- applications should not need to be mobile-aware
-- Security is important
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:
- Address HO for realtime within subnets (micro) and between subnets (macro).
- Address access, AAA, QoS, IPSec, handoff signaling.
- Common terminology
Dana presented some Micro-Mobility objectives, which should become requirements:
- Minimize packets sent/received by mobile
- Minimize time between access link changes
- Minimize lots of other stuff...
Ditto for Macro-mobility
There were a few proposed solutions:
- Combine the whole mess into a single message from the mobile
- Cache context
- Re-use existing protocols
- Avoid a new protocol
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.