One document matched: draft-perkins-dmm-matrix-01.xml

<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200811" category="info" docName="draft-perkins-dmm-matrix-01">

  <front>

    <title abbrev="DMM Comparison Matrix">DMM Comparison Matrix</title>
    <author initials="C.P." surname="Perkins" fullname="Charles E. Perkins">
      <organization>Tellabs</organization>
      <address>
        <phone>+1-408-421-1172</phone>
        <email>charliep@computer.org</email>
      </address>
    </author>

    <author initials="Dapeng" surname="Liu" fullname="Dapeng Liu">
      <organization>China Mobile</organization>
      <address>
        <phone>+86-123-456-7890</phone>
        <email>liudapeng@chinamobile.com</email>
      </address>
    </author>

    <date day='9' month='Jul' year='2011'/>
    <area>Internet</area>
    <workgroup>Mobile IPv6 Extensions (mext)</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet Draft</keyword>
<abstract>
<t>
	Distributed Mobility Management (DMM) is proposed as a way to
	enable scalable growth of mobile core networks so that network
	service providers can meet new requirements for performance and
	reduced operational expenditures.  This requires reconsideration
	of existing approaches within the IETF and elsewhere in order to
	determine which if any such approaches may be used as part of
	a DMM solution.
</t>
</abstract>
</front>

<middle>

<section anchor='intro' title='Introduction'>

<t>
	The goal of this document is to
	identify and compare known existing approaches for Distributed
	Mobility Management (DMM).  Characterizations of each of the
	various methods selected for comparison are provided in a
	matrix form according to whether or not they meet certain
	criteria.
</t>

<t>
	Efforts within the IETF have been launched to find improved
	mobility management by decentralizing some or all of the
	traditional functions associated with mobility, including handovers,
	location management, identification, and so on.
</t>

<t>
	The following abbreviations appear in this document:

<list style="hanging">

<t>
	MN: mobile node
</t>

<t>
	HA: home agent
</t>

<t>
	CN: correspondent node
</t>

<t>
	FQDN: Fully Qualified Domain Name
</t>

</list>

</t>

<t>
	The following approaches to mobility management are characterized:

<list style="hanging">

<t>
Route optimization (RO): MN supplies Binding Updates directly to CN.<xref target="RFC3775"/>
</t>
<t>
Source address selection refinements (SAddrSel): MN picks source address appropriate for current point of attachment when launching an application.
</t>
<t>
Dynamically allocated home agent (DynHA): Mobility anchor for MN is allocated on demand.
</t>
<t>
Binding updates to CN even without HA (CN-wo-HA): Similar to RO, but does not require protocol signaling with home agent.
</t>
<t>
Transport protocol (Trans-Mob) : MN modifies transport (e.g., TCP, SCTP, DCCP, MPTCP) protocol parameters to change the IP address of transport connection endpoint
</t>
<t>
	Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in
	HMIP <xref target="RFC5380"/>) available for use by MN at its
	current point of attachment.
</t>
<t>
Dynamic DNS (DynDNS): When MN gets a new address, DNS is updated so that the MN's FQDN resolves to that new address.
</t>

</list>
</t>

<t>
	The approaches listed above will be characterized according to the
	following criteria:

<list style="numbers">
<t>
scalability: in # of nodes
</t>

<t>
specified?: whether there is a working group document specifying the approach
</t>

<t>
IPadd continuity: provides stable IP address
</t>

<t>
backhaul friendly: reduces burden on backhaul
</t>

<t>
app friendly: apps do not require new code
</t>

<t>
server-friendly: server state minimized, servers do not require new code
</t>

<t>
local routing: "local breakout" / "hairpinning" / local traffic routed locally
</t>

<t>
low signaling: not too much signaling required
</t>
</list>
</t>

<t><vspace blankLines="6"/></t>

</section>

<section anchor="matrix"
	title="Matrix Comparing Existing Approaches for DMM">
	
<t>	
	The following matrix rates the approaches described in the
	the previous section according to the characteristics listed.
</t>

<figure>
<artwork>
                  RO  SAddr  DynHA  CN-wo-HA  Trans  Anchor  DynDNS
                       Sel                     Mob    Mob

scalability        Y    Y      M       Y        Y      M       M

specified?         Y    N      N       N        Y      Y       Y

IPadd continuity   Y    N      N       Y        Y      Y       N

backhaul friendly  Y    Y      Y       Y        Y      M       Y

app friendly       Y    N      Y       Y        N      Y       M

server-friendly    M    Y      Y       Y        N      Y       Y

local routing      Y    Y      M       Y        Y      N       Y

low signaling      N    Y      M       N        N      N       N

     Table 1: Comparison Matrix [Legend: Y=Yes, N=No, M=Maybe]
</artwork>
</figure>

</section>


<section anchor="explain" title="Explanations for Matrix Entries">

<t>
	Most of the matrix entries are relatively self-evident.  
	For instance, "Trans Mob" (Transport-based Mobility) approaches
	are rated as not "app friendly" because applications require
	changes in order to make use of the approach.
</t>

