Hi Jouni, Julien
I believe the charter looks good but I would like to ask you if
deployment scenarios are covered by the charter or not (I'm thinking of
a Informational RFC)?
Let me be a bit more specific. When discussing DMM (in a 3GPP
perspective) with people I get the impression that many operators are
interested in the topic but that they have very few peering points. They
are not always interested (or they do not see the need) in deploying
more peering points since they are expensive. Perhaps the reason for
this is related to the current hierarchical architecture and will change
with a more distributed architecture.
So what do you think? Is there a need for this kind of document?
Best Regards
Conny
On 2011-12-14 09:54, jouni korhonen wrote:
Folks,
We have been working on a charter text from DMM based on the initial goal
setting and the input we received during the Taipei meeting. Note that this is
the first draft and now we are soliciting for input.
- Jouni& Julien
-------------------------------------------------------------------------
Distributed Mobility Management (DMM)
-------------------------------------
Charter
Current Status: Active
Chairs:
Julien Laganier<[email protected]>
Jouni Korhonen<[email protected]>
Internet Area Directors:
Ralph Droms<[email protected]>
Jari Arkko<[email protected]>
Internet Area Advisor:
Jari Arkko<[email protected]>
Mailing Lists:
General Discussion: [email protected]
To Subscribe: https://www.ietf.org/mailman/listinfo/mext
Archive: http://www.ietf.org/mail-archive/web/mext
Description of Working Group:
The Distributed Mobility Management (DMM) working group specifies IP
mobility, access network and routing solutions, which allow for
setting up IP networks so that traffic is distributed in an
optimal way and does not rely on centrally deployed anchors to manage
IP mobility sessions. The distributed mobility management solutions
aim for transparency above the IP layer, including maintenance of
active transport level sessions as mobile hosts or entire mobile
networks change their point of attachment to the Internet.
The protocol solutions should be enhancements to existing IP mobility
protocols, either host- or network-based, such as Mobile IPv6
[RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
NEMO [RFC3963]. Alternatively, the distributed mobility management
solution can be transparent to any underlying IP mobility protocol.
Although the maintenance of stable home address(es) and/or prefix(es)
and upper level sessions is a desirable goal when mobile hosts/routers
change their point of attachment to the Internet, it is not a strict
requirement. Mobile hosts/routers should not assume that IP
addressing including home address(es) and/or home network prefix(es)
remain the same throughout the entire upper level session lifetime.
The distributed mobility management solutions primarily target IPv6
Deployment and should not be tailored specifically to support IPv4,
in particular in situations where private IPv4 addresses and/or NATs
are used. At least IPv6 is assumed to be present in both the mobile
host/router and the access networks. Independent of the distributed
mobility management solution, backward compatibility must be
maintained. If the network or the mobile host/router do not support
the distributed mobility management enabling protocol, nothing should
break.
Work items related to the distributed mobility management include:
o Solution Requirements: Define precisely the problem of distributed
mobility management and identity the requirements for a distributed
mobility management solution.
o Best practices and Gap Analysis: Document best practices for the
deployment of existing mobility protocols in a distributed mobility
management environment and identify the limitations of each such
approach with respect to fulfillment of the solution requirements.
o If limitations are identified as part of the above deliverable,
specify extensions to existing protocols that removes these
limitations within a distributed mobility management environment.
Goals and Milestones:
Aug 2012 - Submit I-D 'Solution Requirements' as a working
group document. To be Informational RFC.
Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
group document. To be Informational RFC.
Nov 2012 - Evaluate the need for additional working group document(s)
for extensions to fill the identified gaps.
Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
consideration as an Informational RFC.
Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG for
consideration as an Informational RFC.
Mar 2013 - Conclude the working group or re-charter.
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
