One document matched: draft-xu-homenet-traffic-class-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" symrefs="no" ?>
<rfc docName="draft-xu-homenet-traffic-class-02" ipr="pre5378Trust200902">
<front>
<title abbrev="Traffic Class Routing in HomeNet">Traffic Class Routing Protocol in Home Networks</title>
<author initials='M.' surname='Xu' fullname='Mingwei Xu'>
<organization abbrev='Tsinghua University'>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>xmw@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author initials='S.' surname='Yang' fullname='Shu Yang'>
<organization abbrev='Tsinghua University'>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>yangshu@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author initials="J." surname="Wu" fullname="Jianping Wu">
<organization abbrev="Tsinghua University">Tsinghua University</organization>
<address>
<postal>
<street>
Department of Computer Science, Tsinghua University
</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86-10-6278-5983</phone>
<email>jianping@cernet.edu.cn</email>
</address>
</author>
<author initials="F." surname="Baker" fullname="Fred Baker">
<organization abbrev="Cisco Systems">Cisco Systems</organization>
<address>
<postal>
<street> </street>
<city>Santa Barbara, California</city>
<code>93117</code>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date month="April" year="2014" />
<abstract>
<t>Home IT staff is generally unfamiliar with network operations, making it desirable to provide a configuration-free mode of operation. Policy-based routing (in the sense of configuring one router to redirect traffic to another based on access control) and multi-topology routing both require configuration, making them undesirable.
</t>
<t>
In this document, we propose a configuration-free mechanism, in which packets will be routed towards
the corresponding upstream ISPs based on both destination and source addresses.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Home networks are growing both in device count and in complexity. Today they generally contain both wired and wireless components, and may require routing to place audio/visual entertainment traffic one one path, office services on another, and wireless LANs (both IEEE-style and 4G/LTE-style) on a third. Traditionally, we have simplified networks using a single exit router and a default route. Today, we might have multiple routers to wired upstream networks, and by separate paths LTE services, "Smart Grid" services, or health network services. Increasingly, such networks are multihomed, and multihomed using diverse access network technologies.</t>
<t>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
home networks that have only one egress router. However, in the multi-homing scenario, packets may be dropped if forwarded
only based on destination addresses <xref target="RFC3704"></xref>. </t>
<t>Although many patch-like solutions, like policy-based routing (PBR), multi-topology routing (MTR) and layer-3 VPN can solve the problem, they complex the configurations in home networks, and are not suitable for home IT staffs. We need a configuration-free solution to help operators set up their home networks in the multi-homing scenario.</t>
<t>In this document, we propose a configuration-free mechanism - traffic class routing, based on OSPFv3, such that home networks can route packets towards the corresponding upstream ISPs, according to both destination and source addresses.</t>
</section>
<section title="Terminology">
<t>Terminology used in this document:</t>
<t><list style="symbols">
<t>Traffic Class (TC): Identified by (destination prefix, source prefix), all packets falling in the domain belong to the traffic
class.</t>
<t>TC-Route: Identified by (destination prefix, source prefix, value), where value is the administrative value applied to the
traffic class (destination prefix, source prefix). </t>
<t>TC-LSA: Link state advertisement that communicates the reachability for a traffic classes.</t>
</list>
</t>
</section>
<section title="Overview">
<t>
In a home network, traditionally, egress routers obtain delegated prefixes from upstream ISPs using DHCPv6 with prefix options <xref target="RFC3633"></xref>. The egress routers will then assign longer sub-prefixes to the other links in the home network. Each router inside the home network will act as standard OSPFv3 router, and forward packets based on their destination addresses.
</t>
<t>
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 home network. Each router inside the home network 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 our routing model, the object being routed might be a destination prefix given that the packet sports a certain source prefix.
</t>
<t>
Each traffic class is associated with a cost, which is a single dimensionless metric.
</t>
<t>
For example, 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.
</t>
<figure title="Figure 1: Multi-homing Scenario in Home Networks">
<artwork>
<![CDATA[
+---------------+ +-----------------+
| | | |
| ISP1: P1 | | ISP2: P2 |
| | | |
+--------+------+ +-----+-----------+
| |
+--+---+ +--+---+
|Router| |Router|
| BR1 | | BR2 |
+---+--+ +---+--+
------+---------- -----------+-----
| |
+---+--+ +---+--+
|Router| |Router|
| E1 | | E2 |
+------+ +------+ +------+
-+-------+Router+---------+-
| I1 |
+--+---+
+--+---+ Address A in P1
| Host |
+------+ Address B in P2
]]>
</artwork>
</figure>
</section>
<section title = "Router Behavior">
<t>
All routers behave like traditional OSPFv3 routers, however, the following behaviors are different with traditional OSPFv3 routers.
</t>
<section title = "Egress Router Behavior">
<t>
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 home network.
</t>
<t>
Note that an egress router behaves like an interior router if it receives a TC-LSA from other egress routers.
</t>
</section>
<section title = "Interior Router Behavior">
<t>
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. The cost for a traffic class is the
sum of the advertised metric of the traffic class plus the cost towards the egress router.
</t>
<t>
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.
</t>
<t>
At last, interior routers should update the Forwarding Information Base (FIB), which will be discussed in the next version of this document.
</t>
</section>
</section>
<section title = "TC-LSA Format">
<t>
TC-LSA adds TLV extensions, which contains source prefix information, based on original OSPFv3 LSA. We follow the TLV format
in <xref target="I-D.baker-ipv6-ospf-dst-src-routing"></xref> and extended LSA format in <xref target="I-D.acee-ospfv3-lsa-extend"></xref>.
</t>
<t>
Each extended LSA includes the traditional LSA part in <xref target="RFC5340"></xref>, and one or more TLVs defined in <xref target="I-D.baker-ipv6-ospf-dst-src-routing"></xref>. Because home network is not so large, we do not need to extend all LSAs. The extended
LSAs are as follows:</t>
<t><list style="symbols">
<t> E-Intra-Area-Prefix-LSA: The extended LSA has type 0xA029.</t>
</list></t>
<t>
The format of E-Intra-Area-Prefix-LSA in multi-homing is as follows:
</t>
<t>
<figure title="Figure 1: Multi-homing Scenario in Home Networks">
<artwork>
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPrefixLength | SPrefixOptions| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
All LSA header fields are the same as defined in <xref target="RFC5340"></xref>, except the following:
</t>
<t><list style="symbols">
<t> LSA type: The LSA type value is 0xA029, according to <xref target="I-D.acee-ospfv3-lsa-extend"></xref>;</t>
<t> LSA length: The length of the whole LSA header, including the TLVs; </t>
<t> TLV type: The type of IPv6 source prefix TLV, assigned by IANA;</t>
<t> TLV length: The value is 20 as defined in <xref target="I-D.baker-ipv6-ospf-dst-src-routing"></xref>;</t>
<t> SPrefixLength, SPrefixOptions, Source Address Prefix: Representation of the IPv6 address prefix, which is delegated from the upstream ISP providers;</t>
</list></t>
<t>
For simplicity, each extended LSA should only carry one source prefix, suppose there are n destination prefix d1, d2, ..., dn,
and the source prefix is s, then the LSA
carries n TC-route announcement, (d1, s, v1), (d1, s, v2), ..., (dn, s, vn),
where vi is the metric associated with destination prefix di.
</t>
</section>
<section title = "Routing Table Structure">
<t>
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.
</t>
<t>
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 <xref target="RFC5340"></xref>:
</t>
<t><list style="symbols">
<t> Source IP Address: The IP address of the source in traffic class.</t>
<t> Source Address Mask: If the source is a subnet, then it is referred to as the subnet mask.</t>
</list></t>
<t>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.
</t>
</section>
<section title = "Calculation of the Routing Table">
<t>
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.
</t>
<t>
Note that we do not have to change router-LSA and network-LSA in <xref target="RFC5340"></xref>. Thus, the first stage of
Section 4.8.1 in <xref target="RFC5340"></xref> remains the same in this document. However, the second stage of Section 4.8.1 in
<xref target="RFC5340"></xref> 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.
</t>
</section>
<section title = "Matching Rule">
<t>
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 reachability according to
the destination prefix.
</t>
</section>
<section title = "Forwarding Table Structure">
<t>
As the format of routing table entries changes from (destination
prefix, nexthop) to (destination prefix, source prefix, nexthop),
The Forwarding Information Base (FIB), based on which routers forward IP
packets, should be redesigned. There can be different possible FIB
structures, e.g., TCAM-based structure, linear table structure, trie-based structure, etc.
we use a trie-based solution in this document.
</t>
<t>
In traditional routing, the
destination prefixes are constructed using a prefix trie.
However, in traffic class routing, the forwarding decision is based on
both the destination and source prefixes. To store them, we
design a new structure, based on patricia-trie to meet
the needs.
</t>
<t>
In traffic class routing, the router forwards IP packets following the right
traffic class based on destination and
source prefixes. Routers construct a two dimensional (or two level)
patricia-trie, where each trie node in the first dimension points
to a sub-trie (the sub-trie can be empty).
When a packet arrives, the packet should match a trie node (destination prefix) in the
first dimension using the destination address. Following the
sub-trie under the node, the packet should match another trie node (source prefix)
in the second dimension, i.e., the sub-trie.
</t>
</section>
<section title = "Implementation">
<t>
We implemented the routing protocol in Quagga, an open-source routing software.
In Quagga, we modified the LSA format to support E-Intra-Area-Prefix-LSA, the
routing table format, and the routing table calculation algorithm.
</t>
<t>
To implement the FIB structure, we modified Click, which is a
modular software router. The FIB
structure could support lookup and update.
When the routing table changes, routers can update the FIB through
pre-defined interfaces.
</t>
</section>
<section title = "Compatibility">
<t>
Routers can also announce the traditional destination-based LSAs, e.g., Intra-Area-Prefix-LSA, at the same time. When a router
receives traditional destination-based LSAs, it has two choices.
In the first choice, the destination-based LSAs are treated as TC-LSAs where the source prefix equal the wildcard, and
routers keep all routes in a common routing table. When a packet arrives, routers need to lookup in the routing table
according to the matching rule.
In the second choice, routers have to keep two
routing tables, one for destination prefix only, and the other for traffic classes. When a packet arrives, routers first
lookup in the routing table storing traffic classes; If none entry matches, then routers lookup in the routing table storing
destination prefixes.
</t>
</section>
<section title="IANA Considerations">
<t>
The newly LSA types and TLVs should be assigned by IANA, please refer to <xref target="I-D.baker-ipv6-ospf-dst-src-routing"></xref> and <xref target="I-D.acee-ospfv3-lsa-extend"></xref>.
</t>
</section>
<section title="Acknowledgments">
<t>Zheng Liu and Gautier Bayzelon provided useful input into this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.3633" ?>
<?rfc include="reference.RFC.5340" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.draft-ietf-homenet-arch-07" ?>
<?rfc include="reference.I-D.draft-baker-ipv6-ospf-dst-src-routing-02" ?>
<?rfc include="reference.I-D.draft-acee-ospfv3-lsa-extend-00" ?>
<?rfc include="reference.I-D.draft-baker-fun-routing-class-00" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:28 |