<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" symrefs="no" ?>
<rfc category="std" docName="draft-xu-homenet-twod-ip-routing-02" ipr="trust200902" obsoletes="" submissionType="IETF" xml:lang="en">
	<front>
		<title abbrev="Two-IP Routing in HomeNet">Two Dimensional-IP Routing Protocol in Home Networks</title>
				<author initials='M.' surname='Xu' fullname='Mingwei Xu'>
			<organization abbrev='Tsinghua University'>Tsinghua University</organization>
			<address>
				<postal>
	        <street>Department of Computer Science, Tsinghua University</street>
	        <city>Beijing</city>
	        <code>100084</code>
	        <country>P.R. China</country>
	    	</postal>
	    	<phone>+86-10-6278-5822</phone>
	    	<email>xmw@cernet.edu.cn</email>
	    </address>
		</author>
		<author initials='J.' surname='Wu' fullname='Jianping Wu'>
			<organization abbrev='Tsinghua University'>Tsinghua University</organization>
			<address>
				<postal>
	        <street>Department of Computer Science, Tsinghua University</street>
	        <city>Beijing</city>
	        <code>100084</code>
	        <country>P.R. China</country>
	    	</postal>
	    	<phone>+86-10-6278-5983</phone>
	    	<email>jianping@cernet.edu.cn</email>
	    </address>
		</author>
		    <author initials="S." surname="Yang" fullname="Shu Yang">
     			 <organization abbrev="Shenzhen University">Shenzhen University</organization>
      			<address>
      			  <postal>
       			   <street>South Campus, Shenzhen University</street>
        			  <city>Shenzhen</city>
        			  <code>518060</code>
       			   <country>P.R. China</country>
      			  </postal>
       			 <phone>+86-755-2653-4078</phone>
      			  <email>yang.shu@szu.edu.cn</email>
      			</address>
   		 </author>  
		<author initials="L." surname="Cui" fullname="Laizhong Cui">
      			<organization abbrev="Shenzhen University">Shenzhen University</organization>
     			 <address>
      			  <postal>
       			   <street>South Campus, Shenzhen University</street>
       			   <city>Shenzhen</city>
       			   <code>518060</code>
        			  <country>P.R. China</country>
       			 </postal>
			<phone>+86-755-8695-6280</phone>
      			  <email>cuilz@szu.edu.cn</email>
     			 </address>
   		 </author>
		<author initials='D.' surname='Wang' fullname='Dan Wang'>
			<organization abbrev='Hong Kong Polytechnic University'>Hong Kong Polytechnic University</organization>
			<address>
				<postal>
	        <street>Department of Computing, Hong Kong Polytechnic University</street>
	        <city>Hong Kong</city>
	        <country>P.R. China</country>
	    	</postal>
	    	<phone>+852-2766-7267</phone>
	    	<email>csdwang@comp.polyu.edu.hk</email>
	    </address>
		</author>
		<date  />
		<abstract>
			<t>Home network design faces many challenges currently. Two of them are multi-homing and policy enforcement.
				Different with other types of networks, home network operators are usually not professional technicians
				or geeks. The problems we face are fundamentally related with the poor semantics provided by current
				destination-based routing protocol.</t>
			<t>
				TwoD-IP routing protocol is a link state routing protocol that makes routing decisions based on
				both destination and source addresses. This document describes the mechanism for supporting 
				flexible multi-homing and policy routing across home networks. 

			 </t>
		</abstract>
	</front>

