One document matched: draft-moskowitz-hip-based-5gpp-ip-mobility-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-hip-based-5gpp-ip-mobility-01.txt" ipr="trust200902">

<front>
<title abbrev="HIP enabled 5GPP IP Mobility">HIP Enabled ID/Loc separation for fast 5GPP IP mobility</title>
	<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
    <organization>Huawei</organization>
    <address>
      <postal> 
	    <street></street>
        <city>Oak Park</city>
        <region>MI</region>
        <code>48237</code>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Xiaohu Xu" initials="X." surname="Xu">
	<organization>Huawei</organization>
	<address>
	  <postal>
	    <street>Huawei Bld, No.156 Beiqing Rd.</street>
	    <city>Beijing</city>
	    <region>Hai-Dian District</region>
	    <code>100095</code>
	    <country>China</country>
	  </postal>
	  <email>xuxiaohu@huawei.com</email>
	</address>
	</author>
	<author fullname="Bingyang Liu" initials="B." surname="Liu">
	<organization>Huawei</organization>
	<address>
	  <postal>
	    <street>Huawei Bld, No.156 Beiqing Rd.</street>
	    <city>Beijing</city>
	    <region>Hai-Dian District</region>
	    <code>100095</code>
	    <country>China</country>
	  </postal>
	  <email>xuxiaohu@huawei.com</email>
	</address>
	</author>
<date year="2016" />
   <area>Internet</area>
   <workgroup>HIP</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>HIP</keyword>
<abstract>
<t>
	<xref target="RFC7401">HIP</xref> stands alone in providing a 
	secure Endpoint ID for decoupling the Internetworking and Transport 
	protocol layers.  The addition of a secure rendezvous service to 
	facilitate mobility will form the cornerstones for this 5GPP 
	mobility technology.  This document will describe complete mobility 
	environment and the additional components needed.
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	IP mobility in the next generation cellular networks will demand 
	shortest path routing, transportation of data secure from a 
	laundry list of attacks, minimal cost infrastructure, 
	and a viable business model for the 
	providers of the 5GPP infrastructure.
</t> 
<t>
	Infrastructure costs for the 5GPP network come in many forms. Costs 
	can arise from the cost to support network services, or costs to 
	encapsulate data, or network over-provisioning costs to reduce 
	network delays.  At the heart of all the 3GPP mobility costs is the 
	effort to reduce reconnection delays for IP packets so improve 
	users experience. The preferred solution for the 5GPP 
	infrastructure will offer the best possible user experience at the 
	best delivery price point.
</t>
<t>
	HIP, with some important infrastructure enhancements can deliver on 
	these requirements.  This document will detail the infrastructure 
	environment needed along with how all the HIP pieces will fit 
	together.
</t>
<t>
	Further, HIP multihoming support can facilitate a "Make then Break" 
	connectivity model that would add to the user experience and 
	facilitate network providers offloading of traffic to more 
	cost-effective connections.
</t>
<t>
	Finally, HIP mobility is not an overlay solution to mobility. 
	Infrastructure implications are principally requirements for RVS, 
	HIP Proxies (for legacy host mobility access), and potentially HIP 
	NAT traversal services.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<t>
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
		"OPTIONAL" in this document are to be interpreted as described 
		in <xref target="RFC2119">RFC 2119</xref>.
	</t>
	</section>
	<section title="Definitions">
	<t>
		<list style="hanging">
		<t hangText="X:">
			X.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="Compt" title="The components to a HIP-based Mobile world">
<t>
	Three fundamental components lay the foundation of a HIP-based 
	mobile world.  These need extreme scalability at numbers easily 
	ranging from 10 billion to 1 trillion entries.  Many portions can 
	be fragmented.  That is there is needed fore-knowledge to gain 
	entry.
</t>
<section title="Service to HIT mapping by device/owner name">
<t>
	“I wish to make a video call to Alice” query to a video call 
	service should return Alice’s HIT.  Alice could register her HIT 
	with the video calling service mapping by proving ownership of the 
	HIT (via a HIP registration exchange). Which is a separate exercise 
	beyond the basic scope of this service.
</t>
</section>
<section title="HIT to IP mapping service">
<t>
	The HIT is then mapped to Alice’s device’s current IP address for 
	setting up the HIP Security Association and the video stream 
	connection between the IP addresses, mapped to the HITs rather than 
	the location IP addresses.
</t>
<t>
	Even at a later time, a cached HIT can be used to discover Alice's 
	device's current IP address.
</t>
<t>
	For a multihomed device, all addresses can be evaluated, perhaps by 
	an analytics engine associated with the device's RVS for best route 
	selection.
</t>
</section>
<section title="Shortest Path Routing support">
<t>
	Both Bob and Alice are very active people and their devices are 
	constantly moving.  However they wander after starting the session, 
	their devices need to stay in contact with each other.  This needs 
	good performance for when the are in the same city or across the 
	world.
</t>
<t>
	For multihomed devices, all the addresses should be evaluated and 
	the best route selected.
