Provider Provisioned VPN Working Group Wing Cheong Lau Internet Draft Fabio M. Chiussi Lucent Technologies Luyuan Fang AT&T Expires: August 2002 March 2002 Extensions of for QoS Support in Transparent VLAN Services over MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is submitted to the Audio/Video Transport Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the rem-conf@es.net mailing list. Distribution of this memo is unlimited. Abstract The document draft-lasserre-vkompella-ppvpn-vpls-00.txt describes a solution to support point-to-multipoint Transparent Virtual LAN (TVLAN) service over MPLS. This document describes two extensions to facilitate the provisioning and support of Quality of Service (QoS) in TVLAN over MPLS. First, we extend the use of the VCID field in the VC-FEC to identify a VPN endpoint. Second, we use one VC-label per source/destination VPN endpoint pair. In this document, we also identify a number of other mechanisms that increase the flexibility and ease of provisioning of QoS in the TVLAN service. Lau, et al. expires August 2002 [Page 1] INTERNET DRAFT Extensions for QoS Support ... March 2002 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 Placement of this Memo in Sub-IP Area Related Documents http://search.ietf.org/internet-drafts/draft-lasserre-vkompella- ppvpn-vpls-00.txt http://search.ietf.org/internet-drafts/draft-martini-l2circuit- trans-mpls-06.txt http://search.ietf.org/internet-drafts/draft-martini-l2circuit- encap-mpls-02.txt WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN WHY IS IT TARGETED AT THIS WG The charter of the PPVPN WG includes L2 VPN services with support of Quality of Service (QoS), and this draft specifies extensions to provision and support QoS in Ethernet L2 VPN services over MPLS. Justification Existing Internet drafts specify how to provide point-to-multipoint Ethernet L2 VPN services over MPLS. This draft defines how to extend those draft to provision and support QoS in those services. Lau, et al. expires August 2002 [Page 2] INTERNET DRAFT Extensions for QoS Support ... March 2002 1. Background and Overview [1] describes a mechanism to encapsulate Layer 2 Frames for transport over an MPLS network. Signaling mechanisms, in the form of extensions of Label Distribution Protocol (LDP) are then proposed in [2] to dis- tribute the required VC labels as specified in [1] for setting up point-to-point layer 2 transport trunks over an MPLS network. More recently, [4] extends [1] and [2] to support point-to-multipoint Virtual Private LAN Services (VPLS), in particular, Layer 2 (L2) Transparent VLAN services (TVLAN) over MPLS. The aforementioned Internet Drafts have been focusing on providing connectivity for transporting L2 frames over an MPLS network. However, one critical aspect of such services, namely, the support of Quality of Service (QoS), has not been explicitly addressed so far. In this document, we identify a number of additional issues that stem from the need of easily provisioning and supporting QoS in the TVLAN over MPLS service. We then describe two simple extensions of the pro- posed architecture/signaling schemes in [2] and [4] to easily and efficiently support these additional needs. Two mechanisms are useful to considerably facilitate QoS support. First, when provisioning QoS, there is a need to identify each VPN endpoint, as opposed to just the VPN (in this document, we use the terms VPN and TVLAN interchangeably). In fact, the QoS requirements are either specified in terms of individual endpoints (hose model) or pairs of endpoints (pipe model). In addition, in case of two or more endpoints for the same VPN residing in the same Provider Edge switch (PE), aggregation of resources is desirable, or even necessary. If we have the means of identifying the endpoint, existing mechanisms for automatic discovering and signaling can be used without change in the case of multiple endpoints residing in the same PE. The identifica- tion of the VPN endpoints can be easily achieved by extending the use of the VCID field in [4] and [2] to refer to the VPN endpoint rather than to the VPN as a whole. It should be noted that such an extension can even coexist with the use of the VCID field as in the [4] and [2] drafts. For example, VPN's with best effort traffic can use the VCID field as in the [4] and [2] drafts, while VPN's with QoS requirements can use the VCID field as defined in this draft. For this purpose, we propose to add a new code-point in the VC-type field of the VC FEC as defined in [2, 4]. Second, when QoS is supported, multiple tunnels may be established between a given pair of PE's. In the TVLAN service, a binding needs to be created between each VC-label and its transport outer tunnel, Lau, et al. expires August 2002 [Page 3] INTERNET DRAFT Extensions for QoS Support ... March 2002 to be used for VC label provisioning and resource reservation at the destination PE. To facilitate this binding, we propose the use of one VC-label per source/destination VPN endpoint pair. An added benefit of the use of this scheme is that it eliminates the need of local bridging at the destination PE in case of multiple endpoints of a given VPN residing on the same PE, since the VC-label distinguishes among the source/destination endpoint pairs. It should also be pointed out that signaling extensions are needed to support the crea- tion of the bindings between VC-labels and their corresponding outer tunnel. 2. VPN Endpoint identifiers for specifying VPN QoS requirements From the perspective of a customer who is purchasing L2VPN services from a service provider, it is natural to specify customer QoS requirements in form of QoS requirements at (or between) various end- points of the VPN [Note1]. By a VPN endpoint, we mean a customer- facing interface on a PE of the service provider network belonging to the said L2VPN. It is therefore essential for the provider of L2VPN services to be able to identify, reference and discover the endpoints within a L2VPN so that QoS requirements of a VPN can be specified and maintained. The architectures proposed in [2, 4] do not provide the capability to identify/ reference individual endpoints within a L2VPN: In [4], a network-wide unique VCID is assigned to each L2VPN to serve as the identifier for the whole VPN. No means is explicitly provided to identify/ reference different endpoints within a L2VPN. It should be noted that, while the VCID's in [2] carry similar seman- tics as in the case of [4], the limitation imposed by [2] is not as serious because [2] only covers the point-to-point case, i.e. there are only two endpoints within the VPN. As such, the two endpoints within a VPN can easily be referenced/ identified by a hosting PE depending on whether it is the "local" one or the "remote" hosted by the peering PE. Obviously, this is not the case in a multipoint scenario. In [4], the VCID of a L2VPN is used as a Forwarding Equivalent Class (FEC) to support MPLS- based packet delivery towards the list of PEs hosting the L2VPN. Once a packet arrives at the destination PE, the VC-label carried by the packet is used to determine its VPN member- ship. Unless the destination PE hosts only one endpoint of the same VPN, the egress customer-facing interface for the packet has to be determined based on further local bridging, i.e. processing based on L2-header information and locally learned binding between the Lau, et al. expires August 2002 [Page 4] INTERNET DRAFT Extensions for QoS Support ... March 2002 destination MAC address (VLAN-tag), VPN identifier and the egress- facing port. In this regard, the architecture proposed by [4] hides the presence of multiple endpoints of the same L2VPN at a PE from other PEs in the network. This is the case during not only the sig- naling phase but also the packet forwarding phase. While such an approach may be acceptable for best-effort packet delivery, it becomes inadequate when QoS guarantees have to be specified, signaled and maintained for individual endpoints of a VPN. It is certainly conceivable that, by combining proper flow aggrega- tion, traffic policing / packet-marking, careful resource management, with apriori knowledge of association between endpoints of a VPN and their corresponding hosting PEs, we can translate the QoS require- ments amongst various VPN endpoints to aggregate QoS requirements amongst hosting PE's of the VPN. However, unless individual endpoint requirements are all manually aggregated and provisioned, and no automatic discovery of VPN endpoints is involved, there is still a need to identify and reference individual endpoints of a VPN in the network and to specify QoS requirements amongst these endpoints. More importantly, the ability to identify, discover and reference individual VPN endpoints becomes critical when automated provisioning/signaling of QoS-based L2VPN service is needed. Towards this end, we propose the following extensions to [4]. A L2VPN is uniquely identified by a network-wide VPN identifier, VPNID, as specified by Internet RFC2685. This VPNID is to be carried in the optional interface parameter in the VC FEC as specified in [3]. A 32-bit VPN-wide unique VCID is assigned to represent each end- point within a VPN. This VCID is carried in the same VCID field in the VC FEC as defined in [2]. The concatenation of the VPNID and the VCID defines a globally unique VPN endpoint which can be used as the identifier/ reference for VPN endpoint discovery. By adopting the definition of VPNID in RFC2685, collision of VPNID identifier amongst different service provider is avoided. This is not the case for [4], where a provider-wide unique VCID is used for identifying a L2VPN. With this mechanism, discovery of VPNID/VCID information within a network can be based on the use of a full-mesh of LDP sessions among all PE's within a network using LDP extended discovery mechanism or using extensions of existing interior or exterior routing protocols similar to those proposed in [6, 7, 8]. The details of such discovery protocols and mechanism are beyond the scope of this draft and will be addressed in future drafts. Once VPNID's and VCID's are in place, the definition of a L2VPN as Lau, et al. expires August 2002 [Page 5] INTERNET DRAFT Extensions for QoS Support ... March 2002 well as its QoS requirement can be specified, signaled and maintained in each PE, e.g. bandwidth pipes can be setup between each ordered pair of source and destination VCID's. We define a new code-point in the VC-type field of the VC FEC as defined in [2, 4] to indicate the new use/semantics of VPNID and VCIDs as VPN and VPN endpoint identifiers respectively. The new VC type, called VPN Endpoint VPLS, has codepoint 0x000C. By introducing this new VC-type, our proposed signaling scheme can coexist with those defined in [2] and [4]. 3. The need of Supporting Parallel Outer Tunnels between PE's [2] and [4] both assume the existence of an outer tunnel between the source and destination PEs of an VC-LSP. While one outer tunnel per source/destination PE pair may be adequate for best-effort based L2VPN's, the support of parallel outer tunnels is crucial in QoS- based L2VPNs for load-balancing, traffic-engineering as well as fault-tolerant purposes. With multiple parallel tunnels, the creation/book- keeping of the binding between each outer-tunnel and its component VC-LSP's at the source and destination PEs becomes important. However, these issues are not addressed by [2, 4]. In fact, under the label distribution mechanism proposed in [2,4], VC-labels are created and distributed by a destination PE on a per-platform basis. Unless there is only one outer tunnel between a pair of PE's, the destina- tion PE, in general, does not know apriori the arrival (ingress) port of packets carrying a specific VC-label. When multiple parallel outer tunnels exist between the same pair of PE's, and are terminated at different ingress ports of the destination PE, it is essential for the destination PE to know the binding between each VC LSP and its outer tunnel. Otherwise, VC-label provisioning as well as resource reservation have to be performed at all of the potential ingress ports of the destination PE [Note2]. While the binding information between a VC LSP and its carrying outer tunnel should be readily available at the source PE, this informa- tion has to be convened to the destination PE either via signaling during VC- label distribution, or less preferably, via manual provi- sioning. Notice that the binding information between an outer tunnel and its component VC LSP's is not only useful for initial resource reservation, but also crucial for supporting automatic restoration Lau, et al. expires August 2002 [Page 6] INTERNET DRAFT Extensions for QoS Support ... March 2002 when a failure triggers a outer-tunnel to be rerouted to a different ingress port of the destination PE. To address the need of signaling the binding between a outer-tunnel and its component VC-LSP's, new tunnel-signaling mechanisms along the lines of those proposed for RSVP-TE in [9] and [10] are required. The details of such extensions is beyond the scope of this draft and will be addressed in a separate note in the future. As a interim solution, the binding between an outer-tunnel and its component VC- LSP's can be convened from the source PE to the destination PE via a network management system or through manual provisioning. 4. The need of finer grain VC-label assignment The need of supporting multiple parallel outer tunnels between a pair of PEs for the case of QoS-based L2VPN's also makes the strategy pro- posed in [4] of assigning one VC-label per VPN per pair of source and destination PEs inadequate due to packet reordering considerations. Consider the scenario in which multiple parallel outer tunnels exist between a pair of PEs and both the source and destination PEs host more than one endpoint of the same VPN. To preserve the delivery sequence of packets between a pair of source and destination VPN end- points, it is necessary to force packets destinating to the same VPN endpoint to take the same outer-tunnel. Otherwise, packet reordering at the destination endpoint is possible due to difference/variation in delay across multiple parallel outer-tunnels. The mapping of pack- ets into outer-tunnel should therefore be done on some sort of per destination VPN endpoint basis [Note3]. By assigning and distributing VC-labels on some sort of per destina- tion VPN endpoint basis, mapping of packet into outer-tunnel can be implemented straightforwardly by establishing the binding between VC-labels and outer-tunnel labels at the source PE. Given that per-destination-VPN-endpoint VC-label assignment is required, one may consider the use of the approach of assigning/distributing one VC-label per source PE per destination VPN endpoint. The benefit of this approach is that one can still rely on the downstream unsolicited mode of LDP, as stated in [2, 4] to per- form VC-label distribution. However, upon closer examination, such an approach is not feasible, since it requires the use of local bridging at a destination PE for packet delivery, which in turn prevents the proper choice of a per-destination-VPN-endpoint VC- label [Note4]. As a result, it becomes necessary to use a finer grain of VC-label assignment, namely, assigning one VC-label per ordered pair of Lau, et al. expires August 2002 [Page 7] INTERNET DRAFT Extensions for QoS Support ... March 2002 source and destination VPN endpoints. By assigning a different VC-label for each ordered pair of source and destination endpoints (identified by their corresponding VCIDs) within a VPN, merely standard MPLS based label popping and forwarding at the destination PE would suffice. The need to perform local bridg- ing at the destination PE is removed. Moreover, resource management at the destination PE can also be sim- plified by aligning QoS requirement within a VPN, i.e. as specified in a VPNendpoint-to-VPNendpoint basis, with the granularity of VC- label assignment. This can eliminate the delicate resource aggregation/policing/ packet-marking amongst QoS-guaranteed traffic flows sharing the same VC-label. A main drawback of using such a fine grain VC-label assignment is the increase in number of VC-labels being used [Note5]. Note that the downstream unsolicited mode of VC-label distribution using LDP extension, as specified by [2,4] cannot support the distri- bution of one VC-label per source/destination VPN endpoint. This is because, under the downstream unsolicited mode, there is no provi- sion for the destination PE to distribute multiple VC labels for dif- ferent VPN endpoints hosted by the same source PE. Towards this end, it is necessary to use the downstream on-demand mode of label distri- bution such as those in RSVP-TE and CR-LDP, to support VC-label dis- tribution as well as QoS flow reservation on a per source/destination VPN endpoint pair basis. In summary, we have identified a list of potential issues in [1, 2, 4] when QoS support has to be considered. To address these issues, we have proposed the following extensions/changes to the existing schemes as defined in [1, 2, 4]: 1) To extend the use of the VCID field in the VC-FEC as VPN endpoint identifiers ; 2) To use the VPNID defined in RFC 2685 (together with corresponding VC-FEC extension specified in [3]) to provide a globally unique iden- tifier of a L2VPN. 3) Maintain one VC-label per source/destination VPN endpoint pair to simplify resource and flow management and avoid complicated flow- aggregation at the source/destination PE's ; eliminate the need of performing local bridging at the destination PE; instead, it is suf- ficient to perform standard MPLS based forwarding in the destination PE based on the VC-label of an incoming packet. Lau, et al. expires August 2002 [Page 8] INTERNET DRAFT Extensions for QoS Support ... March 2002 4) VC-label distribution using downstream on-demand mode of RSVP-TE and/or CR-LDP instead of via downstream unsolicited mode of LDP. 5) Provide to the destination PE the binding information between an outer tunnel and its component VC LSP's to facilitate resource reser- vation/ restoration support. 5. Security This draft does not impose additional security considerations beyond those that apply to [1, 2, 3, 4]. 6. References [1] L. Martini et al, "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS networks". July 2001. [2] L. Martini et al, "Transport of Layer 2 Frames over MPLS", draft-martini-l2circuit-trans-mpls-07.txt, July 2001. [3] M. Lasserre et. al. " Transparent VLAN Services over MPLS", draft-lasserre-tls-mpls-00.txt, Aug. 2001. [4] M. Lasserre et. al. " Transparent VLAN Services over MPLS", draft-lasserre-vkompella-ppvpn-vpls-00.txt., Nov. 2001. [5] B. Fox, B. Gleeson, "Virtual Private Networks Identifier", RFC 2685. [6] T. Senevirathne, Paul Billinghurst, "Distribution of Layer 2 VPN Membership and Configuration using OSPF Opaque LSAs", draft- tsenevir-8021qospf-01.txt, July 2001. [7] T. Senevirathne, et. al., " BGP/MPLS Layer 2 VPN", draft- tsenevir-bgp-l2vpn-01.txt, July 2001. [8] H. Ould-Brahim et. al., "Using BGP as an Auto-Discovery Mechanism for Networked based VPNs", draft-ietf-ppvpn-bgpvpn-auto-00.txt, July 2001. [9] F. Baker et. al, ôAggregation of RSVP for IPV4 and IPV6 Reserva- tionö, RFC3175, September 2001. [10] A. Terzis et. al, ôRSVP Operation Over IP Tunnelsö, RFC 2746, Lau, et al. expires August 2002 [Page 9] INTERNET DRAFT Extensions for QoS Support ... March 2002 January 2000. 7. Notes [Note1] Under the pipe-model, QoS requirements are specified for traffic flows between each ordered pair of VPN endpoints. Under the hose-model, QoS requirements is specified for the aggregate incoming/outgoing flow at each VPN endpoint. [Note2] While per-platform provisioning of VC-label may be feasible for the support of best-effort VC LSP, such approach becomes unac- ceptably wasteful when VC LSPs within QoS guarantees are involved. [Note3] The alternative of using one VC-label per source/destination PE pair and map packets across multiple parallel tunnels based on destination MAC address (and VLAN-tag) is not attractive nor practi- cal from a outer-tunnel bandwidth management perspective because the QoS requirements within a L2VPN is likely to be defined in a VPNendpoint-to-VPNendpoint basis instead of at a per destination MAC address (and VLAN-tag basis). [Note4] This is because, with one VC-label per-source PE per destina- tion VCID, the whereabout of a source MAC address can only be learned and determined down to the source PE level: the specific source VPN endpoint within the source PE cannot be determined in gen- eral (unless the source PE only hosts a single endpoint of the VPN). As such, it becomes impossible for a source which wants to transfer data in the opposite direction to select the proper destination VPN endpoint specific VC-label. [Note5] For a VPN with N endpoints hosted by k PEs, our approach requires N(N-1) VC-labels while the [4] scheme requires k(k-1) VC- labels where N >= k in general. In practice, depending on geographi- cal distributions and the number of the PEs and customer sites, it is possible to have cases where N ~= k as well as N >> k > 1. (The k=1 case is irrelevant as VC-labels (or MPLS) should not be needed in such case.) To avoid unnecessary delivery of multiple copies of the same packet to the same PE during a VPN-wide broadcast/flooding, in our approach, it is also desirable to assign one "multicast" VC-label per destination PE per source VPN endpoint per VPN in case a desti- nation PE hosts more than one endpoint of the same VPN. This further increases the total number of VC-labels required for our approach. Lau, et al. expires August 2002 [Page 10] INTERNET DRAFT Extensions for QoS Support ... March 2002 8. Intellectual Property Considerations Lucent Technologies Inc. may own intellectual property in some on some of the technologies disclosed in this document. The patent licensing policy of Lucent Technologies Inc. with respect to any patents or patent applications relating to this submission is stated in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker, Intellectual Property Vice President, Lucent Technologies, Inc. This letter is on file in the offices of the IETF Secretariat. 9. Authors' Addresses Fabio M. Chiussi Bell Laboratories Lucent Technologies 101, Crawfords Corner Road, Holmdel, NJ 07733 fabio@lucent.com +1-(732)-949-2407 Luyuan Fang AT&T Room C2-3B35 200 S. Laurel Avenue Middletown, NJ 07748 luyuanfang@att.com +1-(732)-420-1921 Wing Cheong Lau Bell Laboratories Lucent Technologies 101, Crawfords Corner Road, Holmdel, NJ 07733 lau@lucent.com +1-(732)-949-0979