Sunday, June 13, 2010

Avoiding double IP reassembly in eNodeB and IPsec Gateway in LTE - Red Side Fragmentation

I have given one use case long time back for Red side fragmentation feature. Please find it here.  There is one more use case where one can avoid double IP reassembly.

In LTE world,  you have eNodeB and SGW (Serving Gateways) communicate using IPsec  over backhaul network.  Ipsec functionality is normally part of eNodeB.  But on the SGW side, IPsec is normally deployed in a separate network element (IPsec Gateway).  Due to this, there could be double IP reassembly in eNodeB. Avoiding reassembly can improve eNodeB performance. This can be achieved by configuring 'Red side fragmentation' on Ipsec GW in core network near SGW. 

Let us step back and see the packet processing.  Any packet between eNodeB and SGW are first tunneled using GTP tunnel.  Then they get tunneled using IPsec to secure the traffic.  Let us all assume that MTU of all the links is 1500. It is not a bad assumption at all as interfaces of these network elements in many deployments are Ethernet interfaces.  Let us also assume that 1500 byte packet is being sent out from SGW to eNodeb (downlink packet).  GTP in the SGW adds GTP/UDP/IP header to the packet.  Since MTU of transmitting interface is 1500, this packet would be broken down into two - one packet with 1500 bytes and another packet with rest of data.  Now this packet goes to the IPsec gateway .  IPsec adds ESP/IP header to the first 1500 byte fragment and second fragment.  First fragment after Ipsec is done exceeds the MTU and it gets fragmented.  So, there are now total three packets for the original 1500 byte packet.  eNodeB upon receiving the packets, first needs to reassemble the fragments for Ipsec inbound processing consumption.  For GTP-U consumption, it needs to reassemble the fragments which went through the Ipsec inbound processing.

How do we avoid the double reassembly?  I can think of three options.

  • Combine GTP and Ipsec in the same network elements. Packets will get fragmented only after GTP and Ipsec outbound processing is done.  Hence only two fragments would be generated and peer only needs to do only one reassembly.  Note that this option may not be possible on SGW side due to scalability reasons.  GTP and IPsec are always  together in case of eNodeB though.
  • Configure IPsec gateway to do reassembly before it does IPsec outbound processing:  Here GTP-U might have broken the packet into two. Ipsec gateway reassembles them and passes the reassembled packet to the IPsec outbound processing.  Ipsec gateway after outbound processing would fragment the packet if necessary.  Peer (eNodeB) will only see two fragments and only one reassembly is required. But note that this would have overheads in Ipsec gateway. This may be okay as ipsec gateway is normally deployed as separate element and the CPU might be entirely dedicated for this.
  • Better option is in my view is to enable 'Red side fragmentation' in the IPsec gateway.  1500 byte GTP-U packet it receives get fragmented before IPsec processing is done. Three packets in total would go through the IPsec processing and would be sent out. There is no further fragmentation.  On eNodeB,  three fragments would get reassembled after Ipsec inbound processing is done and before GTP-U detunnel processing.  Only one reassembly is required.  It has its own advantage, but I believe this is better option. Disadvantages being - It requires 3 fragment reassembly on eNodeB.  On IPsec gateway, more packets would go through Ipsec engine. Since many Ipsec gateway use hardware accelerators, I am thinking that this additional processing will not affect the overall throughput.
Comments?

2 comments:

howler said...

Hi
Your solution red fragmentation looks good. I have seen cisco doing the same in the name of pre-fragmentation.

ישי said...

What about the option to perform a Path MTU Discovery (especially for IPv6), and to take into account the possible additional headers when determining the packet length?
Let say it's 1500 bytes, fix your max packet length as 1300?