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