Loading ...
Global Do...
News & Politics
18
0
Try Now
Log In
Pricing
Claranet Service Description VPN:ng Version 1.1 Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 1 Introduction This document is copyright Claranet Ltd. and is for internal use and customer distribution. The purpose of this document is to provide a reference guide to the processes and procedures Claranet employ when supplying the VPN:ng service. This description of service describes Claranet’s duties, obligations and responsibilities related to the installation and management of VPN:ng services described herein and some of the customer's responsibilities. This description of service is not a service level agreement. Definitions Access service is a link or connection between a customer’s site and the Claranet network. An example of a access service would include an ADSL connection or a Leased Line connection SOW is the Statement of Work, a Claranet document used to capture customer specific requirements for the implementation of the customer’s service. Abbreviations MPLS - Multi Protocol Label Switching VPN – Virtual Private Network DLCI – Data Link Connection Identifier VLAN – Virtual Local Area Network CPE – Customer Premises Equipment MTU – Maximum Transmission Unit D/F – Do not Fragment unit PVC – Permanent Virtual Circuit WRED – Weighted Random Early Detection CDR – Committed Data Rate Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 2 Scope of Services This Service Description is provided by Claranet (or subsidiary company) and applies specifically to the VPN:ng service, including all Managed devices and value added services fully managed by Claranet. Service Overview Claranet VPN:ng is a Virtual Private Network service available across Claranet’s International MPLS backbone. This solution provides customers with a private network with any-to-any connectivity at IP layer 3. In addition, customers can purchase Value Added Services such as Secure Internet Access through a managed Firewall. Claranet VPN:ng provides physical connectivity to the Claranet MPLS backbone with logical private connectivity to one or many private VPNs using ADSL, SDSL, Point to Point and Ethernet Access services. Layer 3 IPv4 VPNs by default provide any-to-any connectivity between Customer Premises Equipment (CPE) nodes, but on request can be provisioned in a hub-and-spoke model. Virtual Private Networking between customer sites The primary function of the VPN:ng service is to provide the customer a private networking service connecting the customer’s sites together to enable IP based applications and services to communicate. The network is private as it is logically separated from other VPN:ng services provided in the Claranet network, allowing customers to define how the IP addressing and routing should work within the network. The network is Virtual as many customers are able to take advantage of the Claranet International core network infrastructure rather than build their own dedicated network. The VPN is technically enabled by using Virtual Routing instances on the provider edge of Claranet’s network, and using MPLS labelling within the core of Claranet’s network. Claranet can connect customer sites into this private network using access services such as ADSL or Leased Lines. Claranet will only support access service connections purchased through Claranet to connect into the VPN:ng private network. VPN default route Claranet is able to configure a default route within the customers VPN, allowing access to IP networks outside of the realm of the VPN. The most common use for a default route is to provide Internet access to the sites in the VPN. The VPN default route can be used in conjunction with an Internet Breakout service, where Claranet provide a gateway to the Internet, protected with a Managed Firewall generally located either at the customer’s main office or in a Claranet data centre. Service Restrictions The Maximum Transmission Unit (MTU) supported by the Claranet network for IPv4 traffic is 1500 bytes. Claranet may advise on a lower Maximum MTU dependant on the Access service used. All packets transmitted greater than the Max MTU will be fragmented. Packets sent with the D/F bit flagged shall be discarded at ingress to the Claranet network. Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 3 VPN:ng must always be purchased with at least 2 compatible Claranet supplied access services and generally with one or many ClaraCare Managed Router services. Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 4 Claranet Responsibilities Design Claranet offer a comprehensive Solution Design service as standard for all prospective VPN:ng customers. Claranet Sales will discuss with the customer their Business and Technical requirements, and in conjunction with a Claranet Pre-Sales engineer will design a VPN:ng Solution. Claranet will deliver a a detailed description of the technical design including a network diagram and statement of works. The VPN:ng standard design service uses information from the customer as the primary influence to the proposed solution. If the customer is unsure what their current and/or future Business and Technical requirements, Claranet can offer an optional Design consultancy service. Installation and Setup Using the information provided in the Design documentation, a team of Technical and Administrative staff will implement the VPN. Orders will be placed for Access circuits and hardware, and the Technical team will build on the Design documentation with additional technical information about the solution. Claranet is able to offer time measured implementation targets and guarantees on certain Access services. Please refer to the VPN:ng Service Level Agreement (SLA) for details of Implementation targets and guarantees. Testing Claranet test various aspects of the VPN:ng solution to ensure consistent performance from day one. The customer is asked to agree that the service has been delivered to their satisfaction before the network is handed over to the Claranet Support department to maintain thereafter. Claranet will provide a Hand Over document at this stage detailing the Solution, and how the customer should contact Claranet in the future. Ongoing Management Support & Configuration changes Support for the VPN:ng solution as a whole is provided on a 24/7 basis by the Claranet Corporate Support and Network Operation Centre. Customers should note that the level of support provided on each access service that connects in to the VPN:ng solution is detailed in the service description for that access service. Monitoring Claranet will monitor, maintain and pro-actively react to outages or detected degradation in the VPN:ng core network. Claranet’s network management platform regularly probes the VPN:ng core network for continuity and usage information. This data is processed by a logic engine that will trigger an alert if an outage has been detected. Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 5 The Claranet support department will react to these alerts by investigating the cause and alerting the customer of the situation if it affects their service. Once the fault is resolved, the customer will be contacted for a final time to close the fault and discuss any further consequences that may be involved. Claranet is also able to monitor the individual access services that connect in to a VPN:ng solution. Information on what monitoring Claranet will do is available in the ClaraCare Managed Router Service Description. Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 6 Customer Responsibilities Design At the design phase it is the Customer’s responsibility to ensure Claranet has the correct site address, contact and technical information for the proposed VPN:ng solution. Although changes can generally be made during installation, delays and additional costs may be incurred. Installation Installation of the VPN:ng core network service is Claranet’s responsibility, although at various stages of the installation process Claranet may require clarification on some technical details which it is the customer’s responsibility to promptly provide. Details on the customer’s responsibilities regarding installation of the various access services that connect in to the VPN:ng solution are available in the service descriptions for the access services and the Managed Router service description Ongoing Management Support & Configuration changes In the event of a service outage, it is the customer’s responsibility to comply with Claranet’s requests for help with diagnostics as quickly as possible. Any delay in resolving the fault due to the customer not being available or not complying with Claranet’s requests may impact the validity of the VPN:ng service level agreement (SLA) It is the customer’s responsibility to inform Claranet of any changes that are required to the VPN:ng solution as quickly as possible. Any changes agreed by Claranet that require work to be done at night will require at least 2 weeks prior notice. Adding, removing or changing access services that connect the customer’s sites to the VPN:ng solution are subject to restrictions detailed in the service descriptions for those access services. Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 7 Optional Services The following optional services are available to all VPN;ng customers. These services are charged on a time and materials basis and may also result in an increase in the monthly service fees. Project Managed Implementation As an optional chargeable service, Claranet can instruct a named Project Manager to Implement the VPN:ng solution. The Project Management service is recommended for large or complex VPNs, or where the VPN Implementation timeframe is a critical Business need of the customer. Claranet Project Managers are certified with either PRINCE2 or Association of Project Managers (APM) accreditations, and use tried and tested plans and documentation templates to customise for each VPN:ng implementation. Quality of Service Quality of Service (QoS) is a data traffic classification and prioritisation features available on most Claranet access services. Quality of Service has two main functions; one is to identify and classify the IP data by application; the other is to prioritise certain application classes over others if the connectivity service becomes congested. QoS is enabled on the connectivity link between the equipment located at the Customer site (customer premises equipment - CPE) and the equipment at the associated edge of Claranet’s network (Provider Edge – PE). Quality of Service offers guarantees that the data traffic classified and prioritised at the edge of the network is transported over the Access service and Claranet Core within a defined set of quality performance metrics. Claranet control the performance of the Core Network through a combination of capacity management and congestion management techniques. QoS SLA performance metrics are Customer Site to Customer Site, based on a combination of the performance guarantees of the connectivity services used to connect the Site to the Claranet Core, and the performance guarantees for within the Claranet Core. If a connectivity service does not have performance guarantees (for example a contended DSL service), QoS is not available for that link. QoS is available only when a compatible CPE is provided by Claranet or a VPN:ng accredited partner, and where the connectivity service itself support QoS. Quality of Service is also only available where the access service has network performance guarantees. QoS Class Definition Claranet Quality of Service offers up to six levels of application classification. In some circumstances (such as very high capacity links, or very complex networks) all six Classes will be used, but in majority of cases no more than 3 separate Classes are needed. The table below illustrates the Classes available: Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 8 Application Classes Queuing technique Example Application Gold Low Latency Queue Voice over IP Silver-1 Class Based Weighted Fair Queue Citrix Silver-2 EPOS Silver-3 Intranet Silver-4 Internal Messaging Bronze (default) Weighted Fair Queuing Internet Access Gold The ‘Gold’ queue is a strict priority queue designed specifically for real-time voice and video applications. The purpose of a strict priority queue is that while the flow of data in question remains within pre-defined limit of bandwidth, no other traffic on the same link can affect the flow of the priority queue. All Gold data above the configured committed data rate (CDR) for this queue will be dropped. It is very important that enough bandwidth is allocated to Gold, as dropping data from this application class will be highly detrimental to the real time applications that use this class. Silver The ‘Silver’ queue is a group of prioritised queues making use of Class Based Weighted Fair Queuing and Weighted Random Early Detection (WRED) congestion management techniques. This queue is prioritised above ‘Bronze’ and designed for non real-time business critical applications. The ‘Silver’ queues will not drop traffic above the Committed Data Rate, instead it will be allowed to burst down into any remaining bandwidth that might be available within ‘Bronze’ queues, with the consequence that it will tagged as Bronze traffic. If only one Silver Queue is configured, it will be given priority over the Bronze queue. If more than one ‘Silver’ queue is configured, each ‘Silver’ queue is given a priority weighting against the other ‘Silver’ queues within the bandwidth allocated for all ‘Silver’ queues. The weighting used to determine how much bandwidth is available for each Silver Class is calculated based on a ratio of the total bandwidth allocated to Silver and the level of Silver used. For example, where two Silver classes are used, classifying one application as Silver-1 and another as Silver-4 will give far greater priority to Silver-1 than if one application is classified Silver-1 and the other Silver-2. For further details on the exact ratios, please refer to Section 5.1 – CBWFQ technical details. Bronze The ‘Bronze’ queue can take advantage of the full access-link bandwidth if the Gold or Silver queues are not enabled or if there is available bandwidth not being utilized by the priority queues. Bronze also uses WRED congestion management. Allocation of Class Bandwidth with QoS Once a decision has been made on the applications that need to be prioritised, and in what Classes they should sit, bandwidth will need to be allocated to each Class. The amount of bandwidth allocated to each Class will influence the prioritisation decisions that the network will need to make if the Connectivity service were to become congested. Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 9 The following are limitations to how much bandwidth or ‘weighting’ each Class can have in a Class of Service Prioritised link. 1. It is not possible to allocate more than 75% of the link bandwidth to the Silver Classes. 2. The maximum amount of bandwidth that can be allocated to a Gold Class is 50% of the total link bandwidth. 3. The minimum amount of bandwidth that can be allocated to Gold is 100Kbps. 4. Gold bandwidth allocation must always be configured by speed symmetrically, ie. the same downstream allocation as upstream. 5. Silver bandwidth allocation can be configured asymmetrically, but the rules regarding maximum percentage allocation on a link must be honoured, in both directions. 6. Where a link has both Gold and Silver Classes configured; the combined total of the bandwidth allocated to these Classes must not exceed 75%. The remaining 25% is used for CPE management and Bronze data. 7. The Bandwidth value allocated to any Class must be based on 10Kbps increments. There is no specific bandwidth allocated to Bronze applications, although applications in this class will have less congestion management (therefore better performance) if less of the total link is allocated to the prioritised Classes. The following table summarises the above rules: Application Classes Minimum bandwidth allocation per Class Maximum bandwidth allocation per Class Maximum total allocation of link Gold 100 Kbps 50% 75% Silver-1 N/A 75% Silver-2 Silver-3 Silver-4 Bronze Not allocated Traffic Signalling Customer Application Traffic destined for either the Gold or Silver queues must be marked appropriately with either IP Precedence or DiffServ Code Point (DSCP). By default the following values will signal the traffic to be forwarded into the queues marked below: Service Description – VPN:ng Services Commercial in Confidence May 2008 Page 10 IP Precedence Value VPN Queue 5 101 Gold 4 100 Silver-1 3 011 Silver-2 2 010 Silver-3 1 001 Silver-4 0 000 Bronze Where DSCP is the chosen mechanism of QoS signalling by default the Claranet network will honour the following three coarse mechanisms of prioritisation: • Expedited Forwarding (EF) traffic will be given ‘Gold’ prioritisation. • Assured Forwarding (AF) traffic will be given ‘Silver-1’ prioritisation. • Default classification (zero) will be given ‘bronze’ prioritisation. All traffic marked with either IP precedence or DSCP values on non QoS enabled VPN tail circuits shall be remarked to zero at ingress and prioritised using the ‘Bronze’ queue. QoS Access service Compatibility In order for an access service to have full Quality of Service capability, that service must either be fully uncontended, or it must support application prioritisation backed up by a network performance service level guarantees. The following table highlights the Access service compatibility with Quality of Service (QoS) Service Type VPN:ng QoS Ethernet Point to Point Yes Full Point to Point Yes Full SDSL Yes Dependant on Vendor and Product, but generally None ADSL Yes ISDN/Dial Yes None
