One document matched: draft-baker-ipv6-ospf-extensible-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents, but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-ipv6-ospf-extensible-00"
ipr="trust200902">
<front>
<title abbrev="">Extensible OSPF LSAs</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2013" />
<area>Internet Engineering Task Force</area>
<workgroup></workgroup>
<abstract>
<t>This note describes the changes necessary for OSPFv3 to route
extensible classes of traffic. This implies not routing "to a
destination", but "traffic matching a classification tuple" which
includes a destination but may also include other attributes such as the
source address, DSCP, or Flow Label.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>In related documents, the author proposes extensions to OSPF and
IS-IS for the routing of IPv6 traffic using more than the destination
address as the definition of a class of traffic to be routed. These
include the possibility of source/destination routing, and especially
egress routing, routing based on the destination plus the DSCP value
such as is discussed in <xref target="RFC4915"></xref>, and routing
using the destination plus the IPv6 Flow Label for a form of Role Based
Access Control - if the sender doesn't know the flow label value that
the receiver is using, which it would learn from the network
administrator through configuration, DHCP, or some other means, it in
effect has no route to the destination.</t>
<t>These capabilities, in OSPFv3, are have as a premise an extensible
LSA; an LSA that contains the necessary elements of any LSA as discussed
in section 4.4.1 of <xref target="RFC5340"></xref>, a destination
address, and a set of options. This document describes extensible
inter-area-prefix-LSAs, intra-area-prefix-LSAs, and AS-external-LSAs.
Additional options are defined in other documents.</t>
<t>Existing OSPF LSAs that specify only a destination prefix may be
understood as identifying a destination prefix and "any" other option,
whether it be source address, flow label, or something else. This is
also a useful class of traffic to compactly represent, so existing LSA
types are not deprecated, merely added to.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="extensions" title="Theory of Routing">
<t>Both IS-IS and OSPF perform their calculations by building a routes
from the router performing the calculation to each router, and then use
those routes to get to destinations that those routes advertise
connectivity to. Following the SPF algorithm, calculation starts by
selecting a starting point (typically the router doing the calculation),
and successively adding {link, router) pairs until one has calculated a
route to every router in the network. As each router is added, including
the original router, destinations that it is directly connected to are
turned into routes in the route table: "to get to 2001:db8::/32, route
traffic to {interface, list of next hop routers}". For immediate
neighbors to the originating router, of course, there is no next hop
router; traffic is handled locally.</t>
<section title="Dealing with ambiguity">
<t>In any routing protocol, there is the possibility of ambiguity. An
area border router might, for example, summarize the routes to other
areas into a small set of relatively short prefixes, which have more
specific routes within the area. Traditionally, we have dealt with
that using a "longest match first" rule. If the same datagram matches
more than one destination prefix advertised within the area, we follow
the route to the longest matching prefix.</t>
<t>When routing a class of traffic, we follow an analogous "most
specific match" rule; we follow the route for the most specific
matching tuple. In cases of simple overlap, such as routing to
2001:db8::/32 or 2001:db8:1::/48, that is exactly analogous; we choose
one of the two routes.</t>
<t>It is possible, however, to construct an ambiguous case in which
neither class subsumes the other. For example, presume that <list
style="symbols">
<t>A is a prefix,</t>
<t>B is a more-specific prefix within A,</t>
<t>C is a different prefix, and</t>
<t>D is a more-specific prefix of C.</t>
</list></t>
<t>The two classes {A, D, *, *} and {B, C, *, *} are ambiguous: a
datagram within {B, D, *, *} matches both classes, and it is not clear
in the data plane what decision to make. Solving this requires the
addition of a third route in the FIB corresponding to the class {B, D,
*, *}, which is more-specific than either of the first two, and can be
given routing guidance based on metrics or other policy in the usual
way.</t>
</section>
</section>
<section title="Extensions necessary for OSPFv3">
<t>Changing OSPF to provide for this type of change requires cloning
many of the existing LSAs: the inter-area-prefix-LSAs, the
AS-external-LSAs, and the intra-area-prefix LSA. This can be done
specifically with the information we have thought about, or designed for
extensibility. We choose extensibility.</t>
<section anchor="ospf-extensions" title="OSPF optional data extensions">
<t>This section defines a number of optional type-length-value (TLV)
information elements that may be included in an extensible LSA. In an
extensible LSA, elements not included are not considered in
classification and as a result are in effect wild-carded.</t>
<section anchor="OSPFv3-IPv6-Destination"
title="IPv6 Destination Prefix TLV">
<t>The IPv6 Destination Prefix TLV MAY be used with the IPv6 Source
Prefix TLV, but MUST NOT be used with the IPv4 Source Prefix TLV or
the IPv4 Destination Prefix TLV.</t>
<?rfc needLines="6"?>
<figure title="Destination Prefix TLV">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Prefix Length | Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Destination Prefix Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the TLV in octets</t>
<t hangText="Prefix Length:">Length of the prefix in bits, in
the range 0..128</t>
<t hangText="Prefix:">(Destination prefix length +7)/8 octets of
prefix</t>
</list></t>
</section>
<section anchor="OSPFv3-ipv6-forwarding-TLV"
title="IPv6 Forwarding Address TLV">
<t>The IPv6 Forwarding Address TLV is only used in the
Extensible-AS-external-LSA, and is optional.</t>
<?rfc needLines="8"?>
<figure title="IPv6 Forwarding Address TLV">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | 128 bit IPv6 Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Flow Label Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the TLV in octets</t>
<t hangText="IPv6 Address:">A fully qualified IPv6 address (128
bits). If included, data traffic for the advertised destination
will be forwarded to this address. It MUST NOT be set to the
IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an IPv6 Link-Local
Address (Prefix FE80/10). While OSPFv3 routes are normally
installed with link-local addresses, an OSPFv3 implementation
advertising a forwarding address MUST advertise a global IPv6
address. This global IPv6 address may be the next-hop gateway
for an external prefix or may be obtained through some other
method (e.g., configuration).</t>
</list></t>
</section>
<section anchor="OSPFv3-referenced-router"
title="Referenced Advertising Router TLV">
<?rfc needLines="9"?>
<figure title="Referenced Advertising Router TLV">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Referenced Advertising Router
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Flow Label Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the TLV in octets</t>
<t hangText="Referenced Link State ID:">With the Referenced Link
State ID TLV (Referenced LS Type and Referenced Link State ID),
Identifies the router-LSA or network-LSA with which the IPv6
traffic classes should be associated. If Referenced LS Type is
0x2001, the prefixes are associated with a router-LSA,
Referenced Link State ID should be 0, and Referenced Advertising
Router should be the originating router's Router ID. If
Referenced LS Type is 0x2002, the prefixes are associated with a
network-LSA, Referenced Link State ID should be the Interface ID
of the link's Designated Router, and Referenced Advertising
Router should be the Designated Router's Router ID.</t>
</list></t>
</section>
<section anchor="OSPFv3-metric" title="Metric TLV">
<?rfc needLines="9"?>
<figure title="Metric TLV">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixOptions | Information elements for the traffic class
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Flow Label Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the TLV in octets</t>
<t hangText="Metric:">The cost of this traffic class. Expressed
in the same units as the interface costs in router-LSAs.</t>
<t hangText="Information Elements">This information element will
be followed by zero or more information elements that describe
the traffic class. the traffic class will have been fully
described when parsing reaches the end of the LSA or finds a new
Metric TLV.</t>
</list></t>
</section>
<section anchor="OSPFv3-route-tag" title="External Route Tag TLV">
<t>The External Route Tag TLV is only used in the
Extensible-AS-external-LSA, and is optional.</t>
<?rfc needLines="8"?>
<figure title="External Route Tag TLV">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | External Route Tag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Flow Label Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the TLV in octets</t>
<t hangText="Route Tag:">A 32-bit field that MAY be used to
communicate additional information between AS boundary
routers.</t>
</list></t>
</section>
<section anchor="OSPFv3-referenced-lsid"
title="Referenced Link State ID TLV">
<?rfc needLines="9"?>
<figure title="Referenced Link State ID TLV">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Flow Label Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the TLV in octets</t>
<t hangText="Referenced LS Type:">The LSType of the associate
LSA.</t>
<t hangText="Referenced Link State ID:">If included, additional
information concerning the advertised external route can be
found in the LSA having LS type equal to "Referenced LS Type",
Link State ID equal to "Referenced Link State ID", and
Advertising Router the same as that specified in the
Extensible-AS-external-LSA's link-state header. This additional
information is not used by the OSPF protocol itself. It may be
used to communicate information between AS boundary routers. The
precise nature of such information is outside the scope of this
specification.</t>
</list></t>
</section>
</section>
<section title="OSPF extensible LSAs">
<t>This section defines the extensible
Extensible-Inter-Area-Prefix-LSA, Extensible-AS-external-LSA, and
Extensible-Intra-Area-Prefix LSA.</t>
<section anchor="ospf-Inter-area-prefix-LSA"
title="Extensible-Inter-area-prefix-LSA">
<t>Extensible-Inter-area-prefix-LSAs have LS type equal to [IANA?].
These LSAs are equivalent to OSPFv2's type 3 summary-LSAs (see
Section 12.4.3 of <xref target="RFC2328"></xref>). Originated by
area border routers, they describe IPv4 or IPv6 traffic classes that
belong to other areas, and are encoded using the TLVs defined in
<xref target="ospf-extensions"></xref>. A separate
inter-area-prefix-LSA is originated for each such traffic class. For
details concerning the construction of inter-area- prefix-LSAs, see
<xref target="RFC5340"></xref> Section 4.4.3.4.</t>
<t>For stub areas, inter-area-prefix-LSAs can also be used to
describe a (per-area) default route. Default summary routes are used
in stub areas instead of flooding a complete set of external routes.
When describing a default summary route, the
Extensible-inter-area-prefix-LSA omits the Destination Prefix
information element, which has the same effect as matching 0.0.0.0/0
or ::/0.</t>
<?rfc needLines="20" ?>
<figure anchor="ospf-Inter-area-prefix-LSA-layout"
title="Extensible-Inter-area-prefix-LSA">
<artwork align="center"><![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| LS-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more Information Element TLVs
+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="LS-Type:">To be assigned by IANA</t>
<t hangText="Metric:">The cost of this route. Expressed in the
same units as the interface costs in router-LSAs. When the
Extensible-inter-area-prefix-LSA is describing a route to a
range of addresses (see <xref target="RFC5340"></xref> Appendix
C.2), the cost is set to the maximum cost to any reachable
component of the address range.</t>
</list></t>
</section>
<section anchor="ospf-AS-external-LSA"
title="Extensible-AS-external-LSA">
<t>This is an AS-external-LSAs, but may include other information
elements. Unlike the AS-external-LSAs, however, the presence of
optional information is determined by the presence of the
information elements, not by flags.</t>
<?rfc needLines="20" ?>
<figure anchor="ospf-AS-external-LSA-layout"
title="Extensible-AS-external-LSA">
<artwork align="center"><![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|1|0| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |E|0 0| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One or more Information Element TLVs
+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="E:">The type of external metric. If bit E is set,
the metric specified is a Type 2 external metric. This means the
metric is considered larger than any intra-AS path. If bit E is
zero, the specified metric is a Type 1 external metric. This
means that it is expressed in the same units as other LSAs
(i.e., the same units as the interface costs in
router-LSAs).</t>
<t hangText="Metric:"></t>
<t hangText=":">The cost of this route. Interpretation depends
on the external type indication (bit E above).</t>
</list></t>
</section>
<section anchor="ospf-Intra-Area-Prefix-LSA"
title="Extensible-Intra-Area-Prefix-LSA">
<t>This LSA MUST include a Referenced Link State ID TLV and a
Referenced Advertising Router TLV immediately following the number
of traffic classes. It MUST also include the indicated number of
Metric TLVs, each of which is followed by the information elements
that define that class of traffic, which will usually include a
Destination Prefix TLV and may include a source prefix TLV, Flow
Label TLV, or DSCP TLV.</t>
<t>Extensible-Intra-area-prefix-LSAs have LS types assigned by IANA.
A router uses Extensible-intra-area-prefix-LSAs to advertise one or
more traffic classes that are associated with a local router
address, an attached stub network segment, or an attached transit
network segment. In IPv4, the first two were accomplished via the
router's router-LSA and the last via a network-LSA. In OSPF for
IPv6, all addressing information that was advertised in router-LSAs
and network-LSAs has been removed and is now advertised in
intra-area-prefix-LSAs. For details concerning the construction of
intra-area-prefix-LSA, see <xref target="RFC5340"></xref> Section
4.4.3.9.</t>
<t>A router can originate multiple extensible-intra-area-prefix-LSAs
for each router or transit network. Each such LSA is distinguished
by its unique Link State ID.</t>
<?rfc needLines="20" ?>
<figure anchor="ospf-Intra-Area-Prefix-LSA-layout"
title="Extensible-Intra-Area-Prefix-LSA">
<artwork align="center"><![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| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Traffic Classes | Information Elements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="# Traffic Classes:">The number of traffic classes
that will be specified. Each traffic class has, first, a metric
TLV, and then one or more other TLVs, normally including a
Destination Prefix TLV.</t>
</list></t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section will request LSID values for the LSAs defined, plus
define a registry for optional fields. This is deferred to the -01
version of the draft.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To be considered.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>To be considered.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">February 2013</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.ISO.10589.1992" ?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2328" ?>
<?rfc include="reference.RFC.5340" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4915" ?>
<reference anchor="PATRICIA">
<front>
<title>Practical Algorithm to Retrieve Information Coded in
Alphanumeric</title>
<author fullname="D.R. Morrison" initials="D.R." surname="Morrison">
<organization>Association for Computing Machinery</organization>
</author>
<date month="October" year="1968" />
</front>
<seriesInfo name="Journal of the ACM" value="15(4) pp514-534" />
<format target="http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/PATRICIA/"
type="HTML" />
</reference>
</references>
<section title="FIB Design">
<t>While the design of the Forwarding Information Base is not a matter
for standardization, as it only has to work correctly, not interoperate
with something else, the design of a FIB for this type of lookup may
differ from approaches used in destination routing. We describe one
possible approach that is known to work, from the perspective of a proof
of concept.</t>
<section title="Linux Source-Address Forwarding">
<t>The University of Waikato has added to the Linux Advanced Routing
& Traffic Control facility the ability to maintain multiple FIBS,
one for each of a set of prefixes. Implementing source/destination
routing using this mechanism is not difficult.</t>
<t>The router must know what source prefixes might be used in its
domain. This may be by configuration or, at least in concept, learned
from the routing protocols themselves. In whichever way that is done,
one can imagine two fundamental FIB structures to serve N source
prefixes; N FIBs, one per prefix, or N+1 FIBs, one per prefix plus one
for destinations for which the source prefix is unspecified.</t>
<section title="One FIB per source prefix">
<t>In an implementation with one FIB per source prefix, the routing
algorithm has two possibilities. <list style="symbols">
<t>If it calculates a route to a prefix (such as a default
route) associated with a given source prefix, it stores the
route in the FIB for the relevant source prefix.</t>
<t>If it calculates a route for which the source prefix is
unspecified, it stores that route in all N FIBs.</t>
</list></t>
<t>When forwarding a datagram, the IP forwarder looks at the source
address of the datagram to determine which FIB it should use. If it
is from an address for which there is no FIB, the forwarder discards
the datagram as containing a forged source address. If it is from an
address within one of the relevant prefixes, it looks up the
destination in the indicated FIB and forwards it in the usual
way.</t>
<t>The argument for this approach is simplicity: there is one place
to look in making a forwarding decision for any given datagram. The
argument against it is memory space; it is likely that the FIBs will
be similar, but every destination route not associated with a source
prefix is duplicated in each FIB. In addition, since it
automatically removes traffic whose source address is not among the
configured list, it limits the possibility of user software using
improper addresses.</t>
</section>
<section title="One FIB per source prefix plus a general FIB">
<t>In an implementation with N+1 FIBs, the algorithm is slightly
more complex. <list style="symbols">
<t>If it calculates a route to a prefix (such as a default
route) associated with a given source prefix, it stores the
route in the FIB for the relevant source prefix.</t>
<t>If it calculates a route for which the source prefix is
unspecified, it stores that route in the FIB that is not
associated with a source prefix.</t>
</list></t>
<t>When forwarding a datagram, the IP forwarder looks at the source
address of the datagram to determine which FIB it should use. If it
is from one of the configured prefixes, it looks the destination up
in the indicated FIB. In any event it also looks the destination up
in the "unspecified source address" FIB. If the destination is found
in only one of the two, the indicated route is followed. If the
destination is found in both, the more specific route is
followed.</t>
<t>The argument for this approach is memory space; if a large
percentage of routes are only in the general FIB, such as when
egress routing is used for the default route and all other routes
are internal, the other FIBs are likely to be very small - perhaps
only a single default route. The argument against this approach is
complexity: most lookups if not all will be done in a
prefix-specific FIB and in the general FIB.</t>
</section>
</section>
<section title="PATRICIA">
<t>One approach is a <xref target="PATRICIA"></xref> Tree. This is a
relative of a Trie, but unlike a Trie, need not use every bit in
classification, and does not need the bits used to be contiguous. It
depends on treating the bit string as a set of slices of some size,
potentially of different sizes. Slice width is an implementation
detail; since the algorithm is most easily described using a slice of
a single bit, that will be presumed in this description.</t>
<section title="Virtual Bit String">
<t>It is quite possible to view the fields in a datagram header
incorporated into the classification tuple as a virtual bit string
such as is shown in <xref target="conceptual"></xref>. This bit
string has various regions within it. Some vary and are therefore
useful in a radix tree lookup. Some may be essentially constant -
all global IPv6 addresses at this writing are within 2000::/3, for
example, so while it must be tested to assure a match, incorporating
it into the radix tree may not be very helpful in classification.
Others are ignored; if the destination is a remote /64, we really
don't care what the EID is. In addition, due to variation in prefix
length and other details, the widths of those fields vary among
themselves. The algorithm the FIB implements, therefore, must
efficiently deal with the fact of a discontiguous lookup key.</t>
<figure anchor="conceptual"
title="Treating a traffic class as a virtual bit string">
<artwork align="center"><![CDATA[
+---------------------+----------------------+-----+-----------+
|Destination Prefix |Source Prefix |DSCP | Flow Label|
+------+------+-------+------+-------+-------+-----+-----------+
Common|Varying|Ignored|Common|Varying|Ignored|Varying or ignored
]]></artwork>
</figure>
</section>
<section title="Tree Construction">
<t>The tree is constructed by recursive slice-wise decomposition. At
each stage, the input is a set of classes to be classified. At each
stage, the result is the addition of a lookup node in the tree that
identifies the location of its slice in the virtual bit string
(which might be a bit number), the width of the slice to be
inspected, and an enumerated set of results. Each result is a
similar set of classes, and is analyzed in a similar manner.</t>
<t>The analysis is performed by enumerating which bits that have not
already been considered are best suited to classification. For a
slice of N bits, one wants to select a slide that most evenly
divides the set of classes into 2^N subsets. If one or more bits in
the slice is ignored in some of the classes, those classes must be
included in every subset, as the actual classification of them will
depend on other bits.</t>
<figure anchor="patricia-tree" title="Example PATRICIA Tree">
<artwork align="center"><![CDATA[
Input:{2001:db8::/32, ::/0, *, *}
{2001:db8:1::/48, ::/0, AF41, *}
{2001:db8:1::/48, ::/0, AF42, *}
{2001:db8:1::/48, ::/0, AF43, *}
Common parts: Destination prefix 2001:dba, source prefix, and label
Varying parts: DSCP and the third set of sixteen bits in the
destination prefix
One possible decomposition:
(1) slice = DSCP
enumerated cases:
(a) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF41, *} }
(b) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF42, *} }
(c) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF43, *} }
(2) slice = third sixteen bit field in destination
This divides each enumerated case into those containing 0001 and
"everything else", which would imply 2001:db8::/32
(1) DSCP
--------------------------
(1a) (1b) (1c)
/ \ / \ / \
/32 /48 /32 /48 /32 /48
]]></artwork>
</figure>
</section>
<section title="Tree Lookup">
<t>To look something up in a PATRICIA Tree, one starts at the root
of the tree and performs the indicated comparisons recursively
walking down the tree until one reaches a terminal node. When the
enumerated subset is empty or contains only a single class,
classification stops. Either classification has failed (there was no
matching class, or one has presumably found the indicated class. At
that point, every bit in the virtual bit string must be compared to
the classifier; classification is accepted on a perfect match.</t>
<t>In the example in <xref target="patricia-tree"></xref>, if a
packet {2001:db8:1:2:3:4:5:6, 2001:db8:2:3:4:5:6:7, AF41, 0}
arrives, we start at the root. Since it is an AF41 packet, we deduce
that case (1a) applies, and since the destination has 0001 in the
third sixteen bit field of the destination address, we are comparing
to {2001:db8:1::/48, ::/0, AF41, *}. Since the destination address
is within 2001:db8:1::/48, classification as that succeeds.</t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:36:15 |