One document matched: draft-boutier-babel-source-specific-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<rfc category="exp" docName="draft-boutier-babel-source-specific-00"
ipr="trust200902" updates="6126">
<front>
<title>Source-Specific Routing in Babel</title>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier">
<organization>PPS, University of Paris-Diderot</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>boutier@pps.univ-paris-diderot.fr</email>
</address>
</author>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>PPS, University of Paris-Diderot</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>jch@pps.univ-paris-diderot.fr</email>
</address>
</author>

<date day="20" month="November" year="2014"/>

<abstract>
<t>This document describes extensions to the Babel routing protocol to
support source-specific routing.</t>
</abstract>

</front>

<middle>

<section title="Introduction and background">

<t>Source-specific routing is an extension to traditional next-hop where
packets are routed according to both their destination and their source
address.  This document describes extensions to the Babel routing protocol
<xref target="BABEL"/> to support source-specific routing.</t>

<t>Background information about source-specific routing is provided in
<xref target="SS-ROUTING"/>.</t>

</section>

<section title="Data Structures">

<t>This extension adds some data to the data structures maintained by
a Babel node.</t>

<section title="The Source Table">

<t>Every Babel node maintains a source table, as described in <xref
target="BABEL"/>, Section 3.2.4.  A source-specific Babel node extends
this table with the following field:
<list style="symbols">
<t>the source prefix (sprefix, splen) specifying the source of packets to
which this entry applies.</t>
</list>
If splen is 0, then this is a non-specific entry, and is treated just
like a source table entry defined by the original Babel protocol.</t>

<t>With this extension the route entry contains a source which itself
contains a source prefix.  Notwithstanding the accidental similarity in
their names, these are two very different concepts, and should not be
confused.</t>

</section>

<section title="The Route Table">

<t>Every Babel node maintains a route table, as described in <xref
target="BABEL"/>, Section 3.2.5.  With this extension, this table is
indexed by the 5-tuple (prefix, plen, source prefix, source plen,
router-id) obtained from the associated source table entry.</t>

</section>

<section title="The Table of Pending Requests">

<t>Every Babel node maintains a table of pending requests, as described
in <xref target="BABEL"/>, Section 3.2.6.  A source-specific Babel node
extends this table with the following entry:
<list style="symbols">
<t>the source prefix being requested.</t>
</list></t>

</section>

</section>

<section title="Data Forwarding">

<t>In next-hop routing, if two routing table entries overlap, then one is
necessarily more specific than the other; the "longest prefix rule"
specifies that the most specific applicable routing table entry is chosen.</t>

<t>With source-specific routing, there might no longer be a most specific
applicable prefix: two routing table entries might match a given packet
without one necessarily being more specific than the other.  Consider for
example the following fragment of a routing table:</t>
<t><list style="empty">
<t>(2001:DB8:0:1::/64, ::/0, A)</t>
<t>(::/0, 2001:DB8:0:2::/64, B)</t>
</list></t>
<t>This specifies that all packets with destination in 2001:DB8:0:1::/64
are to be routed through A, while packets with a source in
2001:DB8:0:2::/64 are to be routed through B.  A packet with source
2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules,
although neither is more specific than the other.  A choice is necessary,
and unless the choice being made is the same on all routers in a routing
domain, persistent routing loops may occur.</t>

<t>A Babel implementation MUST choose routing table entries by using the
so-called destination-first ordering, where a routing table entry R1 is
preferred to a routing table entry R2 when either R1's destination prefix
is more specific than R2's, or the destination prefixes are equal and
R1's source prefix is more specific than R2's.  (In more formal terms,
routing table entries are compared using the lexicographic product of the
destination prefix ordering by the source prefix ordering.)</t>

<t>In practice, this means that a source-specific Babel implementation
must take care that any lower layers that perform packet forwarding obey
this semantics.  In particular:
<list style="symbols">
<t>If the lower layers implement the destination-first ordering, then the
Babel implementation MAY use them directly;</t>
<t>If the lower layers can hold source-specific routes, but not with the
right semantics, then the Babel implementation MUST disambiguate the
routing table by using a suitable disambiguation algorithm (see <xref
target="SS-ROUTING"/> for such an algorithm).</t>
<t>If the lower layers cannot hold source-specific routes, then a Babel
implementation SHOULD silently ignore any source-specific routes and MUST
NOT reannounce them to other nodes.</t>
</list>
</t>