<middle>
<section title="Introduction">
	<t>With more and more devices joining home networks, there are increasingly large residential home networks. Traditionally, we
	keep home networks simple using single exit router (subnet) and default route. However, more complex network technologies,
	such as multi-homing, appear when the networks become large. Besides, users demand for more than connectivity service, as
	varieties of devices like private health sensors, exist in their home networks. For example, users demand for finer granularity 
	control for
	privacy and security reasons. While we can not expect home network operators, who usually know nothing about network 
	technologies, to configure complex network policies using tools like access control list (ACL). We need a simpler and more
	flexible routing protocol in home networks.	</t>

	<t>Traditionally, routing protocols make routing decisions solely based on destination IP addresses, so packets towards
	the same destination will be delivered to the same next hop no matter where they come from. These protocols work well with simple
	home networks. However, as users demand for more source-related functions and network
	techonologies evolve. Destination-based routing protocol can not handle these demands, and even fail to provide the basic 
	connectivity services. For example, in the multi-homing scenario, packets may be dropped if forwarded
	only based on destination addresses <xref target="RFC3704"></xref>. </t>
	<t>Although many patch-like solutions, like policy-based routing (PBR), can improve the situation. However, they
	complex the configurations in home networks, and are not suitable for home network operators. The underlying cause
	for these problems is the lack of semantics of destination-based routing. A new routing protocol that makes routing
	decisions based on both destination and source IP addresses is preferred in future home networks 
	<xref target="RFC7368"></xref>.</t>
	<t>In this document, we propose a new link state routing protocol, called Two Dimensional-IP (TwoD-IP) routing protocol, that
	greatly enriches the routing semantics. We list two important scenarios, including multi-homing and access control
	in home networks, where TwoD-IP routing protocol will apply. We also use them as examples to illustrate the new
	routing protocol.</t>
	<t>We modify OSPF to support our TwoD-IP routing protocol. With one more dimension, the routing protocol has to
	disseminate additional information with newly defined LSAs, and compute a two dimensional routing table based
	on the collected LSAs. Thus, we must design new LSA packet formats, data structures and routing algorithms for the
	new routing protocol.</t>
</section>
<section title="Terminology">
	<t>Terminology used in this document:</t>
        <t><list style="symbols">
	  <t>TwoD-IP routing protocol: Two Dimensional IP routing protocol, which makes routing decisions based on both destination
	  and source IP addresses.</t>
	  <t>Guest Network: A subnet in a home network, that supports communication with other subnets in the home network and the
	  Internet.</t>
	  <t>Private Network: A subnet in a home network, that only supports communication with other subnets in the home network.</t>
	  <t>Restricted Network: A subnet in a home network, that supports communication with other subnets in the home network
	  and only parts of the Internet.</t>
	  <t>TwoD Traffic Class: We borrow the definition from <xref target="I-D.baker-fun-routing-class"></xref>, which describes it as
	  a selector that identifies a set of traffic, e.g., from a stated source prefix and towards a stated destination prefix. </t>
	  <t>TwoD Link Metric: The cost of travelling through a link, for a TwoD traffic class.</t>
	  <t>TwoD-LSA: Link state advertisement that disseminates the TwoD link metric information across the network. </t>
	  <t>TwoD-LSB: Extended link state database that stores the TwoD-LSAs.</t>
	</list>
	</t>
</section>

