• SummerOfCode2018Projects
• FinishingMPLS

Finishing FreeBSD MPLS implementation

• Student: Samuel Bassaly (samuel.bassaly@gmail.com)

• Mentor: Alexander Chernikov (melifaro@)

Project description

MPLS is a source-routing method which simplifies routing. When a packet enters a network, the edge router determines the path each packet should take, then assigns it a label. The packet then takes that path until it arrives at its destination. Each intermediate hop in the path reads the label and forwards the packet accordingly, i.e. no more routing decisions are made for the packet. This is unlike conventional networking, where each hop determines the next one for each packet. Each label determines the Label Swiched Path (LSP) which each packet will take. Labels are assigned to packets by Label Switching Routers (LSRs). Packets that are assigned the same label are said to belong to the same Forwarding- Equivalence Class (FEC). Based on the destination address, the FEC of the packet is known and the label is assigned. There are several interesting applications to MPLS. Prominent examples are Layer 3 VPNs (L3VPNs) and Traffic Enginnering (TE). Additionally, there are lots of extensions to MPLS. The most famous are those related to fault management (e.g. MPLS Operations, Administration, and Maintenance (OAM)). These are the focus of this project.

Goal

The main goal of this project is to implement MPLS in the FreeBSD stack. Integration with one of the available routing stacks is a key objective (probably FRR [5]). Support for L3VPN is a main goal and should be completed by the end of the project. The setup and configuration of MPLS networks should be done using userland tools (e.g. `ifconfig(8)` and `route(8)`) For failure detection, at least the implementation of MPLS echo message [6] should be complete. This enables basic userland network diagnostic tools (`ping(8)` and `traceroute(8)`) to work with MPLS. A more ambitious goal is to fully implement MPLS OAM for fault management [7].

Implementation details

Phase 1

MPLS Stack & userland

The MPLS stack will be defined in /sys/netmpls/. The kernel interfaces will be similar to Linux MPLS implementation.

Tasks in this step are expected to be:

• Designing MPLS dataplane primitives (6 days)

  • These include structs and definitions. The path of the packet from entry till transmission should be detailed. Design should allow for future RSVP-TE additions.

• Implementation of the MPLS routing table (12 days)

  • In-kernel storage of Label Information Base (LIB) for MPLS

• Integration with FreeBSD's routing socket table (12 days)

  • Extending routing table to correctly handle labels. Add support for mapping label to routes.

    Add support for MPLS in `netstat(1)`.

• Implement MPLS stack operations (12 days)

  • Input and output (dataplane) functions. Implement stack push and pop, label lookup, forwarding. Also add extra logic needed by LSRs, like selecting correct label for incoming packets and correct encapsulation.

• Implementing userland tools support I (15 days)

  • Tools to setup network like `ifconfig(8)` (enable MPLS interface) and `route(8)` (configure the network)

Testing

It is expected that by this phase, FreeBSD shall have a working MPLS implementation. Testing will be carried out against another FreeBSD node. It should pass the following:

• Successfully initiating an MPLS session (using static configuration) with another FreeBSD
• Correctly handling MPLS packets as an intermediate hop and downstream node
• Successfully carrying out the role of LSR in a network

At this point, the main work with MPLS is done. The next phase would be developing features based on MPLS.

Phase 2

L3VPN

To have L3VPNs, two main features need to be developed. First, edge routers need to be able to handle VRFs. Ability to handle multiple VRFs shall be implemented. Second, VPN labels need to be distributed using existing routing protocols. To support label distribution, extended community attributes and BGP multiprotocol extensions need to be implemented in `bgpd` implementation.

Tasks will be:

• Extending an existing BGP implementation with VPN extensions [8] (12 days)

  • FRR is the main candidate. Support for needed extended attributes shall be added for IPv4 and IPv6

• Add kernel support for L3VPN (12 days)

  • Support for VRFs. For Edge routers: handling multiple VRFs and selecting the right VRF for packets.

• Implementing userland tools support II (6 days)

  • Ability to configure VPNs and configure routes using `route(8)`.

Diagnostics

The most important part in diagnostics is implementing support for network diagnostic tools. Additionally, MPLS OAM [7] will add a great value, but implementation is a bit more complex.

Tasks will be:

• Implementing userland tools support III (9 days)

  • Implement MPLS echo request and reply.

    Integrate with `ping(8)` and `traceroute(8)`. This task is top priority.

• Design and implement an MPLS OAM framework. (12 days)

  • Design a way to interact with OAM and set its parameters.

    Implement at least the minimum implementation requirments stated by the RFC( [7] section 6).

Testing

By this phase, the main goal of this project should be reached. It should pass the following:

• MPLS is working in hybrid environment of FreeBSD and Linux
• A full MPLS VPN can be established
• All network tools should be working seamlessly with MPLS
• An end-to-end network of FreeBSD nodes shall be working, with VPN tunnel established between two nodes

At this point, the main goal of this project is reached.

Useful links

[1]: Multiprotocol Label Switching Architecture, RFC 3031

[2]: Label Distribution Protocal, RFC 5036

[3]: Requirements for Traffic Engineering Over MPLS, RFC 2702

[4]: Demystifying MPLS, The MPLS framework in OpenBSD

[5]: https://frrouting.org/

[6]: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures

[7]: MPLS Fault Management Operations, Administration, and Maintenance (OAM)

[8]: BGP/MPLS IP Virtual Private Networks (VPNs)