<t>
	For approaches that are identified generically,
	it may be ambiguous whether or not they are properly
	specified in any working group document.  Here,
	such approaches are characterized as specified if
	any particular approach in the generic family is
	specified.  More detail may be needed in the future,
	in which case more columns or a new table may be
	needed.
</t>

<!--
<t>
	In this initial pre-release of the document, not too
	many explanations have been supplied.  If the document
	is considered worthwhile, explanations for more matrix
	entries will be developed, concentrating first on those
	entries which have received mailing list attention.
</t>
 -->

<section anchor="ro" title="Route Optimization">
 
<t>
	Mobile IPv6 supports route optimization and bi-directional
	tunneling.  Using route optimization, the mobile node can
	send mobility signalling, and subsequently data packets, directly
	to the correspondent node.  The following aspects of route
	optimization are characterized in the comparison matrix.
 
<list style="numbers">
<t>
	Scalability: Using route optimization, the signalling and data
	do not have to be sent through the centralized mobility anchor.
	Since the effect of route optimization is to reduce traffic
	through the home network, scalability is improved.  Moreover,
	route optimization can reduce the effect of the home agent as
	a single point of failure. 
</t>
 
<t>
	Specified: RFC 3775 specifies the route optimization mode of MIPv6.
</t>
 
<t>
	IP address continuity: In MIPv6 route optimization mode, the mobile
	node still uses  the same home address as the bi-directional tunnel
	mode.  RO mode supports IP address continuity.
</t>
 
<t>
	backhaul friendly: In RO mode, the data can send directly to the CN.
	Data do not need to send through centralized moblity anchor, thence
	RO is backhaul friendly.
</t>
 
<t>
	app friendly: RO mode does not require application changing, so it is
	application friendly.
</t>
 
<t>
 
	server-friendly: RO mode requires the server (i.e., CN) to also
	support Mobile IP RO mode.  In this sense, RO is not server friendly.
</t>
 
<t>
	local routing: In RO mode, the data is forwarded directly between MN
	and CN, it thence can support local routing.
</t>
 
<t>
	low signaling: MIPv6 RO mode use the return routability procedure.
	which requires more signalling than MIPv6 bi-directional tunnel mode.
</t>
</list>
</t>
 
</section>

<section anchor="SAddrSel" title="Source address selection refinements">

<t>
	Source address selection refinements (SAddrSel): MN picks source
	address appropriate for current point of attachment when launching
	an application.

<list style="numbers">
<t>
	Scalability: Since the MN can pick a local source address,
	packets to/from the MN do not have to traverse the home network,
	improving scalability and reducing delay.
</t>
 
<t>
	Specified: see <xref target="RFC3775"/>
</t>
 
<t>
	IP address continuity: If the MN uses a local source address,
	IP address continuity is likely to be violated when MN moves
	to a new network where that address is no longer addressable.
</t>
 
<t>
	backhaul friendly: Since packets do not have to traverse
	the home network, this solution is more backhaul friendly.
</t>
 
<t>
	app friendly: since applications are likely to require changes
	in order to make the address selection, this solution is less
	app-friendly.  If source addresses are selected without involvement
	of the application, this effect would be eliminated.
</t>
 
<t>
	server-friendly: The source address selection by the application
	does not involve the server.
</t>
 
<t>
	local routing: Using a local source address enables local
	routing for local services and communication partners.
</t>
 
<t>
	low signaling: This solution does not impose any signaling
	signaling requirement, unless the address selection algorithm
	requires policy management by the operator.
</t>
</list>
</t>
</section>

<section anchor="DynHA" title="Dynamically allocated home agent ">
<t>
	Dynamically allocated home agent (DynHA): Mobility anchor for MN
	is allocated on demand.
</t>
   
<t>
	Scalability: If the network supports dynamically allocated home agents,
	the mobile node can choose the nearest home agent.  Other mobile nodes
	can use different home agents. But when changing location, home agent
	may not be able to change accordingly.  The mechanism for associating
	home agents to mobile nodes can vary, and different algorithms have
	different scalability characteristics; some may be more scalable than
	others.  Method relying on anycast addresses for home agents are among
	the more scalable approaches.
</t>
 
<t>
	Specified: RFC 3775 specifies dynamic home agent address discovery
	and dynamic home prefix discovery. But it does not support changing
	home agent afterwards.  If the MN selected a new home agent,
	it is likely that existing communications through the previous
	home agent would be disrupted.
</t>
 
<t>
	IP address continuity: When mobile node changes location, it may choose
	a new home agent, but home address would also need to change
	accordingly, making IP address continuity unlikely.
</t>
 
<t>
	backhaul friendly: The mobile node can choose the nearest home
	agent, in this sense, it is backhaul friendly.
</t>
 
<t>
	app friendly: application does not need to change to support
	dynamically allocated home agent. So it is app friendly.
</t>
 
<t>
	server-friendly: server does not need to change to support
	dynamically allocated home agent, so it is server friendly.
</t>
 
<t>
	Local routing: When mobile node selects the nearest home agent,
	it can support local routing through that home agent.
</t>
 
<t>
	Low signaling: Dynamic discovery and assignment of a home agent
	may need additional signaling.
</t>

</section>