<section title="Scenario of Interests">
	<t>
	  This section describes two scenarios, including multi-homing and policy routing, where TwoD-IP routing protocol will
	  apply in home networks. Note that TwoD-IP routing protocol can also apply in other scenarios, despite we focus 
	  on two important ones.
	</t>	 
	<section title="Multi-homing in Home Networks">
		<t>In this scenario, a home network may be connected to multiple upstream ISPs. The network is responsible
		for delivering packets to the exit router that is connected to the corresponding upstream ISP.</t>

		<t>For example, in Figure 1, a home network is connected with two ISPs, ISP1 and ISP2. ISP1 has prefix P1 and is connected
		to the home network through border router BR1; ISP2 has prefix P2 and is connected to the home network through border router
		BR2. A host in the network is connected to the intermediate router I1, and obtains two addresses, A from P1 and B from P2.
		Packets from the host towards the Internet should be sent to BR1 when the host uses address A, else the packets should
		be sent to BR2 when the host uses address B.</t>
		
		<t>The multi-homing scenario is an emerging requirement in home networks. These networks are naturally connected to
		multiple upstream ISPs, e.g., broadband service provider and IPTV service provider, at the same time. Packets could
		be dropped if they are not delivered to the right ISP. For example, some IPTV service provider does not allow packets
		with any source addresses other than their own addresses.</t>
		<figure title="Figure 1: Multi-homing Scenario in Home Networks">
		  <artwork>
			<![CDATA[
                        +--------------------------+
                        |                          |
                        |       Internet           |
                        |                          |
                        |                          |
                        +--------------------------+
                        |                          |
            +-----------+---+                  +---+-------------+
            |               |                  |                 |
            |   ISP1: P1    |                  |    ISP2: P2     |
            |               |                  |                 |
            +--------+------+                  +-----+-----------+
                     |                               |
                  +--+---+                        +--+---+
                  |Router|                        |Router|
                  | BR1  |                        | BR2  |
                  +---+--+                        +---+--+
                ------+------------+-  -+-------------+-----
                                 +-+----+-+
                                 | Router |
                                 |   I1   |
                                 +---+----+
                              -------+--------
                                     |
                                  +--+---+  Address A in P1
                                  | Host |  
                                  +------+  Address B in P2
			]]>
		  </artwork>
		</figure>
	<t></t>	
	</section>
	<section title="Access-control in Home Networks">
		<t>Home networks will involve multiple subset and routers, as more and more dedicated devices including
		sensors are incorporated into home networks. Different subsets in home networks usually have different
		privacy and security policies. For instance, modern home routers will support both guest and private
		subnets <xref target="RFC7368"></xref>.
		</t>	

		<t>For example, in Figure 2, a home network is divided into three subnets, the guest network, private network
		and restricted network. The guest network can communicate with all peer devices/hosts inside or outside the
		home network. The private network can only communicate with all devices/hosts inside the home network. For
		the restricted network, it can communicate with others inside the home network, but only has limited Internet
		access.</t>
		<t>Considering the importance of privacy and security in home network, this senario will be common in the home 
		network enviroment. With more and more devices, like some private health sensors taking part in, it 
		is envisaged that home networks should provide a simple and flexible routing protocol, where access-control
		could be made in much finer granularity.
		</t>
		<figure title="Figure 2: Acess-control Scenario in Home Networks">
		  <artwork>
			<![CDATA[
                            +---------------------+
                            |                     |
                            |       Internet      |
                            +----------+----------+
			               |
                                   +---+---+
                                   |       |
                            +------|  BR1  |------+
                            |      +-------+      |
     +------------+         |                     |         +------------+
     |            |     +---+---+             +---+---+     |            |
     |   Guest    |     |       |             |       |     |   Private  |
     |  Network   +-----+   I1  |             |   I2  +-----+   Network  |
     |            |     +---+---+             +---+---+     |            |
     +------------+         |                     |         +------------+
                            |      +-------+      |
                            +------|       +------+
                                   |   I3  |
                                   +---+---+
                                       | 
                                 +-----+------+
                                 |            |
                                 | Restricted |
                                 |  Network   |
                                 |            |
                                 +------------+
					 	]]>
		  </artwork>
		</figure>
         <t></t>
	</section>
</section>
		
