< draft-xu-homenet-twod-ip-routing-01.txt   draft-xu-homenet-twod-ip-routing-02.txt >
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft S. Yang Internet-Draft J. Wu
Expires: February 23, 2014 J. Wu Intended status: Standards Track Tsinghua University
Tsinghua University Expires: 25 September 2022 S. Yang
L. Cui
Shenzhen University
D. Wang D. Wang
Hong Kong Polytechnic University Hong Kong Polytechnic University
August 22, 2013 24 March 2022
Two Dimensional-IP Routing Protocol in Home Networks Two Dimensional-IP Routing Protocol in Home Networks
draft-xu-homenet-twod-ip-routing-01 draft-xu-homenet-twod-ip-routing-02
Abstract Abstract
Home network design faces many challenges currently. Two of them are Home network design faces many challenges currently. Two of them are
multi-homing and policy enforcement. Different with other types of multi-homing and policy enforcement. Different with other types of
networks, home network operators are usually not professional networks, home network operators are usually not professional
technicians or geeks. The problems we face are fundamentally related technicians or geeks. The problems we face are fundamentally related
with the poor semantics provided by current destination-based routing with the poor semantics provided by current destination-based routing
protocol. protocol.
skipping to change at page 1, line 36 skipping to change at page 1, line 38
homing and policy routing across home networks. homing and policy routing across home networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 23, 2014. This Internet-Draft will expire on 25 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenario of Interests . . . . . . . . . . . . . . . . . . . . 4 3. Scenario of Interests . . . . . . . . . . . . . . . . . . . . 4
3.1. Multi-homing in Home Networks . . . . . . . . . . . . . . 4 3.1. Multi-homing in Home Networks . . . . . . . . . . . . . . 4
3.2. Access-control in Home Networks . . . . . . . . . . . . . 6 3.2. Access-control in Home Networks . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. TwoD Link Metric Configuration . . . . . . . . . . . . . . . 8 5. TwoD Link Metric Configuration . . . . . . . . . . . . . . . 8
6. New Link State Advertisement/Database . . . . . . . . . . . . 10 6. New Link State Advertisement/Database . . . . . . . . . . . . 10
7. Calculation of The Routing Table . . . . . . . . . . . . . . 10 7. Calculation of The Routing Table . . . . . . . . . . . . . . 11
8. Forwarding Table Modification . . . . . . . . . . . . . . . . 10 8. Forwarding Table Modification . . . . . . . . . . . . . . . . 11
9. Incremental Deployment . . . . . . . . . . . . . . . . . . . 10 9. Implementation . . . . . . . . . . . . . . . . . . . . . . . 11
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
With more and more devices joining home networks, there are With more and more devices joining home networks, there are
increasingly large residential home networks. Traditionally, we keep increasingly large residential home networks. Traditionally, we keep
home networks simple using single exit router (subnet) and default home networks simple using single exit router (subnet) and default
route. However, more complex network technologies, such as multi- route. However, more complex network technologies, such as multi-
homing, appear when the networks become large. Besides, users demand homing, appear when the networks become large. Besides, users demand
for more than connectivity service, as varieties of devices like for more than connectivity service, as varieties of devices like
private health sensors, exist in their home networks. For example, private health sensors, exist in their home networks. For example,
skipping to change at page 3, line 28 skipping to change at page 3, line 14
simpler and more flexible routing protocol in home networks. simpler and more flexible routing protocol in home networks.
Traditionally, routing protocols make routing decisions solely based Traditionally, routing protocols make routing decisions solely based
on destination IP addresses, so packets towards the same destination on destination IP addresses, so packets towards the same destination
will be delivered to the same next hop no matter where they come will be delivered to the same next hop no matter where they come
from. These protocols work well with simple home networks. However, from. These protocols work well with simple home networks. However,
as users demand for more source-related functions and network as users demand for more source-related functions and network
techonologies evolve. Destination-based routing protocol can not techonologies evolve. Destination-based routing protocol can not
handle these demands, and even fail to provide the basic connectivity handle these demands, and even fail to provide the basic connectivity
services. For example, in the multi-homing scenario, packets may be services. For example, in the multi-homing scenario, packets may be
dropped if forwarded only based on destination addresses [RFC3704]. dropped if forwarded only based on destination addresses [1].
Although many patch-like solutions, like policy-based routing (PBR), Although many patch-like solutions, like policy-based routing (PBR),
can improve the situation. However, they complex the configurations can improve the situation. However, they complex the configurations
in home networks, and are not suitable for home network operators. in home networks, and are not suitable for home network operators.
The underlying cause for these problems is the lack of semantics of The underlying cause for these problems is the lack of semantics of
destination-based routing. A new routing protocol that makes routing destination-based routing. A new routing protocol that makes routing
decisions based on both destination and source IP addresses is decisions based on both destination and source IP addresses is
preferred in future home networks [I-D.ietf-homenet-arch]. preferred in future home networks [3].
In this document, we propose a new link state routing protocol, In this document, we propose a new link state routing protocol,
called Two Dimensional-IP (TwoD-IP) routing protocol, that greatly called Two Dimensional-IP (TwoD-IP) routing protocol, that greatly
enriches the routing semantics. We list two important scenarios, enriches the routing semantics. We list two important scenarios,
including multi-homing and access control in home networks, where including multi-homing and access control in home networks, where
TwoD-IP routing protocol will apply. We also use them as examples to TwoD-IP routing protocol will apply. We also use them as examples to
illustrate the new routing protocol. illustrate the new routing protocol.
We modify OSPF to support our TwoD-IP routing protocol. With one We modify OSPF to support our TwoD-IP routing protocol. With one
more dimension, the routing protocol has to disseminate additional more dimension, the routing protocol has to disseminate additional
information with newly defined LSAs, and compute a two dimensional information with newly defined LSAs, and compute a two dimensional
routing table based on the collected LSAs. Thus, we must design new routing table based on the collected LSAs. Thus, we must design new
LSA packet formats, data structures and routing algorithms for the LSA packet formats, data structures and routing algorithms for the
new routing protocol. new routing protocol.
2. Terminology 2. Terminology
Terminology used in this document: Terminology used in this document:
o TwoD-IP routing protocol: Two Dimensional IP routing protocol, * TwoD-IP routing protocol: Two Dimensional IP routing protocol,
which makes routing decisions based on both destination and source which makes routing decisions based on both destination and source
IP addresses. IP addresses.
o Guest Network: A subnet in a home network, that supports * Guest Network: A subnet in a home network, that supports
communication with other subnets in the home network and the communication with other subnets in the home network and the
Internet. Internet.
o Private Network: A subnet in a home network, that only supports * Private Network: A subnet in a home network, that only supports
communication with other subnets in the home network. communication with other subnets in the home network.
o Restricted Network: A subnet in a home network, that supports * Restricted Network: A subnet in a home network, that supports
communication with other subnets in the home network and only communication with other subnets in the home network and only
parts of the Internet. parts of the Internet.
o TwoD Traffic Class: We borrow the definition from * TwoD Traffic Class: We borrow the definition from [5], which
[I-D.baker-fun-routing-class], which describes it as a selector describes it as a selector that identifies a set of traffic, e.g.,
that identifies a set of traffic, e.g., from a stated source from a stated source prefix and towards a stated destination
prefix and towards a stated destination prefix. prefix.
o TwoD Link Metric: The cost of travelling through a link, for a * TwoD Link Metric: The cost of travelling through a link, for a
TwoD traffic class. TwoD traffic class.
o TwoD-LSA: Link state advertisement that disseminates the TwoD link * TwoD-LSA: Link state advertisement that disseminates the TwoD link
metric information across the network. metric information across the network.
o TwoD-LSB: Extended link state database that stores the TwoD-LSAs. * TwoD-LSB: Extended link state database that stores the TwoD-LSAs.
3. Scenario of Interests 3. Scenario of Interests
This section describes two scenarios, including multi-homing and This section describes two scenarios, including multi-homing and
policy routing, where TwoD-IP routing protocol will apply in home policy routing, where TwoD-IP routing protocol will apply in home
networks. Note that TwoD-IP routing protocol can also apply in other networks. Note that TwoD-IP routing protocol can also apply in other
scenarios, despite we focus on two important ones. scenarios, despite we focus on two important ones.
3.1. Multi-homing in Home Networks 3.1. Multi-homing in Home Networks
skipping to change at page 5, line 47 skipping to change at page 5, line 33
+-+----+-+ +-+----+-+
| Router | | Router |
| I1 | | I1 |
+---+----+ +---+----+
-------+-------- -------+--------
| |
+--+---+ Address A in P1 +--+---+ Address A in P1
| Host | | Host |
+------+ Address B in P2 +------+ Address B in P2
Figure 1: Multi-homing Scenario in Home Networks Figure 1: Figure 1: Multi-homing Scenario in Home Networks
3.2. Access-control in Home Networks 3.2. Access-control in Home Networks
Home networks will involve multiple subset and routers, as more and Home networks will involve multiple subset and routers, as more and
more dedicated devices including sensors are incorporated into home more dedicated devices including sensors are incorporated into home
networks. Different subsets in home networks usually have different networks. Different subsets in home networks usually have different
privacy and security policies. For instance, modern home routers privacy and security policies. For instance, modern home routers
will support both guest and private subnets [I-D.ietf-homenet-arch]. will support both guest and private subnets [3].
For example, in Figure 2, a home network is divided into three For example, in Figure 2, a home network is divided into three
subnets, the guest network, private network and restricted network. subnets, the guest network, private network and restricted network.
The guest network can communicate with all peer devices/hosts inside The guest network can communicate with all peer devices/hosts inside
or outside the home network. The private network can only or outside the home network. The private network can only
communicate with all devices/hosts inside the home network. For the communicate with all devices/hosts inside the home network. For the
restricted network, it can communicate with others inside the home restricted network, it can communicate with others inside the home
network, but only has limited Internet access. network, but only has limited Internet access.
Considering the importance of privacy and security in home network, Considering the importance of privacy and security in home network,
this senario will be common in the home network enviroment. With this senario will be common in the home network enviroment. With
more and more devices, like some private health sensors taking part more and more devices, like some private health sensors taking part
in, it is envisaged that home networks should provide a simple and in, it is envisaged that home networks should provide a simple and
flexible routing protocol, where access-control could be made in much flexible routing protocol, where access-control could be made in much
finer granularity. finer granularity.
+---------------------+ +---------------------+
| | | |
| Internet | | Internet |
+----------+----------+ +----------+----------+
| |
+---+---+ +---+---+
| | | |
+------| BR1 |------+ +------| BR1 |------+
| +-------+ | | +-------+ |
+------------+ | | +------------+ +------------+ | | +------------+
| | +---+---+ +---+---+ | | | | +---+---+ +---+---+ | |
| Guest | | | | | | Private | | Guest | | | | | | Private |
| Network +-----+ I1 | | I2 +-----+ Network | | Network +-----+ I1 | | I2 +-----+ Network |
| | +---+---+ +---+---+ | | | | +---+---+ +---+---+ | |
+------------+ | | +------------+ +------------+ | | +------------+
| +-------+ | | +-------+ |
+------| +------+ +------| +------+
| I3 | | I3 |
+---+---+ +---+---+
| |
+-----+------+ +-----+------+
| | | |
| Restricted | | Restricted |
| Network | | Network |
| | | |
+------------+ +------------+
Figure 2: Acess-control Scenario in Home Networks Figure 2: Figure 2: Acess-control Scenario in Home Networks
4. Protocol Overview 4. Protocol Overview
TwoD-IP routing protocol is a link-state routing protocol, which is TwoD-IP routing protocol is a link-state routing protocol, which is
preferred in home network, as routing protocol can have knowledge of preferred in home network, as routing protocol can have knowledge of
the whole home network topology [I-D.ietf-homenet-arch]. The new the whole home network topology [3]. The new routing protocol can be
routing protocol can be self-configuring, and allows customizing for self-configuring, and allows customizing for selected subnets.
selected subnets.
Similar with traditional OSPF protocol, TwoD-IP periodically gather Similar with traditional OSPF protocol, TwoD-IP periodically gather
link information and dynamically construct network topology. Then link information and dynamically construct network topology. Then
routers within TwoD-IP routing protocol maintain link state data base routers within TwoD-IP routing protocol maintain link state data base
that describes network topology. After that, all routers will run that describes network topology. After that, all routers will run
routing algorithm that determines the next hop for each packet routing algorithm that determines the next hop for each packet [2].
[RFC5340].
Different with OSPF protocol, which makes routing decisions solely Different with OSPF protocol, which makes routing decisions solely
based on the destination IP address, and computes next hop towards based on the destination IP address, and computes next hop towards
different destination IP addresses; TwoD-IP routing protocol makes different destination IP addresses; TwoD-IP routing protocol makes
routing decisions based on both destination and source IP addresses. routing decisions based on both destination and source IP addresses.
Thus, routers need to disseminate and store additional information, Thus, routers need to disseminate and store additional information,
and run a different routing algorithm that computes next hop for and run a different routing algorithm that computes next hop for
different destination and source IP address pairs. different destination and source IP address pairs.
In this document, we will focus on the differences between new TwoD- In this document, we will focus on the differences between new TwoD-
skipping to change at page 8, line 15 skipping to change at page 7, line 49
With the TwoD-LSB, routers can run routing algorithm that computes With the TwoD-LSB, routers can run routing algorithm that computes
the next hop for each TwoD traffic class. Intrinsically, each TwoD the next hop for each TwoD traffic class. Intrinsically, each TwoD
traffic class will match a TwoD link metric on each link over the traffic class will match a TwoD link metric on each link over the
network. Thus, each TwoD traffic class can obtain a full network network. Thus, each TwoD traffic class can obtain a full network
topolgoy (which may be different with the topologies for other TwoD topolgoy (which may be different with the topologies for other TwoD
traffic classes). Then the routing algorithm shall construct an SPT traffic classes). Then the routing algorithm shall construct an SPT
for the TwoD traffic class. When a packet arrives, according to the for the TwoD traffic class. When a packet arrives, according to the
TwoD traffic class that it falls into, it will flow along the TwoD traffic class that it falls into, it will flow along the
corresponding SPT. Note that a packet may fall into multiple TwoD corresponding SPT. Note that a packet may fall into multiple TwoD
traffic class, we resolve the confliction through the "Most Specific traffic class, we resolve the confliction through the "Most Specific
First" rule [I-D.baker-fun-routing-class]. First" rule [5].
5. TwoD Link Metric Configuration 5. TwoD Link Metric Configuration
Like OSPF, the TwoD link metric is configured in the interface data Like OSPF, the TwoD link metric is configured in the interface data
structure. However, TwoD link metric is not solely a scalar that structure. However, TwoD link metric is not solely a scalar that
describes the cost of sending a packet on the interface, but a triple describes the cost of sending a packet on the interface, but a triple
(destination prefix, source prefix, cost) that describes the cost of (destination prefix, source prefix, cost) that describes the cost of
sending a packet for TwoD traffic class (destination prefix, source sending a packet for TwoD traffic class (destination prefix, source
prefix). A single link can be configured to have multiple TwoD link prefix). A single link can be configured to have multiple TwoD link
metrics, each for a different TwoD traffic class. Note that the metrics, each for a different TwoD traffic class. Note that the
skipping to change at page 8, line 50 skipping to change at page 8, line 38
+-+----+-+ +-+----+-+
| Router | | Router |
| I1 | | I1 |
+---+----+ +---+----+
-------+-------- -------+--------
| |
+--+---+ Address A in P1 +--+---+ Address A in P1
| Host | | Host |
+------+ Address B in P2 +------+ Address B in P2
Figure 3: TwoD link metric configuration in the multi-homing Scenario Figure 3: Figure 3: TwoD link metric configuration in the multi-
homing Scenario
Continuing the example in Figure 1, we plot the TwoD link metric Continuing the example in Figure 1, we plot the TwoD link metric
configuration in Figure 3. We only have to configure the out-going configuration in Figure 3. We only have to configure the out-going
interface (like IF1 and IF2) on the border routers. On IF1, we interface (like IF1 and IF2) on the border routers. On IF1, we
configure two TwoD link metrics, (*, P1, 1) and (*, P2, 1000), configure two TwoD link metrics, (*, P1, 1) and (*, P2, 1000),
indicating packets from P1 will traverse the link with cost 1 while indicating packets from P1 will traverse the link with cost 1 while
packets from P2 will traverse the link with much higher cost, 1000. packets from P2 will traverse the link with much higher cost, 1000.
Similarly, on IF2, we also configure two TwoD link metrics, (*, P2, Similarly, on IF2, we also configure two TwoD link metrics, (*, P2,
1) and (*, P1, 1000). With this configuration, traffic from P1 (or 1) and (*, P1, 1000). With this configuration, traffic from P1 (or
P2) will see a topology where the path through ISP1 (or ISP2) costs 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 much less than the path through ISP2 (or ISP1). Packets from P1 (or
skipping to change at page 9, line 31 skipping to change at page 10, line 5
restricted network can communicate with. We only have to configure restricted network can communicate with. We only have to configure
the router interfaces (like IFA, IFB and IFC) where the subnets are the router interfaces (like IFA, IFB and IFC) where the subnets are
connected. On IFA, we only have to configure (PX, *, 1) as all connected. On IFA, we only have to configure (PX, *, 1) as all
traffic can travel into the guest network. We have to configure (PY, traffic can travel into the guest network. We have to configure (PY,
PR, 1) on IFB, because only hosts from the home network (using PR, 1) on IFB, because only hosts from the home network (using
address in the private prefix) can travel into the private network. 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, 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 because not only hosts inside the home network, but also hosts from
PV, can access the restricted network. PV, can access the restricted network.
+---+---+ +---+---+
| | | |
+------| BR1 |------+ +------| BR1 |------+
| +-------+ | | +-------+ |
+------------+ (PX,*,1)| |(PY,PR,1)+------------+ +------------+ (PX,*,1)| |(PY,PR,1)+------------+
| | +---+---+ +---+---+ | | | | +---+---+ +---+---+ | |
| Guest | IFA| | | |IFB | Private | | Guest | IFA| | | |IFB | Private |
| Network +-----+ I1 | | I2 +-----+ Network | | Network +-----+ I1 | | I2 +-----+ Network |
| | +---+---+ +---+---+ | :PX | | | +---+---+ +---+---+ | :PX |
+------------+ | | +------------+ +------------+ | | +------------+
| +-------+ | | +-------+ |
+------| +------+ +------| +------+
| I3 | | I3 |
+---+---+ (PZ,PV,1) +---+---+ (PZ,PV,1)
|IFC (PZ,PR,1) |IFC (PZ,PR,1)
+-----+------+ +-----+------+
| | | |
| Restricted | | Restricted |
| Network | | Network |
| :PY | | :PY |
+------------+ +------------+
Figure 4: TwoD link metric configuration in the acess-control Figure 4: Figure 4: TwoD link metric configuration in the acess-
Scenario control Scenario
6. New Link State Advertisement/Database 6. New Link State Advertisement/Database
TBD. 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: extension tlv
* Type: Assigned by IANA as denoted in Section 8.1 of [4].
* Length: Length of an IPv6 prefix plus 4 bytes, which is equal to
20.
* PrefixLength, PrefixOptions, and Address Prefix: Denoting an IPv6
prefix, as defined in [2].
7. Calculation of The Routing Table 7. Calculation of The Routing Table
TBD. TBD.
8. Forwarding Table Modification 8. Forwarding Table Modification
Traditional forwarding table only supports making forwarding Traditional forwarding table only supports making forwarding
decisions based on destination IP addresses. TwoD-IP routing decisions based on destination IP addresses. TwoD-IP routing
protocol needs a new forwarding table structure that supports making protocol needs a new forwarding table structure that supports making
forwarding decisions based on both destination and source IP forwarding decisions based on both destination and source IP
addresses. This can be achieved through a variety of ways, we will addresses. This can be achieved through a variety of ways, we will
discuss them in the next version of this document. discuss them in the next version of this document.
9. Incremental Deployment 9. Implementation
TwoD-IP routing protocol should support incremental deployment, i.e., We have developed a prototype of the TwoD-IP policy routing protocol
deploying one or two routers shall be useful in certain scenarios. based on Quagga, and set up tests with a small scale testbed.
However, with more routers deployed, the network should be more
flexible to support policies with finer granularity.
10. Conclusion 10. Conclusion
11. IANA Considerations 11. IANA Considerations
Some newly designed TwoD-IP routing protocols may need new protocol Some newly designed TwoD-IP routing protocols may need new protocol
numbers assigned by IANA. numbers assigned by IANA.
12. Acknowledgments 12. Acknowledgments
Zheng Liu and Gautier Bayzelon provided useful input into this Zheng Liu and Gautier Bayzelon provided useful input into this
document. document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [1] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [2] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
13.2. Informative References [3] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
[I-D.ietf-homenet-arch] [4] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, F. Baker, "OSPFv3 Link State Advertisement (LSA)
"Home Networking Architecture for IPv6", draft-ietf- Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
homenet-arch-07 (work in progress), February 2013. 2018, <https://www.rfc-editor.org/info/rfc8362>.
[I-D.baker-fun-routing-class] 13.2. Informative References
Baker, F., "Routing a Traffic Class", draft-baker-fun-
routing-class-00 (work in progress), July 2011. [5] Baker, F., "Routing a Traffic Class", Work in Progress,
Internet-Draft, draft-baker-fun-routing-class-00, 1 July
2011, <http://www.ietf.org/internet-drafts/draft-baker-
fun-routing-class-00.txt>.
Authors' Addresses Authors' Addresses
Mingwei Xu Mingwei Xu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing
100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: xmw@csnet1.cs.tsinghua.edu.cn Email: xmw@cernet.edu.cn
Shu Yang
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6278-5822
Email: yangshu@csnet1.cs.tsinghua.edu.cn
Jianping Wu Jianping Wu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing
100084
P.R. China P.R. China
Phone: +86-10-6278-5983 Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn Email: jianping@cernet.edu.cn
Shu Yang
Shenzhen University
South Campus, Shenzhen University
Shenzhen
518060
P.R. China
Phone: +86-755-2653-4078
Email: yang.shu@szu.edu.cn
Laizhong Cui
Shenzhen University
South Campus, Shenzhen University
Shenzhen
518060
P.R. China
Phone: +86-755-8695-6280
Email: cuilz@szu.edu.cn
Dan Wang Dan Wang
Hong Kong Polytechnic University Hong Kong Polytechnic University
Department of Computing, Hong Kong Polytechnic University Department of Computing, Hong Kong Polytechnic University
Hong Kong Hong Kong
P.R. China P.R. China
Phone: +852-2766-7267 Phone: +852-2766-7267
Email: csdwang@comp.polyu.edu.hk Email: csdwang@comp.polyu.edu.hk
 End of changes. 47 change blocks. 
144 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/