I didn't say that the tunnel processing can not be done in fast path.
Here is what you could do.

When you create the tunnel, cache the route/nexthop needed to reach the
destination (the tunnel exit point) and create a sudo tunnel header in
advance. Sudo tunnel header can have all the fields in place and the
checksum computed for them. Now when you have all this information, you
could do a route lookup for the destination address of the received
packet in fastpath and if the route returned is the tunnel route, append
the already prepared header and compute the incremental checksum. You
already have the cached nexthop, forward the packet. Update the cached
route/nexthop on route change events.

Hope this helps.

regards
Mukesh

ext aridaman kaushik wrote:

> Hi all,
>    Thanks for the response.
>    I am not getting why tunnelling mechanism should be in slow
> path.
>    If we check intel IXP2400 chip, all tunnelling mechanism has
> been put
>    in fast path.
>    Also, if we consider automatic tunneling, which need to perform
> look
>    up for a ipv4 route. Forwarding table will be in fast path and
> we try
>    to perform route look up for a particular route. How will it
>    work?
>
> regards
> ari.
>
> Hi Ari,
>
> >     I have a doubt regarding ipv6 over ipv4 tunnel.
>
> I think your questions are pretty generic to any IPinIP tunnels.
>
> >1. When a tunnel is configured, source and destination is
> >configured.
> >Is it sufficient to configure destination address only. My
> >means
> >to say why source address is required.
>
> You need to put these source and destination addresses in the
> tunnel
> header of the packet. The source address is required so that the
> router
> at the other end of the tunnel can send the packets back to the
> router
> who tunnelled the packet.
>
> >2. Is it necessary to establish path between source and
> >destination before configuring tunnel and use this path in
> >routing
> >header of tunneled packet for forwarding the packet.
>
> I don't think that's necessary. You could just tunnel the packet
> and
> forward it as a normal IP packet. The tunnelled packet has the
> outer IP
> header (tunnel IP header) which is sufficient to forward the
> packet
> throughout the path.
>
> >3. I have one more doubt, when there is concept of fast path
> >and
> >slow path, which functionality of the tunnelling should go to
> >the
> >fast path and which functionality of tunnelling should go to
> >the
> >slow path.
>
> I think, the tunnel processing (encapsulating the packet in
> another IP
> header) should be done in slow path.
>
> regards
> Mukesh
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to