<section title="Protocol Overview">
	<t>TwoD-IP routing protocol is a link-state routing protocol, which is preferred in home network, as
	routing protocol can have knowledge of the whole home network topology <xref target="RFC7368"></xref>. 
	The new routing protocol can be self-configuring, and allows customizing for selected subnets.</t>
	
	<t>Similar with traditional OSPF protocol, TwoD-IP periodically gather link information and dynamically construct
	network topology. Then routers within TwoD-IP routing protocol maintain link state data base that
	describes network topology. After that, all routers will run routing algorithm that determines the next hop
	for each packet <xref target="RFC5340"></xref>.</t>
	<t>Different with OSPF protocol, which makes routing decisions solely based on the destination IP address,
	and computes next hop towards different destination IP addresses;
	TwoD-IP routing protocol makes routing decisions based on both destination and source IP addresses. Thus,
	routers need to disseminate and store additional information, and run a different routing algorithm
	that computes next hop for different destination and source IP address pairs.</t>
	<t>In this document, we will focus on the differences between new TwoD-IP routing protocol and traditional
	OSPF protocol. Basically, they can be divided into three parts: link metric configuration, link state 
	advertisement/database, routing table calculation.</t>
	<t>With TwoD-IP routing protocol, all traffic can be classified into a TwoD traffic class, which
	can be represented by a (destination prefix, source prefix) pair. Each packet falls into only one traffic
	class based on its destination and source IP addresses. On each link, we can configure multiple two dimensional 
	link metrics, each expresses the cost of a TwoD traffic class. Such link metric is called TwoD link
	metric, and can be represented by a (destination prefix, source prefix, cost) triple.</t>
	<t>After link metric configuration, routers will disseminate these TwoD link metric with new LSA, which is 
	call TwoD-LSA. Receiving them, routers will store them into extended link state database (LSB), which can accommodate
	TwoD-LSAs. The extended link state database is called TwoD-LSB.</t>
	<t>With the TwoD-LSB, routers can run routing algorithm that computes the next hop for each TwoD traffic class.
	Intrinsically, each TwoD traffic class will match a TwoD link metric on each link over the network. Thus, each
	TwoD traffic class can obtain a full network topolgoy (which may be different with the topologies for other TwoD traffic
	classes). Then the routing algorithm shall construct an SPT for the TwoD traffic class. When a packet arrives,
	according to the TwoD traffic class that it falls into, it will flow along the corresponding SPT. Note that
	a packet may fall into multiple TwoD traffic class, we resolve the confliction through the "Most Specific First"
	rule <xref target="I-D.baker-fun-routing-class"></xref>.</t>
</section>

<section title ="TwoD Link Metric Configuration">
        <t>Like OSPF, the TwoD link metric is configured in the interface data structure. However, TwoD link metric is
	not solely a scalar that describes the cost of sending a packet on the interface, but a triple (destination prefix,
	source prefix, cost) that describes the cost of sending a packet for TwoD traffic class (destination prefix,
	source prefix). A single link can be configured to have multiple TwoD link metrics, each for a different TwoD
	traffic class. Note that the links can be automatically configured to have (*,*,1), that degenerates into
	the default configuration for traditional OSPF. </t>
		<figure title="Figure 3: TwoD link metric configuration in the multi-homing Scenario">
		  <artwork>
			<![CDATA[
            +---------------+                  +-----------------+
            |               |                  |                 |
            |   ISP1: P1    |                  |    ISP2: P2     |
            |               |                  |                 |
            +--------+------+                  +-----+-----------+
                     |IF1:(*,P1,1)                   |IF2:(*,P2,1)
                  +--+---+(*,P2,1000)             +--+---+(*,P1,1000)
                  |Router|                        |Router|
                  | BR1  |                        | BR2  |
                  +---+--+                        +---+--+
                ------+------------+-  -+-------------+-----
                                 +-+----+-+
                                 | Router |
                                 |   I1   |
                                 +---+----+
                              -------+--------
                                     |
                                  +--+---+  Address A in P1
                                  | Host |  
                                  +------+  Address B in P2
			]]>
		  </artwork>
		</figure>
	<t>Continuing the example in Figure 1, we plot the TwoD link metric configuration in Figure 3. We only have to
	configure the out-going interface (like IF1 and IF2) on the border routers. On IF1, we configure two TwoD link
	metrics, (*, P1, 1) and (*, P2, 1000), indicating packets from P1 will traverse the link with cost 1 while packets
	from P2 will traverse the link with much higher cost, 1000. Similarly, on IF2, we also configure two TwoD link
	metrics, (*, P2, 1) and (*, P1, 1000). With this configuration, traffic from P1 (or P2) will see a topology where the path
	through ISP1 (or ISP2) costs much less than the path through ISP2 (or ISP1). Packets from P1 (or P2) will never
	be diverted to ISP2 (or ISP1) unless the connection with ISP1 (or ISP2) fails.</t>
	<t>Also continuing the example in Figure 2, we plot the TwoD link metric configuration in Figure 4. Let PX, PY, and PZ be
	the prefix of the guest, private and restricted network, PR be the private prefix used
	in the home network, and PV be the prefix in the Internet which the restricted network can communicate with.
	We only have to configure the router interfaces (like IFA, IFB and IFC) where the subnets are connected. 
	On IFA, we only have to configure (PX, *, 1) as all traffic can travel into the guest network. We have to
	configure (PY, PR, 1) on IFB, because only hosts from the home network (using address in the private prefix)
	can travel into the private network. At last, we have to configure (PZ, PR, 1), (PZ, PV, 1) on IFC, because
	not only hosts inside the home network, but also hosts from PV, can access the restricted network.</t>
		<figure title="Figure 4: TwoD link metric configuration in the acess-control Scenario">
		  <artwork>
			<![CDATA[

                                   +---+---+
                                   |       |
                            +------|  BR1  |------+
                            |      +-------+      |     
     +------------+ (PX,*,1)|                     |(PY,PR,1)+------------+
     |            |     +---+---+             +---+---+     |            |
     |   Guest    |  IFA|       |             |       |IFB  |   Private  |
     |  Network   +-----+   I1  |             |   I2  +-----+   Network  |
     |            |     +---+---+             +---+---+     |    :PX     |
     +------------+         |                     |         +------------+
                            |      +-------+      |
                            +------|       +------+
                                   |   I3  |
                                   +---+---+ (PZ,PV,1)
                                       |IFC  (PZ,PR,1)
                                 +-----+------+
                                 |            |
                                 | Restricted |
                                 |  Network   |
                                 |   :PY      |
                                 +------------+
					 	]]>
		  </artwork>
		</figure>

  </section>

