Internet Draft Document Defeng Li L3 VPN Working Group Huawei Technologies draft-defeng-l3vpn-qos-crc-01.txt Expires: August 2004 February 2004 QoS-guaranteed MPLS-based NBVPN with centralized resource controller draft-defeng-l3vpn-qos-crc-01.txt 1. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document focuses on the QoS problem in NBVPN, analyses the QoS requirement for NBVPN, the insufficiency of QoS guarantee in the current NBVPN schemes in the related IETF work group, and proposes a QoS-guaranteed NBVPN reference model with centralized resource controller, in this model, some new concepts are introduced, such as VPN Logical Bearer Network(VPN-LBN), VPN Centralized resource controller(VPN-CRC); and mechanism of guaranteeing the VPN QoS is explained in details, including address space, isolation between VPNs, VPN route distribution, forwarding, interface requirement signaling requirement, hybrid QoS-VPN, intra-domain VPN, inter-domain VPN. 3. Conventions Defeng Li. [Page 1] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 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 JUSTIFICATION As an important application, several kinds of NBVPN (L2/L3) have been proposed in the industry, and MPLS technology has gained its popularization in these NBVPN mechanisms, compared with ATM/FR/DDN leased line, the resources of different NBVPNs accessed to the same set of PEs are shared through multiplexing the outer label in MPLS label stack. Though the resource of the outer tunnel can be guaranteed in theory by deploying DiffServ Aware Traffic Engineering (DS-Aware TE) or other similar mechanism, in their reference models, there are no network element in individual VPN having the awareness of the whole resource status in the backbone, owing to the competition of the resources at every node between several VPNs and the ignorance of the whole resource status in the backbone, it is difficult to guarantee the resource for every VPN individually, this share-and-competition mechanism introduced more complexity in assurance of quality of service for VPN. In [draft-martini-l2circuit-trans-mpls-10.txt], [draft-martini-l2circuit-encap-mpls-04.txt], which are the basis of the L2VPN, as to QoS problem, "QoS related issues are not discussed in this draft" are stated in both drafts, and in [draft-ietf-l3vpn-rfc2547bis-01.txt], which is basis of BGP/MPLS VPN, it stated that "existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header", but it is embarrassed that existing L3 QoS is intractable open problem. In other words, QoS problem in L2VPN/L3VPN reference model is far from resolved. Table of Contents 1. Status of this Memo.............................................1 2. Abstract........................................................1 3. Conventions.....................................................1 4. Definition .....................................................3 5. Mechanism ......................................................4 5.1. Key Points...................................................5 5.2. Architecture of Reference Model..............................6 5.3. VPN Logical Bearer Network(VPN-LBN) partition................7 5.4. VPN Centralized Resources Controller (VPN-CRC)...............8 Defeng Li. [Page 2] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 5.5. Provider Edge(PE)...........................................10 5.6. Intermediate Transit Router and Core Router.................10 5.7. Address Space...............................................10 5.8. Isolation between QoS-VPNs..................................11 5.9. Routing.....................................................11 5.10. Forwarding.................................................11 5.11. QoS-VPN Topology...........................................11 6. Interfaces and Protocols Requirements.........................12 6.1. Interface/protocol between CE and PE........................12 6.2. Interface/Protocol between VPN-CRC and PE/ITR/CR............13 6.3. Interface/Protocol between VPN-CRCs.........................13 7. Hybrid QoS-VPN ...............................................15 8. Intra-domain QoS-VPN and inter-domain QoS-VPN.................15 9. QoS-VPN across different network providers....................16 10. Security Consideration .......................................16 11. Full Copyright Statement......................................16 12. References....................................................17 13. Authors' Addresses...........................................17 4. Definition QoS-VPN: VPN with QoS requirements (limits of bandwidth, delay, jitter, packet loss) between two or more of its sites, for the VPN in which some sites have QoS requirements, and other sites have no QoS requirements, it can be called hybrid QoS-VPN. VPN-LBN: The set of the resources planned in advance and singled out from the underlying IP network by connecting a part of network element( including PEs, ITRs, CRs) with LSP to exclusively bear QoS-VPN services, it is an overlay logical bearer network. VPN-CRC: The centralized entity in a domain which is responsible for intra-domain resource calculation, path selection, admission control, and inter-domain services request, network topology, QoS-VPN membership and visiting relationship information maintenance and auto-discovery, signalling, and so on. Normally it is decoupled with the forwarding network elements such as PE, ITR, CR. ITR: The provider routers apart from PE and at the border of a domain which participate in the partition of VPN-LBN, which is connected with CR or PE through LSP, ITR should be an LSR. CR: Defeng Li. [Page 3] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 The provider routers at the core of a domain which participate in the partition of VPN-LBN, which is connected with ITR or PE through LSP, CR should be an LSR. VPN-ID: The globally unique parameter in VPN-LBN to identify the information of different QoS-VPN in PE and VPN-CRC. Site-ID: The unique parameter in the QoS-VPN scope to identify the different sites. QoS-path information table: The information table maintained in PE, consists QoS-path information for the local site (directly connected with PE) to the remote sites with QoS requirements in the same QoS-VPN, this table is two-leveled, first level is indexed with VPN-ID, the second level is indexed with the local site ID and the remote site ID, for every couple of local site and remote site, the contents in the QoS-path information table is the MPLS label stack instructed by VPN-CRC to denote the concatenated LSP through which QoS requirements of services from local site to remote site can be guaranteed. In addition, the VPN addresses (VPN-ID + private addresses belong to the respective VPN) are attached to every remote site ID, these VPN addressed are used to decide whether admit the specific service flow from the local site to the remote site. QoS-VPN membership information table: The information table maintained in VPN-CRC, consists of the members of the same QoS-VPN, this table is indexed with VPN-ID. QoS-VPN visiting relationship information table: The information table maintained in VPN?CRC, consists of the visiting relationships among the members of QoS-VPN, i.e. which site can visit other sites, this table can derive from the membership information table and Route Targets of the sites. This table is on the basis of per QoS-VPN, and indexed with VPN-ID. If the export Route Target of a site is identical to the import Route Target of the other site in the same QoS-VPN, then these two sites have visiting relationship. 5. Mechanism I propose to modify the architecture of the VPN reference model, introduce some concepts, such as VPN Logical Bearer Network (VPN-LBN), which is pre-provisioned through MPLS technology by Defeng Li. [Page 4] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 singling out part of resources in the underlying IP network for QoS-VPN to use exclusively, add some controlling elements to the current VPN reference model, such as VPN Centralized resource controller(VPN-CRC) maintaining the topology and resource table separately for VPN-LBN and membership information and visiting relationship information per QoS-VPN. 5.1. Key Points (1) The NBVPN service requiring QoS guarantee is categorized as a particular service class, temporarily called QoS-VPN service, and such NBVPN is called QoS-VPN. Network operator should identify these QoS-VPNs before accessing them, the simplest way (of course not limited to it) is to identify the interface or sub-interface accessing VPN sites with QoS requirements at PE and services from these interface (sub-interface) are sorted as QoS-VPN service, and network operator needs to plan the capacity of QoS-VPN service including topology, path, bandwidth, etc, for QoS-VPN service to use exclusively, considering the current and forecasted QoS-VPN traffic. (2) According to the results of capacity planning, MPLS technology is deployed to pre-provision a logical bearer network (LBN) for QoS-VPN service to use exclusively over the underlying IP network by LSP configuration with resource reservation. And this LBN is called VPN-LBN, it is an overlay logical network. For service flows belonging to QoS?VPN service, the path selection, resource allocation, admission control and label forwarding are handled only within VPN-LBN. The service traffic of VPNs without QoS requirements are still routed and forwarded according to the existing VPN mechanisms within the un-pre-provisioned resources of the underlying IP network. (3) A centralized resource controller in every domain of the VPN-LBN is deployed to maintain the topology and resource table separately for VPN-LBN, and this function entity is temporarily called VPN-CRC, normally, it is decoupled with the data plane network elements. VPN-CRC is responsible for resource calculation, admission control, resource allocation, path selection between VPN sites, and instructs the MPLS label stack (signifies the selected path, i.e. the concatenated LSP through which QoS requirements can be met), and it maintains the membership information and visiting relationship information and processed the necessary signaling at per QoS-VPN level. (4) MPLS TE technology can be deployed to dynamically adjust Defeng Li. [Page 5] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 VPN-LBN topology and bandwidth for LSP protection or capacity changes of VPN-LBN. (5) In every QoS-VPN, though the paths of all its traffic between two sites are all the same, the service traffic can be categorized into different classes, such as voice, video, data, traffic class can be identified and marked with different priority at ingress PE, when these traffic classed with different priorities are encapsulated in MPLS packets at PE, mapping the priority to EXP bits of all the labels in the label stack(instructed by VPN-CRC) is performed (this is done for the reason that in the case of POP the outer label, the pen?outmost label has the same EXP bits, which can guarantee the same forwarding priority under the MPLS-DiffServ mechanism), thus after VPN-CRC decided the path and guaranteed the bandwidth for QoS-VPN between two sites, different classes of traffic between these two sites can be forwarded with MPLS-DiffServ mechanism, which can guarantee the time delay/jitter/packet loss requirements for different traffic classes. (6) For Hybrid QoS-VPN, it can be classified into two parts, one part is composed of the sites with QoS requirements, this the above-mentioned mechanism applies to this part, the other part is composed of the remaining sites of VPN, which follows the existing VPN mechanisms. 5.2. Architecture of Reference Model The QoS-VPN architecture is divided into two layers: VPN bearer layer, VPN bearer control layer. VPN-LBN is pre-provisioned with MPLS technology by configuring the bandwidth reserved LSPs, which connect the Provider Edge(PE), Core Router(CR), Intermediate Router(ITR) according to the capacity planning in advance, and VPN-LBN is composed of PE,CR,ITR and the LSPs. VPN bearer control layer consists of VPN-CRCs, one for each VPN domain (temporarily without considering the VPN-CRC backup). VPN-CRC manages the network resources (including bandwidth, processor, and buffer) of VPN-LBN and maintains the VPN-LBN network topology, performs path selection and then sends path information instruction to PE, resource allocation, admission control within VPN-LBN, and maintains the membership information table, visiting relationship information table at per QoS-VPN level, and related signalling to achieve the membership auto-discovery and Defeng Li. [Page 6] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 single-sided provisioning. 5.3. VPN Logical Bearer Network(VPN-LBN) partition To strictly ensure reliable transmission of the QoS-VPN network, it is necessary to separate QoS?VPN traffic from the best effort traffic (VPN service or internet service without QoS requirements) on the resource allocation and routing aspect, so that the resources of QoS-VPN are allocated within the pre-provisioned VPN-LBN and explicit paths are selected by VPN-CRCs. Whereas, the best effort VPN traffic are still routed and forwarded within the remaining resource of the IP network following conventional VPN mechanisms. VPN-LBN consists of PE, ITR, CR and LSPs connecting these LSRs. The LSP bandwidth and other QoS attributes are configured. The LSPs may be statically configured or automatically set up with RSVP-TE/CR-LDP according to capacity planning and traffic metering data. For LSP protection or capacity change, MPLS TE can be deployed to dynamically adjust and maintain the VPN-LBN topology and bandwidth by applying such as LSP fast reroute technology and etc. When QoS-VPN services request from the local site to the remote site is passed from ingress PE to VPN-CRC, the corresponding QoS requirements will attached to the services request according to the SLA between customer and provider, VPN-CRC(if necessary together with other VPN-CRCs in the VPN Bearer Control layer) decides whether to permit the request or not, If permits the request , it computes the path which can guarantee the QoS requirements, and sends the path information to the ingress PE. The path information is the label stack represents the concatenated LSPs from ingress PE(connected with the local site) to the egress PE(connected with the remote site) within VPN-LBN, the ingress PE should record this path information, including the QoS-VPN(through VPN-ID) and the sites couple(through Site ID) , and all the services belong to this QoS-VPN and sites couple will follow the same path unless the ingress PE received the otherwise instruction. Ingress PE identify QoS-VPN from the relevant information, say, the interface(sub-interface),when a QoS-VPN service flow enters the network, the ingress PE identifies its traffic from the flow description information (generally including source address, source port, destination address, destination port, and protocol type). Defeng Li. [Page 7] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 And then it encapsulates the packet/frame with the label stack instructed by VPN-CRC, sets the different EXP bits for all the labels in the label stack for different data types (Voice/Video/ Data) following RFC 3270 and leads the packets into the VPN-LBN When the traffic transits across the intermediate transit routers £šITR£© along its path, these ITRs forward its packets with DiffServ-aware MPLS technology . 5.4. VPN Centralized Resources Controller (VPN-CRC) The VPN bearer control layer consists of VPN-CRCs in multiple VPN domains. It serves as a control and management plane for VPN logical bearer layer. A VPN-CRC should have such functions as intra-domain resource calculation, path selection, admission control, and inter-domain resource request, network topology, QoS-VPN membership information maintenance, visiting relationship information maintenance and auto-discovery, single-sided provision signalling. In addition, a VPN-CRC may also support policy management, SLA management, LSP traffic metering, and interface with authentication servers (if necessary). In the VPN-CRC, the topology and resource table of VPN-LBN are recorded and maintained independently from that of the underlying IP network. It means that VPN-LBN has an independent table on the VPN-CRC. The initial resource data of VPN-LBN needs to be manually configured by administrator according to its capacity planning results. A VPN-CRC receives services requests (include information such as VPN ID, local site ID, export Route target of local site, remote site ID, QoS requirements) from the ingress PE within its administrative domain or the resource request from other VPN-CRC. It performs resource calculation, path selection and admission control (if necessary, pass the resource request to the downstream VPN-CRC), if the admission response is "reject", sends it back to ingress PE, otherwise, sends the path information to the ingress PE, where setting the EXP of the MPLS labels according to the flow description of the service flow from CE to PE. The QoS-VPN traffic from this local site to the remote site is forwarded following the computed path, and different types of traffic in the same direction are distinguished from EXP of the outer label and forwarded following the MPLS-DiffServ mechanism. VPN-CRC needs to maintain the membership information for all the QoS-VPNs in the VPN-LBN, this can be achieved through directory Defeng Li. [Page 8] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 based mechanisms or other similar signalling among PEs and VPN-CRCs. This signalling requirement is depicted in Section 6. To maintain and transfer the visiting relationship information per QoS-VPN, VPN-CRC needs to maintain the visiting relation between QoS-VPN members, i.e. the topology of QoS-VPN sites, this can be achieved by (of course not limited to) recording two site lists per sites per QoS-VPN, an admissible outgoing site list and an admissible incoming site list. To support auto-discovery of modification to the membership and visiting relationship in QoS-VPN, in case of the addition or removal of sites to a PE in QoS-VPN, the related update message should transfer between PE and VPN-CRC, then related VPN-CRC should update the membership information table and visiting relationship information table. By implementing this mechanism, the single-sided provisioning can be achieved, i.e. in the case of QoS-VPN sites addition or removal, only the configuration to the PE where the addition or removal of sites happens, and in the case of modification to the visiting relationship among the VPN members, only one side of the connection to which the modification happens needs to be configured, and the modification will automatically pass to all the related VPN?CRCs by membership update message and visiting relationship update message, And VPN?CRCs received the update message will update its membership and visiting relationship information table. In the case of addition of QoS-VPN sites, the services request (include information such as VPN-ID, local site ID, export Route target of local site, remote site ID, QoS requirements) will pass to VPN?CRCs, VPN-CRCs will calculate the resources for the added sites to visit the other sites as desired, if such QoS-VPN sites addition is permitted, the paths as to the added sites visiting the different remote sites will be calculated, then instructed the paths to the related PEs, these PEs should update their QoS-path information table, when the remote PEs aware the sites additions through the single-sided provisioning signalling passed by VPN-CRC, they should initiate the contra-direction services requests for their local sites to visit the added new sites, then the same process will be performed, at last, all the sites gets its QoS-path information as to visiting each other. In the case of removal, VPN-CRCs release the resources for the paths relevant to the removed sites, besides update the membership information table and visiting relationship information table, and notify the related PEs to remove the related entries and items in the QoS-path information table, when the remote PEs aware the sites removals, the resources for the contra-direction between the Defeng Li. [Page 9] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 related sites will be released by the related VPN-CRC, The protocol requirement to achieve such single-sided provisioning is depicted in Section 6. 5.5. Provider Edge(PE) In this architecture, PE should support static LSP configuration or dynamic LSP setup through CR?LDP or RSVP-TE in order to implement the pre-provision and dynamic adjustment of VPN?LBN. In addition, traffic classification should be supported in order to set the EXP bits of the labels in the label stacks. When receiving the admission control response from VPN-CRC, if the response of resource calculation is "acceptance", the path and QoS information should be included, the ingress PE creates an entry in the QoS-path information table to record these information, ingress PE maintains the entries on per QoS-VPN basis by the index of VPN-ID, and in every QoS-VPN entry, keeps every item for the service from a local site to a remote site of the same QoS-VPN. According to the QoS-path information table and the traffic class, Ingress PE performs policing, shaping, queuing, scheduling, marking, and MPLS encapsulating(adding the MPLS label stack and setting the EXP bits), then forwards packets to the downstream routers within VPN-LBN. 5.6. Intermediate Transit Router and Core Router In this architecture, Intermediate transit routers should support static LSP configuration or dynamic LSP setup through CR-LDP or RSVP-TE in order to implement the pre-provision and dynamic adjustment of VPN-LBN. And they should support DiffServ-aware MPLS in E-LSP or L-LSP mode and process the traffic at a per-class level. Other core routers in the IP-based backbone network only need supporting DiffServ-aware MPLS in E-LSP or L-LSP mode and process the traffic at a per-class level. 5.7. Address Space VPN address can be composed of globally unique VPN-ID in VPN-LBN and L3/L2/L1 VPN specific private address, such as IPv4/IPv6/IPX address (for L3 VPN)/data link address(for L2 VPN)/cross-connect identifier(for L1 VPN) of VPN site for the particular VPN, in this VPN address scheme, the addresses for sites in the different VPN can be the overlapped, with the globally unique VPN-ID in VPN-LBN, the combined VPN address will be unique globally in VPN-LBN. Defeng Li. [Page 10] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 5.8. Isolation between QoS-VPNs QoS-path information table is two-leveled, first level is indexed with VPN-ID, and the second level is indexed with the site-ID, the information between VPNs can be isolated by this way. 5.9. Routing The QoS-VPN routing is maintained in the QoS-path information table of PE, the granularity is at per QoS-VPN site couple, i.e., the services from the same local QoS-VPN site to the same remote QoS-VPN site have the same route. The route search is two leveled at the ingress PE, at first level, VPN-ID is indexed and searched in the entries for different QoS-VPN, at the second level, the items for the local site and remote site couples in the same QoS-VPN are searched. It should be noted that for every such item, the aggregated addresses of the related site is attached, only the destination address of the service flow matches to the aggregated addresses, the second level search can be thought as success, only after both levels search succeed, ingress PE can assign the route information for this service flow, the route information is the MPLS label stack instructed by VPN?CRC according the resource status in VPN-LBN, if one of the two levels search fails, PE will reject the service flow. 5.10. Forwarding QoS-VPN forwarding is based on MPLS technology, with the MPLS label stack instructed by VPN-CRC and EXP bits set by ingress PE for the different service class, the LSR (including PE, ITR, CR) forwards the packets based on the outer-most label, and the EXP bits following the MPLS-DiffServ mechanism, with these information, the bandwidth and forwarding priority can be ensured, then the QoS(such as bandwidth, time delay, jitter, packet loss rate) for QoS-VPN can be guaranteed. 5.11. QoS-VPN Topology QoS-VPN visiting relationship information is maintained at VPN-CRC, VPN-ID and Route Target can be used to create the visiting relationship information table, VPN-ID is used as the index for different QoS-VPN, Route Target is classified into import Route Target and export Route Target, the former is used to filter visiting relationship in the incoming direction, the latter is used to filter visiting relationship in the outgoing direction, which is Defeng Li. [Page 11] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 attached to the services request from one VPN site to the remote VPN site, if the export route target and VPN-ID of the services request egress PE received is the same with one of the import route targets and VPN-ID for one of sites directly connected to this PE respectively , the services request can be accepted, and record this item in the visiting relationship information table for this QoS-VPN, with the visiting relationship information table, the topology of QoS-VPN sites can be achieved. Such as full-meshed, hub-spoke or any other topology can be provided by such QoS-VPN mechanism. 6. Interfaces and Protocols Requirements In this architecture of QoS-guaranteed MPLS-based NBVPN with centralized resource controller, the interfaces between PE and CE, VPN-CRC and provider routers (including PE,ITR, CR), VPN?CRC and VPN-CRC and the related protocols need be specified. 6.1. Interface/protocol between CE and PE Interface between PE and CE is used to pass the customer information such as topology, aggregated private address, e.g. private IPv4/IPv6/IPX address (for L3 VPN)/data link address(for L2 VPN)/cross-connect identifier(for L1 VPN) of VPN site behind CE and VPN service request (including flow description) to PE¡£ It is noted that for the privacy of address information (including L1/L2/L3 address in the VPN sites) and consideration of address overlap between different QoS-VPN, it is proposed that network provider assign a network-wide unique VPN-ID for every QoS-VPN, this VPN-ID is prefixed by PEs to these addresses received from CEs, and the VPN address is derived, and this VPN-ID can be used as the index to maintain the membership information table in VPN-CRC. 6.2. Interface/Protocol between VPN-CRC and PE/ITR/CR Interface between VPN-CRC and PE is used to allow the VPN-CRC to instruct PE to process the traffic at a per-site level. It is necessary to specify a unique protocol for this interface. COPS may be a good candidate protocol as the basis to be extended for this architecture to use. This protocol should support the following functions. (1) Ingress PE sends the services request (include information such Defeng Li. [Page 12] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 as VPN ID, local site ID, export Route target of local site, remote site ID, QoS requirements) to VPN-CRC, QoS requirements of each service classes include service type, bandwidth, priority, delay limit, jitter limit, loss rate limit, MTU, etc. on per QoS-VPN site basis according to the SLA between customers and provider. (2) VPN-CRC checks whether there is the visiting relationship from the local site to the remote site (thus VPN-CRC should transfer the necessary information to the related VPN-CRCs and PEs), then decide whether it is necessary to compute the path for this services request, and informs the ingress PE the result of admission control as to the QoS-VPN, no matter it is "rejection" or "acceptance". (3) VPN-CRC informs the ingress PE the path information for this site couple, when the result of admission control is "acceptance", the path information is a label stack for a concatenated LSP, PE creates an entry recording such path information on per site couple and QoS-VPN basis in the QoS path information table. (4) In case of the addition or removal of sites to a particular QoS-VPN, or modification of the visiting relationship between these VPN sites, PEs where the change happens (through configuration) should send the update message to the connected VPN-CRC. VPN-CRC passes this update message to the adjacent VPN-CRC(if necessary) through the interface between these VPN-CRC(the interface and protocol between VPN-CRCs is defined in section 6.3), and the VPN-CRCs influenced should update the membership information table and visiting relationship information table of the QoS-VPN. (5) PE sends all the aggregated VPN addresses information to VPN-CRC, and VPN-CRC distributes these VPN addresses to the related VPN-CRCs or PEs according to the membership information table and visiting relationship information table per QoS-VPN. These functions can be achieved by extending the current BGP. At last, all the PEs get the aggregated VPN addresses, recording them in the QoS-path information table per QoS?VPN per remote site with visiting relationship, when PE receives the VPN service flow, it can decide whether to transfer it , and then select the path and set the EXP bits of packets. Moreover, the following two functions should be supported between VPN-CRC and all intra?domain routers including provider edge routers(PE), intermediate transit routers(ITR) and core routers(CR). (1) Enable VPN-CRC to configure the DiffServ PHB on the router for each QoS service classes. Defeng Li. [Page 13] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 (2) Enable the routers (PE/ITR/CR) to report the LSP status such as normal or failure, in case that link or router failure occurs to the intermediate transit router and core router, this router should pass the relevant failure to VPN-CRC in the same domain, this VPN-CRC passes this failure to all the VPN-CRCs in VPN-LBN, these VPN-CRCs recalculate the paths for the QoS-VPNs they have already served, if some paths need be updated, VPN-CRC should send the new paths to ingress PEs which VPN-CRC connected with. This belongs to MPLS OAM mechanism, which is out of the scope of this document. 6.3. Interface/Protocol between VPN-CRCs Interface between VPN-CRCs is used to implement the resource allocation and path selection for services between inter-domain QoS-VPN sites. It is necessary to specify a unique protocol for this interface. There are a number of candidate protocols that could be chosen, such as COPS, BGP and so on. This protocol must support the following functions. (1) Enable VPN-CRC to request downstream VPN-CRC to allocate the bearer resource for services between inter-domain QoS-VPN sites. (2) Enable VPN-CRC to inform downstream VPN-CRC of the identification information of services between inter-domain VPN sites including the local site ID, the remote site ID, VPN-ID. (3) Enable VPN-CRC to inform downstream VPN-CRC of the QoS requirements of services between inter-domain VPN sites including service type, bandwidth, priority, delay limit, jitter limit, loss rate limit, MTU, etc . (4) Enable VPN-CRC to request another VPN-CRC to release the bearer resource allocated for services between inter-domain QoS-VPN sites. (5) Enable VPN-CRC to query another VPN-CRC of the resource allocation status for services between inter-domain QoS-VPN sites. (6) Enable VPN-CRC to inform another VPN-CRC of the responses of the query. (7) Enable VPN-CRC to exchange inter-domain SLS and route Defeng Li. [Page 14] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 information with another VPN-CRC. 7. Hybrid QoS-VPN In some cases, some sites of a VPN have QoS requirements, and other sites have no QoS requirements, this VPN is called hybrid QoS-VPN, hybrid QoS-VPN can be partitioned into two parts, one part is composed of those sites which have QoS requirements, the other part is composed of the remained sites which have no QoS requirements, the former part formed a sub-QoS-VPN, whose QoS requirements can be guaranteed following the mechanism specified above, the latter part formed another sub-VPN, which follows the mechanism specified in the related RFC or Drafts in IETF L3VPN/L2VPN WG and ITU-T recommendations for L1VPN(Y.l1vpnarch and Y.l1vpnsdr). Correspondingly, QoS Route Targets is introduced for the VPN-CRC to maintain the visiting relationship information for the sub-QoS-VPN, QoS Route Targets follows the same format with Route Targets, for the services request from the sites with QoS requirements, after Route Targets comparison passed, QoS Route Targets of the will be compared following the same method, only both of them passed the comparison, the visiting will be permitted for sub-QoS-VPN, otherwise the services will classified into sub-VPN, which has no QoS guarantee. 8. Intra-domain QoS-VPN and inter-domain QoS-VPN Intra-domain QoS-VPN path selection and inter-domain routing are the basis of resource management and admission control. The VPN-CRC makes the intra-domain path selection through resource calculation within the topology and resource table of VPN-CRC. The path selection algorithms might be fixed, time?dependent or state-dependent. It need further study and experiment in different network environment. Besides, the VPN-CRC should maintain an inter-domain routing table that is only used to find out the neighbouring downstream VPN-CRC for services destined to inter-domain sites. Then it negotiates with the neighbouring downstream VPN-CRC through a QoS signalling protocol to determine an inter-domain LSP. The inter-domain routing table on VPN-CRC might be manually configured or automatically generated through running a dynamic routing protocol between VPN-CRCs such as E-BGP or others. It need further study and experiment in different network environment. Defeng Li. [Page 15] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 9. QoS-VPN across different network providers In order to support QoS-VPN services across multiple provider networks, the ASBRs of different network providers must interwork to transfer the VPN services request signalling and VPN traffic. If both network operators deployed the VPN-CRCs, their VPN-CRCs can be interworked, these VPN-CRCs only exchange and map the inter-network SLA. In this case, VPN-CRCs only manage the intra-network link resources, ASBRs manage the inter-network link resources by the specified SLAs, perform the function of the Ingress PE in the intra-provider case. If one of network providers doesn't deploy VPN-CRC and deploy other QoS mechanism for VPN, the two ASBRs should map the QoS requirements to each other, then the degree to guarantee the QoS of VPN across these two network providers depends on the mechanisms of the other network providers. This needs for further study. 10. Security Consideration It needs further study. 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Defeng Li. [Page 16] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. References [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". draft-ietf-ppvpn- rfc2547bis-04.txt, Work in Progress, May 2003. [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. January 2001. [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto- 05.txt, Work in Progress, May 2003. [VPLS-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging-vpls- 00.txt, Work in Progress, June 2002. [L2VPN-SIG] "LDP-based Signaling for L2VPNs", draft-rosen-ppvpn-l2- signaling-03.txt, Work in Progress, May 2003. [L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work in Progress, February 2003. [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements- 00.txt, Work in Progress, May 2003. 13. Authors' Addresses Defeng Li Huawei Technologies Email: lidefeng@huawei.com Defeng Li. [Page 17] Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004