Oops, that was the wrong attachment!! <was, Re: draft charter text updates in github..>
"Charles E. Perkins" <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Organization | Blue Skies |
| Message-ID | <539B8D8F.3020408__8789.07454102791$1402703270$gmane$org@computer.org> |
Oops, that was the wrong attachment!! Please excuse my error. The proper file is attached to this message. Regards, Charlie P. On 6/13/2014 4:37 PM, Charles E. Perkins wrote: > > Hello Jouni, > > Thanks for incorporating some of my suggested revisions. > > Follow-up below... > > On 6/13/2014 3:41 AM, Jouni Korhonen wrote: >>> /* What about RFC 5568 (FMIP)? */ >> >> There is the "..such as.." so I think there is no really need to lost >> all possible MIP6 variations. > > FMIP is particularly important when developing solutions > that are aimed at localizing handover signaling, and I think > it deserves particular mention, at the cost of adding ten or > fifteen more characters to the charter text. > >> >>> /* What does "eventually" mean?? */ >> >> erm.. removed.. > > Well, it's still there. So, maybe, the other dozen or so > revisions that didn't make it into charter revision #9 were > intended to be included also...? I'll await further follow-up > until I can see whether my other comments were rejected > or simply overlooked. Please take a look. > > In particular, misuse of the definite article "the" can be > interpreted to restrict development to a single solution. > And, as has been discussed, I think that the dmm WG is > very likely to develop a suite of smoothly interacting > solutions. Moreover, it should be observed that on a > single mobile node, different applications might require > different treatment for their end-point IP address. This > might also encourage further use of multiple IPv6 addresses > by a single mobile node, which in my opinion is a positive > feature. Or it could elevate the importance of proper > treatment for flow mobility. > > > Is it just me, or do other people prefer "RFC 6275" to > "RFC6275"? > >> >>> >>> Also, the suggested dates for chartered work items seem >>> quite unrealistic to me. >> >> ;-) +3 months? > > That would at least enable some believability. > >> >> >>> I noticed that part of the charter fit nicely in my 80-column >>> (vi) text window, and part of the charter does not fit nicely. >>> I could also fix that if desired. >> >> Fixed. > > Thanks! > > For convenience, I attached the rfcdiff output from my previous > text of the charter compared to today's version #9. If doing so is > not helpful, please let me know. > > Regards, > Charlie P. > > > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm -- Regards, Charlie P. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
Diff dmm_charter-Jun10,2014b.txt - dmm_charter-v9.txt.htm
(text/html, 54.4 KB)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- saved from url=(0102)file:///C:/Users/charliep/Downloads/Diff%20%20dmm_charter-Jun10,2014b.txt%20-%20dmm_charter-v9.txt.htm -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Style-Type" content="text/css">
<title>Diff: dmm_charter-Jun10,2014b.txt - dmm_charter-v9.txt</title>
<style type="text/css">
body { margin: 0.4ex; margin-right: auto; }
tr { }
td { white-space: pre; font-family: monospace; vertical-align: top; font-size: 0.86em;}
th { font-size: 0.86em; }
.small { font-size: 0.6em; font-style: italic; font-family: Verdana, Helvetica, sans-serif; }
.left { background-color: #EEE; }
.right { background-color: #FFF; }
.diff { background-color: #CCF; }
.lblock { background-color: #BFB; }
.rblock { background-color: #FF8; }
.insert { background-color: #8FF; }
.delete { background-color: #ACF; }
.void { background-color: #FFB; }
.cont { background-color: #EEE; }
.linebr { background-color: #AAA; }
.lineno { color: red; background-color: #FFF; font-size: 0.7em; text-align: right; padding: 0 2px; }
.elipsis{ background-color: #AAA; }
.left .cont { background-color: #DDD; }
.right .cont { background-color: #EEE; }
.lblock .cont { background-color: #9D9; }
.rblock .cont { background-color: #DD6; }
.insert .cont { background-color: #0DD; }
.delete .cont { background-color: #8AD; }
.stats, .stats td, .stats th { background-color: #EEE; padding: 2px 0; }
</style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0">
<tbody><tr bgcolor="orange"><th></th><th> dmm_charter-Jun10,2014b.txt </th><th> </th><th> dmm_charter-v9.txt </th><th></th></tr>
<tr><td><a name="diff0001"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> </span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left">Description of Working Group:</td><td> </td><td class="right">Description of Working Group:</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0002"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> The Distributed Mobility Management (DMM) working group specifies IP</td><td> </td><td class="rblock"> The Distributed Mobility Management (DMM) working group specifies</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> mobility, access network and routing solutions, which allow for</td><td> </td><td class="rblock"> IP mobility, access network and routing solutions, which allow for</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> setting up IP networks so that traffic can be expedited between</td><td> </td><td class="right"> setting up IP networks so that traffic can be expedited between</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0003"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> mobile nodes and correspondent nodes. DMM solutions do not necessarily</td><td> </td><td class="rblock"> mobile nodes and correspondent nodes. <span class="insert">The</span> DMM solutions do not</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> rely on a single centrally deployed anchor to manage IP mobility</td><td> </td><td class="rblock"> necessarily rely on a single centrally deployed anchor to manage</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> sessions for the duration of the sessions. DMM solutions</td><td> </td><td class="rblock"> IP mobility sessions for the duration of the sessions. DMM</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> aim for transparency above the IP layer, including maintenance of</td><td> </td><td class="rblock"> solutions <span class="insert">should</span> aim for transparency above the IP layer,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> active transport level sessions when mobile hosts or mobile</td><td> </td><td class="rblock"> including maintenance of active transport level sessions when</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> networks change their point of attachment to the Internet.</td><td> </td><td class="rblock"> mobile hosts or mobile networks change their point of attachment</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> to the Internet.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0004"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Traditional wireless networks use a hierarchical structure that has</td><td> </td><td class="rblock"> Traditional wireless networks use a hierarchical structure that</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> led primarily to centralized deployment models, where a small number</td><td> </td><td class="rblock"> has led primarily to centralized deployment models, where a small</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> of mobility anchors manage both mobility and reachability for a mobile</td><td> </td><td class="rblock"> number of mobility anchors manage both mobility and reachability</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> node. Currently, some wireless networks are evolving away from</td><td> </td><td class="rblock"> for a mobile node. Currently, some wireless networks are evolving</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> such hierarchical structure; a DMM model for</td><td> </td><td class="rblock"> away from such hierarchical structure; a DMM model for mobility</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> mobility management can be useful to them. DMM fosters</td><td> </td><td class="rblock"> management can be useful to them. DMM fosters such a distributed</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> such a distributed deployment model by relocating</td><td> </td><td class="rblock"> deployment model by relocating forwarding functions to improve</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> forwarding functions to improve performance -- as an example, closer</td><td> </td><td class="rblock"> performance -- as an example, closer either to the mobile node or</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> either to the mobile node or the corresponding node.</td><td> </td><td class="rblock"> the corresponding node.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0005"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> DMM solutions should be based on existing IP mobility</td><td> </td><td class="rblock"> DMM solutions should be based on existing IP mobility protocols,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> protocols, either host- or network-based, such as Mobile IPv6</td><td> </td><td class="rblock"> either host- or network-based, such as Mobile IPv6 [RFC6275,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, <span class="delete">5844]</span> and NEMO</td><td> </td><td class="rblock"> 5555], Proxy Mobile IPv6 [RFC5213, <span class="insert">5844],</span> and NEMO [RFC3963].</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">/* What about RFC 5568 (FMIP)? */</span></td><td> </td><td class="rblock"> However, mobility management is not restricted to the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> [RFC3963]. However, mobility management is not restricted to the</td><td> </td><td class="rblock"> abovementioned IP mobility protocols; solutions may extend</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> abovementioned IP mobility protocols;</td><td> </td><td class="rblock"> existing protocols (for example, routing protocols) or even be</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> solutions may extend existing protocols (for example,</td><td> </td><td class="rblock"> based on an entirely new protocol. Routing based proposals must</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> routing protocols) or even be based on an entirely new protocol.</td><td> </td><td class="rblock"> not propagate routing updates outside the IGP routing domain.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Routing based proposals</td><td> </td><td class="rblock"> When extending protocols that are not based on Mobile IP,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> must not propagate routing updates outside the IGP routing domain.</td><td> </td><td class="rblock"> solutions should be reviewed and ratified by the WGs having the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">/* Does this disallow Binding Update? */</span></td><td> </td><td class="rblock"> "ownership" of those protocols.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> When extending protocols that are not based on Mobile IP, solutions</td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> should be reviewed and ratified by the WGs having the "ownership" of</td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> those protocols.</td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> In contrast to existing IETF standard IP mobility protocols,</td><td> </td><td class="right"> In contrast to existing IETF standard IP mobility protocols,</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0006"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> mobility management signalling paths and</td><td> </td><td class="rblock"> mobility management signalling paths and end user traffic</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> end user traffic forwarding paths may differ; those mobility</td><td> </td><td class="rblock"> forwarding paths may differ; those mobility related functions may</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> related functions may be located in separate network nodes. Solutions</td><td> </td><td class="rblock"> be located in separate network nodes. Solutions may also specify</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> may also specify the selection between the</td><td> </td><td class="rblock"> the selection between the care-of addresses and home</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> care-of addresses and home address(es)/prefix(es) for different</td><td> </td><td class="rblock"> address(es)/prefix(es) for different application use cases.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> application use cases.</td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0007"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> When mobile hosts/routers change their point of attachment to the network,</td><td> </td><td class="rblock"> When mobile hosts/routers change their point of attachment to the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> maintenance of stable home address(es) or prefix(es) is a desirable goal</td><td> </td><td class="rblock"> network, <span class="insert">Internet-wide</span> maintenance of stable home address(es) or</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> but not a strict <span class="delete">requirement.</span></td><td> </td><td class="rblock"> prefix(es) is a desirable goal but not a strict <span class="insert">requirement on DMM</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Therefore, home address(es) and/or</td><td> </td><td class="rblock"><span class="insert"> solutions.</span> Therefore, home address(es) and/or home network</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> home network prefix(es) may change during</td><td> </td><td class="rblock"> prefix(es) may change during application level session lifetime,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> application level session lifetime, unless otherwise indicated</td><td> </td><td class="rblock"> unless otherwise indicated to the mobile node/router and its</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> to the mobile node/router and its applications from the network.</td><td> </td><td class="rblock"> applications from the network.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0008"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> DMM solutions are primarily targeted at IPv6 deployments and should not</td><td> </td><td class="rblock"> DMM solutions are primarily targeted at IPv6 deployments and</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> be required to support IPv4, specifically in situations</td><td> </td><td class="rblock"> should not be required to support IPv4, specifically in situations</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> where private IPv4 addresses and/or NATs are used. IPv6 is</td><td> </td><td class="right"> where private IPv4 addresses and/or NATs are used. IPv6 is</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0009"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> assumed to be present in both the mobile host/router and the access</td><td> </td><td class="rblock"> assumed to be present in both the mobile host/router and the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> networks. DMM solutions must maintain backward compatibility.</td><td> </td><td class="rblock"> access networks. DMM solutions must maintain backward</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> If the network or the mobile host/router do not</td><td> </td><td class="rblock"> compatibility. If the network or the mobile host/router do not</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> support the distributed mobility management protocol, that</td><td> </td><td class="rblock"> support the distributed mobility management protocol, that should</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> should not prevent the mobile host/router gaining <span class="delete">an</span> access to the</td><td> </td><td class="rblock"> not prevent the mobile host/router gaining <span class="insert">basic</span> access <span class="insert">(i.e.,</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> network.</td><td> </td><td class="rblock"><span class="insert"> nomadic)</span> to the network.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> The DMM solutions should not distinguish between physical or</td><td> </td><td class="right"> The DMM solutions should not distinguish between physical or</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> virtualised networking functions. However, whenever applicable,</td><td> </td><td class="right"> virtualised networking functions. However, whenever applicable,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> clarifications for specific networking function deployment models</td><td> </td><td class="right"> clarifications for specific networking function deployment models</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> are in scope and encouraged.</td><td> </td><td class="right"> are in scope and encouraged.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> The DMM working group will also work on maintenance-oriented and</td><td> </td><td class="right"> The DMM working group will also work on maintenance-oriented and</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0010"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> incremental extensions to the Mobile IPv6 protocol, specified</td><td> </td><td class="rblock"> incremental extensions to the Mobile IPv6 protocol, <span class="insert">such as those</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> in <span class="delete">RFC 5213, RFC 5844, RFC 5555,</span> and <span class="delete">RFC 6275.</span></td><td> </td><td class="rblock"> specified in <span class="insert">RFC5213, RFC5844, RFC5555, RFC5568,</span> and <span class="insert">RFC6275.</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> Work items related to distributed mobility management include:</td><td> </td><td class="right"> Work items related to distributed mobility management include:</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0011"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> o Distributed mobility management deployment models and scenarios: describe</td><td> </td><td class="rblock"> o Distributed mobility management deployment models and scenarios:</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> the expected high level network architectures and deployment models where</td><td> </td><td class="rblock"> describe the expected high level network architectures and</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> distributed mobility management protocol <span class="delete">solutions</span> would apply.</td><td> </td><td class="rblock"> deployment models where <span class="insert">the</span> distributed mobility management</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> protocol <span class="insert">solution</span> would apply.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0012"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> o Enhanced mobility anchoring: define protocol <span class="delete">solutions</span> for a gateway and</td><td> </td><td class="rblock"> o Enhanced mobility anchoring: define protocol <span class="insert">a solution</span> for a</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> mobility anchor assignment and mid-session mobility anchor switching</td><td> </td><td class="rblock"> gateway and mobility anchor assignment and mid-session mobility</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> that <span class="delete">go</span> beyond what has been, for example, described in <span class="delete">RFC 6097,</span> 6463,</td><td> </td><td class="rblock"> anchor switching that <span class="insert">goes</span> beyond what has been, for example,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> and 5142. <span class="delete">A solution should also define a mechanism for preserving</span></td><td> </td><td class="rblock"> described in <span class="insert">RFC6097,</span> 6463, and 5142.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> ongoing mobility sessions in a single administrative or IGP routing</span></td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> domain, possibly directing traffic towards a new anchor.</span></td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0013"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> o Forwarding path and signalling management: the mobility agent that handles</td><td> </td><td class="rblock"> o Forwarding path and signalling management: the mobility agent</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> mobility signalling interacts with network elements in the DMM network</td><td> </td><td class="rblock"> that handles <span class="insert">the</span> mobility signalling interacts with <span class="insert">the</span> network</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> for managing the forwarding state associated with a mobile node's IP traffic.</td><td> </td><td class="rblock"> elements in the DMM network for managing the forwarding state</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> These two functions may or may not be collocated. Furthermore, the forwarding</td><td> </td><td class="rblock"> associated with a mobile node's IP traffic. These two functions</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> state may also be distributed into multiple network elements instead of a</td><td> </td><td class="rblock"> may or may not be collocated. Furthermore, the forwarding state</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> single network <span class="delete">element (e.g., anchor). Protocol</span> extensions <span class="delete">will be specified</span></td><td> </td><td class="rblock"> may also be distributed into multiple network elements instead</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> to allow <span class="delete">the abovementioned</span> forwarding path and signalling management.</td><td> </td><td class="rblock"> of a single <span class="insert">anchor like</span> network <span class="insert">element. Define required</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> protocol</span> extensions to allow <span class="insert">described</span> forwarding path and</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> signalling management.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0014"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> o Exposing mobility state to mobile nodes and network nodes: define solutions</td><td> </td><td class="rblock"> o Exposing mobility state to mobile nodes and network nodes:</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> that allow, for example, mobile nodes <span class="delete">to</span> select <span class="delete">either a</span> care-of <span class="delete">address or</span></td><td> </td><td class="rblock"> define solutions that allow, for example, mobile nodes select</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> a</span> home <span class="delete">address,</span> depending on <span class="delete">an application's</span> mobility needs. In order to</td><td> </td><td class="rblock"> <span class="insert">between</span> care-of <span class="insert">addresses and</span> home <span class="insert">addresses</span> depending on <span class="insert">the</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> enable this functionality, the network side control functions and other</td><td> </td><td class="rblock"><span class="insert"> applications'</span> mobility needs. In order to enable this</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> networking nodes must also be able to <span class="delete">exchange</span> appropriate <span class="delete">control information,</span></td><td> </td><td class="rblock"> functionality, the network side control functions and other</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> as well as</span> eventually to the mobile nodes and their applications.</td><td> </td><td class="rblock"> networking nodes must also be able to <span class="insert">signal</span> appropriate</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">/* What does "eventually" mean?? */</span></td><td> </td><td class="rblock"> <span class="insert">metadata information between each other, and</span> eventually to the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> mobile nodes and their applications.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0015"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> The working group may decide to extend the current milestones based on the new</td><td> </td><td class="rblock"> The working group may decide to extend the current milestones based</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> information and knowledge gained during working on other documents listed in</td><td> </td><td class="rblock"> on the new information and knowledge gained during working on other</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> initial milestones. The possible new documents and milestones must still fit into</td><td> </td><td class="rblock"> documents listed in initial milestones. The possible new documents</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> the overall DMM charter scope.</td><td> </td><td class="rblock"> and milestones must still fit into the overall DMM charter scope.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left">Goals and Milestones:</td><td> </td><td class="right">Goals and Milestones:</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0016"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Nov 2014 - Submit 'The deployment models and scenarios' as a working group document(s).</td><td> </td><td class="rblock"> </td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> To be Informational RFC.</td><td> </td><td class="rblock"> Nov 2014 - Submit 'The deployment models and scenarios' as a working</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Nov 2014 - Submit 'Enhanced mobility anchoring' as a working group <span class="delete">document. To be</span></td><td> </td><td class="rblock"> group document(s). To be Informational RFC.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> Proposed Standard.</span></td><td> </td><td class="rblock"> </td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> Nov 2014 - Submit 'Forwarding path and signaling management' as a working group</span></td><td> </td><td class="rblock"> Nov 2014 - Submit 'Enhanced mobility anchoring' as a working group</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> document. To be Proposed Standard.</td><td> </td><td class="right"> document. To be Proposed Standard.</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0017"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> <span class="delete">Feb 2015 - Submit 'Exposing mobility state to mobile nodes and network nodes' as a</span></td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> working group document(s). To be Proposed Standard.</span></td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0018"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Feb 2015 - Submit 'The deployment models and scenarios' submitted to the IESG.</td><td> </td><td class="rblock"> <span class="insert">Nov 2014 - Submit 'Forwarding path and signaling management' as a</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> To be Informational RFC.</td><td> </td><td class="rblock"><span class="insert"> working group document. To be Proposed Standard.</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> Mar 2015 - Submit 'Enhanced mobility anchoring' <span class="delete">submitted to the IESG. To be</span></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> Proposed Standard.</span></td><td> </td><td class="rblock"><span class="insert"> Feb 2015 - Submit 'Exposing mobility state to mobile nodes and network</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> Mar 2015 - Submit 'Forwarding path and signaling management'</span> submitted to the IESG.</td><td> </td><td class="rblock"><span class="insert"> nodes' as a working group document(s). To be Proposed</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Standard.</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> </td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> Feb 2015 - Submit 'The deployment models and scenarios' submitted to</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> the IESG. To be Informational RFC.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> </td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> Mar 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> To be Proposed Standard.</td><td> </td><td class="right"> To be Proposed Standard.</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0019"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> <span class="delete">Jul</span> 2015 - Submit <span class="delete">'Exposing mobility state to mobile nodes</span> and <span class="delete">network nodes'</span> submitted</td><td> </td><td class="rblock"> </td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> <span class="insert">Mar</span> 2015 - Submit <span class="insert">'Forwarding path</span> and <span class="insert">signaling management'</span> submitted</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> to the IESG. To be Proposed Standard.</td><td> </td><td class="right"> to the IESG. To be Proposed Standard.</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0020"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> </td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> <span class="insert">Jul 2015 - Submit 'Exposing mobility state to mobile nodes and network</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> nodes' submitted to the IESG. To be Proposed Standard.</span></td><td class="lineno" valign="top"></td></tr>
<tr><td></td><td class="left"></td><td> </td><td class="right"></td><td></td></tr>
<tr bgcolor="gray"><th colspan="5" align="center"><a name="end"> End of changes. 20 change blocks. </a></th></tr>
<tr class="stats"><td></td><th><i>94 lines changed or deleted</i></th><th><i> </i></th><th><i>99 lines changed or added</i></th><td></td></tr>
<tr><td colspan="5" align="center" class="small"><br>This html diff was produced by rfcdiff 1.41. The latest version is available from <a href="http://www.tools.ietf.org/tools/rfcdiff/">http://tools.ietf.org/tools/rfcdiff/</a> </td></tr>
</tbody></table>
X-Generator: pyht 0.35
<!-- args: {'--oldcolour': 'red', '--width': '', 'difftype': '--html', 'filename2': '\r\nDescription of Working Group:\r\n\r\n The Distributed Mobility Management (DMM) working group specifies\r\n IP mobility, access network and routing solutions, which allow for\r\n setting up IP networks so that traffic can be expedited between\r\n mobile nodes and correspondent nodes. The DMM solutions do not\r\n necessarily rely on a single centrally deployed anchor to manage\r\n IP mobility sessions for the duration of the sessions. DMM\r\n solutions should aim for transparency above the IP layer,\r\n including maintenance of active transport level sessions when\r\n mobile hosts or mobile networks change their point of attachment\r\n to the Internet.
\r\n \r\n Traditional wireless networks use a hierarchical structure that\r\n has led primarily to centralized deployment models, where a small\r\n number of mobility anchors man
age both mobility and reachability\r\n for a mobile node. Currently, some wireless networks are evolving\r\n away from such hierarchical structure; a DMM model for mobility\r\n management can be useful to them. DMM fosters such a distributed\r\n deployment model by relocating forwarding functions to improve\r\n performance -- as an example, closer either to the mobile node or\r\n the corresponding node.\r\n\r\n DMM solutions should be based on existing IP mobility protocols,\r\n either host- or network-based, such as Mobile IPv6 [RFC6275,\r\n 5555], Proxy Mobile IPv6 [RFC5213, 5844], and NEMO [RFC3963].\r\n However, mobility management is not restricted to the\r\n abovementioned IP mobility protocols; solutions may extend\r\n ex
isting protocols (for example, routing protocols) or even be\r\n based on an entirely new protocol. Routing based proposals must\r\n not propagate routing updates outside the IGP routing
domain.\r\n When extending protocols that are not based on Mobile IP,\r\n solutions should be reviewed and ratified by the WGs having the\r\n "ownership" of those protocols.\r\n\r\n In contrast to existing IETF standard IP mobility protocols,\r\n mobility management signalling paths and end user traffic\r\n forwarding paths may differ; those mobility related functions may\r\n be located in separate network nodes. Solutions may also specify\r\n the selection between the care-of addresses and home\r\n address(es)/prefix(es) for different application use cases.\r\n\r\n When mobile hosts/routers change their point of attachment to the\r\n network, Internet-wide maintenance of stable home address(es) or\r\n prefix(es) is a desirable g
oal but not a strict requirement on DMM\r\n solutions. Therefore, home address(es) and/or home network\r\n prefix(es) may change during application level session lifetime,\r\n unless
otherwise indicated to the mobile node/router and its\r\n applications from the network.\r\n\r\n DMM solutions are primarily targeted at IPv6 deployments and\r\n should not be required to support IPv4, specifically in situations\r\n where private IPv4 addresses and/or NATs are used. IPv6 is\r\n assumed to be present in both the mobile host/router and the\r\n access networks. DMM solutions must maintain backward\r\n compatibility. If the network or the mobile host/router do not\r\n support the distributed mobility management protocol, that should\r\n not prevent the mobile host/router gaining basic access (i.e.,\r\n nomadic) to the network.\r\n \r\n The DMM solutions should not distinguish between physical or\r\n virtualised ne
tworking functions. However, whenever applicable,\r\n clarifications for specific networking function deployment models\r\n are in scope and encouraged. \r\n \r\n The DMM working
group will also work on maintenance-oriented and\r\n incremental extensions to the Mobile IPv6 protocol, such as those\r\n specified in RFC5213, RFC5844, RFC5555, RFC5568, and RFC6275. \r\n\r\n Work items related to distributed mobility management include:\r\n\r\n o Distributed mobility management deployment models and scenarios:\r\n describe the expected high level network architectures and\r\n deployment models where the distributed mobility management\r\n protocol solution would apply.\r\n \r\n o Enhanced mobility anchoring: define protocol a solution for a\r\n\tgateway and mobility anchor assignment and mid-session mobility\r\n\tanchor switching that goes beyond what has been, for example,\r\n\tdescribed in RFC6097, 6463, and 5142.\r\n
\r\n o Forwarding path and signalling management: the mobility agent\r\n\tthat handles the mobility signalling interacts with the network\r\n\telements in the DMM network for managing t
he forwarding state\r\n\tassociated with a mobile node\'s IP traffic. These two functions\r\n\tmay or may not be collocated. Furthermore, the forwarding state\r\n\tmay also be distributed into multiple network elements instead\r\n\tof a single anchor like network element. Define required\r\n\tprotocol extensions to allow described forwarding path and\r\n\tsignalling management.\r\n \r\n o Exposing mobility state to mobile nodes and network nodes:\r\n\tdefine solutions that allow, for example, mobile nodes select\r\n\tbetween care-of addresses and home addresses depending on the\r\n\tapplications\' mobility needs. In order to enable this\r\n\tfunctionality, the network side control functions and other\r\n\tnetworking nodes must also be able to signal appropriate\r\n\tmetadata in
formation between each other, and eventually to the\r\n\tmobile nodes and their applications.\r\n \r\n The working group may decide to extend the current milestones based\r\n on the new infor
mation and knowledge gained during working on other\r\n documents listed in initial milestones. The possible new documents\r\n and milestones must still fit into the overall DMM charter scope.\r\n \r\nGoals and Milestones:\r\n\r\n Nov 2014 - Submit \'The deployment models and scenarios\' as a working\r\n group document(s). To be Informational RFC.\r\n\r\n Nov 2014 - Submit \'Enhanced mobility anchoring\' as a working group\r\n document. To be Proposed Standard.\r\n\r\n Nov 2014 - Submit \'Forwarding path and signaling management\' as a\r\n working group document. To be Proposed Standard.\r\n\r\n Feb 2015 - Submit \'Exposing mobility state to mobile nodes and network\r\n nodes\' as a working group document(s). To be Proposed\r\n
\t Standard.\r\n\r\n\r\n Feb 2015 - Submit \'The deployment models and scenarios\' submitted to\r\n the IESG. To be Informational RFC.\r\n\r\n Mar 2015 - Submit \'Enhanced mobilit
y anchoring\' submitted to the IESG.\r\n To be Proposed Standard.\r\n\r\n Mar 2015 - Submit \'Forwarding path and signaling management\' submitted\r\n to the IESG. To be Proposed Standard.\r\n \r\n Jul 2015 - Submit \'Exposing mobility state to mobile nodes and network\r\n nodes\' submitted to the IESG. To be Proposed Standard.\r\n\r\n', 'filename1': 'Description of Working Group:\r\n\r\n The Distributed Mobility Management (DMM) working group specifies IP\r\n mobility, access network and routing solutions, which allow for\r\n setting up IP networks so that traffic can be expedited between\r\n mobile nodes and correspondent nodes. DMM solutions do not necessarily\r\n rely on a single centrally deployed anchor to manage IP mo
bility\r\n sessions for the duration of the sessions. DMM solutions\r\n aim for transparency above the IP layer, including maintenance of\r\n active transport level sessions when mobi
le hosts or mobile\r\n networks change their point of attachment to the Internet.\r\n \r\n Traditional wireless networks use a hierarchical structure that has\r\n led primarily to centralized deployment models, where a small number\r\n of mobility anchors manage both mobility and reachability for a mobile\r\n node. Currently, some wireless networks are evolving away from\r\n such hierarchical structure; a DMM model for\r\n mobility management can be useful to them. DMM fosters\r\n such a distributed deployment model by relocating\r\n forwarding functions to improve performance -- as an example, closer\r\n either to the mobile node or the corresponding node.\r\n\r\n DMM solutions should be based on existing IP mobility\r\n p
rotocols, either host- or network-based, such as Mobile IPv6\r\n [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO\r\n/* What about RFC 5568 (FMIP)? */\r\n [RFC3963]. However, mo
bility management is not restricted to the\r\n abovementioned IP mobility protocols;\r\n solutions may extend existing protocols (for example,\r\n routing protocols) or even be based on an entirely new protocol.\r\n Routing based proposals\r\n must not propagate routing updates outside the IGP routing domain.\r\n/* Does this disallow Binding Update? */\r\n When extending protocols that are not based on Mobile IP, solutions\r\n should be reviewed and ratified by the WGs having the "ownership" of\r\n those protocols.\r\n\r\n In contrast to existing IETF standard IP mobility protocols,\r\n mobility management signalling paths and\r\n end user traffic forwarding paths may differ; those mobility\r\n related functions may be located in
separate network nodes. Solutions\r\n may also specify the selection between the\r\n care-of addresses and home address(es)/prefix(es) for different\r\n application use cases.\r\n\r\
n When mobile hosts/routers change their point of attachment to the network,\r\n maintenance of stable home address(es) or prefix(es) is a desirable goal\r\n but not a strict requirement.\r\n Therefore, home address(es) and/or\r\n home network prefix(es) may change during\r\n application level session lifetime, unless otherwise indicated\r\n to the mobile node/router and its applications from the network.\r\n\r\n DMM solutions are primarily targeted at IPv6 deployments and should not\r\n be required to support IPv4, specifically in situations\r\n where private IPv4 addresses and/or NATs are used. IPv6 is\r\n assumed to be present in both the mobile host/router and the access\r\n networks. DMM solutions must maintain backward com
patibility.\r\n If the network or the mobile host/router do not\r\n support the distributed mobility management protocol, that\r\n should not prevent the mobile host/router gaining an
access to the\r\n network.\r\n \r\n The DMM solutions should not distinguish between physical or\r\n virtualised networking functions. However, whenever applicable,\r\n clarifications for specific networking function deployment models\r\n are in scope and encouraged. \r\n \r\n The DMM working group will also work on maintenance-oriented and\r\n incremental extensions to the Mobile IPv6 protocol, specified\r\n in RFC 5213, RFC 5844, RFC 5555, and RFC 6275. \r\n\r\n Work items related to distributed mobility management include:\r\n\r\n o Distributed mobility management deployment models and scenarios: describe\r\n the expected high level network architectures and deployment models where\r\n distributed mobility management p
rotocol solutions would apply.\r\n \r\n o Enhanced mobility anchoring: define protocol solutions for a gateway and\r\n mobility anchor assignment and mid-session mobility anchor swi
tching\r\n that go beyond what has been, for example, described in RFC 6097, 6463,\r\n and 5142. A solution should also define a mechanism for preserving\r\n ongoing mobility sessions in a single administrative or IGP routing\r\n domain, possibly directing traffic towards a new anchor.\r\n \r\n o Forwarding path and signalling management: the mobility agent that handles\r\n mobility signalling interacts with network elements in the DMM network\r\n for managing the forwarding state associated with a mobile node\'s IP traffic.\r\n These two functions may or may not be collocated. Furthermore, the forwarding\r\n state may also be distributed into multiple network elements instead of a\r\n single network element (e.g.,
anchor). Protocol extensions will be specified\r\n to allow the abovementioned forwarding path and signalling management.\r\n \r\n o Exposing mobility state to mobile nodes and net
work nodes: define solutions\r\n that allow, for example, mobile nodes to select either a care-of address or\r\n a home address, depending on an application\'s mobility needs. In order to\r\n enable this functionality, the network side control functions and other\r\n networking nodes must also be able to exchange appropriate control information,\r\n as well as eventually to the mobile nodes and their applications.\r\n/* What does "eventually" mean?? */\r\n \r\n The working group may decide to extend the current milestones based on the new\r\n information and knowledge gained during working on other documents listed in\r\n initial milestones. The possible new documents and milestones must still fit into\r\n the overall DMM charter scope.\r\n
\r\nGoals and Milestones:\r\n Nov 2014 - Submit \'The deployment models and scenarios\' as a working group document(s).\r\n To be Informational RFC.\r\n Nov 2014 - Submit \'E
nhanced mobility anchoring\' as a working group document. To be\r\n Proposed Standard.\r\n Nov 2014 - Submit \'Forwarding path and signaling management\' as a working group\r\n document. To be Proposed Standard.\r\n Feb 2015 - Submit \'Exposing mobility state to mobile nodes and network nodes\' as a\r\n working group document(s). To be Proposed Standard.\r\n\r\n Feb 2015 - Submit \'The deployment models and scenarios\' submitted to the IESG.\r\n To be Informational RFC.\r\n Mar 2015 - Submit \'Enhanced mobility anchoring\' submitted to the IESG. To be\r\n Proposed Standard.\r\n Mar 2015 - Submit \'Forwarding path and signaling management\' submitted to the IESG. \r\n To
be Proposed Standard.\r\n Jul 2015 - Submit \'Exposing mobility state to mobile nodes and network nodes\' submitted\r\n to the IESG. To be Proposed Standard.\r\n\r\n', 'url1': ''
, 'submit': 'Generate diff', 'url2': '', '--newcolour': 'green'} --></body></html>