NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Pat Calhoun <firstname.lastname@example.org>
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Allison Mankin <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: (un)subscribe seamoby your_e-mail_address
During the 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 mobility devices. Examples of state information that could be useful to transfer is AAA information, security context, QOS properties assigned to the user, Robust Header Compression information, etc.
Further, Standards Defining Organizations (SDOs) that work on wireless, such as 3GPP, 3GPP2, IEEE and others, 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. Furthermore, the protocols developed by the Seamoby Working Group must allow for real-time services to work with minimal disruption across heterogeneous wireless, and wired, technologies.
It is expected that SDOs working on wireless technologies will provide their input into the WG during the requirements gathering and protocol design phase.
In addition to Context Transfer, the working group has identified two more technologies that are important for use as tools for providing real-time services over IP wireless infrastructure: Handoff Candidate Discovery and Dormant Mode Host Alerting (aka "IP paging"). Another technology, micro-mobility, in which routing occurs without the Mobile IP address change, was determined by WG discussions to require research; it has been removed by the present rechartering and the topic has been addressed to the IRTF Routing Research Group. The present charter (revised from its original form) is to define and then possibly develop the three technologies. The WG will ensure that its deliverables are compatible with the Mobile IP Working Group's mobility management technology.
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 chage of communications path includes a change in communications media between the host and access networking, including changes from a wireless to a wired connection and changes between wireless technologies even under common administration.
Although the protocol used to actively re-direct the IP packet flows during a change in a mobile's point of attachment is handled by the Mobile IP WG, there is a need for preserving the context of its active IP flows. The IP flow context that might be useful to transfer could include, but not be limited to security context, policy, QOS (diffserv or intserv as needed) header compression, and accounting/AAA information.
The SeaMoby Working group will analyze the requirements and tradeoffs for the goal of transferring context information from a mobile's old access to the new access device. Depending on the results of the requirements analysis, the SeaMoby WG will develop a protocol (or start from an existing protocol such as Contract Net Protocol (CNP) or the IEEE's 802.11f) to transfer the context information for a session.
Handoff Candidate Discovery
Second, while the Mobile IP Working Group in particular is developing protocols to provide "fast handoff" solutions, the mechanisms currently under development assume that a set of candidates has already been chosen and and that handoff should be initiated to all of them. However, the selection of suitable candidates is not part of the Mobile IP WG's overall scope. The Seamoby Working Group has documented that "seamless" handoffs can best be achieved by considering multiple handoff candidates and selecting one or more of them as targets for context transfer. This problem is within scope of Seamoby. Specifically, Seamoby will define the work in a problem statement, and if needed, will define the requirements and the protocol for a handoff candidate discovery protocol, which could be used with any mobility management protocol.
Dormant Mode Host Alerting
Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered.
All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs.
The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups.
Submit I-D on Layer 3 Paging Requirements & Needs assesment
Submit revised charter to IESG with any changes needed especially with respect to the micro-mobility evaluation
Submit I-D on Dormant Mode Host Alerting Requirements to IESG for consideration as Informational
Submit Inter Access Point Context Transfer Problem Statement to IESG
Submit Handoff Candidate Discovery Problem Statement to IESG
Interim Meeting to review pending Inter Access Point Context Transfer and Handoff Candidate Discovery work
Candidate Mode Host Alerting Protocol Protocols are submitted, with accompanying comparison against requirements
Submit Inter Access Point Context Transfer Protocol Requirements to IESG for consideration as Informational
Submit Handoff Discovery Requirements I-D to IESG for consideration as Informational
Candidate Inter Access Point Context Transfer Protocols are submitted, with accompanying comparison against requirements
Candidate Handoff Discovery Protocols are submitted, with accompanying comparison against requirements
Dormant Mode Host Alerting Protocol to IESG for consideration as a Proposed Standard
Inter Access Point Context Transfer Protocol to IESG for consideration as a Proposed Standard
Handoff Discovery Protocol to IESG for consideration as a Proposed Standard
Dormant Mode Host Alerting Protocol MIB to IESG for consideration as a Proposed Standard
Submit Inter Access Point Context Transfer Protocol MIB to IESG for consideration as a Proposed Standard
Submit Handoff Discovery Protocol MIB to IESG for consideration as a Proposed Standard
Dormant Mode Host Alerting ('IP Paging') Problem Statement
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.
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
East of PAAR identification
Control over TAR selection
Simultaneous connections to two ARs from MN
Power conservation issues
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:
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.
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
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.
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?
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.
The MORE BOF
The BoF held for one hour under the chairmanship of James Kempf (SUN) and Paul Reynolds (Orange), in Seamoby working group on 5th August 2001.
James Kempf presented the agenda and a brief history of MORE BoF.
It then followed the following four presentations:
Central Idea of 1st Presentation: (By Paul Reynolds-Orange)
It presented the operators' requirements. The presentation was comprehensive and elucidated the vital requirements that were pre-submitted in the form of Internet draft (ID). The presenter also emphasized that the 3G operators' voice is not very strong in 3GPPs, thus operators want to take their requirements directly to IETF so that appropriate protocols, meeting the operators and ISPs requirements, could be fabricated.
Central idea of 2nd Presentation: (John Waclawsky-Cisco)
The key idea of the second presentation was to specify Service/Application Interface Requirements. It explained the need of continuous or un-interrupted mobile access to Internet applications and services. This means application ubiquity and continuity across a range of heterogeneous access networks.
Central idea of 3rd Presentation:(Atsushi Takeshita, DoCoMo Communications Labs USA)
Focused and stressed on the need of classification of the requirements. The presenter also suggested a few methods for categorizing the requirements, e.g., the requirements that are irrelevant to IETF's scope may be eliminated and the requirements not covered by the ID may be added.
Central Idea of 4th Presentation (Toni Mcauley-Telcordia-Itsumo)
The title of the presentation was Service Negotiation Requirements in Mobile Networks. It mainly discussed the requirements and problems combining Mobility and QoS. It also highlighted some additional requirements like, flexible options for vendor and service provider, and the significance of independent protocol work i.e independent of other protocols (e.g., mobility management, AAA, configuration).
After the presentations there were quite a lot comments and questions among which the most gravity carrying questions/comments were:
It was questioned that why the need of Interworking with PSTN is not adequately touched upon in the MORE draft to which Paul replied that since there are two types of operators (green field operators and the operators with existing infrastructure who wanted the interoperability), we should present the both groups equally.
It was commented that the draft covers a huge chunk of the problem space. Is it possible to view the MISP (Mobile Internet Service Provider) as just bit pipes? It was also suggested to separate applications from bit pipe stuff, basically breaking the MORE draft into several sub-drafts and submitting each sub-draft to the relevant group. It was also commented that how can service providers provide more/new services. It seemed that there was a general agreement to make an informational draft/RFC narrating mobile operators requirements. It will not only be useful for Mobile Operators (to take their voice to IETF) but also useful for IETF (for fabricating the protocols needed). Above all, operators could take their voice to the right audience in the right working groups.
It was remarked that most of the issues appear to have come from the fixed wireline ISPs, therefore cross-domain operation seems important. Some requirements need more justification, as most of them appear to be based on business model than cellular specific model. James Kempf tried to satisfy the interrogators by saying that no business model implied, wants requirements to drive protocols. Further more it was concluded that there is a need to filter out those requirements, which strictly apply to the Mobile Operators and ISPs.
It was also said that the most of the requirements need justification, as they seem to be business oriented rather than access technology. BoF presenters tried to satisfy the audience through bouncing suitable answers in the light of MORE BoF and operators perspectives. It was also clarified that main purpose of the BoF is to influence the protocols.
It was stated that connecting mobile operators requirements with wireless/wireline ISPs' at IETF platform is fundamentally new, furthermore somebody mentioned that education is needed to get awareness of these. To the former comment, presenter stated that different types of networks need to talk to each other for migration as well as various other reasons (financial, political, etc) and to the later, there was a general agreement to make an informational draft/RFC revealing the mobile operators requirements. It was also commented that there are a lot of protocols that can/may satisfy the operators requirements, however there is a need of sharing of knowledge.
`MORE' BoF (unofficial):
Classification of Requirements
Service Negotiation Requirements in Mobile Networks
The Internet Draft & email discussions