Re: draft charter text updates in github..
"Charles E. Perkins" <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Organization | Blue Skies |
| Message-ID | <[email protected]> |
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
Diff dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm
(text/html, 50.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=(0048)http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht -->
<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,2014.txt - dmm_charter-Jun10,2014b.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,2014.txt </th><th> </th><th> dmm_charter-Jun10,2014b.txt </th><th></th></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 class="lineno" valign="top"></td><td class="left"> The Distributed Mobility Management (DMM) working group specifies IP</td><td> </td><td class="right"> The Distributed Mobility Management (DMM) working group specifies IP</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> mobility, access network and routing solutions, which allow for</td><td> </td><td class="right"> mobility, access network and routing solutions, which allow for</td><td class="lineno" valign="top"></td></tr>
<tr><td><a name="diff0001"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> setting up IP networks so that traffic can be <span class="delete">exchanged in an optimal</span></td><td> </td><td class="rblock"> setting up IP networks so that traffic can be <span class="insert">expedited</span> between</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> way</span> between <span class="delete">the</span> mobile <span class="delete">node</span> and <span class="delete">the</span> correspondent nodes. <span class="delete">The</span> DMM <span class="delete">does</span></td><td> </td><td class="rblock"> mobile <span class="insert">nodes</span> and correspondent nodes. DMM <span class="insert">solutions do</span> not <span class="insert">necessarily</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> not rely on a single centrally deployed anchor to manage IP mobility</td><td> </td><td class="rblock"> rely on a single centrally deployed anchor to manage IP mobility</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. <span class="delete">The</span> DMM solutions <span class="delete">should</span></td><td> </td><td class="rblock"> sessions for the duration of the sessions. DMM solutions</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> aim for transparency above the IP layer, including maintenance of</td><td> </td><td class="right"> aim for transparency above the IP layer, including maintenance of</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"> active transport level sessions when mobile hosts or <span class="delete">entire </span>mobile</td><td> </td><td class="rblock"> active transport level sessions when mobile hosts or mobile</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> networks change their point of attachment to the Internet.</td><td> </td><td class="right"> networks change their point of attachment 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 class="lineno" valign="top"></td><td class="left"> Traditional wireless networks use a hierarchical structure that has</td><td> </td><td class="right"> Traditional wireless networks use a hierarchical structure that has</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> led primarily to centralized deployment models, where a small number</td><td> </td><td class="right"> led primarily to centralized deployment models, where a small number</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> of mobility anchors manage both mobility and reachability for a mobile</td><td> </td><td class="right"> of mobility anchors manage both mobility and reachability for a mobile</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"> node. Currently, some wireless networks are evolving away from <span class="delete">this</span></td><td> </td><td class="rblock"> node. Currently, some wireless networks are evolving away from</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> type of</span> hierarchical <span class="delete">structure, and therefore,</span> a DMM model for</td><td> </td><td class="rblock"> <span class="insert">such</span> hierarchical <span class="insert">structure;</span> a DMM model for</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. <span class="delete">The</span> DMM <span class="delete">can be used to</span></td><td> </td><td class="rblock"> mobility management can be useful to them. DMM <span class="insert">fosters</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> realise</span> such a distributed deployment <span class="delete">model,</span> by <span class="delete">distributing</span></td><td> </td><td class="rblock"> such a distributed deployment <span class="insert">model</span> by <span class="insert">relocating</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> forwarding functions <span class="delete">at optimal locations; for</span> example, closer</td><td> </td><td class="rblock"> forwarding functions <span class="insert">to improve performance -- as an</span> example, closer</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> either to the mobile node or the corresponding node.</td><td> </td><td class="right"> either to the mobile node or 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="diff0004"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> <span class="delete">The protocol</span> solutions should be based on existing IP mobility</td><td> </td><td class="rblock"> <span class="insert">DMM</span> solutions should be based on existing IP mobility</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> protocols, either host- or network-based, such as Mobile IPv6</td><td> </td><td class="right"> protocols, either host- or network-based, such as Mobile IPv6</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO</td><td> </td><td class="right"> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO</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"> [RFC3963]. However, <span class="delete">the</span> mobility management is not restricted to</td><td> </td><td class="rblock"><span class="insert">/* What about RFC 5568 (FMIP)? */</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> <span class="delete">mentioned</span> IP mobility <span class="delete">protocols if they do not fit the use case</span></td><td> </td><td class="rblock"> [RFC3963]. However, mobility management is not restricted to <span class="insert">the</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> requirements. The solution</span> may extend existing protocols <span class="delete">such as</span></td><td> </td><td class="rblock"><span class="insert"> abovementioned</span> IP mobility <span class="insert">protocols;</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> routing <span class="delete">protocols</span> or even be based on an entirely new protocol.</td><td> </td><td class="rblock"><span class="insert"> solutions</span> may extend existing protocols <span class="insert">(for example,</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> <span class="delete">Specifically, in a case of routing</span> based <span class="delete">approaches the solution(s)</span></td><td> </td><td class="rblock"> routing <span class="insert">protocols)</span> or even be based on an entirely new protocol.</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">Routing</span> based <span class="insert">proposals</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> must not propagate routing updates outside the IGP routing domain.</td><td> </td><td class="right"> must not propagate routing updates outside the IGP routing domain.</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"> When extending <span class="delete">non- IP mobility protocols,</span> solutions should be</td><td> </td><td class="rblock"><span class="insert">/* Does this disallow Binding Update? */</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> reviewed and ratified by the WGs having the "ownership" of those</td><td> </td><td class="rblock"> When extending <span class="insert">protocols that are not based on Mobile IP,</span> solutions</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> protocols.</td><td> </td><td class="rblock"> should be reviewed and ratified by the WGs having the "ownership" of</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock"> those protocols.</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"> <span class="delete">Unlike with</span> existing IETF <span class="delete">standardised</span> IP mobility protocols, <span class="delete">it</span></td><td> </td><td class="rblock"> <span class="insert">In contrast to</span> existing IETF <span class="insert">standard</span> IP mobility protocols,</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> should not be assumed that the</span> mobility management signalling and <span class="delete">the</span></td><td> </td><td class="rblock"> mobility management signalling <span class="insert">paths</span> and</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> end user traffic forwarding paths <span class="delete">are the same, and that both</span> mobility</td><td> </td><td class="rblock"> end user traffic forwarding paths <span class="insert">may differ; those</span> mobility</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> related <span class="delete">function are collocated</span> in <span class="delete">the same</span> network <span class="delete">node.</span> Solutions</td><td> </td><td class="rblock"> related <span class="insert">functions may be located</span> in <span class="insert">separate</span> network <span class="insert">nodes.</span> Solutions</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> may also <span class="delete">focus specifically on enhancing</span> the selection between the</td><td> </td><td class="rblock"> may also <span class="insert">specify</span> the selection between the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> care-of addresses and home address(es)/prefix(es) for different</td><td> </td><td class="right"> care-of addresses and home address(es)/prefix(es) for different</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> application use cases.</td><td> </td><td class="right"> application use cases.</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"> <span class="delete">Although</span> the maintenance of <span class="delete">the</span> stable home address(es) or prefix(es)</td><td> </td><td class="rblock"> <span class="insert">When mobile hosts/routers change their point of attachment to</span> the <span class="insert">network,</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> is a desirable goal <span class="delete">when mobile hosts/routers change their point of</span></td><td> </td><td class="rblock"> maintenance of stable home address(es) or prefix(es) is a desirable goal</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> attachment to the network, it is</span> not a strict requirement. <span class="delete">Mobile</span></td><td> </td><td class="rblock"> <span class="insert">but</span> not a strict requirement.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> hosts/routers should not assume that the</span> home address(es) and/or</td><td> </td><td class="rblock"> <span class="insert">Therefore,</span> home address(es) and/or</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> home network prefix(es) <span class="delete">remain the same throughout the entire</span></td><td> </td><td class="rblock"> home network prefix(es) <span class="insert">may change during</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> application level session lifetime, unless <span class="delete">such property is</span> indicated</td><td> </td><td class="rblock"> application level session lifetime, unless <span class="insert">otherwise</span> indicated</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> to the mobile node/router and its applications from the network.</td><td> </td><td class="right"> to the mobile node/router and its 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="diff0009"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> <span class="delete">The</span> DMM solutions primarily <span class="delete">target</span> at IPv6 deployments and should not</td><td> </td><td class="rblock"> DMM solutions <span class="insert">are</span> primarily <span class="insert">targeted</span> at IPv6 deployments and should not</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> be <span class="delete">tailored specifically</span> to support IPv4, <span class="delete">in particular</span> in situations</td><td> </td><td class="rblock"> be <span class="insert">required</span> to support IPv4, <span class="insert">specifically</span> in situations</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> where private IPv4 addresses and/or NATs are used. <span class="delete">At least</span> IPv6 is</td><td> </td><td class="rblock"> where private IPv4 addresses and/or NATs are used. IPv6 is</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> assumed to be present in both the mobile host/router and the access</td><td> </td><td class="right"> assumed to be present in both the mobile host/router and the access</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"> networks. <span class="delete">Independent of the</span> DMM <span class="delete">solution, backward compatibility</span></td><td> </td><td class="rblock"> networks. DMM <span class="insert">solutions</span> must <span class="insert">maintain backward compatibility.</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> must <span class="delete">be maintained.</span> If the network or the mobile host/router do not</td><td> </td><td class="rblock"> 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 <span class="delete">enabling protocol</span> that</td><td> </td><td class="rblock"> support the distributed mobility management <span class="insert">protocol,</span> that</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> should not prevent the mobile host/router gaining an access to the</td><td> </td><td class="right"> should not prevent the mobile host/router gaining an access to the</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> network.</td><td> </td><td class="right"> 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="diff0011"></a></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> The DMM solutions should not <span class="delete">make a difference</span> between physical or</td><td> </td><td class="rblock"> The DMM solutions should not <span class="insert">distinguish</span> between physical or</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> virtualised networking functions. However, <span class="delete">when applicable</span></td><td> </td><td class="rblock"> virtualised networking functions. However, <span class="insert">whenever applicable,</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> clarifications for <span class="delete">a</span> specific networking function deployment models</td><td> </td><td class="rblock"> 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 class="lineno" valign="top"></td><td class="left"> incremental extensions to the Mobile IPv6 protocol, specified</td><td> </td><td class="right"> incremental extensions to the Mobile IPv6 protocol, specified</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> in RFC 5213, RFC 5844, RFC 5555, and RFC 6275.</td><td> </td><td class="right"> in RFC 5213, RFC 5844, RFC 5555, and RFC 6275.</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"> Work items related to <span class="delete">the </span>distributed mobility management include:</td><td> </td><td class="rblock"> 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 class="lineno" valign="top"></td><td class="left"> o Distributed mobility management deployment models and scenarios: describe</td><td> </td><td class="right"> o Distributed mobility management deployment models and scenarios: describe</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> the expected high level network architectures and deployment models where</td><td> </td><td class="right"> the expected high level network architectures and deployment models where</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"> <span class="delete">the distributed mobility management protocol solution</span> would apply.</td><td> </td><td class="rblock"> <span class="insert">distributed mobility management protocol solutions</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 class="lineno" valign="top"></td><td class="left"> o Enhanced mobility anchoring: define protocol solutions for a gateway and</td><td> </td><td class="right"> o Enhanced mobility anchoring: define protocol solutions for a gateway and</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> mobility anchor assignment and mid-session mobility anchor switching</td><td> </td><td class="right"> mobility anchor assignment and mid-session mobility anchor switching</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> that go beyond what has been, for example, described in RFC 6097, 6463,</td><td> </td><td class="right"> that go beyond what has been, for example, described in RFC 6097, 6463,</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"> and 5142. <span class="delete">The</span> solution should also define a mechanism for preserving</td><td> </td><td class="rblock"> and 5142. <span class="insert">A</span> solution should also define a mechanism for preserving</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> ongoing mobility sessions in a single administrative or IGP routing</td><td> </td><td class="right"> ongoing mobility sessions in a single administrative or IGP routing</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"> domain, <span class="delete">which would involve directing traffic towards the</span> new anchor.</td><td> </td><td class="rblock"> domain, <span class="insert">possibly directing traffic towards a</span> new anchor.</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"> o Forwarding path and signalling management: the mobility agent that handles</td><td> </td><td class="right"> o Forwarding path and signalling management: the mobility agent that handles</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"> <span class="delete">the mobility signalling interacts with the</span> network elements in the DMM network</td><td> </td><td class="rblock"> <span class="insert">mobility signalling interacts with</span> network elements in the DMM network</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> for managing the forwarding state associated with a mobile node's IP traffic.</td><td> </td><td class="right"> for managing the forwarding state associated with a mobile node's IP traffic.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> These two functions may or may not be collocated. Furthermore, the forwarding</td><td> </td><td class="right"> These two functions may or may not be collocated. Furthermore, the forwarding</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> state may also be distributed into multiple network elements instead of a</td><td> </td><td class="right"> state may also be distributed into multiple network elements instead of a</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"> single <span class="delete">anchor like</span> network <span class="delete">element. Define required protocol</span> extensions to</td><td> </td><td class="rblock"> single network <span class="insert">element (e.g., anchor). Protocol</span> extensions <span class="insert">will be specified</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> allow <span class="delete">described</span> forwarding path and signalling management.</td><td> </td><td class="rblock"> to allow <span class="insert">the abovementioned</span> forwarding path and 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 class="lineno" valign="top"></td><td class="left"> o Exposing mobility state to mobile nodes and network nodes: define solutions</td><td> </td><td class="right"> o Exposing mobility state to mobile nodes and network nodes: define solutions</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"> that allow, for example, mobile nodes select <span class="delete">between</span> care-of <span class="delete">addresses and</span></td><td> </td><td class="rblock"> that allow, for example, mobile nodes <span class="insert">to</span> select <span class="insert">either a</span> care-of <span class="insert">address or</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"> home <span class="delete">addresses</span> depending on <span class="delete">the applications'</span> mobility needs. In order to</td><td> </td><td class="rblock"><span class="insert"> a</span> home <span class="insert">address,</span> depending on <span class="insert">an application's</span> mobility needs. In order to</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> enable this functionality, the network side control functions and other</td><td> </td><td class="right"> enable this functionality, the network side control functions and other</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"> networking nodes must also be able to <span class="delete">signal</span> appropriate <span class="delete">metadata information</span></td><td> </td><td class="rblock"> networking nodes must also be able to <span class="insert">exchange</span> appropriate <span class="insert">control information,</span></td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete"> between each other, and</span> eventually to the mobile nodes and their applications.</td><td> </td><td class="rblock"><span class="insert"> as well as</span> eventually to the mobile nodes and their applications.</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">/* What does "eventually" mean?? */</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"> The working group may decide to extend the current milestones based on the new</td><td> </td><td class="right"> The working group may decide to extend the current milestones based on the new</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> information and knowledge gained during working on other documents listed in</td><td> </td><td class="right"> information and knowledge gained during working on other documents listed in</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> initial milestones. The possible new documents and milestones must still fit into</td><td> </td><td class="right"> initial milestones. The possible new documents and milestones must still fit into</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> the overall DMM charter scope.</td><td> </td><td class="right"> 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 class="lineno" valign="top"></td><td class="left"> Nov 2014 - Submit 'The deployment models and scenarios' as a working group document(s).</td><td> </td><td class="right"> Nov 2014 - Submit 'The deployment models and scenarios' as a working group document(s).</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> To be Informational RFC.</td><td> </td><td class="right"> To be Informational RFC.</td><td class="lineno" valign="top"></td></tr>
<tr><td class="lineno" valign="top"></td><td class="left"> Nov 2014 - Submit 'Enhanced mobility anchoring' as a working group document. To be</td><td> </td><td class="right"> Nov 2014 - Submit 'Enhanced mobility anchoring' as a working group document. To be</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. 19 change blocks. </a></th></tr>
<tr class="stats"><td></td><th><i>50 lines changed or deleted</i></th><th><i> </i></th><th><i>53 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': '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 mobility\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 mobile 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 protocols, 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, mobility 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 compatibility.\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 protocol 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 switching\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 network 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 \'Enhanced 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', '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 exchanged in an optimal\r\n way between the mobile node and the correspondent nodes. The DMM does\r\n not rely on a single centrally deployed anchor to manage IP mobility\r\n sessions for the duration of the sessions. The DMM solutions should\r\n aim for transparency above the IP layer, including maintenance of\r\n active transport level sessions when mobile hosts or entire 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 this\r\n type of hierarchical structure, and therefore, a DMM model for\r\n mobility management can be useful to them. The DMM can be used to\r\n realise such a distributed deployment model, by distributing\r\n forwarding functions at optimal locations; for example, closer\r\n either to the mobile node or the corresponding node.\r\n\r\n The protocol solutions should be based on existing IP mobility\r\n protocols, either host- or network-based, such as Mobile IPv6\r\n [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO\r\n [RFC3963]. However, the mobility management is not restricted to\r\n mentioned IP mobility protocols if they do not fit the use case\r\n requirements. The solution may extend existing protocols such as\r\n routing protocols or even be based on an entirely new protocol.\r\n Specifically, in a case of routing based approaches the solution(s)\r\n must not propagate routing updates outside the IGP routing domain.\r\n When extending non- IP mobility protocols, solutions should be\r\n reviewed and ratified by the WGs having the "ownership" of those\r\n protocols.\r\n\r\n Unlike with existing IETF standardised IP mobility protocols, it\r\n should not be assumed that the mobility management signalling and the\r\n end user traffic forwarding paths are the same, and that both mobility\r\n related function are collocated in the same network node. Solutions\r\n may also focus specifically on enhancing 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 Although the maintenance of the stable home address(es) or prefix(es)\r\n is a desirable goal when mobile hosts/routers change their point of\r\n attachment to the network, it is not a strict requirement. Mobile\r\n hosts/routers should not assume that the home address(es) and/or\r\n home network prefix(es) remain the same throughout the entire\r\n application level session lifetime, unless such property is indicated\r\n to the mobile node/router and its applications from the network.\r\n\r\n The DMM solutions primarily target at IPv6 deployments and should not\r\n be tailored specifically to support IPv4, in particular in situations\r\n where private IPv4 addresses and/or NATs are used. At least IPv6 is\r\n assumed to be present in both the mobile host/router and the access\r\n networks. Independent of the DMM solution, backward compatibility\r\n must be maintained. If the network or the mobile host/router do not\r\n support the distributed mobility management enabling 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 make a difference between physical or\r\n virtualised networking functions. However, when applicable\r\n clarifications for a 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 the 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 the distributed mobility management protocol solution 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 switching\r\n that go beyond what has been, for example, described in RFC 6097, 6463,\r\n and 5142. The solution should also define a mechanism for preserving\r\n ongoing mobility sessions in a single administrative or IGP routing\r\n domain, which would involve directing traffic towards the new anchor.\r\n \r\n o Forwarding path and signalling management: the mobility agent that handles\r\n the mobility signalling interacts with the 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 anchor like network element. Define required protocol extensions to\r\n allow described forwarding path and signalling management.\r\n \r\n o Exposing mobility state to mobile nodes and network nodes: define solutions\r\n that allow, for example, mobile nodes select between care-of addresses and\r\n home addresses depending on the applications\' 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 signal appropriate metadata information\r\n between each other, and eventually to the mobile nodes and their applications.\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 \'Enhanced 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>