ffic engineering and VPNs. This consequently leads to the conclusion that the combination of MPLS with other protocols can poten- tially provide a sophisticated QoS platform for the future. It is important to note that traffic engi- neering, VPNs, and QoS are completely feasible without using MPLS, although MPLS is a convenient platform upon which the implementation of such capabilities is greatly facilitated. However, be aware of the potential impact that a VPN framework may have on the QoS mechanisms as there is no such thing as a free lunch. In fact, MPLS has recently started to play a major role in the evolving QoS debate. Although it has been mostly regarded as a novel way for routing, the fundamental premise of MPLS is a good base for the differentiated QoS treatment of traffic packets. For example, MPLS allows a single IP back- bone to deliver legacy services such as ATM and frame relay by offering similar QoS features to the ones previously offered by the other technologies. An example is IETF's Martini draft¹, which enables MPLS to effectively behave like a layer 2 protocol as it allows IP, which is a layer 3 network proto- col, to actually carry layer 2 protocol traffic such as frame relay, ATM Adaptation Layer 5 (AAL5), or Ethernet while providing a SONET circuit emulation service across an MPLS network and yet to preserve the same QoS guarantees usually associated with frame relay or other layer 2 traffic protocols. Several new approaches are available, including the following, but nothing has been officially standardized yet. RSVP can be used to ask MPLS routers downstream about available resources and, based on their responses, an end-to-end MPLS tunnel can be configured. RSVP Traffic Engineering (RSVP-TE) can be used, which is a newer addition to the long list of possibilities. The Constraint-Based-Routing Label Distribution Protocol (CR-LDP) can be used, which is a variation/extension of LDP, which is currently widely used in MPLS networks. The experimental (EXP) bits in the MPLS shim header can b