<section title="New Link State Advertisement/Database">
	<t>The new protocol need to carry source address prefixes information in link state advertisements. We use the OSPF extension in <xref target="RFC8362"/> to
	carry the additional prefixes. The format of the extended TLV is defined as following. 
	</t>	
	
	<figure title="extension tlv">
          <artwork align="center"><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Type             |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  PrefixLength | PrefixOptions |             0                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Address Prefix                         |
 |                             ...                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

	<t><list style="symbols">
	<t>Type: Assigned by IANA as denoted in Section 8.1 of <xref target="RFC8362"/>.</t>
	<t>Length: Length of an IPv6 prefix plus 4 bytes, which is equal to 20.</t>
	<t>PrefixLength, PrefixOptions, and Address Prefix: Denoting an IPv6 prefix, as defined in <xref target="RFC5340"/>.</t>
	</list>
	</t>
</section>
		
<section title="Calculation of The Routing Table">
	<t>TBD.
	</t>	
</section>

<section title="Forwarding Table Modification">
        <t>Traditional forwarding table only supports making forwarding decisions based on destination IP addresses.
	TwoD-IP routing protocol needs a new forwarding table structure that supports making forwarding decisions
	based on both destination and source IP addresses. This can be achieved through a variety of ways, we will
	discuss them in the next version of this document.</t>
  </section>
		
<section title="Implementation">
	<t>We have developed a prototype of the TwoD-IP policy routing protocol based on Quagga, and 
		set up tests with a small scale testbed.
	</t>	
</section>
		
<section title="Conclusion">
	<t>
	</t>	
</section>
		
<section title="IANA Considerations">
	<t>
		Some newly designed TwoD-IP routing protocols may need new protocol numbers assigned by IANA. 
		</t>
</section>

<section title="Acknowledgments">
<t>Zheng Liu and Gautier Bayzelon provided useful input into this document.</t>
</section>
</middle>

<back>
	<references title="Normative References">
		<?rfc include="reference.RFC.3704" ?>
		<?rfc include="reference.RFC.5340" ?>
		<?rfc include="reference.RFC.7368" ?>
		<?rfc include="reference.RFC.8362" ?>
	</references>

	<references title="Informative References">
		<?rfc include="reference.I-D.draft-baker-fun-routing-class-00" ?>
	</references>
</back>
</rfc>
