• E
    mpls: Basic routing support · 0189197f
    Eric W. Biederman 提交于
    This change adds a new Kconfig option MPLS_ROUTING.
    
    The core of this change is the code to look at an mpls packet received
    from another machine.  Look that packet up in a routing table and
    forward the packet on.
    
    Support of MPLS over ATM is not considered or attempted here.  This
    implemntation follows RFC3032 and implements the MPLS shim header that
    can pass over essentially any network.
    
    What RFC3021 refers to as the as the Incoming Label Map (ILM) I call
    net->mpls.platform_label[].  What RFC3031 refers to as the Next Label
    Hop Forwarding Entry (NHLFE) I call mpls_route.  Though calling it the
    label fordwarding information base (lfib) might also be valid.
    
    Further the implemntation forwards packets as described in RFC3032.
    There is no need and given the original motivation for MPLS a strong
    discincentive to have a flexible label forwarding path.  In essence
    the logic is the topmost label is read, looked up, removed, and
    replaced by 0 or more new lables and the sent out the specified
    interface to it's next hop.
    
    Quite a few optional features are not implemented here.  Among them
    are generation of ICMP errors when the TTL is exceeded or the packet
    is larger than the next hop MTU (those conditions are detected and the
    packets are dropped instead of generating an icmp error).  The traffic
    class field is always set to 0.  The implementation focuses on IP over
    MPLS and does not handle egress of other kinds of protocols.
    
    Instead of implementing coordination with the neighbour table and
    sorting out how to input next hops in a different address family (for
    which there is value).  I was lazy and implemented a next hop mac
    address instead.  The code is simpler and there are flavor of MPLS
    such as MPLS-TP where neither an IPv4 nor an IPv6 next hop is
    appropriate so a next hop by mac address would need to be implemented
    at some point.
    
    Two new definitions AF_MPLS and PF_MPLS are exposed to userspace.
    
    Decoding the mpls header must be done by first byeswapping a 32bit bit
    endian word into the local cpu endian and then bit shifting to extract
    the pieces.  There is no C bit-field that can represent a wire format
    mpls header on a little endian machine as the low bits of the 20bit
    label wind up in the wrong half of third byte.  Therefore internally
    everything is deal with in cpu native byte order except when writing
    to and reading from a packet.
    
    For management simplicity if a label is configured to forward out
    an interface that is down the packet is dropped early.  Similarly
    if an network interface is removed rt_dev is updated to NULL
    (so no reference is preserved) and any packets for that label
    are dropped.  Keeping the label entries in the kernel allows
    the kernel label table to function as the definitive source
    of which labels are allocated and which are not.
    Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    0189197f
mpls.h 234 字节