| Network Working Group | M. Xu |
| Internet-Draft | S. Yang |
| Expires: April 13, 2016 | J. Wu |
| Tsinghua University | |
| F. Baker | |
| Cisco Systems | |
| October 11, 2015 |
Extending OSPFv3 to Support Multi-homing
draft-xu-ospf-multi-homing-ipv6-00
Traditionally, routing protocols make routing decisions solely based on destination IP addresses, 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 networks that have only one egress router. However, in the multi-homing scenario, packets may be dropped if forwarded only based on destination addresses.
This document defines enhancements to the OSPFv3 protocol that allow simple and flexible operations, with which packets will be routed towards the corresponding upstream ISPs based on both destination and source addresses.
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 http://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 April 13, 2016.
Copyright (c) 2015 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as 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.
Networks are growing both in device count and in complexity. Today they are generally connected with multiple upstream providers, and may require routing to place audio/visual entertainment traffic one one path, office services on another. Traditionally, we have simplified networks using a single exit router. Increasingly, such networks are multi-homed.
Traditionally, routing protocols make routing decisions solely based on destination IP addresses, 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 networks that have only one egress router. However, in the multi-homing scenario, packets may be dropped if forwarded only based on destination addresses [RFC3704].
Although many patch-like solutions, like static routing, policy-based routing (PBR), multi-topology routing (MTR) and layer-3 VPN can solve the problem, they complex the configurations in networks, and are not suitable for ISP administrators. We need a simple solution to help administrators manage their networks in the multi-homing scenario.
In this document, we define enhancements to OSPFv3 that allow networks route packets towards the corresponding upstream ISPs, according to both destination and source addresses. The enhancements defined in this memo are backward-compatible with the OSPFv3 specification defined in [RFC5340], and with the OSPF extensions defined in [I-D.ietf-ospf-ospfv3-lsa-extend]
Terminology used in this document:
Traditionally, egress routers obtain delegated prefixes from upstream ISPs using DHCPv6 with prefix options [RFC3633]. The egress routers will then assign longer sub-prefixes to the other links in the network. Each router inside the network will act as standard OSPFv3 router, and forward packets based on their destination addresses.
With traffic class routing, after obtaining delegated prefixes and assigning sub-prefixes, egress routers will populate traffic classes (with extended LSAs), rather than destination address only, into the network. Each internal router will flood these traffic classes information. When calculating the path towards a destination address, routers will take the traffic classes into considerations. Intrinsically, in traditional routing model, the object being routed to is a destination prefix; in the new routing model, the object being routed might be a destination prefix given that the packet sports a certain source prefix.
Each traffic class is associated with a cost, which is a single dimensionless metric.
For example, as shown in Figure 1, a site is connected to the Internet through two ISPs, ISP1 and ISP2. ISP1 delegates prefix P1 to the site, and ISP2 delegates prefix P2 to the site. After being delegated with P1, the egress router E1 of the site will advertise a traffic class - {::/0, P1}, into the site. After being delegated with P2, the egress router E2 of the site will advertise a traffic class - {::/0, P2}, into the site. Receiving these advertisements, interior router I1 will compute two paths towards ::/0, one through router E1 for traffic from P1, the other through E2 for traffic from P2.
+---------------+ +-----------------+
| | | |
| ISP1: P1 | | ISP2: P2 |
| | | |
+--------+------+ +-----+-----------+
| |
+--+---+ +--+---+
|Router| |Router|
| BR1 | | BR2 |
+---+--+ +---+--+
------+---------- -----------+-----
| |
+---+--+ +---+--+
|Router| |Router|
| E1 | | E2 |
+------+ +------+ +------+
-+-------+Router+---------+-
| I1 |
+--+---+
+--+---+ Address A in P1
| Host |
+------+ Address B in P2
Figure 1: Multi-homing Scenario
All routers behave like traditional OSPFv3 routers, however, the following behaviors are different with traditional OSPFv3 routers.
After obtaining delegated prefixes using DHCPv6 with prefix options, an egress router should originate TC-LSAs, i.e., extended LSAs with source prefixes appended. Egress routers then will advertise these TC-LSAs into the network.
Note that an egress router behaves like an interior router if it receives a TC-LSA from other egress routers.
Receiving TC-LSAs from egress routers, an interior router should store the TC-LSAs into its LSDB, and flood it to other routers. After calculating a path to an egress router advertising reachability, i.e., a destination prefix, the interior router should decide which traffic class can follow this path towards the egress router. If a traffic class can travel through two different paths, then interior router should compare their costs, and select the path with the lowest cost.
Interior routers contains a routing table that contains all necessary information to forward an IP packet following the path of a traffic class. After computing the path towards a traffic class, interior routers should update the entry in the routing table if necessary, e.g., change the next hop towards the traffic class. The routing table structure will be described in Section 6. Calculation of routing table will be illustrated in Section 7.
At last, interior routers should update the Forwarding Information Base (FIB), which will be discussed in the next version of this document.
TC-LSA adds TLV extensions, which contains source prefix information, based on original OSPFv3 LSA. We follow the TLV format in [I-D.baker-ipv6-ospf-dst-src-routing] and extended LSA format in [I-D.ietf-ospf-ospfv3-lsa-extend].
Each extended LSA includes the traditional LSA part in [RFC5340], and one or more TLVs defined in [I-D.baker-ipv6-ospf-dst-src-routing]. But we do not need all LSAs to be extended, the LSAs need to be extended are as follows:
The extended LSA format for Intra-Area-Prefix-LSA in multi-homing is shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| LSA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | LSA Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Prefixes | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPrefixLength | SPrefixOptions| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Intra-Area-Prefix-LSA format
All LSA header fields are the same as defined in [RFC5340], except the following:
In the extended LSA, suppose there are n destination prefix d1, d2, ..., dn, and 1 source prefix s, then the LSA carries n TC-route announcement, (d1, s, v1), (d2, s, v2), ..., (dn, s, vn), where vi is the metric associated with destination prefix di.
For traditional routing, the routing table structure contains all needed information to forward IP packets to the right destination. For example, destination prefixes are commonly structured into a prefix trie, where each trie nodes contain the necessary information. Routers can lookup and update the prefix trie.
With traffic classes, the routing table structure must contain all needed information to forward IP packets following the right traffic class, i.e., towards the related destination and from the related source. For each routing table entry, there are two additional fields other than the fields mentioned in [RFC5340]:
The routing table must provide interface for update and lookup in it. For example, traffic classes can be structured into a two dimensional (or two level) trie, where each trie node in the first dimension points to a sub-trie in the second dimension. The trie nodes in the second dimension contain the necessary information to forward IP packets following the right traffic class.
There exist multiple implementation in real routers. For example, 1) we can add an additional routing table besides the destination-based routing table; 2) the destination-based routing table can be extended to support the new structure, in which case all destination-based rule can be appended with a wildcard IPv6 address prefix as the source prefix. The specific implementation for routing table is out of scope of this document.
The fundamental algorithm in OSPFv3 doesn't change. The algorithm uses the SPF approach to calculate a path to the router advertising reachability, and then uses the reachability advertisement to decide what traffic should follow that route. What we are changing is the reachability advertisement, in traiditional OSPFv3, the advertisements, which is one or several kinds of LSAs, represent destination prefixes; in this document, the advertisements, which is one or several kinds of TC-LSAs, represent traffic classes.
Note that we do not have to change router-LSA and network-LSA in [RFC5340]. Thus, the first stage of Section 4.8.1 in [RFC5340] remains the same in this document. However, the second stage of Section 4.8.1 in [RFC5340] should change by a little bit. Instead of examining the list of the intra-area-prefix-LSAs, the list of extended intra-area-prefix-LSAs is examined. The cost of any advertised traffic class is the sum of the class' advertised metric plus the cost of the transit vertex (either router or transit network) indentified by extended intra-area-prefix-LSAs' referenced LS type, referenced link state ID, and referenced advertising router field.
We also adopt the LMF (longest match first) rule when a packet matches multiple routing entries. However, traffic class has two dimensions, there might exist ambiguity. For example, if there exists two routing entries, (d1, s1, nexthop1), (d2, s2, nexthop2), where d1 is longer than d2 and s2 is longer than s1, then none entry is longer than the other in both dimensions. In this situation, we must insert an additional entry into the routing table, e.g., (d1, s2, nexthop1) in the above example. The entry directs to nexthop1 rather than nexthop2, because we must guarantee consistency among routers.
With the enhancements, incremental deployment is possible. The un-deployed routers act according to [RFC5340], and will drop the extended LSA packets when receiving them.
The newly LSA types and TLVs should be assigned by IANA, please refer to [I-D.baker-ipv6-ospf-dst-src-routing] and [I-D.ietf-ospf-ospfv3-lsa-extend].
Zheng Liu and Gautier Bayzelon provided useful input into this document.
| [RFC3704] | Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004. |
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003. |
| [RFC5340] | Coltun, R., Ferguson, D., Moy, J. and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008. |
| [I-D.baker-ipv6-ospf-dst-src-routing] | Baker, F., "IPv6 Source/Destination Routing using OSPFv3", Internet-Draft draft-baker-ipv6-ospf-dst-src-routing-03, August 2013. |
| [I-D.ietf-ospf-ospfv3-lsa-extend] | Lindem, A., Mirtorabi, S., Roy, A. and F. Baker, "OSPFv3 LSA Extendibility", Internet-Draft draft-ietf-ospf-ospfv3-lsa-extend-07, August 2015. |