* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Business Roles and Architecture to realize MUSE
Survey
Document related concepts
Computer network wikipedia , lookup
Deep packet inspection wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Distributed operating system wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Network tap wikipedia , lookup
Distributed firewall wikipedia , lookup
Airborne Networking wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Peer-to-peer wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Transcript
QoS Framework for Access Networks Govinda Rajan Lucent Technologies [email protected] Muse confidential Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 2 Muse confidential QoS in Access Networks > QoS is key in multi-service access > End-to-End QoS solutions (e.g. IntServ) • > commercially failed because of complexity Priority based QoS (e.g. Diffserv) • • works in over-provisioned networks insufficient for Access & Aggregation => Simplified QoS control in Access & Aggregation needed Access Node MUSE Summer School July 2006 — 3 Muse confidential Edge Node Ethernet Network Model bridged or routed Ethernet switch (802.1ad) Ethernet switch (S-VLAN aware or 802.1Q) BRAS or Edge Router CPN NSP/ISP CPG AEN NSP/ISP Ethernet (MPLS) aggregation network NSP/ISP AEN AN MUSE Summer School July 2006 — 4 NAP ASP Muse confidential Congestion in Ethernet Networks A1 A2 A3 A Ag1 B1 B2 B3 B En1 Ag4 Ag2 C1 C2 C All links: 1 GB > Assume all nodes have strict priority queuing & assume there are just 2 QoS priority classes. > Say, that there are 10 flows of high QoS priority of 0.1 GB each, upstream from residential gateway and 2 flows of lower QoS priority. • Link A-Ag1 is 1 GB so A allows all 10 flows and the flows of lower priority will be dropped. > Assume: Similarly B also allows 10 flows of 0.1 GB each. > There is congestion at Ag1, since incoming traffic is 2 GB & upstream link capacity is only 1 GB and eventually packets will have to be dropped and QoS is not guaranteed. MUSE Summer School July 2006 — 5 Muse confidential Potential BottleNecks in Access Networks BNAN SPA SPB BNAgN BNEN EN1 ni times bi Bo Statistical Multiplexing where bandwidth nixbi < Bo EN2 bo Bi Aggregation Node User Gateway Edge Node SPc Access Node > Ingress traffic for a egress port has higher rate than egress port: Bi > bo Because of the nature of sharing the connectivity resources, there can be potential bottlenecks Upstream & Downstream traffic at Access Nodes, Aggregation Nodes & Edge Nodes depending on the quantity & the required quality of service. MUSE Summer School July 2006 — 6 Muse confidential Call Admission Control for QoS QoS Signalling A1 A2 A3 A request for 4 high QoS class flows & 2 low QoS flows. >A signals Ag1 B1 B2 B3 >A gets Central Resource View B En1 Ag4 Ag2 C1 C2 C central resource & gets allow signal for 4 high QoS class. CRV decreases resources by 0.4. >A allows All links: 1 GB 2 flows of low QoS flows without signalling. >B >For all flows, decision of allow or block is needed from central resource view. >Strict priority queuing & 2 QoS classes. gets request for 5 flows of high QoS, gets allow for 4 & block for 1 flow. CRV resource count is now 0. >B gets request for 2 low QoS & allows them. >Central >Low >First >Additional resource is provisioned with 0.8 & 0.2 GB for 2 QoS classes respectively. Mile will be handled locally by ANs. >Central resource view is provisioned with 0.8 Gb for higher QoS and 0.2 for lower QoS. MUSE Summer School July 2006 — 7 QoS flows experience packet loss because of priority queuing at nodes. requests for high QoS flows from edge nodes are blocked by CRV until current flows are ended and signalled to CRV. Muse confidential Virtual Pipes for Multi-service Provider QoS A1 A2 A3 Virtual Pipe A Ag1 B1 B2 B3 B Ag4 En1 Ag2 C1 C2 > C SP1: A – EN1 0.2 SP2: A – EN1 0.3 SP3: B – EN1 0.3 All links: 1 GB At node A • • • • > Capacity (GB) For SP1 , 0.2 GB of flows are allowed & above that new flows are blocked For SP2 , 0.3 GB of flows are allowed & above that new flows are blocked All other QoS flows are blocked Best Effort traffic is allowed At node B • • • For SP3 , 0.3 GB of flows are allowed & above that new flows are blocked All other QoS flows are blocked Best Effort traffic is allowed MUSE Summer School July 2006 — 8 Muse confidential QoS Classes elastic = data integrity dominates elastic inelastic inelastic = temporal integrity dominates MUSE Summer School July 2006 — 9 noninteractive interactive noninteractive interactive Muse confidential Best effort class Background class (3GPP) Non-critical class (ITU) Transactional class Interactive class (3GPP) Responsive class (ITU) Streaming class Streaming class (3GPP) Timely class (ITU) Real-time class Conversational class (3GPP) Interactive class (ITU) Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 10 Muse confidential Tight QoS in ‘Application’ Model Flow based FB monitoring FB gating FB policing FB monitoring FB gating FB policing ABG Access Network Access Network IP Backbone ABG EDGE EDGE Eth. CPN B CPN A MUSE Summer School July 2006 — 11 Muse confidential Loose QoS in ‘Application’ Model Traffic Class “per Service Provider” Based control: All the traffic flows belonging to the same traffic class and served by the same SP are aggregated together and treated as a whole in the ENs. FB monitoring FB gating FB policing ABG Traffic Class Based FB monitoring FB gating FB policing TCB monitoring TCB gating TCB policing Soft switch Access Network Access Network IP Backbone ABG EDGE EDGE Eth. CPN B CPN A MUSE Summer School July 2006 — 12 Muse confidential Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 13 Muse confidential Models of Access Networks ‘Carrier’ model • • • • IMS The network just provides transport/connectivity services. The network is not application/session aware. Current best-effort Internet access model. Can be implemented by enhancing with multiple QoS conenctivity services, tailored and classified for the most prevalent group of services. ‘Application’ model • • The provisioning of an end service is controlled & guaranteed by the operator. The user requests (dynamically) for a service, and the network sets-up the most appropriate transport/connectivity service (service-based policy push). The network is application/session aware. MUSE Summer School July 2006 — 14 Muse confidential Loose QoS in ‘Carrier’ Model Traffic Class “per User” & “per SP” Based control TCB monitoring TCB gating TCB policing Traffic Class “per SP” Based control TCB monitoring TCB gating TCB policing Traffic Class “per User” & “per SP” Based control FB monitoring FB gating FB policing Soft switch ABG Access Network Access Network IP Backbone ABG EDGE EDGE Eth. CPN A Intelligent RGW: It must solve the applications contest for bandwidth according to the end user preferences and the available transport services MUSE Summer School July 2006 — 15 Muse confidential CPN B Converged QoS Model Border nodes (AN & EN) must be able to perform these tasks both at IP flow and traffic class level. Network operator’s choice of policy: Appropriate application of ‘tight’ or ‘loose’ QoS model based on specific requirements for individual access networks • Mix and match of ‘carrier’ or ‘application’ models • Soft switch AB G Access Network Access Network AB G IP Backbone EDGE EDGE Eth. CPN A CPN B Intelligen t RGW MUSE Summer School July 2006 — 16 Muse confidential Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 17 Muse confidential Need for Central View of Resource A1 A2 A3 All links: 1 GB A Ag1 B1 B2 B3 B Ag4 En1 Ag2 C1 C2 C > Virtual & B. Ag5 En2 Virtual Pipe Capacity (GB) SP1: A,B – EN1 0.4 SP2: B – EN1 0.2 SP3: C – EN2 0.1 Pipe of SP1 is 0.4 GB & total subscribers are for 1 GB, at A > To ensure that only 0.4 GB or less is allowed; for each call request, it should be checked if existing calls from both A & B are less than 0.4 GB totally. > A central view of resource is needed to share the same resource for subscribers at A & B. By resource here, it is meant a fraction of physical resource for exclusive use by SP1 subscribers at A & B. MUSE Summer School July 2006 — 18 Muse confidential Local Control of Exclusive Fraction of Resource A1 A2 A3 All links: 1 GB A Ag1 B1 B2 B3 B En1 Ag4 Ag2 C1 C2 C En2 Ag5 Virtual Pipe: SP1: A,B – EN1 (0.4GB) Node Local Quota Node A 0.1 Node B 0.2 Central Quota 0.1 Example for SP1 Virtual Pipe of 0.4 GB: > Node A is provisioned with 0.1 GB as the local threshold. New calls are allowed at A until the total calls active at A is less than 0.1 GB. If total calls active at A is equal or above 0.1 GB, new call requests are signaled to a central resource control for admission decision. > Node B is provisioned with 0.2 GB as the local threshold. New calls are allowed at B until total calls active at B is less than 0.2 GB. If total calls active at B is equal or above 0.2 GB, new call requests are signaled to a central resource control for admission decision. > In this example, Node B has local control of a larger fraction of the total resource since it is assumed that there are more subscribers at Node B than at Node A. The central resource control is used to share a certain fraction of the total resource between A & B. MUSE Summer School July 2006 — 19 Muse confidential Distributed Call Admission Control Step 1 User requests service (eg. TV) AN 1 CPE 2 Step 2 1.If subscriber policy is in agreement Policy Agent •Allotted Quota •Un-allotted Quota •Subscribed BN IP addresses •Subscriber’s Policy •IP adds of other SNs 2.If required QoS can be serviced within allotted quota 3.Then call is admitted Super Node Subscriber Management Server Policy Server 3 3 Network Management System Step 3 1.If required QoS cannot be serviced within allotted quota 2.Then bandwidth reserved in unallotted quota and confirmation requested from BNs subscribed to that un-allotted quota. 3.On confirmation from all subscribed BNs, call is admitted otherwise call not admitted. AN AN EN EN Virtual Network (Control Plane) AN MUSE Summer School July 2006 — 20 Central Resource Database (Not Needed) Muse confidential Distributed Call Admission Control Centralized subscriber and QoS policy system is distributed in a few Super Nodes, which are used to configure and push necessary policy data to the Border Nodes (ANs & ENs). A virtual control network is created between the Super Nodes & the Border Nodes. Some aspects of the local resource quota for a distributed resource system are as follows: • • • • • A portion of quota that is controlled exclusively by that Border Node. A pool of unallocated quota and the IP addresses of Border Nodes that are allowed to use the pool. IP address of Border Nodes (for requesting quota). Information of quota that is reserved for future use (at a certain time & for a certain time period) and IP addresses of reserving Border Nodes. Quotas have a valid time period, in the sense they have to be synchronized after that time period. Usage of unallocated resource is done only after requesting all relevant Border Nodes and getting confirmation, to fore come that multiple usage. If there is no confirmation from all relevant Border Nodes, then there will be a time-out and call request will be denied. MUSE Summer School July 2006 — 21 Muse confidential QoS Policy at Access Node > Access nodes are the first point of contact from end-user premise equipment. It is also the first point of multiplexing in access networks and so the policy enforcement is best done at the access node. > In a central CAC system, the policies are stored centrally hence for each connection the central CAC system makes the admission decision and signals the access nodes to either allow or block the connection and enforce the policy for the duration of the connection. QoS policy is thus pushed from the central system, adaptation is also done at the central system. > In a distributed CAC, QoS policies are available locally and the adaptation is also done locally using the thresholds and the congestion state of the network. The QoS policies are based on individual IP flows or aggregated flows. > Irrespective of where the CAC decision is made centrally or locally, the control or gating is done at the access node. MUSE Summer School July 2006 — 22 Muse confidential QoS Policy at Aggregation Nodes > The network elements in the aggregation network are usually Ethernet based in access networks. > The QoS policy consists of setting the priority for the different queues defined by the QoS identifiers e.g. ‘p’ bits. This is usually defined once during initial network planning and reflects the QoS classes in the network. > The QoS policy in the aggregation nodes is provisioned using the network or element management system. MUSE Summer School July 2006 — 23 Muse confidential QoS Policy at Edge Node > The edge nodes in access networks usually connect to service nodes via transport connectivity through the regional network. > The QoS policy is usually applicable to aggregated flows and is a part of the SLA between the access network operator and the service provider. > The QoS policy is usually provisioned and is rather static, and can be updated with a new SLA. MUSE Summer School July 2006 — 24 Muse confidential Policy Adaptation by Network Overload > The principle of adaptation by network overload is that the border nodes modify the QoS policy based on the overload conditions in the network. > Overload conditions for each link are determined by performance monitoring & the QoS policy system is triggered in the presence of overload conditions. > In case of calamities, if extreme network overload conditions are present, the QoS policies could be adapted such that there is a strict reservation of resources for emergency services (fire brigade, police, alarm, etc.). MUSE Summer School July 2006 — 25 Muse confidential Policy Adaptation by Service Characteristics > QoS policy can also be adapted to prevent QoS degradation because of sudden uptake of popular new services. > Assume that a new broadband “buzz” service is introduced which attracts a large part of the population. Each day hundreds of new subscription requests are received by the service provider. > In such cases, QoS policy adaptation could be implemented such that based on the service uptake pattern, new service connections can be rejected more often. This solution is more acceptable, than the solution where existing users experience a degradation of the service. > A typical implementation could be that service based traffic overload counters are compared to the actual guaranteed load in the corresponding links. When a service exceeds the pre-defined maximum load for that service, then the policy for that service is adapted such that new calls for that service are rejected or a lower QoS is assigned to the new calls. MUSE Summer School July 2006 — 26 Muse confidential Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 27 Muse confidential Counters to Monitor Resources in Access Networks Counters: 1) Queue lengths per QoS class 2) Dropped packets per QoS class 3) Upstream / downstream throughput for all ports A1 A2 A3 A Ag1 B1 B2 B3 B Ag4 En1 Ag2 C1 C2 C > Counters can be used to monitor the node & link resources. > The counters could count the events (e.g. dropped packets) & also quantify the traffic throughput, total dropped packets, queue lengths, etc. and provide averages per time period. MUSE Summer School July 2006 — 28 Muse confidential Performance Monitoring for Synchronization of Resource Database Performance Counters: 1) Queue lengths per QoS class QoS: Resource Database 2) Dropped packets per QoS class 3) Upstream / downstream throughput for all ports 1. Threshold crossing events for counters 2. Available link capacities 3. Overload events > The performance monitoring system periodically updates the QoS resource system with the status of the link capacities. > The QoS resource system compares it’s view of used capacities of links, with the view from performance monitoring and synchronizes it’s database if needed. MUSE Summer School July 2006 — 29 Muse confidential Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 30 Muse confidential Overview of QoS Proposals > QoS proposals are proposed by international forums & standardization bodies such as ETSI-TISPAN, ITU, 3GPP, etc. > The common element in these proposals is that node based priority queuing combined with resource based admission control provides QoS assurance to the flows as per QoS class. > MUSE proposal after detailed analysis identified many important differentiators from other proposals while the overall concept is common. MUSE Summer School July 2006 — 31 Muse confidential ETSI-TISPAN (R1) Resource Model for QoS AF Gq’ NASS e4 RACS SPDF Rq A -RACF Ra Ia Re C - BGF RCEF CPE Access Node L2T Point IP Edge Transport Layer MUSE Summer School July 2006 — 32 Muse confidential Core Di Border Node Ds MUSE QoS Differentiators The main differentiators of the MUSE proposal are: • • • • • • IP awareness in Access Nodes. Concepts of loose & tight QoS. Local / distributed resource & admission control. Policy enforcement at edges. Flow or aggregate based enforcement based on location. Scalability. MUSE Summer School July 2006 — 33 Muse confidential Agenda > QoS with resource based admission control > Tight & loose QoS models > QoS in carrier & application network models > Distribution and adaptation of QoS policies > Performance monitoring for QoS > Comparison of Muse QoS principles to other QoS proposals > Conclusion MUSE Summer School July 2006 — 34 Muse confidential Conclusion Good traffic engineering combined with CAC is the key to providing QoS in access networks. Judicious choice of ‘Tight’ & ‘Loose’ QoS Centralized or distributed CAC as per size of network domain. Regular load monitoring of network and corresponding QoS policy adaptation. Policy enforcement based on flows as close as possible to the origin of the flow, while based on aggregated flows further into the network. Open architecture for multi service / multi provider Acess MUSE Summer School July 2006 — 35 Muse confidential Thank You! MUSE Summer School July 2006 — 36 Muse confidential