NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Pat Calhoun <pcalhoun@eng.sun.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Allison Mankin <mankin@east.isi.edu>
David Oran <oran@cisco.com>
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/
History
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.
Description
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.
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 |
· SeaMoby Micro Mobility Problem Statement
· Problem Description: Reasons For Doing Context Transfers Between Nodes in an IP Access Network
SEAMOBY Working Group Meeting at IETF50
Minneapolis, Minn.
March 21st, 2001
Minutes taken by La Monte H.P. Yarroll <piggy@acm.org>
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.
None received.