</section>

<section title="Protocol Operation">

<t>This extension does not fundamentally change the operation of the Babel
protocol.</t>

<section title="Sending updates">

<t>This extension introduces a new kind of update, the source-specific
update.  Whenever a source-specific Babel node needs to send an update,
it checks whether the update is for a source-specific route (a route with
a source prefix of non-zero length); if that is the case, it sends
a source-specific update (<xref target="ss-update"/>), and otherwise it
sends a non-specific update (<xref target="BABEL"/>, Section 4.4.9).</t>

<t>Every Babel node maintains a source table, which it updates whenever it
sends an Update (<xref target="BABEL"/>, Section 3.7.3).
A source-specific Babel node extends this procedure by updating the
source table not only when it sends an update, but also when it sends
a source-specific update.</t>

</section>

<section title="Requests">

<t>This extension duplicates Babel's two request types: there are now two
kinds of route requests (source-specific and unspecific), and, similarly,
two kinds of seqno requests.</t>

<t>This extension does not modify Babel's strategy for sending requests.
Whenever a Babel node needs to send a request, it checks whether the
request is for a source-specific route; if it is, it should send one of
the request types defined in this document; if it is not, then it should
send one of the request types defined in the original Babel
specification.</t>

<section title="Wildcard requests">

<t>The Babel protocol provides the ability to request a full routing table
dump by sending a "wildcard request", a route request with the AE field
set to 0.  This extension does not modify the semantics of wildcard
requests: a wildcard request prompts a dump of non-specific routes only,
and a Babel node SHOULD NOT send any source-specific updates in reply to
a wildcard request.</t>

<t>A different request is used for obtaining a dump of the source-specific
routes in a node's routing table.  A "source-specific wildcard request" is
a source-specific request (<xref target="ss-request"/>) whose AE field is
0; it requests a dump of the receiving nodes source-specific routes only
(routes with a source prefix length of 1 or more).  A node SHOULD NOT send
any non-specific updates in reply to a source-specific wildcard
request.</t>

<t>In consequence, a node requiring a full routing table dump SHOULD send
both a non-specific wildcard request and a source-specific wildcard
request.</t>

</section>

</section>

</section>

<section title="Protocol Encoding">

<t>This extension defines three new TLV types that are used by
Source-Specific Babel nodes and silently ignored by ordinary Babel
nodes, in accordance with <xref target="BABEL-EXT"/>.</t>

<section title="Source-Specific Update" anchor="ss-update">
<figure><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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 13   |    Length     |      AE       |  Source Plen  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Plen     |    Omitted    |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |             Metric            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
|        Source prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>Fields:
<list style="hanging" hangIndent="10">
<t hangText="Type">Set to 13 to indicate a source-specific update TLV.</t>
<t hangText="Length">The length of the body, exclusive of the Type and
Length fields.</t>
<t hangText="AE">The encoding of the prefix field.</t>
<t hangText="Source Plen">The length of the advertised source prefix.
This MUST NOT be 0.</t>
<t hangText="Plen">The length of the advertised destination prefix.</t>
<t hangText="Omitted">The number of octets that have been omitted at the
beginning of the advertised prefix and that should be taken from
a preceding Update TLV with the flag with value 80 hexadecimal set.</t>
<t hangText="Interval">An upper bound, expressed in centiseconds, on the
time after which the sending node will send a new update for this prefix.
This MUST NOT be 0 and SHOULD NOT be less than 10.  The receiving node
will use this value to compute a hold time for this routing table entry.
The value FFFF hexadecimal (infinity) expresses that this announcement
will not be repeated unless a request is received.</t>
<t hangText="Seqno">The originator's sequence number for this update.</t>
<t hangText="Metric">The sender's metric for this route.  The value FFFF
hexadecimal (infinity) means that this is a route retraction.</t>
<t hangText="Prefix">The destination prefix being advertised.  This
field's size is (Plen/8 - Omitted) rounded upwards.</t>
<t hangText="Source Prefix">The source prefix being advertised.  This
field's size is (Source Plen)/8 rounded upwards.</t>
</list>
</t>

</section>

<section title="Source-Specific Request" anchor="ss-request">

