Subject: [RRG] Ivip6 - Forwarding Label in the Core

From: Robin Whittle <[email-masked]>
Date: Tue, 05 Aug 2008 21:42:25 +1000

I have changed the name of this technique somewhat from "Routing
Label" to "Forwarding Label".

A full explanation is here:

  http://www.firstpr.com.au/ip/ivip/ivip6/

This includes a chart of how the packet is handled by the ITR,
various core routers and the border router at the recipient provider
network:

  http://www.firstpr.com.au/ip/ivip/ivip6/#chart

which most RRG folks will be able to follow easily.

The longer explanation is for people who want more detail - or for
people who are not so up to speed with the RRG discussions and Ivip.

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Robin Whittle <[email-masked]>
Date: Thu, 07 Aug 2008 00:26:44 +1000

I have added a page:

  http://www.firstpr.com.au/ip/ivip/ivip6/lfe/

This considers extending the use of the proposed IPv6 Forwarding
Label (the currently unused Flow Label) to forwarding inside edge
networks.

It also has a section listing the relatively modest upgrades
required to the RIB and FIB of core routers:

  http://www.firstpr.com.au/ip/ivip/ivip6/lfe/#core-new-func

I explore using the lower half of the 2^20 space for 2^19 values
purely for prefixes in the core:

  0 0001 to  7 FFFF  Core - single global namespace.

and the upper half:

  8 0001 to  F FFFF  Edge - separate namespace for each network.

    (It would be possible to use all 20 bits in one way for the
     core and all 20 bits however each edge network likes, purely
     within that edge network.  However I think it is more robust
     to keep the ranges of value separate.)

There may be various uses for it in edge networks, but the most
obvious one I can think of is getting Ivip6 traffic packets from the
border routers of the recipient provider networks through that
network to the ETRs which directly connect to the end-user networks.

So the proposed Forwarding Label is used twice:

  0xxx xxxx xxxx xxxx xxxx  To get the packet from the ITR to the
                            border router of the provider network
                            where the ETR is.

  1yyy yyyy yyyy yyyy yyyy  To get the packet from that border
                            router to the ETR.

This use in the recipient provider network is not required by Ivip6
- but it might be handy in some situations.  It avoids some problems
with alternative approaches to getting the packet from the recipient
border router to the end-user network:

  Tunnel by encapsulation
  to the ETR:                    Packet overhead and PMTUD problems.

  No ETR - make the provider's
  internal routing system
  handle the prefixes of all
  the end-user networks:         Unwieldy - and presents scaling
                                 problems for the internal
                                 routing system.

Also, it is less complex for the FIB of each internal router to
forward packets using the proposed Forwarding Label than to do the
usual classification of the packet by analysing up to 48 bits of the
destination address.

Up to 524,287 provider networks:

   each with up to 524,287 ETRs, (274 billion possible ETRs):

      each able to handle many end-user networks.

That should be sufficient!

In the core, it is OK to have non-upgraded routers - but there can't
be any ITRs or ETRs behind them.

In the edge networks, it is OK to have some non-upgraded routers -
but routes to ETRs (or any outer route which is used by the internal
Label Forwarding system) shouldn't go through them.

 - Robin