| Key Features Tested | Results | |
| L2 Pseudowires | Interoperability RSVP-TE | OK |
| Interoperability LDP | OK in most cases | |
| Static LSPs without signaling | OK, supported by two vendors | |
| Data Transfer | OK | |
| Ethernet tunnels | OK | |
| Traffic Transfer Over RSVP-TE and LDP Tunnels | OK | |
| ATM Pseudowires | OK, tested with one vendor | |
| Frame Relay Pseudowires | not tested | |
| TDM Pseudowires | OK, tested with one vendor | |
| VPLS | Full-Mesh Tunnel Establishment between PE-RS systems | OK |
| Traffic Transfer Over RSVP-TE Transport Tunnels | OK | |
| MAC Address Withdraw | not tested | |
| Hierarchical VPLS PE-RS functionality | OK | |
| Hierarchical VPLS MTU functionality | OK | |
| LSP Ping and Traceroute | Generating LSP Echo Request | OK |
| Generating LSP Echo Reply | OK | |
| Receiving LSP Echo Requests | Issues | |
| Receiving LSP Echo Replies | Issues | |
| Generating LSP Traceroute Request | OK | |
| Receiving LSP Traceroute Messages | Issues | |
Problem Summary
| Problem Area | Description | Temporary Solution, if any | Recommendation |
| LDP | Vendor-specific MTU size calculations do not always match
|
None | If the advertised MTU size is derived from the access interface MTU, the exact value of signalled MTU should be known and configured at both sides. |
| LDP Hello message with Hold time set to 0 (default) was not accepted as correct | Set Hold time to 45 sec explicitly | Implementations shall accept the value 0 to match RFC 3036 3.5.2. | |
| The negotiation of timer values (Hello, Keep Alive) did not work properly which caused LDP sessions to disconnect. | Set timers to identical values | Fix implementations that do not negotiate timers correctly | |
| Some vendors do not support pseudowires on LDP tunnels | None | To be most flexible for multi-vendor networks, it is recommended to support both RSVP-TE and LDP signaling protocols for tunnel transport |
|
| RSVP-TE | Some vendors do not support pseudowires on RSVP-TE tunnels | None | |
| OSPF | Some vendors do not support OSPF | The Router ID had to be configured statically, TE tunnels had to be established without CSPF
|
OSPF-TE support is recommended to improve interoperability and to simplify provisioning |
| Some vendors always expect OSPF-TE to be enabled in order to establish MPLS tunnels, even without Traffic Engineering parameters. It took a lot of time to configure MPLS properly. | Simplify MPLS configuration for the case that the peer does not run a routing protocol. | ||
| MPLS OAM | MPLS LSP ping/traceroute packets were sent without an "IP router alert option". The intermediate router did not recognize this packet as an MPLS OAM packet. | None | This is a common bug with MPLS implementations; vendors should keep it in mind |
| Interoperability couldn't be achieved in some cases because vendors implemented different LSP ping/traceroute draft versions. | Upgrade implementations to the latest draft. | The IETF should verify if incompatible draft updates can be avoided. | |
| Configuration | Traffic Engineering had to be enabled separately in order to establish RSVP-TE tunnels. It took a lot of time to configure MPLS properly. | Simplify the configuration of MPLS. |
Conclusion Since 2002, the MPLS and Frame Relay Alliance has tested and publicly demonstrated different aspects of MPLS interoperability. In a total of six large multi-vendor test events, the participating vendors verified many different MPLS protocols for multi-vendor interoperability - from basic signalling to different flavors of Layer 2 and Layer 3 VPN services as well as DiffServ traffic engineering.
The interoperability event at MPLS World Congress 2005 reassures us that MPLS Layer 2 Ethernet-based VPN implementations are ready for large-scale deployments with many customers in a similar way to Layer 3 VPNs. Of course, each of these two solutions has its particular applications, inherent strengths and weaknesses which are well-known. In both cases, the IETF still continues to develop recommendations (see RFC2547bis, and the battle between BGP-based and LDP-based VPLS).
The more MPLS becomes a complete set of protocols suitable for a multitude of applications, the more we recognize how many work areas still remain to be addressed. As an example, it was quite surprising to notice that there were still issues with the interpretation of the basic LDP standard defined four years ago. At one of the first interoperability events of the MFA in 2003, an urgent need for implementation agreements was noted in order to reduce the amount of protocol options. This statement still holds, and implementation agreements defining use cases are more important than ever.
MPLS LSP ping and traceroute are a different topic. The corresponding internet draft still undergoes regular changes - which is the nature of an internet draft -, and vendors implement different incompatible versions. We contacted the draft authors; they hope that the next draft (number 8) will be fairly mature and might go to last call in March. There is hope that LSP ping and traceroute implementations will work more reliably in heterogeneous environments at the next MFA interoperability test event.
Despite of these small issues, Multi-Protocol Label Switching has grown to support a full set of standardized and interoperable VPN types - making MPLS way more flexible than network technologies of the past. A vast number of vendors implement MPLS by now, and the majority of carriers worldwide uses MPLS as the foundation for their IP and layer 2 service backbones.
The MPLS & Frame Relay Alliance and the supporting test labs, UNH-IOL and EANTC, are proud that the series of interoperability test events conducted since 2001 have been able to improve interoperability dramatically.
