Difference between revisions of "Manual:MPLS/Overview"
|Line 65:||Line 65:|
Revision as of 11:22, 28 November 2008
MPLS stands for MultiProtocol Label Switching. It kind of replaces IP routing - packet forwarding decision (outgoing interface and next hop router) is no longer based on fields in IP header (usually destination address) and routing table, but on labels that are attached to packet. This approach speeds up forwarding process because next hop lookup becomes very simple compared to routing lookup (finding longest matching prefix).
Efficency of forwarding process is the main benefit of MPLS, but it must be taken into account that MPLS forwarding disables processing of network layer (e.g. IP) headers, therefore no network layer based actions like NAT and filtering can be applied to MPLS forwarded packets. Any network layer based actions should be taken on ingress or egress of MPLS cloud, with preferred way being ingress - this way, e.g. traffic that is going to be dropped anyway does not travel through MPLS backbone.
In the simplest form MPLS can be thought of like improved routing - labels are distributed by means of LDP protocol for routes that are active and labelled packet takes the same path it would take if it was not labelled. Router that routes unlabelled packet using some route for which it has received label from next hop, imposes label on packet and send it to next hop - it gets MPLS switched further along its path. Router that receives packet with label it has assigned to some route changes packet label with one received from next hop of particular route and sends packet to next hop. Label switched path ensures delivery of data to the MPLS cloud egress point. Applications of MPLS are based on this basic MPLS concept of label switched paths.
Another way of establishing label switching path is traffic engineering tunnels (TE tunnels) by means of RSVP TE protocol. Traffic engineering tunnels allow explicitly routed LSPs and constraint based path selection (where constraints are interface properties and available bandwidth).
Taking into account complexity, new protocols and applications that MPLS introduces and differences of concepts that MPLS adds to routed/bridged network, it is recommended to have in depth understanding of MPLS concepts before implementing MPLS in production network. Some suggested reading material:
- Multiprotocol Label Switching http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
- RFC3031 Multiprotocol Label Switching Architecture http://www.ietf.org/rfc/rfc3031.txt
- MPLS Fundamentals by Luc De Ghein http://www.amazon.com/MPLS-Fundamentals-Luc-Ghein/dp/1587051974
RouterOS MPLS features
As of version 3.8 MPLS feature development for RouterOS continues in mpls-test package that requires routing-test package. Currently RouterOS (by means of mpls-test and routing-test packages) supports the following MPLS related features:
- MPLS switching with penultimate hop popping support
- static local label bindings for IPv4
- static remote label bindings for IPv4
- Label Distribution Protocol (RFC 3036, RFC 5036) for IPv4
- downstream unsolicited label advertisement
- independent label distribution control
- liberal label retention
- targeted session establishment
- optional loop detection
- Virtual Private Lan Service
- VPLS LDP signalling (RFC 4762)
- VPLS pseudowire fragmentation and reassembly (RFC 4623)
- VPLS MP-BGP based autodiscovery and signaling (RFC 4761), see BGP based VPLS
- RSVP TE Tunnels
- tunnel head-end
- explicit paths
- OSPF extensions for TE tunnels
- CSPF path selection
- forwarding of VPLS and MPLS IP VPN traffic on TE tunnels
- MP-BGP based MPLS IP VPN
- OSPF extensions for MPLS TE
MPLS features that RouterOS DOES NOT HAVE yet:
- IPv6 support
- LDP features:
- downstream on demand label advertisement
- ordered label distribution control
- conservative label retention
- MPLS IP VPN features
- proper CE-PE IGP protocol support
- TE features
- fast reroute
- link/node protection
To ensure compatibility with other manufacturer equipment ensure that required features match, if uncertain, consult with Mikrotik support. RouterOS LDP and TE implementation has been tested with Cisco IOS.