The goal of this event was two-fold - first, as for typical interoperability test events, to verify and improve the interworking of vendors implementations, and secondly, to prove that the Service Providers will be able to deploy VPN services over MPLS networks knowing that the network will provide the differentiated services requested by customers for their business-critical applications.
Today, this means more than just to find bugs and correct them to advance the standards compliance. In many cases, implementations rely on draft standards - vendors need to adapt their features to customers requirements so fast they cannot wait until the final standard is adopted. Thus, the test event was another effort to verify clarity of the current standards.
Results: MPLS Diff-Serv Tests - Basic interoperability of RSVP-TE and OSPF-TE was achieved between all vendors without any signaling or routing issues. Problems that had been noticed in previous events have obviously been corrected. It was very positive to see that the signaling and routing implementations of all participating.
The test went forward without major issues when all vendors defined the mapping between experimental bits and per-hop behaviors for Assured Forwarding (AF), Expedited Forwarding (EF) and Best Effort traffic. Initially, the test plan was unclear about the drop precedence so we discussed the expected handling for different AF types in the same AF class. The IETF standard defines a relative drop precedence relationship instead of absolute values. Some devices were flexible to modify the relative drop precedence while others had fixed relationships. For example, drop precedence is smaller for AF11 than for AF12. The probability to drop AF11 traffic could be varied from zero up to the drop precedence of AF12 in some devices; it was fixed in other devices.
In this multi-vendor test it was of course impossible to use any management application to configure the per-hop behavior policies on all switches. The vendors` engineers had to configure everything manually instead. Naturally, some misconfiguration happened, leading to incorrect prioritization. We recommend to use management systems to control the distribution of policies within a Diff-Serv/traffic engineering enabled network.
All vendors supported E-LSPs (no matter what physical link type was chosen) and were able to use the full range of experimental bits. We tested with three queues which is realistic compared to today`s network requirements. A few vendors also supported L-LSPs over ATM or PoS interfaces.
Only one vendor implemented the DiffServ object as per RFC3270 - all other implementations were designed to accept locally configured Diff-Serv mappings only.
When setting up label-switched paths with traffic engineering and DiffServ, a few interoperability problems were observed by the vendors. Most notably, it is important to recognize an RSVP-TE path as DiffServ-enabled no matter whether the DiffServ object is present or not. Therefore, RFC3270 defines a backwards compatibility mode. Other interop issues with DiffServ-enabled path messages were also noted, leading to path rejection. The participants informed us that these issues have either already been resolved during the event, or will be fixed in the following weeks.
Due to limited time, it was not possible to evaluate constraint-based routing in detail. However, five vendors (see table on page 3) confirmed that they used OSPF-TE constraint-based routing during the whole session. Based on current OSPF-TE reserved bandwidth information, an ingress router calculates a suitable end-to-end path that satisfies the tunnel resource requirements Ñ not just based on static path cost. One vendor demonstrated briefly that the constraint-based routing process works as expected.