<figure><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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 14   |    Length     |      AE       |      Plen     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Source Plen  |        Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|        Source prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>Fields:
<list style="hanging" hangIndent="10">
<t hangText="Type">Set to 14 to indicate a Source-Specific Route Request
TLV.</t>
<t hangText="Length">The length of the body, exclusive of the Type and
Length fields.</t>
<t hangText="AE">The encoding of the prefix field.  The value 0 (wildcard)
requests a full dump of all the source-specific routes of the receving
node (i.e. those with non-zero source prefix length).</t>
<t hangText="Plen">The length of the requested destination prefix.</t>
<t hangText="Source Plen">The length of the requested source prefix.
This MUST NOT be 0, except for AE 0.</t>
<t hangText="Prefix">The destination prefix being requested.  This field's
size is Plen/8 rounded upwards.</t>
<t hangText="Source Prefix">The source prefix being advertised.  This
field's size is (Source Plen)/8 rounded upwards.</t>
</list></t>

</section>

<section title="Source-Specific Seqno Request">

<figure><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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 15   |    Length     |      AE       |      Plen     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |   Hop Count   |  Source Plen  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Router-Id                           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
|        Source prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>Fields:
<list style="hanging" hangIndent="10">
<t hangText="Type">Set to 15 to indicate a Source-Specific Seqno Request
TLV.</t>
<t hangText="Length">The length of the body, exclusive of the Type and Length fields.</t>
<t hangText="AE">The encoding of the prefix field.  This MUST NOT be 0.</t>
<t hangText="Plen">The length of the requested destination prefix.</t>
<t hangText="Seqno">The sequence number that is being requested.</t>
<t hangText="Hop Count">The maximum number of times that this TLV may be
forwarded, plus 1.  This MUST NOT be 0.</t>
<t hangText="Source Plen">The length of the requested source prefix.
This MUST NOT be 0.</t>
<t hangText="Router-Id">The Router-ID associated to this route.</t>
<t hangText="Prefix">The destination prefix being requested.  This field's
size is Plen/8 rounded upwards.</t>
<t hangText="Source Prefix">The source prefix being advertised.  This
field's size is "Source Plen"/8 rounded upwards.
</t>
</list>
</t>

<t>A Source-Specific Seqno Request TLV prompts the receiving node to
send an Update for the route specified by the AE, Plen, Prefix, Source
Plen and Source Prefix fields, with either a router-id different from
what is specified by the Router-Id field, or a Seqno no less than what
is specified by the Seqno field.  If this request cannot be satisfied
locally, then it is forwarded according to the rules set out in Section
3.8.1.2 of <xref target="BABEL"/>.</t>
<t>Just like an ordinary Seqno Request, a Source-Specific Seqno Request
MAY be sent to a multicast address but MUST NOT be forwarded to
a multicast address and MUST NOT be forwarded to more than one neighbour.
A Source-Specific Seqno Request MUST NOT be forwarded if its Hop Count
field is 1.</t>

</section>

</section>

<section title="IANA Considerations">
<t>This document defines three new Babel TLV types:
<list style="hanging" hangIndent="10">
<t hangText="13 - Source-Specific Update"></t>
<t hangText="14 - Source-Specific Request"></t>
<t hangText="15 - Source-Specific Seqno Request"></t>
</list></t>

</section>

<section title="Security considerations">
<t>By itself, the Babel routing protocol is not a secure protocol; this
extension doesn't change that fact.  Babel can be made secure by using
a suitable cryptographic layer, such as the one described in
<xref target="RFC7298"/>.</t>
</section>

</middle>

<back>

<references>

<reference anchor="BABEL"><front>
<title>The Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="February" year="2011"/>
</front>
<seriesInfo name="RFC" value="6126"/>
</reference>

<reference anchor="BABEL-EXT"><front>
<title>Extension Mechanism for the Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="June" year="2013"/>
</front>
<seriesInfo name="Internet Draft" value="draft-chroboczek-babel-extension-mechanism-00"/>
</reference>

<reference anchor='RFC7298'>

<front>
<title>Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication</title>
<author initials='D.' surname='Ovsienko' fullname='D. Ovsienko'/>
<date year='2014' month='July' />
</front>
<seriesInfo name='RFC' value='7298' />
<format type='TXT' octets='128503' target='http://www.rfc-editor.org/rfc/rfc7298.txt' />
</reference>

<reference anchor="SS-ROUTING">
<front>
<title>Source-sensitive routing</title>
<author initials="M." surname="Boutier" fullname="Matthieu Boutier"/>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek"/>
<date year="2014" month="August"/>
</front>
</reference>

</references>

</back>

</rfc>