mpls(4) - NetBSD Manual Pages

Command:

Section:

Arch:

Collection:

>>>

MPLS(4) NetBSD Kernel Interfaces Manual MPLS(4)

NAME

mpls -- Multiprotocol Label Switching

SYNOPSIS

options MPLS
pseudo-device ifmpls
#include <sys/types.h>
#include <netmpls/mpls.h>

DESCRIPTION

MultiProtocol Label Switching represents a mechanism which directs and
carries data in high-performance networks, its techniques being applica-
ble to any network layer protocol.

In an MPLS domain the assignment of a particular packet a particular For-
ward Equivalence Class is done just once, as the packet enters the net-
work. The FEC to which the packet is assigned is encoded as a short
fixed length value known as a ``label''. When a packet is forwarded to
the next hop, the label is sent along with it; that is, the packets are
``labeled'' before they are forwarded.

A router capable of receiving and forwarding MPLS frames is called
``Label Switch Router'' or LSR. Label scope is generally router-wide
meaning that a certain label has a specific meaning only for a certain
LSR.

Currently, NetBSD supports MPLS over Ethernet interfaces and GRE tunnels.
For these kind of interfaces, a label is contained by a fixed sized
``shim'' that precedes any network layer headers, just after data link
layer headers.

MPLS shim header structure
In network bit order:

-------------------------------------------
| | | | |
| Label | TC | BoS | TTL |
| 20 bits | 3 bits | 1 bit | 8 bits |
| | | | |
-------------------------------------------

Label 20 bits representing FEC, consequently the only informa-
tion used to forward the frame to next-hop

Traffic Class Field
3 bits that are used for specifying a traffic class,
usually used for defining a type of service. This field
was named the "Experimental Field" in most early
(pre-RFC 5462) documents.

Bottom of Stack One bit that is set for the last entry in the shim stack
and 0 for all others. An MPLS frame may contain more
than one shim, the last one before the network headers
being marked by setting the BoS bit.

TTL 8 bits, representing Time to Live, decremented at every
LSR.

USAGE

The MPLS behavior is controlled by the net.mpls sysctl(8) tree:

net.mpls.accept If zero, MPLS frames are dropped on sight on
ingress interfaces.

net.mpls.forwarding If zero, MPLS frames are not forwarded to next-
hop.

net.mpls.ttl The default ttl for self generated MPLS frames.

net.mpls.inet_mapttl If set, TTL field from IP header will be mapped
into the MPLS shim on encapsulation, and the TTL
field from MPLS shim will be copied into IP
header on decapsulation.

net.mpls.inet6_mapttl The IPv6 version of the above.

net.mpls.inet_map_prec If set, precedence field from IP header will be
mapped into MPLS shim in TC field on encapsula-
tion, and the MPLS TC field will be copied into
IP Precedence field on decapsulation.

net.mpls.inet6_map_prec The IPv6 version of the above.

net.mpls.icmp_respond Returns ICMP TTL exceeded in transit when an
MPLS frame is dropped because of TTL = 0 on
egress interface.

net.mpls.rfc4182 Pop the Explicit Null labels as specified by RFC
4182
In order to encapsulate and decapsulate to and from MPLS, an mpls pseudo-
interface must be created and packets that should be encapsulated must be
routed to that interface.

MPLS routes may be created using AF_MPLS sa_family sockaddrs for destina-
tion and tag fields. Other protocols can be encapsulated using routes
pointing to mpls pseudo-interfaces, and AF_MPLS sockaddrs for tags.
Decapsulation can be made using values of reserved labels set in the tag
field (see below). For more information about doing this using userland
utilities see the EXAMPLES section of this manual page.

The netstat(1) and route(8) utilities should be used to manage routes
from userland.

The NetBSD implementation stores route tagging information into a sock-
addr_mpls structure that is referenced by the rt_tag field of rtentry
struct. For storing multiple labels associated with the next-hop, the
current implementation abuses the sockaddr_mpls structure, extending it
in order to fit a stack of labels.

ldpd(8) should be used in order to automatically import, manage and dis-
tribute labels among LSRs in the same MPLS domain.

RESERVED LABELS
MPLS labels 0 through 15 are reserved. Out of those, only four are cur-
rently defined:

0 IPv4 Explicit NULL label. This label value is only legal at the bot-
tom of the label stack. It indicates that the label stack must be
popped, and the forwarding of the packet must then be based on the
IPv4 header.

1 Router Alert Label. Currently not implemented in NetBSD.

2 IPv6 Explicit NULL label. It indicates that the label stack must be
popped, and the forwarding of the packet must then be based on the
IPv6 header.

3 Implicit NULL label. This is a label that an LSR may assign and dis-
tribute, but which never actually appears in the encapsulation. When
an LSR would otherwise replace the label at the top of the stack with
a new label, but the new label is ``Implicit NULL'', the LSR will pop
the stack instead of doing the replacement. In this case, the LSR
will have to deduce by itself what is the original address family of
the encapsulated network packet. Currently, NetBSD implementation is
assuming that the latter address family is equal to the next-hop
address family specified in the Implicit Null Label MPLS route.

EXAMPLES

1. Create an MPLS interface and set an IP address:

# ifconfig mpls0 create up
# ifconfig mpls0 inet 192.168.0.1/32

2. Route IP packets into MPLS domain with a specific tag

# route add 10.0.0.0/8 -ifp mpls0 -tag 25 -inet 192.168.1.100

3. Create a static MPLS forwarding rule - swap the incoming label 50 to
33 and forward the frame to 192.168.1.101 and verify the route

# route add -mpls 50 -tag 33 -inet 192.168.1.101
add host 50: gateway 192.168.1.101
# route -n get -mpls 50
route to: 50
destination: 50
gateway: 192.168.1.101
Tag: 33
local addr: 192.168.1.180
interface: sk0
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 0 0
sockaddrs: <DST,GATEWAY,IFP,IFA,TAG>

4. Route IP packets into MPLS domain but use a different source address
for local generated packets.

# route add 10.0.0.0/8 -ifa 192.168.1.180 -ifp mpls0 -tag 25 -inet 192.168.1.100
For the latter example, setting an IP address for the mpls0 inter-
face is not necessary.

5. Route MPLS packets encapsulated with label 60 to 192.168.1.100 and
POP label

# route add -mpls 60 -tag 3 -inet 192.168.1.100

6. Route IP packets into MPLS domain and prepend more tags

# route add 10/8 -ifa 192.168.1.200 -ifp mpls0 -tag 20,30,40 -inet 192.168.1.100
For the above example, tag 20 will be inserted at Bottom of Stack,
while tag 40 will be set into the outermost shim.

7. Replace label 60 with label 30, prepend two more labels: 40 and 41
(in this order) and forward the result to 192.168.1.100

# route add -mpls 60 -tag 30,40,41 -inet 192.168.1.100