[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Short explanation: Ivip6's "Core Routing Label Forwarding"
- To: Routing Research Group <email@example.com>, Iljitsch van Beijnum <firstname.lastname@example.org>
- Subject: [RRG] Short explanation: Ivip6's "Core Routing Label Forwarding"
- From: Robin Whittle <email@example.com>
- Date: Mon, 04 Aug 2008 22:17:06 +1000
- Organization: First Principles
- User-agent: Thunderbird 220.127.116.11 (Windows/20080708)
Thanks for making it to the 50kB mark! Regarding your complaint and
The explanation was long because I figure not everyone knows the
Ivip approach to ITRs, Mapped Address Blocks etc. These are
important - for instance that Ivip ITRs are simple, tunneling
packets to only one ETR, doing no ETR reachability testing etc.
If I was writing just for you, message would have been a third the
length. I could explain this to you face-to-face in 2 or 3 minutes.
I am working on a better explanation, to appear here ASAP:
Using terminology which is in accordance with that new explanation,
here is a brief response to:
> your solution is basically a subset/optimization of MPLS.
Ivip6's "Core Routing Label Forwarding" (or "Core Routing Label
Tunneling"?) technique is unrelated to MPLS:
There is no additional header.
The label has the same value for the whole journey.
There is no state to be set up in the routers.
There is no predefined path.
There is no QoS.
"Core Routing Label Forwarding" could be used for other purposes,
but an Ivip6 ITR uses this technique without any pre-arrangement, to
get the otherwise unmodified traffic packet safely across the core
to the border router of a provider network in which an ETR function
delivers the packet to the destination network.
This is achieved without the ETR address being in the packet at all
- only the 20 bits which directly identifies the prefix of the
destination provider network.
> Earlier, requiring MPLS was categorized as a non-starter. Not sure
> if I agree with that, MPLS implementations are widely available
> and running MPLS without too much overhead in the form of
> signaling protocols seems like a fair tradeoff to gain routing
> scalability to me.
There is no overhead or signalling protocol with this technique.
Let's assume we use all 20 bits of the old Flow Label as a Routing
Label (which is what I will refer to as below), to have significance
only in core routers.
(We don't need a million label values, so I am developing the
proposal to use half of these for this Ivip6 "ITR --> ETR via
the core" purpose - with the other half reserved for private
use however people like in their own networks).
All of the new kind of end-user networks connect to the Net via
providers whose sites have a "Core Egress Prefix" (CEP). For
example, these are 2^20 contiguous /32 prefixes in E00::/12:
CEP-0 E000:0000::/32 (Not used)
and the highest is:
Micronets are the more flexibly defined Ivip to a LISP EID prefix.
They are in units of /64 and can be any number (to 2^32) of /64s in
length. (Mapping granularity = /64.)
All the "end user networks" I discuss here are of the new kind,
using Ivip6-managed micronet address space.
The "recipient provider network" is the network which contains the
ETR function (tunnel endpoint) for the packet being forwarded from
an ITR to an end-user network.
In this example, the sending host emits a packet addressed to a host
in a particular micronet, and the mapping of that micronet is to
some 128 bit "ETR" address, in this example:
This packet reaches an ITR, which for simplicity of explanation is a
border network of some provider network A. It looks up the mapping
- or already has it cached. (Ivip lookups are to local query
servers, so this the delay is insignificant.)
In Ivip4, the mapping system provides the full 32 bit address of the
ETR. In Ivip6, it only provides 20 bits of the full address of the
"ETR". In this example, the mapping is to:
0 0003 (bits 115 to 96 of the "ETR" address)
The ITR writes these 20 bits into the Routing Label and then
performs the following operation on it, which is the same as is
performed by all core routers, up to the border router of the
recipient provider network.
This operation involves the first upgrade to BGP core routers, in
this case to the FIB. There are no changes to the BGP
implementation or to the way these routers communicate with BGP peers.
The core router's FIB receives the packet and because it has a
non-zero Routing Label, it takes no notice of the destination
Instead, it takes the 20 bit value of the Routing Label as an
index to read a value in an array RLFEC. This has 2^20
elements, each already set to the Forwarding Equivalence Class
for the same-numbered CEP prefix.
In our example, the Routing Label is 0 0003, and RLFEC
contains some number which tells the FIB which of the router's
interfaces the packet should be forwarded on.
The router forwards the packet to that interface.
Note there is non rewriting the value of the Routing Label, no state
previously established for this packet or any other such packet.
This is much less expensive then the FIB's usual approach of having
the Tree-Bitmap algorithm chew through the destination address, for
up to 48 bits, until it matches it to a prefix for which it knows
These CEP prefixes are ordinary BGP prefixes - with one exception:
it is verboten to advertise more specifics within them. They must be
advertised as /32s.
Every micronet must be mapped to an address which fits within one of
the currently advertised CEP prefixes. We won't need a million of
them, but for now this example assumes there could be 2^20 of them.
CEP-0 is not used.
The BGP implementation of all core routers does as usual for these
prefixes - it figures out the best path for forwarding packets
addressed to this prefix, and writing the appropriate FEC value into
the relevant part of its FIB.
The second modification to core routers does the following:
The RIB periodically reads through the FEC values of these
2^20 CEP prefixes and copies them sequentially to the RLFEC
array in the FIB.
Q1: What happens when the packet arrives at the border router of the
recipient provider network?
But first let's marvel at the fact that it was transported across
the core, with minimal router effort, no protocol to set up a path
etc. to a border router which advertises a prefix which is unrelated
to the packet's destination address, except by the fact that the
packet's destination micronet is currently mapped to an ETR address
inside this prefix.
A1: If there are multiple ETRs in the recipient provider network,
the recipient border router needs to look up the mapping of the
destination address. The result is the ETR address within that
recipient provider network. (Alert readers will have a Q2 at
Alternatively, there may be no need for an ETR at all. Let's
say the recipient provider network's internal routing system has
a route for the destination end-user's network, which this
packet is addressed to. Then the border router simply zeroes
the Routing Label and forwards the packet according to that
Let us also note:
There is no header overhead.
No MTU problems due to longer packets.
Traceroute works fine for the whole path.
PMTUD works fine for the whole path.
Core router workload is decreased.
Q2: How does the receiving provider network's border router look up
the full "ETR" address in the mapping system, when the mapping
system only provides bits 115 to 96 of that address to the
full database Query Servers, due to this being all that the ITR
needs to know about the "ETR" address?
A2: Good question! In some cases, such as when the provider network
has a business relationship with the end-user network, that
relationship provides the information about which end-user
networks have which pieces of micronet space, and which "ETR"
the packets should be forwarded to in order that the ETR
can forward the packet to the end-user network.
However, in other cases, such as the TTR mobility model, there
is no such relationship and the border router needs to use
the mapping system to find out the full "ETR" address. I am
still working on this.
Q3: What about support for packets from non-upgraded networks?
A3: OITRDs (Open ITRs in the DFZ) advertise MABs (Mapped Address
Blocks) in the DFZ, attracting packets sent to micronet
addresses by hosts in networks without ITRs. All micronets and
therefore MABs are (in this example) in the prefix 4::/3, which
simplifies the operation of OITRDs.
I can anticipate enough questions to write plenty more - but out of
respect for buffers, will sign off now.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg