LNS reassembly

LNS reassembly is supported in the BB-ISA. Fragments are collected and reassembled. After the entire L2TP packet is reassembled, the packet is either decapsulated or sent to the CPM without change.

The delivery of the L2TP packets to the BB-ISA depends on the specific fields in the L2TP header. The forwarding decision on the ingress LNS side in the upstream direction (LAC->LNS) is based on the tunnel-id or session-id combination and the T-bit (message type bit – control or data) in L2TP header.

Control type messages are delivered directly to the CPM. CPM performs L2TP decapsulation and processes the message (tunnel or session setup/teardown related messages or tunnel hellos). The CPM provides forwarding information to the forwarding plane (ingress/egress IOM and the carrier IOM) and to the BB-ISA (tunnel-src plus tunnel-id/session-id plus generated-mac-addr and SAP).

Data type messages are delivered directly to the BB-ISA. The BB-ISA decapsulates the L2TP packets and forwards them to the carrier IOM as a quasi-PPPoE frame (ESM forwarding module).

Because the LAC fragments the packets in the upstream direction, the L2TP header is preserved only in the first fragment. Therefore, the crucial forwarding information needed by LNS is lost in all consecutive fragments. If a fragments ends up in the wrong BB-ISA with no reassembly context for the fragment, the fragment is dropped.

Similarly, the information whether to forward the fragment to the BB-ISA (data packet) or the CPM (control packet) is lost.

To support LSN reassemble, the following configuration limitations are imposed:

The lns-reassembly commands that inform the ingress forwarding plane that all L2TP packets should be sent to the BB-ISA are configured in the config>router>l2tp and config>service>vprn>l2tp contexts.