<section anchor="CN-wo-HA" title="Binding updates to CN even without HA ">
<t>
	Binding updates to CN even without HA (CN-wo-HA): Similar to route
	optimization, but does not require protocol signaling with home agent.

<list style="numbers">
<t>
	Scalability: yes, same as for route optimization.
</t>
 
<t>
	Specified: Internet drafts exist, but no working group document.
</t>
 
<t>
	IP address continuity: yes, same as for route optimization.
</t>
 
<t>
	backhaul friendly:  yes, same as for route optimization.
</t>
 
<t>
	app friendly: yes, same as for route optimization.
</t>
 
<t>
	server-friendly: no, same as for route optimization.
</t>
 
<t>
	local routing: yes, same as for route optimization.
</t>
 
<t>
	low signaling: no, same as for route optimization.
</t>
</list>
</t>
</section>

<section anchor="Trans-Mob" title="Transport protocol Mobility">
<t>
	Transport protocol (Trans-Mob): MN modifies transport (e.g., TCP,
	SCTP, DCCP, MPTCP) protocol parameters to change the IP address of
	transport connection endpoint. In many ways, such approaches
	resemble CN-wo-HA except that the signaling occurs
	at a different layer of the protocol stack (namely, at the transport
	layer instead of the network layer).

<list style="numbers">
<t>
	Scalability: yes, same as for CN-wo-HA.
</t>
 
<t>
	Specified: no, same as for CN-wo-HA.
</t>
 
<t>
	IP address continuity: The point of such approaches is, basically,
	to eliminate the need for IP address continuity.  So, while IP
	address continuity is not provided, this should not be considered
	a demerit of transport mobility approaches.

	It would be better to compare approaches based on
	"session continuity" instead of "IP address continuity".
</t>
 
<t>
	backhaul friendly: yes, same as for CN-wo-HA.
</t>
 
<t>
	app friendly: yes (typically), same as for CN-wo-HA.
</t>
 
<t>
 
	server-friendly: no, same as for CN-wo-HA.
</t>
 
<t>
	local routing: yes, same as for CN-wo-HA.
</t>
 
<t>
	low signaling: MIPv6 RO mode use the return routability procedure.
	which requires more signalling than MIPv6 bi-directional tunnel mode.
</t>
</list>
</t>
</section>

<section anchor="Anchor-Mob" title="Local anchor">
<t>
	Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in
	HMIP <xref target="RFC5380"/>) available for use by MN at its
	current point of attachment.

<list style="numbers">
<t>
	Scalability: The mobile node signals the nearest anchor.  MNs in
	other networks can use different anchors.  Scalability is improved
	because the signaling path between the mobile node and its local
	anchor is shorter.  Moreover, local mobility anchors offload work
	from any remote mobility anchor such as the home agent.
</t>
 
<t>
	Specified: HMIP<xref target="RFC5380"/>
</t>
 
<t>
	IP address continuity: In conjunction with Mobile IPv6 as a
	macro mobility protocol, IP address continuity is enabled.
</t>
 
<t>
	backhaul friendly: The mobile node can choose the nearest
	local anchor; in this sense, it is backhaul friendly.
</t>
 
<t>
	app friendly: application does not need to change to support
	dynamically allocated home agent. So it is app friendly.
</t>
 
<t>
	server-friendly: server does not need to change to support
	local mobility anchor, so it is server friendly.
</t>
 
<t>
	Local routing: Generally, the use of a local anchor does
	not necessarily improve local routing; additional functionality
	would need to be designed or included with the local anchor.
</t>
 
<t>
	Low signaling: Additional signaling is required for the mobile
	node to insert new bindings at the local anchor.
</t>
</list>
</t>
</section>

</section>
<!--  CEP DEBUG
-->

<section anchor="security" title="Security Considerations">

<t>
This document does not have any security considerations.
</t>
</section>


<section anchor="iana" title="IANA Considerations">
<t>
This document does not have any IANA actions. 
</t>
<t><vspace blankLines="6"/></t>
</section>
</middle>

<back>

<references title="Normative References">
 
<?rfc include='reference.RFC.3484.xml'?>
<?rfc include='reference.RFC.3775.xml'?>
<?rfc include='reference.RFC.5380.xml'?>
 
</references>

<!--
<references title="Informative References">
 
    <reference anchor="cool_draft">
	<front>
		<title>
		A cool draft.
		</title>
		<author initials="J." surname="Doe"
			fullname="John Doe">
			<organization abbrev="CIA">CIA </organization>
		</author>

		<author initials="J." surname="Doe"
			fullname="Jane Doe">
			<organization abbrev="CIA">CIA </organization>
		</author>

		<date year="2010" />
	</front>
		<seriesInfo name="Internet-Draft"
			value="draft-does-cia-rules.txt" />
    </reference>
 
  </references>
  -->


<section anchor="ack" title="Acknowledgements">

<t>
	This document has benefitted from discussions with the
	following people, in no particular order:

	Seok Joo Koh,
	Jouni Korhonen,
	Julien Laganier,
	Dapeng Liu,
	Telemaco Melia,
	Pierrick Seite
</t>

   
</section>


</back>

</rfc>