</t>
</section>
</section>
<section anchor="needs" title="Providing services to meet mobility needs">
<section title="Scaleable HITs">
<t>
	HITs as defined in <xref target="RFC7401">RFC7401</xref> have a 96 
	bit flat address space. A 1 trillion deployment HITs would have a 
	0.0006% probability of a collision <xref target="Coll_Prob"/>. 
	However, it is probably significantly worst than this due to 
	historical problems with ‘good’ random number generators or 
	asymmetric key pairs. Selecting a HIT that will not collide with a 
	future communication peer is an effort in futility. <xref 
	target="I-D.moskowitz-hierarchical-hip">Hierarchical HITs</xref> 
	provides a manageable approach to HITs and supplies the basics for 
	a viable business model for registering ownership of a HIT.
</t>
<t>
	Alice selects a Hierarchical HIT Domain Authority (HDA) for her 
	device A.  This may be a different HDA than her device Q.  She 
	agrees to the policy of use by that HDA and follows their 
	instructions to register the HHIT for the device.  The HDA insures 
	there is no authorized collision with her selected HHIT.  She then 
	publishes that HHIT for the services she wishes to be publicly 
	known.  Or she can just share her HHIT with friends and/or 
	colleagues.  At any time she may withdraw that HHIT.  If she is 
	found in violation of the HDA’s policy, it can unregister her 
	device.
</t>
</section>
<section title="Additional services associated with the HDA RVS">
<t>
	The RVS mechanism provides a rich environment to add additional 
	services to enhance the overall performance of mobility.
</t>
<t>
	For example, where a device registers multiple locators on RVS 
	registration, an analytics engine can assess connection costs for 
	each HIP connection request (I1 or UPDATE) received.
</t>
</section>
<section title="Preparing to use an HHIT">
<t>
	HHIT strongly recommends using the HIP RVS.  Even a truly 
	stationary HIP-enabled server should use  it and use the 
	corresponding ‘HIP fast Mobility’ to stay connected with its mobile 
	communication partners.  An RVS could be used for active load 
	balancing across servers with different HITs.
</t>
<t>
	All devices mobile MUST maintain an active RVS connection.  This is 
	required even if device Q never publishes any services but always 
	initiate the session. Q still needs RVS to support fast mobility.  
	Without it the recovery from a double-jump would be left up to Q 
	with no possible successful mobility update by its HIP peer until Q 
	completes its mobility update.
</t>
</section>
<section title="Protecting privacy of an HHIT">
<t>
	An HDA may have a policy to only confirm the validity of a HHIT to 
	HI mapping on receipt of an I2 or R2 packet from the recipient of 
	that packet.  This shows that the HIP device was actively 
	connecting to the peer requesting validation and already has a HIT 
	to HI pairing.  This protects against robots and the like trolling 
	for valid HHITs.
</t>
<t>
	A device can have as many HHITs as it wishes, registering each with 
	a different HDA, if desired.  It can withdraw a HHIT and register a 
	new one, provided the HDA permits this action.  This is commonly 
	done for identity privacy reasons.  If Bob wants some medical 
	advice, he can have his device register a new HHIT for this 
	research then withdraw it when finished.
</t>
</section>
<section title="Contacting a device based on its HHIT">
<t>
	There can be a direct DNS mapping of the HDA within the HHIT to 
	that HDA’s RVS.  This provides the access to the device where ever 
	it may be.
</t>
</section>
<section title="Intra-HDA peering agreements">
<t>
	A HIP Client to RVS connection that spans the globe will work, as 
	will the mobility updates.  But this may not be the most efficient 
	approach.  An HDA may globally diversify its RVS and use DNS to 
	direct the client to the ‘nearest’ RVS.
</t>
<t>
	Alternatively, two HDAs could maintain a peering arrangement.  The 
	mechanism by which a client selects the ‘best’ HDA peer 
	geographically and is contacted through that RVS rather than the 
	HHIT native RVS is a future work item.
</t>
</section>
<section title="Maintaining the HIP session through all mobility events">
<t>
	With each peer in a HIP Security Association maintaining an active 
	connection to their HHIT RVS, the HIP fast mobility mechanism 
	ensures SA remapping to any location changes in a timely manner.
</t>
</section>
</section>
<section title="HIP proxies to Legacy (non-HIP) hosts">
<t>
	A HIP mobile host can use non-HIP connections to legacy, static 
	servers.  This approach would burden the communications with 
	reconnects.  5GPP may well have a significantly higher occurrence 
	of IP address changes than 4GPP.  This would benefit from a HIP 
	mobility enabled mechanism provided in <xref 
	target="I-D.irtf-hiprg-proxies">HIP proxy solutions</xref>.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
    <t>
      There are no IANA considerations for this document.
    </t>
</section>
<section title="Security Considerations">
<t>
	TBD
</t>
</section>
<section title="Acknowledgments">
<t>
	Sue Hares of Huawei contributed to the clarity in this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.I-D.moskowitz-hierarchical-hip.xml"?>
	<?rfc include="reference.I-D.irtf-hiprg-proxies.xml"?>
</references>
<section anchor="Coll_Prob" title="Calculating Collision Probabilities">
<t>
	The accepted formula for calculating the probability of a collision 
	is:
</t>
	<figure>
		<artwork>

	p = 1 - e^{-k^2/(2n)}


	P	Collision Probability
	n	Total possible population
	k	Actual population


		</artwork>
	</figure>
</section>
</back>
</rfc>