| Internet-Draft | Two-IP Routing in HomeNet | March 2022 |
| Xu, et al. | Expires 25 September 2022 | [Page] |
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.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 September 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [1].¶
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 [3].¶
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.¶
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.¶
Terminology used in this document:¶
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.¶
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.¶
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.¶
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.¶
+--------------------------+
| |
| Internet |
| |
| |
+--------------------------+
| |
+-----------+---+ +---+-------------+
| | | |
| ISP1: P1 | | ISP2: P2 |
| | | |
+--------+------+ +-----+-----------+
| |
+--+---+ +--+---+
|Router| |Router|
| BR1 | | BR2 |
+---+--+ +---+--+
------+------------+- -+-------------+-----
+-+----+-+
| Router |
| I1 |
+---+----+
-------+--------
|
+--+---+ Address A in P1
| Host |
+------+ Address B in P2
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 [3].¶
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.¶
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.¶
+---------------------+
| |
| Internet |
+----------+----------+
|
+---+---+
| |
+------| BR1 |------+
| +-------+ |
+------------+ | | +------------+
| | +---+---+ +---+---+ | |
| Guest | | | | | | Private |
| Network +-----+ I1 | | I2 +-----+ Network |
| | +---+---+ +---+---+ | |
+------------+ | | +------------+
| +-------+ |
+------| +------+
| I3 |
+---+---+
|
+-----+------+
| |
| Restricted |
| Network |
| |
+------------+
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 [3]. The new routing protocol can be self-configuring, and allows customizing for selected subnets.¶
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 [2].¶
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.¶
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.¶
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.¶
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.¶
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 [5].¶
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.¶
+---------------+ +-----------------+
| | | |
| 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
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.¶
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.¶
+---+---+
| |
+------| 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 |
+------------+
The new protocol need to carry source address prefixes information in link state advertisements. We use the OSPF extension in [4] to carry the additional prefixes. The format of the extended TLV is defined as following.¶
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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD.¶
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.¶
We have developed a prototype of the TwoD-IP policy routing protocol based on Quagga, and set up tests with a small scale testbed.¶
Some newly designed TwoD-IP routing protocols may need new protocol numbers assigned by IANA.¶
Zheng Liu and Gautier Bayzelon provided useful input into this document.¶