One document matched: draft-perkins-dmm-matrix-00.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-00">

  <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.com</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='4' 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 is 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 mode and bi-directional tunnel mode.
In route optimization mode, 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: In route optimization mode, the signalling and data
	could be sent without through the centralized mobility anchor.
	So there is no single point of failure in RO mode.  Moreover,
	the effect of route optimization is to reduce traffic through
	the home network -- therefore there is no scalability issue.
</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>
	Dummy text here.
      Source address selection refinements (SAddrSel): MN picks source
      address appropriate for current point of attachment when launching
      an application.
</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 after the mobility session setting up.
</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.
</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 selecting the nearest home agent, it
can support local routing in some degree.
</t>
 
<t>
        
Low signaling: Dynamical discovery and assignment of a home agent
may need additionally signaling.
</t>

</section>

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

<section anchor="Trans-Mob" title="Transport protocol ">
<t>
	Dummy text here.
      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>
</section>

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

</section>

<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.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>